IRC channel logs
2025-11-08.log
back to list of logs
<srbaker>Heya folks. I have a small cluster I built with k3s. I'm going to decommission it and move to some machines running guix. I have configurations for haproxy and keepalived, and I have some things I host which are most easily deployed in a container. I was thinking for "consistency" I might just deploy everything in containers. <srbaker>I'm curious if there are patterns or best practises or blogs or whatever on deploying many machines with guix. <srbaker>I'm also curious about "secrets management". I've used password-store, gopass, and sops. Curious if there's a favourite in Guix land. <srbaker>(I really like to do things in idiomatic, and "common" ways where possible.) <flurando>does anyone have experience of configuring yubikey as a login method for gdm? <flurando>I saw the yubikey website requires mannually editing /etc/pam.d/gdm-password to add "auth sufficient pam_u2f.so". <flurando>I wonder how to do that in guix, as I haven't seen any defined way to change that, shall I somehow write a new service? <benjaminwil>hi all. i was trying to switch from pulseaudio to pipewire today using the services defined in the main guix channel. it works! but i've realized that on login my home herd isn't working: `herd: error: /run/user/1000/shepherd/socket: No such file or directory` and i must use `guix home reconfigure` to get it running as normal. i'm not sure where to start debugging... any ideas would be welcome. :-) <benjaminwil>so far i've only determined that it has nothing to do with any of my home services... because i reconfigured with 0 services enabled and i have the same issue on reboot and login. <flurando>for me, adding the home-dbus-service-type and home-pipewire-service-type works <flurando>now, guix does not support using pipewire for whole system, pipewire could only be used as user <benjaminwil>i also removed the pulseaudio-service-type and alsa-service-type from %desktop-services, but i don't think that should have anything to do with my home herd not working at login. <flurando>but make sure you let the enable-pulseaudio? remain #t in pipewire configuration <flurando>the pipewire service would spawn some wrapper service in shepherd as well, which I guess, still requires pulseaudio or alsa in place <benjaminwil>regardless of whether i have those services or not, my real problem seems to be that `herd` isn't simply isn't running for my user until i manually `guix home reconfigure` :-( <flurando>guix pull: error: Git error: could not open '/home/jack/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/CODEOWNERS' for writing: Permission denied <flurando>I know why because guix-daemon does the job so CODEOWNERS is root:root? But this has never happened before! <flurando>Intererstingly, only this file and readme is root:root <flurando>just not pulling for several week, what has changed? <flurando>does anyone have experience configuring /etc/pam.d/gdm-password ? there is no gdm-pasword package, nor there is password related def in gdm... <benjaminwil>after re-reading the guix home services documentation i realized what i'd done wrong. my shell wasn't sourcing `setup-environment` or `on-first-login`, which of course would mean herd wouldn't be running on login. <rekado>apteryx: looks like 6ab1890aba1fd9b1f3a2dc46f1d7ec183452617d doesn't include gnu/packages/patches/squeak-vm-gcc-14-fix.patch, so now "make" fails <ngz>Hello. I don’t know if it has been reported, but Guix is currently broken due to a missing "squeak-vm-gcc-14-fix.patch" file. <identity>ngz: it was, in the previous message in this channel even <ngz>Great then :) I didn’t check the log. <ngz>Meanwhile, I’m going to revert the patch. <akshit>Btw, I am defuser from yesterday <janneke>ACTION has kinda accepted there's no sound on modern computers <akshit>Any barren server where I could just keep pinging myself with alts? <Rutherther>you can just make yourself a channel with arbitrary name you prefer or query yourself directly <apteryx>reapplied with missing patch in 102d0a86fb <apteryx>akshit: I have no sound on pings either, but I have enabled d-bus notifications for ERC, which goes in my desktop notification area. <apteryx>I'm sure you could configure some sound file to have play on pings though, if you wanted. <apteryx>I think if it gets fixed rather than removed from the doc, the doc should be expound to mention what using image entails (e.g.: you're on your own to generate the image of the specified file name, and maybe something about secrets not being auto-managed too?) <apteryx>I'm not sure if /etc/childhurd would work with a custom image <apteryx>or if the host guix system key would be automatically trusted for the image <apteryx>I suppose these niceties are also defeated when providing an image <apteryx>I'm still curious to know if disk-size is relevant at all when using the default '--snapshot' option; since I assume writes would be kept in a volatile overlay (in RAM?) <yelninei>apteryx: I dont even think the childhurd shepherd service would start (if one does not configure the receiving part manually) <apteryx>yelninei: I'm trying with 3583 but so far it seems to still be failing <apteryx>yeah, same message. perhaps my firewall? <apteryx>nope same problem with nftables disabled <apteryx>always something with secret service handshake not going through, returning <eof> <apteryx>I wanted to test building elfutils on the hurd :-) <apteryx>I'm surprised that the bootstrap binaries don't include the same packages based on what you wrote, yelninei ? <apteryx>yelninei: seems to be %boot0-inputs, that has a conditional for i686-linux and x86_64-linux; for other systems it doesn't include bzip2, coreutils, garw, patch, sed and tar... I wonder how that works there. <apteryx>I guess I'll have to punt on this part since I can't repro/debug here. We can always add a target-specific phase or test disabling later? <apteryx>ACTION starts world rebuild and goes bed; night everyone! <yelninei>apteryx: they only have the static bzip2 (from %static-inputs / %static-binaries) but no bunzip2 <attila_lendvai>ll `guix build lean4` has a single share/ directory with the licences?! <attila_lendvai>the package definition certainly looks like it should have more than that... <pastor>Hello, is anyone a user of `kwallet-service-type'? <eikcaz>Anyone able to use Gnome's builtin desktop sharing? I tried adding the gnome-connections package, but I still can't seem to enable desktop sharing. <ajarara>I can't find anything in the info pages for git flow for the codeberg repo. Can I rebase + force push in case of merge conflict? <Rutherther>ajarara: like for a PR? definitely, someone will have to solve the conflict eventually either way <FuncProgLinux>I mean like the package being a program that needs a shepherd service as well <mononoke>apologies to keep coming to chat for help, but I've run into another problem I'm not sure how to solve. in my system config I have fish set up as my user's shell, and in the home config I have the fish service set up how I want. But...when I first login at the tty prompt, before launching my wm (sway) it's still using bash according to `echo $0`. <mononoke>After I start sway, `echo $SHELL` confirms I've got fish up and running. What's going on here? <mononoke>I had assumed that even if I didn't have a graphical env running I'd still be using fish, but that doesn't seem to be the case <eikcaz>FuncProgLinux: the package doesn't provide a service. You define a service and reference packages from there. <eikcaz>Often that takes the form of $#(file-append <package> "/bin/<package") somewhere in a gexp <FuncProgLinux>eikcaz: Ahh so the shepherd service has to pull the package, not the other way around! Now I know why I wasn't finding anyhing wih guix edit dbus and guix edit pipewire <eikcaz>try "guix system edit <service-name>-service-type" <eikcaz>wait, no that should be without the service-type I think <FuncProgLinux>yea i had to do mate-desktop instead of mate-desktop-service-type <eikcaz>also works with home services like "guix home edit pipewire" <FuncProgLinux>Now I'll search for equivalent [Service] Type=dbus on guix services. <eikcaz>mononoke: what's the output of su --login <user> -c 'bash -c "echo $SHELL"' <postroutine>Hello. Do you know if someone already work on enhance the support for system containers and the `guix container` command ? I would like to contribute on this part and join whe are already on it. <eikcaz>mononoke: I've noticed some weird behaviors with user stuff post reconfigure but before a reboot. You could try "sudo herd restart term-tty<number>" which might help (or just reboot). <mononoke>eikcaz: same thing on that fresh tty. logging in as my user and doing echo $SHELL says fish, but echo $0 still says bash <eikcaz>postroutine: You could check the commit history, but in general this shouldn't really be a worry. When parallel works overlap, they result in a merge conflict, which is generally easy to resolve so long as contributions are granular. <mononoke>only when I start sway and use the terminal emulator does it run fish. bizarre <eikcaz>Are you on guix system, or foriegn distro? <postroutine>> postroutine: You could check the commit history, but in general this shouldn't really be a worry. When parallel works overlap, they result in a merge conflict, which is generally easy to resolve so long as contributions are granular. <postroutine>Should I directly do merge requests, or is it better to first discuss a new feature on the mailing list ? <untrusem>does anyone else have ` 'remote-https' is not a git command. ` problem inside distrobox? <ieure>Humm, set up a machine this week (replacing Debian with Guix System). Every time I log in, it says "warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script." Any idea what's up with this? <ieure>I used my normal Guix Home setup on this one, it doesn't do that on other machines I use it on. <eikcaz>I think it gets fixed if you do "guix install hello" <ieure>eikcaz, I don't use the imperative package management stuff at all, though. <eikcaz>on a fresh system, I think that directory usually gets created by the old-fashioned, non-home, profile management, and people use guix home after, so this rarely comes up <meaty>what directory do origin snippets run in/how can I find out? <eikcaz>You can also just manually mkdir the directory <ieure>eikcaz, Hmm, surprising, I think Debian puts /run on tmpfs. <eikcaz>ieure: my fix is not the "right" solution, it is a workaround to address the bug you are encontering. Really, the bug should be squashed :). In your case, you could guix package -m with an empty manifest. <ieure>Yeah, I looked up the right permission bits and did that. Strange issue though. <eikcaz>I'm surprised you get it on Debian, which is the most popular foriegn distro <eikcaz>postroutine: if you have something that you think works and is a clean solution, then just make the pull request and people can comment, suggest, and maybe at some point merge <untrusem>how would one see the logs of a window manager session? <ieure>untrusem, $HOME/.local/share/xorg/Xorg.0.log (or whatever the display server ID is). <ieure>Then it's a compositor, not a window manager. <ieure>No idea where Wayland puts things, but would try rummaging in ~/.local/share anyway. <untrusem>the dbus service shows a log file, but niri service does not <FuncProgLinux>rats :( a quick search lead me to discover there's no equivalent for ~/.xsession-errors <Rutherther>herd status shows only the last run, ~/.local/state/shepherd/shepherd.log is the log for shepherd by default, it can be overriden by the shepherd-service configuration <FuncProgLinux>Apparently that's for the compositor developer(s) to decide either via systemd journaling or the compositor logging itself <mononoke>I guess I never thought to see what happens making a brand new user with fish set as the shell from the start (mine was bash on initial install, I wonder if that has anything to do with it?) <Rutherther>mononoke: so currently in /etc/passwd you see zsh next to your user? <mononoke>mononoke:x:1000:998:mononoke:/home/mononoke:/gnu/store/x2g0npwvq1w8mp9g0zlfjhw8b4g6z1a7-fish-4.0.1/bin/fish <mononoke>currently just a vanilla tty, no dm or anything <mononoke>it appears to use bash when logging in that way <Rutherther>and that "login" program associated with the tty you are logging in has been restarted since you changed it? <mononoke>yep, i've done several reboots since then <mononoke>from the start its always still bash until i start my wm, then it's fish <mononoke>on other ttys its also bash according to echo $0 <Rutherther>and when you do "fish --login", you end up inside of fish? <mononoke>if it helps, this is what's in my system cfg for the greeter, i can't imagine that would affect anything. i was using a gtk greeter but i removed it since troubleshooting this https://pastebin.com/3dYNn6wg <Rutherther>are you using greetd then? I thought you said you weren't using a display/login manager <ieure>Isn't there some thing with the Guix init scripts only supporting bash? <mononoke>it's not, you can see it opens a tty login prompt <ieure>Swear I've seen others with similar issues when they want to use a non-bash shell. <mononoke>i suppose i could try the base mingetty login service instead <Rutherther>ieure: guix provides scripts only for bash, yes. But that has nothing to do with users changing shells to other ones as long as they properly set it up themselves. And the symptomps would be that they cannot use commands from the guix profiles <Rutherther>mononoke: greetd just defaults to bash. It doesn't respect user's login shell, it doesn't matter what you change your login shell to <Rutherther>you can read that in the guix's source, or in the resulting shepherd services commands they execute <mononoke>is that so? then that would be it, then. i was unaware it was so opinionated considering it isn't doing anything particularly fancy <yelninei>mononoke: you should be able to set the default-session-command in greetd-terminal-configuration in your greetd config file. THe default in greetd-user-session is bash. <Rutherther>so guix defaulted to bash that's likely already on the system and used by most users as login shell <mononoke>i see that now, i swear i pored over that section of the manual. i must have just missed it <mononoke>greetd-user-session default command is /bin/bash, yup <mononoke>Rutherther: opinionated may be the wrong term here, it's a sensible default like you said. I just had a brain lapse while reading, I guess! thank you both for nudging me along <mononoke>ok, yes that was totally the issue. feeling very foolish i missed that and just assumed it would use the login shell! <mononoke>all of my startup scripts are firing now like i expected <lh>it’s printing a guix store path to libvulkan-radeon.so, so some new environment variable is being set, I think <lh>I am trying to unset whatever variable my home profile is setting to get it to launch but no luck so far <lh>tried LIBRARY_PATH= ptyxis but still get the error <Rutherther>LIBRARY_PATH is for compiler, not for runtime. LD_LIBRARY_PATH is for runtime <lh>ah right. my guix home profile doesn’t set that anyway <lh>this is on NixOS, which adds /etc/sane-libs and pipewire-jack. but the gtk app (ptyxis) is from NixOS anyway, so that shouldn’t be a problem. I did try unsetting it just to check but no change <lh>ptyxis: symbol lookup error: /gnu/store/srh2gwvmy6q2bv35z63ihn7xvjd45rsf-mesa-25.2.3/lib/libvulkan_radeon.so: undefined symbol: wl_display_dispatch_queue_timeout <lh>that’s the error. which based on the debian bug I linked, indicates ptyxis from my NixOS profile is trying to load a newer mesa library from my guix home profile, but it’s still using the old libwayland-client from my NixOS profile <lh>this is the result of a change in the last couple months, since I just bumped my guix pin <lh>I mean, I guess the change could have been a routine mesa update, and the wrong library was always being loaded, they just were coincidentally compatible before this <Rutherther>do you have GI_TYPELIB_PATH set? if so, can you try unsetting that? <lh>that is set to a bunch of nix store paths, so it should be ok in this case, but unsetting it didn’t change anything <Rutherther>I do not know any more env vars that would lead to picking up other libraries then <lh>oh great I’m getting it from gnome-control-center too D: <Rutherther>can you try running "dbus-run-session bash" (after making sure dbus-run-session is from nix, not guix) and inside of it, execute gnome-control-center? <Rutherther>also, if you do ldd on either of those, are any libraries pointing to /gnu/store? <Rutherther>apart from this all, does /run/opengl-driver/lib contain the libvulkan_radeon driver? You could also try adding it to LD_LIBRARY_PATH, maybe that will make it precedence, working around the issue <lh>running apps inside /run/current-system/sw/bin/dbus-run-session bash didn’t change anything <lh>ldd from guix on ptyxis shows ld-linux-x86-64.so.2 pointing to /gnu/store but ldd from nix has it pointing to /nix/store <Rutherther>yeah, that's normal. You can try running ptyxis with ld-linux-x86-64.so from nix store to ensure, but that should be the one actually chosen if you run it directly <lh> /run/opengl-driver/lib does have the driver but LD_LIBRARY_PATH=/run/opengl-driver/lib ptyxis didn’t affect it <lh>I’m looking through LD_DEBUG now to try to get more info <lh>file=/gnu/store/<hash>-mesa-25.2.3/lib/libvulkan_radeon.so [0]; dynamically loaded by /nix/store/<hash>-vulkan-loader-1.4.313.0/lib/libvulkan.so.1 <lh>got ptyxis to launch with VK_DRIVER_FILES=/run/opengl-driver/share/vulkan/icd.d/radeon_icd.x86_64.json ptyxis <lh>no, no VK vars set, which is the tricky part, since I will have to determine how to get the nix loader to not pay attention to the guix libs <lh>without breaking guix apps in the process or having to make wrappers for everything <Rutherther>I am not even sure how it would know about the guix libs in the first place. I doubt it would be looking through the fs for the libraries at any paths <Rutherther>yeah, but you don't happen to have any of those files from guix, right? or do you? <Rutherther>hm, maybe if you installed an application that has this file, then you could <eikcaz>lh: Check the values of the other XDG_* env vars. <Rutherther>but I can't imagine why you would install for example mesa to your user profile <eikcaz>I've had guix turn an empty XDG_* variable into some guix paths, which is wrong. Empty var has implicit default meaning, so when you replace it with guix paths, you loose the default. <lh>`find -L ~/.guix-home/ -iname '*icd.d*'` returns `/home/lh/.guix-home/profile/share/vulkan/icd.d`, so it’s XDG_DATA_DIRS <lh>XDG_DATA_DIRS= ptyxis works <eikcaz>Do you see your base system paths in $XDG_CONFIG_DIRS and $XDG_DATA_DIRS? <lh>but that’s also not really a viable long term solution <Rutherther>lh: ...so did you install mesa to that profile or what package is it coming from? and if so, why would you install libraries in the first place? <eikcaz>lh: put XDG_DATA_DIRS="/usr/local/share/:/usr/share/:$XDG_DATA_DIRS" into your shell rc <eikcaz>or modify your guix home similarly <lh>eikcaz: I don’t want system xdg data dirs to take precedence over guix home in basically all other cases <lh>I’ll look into why they’re in my home profile, yeah <lh>there’s some guix graph command for that I think <Rutherther>yes, but guix graph doesn't show you what is propagated. mesa is a dependency of mostly all gui apps, but very few propagate mesa <eikcaz>lh: As long as your native distro doesn't have the package installed as well, your guix commands will find the guix data dirs <eikcaz>(Which should almost always be the case: once you install something with guix, you should remove it from your native system IMO.) <Rutherther>lh: guix graph won't really show you what propagates it. But I am afraid that here it will be that you are using an app that propagates gtk+ (as more than a few apps do, unfortunately) and that propagates mesa <lh>I think the main gui apps I include from guix are firefox and emacs <Rutherther>eikcaz: I don't think it's about running installed apps, it's more about font configurations, icons, themes... for all of those things you want to have user's XDG_DATA_DIRS take precedence, not system. Since lh is on NixOS prepending those system paths wouldn't work either way I think. llh would have to prepend /run/opengl-driver/share, which could work, but I am afraid could also break some guix apps that would use vulkan loader. <lh>exactly, thanks for filling in the context for me! <lh>yeah I’m not seeing share/vulkan in a profile created by guix shell firefox emacs-pgtk, will have to keep poking around, maybe comment out a bunch of packages in my home config and rebuild to “bisect” <lh>it appears the culprit is zbar <lh>I basically never use that so easy enough to drop from my home env and rely on guix shell when I need it <Rutherther>I guess it's both an app and a library and in such cases, unfortunately guix propagates most of the time :( <lh>I guess ideally we’d split it into lib and cli outputs? <Rutherther>even for libs a better approach could be done than propagation <lh>the description says it includes a GTK widget, how would you support that without splitting outputs? <lh>in any case, thank you very much for your help! I can open a bug about improving the zbar package, or a general bug about cleaning up packages propagating gtk, if you think it makes sense <Rutherther>lh: the propagation is because of a requirement coming from pc file. And to satisfy it you can just copy the pc file(s) from gtk+. No need to propagate whole gtk+, only the pc file is important <lh>should we open an issue for that? <Rutherther>though it asks for a rewrite of a lot of packages, because this change would have to be made in the whole tree <Rutherther>as in, gtk+ also has to be adapted, because it also propagates stuff due to pc file and maybe some other inputs of it as well, I didn't check further <ajarara>if I have qemu-binfmt-service, when I run guix build --system=$SYSTEM $MY_PACKAGE am I cross compiling or am I using qemu to run guix under the architecture? <ajarara>by cross-compiling meaning passing $SYSTEM down to the compiler <ajarara>which runs on my actual architecture. Am I using these terms right? <Rutherther>ajarara: with --system you use qemu binfmt. You would have to use --target to cross compile