llvmpipe necesita libLLVM (softpipe no bindea el GBM/EGL que kwin exige). El LLVM 22 del
sandbox no compila con mesa 24.0.9 ⇒ sellamos LLVM 18.1.8 desde fuente (rango soportado),
patrón gcc-de-gueto + static-libstdc++. mesa-llvmpipe = mesa-swrast con -Dllvm=enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Elimina el injerto del artefacto viejo que destrababa la sesión Plasma anidada.
Desktop.qml de plasma-workspace importa ese módulo; sin él plasmashell falla
"module not installed". qtdeclarative ya estaba en deps. Rebuild va a la granja.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El comentario justificaba openrc como 'el supervisor de servicios que le falta a arje':
falso. arje-zero es autónomo (PID1 + gestiona servicios). openrc es un init ALTERNATIVO
que la distro ofrece y COMPITE con arje por PID1, no una capa que se apila. Reencuadrado
como el patrón para el resto de la oferta multi-init (runit/s6/dinit). Corrige también la
nota de deps: libcap NO es opcional en Linux (dependency incondicional en meson.build).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
openrc es el supervisor de servicios (rc-service/rc-status/rc-update/start-stop-daemon)
que faltaba para una distro instalable — arje-zero es PID1, openrc gestiona /etc/init.d.
El build fallaba por libcap: meson.build lo pide incondicional en Linux (dependency
'libcap' >=2.33, sin -Dlibcap). Añadido → binarios estáticos-musl sellados.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
libXft es el único de los 11 que no sella. Falla por PIC (freetype/libpng/expat
estáticas no-PIC dentro de un .so), riesgo que su propio header ya predecía. NADIE
lo consume: plasma-workspace (su único declarante) selló SIN él porque KDE es Wayland.
Forzarlo sellaría un artefacto muerto. A .deferred/ para que el loop no lo reintente;
la cadena de deps .pc quedó resuelta (libpng+expat), sólo resta el muro PIC (Capa 0).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El init/service-manager de Gentoo y Alpine — musl-clean por diseño (Alpine lo corre sobre
musl en prod). Enlace static-musl vía zig-cc; deps opcionales (audit/selinux/pam/libcap)
desactivadas para clausura mínima. Encolado en incoming/; el worker lo muele tras la pasada
KDE. Es la pieza de supervisión que falta para la distro instalable (arje-zero=PID1 + openrc
sobre /etc/init.d). hash dry-run: b3:78502dcb.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El --disable-jit anterior movió el error de pcre2_jit_compile.o a pcre2_compile.o (pso_list): el
fondo NO era el JIT, era que los objetos del .a se compilaban SIN -fPIC. qtbase construye Qt SHARED
(BUILD_SHARED_LIBS=ON, libQt6Core.so) y linkea libpcre2-16.a DENTRO de ese .so; un .a no-PIC lleva
relocaciones absolutas R_X86_64_64 que ld.lld rechaza en un objeto compartido. El propio
pcre2-shared.toml ya lo documentaba: 'el canónico es --disable-shared SIN --with-pic ⇒ su .a no
enlaza dentro de un .so'.
Fix: --with-pic + CFLAGS=-fPIC ⇒ objetos position-independent, linkables en .so y en PIE. Convive
con el -no-pie del ejecutable pcre2grep (el audit static lo quiere). JIT queda off igual (W^X +
tablas frágiles). VERIFICADO: qtbase pasó el punto de fallo (objeto 400) y compila de largo (490+),
sin el 'relocation cannot be used against local symbol'.
Es un fix raíz del modelo static↔dinámico (Capa 0 KDE): cualquier consumidor .so del pcre2 canónico
lo necesitaba.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
qtbase falló al linkear: ld.lld 'relocation R_X86_64_64 cannot be used against local symbol' en
libpcre2-16.a(pcre2_jit_compile.o). El JIT de PCRE2 emite relocaciones absolutas en .rodata (sus
tablas de código generado) que son incompatibles con PIE — y TODO binario static musl de hammer se
enlaza PIE. No es un problema de Qt: es un landmine para el modelo entero; cualquier binario PIE que
linkee pcre2 con JIT lo pisa.
Fix raíz: --disable-jit. El regex queda un pelo más lento y la API NO cambia (pcre2_jit_compile
devuelve error si no hay JIT, los consumidores lo manejan). Rehashea pcre2 y sus dependientes, pero
ya estaban en deuda (lo re-sellé este ciclo con el arreglo static). Destraba qtbase → la raíz del
árbol KDE (↑117).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Las 7 recetas del stack gráfico (libdrm/mesa/meson/samurai/seatd/wayland/wayland-protocols) +
6 patches eran imports crudos de Alpine, redundantes: las 7 ya tienen receta CANÓNICA en recipes/
(mesa pineada a 24.0.9 iris-only A PROPÓSITO, no la 26.1.1 cruda con FIXME-sha256). Su trabajo
aterrizó por la vía canónica (7131cd4) hace 3 semanas; la cola quedó de cruft rompiendo cada ciclo.
fa45978 las sacó de QUEUES creyéndolas de 'otro agente' (5126a8b). Confirmado que NO hay otro
agente ⇒ borradas. recipes/incoming/ vuelve a ser cola de staging general y REGRESA a QUEUES; el
guard ls-vacío la salta si no hay nada. recipes/incoming/.deferred/ (24 recetas aparcadas con
diagnóstico, git con muro en libgit.a) NO se toca: el glob de QUEUES es top-level, no la muele.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mi hipótesis de partida era falsa y conviene dejarlo escrito: el libgcc_s.so.1 NO lo metía un
sys-crate en C, y -static-libgcc (el patrón de cmake) no aplicaba — ese patrón es para C/C++.
CAUSA REAL, una sola y compartida: ambas recetas PISABAN la fase compile del lab. El lab sólo
autogenera la fase si la receta no la trae (lib.rs:779, `if out.compile.is_none()`). Las dos venían
del import de Alpine con un `cargo build --frozen --release` propio que REEMPLAZA el comando del
lab entero, y con él las tres cosas que hacen honesto al link=static:
-C target-feature=+crt-static -C relocation-model=static -C linker=.hammer-zig-cc
Sin crt-static, el rust enlaza dinámico contra musl Y contra libgcc_s — que es el UNWINDER DE LA
STD DE RUSTC, no un sys-crate.
LA EVIDENCIA QUE LO CIERRA (contraste, sin bisectar): estaba ya escrita en recipes/cargo-hack.toml
—'receta MÍNIMA sin fase compile custom (una fase cargo build produce binario DINÁMICO; el PATH
DEFAULT del lab aplica crt-static + linker zig → estático)'. cargo-hack es Rust puro y sale
estático; tuc TAMBIÉN es Rust puro, sin una línea de C, y arrastraba el mismo libgcc_s. Misma
toolchain, único delta = quién arma el cargo.
tuc: borrada la fase compile (no aportaba nada sobre el default) + flags=["--bin","tuc"] (cargo
rustc exige un único target y tuc expone lib+bin homónimos). NEEDED=0, tuc 1.3.0 corre y
'hola,mundo | tuc -d, -f2' → mundo.
helix: la fase custom es OBLIGATORIA (exporta HELIX_DEFAULT_RUNTIME y HELIX_DISABLE_AUTO_GRAMMAR_
BUILD) ⇒ replicado a mano el setup del lab siguiendo cargo-edit. Su raíz es un manifiesto
VIRTUAL ⇒ 'cargo rustc' cortaba con 'is a virtual manifest'; resuelto con -p helix-term, que
declara [[bin]] name="hx". Sigue con compiler=gcc (el gueto cc-rs/tree-sitter es real).
NEEDED=0, helix 25.07.1 corre.
MARCADOR: static-audit global = estáticos de verdad: 680 | MIENTEN: 0. Con dos honestidades: el
audit corrió DESPUÉS de los rebuilds (si no, sobre-reporta), y quedan 58 'sin artefacto o sin ELF'
que NO son un pase sino recetas no medidas. El cero es real para lo que el store cubre hoy, no una
prueba de clausura.
TRAMPA ARMADA (no tocada): el riesgo generaliza a toda receta Cargo importada de Alpine que traiga
compile propio — alpine_import.rs traduce el build() del APKBUILD literal. Hoy las 5 con compile
propio llevan crt-static, pero cada receta Rust nueva puede nacer mintiendo. Un gate barato: que el
lab avise/falle si una receta Cargo con link=static define compile sin crt-static. Cambia el lab ⇒
re-hashea sellados ⇒ decisión aparte.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
De las 4, sólo 2 eran mentiras reales. Las otras 2 eran ARTEFACTOS RANCIOS: el audit hace
`ls -dt store/*-<n>` = el sellado MÁS RECIENTE, que no es el VIGENTE (hammer no expone el hash de
una receta sin construirla — no hay 'hammer hash' ni dry-run). Con el store desactualizado, el
audit acusa a recetas ya sanas. El propio script lo advierte ('correr DESPUÉS del rebuild, nunca
antes') y aun así la lista del frente se armó sin re-sellar. => el '11 mienten' está INFLADO;
hay que re-sellar antes de asumir que cada una necesita fix.
pcre2 — mentira real de libtool. NEEDED libz.so.1+libc.so → 0. -all-static en compile Y install.
pcre2grep 10.47 corre y matchea de verdad ('foo bar' con 'b(a|o)r').
libcap — mentira real, pero la causa NO era libtool: Makefile plano, -all-static no aplica.
progs/Makefile ASIGNA `LDFLAGS = -Wl,-Bstatic` + sufijo `-Wl,-Bdynamic`, y una asignación del
makefile PISA el LDFLAGS=-static del lab. El comentario de upstream admite que su default es
'estático contra libcap.a, DINÁMICO contra libc'. Fix = LIBCSTATIC=yes, la palanca que upstream
expone justo para esto (la usa su kdebug/test-kernel.sh) ⇒ rama con `LDFLAGS = --static` sin
sufijo. NO se pasa LDFLAGS por línea de comando: pisaría la rama y devolvería el sufijo.
NEEDED=0; capsh/getcap/setcap corren y getpcaps devuelve caps reales.
dbus — no mentía. Construye con MESON, no libtool ⇒ el agujero no existe acá. Ya tenía
--prefer-static -Ddefault_library=static: libdbus-1.a, cero .so, todos los binarios NEEDED=0.
Verificado end-to-end: dbus-run-session levantó un daemon estático y dbus-send ListNames obtuvo
method return. Sólo se documentó.
libnl — no mentía. Ya tenía --disable-shared --enable-static --disable-cli: 0 .so, 6 .a, sin
ejecutables (es el 'sin ELF: 1' del audit, esperado). libnl-3.a válido con nl_connect/
nl_socket_alloc como T. Sólo se documentó.
LECCIÓN: -all-static no es la única causa. Hay paquetes que pisan LDFLAGS por asignación de
makefile (libcap) y otros que ya están bien. Hay que LEER el Makefile, no aplicar el patrón a ciegas.
Van 9 de 11 (2 eran falsos positivos).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
naabu declaraba link=static y salía dinámica con NEEDED: libdl.so.2, libpthread.so.0, libc.so.6.
Ese libc.so.6 parecía GLIBC dentro de una distro musl — un cuerpo extraño. NO lo es.
CAUSA, y es la inversión contraintuitiva: CGO_ENABLED=0 es quien lo CAUSA, no quien lo evita.
naabu → Mzack9999/gopacket → ebitengine/purego v0.10.0, una FFI SIN cgo que dlopenea libpcap en
runtime. Su internal/fakecgo/zsymbols_linux.go está guardado con //go:build !cgo y hardcodea:
//go:cgo_import_dynamic purego_malloc malloc "libc.so.6"
//go:cgo_import_dynamic purego_pthread_create pthread_create "libpthread.so.0"
//go:cgo_import_dynamic purego_dlopen dlopen "libdl.so.2"
El linker interno de Go honra esos pragmas ⇒ emite binario dinámico (derrotando link=static) con
esos DT_NEEDED literales. Verificado en el artefacto: CGO_ENABLED=0 y purego v0.10.0 presentes.
NO hay glibc: el rootfs Alpine no tiene NI UN libc.so.6, y el INTERP es musl (se construyó en el
sandbox). La musl los absorbe — su ldso reserva esos nombres y los resuelve a sí misma. Strings
vestigiales, no dependencia real. Corre en musl puro (verificado con bwrap) y escanea de verdad.
OJO: en el laptop engaña — este host tiene glibc Y musl.
FIX = declarar la verdad. link=static es INALCANZABLE por diseño: purego existe para dlopen, y un
estático no puede dlopen. cgo=true tampoco sirve: el lab liga con -extldflags=-static ⇒ mismo muro,
y lobotomizaría el escaneo SYN en silencio.
DATO DURO: el binario nuevo es BYTE-IDÉNTICO al viejo ⇒ link=static nunca hizo NADA en recetas Go
(go build no lee LDFLAGS con CGO off): era pura declaración falsa. Las demás recetas Go pasan el
audit por accidente — sin purego, CGO_ENABLED=0 da estático natural.
TICKET APARTE (no tocado): naabu no declara libpcap y NO existe recipes/libpcap.toml. El escaneo
SYN —su feature principal— está INERTE hasta que exista. No es expresable en [deps] hoy: no se
linkea, se dlopenea.
Van 5 de 11.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Las dos enlazan con libtool, que lee el LDFLAGS=-static del lab como 'preferí mis .a' y no como
flag al linker ⇒ salían dinámicas (NEEDED: libc.so) jurando ser estáticas. Patrón conocido:
-all-static en compile Y en install (libtool RELINKEA al instalar; sólo en compile se pierde en
silencio). Nunca en configure.
file: el ./configure venía metido DENTRO de la fase compile (herencia del import de abuild,
envuelto en _abuild_phase()). Partido en configure/compile/install explícitos + --disable-shared
(sólo tenía --enable-static). NEEDED=0, file --version = file-5.47, y clasifica de verdad
(MAGIC=<art>/usr/share/misc/magic.mgc file /bin/sh → 'symbolic link to bash').
libgcrypt: ya tenía fases; sólo -all-static conservando --with-libgpg-error-prefix/--disable-doc.
NEEDED=0 en los 3 ELF (hmac256, dumpsexp, mpicalc) y hacen trabajo real: hmac256 devuelve un HMAC
efectivo, mpicalc '2 40 + p' → 42.
CONTROL del gotcha de xz (lista de ficheros vs el sellado viejo): idéntica en ambas — file conserva
libmagic.a + magic.mgc + mans; libgcrypt sus 3 binarios + libgcrypt.a + libgcrypt-config. No se
perdió nada.
Siguen con compiler="gcc" a propósito: el fix es ortogonal al compilador y migrarlas es el frente
matar-gcc. No hay evidencia nueva de que compilen con zig-cc — no se probó.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
756928a generalizó de más. El alcance real, medido dentro del sandbox con readelf sobre un
`int main(){return 0;}` trivial:
zig 0.13.0: -static → NEEDED=1 (dinámico) ← el bug
zig 0.13.0: -target x86_64-linux-musl -static → NEEDED=0 (estático)
zig 0.16.0: -static → NEEDED=0 (estático) ← default, sano
O sea: el -static roto es de ZIG 0.13.0, NO del framework. Con el zig default el -static que el
lab exporta por link="static" funciona ⇒ CC sin -target (sandbox.rs:415) está BIEN y NO hay que
re-hashear los 841 sellados, al revés de lo que decía 756928a. samurai lo sufría por caer en la
intersección de dos rarezas: pinea zig 0.13.0 Y no usa libtool (nada absorbía el -static).
Las otras 4 recetas con zig 0.13.0 + link=static (mtools/openssh/openssl/xorriso): auditadas,
0 mienten — usan libtool, que absorbe el -static por su cuenta.
pkgconf: el diagnóstico ORIGINAL (libtool se come el -static) era el correcto. Usaba el BuildSys
automático ⇒ fases explícitas sólo para meter -all-static en compile Y en install. Estático de
verdad (NEEDED=0).
Van 2 de 11: samurai, pkgconf.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
samurai declaraba link=static y salía DINÁMICO (NEEDED: libc.so). No usa libtool, así que el
patrón -all-static de jq/parted/shadow no aplicaba. Medido DENTRO del sandbox con readelf, sobre
un `int main(){return 0;}` trivial:
zig cc -mcpu=baseline -static → NEEDED=1 (dinámico)
zig cc -mcpu=baseline -target x86_64-linux-musl -static → NEEDED=0 (estático)
El lab exporta CC="zig cc -mcpu=baseline" SIN -target (sandbox.rs:415) ⇒ zig compila NATIVO,
detecta la musl de Alpine del rootfs (/usr/lib/libc.a existe) y enlaza contra ella IGNORANDO el
-static que el propio lab exporta por link="static". El -target fuerza la musl bundleada de zig.
Las recetas YA declaran target = "x86_64-linux-musl": el campo existe y no llega al CC. El fix
de framework re-hashea los 841 sellados ⇒ decisión aparte; por ahora va por receta.
samurai: estático de verdad (NEEDED=0), corre en el host, samu --version = 1.9.0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Segunda de las 3 con gcc oculto en las fases (tras bzip2). La receta declaraba
compiler=zig-cc y su compile pasaba CC=gcc ⇒ el gcc de Alpine hacía el trabajo.
El frente contaba compiler="gcc" y no miraba las fases, así que pigz nunca
figuró como deuda. Queda cargo-edit de esa terna.
CC="$CC" usa el zig cc que el sandbox exporta por default (lib.rs:269,
Compiler::ZigCc no pisa CC).
Verificado: 0 NEEDED, corre en el host (pigz 2.8), comprime/descomprime,
bit-repro b3:f5614e5b6b0a ×2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
367 ficheros, lista intacta vs el sellado viejo. b3:2a937a913b52
LDFLAGS="-all-static -no-pie" inyectado en las líneas make de compile e install.
samurai revertida: con -static su binario (samu) SIGUE dinámico ⇒ el control la
echó atrás. libcap revertida: mi regex rompió el TOML (parse error línea 37);
su make ya pasa CC/BUILD_CC/AR explícitos y necesita mano, no regex.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fases multilínea: LDFLAGS inyectado en las líneas make de compile e install.
Control de lista de ficheros intacta: libwebp 33, kbd 689, sudo 32, lsof 4.
libwebp b3:138b70a6962f · kbd b3:248de1120197 · sudo b3:6fdbe83990ef ·
lsof b3:d30ddb01b86e
mandoc revertida: no usa libtool ("Unknown Clang option: '-all-static'") y con
-static pierde binarios (apropos, demandoc) ⇒ el control la echó atrás. Necesita
otro enfoque, como xz y pcre2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
parted es el caso didáctico: YA tenía -all-static en compile — era el precedente
que citaban jq/shadow/procps-ng — y aun así salía dinámico, porque le faltaba en
INSTALL. libtool RELINKEA el binario al instalar y ahí pierde el flag. El
patrón citado estaba a medias, y por eso el propio precedente mentía.
libarchive: mismo patrón, forma de fase con comillas dobles.
Control de lista de ficheros intacta: parted 23, libarchive 55.
parted b3:1f2046dde4dd · libarchive b3:238f1fdfc704
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mismo patrón de libtool: LDFLAGS="-all-static -no-pie" en compile Y en install.
El control duro (lista de ficheros vs sellado viejo + 0 NEEDED en TODOS los
ejecutables, si no revierte) hizo su trabajo: pcre2 salió del build con
pcre2grep y pcre2test todavía dinámicos y se revirtió sola. Sin ese control
habría entrado como "arreglada" — es la misma trampa de xz, que devolvía rc=0
con el artefacto mutilado.
sqlite b3:235b18d98f18 (8 ficheros) · libgpg-error b3:8ccbe32ccb41 (36) ·
fontconfig b3:ad960af29ef5 (65) — todas con la lista de ficheros intacta.
Quedan 20: 9 con forma de fase distinta (mandoc, libwebp, kbd, parted, sudo,
libarchive, lsof, samurai, pkgconf, libcap: van a mano), pcre2 y xz que
necesitan otro enfoque, y 5 Rust (helix, yazi, git-absorb, cargo-audit, tuc)
que arrastran libgcc_s por crt-static, no por libtool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mismo patrón que curl: LDFLAGS="-all-static -no-pie" en compile Y en install,
porque libtool relinkea al instalar.
Verificado con un CONTROL que xz obligó a añadir: no basta rc=0 + hash. El
build de xz con -all-static devolvió rc=0 y hash válido, pero el artefacto SALIÓ
SIN NINGÚN BINARIO (el viejo tenía xz, xzgrep, xzdiff, xzless, lzmainfo): con
-all-static, libtool no produce la lib compartida (liblzma.la -rpath) y el
enlace de los ejecutables se saltea EN SILENCIO. Un "éxito" que mutila el
paquete. xz queda revertida: necesita otro enfoque (separar la lib de los
binarios), no este patrón.
⇒ el criterio ahora compara la LISTA DE FICHEROS del artefacto nuevo contra la
del viejo, además de NEEDED=0. Los tres pasan: 15, 13 y 114 ficheros, idénticos
a sus sellados previos.
expat b3:e6990b3e555f · libpng b3:f65887051274 · libxml2 b3:c4c65c4b17b8
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El frente contaba `compiler = "gcc"` y no miraba las FASES. bzip2 declaraba
compiler=zig-cc y decía "migrado de gcc, matar-gcc 2026-07-16" en la cabecera,
mientras su compile pasaba `CC=gcc`: migración cosmética, cambió el campo y no
el build. El Makefile de bzip2 además HARDCODEA CC=gcc, así que un `make` a
secas tampoco habría usado zig.
Barrido: 7 recetas invocan gcc en sus fases sin declararlo. 4 son escapes ya
conocidos (los 3 kernels + cmake); las otras 3 son deuda que nadie contaba:
bzip2 (ésta), pigz y cargo-edit.
De paso cumple link=static: el -static que hammer exporta (lib.rs:261) se
pierde si la receta no lo pasa al make de un Makefile custom.
OJO -static y NO -all-static: -all-static es flag de LIBTOOL (patrón de
jq/parted/shadow/procps-ng); bzip2 usa Makefile crudo y el flag llega tal cual
al compilador → "error: Unknown Clang option: '-all-static'".
Verificado: 0 NEEDED, corre en el host, comprime/descomprime, bit-repro
b3:48b91bb1b658 ×2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Primera de las 28 que static-audit.sh destapó. libtool ignoraba el -static del
lab (lo lee como "preferí mis .a"), así que el curl sellado salía dinámico con
NEEDED libz.so.1 + libc.so — y libc.so es el soname de la musl de zig, que en
el host son 255B de linker script. Resultado: el artefacto NO arrancaba fuera
del sandbox ("Error relocating /lib/libz.so.1: __snprintf_chk").
Fix: LDFLAGS="-all-static -no-pie" en compile Y en install (libtool relinkea
al instalar); nunca en configure, donde rompería los link-tests.
Verificado: 0 NEEDED, corre en el HOST (curl 8.20.0, OpenSSL/3.5.4, zlib/1.3.1)
y hace HTTPS real (http=200). Bit-repro: b3:19a919b28c25 ×2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
31 migradas. La justificación escrita ("gueto, como vim/nano/htop") había
caducado: vim/nano/htop ya estaban en zig-cc. Tres problemas reales, ninguno
"zig miscompila":
1. rpl_realloc: la musl que zig bundlea (estática) devuelve NULL para
realloc(p,0); AC_FUNC_REALLOC acierta y hace #define realloc rpl_realloc,
pero procps-ng no trae esa función (la pide por AC_LIBOBJ y ningún
Makefile.am usa @LIBOBJS@) ⇒ roto upstream en cualquier libc que conteste
"no". Se suprime el renombrado por cache vars; no afirmamos que realloc sea
GNU-compatible. Afectará a todo autoconf con AC_FUNC_REALLOC/MALLOC.
2. SIGSEGV: el binario salía musl-DINÁMICO con NEEDED libc.so. libtool lee el
-static del lab como "usá mis .a", NO como flag al linker ⇒ link=static
nunca se cumplió, ni con gcc. Fix con el patrón de jq/parted/shadow:
LDFLAGS="-all-static -no-pie" en compile Y en install (libtool relinkea al
instalar), nunca en configure.
3. UBSan: zig-cc lo activa por defecto; ps --sort=-rss aborta en sortformat.c
(offset sobre puntero nulo, UB genuino de upstream pero inocuo). Patrón de
libarchive/dwarves: -fno-sanitize=undefined.
Bit-repro verificado; 18 binarios responden y ps --sort da salida idéntica a gcc.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sin parches ni flags: el config.sub de wget 1.25.0 ya conoce -musl* y el
configure no se atraganta con AR="zig ar". Bit-repro verificado (2 builds
desde cero, mismo hash) y la ruta openssl viva (descarga HTTPS real, exit 0).
Como link=static, el ELF no tiene sección dinámica: cero NEEDED ⇒ no arrastra
libgcc_s/libstdc++ de Alpine. El comentario viejo listaba gcc como parte de la
de-Alpinización, que era justo al revés; corregido.
30 migradas. Quedan 17: 12 Rust con sys-crate C (cc-rs invoca el compilador del
sistema desde los build-scripts), 4 matraca dura, procps-ng en vuelo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
zlib-ng: el veredicto T5 hecho receta — dispatch SIMD en runtime en vez de
variantes v3; modo ZLIB_COMPAT, zlib.toml intocada (dep del frente rust).
dwarves: pahole para destrabar sched-ext; el kernel NO lo declara aún (el
análisis de repro BTF/pahole-skew va primero). Ambas al worker.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DOS ERRORES MÍOS, uno de dirección y otro técnico, los dos en la cosecha automática:
1. DIRECCIÓN: declaró `busybox` como dep en 29 recetas — cuando la Etapa C lo está
ELIMINANDO (USERLAND_COMPONENTS=[uutils,findutils,…], ya cerrada; joyas-reusables
§5 lo confirma: "uutils… Ubuntu 25.10 los envía como default"). Estaba cimentando
la deuda que el roadmap borra.
2. TÉCNICO: busybox YA está en el runtime base de harkaq (`ro /bin/busybox`, `ro
/bin/sh` — el sandbox corre `sh -c` y /bin/sh→/bin/busybox). Es CONTRATO, no dep.
Declararlo apila el busybox de hammer sobre el de Alpine y ROMPE el build:
binutils daba "cannot run C compiled programs" en las DOS máquinas. Verificado:
sin busybox declarado, binutils construye (b3:f4507dcd…). Y la cadena se explica:
binutils roto ⇒ zlib (que lo declara) tampoco construía.
Auditoría de la cosecha (diff real, no la línea completa del +): añadió sólo 5 deps
distintas — make ×73, busybox ×29, perl ×8, pkgconf ×5, binutils ×1. Sólo busybox
estaba mal; las otras 4 son deps reales medidas. busybox revertido de 30 recetas
(queda sólo en busybox.toml, pre-existente).
Es el mismo error que ya me habían señalado con otro disfraz: MEDIR BIEN Y ACCIONAR
MAL. harkaq midió correcto (el build toca /bin/busybox: es el shell); la acción
correcta no era declararlo sino reconocerlo como contrato.
+ COORDINACIÓN del §3 con Fable 5 (mismo diseño, tareas repartidas):
- Su lección casper queda CONFIRMADA y REFORZADA: la clausura de build no sólo le
FALTAN las clases del mundo (offline) — también le SOBRA casi todo (headers, gcc).
Medido: htop (estático, 0 NEEDED) no toca NADA al correr ⇒ política = su binario.
- Su "la clase viaja como campo de la ConcesionCapacidad, sin formato nuevo" se
cumple LITERALMENTE: lo firmado es format::Permisos = u32 bitmask en 36 bytes
canónicos (Ring 0) ⇒ las clases SON los bits. La cripto no se toca.
- Diseño unificado: frontera (clases, u32, declaradas) + detalle (paths, Landlock,
medidos). D3 rige en ambos.
- Reparto: clases→Fable 5; medición/harness→Opus. CONTACTO: runtime-policy.sh ahora
emite la CLASE detectada (/etc/resolv.conf→dns, /etc/ssl/certs→tls-certs, …), no
sólo el path: la medición alimenta la tabla, la tabla decide el bit.
- Consumidor esperando: plan-jaula-juegos F1 (Steam que no puede leer ~/.ssh).
+ juez.sh (§10): nombre único por corrida (con uno fijo pega en caché ⇒ falso
"sin evidencia"). Fue el juez quien destapó todo esto en su primera corrida real.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deps de Kconfig verificadas contra el tag v6.16.12 (kernel.org):
NTSYNC sin deps; SCHED_CLASS_EXT depende de DEBUG_INFO_BTF ⇒ tarea propia
(receta dwarves + repro de BTF). Re-sellado disparado en el worker.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PLAN-KIKIN §4.bis + HANDOFF-KIKIN-DESDE-HAMMER: el sustrato que kikin asume
(J4 = io_uring, J4b = Landlock/seccomp del anfitrión, eBPF = observabilidad)
tiene que venir COMPILADO en los kernels que hammer distribuye — «al azar del
defconfig» no es un contrato.
- linux-generic 7.1.2: re-sellado en el worker (5c5ef06c) y VALIDADO en QEMU:
config =y los cuatro, landlock_create_ruleset/io_uring_setup/bpf_prog_load
en kallsyms, y el re-test de input de mirada pasa (5 dispositivos, salida de
emergencia procesada). Imagen mirada-usb re-empaquetada con este kernel.
- linux-metal: mismos flags; se re-sella en el próximo build de imagen metal.
- linux.toml (soberano): NO tocado — su of_tree es load-bearing del
selfhost-verify; deuda anotada en la receta para el próximo re-ancle.
- SECURITYFS queda fuera (introspección opcional; harkaq usa el probe
landlock_create_ruleset(VERSION), que no lo necesita).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Las 2 'sin confirmar' del balance: el smoke-test no las verificaba por ser libs
sin binario, pero generan la lib con zig (libevdev.so, libmtdev.a). Migradas.
mtdev queda COMPLETAMENTE de-Alpinizado: config.sub soberano (patch de esta
sesión) + zig compiler ⇒ cero dependencia de Alpine. Era la única deuda de
soberanía del barrido harkaq y ahora está cerrada por entero.
Total matar-gcc: 29 recetas C migradas. Quedan 18 compiler=gcc (4 matraca-C
dura + 11 Rust + 3 no medidas).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
curl (dep de muchos) y libevent verificadas en laptop: construyen+corren con zig.
Total sesión: 27 recetas C migradas gcc→zig-cc.
BALANCE de las 47 que harkaq nombró:
27 MIGRADAS ✅ (deuda histórica: zig 0.13/0.16 segfaultaba, zig mejoró)
4 matraca real: libgcrypt/libsodium (crypto asm), file (magic), linux-pam
2 sin confirmar: libevdev, mtdev (libs, smoke-test no verifica)
11 Rust diferidas (gcc para el C embebido de sys-crates, otra evaluación)
matar-gcc pasó de '47 invisibles' (harkaq las reveló al leer el compiler=) a
27 cerradas + cola nombrada. Reporte: tandas/needs-review-harkaq/migracion-zig.md
OJO: re-hashea las 27 del índice firmado 748 ⇒ re-firma en próximo packaging.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Segunda tanda. Candidatas que el VPS marcó migrable; re-verificadas en el LAPTOP
(store completo, fiable) build+corre — 14/14, cero matraca:
freetype jq libassuan libgpg-error libssh2 libuv libxml2 nano pcre2 pigz socat
tig tmux vim
pcre2 tuvo una discrepancia transitoria (falló en una prueba local temprana con
"linker version script", migró en el VPS); re-verificado limpio en el laptop:
construye Y corre. Era estado transitorio, no incompatibilidad.
Confirma el patrón: el VPS acierta en las MIGRABLES (build+corre son evidencia
real); sólo erraba en las matraca (build-falla espurio por store parcial). La
medición fiable es el laptop.
Total matar-gcc esta sesión: 25 recetas C migradas (11+14). El frente pasa de 47
compiler=gcc a ~22 (las 25 migradas + las que faltan medir + las 11 Rust). OJO:
re-hashea, índice firmado 748 necesita re-firma en el próximo packaging.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Primera tanda del rollout aprobado. harkaq nombró 47 recetas compiler=gcc;
migra-zig.sh midió que las C-puras migran a zig (~85%). Estas 11 se verificaron
en el LAPTOP (store completo, fiable): construyen con zig-cc Y —las que tienen
binario— corren limpio.
bzip2 expat json-c gzip htop less libpng libyaml zstd libffi xz
El compiler=gcc era deuda histórica: se marcaron con zig 0.13/0.16 (que
segfaultaban C clásicos), zig mejoró, el gcc quedó por inercia. Verificado
in-place: bzip2→b3:86a33b76, json-c→b3:9cbe76e3.
11 dependencias menos del gcc de Alpine. Quedan ~25 C-puras candidatas del VPS
por verificar en el laptop (el store parcial del VPS daba build-falla espurios
por deps faltantes — la medición fiable es la del laptop) + las 11 Rust
(sys-crate C, otra evaluación).
OJO: re-hashea estas 11 (estaban en el índice firmado 748); el índice necesita
re-firma en el próximo packaging.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El único caso de deuda de soberanía del barrido: mtdev copiaba el config.sub/guess
del autoconf de ALPINE (/usr/share/autoconf/build-aux/) porque el suyo (1.1.6) no
conoce *-musl. harkaq lo cazó como lectura no declarada del rootfs.
CERRADO con recipes/mtdev-config-sub-musl.patch: 11 líneas, +`-musl*` a la
whitelist de OS del config.sub DEL PROPIO TARBALL. Ahora es input soberano
(hasheado con la receta), sin leer Alpine. Se quitó el `cp /usr/share/autoconf/...`
del configure. Verificado: mtdev construye (b3:47708e40) sin tocar /usr/share/autoconf.
Método (con un tropiezo honesto): casi afirmo que el `cp` era espurio porque el
config.sub en work/sources/mtdev daba exit 0 con musl — pero ese source estaba
MUTADO por un build previo (el cp lo había reemplazado por el de Alpine). El
tarball ORIGINAL fresco NO conoce musl (exit 1). Casi valido sobre un source
contaminado; me salvó chequear el exit code, no el output.
DESCUBIERTO AL CERRARLO: mtdev tenía DOS deudas de Alpine, no una. También usa
`compiler = "gcc"` (gcc de Alpine, no zig). Bajo la jaula la política deniega
/usr/bin/gcc (sonda esperada) y el configure da "C compiler cannot create
executables". Es parte de matar-gcc (kernel, cmake, mtdev), frente aparte.
LÍMITE DEL MODELO (nuevo, documentado en needs-review): harkaq clasifica gcc como
"sonda esperada" SIEMPRE, así que marca la fase Hermetico — pero para una receta
compiler=gcc, gcc es ESENCIAL y el build no compila sin él. harkaq no distingue
"gcc sondeado (ignorable)" de "gcc = el compilador". Caso límite real del
clasificador; no invalida el cierre de config.sub (producción no usa la jaula).
make declarado en mtdev (deuda declarable restante). config.sub fuera de
needs-review; queda anotado el gcc-compilador.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de
Landlock en un build real: el kernel vio al build usarla sin declararla, y el
store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5).
Recetas:bash binutils busybox bzip2
No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no
provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de
Landlock en un build real: el kernel vio al build usarla sin declararla, y el
store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5).
Recetas:dhcpcd strace
No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no
provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de
Landlock en un build real: el kernel vio al build usarla sin declararla, y el
store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5).
Recetas:coreutils elfutils expat file flex gawk
No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no
provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de
Landlock en un build real: el kernel vio al build usarla sin declararla, y el
store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5).
Recetas:sassc scdoc sed shadow socat sqlite tar tmux tree tzdata util-linux vim wget when which wpa_supplicant xorriso xz zlib
No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no
provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de
Landlock en un build real: el kernel vio al build usarla sin declararla, y el
store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5).
Recetas:gettext-tiny giflib git gnupg gperf gzip htop iproute2 jq kbd libassuan libcap libevent libffi libgcrypt libgpg-error libksba libnl libpng libsass libsodium libssh2 libudev-zero libusb libwebp libxml2 libyaml linux-generic linux-headers linux-metal linux-pam linux lz4 mandoc mtools musl nano npth openssh openssl parted pciutils pcre2 pigz procps-ng python3 readline rsync samurai ca-certificates curl doas dosfstools e2fsprogs fontconfig freetype
No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no
provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
recipes/linux.toml: -e SECURITY -e SECURITY_LANDLOCK -e AUDIT. Era lo único que
faltaba para que harkaq corra DENTRO de hammer (VM/metal) y no sólo en el laptop
y la granja. El CONFIG_LSM del defconfig ya lista `landlock` de primero ⇒ bastó
encenderlo, sin tocar la cadena de LSMs.
AUDIT se fija explícito aunque ya viniera =y por defconfig: sin él el kernel no
emite un solo registro y harkaq certificaría TODO como hermético en silencio
(§3.4). Es la precondición de la que cuelga la evidencia; no se deja al azar de
un default.
VERIFICADO BOOTEANDO, no leyendo el .config — que dice lo que se compiló, no lo
que el kernel hace al arrancar. Misma disciplina de §3.1 (el ABI se consulta por
syscall, jamás por versión) llevada a la verificación: el único que sabe si
Landlock está vivo es el kernel vivo. scripts/harkaq/vm-abi-probe.c es un /init
de initramfs mínimo que pregunta y apaga:
===== HARKAQ EN EL KERNEL DE HAMMER =====
LANDLOCK ABI = 7
audit de denegaciones (>=7): SI
=========================================
Kernel nuevo: b3:f2583d61… (el hash cambia, como se esperaba; el viejo
34755ff2… decía "# CONFIG_SECURITY_LANDLOCK is not set").
Con esto las 4 precondiciones de la Fase 1 están cerradas y harkaq corre en las
tres máquinas del proyecto: laptop (ABI 10), granja (ABI 7 tras el bump de la
golden) y el kernel propio de hammer (ABI 7).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
La única deuda irreducible del barrido (§4.10) era /usr/bin/perl en
ca-certificates y curl. Dos hallazgos al abrirla:
1. EL COMENTARIO DE ca-certificates.toml YA LO DECÍA, escrito por quien la portó:
"El resto del build (mk-ca-bundle.pl → cert.pem → split-ca-bundle.sh) usa el
perl + coreutils del rootfs". La deuda estaba escrita EN PROSA y era invisible
para el sistema; harkaq la convirtió en un veredicto. Es la tesis del §0 en una
línea: no hace falta que nadie DESCUBRA nada, hace falta que la máquina pueda
VER lo que ya se sabía.
2. LA RECETA TAMBIÉN EXISTÍA: recipes/incoming-kde/perl.toml, importada el 13/07
para la campaña KDE (syntax-highlighting e intltool exigen perl). CUARTA
convergencia independiente: dos campañas necesitaban el mismo binario y
llegaron por caminos que no se hablan.
Construye tal cual (b3:c7a899bd…) y con el artefacto en el store:
/usr/bin/perl → declarar dep: perl exit=0 ⇒ CERO deuda irreducible
EL BARRIDO DE 24 RECETAS QUEDA EN 0 IRREDUCIBLES. La métrica del §7 (<5%) se
cumple midiendo lo que la métrica quería medir: cosas que no sabemos construir.
Resultado: ninguna.
Receta promovida a recipes/perl.toml (no había canónica ⇒ sin colisión). Lo que
queda es mecánico y no es diseño: declarar `make` en las ~10 recetas que lo usan
y `perl` en ca-certificates/curl. OJO: eso re-hashea sus artefactos y son
paquetes del base-system (índice firmado 748) ⇒ decisión de rollout, no un sed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
harkaq (§4.6) dejó UN solo caso irreducible en el primer barrido: brotli pidiendo
libstdc++.so.6.0.34 + libgcc_s.so.1. Pero brotli es C, no C++ — la libstdc++ no
era suya: era de `cmake`, su dep de build.
store/99864dcc…-cmake/usr/bin/cmake
NEEDED: libstdc++.so.6, libgcc_s.so.1, libc.so
"gcc retenido para {kernel, cmake}" no era una concesión de BUILD-TIME como
sonaba: el artefacto de cmake arrastraba el runtime C++ de Alpine hacia dentro de
CADA build que lo declarara como dep. Un agujero de soberanía viajando por el
grafo de deps, invisible en la receta del consumidor. harkaq lo señaló desde el
consumidor, que es donde se ve.
EL ARREGLO NO TOCA EL COMPILADOR — gcc sigue compilando cmake (camino
conocido-bueno; zig c++ segfaultea el cmake mínimo). Sólo deja de enlazar su
runtime en dinámico:
CXX='g++ -static-libstdc++ -static-libgcc' LDFLAGS='-static-libstdc++ -static-libgcc'
Medido:
antes NEEDED: libstdc++.so.6, libgcc_s.so.1, libc.so
después NEEDED: libc.musl-x86_64.so.1 (y corre: cmake version 3.31.6)
EL PAGO: brotli —el único irreducible del barrido— pasa a Hermetico ×3 fases,
artefacto sellado b3:bc900676…. El barrido queda 0 irreducibles de 6. El caso que
iba a contar contra el <5% no era una receta mal escrita: era una herramienta de
hammer filtrando Alpine.
+ /proc como superficie de CONTRATO (lo destapó el configure de brotli, que lee
/proc/cpuinfo y /proc/meminfo): bwrap monta un /proc FRESCO dentro del pidns, no
sale del rootfs Alpine y no ve al host ⇒ contrato, no deuda. Mismo caso que
/cache. El hash del artefacto es idéntico antes y después de añadirlo: cambia el
veredicto, no el build.
COSTO DEL ROLLOUT: cambiar recipes/cmake.toml re-hashea cmake y sus 3
consumidores (brotli, libjpeg-turbo, libtiff = 6 sellados). Radio chico, PERO
libjpeg-turbo y libtiff son la cadena GUI y la regla es no rebuildearla en el
laptop (zig-skew rompe cairo) ⇒ el rebuild va al worker.
LO QUE NO CIERRA: /usr/bin/gcc, c89, c99, ldd y el plugin LTO (§4.7) siguen
siendo SONDAS — la jaula las deniega, los builds completan igual, y denegarlas es
lo correcto. El gcc de Alpine sigue en el rootfs y sigue haciendo falta para
{kernel, cmake} en BUILD-TIME. Lo cerrado es la filtración a RUNTIME, que es la
que contaminaba artefactos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TELEMETRÍA (el pedido): el rootfs de la imagen es un initramfs = RAM pura y los logs iban a /run (tmpfs)
⇒ al apagar la máquina ajena no sobrevivía NADA. Ahora la imagen lleva 2da partición FAT32 MIRADALOG
(512M), montada por findfs+LABEL con -o sync (un cuelgue de GPU o corte de luz no se lleva los logs).
Cada arranque vuelca run-NNNN/ con: resumen (modo/GPU/driver), hardware (PCI vía sysfs, módulos, DRM,
input, firmware), pantallas (status/modes por conector), dmesg ANTES y DESPUÉS de mirada, seatd, y el log
del compositor+greeter con RUST_LOG=wgpu_core=debug + EGL_LOG_LEVEL=debug + LIBGL_DEBUG=verbose (para ver
por qué wgpu eligió el backend y si hay float16). Shell de rescate + . FAT32 a propósito: el
pendrive se lee después desde cualquier SO.
metal-usb-sdboot.sh gana DATA_MB/DATA_LABEL genéricos (partición de datos opcional en la GPT).
GOTCHAs verificados antes de confiar: el kernel linux-generic SÍ trae VFAT_FS=y + NLS + USB_STORAGE=y
(sin eso no montaba); el busybox de Alpine NO trae el applet 00:00.0 Host bridge: Intel Corporation Tiger Lake-UP3/H35 4 cores Host Bridge/DRAM Registers (rev 01)
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01)
00:07.0 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #0 (rev 01)
00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module (rev 01)
00:0a.0 Signal processing controller: Intel Corporation Tigerlake Telemetry Aggregator Driver (rev 01)
00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01)
00:12.0 Serial controller: Intel Corporation 500 Series Chipset Family On-Package Integrated Sensor Hub (rev 20)
00:14.0 USB controller: Intel Corporation 500 Series Chipset Family On-Package USB 3.2 Gen 2x1 (10 Gbs) xHCI Host Controller (rev 20)
00:14.2 RAM memory: Intel Corporation 500 Series Chipset Family On-Package Shared SRAM (rev 20)
00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)
00:15.0 Serial bus controller: Intel Corporation 500 Series Chipset Family On-Package I2C Controller #0 (rev 20)
00:15.1 Serial bus controller: Intel Corporation 500 Series Chipset Family On-Package I2C Controller #1 (rev 20)
00:16.0 Communication controller: Intel Corporation 500 Series Chipset Family On-Package CSME HECI #1 (rev 20)
00:1c.0 PCI bridge: Intel Corporation 500 Series Chipset Family On-Package PCI Express Root Port #5 (rev 20)
00:1d.0 PCI bridge: Intel Corporation 500 Series Chipset Family On-Package PCI Express Root Port #9 (rev 20)
00:1f.0 ISA bridge: Intel Corporation 500 Series Chipset Family On-Package eSPI Controller (rev 20)
00:1f.3 Multimedia audio controller: Intel Corporation 500 Series Chipset Family On-Package High Definition Audio (HD Audio) (rev 20)
00:1f.4 SMBus: Intel Corporation 500 Series Chipset Family On-Package System Management Bus (SMBus) (rev 20)
00:1f.5 Serial bus controller: Intel Corporation 500 Series Chipset Family On-Package SPI (flash) Controller (rev 20)
39:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. NV2 NVMe SSD [SM2267XT] (DRAM-less) (rev 03)
3a:00.0 Non-Volatile memory controller: ADATA Technology Co., Ltd. IM2P33F3 NVMe SSD (DRAM-less) (rev 03) (sí findfs/blkid) ⇒ el dump de PCI
lee /sys/bus/pci/devices/*/ directo; sintaxis del init validada con busybox ash (no bash).
BUMP mirada: el pin era 9967b02c (18-jun) — 439 commits viejo. Ahora 9a17fefc, que incluye el fix de
portabilidad a musl que hice en tawasuyu (ioctl: glibc usa c_ulong, musl c_int ⇒ las constantes DRM
casteaban mal y mirada-compositor NO compilaba para musl). mirada-compositor ya selló (87ced528);
greeter/ctl en curso.
+ scripts/kde/{metal-desktop-image,plasma-start-metal}.sh del hilo KDE (imagen de escritorio en metal).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
spectacle 6.7.2 (7a6db883) → /usr/bin/spectacle. Cierre VERIFICADO, los 6 componentes de la cadena:
libKPipeWireRecord.so.6 + libopencv_core.so.410 + libopencv_imgproc.so.410 + libtesseract.so.5.5 +
libKF6PrisonScanner.so.6 + libKQuickImageEditor.so.1.
Cadena nueva completada en esta tanda:
ffmpeg 7.1 faafef5e libavcodec/avutil/avformat/avfilter/swscale — kpipewire los exige los
4 REQUIRED. ffmpeg NO usa autotools: su configure toma --cc/--ar/
--ranlib, y hay que darle wrappers de UN SOLO TOKEN (--ar="zig ar" con
espacio se ejecutaría como binario único — mismo gotcha que el AR de
los crates 'cc'). **--disable-autodetect** = determinismo: sin él
configure escanea el sandbox y activa libs a discreción.
libva 2.22.0 121cd0de libva.so + libva-drm.so, REQUIRED por kpipewire. Sólo la capa de
despacho; los drivers reales son RUNTIME (dlopen). Sólo backend DRM.
kpipewire 6.7.2 745665f3 KPipeWire + KPipeWireRecord. Deps: pipewire + ffmpeg + libva + gbm/EGL
(mesa) + libepoxy.
kquickimageeditor 0a4f8156 **BUMP 0.5.0 → 0.6.2.1**: spectacle 6.7 incluye
<KQuickImageEditor/AnnotationDocument>, que NO existe en la serie 0.5
(no tiene src/annotations). La 0.6.x suma deps propias: KF6Config
REQUIRED + OpenCV 4.7 (stack blur, WITH_OPENCV=TRUE por defecto).
Por qué era cara: TODO en spectacle es REQUIRED y casi nada degradable. En particular **KPipeWire no se
puede esquivar**: find_package va sin REQUIRED y set_package_properties lo marca TYPE REQUIRED (eso sí se
degrada con sed), pero src/CMakeLists.txt:101 linkea K::KPipeWireRecord INCONDICIONALMENTE.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pipewire (6d15a22c) → libpipewire-0.3.so.0 + libspa-* + daemon 'pipewire' + **'pipewire-pulse'** (habla
el protocolo PulseAudio, así que los clientes libpulse ya sellados le hablan) + tools (pw-cli/pw-play/
pw-record/pw-mon/pw-dump/...). Cierra el lado SERVIDOR del audio: hasta ahora sólo teníamos el CLIENTE
(libpulse con -Ddaemon=false).
Dos frentes lo necesitaban: (1) audio real de Plasma 6; (2) spectacle → kpipewire → pipewire.
Fuente del gitlab.freedesktop.org (como networkmanager/modemmanager). Recortado al core+SPA: sin bluez5
(arrastraría los códecs aptx/ldac/aac/opus), sin jack/v4l2/libcamera/gstreamer/ffmpeg/vulkan/roc/lv2/
avahi/x11/echo-cancel-webrtc/libusb/flatpak/snap; systemd/logind/selinux/rtkit off (no hay systemd).
alsa+sndfile+libpulse+dbus+udev enabled (las 4 ya selladas).
GOTCHA static-vs-shared (variante nueva del patrón): **sin ncurses a propósito**. Su única consumidora es
la tool pw-top (monitor de terminal), guardada por 'if ncurses_dep.found()'. El ncurses del catálogo es
static-only y su .pc arrastra '-static' al link ⇒ 'error: using shared libraries requires dynamic linking'
al enlazar pw-top contra libpipewire-0.3.so. Quitando la dep, meson saltea pw-top y el resto construye.
(Alternativa futura si se quiere pw-top: variante ncurses-shared.)
Próximo: ffmpeg → kpipewire → spectacle.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Selladas:
leptonica 1.85.0 e80a5d36 procesamiento de imagen; dep dura de tesseract. Codecs recortados a
las variantes .so/PIC que ya tenemos (libjpeg-turbo-shared +
libpng-shared + zlib-shared); TIFF/WEBP/OPENJPEG/GIF off.
tesseract 5.5.0 08c05238 OCR. spectacle lo exige DURO: pkg_check_modules(TESSERACT REQUIRED)
en CMakeLists:111, sin option() para apagarlo. Sólo la lib (sin
training tools, que piden pango/cairo/icu).
kquickimageeditor 0.5.0 3d4bd904 editor de imagen QtQuick; spectacle lo marca TYPE REQUIRED.
spectacle.toml se commitea CON su blocker documentado en la cabecera (misma convención que usaba
networkmanager-qt): **KPipeWire**. find_package(KPipeWire) va sin REQUIRED y set_package_properties lo
marca TYPE REQUIRED (eso se degrada con sed), PERO src/CMakeLists.txt:101 linkea
INCONDICIONALMENTE ⇒ no hay forma de compilar sin él. Falta la cadena pipewire → (ffmpeg, para
KPipeWireRecord) → kpipewire.
El resto de su cadena YA quedó resuelto y sellado esta sesión: opencv + prison-scanner + zxing-cpp +
tesseract + leptonica + kquickimageeditor + xcb-util-cursor (sin este último: 'No suitable backend
platform was found ... XCB-CURSOR').
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
sergioandClaude Opus 4.8