PyPy has a new release, so we should be able to update cibuildwheel to the latest 2.16.2 2.16.4 version

cc @charris

I think we need to wait for the next cibuildwheel release, otherwise pinning would not have worked.

The failure is in using the openblas_support.py script. I wonder if using the openblas wheels instead to get the shared object as we do in CI (not a full runtime dependency on the wheel) would work around the PyPy bug. That is on my TODO list, I guess it is time to do it.

cibuildwheel 2.16.3 was released with an updated pypy 7.3.14, which fixes one bug but adds another. So this PR should wait for an even newer cibuildwheel release. See pypa/cibuildwheel#1736

hmm. It seems something is off with wheel building on macos:

_multiarray_umath.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace (_cblas_caxpy64_)

, probably due to bumping the OpenBLAS version in #25687, which changed how the tarball is created.

Great. Now there is a pytest failure. Apparently applying a mark to a fixture

now emits a deprecation warning on pytest>=7.4 so collection is failing. This is due to the release of pytest 8.0 a few hours ago.

Rebased off main to get #25710, and updated to cibuildwheel 2.16.4 (latest version, released yesterday).

There is a problem with the newer OpenBLAS tarballs on macos. I am working on it in MacPython/openblas-libs#130, it might take a few hours to resolve.

Darn. I fixed one problem, but there is now a problem when using delocate

  ERROR:delocate.libsana:
  /usr/local/lib/libscipy_openblas64_.0.dylib not found

I guess there is still some hints of the older shared objects burned into the single libscipy_openblas64_.dylib (without the .0)

I reran the failing tests after fixing the macos shared object name, and reran the failing ci steps. Now the wheel action passed but the UI here does not reflect the success.

Ahh, no, it is the cirrus actions that need rerunning. The github ones show success.

I retriggered the failed cirrus runs, let's see in ~40 minutes