Point the PKGBUILD at the current repo and release

[nfvelten]

Fixes #21.

packaging/PKGBUILD had rotted in three ways, and they only work as a set:

1. url="https://github.com/basecamp/ttfx" — 404s since the move to omacom. source= interpolates $url, so this is the download failure reported in Invalid url in PKGBUILD #21.
2. pkgver=0.1.0 — six releases behind v0.3.2. Correcting the url alone still fetches a stale tarball, so this had to move too.
3. sha256sums=('SKIP') — the downloaded release tarball was never verified. Now carries the real digest.

Nothing else changed; build(), check() and package() were already correct at 0.3.2.

Testing

makepkg -f on Arch, from a clean directory:

==> Validating source files with sha256sums...
    ttfx-0.3.2.tar.gz ... Passed
...
==> Finished making: ttfx 0.3.2-1

cargo test --release --locked passes in check(). The resulting package contains usr/bin/ttfx, the README and both completion files, and the binary reports ttfx 0.3.2.

Two negative checks, so the diff is not just cosmetic:

• reverting only url to basecamp (keeping pkgver=0.3.2) still fails with curl: (22) ... 404 — the url fix is necessary
• corrupting one byte of the new checksum gives ttfx-0.3.2.tar.gz ... FAILED — the digest is actually enforced

Notes

• pkgver will drift again on every release. Release binaries #20 (release binaries) plus a release workflow would let this consume real assets instead of /archive/ tarballs, which is also the durable answer to the checksum caveat — GitHub's generated archives are not contractually byte-stable. Left out of this PR deliberately.
• arch=('x86_64') still excludes aarch64. I have no aarch64 machine to test on, so I left it alone.

[omarchybot]

Reviewed at 137dccb. This is correct and it closes #21.

The URL in packaging/PKGBUILD was pointing at basecamp/ttfx, which is why the link in that issue 404s; the repository now lives at omacom/ttfx. With the new url and pkgver the source= line expands to https://github.com/omacom/ttfx/archive/v0.3.2.tar.gz, that archive extracts to ttfx-0.3.2/, and every cd "$pkgname-$pkgver" in build(), check() and package() matches it. v0.3.2 is the current release and Cargo.toml on this branch also says 0.3.2, so the packaged version and the crate version agree. The three remaining basecamp/ strings in the tree are all citations of basecamp/omarchy#6762 in comments, not ownership references, so leaving them is right.

Two things for the maintainer rather than the author.

Replacing SKIP with a real digest is an improvement, but it pins to a GitHub auto-generated tag archive, and those are not guaranteed to stay byte-identical. If GitHub ever changes how it generates them the source is unchanged but makepkg refuses the download, which is a packaging outage needing a hand-checked digest rather than a silent substitution. An uploaded release asset is the more durable thing to hash if that is worth doing later.

bin/release:146 still builds its download URL from omacom-io/ttfx. A second opinion read that as broken; it is not — omacom-io is the previous organisation name and GitHub redirects it, which every API call in this review confirmed, and that line uses curl -fsSL, which follows the redirect. So it works today and is a consistency tidy-up, not a defect, and it is out of scope for this PR.

Reviewed by Claude Opus 5 in Claude Code with a second opinion from Codex at xhigh reasoning, which independently checked the extraction path and the version agreement and raised the checksum-durability point above. That second opinion runs on the same machine as the first, so its independence is not guaranteed, and its one finding about bin/release is the one I checked and rejected. Neither of us could fetch the tarball to verify the literal digest, because this run has no outbound network beyond the GitHub API — so the sha256 itself is unverified.

Nothing pushed. Waiting on the maintainer.