From 8d1efca26e5e3fc4f3ca626e0479be329f3382fb Mon Sep 17 00:00:00 2001 From: sergio Date: Wed, 29 Jul 2026 14:54:34 -0400 Subject: [PATCH] =?UTF-8?q?gnome:=20GIRepository-2.0=20=E2=80=94=20el=20ty?= =?UTF-8?q?pelib=20que=20no=20pide=20el=20shell=20sino=20gjs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Con los siete de `dependencies.js` cerrados, el arranque avanzó y murió en uno que NO está en esa lista: JS ERROR: Requiring GIRepository, version 2.0: Typelib file ... not found El que lo pide es **gjs**, desde su propio JavaScript embebido: su GResource trae literalmente `imports.gi.versions.GIRepository = '2.0';` (verificado con strings sobre libgjs.so.0). Dep de runtime del INTÉRPRETE — invisible al grafo de build Y a la lista del shell. O sea que `dependencies.js` es necesario pero no suficiente: hay una capa más abajo. HAY DOS GIRepository Y NO SON LO MISMO, y los números confunden a propósito: · GIRepository-3.0 = la API NUEVA, la que GLib absorbió (libgirepository-2.0). La produce glib-introspected y ya estaba. · GIRepository-2.0 = la API VIEJA, la de libgirepository-1.0.so.1, contra la que gjs está enlazado. La produce gobject-introspection, pero sólo con -Dbuild_introspection_data=true, y el nuestro va con false. La 2.0 es la vieja porque nombra la librería 1.0; la 3.0 es la nueva porque nombra la 2.0. Receta aparte en vez de prenderle la opción a g-i: su radio alcanza toda la cadena GNOME (catorce recetas la declaran para escanear) y además traería de vuelta los typelibs de X11/cairo que motivaron apagarla. Acá el radio es cero. Replica el custom_target('gir-girepository') de upstream (gir/meson.build:494) pero escaneando contra la libgirepository-1.0 ya instalada. **La lista de fuentes va enumerada a mano y no como glob**, y no es prolijidad: `girepository/*.h` barre también `gitypelib-internal.h`, que declara G_TYPELIB_ERROR; el scanner emite entonces el stanza del error-quark y su binario temporal no linkea, porque `g_typelib_error_quark` es LOCAL en la .so instalada. Upstream nunca lo escanea — el glob era el error. Co-Authored-By: Claude Opus 5 (1M context) --- .../gi-girepository-typelib.toml | 90 +++++++++++++++++++ scripts/gnome/hydrate-gnome.sh | 3 + 2 files changed, 93 insertions(+) create mode 100644 recipes/incoming-gnome/gi-girepository-typelib.toml diff --git a/recipes/incoming-gnome/gi-girepository-typelib.toml b/recipes/incoming-gnome/gi-girepository-typelib.toml new file mode 100644 index 00000000..5e51c85b --- /dev/null +++ b/recipes/incoming-gnome/gi-girepository-typelib.toml @@ -0,0 +1,90 @@ +# gi-girepository-typelib — `GIRepository-2.0.typelib`, y nada más. +# +# QUÉ RESUELVE: con los siete typelibs de la lista del shell ya cerrados, gnome-shell avanzó un paso +# más y murió en uno que NO está en esa lista: +# +# JS ERROR: Requiring GIRepository, version 2.0: Typelib file for namespace 'GIRepository', +# version '2.0' not found +# +# El que lo pide no es el shell sino **gjs**, desde su propio JavaScript embebido: su GResource trae +# literalmente `imports.gi.versions.GIRepository = '2.0';` (verificado con `strings` sobre +# `libgjs.so.0`). O sea que es una dep de runtime del INTÉRPRETE, invisible tanto al grafo de build +# como al `dependencies.js` del shell. Se encuentra arrancando y de ninguna otra forma. +# +# POR QUÉ NO ESTABA: hay DOS GIRepository y no son la misma cosa. +# · `GIRepository-3.0` — la API nueva, la que GLib absorbió (`libgirepository-2.0`). La produce +# `glib-introspected` y ya estaba en el cierre. +# · `GIRepository-2.0` — la API vieja, la de `libgirepository-1.0.so.1`, que es contra la que gjs +# está enlazado. La produce gobject-introspection… pero sólo con +# `-Dbuild_introspection_data=true`, y el nuestro va con `false`. +# Los números confunden a propósito: la 2.0 es la vieja porque nombra la librería 1.0, y la 3.0 es +# la nueva porque nombra la 2.0. +# +# POR QUÉ UNA RECETA APARTE Y NO PRENDERLE LA OPCIÓN A g-i: `yupana radio gobject-introspection` +# alcanza a TODA la cadena GNOME —gtk4, pango, mutter, gnome-shell— porque catorce recetas la +# declaran para escanear. Prender esa opción también traería de vuelta los typelibs de X11 y cairo +# que motivaron apagarla. Acá se genera UN typelib y el radio es cero. Mismo criterio que +# `gi-foreign-typelibs` y que `udev-pc`. +# +# CÓMO: se replica el `custom_target('gir-girepository')` de `gir/meson.build:494` de upstream —los +# mismos `--identifier-prefix`, `--symbol-prefix`, `--c-include`, `--library` y `-DGI_COMPILATION`— +# pero escaneando contra la `libgirepository-1.0` YA INSTALADA en vez de la del árbol de build. La +# lista de fuentes es la `girepo_gir_sources` de `girepository/meson.build:116`, **enumerada a mano y +# no un glob**, y eso no es prolijidad: `girepository/*.h` barre además `gitypelib-internal.h`, que +# declara `G_TYPELIB_ERROR`. El scanner entonces emite el stanza del error-quark, y el binario +# temporal que compila para introspeccionar no linkea: +# ld.lld: error: undefined symbol: g_typelib_error_quark +# porque ese símbolo es LOCAL en la `.so` instalada (`nm` lo muestra en minúscula) — es interno, como +# dice el nombre del header. Upstream nunca lo escanea; el glob fue el error. +name = "gi-girepository-typelib" +version = "1.84.0" + +[source] +tarball = "https://download.gnome.org/sources/gobject-introspection/1.84/gobject-introspection-1.84.0.tar.xz" +sha256 = "945b57da7ec262e5c266b89e091d14be800cc424277d82a02872b7d794a84779" + +[build] +compiler = "zig-cc" +target = "x86_64-linux-musl" +link = "dynamic" + +[build.phases] +configure = "true" +compile = ''' +set -e +PYTHONPATH=/usr/lib/python3.12/site-packages g-ir-scanner \ + --output=GIRepository-2.0.gir \ + --no-libtool --quiet --reparse-validate \ + --add-include-path=/usr/share/gir-1.0 \ + --identifier-prefix=GI --symbol-prefix=g --symbol-prefix=gi \ + --c-include=girepository.h \ + --namespace=GIRepository --nsversion=2.0 \ + --library=girepository-1.0 \ + --pkg-export=gobject-introspection-1.0 \ + --include=GObject-2.0 \ + --cflags-begin \ + $(pkg-config --cflags glib-2.0 gobject-2.0) \ + -I/usr/include/gobject-introspection-1.0 \ + -Igirepository -DGI_COMPILATION \ + --cflags-end \ + $(cd girepository && printf 'girepository/%s ' \ + giarginfo.c gibaseinfo.c gicallableinfo.c giconstantinfo.c gienuminfo.c \ + gifieldinfo.c gifunctioninfo.c giinterfaceinfo.c giobjectinfo.c \ + gipropertyinfo.c giregisteredtypeinfo.c girepository.c gisignalinfo.c \ + gistructinfo.c gitypeinfo.c giunioninfo.c giversion.c givfuncinfo.c \ + giarginfo.h gibaseinfo.h gicallableinfo.h giconstantinfo.h gienuminfo.h \ + gifieldinfo.h gifunctioninfo.h giinterfaceinfo.h giobjectinfo.h \ + gipropertyinfo.h giregisteredtypeinfo.h girepository.h gisignalinfo.h \ + gistructinfo.h gitypeinfo.h gitypelib.h gitypes.h giunioninfo.h givfuncinfo.h) +''' +install = ''' +set -e +mkdir -p /out/usr/lib/girepository-1.0 /out/usr/share/gir-1.0 +g-ir-compiler --includedir=/usr/share/gir-1.0 \ + -o /out/usr/lib/girepository-1.0/GIRepository-2.0.typelib GIRepository-2.0.gir +cp GIRepository-2.0.gir /out/usr/share/gir-1.0/ +ls -l /out/usr/lib/girepository-1.0/ +''' + +[deps] +build = ["pkgconf", "python3", "py3-setuptools", "gobject-introspection", "gi-foreign-girs", "glib", "glib-introspected", "libffi", "pcre2", "zlib-shared"] diff --git a/scripts/gnome/hydrate-gnome.sh b/scripts/gnome/hydrate-gnome.sh index 7d2e3dbd..6ff81fa3 100755 --- a/scripts/gnome/hydrate-gnome.sh +++ b/scripts/gnome/hydrate-gnome.sh @@ -40,6 +40,9 @@ else recipes/incoming-gnome/upower.toml # imports.gi.UPowerGlib recipes/incoming-gnome/librsvg.toml # imports.gi.Rsvg recipes/incoming-gnome/ibus.toml # imports.gi.IBus + # Y ésta NO sale de la lista del shell: la pide el propio gjs desde su JS embebido + # (`imports.gi.versions.GIRepository = '2.0'`). Dep de runtime del INTÉRPRETE. + recipes/incoming-gnome/gi-girepository-typelib.toml ) fi