How to handle required plugins and dbus services for GNOME Programs?

How to handle required plugins and dbus services for GNOME Programs?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> A few caveats: in order for totem to work properly, you must have
>> several other packages installed in your profile.  I'm not entirely sure
>> of the full set needed, but I guess it includes:
>>
>>   grilo
>>   grilo-plugins
>>   gstreamer
>>   gst-plugins-base
>>   gst-plugins-good
>>   dconf
>>
>> You will also need to set the GRL_PLUGIN_PATH and GST_PLUGIN_SYSTEM_PATH
>> environment variables as advised by "guix package --search-paths".
>
> I can imagine why the plugins package need to be in the profile, but I
> find the others more surprising.  Do you know what happens?  Are Grilo,
> GStreamer, and DConf dlopened, or is it just to get the right search
> path recommendation that they are needed?

Actually, it turns out that 'grilo' doesn't need to be in the profile,
although if you don't have it you won't get the search path
recommendation which is crucial for Totem to work properly.

'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
need to explicitly install it and I'm not sure what would happen if it
were removed.

'dconf' apparently needs to be in the profile for both GNOME Terminal
and Totem because of the session dbus service(s) it provides.  Without
it, modern GNOME programs behave quite badly.  They have no way to
access or change their own configuration settings, e.g. if you go into
their preferences, you see checkboxes that do not change their state
when clicked.

I'm not sure how best to deal with issues like this, and also with
things like grilo-plugins and gst-plugins-* that are needed for the
proper functioning of Totem.  Should we make them propagated-inputs?

Or perhaps they should be normal inputs and we should use a wrapper to
add those directories as suffixes to GRL_PLUGIN_PATH and
GST_PLUGIN_SYSTEM_PATH automatically?

What do you think?

      Mark

Re: How to handle required plugins and dbus services for GNOME Programs?

[宋文武]

Mark H Weaver <mhw@netris.org> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> A few caveats: in order for totem to work properly, you must have
>>> several other packages installed in your profile.  I'm not entirely sure
>>> of the full set needed, but I guess it includes:
>>>
>>>   grilo
>>>   grilo-plugins
>>>   gstreamer
>>>   gst-plugins-base
>>>   gst-plugins-good
>>>   dconf
>>>
>>> You will also need to set the GRL_PLUGIN_PATH and GST_PLUGIN_SYSTEM_PATH
>>> environment variables as advised by "guix package --search-paths".
>>
>> I can imagine why the plugins package need to be in the profile, but I
>> find the others more surprising.  Do you know what happens?  Are Grilo,
>> GStreamer, and DConf dlopened, or is it just to get the right search
>> path recommendation that they are needed?
>
> Actually, it turns out that 'grilo' doesn't need to be in the profile,
> although if you don't have it you won't get the search path
> recommendation which is crucial for Totem to work properly.
According to ArchLinux, grilo-plugins is used for media discovery.
Which is optional. I'm ok to add it though.
>
> 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
> need to explicitly install it and I'm not sure what would happen if it
> were removed.
It's safe to remove 'gstreamer' from inputs.
>
> 'dconf' apparently needs to be in the profile for both GNOME Terminal
> and Totem because of the session dbus service(s) it provides.  Without
> it, modern GNOME programs behave quite badly.  They have no way to
> access or change their own configuration settings, e.g. if you go into
> their preferences, you see checkboxes that do not change their state
> when clicked.
Yes, dconf must in profile to be known to dbus-daemon (user sesssion).
It's loaded by dbus-daemon when needed.

https://developer.gnome.org/dconf/unstable/dconf-service.html
>
> I'm not sure how best to deal with issues like this, and also with
> things like grilo-plugins and gst-plugins-* that are needed for the
> proper functioning of Totem.  Should we make them propagated-inputs?
>
> Or perhaps they should be normal inputs and we should use a wrapper to
> add those directories as suffixes to GRL_PLUGIN_PATH and
> GST_PLUGIN_SYSTEM_PATH automatically?
Given that plugins only needed at runtime, how about make a 'raw' totem
package without wrapper and propagation, and a public one wrap it with
envs?  Thus avoid the rebuild of the raw totem package if plugins was
changed.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> I can imagine why the plugins package need to be in the profile, but I
>> find the others more surprising.  Do you know what happens?  Are Grilo,
>> GStreamer, and DConf dlopened, or is it just to get the right search
>> path recommendation that they are needed?
>
> Actually, it turns out that 'grilo' doesn't need to be in the profile,
> although if you don't have it you won't get the search path
> recommendation which is crucial for Totem to work properly.

OK.

I wonder if search path recommendations should work “deeper” somehow.
Because currently there’s always a problem when the search path
specification is attached to a library (GST_*, GRL_*) rather than to an
executable (CPATH, GUILE_LOAD_PATH, etc.)

The difficulty is that, ideally, the propagation of search path
specifications would be based on the run-time dependencies, not the
compile-time dependencies.

Thoughts?

> 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
> need to explicitly install it and I'm not sure what would happen if it
> were removed.
>
> 'dconf' apparently needs to be in the profile for both GNOME Terminal
> and Totem because of the session dbus service(s) it provides.  Without
> it, modern GNOME programs behave quite badly.  They have no way to
> access or change their own configuration settings, e.g. if you go into
> their preferences, you see checkboxes that do not change their state
> when clicked.

Really?  In Evince, I can change the state of various things (such as
whether or not to view documents continuously), but those changes are
lost across restarts.  However, changes made via dconf-editor are not
lost.  Weird no?

> I'm not sure how best to deal with issues like this, and also with
> things like grilo-plugins and gst-plugins-* that are needed for the
> proper functioning of Totem.  Should we make them propagated-inputs?

Are they required, or is it just that fewer features/file formats are
supported when they’re unavailable?

They could be propagated, but one would still need to know about these
environment variables.

