On 24/06/2026 11:23, Drew Parsons wrote:
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?
The thing is that britney/debci don't care or don't know about the specifics of
a library transition. They just consider that one package (petsc) is trying to
migrate to testing. Since there are no 'Breaks' in place, it could
(theoretically) migrate on its own, with none of the rebuilds migrating. If that
were to happen, testing would end up with the old sundials and the new petsc, so
that's why those tests are being scheduled. If there were breaks (e.g. against
the old sundials, or against the old libpetsc), then britney would detect that
petsc can't migrate on its own, so that test combination no longer makes sense.
I'm not saying the solution here is to add breaks though.
This other failure is probably of a similar nature, although the test is quite
succinct:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfinx-mpc/72428997/log.gz
Since we in general don't want to add that kind of Breaks, because it makes
upgrades harder and is very unlikely that a system ends up in a mixed state,
I'll force the migration where needed. It'd be good to confirm that this last
test (dolfinx-mpc) falls in that situation, and perhaps make (in a future
upload) the test more verbose. As for the unreproducibility, since it's not a
regression, I'll ignore it for now. A little progress on that front (e.g. a bug
report somewhere appropriate) would be welcome, since this will bite us again in
the next transition.
Cheers,
Emilio
