IRC channel logs

<vagrantc>1.4.0 ws released December 2022, if git tag can be believed.

<apteryx>what is the largest debug output you've had to download recently?

<apteryx>qtdeclarative is huge at 1.3 GiB; is there something that best it?

<untrusem>it is really huge 🥲

<Rutherther>alanz: if you are running it through home you should probably make a system service that creates a session as your user and also enable-linger if you're still using elogind

<csantosb>So, TIL. A failed ci job, see #3561, may be manually re-launched using the action button (restart).

<csantosb>This ci bot is really useful, thanks to people involved on it !

<loquatdev>I am trying to test running an xorg server on my machine. I'm running a simple shell command from the TTY, `guix shell xorg-server xinit dwm st` and then `sudo xinit .xinitrc` (where the rc just contains `exec dwm`). It works, but I get no input. I've tried adding several different items to the shell to no avail.

<sneek>Welcome back loquatdev, you have 1 message!

<sneek>loquatdev, Rutherther says: when you run guix system reconfigure, guix script checks if you're doing a forward update. To check that, it needs to see the commits in the repo. Since it's executed as root, the checkout under /root/.cache is used for that rather than the one you use as a user. If you want to share the checkouts, see shared-cache-service-type

<loquatdev>Ironically, I've been using wayland for a while with no issues, haha

<tux1c>i know the official grub-bootloader (for bios) only supports device names as input, but is there some sort of a guix function which will convert a uuid to it's parent's device name? the servers im working on don't really have consistent device names and they seem to be changing on different reboots, i'd like my configuration to stay consistent

<civodul>Hello Guix!

<sneek>civodul, you have 3 messages!

<sneek>civodul, apteryx says: yes, I'm aware of the validate-runpath trick (add a global runpath to the libraries to everything), but it's suboptimal: a) new users will no know how to handle with the problem, likely to disable the whole phase b) even if you know about the problem, it's sometimes confusing whether it's a bug in the build system of the package or just a loadable plugin that should be ignored/placated via the a) trick

<sneek>civodul, apteryx says: ... and c) one could argue is not proper to have loadable plugins have a RUNPATH and d) it looks like we perhaps can have some basic heuristic and/or a hint when validate-runpath can't reasonably assume something

<sneek>civodul, efraim says: I'll try my pine64 image again with shepherd-1.0.8

<csantosb>civodul: There is something weird in this bot, see #3561

<cbaines>I'm going to reconfigure bayfront this morning with some nar-herder changes

<civodul>csantosb: i don’t think that’s weird: there are “reviews” for two different evaluations

<civodul>what’s annoying is that the oldest one came last

<civodul>ah yes, and there’s a repetition for eval 4728

<civodul>tracked here: https://codeberg.org/guix/cuirass/issues/91

<csantosb>What's weird to me is that if fails, it success, then if fails again.

<civodul>yes, but you need to look at the evaluation number: they correspond to different commits

<csantosb>Probably due to a rebase on master ?

<csantosb>It is possible that the repetition comes from we re-requesting a review from codeberg, then from action button in cuirass

<civodul>the bot doesn’t read its messages, no need to ask it for review :-)

<civodul>there were two commits at https://codeberg.org/guix/guix/pulls/3561

<civodul>one for the initial push, and another one when you rebased

<civodul>that’s why we get reports from two different evaluations

<civodul>the only problem here is the repeated message for the first evaluation

<csantosb>But in the two evaluations, 4728 and 6478, corresponding both to #3561, no changes in between, results change, right ?

