IRC channel logs
2026-02-04.log
back to list of logs
<FuncProgLinux>It seems I skipped something important while learning guix lol <ieure>matf, I assume it's some combination of dumb hardware and software hacks that only work in Windows, or something. I assume if I kept their Windows image on it, it would work better. <mange>Yeah, the $HOME/.cache being owned by root is caused by the "-E". Just drop that and you'll be fine. <mange>Actually, that's slightly too strong a statement, but it's close enough. :P <ieure>FuncProgLinux, Okay, well. `guix upgrade' upgrades packages in your user profile, which are implicit ones -- stuff you use `guix install' (etc) to manage. It is uncommon to use Guix Home and an implicit profile at the same time, and IMO generally not a good idea. <ieure>FuncProgLinux, See if you even have any packages in your user profile and if not, drop the `guix upgrade'. <ieure>`guix package -I' will list those packages. <FuncProgLinux>ieure: The guix upgrade thing solves the mistery of why it always reports there's nothing to upgrade <ieure>FuncProgLinux, Aha, there you go. <ieure>matf, S3 sleep is supported by substantially all Intel CPUs. There might be firmware/EC bugs with it that prevent it working. <FuncProgLinux>guix package -I does show packages but those are the MATE ones I maintain so it makes sense there's nothing to upgrade lol <matf>In any case, I'm looking forward to using the Comet. I have been daily driving phones running mobile Linux for years, and was using Guix package manager on Droidian on my keyboard phone (mentioned it here already, with another user name), but I could never daily drive something running a mainline kernel. This can, and should have telephony features. <ieure>FuncProgLinux, I'd move those to your home or system config. <ieure>matf, Yep, also interested. Been burned too many times to buy blind, but am keeping an eye on things. <matf>mange: interesting, I learnt here to use sudo -E and have kept doing that for years. My cache was indeed often broken. Good to know I should drop -E. <ieure>-E preserves the environment, so $HOME is your user's home instead of /root <FuncProgLinux>ieure: They are there in the system config. I have my variation of the "mate" package for the mate-desktop-service with some extras but I often test those in the channel itself. <FuncProgLinux>I think it tells me there's nothing to upgrade because in the channel I always build and then install to test (and forget I did that and accumulate packages). <ieure>I use `guix shell' for that kind of testing, they get removed on the next `guix gc'. <ieure>*most of that kind of testing <matf>ieure: many of my UMPCs, including GPD, are now AMD based and not Intel. My Pocket 3 actually is my only Intel one and I use it every day so any drain during sleep would be painless actually.oh there's the MPC2 too actually but it does seem to drain fast during sleep. The others with AMD do too. <matf>(Sorry for the typos/broken sentences, I'm ob mobile.) <FuncProgLinux>Second question, what's our stance about "-next" variants of libraries? <jungy>This is going to sound silly, but one of the advantages to me of a lisp like guile is its interactive dev cycle---what I can't find is, is there a way to open up guile such that you have access to the modules that guix references? <FuncProgLinux>Is: "it's needed for package upgrades" enough for an excuse? <mange>jungy: I don't quite understand the question, but there's "guix repl" which is a Guile REPL with Guix's modules on the load path. I've also had geiser working well-ish for me recently, but I can't remember if I have special config for that. <matf>I'll try to remember you're interested in the Comet ieure when I get it, if you need some info, feedback, or even Guix testing. Do ping me if you decide to pick one (always connected here as kabouik). <jungy>mange: That's exactly what I was looking for. <matf>Anyway, sad that the Nix importer is dead. Importers are great and Nix was a massive source of packages. Would love to see that revived officially. <jungy>I need to figure out how to setup a service, and I've really only done that with systemd and initd. Testing it only with guix system reconfigure is troublesome. <ieure>matf, Thanks, I will strive to remember (but probably forget). <mange>When testing services I've usually used "guix system container" and "guix system vm". <ieure>jungy, Geiser is very helpful here. It's uh... not as good as CIDER or SWANK/SLIME, but gets the job done. <jungy>That's fair. Not as good as SWANK is not really much of an insult. SWANK/SLYNK/SLIME are phenomenal. <clone>How's ares/arei? I haven't tried it yet <duncan>there was a guy at FOSDEM who was going to talk about it but he ran out of time <duncan>actually, maybe he did? some sort of REPL protocol was involved <duncan>there was a rapid series of good talks, that was the first one I saw in that room <duncan>one impression I did get was that it was all heavily tied up with guix, which makes me a bit wary - I need to use the same tools on various computers and most of them don't have guix <apteryx>for guix shell, any argument, e.g. '--pure' invalidates its behavior of using the local manifest.scm implicitly, correct? <apteryx>that's good, but contradicts the doc, which says "As an added convenience, ‘guix shell’ will try to do what you mean when it is invoked interactively without any other arguments [...]" in (info "(guix) Invoking guix shell") <burley>I'm new guix system user and started following the conversation about using "guix install" vs. "guix home" to manage non-system packages. Is one approach recommend over other - or is one more common? <clone>Just from looking at peoples configs I think guix home is more popular for people who are deep into guix. One of the coolest draws of guix is the ability to manage your entire system declaratively after all. I think guix package is mostly used for profiles that aren't loaded by default, and for people coming from other distros who want a more familiar experience. <jungy>Is there a way people tend to quickly move from guix install to a more declarative style after the fact? Like, an easy way of dumping installs into the system configuration? <clone>you can do guix package --export-manifest and then change specifictions->manifest to specifications->packages in the output. A lot of people seem to like to use the package variables directly instead of manifests though, and I don't know if there is an easy way to generate them or what the difference really is. <jungy>This is my first Guix system, and barring unfamiliarity it's pretty pleasant so far. <mange>I basically never use "guix package" or "guix install". I use Guix Home, and I have a lot of project-specific shells (which are automatically activated using direnv). <jungy>Guix repl was recommended to me earlier today but it doesn't seem to work-- <jungy>$ guix repl /gnu/store/ccxagad0fnzyh0z5xflh3wjlxn4la79n-guile-wrapper/bin/guile: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <jungy>Is this a matter of just a corrupted glibc, or something obvious I am missing? <mange>Huh, that's an odd one. When I run "guix repl" it just works. Out of interest, what does "which guix" report? <jungy>it reports: /home/jungy/.config/guix/current/bin/guix <mange>Okay, that checks out. Do you have $LD_LIBRARY_PATH set? <mange>Have you printed it to make sure? Some Guix packages set it unexpectedly (like the Awesome window manager). If it's not that, then I don't know why it's not working for you, but is for me. Sorry! <jungy>I echo'd it, and it was blank <jungy>Not sure what needs to set/provide it by default. <jungy>I kinda figured guix'd have the standard build tools set up by default since it seems to like installing things by source. <mange>Guix builds things from source in isolated containers, and opportunistically pulls pre-built binaries from substitute servers. This means that you won't necessarily have the build tools in your shell. <mange>Do other "guix" commands work properly for you? What about "guix shell --pure guix -- guix repl"? Or even "guix shell --container guix -- guix repl"? <jungy>I'm not familiar with those commands <mange>"guix shell" constructs a temporary profile and starts a new shell with environment variables set to use the profile. "--pure" tells the new shell to use *only* the environment variables from the profile. "--container" goes further and also starts the shell in a new isolated container. <mange>If those commands work, but a bare "guix repl" doesn't, then that's a sign that there's something in your environment breaking it - but I don't know what. <jungy>Is there a way to safely verify/re-pull existing packages? <jungy>because it's probably that glibc package but I don't want to have to start a fresh installation to ensure that stability. <mange>I'm not sure that fits the observation, though. I would expect "guix shell --pure guix -- guix repl" to use the same glibc package. <mange>At any rate, "guix gc --verify=contents" might be what you want? There's also "guix gc --verify=contents,repair" to try to fix it. <jungy>guix repl works if you're running as root <jungy>it's a user permissions issue <jungy>perhaps that's by design actually? <mange>What is trying to access that it can't? The store is accessible to all users on the machine. <mange>"guix repl" does not require root on my machine, nor should it. <jungy>not sure, just reports that glibc issue <mange>You could strace it and see if there's anything permission-y that looks off. <oliverD>I'm trying to compile some of my old golang projects on guix but got this error: <oliverD>/home/oliverd/.cache/go-build/a0/a0e1442cbe30b662e0bb7085f532866d490771445c1f550e2934ee2198f8b4c0-d/draw-platforms: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <mange>Hey, that's the same error that jungy is getting, with the exact same glibc hash. That's very interesting. <mange>Can you both run "guix describe" and tell me the hash you have under "guix", jungy and oliverD? <oliverD>I'm use the Ebitengine (basic graphics library) which might be complicating things <oliverD> commit: 35785d787419d5ed799f26b9b84bf77ef6b9600f <jungy>64429ac5864d68d3ef066f4533a07ce32adc4f87 for me <mange>I'm trying to reproduce with those commits. Give me a few minutes. FWIW I'm on b556659af6fe3b1bcd2bdfefb060dac74e0bf491 (currently the head of master). <oliverD>(Ebitengine links with some x11 librarys, alsa, and openGL) <mange>I can't reproduce the error with 35785d787419d5ed799f26b9b84bf77ef6b9600f (the other one didn't work because of a different channel conflicting). If I build glibc@2.33 I get a different hash, too. <mange>Unfortunately I don't have more time to dig into this right now, but it is strange. You could try a "guix pull" to see if that fixes things, but it's a pretty random guess at this point. :) <oliverD>I'm using non-guix (for some firmware) but I don't think that should change anything <mange>It's also a bit weird that it's loading glibc 2.33. When I strace my guix it's loading glibc 2.41. <jungy>yeah I'll definitely give an update a try <jungy>I'm still super new to guix in general so I wouldn't be surprised if i did something wrong at some point. <mange>If it's possible to do something wrong, then I'd blame the system rather than you. :) I'd love to know what's happened, though, so we can improve things to avoid it in future. <jungy>No luck after updating to b556 <mange>The error still mentions glibc 2.33? <mange>Can you try something stupid, running: "~/.config/guix/current/bin/guix repl" (this should be equivalent to what you've been doing, but who knows...). <jungy>It seems to me that for whatever reason the user account doesn't have access to the same environment that root does. <mange>Okay, good. If that had worked I would have been unhappy (in a happy way). :) <mange>Everything in the store (i.e. under /gnu/store) should be world readable. <mange>You said it works as root. Can you try with "sudo -E"? That will run as root, but use your user environment. I expect that to fail. <mange>Yeah, it's something in your environment variables. I don't know what, but the issue is there. <mange>Can you look at the output of "env" and see if anything mentions glibc 2.33? <jungy>Nothing. Let me see what might be different with root on that command. <mange>It worked in "guix shell --pure guix", so it's not about the user - it's about the environment. <mange>The answer is in "env", somewhere. You could try to bisect the environment variables by starting a "guix shell --pure guix" and then exporting some environment variables and seeing which ones make it break. <jungy>the env command doesn't exist inside guix shell---is that something you can pass in? Sorry for the dumb question. <mange>Not a dumb question at all. You have two options: (a) you can find the path using "which env" and call it using its full path, or (b) you can add coreutils to your shell with "guix shell --pure coreutils guix". <mange>Sorry, for (a) you run "which env" outside of the guix shell. <jungy>Nothing immediately stands out, but I *do* notice they're using different glibc commits <jungy>guix shell uses 230a as opposed to the b556 mentioned earlier <jungy>there's a bunch of extra env variables for the main instance but most seem unrelated. Only ones they share that are different are PATH, GUIX_ENVIRONMENT, and _ <mange>That's actually expected. For self-referential reasons, "guix shell guix" actually pulls in an earlier version of guix in the shell. I didn't want to the muddy the waters with the difference, though. <jungy>and I assume that's mostly because guix shell is sticking to a specific /gnu/store location <mange>I would suggest actually testing the "seem unrelated" ones. <mange>As in, just pulling $PATH into your main shell fixes "guix repl"? <jungy>setting path equal to JUST /gnu/store/hinr...-profile/bin fixes guix repl <jungy>The original seems to be a bunch of symlinks <jungy>PATH=/run/setuid-programs:/home/jungy/.config/guix/current/bin:/home/jungy/.guix-profile/bin:/home/jungy/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <mange>Yeah, that's normal. That's the various directories that profiles and the system set up symlinks in. <mange>Can you check what version of guile you have on your path? "guile -v" <jungy>Yeah, I figured it would work equivalently <jungy>but for whatever reason that doesn't. <jungy>PATH=/gnu/store/hinr4rgszv2qrn2agynwvrirc4nmrx8g-profile/bin <jungy>When I run guix repl, guile version 3.0.9 <mange>Okie doke, well, I'm out of ideas. I thought maybe Guix was calling out the the Guile in $PATH, but looking at guix/scripts/repl.scm it seems like it just starts the REPL in its own process, so that shouldn't even be an issue. <jungy>Well, the fact that I can launch it in via guix shell is probably good enough for me <PotentialUser-45>Hi, I'm trying to create a system image on Guix version b556659 and the partition derivation fails with the same error every time: https://pastebin.com/APPE5QUj - I've tried time-machining to v1.5.0, using `guix system image -t mbr-raw`, using only an `operating-system` declaration instead of `image` and I get the same problem no matter what. Am <mange>Give me a couple of minutes. I'm trying it out locally and I'll let you know what happens. <mange>Heh, first problem was that ---snip--- isn't a valid SSH key. :P <mange>It also fails for me, but with a different error. <mange>".../grub-bios-setup: warning: this msdos-style partition label has no post-MBR gap; embedding won't be possible." <mange>".../grub-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.." <mange>Followed by an error that it won't proceed. <mange>I don't know why you're getting a sqlite error, though. Do you have multiple guix-daemons running, or something? <mange>PotentialUser-45: After adding an offset of (* 50 1024 1024) to the partition record the build completed successfully. So I don't know why you're getting that sqlite error, unless you have multiple daemons or something similar going on. <PotentialUser-45>I can see that an additional instance of guix-daemon runs only during the build, is that normal? When running the build it starts a second instance of guix-daemon with the PID of the guile interpreter as an argument. After the build fails the new daemon exits with it. I've already tried killing and restarting the guix-daemon systemd service, which <apteryx>hm, the jami-service-type stopped logging some time ago... I wonder if it could be the new syslog facility which is handled by shepherd <jakef>did you send the right youtube link in your recent email? <futurile>jakef: no I foobared it and send a link to a packaging tutorial I made heh heh - I need the views! <apteryx>hm, syslogd (from shepherd) does not seem to work? at least: logger -p user.warn "syslog test message" does not cause the message to appear in /var/log/messages <jakef>hate the game not the player <apteryx>(logger is from the inetutils package) <futurile>jakef: I wasn't sure where to put it, I think I'll publish it to the 'guix social' channel - not much point creating a new channel for 'foundation updates' <dariqq>apteryx: Do you use the shepherd default settings for syslog <apteryx>grepping 'syslog' turns nothing in my config, so I assume so <dariqq>because the logger example works for me (but I have slightly customized it) <dariqq>do you get any syslog messages at all? <futurile>audio in Linux, utter confusion in 3-4 subsystems <futurile>massively helped by 'search' and 'ai' - not! <identity>it is not noise because i just learned about it :3 <attila_lendvai>sadly, i just segfaulted the debugger while debugging something that segfaults by itself... :) <danlitt>How can you install a self-signed certificate on guix system? I am trying to use a self signed cert I generated to test a local service. Getting the private key into the service container is ok, I think, but I am having trouble figuring out how to get my localhost.crt file into /etc/ssl/certs (which I think is how it's supposed to work) <danlitt>My understanding is that the nss-certs package causes this directory to be populated, but I don't understand how, or how to modify it <mange>The ca-certificate-bundle hook looks for certificates in a package's /etc/ssl/certs. I expect if you add a package to your system which just puts your certificate at $output/etc/ssl/certs/localhost.pem that hook will figure out the rest. <mange>Sorry, that's specifically to get it included in ca-certificates.crt. If you just want it in /etc/ssl/certs then it might be enough to just include the package. <mange>... By which I mean include a package with a .crt in that output directory. <mange>Alternatively, does anyone know who I should ping on Codeberg about it? It doesn't fall under any of the teams (as far as I can tell), so I don't know how to get attention on it without annoying everyone. <danlitt>futurile,mange: thank you, I'll try those! <futurile>mange: I would email guix-devel; yeah it's a problem - I know nothing about Lua <mange>Rightio! To the emails I will go! <bjc>i've been getting 504s for the last few days trying to download the hurd image from ci. is there a working mirror somewhere? <renbus>Hello. I have an external drive that is configured to auto-mount on boot. However, I would like the system to boot even if the drive isn't plugged in. I use the (mount-may-fail? #t) line in the (file-system) form, but it does hangs on boot, the drive is still needed (if I reboot with the drive plugged, it will boot fine). I also tried with (options <renbus>"nofail"), the "nofail" does appear in the /etc/fstab file, but it still hangs on boot if the disk isn't plugged in. Do you have any clue what could be the issue? <lilyp>could you paste your config, or at least the part for that external drive? <futurile>hmm don't know, that seems correct from what I just read, lilyp -^ <Rutherther>renbus: what messages are printed during the failed boots? <ekaitz>futurile: do my emails sound reasonable? <newguixbie>it is kind of hard for me to dump the requests log information from before and now but I have it if helpful .. it would be grounding to know if it is expected for compressed urls to disappear <renbus>Rutherther, it doesn't display any error, the last line is simply "/dev/sda1 3 files 44/4343984 clusters". The external drive is /dev/sdb1. /dev/sda1 is /boot/efi, /dev/sda2 is a lvm group volume. It simply seems to stop when mounting the partitions, because the external drive isn't plugged in. I was expecting the (mount-may-fail? #t) line to avoid <Rutherther>renbus: pls send the whole screen you see. I cannot say for certain what part of the boot it is in based on what you shared <renbus>And since I have (options "nofail"), and this option appears in the /etc/fstab, I though it should be OK. It seems like the booting phase doesn't care about the "nofail". <renbus>Ok, I will have to take a picture of the boot screen. By the way, I just noticed that while the booting is waiting, if I plugged in the external hard drive, it automaticaly resumes booting, and log in correctly. <Rutherther> I think there might be a bug in the shepherd file system service. I will take a look later today <ieure>Would be very good to get this working and add LVM setup to the installer. <futurile>ekaitz: yes, I understood your point about 'trust', need to think about it a bit as I don't want to add 'load'. I already feel like guix 'admin' costs me a lot of time heh heh <untrusem>btw in which mode you subscribe to the mailing list? digest mode? <sneek>roptat, apteryx says: do you have a clear roadmap to packaging gradle? I've seen some package in one of your repositories, but wondering how usuable it is, or any unresolved issues that remained? <roptat>I haven't been there for a long time, so I'm not sure how recent this message from apteryx is... I haven't written any roadmap <roptat>you can get some inspiration from what I did in guix-more, but I don't think it was working <roptat>unrelated, I'm wondering what the "superseeded" property does exactly? it's not documented in the manual. Is it for packages that are going to be removed, or only for displaying a message if someone tries to use the package from the CLI? <roptat>in the property field of some packages, such us letsencrypt <untrusem>superseded package are those which are redundant now <futurile>heya roptat - hope you had a good guix days <roptat>ok, so they're not necessarily going to disappear, unless someone creates an issue with the "deprecation" label, following the deprecation policy, right? <roptat>I'm asking before merging a PR that adds java-hamcrest version 3, and adds the superseded property to java-hamcrest-{core,library,all} 1.3 which is still useful for bootstrapping java packages (so I wouldn't like it to trigger a removal ^^') <roptat>it seems that it would be fine, and it would warn users that using hamcrest-core should be replaced by using the more up-to-date hamcrest <sneek>Rutherther, you have 1 message! <roptat>pour les francophones, une idée de traduction pour "Full-Source Bootstrap"? <csantosb>"Amorçage complet à partir du code source", but this comes from Madrid, so take it with caution ;-) <csantosb>[codeberg] I just created a "world-rebuild" label, to avoid committing changes which impact too many dependents <yarl>roptat_: Quelle serait la phrase complète? <roptat_>ça vient du manuel : For @code{i686-linux} and @code{x86_64-linux}, Guix now features a @dfn{full-source bootstrap}. <ekaitz>efraim: I have built guix in my riscv machine, do you have anything that you'd like me to test from a bootstrapping perspective? <ekaitz>i prefer if you lead this effort <cdegroot>ekaitz: what RiscV machine if I may ask? I'm semicurious, would love to have a truly open hardware computer, at least one :) <ekaitz>but it is not open hardware really <ekaitz>the fact that the ISA is open doesn't mean hardware made with it is open <cdegroot>I know, but it's the only ISA that is open (and free-as-in-beer) so I'm hoping that someone builds a complete system based on the idea of open hardware <ekaitz>that's what we are trying to merge in guix (finally) <yarl>Rutherther: I did not know artifact-manifest.scm <ekaitz>FuncProgLinux: in that case I'll pass for the moment :) sorry <Rutherther>yarl: I am not surprised, that file is in the repository for like two months <newguixbie>were all the narinfos recently changed on bordeaux? what should i have read to have more success enumerating and fetching the packages of a new release? <newguixbie>i have a palsy and other issues and it can be quite taxing to redesign frequently <Rutherther>newguixbie: wdym narinfos changed? Already existing narinfos typically do not change. They describe a store path that's by design immutable. <Rutherther>there are a couple of things that could change in narinfos, but nothing that would change the result. Ie. a new compression could be added <Rutherther>yes it did, it indicated an event where a new compression has been added <newguixbie>but it sounds like i need to accommodate narinfos growing, this is reasonable, but i should probably study the current practices if they are documented <Rutherther>why are you looking at narinfos in the first place, are you making a mirror? <newguixbie>it takes me many days to write simple code im afraid <newguixbie>i was excited about 1.5 and wanted to try to do it quickly with python and substitute server apis, but compounding issues <dariqq>Rutherther: I am confused. Shouldnt the (catch 'systen-error ..) already catch failing mounts and ignore the error if file-system-mount-may-fail? <Rutherther>dariqq: 1. the error is not system-error, it's a misc error, 2. the error comes from canonicalize-device-spec that was outside the catch prior to my changes <Rutherther>it happens only for uuid / label devices that the canonicalize is trying to 'resolve' <Rutherther>although looking into the source I also see resolve being called for regular /dev/... device. Not really sure why that one was passing my test then <Rutherther>oh... it's a no op then, it's just (identity "/dev/..."), that always succeeds <Rutherther>I think it's a bug though, it should wait for it according to the comment <dariqq>Aah i see. I guess this never worked then? <Rutherther>I suppose, not sure. Something could've changed at unexpected parts of the code that I did not check <dariqq>there might still be a problem in case a mandatory mount is beneath an optional mount but i am willing to accept this as user error <dariqq>or similarly nested optional mounts <Rutherther>dariqq: btw super good news (I am kidding) I am again experiencing unclean unmounts of my root file system. I haven't gotten to debugging it yet. I am suspecting it's related to me adding a swap device. I think that the root-file-system is reached according to the delay, so there hasn't been any corruption for me. But still something keeps the root busy it seems... I added that swap device recently. Though I already checked the shepherd service and... <Rutherther>... it's root-file-system -> udev -> swap-/swapfile. So maybe it's not the right track. What's worse, it doesn't happen every shutdown, so it's hard to reproduce for me <newguixbie>my problem turns out mostly on my end. narinfo change unexplained but minor. <Rutherther>I am getting a bit tired of it. But at least the fix to Shepherd has managed to prevent corruptions <Rutherther>dariqq: I think I will add a second commit to my PR removing "mount-may-fail #t" from the file-system. Any objections to that? <dariqq>Rutherther: from where excatly ? <Rutherther>dariqq: under file-system-shepherd-services there's the sink, provisioning 'file-systems. It has "requirements" on all file systems of the system. So from these <dariqq>Rutherther: This would make the stop order unspecified for these so we would reintroduce the user-file-system problem but at least not with the root-fs <Rutherther>sure, I am also counting on adding it to the user-processes and user-file-systems requirements <Rutherther>I am not thinking straight for the past few days, sorry <dariqq>i think the best would be to just let it fail but treat it as success <cbaines>similar pages should work on data.guix.gnu.org, but they're timing out <Rutherther>dariqq: without the PR it happens only for file-systems specified by a string. The issue is that the whole boot is waiting for the service to start, it's prolonging the boot by 10 seconds unnecessarily (per each file system I think) <cbaines>and as you noticed, the nar-herder behind bordeaux.guix.gnu.org generates zstd compressed nars for some outputs, but these can be removed <cbaines>any URLs given in the narinfo should remain valid as per the Cache-Control header in the response though <Rutherther>cbaines: I am wondering, why aren't rather the uncompressed removed and zstd present always? The uncompressed take more space <ekaitz>sneek: later tell efraim: I just asked guix to build gcc-boot0 in the riscv machine. We'll see what it does <cbaines>Rutherther, for already compressed outputs, they aren't compressed (although maybe they're not ignored for the zstd cached compressions) <cbaines>storing a nar multiple times with different compressions takes more space than just having it once though <the_tubular>Hello #guix, could someone help me debug this error : Installing for x86_64-efi platform. - Could not prepare Boot variable: No space left on device 