IRC channel logs

<vhns>I also dislike the migration to Codeberg. Although now it's too late and I never bothered chiming into the discussion.

<meaty>anyone got some good blog posts/other resources on using guix deploy? specifically I'm looking for any examples of a hetzner deployment and/or how to test the os definition in a vm before deploying

<ekaitz>meaty: fnat does: https://fabionatali.com/posts/xmpp-self-hosting-tutorial/

<meaty>ekaitz: noice, I was planning on prosody being one of the services too

<Kolev>vhns, why do you dislike Codeberg?

<Kolev>meaty, nice, Prosody! 😀

<apteryx>gabber: hi!

<apteryx>for your pgp key, do you use 'E426 7CD1 FC3E E959 7F07 42F9 CC98 E9F0 4330 FD7F' for signing the commits, or is this the primary key and you instead sign using a subkey ?

<Kolev>Why do key fingerprints have " "?

<apteryx>in 200 few packages addition, Guix will catch-up to FreeBSD Ports in terms of collection size, according to Repology :-)

<apteryx>Kolev: seems a convention, perhaps for easing reading them?

<apteryx>it's just cosmetic

<Kolev>apteryx, ah.

<bdju>Is a package conflict worth creating an issue about?

<bdju>I guess it can just be closed if it's not appropriate, better than waiting around.

<bdju>Is there something like --with-commit= that works with tar release version numbers?

<phsw>bdju : --with-version ?

<andreas-e>apteryx: My goal is to get less packages, not more ;-) We need to get rid of cruft that is a maintenance burden.

<andreas-e>And we are only at position 10 for the number of up to date packages; there we have a hope of catching up with Opensuse soon.

<sneek>Yey! ekaitz is back

<jakef>hi andreas-e, what branch do you think that mariadb patch should go to?

<andreas-e>Hello jakef! In CODEOWNERS there is this line:

<andreas-e>gnu/packages/databases\.scm @guix/sysadmin

<andreas-e>So it "belongs" to the sysadmin team. Which is only one person...

<andreas-e>So either we/you/the team can regroup a few changes in that area, or, as I suggested on guix-devel, we should create a branch with a dozen, say, mixed updates.

<jakef>yeah throw it in with that hunspell one

<andreas-e>I have filed a merge request for my "world-rebuild" branch (which is currently empty, but should collect this small number of commits), but guix-patches has not treated it.

<ekaitz>sneek: botsnack

<sneek>:)

<gabber>andreas-e: i can't push (unknown introductory commit and signer). do you know what's missing?

<gabber>i did sign the commit

<yelninei>did you fetch the keyring branch?

<gabber>i just did (to no avail)

<abbe__>git fetch -v origin keyring:keyring

<gabber>no lock either

<abbe__>git show --show-signature HEAD

<abbe__>assuming HEAD is your commit

<gabber>huh

<yelninei>do you want to push to master or another branch (which lacks your authorization)?

<gabber>i want to push to master (with my freshly gained access rights)

<gabber>it fails even when my commit is signed

<gabber>ACTION has to go; will try again later

<abbe__>just make sure it's signed with the right key. if you can pastebin the output of: git show --show-signature HEAD, I can check.

<gabber> https://termbin.com/dlsj

<yelninei>did you initialize guix git authenticate by running it with the full introductory commit and key (it caches thoses in .git/config)

<andreas-e>gabber: Sorry, I was afk, but also do not know the solution.

<abbe__>key is right, but likely the missing keyring branch update

<fnat>Anyone has succeeded in setting up xss-lock and slock under X? I've added a one liner to my .xinitrc ('xss-lock -- slock &', with the correct Guix paths) and added the screen locker service, as described here https://guix.gnu.org/cookbook/en/html_node/Xorg.html - but still no luck.

<abbe__>what about: git rev-parse keyring

<abbe__>fnat: need to elaborate more

<fnat>Glad to do that. Let me prepare a snippet.

<abbe__>are you unable to unlock ?

<fnat>abbe__: No, sorry, I should have said, the issue is that it doesn't lock.

