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

2006-07-06 Thread Patrick Lauer
On Sat, 2006-07-01 at 02:46 -0400, Mike Frysinger wrote:
 well it's about that time of the year ... time for nominating people 
 for the next Gentoo Council
So here's my nominations:

Flameeyes
brix
lu_zero
kosmikus
Stuart
jakub
marienz
patrick


-- 
Stand still, and let the rest of the universe move


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


Re: [gentoo-dev] Re: [gentoo-core] IMPORTANT: bugs performance issues

2006-07-06 Thread Jakub Moc
Curtis Napier wrote:
 Lance Albertson wrote:
 Please thank GNI for helping us out! They really deserve a lot for
 helping us :).

 Thanks-

 [1] http://www.gni.com/

 
 
 Thank you GNI!
 
 
 droolmmm blade cluster/drool
 
 

Yay, *plop* !!! (And no, tsunam - no compiling there :P)


-- 

jakub



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Portage: missing pieces

2006-07-06 Thread Molle Bestefich

I think a piece might be missing from Portage.

I'll depict my workflow as an example.

I'm preparing to upgrade:
# emerge --sync
# emerge -Dp world
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXinerama-1.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXi-1.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXrandr-1.1.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/randrproto-1.1.2)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-misc/makedepend-1.0.0)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking media-libs/mesa-6.5-r3)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libdrm-2.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking
x11-proto/xf86vidmodeproto-2.2.2)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/glproto-1.4.7)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking
x11-proto/xf86driproto-2.0.3)
... etc, lots of blockers ...

Ok, let's try and find why it wants to downgrade to xorg-x11-6.9:
# equery d xorg-x11-6.9
[ Searching for packages depending on xorg-x11-6.9... ]

none found
#

Ok, no reason, apparently.  Maybe it's already merged then?
# emerge -C xorg-x11-6.9
--- Couldn't find 'xorg-x11-6.9' to unmerge.

Nope.  Now I'm getting uncertain.  Don't I have xorg-x11 at all?
# emerge -C xorg-x11

x11-base/xorg-x11
   selected: 7.0-r1
  protected: none
omitted: none


'Selected' packages are slated for removal.
'Protected' and 'omitted' packages will not be removed.



Waiting 5 seconds before starting...
(Control-C to abort)...
Unmerging in: 5 4 3


CTRL-C
Exiting on signal 2

Whoops.  Yep, it's there.

Ok, so status is that I have xorg-x11-7.0, I don't have 6.9,
no packages actually wants xorg-x11-6.9, but whenever I use
emerge -D world, Portage sees it as a blocker anyway.

Is there a piece missing in this puzzle, in particular the one that
will tell me why on earth Portage thinks version 6.9 is a blocker?

Or is the piece in place but I'm not looking hard enough?
--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Danny van Dyk
Am Dienstag, 4. Juli 2006 21:04 schrieb Mike Frysinger:
 from current council:
 koon / agriffis / azarah / seemant / solar

 some other peeps:
 Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba /
 jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg
Thanks, I accept this nomination.

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



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

2006-07-06 Thread Martin Schlemmer
On Tue, 2006-07-04 at 15:04 -0400, Mike Frysinger wrote:
 On Saturday 01 July 2006 02:46, Mike Frysinger wrote:
  well it's about that time of the year ... time for nominating
  people for the next Gentoo Council
 
 i guess i'll start off some mass nominations of random people off the top of 
 my head who i think would do a good job ... there's a bunch more people i 
 think would do a good job, but i'm going to cut my list short as it's already 
 ridiculously long ...
 
 from current council:
 koon / agriffis / azarah / seemant / solar
 
 some other peeps:
 Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / 
 jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg
 
 i'd also nominate g2boojum, but i kind of like his current unofficial role as 
 honorary council adviser guy ...

I would like to refrain from accepting until just before the final
nominees are put out, as currently my life is pretty much in flux.  If
possible that is.


-- 
Martin Schlemmer



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


Re: [gentoo-dev] Portage: missing pieces

2006-07-06 Thread Donnie Berkholz
Molle Bestefich wrote:
 Ok, so status is that I have xorg-x11-7.0, I don't have 6.9,
 no packages actually wants xorg-x11-6.9, but whenever I use
 emerge -D world, Portage sees it as a blocker anyway.
 
 Is there a piece missing in this puzzle, in particular the one that
 will tell me why on earth Portage thinks version 6.9 is a blocker?
 
 Or is the piece in place but I'm not looking hard enough?

I already replied to your post on -user. In the future, please don't
post the same thing to multiple lists.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Portage: missing pieces

2006-07-06 Thread Molle Bestefich

Molle Bestefich wrote:

I think a piece might be missing from Portage.

I'll depict my workflow as an example.


Same thing with a package called 'seamonkey':

# emerge -Dpt world
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
[blocks B ] =sys-apps/shadow-4.0.14-r2 (is blocking
sys-apps/pam-login-4.0.14)
[blocks B ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.15-r2)
... etc ...

# emerge --unmerge seamonkey
--- Couldn't find 'seamonkey' to unmerge.

No packages selected for removal by unmerge.


# equery d seamonkey
[ Searching for packages depending on seamonkey... ]

#

Nobody wants a seamonkey, and I haven't got one already, but Portage
wants to smuggle one in anyway if I tell it to upgrade world.

Where's the piece that can tell me why Portage wants to do so?

(Alternatively, what's the manual process to find out?)
--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Tuesday 04 July 2006 21:04, Mike Frysinger wrote:
 some other peeps:
 Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba /
 jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg
I gladly accept the nomination, too.

And add my nominations for lu_zero, seemant, solar, koon, mr_bones_ and 
wolf31o2.

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


pgpaC2ZdiFnTR.pgp
Description: PGP signature


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

2006-07-06 Thread Stefan Schweizer
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:

AllanonJL for his gnome work
nichoj for the outstanding java-2 move
rl03 for his devdication to webapps
antarus for his treecleaners work
CHTEKK and sebastian for their php work

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Replacing cpu-feature USE flags

2006-07-06 Thread Diego 'Flameeyes' Pettenò
So, I've been drafting this up in my blog[1], and it is a simple way to 
replace the CPU feature useflags. Let's try to summarise:

Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in 
the tree, almost never used to get new dependencies, but usually used to 
supply econf switches.

This works as long as the user enable the flags, but for AMD64 the story was, 
until now, that we simply enabled them when they worked, because we had some 
minimum support available. Unfortunately this became a problem with the 
introduction of nocona, because that is an amd64-like system but with no 
3dnow. And there is the problem that sse3 is supported only in later versions 
of Athlon64 and so on.

To try to clean up this mess, and to make it simpler to work in 
cross-compilation, I thought of using the definitions created by the C 
Preprocessor (CPP) by default for the given CFLAGS. Basically when 
using -march=athlon64, the preprocessor will enable a few definitions that 
tells the availability of MMX, 3dNOW, SSE and so on... if we wrap that 
around, we can use it to know if it's the case of enabling something or not.
This is customisable by the user by setting the CFLAGS themselves. If one does 
not want MMX instructions to be generated, but still want the rest of 
Athlon64 optimisations, it's simply the matter of 
using -march=athlon64 -mno-mmx.

So, rather than the functions proposed in [1], I've sampled today the 
following function:

has_cpuset() {
local def hasfeat

while [[ -n $1 ]]; do
case $1 in
mmx)
def=__MMX__ ;;
3dnow)
def=__3dNOW__ ;;
3dnowex)
def=__3dNOW_A__ ;;
sse)
def=__SSE__ ;;
sse2)
def=__SSE2__ ;;
sse3)
def=__SSE3__ ;;
altivec)
def=__ALTIVEC__ ;;
*)
ewarn Instruction set $1 not supported.
die Instruction set not supported.
esac

echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null | grep -q ${def} || 
hasfeat=no
shift
done

if [[ ${hasfeat} == no ]]; then
return 1
else
return 0
fi
}

that can be tested easily with the following code:

yesno() {
if $@; then
echo yes
else
echo no
fi
}

echo Does it have 3dnow mmx sse2?
yesno has_cpuset 3dnow mmx sse2
echo Does it have mmx sse sse3?
yesno has_cpuset mmx sse sse3
echo Does it have altivec?
yesno has_cpuset altivec


Note that you  need to set your CFLAGS corretly or it will, by default, tell 
you that everything is disabled.

Thoughts? Comments?

SPARC team: I'd like to know if VIS does a similar thing, would make simpler 
for instance its handling in xine-lib ebuild.

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/24/crazy-idea-an-alternative-to-cpu-features-useflags
-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgprX2XeoSak4.pgp
Description: PGP signature


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

2006-07-06 Thread Daniel Drake

Molle Bestefich wrote:

Same thing with a package called 'seamonkey':


Same answer as you got on the -user list: use --tree
But don't only look at the top section of the output.

Daniel

--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Stuart Herbert

On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
[Snip]

Note that you  need to set your CFLAGS corretly or it will, by default, tell
you that everything is disabled.

Thoughts? Comments?


The one advantage of using USE flags for this is that the support can
be controlled very easily on a per-package basis.  CFLAGS is much more
of a system-wide setting.

Are there examples where we'd want to have these CPU feature flags
enabled for one package, but disabled for another (for performance or
stability reasons)?

If this is an ability we no longer need, then I like your idea.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ioannis Aslanidis

Thought: I like it :)

On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

So, I've been drafting this up in my blog[1], and it is a simple way to
replace the CPU feature useflags. Let's try to summarise:

Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
the tree, almost never used to get new dependencies, but usually used to
supply econf switches.

This works as long as the user enable the flags, but for AMD64 the story was,
until now, that we simply enabled them when they worked, because we had some
minimum support available. Unfortunately this became a problem with the
introduction of nocona, because that is an amd64-like system but with no
3dnow. And there is the problem that sse3 is supported only in later versions
of Athlon64 and so on.

To try to clean up this mess, and to make it simpler to work in
cross-compilation, I thought of using the definitions created by the C
Preprocessor (CPP) by default for the given CFLAGS. Basically when
using -march=athlon64, the preprocessor will enable a few definitions that
tells the availability of MMX, 3dNOW, SSE and so on... if we wrap that
around, we can use it to know if it's the case of enabling something or not.
This is customisable by the user by setting the CFLAGS themselves. If one does
not want MMX instructions to be generated, but still want the rest of
Athlon64 optimisations, it's simply the matter of
using -march=athlon64 -mno-mmx.

So, rather than the functions proposed in [1], I've sampled today the
following function:

