Source: lmfit-py Version: 1.3.3-5 Followup-For: Bug #1118038 In my previous message I said the problem (for scipy migration) was that lmfit-py 1.3.3-5 had migrated to testing even though it's failing the test reported in this bug.
The problem is not quite as simple as that. There was no change in lmfit-py 1.3.3-5 that would affect execution, and it is still passing its own tests in testing. It also passed tests with scipy/1.16.2-4 in testing, https://ci.debian.net/data/autopkgtest/testing/amd64/l/lmfit-py/65515026/log.gz Conversely there was no change in scipy/1.16.2-5 that would affect execution. It looks like the timing of the new lmfit-py test failures is a coincidence with respect to the package versions lmfit-py/1.3.3-5 and scipy/1.16.2-5. That is, I suspect the bug is triggered by some other package that happens to be migrating to testing at the same time. Probably not python3.13/3.13.9-1, which provides json/encoder.py, since it had already migrated earlier than these test failures. Possibly triggered by numpy/1:2.3.3+ds-3 which has only just migrated to testing? The last successful test of lmfit-py with scipy/1.16.2-4 used numpy/1:2.2.4+ds-1.2 On the other hand lmfit-py is passing with numpy/1:2.3.3+ds-3 (with scipy 1.15.3-1.1) https://ci.debian.net/data/autopkgtest/testing/amd64/l/lmfit-py/65690136/log.gz Is it the combination of scipy 1.16 with numpy 2.3 that is triggering the lmfit-py failure?