<abbe__>does it lock when you manually run the locker application ?

<fnat>I can launch the lock "manually", but it never locks automatically after a period of inactivity or because of a suspend.

<fnat>So, thinking of it, it sounds like it should be on the xss-lock side of things?

<fnat>xss-lock also does work (it locks on suspend or inactivity) if I launch it manually from a CLI.

<abbe__>so maybe something to do with PATH, perhaps try redirecting output of startx to a log file, or .xinitrc's

<fnat>Here's my .xinitrc: https://paste.debian.net/1386860/

<fnat>abbe__: Ha, great idea re redirecting the output. Will do that.

<abbe__>hmm, not sure why you need xhost, unless you're X11 forwarding

<fnat>abbe__: I don't X11 fwd, nope. I think that's needed by Emacs EXWM? But thanks for pointing that out, I'll double-check.

<abbe__>oh, i see

<Kabouik>andreas-e: thanks a lot for your commit on libmcrypt. Sorry I caught up later, I was AFK when you mentioned your fix.

<Kabouik>I still haven't been able to run my system reconfigure because it still fails on other packages. Looking at the issues on Codeberg, I can see that many packages have broken with the merge. I'm reporting those I see that have not been reported yet.

<andreas-e>Kabouik: No problem! Issues are welcome. Before merging, we mainly looked at the big blockers, and I think quite a few packages towards the leaves are broken.

<andreas-e>I will not have time to work much on fixes today, but will be around to merge pull requests.

<fnat>abbe__: I've redirected the output this way 'startx 2>&1 > /log-file' but that only shows one single line ("localuser:user being added to access control list"). No errors...

<abbe__>`startx >/log-file 2>&1`

<abbe__>should be other way

<fnat>Gotcha.

<fnat>Thanks, let me try again then.

<Kabouik>Is there a way to exclude packages from the upgraded triggered by a system reconfigure, similar as with guix package -u, or should I just uncomment those packages in my config.scm?

<Kabouik>Erm, many typos, sorry. s/upgrade/upgraded. s/uncomment/comment.

<andreas-e>If you uncomment them, this amounts to removing them in this iteration. Remember there is no state in system configuration.

<fnat>abbe__: Ok, I was able to find this: "slock: unable to disable OOM killer. Make sure to suid or sgid slock."

<fnat>A bit unexpected because I do have a screen-locker-service-type service that should be taking care of that.

<abbe__>yes, you need to use the wrapper

<abbe__>not the path in the store

<fnat>Aha!

<fnat>Which is why it works when I launch it from the command line as "slock", I guess?

<abbe__>i'm not sure about that, are you sure you don't get that error when you manually launch it ?

<fnat>Let me try again.

<abbe__>and is it an error, or just a warning ?

<fnat>'slock' works from the CLI. 'xss-lock -- slock' also works if launched manually from the CLI. I see that 'slock' is a symlink to '/run/privileged/bin/slock'.

<fnat>I guess I could try adding that path to my '.xinitrc'.

<abbe__>that explains, or just specify the privileged path in command-line

<fnat>Ok, it looks like it works! I've now switched to using '/run/privileged/bin/slock' in .xinitrc. I guess this is fine?

<abbe__>yep

<fnat>abbe__: Thank you so much for guiding me through this. It'd been buggering me for ages, hehe.

<abbe__>Happy to help :)

<PotentialUser-83>Hello Guix

<PotentialUser-83>How would I declaratively set dark mode for `xdg-desktop-portal-gnome` ?

<PotentialUser-83>I'm using Guix System.

<PotentialUser-83>In a normal distro, I would've done `dconf write /org/gnome/desktop/interface/color-scheme '"prefer-dark"'` in the CLI, but that is an imperative method.

<PotentialUser-83>I would like to do something like this, but utilizing my `config.scm` / `home.scm`

<Noisytoot>why is the guix wireshark package missing androiddump?

<csantosb>Do we have androiddump in the repos ?

<Noisytoot>csantosb: It's supposedly part of wireshark: https://www.wireshark.org/docs/man-pages/androiddump.html, but it's not in the guix package

