Stop the flatpak build updating runtimes it already has #370

Merged

enricobuehler merged 2 commits from worktree-flatpak-deps-no-update into main 2026-08-22 21:16:08 +00:00

Conversation 0 Commits 2 Files Changed 2

+164 -9

enricobuehler commented 2026-08-22 01:36:08 +00:00

Owner

Copy Link

Copy Source

The flatpak job has been dying on every attempt:

Updating runtime/org.freedesktop.Sdk.Extension.rust-stable/x86_64/25.08
Error: Failed to update org.freedesktop.Sdk.Extension.rust-stable: While pulling
  runtime/org.freedesktop.Sdk.Extension.rust-stable/x86_64/25.08 from remote flathub:
  While fetching https://dl.flathub.org/repo/objects/06/0fdf...filez:
  Server returned HTTP 404
scripts/ci/retry.sh: line 19: 911 Segmentation fault (core dumped) "$@"

dl.flathub.org was serving a 404 for one object of the then-current
rust-stable//25.08 commit. retry.sh burned all 10 attempts (~9 min) on the same
object, and flatpak-builder segfaulted on its own error path (rc=139), so the wrapper
saw a crash rather than a clean "this will never work" either.

The root cause is ours, not Flathub's

--install-deps-only does not mean "install what is missing". Confirmed against
flatpak-builder's source — builder_manifest_install_dep() branches on
flatpak info --show-commit <ref> succeeding and runs flatpak update for every dep
that is installed, with no fallback to a plain install when that update fails:

commit = flatpak_info (opt_user, opt_installation, "--show-commit", ref, NULL);
if (commit != NULL)
  {
    g_print("Updating %s\n", ref);
    if (builder_manifest_update_single_dep(ref, ...)) return TRUE;
  }
else { /* Installing %s from %s */ }

ci/flatpak-ci.Dockerfile bakes the entire runtime set, so on a healthy run that
update was a pure no-op that nonetheless made every build depend on Flathub being
healthy at that minute. Nothing about the build wanted the newer commit: the manifest
pins a runtime version, not a commit, and the baked one satisfies it.

What changed

Ask first, reach for Flathub only on a real miss. New
scripts/ci/flatpak-deps-present.sh checks the runtime + SDK at the manifest's exact
runtime-version, and the sdk-extensions by presence — their version comes from the
SDK's own metadata, so any bump that moves them moves runtime-version too and the
first two checks already catch it. It fails open: anything it cannot parse takes
the full install path, because silently skipping the install on a manifest we stopped
understanding is how you build against the wrong runtime.

--install-deps-only is still there as the miss path, warning loudly that the image
is stale — same "guard, don't install on top of a stale image" doctrine as the Tooling
step above it.

Dropped --install-deps-from=flathub from the build step. Its comment called it
"a no-op safety net"; it was neither. builder-main.c calls
builder_manifest_install_deps() whenever that flag is set — --install-deps-only
only decides whether it exits afterwards — so the step billed as offline was
re-running the same update, and it could only ever fire if the prefetch step had
already failed the job.

Added the script to the push-paths filter, so a change to the thing that decides
whether the job talks to Flathub actually gets a run.

packaging/flatpak/build-flatpak.sh keeps --install-deps-from on purpose: a dev box
genuinely wants deps installed and has no baked image.

Checks

bash scripts/ci/flatpak-deps-present.sh --self-test stubs flatpak and covers:
baked → skip, cold box → install, runtime missing, SDK missing, one sdk-extension
missing (the exact 2026-08-22 shape), runtime installed at the wrong version,
unreadable manifest → fail open. Also ran it against the real
packaging/flatpak/io.unom.Punktfunk.yml for those cases, and bash -n'd every
run: block in the workflow.

Not yet validated by a real build — the flatpak workflow is push/tag/dispatch-only, so
it does not run on this PR, and a workflow_dispatch on this branch would publish a
canary bundle and move flatpak.unom.io's canary channel. Say the word if you want
that dispatched before merge.

