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 epicscorelibs#56 — epicscorelibs
• python: publish linux-aarch64 wheels on native ARM runners pvxs#201 — pvxslibs
• Publish linux-aarch64 wheels on native ARM runners #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. epics-base/epicscorelibs#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

Last in the chain; needs both epics-base/epicscorelibs#56 and epics-base/pvxs#201 merged and published first. #156 is the user-facing version of the problem this closes out.

Two p4p-specific details in the new rows:

• They carry the same numpy pins as their x86_64 counterparts. Each pinned version ships manylinux2014_aarch64-compatible wheels at the matching interpreters (1.21.6/cp39, 2.0.1/cp310, 2.2.6/cp311–cp313), so the pins resolve inside the same containers the x86_64 rows use; 2.3.5's aarch64 wheels are manylinux_2_28, which is fine for the cp314 rows since those already run in the manylinux_2_28 container.
• They also carry skip_cothread: true, as the two cp314 rows already do. cothread publishes no aarch64 wheel, so installing it for the test step would mean compiling it. It does ship context/switch-arm64.c, so enabling it later looks feasible — just not something to prove here.

Expect the aarch64 rows to fail until the two upstream PRs publish. Unlike pvxs, the download line here has no --only-binary for epicscorelibs or pvxslibs, so rather than failing fast these rows fall back to the pvxslibs sdist, whose metadata preparation installs epicscorelibs from source — a full EPICS Base compile inside pip download, slow and hard to read if it then fails for an unrelated reason. The last commit adds --only-binary epicscorelibs,pvxslibs to that line, as python.yml in pvxs already does for epicscorelibs, so the requirement is explicit and an unmet one fails in seconds. It is separable from the rest of the PR if you would rather not have it.

[AndreFavotto]

+1 for this (and others)