Heads-up: nono-ai-bin AUR package now available

[sarovin]

Opening this as a heads-up rather than a request: nono is now available on the AUR as nono-ai-bin, a third-party binary package that tracks your official GitHub release tarballs. It currently packages v0.54.0 for both x86_64 and aarch64, and verifies the release assets with sha256 checksums.

The reason for the -bin variant is that nono-ai and nono-ai-git already exist on the AUR, but both build from source. The binary package uses your published release artifacts directly, so installs and updates are much faster while still integrating with pacman and AUR helpers for dependency tracking, clean uninstall, and normal batch upgrades through tools like yay or paru.

About the name: nono is already taken in the official Arch repositories by an emulator, so I used nono-ai-bin to avoid the clash. The -bin suffix follows the standard AUR convention for packages based on pre-built binaries.

I'm opening this mainly for transparency, so you know there's a third-party Arch package out there. If you ever decide to publish or endorse an official Arch package, I'd be glad to coordinate on naming or maintainership. In the meantime, I can also open a small PR adding an Arch Linux install section to the README if that would be useful.

LINK: https://aur.archlinux.org/packages/nono-ai-bin

[lukehinds]

Thanks so much @sarovin , really appreciate it - would you mind making a follow up PR to the docs, we maybe able to add something to the readme as well!

[sarovin]

Hi @lukehinds, thanks so much for the reply!

I'll work on the docs PR as soon as I can — my plan is to add an "Arch Linux (AUR)" subsection to cli/getting_started/installation.mdx (same style as the existing Debian/Ubuntu and Nix entries), with a small "community maintained" disclaimer to make it clear the package isn't official. Happy to add a small note to the README as well if you'd like — let me know.

While I'm at it, I'd like to float an idea: if you're interested, we could automate the AUR package update on each release, similar to what release.yml already does for the Homebrew formula. There are well-established GitHub Actions (e.g. KSXGitHub/github-actions-deploy-aur) that, triggered on release, bump pkgver and the sha256sums in the PKGBUILD and push directly to the AUR.

To do this cleanly, here's the approach I'd suggest:

1. I add you (or a project bot account) as co-maintainer of nono-ai-bin on the AUR. I'd stay on as maintainer too, but you'd have full operational control.
2. You create a dedicated AUR bot account (or use an existing one you prefer), generate an SSH key scoped only to this purpose, and add it as a repo secret alongside AUR_USERNAME / AUR_EMAIL.
3. I open a follow-up PR that adds an update-aur job to .github/workflows/release.yml, parallel to update-homebrew-core, with the same pre-release skip (alpha/beta/rc).

The reason I'd suggest a dedicated account + key rather than reusing my personal AUR credentials is to keep my personal AUR identity out of a third-party org's CI, and to reduce the blast radius if the secret is ever leaked — since anyone with push access to the AUR package can effectively run code as root on every Arch machine that does yay -S nono-ai-bin. Felt like the most hygienic pattern given how security-sensitive this project is.

If you'd rather keep the update manual (bumping pkgver and the two sha256s is about 2 minutes per release), no problem at all — I'm happy to keep doing it by hand as I have been.

Let me know what you prefer. In the meantime, I'll get started on the docs PR.

[lukehinds]

@sarovin so sorry, i completely missed your reply in my notifications.

Agree with your three points - an automated approach would be excellent , if you see this and still are up for doing the work, lets go for it. Should I start by getting signed up to AUR?

[sarovin]

@lukehinds
No worries about the delay, I can only imagine how much there is to keep on top of. I'm still around and happy to help.

Actually, I already wrote the GitHub Action while we were waiting, so I'll open a PR against release.yml soon.
GitHub Action: https://github.com/sarovin/nono-ai-bin/blob/main/.github/workflows/update-aur.yml

My suggestion would be to create an AUR account just for this rather than using your personal one. Generate an SSH key (ssh-keygen -t ed25519 -C nono-aur-bot), add the public key to the AUR account, and send me the username. I'll add it as a co-maintainer on nono-ai-bin so it has push rights. After that, the repo will only need AUR_SSH_PRIVATE_KEY as a secret. The SSH key is what authorises the push, so there's nothing else to configure.

I'll describe the exact steps in the PR description anyway, which I'll write as soon as I can.

Thanks for getting back to me!

[lukehinds]

thanks @sarovin nice clear easy to follow steps!

username: lukehinds

The key is also in AUR_SSH_PRIVATE_KEY as an actions secret.

[sarovin]

@lukehinds The PR is ready.
It moves the PKGBUILD and the update script in-tree (packaging/aur/) and adds an aur-publish.yml workflow that runs after each Release and pushes to the AUR — same pattern as image-build.yml. It only pushes when the generated files differ from what's already on the AUR, so re-runs are safe no-ops.

A few notes:

• it uses the AUR_SSH_PRIVATE_KEY secret you already set up; AUR host keys are pinned and verified, prereleases are skipped
• the PKGBUILD also drops dbus from depends (with a pkgrel bump): the release binary doesn't link libdbus — release.yml already enforces that — and the Secret Service daemons in optdepends pull dbus in anyway
• the workflow_run trigger can only be tested after merge; the plan is a manual workflow_dispatch run with the current tag, which will publish the pkgrel bump above and exercise the whole flow end to end

This work was prepared with AI assistance (Claude Code), under my direction and review.