sergio/takana
> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…
licencias: campo `license` en la receta — de 0 a 228 de 1141, sin re-hashear nada
1# colord 1.4.7 — gestión de color (perfiles ICC por dispositivo). mutter la exige por pkg-config sin
2# perilla (meson.build:128): aplica la curva de color a cada monitor en el backend nativo.
3#
4# CON DEMONIO desde 2026-07-30 (`-Ddaemon=true`). Antes iba apagado, con este razonamiento:
5# «mutter enlaza libcolord (el cliente D-Bus), no necesita el demonio». Cierto para COMPILAR mutter y
6# falso para el escritorio andando: al arrancar la sesión, mutter pide `org.freedesktop.ColorManager` y
7# se come 25 s de timeout de activación D-Bus en CADA arranque —
8# libmutter-WARNING: Failed to connect to colord daemon: Error calling StartServiceByName for
9# org.freedesktop.ColorManager: Timeout was reached
10# — porque el artefacto INSTALA el `.service` de activación (`Exec=/usr/libexec/colord`) y ese binario
11# no existía. O sea que la versión sin demonio no era «colord apagado» sino **colord roto de forma
12# lenta**: el peor de los dos, porque no falla, tarda.
13#
14# El propio comentario de esta receta marcaba la condición para volver: «si alguna vez hace falta el
15# demonio de verdad, vuelve con polkit encima». **Polkit ya está**: `arje-polkit-compat` sirve
16# `org.freedesktop.PolicyKit1` desde que se cerró el bus de sistema, y `polkit-gobject-1` —lo único que
17# el meson del demonio agrega (meson.build:194)— estaba sellado desde antes.
18#
19# `-Ddaemon_user=root`: upstream avisa por consola que correr el demonio como root «is not a good idea»
20# y tiene razón, pero acá no hay usuario `colord` en /etc/passwd ni mecanismo que lo cree — eso es
21# trabajo del paquete de sistema, no de esta receta. Queda explícito para que se lea como deuda y no
22# como descuido.
23#
24# ⚠ MEDIDO 2026-07-27, y el resultado desmiente lo que yo suponía al escribir esta receta: apagar el
25# demonio NO adelgaza las deps. En colord 1.4.7 el bloque de dependency() es de nivel superior, sin
26# ningún `if get_option('daemon')` que lo cubra (meson.build:114-123):
27# sqlite3 ✓ (ya en el corpus) gusb ✗ gudev-1.0 ✗ libudev ✗
28# (las tres ya están selladas). Prender el demonio por tanto **no agrega una sola dep nueva** salvo
29# polkit-gobject-1, ya sellada: el coste estaba pagado desde 2026-07-27 sin que nadie lo cobrara.
30# Nota histórica de entonces: colord costaba 3 recetas nuevas antes que ella: libusb → libgusb, y
31# libgudev (envoltorio GObject de libudev; el proveedor de libudev.pc sería libudev-zero, ya en el
32# corpus). libgudev NO se paga sólo por colord: mutter también la exige por su opción `udev`, que es
33# la que hace falta para el backend nativo KMS. Ése es el orden correcto de la próxima tanda.
34#
35# systemd=false por la misma razón que en todo este frente: arje-zero es PID1.
36# argyllcms_sensor=false: sensores de calibración de HARDWARE (colorímetros por USB). El demonio anda
37# sin ellos; lo que se pierde es calibrar con una sonda física, que no es el caso de uso acá.
38# introspection=false: mutter la enlaza en C.
39name = "colord"
40version = "1.4.7"
41license = "GPL-2.0-or-later AND LGPL-2.1-or-later"
42
43[source]
44tarball = "https://www.freedesktop.org/software/colord/releases/colord-1.4.7.tar.xz"
45sha256 = "de02d9910634ae159547585cec414e450f711c27235453b4f9b38a9f2361a653"
46
47[build]
48compiler = "zig-cc"
49target = "x86_64-linux-musl"
50#
51# COLORD VA A LA ISLA DINÁMICA, y no por gusto: su meson construye libcolord/libcolordprivate/
52# libcolorhug como shared_library() PASE LO QUE PASE — -Ddefault_library=static no las hace
53# estáticas. Con --prefer-static, cada uno de esos .so se tragaba una copia de la glib ESTÁTICA, o
54# sea una tabla de GType por objeto compartido. El síntoma, medido el 2026-07-27, fue exactamente el
55# que da esa duplicación: las herramientas que el propio build compila (cd-create-profile, cd-it8)
56# enlazan y arrancan, pero mueren con `assertion 'G_IS_FILE (file)' failed` y acto seguido SIGSEGV —
57# el tipo GFile registrado en una copia de glib no es el mismo que el que valida la otra.
58# Enlazar la glib .so (la cola GNOME la provee: default_library=both) deja UN registro de tipos, que
59# es lo que GObject asume. Es la misma razón por la que glib/gtk4/gobject-introspection ya son isla
60# dinámica en este frente: la introspección no fue el único motivo, sólo el primero que lo obligó.
61link = "dynamic"
62
63[build.phases]
64configure = "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 -Ddaemon=true -Ddaemon_user=root -Dsystemd=false -Dudev_rules=false -Dargyllcms_sensor=false -Dbash_completion=false -Dintrospection=false -Dvapi=false -Dsane=false -Dtests=false -Dinstalled_tests=false -Dman=false -Ddocs=false -Dc_args=-Wno-error=date-time"
65compile = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
66install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
67
68# lcms2 = el motor ICC (reusada de la cola KDE, ya sellada). glib para gio/D-Bus.
69# sqlite: REQUERIDA aunque daemon=false — meson.build:119 la pide incondicionalmente (la usa la
70# librería para leer la base de perfiles ICC). Ya estaba en el corpus y sellada, provee sqlite3.pc.
71[deps]
72build = ["meson", "samurai", "python3", "pkgconf", "gettext-tiny", "glib", "lcms2", "sqlite", "libgusb", "libgudev", "libudev-zero", "libusb", "json-glib", "hwdata", "polkit", "dbus-shared", "expat", "libffi", "pcre2", "zlib"]