Primera vez que el armador se usa para lo que existe, con artefacto real al final:
b3:8ffd57109a2f7102c1bbbbc91cf0e729047312eee1a4e3fdb8b178680cc94264-linux-gioser
linux-metal derivada gioser
bzImage 14,5 MB 11,1 MB (-23%)
símbolos encendidos 1805 1647
diff-back contra el artefacto ... 35 cumplidos, 0 INCUMPLIDOS
gate contra el artefacto ........ ningún dispositivo en uso sin driver
La base la eligió el probe, no la intuición: linux (el de QEMU) apaga USB, HID e INPUT a
propósito y gioser tiene xhci_hcd, usbhid e i8042 bindeados ⇒ linux-metal. 13 bundles y 3
perillas, 34 banderas, clausura de 3054.
Segunda validación de la clausura contra el olddefconfig real, ahora sobre otra base y con
13 bundles: 154 aciertos, SOBRA 0, faltan 18 (todos de la clase «apagado ahora ≠
inalcanzable» del §12).
LA PRUEBA DE 30 s PREDIJO EL BUILD DE 45 MIN. El .config del artefacto y el de la prueba en
seco difieren en 14 líneas y NI UNA es funcional: son las siete versiones del toolchain que
el kernel graba en su propio config (CC_VERSION_TEXT, GCC_VERSION, AS_VERSION, LD_VERSION,
RUSTC_VERSION, RUSTC_LLVM_VERSION, PAHOLE_VERSION). Cero símbolos de diferencia ⇒ la prueba
barata es un sustituto fiel para todo lo que el armador decide.
Y de regalo, la mecánica exacta de por qué el lab TIENE que estar en hash_inputs: el kernel
graba la versión de su compilador DENTRO del .config, y el .config va dentro del artefacto.
No es que el lab «influya» en el resultado — es que el lab está literalmente en el
contenido sellado. Se ve línea a línea: gcc 15.2.0 del lab anclado vs 16.1.1 del host.
PAHOLE_VERSION=0 confirma además lo que dice la cabecera de linux.toml.
La receta derivada NO se deja en recipes/: build-state.py y yupana barren recipes/ y
recipes/incoming-*, así que dejarla ahí la mete en el grafo compartido como deuda. Va en
docs/state/kernel-plans/ con el comando que la regenera; para construir se copia a
recipes/incoming-kernel/ temporalmente y se saca después.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El gate que había mira lo que apaga el PLAN, así que sólo ve regresiones que introduce el
plan: un hueco que ya venía en la receta base le pasa por debajo. El modo nuevo compara
DOS configs y define regresión como «funcionaba y dejó de funcionar», que es la
formulación literal del #6 del handoff:
hammer kernel gate --config <producido> [--baseline /proc/config.gz] --objective X
El referente por defecto es /proc/config.gz: el kernel que arrancó esta máquina es la
prueba viva de qué hace falta para arrancarla.
Y comparar DOS configs, en vez de mirar sólo el nuevo, mata de raíz un falso positivo que
tenía: los nombres de módulo cortos colisionan. El driver que /sys llama `usb` mapea a
QE_USB (el USB de las QUICC Engine de Freescale) y `port` a PORT_CHAN. Mirando sólo el
config nuevo aparecen como perdidos y el gate bloquearía un plan sano; exigiendo que
estuvieran encendidos en el referente, el falso positivo se cae solo. Con test.
Probado contra gioser (Hetzner vServer, 38 drivers bindeados) partiendo de linux-metal:
destapó cuatro pérdidas que NINGÚN bundle causaba — aer, iTCO_wdt, lpc_ich y pcspkr están
encendidos en el kernel que corre y linux-metal no los enciende nunca. El gate viejo no
podía verlas por construcción.
De paso, un mensaje que mandaba a buscar donde no está: sin culpable atribuido decía «lo
apaga una perilla», cuando la causa es que la receta base no lo enciende.
Catálogo, tres entradas nuevas nacidas de medir esta máquina:
· bundle sin-gpu-intel — DRM_I915 es de los drivers más grandes del kernel y no sirve en
una VM con virtio-gpu. NO apaga DRM: el vídeo sigue por simpledrm/EFI o virtio-gpu.
· knob invitado-virtio — VIRTIO_BALLOON y HW_RANDOM_VIRTIO no vienen en el defconfig y
ninguna receta del repo los enciende; en gioser los dos están BINDEADOS. Un kernel sin
ellos arranca, pero la VM pierde el globo de memoria y la entropía del anfitrión.
· knob plataforma-pc — PCIEAER, LPC_ICH, INPUT_PCSPKR y el watchdog ITCO_WDT. El
watchdog necesita además WATCHDOG, que linux-metal apaga a propósito: por eso va en una
perilla y no en la base. En una máquina sin acceso físico, el watchdog es lo que la
reinicia cuando se cuelga.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decision del usuario tras la medicion de los 4 kernels: dos labs con distinto
rustc producian bytes distintos en la MISMA direccion, y el store no tenia
como notarlo. Ahora el toolchain es una entrada del ArtifactHash.
QUE ENTRA: 29 paquetes del rootfs cuya VERSION puede cambiar los bytes —
compiladores/enlazadores (gcc, clang, llvm, binutils, rust, cargo), las libs
de codegen de gcc (gmp, mpfr4, mpc1, isl), el runtime que se enlaza (musl,
libgcc, libstdc++, libatomic, libgomp) y los headers que se compilan dentro
(linux-headers, fortify-headers). NO entra el rootfs entero: cada paquete de
mas invalida el corpus en cada bump, y con edge rodante curl se actualiza sin
que cambie una sola instruccion emitida.
Quedan fuera a proposito, y no es una afirmacion de que no influyan: los
autotools y las shells pueden cambiar ficheros generados. Es una decision de
coste. Si algun dia se ve una divergencia que rastree ahi, se anaden — y ese
dia el corpus se re-hashea otra vez.
DE DONDE SALE: del apk db del rootfs REAL (cfg.rootfs, que respeta
HAMMER_LAB/HAMMER_ROOTFS), no de docs/state/lab-toolchain.lock. El lock sigue
siendo el registro legible que viaja por git; hashearlo permitiria sellar con
un lab distinto del declarado. Derivar la ruta del padre del store se
descarto: esa suposicion ya rompio al worker cuando su store se anclo a un
volumen (ver defaults_for_store_with_lab).
SIN CAMINO SILENCIOSO: el parametro es obligatorio, no Option. Sin rootfs
falla y dice que hacer. Un default aqui reintroduciria la divergencia que
esto cierra.
Trae test de regresion de un fallo MUDO: la primera lista de prefijos llevaba
el guion de version (`gcc-`) y en el apk db el campo P: es solo el nombre
(`gcc`) ⇒ no casaba ninguno y la huella salia la del conjunto vacio. Un hash
valido, constante e inutil, que mirando el hash no se nota.
COSTE, medido y no estimado: sealed 768 -> 0, debt 777. Los 1745 artefactos
del respaldo quedan SUPERADOS, no perdidos. Ninguna imagen queda lista.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sealed 764 -> 768, deuda kernel=4 -> 0. Los cuatro reconstruidos en gioser y
subidos al respaldo.
La prueba pedida era: como el .config no cambia, el bzImage deberia salir
identico en una direccion nueva. NO sale identico, y la causa NO es la
receta.
Los cuatro dan la MISMA firma. El config instalado difiere en exactamente 4
lineas y ninguna es del cambio:
CONFIG_RUSTC_VERSION=109600 -> 109700
CONFIG_RUSTC_LLVM_VERSION=220103 -> 220108
Es rust 1.96 (laptop) vs 1.97 (gioser, resuelto de Alpine edge). Las lineas
de USB4/THUNDERBOLT/REISERFS son identicas viejo vs nuevo en las cuatro ⇒ la
correccion de receta es inerte, como se habia predicho. Y Rust NI SIQUIERA
ESTA ACTIVADO en estos kernels: Kconfig sondea el rustc del entorno y graba
su version igual.
Vale para las DOS ramas (6.16.12 y 7.1.2), asi que es del sistema, no de una
version de kernel.
Lo que esto destapa importa mas que el experimento: el toolchain del rootfs
NO esta en hash_inputs. Si no se hubiera tocado la receta, gioser habria
sellado bytes distintos en la MISMA direccion que el laptop, y el store no
tiene como notarlo. docs/state/lab-toolchain.lock avisa de la divergencia
pero no la impide.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hasta acá el armador era análisis puro: la clausura decía qué debía morir y nadie lo había
contrastado con el resolvedor real. NO hace falta construir un kernel para hacerlo: lo caro
es la fase compile (35-60 min); toda la cadena del armador vive en configure y corre en
segundos.
Método: árbol 6.16.12 entero, `make defconfig` de base (el config de linux.toml NO sirve de
base: ya apaga wifi/audio/fs a mano, así que el lado disable no apagaría nada y la
predicción no se pondría a prueba — fue mi primer error), el fragmento del plan, y
olddefconfig. Verdad de campo = los símbolos que pasaron de encendidos a apagados.
sólo depends on ....... clausura 1775 aciertos 64/68 SOBRA 0 falta 4
+ huérfanos select .... clausura 1794 aciertos 65/68 SOBRA 0 falta 3
+ comparaciones ....... clausura 1795 aciertos 65/68 SOBRA 0 falta 3
SOBRA 0 en las tres: el predictor nunca dice que muere algo que sobrevive, que es la única
dirección en la que puede equivocarse sin fabricar un ladrillo.
Dos refinamientos que salieron de la medición, cada uno con su test:
· HUÉRFANOS DE SELECT. Un símbolo sin prompt no se marca a mano: sólo entra por select.
Si caen todos sus selectores, cae él, aunque nadie dependa de él (caso ACPI_NHLT). Se
exige >=1 selector: sin ninguno entra por un default, y darlo por muerto mataría media
tabla.
· `X = y` SÍ ES DEPENDENCIA DURA. Medio drivers/video/fbdev declara su dependencia de FB
como `depends on (FB = y) && ARM`. Tratar toda comparación como opaca dejaba esos
drivers fuera. `X = n` sigue fuera a propósito: con X en n es VERDADERA. De regalo, las
fugas select sin declarar de sin-graficos cayeron de 8+ a 1.
Los 3 que faltan NO son un fallo, son otra pregunta: CRYPTO_LIB_ARC4, REGMAP y
SYSTEM_DATA_VERIFICATION tienen selectores FUERA de la clausura (PPP_MPPE, 111 usuarios más
de REGMAP…). Se quedaron sin usuarios en ESE config; encendés PPP y ARC4 vuelve.
«Inalcanzable» y «apagado ahora» no son lo mismo, y la clausura contesta la primera.
Y un bug que sólo aparece corriendo el resolvedor: el diff-back contaba como promesa
incumplida todo símbolo pedido ausente del .config. Pero Kconfig NO EMITE un símbolo cuyas
dependencias no se cumplen ⇒ un `-d WLAN` cuya raíz ya cayó simplemente no sale. Con esa
cuenta un plan perfecto se reportaba roto (2 falsos incumplidos de 16). Ahora: ausente +
se pedía apagar = éxito; ausente + se pedía encender = fallo. La corrida real sale 14
cumplidos, 0 incumplidos.
GUARDIÁN NUEVO, y hacía falta: las cuatro recetas de kernel NO son el mismo kernel — linux
y linux-metal van por 6.16.12, linux-metal-dual y linux-generic por 7.1.2. Planear una
contra el árbol de la otra calcularía clausuras sobre símbolos que ahí no existen, y
saldría SIN RUIDO. KconfigTree lee ahora su versión del Makefile de arriba y `plan` FALLA
si no coincide con la de la receta (los diagnósticos sólo avisan). Aviso de la sesión de
granja/store, verificado antes de implementarlo.
Catálogo: las dos fugas que destapó la clausura más grande quedan declaradas con motivo
(FB_SYSMEM_HELPERS_DEFERRED por HID_PICOLCD_FB; DRM_DISPLAY_DP_TUNNEL_STATE_DEBUG por
DRM_I915_DEBUG), y las notas sobre THUNDERBOLT/REISERFS_FS pasan a pasado: ya se
corrigieron en 2602218.
Runbook §4.bis: cómo probar un plan entero en 30 s en vez de 40 min.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sealed 768 -> 764, debt 9 -> 13, clase kernel=4. Consecuencia esperada del
cambio de hash: las recetas son correctas, los artefactos del store son de
la version anterior. Reconstruirlos deberia dar un kernel identico byte a
byte en una direccion nueva — util como prueba de bit-repro, ya que el
.config no cambia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Paso 3 del §8 del SDD 22, y cierra el orden que fijaba: reversa, clausura, gate, diff-back.
La pieza que faltaba no era el gate sino el MAPA driver → símbolo. El kernel sabe qué
driver tiene bindeado cada dispositivo, pero no de qué CONFIG_* salió: esa relación sólo
existe en los Makefiles de kbuild. modmap.rs lee 15.789 reglas obj-$(CONFIG_X) += y.o en
3182 Makefiles. Dos trampas de nombres, cada una con su test:
· el módulo cargado usa _ donde el fichero usa - (snd-hda-intel.o → snd_hda_intel)
· un módulo puede salir de VARIOS símbolos, y sobrevive si sobrevive cualquiera
Sin resolverlas el gate no encontraría nada y diría que todo está bien, que es el peor
resultado posible para un portón.
POR OBJETIVO, no global. La regla es "todo dispositivo en uso debe seguir teniendo
driver"; aplicada global rechazaría recipes/linux.toml, que apaga USB, HID e INPUT A
PROPÓSITO por ser el kernel de QEMU con consola serie. El gate NO CORRE sin --objective, y
un allow_bundles con un id mal escrito es error de CARGA del catálogo (si no, autorizaría
nada y bloquearía sin que se entienda por qué).
Medido con el mismo plan (sin-usb + sin-entrada-humana + sin-graficos + sin-wifi) y el
hardware real de gioser:
qemu-serial ........ PASA — 5 pérdidas autorizadas
metal-escritorio ... BLOQUEA — las mismas 5 como regresiones, con el bundle culpable
Ése es todo el punto del §5.
Y lo que el gate no puede comprobar, lo dice: de los 38 drivers bindeados, 15 no se
mapearon a ningún símbolo (pcieport, serial8250 — built-ins cuyo nombre de driver no
coincide con el del módulo). Quedan listados como SIN COMPROBAR, nunca como aprobados.
hammer kernel hw vuelca la huella y los drivers de la máquina DESTINO, que no tiene por
qué ser la de build — el SDD lo pedía explícitamente.
Cuatro objetivos en el catálogo (qemu-serial, servidor, metal-escritorio, portatil) y un
runbook nuevo: docs/runbooks/armador-de-kernel.md, con el ataque de punta a punta y una
lista honesta de lo que todavía NO está (sonda en VM, atestación por huella, bisección,
curación del delta con modelo, perillas side=recipe).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Paso 1 del §8 del SDD 22 (va después de la clausura porque necesitaba el grafo). Sigue sin
compilar ni escribir nada.
hammer kernel probe — lee /proc/config.gz (o /boot/config-<release>) y muestra el kernel
que YA CORRE por el lente de los bundles: cuánto de cada uno rige, qué capacidad carga
esta máquina y no usa, y dónde el hardware CONTRADICE a un bundle aplicado. Corrido en
gioser: 10.551 símbolos, 20 dispositivos PCI, 38 drivers bindeados, 15 bundles, 7 con
capacidad que este hardware no usa.
hammer kernel bundles [--check] — el catálogo con las clausuras resueltas contra un árbol
concreto, y el control de frescura.
Piezas nuevas en hammer-core/src/kernel/:
catalog.rs bundles N1 y perillas N2. El campo `side` NO es decorativo: la mitad de N2
son variables de receta, no símbolos; mueven el hash igual pero se aplican en
otra fase y fallan distinto. Una perilla side=recipe sin recipe_field es
error de carga, porque es un diff que la UI no podría explicar.
hw.rs huella DMI+PCI+flags de CPU. El USB se LEE y se REPORTA pero NO se hashea: un
pendrive no puede cambiar la clase de hardware bajo la que se cachea un
kernel. Tampoco entra el serial: la huella agrupa máquinas, no las identifica.
Tres tests fijan esas tres propiedades.
reverse.rs el análisis. Y una tercera salida que no estaba pedida: cada fuga `select`
que entra a un bundle y NO está declarada en el catálogo es un símbolo que
upstream agregó y nadie revisó ⇒ la mitad barata de la curación del delta
(§3 del handoff) sale de comparar grafo con catálogo, sin IA.
docs/state/kernel-bundles.toml — 15 bundles N1 y 8 perillas N2, cada fuga resuelta a mano
una vez: `close_leaks` (se apaga también al que la provoca) o `accept_leaks` (se deja
abierta a sabiendas, con el motivo escrito). Ejemplo de por qué hacían falta las dos:
"sin-audio" NO cierra — DRM_I915/NOUVEAU/AMD_DC hacen select del códec HDMI, y cerrarlo
sería quedarse sin GPU. Se acepta y queda por escrito.
LO QUE DESTAPÓ EL CONTROL DE FRESCURA: las CUATRO recetas de kernel (linux, linux-metal,
linux-metal-dual, linux-generic) apagan `THUNDERBOLT` y `REISERFS_FS`, y 6.16.12 NO TIENE
NINGUNO DE LOS DOS. Thunderbolt se llama USB4 desde que upstream lo fundió con USB4;
reiserfs fue retirado. Los dos `-d` son no-ops silenciosos: el driver USB4 sigue entrando
por el defconfig mientras la receta dice que está apagado. NO las toco — cambiarlo mueve
el ArtifactHash de los cuatro kernels y es una decisión, no una limpieza.
Y el propio probe destapó un desajuste que ahora avisa: el config vivo de gioser es de la
serie 7.1 y el catálogo se revisó contra la 6.16 ⇒ las clausuras son aproximadas. Se dice
en vez de callarlo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los repos del rootfs apuntan a Alpine edge (bump deliberado por el techo
MSRV). Es RODANTE: el mismo script en dos fechas da compiladores distintos.
Medido el 2026-08-10 al bootstrapear gioser — el laptop tenia rust 1.96 y
aqui edge resolvio 1.97.0-r0. Para un proyecto cuyo invariante es reproducir
eso es deriva del LAB, y no aparece en build-state.json.
No es un pin y no puede serlo: edge sirve solo la ultima version (`apk policy
rust` lista unicamente 1.97.0-r0), asi que `apk add rust=1.96.0-r0` rompe en
cuanto edge avanza, y Alpine no publica snapshots datados de edge. Anclar de
verdad pide espejar APKINDEX + los .apk, que es un frente aparte.
Lo que si se puede hoy: registrar los 92 paquetes resueltos en
docs/state/lab-toolchain.lock —que viaja por git, que es como los dos hubs lo
comparan— y AVISAR con el diff delante cuando la maquina difiere. Aceptar el
cambio es deliberado: --relock. Un lock que no se puede imponer sigue
valiendo si al menos nombra lo que cambio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Selladas 6: wayland, wayland-protocols, libxkbcommon, mesa, mirada-compositor
y mirada-greeter. Corpus 766 -> 768, deuda 11 -> 9, y la clase rust
desaparece. El perfil escritorio-mirada pasa a 31/31.
Las cuatro primeras figuraban como selladas y no lo estaban: el respaldo
tiene 7 artefactos VACIOS (mesa, wayland, wayland-protocols, libxkbcommon x2,
dbus x2), --listar los cuenta por nombre de directorio, build-state los toma
por buenos y hammer build hace cache-hit sobre el directorio vacio. Sellaba
sin construir y salia 0. Un ausente falla ruidosamente; un vacio llega hasta
el final diciendo que todo fue bien.
Para construirlas hacian falta dos piezas del lab que gioser no tenia: zig
0.13.0 (lo pinean 84 recetas, y se busca por directorio versionado, no por
el symlink) y el paso apk del rootfs, que trae rust/cargo. Quedan bloqueadas
gnome-session (no hay receta de GTK3 en el corpus) y gnome-settings-daemon
(geocode-glib existe, esta en deuda y no figura en su [deps]).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierre de la reparación. Lo que faltaba eran cuatro recetas que caían todas por `libsndfile`
—cuyo configure de autotools sólo busca python2.x— y `gnome-shell`, que había que rehacer.
Selladas en el hub: wireplumber, xdg-desktop-portal, xdg-desktop-portal-cosmic,
xdg-desktop-portal-gnome y gnome-shell.
ESTADO FINAL DE LOS PERFILES:
base 51/51 · cli 74/74 · escritorio-sway 121/121 · escritorio-kde 162/162
escritorio-cosmic 88/89 · escritorio-gnome 122/125
Lo que queda NO es deuda técnica sino decisiones ya tomadas:
· gdm, gnome-session, gnome-settings-daemon → CERRADAS por decisión (GTK3, 2026-08-08);
· portal-probe → git privado por SSH, HUB-ONLY estructural.
⚠ HALLAZGO EN LA GOLDEN NUEVA, que hay que arreglar antes de confiar en ella: el volumen
persistente `harkaq-cosecha` se monta ENCIMA de `/opt/hammer/store` y **tapa el store horneado
en la imagen**. El worker nuevo arrancó con 2 artefactos en vez de los ~900 que trae el
snapshot, así que la caché de la golden es hoy inútil: el bind del volumen la esconde. El
toolchain sí se heredó bien (cargo/rustc 1.96.0, go 1.26.4 verificados en el arranque).
⇒ O el volumen deja de montarse sobre esa ruta, o la golden no necesita traer store. Hoy hace
las dos cosas y se anulan.
Por eso estas cinco se construyeron en el hub y no en la granja: para cinco recetas no valía la
pena resolver el solapamiento, y el hub las tenía todas cacheadas.
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>
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>
sergio