Yaakov (Cygwin/X | 1 Feb 03:11
Picon

Re: tar.xz packages?

On Tue, 2012-01-31 at 03:37 +0100, Corinna Vinschen wrote:
> I'm not quite sure, but isn't it right that setup is capable of handling
> xz compressed tar files in the meantime?

I have a patch for cygport to generate xz packages ready, which will fix
this for many packagers.  Whatever others are using to build their
packages (including netrel?) would still need to be patched.

On Tue, 2012-01-31 at 15:37 -0500, Christopher Faylor wrote:
> I'll have to find an xz module for perl to get this working with
> Cygwin.  

Compress-Raw-Lzma and IO-Compress-Lzma (which requires the former) both
support XZ.

> If we decide this is desirable, do we just convert the entire
> release?  It would make things slightly easier for upset if it didn't
> have to know about multiple formats.

But upset should already support both gz and bz2, so multiple formats
are already supported; would adding xz be that much work?

> Yes, I know.  The mirrors! The mirrors! They will have to download the
> equivalent of 1.5 times a full release!

An alternative would be to repack only the binary tarballs, not the
source ones.  The -src tarballs are generally barely compressed anyway
(since the bulk of the contents is a compressed tarball which doesn't
gain anything by recompression), so the few bytes we'd save by switching
them from bz2 to xz certainly aren't worth the bandwidth it would cost
(Continue reading)

Yaakov (Cygwin/X | 1 Feb 03:41
Picon

Re: tar.xz packages?

On Tue, 2012-01-31 at 20:11 -0600, Yaakov (Cygwin/X) wrote:
> > Yes, I know.  The mirrors! The mirrors! They will have to download the
> > equivalent of 1.5 times a full release!
> 
> An alternative would be to repack only the binary tarballs, not the
> source ones.  The -src tarballs are generally barely compressed anyway
> (since the bulk of the contents is a compressed tarball which doesn't
> gain anything by recompression), so the few bytes we'd save by switching
> them from bz2 to xz certainly aren't worth the bandwidth it would cost
> to update the mirrors.

FWIW, I tried this with a copy of the Ports repo, and the disk usage
savings was ~8.26% (10614 MiB -> 9736.61 MiB).  A similar result with
the distro would shrink release/ from ~7358 MiB to 6750 MiB.

Yaakov

Christopher Faylor | 1 Feb 06:23
Favicon

Re: tar.xz packages?

On Tue, Jan 31, 2012 at 08:11:20PM -0600, Yaakov (Cygwin/X) wrote:
>On Tue, 2012-01-31 at 03:37 +0100, Corinna Vinschen wrote:
>> I'm not quite sure, but isn't it right that setup is capable of handling
>> xz compressed tar files in the meantime?
>
>> If we decide this is desirable, do we just convert the entire
>> release?  It would make things slightly easier for upset if it didn't
>> have to know about multiple formats.
>
>But upset should already support both gz and bz2, so multiple formats
>are already supported; would adding xz be that much work?

  slight·ly
  Adverb:	
      To a small degree; inconsiderably.

I would rather strip gz support in upset (and maybe even setup.exe) and
just standardize everything on .xz rather than complicate upset.

>> Yes, I know.  The mirrors! The mirrors! They will have to download the
>> equivalent of 1.5 times a full release!
>
>An alternative would be to repack only the binary tarballs, not the
>source ones.  The -src tarballs are generally barely compressed anyway
>(since the bulk of the contents is a compressed tarball which doesn't
>gain anything by recompression), so the few bytes we'd save by switching
>them from bz2 to xz certainly aren't worth the bandwidth it would cost
>to update the mirrors.

As I said above, as far as the mirrors are concerned, it's a one time
(Continue reading)

Corinna Vinschen | 1 Feb 10:15
Favicon

Re: tar.xz packages?

On Feb  1 00:23, Christopher Faylor wrote:
> On Tue, Jan 31, 2012 at 08:11:20PM -0600, Yaakov (Cygwin/X) wrote:
> >On Tue, 2012-01-31 at 03:37 +0100, Corinna Vinschen wrote:
> >> I'm not quite sure, but isn't it right that setup is capable of handling
> >> xz compressed tar files in the meantime?
> >
> >> If we decide this is desirable, do we just convert the entire
> >> release?  It would make things slightly easier for upset if it didn't
> >> have to know about multiple formats.
> >
> >But upset should already support both gz and bz2, so multiple formats
> >are already supported; would adding xz be that much work?
> 
>   slight·ly
>   Adverb:	
>       To a small degree; inconsiderably.
> 
> I would rather strip gz support in upset (and maybe even setup.exe) and
> just standardize everything on .xz rather than complicate upset.

I would rather see upset support .bz2 and .xz.  It's not only about the
mirrors.  Not every package is packed using cygport and some packages
have upstream scripts to create Cygwin packages, openssl for instance.
So a packaging change also requires an upstream patch.  Sure, this is
fixable, but we're all maintaining our packages voluntarily and it's
much more fun if things are taken easily, not under pressure.

> >> Yes, I know.  The mirrors! The mirrors! They will have to download the
> >> equivalent of 1.5 times a full release!
> >
(Continue reading)

Jari Aalto | 1 Feb 10:33
Favicon
Gravatar

Re: tar.xz packages (can it already be used?)

2012-02-01 11:15 Corinna Vinschen:
| > >But upset should already support both gz and bz2, so multiple formats
| > >are already supported; would adding xz be that much work?
|
| ... keep the existing packages as .bz2 and change to .xz by updating one
| at a time?

Just to confirm: all new upload requests can be (are prefered?) in *.xz
format?

Jari

Corinna Vinschen | 1 Feb 10:48
Favicon

Re: tar.xz packages (can it already be used?)

On Feb  1 11:33, Jari Aalto wrote:
> 2012-02-01 11:15 Corinna Vinschen:
> | > >But upset should already support both gz and bz2, so multiple formats
> | > >are already supported; would adding xz be that much work?
> |
> | ... keep the existing packages as .bz2 and change to .xz by updating one
> | at a time?
> 
> Just to confirm: all new upload requests can be (are prefered?) in *.xz
> format?

Not yet.  Upset can't handle .xz so far so it's a bit early.

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Jari Aalto | 1 Feb 10:55
Favicon
Gravatar

RFU pristine-tar 1.18-1

wget --recursive --no-host-directories --cut-dirs=3 \
    http://cante.net/~jaalto/tmp/cygwin/pristine-tar/pristine-tar-1.18-1-src.tar.bz2 \
    http://cante.net/~jaalto/tmp/cygwin/pristine-tar/pristine-tar-1.18-1.tar.bz2 \
    http://cante.net/~jaalto/tmp/cygwin/pristine-tar/setup.hint

New upstream release just come out with XZ support,
Jari

Jari Aalto | 1 Feb 11:02
Favicon
Gravatar

Re: RFU pngcrush 1.7.24 -- Optimize PNG image files

2012-01-30 12:00 Corinna Vinschen:
| On Jan 29 15:35, Jari Aalto wrote:
| >
| > New upstream release:
| >
| > wget --recursive --no-host-directories --cut-dirs=3 \
| >    
http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.24.20120129+git33373b7-1-src.tar.bz2 \
| >    
http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.24.20120129+git33373b7-1.tar.bz2 \
| >     http://cante.net/~jaalto/tmp/cygwin/pngcrush/setup.hint
|
| Is that really right?  The old pngcrush was 68K and linked against
| libpng12 and zlib, while the new one is 435K and not linked against
| anything.  Do you really want static linking? pngcrush won't see
| any security update to libpng or zlib without rebuilding.  I don't
| think that's the right thing to do.

The latest release does not compile againt png14 that is in Cygwin.

Due to linking problems in various platforms the upstream seems to have
decided to embed new zlib (1.2.5) and libpng (1.5.7) with the code and make
program static.

Jari

Corinna Vinschen | 1 Feb 11:19
Favicon

Re: RFU pngcrush 1.7.24 -- Optimize PNG image files

On Feb  1 12:02, Jari Aalto wrote:
> 2012-01-30 12:00 Corinna Vinschen:
> | On Jan 29 15:35, Jari Aalto wrote:
> | >
> | > New upstream release:
> | >
> | > wget --recursive --no-host-directories --cut-dirs=3 \
> | >    
http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.24.20120129+git33373b7-1-src.tar.bz2 \
> | >    
http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.24.20120129+git33373b7-1.tar.bz2 \
> | >     http://cante.net/~jaalto/tmp/cygwin/pngcrush/setup.hint
> |
> | Is that really right?  The old pngcrush was 68K and linked against
> | libpng12 and zlib, while the new one is 435K and not linked against
> | anything.  Do you really want static linking? pngcrush won't see
> | any security update to libpng or zlib without rebuilding.  I don't
> | think that's the right thing to do.
> 
> The latest release does not compile againt png14 that is in Cygwin.
> 
> Due to linking problems in various platforms the upstream seems to have
> decided to embed new zlib (1.2.5) and libpng (1.5.7) with the code and make
> program static.

Ok.  Uploaded.

Thanks,
Corinna

(Continue reading)

Corinna Vinschen | 1 Feb 11:22
Favicon

Re: RFU pristine-tar 1.18-1

On Feb  1 11:55, Jari Aalto wrote:
> wget --recursive --no-host-directories --cut-dirs=3 \
>     http://cante.net/~jaalto/tmp/cygwin/pristine-tar/pristine-tar-1.18-1-src.tar.bz2 \
>     http://cante.net/~jaalto/tmp/cygwin/pristine-tar/pristine-tar-1.18-1.tar.bz2 \
>     http://cante.net/~jaalto/tmp/cygwin/pristine-tar/setup.hint

Uploaded.

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Gmane