In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
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).
First, pass in `self' again so that overriding works properly (thanks
for pointing that out, @edolstra)
Second, instead of having linuxPackages*.kernel mean something different
inside the set and out, add a new attribute linuxPackages*.kernelDev,
which for the generic kernel is simply linuxPackages*.kernel but for the
manual-config kernel is the `dev' output (which has the build tree,
source tree, etc.)
The second change required trivial modifications in a bunch of
expressions, I verified that all of the linuxPackages* sets defined in
all-packages.nix have the same drv paths before and after the change.
Signed-off-by: Shea Levy <shea@shealevy.com>
I'm not entirely sure what the appropriate license attribute for this
package is. The license [1] says:
| 2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of
| Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or
| FreeBSD operating systems, or other operating systems derived from
| the source code to these operating systems, may be copied and
| redistributed, provided that the binary files thereof are not
| modified in any way (except for unzipping of compressed files).
It sounds to me like this gives NixOS the right to re-distribute the
files (because we don't modify them). The 'proprietary' license sort-of
fits that. On the other hand, we seem to assume that proprietary
software cannot be redistributed, which doesn't apply here.
[1] http://www.nvidia.com/content/DriverDownload-March2009/licence.php?lang=us
now has a flat directory structure (i.e. usr/lib, usr/share etc. are
gone), which makes installing everything in the right location
rather more tedious.
svn path=/nixpkgs/trunk/; revision=22628
useful on x86_64-linux to support i686 binaries: there we need the
NVIDIA OpenGL libraries, but not the kernel module or the
nvidia-settings program (which just cause a lot of unnecessary and
large dependencies).
svn path=/nixpkgs/trunk/; revision=22061
I added 'perl' as their buildInputs to get them built.
I don't know if it is something new from nvidia, but I imagine it may be
introduced in 2.6.31, for any module building.
svn path=/nixpkgs/trunk/; revision=19029
find libXrandr when invoked as "nvidia-settings", but not when
invoked by absolute path
(e.g. "/var/run/current-system/sw/bin/nvidia-settings"). Adding it
to libGL's RUNPATH fixes this. Strangely, libGL doesn't even
contain a reference to libXrandr.
svn path=/nixpkgs/trunk/; revision=15971
