The function ‘mkDerivation’ now checks whether the current platform
type is included in a package's meta.platform field. If not, it
throws an exception:
$ nix-build -A linux --argstr system x86_64-darwin
error: user-thrown exception: the package ‘linux-3.10.15’ is not supported on ‘x86_64-darwin’
These packages also no longer show up in ‘nix-env -qa’ output. This
means, for instance, that the number of packages shown on
x86_64-freebsd has dropped from 9268 to 4764.
Since meta.platforms was also used to prevent Hydra from building some
packages, there now is a new attribute meta.hydraPlatforms listing the
platforms on which Hydra should build the package (which defaults to
meta.platforms).
Having N different copies of the NixOS kernel configuration is bad
because these copies tend to diverge. For instance, our 3.10 config
lacked some modules that were enabled in older configs, probably
because the 3.10 config had been copied off an earlier version of some
older kernel config.
So now there is a single kernel config in common-config.nix. It has a
few conditionals to deal with new/removed kernel options, but
otherwise it's pretty straightforward.
Also, a lot of cut&paste boilerplate between the kernel Nix
expressions is gone (such as preConfigure).
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).
what the new nix thinks the fuloong is.
Anyone having the old nix should use a nixpkgs previous to this change to build
the new nix. And then, with the new nix, he can use any newer nixpkgs revision.
svn path=/nixpkgs/trunk/; revision=31751
The "unset MODULE_DIR" trick was enough to get Linux 3.x kernels compiling, but it was definitely the Wrong Thing
We NEED MODULE_DIR set so that depmod can store the right dependencies during the build. The REAL problem with the
3.x kernels was two-fold: Our module-init-tools was so old that the kernel build needed to introduce a hack when
calling depmod (involving creating a symlink prepending 99.98 to the version number), and the depmod wrapper was
moved out of the Makefile into scripts/depmod.sh, so our substituteInPlace to get rid of '-b $(INSTALL_MOD_PATH)' in
the Makefile was a noop and INSTALL_MOD_PATH was still being passed to depmod. This is now fixed and modprobe can
successfully find dependencies using the modules.dep created during install
svn path=/nixpkgs/trunk/; revision=29559
With the new kernel versioning scheme, the first release in a series only has a version number and
a major revision number (e.g. linux 3.0, linux 3.1-rc1, etc.). Unfortunately, the module
directory for these kernels still has a minor revision number (e.g. lib/modules/3.0.0, lib/modules/3.0.1-rc1, etc.).
This causes problems for packages such as broadcom_sta that need to know the module directory, so
this attribute will allow setting the module directory version number separate from the
kernel version number when necessary.
svn path=/nixpkgs/trunk/; revision=28405
Moved the hardcoded postBuild hook from the builder to generic.nix:
Some old kernel (such as 2.6.15) did not yet support the unifdef target.
As a result, compiling them with the current Linux builder leads to a
failure.
Fixed by moving this hook as argument of the top-level function of
generic.nix. This allows some kernel nix codes to overrides its default
value.
svn path=/nixpkgs/trunk/; revision=27708
In fact only 2.6.34 boots fine, while 2.6.35 needs a fetchsvn new revision,
waiting for an upstream patch.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23039
on the native and cross platforms.
I thought I already did that today in a previous commit, but I did all wrong.
svn path=/nixpkgs/trunk/; revision=20280
I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
most of the kernel expressions for the sheevaplug).
I still have not added anything in the kernels about cross compilation.
I moved the platform definitions out of all-packages.
I have not written good platform definitions for the sheevaplug - only for the
PC.
Only the linux-2.6.32 expression uses the platforms kernelConfig.
The linux-2.6.31 was broken, and I left it broken.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19046
sheevaplug kernel, so the kernel does not build in the sheevaplug right now.
I will try to fix that in next commits.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19045
has to be "/bin/sh" - other values such as "sh" or "bash" or "$(type
-tP sh)" cause a build error:
LD .tmp_vmlinux1
/nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld:arch/um/kernel/vmlinux.lds:1: ignoring invalid character `#' in expression
/nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld:arch/um/kernel/vmlinux.lds:1: syntax error
collect2: ld returned 1 exit status
This is caused by Bash 4.0
(http://bugzilla.kernel.org/show_bug.cgi?id=13343).
svn path=/nixpkgs/branches/kernel-config/; revision=18941
`generate-config.pl' runs `make config' to generate a Linux kernel
configuration file. For each question (i.e. kernel configuration
option), unless an override is provided, it answers "m" if possible,
and otherwise uses the default answer (as determined by the default
config for the architecture). This is safer than allmodconfig,
which answers "y" everywhere it can't answer "m" and thus ends up
enabling a lot of experimental or debug options. (For this reason,
a configuration generated by allmodconfig must be carefully checked
with every new release to ensure that nothing dangerous is enabled.
The default config should be safer wrt new kernel releases.)
Overrides are specified in the `config' argument to generic.nix,
which is a string that contains lines such as `EXT2_FS_POSIX_ACL y'.
The script warns about ignored options, and aborts if `make config'
selects an answer inconsistent with the one in `config'. This
allows us to be sure that `make config' doesn't silently override
our configuration values (e.g., depending on other options, it will
set FB_TILEBLITTING to "y" even if we want it to be "n").
svn path=/nixpkgs/branches/kernel-config/; revision=18910
This comes from:
svn diff ^/nixpkgs/trunk/@18255 ^/nixpkgs/branches/stdenv-updates/ > diff
patch -p0 < diff
and then adding into svn all files new from the patch.
trunk@18255 comes from the last time I updated stdenv-updates from trunk.
svn path=/nixpkgs/stdenv-updates2/; revision=18272
