Al lanzar COSMIC, sus 30 raíces fallaron de golpe con «spawn cargo vendor: No such file».
Medido:
worker: cargo AUSENTE · rustc AUSENTE · go AUSENTE
hub: cargo ✓ · rustc ✓ · go ✓
hammer invoca `cargo vendor` en el HOST, no dentro del sandbox — el vendoreo pasa ANTES de
entrar a la caja. El worker no trae toolchain de Rust ni Go ⇒ la granja no puede construir
NINGUNA receta Rust o Go: COSMIC entero, las 228 Rust del corpus y las 362 Go. **El 76% del
catálogo sólo puede construirse en el hub**, que es UNA SOLA MÁQUINA — justo lo que el respaldo
de ayer intentaba dejar de asumir.
ESTO EXPLICA HACIA ATRÁS todos los «no construyó» de esta campaña (amp, anew, apko, atlas, bom,
broot, cargo-audit, cargo-hack, git-absorb). Yo lo atribuí a «necesitan red para sus módulos» y
lo escribí así en el SDD 23 y en memoria. Era falso: **falta el binario**, no la red.
Y ARREGLARLO NO ROMPE LA HERMETICIDAD: cargo/go aquí son herramientas de FETCH, del mismo orden
que `git` para clonar — se usan para traer y fijar deps ANTES del build, no dentro del sandbox.
Instalarlos en la imagen golden no relaja el aislamiento; el build sigue ocurriendo en la caja
con el árbol ya vendoreado. Es lo contrario del caso «no engordar el rootfs del worker», que
habla del rootfs DEL SANDBOX.
⇒ Decisión de aprovisionamiento, no de arquitectura, y desbloquea tres cuartas partes del
catálogo para la granja.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
perl-xml-parser, libpcap, libnl, lm-sensors, libxkbcommon, vulkan-loader y dbus — las siete
sombras de incoming-kde cuyas deps sí estaban al día, o sea el origen de la deriva. 7 de 7
selladas, sin un solo fallo: confirma el diagnóstico de que no había muro técnico, sólo
artefactos que nadie había reconstruido.
Quedan 79, todas aguas abajo. En vez de ir ola por ola se lanzó la construcción de las 11
RAÍCES del perfil y hammer resuelve la clausura solo — que es para lo que sirve el grafo de
deps y evita adivinar el orden a mano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Diagnóstico completo. No es daño de la campaña del split ni un fallo de store-gc.
LO MEDIDO, en orden:
1. 86 nodos del perfil sin artefacto en su hash vigente.
2. NO lo causó el split: revertidas una por una todas las recetas tocadas hoy (3 bibliotecas
base, 30 hojas, dbus, 38 de la 2ª tanda) el número NO se movió de 198 en ningún caso.
3. La FRONTERA son 7 recetas —las únicas cuyas deps sí están al día—: dbus, libnl, libpcap,
libxkbcommon, lm-sensors, perl-xml-parser, vulkan-loader. Las otras 79 cuelgan de ellas.
4. Las 7 son SOMBRAS de incoming-kde, no las canónicas. Las del corpus están al día, y por eso
el problema es INVISIBLE desde el grafo del corpus — que es justo el que yo miraba.
5. No fue store-gc: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres nunca
se podaron. (Lo sospeché porque la regla de «superado» es por NOMBRE y una sombra comparte
nombre con la canónica; la sospecha era razonable y los manifiestos la descartan.)
6. Ni el hub ni el worker los tienen. No están en otro sitio: NO ESTÁN.
LA CAUSA DE FONDO, que importa más que KDE: la cola se construyó en workers EFÍMEROS, el sync
del store es unidireccional (worker→hub) y esos workers ya no existen. Cuando algo del sustrato
compartido cambió después, las sombras se re-hashearon y nadie las reconstruyó, porque el hub
nunca fue la máquina donde vivía ese escritorio.
⇒ Con flota efímera y sync unidireccional, un escritorio puede dejar de ser
reconstruible-desde-el-store SIN QUE NINGÚN INDICADOR LO DIGA. El grafo seguía reportando
162/162 desde un JSON generado semanas antes.
Coste de arreglarlo: 86 reconstrucciones en la granja, empezando por las 7 de la frontera. No
hay muro técnico conocido — son recetas que ya construyeron. Es cómputo, no investigación.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Al desplegar la 2ª tanda de hojas noté 198 recetas de las colas de escritorio sin artefacto
vigente (KDE 133, GNOME 37, COSMIC 24) y asumí que las había roto yo. **No.**
LO VERIFIQUÉ REVIRTIENDO, una causa por vez: las 3 bibliotecas base (expat, zstd, ncurses), las
30 hojas de la 1ª tanda, `dbus`, y las 38 de la 2ª. **El número no se movió de 198 en ningún
caso.** Y mirando el histórico, `escritorio-kde` está en 76/162 en TODOS los commits recientes
—09:10, 09:41, 10:12, 10:44, 11:16, 11:49— o sea desde antes de que la campaña empezara.
EL ERROR FUE MÍO Y DE MÉTODO: escribí «KDE cierra 162/162» leyendo
`docs/state/build-state-kde.json` **sin regenerarlo**. Es un fichero GENERADO, y un generado que
no se regenera es una foto vieja con aspecto de dato fresco. El mismo tipo de fallo que citar el
«79%» midiendo otra unidad: el dato existía, lo que fallaba era de cuándo era.
⇒ Y hay un aviso de fondo para toda la sesión: **medí «cero daño colateral» sobre el grafo
`--wlr`, que sólo carga corpus + incoming-wlr.** Las colas de escritorio son INVISIBLES ahí, así
que ese «cero» era cierto en el grafo que miraba y no decía nada del catálogo completo. Para
juzgar impacto hay que cargar TODAS las colas.
Las 38 de la 2ª tanda quedan revertidas: hasta entender los 198 no conviene añadir cambios
encima. Las 30 de la 1ª y las 5 del piloto siguen puestas y verificadas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
base 51/51 · cli 74/74 · escritorio-sway 121/121. Cosecha verificada: cero artefactos en el
worker que el hub no tenga.
De la tanda: 25 de 30 selladas. Los 5 fallos, ninguno causado por el split:
· cargo-audit, cargo-hack, git-absorb — 'spawn cargo vendor': el grafo las clasifica como clase
`c` porque declaran compiler=gcc para sus deps de C, pero por dentro son Cargo. Filtrar por la
clase del grafo NO basta.
· hammerd — git privado por SSH (HUB-ONLY, como las de tawasuyu).
· coreutils — 'you should not run configure as root'. Esto NO lo causó el split: es DERIVA. La
receta llevaba tiempo sin poder construirse en el lab actual y nadie lo sabía porque su
artefacto viejo seguía en el store. Es exactamente lo que la campaña destapa.
⚠ Y de ahí sale un riesgo que conviene nombrar: cada receta que deja de reconstruir convierte su
artefacto viejo en un REHÉN — store-gc no puede podarlo (es el único ejemplar) y nadie puede
regenerarlo. Hoy son ~12 G inmovilizados, y crecen con cada receta que se rompe en silencio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`base`, `cli` y `escritorio-sway` bajaron a 50/51, 73/74 y 120/121 después de la cascada del
split, y los tres fallaban por LA MISMA receta: dbus.
EL ERROR NO MENCIONABA LA RED POR NINGÚN LADO:
meson.build:372:11: ERROR: Unhandled python exception
Y arriba, enterrado entre reintentos:
<urlopen error unknown url type: https>
WARNING: failed to download with error: name 'ssl' is not defined
dbus declara subproyectos con `.wrap` y meson intenta DESCARGARLOS. En el sandbox no hay red y
python no trae ssl ⇒ «Unhandled python exception», que se lee como un bug de meson y es
simplemente que no hay salida a internet. Y no debe haberla: el build es hermético a propósito.
`--wrap-mode=nodownload` obliga a usar las deps del sistema (nuestros artefactos, vía
pkg-config) y deja los wraps inertes. Mismo caso que `wl-clipboard` anoche.
⇒ base 51/51 · cli 74/74 · escritorio-sway 121/121. Los tres cierran otra vez.
ESTADO DE LA REPARACIÓN DE LA CASCADA: de las 54 que quedaron sin artefacto, 42 reconstruidas.
Las 12 restantes son EXACTAMENTE las que ya estaban en deuda antes de la campaña:
· 6 el muro del PIC (gtk4 y su cadena estática — duplicado superado de la dinámica de GNOME);
· 3 HUB-ONLY (mirada-*, llimphi-counter: git privado / commit en ceros);
· dwarves (libdw/musl), y adwaita-hello (error 39 = la carrera del ADR 0012).
O sea que la campaña no dejó deuda nueva.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Activar strip_debug en tres bibliotecas BASE (expat, zstd, ncurses) re-hasheó 54 recetas en
cascada, incluida la cadena wlroots/sway. Tocar cincuenta HOJAS no habría costado ninguna
reconstrucción extra. El desplegador ordena alfabéticamente y debe ordenar por profundidad en
el grafo, de hoja a raíz.
Y ADR 0012 —la carrera del árbol de fuentes, 'pendiente sin decidir' desde hace meses— acaba de
morder: adwaita-hello murió con error 39 (Directory not empty). Una reconstrucción masiva es
exactamente el escenario que lo dispara, así que decidirlo deja de ser opcional si la etapa 4
va a correr en paralelo.
Más dos lecciones de operación: un drenaje largo no puede vivir dentro del ssh (se cortó a las
14 de 54), y la flota efímera reusa IPs, así que la clave de host cambia y cada conexión grita
MITM — conviene que farm-up lo limpie solo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El §1.bis dijo «sí hay no-determinismo» porque appstream y bison divergían. También estaba mal,
y por un fallo de diseño del propio test.
`verificar-repro.sh` compara el artefacto GUARDADO contra una reconstrucción de hoy. Pero el
guardado puede tener meses: se construyó con OTRO estado del lab. El test conflaba dos cosas:
· NO-DETERMINISMO — mismas entradas, mismo lab, salidas distintas (rompe el invariante);
· DERIVA — el artefacto viejo no es lo que el lab de hoy produce (el mundo se movió).
LA PRUEBA QUE LAS SEPARA es construir DOS VECES HOY, y se dio sin querer: al reejecutar el
verificador sobre recetas ya reconstruidas, TODAS pasaron a reproducir.
anew ✗ diverge → ✓ REPRODUCE
gron ✗ diverge → ✓ REPRODUCE
age ✗ diverge → ✓ REPRODUCE (y en la 1ª ni instalaba los mismos ficheros: faltaba age-inspect)
⇒ EL CORPUS ES DETERMINISTA HOY. Lo que hay es deriva contra artefactos viejos.
QUÉ SIGNIFICA, sin adornos:
· El argumento de reproducibilidad para el split de debug SE CAE. El split se justifica por
ESPACIO (~60%), que sigue siendo real y grande. Nada más.
· Pero la DERIVA es un problema por derecho propio y mayor: el store contiene artefactos que el
lab de hoy no reproduciría, así que «nuestros artefactos son verificables por terceros» es
falso para parte del corpus — quien reconstruya no obtendrá lo publicado. `age` es el caso
feo: la reconstrucción ni siquiera instala los mismos ficheros.
· ⇒ La reconstrucción masiva SIGUE valiendo la pena, pero por otra razón: no para arreglar el
determinismo sino para PONER EL STORE AL DÍA CON EL LAB y que la promesa sea cierta.
Y otro hallazgo del mismo experimento: en el hub las recetas Go SÍ reconstruyen (0 fallos). Lo
que fallaba en el worker era la RED para bajar los módulos, no las recetas. Eso cambia el
bloqueante de la etapa 4: no es «Go no reconstruye», es «el worker no tiene red para módulos».
LA LECCIÓN, que es la misma tres veces en este documento: un test hay que diseñarlo contra la
PREGUNTA, no contra lo que es fácil de comparar. Comparar con lo que hay en el store es cómodo;
comparar dos builds de hoy es lo que contesta. El script queda anotado con esto en la cabecera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El «79%» que este plan y los SDD 19/20 venían citando era **el 79% del CONTENIDO BINARIO**,
medido sobre una muestra de .so/.a. Es cierto y es la cifra equivocada para planificar, porque un
artefacto no es sólo binarios: trae cabeceras, datos, iconos, locales, .pc y documentación, que
no encogen.
MEDIDO con `scripts/medir-debug.sh` (suma los tamaños reales de las secciones .debug_* vía
readelf -S y los compara con el tamaño del árbol, sin reconstruir nada):
40 artefactos · 876 MB · 27%
100 artefactos · 2955 MB · 38% (truncada a 60 ficheros/artefacto)
250 artefactos · 8874 MB · 60% ← la que manda: sin truncar, ~7% del store
La varianza es alta porque unos pocos artefactos grandes dominan el total, así que el número
necesitaba validación independiente — y la tiene: el piloto de la etapa 2, donde se reconstruyó y
se pesó de verdad, dio bison −50% y appstream −68%. Los dos ENCIERRAN el 60% de la muestra
grande. El modelo predice lo que el rebuild produjo.
CIFRAS CORREGIDAS, con el store en 127 G:
se venía diciendo medido
reserva de disco ~96 G ~76 G
store tras el split ~30 G ~51 G
espejo público ~30 G ~51 G
Sigue siendo el mayor ahorro disponible en el proyecto —76 G no es poco— pero no es lo
prometido, y la diferencia importa para dimensionar el alojamiento del espejo, que es una
decisión con factura.
LA LECCIÓN: una cifra medida sobre una cosa (contenido binario) se citó durante semanas como si
midiera otra (tamaño de artefacto), y llegó a tres documentos. El número no era falso; LA UNIDAD
sí. Cuando un número vaya a decidir un gasto, hay que volver a la medición original y comprobar
QUÉ estaba midiendo.
Corregido en los tres sitios donde se había propagado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decía «y por qué es la mitad de lo que se creía» y la etapa 1 demostró que son las dos mitades.
Un título que contradice su propio contenido es peor que uno vago: se lee primero y se recuerda
más.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ayer escribí en el SDD 23 que el `-ffile-prefix-map` global «se cancela porque su premisa es
falsa». **Era falso**, y la etapa 1 lo demostró en veinte minutos. Corregido en el §1.bis.
LA MEDIDA: `scripts/verificar-repro.sh` aparta el artefacto, reconstruye con las deps cacheadas
y compara con `why-differs`. Sobre las que pudieron reconstruirse: binutils ✓ y wl-clipboard ✓
reproducen; **appstream ✗ y bison ✗ DIVERGEN**. Causa idéntica en ambas:
difieren [.debug_aranges, .debug_info, .debug_pubnames, .debug_pubtypes, .debug_str]
— sólo info de depuración (el código ejecutable es idéntico)
· .debug_str sólo en B: /src/output/meson-private
DÓNDE ME EQUIVOQUÉ, exactamente: mi barrido buscaba rutas DEL HOST (/home/<user>/,
/tmp/<aleatorio>) y no halló ninguna nuestra — cierto. Pero el no-determinismo no venía de una
ruta del host sino de rutas INTERNAS al árbol de build (/src/output/meson-private) que varían
entre corridas aunque /src sea constante. Buscar la forma equivocada de ruta y no encontrarla no
prueba que no haya otra. Y una sola muestra que reproduce no es una muestra: leí `wl-clipboard`
como si probara más de lo que probaba, que es el error contra el que el propio documento
advertía dos párrafos antes.
Lo que me salvó fue haber puesto la PUERTA antes de la campaña en vez de después. Si hubiera
seguido mi conclusión, habría cerrado como «resuelto» un invariante roto.
🎁 Y de ahí sale la mejor noticia del plan: LAS DOS MITADES SON EL MISMO TRABAJO. La divergencia
vive ENTERA en secciones .debug_* y el código ejecutable es idéntico ⇒ separar el debug del
artefacto principal hace que el artefacto principal REPRODUZCA, sin tocar -ffile-prefix-map en
720 recetas. Queda decidir qué hacer con el contenido del paquete -debug, pero eso afecta a un
artefacto secundario que nadie instala por defecto.
El script queda como herramienta: muestra por clase de build (C, Rust, Go: el no-determinismo
suele vivir en codegen paralelo y orden de símbolos, no sólo en C), y RESTAURA el artefacto si
el rebuild falla — distinguir «no reproduce» de «no construye acá» importa, porque mezclarlos
inventaría un problema de determinismo que no existe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El usuario decidió hacer «ahora» el re-hasheo masivo. Lo primero fue verificar la premisa, y no
se sostuvo: **el `-ffile-prefix-map` global no hace falta**. Se ahorran días de granja y un
re-hasheo de ~720 recetas.
EL PLAN HEREDADO decía «92 paquetes con no-determinismo probable, todos por rutas /src en
.debug_». Tres medidas, de fuerza creciente, lo desmontan:
(a) Las rutas `/src` son CONSTANTES: el lab bindea el árbol de fuentes en /src literal, así que
una ruta embebida en .debug_ es idéntica en cada rebuild y en cualquier máquina. Parece
sospechosa y es fija.
(b) Barrido de 195 artefactos buscando rutas que SÍ variarían (/home/<user>/, /opt/hammer/work,
/tmp/<aleatorio>): 15 las tienen, y ninguna es nuestra —
· /home/buildozer/aports/main/musl/src/musl-1.2.6 = la ruta de compilación DE ALPINE,
horneada en el musl prebuilt que inyectamos;
· /tmp/apiresponse.json = una cadena literal en el fuente de gron;
· /home/jimmac/, /home/sam/dev/ = rutas de los autores en los assets SVG de adwaita.
(c) LA PRUEBA QUE DECIDE: apartar el artefacto de wl-clipboard, reconstruir con deps cacheadas y
comparar con `hammer why-differs` → «24 entradas idénticas · 0 divergen · REPRODUCE».
La lección de método vale más que el ahorro: el no-determinismo se mide RECONSTRUYENDO Y
COMPARANDO, no buscando cadenas sospechosas. Un grep sobre binarios da candidatos, no veredictos
— misma clase de error que la regla del `.a` no-PIC (contaba reubicaciones de .debug_*) y que el
conteo de licencias con `grep -l license` (contaba comentarios). El proyecto YA tenía la
herramienta del veredicto; lo que faltaba era usarla antes de planificar.
QUEDA EL SPLIT DE DEBUG, que sí es real: el 79% del contenido binario del store son secciones
.debug_ ⇒ ~96 G de reserva y el espejo público de 126 G a ~30 G, que toca la decisión ya tomada
de servirlo desde el Storage Box.
🧨 Y APARECIÓ ALGO QUE CONDICIONA EL CÓMO: el entorno del lab NO ESTÁ HASHEADO. sandbox.rs fija
CC/-mcpu=baseline, SOURCE_DATE_EPOCH, TZ, LC_ALL, AR y codegen-units para TODOS los builds, y
ninguna entra en hash_inputs. ⇒ Cambiar el entorno del lab cambiaría lo que sale del build SIN
mover un solo hash: el store diría que todo está al día mientras los artefactos ya no
corresponden. En un sistema direccionado por contenido ese es el peor fallo posible: no falla,
miente. Hoy no muerde porque ese entorno no cambia nunca — y una campaña global es justo el
momento en que cambiaría.
Por eso el plan propone hacer el split en la fase `install` de cada receta (entra al hash por
diseño, auditable, re-hashea sólo lo que toca) y NO como flag del lab; más un ticket previo
chico: un `lab_version` en hash_inputs con el diseño de `zig_version` — sólo entra si está
fijado, así los hashes actuales no se mueven.
Cinco etapas con PUERTA cada una. La primera es verificación amplia de reproducibilidad (~30
recetas de clases distintas); si alguna diverge, ESO es el trabajo real y la campaña se pospone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
§II.1 decía «medido: no hay ninguno — de toda la familia sólo existen foot y mako». Ya no: 10
recetas selladas, 12 binarios, el perfil escritorio-sway cerrando 121/121 y ARRANCANDO en QEMU
con evidencia. La hipótesis que traía la sección —«son baratos, no hay torre de C debajo»— se
cumplió: KDE y GNOME fueron campañas de semanas, esto salió en una noche.
Y se añade la lección que corrige cómo hay que leer TODO el documento: el grafo prueba que una
imagen SE ARMA, no que ARRANQUE. Entre 121/121 y una pantalla con algo dibujado hubo SEIS
muros y ocho ciclos de imagen —PATH vacío, libz.so.1 ausente del rootfs, un backend de libseat
que nuestra receta no construye, /run de sólo lectura, los datos XKB, y la falta de
tipografías— y ninguno era una dependencia de build, así que ninguno podía salir en el grafo.
Con el método incluido, porque es lo que más se olvida: el veredicto es CONTAR COLORES del
PPM, no leer el log. Hubo un arranque con todo verde (salida activada, modo correcto, «Commit
of 1 outputs succeeded», workspace creado) y la captura 100% negra.
⇒ Corolario escrito en una sección nueva: cuando este documento diga que algo «cierra», hay que
leerlo como «se puede intentar», no como «funciona». Los tres escritorios que aún no se
validaron con pantalla deben esa misma distancia, y no conviene prometer fechas contra el
número del grafo.
waybar queda anotado como fuera-por-medición (gtkmm-3.0 = GTK3 + bindings C++ + 8 recetas), con
yambar en su lugar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`docs/evidencia/sway-qemu-2026-08-08.png`: 1280×800, **102 colores distintos**, sway con foot a
pantalla completa y un prompt vivo, la barra de título del compositor arriba y el fondo
#1a4b8c asomando en los bordes. Sobre el kernel de hammer con arje-zero como PID1, sin X11 y
sin systemd.
EL VEREDICTO ES CONTAR COLORES, NO LEER EL LOG — y esta campaña lo demuestra sola: hubo un
arranque con TODO verde en el log (salida activada, modo 1280x800, «Commit of 1 outputs
succeeded», workspace creado) y la captura salía **100% negra**. Un compositor puede estar
perfectamente vivo y no pintar nada.
LOS SEIS MUROS, ninguno visible en un grafo de dependencias que decía 121/121:
1. `PATH` vacío — el console-getty no lo exporta y ni `mkdir` se encontraba. «mkdir: not found»
se lee como «falta busybox» cuando busybox está entero: mismo engaño que el exit 127 de meson.
2. `libz.so.1` AUSENTE del rootfs. El zlib del corpus es sólo estático; la compartida vive en
`zlib-shared`, en otra cola. Se cazó comparando los NEEDED del ELF contra el rootfs, no
leyendo logs.
3. `LIBSEAT_BACKEND=builtin` NO EXISTE en nuestro libseat: `recipes/seatd.toml` construye con
`-Dlibseat-seatd=enabled -Dlibseat-logind=disabled`, o sea UN backend, confirmado con
`strings`. La receta manda sobre lo que uno cree recordar del proyecto — y la misma receta
traía la salida: `-Dserver=enabled` construye `seatd-launch`.
4. `/run` de SÓLO LECTURA. La raíz de hammer es inmutable por diseño, y sway moría con «unable
to open lockfile … check permissions», que suena a permisos de directorio y era un
filesystem read-only. Se resolvió montando un tmpfs, que es lo que hace cualquier init.
5. `xkeyboard-config` — «failed to add default include path /usr/share/X11/xkb». Es EXACTAMENTE
lo que dejé anotado en la receta de swaylock: «para que el teclado tenga distribución en una
imagen real hará falta incluirlo por el lado del perfil». Apareció donde se dijo.
6. SIN TIPOGRAFÍAS no hay terminal. `fcft: failed to match font` → `failed to load primary
fonts`: foot arrancaba y no dibujaba. `dejavu-fonts` estaba en el catálogo pero en otra cola.
Va en la lista de §I.5 del SDD 20 («tipografías») y acá se ve por qué no es un detalle.
Y un fallo de MÉTODO que costó dos ciclos: mandé el log de sway a /var/log/sway.log DENTRO de
la VM, así que la primera captura negra vino sin una sola línea que la explicara — el
diagnóstico estaba dentro de la caja que no arranca. Un log que no se puede leer desde fuera no
es un log. Ahora va al serial.
Los `exec` de la config de sway disparan ANTES de que exista el workspace (0,259 s vs 0,305 s)
y mueren con «Failed to create launch context. No workspace». Los clientes se lanzan desde
sway-start esperando el socket de Wayland, que es la condición real.
Andamiaje reutilizable en scripts/wlr/: qemu-sway-image.sh (hermano del de COSMIC, sin logind
ni dbus, que sway no necesita), sway-start.sh y sway-config.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Declarado en targets.toml y verificado con el grafo: **121 nodos, 121 sellados, falta 0**. Es
una imagen construible hoy, no una intención.
Nueve raíces (sway, yambar, fuzzel, swaybg, swaylock, swayidle, grim, slurp, wl-clipboard) más
`hereda = ["cli"]`, porque un WM sin userland debajo no se usa: hacen falta la terminal y las
herramientas. `foot` no se lista porque ya entra por la clausura de `cli`. El resto de la
imagen —wlroots, mesa, wayland, libinput, seatd, cairo, pango, fcft…— lo calcula el grafo
siguiendo las aristas: escribir la clausura a mano es justo lo que targets.toml existe para
evitar.
LA COMPARACIÓN QUE VALE: KDE y GNOME fueron campañas de semanas porque debajo tienen una torre
de C (Qt entero, GTK, la cascada de mesa). Esto es una decena de binarios pequeños sobre
wlroots y salió en una noche. Ya estaba escrito en el SDD 20 como hipótesis —«los WMs ligeros
son la mejor relación esfuerzo/resultado que queda»—; ahora está medido.
`--wlr` en build-state.py, con su flag propio por la misma razón que COSMIC: sin él el frente
es INVISIBLE para el khipu, y `yupana radio` sobre una receta compartida (wayland, libinput,
pixman, mesa, libxkbcommon…) no reportaría la imagen sway entre las afectadas — o sea que el
próximo que toque una de ésas mediría de menos y creería que no rompe nada.
Queda lo que no puede decidir el grafo: probarlo en QEMU CON PANTALLA. La regla ya pagada cara
es que las imágenes de escritorio no se validan con `-nographic`, porque el compositor puede
«arrancar» en los logs y no pintar nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El handoff avisa que nada suyo está verificado contra hammer («si un dato de hammer lo
contradice, manda hammer»). Esto es esa verificación: contesta sus seis preguntas del §9 con
evidencia del código, corrige lo que estaba mal y añade dos objeciones que cambian el orden.
NO es aprobación ni plan de implementación.
EL HECHO QUE REORDENA TODO, y que el handoff no podía conocer: las FASES entran en
hash_inputs, y el config del kernel vive en la fase `configure` ⇒ **el config ES la identidad
del artefacto**. Corta en los dos sentidos. A favor: §2.2 (atestar un config por huella de
hardware) sale casi gratis, porque cada config ya es un artefacto direccionado por contenido,
reproducible y firmable — no hay que inventar el mecanismo. En contra: la explosión de builds
no es hipotética, es aritmética visible en el disco, que ya crece 24 G por ciclo. Y una
«perilla» de la UI no es un parámetro de runtime: es una edición de receta.
LAS SEIS RESPUESTAS:
P1 fragmentos — YA es como §6 prescribe: defconfig + `scripts/config -e/-d` + olddefconfig,
o sea que la app nunca escribe un .config. Media implementación está en producción. Falta
el diff-back, sin el cual un símbolo pedido que no sobrevive se pierde EN SILENCIO.
P2 repro con config variable — sí, por construcción: no hay un kernel cuya reproducibilidad
dependa de congelar el config; hay N kernels, cada uno congelado. Se pueden PREFIRMAR
artefactos, no sólo configs.
P3 tiempo — 35/45/60 min según receta ⇒ la bisección de §5 son ~4,5 h de la máquina que
acaba de no arrancar. Mata la bisección ingenua.
P4 harkaq — el patrón sí, el código no: su clausura enumera fichero a fichero sobre
artefactos del store, semántica de rutas. Kconfig es otro grafo.
P5 eje huella en el índice — sí y compatible hacia atrás: PackageEntry usa campos serde
opcionales. Mismo truco que hizo pagable el campo `license` hoy.
P6 PLAN-KIKIN §4.bis — DADO POR PENDIENTE Y ESTÁ HECHO EN DOS DE TRES: linux-metal y
linux-generic ya declaran los cuatro símbolos; sólo `linux` deja IO_URING y BPF_SYSCALL
al azar del defconfig. Y ojo al método: `grep IO_URING` da positivo por un COMENTARIO;
hay que mirar los -e/-d dentro del bloque configure. Mismo error que infló el conteo de
licencias hoy y que hace mentir la regla del `.a` no-PIC.
OBJECIÓN a §2.1: «clausura» sobre Kconfig no está definida todavía. Hay tres tipos de arista
(`depends on`, `select`, `imply`) con semánticas incompatibles, y `select` fuerza símbolos
IGNORANDO los `depends on` del destino. «Alcanzable desde CONFIG_WIRELESS» da conjuntos
distintos según la arista y ninguno es la respuesta. No lo invalida: lo convierte en la parte
con contenido técnico real. Y hay con qué validarlo GRATIS: el config actual de linux.toml
YA es un juego de bundles N1 hecho a mano («-d WLAN -d WIRELESS -d CFG80211 -d MAC80211
-d RFKILL» es literalmente «no necesito wifi») sobre un kernel que arranca.
LO QUE AGREGO:
· Bisección SIN recompilar: kernel «superset» con lo bisecable como módulo ⇒ los bundles de
hardware se prueban con lista de bloqueo en la línea de arranque. 6 reinicios en vez de 6
rebuilds. No cubre lo que debe ser =y (buena parte de N2), y el superset es el kernel gordo
que N1 quiere evitar: es diagnóstico, no el de todos los días.
· El gate de no-regresión debe ser POR OBJETIVO: linux.toml apaga USB/HID/INPUT a propósito
(es el kernel de QEMU con consola serie) y un gate global rechazaría una receta sana.
· «Booteó» no basta para atestar: un kernel arranca y te deja sin red, que es el desastre que
el propio gate quiere evitar. La atestación debe llevar QUÉ se comprobó — el mismo dato que
calcula el gate: una implementación, dos usos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los identificadores obsoletos (`GPL-2.0`, `LGPL-2.1`, `AGPL-3.0`) no dicen si el proyecto
concede «sólo esta versión» o «ésta o cualquier posterior», y eso decide con qué se puede
combinar el paquete y bajo qué términos puede redistribuirlo quien lo reciba.
NO SE PUEDE MIRAR EL COPYING, que es la trampa evidente: el texto de la GPL es IDÉNTICO en
los dos casos —es la licencia, no la concesión— y encima su apéndice «cómo aplicar la
licencia» contiene literalmente «or (at your option) any later version», así que buscarla
ahí da SIEMPRE positivo y parece evidencia siendo plantilla. Misma trampa que la regla del
`.a` no-PIC, donde grep contaba reubicaciones de `.debug_*`. La concesión vive en las
cabeceras de los fuentes y en el README; ahí se busca, excluyendo los ficheros de licencia.
SE GUARDA LA CITA, no sólo el veredicto: fichero + frase exacta que decidió. Una licencia es
una afirmación legal y quien la revise tiene que poder ver POR QUÉ dice lo que dice sin
repetir el trabajo.
Y eso pagó de inmediato: de las 12 primeras resoluciones, TRES eran evidencia inválida y
sólo se vieron porque estaba la cita. Cada una de una clase distinta:
· caligula — la frase salía de `checks/headless/expected.iso`, un FIXTURE DE TEST;
· libnl — de `include/linux-private/linux/seg6.h`, una cabecera del KERNEL vendorizada.
La licencia del kernel no es la de libnl;
· lm-sensors — declarado GPL-2.0 y la cita decía «version 2.1 of the License», que es la
LGPL. La frase era real pero no sostenía lo que se le atribuía.
Las tres clases quedan filtradas en el script: ficheros de licencia, rutas de test/fixture, y
código vendorizado; más una comprobación nueva de que **la cita hable de la misma versión que
la licencia declarada**.
Sembradas las 9 auditadas (13 ficheros; algunas viven en varias colas). Ambiguas: 55 → 41.
Las 40 sin evidencia quedan listadas y siguen contadas — la mayoría son Go y la familia
cosmic, donde la frase no aparece fuera del COPYING.
Hashes verificados: 0 movidos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergio
