Repair the Flatpak index labels, and keep them repaired

[hanthor]

The remote is decaying on its own

Coverage of AppStream labels in the served index, measured over a few hours:

Time	Coverage
Start	18/20
~1h later	10/22
~1h later	6/22

Nothing broke to cause that. It is just routine republishes. Every app that publishes re-strips its own index entry, and in a software centre each one drops to a bare application ID with an "Unknown" licence and no icon.

Why the earlier per-repo fixes stopped working

finupdate, the four installer frontends, mariner, dualcut and mandelbrot have migrated to publish through tuna-os/.github/.github/workflows/publish-flatpak.yml@main, and their local .github/scripts/ directories were deleted by that migration. The one-line fixes merged into each repo are no longer executed at all.

finupdate, xfce, kde, cosmic, niri, mariner   SHARED-WORKFLOW  (local script deleted)
dualcut                                        SHARED-WORKFLOW  (local script vestigial)
tavern                                         local script     <- the only holdout

Consolidating onto one publisher is the right direction. It just means the fix has to live in that one place, and it does not yet.

What this PR does

1. Repairs the index now. Labels read back from the registry — no rebuild, no republish. The conflict against main was resolved by taking main's index and re-deriving the repair, so this carries main's newer digests rather than reverting them.

Property	Result
Image set + digests	identical to main, 22 images
Labels removed	none
Coverage	6/22 → 21/22

2. Keeps it repaired. .github/workflows/repair-flatpak-index.yml does the same thing hourly, so the remote stops depending on a human noticing. A hand-applied repair currently has a shelf life of about an hour; this PR has already been rebuilt twice while open for exactly that reason.

The workflow refuses to commit anything but added labels. If the image set changes, a digest changes, or any label would be removed, it fails rather than pushing a corrupted index to the live remote. That guard is tested in all four directions:

no-op (identical)              rc=0  0 label(s) added; 21/22 images carry AppStream labels
a label removed  (must FAIL)   rc=1  ::error::labels would be removed: {...}
a digest changed (must FAIL)   rc=1  ::error::the image set or a digest changed; refusing to commit
an image dropped (must FAIL)   rc=1  ::error::the image set or a digest changed; refusing to commit

It pulls the script from tuna-os/flatpak-index rather than vendoring a copy — vendoring is precisely how the original one-line bug reached nine repositories.

This is a mitigation, not the fix

The fix is one line in tuna-os/.github's publish-flatpak.yml:

keep_prefixes = ("org.flatpak.", "org.freedesktop.appstream.")
"Labels": {k: v for k, v in labels.items() if k.startswith(keep_prefixes)}

Once that lands, this workflow finds nothing to do and can be deleted. I cannot open a PR against tuna-os/.github from this session — dot-prefixed repositories cannot be attached — so that one needs a human.

tuna-os/Tavern#133 remains effective on its own, since Tavern still publishes with its own script.

The one that cannot be repaired at all

ghcr.io/tuna-os/bootc-installer returns 401 from the GHCR token endpoint, so its labels cannot be read back by any means. The package is private. Until its visibility changes it stays missing, and the app is not installable from the remote by anyone. That is the 1 in 21/22.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	tunaos-org	29ad8c7	Commit Preview URL Branch Preview URL	Aug 27 2026, 06:51 AM

[hanthor-hive-agent]

Merge attempt found a genuine branch conflict; deferring for rebase per the scanner starvation guard.

🐝 Hive Agent: scanner | Instance: hive-keen-mink | SHA: unknown

— hive: agent=scanner backend=codex model=claude-opus-4-6 codex=0.146.0