On 7/7/06, Seemant Kulleen [EMAIL PROTECTED] wrote:
I think the Council idea is great. However, I think
the Council should be charged with a little bit of direction-setting and
leadership as well.
[...]
1. The council was (by design?) a reactive force, rather than a
pro-active force.
[...]
On 7/7/06, Steve Dibb [EMAIL PROTECTED] wrote:
If your blog is being aggregated on Planet Gentoo / Universe, it's time to send
us a copy of your smiling face. I'm putting out a request for some
hackergotchis. Really, you don't want just a few of us to have all the fun, do
you?
Any chance of
Stuart Herbert wrote:
Any chance of you updating the template so that the heads don't look
quite so naff? They're a bit of an afterthought atm, and it shows.
I agree, http://planet.gnome.org/ looks so much nicer ;-)
--
Sebastian Bergmann
On Thu, 2006-07-06 at 18:18 -0400, Mike Frysinger wrote:
On Thursday 06 July 2006 15:27, Albert Hopkins wrote:
On Tue, 2006-07-04 at 18:58 -0400, Mike Frysinger wrote:
On Tuesday 04 July 2006 18:43, Enrico Weigelt wrote:
We should think about mechanisms to check if the service is
Curtis Napier wrote:
I could find a million threads in the forums supporting what Ciaran is
saying here. We have been told over and over and over until my head
feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT
IS WHAT USE FLAGS ARE FOR
Every developer who has ever
Luca Barbato wrote:
Alternatives:
- as PPC we provide a default cflags use tuned per certain cpu
families using profiles, amd64 could provide a nocona profile that bans
3dnow* useflags.
Not really. There are athlon64s and opterons with and without sse3 support. The
users who have an
On Tue, 2006-07-04 at 19:40 -0400, Curtis Napier wrote:
Two names I see missing from this (otherwise very good) list are Chris
Gianelloni (wolf31o2) and Donnie Berkholz (spyderous aka dberkholz). I
think everyone knows exactly how much work these two put into Gentoo and
how valuable that
* Luca Barbato [EMAIL PROTECTED] [06/07/07 02:13 +0200]:
I'd add to the pot pvdabeel and pylon since was and still is a pleasure
working with them =)
I accept the nomination. But I can't add more nominees as
all my favorites for the council have been named already ;)
On the other hand, this
Simon Stelling wrote:
Luca Barbato wrote:
Alternatives:
- as PPC we provide a default cflags use tuned per certain cpu
families using profiles, amd64 could provide a nocona profile that bans
3dnow* useflags.
Not really. There are athlon64s and opterons with and without sse3 support.
On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
| No, we never spent years telling them not to use your so-called
| CFLAGS hacks that are rather a proper usage of what the compiler
| gives you.
Wrong. We did.
Then
On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
| No, we never spent years telling them not to use your so-called
| CFLAGS hacks that are rather a
On Fri, 2006-07-07 at 04:28 +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 07 July 2006 03:15, Mike Frysinger wrote:
x86_64 toolchain accepting 3dnow on a nocona arch? :)
that isnt a cross-compile nor a different architecture
This is the whole point of my solution.
From what you
On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote:
On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
| No, we never spent years telling them not
Martin Schlemmer [EMAIL PROTECTED] writes:
Stupid question though ... does the gcc test thingy list __3dNOW__ on
nocona ? I would think that it does, as there is no -march=nocona (or
whatever) yet.
There is an -march=nocona (which I think was introduced in gcc 3.4)
which works for both 32bit
On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote:
The more I think about the issue and the more I like the complete
profiles for amd64 more than the other solutions.
I don't even *want* to think of what this would be for x86.
These are what I can think of, so far, with regards to
Chris Gianelloni wrote:
[snip]
This means it is now 36 profiles to support, if we dropped support on
all profiles except for the new ones. Without having any sort of
multiple inheritance available, this is really unmanageable.
This is exactly the same reason why amd64 won't move to a per
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Schweizer wrote:
Mike Frysinger wrote:
- only Gentoo devs may be nominated
with that limitation in mind I want to propose some developers that are
doing a lot of work to improve gentoo:
antarus for his treecleaners work
I appreciate
On Fri, 07 Jul 2006 13:13:09 +0200
Simon Stelling [EMAIL PROTECTED] wrote:
Curtis Napier wrote:
I could find a million threads in the forums supporting what Ciaran
is saying here. We have been told over and over and over until my
head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT
On Fri, 7 Jul 2006 07:46:16 +0200
Harald van Dijk [EMAIL PROTECTED] wrote:
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
Gentoo's gcc with the vanilla flag isn't the official GCC. Most
patches don't get appplied, but
Marius Mauch wrote:
That's because CFLAGS=-msse currently doesn't do what the user
would think it does. Which is the real problem, which we're solving
with the change Diego suggested.
Huh? What do you assume users think that CFLAGS=-msse does?
I know some people get confused by the
On Friday 07 July 2006 15:53, Martin Schlemmer wrote:
Check Chris Gianelloni's mail just now. For some compilers with some
-march's on x86 it did not explicitly turn on some features (or maybe
not to such a high extend).
Uh no, I think he meant that for some borderline processors there's not
OK, this rfc/proposal is competing with Flameeye's proposal:
I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
This should be set to sane defaults in the profiles. I.e. for x86,
it should not set CPUFLAGS at all, and on AMD64 it should be
CPUFLAGS=mmx sse sse2
I'm no quite sure, but
On Friday 07 July 2006 16:20, Danny van Dyk wrote:
I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
Improvement respect the current situation? You're just asking for the same
exact treatment that is in place now, but changing its name like it is a
change...
--
Diego Flameeyes
Danny van Dyk wrote:
OK, this rfc/proposal is competing with Flameeye's proposal:
I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
Name it SIMD or CPUFEAT to avoid misunderstanding with the other *FLAGS
This should be set to sane defaults in the profiles. I.e. for x86,
it
Am Freitag, 7. Juli 2006 16:19 schrieb Diego 'Flameeyes' Pettenò:
On Friday 07 July 2006 16:20, Danny van Dyk wrote:
I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
Improvement respect the current situation? You're just asking for the
same exact treatment that is in place now,
Danny van Dyk wrote:
USE_EXPAND useflags do not need to be added to either use.desc nor
use.local.desc.
One point was adding better description about them to avoid misuse.
Further, we keep track of other hardware-related
metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.
On Friday 07 July 2006 16:40, Danny van Dyk wrote:
USE_EXPAND useflags do not need to be added to either use.desc nor
use.local.desc.
You need to put them in misc/whatever.desc
Further, we keep track of other hardware-related
metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.
Diego 'Flameeyes' Pettenò wrote:
Further, we keep track of other hardware-related
metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS.
Quite a different thing to me, considering the wide quantity of them.
But for an handful of useflag it would be a bit of overkill.
Perhaps you are
On Friday 07 July 2006 16:53, Stephen P. Becker wrote:
Perhaps you are thinking too narrowly here. Consider that this
USE_EXPAND could potentially be used to enable cpu specific flags over
more arches than just 32/64-bit x86. It seems clear that ppc and sparc
could already benefit, and I can
On Fri, 2006-07-07 at 16:03 +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 07 July 2006 15:53, Martin Schlemmer wrote:
Check Chris Gianelloni's mail just now. For some compilers with some
-march's on x86 it did not explicitly turn on some features (or maybe
not to such a high extend).
On Fri, 7 Jul 2006 16:20:08 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
OK, this rfc/proposal is competing with Flameeye's proposal:
I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
I don't like the name - I'd prefer something like CPU_SUBMODEL or
CPU_FEATURES or perhaps
Pierre Guinoiseau writes:
pam-login is now included in shadow, you no longer need to emerge it.
Thanks, that's what I needed to know.
I had done an emerge -D world, and suddenly I couldn't turn on the
PC. I later found out that /sbin/login had been removed.
Richard Fish writes:
USE=mono
On Fri, 2006-07-07 at 16:59 +0200, Diego 'Flameeyes' Pettenò wrote:
So the question is: why they aren't useflags in the first place? There has to
be a reason, or it would just be that up to now we did the same thing in
different ways just because of it.
Most likely.
Have you ever looked at
Quite honestly I see this as providing no advantage what so ever over
the current USE=mmx blah foo that we already have..
Please explain to me what I'm missing here..
How does this help us?
On Fri, 2006-07-07 at 16:20 +0200, Danny van Dyk wrote:
OK, this rfc/proposal is competing with
On Fri, 2006-07-07 at 17:46 +0200, Kevin F. Quinn wrote:
On Fri, 7 Jul 2006 16:20:08 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Diego's proposal essentially generates CPU_SUBMODEL automatically from
CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not
set. That way we have
On Fri, 07 Jul 2006 08:36:32 -0500 Mike Doty [EMAIL PROTECTED]
wrote:
| Chris Gianelloni wrote:
| [snip]
| This means it is now 36 profiles to support, if we dropped support
| on all profiles except for the new ones. Without having any sort of
| multiple inheritance available, this is really
On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk [EMAIL PROTECTED]
wrote:
| I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
| This should be set to sane defaults in the profiles. I.e. for x86,
| it should not set CPUFLAGS at all, and on AMD64 it should be
| CPUFLAGS=mmx sse sse2
The
Ciaran McCreesh wrote:
On Fri, 07 Jul 2006 08:36:32 -0500 Mike Doty [EMAIL PROTECTED]
wrote:
| Chris Gianelloni wrote:
| [snip]
| This means it is now 36 profiles to support, if we dropped support
| on all profiles except for the new ones. Without having any sort of
| multiple inheritance
On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
On Fri, 7 Jul 2006 07:46:16 +0200
Harald van Dijk [EMAIL PROTECTED] wrote:
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
Gentoo's gcc with the vanilla
On Friday 07 July 2006 17:31, Martin Schlemmer wrote:
As I pointed out on irc (to clarify), its still an issue even with
gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they
'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
4.0.1 I think.
For what I know,
On 7/7/06, Simon Stelling [EMAIL PROTECTED] wrote:
That's because CFLAGS=-msse currently doesn't do what the user would think it
does. Which is the real problem, which we're solving with the change Diego
suggested.
Well I certainly do *not* expect it to run configure with --enable-sse.
On Fri, 2006-07-07 at 18:53 +0200, Harald van Dijk wrote:
On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
On Fri, 7 Jul 2006 07:46:16 +0200
Harald van Dijk [EMAIL PROTECTED] wrote:
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
On Thursday 06 July 2006
On Thu, 06 Jul 2006 16:27:39 -0700
Zac Medico [EMAIL PROTECTED] wrote:
But anyway, base/make.defaults makes sense for now.
It is done.
--
gentoo-dev@gentoo.org mailing list
On Friday 07 July 2006 13:22, Diego 'Flameeyes' Pettenò wrote:
On Friday 07 July 2006 17:31, Martin Schlemmer wrote:
As I pointed out on irc (to clarify), its still an issue even with
gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they
'fixed' it in 3.4.5 via specs, and
Every now and then someone get sick of Gentoo and suddenly became
prophet, preaching that the end of the distro is near.
I wanted to see how much should we worry about it so I've made a perl
script to find the history of the following characteristics:
- no. of active developers (active dev := did
On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
Keep pushing this and the only thing you will end up with is the
vanilla flag being removed all together..
Is that a threat? If not, is there a reason behind this?
You want a pure 100%
vanilla(POS) non working toolchain then go
On Fri, 07 Jul 2006 21:34:49 +0300 Alin Nastac [EMAIL PROTECTED]
wrote:
| I am aware those characteristics are quantitative and don't say
| anything about the quality of the distribution.
They're also somewhat skewed, given all the modular ebuilds people are
making of late...
--
Ciaran McCreesh
On Fri, 2006-07-07 at 19:49 +0100, Ciaran McCreesh wrote:
On Fri, 07 Jul 2006 21:34:49 +0300 Alin Nastac [EMAIL PROTECTED]
wrote:
| I am aware those characteristics are quantitative and don't say
| anything about the quality of the distribution.
They're also somewhat skewed, given all the
Kevin F. Quinn [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Fri,
07 Jul 2006 17:46:14 +0200:
Diego's proposal essentially generates CPU_SUBMODEL automatically from
CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not
set. That way we have the best of both
On 07/07/06, Alin Nastac [EMAIL PROTECTED] wrote:
I am aware those characteristics are quantitative and don't say anything
about the quality of the distribution. However, judging after those
graphs, even the worst basher will recognize that we are far from being
dead.
It may be a better
On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
Keep pushing this and the only thing you will end up with is the
vanilla flag being removed all together..
Is that a threat? If not, is there a reason behind this?
Yes..
On 7/7/06, Ned Ludd [EMAIL PROTECTED] wrote:
You want a pure 100%
vanilla(POS) non working toolchain then go download it and
compile it yourself. You will soon see why things exist the way
they do..
LFS http://www.linuxfromscratch.org/lfs has always been based on a
vanilla toolchain. Never ran
On Friday 07 July 2006 12:53, Harald van Dijk wrote:
On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
If you take out the stub patches (which incidentally have no impact on
code generation), many builds will simply fail because they expect the
additional flags from ssp, htb
On Fri, 7 Jul 2006 20:53:12 +0100
Chris Bainbridge [EMAIL PROTECTED] wrote:
On 07/07/06, Alin Nastac [EMAIL PROTECTED] wrote:
I am aware those characteristics are quantitative and don't say
anything
about the quality of the distribution. However, judging after those
graphs, even the
On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote:
On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
Keep pushing this and the only thing you will end up with is the
vanilla flag being removed all together..
Is
On Friday 07 July 2006 01:46, Harald van Dijk wrote:
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
don't get appplied, but some do. Plus,
On 2006.07.07 14:27, Chris Gianelloni wrote:
On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote:
The more I think about the issue and the more I like the complete
profiles for amd64 more than the other solutions.
I don't even *want* to think of what this would be for x86.
These are what I
On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
On Friday 07 July 2006 01:46, Harald van Dijk wrote:
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
Gentoo's gcc with the vanilla flag isn't the official
On Friday 07 July 2006 12:18, Ciaran McCreesh wrote:
On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk [EMAIL PROTECTED]
| I suggest to add a CPUFLAGS USE_EXPAND variable to the tree.
| This should be set to sane defaults in the profiles. I.e. for x86,
| it should not set CPUFLAGS at all, and on
On Friday 07 July 2006 17:53, Harald van Dijk wrote:
On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
On Friday 07 July 2006 01:46, Harald van Dijk wrote:
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| The issue with this is that $feature on amd64 is not exactly the
| same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
| somesuch? That way there would be no confusion as to whether the
| cpuflags_sse2
On Friday 07 July 2006 18:15, Ciaran McCreesh wrote:
On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger [EMAIL PROTECTED]
| The issue with this is that $feature on amd64 is not exactly the
| same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
| somesuch? That way there would
On Fri, Jul 07, 2006 at 06:13:27PM -0400, Mike Frysinger wrote:
ignored *what* then ? you requested USE=vanilla control ssp, i said no and
i'll add support for USE=nossp ... you requested USE/stub control, i said no,
go delete the stubs
USE=nossp existed before USE=vanilla did. To be sure
On 7/7/06, Molle Bestefich [EMAIL PROTECTED] wrote:
Are you using an portage overlay? If so, what is in it?
No. No idea what that is. Sounds interesting, though.
It is a local portage tree with ebuilds that you have either written
yourself or downloaded from others. Since the overlay
On Fri, Jul 7, 2006 at 09:53:36 +0200, Seemant Kulleen wrote:
Hi Everyone,
I just wanted to put a few thoughts out there as people contemplate
nominees and the elections for the Gentoo Council. I personally am on
the fence about running this year, because I think there are a lot of
On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| | It'd also make handling use masking much easier.
| |
| | why ? because there wouldnt be anything to mask ?
|
| I'm pretty sure that USE_EXPAND has to be the same across all
| profiles, so no, masking would still
On Friday 07 July 2006 19:04, Harald van Dijk wrote:
I hope this is specific enough: toolchain.eclass revision 1.234
(separating ssp/... from vanilla) log message:
ssp/pie/htb have their own USE flags sep from vanilla, so people can
utilize those
when in fact the old USE=vanilla behaviour is
Ciaran McCreesh wrote:
Assuming that x86 and amd64 both support foo and bar, and that the baz
app supports both on x86 and only foo on amd64:
the app would ignore foo by itself and usually people are working on
having their tailored x86 code in shape for amd64 (using some tricks as
usual...)
I
Chris Bainbridge wrote:
It may be a better metric to look at the bugzilla stats. How has the
number of bugs being filed changed? What ratio of filed bugs are
resolved, vs the ones that are left open? bugs.gentoo.org has some
facilities for graphing stats back to December 2005...
Bugzilla
69 matches
Mail list logo