<acrow>Does anyone have a patch for guix's version of nyxt?

<fnat>I've this setup where I login on a TTY, then I launch 'startx' to get to Xorg. I have the unclutter services enabled so that my cursor gets hidden automatically after a short period of inactivity.

<fnat>However, this won't work without some manual nudging every time I start X.

<fnat>The reason being: unclutter relies on x11-display. x11-display won't start while I'm on the TTY (rightfully so). So by the time I've entered X, both services are either stopped or disabled - and I need to restart/re-enable them manually.

<fnat>I suppose there's no easy fix to this, if not somehow heavily customising the services, correct?

<fnat>Or potentially adding the restart operation to my '.xinitrc', which is meh... not the cleanest way of approaching this?

<Noisytoot>Actually never mind - the guix package does have it, it's just in lib/wireshark/extcap/androiddump and not in bin as I was expecting

<umanwizard>another day, another attempt to reconfigure my system on the newly updated master :). Let's see if it succeeds now that the bpb issues have been fixed.

<umanwizard>s/bpb/bdb

<andreas-e>umanwizard: Just about an hour ago!

<andreas-e>Which means that there will not yet be substitutes of packages depending on it.

<umanwizard>andreas-e: that's sadly often the case on aarch64 (lack of substitutes)

<umanwizard>fortunately, things build pretty fast on M3 Max

<andreas-e>They will come, but it takes a bit of time; about two hours for the data service to handle the commit.

<andreas-e>Interesting, so you have Linux on a recent Mac! A Guix system, or just the package manager on top of another distribution?

<umanwizard>guixSD on a vm. there is no way to run any Linux distro natively on this hardware (Asahi only supports M1/M2 series).

<umanwizard>but the performance hit introduced by the VM is minimal

<andreas-e>That sounds good! How long does a "guix pull" take?

<umanwizard>not sure, I usually run it in the background while doing something else. A few minutes at least, definitely long enough that I don't want to sit there waiting for it

<umanwizard>I'll measure next time and tell you

<yelninei>andreas-e: thank you for managing the core-packages-team branch. It felt like it got stuck a bit a few months ago

<umanwizard>there is another package failing (in `check` phase now): google-highway. looking into it...

<andreas-e>yelninei: Yes, it was annoying to rebase and rebase and rebase :)

<andreas-e>Abd every time there were merge conflicts with Janneke's copyright lines.

<andreas-e>umanwizard: Thank you!

<ekaitz>andreas-e: hahaha janneke has been a source of conflicts for me in other repos too hahaha

<umanwizard>codeberg seems slow/broken, can't submit my pr

<PotentialUser-7>Here is a question: several times my upgrades fail because some derivation fails to build. The failure is not due to the download, but the actual processing of the files.

<PotentialUser-7>Given that the package builds are reproducible, then I can expect the building also fail to everyone else, like the CI platform and the creator of the "package". Am I wrong?

<umanwizard>andreas-e: oh, looks like it submitted after all. https://codeberg.org/guix/guix/pulls/1423

<andreas-e>umanwizard: Yes, codeberg seems to have problems. A sign that I should give it a break after this long weekend guixing!

<umanwizard>PotentialUser-7: often yes but not necessarily. things can break due to quirks of the specific model of hardware you're using. For example, I have had builds break because some packages assume all aarch64 processors can virtualize 32-bit ARM code, which is true for most aarch64 processors but not mine. Or there might be a situation where e.g. something erroneously assumes all x86-64 processors have some particular SIMD extensions, etc.

<umanwizard>Or you can have builds fail because of running out of memory and need to retry with a lower --max-jobs setting

<andreas-e>PotentialUser-7: Yes, we merged big changes Friday night, which caused quite a few things to break. And since then we are repairing :)

<andreas-e>You can have a look on codeberg and potentially submit an issue or a pullrequest if none is there for your package.

<PotentialUser-7>umanwizard Those are good points I did not consider. They do not apply to my case, but they still stand.

