IRC channel logs

<vagrantc>planned downtime

<ElevatorConnoiss>Greetings, how do I set up containers with the latest rolling release packages at the time of creation? Right now, when I start a container with =guix shell -C=, it's on the latest stable release. =guix --version= inside the container returns 1.5.

<apteryx>hello, Guix! Shouldn't the option 'enable-ssh-support' be written to ~/.gnupg/gpg-agent.conf file by the home-gpg-agent-service-type when ssh-support? is #t?

<apteryx>oh, I guess it's unnecessary; from (info "(gnupg) Agent Options"): On Unix platforms the OpenSSH Agent protocol is always enabled, but 'gpg-agent' will only set the 'SSH_AUTH_SOCK' variable if the option 'enable-ssh-support' is given.

<apteryx>that means it's always enabled, and only used to set SSH_AUTH_SOCK, but that's already taken of by the home-gpg-agent-service (see the `home-gpg-agent-environment-variables' procedure).

<apteryx>podiki: ^

<loquatdev>Has anyone here had issues with static-networking-service-type? I'm trying to move from dhcpcd-service-type to a static configuration but doing so, even with very, very simple configuration causes the networking service to fail and consequently nuke all of my other services that use the internet.

<loquatdev>I had it work once but upon running the exact same reconfigure command it failed again.

<loquatdev>I don't have any other networking services running. Could it perhaps be conflicting with the loopback definition in %base-services?

<apteryx>guix home can't seem to deal with a ~/.gnupg being a symlink

<loquatdev>I've been poking at it for a while and can't find any helpful logs or error messages.

<loquatdev>I got it working. Basically, I just had to manually flush all of my addresses and routes and then reconfigure. I imagine most people don't change static networking configurations after the first `guix init`.

<LongTimeUser-48>Hm, since migrating to home-gpg-agent-service-type my SSH key is not usable; attempting to SSH anywhere yields: sign_and_send_pubkey: signing failed for ED25519 "/home/myuser/id_ed25519" from agent: agent refused operation. Any idea?

<LongTimeUser-48>good old pinentry confusion; it didn't work initially for reasons, then started experimenting with other pinentry programs; the one that works for gpg-agent is the one named "pinentry", which is the same as pinentry-gtk2

<maxim>eh, I think my mistake is silly: pinentry-program /gnu/store/s7lwk1dqqdxnarvpv0lx0hsvz5f8zah9-pinentry-1.3.2

<maxim>that'd have to be the bin/pinentry-gtk-2 program

<apteryx>hm, gpg-agent migration to guix home is not yet a success

<switchy>oh yeah, I had pinentry troubles too

<apteryx>gpg is now able to use pinentry, but ssh itself fails; with errors like sign_and_send_pubkey...agent refused operation

<apteryx>uh, the good old updatestartuptty seemed to have helped: https://lists.gnu.org/archive/html/help-guix/2025-01/msg00015.html

<apteryx>let's see if it still works after logout/login

<test202020>bourdeux is live?

<apteryx>still had that in my .bash_profile, maybe it conflicted with the home gpg-agent service: https://paste.guixotic.coop/.bash_profile_bash_-485-916.html

<test202020>apteryx: why you pass that in bashrc? in my case gpg agent from home service working fi ne witgout that

<apteryx>I think I used to do weird stuff such as SSH'in from outside, and wanted gpg to work even in that situation

<apteryx>that probably how it landed there (duplicated from my ~/.bash_profile as well)

<apteryx>I've removed both now, let's see

<test202020>i not pass anything related to ssh in bashrc

<test202020>apteryx: maybe you want to configure gpg remote forwading?

<test202020>ForwardAgent yes

<test202020>RemoteForward

<test202020>in ssh config

<apteryx>interesting; I don't have a use for it at the moment but will remember that option (RemoteForward)

<apteryx>the --supervised option used for gpg-agent service is apparently deprecated

<test202020>if you pass IdentityFile in remote machine ssh config, you can forwarding key without copying private and public key to remote machine. just use ssh-add ~/local-machine/privatekey

<test202020>somethimes that have strange bug and you need to remove gpg sockets on remote machine if your agent is broken

<test202020>do not copy private keys to remote machine

<apteryx>ssh over gpg-agent is still not working after that cleanup :-/

<apteryx>though my key is listed by 'ssh-add -L'

<test202020>show your ssh config entry

<apteryx>ssh is apparently failing to sign with the private key

<test202020>you are setup pinentry?

<test202020>failing on remote machine, right?

<apteryx> https://paste.centos.org/view/d44e8961

<apteryx>I'm just trying to make a successfull ssh from my local machine at the momen

<apteryx>moment

<apteryx>it succeeds after 'gpg-connect-agent updatestartuptty /bye'

<test202020>whats about ssh config entry?

<apteryx>I don't think it matters here, any SSH out fails the same

<apteryx>and passes if I 'gpg-connect-agent updatestartuptty /bye'

<test202020>i do not make that

<apteryx>maybe it has to do with the lazy socket activated gpg-agent

<apteryx>do you use home-gpg-agent-service-type ?

<apteryx>the problem started after migrating to it

<test202020>hm, maybe emacs something setup that for me

<test202020>apteryx: i using emacs-pinentry.

<apteryx>does this work well outside of emacs as well?

<test202020>but i can try something else

<apteryx>I'm using the good old gtk2 one (`pinentry` variable package), which is the one that works with gpg-agent

<test202020>apteryx: what your SSH_AUTH_SOCK entry now?

<apteryx>actually, my .bashrc usage was straight from the recommended practice in (info "(gnupg) Agent Examples")

<test202020>apteryx: i remember that, but maybe that outdated.

<apteryx>my SSH_AUTH_SOCK is /run/user/1000/gnupg/S.gpg-agent.ssh

<apteryx>this is about the systemd socket activation being deprecated, which we use: https://dev.gnupg.org/T6336

<apteryx>maybe related to these problems

<test202020>apteryx: that rights. need to look at ssh config i think

<test202020>that you append for agent?

<test202020>you can debug ssh with -v and -vv

<test202020>get_agent_identities: agent returned 1 keys

<apteryx>test202020: yeah, already tried -vvv, it just says the private key could not be read or something

<apteryx>sign_and_send_pubkey: signing failed for ED25519 "/home/maxim/.ssh/id_ed25519" from agent: agent refused operation

<apteryx>i'll try dumbing down our services to not use systemd socket activation

<test202020>that not using systemd

<test202020>you are need to setup ssh for using gpg agent

<test202020>in ssh config

<apteryx>that's taken care of by home-gpg-agent-service-type, which uses make-systemd-constructor

<apteryx>I'll change this constructor to use #:lazy-start? #t, maybe that'll help

<test202020>in my home config i havw only ssh-support? #t

<apteryx>I'm not sure why this is enough for you but not for me :-)

<apteryx>maybe the way the session launches; I'm using GNOME here.

<test202020>for gnome you can try pinentry-gnome

<apteryx>nah, that one doesn't like gpg-agent

<apteryx>(confusingly so)

<test202020>pinentry dedicated for gpg-agent

<apteryx>you can't ssh-add while running gpg-agent as ssh-agent (it'll fail mysteriously)

<apteryx>at least that's what I had discovered a couple years ago

<test202020>apteryx: but i am using gpg-agent as ssh agent and ssh-add required for remote forwarding

<test202020>without ssh-add in gpg-agent remote forwarding impossible

<apteryx>that's with pinentry-emacs, right? I hadn't tried that one, maybe it works fine with gpg-agent and ssh-add, contrary to pinentry-gnome3

<test202020>apteryx: i just using pinentry-emacs because regular emacs user. but that must working with other pinentry too

<apteryx>I found back my old post: https://unix.stackexchange.com/a/494530/82353

<apteryx>apparently I was using pinentry-emacs back then and it didn't work with ssh-add; perhaps it's been fixed since?

<apteryx>for emacs to prompt by itself, I just use its native feature: (require 'epg) (setopt epg-pinentry-mode 'loopback)

<apteryx>maybe to trigger that bug you need a passphrase protected key

<test202020>apteryx: no, i am not setup epg

<test202020>i put socket path to my ssh config and setup pinentry in guix home, that all

<test202020> https://wiki.gnupg.org/AgentForwarding

<test202020>look at SSH Configuration

<test202020>maybe that problem in extra socket

<test202020>while setup forwarding i specify extra socket for connection

<test202020>apteryx: you trying that?

<apteryx>I'm not trying to fix agent forwarding at the moment, just the basics of having gpg-agent work all the time as an ssh-agent, without requiring 'gpg-connect-agent updatestartuptty /bye'

<test202020>i not using updatestartuptty

<apteryx>test202020: do you perhaps launch your graphical shell/session from your .bash_profile or similar?

<test202020>apteryx: you mean M-x term?

<apteryx>no, your graphical session, if you use one

<apteryx>test202020: do you set GPG_TTY ?

<test202020>apteryx: no, for what?

<apteryx>for telling gpg-agent which TTY it should talk to

<test202020>apteryx: that not required for gpg-agent work

<apteryx>what does the command 'tty' output for you?

<test202020>apteryx: my ssh contact with gpg-agent over socket

<switchy>apteryx: I think I initially had that issue when I was using the default pinentry, so I was manually setting GPG_TTY.. but then I just decided to switch to pinentry-gtk2 which doesn't seem to break in the same way and I didn't bother trying to fix it since that

<test202020>anyway curses and tty pinentry is been broken while i trying that year ago

<test202020>but i do not know how emacs pinentry handle that

<apteryx>the funny thing is this setup was working for years in a minimal environment (ratpoison), where gpg-agent was launched via a manual shepherd service from the same startup file (.xinit IIRC); then I migrated GNOME, and it was still working with some flakiness, then I migrated to 'guix home' and it doesn't work at all as a ssh-agent, or at least not until I manually run 'gpg-connect-agent updatestartuptty /bye'.

<apteryx>Perhaps I'll slap this in my ~/.bashrc an call it a day.

<test202020>apteryx: you try to pass socket in ssh config?

<apteryx>it's already in the environment, SSH_AUTH_SOCK

<test202020>apteryx: i mean extra socket

<apteryx>that's just for the forwarding, no?

<apteryx>I'm not interested in forwarding, just want the basics to work out of the box

<apteryx>I see Caleb had the same or similar problem apparently: https://lists.gnu.org/archive/html/help-guix/2025-01/msg00015.html

<apteryx>unclear if that's using home-gpg-agent-service-type though (they didn't say)

<test202020>apteryx: updatestartuptty usinf for remote forwarding to setup your tty

<apteryx>that's typically when I needed it, but right now I need it in a local terminal emulator after a fresh login into GNOME, otherwhise gpg-agent rejects ssh-agent

<test202020>apteryx: that strange, but anyway in my setup is working

<apteryx>do you also use GNOME?

<test202020>apteryx: no, sway.

<test202020>apteryx: echo GETPIN | pinentry

<test202020>gnome3 pinentry require Gcr

<apteryx>test202020: we have a gcr home service; maybe I'll try this next time

<apteryx>for now 'gpg-connect-agent updatestartuptty /bye > /dev/null' in my ~/.bashrc makes things function normally at least

<test202020>apteryx: pinentry is working? gtk2? what giving echo GETPIN before that?

<apteryx>yes, that works

<apteryx>I guess it wouldn't have worked without the updatestartuptty

<apteryx>I'll try for the kicks

<venoflux>I just updated my guix and it seems that due to missing static-when in emacs both magit and geiser does not work, after I researched I was suggested to upgrade compat package to version 31 however, on guix packages it is version 30.1 is there a way to upgrade before channel or downgrade my magit and geiser so it does not require static-when?

<apteryx>test202020: echo GETPIN | pinentry works any time, even if I remove 'gpg-connect-agent updatestartuptty /bye > /dev/null' from my ~/.bashrc and re-login (it should, it's not related after all)

<test202020>apteryx: whats about gpg-agent log? use can pass guru verbose

<apteryx>I think the issue was the TTY used by gpg-agent was wrong until I update it with the command, so it was causing the pinentry to prompt on some other TTY, which failed

<apteryx>test202020: https://paste.guixotic.coop/shepherd-1189086-1190986.log.html the tail of my shepherd.log when it was failing

<apteryx>anyway, I think I'll try to move on as that sucked my energy ^^'

<test202020>apteryx: failed to unprotect the secret key: Ioctl() is problem.

<apteryx>which would happen because pinentry was not successful

<test202020>i just using emacs-pinentry, that works without that. i do not know how :S

<test202020>you can make more verbose, gpg-agent support that

<apteryx>test202020: thanks for your help

<apteryx>I need to run

<jlicht>is there any reason for us not going crazy with wrapping pretty much any system service that provides a shepherd service with least-authority-wrapper

<jlicht>ignoring the "someone needs to do it", "someone needs to test it" and "someone needs to review it" matter, of course :-)

<kestrelwx>o/

<jlicht>kestrelwx: o/

<oliverD>Is the substitute server down currently? I get "No route to host" after looking up substitutes (and I haven't set up swap so the build just runs my computer out of ram and fails)

<oliverD>Or maybe I've just broken something else.

<jlicht>oliverD: one of the machines is, yes. I think the HDD is being replaced by an SDD? Could be that I'm misremembering some messages :-)

<bjc>janneke: does this race patch in #8609 work for you: https://codeberg.org/guix/guix/commit/ca6bef625fc5c9c3af520a9168862e108b932edb?

<bjc>that bug is so annoying

<janneke>bjc: that's still hard to say

<janneke>i haven't seen the problem anymore, but it only seems to occur once in 10-20 boots, and then often several times in sequence, and then it goes away again, or something.

<janneke>i stumbled upon it in a Debian patch and copied+modified it

<janneke>also, i haven't tried it yet in combination with your tmpfs patch that might tell us better what races, as we have more messages?

<bjc>janneke: ok. i'll keep that in mind

<bjc>so, the old tmpfs still had it, for sure

<bjc>new one is more robust (in early boot guile), so maybe not? i haven't had the issue yet

<bjc>but that doesn't mean it's not there, of course

<janneke>bjc: just commented on your "setxattr, cannot do than from linux" remark

<bjc>👍

<janneke>we /can/ embed passive translators in a hurd filesystem from linux

<janneke>sadly, as it turns out, we cannot do that from tmpfs, which is used during the guix image build

<bjc>i'll look more closely. i went crazy for a bit trying to figure out how to do that

<bjc>i even tried from an ext2 fs image, thinking that was how we did it

<janneke>i see two solutions (there may be more:): add a post-processing stage: use qemu-nbd to mount the image after creation and embedd the passive translators using setxattr

<bjc>i'll dig in more, but my recollection from my attempt was that guile was using ffi to call xattr stuff and getting the same error that setfattr was, so i assumed it was the problem

<bjc>i *was* using qemu-nbd to test. i'll try again though and update the ticket

<janneke>or, which i'm currently testing, patch linux to allow gnu.* on tmpfs

<bjc>i might be misremembering

<bjc>i don't think patching linux is going to be a starter, tbh. this is standard behavior

<janneke>bjc: i have a script to embed the servers/socket/1 pflocal in a hurd qemu image, and then guile runs in runsystem on 1st boot

<bjc>i tested it on freebsd too, before i figured it out

<bjc> https://www.man7.org/linux/man-pages/man7/xattr.7.html

<bjc>there are only 4 namespaces defined

<janneke> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88ee9d571b6d8ed345f877e05f685814412e359b<

<janneke>maybe someone should have created a patch for the man page

<bjc>well ok

<bjc>i must be doing something weird then

<janneke>the GNU namespace was reserved in 2016 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3980bd3b406addb327d858aebd19e229ea340b9a

<janneke>np, if you're running a very stable kernel, 4.x or possibly 5.x, it might not be there?

<bjc>ok, i was wrong. i tested it again with qemu-nbd on an ext2 image and it was fine

<janneke>bjc: https://kluit.dezyne.org/download/janneke/pipe.sh

<bjc>yeah, i think i just got my memories jumbled

<janneke>bjc: good! it's easy to confuse yourself with all these images and options, i do that all the time

<bjc>i spent a long time trying to figure out the xattr thing and went down a lot of rabbit holes

<janneke>i found it "funny" that i took the path of trying to run guile from the top of runsystem to prepare to replace it a guile script, while at the same time you moved most of the bash to guile

<janneke>nicely complementary

<bjc>early guile is a worthy goal

<bjc>was slightly trickier than i thought, but it was just a matter of sequencing a few things properly

<janneke>sure

<janneke>runsystem has had at its top

<janneke># XXX Guile needs pipe support for its finalizer thread, to start.

<janneke># Remove this script when Linux and the Hurd have xattr patches.

<janneke>since we patched linux and hurd to enable this...

<tusharhero-xmpp>Guile bases shell when?

<janneke>i wasn't really looking forward having to do all this work of translating bash to guile, and it seems now i don't have to

<tusharhero-xmpp>s/bases/based

<tusharhero-xmpp>I know of gash

<janneke>tusharhero-xmpp: yeah/no; in the current hurd server startup, there's still one bash script

<janneke>the linux-based startup is pure guile, we want that for the hurd too

<tusharhero-xmpp>janneke: what is gash used for?

<janneke>for example, instead of using `fsck' we'd like to use `check-file-system` from `(gnu build file-systems)`

<tusharhero-xmpp>Mes?

<janneke>tusharhero-xmpp: gash started as two projects: geesh and gash, which later merged

<trev>i have a request for anyone running an AMD laptop and on a recent-ish guix pull... can you do a `guix shell hyprpaper -- hyprpaper` and confirm if it crashes?

<janneke>gash' aim was to create a convenient shell library for scripting in guile, and an automatic bash->guile translator

<tusharhero-xmpp>I see

<janneke>when gash and geesh merged, gash was re-prioritised to support the full source bootstrap, so replace all of bash and coreutils&co (gawk, grep, sed, etc); so yeah, if you say "used for mes" that's pretty correct :)

<janneke>gash is a fully functional bash-compatible shell in guile, though

<janneke>and there's still the hope of creating this very convenient guile shell scripting library with it

<tusharhero-xmpp>Why would one still prefer to use bash instead of gash?

<tusharhero-xmpp>Anything that's missing?

<kestrelwx>Doesn't seem to have time. :D

<kestrelwx>`time`

<tusharhero-xmpp>kestrelwx: hello!

<kestrelwx>Hi!

<janneke>tusharhero-xmpp: things like: guix copy --to=kluit $(grep -o '"out","[^"]*"' $(cat drv) | sed -e 's,"out".,,' -e 's,",,g' -e s,.*:,, | grep -v ^static$ | sort -u)

<tusharhero-xmpp>I think M-x guix-shell I will have to add a transient menu

<janneke>it's pretty involved to type things like that in guile

<janneke>but i agree, using shell is crazy

<janneke>in dezyne we have some pretty convenient `pipeline` functions for guile that should end up in guile or gash

<tusharhero-xmpp>There is a section about scheme shell in guile manual

<janneke>guix and BLUE also have quite a lot of nice functions

<tusharhero-xmpp>What's that about)

<janneke>there's just not one library yet that provides them all

<kestrelwx>tusharhero-xmpp: For package selection, or what kind of menu?

<janneke>tusharhero-xmpp: pipeline? it's for writing a pipeline like the guix copy above in a convenient way, in guile

<tusharhero-xmpp>kestrelwx: I was thinking, "okay I have C-u for selecting manifest.sxm, and C-u C-u for ..." And realized it is stupid to even try making this stuff up, no one is going to be able to remember. Transient was designed to solve this problem, so we should just use that. Emacs-Guix already has some transient menus anyway.

<tusharhero-xmpp>janneke: scsh or something, I rmemebr seeing something about a scheme shell in the guile manual.

<janneke>tusharhero-xmpp: yeah, a `modern' version of that, if you will

<janneke>ACTION seems to remember that someone did something for racket not too long ago, `rash' maybe

<tusharhero-xmpp>ACTION thinks gash is a much better name than rash

<janneke>you probably want to use bash-like syntax in your shell by default, but be apble to escape to scheme: ,(map foo (find-files '*.drv'))

<tusharhero-xmpp>Someone is going to make "Oh My Gash"

<janneke>*".drv"

<kestrelwx>There's also schemesh...

<bjc>btw, janneke, i think we'll always need a tmpfs /servers/socket for early-boot guile until guile can be patched to not require it

<bjc>the issue is what happens when someone removes /server/socket/1? it'd render the system unbootable again

<janneke>bjc: then don't do that?

<janneke>i don't really follow the tmpfs /servers/.. to run guile, i think i convinced myself guile starts nicely when we embed the xattr pipe translator in the image/file-system

<janneke>but yeah, if someone removes the xattr, it won't boot

<janneke>and also, my offload server just told me

<janneke>objcopy: unable to copy file 'drivers/accessibility/speakup/speakup.ko'; reason: No space left on device

<janneke>so two hours of linux-libre build time wasted...%-/

<bjc>oof

<jlicht>trev: provided amd gpu/cpu desktop is also fine, can confirm it crashes with eglGetProcAddress(eglCreateImageKHR) failed

<bjc>i sort of get the “don't do that” argument, but it feels like, if we can reasonably protect people from an unbootable system, we should

<janneke>i pushed the patch to a pr, possibly the guix build farm already built it

<janneke>bjc: agree

<jlicht>trev: using sway, in case that matters

<janneke>i think we should balance it agains what harm a stray rm -rf <something> could do to render a current linux-based guix unbootable

<janneke>*against

<bjc>i'm using guix with a tmpfs /, so i'm not sure *what* can make my system unbootable

<bjc>deleting /boot, i guess

<janneke>we don't want a fragile system, but if you follow random advice from the interwebs (some people think they're really funny posting some rm -rf meme), then yeah

<janneke>yeah, that would do it; or even corrupting one file under /boot

<identity>gush sounds like a better name than gash, especially looking at the dictionary entries. Gush, v. t. A sentimental exhibition of affection or enthusiasm, etc.; effusive display of sentiment. Gash, n. A deep and long cut; an incision of considerable length and depth, particularly in flesh.

<identity>though i guess that would mean losing the ‹a› from ‹bash›

<janneke>identity: i like your suggestion and i'll try to forward it to samplet when they arrive

<janneke>we had some major dissaproval action on `gash' and we just chose to ignore that, but yeah

<janneke>sneek: later tell samplet: https://logs.guix.gnu.org/guix/2026-05-15.log#131216, wdyt?

<sneek>Okay.

<janneke>sneek: botsnack

<sneek>:)

<janneke>identity: yeah, but it gains the `u' from guile