You are using cobalt in SRC_URI but not in IUSE. dev-lisp/sbcl-1.0.6-r1: attr(fetchables) uses unstated flags [ cobalt ] dev-lisp/sbcl-1.0.6-r2: attr(fetchables) uses unstated flags [ cobalt ]
it is to distinguish mips from mipsel binaries. There is no official keyword that does this, so we have to use this kludge. Just like other keywords it shouldn't be in IUSE, so I intentionally left it out.
(In reply to comment #1) > it is to distinguish mips from mipsel binaries. There is no official keyword > that does this, so we have to use this kludge. That's fine, then stick it in IUSE. > Just like other keywords it shouldn't be in IUSE This is not a keyword, it's a USE flag; as such it belongs in IUSE as it is the case with the remaining ebuilds: # euse -i cobalt global use flags (searching: cobalt) ************************************************************ no matching entries found local use flags (searching: cobalt) ************************************************************ [- ] cobalt (dev-lisp/sbcl): mips only: use mipsel binary instead of mips big endian binary to bootstrap [- ] cobalt (sys-boot/arcboot): Disables support for Cobalt Microserver hardware (Qube2/RaQ2) [- ] cobalt (sys-kernel/mips-headers): Enables support for Cobalt Microserver hardware (Qube2/RaQ2) [- ] cobalt (sys-kernel/mips-sources): Enables support for Cobalt Microserver hardware (Qube2/RaQ2)
it is an unofficial arch keyword, nobody should enable or disable it.
Please, could you have a look at the ebuilds mentioned above (and for that matter, at any other ebuilds that have ip27, ip28, or ip30 USE flags as well? All USE flags used in an ebuild belong to IUSE. Whether users should or should not enable or disable them is irrelevant. I don't see any reason why dev-lisp/sbcl should be special and break policy.
I don't want it showing up anywhere that x86, amd64, ppc, mips etc don't show up. Nobody need see it is there and nobody needs to care about it. I'm not claiming SBCL is special. What I am claiming is that policy is that keywords should not be in IUSE and cobalt is (used as) a keyword in this and probably the other cases.
Well, sending this to QA then, this doesn't go anywhere. If you want to be it a keyword, then make it so w/ MIPS folks (ditto for the rest of 'keywords' mentioned above. Until it's a keyword, it's a use flag that belongs to IUSE.
Marijn - please put the cobalt edits back the way they were. The way the ebuilds currently are is just plain wrong. Thanks.
No, there is no reason for the Arch flag to clutter up the use flags, especially not while its main arch is broken and unkeyworded.
(In reply to comment #8) You know, I talked with Redhatter about this and they specifically *want* these flags *visible* on non-mips profiles as well because of cross-compile purposes. You instead decided to break it once again once Redhatter fixed this two weeks ago. Please revert your broken commit that's in breach of policy, it's getting really annoying.
Redhatter should talk to ME if he has anything to say about this. Further there is no way cross compilation works at all with the ebuild.
(In reply to comment #10) > Redhatter should talk to ME if he has anything to say about this. Please, read the fine devmanual, cobalt is NOT an arch flag no matter how much you wish it was one, and there's zero valid reasons your ebuild should be special (cf. Comment #2, Comment #4) http://devmanual.gentoo.org/ebuild-writing/variables/index.html cat $PORTDIR/profiles/arch.list This is getting old. QA, please fix the ebuild, this debate goes nowhere.
Instead of the use flag it is probably possible to use toolchain-funcs.eclass to determine the endianness of the mips arch with the tc-endian function.
(In reply to comment #12) > Instead of the use flag it is probably possible to use toolchain-funcs.eclass > to determine the endianness of the mips arch with the tc-endian function. No, you totally can't use toolchain-funcs.eclass in SRC_URI, please stop being silly and stick the flag back.
(In reply to comment #7) > Marijn - please put the cobalt edits back the way they were. The way the > ebuilds currently are is just plain wrong. Thanks. > Please fix this now. It should be in IUSE. This is the same as the IP28, ip32r10k, etc USE flags which all get put into IUSE. Thanks
If anyone's looking for a clean solution to this... Bring back PROFILE_ARCH, call it something less silly like SUBARCH and USE_EXPAND{,HIDDEN} it. It'll still need to be in IUSE (as subarch_cobalt), but it'll be hidden from end users.
(In reply to comment #15) > If anyone's looking for a clean solution to this... Bring back PROFILE_ARCH, > call it something less silly like SUBARCH and USE_EXPAND{,HIDDEN} it. It'll > still need to be in IUSE (as subarch_cobalt), but it'll be hidden from end > users. > That sounds like an idea for a longer term solution, but right now it has to go back into IUSE like it is for arcboot, mips-headers, and mips-sources.
Fixed. If you would like to pursue the solution that Ciaran gave below, please open a new bug so it can be discussed. Thanks
