- Package:
- release.debian.org
- Source:
- release.debian.org
- Submitter:
- Francesco Ballarin
- Date:
- 2026-06-26 11:07:02 UTC
- Severity:
- normal
- Tags:
Hi, we would like to request a transition of the numerical stack libraries, namely: - PETSc and petsc4py, from 3.24 to 3.25 - SLEPc and slepc4py, from 3.24 to 3.25 - mumps, from 5.8 to 5.9 - adios2, from 2.11 to 2.12 https://release.debian.org/transitions/html/auto-petsc.html https://release.debian.org/transitions/html/auto-slepc.html https://release.debian.org/transitions/html/auto-mumps.html https://release.debian.org/transitions/html/auto-adios2.html The transitions are in principle independent but, since they affect the same downstream packages and upstream source have released new versions roughly at the same time, we would like to proceed with a single transition for the whole stack. The most relevant downstream packages have been locally tested for compatibility. dolfinx, dolfinx-mpc and vtk9 built+tested correctly without any changes. dolfin, sundials and deal.ii have received a new upload upload in unstable for compatibility with PETSc 3.25. Cheers, Francesco
... Not independent as such. mumps first, it's used by petsc. Drew
Control: tags -1 confirmed Go ahead. Cheers, Emilio
Note that petsc is now BD-Uninstallable on 32 bit architectures. Please make it buildable or get the binaries of petsc and its reverse dependencies removed on those architectures. Cheers
Can vtk9 be rebuilt with adios2 already? It's in the opencv dependency chain which is now uninstallable in unstable. Kind Regards, Bas
Done Cheers
petsc has some reproducibility regressions, as well as some autopkgtest issues. Can you take a look? https://tracker.debian.org/pkg/petsc Cheers, Emilio
These are not actually regressions, but renamed unreproducible packages. 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] In this case it already fails due to related CMake issues, but running tests with two different soversions of a library linked would anyway be outside of what can be expected to work in the general case. cu Adrian
Control: tags 1135890 help I've been monitoring it. I'm really not sure what to do about it. The issue is not something obvious like a build date or random order of build flags. The libraries are simply getting their starting memory addresses with different numbers, why would that happen? And the fortran modules (*.mod) are getting their entries recorded in random order. I don't think petsc is doing anything deliberately to generate non-reproducibility like that. Help welcome.
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
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
... I think dolfinx-mpc is following the same logic. It's not showing red in any of the tracker pages, mind, it already passed. It passed tests with the new petsc 3.25 in https://ci.debian.net/packages/d/dolfinx-mpc/testing/amd64/71965048/ using the binNMU rebuilt dolfinx-mpc 0.10.5-1+b1. Drew
After some hints, petsc et al have migrated to testing. Closing this. Cheers, Emilio