<PotentialUser-7>andreas-e Yes, it was a large update, and I was happy to try the new version of kdenlive! :-(

<PotentialUser-7>How is the Codeberg experience going? Is it making life easier for the contributors, or do you prefer the mail process?

<andreas-e>kdenlive has a substitute. If updating your complete system does not work, maybe you could try "guix shell kdenlive".

<andreas-e>For Codeberg, difficult to know, since we have no good metrics. Some people are more active and enjoy it, others have refused to move over.

<andreas-e>I like the milestones; it was really useful to have a milestone for the core-packages-team merge to regroup all issues as soon as they popped up.

<PotentialUser-7>andreas-e The people who prefer the old method can continue to contribute using email, right?

<andreas-e>Yes, but if I remember well, only up to the end of the year. Some do.

<andreas-e>umanwizard: I will comment on your patch here. If you update the style of the package, it is preferred to do so in a separate, second commit (although here it is visible what changes really and what is just stylistic, because the package recipe is rather short).

<andreas-e>And it would be nice if you could document all changes in the commit message, see "git log" for templates.

<andreas-e>There are less than 500 packages depending on google-highway. I wonder if it would not be better to just update the package?

<umanwizard>that sounds fine to me

<umanwizard>btw, I'm getting some errors in dependent packages now, in particular openexr

<umanwizard>so yes, just updating google-highway might be worth trying

<andreas-e>Interestingly, it has only two directly depending packages, libjxl in two versions. So it looks like relatively low risk to update globally, for all architectures.

<andreas-e>Ah well, one failure can hide another one!

<umanwizard>actually, the openexr failure is happening even without my patch, so maybe a separate issue. it's just that libjxl depends on openexr so can't build until that is fixed.

<andreas-e>Ah, okay. But we could already try on x86.

<andreas-e>umanwizard: Sorry if I did not credit you with the patch for bdb! I just skimmed through the bug report you referenced, and it contained a patch that looked like yours.

<umanwizard>I don't care about the credit. All I did was search-and-replace :)

<fnat>There seems to be an issue building unclutter.

<fnat>It doesn't look like unclutter has been updated recently (?) so I suppose it might be a side effect of some other change?

<dariqq>oh god, I think I just found out why some of the i686 packages fail to build: gcc-13 introduced more precise floats also for cxx (casting as late as possible to not lose precision). all packages that have wrong assumptions about this are now wrong. webkitgtk has a funny static assert in one of their libraries to assert that precision is lost but his now fails .... infuriating

<umanwizard>gotta love tests that assert buggy behavior

<umanwizard>andreas-e: https://codeberg.org/guix/guix/pulls/1427

<umanwizard>Let me know if the commit message style is correct this time

<dariqq>even more infuriating: the asserts were explicitly introduced to fix rounding on i686 . but now an assert of "0.49999999999999994 + 0.5 == 1.0" fails because the + is still done as long double ond only then cast to double

<umanwizard>out of curiosity, what's your use case for i686? Just some 20+-year-old PCs you have around?

<dariqq>yes

<umanwizard>My dad has some Windows XP box collecting dust in his garage. Maybe I should try installing Guix on it :)

<dariqq>getting mate to build only involved skipping tests in 4 packages before but now the list of extra transformations i have to do has become enormous. I feel like i am commited now to keep it up to date but trying to troubleshoot this has not been fun

<tazjin>I still haven't managed to build up an intuition for what is going on with guix channels vs. nixpkgs imports

<tazjin>stuff like, why can "Computing guix derivation" happen many times for the exact same pinned commits? (e.g. between different users, or if you pin channels directly in your config with `guix-for channels`)

<tazjin>I'd expect this to trivially hit something cached in the store

<PotentialUser-7>I am trying to configure a networked laser printer (that understands PS/PDF). How do I declare it in the config.scm file?

<identity>PotentialUser-7: i would guess ‘cups-service-type’

<PotentialUser-7>identity Sure, but that seems to configure only the cups service. Where do I say what printer I have, and how to reach it?

<bdju>I finally got an upgrade to go through after skipping over 40 packages.

<PotentialUser-7>bdju How do you skip over a package (other than removing it?)

