Linux kernel 4.11.3 is the current stable kernel listed at www.kernel.org but the latest Gentoo linux-headers version is sys-kernel/linux-headers-4.10
There's a "rip-headers.sh" script included in each gentoo-headers-base* tarball that is used to copy the required header bits out of a kernel source tree. However, for 4.12, this script fails due to some kind of change in 4.12: + ver=4.12 + [[ -z 4.12 ]] + [[ 4.12 == linux-* ]] + ver=4.12 + src=linux-4.12 + dst=gentoo-headers-base-4.12 + '[' '!' -d linux-4.12 ']' + for srcdir in . /usr/portage/distfiles + for ext in bz2 xz + srctar=./linux-4.12.tar.bz2 + '[' -e ./linux-4.12.tar.bz2 ']' + for ext in bz2 xz + srctar=./linux-4.12.tar.xz + '[' -e ./linux-4.12.tar.xz ']' + for srcdir in . /usr/portage/distfiles + for ext in bz2 xz + srctar=/usr/portage/distfiles/linux-4.12.tar.bz2 + '[' -e /usr/portage/distfiles/linux-4.12.tar.bz2 ']' + for ext in bz2 xz + srctar=/usr/portage/distfiles/linux-4.12.tar.xz + '[' -e /usr/portage/distfiles/linux-4.12.tar.xz ']' + tar xf /usr/portage/distfiles/linux-4.12.tar.xz + break + '[' '!' -d linux-4.12 ']' + rm -rf gentoo-headers-base-4.12 + mkdir gentoo-headers-base-4.12 + cp linux-4.12/Makefile gentoo-headers-base-4.12/ + mkdir gentoo-headers-base-4.12/include + cp linux-4.12/include/Kbuild gentoo-headers-base-4.12/include/ cp: cannot stat 'linux-4.12/include/Kbuild': No such file or directory I've pinged Mike for any guidance on how to solve this.
Could we please have a useflag or an alternative package (similarly to evdev can replace udev) which makes the system use (by sym-linking or copying) the headers from /usr/src/linux, or maybe an eselect option to switch between the files installed by linux-headers and the files found in /usr/src/linux (which is usually set by eselect as well)? I know the over-zealously referenced age-old quote from Linus which explains why only a handful of developers might want to do such a thing but most Gentoo users build their own glibc by default (just like pretty much everything in their system except some closed-source binary-distributed software, or if they decided to use binary packages by choice). As much as I know, the only caveat is that some libraries and binaries might need to be rebuilt in the right order after switching between the header versions. But Gentoo has the facilities for such things (like revdep-rebuild). Or, I guess, this would not even come up as an issue in practice if linux-headers would closely follow gentoo-sources with version updates. After all, even those who exaggerate the importance of separating these two packages ("you are a moron and the butcher of a dozen kittens if you symlink your linux headers") basically recommend to keep your headers equally or might even more close to the latest mainline version than you kernel itself. Yet, with Gentoo (where we have more flexibility in the matter), header versions tend to lag behind source versions (just like right now) with no easy means of switching to source headers (which could be a valid option in this distro).
(In reply to János Tóth F. from comment #2) > Could we please have a useflag or an alternative package ... (*) Just to point this out: Running on "longterm" for production typically, I do install and test current "stable" or even "_rc" for testing purposes. But in order to be able to switch back, I personally would never accept any automatism to upgrade the header files to latest installed <...> automatically. As a minimum, (*) should take the given installed header files as "default" - and in every case double-ask before upgrading, indicating clearly the implicit consequences for installed packages, possibly breaking compatibility. Just my 2 cents of thought ... Thanks Manfred
(In reply to Joshua Kinard from comment #1) > + cp linux-4.12/include/Kbuild gentoo-headers-base-4.12/include/ > cp: cannot stat 'linux-4.12/include/Kbuild': No such file or directory "cp" is absolutely correct ;-) # ls -Alg /usr/src/linux/include | grep -i Kbuild # But: # find /usr/src/linux/include -name "Kbuild" /usr/src/linux/include/uapi/linux/Kbuild <----- ....................../^^^^/^^^^^/...... and # ls -1 /usr/src/linux/Kbuild /usr/src/linux/Kbuild <----- no "/include/ in front of /Kbuild ..............^________________________________/^^^^^^^/ instead. (AFAICR, the famous "UAPI header file split" happened ~5 years ago.)
I've added sys-kernel/linux-headers-4.11 to the tree, but with KEYWORDS all removed until this can be carefully tested. It's not 4.12 for the purposes of this bug, but I need to move on to other priorities, so won't be tackling the issue with creating 4.12 headers right now. Should still help to bump things along that are being held back due to 4.10 being the current unstable. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f72ababac9f177d374f3e8e27f1e3f06ce04c444
(In reply to Joshua Kinard from comment #5) > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=f72ababac9f177d374f3e8e27f1e3f06ce04c444 +RDEPEND="!!media-sound/alsa-headers" Dependency obsolete. Exactly in favour of this very linux-headers, this package has been removed from tree ~4 years ago. # emerge -s "alsa" | grep "*" | grep "headers" # Is it still necessary to further keep it as a "safe-guard"? At least, it does no harm - only irritates.
(In reply to Manfred Knick from comment #6) > (In reply to Joshua Kinard from comment #5) > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=f72ababac9f177d374f3e8e27f1e3f06ce04c444 > > +RDEPEND="!!media-sound/alsa-headers" > > Dependency obsolete. > > Exactly in favour of this very linux-headers, > this package has been removed from tree ~4 years ago. > > # emerge -s "alsa" | grep "*" | grep "headers" > # > > Is it still necessary to further keep it as a "safe-guard"? > At least, it does no harm - only irritates. I simply copied the 4.10 ebuild to 4.11. Didn't even look at much else in the ebuild except to nullify the KEYWORDS variable as a sanity-check. When I add the ~mips keyword later today, I'll pull this RDEP. There's probably tons of examples of this all over the tree. IMHO, this looks like something repoman (our QA check tool) should test for. It does not seem to detect this missing package. You might try filing a bug with the portage team noting this so they can look into it. A 'repoman full' scan of sys-kernel/linux-headers simply reports the following: RepoMan scours the neighborhood... KEYWORDS.missing 1 sys-kernel/linux-headers/linux-headers-4.11.ebuild repo.eapi.deprecated 5 sys-kernel/linux-headers/linux-headers-3.18.ebuild: 4 sys-kernel/linux-headers/linux-headers-4.3.ebuild: 4 sys-kernel/linux-headers/linux-headers-4.4.ebuild: 4 sys-kernel/linux-headers/linux-headers-4.5.ebuild: 4 sys-kernel/linux-headers/linux-headers-4.6.ebuild: 4
Added 4.12 and 4.13 headers to the tree.
