[fix] Rebuild compatible Hyprland dependencies for factory images

[Fail-Safe]

Fresh ARM64 factory builds cannot resolve the rolling repository's mixed aquamarine ABIs: the pinned Hyprland needs libaquamarine.so=13, while the current Hyprtoolkit needs .so=14.

This rebuilds aquamarine 0.14 and Hyprtoolkit 0.5.4 from reviewed Arch recipes and verified upstream sources, then exposes the compatible pair through a disposable builder repository. Hyprtoolkit uses package release 6.1 to distinguish the rebuild. The finished guest holds both packages alongside the patched Hyprland and does not retain the builder repository.

The source builder now gives its unprivileged build user access to temporary directories, explicitly produces zstd packages, cleans up its build account on failure, and remaps temporary build paths. Library hashes are verified before packages enter the repository. The Rust/ttfx and pkgconf/Hyprland pins and the 614-package transaction lock are refreshed together.

Validation:

• CI passes on 3f7ec01.
• Full make test passes with the Xcode toolchain, including new regression tests for the compatible pair, missing archives, and guest/builder package holds.
• Independent source rebuilds reproduce the aquamarine and Hyprtoolkit library hashes; the rebuilt ttfx matches its reviewed hash.
• Full make build passes with a new, empty guest-work volume. The independent Hyprland rebuild reproduces its pinned hash and passes its installed version check inside the guest root.
• The app passes strict code-signature validation and the macOS 15 compatibility check.
• An isolated ephemeral VM boots kernel 7.2.3-2, renders first-run setup, and reaches the graphical desktop after setup. The tester completed setup and supplied a screenshot confirming the rendered panel, wallpaper, and welcome notifications. QMP screenshots remain black with the accelerated display, so visual confirmation used the supplied screenshot.

Fixes #171 and extends the factory-build work discussed in #134.

[themartiano]

Thanks for the pull request!

Codex comments

Please rebase after #136 and resolve the guest-contract conflict. Also record and verify the provenance of the vendored aquamarine archive: the new repository uses Optional TrustAll, and a SHA declared beside the binary does not establish its upstream origin. Include verified upstream signature evidence or a reproducible source build, then run the complete guest build to verify the changed CMake/Hyprland pins.

[Fail-Safe]

Rebased onto current main (including #136) and resolved the guest-contract / Hyprland identity conflicts. The cmake build pin stays at 4.4.3-2 because Arch Linux ARM still publishes that.

Provenance: the reconstructed unsigned archive is gone. The factory now rebuilds aquamarine 0.14.0-2 from the Arch packaging commit 8489a8358817a964a923f05ba324996378d81a5d (tag 0.14.0-2) and the reviewed hyprwm/aquamarine v0.14.0 tarball. [try-omarchy-abi-pins] still uses Optional TrustAll only because repo-add writes an unsigned database for that just-built package; origin is the source rebuild.

supplyChain.aquamarine.binarySha256 is libaquamarine.so.0.14.0 from the previously installed ALARM 0.14.0-2 payload. The first factory rebuild will confirm that digest or we will update the pin if this toolchain is not bit-identical.

Locally: python3 guest/tests/verify.py and python3 -m unittest discover -s guest/tests pass. Complete guest/build-container.sh is still the remaining requested check.

[Fail-Safe]

@itamblyn I'm reviewing this PR again. There has been a lot in motion in the past day, so let me see what is going on here.

[Fail-Safe]

@itamblyn This should be in working shape again. Extra confirmation is very welcome--thanks!

[k5953837]

🤖 Written by Claude Opus 5 (an Anthropic AI model) on behalf of @k5953837, who is blocked on this PR for #175 and ran the build to confirm it. Everything below is from one run on 2026-09-09.

Confirmation from an Apple Silicon Mac, since you asked for it.

Setup: macOS 15 on Apple Silicon, Docker 29.6.2 with native linux/arm64, pr-142 at 3f7ec01 in a clean worktree.

make test

Passes, with one failure that is not yours: StartMenuWindowWidthTests.swift:131, Expectation failed: (content.bounds.width → 601.0) == (600 → 600.0). I ran the same suite on clean main (768d03d) before touching anything and got the same single test, the same expectation, and the same two values — so it is a local display/font-metric artifact here, not a regression from this branch.

Everything guest-side is green: Ran 88 tests ... OK for the unittest modules (including the new test_builder_pacman_conf.py) and 196 ok - checks ending in native guest contract verified.

make guest

The structural fix works. 13 minutes wall clock, and both blockers reported in #171 are gone:

rust-1:1.98.1-1                                       # builder stage installs cleanly
Rebuilt aquamarine 0.14.0-2 from 8489a835... (library 7da003aa...)
Rebuilt hyprtoolkit 0.5.4-6.1 from 1ed23038... (library dc814fad...)

The transaction then resolves past hyprland/aquamarine with no could not satisfy dependencies.

Where it stops

One step later, on a lock drift that appeared today:

package repository transaction differs from packages.lock.json; refresh and review the lock intentionally
archlinux-keyring: 20260902-1 -> 20260909-1
build-cache: guest build failed with exit status 1

Exactly one package. ALARM published archlinux-keyring 20260909-1 today, after this branch's lock was refreshed on the 8th. So this reads as needing one more --refresh-package-lock pass rather than anything structural.

Happy to re-run the full build as soon as you push a refreshed lock — the worktree and the builder image are still warm here, so it is a 13-minute turnaround.

[Fail-Safe]

@themartiano The lock refresh is pushed in 9e31d3b and CI is green. The fresh resolver confirmed that only archlinux-keyring changed, from 20260902-1 to 20260909-1.

Local validation also passes: the full test suite, complete factory/runtime/app build, pinned binary-hash checks, app signing verification, and macOS 15 compatibility checks.

Could you take another look at the outstanding review and merge if everything is satisfactory? The provenance and complete-build work requested on the earlier revision is included. Since the build resolves against rolling repositories, a timely review would help avoid another lock refresh while this is pending.

[themartiano]

Great! Merging now, thanks