Bug#1094821: spglib: autopkgtest failure on 32 bits blocking ruby3.3 transition
Lucas Nussbaum
lucas at debian.org
Thu Feb 6 21:39:23 GMT 2025
On 06/02/25 at 14:30 +0100, Lucas Nussbaum wrote:
> On 31/01/25 at 17:14 +0200, Andrius Merkys wrote:
> > Hi,
> >
> > On 2025-01-31 15:54, Lucas Kanashiro wrote:
> > > spglib autopkgtest is failing on 32 bits architectures due to some
> > > issues with the python test suite:
> > >
> > > https://ci.debian.net/packages/s/spglib/testing/armel/57276728
> > > https://ci.debian.net/packages/s/spglib/testing/armhf/57232534/
> > > https://ci.debian.net/packages/s/spglib/testing/i386/57232539/
> > >
> > > Could you please fix it ASAP? Those failures are blocking the ruby3.3
> > > transition (check ruby-defaults tracker page).
> >
> > This is most likely caused by numpy2 transition. I will try to give it a
> > deeper look.
>
> I could reproduce the failure using:
> autopkgtest spglib --skip-test=command1 --apt-default-release=trixie --apt-upgrade --add-apt-release=unstable --pin-packages=unstable=src:ruby-defaults,src:spglib -- schroot testing-armhf
>
> It indeed looks like something related to numpy2, independent from the
> ruby-defaults transition: the newly built (against unstable) spglib
> packages pull in some transitioned packages that break it.
Digging a bit further,
1/ I confirmed that it has nothing to do with ruby (pybuild-autopkgtest
fails the same way with no ruby packages installed)
2/ It seems that the bottom line is: spglib built against numpy 2 (in
unstable) breaks when run against numpy 1 (in testing).
To reproduce:
- build spglib in unstable. (it builds and tests fine)
- install it
- downgrade python3-numpy to the version in testing (1:1.26.4+ds-13)
- run the test (it fails): python3.12 -m pytest test test/functional/python/test_reciprocal_mesh.py
I don't understand numpy enough to dig further.
Lucas
More information about the debian-science-maintainers
mailing list