Commit Graph
569 Commits
Author SHA1 Message Date
Sergio 65c1579571 estado: cosecha granja 2026-08-27T17:31:51Z — avance del árbol KDE 2026-08-27 17:31:51 +00:00
Sergio f2a704df9c estado: cosecha granja 2026-08-27T17:02:04Z — avance del árbol KDE 2026-08-27 17:02:04 +00:00
Sergio 799438b81a estado: cosecha granja 2026-08-27T16:32:05Z — avance del árbol KDE 2026-08-27 16:32:05 +00:00
Sergio 9472a3e260 estado: cosecha granja 2026-08-27T16:02:08Z — avance del árbol KDE 2026-08-27 16:02:08 +00:00
Sergio 177e6a9549 estado: cosecha granja 2026-08-27T15:32:05Z — avance del árbol KDE 2026-08-27 15:32:05 +00:00
Sergio 2cd5453b64 estado: cosecha granja 2026-08-27T15:02:15Z — avance del árbol KDE 2026-08-27 15:02:15 +00:00
Sergio f08e13383e estado: cosecha granja 2026-08-27T14:31:55Z — avance del árbol KDE 2026-08-27 14:31:55 +00:00
Sergio 3a4da09851 estado: cosecha granja 2026-08-27T14:02:08Z — avance del árbol KDE 2026-08-27 14:02:08 +00:00
Sergio a8b7ec9ba9 estado: cosecha granja 2026-08-27T13:32:10Z — avance del árbol KDE 2026-08-27 13:32:11 +00:00
Sergio 9e4db8e6ca estado: cosecha granja 2026-08-27T13:01:47Z — avance del árbol KDE 2026-08-27 13:01:47 +00:00
Sergio 9a4689e568 estado: cosecha granja 2026-08-27T12:31:52Z — avance del árbol KDE 2026-08-27 12:31:52 +00:00
Sergio ead6dc2218 estado: cosecha granja 2026-08-27T12:01:57Z — avance del árbol KDE 2026-08-27 12:01:57 +00:00
Sergio e10615e60d estado: cosecha granja 2026-08-27T11:31:56Z — avance del árbol KDE 2026-08-27 11:31:56 +00:00
Sergio 2b7e51be3f estado: cosecha granja 2026-08-27T11:01:54Z — avance del árbol KDE 2026-08-27 11:01:54 +00:00
Sergio abfcd45cc3 estado: cosecha granja 2026-08-27T10:31:58Z — avance del árbol KDE 2026-08-27 10:31:58 +00:00
Sergio 729ad0d687 estado: cosecha granja 2026-08-27T10:01:56Z — avance del árbol KDE 2026-08-27 10:01:56 +00:00
Sergio ac506b4d1b estado: cosecha granja 2026-08-27T09:31:57Z — avance del árbol KDE 2026-08-27 09:31:57 +00:00
Sergio 1d32b034de estado: cosecha granja 2026-08-27T09:02:01Z — avance del árbol KDE 2026-08-27 09:02:01 +00:00
Sergio acd156de4d estado: cosecha granja 2026-08-27T08:31:58Z — avance del árbol KDE 2026-08-27 08:31:58 +00:00
Sergio 8eedd414e2 estado: cosecha granja 2026-08-27T08:02:12Z — avance del árbol KDE 2026-08-27 08:02:12 +00:00
Sergio ae2cbc1c03 estado: cosecha granja 2026-08-27T07:31:55Z — avance del árbol KDE 2026-08-27 07:31:55 +00:00
Sergio 4f35256305 estado: cosecha granja 2026-08-27T07:02:02Z — avance del árbol KDE 2026-08-27 07:02:02 +00:00
Sergio e26e32b16e estado: cosecha granja 2026-08-27T06:32:04Z — avance del árbol KDE 2026-08-27 06:32:04 +00:00
Sergio 624cfbce3e estado: cosecha granja 2026-08-27T06:02:01Z — avance del árbol KDE 2026-08-27 06:02:01 +00:00
Sergio e3fda11875 estado: cosecha granja 2026-08-27T05:32:00Z — avance del árbol KDE 2026-08-27 05:32:00 +00:00
Sergio e578873243 estado: cosecha granja 2026-08-27T05:02:04Z — avance del árbol KDE 2026-08-27 05:02:04 +00:00
Sergio 3fa0fc3817 estado: cosecha granja 2026-08-27T04:32:44Z — avance del árbol KDE 2026-08-27 04:32:45 +00:00
Sergio 6d72101795 estado: cosecha granja 2026-08-27T04:02:10Z — avance del árbol KDE 2026-08-27 04:02:10 +00:00
Sergio 32fb404f88 estado: cosecha granja 2026-08-27T03:32:17Z — avance del árbol KDE 2026-08-27 03:32:17 +00:00
Sergio 252dec45ab estado: cosecha granja 2026-08-27T03:01:58Z — avance del árbol KDE 2026-08-27 03:01:58 +00:00
Sergio 993fc239e8 estado: cosecha granja 2026-08-27T02:31:52Z — avance del árbol KDE 2026-08-27 02:31:52 +00:00
Sergio c4ef89b474 estado: cosecha granja 2026-08-27T01:31:55Z — avance del árbol KDE 2026-08-27 01:31:55 +00:00
Sergio d8e36085b2 estado: cosecha granja 2026-08-27T01:02:12Z — avance del árbol KDE 2026-08-27 01:02:12 +00:00
Sergio 320e88f675 estado: cosecha granja 2026-08-27T00:31:56Z — avance del árbol KDE 2026-08-27 00:31:56 +00:00
Sergio 30f164b181 estado: cosecha granja 2026-08-27T00:02:01Z — avance del árbol KDE 2026-08-27 00:02:01 +00:00
Sergio dd58715e54 estado: cosecha granja 2026-08-26T23:32:18Z — avance del árbol KDE 2026-08-26 23:32:18 +00:00
Sergio d5c0a91309 estado: cosecha granja 2026-08-26T22:31:29Z — avance del árbol KDE 2026-08-26 22:31:29 +00:00
Sergio 560448aaf1 estado: cosecha granja 2026-08-26T22:02:59Z — avance del árbol KDE 2026-08-26 22:02:59 +00:00
Sergio 54e66a172a estado: cosecha granja 2026-08-26T21:32:06Z — avance del árbol KDE 2026-08-26 21:32:06 +00:00
SergioandClaude Opus 5 ce69ea23d4 ADR 0013: el pin de una receta no siempre es un commit
Documenta los tags anotados de diffutils/findutils-xargs/kustomize y por qué rompían las dos puntas
del mirror, y corrige la pregunta abierta: ningún servidor ha negado aún el fetch por sha suelto.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 21:13:59 +00:00
SergioandClaude Opus 5 276efdeced mirror git: el poblador reporta el error real de git, no una conjetura
Imprimía siempre «upstream no da el commit» pasara lo que pasara. En la primera tanda marcó así a
diffutils, findutils-xargs y kustomize, cuyos commits se traen a mano sin problema: era transitorio.
Ahora bundle() devuelve (ruta, motivo) con el stderr del paso que falló.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 21:07:10 +00:00
Sergio 75b8cdb945 estado: cosecha granja 2026-08-26T20:01:42Z — avance del árbol KDE 2026-08-26 20:01:43 +00:00
Sergio 3d38d5e573 estado: cosecha granja 2026-08-26T19:31:29Z — avance del árbol KDE 2026-08-26 19:31:29 +00:00
SergioandClaude Opus 5 8ab5040a8d ADR 0013: mirror de fuentes git — bundles shallow por commit
Los 606 repos por commit son el 52% de las fuentes y el mirror de tarballs no los cubría. Se espejan
como `hammer/fuentes-git/{commit}.bundle` — 571 commits distintos, porque hay commits compartidos
entre colas y se espeja uno solo.

