Age | Commit message (Collapse) | Author |
|
|
|
Otherwise, we will associate fixed-output derivations with outputs that
they did indeed produce, but which had the wrong hash. That's no good.
|
|
|
|
Add a fallback path in `queryPartialDerivationOutputMap` for daemons
that don't support it.
Also upstreams a couple methods from `SSHStore` to `RemoteStore` as this
is needed to handle the fallback path.
|
|
Fixes #3992.
|
|
When deploying a Hydra instance with current Nix master, most builds
would not run because of errors like this:
queue monitor: error: --- Error --- hydra-queue-runner
error: --- UsageError --- nix-daemon
not a content address because it is not in the form '<prefix>:<rest>': /nix/store/...-somedrv
The last error message is from parseContentAddress, which expects a
colon-separated string, however what we got here is a store path.
Looking at the worker protocol, the following message sent to the Nix
daemon caused the error above:
0x1E -> wopQuerySubstitutablePathInfos
0x01 -> Number of paths
0x16 -> Length of string
"/nix/store/...-somedrv"
0x00 -> Length of string
""
Looking at writeStorePathCAMap, the store path is indeed the first field
that's transmitted. However, readStorePathCAMap expects it to be the
*second* field *on my machine*, since expression evaluation order is a
classic form of unspecified behaviour[1] in C++.
This has been introduced in https://github.com/NixOS/nix/pull/3689,
specifically in commit 66a62b3189c8c9b0965850e6b3c9b0fda0b50fd8.
[1]: https://en.wikipedia.org/wiki/Unspecified_behavior#Order_of_evaluation_of_subexpressions
Signed-off-by: aszlig <aszlig@nix.build>
|
|
- More and better comments
- The easier renames
|
|
Thanks!
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
|
|
|
|
|
|
This means profiles outside of /nix/var/nix/profiles don't get
garbage-collected. It also means we don't need to scan
/nix/var/nix/profiles for GC roots anymore, except for compatibility
with previously existing generations.
|
|
|
|
|
|
|
|
|
|
|
|
Revise division of labor in deserialization of derivations
|
|
As pointed out by @B4dM4n, the call to to.flush() on stderrThread is
unsafe because the NAR writer thread is also writing to 'to'.
Fixes #3943.
|
|
|
|
DummyStore does not allow building or adding paths. This is useful for
evaluation tests when you don't want to initialize a "proper" store.
|
|
tabs -> spaces
|
|
|
|
Insead they should be opaque `/<hash>` like the placeholders we already
have.
|
|
Sorry I let the tab sneak in there in the first place.
|
|
|
|
- `queryDerivationOutputMapAssumeTotal` -> `queryPartialDerivationOutputMap`
- `queryDerivationOutputMapAssumeTotal` -> `queryDerivationOutputMap
|
|
`queryDerivationOutputMap` no longer assumes all outputs have a mapping
|
|
- `queryDerivationOutputMapAssumeTotal` -> `queryPartialDerivationOutputMap`
- `queryDerivationOutputMapAssumeTotal` -> `queryDerivationOutputMap`
|
|
|
|
This means we don't have two (divergent) sets of option descriptions
anymore.
|
|
derivation-header-include-order
|
|
Define `LegacySSHStore::buildPaths` using `cmdBuildPaths`
|
|
|
|
|
|
https://github.com/obsidiansystems/nix
|
|
|
|
|
|
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
Offer a safer interface for path and pathOpt
|
|
Make `system-features` a store setting
|
|
Add hashed-mirrors back
|
|
Make narHash in ValidPathInfo not optional
|
|
Evidentally this was never implemented because Nix switched to using
`buildDerivation` exclusively before `build-remote.pl` was rewritten.
The `nix-copy-ssh` test (already) tests this.
|
|
Include a long comment explaining the policy. Perhaps this can be moved
to the manual at some point in the future.
Also bump the daemon protocol minor version, so clients can tell whether
`wopBuildDerivation` supports trustless CA derivation building. I hope
to take advantage of this in a follow-up PR to support trustless remote
building with the minimal sending of derivation closures.
|
|
|
|
Fix `wopNarFromPath` which needed a `toRealPath`.
|
|
|
|
This seems more correct. It also means one can specify the features a
store should support with --store and remote-store=..., which is useful.
I use this to clean up the build remotes test.
|