On Tue, Feb 21, 2023 at 12:39:53AM +0200, Peter Pentchev wrote: > On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote: > > Hi, > > > > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道： > > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum <lu...@debian.org> > > > wrote: > > > > Source: python-zstandard > > > > Version: 0.19.0-3 > > > > Severity: serious > > > > Justification: FTBFS > > > > Tags: bookworm sid ftbfs > > > > User: lu...@debian.org > > > > Usertags: ftbfs-20230216 ftbfs-bookworm > > > > > > > > Hi, > > > > > > > > During a rebuild of all packages in sid, your package failed to build > > > > on amd64. > > > > > > At the moment this is creating quite > > > the havoc with making a bunch of things FTBFS as well (see merhged bugs) > > > > > > This is likely due to py-zst trying to link with the zstandard in the > > > archive > > > which does not seem to go very well. > > > > > > Is someone working to fix this? > > > > Thanks for cc-ing. I did not monitor bugs for this package before. > > > > Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it out > > and have it packaged. > > > > On the long run, the mismatch of src:libzstd and src:python-zstandard will > > always occur intermittently due to its nature. I am not sure whether re- > > enabling bundled libzstd would be a good choice, but at least let's fix the > > combination for Debian 12 first. > > > > Any suggestions? > > Oof. Sorry about that. I guess I didn't consider the python-zstandard > package at all until now. > > As I am a member of both the pkg-rpm and pkg-python teams, I could try to > update the packages in sync from now on, possibly adding something like > Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to > libzstd itself if it breaks the then-current python-zstandard package.
(of course, I meant Breaks: python3-zstandard (<< ...)) ...of course, another - or rather, an additional - option would be to relax (or remove) the check that python-zstandard makes regarding the libzstd version recorded at compile time. Since both libzstd upstream and the Debian package tries to hold true to the usual semver-like compatiblity scheme, python-zstandard ought to be able to believe that even a more recent version of libzstd would be ABI-compatible unless it has reason to think otherwise - and that case could be handled by Breaks: python3-zstandard (<< next-version) in libzstd as outlined above. So maybe (for future new upstream versions of libzstd): - relax (or remove) the python3-zstandard check for the libzstd version - each time a new libzstd upload is about to be done, check that python3-zstandard works, too - if it works, do nothing else, upload libzstd as usual - if python3-zstandard would for some reason break and needs updating, hold off with the libzstd upload until an updated version of python3-zstandard is released upstream, make sure it will work, and only then upload libzstd with a Breaks declaration - upload the updated version of python3-zstandard immediately (maybe even simultaneously) and declare a Depends relationship on the just-uploaded version of libzstd (as it does now) If this sounds good, I believe I can do it that way for future libzstd uploads. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
