http://bugs.python.org/issue15833
When Python 3.3.0 attempts to compile python bytecode in the system
directories it raises and exception and stops. Since Python 3.3 is
only required by the latest Blender, I hope it's OK to use the RC
until the final release.
Now, our builds shouldn't break anymore once there is a new change in ocamllibs.
I've used revision 256 from ocamllibs, because this was approximately the
revision we had back then when Haxe 2.10 got released.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is required in order to support Haxe 3, but won't hurt (tested with a few
projects) even in Haxe 2.x.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
That is, there are now distinct jobs like ‘coreutils.x86_64-linux’ and
‘coreutils.x86_64-darwin’, rather than a single job ‘coreutils’ with
multiple builds. This means that testing a job is simpler:
$ nix-build pkgs/top-level/release.nix -A coreutils.x86_64-linux
See https://github.com/NixOS/hydra/issues/60 for the motivation.
libxslt has optional dependencies which may be found in /usr or
/usr/local on platforms that have a native stdenv. With those features
enabled, the build generated binaries that depend on libraries outside
of the store. In this particular case, the NixOS channel had binaries
for FreeBSD that depended on libgcrypt, apparently because that packages
happens to be installed outside of Nix on the build machine. On other
machines, however, those binaries failed with unresolvable references.
libxslt has optional dependencies which may be found in /usr or
/usr/local on platforms that have a native stdenv. With those features
enabled, the build generated binaries that depend on libraries outside
of the store. In this particular case, the NixOS channel had binaries
for FreeBSD that depended on libgcrypt, apparently because that packages
happens to be installed outside of Nix on the build machine. On other
machines, however, those binaries failed with unresolvable references.
