From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: bug#21842: Brasero fails to start on foreign distros Date: Fri, 6 Nov 2015 17:31:15 +0100 Message-ID: References: <87fv0jji88.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zujvs-00044u-Al for bug-guix@gnu.org; Fri, 06 Nov 2015 11:32:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zujvm-0007Uj-Gk for bug-guix@gnu.org; Fri, 06 Nov 2015 11:32:08 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:37081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zujvm-0007UN-Cb for bug-guix@gnu.org; Fri, 06 Nov 2015 11:32:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zujvm-0000xd-4r for bug-guix@gnu.org; Fri, 06 Nov 2015 11:32:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zujv3-0003h8-Ug for bug-guix@gnu.org; Fri, 06 Nov 2015 11:31:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zujv2-0006n5-NO for bug-guix@gnu.org; Fri, 06 Nov 2015 11:31:17 -0500 In-Reply-To: <87fv0jji88.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: wingo@pobox.com, iyzsong@member.fsf.org, 21842@debbugs.gnu.org On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Court=C3=A8s wrote: > As Andy notes on IRC, Brasero currently fails to start: > > --8<---------------cut here---------------start------------->8--- > $ /gnu/store/dq3817g8w80c9hffbgzspslqjy7szq35-brasero-3.12.1/bin/brasero > > ** (brasero:21487): WARNING **: Error retrieving accessibility bus addres= s: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not= provided by any .service files > > (brasero:21487): GLib-GIO-ERROR **: Settings schema 'org.gnome.brasero.co= nfig' is not installed > > Trace/breakpoint trap (core dumped) > --8<---------------cut here---------------end--------------->8--- > > On GuixSD, it starts just fine *if* it is installed in ~/.guix-profile, > because XDG_DATA_DIRS and XDG_CONFIG_DIRS are appropriately set. > > However, on foreign distros, it doesn=E2=80=99t work out of the box. > > Andy suggests using =E2=80=98glib-or-gtk-build-system=E2=80=99 for Braser= o, which > appears to solve the problem. > > WDYT? I think that using the 'glib-or-gtk-build-system' is the right thing to do. It will create a wrapper with the correct value of some environment variables, enabling the program to find its schema. > > Should we add a profile hook similar to =E2=80=98gtk-icon-themes=E2=80=99= in (guix > profiles) but for schemas? I do not think so because if a program gets the wrong schema (say, a different incompatible version) then it may crash. With the 'glib-or-gtk-build-system' it is guaranteed that it will find the schema used at build time. Speaking of GTK+ applications: I think that removing the generation of 'icon-theme.cache' from the 'glib-or-gtk-build-system' was a mistake (I may even have suggested this). It is my understanding (see [1, 2]) that this file is not strictly necessary, however it speeds up things and is therefore useful. Having the cache generated by the build-system allows one to use the program optimally without having to install it into a profile. The icon profile hook is still useful because it allows one to add icon themes a posteriori, that is after having build a program derivation and without having to rebuild it. The wrapper created by 'glib-or-gtk-build-system' still looks in the directories listed in XDG_DATA_DIRS (similarly for some other variables). See also the discussion at [3]. The reason for removing the phase from the build system was to suppress annoying collision warnings, but in my opinion it would be better to suppress them in a different way. As long as the profile hook is the last derivation being installed in a profile, such collisions are harmless and should just be masked. Regards, Fede [1] https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html [2] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest= .html [3] https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00108.html