IRC channel logs

<vagrantc>lechner: the mnt/reform flks gnerate debian packages by having the full history and generating a patchset to import into the kernel packaging ... but they are not limited by guix's build environment

<PuercoPop>sham1: doas guix pull _is_ running guix as root

<PuercoPop>what I mostly care is understanding why guix describe and doas guix describe can point to different versions of the same channels (and consequently need to be updated separately)

<vagrantc>PuercoPop: a root user can run the guix produced by a given user

<vagrantc>when that user runs guix pull ...

<sham1>PuercoPop: that it's being run as UID 0 doesn't matter

<sham1>Anyway, guix-service-type lets you specify channels, including pinning their commits

<sham1>That's system-wide, and then there's also the one that allows you to do that with Guix Home specifically

<guix-newbie>Has anyone attempted to package qylock before?

<rgarcia>hi! do I have to "guix system reconfigure" as root?

<rgarcia>nevermind. The answer is "yes", it says so in the manual.

<flurando>sorry guys, the polkit issue I described yestterday is not reproducible, I haved closed the codeberg issue.

<flurando>It must be some problem with my own config, as I just run my whole config in vm, same faulty behaviour.

<flurando>uh, the problem is in my yubikey setup. But the hard part is my yubikey service just add a line in every pam with sufficient and put pam-u2f in system profile, along with udev rule for fido2 and pcscd service, how could that break everything suddenly?

<switchy>are there auth logs from pam?

<lechner>There are in Guile-PAM. https://juix.org/manuals/guile-pam.html

<flurando>switchy: that mainly says pam_u2f could not restore permission blablabla, the strange thing to me is that I only add an `auth sufficient .....` line for pam_u2f.so, then every auth attempt breaks, including a 700 /var/log/sudo. the pam lines used to work months ago and I have been using that since 2024 or 2025, it is frustrating to find a personally written part breaks when updating the main channel.

<flurando>the line my service added to every pam file look like this: auth sufficient /gnu/store/s01p7mw8pj9vjzx18p4pfyn693b34pvb-pam-u2f-1.4.0/lib/security/pam_u2f.so openasuser cue pinverification=1

<flurando>any idea why this does not work now, and effectively breaking any auth attempt, is it because of some pam update that bring in new security model?

<lechner>Are you sure the PAM line is working? The pam_u2f.so module could depend on a library that can't be found or a similar error, thereby causing all authentication to fail. You can use readelf -d on the module. It should show prerequisites under NEEDED.

<flurando>Of course, I've used it for at least half a year

<lechner>Same store path?

<lechner>ldd will dive deeper

<flurando>lechner: the store path is not hard coded, it is generated from package output.

<flurando>I am suspecting if it is openasuser, which as documented on pam_u2f, uses setuid to "become" the user temperarily, and maybe setuid is banned by pam after recent update?

<lechner>Yes, but a different store path would indicate an updated module, which could be defective.

<lechner>How could it be banned?

<flurando>pam_u2f has not updated in guix, because guix locate pam_u2f.so only returns a single entry

<cqst>after I recently updated guix, "mosh" is broken, it takes forever to connect, and when it does I get this error spammed repeatedly in my terminal

<cqst>/home/cqst/.profile: line 3: /home/cqst/.guix-home/on-first-login: Argument list too long

<flurando>the setuid to user is the most possible cause here, because my /var/log/secure says that pam_u2f could not restore permission, so something must have changed in pam recently

<lechner>Pam_u2f.so accepts a debug argument

<cqst>I'm using guix system

<cqst>using regular ssh works just fine

<flurando>lechner: yes, I would try different lines by forking my service writing later today

<lechner>flurando: Are you seeing a recent update to Linux-PAM?

<flurando>no, just suspecting, because in July my setup works, now it don't, I didn't change my yubikey service, so of course pam in guix channel changed something, unconciously break my pam lines.

<lechner>I don't see how setuid could be banned in Linux-PAM.

<lechner>Plus, I also use setuid to assume user privileges in PAM.

<lechner>Does password login work?

<flurando>any auth attempt logged in /var/log/secure fails, including sudo:auth and polkit:auth

<flurando>any it only happens when I activate my yubikey service, which despite add a harmless pam-u2f to system package profile, add the said lines to all pam files

<flurando>this is the failure log: https://paste.debian.net/hidden/96fbfe8a

