Bug 354069

Summary:	sys-libs/newlib invalid metadata
Product:	Gentoo Linux	Reporter:	Tiziano Müller (RETIRED) <dev-zero>
Component:	New packages	Assignee:	Luca Barbato <lu_zero>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	branko, vapier, zima
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Tiziano Müller (RETIRED) gentoo-dev

2011-02-08 08:53:20 UTC

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).

Comment 1 Petr Zima 2011-02-08 09:46:22 UTC

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.

Comment 2 SpanKY gentoo-dev

2011-02-10 02:47:08 UTC


*** This bug has been marked as a duplicate of bug 174407 ***

Comment 3 Tiziano Müller (RETIRED) gentoo-dev

2011-02-10 08:38:25 UTC

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)?

Comment 4 Branko Majic 2011-02-12 15:10:44 UTC

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?

Comment 5 SpanKY gentoo-dev

2011-02-12 23:52:10 UTC

that's nice.  the ebuild no longer supports newlib-on-glibc installs.

Comment 6 Tiziano Müller (RETIRED) gentoo-dev

2011-02-13 09:03:59 UTC

right, newlib is fixed. uclibc still has problems, opened a new bug for it: bug #354701