Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1987993 - scipy: FTBFS in Fedora rawhide/f35
Summary: scipy: FTBFS in Fedora rawhide/f35
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: scipy
Version: 35
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Nikola Forró
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PYTHON3.10 F35FTBFS F36FTBFS PYTHON3.11 F37FTBFS
TreeView+ depends on / blocked
 
Reported: 2021-07-29 17:37 UTC by Fedora Release Engineering
Modified: 2022-03-28 13:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-28 13:33:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (deleted)
2021-07-29 17:37 UTC, Fedora Release Engineering
no flags Details
root.log (deleted)
2021-07-29 17:37 UTC, Fedora Release Engineering
no flags Details
state.log (deleted)
2021-07-29 17:37 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2021-07-29 17:37:30 UTC
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/

Comment 1 Fedora Release Engineering 2021-07-29 17:37:35 UTC
Created attachment 1808799 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2021-07-29 17:37:39 UTC
Created attachment 1808800 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2021-07-29 17:37:40 UTC
Created attachment 1808801 [details]
state.log

Comment 4 Ben Cotton 2021-08-10 13:30:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 5 Matej Mužila 2021-09-22 06:42:06 UTC
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.

Comment 6 Nikola Forró 2021-09-28 15:39:11 UTC
Thanks Matěj! Could you file a bug against lapack then?

Comment 7 Matej Mužila 2021-10-11 14:07:16 UTC
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

Comment 8 Nikola Forró 2021-11-08 12:59:24 UTC
(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.

Comment 9 Matej Mužila 2021-11-08 13:38:35 UTC
(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

Comment 10 Miro Hrončok 2022-03-22 13:03:36 UTC
219 are blocked by this for Python 3.11 rebuild. Bumping severity accordingly.

Comment 11 Nikola Forró 2022-03-23 09:19:04 UTC
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.

Comment 12 Nikola Forró 2022-03-28 13:25:29 UTC
(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

Comment 13 Nikola Forró 2022-03-28 13:33:02 UTC
The FTBFS should be resolved with rebase to 1.8.0 (bug #2035126).


Note You need to log in before you can comment on or make changes to this bug.