Re: [gentoo-dev] Off with your heads!

[Stuart Herbert]

On 7/7/06, Steve Dibb <[EMAIL PROTECTED]> wrote:

If your blog is being aggregated on Planet Gentoo / Universe, it's time to send
us a copy of your smiling face.  I'm putting out a request for some
hackergotchis.  Really, you don't want just a few of us to have all the fun, do 
you?


Any chance of you updating the template so that the heads don't look
quite so naff?  They're a bit of an afterthought atm, and it shows.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Off with your heads!

[Sebastian Bergmann]

Stuart Herbert wrote:
> Any chance of you updating the template so that the heads don't look
> quite so naff?  They're a bit of an afterthought atm, and it shows.

 I agree, http://planet.gnome.org/ looks so much nicer ;-)

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] init.d problem

[Martin Schlemmer]

On Thu, 2006-07-06 at 18:18 -0400, Mike Frysinger wrote:
> On Thursday 06 July 2006 15:27, Albert Hopkins wrote:
> > On Tue, 2006-07-04 at 18:58 -0400, Mike Frysinger wrote:
> > > On Tuesday 04 July 2006 18:43, Enrico Weigelt wrote:
> > > > We should think about mechanisms to check if the service is
> > > > actually running. This could also be used for frequently service
> > > > checks and notification.
> > >
> > > there is no fool proof way to do this
> >
> > Has anyone considered daemontools?  It does this kind of stuff very
> > well.
> 
> you're "fixing" the issue by replacing sysvinit/baselayout with daemontools
> 
> some people may want to do that but really i dont see how that's generally 
> relevant to this discussion

There are wrapper scripts if you want to use daemontools with
rc-scripts:

  sys-process/daemontools-scripts


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Curtis Napier wrote:
> I could find a million threads in the forums supporting what Ciaran is
> saying here. We have been told over and over and over until my head
> feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT
> IS WHAT USE FLAGS ARE FOR
> 
> Every developer who has ever commented on one of these threads has
> always agreed with that. Put it in USE not CLFAGS.

That's because CFLAGS="-msse" currently doesn't do what the user would think it
does. Which is the real problem, which we're solving with the change Diego
suggested.

> To change this behavior now after all this time would be crazy IMHO.

It might have become some sort of policy, but if the policy doesn't have a
god-like status. Sometimes it becomes obsolete and new (better) rules are put in
place.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Luca Barbato wrote:
> Alternatives:
> 
> - as PPC we provide a default cflags & use tuned per certain cpu
> families using profiles, amd64 could provide a nocona profile that bans
> 3dnow* useflags.

Not really. There are athlon64s and opterons with and without sse3 support. The
users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as
they expect the flag to do what it says. The problem is even worse for x86:
You'd have to provide own profiles for:

* i386
* pentium-mmx,k6
* athlon xp,pentium3
* pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting from
'willamette' core)
* celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting from
venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX (starting
from san diego stepping E4), sempron (starting from palermo stepping E3),
pentium4 (starting from 'prescott')
etc...

and now you want to let your pentium4(paris)-server, which is running 24/7,
compile a binpkg for your pentium4(prescott), using SSE3

have fun 8-)

> - as before but provide an eclass that uses flameeyes infrastructure to
> warn about possible mismatch between what the cflags could do and what
> you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning
> and disable it

I'm not sure whether I understand this correctly. If we use flameeyes logic
anyway, why keeping the use flags?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007

[Chris Gianelloni]

On Tue, 2006-07-04 at 19:40 -0400, Curtis Napier wrote:
> Two names I see missing from this (otherwise very good) list are Chris
> Gianelloni (wolf31o2) and Donnie Berkholz (spyderous aka dberkholz). I
> think everyone knows exactly how much work these two put into Gentoo and
> how valuable that contribution is. Their knowledge would be a great
> addition to the council.

I've been thinking about this and still am on the fence.  At least I
have a couple more weeks to think about it, but thanks to everyone who
has nominated me.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

[Lars Weiler]

* Luca Barbato <[EMAIL PROTECTED]> [06/07/07 02:13 +0200]:
> I'd add to the pot pvdabeel and pylon since was and still is a pleasure
> working with them =)

I accept the nomination.  But I can't add more nominees as
all my favorites for the council have been named already ;)

On the other hand, this means, I won't be available as
trustee any more (I don't think, that I have enough time for
both boards).  But as I have not been nominated yet, things
look good...

Regards, Lars

-- 
Lars Weiler  <[EMAIL PROTECTED]>  +49-171-1963258
Gentoo Linux PowerPC: Strategical Lead and Release Engineer
Gentoo Infrastructure   : CVS Administrator
Gentoo Foundation   : Trustee


pgppeazpBLFed.pgp
Description: PGP signature

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Simon Stelling wrote:
> Luca Barbato wrote:
>> Alternatives:
>>
>> - as PPC we provide a default cflags & use tuned per certain cpu
>> families using profiles, amd64 could provide a nocona profile that bans
>> 3dnow* useflags.
> 
> Not really. There are athlon64s and opterons with and without sse3 support. 
> The
> users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as
> they expect the flag to do what it says. The problem is even worse for x86:
> You'd have to provide own profiles for:
> 
> * i386

there is already isn't it?

> * pentium-mmx,k6

people know what they are

> * athlon xp,pentium3

ditto

> * pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting 
> from
> 'willamette' core)

those are relatively new

> * celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting 
> from
> venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX 
> (starting
> from san diego stepping E4), sempron (starting from palermo stepping E3),

Don't complain with me about marketing

> pentium4 (starting from 'prescott')

and so on...

> etc...
> 
> and now you want to let your pentium4(paris)-server, which is running 24/7,
> compile a binpkg for your pentium4(prescott), using SSE3
> 
> have fun 8-)

I take the base profile and turn sse3 useflag on, tune the cflags
properly and then I issue the emerge -B foo as usual

specific profiles are good just for disoriented users that need
something working quickly, people knowing their system and what they
want would be much happy with the useflags.

Having better descriptions for flags could be of help too.

Keep in mind that discover what your cpu or another cpu could take as
cflags or simdflags requires the same (look at the arch faq about it,
parse the cpuinfo, google a bit)

> I'm not sure whether I understand this correctly. If we use flameeyes logic
> anyway, why keeping the use flags?
> 

Because you may not want all the flags the gcc guess would set for a
reason or another (and there are many, including having gcc-X.ugly doing
the worst with -msimd_du_jour but having some nicely tuned routines for
that simd triggered by --enable-simd_du_jour)

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> > | No, we never spent years telling them not to use your so-called
> > | "CFLAGS hacks" that are rather a proper usage of what the compiler
> > | gives you.
> > Wrong. We did.
> Then you were wrong. I could have spent time explaining them when they make 
> sense and why they don't in their usecases. If you did, well, then you really 
> need to know better what you do because you seem to me pretty confused 
> yourself, and I feel pity for you.
> 

Yes, we did.  Were we wrong?  Out of a purest point of view ... maybe.
The problem was though that earlier gcc's was very bad at generating
sse/sse2, and sometimes mmx code.

Users being what they are though (ricers should say it all), they
enabled every flag that sounded like it could make their old box two
times faster.  This included -msse, -msse2, etc.  Which quite frankly
produced bad code in many cases.  So we told the users to not add any
-m* flags, and let gcc do its job with the proper -march.

So yeah, I can see that general use flags for cpu features might become
more tedious with the many new modules of processors out there, but to
say handle it by adding -msse, etc to CFLAGS, will surely if not on
gcc4, but then on gcc3 systems just ask for trouble.

And yes, I know you are saying that that is not exactly what you are
proposing, but the users will see it as a clear passport to stick all
those nice sounding flags just right back in, and then it will be too
late to tell them its not proper thing to do when the bugs start
flooding in.

Anyway, I tried to give some history and some what ifs, but as I
admitted many times in the past, I am no great writer.  You had to be
'there' I guess, *shrug*.


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Brian Harring]

On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
> On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> > > | No, we never spent years telling them not to use your so-called
> > > | "CFLAGS hacks" that are rather a proper usage of what the compiler
> > > | gives you.
> > > Wrong. We did.
> > Then you were wrong. I could have spent time explaining them when they make 
> > sense and why they don't in their usecases. If you did, well, then you 
> > really 
> > need to know better what you do because you seem to me pretty confused 
> > yourself, and I feel pity for you.
> > 
> 
> Yes, we did.  Were we wrong?  Out of a purest point of view ... maybe.
> The problem was though that earlier gcc's was very bad at generating
> sse/sse2, and sometimes mmx code.
> 
> Users being what they are though (ricers should say it all), they
> enabled every flag that sounded like it could make their old box two
> times faster.  This included -msse, -msse2, etc.  Which quite frankly
> produced bad code in many cases.  So we told the users to not add any
> -m* flags, and let gcc do its job with the proper -march.
> 
> So yeah, I can see that general use flags for cpu features might become
> more tedious with the many new modules of processors out there, but to
> say handle it by adding -msse, etc to CFLAGS, will surely if not on
> gcc4, but then on gcc3 systems just ask for trouble.
> 
> And yes, I know you are saying that that is not exactly what you are
> proposing, but the users will see it as a clear passport to stick all
> those nice sounding flags just right back in, and then it will be too
> late to tell them its not proper thing to do when the bugs start
> flooding in.

Dumb question, but what really blocks them from doing that now for 
x86 (for example)?

Yes, can't enable certain flags for non x86/x86_64 arches, but the con 
you're pointing at exists now for the most part.

~harring


pgpYOnT8LDWmY.pgp
Description: PGP signature

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

On Fri, 2006-07-07 at 04:28 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 03:15, Mike Frysinger wrote:
> > > x86_64 toolchain accepting 3dnow on a nocona arch? :)
> > that isnt a cross-compile nor a different architecture
> This is the whole point of my solution.
> 

From what you discussed above, it sounds more like a problem due to
short-sightedness on the amd64 team's part (no offence to amd64 team,
just stating things as I see them) because they just enabled 3dnow for
stuff that worked regardless.

Stupid question though ... does the gcc test thingy list __3dNOW__ on
nocona ?  I would think that it does, as there is no -march=nocona (or
whatever) yet.

