Am 11.11.2015 um 05:16 schrieb Ulrich Mueller:
>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
>
>> Arfrever highlights these are not even safe to use. bash is locale aware,
>> so it'll apply LC_COLLATE rules when processing the ^/, casemods. while
>> you can fix this with external programs
Am 17.03.2015 um 16:33 schrieb Michał Górny:
However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done using
the following package.use entry:
*/* abi_x86_32
I'm confused: Has this a different semantics
Am 10.01.2014 19:19, schrieb Ciaran McCreesh:
> On Fri, 10 Jan 2014 14:18:24 +0100
> René Neumann wrote:
>> And again: What is needed is streamlining the algorithms (discussion
>> on that already started as far as I could notice). An algorithm in
>> O(n³) is always¹ worse
Am 10.01.2014 14:05, schrieb Igor:
> Hello Patrick,
>
> Friday, January 10, 2014, 4:39:59 PM, you wrote:
>
>> No, Python isn't slow.
>> Bad code is bad. You can write bad code in any language.
>
> Are you sure? Take a look here:
>
> http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?tes
Am 10.01.2014 13:52, schrieb Igor:
> And you belive that you're outside competition. It looks unreal.
> Gentoo is in competition with other distros - it's real and happens
> right now.
Again, just because this "science" called 'Economics' believes,
everything is in competition, does not change rea
Am 10.01.2014 13:23, schrieb Igor:
> You could make fast and correct decisions.
There is no such thing as the single correct decision. Management people
often think there is, but this is because management people often have
no clue what they are talking about.
>
> Why not to get rid of Python a
Am 10.01.2014 13:10, schrieb Igor:
> Hello Chris,
>
> Friday, January 10, 2014, 1:08:39 AM, you wrote:
>
>> Right here is the big problem: you're not looking at this from the
>> perspective of the average Gentoo developer. We don't care about market
>> share. We don't care whether we're on top fo
Am 13.06.2013 07:44, schrieb Michał Górny:
> Dnia 2013-06-12, o godz. 13:23:04
> Michael Orlitzky napisał(a):
>
>> We need worse support for overlays, i.e. no. Having to use >3 overlays
>> defeats the purpose of a QA'd tree. Everything in an (official)
>> overlay should be in package.mask instead
Am 27.05.2013 22:38, schrieb Anthony G. Basile:
> Hi everyone,
>
> I was about to add a use expand flag for monkeyd (a tiny web server) and
> there is a notice in base/make.default to discuss use expand flags on
> the list first. There are about 9 plugins for monkeyd similar to apache
> which can
Am 19.05.2013 18:03, schrieb viv...@gmail.com:
> On 05/19/13 17:47, Alexis Ballier wrote:
>> On Sat, 18 May 2013 22:31:11 -0400
>> "Walter Dnes" wrote:
>>
>> [...]
>>> ...shouldn't "mmxext" be moved out of use.local.desc into use.desc?
>>
>> all the cpu flags should be global IMHO, regardless of h
Am 03.05.2013 22:20, schrieb Zac Medico:
> Is it worth changing?
Nope. What's worth changing is the excessive use of USE_EXPAND for no
reason (your described usecase makes sense for reasonable USE_EXPAND
stuff like VIDEO_CARDS). But seems like I'm the only one concerned by
this, so I should probab
Am 24.04.2013 11:51, schrieb René Neumann:
> As more and more packages seem to (mis)use USE_EXPAND: Can we get the
> possibility to set this directly in package.use? Having to write
> 'claws_mail_plugins_foo' does not help readability, and setting it in
> make.conf is also no
Dear all,
I noticed, that there is a global useflag 'xsl', with one of those
bleh-descriptions "Enables XSL support"
There is exactly one user of it: php -- to pull in libxslt.
Now there is also the local useflag xslt (used by three other packages)
for enabling xslt support (by pulling in libxsl
Am 24.04.2013 19:15, schrieb Zac Medico:
> On 04/24/2013 02:51 AM, René Neumann wrote:
>> As more and more packages seem to (mis)use USE_EXPAND: Can we get the
>> possibility to set this directly in package.use? Having to write
>> 'claws_mail_plugins_foo' does not h
Am 21.04.2013 23:38, schrieb Christian Faulhammer:
> Hello everybody,
>
> the upcoming Claws Mail release will have no separation between
> internal plugins (stuff that is built on mail-client/claws-mail with
> USE="crypt bogofilter") and external ones (all packages
> mail-client/claws-mail-*) any
Am 21.03.2013 14:09, schrieb Denis M.:
> Hello, I'd want to ask if it's possible and a good idea to add
> HEXCHAT_PLUGINS to the global USE_EXPAND var.
I personally don't think this is a good idea. Imho USE_EXPAND should be
used for flags that will be used by multiple (>5?) packages -- for the
sim
Am 08.07.2012 22:10, schrieb Michał Górny:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann wrote:
>
>> Hi all,
>>
>> I'd like just to receive a short clarification about the 'status' of
>> base.eclass: Is this eclass expected to be available
Hi all,
I'd like just to receive a short clarification about the 'status' of
base.eclass: Is this eclass expected to be available everywhere, i.e.
should each eclass make sure it imports and incorporates it. Or is it
just an eclass like the others and ebuilds should make sure they inherit
it if ne
> * Undocumented use flags:
> --
> pango
% euse -i pango
global use flags (searching: pango)
no matching entries found
local use flags (searching: pango)
[+ D ] pa
19 matches
Mail list logo
