Publish a reusable aarch64 repository artifact - #223
Conversation
e723c3d to
525eb55
Compare
|
Native ARM64 end-to-end validation passed after making repository database creation use the target architecture: package build, omarchy.db publication, verification, and artifact upload all succeeded. Evidence: https://github.com/birkskyum/omarchy-pkgs/actions/runs/33119644049 |
|
Confirming provenance. The reusable repository workflow is mine, from |
|
Small thing: the body says "The consuming ISO work is #129", which GitHub resolves to #129 ("Update omasnap to 1.0.6") since bare numbers link within the current repo. I think you mean omacom/omarchy-iso#129, "Boot and install Omarchy on Snapdragon X ARM64 systems" — worth spelling out in full so the dependency chain is followable. Also flagging that I've narrowed #171 to CI only: the tensaku and tzupdate changes are out, so it's now just |
f8779bb to
bd75175
Compare
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.
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>
Extend the native ARM package build so an ISO workflow can call it, receive a complete omarchy.db repository artifact, and verify the requested package set.
bd75175 to
eb27276
Compare
|
The full ISO integration test exposed one reusable-workflow correction worth carrying into this PR: a recipe directory is not necessarily its pkgbase. In the selected set, Candidate fix The native GitHub ARM package job built all 31 selected recipes, producing 40 ARM64/ Two consumer-side findings belong in omacom/omarchy-iso#129: include upstream's existing ARM display-stack rebuild recipes in the caller's selection, and give those local packages repository precedence over incompatible distribution binaries. Neither needs a second package-build pipeline. Full source pins, build corrections and physical results. This advances validation beyond the previous two-package smoke test, but it is not a completed installation test or validation of all Snapdragon hardware. |
Use the existing architecture-aware metadata helper instead of treating recipe directories as pkgbases. Clarify input names and extend the existing regression cases for differing names, pkgname fallback, and target-architecture metadata.
3 participants
Summary
omarchy.dbrepository artifact for Boot and install Omarchy on Snapdragon X ARM64 systems omarchy-iso#129.Dependencies and provenance
Carries Scott Jones's CI prerequisite from #171 and Jimmy Van Veen's reusable repository work from
JimmayVV/omarchy-pkgs@snapdragon, preserving both authors. Remove the carried prerequisite after #171 merges.Uses upstream
master's ARM/Podman build pipeline without duplicating it. Package selection belongs to the caller. The Snapdragon ISO still needs #221 and #222; ARM 1Password and the Omarchy package pair are already onmaster.Validation
makepkg/repo-addsplit-package database, differing directory/base/package names, exact matching and architecture-awarepkgnamefallback. The existing CI job runs them as a non-root user; tests select workflow snippets by stable step IDs.3f3457e513322074aa9e263d2caeb20bd2f55edc, built the firmware extractor and kernel shim, published the repository, verified both pkgbases and uploaded its artifacts.d049fb66c50c02a2dcf92dd51289261d35e22dec, including the recipe-directory/pkgbase correction now carried in7e4926d. Source pins and limits: no fresh installation was performed, and live USB/power issues remain unresolved.