Roger Leigh dixit:
Possibly a stupid question here but: Given that we are now autosigning
builds, why can't the slower arches use gzip, and then after upload
they could be recompressed with xz (and resigned) on a faster arch?
xz -2 is fast enough on m68k (IIRC, compresses not worse than bzip2
Le Mon, Aug 15, 2011 at 01:48:50AM +0200, Adam Borowski a écrit :
* A year ago, I repacked CD1, .xz took 66% space needed by .gz. This time,
on the whole archive, gains are somewhat smaller: 72%. I guess that CD1
is code-heavy while packages of lower priorities tend to have more data.
Hi,
2011/8/15 Eduard Bloch e...@gmx.de:
#include hallo.h
* Roger Leigh [Sun, Aug 14 2011, 11:01:11PM]:
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
On 11/08/11 at 19:52 +, Philipp Kern wrote:
Wouldn't it be better to get more buildds for those archs, then?
That
On Mon, Aug 15, 2011 at 06:38:28AM +0200, Tollef Fog Heen wrote:
]] Adam Borowski
| Does someone have an estimate how many core-hours would an archive rebuild
| on such a machine take? Folks on IRC quoted numbers like 340, 240 on a
| very fast box, more like 1500 -- too divergent for
Hi there!
On Mon, 15 Aug 2011 10:16:55 +0200, Charles Plessy wrote:
Also, many files in /usr/share/doc are gzipped as per §12.3;
[...]
- Most systems have enough space to keep them uncompressed,
Which alone is not a good reason to not compress them.
Perhaps we could consider allowing xz
On Mon, Aug 15, 2011 at 11:25:42AM +0200, Luca Capello wrote:
What about zless Co.? Are they available for xz as well?
xz-utils contains xzless, xzcat etc.
--
WBR, wRAR
signature.asc
Description: Digital signature
Hi,
I'm happy to hear xz support. Some font packages can get huge profit with
this (e.g. fonts-vlgothic: 4924KB - 2132KB (half! :)
On Thu, 11 Aug 2011 19:52:46 + (UTC)
Philipp Kern tr...@philkern.de wrote:
It takes a lot longer to compress on slower architectures (i.e. on the
buildds),
On 11/08/11 at 19:52 +, Philipp Kern wrote:
On 2011-08-11, Adam Borowski kilob...@angband.pl wrote:
Think of both user systems and the Debian buildds which will waste more
time - an especially bad problem on slower architectures.
The gain is especially meaningful for slower
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
On 11/08/11 at 19:52 +, Philipp Kern wrote:
On 2011-08-11, Adam Borowski kilob...@angband.pl wrote:
Think of both user systems and the Debian buildds which will waste more
time - an especially bad problem on slower
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
Of course, it might require finding more buildd maintainers. But I must
admit that I have no idea what buildd admins spend time on, and how it's
possible to help them.
A life in the day of a buildd maintainer would not be a bad
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
On 11/08/11 at 19:52 +, Philipp Kern wrote:
On 2011-08-11, Adam Borowski kilob...@angband.pl wrote:
Think of both user systems and the Debian buildds which will waste more
time - an especially bad problem on slower
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
On 11/08/11 at 19:52 +, Philipp Kern wrote:
On 2011-08-11, Adam Borowski kilob...@angband.pl wrote:
Think of both user systems and the Debian buildds which will waste more
time - an especially bad problem on slower
On Sun, Aug 14, 2011 at 11:01:11PM +0100, Roger Leigh wrote:
Possibly a stupid question here but: Given that we are now autosigning
builds, why can't the slower arches use gzip, and then after upload
they could be recompressed with xz (and resigned) on a faster arch?
This would allow xz
Raphael Hertzog wrote:
Nope, sorry. I was referring to things like GNOME shipping only .tar.xz.
I mean they would not take such a decision if getting an xz decompressor
was a pain on many systems.
There is a large distance between systems on which users are likely to
build gnome from scratch
#include hallo.h
* Roger Leigh [Sun, Aug 14 2011, 11:01:11PM]:
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
On 11/08/11 at 19:52 +, Philipp Kern wrote:
Wouldn't it be better to get more buildds for those archs, then?
That would be a totally appropriate use of Debian
]] Adam Borowski
| Does someone have an estimate how many core-hours would an archive rebuild
| on such a machine take? Folks on IRC quoted numbers like 340, 240 on a
| very fast box, more like 1500 -- too divergent for my liking. The
| first number, 340, would mean switching to xz
On Thu, 11 Aug 2011, Colin Watson wrote:
Since hardcoding gzip for base packages seems to be a bit brittle,
we need to work towards allowing xz usage in debian-installer and accept
it as a dependency for deboostrap on non-Debian systems (I don't think
it's a big issue, xz is portable and
On Fri, Aug 12, 2011 at 02:50:32PM +0200, Raphael Hertzog wrote:
On Thu, 11 Aug 2011, Colin Watson wrote:
Can you quantify that? I don't have hard numbers for the non-Debian
systems where people report running debootstrap; perhaps you do ...
Nope, sorry. I was referring to things like
On Thu, Aug 11, 2011 at 05:12:36PM +0200, Ansgar Burchardt wrote:
Hi,
The archive software now accepts packages using xz for compression in
addition to gzip and bzip2 for both source and binary packages.
Hurray!
please only use xz (or bzip2 for that matter) if your
package really profits
On 2011-08-11, Adam Borowski kilob...@angband.pl wrote:
Think of both user systems and the Debian buildds which will waste more
time - an especially bad problem on slower architectures.
The gain is especially meaningful for slower architectures, as they tend to
have less disk space and slower
Hi,
On Thu, 11 Aug 2011, Adam Borowski wrote:
Thus, I'd strongly recommend just compressing everything with xz, on all
architectures. Preferably, as a default in dpkg-dev.
I am very much in favor of this as well but after having discussed this
at debconf with Colin Watson and Joey Hess, I'm
On Thu, Aug 11, 2011 at 09:19:55PM +0200, Raphael Hertzog wrote:
As Ansgar mentionned, it creates a new requirement: for debootstrap to work
xz must be present and it's currently not present in debian-installer.
The main thing I consider to be difficult is that putting xz-compressed
packages in
22 matches
Mail list logo
