Repeating this comment here in the hopes it gets greater visibility. The MacPython/matplot-lib repo builds and uploads wheels weekly, and also can provide them for uploading to PyPI. It has been broken for a while. I tried reviving it in a PR to move the x86 builds to github actions, and leave only the arm64 ones on travis.com.
Should the arm64 and i686 ones be failing? The strategy in that repo is to build in a docker image and to test in a different one, perhaps that is breaking the image tests?
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
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)
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.
Activity
QuLogic commented on Dec 19, 2020
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.
mattip commented on Dec 19, 2020
From what I can gather, there are the following CI runs on github actions
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?
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)
mattip commented on Dec 19, 2020
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"
QuLogic commented on Dec 22, 2020
Fedora does not run HEAD, just releases (and release candidates), which is why the new tests are not yet fixed.
QuLogic commented on Dec 22, 2020
The last AppVeyor run was today?
QuLogic commented on Sep 16, 2023
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.