<judson>
Seems fair. Let me look at how to add the flag to that PR.
iceypoi has quit [Quit: WeeChat 2.4]
kaliumxyz has joined #home-manager
<kaliumxyz>
ping
linarcx has joined #home-manager
linarcx has quit [Ping timeout: 246 seconds]
linarcx has joined #home-manager
linarcx has quit [Ping timeout: 255 seconds]
linarcx has joined #home-manager
<rycee>
kaliumxyz: Hi! If you have a question then ask directly and somebody will answer when they have time.
linarcx has quit [Ping timeout: 268 seconds]
linarcx has joined #home-manager
linarcx has quit [Ping timeout: 255 seconds]
linarcx has joined #home-manager
linarcx has quit [Ping timeout: 244 seconds]
linarcx has joined #home-manager
linarcx has quit [Quit: WeeChat 2.4]
kaliumxyz has quit [Ping timeout: 255 seconds]
kisik21 has quit [Ping timeout: 268 seconds]
linarcx has joined #home-manager
thePirateKing has quit [Remote host closed the connection]
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #home-manager
<infinisil>
Hmm I've been thinking, for single-user systems, using home-manager for services doesn't really help with anything
<infinisil>
Because you might as well just use NixOS' `systemd.user.services`
<rycee>
Yup. It won't provide any major benefit that I know of in that scenario.
<infinisil>
And since NixOS can now also install packages for specific users (users.users.<name>.packages), the only thing home-manager is needed for is for writing config files in ~
<infinisil>
Yeah, I guess one benefit is that some service modules might be better in HM (like the gpg-agent one I just wanted to use)
<rycee>
And other user-level activation commands. Like importing dconf settings…
<infinisil>
I think NixOS also has an option for that now iirc
<infinisil>
system.userActivationScripts
<infinisil>
Not entirely the same though, I think
<rycee>
Hmm, I think that is more "user" as in you as a user can add scripts to be run during system boot.
<rycee>
Oh, and by "single-user systems" I assume you mean "single-user NixOS systems" ;-)
<infinisil>
I do indeed :)
<infinisil>
Hmm, userActivationScripts just creates systemd.user.services.nixos-activation
<infinisil>
I think that should work for what HM uses its activation scripts?
<infinisil>
Although, it might run before X setup
<infinisil>
(there's no after = [ "graphical.." ] for it, but that could be added)
<rycee>
Hmm, HM assumes that the activation script will run under the target user so you'd have to do some sudo thingy. The idea being that the system admin in principle could set up the system configuration that imports a HM configuration from a non-admin user.
<rycee>
And this non-admin user won't be able to screw the system up to badly.
<rycee>
For a single-user system this wouldn't be an issue :-)
<infinisil>
rycee: Yeah nixpkgs userActivationScripts does run under the user (because it's the users systemd service)
<infinisil>
Yeah
<infinisil>
Ah darn, HM's gpg-agent.enableSshSupport doesn't actually work
<infinisil>
I think
<andi->
works for me
<rycee>
Hmm, I've used enableSshSupport since the inception without issues.
<infinisil>
andi-: I quit gpg-agent before trying this (because it's supposed to be socket activated)
<rycee>
It does require a relog.
<rycee>
Since it needs to set an environment variable.
<rycee>
Do you have an SSH_AUTH_SOCK variable already?
<infinisil>
Yeah I do
<infinisil>
rycee: andi-: I suspect that it only works for you because gpg-agent automatically gets started even before you need it (via a new terminal/system login)
<rycee>
If it is set to the same as what `gpgconf --list-dirs agent-ssh-socket` outputs then it might find the right gpg-agent,
<infinisil>
Hmm no, that command doesn't start gpg-agent as I suspected initially
* infinisil
tries to figure out why gpg-agent gets started automatically on new shells
<infinisil>
But this is weird, why define all these sockets when none of them get used in the end, because it's started anyways when you open a terminal
<rycee>
Well, I guess when you don't use the SSH socket then it wouldn't happen.
<rycee>
An alternative would be to wrap the ssh command to run updatestartuptty first.
<infinisil>
Which kind of defeats the purpose of gpg-agent using a socket
<rycee>
In the case where you have `enableSshSupport = true`, yeah.
<rycee>
Maybe there is some development on the ssh side to not require these workarounds but searching for it seems to just turn up the updatestartuptty trick.
<infinisil>
`gpg-connect-agent "help updatestartuptty" /bye` also mentions `# Set startup TTY and X11 DISPLAY variables to the values of this# session. This command is useful to pull future pinentries to# another screen. It is only required because there is no way in the# ssh-agent protocol to convey this information.`
<rycee>
Would be really nice if there was a nice solution.
<infinisil>
It might be better for HM to just start gpg-agent as a normal service, without all these sockets. Or only use sockets when sshSupport is disabled
<rycee>
Hmm, that seems like unnecessary work. Wouldn't that just make it function basically the same as today?
<rycee>
Just starting a bit earlier.
<infinisil>
Yeah but it feels cleaner and doesn't delay terminal startup
<rycee>
I can't say I've ever felt bothered by the first terminal startup speed :-)
<rycee>
But certainly, if it is something people are noticing and get disturbed by then it might be worth changing.
<infinisil>
I certainly have!
<infinisil>
(well gpg only plays a short part in my terminal startup time probably)
<infinisil>
But actually, gpg-agent doesn't work with ssh. Relogged, gpg-agent is certainly running. I type `ssh <host>`, enter passphrase (on the terminal, no gpg-agent gui opening), close, ssh again, have to enter passphrase again
<infinisil>
Oh
<infinisil>
Hold on, ssh-add..
<rycee>
Tried a few first logins and it seems to lie around 6-7ms
<rycee>
And subsequent terminals 2ms.
<rycee>
(on my old laptop, with ssd)
<infinisil>
Yeah I had to ssh-add them to gpg-agent, now it works
<rycee>
Yup, can't get away from the ssh-add. I usually forget that as well :-)
<infinisil>
I'm using HDD's with an SDD cache, so it will be pretty fast now, but on startup much slower
<rycee>
I guess it should be safe to run the command with &.
<rycee>
So it won't block the shell start up.
<infinisil>
I'm wondering why I've never seen these gpg-connect-agent stderr outputs before
<rycee>
But the fork will also cost a bit, I guess…
<infinisil>
It's 3ms for me now that it's in the SSD cache
<infinisil>
If I see a noticeable improvement I'll make a PR
<infinisil>
(with something like using an systemd service instead
<rycee>
I guess systemd readahead has been removed?
<rycee>
It was quite handy when I was using a regular HD.
<infinisil>
But man, SSD's are expensive. Am I just poor or is everybody else so rich?
<infinisil>
(well tbh I could split my system to be partly on the smaller SSD I have, but that would complicate things, so I just use the SDD as a cache)
<infinisil>
It's unfortunate that ZFS caches can't persist over reboots as of yet, this is the real reason my boot is so slow. It's a planned feature in the future at least.
<rycee>
Hehe, I saved for it by just getting the ssd and keeping old laptop. It made quite a difference.
<rycee>
But will have to get a new one this year. It's pretty struggling now.
<rycee>
Hoping there will be a new Librem 15 available in the summer with usb-c charger.
<rycee>
By the way, perhaps you could try putting `systemd.user.services.gpg-agent.Install.WantedBy = [ "default.target" ];` in your configuration. Then it should start immediately.
<infinisil>
rycee: Ohh that would be nice, I'm already considering buying this Librem 15, but some new USB-C would be nice
<infinisil>
rycee: Oh that's true, I might try that
<infinisil>
Oh and btw, I just found "AddKeysToAgent: Specifies whether keys should be automatically added to a running ssh-agent" for ssh's config
<rycee>
Just saw some rumor about this new model on the purism reddit a while ago. Don't know if it's actually true.
<rycee>
Ah, that's a very handy option! I'll try it out tomorrow :-)
<infinisil>
Although, I'm considering using gpg keys instead, there's more support for handling those, and I won't need a new passphrase for every ssh key like that