<nckx>It was a guile-parted bug. <sneek>marusich, you have 2 messages! <sneek>marusich, dftxbs3e says: I would like to try and rebase the branch on master ASAP <marusich>sneek, later tell dftxbs3e we need to rebuild the bootstrap binaries in order to fix the problem with the statically linked guile, right? Do you know how to fix it? Re: rebasing on master, that's fine w/me if it works. Last time, I merged master into wip-ppc64le, so I'd prefer merging, but rebasing is fine too. <marusich>sneek, later tell narispo neat, it's good to see things being reported in the Guix Data Service. Who's building this? Is somebody running Cuirass on a powerpc64-linux system, or is the build farm using the transparent qemu binfmt trick to emulate the builds for the arch? <leoprikler>Can Guile/Guix shell-escape strings during build phases? <leoprikler>oh, wait, format ~s probably does what I want already <ngz>leoprikler: Regarding oshu revival, LGTM. You may want to sort inputs alphabetically and replace @dfn{oshu!} with simply Oshu! in the description. <leoprikler>sorting done, but I'd personally prefer lowercase oshu <ngz>Fair enough. But @dfn was odd anyway :) <ngz>Nothing (hence the capital letter), or possibly @code{...}. <leoprikler>I think I could use @command for oshu without !, but oshu! with bang is neither code nor command, but rather a pseudo-trademark™ <ngz>It the title of a work, isn't it? <leoprikler>In an abstract sense maybe, but in a more concrete sense it is the name of a product, and those are typically case-sensitive. <ngz>Hmmmm... What about ``oshu!''? <leoprikler>@i seems closest if I take a quick look at rgrep <ngz>I would lean towards consistency in this case, but anything goes. <lfam>Oof. That is an old patch <leoprikler>W.r.t. renpy-build-system: That patch only solves part of my problem sadly, the other part is that the game still fails to run since it's meant for an ancient version of Ren'py and there's no source code to go fix it. <leoprikler>I think that's what I get for trying to package stuff for the evil channels. <leoprikler>Hmm, not quite, I could try using unrpa et al, but they're not yet packaged either <lfam>`git shortlog -n -c --summary v1.2.0..HEAD` 🤯 <lfam>No, but less time has passed <leoprikler>True, but we also have more rust packages since. <leoprikler>If I finally get down to package fractal, that's easily 50 more. <lfam>There's also `git shortlog -n --summary v1.2.0..HEAD`, which shows authors instead of committers <ngz>I'm cheating. I packaged Rust stuff. <lfam>`guix import -t crate --recursive github.com` <ngz>nushell alone required 270 dependencies… <ngz>And it was bumped to a new release like 2 days after I pushed it. Depressing. <leoprikler>btw. is there a way of handling rust packages, that must be created from a specific git commit? <ngz>You can fetch source from a git repository, not necessarily from crates.io <leoprikler>okay, but what if the git repo does not mirror the layout in crates.io? <ngz>I don't know. I guess I didn't encounter such beasts. <ngz>Is your question theoretical or do you have a crate in mind? <ngz>And your package definition fails? <leoprikler>I've already packaged 0.2 on a branch of mine, but the commit is somewhere between 0.1 and 0.2 <leoprikler>Well, I can't get the git-fetch variant into my dependencies. Cargo yells it doesn't exist. <ngz>hmmm. I don't know, sorry. <leoprikler>Don't worry, I wouldn't be asking if it wasn't something extremely arcane in the first place 😄️ <marusich>sneek, later tell dftxbs3e I am not actually sure we need to rebuild the powerpc64le-linux bootstrap binaries. What is the problem with the statically linked bootstrap guile? It seems to work when I use it. *apteryx is adding a static output to QEMU <vagrantc>for the qemu-user stuff? or something else? <apteryx>the qemu:static output will be equivalent to the 'qemu-user-static' package of other distros <apteryx>useful to unlock qemu user-emulation with other container manegement systems such as Docker <apteryx>(I'll need to expose a fix-binary? switch to the qemu-binfmt service, which will switch the qemu binaries to the static versions and set the F flag for the binfmt registrations <apteryx>after that the qemu user emulation should be available for any application <apteryx>should be easy once I have the package bits in place (qemu just finished building successfully) <vagrantc>i had proposed a bug to enable soemthing like this for a smaller closure when building foreign binaries... <Aurora_v_kosmose>Should I package a library that seems like it may be abandonware beyond the Debian team or not? <Aurora_v_kosmose>I realized it died when I went to port my chatbot to Guix (to create a portable tarball) and found I couldn't find cl-irc. ***spk121_ is now known as spk121
***amfl_ is now known as amfl
<wumpus>i'm trying to get shutdown through 'virsh shutdown', which simulates the ACPI power button, to work in a GUIX VM, is there a simple low-overhead way i'm overlooking to do this? i know acpid exists as a package but there's no service for it, and pulling in the desktop services just for elogind-service seems overkill <Aurora_v_kosmose>From within the VM, when you send the virsh signal, do you see anything happen in the kernel logs & other system events? <g_bor[m]>wumpus: i guess you can just pull in elogind service *Aurora_v_kosmose is wondering if it's just ignored entirely or some option <Rovanion>The path used in the `head` call is copied from the `guix` call. <milkey>i'm thinking about packaging some ethereum stuff, would it make sense to make a (gnu packages cryptocurrency) module? <milkey>then we can move bitcoin-core out of finance.scm <Rovanion>And I've done the inverse. Modified the `head -n 1 $file` call so that it reads `guix environment --ad-hoc --load=$file` instead. And its in the same shell with the same user. <Rovanion>Ran strace on it and found the issue. The file not found error comes from invoking the code in the file rather than guix not finding the file. That should be fixed... ***rekado_ is now known as rekado
<alextee[m]>is it ok if my patch includes the removal of extra space at the end of a line somewhere else in the file I'm editing? <wumpus>Aurora_v_kosmose: i'll check, but what i expect is that the ACPI signal reaches the kernel fine (as it works for other Linux-based VMs like ubuntu), there's just nothing in userspace that triggers a soft shutdown in response <wumpus>g_bor[m]: yes, just biting the bullet and installing elogind (and whatever it pulls in, some dbus service related things?) would be one option, it seemed overkill to have for a tiny VM, so i was just wondering if this had been considered before <wumpus>i really want to avoid pulling in 'desktop' stuff like X11 and display managers and fonts, but maybe my worry is ungrounded there <leoprikler>alextee[m]: it will maybe cause a little stress to the reviewer, but we aim for proper indentation anyway <leoprikler>you may want to separate the line noise from your actual commit however <nckx>alextee[m]: Better to keep it separate. If you're thinking ‘well that's not worth a patch...’: there are (surprisingly many) more " $" in .scm files alone. <nckx>But they're optional; one fix is better than none. <alextee[m]>it's just a bit annoying for the audio.scm file because my editor auto-corrects that and I have to keep removing it from the staging area lol <nckx>Yeah, git hides a lot of stuff to L. <alextee[m]>it's basically a GUI version that allows you to stage/unstage things interactively <leoprikler>I have aliased gitg to "git gud", but only use it to look at the tree. <leoprikler>if it packs a large bunch of rust stuff, that belongs to crates anyway ;D <pretzel>leoprikler: Thanks for the suggestion. It's a simple patch (approx. 10 loc), but I'd prefer a diff. mdevos: Thanks. I fail to understand how to use such a plain-file as with-patch argument (latter seems to expect a path string not a file-like object). <leoprikler>It might be easier to use guix' package facility directly rather than through (guix transformations) here. <cage_>i am trying to install guix stable on a ubuntu (last stable) and it fail to build guile 3.0, someone got the same problem? <xelxebar>Hrm, I have a (udev-rules-service 'foo foo-rules) entry in my services, but after a reconfigure the rule isn't showing up under the output reported by herd rules udev... <cbaines>cage_, are you installing through building from source, or using the binary installation? <cbaines>cage_, OK, the binary installation shouldn't involve building guile, so when's that happening? <cage_>i deownoladed the image and followed the instruction to setup the environment (making '/gnu' directory making build users etc.) <cage_>than typed git pull to update the channels <cage_>and just 'guix install hello' <cbaines>Ok, so I'm guessing you've installed Guix successfully then <cbaines>and you're having problems when doing guix install hello <cage_>i get the command and all the infrastructure, so i think yes :) <cbaines>What specific derivation fails to build? <cbaines>when I say derivation, I mean a file within /gnu/store ending in .drv <cage_>sorry but i am just starting with substitutes, can you explain me what are or point to the manual? <cbaines>so you're looking for a line like: build of /gnu/store/1h6cjgrldak6z3qqrpnwvjh2cdr04955-0ad-0.0.24-alpha.drv failed <cage_>i skipped that point before ^^; <cage_>i enabled substitutes and installing 'hello' again <cage_>seems that is pulling binary packages now <cage_>should i update guix using 'guix pull'? <smartineng>Hello, is guix has gnat/gcc-ada compiler in the package repository? <janneke>smartineng: no, i don't think gnat/ada has not been bootstrapped yet <smartineng>there are some serious issue with it or just no time to fix it? <janneke>i believe there's a cyclic dependency, but a search may give better information <nckx>smartineng: You need an Ada compiler to build GNAT, and I failed to find an Ada compiler that can do so that can be built from source... <nckx>smartineng: I'm not an Ada programmer though, there may be an obvious choice that I'm not aware of. <apteryx>sneek: later tell vagrantc oh nice, we'll manage to squash a bug in the process :-) <sneek>apteryx, you have 1 message! <sneek>dftxbs3e, you have 1 message! <sneek>dftxbs3e, marusich says: we need to rebuild the bootstrap binaries in order to fix the problem with the statically linked guile, right? Do you know how to fix it? Re: rebasing on master, that's fine w/me if it works. Last time, I merged master into wip-ppc64le, so I'd prefer merging, but rebasing is fine too. <dftxbs3e>marusich, oh well yes merging is fine too, I just kind of dislike merge commits aha <dftxbs3e>marusich, I think we do, I am not sure yet if that guile-static binary is in the bootstrap binaries themselves or built using them (my investigations for this were inconclusive). I am not sure why it contains such a reference and the binary seems not static at all since there's few dynamic libraries listed by ldd. <dftxbs3e>marusich, I think we could detect this better using the forbidden reference functionality..? <dftxbs3e>Going to review some patches now, since that how I think I will be most useful as a committer first! <leoprikler>Rust folks, how do you deal with "the trait bound `anyhow::Error: std::error::Error` is not satisfied" <hapster>is anyone else having troubles with guix pull? <hapster>I seem to have a problem with guix-package-cache *nckx pulls. Could you paste the entire error to paste.debian.net, hapster? <nckx>& do you use channels in addition to the canonical Guix upstream @ Savannah? <dftxbs3e>nckx, hello :-D ! I am using "make authenticate" before pushing and it says it can't verify my commit for some reason. "key 148B CB8B D80B FB16 B1DE 0E91 45A8 B1E8 6BCD 10A6 is missing" - Is that my GPG install or..? <dftxbs3e>(it also fails with ./pre-inst-env make authenticate) <mbakke>dftxbs3e: try updating your 'keyring' branch <dftxbs3e>mbakke, okayy!! thank you! I have GNU Guix's official remote named "upstream" instead of "origin" there. <hapster>I do use two channels but those share the "dont speak about it" characteristic ;-) <mbakke>dftxbs3e: also, there is a 'pre-push' hook in 'etc/git'; it will run make authenticate for you to ensure no bad commits are pushed :-) <mbakke>(but you need to install it manually) <leoprikler>dftxbs3e: hmm, rust-playground does not complain, but trying to build fractal in Guix delivers a bunch of those errors <dftxbs3e>leoprikler, can I reproduce the error somehow? Got a patch? <nckx>smartineng: Thanks, will read later. <nckx>hapster: Could you share bitte das Erstellungsprotokoll? (bzless/bzcat/... /var/log/guix/drvs/as/lr254bx5qr3rzw3rqlk29iqx45vc0x-guix-package-cache.drv.bz2) <jonsger>hm, simple-cuirass-service is simply not working like I want it :( <dftxbs3e>It's a bit annoying that "git checkout <branch>" invalidates make caching by altering dates <leoprikler>I haven't had that issue yet. My branch diverged from master five days ago or so. <leoprikler>so the large number of rebuilds is probably caused by that <dftxbs3e>leoprikler, I didnt mean it for your branch, been switching to and from "keyring" to update it. <nckx>hapster: Never mind; I'm pretty sure the error is in a naughty channel, not in Guix. Please try disabling those before reporting bugs. <leoprikler>Some nice advice to Guix from Rust: "[A] library should not be deterministically recompiled for all users of the library." Just where did we go wrong? <leoprikler>It's a joke at the expense of Rust, since we aim to reproducibly build everything, not just end-user applications. <raghavgururajan>builder for `/gnu/store/mlpp94hpr5difzw9lbzjc2n3a83lrng7-qtsingleapplication-0-53.9568abd.drv' failed to produce output path `/gnu/store/r1rdqiramrj757v0l3j02kl26qi74b54-qtsingleapplication-0-53.9568abd' <leoprikler>hmm, that means that "make install" or whatever equivalent did exactly nothing <dftxbs3e>leoprikler, well I think it's mainly because it's the end-user application that defines things like RUSTFLAGS and not libraries themselves, and in GNU Guix we don't currently reproduce libraries since we only package source code right now. <dftxbs3e>It would be nice if the remote's name for checking keyring could be configured, like "origin" or "upstream" <leoprikler>We (more or less) reproducibly build other libraries just fine and there is at least one patch in the ML that fixes Rust's weird take on software architecture. <dftxbs3e>leoprikler, they just don't have a stable ABI yet heh, does that thing also happen with Go by the way? <dftxbs3e>leoprikler, I got an hash mismatch for rust-sourceview4 <leoprikler>btw i tried ("rust" ,rust-1.50)("rust:cargo" ,rust-1.50 "cargo") and the same happens <dftxbs3e>leoprikler, I ran "./pre-inst-env guix build fractal" on your "fractal4" branch, expected hash: 1bm1y4k3czplyf796cxgs4k6lrdhkjb7f52ligml73pakz9s1q26 actual hash: 0aib8385fxdpw79sasfzn6q11sqx3wigkb267if9fb12bagycgpk <dftxbs3e> /gnu/store/1cfcs1h1842iy096s5m73kj4m2zrnwlw-rust-sourceview4-0.2.0.tar.gz <dftxbs3e>leoprikler, tell me when you push something that can reproduce the fractal error :-D <leoprikler>just add (recursive? #t) to the git-reference of rust-sourceview4-for-fractal <leoprikler>then you should no longer have the hash mismatch <dftxbs3e>leoprikler, okay! done! Building fractal now <dftxbs3e>nckx, leoprikler: what's the policy for copyright lines? when should we add them? is it always at the discretion of the contributor? should we do it for contributors if they didnt (or suggest that they do)? Nobody ever told me to add them since I don't myself. <leoprikler>I personally tend to forget them as well, but at least for major contributions such as non-trivial packages, you should definitely add them. <abcdw>dftxbs3e: acquired a commit access?) <leoprikler>btw. it reproducibly fails for the non-recursive git checkout with your hash as well <dftxbs3e>cbaines, hello! :-D it would be nice to be able to checkout in guix-patches directly to bug-ids or something, like <bug-id>-v<n> <rekado>dftxbs3e: do you mean in issues.guix.gnu.org? <dftxbs3e>cbaines's guix-patches allows me to cherry-pick patches submitted to the ML as commits directly <nckx>dftxbs3e: re: copyright, for small changes I just follow what the contributor did; for ones that are obviously significant and lack a copyright line I always ask (the name/mail they use for git might not be the one they want recorded there, for whatever reason). <dftxbs3e>leoprikler, why as soon as I change whatever input it says: error: failed to select a version for `cairo-sys-rs` ? <leoprikler>did you get a version conflict or is there no cairo? <dftxbs3e>leoprikler, this happens whenever I update an input's definition or add inputs to the list, I didnt do anything related to cairo at all. <dftxbs3e>leoprikler, versions that meet the requirements `^0.10` are: 0.10.0 <dftxbs3e>leoprikler, the package `cairo-sys-rs` links to the native library `cairo`, but it conflicts with a previous package which links to `cairo` as well: <leoprikler>the stuff you're adding into the mix probably have their own cairo, which is older <leoprikler>you need to bring in libraries, that build against cairo-sys-0.10 or that don't build against cairo at all <dftxbs3e>I am thinking this is somehow due to Cargo.lock not being respected, but building 4.4.0 separately to investigate <leoprikler>hmm, perhaps it's due to the cargo inputs, that still get propagated by rust-sourceview4-for-fractal <leoprikler>(since the inputs are the same as rust-sourceview4-0.2, but they'd actually differ) <marusich>dftxbs3e, which guile are you looking at? The one contained in the bootstrap binaries doesn't seem to be a dynamically linked executable. <dftxbs3e>marusich, the one resulting from guile-static-stripped@3.0 <marusich>Do you encounter an error when you use "bin/guile" from that tarball? <marusich>It does work for me without erroring out. <cage_>the guix file now works flawlessly with my software, thank to you all! <dftxbs3e>marusich, it works for me too, so it's probably not bootstrap binaries <marusich>OK, well at least that's good; I dread rebuilding them :( <avalenn>dftxbs3e: Go and Rust seem to really be on the same "there is no such thing as binary library" page. <marusich>If you can provide more details about the guile you think is not working, I can help investigate, but right now I don't know which guile you're referring to. <marusich>guile-static-stripped@3.0 is the one built and included in the bootstrap binaries, right? <dftxbs3e>marusich, it's guile-static-stripped@2 in the bootstrap binaries it seems <dftxbs3e>marusich, just run ./pre-inst-env guix build guile-static-stripped@3 - I think you'll meet the error. Basically that package is used when building a GNU Guix System image <dftxbs3e>Basically the binary contains a dynamic link to glibc with "eeeeeee.." in the gnu/store path which means it was erased by GNU Guix, so the binary does not run obviously <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, apteryx says: oh nice, we'll manage to squash a bug in the process :-) <vagrantc>is that test potentially indirectly dependent on the network somehow? <vagrantc>it works fine on my machines and the official debian build machines, just not on the reproducible-builds.org tests infrastructure <vagrantc>build log is available from the above URL <vagrantc>but, it's not clear to me exactly what is failing with that test <vagrantc>apteryx: fwiw, debian's qemu-user-static basically works without having any binaries in the chroot for some time now <vagrantc>and in theory the non-static variant as well *vagrantc waves hands magically <vagrantc>have mixed feelings about the way guix uses qemu for emulated foreign architecture builds ... having the entire closure of qemu available in the build environment would seem to potentially taint the purity of the build environment *vagrantc wonders if a bit of kernel-level deception wouldn't be better in this particular case <vagrantc>NieDzejkob: part of the issue may just be my lack of fluency with guile ... <leoprikler>dftxbs3e: if you want to reproduce it, I've force-pushed fractal4 <vagrantc>is there a /bin/sh in the environment used by guix-daemon to build packageS? <leoprikler>nckx: not quite. I read this as "if you somehow manage to bootstrap ancient GNAT, you can probably jump to modern GNAT easily", which is an interesting proposal at least (*cough* rust *cough*) <nckx>leoprikler: I didn't read it that way but that would be better indeed. <nckx>Well, hm, no: that just leaves ‘manage to bootstrap ancient GNAT’ as the original begged question. <nckx>I read ‘not worth it’ as ‘we never bootstrapped from C’, so GNAT 0.1 isn't going to be better. That said, I haven't found it yet ☺ <leoprikler>of course, but I'd imagine that a sufficiently ancient GNAT can be compiled with a different Ada and some spit. <nckx>The only Ada we have conforms to a standard that predates GNAT, is the problem. <nckx>I'll give looking for the oldest surviving GNAT another go, so we're not just slinging hypotheticals at each other. <dftxbs3e>leoprikler, yes.. I didnt think the upgrade would solve it <dftxbs3e>leoprikler, the error doesnt make sense basically, but it's not easy to modify upstream code and test changes <leoprikler>I've also specified inputs for sourceview4 now, so you should be able to go ham without stuff breaking <euandreh>Is there a way to (local-file ...) to escape PWD? I wanted to reference (local-file "~/.ssh/id_rsa.pub") but the tilde won't expand, and running "guix deploy" will prefix $PWD <euandreh>so I get the error: guix deploy: error: canonicalize-path: Aucun fichier ou dossier de ce type: "/home/andreh/dev/libre/servers/vps/~/.ssh/id_rsa.pub" <raghavgururajan>leoprikler: I hope you received my follow-up email for v11. Seems like we can't use QtSolutions. There are classes missing. <euandreh>aaaaand it works like a charm. ty leoprikler <leoprikler>raghavgururajan: any specifics as to what class it's missing? there doesn't seem to be anything in nextcloud's tree, that adds to it <leoprikler>(substitute* (list "src/gui/application.cpp" "src/gui/application.h") (("SharedTools::QtSingleApplication") "QtSingleApplication")) <apteryx>vagrantc: from what I've read non-static variants wouldn't work because dynamically loading wouldn't be allowed to work from the container <apteryx>Actually I've tried it and it doesn't work, this is what Guix uses when you configure the qemu-binfmt service <apteryx>it gets away with it in the case of guix-daemon by adding many --chroot arguments to bind expsoe transitive dependencies of qemu (so that it can dynamically load them from the container) <apteryx>I have tried the dynamically linked QEMU with the fix binary (F) binfmt_misc flag though <dftxbs3e>leoprikler, still looking, but will continue tomorrow! <marusich>dftxbs3e, do you know what the syscall id for clone is on ppc64le? I want to add it to guix/build/syscalls.scm (search for existing string "mips" to find the code I'm looking at), since I think that might be why some guix tests are failing. <marusich>I am not sure how to find the syscall id, although it seems like it should be trivial........ <nckx>marusich: arch/powerpc/kernel/syscalls/syscall.tbl ? <marusich>I guess it's automatically generated (of course it is..) in glibc <marusich>The clone procedure hard-codes these, presumably for linux. <nckx>I assume (but haven't checked) that glibc simply includes the kernel definition. <marusich>FWIW there is a TODO that says "don't do this" :) ***seepel1 is now known as seepel
<jackhill>When creating a package for a daemon, for which there will be a system service, should anything special be put the in the package description? <leoprikler>$package is next to useless from command line, use $service instead? <jackhill>leoprikler: Something to directly people reading the description to documentation for the shepherd service. <leoprikler>I don't think that's done anywhere in Guix. See e.g. the gnome package, which is used for gnome-desktop-service-type. <jackhill>Perhaps, it's not nessisary, or something we ordinarily do, and that's okay, but as long as I'm writing the description I thought I would think about it :) <vagrantc>apteryx: yeah, the F flag is key to it being amazing :) <vagrantc>apteryx: i think because the kernel is handling it, it isn't limited by the chroot of the working environment ... but further testing needed to be sure <brown121407>Hi, Guix! Knowing that we have a "kernel" field in the operating system configuration and that Guix works on at least two kernels (Linux and Hurd) does this mean that we could one day have a GNU/BSD operating system with Guix running on top of a *BSD kernel? Is this possible? <pkill9>brown121407: i think someone/some people have looked into that, i can't remember what the verdict was <cbaines>I think one issue is software support for the kernel, glibc works with Linux and the Hurd, but I'm unsure about BSD? <vagrantc>debian has a GNU/kFreeBSD port which has some patches (maybe upstreamed by now), but it isn't a very mature port. but definitely possible <brown121407>cbaines, does Guix directly depend on glibc? I mean, is it something in glibc that other libcs don't have that makes Guix work? <vagrantc>so, theoretically possible, though i think guix relies (or at least prefers to have) some linux specific features for the container features used to build packages and such <cbaines>brown121407, Guix doesn't directly, but most things packaged for Guix directly or indirectly use glibc <jackhill>What about nscd, is that a glibc feature, and how important is to to Guix to avoid loading conflicting libcs for name and other database lookups? <nikita`>guix is very glibc specific. i abandoned my explorations of a port to netbsd because it also needs to support the kernel + libc combinationation (more or less). freebsd gets away with some linuxisms in their kernel, but i have no idea if glibc works for them with lots of pretending and patches. doesn't for us, and doesn't for openbsd as far as i can guess <nikita`>also for anyone suggesting the idea of GNU/BSD combination seems somewhat okay and who doesn't approach this from a Linux perspecitve, please take 5 steps back from the idea and look at what makes BSD BSD and why this is a bad idea. <rekado>jackhill: nscd is part of glibc. It is indeed used to provide a stable client-server protocol for user names as an alternative to loading plugins that have been built for a different C library. <milkey>a step in that direction would be getting stuff building on top of musl libc instead of glibc <rekado>milkey: there’s really no point in doing this without glibc <rekado>you can swap out kernels easily (as long as they are supported by the glibc), but you can’t easily swap out any of the lower level parts that the Guix package graph is built upon. <vagrantc>huh. never made the connection between the SD in BSD and the "old" GuixSD <milkey>i would be interested in a version of guix using musl & clang instead of glibc & gcc but it's not worth spreading the developer effort too thin <milkey>coming from gentoo I'm used to doing weird things like swapping out one libc for another, but I appreciate stock guix breaking much less often :P <apteryx>vagrantc: I'll try it, if I get the time tonight <vagrantc>milkey: wow, surprising to hear there are other systems that break more :) i really like guix and all ... but it does have some surprising tracebacks pretty often. :) <milkey>at least when guix breaks it's reproducible most of the time <sundbry>it might work on illumos, it has a linux kernel compatibility mode built in <sundbry>that would be an interesting project ffor a hypervisor running on guix <leoprikler>For a software that breaks all the time, Guix is surprisingly stable :)