On Sun, 9 Jul 2006 23:30:40 +0200
Molle Bestefich [EMAIL PROTECTED] wrote:
Richard Fish wrote:
The expectation here is that when a new version of gcc is
stabilized, that users will upgrade to that in a reasonable amount
of time, and use that (by selecting it with gcc-config) for
On Sun, 09 Jul 2006 15:27:14 -0700
Josh Saddler [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc [EMAIL PROTECTED]
wrote: | Not true. According to the 2006.0 x86 profile, for
example, you're |
Kevin F. Quinn wrote:
I don't believe retro-actively modifying the 2006.0 profile is a good
idea in general. The profile currently says that for x86, gcc
must be =sys-devel/gcc-3.3.4-r1 - if you do
# emerge =sys-devel/gcc-3.3.4-r1
on a current tree you'll get a much higher version. Still,
On Sun, 9 Jul 2006 19:17:09 +0200
Matthias Schwarzott [EMAIL PROTECTED] wrote:
Hi!
As the situation now has changed I would like to discuss this one
more. Since one week we (hd_brummy and me) have changed our Gentoo
VDR Project
(http://www.gentoo.org/proj/en/desktop/video/vdr/index.xml) to
On 7/10/06, Robin H. Johnson [EMAIL PROTECTED] wrote:
On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote:
On Monday 10 July 2006 02:25, Luca Barbato wrote:
c is simpler. I like it.
Yes, of course if _all wranglers_ respected metadata, instead of stopping to
herd tag
Robin H. Johnson wrote:
On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote:
On Monday 10 July 2006 02:25, Luca Barbato wrote:
c is simpler. I like it.
Yes, of course if _all wranglers_ respected metadata, instead of stopping to
herd tag and assigning to that even when
On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote:
As far as I can tell, the complaints are about Portage being unable to
handle GCC upgrades gracefully for end users.
The thing is, that portage doesn't technically handle gcc upgrades.
The user really needs to do that, and they (should) know
On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote:
2) If yes, are there any other flags that ebuilds should die on ?
My (user) opinion is that ebuilds should not die on CFLAGS, at least
not until per-package CFLAGS are implemented.
Now if someone is crazy enough to enable -ffast-math globally
Richard Fish wrote:
That won't be necessary. Things mostly works, and when they don't,
users file a bug like the aforementioned one, which should result in
that particular ebuild getting fixed, instead of the bug being marked
INVALID.
The thing is, this particular ebuild isn't actually
On Mon, 2006-07-10 at 01:34 -0700, Richard Fish wrote:
On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote:
2) If yes, are there any other flags that ebuilds should die on ?
My (user) opinion is that ebuilds should not die on CFLAGS, at least
not until per-package CFLAGS are implemented.
per
Denis Dupeyron [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Sun, 09 Jul 2006 23:24:24 +0200:
In bug #139412, I ask Paul de Vriese why he thinks python should die on
--fast-math instead of just filtering it. Here's his answer :
Denis, quite simple. -ffast-math is broken
On 7/10/06, Ryan Hill [EMAIL PROTECTED] wrote:
Ebuilds shouldn't die on anything according to the non-interactive portage
philosophy. I don't know how official that philosophy is though.
Correct me if I'm wrong, but this has nothing to do with being
interactive or not. To me, an ebuild that
Denis Dupeyron wrote:
This, for me, triggers 3 questions that are gentoo-dev@ material :
1) Should all ebuilds that currently filter --fast-math die on its
presence instead of filtering it ?
I don't think we should die on anything, if a user wants a particular
CFLAG, generally the default
[ resending this, the original appears to have been eaten. ]
On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED]
wrote:
| 1) Should all ebuilds that currently filter --fast-math die on its
| presence instead of filtering it ?
On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED]
wrote:
| 1) Should all ebuilds that currently filter --fast-math die on its
| presence instead of filtering it ?
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html
Basically, if you're
On Mon, 10 Jul 2006 10:41:25 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
| There's no sane way to force users to switch their gcc version, so
| messing w/ ebuild deps, profiles or keywords of outdated gcc versions
| won't help...
Messing with profiles will, however, give you grounds to close bugs as
Daniel Drake wrote:
Hi,
I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll
give around a weeks notice here when that is to happen. Hopefully we'll
use this for the 2006.1 release too.
It will be a little later than planned, but this is your 1 week notice
that 2.6.17
On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote:
per pkg cflags are here already it would fall under the per
pkg env variables.
Please forgive my stupidity, but the only place I could see to set a
env var per package was /etc/portage/bashrc. Is that what you are
referring to?
-Richard
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Fish wrote:
On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote:
per pkg cflags are here already it would fall under the per
pkg env variables.
Please forgive my stupidity, but the only place I could see to set a
env var per package was
Kevin F. Quinn wrote:
The expectation here is that when a new version of gcc is
stabilized, that users will upgrade to that in a reasonable amount
of time, and use that (by selecting it with gcc-config) for
compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on
2-Dec-2005, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This package was absorbed back into perl-core/Test-Simple as of the 0.62
release (which you have either via dev-lang/perl-5.8.8 or as the ebuild
at this point). I'm package.mask'ing it and will be removing it from the
tree in 30 days. Anything that
Richard Fish wrote:
Having dozens (hundreds? all?) ebuilds check for a minimum version
Probably just the ebuilds that happen to use new GCC features before
the mass of the general public has changed to that version. But yes,
a minimum version constraint could theoretically end up in a lot of
I've masked www-servers/resin-ee on 1 July, it will be removed from tree
around friday (14 July) - it's old, binary and there's no version 3 of
it. Please use www-servers/resin.
--
Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java,
Molle Bestefich wrote:
Kevin F. Quinn wrote:
The expectation here is that when a new version of gcc is
stabilized, that users will upgrade to that in a reasonable amount
of time, and use that (by selecting it with gcc-config) for
compiling all new updates. FYI, gcc-3.4.4-r1 was
Jakub Moc wrote:
Sigh. Because it would break your system!
You really need to research better if you insist on beating a dead
horse over and over again. Kindly read the toolchain.eclass:
You're misreading me.
I was merely counter-arguing Kevin, who said that Portage provides
plenty of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So who's planning on going? Basically I'd like to know who's planning
on going. I'm still undecided about it honestly, and if I go it'd only
be for a few days. Its also probably a good way to find a roomate to
make the cost of rooms a bit less. We
On Mon, 10 Jul 2006 19:23:54 +0200
Molle Bestefich [EMAIL PROTECTED] wrote:
Kevin F. Quinn wrote:
The expectation here is that when a new version of gcc is
stabilized, that users will upgrade to that in a reasonable
amount of time, and use that (by selecting it with gcc-config)
On Mon, 10 Jul 2006 19:32:00 +0200
Molle Bestefich [EMAIL PROTECTED] wrote:
Richard Fish wrote:
Having dozens (hundreds? all?) ebuilds check for a minimum version
Probably just the ebuilds that happen to use new GCC features before
the mass of the general public has changed to that
On 7/10/06, Molle Bestefich [EMAIL PROTECTED] wrote:
Richard Fish wrote:
of gcc doesn't seem very effecient.
I can't see why it would not be efficient?
I think it is an inefficient use of developer time. Do we really want
gentoo devs spending their time figuring out what the minimum gcc
On 7/10/06, Molle Bestefich [EMAIL PROTECTED] wrote:
It shouldn't even be _necessary_ to create bugs and receive advice
from a living, breathing human being just to perform a system update.
It isn't necessary. -user, the forums, IRC, all are monitored by
living, breathing human beings.
On 7/10/06, Zac Medico [EMAIL PROTECTED] wrote:
Richard Fish wrote:
On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote:
per pkg cflags are here already it would fall under the per
pkg env variables.
Please forgive my stupidity, but the only place I could see to set a
env var per package was
Richard Fish wrote:
I have to say I dislike allowing this backdoor method to set CFLAGS,
as they won't show up in emerge --info or emerge -pv pkg. You'd
have to see the actual build output to see the nasty flags, which you
might not even think to ask for if a package builds fine but crashes
On 7/10/06, Simon Stelling [EMAIL PROTECTED] wrote:
Sounds like your after bug 95741:
http://bugs.gentoo.org/show_bug.cgi?id=95741
Yeah, that would be nice! :-)
-Richard
--
gentoo-dev@gentoo.org mailing list
Richard Fish wrote:
I have to say I dislike allowing this backdoor method to set CFLAGS,
as they won't show up in emerge --info or emerge -pv pkg. You'd
have to see the actual build output to see the nasty flags, which you
might not even think to ask for if a package builds fine but crashes
maillog: 09/07/2006-17:17:59(+0100): John Mylchreest types
I've tried to clarify my point fairly well above, but the dependancy
is fairly strict by design. What in linux-mod except for my specific
example above would continue to work if there were no kernel sources
present? (I do of course
With the help of Brian Harring, we've now got a check for unported
packages. It indicates 207 unported packages, of which 93 can
potentially be fixed by stabilizing newer versions and pulling unported
ebuilds from the tree.
I've uploaded the list [1]. Run `grep potentially
Krzysiek Pawlik wrote:
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.
Something
37 matches
Mail list logo
