Sus deps foundational ya publicadas ⇒ el orden de dependencias resolvió y packean+firman.
Sin colisión con canónicas. Quedan en incoming-clib las 8 GUI meson pesadas (gtk4/pango/
libadwaita/gtksourceview + demos) y las 13 variantes colisionantes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sus recetas canónicas referenciaban cmake-version.patch / fix-test-musl.patch pero los
ficheros habían quedado en tandas/staged-2026-06-26/ (patch-huérfano de una promoción
vieja) ⇒ pack fallaba. Movidos junto a su receta; ambos publican+firman ahora.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cierra el desfase receta/repo: 15 recetas que ya construyen y están publicadas+firmadas
en dist/repo pero seguían en la cola de staging. Sin colisión con canónicas (guarda de
build-farm). Los .patch viajan con su receta. Quedan en incoming-clib las 13 variantes
colisionantes (build-deps del stack GUI) y las 14 GUI deep-dep sin publicar aún.
brotli fribidi gettext-tiny giflib glib gperf graphene harfbuzz itstool
libjpeg-turbo libsass libtiff libxmlb lz4 sassc
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Dos bugs del promote de build-farm.sh, hallados al cosechar incoming-clib:
1. mv movía el .toml pero NO sus .patch (quedaban en la cola) ⇒ toda receta
parcheada fallaba el pack ("leyendo patch ...: No such file or directory").
Ahora mueve los patches referenciados junto al .toml.
2. mv sobrescribía a ciegas una receta canónica de recipes/ con una variante
homónima de la cola (p.ej. curl 8.11 mínimo-para-appstream pisando el
curl 8.20 full). Se agrega guarda: si ya existe recipes/<n>.toml, NO se
promueve la variante (queda staged para triage) ni se re-publica.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
brotli fallaba con 'cmake: not found' porque no declaraba cmake en [deps].build
(patrón libjpeg-turbo/libtiff que sí materializa el tool). bzip2 en incoming-clib
era un duplicado del ya-promovido recipes/bzip2.toml (sellado en dist/repo).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Abrir/guardar/guardar-como (GtkFileDialog async), resaltado por extensión, números de línea, línea
actual, auto-indent, apertura de archivos desde CLI (G_APPLICATION_HANDLES_OPEN). Link 100% estático:
157MB ELF 'not a dynamic executable', --help responde. App instalable y usable, no una demo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
giflib: quita xmlto (solo docs). xz: fuente release (trae ./configure; el archive del tag no) + quita
autoconf/automake/libtool. libwebp construye al destrabarse giflib. Limpia los fallos recurrentes del loop.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Link 100% estático: gtk4+libadwaita+gtksourceview → 154MB ELF estático, corre. Esqueleto de un editor
real para el distro; valida los 3 stacks juntos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
meson static; introspection/vapi/docs/sysprof off; sed elimina subdir tests/testsuite (linkean gtk4
estático y fallan por privadas, pero la lib sí construye).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Linkeado 100% estático contra libadwaita-1.a: binario 152MB, ELF 'not a dynamic executable', corre.
Prueba que el stack Adwaita del lab es usable por apps reales.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
libadwaita-1.a archive GORDO (meson library() normal, sin el split de GTK) + libadwaita-1.pc + adwaita.h.
Cierra el stack GUI de alto nivel del lab: ya se pueden construir apps Adwaita.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
appstream 1.0.5 lean (compose/svg/stemming/gir/systemd off) destrabado con: gettext-tiny (msgfmt
p/ i18n de meson), itstool stub (copia el join-source, sin traducciones), curl mínimo (sin TLS, solo
satisface el link), libxmlb+libyaml, y sed que elimina subdir('docs/') incondicional (xsltproc+docbook).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- gtk4.toml: el merge ahora fusiona TODOS los convenience-libs bajo output/ (gtk/css, gdk/wayland,
cursor, gsk…), no solo gtk/gdk/gsk — el .a queda monolítico y autocontenido.
- gtk4-hello.toml: hello.c propio (GtkApplication+ventana), link estático vía pkg-config --static gtk4
+ privadas de gdk/gsk que gtk4.pc no declara (harfbuzz-subset/epoxy/xkbcommon/wayland/tiff/jpeg/
cairo-script-interpreter). Binario: 134MB, ELF 'not a dynamic executable', corre (exit 0).
Prueba de que el toolkit de GUI del lab es USABLE por apps reales, no solo que compila.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Backend solo wayland (GL renderer vía libepoxy, vulkan off), todo lo opcional off.
Cierre .pc transitivo completo (24 deps). Parches: tools→libgtk_static_dep (la .so no
linkea con -static); instala libgtk-4.a además de la .so (apps static-musl). Corona el
stack gráfico C: glib/cairo/pango/gdk-pixbuf/graphene/libepoxy/wayland/mesa/harfbuzz/…
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Como root (granja), tar preservaba el uid del tarball → el sandbox (userns) no podía chmod/escribir
esos ficheros → configure autotools fallaba (oniguruma: Permission denied creando Makefile). Extraer
como root sin preservar owner lo arregla para TODO tarball. oniguruma vuelve a configure plano.
sergioandClaude Opus 4.8