Bug 380999 – kernel-2.eclass breaks with linux-headers-3.0

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description SpanKY 2011-08-29 05:08:55 UTC]

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 !

[Comment 1 Mike Pagano 2011-08-29 12:46:19 UTC]

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.

[Comment 2 SpanKY 2011-08-29 20:46:41 UTC]

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.

[Comment 3 Mike Pagano 2011-08-29 23:30:29 UTC]

I'll take a look when I have some time. Grab a chair and get patient.

[Comment 4 SpanKY 2011-08-30 01:33:45 UTC]

np.  not in a rush here.

[Comment 5 Mike Pagano 2011-08-30 10:57:39 UTC]

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"

[Comment 6 Mike Pagano 2011-08-30 12:39:02 UTC]

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

[Comment 7 SpanKY 2011-12-02 04:52:03 UTC]

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

[Comment 8 Mike Pagano 2011-12-02 16:25:18 UTC]

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.

[Comment 9 SpanKY 2011-12-02 19:00:39 UTC]

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.

[Comment 10 Mike Pagano 2011-12-03 00:43:33 UTC]

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.

[Comment 11 Anthony Basile 2011-12-05 21:25:32 UTC]

(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.

[Comment 12 SpanKY 2011-12-10 07:58:03 UTC]

http://sources.gentoo.org/eclass/kernel-2.eclass?r1=1.271&r2=1.272