Add riscv64 to Linux wheel build matrix

[gounthar]

Fixes #9462.

Changes proposed in this pull request:

• Add manylinux_2_28 riscv64 entry to build-native-wheels matrix in wheels.yml
• Add QEMU setup step for riscv64 emulation on x86_64 runners
• Build manylinux_2_28_riscv64 wheels via cibuildwheel + QEMU

Note: EXPECTED_DISTS may need updating once the exact wheel count is determined.

Evidence

• Tested wheel: pillow-12.1.1-cp313-cp313-linux_riscv64.whl
• Built natively on BananaPi F3 (SpacemiT K1, rv64imafdcv, 8 cores @ 1.6 GHz, 16 GB RAM)
• Imports and passes basic smoke test on riscv64

Context

• manylinux_2_28_riscv64 is available in pypa/manylinux
• cibuildwheel 3.x supports riscv64 via QEMU
• Several packages already ship riscv64 wheels: aiohttp, yarl, multidict, propcache
• RISC-V hardware is shipping (SiFive, SpacemiT, Sophgo SG2044)

[radarhere]

Hi. At the moment, you've only added the QEMU step, you haven't actually changed the matrix.

As a word of warning, I expect that once you do update the matrix, this will take a very long time to build - #9462 (comment)

[gounthar]

@radarhere: oopsie; I'd added the QEMU step but forgot the matrix entry. Fixed in 7b026c6: added a manylinux_2_28 riscv64 entry scoped to cp3{12,13}-manylinux* only (2 wheels, as suggested in #9462 (comment)).

This should trigger a CI run. I expect it will either hit the libaom/RVV build error or the 6-hour timeout (or both). Either way, we'll have concrete data on what happens under QEMU, which will help decide whether to pursue the self-hosted runner path or close this.

[radarhere]

Regarding the general test failures, they should be fixed by #9464

Regarding riscv64, it did fail to build libavif - https://github.com/python-pillow/Pillow/actions/runs/23025132993/job/66876973143?pr=9463#step:6:5045

I don't expect riscv64 to hit the 6 hour limit if you are only building two Python versions.

[gounthar]

@radarhere Thanks for pointing to the libavif failure. I'll investigate the build log; it looks like it could be a libaom/RVV (RISC-V Vector) codegen issue in the cross-compilation path.

On the build time front: if QEMU overhead becomes a concern, https://cloud-v.co/ provides free native riscv64 GitHub Actions runners to open source projects. That would speed things up and give more representative results. But let me first focus on getting libavif to build (or not) under QEMU.
There's no point discussing runners if the build itself doesn't work yet. 🤷

[gounthar]

Following up on the libavif/libaom failure. There is an active review on the aomedia Gerrit fixing RVV handling for specific block sizes in riscv64: https://aomedia-review.googlesource.com/c/aom/+/208401

Not sure yet if this is the exact issue we hit, but it is in the same area. I will rebase and re-run once it lands to see if it unblocks the build.