Dear release team,

the upgrade from c-blosc2 v2.23.1 to v3.1.5 requires a change in the
SONAME and hence a transition. The new version is already in experimental.
The following source packages need to be rebuilt:

* adios2
* groonga
* pytables
* zmat

I have tested the above packages with the new version of c-blosc2.
Only for pytables it was necessary a small patch that has been already
uploaded.

pytables 3.11.1-2 is now in unstable and it should migrate to testing in
5 days.

Apart for that all the packages build successfully with the new c-blosc2
version that is currently in experimental.

Ben file:

title = "c-blosc2";
is_affected = .depends ~ "libblosc2-7" | .depends ~ "libblosc2-8";
is_good = .depends ~ "libblosc2-8";
is_bad = .depends ~ "libblosc2-7";

Control: tags -1 moreinfo

There's a few build failures in experimental:

https://buildd.debian.org/status/package.php?p=c-blosc2&suite=experimental

Please fix those in experimental first.

Cheers,
Emilio

Dear Emilio,

On Mon, 6 Jul 2026 19:54:28 +0200 Emilio Pozuelo Monfort <pochu@debian.org> wrote:

Thanks for the quick reply.
According to [1] 32bit architectures are no longer supported in c-blosc2
v3.x.

My plan would be just to request the removal of c-blosc2 package for
i386 and armhf from sid.
According to my understanding this should unblock the migration of the
new new c-blosc2 package to testing in a normal situation.
I'm not sure if this is fine for a transition (like in this case).
Do you have comments or any advice?



[1] https://github.com/Blosc/c-blosc2/issues/790



kind regards

You also need to request removal of reverse-(build-)dependencies, recursively.
According to my dak foo, there's a lot of rdeps, since pytables build-depends on
libblosc2-dev. There's other stuff, such as pandas, vtk9... You can run `dak rm
-Rn c-blosc2` on coccia, or play with `build-rdeps` and `apt-cache rdepends`.

If this has to happen, then it should happen in sid *before* the transition
starts, since the package removals can happen with the current version in sid.
Basically you'll have to find the set of packages that need to be dropped, then
file bugs against ftp.debian.org for each source package.

Cheers,
Emilio

c-blosc2 was never built on s390x, packages like pandas and vtk9 that
are available on s390x won't need removal. For vtk9 it isn't obvious
to me that it needs any change at all.

pytables and zmat might be the only packages that will need removal.

That's a bad suggestion, wanna-build would try to build the packages
again after removal.

Sorting this out is trivial for people who have experience doing that,
but asking someone without experience to do that could easily result
in a mess.

If you approve the transition, then I'll sort out whatever is needed
in rdeps.
Adrian

BTW: Build dependencies on architecture-is-64-bit and
     architecture-is-little-endian in c-blosc2 would be
     helpful to document that this is not supported
     (and avoid trying the known-failing builds).

Dear all,

Il 13/07/26 13:10, Adrian Bunk ha scritto:


Thanks a lot for supporting me and sorry for the late reply.

I have filed the following bugs against ftp.debian.org:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142138
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142140

for c-blosc2 and python3-tables-lib (that are maintained by me).

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).

According to my understanding adios2 already doesn't have packages for
armhf and i386.


As DM I do not have direct access to coccia.
I played a bit with apt rdepends and reverse-depends apt-rdepends.

The recursive list of reverse dependencies seems to be quite long and I
never did a mass bug filing.
I would definitively appreciate some help.


I will update the c-blosc2 package to build-depend on
architecture-is-64-bit and architecture-is-little-endian (thanks Adrian
for the hint).

Finally recently c-blosc2 v3.2 has been released upstream, and t
requires a new SOVERSION bump.

To avoid a double transition, I'm planning to upload to experimental the
latest c-blosc2 version.
Please let me know if you have a different advice, and if I can add to
#1141561 the new transition information or if I need to file a new
transition request.


kind regards
,

Hi,

[Alternative option at the bottom]


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


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.


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.


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