cust0dian has quit [Ping timeout: 260 seconds]
Chiliparrot has joined #nix-darwin
cust0dian has joined #nix-darwin
<teehemkay> Hello. I'm repeatedly seeing the following error `cannot link '/nix/store/.tmp-link-46606-794821922' to '/nix/store/.links/0h0djvzb904ygckpvnblwanfz8fj4m7bv32js79b7z8p28s1nslz': File exists` whenever I try to rebuild and environment (`nix-darwin rebuild`). I need to issue the command several times (typically half a dozen times) until it finally succeeds.
<teehemkay> I've looked into the `/nix/store/.links/` folder and it contains several hundred thousands files.
<teehemkay> Is it safe to delete these files? Shouldn't there be some housekeeping to do that automatically?
<teehemkay> Thanks!
<teehemkay> To be clear, the error messages I'm seeing are a variation of the one above, not the same one repeatedly
<LnL> those get generated by nix-store --optimize
<LnL> not sure what could cause the issue you're describing however
__monty__ has joined #nix-darwin
__Sander__ has joined #nix-darwin
<teehemkay> Thanks. Btw running `nix-store --optimise` I get a lot of `skipping suspicious writable file '/nix/store/<blablabla>' messages.
<clever> teehemkay: try `nix-collect-garbage --max-freed 10m`
Chiliparrot has quit [Ping timeout: 265 seconds]
Chiliparrot has joined #nix-darwin
cust0dian has quit [Remote host closed the connection]
cust0dian has joined #nix-darwin
__Sander__ has quit [Quit: Konversation terminated!]
nikivi has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
nikivi has joined #nix-darwin
<teehemkay> @clever: thanks!
<__monty__> I think I mentioned my issue about a usb pen drive with nothing but a `.gnupg` directory on it being impossible to eject here before?
<__monty__> At the time I couldn't reproduce it. Figured a reboot fixed it?
<__monty__> Well, it just happened again so nothing's fixed.
<cransom> is there a gpg-agent process using it?
<__monty__> Ooh, that might be the issue yeah. I did access it with `gpg --homedir`. I've never started a gpg-agent on purpose but maybe that's done transparently?
<clever> __monty__: `ps aux | grep gpg`
<__monty__> Yep, that must be it. After I use --edit-key a gpg-agent is started.
<__monty__> What's the proper way to stop the agent? Kill it?
<clever> not sure
<cransom> you can just kill it
<cransom> it's a gpg2 thing where it automatically starts one in order to do some privilege separation.
<__monty__> Is there a way to make the gpg-agent give up the device automatically? finding the pid to kill is kind of an annoying extra step.
<cransom> pkill gpg-agent is close enough for my uses usually. it should only ever run as your user anyway
<__monty__> But the one for the .gnupg on my machine may be killed instead. Still requiring two extra steps.
<cransom> gpg-agent with a --no-detach so you remember to kill it when done?
<__monty__> But I don't start it explicitly so that's another extra step.
<__monty__> I guess there's no better way : /
<evelyn> gpgconf --kill all is the proper way to kill it
<evelyn> there are other things it might start depending on how you've configured it
<evelyn> e.g. scdaemon
<evelyn> and that will only kill it for you. it won't touch other users'
<__monty__> Maybe there's a better way to update offline keys than using `--homedir`? One that won't start all these things I then have to kill?
<cransom> if anyone has any suggestions for something less fiddly than gpg, i'm all ears too.
<evelyn> there is a good replacement for gpgv in sqv:
<evelyn> they are working on a proper successor to the whole suite.
<__monty__> That doesn't really help us rn though.
<__monty__> I don't interact with gpg enough to bother trying to use a less well-known tool either tbh.
<__monty__> I need something I can get help on easily.
<evelyn> lol in the manpage there is an option, --no-use-agent
<evelyn> This is dummy option. gpg always requires the agent.
<LnL> euh
<__monty__> SEO? For people trying to figure out how to stop the agent?
Ericson2314 has quit [*.net *.split]
<cransom> well, it was a previous behavior in gpg1 that you didn't have to use the agent (because it also didn't have one)
cust0dian has quit [Quit: WeeChat 2.7]
<__monty__> Then it can't possibly be an option inherited from that version?
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Ericson2314 has joined #nix-darwin
Ericson2314 has quit [*.net *.split]
johnw has joined #nix-darwin
<johnw> LnL: the way is written, you cannot say --option builders ''
<LnL> yeah... I should fix that
<LnL> actually it's implemented properly, I just used test -z for some bizar reason
Ericson2314 has joined #nix-darwin
<johnw> yeah, that's what I was wondering :)
<johnw> the `-z` is totally legit on the first argument after --option
<johnw> does this ring any bells:
<johnw> Vulcan ~ $ nix copy --all --to 'ssh://hermes?store=/Volumes/G-DRIVE/nix'
<johnw> error: path '/nix/store/000ghyr3m1n42mlsk6xagpjkiw722f4n-binutils-wrapper-2.31.1.drv' is not in the Nix store
<johnw> that path most definitely *is* in the given path
<johnw> s/path$/store
<LnL> kind of sounds like a bug
<LnL> can you copy a drv that way?
<johnw> no
<johnw> if I try to copy just that file, same error
<LnL> the new protocol might work
<johnw> what is that?
<johnw> ssh-ng?
<LnL> yeah
<johnw> error: cannot open connection to remote store 'ssh-ng://hermes': changing owner of directory '/nix/var/nix/profiles/per-user/root': Operation not permitted
<johnw> interesting
<LnL> that one probably doesn't support the store query param
<LnL> try ssh-ng://$host?store=$vol/nix/store&state=$vol/nix/var/nix
<johnw> k
<johnw> note that this is not a regular nix store
<johnw> the place I'm trying to 'nix copy' to was created by running:
<johnw> nix copy --all --to file:///path/nix on that machine
<johnw> which worked, resulting in a directory full of narinfo files
<johnw> so, there's no /store on /var subdirectories
<LnL> ah it's a file:// store
<johnw> yes
<johnw> I want to use ssh to pipe stuff over to another store
<LnL> not sure that's possible
<johnw> sshfs maybe
<LnL> store/state are the generic store options
<LnL> only the legacy ssh implementation has the remote-store parameter
<johnw> what I really want here is a way to cache all my store contents onto an external SSD, so that when I have poor Internet access and need to grab something I'd already grabbed in the recent past, it's easy to do
<LnL> nix copy --to file:// to a mount will definitively work
<johnw> right, but the machine which is building the majority of the things I want to cache, isn't that machine
<johnw> so, before I take machine R and its SSD off for a trip, I want to update the SSD with the store from my main machine M
<johnw> at the moment, Nix offers no good way to do this
<johnw> I'll try sshfs
<LnL> adding remote-store looks pretty easy at first glance
<LnL> alternatively you could build something streaming on top of nix-store --dump <path> but that's kind of awkward
<clever> LnL: have you seen local?root and store-uri=?
<LnL> hm?
<clever> nix copy --to ssh://root@target?remote-store=local?root=/mnt /nix/store/hash-nixos
<clever> LnL: `local?root=/mnt` will tell nix to prefix everything with /mnt (similar to a chroot)
<clever> so you can act on /mnt/nix/store, without needing a mass rebuild (but it only works if you then chroot /mnt)
<LnL> yeah why?
<clever> ssh://user@target?remote-store=, accepts a store URI
<clever> which can be a local?root=
<LnL> it's linux only tho (for builds)
<clever> LnL: what was the actual problem? i didnt read it that closely
<LnL> clever: yeah that's where we started :) ssh:// fails with drvs
<clever> LnL: i think its that `nix copy` cant deal with drv's, only nix-copy-closure
<LnL> doesn't look like it
<LnL> regardless ssh-ng://host?remote-store= would be useful
<LnL> well that was trivial
<johnw> LnL: do you have an answer?
<LnL> 1 sec
<johnw> nice!
<johnw> unrelated question: do you know why, on Linux, `nproc` would always report 1 after entering a nix-shell? It doesn't happen on Darwin
<LnL> you also don't need any changes on the remote side
<johnw> but I'd have to rebuild Nix on the local side
<LnL> yeah, unless you setup some ssh key shenanigans as a workaround
<johnw> ooh... how would I shenanigize?
<LnL> setup a new keypair that always uses the file store you want to copy from/to
<__monty__> Could the nproc thing be because of sandboxing?
<__monty__> That's still not enabled by default on darwin afaik?
<__monty__> Does sound sensible for reproducibility as well though.
<LnL> could be patched out for reproducibility somehow
<LnL> the sandbox isn't involved in shells
<__monty__> Even --pure shells? (I know that wasn't mentioned. Just trying to learn now.)
<LnL> that only clears the environment
<LnL> so other binaries, etc. won't be in PATH anymore and are less likely to leak but thinks like cmake can still find system stuff
<__monty__> Got it, thanks.
<__monty__> Good luck on the other issues : )
<LnL> johnw: oh also 590e9c872a850e970f9b5ba1d2428ec030fb7455
__monty__ has quit [Quit: leaving]
<johnw> ah, that's clever