El compositor construye: /usr/bin/mutter + gdctl, libmutter-*.so, los typelibs Clutter-16 y
Cogl-16, y libmutter-16.pc — que es exactamente lo que gnome-shell enlaza e importa.
LO QUE DESTRABÓ TODO: libelogind (b3:a6058906), receta nueva sobre `arje-sdlogin-compat`, un
crate que escribí en tawasuyu para esto. arje-logind-compat ya publicaba el estado de sesión
en /run/systemd/{sessions,users,seats}; faltaba la librería C que lo LEYERA, porque la API
sd-login no es cliente D-Bus: lee esos ficheros. mutter probó libsystemd (no), después
libelogind (sí) y siguió de largo. No es un stub: lee estado real que el daemon publica.
Después del muro aparecieron cinco cosas más, todas resueltas y ninguna de fondo:
udev-pc (b3:69e2d418) mutter pide DOS pkg-config: `libudev` (lo da libudev-zero) y `udev`
(metadata: udevdir). Receta aparte y no agregado a libudev-zero
porque `yupana radio` daba 51 SELLADOS cayendo a deuda en las cinco
imágenes. Un .pc de 4 líneas no justifica medio catálogo.
libxcvt (b3:ab8ede67) mutter corre `cvt` en build-time para generar meta-default-modes.h.
El app/cvt clásico vive en xorg.freedesktop.org, que desde acá no
responde (probé x.org, kernel.org y Lysator). libxcvt es la
extracción moderna del mismo código, está en el pool de Debian y no
arrastra nada de X11.
-Dbash_completion=false y el sed de subdir('doc/man') (pedía rst2man).
py3-setuptools el distutils del g-ir-scanner, mismo precedente que polkit y gjs.
cierre C dinámico freetype/fontconfig/cairo/libpng/zlib/libjpeg/libtiff pasan a sus
variantes -shared: mutter ya es .so y las estáticas canónicas no
entran («relocation R_X86_64_32 … recompile with -fPIC»). Mismas
variantes que usa gtk4.
Y gsettings-desktop-schemas pasa a introspection=true + isla dinámica: su gir GDesktopEnums
entra en el de Meta, y sin él el scanner cortaba en el ÚLTIMO target (721/722). Es exactamente
el caso que el comentario de esa receta dejaba previsto («si mutter/gjs lo pidieran vía
typelib, se re-activa»). Costo medido: 1 sellado (gnome-desktop), reconstruido acá mismo.
PENDIENTE: la receta apunta al commit de gitea que todavía NO está pusheado (ver el informe).
El artefacto ya es el correcto — la URL no entra al ArtifactHash, sólo el commit, así que
construir desde el clon local dio el MISMO hash que dará desde gitea.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tercera de la cima. gnome-shell la exige por gcr-4 (meson.build:74) y su JS importa gi://Gcr
(js/ui/components/keyring.js) ⇒ tenía que ser .so con typelib, no había opción estática.
Cadena nueva: p11-kit (b3:8dbec390) → gcr. p11-kit va con -Dtrust_module=disabled, que es lo
único que arrastraba libtasn1: una receta menos.
EL NUDO REAL fue el PIC, otra vez. libgcrypt y libgpg-error del corpus son estáticas SIN PIC
(y libgcrypt además está afinada para binarios -all-static -no-pie, con la advertencia escrita
de que el flag va en compile e install pero nunca en configure). Meterlas en un .so da
«relocation R_X86_64_32 ... recompile with -fPIC».
NO se tocaron las canónicas: `yupana radio` dio 5 sellados cayendo a deuda en base/cli, y
mostró además que existe OTRA libgpg-error en incoming-kde con 39 dependientes — justo el
tipo de colisión que el radio existe para ver. Se hicieron variantes -shared en la cola, que
es el idioma que este frente ya tiene (zlib-shared, cairo-shared, freetype-shared…).
libgcrypt-shared compiló con ZIG-CC, no gcc como la canónica: evidencia de que esa receta puede
migrar cuando le toque el turno de matar-gcc. Necesitó -fno-sanitize=undefined (el runtime UBSan
que inyecta zig deja __ubsan_handle_* sin definir en el .so), remedio ya documentado en zlib-shared.
Otros dos apagados de gcr, cada uno ahorrando una receta: -Dssh_agent=false (libsecret sólo la
pide el agente ssh) y -Dgpg_path fijo (gcr sólo quiere la RUTA de gpg para hornearla, no ejecuta
nada). Y el sed de subdir('po'): el msgfmt de gettext-tiny ABORTA con SIGABRT en po/ar.po. Es la
segunda vez que ese msgfmt marca el límite; si hay una tercera, conviene autorar el gettext de GNU.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Segunda de la cima. Da atk.pc, atk-bridge-2.0.pc y atspi-2.pc + los typelibs Atk-1.0 y
Atspi-2.0. gnome-shell la exige por atk-bridge-2.0 (meson.build:71).
El choque que atk.toml anticipaba se confirmó: el tarball de at-spi2-core trae `atk/` adentro
e instala su propio atk-1.0. Dos recetas con el mismo .pc se pisan en el sandbox, y NO era
hipotético: el cierre de gnome-shell contiene a las dos, porque mutter es dep suya. Se retira
atk.toml y at-spi2-core queda como único proveedor — que es lo que hace upstream desde 2.51.90.
Medido antes de tocar, con `yupana radio atk`: 1 dependiente directo (mutter), 0 sellados que
caigan a deuda. mutter repuntado a at-spi2-core llega EXACTAMENTE al mismo muro de logind, sin
ninguno nuevo.
DBus-1.0.gir lo pedía el scanner y ya lo provee gi-foreign-girs (no hizo falta receta nueva).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Primera de la cima. Da polkit-agent-1.pc (lo que gnome-shell enlaza en C) y los typelibs
Polkit-1.0 + PolkitAgent-1.0 (lo que su JS importa: gi://Polkit aparece en polkitAgent.js,
endSessionDialog.js, status/thunderbolt.js y environment.js — verificado, no supuesto).
-Dlibs-only=true y acá la opción SÍ recorta, al revés que en colord: el bloque `if not
libs_only` (:145-159) es justo el que pide expat, duktape y threads. Y no es un recorte a
desgana — la Semilla de arje ya trae compat-polkit implementando el servicio D-Bus; construir
polkitd sería competirle, no completarlo.
-Dsession_tracking=ConsoleKit no es preferencia por ConsoleKit: es la ÚNICA de las tres que no
exige una C-ABI de logind (logind→libsystemd, elogind→libelogind), y son LAS MISMAS funciones
sd-login que traban a mutter (sd_uid_get_display, sd_pidfd_get_session). Con libs-only ese
camino queda inerte. Cuando exista el shim, vuelve a `logind`.
-Dauthfw=shadow (no hay linux-pam). Isla dinámica, como manda la regla del registro único de
GType. Las 3 deps de tooling que faltaban salieron de precedentes ya escritos del frente:
gettext-tiny (msgfmt), py3-setuptools (distutils de g-ir-scanner) y glib-introspected
(Gio-2.0.gir para el scanner).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Selladas: libgudev b3:a767a231, libusb b3:a8507df1, libgusb b3:4903731d,
colord b3:a0c30aac, libei b3:0537145b, py3-jinja2 b3:e8f28561, py3-markupsafe b3:3ef224ac.
EL HALLAZGO DE LA TANDA — colord destapó una regla que vale para todo el frente:
su meson construye libcolord/libcolorhug como shared_library() pase lo que pase, y con
--prefer-static cada .so se tragaba una copia de la glib ESTÁTICA ⇒ una tabla de GType por
objeto compartido. Síntoma: las herramientas que el propio build compila (cd-create-profile,
cd-it8) enlazaban, arrancaban, y morían con `assertion 'G_IS_FILE (file)' failed` + SIGSEGV.
Yo había anotado a lcms2 como sospechoso; era falso y quedó corregido en la receta. Pasar
colord a la ISLA DINÁMICA (glib .so, un solo registro de tipos) lo selló con CERO segfaults
y los 9 perfiles ICC generándose bien. mutter va por el mismo camino: gnome-shell dlopea
libmutter vía gjs, así que también es isla dinámica.
Lecciones menores, todas medidas:
- -Dremote_desktop=false NO evita libei: mutter 48.8 la pide incondicional (meson.build:130),
y del lado SERVIDOR (libeis). Sólo se llevó pipewire.
- libusb necesita --with-pic para poder vivir dentro de un .so — mismo remedio y misma razón
que recipes/libffi.toml, que lo aprendió con Mesa.
- La cadena de build más larga y menos obvia: mutter → libei → jinja2 → markupsafe.
- gvdb NO es frontera: viene dentro del tarball de mutter como subproyecto.
- La mesa del corpus es EGL/GLES sin GL de escritorio (coherente con Wayland-only) ⇒
mutter va con -Dopengl=false.
- gnome-desktop-4.pc arrastra xkeyboard-config/iso-codes/libseccomp: patrón .pc Requires →
[deps].build.
MURO QUE QUEDA, uno solo y bien delimitado: mutter exige un proveedor de logind POR C-ABI
(libsystemd o libelogind por pkg-config), no por D-Bus. Usa ~10 funciones de sd-login:
sd_pid_get_session/get_cgroup/get_user_unit, sd_session_get_type/is_active/get_class,
sd_uid_get_sessions/get_display. Y no se puede esquivar: -Dudev=false exige -Dlogind=false
(meson.build:257) y sin udev+logind no hay backend nativo KMS, o sea no hay compositor real.
Esto CORRIGE lo anotado en el frente ("no hace falta la C-ABI sd-login, los escritorios
consultan login1 por D-Bus"): cierto para los clientes, falso para mutter.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
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>
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>
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>
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>
El motor JS de Mozilla, keystone del frente GNOME (gjs→gnome-shell cuelgan de él),
sella b3:c48dbd10: libmozjs-128.so + libjs_static.a + shell js128 + mozjs-128.pc +
550 headers. Compiló el C++ entero a -O3 -j8 sin OOM en el hub (31GB/0 swap, al filo).
Seis capas iteradas desde el borrador:
1-2. FIX DE INFRA: el rootfs builder tenía clang pero NO el paquete (Alpine
separa los binutils LLVM del compilador). Sin llvm-ar/llvm-objdump/llvm-profdata
configure aborta. bootstrap-devfs.sh: +llvm22 en NEEDED + paso 3a-ter que
symlinkea la suite llvm-* a /usr/bin (Alpine la deja en /usr/lib/llvm22/bin sin
exponerla). Aplicado ya al rootfs real (.dev-fs/alpine).
3. triple: mozjs no traduce vendor ; 4. debe COINCIDIR con el host de rustc
(); fijado ese exacto.
5. venv de mach: cada fase es un bwrap con /tmp fresco ⇒ el venv no sobrevivía de
configure a compile. Anclado a /src/.mozbuild (persiste, es scratch).
No re-hashea artefactos (el rootfs no entra al hash). OJO: el worker golden también
necesita llvm22 (ya cubierto por bootstrap-devfs.sh para la próxima provisión).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El keystone del frente. spidermonkey.toml es PRIMER BORRADOR — mozjs no sella a la
primera sobre musl (mach/configure no lo auto-detecta el lab ⇒ fases a mano, iterar
en worker ccx33+). Anclado al APKBUILD musl de Alpine: source del árbol firefox
128.14.0esr (sha real), clang, icu in-tree, nspr+zlib del sistema, shared-js.
Leaves que faltaban (ninguno estaba en el rootfs ni tenía receta):
nspr 4.36 (autotools), nasm 2.16.03 (autotools), cbindgen 0.27.0 (Cargo).
Las 4 parsean (hash dry-run OK) y pueblan el grafo: yupana radio nspr/cbindgen ya
ven a spidermonkey como dependiente. Capa grafo del yupana-gnome VIVA y reckonando.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
build-state.py gana --gnome (análogo a --kde): carga recipes/incoming-gnome/ y sale
a build-state-gnome.json. drenar/yupana/seed-graph aprenden ese grafo (keystones,
drenar --perfil escritorio-gnome, radio de nodos incoming-gnome, frontera). Hoy la
cola está vacía ⇒ el grafo trae 0 nodos gnome; se poblará al aterrizar recetas y ahí
drenar/keystones reckonan solos.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1. targets.toml: [perfil.escritorio-gnome] (9 raíces de sesión, cola incoming-gnome)
⇒ `yupana objetivo` ya lo ve; fluye por targets.py. build-state lo SALTA hasta
que la cola se cargue (--gnome), así declararlo no reporta raíces fantasma.
2. seed-gnome.py OPTIMIZADO: hornea la triage (sustitución/tooling/opcional/espinazo)
como HIPÓTESIS con el caveat "el cierre de nixpkgs sobreestima ~5-10×", marca el
keystone (spidermonkey→gjs→gnome-shell), y deja de mentir con el 465 crudo. El
espinazo (353) se reporta como COTA ALTA, no como lista de build.
Falta (se activa al autorar): grafo build-state-gnome + flag --gnome ⇒ keystones/
drenar nativos sobre GNOME. Hoy la capa OBJETIVO del yupana-gnome está; la GRAFO no.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La campaña de 40 nodos KDE selló 40/40, 0 fallidas: kio (desbloqueado por 6a0dc40)
arrastró la cascada y completó el escritorio. De 85/162 al abrir el catálogo a
162/162. 41 tiempos reales cosechados para el camino crítico pesado.
El peso que le faltaba a las ondas: sin él, critical-path = nº de pasos; con él,
ETA real en segundos.
INSTRUMENTACIÓN (worker):
scripts/farm/build-timed.sh envuelve `hammer build` midiendo la pared y la
registra en $STORE/.times/<hash>-<host>.json — un SIDECAR del store, NUNCA
dentro del artefacto. La duración es no determinista (varía por máquina/carga)
⇒ no puede tocar el ArtifactHash. Keyed por hash (CAS-safe: dos workers no se
pisan) + host (varias muestras por receta). Viaja al hub con el rsync de store
que ya hace la cosecha; ninguna herramienta del store lo confunde con artefacto.
Sólo builds REALES (pared ≥ UMBRAL 3s) — los cache-hits no envenenan la mediana.
campana-deuda.sh ahora construye vía build-timed.sh (transparente, mismo exit).
CONSUMO (hub): yupana._tiempos() carga name→mediana de segundos; keystones
computa el CAMINO CRÍTICO pesado = longest weighted path del subgrafo de deuda
(peso = segundos de build). La cadena más larga hay que construirla en SERIE
aunque haya ∞ workers ⇒ es la ETA con paralelismo infinito. Degrada con gracia:
sin datos, peso=1 y el camino crítico = nº de pasos (lo que ya daban las ondas).
Verificado: con muestras sintéticas da "ETA 19 min sobre 5 pasos, kio → kparts →
frameworkintegration → breeze → plasma-integration"; sin datos degrada a "5 pasos
(SIN datos)". store/.times está git-ignorado (metadata de máquina, no se commitea).
LÍMITE honesto (en la cabecera de build-timed.sh): `hammer build` arrastra deps ⇒
la pared incluye deps no selladas. En orden topológico (drenar) las deps ya están
selladas y la pared mide sobre todo ESTA receta — cota superior buena para pesar.
La precisión exacta pediría instrumentar el sellado dentro de hammer-build (Rust).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El usuario pidió arreglar itstool y la sombra de dbus. Apliqué el reflejo
(`yupana radio` + diff completo antes de tocar) y NINGUNO era un bug: ambos eran
patrones deliberados y documentados que mi detector, demasiado superficial, leyó
mal. Si los "arreglaba" a ciegas rompía dos builds.
· dbus: corpus/dbus (estático) e incoming-kde/dbus (dinámico) NO son redundantes
— qtbase linkea libdbus-1.so dinámicamente para Qt6DBus. El detector comparó
sólo versión+sha+deps, no el BUILD. Borrar la sombra rompía KDE.
· itstool: es un STUB documentado (`[source]=carrier`). El itstool real es
Python con libxml2-bindings ausentes en el lab; este genera un script inline y
sólo PRESTA el tarball de gettext-tiny. Apuntarlo al itstool real rompía
appstream (radio 5) con un source que ni compila acá.
Los 3 *-hello son el mismo patrón carrier; prison/prison-scanner una variante
cross-nombre (misma fuente, WITH_ZXING distinto).
FIX = el detector, no las recetas. Tres señales que le faltaban:
1. huella de BUILD en la firma de sombra (estático≠dinámico ⇒ no redundante).
2. CARRIER: ≤1 receta del grupo construye la fuente ⇒ el resto presta el tarball.
Señal: ¿invoca make/meson/cmake/ninja/cargo? (comentarios strippeados — la
prosa "invocación de meson" de un stub daba falso builder, lo cazó el guardián).
3. variante cross-nombre: ≥2 builders con BUILD distinto = deliberado, no bug.
Resultado: 0 colisiones reales (invariante c se cumple), 4 carrier + 14 variantes
+ 12 sombras justificadas, todas benignas.
Guardián extendido: ancla que el detector agrupa por FUENTE (itstool↔gettext-tiny)
y NO cría lobos (itstool=carrier, dbus=variante deliberada).
LECCIÓN: el reflejo del radio/diff antes de tocar evitó dos borrados destructivos
guiados por un falso positivo de mi propia herramienta. Medir antes de creer, aun
a la propia yupana.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`yupana keystones` rankea los nudos EN DEUDA por cuánto trabajo BLOQUEADO libera
su sellado (cierre inverso transitivo restringido a la deuda). Sellá de arriba
hacia abajo y la cascada cae lo antes posible.
CORRIGE UN ERROR MÍO: dije "árbol de dominadores = keystones". Lo medí y es
FALSO. El dominador ingenuo asume alcanzabilidad OR (basta un camino), pero
construir es AND (hacen falta TODAS las deps): kcoreaddons depende de dbus/libdrm
/mesa además de qtbase ⇒ hay un camino de desbloqueo que evita qtbase y el
dominador-OR lo pierde. La métrica correcta bajo AND es el cierre inverso
transitivo. Y el crudo lo gana el toolchain (make gatea 313, inútil) ⇒ el
keystone accionable es el cierre restringido a la deuda, y sólo cuenta si el
nudo mismo está en deuda (un sellado ya está disponible, no gatea nada).
Estado actual (qtbase ya sellado, era EL keystone con 117 gateados):
kio 36 ← sellarlo libera 36 recetas KDE bloqueadas
kparts 19
kcmutils 17
ksvg 14
libplasma 13
Ése es el camino crítico ahora.
El dominador SÍ entra, en su uso legítimo: la columna `exclusivo` = retención
estilo GC (nodos que sólo dependen de mí). kwin=9 (sus plugins privados),
libksysguard=3. Responde "si suelto esta feature, cuánto más puedo soltar".
Sin datos nuevos (no necesita duración de build). Cuando instrumentemos tiempos,
el mismo cierre se vuelve camino crítico PESADO (ETA real).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`yupana duplicados` caza nudos que son el MISMO paquete bajo nombres/colas
distintos, agrupando por lo que BAJA (sha/url), no por el nombre. Clasifica:
colisión-fuente — mismo sha, familias de nombre DISTINTAS ⇒ casi seguro un
sha copiado por error. ACCIONABLE.
variante — mismo sha, misma familia (zlib/zlib-shared, mesa-*) ⇒
diversificación deliberada estático/shared, OK (14 vistas).
sombra — mismo nombre en >1 cola; redundante si versión+sha+deps
coinciden (una sobra), justificada si difieren.
HALLAZGO INMEDIATO — el detector encontró un bug real en su primera corrida:
itstool.toml dice versión 2.0.7 pero su url+sha apuntan al tarball de
gettext-tiny (29cc165e…). Construiría la fuente equivocada. radio itstool=1,
gettext-tiny=78 ⇒ el sha copiado es el de itstool.
Otras 3 colisiones son demos (adwaita-hello/libadwaita, sourceview-hello/
gtksourceview, radio 0) o subcomponentes (prison/prison-scanner) — a revisar,
no urgentes. Y 1 sombra redundante: incoming-kde/dbus es byte-idéntica a
corpus/dbus (mismo hash de artefacto) ⇒ los 114 consumidores KDE podrían
apuntar a corpus/dbus sin rebuild.
NO funde nada solo: reporta a docs/state/duplicados.json y deja el juicio al
humano (como el triaje). El radio de cada nudo dice cuál es el canónico (el de
mayor radio). Guardián extendido: test-yupana-radio.py falla si el detector
deja de ver colisiones de fuente (agrupar por nombre en vez de sha = invariante
c ciego).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sergio
