IRC channel logs


back to list of logs

<sneek>wb rekado :D
<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?
<bumble[m]>the config used here brings swaylock using the wm module... (full message at <>)
<bumble[m]>this line guix reports an invalid specifier is the line is this one,... (full message at <>)
<bumble[m]>thanks in advance for any recommendation or advice anyone may have
<ChocolettePalett>Your config differs with the one provided over there:
<ChocolettePalett>It's Xorg configuration though, not Wayland...
<ChocolettePalett>I assume that specifying field names is mandatory, e.g. instead of "swaylock" you should write (name "swaylock").
<ChocolettePalett>Oh, there is an example config for swaylock:
<bumble[m]>@ChocolettePalette ah thank you
<bumble[m]>maybe the interface changed
<bumble[m]>reconfigure seems to be working now
<bumble[m]>when the swaylock pam setuid issues popped up a week or two ago, I tried using this newer interface but would get reconfigure errors
<bumble[m]>and maybe I needed to pull and update one time before using the newer interface and updating again
<bumble[m]>thank you go to reboot now to try it out :)
<bumble[m]>it works using the new interface but I wish this boilerplate weren't needed --copied from message someone left in this channel a few weeks ago,... (full message at <>)
<bumble[m]>I tried removing this and the result was that swaylock wouldn't run and the pam setuid error would be returned instead
<isf>hello, how I can run gnome-disks as super user? when I try it dont find it even when I have it installed as root too
<mirai>isf: does 'sudo -E …' work?
<isf>works mirai thanks
<Mari[m]>how do i add udev rules to guix
<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?
<lilyp>Mari[m]: using udev-rules-service
<Mari[m]><lilyp> "Mari: using udev-rules-service" <- how would i add the udev rules using that?
<Mari[m]>there's no package for the ones i want
<Mari[m]>this is the one i want to add
<lilyp>you can try and see whether they are in our dolphin-emu package; if so, you can use dolphin-emu
<lilyp>if not, you have to roll your own package based on copy-build-system
<lilyp>gtg, cheers
<Mari[m]>problem is the dolphin package for guix is broken
<Mari[m]>whenever i try to install it, it fails
<Mari[m]>nvm i got what i needed working
<zamfofex>Is it just me or do “bare” 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
<janneke>efraim: ok, thanks
<ChocolettePalett>I assume there is a correlation between the number of cores and the number of failures
<panosalevro>I get `commit ... lacks a signature` when I try `guix pull`
<futurile>morning Guixers
<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?
<evilsetg[m]>Ah, okay. Thank you!
<tlecarrour>hi jpoiret… can I paste it here?
<jpoiret>if it's long you can use
<tlecarrour>jpoiret: I was looking for a paste instance! Thanks for the link! …
<tlecarrour>jpoiret: actually, I had to add `(service syslog-service-type) (service nscd-service-type)` this moring. It used to work without them.
<jpoiret>huh, why do i need to download linux-libre for this 🤔
<tlecarrour>jpoiret: hope you're not asking **me**! 😅
<jpoiret>aha no, just my own ramblings
<jpoiret>huh, can't reproduce myself. Do you have the full backtrace, or preferably even the full log?
<jpoiret>tlecarrour: can you find out what file /gnu/store/bp029p543bvsprbnz2v0p33 is and paste it?
<tlecarrour>jpoiret: no exact match, but /gnu/store/bp029p543bvsprbnz2v0p33yf1n8k8yk-system, which contains `activate boot etc kernel locale profile`
<jpoiret>looking at it right now
<jpoiret>how old is your guix?
<HiltonChain[m]>atuin: You seem experiencing <>
<HiltonChain[m]>This patchset might help you <>
<jpoiret>HiltonChain[m]: it might be because shepherd now starts services in parallel
<chomwitt>if i edit my /etc/fstab to add some options that i dont have in my /etc/config.scm could or will guix on reboot overwrite fstab values with those in config.scm ?
<jpoiret>civodul: huh, isn't the bug you reported this morning *really* bad?
<jpoiret>chomwitt: yes, you should add the devices in /etc/config.scm
<jpoiret>tlecarrour: what's your `guix describe`?
<tlecarrour>jpoiret: depends on what you mean by "old" ! I installed it 4 years ago (no full reinstall since then) but updated (pull & reconfigure) it this morning!
<jpoiret>aha, this morning!
<jpoiret>i'm thinking it might be related to
<tlecarrour>jpoiret: yes, sorry, I'm one of "those" people who updates weekly! 😅
<jpoiret>but for activation snippets
<jpoiret>oh no, it's good!
<jpoiret>i just end up spending more time using my git checkout that the guix pull'd guix so I always forget to update
<chomwitt>jpoiret, i added all the devices in config.scm . but i just tweaked some minor options to a certain filesystem but i noticed on reboot that fstab is again as before.
<jpoiret>you need to add these options to the config.scm in any case, fstab is generated from it and changes to it on disk will not persist
<chomwitt>jpoiret, ok. thanks for the confirmation.
<jpoiret>tlecarrour: let me try with a fresher guix if I can reproduce
<tlecarrour>jpoiret: 🤞
<evilsetg[m]>jpoiret: I think there is a small typo in the swaylock example for screen-locker-service-type. The example for swaylock uses the xlock executable. Here is a patch to fix that:
<jpoiret>cbaines: reading your patch about the branch workflow and QA, how does one register a branch for QA?
<civodul>jpoiret: it is; working on it
<civodul>ACTION would love to master his agenda
<jpoiret>lmk if you need help
<jpoiret>today is the swedish national holiday, so I have time :)
<civodul>neat, thanks :-)
<civodul>it's due to the recent innocent-looking change in 'modify-services'
<civodul>modify-services would no longer preserve service order
<jpoiret>tlecarrour: can you run`guix gc -R "$(readlink -f /gnu/store/bp029p543bvsprbnz2v0p33yf1n8k8yk-system/activate)" | grep .scm | xargs tar cvzf /tmp/archive.tar.xz` and send /tmp/archive.tar.xz somehow?
<jpoiret>this basically creates an archive with all the .scm files the activate script depends on
<jpoiret>i'm thinking there might be an ordering problem with the activation scripts
<civodul>i ended up rewriting modify-services like this:
<jpoiret>civodul: looks very nice
<jpoiret>i always feel bad about using multiple reverses
<tlecarrour>jpoiret: can you access this?
<jpoiret>yes, thanks!
<jpoiret>although I think it's the same bug that civodul is fixing :)
<jpoiret>ah, no, I might be wrong here
<jpoiret>evilsetg[m]: thanks, i'll look into it later
<tlecarrour>jpoiret: can I blame it on civodul then?! 😁
<jpoiret>not yet! and it's not even his code :p
<tlecarrour>too bad! … by the way, thanks for your time and help! swedish national holiday or not! 😉
<jpoiret>can you also paste the script that `guix system container ...` gives you?
<civodul>hey tlecarrour! :-)
<tlecarrour>content of `/gnu/store/3hphg5a74g3vzp0r2l4psma1whczdq5n-run-container`:
<tlecarrour>hi civodul! 😁
<jpoiret>yeah, so it's definitely the same bug: the activation-service-type's extension to boot-service-type is ordered after shepherd's, meaning that shepherd boots before the activation script runs
<jpoiret>so /run/current-system is never properly symlinked, hence the error
<civodul>i'll push a fix in a moment
<civodul>the issue of ordering totally escaped me when i reviewed that code
<civodul>jpoiret, tlecarrour: lemme know if it fixes your problems, whatever they are! :-)
<janneke>ACTION wonders if they suffered about this too --
<janneke>"check for stale shepherd socket and remove it"
<jpoiret>it's a shame we depend on the ordering of the service extensions
<jpoiret>thanks for taking care of it!
<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
<attila_lendvai>ACTION pings civodul 
<evilsetg[m]>jpoiret: Hmm, I used `git send-email -1 -a --base=auto` and copied the output from the terminal into icedove.
<tlecarrour>civodul: I pulled the latest version… and… `guix pull: error: build of `/gnu/store/lcl2pvk4rw6b3rkg76sxc8yckvm1qf1k-profile.drv' failed`! 😱
<tlecarrour>`gnu/services.scm:348:48: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f`
<tlecarrour>somewhere in `In gnu/services.scm: 348:48 0 (_ (#<service-type mingetty 7fffe0d70680> #<procedure 7fffdc904fa0 at ice-9/eval.scm:333:13 (a)> ((filename . "gnu/tests/desktop.scm") (line . 123) (column . 3))) #f ())`
<attila_lendvai>ACTION sees the same error
<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[1]: 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
<chomwitt>but wanting my system to not hang during booting if my external storage is not connected i made a couple of tests with 'nofail' but with no luck.
<jpoiret>evilsetg[m]: icedove messes up with formatting
<jpoiret>you should let git send-email send the mail itself
<rekado>make as-derivation fails with the above error
<jpoiret>tlecarrour, attila_lendvai, rekado: i'm on it
<rekado>it’s the builder for guix-system-tests
<jpoiret>just need to test the easy fix I have
<rekado>jpoiret: thank you
<jpoiret>make as-derivation is pretty long though
<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
<civodul>jpoiret: thanks for the hot fix!
<jpoiret>i didn't spot it either when I read your code :)
<jpoiret>trying to figure out why b4 mangled unmatched-paren's From: line
<William[m]>Hi all!
<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 processing branches, it looks at guix-patches issues
<cbaines>you can see the branches and the corresponding issues on the homepage
<jpoiret>right, but how are these branches picked? are they all of the branches?
<cbaines>currently it just builds the branch corresponding to the oldest issue
<cbaines>but it could do anything really, I set out in the patch I sent how to use the issues to specify the ordering in which the branches should be merged
<cbaines> processes all the branches, so the information is all available
<tlecarrour>jpoiret civodul your patches solved my problem! 👍 Thaaaaanks!
<civodul>tlecarrour: excellent!
<dthompson>anyone have experience using chicken scheme with guix?
<dthompson>I'm not familiar with it and I'm trying to build someone's project but chicken-install is trying to install stuff to /gnu/store and failing (of course)
<dthompson>chicken-install is how you install stuff with their package manager. maybe that's just plain broken on guix.
<dthompson>I guess probably I would need to package all the relevant libraries.
<iska>dthompson: can you point chicken-install to a user folder?
<iska>I know quicklisp breaks with FFI packages, so anything that uses an FFI has to be packaged and visible
<apteryx>initial guix pull on raspberry pi 4: 31.5 minutes
<ham5urg>Is it possible to add networking to an container from within a container.scm? does it not but uses the shell.
<jpoiret>ham5urg: most of the setup takes place outside the container. Currently this isn't possible in a container.scm
<ham5urg>jpoiret, such feature would enhance Guix to be used instead of Nix and sometimes even replace Docker.
<apteryx>hm, opencv doesn't build on aarch64-linux
<lambdanil>hi, I'm currently experiencing a bit of an issue with dbus
<lambdanil>for some reason my flatpaks don't connect with xdg-portals properly
<lambdanil>if I start a flatpak and then run xdg-desktop-portal -r manually it fixes itself
<jpoiret>lambdanil: does that fix it for good?
<lambdanil>also possibly related is that virt-manager fails to connect to libvirtd completely
<lambdanil>jpoiret: until a relog/reboot
<lambdanil>internal error: Unable to get system bus connection: Could not connect: No such file or directory
<lambdanil>this is what I get with virt-manager
<lambdanil>I think there's just something weird with dbus or something?
<jpoiret>what DE/WM do you use?
<lambdanil>sway, I'm invoking it with the dbus-run-session or whatever it's called
<lambdanil>using it without that doesn't help
<lambdanil>dbus-run-session is what it is
<jpoiret>you do need the dbus-run-session
<lambdanil>okay yeah I have that
<jpoiret>do you have the proper XDG_CURRENT_DESKTOP variable set to sway?
<lilyp>does this happen once per session or once per reconfigure?
<jpoiret>and do you run dbus-update-activation-environment afterwards?
<lambdanil>happens on a fresh boot
<lambdanil>I have a dbus-update-activation-environment in my sway config
<lambdanil>jpoiret: it does look like XDG_CURRENT_DESKTOP isn't set right
<jpoiret>you need to update the XDG_CURRENT_DESKTOP variable for the desktop portal to pick up when launched automatically through dbus, otherwise it won't find the proper backend
<lambdanil>oh and update the dbus environment after?
<lambdanil>because I tried fixing it yesterday and did that but the other way around
<jpoiret>yes, run `dbus-update-activation-environment XDG_CURRENT_DESKTOP` after setting the env variable should be enough
<lambdanil>yeah that makes sense, I'll try it
<lambdanil>thank you, I'll dc but I'll be back in a bit once I test it
<jpoiret>i have `exec "dbus-update-activation-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP XDG_DESKTOP_PORTAL_DIR"` in my sway config
<jpoiret>WAYLAND_DISPLAY might be needed for screen capture
<lambdanil>okay thank you, I'll try it out with these variables
<elevenkb>Can anyone help out with this bug:
<elevenkb>Basically the geiser-guile repl doesn't work at all for me to evaluate packages.
<elevenkb>Using guix repl directly does work though.
<elevenkb>Nvm. Pls ignore.... something has changed.
<lambdanil>jpoiret: so I added the dbus thing in my sway config, WAYLAND_DISPLAY, XDG_CURRENT_DESKTOP and XDG_DESKTOP_PORTAL_DIR are now all correctly set but unfortunately nothing changed
<jpoiret>is it set in the activation environment?
<lambdanil>I think it should be?
<jpoiret>you can check by finding the running xdg-desktop-portal process and cat'ing /proc/<PID>/env
<lambdanil>such a file doesn't seem to exist at all
<jpoiret>environ, sorry
<lambdanil>well now my portals aren't starting at all on a fresh login for some reason
<lambdanil>opening a flatpak starts them
<jpoiret>yes, that's what they're supposed to do
<jpoiret>dbus autostarts them when needed
<lambdanil>they seem to be there
<civodul>sneek: later tell ngz how far are we from merging 'tex-team'?
<lambdanil>well, I saved the environ from the autostarted one and the manually started one, I'll try to compare them to dinf a difference
<cbaines>civodul, I see some log entries regarding ludo on hamal, do you get an authentication error?
<cbaines>if so, try again, I think there was a wrapping issue with the SSH key
<civodul>cbaines: works now, thanks!
<civodul>jpoiret: i think can go in now
<cbaines>civodul, awesome :)
<jpoiret>civodul: right! i'm stacking a couple of patches so that I don't push too many times
<lambdanil>I don't know what's wrong but I think it goes deeper than the portal issue since virt-manager fails to connect to libvirt
<lambdanil>despite the socker existing and having all the correct permissions and groups
<jpoiret>you can also monitor dbus by using `dbus-monitor` (and possibly `--system`) and see if there's anything there that's going wrong
<civodul>cbaines: i don't see the "Grace period" messages in /var/log/messages*, so maybe it's too late
<civodul>anyway it's running shepherd 0.10.0, so you might want to upgrade
<tricon>Don't know if this documentation is current, but using *GPT* to discover/construct Guix code is appealing:
<davidl_>how do you put a g-expression inside a build argument, or more specifically to a configure-flag string?
<apteryx>#:configure-flags #~(list --prefix=#$output)
<apteryx>err, #:configure-flags #~(list "--prefix" #$output)
<bdju>The pcsxr package fails to build. I'll send in a report with the build log in a bit...
<elevenkb>Hello there is there any way to invoke guix build --no-offload from the repl?
<apteryx>you may be able to do so by setting the build options before invoking ,build
<apteryx>see the 'set-build-options' procedure from (guix store)
<elevenkb>apteryx: thanks for letting me know about this.
<elevenkb>I wonder: how come it isn't set up so that if you can't contact an offload server then you build locally?
<elevenkb>Or maybe the idea is that you add localhost as an offload server in that case?
<jlicht>hey guix
<apteryx>elevenkb: I think the original need was 'I never want this machine to build anything'
<apteryx>at least 3 people would be interested in that feature; you, nckx and myself :-) (configurable local-fallback capability)
<jackhill>I presume that any arbitrary logic can be implemented in machines.scm. Perhaps we need a module of commonly used helpers.
<jlicht>hmm, (modify-services %base-services (delete mingetty-service-type)) seems to still contain mingetty-service-type services on current master. Not quite sure what changed recently
<davidl_>apteryx: Thanks, I managed to make it work!
<apteryx>are we already building our packages with GCC 11?
<apteryx>I thought we were still with GCC 10.3.0
<apteryx>hard to know looking at the source
<apteryx>yes, it's at 11.3.0
<apteryx>figured it out at the REPL
<f1refly>the package `kvantum` needs `wayland` in its inputs so it can run natively with the wayland plugin
<f1refly>when setting QT_QPA_PLATFORM=wayland the application crashes when wayland is missing from its inputs
<mirai>f1refly: can you send a patch or open a issue?
<f1refly>I'm still unsure how to test patches before submitting them, would it be possible to get help regarding that tomorrow so I can create the patch?
<f1refly>There are more qt packages that need the exact same fix that I'd like to submit patches for :)
<cel7t>For testing patches, try using ./pre-inst-env
<mirai>Unrelated to above, is it acceptable to send a patch-series that depends on other patch-series? Or should I group it up into a monolithic patch-series
<mirai>I've got what roughly can be classified as 3 patch-series (that depend serially): define-configuration serializer-kwargs feature < (gnu services configuration generic-ini) module < NetworkManager refactoring/new fields
<f1refly>I tried that but I had issued where it would use the regular repository instead of the local checkout. I will try fiddling with it again tomorrow I guess.
<iska>I want to delete my home generations but keep everything needed to recreate them (to save space), which files do I need to grab from /var/guix/{...}
<iska>I know normal user profiles just need manifest files