| Age | Commit message (Collapse) | Author |
|---|
|
Fix #4026
|
|
This isn't used anywhere except in the configure script of the Perl
bindings. I've changed the latter to use the C++ API's Settings object
at runtime.
|
|
remove-storetype-delegate-regStore
|
|
|
|
Doesn't test much, but at least ensures that the command runs properly
|
|
|
|
remove-storetype-delegate-regStore
|
|
Otherwise the result of the printing can't be parsed back correctly by
Nix (because the unescaped `${` will be parsed as the begining of an
anti-quotation).
Fix #3989
|
|
Co-authored-by: lf- <lf-@users.noreply.github.com>
|
|
ca-floating-upstream
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
We will sometimes try to query the outputs of derivations we can't
resolve. That's fine; it just means we don't know what those outputs are
yet.
|
|
ca-floating-upstream
Tests also now fail as they should
|
|
|
|
|
|
ca-floating-upstream
|
|
|
|
All GC roots are now indirect.
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
DummyStore does not allow building or adding paths. This is useful for
evaluation tests when you don't want to initialize a "proper" store.
|
|
|
|
|
|
Add commented-out test for remote building with fixed output derivations
|
|
|
|
|
|
|
|
|
|
Make `system-features` a store setting
|
|
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.
|
|
Before, processConnection wanted to know a user name and user id, and
`nix-daemon --stdio`, when it isn't proxying to an underlying daemon,
would just assume "root" and 0. But `nix-daemon --stdio` (no proxying)
shouldn't make guesses about who holds the other end of its standard
streams.
Now processConnection takes an "auth hook", so `nix-daemon` can provide
the appropriate policy and daemon.cc doesn't need to know or care what
it is.
|
|
into single-ca-drv-build
|
|
|
|
These are not supposed to include the 'name' part of the store
path. This was broken by 759947bf72.
|
|
It is in fact more sorted than before, but I don't think we want to
guarantee anything about the ordering.
|
|
|
|
|
|
|
|
|
|
If a repo is dirty, it used to return a `rev` object with an "empty"
sha1 (0000000000000000000000000000000000000000). Please note that this
only applies for `builtins.fetchGit` and *not* for `builtins.fetchTree{
type = "git"; }`.
|
|
The original idea was to implement a git-fetcher in Nix's core that
supports content hashes[1]. In #3549[2] it has been suggested to
actually use `fetchTree` for this since it's a fairly generic wrapper
over the new fetcher-API[3] and already supports content-hashes.
This patch implements a new git-fetcher based on `fetchTree` by
incorporating the following changes:
* Removed the original `fetchGit`-implementation and replaced it with an
alias on the `fetchTree` implementation.
* Ensured that the `git`-fetcher from `libfetchers` always computes a
content-hash and returns an "empty" revision on dirty trees (the
latter one is needed to retain backwards-compatibility).
* The hash-mismatch error in the fetcher-API exits with code 102 as it
usually happens whenever a hash-mismatch is detected by Nix.
* Removed the `flakes`-feature-flag: I didn't see a reason why this API
is so tightly coupled to the flakes-API and at least `fetchGit` should
remain usable without any feature-flags.
* It's only possible to specify a `narHash` for a `git`-tree if either a
`ref` or a `rev` is given[4].
* It's now possible to specify an URL without a protocol. If it's missing,
`file://` is automatically added as it was the case in the original
`fetchGit`-implementation.
[1] https://github.com/NixOS/nix/pull/3216
[2] https://github.com/NixOS/nix/pull/3549#issuecomment-625194383
[3] https://github.com/NixOS/nix/pull/3459
[4] https://github.com/NixOS/nix/pull/3216#issuecomment-553956703
|
|
|
|
|
|
|
