as indicated by Linus the next stable release of linux will be 3.0. (current 3.0-rc1) kernel-2 eclass doesn't currently handle this new situation Reproducible: Always Steps to Reproduce: 1. create an ebuild using 2 part versioning e.g. vanilla-sources-3.0_rc1.ebuild 2. emerge vanilla-sources-3.0_rc1 Actual Results: * Missing variables: KV_PATCH * ERROR: sys-kernel/vanilla-sources-3.0_rc1 failed (depend phase): * Failed to extract kernel version (try explicit CKV in ebuild)! * * Call stack: * ebuild.sh, line 2047: Called source '/opt/noc4/portage/sys-kernel/vanilla-sources/vanilla-sources-3.0_rc1.ebuild' * vanilla-sources-3.0_rc1.ebuild, line 12: Called inherit 'kernel-2' * ebuild.sh, line 1410: Called qa_source '/usr/portage/eclass/kernel-2.eclass' * ebuild.sh, line 43: Called source '/usr/portage/eclass/kernel-2.eclass' * kernel-2.eclass, line 334: Called kernel_is 'ge' '2' '6' '27' * kernel-2.eclass, line 277: Called detect_version * kernel-2.eclass, line 171: Called die * The specific snippet of code: * [[ $n -eq 1 ]] && \ * eerror "Missing variables: ${missing}" && \ * die "Failed to extract kernel version (try explicit CKV in ebuild)!" * * If you need support, post the output of 'emerge --info =sys-kernel/vanilla-sources-3.0_rc1', * the complete build log and the output of 'emerge -pqv =sys-kernel/vanilla-sources-3.0_rc1'. * This ebuild is from an overlay: '/opt/noc4/portage/' * S: '/var/tmp/portage/sys-kernel/vanilla-sources-3.0_rc1/work/vanilla-sources-3.0_rc1' Expected Results: merge 3.0-rc1 sources ok :) Linus's quote: "We'll have the usual 6-7 weeks to wrestle it into submission, and get scripts etc cleaned up, and the final release should be just "3.0"." ref.: https://lkml.org/lkml/2011/5/29/204
Created attachment 275395 [details, diff] kernel-2.eclass.patch git sources only Ok, here's a patch that enables git sources be found and to download properly. "the final release should be just "3.0". The -stable team can use the third number for their versioning." So the three point versioning is now a bit different. From Linus' quote, it won't be 3.0.0 with 3.0.0.1, 3.0.0.2 for -stable. it will be 3.0 and 3.0.1, 3.0.2 etc for -stable This will need some more work, and everyone's help is appreciated. I might start CC'in the usual kernel suspects.
Also there is different issue with linux-mod eclass. It assumes that linux kernels other than 2.6 uses .o format for kernel modules
linux-mod is now fixed.
hmm we're going to have a bit of a kludge I guess in that we cant use OKV="${KV_MAJOR}.${KV_MINOR}.$((${KV_PATCH} - 1))" KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.bz2 ${KERNEL_BASE_URI}/testing/linux-${OKV}.tar.bz2" when we're dealing with 3.0-rc1 since patch-3.0-rc1 is actually against 2.6.39 so I guess in that case we need: KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.bz2 mirror://kernel/linux/kernel/v2.6/testing/linux-2.6.39.tar.bz2" or maybe a more generic way of doing this for any future version jumps via some variables (thinking of 4.x here :) ?
(In reply to comment #4) > hmm we're going to have a bit of a kludge I guess in that we cant use > > OKV="${KV_MAJOR}.${KV_MINOR}.$((${KV_PATCH} - 1))" > KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.bz2 > ${KERNEL_BASE_URI}/testing/linux-${OKV}.tar.bz2" that should have been OKV="${KV_MAJOR}.${KV_MINOR}.$((${KV_PATCH} - 1))" KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.bz2 ${KERNEL_BASE_URI}/linux-${OKV}.tar.bz2" > > when we're dealing with 3.0-rc1 since patch-3.0-rc1 is actually against 2.6.39 > > so I guess in that case we need: > > KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.bz2 > mirror://kernel/linux/kernel/v2.6/testing/linux-2.6.39.tar.bz2" > and again! KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.bz2 mirror://kernel/linux/kernel/v2.6/linux-2.6.39.tar.bz2" > > or maybe a more generic way of doing this for any future version jumps via some > variables (thinking of 4.x here :) ? K_BASEVERSION maybe?
Created attachment 275635 [details, diff] Patch to handle 2 part kernel version Please everyone test this patch, I was able to fetch and unpack for vanilla, git and gentoo-sources, including deblob and LONGTERM
Tested the patched kernel-2.eclass with git-sources-3.0_rc1, and gentoo-sources-2.6.39 and works fine (fetch && unpack). I also fetched without problems older versions of gentoo-sources, vanilla, tuxonice, zen and hardened. Seems that the patch works fine, and the code/patch looks ok too. :)
Thanks, Stratos. I'm going to go ahead and commit this change. I'm sure when 3.0.1, etc comes out we might have some more tweaking to do. At that time, we can fix this eclass, again. If kernel maintainers or bash experts see any improvements needed to my changes in this eclass, please let us know.
+1 also tested with vanilla-sources-3.0-rc1 - thanks Mike :)
yw, thanks. I'm going to close this as I committed the change, we can reopen for next breakage or create a new bug. :) Thanks, everyone who reported and tested.
I just tested with hardened-sources-2.6.X-rY and it does not appear to break there either.
Resolving again as I'm guessing Anthony did not mean to remove that.
