On Sun, 16 Mar 2025 14:33:23 + Simon McVittie
wrote:
> On Sun, 16 Mar 2025 at 14:28:52 +, Luca Boccassi wrote:
> >I'll try to look into fixing python3-zstandard, it's unfortunate
that
> >the zstd transition was started to late
>
> It's a bit of a weird transition, because upgrading a libr
On Sun, 16 Mar 2025 at 14:28:52 +, Luca Boccassi wrote:
I'll try to look into fixing python3-zstandard, it's unfortunate that
the zstd transition was started to late
It's a bit of a weird transition, because upgrading a library to a new
micro version with no new SONAME and no API/ABI break
On Sun, 16 Mar 2025 at 14:26, Simon McVittie wrote:
>
> On Sun, 16 Mar 2025 at 13:07:50 +, Luca Boccassi wrote:
> >This is only a corner case anyway, kernel images should use zboot
> >instead of shipping compressed files, as firmwares cannot handle that
> >anyway. It's only an issue with some
On Sun, 16 Mar 2025 at 13:07:50 +, Luca Boccassi wrote:
This is only a corner case anyway, kernel images should use zboot
instead of shipping compressed files, as firmwares cannot handle that
anyway. It's only an issue with some Ubuntu architectures other than
x86_64.
Should python3-zstanda
Control: tags -1 wontfix
Control: close -1
On Sun, 16 Mar 2025 12:44:57 + Simon McVittie
wrote:
> Package: systemd-ukify
> Version: 257.4-3
> Severity: wishlist
> Tags: upstream
>
> systemd-ukify currently supports zstd decompression by using
> python3-zstandard, which is a hard dependency;
Package: systemd-ukify
Version: 257.4-3
Severity: wishlist
Tags: upstream
systemd-ukify currently supports zstd decompression by using
python3-zstandard, which is a hard dependency; but python3-zstandard
seems to require source changes every time libzstd is upgraded as a
result of having been d
6 matches
Mail list logo
