Skip to content

No shas in the repo manifest - #134

Merged
Jens-Co merged 1 commit into
mainfrom
flatpak/no-shas
Aug 16, 2026
Merged

No shas in the repo manifest#134
Jens-Co merged 1 commit into
mainfrom
flatpak/no-shas

Conversation

@Jens-Co

@Jens-Co Jens-Co commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

No description provided.

The Flatpak manifest pinned files that live at moving targets: the tarball at
the dev release, the metadata on main. A hash of something that moves goes
stale by definition, which is where the run of "Renew sha256" commits came
from. Nobody was doing anything wrong; the arrangement could not be won.

Every source now points at the file beside it, so the manifest carries no urls
and no hashes at all. The only sha256 left belongs to zenity, which is a GNOME
release that never moves. There is nothing to renew by hand any more, and a
local build is: build Linux, drop the tarball in flatpak/, run flatpak-builder.

Flathub builds from its own repository and cannot reach those paths, so
scripts/flathub_manifest.py rewrites every source to a url on the tag with the
hashes computed from the files that tag serves. The release job generates it,
checks the tag really serves what it pins, and attaches it to the release. A
tag never moves, so that copy stays correct, and the x-checker-data blocks let
Flathub's own updater carry it to the next version.

The build no longer rewrites four sources into a temporary manifest either. It
copies the tarball next to the manifest and builds from the checkout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Jens-Co
Jens-Co merged commit 57fde5d into main Aug 16, 2026
8 checks passed
@Jens-Co
Jens-Co deleted the flatpak/no-shas branch August 16, 2026 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant