From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 13:32:44 2025 Received: (at submit) by debbugs.gnu.org; 12 Jan 2025 18:32:44 +0000 Received: from localhost ([127.0.0.1]:49076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX2lQ-0007Pg-7K for submit@debbugs.gnu.org; Sun, 12 Jan 2025 13:32:44 -0500 Received: from lists.gnu.org ([2001:470:142::17]:33982) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX2lN-0007PL-3h for submit@debbugs.gnu.org; Sun, 12 Jan 2025 13:32:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tX2l9-00076z-Oh for bug-guix@gnu.org; Sun, 12 Jan 2025 13:32:28 -0500 Received: from smtprelay02.ispgateway.de ([80.67.31.36]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tX2l7-0007Ar-5p for bug-guix@gnu.org; Sun, 12 Jan 2025 13:32:27 -0500 Received: from [62.144.230.172] (helo=milk) by smtprelay02.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1tX2kZ-000000004T3-2HlZ; Sun, 12 Jan 2025 19:31:51 +0100 From: Simon Streit To: bug-guix@gnu.org Subject: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load Gcc: nnfolder+archive:sent.2025-01 Date: Sun, 12 Jan 2025 19:32:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Df-Sender: c2ltb25AbmV0cGFuaWMub3Jn Received-SPF: pass client-ip=80.67.31.36; envelope-from=simon@netpanic.org; helo=smtprelay02.ispgateway.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: Maxim Cournoyer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello, if Guix is installed on a foreign system (Debian Bookworm), sourcing GDK_PIXBUF_MODULE_FILE will prevent native applications on foreign systems from loading their icons: --8<---------------cut here---------------start------------->8--- user@host:~$ /usr/bin/nautilus ** Message: 18:24:36.710: Connecting to org.freedesktop.Tracker3.Miner.Files (org.gnome.Nautilus:134621): Gtk-WARNING **: 18:24:36.915: Failed to load i= con /org/gnome/nautilus/icons/scalable/actions/funnel-symbolic.svg: Unable = to load image-loading module: /gnu/store/cip1g5lwcvrmwp57y0fxyzp6jamn4xjk-l= ibrsvg-2.58.5/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /li= b/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /= gnu/store/cip1g5lwcvrmwp57y0fxyzp6jamn4xjk-librsvg-2.58.5/lib/librsvg-2.so.= 2) ... --8<---------------cut here---------------end--------------->8--- I have a user profile with the following in .bashrc: --8<---------------cut here---------------start------------->8--- export GUIX_LOCPATH=3D"$HOME/.guix-profile/lib/locale" export GUIX_BUILD_OPTIONS=3D"--cores=3D$(echo $(lscpu | grep ^Core) | awk '= {print $4}')" export GUIX_PROFILE=3D"${HOME}/.config/guix/current" . "${GUIX_PROFILE}/etc/profile" eval $(guix package --search-paths=3Dprefix) # Manually sourcing it to be independent of gdk-pixbuf and/or librsvg # being installed in the profile: export GDK_PIXBUF_MODULE_FILE=3D".guix-profile/lib/gdk-pixbuf-2.0/2.10.0/lo= aders.cache" --8<---------------cut here---------------end--------------->8--- If GDK_PIXBUF_MODULE_FILE is explicitly sourced, then Guix based applications show their icons. If not, no icons are displayed and the host has the ability restored to show icons. This leaves Guix on foreign systems currently at: Either the foreign system knows how to load icons, or Guix, if sourcing GDK_PIXBUF_MODULE_FILE. Not simultaneously. This behaviour is somewhat similar in Guix Systems too and has had a similar discussion before: [1]. There it was proposed to wrap the applications to provide GDK_PIXBUF_MODULE_FILE directly. But, there was a time where this was not a problem that lasted up to at least commit 6da03fcc459f4475553f394354ef37c628f39f97. I tried to bisect my way into the past and find the offending change. Unfortunately, I had to give up as trying to pull into commits around August 2024 is close to impossible now. Many commits failed on me and I never got anywhere close to where that change happened. Therefor I am opening this bug report hoping that someone will help me figure out what is going on here? I do remember reading a thread last year, where Maxim =E2=80=93 CCed =E2=80= =93 discussed a problem related to librsvg and gdk-pixbuf. I only found an upstream issue at [2]. But not the discussion on the lists here. [1] https://issues.guix.gnu.org/63427 [2] https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/933/diffs?commi= t_id=3D2dba33bc1b752e2e6fbed3c78f1cec6a74dea201 [3] https://issues.guix.gnu.org/60434 Kind regards --=20 Simon From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 00:37:31 2025 Received: (at submit) by debbugs.gnu.org; 15 Jan 2025 05:37:32 +0000 Received: from localhost ([127.0.0.1]:56659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXw5r-0000I3-F3 for submit@debbugs.gnu.org; Wed, 15 Jan 2025 00:37:31 -0500 Received: from lists.gnu.org ([2001:470:142::17]:50132) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXw5o-0000Hk-Q8 for submit@debbugs.gnu.org; Wed, 15 Jan 2025 00:37:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXw5h-0007s3-Jp for bug-guix@gnu.org; Wed, 15 Jan 2025 00:37:21 -0500 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tXw5g-0000ZT-07 for bug-guix@gnu.org; Wed, 15 Jan 2025 00:37:21 -0500 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-21631789fcdso5945255ad.1 for ; Tue, 14 Jan 2025 21:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736919437; x=1737524237; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=8xdaaSzLRhglJ+xu1o7sLtzcOAUfXCnQWF7nq294Hts=; b=A9yo82+1/6ETEGqK59EDO9l7/LuMJzRbChHiPwa74oOom+pd8coU6Lr3jGTP7iKdzj cmnNvVuo1J1017tENdVig2RspE+xQcJqWwCE/dLOcdb5lKP4IUvejMdM8l1IWEK1DmPX cCvY9WxDDK/7RdghIWjXB5ZxvdjmLS1nWULIFJrZQY2fF9bniO+tXyAPYy+VW0GrOKOY 3sDAOvr3H/CddJaVHw2L8IH2NmAFjqTdON3k+yZ7ZA1DFel1m/hRI/eMXftUJIbPV7hM X+O2QpwFEakAXH+zw9ftxO91avb7MKxfElOR739z5QtVRezy1CEmbDsGED3aY8/7c6el TcTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736919437; x=1737524237; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8xdaaSzLRhglJ+xu1o7sLtzcOAUfXCnQWF7nq294Hts=; b=OeLGXdqzCNmQvsjvWLOMyv1BOkMIXLaV3v5WgZoorlnRTy9u5aZQhCrvTFswBPE/QW iV+XQNel4n1F3cq1/u3FCJl38/RwjbpSiWuAvfQCg24EsqhB93TQQCs/VtSkbJHPmvQ6 gSTXPKEpBqVM7nroh4AzQIrCaIPhe5eVC15AlfbGGGHRcQCAQGn3/7OpDjPK2C3w2An+ 2651ujrp/WGBQh2tw0GYu+W/Cf7wrpWYn6G/XsUtVl+xhZdeNHqo94LqFRtI2oY5mO+F s+jfs+6964zFMGFNJrrvJF+bk2Rn8c02/6jStIE7qek16rb0SanjLfoFoWheB/Qy3mVc qwCg== X-Gm-Message-State: AOJu0YyH8QVnYba0Y9y8PbQvFb3GGnSftrHJes1MQJ4e1UDOaxYkl19E 8kt9XZTK4awDQiN0pGkh20RK6nqXkXNV5lfFU1j/a70orm5O8lPS0OzeSKyF X-Gm-Gg: ASbGncuV4mFwVffljSVKAXtkq9Qc9ltBGyjxfvGWhUF7TlyNX3vh51DCguNeNxYzm8H 1Up7rrRLL+gpzHNYt5Th32eeRalWMBMWOwSYaGcfLcjuqNBFBtrT8TTD9P/Q93WWpPOkNRDnW4m wr9buV50Tf/FsL76XwLhlqJEUtE2N1MYiYMrZeiqdtmyfKqAiTlRJ68GQ9iv2r8X7wL/8Dd53wi Bckd/8DxSmVnZTjSnd88T/x9ej8Z/0BklDaDkzXnbumS/OmRuus7w== X-Google-Smtp-Source: AGHT+IE4do0RmVPP3YvrOi8WIf50b4Q2gIDiTpJktwy8HQSKH3ffPwQ/9fUnTKUuP62ek0VfJxA6qA== X-Received: by 2002:a05:6a00:858b:b0:725:f1e9:5334 with SMTP id d2e1a72fcca58-72d8c756d22mr3015441b3a.8.1736919437112; Tue, 14 Jan 2025 21:37:17 -0800 (PST) Received: from terra ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72d406a61f7sm8537441b3a.175.2025.01.14.21.37.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 21:37:16 -0800 (PST) From: Maxim Cournoyer To: Simon Streit Subject: Re: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load In-Reply-To: (Simon Streit's message of "Sun, 12 Jan 2025 19:32:16 +0100") References: Date: Wed, 15 Jan 2025 14:37:05 +0900 Message-ID: <87r054d4e6.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::635; envelope-from=maxim.cournoyer@gmail.com; helo=mail-pl1-x635.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: bug-guix@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi Simon, Simon Streit writes: > Hello, > > if Guix is installed on a foreign system (Debian Bookworm), sourcing > GDK_PIXBUF_MODULE_FILE will prevent native applications on foreign > systems from loading their icons: [...] > If GDK_PIXBUF_MODULE_FILE is explicitly sourced, then Guix based > applications show their icons. If not, no icons are displayed and the > host has the ability restored to show icons. > > This leaves Guix on foreign systems currently at: Either the foreign > system knows how to load icons, or Guix, if sourcing > GDK_PIXBUF_MODULE_FILE. Not simultaneously. That's annoying, but kind of inherit to the design of that single entry GDK_PIXBUF_MODULE_FILE. If we had a GDK_PIXBUF_MODULE_FILES instead, allowing multiple entries, we could, in the guix-install.sh script arrange so that the that environment variable would always have a default value to that of the system, like we currently do for a bunch of XDG_* variable already. > This behaviour is somewhat similar in Guix Systems too and has had a > similar discussion before: [1]. There it was proposed to wrap the > applications to provide GDK_PIXBUF_MODULE_FILE directly. That's not a bad way, though again because of the design of GDK_PIXBUF_MODULE_FILE, it would make it impossible for the user to add extra loaders to their profile. This pixbuf module thing is akin to plugins; it's ideally meant to be extendable by the user post-installation. If we had GDK_PIXBUF_MODULE_FILES, we could opt to wrap the binaries with it in a 'prefix' fashion, leaving open the door for the user to augment its value (say by installing some loaders in their user profile). > > But, there was a time where this was not a problem that lasted up to at > least commit 6da03fcc459f4475553f394354ef37c628f39f97. I tried to > bisect my way into the past and find the offending change. > Unfortunately, I had to give up as trying to pull into commits around > August 2024 is close to impossible now. Many commits failed on me and I > never got anywhere close to where that change happened. > > > Therefor I am opening this bug report hoping that someone will help me > figure out what is going on here? I'm sorry, I do not know why this has recently become a problem for you. This GDK_PIXBUF_MODULE_FILE thing has been in Guix for at least 2 years. I think the best course of action would be to open an issue upstream against gdk-pixbuf, detailing our use case and how the current single entry GDK_PIXBUF_MODULE_FILE variable is a problematic, and throw the idea of having an actual search path of modules, such as GDK_PIXBUF_MODULE_FILES. If you get around to do that, please post the link so we can follow the conversation there, and perhaps participate. -- Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 14:32:33 2025 Received: (at submit) by debbugs.gnu.org; 25 Jan 2025 19:32:34 +0000 Received: from localhost ([127.0.0.1]:52697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbltP-0004le-7o for submit@debbugs.gnu.org; Sat, 25 Jan 2025 14:32:33 -0500 Received: from lists.gnu.org ([2001:470:142::17]:55526) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbltK-0004kf-CQ for submit@debbugs.gnu.org; Sat, 25 Jan 2025 14:32:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tbltA-0007jX-KP for bug-guix@gnu.org; Sat, 25 Jan 2025 14:32:16 -0500 Received: from smtprelay07.ispgateway.de ([134.119.228.102]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tblt8-0008DQ-Mw for bug-guix@gnu.org; Sat, 25 Jan 2025 14:32:16 -0500 Received: from [195.52.158.165] (helo=milk) by smtprelay07.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1tblt8-000000008I3-2XeL; Sat, 25 Jan 2025 20:32:14 +0100 From: Simon Streit To: Maxim Cournoyer Subject: Re: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load In-Reply-To: <87r054d4e6.fsf@gmail.com> (Maxim Cournoyer's message of "Wed, 15 Jan 2025 14:37:05 +0900") References: <87r054d4e6.fsf@gmail.com> Gcc: nnfolder+archive:sent.2025-01 Date: Sat, 25 Jan 2025 20:32:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Df-Sender: c2ltb25AbmV0cGFuaWMub3Jn Received-SPF: pass client-ip=134.119.228.102; envelope-from=simon@netpanic.org; helo=smtprelay07.ispgateway.de X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.049, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: bug-guix@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello Maxim, sorry about the delay. Maxim Cournoyer writes: > That's annoying, but kind of inherit to the design of that single > entry GDK_PIXBUF_MODULE_FILE. If we had a GDK_PIXBUF_MODULE_FILES > instead, allowing multiple entries, we could, in the guix-install.sh > script arrange so that the that environment variable would always have > a default value to that of the system, like we currently do for a > bunch of XDG_* variable already. With a hint from outside it finally became obvious what the problem is: Debian Bookworm's glibc is at 2.35 while Guix updated it to 2.39 last summer. Ever since, the foreign system may silently fail to load the icons. Which explains why I was trying to bisect my way to August 2024. I only observe this on my stable Debian systems. I set up a Debian Testing and: The images are back again. Including after sourcing GDK_PIXBUF_MODULE_FILE. Trixie's glibc is currently at 2.40. The error is usually silent. Only after adding librsvg to a profile and sourcing GDK_PIXBUF_MODULE_FILE will give you the following: --8<---------------cut here---------------start------------->8--- (nm-applet:2793559): nm-applet-WARNING **: 23:07:43.649: failed to load icon "nm-device-wired": Failed to load /usr/share/icons/Papirus/16x16/panel/nm-device-wired.svg: Unable to load image-loading module: /gnu/store/4sh8wcw94d4x7gpp82a4ryk8hd9zr0s9-librsvg-2.56.4/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /gnu/store/4sh8wcw94d4x7gpp82a4ryk8hd9zr0s9-librsvg-2.56.4/lib/librsvg-2.so.2) --8<---------------cut here---------------end--------------->8--- Quoting gdk-pixbuf-query-loaders(1): > Normally, the output of gdk-pixbuf-query-loaders is written to $lib- > dir/gdk-pixbuf-2.0/2.10.0/loaders.cache, where gdk-pixbuf looks for it > by default. If it is written to some other location, the environment > variable GDK_PIXBUF_MODULE_FILE can be set to point gdk-pixbuf at the > file. Which means, gdk-pixbuf is now looking into a completely different environment that may not properly know how to load, which can be the case if there is a mismatch with versions of glibc. > That's not a bad way, though again because of the design of > GDK_PIXBUF_MODULE_FILE, it would make it impossible for the user to > add extra loaders to their profile. This pixbuf module thing is akin > to plugins; it's ideally meant to be extendable by the user > post-installation. I took that advice and wrapped rofi-wayland with GDK_PIXBUF_MODULE_FILE. It helped. Rofi had its icons back. As it is an application launcher, it will pass on the variables from its own environment to the application it is launching. Which means: The icons in the native application are missing again. There has been a discussion regarding flatpak leaking its environment into the sandbox [1]. We are not discussing a sand-boxed environment, though it does look familiar. > I'm sorry, I do not know why this has recently become a problem for you. > This GDK_PIXBUF_MODULE_FILE thing has been in Guix for at least 2 years. > > I think the best course of action would be to open an issue upstream > against gdk-pixbuf, detailing our use case and how the current single > entry GDK_PIXBUF_MODULE_FILE variable is a problematic, and throw the > idea of having an actual search path of modules, such as > GDK_PIXBUF_MODULE_FILES. You're right. I should place a note upstream. For my part this issue is now resolved. Closing. [1] https://issues.guix.gnu.org/55072 Kind regards -- Simon From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 14:35:04 2025 Received: (at control) by debbugs.gnu.org; 25 Jan 2025 19:35:04 +0000 Received: from localhost ([127.0.0.1]:52729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tblvr-0004sQ-Oh for submit@debbugs.gnu.org; Sat, 25 Jan 2025 14:35:03 -0500 Received: from smtprelay04.ispgateway.de ([80.67.31.27]:34763) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tblvp-0004rh-OC for control@debbugs.gnu.org; Sat, 25 Jan 2025 14:35:02 -0500 Received: from [195.52.158.165] (helo=milk) by smtprelay04.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1tblvl-0000000067I-09E3 for control@debbugs.gnu.org; Sat, 25 Jan 2025 20:34:57 +0100 Date: Sat, 25 Jan 2025 20:34:57 +0100 Message-Id: To: control@debbugs.gnu.org From: Simon Streit Subject: control message for bug #75523 X-Df-Sender: c2ltb25AbmV0cGFuaWMub3Jn X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 75523 quit From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 22:49:51 2025 Received: (at 75523) by debbugs.gnu.org; 26 Jan 2025 03:49:51 +0000 Received: from localhost ([127.0.0.1]:53613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbteg-0002Kj-Qg for submit@debbugs.gnu.org; Sat, 25 Jan 2025 22:49:51 -0500 Received: from mail.envs.net ([5.199.136.28]:60372) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbteb-0002KV-Mq for 75523@debbugs.gnu.org; Sat, 25 Jan 2025 22:49:48 -0500 Received: from localhost (mail.envs.net [127.0.0.1]) by mail.envs.net (Postfix) with ESMTP id 12A8C38A2B9C; Sun, 26 Jan 2025 03:49:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=envs.net; s=modoboa; t=1737863384; bh=Ulb//i1M7OddgTbkaq63DX+ynkFLd1FTx6GGqyEIOBc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=deuREV48ljeIMWRpLL9xB+xKLbx4biHOLCFnNbNlZBQL/efgIegBEJbwOKNR2tBdF 0/P08N0Rv8laK1xauYWnwDHGB1q2TeWPOaToszebTGfuuwzObJhqh4QejvBxTYCFWd gQ/iZ6ACHJI1fBfqNcOEBq2PoBZ+mQX+ncz6m0ggoxO4USfw0AoCi7ej3jLvE0RI3+ /E9l7xOteAru2u4V39+9TwXZ5FewKdVW0UmPuRvkzJDCPxycMvuz79pnG3eTEpSCq6 yab5QiU3Zs/02yCRIjTkD8oN3vCOez6h5VIYzaKWl4hkLbbdmbaAaV8fCEVu4U9KAA MQAzhKF6xq8hhgT4d3bWDCMVe5f/5FmD+UqKV5cjc14C1xYB6qn7VRYMtuPTWmVkLa XHn2OLwcamNoFDY+LxEUFcQC8lv2WMvncQdZwtFWTUT40DjBlIGu6+ZKmAz8csaj4L QGmR5uE0pyOVxEnVzvvq0mpk3f9NOmmUYxwxcdv266OoDAoPkb3Xe5CvoMZ/vLIplJ hMhKAnz9peMuQGGWjHqhP9LNGnscW/g24YExpBPmVm0Wl622UhDWsw1r4zNxf05rYf jPq4thfp65TptadJ0k/Qe8rPlcuj/ozHtL69bYo9D9LhsJsbm/uD7ERPG59M+UlQuh v5sbNmUtM/sUuBAUaYAe2Ih8= X-Virus-Scanned: Debian amavisd-new at mail.envs.net Received: from mail.envs.net ([127.0.0.1]) by localhost (mail.envs.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kkMDvEmgnU8G; Sun, 26 Jan 2025 03:49:39 +0000 (UTC) Received: from localhost (unknown [112.44.100.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.envs.net (Postfix) with ESMTPSA; Sun, 26 Jan 2025 03:49:39 +0000 (UTC) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 18adc0a3; Sun, 26 Jan 2025 03:53:14 +0000 (UTC) From: =?utf-8?B?5a6L5paH5q2m?= To: Simon Streit Subject: Re: bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load In-Reply-To: (Simon Streit's message of "Sat, 25 Jan 2025 20:32:09 +0100") References: <87r054d4e6.fsf@gmail.com> Date: Sun, 26 Jan 2025 11:53:14 +0800 Message-ID: <87ed0q1b9x.fsf@envs.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75523 Cc: 75523@debbugs.gnu.org, Maxim Cournoyer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Simon Streit writes: >> I'm sorry, I do not know why this has recently become a problem for you. >> This GDK_PIXBUF_MODULE_FILE thing has been in Guix for at least 2 years. >> >> I think the best course of action would be to open an issue upstream >> against gdk-pixbuf, detailing our use case and how the current single >> entry GDK_PIXBUF_MODULE_FILE variable is a problematic, and throw the >> idea of having an actual search path of modules, such as >> GDK_PIXBUF_MODULE_FILES. > > You're right. I should place a note upstream. > > For my part this issue is now resolved. Closing. > Hello, just add a note that this issue would be addressed in https://issues.guix.gnu.org/75795 later. By using GUIX_GDK_PIXBUF_MODULE_FILES in guix to avoid influence foreign programs. Thanks. From unknown Thu Jun 19 14:22:12 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 23 Feb 2025 12:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator