The newlib ebuilds rely on certain global variables to be defined during metadata-generation but they are not defined (check the metadata for newlib after syncing from tree) and can't be reliably defined (since they are target-specific). This results in invalid SLOT-names in the newlib-metadata (slot-names starting with a dash '-...'). CC'ing QA since this is quiet a common error in certain packages (older versions of uclibc still in tree, kgcc64, etc.) and leaving the decision to them whether to open a tracker-bug for all of those packages or close/depend this if such a tracker-bug already exists (didn't find any).
Confirming this bug, it applies to all versions of sys-libs/newlib, and also to all versions of sys-libs/uclibc. Although I do not use any of those, the corrupt metadata cause errors while generating the search index for paludis. Metadata of other packages seem to be ok.
*** This bug has been marked as a duplicate of bug 174407 ***
not a duplicate: it's not about USE-dep SLOTS but the package depends on other non-mandatory variables. I could as well CC infra since we're distributing invalid metadata via our mirrors. How about setting a valid default slot when checking for CHOST/CTARGET instead of assuming they're valid (as seen in uclibc-ebuilds >=0.9.30)?
SLOT should be invariant according to: http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-680008.1 This sounds more like a violation of the current specification since it seems to depend on something that is dependant on user's configuration files. Should we open-up another bug report for this for uclibc?
that's nice. the ebuild no longer supports newlib-on-glibc installs.
right, newlib is fixed. uclibc still has problems, opened a new bug for it: bug #354701
