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".
The signed repo is live: https://dl.breadway.dev/arch/x86_64/ serves
breadway.db + .files + every .pkg.tar.zst with a detached .sig from the
BOS release key (56203B86A110695AE7F310934AF3323D678EB5E2 = KEYS.asc),
rebuilt from the Forgejo Arch registry by signed-repo.yml +
scripts/ci-publish-signed-repo.sh. Verified: db/pkg sigs all GPG-good
against KEYS.asc.
Executes the "After the signed repo exists" plan in docs/signed-repo.md:
- `iso/pacman.conf` + `iso/airootfs/etc/pacman.conf`: section renamed
`[Breadway.os.git.breadway.dev]` → `[breadway]` (matches breadway.db),
`Server = https://dl.breadway.dev/arch/$arch`, `SigLevel = Required`.
The old "Forgejo has no db sigs / KEYS.asc is not a repo key / do NOT
flip" comments are gone — both are now false.
- `iso/airootfs/etc/pacman.d/breadway-repo.asc`: the public key, baked
into the image.
- `build-local.sh`: trust the key in the build host's pacman keyring
before mkarchiso (so pacstrap can verify [breadway] while assembling
the airootfs); drop the now-obsolete Forgejo-registry URL rewrite.
- `iso/airootfs/root/customize_airootfs.sh` (new): trust the key in the
image keyring so the live medium — and, via calamares unpackfs, the
installed target — verify [breadway]. (archiso warns this hook is
deprecated; there is no replacement for "add a repo key to the image
keyring" and BOS ships no pacman-init.service.)
- `calamares/post-install.sh`: `pacman-key --add` + `--lsign-key` the
BOS key in the target chroot as a fallback (unpackfs can skip
/etc/pacman.d/gnupg).
- README.md / DESIGN.md / docs/signed-repo.md updated.
NOT yet done: build the ISO (`sudo ./build-local.sh`) and VM-verify
`pacman -Sy` + a `[breadway]` install with no signature prompt, on both
the live medium and a fresh install. The build-time keyring path
(pacstrap -G vs host keyring vs customize_airootfs) may need a tweak
once the real build runs.
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.
Point os-release at the bos repo and issues; drop Arch privacy terms.
Take a best-effort snapper pre snapshot before pacman and bakery.
Pin current stable bakery versions so CI fetches the same bits per commit.
Autostart breadpaper/breadshot listen behind command -v.
Document signed-repo setup and Mesa/NVIDIA/grub-btrfs recovery.
