5 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	e568513f74	fix(web): retry the console image's dependency install once ... A single failed tarball kills `bun install` and takes the whole image build with it. Seen in CI as: error: Fail extracting tarball for "@rolldown/binding-linux-x64-musl" — a 7.7 MB optional binding that bun fetches on any linux-x64 host (the lockfile records `os`/`cpu` but no libc, so the musl and glibc bindings are equally eligible) and that had arrived truncated. The lockfile is NOT at fault, which is worth recording because it is the obvious suspect: `bun install --frozen-lockfile` accepts it, regenerating it with bun 1.3.14 — the version in the failing log — is byte-identical, the tarball downloads and extracts cleanly, and this exact layer builds green for `--platform linux/amd64` with `--no-cache`. So this is a transient-download guard, not a lockfile fix: two attempts with a pause, then fail for real. It recovers a truncated download and deliberately does NOT paper over a runner that is out of disk, which fails identically every time.	2026-08-13 16:52:12 +02:00
enricobuehler	185a69c806	fix(web/plugins): a plugin's interface loads again, instead of an empty panel ... Two separate things had to be wrong for this, and both were. The frame's own policy locked it out. Plugin UIs moved to their own origin so a plugin cannot act as the logged-in operator, and the plugin origin names the console as the only page allowed to frame it. It built that name from the incoming request — but Nitro hands the app a synthetic request with no TLS socket, so an HTTPS console reads back as `http:`. The header said `frame-ancestors http://host:47992` while the operator was on `https://host:47992`, and the browser refused the frame outright (ERR_BLOCKED_BY_RESPONSE). Nothing on screen said so; the reason was only in devtools. The scheme now comes from the listener's own TLS state, stamped at bind time, with x-forwarded-proto winning when something in front terminated TLS for us — the one case where the browser's scheme is not ours. And the port was shut. 47993 was added to the firewall definitions, but an already-open firewall does not pick a new port up: ufw expands an app profile into rules when you allow it and keeps those, so editing the profile on upgrade changes nothing, and firewalld needs a reload. Every upgraded Linux host kept a 47992-only rule, silently. The packages now notice on upgrade and print the one command that fixes it, without touching the running firewall. The NixOS module and the container image never learned the port at all; both now open it. Also: the console no longer mounts the frame while it is still checking whether that origin is reachable. A firewalled port drops rather than refuses, so the check hangs for the browser's whole connect timeout, and mounting meanwhile is exactly the empty panel with no explanation. The card that follows now names both causes it can be — an untrusted certificate for that port, or a closed one — because from a browser the two are indistinguishable. The rule is now a pure function with tests, since its failure mode is a well-formed header that only a browser rejects. Verified on glass against home-worker-5 (.21) and its ROM Manager plugin: the frame was refused before, renders the plugin's UI after.	2026-08-06 22:33:57 +02:00
enricobuehlerandClaude Fable 5	af74c9ca67	feat(web,host/windows): move the web console off :3000 to :47992 ... Port 3000 collides with half the dev-server ecosystem; 47992 sits next to the mgmt API (47990) in the punktfunk port family. Updates the run scripts, systemd/scheduled-task units, Dockerfile, Windows firewall rule + installer, packaging, and every doc that referenced :3000. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 18:17:42 +00:00
enricobuehlerandClaude Opus 4.8	0925f1aaa1	fix: complete the docs/→design/ and openapi→api/ rename references ... The file moves (docs/ → design/, docs/api/openapi.json → api/openapi.json) landed in 8897286, 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
enricobuehlerandClaude Fable 5	a5ba9d9459	feat(ci): Gitea Actions — dockerized web/docs/rust-ci images, Apple client CI, Mac runner ... Three workflows: ci.yml (Rust workspace inside the punktfunk-rust-ci builder image + web/docs-site build+typecheck), docker.yml (build+push punktfunk-web, punktfunk-docs, punktfunk-rust-ci to git.unom.io — host and native clients stay un-dockerized by design), apple.yml (host-mode macos-arm64 runner: Rust core -> PunktfunkCore.xcframework -> swift build + swift test). ci/rust-ci.Dockerfile: Ubuntu 26.04 with the workspace's link deps (FFmpeg 8, PipeWire, Opus, GL/EGL/GBM, xkbcommon, libcuda via the 580-server userspace as a link stub) + pinned rustup + node for the JS actions. Verified end to end in-container: build, 141/141 tests, C ABI harness; all three images seeded to the registry manually. scripts/ci/setup-macos-runner.sh provisions the Mac (rustup + darwin targets, Node tarball, gitea-runner 1.0.8 host mode, LaunchAgent with DEVELOPER_DIR auto-detect for sudo-free Xcode selection). Docs in docs-site/content/docs/ci.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-06-12 12:28:13 +00:00