has_cpuset() {
   local def hasfeat

   while [[ -n $1 ]]; do
   case $1 in
   mmx)
   def=__MMX__ ;;
   3dnow)
   def=__3dNOW__ ;;
   3dnowex)
   def=__3dNOW_A__ ;;
   sse)
   def=__SSE__ ;;
   sse2)
   def=__SSE2__ ;;
   sse3)
   def=__SSE3__ ;;
   altivec)
   def=__ALTIVEC__ ;;
   *)
   ewarn Instruction set $1 not supported.
   die Instruction set not supported.
   esac

   echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null | grep -q ${def} ||
hasfeat=no
   shift
   done

   if [[ ${hasfeat} == no ]]; then
   return 1
   else
   return 0
   fi
}

that can be tested easily with the following code:

yesno() {
   if $@; then
   echo yes
   else
   echo no
   fi
}

echo Does it have 3dnow mmx sse2?
yesno has_cpuset 3dnow mmx sse2
echo Does it have mmx sse sse3?
yesno has_cpuset mmx sse sse3
echo Does it have altivec?
yesno has_cpuset altivec


Note that you  need to set your CFLAGS corretly or it will, by default, tell
you that everything is disabled.

Thoughts? Comments?

SPARC team: I'd like to know if VIS does a similar thing, would make simpler
for instance its handling in xine-lib ebuild.

[1]
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/24/crazy-idea-an-alternative-to-cpu-features-useflags
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE






--
Ioannis Aslanidis

deathwing00[at]gentoo.org 0xB9B11F4E

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Re: GPL and Source code providing

2006-07-06 Thread Chris Gianelloni
On Wed, 2006-07-05 at 23:01 +, Duncan wrote:
 request for three years.  Do we want that three-year obligation and is it
 worth that to make it on-request vs having them available at the same
 time?  I don't know, but it needs to be considered.

Not really.  There is 0 overhead to *leaving* a source DVD set on the
store indefinitely.  It is only the creation that requires work.  Once
it is there, it's there.

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

2006-07-06 Thread Donnie Berkholz
Diego 'Flameeyes' Pettenò wrote:
 On Thursday 06 July 2006 13:40, Donnie Berkholz wrote:
 How will you handle non-gcc compilers?
 We don't support any, to start with.
 
 But ICC I'm pretty sure behaves like GCC, and whatever else we'd go by 
 supporting should likely do the same.
 
 But again, we don't support any, so it's up to whoever wants to support them 
 to find a solution, I'd say.

Well, there are enough in the tree that you should at least make sure
they don't completely break and error out when passing them invalid
flags, even if you fail to auto-enable mmx/sse/whatever. You could do if
[[ $(tc-getCC) != *gcc* ]] or something...

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] New virtuals: virtual/jre and virtual/jdk

2006-07-06 Thread Krzysiek Pawlik

Two new new-style virtuals have been added today to the tree:

 - virtual/jdk
 - virtual/jre

This allows migration to generation 2 of Java build system to advance.
All virtual/{jdk,jre} have been removed from profiles. The bug for this
was #138747.

-- 
Krzysiek Pawlik   nelchael at gentoo.org   key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...



signature.asc
Description: OpenPGP digital signature


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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 12:52:29 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags
| present in the tree, almost never used to get new dependencies, but
| usually used to supply econf switches.
| 
| This works as long as the user enable the flags, but for AMD64 the
| story was, until now, that we simply enabled them when they worked,
| because we had some minimum support available. Unfortunately this
| became a problem with the introduction of nocona, because that is an
| amd64-like system but with no 3dnow. And there is the problem that
| sse3 is supported only in later versions of Athlon64 and so on.

The other option here... Is to rename the x86 flags to x86_mmx,
x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not
really the same as the x86 flags.

There's probably some USE_EXPAND trickery that can be used here...
CPU_FEATURE_X86=mmx sse - cpu_feature_x86_mmx etc might be cleaner?

| To try to clean up this mess, and to make it simpler to work in 
| cross-compilation, I thought of using the definitions created by the
| C Preprocessor (CPP) by default for the given CFLAGS. Basically when 
| using -march=athlon64, the preprocessor will enable a few definitions
| that tells the availability of MMX, 3dNOW, SSE and so on... if we
| wrap that around, we can use it to know if it's the case of enabling
| something or not. This is customisable by the user by setting the
| CFLAGS themselves. If one does not want MMX instructions to be
| generated, but still want the rest of Athlon64 optimisations, it's
| simply the matter of using -march=athlon64 -mno-mmx.

Sounds rather flaky and unreliable...

| SPARC team: I'd like to know if VIS does a similar thing, would make
| simpler for instance its handling in xine-lib ebuild.

VIS is present on all v9 CPUs. GCC's VIS support, however, sucks.

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


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New eclass: java-wsdp.eclass

2006-07-06 Thread Krzysiek Pawlik

New eclass has been added to the tree:

 - java-wsdp.eclass

This class is to make ebuilds for all JWSDP (
http://java.sun.com/webservices/jwsdp/ ) smaller and simpler. I'll start
commiting ebulds using this eclass in the evening (UTC), those are (all
in dev-java):

 - sun-fastinfoset-bin
 - sun-jaxb-bin
 - sun-jaxp-bin
 - sun-jaxr-bin
 - sun-jaxrpc-bin
 - sun-jaxws-bin
 - sun-jwsdp-shared-bin
 - sun-saaj-bin
 - sun-sjsxp-bin
 - sun-wsdp-bin
 - sun-xmldsig-bin
 - sun-xws-security-bin

The eclass has been tested - it has been in Java experimental overlay
for quite some time.

-- 
Krzysiek Pawlik   nelchael at gentoo.org   key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...



signature.asc
Description: OpenPGP digital signature


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

2006-07-06 Thread Kevin F. Quinn
On Thu, 6 Jul 2006 12:52:29 +0200
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

 So, I've been drafting this up in my blog[1], and it is a simple way
 to replace the CPU feature useflags.
[...]

To paraphrase the idea - use the compiler's knowledge of the target
processor to select cpu-specific code.

I like the idea a lot.  To my mind, the sse/sse2/3dnow etc should be
derived from the target arch, which is what you're doing with the
compiler's macro definitions.  This could easily be done by configure
scripts; perhaps it would be a good idea to look into writing some
autoconf macros.

re. hardened - all we ever need, is to be able to force a package to
fall back to it's portable C implementation when the asm code breaks
PIC (which is independent of whether it uses mmx, sse etc) or
generates code at runtime. I think most packages provide this, as it's
useful to the developer to compare the C implementation with
accelerated asm versions easily.

re. Donnie's point about non-gcc compilers - handling these can be
hidden in the has_cpuset() function.  They can always be determined
from the target arch (combination of ARCH and -march or equivalent
CFLAGS).  The suggested code already does the worst-case fall-back, as
it responds 'no' if the compiler doesn't support -dM or doesn't define
the relevant macro.

echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null | grep -q ${def} || 
hasfeat=no

The '2/dev/null' is the critical element for that.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote:
 Sounds rather flaky and unreliable...
Sounds rather vague and without arguments.

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


pgpBJXhfBv3GB.pgp
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote:
 This could easily be done by configure
 scripts; perhaps it would be a good idea to look into writing some
 autoconf macros.
Actually there's little need, you can simply use the #ifdef in the code, 
unless you have separated source files for MMX, SSE and so on (that might as 
well be), but even then, it's really trivial to autoconf.

The problem is that many autoconf scripts do it the other way around, by 
forcing -march or -mcpu (that is deprecated by -mtune too) deduced 
from /proc/cpuinfo.

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


pgpwZMttvPvt1.pgp
Description: PGP signature


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

2006-07-06 Thread Kevin F. Quinn
On Thu, 6 Jul 2006 14:44:22 +0200
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

 On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote:
  This could easily be done by configure
  scripts; perhaps it would be a good idea to look into writing some
  autoconf macros.
 Actually there's little need, you can simply use the #ifdef in the
 code, unless you have separated source files for MMX, SSE and so on
 (that might as well be), but even then, it's really trivial to
 autoconf.

Yep; I've seen that several packages do it the #ifdef way, which is
ideal as we don't need to do set any configure stuff at all then (I
guess those packages don't have configure options/use flags to select
between mmx, sse etc anyway).

 The problem is that many autoconf scripts do it the other way around,
 by forcing -march or -mcpu (that is deprecated by -mtune too) deduced 
 from /proc/cpuinfo.

Ooh; that's nasty.  Let me guess - mplayer ... yeah; what a surprise.
Presumably we disable such trickery if we see it, as it makes the
target code depend on the build system which is obviously wrong - at
least for Gentoo.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-06 Thread Paul de Vrieze
On Wednesday 05 July 2006 02:17, George Prowse wrote:
 On 05/07/06, Curtis Napier [EMAIL PROTECTED] wrote:
 pauldv jr
Tom let's me know he's happy with the nomination, but unfortunately does not 
master English sufficiently yet, to accept.

 pauldv snr

Senior will be happy to accept. Unlike last year, when I didn't run, I will 
have more time this year as my Ph.D. thesis is now finished, and I'm only 
waiting for formal approval.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpTInmYy8aRv.pgp
Description: PGP signature


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

2006-07-06 Thread Simon Stelling

Ciaran McCreesh wrote:

Well, you're assuming that a) everyone's using a C compiler, b) that
gcc has the slightest clue what it's doing, c) that the user has no
problem using nasty hacks to regain control, d) that this information
is only needed at compile time, e) that various gcc internal
definitions won't change... You're adding a lot of complexity, and thus
room for very weird breakages, to something that doesn't need it.


as for...

b) You kind of have to assume that when running a system that was 
compiled from ground up with gcc


c) This is not about regaining control. Currently, users who want to 
cross-compile are screwed and need nasty use.mask-hacks to not end up 
with broken binaries. The inability to provide per-package CFLAGS is a 
missing feature in portage, it's got nothing to do with this issue.


--
Kind Regards,

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



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

2006-07-06 Thread Ciaran McCreesh
On Thu, 06 Jul 2006 16:03:47 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
|  Well, you're assuming that a) everyone's using a C compiler, b) that
|  gcc has the slightest clue what it's doing, c) that the user has no
|  problem using nasty hacks to regain control, d) that this
|  information is only needed at compile time, e) that various gcc
|  internal definitions won't change... You're adding a lot of
|  complexity, and thus room for very weird breakages, to something
|  that doesn't need it.
| 
| as for...
| 
| b) You kind of have to assume that when running a system that was 
| compiled from ground up with gcc

