9 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	cec3955872	feat(client/linux): the app icon reaches About — and the launcher, which never had it either ... Adding the icon to the About dialog turned out to be one line and a missing install: the icon existed, but only the flatpak ever shipped it. The deb, rpm, arch and nix entries all carried `Icon=video-display` — a stock monitor glyph — so on every non-flatpak install the launcher, the taskbar and the window switcher have been showing a generic icon this whole time. About would have shown the same nothing. So the icon moves out of `packaging/flatpak/` into `packaging/linux/icons/hicolor/` beside the tray icons, which is where a shared asset belongs, and all five packagings install it to the same hicolor path. The desktop entry names the app's own icon, and `AboutDialog` names the app id — one identity resolved through the icon theme rather than a path anyone has to keep in step. A `PUNKTFUNK_SHOT_SCENE=about` scene comes along so the dialog is capturable like every other surface; that is how the icon above was verified to actually resolve rather than silently falling back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:38:53 +02:00
enricobuehlerandClaude Opus 5	bf98102714	feat(packaging): ship punktfunk everywhere, and deprecate the session's stray pairing flag ... The rest of C1. A CLI that only exists in a dev tree is not a door anyone can use, so it now builds and installs in deb, rpm, arch, nix, flatpak and MSIX alongside the client and the session. On Windows it gets its own `AppListEntry="none"` application with the alias `punktfunk.exe` — a command, not a Start-menu tile — which is what the Playnite importer will shell to for `punktfunk library <host> --json`. `punktfunk-session --pair` prints a deprecation notice and forwards. Pairing is a trust ceremony and belongs to the brain, fronted by `punktfunk pair` or a shell; a renderer owning one is precisely the mixing of concerns this split exists to undo. It keeps working for a release, because someone's provisioning script is calling it today. Decky's invocations are untouched and verified still working (`--list-hosts` JSON shape unchanged, `--reachable` exit codes unchanged): those flags are a frozen compat contract until Decky migrates to the verbs at its own pace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Opus 5	fa430646ff	fix(packaging): the Pulse shim is never the client's, and never the host's requirement ... Same bug as the Arch package, in the other two packagings. The .deb CLIENT recommended `pipewire-pulse`. Apt installs Recommends by default and the shim Conflicts with `pulseaudio`, so this proposed pulling the user's sound server out from under them in exchange for something the client cannot use: audio.rs drives libpipewire-0.3 directly and opens no Pulse socket. (SDL is initialized with zero subsystems — gamepads only, on demand — so it brings no audio backend either.) The RPM HOST hard-Required `pipewire-pulseaudio`, which conflicts with `pulseaudio` on Fedora too — uninstallable for anyone running real PulseAudio. The host doesn't speak Pulse either; the shim is for the GAMES, which commonly emit through the PulseAudio API, and real PulseAudio serves those equally well. Demoted to Recommends, so the default Fedora box is unchanged and the informed choice stops being blocked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:14:56 +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 4.8	efbcc4cdb6	fix(packaging): ship packages@unom.io as the maintainer, not noreply@anthropic.com ... Every Linux package declared its maintainer as `noreply@anthropic.com` — the git co-author trailer address, copied out of commit metadata into PACKAGE metadata, where it is user-visible: * deb: `Maintainer:` in the host/client/web/scripting control files, plus the generated debian/changelog trailer (`dpkg -s punktfunk`) * rpm: all three %changelog entries (`rpm -q --changelog`) * arch: the PKGBUILD Maintainer comment So installed packages named Anthropic as the maintainer of this project, and pointed anyone with a packaging problem at an address that discards mail. packages@unom.io is the project's real packaging identity — it's already the EdDSA key (AF245C506F4E4763, "punktfunk packages") that sign-rpms.sh signs every RPM with, and it's what packaging/rpm/README and the bootc Containerfile document. The RPMs were therefore SIGNED by packages@unom.io while DECLARING noreply@anthropic.com; those now agree. Checked the other publisher surfaces — the Inno installer (AppPublisher=unom), the flatpak metainfo (developer id io.unom) and the decky package.json were already correct. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 11:21:05 +02:00
enricobuehlerandClaude Opus 4.8	0052a6ae30	fix(packaging): vulkan-headers build dep + ship punktfunk-session across desktop packages ... The re-architecture split the Linux client into two binaries (shell + Vulkan session streamer) and added the pf-ffvk crate, whose build.rs runs bindgen over FFmpeg's libavutil/hwcontext_vulkan.h (#include <vulkan/vulkan.h>). Two release regressions fell out of that on the desktop-package legs: 1. Missing build dep. The Arch build (archlinux:base-devel + its own pacman list) fatal-errored at `vulkan/vulkan.h file not found`. Add the Vulkan dev headers wherever the client compiles from a self-managed dep set: arch (PKGBUILD makedepends + arch.yml), rpm (spec BuildRequires + rpm.yml + fedora image), deb.yml (belt-and-suspenders; the rust-ci image already bakes libvulkan-dev), and the screenshots job. The flatpak builds offline against the GNOME SDK, so install Vulkan-Headers into /app as a pinned module and point pf-ffvk's bindgen at it via PF_FFVK_VULKAN_INCLUDE. 2. Only the shell shipped. arch/deb/rpm built and installed just punktfunk-client; the shell execs its sibling punktfunk-session for a connect, so desktop streaming would break exactly as Decky's did. Build and install BOTH binaries in all three, and declare the runtime Vulkan loader the session binary dlopens (vulkan-icd-loader / vulkan-loader / libvulkan1 — not a DT_NEEDED, so shlibdeps/auto-requires can't see it). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-07 23:41:10 +02:00
enricobuehlerandClaude Opus 4.8	f7a9549cd1	chore(licensing): LGPL FFmpeg swap, third-party notices, attribution hygiene ... The MIT OR Apache-2.0 SOURCE license is clean (audit found no copied copyleft); the gaps were all binary-distribution (Layer-2). This makes the shipped artifacts honest: - Windows host + client: bundled FFmpeg BtbN gpl-shared -> lgpl-shared (AMF/QSV/decode unaffected; the GPL-only x264/x265 were never used), and ship the FFmpeg LGPL notice + license text in the installer + MSIX (licenses/). - THIRD-PARTY-NOTICES.txt generated + bundled into installer/MSIX/deb/rpm. Offline generator (scripts/gen-third-party-notices.{py,sh}) + cargo-about config (about.toml/ .hbs) with a permissive-only accepted-license allow-list as a copyleft regression gate. - Reword the win32u GPU-preference hook comments to reflect independent reimplementation (no Apollo/Sunshine GPL-3.0 source copied). - README dual-license + inbound=outbound contributor clause + non-affiliation trademark disclaimer; new CONTRIBUTING.md. - LICENSE files into the standalone driver + vk-layer workspaces; deb copyright holder aligned to "unom and the punktfunk contributors". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:20:38 +00:00
enricobuehlerandClaude Opus 4.8	658d6ce1b8	fix(client/pkg): ship 32MB UDP recv-buffer sysctl with the Linux client ... The client asks the kernel for a 32 MB SO_RCVBUF, but the kernel silently clamps it to net.core.rmem_max — whose default is far too small. A too-small recv buffer is the dominant client-side wall above ~1 Gbps. Measured live (Fedora host -> two clients, real 2.5G LAN, GSO off): a client capped at 4 MB rmem_max dropped 31.6% of a 2 Gbps stream at the receiver, while a 32 MB client delivered the same 2 Gbps at 0.0% loss. The host already shipped this tuning; the client packages didn't (the RPM's %post even referenced the host-only file), so a client-only install streamed lossy at high bitrate. Add scripts/99-punktfunk-client-net.conf (rmem/wmem = 32 MB, distinct filename so host+client can coexist) and ship+apply it from both the .deb (build-client-deb.sh) and the RPM client subpackage (install, %files client, %post client). For reference the full ladder (punktfunk speed-test): 0% loss to 1.5 Gbps on a 4 MB client; 31.6% at 2 Gbps on 4 MB vs 0% at 2 Gbps on 32 MB. iperf3 put the raw link at ~2.35 Gbps TCP / ~2.4 Gbps UDP, so the stack now tracks the wire given a big enough recv buffer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-14 08:45:19 +00:00
enricobuehlerandClaude Fable 5	7bda3d8059	ci(packaging): punktfunk-client .deb + RPM subpackage ... Hook the Linux client into the existing packaging CI: - deb.yml builds both binaries and publishes punktfunk-host AND punktfunk-client to the Gitea apt registry; new packaging/debian/build-client-deb.sh mirrors the host script (shlibdeps auto-Depends — GTK4/libadwaita/SDL3/FFmpeg/PipeWire sonames; no NVIDIA filter, the client links no CUDA). Built and inspected locally on Ubuntu 26.04. - punktfunk.spec gains a "client" subpackage (binary + desktop entry + udev rule); rpm.yml's publish loop picks it up unchanged. - New shared assets: packaging/linux/io.unom.Punktfunk.desktop and scripts/70-punktfunk-client.rules — DualSense hidraw uaccess (USB + Bluetooth, steam-devices style) so SDL's HIDAPI driver gets touchpad/motion/lightbar/triggers instead of degrading to evdev. - Builder images learn the client link deps (rust-ci already had them; fedora-rpm adds gtk4/libadwaita/SDL3-devel) with idempotent install steps in deb.yml/rpm.yml since jobs run against the previous push's image. Workspace check CI (build/clippy/test) already covers the crate since a601022. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-06-12 23:18:12 +00:00