<apteryx>civodul: hi! I was testing something like this for a `safe-clone' variant that integrates your ideas/feedback so far: https://paste.guixotic.coop/new-safe-clone.html

<apteryx>I'll update the PR with it soon, you can wait to comment there if you prefer.

<csantosb>civodul: Ok. If fails when it attempts to build libtorrent-0.16.0 and rtorrent-0.9.8. Pr concerns an update to 0.16.1 of both.

<cbaines>going to stop the bordeaux build farm bits while I fiddle with the nar-herder...

<ekaitz>civodul: should we announce what we did yesterday and also move fibers?

<civodul>ekaitz: maybe check on #guile? i believe if we do that fibers/fibers will redirect to guile/fibers right?

<civodul>i’ll have to update links here and there…

<ekaitz>yes

<jab>morning guix!

<jab>Anyone want to buy a Dell optiplex 7020 ? I've got guix system running on it. I think it's a 2TB hard drive with 16 or 32 GB of ram. I'd be happy to sell it for $450 and donate $50 to guix. I'm in the USA, by the way.

<jab>for the new release....something about the installer getting my username is confusing.

<jab>This is the second time, that I put in my name/username and when I tried to log in as "joshua" I found out that my username was actually "Joshua Branson"

<jab>I just installed guix system just now. And when it asks you to add a username, perhaps it should say...

<jab>"Your full name:" User puts in their full name

<jab>"your username:" User puts in their username

<jab>home loctation "/home/username"

<jab>The installer is perfectly happy to let your home location to be "/home/joshua" but the username is "Joshua Branson." That is a little confusing.

<jab>is it still the case that after a new install, one should run, just once, "sudo -i guix pull" ?

<Rutherther>jab: on guix system you typically do not use root's guix at all, so no

<jab>good to know.

<Rutherther>And on foreign distros you should run it regularly to update the guix-daemon (assuming usage of guix-install.sh)

<tesseract>Rutherther: should i also do "sudo -i hash guix" on a foreign distro?

<tesseract>after "sudo -i guix pull"?

<tesseract>i did "sudo -i guix pull" it is doing stuff. it says "Authenticating channel 'guix', commits 9edb3f6 to b7b6851 (66,653 new commits)"

<Rutherther>tesseract: no, hash makes sense only when you are running an interactive shell, this immediatelly closes the process, so it will have no useful side effects

<tesseract>66.653!

<tesseract>i am doing it the first time

<tesseract>Rutherther: thanks

<tesseract>Rutherther: but i have to do "hash guix" after non-root "guix pull", right?

<andreas-e>The first time is always very long. But it is recommended to do the "guix pull" as the normal user without "sudo", and later you can "guix system reconfigure" with "sudo".

<Rutherther>andreas-e: but note that will still populate root's cache with guix checkout when you run reconfigure, redownloading guix repo twice (root + user), so still first reconfigure is slower than subsequent ones

<Rutherther>tesseract: I am not completely sure in what exact situations hash becomes necessary. Maybe it is always necessary for bash, cant tell

<andreas-e>Rutherther: Why would it download the guix checkout twice? "guix pull" followed by "sudo guix system reconfigure" should use the user Guix, no?

<Rutherther>andreas-e: yes. Because of the forward update check that runs as root and looks at the channel checkouts to figure out if your current guix commit is a descendant of channels used for previous guix system generation

<anemofilia>Do someone here know how to wrap a program while still having functioning search paths?

<anemofilia>I found this question on the mail list (https://lists.gnu.org/archive/html/help-guix/2025-02/msg00078.html) but it wasn't clear to me if Tomas found a better approach

<cbaines>nar-herder database updates have finally finished on bayfront, but I'm still testing things and I haven't got the build coordinator going again yet

<andreas-e>Thanks for moving things forward cbaines!

<jab>the manual here should be updated by the way: https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html

<jab>It mentions nss-certs for the desktop configuration, but that is included by default now apparently.

<jab>it's included in %base-packages

<Deltafire>that's the old manual, check the devel version

<jab>gotcha.

<jab>Deltafire: you were right. the newer version doesn't have that.

<futurile>Afternoon

<csantosb>Hi Steve

<futurile>Q: anyone know a magic invocation to set an environment variable in guix shell? Rutherther I think you had a neat way to do it?

<csantosb>`guix shell -CN --preserve='^TERM$'` ?

<futurile>yeah, I want to set a new one

<futurile>I thought I might be able to do it in a manifest, but no dice so far

<trev>anyone know when team-gnome branch will merge into master? waiting for gnome 48

<csantosb>You can check at qa.guix.gnu.org

<trev>is it down, or just me?

<identity>502

<trev>same

<andreas-e>trev: QA is back.

<andreas-e>gnome-team has not yet made a merge request for their branch.

<vntsuyo>is it possible to package https://github.com/sentriz/go-taglib for upstream? it bundles a wasm binary and I don't think upstream has the tools do recreate it

<kestrelwx>apteryx: By the way, for OpenDHT - it uses uring over epoll if built with it, judging from the macro names.

<trev>andreas-e: thanks

<alanz>Rutherther: thanks, I will look at those options

<civodul>i’ve been trying to push on ‘master’ for an hour or so, but everytime i do, i have to rebase, then rebuild, and by the time i get around to retrying ‘git push’, someone else pushed :-)

<civodul>(and the rebuild cycle is long because it’s the ‘define-deprecated-package’ change i’m trying to push, and that touches many files)

<ekaitz>civodul: that's an interesting dev ux issue, we should do that better...

<ekaitz>ideas on how to improve this?

<ieure>Make Guile way faster :()

<trev>wait until everyone is asleep 🥲

<alanz>Maybe the CI stuff can have an option to push to master once the tests pass

<futurile>vntsuyo: it's possible to package it, but not to have it in Guix, you could have it in nonguix I guess.

<ekaitz>ieure: Guile is pretty fast already

<futurile>civodul: when you do 'make check-system TESTS=debian-install"' is there a way to break into the VM that it's starting?

<futurile>civodul: and uh where do the logs go?

<futurile>oh hold on it's told me

<tesseract>what does "applying 6 grafts for icecat-140.4.0-gnu1" mean?

<ieure>tesseract, https://guix.gnu.org/manual/en/html_node/Security-Updates.html https://guix.gnu.org/blog/2020/grafts-continued/

<tesseract>checking

<tesseract>what the hell, dude

<tesseract>nevermind

<tesseract>i don'T understand a thing

<tesseract>i guess it works

<tesseract>i will leave as it is whatever it is doing

<identity>tesseract: basically, it is monkey-patching the executable to point to a different (usually patched to fix security vulnerabilities) version of the library

<tesseract>identity: but it applies too fast on my debian. that's what confused me

<identity>what do you mean «too fast»?

<tesseract>nevermind :/

<tesseract>i don't want to talk about it now. but thanks

<andreas-e>civodul: The "define-deprecated-package" is really interesting. We have lots of references to libolm, which was deprecated in 2022; so normally the deprecation should have been dropped for two years already...

<redacted>I'm building a guile script with (program-file), and I'd like to step through the resulting script to debug it. Loading it with ,load from guix repl runs the script, but I'm not able to set breakpoints.

<redacted>,bs <script-path> 3 tells me that no procedures are found

<redacted>(which is true, there are no procedures there)

<redacted>Is there a way to do what I'm trying to do from the guix repl?

<voroskoi>is it just me or libgcc_s.so.1 gone missing from gcc-15 guix builds? I can find it in gcc-14 store files

<kestrelwx>[env] ~ $ find $(guix build gcc-toolchain) -name libgcc_s.so.1

<kestrelwx>/gnu/store/rbs3nrx9z6sfawn3fa8r8z1kffdbnk8q-gcc-toolchain-15.2.0/lib/libgcc_s.so.1

<voroskoi>that is just a symlink pointing nowhere

<voroskoi>my bad, it is there actually

<kestrelwx>It points to a real lib for me.

<voroskoi>You are right, thanks

<kestrelwx>Can you show ldd for your application? It should show nothing for this library.

<civodul>andreas-e: https://codeberg.org/guix/guix/pulls/3579#issuecomment-7873193

<civodul>there’s nothing to fix :-)

<civodul>and we know that

<civodul>er

<civodul>and we know that because CI did its magic before merging

<yelninei>i just killed my guix after it used 4gib of ram. Is this related?

<civodul>without knowing what you did, it’s hard to tell :-)

<civodul>but at first sight, i don’t think it’s related

<yelninei>"./pre-inst-env guix build shepherd" after a git pull and make

<civodul>woow, https://ci.guix.gnu.org/jobset/master performed several evaluations per hour and each evaluation takes ~50mn

<civodul>yelninei: works for me!

<civodul>on x86_64-linux

<civodul>works for ci.guix too :-)

<yelninei>recompiling now, i was on my x86_64-gnu branch but there is nothing special there except some test skips

<andreas-e>civodul: So I fixed the deprecated references for nothing :)

<civodul>andreas-e: not for nothing: it’s still useful work that would have had to be done

<andreas-e>Anyway, I am cleaning up now. Updating bioinformatics packages!

<civodul>but it’s not a “fix”, strictly speaking :-)

<civodul>but i guess you deserved to be thanked anyhow: thank you! :-)

<andreas-e>Thanks, that embellishes my evening :-)

<civodul>heheh

<yelninei>civodul: recompiling did not fix it but i was in a different branch than I thought which has more intrusive changes

<yelninei>the actual branch i wanted to test works, so maybe I have a problem somewhere

<kestrelw`>Good night!

<RavenJoad>I have a library that builds with go-build-system, but another go package that uses it as a native-input does not have the source for the library present. (#:install-source? is #f on the library. Any ideas?

<yelninei>hmm something does like the mig patch I added. I guess it causes a circular dependency to apply the patch in commencement.scm

<RavenJoad>Ah. I figured it out. It turns out that the builder only makes the GOPATH union directory out of packages that satisfy go-package?. That just checks for the package's name to have a "go-" prefix.

<alanz>For anyone following my elogind issue, I kept elogind as it was, and added auto-login via https://guix.gnu.org/cookbook/en/html_node/Auto_002dLogin-to-a-Specific-TTY.html#Auto_002dLogin-to-a-Specific-TTY

<alanz>I now have my bot running at boot

<Deltafire>nice.. but seems like something that shouldn't depend on elogind

<alanz>Agree, but for my own reasons I decided to run it via home, and that needs XDG_RUNTIME_DIR, and this seems the simplest for that. The logic being I can run things on my debian laptop too

<alanz>And the whole thing is a learning experience

IRC channel logs

2025-10-23.log