🔇 wireplumber: construido, corriendo… y NO era el bloqueo

b3:b8f3baf0, selló a la primera. Arranca desde cosmic-start ("wireplumber OK (pid
192) — hay gestor de sesión"), se conecta al grafo (dos clientes en wpctl status) y
wpctl pasa a mostrar una sección Video que antes no existía.

Y el Start de ScreenCast SIGUE sin Response a los 60s. Mismo resultado exacto.

LA HIPÓTESIS QUEDA MATADA POR MEDICIÓN. "Falta el gestor de sesión que mueva el nodo
de Paused a Streaming" era mía y era razonable; no era cierta. Queda escrita junto a
su refutación porque una hipótesis descartada CON EVIDENCIA vale más que una lista de
sospechosos: acota el próximo paso a lo que queda, que es el backend mismo.

El dato nuevo, que es por dónde seguir: con wireplumber corriendo, `wpctl status`
lista `Video → Streams` VACÍO durante el handshake. O sea que el nodo
`cosmic-screencast` que SÍ existe en `pw-cli ls Node` no llega a wireplumber como
stream gestionado. Próximo movimiento: RUST_LOG=trace sobre screencast_thread, no
otra dep.

── por qué receta propia y no la de GNOME ──────────────────────────────────────
La de incoming-gnome funciona pero NEEDea libglib/libgobject/libpipewire de la ISLA
DINÁMICA de GNOME: traerla metería una segunda glib y una segunda pipewire en la
imagen. De 19 deps, 14 dan hash idéntico; las que divergen divergen a propósito —
sobre todo `pipewire`, que acá apunta a la de COSMIC (338d1d8c), la que el escritorio
realmente ARRANCA. Un gestor de sesión contra otra pipewire que la que corre no
gestiona nada.

El cambio de fondo es glib → glib-shared. COSMIC usa la glib ESTÁTICA del corpus, que
le alcanza al portal porque es un ejecutable. Acá no: wireplumber produce un .so y 17
módulos, y libglib-2.0.a tiene 44.275 reubicaciones R_X86_64_32/32S ⇒ no es PIC. La
regla del frente GNOME (readelf -r ANTES de gastar el build) ahorró uno.

Y la salida no fue una campaña nueva sino una MEDICIÓN: incoming-kde/glib-shared
copiada a esta cola resuelve al MISMO hash (0584ce1f) y ya estaba sellada ⇒ cero
rebuild. Idem pcre2-shared, lua y libelogind. Las dos glib coexisten sin pisarse (.a
y .so son ficheros distintos) y el portal conserva sus 3 NEEDED.

escritorio-cosmic: 84 → 89 recetas, 0 faltantes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/runbooks/cosmic-desktop.md

@@ -1090,6 +1090,46 @@ esperarlo. Es una hipótesis, no una medición — construir `wireplumber` la co
 - Y uno de shell, al automatizar por QMP: **`| head -N` bufferiza** y deja la terminal en blanco hasta
   que el programa termina. Parece que la sonda colgó cuando en realidad está esperando.
 
