sergio/takana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
3379a1f1709f6dab9d012cbbb46d7e6ace20db45
takana/recipes/incoming-gnome/libgdm.toml
T
SergioandClaude Opus 5 3379a1f170 licencias: las 26 que faltaban, y el guardián que las contaba mal 
CAMPAÑA CERRADA: 1166/1166 recetas declaran `license`. Ninguna adivinada — cada una sale del
fichero de licencia de su fuente PINEADA (tarball del sha256 de la receta, o el commit exacto en
la forja), y la cita queda como comentario en la propia receta.

⚠ Y EL GUARDIÁN ESTABA MAL, que es el hallazgo que vale más que las 26. `licencias-rootfs.sh`
resolvía la receta por NOMBRE DE FICHERO (`ls recipes/$pkg.toml`), y el paquete se llama por su
campo `name`, que en 34 recetas NO coincide: nu.toml→`nushell`, dust.toml→`du-dust`,
incoming-kde/qtbase.toml→`qt6-qtbase`… Medido: **14 paquetes que SÍ declaran licencia salían como
«licencia desconocida»** y el guardián vetaba una imagen perfectamente publicable.
El falso veto se nota; el hermano silencioso NO: si existe un `<pkg>.toml` que pertenece a OTRO
paquete, la versión vieja reportaba la licencia EQUIVOCADA sin decir nada. Hoy no pasa —medido,
0 casos, y de los 34 nombres duplicados CERO declaran licencias distintas—, pero ahora es
imposible en vez de improbable.

El arreglo tuvo que ser por LOS DOS lados, y el primer intento rompió el otro: el grafo de estado
nombra sus nodos por el fichero (`dust`) y el artefacto del store por `name` (`du-dust`), así que
resolver sólo por `name` dejaba a `dust` sin licencia. Ahora busca por `name` y cae al fichero.
Medido en los dos sentidos: corpus entero 1128/1128, perfil base+cli 81/81, cero sin licencia.

Y probado CON ROTURA A PROPÓSITO además del control, que es lo único que distingue a un guardián
que sirve de uno que nunca salta:
  paquete inexistente en la lista               → exit 1 y «ESTA IMAGEN NO SE PUEDE PUBLICAR»
  control (zlib nushell qt6-qtbase lsof tzdata) → exit 0, y escribe los textos
(⚠ ojo al medir: `script | tail` devuelve el exit de `tail`. La primera corrida dijo exit=0 sobre
la rotura y no era el guardián, era el pipe.)

SE LEVANTA EL VETO QUE SDD 20 DEJÓ ESCRITO. Decía que `base` y `cli` iban con 2 paquetes cada una
con binarios y licencia desconocida: `lsof` y `tzdata`, «que necesitan la vía LicenseRef- y siguen
vetando a propósito». Hechos los dos, con su texto real en licenses/:
  lsof    → LicenseRef-lsof (licencia propia de Purdue, sin identificador SPDX)
  tzdata  → LicenseRef-tz-public-domain (su LICENSE: «all files in the tz code and data … are in
            the public domain»; los tres ficheros BSD-3-Clause que menciona NO se instalan — la
            receta sólo compila zic y deja /usr/share/zoneinfo)

⚠ DOS QUE NO SE PUEDEN REDISTRIBUIR, y ahora el veto los ve:
  duplicacy    NO ES LIBRE. Su LICENSE.md: «Free for personal use or commercial trial; non-trial
               commercial use requires per-computer CLI licenses … $50 per year»
  waybackurls  NO DECLARA LICENCIA: en el commit pineado la raíz es .gitignore, README.mkd,
               go.mod, main.go y script/ — sin LICENSE ni COPYING, y el README no la menciona. Sin
               concesión expresa, el defecto es «todos los derechos reservados»
Los dos con LicenseRef y un texto en licenses/ que explica qué hay, en vez de dejar el campo vacío,
que se lee como «todavía no lo poblamos». Ninguno está hoy en un perfil de imagen; si alguien los
mete, el guardián corta.

De paso queda escrito el texto de `LicenseRef-qorpa-ajena-no-enumerable`, que ya se usaba en
steam-runtime-sniper y no tenía fichero; y `licencias-textos.sh` bajó los canónicos nuevos
(BSL-1.0 para boost, GCC-exception-3.1 que ya hacía falta).

Hueco conocido y anotado en la receta: `XFree86-1.0` (rama del OR de hwdata) se queda sin texto —
SPDX no publica ese identificador, sólo XFree86-1.1, que es otra licencia, y el tarball lo nombra
sin incluirlo. El guardián avisa y no veta, que es correcto: la otra rama del OR es la GPL y su
texto sí está.

NADA SE RE-HASHEA: `license` está fuera de `hash_inputs`. Verificado, no supuesto — `hammer hash`
sobre pigz, lsof y boost después de editarlas devuelve el hash cuyo artefacto YA está en el store.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV
2026-09-09 17:47:16 +00:00

85 lines
5.5 KiB
TOML
Raw Blame History

