| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
"nix-channel --add" now accepts a second argument: the channel name.
This allows channels to have a nicer name than (say) nixpkgs_unstable.
If no name is given, it defaults to the last component of the URL
(with "-unstable" or "-stable" removed).
Also, channels are now stored in a profile
(/nix/var/nix/profiles/per-user/$USER/channels). One advantage of
this is that it allows rollbacks (e.g. if "nix-channel --update" gives
an undesirable update).
|
|
|
|
so that network progress is what's measured
|
|
|
|
|
|
|
|
If we don't follow redirects, we might think that MANIFEST.bz2 exists
just because the HEAD request succeeds on the redirector URI.
|
|
|
|
Sometimes when doing "nix-build --run-env" you don't want all
dependencies to be built. For instance, if we want to do "--run-env"
on the "build" attribute in Hydra's release.nix (to get Hydra's build
environment), we don't want its "tarball" dependency to be built. So
we can do:
$ nix-build --run-env release.nix -A build --exclude 'hydra-tarball'
This will skip the dependency whose name matches the "hydra-tarball"
regular expression. The "--exclude" option can be repeated any number
of times.
|
|
--command
|
|
This command builds or fetches all dependencies of the given
derivation, then starts a shell with the environment variables from
the derivation. This shell also sources $stdenv/setup to initialise
the environment further.
The current directory is not changed. Thus this is a convenient way
to reproduce a build environment in an existing working tree.
Existing environment variables are left untouched (unless the
derivation overrides them). As a special hack, the original value of
$PATH is appended to the $PATH produced by $stdenv/setup.
Example session:
$ nix-build --run-env '<nixpkgs>' -A xterm
(the dependencies of xterm are built/fetched...)
$ tar xf $src
$ ./configure
$ make
$ emacs
(... hack source ...)
$ make
$ ./xterm
|
|
We're already printing progress on stderr, so printing them on stdout
afterwards is kind of useless.
|
|
|
|
In the build hook, don't wait forever to get the upload lock. This
ensures progress if another process gets stuck while holding the
upload lock.
|
|
directory. Previously in this situation we did add the Nix
expressions from the channel to allow installation from source, but
this doesn't work for binary-only channels and leads to confusing
error messages.
|
|
directory rather than the current directory.
* nix-build: --drv-link now implies --add-drv-link.
|
|
|
|
scripts.
* Include the version and architecture in the -I flag so that there is
at least a chance that a Nix binary built for one Perl version will
run on another version.
|
|
* Refactor the nix-channel unpacker a bit.
|
|
|
|
other simplifications.
* Use <nix/...> to locate the corepkgs. This allows them to be
overriden through $NIX_PATH.
* Use bash's pipefail option in the NAR builder so that we don't need
to create a temporary file.
|
|
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).
|
