Sergio
3d79cdf98b
Los demonios de sistema pasan de lanzarse con `&` desde un script de 500 líneas a ser Cards del `genesis`. El bloqueo que este frente daba por corpus se levantó solo: otro agente selló evolution-data-server y gnome-shell mientras esto se escribía, y escritorio-gnome quedó 309/309. SE CORRIÓ UN CONTROL PRIMERO, y es lo único que hace interpretable el resultado: colord control: `MURIÓ al arrancar` cards: `ya vive (pid 175)` ColorManager control: `NO apareció en 40s` cards: `OK` login1/Accounts/UPower OK en los dos compositor wayland-0 y shell vivo en los dos El fallo del control DESAPARECIÓ, y no lo buscaba: colord moría arrancado por el script y vive arrancado por arje, con el bus ya listo porque la espera está dentro de su argv. Sin el control, «ColorManager OK» sería un dato suelto en vez de una diferencia. Los PIDs lo confirman: polkit=119, colord=175, upowerd=178, accounts=180 — de antes de que el lanzador de sesión existiera. QUÉ NO SE COMPROBÓ: no hay screendump; QEMU salió por timeout y el control tampoco lo tuvo. La comparación es serial contra serial y lo que se afirma es sobre los DEMONIOS, no sobre el pintado. Las piezas donde corresponde: `takana service-cards` (UNA sola implementación de receta→Card; el formato es contrato con card_core::Card), `targets.py --service-paths` (une qué-es con si-arranca), y un inyector en FICHERO APARTE porque anidar dos heredocs de python falló en vivo — el terminador del interno cerró el externo y media cosa corrió como shell. La espera del bus va DENTRO del argv de las 5 recetas de sistema: sin ella un daemon arranca antes de que dbus escuche y queda en modo idle sin registrar su nombre — un fallo que no se ve, porque el proceso vive y el bus no lo tiene. Los 5 hashes intactos. Y el guardia de gnome-start es por «¿está corriendo?», no por una perilla: así es correcto venga de donde venga el proceso y la misma copia sirve donde no se inyectaron cards.
31 lines
1.6 KiB
Python
Executable File
31 lines
1.6 KiB
Python
Executable File
#!/usr/bin/env python3
|
|
# inyectar-cards.py — mete las Cards de servicio de un perfil en el `genesis` de la seed (SDD 30 §4c).
|
|
#
|
|
# Por qué es un fichero y no un heredoc dentro del script de imagen: el script ya tiene un heredoc de
|
|
# python (el del console-getty) y anidar dos es la receta del error mudo — el terminador del interno
|
|
# cierra el externo y la mitad del programa se ejecuta como shell. Pasó al escribir esto.
|
|
#
|
|
# NO genera las Cards: las recibe ya emitidas por `takana service-cards`, que es la única
|
|
# implementación de la traducción `[[service]]` → Card. Acá sólo se COMPONE la seed.
|
|
import json, os, sys
|
|
|
|
seed_p, cards_p = sys.argv[1], sys.argv[2]
|
|
seed = json.load(open(seed_p))
|
|
cards = json.load(open(cards_p))
|
|
|
|
# Idempotente por `label`: re-armar la imagen no puede duplicar Entes. Dos Cards con el mismo label
|
|
# no son "dos servicios": para el grafo de arje son una colisión de identidad, y el segundo se
|
|
# perdería en silencio o pelearía con el primero por el mismo nombre del bus.
|
|
ya = {g.get("label") for g in seed.get("genesis", [])}
|
|
puestos = [c["label"] for c in cards if c["label"] not in ya]
|
|
seed.setdefault("genesis", []).extend(c for c in cards if c["label"] not in ya)
|
|
|
|
tmp = seed_p + ".new"
|
|
with open(tmp, "w") as f:
|
|
json.dump(seed, f, indent=2)
|
|
os.chmod(tmp, 0o644)
|
|
# Reemplazar la ENTRADA de directorio, no escribir en sitio: la seed del árbol fundido es un hardlink
|
|
# read-only al artefacto del store, y escribirle encima mutaría el store.
|
|
os.replace(tmp, seed_p)
|
|
print(" cards en el genesis:", ", ".join(puestos) or "(ninguna nueva)")
|