| Age | Commit message (Collapse) | Author |
|---|
|
readable to other users. Otherwise, any user can open the lock file
for reading and lock it, thus DoSing the remote build mechanism.
|
|
closure to a given machine at the same time. This prevents the case
where multiple instances try to copy the same missing store path to
the target machine, which is very wasteful.
|
|
|
|
|
|
|
|
base-32. (This affects Hydra manifests.)
|
|
|
|
|
|
‘nix-store --export’.
* Add a Perl module that provides the functionality of
‘nix-copy-closure --to’. This is used by build-remote.pl so it no
longer needs to start a separate nix-copy-closure process. Also, it
uses the Perl API to do the export, so it doesn't need to start a
separate nix-store process either. As a result, nix-copy-closure
and build-remote.pl should no longer fail on very large closures due
to an "Argument list too long" error. (Note that having very many
dependencies in a single derivation can still fail because the
environment can become too large. Can't be helped though.)
|
|
|
|
read the manifest just to check the version and print the number of
paths. This makes nix-pull very fast for the cached cache (speeding
up nixos-rebuild without the ‘--no-pull’ or ‘--fast’ options).
|
|
disk space, and, since they're typically only decompressed once (to
fill the manifest cache), doesn't make things slower.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the Nix:: namespace.
|
|
|
|
not really supposed to use according to the DBD::SQLite docs, and
fails on some systems (e.g. http://hydra.nixos.org/build/1246662).
|
|
brackets, e.g.
import <nixpkgs/pkgs/lib>
are resolved by looking them up relative to the elements listed in
the search path. This allows us to get rid of hacks like
import "${builtins.getEnv "NIXPKGS_ALL"}/pkgs/lib"
The search path can be specified through the ‘-I’ command-line flag
and through the colon-separated ‘NIX_PATH’ environment variable,
e.g.,
$ nix-build -I /etc/nixos ...
If a file is not found in the search path, an error message is
lazily thrown.
|
|
if it doesn't exist.
|
|
SQLite manifest cache. The DBI AutoCommit feature caused every
process to have an active transaction at all times, which could
indefinitely block processes wanting to update the manifest cache.
* Disable fsync() in the manifest cache because we don't need
integrity (the cache can always be recreated if it gets corrupted).
|
|
doesn't work when building through the Nix daemon. This also
ensures an error message when the user doesn't have sufficient
privileges to do nix-pull.
|
|
them into memory. This brings memory use down to (more or less)
O(1). For instance, on my test case, the maximum resident size of
download-using-manifests while filling the DB went from 142 MiB to
11 MiB.
|
|
|
|
location to DBI and DBD::SQLite can be passed with --with-dbi and
--with-dbd-sqlite.
|
|
modules as well. So use symbolic field names everywhere (which is
nicer anyway).
|
|
|
|
This significantly speeds up the download-using-manifests
substituter, especially if manifests are very large. For instance,
one "nix-build -A geeqie" operation that updated four packages using
binary patches went from 18.5s to 1.6s. It also significantly
reduces memory use.
The cache is kept in /nix/var/nix/manifests/cache.sqlite. It's
updated automatically when manifests are added to or removed from
/nix/var/nix/manifests. It might be interesting to have nix-pull
store manifests directly in the DB, rather than storing them as
separate flat files, but then we would need a command line interface
to delete manifests from the DB.
|
|
and redundant anyway.
|
|
|
|
|
|
|
|
This caused a lot of "Use of uninitialized value" warnings from
Perl.
|
|
|
|
`+' and `?' in filenames. This is very slow if /nix/store is very
large. (This is a quick hack - a cleaner solution would be to
bypass the shell entirely.)
|
|
failure. The build hook can use this to distinguish between
transient and permanent failures on the remote side.
|
|
of expensive calls to `nix-store --check-validity'.
|
|
|
|
|
|
* Fix the binary patching test.
|
|
|
|
|
|
necessary because bsdiff has some pathological worst-case behaviour,
e.g. O(n^2) on files consisting only of 0s.
|
|
|
|
`nix-store -q --hash' to get the hash of the base path rather than
`nix-hash'. However, only do this for estimating the size of a
download, not for the actual substitution, because sometimes the
contents of store paths are modified (which they shouldn't, of
course).
|
|
Hopefully this doesn't slow things down too much.
|
|
will approximately require.
|
