selkies-core
| Version | 2026.170.2327 |
| Repo | superproject |
Single shared streaming spine for every selkies flavor; supervises the desktop’s Chrome for both labwc and KDE. Compositor-agnostic core of the selkies streaming desktop: the pixelflux WebRTC transport (selkies) plus the shared desktop fixings every flavor (labwc, KDE Plasma) needs — Chrome + CDP, fonts, the wl-* pixelflux screenshot/record/overlay tooling, accessibility introspection, an X terminal, the terminal-recording stack, and sshd. There is NO compositor here and NO compositor-specific panel/notifier — those live in the per-flavor metalayer (selkies-desktop for labwc; selkies-kde-desktop for KDE Plasma). This is the single shared spine consumed by BOTH flavors across ALL GPU configs, so the streaming transport + fixings are defined exactly once (R3 — no duplication, no -host/-pod siblings).
selkies-core’s OWN contribution on top of the composed candies is the supervised [program:chrome] launcher: it bakes the chrome program into the assembled supervisord config and keeps the browser alive for both flavors, where the former per-flavor fire-once autostart only ever passed by racing Chrome’s brief alive window. The scenarios below assert that baked supervisor entry (build scope) and that the supervised browser stays up with a responsive CDP endpoint after the nested-compositor startup-race settles (deploy scope).
Services
Section titled “Services”chrome
Acceptance plan
Section titled “Acceptance plan”This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.
| Intent | Step |
|---|---|
check |
the assembled supervisord config carries selkies-core’s own [program:chrome] launcher entry |
check |
that supervised entry execs the chrome-wrapper launcher (self-synchronizing — it polls for the nested compositor’s wayland-0 socket) |
check |
the init system reports selkies-core’s supervised chrome program as RUNNING |
check |
25s after deploy Chrome is still alive and its internal CDP endpoint on 9223 answers in-container, proving supervisord relaunched the browser past the nested-compositor self-exit instead of the bed merely racing its brief alive window |
check |
file=/etc/supervisord.conf |
check |
the supervised Chrome browser launched with –no-first-run (the first-run “welcome / make Chrome default” dialog is suppressed) and –start-maximized |
check |
the supervised Chrome window actually fills the streamed virtual screen (maximize took effect, not merely the flag) |
check |
the streamed desktop frame is real composited content, not an all-black / uniform frame — a deterministic frame-content guard so the bed cannot false-green on a blank stream |