@proxy-maint : Could you please push the 3.5.7 release of sys-kernel/ck-sources into portage's tree. You will need the 4 files attached : One metadata - One ebuild - Two patches. For the changelog, I suggest that you link to this bug. Thanks for your contribution. Reproducible: Always
Created attachment 326918 [details] Package metadata New metadata including description for the new useflags : - bfsonly - experimental - urwlocks
Created attachment 326920 [details] Ebuild for 3.5.7 - Building linux 3.5 + genpatches rev 7 + 3.5-ck-1 patchset (BFS 424) - Honoring new useflags as described in the metadata : - bfsonly : enabling to install only the BFS rather than the full patchset. - experimental : enabling experimental patches - urwlocks : Modifying the global runqueue of BFS in order to use upgradeable read/write locks in place of the grq spinlock.
Created attachment 326922 [details, diff] Patch enabling the application of the ck-patchset This patch reverts the modifications made in sched.h by 1004_linux-3.5.5.patch which prevent the ck-patchset to apply smoothly.
Created attachment 326924 [details, diff] Patch restoring 1004_Linux-3.5.5 modifications for CFS configs Applied after the ck-patchset, this patch restores the modifications made in sched.h and init_task.h by 1004_Linux-3.5.5, enabling kernel configurations for which CONFIG_SCHED_BFS is not set.
*** This bug has been marked as a duplicate of bug 437088 ***
(In reply to comment #5) > > *** This bug has been marked as a duplicate of bug 437088 *** I am afraid I do not understand the way you work Jeroen: - You get Bug B1 with a summary = S1 - You get Bug B2 with a summary = S2 => - You change Bug B1's summary to S2 - You flag B2 as duplicate of B1 ???? BTW : This bug is to the intention of the proxy maintainers. I opened it irrespective of the other one because : 1- This is *not* the same topic 2- The attachment in the other bug is *not* to be pushed in the tree => For proxy-maintainers' comfort, I wanted only the appropriate files to be attached. 3- This bug was intended to *serve as a changelog* that is to say *not* to be mixed with some academic discussion !
OK, SO I WILL WORD MY QUESTION DIFFERENTLY : CAN YOU REFRAIN FROM FLAGGING THIS BUG "RESOLVED WHATEVER", UNTIL THE PROXY MAINTAINERS COMMIT THIS RELEASE INTO THE TREE ?
Created attachment 327032 [details] Ebuild for 3.5.7 [Adapting to new ck urls]
hrmmm... it seems that Bug 439502 represents a valid reason for waiting longer.
(In reply to comment #8) > OK, SO I WILL WORD MY QUESTION DIFFERENTLY : > > CAN YOU REFRAIN FROM FLAGGING THIS BUG "RESOLVED WHATEVER", UNTIL THE PROXY > MAINTAINERS COMMIT THIS RELEASE INTO THE TREE ? please relax. Jer is right. Two similar bugs existed for a the same request. And please don't write in capitals
Please keep a single bug for version bumps. Lets handle that in 437088 *** This bug has been marked as a duplicate of bug 437088 ***
(In reply to comment #10) > hrmmm... it seems that Bug 439502 represents a valid reason for waiting > longer. The conclusions reached about the ext4 progressive data corruption problem support the decision to stop considering Bug 439502 as a blocker.
*** Bug 437088 has been marked as a duplicate of this bug. ***
There is a problem here. The deblog use flag must be present and used by the ebuild if the user requests it. Please provide an ebuild that does what the previous versions of ck-sources used to do. Also the metadata.xml needs to be fixed to include this flag as well
Hrmmm... There is something I must be missing somewhere : A/ As far as I can see, the last version of the ck-sources actually honoring the deblob use flag is 2.6.38-r3 B/ This version does not honor the deblob use flag "voluntarily", that is to say thanks to any explicit effort made in the ebuild but only thanks to some automagic decision from the kernel-2.eclass helper, automagic decision pushed as a solution for Bug 359865. C/ Since ${DEBLOB_MAX_VERSION:=38}, the automagic decision is not taken for > 2.6.38 kernels and as K_DEBLOB_AVAILABLE is not explicitly set in associated ebuilds, no > 2.6.38 ck-sources package honor the deblob use flag. BTW, I see that A,B and C statements are worth for the pf-sources too. As a consequence of these observations, I can of course easily restore the description of the deblob use flag in the metadata for the sole interest of the obsolete and deprecated 2.6.38 but I fail understanding what you want next as, "providing an ebuild that does what the previous versions of ck-sources used to do" will *not* enable a build honoring the deblob useflag. If you state that "The deblog use flag *must* be present and used by the ebuild if the user requests it" then I believe you but then, I will need first to dig into a lot of unwritten history in order to understand what have been the good reasons of ck-sources / pf-sources maintainers to ignore this obligation.
Sorry ignore me. I forgot that all this deblob stuff is coming from the eclass
+*ck-sources-3.5.7 (26 Oct 2012) + + 26 Oct 2012; Markos Chandras <hwoarang@gentoo.org> + +files/ck-sources-3.4-3.5-PostCK-Sched_Fix_Race_In_Task_Group-aCOSwt_P5.patch + , + +files/ck-sources-3.4-3.5-PreCK-Sched_Fix_Race_In_Task_Group-aCOSwt_P4.patch, + +ck-sources-3.5.7.ebuild, metadata.xml: + Version bump. Thanks to Eric F. GARIOUD <eric-f.garioud@wanadoo.fr>. + Fixes bug #438910 + I had to fix the following problems as well: IUSE.invalid 1 sys-kernel/ck-sources/ck-sources-2.6.38-r3.ebuild: deblob ebuild.minorsyn 2 sys-kernel/ck-sources/ck-sources-3.5.7.ebuild: Trailing whitespace error on line: 50 sys-kernel/ck-sources/ck-sources-3.5.7.ebuild: Malformed CVS Header on line: 3
(In reply to comment #17) > Sorry ignore me. I forgot that all this deblob stuff is coming from the > eclass Hrmmm... as I wrote in comment #16, this deblob stuff *was* coming, transparently to the ebuild, from the eclass, up to 2.6.38. It is now still coming from the eclass but with a little bit less transparency. K_DEBLOB_AVAILABLE is to be set and the deblob use flag explicitly declared if we wish to provide this facility. As a consequence of this, no >2.6.38 pf/ck - sources kernels provide this facility. I am not an expert in licenses but I see that the pf-ck sources are distributed under the GPL-2 freedist licenses. So it could be that, because of the freedist license, you are indeed correct underlining that "The deblob use flag must be present and used by the ebuild if the user requests it". What is your opinion about this as pf-sources maintainer ? - Drop the freedist license ? - K_DEBLOB_AVAILABLE=1 ? - Ignore ?
(In reply to comment #19) > (In reply to comment #17) > > Sorry ignore me. I forgot that all this deblob stuff is coming from the > > eclass > > Hrmmm... as I wrote in comment #16, this deblob stuff *was* coming, > transparently to the ebuild, from the eclass, up to 2.6.38. > It is now still coming from the eclass but with a little bit less > transparency. > K_DEBLOB_AVAILABLE is to be set and the deblob use flag explicitly declared > if we wish to provide this facility. > > As a consequence of this, no >2.6.38 pf/ck - sources kernels provide this > facility. > > I am not an expert in licenses but I see that the pf-ck sources are > distributed under the GPL-2 freedist licenses. > > So it could be that, because of the freedist license, you are indeed correct > underlining that "The deblob use flag must be present and used by the ebuild > if the user requests it". > > What is your opinion about this as pf-sources maintainer ? > - Drop the freedist license ? > - K_DEBLOB_AVAILABLE=1 ? > - Ignore ? If K_DEBLOB_AVAILABLE works, then I'd go with that... The other options are not ideal to me