The flatpak job has been dying on every attempt: ``` Updating runtime/org.freedesktop.Sdk.Extension.rust-stable/x86_64/25.08 Error: Failed to update org.freedesktop.Sdk.Extension.rust-stable: While pulling runtime/org.freedesktop.Sdk.Extension.rust-stable/x86_64/25.08 from remote flathub: While fetching https://dl.flathub.org/repo/objects/06/0fdf...filez: Server returned HTTP 404 scripts/ci/retry.sh: line 19: 911 Segmentation fault (core dumped) "$@" ``` `dl.flathub.org` was serving a 404 for one object of the then-current `rust-stable//25.08` commit. retry.sh burned all 10 attempts (~9 min) on the *same* object, and flatpak-builder segfaulted on its own error path (rc=139), so the wrapper saw a crash rather than a clean "this will never work" either. ## The root cause is ours, not Flathub's `--install-deps-only` does not mean "install what is missing". Confirmed against flatpak-builder's source — `builder_manifest_install_dep()` branches on `flatpak info --show-commit <ref>` succeeding and runs `flatpak update` for every dep that *is* installed, with no fallback to a plain install when that update fails: ```c commit = flatpak_info (opt_user, opt_installation, "--show-commit", ref, NULL); if (commit != NULL) { g_print("Updating %s\n", ref); if (builder_manifest_update_single_dep(ref, ...)) return TRUE; } else { /* Installing %s from %s */ } ``` `ci/flatpak-ci.Dockerfile` bakes the entire runtime set, so on a healthy run that update was a pure no-op that nonetheless made every build depend on Flathub being healthy at that minute. Nothing about the build wanted the newer commit: the manifest pins a runtime **version**, not a commit, and the baked one satisfies it. ## What changed **Ask first, reach for Flathub only on a real miss.** New `scripts/ci/flatpak-deps-present.sh` checks the runtime + SDK at the manifest's exact `runtime-version`, and the `sdk-extensions` by presence — their version comes from the SDK's own metadata, so any bump that moves them moves `runtime-version` too and the first two checks already catch it. It **fails open**: anything it cannot parse takes the full install path, because silently skipping the install on a manifest we stopped understanding is how you build against the wrong runtime. `--install-deps-only` is still there as the miss path, warning loudly that the image is stale — same "guard, don't install on top of a stale image" doctrine as the Tooling step above it. **Dropped `--install-deps-from=flathub` from the build step.** Its comment called it "a no-op safety net"; it was neither. `builder-main.c` calls `builder_manifest_install_deps()` whenever that flag is set — `--install-deps-only` only decides whether it *exits* afterwards — so the step billed as offline was re-running the same update, and it could only ever fire if the prefetch step had already failed the job. **Added the script to the push-paths filter**, so a change to the thing that decides whether the job talks to Flathub actually gets a run. `packaging/flatpak/build-flatpak.sh` keeps `--install-deps-from` on purpose: a dev box genuinely wants deps installed and has no baked image. ## Checks `bash scripts/ci/flatpak-deps-present.sh --self-test` stubs `flatpak` and covers: baked → skip, cold box → install, runtime missing, SDK missing, one sdk-extension missing (the exact 2026-08-22 shape), runtime installed at the wrong version, unreadable manifest → fail open. Also ran it against the real `packaging/flatpak/io.unom.Punktfunk.yml` for those cases, and `bash -n`'d every `run:` block in the workflow. Not yet validated by a real build — the flatpak workflow is push/tag/dispatch-only, so it does not run on this PR, and a `workflow_dispatch` on this branch would publish a canary bundle and move `flatpak.unom.io`'s canary channel. Say the word if you want that dispatched before merge.

enricobuehler added 2 commits 2026-08-22 01:36:09 +00:00

fix(ci): stop the flatpak build updating runtimes it already has ... 92578803c2

The flatpak job died on every attempt with

    Updating runtime/org.freedesktop.Sdk.Extension.rust-stable/x86_64/25.08
    Error: Failed to update org.freedesktop.Sdk.Extension.rust-stable: While
      pulling ... .filez: Server returned HTTP 404

dl.flathub.org was serving a 404 for one object of the then-current
rust-stable//25.08 commit. retry.sh burned all 10 attempts (~9 min) on the
same object, and flatpak-builder segfaulted on its own error path (rc=139),
so the wrapper could not tell a dead end from a load blip either.

Root cause is ours, not Flathub's: `--install-deps-only` does not install
what is missing, it UPDATES what is present. builder_manifest_install_dep()
branches on `flatpak info --show-commit <ref>` succeeding and runs
`flatpak update` for every already-installed dep, with no fallback to a
plain install when that update fails. ci/flatpak-ci.Dockerfile bakes the
entire runtime set, so that update was a pure no-op on a healthy run while
making every build depend on Flathub's health at that minute. Nothing wanted
the newer commit — the manifest pins a runtime VERSION, not a commit.

So ask first, and reach for Flathub only on a real miss. The check is
scripts/ci/flatpak-deps-present.sh (runtime + SDK at the manifest's exact
runtime-version, sdk-extensions by presence, since their version comes from
the SDK's metadata and any bump that moves them moves runtime-version too).
It fails OPEN: anything it cannot parse takes the full install path. Its
--self-test stubs `flatpak` and covers baked / cold / each dep missing /
wrong version / unreadable manifest.

Also drop --install-deps-from=flathub from the build step. Its comment
called it "a no-op safety net"; builder-main.c calls
builder_manifest_install_deps() whenever that flag is set, and
--install-deps-only only decides whether it exits afterwards, so the step
billed as offline was re-running the same update — and could only ever fire
if the prefetch step had already failed the job.

packaging/flatpak/build-flatpak.sh keeps --install-deps-from: a dev box
genuinely wants deps installed, and it has no baked image.

ci(flatpak): trigger on the deps-check script too ... 430499bdab

flatpak-deps-present.sh decides whether the job talks to Flathub at all, and
a push-paths filter that ignores it means a change to that decision ships
untested until the next unrelated client commit happens to rebuild. Same
reason .gitea/workflows/flatpak.yml is already listed.

enricobuehler merged commit 7f77fa68af into main 2026-08-22 21:16:08 +00:00

enricobuehler deleted branch worktree-flatpak-deps-no-update 2026-08-22 21:16:14 +00:00

enricobuehler referenced this issue from a commit 2026-08-22 22:54:41 +00:00

release: 0.31.3 — version bump, notes, CHANGELOG, Play notes

enricobuehler referenced this issue from a commit 2026-08-23 10:01:50 +00:00

release: 0.31.3 — version bump, notes, CHANGELOG, Play notes

enricobuehler referenced this pull request 2026-08-23 10:02:22 +00:00

0.31.3 — the launch that dropped, the refresh a TV never output, and the probe that choked the link #386

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX FlipperDan HitFrostbite enricobuehler (Enrico Bühler) kszlim luxus nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#370