On 14/05/14 03:47, Brian Evans (grknight) wrote:
Hi Brian,
EAPI=4
please always try to bump to latest EAPI when ever you add a new
revision or version to the tree,
# Most of these are in the eclass
DEPEND=|| ( =sys-devel/gcc-3.4.6 =sys-devel/gcc-apple-4.0 )
On 14/05/14 08:56, Justin (jlec) wrote:
On 14/05/14 03:47, Brian Evans (grknight) wrote:
Hi Brian,
EAPI=4
please always try to bump to latest EAPI when ever you add a new
revision or version to the tree,
# Most of these are in the eclass
DEPEND=|| ( =sys-devel/gcc-3.4.6
On Sun, 11 May 2014, Michał Górny wrote:
The gx86-multilib project is working hard to bring our users a better
experience in multilib support. Eventually, we would like to phase out
emul-linux and replace it with less flawed multilib-build solution.
However, that requires a lot of work and
On 05/13/14 13:01, Andrew Savchenko wrote:
f we are trying to consider a majority of users (and thus to
select reasonable defaults), from disk usage + decompression
overhead point of view it will be the best to store compressed files
if they are at least one filesystem block smaller than
Am Dienstag, 13. Mai 2014, 15:42:11 schrieb Ulrich Mueller:
Compression for very small files was systematically studied by vapier
in bug 169260, which led to the current threshold of 128 bytes. Files
smaller than that usually don't compress at all.
As long as this concerns manpages (where
On Wed, 14 May 2014, Andreas K Huettel wrote:
However, I'm not so happy with a semi-random compres/dont compress
decision for other files. Maybe some program expects a certain
filename to display a README? If there is a clear-cut decision, then
the code can be adapted, but if the portage
On 2014.05.12 10:35, Tom Wijsman wrote:
On Sun, 11 May 2014 19:46:50 +0200
Michał Górny mgo...@gentoo.org wrote:
Rationale: xz-utils is quite widespread nowadays and it is a part
of @system set. It can achieve better compression ratio than bzip2,
and faster decompression at the same
On Wed, May 14, 2014 at 12:53 PM, Roy Bamford neddyseag...@gentoo.org wrote:
What about not compressing files smaller than the filesysem block size
at all. In my case its 4k. Any file gets allocated 4k on disc anyway,
so compression/decompression is just a waste of resource for files
=4k.
On Thu, May 08, 2014 at 07:07:33AM +0300, Alex Alexander wrote:
I've dropped myself from the maintainer list in the following packages.
Feel free to pick them up if you use them, they deserve better :)
app-misc/vifm
I'll take this one.
signature.asc
Description: Digital signature
On Tue, 13 May 2014 19:11:18 +0200
Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-05-13, o godz. 09:28:49
Andrew Savchenko birc...@gmail.com napisał(a):
I tried network-sandbox — this is a disaster. It brokes distcc
completely since distcc client can't connect to remote servers (and
I'm a lazy bum and I'm tired of rebasing patches that fail due to whitespace.
Is this doable or would it make the universe explode?
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
140515 Chema Alonso wrote:
On Thu, May 08, 2014 at 07:07:33AM +0300, Alex Alexander wrote:
I've dropped myself from the maintainer list in the following packages.
Feel free to pick them up if you use them, they deserve better :)
app-misc/vifm
I'll take this one.
Thanks from a user : Vifm is
On Wed, 14 May 2014, Ryan Hill wrote:
I'm a lazy bum and I'm tired of rebasing patches that fail due to
whitespace. Is this doable or would it make the universe explode?
Please don't. There are languages where whitespace is significant.
Ulrich
pgpPEf4n3_MP3.pgp
Description: PGP signature
13 matches
Mail list logo
