takana etapa 5c: comentarios de scripts, MOTD, y un BUG que introdujo la etapa 4
250 líneas de comentario en 151 scripts. Control verificado: el diff no toca NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa. El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces: las tres eran el MOTD que el script escribe DENTRO de la imagen construida — texto del producto, no comentario del script. Se cambiaron aparte y a propósito, que es rebranding, no limpieza. Y el hallazgo caro: casaba contra , que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate. La etapa 4 lo movió a y el script quedó casando NADA. No fallaba: imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja. Además 14 rutas de módulo en docs, que el barrido anterior no tocó porque no es frontera de palabra.
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env bash
|
||||
# complete-closure.sh — completa el cierre RUNTIME de un FHS hidratado: escanea los `NEEDED` (DT_NEEDED)
|
||||
# de cada ELF del rootfs y, por cada soname AUSENTE, proyecta del store SELLADO el artefacto que lo
|
||||
# provee (`hammer hydrate`). Itera hasta punto fijo. Resuelve las deps runtime que el índice del repo NO
|
||||
# provee (`takana hydrate`). Itera hasta punto fijo. Resuelve las deps runtime que el índice del repo NO
|
||||
# lista (p.ej. libmount.so.1 de util-linux, dep de build de kcoreaddons pero .so runtime de libKF6CoreAddons).
|
||||
#
|
||||
# Sonames del SUSTRATO base (musl libc, loader, libgcc) NO se hidratan: los provee la base soberana del
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env bash
|
||||
# hydrate-fhs.sh — hidrata un FHS runtime KDE desde el repo firmado, instalando el CIERRE completo.
|
||||
#
|
||||
# `hammer install <pkg> --prefix P` sólo hidrata los archivos de <pkg>, NO de su cierre. Para un
|
||||
# `takana install <pkg> --prefix P` sólo hidrata los archivos de <pkg>, NO de su cierre. Para un
|
||||
# rootfs runtime usable (que capture todas las `.so`), hay que instalar cada paquete del cierre en el
|
||||
# MISMO prefix (igual que product-userland-from-repo.sh). El store del worker está caliente ⇒ cache-hit.
|
||||
#
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# hydrate-from-store.sh — hidrata un FHS runtime KDE PROYECTANDO artefactos SELLADOS del store, SIN
|
||||
# reproduce ni rebuild (`hammer hydrate <hash> --into`). Es la vía correcta para el escritorio completo:
|
||||
# reproduce ni rebuild (`takana hydrate <hash> --into`). Es la vía correcta para el escritorio completo:
|
||||
# `install` reproduce-desde-fuente y el hashing determinista es frágil bajo el régimen dinámico (cada
|
||||
# consumidor puede recomputar un hash distinto de qtbase → rebuild). Aquí se toma la salida ya sellada
|
||||
# por la granja.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
# NVIDIA Pascal/nouveau) con render por SOFTWARE (mesa-llvmpipe soberano). USB "live" que se adapta a la
|
||||
# máquina donde se bootee. Ver [[kde-metal-qemu-desktop]] y el runbook docs/runbooks/kde-qemu-desktop.md.
|
||||
#
|
||||
# Por qué software y no iris/nouveau HW: el mesa hammer-built es swrast/llvmpipe; una mesa HW con nouveau
|
||||
# Por qué software y no iris/nouveau HW: el mesa takana-built es swrast/llvmpipe; una mesa HW con nouveau
|
||||
# hoy sólo existe como binario Alpine (rompe soberanía). llvmpipe sobre el KMS del kernel (i915 O nouveau)
|
||||
# funciona idéntico en ambas máquinas y reusa los fixes ya validados. HW-accel = iteración siguiente.
|
||||
#
|
||||
@@ -116,7 +116,7 @@ PY
|
||||
rm -f "$MERGED/etc/motd" # romper el hardlink: `cat >` escribiría el inodo COMPARTIDO con work/metal-rootfs
|
||||
cat > "$MERGED/etc/motd" <<'MOTD'
|
||||
|
||||
#-- hammer :: escritorio KDE Plasma 6 (metal, dual-GPU software) ------------
|
||||
#-- takana :: escritorio KDE Plasma 6 (metal, dual-GPU software) ------------
|
||||
Render por software (llvmpipe soberano) sobre i915 (Intel) o nouveau (NVIDIA).
|
||||
|
||||
Arrancar el escritorio: plasma-start
|
||||
|
||||
@@ -46,7 +46,7 @@ chmod 1777 "$MERGED/tmp"
|
||||
# motd: que el usuario sepa qué correr al llegar al shell.
|
||||
cat > "$MERGED/etc/motd" <<'MOTD'
|
||||
|
||||
#-- hammer :: escritorio KDE Plasma 6 (metal) ------------------------------
|
||||
#-- takana :: escritorio KDE Plasma 6 (metal) ------------------------------
|
||||
Todo construido desde fuente con hammer (musl + zig-cc), sin binarios ajenos.
|
||||
|
||||
Arrancar el escritorio: plasma-start
|
||||
|
||||
@@ -67,7 +67,7 @@ echo "==> inyectando musl (loader + libc) — los binarios KDE son dinámicos"
|
||||
# La base metal es 100% ESTÁTICA (arje-zero+busybox) y el KDE-rootfs no trae libc ⇒ el merge no tiene
|
||||
# loader musl. Los binarios KDE piden interp /lib/ld-musl-x86_64.so.1 + NEEDED libc.so (única lib base
|
||||
# que falta; el resto del closure Qt/KF6 está). Copiamos el musl soberano del host (mismo que corre la
|
||||
# mirada del laptop ⇒ ejecuta binarios hammer-musl dinámicos). En musl el loader ES libc (mismo fichero).
|
||||
# mirada del laptop ⇒ ejecuta binarios takana-musl dinámicos). En musl el loader ES libc (mismo fichero).
|
||||
MUSL="${MUSL:-/usr/lib/musl/lib/libc.so}"
|
||||
[ -r "$MUSL" ] || { echo "no encuentro musl libc ($MUSL) — set MUSL=" >&2; exit 1; }
|
||||
mkdir -p "$MERGED/usr/lib/musl/lib" "$MERGED/lib"
|
||||
|
||||
Reference in New Issue
Block a user