Both of these are built and tested on Fedora and pass. A couple of the tests are new and the failure on aarch64 might need new tolerances. The i686 ones really shouldn't be failing so much; I think this must be a difference between compiler arguments and/or actual hardware involved in floating-point calculations.

From what I can gather, there are the following CI runs on github actions

• tests.yml which has 4 runs:
  • Ubuntu 16.04 minimal with python 3.7
  • Ubuntu 16.04 with python 3.7
  • Ubuntu 16.04 with python 3.8
  • macos-latest with python 3.7
• cibuildwheel.yml which has 3 runs building 5 wheels each for python 3.7, 3.8, 3.9 (macos, windows64bit, windows32bit, manylinux1 64 bit, manylinux1 32) bit but does not test them

There is an .appveyor.yml file but the last appveyor run was four months ago

There is a .travis.yml file in the repo but the last travisci.com run was about a month ago

Where are the logs from the Fedora runs on HEAD?

Would the following make sense?

• sign up with a service like https://www.shippable.com/pricing.html to get arm64 builds and use cibuildwheel there
• • turn on cibuildwheel testing to make sure tests pass on all 15 build combinations, (or at least for 5 combinations on python3.8) and turn off the tests.yml since it only tests 2-3 combinations
• mark MacPython/matplotlib-wheels as not active

If that plan is acceptable I could try to get some PRs going. An admin would have to sign up with a service like shipppable.com for arm64 (which is what numpy uses)

I see I missed the azure runs which build and test on (linux, macos, windows) * (python 3.7, 3.8) and windows python version "Pre"

Fedora does not run HEAD, just releases (and release candidates), which is why the new tests are not yet fixed.

There is an .appveyor.yml file but the last appveyor run was four months ago

The last AppVeyor run was today?

We no longer build for 32-bit, and arm64 wheels are building fine with cibuildwheel now for a while. The MacPython wheel building system is no longer used.