On 2026-06-24 10:26, Adrian Bunk wrote:
On Wed, Jun 24, 2026 at 09:29:53AM +0200, Emilio Pozuelo Monfort wrote:
> - PETSc and petsc4py, from 3.24 to 3.25
as well as some autopkgtest issues. Can you take a look?
https://tracker.debian.org/pkg/petsc
This is the usual problem that the release team wants smooth
transitions,
but Breaks between different soversions of a library would be correct:
40s Get:253 http://deb.debian.org/debian unstable/main amd64
libpetsc-real3.25-dev amd64 3.25.2+dfsg1-1 [14.3 MB]
40s Get:254 http://deb.debian.org/debian unstable/main amd64
libpetsc-real-dev all 3.25.2+dfsg1-1 [12.6 kB]
40s Get:255 http://deb.debian.org/debian testing/main amd64
libpetsc-real3.24 amd64 3.24.5+dfsg1-2 [7,959 kB]
I'm a bit confused what's going on with the tests. I guess you mean the
sundials tests.
We don't usually have to place an explicit Breaks with the old version
(it would be sort of disruptive to do that,
undermining the reason for creating different abi packages.
Otherwise why not just have one unversioned libpetsc package?).
The dependent packages get rebuilt as part of the transition process
and the transition normally just goes through once they're done
without needing Breaks (tests need to be made with the rebuilt versions
of course).
These sundials tests are confusing me.
https://ci.debian.net/packages/s/sundials/testing/amd64/72397287/
is testing the old (not rebuilt) version 7.1.1+dfsg1-12 of sundials
against the new petsc 3.25, so of course it fails.
https://ci.debian.net/packages/s/sundials/testing/amd64/72376730/
uses the new bin-NMU rebuilt version 7.1.1+dfsg1-12+b1
and so passes with the new petsc 3.25.
Why isn't 72376730 being used instead of 72397287 for the transition?
Drew
