Commit Graph
973 Commits
Author SHA1 Message Date
sergio 497414cde3 estado: cosecha granja 2026-07-27T23:35:36Z — avance del árbol KDE 2026-07-27 19:35:36 -04:00
sergioandClaude Opus 5 64bc2bade0 gnome onda 3: atk SELLADO + mutter feature-minimal + colord medido hasta su muro real
atk (b3:506acb89): mutter la exige sin perilla (meson.build:127) porque Cally, la
accesibilidad de Clutter, habla ATK. 2.38.0 es la última release independiente —
después upstream la fundió en at-spi2-core. Se autora suelta a propósito: es glib y
nada más, mientras at-spi2-core arrastra dbus y el bus de accesibilidad entero.
Queda escrito en la receta el choque futuro: cuando entre at-spi2-core (lo pide
gnome-shell) las dos instalan atk-1.0.pc.

mutter: -Dremote_desktop=false mata pipewire Y libei de un saque; también x11, glx,
libwacom, sound_player, startup_notification y sm apagados. Con atk+json-glib+lcms2+
libdisplay-info declaradas, el configure avanza hasta colord.

colord: receta escrita y medida. El comentario que yo mismo puse (que -Ddaemon=false
adelgazaría las deps) es FALSO y queda corregido en la receta: en 1.4.7 el bloque de
dependency() es de nivel superior, sin `if daemon`. Pide sqlite3 (ya estaba, declarada),
gusb, gudev-1.0 y libudev. Faltan tres ⇒ la próxima tanda es libusb → libgusb + libgudev,
y libgudev no se paga sólo por colord: mutter la exige por su opción udev, la del
backend nativo KMS.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 19:28:15 -04:00
sergioandClaude Opus 5 8bc349afa9 gnome onda 3: json-glib SELLADO + 3 recetas reusadas de KDE + veredicto de gnome-session
json-glib (b3:1b90c876): la dep más compartida de la cima — la piden mutter, gnome-shell
y gnome-session. Feature-minimal, static, sin introspección (con la condición de vuelta
escrita en la receta: si gnome-shell pide Json-1.0.typelib desde JS, pasa a isla dinámica).

Reusadas de incoming-kde SIN construir nada — fichero idéntico ⇒ mismo ArtifactHash ⇒
cache-hit del artefacto que KDE ya selló: libdisplay-info (b3:260f0519) + su dep hwdata,
y lcms2 (b3:07fbf8a1). Tres de la frontera de mutter cerradas a coste cero.

pipewire NO se trajo, y el intento dejó la lección: al resolverse contra la glib de la cola
GNOME cambia de hash (deja de ser cache-hit) y arrastra pulseaudio/libsndfile/alsa-lib a
esta cola. mutter tiene -Dremote_desktop=false, que mata pipewire Y libei de un saque.
El guardián del barrido existe justamente para no pisar variantes homónimas.

gnome-session: medido y APARCADO con diagnóstico en la propia receta. No le falta un
parche: exige gtk+-3.0, gnome-desktop-3.0 (la legacy que apagamos) y libsystemd
required:true sin perilla. Asume systemd y GTK3, los dos ausentes por decisión. No bloquea
el escritorio: gnome-shell no depende de gnome-session — sólo gdm. El camino vivo es
mutter → gnome-shell.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 19:24:53 -04:00
sergioandClaude Opus 5 f857843a21 gnome onda 3: gnome-desktop SELLADO (b3:f65767ca) — 3 parches de introspection-off
iso-codes (b3:c447da29) y libseccomp (b3:b3da6b80) construidos; con ellos y el
xkeyboard-config reusado de KDE, gnome-desktop encuentra sus tres deps y sella.

Tres seds en configure, todos consecuencia de decisiones ya tomadas del frente:

  gnome-rr/meson.build   con introspection=false el .gir queda como cadena VACÍA y
                         meson la trata como fichero: «ERROR: File  does not exist».
  gnome-bg/meson.build   ídem pero peor: la variable queda SIN DEFINIR.
                         (libgnome-desktop/meson.build:163 NO se toca: ése inicializa
                          a [], que meson aplana. Es el patrón correcto.)
  subdir('tests')        installed_tests=false sólo decide si se INSTALAN, no si se
                         compilan. Su exe se enlaza -static contra -lgtk-4 y desde la
                         onda 2 gtk4 es dinámica ⇒ no hay libgtk-4.a. La librería ya
                         está enlazada cuando eso pasa (26 de 27 targets).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 19:20:15 -04:00
