feat(ci): build, test and package for aarch64 as well as x86_64

[vietanhdev]

Adapted from the sibling bulwark project, which is also a Tauri GTK/WebKit app — so most of its approach transfers directly.

Why ARM is worth shipping

ThinkUtils was x86_64-only on the reasoning that thinkpad_acpi is an x86 platform driver, so there'd be no hardware to run on. Half of that is still true and half isn't:

• Fan control genuinely cannot work on ARM — that's a kernel limitation
• But the ThinkPad X13s is aarch64, and battery thresholds (generic power_supply API), CPU governor, power profiles and system monitoring aren't ThinkPad-specific at all

The app already detects an absent /proc/acpi/ibm/fan and reports degraded rather than failing — asserted by the container launch tests. So this is a supported configuration, not a hopeful one. The download page says so plainly rather than letting X13s users discover it.

Native, not cross-compiled, not emulated

runs-on picks the CPU; container: ubuntu:22.04 pins the glibc floor. Separating those also retires the standing note in release.yml about the deprecated ubuntu-22.04 runner label — the floor is now ours to choose rather than GitHub's to withdraw.

Cross-compiling is rejected for a concrete reason: Tauri's bundlers infer architecture from the build host and declare none in the manifest, so --target aarch64-… would stage host artifacts under an aarch64 name and ship an x86_64 binary inside an arm64 package. QEMU is refused outright — a WebKit GUI under emulation fails on graphics paths no real user touches, and a misleading red result is worse than no coverage because people learn to ignore the job.

Making the arch axis falsifiable

An arch matrix that silently isn't testing that arch is worse than none. Three guards:

1. uname -m assertion in every arch job. If GitHub renames or withdraws the arm label, runs-on falls back silently — CI would build x86_64 twice, publish it under an arm64 name, and stay green.
2. file(1) check on the built binary in Verify package contents — the last point a mislabelled package is catchable before users get it.
3. gui-launch runs the FULL distro matrix on both arches, not a thinner arm leg. The point of those rows is catching a distro/arch interaction, which a reduced matrix would be most likely to miss.

That third one is where arm64 is actually proven. JavaScriptCore has its own arm64 JIT, so "the native shell paints but the JS never runs" is an arch-specific failure — and a screenshot of it looks like a working window. The existing OCR step is what distinguishes them: a blank-but-styled window still has hundreds of distinct colours, and only the absence of rendered text gives it away.

Packaging follows the matrix rather than restating it

Channel	Declaration
AUR	arch=('x86_64' 'aarch64')
COPR	ExclusiveArch: x86_64 aarch64
PPA	Architecture: any

The PPA asserts the mechanism, not a list — Launchpad builds whatever the series enables, so narrowing to amd64 would silently stop producing arm64 builds with nothing else in the repo changing, and Launchpad reports per-arch results by email rather than failing anything here.

packaging_architectures_match_what_release_actually_builds reads the arches out of release.yml rather than hardcoding them, so it can't pass while disagreeing with the workflow it tracks.

Note for COPR: widening ExclusiveArch alone does not ship aarch64 — the COPR project must have the aarch64 chroots enabled, or the spec claims an arch that produces nothing, silently.

Download page

Its own comment warned about exactly this case: find() returns the first match, so an unpinned predicate would hand an arm64 user an x86_64 package — a download that works and a package that won't install. The suffix stays pinned and the arch is an explicit choice; detection only picks the default tab, since navigator.platform is deprecated and wrong under some emulation layers.

Verification

132 tests, clippy clean, fmt clean, lint + format clean, docs build clean, both workflows parse.

Arch guards mutation-verified — dropping aarch64 from the PKGBUILD or narrowing the PPA to amd64 fails them by name:

packaging_architectures_match_what_release_actually_builds ... FAILED
  PKGBUILD arch=() omits aarch64, which release.yml builds
debian_control_delegates_architecture_to_launchpad ... FAILED
  the PPA must delegate architecture to the series

The real proof is this PR's own CI: if gui-launch (aarch64) goes green, an arm64 package installed and rendered its UI on real ARM hardware.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	thinkutils	0078752	Jul 20 2026, 04:58 AM