Not really true. GCC can be quite happily wrong about what your CPU
could support, so long as it's not told to use it. This happens with
VIS, for example.

| c) This is not about regaining control. Currently, users who want
| to cross-compile are screwed and need nasty use.mask-hacks to not end
| up with broken binaries. The inability to provide per-package CFLAGS
| is a missing feature in portage, it's got nothing to do with this
| issue.

You can do it through bashrc. But then, if this is about working around
Portage's annoying lack of sane cross compile handling, why not put a
little effort into fixing it properly rather than a lot of effort into
making the tree more complicated?

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


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: autotools - 'make' infinite loop

2006-07-06 Thread Marcus Furlong

Finally, this was caused by a missing one-liner Makefile.am, it was already
fixed upstream but didn't make it into the tarball. Thanks anyway for the
suggestions.

Marcus,

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Kevin F. Quinn
On Thu, 6 Jul 2006 13:49:39 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Thu, 6 Jul 2006 14:29:39 +0200 Diego 'Flameeyes' Pettenò
 [EMAIL PROTECTED] wrote:
 | On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote:
 |  Sounds rather flaky and unreliable...
 | Sounds rather vague and without arguments.
 
 Well, you're assuming that a) everyone's using a C compiler,
 b) that gcc has the slightest clue what it's doing,

We're mostly talking about specially-written assembler code, not stuff
like vectorisation or the intrinsics (which very few packages use, if
any).

 c) that the user has no
 problem using nasty hacks to regain control,

Control is easy.  Specify the relevant -march in CFLAGS.

 d) that this information is only needed at compile time,

Where a package does run-time detection, there's no need for any
conditional compilation as they build for everything anyway, so such
packages wouldn't use mmx/sse/sse2 etc USE flags anyway.

 e) that various gcc internal definitions won't change...

Unlikely for these macros, as that would break a lot of existing code
regardless what we do.

 You're adding a lot of complexity, and
 thus room for very weird breakages, to something that doesn't need it.

I'd argue the current approach is the more complex approach, involving
the user having to discover the relationship between their processor
(which they've already set via -march in CFLAGS) and the various bits
that their processor has.


There are relatively few packages affected (1%), so I think it's worth
a try.  In the end it may be that a few packages need to deal with
stuff manually like with the current USE flags, but they'd be local USE
flags at that point.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-06 Thread Simon Stelling

Ciaran McCreesh wrote:

You can do it through bashrc. But then, if this is about working around
Portage's annoying lack of sane cross compile handling, why not put a
little effort into fixing it properly rather than a lot of effort into
making the tree more complicated?


Err, I think you're mixing up different things. How should portage be 
able to do sane cross compiling if you control the instruction sets 
through use flags which are blocked in profiles the build system is 
using? In fact, moving away from use flags over to the real(TM) solution 
is a step towards fixing the issue. Also, it doesn't make the tree more 
complicated. It is far more intuitive that supported instruction sets 
are used if the user doesn't explicitly wish not to than having some 
strange use flags that don't mean what they're named like.


--
Kind Regards,

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



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

2006-07-06 Thread Ciaran McCreesh
On Thu, 06 Jul 2006 17:09:42 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
|  You can do it through bashrc. But then, if this is about working
|  around Portage's annoying lack of sane cross compile handling, why
|  not put a little effort into fixing it properly rather than a lot
|  of effort into making the tree more complicated?
| 
| Err, I think you're mixing up different things. How should portage be 
| able to do sane cross compiling if you control the instruction sets 
| through use flags which are blocked in profiles the build system is 
| using?

That's just it. You shouldn't be using the wrong profile when compiling
things.

| In fact, moving away from use flags over to the real(TM)
| solution is a step towards fixing the issue. Also, it doesn't make
| the tree more complicated. It is far more intuitive that supported
| instruction sets are used if the user doesn't explicitly wish not to
| than having some strange use flags that don't mean what they're named
| like.

That's like saying well we should just link against whatever's
available, it's far more intuitive than letting the user decide.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ned Ludd
On Thu, 2006-07-06 at 13:19 +0100, Ciaran McCreesh wrote:
 On Thu, 6 Jul 2006 12:52:29 +0200 Diego 'Flameeyes' Pettenò
 [EMAIL PROTECTED] wrote:
 | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags
 | present in the tree, almost never used to get new dependencies, but
 | usually used to supply econf switches.
 | 
 | This works as long as the user enable the flags, but for AMD64 the
 | story was, until now, that we simply enabled them when they worked,
 | because we had some minimum support available. Unfortunately this
 | became a problem with the introduction of nocona, because that is an
 | amd64-like system but with no 3dnow. And there is the problem that
 | sse3 is supported only in later versions of Athlon64 and so on.
 
 The other option here... Is to rename the x86 flags to x86_mmx,
 x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not
 really the same as the x86 flags.
 


 There's probably some USE_EXPAND trickery that can be used here...
 CPU_FEATURE_X86=mmx sse - cpu_feature_x86_mmx etc might be cleaner?

I tend to agree this might be a cleaner approach vs having to edit 
redit CFLAGS all over the place.


-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ned Ludd
On Thu, 2006-07-06 at 17:09 +0200, Simon Stelling wrote:
 Ciaran McCreesh wrote:
  You can do it through bashrc. But then, if this is about working around
  Portage's annoying lack of sane cross compile handling, why not put a
  little effort into fixing it properly rather than a lot of effort into
  making the tree more complicated?
 
 Err, I think you're mixing up different things. 


 How should portage be 
 able to do sane cross compiling if you control the instruction sets 
 through use flags which are blocked in profiles the build system is 
 using? 

That is not the case anymore.. See PORTAGE_CONFIGROOT= and the
attachment as an example which solves this exact problem.

-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
export PORTDIR=$(portageq envvar PORTDIR)
export ROOT=/dev/shm/blah
export PORTAGE_CONFIGROOT=${ROOT}
PROFILES=$(grep ^[a-z,0-9] ${PORTDIR}/profiles/profiles.desc | awk '{print 
$2}' | sort -u)

mkdir -p ${PORTAGE_CONFIGROOT}/etc/
cd ${PORTAGE_CONFIGROOT}/etc/
for p in ${PROFILES}; do
rm -f make.profile
ln -s ../../../../${PORTDIR}/profiles/${p} make.profile
touch make.conf
ls -ld $(readlink -f make.profile)
emerge --info
done


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

2006-07-06 Thread Ned Ludd
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
 Diego 'Flameeyes' Pettenò wrote:
  echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
 
  Thoughts? Comments?
 
 How will you handle non-gcc compilers?

Non gcc compilers have never been supported and probably never will be.

Gentoo uses the GNU Toolchain.

-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Mike Doty

Mike Frysinger wrote:

On Saturday 01 July 2006 02:46, Mike Frysinger wrote:

well it's about that time of the year ... time for nominating
people for the next Gentoo Council


i guess i'll start off some mass nominations of random people off the top of 
my head who i think would do a good job ... there's a bunch more people i 
think would do a good job, but i'm going to cut my list short as it's already 
ridiculously long ...


from current council:
koon / agriffis / azarah / seemant / solar

some other peeps:
Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / 
jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg


i'd also nominate g2boojum, but i kind of like his current unofficial role as 
honorary council adviser guy ...

-mike


Vote Taco!

If elected, I promise to add 2 minutes to nap time every Friday and 
double juice boxes every third Wednesday of the month.

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] IMPORTANT: bugs performance issues

2006-07-06 Thread Josh Saddler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lance Albertson wrote:
 All-
 
 Just thought I'd update you on some of issue's we've been having with
 bugzilla.g.o lately. Yes, its been slow in the last few months, but
 today has been even slower than normal. The primary reason being another
 large OSS project's database was added to the same server which appeared
 to cause a larger load than the OSL had expected. I have notified the
 OSL about the issue and they are working on bringing up another server
 to handle the load. I don't expect this to be done till tomorrow or the
 day after that so please be patient.
 
 On the plus side, thanks to the generosity of one of our great sponsors,
 GNI [1], we should be getting a cluster of blade servers in the next
 week or so to help with the on going bugzilla issues. I hope to finally
 get this resolved soon as its annoying me as well.
 
 Please thank GNI for helping us out! They really deserve a lot for
 helping us :).
 
 Thanks-
 
 [1] http://www.gni.com/
 
Thankya! Done. I sent a thank-you to [EMAIL PROTECTED], so hopefully they'll 
see it. :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFErS/DrsJQqN81j74RAiOHAJwOwwlDzdnqvwN8eJ1BHz5Yg3ILTwCgjNy6
oY9Xtie0+1bilnbe2IE2Y4s=
=L3LD
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Donnie Berkholz
Ned Ludd wrote:
 On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
 Diego 'Flameeyes' Pettenò wrote:
 echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
 Thoughts? Comments?
 How will you handle non-gcc compilers?
 
 Non gcc compilers have never been supported and probably never will be.

Neither has USE=-*, but we don't actively try to break it. =) As long as
this doesn't cause all non-gcc compilers to immediately die, I don't
care if they miss out on auto-mmx or whatever.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


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

2006-07-06 Thread Thierry Carrez
Mike Frysinger wrote:

 i guess i'll start off some mass nominations of random people off the top of 
 my head who i think would do a good job ... there's a bunch more people i 
 think would do a good job, but i'm going to cut my list short as it's already 
 ridiculously long ...
 
 from current council:
 koon / agriffis / azarah / seemant / solar

Thanks for the nomination, but I can't accept it. I don't have enough
time to devote to Gentoo those days so I can't commit to following
all/most discussion subjects for the Council job for another year. Maybe
sometime in the future ?

There are plenty of good/better candidates out there. I second the
nominations for plasmaroo, jaervosz, Kugelfang and Weeve.

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



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

2006-07-06 Thread Luca Barbato
Diego 'Flameeyes' Pettenò wrote:
 So, I've been drafting this up in my blog[1], and it is a simple way to 
 replace the CPU feature useflags.

My counterproposal:

- keep the useflags
- add an eclass with the guessing logic from gcc
- add an useflag to let people decide the priority between gcc decisions
or useflag decisions.

So:

- don't have to wait for per package cflags

- have the hopefully best results if you don't really care (gcc guess)

