## Why
`nzbget` is absent from the artifactapi `rpm-vendor-el9` / `rpm-vendor-el8` repodata, so `dnf install nzbget` fails on the media host (AlmaLinux 9.7). The legacy Gitea RPM registry is being removed from hosts by puppet-prod #496, so nzbget must land in `rpm-vendor-el9` or installs break.
Root cause: nzbget's `build.sh` built the GitHub download URL from `PACKAGE_RELEASE`, which carries the dist tag (e.g. `1.el9`). Upstream only publishes `nzbget-<version>-1.x86_64.rpm` (no dist tag), so the fetch 404s and a 22-byte "upstream returned 404" junk file is what gets published — createrepo cannot index it, so the package never appears in the repo metadata. The stale junk `nzbget-26.1-1.el9` also makes the deploy step's dedup probe return HTTP 200, which would skip re-uploading a corrected 26.1.
## How
- Point the `build.sh` source URL at the upstream release-1 asset name (`nzbget-${PACKAGE_VERSION}-1.x86_64.rpm`) while keeping the dist-tagged local output filename, mirroring the `code-server` package which repackages a prebuilt upstream RPM the same way.
- Bump nzbget el8/el9 to `26.2` (current upstream stable) so the corrected build produces a fresh filename the deploy step will actually PUT (side-stepping the stale-junk dedup skip).
## Validation
- Confirmed the corrected URL fetches a real 9.1MB RPM through artifactapi's github remote: `NAME=nzbget VER=26.2 REL=1 ARCH=x86_64`.
- `pytest` 72 passed; metadata validates against `schema/metadata.json`; all pre-commit hooks pass (yamllint, check-jsonschema, etc.).
## Post-merge
The deploy pipelines (`.woodpecker/deploy-almalinux{8,9}.yaml`) run on push to `master`. On merge they will `build-all --distro almalinux/el{8,9}`, build nzbget 26.2, and PUT `nzbget-26.2-1.el{8,9}.x86_64.rpm` to `rpm-vendor-el{8,9}`; artifactapi regenerates repodata so `dnf install nzbget` resolves.
https://claude.ai/code/session_015ur3i7D2azsMAWTSVABApv
Reviewed-on: #170
Co-authored-by: Ben Vincent <ben@unkin.net>
Co-committed-by: Ben Vincent <ben@unkin.net>
- Add github_release_pattern field to support multi-product repositories
- Implement get_github_releases_by_pattern() for filtered release matching
- Add parse_github_version_release() to extract version-release components
- Update openbao plugin packages with release patterns and correct versions
- Configure openbao-plugins meta package for manual versioning
- Fix HashiCorp package GitHub repository references
- Support complex tag formats like "secrets-consul-v0.1.0" and "v7.1.3-1"
This enables automatic updates for packages sharing GitHub repos while
maintaining proper RPM version/release semantics and backward compatibility.
- Migrate from legacy shell-based build system to modern Python tooling
- Update all metadata.yaml files to new schema with per-distro builds
- Standardise build scripts with curl -L, envsubst, and error handling
- Convert nfpm.yaml templates to use environment variable substitution
- Update Dockerfile to accept all package metadata as build arguments
- Modernise Makefile to use new Python build tool commands
- Update CI workflow to use tools/build instead of make
Add simplified metadata structure for all 41 packages containing:
- Package name, version, and release number
- GitHub repository for packages with GitHub releases
- Build configuration for el/8 and el/9 distributions
This metadata enables future automation for version checking and package building across different distributions.
unkinben