Created attachment 898651 [details] emerge --info # emerge =dev-python/scipy-1.14.0 … Program f2py found: YES (/usr/bin/f2py) ../scipy-1.14.0/scipy/meson.build:156:15: ERROR: Command `/usr/bin/f2py -v` failed with status 1. A full log can be found at /var/tmp/portage/dev-python/scipy-1.14.0/work/scipy-1.14.0-python3_12/meson-logs/meson-log.txt # cat meson-log.txt: Program f2py found: YES (/usr/bin/f2py) Running command: /usr/bin/f2py -v --- stdout --- --- stderr --- Traceback (most recent call last): File "/usr/lib/python-exec/python3.12/f2py", line 5, in <module> from numpy.f2py.f2py2e import main File "/usr/lib/python3.12/site-packages/numpy/f2py/__init__.py", line 14, in <module> import subprocess File "/usr/lib/python3.12/subprocess.py", line 49, in <module> import signal File "/var/tmp/portage/dev-python/scipy-1.14.0/work/scipy-1.14.0/scipy/signal/__init__.py", line 307, in <module> from . import _sigtools, windows File "/var/tmp/portage/dev-python/scipy-1.14.0/work/scipy-1.14.0/scipy/signal/windows/__init__.py", line 42, in <module> from ._windows import * File "/var/tmp/portage/dev-python/scipy-1.14.0/work/scipy-1.14.0/scipy/signal/windows/_windows.py", line 7, in <module> from scipy import linalg, special, fft as sp_fft File "/var/tmp/portage/dev-python/scipy-1.14.0/temp/scipy.py", line 1, in <module> raise ImportError("hide real scipy") ImportError: hide real scipy ../scipy-1.14.0/scipy/meson.build:156:15: ERROR: Command `/usr/bin/f2py -v` failed with status 1. # f2py -v 2.0.1 So apparently it's something to do with portage's build environment breaking f2py?
import signal File "/var/tmp/portage/dev-python/scipy-1.14.0/work/scipy-1.14.0/scipy/signal/__init__.py", line 307, in <module> I don't really understand how it could possibly be reinterpreting "import signal" as "with ${S}/scipy in sys.path, import the signal module which happens to be a submodule of scipy". f2py is a script, it doesn't add $PWD to the sys.path even if it is running with $PWD as ${S}/scipy. And this does work fine for me. :/
In your emerge --info, I see this: PYTHONPATH="" This is a very bad idea, try deleting it. :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b97c692bdf00d06a3eace3c2aea88b5b9bc9d46a commit b97c692bdf00d06a3eace3c2aea88b5b9bc9d46a Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2024-07-30 18:53:27 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-07-31 03:51:37 +0000 dev-python/scipy: remove outdated workaround for pythran The upstream issue was fixed and released in 0.16, which is also the only version we package anymore. Bump the dependency to make sure people actually updated this bdep, and drop our hack. This also fixes the problem where people misdiagnose a faulty personal environment as a portage bug, due to setting PYTHONPATH="". Well... actually it may hide the issue entirely, if scipy.signal as the `signal` module doesn't actually get used. :) But that is beside the point. Bug: https://bugs.gentoo.org/936948 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> dev-python/scipy/scipy-1.14.0.ebuild | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-)
(In reply to Eli Schwartz from comment #2) > In your emerge --info, I see this: > > PYTHONPATH="" > > This is a very bad idea, try deleting it. :) $ cat /etc/portage/make.conf … # try to work around https://bugs.gentoo.org/789870 PYTHONPATH="" … Hmm I guess that tweak may be obsolete now that the relevant bug has been closed for 2 years
