On Friday 28 April 2006 21:20, Grant Goodyear wrote:
Ryan Phillips wrote: [Fri Apr 28 2006, 01:57:30PM CDT]
I disagree. The developers should make *all* the decisions.
Originally, Gentoo was effectively a meritocracy. It's now, in some
respects, a republic. If you want a democracy, feel
On Saturday 29 April 2006 19:52, Donnie Berkholz wrote:
Jan Kundrát wrote:
Ryan Phillips wrote:
Stable and unstable keywords are a hack on top of a version control
system. We wouldn't have them if gentoo used an SCM that supports
true branches. There would be no need.
Umm, I'm not
Robin H. Johnson wrote:
On Sun, Apr 30, 2006 at 06:30:23PM +0200, Patrick Lauer wrote:
We have ~15k .tar.gz in distfiles. ~6500 .tar.bz2, ~2000 others.
A short run over 477 distfiles spanning 833M gave me 586M of .tar.bz2 -
roughly 30% more efficient!
A comparison run with 7zip gave me 590M
Patrick Lauer [EMAIL PROTECTED] said:
Hi all,
I had this random idea that many of our distfiles are .tar.gz while more
efficient compression methods exist. So I did some testing for fun:
We have ~15k .tar.gz in distfiles. ~6500 .tar.bz2, ~2000 others.
A short run over 477 distfiles
On Tue, 2006-05-02 at 08:50 -0700, Ryan Phillips wrote:
Patrick,
did you benchmark CPU load? Often bzip2 takes 3x as long to
uncompress a package than bzip. Often, the space savings doesn't
justify the cost of how long it takes for the cpu to decompress the
archive.
I did not compare
On Tue, 2006-05-02 at 18:27 +0200, Patrick Lauer wrote:
On Tue, 2006-05-02 at 08:50 -0700, Ryan Phillips wrote:
Patrick,
did you benchmark CPU load? Often bzip2 takes 3x as long to
uncompress a package than bzip. Often, the space savings doesn't
justify the cost of how long it
Ryan Phillips wrote:
did you benchmark CPU load? Often bzip2 takes 3x as long to
uncompress a package than bzip. Often, the space savings doesn't
justify the cost of how long it takes for the cpu to decompress the
archive.
How long does it take in time units defined as the time required to
Hi all,
I'm compiling some software created for Fedora/Red Hat and discovered some of
the gentoo kernel-headers are broken.
For example ethtool.h, which uses the u32 typedef defined in asm/types.h. This
typedef has been disabled outside the kernel to avoid name space clashes which
I think is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi devs,
The PPC team had a meeting on Sunday, April 30th. I've attached a
summary for those interested. Logs are available by request, (at least
until I get them added to ppc.gentoo.org).
Thanks,
- -Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG
On Saturday 29 April 2006 10:12, Mike Frysinger wrote:
On Saturday 29 April 2006 03:08, Alin Nastac wrote:
Carsten Lohrke wrote:
RDEPEND=cvs? ( dev-util/cvs )
svn? ( dev-util/subversion )
!cvs? ( ! svn? ( dev-util/cvs ) )
Huh? How about:
RDEPEND=|| ( dev-util/cvs
In an attempt to receive more comments and to request comments on the
virtual/config-manager, I have forwarded this mail here. Please comment
+ point out weird things wrong. I'd prefer to make either dispatch-conf
or cfg-update the default for the virtual, but I am definately open to
On Tuesday 02 May 2006 15:25, Dick wrote:
For example ethtool.h, which uses the u32 typedef defined in asm/types.h.
This typedef has been disabled outside the kernel to avoid name space
clashes which I think is a Good Thing.
that's because the sed used in kernel-2.eclass is slightly broken ...
Zac Medico wrote:
Well, it's been the tree for 2 days now we'll surely get bug reports
as soon as people run into these hypothetical issues (though I
expect very few, if any regressions). I think the globals cleanup
is worth having in 2.1 because it makes the code more maintainable.
Ack.
Here's a stab at pre10...
The order of application is the order of explanation:
globals.diff - remove most globals
main_emerge.diff - add __main__ section
emergelint.diff - remove some obvious lint issues (unused/non-existent vars)
emergepychecker.diff - remove unused (and repeated) imports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The 2006.1 release is scheduled for this coming August and there are
a lot of people counting on portage-2.1 being stable in time for
that release. In order to ensure that this happens, we need to stop
the addition of new features.
15 matches
Mail list logo
