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
