--- Begin Message ---
|
Subject: |
Brasero fails to start on foreign distros |
|
Date: |
Fri, 06 Nov 2015 15:49:27 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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 address:
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.config'
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’t work out of the box.
Andy suggests using ‘glib-or-gtk-build-system’ for Brasero, which
appears to solve the problem.
WDYT?
Should we add a profile hook similar to ‘gtk-icon-themes’ in (guix
profiles) but for schemas?
TIA! :-)
Ludo’.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#21842: Brasero fails to start on foreign distros |
|
Date: |
Fri, 20 Nov 2015 15:58:33 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
address@hidden (宋文武) skribis:
> Federico Beffa <address@hidden> writes:
[...]
>> 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.
AIUI this (commit 1c40e3b7) fixes the bug, so I’m closing it.
>>> Should we add a profile hook similar to ‘gtk-icon-themes’ 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-latest.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.
What’s the conclusion with caches? We should probably move the
discussion to guix-devel.
Thanks!
Ludo’.
--- End Message ---