✨ Build and publish arm64 Linux artifacts - #29
Closed
manupawickramasinghe wants to merge 1 commit into
Closed
Conversation
Adds a native `ubuntu-24.04-arm` leg to CI and to the release matrix, so `sensorview` ships a `.deb` for arm64 Linux — Raspberry Pi 5, Ampere and Graviton servers, Snapdragon X laptops running Linux. Native rather than cross-compiled, for two independent reasons: TODO.md already records that cross-compiling this project fails in `ring`'s build script for want of a target C toolchain, and ARM AppImages can only be produced on ARM hardware in any case. GitHub's arm64 runners are generally available and free for public repositories, so a real runner costs nothing here. Nothing in the sensor path needed changing. The Linux backend is sysfs and procfs (`src/source/linux.rs`), which is architecture-neutral, and the one place that reads CPUID is already gated behind `not(any(target_arch = "x86_64", ...))` in `src/sysinfo.rs`. So aarch64 compiled before this change; it simply was never built. What it loses is the x86-only part of the System Summary — the CPUID signature, the codename and the feature list report empty — which the README now states. Two supporting changes: - The per-step guards now key on a new `os` matrix field rather than on the runner label. With two Linux labels, `platform == 'ubuntu-24.04'` would have skipped the apt step on the arm leg and failed it later at the eframe build, for a reason that looked nothing like the cause. - The arm leg packages `deb` only. cargo-packager's AppImage path fetches linuxdeploy, and whether it resolves an aarch64 build is unverified — guessing would make the leg red for a reason unrelated to this project. Both Linux legs can glob `*.deb` safely because cargo-packager puts the architecture in the filename. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 26, 2026
Member
Author
|
Merged into master |
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
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.
What
Adds a native
ubuntu-24.04-armleg to both CI and the release matrix, so SensorView ships a.debfor arm64 Linux: Raspberry Pi 5, Ampere/Graviton servers, and Snapdragon X laptops running Linux.Why no code changes were needed
This is the useful finding. aarch64 already compiled — it had simply never been built:
src/source/linux.rsreadshwmon,/proc/stat,/proc/diskstats,/proc/net/devandcpufreq. None of that is architecture-specific.src/sysinfo.rs, is already gated behind an explicit#[cfg(not(any(target_arch = "x86_64", all(target_arch = "aarch64", target_os = "macos"))))]fallback arm.So sensor coverage on arm64 is the same as on x86-64. What is lost is the x86-only part of the System Summary — CPUID signature, microarchitecture codename, instruction-set feature list — which report empty. The README now says so rather than leaving it to be discovered.
Why a native runner, not a cross-build
Two independent reasons, neither of which is a preference:
TODO.mdalready records that cross-compiling this project fails inring's build script for want of a target C toolchain.GitHub's arm64 runners are GA and free for public repositories, so a real runner costs nothing here.
Two supporting changes worth a look
Guards now key on a new
osmatrix field, not the runner label. With two Linux labels in the matrix,if: matrix.platform == 'ubuntu-24.04'would have skipped the apt step on the arm leg and then failed it much later at the eframe build — a failure that looks nothing like its cause. Verified that everymatrix.osguard resolves against a leg that exists.The arm leg packages
debonly, deliberately. cargo-packager's AppImage path fetches linuxdeploy, and whether it resolves an aarch64 build of it is unverified. Addingappimageon a guess would make the leg red for a reason unrelated to this project. Widen it once someone has watched it work.Both Linux legs can glob
*.debsafely: cargo-packager puts the architecture in the filename (_amd64.debvs_arm64.deb), so neither leg matches the other's artifact and the release ends up with both.Verification
matrix.osguard was checked against the set of legs actually defined.ubuntu-24.04-arm, linux, debpassed in 9m57s. That is the first time this code has ever been compiled and packaged for aarch64, so widening the leg to AppImage later starts from a known-good baseline rather than an open question.Not in scope
Windows on ARM. The Windows sensor path is a .NET LibreHardwareMonitor sidecar (
win-x64) plus a Ring-0 driver; that is a port, not a matrix line.🤖 Generated with Claude Code