This change is done for completness in regards to [1] since we already
support a newer "stable" version.
nvidia_x11_beta now compiles on both 4.14 and 4.15.
[1] https://github.com/NixOS/nixpkgs/issues/31640
390.x is Nvidia's latest "Long Lived Branch version" according to
https://www.nvidia.com/object/unix.html so this upgrades the stable version
from 387.xx.
390.x also also has support for kernel 4.15 and later (due to removal of the
old init_timer APIs, among other things), meaning that
linuxPackages_4_15.nvidia_x11 now builds correctly.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
I *suspect* that NV_VM_OPERATIONS_STRUCT_HAS_FAULT isn't detected
in our case for some reason, so this patch doesn't make a difference.
In any case, the patch seems unlikely to make anything worse.
This now builds with kernel 4.13; Debian has only the typo patch there.
Curiously, .settings still fails to link on x86_64-linux but works
on i686-linux, just as with .135.
Fixes#32169: build with kernel 4.13.
Unfortunately, 4.13 is going away very soon and for 4.14 doesn't build.
I only tested building it, but these minor bumps should be safe.
At the time of the last upgrade, the new driver wasn't available on
anything but their US mirror. Pinning to the US mirror isn't
recommended or preferable, but I did it anyway to be able to get the
upgrade out.
Tested & reviewed by vcunat:
- the patch seems not needed anymore,
- reflects changes in their build system
ftp://download.nvidia.com/XFree86/packaging/linux/new-kbuild-for-355/README
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
Otherwise we end up with multiple versions of GTK in the system
closure. Also, GTK 3 is not well integrated in NixOS yet (e.g. it
doesn't respect KDE's colour scheme).
The GUI would no longer find libs it needed.
Now it's gtk3 by default, so we don't support gtk2 version for simplicity.
ldd finds no missing libs after this commit.
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>
Edmund Wu
Herman Fries
Herman Fries
volth
Bastian Köcher
Nikolay Amiantov
Vladimír Čunát
Andreas Rammhold
Austin Seipp
Elis Hirwing
Cray Elliott
Linus Heckemann
Victor Calvert
Frederik Rietdijk
Graham Christensen
Kirill Boltaev
Franz Pletz
Robin Gloster
Karn Kallio
Eelco Dolstra
Svein Ove Aas
William A. Kennington III
Eric Seidel
Shea Levy
Eduard Bachmakov
Lluís Batlle i Rossell
Mathijs Kwik
ambrop7@gmail.com
Aristid Breitkreuz
Evgeny Egorochkin
Peter Simons