IRC channel logs
2024-03-12.log
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>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>you’d have to check what error messages appear before the bournish prompt <civodul>could be a file system check failure <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>I should note that it the shepherd error comes right after it said that «guix: system: bootloader successfully installed on '(/dev/vda1)'» <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 familiar....is it one disabled on hurd maybe? <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… <efraim>%bash-completion-dir (and fish,zsh,etc) in (guix utils) or (guix build 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 <civodul>hmm just realized that the news entry makes it sound like only Guix System users should upgrade their daemon <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 <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. <dariqq>anyone using greetd+sway? after reconfiguring greetd is flickering and I cant login <jpoiret>dariqq: was it working before for you? <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 <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>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 <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 <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 <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>(maybe after would be a better idea than before) <efraim>looks like llvm-17 doesn't currently build on riscv64 <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. <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 <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. <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>ayatsfer: you can also run “guix build PACKAGE --dry-run --no-grafts” <civodul>ah well, not the output file name(s) <ayatsfer>Is there any reason --no-grafts is needed? <civodul>this is to make sure you’re looking at the original byproduct, before grafting <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>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)) <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 <ayatsfer>it's the guix-science tensorflow (v2) package <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 <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 <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>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 ... <civodul>i’ll leave my laptop for a week to make sure there’s no 3rd patch <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 <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>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 guix.gnu.org 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 <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. <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 <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>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? <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~! <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'"