* broadcom: fix build 5.9
Patch to fix the build error for the 5.9 Linux kernel.
* broadcom: swith 5.9 patch to Joan Bruguera's version
Switch the current patch for 5.9 to Joan Bruguera's version which is cleaner and also works for 5.10
They aren't meant to be critical (uncatchable) errors.
Tested with nix-env + checkMeta:
[ "x86_64-linux" "i686-linux" "x86_64-darwin" "aarch64-linux" ]
The patch is from Arch Linux at:
https://aur.archlinux.org/cgit/aur.git/tree/linux412.patch?h=broadcom-wl
Tested this by building against the following attributes:
* linuxPackages.broadcom_sta
* linuxPackages_latest.broadcom_sta
* pkgsI686Linux.linuxPackages.broadcom_sta
* pkgsI686Linux.linuxPackages_latest.broadcom_sta
I have not tested whether this works at runtime, because I do not posess
the hardware.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The patch for kernel version 3.18 is already applied upstream, so we
don't need it any longer.
Without i686-build-failure.patch, the build for i686-linux fails because
it references rdtscl(), which is no longer available in Linux 4.3.0.
Patch for missing rdtscl() is from Arch Linux:
https://aur.archlinux.org/cgit/aur.git/tree/002-rdtscl.patch?h=broadcom-wl-ck
I've tested building against 32 and 64 bit Linux versions 3.18.36,
4.4.16 and 4.7.0.
The hashes were verified using the ones from the AUR (using the 16 bit
hashes of course):
$ nix-hash --type sha256 --to-base16 1kaqa2dw3nb8k23ffvx46g8jj3wdhz8xa6jp1v3wb35cjfr712sg
4f8b70b293ac8cc5c70e571ad5d1878d0f29d133a46fe7869868d9c19b5058cd
$ nix-hash --type sha256 --to-base16 1gj485qqr190idilacpxwgqyw21il03zph2rddizgj7fbd6pfyaz
5f79774d5beec8f7636b59c0fb07a03108eef1e3fd3245638b20858c714144be
AUR hashes can be found at:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=broadcom-wl&id=9d6f10b1b7745fbf5d140ac749e2253caf70daa8#n26
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @phreedom, @vcunat
This replaces our patches with those from Arch's package [1]. Further
discussion can be found on the Arch forum [2].
This patch set is a superset of the previous set, and resolves the
immediate and consistent kernel panics I've seen on my MacBook Pro
Retina since switching from version 3.16 to 3.18 of the Linux kernel.
Fixes#5315Fixes#7710
1: https://aur.archlinux.org/packages/broadcom-wl/
2: https://bbs.archlinux.org/viewtopic.php?id=192287
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>
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>
X9VoiD