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

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]


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@suse.com>
>> 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@amazon.com>
>> Tested-by: Julien Grall<jgrall@amazon.com>
> 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

[-- Attachment #2: Type: text/html, Size: 2691 bytes --]