- if you care do whatever you want, eg: turn cflags for vector units AND
autovectorized and shut down hand vectorized code (yes it could be dump
if the handmade stuff isn't wrong)

Sounds fair or I'm missing something?

-- 

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

2006-07-06 Thread Kevin F. Quinn
Had a rough scan through the tree; there are 73 packages that make
direct use of mmx, sse*, 3dnow or altivec in IUSE (list below),
excluding gcc itself. They also appear in the mythtv-plugin eclass
so presumably some of media-plugins/myth* (11 packages) are also
affected.

I don't know if altivec is as clearly determined from the target arch;
perhaps the ppc people could chime in.

Clearly most are in media-* categories, so that would be a good place
to start :)

app-crypt/johntheripper
dev-lang/pike
dev-lang/squeak
dev-libs/DirectFB
dev-libs/DirectFB-extra
dev-php5/eaccelerator
games-emulation/dgen-sdl
games-emulation/visualboyadvance
games-emulation/xmame
games-emulation/xmess
games-engines/exult
media-gfx/gimp
media-gfx/inkscape
media-gfx/optipng
media-libs/allegro
media-libs/flac
media-libs/gdk-pixbuf
media-libs/imlib2
media-libs/libfame
media-libs/libggi
media-libs/libmovtar
media-libs/libmpeg3
media-libs/libquicktime
media-libs/mlt
media-libs/sdl-gfx
media-libs/smpeg
media-libs/speex
media-libs/xvid
media-plugins/eq-xmms
media-plugins/vdr-softdevice
media-plugins/xmms-mpg123
media-sound/ardour
media-sound/audacious
media-sound/fluidsynth
media-sound/jack-audio-connection-kit
media-sound/mpg123
media-sound/noxmms
media-sound/terminatorx
media-sound/xmms
media-sound/zynaddsubfx
media-tv/mythtv
media-tv/xawtv
media-tv/xdtv
media-video/avidemux
media-video/cinelerra-cvs
media-video/dirac
media-video/dxr3player
media-video/effectv
media-video/fame
media-video/ffmpeg
media-video/gephex
media-video/mjpegtools
media-video/mpeg4ip
media-video/mplayer
media-video/ogle
media-video/recmpeg
media-video/transcode
media-video/vlc
media-video/xmovie
net-irc/xchat
net-irc/xchat-gnome
net-misc/asterisk
sci-chemistry/gromacs
sci-libs/acml
sci-libs/fftw
x11-base/xorg-x11
x11-libs/evas
x11-libs/libast
x11-misc/rss-glx
x11-terms/eterm
x11-themes/polymer
x11-wm/afterstep
x11-wm/metisse

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
 Well, you're assuming that
Properly listing, what an arcane science.

 a) everyone's using a C compiler,
No, I assume that everyone is using a compiler. You cannot have a C++ compiler 
without a C compiler. The first person I see that sets CXXFLAGS but not 
CFLAGS I'm personally going to give him the doesn't have a clue prize.

 b) that gcc has the slightest clue what it's doing,
No, I assume that gcc has a big clue about which capabilities are available to 
the -march switch. I might be assuming that users have a clue on what they 
are doing, but that's an assumption I do have to do, or I shouldn't be 
working on Gentoo but on Debian, which seems pretty good at optimising for 
i386 still.

 c) that the user has no problem using nasty hacks to regain control,
Where regain control is doing something that could have done before but 
made actually no sense to do before. And the bashrc thing is not a big nasty 
hack, works quite well for me.

 d) that this information is only needed at compile time,
Well of course use flags are available at runtime for the packages built to 
know, this is perfectly logic of you.

You really was getting out of arguments, don't you?

If I have to enable a configure switch I need it only at buildtime. If it has 
to be known at runtime there's the cpuid function!

 e) that various gcc internal definitions won't change... 
It's like assuming that gcc will always output the correct hello world for

int main() {
printf(Hello, world!\n);
return 0;
}

If it does change those values, it's going to be a killer for way more than 
just Portage.

 You're adding a lot of complexity, and thus 
 room for very weird breakages, to something that doesn't need it.
You're not exposing any of such breakages, I find it to reduce complexity to 
users that cannot try to enable SSE3 on an Athlon-TBird system.

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


pgpBazG9uNTou.pgp
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 17:33, Ned Ludd wrote:
 I tend to agree this might be a cleaner approach vs having to edit 
 redit CFLAGS all over the place.
Really if one has to disable mmx support in one package, it should be disabled 
altogether, in the real world we're all in, mmx useflag is enabled by the 
vast majority of our users.

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


pgpiOpxvI3HJS.pgp
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 18:02, Luca Barbato wrote:
 - if you care do whatever you want, eg: turn cflags for vector units AND
 autovectorized and shut down hand vectorized code (yes it could be dump
 if the handmade stuff isn't wrong)
In the case you need to shut down the hand vectorised code, it has to be done 
always, not selected by users. It should be transparent for them, and if the 
code is wrong, just punt it entirely. Or fix it, your call.

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


pgppcbVBjcpSV.pgp
Description: PGP signature


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

2006-07-06 Thread Ned Ludd
On Thu, 2006-07-06 at 18:44 +0200, Diego 'Flameeyes' Pettenò wrote:
 On Thursday 06 July 2006 17:33, Ned Ludd wrote:
  I tend to agree this might be a cleaner approach vs having to edit 
  redit CFLAGS all over the place.


 Really if one has to disable mmx support in one package, it should be 
 disabled 
 altogether, in the real world we're all in, mmx useflag is enabled by the 
 vast majority of our users.

All together as in across the board? Or simply for the 1 pkg 
in question?

I seriously hope you are not suggesting across the board cuz that 
would make me laugh at you for a good hour solid.


-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Luca Barbato
Kevin F. Quinn wrote:
 Had a rough scan through the tree; there are 73 packages that make
 direct use of mmx, sse*, 3dnow or altivec in IUSE (list below),
 excluding gcc itself. They also appear in the mythtv-plugin eclass
 so presumably some of media-plugins/myth* (11 packages) are also
 affected.
 
 I don't know if altivec is as clearly determined from the target arch;
 perhaps the ppc people could chime in.

it is

 
 Clearly most are in media-* categories, so that would be a good place
 to start :)
 

yes

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

2006-07-06 Thread Luca Barbato
Diego 'Flameeyes' Pettenò wrote:
 On Thursday 06 July 2006 17:33, Ned Ludd wrote:
 I tend to agree this might be a cleaner approach vs having to edit 
 redit CFLAGS all over the place.
 Really if one has to disable mmx support in one package, it should be 
 disabled 
 altogether, in the real world we're all in, mmx useflag is enabled by the 
 vast majority of our users.
 

Depending on who wrote the altivec part of a program you may like to
disable it since works just on macosx

/me still would rather have both systems in place.

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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 18:58, Ned Ludd wrote:
 All together as in across the board? Or simply for the 1 pkg
 in question?
For the package in question of course. Do you think I'm an idiot? Seriously?

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


pgpTaMpZzqze8.pgp
Description: PGP signature


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

2006-07-06 Thread Ryan Tandy

Mike Doty wrote:


Vote Taco!

If elected, I promise to add 2 minutes to nap time every Friday and 
double juice boxes every third Wednesday of the month.


WTF!

I want to be a dev if there's juice boxes involved!

*runs off to take the ebuild quiz*
--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ned Ludd
On Thu, 2006-07-06 at 19:09 +0200, Diego 'Flameeyes' Pettenò wrote:
 On Thursday 06 July 2006 18:58, Ned Ludd wrote:
  All together as in across the board? Or simply for the 1 pkg
  in question?
 For the package in question of course. Do you think I'm an idiot? Seriously?

Well. Sorry but there is very little we can assume these days.
Just when you think people know what they are doing along comes 
some hair brained idea that sound ok on the surface but can cause lots 
of fun problems.


-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] IMPORTANT: bugs performance issues

2006-07-06 Thread Joshua Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thank you to all of our sponsors and especially GNI for being so
gracious and giving to us.

Not even a little tiny bit of compiling? A smidge? pretty please with
a cherry on top?

 Yay, *plop* !!! (And no, tsunam - no compiling there :P)



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

iD8DBQFErUohSENan+PfizARAtGqAJ9du+4mdXYqEyjTmn5u4cwMyfWHVQCffhhn
LSd4QYOi4AeiJWkYPgDgA5I=
=W5ou
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 18:43:11 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
|  Well, you're assuming that
| Properly listing, what an arcane science.

Perhaps I should've written a Java + XML app that automatically formats
messages according to what the reader probably wants to see.
 
|  a) everyone's using a C compiler,
|
| No, I assume that everyone is using a compiler. You cannot have a C++
| compiler without a C compiler. The first person I see that sets
| CXXFLAGS but not CFLAGS I'm personally going to give him the doesn't
| have a clue prize.

And for a single compile?

|  b) that gcc has the slightest clue what it's doing,
|
| No, I assume that gcc has a big clue about which capabilities are
| available to the -march switch. I might be assuming that users have a
| clue on what they are doing, but that's an assumption I do have to
| do, or I shouldn't be working on Gentoo but on Debian, which seems
| pretty good at optimising for i386 still.

And your assumption would be wrong. I can assure you that relying upon
-march doing anything sensible with __MAGIC__ is entirely unsafe. Go
and look at the VIS handling if you want a perfect example.
 
|  c) that the user has no problem using nasty hacks to regain control,
|
| Where regain control is doing something that could have done
| before but made actually no sense to do before. And the bashrc thing
| is not a big nasty hack, works quite well for me.

No no. Where regain control means the user has to screw around with
nasty hacks and pray, rather than setting a well defined, specific
variable.

|  d) that this information is only needed at compile time,
|
| Well of course use flags are available at runtime for the packages
| built to know, this is perfectly logic of you.

Uh. USE flags are available at DEPEND time.

| You really was getting out of arguments, don't you?

No, you're just not thinking this through.

| If I have to enable a configure switch I need it only at buildtime.
| If it has to be known at runtime there's the cpuid function!

And at the metadata phase?

|  e) that various gcc internal definitions won't change... 
| It's like assuming that gcc will always output the correct hello
| world for
| 
| int main() {
|   printf(Hello, world!\n);
|   return 0;
| }
| 
| If it does change those values, it's going to be a killer for way
| more than just Portage.

Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
It can and does change with different GCC releases. I know there've been
GCC changes on sparc to those kinds of defines to try to play nice with
certain other compilers...

|  You're adding a lot of complexity, and thus 
|  room for very weird breakages, to something that doesn't need it.
|
| You're not exposing any of such breakages, I find it to reduce
| complexity to users that cannot try to enable SSE3 on an Athlon-TBird
| system.
 
