On Wednesday 18 April 2012 22:14:54 hero...@gentoo.org wrote:
> How about unmasking it now?
file a bug for the arm team to request keywordings. we'll probably say yes.
-mike
signature.asc
Description: This is a digitally signed message part.
On Wed, Apr 18, 2012 at 10:14 PM, wrote:
> Dear All,
>
> I have just emerged ocaml-3.12.0[ocamlopt] on arm and used it to compile
> mldonkey[ocamlopt]. It seems to work well.
>
> it was masked on Apr 18, 2010,
> ,
> | /usr/portage/profiles$ grep -n -B3 ocamlopt ./arch/arm/use.mask
> | 31-# Ra
Dear All,
I have just emerged ocaml-3.12.0[ocamlopt] on arm and used it to compile
mldonkey[ocamlopt]. It seems to work well.
it was masked on Apr 18, 2010,
,
| /usr/portage/profiles$ grep -n -B3 ocamlopt ./arch/arm/use.mask
| 31-# Raúl Porcel
| 32-# Fails to build/work
| 33-openexr
| 34:oc
Zac Medico wrote:
Isn't that just a consequence of how autotools works? Do you have a
better alternative?
Maaaybe letting the package manager know how to run autotools if
necessary? There's already built-in autotools knowledge in that econf
is in practice autotools-specific. On the other ha
On Wed, 18 Apr 2012 12:41:32 -0700
Zac Medico wrote:
> On 04/18/2012 11:34 AM, David Leverton wrote:
> > Zac Medico wrote:
> >> Also, maybe apply_user_patches_here should have a special return
> >> value if there are no patches to be applied? That way, src_prepare
> >> can avoid an eautoreconf ca
On 04/18/2012 11:34 AM, David Leverton wrote:
Zac Medico wrote:
Also, maybe apply_user_patches_here should have a special return value
if there are no patches to be applied? That way, src_prepare can avoid
an eautoreconf call if there are no patches.
Does that imply that every ebuild for an au
Zac Medico wrote:
Also, maybe apply_user_patches_here should have a special return value
if there are no patches to be applied? That way, src_prepare can avoid
an eautoreconf call if there are no patches.
Does that imply that every ebuild for an autotools-based package would
be expected to hav
On 04/18/2012 10:41 AM, Ciaran McCreesh wrote:
On Wed, 18 Apr 2012 13:39:59 -0400
Mike Frysinger wrote:
i'm not sure splitting patches out of src_prepare into a dedicated
src_patch step would benefit that much. often times, you need to
mangle the code before/after patching.
Right. If we were
it isn't uncommon for people to want to force the patch (-p#) or fuzz (-f#)
level when applying specific patches. but it is unusual that they want to kill
off the extra options: -g0 -E --no-backup-if-mismatch. so i'd like to split
these off and improve the epatch API.
# Extra options to pass
On Wed, 18 Apr 2012 13:39:59 -0400
Mike Frysinger wrote:
> i'm not sure splitting patches out of src_prepare into a dedicated
> src_patch step would benefit that much. often times, you need to
> mangle the code before/after patching.
Right. If we were going to take the EAPI route with this, the
On Wednesday 18 April 2012 12:59:13 Jeroen Roovers wrote:
> On Sun, 15 Apr 2012 01:35:40 -0700 Zac Medico wrote:
> > Funtoo has support for FEATURES=localpatch, which does the epatch_user
> > thing before src_prepare. I think it should really go after
> > src_prepare, in order to apply patches afte
On Sun, 15 Apr 2012 01:35:40 -0700
Zac Medico wrote:
> Funtoo has support for FEATURES=localpatch, which does the epatch_user
> thing before src_prepare. I think it should really go after
> src_prepare, in order to apply patches after those that src_prepare
> may apply (avoiding possible conflict
On Wednesday 18 April 2012 17:01:28 Amadeusz Żołnowski wrote:
> > I guess this should go to the wiki.
>
> I was asked in the past to move howto from wiki to some more reliable
> place, because wiki used to be offline quite often. Has this been
> changed? If you move it, please just know me the a
Excerpts from Alex Legler's message of 2012-04-18 16:49:57 +0200:
> On Wednesday 18 April 2012 16:03:09 Amadeusz Żołnowski wrote:
> > I no longer use plymouth and have no more will to work on it, but
> > because I believe many users use this package it would be good if
> > somebody take maintainers
On Wednesday 18 April 2012 16:03:09 Amadeusz Żołnowski wrote:
> Hi,
>
> I no longer use plymouth and have no more will to work on it, but
> because I believe many users use this package it would be good if
> somebody take maintainership of it.
I'll take it for now. Co-maintainers welcome.
> Ther
Hi,
I no longer use plymouth and have no more will to work on it, but
because I believe many users use this package it would be good if
somebody take maintainership of it. There's only one serious bug opened
at this time and there's no much work with this package. I have also
written some howto
I can be convinced to work on this again after goffice maintainers get
new version in tree, but for now...
# Samuli Suominen (18 Apr 2012)
# Fails to build according to bugs 348231 and 388509.
# Needs a version bump but required goffice version is not
# yet in Portage wrt bug 37.
# Because
El lun, 16-04-2012 a las 10:40 +0200, Pacho Ramos escribió:
> El lun, 16-04-2012 a las 03:04 +0200, Jeroen Roovers escribió:
> > On Sun, 15 Apr 2012 11:55:04 +0200
> > Pacho Ramos wrote:
> >
> > > Well, I currently manually do eix searching to check it, maybe would
> > > be a way to compare eix o
18 matches
Mail list logo
