Krzysiek Pawlik wrote:
> 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.
>
it's not replaced by resin pro ?
--
gentoo-dev@gentoo.org mailing list
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.
>
>
Somet
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
unported-notinc-nonstabl
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
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 . 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 . 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, 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 packa
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".
-R
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
v
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 th
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 g
mail-mta/courier is without an active ebuild maintainer and has an open
security bug [1].
Anyone willing to take care of this package in the future, please update
metadata.xml and CC yourself on the bug.
[1] https://bugs.gentoo.org/show_bug.cgi?id=135005
--
Sune Kloppenborg Jeppesen
Gentoo Li
-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 don
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 informa
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.
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 key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...
signature.
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
-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 use
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-
-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 w
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
--
gento
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 wi
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 a
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'r
[ 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 ?
http://devmanual.gentoo.org/ebuild-writing/functions
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
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" <[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 b
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 implemente
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 a
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 globall
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) kn
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
>> tag and assigning to that even
34 matches
Mail list logo
