I'm not sure how urgent this is for Fedora, but if it is blocking for now those can be skipped with a local patch, they're flaky since the shift to meson didn't fully convert the testsuite..

EDIT: From the log it seems (expected) that all the F2PY tests fail. The public API failure is unexpected.

What's the best way to do that as the testsuite currently is?

The easiest way would be to apply this patch:

diff --git c/numpy/f2py/tests/test_compile_function.py i/numpy/f2py/tests/test_compile_function.py
index 3c16f3198..e38fed898 100644
--- c/numpy/f2py/tests/test_compile_function.py
+++ i/numpy/f2py/tests/test_compile_function.py
@@ -17,6 +17,10 @@ def setup_module():
         pytest.skip("Needs C compiler")
     if not util.has_f77_compiler():
         pytest.skip("Needs FORTRAN 77 compiler")
+    if sys.version_info[:2] >= (3, 12):
+        pytest.skip(
+            "F2PY compilation tests do not work with meson."
+        )
 
 
 # extra_args can be a list (since gh-11937) or string.

I can't see the public API failure in the log (or the issue) clearly though, its truncated. Here is the complete error (from the linked build.log):

74259   │         if modnames:
74260   │ >           raise AssertionError(f'Found unexpected modules: {modnames}')
74261   │ E           AssertionError: Found unexpected modules: ['numpy.distutils', 'numpy.dis
        │ tutils.armccompiler', 'numpy.distutils.ccompiler', 'numpy.distutils.ccompiler_opt', 
        │ 'numpy.distutils.command', 'numpy.distutils.command.autodist', 'numpy.distutils.comm
        │ and.bdist_rpm', 'numpy.distutils.command.build', 'numpy.distutils.command.build_clib
        │ ', 'numpy.distutils.command.build_ext', 'numpy.distutils.command.build_py', 'numpy.d
        │ istutils.command.build_scripts', 'numpy.distutils.command.build_src', 'numpy.distuti
        │ ls.command.config', 'numpy.distutils.command.config_compiler', 'numpy.distutils.comm
        │ and.develop', 'numpy.distutils.command.egg_info', 'numpy.distutils.command.install',
        │  'numpy.distutils.command.install_clib', 'numpy.distutils.command.install_data', 'nu
        │ mpy.distutils.command.install_headers', 'numpy.distutils.command.sdist', 'numpy.dist
        │ utils.conv_template', 'numpy.distutils.core', 'numpy.distutils.cpuinfo', 'numpy.dist
        │ utils.exec_command', 'numpy.distutils.extension', 'numpy.distutils.fcompiler', 'nump
        │ y.distutils.fcompiler.absoft', 'numpy.distutils.fcompiler.arm', 'numpy.distutils.fco
        │ mpiler.compaq', 'numpy.distutils.fcompiler.environment', 'numpy.distutils.fcompiler.
        │ fujitsu', 'numpy.distutils.fcompiler.g95', 'numpy.distutils.fcompiler.gnu', 'numpy.d
        │ istutils.fcompiler.hpux', 'numpy.distutils.fcompiler.ibm', 'numpy.distutils.fcompile
        │ r.intel', 'numpy.distutils.fcompiler.lahey', 'numpy.distutils.fcompiler.mips', 'nump
        │ y.distutils.fcompiler.nag', 'numpy.distutils.fcompiler.none', 'numpy.distutils.fcomp
        │ iler.nv', 'numpy.distutils.fcompiler.pathf95', 'numpy.distutils.fcompiler.pg', 'nump
        │ y.distutils.fcompiler.sun', 'numpy.distutils.fcompiler.vast', 'numpy.distutils.from_
        │ template', 'numpy.distutils.fujitsuccompiler', 'numpy.distutils.intelccompiler', 'nu
        │ mpy.distutils.lib2def', 'numpy.distutils.line_endings', 'numpy.distutils.log', 'nump
        │ y.distutils.mingw32ccompiler', 'numpy.distutils.misc_util', 'numpy.distutils.msvc9co
        │ mpiler', 'numpy.distutils.msvccompiler', 'numpy.distutils.npy_pkg_config', 'numpy.di
        │ stutils.numpy_distribution', 'numpy.distutils.pathccompiler', 'numpy.distutils.syste
        │ m_info', 'numpy.distutils.unixccompiler']

Which seems to suggest that there's something amiss with the source files since those modules should not be present on 3.12? Could you open a separate issue for that since its unrelated to the F2PY bug?

Could that be from the numpy installed on the system being used to build?

Could that be from the numpy installed on the system being used to build?

Actually that might be it! Also most of the tests (except one) actually pass locally with 3.12 for f2py as well so it might just be because the wrong files are picked up..

We're not building with Meson yet, can we patch out that one too?

We're not building with Meson yet, can we patch out that one too?

That would be a question for @rgommers perhaps, but AFAIK 3.12 dropped distutils so the only way to build is with meson...

It's not 100% gone yet, but likely will be. I can try meson. Is it possible without spin? It's not currently in Fedora but I can package it if needed.

It's not 100% gone yet, but likely will be. I can try meson. Is it possible without spin? It's not currently in Fedora but I can package it if needed.

spin is optional, pip install should work. There are also some gotchas for fedora in the same document.

Assuming I can pass similar options to meson as to pip, since we don't build with internet access, can I specify the cflags and libs options separately, using the output of flexiblas-config? The values in the documented openblas.pc don't support everything we build for.

Assuming I can pass similar options to meson as to pip, since we don't build with internet access, can I specify the cflags and libs options separately, using the output of flexiblas-config? The values in the documented openblas.pc don't support everything we build for.

meson should pick up appropriately set environment variables, so that should work.

This is interesting.

meson.build:9:17: ERROR: Meson version is 1.2.1 but project requires >=1.2.99

Patching that to 1.2.1, then I get:

meson_cpu/x86/meson.build:2:15: ERROR: Module "features" does not exist

@limburgher python -mpip install meson?

Meson is installed from the Fedora RPM.

Or maybe submodule update. We have vendored meson while waiting for the next release, so you will need the repo for now.

I take it you are compiling for Python 3.12?

I think we should be packaging everything needed for building in the sdist, so since we require the vendored-meson submodule it should be packed into the sdist.

It is part of the sdist. I think the only way this can go wrong is if a distro is trying to unvendor it - that will not work. Or if the user is trying to run meson setup directly. @limburgher you want to build a package by either pip install . or python -m build, and then you should not be getting a Meson version mismatch. The Module "features" does not exist indicates that you are getting a non-vendored Meson; our vendored version does have a features module (and that is actually the reason why we vendor it, we need that non-merged new feature).

can I specify the cflags and libs options separately, using the output of flexiblas-config? The values in the documented openblas.pc don't support everything we build for.

Rather than doing that, you want to do:

# assuming up-to-date `pip`, otherwise replace `-C` with `--config-settings=`
python -m pip -Csetup-args=-Dblas=blas -Csetup-args=-Dlapack=lapack

I believe Flexiblas provides plain blas/lapack interfaces, right? If not, then you may want -Dblas=flexiblas instead.

See http://scipy.github.io/devdocs/building/blas_lapack.html#selecting-blas-and-lapack-libraries for docs.

So I attempted:

python -m build -Csetup-args=-Dblas=flexiblas -Csetup-args=-Dlapack=lapack

Which ends with:

Build targets in project: 101

NumPy 1.26.0

User defined options
Native files: /home/gwyn/fedora/git/numpy/numpy-1.26.0/.mesonpy-2iq9o8w4/build/meson-python-native-file.ini
buildtype : release
b_ndebug : if-release
b_vscrt : md
blas : flexiblas
lapack : lapack

Found ninja-1.11.1 at /usr/bin/ninja

• /tmp/build-env-bgkjoj69/bin/python /home/gwyn/fedora/git/numpy/numpy-1.26.0/vendored-meson/meson/meson.py dist --allow-dirty --no-tests --formats gztar
  Dist currently only works with Git or Mercurial repos

ERROR Backend subprocess exited when trying to invoke build_sdist

-Csetup-args=-Dlapack=lapack

Just to make sure: since Flexiblas provides LAPACK wrappers also, you may want -Csetup-args=-Dlapack=flexiblas as well perhaps?

ERROR Backend subprocess exited when trying to invoke build_sdist

I think that means that you don't have a git clone, but a local sdist that you downloaded and unpacked? If not, I don't understand why Meson wouldn't recognize that it's in a git repo. I can reproduce your error by running python -m build on an unpacked sdist at least. build builds an sdist first by default, and a wheel from an sdist. So if you already had an sdist, you want to run python -m build --wheel (plus the extra -C flags).

Ok, I managed to make that work with our system. The only remaining issue is two test failures on s390x:
https://kojipkgs.fedoraproject.org//work/tasks/7512/106447512/build.log

Thanks @limburgher. Those failures look new, and related to the new meson_cpu implementation for SIMD support (Cc @seiko2plus):

_______________________________ test_dispatcher ________________________________
    def test_dispatcher():
        """
        Testing the utilities of the CPU dispatcher
        """
        targets = (
            "SSE2", "SSE41", "AVX2",
            "VSX", "VSX2", "VSX3",
            "NEON", "ASIMD", "ASIMDHP"
        )
        highest_sfx = "" # no suffix for the baseline
        all_sfx = []
        for feature in reversed(targets):
            # skip baseline features, by the default `CCompilerOpt` do not generate separated objects
            # for the baseline,  just one object combined all of them via 'baseline' option
            # within the configuration statements.
            if feature in __cpu_baseline__:
                continue
            # check compiler and running machine support
            if feature not in __cpu_dispatch__ or not __cpu_features__[feature]:
                continue
    
            if not highest_sfx:
                highest_sfx = "_" + feature
            all_sfx.append("func" + "_" + feature)
    
        test = _umath_tests.test_dispatch()
>       assert_equal(test["func"], "func" + highest_sfx)
E       AssertionError: 
E       Items are not equal:
E        ACTUAL: 'func_VXE'
E        DESIRED: 'func'
all_sfx    = []
feature    = 'SSE2'
highest_sfx = ''
targets    = ('SSE2', 'SSE41', 'AVX2', 'VSX', 'VSX2', 'VSX3', ...)
test       = {'all': ['func_VXE', 'func_VX', 'func'], 'func': 'func_VXE', 'func_xb': 'func_VXE', 'var': 'var_VXE', ...}
../../../../BUILDROOT/numpy-1.26.0-1.fc40.s390x/usr/lib64/python3.12/site-packages/numpy/core/tests/test_cpu_dispatcher.py:31: AssertionError
______________________ Test_SIMD_MODULE.test_truncate_f32 ______________________
self = <numpy.core.tests.test_simd_module.Test_SIMD_MODULE object at 0x3ff2e4e9bb0>
    def test_truncate_f32(self):
>       f32 = npyv.setall_f32(0.1)[0]
E       AttributeError: module 'numpy.core._simd.VX' has no attribute 'setall_f32'. Did you mean: 'setall_s32'?
self       = <numpy.core.tests.test_simd_module.Test_SIMD_MODULE object at 0x3ff2e4e9bb0>
../../../../BUILDROOT/numpy-1.26.0-1.fc40.s390x/usr/lib64/python3.12/site-packages/numpy/core/tests/test_simd_module.py:89: AttributeError

The first error should be fixed by #24772:

        test = _umath_tests.test_dispatch()
>       assert_equal(test["func"], "func" + highest_sfx)
E       AssertionError: 
E       Items are not equal:
E        ACTUAL: 'func_VXE'
E        DESIRED: 'func'
all_sfx    = []
feature    = 'SSE2'
highest_sfx = ''
targets    = ('SSE2', 'SSE41', 'AVX2', 'VSX', 'VSX2', 'VSX3', ...)
test       = {'all': ['func_VXE', 'func_VX', 'func'], 'func': 'func_VXE', 'func_xb': 'func_VXE', 'var': 'var_VXE', ...}
../../../../BUILDROOT/numpy-1.26.0-1.fc40.s390x/usr/lib64/python3.12/site-packages/numpy/core/tests/test_cpu_dispatcher.py:31: AssertionError

while the second one should be fixed by gh-24776 which is the back-port of #24479:

______________________ Test_SIMD_MODULE.test_truncate_f32 ______________________
self = <numpy.core.tests.test_simd_module.Test_SIMD_MODULE object at 0x3ff2e4e9bb0>
    def test_truncate_f32(self):
>       f32 = npyv.setall_f32(0.1)[0]
E       AttributeError: module 'numpy.core._simd.VX' has no attribute 'setall_f32'. Did you mean: 'setall_s32'?
self       = <numpy.core.tests.test_simd_module.Test_SIMD_MODULE object at 0x3ff2e4e9bb0>
../../../../BUILDROOT/numpy-1.26.0-1.fc40.s390x/usr/lib64/python3.12/site-packages/numpy/core/tests/test_simd_module.py:89: AttributeError

So they do, thank you!

Closing as completed by #24772 and #24776, thanks all.

This is interesting.

meson.build:9:17: ERROR: Meson version is 1.2.1 but project requires >=1.2.99

Patching that to 1.2.1, then I get:

meson_cpu/x86/meson.build:2:15: ERROR: Module "features" does not exist

Same problem， despite installing the latest version pip3 install meson

The features module exists only in the Meson fork in this repo, under vendored-meson/meson. So if you are seeing this as part of the NumPy build, your submodule is out of date or not being picked up somehow.

Note that you cannot run a plain meson setup build, you must use either:

• pip or python -m build to produce a wheel
• spin build for a dev build
• python vendored-meson/meson/meson.py setup build to use Meson directly

@rgommers perfect, thanks!

I had the same problem.
What worked for me the following steps (I'm a newbie to meson):

• python vendored-meson/meson/meson.py setup build
• cd build
• python ../vendored-meson/meson/meson.py compile

But then, how do I run tests? spin test does not work as it wants to build again with the infamous

meson_cpu/x86/meson.build:2:15: ERROR: Module "features" does not exist

No need to do the steps in your first 3 bullets @lorentzenchr. Just spin test in a clean repo with up to date git submodules should do.

Even after git clean -xdf , git pull main , git submodule update --init (vendored meson is e6e1bf97 same as https://github.com/numpy/numpy/tree/main/vendored-meson), I still get that error message.

This must be something like a too old version of spin or meson-python (or user error), causing the vendored meson to not be picked up. If those old versions aren't it, can you please open a new issue with full details on your environment?

It was an old version of spin. @rgommers Thanks for your super fast support!