+## 🔇 wireplumber: construido, corriendo… y NO era el bloqueo (2026-08-05)
+
+`recipes/incoming-cosmic/wireplumber.toml` 0.5.15 → **`b3:b8f3baf0`**, selló a la primera. Arranca
+desde `cosmic-start` (`wireplumber OK (pid 192) — hay gestor de sesión`), se conecta al grafo (dos
+clientes en `wpctl status`) y `wpctl` pasa a mostrar una sección **Video** que antes no existía.
+
+**Y el `Start` de ScreenCast sigue sin `Response` a los 60s. Exactamente el mismo resultado.**
+
+La hipótesis de la sección anterior —«falta el gestor de sesión que mueva el nodo de `Paused` a
+`Streaming`»— **queda MATADA por medición**. Era mía y era razonable; no era cierta. Se deja escrita
+junto con su refutación porque una hipótesis descartada con evidencia vale más que una lista de
+sospechosos: acota el próximo paso a lo que queda, que es el propio backend.
+
+El dato nuevo, que es por dónde seguir: con wireplumber corriendo, `wpctl status` lista
+`Video → Streams` **vacío** durante el handshake. O sea que el nodo `cosmic-screencast` que sí existe
+en `pw-cli ls Node` **no llega a wireplumber como stream gestionado**. El próximo movimiento es el log
+del backend con `RUST_LOG=trace` alrededor de `screencast_thread`, no otra dep.
+
+### Por qué es una receta propia y no la de GNOME
+
+La de `incoming-gnome` está sellada y funciona, pero su binario NEEDea `libglib-2.0.so.0`,
+`libgobject-2.0.so.0` y `libpipewire-0.3.so.0` **de la isla dinámica de GNOME**: traerla tal cual
+metería una segunda glib y una segunda pipewire en la imagen. De las 19 deps, **14 dan hash idéntico**
+y las que divergen divergen a propósito — sobre todo `pipewire`, que acá apunta a la de COSMIC
+(`338d1d8c`), la que el escritorio realmente arranca. Un gestor de sesión contra otra pipewire que la
+que corre no gestiona nada.
+
+**El cambio de fondo es `glib` → `glib-shared`.** COSMIC usa la glib ESTÁTICA del corpus, que le
+alcanza a `xdg-desktop-portal` porque es un ejecutable. Acá no: wireplumber produce
+`libwireplumber-0.5.so` y 17 módulos, y `libglib-2.0.a` del corpus tiene **44.275 reubicaciones
+`R_X86_64_32/32S`** ⇒ no es PIC y no entra en un `.so`. (Regla del frente GNOME: `readelf -r` ANTES de
+gastar el build — acá ahorró uno.)
+
+La salida no fue una campaña nueva sino una **medición**: `incoming-kde/glib-shared.toml` copiada a
+esta cola resuelve al **mismo hash** (`0584ce1f`) y **ya estaba sellada** ⇒ cero rebuild. Idem
+`pcre2-shared` (`f254abaa`), `lua` (`e6c35f98`) y `libelogind` (`f1a690b2`). Las dos glib **coexisten
+sin pisarse** en el rootfs: `.a` y `.so` son ficheros distintos, y el portal conserva sus 3 NEEDED.
+
+Cierre: `escritorio-cosmic` pasa de 84 a **89 recetas**, 0 faltantes.
+
 ### El `-L/usr/lib` que pkg-config no da
 
 `pkg-config` **omite los `-L` de directorios que considera estándar del sistema**, asumiendo que el
@@ -1105,11 +1145,12 @@ existe, y eso cuesta igual que un bug.
 
 ## Lo que falta, en orden
 
-1. ~~Arrancar el demonio de pipewire~~ ✅ y ~~el cliente persistente~~ ✅ (`portal-probe`, `b3:af49d32d`).
-   **Lo que queda es `wireplumber`**: el stream de ScreenCast se crea y llega a `Paused`, con nodo
-   `cosmic-screencast` visible en pipewire, pero nadie lo pasa a `Streaming` y el backend no emite el
-   `Response`. La hipótesis es que falta el gestor de sesión — construirlo la confirma o la mata.
-   Falta también correr `portal-probe filechooser`, que ya puede capturar la URI.
+1. ~~Demonio de pipewire~~ ✅, ~~cliente persistente~~ ✅ (`portal-probe`, `b3:af49d32d`),
+   ~~`wireplumber`~~ ✅ (`b3:b8f3baf0`) — **y wireplumber NO era el bloqueo**: el `Start` sigue sin
+   `Response`. Lo que queda es el **backend mismo**: con `RUST_LOG=trace` alrededor de
+   `screencast_thread`, mirando por qué el nodo que sí existe en `pw-cli ls Node` no aparece como
+   `Video → Streams` en `wpctl`. Falta también correr `portal-probe filechooser`, que ya puede
+   capturar la URI.
 2. **Decidir `gvfs`** (ver la corrección de arriba: las piezas ya están selladas, lo que falta es la
    decisión sobre la segunda glib). Destrabaría los montajes remotos de cosmic-files y su applet.
 3. **Enchufar la tienda a `.swm`**: servir `org.freedesktop.PackageKit` y encender la feature

docs/state/targets.toml

@@ -137,6 +137,11 @@ paquetes = [
   # porque nadie la declara como dep y sin ella el perfil no incluiría con qué verificarse a sí
   # mismo — un handshake de portal sólo se puede ejercer DESDE la sesión, con bus y compositor vivos.
   "portal-probe",
+  # El GESTOR DE SESIÓN de pipewire. Se lista como raíz porque ningún `[deps]` lo alcanza: es un
+  # CLIENTE del demonio, no una librería de nadie. Trae consigo la glib COMPARTIDA (`glib-shared`),
+  # que no es la estática que usa el resto de la cola — wireplumber produce `.so` y la estática del
+  # corpus no es PIC. Construido y corriendo; NO desbloqueó ScreenCast (ver el runbook).
+  "wireplumber",
   # Datos, no binarios: el tema de iconos (y el hicolor del que hereda), las tablas de xkb y una
   # tipografía. Ninguno es dep de build de nadie y sin ellos el escritorio arranca roto — sin puntero,
   # sin teclado o con tofu.