<flurando>would have classes soon, so bye everyone, would check the channel log later.

<psycotica0>PuercoPop: Yes, you're correct. Guix doesn't have a repo or config or anything like that, it fetches the channels and then builds that config, as code, into the guix executable. And then when you run `guix install` or `guix search` it's using the in-memory "hard-coded" package descriptions. So the reason your two invocations of `guix describe` are different is because the binaries are different. `which gu

<psycotica0>ix` and `sudo which guix` will point at different binaries, which were built by different code, and thus will have different package definitions, unless you specifically point them at your binary, like `sudo $(which guix) describe`. I think

<psycotica0>But the reason everyone's talking around the issue is because there's not really an expectation that you'll actually _use_ `sudo guix` for anything. So you don't really have to keep it up to date, because it's not used by most people.

<psycotica0>There _used_ to be a time when on a foreign distro the build-service used the root's guix code... and maybe that's still true, but even then that only needs to be updated when something changes substantially enough that the build daemon needs to be refreshed, which is not as common as normal package definitions changing. That's more of a "breaking change" kind of change. In which case you might need to `s

<psycotica0>udo guix pull` and then restart the build daemon.

<psycotica0>And in general, I believe that if you wanted to install system-level daemons or something, then I suppose you would use `sudo guix install` for that, but it's much clearer in that headspace that you really are installing *for the user who is the root user*, and not just "installing with priviledges", and so just like with any two users on one system, they manage their guix pulls themselves. It just so hap

<psycotica0>pens you are both your user, and the root user sometimes, if you're an admin

<lechner>sneek / later tell flurando / I think this is your error: pam_modutil_regain_priv: setgroups failed: Operation not permitted

<sneek>Will do.

<lechner>Sneek / later ask flurando / Also, that module accepts both the debug and the debug_file options. Did you enable them?

<sneek>Got it.

<sham1>Using Guix on a foreign distro is pretty much the same as using Nix on a foreign distro. You don't need to really do much as root for the latter either

<charlesroelli>The info node `(guix)Upgrading Guix' recommends "sudo -i guix pull" for upgrading the build daemon on a foreign distro.

<flurando>hi, I solved the pam_u2f could not regain privileged after dropping problem partially by using /etc root only as a walkaround, the problem still exists, that util.c in pam-u2f could not restore privilege, maybe I shall open an issue there.

<sneek>flurando, you have 2 messages!

<sneek>flurando, lechner says: / I think this is your error: pam_modutil_regain_priv: setgroups failed: Operation not permitted

<sneek>flurando, lechner says: / Also, that module accepts both the debug and the debug_file options. Did you enable them?

<flurando>lechner: thanks for suggesting, I have figured how to not dropping privilege at all to walkaround could not restore problem.

<dariqq>flurando: Could you try without the no-setfsuid patch?

<flurando>Unfortunately, I do not have the ability to fix the problem or exactly tell what is happening in util.c of pam_u2f.so. Would open an issue in Yubico's pam-u2f repo later when I have time.

<flurando>dariqq: what patch? I don't know, is that a patch for pam-u2f?

<flurando>I didn't use any patch, I just extend etc service to have a authfile and use authfile to point to it, as well as emitting the openasuser label, thus pam-u2f would not try to read as user any more.

<dariqq>flurando: No, that is a patch in the guix linux-pam (and is currently buggy because the setfsuid path is now always disabled)

<jlicht>hey guix

<dariqq>i found an issue for debian for a similar error and it pointed to the patch

<dariqq>you will need to recompile everything depending on pam for this

<flurando>dariqq: thanks for explaination, but I want to leave that for the guix team maintaining pam instead of digging deeper myself. However, I do wonder if the restore privilege fails only for pam-u2f, or it just fails for any pam module that goes the drop+restore path.

<orahcio>Hi jlicht, how are you? I want to know a little more about the javascript team

<dariqq>flurando: See https://github.com/linux-pam/linux-pam/pull/917.

<gkoebel-ext>hi again, still confused as to why pinentry is borked on my system. It seems that somewhere the loopback setting is being ignored.

<gkoebel-ext>ask and you shall find it. I think its bad store paths coming back to fight me again

<dariqq>flurando: and https://github.com/Yubico/pam-u2f/issues/343

<jlicht>orahcio: hi! I'm (still) in a French chalet, so will get back to your pings somewhere next week :-)

