bug#21842: Brasero fails to start on foreign distros

bug#21842: Brasero fails to start on foreign distros

[Ludovic Courtès]

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’.

bug#21842: Brasero fails to start on foreign distros

[Federico Beffa]

On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès <ludo@gnu.org> 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 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?

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 ‘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.

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

bug#21842: Brasero fails to start on foreign distros

[宋文武]

Federico Beffa <beffa@ieee.org> writes:

> On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès <ludo@gnu.org> 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
>> 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?
>
> 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 ‘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.

Thanks!

bug#21842: Brasero fails to start on foreign distros

[宋文武]

Federico Beffa <beffa@ieee.org> writes:

> On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès <ludo@gnu.org> 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 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?
>
> 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 ‘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.

Thanks!

bug#21842: Brasero fails to start on foreign distros

[Ludovic Courtès]

iyzsong@member.fsf.org (宋文武) skribis:

> Federico Beffa <beffa@ieee.org> 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’.