You're trying to guess what the user wants based upon hairy magic,
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?), and all because you aren't aware
of how to cross compile correctly.

Now, please go back to justifying this thing on any merits it may have,
rather than playing the Go and use Debian!!!! card.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
 And for a single compile?
I always leave the two of them in sync, even C++ apps might have parts 
building CFLAGS. In case you know you're going to use only C++ is not 
difficult to use

CFLAGS=${CXXFLAGS} has_cpuset 3dnow

don't you think?

 And your assumption would be wrong. I can assure you that relying upon
 -march doing anything sensible with __MAGIC__ is entirely unsafe. Go
 and look at the VIS handling if you want a perfect example.
Okay, maybe VIS handling is broken. But we can rely pretty safely on x86, 
amd64 and PPC gcc to know the table of arches and extensions supported. 
Remember that I asked to talk with SPARC team for VIS just because I only 
know about the other three arches.

 No no. Where regain control means the user has to screw around with
 nasty hacks and pray, rather than setting a well defined, specific
 variable.
Find me a reason to do that, a part for broken MMX code that should be 
disabled on the ebuild itself already.

 Uh. USE flags are available at DEPEND time.
If you talk about the nasm dependency, then it is rare, most of the MMX 
support is inline in C sources anyway.

 And at the metadata phase?
Should be already transparent or something is strange. nasm is simpler to add 
the dependency for x86, there is really few people not enabling mmx already. 
Yes it is a bit of regression, but for a small percentage of users, while 
there's more safety for many other people.

 Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
This ain't no magic. The magic is in the _CODE_ that GCC creates, but not in 
the _DEFINES_ that GCC emits.

 You're trying to guess what the user wants based upon hairy magic,
No, about their chosen architecture.

 rather than doing what the user says (aren't you always yelling at
 upstreams for doing that?)
The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, 3dnowex, 
sse, sse2)
The user asks for G3 support? They get G3 (nothing)
The user asks for Pentium4 support? They get what they want (mmx, sse, sse2, 
sse3 in case)

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


pgpEMEE1Ith5N.pgp
Description: PGP signature


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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 20:07:00 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
|  And for a single compile?
|
| I always leave the two of them in sync, even C++ apps might have
| parts building CFLAGS. In case you know you're going to use only C++
| is not difficult to use
| 
| CFLAGS=${CXXFLAGS} has_cpuset 3dnow
| 
| don't you think?

Ah yes, yet more added complexity that's going to be forgotten and that
will lead to weird breakages.

Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
you want your C compiler to work and produce vaguely sane code.

|  And your assumption would be wrong. I can assure you that relying
|  upon -march doing anything sensible with __MAGIC__ is entirely
|  unsafe. Go and look at the VIS handling if you want a perfect
|  example.
|
| Okay, maybe VIS handling is broken. But we can rely pretty safely on
| x86, amd64 and PPC gcc to know the table of arches and extensions
| supported. Remember that I asked to talk with SPARC team for VIS just
| because I only know about the other three arches.

Not really. The __MAGIC__ is subject to change whenever any GCC person
feels like it. It also doesn't work in cases where people have one of
those nasty corner case CPUs (such as the 4m, which is not an m and not
really a 4 either, or the USIV, or the r8k) that's best off with a weird
march.

|  No no. Where regain control means the user has to screw around
|  with nasty hacks and pray, rather than setting a well defined,
|  specific variable.
|
| Find me a reason to do that, a part for broken MMX code that should
| be disabled on the ebuild itself already.

Well that's kinda the point. Since ebuild developers don't have access
to every kind of CPU, relying upon the ebuilds getting it right isn't a
very good idea.

|  Uh. USE flags are available at DEPEND time.
|
| If you talk about the nasm dependency, then it is rare, most of the
| MMX support is inline in C sources anyway.

'most'?
 
|  And at the metadata phase?
|
| Should be already transparent or something is strange. nasm is
| simpler to add the dependency for x86, there is really few people not
| enabling mmx already. Yes it is a bit of regression, but for a small
| percentage of users, while there's more safety for many other people.

Since when was Gentoo about covering up for idiots who can't get their
ricing correct at the expense of those who know what they're doing?
 
|  Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the
|  contrary.
|
| This ain't no magic. The magic is in the _CODE_ that GCC creates, but
| not in the _DEFINES_ that GCC emits.

Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
them around now and again for compatibility with other compilers.
 
|  You're trying to guess what the user wants based upon hairy magic,
| No, about their chosen architecture.
| 
|  rather than doing what the user says (aren't you always yelling at
|  upstreams for doing that?)
|
| The user asks for athlon64 support? They get athlon64 (mmx, 3dnow,
| 3dnowex, sse, sse2)
| The user asks for G3 support? They get G3 (nothing)
| The user asks for Pentium4 support? They get what they want (mmx,
| sse, sse2, sse3 in case)
 
Setting CFLAGS and praying is not asking for something. Setting a
MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Grant Goodyear
Vapier wrote: [Tue Jul 04 2006, 02:04:38PM CDT]
 i'd also nominate g2boojum, but i kind of like his current unofficial
 role as honorary council adviser guy ...

*Grin*  I'm rather fond of that role myself, so I cheerfully accept the
non-nomination.  (Also, I plan to run for trustee again, which is more
than enough administrative annoyance all by itself.)

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpovh6Vp5JnS.pgp
Description: PGP signature


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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 20:42:27 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
|  Not really. The __MAGIC__ is subject to change whenever any GCC
|  person feels like it.
|
| It's not magic. But if you think that going by that trick you can
| magically turn me in agreeing with you, good luck.

They're a bunch of arbitrary somethings that may or may not be defined
based upon whatever upstream feels like doing to the compiler this
week. It's not like the behaviour of your hello world app, which is
defined by international standards.
 
|  It also doesn't work in cases where people have one of 
|  those nasty corner case CPUs (such as the 4m, which is not an m and
|  not really a 4 either, or the USIV, or the r8k) that's best off
|  with a weird march.
|
| That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are
| for.

Which is a horrible hack, and far less elegant than just having a
frickin' variable telling ebuilds what to do.
 
|  Well that's kinda the point. Since ebuild developers don't have
|  access to every kind of CPU, relying upon the ebuilds getting it
|  right isn't a very good idea.
|
| The MMX code either works or don't. Not much to think about different
| CPUs.

And in cases where the choice is an SSE routine or an MMX routine or a
C routine? It's not very likely that all possibilities will get tested
by ebuild devs.
 
|  Since when was Gentoo about covering up for idiots who can't get
|  their ricing correct at the expense of those who know what they're
|  doing?
|
| Again, I don't see any loss for who knows what he's doing.

Because you carefully snipped it out of your reply. You said yourself
that it's a regression.
 
|  Sure it's magic. The __DEFINES__ aren't reliable. The GCC people
|  change them around now and again for compatibility with other
|  compilers.
|
| Yeah _some_ of them are unreliable. Not those tho, as they are just
| the same on all the GCC we support. And I doubt that next week GCC
| 4.1.2 changes them around.

Oh, you doubt, do you? Very reassuring.
 
|  Setting CFLAGS and praying is not asking for something. Setting a
|  MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
|
| And if you know what your CPU does, is it that difficult to tell the
| compiler to use them?
 
Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one
remembers that for years we've been screaming at users for doing just
that.

CFLAGS is not a variable that should be used to control things. It has
a specific purpose, which is providing flags to the compiler that
should be used when compiling C programs. You're trying to give it a
new unrelated meaning. This is bad even if it were not for all the
nasty side cases and added complexity.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Harald van Dijk
On Thu, Jul 06, 2006 at 02:21:43PM +0200, Diego 'Flameeyes' Pettenò wrote:
 On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
  Well, there are enough in the tree
 There are ebuilds for non-gcc compilers. There's no support in using them for 
 anything like building stuff. Let's think to all the append-flags there are 
 in the tree.

`append-flags $(test-flags ...)` can be used instead, if the options are
gcc-specific, and I have done that myself in a case where every
supported GCC version supported the specific option. (-fpermissive was
the one.)

 This is not going to make the support any less working. There's 
 no project maintaining support for icc and the like.

When the answer is make icc not suck even when it is capable of
compiling mostly any package if the portage tree would not assume gcc,
that's not going to happen. First, alternative compilers must be
accepted (even when not supported) by package maintainers, and only then
might they ever become supported.

  that you should at least make sure 
  they don't completely break and error out when passing them invalid
  flags, 
 Uhm, If you look at the function itself you can see that I drop the stderr 
 output and I just care about the other part. The flags used are the ones set 
 by the user with the exclusion of -E -dM that are, afaik, standard unix 
 compiler options like -c and -o..

-E is a standard unix compiler option. -dM isn't. What you could do
instead is `$(tc-getCC) ${CFLAGS} -E - /dev/null 21 EOF
#if !($macro)
#error
#endif
EOF` and check $CC's return value. If $macro is not defined, or is
defined to something like 0, preprocessing won't succeed, and $CC will
return nonzero.

 if the compiler does not support those, 
 it's unlikely it can actually do anything useful in Gentoo.
 And anyway it cannot break, it will just report that no extensions are 
 available.

That's sane behaviour regardless. :)
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Harald van Dijk
On Thu, Jul 06, 2006 at 11:41:26AM -0400, Ned Ludd wrote:
 On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
  Diego 'Flameeyes' Pettenò wrote:
   echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
  
   Thoughts? Comments?
  
  How will you handle non-gcc compilers?
 
 Non gcc compilers have never been supported and probably never will be.
 
 Gentoo uses the GNU Toolchain.

The GNU toolchain is not supported by Gentoo, and in fact gets actively
broken with unsupported command-line options. Only the GNU toolchain as
modified by Gentoo's toolchain guys is supported, unfortunately.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Mike Frysinger
On Wednesday 05 July 2006 04:31, Donnie Berkholz wrote:
 I really appreciate your bringing my name up. But I want to take a year
 to rediscover the reasons I joined Gentoo in the first place and the
 things I joined it to do, so I'm going to decline this for now. Maybe
 next time around. =)

i really hope so
-mike


pgp2vSwi3x4Ca.pgp
Description: PGP signature


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

2006-07-06 Thread Mike Frysinger
On Thursday 06 July 2006 04:45, Martin Schlemmer wrote:
 I would like to refrain from accepting until just before the final
 nominees are put out, as currently my life is pretty much in flux.  If
 possible that is.

sure ... you can wait until the 31st to accept ;)
-mike


pgpAU0QKJ2ClD.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Re: Re: GPL and Source code providing

