On 02/07/15 13:50, Ciaran McCreesh wrote:
On Sat, 07 Feb 2015 13:46:28 -0500
"Anthony G. Basile" wrote:
I assume this is a problem with $IUSE and its scope, and not with the
code for in_use() per se? Can you help me understand why you can't
just walk through $IUSE and see if there's a matching
On Sat, 07 Feb 2015 13:46:28 -0500
"Anthony G. Basile" wrote:
> I assume this is a problem with $IUSE and its scope, and not with the
> code for in_use() per se? Can you help me understand why you can't
> just walk through $IUSE and see if there's a matching flag in there?
It's because of eclas
On 02/07/15 01:31, Ulrich Mueller wrote:
On Fri, 6 Feb 2015, Luke Dashjr wrote:
On Friday, February 06, 2015 12:54:26 PM hasufell wrote:
Another thing I just found:
# @FUNCTION: in_iuse
[...]
# Note that this function should not be used in the global scope.
From a PMS point of view: s/ in th
On 02/06/15 14:41, Michał Górny wrote:
Dnia 2015-02-05, o godz. 19:11:11
"Anthony G. Basile" napisał(a):
I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds
make use of the same codebase, so its probably a good idea to migrate
that code to an eclass. Can we have the follo
> On Fri, 6 Feb 2015, Luke Dashjr wrote:
> On Friday, February 06, 2015 12:54:26 PM hasufell wrote:
>> Another thing I just found:
>>
>> # @FUNCTION: in_iuse
>> [...]
>> # Note that this function should not be used in the global scope.
From a PMS point of view: s/ in the global scope//
You
On 02/06/2015 11:07 PM, Luke Dashjr wrote:
>
> Also, it seems that it can't use a common repository for different remotes.
> While right now, we're only supporting git master, in the past we've also had
> times we supported stable branches, which are usually kept separate.
Maybe the eclass main
On Friday, February 06, 2015 12:54:26 PM hasufell wrote:
> Luke Dashjr:
> > On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
> >> Why does it not use git-r3?
> >
> > I just looked into this, and I don't see a way to get git-r3 to use the
> > same repositories already cloned for previous ver
Dnia 2015-02-05, o godz. 19:11:11
"Anthony G. Basile" napisał(a):
> I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds
> make use of the same codebase, so its probably a good idea to migrate
> that code to an eclass. Can we have the following eclass reviewed
> before com
Luke Dashjr:
> On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
>
>> Why does it not use git-r3?
>
> I just looked into this, and I don't see a way to get git-r3 to use the same
> repositories already cloned for previous versions. What is the standard
> practice for ebuilds already using
On Friday, February 06, 2015 4:24:58 AM Jason Zaman wrote:
> On Fri, Feb 06, 2015 at 02:46:37AM +, Luke Dashjr wrote:
> > On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
> > > Why does it not use git-r3?
> >
> > I just looked into this, and I don't see a way to get git-r3 to use the
>
On Fri, Feb 06, 2015 at 02:46:37AM +, Luke Dashjr wrote:
> On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
> > Why does it not use git-r3?
>
> I just looked into this, and I don't see a way to get git-r3 to use the same
> repositories already cloned for previous versions. What is the
On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
> Afais the eclass is missing the safeguard, as in
I wasn't aware this was needed. Basically just wrap everything except
EXPORT_FUNCTIONS in it? I couldn't find it documented anywhere...
> Why is EAPI=5 not supported?
*Only* EAPI=5 is supp
hasufell:
> We had this with qt eclass once and it wasn't really correct,
> but rather a convenience shortcut.
>
sorry, I meant KDE
Anthony G. Basile:
> Hi everyone,
>
> I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds
> make use of the same codebase, so its probably a good idea to migrate
> that code to an eclass. Can we have the following eclass reviewed
> before committing it to the tree:
>
> https
On 05/02/15 07:11 PM, Anthony G. Basile wrote:
> Hi everyone,
>
> I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds
> make use of the same codebase, so its probably a good idea to migrate
> that code to an eclass. Can we have the following eclass reviewed
> before committin
Hi everyone,
I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds
make use of the same codebase, so its probably a good idea to migrate
that code to an eclass. Can we have the following eclass reviewed
before committing it to the tree:
https://gitorious.org/bitcoin/gento
16 matches
Mail list logo