La identidad es el commit y la verificación la hace git: al desempaquetar comprueba cada objeto
contra su SHA, así que un bundle alterado no pasa. No hace falta índice ni sha256 aparte.

SHALLOW, NO CLONES COMPLETOS. El bundle sale de un `fetch --depth 1` del commit exacto: para `act`
son 9,3 MB en vez del repo entero, y con 571 fuentes eso decide si el mirror cabe. Es legítimo
porque hammer NUNCA usa la historia — lo único que hace con un repo es `git archive <commit> |
tar -x`, materializar un árbol.

EL DETALLE QUE COSTÓ ENCONTRAR. Un bundle hecho desde un repo shallow no lleva la frontera de
historia, y al desempaquetarlo git aborta con «Failed to traverse parents … did not send all
necessary objects». El mensaje dice que faltan objetos y es ENGAÑOSO: llegan enteros —`git archive`
ya funciona pese al error—; lo que falta es decirle a git dónde termina la historia. Se escribe el
propio commit en `<destino>/shallow` antes del fetch. No hay nada que transportar: la frontera de un
`--depth 1` es exactamente ese commit.

Y UN BUG PROPIO QUE VALE DOCUMENTAR: se pasaba al `git fetch` la ruta RELATIVA del bundle, y como
`run_git` invoca `git -C <destino>`, git la resolvía dentro de `<destino>`. Como el fallo del mirror
se traga a propósito para caer a upstream, el síntoma salía lejísimos: el build moría con «commit …
no existe en <repo> tras fetch», culpando a upstream de un error de ruta local. Ése es el precio de
que el mirror falle en silencio, y por eso el silencio se paga con comentarios explícitos.