> Or perhaps they should be normal inputs and we should use a wrapper to
> add those directories as suffixes to GRL_PLUGIN_PATH and
> GST_PLUGIN_SYSTEM_PATH automatically?

If they are required, that may be best.

Thanks,
Ludo’.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Mark H Weaver]

宋文武 <iyzsong@gmail.com> writes:
>> Actually, it turns out that 'grilo' doesn't need to be in the profile,
>> although if you don't have it you won't get the search path
>> recommendation which is crucial for Totem to work properly.
> According to ArchLinux, grilo-plugins is used for media discovery.
> Which is optional. I'm ok to add it though.

Without the grl-bookmarks grilo plugin, attempts to add local video
files to the playlist via the GUI interface silently fail.  See:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768515

I ran into this problem before I packaged 'gom'.  So, although it is
still possible to play local videos by running "totem <filename>", I
would say that Totem malfunctions quite badly even for basic usage
without grilo-plugins.

>> 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
>> need to explicitly install it and I'm not sure what would happen if it
>> were removed.
> It's safe to remove 'gstreamer' from inputs.

I don't understand.  Do you mean that it's safe to remove 'gstreamer'
from the inputs of some package?  Which package?

>> 'dconf' apparently needs to be in the profile for both GNOME Terminal
>> and Totem because of the session dbus service(s) it provides.  Without
>> it, modern GNOME programs behave quite badly.  They have no way to
>> access or change their own configuration settings, e.g. if you go into
>> their preferences, you see checkboxes that do not change their state
>> when clicked.
> Yes, dconf must in profile to be known to dbus-daemon (user sesssion).
> It's loaded by dbus-daemon when needed.
>
> https://developer.gnome.org/dconf/unstable/dconf-service.html
>>
>> I'm not sure how best to deal with issues like this, and also with
>> things like grilo-plugins and gst-plugins-* that are needed for the
>> proper functioning of Totem.  Should we make them propagated-inputs?
>>
>> Or perhaps they should be normal inputs and we should use a wrapper to
>> add those directories as suffixes to GRL_PLUGIN_PATH and
>> GST_PLUGIN_SYSTEM_PATH automatically?
> Given that plugins only needed at runtime, how about make a 'raw' totem
> package without wrapper and propagation, and a public one wrap it with
> envs?  Thus avoid the rebuild of the raw totem package if plugins was
> changed.

I'm not sure it would be worth it.  Totem itself doesn't take very long
to build.

     Mark

Re: How to handle required plugins and dbus services for GNOME Programs?

[David Hashe]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

It's worth noting that these same questions appear in the Rhythmbox patch I
submitted earlier this week, so I'll be watching what we decide here for
guidance on how to improve that patch.

Thanks,
David

On Wed, Jun 24, 2015 at 12:58 AM, Mark H Weaver <mhw@netris.org> wrote:

> ludo@gnu.org (Ludovic Courtès) writes:
>
> > Mark H Weaver <mhw@netris.org> skribis:
> >
> >> A few caveats: in order for totem to work properly, you must have
> >> several other packages installed in your profile.  I'm not entirely sure
> >> of the full set needed, but I guess it includes:
> >>
> >>   grilo
> >>   grilo-plugins
> >>   gstreamer
> >>   gst-plugins-base
> >>   gst-plugins-good
> >>   dconf
> >>
> >> You will also need to set the GRL_PLUGIN_PATH and GST_PLUGIN_SYSTEM_PATH
> >> environment variables as advised by "guix package --search-paths".
> >
> > I can imagine why the plugins package need to be in the profile, but I
> > find the others more surprising.  Do you know what happens?  Are Grilo,
> > GStreamer, and DConf dlopened, or is it just to get the right search
> > path recommendation that they are needed?
>
> Actually, it turns out that 'grilo' doesn't need to be in the profile,
> although if you don't have it you won't get the search path
> recommendation which is crucial for Totem to work properly.
>
> 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
> need to explicitly install it and I'm not sure what would happen if it
> were removed.
>
> 'dconf' apparently needs to be in the profile for both GNOME Terminal
> and Totem because of the session dbus service(s) it provides.  Without
> it, modern GNOME programs behave quite badly.  They have no way to
> access or change their own configuration settings, e.g. if you go into
> their preferences, you see checkboxes that do not change their state
> when clicked.
>
> I'm not sure how best to deal with issues like this, and also with
> things like grilo-plugins and gst-plugins-* that are needed for the
> proper functioning of Totem.  Should we make them propagated-inputs?
>
> Or perhaps they should be normal inputs and we should use a wrapper to
> add those directories as suffixes to GRL_PLUGIN_PATH and
> GST_PLUGIN_SYSTEM_PATH automatically?
>
> What do you think?
>
>       Mark
>
>

