IRC channel logs
2025-12-14.log
back to list of logs
<freakingpenguin>When using guix home, I get "duplication definition for FOO environment variable" warnings. I have multiple services extending the same env var in home-environment-variables-service. (e.g. multiple extensions adding to path). Anyone with a similar setup find a way to avoid/silence those warnings? <freakingpenguin>Functionally it works how I want since they expand e.g. PATH in the definition, just an overzealous warning. <pomel0_>I was trying to build an installation image, but when running `guix system image -t iso9660 gnu/system/install.scm` it says it can't find that file. How do I make such a file/is there a way to export it? <pomel0_>ah, should I clone the guix git for this? <vagrantc>gnu/system/install.scm is in guit.git, yeah <vagrantc>i have not tried creating an installer (at least not recently) ... so cannot help too much beyond that <pomel0_>yes it's all working now after cloning the git repo <vhns>couldnt you also just generate the install media through an expression instead of cloning the repo <vhns>guix system image -e '(@ (gnu system install) installation-os)' <pomel0_>well I'll try that later, it's what I was thinking about <vhns>be careful to specify the image type <vhns>guix system image -t iso9660 -e '(@ (gnu system install) installation-os)' <pomel0_>I'm actually building an image for i686, I wanna try out Hurd in my Thinkpad X60, specially after reading the blog post about it some time ago <lilyp>can someone explain to me the following: <lilyp>$ ./pre-inst-env guix weather webkitgtk → 100.0% substitutes available (2 out of 2) <lilyp>$ ./pre-inst-env guix build webkitgtk --dry-run → The following derivation would be built: /gnu/store/p9kxay2wdq0clmqwfmj87yl3v4b0r1lh-webkitgtk-2.50.3.drv <lilyp>note that the hash matches the one built on CI <Rutherther>lilyp: can you try --no-grafts for the guix build --dry-run? <lilyp>2.48.1 gets returned as store path just fine <lilyp>csantosb: uhm, nope, there's a security patch :P <lilyp>CI evaluated it already, but I'm still stuck on unbuilt myself (ain't nobody got the time&memory to build webkit) <csantosb>"./pre-inst-env guix build webkitgtk --no-grafts --dry-run" gives me <csantosb>"114.7 MB would be downloaded", along with a list of store packages <lilyp>yeah, but i need to download the grafted one :P <Rutherther>oh, you're dealing with a replacement on webkitgtk itself, have you tried build --expression on the replacement then? <Rutherther>not really sure how exactly guix build behaves with replacements on the package you want to build tbh, maybe it's not 100 % <Rutherther>but on first sight it looks correct to me in scripts/build.scm, so it might be bad direction to look into. Not really sure what else it could be though <lilyp>The following derivation would be built: <lilyp> /gnu/store/p9kxay2wdq0clmqwfmj87yl3v4b0r1lh-webkitgtk-2.50.3.drv <Rutherther>hmm, are you by chance using the pulls.ci.guix.gnu.org for this? <lilyp>well, duh, but it should be available to regular ci, no? <Rutherther>I am not sure tbh, it's built in a VM, not sure what happens to it afterwards. I am just thinking if the store path is being outputted with the regular signature of ci.guix.gnu.org or a different one <lilyp>it's built already, why won't it just download it? <Rutherther>I really think it's going to be the missing signing key, unfortunately it seems cuirass doesn't provide the signing key anywhere. guix publish does provide it at /signing-key.pub, but cuirass doesn't let that url pass through <lilyp>but then why does the substitute show up on guix weather? <lilyp>and mind you, it also shows up on bordeaux <Rutherther>oh! I see then, my bad. It seems guix weather would even print a warning when something is not signed. So you would definitely notice that. It's not guix build that handles grafts wrongly, it's weather. Showing you the original webkitgtk package and not the replacement <Rutherther>try guix weather with the --expression for the replacement <lilyp>no, it's not guix weather that is wrong <Rutherther>have you submitted a job to qa already? or how would bordeaux build the package then? <Rutherther>I have went over guix weather and it turns grafting off and never uses package-replacement <lilyp>*sigh* it is a different key, wtf <PotentialUser-71>I just upgraded my Guix System and now I'm wondering why the init Guile segfaulted 3 times in the boot process. <PotentialUser-71>(or more precisely, a segfault was logged 3 times in the boot process, dmesg only reports 1) <identity>PotentialUser-71: the segfaults are a known issue, but they should be harmless. it is probably the same segfault message displayed multiple times <Rutherther>lilyp: for me "guix weather webkitgtk" and "guix weather --expression="(@@ (gnu packages webkit) webkitgtk/fixed)"" end up with different results. You're right that it was wrong of me to say weather is wrong here. It's probably correct, the idea being that the build farms do not build grafts. On the other hand maybe in this edge case it would be nice if it gave the package-replacement instead of the package itself. I get no availabilities for the... <Rutherther>... latter on neither ci nor bordeaux. I get availability for pulls with the public key <lilyp>well, I would hope that the results of CI feed into CI… <Rutherther>I would rather refrain from authorizing the key for longer times though, because anyone can submit any PR and can even change the entrypoint of cuirass (unless it has been somehow prevented for pulls specifically, I haven't got into that yet). Which in the end means that one could supply any .drv paths with any contents/outputs they desire <lilyp>otherwise, I'm kinda at a loss not just with webkit, but with gnome-team as well <lilyp>(but it seems gnome-team is evaluated by regular CI?) <Rutherther>maybe a question for Ludo, I am not sure what the security implications would be of just submitting all those built outputs to master <lilyp>if it's not fixed by 1pm, then I'll just have to push a change that causes lots of rebuilds on sunday <csantosb>"guix git: error: could not authenticate commit e3c33d9ab4c88c7", did I miss something ? <Rutherther>(note that guix time-machine has a bug, it doesn't pull keyring) <cow_2001>getting "Original error was: libz.so.1: cannot open shared object file: No such file or directory" in a container trying to install numpy <noe>Hey Guix :) Is this supposed to happen? “note: currently hard linking saves -618417 bytes” <identity>yay negative savings from hardlinking. it is probably not supposed do <nckx>It's possible for the .links directory entry to be huge, and that size is subtracted (as overhead) from the total saved count. This size also won't shrink when the link count decreases, which is probably what happened. <nckx>In your case the ‘ls -ldh’ might exceed the ‘du -sh’. <nckx>(‘du -sh’ isn't exactly correct but it's a good indication.) <nckx>If so, all this is to say that Guix is right, even if its English could be improved. <noe>hmm I don’t think thats it, my .links is only 1,1M <identity>noe: if i did the math right, that is ~1153433 bytes, which is more than 618417 bytes <noe>identity, what does it mean that its more? <identity>unless i did the math wrong the second time and the numbers wrong <identity>noe: the size of .links is more than the space hard linking saves (about 535016 bytes, which i get by adding the ~size of .links in bytes and the reported savings), which causes the weird message, as negative savings are not handled properly. or at least that is what i got from the messages above <identity>«the space hard linking saves» without taking into account the losses, i mean <noe>ohh makes sense, thanks for the explanation <yelninei>How can I get a substitute from ci.guix.gnu.org for a package I am trying to upgrade? <Rutherther>is it really important that it's from ci.guix.gnu.org in particular? if so, it would be by making a jobset or adding it to any branch it already has a jobset for <yelninei>i am just confused that after bumping the version+hash and wanting to try the update there is nothing to do as apeparently this is already build somewhere? i tried to look through the commits on other branches but could not find anything <Rutherther>is the output path/derivation path different from the one before your change? <yelninei>yes, I would assume that atleast there would be a "Update libgit2 to 1.9.2" commit somewhere <Rutherther>and guix weather told you it's on ci.guix.gnu.org? <Rutherther>(found it like this "git grep -l "1\.9\.2" $(git branch -a --format='%(refname:short)') -- gnu/packages/version-control.scm", I do fetch all the pull refs locally) <yelninei>I guess that would explain it. I was jsut searching the codeberg web for libgit2 and that pr did not show up <yelninei>closed the pr again as duplicate. But i got a bit spooked <loquatdev>Is there a way I can see the exact command shepherd ran? I'm building a custom service as an exercise and the command is failing. The issue is unclear from the output, though. <loquatdev>I figured out why it wasn't working, but I'm still curious if there's a way to do this. <avalenn>I am building some Rust app from a Guix container that I want to use on other system, but the /gnu/store path for glibc is leaking in the binary <avalenn>How can I avoid that or workaround it to avoid libc not found when launching the binary on a Debian ? <cbaines>this sounds like a rust problem avalenn, rather than a Guix one <cbaines>the approach with Guix would be to deploy this through a Guix package to the Debian system, which would solve the glibc reference issue <cbaines>the guix pack also provides tooling to deploy software built using Guix on other systems