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
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 o
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 abi
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 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 accep
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 upstre
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
-=| 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
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
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
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
differ
11 matches
Mail list logo
