On Fri, 25 May 2012, Kent Fredric wrote:
On 25 May 2012 13:21, Alec Warner anta...@gentoo.org wrote:
So I'm a bit confused. Is GitHub open source?
Your confusion begets more confusion:
Whether or not Github is open-source seems orthogonal to whether or
not we use it, as github is a
/local-lib-1.008004'.
* This ebuild is from an overlay named 'x-portage': '/usr/local/portage/'
* The complete build log is located at
'/var/log/portage/dev-perl:local-lib-1.008004:20120525-061124.log'.
* The ebuild environment file is located at
'/var/tmp/portage/dev-perl/local-lib-1.008004/temp
On 25 May 2012 18:12, Ulrich Mueller u...@gentoo.org 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 case of github, gentoo is not depending upon it.
Github
On 25 May 2012 18:16, Grant emailgr...@gmail.com wrote:
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
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 why the
On 25 May 2012 20:52, Grant emailgr...@gmail.com 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
On Fri, May 25, 2012 at 8:47 AM, Kent Fredric kentfred...@gmail.com wrote:
On 25 May 2012 18:12, Ulrich Mueller u...@gentoo.org 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
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
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
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 handle this.
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 ideas in mind ? i can see
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
cares.
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
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
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.
On Fri, 25 May 2012 15:02:32 -0500
Dan Douglas orm...@gmail.com 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
On Friday, May 25, 2012 11:33:43 PM Ciaran McCreesh wrote:
On Fri, 25 May 2012 15:02:32 -0500
Dan Douglas orm...@gmail.com 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
-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
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 maybe
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 temporary
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 inherit.
On Sat, 26 May 2012 02:33:06 +0200
hasufell hasuf...@gentoo.org 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
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 Thursday 24 May 2012 16:04:30 Zac Medico wrote:
On 05/24/2012 12:20 PM, Mike Frysinger wrote:
Rather than copying pasting the same behavior for the different eclass
checks, add a common class for them to extend. This makes adding more
eclass checks trivial, and keeps down bitrot.
24 matches
Mail list logo
