Files
punktfunk/packaging/rpm
enricobuehler 9f92dc505b
ci / web (push) Successful in 27s
ci / docs-site (push) Successful in 31s
apple / swift (push) Successful in 1m16s
ci / rust (push) Successful in 2m6s
ci / bench (push) Successful in 1m36s
docker / build-push (--build-arg FEDORA_VERSION=44, ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm) (push) Successful in 6s
docker / build-push (., web/Dockerfile, punktfunk-web) (push) Successful in 5s
docker / build-push (ci, ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 3s
docker / build-push (ci, ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 4s
docker / build-push (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 4s
deb / build-publish (push) Successful in 2m19s
rpm / build-publish (bazzite, punktfunk-fedora-rpm) (push) Successful in 4m51s
docker / deploy-docs (push) Successful in 17s
rpm / build-publish (fedora-44, punktfunk-fedora44-rpm) (push) Successful in 4m24s
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
..

punktfunk-host — RPM (Bazzite / Fedora Atomic) via the Gitea registry

punktfunk-host is published as an RPM to Gitea's RPM package registry in the public unom org (group bazzite), so Bazzite / Fedora Atomic hosts layer and update it with rpm-ostree. CI (.gitea/workflows/rpm.yml) builds and publishes on every push to main (a rolling 0.0.1-0.ciN.<sha> build) and on v* tags (a clean X.Y.Z-1). The RPM is built in the Fedora 43 image (ci/fedora-rpm.Dockerfile) so its auto-generated library Requires (libavcodec.so.NN, …) match Bazzite's sonames; the NVIDIA driver lib (libcuda.so.1) is excluded — NVENC/EGL come from whatever NVIDIA stack the host runs (a weak Recommends).

This is the same package as the COPR / bootc paths — same spec (punktfunk.spec) — just self-hosted in Gitea instead of COPR, mirroring the Debian/apt setup.

Install on a Bazzite host (one-time)

# Add the repo. Our RPMs are unsigned, but Gitea GPG-signs the repo METADATA — so verify that
# (repo_gpgcheck=1) and skip the per-package signature check (gpgcheck=0). The signed metadata
# carries each package's SHA256, so authenticity still holds. (Don't just curl Gitea's served
# bazzite.repo — it sets gpgcheck=1, which fails on unsigned packages.)
sudo tee /etc/yum.repos.d/punktfunk.repo >/dev/null <<'REPO'
[gitea-unom-bazzite]
name=punktfunk (unom, Bazzite)
baseurl=https://git.unom.io/api/packages/unom/rpm/bazzite
enabled=1
gpgcheck=0
repo_gpgcheck=1
gpgkey=https://git.unom.io/api/packages/unom/rpm/repository.key
REPO

# Layer the package, then reboot into the new deployment.
rpm-ostree install punktfunk
systemctl reboot

If rpm-ostree can't complete the metadata GPG check non-interactively, set repo_gpgcheck=0 (TLS-only trust to the self-hosted registry). Proper per-package signing (gpgcheck=1) would need a CI signing key + rpm --addsign — future hardening, not wired up.

After reboot, as the desktop user:

ujust add-user-to-input-group           # virtual gamepads need /dev/uinput (re-login).
                                        # Bazzite is atomic — use ujust, NOT `usermod -aG input`.
mkdir -p ~/.config/punktfunk
cp /usr/share/punktfunk/host.env.bazzite ~/.config/punktfunk/host.env   # gamescope defaults
systemctl --user enable --now punktfunk-host

(See ../bazzite/README.md for the full appliance walkthrough — udev/group, host.env, the Steam session unit, firewall, verify.)

Updates

rpm-ostree upgrade            # pulls the newest punktfunk with the system update
systemctl reboot             # rpm-ostree changes apply on reboot

Layered packages are re-resolved against their repos on every rpm-ostree upgrade, so the box tracks new builds automatically (Bazzite's auto-update timer does this for you). To pin or stop tracking: rpm-ostree override / rpm-ostree uninstall punktfunk.

Build an RPM locally

PF_VERSION=0.0.1 bash packaging/rpm/build-rpm.sh   # -> dist/punktfunk-0.0.1-1.fcNN.x86_64.rpm

Run it inside the Fedora 43 builder image so the deps resolve and match Bazzite:

docker build -f ci/fedora-rpm.Dockerfile -t punktfunk-fedora-rpm ci
docker run --rm -v "$PWD:/src" -w /src punktfunk-fedora-rpm \
  bash -lc 'git config --global --add safe.directory /src && PF_VERSION=0.0.1 bash packaging/rpm/build-rpm.sh'

A plain rpmbuild/COPR build with no pf_version/pf_release defines produces 0.0.1-1.