2006-07-06 Thread Michael Cummings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
 Not really.  There is 0 overhead to *leaving* a source DVD set on the
 store indefinitely.  It is only the creation that requires work.  Once
 it is there, it's there.
 

Probably too off the wall and simpleton for the problem - but what if
the install docs included something like:


To obtain the sources for your new install, please use:

emerge -fDN world

to download all of the sources used to build your stage3  install.


(the presumption being after the unrolling of stage3, they would have to
get the sources anyway to proceed forward, so this would fill the
initial gap...or am I missing something more critical?)


- --

- -o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
- -o()o--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFErWEuq1ztTp5/Ti4RApD4AJwJWWjjsC+VFQu6Ymb0AB73OjSt4gCfR0Cn
H4AczL0jjHozbgGlnJf9Ljo=
=CS7S
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Mike Frysinger
On Thursday 06 July 2006 14:40, Grant Goodyear wrote:
 Vapier wrote: [Tue Jul 04 2006, 02:04:38PM CDT]

  i'd also nominate g2boojum, but i kind of like his current unofficial
  role as honorary council adviser guy ...

 *Grin*  I'm rather fond of that role myself, so I cheerfully accept the
 non-nomination.  (Also, I plan to run for trustee again, which is more
 than enough administrative annoyance all by itself.)

thanks, i sit comfortably knowing you're manning these positions
-mike


pgpL9i3snDRYb.pgp
Description: PGP signature


Re: [gentoo-dev] init.d problem

2006-07-06 Thread Albert Hopkins
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.

-m

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Kevin F. Quinn
On Thu, 6 Jul 2006 21:06:18 +0200
Harald van Dijk [EMAIL PROTECTED] wrote:

 The GNU toolchain is not supported by Gentoo, and in fact gets
 actively broken with unsupported command-line options. Only the GNU
 toolchain as modified by Gentoo's toolchain guys is supported,
 unfortunately.

What exactly is it about the toolchain supplied with Gentoo that causes
you problems?

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-06 Thread Harald van Dijk
On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote:
 On Thu, 6 Jul 2006 21:06:18 +0200
 Harald van Dijk [EMAIL PROTECTED] wrote:
 
  The GNU toolchain is not supported by Gentoo, and in fact gets
  actively broken with unsupported command-line options. Only the GNU
  toolchain as modified by Gentoo's toolchain guys is supported,
  unfortunately.
 
 What exactly is it about the toolchain supplied with Gentoo that causes
 you problems?

I don't have a lot of trust in Gentoo's patches, as they have resulted
in completely and utterly unusable ld, and (minor) data loss due to a
miscompilation by Gentoo's gcc, in the past. Also, being able to check
whether your own software compiles with a GNU toolchain is to me a good
thing.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 21:42:20 +0200 Kevin F. Quinn
[EMAIL PROTECTED] wrote:
| On Thu, 6 Jul 2006 21:06:18 +0200
| Harald van Dijk [EMAIL PROTECTED] wrote:
|  The GNU toolchain is not supported by Gentoo, and in fact gets
|  actively broken with unsupported command-line options. Only the GNU
|  toolchain as modified by Gentoo's toolchain guys is supported,
|  unfortunately.
| 
| What exactly is it about the toolchain supplied with Gentoo that
| causes you problems?

Selective and partial backporting of patches that leads to the C++
standard library code getting broken?

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Curtis Napier
Ciaran McCreesh wrote:
 On Thu, 6 Jul 2006 20:42:27 +0200 Diego 'Flameeyes' Pettenò
  
 |  Setting CFLAGS and praying is not asking for something. Setting a
 |  MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
 |
 | And if you know what your CPU does, is it that difficult to tell the
 | compiler to use them?
  
 Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one
 remembers that for years we've been screaming at users for doing just
 that.
 

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.

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



signature.asc
Description: OpenPGP digital signature


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

2006-07-06 Thread Stephen P. Becker

Harald van Dijk wrote:

On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote:

On Thu, 6 Jul 2006 21:06:18 +0200
Harald van Dijk [EMAIL PROTECTED] wrote:


The GNU toolchain is not supported by Gentoo, and in fact gets
actively broken with unsupported command-line options. Only the GNU
toolchain as modified by Gentoo's toolchain guys is supported,
unfortunately.

What exactly is it about the toolchain supplied with Gentoo that causes
you problems?


I don't have a lot of trust in Gentoo's patches, as they have resulted
in completely and utterly unusable ld, and (minor) data loss due to a
miscompilation by Gentoo's gcc, in the past. Also, being able to check
whether your own software compiles with a GNU toolchain is to me a good
thing.


Isn't this why gcc et al support the vanilla USE flag?

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



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

2006-07-06 Thread Harald van Dijk
On Thu, Jul 06, 2006 at 04:03:26PM -0400, Stephen P. Becker wrote:
 Harald van Dijk wrote:
 On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote:
 On Thu, 6 Jul 2006 21:06:18 +0200
 Harald van Dijk [EMAIL PROTECTED] wrote:
 
 The GNU toolchain is not supported by Gentoo, and in fact gets
 actively broken with unsupported command-line options. Only the GNU
 toolchain as modified by Gentoo's toolchain guys is supported,
 unfortunately.
 What exactly is it about the toolchain supplied with Gentoo that causes
 you problems?
 
 I don't have a lot of trust in Gentoo's patches, as they have resulted
 in completely and utterly unusable ld, and (minor) data loss due to a
 miscompilation by Gentoo's gcc, in the past. Also, being able to check
 whether your own software compiles with a GNU toolchain is to me a good
 thing.
 
 Isn't this why gcc et al support the vanilla USE flag?

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.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 22:02, Curtis Napier wrote:
 Every developer who has ever commented on one of these threads has
 always agreed with that. Put it in USE not CLFAGS.
Well it's not totally right.

Putting them in CFLAGS, when using -march, is redundant, pure and simple.

-march=athlon64 -msse -msse2 -mmmx -m3dnow -m3dnowex
would be equivalent of
-march=athlon64

If you have a new Athlon64 that supports SSE3, using
-march=athlon64 -msse3
is not only legit, but also (in my opinion at least) suggested. GCC can 
improve heavily if it knows what it has to do.

The problem is that people think that using
-march=pentium3 -mmmx
will bring them more acceleration, while this isn't true.

So I would suggest anybody wanting to comment on these issue to know the 
difference of using mmx in useflag and -mmmx in CFLAGS at the moment.
And then evaluate the change in behaviour.


Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most of the 
times, as it's not an i686 but at the same time it has MMX support.

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


pgppXtMqRbnIf.pgp
Description: PGP signature


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

2006-07-06 Thread Stephen Bennett
On Thu, 6 Jul 2006 20:56:31 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 Selective and partial backporting of patches that leads to the C++
 standard library code getting broken?

Obviously not an issue. Noone uses C++ anyway.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 22:13:11 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| So I would suggest anybody wanting to comment on these issue to know
| the difference of using mmx in useflag and -mmmx in CFLAGS at the
| moment. And then evaluate the change in behaviour.

Well, if you're playing that game, I'd suggest that anybody wanting to
make proposals on this issue should know what CFLAGS is and understand
how it is nothing other than a set of flags that are passed to the
compiler when compiling a C program, and then evaluate the impact of
subverting such a variable for nefarious purposes.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Stephen Bennett
On Tue, 4 Jul 2006 15:04:38 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:

 some other peeps:
 Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / 
 jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg

Thanks, accepted.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote:
 Well, if you're playing that game, I'd suggest that anybody wanting to
 make proposals on this issue should know what CFLAGS is and understand
 how it is nothing other than a set of flags that are passed to the
 compiler when compiling a C program, and then evaluate the impact of
 subverting such a variable for nefarious purposes.
And I suggest that anybody willing to comment on user-side of things would 
know what an user is and understand how users feel about issues, instead of 
going on and on and on commenting without having a clue.

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


pgpZvC5MwKfS1.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Re: Re: GPL and Source code providing

2006-07-06 Thread Chris Gianelloni
On Thu, 2006-07-06 at 15:14 -0400, Michael Cummings wrote:
 Probably too off the wall and simpleton for the problem - but what if
 the install docs included something like:
 
 
 To obtain the sources for your new install, please use:
 
 emerge -fDN world
 
 to download all of the sources used to build your stage3  install.
 
 
 (the presumption being after the unrolling of stage3, they would have to
 get the sources anyway to proceed forward, so this would fill the
 initial gap...or am I missing something more critical?)

Well, it would need to be -efDN, but that doesn't take into account what
happens when someone uses a tarball from 2 releases ago that is still on
our mirrors, but the packages haven't been in the tree (and therefore
not on our mirrors) for months.  For the most part, it would work,
provided upstream kept copies of their older sources, but there would
still be source lost, like patches in ${FILESDIR}.  This only works so
long as we have everything either in the tree or on our infrastructure.

A burned DVD, however, will always have the old stuff there, no matter
what happens in the tree.

It really is the simplest method for us.

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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 22:46:31 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote:
|  Well, if you're playing that game, I'd suggest that anybody wanting
|  to make proposals on this issue should know what CFLAGS is and
|  understand how it is nothing other than a set of flags that are
|  passed to the compiler when compiling a C program, and then
|  evaluate the impact of subverting such a variable for nefarious
|  purposes.
|
| And I suggest that anybody willing to comment on user-side of things
| would know what an user is and understand how users feel about
| issues, instead of going on and on and on commenting without having a
| clue.

You're not going to give in gracefully, huh? Ok, I'd like to ask the
council to declare that abusing CFLAGS in the manner proposed in this
thread is a very bad idea.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Kevin F. Quinn
On Thu, 6 Jul 2006 22:13:11 +0200
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

 Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most
 of the times, as it's not an i686 but at the same time it has MMX
 support.

There's -march=pentium-mmx for this.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 23:10, Kevin F. Quinn wrote:
 There's -march=pentium-mmx for this.
I forgot about it, thanks for pointing it out :)

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


pgpzOhSWFVsLH.pgp
Description: PGP signature


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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote:
 You're not going to give in gracefully, huh? Ok, I'd like to ask the
 council to declare that abusing CFLAGS in the manner proposed in this
 thread is a very bad idea.
If you finished the proper arguments, the next one will be that it's all a 
cabal of infra against you, I suppose.

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


pgpjBAukAFhDn.pgp
Description: PGP signature


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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 23:12:51 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote:
|  You're not going to give in gracefully, huh? Ok, I'd like to ask the
|  council to declare that abusing CFLAGS in the manner proposed in
|  this thread is a very bad idea.
|
| If you finished the proper arguments, the next one will be that it's
| all a cabal of infra against you, I suppose.

