Re: [PATCH v3] releases: use newer compression methods for tarballs

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/14/25 3:43 PM, Jan Beulich wrote:

> On 12.09.2025 23:23, Julien Grall wrote:
> > On 11/09/2025 09:14, Jan Beulich wrote:
> > > Other projects have long switched to xz and/or lzip.
> > >
> > > Tidy things some as well: With the removal of qemu from the tarball,
> > > intermediately extracting the tarball again has become wasteful. Drop
> > > that. Invoke compressors using asynchronous lists, to reduce overall
> > > latency. Drop the -v option from the (previously implicit) gzip
> > > invocation.
> > >
> > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > >         
> > I have tested manually the steps and the correct tarballs have been 
> > produced. I will update my scripts to copy & sign all the tarballs once 
> > this is merged.
> >
> > Acked-by: Julien Grall <jgrall@xxxxxxxxxx>
> > Tested-by: Julien Grall <jgrall@xxxxxxxxxx>
> >       
> Thanks.
>
> > Is this intended for Xen 4.21?
> >       
>     
IMO, it would be nice to have that in Xen 4.21.

> So far it was, but I'm increasingly unsure, seeing that it still hasn't
> gone in. Cc-ing Oleksii too now. Andrew had voiced concern towards the
> rm use, but hasn't come back as to his argument towards the uncompressed
> tarball previously not having been removed (when I can't see that one
> would have been created in the first place), hence why I couldn't make
> use of his (conditional) R-b.
>     
There is not too much sense in the uncompressed tarball. I prefer to not
generate it at all.

Also I have regarding .gz. If other projects switched to xz and/or
lzip (as it is mentioned in the commit message) what is the purpose of
having .gz tarball then?

~ Oleksii