<mbakke>NieDzejkob: it hasn't been discussed AFAIK, but I suppose august-september-ish :-) <mbakke>do you think you'll have time for a GCC bump? I'm happy to help with it. <NieDzejkob>meanwhile rustc@1.44 finished building. It's the third version in a row that didn't need any changes in the package definition. <NieDzejkob>oh, just saw your message about GCC. I'm somewhat swamped through June, but I hope to find a lot of guix time in July and August ;) <NieDzejkob>though a gcc bump is mostly waiting for builds anyway, so it's easily multithreaded :P <mbakke>ooh, great that you keep rustc rolling :-) <mbakke>rumor has it that mrustc can soon build 1.39, I would really like to cut down on that bootstrap chain... <vagrantc>oh no ... i suspect the new grub configuration things borked extlinux configuration <NieDzejkob>weren't we still stuck when trying to bump to 1.29 or something? <mbakke>NieDzejkob: because of a silly linker flag ordering issue that can be easily worked around :P <NieDzejkob>oh. Let's hope for a mrustc->1.39 bootstrap chain by next staging, then :D *vagrantcish digs out the configuration failure <vagrantc>which was pretty much the same issue i had with generating the extlinux.conf too <vagrantc>Unbound variable: boot-parameters-kernel-arguments <vagrantc>maybe someone can confirm? i gotta run... <guix-vits>mbakke, janneke: `ls /gnu/store/*linux-libre*/.config`. Not only in gnu/packages/aux-files/linux-libre/, but also there the k-configs are... Just those are dot-files. Probably i need to alias ls, adding -a by default. <xelxebar_>Our bison is old, at 3.5.3. I tried bumping to the laste (3.6.3), and holy bajeezus, `guix refresh -l bison' wants to update 3713 dependents... <apteryx>xelxebar: did you check which bison version is used on the core-updates branch? That's the place such update would need to happen. <apteryx>sneek later tell xelxebar did you check which bison version is used on the core-updates branch? That's the place such update would need to happen. <sneek>Welcome back xelxebar, you have 1 message! <sneek>xelxebar, apteryx says: did you check which bison version is used on the core-updates branch? That's the place such update would need to happen. <apteryx>ah, sorry, I mistakenly thought you were offline :-) <xelxebar>No worries. What would be the correct place for a graft? <apteryx>What do you mean by 'the correct place' ? <xelxebar>Or better yet, how does one decide that a graft is a good idea? <nckx>Grafts don't affect builds though. <apteryx>usually if it's a security vulnerability (time sensitive) or if it's a bug big enough that it needs to be fixed ASAP on the master branch <apteryx>(that would entail a massive amount of rebuilding otherwise) <nckx>It just doesn't make much sense for a package like bison. <xelxebar>I see. So grafts are for times when "we need to get this to users quick and before we have time to rebuild the world" <nckx>But packages that depend on a grafted package are built against the *old* package, not the graft. <nckx>Everything would still be built with bison@3.5. <nckx>xelxebar: Is there a particular reason you want 3.6? <xelxebar>Yeah, that's something that somewhat confused me. I mean, in priciple at least, a security issue in perl could propogate problems in the built outputs of something, no? <xelxebar>nckx: Yeah, I wanted to check out gnu poke, but it requires bison 3.6+ to work <nckx>Everything's possible in principle 😉 If a package statically links perl, for example, or if some references to /gnu/store/old-perl are ‘obfuscated’ in some way so the grafter can't find & rewrite them. <nckx>xelxebar: For that case you can simply create a bison-3.6 package and use ("bison" ,bison-3.6) in your poke package. <nckx>Switch to ,bison when it's updated to 3.6 next core-updates. <royball>hello guix. i am also getting that same grub.cfg error (for both guix system vm and guix system reconfigure) <royball>looks like there are a couple minor tweaks to get it working again. <royball>i can submit patches for the tweaks that worked for me, if y'all don't mind goofy commit-messages. <nckx>…grub.cfg error? Oh dear. I'm currently reconfiguring my system. Is there a pleasant surprise waiting for me at the end? *Kozo Holds off on updating Kernel <royball>if you did a guix pull today, probs. *nckx early night tonight → 😴 <royball>41770 and 41769 submitted to try and address it. <royball>also, thank y'all for creating/maintaining/extending this project! <xelxebar>nckx: That... is an imminently simply solution. Thanks. <xelxebar>By "switch to ,bison" does that mean I should submit a bison update patch for core-updates? <xelxebar>And then submit a fixup patch to poke switching from ("bison" ,bison-3.6) to ("bison" ,bison) after core-updates merges? <anadon>Can I bug someone to head over to #guile to help me out? <apteryx>NieDzejkob: the missing gdb option was 'set follow-fork-mode child' :-) <bdju>grub failed to build doing a system upgrade! <dftxbs3e>efraim, hey, you can't make a little endian chroot on the machine because the kernel is big endian, you'd need a VM for that <dftxbs3e>efraim, I enabled nested virtualization on the host etc. so it should be possible to start one inside the VM <bdju>ah, no error with grub this time, so guess all is well now. <dftxbs3e>efraim, I'll have to go to work now but I'm compiling grub with emerge (Gentoo's) now <dftxbs3e>efraim, I think I'll have to reboot the guest ***wxie1 is now known as wxie
<dftxbs3e>efraim, I'll recompile the kernel with 64K page size <dftxbs3e>nested virtualization was enabled on the host but not on that particular guest so now it is, but now the fact that the guest kernel has 4K pages instead of 64K makes it somewhat troublesome <efraim>I have a screen session open but nothing happening inside <dftxbs3e>I rebooted the VM so probably that session was shut down <efraim>I'm actually on my phone now, we're expecting a power outage today <dftxbs3e>trying to fix this before work so you can do whatever you like later <dftxbs3e>sneek later tell marusich what are your findings for now with reproducibility? any hints? share your progress and I'll help since that's a condition for merge <dftxbs3e>sneek later tell marusich what are your findings for now with reproducibility? any hints? share your progress and I'll help since that's a condition for merge <dftxbs3e>efraim, started recompiling the kernel, should take 5 minutes or so <dftxbs3e>efraim, I'll run to work, once there I'll switch the kernel over the the new one and reboot the VM - so then you can run qemu - # qemu-system-ppc64 -enable-kvm <dftxbs3e>and then you can figure out the rest of the options <dftxbs3e>to explicitly enable little endian mode etc. <dftxbs3e>you should be able to enable serial mode so it gives you a regular console <dftxbs3e>you should be able to boot an Ubuntu or Fedora ISO <dftxbs3e>as convenience, you could install libvirt and virt-manager and run that with -X or -Y over SSH for X11 Forwarding, it should work <dftxbs3e>it'll save you from learning all that fuss about qemu options and manage storage in a nicer way <dftxbs3e>by the way you can most certainly use GNU Guix to install all of that, just make sure to make host services for GNU Guix things <dftxbs3e>I made a small service for GNU Guix's daemon in /etc/init.d/guix <dftxbs3e>efraim, in /root - run : qemu-system-ppc64 -nographic -enable-kvm -machine cap-ccf-assist=off -cdrom Fedora-Server-netinst-ppc64le-32-1.6.iso <dftxbs3e>(yes I'm still not gone because kernel recompilation succeeded before I was gone :-() <efraim>I was going to use a debian iso and try with -curses (I think) <dftxbs3e>use this instead : qemu-system-ppc64 -nographic -enable-kvm -machine cap-ccf-assist=off -cdrom Fedora-Server-netinst-ppc64le-32-1.6.iso -hda fedora-ppc64le-1.qcow2 <efraim>I have to say though, it was much faster building 32-bit ppc binaries on your machine than on my G4 <dftxbs3e>well you get the idea anyway, I downloaded a Fedora Cloud image which is qcow2 already and it gets to the GNU/Linux login phase, but I couldnt find the default password aha <dftxbs3e>qemu-system-ppc64 -hda alpine_disk.img -enable-kvm -m 8G -smp 16,sockets=16,cores=1,threads=1 -nodefaults -nographic -serial stdio -cdrom alpine-standard-3.12.0-ppc64le.iso -machine cap-ccf-assist=off <dftxbs3e>I'm going to work! I'll let you figure this out! Thanks a lot for giving interest to PowerPC :p <efraim>on a lark I tried using qemu-ppc64 on Debian and syncthing pre-built for ppc64 on my ppc32 machine, that's a serious no-go <efraim>I think just on the single quotes <raghavgururajan>efraim: Hmm, I got In procedure make-regexp: Invalid content of \{\} <efraim>you need to escape it twice, once for guile and once for the regex, so \\{\\} <xelxebar>Ugh. I have a package who's ./configure generates a script, so that script's schebang is wrong... <xelxebar>Hey civodul and bricewge1 ;) Welcome back into the munge. <jake29>is that done with guile, mcron, or some other program? <thorwil>hi! how do i force locally building a package that i just got as binary substitute? as none --check, --no-grafts, --no-substitutes does the trick ***cjpb0 is now known as cjpbirkbeck
<civodul>thorwil: in general something already in the store doesn't get rebuilt/redownloaded <thorwil>even after ‘guix package -r clementine’, i get: ‘guix gc: error: cannot delete path `/gnu/store/yhnf5mf4bgxd4bb931xmwky637gbwxnp-clementine-1.3.1-2.4619a4c' since it is still alive’ <thorwil>civodul: hi! i should provide the motivation: i had a build error with clementine, there’s an open ticket. can’t be reproduced. todays ‘guix pull && guix package -u’ got me the substitute. <janneke>nckx: you and royball found/fixed my grub.cfg typos? so sorry! <thorwil>so i would have liked to trigger a local build with the least amount of fuzz. ideally without removing the package and a garbage collection run that will get rid of much of the build machinery, again ... *janneke didn't see the actual conversation about that, only something here and the patches on master <civodul>thorwil: you can try "guix build clementine --no-grafts --check" to rebuild locally <civodul>janneke: i think it wasn't in our timezone <janneke>civodul: the worst part is that i found and fixed these typos this weekend ... and apparently i lost them <janneke>juggling branches and updates...wip-hurd-vm / wip-hurd-vm-new or so <thorwil>civodul: thanks, it’s busy now :) doesn’t --no-grafts apply to build dependencies, too? <janneke>on a more positive note, "guix build hello" now progresses until coreutils-final with wip-hurd-vm <janneke>the check phase takes more time than i have patience for <janneke>coreutils make check...everything up to that also took ~6h <janneke>oh, the native hurd's disk usage until coreutils-final <janneke>directions for the rest of the guix herd ;-) <thorwil>lovely. building clementine succeeded this time, but check found out it may not be deterministic <civodul>you can paste the output of "guix challenge clementine" in the bug report <mothacehe>hey guix! Is there an alternative to '@@' to use a non-public variable? <raghavgururajan>Will `(substitute* "foo" (((string-append "line1" "//n" "line2" "//n" "line3")) ""))` work? <thorwil>civodul: ‘guix challenge clementine’ found it to be identical! <civodul>thorwil: oh right, because it's just looking at the substitute you downloaded <civodul>i'm seeing /gnu/store/sa56z96rixkghpf3z1rv0sqc41rfix4d-gcc-cross-sans-libc-x86_64-linux-7.5.0.drv when running "guix system disk-image --target=i586-pc-gnu" <thorwil>civodul: is this enough for a report? ‘guix build: error: derivation `/gnu/store/003z966hxvb6hs17sjq4fcwshcqvafxa-clementine-1.3.1-2.4619a4c.drv' may not be deterministic: output `/gnu/store/2vpsjrx7q7wx9715cpc2y1vg5xy7hbfw-clementine-1.3.1-2.4619a4c' differs’ <civodul>"guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl" also wants to build a "-x86_64-linux" cross-toolchain <civodul>looks like a system type is used as a cross-compilation target somewhere <janneke>civodul: ah...i'm still trying to grasp what's going on <janneke>we do build a gcc-cross during the bootstrap; i was looking how i can see this isn't that one <janneke>there's the -gnu bit missing and that's how you immediately spot it's fishy, i guess <civodul>doesn't happen with --no-grafts, ah ha! *janneke does not have any _64 thing end up in the VM <janneke>i seem to remember "someone" wrote an insightful blog post about them grafts, maybe we can ask them? <civodul>but i can feel the presence of dynamic binding <raghavgururajan>Hmm, how to make substitute*, to use all files with .xml extention, in a given directory? <janneke>civodul: this kind of stuff is scary, right: (target #$(let-system (system target) (or target system))) <sneek>Welcome back guix-vits, you have 1 message! <sneek>guix-vits, nckx says: The Guix System equivalent of /proc/config.gz is /run/booted-system/kernel/.config . It always matches your running kernel. Unlike /proc, it doesn't require loading an otherwise useless module into kernel memory as root. *guix-vits Which is a great thing. <janneke>is that documented somewhere (eh, besides this channel's logs?) <NieDzejkob>I sometimes encounter libraries that need other libraries in the profile to use them during compilation (either because of headers or linking). Is it appropriate to move the dependencies into propagated-inputs? <leoprikler>i found that even if you do, you have to manually supply those inputs <guix-vits>janneke: if you about .config, then probably no (will be cool if someone with good English append this to the Cookbook). <NieDzejkob>I'm not familiar with the glib ecosystem, any specific examples? I observed that linking with igraph (statically? this is only triggered by rw 0.8) needs zlib, lapack and openblas, moving these to igraph's propagated-inputs makes it work <leoprikler>nvm, it appears those packages all propagate glib for the same reason <efraim>how can I quickly add something as a GC root? <mothacehe>efraim: I think by adding a symlink to /var/guix/gcroots/. <efraim>mothacehe: had to be inside the directory somewhere, that worked <mbakke>NieDzejkob: that does sound like a case for propagation <civodul>janneke: ah yes, (or target system) is likely to go wrong in some cases <janneke>that's nice and all, but janneke did get quite some help <civodul>now we have a solid base all of us can have fun with! <civodul>i'm really happy all this is in master <janneke>yeah! -- sure you've seen the 3/4 commits/patches to allow ssh access and cleanup hurd-boot <janneke>i'm wondering when to wake-up rekado on how to (/what's needed) to setup a VM *janneke means this in the friendliest possible of ways <mothacehe>civodul: saw your message! indeed seems like there's still something wrong <mothacehe>janneke: we could first make sure that the CI is cross-building hurd barebones, so that we have fresh substitutes <mothacehe>I'd like to define a set of images that the CI would rebuilt for each commit on master <mothacehe>we are already doing that for the installation ISO image <janneke>we are very close to having a setup where people can just join-in and contribute <janneke>...but (re-)building everything without substitutes is a bit harsh <mothacehe>yes for sure. Having the CI to build those wouldn't be hard, almost everything is ready. It's just that I would like to tie it to the image "catalog" concept (that is more blurry) <mothacehe>once done, I could help you setup a Hurd VM in the build machines farm if rekado is too busy <guix-vits>is `guix system vm` will work for Hurd now, or the "disk-image" is only option? <sneek>guix-vits, you have 1 message! <sneek>guix-vits, guix-vits says: test <janneke>mothacehe: that's great, i certainly don't want to pressure rekado, i just wish for him not to miss out on the guix herd fun <nckx>Morning all. Congratulations janneke. <janneke>morning nckx, thanks nckx (and thanks for helping with my grub.cfg goof) <nckx>janneke: What happened there? <janneke>i mixed up two trees and apparently pushed a commit with a typo, and one with an module-include omission <mbakke>I think the bad commits are still in the 'guix snapshot', so people who generate an installer from master will not be able to install the bootloader <civodul>janneke: re CI for GNU/Hurd, what about writing a Hurd-in-VM service? <janneke>mbakke: oops -- but i'm looking at master right now and it looks like i cannot build a hurd system anymore -- investigating <Bryophyllum>Hello Guix users. How do I configure a static DNS nameserver using dhclient? static-networking-service won't do because I need ipv6 in my network. <janneke>civodul: .. Hurd-in-VM service? /me ponders what that could/would look like <mbakke>Bryophyllum: unfortunately the network configuration facilities in guix are still somewhat rudimentary :/ <mbakke>Bryophyllum: if you feel like getting your feet wet with guix hacking, it should not be too difficult to extend dhclient-service-type to write a configuration file where you can specify additional DHCP servers <guix-vits>Bryophyllum: IDK. What about a firewall trick like that: "udp dport 53 redirect to :5353" (using some app that serve the DNS thingy)? <janneke>nothing to see here... "<janneke> mbakke: oops -- but i'm looking at master right now and it looks like i cannot build a hurd system anymore -- investigating" => make clean-go <mbakke>s/DHCP servers/DNS servers/ in my previous message :P <guix-vits>janneke: doing `guix system vm --target=i586-pc-gnu --no-grafts gnu/system/examples/bare-hurd.tmpl` on <guix 141b5c1> i got: "configure: error: this is the gnu os, host cannot be linux-gnu". What had i did wrong? <Bryophyllum>mbakke: Right. I've peaked at the source code, and it wouldn't be too hard to define an extra variable and append it to the fork+exec line. I have a lot of free time on my hands, so I might do that as well, but I must learn GNU Guile first <Bryophyllum>guix-vits: I was thinking of a simpler approach: overriding the resolv.conf after it's created by dhclient, but I couldn't make it work. <civodul>janneke: it'd be a Shepherd service that spawns qemu with the image as an argument, and the image would be the return value of system-disk-image or whatever it's called <mbakke>Bryophyllum: sounds great! Don't hesitate to ask here about anything, it's a pretty helpful and knowledgeable crowd :-) <janneke>guix-vits: you're not doing anything wrong, per se, but currently only "guix system build" and "guix system disk-image" are supported <janneke>civodul: ah...not for CI, but just for us mortals -- to always/easily have a Hurd VM ready <mbakke>janneke: we could launch that service on all the CI build nodes, and then we'd have a Herd of Hurds available for CI <guix-vits>janneke: cool. Through someone (:P civ*dul) omit "how to use" part in the post, so i going to "ook? ook!" the disk-image usages (Manual 8.16). <janneke>well, maybe someone can fix the post by adding a reply *nckx ooks onto the Hurd bandwagon. <Bryophyllum>mbakke: That's the spirit! ^^ I'm going to leap at a chance while we're still at it: would there be a reliable way to configure a simple-service to overwrite the resolv.conf file after it's created by dhclient? This seems hacky at best, but should do *for now*. <Bryophyllum>I'm thinking of something similar to systemd units, where it can be specified after which service my service should be executed. <guix-vits>dhclient_in_store=$(ls -lh `which dhclient`|awk '{print $11}') <civodul>mbakke: we already have qemu-binfmt on some of the nodes, so we could just as well have that hurd vm on a herd thereof <mbakke>Bryophyllum: you could try using (requirement '(dhcp-client-service-type)) for the simple-service, but it's prone to races where the resolv.conf has not yet been written, or later gets updated <mbakke>Bryophyllum: a cron job is probably a better fit for that particular use case, though suboptimal too of course <royball>hello guix. sorry for any confusion about the grub.cfg stuff. <royball>next time, i will open a bug report so it is properly documented. <royball>i think mbakke is right about having to bump the guix package in package-management so it contains the fixes. <royball>bumping the guix package to at least ea80cdbcea3763ded87d2fc3b5e97a427a6bb1d4 should contain all the fixes that were applied earlier. <janneke>royball: np, thanks for the prompt fixing in your timezone! <royball>thank you for all the work you put into getting hurd into guix! <guix-vits>janneke: can the $TERM in hurd-vm be set to 'xterm' out-of-the box? 'unknown' misbehaves. <janneke>guix-vits: good catch, thanks! isn't "xterm" weird for a console, what about "gnu"? *janneke is wondering where this "unknown" comes from <janneke>possibly we "just" miss some service/setting <guix-vits>janneke: cool, but seems that TERM=gnu doesn't work (C-a glitches)? <janneke>now, where should that setting come from, and does it need other configuration [files] <janneke>hmm, getty has asprintf (&arg, "TERM=%s", tt ? tt->ty_type : "unknown"); *guix-vits constantly forgets is C-like TRUE a value that more, or less than, or equal to 0. <janneke>yeah /etc/ttys is missing -- that's because last moment we switched away from a special hurd-etc-service to the generic one; and i missed this <janneke>mbakke,royball: updated the guix package after confirming it needed fixing <leoprikler>'tis a joke, because you can get arbitrarily close to 0 with floating points, but getting exact 0 is very, very hard if you're not hardcoding the value <leoprikler>(or do other trivial constructions like 1.0 - 1.0) <nckx>#define TRUE strcmp("0", "0.000"); <janneke>hmm...(string-append "argv[0] = \"" #f "/sbin/mdadm\"") <janneke>guix-vits: pushed a fix to master for TERM, thank you...however ^^^ <janneke>mothacehe: the recent grub theme update broke the hurd <janneke>it somehow ignores the "grub-minimal" specification and introduces a dependency on the default grub -- that doesn't work *guix-vits got `guix JIT-pull`, then. ***dingenskirchen1 is now known as dingenskirchen
<guix-vits>janneke: is that OK to get "connection refused" as root during `herd status` (in hurd)? <mothacehe>janneke: I think I found why, didn't see a typo :( <janneke>mothacehe: i'm still looking for it, and even then haven't found it yet <janneke>oh well, this just inspires us more to get CI going :) *guix-vits "i used to joke about missing paren... then i was shot to the knee" <efraim>janneke: don't forget to change the version of guix in the commit message when updating, you've bumped it to 1.1.0-1 a couple of times :) <mothacehe>janneke: hehe, that's what I was saying to myself, besides feeling dumb for not checking for cross-compilation <janneke>we're at 1.1.0-10; luckily only the commit message is lying <janneke>mothacehe: yes, it's the #$font-file <mothacehe>ok, I'll send a patch as soon as the build is over <janneke>mothacehe: great! to be fair, we've all been dancing around that grub.cfg bit there -- an honest mistake <mothacehe>janneke: civodul is proposing to remove all canonical-package references, that's much smarter than what I was up to. I'll see if it's possible. <janneke>i've counted 100 commits that mention 'hurd' since february, 200 if you include cross <janneke>some cross build fixes had nothing to do with the hurd, and some were a nice "coincidence" <tibbe_>Hi, after some time I wanted to start writing C++ code on my Guix machine again. But compiling almost any C++ program fails somewhere in the standard library headers. I am using the g++ from the gcc-toolchain package. Is this a known problem or am I doing something wrong? <civodul>tibbe_: there was a report recently but i don't know what's going on <tibbe_>civodul: Yep, I tried gcc 10, 9 and 8. "Hello, World" fails as soon as you include <iostream>. <civodul>"guix environment --ad-hoc gcc-toolchain -C -- g++ t.cpp" works for me <janneke>hmm, why do i get this object is not an exception of the right type #<&gexp-input-error input: #<procedure %image-size-procedure (s)>> #<record-type &package-input-error> <janneke>root@dundal ~# herd status hurd-in-vm ***test is now known as Guest14618
***benny_ is now known as benny
***benny is now known as Guest20992
***Guest20992 is now known as benny
<NieDzejkob>hmm. Looks like offloading over a slightly flaky network can give you the impression that a build got stuck <nckx>It can do anything. In my case, the slightest hint of flake aborts with an <#eof>. <nckx>NieDzejkob: Does the build still complete eventually? <NieDzejkob>nckx: not sure because the build I'm experimenting with also fails for a different reason <nojr>hello, in a foreign distro, guix's emacs has a link to a unexisting node in (info "(guix) Build Systems") <nojr>" thereof (*note configuration and makefile conventions: <nojr> (standards)Configuration.)." <nojr>Line 36, however, if I (add-to-list 'Info-default-directory-list "~/Documents/Info"), and then download the .info file and place it in the directory <nojr>it will work, but the `standards' manual won't appear on my Info menu when I `M-x C-h i` <nojr>** `M-x C-h i m standards` <nojr>another question, the Build Systems section in the manual describes the `arguments' option for the build system. It says it accepts keywords but the problem <nojr>it doesn't specify which keyword args it receives <nckx>Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) <janneke>mbakke, civodul needs some more work; but meanwhile i went from hard-coding the image file name to "Wrong type to apply: "/gnu/store/07ds9abpfsj30bp3aafkxjwwgxihrsad-disk-image"" <janneke>hoping to mail a draft patch some time soon <leoprikler>all of them, safe for trivial-build-system accept #:phases, for instance <nojr>leoprikler: thanks, another question, when setting up a dev environment it only needs `guix environment -l guix.scm`? I am using this on a repo online which provides `guix.scm` but when I try to reach for `./pre-inst-env` it says says No such file or directory <leoprikler>Assuming that you have a clean checkout of the code and the guix.scm is well-written, such a thing should not happen. <leoprikler>"pre-inst-env" is rarely part of a clean checkout, though, usually you'd have to ./configure first <nojr>leoprikler: thank you, I think in my case the provided guix.scm is a bit old, that may be it (12 months Guix has changed since then)