In ffc498c490 -j$NIX_BUILD_JOBS was added.
Somehow this caused my machine to run many many more parallel jobs than
it was supposed to, freezing the system.
If you don't experience this, feel free to revert.
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.
Thanks to the great commit message in 6257425dab
(thank you edwtjo) I was able to go back and find out the patch which
was causing build failures is no longer necessary after upgrading
this legacy driver.
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.
Close#9218.
It's our default kernel (now and for the upcoming release).
- 304 won't build with 4.1,
- 173 didn't even build with 3.14 due to other issues (3.12 is OK ATM)
- all legacy drivers are up-to-date with upstream releases.
nvidia's EGL stack looks for libGLESv2.so.2 at runtime (confirmed by
watching strace), however builder.sh only provides a libGLESv2.so.1
symlink.
@vcunat ported to legacy_340; older ones don't produce GLES.
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>