Verificado igual que el de tarballs, con receta EFÍMERA para que no haya cache-hit: commit de `act`
ya espejado + un repo cuyo host no resuelve por DNS. Sin HAMMER_MIRROR_GIT falla en el clone; con
él, sella — y el artefacto trae el README.md real de act.

`cargo test -p hammer-build`: 5/5. Población de los 571 bundles corriendo aparte.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 19:25:28 +00:00
Sergio f5decc26b1 estado: cosecha granja 2026-08-26T19:01:29Z — avance del árbol KDE 2026-08-26 19:01:29 +00:00
SergioandClaude Opus 5 45b95f78b9 ADR 0013: mirror de fuentes — la URL es transporte, el sha256 es la identidad
`rsync` (404 de samba.org) y `musl` (musl.libc.org no responde) no se pueden construir hoy, y no por
culpa nuestra. Es el estado estacionario: una distro que construye TODO desde fuente tiene tantos
puntos de fallo como fuentes, y son servidores de terceros que nadie nos prometió mantener.

LA MEDIDA, peor de lo que parecía. Sobre 1167 fuentes (561 tarball + 606 git, 79 hosts):
github.com sostiene 742 — el 64% del corpus depende de UN host. Doce hosts sostienen el 89%. Y 43
hosts sostienen exactamente UNA receta cada uno: ahí es donde muerde el bit-rot lento.

El vigía, en su primera corrida: 8 URLs muertas de 1167. Tres de ellas —busybox, freetype,
freetype-shared— están SELLADAS Y EN USO: son el shell y las fuentes del escritorio que se capturó
hoy. Se salvan sólo porque el tarball sigue en la caché local de esta máquina.

LA URL NUNCA FUE LA IDENTIDAD, y el código ya lo sabía: `hash_inputs` usa `tarball:{sha256}` /
`git:{commit}` y el `..` descarta la URL; la caché se nombra `{sha256}.tar` con un comentario que
dice literalmente que cambiar de mirror no la invalida. Añadir mirrors NO re-hashea NADA. Faltaba el
mecanismo, no el diseño.

Orden: caché local → mirror propio → upstream. El mirror va ANTES, no como rescate: el sha256 se
verifica igual, así que no hay diferencia de contenido posible, y un mirror que sólo se usa cuando
upstream falla es un mirror que nadie prueba — se descubre roto el día que hace falta.

LO QUE HAY QUE HACER BIEN. Un mirror que sirve calladamente lo que upstream perdió convierte un
fallo ruidoso en silencio. Por eso construir y vigilar van SEPARADOS: `hammer build` nunca avisa
(sería ruido en 561 recetas), y `fuentes-vigia.sh` pide cabeceras, escribe
docs/state/fuentes-vigia.json y lo corre el latido. Sin ese contrapeso las URLs se mueren una a una
y el corpus queda irreconstruible con todo en verde — el mismo modo de fallo que dejó el grafo de
wlr 17 días anunciando un 121/121 falso.

 PROHIBIDO cambiar el sha256 para "arreglar" una URL muerta. Es la tentación natural ante un 404 y
no arregla una descarga: cambia lo que la distro construye. Otro sha256 es otro contenido, y la
receta seguiría diciendo `rsync 3.4.4` mientras construye otra cosa.

VERIFICADO DE PUNTA A PUNTA. El primer intento —construir busybox con el mirror puesto— dijo BUILD
OK y NO PROBÓ NADA: cache-hit del artefacto, cero bytes descargados. La prueba válida usa una receta
efímera con un sha256 que sí está en el mirror y una URL que ni resuelve por DNS. Sin HAMMER_MIRROR:
`curl (6) Could not resolve host`. Con él: sella, con el contenido real.

Mirror poblado: 126 objetos en el Storage Box que ya se paga. `cargo test -p hammer-build`: 5/5.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 18:57:40 +00:00
SergioandClaude Opus 5 f8f679d038 corpus: expat-shared y libffi-shared cierran la fuga al Alpine del lab
sway es `link = "dynamic"` A PROPÓSITO —un compositor dlopea los drivers DRI de mesa en runtime— y
sale con doce NEEDED. Nueve los cubría la clausura (pixman, drm, evdev, input, udev, wayland-server,
wlroots, xkbcommon, libc), porque esas recetas ya son dinámicas. Los otros tres —libz.so.1,
libexpat.so.1, libffi.so.8— venían de recetas `--disable-shared`, así que NINGÚN artefacto sellado
producía ese `.so` y el rootfs los resolvía contra el sysroot Alpine DEL LAB.

POR QUÉ ERA PEOR QUE UNA DEP FALTANTE. Una dep ausente falla ruidosamente. Ésta no: el lab NO entra
en `hash_inputs`, así que el store daba el artefacto por bueno mientras el binario sólo arrancaba en
una máquina que tuviera Alpine debajo. La fuga era invisible para todo el sistema de medición.