No, Diego. The argument is that you're coming up with a horrible and
unnecessary hack where there are far cleaner alternatives, and that
you're blindly sticking to it and trying to throw off any objections by
devious means because you don't want to scrap said hack after all the
misguided effort you've spent on it. However, since you seem to be
incapable of admitting the gaping flaws in your own work, I'm asking for
someone else to point this out to you in a formal manner rather than
watch this thread go on for even longer.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Joshua Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Or instead of throwing a hissy fit yourself about diego not agreeing
with you..I don't know you could go and show the way that you feel it
should be done and show the technical merit.  Ciaran I will give you
that you are a capable programmer, and had valid arguments in this
thread. However, when interacting with people and proving points on
merits you seem to go out of your way to not prove anything and throw
examples out there without really backing them up.

 No, Diego. The argument is that you're coming up with a horrible
 and unnecessary hack where there are far cleaner alternatives, and
 that you're blindly sticking to it and trying to throw off any
 objections by devious means because you don't want to scrap said
 hack after all the misguided effort you've spent on it. However,
 since you seem to be incapable of admitting the gaping flaws in
 your own work, I'm asking for someone else to point this out to you
 in a formal manner rather than watch this thread go on for even
 longer.


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

iD8DBQFErYFLSENan+PfizARAjzzAJwIue9UDtwsANxaaqqnVJVr0jTz6ACglAL6
cO7O0Pw+CGDfFlVdY7z1N3o=
=6G6V
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Ciaran McCreesh
Is there any particular reason USE_EXPAND_HIDDEN needs to be in
make.globals, as opposed to in base/make.defaults alongside USE_EXPAND?
Seems to me it'd make more sense were the two kept together...

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Stephen Bennett
On Thu, 06 Jul 2006 14:31:56 -0700
Joshua Jackson [EMAIL PROTECTED] wrote:

 Or instead of throwing a hissy fit yourself about diego not agreeing
 with you..I don't know you could go and show the way that you feel it
 should be done and show the technical merit.  

He already has done.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote:
 No, Diego. The argument is that you're coming up with a horrible and
 unnecessary hack where there are far cleaner alternatives, and that
 you're blindly sticking to it and trying to throw off any objections by
 devious means because you don't want to scrap said hack after all the
 misguided effort you've spent on it. However, since you seem to be
 incapable of admitting the gaping flaws in your own work, I'm asking for
 someone else to point this out to you in a formal manner rather than
 watch this thread go on for even longer.

Wait, isn't that what _you_ usually do? Like climbing up on mirrors when you 
misunderstood something and blamed someone for an error that was never made, 
trying to find another glitch in the procedure to back it up?

Yeah that really sounds like you more than me.

I'm entirely ready to scrap what I have here if I find _valid reasons to_.
All you seem to be able to say is that you don't like this, you point to a 
control that users have not much for a valid reason than for the simple fact 
that the useflag was a good way to allow user to choose what it had without 
forcing it to use support that was not supported on their system. A solution 
that worked, but that is not the only one, and that I wouldn't consider a 
great choice that users really need to be able to use Gentoo.

The most interesting point shown up until now is the one about non-gcc 
compatibility, that I actually thought about for a while, but I thought -dM 
was unix standard option, Harald got me there, and I'll be checking for 
something in ICC.

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


pgpx6QSrOFiRm.pgp
Description: PGP signature


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

2006-07-06 Thread Ciaran McCreesh
On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED]
wrote:
| Or instead of throwing a hissy fit yourself about diego not agreeing
| with you..I don't know you could go and show the way that you feel it
| should be done and show the technical merit.  Ciaran I will give you
| that you are a capable programmer, and had valid arguments in this
| thread. However, when interacting with people and proving points on
| merits you seem to go out of your way to not prove anything and throw
| examples out there without really backing them up.

No, I go out of my way to avoid posting hundred page essays explaining
things that people already know. If there's really anyone reading this
discussion who doesn't understand any of the points being discussed,
they're more than welcome to ask for clarification. However, given how
basic an issue this is, is it really worth wasting everyone's time with
huge explanations of what CFLAGS is?

Come on, do you really think anyone will benefit from another
http://dev.gentoo.org/~blubb/duncan.pdf ?

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


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Replacing einfo with elog

2006-07-06 Thread Marius Mauch
For the impatient reader:
Ebuilds should stop using einfo() for important messages and use elog()
instead.

Rationale:
I assume most of you are already aware of the new elog framework in
portage-2.1 for handling ebuild messages (like sending them by
mail/syslog or just storing them for later review).
This works very well, except that currently if you enable einfo logging
the user will be swamped with many status messages (updating
foo, removing bar) that might be interesting when you watch the build
output but are rather useless once the build is done.
To avoid this information overflow einfo messages aren't logged in the
default portage config, but that means that right now users will only
see ewarn and eerror messages and miss some einfos that might be
important.
To fix this problem a new function elog() was added in portage-2.1 to
close the gap between einfo and ewarn. THe reason this wasn't advertised
until now is that it couldn't be used in the tree as the function didn't
exist for people still on portage-2.0. A few minutes ago I committed the
attached patch to base/profile.bashrc so this is no longer an issue
(for 2.0 users elog is merely an alias to einfo). So from now on please
use elog() for any messages the user should read and use einfo() only
for status/progress messages that have no use once the build is
completed.

I'll get the relevant docs updated in the next days.

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-dev] Replacing einfo with elog

2006-07-06 Thread Marius Mauch
On Thu, 6 Jul 2006 23:51:09 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 A few minutes ago I committed the attached patch to
 base/profile.bashrc so this is no longer an issue (for 2.0 users elog
 is merely an alias to einfo).

*sigh*, gotta get rid of this attachment-eating gremlin someday.
Anyway, patch is available at
dev.gentoo.org/~genone/temp/elog-compat-hack.diff (not that it is
actually important).

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-dev] Replacing cpu-feature USE flags

2006-07-06 Thread Jory A. Pratt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED]
 wrote:
 | Or instead of throwing a hissy fit yourself about diego not agreeing
 | with you..I don't know you could go and show the way that you feel it
 | should be done and show the technical merit.  Ciaran I will give you
 | that you are a capable programmer, and had valid arguments in this
 | thread. However, when interacting with people and proving points on
 | merits you seem to go out of your way to not prove anything and throw
 | examples out there without really backing them up.
 
 No, I go out of my way to avoid posting hundred page essays explaining
 things that people already know. If there's really anyone reading this
 discussion who doesn't understand any of the points being discussed,
 they're more than welcome to ask for clarification. However, given how
 basic an issue this is, is it really worth wasting everyone's time with
 huge explanations of what CFLAGS is?
 
 Come on, do you really think anyone will benefit from another
 http://dev.gentoo.org/~blubb/duncan.pdf ?
 

Stephen Bennett wrote:
 On Thu, 06 Jul 2006 14:31:56 -0700
 Joshua Jackson [EMAIL PROTECTED] wrote:

 Or instead of throwing a hissy fit yourself about diego not agreeing
 with you..I don't know you could go and show the way that you feel it
 should be done and show the technical merit.

 He already has done.


After reading this thread I can see this is just another one of ciaran's
b.s games that Stephen happens to back. My question is just how far up
ciaran's ass does stephen go. I am begining to think we will never get
to the end if ciaran and his bullshit around gentoo, nor will we ever
get rid of stephen's bullshit around gentoo. But the project continues
to allow such non-sence and wonders why devs are still walking away.



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

iD8DBQFErYoRo9V4dnAHxYwRAiq7AJ4+kLNig3h0Ra8k9CuLJynDFBuC+QCgiq/W
BFKmn9FzOXFhWgBt8rSbUdo=
=wTC0
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] init.d problem

2006-07-06 Thread Mike Frysinger
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
-mike


pgpNOzInupUbJ.pgp
Description: PGP signature


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

2006-07-06 Thread Stephen Bennett
On Thu, 06 Jul 2006 17:09:22 -0500
Jory A. Pratt [EMAIL PROTECTED] wrote:

 snip

Leaving aside the incoherent ad-hominem attack, could you please point
out where the bullshit is? If you were referring to my post, I suggest
you re-read Ciaran's first mail to this thread. He outlined at least
two possible alternatives, but everyone seems to have ignored this.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Luca Barbato
Diego 'Flameeyes' Pettenò wrote:
[summary:provide a way to enable simd features by extracting them from
the ones supported by the cflags selected and the compiler]

Pros:
- automagic : you just carefully select your cflags and your apps will
have all the simd goodness you may dream/want/expect.
- less useflags around
- simpler life when building stages (given we gut cpuinfo checks in
configures)

Cons:
- assumes gcc
- per ebuild cflags feat isn't ready yet
- makes less simple to have certain corner case

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.

- have simdflags as use_expand to keep them on a single place and
improve the description

- 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

- as the one before again but with a var to decide if follow the use or
the gcc check.


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

2006-07-06 Thread Curtis Napier
Jory A. Pratt wrote:
 Ciaran McCreesh wrote:
 On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED]
 wrote:
 | Or instead of throwing a hissy fit yourself about diego not agreeing
 | with you..I don't know you could go and show the way that you feel it
 | should be done and show the technical merit.  Ciaran I will give you
 | that you are a capable programmer, and had valid arguments in this
 | thread. However, when interacting with people and proving points on
 | merits you seem to go out of your way to not prove anything and throw
 | examples out there without really backing them up.

 No, I go out of my way to avoid posting hundred page essays explaining
 things that people already know. If there's really anyone reading this
 discussion who doesn't understand any of the points being discussed,
 they're more than welcome to ask for clarification. However, given how
 basic an issue this is, is it really worth wasting everyone's time with
 huge explanations of what CFLAGS is?

 Come on, do you really think anyone will benefit from another
 http://dev.gentoo.org/~blubb/duncan.pdf ?

 
 Stephen Bennett wrote:
 On Thu, 06 Jul 2006 14:31:56 -0700
 Joshua Jackson [EMAIL PROTECTED] wrote:

 Or instead of throwing a hissy fit yourself about diego not agreeing
 with you..I don't know you could go and show the way that you feel it
 should be done and show the technical merit.
 He already has done.
 
 
 After reading this thread I can see this is just another one of ciaran's
 b.s games that Stephen happens to back. My question is just how far up
 ciaran's ass does stephen go. I am begining to think we will never get
 to the end if ciaran and his bullshit around gentoo, nor will we ever
 get rid of stephen's bullshit around gentoo. But the project continues
 to allow such non-sence and wonders why devs are still walking away.
 
 
 

