[From nobody Wed Apr 1 19:35:06 2026 Received: (at submit) by bugs.debian.org; 16 Jan 2024 14:25:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02 (2021-04-09) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-115.0 required=4.0 tests=BAYES_00, BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER,HAS_PACKAGE,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY, USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST autolearn=ham autolearn_force=no version=3.4.6-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 6; hammy, 150; neutral, 127; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:108, 0.000-+--H*RT:311 Return-path: <smcv@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:53238) from C=NA, ST=NA, L=Ankh Morpork, O=Debian SMTP, OU=Debian SMTP CA, CN=stravinsky.debian.org, EMAIL=hostmaster@stravinsky.debian.org (verified) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from <smcv@debian.org>) id 1rPkND-001e9S-8c for submit@bugs.debian.org; Tue, 16 Jan 2024 14:25:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=2RS4Zhbqg7tjeY5VX4izVMx60y90Nmz298W8vt53wk4=; b=daZqxZEGTABz6Ts3POL4yDfO4J MiYhFOXQenjzFb5Dj7RfTX8eJJiBZMMCrxYMUp8i3QcBWi8F0LjKWH2FxCtoXpoylN6U74ghCjLhP dOPObUc/MCF5hYUP4Xp8Ftl8/zpvDzbzfmz5vvVFcbPPNO/ryTYpOrUqLb+Da+bEDTRhWMyBo6Ze4 XUmJzJrb+12Uwb4LibDtw3h4USNM2m48vJp/DScWZVo+12yBPGHfJcFsg29w+dTPlQAI+BRGiVP59 Ipq8b368TXmUichDE39TEl0t17VayCijm5EAPud50CfsiIrZ6MGc+worsQLY/4xs41e13xY4evg4S 5D9DCdfw==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from <smcv@debian.org>) id 1rPkNA-00BR84-DC for submit@bugs.debian.org; Tue, 16 Jan 2024 14:25:01 +0000 Date: Tue, 16 Jan 2024 14:24:58 +0000 From: Simon McVittie <smcv@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: blueprint-compiler: Please search the same paths for GIR XML that GObject-Introspection does Message-ID: <ZaaRukYjZhDkQiFx@tautology.pseudorandom.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Debian-User: smcv Delivered-To: submit@bugs.debian.org Package: blueprint-compiler Version: 0.10.0-4 Severity: wishlist Tags: trixie sid upstream User: pkg-gnome-maintainers@lists.alioth.debian.org Usertags: gi-gir-path Forwarded: https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues/142 The gobject-introspection package had a long-standing bug that GLib-2.0.gir was installed in /usr/share, but has architecture-dependent contents, preventing it from being co-installed on different architectures. Recent versions solve this by moving GLib-2.0.gir to /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0 (in the gir1.2-glib-2.0-dev package), and configuring gobject-introspection to search that path. Unfortunately, various other packages like blueprint-compiler also want to read GIR XML, and they don't search the same directories for it that gobject-introspection does. For backwards compatibility, gobject-introspection still installs a symbolic link /usr/share/gir-1.0/GLib-2.0.gir -> ../../lib/${DEB_HOST_MULTIARCH}/GLib-2.0.gir in the libgirepository1.0-dev package to avoid breaking those tools, but I would prefer that symlink to disappear eventually. There is at least one other package that has an architecture-dependent GIR XML file: GstAudio-1.0.gir in libgstreamer-plugins-base1.0-dev (https://bugs.debian.org/1016631). Having a symbolic link in /usr/share is probably not an option here, because there's no convenient package split to take advantage of; but if we move GstAudio-1.0.gir into /usr/lib/${DEB_HOST_MULTIARCH}, then blueprint-compiler will become unable to process it. I was unable to find a trivial test-case where this breaks blueprint-compiler in practice, because it doesn't seem to resolve GIR XML dependencies recursively, and I don't know of any GUI libraries that need to have their GIR XML moved into /usr/lib/${DEB_HOST_MULTIARCH}; but I know essentially nothing about this particular package, so if a maintainer can find a scenario where it matters in practice, it might be necessary to raise this bug's severity. The ideal way to solve this would be to propose changes upstream to make it use the same search path as gobject-introspection, resolving <https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues/142>, and then apply those changes in Debian (as a backported patch if necessary) and configure it in a suitable way so that it searches /usr/lib/${DEB_HOST_MULTIARCH}. Thanks, smcv ]