python-pywal was dropped from Arch's [extra] repo (AUR-only now), so
`pacstrap` can no longer resolve it and every ISO build fails with
"target not found: python-pywal". The `wal` binary is load-bearing —
bread-theme shells out to it to extract the colour palette from the
user's wallpaper.
Republish it the same way as calamares / bibata / powerlevel10k /
yay-bin:
- `packaging/python-pywal/PKGBUILD` — in-house copy of the AUR PKGBUILD
(Morten Linderud's), modernised to `python -m build` / `installer`
instead of the removed `setup.py install`, sha256-only sources like
the sibling PKGBUILDs. Test-built locally: 28 unit tests pass, package
ships `/usr/bin/wal`.
- `.forgejo/workflows/python-pywal.yml` — builds + PUTs to the Forgejo
Arch registry on a push to `packaging/python-pywal/**`.
- `signed-repo.yml` gains it as a `workflow_run` trigger;
`ci-publish-signed-repo.sh` gains it in `PACKAGES` so the signed
dl.breadway.dev/arch db picks it up.
- packages.x86_64 keeps the `python-pywal` line (now sourced from
[breadway]) with a note.
Ordering: `python-pywal.yml` must publish to the registry once before
`signed-repo.yml` runs, or the collect step errors "registry db missing
packages: python-pywal".
Docker as root left 0600 .sig files the runner could not chmod
(run 1050), so publish_tree never moved the tree into
/srv/breadway-dl/arch/x86_64. Sign as the host uid so nginx can
read the files and the next publish can replace them.
Host job on hestia (no container) collects breadlock plus the ISO AUR
republishes from the Forgejo registry, detach-signs them, repo-add -s,
and writes /srv/breadway-dl/arch/x86_64/. ISO SigLevel stays Never.
