This is a dep of media-video/kaffeine-0.8.8 which i plan to stabilize. If there are no problems regarding this package, please proceed. Thank you in advance
*** Bug 274395 has been marked as a duplicate of this bug. ***
There is also a problem with timezone-data-2009j. On my x86 Gentoo box (2.6.29-gentoo-r5 sources and linux-headers-2.6.27) the former package failed to compile until I unmasked linux-headers-2.6.29*.
file a new bug. no one else has reported this, it works for me, and the info you give is not enough to figure out what is wrong.
Guys, we need 2.6.29 got qemu-0.10.6, can we stabilize that instead?
also we need 2.6.29 or later for fresh media-video/vdr
Proposal: Create a script to extract the headers of the linux kernel to be released and release the header package at the same time as the kernel both with the same version of kernel. The kernel is released with a certain version of API for the various kernel interface modules, so why not make sure applications are compiled with the according kernel header files. (In reply to comment #5) > also we need 2.6.29 or later for fresh media-video/vdr >
net-firewall/ipsec-tools-0.7.2 need linux-2.6.30 (see bug #282752) why linux-headers stabilization doesn't follow gentoo-sources'?
there is no hard requirement to keep the two in sync
(In reply to comment #8) > there is no hard requirement to keep the two in sync > Can we get some recent version of linux-headers stable please? Seeing that there are packages that need it.
(In reply to comment #8) > there is no hard requirement to keep the two in sync > YES , YES , and YES there is. Why is this so hard to get sorted out. API in Linux changes ( as they do between the various releases) very often are reflected in changes of the associated kernel include (header) files. So why can't the gentoo kernel team not create a script that when a new kernel is released it automatically creates the associated kernel header file package? This would solve the problem of a continuous stream of requests each time something changes in an API.
using caps lock doesnt make your argument correct. perhaps if you understood how user/kernel space interacted and the strong ABI in play you wouldnt post such incorrect statements.
app-emulation/qemu-kvm-0.11.0 needs >=sys-kernel/linux-headers-2.6.29, so I am affected by this. Is the best course of action for now to unmask the 'unstable' linux-headers?
Tested on x86, looks good with all the revdeps mentioned on tindebox's rindex.
Perhaps it's more useful to stabilize 2.6.32 headers as opposed to 2.6.30, since 2.6.32 is going to be a "long-term" stable release, per http://www.kroah.com/log/linux/stable-status-01-2010.html
(In reply to comment #14) > Perhaps it's more useful to stabilize 2.6.32 headers as opposed to 2.6.30, > since 2.6.32 is going to be a "long-term" stable release, per > http://www.kroah.com/log/linux/stable-status-01-2010.html vapier, anything severe that would prevent it?
stabilize 2.6.30. we're not throwing something that's been in the tree for less than a week into stable.
It might be a good time to get a newer version of sys-apps/hwinfo stable as the current stable does not build with newer headers per bug #236449.
x86 stable, thanks Andreas and Thomas.
Marked ppc/ppc64 stable.
Stable on amd64
(In reply to comment #11) > using caps lock doesnt make your argument correct. perhaps if you understood > how user/kernel space interacted and the strong ABI in play you wouldnt post > such incorrect statements. > (sorry - a long-winded attempt at asking "why") I must admit, I don't get this either. Isn't the only purpose of kernel-headers to provide out-of-kernel sources access to the kernel's data structures etc? Sure, you don't need the equivalent sys-kernel/kernel-headers-xxx when compiling the kernel itself, but doesn't it make sense to have the right set of kernel headers when compiling other pkgs? I mean, if I've already compiled and am running gentoo-sources-bleeding.edge.unstable , then what benefit is derived from having kernel-headers-old.but.stable ? Apologies if I've completely missed the point here ...
Stable for HPPA.
Stable on alpha.
you're assuming that the new headers dont break packages. they semi-frequently do considering they often get implicitly included in a vast number of packages. being a bit conservative here doesnt really hurt anything. on the flip side, new features added to the headers are much more infrequent and the only way those new features even matter is if some package actually uses them. which, again, are much more infrequent. plus, many of those features arent even meant to be used by the end developer ... you go through the C library to access the new functionality, and the library itself takes care of copying the required definitions to its own headers. so it really doesnt matter if you have bleeding edge headers if your C library isnt using them, or if it doesnt even use the kernel headers version. as for the ABI misinformation, there is no such requirement. the userspace/kernel ABI is _extended_, not _contracted_, so using old linux headers with newer kernel only semi-restricts access to _new_ functionality. things will continue to run just fine. HTH
arm stable
ia64/m68k/sparc stable
s390 done
