The latest installment of the linux kernel, 3.0.3, already appeared in gentoo-sources, vanilla-sources and hardened-sources. Please add the corresponding linux-headers ebuild so we can have matching headers and kernel.
the same applies to the new additions in gentoo- and vanilla-sources, 3.0.4
I'm wondering when this is getting bumped, too. I've been stuck on linux-headers-2.6.39 for awhile now and it seems that it's stuck at the 2.6 series. We are up to gentoo-sources-3.0.6 now.
We are up to gentoo-sources-3.1.0 now and no word on when we're getting an updated header ebuild.
*** Bug 388855 has been marked as a duplicate of this bug. ***
Could someone explain what need there is to have the headers match the kernel? Matching arbitrary labels like version numbers is just an optical illusion, otherwise.
(In reply to comment #5) > Could someone explain what need there is to have the headers match the kernel? > > Matching arbitrary labels like version numbers is just an optical illusion, > otherwise. Good point. Especially the seemingly large difference between 2.6.39 and 3.0 is just due to a change in the numbering scheme. 3.0 is the direct successor of 2.6.39 with no major architectural change in between. And the only package depending strongly on linux headers is glibc.
(In reply to comment #5) > Could someone explain what need there is to have the headers match the kernel? > > Matching arbitrary labels like version numbers is just an optical illusion, > otherwise. Because many 3rd party kernel patchsets (like the one's used in gentoo-sources) assume the system linux-headers are matched to the kernel source tree being compiled and patch with # include <linux/newinclude.h> instead of # include "linux/newinclude.h" The mismatch mostly works but sometimes it doesn't. For instance when a patch references functions only available in the new headers.
We're almost to Linux Kernel 3.2 and still no updated headers.
Give a specific reason you need them.
The reason to have linux-headers >= 3.0 is exactly the same as having linux-headers at all. As far as I know, that translates to "having headers for the linux kernel APIs to link against". When a new feature gets introduced in the kernel you need matching headers to be able to use it. An oldish example is when Inotify was introduced to supersede the older Dnotify system and relevant APIs. If you run a kernel >=2.6.13 with Inotify support compiled in you won't ever be able to use it if you stick at linux-headers <= 2.6.12. A newer example would probably be the new Near-Field Communication subsystem introduced in linux-3.1, its APIs being absent from linux-headers-2.6.xx. I don't know if these new features require matching headers but I wouldn't be surprised if they actually do: software raid (MD) bad block support via mdadm, Xen memory hot plug via balloon driver, new SEEK_* flags for lseek(), and so on. That means no system will stop working if linux-headers lags behind the running kernel version, but we will lose the ability to call any new function that gets introduced in the kernel. Also, *I may be wrong here*, but I suspect that compiling external modules could have some troubles with wrong linux-headers. So while it's not a showstopper now, we should IMHO try to keep up with the available kernel versions... sooner or later 2.6.39 will be "too old" for one reason or another.
(In reply to comment #10) I think this is more of a "We do not have time right now, so give us real-world-problem fixed by this bump so we know why we should prioritize this bump now instead of working on getting gcc-4.6 into ~arch" and so on. These guys has plenty of stuff on their table that needs priority without having to deal with linux-headers right now if they do not have to. If you really want this going any faster into portage, maybe you should either acctually find a package that fails to build, a package that crashes or something alike that before there is a real reason to give this higher priority. Or, you could do a local bump, rebuild world, and then report back here when that works fine and if/what you needed to change to get things building and working (i.e. actually not crashing). That may inspire a dev to take your proposed changes into tree.
done locally http://sources.gentoo.org/gentoo/src/patchsets/gentoo-headers/3.1/
@SpanKY: HTTP 404
