<bumble[m]>I tried to guix pull and guix system reconfigure today but am seeing a new error today that was not there before `error: "swaylock" invalid field specifier` would anyone here happen to have any solutions to suggest?
<isf>i open gnome-disks for open a hard drive automathically but just do it for super user, as I need sudo -E to run it, I want to access to the hard drive with simbolic links. Someone know how to do this better?
<zamfofex>Is it just me or do “bare” freedesktop.org GitLab URLs not work wit Git anymore? I get error 500 for e.g. wlroots. It seems adding a ‘.git’ suffix to the URL fixes it.
<efraim>janneke: I don't know a lot about the python test suite, but I believe it runs twice, in your 177/401/4. it would be 177 passed of 401 (with the others not yet run), with 4 failed. I think it runs concurrently 1 test per core
<atuin>I am trying to debug this error when using nix-daemon service: `opening pseudoterminal master: No such device` when running `nix-channel --update`. Seems that the problem is that devpts is not mounted in the mnt ns. Who creates that ns, make-forkexec-constructor?
<atuin>also restarting the daemon with herd seems to fix the issue
<atuin>After restarting the daemon the devpts fs is mounted, could it be a race condition_
<atuin>after computing the deps graph seems that nix-daemon has no dependencies, similar to iptables and others, that could be the cause indeed
<evilsetg[m]>Is anybody else having problems with swaylock? After the latest reconfigure I get following error:
<evilsetg[m]>`[source/pam.c:17] swaylock is setuid, but was compiled with the PAM backend. Run 'chmod a-s swaylock' to fix. Aborting.`
<tlecarrour>Hi Guix! Before spamming `help-guix`, I wanted to take my chances here… anyone running into `In procedure canonicalize-path: No such file or directory` when running a container built with `guix system container`?
<jpoiret>evilsetg[m]: you now need to use the screen-locker-service-type with (using-setuid? #f)
<jpoiret>the manual has been updated to reflect this change
<jpoiret>tlecarrour: do you have a minimal working example of this?
<jpoiret>what's weird is that I couldn't reproduce with my checkout
<jpoiret>evilsetg[m]: how did you send your patch? it doesn't apply, and it seems that the whitespace has been replaced by nonbreaking space
<bjc>speaking of service ordering, can anyone look at #62726? it moves setuid-program activation into shepherd so it can be ordered properly. currently, things like wireshark don't work because the ordering between group and setuid activation is undefined
<attila_lendvai>pulled master just now, but it fails with "In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f", while compiling guix-system-tests.drv
<chomwitt>In config.scm trying to provide options to an ext4 fs mount (options "rw,relatime,nofail 0 2") the filesystem wont get mounted and i see in dmesg [ 41.928441] ext4: Unknown parameter 'relatime'
<chomwitt>i see that message after many attempts of shepherd shepherd: Service file-system-/home/chomwitt/MyCalibreLibrary-SSD failed to start.
<chomwitt>strangely if i dont supply any options then the 'defaults' will be added to my fstad and the filesystem will be mounted ok with rw,relatime
<jpoiret>bjc: haven't taken time to reply to it, but here's one blocker for it: nothing depends on the shepherd service
<jpoiret>so you can't guarantee that eg. login is available setuid
<jpoiret>ah, maybe login uses PAM, but the point stands
<jpoiret>we'd have to make a careful review of what services depend on setuid programs being available
<bjc>jpoiret: yeah, the lack of dependents occurred to me, too, but i didn't see anything in ‘/run/setuid-programs’ that wasn't meant for interactive use. doesn't mean i'm not missing something obviously
<jpoiret>even if they're for interactive use, we have to make sure they're available before the user is able to interact with the system
<bjc>that's relatively easy, right, by making user-homes dependent?
<jpoiret>i'm not sure that's the right synchronization point
<jpoiret>also, you might have looked at your own setuid-programs directory, but not all of the ones provided by Guix, right?
<jpoiret>i see at least some dbus stuff on mine, so I would expect the dbus service to be impacted
<jpoiret>eg. people with autologin or with complicated DMs like GDM would have problems I think
<jpoiret>rekado, tlecarrour, attila_lendvai: just pushed a fix
<jpoiret>if only we had static typing to prevent easy mistakes like this
<bjc>jpoiret: yeah, i didn't do a thorough audit of all setuid-programs. it didn't even occur to me, tbh
<bjc>the “right thing” would be to have each service that needs it be dependent on it, rather than a single synchronization point
<jpoiret>yeah. Still don't know about ensuring they're available for interactive use though
<bjc>it doesn't look like there's too many, less than 12. i'll see about modifying them
<jpoiret>maybe adding it to each DM/login process is possible, but it's quite annoying and prone to forgetting
<bjc>well, one of them is ‘pam-root-service-type’, so that should cover the greeter bases
<jpoiret>greeters are not the only dependents of pam though
<bjc>i don't think i'm understanding you. if pam requires setuid-activation, then anything that requires pam would, as well
<bjc>i'm not suggesting only changing pam, just mentioning that adjusting pam would allow greeters to work in a better defined fashion
<jpoiret>pam doesn't require setuid-activation, it's orthogonal afaik. What I mentioned before with login was maybe imprecise
<bjc>pam does require it, though, for ‘sbin/unix_chkpwd’
<jpoiret>ah, right. Still, I have the feeling that using only this dependency to ensure setuid-programs are setup for user interaction will be flaky
<evilsetg[m]>jpoiret: I resent the patch again via git send-email. Is it possible to apply it now?
<jpoiret>evilsetg[m]: It does! Although, note that you shouldn't modify anything above the -- line, as that will be part of the commit message (except for the automatically inserted From:)
<bjc>jpoiret: the main problem is the dependency graph is under-specified. i'm not sure how to fix that for everything in one patch. we *can* fix it for (hopefully) everything that has a shepherd service (such as pam), which covers a lot of uses. the rest will have to be done as they're discovered, i think
<bjc>but having setuid activation itself be underspecified is also a problem, as evidenced with wireshark
<jpoiret>in general you should follow the ChangeLog format to write commit messages, also make sure to capitalize the patch title. Other than than, seems good, i will apply it :)
<jpoiret>bjc: yes, that's the main problem. I'm not against the idea of the patch at all, but I'm trying to anticipate the problems that it could cause
<jpoiret>we're working backwards by trying to untangle the dependency graph unfortunately
<William[m]>how would you set an env var with guix shell? I tried a (setenv "HELLO" "world") after set-paths phase, but that didn't work. I'd like to run "guix shell" and be able to echo $HELLO in a shell. could someone point me in the right direction?
<bjc>jpoiret: yeah, it's tricky. but thanks for the feedback; i can at least go through the existing setuid extensions and fix what i find there
<cbaines>jpoiret, regarding your earlier question about qa.guix.gnu.org processing branches, it looks at guix-patches issues