<bdju>e.g. guix package --upgrade . --do-not-upgrade={pfetch,rgbds,dolphin-emu}

<bdju>You can just keep extending the list.

<PotentialUser-7>Ohhh! Thank you.

<bdju>You're welcome.

<lilyp>dariqq: ha, fun

<lilyp>I downgraded one package to GCC 11 exactly because of this

<andreas-e>dariqq: Crazy! Everybody should follow the IEEE-754 standard nowadays. But also never compare floating point values for equality, unless IEEE-754 is ensured.

<vagrantc>yay, bdb on aarch64 seems to be fixed! now just glib-networking and i can finally update my profiels and system configuration!

<vagrantc>although, i am at a loss with glib-networking

<vagrantc> https://codeberg.org/guix/guix/issues/1377

<andreas-e>Flaky tests are annoying. Neither right nor wrong...

<vagrantc>i presume someone just lucked out and got 0 failures on (one of) the build farm(s) ?

<vagrantc>i've tried on two different systems, x86_64-linux and aarch64-linux and both have the same problem

<AidenIsik>I'm guessing the GCC version used for builds was just updated?

<vagrantc>but there is no substitute on aarch64-linux ... i think the availability of the substitute is masking the gravity of the problem

<vagrantc>AidenIsik: yup!

<vagrantc>there is not much that buidls without glib-networking :(

<AidenIsik>Figured. Earlier I tried to reconfigure and guile i686 was failing based on a missing header (updated C/C++ standard?)

<AidenIsik>What are we on now? GCC 14? 15?

<vagrantc>gcc@14 is much more picky about things

<AidenIsik>Just wait until we get GCC 15+ lol, with the bump to C23

<dariqq>lilyp: webkitgtk cant be build with an earlier gcc because something uses <fenv> which breaks if #include_next (in libstc++) does not resolve to the glibc fenv.h. I need to patch it anyways (a missing semicolon in an i686 specific code path in the current guix version) so i just removed the asserts as well

<vagrantc>debian or ubuntu usualyl get thee first, so there are often patches available to snag ... but they also don't often build ancient versions of things ...

<dariqq>it is both a blessing and a curse that guix forces one to deal with these issues immediately but increases the scope of such an update drastically because it needs to be fixed for all packages and architectures at once

<keenban>hey hey is there anyone online

<keenban>oh there is plenty of people i missed the memo it says it right there haha

<keenban>im struggling to decide if the guix way of doing things is right for me

<keenban>i have been using gentoo for some time (maybe about 6 months) and love the source based nature. i really enjoy the idea of having a declarative package managaement system all in 1 file for easy version control. however, use flags make tweaking packages much easier. i also run on a dell laptop, and im not aware of how much proprietary blobs are important to the usability of my system

<bdju>Down to only 13 packages I had to skip to get upgrades to go through, I think. Very nice work these last couple days, guix.

<identity>keenban: tweaking packages is still pretty easy with Guix (see the various package transformation options and ‘tunable?’); the installer should warn you if your hardware will not work without proprietary firmware before it makes any changes, and there are ways to get that if you really need it (-> #nonguix)

<andreas-e>bdju: Good to hear that, and thanks for your reports!

<andreas-e>I think we mainly made sure the big blockers were resolved, and mainly on x86_64 (and not at all on armhf, which nobody noticed!).

<andreas-e>We did fewer tests towards the leaves, which anyway can be solved one by one later. And very few games, I think the developers take their fun in working on Guix :)

<keenban>thank you identity

<keenban>i will look a bit more into those options

<csantosb>Ey Guix, another random question, do we have a rule to follow concerning trailing slashes in url ? Better remove or keep/add it ?

<nomike_>Hi

<andreas-e>Hello!

<andreas-e>No idea about the slashes, csantosb.

<csantosb>I remember the linter asking for it, so I understand this is the rule to follow; maybe I'm wrong

<andreas-e>You could just try the linter on both variants again :)

<csantosb>I get "permanent redirect from https://pwmt.org/projects/zathura-pdf-poppler to https://pwmt.org/projects/zathura-pdf-poppler/"