[-- Attachment #2: Type: text/html, Size: 3096 bytes --]

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> 'dconf' apparently needs to be in the profile for both GNOME Terminal
>> and Totem because of the session dbus service(s) it provides.  Without
>> it, modern GNOME programs behave quite badly.  They have no way to
>> access or change their own configuration settings, e.g. if you go into
>> their preferences, you see checkboxes that do not change their state
>> when clicked.
>
> Really?  In Evince, I can change the state of various things (such as
> whether or not to view documents continuously), but those changes are
> lost across restarts.  However, changes made via dconf-editor are not
> lost.  Weird no?

'dconf' is responsible for handling the program configuration. For
writes, it contacts D-Bus, for read it doesn't need D-Bus.

https://developer.gnome.org/dconf/0.22/dconf-overview.html

If 'dconf' is not available, the program reverts to a 'memory' back-end
and configuration is lost upon exit.

For this reason 'dconf' should be available to all GLib programs
(implicit input to 'glib-or-gtk-build-system'?).

Regards,
Fede

Re: How to handle required plugins and dbus services for GNOME Programs?

[宋文武]

Mark H Weaver <mhw@netris.org> writes:

> 宋文武 <iyzsong@gmail.com> writes:
>>> Actually, it turns out that 'grilo' doesn't need to be in the profile,
>>> although if you don't have it you won't get the search path
>>> recommendation which is crucial for Totem to work properly.
>> According to ArchLinux, grilo-plugins is used for media discovery.
>> Which is optional. I'm ok to add it though.
>
> Without the grl-bookmarks grilo plugin, attempts to add local video
> files to the playlist via the GUI interface silently fail.  See:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768515
>
> I ran into this problem before I packaged 'gom'.  So, although it is
> still possible to play local videos by running "totem <filename>", I
> would say that Totem malfunctions quite badly even for basic usage
> without grilo-plugins.
So grilo-plugins is really a curcial dep, thanks for explaination.
>
>>> 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
>>> need to explicitly install it and I'm not sure what would happen if it
>>> were removed.
>> It's safe to remove 'gstreamer' from inputs.
>
> I don't understand.  Do you mean that it's safe to remove 'gstreamer'
> from the inputs of some package?  Which package?
I mean totem, sorry for the confusion.
>
>>> 'dconf' apparently needs to be in the profile for both GNOME Terminal
>>> and Totem because of the session dbus service(s) it provides.  Without
>>> it, modern GNOME programs behave quite badly.  They have no way to
>>> access or change their own configuration settings, e.g. if you go into
>>> their preferences, you see checkboxes that do not change their state
>>> when clicked.
>> Yes, dconf must in profile to be known to dbus-daemon (user sesssion).
>> It's loaded by dbus-daemon when needed.
>>
>> https://developer.gnome.org/dconf/unstable/dconf-service.html
>>>
>>> I'm not sure how best to deal with issues like this, and also with
>>> things like grilo-plugins and gst-plugins-* that are needed for the
>>> proper functioning of Totem.  Should we make them propagated-inputs?
>>>
>>> Or perhaps they should be normal inputs and we should use a wrapper to
>>> add those directories as suffixes to GRL_PLUGIN_PATH and
>>> GST_PLUGIN_SYSTEM_PATH automatically?
>> Given that plugins only needed at runtime, how about make a 'raw' totem
>> package without wrapper and propagation, and a public one wrap it with
>> envs?  Thus avoid the rebuild of the raw totem package if plugins was
>> changed.
>
> I'm not sure it would be worth it.  Totem itself doesn't take very long
> to build.
OK.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Really?  In Evince, I can change the state of various things (such as
>> whether or not to view documents continuously), but those changes are
>> lost across restarts.  However, changes made via dconf-editor are not
>> lost.  Weird no?
>
> 'dconf' is responsible for handling the program configuration. For
> writes, it contacts D-Bus, for read it doesn't need D-Bus.
>
> https://developer.gnome.org/dconf/0.22/dconf-overview.html
>
> If 'dconf' is not available, the program reverts to a 'memory' back-end
> and configuration is lost upon exit.

In this last sentence, are you referring to dconf-the-program,
dconf-the-library, or dconf-the-service?

dconf-the-package is in my profile, so I would expect Evince to
automatically dbus-launch it when it needs to save its settings, but
apparently that doesn’t happen.

> For this reason 'dconf' should be available to all GLib programs
> (implicit input to 'glib-or-gtk-build-system'?).

dconf-the-program?

Thanks,
Ludo’.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

On Thu, Jun 25, 2015 at 1:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> Really?  In Evince, I can change the state of various things (such as
>>> whether or not to view documents continuously), but those changes are
>>> lost across restarts.  However, changes made via dconf-editor are not
>>> lost.  Weird no?
>>
>> 'dconf' is responsible for handling the program configuration. For
>> writes, it contacts D-Bus, for read it doesn't need D-Bus.
>>
>> https://developer.gnome.org/dconf/0.22/dconf-overview.html
>>
>> If 'dconf' is not available, the program reverts to a 'memory' back-end
>> and configuration is lost upon exit.
>
> In this last sentence, are you referring to dconf-the-program,
> dconf-the-library, or dconf-the-service?
>
> dconf-the-package is in my profile, so I would expect Evince to
> automatically dbus-launch it when it needs to save its settings, but
> apparently that doesn’t happen.

I'm not sure about the terminology, but if you do

GIO_EXTRA_MODULES=/gnu/store/...-dconf-0.22.0/lib/gio/modules evince

it should work. (See comments in the 'glib-or-gtk-build-system'.)

>
>> For this reason 'dconf' should be available to all GLib programs
>> (implicit input to 'glib-or-gtk-build-system'?).
>
> dconf-the-program?

See above.

>
> Thanks,
> Ludo’.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Federico Beffa <beffa@ieee.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> Really?  In Evince, I can change the state of various things (such as
>>> whether or not to view documents continuously), but those changes are
>>> lost across restarts.  However, changes made via dconf-editor are not
>>> lost.  Weird no?
>>
>> 'dconf' is responsible for handling the program configuration. For
>> writes, it contacts D-Bus, for read it doesn't need D-Bus.
>>
>> https://developer.gnome.org/dconf/0.22/dconf-overview.html
>>
>> If 'dconf' is not available, the program reverts to a 'memory' back-end
>> and configuration is lost upon exit.

In Totem and GNOME Terminal, it's worse than that.  I've found that
without 'dconf' in my profile, I cannot even modify the settings within
a single run of the program.  For example, if I click on a checkbox in
the preferences, I see the state of the checkbox toggle and then
immediately revert back to its original setting within a small fraction
of a second.

      Mark

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Thu, Jun 25, 2015 at 1:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>> [...]
>>
>>>> Really?  In Evince, I can change the state of various things (such as
>>>> whether or not to view documents continuously), but those changes are
>>>> lost across restarts.  However, changes made via dconf-editor are not
>>>> lost.  Weird no?
>>>
>>> 'dconf' is responsible for handling the program configuration. For
>>> writes, it contacts D-Bus, for read it doesn't need D-Bus.
>>>
>>> https://developer.gnome.org/dconf/0.22/dconf-overview.html
>>>
>>> If 'dconf' is not available, the program reverts to a 'memory' back-end
>>> and configuration is lost upon exit.
>>
>> In this last sentence, are you referring to dconf-the-program,
>> dconf-the-library, or dconf-the-service?
>>
>> dconf-the-package is in my profile, so I would expect Evince to
>> automatically dbus-launch it when it needs to save its settings, but
>> apparently that doesn’t happen.
>
> I'm not sure about the terminology, but if you do
>
> GIO_EXTRA_MODULES=/gnu/store/...-dconf-0.22.0/lib/gio/modules evince
>
> it should work. (See comments in the 'glib-or-gtk-build-system'.)

Oh, I see.

Then, should we make dconf an implicit input of
glib-or-gtk-build-system?

Or should we add it as an explicit dependency on a case-by-case basis?

Thanks,
Ludo’.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

On Mon, Jun 29, 2015 at 1:35 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> On Thu, Jun 25, 2015 at 1:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>> [...]
>>>
>>>>> Really?  In Evince, I can change the state of various things (such as
>>>>> whether or not to view documents continuously), but those changes are
>>>>> lost across restarts.  However, changes made via dconf-editor are not
>>>>> lost.  Weird no?
>>>>
>>>> 'dconf' is responsible for handling the program configuration. For
>>>> writes, it contacts D-Bus, for read it doesn't need D-Bus.
>>>>
>>>> https://developer.gnome.org/dconf/0.22/dconf-overview.html
>>>>
>>>> If 'dconf' is not available, the program reverts to a 'memory' back-end
>>>> and configuration is lost upon exit.
>>>
>>> In this last sentence, are you referring to dconf-the-program,
>>> dconf-the-library, or dconf-the-service?
>>>
>>> dconf-the-package is in my profile, so I would expect Evince to
>>> automatically dbus-launch it when it needs to save its settings, but
>>> apparently that doesn’t happen.
>>
>> I'm not sure about the terminology, but if you do
>>
>> GIO_EXTRA_MODULES=/gnu/store/...-dconf-0.22.0/lib/gio/modules evince
>>
>> it should work. (See comments in the 'glib-or-gtk-build-system'.)
>
> Oh, I see.
>
> Then, should we make dconf an implicit input of
> glib-or-gtk-build-system?
>
> Or should we add it as an explicit dependency on a case-by-case basis?

IMO, given that every GLib based program needs it, the right thing to
do is to make it an implicit input of 'glib-or-gtk-build-system'.

In a similar way, every GLib based program/library makes use of sound
themes. For this to work it needs access to 'libcanberra'. Thus, for
sound themes to work, 'libcanberra' should also be an implicit input
of the build system.

You may be using a desktop where no sound theme is used/configured and
therefore not be seeing any message about this. But, if you use a
desktop with a sound theme, e.g. GNOME, you will see the following
messages:
Gtk-Message: Failed to load module "canberra-gtk-module"
This is taken care by setting

GTK_PATH=/gnu/store/...-libcanberra-0.30/lib/gtk-3.0/modules

and would be done automatically by the 'glib-or-gtk-build-system' if
'libcanberra' would be an implicit input.

Regards,
Fede

Re: How to handle required plugins and dbus services for GNOME Programs?

[Mark H Weaver]

Federico Beffa <beffa@ieee.org> writes:

> On Mon, Jun 29, 2015 at 1:35 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Then, should we make dconf an implicit input of
>> glib-or-gtk-build-system?
>>
>> Or should we add it as an explicit dependency on a case-by-case basis?
>
> IMO, given that every GLib based program needs it, the right thing to
> do is to make it an implicit input of 'glib-or-gtk-build-system'.

Many GLib based programs do *not* need dconf.  So far, I know of only
two programs in Guix that need dconf.  It is a GNOME thing, not a GLib
thing.

Also, I wouldn't be surprised if one of the transitive inputs of dconf
uses 'glib-or-gtk-build-system', which would lead to a circularity
problem.

> In a similar way, every GLib based program/library makes use of sound
> themes.

That's not true either.

It may be that we should have a 'gnome-build-system' that's based on
'glib-or-gtk-build-system' but adds these extra implicit inputs and
arranges for more environment variables to be set in the wrappers.

Thoughts?

      Mark

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

On Tue, Jun 30, 2015 at 6:01 PM, Mark H Weaver <mhw@netris.org> wrote:
> Federico Beffa <beffa@ieee.org> writes:
>
>> On Mon, Jun 29, 2015 at 1:35 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Then, should we make dconf an implicit input of
>>> glib-or-gtk-build-system?
>>>
>>> Or should we add it as an explicit dependency on a case-by-case basis?
>>
>> IMO, given that every GLib based program needs it, the right thing to
>> do is to make it an implicit input of 'glib-or-gtk-build-system'.
>
> Many GLib based programs do *not* need dconf.  So far, I know of only
> two programs in Guix that need dconf.  It is a GNOME thing, not a GLib
> thing.

You are right. I got confused. 'dconf' is a backend of 'GSettings'.

>
> Also, I wouldn't be surprised if one of the transitive inputs of dconf
> uses 'glib-or-gtk-build-system', which would lead to a circularity
> problem.
>
>> In a similar way, every GLib based program/library makes use of sound
>> themes.
>
> That's not true either.
>
> It may be that we should have a 'gnome-build-system' that's based on
> 'glib-or-gtk-build-system' but adds these extra implicit inputs and
> arranges for more environment variables to be set in the wrappers.

The distinction between "a GNOME application" and an application
making use of "a subset of the GNOME infrastructure and requiring
'dconf' and/or 'libcanberra'" doesn't appear to be clear cut to me:

* GLib is hosted on the GNOME site. Isn't it part of the GNOME project?
* I get the warnings:

    Gtk-Message: Failed to load module "canberra-gtk-module"
    GLib-GIO-Message: Using the 'memory' GSettings backend.  Your
settings will not be saved or shared with other     applications.

  even when starting 'emacs' and the first one even when importing
'matplotlib' inside of a python shell. As far as I know, these two
programs are not part of GNOME.

Adding 'dconf' and 'libcanberra' as default inputs to
'glib-or-gtk-build-system' would make many of these problems go away,
with the only drawback of a possibly unused entry in an environment
variable. However, if you want to be super accurate then yes, this
will not do.

Fede

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> Adding 'dconf' and 'libcanberra' as default inputs to
> 'glib-or-gtk-build-system' would make many of these problems go away,
> with the only drawback of a possibly unused entry in an environment
> variable.

Another drawback is that it will increase the size of the closure of
each package that is concerned (‘emacs’ is at 835 MiB without dconf nor
libcanberra.)

> However, if you want to be super accurate then yes, this
> will not do.

I guess it’s a trade-off.

How difficult would it be to identify applications that require the
dconf GIO module (Totem, Evince) vs. those that can live without it
(Emacs)?

Likewise, what fraction of the ‘glib-or-gtk-build-system’ packages
require dconf?

Based on that, we could choose to either make it opt-in (that is,
explicitly add dconf as an input when needed), or opt-out (dconf is an
implicit input of ‘glib-or-gtk-build-system’ that can be removed with
#:dconf? #f).  Similarly with libcanberra.

How does that sound?

Ludo’.

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

On Tue, Jun 30, 2015 at 9:28 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> Adding 'dconf' and 'libcanberra' as default inputs to
>> 'glib-or-gtk-build-system' would make many of these problems go away,
>> with the only drawback of a possibly unused entry in an environment
>> variable.
>
> Another drawback is that it will increase the size of the closure of
> each package that is concerned (‘emacs’ is at 835 MiB without dconf nor
> libcanberra.)

That's a scary number, but, I guess, it does include libraries shared
with a large number of programs. So it doesn't represent (in the
typical case) what you need to download "just" to add emacs.

>
>> However, if you want to be super accurate then yes, this
>> will not do.
>
> I guess it’s a trade-off.
>
> How difficult would it be to identify applications that require the
> dconf GIO module (Totem, Evince) vs. those that can live without it
> (Emacs)?

I was just trying to provide some input (like having to set
GIO_EXTRA_MODULES up in this thread) from things that I did
investigate a while back... I'm not trying to disturb the piece of
mind of anybody. Right now I have no time to do this kind of
investigations.

The way I came across GIO_EXTRA_MODULES, was by looking at how I could
suppress the warnings we are talking about, in the emacs package. I've
found that, despite possibly not being needed, many people are annoyed
by such warnings and are interested in suppressing them (I was one of
those). In the end of the day, as an end user without knowledge of the
program internals, how can you know if it is harmless or a real
problem?

>
> Likewise, what fraction of the ‘glib-or-gtk-build-system’ packages
> require dconf?
>
> Based on that, we could choose to either make it opt-in (that is,
> explicitly add dconf as an input when needed), or opt-out (dconf is an
> implicit input of ‘glib-or-gtk-build-system’ that can be removed with
> #:dconf? #f).  Similarly with libcanberra.
>
> How does that sound?

I have a very small number of guix based graphical programs. So, my
case is not very relevant statistically. But, all of them either
complain about at least one of the two packages in question, or they
do have them as inputs.

0 means: it's not an input and I can't see complains.
1 means: it's either an input, or I get complains.

| package           | dconf | libcanberra |
|-------------------+-------+-------------|
| emacs             |     1 |           1 |
| evince            |     1 |           1 |
| python-matplotlib |     0 |           1 |
| inkscape          |     0 |           1 |
| gimp              |     0 |           1 |

Regards,
Fede

Re: How to handle required plugins and dbus services for GNOME Programs?

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> 'dconf' apparently needs to be in the profile for both GNOME Terminal
> and Totem because of the session dbus service(s) it provides.  Without
> it, modern GNOME programs behave quite badly.  They have no way to
> access or change their own configuration settings, e.g. if you go into
> their preferences, you see checkboxes that do not change their state
> when clicked.
>
> I'm not sure how best to deal with issues like this, and also with
> things like grilo-plugins and gst-plugins-* that are needed for the
> proper functioning of Totem.  Should we make them propagated-inputs?
>
> Or perhaps they should be normal inputs and we should use a wrapper to
> add those directories as suffixes to GRL_PLUGIN_PATH and
> GST_PLUGIN_SYSTEM_PATH automatically?
>
> What do you think?

So, at this point my inclination is to do the following:

* Add 'dconf' to the propagated-inputs of 'totem', since totem needs
  dconf services to be available on the user session D-Bus.

* Add a wrapper for 'totem' that add prefixes to both
  GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH to ensure reliable access
  to a baseline set of plugins needed for proper functioning of 'totem'.
  This includes grilo-plugins, gst-plugins-base, and gst-plugins-good.
  IMO, this hard-coded set of plugins should exclude patent-encumbered
  codecs, so no gst-libav or gst-plugins-ugly.

Please see the attached 'totem' package.  To simplify things, the values
of the GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH environment variables
are taken directly from the build environment (using 'getenv') and
propagated unchanged into the created wrapper.

What do you think?

      Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] gnu: Add totem --]
