Since we want to build scikit-misc using FlexiBLAS, I need to find a way of providing build options -Dblas=flexiblas -Dlapack=flexiblas, preferably as an option to one of the build macros. Alternatively, I'd need to patch the pyproject.toml file as documented upstream.

However, I have hit an issue of a different nature with mock trying to install an older version of numpy. I asked the Python SIG for help.

Of course, if someone here has an idea, I'd like to hear it.

Issue with numpy being pinned has been solved (thanks again @music).

I resorted to patching the pyproject.toml to allow the use of flexiblas. However, another roadblock has just emerged:

No matching package to install: 'python3dist(patchelf) >= 0.11'

I will look into packaging python-patchelf. Current state of the specfile is in my fork's mesonpy branch.

No matching package to install: 'python3dist(patchelf) >= 0.11'

I will look into packaging python-patchelf. Current state of the specfile is in my fork's mesonpy branch.

Looks like meson-python adds the Python patchelf dependency (which exists just as a hack to provide the CLI program via PyPI) when the patchelf CLI program is not in the PATH.

https://github.com/mesonbuild/meson-python/blob/78def82ff1e6466afda91c69d7630cc89bc5177d/mesonpy/init.py#L1088

If I add patchelf (or /usr/bin/patchelf) to the runtime dependencies of python3-meson-python, then it should not be necessary to create a python-patchelf package.

The fix for python-meson-python is building in Rawhide, with amended F37/F38 newpackage updates to follow. You will need to use %pyproject_buildrequires -w.

If I add patchelf (or /usr/bin/patchelf) to the runtime dependencies of python3-meson-python, then it should not be necessary to create a python-patchelf package.

Indeed! Adding patchelf as a BR made the issue go away. Maybe the patchelf package could provide python3dist(patchelf)? That would avoid others getting confused and being mislead.

The fix for python-meson-python is building in Rawhide, with amended F37/F38 newpackage updates to follow. You will need to use %pyproject_buildrequires -w.

What fix? For the patchelf warning/error?

Anyway, I got everything working and submitted a PR, which also includes your PR @music. Would you mind reviewing my changes before I merge? Thanks for all your help, btw. Much appreciated.

If I add patchelf (or /usr/bin/patchelf) to the runtime dependencies of python3-meson-python, then it should not be necessary to create a python-patchelf package.

Indeed! Adding patchelf as a BR made the issue go away. Maybe the patchelf package could provide python3dist(patchelf)? That would avoid others getting confused and being mislead.

The fix for python-meson-python is building in Rawhide, with amended F37/F38 newpackage updates to follow. You will need to use %pyproject_buildrequires -w.

What fix? For the patchelf warning/error?

In my opinion, the correct fix here was for python-meson-python to add the /usr/bin/patchelf dependency. With the command-line tool installed system-wide, the mesonpy dependency generation will not generate the python3dist(patchelf) dependency at all, and /usr/bin/patchelf will always be present as a transitive dependency.

Anyway, I got everything working and submitted a PR, which also includes your PR @music. Would you mind reviewing my changes before I merge? Thanks for all your help, btw. Much appreciated.

With the change linked above to python-meson-python, the spec file for python-scikit-misc should not need to mention patchelf at all.

What fix? For the patchelf warning/error?

In my opinion, the correct fix here was for python-meson-python to add the /usr/bin/patchelf dependency. With the command-line tool installed system-wide, the mesonpy dependency generation will not generate the python3dist(patchelf) dependency at all, and /usr/bin/patchelf will always be present as a transitive dependency.

Thinking about it, it makes (more?) sense fixing it in the python-meson-python package itself, masking the hack upstream put in there. In that regard the entire python-patchelf package is one big hack. It makes sense from a Python packaging perspective, but not from a distro perspective.

With the change linked above to python-meson-python, the spec file for python-scikit-misc should not need to mention patchelf at all.

All right. I changed my PR commit comment locally. I might as well remove the BR for patchelf as well once the change has landed in rawhide. Was planning on a final housekeeping force push anyway.

Thinking about it, it makes (more?) sense fixing it in the python-meson-python package itself, masking the hack upstream put in there. In that regard the entire python-patchelf package is one big hack. It makes sense from a Python packaging perspective, but not from a distro perspective.

That’s what I think. There are quite a few of these PyPI hacks for providing command-line tools, e.g. https://pypi.org/project/cmake/. They’re workarounds for not being able to rely on distro packaging. And it’s clear from the source code that meson-python upstream meant for the PyPI patchelf dependency to be added only as a workaround for situations where there was no system patchelf.

It looks like the effort was successful. Anything else to keep this ticket open for?

I'm still waiting for python-meson-python to land in f38 and f37, so I can build and push updates for these branches as well. In hindsight it might have been worth if we had coordinated the branched builds in a side tag.

Turns out using mesonpy python-scikit-misc (correctly?) requires python3-numpy >= 1.23.2, which is not (yet?) available for f37.

I will try and loosen that requirement, building against the available version in f37.

Updates for both f38 and f37 have been pushed to testing.

This ticket has been migrated to the forgejo instance. Please find the new ticket here
https://forge.fedoraproject.org/neuro/NeuroFedora//issues/544