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.

This is now good on aarch64 due to changes here and the linked PRs. The M1 macOS build should also pass, but it's failing due to homebrew breakage. I don't know if we want to continue to use mactex; it seems to take the majority of the OS setup part of the build.

OK, adding a brew update fixed the mactex install. The sigint failure is still happening a lot; we should probably add an xfail on that as well.

There was a recent post on the numpy-mailing list that they are now exceeding the free quota on Cirrus. Not sure if it will become a problem for us as well, but I can imagine it may be. Especially since our tests takes quite a bit of longer time.

Anyway, as a small counter measure it has been suggested running their tests in sequence, starting with the linux one numpy/numpy#24435

We may consider having these optional as well, just running them with a certain label or similar.

Setting up the Mac environment seems to be the major culprit here. Not sure if we are charged all four CPUs during that time and/or it we can try to make use of all four CPUs somehow to reduce the install time? In general, adding a 39 minute test seems a bit unfortunate. But maybe we can reduce that using caching and/or our own image?

Scrolling back I note that you have already noted the potential issue...

However, I also noted this log message:

==> You have set:
  HOMEBREW_NO_AUTO_UPDATE
but we have dramatically sped up and fixed many bugs in the way we do Homebrew updates since.
Please consider unsetting these and tweaking the values based on the new behaviour.
Installing from the API is now the default behaviour!
You can save space and time by running:
  brew untap homebrew/core

which seems to be set by the image? Maybe one will just have to wait for the image to be updated...

One of the biggest time sinks on macOS M1 is installing MacTeX; we may want to not do that to save some time.

Just noting this (should be solved at some stage I guess, but not required for merging IMHO):

Successfully installed matplotlib-0.1.0.dev48306+g388057b

for both runs.

I guess that means that there are still issues for some users to install from source as well?

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

Considering the limited resources, we should try to confirm this/make it happen...

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.