204 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Fable 5	beefeaf9d7	fix(ci/windows-host): refuse to pack an installer that is missing a payload ... Every payload the job bundles is now asserted before packing: the console, the bun runtime, the plugin runner, the FFmpeg DLLs and VB-CABLE. Each is optional to pack-host-installer.ps1 — right for a local debug pack, and the reason 0.22.1 and 0.22.2 shipped with no web console: one unset variable omitted it behind a single line of log and the build stayed green. CI knows it bundles all five, so a missing input belongs here as a failure rather than downstream as a quietly smaller installer. FFmpeg is the one that would hurt most and was silent too: an amf-qsv host link-imports avcodec, so an installer missing those DLLs ships a host that cannot start at all, and FFMPEG_DIR is a fallback to a provisioned path that nothing verified. The shape is borrowed from the packer's own VB-CABLE check, which already throws on a supplied-but-empty dir "instead of silently shipping an installer without the virtual mic - exactly the field regression this bundling fixes". Same lesson, applied to the rest. Both paths were exercised on the Windows runner: all five unset fails with exit 1 naming each one, all five present passes with exit 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 14:36:46 +02:00
enricobuehlerandClaude Fable 5	5b6fe7882a	fix(ci/windows-host): a cached console no longer ships an installer without one ... WEB_OUTPUT_DIR was exported on the last line of "Build + smoke-boot web console", a step that is skipped on a cache hit. So the second and every later build with an unchanged web/ and sdk/ left it unset — and pack-host-installer.ps1 reads an unset WEB_OUTPUT_DIR as "don't bundle the console" and says so in one line of log before carrying on happily. The installers that fell out of that have no {app}\web at all: no web-run.cmd, so `web setup` bails with "web launcher missing" before it registers anything, so there is no PunktfunkWeb task, no console, and no firewall rule for 47992. A user is left with a working host, a tray that says "Open web console (not responding)" for ever, and nothing to reinstall their way out of, because every rebuild reproduces it. It also explains the bun.exe lock reported separately. bun.exe ships under WithWeb OR WithScripting, but the pre-copy stop was #ifdef WithWeb — so in a console-less installer bun still shipped while the only code that stopped bun was compiled out, and replacing a running bun.exe is the "DeleteFile failed; code 5" modal. Exporting the variable from its own unconditional step fixes it. The throw alongside is the actual lesson: a missing web\.output now fails the job instead of silently redefining what the installer is. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 14:36:46 +02:00
enricobuehlerandClaude Fable 5	c4c4f217bf	ci(update): build+sign+publish the update manifest — stable at announce, canary after the canary installer ... bash+openssl signer (raw-64-byte ed25519 over exact bytes, base64 .sig — the plugin-index format) with the pinned-key cross-check, manifest-then-sig upload order, and a live-feed self-verify. announce.yml re-hashes the installer against its sidecar and fail-closes without UPDATE_MANIFEST_KEY; pre-release tags never enter the stable feed. windows-host.yml grows a Linux canary-manifest job. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 14:34:47 +02:00
enricobuehlerandClaude Fable 5	a48321ee27	test(client): CI runs the binaries it ships ... The 0.22.0 clobber proved a gap no build gate covers: a wrong program wearing the right binary name compiles green. `cargo build -p punktfunk-client-session` happily shipped the GTK shell's three-line Windows stub as punktfunk-session, because nothing between commit and release ever EXECUTED the result. Two integration tests close the class, and they run under gates that already exist (ci.yml's workspace test on Linux, windows.yml's test step on Windows): - contract_smoke spawns the real punktfunk-session against a refusing port and asserts the stdout contract answers — whatever fails first on the machine (presenter init headless, the dial elsewhere), the binary must SAY so in a contract line. Proven non-vacuous by planting the 0.22.0 stub and watching it fail, then pass again on the real main.rs. - cli_smoke runs the real punktfunk over its help surface (stdout, exit 0) and an unknown verb (stderr, exit 5) — store-free and network-free, safe on any runner. windows.yml now gates punktfunk-cli in all four steps (build, clippy, fmt, test): the MSIX has shipped its `punktfunk.exe` alias since bf981027, but only the release workflow ever compiled it — a PR could break the CLI and find out on tag day. The session README also stops selling `--pair` as the enrolment route (deprecated by bf981027, `punktfunk pair` is the door) and says out loud what this binary is: a deliberately dumb renderer the GTK shell, the WinUI shell and the CLI all call into through one brain. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 10:58:44 +02:00
enricobuehlerandClaude Fable 5	5c0cb84fda	fix(ci/windows-host): drop the drivers-target cache — act rotates the workspace path ... I added it yesterday on the theory that cargo's fingerprints would sort out a restored in-tree target/. They can't: act gives each run a different absolute workspace (~/.cache/act/<hash>/hostexecutor), and a target dir restored under a new path carries state pointing at the old one. Measured today — pf-umdf-util died with 14 x 'unable to create file lock (os error 3)' and failed the job. ~1 min of rebuild is the right price, and it's the same rotation that made the other Windows jobs use a fixed C:\t. The web console cache stays: it restored cleanly and skipped its ~2.5 min build+smoke, taking the job 13.6 -> 8.5 min in the same measurement. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 10:46:47 +02:00
enricobuehlerandClaude Fable 5	2b82ce6484	fix(ci/flatpak): host networking — ostree's resolver never worked through docker's embedded DNS ... The flathub fetch has failed 10/10 retries for months, blamed on fleet load and DNS tuning. It is neither. Measured on home-runner-2, all inside ONE container: getent resolved dl.flathub.org, curl fetched the same URL with HTTP 200 (auto and -4), and flatpak still died '[6] Could not resolve hostname'. Rewriting resolv.conf to a real nameserver didn't help; the default bridge failed too; --network host works every time. So it is ostree's own resolver against Docker's embedded 127.0.0.11, and removing that resolver from the path is the fix. retry.sh stays as the backstop for genuine upstream blips. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 01:29:13 +02:00
enricobuehlerandClaude Fable 5	be2fabcfba	feat(ci/windows-host): the console and the drivers stop rebuilding what nobody changed ... The job's two cache-shaped tails, now actually cached (the runner just got wired to the central cache server — it had none): web/.output restores and skips the ~2.5 min bun build+smoke whenever web/ and sdk/ are untouched, and the UMDF drivers' in-tree target/ (which checkout's clean wiped every run because wdk-build can't relocate it) restores so cargo's fingerprints declare it fresh. Typical run: ~13.6 min -> ~10. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 00:30:59 +02:00
enricobuehlerandClaude Opus 5	bb7baef20b	fix(client/android): the menus keep their safe area after a stream ... Returning from a stream left every menu laid out against the wrong safe area: content shoved right, the profile row sliding under the status bar, the tab labels crowding the gesture pill. Dumped on the reporter's phone, the window's real insets were bars=[0,162,0,72] cutout=[0,162,0,0] while the layout was using the landscape immersive set — cutout left=162 (Material3 lays out against systemBars.union(displayCutout)), bars all zero. No rotation and no IME animation could shake it loose. Compose attaches its OnApplyWindowInsets and WindowInsetsAnimation callbacks when the first composable reads an inset and removes them when the last reader goes away (WindowInsetsHolder.increment / decrementAccessors). StreamScreen reads no insets at all, so a stream drops that count to zero for its whole duration. Survivable on its own — but a session that ends while the app is BACKGROUNDED is the common case (leaving the app ends the session), and then the entire window restore runs on a stopped activity. The corrected insets arrive while Compose has no listener attached; when the menus recompose, incrementAccessors re-attaches and asks for a fresh pass, but a stopped window produces no dispatch and on resume nothing has changed any more, so none ever comes. Compose keeps serving the landscape, bars-hidden values for the rest of the process. Hold one inset reader at the root for the activity's whole life, so the listeners survive the stream and every dispatch lands. It subscribes to no inset VALUE, only the holder object, so it costs one DisposableEffect and no recomposition. Verified on the reporter's device by replaying the real teardown sequence (forced landscape + immersive, composition swapped to a screen that reads no insets, torn down while stopped) and reading the layout back through uiautomator: 3 of 4 runs wrong without this, 4 of 4 correct with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:30:59 +02:00
enricobuehlerandClaude Fable 5	a86b4c18ee	feat(ci): arch gets its builder image too — the last per-run gigabyte, and sccache through makepkg ... The arch job was the one still paying full freight every run: ~1 GB of pacman across its two install steps (never cached — container layers die with the job) and cold cargo builds (arch was skipped in the sccache rollout). punktfunk-arch-ci bakes base-devel + both makepkg legs' deps + bun + node + sccache; the in-job installs become --needed no-op guards for the one push where :latest lags. Rolling-release note in the Dockerfile: packages now build against the image's snapshot, the same staleness the gamescope cache already embraces, re-snapshotted on any ci/ edit. sccache reaches makepkg by crossing the sudo boundary explicitly — env_reset strips ambient env, so the wrapper env rides the existing `sudo -u builder env ...` list. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 22:49:00 +02:00
enricobuehlerandClaude Fable 5	43a9cf741b	fix(client/android): the build resolves cargo from CARGO_HOME before guessing ~/.cargo ... The kts resolves cargo by ABSOLUTE path on purpose (a GUI Android Studio launch has no ~/.cargo/bin on PATH), but user.home is the wrong anchor in the CI image, where the shared toolchain lives at CARGO_HOME=/usr/local/cargo — gradle died starting /root/.cargo/bin/cargo. CARGO_HOME/bin is where rustup puts binaries whenever the variable is set, so it wins; the ~/.cargo fallback keeps GUI launches working. Also: android.yml's path filter learns ci/android-ci.Dockerfile — an image change must exercise its consumer instead of needing a manual rerun to prove itself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:47:07 +02:00
enricobuehlerandClaude Fable 5	12b0ce9b2d	fix(ci): the android image learns node, and msix finally builds the CLI it packs ... Two first-run discoveries. actions/checkout (and every JS action) execs `node` inside the job container — the android-ci image didn't ship it, so the job died at checkout with exit 127 (flatpak.yml documents the same lesson for fedora:43); a trailing layer keeps the fat SDK/NDK layers cache-valid. And windows-msix has been red since bf981027 required punktfunk.exe in the package without adding punktfunk-cli to the build — the same gap 90c84ef4 already closed for deb, now closed here (rpm and arch already build it; the CLI has no features, so the arm64 leg's --no-default-features changes nothing). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:36:57 +02:00
enricobuehlerandClaude Fable 5	9cda05dffb	feat(ci): android gets a baked builder image; apple gets sccache and a pinned DerivedData ... Android was the last job still downloading its world every run: ~3 GB of SDK/NDK/CMake from Google, a from-source cargo-ndk build, and one monolithic cache key where a gradle edit invalidated the cargo registry and the Rust target/ with it. punktfunk-android-ci (content-keyed, LAN registry) bakes JDK 21 + SDK + NDK + cargo-ndk + sccache; the workflow shrinks to checkout → two caches → gradle. The cargo-home cache joins the fleet-wide namespace (same lockfile, same layout — it was the same bytes under a private key), gradle gets its own key shared with android-screenshots (which stored the identical content under a second name), and target/ leaves the cache — sccache covers the three ABI builds now. Apple: sccache (self-healing ~/.local/bin install + already provisioned on the mini) covers every cargo invocation build-xcframework.sh makes across the swift job, the screenshots job and release.yml — three jobs that each recompiled the same core. screenshots.sh learns PF_SHOT_DERIVED_DATA so CI pins one stable DerivedData root instead of cold-building into two throwaway mktemp trees per run (release.yml's disease, same cure), and the Simulators get shut down after capture (the 846-leaked-sims lesson). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:20:59 +02:00
enricobuehlerandClaude Fable 5	fcdb4d147d	feat(ci): sccache everywhere a Rust job runs — one warm compile cache for the whole fleet ... Backend = the existing RustFS (storage.unom.io, S3, region home-central; LAN-pinned to home-central's address by ci-core's unbound so cache traffic never hairpins the router). Repo secrets SCCACHE_ACCESS_KEY_ID/SECRET carry a keypair scoped to the unom-ci-sccache bucket; keys embed compiler hash + target + flags, so the Ubuntu, Fedora, cross-arm64 and MSVC universes share one bucket without ever colliding. Wired: ci (rust, rust-arm64), deb (all three), rpm, bench, linux-client-screenshots, windows, windows-msix, windows-host. CARGO_INCREMENTAL=0 alongside (sccache and incremental are mutually exclusive, and incremental artifacts are what bloated the persistent Windows target dirs anyway). The binary is baked into the builder images; a per-job ensure-step (same pattern as the GTK4 packages step) keeps jobs green while the running :latest predates the bake, and ensure-windows-toolchain.ps1 self-provisions sccache.exe on the Windows runner. windows-drivers stays unwrapped (wdk-build owns its build env), arch/android/apple are follow-ups. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:04:05 +02:00
enricobuehlerandClaude Fable 5	fcdb90c39b	feat(ci): builder images move to the LAN registry, content-keyed; fan-out scoped by paths ... The five builder images now live on home-ci-core's LAN registry (192.168.1.58:5010) under content keys — a hash of the ci/ tree (+ rust-toolchain.toml for the cross image). docker.yml builds one only when its key has no manifest yet, so a push that doesn't touch ci/ costs a curl per image instead of seven WAN pushes and a set of per-SHA tags that no plain prune could ever reclaim. Releases pin builders by copying the key manifest to a vX.Y.Z tag via the registry API — no rebuild, no bytes moved. Around that: deb/rpm/arch/android/apple/decky get path filters so docs-only pushes stop lighting up the whole fleet (branch pushes only — tag runs match tags:, as flatpak/windows-msix releases have proven for months); the report-only bench job moves to bench.yml (nightly + dispatch) and stops occupying a fleet slot per push; flatpak caches its Flathub runtimes and builder state instead of re-downloading multi-GB every run; rpm's cargo registry cache gets its own key namespace instead of sharing the Ubuntu jobs'; audit caches cargo bin+registry rather than the whole toolchain dir; docker-prune.sh loses the local act-cache cap/burst-clear (the cache is central now — deleting it under disk pressure was how runner-2 ended up cold-building everything) and gains a leaked-network prune. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:04:05 +02:00
enricobuehlerandClaude Opus 5	90c84ef4bc	fix(packaging/deb): build the CLI the client .deb installs ... With the client crates compiling again, deb got as far as "Build .debs" and died on `install: No such file or directory` — a confusing way to report that punktfunk-cli was never built. Two halves of the same omission, from when the `punktfunk` CLI was added. deb.yml pre-builds `-p punktfunk-client-linux -p punktfunk-client-session` and stops there, while build-client-deb.sh installs THREE binaries. Its build-if-missing guard tested only the first two, so the pre-built pair satisfied it, the fallback build (which does list punktfunk-cli) was skipped, and the install of a binary nobody had built failed. deb.yml now builds all three, and the guard tests every binary it goes on to install rather than a subset — either change alone fixes it; both together mean the script is correct however it is called. That asymmetry is also why the arm64 leg passed throughout: it pre-builds nothing, so its guard always fired and built all three. arch was already right (`-p punktfunk-cli` in its PKGBUILD, installed at line 255) and the rpm spec ships no CLI, so this was deb-only. Verified: guard truth-tabled (skip when all three present, BUILD when the CLI is missing, BUILD when nothing is), shellcheck clean, and punktfunk-cli builds to target/release/punktfunk on a real Linux box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:02:36 +02:00
enricobuehlerandClaude Fable 5	35c61fee64	chore(client): the windows-rs pin moves a month forward, onto the SDK-metadata bindings ... The July 2026 windows-rs brings a reconciler keyed-child-order fix (#4728), widget validation (#4727), a DPI collision fix (#4751), icon elements (#4736), multi-window support (#4730) and scroll virtualization (#4710) — the re-render fixes the Windows client has been working around at the architecture level. All three pinned deps (windows-reactor, windows, windows-reactor-setup) move together so windows-core stays unified across the swap-chain hand-off, and pf-client-core moves with them. The bulk of the diff is #4689: windows/windows-sys now generate straight from the Windows SDK, so the `Win32_*` namespace features became one feature per SDK header (winuser, dxgi, d3d11, …), the PascalCase namespace modules became header-named modules, struct-returning COM methods take explicit out-params and return HRESULT, Win32 functions return their raw BOOL/HANDLE instead of Result, and flag constants are plain integers. Both crates' Win32 code is rewritten to that shape; behaviour is unchanged on every path. Riding along, all already stale before the bump: the README and the three Windows workflows stop claiming windows-reactor's build.rs needs CARGO_WORKSPACE_DIR (that build.rs no longer exists — staging moved to windows-reactor-setup via OUT_DIR); the README layout section stops describing modules that moved into the session binary long ago and gains the manual smoke checklist; the notices generator learns the SPDX for crates that ship license files without a `license` field, which turns windows-reactor-setup's UNKNOWN into MIT OR Apache-2.0; and the crate records its real rust-version (1.96) instead of inheriting the workspace's 1.82. Verified: cargo check/clippy/fmt clean on punktfunk-client-windows, pf-client-core and punktfunk-client-session; both bins build; --discover finds the LAN hosts; the GUI shell comes up (WinAppSDK bootstrap intact under the new reactor-setup). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 18:31:47 +02:00
enricobuehler	8fee1139f6	chore(client/android): adopt AGP 9.3.1 / Gradle 9.5.0, and tell CI about it ... The bump itself came from Android Studio; this makes the rest of the repo agree with it. The toolchain line at the top of the root build file still claimed AGP 9.2.0 and Gradle 9.4.1, and both Android workflows named "AGP 9.2" as the reason they pin JDK 21 — the sort of comment that is trusted precisely because it looks maintained. The Gradle caches also needed telling: they cache the DISTRIBUTION under `~/.gradle/wrapper`, keyed on a hash of `*.gradle.kts` only. This bump moved both files so the key changed anyway, but a wrapper-only bump would have restored a key that can never contain the new distribution. The wrapper properties are in the key now. Verified with the workflows' own commands on the new toolchain: `:app:testDebugUnitTest -PskipRustBuild --stacktrace --rerun-tasks` (the screenshot job, 45 tasks from cold) and `:app:assembleDebug` including the cargo-ndk native build. AGP 9.3.1 resolves no build-tools newer than the 37.0.0 both jobs install, so their sdkmanager lines still cover it.	2026-07-29 12:17:18 +02:00
enricobuehlerandClaude Opus 5	a49858f194	feat(packaging/windows): give the drivers one publisher identity, and give the trust back ... The drivers had no cryptographic identity at all. Every build minted a fresh `CN=punktfunk-driver` cert (build-pf-vdisplay.ps1, build-gamepad-drivers.ps1), and install.rs `trust_cert` adds whatever .cer it finds in the unpacked bundle to machine Root AND TrustedPublisher. So the signature vouched for nothing an attacker couldn't restage — replace the bundle, ship your own cert beside your own driver, install proceeds identically. It was ceremony to make PnP install quietly. Worse, it leaked. `trust_cert` runs once per driver (install.rs:102 and :155), so every upgrade added TWO more self-signed root CAs under the same name, and nothing ever removed them: uninstalling punktfunk left trust behind that the user had no reason to keep granting. So: both build scripts now take a stable cert via DRIVER_CERT_PFX_B64 (they already read the env var — windows-host.yml just never passed it) and fail closed on a v* tag, same rule as the host and MSIX packers. `driver uninstall` purges every `CN=punktfunk-driver` cert from both stores, and `driver install` purges before adding, so an upgrade also collects the historical pile instead of adding to it. Purge-before-add lives ONLY on the pf-vdisplay install path, not the gamepad one. The installer runs vdisplay first and gamepad second; purging in both would have the gamepad leg delete the cert the vdisplay leg just added whenever the two bundles carry different certs — which is exactly what canary's per-build fallback produces. Purging by subject rather than thumbprint is deliberate too: it is what lets one install clean up certs from builds that no longer exist anywhere, and it needs no parsing of certutil's localized output (this module exists because locale-parsed PowerShell broke the driver install on a German box). This does NOT make the driver download authenticated — a self-signed leaf is its own root, so the installer must trust it for the driver to install at all. What it buys is a fingerprint we can publish out-of-band so a substituted driver is detectable, an allowlistable publisher, continuity across releases, and no root accumulation. Attestation signing remains the real fix; documented as such. Documented the key-custody trade honestly in packaging/windows/README.md: a stable key trusted as a machine root on every install is worth stealing in a way a throwaway never was, with no revocation path. CI secret only. ⚠️ The secrets must exist before the next v* tag or the release will fail — that is the guard working, and the generation runbook is in that README. The fingerprint line there is a placeholder until the key is generated. Verified: punktfunk-host compiles clean on the windows-amd64 runner with this install.rs (exit 0, no warnings); both build scripts parse; cargo fmt clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	93902ff60e	feat(packaging/bazzite): the sysext feed is signed, and the client refuses one that isn't ... `punktfunk-sysext` checked the SHA256 of every image it downloaded, which sounds like verification but isn't: SHA256SUMS lives on the same registry as the images it describes, so anything able to replace an image could replace its checksum in the same request. The checksum only ever proved the download wasn't corrupted. Each feed now carries SHA256SUMS.asc, a detached OpenPGP signature over the manifest, and the client verifies it before believing a line of it. The key is packages@unom.io (AF245C506F4E4763) — the same one that already signs our RPMs, so boxes have one key to trust and we have one key to rotate. Its public half is baked into the script rather than fetched from the feed, because a key you fetch from the thing you're authenticating authenticates nothing; gpg (present on Bazzite) does the verifying against a throwaway keyring holding only that key, so "good signature" and "signed by us" are the same statement. Rollout: stable feeds only publish on a tag, so a `--seal` mode re-signs an existing manifest without rebuilding an image, and every rpm.yml run seals the OTHER channel of its Fedora major too. Canary pushes are frequent, so all live feeds seal within a day of this landing and a key rotation propagates without republishing anything. Until a feed is sealed the client refuses it and says so, naming PUNKTFUNK_SYSEXT_ALLOW_UNSIGNED=1 as the informed way through. Two things testing changed. The baked-key fingerprint check compared against an empty string — the armor block is a single-quoted shell literal, so the extracted range carried `FEED_KEY='` on its first line and gpg saw no armor at all; every publish would have "mismatched" and, on a tag, failed the release. And `status` captured fetch_manifest's stderr but only printed it on failure, swallowing the ALLOW_UNSIGNED warning precisely when someone was running unverified. Verified end to end on Bazzite 44 against a file:// feed with a throwaway key: unsigned feed refused; ALLOW_UNSIGNED=1 proceeds and says so; wrong signer rejected; tampered manifest rejected; good signature accepted; `update` exits 1 before touching anything on a bad feed. Publisher side: signs when the baked key matches, refuses on mismatch, refuses with no key, and its signature round-trips through the real client. shellcheck clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	7b053a4a39	fix(packaging/rpm): a release must not publish unsigned RPMs into a gpgcheck=1 repo ... Signing was already live and the docs were half right about it. `RPM_GPG_PRIVATE_KEY` is an ORG-level secret on unom, so it is invisible in this repo's Actions secrets — which reads exactly like "never set up", and both the rpm.yml step name and sign-rpms.sh's header still said "dormant". Checked it on the wire instead: a published punktfunk-web RPM carries an OpenPGP V4 EdDSA header signature from af245c506f4e4763, the same key committed at packaging/rpm/RPM-GPG-KEY-punktfunk. The real gap was the failure mode. README.md hands users a repo file with gpgcheck=1, but sign-rpms.sh exits 0 when the key is missing — so an org secret that got rotated, renamed, or not inherited would publish an unsigned release into a repo that rejects unsigned packages, and every user's `dnf upgrade` would break with us none the wiser. On refs/tags/v* that is now a build failure. Other builds still fall through unsigned so forks and local builds keep working. Docs corrected to match: the org-level location (with a wire-level check that doesn't depend on where the secret lives), the fail-closed rule, and a note that `rpmkeys --checksig` reporting NOKEY still means signed. Guard tested locally: exit 1 on refs/tags/v0.21.0, exit 0 on refs/heads/main and on an unset ref. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	5db93c1156	fix(packaging/windows): a release must not sign itself with a throwaway cert ... Both pack scripts fell back to a fresh `New-SelfSignedCertificate` whenever MSIX_CERT_PFX_B64 was absent, and said nothing about it beyond one Write-Host. That fallback is right for canary and dev builds. On a tag it is not: an ephemeral cert is regenerated per build, so nobody can pin it, and a release signed with one is indistinguishable from a release signed by whoever else got to the artifact. A secret that got renamed, rotated away, or simply wasn't inherited by a new workflow would have downgraded a real release silently and shipped it. pack-msix.ps1 and pack-host-installer.ps1 now resolve -RequireSignedCert (default 'auto' = true iff GITHUB_REF is refs/tags/v*) and throw instead of falling back; pack-host-installer.ps1 also refuses -NoSign on the same condition. Reading GITHUB_REF inside the scripts rather than taking a workflow flag means a future packaging workflow inherits the guard instead of having to remember it. No effect on today's releases: MSIX_CERT_PFX_B64 / MSIX_CERT_PASSWORD are both set as repo secrets, so the supplied-cert branch is the one tag builds take. This only closes the trapdoor underneath it. Verified on the windows-amd64 runner: both files parse, and the guard resolves true for refs/tags/v0.21.0, false for refs/heads/main and for an unset ref, with 'true'/'false' overriding as intended. Not touched: the pf-vdisplay / gamepad driver builds use the same pattern with DRIVER_CERT_PFX_B64, which has no secret behind it — those need attestation signing (a Partner Center action), and a guard there would just fail every tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Fable 5	7fb2ad266e	ci: a newer push supersedes the queued run — concurrency groups everywhere ... Every push-triggered workflow now declares concurrency: { group: workflow+ref, cancel-in-progress: true } A busy push cadence on main was stacking ~10 queued runs per commit — the fleet was 110 runs behind tonight — while only the newest commit's canary matters. Now each new push cancels the superseded queued/running run of the same workflow. Release tags are unaffected: every tag is its own ref, so tag runs never cancel each other. Gitea honors this for push triggers (PR triggers don't cancel yet: gitea#35933). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 01:07:00 +02:00
enricobuehlerandClaude Fable 5	cd67bd5d30	ci(audit): scope decky to shipped deps; make docs-site non-blocking deterministically ... First real-runner dispatch (run 13627) surfaced two calibration issues: * pnpm audit flagged 6 high advisories — all in decky's devDependencies (the rollup build toolchain), which never ship: the plugin bundle carries prod deps only. --prod scopes the gate to what users get, matching the locally-validated state (clean). * docs-site relied on job-level continue-on-error, which act_runner does not reliably honor — replaced with a step-level '||' warning so the known advisories can never take the run red while staying visible in the log. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 00:59:29 +02:00
enricobuehlerandClaude Fable 5	5d018eea7c	ci: the supply chain accounts for itself — per-release SBOM, full-tree audits, a real license gate ... CRA Annex I Part II groundwork (see punktfunk-planning design/cra-readiness.md, Phase 1): * sbom.yml + scripts/ci/gen-sbom.sh: every vX.Y.Z release gets a CycloneDX SBOM attached — syft over both Cargo.locks, all Bun/pnpm trees and the Swift Package.resolved (2,667 components), merged with compliance/sbom/manual-components.cdx.json for what no lockfile records (pyrowave/Granite/volk/Vulkan-Headers pins, libvpl, FFmpeg, SDL3, VB-CABLE, punktfunk-gamescope). * audit.yml: bun audit now covers sdk + plugin-kit (not just web), decky's pnpm tree is scanned, and docs-site runs non-blocking until its known CMS-chain advisories are cleared. All shipping trees verified green today. * license-gate: about.toml's allowlist claim is finally enforced — cargo-about 0.9.1 with --fail over BOTH workspaces. The old [crate.clarify] license-only syntax fails to deserialize under 0.9; migrated ring to a per-crate accepted extension and dropped the stale aws-lc-sys entry (workspace is ring-only). Both gates validated green locally. * drivers/Cargo.lock: sync the pf-dualsense→pf-gamepad rename — the crate rename updated the manifest but the Windows-only lockfile was never regenerated; cargo-about's metadata pass caught it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 00:59:29 +02:00
enricobuehler	735cd99e8f	fix(ci/windows): the web install was the one CI site still running lifecycle scripts ... The Windows host job died in "Build + smoke-boot web console (bun)": $ bun2nix -o bun.nix error: bun is not installed in %PATH% error: postinstall script from "punktfunk-web" exited with 255 bun install failed (255) `web`'s `postinstall` is `bun2nix -o bun.nix` — Nix codegen that shells out to `bun` on PATH. This job runs a fetched PORTABLE bun by absolute path (`$env:BUN_EXE`), so PATH has none and the script aborted the install, taking the installer, the driver bundle and the publish steps with it. Every other web install in CI already passes `--ignore-scripts` — ci.yml (twice), web-screenshots.yml, sdk-publish.yml, plugin-kit-publish.yml, and the SDK install 25 lines further down THIS SAME FILE. This one line was the lone exception: the same N-1-of-N seam asymmetry the pf-vdisplay sweep keeps turning up. Nothing here needs those scripts — `bun run build` re-runs its own `prebuild` codegen, and ci.yml proves the build works after an `--ignore-scripts` install — and `bun.nix` is a Nix artifact this job neither consumes nor commits. deb.yml still regenerates it (bun on PATH there), so the self-regenerating contract is unchanged. ⚠️ Honest about the evidence: I could NOT reproduce the failure on .173. Invoking the portable bun by absolute path with `where bun` empty, the postinstall SUCCEEDED there — bun made itself resolvable to its own lifecycle script, which the SYSTEM-account runner evidently does not. So this is not a reproduced-then-fixed A/B. It is justified instead by construction: `--ignore-scripts` removes the dependency on bun2nix (and on how bun2nix locates bun) altogether, and aligns the step with every sibling. If the job goes green, that is the confirmation. ⚠️ Related trap for whoever deploys the console by hand: rebuilding `web/.output` does NOT take effect until the `PunktfunkWeb` SCHEDULED TASK is restarted — restarting the host service does not touch it. A server left running from before a rebuild serves HTML referencing the OLD asset hashes while disk holds the new ones, so every asset 500s while `/login` still returns 200. Hit on .173 today; `Stop-ScheduledTask PunktfunkWeb; Start-ScheduledTask PunktfunkWeb` fixes it.	2026-07-29 00:18:27 +02:00
enricobuehlerandClaude Opus 5	6782aa0054	fix(vdisplay): stop the suite reporting ok for tests that never ran, and let clippy see the KWin backends ... Three coverage holes, all of the same shape — a gate that looks green because nothing is behind it. The Windows half (~3,400 lines) had no executed tests. Its only two `#[test]`s opened with `if env::var("PUNKTFUNK_PF_VDISPLAY_LIVE").is_err() { return; }`, so without the hardware they passed without running, and no CI job compiled the crate's test targets at all — `-p punktfunk-host` builds pf-vdisplay as a dependency, which never reaches a `#[cfg(test)]` module. Both live tests are `#[ignore]`d now (an unrun hardware test should say `ignored`), and windows-host.yml gains the `--all-targets` lint plus a real test step. The link question that keeps the host and pf-encode on clippy-only does not apply: pf-encode is `default = []` and nothing here turns on nvenc/amf-qsv/qsv. Settled on the runner to the same standard as pf-capture's step — 46 passed, 2 ignored. `#![allow(clippy::all, ...)]` at the top of kwin.rs and kwin_output_mgmt.rs was meant for wayland-scanner output, but the generated modules already carry their own copy of that attribute — so the file-level one was only ever silencing 2,366 lines of hand-written backend, with `clippy::correctness` (deny-by-default) among the casualties. Dropping it found a dead match arm in the `kde_output_configuration_v2` dispatch; that one is now exhaustive on purpose, so a re-vendored XML that adds an event fails the build instead of dropping it silently. (The sibling `_ => {}` in the DeviceMode dispatch is NOT dead — `ModeEvent::Removed` really does reach it and get swallowed, which is a separate defect.) `dead_code` is now enforced on Linux, where ~10k of the ~17k lines live, instead of allowed crate-wide behind a rationale that had stopped being true. It turned up no genuinely dead code: four items, every one live from tests or another platform, now annotated with which. One deserved the comment most — `Entry::keepalive` is "never read" because it is an RAII guard whose `Drop` releases the compositor output, so deleting it as unused would release every pooled display the moment it was created. Two tests were not testing what they claimed. `another_uids_socket_is_ignored` asserted the sway-socket ownership guard but never reached it — `find_sway_socket` filters on the `sway-ipc.<uid>.` filename prefix first, so the foreign-uid file was rejected by name and the assertion held even with `md.uid() != uid` deleted. It is renamed to what it does cover, and the real leg is a new `#[ignore]`d root test that chowns a correctly-named socket (querying with a non-matching pid, or the exact-path shortcut would return before the guard and make it vacuous all over again). And proc.rs's tests were ungated while the module is compiled everywhere, so they would have gone red on Windows the first time anyone ran them: `#[cfg(all(test, unix))]` now, with a `cmd /c` twin that does run there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:11 +02:00
enricobuehlerandClaude Opus 5	2f39e15e88	fix(ci): the shader drift gate never ran — dash has no process substitution ... `diff <(spirv-dis …) <(spirv-dis …)` is bash syntax, and Gitea's runner executes a step's `run:` under `sh -e`. dash rejected the script at PARSE time, so the gate compared nothing — and, being step 2 of the `rust` job, it took Format, Clippy, Build, Test, the feature-gated encode backends, the C ABI harness and the committed-header check down with it. Every one of those has been skipped on the 35 commits between the gate landing (143a707f) and this one. A gate that cannot run looks exactly like a gate that passes, which is the precise failure mode it was written to prevent. Disassemble to files instead. That is dash-clean without depending on whether act_runner honours a `shell: bash` override, which is the other way to fix it and the more fragile one. Verified in CI's own container (ubuntu:resolute, glslang 16.2.0, spirv-tools 2026.1) by running the step body extracted from this YAML under `sh -e`: it passes on the current tree, and — the half worth checking — it still FAILS on a deliberately corrupted blob, so it is not passing vacuously. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 18:28:29 +02:00
enricobuehlerandClaude Opus 5	c801465469	fix(packaging): every channel that ships punktfunk-gamescope now builds it ... The docs already told users where to get it — the Bazzite sysext, an Arch package, a NixOS option — and none of the three were true. `rpm.yml` built the sysext without ever passing `--gamescope`, `arch.yml` did not know the PKGBUILD existed, and the nix derivation had never been evaluated once. Evaluating it found its central assumption wrong: `gamescope.unwrapped` does not exist on current nixpkgs, where `gamescope` IS the buildable derivation, so the override threw on every build. It now prefers `.unwrapped` where a future nixpkgs wraps it and checks the RESULT is patchable — `overrideAttrs` on a symlinkJoin succeeds and does nothing, which would install an UNPATCHED gamescope under a name the host reads as a promise of HDR. Both it and the PKGBUILD had also drifted to a stale patch list: two patches named where three exist, one of them under the level-1 filename retired when the cursor patch landed. Both read the patch directory now, so the list cannot go stale again. The PKGBUILD additionally delegates the whole build to `build-punktfunk-gamescope.sh` rather than re-deriving the meson invocation — its copy had already lost `force_fallback_for=wlroots`, and unlike Fedora 43, Arch ships wlroots, so that package would have linked it shared and shipped a binary that starts only on machines carrying the dev library. It asserts its own pinned rev matches the script's, the one thing makepkg needs statically. Both CI builds are cached on `packaging/gamescope/**`, which is the only reason this is affordable: that tree depends on nothing else in the repo, so a normal push restores a binary instead of spending ten minutes on someone else's C++. And both are best-effort. punktfunk works without this binary — SDR on the gamescope backend, which is what every release before this one did — so a hiccup building gamescope must not cost the packages those workflows exist to publish. A failure warns and is never cached, so the next run retries. `rpm.yml` also installs Fedora's own gamescope for its runtime libraries: the sysext verifies our binary by executing `--version`, and on a cache hit nothing else in the job would have pulled libavif/luajit/seatd in. Verified by evaluating and patch-phase-building the nix derivation against nixos-unstable: all three patches apply to nixpkgs' already-patched 3.16.25 tree, and the banner stamps +pfhdr2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 18:03:30 +02:00
enricobuehler	347c106498	fix(packaging/tray): the .deb must build the tray in its own cargo invocation ... punktfunk-tray panicked at every launch on Debian/Ubuntu: zbus-5.16.0/src/abstractions/executor.rs:190 there is no reactor running, must be called from the context of a Tokio 1.x runtime Not a code bug — cargo feature unification. zbus picks its executor from its own feature flags; the host's ashpd enables zbus/tokio while the tray runs ksni's async-io executor with no tokio runtime by design. Features are additive across everything built in ONE invocation, and deb.yml built `-p punktfunk-host -p punktfunk-tray` together, handing the tray a tokio-flavoured zbus with no runtime anywhere near it. The invariant is already established and explained inline in the RPM spec, the Arch PKGBUILD and the Nix packages.nix — all three build the tray alone, and their comments even claim "(Same split the .deb does.)" The .deb did not, in two places at once: the workflow co-built it, and build-deb.sh's own correct standalone build was skipped by an `if [ ! -x "$TRAY_BIN" ]` guard, so it packaged the poisoned artifact. That is also why only Debian/Ubuntu users saw it. Drops the tray from the workflow's host build and makes build-deb.sh's tray build unconditional — cargo no-ops when the artifact is already async-io-resolved and rebuilds it when it is not, so a stale co-built binary can no longer be shipped. Corrects the Nix README note that had recorded deb/rpm/arch as sharing a "latent" crash, and its nix develop recipe, which co-built all four. Verified on a Linux box: co-built reproduces the panic exactly; built alone, the tray reaches the session bus and exits with the intended "no StatusNotifier tray available". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit f91983a84c56464bd2c18d537963cb7fb3a6e059)	2026-07-28 17:01:59 +02:00
enricobuehlerandClaude Opus 5	560e663aef	fix(drivers): the pad channel asks the devnode who to trust, not the mailbox ... A LocalService principal could take over a virtual pad's shared input section and forge HID input into the interactive desktop. The host duplicates each pad's unnamed DATA section into the driver's WUDFHost, and through gamepad proto v2 it learned that process from `driver_pid` in the named bootstrap mailbox. That mailbox has to be LocalService-writable — that is what the driver's own WUDFHost runs as — and the delivery gate, verify_is_wudfhost, only checks that the target's IMAGE is %SystemRoot%\System32\WUDFHost.exe. That image is world-executable. So anything running as LocalService — notably the deliberately de-privileged plugin runner — could spawn its own WUDFHost (CREATE_SUSPENDED parks it indefinitely with the right image path), publish that pid, and be handed SECTION_MAP_READ|WRITE on a live section. For pf-mouse that section drives a real absolute pointer, so it was desktop control; for the pads it was forged gamepad input plus a read of the remote user's controller state. The module docs claimed mailbox tampering "yields at worst a gamepad DoS, never a read or an injection". That was wrong, and the reasoning behind it — that a LocalService token is DACL-denied OpenProcess on a UMDF WUDFHost — only covers the REAL host, not one the attacker spawned itself. The pid now comes from the device stack (ChannelProof, proto 2 -> 3). The host asks the devnode it SwDeviceCreate'd who is serving it, looked up by the instance id PnP handed back, so a planted look-alike devnode is not a candidate and the kernel — not anything the attacker supplies — does the routing. Only the driver PnP actually bound to that device can answer. `driver_pid` survives as a liveness hint; a tamperer can still deny a pad, which squatting the name always allowed, but can no longer choose the recipient. Two rules keep the state machine honest around it: a delivery stands until its target process EXITS (judged on a retained SYNCHRONIZE handle, so a recycled pid cannot fake it, and UMDF's restart-after-driver-crash still re-attaches), and a pad with no SwDeviceCreate devnode refuses to deliver rather than fall back — unless an operator sets PUNKTFUNK_PAD_CHANNEL_TRUST_MAILBOX, which says so loudly. Three transports, because Windows carries different things to different driver shapes, and the obvious two did not survive contact with hidclass. Measured on .173 (Win11 26200): HidD_GetIndexedString is NOT forwarded to a UMDF HID minidriver at all — it failed for every index including ones the driver demonstrably serves through the named wrappers; and a private device interface registers and enumerates but cannot be OPENED (ERROR_GEN_FAILURE), because hidclass owns IRP_MJ_CREATE on a devnode it is the FDO for. That is exactly why pf-xusb was never affected: it is not a HID minidriver, so nothing sits above it. What works: * pf-xusb — a private IOCTL on its own GUID_DEVINTERFACE_XUSB. * pf-mouse — the HID serial string. Verified: PFCP:3:0:7296, and 7296 was a genuine service-spawned WUDFHost.exe. Safe here alone: nothing reads the virtual mouse's serial, whereas a pad's is SDL/Steam dedup material. * pf-gamepad — a HID feature report, and it cost NO report-descriptor change. The captured descriptors already declare far more Feature ids than the driver ever served: 0x85 is declared on DualSense, DualShock 4 and Edge alike and used to fail with STATUS_INVALID_PARAMETER, so hidclass lets it through and nothing can have depended on the old failure. The Deck's one feature report is unnumbered and Steam drives it command->response, so its proof rides that existing contract via a private two-byte command. Verified: feature 0x85 returned magic "PFCP", proto 3, pad_index 0, wudf_pid 18456 — and 18456 was a WUDFHost — with the product string still 'DualSense Wireless Controller'. Also renamed pf-dualsense -> pf-gamepad. One driver has always served four identities, so the old name read as if the other three lived elsewhere. ONLY the package identity moved (crate, INF/CAT/DLL, UMDF service, build script, CI lines, log file, env var). The four HARDWARE IDS are deliberately unchanged — they bind every devnode the host creates and every installed system — as are the Global\pfds-boot-<i> mailbox and PAD_MAGIC, which are wire contract. `driver install --gamepad` now retires the pre-rename store package first, matched on pf_dualsense.dll because that string appears only in the OLD inf; matching on the hardware ids would delete what we are about to install. On .173 that separated 14 stale packages from the 1 new one with 0 ambiguous, and the renamed package binds the old hwid (devgen root\pf_dualsense -> oem143.inf = pf_gamepad.inf). The repo's own pre-commit/pre-push rustfmt hooks named the old crate, so they caught the rename before the commit did — they now check pf-gamepad, and pf-mouse alongside it, which they had been missing relative to the CI line. Host and drivers MUST ship together: v2<->v3 fails closed in both directions by design, with the existing "update host + drivers together" diagnostic. The rename moved files that also carry the security change, so splitting this into two commits would mean reconstructing an intermediate state that was never gated. It is one commit on purpose. Gated on the windows-amd64 runner with cargo clean first (the box's clock lags, so stale artifacts would read as a vacuous green): clippy -D warnings clean for pf-inject, pf-capture and pf-driver-proto, drivers workspace build + the CI clippy line clean, cargo check --release -p punktfunk-host clean, 19 + 58 tests green. Also fixes pf-mouse still writing its debug log to world-writable C:\Users\Public, which the 2026-07-17 review moved for the other three drivers and missed here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 16:54:40 +02:00
enricobuehlerandClaude Fable 5	143a707f76	fix(zerocopy): the mechanical sweep batch — truthful fence waits, forgiving env flags, no leaked planes ... From the pf-zerocopy review sweep (design/pf-zerocopy-sweep-handoff.md), the compile-verifiable batch: - dmabuf_fence: the blocking poll's result was discarded — EINTR silently skipped the wait (reopening the stale-frame race a SIGCHLD away) and a timeout reported as waited. Now EINTR retries with the remaining budget and the caller gets Signaled/TimedOut/NoFence, so the one diagnostic operators have about implicit fencing stops lying. (C2) - env flags: PUNKTFUNK_ZEROCOPY=TRUE meant *off* — values are case-folded now, and an unrecognised spelling falls back to the flag's default with a one-shot warning instead of silently inverting the operator's intent. (C3) - cuda: alloc_pitched_nv12 leaked the Y plane when the UV allocation failed (per-frame under VRAM pressure — the worst possible time to leak); a failed async-copy enqueue now drains the stream before returning, so a recycled pool buffer can't race an orphaned in-flight copy. (C4, C5) - worker: --fd is validated (>= 3, fstat + S_ISSOCK) before OwnedFd adoption — 'zerocopy-worker --fd -1' was constructing OwnedFd's niche value. (V1) - docs: all 15 rustdoc warnings fixed, including the link to the renamed note_raw_dmabuf_negotiation_failed. (D1) - CI: a SPIR-V drift gate — the committed .spv blobs are include_bytes!'d and rebuilt by hand; the gate diffs disassembly (filtering only the shaderc/glslang generator difference) so a forgotten rebuild fails CI instead of shipping the old kernel. Both blobs verified in sync. (S1) - tests: bt709_limited pinned to external BT.709 anchors (it is the sole oracle for the GPU colour self-test); blend_geometry gets its first tests — empty rect, CURSOR_MAX clamp, per-format group counts, and negative-ox floor alignment. (T2, T3) Verified on .25: clippy -D warnings clean, 27/27 tests, cargo doc 0 warnings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-28 12:40:37 +02:00
enricobuehlerandClaude Sonnet 5	74179c4c2e	fix(ci/winget): envs: must live under with:, not as a step sibling ... 24d2f97e added envs: GITHUB_REF_NAME to fix "Verify the served catalogue" failing on every tag with `GITHUB_REF_NAME: unbound variable` — but placed it as a sibling of with:/env: on the step, which is not part of the step schema and is silently ignored by Gitea's runner. appleboy/ssh-action never received it as an input, so the step kept failing identically on v0.20.1's first tag run. docker.yml and deploy-services.yml already forward REGISTRY_TOKEN this way correctly: envs: nested inside with:. Moved to match. Confirmed by parsing the workflow and checking envs lands in the step's with: dict, not as a bare step key. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 00:01:45 +02:00
enricobuehler	24d2f97eae	fix(ci/winget): forward GITHUB_REF_NAME into the remote shell ... The catalogue-verify step has failed on every stable tag since it landed, v0.20.0 included: `bash: line 6: GITHUB_REF_NAME: unbound variable`, twice, then exit 1. `env:` populates the RUNNER's environment. appleboy/ssh-action executes its `script` on the REMOTE host over SSH, which inherits none of it — the action has a separate `envs:` input naming the variables to forward. Without it the `set -u` at the top of the script turns the first expansion into a fatal, and the two `curl`s either side report only the collateral: `Failed writing body` is curl losing its pipe when the `grep` it was feeding died. The failure is maximally misleading, because everything it guards ALREADY WORKED: the catalogue is built, tested and shipped in the preceding steps, and only the proof-of-serving fails. Confirmed by hand against the live source during the v0.20.0 release — it serves unom.PunktfunkHost 0.20.0 correctly. The pattern was already right everywhere else: both "Pull and start docs" steps (deploy-services.yml, docker.yml) pair `env:` with `envs:`. A sweep of the other three ssh-action steps found no further instance — the remaining two pass no variables at all.	2026-07-27 07:31:55 +02:00
enricobuehler	0c261de636	ci(plugin-kit): quote the step name that contains a colon ... `- name: Repair the file: dependency (…)` is not valid YAML — the unquoted `file: ` reads as a second mapping key — so the workflow has been unparseable since it was added, which is why re-pushing the tag never triggered a run and a manual dispatch 500'd. I had put that down to a Gitea tag quirk; it was this. The failure is invisible from the repo side: nothing validates workflow YAML on push, and an unparseable workflow simply never runs.	2026-07-26 20:45:58 +02:00
enricobuehlerandClaude Opus 5	1839d7566b	feat(packaging/winget): install the Windows host with winget, from our own source ... `winget install unom.PunktfunkHost` after adding the source, and `winget upgrade` from then on. Windows had no update path at all before this — no self-update, no package manager — so keeping a host current meant noticing a release and re-running an installer by hand. Ships the manifest trio in winget-pkgs' own format (so submitting upstream later is a copy, not a rewrite) plus a release-time generator that substitutes only version, URL, hash and release-notes link. Everything reviewable — the silent switches, the agreements, the installation notes — stays in the checked-in templates rather than buried in a generator. Silent installs deliberately take the SAME task defaults the wizard shows: a per-channel default is a support trap. The disclosures the wizard puts on screen travel as manifest Agreements instead, shown before install and requiring acceptance — VB-Audio's bundling grant wants the user to see VB-CABLE's origin and donationware status, and a silent install shows them nothing otherwise. The console password can only be pointed at, never printed: it is generated per install and the notes are fixed at publish time. Self-hosted rather than the community repo, which gates on Defender/SmartScreen validation the self-signed installer cert would not clear today. The source is three endpoints — /information, /manifestSearch, /packageManifests/{id}. The reference implementation's other twenty are its admin API for mutating a CosmosDB; a catalogue generated at release time has nothing to mutate. It runs on unom-1 as a stock bun image with the two .mjs files bind-mounted, the same shape as the flatpak server, so there is no image to build or pull. The catalogue is derived from the RELEASES rather than local files: winget resolves --version and upgrade against the version list, so a source that only knew the newest release could neither pin an older one nor show an upgrade path from it. That also leaves no state to drift — re-running the build reproduces it exactly. NormalizedPackageNameAndPublisher is declared unsupported on purpose. winget derives it client-side with its own normalization, and a near-miss silently mis-correlates an installed host; ProductCode is exact and Inno gives us one. 28 checks drive the handler directly, and CI gates on them before anything reaches the box — a wrong response shape does not fail loudly, it just makes winget report "no package found". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 19:09:13 +02:00
enricobuehler	d8b7a86366	ci(plugin-kit): repair the file: dependency bun 1.3 links to itself ... The publish workflow has been failing at Typecheck with "cannot find module '@punktfunk/host'" — every import of the SDK, in a job whose previous step built that very SDK successfully. bun 1.3 installs a `file:` dependency by copying its DIRECTORIES but symlinking each top-level FILE to itself: `node_modules/@punktfunk/host/package.json -> package.json`, a dangling self-reference. So `dist/index.d.ts` arrives intact while the manifest that points at it does not, and resolution dies at the first step it takes. The types were never missing; nothing could find the front door. Replacing that tree with a real copy is the whole fix, and the step no-ops itself the moment bun links `file:` deps correctly again. Not a regression from anything in the kit — it has been broken since bun updated, and went unnoticed because nothing has been published since 0.1.4. Verified from a clean node_modules: install → repair → typecheck → 20 tests → build, all green.	2026-07-26 18:58:49 +02:00
enricobuehlerandClaude Opus 5	0d69ebf60b	ci(windows): run pf-capture's tests instead of only type-checking them ... Phase 0 of the sweep added `clippy -p pf-capture --all-targets` to this workflow, which type-checks all 19 Windows `#[test]`s and executes none of them. They were decorative. The workflow's own comment explains why pf-encode's tests cannot run here — nvenc link-imports NvEncodeAPICreateInstance, which resolves only against the driver's import lib. That reasoning does not extend to pf-capture: it has no encoder dependency at all (`cargo tree -p pf-capture` lists no nvidia/ffmpeg/libvpl/pyrowave), so its test binary links against nothing the runner lacks. Confirmed empirically rather than reasoned: `cargo test --release -p pf-capture` was run on a Windows dev box against a workspace checkout — it linked, executed and passed, building in ~51 s off an existing release target dir. --release keeps it in the one C:\t\release tree, so it does not trip the C1069 disk exhaustion a second debug dep tree causes. 18 of the 19 run here (StallWatch + ring-generation masking, the cursor shape→wire truth table, and `f32_to_f16`'s rounding-carry/saturation edges); all are pure — no Win32, no device, no desktop. The 19th, `hdr_p010_selftest_intel_1080_live`, is `#[ignore]`d because it needs a real Intel adapter. This is Windows-only code no other job can execute, so it was the cheapest coverage still on the table. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 12:07:22 +02:00
enricobuehlerandClaude Opus 5	6a2a153c0b	chore(pf-capture): make the crate verifiable — Windows CI lint + two denies (sweep Phase 0) ... Gate for the rest of design/pf-capture-sweep.md: today half this crate is compiled by no CI job at all, so the Windows-side findings can't even be type-checked. 0.1 (X1) — windows-host.yml lints `-p pf-capture --all-targets`. The host lint above it builds pf-capture only as a DEPENDENCY, so its `#[cfg(test)]` modules were never compiled anywhere: the 5 StallWatch tests, the DXGI HDR self-tests and the cursor-conversion tables were dead code in CI. The workflow's own comment already diagnosed this blind spot and fixed it for pf-encode; pf-capture never got the same treatment. No features on this crate, so no feature juggling and no extra dep tree. 0.2 (X2) — `#![deny(unsafe_op_in_unsafe_fn)]` beside the existing `deny(clippy::undocumented_unsafe_blocks)`. The crate declares "every unsafe block carries a SAFETY proof; enforce it" in ten file headers, but in edition 2021 that lint has nothing to fire on inside an `unsafe fn` — so the hardest FFI in the crate was exempt from its own program: the ring/slot construction, the fence signal, the blend scratch, and every D3D converter ctor/convert. 119 operations across 16 functions now carry a proof. `shared_object_sa` loses its `unsafe` marker instead (it states no precondition — only its RESULT is a raw pointer, which is the caller's business). 0.3 (X4) — drop the crate-wide `#![allow(dead_code)]`. Verified: zero warnings on either target without it, so it was hiding nothing the lint can see (W16's dead items are `pub`/written-once, so they need Phase 1.7's deletion instead). No behaviour change: only lint attributes, `unsafe { }` scoping and comments. Linux `cargo test -p pf-capture` 6/6, clippy --all-targets clean on both targets (Windows verified by cross-checking x86_64-pc-windows-msvc locally). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:18:48 +02:00
enricobuehlerandClaude Opus 5	cac82d13df	ci: check the client for aarch64 on every push ... Adds a `rust-arm64` job: clippy -D warnings for the client crates at --target aarch64-unknown-linux-gnu, plus a --no-default-features session build so the minimal embedded configuration keeps compiling in its own right rather than only as a subset of the default one. Runs in the cross image on the ordinary amd64 runner; client crates are listed explicitly because --workspace would drag in the x86-only host encode stack. This is a regression guard, not an artifact leg (deb.yml ships those). c_char signedness cuts both ways and neither direction is visible from an x86-only CI: hardcoding i8 fails to COMPILE on ARM, while casting to u8 fails the LINT on ARM. Two such defects were already found this way. Also documents the arm64 client .deb recipe in packaging/debian/README.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	000f8b85b0	build(ci): cross-compile and publish an aarch64 Linux client ... Adds punktfunk-rust-ci-arm64cross (the rust-ci toolchain + an Ubuntu ports arm64 multiarch sysroot) and a deb.yml job that cross-builds the client package on the ordinary amd64 runner — no arm64 runner in the fleet and none needed. Client only: the Linux host encodes with NVENC/QSV/AMF, all x86. The apt registry keys pool entries by the .deb's own arch, so an arm64 box picks the package up with no client-side configuration. Three things this had to get right, each of which cost a failed build: * rustup target add must run against the toolchain rust-toolchain.toml PINS, not the image's default `stable` — otherwise the pinned toolchain has no aarch64 std and the build dies ~230 crates in on "can't find crate for core". Copying the pin file in also pre-downloads the toolchain every CI job currently re-fetches on first use. * ffmpeg-sys-next compiles a probe it intends to RUN, so it forces .target(HOST) while still passing the TARGET's include paths; the arm64 dir then shadows the host's own libc headers and the x86 compiler dies in bits/math-vector.h on NEON/SVE types. Prepending the host dir does NOT help — GCC drops a -I that duplicates a system directory, keeping its original later position — so ci/pf-host-cc strips target include dirs from host compiles instead. * the job hard-fails on a non-AArch64 session binary, rather than shipping an amd64 payload under an arm64 package name. skia needs no special handling: the aarch64-linux-gnu textlayout+vulkan prebuilt resolves, so arm64 ships the FULL client, OSD included — unlike Windows ARM64, which still builds --no-default-features. The cross image builds in its own docker.yml job (needs: build-push) since it is FROM punktfunk-rust-ci:latest and must not race the entry that publishes that base. rpm/Arch/Flatpak stay x86_64 for now — their builders have no arm64 sysroot, which is its own piece of work. Plan: punktfunk-planning design/embedded-arm64-client.md Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	16fa43da40	ci(encode): lint and test the feature-gated encode backends ... pf-encode's GPU backends are off by default, so almost none of them were under `-D warnings`: - ci.yml lints/tests with default features, which do cover VAAPI, libav-NVENC and — via punktfunk-host's `default = ["pyrowave"]` — the PyroWave backends, but not `nvenc` or `vulkan-encode`. - deb.yml builds those two, but with `cargo build`, where warnings are not errors. That left enc/linux/nvenc_cuda.rs, enc/linux/vulkan_video.rs and the vendored vk_av1_encode / vk_valve_rgb bindings — ~8,150 lines carrying ~70 `unsafe` blocks — never linted anywhere, so the crate's own `#![deny(clippy::undocumented_unsafe_blocks)]`, its stated unsafe-proof gate, was never actually enforced on them. Linux gains a clippy+test leg at the SHIPPED feature set: deb.yml builds `punktfunk-host/nvenc,punktfunk-host/vulkan-encode` WITHOUT `--no-default-features`, so the .deb carries pyrowave too and that combination is what deserves the lint. GPU-free — the hardware tests are `#[ignore]`d and NVENC/CUDA dlopen their entry points, so the test binary links with no driver. Windows gains a separate `-p pf-encode --all-targets` lint. The existing lint is `-p punktfunk-host`, which never builds pf-encode's test targets — the blind spot that let the Linux twin's tests rot. It must be clippy rather than `cargo test`: on MSVC nvidia-video-codec-sdk link-imports NvEncodeAPICreateInstance / NvEncodeAPIGetMaxSupportedVersion, so a test binary cannot link without the driver's import lib. clippy type-checks without linking; ci.yml runs the tests. `--all-targets` is load-bearing, not decoration: without it the feature-gated `#[cfg(test)]` modules are never compiled at all. Also widens windows-host.yml's paths filter, which listed `crates/pf-encode/**` but none of the crates it compiles against (pf-frame, pf-gpu, pf-zerocopy, pf-host-config, pf-capture, ...), so a change reaching the Windows host through one of those triggered no Windows build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 4.8	00c8c12a0f	feat(ci/apple): export the iOS .ipa to the release + run artifacts ... The iOS leg archives with development signing and re-signs for App Store distribution at export time, but the existing export uses destination=upload (straight to TestFlight) and leaves no .ipa on disk. Add an export step that re-exports the SAME archive with destination=export to produce an App Store distribution-signed .ipa, then: * attach it as the `punktfunk-ios-ipa` run artifact on every build (upload-artifact@v3, since Gitea's backend rejects @v4), and * attach it to the unified Gitea release on vX.Y.Z tags (alongside the DMG), via the shared ensure_release/upsert_asset helpers. Same gate as the archive; warn+skip (never fails the best-effort iOS leg) if the archive is absent. Note: an App Store-signed .ipa installs only via TestFlight/App Store, not by direct sideload — it is a release/archival artifact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 18:18:45 +02:00
enricobuehlerandClaude Opus 4.8	15d09a8c10	feat(ci/release): author release notes in-repo + announce stable releases to Discord ... Release notes now live in the repo at docs/releases/vX.Y.Z.md, authored during the version bump (before the tag). ensure_release (gitea-release.sh + .ps1 twin) seeds the Gitea release body from that file in the create POST, so the release is born WITH its notes instead of being created empty and PATCHed afterward. canary/rc have no file -> empty body, unchanged. New manual `announce` workflow (workflow_dispatch, tag input) re-syncs the notes file over the live release and posts a violet embed (title, notes lead-in, release-page link) to the Discord #releases channel via the DISCORD_RELEASE_WEBHOOK secret. Stable-only: a -rc tag is refused unless allow_prerelease=true. Pressing "go" is the quality gate, so a half-built or failed release is never announced. docs/releases/README.md documents the ritual; TEMPLATE.md is the skeleton. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 16:43:18 +02:00
enricobuehlerandClaude Fable 5	d83eeedde4	ci(flatpak): drop the use-vc TCP-DNS hack — the runner-side cache made it the failure ... Every flatpak Tooling failure on 2026-07-22 (4 runs, incl. two AFTER the runner fleet got its local dnsmasq cache) died in flatpak remote-add with an instant 'Could not resolve hostname' ×10 while dnf in the SAME container resolved fine. The one thing only this leg does is force glibc onto TCP DNS (use-vc) — a 2026-07-11 mitigation for the embedded resolver dropping UDP under fleet load. With job containers now resolving against the on-box dnsmasq cache (daemon.json dns → docker0), UDP is reliable again and the TCP path through the same chain is the flaky one under concurrency. Remove the hack; keep the nss-resolve drop and retry.sh as the backstop. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 00:27:52 +02:00
enricobuehlerandClaude Fable 5	b5ed486243	ci(android): survive fleet-load download truncation in the SDK setup ... The android leg failed twice on 2026-07-22 with sdkmanager's "Error on ZipFile unknown archive" — once in our NDK/build-tools step, once inside setup-android's default package set. Root cause is the shared runner fleet dropping packets under parallel-job load (the same class retry.sh documents for the flatpak leg): sdkmanager unzips while streaming, so a truncated stream reads as a corrupt archive. A solo re-download on the same runner verified clean. - setup-android: install only platform-tools — the action's default legacy `tools` package drags in the ~250 MB emulator this job never uses, which was the largest and flakiest download in the whole leg. - NDK/build-tools/CMake: wrap sdkmanager in retry.sh (4 attempts, linear backoff) — a failed attempt leaves no partial package, so re-invoking is safe. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 22:12:02 +02:00
enricobuehlerandClaude Fable 5	abc54a7d13	fix(decky): actually ship shortcut artwork + Steam Input layout in the published plugin ... The CI workflow assembled the store zip by hand and silently drifted from scripts/package.sh when 60d46530 added assets/ and controller_config/ — every published build (canary and stable through 0.17.1) was missing both, so the Steam shortcut a fresh install creates had no images and no controller layout (shortcut_art() found nothing to send; apply_controller_config failed with template-missing). CI now stages through scripts/package.sh — the plugin file list lives in one place — and a backstop verifies the runtime-loaded pieces are in the zip before publishing. Frontend hardening for installs poisoned by those builds: applyArtwork stamped its per-appId ART_VERSION marker even when zero assets were applied, so shipping the files alone would never heal existing shortcuts — only mark done when something actually landed, and bump ART_VERSION 2→3 to force one re-apply. Same guard for the controller-config marker (ok with zero account configset dirs is not done), plus one deferred artwork retry for the fresh-AddShortcut registration race setShortcutHidden already defers around. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 22:36:55 +02:00
enricobuehlerandClaude Fable 5	8d72e1d27e	feat(plugin-kit): @punktfunk/plugin-kit 0.1.0 — the Effect plugin framework ... The ~80% of every plugin that was copy-pasted (rom-manager ↔ playnite), extracted as one Effect-v4 package: - runtime: definePluginKit — async-main boundary hiding a ManagedRuntime (two-effect-instances discipline), signal-driven interruption with a bounded shutdown grace - config: Schema-driven raw round-trip (defaults only in the Schema via withDecodingDefaultKey + encodingStrategy omit; file stays authored-shape), atomic writes, world-writable refusal, changes stream - cache-store: disposable derived state, corrupt→empty, write-through - reconcile: kit-owned provider wire schemas + typed client over the skew-safe untyped pf.request seam - sync-engine: generic poll/watch/debounce/single-flight-coalesce/ fingerprint-skip engine with a status PubSub (the SSE feed) - ui-server + sse: effect/unstable/httpapi behind servePluginUi with core-only env layers (validated by the phase-0 spikes); raw SSE route (httpapi has no event-stream media type) - cli: minimal command dispatcher reusing the plugin layer graph (deliberately not effect/unstable/cli — it needs platform packages) - react subpath: plugin router (path→hash→fallback deep-link restore + pf-ui:navigate bridge), ResultGate, sseAtom, resolvePluginBase - theme.css: the console's violet identity packaged for plugin UIs 18 bun tests incl. the two phase-0 spikes; publish workflow mirrors sdk-publish (tag plugin-kit-v*; 0.1.0 published manually). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 18:41:11 +02:00
enricobuehlerandClaude Opus 4.8	3213c1b61c	ci(flatpak): resolve over TCP so the flathub bootstrap stops failing on tag pushes ... The flathub remote-add has now burned its entire retry budget and failed the job on three consecutive tag builds — v0.15.0, the v0.15.0 re-point, and v0.16.0 — each one needing a manual re-run to land the bundle. The cause was already root-caused here on 2026-07-11 (see the Tooling step's comment): home-runner-1's Docker embedded resolver at 127.0.0.11 drops UDP lookups while the shared multi-org fleet is saturated. Nothing retransmits a dropped datagram, so the lookup simply times out. The fix then was to widen retry.sh to 10 attempts (~9 min), which comfortably outlasts a main push's ~8-workflow fan-out — but a TAG push starts 13 workflows at once, and that burst now outlives the whole budget. Retrying harder is chasing the symptom; the transport is the problem. `options use-vc` moves resolution to TCP, where the kernel retransmits and a query cannot be silently lost under load. Same resolver and search path — only the transport changes — so internal names still resolve exactly as before. Deliberately no additional nameservers: a public resolver in the list could answer an internal name (git.unom.io) with NXDOMAIN. retry.sh stays as the backstop for real upstream blips. Applied non-fatally, because Docker bind-mounts /etc/resolv.conf and may present it read-only: a DNS tuning that cannot be applied must not be the thing that fails a release build. If the write is refused we warn and stay on UDP, i.e. exactly today's behaviour. Scoped to the flatpak workflow, where the failure is actually evidenced, rather than applied fleet-wide on suspicion. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 08:33:34 +02:00
enricobuehlerandClaude Opus 4.8	b3adfb3a56	ci(release): pin Xcode DerivedData so it stops filling the mac runner's disk ... v0.16.0's Apple leg failed at the xcframework build with "No space left on device (os error 28)": the runner's boot volume was at 100% with 152 MB free. None of the four `xcodebuild archive` calls passed -derivedDataPath, so each one used the default ~/Library/Developer/Xcode/DerivedData/<name>-<hash> — and that hash is derived from the PROJECT'S ABSOLUTE PATH. act_runner rotates its workspace (~/.cache/act/<hash>/hostexecutor), so every rotation looked like a new project to Xcode and minted a fresh ~760 MB tree. Nothing ever collects those: they live outside the workspace, so act's own cleanup never sees them. 31 had accumulated in three days (17 -> 20 July), which with the 12 GB shared ModuleCache came to 32 GB — on a 228 GB volume already 95% full. Pin all four archives to one path. The tree is now REUSED rather than multiplied, which also keeps the module cache warm instead of rebuilding it per run. The new step additionally prunes anything week-stale left in the default root, covering both the legacy per-path trees and any other job that lands there. Cleared by hand on home-mac-mini-1 to unblock the release (152 MB -> 31 GB free); this is the change that stops it coming back. Note the same class of problem bit the Windows runner the same night from the other direction — its disk-cleanup task purges C:\t and deleted files out from under ISCC mid-pack — which is worth its own look and is NOT addressed here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 08:17:33 +02:00
enricobuehlerandClaude Fable 5	2508b72062	feat(client/windows): make the console UI findable, and launchable on its own ... Two problems, one feature. The gamepad/couch UI existed but you had to already know it was there: - On the hosts page its card only rendered when a controller was CONNECTED, so with no pad plugged in there was no visible entry point at all -- the only other door being a per-host overflow menu behind a "..." nobody opens. The card now always shows, with copy that adapts to whether a pad is present, so the feature is findable before you own the hardware. - There was no way to start it directly. An HTPC or TV box wants the couch interface as its first screen, not the desktop shell. "punktfunk-client --console" now hands straight off to it (fullscreen unless --windowed), which covers shortcuts, Steam entries, autostart and Task Scheduler. The Start-menu tile needs its own executable: an MSIX <Application> cannot pass arguments to a full-trust exe, so "punktfunk-client.exe --console" is not expressible there. punktfunk-console.exe is a ~20-line hand-off to the session binary's browse mode, staged into the package and given its own tile ("Punktfunk Console"). Nothing new is implemented behind either door: a bare "--browse" was already a complete standalone client (host list, discovery, PIN pairing, settings, Wake-on-LAN, library). It just had no front door. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00