553fc1fb7db33fab0012832f63f8ca3455809d2d
803
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Sergio
|
553fc1fb7d |
wasi-libcxx: el eslabón que faltaba en la cadena wasm (lo encontró el build)
El firefox con RLBox murió en el configure a los SEIS SEGUNDOS:
/tmp/conftest.cpp:1:10: fatal error: 'cstring' file not found
ERROR: Cannot find wasi headers or problem with the wasm compiler.
El mensaje culpa a los headers de WASI y los headers de WASI estaban perfectos.
`<cstring>` es un header de C++ y `wasi-libc` sólo trae la C: las librerías que
RLBox enjaula no son todas C —graphite2 es C++— así que el sandbox necesita una
biblioteca estándar de C++ para wasm32. Mismo patrón que la lección de los
headers UAPI: el error nombra lo que buscó, no lo que falta.
El hueco estaba en el GRAFO antes de que el build lo encontrara, y se podía ver
sin construir nada: el `wasi-sdk` de Alpine declara
`depends="wasi-libc wasi-libcxx wasi-compiler-rt"` —TRES— y nosotros teníamos
dos. Queda anotado como método: cuando se porta una cadena ajena, la lista de
depends del paquete equivalente es una comprobación de completitud gratis.
La receta es el mismo tarball de LLVM 22.1.8 que `wasi-compiler-rt` (mismo
sha256) y repite su transcripción del toolchain file de wasi-sdk, por el mismo
motivo: 38 líneas de declaraciones puras no justifican una fuente de red y una
receta. Si se toca una, se toca la otra.
Dos detalles que son trampas y no adorno:
- Se construyen los DOS triples (wasip1 y wasip1-threads). `wasi-libc` ya publica
los dos y firefox pide el sysroot por nombre de triple, así que dejar uno sin
libc++ sería presente-a-medias, que es peor que ausente.
- cmake instala en el triple canónico (`wasm32-unknown-wasip1`) y clang busca en
el corto (`wasm32-wasip1`). Sin el renombre del install, libc++ queda al lado
del sitio donde se la busca: en el artefacto e invisible para el compilador.
El guardián exige exactamente lo que el configure no encontró —`cstring`,
`libc++.a` y `libc++abi.a`— para los dos triples.
Re-hashea: wasi-sdk b3:c8a587fa -> b3:f13634c6, firefox b3:98d6899a ->
b3:2880e28a.
|
||
|
Sergio
|
65ee20e437 |
firefox: guardián que exige RLBox EN EL BINARIO, no en el configure
Tercera repetición de la misma lección en esta receta, y por eso nace junto con la bandera y no después: `--with-wasi-sysroot` es exactamente la clase de opción que el configure acepta sin chistar y que puede no llegar al artefacto. Ya pasó dos veces acá (MOZ_REQUIRE_SIGNING y MOZ_BUILD_DATE) y las dos veces el síntoma apareció lejísimos, sin nombrar la bandera. Acá el fallo sería el más caro de los tres: un firefox que dice tener enjaulados los parsers de fuentes y medios —graphite, ogg, expat, woff2, o sea el código que come entrada NO confiable de la red— y no los tiene. Una promesa falsa de seguridad es peor que no ofrecerla (§4 del SDD 26, mismo criterio que el modelo de adversario de qullqa). El discriminante está MEDIDO, no supuesto: sobre el artefacto b3:352d7880 —el último con RLBox apagado, 224 MB de libxul.so— los tres patrones (w2c_, rlbox, wasm2c) dan CERO. Así que cualquiera apareciendo prueba que la jaula entró. Se aceptan los tres y no sólo `w2c_` a propósito: el prefijo exacto es un detalle de la versión de wasm2c, y un guardián que falla por un cambio de convención de nombres tira 4 h de build por algo que no está roto. Lo que no puede pasar desapercibido es que los tres sigan en cero. El método de comprobar el artefacto y no la doc lo aportó la sesión hammer-f8. Re-hashea: b3:dba8fbf9 -> b3:98d6899a. Entra en el build que arranca ahora, que es justamente para lo que se agrega antes y no después. |
||
|
Sergio
|
ff0b5567d6 |
firefox: RLBox ENCENDIDO — --without-wasm-sandboxed-libraries -> --with-wasi-sysroot
Cierra la unidad 3.b del SDD 26. El flag que se va apagaba la jaula wasm que envuelve a los parsers de fuentes y medios (graphite, ogg, expat, woff2), o sea el código que come entrada NO confiable de la red. Estaba apagado por una razón honesta —«el SDK de WASI no está en ninguna cola»— que dejó de ser cierta hace un commit: la cadena wasi-libc-headers -> wasi-compiler-rt -> wasi-libc -> wasi-sdk sella entera. El flag nuevo es LITERALMENTE el de Alpine, verificado hoy trayendo su mozconfig de community/firefox: `--with-wasi-sysroot=/usr/share/wasi-sysroot`, que es la misma ruta donde instala nuestro wasi-libc. Las deps van las TRES y no es redundancia: en hammer las deps NO son transitivas —el bwrap apila como overlay sólo lo que está escrito en la lista— así que declarar sólo `wasi-sdk` no arrastraría al `wasi-libc` que necesita, y ése es el peor fallo posible de esta cadena: el sysroot no existiría y el error saldría horas después, hablando de un header de wasm sin nombrar a ninguna receta. Alpine declara wasi-compiler-rt + wasi-sdk porque su wasi-sdk YA trae el sysroot dentro; el nuestro está partido en cuatro, así que la lista es distinta a propósito. Esto re-hashea firefox: b3:352d7880 -> b3:dba8fbf9. Es un rebuild largo y va a la máquina que corresponde, no a gioser (4c/7,6 G sin swap). |
||
|
Sergio
|
85a393aff4 |
cadena wasm completa: wasi-libc y wasi-sdk sellan (SDD 26, unidad 3.b)
Los cuatro eslabones que enciende RLBox en firefox, sellados de punta a punta:
wasi-libc-headers b3:54c6e96d (andamio, rompe el ciclo del bootstrap)
wasi-compiler-rt b3:a3fe63d1 (libclang_rt.builtins-wasm32.a)
wasi-libc b3:8e50b145 (libc.a 970.734 bytes, 32 archivos .a)
wasi-sdk b3:c8a587fa (el .cfg que hace el sysroot invisible)
Los dos primeros ya estaban construidos; los dos últimos costaron dos fallos, y
ninguno de los dos era de la receta:
1. `check-symbols` moría por SESGO DE CLANG, no por un artefacto malo. El lab
trae clang 22.1.8 y este commit de wasi-libc (2025-06-26) congeló su snapshot
de macros predefinidos contra un clang anterior, así que el diff completo era
UNA línea: `+#define __wasip1__ 1`. La mitad que importa —los símbolos
definidos e indefinidos de la libc recién construida— coincidía byte a byte.
Por eso se RECONCILIA `expected/*/predefined-macros.txt` en vez de saltar el
chequeo con `make no-check-symbols`, que era la salida fácil: ese target
existe y se lleva por delante también la comparación de símbolos, que es la
que vale. Así cualquier OTRA deriva sigue matando el build.
2. `make TARGET_TRIPLE=NOBUILD ... install` NO es un no-op. La regla `install`
depende de `finish`, que depende de `libc`, así que make no lee el triple
inexistente como «no construyas» sino como «construí para el triple NOBUILD»
y muere en `build/NOBUILD/.../crt1-command.o` con `invalid thread model
'single'` — un error que nombra un fichero que nadie pidió. Se copia
`sysroot/{lib,share,include}` a mano, que es literalmente lo que hace la
regla de upstream (`SYSROOT ?= $(CURDIR)/sysroot`).
Cada receta lleva su guardián de contenido, porque acá el modo de fallo caro no
es el ausente sino el vacío: un sysroot con headers y sin libc.a pasa por bueno
y revienta dentro del build de firefox, horas después y sin nombrar a nadie de
esta cadena. Verificado en verde: los builtins son objetos wasm de verdad
(magic 0061736d, no x86_64 nativos) y el .cfg de wasi-sdk apunta a un sysroot
que existe.
El segundo fallo lo diagnosticamos entre dos sesiones: hammer-f8 aportó el
`invalid thread model 'single'` que explicaba la línea que yo veía.
Queda para la próxima unidad el flip de recipes/firefox.toml:
--without-wasm-sandboxed-libraries -> --with-wasi-sysroot, que es un rebuild
largo y su propia unidad de trabajo.
|
||
|
Sergio
|
1505bfad78 |
licencias: ffmpeg y LLVM salen del árbol — «lo decide un humano» era «lo decide la receta»
Tres que había clasificado como decisión legal y no lo eran. Las dos causas son distintas y las dos me las estaba perdiendo por mirar sólo el árbol: **ffmpeg → LGPL-2.1-or-later.** Su raíz trae cuatro COPYING.* y por eso el detector se planta, con razón: el árbol solo no puede decidir. Pero el `LICENSE.md` del propio ffmpeg explica la regla —«In combination the LGPL v2.1+ applies to FFmpeg» y «None of these parts are used by default, you have to explicitly pass `--enable-gpl`… In this case, FFmpeg's license changes to GPL v2+»— y la respuesta la da NUESTRA receta: no pasa `--enable-gpl` ni `--enable-version3`, y encima va con `--disable-autodetect`. O sea que la licencia sale de cruzar el árbol con los flags, no de elegir uno de los cuatro ficheros. **llvm18 y clang18 → Apache-2.0 WITH LLVM-exception.** Acá el detector veía «tres licencias distintas» en un solo `LICENSE.TXT` y se plantaba, pero el fichero ABRE diciendo «The LLVM Project is under the Apache License v2.0 with LLVM Exceptions»: lo demás es la sección legada. La regla de «varias licencias ⇒ decide un humano» es correcta como default y aquí el humano sólo tuvo que leer la primera línea. `licenses/` pasa de 48 a 49 textos: `LLVM-exception` hacía falta para poder declararla, que es el lazo de siempre —no se declara lo que no se puede entregar—. El único sin texto canónico sigue siendo `LicenseRef-qorpa-ajena-no-enumerable`, que es identificador nuestro y SPDX no publica. 97% (1135/1165); la cola baja de 27 a 24. Los 3 ArtifactHash, idénticos. |
||
|
Sergio
|
e348c97964 |
aichat: era NO REPRODUCIBLE, y la causa estaba en el build.rs de un crate transitivo
`scripts/verificar-repro.sh` lo cazó en el worker: dos reconstrucciones seguidas, misma máquina y mismo lab, dan `usr/bin/aichat` distintos. Es el primer no-determinismo REAL que el instrumento encuentra —hasta hoy todo lo que había marcado era deriva— y salió porque el arreglo de esta tarde conserva los dos ejemplares en `store/.divergen/` en vez de borrarlos. `hammer why-differs` dijo `.rodata`. El primer byte que cambia (offset 1749687) cae dentro de un JSON de *stopwords* por idioma embebido en el binario, y lo que difiere no es el contenido sino el ORDEN: una build empieza por `"sl"` y la otra por `"fi"`. De ahí a la causa: el crate es `stop-words` 0.8.1, transitivo vía bm25, y su `build.rs` arma un `HashMap<String, Vec<String>>` y lo serializa con `serde_json::to_string`. El `HashMap` de Rust usa `RandomState` —semilla ALEATORIA POR PROCESO— así que el orden de serialización cambia en cada compilación y ese JSON se hornea en el binario. `BTreeMap` serializa en orden de clave. Es un arreglo de una palabra que upstream no hizo. Se parchea el crate vendorizado en una fase `configure` (el vendoreo ocurre ANTES de las fases, así que el árbol ya está ahí) y se vacía la lista de ficheros de su `.cargo-checksum.json`, por la misma razón y con la misma técnica que `recipes/firefox.toml`: cargo verifica el sha de cada fichero vendorizado y no ofrece forma de recalcularlo. Los `[ -f ]` fallan ruidoso a propósito. Si mañana la cadena de deps deja de traer stop-words, lo peor sería que el parche se saltara en silencio y el binario volviera a ser aleatorio sin que nadie se entere — que es exactamente cómo esto llegó hasta acá. Re-hashea aichat (b3:c40a15bd → b3:7a515b0a), y eso es gratis: `yupana radio` da 0 dependientes y ninguna imagen lo declara. |
||
|
Sergio
|
59a0e56a16 |
licencias 97% (1132/1165): «no hay fichero» y «no reconozco el texto» no son lo mismo
El script decía «sin COPYING ni declaración en el árbol» para `lsof`, `when`, `wpa_supplicant`,
`perl-xml-parser` y `fuse3` — y las cinco SÍ tienen un COPYING o un LICENSE en la raíz. Lo que
pasaba es que ninguna de mis huellas reconocía su texto, que es un problema distinto y se acciona
distinto: uno pide buscar la licencia en otro sitio, el otro pide una huella nueva o leerla. Decir lo
mismo de los dos casos mandaba a mirar donde no era. Ahora el mensaje nombra el fichero y cita su
primera línea, y con eso tres se resolvieron leyéndolas:
· `wpa_supplicant` — su COPYING no es una licencia sino un aviso: «the project has chosen to use
only the BSD license option for future distribution», y remite al README. El README trae las tres
cláusulas clásicas ⇒ BSD-3-Clause. Sin seguir esa remisión no había veredicto posible.
· `when` — «under the same terms as Perl, or, at your option, under version 2 of the GPL». «Los
mismos términos que Perl» ES la disyunción Artistic-1.0-Perl OR GPL-1.0-or-later, y la opción de
GPL-2 ya queda cubierta por el `-or-later`.
· `perl-xml-parser` — su LICENSE es el texto íntegro de la Artistic License 2.0.
Ese último obligó a cerrar un lazo que yo mismo había dejado abierto: el script se niega a declarar
un SPDX cuyo TEXTO no tengamos en `licenses/`, porque la obligación legal es entregar el texto y no
el nombre. Pero `licencias-textos.sh` deriva qué textos bajar DE las licencias ya declaradas ⇒ una
licencia genuinamente nueva no podía entrar por ningún lado. El orden que lo resuelve es: declarar
con evidencia, bajar el texto, comprobar que llegó. `licenses/` pasa de 44 a 48 textos y el único que
queda sin texto canónico es `LicenseRef-qorpa-ajena-no-enumerable`, que es un identificador nuestro y
SPDX no publica.
Quedan 33. `lsof` (licencia propia de Purdue) y `fuse3` (aviso compuesto: LGPL para la librería, GPL
para las utilidades) siguen pendientes a propósito, y el resto son expresiones que decide una
persona: gmp, ffmpeg, clang18, llvm18 y los `gi-*` traen VARIOS ficheros de licencia que dicen cosas
distintas, y en ffmpeg la respuesta ni siquiera está en el árbol —la deciden los flags de la receta.
Los 3 ArtifactHash, idénticos antes y después.
|
||
|
Sergio
|
b87835f719 |
licencias 96% (1129/1165): la fuente git también es evidencia, y el script deja de llamarse «tarball»
Faltaban tres recetas cuya fuente es un repo, no un tarball: `fcft`, `foot` y `glab`. El commit pineado cumple exactamente el mismo papel que el sha256 —es el árbol EXACTO que construimos— así que la evidencia estaba igual de disponible, sólo que por otra puerta. `miembros_de_git()` la abre sin clonar el árbol entero: `--depth 1 --filter=blob:limit=64k` sobre el commit. Un COPYING nunca pasa de 64k y los fuentes donde vive la concesión tampoco; los que sí pasan —binarios, assets— son justo los que no interesan. Un repo de cientos de megas se resuelve con unos pocos. Las tres salieron del `license:` que el propio autor escribe en su `meson.build` (fcft, foot) y del texto del LICENSE (glab). Los repos por SSH se saltan diciéndolo: este script hace fetch anónimo y no tiene claves. Son `hammerd` y `portal-probe`, y ya están resueltas por otra vía (su repo es este mismo). `analizar()` pasa a consumir un iterable de `(ruta, bytes)` en vez de abrir el tar ella misma, así que las dos fuentes comparten TODA la lógica de veredicto: la jerarquía de evidencia, la regla de sólo-la-raíz, la unión de identificaciones y la exigencia de que la concesión hable de la misma versión que el COPYING. Un criterio, dos puertas. Y el script se renombra `licencias-tarball.py` → `licencias-fuente.py`, porque el nombre viejo pasó a ser mentira en el momento en que aprendió a leer git. Un nombre que describe la implementación de ayer manda a la gente a buscar en el sitio equivocado. Los 3 ArtifactHash, idénticos antes y después. |
||
|
Sergio
|
5e489e974e |
firefox: BuildID determinista — se cierra la deuda de reproducibilidad, con guardián
Medido y probado hoy: `atuq` REPRODUCE bit a bit (`why-differs`: 85 entradas idénticas, 0 divergen), lo que valida el re-empaque determinista del omni.ja, el XPI, los iconos copiados y el BuildID derivado del contenido. El que NO reproducía era la BASE: el `BuildID` de firefox era la fecha y hora del build (`20260905035306` en el artefacto sellado), así que dos construcciones con el mismo ArtifactHash daban bytes distintos. Es el agujero exacto que el invariante de reproducibilidad existe para cerrar, y `build-state.json` no lo puede ver: el hash es input-addressed y no se mueve por esto. Verde y mintiendo. El valor sale de `SOURCE_DATE_EPOCH`, que el sandbox de hammer YA fija a 1 para todas las recetas — mejor que una constante escrita a mano, porque usa el mecanismo de hermeticidad que ya existe en vez de inventar un segundo. Alpine hace lo mismo en su APKBUILD. BuildID esperado: 19700101000001. Va en LAS TRES FASES, por la lección que costó 50 minutos esta misma tarde con MOZ_REQUIRE_SIGNING: son shells distintos y `mach build` re-ejecuta el configure cuando le parece. Y con su GUARDIÁN, hermano del de la firma: la fase install compara el BuildID del artefacto contra el que SOURCE_DATE_EPOCH obliga, y falla el build si no coinciden. Los dos fallos de esta familia —flag que el configure acepta y el artefacto ignora— son mudos y viajan lejos; la única defensa es comprobarlos donde importa, que es dentro del artefacto. |
||
|
Sergio
|
2660063f99 |
atuq v0.4: el branding que se VE estaba en las imágenes del zip, no en el texto
Capturé la pantalla con `grim` y por fin miré lo que el usuario miraba. El diagnóstico cambió
entero: la ventana SÍ estaba —el título decía «New Tab — atuq» y el icono del lanzador era el
zorro— pero la PÁGINA mostraba el logo y la palabra «Nightly».
O sea que la v0.2 rebrandeó lo que se lee y no lo que se ve. El branding de Gecko vive en TRES
sitios y sólo uno es texto FTL:
· `brand.ftl` — las cadenas nuevas (título de ventana, menús). Ya estaba.
· `brand.properties` — las cadenas VIEJAS, formato heredado. Seguía diciendo Nightly, y nadie lo
habría notado leyendo la receta: son 71 bytes en otra ruta del mismo zip.
· las imágenes de `chrome/browser/content/branding/` — TODO lo visible: el favicon de las páginas
internas (ese orbe azul en la pestaña), el logo de about:, y el «wordmark»,
que es una IMAGEN con la palabra dibujada, no un texto traducible.
Se reemplazan 10 imágenes + las dos tablas de cadenas + los dos wordmarks. Cada imagen va con LAS
MISMAS DIMENSIONES que la que sustituye (192, 384, 300x236, 16/32/48/64/128): son tamaños que el CSS
del chrome da por sentados, y meter otro tamaño descoloca la página en vez de rebrandearla. El
`about.png` (300x236, no cuadrado) lleva el medallón ENCAJADO y centrado, no estirado.
El wordmark conserva el `viewBox` exacto del original (0 0 372 99) y `fill="context-fill"`, que es
la convención de Gecko para que el color lo ponga quien lo usa — así sigue el tema claro/oscuro solo
en vez de imponer un color.
La variante «private» usa el mismo medallón a propósito: inventar una segunda marca para un modo del
navegador es ruido, y ese modo ya se distingue por su propio chrome.
MÉTODO, que es lo que más vale de esta vuelta: `grim` está en el corpus (incoming-wlr), se hidrata
en el mismo rootfs y captura la pantalla real desde dentro de la jaula. Dejé de decir «mirá tu
pantalla» y pasé a mirarla yo.
|
||
|
Sergio
|
17a7eda1c7 |
sqlite-shared: anotada la verruga del sqlite3 de CLI, con el costo de las dos salidas
El binario de la CLI sale con `NEEDED libreadline.so.8` y el `readline` canónico del corpus es `.a`, así que en la imagen GNOME ese comando no carga — lo resolvía contra el sysroot del lab. Las apps no están afectadas: el NEEDED lo lleva `usr/bin/sqlite3`, no `libsqlite3.so.0`. No lo arreglo de paso porque las dos salidas cuestan cosas distintas y la elección no es de rutina: una `readline-shared` de raíz es 1 build pero suma una librería a la imagen por un comando; `--disable-readline` acá es más limpio pero `yupana radio` da 6 dependientes que caen a deuda. La nota va en la receta y no en un documento aparte porque es donde alguien la va a editar. Verificado que un comentario no toca el ArtifactHash (b3:22e25fc7 antes y después). |
||
|
Sergio
|
3a83d2eda4 |
gnome: xz-shared — sin ella NINGUNA app de la imagen carga, no una
`scripts/vigia-sonames.py` sobre los cinco perfiles marcaba `liblzma.so.5` en GNOME pedido por `libadwaita` y por `python3`. La columna de QUIÉN lo pide es la que decide, y acá decidió fuerte: mirando el artefacto sellado, el `NEEDED` no lo lleva un binario suelto sino **`usr/lib/libadwaita-1.so.0`**, que es la librería contra la que enlaza toda app GTK4/GNOME de la imagen. Sin proveedor del SONAME el loader falla en TODAS, no en una. Misma fuga de siempre —el `xz` canónico del corpus es `.a`, así que el rootfs lo resolvía contra el sysroot Alpine DEL LAB— y por eso invisible al store: el lab no entra en `hash_inputs`. La receta `-shared` existía sólo en `incoming-kde`. Se promueve al corpus con el mismo procedimiento que `bzip2-shared` el 2026-09-03, y comprobando lo mismo antes de creerlo: el hash es idéntico desde las dos rutas (b3:174289d5) ⇒ un solo artefacto y cero rebuilds. Si hubiera diferido, sería otra receta y no valdría la promoción. Va sólo en GNOME: en cosmic y sway ese soname lo pide únicamente `python3`, que es herramienta de build y no viaja en la imagen. GNOME pasa de 3 sonames sin proveedor a 2. De los dos que quedan, `libperl.so` es de `perl` (build), y `libreadline.so.8` lo pide `usr/bin/sqlite3` —el shell de la CLI, NO `libsqlite3.so.0`—, así que las apps están bien y lo roto es el comando. Queda anotado como verruga, no como rotura. |
||
|
Sergio
|
66db079b64 |
firefox: la bandera de firma en LAS TRES fases, y un guardián que lo comprueba en el artefacto
El build anterior selló con `MOZ_REQUIRE_SIGNING: true` DENTRO del omni.ja, pese a que el configure
aceptó la variable sin una queja. Cincuenta minutos para descubrirlo, y no al construir sino al
intentar instalar la extensión de la página de inicio — a dos recetas de distancia y con un error
(`ERROR_SIGNEDSTATE_REQUIRED`) que no nombra la bandera por ningún lado.
LA CAUSA ES LA QUE ESTA MISMA RECETA YA DOCUMENTABA PARA OTRA VARIABLE: las fases son shells
distintos y `mach build` re-ejecuta el configure cuando lo cree necesario. Por eso `RUST_TARGET` se
repite en las tres desde siempre; `MOZ_REQUIRE_SIGNING` estaba sólo en `configure`.
Y como el fallo es de los que viajan lejos y callados, la fase install ahora lo COMPRUEBA donde de
verdad importa —el `AppConstants.sys.mjs` que va dentro de omni.ja— y falla el build si no quedó en
`false`, con el mensaje que dice qué revisar. Un flag que el configure acepta y el artefacto ignora
es justo la clase de cosa que sólo se ve si alguien la mide.
Lo que se leyó para llegar acá, y no se dedujo: el parser de mozbuild confirma que el valor VACÍO
desactiva (`if values == ("",): return NegativeOptionValue()`) y que un env vacío sí se considera
presente (`if env is not None`). O sea que el mecanismo era correcto; lo que faltaba era que la
variable estuviera donde el build la vuelve a leer.
|
||
|
Sergio
|
ab7cdf25e3 |
licencias: hammerd y portal-probe son MIT — su repo es el propio hammer
Las dos recetas apuntan a `ssh://gitea@git.gioser.net:2345/sergio/hammer.git`, o sea a este mismo árbol, que declara MIT en `Cargo.toml` y trae su `LICENSE`. No hace falta clonar nada para saberlo: la evidencia estaba en el directorio de trabajo. Los dos ArtifactHash, idénticos. |
||
|
Sergio
|
96855001c6 |
licencias: 96% (1124/1164) — --fetch para los tarballs que no estaban en caché
Ocho paquetes más (giflib, pcre2, nghttp2, libogg, libvorbis, speexdsp, libuv, tea) con la misma
regla de evidencia. Su tarball no estaba en `work/tarballs/`, así que el modo `--fetch` lo baja a un
temporal, lo verifica contra el sha256 QUE LA RECETA PINEA —o es el árbol exacto o no se mira— y lo
borra. No se escribe en la caché de hammer a propósito: es suya, y un fichero puesto ahí por otro
camino es una vía de envenenamiento que nadie audita.
Dos correcciones al criterio, las dos porque produjo una afirmación falsa:
· `gmp` salía GPL-3.0-or-later. Su `COPYING` es la GPLv3, pero al lado trae `COPYING.LESSERv3` y
`COPYINGv2` porque la biblioteca es LGPL. La regla anterior —«el `COPYING` a secas gana al
sufijado»— arregla socat, cuyo `COPYING.OpenSSL` es una excepción, y rompe gmp, donde el extra
nombra otra VERSIÓN y no una dep. Esa diferencia es demasiado fina para codificarla sin
equivocarse, así que ahora se identifican TODOS los ficheros de la raíz y sólo hay veredicto si
dicen lo mismo. gmp, ffmpeg y los tres `gi-*` quedan pendientes, que es lo correcto: en ffmpeg
la respuesta ni siquiera está en el árbol, la deciden los flags de la receta.
· Pero «varios ficheros» no es «ambigüedad»: el `COPYING` de pcre2 son dos líneas apuntando a
`LICENCE.md`, y los dos dicen BSD-3. Por eso se unen las identificaciones en vez de contar
ficheros — ambiguo es que digan cosas DISTINTAS.
Y el TSV pasa a ser ACUMULATIVO. Una receta ya sembrada sale del conjunto de entrada porque ya tiene
`license`, así que regenerar el fichero entero borraba su cita — y la cita es el rastro de
auditoría, lo único que deja revisar un veredicto sin repetir el trabajo. Un fichero de evidencia
que se olvida de lo que ya probó no es evidencia.
Los 10 ArtifactHash afectados, idénticos antes y después.
|
||
|
Sergio
|
ba1fb2d3a8 |
licencias: 95% (1114/1164) — la evidencia sale del tarball pineado, offline
`licencias.sh --sembrar` escribe desde una tabla curada a mano y `licencias-desambiguar.sh` resuelve
`-only` vs `-or-later` preguntándole a la búsqueda de código de GitHub. Los dos dejan fuera lo mismo:
lo que nadie curó y lo que no vive en GitHub.
Pero `work/tarballs/` indexa cada tarball por su sha256, así que el árbol EXACTO que la receta pinea
ya está en disco: la declaración del propio autor, en el commit que construimos, sin red. De las 76
sin licencia, 55 tenían su tarball cacheado y 25 salieron con evidencia citable.
`scripts/licencias-tarball.py` la busca en tres niveles: la declaración del autor (`Cargo.toml`,
`meson.build`), un único fichero en `LICENSES/` (REUSE, que usa KDE), y el texto del COPYING más la
CONCESIÓN buscada en las cabeceras de los fuentes — excluyendo COPYING/LICENSE, porque el apéndice
de la GPL trae literalmente «or (at your option) any later version» y buscarla ahí da siempre
positivo siendo plantilla. Es la regla que ya fijó `licencias-desambiguar.sh`, aplicada al árbol
pineado en vez de a GitHub.
La primera versión resolvía 40, y CUATRO estaban mal. Las dejo escritas porque son la forma del
error, no accidentes:
· `socat` salía BSD-2 por su `COPYING.OpenSSL`, que es la excepción, no la licencia. Un `COPYING`
a secas gana ahora a cualquier sufijado.
· `pigz` salía Apache-2.0 por `zopfli/COPYING`: la licencia de una pieza VENDORIZADA leída como la
del contenedor. Sólo se mira la raíz.
· `openssh` salía MIT porque su `LICENCE` es un compendio de cuatro y me quedaba con la primera
que pegara. Si el texto trae varias, no hay veredicto: lo compone un humano.
· `nano` salía GPL-3.0-**or-later** citando el «either version 2» de su `aclocal.m4` — plantilla de
autotools, no del proyecto, y encima de otra versión. Ahora la cita tiene que venir de un fichero
del autor Y hablar de la misma versión mayor que el COPYING.
Y dos bugs míos que producían el mismo daño en silencio: la marca de BSD-3 era «Neither the name of»,
que libpcap y libzip no usan («The names of the authors may not be used to endorse») ⇒ se declaraban
BSD-2; y el mayor de versión lo sacaba de `"GPL-3.0".rsplit("-",1)[0][-1]`, que da «L», así que la
comprobación de coherencia rechazaba TODA cita válida.
La validación final no es una regex: un identificador vale si tenemos su texto en `licenses/`. La
obligación legal es acompañar el binario del TEXTO, así que un SPDX que no podemos entregar no
adelanta nada y sí crea una afirmación que no se sostiene. Eso es lo que atrapa el «GPL2+» que meson
deja escribir en `gsd-schemas` y `libgdm`, que no es un SPDX sino taquigrafía.
Nada se sembró a ojo: cada línea de `docs/licencias-evidencia.tsv` lleva la cita que la decidió, y
las 50 que quedan salen listadas con lo que SÍ se encontró en vez de rellenarse.
Comprobado que no se invalida nada: los 26 ArtifactHash afectados son idénticos antes y después
(`license` no está en `hash_inputs`) — medido, no supuesto.
|
||
|
Sergio
|
37afec380f |
firefox: MOZ_REQUIRE_SIGNING se desactiva con el valor VACÍO, no con cero
El primer intento murió en un segundo:
mozbuild.configure.options.InvalidOptionError: MOZ_REQUIRE_SIGNING takes 0 values
Es una bandera booleana: el `0` no es «falso», es un VALOR que la opción no acepta. La semántica no
se dedujo, se leyó del parser de mozbuild sacado del propio tarball
(`python/mozbuild/mozbuild/configure/options.py`):
if values == ("",): return NegativeOptionValue() ⇒ VAR= (vacío) DESACTIVA
if values == ("1",): return PositiveOptionValue() ⇒ VAR=1 activa
Y el `export` con valor vacío es justo lo que hace llegar la variable PRESENTE y vacía: desexportarla
la dejaría sin definir y volvería al default, que acá es exigir firma porque el default sale de
`milestone.is_release_or_beta and not milestone.is_esr` — 154.0 es release.
Queda escrito en la receta con las dos líneas del parser, porque «=0 no es falso» es la clase de
detalle que cuesta una hora la segunda vez que aparece.
|
||
|
Sergio
|
1dc662c48d |
atuq v0.3: página de inicio y pestaña nueva — y la firma de complementos venía COMPILADA
La página de inicio va en una extensión de sistema (`inicio@atuq.tawasuyu`) y no en una pref, porque la pestaña NUEVA no se puede redirigir con prefs desde hace años: el único mecanismo soportado es `chrome_url_overrides.newtab`. La misma pieza resuelve la home con `chrome_settings_overrides`. La página: el medallón, el nombre y una barra que decide sola. Si lo tecleado PARECE una dirección, navega; si no, BUSCA CON EL MOTOR POR DEFECTO DEL USUARIO vía `browser.search.query`. No se cablea ningún buscador: una distro que hornea su motor en la página de inicio está tomando por el usuario la única decisión que esa página debería respetar. Y dice cuál es el motor, para que la búsqueda no sea una caja negra. DOS MECANISMOS MUERTOS Y UNO VIVO, TODOS MEDIDOS: - `distribution/extensions/` (el clásico de las distros) NO instala nada: Firefox retiró el sideloading. El `extensions.json` del perfil ni lo mencionaba y el log no decía una palabra — fallo perfectamente silencioso. - `policies.json` con `ExtensionSettings` SÍ se lee (`browser.policies.applied=true` en el perfil) y falla con un error que al menos se nombra: `ERROR_SIGNEDSTATE_REQUIRED`. - Y `xpinstall.signatures.required=false` TAMPOCO alcanza. PARA SABER SI EL AUTOCONFIG SIQUIERA CORRÍA, HIZO FALTA UN TESTIGO. `defaultPref` no deja rastro en `prefs.js` (sólo se guarda lo que difiere del default), así que un `.cfg` que no se ejecuta es INDISTINGUIBLE de uno que sí y no hace nada. `atuq.cfg` ahora escribe `atuq.autoconfig.ok` como pref de USUARIO, legible desde fuera sin abrir el navegador. Salió `true` ⇒ el .cfg corre, y la pref de firma se estaba ignorando: la exigencia viene COMPILADA. El default de `MOZ_REQUIRE_SIGNING` sale del MILESTONE (154.0 es release), no del canal — el nuestro es `default` y aun así estaba activa. De ahí `export MOZ_REQUIRE_SIGNING=0` en firefox.toml, con su precio escrito: este Firefox deja de exigir la firma de Mozilla para CUALQUIER complemento. La alternativa es firmar en AMO —cuenta y revisión de Mozilla por versión—, que es la dependencia externa que esta distro existe para no tener. Y no es un desvío: sin esto, el `sct` del SDD 26 §6.1 tampoco se podría shipear nunca. La prueba se hizo SIN reconstruir: se montó el `.cfg` con el testigo por encima del artefacto con `--ro-bind`, en vez de editar un hardlink del store (que habría corrompido el artefacto sellado). |
||
|
Sergio
|
082246da84 |
atuq: la marca de verdad — el zorro en medallón, y la paleta muestreada del propio logo
El operador pasó un tablero de identidad: zorro en medallón con cenefa andina, disco teal, anillo noche. Se adapta la FORMA y el COLOR. Los eslóganes NO — los descartó explícitamente, y de todos modos `brand.ftl` no es sitio para copy: lleva el nombre y nada más. EL ICONO DEJA DE DIBUJARSE EN CÓDIGO. Hasta la v0.2 `rebrand.py` generaba una marca geométrica en Python puro, con el argumento de que un PNG en el árbol no se puede revisar en un diff. Ese argumento valía mientras el icono era un marcador de posición inventado por falta de arte. Ya hay arte, así que el criterio se invierte: un asset de diseño ES la fuente, no un derivado. Lo que se conserva es la disciplina — los seis tamaños salen del MISMO master (recorte del medallón con máscara circular y alfa, LANCZOS desde 1024 px), se generan una vez y se copian, así que dos builds ponen los mismos bytes. LA PALETA SE MIDIÓ, NO SE ESTIMÓ. Los cuatro tokens salen del color más frecuente de cada zona del medallón: #c15728 el zorro, #1b6470 el disco, #04161d el anillo, #f5ecde los reflejos. Escribirlos «parecidos» a ojo es cómo una identidad se desalinea de su propio logo en tres ediciones. Con eso el CSS suma `accent-color` —un solo cambio alcanza decenas de widgets nativos del chrome sin enumerar ninguno— y el fondo de la barra de pestañas verticales, para que marco e icono cuenten lo mismo. ⚠ Anotado y no escondido: a 16 px el medallón pierde el detalle y queda como una mancha cálida redonda. Es intrínseco a un logo con cenefa; la salida sería un dibujo simplificado para ese tamaño y lo decide quien dibujó el zorro, no este script. Construido y sellado EN LOCAL en 3 segundos (b3:97328d1c), hidratado y abierto: 8 procesos vivos, anunciándose como `(atuq:9581)`. |
||
|
Sergio
|
5d06a3b83d |
atuq ABRE: el app_id estaba compilado en el binario, y el árbol copiado llegaba de sólo lectura
Con la cadena GTK3 arreglada, atuq arrancó de verdad: parent vivo, CERO procesos de contenido muertos, y pintando una página local. Quedaban dos cosas. 1. SE ANUNCIABA COMO `firefox-default`. El application.ini decía RemotingName=atuq y aun así el proceso se presentaba así — porque esa cadena es un MOZ_APP_REMOTINGNAME horneado en el ELF, y es la que Gecko pasa a g_set_prgname(), o sea el **app_id de Wayland**. Consecuencia visible: el escritorio no casaba la ventana con nuestro .desktop (StartupWMClass=atuq) ⇒ icono genérico y sin agrupar. Se parchea EN SITIO, no recompilando: cambiarlo en recipes/firefox.toml brandearía la BASE como atuq, y firefox tiene que seguir siendo firefox para los otros forks. Es seguro porque es una cadena C terminada en NUL en el pool de .rodata —`firefox-default\0` son 16 bytes exactos y se escriben 16—, y se EXIGE una única ocurrencia: si upstream la duplica o la renombra, falla en vez de parchear el sitio equivocado. Verificado después: 0 ocurrencias de la vieja, y el log dice `(atuq:26423)`. 2. UN BUG QUE SÓLO SE VE FUERA DE ROOT. `cp -a` preserva los modos y los ficheros del store están sellados sin permiso de escritura; todo lo que viene después los modifica. En el worker pasaba inadvertido porque corre como root, que ignora los bits. El primer build local murió con `PermissionError: /out/usr/lib/atuq/application.ini`. Se arregla con `chmod -R u+w` en la receta y no en el entorno: un artefacto no debe depender de con qué uid lo construiste. Y el runner pasa a hidratar las variantes `-shared`: en runtime una `.a` no sirve de nada, y son las que gtk3 declara NEEDED desde el arreglo del cuadro de las dos Pango. Este atuq se construyó EN LOCAL en segundos, que era la promesa entera del diseño derivado del SDD 26: iterar el envoltorio sin volver a pagar un build de Gecko. |
||
|
Sergio
|
a828e74c40 |
la cadena GTK3 se enlazaba estática dentro de dos .so: cuatro variantes -shared y xkeyboard-config al corpus
Con `atk` arreglado, atuq llegó más lejos y murió igual, ahora con Pango:
GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
… decenas de líneas … tipo '<invalid>'
MISMO CUADRO, CULPABLE DISTINTO Y MÁS GRANDE. `gtk3` produce DOS objetos compartidos —libgtk-3.so y
libgdk-3.so— y libxul declara NEEDED las dos, así que se cargan siempre juntas. Con las variantes
ESTÁTICAS de sus deps, cada una se llevaba adentro su propia copia. Medido con el mismo instrumento
que cazó a atk, `nm -D --defined-only`, preguntando quién DEFINE cada símbolo:
pango_font_map_get_type → libgdk-3.so, libgtk-3.so, libgailutil-3.so
cairo_create → libgdk-3.so, libgtk-3.so
gdk_pixbuf_get_type → libgdk-3.so, libgtk-3.so
hb_buffer_create → libgdk-3.so, libgtk-3.so, libgailutil-3.so
Y se comprobó el otro lado: libxul NO embebe ninguna —enlaza libgtk-3/libgdk-3 como debe—, así que
la duplicación es toda interna del par GTK3.
Cuatro variantes nuevas: harfbuzz-shared, cairo-shared, gdk-pixbuf-shared, pango-shared. Sólo cambia
el modo de librería; se conservan todos los switches del canónico para no arrastrar deps nuevas.
DOS DEUDAS ANOTADAS, NO OLVIDADAS: `fribidi` y `pixman` siguen estáticos —no existe variante— pero
quedan embebidos en UNA sola .so cada uno, así que no hay copia que colisione; y `libepoxy` sí queda
en las dos, y se deja porque no registra tipos de GObject ni mantiene estado global. Si algún día
otra .so del mismo proceso los embebe, vuelve el cuadro.
`firefox` swapea las mismas cuatro: declarar las ESTÁTICAS junto a un gtk3 que trae las compartidas
son dos artefactos peleando por el mismo `pango.pc`, que es la otra forma conocida de este fallo.
Y `xkeyboard-config` SUBE AL CORPUS. Existía idéntica en las cuatro colas de escritorio (un solo md5
entre las cuatro, verificado antes de mover) y atuq, que vive en el corpus, no podía alcanzar
ninguna: sibling-first y después el catálogo padre, nunca una cola hermana. Sin sus datos el
navegador ni pinta («xkbcommon: failed to add default include path /usr/share/X11/xkb»). Mismo hash
en el corpus que en las colas ⇒ cero rebuilds, y las copias de las colas se quedan donde están.
|
||
|
Sergio
|
0f7d19232e |
atuq: el lanzador deja de ser un symlink, y un runner para abrirlo en la pantalla que ya tenés
Dos cosas que salieron de intentar ABRIRLO, que es lo único que distingue «sellado» de «usable».
1. EL LANZADOR. Con `/usr/bin/atuq` como symlink, el navegador moría antes de pintar:
XPCOMGlueLoad error for file /usr/lib/atuq/libmozsandbox.so:
Error loading shared library libnspr4.so: No such file or directory
El motor carga sus propias librerías desde `/usr/lib/atuq` y ni el binario ni esas `.so` traen
RPATH/RUNPATH — comprobado con `readelf -d`, no supuesto. Pasa a ser un script que exporta
`LD_LIBRARY_PATH` (lo mismo que hacen Debian y Fedora) y hace `exec`, para que el proceso que
queda sea el motor y `/proc/self/exe` siga resolviendo el appdir. El `LD_LIBRARY_PATH` además
tiene que HEREDARSE: Firefox lanza un proceso por pestaña y todos cargan las mismas librerías.
La alternativa limpia es grabar RPATH=$ORIGIN con `patchelf` —es lo que hace Alpine— pero
`patchelf` todavía no existe como receta del corpus; cuando exista, esto vuelve a ser un symlink.
2. `scripts/atuq-nested.sh` — hidrata el cierre de runtime y abre atuq como ventana anidada en el
compositor que ya está delante (waypipe, mirada, sway). Trae dos cosas aprendidas a golpes:
· EL ROOTFS VA EN EL MISMO MOUNT QUE EL STORE. `hydrate` proyecta con hardlinks y `linkat()`
rechaza cruzar un punto de montaje aunque sea el mismo filesystem. Acá el store es /dev/sdb
bind-monteado y `work/` vive en /dev/sdc: hidratar a `work/…` muere con «Invalid cross-device
link (os error 18)». El volumen entero está en /mnt/cosecha, así que el rootfs va ahí. Se
comprueba con `findmnt -T`, nunca con `stat -c %d`.
· `dejavu-fonts` va en las raíces por necesidad, no por completismo: un navegador sin una sola
fuente arranca, pinta y muestra cuadraditos. Ya nos costó una tarde en GNOME.
Y no saltea en silencio: si falta un artefacto de la lista, sale con error en vez de armar un
rootfs al que le faltan tres paquetes y falla tres capas más abajo.
|
||
|
Sergio
|
c9c6727c3b |
atk: a las variantes -shared — su .so llevaba una copia entera de GObject adentro
Al abrir el primer atuq en pantalla, murió así:
GLib-GObject-CRITICAL: cannot register existing type 'gpointer'
… 45 líneas iguales … Segmentation fault (exit 139)
El síntoma no nombra a atk por ningún lado, y las dos glib no estaban como dos ficheros en el
rootfs —había UNA sola libgobject—. La segunda copia estaba EMBEBIDA: `atk` declaraba la variante
ESTÁTICA de glib y produce un objeto compartido, así que el enlazador le metió GObject entero
dentro de `libatk-1.0.so`. Todo proceso que cargue atk y libgobject a la vez —o sea cualquier app
GTK— acaba con dos sistemas de tipos peleando.
SE ENCONTRÓ MIDIENDO, NO LEYENDO: `nm -D --defined-only` sobre cada `.so` del rootfs, buscando
quién DEFINE `g_type_register_static`. Dos respuestas: `libgobject-2.0.so`, que debe, y
`libatk-1.0.so`, que no.
Es la regla que el corpus ya tenía escrita desde GTK4 y que esta receta se saltó: las deps de una
`.so` van a las variantes `-shared` EN LUGAR DE las estáticas, nunca junto a ellas.
RADIO MEDIDO ANTES DE TOCAR (`yupana radio atk`): 4 transitivos, 3 sellados caen a deuda —
atk, gtk3 y firefox. GNOME NO está en el radio: usa gtk4. El costo es un rebuild de firefox de
cuatro horas, y no hay forma de esquivarlo: sin esto el navegador no abre.
Esto es «sellado ≠ usable» otra vez, y la única razón por la que apareció es que alguien lo ABRIÓ
en una pantalla. La clausura decía 100%.
|
||
|
Sergio
|
1728fd65e5 |
firefox NO reproduce bit a bit: el BuildID es la fecha del build — medido y anotado, no arreglado de paso
Al abrir `application.ini` para el branding de atuq apareció esto:
BuildID=20260905035306
Es la fecha y hora del build. Dos construcciones de la MISMA receta, con el mismo ArtifactHash,
producen bytes distintos. Es justo el agujero que el invariante de reproducibilidad existe para
cerrar, y no se ve en `build-state.json` porque el hash es input-addressed y no se mueve por esto.
El arreglo es conocido y lo usa Alpine: exportar `MOZ_BUILD_DATE` con un valor determinista.
NO se aplica de paso, a propósito: vive en una FASE, así que re-hashea la receta y cuesta otro build
de cuatro horas más el re-sellado de atuq, que cuelga de ella. Es su propia unidad de trabajo y
queda como 4.c en el plan del SDD 26.
El comentario se comprobó que NO mueve el hash antes de commitearlo (b3:aa90192a antes y después):
un comentario fuera de las fases no entra en `hash_inputs`, así que el firefox sellado sigue válido.
Y el §2.ter del SDD queda con el estado real de atuq v0.2 y su evidencia.
|
||
|
Sergio
|
6f6c32bb9d |
atuq 0.2.0: branding real — el zip, el .ini, los binarios y un icono que no es de otro
Hash b3:7eff4ba4. La v0.1 dejó el branding fuera porque había que MIRAR el árbol antes de adivinar. Se miró, y lo que apareció decidió la forma de esta versión: - `application.ini` del appdir arranca diciendo «This file is not used». Es herencia del árbol de desarrollo: en un build empaquetado el launcher SÍ lo lee. `rebrand.py` no le cree al comentario: comprueba que las claves estén y falla si no. - Las cadenas que la gente VE están DENTRO de `browser/omni.ja` ⇒ sin re-empacar el zip no hay branding. Y el original no dice «Firefox», dice **Nightly**, porque construimos con `--with-branding=unofficial`. Sin tocarlo, atuq se presentaría como lo peor de los dos mundos. - Los ICONOS, en cambio, viven FUERA del zip ⇒ se reemplazan sin abrirlo. EL RE-EMPAQUE PRESERVA TRES PROPIEDADES DEL ORIGINAL, Y CADA UNA POR UNA RAZÓN MEDIDA: orden de las 5306 entradas (es el que Gecko lee al arrancar, y es lo que el jarlog del PGO va a refinar), `compress_type=0` (Mozilla lo deja SIN COMPRIMIR para poder mapearlo) y `date_time` 2010-01-01 (ya venía normalizado: Mozilla también persigue reproducibilidad). VERIFICADO CONTRA EL ARTEFACTO, NO CONTRA EL LOG: - diff entrada por entrada entre el omni.ja de firefox y el de atuq: **5306 → 5306, mismo orden, todo STORED, mismas fechas, y UNA SOLA entrada con contenido distinto**: brand.ftl. - re-empacar dos veces el mismo zip da el mismo sha256 ⇒ el paso es determinista. - application.ini: Vendor=tawasuyu, Name/RemotingName/CodeName=atuq. `ID` NO se toca: es el GUID con el que las extensiones declaran compatibilidad, y cambiarlo dejaría a atuq fuera del ecosistema de complementos. EL BuildID SE DERIVA DEL CONTENIDO DEL OVERLAY, no de la fecha. Es la clave con la que Gecko invalida su startup cache: si atuq cambia su chrome y el BuildID no se mueve, el navegador arranca con la interfaz vieja cacheada y PARECE que el overlay no agarró. Derivarlo del contenido lo mueve exactamente cuando hace falta y dos builds del mismo atuq dan el mismo número — con la fecha pasaría lo contrario en los dos sentidos. Se vio funcionar: al sumar `CodeName` el BuildID cambió solo, de 81921491609672 a 24128696592342. El icono se DIBUJA en código (PNG en Python puro, zlib + struct) y no se commitea como binario: un PNG en el árbol no se puede revisar en un diff, el código sí, y el resultado es idéntico en cada build. ⚠ Es un marcador de posición declarado —una marca geométrica plana, 5 tamaños—; lo correcto es que alguien dibuje el zorro. Su única función irrenunciable ya la cumple: que la ventana y el lanzador NO muestren el icono de otro producto. Binarios: firefox → atuq y firefox-bin → atuq-bin, con symlink `firefox` → `atuq` dentro del appdir porque hay scripts de terceros que invocan por el nombre histórico y Gecko resuelve su directorio por /proc/self/exe (entrar por el symlink resuelve al mismo sitio). Más `.desktop` con StartupWMClass=atuq, que casa con el app_id que da RemotingName bajo Wayland. |
||
|
Sergio
|
aeebb194dc |
atuq 0.1.0: la receta del envoltorio, derivada de firefox
Primera receta del navegador de la distro (SDD 26). No compila nada: depende de `firefox`, copia su árbol y le pone encima cuatro ficheros. Hash b3:2d6e4dcf. LA CAPA SON CUATRO FICHEROS Y CADA UNO ESTÁ DONDE ESTÁ POR UNA RAZÓN: - `defaults/pref/autoconfig.js` — el único gancho que corre ANTES de que exista un perfil. - `atuq.cfg` — prefs de fábrica + carga del chrome. Con `defaultPref` y no `lockPref`: son valores de arranque, no una cárcel; lo que de verdad se bloquea va en policies.json. - `chrome/atuq.css` — el aspecto. - `distribution/policies.json` — telemetría, updates, primer arranque. POR QUÉ EL CSS NO ES `userChrome.css`: ese fichero vive en el PERFIL y exige que el usuario prenda `toolkit.legacyUserProfileCustomizations.stylesheets`. atuq tiene que verse como atuq en el primer arranque, con un perfil recién creado, sin que nadie prenda nada. El único gancho a nivel de APLICACIÓN es nsIStyleSheetService desde autoconfig — y llegar a él es la razón de `sandbox_enabled = false`. Se registra como USER_SHEET, el mismo nivel de cascada que userChrome, para que el usuario pueda seguir pisándolo. DOS TRAMPAS DEL FORMATO, ESCRITAS EN EL PROPIO FICHERO: - la PRIMERA LÍNEA de un autoconfig se ignora siempre, por diseño (herencia de Netscape). Código en la línea 1 no corre y no da error: el fallo más caro de ese fichero es el que no dice nada. - el CSS va acotado con @-moz-document a browser.xhtml. Una hoja USER sin acotar alcanza CUALQUIER documento chrome —visor de PDF, inspector, diálogos— y un selector como `toolbar` termina pintando ventanas que nadie miró. `extensions.autoDisableScopes = 0` es la otra mitad del `--with-unsigned-addon-scopes` que ya viaja en el build de firefox: sin los dos, las extensiones de la distro se instalan DESACTIVADAS. LAS ASERCIONES VAN PRIMERO Y FALLAN RUIDOSAS. Un derivado que no encuentra su base produciría un directorio con cuatro ficheros de config, `Store::has` lo daría por presente y el fallo aparecería el día que alguien abra el navegador (regla 3 del CLAUDE.md). Y al final imprime el inventario de la capa con sus tamaños, que es la primera pregunta del diagnóstico cuando «atuq se ve como Firefox». LO QUE LA v0.1 NO HACE, A PROPÓSITO: no renombra el binario ni toca application.ini, y no re-empaqueta omni.ja. Las dos cosas necesitan mirar la forma real del árbol que selle `firefox`, y adivinarla desde acá daría un artefacto que arranca en una máquina y en ninguna otra. No se puede construir todavía: su dep `firefox` está en vuelo. |
||
|
Sergio
|
6dbe17f87d |
firefox: fuera clang18 y llvm18 — una dep del corpus tapaba el llvm-ar del lab
Primer build con clang+ThinLTO: murió a los 4 minutos, y el error nombra las dos versiones, que es
lo que lo hace diagnosticable de un vistazo:
/usr/bin/llvm-ar: error: …log.o: 'Unknown attribute kind (102)'
(Producer: 'LLVM22.1.8' Reader: 'LLVM 18.1.8')
`clang18` y `llvm18` estaban en [deps].build de cuando esta receta compilaba con gcc: aportaban el
libclang para bindgen y la suite llvm-ar/llvm-objdump que Mozilla exige. Con `compiler = "clang"` se
volvieron ACTIVAMENTE DAÑINAS: una dep del corpus se materializa en el sandbox y TAPA el binario del
lab, así que llvm-ar pasó a ser el de LLVM 18 con un compilador clang 22. Mientras los .o eran
objetos no se notaba; con ThinLTO son BITCODE, y el bitcode no es compatible hacia atrás.
Misma forma que la lección de los headers UAPI: una dep tapa al lab y el fallo aparece lejos del
sitio que lo causó.
El arreglo no es apuntar AR a mano, es no traer el 18: el lab ya expone
/usr/bin/llvm-{ar,objdump,profdata} → llvm22 y /usr/lib/libclang.so → llvm22 (paso 3a-ter del
bootstrap). Es además lo que hace Alpine: clang22 + clang22-libclang, sin un segundo LLVM en la mesa.
Y llvm-profdata del 22 es el que va a hacer falta para el PGO.
Nuevo ArtifactHash: b3:aa90192a141f9fc6d2b59acd074db6caa36854af7100fb08fb51c8fe441b72b7
|
||
|
Sergio
|
fe940887bf |
waterfox aparcada: no falló por los parches, le falta browser/locales en el clon
Primer intento en el worker: murió en CUATRO SEGUNDOS, no en cuatro horas. `mach build` abortó con «FATAL ERROR PROCESSING MOZBUILD FILE» sobre browser/moz.build porque referencia browser/locales/moz.build y ese fichero NO ESTÁ en el árbol traído. Lo que eso significa, y es la parte que vale: LOS ONCE PARCHES DE MUSL SÍ AGARRARON. La apuesta explícita de esta receta —reusar los parches de 154 sobre un árbol 153.1.0— no es lo que falló. Lo que falla es el FETCH: falta un trozo del árbol. Sospechoso número uno el `--filter=blob:none` contra cómo BrowserWorks compone su repo, no la receta. Se aparca por decisión del usuario: la prioridad pasa a firefox con la cadena de optimización y a atuq (SDD 26). El primer paso al retomarla es un `git ls-tree` del commit pineado, no un build. |
||
|
Sergio
|
cb3ecd5a00 |
firefox pasa a clang+lld con LTO: la puerta de las optimizaciones costaba apk add lld, no una receta de LLVM
El SDD 26 estimó que habilitar PGO/LTO exigía una receta `llvm-toolchain` (clang+lld+libc++ desde fuente). ERA CARO DE MÁS. Al mirar el lab en vez de suponerlo: - `.dev-fs/alpine` YA TRAE clang22 + llvm22 22.1.8 — la MISMA major que usa el APKBUILD de Alpine para este mismo Firefox (`_llvmver=22`). - `Compiler::Clang` YA EXISTE en hammer, cableado de punta a punta: `parse_compiler` lo acepta y `hammer-build/src/lib.rs` pone CC=clang, CXX=clang++ y AR=llvm-ar. NINGUNA receta lo usaba. - Lo único que faltaba era `ld.lld`. `apk add lld` ⇒ lld22 22.1.8, dos paquetes, cero upgrades. CON ESO CAEN LOS TRES MUROS QUE OBLIGABAN A gcc, sin perder lo que gcc daba: el sondeo de linker se satisface con `--enable-linker=lld`, el `ar` lo pone hammer solo, y el `NEEDED` de la stdlib de C++ existe porque clang++ de Alpine usa la libstdc++ COMPARTIDA — la prueba no es teórica, Alpine construye este Firefox con clang22 y sin libcxx en sus makedepends. LA HUELLA DEL LAB NO SE MOVIÓ, Y SE MIDIÓ ANTES DE TOCAR NADA. `lld` no casa ningún prefijo de TOOLCHAIN_PREFIXES (hammer-core/src/lab.rs), así que los 43 paquetes que entran en `hash_inputs` salieron idénticos ⇒ los 837 artefactos sellados quedan intactos. Eso es lo que hace barato el cambio HOY, y a la vez es un agujero escrito en los dos sitios: la versión de lld no es parte de la identidad del artefacto, y sólo expone a las recetas `compiler="clang"`, que hoy es una. Meter "lld" en la lista de prefijos es lo correcto y cuesta re-hashear el corpus entero: próxima campaña. En el mozconfig entran, además de lld: `--enable-lto=cross`, `--enable-packed-relative-relocs` y `--with-unsigned-addon-scopes=app,system`. El último no es cosmético: sin él un Firefox de release rechaza las extensiones que la distro deja en distribution/extensions/, así que la capacidad de atuq de shipear su propio `sct` se decide ACÁ, en la base, y no en el overlay del derivado. PGO no entra en esta pasada y el porqué queda escrito en la receta: el perfil se junta corriendo el navegador (Alpine y Arch usan xvfb-run; nosotros no tenemos X11 ⇒ sway headless) y el profdata NO es determinista, así que tiene que sellarse como artefacto propio y consumirse por hash. ThinLTO se capa con la misma cuenta que -j y por la misma razón que ella no es un literal: un número fijo ataría el ArtifactHash a la RAM de quien escribió la receta. Nuevo ArtifactHash: b3:6f2a3b2f6db4452ed0d2d3f4e2ff7cd6562a86878d4360653859720be1c3d94d (el firefox 154.0 sellado con gcc queda SUPERADO, no perdido). |
||
|
Sergio
|
a221300c30 |
waterfox 6.7.1.1 (Gecko 153.1.0) — el primer fork, y la prueba de la tesis del reúso
Waterfox es un fork de Gecko con árbol propio, así que consume EXACTAMENTE la misma plataforma que Firefox (gtk3, nodejs, clang18, cbindgen, variantes -shared) y hereda los seis muros ya resueltos sin volver a pagarlos: sin --enable-linker, compiler=gcc, RUST_TARGET, vaciado de checksums vendorizados, strip_debug y el build hermético. Medido con diff ignorando comentarios: las diferencias REALES con firefox.toml son TRES — la fuente, el branding y la versión. Si aparece una cuarta, conviene preguntarse si no debería estar en las dos. LA BASE ES 153.1.0 y los parches son de 154, una release por encima. Se reutilizan igual porque el código que tocan (LFS64, time64, prctl, sandbox) se mueve poco entre releases, pero es una apuesta EXPLÍCITA y no un hecho: si patch falla, falla temprano —antes de compilar nada— y el arreglo es rebasar el que se queje. ACÁ SÍ VA BRANDING OFICIAL, y no contradice a firefox.toml: allá va sin marca porque el nombre y el logo de Firefox sobre un binario parcheado entran en la política de marcas de Mozilla; acá browser/branding/official ES la marca del propio Waterfox, que BrowserWorks distribuye en su árbol para que se construya así. Fuente por commit y no por el tarball_url de GitHub, que es /archive/-style y se genera al vuelo. hammer clona con --filter=blob:none, así que el árbol Gecko no trae historia. |
||
|
Sergio
|
141eb9afd7 |
firefox: vaciar el checksum de los 5 crates vendorizados que tocan los parches
Sexto muro: «error: the listed checksum of third_party/rust/zeitstempel/src/unix.rs has changed». Los crates de Rust vienen VENDORIZADOS en el tarball y cargo verifica el sha de CADA fichero contra .cargo-checksum.json; en cuanto un parche de musl toca uno, el build muere. Cargo no ofrece forma de recalcularlo, así que la salida —la misma del APKBUILD de Alpine— es vaciar la lista de ficheros del manifiesto dejando el checksum del paquete. Se hacen los CINCO de una (audio_thread_priority, cc, zeitstempel, wgpu-hal, alsa) y no sólo el que reportó el error: cargo los destapa de a uno, y buscarlos por prueba y error costaría cinco vueltas de configure de las que cada una tarda minutos. El bucle falla RUIDOSO si un crate no está, en vez de seguir en silencio: si upstream mueve uno, quiero enterarme acá y no tres capas más abajo. |
||
|
Sergio
|
fee383ff64 |
cbindgen 0.27.0 → 0.29.4 — el configure de Firefox 154 exige >= 0.29.4
«cbindgen version 0.27.0 is too old. At least version 0.29.4 is required.»
Subir es gratis: yupana radio cbindgen = 0, ninguna receta la declara todavía —
es herramienta de la plataforma Gecko y nada más.
De paso pasa de tarball /archive/refs/tags/ a commit pineado. Esos tarballs los
genera la forja al vuelo y su sha256 cambia cuando el servidor actualiza git/gzip
(ADR 0006); ya que había que tocar la fuente, se deja anclada. El tag 0.29.4 es
LIGERO —una sola ref en ls-remote, sin ^{}— así que el sha ES el commit.
|
||
|
Sergio
|
c104a64462 |
firefox: RUST_TARGET — lo exige el parche de Alpine, no Firefox
Cuarto fallo de configure: KeyError: RUST_TARGET. Se lee como un bug de Firefox y es en realidad el CONTRATO del parche que trajimos: fix-rust-target.patch reemplaza la autodetección del triple de Rust por un os.environ["RUST_TARGET"] pelado, y el APKBUILD de Alpine lo exporta como $CTARGET. Traer el parche sin la variable es traer media cosa. El valor NO se adivinó: sale de ls .dev-fs/alpine/usr/lib/rustlib/ en el lab, que da x86_64-alpine-linux-musl. El rustc del sandbox es el de Alpine, no el del host — el del host es x86_64-unknown-linux-gnu y usarlo habría producido un cross-compile silencioso, que es peor que un error. Va en las TRES fases: mach lo vuelve a leer al compilar e instalar. Van cuatro muros de configure y cada uno destapó al siguiente: linker → ar → libstdc++ estática (que forzó compiler=gcc) → RUST_TARGET. |
||
|
Sergio
|
3ffca7c7fe |
firefox: pasa a compiler=gcc — zig-cc choca con una negativa de upstream
Tercer fallo de configure, y el que decide: «Firefox does not support linking statically with libstdc++». No es un flag. flags.configure:79 compila un C++ mínimo, lo pasa por llvm-objdump --private-headers y EXIGE encontrar un `NEEDED …libc++`; zig enlaza libc++ estática para musl, así que ese NEEDED no existe nunca. Es una negativa de Mozilla, no una opción. Cambiar a gcc derriba los tres muros que zig-cc levantó, de una vez: 1. el sondeo del linker (gcc se anuncia como «GNU ld», que Firefox reconoce), 2. «Cannot find ar» (hay un ar de verdad; se quitan los wrappers de zig), 3. libstdc++ COMPARTIDA — el gcc del lab es 15.2.0 con libstdc++.so.6. Es una excepción consciente y del mismo tipo que la que el repo ya mantiene para el kernel y cmake (ADR 0011), a la que se llegó por eliminación y no por comodidad: los tres intentos con zig-cc están documentados en la cabecera. ⚠ El precio queda escrito en la receta: el lab NO entra en hash_inputs, así que un Firefox construido con el gcc del lab queda más expuesto a la deriva del rootfs que uno con zig-cc — dos labs con gcc distinto pueden sellar bytes distintos sin que el store lo note. Misma deuda que ya cargan el kernel y las otras recetas compiler=gcc, y razón para no ampliar esa lista sin agotar antes el camino zig. |
||
|
Sergio
|
61143203f9 |
firefox: wrappers de ar/nm/ranlib — zig los trae como subcomandos
Segundo fallo de configure: «ERROR: Cannot find ar». moz.configure hace
check_prog("AR", …) y en el sandbox no existe un ejecutable llamado `ar`: existe
`zig ar`. Un AR="zig ar" con espacio tampoco sirve, se ejecutaría como un binario
único llamado «zig ar» — el mismo gotcha que ya documentan la receta de ffmpeg y
el de los crates cc en las recetas Rust.
Wrapper de UN SOLO TOKEN por herramienta (ar, ranlib, nm, objcopy), que es el
patrón ya establecido en el corpus, exportados en configure Y en compile porque
las dos fases los necesitan.
El linker ya pasó: este fallo es posterior, lo que confirma que quitar
--enable-linker fue correcto.
|
||
|
Sergio
|
2fd738bf82 |
firefox: quitar --enable-linker=lld — el sondeo de Mozilla no reconoce a zig
Primer intento de build: configure murió con «Could not use lld as linker».
NO era que faltara lld. toolchain.configure sondea con
`$CC -fuse-ld=lld -Wl,--version` y clasifica por la SALIDA, buscando «mold»,
«GNU ld», «GNU gold» o «LLD». zig se identifica como `zig ld 0.16.0`, que no casa
con ninguno ⇒ kind = "unknown".
«unknown» por sí solo NO rompe: el código lo acepta explícitamente. Lo que rompe
es PEDIR el linker por nombre, porque eso vuelve fatal cualquier fallo del sondeo:
if linker: result = try_linker(linker)
if result is None: die("Could not use %s as linker")
Sin el flag, unas líneas más abajo Firefox prueba lld igual —c_compiler.type es
clang y la versión 21.1.0 pasa el umbral de 15.0— y si el sondeo falla sigue a
gold y al linker por defecto, que es exactamente el lld que zig trae adentro.
Mismo linker, sin el die.
Diagnóstico hecho leyendo toolchain.configure en el árbol del worker, no
suponiendo: el comando sondeado devuelve rc=0 y sí imprime la versión cuando se
corre a mano.
|
||
|
Sergio
|
90364fabbf |
nodejs y firefox: strip_debug — medido, no supuesto
El nodejs que selló en el LXC sin strip pesa 984 MB, de los cuales .debug_info son 497 MB y .debug_line otros 43: MÁS DE LA MITAD del artefacto es información de depuración, para una herramienta que nadie va a depurar y que ni siquiera se publica. Se aplica también a firefox ANTES de construirlo, que es donde importa: Firefox es varias veces V8 y sin strip su artefacto entraría en varios GB. El store no es sólo disco — se sincroniza hub↔worker y se respalda. Es el hallazgo del SDD 23: el 79% del contenido binario del store era .debug_*, y quitarlo hace que artefactos que no reproducían PASEN a reproducir, porque lo que difería eran las rutas del árbol de build embebidas en esas secciones. El campo entra en hash_inputs a propósito (cambia el contenido) y usa zig objcopy, que siempre está en el sandbox ⇒ no agrega dep de build. Node se reconstruye. |
||
|
Sergio
|
428be5e8d1 |
firefox 154.0 — la cabeza de la familia Gecko (receta, sin construir todavía)
154 y no 155 pese a que Zen sigue 155.0.1 y Waterfox también va por release: los
parches de musl de Alpine son para 154.0, y son ONCE. Ese es el trabajo de
portabilidad que un import de nix pierde y sin el cual Firefox no compila contra
musl. Un Firefox que compila con el set probado vale más que uno con el número
correcto que no compila; y como Firefox se mueve cada 4 semanas, la paridad exacta
con Zen es una cinta de correr. Lo que se reutiliza entre los tres es la
PLATAFORMA (gtk3/nodejs/clang18/cbindgen, ya en el corpus) y este set de parches.
Subir a 155 después es un rebase, no un port.
Se traen los 11 de musl y NO los de ppc64le, loongarch ni Android: cada parche que
no hace falta es una forma más de que un rebase falle sin motivo.
TODO BUNDLEADO salvo GTK3. Alpine usa --with-system-{icu,nspr,nss,av1,libvpx,
webp,libevent} y de ésas el corpus tiene cero; Firefox las trae en el árbol.
Menos piezas móviles para el primer build, que es cuando conviene minimizar
variables.
SIN BRANDING OFICIAL, y no es descuido: el binario lleva once parches, y poner el
nombre y el logo de Firefox sobre un build modificado entra en la política de
marcas de Mozilla — es la historia de Iceweasel en Debian. Misma cautela que
dejavu-fonts-nerd con la licencia de Bitstream Vera: una fuente modificada no
puede llamarse como la original, y un navegador parcheado tampoco.
HERMÉTICO: --disable-bootstrap (su trabajo es descargar toolchains),
MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system (si no, mach arma un virtualenv con
pip y sale a la red) y MOZBUILD_STATE_PATH al árbol (por defecto escribe en $HOME,
que en el sandbox no es suyo). Los crates vienen vendorizados en el tarball.
Wayland-only heredado de gtk3 (-Dx11_backend=false) ⇒ este Firefox NO correrá como
cliente X11 ni bajo Xwayland. Escrito en las dos recetas.
|
||
|
Sergio
|
9c657efe61 |
plataforma Gecko: nodejs 24.18.1 — ./mach configure lo exige
Firefox aborta con «Could not find a Node.js executable»: lo usa para empaquetar los bundles de JS. Waterfox y Zen lo necesitan igual ⇒ al corpus con el resto de la plataforma. TODO BUNDLEADO, a diferencia de Alpine, que lo construye contra diez deps del sistema de las cuales el corpus tiene dos. La decisión de fondo: acá Node es un COMPILADOR, no software que la distro publique — entra al sandbox de Firefox y desaparece, así que el cierre chico gana al cierre puro y el precio (binario gordo, openssl bundleado que nadie expone) no lo paga ningún usuario. Si algún día se quiere PUBLICAR Node, esa es otra receta; queda avisado en la cabecera. Dos AVX-512 apagados, y los dos por la perilla que upstream mismo deja: · simdjson → SIMDJSON_AVX512_ALLOWED=0. ⚠ EN EL .h Y EN EL .cpp: la librería se distribuye AMALGAMADA y el .cpp lleva su propia copia (línea 2493), así que tocar sólo el header no sirve — y engaña, porque ninja sigue con otros objetos y el log parece avanzar. · simdutf (dentro de V8) → se antepone SIMDUTF_IMPLEMENTATION_ICELAKE 0, que es el override que habilita su #ifndef. No se pierde nada: todo el corpus va -mcpu=baseline y ambas eligen implementación en RUNTIME. CXXFLAGS NO sirve acá — GYP no lo propaga a la línea de compilación (verificado buscando el -D en el comando que ninja reportó al fallar). EL PARALELISMO SE CAPA POR RAM Y SIN ESCRIBIR UN NÚMERO. Sin cap, ninja lanza nproc+2 y muere con `job terminated due to signal 9` en el objeto 2936/4414 compilando lo que genera Torque (~2 G por job). Un `-j2` fijo ataría el ArtifactHash a la RAM de quien escribió la receta; la cuenta es un job cada 3 GiB de MemTotal, mínimo 1, tope nproc. Da 2 en momento (7,6 GiB) y 5 en el LXC (16 GiB, 6 cores) con el MISMO texto y el mismo hash. |
||
|
Sergio
|
dc8aa7367e |
plataforma Gecko: cbindgen sube al corpus
Genera las cabeceras C++ de los componentes Rust de Gecko (Stylo, WebRender) y el build de Firefox la exige. Mudanza gratis: [deps] vacío ⇒ no hay cierre que cambiar, mismo ArtifactHash (b3:bd2e6ca6) en las dos rutas, radio 0. |
||
|
Sergio
|
027d3a25ef |
plataforma Gecko: clang18 sube al corpus — bindgen necesita libclang
El build de Firefox corre bindgen sobre los headers de C++ y bindgen carga libclang.so en RUNTIME. La receta ya existía —nació en incoming-cosmic por un crate *-sys del portal, y su commit de origen dice «sólo libclang.so»— pero desde el corpus no se alcanza una cola hermana. Sin esto no hay Firefox, ni Waterfox, ni Zen. Mudanza medida ANTES, no después: sus cinco deps (cmake, samurai, python3, pkgconf, llvm18) viven sólo en el corpus, así que incoming-cosmic ya las resolvía por caída al padre y el cierre no cambia. hammer hash dio el MISMO ArtifactHash (b3:25d95279) en las dos rutas. Verificado que xdg-desktop-portal-cosmic —su único dependiente— sigue SELLADO y que la cola cosmic queda en 36/36 sin deuda: cero rebuilds. Se MUEVE y no se copia: dos ficheros para un artefacto es el cuadro de las dos glib esperando a que uno de los dos derive. |
||
|
Sergio
|
7c58f6b62e |
plataforma Gecko: atk + GTK3 Wayland-only — la base que comparten Firefox, Waterfox y Zen
GTK3 no existía en NINGUNA cola y es el único toolkit de Gecko en Linux. Como Waterfox y Zen son forks de Gecko, los tres navegadores consumen exactamente esta misma pieza: una receta sostiene a los tres. Por eso va al CORPUS y no a una cola —una receta resuelve sibling-first y después el catálogo padre, nunca una cola hermana—, que es la lección de mpv y justo lo que OBS no pudo cumplir al quedar atado a incoming-kde por Qt6. La plataforma nace bien puesta para que los tres navegadores no repitan ese error. Al medir el cierre antes de escribir, TODO estaba ya en el corpus salvo `atk`. Un ladrillo chico destrabando una pieza grande: por eso atk fue primero. WAYLAND-ONLY de verdad, no de intención: -Dx11_backend=false. A diferencia de OBS —que exigía find_package(X11) incondicional— GTK3 sí deja apagarlo, y eso saca libX11/libXext/libXi/libXrandr/… del cierre. Esa cadena vive sólo en incoming-kde y meterla en el corpus la pondría en las CINCO imágenes. Verificado en el artefacto: los .pc son gdk-wayland-3.0 y gtk+-wayland-3.0 (no hay gdk-x11-3.0), libgtk-3.so.0 no enlaza X11 ni xcb, y libgdk-3.so trae NEEDED libwayland-client/cursor/egl + libxkbcommon. ⚠ Consecuencia escrita en la receta: un Firefox contra este GTK3 no correrá como cliente X11 ni bajo Xwayland. Bajo Wayland nativo sí. Es la postura de la distro aplicada al navegador, no un accidente. Las deps van a las variantes -shared EN LUGAR DE las estáticas, nunca junto a ellas: libgtk-3.so es un objeto compartido y un .a sin PIC adentro da `relocation R_X86_64_32 against png_default_write_data`. Se sustituye y no se suma porque ambas variantes instalan los MISMOS .pc y cabeceras — declarar las dos serían dos artefactos peleando por lib/pkgconfig/glib-2.0.pc. |
||
|
Sergio
|
670a5b6b49 |
OBS Studio 32.2.2 — segunda app gráfica de usuario final, con el renderer portado a EGL
13 plugins sellados, entre ellos los que importan: linux-pipewire (captura de
pantalla en Wayland), obs-ffmpeg, obs-x264, obs-outputs (RTMP RTMP),
linux-pulseaudio/alsa y text-freetype2.
EL PORT. El glad de OBS hacía dlopen("libGL.so.1") + dlsym("glXGetProcAddressARB")
y devolvía 0 si no lo hallaba, o sea que el renderer no arrancaba: OBS estaba
atado a GLX —y por tanto a X11— aun corriendo en Wayland puro. Acá nadie publica
libGL.so.1 y el libglvnd del corpus va sin GLX a propósito. El parche carga por
libEGL.so.1 + eglGetProcAddress, que es lo que OBS ya usa para las extensiones.
Verificado en el artefacto, no en el log: libobs-opengl.so.30 tiene CERO
ocurrencias de glXGetProcAddressARB, sus NEEDED son libEGL.so.1 +
libwayland-egl.so.1, y el binario no filtra a glibc.
DÓNDE VIVE. En incoming-kde y no en el corpus porque su frontend es Qt6 y las 13
recetas Qt viven sólo en esa cola. Se midió antes de descartar el corpus: qtbase
sin X11 cierra en 26 nodos que YA están en el corpus, pero el qtbase de la cola va
xcb=ON, así que un qtbase de corpus tendría otro hash con el MISMO nombre de
artefacto ⇒ dos Qt peleando por /usr/lib/libQt6Core.so. Unificar obligaría a
apagarle xcb a KDE: radio 119.
Los símbolos indefinidos salieron por CAPAS y ninguno nombraba al culpable:
freetype (.a no PIC) → fontconfig (idem) → i2d_SSL_SESSION → inflateInit_. Las dos
primeras se arreglaron usando las variantes -shared que YA existían en el corpus;
las dos últimas con -lssl -lcrypto -lz, porque OBS resuelve curl con el FindCURL
de CMake, que toma libcurl.a por fichero y no lee su Libs.private. Un símbolo
indefinido nombra a la librería que lo USA, no a la que falta.
Huecos escritos en la receta para que no se descubran en la mano del usuario:
sin webcam (ENABLE_V4L2=OFF, libv4l2 no está en ninguna cola), sin salida MPEG-TS
(SRT/RIST ausentes) y sin scripting (falta swig). Grabar, capturar pantalla y
publicar por RTMP no pasan por ninguno de los tres.
|
||
|
Sergio
|
f3767f6361 |
corpus: pciutils-shared y mbedtls — dos deps duras de OBS
pciutils-shared: obs-ffmpeg (el plugin de codificación, sin perilla para apagarlo) hace find_package(Libpci) para identificar la GPU por su ID. La pciutils canónica va SHARED=no e instala SÓLO bin/sbin/share — provee.py confirmaba que libpci.so no lo publicaba NINGUNA cola. Patrón zlib-shared: una variante, sin mover el hash de la canónica. Verificado que NO colisionan listando los dos artefactos: la variante sólo pone usr/lib y usr/include; la canónica no pone nada en usr/lib. Rutas disjuntas conviven; rutas pisadas son el cuadro de las dos glib. Por eso el install usa el target `install-lib` y no `install`, que traería los binarios. mbedtls: obs-outputs (streaming RTMP) hace find_package(MbedTLS REQUIRED) y NO acepta OpenSSL — no hay opción en su CMake, está cableado. Va por TARBALL DE RELEASE y no por commit, que es excepción consciente al ADR 0006: mbedtls 3.6 tiene framework/ como submódulo y [source] de hammer no clona submódulos, así que el árbol llegaría incompleto. Un fichero de /releases/download/ lo sube upstream y su sha256 es estable; lo inestable es /archive/<tag>, que la forja genera al vuelo. La propiedad que el ADR exige —que la fuente sea la misma mañana— se cumple igual. PIC ON porque quien la consume es obs-outputs.so, un módulo dlopen. |
||
|
Sergio
|
99eb0071f6 |
corpus: simde 0.8.2 — libobs la exige REQUIRED
libobs/CMakeLists.txt:10 hace find_package(SIMDe REQUIRED) y linkea SIMDe::SIMDe, así que no es opcional para OBS. Sólo cabeceras, pero se instala por meson y no copiando a mano porque genera simde.pc, que es por donde el FindSIMDe de OBS lo encuentra: dejar las cabeceras sin su fichero de descubrimiento da el «está pero no lo encuentra», peor de diagnosticar que una ausencia. |
||
|
Sergio
|
c2feb3eab6 |
corpus: uthash, nlohmann-json, jansson y x264 — las 4 deps que a OBS le faltaban
Las cuatro no existían en NINGUNA cola (medido cruzando el grafo, no con grep).
Van al corpus y no a una cola porque OBS es una app que quieren las cuatro
imágenes, y una receta resuelve sibling-first y después el catálogo PADRE, nunca
una cola hermana.
Verificadas por CONTENIDO del artefacto, no por exit 0 (regla 3 del repo):
· uthash 5 cabeceras; no compila nada y la fase `compile` dice `true`
explícito, porque que una librería sea sólo cabeceras es un
hecho suyo, no un descuido de la receta.
· nlohmann-json pasa por CMake y no por un `cp` para que instale sus
nlohmann_jsonConfig/Targets.cmake: OBS hace find_package, y
copiar los .hpp a mano dejaría «está pero no lo encuentra».
· jansson libjansson.so.4.
· x264 libx264.so.165 + x264.pc, y `asm: yes` — con SIMD, que es la
lección que ffmpeg acaba de costar hoy.
⚠ jansson trajo su propia trampa: la perilla es JANSSON_BUILD_SHARED_LIBS, NO la
estándar BUILD_SHARED_LIBS de CMake (CMakeLists.txt:5, default OFF). Con la
estándar el build sale exit 0 y sella un artefacto con SÓLO libjansson.a — la
receta diciendo link="dynamic" y el artefacto estático. Se vio mirando usr/lib/
del artefacto, no el código de salida.
|
||
|
Sergio
|
666a681812 |
libglvnd 1.7.0: el GL de escritorio que a la distro le faltaba
Hasta hoy NINGUNA cola publicaba libGL.so, libGL.so.1 ni gl.pc (medido con
provee.py): mesa va -Dglx=disabled -Dglvnd=false, así que sólo había libEGL y
libGLESv2. Toda app de GL fijo compilaba —mesa SÍ instala GL/gl.h— y moría al
LIGAR. Lo destapó OBS: deps/glad linkea PUBLIC OpenGL::GL, que ES libGL.so, y eso
es un link, no un gate de configure que se pueda apagar.
SIN GLX Y SIN X11, que es lo que hace esto coherente con la distro: glvnd parte el
libGL.so.1 histórico en libGL.so.1 (GL+GLX ⇒ implica X11) y libOpenGL.so.0 (GL
pelado ⇒ no implica nada). Vamos por la segunda. Encender glx metería
libX11/libxcb/xorgproto —hoy sólo en incoming-kde— en el CORPUS, o sea en las
cinco imágenes, para servir a una sola app.
Entrega verificada en el artefacto: libOpenGL.so.0, libGLdispatch.so.0,
libEGL.so.1, libGLESv{1_CM,2}, y opengl.pc. Cero GLX.
El wrapper: meson emite `-Wl,--version-script <ruta>` con ESPACIO. Con gcc anda de
casualidad (reenvía al linker el argumento suelto que no entiende); zig-cc lo
rechaza con «unrecognized file extension». El wrapper une el par con `=`. No se
parchea upstream: el defecto es del contrato meson↔driver, no de glvnd.
⚠ Instala libEGL.so.1, que HOY la pone mesa. Mismo soname, otro dueño ⇒ mesa se
reconstruye con -Dglvnd=true en esta misma campaña, no después.
|
||
|
Sergio
|
8d48f1869f |
vaapi: mpv cierra su último hueco — decodificación por hardware
libva sube al corpus y la copia de incoming-kde se JUBILA (git mv, no copia: dos ficheros para un artefacto es el cuadro de las dos glib esperando a derivar). La mudanza fue gratis y medida antes: las cinco deps de libva viven sólo en el corpus, así que incoming-kde ya las resolvía por caída al padre y hammer hash dio el MISMO ArtifactHash en las dos rutas (b3:405c6211). libva pasa a -Dwith_wayland=yes, que eso SÍ cambia el hash. La razón está en mpv/meson.build:1464: el feature `vaapi` se requiere contra `vaapi-drm or vaapi-wayland or vaapi-x11 or vaapi-win32` ⇒ -Dvaapi=enabled a secas no habilita NADA. De los cuatro backends, x11/win32 están fuera por Wayland-only y vaapi-drm exige features[drm] de mpv, apagado porque vo=drm pide libdisplay-info. Queda vaapi-wayland, que pide libva-wayland.pc. Evidencia, no sólo sello: meson lista «vaapi vaapi-wayland» entre los features habilitados, y el binario sellado trae NEEDED libva.so.2 + libva-wayland.so.2. Radio medido antes de tocar: 2 dependientes (kpipewire, spectacle), los dos reconstruidos. Las 7 imágenes siguen en 0 en deuda. ⚠ El driver es RUNTIME (intel-media-driver / gallium VA por dlopen): que esto selle y que --hwdec=vaapi funcione en una máquina son cosas distintas. |
||
|
Sergio
|
269e8410fd | estado: cosecha granja 2026-09-04T15:02:12Z — avance del árbol KDE | ||
|
Sergio
|
814676ad26 |
ffmpeg: x86asm encendida — mpv decodificaba sin SIMD por una prohibición vencida
La receta llevaba --disable-x86asm heredado de cuando ffmpeg entró SÓLO para kpipewire (codificar un stream de escritorio, donde da igual). Para el reproductor era decodificar sin SIMD. Dos recetas —ffmpeg.toml y mpv.toml— prohibían tocarlo con la misma razón: un hash distinto dejaría DOS ffmpeg peleando por las mismas rutas en una imagen KDE, y el arreglo correcto sería «promover una sola y jubilar la de la cola». Eso ya había pasado: incoming-kde/ffmpeg.toml no existe y hay UNA sola receta ffmpeg en todo el disco. La prohibición sobrevivió a la condición que la justificaba. --x86asmexe=nasm explícito y nasm (2.16.03) a [deps].build: sin ensamblador declarado configure apagaría x86asm en SILENCIO, sellando un artefacto con otro hash y sin la SIMD que dice traer. Evidencia, no sólo sello: configure imprime «x86 assembler nasm», compila los objetos X86ASM, y libavcodec.so pasa de 12.685.744 a 14.454.288 bytes (+1,77 MB). Radio medido antes de tocar (yupana radio ffmpeg): 4 dependientes, ninguno transitivo de más — mpv, wf-recorder, kpipewire, spectacle. Los 4 reconstruidos y sellados; las 7 imágenes siguen en 0 en deuda. |