With: LD block/partitions/built-in.o CC block/bsg.o CC block/noop-iosched.o CC block/deadline-iosched.o CC block/cfq-iosched.o make[1]: *** No rule to make target `block/bfq-iosched.o', needed by `block/built-in.o'. Stop. make: *** [block] Error 2 This looks to point to a problem with the way we apply the patches: http://forums.funtoo.org/viewtopic.php?id=1491 I am trying to review eclass to know how are they applied Reproducible: Always
Looking old zen-sources: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/zen-sources/zen-sources-2.6.34_p1-r1.ebuild?hideattic=0&revision=1.1&view=markup Looks like epatch detects wrongly "-p" parameter due new files being added and, then, forcing of "-p1" for them is needed
(In reply to Pacho Ramos from comment #1) > Looks like epatch detects wrongly "-p" parameter due new files being added > and, then, forcing of "-p1" for them is needed https://bugs.gentoo.org/show_bug.cgi?id=436424
*** Bug 474020 has been marked as a duplicate of this bug. ***
I think we definitely should fix the kernel eclass in the right way, which I will into with a fresh mind in a few hours from now after a night of sleep; failing that we could look for temporary workarounds. None the less, I will ensure that this patch is properly applied by 3.9.8 and hopefully before that. Pretty surprising that this patch points out a bug in the eclass; glad we uncovered this by adding these patches, this could have had worse effects if a more important patch was not properly applied.
*** Bug 474100 has been marked as a duplicate of this bug. ***
(In reply to Tom Wijsman (TomWij) from comment #4) > I think we definitely should fix the kernel eclass in the right way. Hmmm... Is there really something to be "fixed" in the eclass ? Considering the bug I linked to in my comment #2 : - Mike apparently did not confirm this was a bug, - I realized that the eclass provides an elegant way to sort this problem out. Whatever you decide to do with the eclass about this problem, please take care not to break the 2.6.38 < ck-sources < 3.8 which all use the facility offered by the eclass to force a specific PATCH_DEPTH, i.e : UNIPATCH_LIST="${UNIPATCH_LIST} ${DISTDIR}/${XPR_1_FILE} ${DISTDIR}/${XPR_2_FILE}:1"
There is already a very simple way to apply the patches correctly: rename them from .patch to .patchLEVEL e.g. .patch1
> CHANGES SINCE 3.7-14 and 3.9-11 > ------------------------------- > > Revision 2409: > Applied security patch to 3.7 for bug #469854, CVE-2013-2094 to auto > stable fix the remaining arches. Fixed BFQ patch depth for 3.9 such > that this release can be used by consumers, this fix will be present in > gentoo-sources-3.9.8. (tomwij) > Added: 1600_CVE-2013-2094-perf_swevent_enabled-OOB-access.patch > Added: 1802_block-introduce-the-BFQ-v6r2-I-O-sched-for-3.9.patch1 > Added: > 1803_block-bfq-add-Early-Queue-Merge-EQM-to-BFQ-v6r2-for-3.9.0.patch1 > Deleted: > 1802_block-introduce-the-BFQ-v6r2-I-O-sched-for-3.9.patch > Deleted: > 1803_block-bfq-add-Early-Queue-Merge-EQM-to-BFQ-v6r2-for-3.9.0.patch > > Revision 2410: > 3.7-15 release. > > Revision 2411: > 3.9-12 release. Made the decision to write a test ebuild that uses as much functionality from the eclass as possible and ensures a local QA check to avoid this from everhappening again and thus I just apply it anyway, since I also made it build and install the kernel this makes it more proper and streamlined to test the genpatches. Patching it in the eclass appears to be a hack that may have other consequences, we can not assume any consumer would not apply a patch that contain an intentional b directory, that would also make the eclass more complex. We are however thinking about possible approaches to make this less likely to occur, like for instance trying -p1 before -p0; but we need to inspect if such methods would not induce any breakage anywhere. Another option is to expect everyone to just use -p1, but that might be received as unacceptable. Users that wish to use BFQ can simply execute `mv /usr/src/linux-3.9.7-gentoo/b/* /usr/src/linux-3.9.7-gentoo/` as a temporary fix or bump the genpatches revision to 12 in the ebuild and run `repoman manifest` in the same directory. The permanent fix will be present in gentoo-sources-3.9.8 as a revision bump is unacceptable for a single optional patch. Other *-sources may choose to do this at their own convenience, or maybe have not bumped yet and could use the right genpatches version right away. Sorry for the temporary unintended inconvenience towards BFQ users. Thank you for reporting. Have a nice day.
(In reply to Tom Wijsman (TomWij) from comment #8) > `mv /usr/src/linux-3.9.7-gentoo/b/* /usr/src/linux-3.9.7-gentoo/` Sorry, use `cp -R ...` instead of `mv ...` to prevent it from bailing out.
(In reply to Tom Wijsman (TomWij) from comment #8) [...] > as a temporary fix or bump the genpatches revision to 12 in the ebuild and > run `repoman manifest` in the same directory. > > The permanent fix will be present in gentoo-sources-3.9.8 as a revision bump > is unacceptable for a single optional patch. [...] Why not simply bump genpatches revision to 12 in current 3.9.7 ebuild? (without revision bump for gentoo-sources) That way, people installing 3.9.7 now will get it fixed, and other people like we can simply re-emerge it
(In reply to Pacho Ramos from comment #10) > Why not simply bump genpatches revision to 12 in current 3.9.7 ebuild? > (without revision bump for gentoo-sources) Oh, haven't thought about and have the "revision bump if image changes" idea a bit too much in my mind; but I found the following relevant part in the ebuild policy that should make this a good reason to do so: > Likewise, if you fix a compilation problem in the ebuild that was affecting some users, there is no need to bump the revision number, since those for whom it worked perfectly would see no benefit in installing a new revision, and those who experienced the problem do not have the package installed (since compilation failed) and thus have no need for the new revision number to force an upgrade. A revision bump is also not necessary if a minority of users will be affected and the package has a nontrivial average compilation time; use your best judgement in these circumstances. This definitely limits the impact, I will make sure to do this more soon in the future when needed and allowed. + 22 Jun 2013; Tom Wijsman <TomWij@gentoo.org> gentoo-sources-3.9.7.ebuild: + Use the genpatches where the patch depth is forced for the BFQ patches that + failed; no rev bump needed, allowed per ebuild policy. See bug #474008, + comment 10 and 11. Thank you for reminding me of that; sometimes I try to follow the rules too much that I forget about its exceptions. :) So, CFQ users are suggested to re-emerge the package after syncing again (wait at least an hour from now) or use one of the earlier temporary solutions.
Thanks!
