XZ compresses significantly better than bzip2.  Here are the
compression ratios and execution times (using 4 cores in parallel) on
my /var/run/current-system (3.1 GiB):

  bzip2: total compressed size 849.56 MiB, 30.8% [2m08]
  xz -6: total compressed size 641.84 MiB, 23.4% [6m53]
  xz -7: total compressed size 621.82 MiB, 22.6% [7m19]
  xz -8: total compressed size 599.33 MiB, 21.8% [7m18]
  xz -9: total compressed size 588.18 MiB, 21.4% [7m40]

Note that compression takes much longer.  More importantly, however,
decompression is much faster:

  bzip2: 1m47.274s
  xz -6: 0m55.446s
  xz -7: 0m54.119s
  xz -8: 0m52.388s
  xz -9: 0m51.842s

The only downside to using -9 is that decompression takes a fair
amount (~65 MB) of memory.

Since the Perl bindings require shared libraries, this is required on
platforms such as Cygwin where we do a static build.

Perl on some 32-bit systems needs -D_FILE_OFFSET_BITS=64.  See also commit
02f1363e.

This fixes the Darwin build (http://hydra.nixos.org/build/2517380).
Hopefully it doesn't break other builds.

nix-copy-closure: Move the progressViewer directly adjacent to the ssh call so that network progress is what's measured

This command builds or fetches all dependencies of the given
derivation, then starts a shell with the environment variables from
the derivation.  This shell also sources $stdenv/setup to initialise
the environment further.

The current directory is not changed.  Thus this is a convenient way
to reproduce a build environment in an existing working tree.

Existing environment variables are left untouched (unless the
derivation overrides them).  As a special hack, the original value of
$PATH is appended to the $PATH produced by $stdenv/setup.

Example session:

$ nix-build --run-env '<nixpkgs>' -A xterm
(the dependencies of xterm are built/fetched...)
$ tar xf $src
$ ./configure
$ make
$ emacs
(... hack source ...)
$ make
$ ./xterm

We're already printing progress on stderr, so printing them on stdout
afterwards is kind of useless.

  Without these, Nix fails on 32-bit Linux with Perl 5.14, with a
  rather unhelpful error message:

    Not a CODE reference at /nix/store/n6kpbacn6nn7i3i735v8j3di8aqyl07v-perl-5.14.2/lib/perl5/5.14.2/i686-linux-thread-multi/DynaLoader.pm

  This is likely because the lack of -D_FILE_OFFSET_BITS=64 causes
  various Perl structures to not match what the Perl interpreter
  expects.

  Mac OS X instead of .dylib, so don't do that.

  scripts.
* Include the version and architecture in the -I flag so that there is
  at least a chance that a Nix binary built for one Perl version will
  run on another version.

* Refactor the nix-channel unpacker a bit.

  base-32.  (This affects Hydra manifests.)

  ‘nix-store --export’.
* Add a Perl module that provides the functionality of
  ‘nix-copy-closure --to’.  This is used by build-remote.pl so it no
  longer needs to start a separate nix-copy-closure process.  Also, it
  uses the Perl API to do the export, so it doesn't need to start a
  separate nix-store process either.  As a result, nix-copy-closure
  and build-remote.pl should no longer fail on very large closures due
  to an "Argument list too long" error.  (Note that having very many
  dependencies in a single derivation can still fail because the
  environment can become too large.  Can't be helped though.)

  libstore so that the Perl bindings can use it as well.  It's vital
  that the Perl bindings use the configuration file, because otherwise
  nix-copy-closure will fail with a ‘database locked’ message if the
  value of ‘use-sqlite-wal’ is changed from the default.

  read the manifest just to check the version and print the number of
  paths.  This makes nix-pull very fast for the cached cache (speeding
  up nixos-rebuild without the ‘--no-pull’ or ‘--fast’ options).

  disk space, and, since they're typically only decompressed once (to
  fill the manifest cache), doesn't make things slower.

  DB.  This speeds up creating the cache from 16.1s to 7.9s on my
  system.

  the Nix:: namespace.

  bindings to be used in Nix's own Perl scripts.

  The only downside is that Perl XS and Automake/libtool don't really
  like each other, so building is a bit tricky.