| Age | Commit message (Collapse) | Author |
|---|
|
|
|
A few versioning mistakes were corrected:
- In 27b5747ca7b5599768083dde5fa4d36bfbb0f66f, Daemon protocol had some
version `>= 0xc` that should have been `>= 0x1c`, or `28` since the
other conditions used decimal.
- In a2b69660a9b326b95d48bd222993c5225bbd5b5f, legacy SSH gated new CAS
info on version 6, but version 5 in the server. It is now 6
everywhere.
Additionally, legacy ssh was sending over more metadata than the daemon
one was. The daemon now sends that data too.
CC @regnat
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
|
|
It was in the header but never implemented.
|
|
obsidiansystems/derivation-goal-detect-invalid-output
Throw error for derivation goal with bogus wanted output
|
|
Restore now-working build-remote-content-addressed-fixed test
|
|
Don't let them inherit the signature from the parent one (because it
makes no sense to do so), but re-sign them after they have been built
|
|
Broken atm
|
|
I guess the rationale behind the old name wath that
`pathInfoIsTrusted(info)` returns `true` iff we would need to `blindly`
trust the path (because it has no valid signature and `requireSigs` is
set), but I find it to be a really confusing footgun because it's quite
natural to give it the opposite meaning.
|
|
Not exposed anywhere, but built realisations are now signed (and this
should be forwarded when copy-ing them around)
|
|
Substitute content-addressed derivations
|
|
|
|
There were done when StorePath was defined in Rust and there were some
FFI issues. This is no longer an issue.
|
|
|
|
- UsageError -> Error
- include drv path too
|
|
|
|
To prepare for the upcoming DrvOutputSubstitutionGoal
|
|
libstore: support passing a builder's public SSH host key
|
|
|
|
What happened was that Nix was trying to unconditionally mount these
paths in fixed-output derivations, but since the outer derivation was
pure, those paths did not exist. The solution is to only mount those
paths when they exist.
|
|
|
|
|
|
|
|
This separates the scheduling logic (including simple hook pathway) from
the local-store needing code.
This should be the final split for now. I'm reasonably happy with how
it's turning out, even before I'm done moving code into
`local-derivation-goal`. Benefits:
1. This will help "witness" that the hook case is indeed a lot simpler,
and also compensate for the increased complexity that comes from
content-addressed derivation outputs.
2. It also moves us ever so slightly towards a world where we could use
off-the-shelf storage or sandboxing, since `local-derivation-goal`
would be gutted in those cases, but `derivation-goal` should remain
nearly the same.
The new `#if 0` in the new files will be deleted in the following
commit. I keep it here so if it turns out more stuff can be moved over,
it's easy to do so in a way that preserves ordering --- and thus
prevents conflicts.
N.B.
```sh
git diff HEAD^^ --color-moved --find-copies-harder --patience --stat
```
makes nicer output.
|
|
Doing this prior to splitting, so we get better diff with default
options (e.g. on GitHub).
|
|
Build ca derivations remotely
|
|
|
|
|
|
|
|
|
|
The experimental feature was by mistake required for `nix copy` to work
at oll
|
|
Mostly removing useless comments and adding spaces before `&`
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
This should already hold, but better ensure it for future-proof-nees
|
|
Rather throw a proper exception, and catch&log it on the client side
|
|
That way we can copy the realisations too (in addition to the store
paths themselves)
|
|
This is already used by Hydra, and is very useful when materializing
a remote builder list from service discovery. This allows the service
discovery tool to only sync one file instead of two.
|
|
This is technically a breaking change, since attempting to set plugin
files after the first non-flag argument will now throw an error. This
is acceptable given the relative lack of stability in a plugin
interface and the need to tie the knot somewhere once plugins can
actually define new subcommands.
|
|
We know the flag will be ignored but the user wants it to take effect.
|
|
Add x86_64 compute levels as system features
|
|
This field used to be a `BasicDerivation`, but this `BasicDerivation`
was downcasted to a `Derivation` when needed (implicitely or not), so we
might as well make it a full `Derivation` and upcast it when needed.
This also allows getting rid of a weird duplication in the way we
compute the static output hashes for the derivation. We had to
do it differently and in a different place depending on whether the
derivation was a full derivation or just a basic drv, but we can now do
it unconditionally on the full derivation.
Fix #4559
|
|
There was already some logic for that, but it didn't handle the case of
content-addressed outputs, so extend it a bit for that
|
|
Otherwise they don't get registered, triggering an assertion failure
at some point later
|
|
To allow it to build ca derivations remotely
|
|
To allow it to build ca derivations remotely
|
|
To allow it to build ca derivations remotely
|
|
- Pass it the name of the outputs rather than their output paths (as
these don't exist for ca derivations)
- Get the built output paths from the remote builder
- Register the new received realisations
|
|
|
|
When performing distributed builds of machine learning packages, it
would be nice if builders without the required SIMD instructions can
be excluded as build nodes.
Since x86_64 has accumulated a large number of different instruction
set extensions, listing all possible extensions would be unwieldy.
AMD, Intel, Red Hat, and SUSE have recently defined four different
microarchitecture levels that are now part of the x86-64 psABI
supplement and will be used in glibc 2.33:
https://gitlab.com/x86-psABIs/x86-64-ABI
https://lwn.net/Articles/844831/
This change uses libcpuid to detect CPU features and then uses them to
add the supported x86_64 levels to the additional system types. For
example on a Ryzen 3700X:
$ ~/aps/bin/nix -vv --version | grep "Additional system"
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
|
|
It isn't needed anymore now that don't need to eagerly resolve
everything like we used to do. So we can safely get rid of it
|
|
That way we
1. Don't have to recompute them several times
2. Can compute them in a place where we know the type of the parent
derivation, meaning that we don't need the casting dance we had before
|
|
It's not fixed nor useful atm, so better keep it hidden
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
