Previously we can't have quoted arguments.

This now allows us to use things like `ghcWithPackages`

Rather than using $<host-TMPDIR>/nix-build-<drvname>-<number>, the
temporary directory is now always /tmp/nix-build-<drvname>-0. This
improves bitwise-exact reproducibility for builds that store $TMPDIR
in their build output. (Of course, those should still be fixed...)

autoCallFunction now auto-calls functors

Update nix.spec.in

Some benchmarking suggested this as a good value. Running

  $ benchmark -f ... -t 25 -- sh -c 'rm -f /nix/var/nix/binary-cache*; nix-store -r /nix/store/x5z8a2yvz8h6ccmhwrwrp9igg03575jg-nixos-15.09.git.5fd87e1M.drv --dry-run --option binary-caches-parallel-connections <N>'

gave the following mean elapsed times for these values of N:

N=10:  3.3541
N=20:  2.9320
N=25:  2.6690
N=30:  2.9417
N=50:  3.2021
N=100: 3.5718
N=150: 4.2079

Memory usage is also reduced (N=150 used 186 MB, N=25 only 68 MB).

Closes #708.

There is really no conceivable reason why building Nix would need
access to the host's nix.conf. If it does, it's a bug, and we should
fix that instead.

Also, make the FreeBSD checks conditional on FreeBSD.

Print license information on '--xml --meta'

Fixed typo.

FreeBSD support with knowledge about Linux emulation

Reintroduces the functionality that allows the baked-in pre-build-hook to find framework dependencies

As discussed in NixOS/nixpkgs#11001, we still need some of the old
sandbox mechanism.

This reverts commit d760c263.

The nixpkgs manual prescribes the use of values from stdenv.lib.licenses
for the meta.license attribute. Those values are attribute sets and
currently skipped when running nix-env with '--xml --meta'. This has the
consequence that also nixpkgs-lint will report missing licenses.

With this commit nix-env with '--xml --meta' will print all attributes
of an attribute set that are of type tString. For example the output for
the package nixpkgs.hello is

    <meta name="license" type="strings">
      <string type="url" value="http://spdx.org/licenses/GPL-3.0+" />
      <string type="shortName" value="gpl3Plus" />
      <string type="fullName" value="GNU General Public License v3.0 or later" />
      <string type="spdxId" value="GPL-3.0+" />
    </meta>

This commit fixes nixpkgs-lint, too.

Temporarily allow derivations to describe their full sandbox profile.
This will be eventually scaled back to a more secure setup, see the
discussion at #695

src/libstore/build.cc: clarify error message for hash mismatches

Nix reports a hash mismatch saying:

  output path ‘foo’ should have sha256 hash ‘abc’, instead has ‘xyz’

That message is slightly ambiguous and some people read that statement
to mean the exact opposite of what it is supposed to mean. After this
patch, the message will be:

  Nix expects output path ‘foo’ to have sha256 hash ‘abc’, instead it has ‘xyz’

Use AutoDelete for sandbox profile file

- rename options but leav old names as lower-priority aliases,
  also "-dirs" -> "-paths" to get closer to the meaning
- update docs to reflect the new names (old aliases are not documented),
  including a new file with release notes
- tests need an update after corresponding changes to nixpkgs
- __noChroot is left as it is (after discussion on the PR)

Passing "--option build-repeat <N>" will cause every build to be
repeated N times. If the build output differs between any round, the
build is rejected, and the output paths are not registered as
valid. This is primarily useful to verify build determinism. (We
already had a --check option to repeat a previously succeeded
build. However, with --check, non-deterministic builds are registered
in the DB. Preventing that is useful for Hydra to ensure that
non-deterministic builds don't end up getting published at all.)

This reverts commit 79ca5033. Ouch,
never noticed this. We definitely don't want to allow builds to have
arbitrary access to /bin and /usr/bin, because then they can (for
instance) bring in a bunch of setuid programs. Also, we shouldn't be
encouraging the use of impurities in the default configuration.

If automatic store optimisation is enabled, and a hard-linked file in
the store gets corrupted, then the corresponding .links entry will
also be corrupted. In that case, trying to repair with --repair or
--repair-path won't work, because the new "good" file will be replaced
by a hard link to the corrupted file. We can catch most of these cases
by doing a sanity-check on the file sizes.