On Tuesday 5 June 2007 06:54, Roberto C. Sánchez wrote:
Yes. But then what of projects like OpenOffice.org and gcc?
No one has said that bzip2 should be *required* as a compression format, only
a possibility. I see the use in that: I've seen several upstreams shifting
from gzip to providing
On Tue, Jun 05, 2007 at 03:06:16PM +0200, Thijs Kinkhorst wrote:
On Tuesday 5 June 2007 06:54, Roberto C. Sánchez wrote:
Yes. But then what of projects like OpenOffice.org and gcc?
No one has said that bzip2 should be *required* as a compression format, only
a possibility. I see the use
On Sat, Jun 02, 2007 at 12:26:22PM -0400, Simon wrote:
screwing that up. I don't see why the build system isn't just
extended to handle bz2 files, it's one of the things that bugs me
about debian packaging.
That's happening - support for bzip2 compressed tarballs is in dpkg-dev
in etch so it
On 6/2/07, Roberto C. Sánchez [EMAIL PROTECTED] wrote:
Because on some architectures, there are not 2 GHz dual-core or
quad-core CPUs available. Making them take double or triple the time
for a 10% gain space is probably not acceptable.
It's not about saving space, it's about handling
On Mon, Jun 04, 2007 at 09:31:24PM -0400, Simon wrote:
On 6/2/07, Roberto C. Sánchez [EMAIL PROTECTED] wrote:
Because on some architectures, there are not 2 GHz dual-core or
quad-core CPUs available. Making them take double or triple the time
for a 10% gain space is probably not acceptable.
On Tue, 2007-06-05 at 00:54 -0400, Roberto C. Sánchez wrote:
I am relatively certain that on those machines, the speed boost of
using
gzip compression over bzip2 compression is probably quite necessary in
the ability of those machines which are being used as buildds to keep
up.
This
On Tue, Jun 05, 2007 at 02:59:16PM +1000, Robert Collins wrote:
On Tue, 2007-06-05 at 00:54 -0400, Roberto C. Sánchez wrote:
I am relatively certain that on those machines, the speed boost of
using
gzip compression over bzip2 compression is probably quite necessary in
the ability of
-=| Giorgio Pioda, Sat, 02 Jun 2007 17:14:29 +0200 |=-
If I try to recompress peless-1.125.tar.bz2 to peless-1.125.tar.gz (as
suggested above) the md5sum changes, and doesn't correspond to md5sum
of the peless_1.125.orig.tar.gz generated by uupdate. I actually get 3
different md5sums!
But the
Hi Damyan and mentors,
just a very stupid question (sorry!) about tarball formats:
About building a debian package using uupdate (where the former source
was in tar.gz and the update in tar.bz2) I got the comment that the
md5sum of the original upstream source and of the debian source were
On 6/2/07, Giorgio Pioda [EMAIL PROTECTED] wrote:
Damyan, you answered the following:
What you should do in this case is to re-compress the tarfile with
something like bzcat some.tar.bz2 | gzip -9 some.tar.gz. This way
the tar itself will remain exactly the same. In any case, no need to
On Sat, Jun 02, 2007 at 12:26:22PM -0400, Simon wrote:
I don't see why the build system isn't just
extended to handle bz2 files, it's one of the things that bugs me
about debian packaging.
Because on some architectures, there are not 2 GHz dual-core or
quad-core CPUs available. Making them
11 matches
Mail list logo
