meta.license is can be a string or a list of strings. But there is one
unhandled case where "unfree" (or "unfree-redistributable") is a part of
a list. It will currently not be detected as an "unfree" package and
Hydra will attempt to build it. This should fix it.
Example: http://hydra.nixos.org/build/6553461
Before this, the passthru attributes were only merged in with the
derivation attribute set, and there was no way to distinguish after the
fact which attributes were part of the derivation and which came from
passthru. Now passthru can be looked at separately as well.
Signed-off-by: Shea Levy <shea@shealevy.com>
With multiple outputs, adding attributes to a derivation without
changing the {drv,out}Path is no longer as trivial as simply using the
`//' operator, as we usually want to add the attribute to _each_ output,
and even if we only care about one that one output can be reached via
multiple paths.
For stdenv.mkDerivation, we already had code in place to add passthru
and meta attributes to derivations. This commit simply factors part of
that code out into a lib function addPassthru, which takes a derivation
and an attribute set and appends the attribute set to each output of the
derivation.
Signed-off-by: Shea Levy <shea@shealevy.com>
Before, only the first output (and not even that when accessed through 'all' or its corresponding attribtue) had meta information and the relevant passthru attributes.
This doesn't change stdenv's hash and the tarball still builds, I'm pretty sure this is safe for master.
I'm not sure whether this was by intention, but so far postPatch hooks were
silently skipped whenever the patches list was empty. This change could possibly
change the build results of the following packages:
* gcc
* cmake (264)
* systemtap
* quemu-kvm
These packages all have in common that they have a postPatch hook and the
patches list can be empty when certain conditions are met.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Due to xz being override in the last stdenv and also in the previous, the
nixpkgs xz ended up being built by bootstrap-tools, and thus depending on it
through libgcc_so.so.1. That ends up making 'nix' with a runtime
dependency on bootstrap-tools.
If set to false, mkDerivation will throw an exception if a package has
an unfree license. ‘release-lib.nix’ uses this to enforce that we
don't build unfree packages as part of the Nixpkgs channel. Since
this is set through Nixpkgs' ‘config’ argument, it's more finegrained
than $HYDRA_DISALLOW_UNFREE.
Although patching it made some programs run (configure tests), some others
crashed with segfault. So I don't think there is any win patching it. The
proper way to solve the bootstrap in the raspberry pi is, as far as I've been
testing, use glibc 2.17 libs in bootstrap-tools with the same ld.so name as the
bootstrapped glibc.
This is a problem inherent in our way to bootstrap, that first replaces
the glibc of a given gcc+glibc (bootstrap-tools) with gcc-wrapper tricks, and
then builds a new gcc. A nicer way would be to build a gcc without glibc,
then the glibc, then the final gcc, as we do with cross-tools.
Some comments about this problem in
https://github.com/NixOS/nixpkgs/issues/234#issuecomment-11764352
This solves the problem of the change of name in ld.so between
glibc 2.13 and 2.17 (at least for armhf). Some comments about it in
https://github.com/NixOS/nixpkgs/issues/234#issuecomment-11764352
As there says, without this, gmp (after glibc built) tests crashed
- segfault.
Now that we have a way to alter /bin/sh in chroots on non-NixOS Linux
platforms, it may be useful to have access to stdenv.shell package and to
static bash contained in bootstrap tools. So make them accessible via stdenv
attribute set.
libstdc++ and libmudflapth link to the dynamic loader; if the
bootstrap uses another dynamic loader name, and the rpath of these
libs isn't changed, they will fail to load.
Conflicts:
pkgs/development/compilers/gcc/4.6/default.nix
pkgs/development/compilers/gcc/4.7/default.nix
The 4.7 had some weird parameters added in crossAttrs; I've removed
them, but I don't understand where they come from.
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
This allows various applications. It allows users to set global
optimisation flags, e.g.
stdenv.userHook = ''NIX_CFLAGS_COMPILE+=" -funroll-loops"'';
But the impetus is as an alternative to issue #229, allowing impure
stdenv setup for people who want to use distcc:
stdenv.userHook = "source /my/impure/setup-script.sh";
This is probably a bad idea, but at least now it's a bad idea in
people's configuration and not in Nixpkgs. :-)
