Eelco Dolstra
Eelco Dolstra
Another option: Add a command `nix uninstall-nix`. That way you don't need to dig up an (un)install script.
Did you reset the VM between the first and the second run, or otherwise uncleanly shut down the VM? That's the only situation I can think of that would cause...
It performs a full `sync()` before every valid path registration. Since there can be hundreds of path registrations during Nix evaluation, this would be pretty expensive. (In fact, on heavily...
Some comments: - I'm wondering if it wouldn't be better to only run builders in the calling cgroup (rather than the entire worker). Otherwise there is a risk of priority...
It won't need to restore the cgroup if you only change the cgroup in the builder's child process, i.e., in initChild() in build.cc.
Hm, I don't think it's a good idea to make assumptions about the remote machine like this, i.e. appending a bunch of paths to `$PATH` in the hope that one...
Maybe it's better to do something like `ssh ... sh --login exec nix-store --serve`? I don't think it's ideal to make assumptions about the location of Nix on the remote...
How about `sh --login -i`?
Hm, what is the purpose of this PR? What is "adr"?
What was the issue here? I re-run `init.sh` all the time without any problems.