From mboxrd@z Thu Jan 1 00:00:00 1970 From: iyzsong@member.fsf.org (=?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?=) Subject: bug#21842: Brasero fails to start on foreign distros Date: Sat, 07 Nov 2015 22:37:06 +0800 Message-ID: <87si4hg9kd.fsf@member.fsf.org> 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]:37158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv6wI-0000TH-Nc for bug-guix@gnu.org; Sat, 07 Nov 2015 12:06:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv6wF-0003Zc-Fw for bug-guix@gnu.org; Sat, 07 Nov 2015 12:06:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:38087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv6wF-0003ZY-C6 for bug-guix@gnu.org; Sat, 07 Nov 2015 12:06:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zv6wF-0006oF-2K for bug-guix@gnu.org; Sat, 07 Nov 2015 12:06:03 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv4cV-0002wY-19 for bug-guix@gnu.org; Sat, 07 Nov 2015 09:37:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv4cT-0003MZ-IO for bug-guix@gnu.org; Sat, 07 Nov 2015 09:37:30 -0500 In-Reply-To: (Federico Beffa's message of "Fri, 6 Nov 2015 17:31:15 +0100") 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: Federico Beffa Cc: wingo@pobox.com, 21842@debbugs.gnu.org Federico Beffa writes: > 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 addre= ss: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was no= t provided by any .service files >> >> (brasero:21487): GLib-GIO-ERROR **: Settings schema 'org.gnome.brasero.c= onfig' 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 Brase= ro, 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. Sure, I went ahead and push it. > >> >> 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. Yes, using the schemas cache built from profile is problematic for a program, but as long as it was wraped, the profile cache won't be used. But the profile cache is required for dconf-editor to be functional, I'd like to add it. > > 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. Technical right, but since the cache (hicolor) build for the program only contain it's own icon (eg: evince). For desktop-wide applications (panel, file managers) this cache is not useful at all. I guess there won't be much speeds up, need tests to find more detail though :-) > > 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. Yes, remove the phase is an easy way to suppress the warnings for icon cache. (there still have some programs install the icon cache, which could be handled per-package IMO.) We did need to suppress the warnings for the schemas cache. If just mask the collisions instead of avoid collisions actually don't have performance issue, I'm ok with it. > > 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-late= st.html > [3] https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00108.html I'd like to do some tests to see how the icon cache is used actually. Thanks!