The votes keep pouring in. Ffmpeg is the preference of Gentoo users, as
well as the majority of Gentoo developers, and by a very relevant upstream
author.
On Sat, Feb 7, 2015 at 3:12 PM, hasufell wrote:
>
> You are making it sound like there is some huge work to be done. There
> isn't. And no one has to step up to change the current situation, except
> the council.
Are we that politics driven now?
If you feel so strongly about it, then join the ga
Rich Freeman:
> On Sat, Feb 7, 2015 at 10:06 AM, hasufell wrote:
>>
>> The council just chose the worst way, because it didn't want to upset
>> either party involved in the discussion.
>>
>
> The council simply upheld GLEP 39 - people don't HAVE to work with a
> project team to work on packages.
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 Sat, Feb 7, 2015 at 10:06 AM, hasufell wrote:
>
> The council just chose the worst way, because it didn't want to upset
> either party involved in the discussion.
>
The council simply upheld GLEP 39 - people don't HAVE to work with a
project team to work on packages. There is no QA policy tha
On 7 February 2015 at 23:06, hasufell wrote:
DEPEND=""
>>>
>>> unzip is missing from DEPEND
>>
>> I thought portage auto-depends on this. But I can add || ( unzip zip )
>> to be explicit.
>>
>
> I don't know, but it's definitely not in @system. Afair we are only
> allowed to omit deps from th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
On 07/02/15 05:16, Ben de Groot wrote:
> I discussed this beforehand with said developer on IRC.
Ok, that wasn't clear from the commit message.
> Do you think a news item to explain this situation and giving
> explicit instructions for users w
Ben de Groot:
>>>
>>> EAPI=5
>>> inherit toolchain-funcs
>>>
>>
>> This breaks consistency. Now users cannot rely on games.eclass anymore.
>> We should either abandon it completely or follow it consistently.
>
> I thought we had abandoned it already?
>
> Is there anything to be gained from using
On 02/06/2015 06:47 PM, Patrick Lauer wrote:
> On Friday 06 February 2015 06:28:27 Jory A. Pratt wrote:
>> As many of you are aware we are using esr ( extended service releases
>> ) for stable. We will remove all versions prior to 31.x in 7 days. If
>> you are needing an older version please let us
12 matches
Mail list logo