<jlicht>orahcio: if you'd be interested in joining the javascript team, even better!

<gkoebel-ext>okay so my `pinentry-program` line in gpg-agent.conf is wrong it has a path to an old store and an appended path to the symlinked store for my profile. Not sure how I override that line so it just gets the correct path?

<dariqq>also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095194

<orahcio>Tahnks jlicht, I have a plan to package bokehjs, and maybe jupyterlab. The initial motivation was python-bokeh and python-jupyter packages from python team. But I can join to javascript team for these projects

<gkoebel-ext>So `(pinentry-program (file-append pinentry "/home/gkoebel/.guix-profile/bin/pinentry"))` is what I'm using in my home config and it is wrong as this yields a gpg-agent.conf that has an incorrect path butted up against the path I'm trying to use (the one in ""'s).

<lechner>gkoebel-ext: I'd remove the file-append and the first pinentry

<stampede_>gkoebel-ext: the `pinentry` there resolves to the store directory of the pinenetry package

<lechner>Yeah, its a bogus path

<stampede_>so file-append will make it `/gnu/store/[hash]-pinentry/home/gkoebel ...`

<guix-newbie>IIRC that is the documented example that they are using.

<stampede_>just use (file-append pinentry "/bin/pinentry-gtk2") cuz i think `pinentry` package provides the gtk2 ui

<gkoebel-ext>lechner: what's the proper way to give it a "file-like" arg? Just removing it is invali

<gkoebel-ext>I think I got that example from the manual but now can't find where

<guix-newbie>I was struggling with pinentry 2 days ago too, until I switched over to mango and magically it just worked...

<stampede_>guix-newbie: no it isn't, the example was (file-append pinentry-emacs "/bin/pinentry-emacs")

<guix-newbie>Yes that

<stampede_>at least that's what i find in the manual

<guix-newbie>But it also uses your (file-append pinentry-<type> ..)

<guix-newbie>Or the one you said to not use

<gkoebel-ext>stampede_ using your example will just give me a different invalid path based on current evidence since it will just append /bin/pinentry-gtk2 to the invalid store path

<guix-newbie>what desktop are you using?

<gkoebel-ext>KDE Plasma, but I don't need GUI pinentry working I'm trying to get the cli version to work

<lechner>According to the EasyPG manual emacs-pinentry is insecure and outdated

<gkoebel-ext>iirc the base pinentry package will spawn a GUI anyway since it did work exactly once

<guix-newbie>Because with sddm+kwallet+pinentry-qt+gpg-agent+hyprland <- not working, replaced hyplrand with mango (same config)and it just works

<guix-newbie>try pinentry-qt

<guix-newbie>(pinentry-program (file-append pinentry-qt "/bin/pinentry-qt"))

<guix-newbie>works for me

<gkoebel-ext>I'm not sure I'm being clear here. The paths are being mushed together

<gkoebel-ext>like pinentry-program /gnu/store/friygda4jav31w9lgz07a7kj23vy8inn-pinentry-1.3.3/home/gkoebel/.guix-profile/bin/pinentry looks to me that is mushed the location of one binary into the provided path I gave it instead of just taking my string as the path.

<guix-newbie>what does your whole config look like for that bit?

<gkoebel-ext>So if I swap that for literally anything else its just going to stick it on the end

<guix-newbie>Because that looks weird

<guix-newbie>Also, you may need to enable kwallet

<gkoebel-ext>That's from gpg-agent.conf

<guix-newbie>;; TODO: consider integrating service in `<plasma-desktop-configuration>' as

<guix-newbie>;; done in `<gnome-desktop-configuration>'. This requires rewritting the

<guix-newbie>;; `<plasma-desktop-service-type>' as done for `<gnome-desktop-service-type>'.

<gkoebel-ext>kwallet depends on pinentry working not the other way round

<guix-newbie>right

<guix-newbie>that snippet is from kwallet

<stampede_>gkoebel-ext: https://paste.debian.net/hidden/e61f5a11

<guix-newbie>:s/snippet/kwallet

<gkoebel-ext>and I'm not trying to fix plasma I'm trying to fix pinentry

<stampede_>try this in your guix repl

<guix-newbie>we get that

<guix-newbie>do what stamped did

<guix-newbie>in repl

<gkoebel-ext>stampede_ ,use (guix) is not a valid command according to my repl

<gkoebel-ext>oh wait it was just really late processing a ctrl-c

<guix-newbie>Also, have I been suffering with (use-modules (bla)) while I could have used ,

<guix-newbie>ffs

<gkoebel-ext>So yeah running that matches everything except the hash

<stampede_>well it should be normal to use then in your home config

<gkoebel-ext>no

<gkoebel-ext>again its just mushing a bad path together with the provided path

<stampede_>(btw side note, if you are using pinentry-gtk2 or -gnome3, make sure to also install gcr@3, they need it)

<gkoebel-ext>`/gnu/store/friygda4jav31w9lgz07a7kj23vy8inn-pinentry-1.3.3/bin/pinentry-gtk2`

<stampede_>great

<stampede_>this should work

<stampede_>this is correct

<gkoebel-ext>No

<guix-newbie>why use the gtk bit when you are in kde? why not just use pinenetry-qt

<gkoebel-ext>it is not

<guix-newbie>why is it not?

<stampede_>so you are saying the hash is wrong in the first place?

<gkoebel-ext>that entire leading bit before /bin is not a valid store path

<guix-newbie>oh

<stampede_>can you cd to that store path?

<stampede_>and btw what does running home reconfigure with that in there show?

<stampede_>what error

<gkoebel-ext>or maybe I stand corrected it is a valid store path. I had a similiar issue before where pkg-config was using the store paths instead of the symlinked user profile so assumed it was the same here

<gkoebel-ext>stampede_ the error I get is when I try to use any program except gpg itself that needs to activate pinentry

<gkoebel-ext>i.e. git signing

<gkoebel-ext>and I get `gpg: signing failed: no pinentry`

<gkoebel-ext>hmmm. On windows git ships its own gpg... I wonder if that's the issue

<gkoebel-ext>I also assumed a guix git would use the system gpg.

<stampede_>hmm install gcr@3

<stampede_>add it to your config

<stampede_>this was a point of headache for me

<stampede_>because pinentry-qt works, but i couldn't get gnome3 or gtk2 to work ever, but it just turned out that they need gcr@3 to show the prompt, otherwise they fail

<stampede_>honestly i should just PR a change to add gcr@3 to their propagated0-inputs

<guix-newbie>Sanest solution imo stampede_

<stampede_>yeah, the packages are unusable without it

<guix-newbie>since we are speaking about PR's, what are the exact requirements for a PR to guix?

<gkoebel-ext>well it wasn't the git gpg program setting

<guix-newbie>I found out yesterday you cannot install mpv when having lua installed with home-profile-service-type

<gkoebel-ext>I actually can't install gcr evidentally there are conflicts

<guix-newbie>with?

<gkoebel-ext>conflicting entries for glib

<guix-newbie>huh

<guix-newbie>Interesting

<stampede_>guix-newbie: i'm not sure this would be my first, but there should be a contributing.md file to check

<guix-newbie>I will look it up, ty!

<stampede_>gkoebel-ext: hmm i have glib:bin but it isn't showing any conflicts

<stampede_>can you try pinentry-qt for now? (file-append pinentry-qt "/bin/pinentry-qt")

<stampede_>at least to get things working then try to figure out this conflict issue later

<gkoebel-ext>its a conflict with remina they pull the same version tho

<gkoebel-ext>it'll probably clear when I upgrade

<gkoebel-ext>stampede_ I am almost certain it is not because of the pinentry version its must be some problem with how things are calling it in loopback

<gkoebel-ext>like I can use gpg and get a loopback pinentry. No other program can

<gkoebel-ext>guix-newbie: if you're also on Plasma, have you had issues with your machine never fully shutting down or never finishing a restart?

<gkoebel-ext>I don't think its an issue from Plasma but may as well rule it out

<jonsger>Is someone using JOSM (Java OpenStreetMap editor)? Because for me with GNOME the mouse pointer is a bit off while hovering menu entries :(

<untrusem>jonsger: I use josm

<untrusem>but don't use a DE but niri window manager

<cbaines>jonsger, I use it, I find it's worse when fullscreen, often if you don't have it fullscreen and move the window a bit, things line up at least for a short while

<guix-newbie>gkoebel-ext: just came back after a short break, I am not on plasma. I did mention I was on mango :)

<guix-newbie>and how are you shutting down your computer?

<gkoebel-ext>guix-newbie by running `shutdown` or via the GUI. makes no difference

<gkoebel-ext>I have to unplug it before I am able to startup agian

<guix-newbie>very strange.. did you check the logs from previous reboot and see what was preventing it from rebooting?

<guix-newbie>Not sure but they should reside inside /var/log/*

<guix-newbie>(I am also new here btw, got here 1 or 2 weeks ago, so I am missing some commands in my head)

<jonsger>cbaines: ah thanks for the tip. The window moving helps :)

<untrusem>josm, please a good ui

<untrusem>I want nothing more :g

<untrusem>jonsger: btw I have wip pr on updating josm, if you feel free to take it

<juli>Hey folks. I've just noticed that bash's builtin `command -p` doesn't work properly on Guix and started working on a fix. Does anyone know whether that fix should change the bash-defined STANDARD_UTILS_PATH or should it instead patch glibc's confstr?

<dariqq>juli: There is a patch to add /run/current-system/profile/bin to CS_PATH on a branch

<juli>Which branch?

<juli>I need this for work; when do you expect that to land?

<dariqq>it is here, https://codeberg.org/guix/guix/pulls/1219, its glibc so probably forever

<juli>Looks like it's been merged into `core-packages-team` so it should land with the 1.5.0 release at the latest

<juli>er

<juli>next installer release rather

<Rutherther>why do you think so?

<Rutherther>core packages isn't even in the queue

<Rutherther>it's not going to be in the release...

<juli>I assumed that was the checkpoint at which we would update core packages.

<juli>...why are we cutting an installer release if we're not updating core packages with it?

<Rutherther>the gcd lists the motivation as far as I remember

<Rutherther>it would be hard to coordinate the release with such changes, and they take so much time, the release could be postponed by a year if it was just waiting for that...

<Rutherther>there is not just core packages, there's a lot of software with security holes and so on. And new software added that could possibly be added to the installer and so on

<juli>I should have paid more attention to this GCD. Given that core packages are potential limitations on how far literally any other package can be updated (a problem I have run into more than once), it seems pointless to have regular releases if those releases don't actually indicate a more up-to-date base system.

<alteregon>o/

<juli>The GCD doesn't mention any specific team's packages; it leaves the decision of what package sets there are and what constitutes those sets up to the release team (if I'm reading this correctly)

<Rutherther>the release process even has some side effects beyond the release. It forces to fix the installer, source tarball generation and so on. For example right now the guix system installer has been broken for months

<Rutherther>right, the package sets aren't about the packages being up to date though, they are just about the packages building

<juli>True.

<dariqq>juli: As a workaround you could use a patched bash (but I dont quite see the use case of a trusted PATH when it is easy to override with a custom bash)

<juli>The usecase is the Node ecosystem is a crime against humanity.

<juli>sorry, that was an unhelpful bit of snark... one of the tools I use at work relies on a shell script that uses `command -p` to avoid other npm packages injecting malicious tools into PATH

<juli>Do we have any criteria for when `core-package-team` is merged?

<cbaines>the release process isn't really relevant here

<cbaines>the process for handling large changes/branches is broken at the moment since it hasn't been updated since the switch to Codeberg

<Rutherther>it is relevant only with the freezes - during the freeze it cannot be merged

<Rutherther>that pretty much means that we can say core-packages won't be merged till December

<cbaines>the world-rebuild branch is expected to be merged shortly, so it's not like changes that impact lots of packages can't be merged

<dariqq>but these potentially malicious packages can run arbitrary code anyway?

<juli>Idk dude I just work here

<juli>;)

<lonely_ghost>alien film great citation

<cbaines>the commit looks like it is on the core-packages-team branch, and that branch still looks active, but if it had gone to the world-rebuild branch created a few months ago, it could have been merged sooner

<juli>Yeah that makes sense

<attila_lendvai>the CS_PATH commit uses /run/current-system/ but shouldn't such places use /run/booted-system/ instead?

<juli>No, because the user may have run a `guix system reconfigure` since booting.

<haugh>Hey folks. I'm doing a no-substitutes pull on a system that hasn't been updated in a long time and it appears to be hanging on the guile package build. How long should I let this run before giving up?

<sham1>1) You knew what you got yourself into when you passed --no-substitutes. 2) You could look at the process list and see if stuff is doing IO, consuming CPU cycles or just waiting for something

IRC channel logs

2026-10-14.log