Repository navigation
Build aarch64 packages on native ARM64 runners - #171
scottjones wants to merge 5 commits into
Conversation
The build system already supports aarch64 end to end -- bin/build, bin/sign, bin/update-repo and bin/sync-repo all take --arch, the Dockerfile bootstraps an Arch Linux ARM rootfs, and omarchy-keyring is published for aarch64 so that image can bootstrap -- but nothing runs it, so pkgs.omarchy.org serves no aarch64 tree. GitHub's ARM64 runners are free for public repositories, so the build needs no QEMU. The workflow is dispatch-only and takes an optional package list, and it stops at uploading artifacts: signing and syncing need credentials only a maintainer has.
The builder container works as its own uid 1000 user, while a GitHub runner is uid 1001, and make_dir_writable() chowns the mounted output directories to the host user. The container then cannot write its incremental omarchy-build database, pacman -Sy fails to open it, and no makedepends resolve -- the build dies on the first package. This is invisible on a workstation, where the developer is uid 1000 too.
|
There are now eight open aarch64 PRs on this repo and we're starting to collide. Posting a map here since this PR is the one several of the others already reference. How they fit
These are complementary rather than competing. #223 says so directly — it carries this branch's commits so it can be exercised today, and plans to rebase to only its follow-up commits once this merges. #240 is the mirror image: its Where we actually conflictUntil a few minutes ago three PRs flipped
I've removed those from this PR (see below), so what remains is #195 and #240, which also overlap on The diffs agree — Proposed sequencing
Happy to reorder if maintainers would rather take #240 first — the point is mainly that these want an order rather than parallel resolution of the same files. |
|
Re-reviewed at 60d8452 (previous pass was 913d235). Reviewed by Claude Opus 5 and by Codex at xhigh reasoning as an independent second reviewer; where the two agree below I say so, and Codex's independence is not currently guaranteed, so agreement is worth less than the two findings it contributed on its own. What changed since the last pass. The branch was rebased rather than extended: Still open, and new.
Re-verified clean at this head. No fork can reach this workflow: What was not tested. Nothing was executed. This repository has no test suite, and the only thing that can exercise a GitHub Actions workflow on Where this sits. Waiting on you for item 1 — a few lines in the header comment. Nothing was pushed to your branch. For the maintainer there is a sequencing question this comment's map understates: #223 does not carry this branch's workflow, it replaces |
|
@scottjones if you can land this one, i can rebase the prs i have that build on top. |
The maintainer recipe in the header comment published packages without a
database. bin/promote-build skips omarchy-build.db* when it moves packages
into the published tree, and bin/repo update is the only thing that runs the
repo-add that produces omarchy.db, so sign -> promote -> sync uploaded package
files that no pacman client could resolve. Add the update step, and thread
--mirror through all four: helpers/paths.sh defaults MIRROR to edge, so the
recipe as written would have read the wrong tree for a stable artifact.
The batching suggestion on timeout-minutes was not dependency-complete either.
build/build.sh builds only the named packages and counts a dependency only
when it is also in the selected set, and it configures the production
[omarchy] repo only when a database already exists, which is never true on a
clean runner. A batch containing omarchy without omarchy-settings fails at
makepkg -s on its pinned omarchy-settings=${pkgver}. Say what the input is
actually for rather than offering it as a way to split a full build.
The log upload could never match. LOG_DIR is logs/, written only by bin/repo,
and this workflow calls bin/build directly; build/build.sh writes no log files
at all. With if-no-files-found: ignore the step was silent about it, implying
a diagnostic artifact that never existed. The job log is the diagnostic.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Thanks — items 1, 2 and 3 are fixed in 7d50d88. All three were comment-only, so the workflow's behaviour is unchanged; what changed is that the comments no longer describe things that do not work. 1. Publish recipe (medium). Confirmed, and the diagnosis was exactly right. with 2. Batching advice (low). Confirmed. 3. Log upload (low). Confirmed, and slightly worse than described — not only does this workflow call 4. On the sequencing note at the end: agreed, and thanks for catching it — I had #223 as stacked on this branch, and it is a competing rewrite of the same file rather than a follow-up. That is worth settling before either merges. cc @birkskyum, since it changes what "rebase on top" means for #223 specifically — #221 and #222 are unaffected. |
|
@ryanrhughes , this contriubtion has become quite a bottleneck - it's holding back an entire cascade of other PRs related to improving ARM support. |
|
Re-reviewed at 7d50d88 (previous pass was 60d8452). Reviewed by Claude Opus 5 and by Codex at xhigh reasoning as an independent second reviewer; Codex's independence is not currently guaranteed, so where it merely agrees below that is worth less than the one confirmation it contributed on its own. The delta is a single commit. Apart from deleting the log-upload step it is comment text only, so the workflow's behaviour is unchanged except that a step which could never have matched anything no longer runs. Items 1, 2 and 3 are fixed, and the corrections are accurate. Each claim in the new text was checked against the tree at this head rather than taken on trust. The publish recipe (lines 12-27). The batching note (lines 52-61). Accurate. The log upload. Deleting it was right rather than repointing it. Item 4, the One new thing, low, and not a reason to hold the PR. The recipe does not say where it runs. README.md:99-101 says publishing happens on the repository host — "Do not publish from a local checkout instead: only the repository host holds the complete repository and the signing key" — and README.md:219-226 repeats it. That matters for these four commands specifically: What was checked, and what was not. No PKGBUILD changes in this PR at all — Where this sits. Nothing was pushed to your branch and nothing here blocks a merge. For whoever sequences this: since the last pass a fourth aarch64 stack has appeared — #275, #276 and #277 from @maralcbr, which make aarch64 first-class in the scheduled pipeline on the repository host rather than in a dispatched GitHub-hosted job. #277 touches this PR's README.md and overlaps #240 heavily on |
|
@birkskyum This is refreshed against current master and ready for another look. The README conflicts are resolved, At This still only changes the workflow and README. My preference is to land this first, then rebase #223 so its reusable calls and repository artifact build on the merged workflow. It is ready for maintainer review and merge. |
|
I’ve updated the Dragon ISO to consume the published ARM repositories directly, so this is no longer needed from for snapdragon support. |
4 participants
Building aarch64 packages on an x86_64 host requires QEMU. This adds a manually dispatched Build aarch64 Packages workflow on
ubuntu-24.04-arm, with a native architecture check and unsigned package artifacts retained for 14 days.Choose
edge,rc, orstable, and optionally provide space-separated recipe names. Package channel and release-ring policy still applies; ordinary packages build onedge. Targeted builds must include any required recipes from this repository; package dependencies are not automatically added to the selected set. A full build has a six-hour timeout. A run that produces no package files fails visibly, and the artifact contains only package archives.To publish, download and extract the artifact on the repository host into
build-output/<mirror>/aarch64, then run:Use the same mirror as the build. This signs, promotes, updates the repository database, and syncs under one release lock.
The workflow complements the scheduled architecture support from #277. It does not enable scheduled ARM publishing; the checked-in
PUBLISHED_ARCHESdefault remainsx86_64. The PR changes only the workflow and README. #223 adds reusable workflow calls and a repository artifact to the same workflow file and will need to reconcile its changes after this lands.Validation:
bash -n;git diff --checkpassed. The summary script was exercised with empty output (failure) and a package file (success).3cc6f83passed:tzupdateon edge andsymfony-clion rc, each with one package built and zero failures. Downloaded both artifacts and verified.PKGINFOreportsaarch64and their executables have ELF machine type AArch64.A full repository build and production publication were not exercised.