sergioandClaude Opus 5 5aec112629 gnome onda 3: cierra las 3 fronteras de gnome-desktop + el latido regenera el grafo GNOME
Las 3 fronteras que el propio comentario de gnome-desktop declaraba:

  iso-codes         receta nueva (datos + .pc). Ya no está en download.gnome.org (404);
                    Salsa es GitLab y su archive no es determinista (lección de cairo-shared),
                    así que la fuente es el .orig.tar.xz inmutable del pool de Debian.
                    Sin traducciones: i18n.gettext exige msgfmt completo y sólo hay
                    gettext-tiny — se vacían los 8 meson.build de dominio.
  libseccomp        receta nueva (autotools estático, gperf de build-dep real).
  xkeyboard-config  duplicada desde incoming-kde: fichero idéntico ⇒ MISMO ArtifactHash
                    (b3:bcf9b766) ⇒ ya está SELLADO. Frontera cerrada con cero rebuild.

Y un punto ciego del latido: cosecha-cron regeneraba build-state.json y el de KDE, pero
NUNCA el de GNOME. El grafo llevaba días mintiendo `never` sobre gobject-introspection y
toda la onda 2, que están selladas. Un grafo viejo miente con la misma cara que uno fresco.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 19:14:59 -04:00
sergio 29e296efee estado: cosecha granja 2026-07-27T21:26:06Z — avance del árbol KDE 2026-07-27 17:26:06 -04:00
sergioandClaude Opus 4.8 855ff932c4 gnome onda 2: libtiff-shared --undefined-version (version-script Windows-only)
libtiff.so falló 'version script assignment LIBTIFF_4.5 to TIFFOpenWExt failed':
el map lista símbolos Windows-only no compilados en musl; lld lo trata como error.
-Wl,--undefined-version lo hace laxo (estándar en cross).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 17:06:49 -04:00
sergioandClaude Opus 4.8 9696c4873b gnome onda 2: libtiff-shared + libjpeg-turbo-shared para gtk4
gtk4 EXIGE libtiff-4 (meson.build:450, sin required:false) ⇒ removerlo no sirve
(quiere bajar un wrap). Autoro libtiff-shared (dynamic, NEEDED libz.so/libjpeg.so)
+ copio libjpeg-turbo-shared de KDE. gtk4 los declara ⇒ sus loaders linkean las
.so y la cadena zlib resuelve por NEEDED.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 17:03:38 -04:00
sergioandClaude Opus 4.8 6b3b6e1489 gnome onda 2: gtk4 sin libtiff/libjpeg (loaders no-esenciales, romapían el link)
gtk4 compiló pero el link murió 'undefined inflate' de libtiff.a (necesita zlib,
no resuelto sin --prefer-static). Los loaders tiff/jpeg propios de gtk4 no los
usa gnome-shell (png/gdk-pixbuf alcanzan). Removidos ⇒ gtk4 los saltea.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:59:14 -04:00
sergioandClaude Opus 4.8 80465d1689 gnome onda 2: gtk4 al cierre C dinámico (-shared) + gi-foreign-girs
pango SELLÓ (5/6 onda2). gtk4 = el último y más grande: mismo patrón -shared
(cairo/fontconfig/freetype/libpng/zlib) + gi-foreign-girs (cairo-1.0.gir).
pango/gdk-pixbuf/graphene/harfbuzz resuelven a las islas. wayland/mesa/libdrm/
libepoxy/libjpeg/libtiff quedan corpus (worker revela si necesitan -shared por PIC).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:55:10 -04:00
sergioandClaude Opus 4.8 a537f9857a gnome onda 2: gi-foreign-girs genera cairo-1.0.gir del .in
cairo-1.0.gir NO está en gir/ como .gir sino como cairo-1.0.gir.in (g-i lo genera
con configure_file). Reproduzco la sustitución @CAIRO_GIR_PACKAGE@=cairo-gobject
y @CAIRO_SHARED_LIBRARY@=libcairo-gobject.so.2 con sed. Desbloquea pango (PangoCairo
referencia cairo-1.0). Es el gir foráneo que hizo SIGSEGV al keystone original.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:49:51 -04:00
sergio f6c5811be6 estado: cosecha granja 2026-07-27T20:19:12Z — avance del árbol KDE 2026-07-27 16:19:12 -04:00
sergioandClaude Opus 4.8 f07665d553 gnome onda 2: gi-foreign-girs instala los .gir foráneos (freetype2/cairo/…)
harfbuzz falló 'Couldn't find freetype2-2.0.gir'; nuestro g-i minimal
(build_introspection_data=false) NO instala ningún .gir, ni los foráneos
hand-written. Nuevo recipe gi-foreign-girs copia gir/*.gir del source de g-i a
/usr/share/gir-1.0 (sólo XML, sin compilar ⇒ SIN cascada de re-hash de g-i).
harfbuzz→freetype2-2.0, pango→cairo-1.0 lo declaran. (pango tuvo tmb la carrera
ADR 0012 'Directory not empty', reintenta sola.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:14:03 -04:00
sergioandClaude Opus 4.8 8d0dae6390 gnome onda 2: harfbuzz isla con introspección (HarfBuzz-0.0.gir p/ pango)
gdk-pixbuf SELLÓ. pango compiló sus .so pero su g-ir-scanner pide HarfBuzz-0.0.gir
(Pango-1.0 referencia tipos hb): el harfbuzz corpus tiene introspection/gobject
disabled. Autoro harfbuzz isla (shadow, dynamic, default_library=both,
gobject+introspection enabled) ⇒ produce HarfBuzz-0.0.gir + libharfbuzz.so.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:09:16 -04:00
sergioandClaude Opus 4.8 62cad30978 gnome onda 2: pango/gdk-pixbuf usan el cierre C dinámico (-shared)
gjs SELLÓ (898b424f) con el cierre -shared; aplico el mismo a pango/gdk-pixbuf:
- pango: cairo-shared/freetype-shared/fontconfig-shared/libpng-shared/zlib-shared
  ⇒ el test cairo-ft deja de fallar 'FontConfig support' (era el cierre estático
  no resuelto, no fontconfig faltante).
- gdk-pixbuf: libpng-shared/zlib-shared ⇒ no 'undefined inflate'.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:04:02 -04:00
sergioandClaude Opus 4.8 09e2bd6129 gnome onda 2: gjs -Dreadline=disabled (libreadline.a no es PIC)
Último muro del link: libgjs.so (dinámica, exige PIC) arrastra libreadline.a, que
es --enable-static sin --with-pic ⇒ R_X86_64_PC32 contra rl_prompt. (libffi.a pasó:
es PIC, la glib-isla lo probó.) readline = sólo la consola JS interactiva, que
gnome-shell no usa. Desactivado. Vuelve con una variante readline-shared/PIC.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:20:07 -04:00
sergioandClaude Opus 4.8 5ecefdb4b4 gnome onda 2: gjs sed-ea el subproyecto de tests (pide cairo-1.0.gir)
gjs compiló libgjs y GjsPrivate typelib, pero muere en el subproyecto INCONDICIONAL
gobject-introspection-tests (Regress/WarnLib, cairo=true): su g-ir-scanner pide
cairo-1.0.gir, que nuestro g-i (cairo=disabled) no instala. Son fixtures de test;
los removemos (subproject + subdirs installed-tests/test). gi_tests no se usa fuera.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:16:12 -04:00
sergio b9fbb4c368 estado: cosecha granja 2026-07-27T18:14:58Z — avance del árbol KDE 2026-07-27 14:14:58 -04:00
sergioandClaude Opus 4.8 33c3fcdc75 gnome onda 2: cairo-shared usa el release estable + sed boilerplate
El archive de GitLab es NO-determinista (cada fetch = otro sha256, imposible de
pinnear). Cambio al release de cairographics.org (hash fijo 445ed820); strippea
boilerplate/ (sólo tests) ⇒ configure sed-ea subdir('boilerplate'). Fuente estable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:09:50 -04:00
sergioandClaude Opus 4.8 259f9ef901 gnome onda 2: cairo-shared sha256 al valor actual de GitLab (archive no determinista)
El archive de GitLab recomprime al vuelo ⇒ el sha256 6d9281 (que el canónico
registró) ya no coincide; sirve d221d540. El canónico no lo nota (sellado, no
re-fetchea). Deuda: pinnear a un mirror estable. Por ahora, desbloquea.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:06:18 -04:00
sergioandClaude Opus 4.8 5fe6e7e3c9 gnome onda 2: cairo-shared usa la fuente GitLab + cairo-ctime-r.patch
cairo-shared murió 'Nonexistent build file boilerplate/meson.build': el release
de cairographics.org strippea boilerplate/; el canónico usa el archive de GitLab
(git tree completo) + el patch HAVE_CTIME_R. Alineo la fuente al canónico.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:03:16 -04:00
sergioandClaude Opus 4.8 5a025fe1e7 gnome onda 2: cierre C dinámico (cairo-shared) desbloquea gjs
El link de gjs moría en cairo estático (undefined XML_GetCurrentLineNumber): el
cairo canónico --prefer-static arrastra fontconfig/freetype/pixman/expat como
cadena estática que un consumidor dinámico no resuelve. Fix = cairo DINÁMICO:
- cairo-shared (nuevo): libcairo.so.2 default_library=both, deps al cierre -shared.
- copio zlib/libpng/freetype/fontconfig -shared de incoming-kde (sufijo NO sombrea
  el corpus ⇒ NO re-hashea la glib-isla). pixman canónico ya es dinámico.
- gjs usa el cierre -shared: linkea libcairo.so, la cadena resuelve por NEEDED.

Mismo cierre desbloqueará pango/gtk4 (próximo). Confirma la revelación del
comentario de pixman.toml: el muro 'cairo-ft FontConfig' era el cierre estático
no resuelto, no fontconfig faltante.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:59:09 -04:00
sergioandClaude Opus 4.8 5e4dd7ab9d gnome onda 2: gjs inyecta el cierre estático de cairo via cpp_link_args
cairo es dep obligatoria (sin -Dcairo). El link de gjs sólo pone -lcairo, no la
cadena transitiva estática (fontconfig->expat, freetype->png/z, pixman) =>
undefined XML_GetCurrentLineNumber. Inyecto -lfontconfig,-lfreetype,-lpixman-1,
-lpng16,-lexpat,-lz (todas no-GObject: sin doble-estado, a diferencia de
--prefer-static con glib). Se limpia cuando cairo sea isla dinamica (#7).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:51:53 -04:00
sergioandClaude Opus 4.8 a425a55ab9 gnome onda 2: gjs -Dcairo=disabled para sellar el hito (cairo vuelve con el cierre C)
Muro de link 'undefined symbol: XML_GetCurrentLineNumber' (expat): gjs dinámico
linkea cairo.a→fontconfig.a→expat pero meson no arrastra la cadena estática
transitiva. Es la deuda del cierre C (#7). Desactivo cairo para sellar YA el
hito (motor JS + typelib GjsPrivate bajo musl); los bindings cairo vuelven cuando
cairo sea isla dinámica.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:47:47 -04:00
sergioandClaude Opus 4.8 4c4a8d570a gnome onda 2: gjs declara py3-setuptools (distutils de g-ir-scanner)
gjs pasó meson setup + compile y murió generando GjsPrivate typelib con
'No module named distutils' — el mismo muro que graphene. py3-setuptools da el
shim. Olvidado en gjs (lo puse en las 4 islas GUI pero no acá).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:44:12 -04:00
sergio 32a902eb93 estado: cosecha granja 2026-07-27T17:43:16Z — avance del árbol KDE 2026-07-27 13:43:16 -04:00
sergioandClaude Opus 4.8 9f73ea09cf gnome onda 2: gjs declara ncurses (backend curses de readline)
gjs llegó lejos (glib/gobject/gio/cairo/mozjs-128 todos YES) y murió en el link
de readline: ncursesw/ncurses/termcap NO encontrados. ncurses ya sellado (widec).
Lo declaro ⇒ libncursesw.a hidratada, mantiene la consola JS interactiva.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:41:27 -04:00
sergioandClaude Opus 4.8 625b704331 gnome onda 2: gjs declara nspr (mozjs-128.pc lo requiere)
Avanzó tras el cierre .pc de glib; nuevo muro: mozjs-128.pc Requires nspr, no
declarado. nspr ya sellado en el volumen. Patrón .pc→deps.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:37:42 -04:00
sergioandClaude Opus 4.8 26bb33c31b gnome onda 2: gjs declara el cierre .pc de glib+cairo (pcre2/zlib/freetype/...)
meson setup abortaba 'libpcre2-8 required by glib-2.0 not found': glib-2.0.pc y
cairo.pc traen Requires.private que hammer no hidrata transitivamente. Agrego
pcre2/zlib (glib) + freetype/fontconfig/pixman/libpng/expat (cairo). Patrón .pc→deps.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:34:56 -04:00
sergioandClaude Opus 4.8 293e996ebf gnome onda 2: gjs -Dbsymbolic_functions=false (zig/lld no soporta -Bsymbolic-functions)
gjs pasó spidermonkey (sembrado, cache-hit) y murió en meson.build:89:
'-Bsymbolic-functions not supported'. El linker zig/lld no lo soporta.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:31:30 -04:00
sergioandClaude Opus 4.8 c2ea7cd884 gnome onda 2: py3-setuptools en las 4 islas GUI (fix distutils de g-ir-scanner)
Primer ciclo del worker: los 5 targets fallaron, 3 muros distintos:
- graphene: compiló+linkeó .so/.a, murió SÓLO en g-ir-scanner con
  'ModuleNotFoundError: distutils' (Python 3.12 lo removió). Faltaba declarar
  py3-setuptools (el shim de setuptools), como ya hacían los keystones. FIX aquí.
- pango/gtk4: fallan en meson setup 'cairo-ft does not have required FontConfig
  support' — la DEUDA DE ALCANCE cobrándose: sin --prefer-static, pkg-config no
  resuelve las deps estáticas transitivas de cairo. --prefer-static NO sirve
  (embebería glib en pango.so → doble GType → SIGSEGV del keystone). Fix real =
  escalar el cierre C (cairo/fontconfig/freetype/harfbuzz) a islas dinámicas.
  PENDIENTE (pase grande). py3-setuptools agregado igual (lo necesitarán luego).
- spidermonkey: 'No module named _ctypes' (python3 del rootfs worker sin _ctypes,
  skew). No se reconstruye: se SIEMBRA la sellada del laptop (1.3G) ⇒ gjs cache-hit.

Este ciclo esperado: graphene sella + gjs sella (spidermonkey sembrado).
pango/gdk-pixbuf/gtk4 esperan el cierre C dinámico.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 12:29:37 -04:00
sergio 9c9a8a8003 estado: cosecha granja 2026-07-27T15:09:35Z — avance del árbol KDE 2026-07-27 11:09:35 -04:00
sergioandClaude Opus 4.8 328c7219aa gnome onda 2: cola driver aislada incoming-gnome-onda2
Cola de build para el worker (patrón onda1): SÓLO los 5 targets listos
(gjs/graphene/pango/gdk-pixbuf/gtk4) + su cierre de deps que vive en
incoming-gnome/ (islas glib/glib-introspected/g-i/py3-setuptools + la cadena
spidermonkey/nspr/nasm/cbindgen). Todas las deps ya selladas ⇒ cache-hit; el
worker sólo mide los 5. Excluye mutter/gnome-shell/gdm (deps no listas) para
no quemar compute en builds condenados. Byte-idénticas al corpus/incoming-gnome
⇒ hashes idénticos (resolver sibling→parent auto-consistente).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 11:04:05 -04:00
sergioandClaude Opus 4.8 4ecfa2ab0b gnome onda 2: islas dinámicas del stack GUI + gjs
Autoría Fase 1 (laptop, cero compute) de la onda 2 GNOME (gjs → gnome-shell).
Patrón isla dinámica (SHADOW del corpus estático, resolver hermano→padre):
link=dynamic, default_library=both (.a interno + .so p/ scanner/gjs),
introspection=enabled ⇒ producen su typelib. Todas hashean limpio.

- gjs: declara glib-introspected (su g-ir-scanner sobre GjsPrivate necesita los
  .gir CORE; hidratación directa, no transitiva). Deps ya TODAS selladas ⇒ listo
  para construir — primer nodo de onda 2, no necesita gtk4.
- graphene/pango/gdk-pixbuf: islas + Graphene-1.0/Pango-1.0/GdkPixbuf-2.0.typelib.
- gtk4: isla + Gtk-4.0/Gdk-4.0/Gsk-4.0.typelib. Revierte los hacks del mundo
  estático (sed libgtk_dep, fat-archive). ITERATIVA: el scan arrastra el cierre
  transitivo (wayland/mesa/libdrm/epoxy) aún estático — walls esperados en worker.

Deuda de alcance declarada: sub-deps C (cairo/harfbuzz/etc.) siguen corpus
estáticas embebidas; si duplican estado en runtime se escalan a isla puntual.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 11:02:14 -04:00
sergio df23b70d8f estado: cosecha granja 2026-07-25T09:37:55Z — avance del árbol KDE 2026-07-25 05:37:55 -04:00
sergioandClaude Opus 4.8 ade217cf06 gnome isla: glib-introspected SELLA (b3:c12cb9fa) — typelibs CORE ✓ GATE PASS
El test definitivo del keystone: glib con -Dintrospection=enabled produce los
typelibs CORE (GLib/GObject/Gio/GModule/GioUnix/GLibUnix/GIRepository) usando
g-ir-scanner+compiler sobre GLib misma. SELLA ⇒ g-ir-compiler SÍ sirve para lo
core bajo musl; el SIGSEGV anterior era EXCLUSIVO de los .gir X11/cairo (que no
queremos, Wayland-only). La introspección funciona end-to-end ⇒ gjs→gnome-shell
destrabado.

Rompe el ciclo glib↔g-i: glib-introspected → g-i → glib(stage1, sin introspección),
sin ciclo. Clave: declara glib(stage1) en deps para hidratar libglib-2.0.so.0 y que
g-ir-scanner (que _giscanner.so dlopea) CORRA al configure (hammer hidrata deps
DIRECTAS, no transitivas — diagnosticado con una sonda musl).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 05:21:58 -04:00
sergio 5296e91498 estado: cosecha granja 2026-07-25T05:36:10Z — avance del árbol KDE 2026-07-25 01:36:12 -04:00
sergioandClaude Opus 4.8 d83979d6ce gnome isla: gobject-introspection SELLA (b3:935cedf3) — keystone GNOME
El palo largo del stack GNOME, sellado. link=dynamic (consistente con la glib .so
de la isla, evita mezcla de estado GType) + build_introspection_data=false: g-i 1.84
sólo generaba aquí los typelibs EXTERNOS de X11/cairo (cairo/xlib/xft/xrandr/xfixes/
win32) — que NO queremos (Wayland-only) y sobre los que g-ir-compiler hace SIGSEGV
bajo musl. Los typelibs CORE (GLib/GObject/Gio) los produce glib (absorbió
girepository). g-i aquí = las TOOLS (g-ir-scanner/compiler) + libgirepository-1.0.so.

Cadena del muro (6 capas): py3-setuptools → wrapper -static/-shared → wrapper
--export-dynamic/.so → glib dinámica → glib default_library=both → introspection_data
off. El scanner (ejecuta código del target, el miedo real) CORRE bit a bit.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 01:30:49 -04:00
sergioandClaude Opus 4.8 b57ce69311 gnome isla: glib default_library=both (.a + .so)
g-i (link=static) compila binarios internos que hacen `-static -lglib-2.0`; con la
glib sólo-shared, zig falla "unable to find static system library glib-2.0" (no hay
.a). La isla necesita AMBOS: el .so para que g-ir-scanner resuelva la introspección
(y gjs lo dlopee en runtime), el .a para el link estático interno de los consumidores.
default_library=shared → both.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 01:25:21 -04:00
sergioandClaude Opus 4.8 319cfd83ec gnome isla: glib dinámica (shadow de la corpus) para destrabar introspección
El fork elegido: isla dinámica para GNOME. Piedra angular = glib como .so real,
porque g-ir-scanner exige "shared libraries" (el typelib mapea a una lib que gjs
dlopea en runtime) y la corpus es sólo libglib-2.0.a.

Variante link=dynamic (-Ddefault_library=shared) en la cola GNOME. NO toca
recipes/glib.toml (estática, la consume KDE/corpus entero — cambiarla re-hashea
cientos). Por el orden del resolver (hermano→padre) SOMBREA la corpus SÓLO para
recetas GNOME; el resto del árbol intacto. Deps internas (libffi/pcre2/zlib) siguen
estáticas embebidas en el .so. introspection=disabled (los typelibs los produce g-i
externamente, evita el ciclo glib↔g-i).

g-i re-hashea a 8c3e5dd1 (dep glib static→dynamic); prueba de fuego en worker.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 01:18:24 -04:00
sergioandClaude Opus 4.8 d4eb77df14 harness: -static cede ante TODO link dinámico (no sólo -shared)
El wrapper anterior (quita -static con -shared) destrabó la extensión Python de
g-i, pero g-i es dinámico en 3 puntos y el fallo saltó a los otros dos:
"error: using shared libraries requires dynamic linking" en (a) las tools que
linkean libgirepository-1.0.so y (b) el dumper del scanner con -Wl,--export-dynamic.

Generalizo la regla del wrapper: -static se quita ante cualquier marcador de link
dinámico — -shared, -rdynamic, --export-dynamic, o un shared object (.so/.so.N) en
la línea. Todos son casos donde -static es contradictorio de por sí. El link
estático normal (exe/.a sin marcadores) y el compile puro quedan byte-idénticos.
Verificado contra las 2 líneas reales que fallaban + 2 casos de no-regresión.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 01:09:48 -04:00
sergioandClaude Opus 4.8 437d5bb103 harness: wrapper linker-driver que quita -static en links -shared
Las extensiones Python (python.extension_module → shared_module) son .so que el
intérprete del sandbox debe dlopen; intrínsecamente dinámicas. El harness inyecta
LDFLAGS=-static para link=static, y meson/autotools lo aplican a TODOS los targets
por igual ⇒ el .so sale ET_EXEC y dlopen da "Exec format error" (el muro de
gobject-introspection: _giscanner.cpython-312.so no cargaba).

Fix estructural (elegido sobre flip-a-dynamic): ensure_layout materializa en el
rootfs dos wrappers (hammer-zig-cc/-cxx sobre zig cc/c++) que QUITAN -static SÓLO
cuando el link lleva -shared. -static+-shared es contradictorio ⇒ correcto por
construcción: transparente (byte-idéntico) para todo link normal, arregla TODA
extensión Python futura, no sólo g-i.

Hash-safe: el ArtifactHash se deriva de inputs (receta+deps), no de los bytes ⇒
no re-hashea ninguno de los 700+ sellados (cache-hit intacto); sólo cambia builds
nuevos con .so dinámicos. Verificado: rota positional params, preserva orden y
espacios; transparente sin -shared.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 01:04:23 -04:00
sergioandClaude Opus 4.8 ee2f3b6de3 gnome onda-1: py3-setuptools + destrabar los 2 fallos de la 1ª molienda
El worker molió la onda 1: gsettings-desktop-schemas SELLÓ (hash 4777231b
reproducido exacto). Los otros 2 fallaron con causas limpias:

- gobject-introspection: meson.build:29 exige `python3 (setuptools)` importable
  (instala giscanner como paquete python); el python3 del rootfs no lo trae.
  Fix: receta py3-setuptools (puro-python, copia a site-packages, sin pip ni red
  — espejo de meson.toml) + declararla en [deps].build.
- gnome-desktop: sub-declaré gsettings-desktop-schemas (schemas_dep en meson:62);
  ya sellada ⇒ añadida a [deps].build. Avanza el diagnóstico al siguiente muro
  real (iso-codes / xkeyboard-config / libseccomp, frontera genuina de la receta).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 00:44:02 -04:00
sergio 5db4c6931a estado: cosecha granja 2026-07-25T04:00:51Z — avance del árbol KDE 2026-07-25 00:00:51 -04:00
sergioandClaude Opus 4.8 da26b3a280 gnome onda-1: cola aislada incoming-gnome-onda1 para el worker
Las 3 raíces de la onda 1 (gsettings-desktop-schemas, gobject-introspection,
gnome-desktop) copiadas a una cola propia + añadida al QUEUES del worker-loop.
Aislar evita que el worker dispare rebuilds de spidermonkey/mutter (onda 2/3).

El cierre real de RECETAS de las 3 es 39 nodos, 0 en incoming-kde: el "gap del
resolver" que temía era de seed-edges (.pc cairo→libX11), NO de deps declaradas.
El espinazo corpus (38 nodos: gtk4/cairo/pango/gdk-pixbuf en recipes/) está 100%
sellado ⇒ el worker cachea todo e sólo construye las 3. Hashes byte-idénticos a
los sellos de incoming-gnome (base_dir no entra al hash).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 23:31:27 -04:00
sergio 4ebcba1301 estado: cosecha granja 2026-07-24T19:45:44Z — avance del árbol KDE 2026-07-24 15:45:44 -04:00
sergioandClaude Opus 4.8 6f9e30bcaf gnome: las 10 raíces del perfil escritorio-gnome — el perfil CIERRA (mapa real)
Autoradas top-down feature-minimal en incoming-gnome (parte por subagentes, parte
a mano tras un stall de API): gobject-introspection, gjs, gsettings-desktop-schemas,
gnome-desktop, gnome-session, gnome-settings-daemon, mutter, gnome-shell, gdm,
xdg-desktop-portal-gnome. Las 10 parsean (hash dry-run). Versiones GNOME 48 salvo
gnome-desktop (44.5: upstream no corta estable de la lib compartida tras 44.5).

Con las raíces, el perfil escritorio-gnome CIERRA: 70 nodos, 60 YA sellados, 10 en
deuda (las raíces), en 3 ondas topológicas. Contra los 613-694 del cierre nixpkgs:
la sobreestimación 5-10x confirmada en vivo. La frontera GENUINA que aún no tiene
receta va documentada como comentarios FRONTERA en cada TOML (json-glib, libei,
colord, gcr, libsecret, polkit, ibus, at-spi2, accountsservice, linux-pam, upower,
geoclue, libnotify, iso-codes, xdg-desktop-portal, libseccomp; + gtk3/x11 que
g-settings-daemon 48 aún exige incondicional). Deuda de resolver: pipewire/pulseaudio/
alsa-lib/xkeyboard-config existen en incoming-kde pero resolve_dep_path no ve esa cola.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-24 15:42:12 -04:00
sergio 4ae5a3422c estado: cosecha granja 2026-07-24T19:15:34Z — avance del árbol KDE 2026-07-24 15:15:34 -04:00
sergio 8669d5b45a estado: cosecha granja 2026-07-24T18:45:21Z — avance del árbol KDE 2026-07-24 14:45:21 -04:00
sergioandClaude Opus 4.8 afd867ea51 yupana: drenar reckona honesto un perfil sin cierre (guardián GNOME)
drenar --perfil escritorio-gnome erraba 'no encontré un grafo (¿corriste
build-state.py?)' — mentira: el grafo GNOME existe, pero NINGUNA raíz del perfil
(mutter/gnome-shell/gdm) está autorada ⇒ 0 nodos etiquetados con el perfil, y la
comprobación por etiqueta en cargar() fallaba. Dos correcciones:
  · cargar(): una cola NO-corpus identifica su grafo unívocamente ⇒ matchear por
    cola; la etiqueta sólo desambigua dentro de corpus (perfiles solapados).
  · main(): ámbito vacío con perfil ≠ 'imagen completa' — es 'SIN CIERRE todavía:
    0 raíces autoradas', y apunta a autorar top-down.
KDE (162 sellados) y corpus (769/4-deuda) sin regresión. El yupana-gnome queda
armado en las 4 capas: objetivo, radio/grafo, keystones y drenar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-24 14:23:12 -04:00