[juanluisbaptiste]

Hi Ben,

First of all, many thanks for this program! now I don't need to find my phone to configure my WiiM Amp!

I created an Arch Linux package for the AUR repo. This commit includes the PKGBUILD file needed to submit for the AUR package, which you can submit with your AUR account (if you have one, I don't), and a README file with some instructions on how to build the package locally and how to submit it, if you do not know how to do it.

The package is using the current lastest 0.13.0 version. It works fine, it installs a desktop entry for easy access to it.

I hope this helps and keep the good job!

[ozbenh]

Thanks, I'll look at is as soon as I have spare cycles and see if I can it plumbed in the github actions to auto-generate binary packages like I do for other distros

[ozbenh]

How set are you in having it in that form ? I'm not particularly familiar with Arch and its packaging system, but so far I've avoided most top-level distro things, mostly relying on cargo deb and cargo rpm magic. Unfortunately claude tells me there isn't a good equivalent for arch, but it suggests auto-generating some of it.

Here's a summary of claude answer to my questions, what do you think ?

Why this can't work like the deb/rpm do

We don't carry a debian/ dir or a .spec file: cargo-deb and
cargo-generate-rpm both write the archive format themselves, driven by
[package.metadata.*] in Cargo.toml, so make deb / make rpm work
anywhere. Arch has no equivalent — building a .pkg.tar.zst needs makepkg +
fakeroot + pacman, i.e. a real Arch root.

More importantly the artifacts aren't the same kind of thing. A .deb/.rpm on
the release page is the deliverable. For Arch the deliverable is the PKGBUILD
in the AUR — a build recipe, in its own git repo. A prebuilt .pkg.tar.zst
attached to a GitHub release is actively fragile on a rolling distro: it breaks
the moment gtk4/libadwaita/glib bump a soname. Debian and Fedora don't have that
problem because their releases are frozen.

(I looked at cargo-aur as the obvious candidate — it's stale, last released
March 2024, generates a -bin style PKGBUILD that downloads a prebuilt x86_64
tarball, and doesn't produce .SRCINFO. Not a fit.)

So: the PKGBUILD stays hand-written. That's fine, it's the right shape for Arch.

Bugs to fix

• makedepends is missing glib2-devel. build.rs shells out to
  glib-compile-resources, and Arch split that out of glib2 into
  glib2-devel in 2024. The listed glib2 doesn't provide it, so this fails in
  a clean chroot. (gcc and pkgconf are redundant — they're in base-devel.)

• The built binary reports the wrong version. From a release tarball there's
  no .git, so build.rs's git describe falls through to its last branch and
  produces CARGO_PKG_VERSION + "+". The package would say 0.13.0 while the
  About dialog says 0.13.1+.

• url= is misused. In a PKGBUILD url is the project homepage shown by
  pacman -Si, not the source URL. Should be
  url="https://github.com/ozbenh/rustywiim" with the tarball spelled out in
  source=().

• pkgver=0.13.0 is already behind the current tag.

• Minor: glibc, libgcc, pango and glib2 in depends are pulled in
  transitively by gtk4 and namcap will flag them.

The last three all have one root cause: a checked-in PKGBUILD with a
sha256sums of a release tarball is inherently self-referential. You tag, then
compute the sum, then commit a change after the tag it describes — so whatever
is in the tree is always one release stale. Switching to a git source fixes the
staleness, the pkgver drift and the version bug in one go:

source=("$pkgname::git+https://github.com/ozbenh/rustywiim.git#tag=v$pkgver")
sha256sums=('SKIP')

makepkg gives that a real clone, so git describe works and the binary
reports the right version.

Layout

Could we make this a single file — packaging/PKGBUILD — rather than
aur/rustywiim/ with a README and a .gitignore?

The nested dir mirrors the AUR repo's own layout, but nothing in-tree ever runs
from that path, so it only helps a cp -r into an AUR checkout. The macOS
precedent is one file (macos/entitlements.plist) that the build actually
consumes. Nothing is built in-tree here so the .gitignore isn't needed, and
I'd rather the release instructions live with the rest of the release process
than as a second copy that drifts.

One correction on the README while it's still here: the AUR's server-side hook
requires .SRCINFO, so a push with only the PKGBUILD is rejected. And
aur-helper push --yes isn't a real command — submission is
git remote add aur ssh://aur@aur.archlinux.org/rustywiim.git and a plain
git push.

/usr/lib vs /usr/libexec

Installing the diagnostic tools to /usr/lib/rustywiim rather than the
/usr/libexec the deb/rpm use is correct — Arch deliberately doesn't have
/usr/libexec. Nice catch.

CI

Separately I'd like to add a validation job so a broken recipe fails the release
instead of surfacing as AUR bug reports. Rough shape:

  pkg-arch:
    name: .pkg.tar.zst (Arch)
    runs-on: ubuntu-latest
    container: archlinux:base-devel
    steps:
      - run: pacman -Syu --noconfirm git gtk4 libadwaita glib2-devel rust
      - run: git config --global --add safe.directory '*'   # same reason as the debian/fedora jobs
      - uses: actions/checkout@v5
        with: { fetch-depth: 0 }
      - run: useradd -m builder && chown -R builder .       # makepkg refuses to run as root
      - run: sudo -u builder makepkg -s --noconfirm

The useradd is the non-obvious bit — Actions containers run as root and
makepkg hard-refuses that.

I don't plan to attach the resulting .pkg.tar.zst to the release (see the
rolling-distro caveat above); the job is there to prove the recipe builds.
Pushing to the AUR is the part that actually reaches users, and that's a
separate job needing an AUR_SSH_KEY secret plus
makepkg --printsrcinfo > .SRCINFO. Happy to wire that up once the PKGBUILD
itself lands.

Also, longer term: [package.metadata.generate-rpm].assets in Cargo.toml
already holds exactly the source→dest→mode triples package() needs, so a small
generator could emit the package() body from it and keep one asset list. Not a
blocker for this PR.