[-- Type: text/x-patch, Size: 4054 bytes --]

From f1cbb55b1dd87bffd34d77cf6e1e68f33c38b9e0 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Sat, 20 Jun 2015 18:26:34 -0400
Subject: [PATCH] gnu: Add totem.

* gnu/packages/gnome.scm (totem): New variable.
---
 gnu/packages/gnome.scm | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 30277f5..3142506 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -57,6 +57,7 @@
   #:use-module (gnu packages libcanberra)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages libusb)
+  #:use-module (gnu packages lirc)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages image)
   #:use-module (gnu packages perl)
@@ -2823,3 +2824,81 @@ for application developers.")
      "Grilo is a framework focused on making media discovery and browsing easy
 for application developers.")
     (license license:lgpl2.1+)))
+
+(define-public totem
+  (package
+    (name "totem")
+    (version "3.16.1")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "mirror://gnome/sources/" name "/"
+                           (version-major+minor version) "/"
+                           name "-" version ".tar.xz"))
+       (sha256
+        (base32
+         "1nkm2i271ivq40hryrl6px39gbbvhmlx4vmvwvw4h3z8xh3013f9"))))
+    (build-system glib-or-gtk-build-system)
+    (native-inputs
+     `(("pkg-config" ,pkg-config)
+       ("desktop-file-utils" ,desktop-file-utils)
+       ("gobject-introspection" ,gobject-introspection)
+       ("intltool" ,intltool)
+       ("itstool" ,itstool)))
+    (propagated-inputs
+     `(("dconf" ,dconf)))
+    (inputs
+     `(("gtk+" ,gtk+)
+       ("gdk-pixbuf" ,gdk-pixbuf)
+       ("atk" ,atk)
+       ("cairo" ,cairo)
+       ("dbus-glib" ,dbus-glib)
+       ("clutter" ,clutter)
+       ("clutter-gtk" ,clutter-gtk)
+       ("clutter-gst" ,clutter-gst)
+       ("xproto" ,xproto)
+       ("libxxf86vm" ,libxxf86vm)
+       ("libxtst" ,libxtst)
+       ("libxrandr" ,libxrandr)
+       ("libxml2" ,libxml2)
+       ("libsoup" ,libsoup)
+       ("libpeas" ,libpeas)
+       ("librsvg" ,librsvg)
+       ("lirc" ,lirc)
+       ("gnome-desktop" ,gnome-desktop)
+       ("gstreamer" ,gstreamer)
+       ("gst-plugins-base" ,gst-plugins-base)
+       ("gst-plugins-good" ,gst-plugins-good)
+       ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
+       ("adwaita-icon-theme" ,adwaita-icon-theme)
+       ;; XXX We use python-2 because libxml2 because itstool (which needs
+       ;; libxml) currently uses python-2.
+       ("python" ,python-2)
+       ("python-pygobject" ,python2-pygobject)
+       ;; XXX TODO pylint needed for python support
+       ("totem-pl-parser" ,totem-pl-parser)
+       ("grilo" ,grilo)
+       ("grilo-plugins" ,grilo-plugins)
+       ("nettle" ,nettle)
+       ("vala" ,vala)))
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-after
+          'install 'wrap-totem
+          (lambda* (#:key inputs outputs #:allow-other-keys)
+            (let ((out             (assoc-ref outputs "out"))
+                  (gst-plugin-path (getenv "GST_PLUGIN_SYSTEM_PATH"))
+                  (grl-plugin-path (getenv "GRL_PLUGIN_PATH")))
+              (wrap-program (string-append out "/bin/totem")
+                `("GST_PLUGIN_SYSTEM_PATH" ":" prefix (,gst-plugin-path))
+                `("GRL_PLUGIN_PATH"        ":" prefix (,grl-plugin-path))))
+            #t)))))
+    (home-page "https://wiki.gnome.org/Apps/Videos")
+    (synopsis "Simple media player for GNOME based on GStreamer")
+    (description "Totem is a simple yet featureful media player for GNOME
+which can read a large number of file formats.")
+    ;; GPL2+ with an exception clause for non-GPL compatible GStreamer plugins
+    ;; to be used and distributed together with GStreamer and Totem.  See
+    ;; file://COPYING in the source distribution for details.
+    (license license:gpl2+)))
-- 
2.4.3

Re: How to handle required plugins and dbus services for GNOME Programs?

[宋文武]

Mark H Weaver <mhw@netris.org> writes:

[...]
> So, at this point my inclination is to do the following:
>
> * Add 'dconf' to the propagated-inputs of 'totem', since totem needs
>   dconf services to be available on the user session D-Bus.
>
> * Add a wrapper for 'totem' that add prefixes to both
>   GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH to ensure reliable access
>   to a baseline set of plugins needed for proper functioning of 'totem'.
>   This includes grilo-plugins, gst-plugins-base, and gst-plugins-good.
>   IMO, this hard-coded set of plugins should exclude patent-encumbered
>   codecs, so no gst-libav or gst-plugins-ugly.
>
> Please see the attached 'totem' package.  To simplify things, the values
> of the GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH environment variables
> are taken directly from the build environment (using 'getenv') and
> propagated unchanged into the created wrapper.
>
> What do you think?
Look great!

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> So, at this point my inclination is to do the following:
>
> * Add 'dconf' to the propagated-inputs of 'totem', since totem needs
>   dconf services to be available on the user session D-Bus.
>
> * Add a wrapper for 'totem' that add prefixes to both
>   GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH to ensure reliable access
>   to a baseline set of plugins needed for proper functioning of 'totem'.
>   This includes grilo-plugins, gst-plugins-base, and gst-plugins-good.
>   IMO, this hard-coded set of plugins should exclude patent-encumbered
>   codecs, so no gst-libav or gst-plugins-ugly.
>
> Please see the attached 'totem' package.  To simplify things, the values
> of the GST_PLUGIN_SYSTEM_PATH and GRL_PLUGIN_PATH environment variables
> are taken directly from the build environment (using 'getenv') and
> propagated unchanged into the created wrapper.
>
> What do you think?

Sounds good.  Thanks for moving forward!

Ludo’.

RE: How to handle required plugins and dbus services for GNOME Programs?

[Cook, Malcolm]

Hi, 

What fortune...

> IMO, given that every GLib based program needs it, the right thing to do is to
> make it an implicit input of 'glib-or-gtk-build-system'.
> 
> In a similar way, every GLib based program/library makes use of sound
> themes. For this to work it needs access to 'libcanberra'. Thus, for sound
> themes to work, 'libcanberra' should also be an implicit input of the build
> system.
> 
> You may be using a desktop where no sound theme is used/configured and
> therefore not be seeing any message about this. But, if you use a desktop
> with a sound theme, e.g. GNOME, you will see the following
> messages:
> Gtk-Message: Failed to load module "canberra-gtk-module"
> This is taken care by setting
> 
> GTK_PATH=/gnu/store/...-libcanberra-0.30/lib/gtk-3.0/modules
> 

... I was at this very moment poised to ask about this very issue here, for, in the case of a fresh guix 0.8.3 I was witnessing:

After `guix package --install emacs`, I find:

	$ emacs
	(process:3941): Gtk-WARNING **: Locale not supported by C library.
		Using the fallback 'C' locale.
	Gtk-Message: Failed to load module "canberra-gtk-module"
	Gtk-Message: Failed to load module "pk-gtk-module"

The installed emacs v 24.5 does still start, and looks pretty snappy (despite, alas, being build without svg support).

But, let me try and take your advice:

	$ guix package -i libcanberra
	$ export GTK_PATH=/gnu/store/*-libcanberra*/lib/gtk-3.0/modules
	$ echo $GTK_PATH
	/gnu/store/x06vfgf5fn09yr9crqlg22rwc301jnhp-libcanberra-0.30/lib/gtk-3.0/modules
	$ ls $GTK_PATH
	libcanberra-gtk3-module.la  libcanberra-gtk3-module.so  libcanberra-gtk-module.so

But, upon starting emacs again, alas, I still get the same Gtk warnings and messages.

Am I not following your advice, or otherwise mis-understanding it?

Thanks,

Malcolm

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

On Thu, Jul 23, 2015 at 8:16 PM, Cook, Malcolm <MEC@stowers.org> wrote:
> Hi,
>
> What fortune...
>
>> IMO, given that every GLib based program needs it, the right thing to do is to
>> make it an implicit input of 'glib-or-gtk-build-system'.
>>
>> In a similar way, every GLib based program/library makes use of sound
>> themes. For this to work it needs access to 'libcanberra'. Thus, for sound
>> themes to work, 'libcanberra' should also be an implicit input of the build
>> system.
>>
>> You may be using a desktop where no sound theme is used/configured and
>> therefore not be seeing any message about this. But, if you use a desktop
>> with a sound theme, e.g. GNOME, you will see the following
>> messages:
>> Gtk-Message: Failed to load module "canberra-gtk-module"
>> This is taken care by setting
>>
>> GTK_PATH=/gnu/store/...-libcanberra-0.30/lib/gtk-3.0/modules
>>
>
> ... I was at this very moment poised to ask about this very issue here, for, in the case of a fresh guix 0.8.3 I was witnessing:
>
> After `guix package --install emacs`, I find:
>
>         $ emacs
>         (process:3941): Gtk-WARNING **: Locale not supported by C library.
>                 Using the fallback 'C' locale.
>         Gtk-Message: Failed to load module "canberra-gtk-module"
>         Gtk-Message: Failed to load module "pk-gtk-module"
>
> The installed emacs v 24.5 does still start, and looks pretty snappy (despite, alas, being build without svg support).
>
> But, let me try and take your advice:
>
>         $ guix package -i libcanberra
>         $ export GTK_PATH=/gnu/store/*-libcanberra*/lib/gtk-3.0/modules
>         $ echo $GTK_PATH
>         /gnu/store/x06vfgf5fn09yr9crqlg22rwc301jnhp-libcanberra-0.30/lib/gtk-3.0/modules
>         $ ls $GTK_PATH
>         libcanberra-gtk3-module.la  libcanberra-gtk3-module.so  libcanberra-gtk-module.so
>
> But, upon starting emacs again, alas, I still get the same Gtk warnings and messages.
>
> Am I not following your advice, or otherwise mis-understanding it?

I had a typo, sorry: the path should stop at one level above the modules:

$GTK_PATH=/gnu/store/nlm81g8hgsw7d01la14zjycjcgamn4qp-libcanberra-0.30/lib/gtk-3.0
emacs

GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings
will not be saved or shared with other applications.

The remaining above message is because of the missing 'dconf' (I guess
we should add it). I'm not getting the message about "pk-gtk-module".
I'm not sure what it refers to.

HTH,
Fede

RE: How to handle required plugins and dbus services for GNOME Programs?

[Cook, Malcolm]

> On Thu, Jul 23, 2015 at 8:16 PM, Cook, Malcolm <MEC@stowers.org> wrote:
> > Hi,
> >
> > What fortune...
> >
> >> IMO, given that every GLib based program needs it, the right thing to
> >> do is to make it an implicit input of 'glib-or-gtk-build-system'.
> >>
> >> In a similar way, every GLib based program/library makes use of sound
> >> themes. For this to work it needs access to 'libcanberra'. Thus, for
> >> sound themes to work, 'libcanberra' should also be an implicit input
> >> of the build system.
> >>
> >> You may be using a desktop where no sound theme is used/configured
> >> and therefore not be seeing any message about this. But, if you use a
> >> desktop with a sound theme, e.g. GNOME, you will see the following
> >> messages:
> >> Gtk-Message: Failed to load module "canberra-gtk-module"
> >> This is taken care by setting
> >>
> >> GTK_PATH=/gnu/store/...-libcanberra-0.30/lib/gtk-3.0/modules
> >>
> >
> > ... I was at this very moment poised to ask about this very issue here, for, in
> the case of a fresh guix 0.8.3 I was witnessing:
> >
> > After `guix package --install emacs`, I find:
> >
> >         $ emacs
> >         (process:3941): Gtk-WARNING **: Locale not supported by C library.
> >                 Using the fallback 'C' locale.
> >         Gtk-Message: Failed to load module "canberra-gtk-module"
> >         Gtk-Message: Failed to load module "pk-gtk-module"
> >
> > The installed emacs v 24.5 does still start, and looks pretty snappy (despite,
> alas, being build without svg support).
> >
> > But, let me try and take your advice:
> >
> >         $ guix package -i libcanberra
> >         $ export GTK_PATH=/gnu/store/*-libcanberra*/lib/gtk-3.0/modules
> >         $ echo $GTK_PATH
> >         /gnu/store/x06vfgf5fn09yr9crqlg22rwc301jnhp-libcanberra-
> 0.30/lib/gtk-3.0/modules
> >         $ ls $GTK_PATH
> >         libcanberra-gtk3-module.la  libcanberra-gtk3-module.so
> > libcanberra-gtk-module.so
> >
> > But, upon starting emacs again, alas, I still get the same Gtk warnings and
> messages.
> >
> > Am I not following your advice, or otherwise mis-understanding it?
> 
> I had a typo, sorry: the path should stop at one level above the modules:
> 
> $GTK_PATH=/gnu/store/nlm81g8hgsw7d01la14zjycjcgamn4qp-libcanberra-
> 0.30/lib/gtk-3.0
> emacs

Thanks, but, I should have reported in the first place that I (guessing) also tried GTK_PATH without the final /modules directory as you suggest and got the same message.

I also did not report the many other errors encountered during emacs startup, including

(emacs-24-5:8483): Gtk-WARNING **: Could not find the icon 'document-new'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
	http://icon-theme.freedesktop.org/releases

and others of the flavor

     (emacs-24-5:8483): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
      (emacs-24-5:8483): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
     (emacs-24-5:8483): Gdk-CRITICAL **: gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
      (emacs-24-5:8483): Gtk-WARNING **: Error loading theme icon 'document-new' for stock: Icon 'document-new' not present in theme gnome

Any advice from you or other lurkers much appreciated...


> 
> GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings
> will not be saved or shared with other applications.
> 
> The remaining above message is because of the missing 'dconf' (I guess we
> should add it). I'm not getting the message about "pk-gtk-module".
> I'm not sure what it refers to.

Apparently something called packageKit per https://bugzilla.redhat.com/show_bug.cgi?id=643129

> 
> HTH,

Thx, a bit,

!Malcolm

> Fede

Re: How to handle required plugins and dbus services for GNOME Programs?

[Federico Beffa]

On Fri, Jul 24, 2015 at 8:41 PM, Cook, Malcolm <MEC@stowers.org> wrote:
>> On Thu, Jul 23, 2015 at 8:16 PM, Cook, Malcolm <MEC@stowers.org> wrote:
>> > Hi,
>> >
>> > What fortune...
>> >
>> >> IMO, given that every GLib based program needs it, the right thing to
>> >> do is to make it an implicit input of 'glib-or-gtk-build-system'.
>> >>
>> >> In a similar way, every GLib based program/library makes use of sound
>> >> themes. For this to work it needs access to 'libcanberra'. Thus, for
>> >> sound themes to work, 'libcanberra' should also be an implicit input
>> >> of the build system.
>> >>
>> >> You may be using a desktop where no sound theme is used/configured
>> >> and therefore not be seeing any message about this. But, if you use a
>> >> desktop with a sound theme, e.g. GNOME, you will see the following
>> >> messages:
>> >> Gtk-Message: Failed to load module "canberra-gtk-module"
>> >> This is taken care by setting
>> >>
>> >> GTK_PATH=/gnu/store/...-libcanberra-0.30/lib/gtk-3.0/modules
>> >>
>> >
>> > ... I was at this very moment poised to ask about this very issue here, for, in
>> the case of a fresh guix 0.8.3 I was witnessing:
>> >
>> > After `guix package --install emacs`, I find:
>> >
>> >         $ emacs
>> >         (process:3941): Gtk-WARNING **: Locale not supported by C library.
>> >                 Using the fallback 'C' locale.
>> >         Gtk-Message: Failed to load module "canberra-gtk-module"
>> >         Gtk-Message: Failed to load module "pk-gtk-module"
>> >
>> > The installed emacs v 24.5 does still start, and looks pretty snappy (despite,
>> alas, being build without svg support).
>> >
>> > But, let me try and take your advice:
>> >
>> >         $ guix package -i libcanberra
>> >         $ export GTK_PATH=/gnu/store/*-libcanberra*/lib/gtk-3.0/modules
>> >         $ echo $GTK_PATH
>> >         /gnu/store/x06vfgf5fn09yr9crqlg22rwc301jnhp-libcanberra-
>> 0.30/lib/gtk-3.0/modules
>> >         $ ls $GTK_PATH
>> >         libcanberra-gtk3-module.la  libcanberra-gtk3-module.so
>> > libcanberra-gtk-module.so
>> >
>> > But, upon starting emacs again, alas, I still get the same Gtk warnings and
>> messages.
>> >
>> > Am I not following your advice, or otherwise mis-understanding it?
>>
>> I had a typo, sorry: the path should stop at one level above the modules:
>>
>> $GTK_PATH=/gnu/store/nlm81g8hgsw7d01la14zjycjcgamn4qp-libcanberra-
>> 0.30/lib/gtk-3.0
>> emacs
>
> Thanks, but, I should have reported in the first place that I (guessing) also tried GTK_PATH without the final /modules directory as you suggest and got the same message.
>
> I also did not report the many other errors encountered during emacs startup, including
>
> (emacs-24-5:8483): Gtk-WARNING **: Could not find the icon 'document-new'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
> You can get a copy from:
>         http://icon-theme.freedesktop.org/releases
>
> and others of the flavor
>
>      (emacs-24-5:8483): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
>       (emacs-24-5:8483): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
>      (emacs-24-5:8483): Gdk-CRITICAL **: gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
>       (emacs-24-5:8483): Gtk-WARNING **: Error loading theme icon 'document-new' for stock: Icon 'document-new' not present in theme gnome
>
> Any advice from you or other lurkers much appreciated...

The behavior is then different from what I see on my machine. I can't
help further then.

Sorry,
Fede