`zlib-shared` ya existía en el corpus y sólo faltaba declararla. `expat-shared` y `libffi-shared` son
nuevas, calcadas del patrón: autotools con --enable-shared, sin el truco de --whole-archive que
zlib-shared necesita porque SU configure aborta bajo zig cc. SONAMEs verificados contra lo que pide
el ELF: libexpat.so.1, libffi.so.8, libz.so.1. Exactos.

NO se tocó `link` en las canónicas: entra en `hash_inputs` y habría re-hasheado expat, libffi y todo
lo que los lista en deps —fontconfig, dbus, mesa, glib, python3, los crates `-sys`— cientos de
recetas selladas por libs que ya están bien. El nombre `*-shared` es distinto del canónico, así que
conviven. Verificado antes de construir: recalculadas las 794 recetas, **0 hashes cambiados**, sólo
las 2 nuevas.

Van al CORPUS y no a incoming-wlr/ porque la resolución de deps es hermano→padre: una receta del
corpus no ve una cola. Es donde ya viven zlib-shared, fontconfig-shared, freetype-shared…

VERIFICADO CON PÍXELES, no con el log. Rootfs rehidratado desde cero (126/126), CERO ficheros de
`.dev-fs/alpine`. Cero «Error relocating». La captura tiene el MISMO sha256 que la de las libs de
Alpine: 177fea396caa9dca, 1280x720, 383 colores. Tercera vez que la evidencia sale bit a bit igual
al cambiar la procedencia — la soberanía no costó ni un píxel.

Perfil: escritorio-sway 126/128. Faltan strace (linux-headers del lab) y rsync (404 de upstream).

QUEDA UN RESTO: el loader `/lib/ld-musl-x86_64.so.1` todavía se toma del host. `recipes/musl.toml`
existe en el corpus pero está EN DEUDA y fuera de todo perfil — mismo agujero de declaración, un
nivel más abajo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 18:42:11 +00:00
SergioandClaude Opus 5 428ad80b24 wlr: fuentes y XKB DECLARADAS en el perfil — la captura sale bit a bit idéntica
`dejavu-fonts` y `xkeyboard-config` entran en `recipes/incoming-wlr/` y en las raíces de
`escritorio-sway`. La clausura pasa de 123 a 125 y ambas ya estaban selladas: cero builds.

POR QUÉ TENÍAN QUE SER RAÍCES Y NO PODÍAN LLEGAR POR CLAUSURA. Son DATOS, no binarios: ninguna
receta depende de una fuente ni de un mapa de teclado para COMPILAR. El grafo puede seguir todas las
aristas que quiera y no va a alcanzarlas nunca. Si no se declaran, no están — y el perfil sigue
dando 100%, porque mide la clausura de las raíces declaradas.

Copias BYTE-IDÉNTICAS a las de incoming-kde, a propósito. Ya había tres copias iguales de
xkeyboard-config (kde, gnome, cosmic) y dos de dejavu-fonts (kde, cosmic); ésta es la cuarta. No se
consolidan al corpus ahora porque eso toca las colas de otros tres frentes que otros agentes
trabajan. Mantenerlas idénticas deja esa consolidación como un `git mv` trivial en vez de un merge:
cuatro ficheros iguales se unifican de un tirón, cuatro casi-iguales exigen revisión.

VERIFICADO de punta a punta, no por el log: rootfs rehidratado DESDE CERO con sólo lo que la
clausura declara (123/123), y `sway-headless.sh` sin una línea de inyección manual de fuentes ni
XKB. Cero errores de xkbcommon, cero de fcft. La captura resultante tiene el MISMO sha256 que la de
ayer con todo inyectado a mano — 1280x720, 383 colores. La declaración es exactamente equivalente a
la inyección, y el pipeline reproduce.

Queda como deuda real (no de declaración): libz.so.1 / libexpat.so.1 / libffi.so.8, que sway pide
por estar enlazado dinámico y el corpus sólo produce como `.a`. Y `fonts.conf` NO era deuda: lo trae
el propio artefacto de fontconfig.

Perfil: escritorio-sway 123/125. Los 2 que faltan son strace (choca con los linux-headers del lab) y
rsync (404 de upstream), ninguno del escritorio.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 18:03:46 +00:00
Sergio fd2dc39a83 estado: cosecha granja 2026-08-26T18:00:25Z — avance del árbol KDE 2026-08-26 18:00:25 +00:00
SergioandClaude Opus 5 d68b750109 evidencia: sway headless 2026-08-26 — 1280x720, 383 colores, foot con texto vivo
Captura tomada por grim (del corpus) sobre sway 1.10 / wlroots 0.18.2 / foot 1.27.0, todo construido
desde fuente con zig cc contra musl. Backend headless en bwrap: ni QEMU ni kernel de por medio.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
2026-08-26 17:09:56 +00:00