IRC channel logs


back to list of logs

<nckx>jackhill: Long story, or so it felt at the time, disappointing answer. When I pushed that patch I thought it had something to do with the tzdata package in Guix, or glibc, or something, because it was broken both in the build environment (even with tzdata-for-tests) and my desktop. Oddly, the PST8DST time zone worked fine, as does my Europe/Brussels. However, I since discovered that my /etc/environment wasn't being sourced, and hence TZDIR wasn't set. I need to
<nckx>try adding it to the package (together with tzdata) and see if that fixes it.
<jackhill>nckx: ah. I'm in America/New_York, so I guess I'm safe. Can't say I enjoyed the time I spent at the airport in Las Angeles anyways :þ
<nckx>Some say it's the best part.
<nckx>jackhill: I actually went as far as to ask someone using Guix System in LA about their time zone setting… sigh.
<nckx>I still don't pretend to grok why PST8DST works — some kind of minimal database? — but I'm guessing that setting TZDIR will make it moot.
<anadon>nckx: Thanks!  I messed up the send-mail command last night.  I had spend hours trying  to get postfix to work with the new gmail requirements.
<nckx>How did they choose to better serve their users this week.
<anadon>"Less Secure Applications" were disabled, requiring a new security scheme SASL to be required which was hardly and poorly documented.  Google's own documentation was worse than useless in that it tried to force you to use a heavy-wight google workspace fronting your entire enterprise infrastructure.  Eventually house a serverfault question that
<anadon>was new enough to cover the correct configuration.
<nckx>I see. Thanks.
<nckx>Sure: setting up and maintaining your account is more work that self-hosting a mail server, but you do get the prestige of an address.
<anadon>nckx: Here's the important webpage to keep in your pocket:
<nckx>Thanks, I am but a lowly self-hoster myself. I might seriously have to adjust my image of @gmail users: from average e-mail user to elite SASL enjoyer.
<nckx>‘You set up git-send-email with Gmail? Hired!’
<nckx>‘Now do mine.’
***duds-_ is now known as duds-
<anadon>Hey, it is just what I've found practical for my setup.  It is by no means sacred.  Much less '''good'''.
<nalaginrut>alright, guile-3.0.8 has a critical bug to run artanis...
<nalaginrut>but it's too hard to construct the test case
<zamfofex>civodul: I’m not sure whether you saw the reply I sent regarding <> This time I made sure to add the debbugs email to the reply list, but my reply still hasn’t showed on in that thread (maybe I did something stupid).
<zamfofex>Actually, I added the debbugs email to the “Reply To” field, rather than “Cc”. Could that have been it?
<nckx>zamfofex: ‘Reply-To’ means ‘this is my other address, please send replies there’.
<nckx>It does not mean ‘I am replying to…’.
<nckx>Or do I misunderstand?
<zamfofex>Ah, huh. I suppose that explains it, then!
<zamfofex>I’m not particularly familiar with email conventions.
<nckx>You want CC.
<zamfofex>Ought I to resend the email, then?
<nckx>If you want it to appear on the tracker.
<nckx>*, yes.
<nckx>civodul will receive another copy but he'll live. :)
<nckx>zamfofex: If your MUA has a ‘reply all’ feature, use that, it will do the right thing.
<zamfofex>I understand!
<nckx>Well, it should.
<nckx>I'll hedge my bets. I'm sure there's zany software out there.
<zamfofex>I see. Well, I remember clicking that. Though it had this drag and drop thing that I used to rearrange the addresses. I thought “Reply To” meant that I was replying to that thread, so I dragged the debbugs email there.
<nckx>Anyway, mystery solved.
<zamfofex>Thank you!
<nckx>Thanks for the patch :)
<KarlJoad>What is the Guix way to describe a Nix Overlay? I want my Emacs to
<KarlJoad> also understand where gcc-toolchain and linux-libre-headers are for
<KarlJoad> itself, without installing to the shell-available profile.
<zamfofex>KarlJoad: Do you mean propagated outputs or something else? When you say “my Emacs”, do you mean you are packaging a custom Emacs, or do you just want for Emacs to be able to find GCC and the Linux headers? I don’t understand what’s the problem with just installing the appropriate packages too alongside Emacs. (Sorry if I’m missing the point.)
<KarlJoad>zamfofex: I want Emacs to pick up a GCC & linux-libre-headers path, but do not want those packages to be available from my home profile. Only Emacs should directly refer to those 2 packages.
<KarlJoad>So I can upgrade Emacs & the GCC/headers used by my home profile separately from each other.
<KarlJoad>I can package a custom Emacs, that's fine. I just want Emacs to pick up its own unique set of GCC and headers.
<KarlJoad>I want to avoid the issues I had earlier when I was trying to compile emacsql-sqlite.
<zamfofex>KarlJoad: Ah, I understand. You could put the packages into their own profile, then use ‘PATH="$PATH:.../my-profile/bin" emacs’, perhaps with a shell alias or function. Conversely, you could use ‘guix shell’ before running Emacs. I think ‘guix shell’ can accept a manifest file, but I’m unsure.
<KarlJoad>guix shell can accept a manifest. I am using that feature right now for a project. It's more that I want to make a "new" Emacs that has its own package symbol that carries the necessary information with it to compile emacsql-sqlite on a new Guix system.
<zamfofex>I don’t think I fully understand. Are you trying to package ‘emacsql-sqlite’, or do you want to work on it from Emacs? because if the former, I think you could just specify both Emacs and GCC as build inputs, no? If the latter, I don’t understand what’s wrong with using ‘guix shell emacs gcc-toolchain ...’, for example. Or do you mean you are trying to build a system image with an Emacs package that propagates GCC?
<zamfofex>(GCC and the Linux headers, I mean. I was running out of space in that message!)
<KarlJoad>So, emacsql-sqlite can only be built at runtime with the way I want it to be done. But, I don't want to specify Emacs in my config and have GCC added to the profile's PATH.
<KarlJoad>I do not need to package emacsql-sqlite. I want that to remain a job for my Emacs config to handle. I just want to expose the necessary tools to Emacs to build sqlite during runtime without adding GCC & headers to my home profile's PATH.
<zamfofex>I think the two choices you have are to either use ‘guix shell’ before starting Emacs or to use a different profile with ‘PATH="$PATH:..." emacs’ like I had suggested. You mentioned Nix had a solution for it, I think — what does it do?
<KarlJoad>With Nix overlays, you can redefine & extend already defined packages. For example, I have a Nix overlay to force any instance of emacs in my system configuration to refer to my Emacs which has the withXwidgets configure-time flag set to true.
<zamfofex>KarlJoad: Do you mean something like this? <> Of course, you can also use ‘(inherit ...)’ from Scheme to get more power than the command line options give you. You won’t have substitutes then, though, if you don’t mind that.
<zamfofex>KarlJoad: Though note that this won’t “put GCC on the PATH” or anything like that. Rather, it would make the Emacs package refer to GCC from the store. So if you e.g, have a shell in Emacs, you will likely not be able to just run ‘gcc’ directly.
<KarlJoad>I mean, for Emacs, no substitutes is fine. It's not a hard program to compile on modern hardware. I think an inherit is what I want.
<KarlJoad>But that is exactly what I want. I want Emacs itself to be able to refer to its GCC directly, but for anything else to not see that GCC. (Unless it gets shared by a separate profile, obviously.)
<zamfofex>This might be what you want.
<zamfofex>Though I meant more so that this will only really have an effect if the Emacs package itself refers to GCC during its build. If Emacs tries to e.g. invoke GCC as ‘gcc’ from the PATH at runtime, this won’t help.
<apteryx>neat, it looks like I'll be able to migrate (gnu build jami-service) to use the AC/D-Bus Guile library instead of some ad-hoc dbus-send parser
<zamfofex>KarlJoad: I think this is meant to work transparently for shared libraries, but usually if you want for the GCC invocation to to refer to the input rather than to the one in the PATH during runtime, you’d have to apply a patch or use a snippet.
<zamfofex>It works well for shared libraries, I think, because there is a phase that replaces dependencies in the ELF files with their paths from the store (from the input list).
<KarlJoad>Yeah. And since Emacs does not directly refer to GCC by an ELF file, such a replacement would do nothing.
<zamfofex>Indeed. If there is e.g. a plain string literal in the source containing the contents ‘"gcc"’, Guix has no way to know that it is meant to refer to GCC from the input list, even if it is in a call to ‘exec*’ for example. So you’d have to find that reference in the source write a snippet to replace it with the GCC from the input list if you’d like.
<zamfofex>“*and* write a snippet to replace it …” I mean
<zamfofex>On other news, I’m trying to use ‘guix system image’, and I’ve realized that it doesn’t work well if I specify e.g. ‘--image-size=64G’. It slows down my entire system, and takes way longer than it should. I suspect it’s somehow trying to allocate 64 GiB of RAM, which is very unideal. Is that the expected way to create a system image with that partition size?
<nckx>I'd file a bug, zamfofex. That sounds wrong. Your use of ‘guix system image’ isn't.
*nckx → 😴💤
<voroskoi>I use (patches (list "path/to/patch")) to append patches, but it gives a warning on relative path
<voroskoi>how do I make that absolute?
<voroskoi>I try to do this in my private channel
<rekado_>I think Guix would be a good fit for this conference:
<lilyp>voroskoi: if you're doing local development, you can ignore this patch
<lilyp>if it still appears if you `guix pull' your channel (and are not currently working on it), that's a problem
<bovid-19>hello guix!
<voroskoi>lilyp: ok, thanks
<voroskoi>yeah, I've figured that out :-)
<jpoiret>nalaginrut: wdym but critical bug?
<jpoiret>sneek, last seen maximed
<jpoiret>sneek last seen maximed
<maximed>sneek: last seen jpoiret
<jpoiret>maybe sneek is down?
<jpoiret>what a coincidence though
<jpoiret>or do you have some alerts configured when someone pings you on irc offline?
<maximed>jpoiret: I sometimes look at
<maximed>nothing automated though
<jpoiret>in any case, thanks for the review for the open-bidir patches, though your comment on fprintf/dprintf made me look more closely at the manpages and i realized none of these functions should be called after fork anyways
<jpoiret>so i've got ... *even more* patches!
<jpoiret>i'll just send them all to guile-devel at this point
<jpoiret>hopefully, piped-process will be fully MT-safe with those
<maximed>jpoiret: if things fail between 'fork' and 'exec', where does the error message go?
<jpoiret>to a pipe to the parent process!
<jpoiret>which will be able to properly raise the exception, which is better than what we have no
<jpoiret>now *
<maximed>jpoiret: sounds complicated but nice
<maximed>is this pipe closed before/during/after the exec?
<jpoiret>it's just a couple of repetititive lines, nothing wild
<maximed>such that it doesn't leak into the child process
<jpoiret>yeah, it's marked as CLOEXEC so that on successful exec nothing is read
<jpoiret>it's not atomic though, so theoretically another thread that forks in between the pipe + fcntl could steal the fd without CLOEXEC and block it, but it's their responsibility to release the fds they don't need imo
<jpoiret>we already do that (release the fds) in piped-process, so it won't happen if all we use is that
<maximed>jpoiret: Is there some option for _not_ releasing some of the fds? E.g. for a make jobserver
***PrinceMyshkin3 is now known as PrinceMyshkin
<jpoiret>no, though that behavior was already present
<maximed>jpoiret: It's possible to create a pipe that directly is O_CLOEXEC
<jpoiret>on Linux, but that's not POSIX
<jpoiret>although i've read somewhere that it is slated for inclusion in whatever new posix version should come out
<maximed>WDYT of race-free pipe2(...,O_CLOEXEC) on Linux an technically racy pipe(...) elsewhere?
<jpoiret>hmmm, right, i had thought of that but didn't end up doing it. Maybe I'm too scared of #ifdefs :p, let me try
<maximed>(though technically there are still races if move->fdes is used)
<jpoiret>yeah, or if another thread forks but never execs
<jpoiret>you know, for fun
<jpoiret>multi threaded semantics really are terrible
<maximed>jpoiret: Maybe look at AC_CHECK_FUNCS in
<maximed>instead of #ifdef its linux
<jpoiret>it'd be great if we could avoid primitive-fork in all of guix's codebase
<jpoiret>or at least have some good cleanup primitive we could use to _actually_ isolate the child process and not let it hold resources
<jpoiret>also, i've heard that fork is quite costly, i don't know if this affects us
<unmatched-paren>hmm. looking at this <> and `find`ing in tzdata's output dir, I notice that we don't have leap-seconds.list installed in our tzdata package (though we do have a file called `leapseconds`, which might be the same thing...?)
<unmatched-paren>oh, nvm
<unmatched-paren>it is the same thing
***jesopo is now known as jess
***taiju is now known as Guest1099
***taiju` is now known as taiju
<jpoiret>maximed: if you want to have a look, I just sent the 4 patches to
<char[m]>Is there a reason that I have to install additional packages (gcc, binutils, glibc, others?) For ghc to work properly? Why aren't they just in the inputs?
<jpoiret>char[m]: how are you using it? installed in your profile?
<unmatched-paren>char[m]: i guess it calls them?
<rekado>(install gcc-toolchain instead of all the individual packages; but the question remains)
<unmatched-paren>to perform linking etc
<jpoiret>it'd seem weird to me that it doesn't work directly
<char[m]>Yes i just did a guix install.
<unmatched-paren>there should probably be a ghc-toolchain package that propagates them all
<unmatched-paren>because there's gcc-toolchain, gdc-toolchain, gfortran-toolchain
<unmatched-paren>the *-toolchain packages install their respective compilers along with binutils et al.
<jpoiret>let's see if i can write an hello world in haskell from memory
<char[m]>I dont see a ghc-toolchain
<jpoiret>there isn't
<jpoiret>btw, the -toolchain packages are mostly to choose the glibc for the compilers iirc
<unmatched-paren>char[m]: i know, i was proposing that there should be one
<char[m]>Installing the libs i mentioned makes ghc work, but the resulting binary still cant find or even though i installed those too.
<unmatched-paren>char[m]: ok, THAT shouldn't be happening
<unmatched-paren>the binary GHC produces?
<unmatched-paren>or the GHC binary itself?
<char[m]>No, the binary of my haskell program that ghc made gcc make
<unmatched-paren>try `guix shell libffi gmp -- [your compilation command here]` maybe?
<char[m]>unmatched-paren: what is the reason for having -toolchain packages? Why not just propogate the needed inputs in the compiler package? They won't function properly without those inputs anyway
<unmatched-paren>it probably won't work, just trying things
<jpoiret>char[m]: the non -toolchain packages are hidden, ie not installable from commandline
<jpoiret>(and gcc redirects to gcc-toolchain even)
<unmatched-paren>char[m]: no idea. it's just the way things are done for some reason
<unmatched-paren>there probably _is_ a good reason tho
<unmatched-paren>i just don't know it
<jpoiret> ;; The main raison d'être of this "meta-package" is (1) to conveniently
<jpoiret> ;; install everything that we need, and (2) to make sure ld-wrapper comes
<jpoiret> ;; before Binutils' ld in the user's profile.
<jpoiret>otherwise, you know, gcc and ld are different programs
<jpoiret>gcc-toolchain is basically gcc + ld + binutils + glibc
<unmatched-paren>ghc-toolchain should be ghc + gcc + ld + binutils + glibc + libffi + gmp
<jpoiret>char[m]: an hello world compiled an ran fine with `guix shell ghc gcc-toolchain gmp libffi`
<char[m]>That should be it. Im not sure if ghc needs other .so depending on features or libraries used in the haskell code.
<char[m]>also just installing libffi and gmp didn't work because they still couldnt be found by the compiled haskell program
<char[m]>Ill try again with gcc-toolchain
<unmatched-paren>char[m]: do you have other C libraries installed?
<unmatched-paren>because it's possible the reason ghc wasn't finding them was because the C library search path hadn't been reloaded...?
<unmatched-paren>i think guix shell reloads search paths for you
<jpoiret>you need gcc-toolchain installed for libs to get picked up
<jpoiret>since LIBRARY_PATH is a search path of gcc iirc
<jpoiret>at least gcc-toolchai
<unmatched-paren>jpoiret: that makes sense. so it was the search paths.
<unmatched-paren>char[m]: if you install gcc-toolchain and do `bash --login` it should work
<unmatched-paren>and/or log out and back in
<jpoiret>just use shells for dev purposes
<jpoiret>don't globally install non-user programs ... is my opinion anyway
<unmatched-paren>and write manifests for your programs
<unmatched-paren>*your projects
<unmatched-paren>so (specifications->manifest (list "gcc-toolchain@12" "ghc@whatever" "gmp@whatever" ...))
<unmatched-paren>There should still be a ghc-toolchain imo.
<unmatched-paren>char[m]: why not send a patch to add one? :)
<char[m]>Okay, doing a guix shell like char: `guix shell --pure ghc gcc-toolchain gmp libffi` worked. Im not sure why it didnt work before because i was sourcing ~/.guix-profile/etx/profile every time i installed something
<char[m]>Once I have ghc-toolchain, it should just be guix shell ghc-toolchain right? And you said it should propogate the packages?unmatched-paren. Do I need to make one for every veraion of ghc?
<unmatched-paren>char[m]: (1) yes (2) yes (3) yes, but you should be able to write a `(make-ghc-toolchain GHC-PACKAGE)` procedure quite easily, I'd think...?
<unmatched-paren>you should be able to find a make-gcc-toolchain in gnu/packages/gcc.scm i think
<char[m]>I should be capable of that.
<unmatched-paren>yeah, the (make-gcc-toolchain gcc #:optional (libc #f)) procedure is pretty trivial (turns out it's actually in gnu/packages/commencement.scm apparently)
<yewscion>Hi Guix, shot in the dark  here: I've just purchased a Librem 14 from Purism, and I am experencing instant shutoffs immediately upon invoking any cpu-intensive operation while on battery (such as `guix pull` for instance). Purism has put out a workaround here: but it doesn't
<yewscion>seem to do anything on Guix. The basic fix is modifying values that live in `/sys/devices/virtual/powercap/` and want to confirm whether Guix might not honor these values (and work out a real solution, so I can use my laptop on battery).
<jpoiret>anything in /sys should be honored since you're directly talking to the kernel
<yewscion>jpoiret: Ah, alright. Thanks for the confirmation. Maybe I'm doing something wrong, then.
<jpoiret>you should be able to see if the changes you make are taken into account by cat`ing the relevant file
***taiju_ is now known as taiju
<oriansj>yewscion: the link you shared indicates there is a max wattage one can draw from the battery before brownout voltage occurs. So what the change is doing is lowering the max wattage draw for the CPU
<oriansj> n n
<oriansj> *sorry toddler attack*
<yewscion>oriansj: I see, that makes sense. Hopefully it will work this time, I have reapplied the fix as listed and confirmed the changes as jpoiret suggested.
<Kalq[m]>Hi all, regarding is there a reason there are 2 gtk+ as inputs?
<lilyp>Kalq[m]: good catch
<unmatched-paren>is it possible to tune a package _object_ without the command line? I want to tune some packages in my home.scm
<lilyp>all transformations plus some more can be coded in scheme
<lilyp>see (guix transformations) for the innards
<unmatched-paren>aha, (tuned-package pkg micro-architecture)
<unmatched-paren>hmm, (transform-package-tuning)'s docstring is just "Return a procedure that, when " i suppose that's a mistake
<unmatched-paren>lilyp: so would i do (tuned-package pkg (current-cpu))?
<unmatched-paren>Yet another reason to dislike dynamic typing -- it makes it difficult to see what a function will actually accept :(
<unmatched-paren>or maybe (cpu-architecture (current-cpu))...
<maximed>unmatched-paren: See
<unmatched-paren>ok, going to see if supertuxkart will benefit from cpu tuning at all...
<unmatched-paren>probably not :P
<nckx>Good morning, Guix! (It's been a while since I said that...)
<acrow>Glad to be back with guix.
<nckx>Perfect response by acrow.
<nckx>unmatched-paren: I guess you don't read PMs? That is probably for the best.
<nckx>I shall make note of it.
<acrow>Thank you nckx.
<jpoiret>reminder that arun isaac's guix-forge presentation is in less than 10 minutes
<unmatched-paren>it's probably the placebo effect, but supertuxkart does seem a bit faster now
<nckx>jpoiret: That's why I'm here!
<jpoiret>for once i wrote it down in my calendar with a notification
<nckx>I can't unmute my mic without hearing the sound of a thousand cats dying, but am looking forward to the presentation.
<whereiseveryone>Hi guixers, we'll be starting the guix-forge presentation with Arun Isaac. Feel free to join us:
<jpoiret>PurpleSym: alright, went back to the grub patches
<jpoiret>unfortunately, they're not really backportable to 2.06, at least for me
<jpoiret>so i guess we'll have to wait for the next version
<PurpleSym>jpoiret: Bummer. Did you check if we can force the inclusion of all modules required? I can also see if I can come up with something on Monday.
<PurpleSym>Could you also point me to the patches by any chance?
<nckx>It's a miracly my connection fared as well as it did, but my luck finally ran out. No WebRTC for me. Could you convey my regards to Arun, jgart[m]? Looking forward to the next presentation I can attend.
<nckx>whereiseveryone: Or you :)
<nckx>Corporate sockpuppet accounts, oh dear.
<vivien>TIL that you can write a implies b in scheme as (if a b)
<vivien>(as a boolean)
<vivien>(if (if a b) "Implication OK!" "Implication not OK :(")
<vivien>But (if (if a b) ...) does not seem very readable
<f1refly>what is the best way to tell my laptop to disable bluetooth with rfkill on boot?
<kiranshila>Hey everyone! Is anyone familiar with SHM_LOCK stuff? I'm working on packaging a radio astronomy data management suite ( and am getting "Cannot allocate memory". The same build on a foreign distro seems to work fine
<vivien>kiranshila, you need to tell us more. You present the issue as if something identified by SHM_LOCK is part of the problem, but it doesn’t appear in the error message.
<emacsomancer[m]>packaging question: I'm trying to build 'zutty' in Guix (build file: ), but though I include `libxmu` in both `inputs` and `native-inputs`, I get a build error (see: ) which seems to indicate that it's not finding `xmu`.
<kiranshila>The full error from the application was `ipcbuf_lock: shmctl (shmid, SHM_LOCK): Cannot allocate memory`
<kiranshila>I'm pretty unfamiliar with the whole shared memory architecture - but I wasn't sure if there was something special about guix SD'
<unmatched-paren>it's possible that the guix sandbox disables shm, but i know nothing about either
<unmatched-paren>seems a bit unlikely tho
<unmatched-paren>(btw, it's not GuixSD anymore, it's just Guix and/or Guix System)
<unmatched-paren>it apparently hasn't been called GuixSD for some years
<kiranshila>This software lets me allocate "keyed blocks" and when I try to request a 4096 block, it works fine. Anything bigger than that fails. I'm not sure where that limit is coming from.
<guixsdbot>unmatched-paren: That is correct!
<nckx>kiranshila: Just a guess, but prlimit's --memlock option is apparently relevant here.
<nckx>According to setrlimit(2).
<kiranshila>Oh yeah, that's certainly different on my arch box
<kiranshila>I have the pam limits entry for memlock set to unlimited, at least I think I do
<kiranshila>Well, I guess it would say "unlimited" if that were truee
<nckx>If it is the culprit (it's not clear from your answer if it is, isn't, or you don't know yet, and I have to leave), there's a pam-limits-service in Guix. See the manual's ‘Base Services’ section.
<nckx>Good luck!
<kiranshila>Yeah that very well might be the culprit. I have that `pam-limits-service` entry in my config, but I may have misconfigured it
<kiranshila>Yeah /etc/security/limits.conf is certainly set correctly - it's just not actually applying? This was after a reboot
<maximed>if that's the culprit, I think the guix daemon should set the limit for the build processes (if that's possible per-process), to eliminate this build irreproducibility variable
<nckx>It feels like plugging infinite holes, though. Not that we shouldn't; it's just Sisyphean.
<mohammed>hi, I am planning to move to guix linux, and I want ask you about installing packages there because it is risk if delete my currentOS without know about supported package.
<mohammed>I have Intel-Wireless AC 9260 and this is not free. can I install the frimware there?
<unmatched-paren>mohammed: there _is_ a way, but you can also just use a wifi dongle or card with the ath9k chipset
<mohammed>Thanks unmatched-paren, but I didn't use it before
<mohammed>is it coming with installation ?
<nckx>Uugh. CUPS update is a 112531 diff and it's 80% pointless treewide style changes.
<nckx>That's our job!
*nckx continues auditing C comments…
<nckx>* -line
<singpolyma>It's in guixrus if you want to try it
<nckx>I'm using diffoscope. Does difftastic work in text mode?
<singpolyma>It has both side by side and inline display modes also
<nckx>I'll try it out. Thanks.
<zamfofex>mohammed: If you’re unsure about whether the installation will work and you only have one computer, you can always just have another OS (e.g. Debian) on a different installation medium and use it in case the Guix system installation doesn’t work.
<zamfofex>I have Guix with the Hurd on a QEMU VM, and it seems to be failing to build and install packages while building Guile 3.0.7, presumably during bootstrapping. Has anyone experienced something like this?