So now you want to instead of fixing the amd64 profiles to be more
flexible, implement something that will give the green light to users on
x86 to use flag combinations, especially on older gcc's that causes
great pain for themselfs and developers ?

Sure, nocona should have had CFLAGS="-march=k8 -mno-3dnow", but it would
never have been an issue if the '3dnow' USE flag worked as expected on
amd64 ;)

Anyhow, just ranting - I understand the reasoning for doing it that way,
but you should also see it from the x86 side where -msse could really
mean a broken system, and maybe rethink your solution.


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote:
> On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
> > On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> > > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> > > > | No, we never spent years telling them not to use your so-called
> > > > | "CFLAGS hacks" that are rather a proper usage of what the compiler
> > > > | gives you.
> > > > Wrong. We did.
> > > Then you were wrong. I could have spent time explaining them when they 
> > > make 
> > > sense and why they don't in their usecases. If you did, well, then you 
> > > really 
> > > need to know better what you do because you seem to me pretty confused 
> > > yourself, and I feel pity for you.
> > > 
> > 
> > Yes, we did.  Were we wrong?  Out of a purest point of view ... maybe.
> > The problem was though that earlier gcc's was very bad at generating
> > sse/sse2, and sometimes mmx code.
> > 
> > Users being what they are though (ricers should say it all), they
> > enabled every flag that sounded like it could make their old box two
> > times faster.  This included -msse, -msse2, etc.  Which quite frankly
> > produced bad code in many cases.  So we told the users to not add any
> > -m* flags, and let gcc do its job with the proper -march.
> > 
> > So yeah, I can see that general use flags for cpu features might become
> > more tedious with the many new modules of processors out there, but to
> > say handle it by adding -msse, etc to CFLAGS, will surely if not on
> > gcc4, but then on gcc3 systems just ask for trouble.
> > 
> > And yes, I know you are saying that that is not exactly what you are
> > proposing, but the users will see it as a clear passport to stick all
> > those nice sounding flags just right back in, and then it will be too
> > late to tell them its not proper thing to do when the bugs start
> > flooding in.
> 
> Dumb question, but what really blocks them from doing that now for 
> x86 (for example)?
> 
> Yes, can't enable certain flags for non x86/x86_64 arches, but the con 
> you're pointing at exists now for the most part.
> 

I thought it was obvious, but apparently I overrated my writing
skills :/

Anyhow, because now we can say 'don't do that!', or just close the bug
as INVALID.  If not, you can still try it, but the user might say we
told him to enable sse/whatever like that.

Also, as Luca stated, USE=mmx/sse/sse2/etc means that you enable
tailored mmx/sse/whatever code, that should be working fine, as it was
not gcc doing some shot in the dark at optimising, where if its
enveloped with the CFLAGS, you cannot disable broken gcc optimisations,
but enabled mmx/sse/whatever that should work on those older gcc's.


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Graham Murray]

Martin Schlemmer <[EMAIL PROTECTED]> writes:

> Stupid question though ... does the gcc test thingy list __3dNOW__ on
> nocona ?  I would think that it does, as there is no -march=nocona (or
> whatever) yet.

There is an -march=nocona (which I think was introduced in gcc 3.4)
which works for both 32bit (x86) and 64bit (amd64) systems. At least
on x86 it does NOT define __3dNOW__. Also, for x86 -march=prescott
defines __SSE3__ whereas -march=pentium4 does not.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Martin Schlemmer wrote:
> Stupid question though ... does the gcc test thingy list __3dNOW__ on
> nocona ?  I would think that it does, as there is no -march=nocona (or
> whatever) yet.

There is a -march=nocona, and it doesn't define __3dNOW__.

> So now you want to instead of fixing the amd64 profiles to be more
> flexible, implement something that will give the green light to users on
> x86 to use flag combinations, especially on older gcc's that causes
> great pain for themselfs and developers ?

I don't understand this. Why is '-march=i686 -m3dnow' bad if it results in the
same thing as '-march=athlon-xp'? I guess I'm just lacking facts here, so please
give me a hint :)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Chris Gianelloni]

On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote:
> The more I think about the issue and the more I like the complete
> profiles for amd64 more than the other solutions.

I don't even *want* to think of what this would be for x86.

These are what I can think of, so far, with regards to different support
on different chips.

x86 (everything)
i586 (everything i586-compatible)
i586 + mmx (pentium-mmx)
i686 (everything i686-compatible)
i686 + mmx (pentium2+, athlon+)
i686 + mmx + sse (pentium3+, athlon-xp+)
i686 + mmx + sse + sse2 (pentium4+, athlon64+, opteron+)
i686 + mmx + see + sse2 + sse3 (some pentium4, some athlon64, some
opteron)
i686 + mmx + 3dnow (athlon+)
i686 + mmx + 3dnow + sse (athlon-xp+)
i686 + mmx + 3dnow + sse + sse2 (athlon64+, opteron+)
i686 + mmx + 3dnow + sse + sse2 + sse3 (some athlon64, some opteron)

Now, some of those aren't able to be turned on solely via -march.

I'm not arguing for or against this, since I haven't bothered to read
the entire thread at the moment.  I just wanted to point out that we
would likely end up with 12 sub-profiles for all of our profiles to
accomplish this.  Even if we only started this going forward, x86 has a
few profiles considered "supported" by Release Engineering that would
need adjustment...

x86/2006.1/desktop
x86/no-nptl
x86/no-nptl/2.4

This means it is now 36 profiles to support, if we dropped support on
all profiles except for the new ones.  Without having any sort of
multiple inheritance available, this is really unmanageable.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Doty]

Chris Gianelloni wrote:
[snip]


This means it is now 36 profiles to support, if we dropped support on
all profiles except for the new ones.  Without having any sort of
multiple inheritance available, this is really unmanageable.



This is exactly the same reason why amd64 won't move to a per CPU 
subprofile.  it might be a good idea for ppc, but not for us.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefan Schweizer wrote:
> Mike Frysinger wrote:
>>  - only Gentoo devs may be nominated
> 
> with that limitation in mind I want to propose some developers that are
> doing a lot of work to improve gentoo:
> antarus for his treecleaners work

I appreciate the nomination (it made me giggle) but I am far too
retarded and underqualified as of yet ;)

> 
> Thanks,
> Stefan
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRK5koGzglR5RwbyYAQKESQ/+MDjqTWfHKk7ljkS+KVoCgvI15OZVo+5R
gH8whgcL4/18PLOsnLRT+VJnqjL2CCbQGL9zvd+JQv2trIPwge704T6gP+xaQOeM
fevtDBN2thgbaJ7pub0TOchyS+YbPb0zWUICBYVcfTz0j4Q/YPHqvNmTOD2pOIPR
qT7LmydQ/iuI5PFeHWuhKahGPjfNxBrlEH0qhVLfxVH+zsAk9iUMMAMxHe4ugNfk
gVhHgxuH8/U7TXfiGvXoxDLPtffvFM4QbOaYCtHN6Vd6zAldupgdkONgEew5uKz+
k41lh1CRr11pc/hk5X3t+7T+9CM+ptitDbC+/LoavY4g2NKTBT9Le5JfACeuSc7W
hCTlIkGMZYCux+qtuF5aeQBvSZREZnXoQ1ppzFOQsRJSvnzwyHHI74ZaUdRiB/K1
JIsnY5ZMD7cqWnbuJXZ0c1N52uK2vO2oR1pox/pR9qVwQL+2EPEWrsO/L2kpakm0
wznpoPwEHJ7vrxozFjOctE2D1MmjXzlyMEoz5vboQgIjPGCiPoOLJeaPd5wQe4Fl
9UFpPvRoF6OGiEiwPSv2Bxhd+dGkLv+9LqdtbU49xXNwUE6rMNWBHdGO5MN/P/OM
oUcEYmNXEABzvgZ+IfqTlC5Zl/PLZ3+DyV9ils83s6Z5ROow0nXD94exlnY3nhxc
ZU70aIMQAg0=
=XTuy
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Marius Mauch]

On Fri, 07 Jul 2006 13:13:09 +0200
Simon Stelling <[EMAIL PROTECTED]> wrote:

> Curtis Napier wrote:
> > I could find a million threads in the forums supporting what Ciaran
> > is saying here. We have been told over and over and over until my
> > head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN
> > CFLAGS!! THAT IS WHAT USE FLAGS ARE FOR
> > 
> > Every developer who has ever commented on one of these threads has
> > always agreed with that. Put it in USE not CLFAGS.
> 
> That's because CFLAGS="-msse" currently doesn't do what the user
> would think it does. Which is the real problem, which we're solving
> with the change Diego suggested.

Huh? What do you assume users think that CFLAGS=-msse does?
I know some people get confused by the mmx/sse/whatever use flags, but
I've never seen anybody assuming that CFLAGS determine if a patch
should be applied/configure switch enabled.
(I'm not arguing about the proposal itself here, just this argument is
bullshit)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Kevin F. Quinn]

On Fri, 7 Jul 2006 07:46:16 +0200
Harald van Dijk <[EMAIL PROTECTED]> wrote:

> On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > a supported compiler in Gentoo.
> > 
> > you're just griping because i forced ssp/pie regardless of
> > USE=vanilla ... 
> 
> I didn't mind that you applied ssp/pie patches regardless of
> USE=vanilla, I did mind that you applied the stub patches with
> USE="nossp vanilla", and I also didn't like that this was either done
> accidentally but ignored when pointed out, or that this was done
> deliberately with a misleading cvs log message.

If you take out the stub patches (which incidentally have no impact on
code generation), many builds will simply fail because they expect the
additional flags from ssp, htb etc to be there.

Since they have no impact on code generation, their presence doesn't
impact comparisons with a pure upstream release.

> > since gcc-4.0 and below are on the way out, i have no problem
> > changing this behavior
> > 
> > besides, since both of these technologies are in mainline gcc now,
> > i really dont see how you can continue to gripe with gcc-4.1.1+
> 
> I don't know how much gcc-spec-env.patch can be trusted, and even if
> it is 100% safe, such patches don't belong in anything that would be
> called "vanilla". (I have commented on that patch long before this
> thread started, so don't think I'm just looking for something to
> complain about now.)

Again, if you don't gave GCC_SPECS defined in your environment then
that patch makes no difference to code generation.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

