Publish linux-aarch64 wheels on native ARM runners

[thellert]

linux-aarch64 wheels for the EPICS PVA stack

There is no linux-aarch64 wheel on PyPI for epicscorelibs, pvxslibs or p4p, at any interpreter. All three publish macosx_11_0_universal2, manylinux2014_x86_64 / manylinux_2_28_x86_64 and win_amd64 only. So on arm64 Linux pip install p4p source-builds all three and needs a C toolchain on the host. A container image can stage one; a bare-metal install cannot be assumed to have one.

Three PRs, one per repo, adding the missing rows:

• Publish linux-aarch64 wheels on native ARM runners #56 — epicscorelibs
• python: publish linux-aarch64 wheels on native ARM runners pvxs#201 — pvxslibs
• Publish linux-aarch64 wheels on native ARM runners p4p#226 — p4p

They need to merge in that order: pvxslibs builds against epicscorelibs, and p4p against both. Until the one above it has merged and published, each downstream PR's aarch64 jobs are expected to fail — see the note in each.

Why now. #21 and epics-base/pvxs#48 proposed this in 2023 using QEMU, and were closed unmerged in favour of waiting for ARM-based hosted runners. Those runners are now generally available and free on public repositories, which removes both objections raised in that discussion: the build is native rather than ~40 minutes emulated, and the unit tests run against a real kernel, so qemu-user not translating IP_MULTICAST_ALL, SO_RXQ_OVFL, IP_MULTICAST_IF and IPV6_MULTICAST_IF is no longer a factor.

The change, identical in all three:

• runs-on: ${{ matrix.runner || 'ubuntu-latest' }}, following the existing ${{ matrix.cy || 'Cython' }} idiom, so the x86_64 and native rows are untouched.
• New manylinux2014_aarch64 rows for cp39–cp313 and manylinux_2_28_aarch64 for cp314/cp314t, mirroring the x86_64 set, each with runner: ubuntu-24.04-arm.
• Nothing cross-compiles: ubuntu-24.04-arm builds linux-aarch64 natively. (epics-base/ci-scripts already builds that target, as a cross-compile.)
• podman 5.8.4 is preinstalled on ubuntu-24.04-arm, the same version as on the x64 image, so the podman run step is unchanged.
• mdavidsaver/ci-core-dumper@master is a node24 action and GitHub-provided runtimes are arm64-native, so it needs no change.
• Artifact names already include matrix.ml, so nothing collides, and src: true stays on the x86_64 cp314 row only.

This repo

First in the chain — epicscorelibs has no EPICS build dependency of its own, so this PR's CI stands alone and should be green as submitted. The other two depend on the wheels this one publishes.

Seven new rows, none carrying skip, so all seven publish. cp38 is left out: its x86_64 row rides manylinux2010, which never had an aarch64 variant. A cp38 row on manylinux2014_aarch64 is possible if you want the sets to match exactly.

Separate question, deliberately not addressed here because it changes published metadata rather than CI: src/python/epicscorelibs/config.py maps a Linux aarch64 machine to EPICS_HOST_ARCH = linux-arm — the 32-bit target — while the Darwin branch just below maps arm64 to darwin-aarch64. The branch predates 7.0.4.1, which is what added linux-aarch64. On Linux the difference looks inert — the only ARCH_CLASS consumers I can find are the vxWorks, darwin and ios configs, and the -D_FILE_OFFSET_BITS=64 that linux-arm adds is a no-op at 64 bits. But the value is what get_config_var('EPICS_HOST_ARCH') reports, it is what pvxslibs and p4p build against, and whichever value is in place when the first aarch64 wheel ships is the one downstream sees — so it seems better settled before publishing than after. Happy to change it here, in a separate PR, or not at all.

[mdavidsaver]

Is it really necessary to publish aarch64 wheels for older python?

fyi. The wheel files for epicscorelibs, pvxslibs, and p4p collectively account for ~9.6 GB of storage on pypi.org. I am not sure of our specific point in the distribution, but I have to assume that this is relatively large. I have a policy of removing older pre-release builds, and hopefully the historic trends towards cheaper storage and bandwidth will continue. Still, this leaves me sensitive to overindulging in this free service.

I am inclined to only upload aarch64 wheels for py 3.14 and newer.

[mdavidsaver]

I have uploaded p4p==4.3.0a2, pvxslibs==1.5.3a1, and epicscorelibs==7.0.10.99.0.2a1. These includes py3.14 and 3.14t builds for linux x64 + aarch64, OSX, and windows.

maps a Linux aarch64 machine to EPICS_HOST_ARCH = linux-arm

a0b3f49 changes this to linux-aarch64.