colord: el demonio ya se construye (b3:8100fa39) — arranca, abre sus DB y NO adquiere el nombre

La receta iba con `-Ddaemon=false` y el razonamiento era «mutter enlaza libcolord, no
necesita el demonio». Cierto para COMPILAR mutter y falso para el escritorio andando: el
artefacto INSTALA el `.service` de activación (`Exec=/usr/libexec/colord`) y ese binario no
existía, así que cada arranque se comía 25s de timeout. **No era «colord apagado» sino
colord roto de forma lenta** — el peor de los dos, porque no falla, tarda.

Su propio comentario marcaba la condición de vuelta: «si alguna vez hace falta el demonio
de verdad, vuelve con polkit encima». Polkit ya está (arje-polkit-compat). Y medido: prender
el demonio **no agrega una sola dep nueva** salvo polkit-gobject-1, ya sellada — el bloque
de dependency() de colord 1.4.7 es de nivel superior y pedía gusb/gudev/libudev igual con
daemon=false. El coste estaba pagado desde el 2026-07-27 sin que nadie lo cobrara.

**PERO EL TIMEOUT SIGUE**, y lo que aprendí es dónde NO está:
- El binario existe y arranca: `/usr/libexec/colord` crea sus tres bases en
  /var/lib/colord (mapping.db, storage.db) y lo dice en el log.
- Con `--verbose` NO hay una línea más después de abrir la tercera base.
- La política D-Bus SÍ permite `own` a root, y el `.service` corre como root: no es el caso
  de polkit (donde `own` estaba restringido al usuario `polkitd`).
- Los cuatro `cd_main_load_introspection` que van entre las DB y `g_bus_own_name`
  (cd-main.c:2434-2460) leen de un **GResource compilado en el binario**, no de disco, así
  que no pueden faltar. Los XML instalados en /usr/share/dbus-1/interfaces son para otros.

⇒ Queda entre `cd_main_load_introspection` y `g_main_loop_run`, y el siguiente dato es si el
proceso sigue vivo en ese momento. **Esa comprobación me faltaba en el script** — reportaba
«colord lanzado (pid N)» sin verificar nada, que es exactamente el error que yo mismo había
señalado para upowerd («un pid no es un servicio») y no apliqué acá. Ya está puesta: sin
ella, «no apareció el nombre» no distingue MURIÓ de SE COLGÓ, y son dos investigaciones
distintas.

Verificado que no hay regresión en lo que sí funciona: audio (48. HDA Intel, sink y source
reales) y vídeo (0 page-flips fallidos) siguen bien con el demonio en la imagen.

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

scripts/gnome/gnome-start-qemu.sh

@@ -271,9 +271,12 @@ fi
 # ADQUIRIÓ su nombre en el bus. Se le da tiempo y, si no aparece, se vuelca su log y la lista de
 # nombres del bus — que es el dato que dice si el problema es «no arrancó», «arrancó y no pidió el
 # nombre» o «lo pidió y se lo negaron».
+# $3 = décimas de segundo a esperar (default 20 = 10 s). colord necesita más: en el PRIMER arranque
+# crea sus tres bases de datos en /var/lib/colord y escanea los directorios de perfiles ICC antes de
+# pedir el nombre, y con 10 s daba «NO apareció» sin estar colgado — o sea un falso negativo.
 esperar_nombre() {
-  n="$1"; log="$2"; i=0
-  while [ $i -lt 20 ]; do
+  n="$1"; log="$2"; lim="${3:-20}"; i=0
+  while [ $i -lt "$lim" ]; do
     if dbus-send --system --dest=org.freedesktop.DBus --print-reply \
          /org/freedesktop/DBus org.freedesktop.DBus.NameHasOwner "string:$n" 2>/dev/null \
        | grep -q "boolean true"; then
@@ -282,7 +285,7 @@ esperar_nombre() {
     fi
     i=$((i+1)); sleep 0.5
   done
-  say "!! bus: $n NO apareció en 10s"
+  say "!! bus: $n NO apareció en $((lim/2))s"
   [ -n "$log" ] && [ -s "$log" ] && dump "$log"
   say "nombres en el bus de sistema:"
   dbus-send --system --dest=org.freedesktop.DBus --print-reply \
@@ -370,10 +373,35 @@ else
   say "!! sin /usr/bin/pipewire — el shell va a avisar 'Failed to connect context'"
 fi
 
+# colord: gestión de color (curva ICC por monitor). Mutter lo pide al arrancar y, si no está, se come
+# 25 s de timeout de activación D-Bus. Se lanza explícito por el mismo motivo que accounts-daemon y
+# upowerd: la activación por bus funciona (el launch-helper ya es setuid) pero deja el arranque
+# esperando, y lanzarlo a mano además deja un log donde mirar si no adquiere el nombre.
+if [ -x /usr/libexec/colord ]; then
+  # --verbose: su log normal se corta después de abrir las tres bases de datos y no dice nada más, así
+  # que sin esto un colord que no adquiere el nombre es indistinguible de uno que se cuelga.
+  CD_VERBOSE=1 /usr/libexec/colord --verbose >/tmp/colord.log 2>&1 &
+  CD_PID=$!
+  say "colord lanzado (pid $CD_PID)"
+  # ⚠ ESTA COMPROBACIÓN FALTABA, y es la misma que yo mismo escribí para upowerd: **un pid no es un
+  # servicio**. Sin ella, «colord lanzado (pid N)» + «bus: ColorManager NO apareció» no distingue
+  # MURIÓ de SE COLGÓ, que son dos investigaciones distintas. Es el hueco que dejó el diagnóstico de
+  # colord a medias.
+  sleep 2
+  if alive $CD_PID; then say "colord sigue vivo"; else say "!! colord MURIÓ al arrancar"; fi
+else
+  say "!! sin /usr/libexec/colord — mutter va a esperar 25s y seguir sin gestión de color"
+fi
+
 esperar_nombre org.freedesktop.login1 /tmp/logind-compat.log
 esperar_nombre org.freedesktop.PolicyKit1 /tmp/polkit-compat.log
 esperar_nombre org.freedesktop.Accounts /tmp/accounts-daemon.log
 esperar_nombre org.freedesktop.UPower /tmp/upowerd.log
+esperar_nombre org.freedesktop.ColorManager /tmp/colord.log 80   # 40 s: ver el comentario
+# El log de colord SIEMPRE, no sólo si falla el nombre: un daemon vivo que no adquiere su nombre es el
+# caso interesante y es justo el que se quedaba sin evidencia.
+say "colord :: log completo"
+dump /tmp/colord.log
 
 if [ "${DIAG:-1}" = 1 ]; then
   ulimit -c unlimited 2>/dev/null || true