I have confirmed evidence for: sys-kernel/aufs-sources sys-kernel/ck-sources sys-kernel/gentoo-sources sys-kernel/tuxonice-sources All those packages call use* at least one in global scope. This is forbidden, unpredictable and is fatal error in Portage starting with EAPI 6. if I understand the creepy code correctly, this happens via detect_version call, which in turn calls handle_genpatches, which has 'use experimental'. There may be more uses. Please fix it urgently.
Fixed, but needs more testing. handle_genpatches affects both the URI and the GENPATCHES list of patch tarballs to apply...
The 'fix' broke installing kernel-sources and should be reverted. See https://bugs.gentoo.org/show_bug.cgi?id=566600
(In reply to Patrick Lauer from comment #2) > The 'fix' broke installing kernel-sources and should be reverted. See > https://bugs.gentoo.org/show_bug.cgi?id=566600 Reverted now.
Created attachment 417716 [details, diff] kernel-2.eclass patch Ok, so here is my shot. Please test if you have the time. After this I will tackle 'use kdbus'. I added this to an ebuild: K_EXP_GENPATCHES_NOUSE=`use experimental && echo "1"` I need someone to tell me if that's OK, or if I'm breaking bash in ways no man has ever done before, and I should be committed. I'll attach the test ebuild also.
Created attachment 417718 [details] test ebuild USE=experimental ebuild gentoo-sources-4.2.4.ebuild manifest clean unpack should install experimental patchset and ebuild gentoo-sources-4.2.4.ebuild manifest clean unpack should not install experimental patchset
That's still global scope 'use' call, just moved to another place, you know.
(In reply to Michał Górny from comment #6) > That's still global scope 'use' call, just moved to another place, you know. Help me understand, please. I took out 'use experimental' and the code now looks for a variable set from the ebuild. Is that still invalid?
It is because the ebuild now calls use in global scope. I don't really know the code but I suspect you want to use 'experimental?' in metadata.
Ok, I understand. What would be cool is if I could call a function defined in the ebuild and then call super().
Created attachment 417800 [details, diff] kernel-2.eclass patch V2 Some changes for the eclass. 1. Removed the export of pkg_setup so the use checks can happen in the function in the ebuild. Deleted unused code and move the rest to other parts of the eclass. 2. Removed any sign of 'use experimental' 3 Added a new variable that can be set in pkg_setup in the ebuilds to pull in experimental patch set or not pull it in.
Created attachment 417802 [details] Test ebuild Check for 'use experimental' in pkg_setup and set eclass variable accordingly.
Did you merge some irrelevant changes in that patch, or am I incorrect? setup_headers doesn't really belong in global scope either. You're doing arch conditionals there. You are going to cause cache regen fail for all headers which are not for arch used by machine generating the cache. Now experimental are in GENPATCHES_URI without 'experimental? ( )' condition. I don't think that's desired. I still barely understand all the creepy code in there but I believe what you'd really want there is splitting handle_genpatches in two parts -- one to be called in global scope to set up the URIs (without 'use' call, but generating 'experimental? ( ... )'), and the other to be called in phase scope to set UNIPATCH_LIST_GENPATCHES.
(In reply to Michał Górny from comment #12) > Did you merge some irrelevant changes in that patch, or am I incorrect? > > setup_headers doesn't really belong in global scope either. You're doing > arch conditionals there. You are going to cause cache regen fail for all > headers which are not for arch used by machine generating the cache. > > Now experimental are in GENPATCHES_URI without 'experimental? ( )' > condition. I don't think that's desired. > > I still barely understand all the creepy code in there but I believe what > you'd really want there is splitting handle_genpatches in two parts -- one > to be called in global scope to set up the URIs (without 'use' call, but > generating 'experimental? ( ... )'), and the other to be called in phase > scope to set UNIPATCH_LIST_GENPATCHES. Well, clearly this 'creepy' code needs a better eclass developer than I am. You mention a lot of baggage that's been around longer than me. setup_headers has been around forever. Right or wrong. I appreciate your bits of direction here, but without any more concrete suggestions that aren't going to result in a real solution I don't think I going to be able to create something that satisfies.
No, i mean your patch removes pkg_setup which seemed irrelevant. Anyway, I'll try to tackle it today and hopefully find a simple solution. Though the eclass pretty much requires solid rewrite.
My suggested solution: https://github.com/gentoo/gentoo/pull/442 Tested it with gentoo-sources, should work with others too.
(In reply to Michał Górny from comment #15) > My suggested solution: > > https://github.com/gentoo/gentoo/pull/442 > > Tested it with gentoo-sources, should work with others too. Passed through my testing fine.
Should I merge it then?
(In reply to Michał Górny from comment #17) > Should I merge it then? +1 from me. Hardened team, please bless.
I hope it's ok to reassign to hardened to get it on your guys radar. Looking for an 'OK' here, please. Or a 'not OK'.
Merged given prometheanfire approval on the PR.