I'm not sticking up for Ciaran, he already made his bed and now he's
laying in it. I'm sticking up for spb who is a damn good dev and doesn't
deserve this kind of bullshit dumped on him.

spb works his ass off for this project and is */ALWAYS/* very
professional. Just look at the past few threads that he has started
where he totally changed his approach based on feedback from everyone
(hell, look at ANY technical discussion that spb has ever had regarding
Gentoo - not just the last few mail threads). He was professional,
listened attentively and made changes based on the feedback that
satisfied everyone involved while still solving the problem at hand.
Sounds like a damn good developer to me. One I would like to see more of
in Gentoo.

spb != ciarnm

Just my two cents for what it's worth.



signature.asc
Description: OpenPGP digital signature


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

2006-07-06 Thread Jason Wever
On Tue, 4 Jul 2006 15:04:38 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:

 i guess i'll start off some mass nominations of random people off the
 top of my head who i think would do a good job ... there's a bunch
 more people i think would do a good job, but i'm going to cut my list
 short as it's already ridiculously long ...

Thanks for the nomination! :)  However I don't feel that I currently
have the time to put towards this that it needs.

Here is hoping towards next year :)

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead


signature.asc
Description: PGP signature


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

2006-07-06 Thread Ciaran McCreesh
On Thu, 6 Jul 2006 23:45:21 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote:
|  No, Diego. The argument is that you're coming up with a horrible and
|  unnecessary hack where there are far cleaner alternatives, and that
|  you're blindly sticking to it and trying to throw off any
|  objections by devious means because you don't want to scrap said
|  hack after all the misguided effort you've spent on it. However,
|  since you seem to be incapable of admitting the gaping flaws in
|  your own work, I'm asking for someone else to point this out to you
|  in a formal manner rather than watch this thread go on for even
|  longer.
| 
| Wait, isn't that what _you_ usually do? Like climbing up on mirrors
| when you misunderstood something and blamed someone for an error that
| was never made, trying to find another glitch in the procedure to
| back it up?

Please try to keep this technical, even if your co-developers can't...

| I'm entirely ready to scrap what I have here if I find _valid reasons
| to_.

What's wrong with the ones you've been given so far? I'll summarise the
ones I consider important:

* it's relying upon non-guaranteed GCC internals.

* it's relying upon GCC knowing the state of the underlying system,
which fails at least for VIS.

* it's removing the ability to get access to the data at the metadata
phase, leading to what you yourself called a regression.

* it's forcing users to use insane CFLAGS hacks, which we've spent years
telling them not to do and for good reason, to get back to previous
behaviour.

* a large part of the justification is based upon a misunderstanding of
how cross compilation should be done. The correct way around this
problem was already posted to the thread by solar.

* it's removing transparency and simplicity and replacing them with
obfuscation and complexity.

* it's taking a variable with a well defined purpose and abusing it for
something unrelated.

Will that lot do or would you like some more?

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Mike Frysinger
On Wednesday 05 July 2006 12:28, Alexandre Buisse wrote:
 Please correct me if I am wrong, but there is no point in nominating
 people multiple times, right?

*shrug* gives a good indication of who you think is competent and/or who has 
the best abs (seemant does btw)
-mike


pgpwmfns69sHU.pgp
Description: PGP signature


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

2006-07-06 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 Is there any particular reason USE_EXPAND_HIDDEN needs to be in
 make.globals, as opposed to in base/make.defaults alongside USE_EXPAND?
 Seems to me it'd make more sense were the two kept together...

Given the support that's currently available in portage, that seems like a good 
move to my.  However, I've been thinking about proposing the addition of 
support for things like $PORTDIR/profiles/{make.defaults,bashrc,package.use} as 
part of a repo level profile.  These would be a logical extension of the 
support that already exists for $PORTDIR/profiles/package.mask.  But anyway, 
base/make.defaults makes sense for now.

Zac

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFErZxp/ejvha5XGaMRAvw4AKCiNolBORuKxOhptk6THRqG8PrmkwCgwCVt
hjybF1i7x/ymSkKx7QbxyEg=
=kziC
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-06 Thread Molle Bestefich

Dont snip.  The relevant part comes *after* the blocks lines.


Aah.  I get it.  Thanks.
Sorry for the noise.


 www-client/seamonkey (is blocking www-client/mozilla-1.7.13)

Also, you are mis-interpreting the blocks lines.  The correct
reading of X (is blocking Y) is that you have (or should have)
X installed, and now portage wants to install Y instead.
Usually this is because Y supercedes the functionality that used
to be provided by X, and  in almost all cases, the right thing
to do is to unmerge X and merge Y.


Evolution depends on Mozilla and Mono depends on SeaMonkey.  Mono is
the newer (actively developed... sort of) component, also, from what
I've heard, SeaMonkey is based on a vastly newer version of Gecko.  So
I'm not sure how that fits with the above.

Anyway, I tried unmerging SeaMonkey and merging Mozilla, which went fine.
Doesn't help any with the blocker status, though.

So I'm stuck here.
Is it impossible to have Mono and Evolution installed at the same time?

(Same story with OpenSSH and pam-login.  OpenSSH wants shadow, and
pam-login refuses to merge alongside shadow.  I want both pam-login
and OpenSSH, but seems like I'll have to choose, right?)
--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Mike Frysinger
i'll be keeping track of nominations here:
http://dev.gentoo.org/~vapier/council-2006-nominees.html
lemme know if i missed one of you suckers

yes it's very basic, when i get a min i'll guide-xml it :P
-mike


pgphwOfWz2WSL.pgp
Description: PGP signature


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

2006-07-06 Thread Richard Fish

On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
the tree, almost never used to get new dependencies, but usually used to
supply econf switches.


Hoping the S/N ratio here hasn't gotten too high...

IMO the main purpose of USE flags should be econf switches.  Pulling
in dependancies should be viewed as more of a side-effect, even if a
common one.  If the user wants ./configure ... --enable-gtk, then
they need gtk on their box.

Similarly, the mmx,sse,3dnow,etc useflags should be there for econf
switches, not additions to CFLAGS.  If the autoconf script has an
--enable-mmx option, then the proper way to control that is through a
useflag.

I don't object to ebuilds adding CFLAGS/CXXFLAGS based on the result
of your has_cpuset (for example, --fpmath= could be useful), but I
don't believe has_cpuset should be used to set econf switches.

And users should absolutely not have to muck with bashrc to disable
this.  Add a FEATURE, or something, to enable/disable it if necessary.

-Richard

--
gentoo-dev@gentoo.org mailing list



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

2006-07-06 Thread Diego 'Flameeyes' Pettenò
On Friday 07 July 2006 01:16, Ciaran McCreesh wrote:
 Please try to keep this technical, even if your co-developers can't...
You started this.

 * it's relying upon non-guaranteed GCC internals.
Not that internals, that part is guaranteed to work, or we cannot consider 
guaranteed __PIC__ either, and we rely on that heavily.

 * it's relying upon GCC knowing the state of the underlying system,
 which fails at least for VIS.
Define state of underlying system because that is not a complete definition. 
This is not a state machine we're talking about, and we're not in science 
class.

 * it's removing the ability to get access to the data at the metadata
 phase, leading to what you yourself called a regression.
Yes, a little regression. That's what procons consideration are needed for 
after all.

 * it's forcing users to use insane CFLAGS hacks, which we've spent years
 telling them not to do and for good reason, to get back to previous
 behaviour.
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.

I would _not_ ask someone why he's using -mno-mmx for instance, but I _will_ 
tell someone using

-march=athlon64 -mmmx -msse -msse2 -m3dnow -m3dnowex

that he's not doing anything useful.
Kinda like I do to people who uses -Wl,--enable-new-dtags [1]

 * a large part of the justification is based upon a misunderstanding of
 how cross compilation should be done. The correct way around this
 problem was already posted to the thread by solar.
No I'm not misunderstand how cross compilation should be done with a package 
manager. I'm saying that this will anyway give a hand to that. What I was 
referring to mostly comes down to the fact that, if I want to build a bin 
package for amd64 nocona arch, right now I am not guaranteed that setting 
CFLAGS to -march=nocona will produce the right result.

 * it's removing transparency and simplicity and replacing them with
 obfuscation and complexity.
It's removing green and yellow and adding black and white.
Your words are useless unless you explain them.

 * it's taking a variable with a well defined purpose and abusing it for
 something unrelated.
No it is not. Want to get the news? People at binutils were discussing about 
adding -march support to gas, so that it would refuse to build asm sources 
that contains instructions not supported by the -march value passed.
So using -march=i586 with mmx useflag wouldn't work anymore.

It does make sense to them and it does to me too.

 Will that lot do or would you like some more?
You have the innate ability to find more arguments when the ones you brought 
on are not accepted.

For what concerns me, I brought the idea, I find the single regression 
acceptable, I find it a proper usage of $CFLAGS variable, I find the 
internals guaranteed enough to work. My work is done here, I leave to anybody 
else to say what they think, as it seems I'm not the only one thinking this 
is a good idea.

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/22/nonsensical-hacks-why-i-find-kdenewldflags-stupid
-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpyJw1w2B75S.pgp
Description: PGP signature


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

2006-07-06 Thread Mike Frysinger
On Thursday 06 July 2006 15:56, Ciaran McCreesh wrote:
 Selective and partial backporting of patches that leads to the C++
 standard library code getting broken?

that patch was picked up by more than just Gentoo and then just as summarily 
punted
-mike


pgpmw8k1Bgvxk.pgp
Description: PGP signature


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

2006-07-06 Thread Mike Frysinger
On Thursday 06 July 2006 15:55, Harald van Dijk wrote:
 I don't have a lot of trust in Gentoo's patches, as they have resulted
 in completely and utterly unusable ld, and (minor) data loss due to a
 miscompilation by Gentoo's gcc, in the past.

historically i'd agree with you but i'm pretty confident that this has gotten 
a ton better with 3.3.6 / 3.4.6 / 4.0.3 / 4.1.1

 Also, being able to check 
 whether your own software compiles with a GNU toolchain is to me a good
 thing.

USE=vanilla
-mike


pgpq09DVaZYre.pgp
Description: PGP signature


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

2006-07-06 Thread Mike Frysinger
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 ... 
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+
-mike


pgpIF6VkHyicH.pgp
Description: PGP signature


  1   2   >