Giving up for now.

For FreeBSD, I get the following error when running pip or python

ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.7m.so.1.0 not found

so something is wrong with the install.

For MacOS and Linux ARM64, the following happens

Successfully installed matplotlib-0.1.0.dev45061+g1ca320e
...
ERROR  - ImportError: cannot import name '_c_internal_utils' from partially initialized module 'matplotlib' (most likely due to a circular import) (/tmp/cirrus-ci-build/lib/matplotlib/__init__.py)

Not sure if they are related, but it would be nicer if the version numbering worked properly to start with...

I see stuff like:

    Not uninstalling setuptools at /usr/lib/python3/dist-packages, outside environment /usr
    Can't uninstall 'setuptools'. No files were found to uninstall.

and

WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

These are Debian system paths. Perhaps it would be best to follow that advice and create a venv.

Successfully installed matplotlib-0.1.0.dev48306+g388057b

This is because their checkout does a shallow clone without tags.

Btw, do we know if previous tests will be cancelled when pushing a new version?

Yes, it seems so on any branch other than main: https://cirrus-ci.org/guide/writing-tasks/#auto-cancellation-of-tasks

May be worth modifying it so that it does cancel even on main (or perhaps even to not run again on every commit to main)

I tried to see if one somehow can trigger the runs based on setting a specific label, but to no avail.

An option is to use manual https://cirrus-ci.org/guide/writing-tasks/#manual-tasks and then do a bit of a guessing game if the PR may affect anything... (Not sure exactly who can trigger it though.)

Successfully installed matplotlib-0.1.0.dev48306+g388057b

This is because their checkout does a shallow clone without tags.

This is fixed now by adding the git fetch --tags.

I tried to see if one somehow can trigger the runs based on setting a specific label, but to no avail.

I'm not sure we should try to optimize too much before finding out if we're going to end up close to the limit.

https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/

Turns out if we wait long enough, GHA has M1 now...

It looks like those are xlarge runners, which are only available for GitHub Team or GitHub Enterprise Cloud plans. So we'd still need to wait some more.

Comparing the previous build on aarch64, it took >2min to build, and now takes 34s, a factor of about 4, which matches CPU count. So the Meson build does seem to be taking advantage of all CPUs as expected. On macOS, it was 43s and now 15s, which is only 3x, but that might be too fast already.

Oddly, there are new image failures on aarch64. I'm not sure why that's happening as that test image doesn't seem to have changed. Perhaps it's about optimizations or similar.

It appears we have waited long enough, at least for M1 macOS: #27723

Is it worth closing this now we can get native M1 runners on GH actions? #27723

Unless we think that aarch64-Linux is worthwhile, I'd be happy to close this.

aarch64-linux runners are available on GH actions now now: https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/, so I think this has become redundant?

Yes, I think unfortunately or fortunately, this PR is no longer needed.