| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
users.
* Change to base-32 hashes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
unique.
* Drop `hashAlgo' attribute in manifests; prefix hashes with the hash
algorithm instead.
|
|
file names in the directory not included in any of the manifests
specified on the command line.
|
|
|
|
* nix-prefecth-url: print out in base-16.
|
|
expressions.
|
|
conditional expression in the blacklist can specify when to
continue/stop a traversal. For example, in
<condition>
<within>
<traverse>
<not><hasAttr name='outputHash' value='.+' /></not>
</traverse>
<hasAttr name='outputHash' value='ef1cb003448b4a53517b8f25adb12452' />
</within>
</condition>
we traverse the dependency graph, not following the dependencies of
`fetchurl' derivations (as indicated by the presence of an
`outputHash' attribute - this is a bit ugly). The resulting set of
paths is scanned for a fetch of a file with the given hash, in this
case, the hash of zlib-1.2.1.tar.gz (which has a security bug). The
intent is that a dependency on zlib is not a problem if it is in a
`fetchurl' derivation, since that's build-time only. (Other
build-time uses of zlib *might* be a problem, e.g., static linking.)
|
|
|
|
Maybe this is a bad idea.
|
|
checked against every item in a blacklist.
|
|
|
|
|
|
* Maintain the cleanup invariant in clearSubstitutes().
|
|
|
|
store path (which is stored in the database).
|
|
|
|
|
|
occurances of a component. If the shortest path distance between a
component P and Q in the referers graph is D, then the contribution
of Q to the use of P is 1 / R^D, where R >= 1, typically 2. This
expresses that distant indirect uses are less important than nearby
uses.
For instance, this can disambiguate between the bootstrap GCC in
Nixpkgs and the GCC of the final stdenv (the former has more uses,
but they are further away), and between the GCC of the final stdenv
and the GCC+G77 build (the latter has very few uses).
|
|
name but differ to much in sice (by more than a factor of 3), then
never generate a patch.
|
|
|
|
|
|
by the build farm. See e.g.,
http://catamaran.labs.cs.uu.nl/dist/nixpkgs-0.8/nixpkgs-0.7pre2302/;
the user can click on packages, and they will be installed (assuming
the `application/nix-package' MIME type has been associated with
`nix-install-package').
Nix expressions are no longer involved: a "package" is just a
pointer to a manifest, and the top-level store derivation to be
added to the user environment. This makes these packages
independent from Nix expression evolution.
Note that we install the store derivation ($drvPath), not the
resulting output path ($outPath). This is equivalent, except that
installing the derivation maintains the back-link from the output
path to the derivation that built it. This is useful for
maintenance.
* Automatically re-exec in an xterm so that the user sees something
when `nix-install-package' is run from a browser.
|
|
too.
* Change the default hash for nix-prefetch-url back to md5, since
that's what we use in Nixpkgs (for now; a birthday attack is rather
unlikely there).
|
|
|
|
continue building when one fails unless `--keep-going' is
specified.
* When `--keep-going' is specified, print out the set of failing
derivations at the end (otherwise it can be hard to find out which
failed).
|
|
NAR dump of the path).
|
|
in `fetchurl' in Nix <= 0.7, but doesn't in Nix 0.8.
|
|
multiple times is also a top-level goal, then the second and later
instantiations would never be created because there would be a
stable pointer to the first one that would keep it alive in the
WeakGoalMap.
* Some tracing code for debugging this kind of problem.
|
|
|
|
of the given derivation. Useful for getting a quick overview of how
something was built. E.g., to find out how the `baffle' program in
your user environment was built, you can do
$ nix-store -q --tree $(nix-store -qd $(which baffle))
Tree nesting depth is minimised (?) by topologically sorting paths
under the relation A < B iff A \in closure(B).
|
|
|
