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.
|
@scottjones, following up on your sequencing note: you were right that this substantially rewrites the same workflow, so my earlier suggestion to merge #171 and then rebase did not settle the overlap. Would you be comfortable consolidating the native ARM workflow here in #223? It would keep manual builds and add Jimmy's reusable repository artifact for omacom/omarchy-iso#129, using the existing package builder. Signing and production publication would remain outside this workflow. Your three CI commits and Jimmy's repository-workflow commit are retained with their authorship. I would reconcile the remaining differences here, including retaining your If that approach works for you and the maintainers, this could supersede #171 once the consolidated version is accepted. I will leave that decision with you rather than assume agreement. #221 and #222 remain independently reviewable. |
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 native ARM CI work from #171 and Jimmy Van Veen's reusable repository work from
JimmayVV/omarchy-pkgs@snapdragon, preserving both authors' commits.Workflow coordination: #171 and this PR propose different versions of the same workflow. The proposed landing route is one consolidated workflow through this PR, retaining manual builds and adding reusable repository artifacts. This awaits Scott's and the maintainers' agreement; #171 is not being treated as superseded, and merging it first would still require reconciling the workflow differences.
master. This generic workflow can land independently of the Snapdragon recipes in Add safe Windows firmware extraction for Snapdragon laptops #221 and Add linux-aarch64 kernel compatibility shim #222.master, so that reference cannot resolve until this PR lands.master.The output is a GitHub Actions repository artifact for the ISO build. This workflow does not publish the signed production repositories at
pkgs.omarchy.org; package availability in those channels remains a separate delivery step.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.