Add an integration test for aarch64 Linux#18517
Draft
zanieb wants to merge 12 commits intoastral-sh:mainfrom
Draft
Add an integration test for aarch64 Linux#18517zanieb wants to merge 12 commits intoastral-sh:mainfrom
zanieb wants to merge 12 commits intoastral-sh:mainfrom
Conversation
Adds an integration test on the GitHub ARM runner (github-ubuntu-24.04-aarch64-2) that validates Python installation and venv creation work correctly on ARM Linux. This catches regressions like astral-sh#18509 where uv incorrectly selects soft-float (gnueabi) instead of hard-float (gnueabihf) Python variants on ARM systems. The test verifies: - Python install does not select a soft-float variant on aarch64 - stdlib venv creation works with the installed Python - uv venv creation works with managed Python - The Python in the venv reports aarch64 architecture - Package installation (anyio) works - uv run works https://claude.ai/code/session_012ajDxX28WfNxJ9N7JCibE4
The managed Python directory uses `cpython-3.13` not `cpython-3.13.12`. https://claude.ai/code/session_012ajDxX28WfNxJ9N7JCibE4
Adds a CI job that cross-compiles uv for armv7 and runs it on the aarch64 runner. This reproduces the scenario from astral-sh#18509 where /proc/cpuinfo reports aarch64-style features (no "vfp" flag), causing uv to incorrectly select the soft-float Python variant. The test verifies that uv picks gnueabihf (hard-float) when installing Python on armv7l running on an aarch64 host. https://claude.ai/code/session_012ajDxX28WfNxJ9N7JCibE4
The previous sed command blindly modified all .list files including microsoft-prod.list, which caused a URI parse error. Now we: - Remove the microsoft-prod.list (not needed for this job) - Handle DEB822 format (.sources files) by adding Architectures field - Only modify .list files that don't already have arch qualifiers https://claude.ai/code/session_012ajDxX28WfNxJ9N7JCibE4
When an armv7 binary runs on an aarch64 kernel (e.g., armv7l containers on aarch64 hosts, or 32-bit Raspberry Pi OS on 64-bit hardware), /proc/cpuinfo reports AArch64-style feature flags instead of ARM-32 flags. The existing check for "vfp" fails because AArch64 uses "fp" instead. Add detection of the AArch64 "fp" feature flag (mandatory on all AArch64 CPUs) as a discrete token, indicating hardware floating-point support. This ensures uv selects the gnueabihf (hard-float) Python variant instead of the gnueabi (soft-float) variant. Closes astral-sh#18509
- Backtick-quote 'AArch64' in doc comments to satisfy clippy::doc-markdown - Accept 'aarch64' in the architecture check since platform.machine() returns the kernel architecture when running armv7 binaries on an aarch64 kernel without a personality override
f1e51b4 to
88ac62d
Compare
This was referenced Mar 17, 2026
zanieb
added a commit
that referenced
this pull request
Mar 18, 2026
…18530) Pulled out of #18517 I don't have aarch64 hardware available locally, but Claude posited: > When an armv7 binary runs on an aarch64 kernel (e.g., armv7l containers on aarch64 hosts, or 32-bit Raspberry Pi OS on 64-bit hardware), /proc/cpuinfo reports aarch64-style feature flags instead of armv7 flags. The existing check for "vfp" fails because aarch64 uses "fp" instead. > > Add detection of the aarch64 "fp" feature flag (mandatory on all aarch64 CPUs) as a discrete token, indicating hardware floating-point support. This ensures uv selects the gnueabihf (hard-float) Python variant instead of the gnueabi (soft-float) variant. I reproduced this in #18532 Under QEMU on aarch64 macOS, both the `vfp` and `fp` feature flags are set. Closes #18509
zanieb
added a commit
that referenced
this pull request
Mar 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #18509