scipy failed to build from source in Fedora rawhide/f35 https://koji.fedoraproject.org/koji/taskinfo?taskID=72506709 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild Please fix scipy at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, scipy will be orphaned. Before branching of Fedora 36, scipy will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 1808799 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 1808800 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1808801 [details] state.log
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
This seems to be a problem with lapack package. I wrote a Fortran program that uses liblapack directly (it resembles <scipy.linalg.tests.test_decomp.TestSchur> lhp sort test) and it gives different result on F33 and F36.
Thanks Matěj! Could you file a bug against lapack then?
I managed to reach Lapack upstream. It seems that the Lapack library still gives valid results (despite of being different). https://github.com/Reference-LAPACK/lapack/issues/628
(In reply to Matej Mužila from comment #7) > I managed to reach Lapack upstream. It seems that the Lapack library still > gives valid results (despite of being different). > > https://github.com/Reference-LAPACK/lapack/issues/628 Matěj, does this mean the test(s) need to be modified to account for different results of DGEES? It still fails with scipy 1.7.2.
(In reply to Nikola Forró from comment #8) > (In reply to Matej Mužila from comment #7) > > I managed to reach Lapack upstream. It seems that the Lapack library still > > gives valid results (despite of being different). > > > > https://github.com/Reference-LAPACK/lapack/issues/628 > > Matěj, does this mean the test(s) need to be modified to account for > different results of DGEES? It still fails with scipy 1.7.2. If I understand upstream's explanation [1] correctly, then yes. It seems that the Schur decomposition can have more than one valid outputs for an input. It means that the result expected by the testsuite is valid, but it is not the only valid result possible. Implementation of lapack have changed, thus now it returns a different result from set of possible results. [1] https://github.com/Reference-LAPACK/lapack/issues/628#issuecomment-940023706
219 are blocked by this for Python 3.11 rebuild. Bumping severity accordingly.
Sorry, I've been working on this (together with a rebase to 1.8.0), there is one i686 issue left, I'll try to resolve it ASAP.
(In reply to Matej Mužila from comment #9) > If I understand upstream's explanation [1] correctly, then yes. It seems > that the Schur decomposition can have more than one valid outputs for an > input. It means that the result expected by the testsuite is valid, but it > is not the only valid result possible. Implementation of lapack have > changed, thus now it returns a different result from set of possible results. > > [1] > https://github.com/Reference-LAPACK/lapack/issues/628#issuecomment-940023706 Here is an upstream issue for this: https://github.com/scipy/scipy/issues/14517
The FTBFS should be resolved with rebase to 1.8.0 (bug #2035126).