This speeds up queries against the binary cache.

Fix spec file

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

Since we now chmod /nix/store at install time, we don't need to do it in the
post install script. We still chgrp in the post-install, because the nixbld
group doesn't exist at install time.

The Nix download page only mentions the .xz source tarball, so that's what
people are likely to have available. This means that somebody who downloads a
Nix source tarball can turn it directly into an RPM with `rpmbuild -ta
nix-*.tar.xz`.

Nix expects build users to be in the "nixbld" group. You can change that in the
config file, but `nix.spec` does not ship with a config file, so we should
use the defaults.

http://hydra.nixos.org/build/36944270

Looks like these were accidentally commented out in
9ffc4f43.

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