Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Once upon a time, I wrote my bachelors thesis about functional
deployment mechanisms.
I had to evaluate several szenarios where package management and
deployment were relevant. One szenario was to do distributed builds
over several machines.
I told myself: Weee, nix can do this! And with nix, this is actually
save, as you do not have side effects when building!
So I started. I use a cloud to set up four virtual machines where I
wanted to do the build. A fifth machine was used as master to distribute
the builds. All was good.
I created the necessary SSH keys, made sure every machine was reachable
by the master and configured the build in my remotes.conf.
When I started to try to build weechat from source, the build failed. It
failed, telling me
error: unable to start any build; either increase ‘--max-jobs’ or enable distributed builds
And I started to dig around. I digged long and good. But I wasn't able
to find the issue.
I double and triple checked my environment variables, my settings, the
SSH key and everything.
I reached out to fellow Nixers by asking on the nixos IRC channel. And I
got help. But we weren't able to find the issue, either.
So I became frustrated. I re-did all the environment variables.
And suddenly,... it worked! What did I change? Well... I made the
environment variables which contained pathes contain absolute pathes
rather than relatives.
And because I like to share my knowledge, this should be put into the
documentation, so others do not bang their heads against the wall
because something is not documented somewhere.
|
|
|
|
|
|
|
|
Fixes: a6ca68a7 ("Require OpenSSL")
|
|
|
|
|
|
|
|
Don't hardcode docbook XSL namespace URL
|
|
Docbook XSL got updated to version 1.79.1 in NixOS/nixpkgs@fb893a8 and
we're still referring to the hardcoded previous version.
So instead of just updating this to 1.79.1 we're going to use "current"
in the hope that this won't happen again.
I have tested this by building the manual under Nix(OS) but I haven't
tested this in a non-Nix environment, so I'm not sure whether this could
have implications.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
|
|
|
|
http://hydra.nixos.org/build/36944270
|
|
Looks like these were accidentally commented out in
9ffc4f4363d9596e2477645eab94e4140cd47c19.
|
|
http://hydra.nixos.org/build/36631898
|
|
Remove nix-copy-closure reference note from nix-store docs
|
|
nix-copy-closure is not using nix-store directly anymore.
|
|
This way, all builds appear to have a uid/gid of 0 inside the
chroot. In the future, this may allow using programs like
systemd-nspawn inside builds, but that will require assigning a larger
UID/GID map to the build.
Issue #625.
|
|
|
|
|
|
This allows an unprivileged user to perform builds on a diverted store
(i.e. where the physical store location differs from the logical
location).
Example:
$ NIX_LOG_DIR=/tmp/log NIX_REMOTE="local?real=/tmp/store&state=/tmp/var" nix-build -E \
'with import <nixpkgs> {}; runCommand "foo" { buildInputs = [procps nettools]; } "id; ps; ifconfig; echo $out > $out"'
will do a build in the Nix store physically in /tmp/store but
logically in /nix/store (and thus using substituters for the latter).
|
|
|
|
|
|
|
|
Show both cycle ends
|
|
|
|
http://hydra.nixos.org/build/36613774
|
|
|
|
|
|
|
|
It's not needed and can cause problems in a user namespace.
|
|
This is a convenience command to allow users who are not privileged to
create /nix/store to use Nix with regular binary caches. For example,
$ NIX_REMOTE="local?state=$HOME/nix/var&real=/$HOME/nix/store" nix run firefox bashInteractive
will download Firefox and bash from cache.nixos.org, then start a
shell in which $HOME/nix/store is mounted on /nix/store.
|
|
|
|
This is primarily to subsume the functionality of the
copy-from-other-stores substituter. For example, in the NixOS
installer, we can now do (assuming we're in the target chroot, and the
Nix store of the installation CD is bind-mounted on /tmp/nix):
$ nix-build ... --option substituters 'local?state=/tmp/nix/var&real=/tmp/nix/store'
However, unlike copy-from-other-stores, this also allows write access
to such a store. One application might be fetching substitutes for
/nix/store in a situation where the user doesn't have sufficient
privileges to create /nix, e.g.:
$ NIX_REMOTE="local?state=/home/alice/nix/var&real=/home/alice/nix/store" nix-build ...
|
|
|
|
E.g. "local?store=/tmp/store&state=/tmp/var".
|
|
This ensures that the disappearance of upstream bootstrap tarballs
(e.g. https://github.com/NixOS/nixpkgs-channels/pull/1) doesn't break
stdenv rebuilds.
|
|
|
|
|
|
Also, test HttpBinaryCacheStore in addition to LocalBinaryCacheStore.
|
|
|
|
http://hydra.nixos.org/build/36462209
|
|
|
|
|
|
http://hydra.nixos.org/build/36462150
|
|
|
|
Apparently opinion is divided on whether [[noreturn]] is allowed on a
lambda: http://stackoverflow.com/questions/26888805/how-to-declare-a-lambdas-operator-as-noreturn
http://hydra.nixos.org/build/36462100
|
|
http://hydra.nixos.org/build/36462078
|
|
|
|
This restores the Nix 1.11 behaviour.
|