[Feature] Add GitHub Action Workflow for Arch Linux AUR Package publishing #33
Reference in New Issue
Block a user
Delete Branch "feat/add-arch-linux-support"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi @razvandimescu ! I came across your post about Numa on Hacker News yesterday, and love the concept of this project.
Since I'm an Arch Linux user myself, I thought I'd write up a quick GitHub Actions workflow to publish Numa as an
AURpackage anytime themainbranch updates, so that my system will auto-update anytime a new release is made.Feel free to disregard/close this PR if it doesn't fit your needs. Otherwise, changes listed below!
Note: since I haven't created the AUR account/package myself, there's a chance there still might be a bug or two in this PR (especially as this is my first time attempting to create an AUR package 😅) . We can diagnose/solve together after you've created the AUR account (assuming you want this merge this PR, of course!).
Overview
AUR(Arch User Repository) package anytime themainbranch is updatedyay numa-git)Changes
./PKGBUILD: PKGBUILD is essentially a Bash script containing the build information required by Arch Linux packages..github/workflows/publish-aur.yml: a GitHub Actions workflow to build and publish the AUR package anytime this repo'smainbranch is updated.README.md: added a one-liner install command for Arch Linux users.TODO
To enable the AUR package publishing, you will personally need to setup an AUR account (if you don't have one already) to publish the package, and add some GitHub Secrets to this repo:
1. Create an AUR Account
2. Generate a Dedicated SSH Key for GitHub Actions
Open your terminal and generate a new key pair specifically for this GitHub Action (do not use your personal key):
aur_key; you will need it for GitHubaur_key.pub3. Upload Public Key to AUR
${HOME}/.ssh/aur_key.pubinto the SSH Public Key field and save.4. Create the AUR Repository
AUR "creates" a package automatically the first time you do a git push to its URL. You can do this once manually from your machine to "claim" the AUR package name:
5. Configure GitHub Secrets
In your GitHub repository, go to Settings > Secrets and variables > Actions and add the following Repository Secrets:
AUR_SSH_PRIVATE_KEYaur_keyfileAUR_PACKAGE_NAMEnuma-gitAUR_USERNAMEAUR_EMAILOnce these secrets are set, the workflow will automatically handle all future updates!
6. Test & Merge this Pull Request
Once this pull request is merged, a new Arch Linux AUR package will be published anytime you make a new merge to the
mainbranch... meaning end-users like myself can auto-update Numa whenever a new release is created!Hi @CaseyLabs — apologies for the slow response, and thank you for the contribution.
Your PR catalyzed an upstream fix. Reviewing your
prepare()patches, I noticed numa was hardcoding/usr/local/var/numaon all Unix platforms instead of the FHS-correct/var/lib/numaon Linux. Shipped that fix in #43 (now in v0.10.1) — numa is now FHS-compliant on Linux, so PKGBUILD path patching is no longer needed at all. Your contribution had meaningful upstream impact before we even got to the AUR work.I just pushed three small fixes to your branch:
prepare()— dropped thesedpatches now that #43 makes them unnecessary.package()sed for the systemd unit — your sed targetedExecStart=/usr/local/bin/numabutnuma.serviceactually uses{{exe_path}}as a placeholder (substituted bynuma installat runtime viareplace_exe_path()). The fixed sed issed 's|{{exe_path}}|/usr/bin/numa /etc/numa.toml|g'so the AUR-installed unit gets a realExecStartpath that systemd can actually start.docker/setup-qemu-actionSHA pin — the pinned SHA6882732593b27c7f95a044d559b586a46371a68edoesn't exist in upstreamdocker/setup-qemu-action. The verified v3.0.0 SHA is68827325e0b33c7199eb31dd4e31fbe9023e06e3. Without this fix, theaarch64validate job would fail to load the action at workflow start time.Plus a small cosmetic refresh of the
pkgverplaceholder in PKGBUILD and.SRCINFO(was0.9.1.r0.g1234abcfrom before v0.10.0; now0.10.1.r0.g0000000to reflect the current era — auto-overridden bypkgver()on each build either way).Once you've had a chance to look these over, happy to merge the PR. Then I'll claim
numa-giton AUR and the workflow takes over for future commits.Genuinely thank you — not just for the code, but for being the catalyst on the FHS fix and the AUR conversation overall.
Hey @razvandimescu - that's awesome this inspired the upstream fix, and it's been fun on my end learning how AUR packages are made! I've pushed a few changes to my branch, and I think we may be all set to go now.
New changes:
Turns out Arch Linux only officially supports x86_64 architectures (I wasn't aware of this and assumed Arch supported ARM64 by default 🤦), so I've removed the aarch64 from the AUR build process
Fixed the following Arch build issues: install rust directly, fetch sources before cargo audit, and run
the audit inside the fetched repo, disabled makepkg LTO, and marked /etc/numa.toml as a backup file.
Updated the AUR GitHub Actions workflows to use
actions/checkout v6.0.2Added
/build-dirto.gitignorefor local AUR test runs.Validation:
Note:
rustls-pemfile 2.2.0as unmaintained (RUSTSEC-2025-0134), but that is currently a warning, not a failing condition. I may experiment with setting up Dependabot in a separate pull request.Hey @CaseyLabs - one more small fix I pushed to your branch.
The AUR SSH known_hosts fingerprint was truncated (52 chars of base64 vs the 71 expected for an ed25519 wire-format key), so it wouldn't have matched and the publish job would have failed at the git clone ssh://aur@... step. Verified the correct key via ssh-keyscan aur.archlinux.org and updated it:
aur.archlinux.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEuBKrPzbawxA/k2g6NcyV5jmqwJ2s+zpgZGZ7tpLIcN
@razvandimescu - looks good to me, I've synced up my branch with your change now!
@razvandimescu - just noticed the builds on main for AUR are failing. Codex suggests the following:
Current issue: the earlier broken-quote bug was fixed, but the AUR publish job still fails because its Docker container runs
makepkg -od, which triggersprepare()in PKGBUILD, andprepare()callscargo fetch --lockedeven though that container does not install cargo or rust.Potential fix:
.github/workflows/publish-aur.ymlpacman -Syu --noconfirm --needed binutils git sudopacman -Syu --noconfirm --needed binutils git sudo rust@razvandimescu - we have lift-off!
Thanks for being so open to this pull request and process. I know it included a lot of extra work on your end, but a lot of Arch users will be happy to see this available as an AUR option now!
Hey @CaseyLabs thanks so much for testing this, your banner actually caught a real bug.
numa's default isn't Quad9 - it tries to inherit your system DNS first and only falls back to Quad9 as a last resort.
It seems that on systems with NetworkManager + systemd-resolved, /etc/resolv.conf is a symlink to stub-resolv.conf containing just nameserver 127.0.0.53, and the real upstream lives inside systemd-resolved's per-link state.
numa was only parsing /etc/resolv.conf, filtering the stub, and falling through - so on most modern Linux desktops it silently landed on Quad9 instead of the user's actual router/ISP DNS.
I'm working on fixing this on #52