<csantosb>So I guess yes, the trailing slash is advised

<andreas-e>Looks so!

<vagrantc>andreas-e: if the release GCD is any example, we should probably pay a bit more attention to aarch64-linux than armhf-linux :P

<andreas-e>vagrantc: Indeed, and we do. The package coverage was not bad. However, the bdb failure was a biggish problem.

<andreas-e>vagrantc: Another biggish problem that we have had forever is the lack of ghc on aarch64, which prevents pandoc, which is quite important. There must be a solution, as Nix ships ghc on aarch64.

<vagrantc>seems like whenever Nix gets a hard bootstrapping problem, they just ... take the pre-bootstrapped binaries from wherever

<vagrantc>hmmm... i guess i can run an upgrade of my user profile with --without-tests=glib-networking .... let's see how that goes

<vagrantc>does guix system take that too?

<vagrantc>hrmpf. "guix build --without-tests=glib-networking" ... but "guix upgrade --without-tests=glib-networking" still runs the tests ... :(

<vagrantc>am i holding it wrong?

<vagrantc>i don't even intentionally have glib-networking as a package in my profile ... something else is using it

<umanwizard>andreas-e: you asked how long guix pull takes on my machine: Just measured it: 12m41

<vagrantc>and "guix system" does not accept --without-tests

<andreas-e>vagrantc: But I thought we also took pre-bootstrapped binaries for ghc on x86? There may be a reasonable compromise there.

<andreas-e>umanwizard: Thanks for the timing! That was with compiling everything from scratch, I suppose? Or did it involve substitutes?

<umanwizard>that's just guix pull, not a full system reconfigure...

<umanwizard>andreas-e: here's the log so you can see what it's doing. https://pastebin.com/Wy2XEq4M

<umanwizard>It's in German, but because of your name, I suspect you can understand that :)

<andreas-e>Thanks, no substitutes. And without additional channels, it would even be a bit faster, but I suppose that most of the time is spent with the guix channel.

<vagrantc>andreas-e: ah, right. ghc's bootstrap binaries is one of the dark dirty "secrets" of guix and the full source bootstrap. :)

<andreas-e>Hehe. But we still start very low and bootstrap a lot of ghc versions one after the other... I do not know if the same would be possible on aarch64.

<nomike_>I've got a clone of guix, pulled the latest commit, but when I open a `guix shell` and run `make clean && ./configure && make` it fails with an error when compiling russian translations. I guess that's not an issue on my end but an issue with what's currently in the repo, isn't it? https://paste.debian.net/1386927/

<andreas-e>nomike: When there are problems with translations, I usually run ./bootstrap.

<nomike>Thx, I will try that.

<nomike>Didn't help unfortunately.

<Noisytoot><vagrantc> seems like whenever Nix gets a hard bootstrapping problem, they just ... take the pre-bootstrapped binaries from wherever

<Noisytoot>This is also Guix's solution to ghc's bootstrapping problem on x86

<Noisytoot>Doing it on ARM isn't any worse

<Noisytoot>How come there's an exception for GHC but not for GNAT?

<Noisytoot>GNAT is important as it's required to build coreboot (specifically libgfxinit), which is required for a fully free system

<vagrantc>Noisytoot: yeah, andreas-e pointed out it is done for x86

<vagrantc>Noisytoot: my guess is the bootstrap binaries aren't taken lightly (and GHC has been in guix for a long time) ... but feel free to propose a fix

<vagrantc>Noisytoot: for GNAT that is ...

<vagrantc>not sure what the process is like for new bootstrap binaries for new languages ... obviously if it is bootstrappable from source that is ideal.

<nomike>andreas-e, I tried with a fresh clone of the repo, there it seems to work. I just need to figure out how to properly clean the one I'm using..

<nomike>But I think I should wait until the build is fully complete. It looks like the part where it fails has already passed, but I'm not sure.

<andreas-e>nomike: Good to hear, good luck!

<nomike>thx

<rkazak>Hi, has anyone got guile-emacs to install successfully? I am seeing issues :(

IRC channel logs

2025-07-20.log