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
Description: OpenPGP digital signature
