control: affects -1 src:qutip On 2024-10-28 18:38, Aurelien Jarno wrote: > control: tag 1086108 + patch > > Hi, > > On 2024-10-28 09:56, Michael R. Crusoe wrote: > > On 26/10/2024 21.21, Aurelien Jarno wrote: > > > Source: scipy > > > Version: 1.13.1-5 > > > Severity: important > > > Tags: ftbfs upstream > > > X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org, > > > debian-ri...@lists.debian.org > > > User: debian-ri...@lists.debian.org > > > Usertags: riscv64 > > > Control: affects -1 + src:nipy > > > Control: found -1 scipy/1.14.0-1exp5 > > > > > > Dear maintainer, > > > > > > I have been debugging the cause of the FTBFS of nipy on riscv64. It > > > fails with [1]: > > > > > > | nipy/core/reference/tests/test_matrix_groups.py . > > > | E: Build killed with signal TERM after 600 minutes of inactivity > > > > > > I have been able to extract a minimal reproducer calling the SciPy expm > > > function: > > > > > > | #!/usr/bin/python3 > > > | > > > | import numpy as np > > > | from scipy.linalg import expm > > > | > > > | Z = np.array([[-0.83555296, 1.23536117, -0.54084919], > > > | [ 0.48341885, -0.55882754, -0.53693891], > > > | [-0.14802191, -0.43249490, 0.53730155]]) > > > | # Z = np.random.standard_normal((3,3)) > > > | > > > | orth = expm(Z - Z.T) > > > > > > The original code uses np.random.standard_normal but I changed that into > > > a static array to always use to the same code path. Debugging further, > > > it happens that the pick_pade_structure() in the Cython expm support > > > code is relying on undefined behaviour (UB) to convert a non-finite > > > floating point value to int in a few places [2]. According to the C++ > > > standard this is an undefined behaviour: > > > > > > | When a finite value of real floating type is converted to an integer > > > | type other than _Bool, the fractional part is discarded (i.e., the > > > | value is truncated toward zero). If the value of the integral part > > > | cannot be represented by the integer type, the behavior is undefined. > > > > > > On x86, the conversion returns 0, but on RISC-V it returns either > > > INT_MIN or INT_MAX depending on the sign of the floating point value. As > > > the result of this conversion is then used in a loop [3], this takes an > > > eternity to execute and just appears as endless. > > > > > > The problem has been fixed upstream as part of the rewrite of the Cython > > > code into C [4][5]. For what I understand this will go into SciPy 1.15. > > > > > > I am not sure how you want to get that fixed in the Debian package. I > > > see two options: > > > - Backport the upstream commits [4][5] > > > - Change the Cython code to check if number are finite before conversion > > > to int, and if not return 0. > > > > > > Please tell me what do you prefer, and I will work on the corresponding > > > patch. > > > > Dear Aurelien, > > > > Thank you very much for your research. I think the second option is safer > > and simpler. > > > > Thanks for your fast answer. Please find the patch attached, it should > work with both the scipy version in unstable and the one in > experimental. I tested it against the unstable version on both amd64 and > riscv64.
This problem is also the cause of the qutip FTBFS on risc64. As this package is in testing and this blocks the python 3.13 transition. I am therefore increasing the severity to serious. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
