Dear all,
Il 13/07/26 13:10, Adrian Bunk ha scritto:
On Mon, Jul 13, 2026 at 11:21:32AM +0200, Emilio Pozuelo Monfort wrote:
On 13/07/2026 06:42, Antonio Valentino wrote:
Dear Emilio,
On Mon, 6 Jul 2026 19:54:28 +0200 Emilio Pozuelo Monfort
<[email protected]> wrote:
Control: tags -1 moreinfo
On 06/07/2026 10:49, Antonio Valentino wrote:
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: [email protected], [email protected]
Control: affects -1 + src:c-blosc2
User: [email protected]
Usertags: transition
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.
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.
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?
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`.
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.
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.
That's a bad suggestion, wanna-build would try to build the packages
again after removal.
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.
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.
Cheers,
Emilio
cu
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).
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
,
--
Antonio Valentino
