| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
in sys/personality.h).
|
|
(e.g. an SSH connection problem) and permanent failures (i.e. the
builder failed). This matters to Hydra (it wants to know whether it
makes sense to retry a build).
|
|
|
|
installations. This is implemented using the personality() syscall,
which causes uname to return "i686" in child processes.
|
|
|
|
years of loyal service :-)
|
|
|
|
|
|
interrupted build).
|
|
links to the inputs.
|
|
if they belong a path that's currently being built. This gets rid
of some Cygwin-specific code.
|
|
|
|
|
|
allocate memory, which is verboten in signal handlers. This caused
random failures in the test suite on Mac OS X (triggered by the spurious
SIGPOLL signals on Mac OS X, which should also be fixed).
|
|
accidentally bind-mount a directory twice.
|
|
(http://hydra.nixos.org/nixlog/384/1).
|
|
closure of the inputs. This really enforces that there can't be any
undeclared dependencies on paths in the store. This is done by
creating a fake Nix store and creating bind-mounts or hard-links in
the fake store for all paths in the closure. After the build, the
build output is moved from the fake store to the real store. TODO:
the chroot has to be on the same filesystem as the Nix store for
this to work, but this isn't enforced yet. (I.e. it only works
currently if /tmp is on the same FS as /nix/store.)
|
|
don't have to put the chroot in /nix/var/nix/chroots anymore.
They're back in /tmp now.
|
|
happy.
|
|
bind-mounts we do are only visible to the builder process and its
children. So accidentally doing "rm -rf" on the chroot directory
won't wipe out /nix/store and other bind-mounted directories
anymore. Also, the bind-mounts in the private namespace disappear
automatically when the builder exits.
|
|
read-only operations (like nix-env -qa) work properly when the
daemon isn't running.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
makes more sense for the build farm, otherwise every nix-store
invocation will lead to at least one local build. Will come up with
a better solution later...
|
|
|
|
necessary that at least one build hook doesn't return "postpone",
otherwise nix-store will barf ("waiting for a build slot, yet there
are no running children"). So inform the build hook when this is
the case, so that it can start a build even when that would exceed
the maximum load on a machine.
|
|
nix-store process when the connection is interrupted.
|
|
nix-store -r (or some other operation) is started via ssh, it will
at least have a chance of terminating quickly when the connection is
killed. Right now it just runs to completion, because it never
notices that stderr is no longer connected to anything. Of course
it would be better if sshd would just send a SIGHUP, but it doesn't
(https://bugzilla.mindrot.org/show_bug.cgi?id=396).
|
|
list like
root@example.org x86_64-linux /root/.ssh/id_buildfarm 1
root@example.org i686-darwin /root/.ssh/id_buildfarm 1
This is possible when the Nix installation on example.org itself has
remote builds enabled.
|
|
|
|
derivation should be a source rather than a derivation dependency of
the call to the NAR derivation. Otherwise the derivation (and all
its dependencies) will be built as a side-effect, which may not even
succeed.
|
|
the client to a temporary directory, as that is highly inefficient.
|
|
|
|
|
|
|
|
|
|
being copied 3 times in the worst case. It doesn't run in constant space,
but it didn't do that anyway.
|
|
SHA-256 outputs of fixed-output derivations. I.e. they now produce
the same store path:
$ nix-store --add x
/nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x
$ nix-store --add-fixed --recursive sha256 x
/nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x
the latter being the same as the path that a derivation
derivation {
name = "x";
outputHashAlgo = "sha256";
outputHashMode = "recursive";
outputHash = "...";
...
};
produces.
This does change the output path for such fixed-output derivations.
Fortunately they are quite rare. The most common use is fetchsvn
calls with SHA-256 hashes. (There are a handful of those is
Nixpkgs, mostly unstable development packages.)
* Documented the computation of store paths (in store-api.cc).
|
|
|
|
|
|
|
|
close tags.
|
|
|
|
|
