A/ Please update the tree with the attached ebuilds for the 3.4.36_p50 / 3.6.11_p31 / 3.8.4_p1 releases. B/ As we do not appear following the 3.0 and 3.2 branches and since 3.0.27_p46 and 3.2.14_p24 are somewhat outdated, my opinion is that we should drop them. - No significant modification in the ebuilds apart from switching the compression type of the rt-patch from bz2 to xz since this format appears to be the one preferred by the Gentoo kernel maintainers. Reproducible: Always
Created attachment 343008 [details] rt-sources-3.4.36_p50.ebuild Ebuild for the 3.4.36_p50 release of the STABLE branch Based on : - Sources for the linux 3.4.36 release - 3.4.36_p50 CONFIG_PREEMPT_RT patchset
Comment on attachment 343008 [details] rt-sources-3.4.36_p50.ebuild --- rt-sources-3.4.33_p47.ebuild 2013-03-10 20:40:54.475740423 +0100 +++ - 2013-03-23 18:10:19.660619778 +0100 @@ -19,7 +19,7 @@ detect_version K_BRANCH_ID="${KV_MAJOR}.${KV_MINOR}" -RT_FILE="patch-${K_BRANCH_ID}.${KV_PATCH}-rt${RT_PATCHSET}.patch.bz2" +RT_FILE="patch-${K_BRANCH_ID}.${KV_PATCH}-rt${RT_PATCHSET}.patch.xz" RT_URI="mirror://kernel/linux/kernel/projects/rt/${K_BRANCH_ID}/${RT_FILE}" DESCRIPTION="Full Linux ${K_BRANCH_ID} kernel sources with the CONFIG_PREEMPT_RT patch"
Created attachment 343010 [details] rt-sources-3.6.11_p31.ebuild Ebuild for the 3.6.11_p31 release. Based on : - Sources for the linux 3.6.11 release - 3.6.11-rt31 CONFIG_PREEMPT_RT patchset WARNING : Fixes for recent security issues are no longer backported to the 3.6 branch.
Created attachment 343012 [details] rt-sources-3.8.4_p1.ebuild Ebuild for the 3.8.4_p1 release. Based on : - Sources for the linux 3.8.4 release - 3.8.4-rt1 CONFIG_PREEMPT_RT patchset
Why do you attach ebuilds for rt-sources if this bug is about ck-sources?
(In reply to comment #5) > Why do you attach ebuilds for rt-sources if this bug is about ck-sources? I apologize for this Markos. I think I had done things right the first time but then jer bugged me with his -as-usual- fiddlings. I remade the things (summary & category) according to your requirements but... apparently... too quickly.
Thanks again for the ebuilds! I pushed them today. Two questions / notes: 1) The kernel (Makefile) EXTRAVERSION only contains the -rt suffix. I think it should probably be "-rt{n}". (-rt33, -rt1 etc). I think that's how the older ebuilds used to work (EXTRAVERSION="-rt${RT_PATCHSET}"). 2) I'm not sure about the removal of the deblob USE flag.
(In reply to comment #7) > 1) The kernel (Makefile) EXTRAVERSION only contains the -rt suffix. I think > it should probably be "-rt{n}". (-rt33, -rt1 etc). I think that's how the > older ebuilds used to work (EXTRAVERSION="-rt${RT_PATCHSET}"). a/ You are correct, older ebuilds were setting EXTRAVERSION as you say. b/ Feel free to put it back if you wish. My opinion is that : c/ There is nothing Gentoo-specific in the result you obtain after emerging the rt-sources. => It does not make much sense to particularize the makefile with something that appears to me mostly cosmetic. d/ There is as well nothing Gentoo-specific in the kernel you obtain after making => I do not think wise to fiddle things such as /proc/version on which users/programs may rely. e/ If the end user absolutely wishes to particularize /proc/version, he is free to use CONFIG_LOCALVERSION. > 2) I'm not sure about the removal of the deblob USE flag. I removed it from the ebuilds because the eclass does the job of setting deblob in IUSE depending on K_DEBLOB_AVAILABLE value.
BTW, I do not really care but it does not seem that the header of the ebuilds has been appropriately updated.
(In reply to comment #8) > a/ You are correct, older ebuilds were setting EXTRAVERSION as you say. > b/ Feel free to put it back if you wish. > > My opinion is that : > > c/ There is nothing Gentoo-specific in the result you obtain after emerging > the rt-sources. => > It does not make much sense to particularize the makefile with something > that appears to me mostly cosmetic. > d/ There is as well nothing Gentoo-specific in the kernel you obtain after > making => I do not think wise to fiddle things such as /proc/version on > which users/programs may rely. > e/ If the end user absolutely wishes to particularize /proc/version, he is > free to use CONFIG_LOCALVERSION. Ok, I ckeched the upstream patch and it doesn't even modify the EXTRAVERSION. IIRC, some patchsets did (maybe -ck). Anyway, my point is that since 3.8.4_p1 and 3.8.4_p2 differ, the /proc/version / uname -r etc should reflect that. It's not too important, so I'll maybe leave it as it is. > > 2) I'm not sure about the removal of the deblob USE flag. > > I removed it from the ebuilds because the eclass does the job of setting > deblob in IUSE depending on K_DEBLOB_AVAILABLE value. Ok, we could probably change the other -sources too, although I think it's actually better to have it explicitly in the ebuild. Seems more clear to me. (In reply to comment #9) > BTW, I do not really care but it does not seem that the header of the > ebuilds has been appropriately updated. Not sure what you mean. Anyway, closing this.
(In reply to comment #10) > (In reply to comment #9) > > BTW, I do not really care but it does not seem that the header of the > > ebuilds has been appropriately updated. > > Not sure what you mean. I mean that the header of the ebuilds committed in the tree still reflect the previous commit, v.g : # $Header: /var/cvsroot/gentoo-x86/sys-kernel/rt-sources/rt-sources-3.4.33_p47.ebuild,v 1.2 2013/03/09 21:07:33 tomwij Exp $ But that might well be of no importance at all.
I am sorry but I an afraid I must re-open. I understand that jeroen's did not help making this bug very clear but, as a matter of fact, the ebuild for the rt-sources-3.4.36_p50 I had initially attached but jer marked obsolete is actually meant to be pushed into the tree. (It's the stable branch and as such, even more important than the 2 others)
done Btw, the headers are correct. I guess you were confused with the 3.4 ebuild that didn't get bumped.