On Fri, 2006-07-07 at 15:21 +0200, Simon Stelling wrote:
> Martin Schlemmer wrote:
> > Stupid question though ... does the gcc test thingy list __3dNOW__ on
> > nocona ?  I would think that it does, as there is no -march=nocona (or
> > whatever) yet.
> 
> There is a -march=nocona, and it doesn't define __3dNOW__.
> 

Missed that, sorry.

> > So now you want to instead of fixing the amd64 profiles to be more
> > flexible, implement something that will give the green light to users on
> > x86 to use flag combinations, especially on older gcc's that causes
> > great pain for themselfs and developers ?
> 
> I don't understand this. Why is '-march=i686 -m3dnow' bad if it results in the
> same thing as '-march=athlon-xp'? I guess I'm just lacking facts here, so 
> please
> give me a hint :)
> 

Check Chris Gianelloni's mail just now.  For some compilers with some
-march's on x86 it did not explicitly turn on some features (or maybe
not to such a high extend).  So where say CFLAGS="-march=pentium3" would
work, CFLAGS="-march=pentium3 -msse" would fail to build, or generate
bad code (segfaulting binaries).


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Marius Mauch wrote:
>> That's because CFLAGS="-msse" currently doesn't do what the user
>> would think it does. Which is the real problem, which we're solving
>> with the change Diego suggested.
> 
> Huh? What do you assume users think that CFLAGS=-msse does?
> I know some people get confused by the mmx/sse/whatever use flags, but
> I've never seen anybody assuming that CFLAGS determine if a patch
> should be applied/configure switch enabled.
> (I'm not arguing about the proposal itself here, just this argument is
> bullshit)

Well, that was the best argument I could think of. I wasn't aware of the
breakage in old compilers like 

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

On Friday 07 July 2006 15:53, Martin Schlemmer wrote:
> Check Chris Gianelloni's mail just now.  For some compilers with some
> -march's on x86 it did not explicitly turn on some features (or maybe
> not to such a high extend).
Uh no, I think he meant that for some borderline processors there's not 
a -march value, like for Athlon64 Revision D, that has sse3 support. In those 
cases you have to use -msse3 or whatever else to tell the compiler what to 
generate.

> So where say CFLAGS="-march=pentium3" would 
> work, CFLAGS="-march=pentium3 -msse" would fail to build, or generate
> bad code (segfaulting binaries).
This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 
and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt.

What you might incorrectly remember is -mfpmath=sse that is totally another 
thing, and dies usually on bad code anyway, and it's enabled by default on 
64-bit CPUs just because on there the 80-bit limit for doubles is not 
pertinent anymore.

I might seem an idiot, but I have enough experience to know what I'm talking 
about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse 
with -mfpmath=sse (or simply remember just what happened with GCC 3.2).

A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were 
almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 
series improved, drastically.
Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You 
cannot think that a flag or a support will always be broken because a release 
had it broken, you have to watch what you're doing to do it correctly.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpLOzIWZ4SFL.pgp
Description: PGP signature

[gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Danny van Dyk]

OK, this rfc/proposal is competing with Flameeye's proposal:

I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
This should be set to sane defaults in the profiles. I.e. for x86,
it should not set CPUFLAGS at all, and on AMD64 it should be
  CPUFLAGS="mmx sse sse2"

I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty,
and ppc/ppc64 should set
  CPUFLAGS="altivec".


The main reasons for a USE-like implementation om contrast to Diego's 
proposal are:

a) There is no call to gcc involved, but only a call to use(). This
   allows usage in metadata phase.
b) There is no implicit (non-transparent) choice made for the users.
c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo)
   with the purpose of optional codepaths.

I know, there aren't use-based deps in portage yet, but I really feel
uncomfortable to be unable to use cpuflags in metadata phase. This is 
what worries me most.

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Diego 'Flameeyes' Pettenò]

On Friday 07 July 2006 16:20, Danny van Dyk wrote:
> I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
Improvement respect the current situation? You're just asking for the same 
exact treatment that is in place now, but changing its name like it is a 
change...

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgp4qiuLrXRKA.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Luca Barbato]

Danny van Dyk wrote:
> OK, this rfc/proposal is competing with Flameeye's proposal:
> 
> I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.

Name it SIMD or CPUFEAT to avoid misunderstanding with the other *FLAGS

> This should be set to sane defaults in the profiles. I.e. for x86,
> it should not set CPUFLAGS at all, and on AMD64 it should be
>   CPUFLAGS="mmx sse sse2"
> 
> I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty,
> and ppc/ppc64 should set
>   CPUFLAGS="altivec".

No

