101 Commits

Author	SHA1	Message	Date
enricobuehler	a9cca82fb8	chore(windows): clean up build/packaging - drop vendored driver binaries + the LLVM-21 pin ... Now that the drivers build from source in CI, remove the dead checked-in binaries and the toolchain cruft they left behind: - Delete packaging/windows/{pf-vdisplay,gamepad-drivers}/ (the prebuilt .dll/.inf/.cat/.cer). pack-host-installer.ps1 builds + signs all three drivers from the drivers/ workspace and nothing reads the vendored dirs anymore; stage-pf-vdisplay.ps1's -VendorDir is now a mandatory build-output path, not a vendored default. - Drop the LLVM-21 pin. The vendored bindgen 0.71->0.72 bump (the shipping pack already builds green on the runner-default clang 22) retired the bindgen-0.71 layout-test overflow that needed LLVM 21.1.2, so windows-drivers.yml + provision-windows-wdk.ps1 no longer install/point at C:\llvm-21 (~898 MB off a fresh provision) - both driver builds now use one toolchain (clang 22 + bindgen 0.72). - pack -SkipBuild on the gamepad build (build-pf-vdisplay.ps1 already builds the whole workspace), build-web.ps1 reaps a stale node too, deploy-dev.ps1 nefconc path + comments. - Reword the vendored-driver references (build scripts, .iss, READMEs, the vite web-bundle comment) to the build-from-source reality. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:16:46 +00:00
enricobuehler	bdfab8e0d5	fix(windows-installer): build pf-vdisplay from source in CI; ASCII scripts; upgrade-safe web console ... The pf-vdisplay virtual-display driver shipped as a checked-in PREBUILT binary that went stale - two field failures on a fresh install (live-repro'd on a German-locale Dell laptop): * Bug A (every box): a repo-wide rename edited the vendored pf_vdisplay.inf but never re-signed pf_vdisplay.cat, so the catalog stopped covering the INF -> `pnputil /add-driver` fails SPAPI_E_FILE_HASH_NOT_IN_CATALOG -> driver never installs -> every session dies "pf-vdisplay driver interface not found". * the prebuilt binary also predated IOCTL_SET_RENDER_ADAPTER (added to the driver source after the vendor freeze) that the host needs to pin the IDD render GPU on hybrid/Optimus boxes. Fix: build the driver FROM SOURCE every release (build-pf-vdisplay.ps1, wired into pack-host-installer.ps1) so .dll/.inf/.cat are always in lockstep and current driver features ship. The runner's clang 22 made the driver's pinned bindgen 0.71 emit opaque structs (157 layout-assert errors), so bump the vendored wdk-sys/wdk-build bindgen 0.71 -> 0.72 (+ lock). The build self-signs the driver per build (installer trusts the bundled .cer); a stable DRIVER_CERT_PFX_B64 secret can override. * Bug B (non-English boxes): the installer runs install-pf-vdisplay.ps1 etc. via powershell.exe (5.1), which reads a BOM-less script in the ANSI codepage - an em-dash's trailing 0x94 byte becomes a curly quote on German Windows-1252 and the script aborts "unterminated string", so the driver never installed (the gamepad script survived only because it was already ASCII). Scrub every installer-run .ps1/.cmd to ASCII + add a CI gate that fails on any non-ASCII so it can't regress. * Bug C (upgrades): nothing stopped the OLD web console before re-registering its task, so a stale server kept :3000 (the new one restart-looped on EADDRINUSE) and served a broken old bundle (500 on /login). Stop + reap it (runtime-agnostic, by the :3000 listener owner) in web-setup.ps1 and in the .iss before the file copy + on uninstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 14:33:34 +00:00
enricobuehler	f6490f4c28	fix: complete the docs/→design/ and openapi→api/ rename references ... The file moves (docs/ → design/, docs/api/openapi.json → api/openapi.json) landed in d01a8fd, but the matching reference updates did not — so mgmt.rs's drift-test `include_str!("../../../docs/api/openapi.json")` pointed at a path that no longer exists and the host failed to build. This restores it and updates every reference: - mgmt.rs include_str! → ../../../api/openapi.json (fixes the build) - web/orval.config.ts codegen target, web/Dockerfile, .dockerignore - deb/rpm/Arch packaging install paths - CLAUDE.md, the .gitea CI workflows, code doc-comments, design-doc cross-links docs-site route URLs (/docs/...) untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 11:53:02 +00:00
enricobuehler	d01a8fd17a	feat(host): HDR Vulkan layer so Vulkan games get HDR on the virtual display ... NVIDIA/AMD Vulkan ICDs refuse to *advertise* an HDR color space for a surface on an IddCx indirect/virtual display, so Vulkan games (Doom: The Dark Ages, id Tech, Indiana Jones, …) report "device does not support HDR" — even though Windows HDR, DWM compose, and the client PQ stream all work, and the ICD happily *accepts + presents* a forced HDR swapchain there. The whole gap is enumeration; the community (Apollo/Sunshine/VDD) wrote this off as kernel-side / unfixable. Add VK_LAYER_PUNKTFUNK_hdr_inject (packaging/windows/pf-vkhdr-layer/): a standalone cdylib Vulkan implicit layer that appends {A2B10G10R10, HDR10_ST2084} + {RGBA16F, scRGB} to vkGetPhysicalDeviceSurfaceFormats[2]KHR (no need to hook vkCreateSwapchainKHR — the ICD doesn't validate the color space there). Self-gated on the surface monitor's actual advanced-color state (DisplayConfig GET_ADVANCED_COLOR_INFO), so it is a complete no-op on SDR sessions and real monitors (dedup). Always-on (registry-discovered) so it works regardless of how a game is launched — env-scoping silently fails for already-running Steam. Escape hatches: DISABLE_PF_VKHDR, PF_VKHDR_EXCLUDE, and a built-in kernel-anti- cheat denylist. The installer builds/signs/stages it and registers it under HKLM64\SOFTWARE\Khronos\Vulkan\ImplicitLayers (opt-out "Install the HDR Vulkan layer" task); windows-host CI fmt+clippy-gates it (msvc-only FFI). Live-validated on the RTX box: Doom: The Dark Ages enables HDR over the pf-vdisplay virtual display. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 11:33:20 +00:00
enricobuehler	00cf51d610	refactor: rename pf-vdisplay-proto -> pf-driver-proto (it spans all drivers) ... The shared host<->driver ABI crate already contains more than the virtual display: the IDD-push frame ring + control plane AND the gamepad shared-memory layouts (XusbShm / PadShm). "pf-vdisplay-proto" was a misnomer — the name now represents all the drivers it serves. Mechanical rename, no behavior change: - git mv crates/pf-vdisplay-proto -> crates/pf-driver-proto (package name + path-deps in the host crate and the driver workspace). - pf_vdisplay_proto -> pf_driver_proto across host + driver Rust, both Cargo.lock files, the workspace members, the CI path triggers (windows-drivers.yml), and the docs/INF comments. The runtime Global\pfvd-* shared-object names are a SEPARATE contract and are deliberately untouched (host<->driver name matching). - The pf-vdisplay DRIVER crate + its INF service name (Root\pf_vdisplay, UmdfService=pf_vdisplay, pf_vdisplay.dll) are unchanged — only the full `pf_vdisplay_proto` token was replaced, never the `pf_vdisplay` driver name. Linux-verified: cargo test -p pf-driver-proto (const size-asserts compile) + cargo clippy -p punktfunk-host -D warnings clean; Cargo.lock regenerated. The driver-workspace side (path-dep + imports + its Cargo.lock) is Windows-CI-gated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 05:38:21 +00:00
enricobuehler	d0d31b1040	fix(windows-drivers): size_of config size (1.0 IddCxStub lacks the version table) + CI builds pf-vdisplay ... The versioned IDD_STRUCTURE_SIZE path referenced IddClientVersionHigherThanFramework/ IddStructureCount/IddStructures — LNK2019 unresolved, because the WDK links the iddcx 1.0 IddCxStub which lacks those (they are >=1.4). We target 1.10 against a current framework (higher==false) where size_of is exactly the versioned result, so use it directly (the surface-assert refs linked only because they were DCE-eliminated). pf-vdisplay now COMPILES + LINKS IddCxStub on the box (263,680B). Point windows-drivers.yml at the whole workspace + clear FORCE_INTEGRITY on pf_vdisplay.dll; drop the obsolete UINT diagnostic dump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 16:16:22 +00:00
enricobuehler	2f7847ce9b	ci(windows-drivers): dump generated iddcx.rs structure on failure (diagnostic) ... UINT fails to resolve despite a top-level `pub type UINT` in the same scope as the working `use crate::types::*` — error count byte-identical before/after the fix. Add an if:always() step dumping the generated module structure + UINT-use context to pinpoint the scope mismatch (RTX box rebooted to Proxmox, so CI is the only validator). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:55:20 +00:00
enricobuehler	f896f70bb8	feat(windows-drivers): clear FORCE_INTEGRITY for self-signed driver load (M0) ... wdk-build links UMDF drivers with /INTEGRITYCHECK unconditionally (no opt-out), so the self-signed DLL would be refused by Code Integrity (3004/3089). Add a deterministic, idempotent, reusable packaging step (packaging/windows/clear-force-integrity.ps1) that clears the PE IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY bit (0x0080 @ e_lfanew+0x5e) and verifies — the gamepad recipe, no longer hand-run. driver-build now inspects the bit (before) then clears+verifies it. Real drivers will: build -> clear -> sign .dll -> Inf2Cat -> sign .cat. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 11:38:57 +00:00
enricobuehler	b24c10a723	ci(windows-drivers): LLVM via portable tar.xz + self-provision driver-build ... The LLVM NSIS .exe /S silent install HANGS in the headless SYSTEM CI session (stuck >15min after download, blocking the single runner). Switch to the portable clang+llvm-21.1.2-x86_64-pc-windows-msvc.tar.xz (curl + Win11 tar -xf, strip 1) — deterministic, no installer. And make driver-build run the provision script itself (idempotent) so it self-provisions LLVM and never races a separate provision run. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 09:27:42 +00:00
enricobuehler	1682b83b3f	ci(windows-drivers): point driver-build LIBCLANG_PATH at LLVM 21.1.2 ... Use the provisioned C:\\llvm-21 libclang for the driver build so wdk-sys bindgen builds clean (the runner default LLVM is a ToT/22-dev with the E0080 layout-test overflow bug). Queues behind the in-progress LLVM provision on the single runner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 09:08:04 +00:00
enricobuehler	4f62643c82	ci(windows-drivers): static-CRT .cargo/config (fixes StaticCrtNotEnabled) ... wdk-build errored StaticCrtNotEnabled + the generated wdk-sys layout asserts overflowed (E0080) — UMDF needs the static CRT. Add the canonical windows-drivers-rs .cargo/config.toml: explicit target = x86_64-pc-windows-msvc (separates host proc-macros, which stay dynamic-CRT, from the driver) + target-feature=+crt-static scoped to that target. DLL now under the triple subdir. The WDK bindgen itself now runs (it generated out/types.rs) — this is the last build-config layer before the /INTEGRITYCHECK verdict. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:52:40 +00:00
enricobuehler	bed4711096	ci(windows-drivers): in-tree target dir for driver-build (find the lock) ... wdk-build find_top_level_cargo_manifest() walks UP from OUT_DIR to the first ancestor with a Cargo.lock; the relocated CARGO_TARGET_DIR=C:\\t\\drvws hid the workspace lock (ancestors C:\\t, C:\\ have none) -> the "Cargo.lock should exist" panic. Drop the override; the driver deps have no deep CMake crates so the in-tree target stays under MAX_PATH. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:45:00 +00:00
enricobuehler	d3e4ea0118	feat(windows-drivers): driver workspace + wdk-probe on windows-drivers-rs (M1) ... Stand up packaging/windows/drivers/ — the unified driver workspace on crates.io windows-drivers-rs (wdk 0.4.1 / wdk-sys + wdk-build 0.5.1), retiring the dev-box ../../crates/wdk* path-deps. First member: wdk-probe, the smallest UMDF2 driver (DriverEntry -> WdfDriverCreate -> EvtDeviceAdd -> WdfDeviceCreate) that force-links the shared pf-vdisplay-proto ABI crate. It validates on the runner: wdk-sys bindgen + WDF stub link against the WDK + LLVM, the cross-workspace no_std proto path-dep, and the produced DLL's PE FORCE_INTEGRITY bit. windows-drivers.yml gains a driver-build job: cargo build -p wdk-probe (pinning Version_Number=10.0.26100.0) + a PE inspection that prints whether /INTEGRITYCHECK is set — the M0 self-signed-load question. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:33:38 +00:00
enricobuehler	d8a7d6f3a2	ci(windows-drivers): provision WDK + cargo-wdk on the runner (rewrite M0) ... The windows-amd64 runner has the base Windows SDK + MSVC + LLVM + Rust but NOT the WDK (probed: km=False, no um/iddcx, no inf2cat/stampinf/devgen) or cargo-wdk, so the all-Rust UMDF drivers can't build there yet. Adds an idempotent provisioning script (scripts/ci/provision-windows-wdk.ps1: download wdksetup 26100 -> /q /norestart, cargo install --locked cargo-wdk, then verify km/wdf + iddcx headers + inf2cat/stampinf + cargo-wdk) and a workflow_dispatch/push workflow that runs it on the persistent runner (one-time; install persists). cargo-wdk (not cargo-make) is windows-drivers-rs's current build+package tool (cargo build -> stampinf/inf2cat/signtool). Driver builds must pin Version_Number=10.0.26100.0 (the runner also has 10.0.28000.0, which lacks km/crt). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:20:55 +00:00
enricobuehler	8a04db9844	ci(windows-drivers): probe runner driver toolchain + build proto (rewrite M0) ... Stage-1 CI for the Windows-host rewrite: a probe job on the self-hosted windows-amd64 runner that reports the driver toolchain (WDK Include km/ + iddcx versions, inf2cat/stampinf/devgen/signtool, EWDK, LLVM/clang version, cargo-make, installed Rust targets) so we know what's provisioned BEFORE writing driver code, and builds+tests+lints pf-vdisplay-proto on MSVC to prove the owned ABI crate compiles cross-OS and the CI wiring works. No RTX GPU needed for any of this (only live NVENC encode needs one — that defers to the RTX box). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 06:51:59 +00:00
enricobuehler	c5dab484df	feat(windows): bundle pf-vdisplay in the host installer; drop SudoVDA ... Switch the Inno Setup installer's virtual-display driver from the vendored SudoVDA C++ binary to our own all-Rust pf-vdisplay (validated streaming at 5120x1440@240). - packaging/windows/pf-vdisplay/: vendored SIGNED driver (pf_vdisplay.dll/inf/cat + punktfunk-driver.cer, the same cert the gamepad drivers ship), built from vdisplay-driver/ via deploy-dev.ps1. - install-pf-vdisplay.ps1 / stage-pf-vdisplay.ps1: mirror the SudoVDA scripts - trust cert -> gated ROOT\pf_vdisplay node via nefconc (NEVER devgen) -> pnputil /add-driver /install. Idempotent, best-effort (never aborts the install). - punktfunk-host.iss + pack-host-installer.ps1: install the pf-vdisplay bundle under the existing installdriver task. - Removed the vendored SudoVDA driver + install-sudovda.ps1 + stage-sudovda.ps1. - README + windows-host.yml: SudoVDA -> pf-vdisplay. The host's vdisplay/sudovda.rs backend is unchanged - it drives whichever driver provides the {e5bcc234} interface, now pf-vdisplay. Live installer build/test on the runner is the remaining step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:39:28 +02:00
enricobuehler	de232ec2f7	fix(web): bundle deps into the server (noExternals) — kill the 47k-file install ... The Windows installer ballooned to 154 MB and installed forever because the node-server bundle externalized the WHOLE @unom/ui dependency tree (payload, lexical, date-fns, prismjs…) to .output/server/node_modules — 47,567 files / 730 MB copied into Program Files. Set Nitro `noExternals: true` so every dependency is bundled + tree-shaken into the server output: .output drops to ~75 files / 10 MB, and the bare external imports (srvx, seroval…) bun couldn't resolve at runtime are gone — so the console runs on bun (no node, no node_modules), which is the issue we previously worked around with node. Windows installer now ships bun.exe + the ~75-file .output (was node.exe + a node_modules forest) and runs `bun .output\server\index.mjs`: - windows-host.yml: fetch a pinned portable bun (build tool AND shipped runtime); drop the node fetch + the .output/server install; smoke-boot under the bundled bun. - pack-host-installer.ps1 / punktfunk-host.iss: -NodeExe -> -BunExe; stage {app}\bun\bun.exe. - web-run.cmd / build-web.ps1: run/restart on bun; docs updated. Net win everywhere: the Linux .deb shrinks (node still runs the self-contained output), and the docker web image — which already ran `bun run .output/server/index.mjs` with only .output copied — is fixed (the externals had no node_modules to resolve at runtime). Validated locally: noExternals build = 75 files / 10 MB; node AND bun both serve /login (200) + static assets (200) + gate /api (401). (A true single binary via `bun build --compile` is blocked for now: Nitro serves public assets from an import.meta-relative path `--compile` doesn't embed (/$bunfs/public); the 75-file payload is the clean result.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 21:19:32 +02:00
enricobuehler	e4e34fdb48	fix(apple/ci): create the Simulator on demand; scope CI shots to iPhone+iPad ... Diagnosed from the first run: only the iPad shots were produced. The runner lacks an "iPhone 16 Pro Max" device, is headless (no window server -> the macOS window capture's app window never appears), and the Tier-3 tvOS build-std slice failed. - screenshots.sh: shoot_sim now creates a throwaway Simulator (matching device type + newest available runtime) when the runner has no matching device, so the iPhone 6.9" shots are reproducible instead of skipped. - apple.yml: scope the CI job to the two REQUIRED iOS sizes (iPhone 6.9" + iPad 13"), captured via `simctl io screenshot` (no Screen Recording grant needed). Drop macOS (headless runner has no window server) and tvOS (build-std slice) from CI — generate those locally with `tools/screenshots.sh macos tvos`. Faster, deterministic xcframework build (BUILD_IOS=1 only). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 20:46:41 +02:00
enricobuehler	3ec462c2ea	ci(apple): use upload-artifact@v3 for screenshots (Gitea has no v4 backend) ... Gitea's artifact storage identifies as GHES, which @actions/artifact v2+ (upload-artifact@v4) refuses outright. v3 uses the older artifact API Gitea supports; the downloaded artifact is still a zip. (The capture itself already worked — 5 macOS scenes were produced; only the v4 upload failed.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 20:41:14 +02:00
enricobuehler	32879f45bf	feat(apple): App Store screenshot harness + CI zip artifact ... A DEBUG-only "shot mode" renders one mock-populated screen full-bleed (PUNKTFUNK_SHOT_SCENE=<name> -> ScreenshotHostView instead of ContentView), so the OS can screenshot the REAL, fully-rendered UI. tools/screenshots.sh drives it: screencapture for the mac window, `simctl io booted screenshot` for the iOS/iPad/tvOS Simulators, at exactly the App Store Connect sizes. ImageRenderer was tried first and rejected: it can't rasterize this app's chrome (NavigationStack, Form/TabView, Liquid-Glass/NSVisualEffect all render black or the "can't render" placeholder). Capturing the live window/Simulator avoids that. Only the stream hero is synthetic (StreamView needs a live connection) - a synthwave frame + the real glass HUD, overridable via PUNKTFUNK_SHOT_HERO. CI: a new `screenshots` job in apple.yml builds the iOS (+ tvOS best-effort) xcframework slices, runs the harness per platform best-effort, and attaches the result as a single zip artifact (punktfunk-appstore-screenshots). It is isolated from the build/test job and skipped on PRs, so a capture gap (missing Simulator runtime, or no Screen Recording grant for the mac window capture) never reds the core signal. Generated PNGs (clients/apple/screenshots/) are gitignored. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 19:44:03 +02:00
enricobuehler	b54f781524	ci(windows-host): bootstrap bun + supply @unom token for the web build ... The first windows-host run with the bundled console failed at "bun not found": the self-hosted runner executes as SYSTEM, so the dev user's bun (and its ~/.npmrc with the @unom registry token) aren't on PATH. Make the web-build step self-sufficient: - Install bun via bun.sh/install.ps1 when it isn't already present (checking PATH + the SYSTEM/Public profile locations first), like deb.yml bootstraps it. - Write the private @unom registry mapping + auth token (REGISTRY_TOKEN) into the SYSTEM home .npmrc so `bun install` can fetch the @unom packages — kept out of the project tree and the shipped .output bundle (.output\server\.npmrc stays mapping-only). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 19:39:23 +02:00
enricobuehler	5e106c51cf	feat(windows-host): bundle + auto-run the web console in the installer ... The Windows host installer shipped only the host exe + SudoVDA driver + FFmpeg, so a fresh install had no web management console — required for basically every user (status, paired devices, the PIN pairing flow). The console was only ever set up by hand on the dev box (build-web.ps1 + a hand-made PunktfunkWeb task whose web-run.cmd wasn't even committed). Bundle it into the same installer, mirroring the proven Linux punktfunk-web deploy. - windows-host.yml builds the Nitro node-server console (bun, deb.yml's shape) + fetches a pinned portable Node, smoke-boots it under node (/login == 200) to gate the build, and hands web/.output + node.exe to the pack script. - pack-host-installer.ps1 gains -WebDir/-NodeExe and stages the .output tree, node, and the two new scripts into the non-WOW64-redirected build area. - punktfunk-host.iss lays the payload into {app}\web\.output + {app}\node\node.exe, adds a wizard page for the console login password pre-filled with a crypto-random default (shown on the finish page; kept on upgrade), and runs web-setup.ps1. - web-setup.ps1 writes the ACL'd %ProgramData%\punktfunk\web-password (Administrators + SYSTEM), registers the PunktfunkWeb scheduled task (boot, SYSTEM, restart-on-failure -> web-run.cmd -> node on :3000), opens inbound TCP 3000, and starts it. web-run.cmd sources the host's mgmt-token + the password and runs the bundled node. - The console proxies the host's loopback mgmt API with the host's own %ProgramData%\punktfunk\mgmt-token (no host-code change). Uninstall removes the task + firewall rule. Validated locally: bun build -> node-server bundle, node boot serves /login (200) and gates /api (401). The Windows-only bits (ISCC compile, scheduled task, password page, firewall) validate on the Windows runner CI + on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 19:28:47 +02:00
enricobuehler	51de8ccbdb	ci(release): run tvOS on the canary track alongside iOS/macOS ... The canary/stable split (0205c7b) gated the tvOS archive/upload — and its xcframework slice — to vX.Y.Z tags, while moving iOS/macOS onto canary main pushes. No tag has been cut since (both existing tags predate the split), so tvOS stopped reaching TestFlight entirely while iOS/macOS kept shipping on canary. Build the tvOS tier-3 slice unconditionally again (BUILD_TVOS=1; the nightly -Zbuild-std std is cached on the self-hosted runner) and drop the tag gate on the tvOS step so its if: matches the iOS / macOS App Store steps exactly — tvOS now uploads on canary main pushes + stable tags + dispatch, same as the others. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 14:47:14 +02:00
enricobuehler	72eeedc4da	feat(windows): AMD (AMF) + Intel (QSV) hardware encode on the Windows host ... The Windows host was NVIDIA-only (NVENC) with an openh264 software fallback. Add AMD AMF and Intel QSV via libavcodec — the Windows analogue of the Linux VAAPI backend — so one installer serves all three GPU vendors. - encode/ffmpeg_win.rs: new WinVendor{Amf,Qsv} encoder. System-memory NV12/P010 readback (default, robust) + opt-in zero-copy D3D11 (PUNKTFUNK_ZEROCOPY: shares the capturer's ID3D11Device; AMF takes AV_PIX_FMT_D3D11, QSV derives a QSV frames ctx and maps) with a system fallback for the format-group mismatch the capturer's video-processor fallback can produce. HDR Main10 (P010 + BT.2020/PQ VUI; an Rgb10a2->P010 swscale covers the shader fallback). - encode.rs: Codec::amf_name/qsv_name; open_video + windows_resolved_backend() resolve PUNKTFUNK_ENCODER=auto|nvenc|amf|qsv|sw via a DXGI adapter VendorId probe. - capture/dxgi.rs: gpu_mode mirrors the resolved backend (D3D11 NV12/P010 for AMF/QSV). - gamestream/serverinfo.rs: GPU-aware codec advertisement (windows_codec_support; AV1 gated to RDNA3+/Arc, like the VAAPI path). - Cargo.toml: amf-qsv feature (optional ffmpeg-next in the windows target block). - CI/installer: windows-host.yml sets FFMPEG_DIR + builds --features nvenc,amf-qsv; the Inno installer bundles the FFmpeg DLLs; host.env default nvenc -> auto. CI-green target; AMF/QSV not yet on-glass validated (no AMD/Intel Windows box in the lab) — NVENC stays live-validated. An adversarial-review pass caught + fixed real FFI bugs (AV_PIX_FMT_P010 is a macro -> P010LE; windows-rs 0.62 GetImmediateContext/ GetDesc1 return Result; AV_HWFRAME_MAP_* is a bindgen enum with no BitOr). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 10:31:54 +00:00
enricobuehler	0205c7b8d6	ci(release): split canary/stable tracks + unified Gitea Releases ... A push to main publishes canary builds to canary channels (fast iteration, unchanged); a single vX.Y.Z tag releases every platform at one version to the stable channels and attaches all artifacts (.deb/.rpm/.msix/.apk/.aab/.dmg + flatpak/decky/host-installer) to one Gitea Release. Collapses the host-v*/win-v*/host-win-v* tag namespaces into v* — the channel split makes the version-shadow bug structurally impossible (canary and stable are separate repos, never a shared version line). - scripts/ci/gitea-release.{sh,ps1}: one idempotent release helper (create-or-fetch + delete-before-upload), replacing 3 copy-pasted inline blocks and fixing their latent 409-on-reupload bug; prerelease flag auto-derived from the tag (an -rc tag won't shadow "Latest") - channels: apt canary/stable distributions; rpm *-canary/base groups; flatpak canary/stable OSTree branches + a 2nd .Canary.flatpakref; generic-registry canary/ vs latest/ aliases; Play internal/alpha; Apple TestFlight vs notarized DMG - android versionName threaded through gradle (versionCode stays run_number); Apple canary = TestFlight-only (no DMG/tvOS); canary base bumped to 0.3.0 - docs: new docs-site channels.md (subscribe table + cut-a-release runbook + box migration), refreshed ci.md workflow table + packaging READMEs Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 17:26:38 +00:00
enricobuehler	bd3f417d4b	feat(windows-client): cross-compile + ship ARM64 (aarch64) off the x64 runner ... windows.yml + windows-msix.yml gain an x86_64/aarch64 target matrix. ARM64 is cross-compiled on the one x64 Windows runner — the x64 MSVC toolset ships the ARM64 cross compiler, aarch64-pc-windows-msvc is tier-2 with host tools, and SDL3/libopus (build-from-source) cross-compile cleanly. The only arch-specific external dep is FFmpeg's import libs: the matrix points FFMPEG_DIR at a per-arch tree (x64 C:\Users\Public\ffmpeg, arm64 C:\Users\Public\ffmpeg-arm64, both FFmpeg 7.x / avcodec-61). Per-arch short CARGO_TARGET_DIR avoids a shared target dir; fmt + test run only for x64 (aarch64 can't execute on the x64 host). pack-msix.ps1 gains -Arch x64|arm64 (stamps the manifest ProcessorArchitecture, arch-suffixes the .msix/.cer); windows-msix.yml matrixes both arches and publishes ..._x64.msix / ..._arm64.msix. setup-windows-runner.ps1 provisions the rustup target + the ARM64 FFmpeg tree (idempotent). Verified live on the runner (home-windows-1): debug+release cross-build green, clippy -D warnings green, and MSIX pack produces a valid arm64 package (manifest arch=arm64; bundled exe/SDL3/avcodec/reactor-bootstrap all PE machine 0xAA64). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-19 11:44:24 +00:00
enricobuehler	16d3b7767e	feat(packaging): signed Inno Setup installer for the Windows host + CI ... MSIX (the client's format) can't install the host's LocalSystem secure-desktop service or the SudoVDA kernel driver, so the host ships as a signed Inno Setup setup.exe that runs elevated and delegates to the existing idempotent `punktfunk-host service install`. - packaging/windows/punktfunk-host.iss: lay exe into Program Files, optional SudoVDA driver task, run service install/start; [Code] stops+waits the service before file copy on upgrade; uninstall runs service uninstall. - pack-host-installer.ps1: cert (reuses MSIX_CERT_PFX_B64 / self-signed CN=unom), sign inner exe + setup.exe, fetch/stage SudoVDA, run ISCC, export public .cer. - fetch-sudovda.ps1 / install-sudovda.ps1: pinned SudoVDA + nefcon download, cert import, gated device-node create (no phantom dup), pnputil install (warn-not-abort). - nvenc/: synthesize nvencodeapi.lib via llvm-dlltool from a 2-export .def so --features nvenc links with no GPU/SDK at build time. - .gitea/workflows/windows-host.yml: build (nvenc) -> clippy -> ISCC -> sign -> publish setup.exe + .cer to the generic registry pkg punktfunk-host-windows. Tag host-win-v* -> X.Y.Z (+ latest/ alias); main push -> rolling 0.2.<run>. - setup-windows-runner.ps1: provision Inno Setup; docs: installer instructions. SudoVDA/nefcon release URLs+SHA-256s in fetch-sudovda.ps1 are placeholders (baseline v0.2.1) — fetch warns + prints the computed hash until pinned. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 23:05:20 +00:00
enricobuehler	586c4d0ddc	fix(flatpak): sign the OSTree commit, not just the summary ... Install failed with "GPG verification enabled, but no signatures found" on the commit: the deploy step only ran build-update-repo (signs the summary). Add `flatpak build-sign` to sign the commit objects too — clients with gpg-verify=true verify the commit, so summary-only signing isn't enough. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 22:10:07 +00:00
enricobuehler	f1032a7a23	fix(flatpak): pass stable branch to build-bundle (matches --default-branch) ... The CI added --default-branch=stable, so the repo ref is app/io.unom.Punktfunk/x86_64/stable. build-bundle defaults to `master` when no branch is given → "Refspec app/io.unom.Punktfunk/x86_64/master not found". Pass `stable` explicitly in both flatpak.yml and the local build-flatpak.sh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:48:17 +00:00
enricobuehler	d9d495a53e	feat(flatpak): host a signed OSTree repo at flatpak.unom.io for flatpak update ... The CI only shipped a single-file .flatpak bundle, which has no remote — users couldn't `flatpak update`. Keep the bundle (Decky fallback) but also sign the OSTree repo flatpak-builder already produces and publish it to a shared, reusable unom-wide remote. - flatpak.yml: pin --default-branch=stable; import the signing key and build-update-repo --gpg-sign; generate unom.flatpakrepo + the app .flatpakref + index.html; rsync the repo to unom-1 and bring up a static Caddy container. The step no-ops until FLATPAK_GPG_PRIVATE_KEY/DEPLOY_* exist (build stays green). - packaging/flatpak/server/: compose.production.yml + Caddyfile (static file server on :3230, mirrors docker.yml deploy-docs). - unom-flatpak.gpg: committed public signing key (base64 -> GPGKey= in the descriptors). - README: hosted repo is now the recommended install; documents the one-time infra (edge Caddy vhost, infra port 3230, DNS, the GPG secret). Edge Caddy vhost + infra port allowlist + the secret are applied out-of-band. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:07:27 +00:00
enricobuehler	9c8fa9340c	refactor: drop milestone names + consolidate clients; loss-recovery & rumble fixes ... Two bodies of work in one commit (the rename moved files the fixes also touched). Naming/structure cleanup (pre-launch): - Host modules m3.rs->punktfunk1.rs, m0.rs->spike.rs; CLI m3-host->punktfunk1-host, m0->spike; bare `punktfunk-host` now prints help. Types M3Options/M3Source-> Punktfunk1Options/Punktfunk1Source. - Clients consolidated out of crates/ into clients/: punktfunk-client-rs-> clients/probe (crate punktfunk-probe), client-linux->clients/linux, client-windows->clients/windows, punktfunk-android->clients/android/native (crate punktfunk-client-android; kept [lib] name=punktfunk_android so the JNI contract is unchanged). crates/ now holds only core + host. - Milestone codes M0-M4 purged from code/CLI/CLAUDE.md/README/docs/docs-site, kept only in docs/implementation-plan.md. docs/m2-plan.md-> docs/gamestream-host-plan.md. CI/gradle/flatpak paths updated. Client loss-recovery (video froze and never recovered after a brief drop): - Export punktfunk_connection_frames_dropped through the C ABI (the core already tracked it for the client keyframe-recovery loop; it was never reachable from the ABI clients). Regenerated punktfunk_core.h. - Apple (StreamPump + Stage2Pipeline) and Android (decode.rs) now poll frames_dropped and request a keyframe when it climbs -- the same loss-driven recovery Linux/Windows already had. Under infinite GOP the decoder silently conceals reference-missing frames, so the decode-error trigger rarely fires. Apple rumble robustness (worked then went spotty -- DualSense + Xbox): - Add CHHapticEngine stopped/reset handlers (rebuild on app background / audio interruption / server reset) and drop the permanent `broken` latch on a transient drive failure; latch only when the controller truly has no haptics. - Surface swallowed SDL set_rumble errors on Linux/Windows + diagnostic logging. Verified: cargo build/clippy/fmt --workspace, C-ABI harness, header drift. Not runnable on this box (verify in CI): Gitea workflows, gradle/Android, flatpak, Swift/decky. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 21:05:58 +00:00
enricobuehler	1faa6c6ad4	ci(android): replace r0adkll with a direct Play Publishing-API upload ... r0adkll/upload-google-play hides real API errors behind "Unknown error occurred." Proved the full upload sequence (insert edit -> upload bundle -> track update -> validate) succeeds with the service account, so the failure was r0adkll's opaque error handling and/or a base64-encoded SERVICE_ACCOUNT_JSON secret. clients/android/ci/play-upload.py does the same sequence with stdlib + openssl (no pip), reuses the SERVICE_ACCOUNT_JSON secret, tolerates it being raw JSON or base64, auto-retries commit with changesNotSentForReview, and prints Google's actual error. Locally dry-run-validated against the live app (both secret forms). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 20:38:20 +00:00
enricobuehler	72d1b19743	ci(android): publish signed AAB + universal APK to Gitea generic registry ... Build a universal release APK alongside the AAB and push both to the public generic registry (punktfunk-android/<run_number>/) before the Play upload, so artifacts are downloadable even while the Play step is still failing. Matches windows-msix.yml / deb.yml (REGISTRY_TOKEN, user enricobuehler). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 20:26:42 +00:00
enricobuehler	22409acba5	fix(ci): use android-36 platform as 37 is missing from sdkmanager channel	2026-06-18 12:24:00 +02:00
enricobuehler	a24679ce69	feat: setup CI for Google Play Store submission and refactor UI	2026-06-18 11:51:40 +02:00
enricobuehler	6c02acab59	build: update Android NDK to r30 (30.0.14904198)	2026-06-18 11:13:14 +02:00
enricobuehler	15d3d423fa	feat(decky): full-featured Gaming-Mode client — fullscreen page, pairing, focus-correct launch ... The plugin was a QAM launcher whose stream never appeared, with no pairing. Three fixes, plus a headless --pair mode on the GTK client: - Stream actually starts (MoonDeck's proven mechanism): gamescope only focuses the process tree Steam launched via reaper, so a flatpak spawned from the (root) backend is invisible. The frontend now registers ONE hidden non-Steam shortcut pointing at bin/punktfunkrun.sh, passes the host as the shortcut's Steam launch options, and starts it with SteamClient.Apps.RunGame — gamescope then fullscreen-focuses it. The wrapper execs `flatpak run io.unom.Punktfunk --connect <host>`. - Fullscreen page: routerHook.addRoute("/punktfunk") — host list, per-host Pair/Stream, and a settings section (resolution/refresh/ bitrate/gamepad/mic, written to client-gtk-settings.json). - Pairing: a gamepad-navigable PIN keypad. The host shows the PIN; the backend runs the SPAKE2 ceremony headlessly via the client's new `--pair <PIN> --connect host` CLI mode (app.rs), persisting the host as paired so the stream then connects silently. Same flatpak => shared identity store, verified live (ceremony against a real host). - Backend (main.py): discover / pair / runner_info / get_settings / set_settings / kill_stream; uses DECKY_USER_HOME so paths resolve to the deck user's flatpak install regardless of the plugin's root flag. CI (decky.yml) and the sideload packager now ship bin/punktfunkrun.sh. The Steam-shortcut launch and headless-pairing env follow MoonDeck exactly but need a Deck in Gaming Mode to fully confirm. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-17 09:17:14 +00:00
enricobuehler	a5b99b2928	fix(flatpak): prune microsoft/windows-rs git crates before vendoring ... The flatpak CI was failing at "Downloading sources" with "No space left on device": flatpak-cargo-generator walks the whole workspace Cargo.lock and emits a `type: git` source for the windows-rs crates (windows + windows-reactor + ~12 sub-crates, pinned by punktfunk-client-windows), and flatpak-builder then FULL-clones that multi-GB repo — for a bundle that only ever compiles `-p punktfunk-client-linux` and never touches a windows-* crate. New packaging/flatpak/prune-windows-lock.py writes a copy of Cargo.lock with the windows-rs git packages stripped (matches on the `source =` line, so a crate that merely lists a windows dependency is kept; dependency-free so it also runs on the Deck's stock python). Both the CI and build-flatpak.sh feed that pruned lock to the generator. The committed Cargo.lock is untouched — cargo --offline only needs vendored sources for the crates it actually builds, and the windows-rs crates are not in the Linux client's dependency closure. Verified locally: 14 crates pruned (507 -> 493 packages), zero windows-rs `source =` lines remain, output parses as TOML, all Linux-client deps (gtk4/ffmpeg-sys-next/sdl3/pipewire) intact. This unblocks the flatpak build carrying the VAAPI green-screen fix (64b1679) for the Steam Deck. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-17 07:43:11 +00:00
enricobuehler	bb11b2faf7	feat(windows): MSIX packaging + publish workflow for the WinUI client ... Package the Windows client as a signed MSIX (Start tile, clean install/uninstall) and publish it to Gitea's generic registry, mirroring the host's .deb/.rpm and the Mac's DMG. Validated end-to-end on the build VM: cargo build --release -> makeappx pack (16 payload files, 58 MB) -> signtool -> Add-AppxPackage deploy -> framework-dependency resolution all green. - packaging/AppxManifest.xml: full-trust Win32 app (Windows.FullTrustApplication + runFullTrust), templated {VERSION}/{PUBLISHER}. windows-reactor packages cleanly despite being built "unpackaged" because it calls MddBootstrapInitialize2 with OnPackageIdentity_NOOP — under MSIX identity the bootstrapper no-ops and the App SDK resolves from the manifest's PackageDependency on Microsoft.WindowsAppRuntime.2 (reactor pins MAJORMINOR 0x20000 = 2.0). - packaging/pack-msix.ps1: assemble layout (exe + reactor/SDL3 auto-staged DLLs + resources.pri + FFmpeg DLLs + tile assets), makeappx, signtool. Cert precedence: MSIX_CERT_PFX_B64 secret, else an ephemeral self-signed cert whose .cer is published alongside (swap in a real cert later, no manifest change). - assets: tile/store logos rasterized from packaging/flatpak/io.unom.Punktfunk.svg. - .gitea/workflows/windows-msix.yml: runs on the Windows runner on main pushes + win-v* tags + dispatch. MSIX version is 4-part numeric — win-vX.Y.Z -> X.Y.Z.0, else 0.2.<run>.0. shell: pwsh + CARGO_TARGET_DIR=C:\t like windows.yml. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 08:45:43 +00:00
enricobuehler	e39f65a228	ci(windows): set CARGO_TARGET_DIR=C:\t — dodge MAX_PATH in CMake-from-source builds ... With the BOM fixed (shell: pwsh), the build got far enough to compile audiopus_sys, which does a CMake-from-source build of libopus. The runner's host workdir sits deep under C:\Windows\System32\config\systemprofile\.cache\act\<hash>\hostexecutor\, so target\debug\build\ audiopus_sys-*\out\build\CMakeFiles\CMakeScratch\TryCompile-*\...\.tlog overran Windows' 260-char MAX_PATH and MSBuild's tracker failed to create its .tlog (DirectoryNotFoundException -> MSB6003, "CL.exe konnte nicht ausgeführt werden"). Pointing CARGO_TARGET_DIR at C:\t shortens every nested build path well under the limit (fixes audiopus_sys + SDL3, both CMake-from-source). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 08:18:34 +00:00
enricobuehler	372483abf0	ci(windows): use shell: pwsh (PowerShell 7) — fixes GITHUB_ENV BOM corruption ... Windows PowerShell 5.1's Out-File -Encoding utf8 prepends a UTF-8 BOM, corrupting the first GITHUB_ENV line so CARGO_WORKSPACE_DIR silently never got set -> windows-reactor build.rs panic -> CI build failed (runs 8765/8768). pwsh 7 writes UTF-8 without a BOM. Installed PowerShell 7.6.2 MSI on the runner and put C:\Program Files\PowerShell\7 on the daemon wrapper PATH so jobs find pwsh; switched all windows.yml steps to shell: pwsh. (Reproduced locally with CARGO_WORKSPACE_DIR set: the build is green in 2m37s — the BOM was the only issue.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 08:10:30 +00:00
enricobuehler	7a814b5f18	ci(windows): restore paths filter + document global runner scope ... Re-add the paths filter (the trigger was never the problem — the runner was registered at the wrong scope, so org-repo runs found 'no fitting runner' despite the runner showing idle). Document in setup-windows-runner.ps1 that the registration token must be GLOBAL (Site Administration -> Actions -> Runners), like the Linux runner. CARGO_WORKSPACE_DIR is set via GITHUB_ENV in a step (the job-env ${{ github.workspace }} form didn't resolve, leaving it unset -> reactor build.rs panic). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 07:38:08 +00:00
enricobuehler	644274c33e	ci(windows): set CARGO_WORKSPACE_DIR via GITHUB_ENV (not job-env expression) ... Mirror apple.yml's shape — drop the job-level env + defaults blocks; set CARGO_WORKSPACE_DIR from $GITHUB_WORKSPACE in a step (Gitea can't resolve github.workspace at job-env-eval time) and use per-step shell: powershell. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 07:24:53 +00:00
enricobuehler	dd9dfecbe4	ci(windows): drop paths filter (trigger reliability) + NO_COLOR runner logs ... The paths filter wasn't dispatching the run on the newly-added workflow (the runner is healthy and 'declare successfully', but received no task). Match apple.yml: trigger on every push to main + PRs. Also set NO_COLOR in the daemon wrapper so runner.log is plain text (the ANSI spinner garbled it). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 07:16:26 +00:00
enricobuehler	fc11a42b63	ci(windows): build/clippy/fmt/test workflow on the self-hosted Windows runner ... runs-on: windows-amd64 (home-windows-1, host mode). Build + clippy(-D warnings) + fmt + test the WinUI 3 client. The toolchain is baked into the runner's daemon env; the workflow only sets CARGO_WORKSPACE_DIR=${{ github.workspace }} (windows-reactor's build.rs needs it). Triggers on changes to the windows crate / core / Cargo / this workflow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 07:11:11 +00:00
enricobuehler	8446ca1e47	ci(android): keep platforms;android-36 (android-37 not in the runner SDK channel) ... The previous CI fix bumped the pinned platform to android-37, but the runner's sdkmanager has no such package yet ("Failed to find package 'platforms;android-37'"), failing the SDK step before it could install CMake. Revert to platforms;android-36 (AGP auto-installs the compileSdk-37 platform during the build, as it did before) while keeping the cmake;3.22.1 package that fixes the libopus cross-build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 16:31:46 +02:00
enricobuehler	8265742e74	ci: bust the re-poisoned cargo cache (v3) + burst-guard the runner prune ... This session's push storm refilled the runner to 100% WITHIN the prune timer's 24h window (it only trims >24h), so a build hit ENOSPC and actions/cache saved a truncated target/ -> `error[E0463]: can't find crate for shlex` in ci.yml's clippy. Two fixes: - Bump cargo-target-v2- -> v3- in ci.yml + deb.yml so the poisoned tarball is bypassed (a suffix bump can't — restore-keys falls back to the old prefix; same as the v1->v2 fix). - Harden scripts/ci/docker-prune: run HOURLY (was 6h) with a burst guard — if the disk is still >85% after the normal until=12h trim, prune ALL idle images + build cache (in-use protected). A fast push-burst can fill 99 GB inside any time window, so the disk-pressure trigger, not the age filter, is the real backstop. Applied live on home-runner-1 (reclaimed 95%->66%) and checked in. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 14:25:40 +00:00
enricobuehler	6e572a38cd	ci(android): install the SDK CMake package so cargo-ndk can build libopus ... The android.yml runner installed the NDK but not cmake/ninja, so cargo-ndk's audiopus_sys (libopus via CMake) failed with "is `cmake` not installed?" — broken since the audio increment added the libopus dependency. kit/build.gradle.kts prepends $ANDROID_SDK/cmake/3.22.1/bin to PATH (the same SDK CMake that makes local builds work); install cmake;3.22.1 (cmake + ninja) so that path exists in CI too. Also pin platforms;android-37 to match compileSdk (AGP auto-installs it otherwise). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 16:17:14 +02:00
enricobuehler	262305b771	fix(ci): provide bun for deb.yml's web-console build ... deb.yml builds the punktfunk-web .output in the rust-ci image, but that image had no bun (only ci.yml's web/docs jobs use the oven/bun image) -> "bun: not found". Bake bun (+ unzip for its installer) into ci/rust-ci.Dockerfile, and bootstrap it in the deb web step too so the job is green against the previous image (docker.yml rebuild lag) — mirroring the rpm.yml fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 14:06:12 +00:00
enricobuehler	59bcfa1a12	fix(ci): rpm signing uses rpm's default signer; flatpak installs node before checkout ... Two CI fixes: - rpm signing (2nd bug): overriding %__gpg_sign_cmd via --define reached gpg with %{__plaintext_filename}/%{__signature_filename} UNEXPANDED ("No such file or directory"). Stop overriding it — use rpm's default signer (which expands those correctly) and just set _gpg_name; a passphrase-less key + loopback in gpg.conf makes gpg sign headless. (Requires a passphrase-less signing key, as the runbook's %no-protection key is.) - flatpak: the job runs in fedora:43 which has no node, so actions/checkout (a JS action) failed with "node: not found". Install nodejs in a plain `run:` step (shell, no node needed) before checkout. Also scope the heavy flatpak-builder run to client/core/manifest changes (+ tags) so it stops rebuilding on every unrelated docs/host push (tag pushes still build — paths filters only branch pushes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-15 13:54:43 +00:00