# libgdm 48.0 — SÓLO la librería cliente de GDM y su typelib `Gdm-1.0`, no el display manager.
#
# POR QUÉ EXISTE, y de nuevo se destapó ARRANCANDO y no compilando: gnome-shell importa `Gdm` desde
# JavaScript, y no de forma condicional —`js/misc/dependencies.js:12` hace
# `import 'gi://Gdm?version=1.0'` en el arranque, antes de cualquier lógica de sesión—. Sin el
# typelib el shell muere en:
#
# JS ERROR: Requiring Gdm, version 1.0: Typelib file for namespace 'Gdm', version '1.0' not found
#
# Además lo usan `systemActions.js` (apagar/reiniciar/cambiar de usuario), `unlockDialog.js` y todo
# `js/gdm/`. O sea que **la librería cliente de GDM es dep de runtime del SHELL**, no sólo del
# greeter, y eso no se ve en ningún meson.build.
#
# POR QUÉ NO SIRVE LA RECETA `gdm.toml`: aquélla construye el display manager ENTERO, y está aparcada
# por una razón real —`libpam_dep = cc.find_library('pam')` en meson.build:55, incondicional y sin
# `required: false`, y no hay receta de linux-pam—. Pero PAM es del DEMONIO: lo usan `daemon/` y
# `pam_gdm/`. `libgdm/` no lo toca; sus deps son glib, gio, logind y `libgdmcommon` (el estático de
# `common/`). Esta receta corta justo por ahí. Cuando exista linux-pam, `gdm.toml` sigue siendo la
# receta del demonio y ésta no estorba: instala sólo la librería, su .gir/.typelib y su .pc.
#
# LOS TRES SEDS, todos verificados contra el meson real:
# 1. `cc.find_library('pam')` → `required: false`. Sin PAM el `pam_extensions_supported` de :56 da
# falso, que a su vez hace `json-glib` opcional (:67) y saltea `subdir('pam-extensions')` (:317).
# La cadena se apaga sola; no hace falta tocar nada más.
# 2. Se borran los `subdir()` que necesitan PAM o que no aportan nada acá: daemon, utils, pam_gdm,
# po (el msgfmt de gettext-tiny — SEXTA vez) y docs. Quedan `common`, `libgdm` y `data`.
#
# ⚠ `data` SÍ QUEDA, y eso costó un ciclo entero de imagen+arranque. Empecé borrándola por
# parecer «cosas del greeter» —perfiles dconf, autostart de orca— pero **ahí vive el gschema
# `org.gnome.login-screen`, y gnome-shell lo lee al arrancar**: sin él muere con
# `Gio.IOErrorEnum: GSettings schema org.gnome.login-screen not found`. Un esquema de GSettings
# no es un fichero de datos del demonio: es una interfaz publicada que consume otro programa.
# De `data` se borra sólo `subdir('dconf')`, que es la única pieza problemática — compila sus
# defaults con el binario `dconf` (`data/dconf/meson.build:18`), que no está en el corpus.
# 3. `gnome.post_install(glib_compile_schemas: true)` se borra: meson lo saltea igual cuando hay
# DESTDIR, pero deja un WARNING por build y confunde el log.
#
# `-Dx11-support=false`: sin él el top-level pide `xcb`, `x11`, `xau` y hasta corre
# `build-aux/find-x-server.sh` para localizar el binario de Xorg (meson.build:87-93). Nada de eso
# existe acá ni va a existir — X11 está al tacho para toda la distro. Es la opción que gdm sí tiene,
# a diferencia de gnome-settings-daemon, donde GTK3/X11 son incondicionales y por eso está aparcada.
#
# `-Dlogind-provider=elogind`: gdm SÍ tiene la perilla (meson_options.txt:16) y su valor por defecto
# es `systemd`, que hace `dependency('libsystemd')` DURA (meson.build:129) y corta. No cae solo por no
# encontrar systemd.pc — hay que elegir la rama. Es exactamente el punto para el que se autoró
# arje-sdlogin-compat. Y `-Dsystemd{system,user}unitdir=no` porque acá PID1 es arje-zero.
#
# `accountsservice` es dep DURA del top-level (:69) aunque libgdm no la use: se declara y ya está
# sellada. Es la segunda vez que aparece en esta cadena.
#
# ISLA DINÁMICA (`link = "dynamic"`, `default_library=shared`): lo que se busca ES el typelib, y gjs
# dlopea la `.so` que el typelib nombra. Ver [[gnome-introspection-dinamica]].
name = "libgdm"
version = "48.0"
# licencia: COPYING del tarball de gdm y la cabecera de libgdm/gdm-client.c —la librería que esta receta construye— dicen GPL v2 «or (at your option) any later version». Ojo: es GPL, no LGPL, aunque sea la librería cliente
license = "GPL-2.0-or-later"
[source]
tarball = "https://download.gnome.org/sources/gdm/48/gdm-48.0.tar.xz"
sha256 = "1bc06daff093ec7b5e37ecb4f92e5da3474a1b1ba076edb9151ee967d1c30adf"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = '''
set -e
sed -i "s/^libpam_dep = cc.find_library('pam')$/libpam_dep = cc.find_library('pam', required: false)/" meson.build
sed -i "/^subdir('daemon')$/d; /^subdir('utils')$/d; /^subdir('pam_gdm')$/d; /^subdir('po')$/d; /^subdir('docs')$/d" meson.build
sed -i "/^subdir('dconf')$/d" data/meson.build
sed -i "/^gnome.post_install($/,/^)$/d" meson.build
PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output \
--prefix=/usr --buildtype=release --wrap-mode=nodownload \
-Ddefault_library=shared -Dselinux=disabled -Dplymouth=disabled \
-Dx11-support=false -Dlogind-provider=elogind -Dsystemd-journal=false \
-Dsystemdsystemunitdir=no -Dsystemduserunitdir=no -Dc_args=-Wno-error=date-time
'''
compile = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
[deps]
build = ["meson", "samurai", "python3", "pkgconf", "gettext-tiny", "py3-setuptools", "gi-foreign-girs", "gobject-introspection", "glib", "glib-introspected", "accountsservice", "libelogind", "libgudev", "udev-pc", "libudev-zero", "json-glib", "libffi", "pcre2", "zlib-shared", "expat", "dbus-shared", "polkit"]
Reference in New Issue View Git Blame Copy Permalink