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
|
|
Gracefully handle duplicate realisations
|
|
Make `nix develop` work with CA derivations
|
|
Should always hold, but that’s not necessarily obvious, so better
enforce it
|
|
|
|
|
|
|
|
|
|
Make `nix-shell` support content-addressed derivations
|
|
Recursively substitute the realisations
|
|
Make `computeFSClosure` ca-aware
|
|
Add a ca-derivations required machine feature
|
|
Fix the remote build of CA derivations
|
|
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>
|
|
This shouldn’t happen in practice, so better make it explicit
|
|
|
|
Always send the realisations as JSON
|
|
Remove a possible existing store path when building CA derivations
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
Fix #4925
|
|
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
|
|
Make sure that the derivation we send to the remote builder is exactly
the one that we want to build locally so that the output ids are exactly
the same
Fix #4845
|
|
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
|
|
When recursive Nix is enabled, NIX_REMOTE is set to
unix:///build/.nix-socket, which doesn't work outside of the sandbox.
|
|
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 #4823
|
|
Resolve the derivation before trying to load its environment −
essentially reproducing what the build loop does − so that we can
effectively access our dependencies (and not just their placeholders).
Fix #4821
|
|
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.
|
|
|
|
|
|
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
This function might or might not throw depending on the value of
`keepGoing`, so naming it `throw_` was a bit confusing
|
|
When the `keep-going` option is set to `true`, make `nix flake check`
continue as much as it can before failing.
The UI isn’t perfect as-it-is as all the lines currently start with a
mostly useless `error (ignored): error:` prefix, but I’m not sure what
the best output would be, so I’ll leave it as-it-is for the time being
(This is a bit hijacking the `keep-going` flag as it’s supposed to be a
build-time only thing. But I think it’s faire to reuse it here).
Fix https://github.com/NixOS/nix/issues/4450
|
|
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
|
|
Fix typo in documentation
|
|
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.
|
|
|
|
|