On Friday 13 May 2005 01:00 am, Mike Frysinger wrote:
> if you have any questions, or you think your package is special (everyone
> does), feel free to pipe up now and ask for a 3rd party review
to make everyones' lives easier (well just mine really), if you want me to
review your package and you
as some may have noticed, a lot of packages have suddenly started aborting
with messages such as:
* Patching ${S}/ltmain.sh ...
* Portage patch failed to apply (ltmain.sh version 1.3.4)!
!!! ERROR: category/package failed.
!!! Function elibtoolize, Line 240, Exitcode 0
!!! Portage patch failed to
Michael Haubenwallner wrote:
- Original Message -
From: "Marius Mauch" <[EMAIL PROTECTED]>
Ciaran McCreesh wrote:
As for the new metadata variable, I think it should be a complement to
RESTRICT (not limited to prefix). As the name for this var I suggest
SUPPORTS, so for an ebuild that can
On Thursday 12 May 2005 09:31 am, Mike Frysinger wrote:
> if mono is the only thing [ab]using have_NPTL, then maybe i'll bug
> latexer/dotnet guys and see why they cant utilize USE=nptl
aaand it's gone
so your only solution now is `use nptl`, muwahahahaha
-mike
--
gentoo-dev@gentoo.org maili
On Thu, May 12, 2005 at 08:01:23PM +0100, Stroller wrote:
> >>>* Unique ID strings for packages, zynot style. Messy as hell though,
> >>>DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't
> >>>have
> >>>the same kind of ring to it...
> >>
> >>Maybe I'm just a messy person, but I re
Rafael EspÃndola wrote:[Thu May 12 2005, 02:40:46PM EDT]
> Why does get_number_of_jobs reduces the number of parallel jobs to "to
> ensure successful merge"? In my humble opinion if a package fails to
> compile with a large -j then the ebuild should know the limit and
> reduce it.
Nope, if
Mike Frysinger wrote:
On Wednesday 11 May 2005 05:20 pm, Francesco Riosa wrote:
what we have:
At the moment have_NPTL is defined in eclass/eutils.eclass, it compile a
small test program to check if glibc have nptl support.
hasnt this been outgrown ? people should `use nptl` now i think
in fact gli
On Thursday 12 May 2005 21:22, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 12 May 2005 21:20, Gregorio Guidi wrote:
> > Is there a package where this could apply?
>
> We have couple of packages which can use both lame or toolame.
...toolame doesn't seem to do mp3s, so it doesn't overlap with la
Rafael EspÃndola wrote:
For this reason I have ported the ebuild to gcc 3.4.3. Should I submit
a bug report with it?
Yes, a bug report is ideal.
--
Nick Dimiduk
Gentoo for MacOS Developer
ndimiduk (at) gentoo (dot) org
--
gentoo-dev@gentoo.org mailing list
On Thursday 12 May 2005 21:20, Gregorio Guidi wrote:
> Is there a package where this could apply?
We have couple of packages which can use both lame or toolame.
--
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flameeyes/
pgpfon0vIe2JM.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stroller wrote:
>
> On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
>
>> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
>>
>>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>>>
* Unique ID strings for packages, zynot style. Mes
On Thursday 12 May 2005 20:55, Simon Stelling wrote:
> Mike Frysinger wrote:
> > so ? can you show me a package that this difference matters ? if not,
> > then having lame sep from mp3 is pointless ...
>
> It's analog to the lesstif use flag:
>
> lesstif - Use lesstif over openmotif in cases wher
On Thursday 12 May 2005 02:40 pm, Rafael Espíndola wrote:
> Why does get_number_of_jobs
it's an old hack that should be punted ... it's only used by glibc/gcc now, i
just havent gotten around to removing it
there's some parallel build issues in glibc, i just havent gotten up the guts
to track i
On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
* Unique ID strings for packages, zynot style. Messy as hell though,
DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't
have
the
Mike Frysinger wrote:
> so ? can you show me a package that this difference matters ? if not, then
> having lame sep from mp3 is pointless ...
It's analog to the lesstif use flag:
lesstif - Use lesstif over openmotif in cases where a program supports both
lame - Use lame over $OTHER_MP3ENCODI
Why does get_number_of_jobs reduces the number of parallel jobs to "to
ensure successful merge"? In my humble opinion if a package fails to
compile with a large -j then the ebuild should know the limit and
reduce it.
An example of the problem: My machine has one processor but there are
many icecc
I know that the libstdc++v3 is intended to help in the migration to
gcc 3.4. But I also find it usefull to build very small installations
without gcc.
For this reason I have ported the ebuild to gcc 3.4.3. Should I submit
a bug report with it?
Rafael Ávila de Espíndola
# Copyright 1999-2005 Gento
On Thursday 12 May 2005 01:19 pm, Matthijs van der Vleuten wrote:
> On 5/12/05, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > if you created a USE=lame, it would simply be a subset of USE=mp3
>
> But USE=mp3 could mean mp3 decoding support in audio players, while
> lame is not a decoder.
so ? can
On 5/12/05, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> if you created a USE=lame, it would simply be a subset of USE=mp3
But USE=mp3 could mean mp3 decoding support in audio players, while
lame is not a decoder.
--
gentoo-dev@gentoo.org mailing list
On Thursday 12 May 2005 12:50 pm, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 12 May 2005 18:18, Mike Frysinger wrote:
> > lame doesnt produce any other formats than mp3s afaik
>
> But there are other libraries which produce mp3s. Lame is just one of them.
whats your point ?
if you created a U
On Thursday 12 May 2005 18:18, Mike Frysinger wrote:
> lame doesnt produce any other formats than mp3s afaik
But there are other libraries which produce mp3s. Lame is just one of them.
--
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flam
On Thursday 12 May 2005 11:52 am, Simon Stelling wrote:
> Mike Frysinger wrote:
> >>My proposal is to start using lame useflag to enable lame support (in
> >>software which is just encoding on itself),
> >
> > why not re-use the 'mp3' USE flag ?
>
> I guess the focus here wouldn't be on supporting
Mike Frysinger wrote:
>>My proposal is to start using lame useflag to enable lame support (in
>>software which is just encoding on itself),
>
>
> why not re-use the 'mp3' USE flag ?
because LAME Ain't an Mp3 Encoder? ;)
I guess the focus here wouldn't be on supporting mp3-encoding as such
but
On Thursday 12 May 2005 08:58 am, Francesco Riosa wrote:
> Mike Frysinger wrote:
> >On Wednesday 11 May 2005 05:20 pm, Francesco Riosa wrote:
> >>what we have:
> >>At the moment have_NPTL is defined in eclass/eutils.eclass, it compile a
> >>small test program to check if glibc have nptl support.
>
Mike Frysinger wrote:
>On Wednesday 11 May 2005 05:20 pm, Francesco Riosa wrote:
>
>
>>what we have:
>>At the moment have_NPTL is defined in eclass/eutils.eclass, it compile a
>>small test program to check if glibc have nptl support.
>>
>>
>
>hasnt this been outgrown ? people should `use np
Diego 'Flameeyes' Pettenò wrote:
>Another useflag-related question.
>
>Currently, the encode useflag is defined as follow:
>
>encode - Adds support for MEncoder or LaME encoder, wherever applicable
>
>this is a loose definition which is quite useless for medium user, as it's
>used also in a non-c
On Thursday 12 May 2005 05:12 am, Diego 'Flameeyes' Pettenò wrote:
> encode - Adds support for MEncoder or LaME encoder, wherever applicable
>
> this is a loose definition which is quite useless for medium user, as it's
> used also in a non-complete-standard way in all ebuilds.
agreed
> My propos
Mike Frysinger wrote:
>On Wednesday 11 May 2005 07:26 pm, Ciaran McCreesh wrote:
>
>
>>On Wed, 11 May 2005 16:12:45 -0700 Donnie Berkholz
>>
>><[EMAIL PROTECTED]> wrote:
>>| Francesco Riosa wrote:
>>| > case $(getconf GNU_LIBPTHREAD_VERSION | tr
>>| > abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQ
On Wednesday 11 May 2005 05:20 pm, Francesco Riosa wrote:
> what we have:
> At the moment have_NPTL is defined in eclass/eutils.eclass, it compile a
> small test program to check if glibc have nptl support.
hasnt this been outgrown ? people should `use nptl` now i think
> there are drawbacks on
On Wednesday 11 May 2005 08:59 pm, Georgi Georgiev wrote:
> maillog: 12/05/2005-00:26:14(+0100): Ciaran McCreesh types
>
> > On Wed, 11 May 2005 16:12:45 -0700 Donnie Berkholz
> >
> > <[EMAIL PROTECTED]> wrote:
> > | Francesco Riosa wrote:
> > | > case $(getconf GNU_LIBPTHREAD_VERSION | tr
> > | >
On Wednesday 11 May 2005 07:26 pm, Ciaran McCreesh wrote:
> On Wed, 11 May 2005 16:12:45 -0700 Donnie Berkholz
>
> <[EMAIL PROTECTED]> wrote:
> | Francesco Riosa wrote:
> | > case $(getconf GNU_LIBPTHREAD_VERSION | tr
> | > abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ) in
> |
> | Wow, what
Brian Harring wrote:
> > The layout on disk and the semantics of categories do not need to be > >
> > related.
> Yes and no. You're assuming that people don't use the layout on
> disk for digging around without calling portage. Personally, I do.
Sometimes I do the same; but other times I find
Another useflag-related question.
Currently, the encode useflag is defined as follow:
encode - Adds support for MEncoder or LaME encoder, wherever applicable
this is a loose definition which is quite useless for medium user, as it's
used also in a non-complete-standard way in all ebuilds.
My p
On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
> >
> > * Unique ID strings for packages, zynot style. Messy as hell though,
> > DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> > the same kind of ring to it...
>
> M
- Original Message -
From: "Marius Mauch" <[EMAIL PROTECTED]>
> Ciaran McCreesh wrote:
> As for the new metadata variable, I think it should be a complement to
> RESTRICT (not limited to prefix). As the name for this var I suggest
> SUPPORTS, so for an ebuild that can install into /usr, $
35 matches
Mail list logo
