IRC channel logs


back to list of logs

<festerdam>When doing a system reconfigure, I'm getting (transcribed since its running in a vm and I don't share clipboard): «shepherd: Evaluating user epression (and (defined? (quote transient?)) (map (# ?) ?))» and then right afterward «guix system: warning: exception caught while executing 'eval' on service 'root': error: service: unbound variable». Rebooting leads me into a bournish repl. What could have
<festerdam>gone wrong?
<festerdam>Those two errors are followed by «guix system: warning: some services could not be upgraded»
<civodul>festerdam: “service: unbound variable” could be because you reconfigured from an old system running shepherd < 0.9
<civodul>as for the rest, it’s hard to tell
<civodul>you’d have to check what error messages appear before the bournish prompt
<civodul>could be a file system check failure
<civodul>ACTION -> zZz
<festerdam>civodul: It says «loading kernel modules...»; «e2fsck: Bad magic number in super-block while trying to open /dev/vda1»; [longer message saying it couldn't read the vda1 or that it does not describe a ext* fs and that I should run e2fsck if it is corrupt]; «/dev/vda1 constains a vfat file system labelled 'GNU-ESP'»; «File system check on /dev/vda1 failed»
<festerdam>So it's indeed a file system check failure.
<festerdam>shepherd is version 0.9.3, though.
<festerdam>I should note that it the shepherd error comes right after it said that «guix: system: bootloader successfully installed on '(/dev/vda1)'»
<festerdam>*that the shepherd [...]
<festerdam>I should also note that I tried adding a substitute url to the modify-services part of the configuration scm. Before runnning reconfigure.
<festerdam>Hmm. It still fails even without the substitute url added. I don't understand why it's happening.
<apteryx>jpoiret: on core-updates: got this building curl locally: TESTFAIL: These test cases failed: 1474
<apteryx>seems there's now a substitute for it though
<apteryx>(non-deterministic test failure -- it should be report + disabled, ideally)
<apteryx>jpoiret: pushed 'gnu: kmod: Remove libtool archives.' to core-updates; can't test libblockdev yet (missing substitutes)
<podiki>apteryx: that test number seems awfully it one disabled on hurd maybe?
<adanska>Hi Guix!
<efraim>hello guix!
<sarg>greetings! Could someone please educate me on how to submit an updated patch belonging to series? Should I resubmit v2 for all patches or just v2 for the changed patches?
<vivien>I would send a v2 for the whole series.
<vivien>But it probably depends on how many patches there are, how many recipients there are…
<civodul>Hello Guix!
<efraim>%bash-completion-dir (and fish,zsh,etc) in (guix utils) or (guix build utils)?
<efraim>I'm thinking (guix utils)
<gabber>efraim: %bash-completion-dir is for TAB completion in bash and not directly related to Guix' build process, right?
<efraim>right. but we have a lot of code reuse with installing the completions into the correct (or not) directories
<gabber>so i'd go with (guix utils)
<civodul>hmm just realized that the news entry makes it sound like only Guix System users should upgrade their daemon
<civodul>probably worth fixing
<gabber>civodul: you mean "Daemon vulnerability allowing store corruption has been fixed"? i do not understand that as if it only related to Guix System. or is that already the fixed message?
<jpoiret>apteryx: I ran into a lot of transient test failures while building core-updates, some found even on master. I noted some of them
<ayatsfer>hello, is it possible to package a pre-built wheel from pypi? there's this python package "tensorboard" that uses bazel for the build, and I'd probably not want to deal with that....
<jpoiret>ayatsfer: you can do that for yourself, yes, but it won't be accepted in the guix repo
<ayatsfer>yes, I know
<rekado>ayatsfer: take a look at the guix-science repository
<rekado>we've got a bazel build system there, and also a tensorflow 2 package.
<peanuts>"GitHub - guix-science/guix-science: Free scientific packages for GNU Guix."
<ayatsfer>thank you, I will take a look ^^
<dariqq>anyone using greetd+sway? after reconfiguring greetd is flickering and I cant login
<jpoiret>dariqq: was it working before for you?
<jpoiret>or did you just start using greetd?
<dariqq>yes, has been working great for 6 months +.
<dariqq>now I am back at my previuos generation and trying to find out the issue
<dariqq>originally i thought it aws maybe the rust team changes but playing around with a minimal vm suggests that the issue occured alter
<jpoiret>dariqq: because of roll-backs it's probably easier to test on your hardware
<jpoiret>it's probably very recent, I haven't had issues with a branch built with last week's master
<dariqq>hmm there was an update to sway why this would cause issues for greetd
<dariqq>looks like indeed 0e9c2d2eba5e573e43382611474784c8bf5a4309 is the first bad commit
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<dariqq>this seems like resp.
<peanuts>"build of sway-1.9-checkout.drv failed"
<peanuts>"~kennylevinsen/wlgreet: Remove unwanted unreachable macro - sourcehut git"
<qecep>hello, are the services listed in herd status all installed services? is there an argument I'm missing to view all services installed even if they are disabled?
<gabber>qecep: without sudo it lists your user's service, with sudo the system ones
<qecep>I see thank you
<qecep>still, it doesn't show all services installed, only the enabled ones? I can't seem to find the alsa service, on debian I think it's a one shot to set sockets or something
<qecep>so I'm assuming I'm missing a package or more, i'll browse the package archive
<dariqq>I've replaced wlgreet in the greetd-wlgreetd-session with wlgreet at this commit and it works again.
<peanuts>"~kennylevinsen/wlgreet: Remove unwanted unreachable macro - sourcehut git"
<dariqq>love how easy it is to do that
<jakef>a commit in the last 2 days caused me a problem after a system reconfigure
<jakef>guix suspicious ownership or permission on... rejecting this build output
<jakef>working on 2a8018e42c0d9b81d, not working on 7f1145d11a92
<civodul>jakef: hi! could you show which derivation is causing this?
<civodul>i think i’ve identified the problem (in the fix i pushed yesterday)
<jakef>it's a package from a custom channel, is that OK?
<civodul>just to see what kind of derivation it is
<civodul>it’s a download, right?
<dariqq>i got a similar error today when trying to build something with a wrong hash
<jakef>do you want the channel/package or a file contents like .drv
<jakef>i rolled back to check it was the system reconfig, i might need to roll forward to get more info for you
<civodul>jakef: either the .drv or the source, whichever you prefer
<civodul>or something else that reproduces the bug
<civodul>ACTION -> lunch
<attila_lendvai>hi civodul, any comment on ? (the definitions from (shepherd support) module are visible in service start GEXPs)
<peanuts>"shepherd: (shepherd support) is visible for start GEXP"
<festerdam>civodul: As you said yesterday, it is a filesystem check failure, but shepherd is version 0.9.3.
<vivien>Are we releasing 1.5.0 after the core-updates merge?
<vivien>Or before?
<vivien>(maybe after would be a better idea than before)
<efraim>looks like llvm-17 doesn't currently build on riscv64
<civodul>festerdam: oh right sorry, the ‘service’ interface was introduced in 0.10:
<peanuts>"Legacy GOOPS Interface (The GNU Shepherd Manual)"
<civodul>anyway, the file system check issue and that are unrelated i believe
<civodul>attila_lendvai: no sorry; i did notice it and i think i confirmed the problem, but that’s all i did so far :-/
<attila_lendvai>civodul, so, it's not intentional then, right? i think that was my main question, so that i'm not wasting time investigating a non-bug.
<civodul>no i think it’s not
<attila_lendvai>last time i looked i spent about an hour finding out why this happens, but i couldn't find any sign of this being done intentionally
<attila_lendvai>but then i don't yet fully understand the entire chain of machinery that creates and loads the shepherd config files
<gabber>i have freshly installed guix on a host, instantiated my home configuration but got "warning: XDG_RUNTIME_DIR doesn't exists" - which it really doesn't (/run/user doesn't exist). is this a known issue?
<civodul>gabber: i believe that happens when none of you Home services pulls in Shepherd
<civodul>in which case /run/user/$UID isn’t created
<gabber>WDYM "pulls in"?
<civodul>i mean you don’t end up with shepherd among your Home services
<gabber>indeed, `guix home import ~/src/guix-config` did only add home-bash-service-type to the list of services.
<gabber>this smells like a bug, no?
<ayatsfer>hello, which was the command to print the outputs paths that a package (or a .drv) prodcues? without building it
<pranavats>Hello. Does anyone know a way to make multilib glibc available in an FHS emulated container? I'm trying to cross-compile a library for android (arm64), but somehow the llvm toolchain with ndk requires multilib headers (gnu/stubs-32.h).
<jpoiret>ayatsfer: i don't think there is a command, but you can look at the .drv itself, it'll have the output paths in there
<ayatsfer>yes, I thought there would be some flag for it :)
<civodul>heads-up: i pushed a followup for the vulnerability reported at
<peanuts>"[PATCH security] daemon: Protect against FD escape when building fixed-output derivations (CVE-2024-27297)."
<civodul>and also sent a reproducer
<civodul>ayatsfer: you can also run “guix build PACKAGE --dry-run --no-grafts”
<civodul>that prints what would be built
<civodul>ah well, not the output file name(s)
<civodul>another option is to use ,lower at the REPL:
<peanuts>"Using Guix Interactively (GNU Guix Reference Manual)"
<ayatsfer>Is there any reason --no-grafts is needed?
<civodul>this is to make sure you’re looking at the original byproduct, before grafting
<civodul>see for background
<peanuts>"Security Updates (GNU Guix Reference Manual)"
<ayatsfer>I see, thank you
<civodul>yw :-)
<festerdam>civodul: Hmm. I will then download the qcow image again (I didn't back it up) and try to do «guix pull» followed «sudo guix system reconfigure /run/current-system/configuration.scm» and see if it breaks the system.
<civodul>festerdam: oh, that was your first reconfigure after a fresh install of 1.4.0?
<ayatsfer>in that regard, originally I was looking for a cached tensorflow, which seems to be available in this evaluation:
<ayatsfer>For that tensorflow build, I get the same store paths (and cache hit) with --no-grafts, but different store paths without it (and no cache hit, starts to build tensorflow (ouch))
<civodul>ouch indeed
<ayatsfer>I guess there was some security update in the meantime that forced a graft and a rebuild?
<civodul>no no, it must be something “special” about the tensorflow package
<civodul>lemme see
<ayatsfer>it's the guix-science tensorflow (v2) package
<civodul>right, the “bazel stuff”…
<festerdam>civodul: It was the first reconfigure after first running the qemu image that can be downloaded from the official website.
<festerdam>It was only downloaded 3 days ago, so it is 1.4.0
<civodul>that image must install shepherd 0.9 indeed
<civodul>not great
<Altadil>Hi, I’m trying KDE in Guix right now and it seems really nice. If the people who made it possible are reading, well thank you ! You rock. <3
<civodul>time to upgrade the daemon!
<vagrantc>oh, the plot thickens, more patches!
<podiki>and a nice proof of concept to try!
<vagrantc>yes, the code demonstrating the vulnerability is much appreciated :)
<vagrantc>although ... could that code be distributed in guix.git ? that has, well ... a stronger trust path than the blog post
<vagrantc>if it were in the form of a test, it could even check if we accidentally break it again :)
<vagrantc>ACTION wonders if this stuff will reasonably backport to guix 1.2.x ! :)
<vagrantc>huh, there are at least 158 active installations of guix that use the Debian package:
<peanuts>"Popularity Contest Statistics -- Debian Quality Assurance"
<vagrantc>that's opt-in data with a opt-out default ...
<civodul>vagrantc: ahem, looks like you were right about testing the fix beforehand *cough*
<vagrantc>civodul: referring to the second patch ... or ... an upcoming third patch? :)
<vagrantc>i am often right about things i often neglect to do myself
<vagrantc>for example, in the spirit of getting this fix into debian unstable ... i disabled some other tests with no idea of the ramificiations ...
<peanuts>"debian/patches: Temporarily disable tests to workaround (f24f76ad) ? Commits ? Debian / guix ? GitLab"
<civodul>vagrantc: no no, the second one
<civodul>i’ll leave my laptop for a week to make sure there’s no 3rd patch
<civodul>(from me)
<vagrantc>just how serious are these failed tests anyways? test-name: fold-available-packages with/without cache
<vagrantc>test-name: find-packages-by-name with cache
<vagrantc>test-name: find-packages-by-name + version, with cache
<vagrantc>test-name: find-package-locations with cache
<gumbo>GNU's Not Unix
<civodul>vagrantc: not serious; usually they happen when there are two same-named packages or something like that
<civodul>that’s not the case on current ‘master’
<vagrantc>civodul: this is on a somewhat patched 1.4.x
<vagrantc>what is unsettling is they used to succeed
<vagrantc>some dependency changed and now they fail
<vagrantc>i presume
<civodul>even weirder :-)
<civodul>ACTION has to go
<vagrantc>well, the guix-daemon patches apply on 1.2.x too :)
<vagrantc>at some point i should remind myself why i decided to package guix for debian :)
<vagrantc>oh, i wonder if the 64-bit time changes currently pending in debian are related ... no ... it started failing before that whole mess
<vagrantc>hrm. i hope my three concurrent builds of guix are sufficiently isolated from each other that they don't clobber one-another in tests ...
<jas>hi! i was just going to re-install guix on a machine and noticed the security announcement, are new install images in progress? the "latest" download link on does not work for me now
<vagrantc>if the latest link is not working, you're probably stuck with the released version with the vulnerability ... (does the released version download ok?)
<jas>yes no problem with 1.4. i'll pick that and then upgrade it after install..
<jas>is there any reason not to use wayland for gnome in guix any more? i see the default is still xorg
<moesasji>the gnome-team branch switched to wayland by default in February
<dthompson>ooh nice good to know
<yewscion>Hey Guix! Just reinstalled my VPS, and noticed that guix seems to be pulling checkouts with write permission enabled for the owner for some reason? Did I may a mistake?
<yewscion>I only observe this issue when building a package from source, so it is only with the source directories, not substitutes. But it is with /every/ source directory guix downloads.
<yewscion>Here is an example of the output I get when attempting to download the source for emacs, as well as the output of ls -lha on the resulting file:
<peanuts>"debian Pastezone"
<yelninei>yewscion: There was this commit today ff1251de0bc327ec478fc66a562430fbf35aef42. Which sounds like the problem you're facing
<podiki>yewscion: have to run, but did you pull recently? there was a fix for a cve that had 2 commits, if you were between them there might have been an issue
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<podiki>yes that's the one; would guix pull and should be good (and needed for security; reconfigure and restart guix-daemon)
<yewscion>Will check by running `guix pull` again and then pinning to before that commit, to see if it helps!
<yewscion>(Assuming the `guix pull` fails, I mean. No need to pin if it helps!
<podiki>you should pull to that commit (at least) for security reasons
<yewscion>podiki: I will, so long as I can actually use the software I need running on the server. Unfortunately, this happened mid-reinstall for me... so I may be stuck reconfiguring to before the commit first, building everything, and then after the commit if the guix pull does not resolve it
<podiki>ah gotcha; unlucky timing
<podiki>might as well go before the first commit for the cve; without both it isn't mitigated anyway, and seems just the first commit leads to the issue you were having
<moesasji>I'm trying to understand how to start a system service for keyd, which needs a config file in /etc. It looks like etc-service-type can create such a file in /etc, but it evades me how this would interact with a keyd services. Can anybody point me to an example how setting up a service for something like keyd would be done?
<attila_lendvai>i've been running with this for quite some time now:
<peanuts>"[PATCH] guix: pull: Also print the name of the branch."
<yewscion>podiki: In case it's useful to anyone: doing a `guix pull && guix system reconfigure config.scm` *followed by* `herd restart guix-daemon` (as mentioned in the article linked above) was necessary to fix the issue I was having. All is working now. ^_^ Thank You for the help~!
<podiki> Welcome, glad it works!
<zilti>I am trying to create a Python package that needs gnu-build-system. During the build phase, I get "ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied", what can I do about that?
<zilti>...ah no, it actually *is* able to be built using pyproject-build-system. Never mind. But there I get "AttributeError: module 'pep517' has no attribute 'build_wheel'"