You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building and testing macOS wheels with the c-code template GHA test configuration the currently running platform (x86_64 vs. arm64) is ignored. The download step synthesizes a file name consisting of the runner OS and the Python version only. macOS wheels come in two flavors, the standard one that conforms to the simple runner OS/Python version naming is actually for x86_64, while the arm64 wheel with a slightly different name never gets downloaded and tested.
I implemented 8d837c8 as a workaround to make sure the correct wheels are tested on modern (arm64) GHA runners.
The eggs that have been published so far are not broken. They install and run fine on a "normal" macOS/arm64 install. The issue is with the GHA runners using Python in universal2 build and zc.buildout not being able to deal with that, which doesn't need solving here.
When building and testing macOS wheels with the c-code template GHA test configuration the currently running platform (x86_64 vs. arm64) is ignored. The download step synthesizes a file name consisting of the runner OS and the Python version only. macOS wheels come in two flavors, the standard one that conforms to the simple runner OS/Python version naming is actually for x86_64, while the arm64 wheel with a slightly different name never gets downloaded and tested.
It could be that the arm64 wheels are broken, at least for the way the macOS GHA runner is set up, see https://github.com/zopefoundation/Zope/actions/runs/9264831347/job/25485668334#step:2:1
The text was updated successfully, but these errors were encountered: