Split out of #309 so it does not disappear when that issue closes.
The gap
The release publishes aarch64-unknown-linux-gnu, and no hosted runner can execute it. Nothing has ever started that binary as part of a release. It ran once under emulation during development; no automated test covers it.
Why this is not being fixed now
Closing it needs either self-hosted ARM capacity or emulation in CI. Both cost more than the risk they remove today: the target cross-compiles, packages, and its tarball is checksum-verified like every other, so what is unproven is execution rather than production.
What would close it
Either of:
- an ARM runner that installs the published tarball and runs
hu --version and hu plugin list, the same two assertions the x86_64 leg already makes; or
- a qemu leg in CI doing the same, accepting the wall-clock cost.
Why it has its own issue
A limitation stated only as a paragraph inside a parent issue stops being tracked the moment that parent closes. This is the honest remainder of the release-usability work, not an oversight.
Split out of #309 so it does not disappear when that issue closes.
The gap
The release publishes
aarch64-unknown-linux-gnu, and no hosted runner can execute it. Nothing has ever started that binary as part of a release. It ran once under emulation during development; no automated test covers it.Why this is not being fixed now
Closing it needs either self-hosted ARM capacity or emulation in CI. Both cost more than the risk they remove today: the target cross-compiles, packages, and its tarball is checksum-verified like every other, so what is unproven is execution rather than production.
What would close it
Either of:
hu --versionandhu plugin list, the same two assertions the x86_64 leg already makes; orWhy it has its own issue
A limitation stated only as a paragraph inside a parent issue stops being tracked the moment that parent closes. This is the honest remainder of the release-usability work, not an oversight.