(less sigill, less sigbus). Related to bad handling of FPU instructions.
I apply them only to linux 3.4, although I think they can apply to many older kernels too.
svn path=/nixpkgs/trunk/; revision=34522
as they are referenced from other kernel headers, this seems like the
best thing to do. Ubuntu seems to do so too.
Fixes issues with nvidia's binary driver and bbswitch on kernels > 3.3
svn path=/nixpkgs/trunk/; revision=34469
This incorporates the btrfs fix, so remove that patch. Also, I will test
that this builds after committing, and fix it if it fails
svn path=/nixpkgs/trunk/; revision=33885
This should solve the problem I had, where I could not boot either 3.3 or 3.3.1
in my system, as I got ENOSPC all the time.
svn path=/nixpkgs/trunk/; revision=33714
The patch is currently being discussed on LKML and hopefully will be included
in mainline in some form in the future. Note that booting from the livecd has
to do a lot of work before anything is output to the console, so if the drive
is still busy don't assume the boot has hanged
svn path=/nixpkgs/trunk/; revision=33235
Not merged r32497 (tree conflict, glibc GNU Hurd update). Ludovic, could you
please look at this?
svn path=/nixpkgs/branches/stdenv-updates/; revision=32520
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
I add newt, checking that it cross-builds too.
I update perf to have newt support, and now it's also finding python, whatever
that means. I've not tested if 'python' as buildInputs is enough.
svn path=/nixpkgs/trunk/; revision=31353
and lower quality than regular drivers. However, there are a lot of drivers
for wireless cards that we really need to have. And it doesn't really hurt
to have these drivers if you don't need them.
* Enable the Radeon KMS option. This shouldn't be a problem since the X driver
supports KMS (I think).
svn path=/nixpkgs/trunk/; revision=29994
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
I wanted to wait for kernel.org to get back up, but there doesn't seem to be any information about when that will be. If you don't trust that this is Torvalds' github, see https://lkml.org/lkml/2011/9/4/92 for how to verify
svn path=/nixpkgs/trunk/; revision=29198
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
Renamed cifs-timeout-2.6.32 patch to cifs-timeout-2.6.29 as this is the
older kernel version this patch applies to.
svn path=/nixpkgs/trunk/; revision=27711
Currently suffixed with 2.6.32.
This pre-patch prepares the landing of several versions of this patch to
support other Linux kernel versions.
svn path=/nixpkgs/trunk/; revision=27709
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
This patch adds a "features.aufs2_1" to the aufs-2.1 patch for Linux
2.6.37 to prevent aufs2_1 and aufs2_1_util from being options for
kernels without an aufs 2.1 patch. There were several Hydra build
failures as a result of attempting to build aufs2.1 against older
kernels.
svn path=/nixpkgs/trunk/; revision=26597
* My motivation for this patch is that kernels < 2.6.36 contain an
e1000e that does not support the ethernet card that is part of the
chipset for the second-generation Core-i Intel CPUs, so in order
to have a more useful livecd I needed to get aufs working with a
newer kernel, and 2.6.37 is the latest kernel with an official
aufs release.
* All sources are downloaded with fetchgit. This is because the aufs
upstream doesn't provide release tarballs, they just add a tag to
their git tree for an official release.
* The make target for the aufs2.1 headers uses a Makefile in the
kernel build directory that requires that unifdef be in the
scripts/ subdirectory of the build directory. The way I've dealt
with this here is by adding "make $makeFlags -C scripts unifdef"
to the postBuild in the kernel builder. Since the builder is used
by all kernel versions, this will require rebuilding every kernel
and kernel-dependent package if the patch is accepted, so one
alternative I thought of would be to create a fake kernel build
directory where everything is symlinked to the real build
directory except scripts/, which is first copied and then make
unifdef is run before building aufs2.1. If that more complicated
solution is preferred, or if anyone has ideas for another one, I
can do that and submit a new patch.
* The patch was tested by building a livecd ISO that uses it, then
running the ISO from within virtualbox and installing aufs2.1-util
from within the livecd environment.
* The livecd was built using installation-cd-minimal.nix, with two
changes to the Nixos tree:
1. boot.kernelPackages = pkgs.linuxPackages_2_6_37 was added to
profiles/minimal.nix
2. config.boot.kernelPackages.aufs2 was changed to
config.boot.kernelPackages.aufs2_1 in iso-image.nix
I would have preferred to keep all changes within
profiles/minimal.nix, but I couldn't figure out how to override
iso-image.nix's definition of boot.extraModulePackages. Livecds
that use an older kernel can't be built with this iso-image.nix,
since we don't have aufs2.1 for them (just aufs2). If someone can
point me to how I can override things set in iso-image.nix, I'd
appreciate it.
make -C scripts unifdef compiles the unifdef application in the
scripts/ directory, and when Nix copies over the build tree to
$out/lib/modules/$version/build for kernel modules to reference, it
copies over all of scripts/ except the .o files. I can't speak for
other kernel versions, but at the least for 2.6.37.1 unifdef is not
built by default. If you look at the Makefile in scripts, unifdef is
listed under a comment saying that the following programs are only
built on-demand.
svn path=/nixpkgs/trunk/; revision=26548
