Bug#1141561: transition: c-blosc2

Paul Gevers <[email protected]> Thu, 16 Jul 2026 07:59:06 +0200

Newsgroups	gmane.linux.debian.devel.release
Message-ID	<d83b98bc-f619-4de4-9ba7-adb2c3f4092d__28135.1848434255$1784181686$gmane$org@debian.org>

Hi,

[Alternative option at the bottom]

On 15-07-2026 22:26, Antonio Valentino wrote:
> Then I have filed the following bugs:
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142146
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142148
> 
> against libzmat1 and libgroonga0t64 respectively (severity normal).

I was confused for a second, luckily you filed them against ftp.debian.org.

> The recursive list of reverse dependencies seems to be quite long

More reason to deal with the removal before the transition happens. But 
one important aspect was already mentioned by Adrian, you need to 
prevent building the binaries on those architectures before the binaries 
are removed, otherwise they just build again. (So upload to unstable a 
newer Debian revision of the version in unstable that does that).

Reverse build dependencies don't need any action in the package by 
themselves, as once removed, they can't build if the binaries of 
c-blosc2 are gone, but regular reverse dependencies will need adaption 
to either stop depending, or stop building on those architectures.

> and I 
> never did a mass bug filing.

Right, but mass bug filings against ftp.debian.org are different in that 
sense. Also, if you could discuss with the archive team (if the list is 
really long) how do to this in one go. Please read on.

> I would definitively appreciate some help.

One thing that hasn't been brought up yet, is that you should judge for 
yourself too. While upstream doesn't support 32 bits and big-endian, you 
can try to see what that means. While a test suite may fail, I've seen 
often enough that the test suite has assumptions that aren't true on 
different architectures, but that the package itself is just fine. Also, 
it might be only mildly broken (e.g. some corner case). Then, is it in 
the interest of our users to fully remove it? There are no clear cut 
answers to that, but historically Debian has provided the binaries on 
more architectures than a lot of our upstreams support. That's also part 
of being Debian. If it looks like it's a test only issue, try fixing 
them (I assume upstream will still take the patch if that's the case) or 
skip them on those architectures where it doesn't work.

At least it's an option you have. For big-endian issues, the s390x 
porters are pretty good at this moment to help you.

Paul

OpenPGP_signature.asc (application/pgp-signature, 585 B)