The gamescope deb image never needed x11-xcb until we started building the WSI layer #220
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: unom/punktfunk#220
Reference in New Issue
Block a user
🛑 Blocks the v0.28.1 tag. Caught on main's post-merge runs for
ceb081f0(run 18143, jobbuild-publish-gamescope).Not a flake, not the pin, and not best-effort noise: this fails the entire
punktfunk-gamescope.deb. Tagging as-is would publish 0.28.1 with no gamescope package on apt at all — while the release notes claim we now ship the WSI layer "on every Linux packaging channel."Why it appeared exactly now
v0.28.1 flipped
-Denable_gamescope_wsi_layer=trueinbuild-punktfunk-gamescope.sh. It was off before, on the recorded (and false) premise that the layer is version-independent of the compositor binary. The layer is a separate meson subdir with its own dependency set, and it wantsx11-xcb— which the compositor never did. An image that was sufficient for every previous release stopped being sufficient the moment the layer started building, and nothing named the new dep anywhere in the tree.Debian is the only channel that has to name it. Arch's
libx11and Fedora'slibX11-develboth shipx11-xcb.pcthemselves, which is why arch.yml and rpm.yml build the same tree fine and only the trixie image came up short. That also matches the observed failure set — one leg, not four.The change
libx11-xcb-dev(confirmed against Debian's package index as the provider ofx11-xcb.pc, and present in trixie).pkg-config --exists x11-xcbat image build, alongside the existing wayland-server floor assertion. Same argument as that one, only sharper: a missingx11-xcbdoes not fail the compositor build, it fails the layer's — and the layer is the only route to an HDR10 swapchain for a nested game. Losing it silently yields a package that looks completely healthy and denies every game HDR, which is the exact failure v0.28.1 exists to end. The assertion means the next dependency the layer grows fails at image build instead of mid-release.⚠ Ordering for the release cut
docker.ymlrebuilds this image on a push to main (its key hashes theci/tree, so this busts it), anddeb.yml's gamescope job consumes:latest. Let the image publish before the deb job that needs it runs — on the cut that means: merge this → let docker.yml finish → then push the tag. The failed job saved no cache, so the tag run rebuilds against the new image rather than restoring the broken state.Not verified locally
No Docker on this machine, so the image was not built and the layer was not compiled here. The package name is confirmed against Debian's own index; the assertion added here is what proves it in CI — if the name were wrong, the image build fails loudly instead of the deb leg failing quietly.
The v0.28.1 deb leg failed for real, and the package it costs is the whole punktfunk-gamescope .deb: gamescope/layer/meson.build:3:14: ERROR: Dependency "x11-xcb" not found, tried pkgconfig Not a flake and not the pin. v0.28.1 flipped `-Denable_gamescope_wsi_layer=true` in build-punktfunk-gamescope.sh (it was off before, on the recorded and false premise that the layer is version-independent of the compositor). The layer is a separate meson subdir with its own dependency set, and it wants x11-xcb — which the compositor never did. So an image that had been sufficient for every previous release stopped being sufficient the moment the layer started building, and nothing named the new dep anywhere. Debian is the only channel that has to name it: Arch's libx11 and Fedora's libX11-devel both ship x11-xcb.pc themselves, which is why arch.yml and rpm.yml build the same tree fine and only the trixie image came up short. Asserted as well as installed. The image already asserts the wayland-server floor at build time, on the argument that the one version deciding whether the image can do its job should fail loudly HERE rather than inside a deb.yml run — and this is the same class, only worse: a missing x11-xcb does not fail the compositor build, it fails the layer's, and the layer is the only route to an HDR10 swapchain for a nested game. Losing it silently produces a package that looks completely healthy and denies every game HDR, which is precisely the failure v0.28.1 exists to end. The assertion means the next dependency the layer grows fails at image build instead of mid-release. ORDERING, for whoever lands this: docker.yml rebuilds the image on a push to main (its key hashes the ci/ tree, so this change busts it), and deb.yml's gamescope job consumes `:latest`. Let the image publish before the deb job that needs it runs — on a release cut that means merging this, letting docker.yml finish, and only then pushing the tag. The failed job saved no cache, so the tag run rebuilds against the new image rather than restoring the broken state. NOT verified locally: no Docker on this machine, so the image was not built and the layer was not compiled here. The package name is confirmed against Debian's own package index (libx11-xcb-dev ships x11-xcb.pc, and exists in trixie), and the assertion added here is what proves it in CI — if the name were wrong the image build fails loudly instead of the deb leg failing quietly.