using linux-headers-2.6.39 works fine, but linux-headers-3.0 doesnt. the S value seems to get screwed up somehow. just copy existing linux-headers-2.6.39 ebuild to linux-headers-3.0.ebuild. you can find the two tarballs in my dist dir: http://dev.gentoo.org/~vapier/dist/ >>> Emerging (1 of 1) sys-kernel/linux-headers-3.0 * gentoo-headers-base-3.0.tar.xz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * gentoo-headers-3.0-1.tar.xz RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking gentoo-headers-base-3.0.tar.xz to /var/tmp/portage/sys-kernel/linux-headers-3.0/work >>> Unpacking gentoo-headers-3.0-1.tar.xz to /var/tmp/portage/sys-kernel/linux-headers-3.0/work /var/tmp/portage/sys-kernel/linux-headers-3.0/temp/environment: line 3180: cd: /var/tmp/portage/sys-kernel/linux-headers-3.0/work/linux-3.0: No such file or directory * Applying various patches (bugfixes/updates) ... * 00_all_0001-kbuild-auto-convert-size-types-in-userspace-headers.patch ... * Failed Patch: 00_all_0001-kbuild-auto-convert-size-types-in-userspace-headers.patch !
Mike, We've been using 3.0.0 for this series. The eclass was coded to this. Would you object, or are there issues to using linux-headers-3.0.0? I changed the ebuild name, renamed and recreated your tarballs using 3.0.0 naming and it installed without issue. >>> Installing (1 of 1) sys-kernel/linux-headers-3.0.0 >>> Recording sys-kernel/linux-headers in "world" favorites file... >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. * IMPORTANT: 2 news items need reading for repository 'gentoo'. * Use eselect news to read news items.
the upstream kernel version is "3.0", not "3.0.0". and for the next release, it's going to be "3.1", not "3.1.0". seems like we should fix our code to handle this since it's the new world order and not a passing fad.
I'll take a look when I have some time. Grab a chair and get patient.
np. not in a rush here.
One more try to convince you. This kernel version is certainly spoken as the 3.0 kernel, but the Makefile clearly shows it as 3.0.0. VERSION = 3 PATCHLEVEL = 0 SUBLEVEL = 0 EXTRAVERSION = NAME = Sneaky Weasel And 3.1, will also clear be 3.1.0. VERSION = 3 PATCHLEVEL = 1 SUBLEVEL = 0 EXTRAVERSION = -rc4 NAME = "Divemaster Edition"
Not to keep beating this drum: openSUSE also thought about this and came to the same conclusion as our kernel team: http://lists.opensuse.org/opensuse-kernel/2011-06/msg00028.html Debian: http://packages.debian.org/testing/kernel/linux-headers-3.0.0-1-486 Fedora http://rpm.pbone.net/index.php3/stat/4/idpl/16874643/dir/fedora_1/com/kernel-headers-3.0.0-1.fc16.i686.rpm.html It seemed strange to me to install vanilla-sources-3.0 and the do uname -na and get 3.0.0
looks to me like the problem lies in detect_version. it keeps resetting $S when it probably shouldnt be. this is already a problem for linux-headers as can be seen when you run `emerge --debug linux-headers`: ++ S=/var/tmp/portage/sys-kernel/linux-headers-2.6.39/work/linux-2.6.39 ++ S=/var/tmp/portage/sys-kernel/linux-headers-2.6.39/work/gentoo-headers-base-2.6.39 ++ S=/var/tmp/portage/sys-kernel/linux-headers-2.6.39/work/linux-2.6.39 ++ S=/var/tmp/portage/sys-kernel/linux-headers-2.6.39/work/gentoo-headers-base-2.6.39 which means to me we should change detect_version: - if [[ -n ${KV_FULL} ]]; then - # we will set this for backwards compatibility. - KV=${KV_FULL} - - # we know KV_FULL so lets stop here. but not without resetting S - S=${WORKDIR}/linux-${KV_FULL} - return - fi + # We've already run, so nothing to do here. + [[ -n ${KV_FULL} ]] && return 0
Thanks, Mike. I will definitely run with this locally for a bit and encourage others too, also. I will be traveling for a week, but if all looks well I can commit it then, or someone can commit it beforehand if necessary.
thanks ... that should address the technical issues of calling it "linux-headers-3.0" which means we can get back to bike shedding about "3.0" vs "3.0.0" if you want ;). from the kernel-headers pov, i don't think it matters that much.
In my list of things in my life I need to worry about, kernel version numbers are fairly low. ;) I plan on poking the hardened guys to also give this a run through with their kernels.
(In reply to comment #10) > In my list of things in my life I need to worry about, kernel version numbers > are fairly low. ;) > > I plan on poking the hardened guys to also give this a run through with their > kernels. I made the change suggested in Comment 7 to the eclass and emerged then unmerged hardened-sources-3.1.4. No problems.
http://sources.gentoo.org/eclass/kernel-2.eclass?r1=1.271&r2=1.272
