Age | Commit message (Collapse) | Author | Files | Lines |
|
For security reasons, daemon users can only specify caches that appear
in the ‘binary-caches’ and ‘trusted-binary-caches’ options in
nix.conf.
|
|
|
|
|
|
|
|
Put all Nix configuration flags in a Settings object.
|
|
|
|
|
|
|
|
You can use ‘--option binary-caches URLs’ instead.
|
|
The .nixpkg file format is extended to optionally include the URL of a
binary cache, which will be used in preference to the manifest URL
(which can be set to a non-existent value).
|
|
Previously substituters could read nix.conf themselves, but this
didn't take --option flags into account.
|
|
|
|
|
|
Querying all substitutable paths via "nix-env -qas" is potentially
hard on a server, since it involves sending thousands of HEAD
requests. So a binary cache must now have a meta-info file named
"nix-cache-info" that specifies whether the server wants this. It
also specifies the store prefix so that we don't send useless queries
to a binary cache for a different store prefix.
|
|
|
|
|
|
Since SubstitutionGoal::finished() in build.cc computes the hash
anyway, we can prevent the inefficiency of computing the hash twice by
letting the substituter tell Nix about the expected hash, which can
then verify it.
|
|
|
|
Instead call curl directly and pipe it into ‘nix-store --restore’.
This saves I/O and prevents creating garbage in the Nix store.
|
|
|
|
|
|
This makes all the tests succeed. Woohoo!
|
|
|
|
|
|
|
|
|
|
The file:// URI schema requires checking for errors in a more general
way. Also, don't cache file:// lookups.
|
|
|
|
|
|
Fixes #39.
|
|
Commit 6a214f3e06fa1c5f0a4d40e555f14d87691af297 reused the NixOS
environment initialisation for nix-profile.sh, but this is
inappropriate on systems that don't have multi-user support enabled.
|
|
|
|
heap just in case it escapes the stack frame.
|
|
|
|
attrset.
The generated attrset has drvPath and outPath with the right string context, type 'derivation', outputName with
the right name, all with a list of outputs, and an attribute for each output.
I see three uses for this (though certainly there may be more):
* Using derivations generated by something besides nix-instantiate (e.g. guix)
* Allowing packages provided by channels to be used in nix expressions. If a channel installed a valid deriver
for each package it provides into the store, then those could be imported and used as dependencies or installed
in environment.systemPackages, for example.
* Enable hydra to be consistent in how it treats inputs that are outputs of another build. Right now, if an
input is passed as an argument to the job, it is passed as a derivation, but if it is accessed via NIX_PATH
(i.e. through the <> syntax), then it is a path that can be imported. This is problematic because the build
being depended upon may have been built with non-obvious arguments passed to its jobset file. With this
feature, hydra can just set the name of that input to the path to its drv file in NIX_PATH
|
|
|
|
E.g. Darwin doesn't allow this.
|
|
|
|
|
|
Incremental optimisation requires creating links in /nix/store/.links
to all files in the store. However, this means that if we delete a
store path, no files are actually deleted because links in
/nix/store/.links still exists. So we need to check /nix/store/.links
for files with a link count of 1 and delete them.
|
|
Auto-optimisation is enabled by default. It can be turned off by
setting auto-optimise-store to false in nix.conf.
|
|
optimiseStore() now creates persistent, content-addressed hard links
in /nix/store/.links. For instance, if it encounters a file P with
hash H, it will create a hard link
P' = /nix/store/.link/<H>
to P if P' doesn't already exist; if P' exist, then P is replaced by a
hard link to P'. This is better than the previous in-memory map,
because it had the tendency to unnecessarily replace hard links with a
hard link to whatever happened to be the first file with a given hash
it encountered. It also allows on-the-fly, incremental optimisation.
|
|
|
|
Also use utimes() instead of utime() if lutimes() is not available.
|
|
|
|
|
|
|
|
|
|
|
|
|