Grant posted on Fri, 25 May 2012 23:01:42 -0700 as excerpted:
>>> May I ask why you force the g-cpan category to dev-perl?
>>
>> Using that category solves many issues in advance, ie: if you generated
>> an ebuild locally, and then we provided a maintained copy,
>> portage would just switch from o
>> May I ask why you force the g-cpan category to dev-perl?
>
> Using that category solves many issues in advance, ie: if you
> generated an ebuild locally, and then we provided a maintained copy,
> portage would just switch from one to the other seamlessly where
> needed without you having to modi
On Friday 25 May 2012 23:23:30 Ryan Hill wrote:
> ...
what Ryan said
-mike
signature.asc
Description: This is a digitally signed message part.
On Sat, 26 May 2012 02:33:06 +0200
hasufell wrote:
> What's the official policy, so everyone can be clear about this?
It's not a requirement, except when it is. :)
Some projects are territorial. Games is one. I imagine adding something
to kde, gnome, or xfce categories without contacting tho
> maybe a new eclass-level keyword @INHERITED-API ? it takes a space delimited
> list of eclasses that are guaranteed by the API. so in distutils.eclass,
> we'd
> add:
> # @INHERITED-API: python
>
> and repoman would use this to build a tree of implicit funcs to allow w/out a
> direct inher
On Friday, May 25, 2012 08:52:00 PM Mike Frysinger wrote:
> On Friday 25 May 2012 18:33:43 Ciaran McCreesh wrote:
> > On Fri, 25 May 2012 15:02:32 -0500 Dan Douglas wrote:
> > > If it were made a policy now that ebuilds and eclasses cannot depend
> > > upon the subshell (for example, to set tempora
On Friday 25 May 2012 18:33:43 Ciaran McCreesh wrote:
> On Fri, 25 May 2012 15:02:32 -0500 Dan Douglas wrote:
> > If it were made a policy now that ebuilds and eclasses cannot depend
> > upon the subshell (for example, to set temporary positional
> > parameters or isolate temporary variables), then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Due to bug https://bugs.gentoo.org/show_bug.cgi?id=417117
it seems the situation on this topic is unclear.
I myself don't have a problem with getting my ebuilds reviewed if the
herd requires that before I commit them and have done this already a
few t
On Friday, May 25, 2012 11:33:43 PM Ciaran McCreesh wrote:
> On Fri, 25 May 2012 15:02:32 -0500
> Dan Douglas wrote:
> > If it were made a policy now that ebuilds and eclasses cannot depend
> > upon the subshell (for example, to set temporary positional
> > parameters or isolate temporary variable
On Fri, 25 May 2012 15:02:32 -0500
Dan Douglas wrote:
> If it were made a policy now that ebuilds and eclasses cannot depend
> upon the subshell (for example, to set temporary positional
> parameters or isolate temporary variables), then maybe someday in the
> distant future this could be made the
I like it. There would be plenty of time for migration considering the 4.2
requirement. Unfortunately, writing a QA check for violations would be
nearly impossible.
As many are probably aware, Bash 4.2 adds a shopt feature to enable not
running the last command of a pipeline in a subshell (POSIX leaves it up to
the shell to decide). Aside from being a slight optimization, it allows some
syntactic convenience such as reduced reliance upon process substitutio
preprocessor flags (e.g. -I and -D) should be added via `append-cppflags`, and
build systems should be respecting ${CPPFLAGS}. to enforce this a bit better,
i'll be adding a qawarning to append-flags when it encounters flags that should
be passed to append-cppflags.
-mike
signature.asc
Descri
On Friday 25 May 2012 14:38:34 Steven J Long wrote:
> > Steven J Long wrote:
> >> You could maybe tighten the false-negative side by scanning all
> >> functions defined in an eclass, and warning if they're undocumented.
> >
> > that happens now when you emerge eclass-manpages, but i suspect no one
Mike Frysinger wrote:
> Alexey Shvetsov wrote:
>> Mike Frysinger писал:
>> > Ryan Hill wrote:
>> >> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
>> >> foo-functions.
>> >
>> > i was thinking of extending the metadata to handle this. did you
>> > have any
>> > specific idea
On Friday 25 May 2012 12:06:49 Alexey Shvetsov wrote:
> Mike Frysinger писал 2012-05-25 19:42:
> > On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
> >> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
> >> foo-functions.
> >
> > i was thinking of extending the metadata to han
Mike Frysinger писал 2012-05-25 19:42:
On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
Is there any sane way to handle sub-eclasses? eg. foo-base inherits
foo-functions.
i was thinking of extending the metadata to handle this. did you
have any
specific ideas in mind ? i can see inheriti
On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
> foo-functions.
i was thinking of extending the metadata to handle this. did you have any
specific ideas in mind ? i can see inheriting say distutils should not require
peo
On Fri, May 25, 2012 at 8:47 AM, Kent Fredric wrote:
> On 25 May 2012 18:12, Ulrich Mueller wrote:
>>
>> Actually, Alec's question is not so far-fetched. The Gentoo Social
>> Contract says that Gentoo will never depend upon a piece of software
>> unless it is open source.
>>
>
> Though in the cas
On 25 May 2012 20:52, Grant wrote:
> I switched local-lib from the g-cpan one to the perl-experimental one
> and all is well as far as installation all the way through
> Net-Braintree. Thank you very much for sticking with me on this guys.
>
> May I ask why you force the g-cpan category to dev-pe
>> That did it, but there's more trouble. g-cpan strikes again?
>>
> Configuring source in
> /var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004 ...
>
> For local-lib, you're best trying using the copy in the
> perl-experimental overlay. If that doesn't work either, then
21 matches
Mail list logo
