Sergio
e852f48491
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no hasheaban de antes). El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de TOML y no entra ahí. Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
71 lines
4.8 KiB
TOML
71 lines
4.8 KiB
TOML
# json-glib 1.10.8 — PROMOVIDA AL CORPUS el 2026-09-03, para `zathura`.
|
|
#
|
|
# ══ POR QUÉ SUBE, Y POR QUÉ SALIÓ GRATIS ═══════════════════════════════════════════════════════
|
|
# `zathura` va al corpus para poder estar en las cuatro imágenes, y pide `json-glib-1.0`. Existían
|
|
# DOS copias y ninguna en el corpus: `incoming-cosmic` e `incoming-gnome`. Una receta del corpus no
|
|
# alcanza una cola hermana ⇒ había que subir una.
|
|
#
|
|
# Ganó la de COSMIC, y no por gusto: sus `[deps]` (glib, libffi, pcre2, zlib) resuelven ENTERAS
|
|
# contra el catálogo padre, así que **sella el MISMO ArtifactHash desde el corpus que desde la cola**
|
|
# —`b3:62011e81`, medido con `takana hash` antes de mover nada— o sea cache hit y UN solo artefacto,
|
|
# no dos peleando por la misma ruta. La de GNOME no podía: arrastra `gobject-introspection`,
|
|
# `glib-introspected`, `gi-foreign-girs` y `py3-setuptools`, que son maquinaria de GNOME.
|
|
#
|
|
# **La copia de `incoming-cosmic` se jubiló** en el mismo movimiento, verificado como manda el
|
|
# repo: su único consumidor (`xdg-desktop-portal`) hashea `b3:749fbffe` ANTES y DESPUÉS de quitarla
|
|
# ⇒ cero rebuilds. La de `incoming-gnome` SE QUEDA: es una variante deliberada (con introspección),
|
|
# artefacto distinto, y jubilarla sí rompería a quien la usa.
|
|
#
|
|
# Lo de abajo es el comentario original de la receta de COSMIC, que sigue valiendo tal cual.
|
|
#
|
|
# json-glib 1.10.8 — segundo eslabón de LA CADENA DEL PORTAL. `xdg-desktop-portal` lo pide con
|
|
# `dependency('json-glib-1.0')` incondicional (lo usa para el índice de portales y la configuración).
|
|
#
|
|
# ── POR QUÉ UNA RECETA PROPIA Y NO LA DE `incoming-gnome` ────────────────────────────────────────
|
|
# Existe `recipes/incoming-gnome/json-glib.toml`, pero **no se puede reusar**, y el motivo no es
|
|
# burocrático: aquella receta está en la ISLA DINÁMICA de GNOME —`-Dintrospection=enabled`,
|
|
# `default_library=both`— porque el `.gir` de json-glib es entrada del `.gir` de
|
|
# evolution-data-server, que gnome-shell lee desde JS. Sus `[deps]` arrastran
|
|
# `gobject-introspection`, `glib-introspected`, `gi-foreign-girs` y `py3-setuptools`.
|
|
#
|
|
# Acá nadie introspecta nada: el portal es C que enlaza y ya. Traer esa receta metería toda la
|
|
# maquinaria de introspección de GNOME en la clausura de COSMIC para no usar ni un `.typelib`. Ésta
|
|
# es la misma librería con la introspección APAGADA, que es lo que este consumidor necesita.
|
|
#
|
|
# (El método para saber si una receta se puede compartir es `takana hash` desde las dos colas — así
|
|
# se comprobó que `glib-shared` y `pcre2-shared` sí resuelven idéntico. Acá ni hace falta: las
|
|
# `[deps]` son visiblemente distintas, así que el hash no podía coincidir.)
|
|
#
|
|
# `nls=disabled` por lo mismo que en la cola de GNOME: las traducciones piden un `msgfmt` completo y
|
|
# el corpus sólo tiene gettext-tiny.
|
|
name = "json-glib"
|
|
version = "1.10.8"
|
|
license = "LGPL-2.1-or-later"
|
|
|
|
[source]
|
|
tarball = "https://download.gnome.org/sources/json-glib/1.10/json-glib-1.10.8.tar.xz"
|
|
sha256 = "55c5c141a564245b8f8fbe7698663c87a45a7333c2a2c56f06f811ab73b212dd"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
# ⚠ `--prefer-static` NO es redundante con `-Ddefault_library=static` (2026-09-08). El segundo
|
|
# gobierna cómo se construye la librería PROPIA —y funcionaba: el artefacto trae `libjson-glib-1.0.a`—
|
|
# pero no dice nada de con qué se enlazan los EJECUTABLES. Sin `--prefer-static`, `json-glib-format` y
|
|
# `json-glib-validate` salían dinámicos contra `libffi.so.8`, `libz.so.1` y `libc.so`; ese `libc.so`
|
|
# es la musl de zig, que en el host son 255 bytes de linker script ⇒ **binarios que no corren fuera
|
|
# del sandbox**, en una receta que declara `link = "static"`. Lo cazó `scripts/static-audit.sh`, que
|
|
# existe justamente para que la declaración y el binario no se separen. Mismo remedio que `appstream`.
|
|
[build.phases]
|
|
configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload --prefer-static -Ddefault_library=static -Dintrospection=disabled -Ddocumentation=disabled -Dman=false -Dtests=false -Dconformance=false -Dnls=disabled -Dinstalled_tests=false"
|
|
compile = "ninja -C output"
|
|
install = "DESTDIR=/out meson install -C output --no-rebuild"
|
|
|
|
[deps]
|
|
# La glib ESTÁTICA del corpus, que es lo que un consumidor en C puede usar sin problema — el muro de
|
|
# la glib dinámica es de los crates `*-sys` de Rust, no de un `.c`. `libffi`/`pcre2`/`zlib` son la
|
|
# clausura de pkg-config que declara el `.pc` de glib en `Requires.private`.
|
|
build = ["meson", "samurai", "python3", "pkgconf", "glib", "libffi", "pcre2", "zlib"]
|