[gentoo-dev] QA last rites for net-misc/rarpd
# Diego E. Pettenò (30 Aug 2009) # on behalf of QA team # # Blocks iputils since 2007 (and iputils is a system # package); lacks a Gentoo maintainer, and upstream seems # to be gone. The same code has been used and patched since # 2002 at least. # # Removal on 2009-10-29 net-misc/rarpd
[gentoo-dev] QA last rites for dev-util/qtunit
# Diego E. Pettenò (30 Aug 2009) # on behalf of QA team # # Uses serial make (and can't build in parallel, bug # #283170); last release in 2004, declared dead upstream, # uses Qt 3. # # Removal on 2009-10-29 dev-util/qtunit
[gentoo-dev] QA last rites for sys-process/acctail
# Diego E. Pettenò (30 Aug 2009) # on behalf of QA team # # Fails to build since at least November 2007, bug #199164. # # Removal on 2009-10-29 sys-process/acctail
[gentoo-dev] Re: 2009.0 profiles
Mike Frysinger posted on Sat, 29 Aug 2009 02:56:33 -0400 as excerpted: > On Friday 28 August 2009 20:05:12 Alex Alexander wrote: >> On Sat, Aug 29, 2009 at 00:23, Mike Frysinger wrote: >> > On Friday 28 August 2009 16:27:18 Sebastian Pipping wrote: >> >> Mike Frysinger wrote: >> >> > 10.0 is retarded >> >> >> >> How would you like the problem to be addressed? >> > >> > we already have a simple logical version system. 2009.0 is the next >> > step. >> >> Years do not make a good versioning scheme, if one release gets out >> late you're automatically considered outdated by users. > > then help the release team to get more tested releases, otherwise > reality is we are releasing out of date install media But as we all know, releases != profiles. If there's no reason to update the profiles besides the fact that the name incorporates a year, and they look out of date, why do so? For that reason, getting away from year for the profiles is a reasonable idea, now that Gentoo seems to be mature enough that we don't need a new profile multiple times a year. OTOH, having the year in there, as long as people don't get fixated on it, can be useful as an indication of when the profile was born, just not necessarily that it's outdated. If it weren't for the outdated appearance, therefore, year would be fine. Whatever, bikeshedding from my perspective, and this one I don't /care/ what the color/name is. But since we already have 10.0 profiles in-tree, just run with them, as it's more work to worry about changing them now, than it's worth. (And, I might add, I'm glad they're in, as the /last/ thing we need is to be stalemated debating it for a year or two, as it /is/ bikeshedding.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] 2009.0 profiles
> On Sat, 29 Aug 2009, Alex Alexander wrote: > On Sat, Aug 29, 2009 at 00:23, Mike Frysinger wrote: >> we already have a simple logical version system. 2009.0 is the >> next step. > Years do not make a good versioning scheme, if one release gets out > late you're automatically considered outdated by users. You don't make it less outdated by obscuring the version system. Ulrich
Re: [gentoo-dev] Re: Proposal for flag-o-matic.eclass (append-ldflags)
On 28-08-2009 16:08:59 -0400, Mike Frysinger wrote:
> > As such, we will leave
> > it local to Gentoo Prefix until we can come up with a better idea.
>
> stick it behind userland_GNU ? i dont mind extending append-ldflags
> in such a way, but the "pro" you listed originally (protect users from
> typos in ebuilds) isnt a pro in my book -- it should fail.
basically we would need something like "linker_GNU", since all Prefix
arches have userland_GNU set to true
at some point we did stuff like grepping for GNU in ld -v output, but
that's expensive, and it makes probably more sense to do some CHOST
matches with known configurations then, handling the obvious cases
(--{no-,}as-needed etc.)
> i.e. something like:
> append-ldflags() {
> use userland_GNU || set -- $(test-flag-LD "$@")
> ..
> }
thanks
--
Fabian Groffen
Gentoo on a different level
