| Age | Commit message (Collapse) | Author |
|---|
|
Eventually delete the CA paths lock files
|
|
Make the CA tests actually test something
|
|
Mark the lockfiles as having to eventually be deleted so that they don’t
stay laying around in the store at the end of the build
Fix #4936
|
|
Add an access-control list to the realisations in recursive-nix (similar
to the already existing one for store paths), so that we can build
content-addressed derivations in the restricted store.
Fix #4353
|
|
Fix #4837
|
|
Should always hold, but that’s not necessarily obvious, so better
enforce it
|
|
|
|
|
|
|
|
|
|
Recursively substitute the realisations
|
|
Make `computeFSClosure` ca-aware
|
|
Add a ca-derivations required machine feature
|
|
Track the dependencies of CA realisations
|
|
|
|
|
|
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
Rather than copying them around everywhere
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
|
|
Always send the realisations as JSON
|
|
In case a previous interrupted build left a garbage path laying around,
remove it before trying to move the path to its final location.
Fix #4858
|
|
Useful when we're using a daemon with a chroot store, e.g.
$ NIX_DAEMON_SOCKET_PATH=/tmp/chroot/nix/var/nix/daemon-socket/socket nix-daemon --store /tmp/chroot
Then the client can now connect with
$ nix build --store unix:///tmp/chroot/nix/var/nix/daemon-socket/socket?root=/tmp/chroot nixpkgs#hello
|
|
That doesn’t really make sense with CA derivations (and wasn’t even
really correct before because of FO derivations, though that probably
didn’t matter much in practice)
|
|
Fix #4820 by preventing nix-collect garbage from crashing if
`keep-outputs` or `keep-derivations` is true
|
|
Make ca-derivations require a `ca-derivations` machine feature, and
ca-aware builders expose it.
That way, a network of builders can mix ca-aware and non-ca-aware
machines, and the scheduler will send them in the right place.
|
|
When adding a path to the local store (via `LocalStore::addToStore`),
ensure that the `ca` field of the provided `ValidPathInfo` does indeed
correspond to the content of the path.
Otherwise any untrusted user (or any binary cache) can add arbitrary
content-addressed paths to the store (as content-addressed paths don’t
need a signature).
|
|
Only link with libdl on Linux
|
|
unified macro style for ENABLE_S3
|
|
Linux is (as far as I know) the only mainstream operating system that
requires linking with libdl for dlopen. On BSD, libdl doesn't exist,
so on non-FreeBSD BSDs linking will currently fail. On macOS, it's
apparently just a symlink to libSystem (macOS libc), presumably
present for compatibility with things that assume Linux.
So the right thing to do here is to only add -ldl on Linux, not to add
it for everything that isn't FreeBSD.
|
|
Make sure that whenever we substitute a realisation, we also substitute
its entire closure
|
|
|
|
|
|
Otherwise registering the realisations on the remote side might fail as
it now expects a complete closure
|
|
|
|
Only considers the closure in term of `Realisation`, ignores all the
opaque inputs.
Dunno whether that’s the nicest solution, need to think it through a bit
|
|
|
|
Currently never used, nor set but will be useful shortly
|
|
Align all the worker protocol with `buildDerivation` which inlines the
realisations as one opaque json blob.
That way we don’t have to bother changing the remote store protocol
when the definition of `Realisation` changes, as long as we keep the
json backwards-compatible
|
|
|
|
It makes much more sense to have the Nar hash be a plain straight hash
rather than a hash modulo
|
|
Align all the worker protocol with `buildDerivation` which inlines the
realisations as one opaque json blob.
That way we don’t have to bother changing the remote store protocol
when the definition of `Realisation` changes, as long as we keep the
json backwards-compatible
|
|
Move the `closure` logic of `computeFSClosure` to its own (templated) function.
This doesn’t bring much by itself (except for the ability to properly
test the “closure” functionality independently from the rest), but it
allows reusing it (in particular for the realisations which will require
a very similar closure computation)
|
|
Enforce the use of properly built paths in libcmd
|
|
Replace `DerivedPathWithHints` by a new `BuiltPath` type that serves as
a proof that the corresponding path has been built.
|
|
For whatever reason, many programs trying to access SystemVersion.plist
also open SystemVersionCompat.plist; this includes Python code and
coreutils’ `cat(1)` (but not the native macOS `/bin/cat`). Illustratory
`dtruss(1m)` output:
open("/System/Library/CoreServices/SystemVersion.plist\0", 0x0, 0x0) = 3 0
open("/System/Library/CoreServices/SystemVersionCompat.plist\0", 0x0, 0x0) = 4 0
I assume this is a Big Sur change relating to the 10.16.x/11.x
version compatibility divide and that it’s something along the lines of
a hook inside libSystem.
Fixes a lot of sandboxed package builds under Big Sur.
|
|
Relock wait for build slot goals
|
|
Fix tokenize output names in DerivedPath
|
|
This should fix the issue described in
https://discourse.nixos.org/t/derivation-does-not-have-wanted-outputs-dev-out/12905.
Specifically, we get an error of
error: derivation '/nix/store/_.drv' does not have wanted outputs 'dev,out'
when a path like /nix/store/_.drv!dev,out is sent to the daemon.
|
|
When we don’t have enough free job slots to run a goal, we put it in
the waitForBuildSlot list & unlock its output locks. This will
continue from where we left off (tryLocalBuild). However, we need the
locks to get reacquired when/if the goal ever restarts. So, we need to
send it back through tryToBuild to get reqacquire those locks.
I think this bug was introduced in
https://github.com/NixOS/nix/pull/4570. It leads to some builds
starting without proper locks.
|
|
Just a renaming for now
|