ppc/* should have it empty as default and the G4 and G5 profile should
have it set.

beside that looks ok

lu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Danny van Dyk]

Am Freitag, 7. Juli 2006 16:19 schrieb Diego 'Flameeyes' Pettenò:
> On Friday 07 July 2006 16:20, Danny van Dyk wrote:
> > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
>
> Improvement respect the current situation? You're just asking for the
> same exact treatment that is in place now, but changing its name like
> it is a change...

USE_EXPAND useflags do not need to be added to either use.desc nor 
use.local.desc. Further, we keep track of other hardware-related 
metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Luca Barbato]

Danny van Dyk wrote:
> 
> USE_EXPAND useflags do not need to be added to either use.desc nor 
> use.local.desc.

One point was adding better description about them to avoid misuse.

 Further, we keep track of other hardware-related
> metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.
> 
> Danny

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Diego 'Flameeyes' Pettenò]

On Friday 07 July 2006 16:40, Danny van Dyk wrote:
> USE_EXPAND useflags do not need to be added to either use.desc nor
> use.local.desc.
You need to put them in misc/.desc

> Further, we keep track of other hardware-related 
> metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.
Quite a different thing to me, considering the wide quantity of them.
But for an handful of useflag it would be a bit of overkill.

Yes also KERNEL, ELIBC, USERLAND are handled as use-expand, but that's just an 
hack-that-works.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpwqqDMNZdVq.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Stephen P. Becker]

Diego 'Flameeyes' Pettenò wrote:
Further, we keep track of other hardware-related 
metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.

Quite a different thing to me, considering the wide quantity of them.
But for an handful of useflag it would be a bit of overkill.


Perhaps you are thinking too narrowly here.  Consider that this 
USE_EXPAND could potentially be used to enable cpu specific flags over 
more arches than just 32/64-bit x86.  It seems clear that ppc and sparc 
could already benefit, and I can think of at least one situation on mips 
where it would be useful.


Any other arch teams care to comment?  How many different types of CPUs 
would it take to become a "wide quantity" in your eyes?


-Steve
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Diego 'Flameeyes' Pettenò]

On Friday 07 July 2006 16:53, Stephen P. Becker wrote:
> Perhaps you are thinking too narrowly here.  Consider that this
> USE_EXPAND could potentially be used to enable cpu specific flags over
> more arches than just 32/64-bit x86.  It seems clear that ppc and sparc
> could already benefit, and I can think of at least one situation on mips
> where it would be useful.
So the question is: why they aren't useflags in the first place? There has to 
be a reason, or it would just be that up to now we did the same thing in 
different ways just because of it.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgp6Xq9wGP5Fk.pgp
Description: PGP signature

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

On Fri, 2006-07-07 at 16:03 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 15:53, Martin Schlemmer wrote:
> > Check Chris Gianelloni's mail just now.  For some compilers with some
> > -march's on x86 it did not explicitly turn on some features (or maybe
> > not to such a high extend).
> Uh no, I think he meant that for some borderline processors there's not 
> a -march value, like for Athlon64 Revision D, that has sse3 support. In those 
> cases you have to use -msse3 or whatever else to tell the compiler what to 
> generate.
> 
> > So where say CFLAGS="-march=pentium3" would 
> > work, CFLAGS="-march=pentium3 -msse" would fail to build, or generate
> > bad code (segfaulting binaries).
> This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 
> and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt.
> 
> What you might incorrectly remember is -mfpmath=sse that is totally another 
> thing, and dies usually on bad code anyway, and it's enabled by default on 
> 64-bit CPUs just because on there the 80-bit limit for doubles is not 
> pertinent anymore.
> 

As I pointed out on irc (to clarify), its still an issue even with
gcc-3.4.6.  Its just well enough filtered, and as Mike pointed out, they
'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
4.0.1 I think.

> I might seem an idiot, but I have enough experience to know what I'm talking 
> about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse 
> with -mfpmath=sse (or simply remember just what happened with GCC 3.2).
> 

I did not imply this as far I know, and if it seemed that way, I can
only say that I assumed that newer guys had the advantage of most
ebuilds filtering or -mno-sse/whatever for known broken stuff (I know
xorg was one with a few workarounds, also mozilla, etc at at some
stage), so would not have noticed if sse/whatever broke something.
That, and not being on the toolchain list you might not be familiar with
the extend of the issue, with the fact that its different issues with
different versions depending besides that on if its a i586, k6, p2, p3
or p4, etc.

> A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were 
> almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 
> series improved, drastically.
> Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You 
> cannot think that a flag or a support will always be broken because a release 
> had it broken, you have to watch what you're doing to do it correctly.
> 

I'd say only 4.0.1 and upwards really solved most of those issues,
especially the long comming sse one.


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Kevin F. Quinn]

On Fri, 7 Jul 2006 16:20:08 +0200
Danny van Dyk <[EMAIL PROTECTED]> wrote:

> OK, this rfc/proposal is competing with Flameeye's proposal:
> 
> I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.

I don't like the name - I'd prefer something like CPU_SUBMODEL or
CPU_FEATURES or perhaps ARCH_FEATURES.  I agree with Diego, I don't see
this gets us anything we don't already have - it becomes just a USE
flag list tidy-up (c.f. INPUT_DEVICES et. al.).

> This should be set to sane defaults in the profiles. I.e. for x86,
> it should not set CPUFLAGS at all, and on AMD64 it should be
>   CPUFLAGS="mmx sse sse2"
> 
> I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty,
> and ppc/ppc64 should set
>   CPUFLAGS="altivec".

It would be nice to be able to specify the sub-model using the gcc arch
name, as well as by just listing the various features supported.  It
would be even tidier if by default it would expand to the
common-denominator features supported by any -march setting in CFLAGS.

I'm thinking that from a user's perspective, they could:

a) set -march= in CFLAGS, and the CPU_SUBMODEL would be
determined automatically

b) set CPU_SUBMODEL to an arch, for brevity; e.g.
CPU_SUBMODEL="athlon-xp"

c) set CPU_SUBMODEL to a set of features; e.g. CPU_MODEL="mmx sse sse2"

d) set CPU_SUBMODEL to a combination of the two; e.g.
CPU_MODEL="athlon-xp sse3"

e) not bother setting CPU_SUBMODEL at all, letting portage work out a
sensible set

To do this means more than just a USE_EXPAND, however.  Obviously
portage is not a good place to store information about what submodels
support which features; this could be done via a file in the profiles;
e.g. profile.submodels:

athlon mmx 3dnow 3dnow_a
athlon-xp mmx sse 3dnow 3dnow_a
nocona mmx sse sse2 sse3
pentium
pentium-mmx mmx
pentium-m mmx sse sse2

and so on.

> The main reasons for a USE-like implementation om contrast to Diego's 
> proposal are:
> 
> a) There is no call to gcc involved, but only a call to use(). This
>allows usage in metadata phase.
> b) There is no implicit (non-transparent) choice made for the users.
> c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo)
>with the purpose of optional codepaths.
> 
> I know, there aren't use-based deps in portage yet, but I really feel
> uncomfortable to be unable to use cpuflags in metadata phase. This is 
> what worries me most.

The only thing my CPU_SUBMODEL conflicts with here is (b), in that the
submodel features appropriate to the CFLAGS -march setting are
automatically set.

A downside is that there is still redundancy between CFLAGS and
CPU_SUBMODEL; e.g. an sse3-enabled athlon user would set

CFLAGS="-march=k8 -msse3"
CPU_SUBMODEL="k8 sse3"

(for a k8 processor that also has sse3) which seems a little daft.  It
does highlight that we're controlling two things, however; one being
what type of code is generated by gcc (CFLAGS) and the other being the
configure enable/disable bits (CPU_SUBMODEL).

Diego's proposal essentially generates CPU_SUBMODEL automatically from
CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not
set.  That way we have the best of both worlds; people who are happy to
let the system determine the configure options from the compiler
architecture can do so, those who want to control things in more detail
can do that as well.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Pierre Guinoiseau writes:

pam-login is now included in shadow, you no longer need to emerge it.


Thanks, that's what I needed to know.
I had done an emerge -D world, and suddenly I couldn't "turn on the
PC".  I later found out that /sbin/login had been removed.

Richard Fish writes:

USE="mono" emerge -Devp evolution

No mozilla comes in.
So evolution does not depend on mozilla, at least not directly.


Ok.  Same picture here.  (Above command pulls in 402 other packages
though... caramba)


In fact, in the current portage tree, mozilla is going away, and
being replaced by seamonkey.  Very few (and hard masked) packages
like gecko-sdk still depend on mozilla.  So what you should
eventually end up with is no mozilla but seamonkey.


Thanks for the info!


Are you using an portage overlay?  If so, what is in it?


No.  No idea what that is.  Sounds interesting, though.


When was the last time you did an emerge --sync?


Yesterday.  It changed things a bit since last time (month ago?), but
it still wants to merge mozilla.  Only now it's mono-tools (or rather
gecko-sharp) that wants it, Evolution is out of the picture:

[nomerge  ] dev-util/mono-tools-1.1.11
[ebuild  N]  dev-dotnet/gecko-sharp-0.6
[nomerge  ]   www-client/mozilla-1.7.13


Also, the full output of "emerge -Duvpt world"


Attached.

Note that I got rid of the Xorg-6.9 blockers by merging virtual/xft-7.0.
Doesn't make any sense to me at all, explanations sought for :-).

These are the packages that would be merged, in reverse order:

Calculating world dependencies  . . 
!!! Packages for the following atoms are either all
!!! masked or don't exist:
media-tv/atitvout

... done!
[blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
[blocks B ] www-client/mozilla (is blocking www-client/seamonkey-1.0.2)
[ebuild U ] kde-base/kwalletmanager-3.5.3 [3.5.2] USE="xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility%" 2,910 kB 
[ebuild U ] sys-fs/device-mapper-1.02.07 [1.02.02] 902 kB 
[ebuild U ] kde-base/kdebase-meta-3.5.3 [3.5.2] 0 kB 
[ebuild U ]  kde-base/konsole-3.5.3-r1 [3.5.2-r1] USE="xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility%" 6 kB 
[ebuild U ]  kde-base/ksysguard-3.5.3-r1 [3.5.2-r2] USE="xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% -lm_sensors -zeroconf" 0 kB 
[ebuild U ]  kde-base/knetattach-3.5.3 [3.5.1] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kdeprint-3.5.3 [3.5.2] USE="cups kde xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]   kde-base/kghostview-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 7,129 kB 
[ebuild U ]  kde-base/ktip-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kate-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kscreensaver-3.5.3 [3.5.1] USE="opengl xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kmenuedit-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kpager-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/drkonqi-3.5.3-r1 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kappfinder-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]  kde-base/kxkb-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 5 kB 
[ebuild U ]  kde-base/klipper-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[nomerge  ] app-cdr/k3b-0.12.14  USE="alsa encode ffmpeg flac kde mp3 
sndfile* vorbis xinerama -arts* -css -debug -dvdr -hal -musepack -musicbrainz 
-vcd" 
[ebuild U ]  app-cdr/cdrdao-1.2.1-r1 [1.2.1] USE="encode gnome -debug 
-pccts" 0 kB 
[nomerge  ]   dev-cpp/gtkmm-2.8.1  USE="-debug" 
[ebuild U ]dev-cpp/glibmm-2.8.4 [2.8.1] USE="doc* -debug" 1,977 kB 
[ebuild U ] kde-base/konq-plugins-3.5.3 [3.5.2-r1] USE="xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility%" 1,607 kB 
[ebuild U ]  kde-base/konqueror-3.5.3 [3.5.2] USE="java xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ]   kde-base/kfind-3.5.3 [3.5.2] USE="xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild U ] dev-libs/openobex-1.2-r1 [1.0.1] USE="bluetooth% -debug% -irda% 
-syslog% -usb%" 333 kB 
[nomerge  ] media-video/konverter-0.92_beta1  USE="xinerama -arts* -debug" 
[ebuild U ]  media-libs/xine-lib-1.1.2_pre20060328-r9 
[1.1.2_pre20060328-r1] USE="X aac alsa asf directfb esd* fbcon ffmpeg flac 
gnome ipv6 mad opengl oss sdl theora vorbis win32codecs xinerama 

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Chris Gianelloni]

On Fri, 2006-07-07 at 16:59 +0200, Diego 'Flameeyes' Pettenò wrote:
> So the question is: why they aren't useflags in the first place? There has to 
> be a reason, or it would just be that up to now we did the same thing in 
> different ways just because of it.

Most likely.

Have you ever looked at the profiles, even the default-linux profiles
for a given release?  They're all over the place, doing things
differently in lots of ways.  Something that I have been working on
since taking over Release Engineering is trying to make things closer to
being the same.  We all know that there will never be a way to have
things identical, but we're working to make them as similar as possible.
However, I can tell you that there are definitely *tons* of examples of
things being done all kinds of crazy ways by different teams.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ned Ludd]

Quite honestly I see this as providing no advantage what so ever over
the current USE="mmx blah foo" that we already have..

Please explain to me what I'm missing here..
How does this help us?


On Fri, 2006-07-07 at 16:20 +0200, Danny van Dyk wrote:
> OK, this rfc/proposal is competing with Flameeye's proposal:
> 
> I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
> This should be set to sane defaults in the profiles. I.e. for x86,
> it should not set CPUFLAGS at all, and on AMD64 it should be
>   CPUFLAGS="mmx sse sse2"
> 
> I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty,
> and ppc/ppc64 should set
>   CPUFLAGS="altivec".
> 
> 
> The main reasons for a USE-like implementation om contrast to Diego's 
> proposal are:
> 
> a) There is no call to gcc involved, but only a call to use(). This
>allows usage in metadata phase.
> b) There is no implicit (non-transparent) choice made for the users.
> c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo)
>with the purpose of optional codepaths.
> 
> I know, there aren't use-based deps in portage yet, but I really feel
> uncomfortable to be unable to use cpuflags in metadata phase. This is 
> what worries me most.
> 
> Danny
> -- 
> Danny van Dyk <[EMAIL PROTECTED]>
> Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Martin Schlemmer]

On Fri, 2006-07-07 at 17:46 +0200, Kevin F. Quinn wrote:
> On Fri, 7 Jul 2006 16:20:08 +0200
> Danny van Dyk <[EMAIL PROTECTED]> wrote:

> Diego's proposal essentially generates CPU_SUBMODEL automatically from
> CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not
> set.  That way we have the best of both worlds; people who are happy to
> let the system determine the configure options from the compiler
> architecture can do so, those who want to control things in more detail
> can do that as well.
> 

I snipped your proposal, which I will reread better later on, but sounds
not too bad if the glimpse was true.

The big issue with Diego's proposal though that most of us for x86 have
issues, is that you tie configure time optimisations that in theory
should be good with most compilers, with gcc's potshots that may or may
not be good.  Sure, you might get away with it these days, because
either bad stuff are filtered, or patched away, but it really is
essentially not the same thing.

I might for example with gcc-4.1.1 rather want gcc to do all
optimization, as it does a better job than the coders do, but with 3.4.6
gcc that sucks at sse2 (ok, apparently this should be fixed with patches
Mike backported, but still), I want what the developer coded mmx/sse
code.

The other side of it as well, is for new cpu's you might have to disable
custom configure enabled mmx/sse/etc in general, as they break with the
code (think when p4 was released).

Sure, maybe adding auto detecting for USE="mmx sse sse2 etc" if they are
not -mmx/-sse/etc can be a cool feature, but that is totally different.

Hopefully that was clear - if not, point out what I should try to
elaborate on.


-- 
Martin Schlemmer



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] CPU subprofiles (was: Replacing cpu-feature USE flags)

[Ciaran McCreesh]

On Fri, 07 Jul 2006 08:36:32 -0500 Mike Doty <[EMAIL PROTECTED]>
wrote:
| Chris Gianelloni wrote:
| [snip]
| > This means it is now 36 profiles to support, if we dropped support
| > on all profiles except for the new ones.  Without having any sort of
| > multiple inheritance available, this is really unmanageable.
| 
| This is exactly the same reason why amd64 won't move to a per CPU 
| subprofile.  it might be a good idea for ppc, but not for us.

I believe all discussion on CPU subprofiles has started with "if we had
multiple profile support then". Would the situation be any different if
it were just a case of telling Portage to use
base/default-linux/x86/2008.1 + extras/x86/cpu/pentium4?

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <[EMAIL PROTECTED]>
wrote:
| I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
| This should be set to sane defaults in the profiles. I.e. for x86,
| it should not set CPUFLAGS at all, and on AMD64 it should be
|   CPUFLAGS="mmx sse sse2"

The issue with this is that $feature on amd64 is not exactly the same as
$feature on x86. Would a better name be ${ARCH}_FEATURES or somesuch?
That way there would be no confusion as to whether the cpuflags_sse2 USE
flag did something for x86 or for amd64 or for both, since there'd be
either x86_features_sse2 or amd64_features_sse2 or both. It'd also make
handling use masking much easier.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CPU subprofiles

[Mike Doty]

Ciaran McCreesh wrote:

On Fri, 07 Jul 2006 08:36:32 -0500 Mike Doty <[EMAIL PROTECTED]>
wrote:
| Chris Gianelloni wrote:
| [snip]
| > This means it is now 36 profiles to support, if we dropped support
| > on all profiles except for the new ones.  Without having any sort of
| > multiple inheritance available, this is really unmanageable.
| 
| This is exactly the same reason why amd64 won't move to a per CPU 
| subprofile.  it might be a good idea for ppc, but not for us.


I believe all discussion on CPU subprofiles has started with "if we had
multiple profile support then". Would the situation be any different if
it were just a case of telling Portage to use
base/default-linux/x86/2008.1 + extras/x86/cpu/pentium4?


that would make it feasible, still not convinced it's the right way to go...
--
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
> On Fri, 7 Jul 2006 07:46:16 +0200
> Harald van Dijk <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > > a supported compiler in Gentoo.
> > > 
> > > you're just griping because i forced ssp/pie regardless of
> > > USE=vanilla ... 
> > 
> > I didn't mind that you applied ssp/pie patches regardless of
> > USE=vanilla, I did mind that you applied the stub patches with
> > USE="nossp vanilla", and I also didn't like that this was either done
> > accidentally but ignored when pointed out, or that this was done
> > deliberately with a misleading cvs log message.
> 
> If you take out the stub patches (which incidentally have no impact on
> code generation), many builds will simply fail because they expect the
> additional flags from ssp, htb etc to be there.

That's the point. I mentioned being able to test whether your own
software compiles with a pure GNU toolchain as a desire. Being able to
see whether unofficial compiler options are used is not just a nice
extra, but even necessary for that.

> Since they have no impact on code generation, their presence doesn't
> impact comparisons with a pure upstream release.
> 
> > > since gcc-4.0 and below are on the way out, i have no problem
> > > changing this behavior
> > > 
> > > besides, since both of these technologies are in mainline gcc now,
> > > i really dont see how you can continue to gripe with gcc-4.1.1+
> > 
> > I don't know how much gcc-spec-env.patch can be trusted, and even if
> > it is 100% safe, such patches don't belong in anything that would be
> > called "vanilla". (I have commented on that patch long before this
> > thread started, so don't think I'm just looking for something to
> > complain about now.)
> 
> Again, if you don't gave GCC_SPECS defined in your environment then
> that patch makes no difference to code generation.

Yes, but if GCC_SPECS is defined in the environment, I don't know enough
about it to be sure that it interacts properly with -specs command-line
options. Even if it works perfectly, though, the point remains that it
does not belong in a USE=vanilla build.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

On Friday 07 July 2006 17:31, Martin Schlemmer wrote:
> As I pointed out on irc (to clarify), its still an issue even with
> gcc-3.4.6.  Its just well enough filtered, and as Mike pointed out, they
> 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
> 4.0.1 I think.
For what I know, the last issue was fixed with 3.3/3.4, so this sounds new to 
me.
That said, I think this is up to now the only point that would make me rethink 
over this whole idea. For a pure simple and practical problem.

> I did not imply this as far I know, and if it seemed that way, I can
> only say that I assumed that newer guys had the advantage of most
> ebuilds filtering or -mno-sse/whatever for known broken stuff
Probably, but never assume that gentoo is the first experience for everyone ;) 
I had my own share of GCC problems way before, and I remember how much shit 
GCC 3.2 created, 3.3 compared to it was a different order of magnitude: it 
worked.

> I'd say only 4.0.1 and upwards really solved most of those issues,
> especially the long comming sse one.
Maybe because SSE wasn't that widespread in the past, I remember most issues 
to be related to MMX/3Dnow! extensions mainly, a part a big one with -msse 
that I thought dead with GCC 3.3, but I might be mistaken on that then, and I 
beg you pardon in that case.

Of course there's the usual -mfpmath=sse that do cause problems on 32-bit 
systems (although it's the default on 64-bit).

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpvc4mXWJpWb.pgp
Description: PGP signature

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Richard Fish]

On 7/7/06, Simon Stelling <[EMAIL PROTECTED]> wrote:

That's because CFLAGS="-msse" currently doesn't do what the user would think it
does. Which is the real problem, which we're solving with the change Diego
suggested.


Well I certainly do *not* expect it to run configure with "--enable-sse".

-Richard
--
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ned Ludd]

On Fri, 2006-07-07 at 18:53 +0200, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
> > On Fri, 7 Jul 2006 07:46:16 +0200
> > Harald van Dijk <[EMAIL PROTECTED]> wrote:
> > 
> > > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > > > a supported compiler in Gentoo.
> > > > 
> > > > you're just griping because i forced ssp/pie regardless of
> > > > USE=vanilla ... 
> > > 
> > > I didn't mind that you applied ssp/pie patches regardless of
> > > USE=vanilla, I did mind that you applied the stub patches with
> > > USE="nossp vanilla", and I also didn't like that this was either done
> > > accidentally but ignored when pointed out, or that this was done
> > > deliberately with a misleading cvs log message.
> > 
> > If you take out the stub patches (which incidentally have no impact on
> > code generation), many builds will simply fail because they expect the
> > additional flags from ssp, htb etc to be there.
> 
> That's the point. I mentioned being able to test whether your own
> software compiles with a pure GNU toolchain as a desire. Being able to
> see whether unofficial compiler options are used is not just a nice
> extra, but even necessary for that.
> 
> > Since they have no impact on code generation, their presence doesn't
> > impact comparisons with a pure upstream release.
> > 
> > > > since gcc-4.0 and below are on the way out, i have no problem
> > > > changing this behavior
> > > > 
> > > > besides, since both of these technologies are in mainline gcc now,
> > > > i really dont see how you can continue to gripe with gcc-4.1.1+
> > > 
> > > I don't know how much gcc-spec-env.patch can be trusted, and even if
> > > it is 100% safe, such patches don't belong in anything that would be
> > > called "vanilla". (I have commented on that patch long before this
> > > thread started, so don't think I'm just looking for something to
> > > complain about now.)
> > 
> > Again, if you don't gave GCC_SPECS defined in your environment then
> > that patch makes no difference to code generation.
> 
> Yes, but if GCC_SPECS is defined in the environment, I don't know enough
> about it to be sure that it interacts properly with -specs command-line
> options. Even if it works perfectly, though, the point remains that it
> does not belong in a USE=vanilla build.


Keep pushing this and the only thing you will end up with is the 
vanilla flag being removed all together.. You want a pure 100% 
vanilla(POS) non working toolchain then go download it and 
compile it yourself. You will soon see why things exist the way 
they do..

-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE_EXPAND_HIDDEN: why make.globals?

[Stephen Bennett]

On Thu, 06 Jul 2006 16:27:39 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:

> But anyway, base/make.defaults makes sense for now.

It is done.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Frysinger]

On Friday 07 July 2006 13:22, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 17:31, Martin Schlemmer wrote:
> > As I pointed out on irc (to clarify), its still an issue even with
> > gcc-3.4.6.  Its just well enough filtered, and as Mike pointed out, they
> > 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
> > 4.0.1 I think.
>
> For what I know, the last issue was fixed with 3.3/3.4, so this sounds new
> to me.

i dont think the segfaults applied to the 3.3 branch as the code was new to 
the 3.4 branch

the issues were worked around in 3.4.5 via specs filtering, 3.4.6 included one 
fix and i backported the other, 3.4.4 and older i dont know the status of 
(but i'd be inclined to push people to 3.4.6 anyways and cut 3.4.[0-4])

> That said, I think this is up to now the only point that would make me
> rethink over this whole idea. For a pure simple and practical problem.

doesnt seem like a valid roadblocker to me ... but i see the toolchain as 
something higher up guys shouldnt have to worry/think about; fix the gcc 
bugs, dont work around them in ebuilds
-mike


pgprKNDIDEP0b.pgp
Description: PGP signature

[gentoo-dev] Gentoo activity graphs

[Alin Nastac]

Every now and then someone get sick of Gentoo and suddenly became
prophet, preaching that the end of the distro is near.
I wanted to see how much should we worry about it so I've made a perl
script to find the history of the following characteristics:
 - no. of active developers (active dev := did at least a commit in that
month)
 - no. of commits / month
The data and the perl script used to obtain it are available at 
http://dev.gentoo.org/~mrness/gentoo-activity-2006-06/ .

I am aware those characteristics are quantitative and don't say anything
about the quality of the distribution. However, judging after those
graphs, even the worst basher will recognize that we are far from being
dead.



signature.asc
Description: OpenPGP digital signature

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> Keep pushing this and the only thing you will end up with is the 
> vanilla flag being removed all together..

Is that a threat? If not, is there a reason behind this?

> You want a pure 100% 
> vanilla(POS) non working toolchain then go download it and 
> compile it yourself. You will soon see why things exist the way 
> they do..

If you mean modifying the build system to actually work properly, then I
have no problem with that. USE=vanilla refers to runtime behaviour, not
the build system. (See use.desc.) Specifically, if patches are applied
that make sure GCC compiles, and those patches make sure GCC compiles to
the same program intended by the GCC devs at that release, those patches
are appropriate, IMO. None of the GCC patches I have problems with are
of this nature.

If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
an explanation, because as far as I know, it can work just fine as a
system compiler, and plenty of people, at some times myself included,
use it as one.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo activity graphs

[Ciaran McCreesh]

On Fri, 07 Jul 2006 21:34:49 +0300 Alin Nastac <[EMAIL PROTECTED]>
wrote:
| I am aware those characteristics are quantitative and don't say
| anything about the quality of the distribution.

They're also somewhat skewed, given all the modular ebuilds people are
making of late...

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo activity graphs

[Chris Gianelloni]

On Fri, 2006-07-07 at 19:49 +0100, Ciaran McCreesh wrote:
> On Fri, 07 Jul 2006 21:34:49 +0300 Alin Nastac <[EMAIL PROTECTED]>
> wrote:
> | I am aware those characteristics are quantitative and don't say
> | anything about the quality of the distribution.
> 
> They're also somewhat skewed, given all the modular ebuilds people are
> making of late...

Gnome ( + a few dependencies) == 150
KDE == 15
KDE (modular) == 289 ( + 10 for kdebindings-meta and dependencies)
X.Org (7.0) == 190

Now, gnome's always been a bit big, but KDE went from 15 to 300, and
X.Org went from one to 190.

By the way, all these numbers are from the input files I used for my
"keyword" script when marking these on x86.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Duncan]

"Kevin F. Quinn" <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Fri,
07 Jul 2006 17:46:14 +0200:

> Diego's proposal essentially generates CPU_SUBMODEL automatically from
> CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not
> set.  That way we have the best of both worlds; people who are happy to
> let the system determine the configure options from the compiler
> architecture can do so, those who want to control things in more detail
> can do that as well.

+1

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo activity graphs

[Chris Bainbridge]

On 07/07/06, Alin Nastac <[EMAIL PROTECTED]> wrote:
> I am aware those characteristics are quantitative and don't say anything

about the quality of the distribution. However, judging after those
graphs, even the worst basher will recognize that we are far from being
dead.


It may be a better metric to look at the bugzilla stats. How has the
number of bugs being filed changed? What ratio of filed bugs are
resolved, vs the ones that are left open? bugs.gentoo.org has some
facilities for graphing stats back to December 2005...
--
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ned Ludd]

On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> > Keep pushing this and the only thing you will end up with is the 
> > vanilla flag being removed all together..
> 
> Is that a threat? If not, is there a reason behind this?

Yes.. When users or devs complain non stop when they 
don't understand something it leaves us with a few choices.
1) put up with people not having a clue.
2) remove the option so they can't bitch about it.

Option #1 is not fun as it pushes the hand on #2

> > You want a pure 100% 
> > vanilla(POS) non working toolchain then go download it and 
> > compile it yourself. You will soon see why things exist the way 
> > they do..
> 
> If you mean modifying the build system to actually work properly, then I
> have no problem with that. USE=vanilla refers to runtime behaviour, not
> the build system. (See use.desc.) Specifically, if patches are applied
> that make sure GCC compiles, and those patches make sure GCC compiles to
> the same program intended by the GCC devs at that release, those patches
> are appropriate, IMO. None of the GCC patches I have problems with are
> of this nature.
> 
> If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
> an explanation, because as far as I know, it can work just fine as a
> system compiler, and plenty of people, at some times myself included,
> use it as one.

You use the Gentoo modified one. Regardless of what USE= flags you have
enabled you are still getting Gentoo behaviors.

Think vanilla-sources are pure? They are not. 
They get patched as well with the minimal amount of patches required.
-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Tushar Teredesai]

On 7/7/06, Ned Ludd <[EMAIL PROTECTED]> wrote:

You want a pure 100%
vanilla(POS) non working toolchain then go download it and
compile it yourself. You will soon see why things exist the way
they do..


LFS  has always been based on a
"vanilla" toolchain. Never ran into issues. Of course, we do apply
upstream patches when needed.

--
Tushar Teredesai
  mailto:[EMAIL PROTECTED]
  http://www.linuxfromscratch.org/~tushar/
--
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

On Friday 07 July 2006 12:53, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
> > If you take out the stub patches (which incidentally have no impact on
> > code generation), many builds will simply fail because they expect the
> > additional flags from ssp, htb etc to be there.
>
> That's the point. I mentioned being able to test whether your own
> software compiles with a pure GNU toolchain as a desire. Being able to
> see whether unofficial compiler options are used is not just a nice
> extra, but even necessary for that.

as i said, this really is a non-issue considering SSP has been integrated into 
mainline gcc

> > Again, if you don't gave GCC_SPECS defined in your environment then
> > that patch makes no difference to code generation.
>
> Yes, but if GCC_SPECS is defined in the environment

so what's stopping you from undefining it ?
-mike


pgpduWyurTvdI.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo activity graphs

[Kevin F. Quinn]

On Fri, 7 Jul 2006 20:53:12 +0100
"Chris Bainbridge" <[EMAIL PROTECTED]> wrote:

> On 07/07/06, Alin Nastac <[EMAIL PROTECTED]> wrote:
>  > I am aware those characteristics are quantitative and don't say
>  > anything
> > about the quality of the distribution. However, judging after those
> > graphs, even the worst basher will recognize that we are far from
> > being dead.
> 
> It may be a better metric to look at the bugzilla stats. How has the
> number of bugs being filed changed? What ratio of filed bugs are
> resolved, vs the ones that are left open? bugs.gentoo.org has some
> facilities for graphing stats back to December 2005...

There's information on this in the GWN.  However I'm not sure it's
accurate; over the last two months, new bugs filed has consistently
been double the number of bugs closed or resolved; typically some
700-800 new bugs a week and 300-400 closed/resolved a week - however the
total number of open bugs over the same period has increased by just
372 bugs from 9947 to 10319 (total new + reopened - closed = 3791).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote:
> On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
> > On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> > > Keep pushing this and the only thing you will end up with is the 
> > > vanilla flag being removed all together..
> > 
> > Is that a threat? If not, is there a reason behind this?
> 
> Yes.. When users or devs complain non stop when they 
> don't understand something it leaves us with a few choices.
> 1) put up with people not having a clue.
> 2) remove the option so they can't bitch about it.
> 
> Option #1 is not fun as it pushes the hand on #2

Option 3: Enlighten me. I have explained why I feel the way I do, so if
there's some big flaw in my understanding, please do correct it.

> > > You want a pure 100% 
> > > vanilla(POS) non working toolchain then go download it and 
> > > compile it yourself. You will soon see why things exist the way 
> > > they do..
> > 
> > If you mean modifying the build system to actually work properly, then I
> > have no problem with that. USE=vanilla refers to runtime behaviour, not
> > the build system. (See use.desc.) Specifically, if patches are applied
> > that make sure GCC compiles, and those patches make sure GCC compiles to
> > the same program intended by the GCC devs at that release, those patches
> > are appropriate, IMO. None of the GCC patches I have problems with are
> > of this nature.
> > 
> > If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
> > an explanation, because as far as I know, it can work just fine as a
> > system compiler, and plenty of people, at some times myself included,
> > use it as one.
> 
> You use the Gentoo modified one. Regardless of what USE= flags you have
> enabled you are still getting Gentoo behaviors.

Gentoo isn't the only system I use. I have used vanilla GCC + build
fixes, and I have been able to get a working system with it. So I'm
still waiting on your explanation of how it is unusable.

> Think vanilla-sources are pure? They are not. 
> They get patched as well with the minimal amount of patches required.

Interesting, and I did not know that, but looking at kernel-2.eclass
(which appears to be the only thing doing any modifying), the
modifications are all build system fixes, and won't affect the generated
kernel.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

On Friday 07 July 2006 01:46, Harald van Dijk wrote:
> On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > > compiler in Gentoo.
> >
> > you're just griping because i forced ssp/pie regardless of USE=vanilla
> > ...
>
> I didn't mind that you applied ssp/pie patches regardless of
> USE=vanilla, I did mind that you applied the stub patches with
> USE="nossp vanilla", and I also didn't like that this was either done 
> accidentally but ignored when pointed out, or that this was done
> deliberately with a misleading cvs log message.

it was not ignored, i told you the answer was no ... i listened to your 
request and then i evaluated the situation and deemed at the time to go with 
what we have now.  see how your usage of "ignored" is incorrect here ?

as Kevin pointed out, the stubs do not affect code generation so i preferred 
to keep users from breaking themselves

also, at the time, i told you you could easily work around the stub situation 
by simply deleting them:
rm /usr/portage/sys-devel/gcc/files/stubs/*
and then add sys-devel/gcc/files/stubs/ to your rsync exclude list

once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply 
the stubs when USE=nossp as the majority of users will no longer be in the 
situation i referred to earlier

> > since gcc-4.0 and below are on the way out, i have no problem changing
> > this behavior
> >
> > besides, since both of these technologies are in mainline gcc now, i
> > really dont see how you can continue to gripe with gcc-4.1.1+
>
> I don't know how much gcc-spec-env.patch can be trusted, and even if it
> is 100% safe, such patches don't belong in anything that would be called
> "vanilla". (I have commented on that patch long before this thread
> started, so don't think I'm just looking for something to complain about
> now.)

you never pointed that patch out to me nor did i notice it, so i dont really 
see how you could have expected this to be fixed already

i'll update cvs when i get a chance
-mike


pgpC3qwT1Y3nm.pgp
Description: PGP signature

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Roy Bamford]

On 2006.07.07 14:27, Chris Gianelloni wrote:

On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote:
> The more I think about the issue and the more I like the complete
> profiles for amd64 more than the other solutions.

I don't even *want* to think of what this would be for x86.

These are what I can think of, so far, with regards to different
support
on different chips.

x86 (everything)
i586 (everything i586-compatible)
i586 + mmx (pentium-mmx)
i686 (everything i686-compatible)
i686 + mmx (pentium2+, athlon+)
i686 + mmx + sse (pentium3+, athlon-xp+)
i686 + mmx + sse + sse2 (pentium4+, athlon64+, opteron+)
i686 + mmx + see + sse2 + sse3 (some pentium4, some athlon64, some
opteron)
i686 + mmx + 3dnow (athlon+)
i686 + mmx + 3dnow + sse (athlon-xp+)
i686 + mmx + 3dnow + sse + sse2 (athlon64+, opteron+)
i686 + mmx + 3dnow + sse + sse2 + sse3 (some athlon64, some opteron)


[snip]


--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


Chris,

Its east to make worse too. There's mmxext and 3dnowext too.

Regards,

Roy Bamford

--
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
> On Friday 07 July 2006 01:46, Harald van Dijk wrote:
> > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > > > compiler in Gentoo.
> > >
> > > you're just griping because i forced ssp/pie regardless of USE=vanilla
> > > ...
> >
> > I didn't mind that you applied ssp/pie patches regardless of
> > USE=vanilla, I did mind that you applied the stub patches with
> > USE="nossp vanilla", and I also didn't like that this was either done 
> > accidentally but ignored when pointed out, or that this was done
> > deliberately with a misleading cvs log message.
> 
> it was not ignored, i told you the answer was no ... i listened to your 
> request and then i evaluated the situation and deemed at the time to go with 
> what we have now.  see how your usage of "ignored" is incorrect here ?

Actually, you did ignore. The below text refers to something older.

> as Kevin pointed out, the stubs do not affect code generation so i preferred 
> to keep users from breaking themselves
> 
> also, at the time, i told you you could easily work around the stub situation 
> by simply deleting them:
> rm /usr/portage/sys-devel/gcc/files/stubs/*
> and then add sys-devel/gcc/files/stubs/ to your rsync exclude list

Yes, you told me this, before USE=vanilla even existed for gcc. When
there's no implicit claim that installed GCC is official GCC, it's much
less of a problem that it's not. Back then, I never complained that the
installed GCC wasn't the official GCC, only that (a manually installed)
official GCC wasn't a supported compiler. And I did not ask for an
official way to disable the stub patches then, I only asked how I could
do it for my own system.

> once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply 
> the stubs when USE=nossp as the majority of users will no longer be in the 
> situation i referred to earlier

Thanks. I hope that if a similar situation comes up, ebuilds will use
test-flags instead of assuming the option is valid, though.

> > > since gcc-4.0 and below are on the way out, i have no problem changing
> > > this behavior
> > >
> > > besides, since both of these technologies are in mainline gcc now, i
> > > really dont see how you can continue to gripe with gcc-4.1.1+
> >
> > I don't know how much gcc-spec-env.patch can be trusted, and even if it
> > is 100% safe, such patches don't belong in anything that would be called
> > "vanilla". (I have commented on that patch long before this thread
> > started, so don't think I'm just looking for something to complain about
> > now.)
> 
> you never pointed that patch out to me nor did i notice it, so i dont really 
> see how you could have expected this to be fixed already

I didn't point that out to you, I pointed that out to another of the
toolchain guys. I'm not completely sure who, but I think it was
Halcy0n.

> i'll update cvs when i get a chance

Thanks again.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Mike Frysinger]

On Friday 07 July 2006 12:18, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk <[EMAIL PROTECTED]>
> | I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
> | This should be set to sane defaults in the profiles. I.e. for x86,
> | it should not set CPUFLAGS at all, and on AMD64 it should be
> |   CPUFLAGS="mmx sse sse2"
>
> The issue with this is that $feature on amd64 is not exactly the same as
> $feature on x86. Would a better name be ${ARCH}_FEATURES or somesuch?
> That way there would be no confusion as to whether the cpuflags_sse2 USE
> flag did something for x86 or for amd64 or for both, since there'd be
> either x86_features_sse2 or amd64_features_sse2 or both.

it would make handling in ebuilds a bit more complicated, but then again 
having a unified namespace here would make profile use.masking more 
complicated ... keeping all this information in the ebuild would make life a 
lot easier for developers even if it did make configure flag setup a bit more 
complicated

> It'd also make handling use masking much easier.

why ?  because there wouldnt be anything to mask ?
-mike


pgpGQQxuZ9LH7.pgp
Description: PGP signature

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

On Friday 07 July 2006 17:53, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
> > On Friday 07 July 2006 01:46, Harald van Dijk wrote:
> > > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a
> > > > > supported compiler in Gentoo.
> > > >
> > > > you're just griping because i forced ssp/pie regardless of
> > > > USE=vanilla ...
> > >
> > > I didn't mind that you applied ssp/pie patches regardless of
> > > USE=vanilla, I did mind that you applied the stub patches with
> > > USE="nossp vanilla", and I also didn't like that this was either done
> > > accidentally but ignored when pointed out, or that this was done
> > > deliberately with a misleading cvs log message.
> >
> > it was not ignored, i told you the answer was no ... i listened to your
> > request and then i evaluated the situation and deemed at the time to go
> > with what we have now.  see how your usage of "ignored" is incorrect here
> > ?
>
> Actually, you did ignore. The below text refers to something older.

ignored *what* then ?  you requested USE=vanilla control ssp, i said no and 
i'll add support for USE=nossp ... you requested USE/stub control, i said no, 
go delete the stubs

i dont see what else you're referring to ... be specific, vague claims only 
lead to wasting of both our times

> > > I don't know how much gcc-spec-env.patch can be trusted, and even if it
> > > is 100% safe, such patches don't belong in anything that would be
> > > called "vanilla". (I have commented on that patch long before this
> > > thread started, so don't think I'm just looking for something to
> > > complain about now.)
> >
> > you never pointed that patch out to me nor did i notice it, so i dont
> > really see how you could have expected this to be fixed already
>
> I didn't point that out to you, I pointed that out to another of the
> toolchain guys. I'm not completely sure who, but I think it was
> Halcy0n.

all bets are off now then ... with Halcy0n leaving us, that leaves me as the 
only person maintaining the toolchain (there are few devs who contribute 
fixes for their ports and it helps out a ton, but that doesnt really count as 
being fully responsible for the toolchain packages).  no more making 
retroactive claims when i wasnt involved ;P

i trust azarah to help out, but he's been busy in real life so i havent/wont 
ask him to contribute since i know he cannot (even if he wants to)
-mike


pgpo5gBd7Gxpr.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <[EMAIL PROTECTED]>
wrote:
| > The issue with this is that $feature on amd64 is not exactly the
| > same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
| > somesuch? That way there would be no confusion as to whether the
| > cpuflags_sse2 USE flag did something for x86 or for amd64 or for
| > both, since there'd be either x86_features_sse2 or
| > amd64_features_sse2 or both.
| 
| it would make handling in ebuilds a bit more complicated

I'm not so sure. As I understand things based upon previous
discussions on this issue, in most cases fancy optional assembly
routines aren't compatible between x86 and amd64 and separate code is
required for them anyway.

| > It'd also make handling use masking much easier.
| 
| why ?  because there wouldnt be anything to mask ?

I'm pretty sure that USE_EXPAND has to be the same across all profiles,
so no, masking would still be required. I'm thinking more avoiding the
cases where amd64 users set CPU_FEATURES="blah", and the fooplayer
package only has blah code written for x86 CPUs.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Mike Frysinger]

On Friday 07 July 2006 18:15, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <[EMAIL PROTECTED]>
> | > The issue with this is that $feature on amd64 is not exactly the
> | > same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
> | > somesuch? That way there would be no confusion as to whether the
> | > cpuflags_sse2 USE flag did something for x86 or for amd64 or for
> | > both, since there'd be either x86_features_sse2 or
> | > amd64_features_sse2 or both.
> |
> | it would make handling in ebuilds a bit more complicated
>
> I'm not so sure. As I understand things based upon previous
> discussions on this issue, in most cases fancy optional assembly
> routines aren't compatible between x86 and amd64 and separate code is
> required for them anyway.

where it's a unified configure option it would be:

econf $(use_enable mmx)

myconf=""
use amd64_cpuflags_mmx && myconf="${myconf} --enable-mmx"
use x86_cpuflags_mmx && myconf="${myconf} --enable-mmx"
econf $myconf

then again, the situation we're in now is the same (people either checking 
USE=mmx or ARCH=amd64, which is wrong imho)

> | > It'd also make handling use masking much easier.
> |
> | why ?  because there wouldnt be anything to mask ?
>
> I'm pretty sure that USE_EXPAND has to be the same across all profiles,
> so no, masking would still be required. I'm thinking more avoiding the
> cases where amd64 users set CPU_FEATURES="blah", and the fooplayer
> package only has blah code written for x86 CPUs.

huh ?  in your schema, the variable itself would be name spaced, so there 
would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there wouldnt be just 
CPU_FEATURES
-mike


pgpRdcIuR7cXa.pgp
Description: PGP signature

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 06:13:27PM -0400, Mike Frysinger wrote:
> ignored *what* then ?  you requested USE=vanilla control ssp, i said no and 
> i'll add support for USE=nossp ... you requested USE/stub control, i said no, 
> go delete the stubs

USE=nossp existed before USE=vanilla did. To be sure I'm remembering
right, I checked `cvs log toolchain.eclass`. In order, probably skipping
a few steps:

1- No SSP
2- Choice between SSP [USE=-nossp] and stub patches [USE=nossp].
   USE=vanilla didn't exist.
3- Choice between SSP [USE="-nossp -vanilla"], stub patches
[USE="nossp -vanilla"], and nothing [USE="vanilla"]
4- Choice between SSP [USE=-nossp] and stub patches [USE=nossp]
   USE=vanilla exists but has no effect on SSP.

It was during 2 that I asked for a way to disable stub patches for
myself (and not as part of the official ebuild), and you said to delete
them. That was good enough for me during 2. We are now in 4.

> i dont see what else you're referring to ... be specific, vague claims only 
> lead to wasting of both our times

I hope this is specific enough: toolchain.eclass revision 1.234
(separating ssp/... from vanilla) log message:
"ssp/pie/htb have their own USE flags sep from vanilla, so people can 
 utilize those"
when in fact the old USE=vanilla behaviour is unavailable now. You have
never (as far as I know) answered whether it was intended to keep the
old behaviour as an option, and if it wasn't, why the log message is
what it is.

> all bets are off now then ... with Halcy0n leaving us, that leaves me as the 
> only person maintaining the toolchain (there are few devs who contribute 
> fixes for their ports and it helps out a ton, but that doesnt really count as 
> being fully responsible for the toolchain packages).

I'll keep that in mind, I wasn't aware that the other toolchain guys
handle specific parts of the toolchain packages only. Even if I disagree
with some specific decisions, nice job overall, then.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/7/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:

> Are you using an portage overlay?  If so, what is in it?

No.  No idea what that is.  Sounds interesting, though.


It is a local portage tree with ebuilds that you have either written
yourself or downloaded from others.  Since the overlay will override
what is in portage, you can easily get yourself into trouble this way.
So it is not really recommended unless you *really* know what you are
doing!


[nomerge  ] dev-util/mono-tools-1.1.11
[ebuild  N]  dev-dotnet/gecko-sharp-0.6
[nomerge  ]   www-client/mozilla-1.7.13


*Sigh*.  What a mess.  Unfortunately the Gentoo dev's have taken the
rather unusual step of _breaking the tree_ due to a security problem.
And from what I understand [1], mozilla is going to be package masked
today (if it hasn't already), so the block messages should go away,
but you'll get even worse "no package to satisify" messages.

At this point your choices are fairly limited, and neither one is very good.

1. Unmerge both mono-tools and gecko-sharp.  Mono-tools requires
gecko-sharp, and that requires mozilla.  You can use "equery files
mono-tools" to see what you will lose by going this route.

2. Manually unmask mozilla (and probably mono-tools and gecko-sharp)
to keep them around.  This might work, but I think you're going to be
jumping through a lot of hoops to try and avoid seamonkey.

-Richard

[1] http://bugs.gentoo.org/show_bug.cgi?id=137665
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

[Alexandre Buisse]

On Fri, Jul  7, 2006 at 09:53:36 +0200, Seemant Kulleen wrote:

> Hi Everyone,
> 
> I just wanted to put a few thoughts out there as people contemplate
> nominees and the elections for the Gentoo Council.  I personally am on
> the fence about running this year, because I think there are a lot of
> talented people who *should* be on the council.
> 
> Now that I've said that (the "*should*" bit), let me expand on its
> meaning a little.  I think the Council idea is great.  However, I think
> the Council should be charged with a little bit of direction-setting and
> leadership as well.  In the past year, the council did make some
> decisions, and helped to mediate some controversial issues. 
> 
> There were a couple of things which I thought were lacking, however:
> 
> 1. The council was (by design?) a reactive force, rather than a
> pro-active force.
> 
> 2. There's no way to follow through on the Council's decisions.
> 
> I think these points involve *every* gentoo developer (and would-be
> developer) and not just the Council.  If you have a GLEP or an idea and
> it gets approved by the council, now what?  That's the thing: follow
> through on it! A question is, perhaps, should the council follow-up with
> previously approved GLEPs and inquire as to status updates?
> 
> For an exemplar of the way I think the council should be is
> Spanky/vapier.  Solar also does this well.  Both of them take a
> leadership role in general in the project and are generally respected
> and admired for it.  They both have great ideas and a vision.  I think
> that should be explored further.  This project needs some leadership, as
> the events of the past few months show fairly clearly.

Encouraged by this email and hoping that it is ok to do so, I will
nominate myself.

Thanks,
/Alexandre
-- 
Hi, I'm a .signature virus! Please copy me in your ~/.signature.


pgpBeJrKXXpfW.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Ciaran McCreesh]

On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger <[EMAIL PROTECTED]>
wrote:
| > | > It'd also make handling use masking much easier.
| > |
| > | why ?  because there wouldnt be anything to mask ?
| >
| > I'm pretty sure that USE_EXPAND has to be the same across all
| > profiles, so no, masking would still be required. I'm thinking more
| > avoiding the cases where amd64 users set CPU_FEATURES="blah", and
| > the fooplayer package only has blah code written for x86 CPUs.
| 
| huh ?  in your schema, the variable itself would be name spaced, so
| there would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there
| wouldnt be just CPU_FEATURES

My example was demonstrating a problem in the non-namespaced case, not
the namespaced solution. Expanding this with an example...

Assuming that x86 and amd64 both support foo and bar, and that the baz
app supports both on x86 and only foo on amd64:

No namespacing:

x86   # [ebuild N] app-misc/baz USE="oink" CPU_FEATURES="foo baz"
amd64 # [ebuild N] app-misc/baz USE="oink" CPU_FEATURES="foo baz"

With namespacing:

x86   # [ebuild N] app-misc/baz USE="oink" x86_CPU_FEATURES="foo baz"
amd64_CPU_FEATURES="(-foo)"
amd64 # [ebuild N] app-misc/baz USE="oink" x86_CPU_FEATURES="(-foo)
(-baz)" amd64_CPU_FEATURES="foo"

With namespacing, and with USE_EXPAND_HIDDEN set in subprofiles which
may well be illegal:

x86   # [ebuild N] app-misc/baz USE="oink" x86_CPU_FEATURES="foo baz"
amd64 # [ebuild N] app-misc/baz USE="oink" amd64_CPU_FEATURES="foo"

The output's a bit longer, but it avoids telling the user that they're
getting something that they aren't.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

On Friday 07 July 2006 19:04, Harald van Dijk wrote:
> I hope this is specific enough: toolchain.eclass revision 1.234
> (separating ssp/... from vanilla) log message:
> "ssp/pie/htb have their own USE flags sep from vanilla, so people can
>  utilize those"
> when in fact the old USE=vanilla behaviour is unavailable now. You have 
> never (as far as I know) answered whether it was intended to keep the
> old behaviour as an option, and if it wasn't, why the log message is
> what it is.

well i cant answer it if you havent asked it ... me not answering you on irc 
when i'm not around does not constitute being ignored and anyone who relies 
on irc in this respect really needs to learn more about irc

the log message looks pretty clear to me, i dont see this "hidden message" 
you're referring to

the ssp/pie/htb patches have their own USE flags so separating them from 
USE=vanilla makes perfect sense ... now you can do:
gentoo patches + ssp
gentoo patches + nossp
vanilla + ssp
vanilla + nossp

whereas before you only had the option of:
gentoo patches + ssp
vanilla + nossp

like i said in my previous e-mail, forcing stubs onto people even when 
USE=vanilla *is by design* because i got tired of people who had no clue 
about the consequences throwing USE=vanilla into their USE in make.conf and 
then complaining when the lack of SSP broke things ... this is also the 
reason i havent added USE=vanilla to glibc, too many users would simply break 
their boxes
-mike


pgpi4ug0sMzuq.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles

[Luca Barbato]

Ciaran McCreesh wrote:
> Assuming that x86 and amd64 both support foo and bar, and that the baz
> app supports both on x86 and only foo on amd64:

the app would ignore foo by itself and usually people are working on
having their tailored x86 code in shape for amd64 (using some tricks as
usual...)

I feel afraid since we are spending lot of time assuming our users don't
have a clue about what they bought or that they cannot document
themselves as they should for picking the right cpu/tune for the CFLAGS...

Diego's proposal could be nice for remove some options and prevent the
burden of keeping a long list of useflag due the Intel vs Amd war on the
extensions, sadly I think was pointed that isn't a complete solution and
many would be unhappy about it.
Having a USE_EXPAND for the cpu feats could a little improvement if we
expect sse99 or 5dnowultra appear within the year since we could stuff
all this cruft in a single place and have a separate use.desc for them.

I hope I'm not too tired and I didn't miss something ^^

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo activity graphs

[Alin Nastac]

Chris Bainbridge wrote:
> It may be a better metric to look at the bugzilla stats. How has the
> number of bugs being filed changed? What ratio of filed bugs are
> resolved, vs the ones that are left open? bugs.gentoo.org has some
> facilities for graphing stats back to December 2005...
Bugzilla cannot plot ratios.

I find "active devs" metric a useful one.Until a year ago, the number of
active devs was linearly rising, but in last year we seem to hit a ceil
(175) - either recruiter team is understaffed or our organization
reached the maximum number of individuals who can work together without
stepping (too much) on each other toes. Anyway, a thing is certain...
Gentoo didn't loosed dev's attention.



signature.asc
Description: OpenPGP digital signature

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
> On Friday 07 July 2006 19:04, Harald van Dijk wrote:
> > I hope this is specific enough: toolchain.eclass revision 1.234
> > (separating ssp/... from vanilla) log message:
> > "ssp/pie/htb have their own USE flags sep from vanilla, so people can
> >  utilize those"
> > when in fact the old USE=vanilla behaviour is unavailable now. You have 
> > never (as far as I know) answered whether it was intended to keep the
> > old behaviour as an option, and if it wasn't, why the log message is
> > what it is.
> 
> well i cant answer it if you havent asked it ... me not answering you on irc 
> when i'm not around does not constitute being ignored and anyone who relies 
> on irc in this respect really needs to learn more about irc

I also mentioned it in a bugzilla comment, though admittedly not as a
question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to
assume read, right?

> the log message looks pretty clear to me, i dont see this "hidden message" 
> you're referring to
> 
> the ssp/pie/htb patches have their own USE flags so separating them from 
> USE=vanilla makes perfect sense ...

I'm not disagreeing with that, but removing an older option is not just
providing more choices.

> now you can do:
> gentoo patches + ssp
> gentoo patches + nossp
> vanilla + ssp
> vanilla + nossp

gentoo patches + ssp
gentoo patches + stub
vanilla + ssp
vanilla + stub

> whereas before you only had the option of:
> gentoo patches + ssp
> vanilla + nossp

gentoo patches + ssp
gentoo patches + stub
vanilla

> like i said in my previous e-mail, forcing stubs onto people even when 
> USE=vanilla *is by design* because i got tired of people who had no clue 
> about the consequences throwing USE=vanilla into their USE in make.conf and 
> then complaining when the lack of SSP broke things ...

But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
asking for USE="vanilla nossp" to disable it. "nossp" is already
explicitly documented as "NOT FOR GENERAL USE", too.

>this is also the 
> reason i havent added USE=vanilla to glibc, too many users would simply break 
> their boxes

No complaints there. :)
-- 
gentoo-dev@gentoo.org mailing list