Bug 3536

I think you're getting this for any drak tool or any gtk+ app

Priority: Normal => Low

I can confirm what Thierry says.
It can be fixed by installing lib(64)canberra-gtk0.
There is a missing requires somewhere ...

CC: (none) => malo

Still valid.

Source RPM: (none) => gtk+2.0

assigning to maintainer

Assignee: bugsquad => olav
CC: (none) => marja11

I really dislike canberra-gtk. I guess a suggests on gtk+2.0, but as said: urgh.

*** Bug 5115 has been marked as a duplicate of this bug. ***

CC: (none) => mnaud.free

Stil valid.

Standard installation, without Gnome+KDE. Then in WM after opening for example emacs I can read this error.

Gtk-Message: Failed to load module "canberra-gtk-module"

Olav, can you add the suggests? 
Otherwise, is there any way to remove that warning?

Thinking about it more, I think it would be in the wrong place. I thought it was some theme, but this is the freedesktop.org sound module IIRC.

Could you run the following:
  rpm -qa | grep canberra

Something is suggesting gtk+2.0 to load canberra, but not pulling in the module. It is a bit odd.

/etc/X11/xinit.d/libcanberra-gtk-module.sh adds an environment variable to have it loaded. By default gtk+2.0 shouldn't try to load this.

$ rpm -qa | grep canberra
canberra-common-0.28-7.mga2
canberra-gtk-0.28-7.mga2
libcanberra0-0.28-7.mga2
libcanberra-devel-0.28-7.mga2
libcanberra-gtk3_0-0.28-7.mga2

Yes, something is odd, especially if canberra is about sound ...

$ rpm -qa|grep canberra
lib64canberra0-0.28-7.mga2
canberra-gtk-0.28-7.mga2
lib64canberra-gtk0-0.28-7.mga2
canberra-common-0.28-7.mga2
lib64canberra-gtk3_0-0.28-7.mga2

I've got to install lib64canberra-gtk0-0.28-7.mga2 (IIRC) and it fixes the warning.

So something is installing canberra somehow :P

I should find out what and solve it there, or add Suggests/Requires to canberra-gtk I guess..

Have a look at libgnome2_0 ...

> urpmq -a --whatrequires canberra
aisleriot canberra-common canberra-gtk cheese drwright empathy evolution gdm gerbv gnect gnibbles gnobots2 gnome-color-manager gnome-control-center gnome-phone-manager gnome-screenshot gnome-settings-daemon gnome-shell gok iagno kdebase4-runtime libbrasero-burn3_1 libbrasero-devel libcanberra-devel libcanberra-gtk-devel libcanberra-gtk0 libcanberra-gtk3_0 libcanberra0 libcheese-gtk-devel libcheese-gtk21 libgnome2-devel libgnome2_0 libmutter-private-devel libmutter-private0 metacity notification-daemon pavucontrol pcb quadrapassel sound-juicer xchat-gnome-soundnotification

among them, I have only libgnome2_0 installed ...

*** Bug 5403 has been marked as a duplicate of this bug. ***

CC: (none) => fri

The small demo from the Gtk3 manpage (converted back to Gtk2) fails with the message quoted in the bug description (Failed to load module "canberra-gtk-module), only runs if libcanberra-gtk0 is manually installed in addition to what has been installed at system generation - a nice example to put this problem into evidence.

  #!/usr/bin/perl -w
  use Gtk2 '-init';
  my $window = Gtk2::Window->new ('toplevel');
  my $button = Gtk2::Button->new ('Quit');
  $button->signal_connect (clicked => sub { Gtk2::main_quit });
  $window->add ($button);
  $window->show_all;
  Gtk2->main;

But weird, I have a quite complex perl-Gtk application (which - necessarily - contains all the ingredients used in the small demo) and that runs perfectly even when the canberra module is not installed on my system: there are facettes of this problem which go beyond a missing require/suggest.

(And yes, I have several of the packages quoted in comment 13 installed on my system, but nevertheless do not get libcanberra-gtk0 installed simply as a dependency)

CC: (none) => juergen.harms

Still valid

I hit this bug when checking the livecd for the final release, simply by launching Gimp - maybe that helps to find the broken link in the chain of requires. And again, the problem is solved (on my i586 system) by simply installing libcanberra-gtk0.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Still valid in Mageia 2

Isn't there a simple solution: make libcanberra-gtk0 (i586) and lib64canberra-gtk0 (x86_64) both provide the resource canberra-gtk-module?

Juergen

Still valid in Mageia 3 alpha 1. Can this be fixed? please!!!

Status: NEW => ASSIGNED

Error: Gtk-Message **: Failed to load module "canberra-gtk-module"
Solution:
32bit:
# urpmi libcanberra-gtk0
64bit:
# urpmi lib64canberra-gtk0

CC: (none) => loginov_alex

Yes, most people who see this problem apply this as a workaround.

But that does not solve the fundamental issue: installing modules required by " the infrastructure" should be handled by "the infrastructure" itself - there are naive users around who do not know about urpmi.

The beard of the fundamental problem is happily growing and growing, there will be a birthday of the initial bugzilla report soon (-

OOPS we missed that birthday party!
But rejoice, we have chance next year, as it is stil valid ;)

Just spotted in .xsession.errors on up to date 3RC:

Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message **: Failed to load module "canberra-gtk-module" at /usr/lib/libDrakX/mygtk2.pm line 20.

I apply that usual workaround now...

Whiteboard: MGA2TOO 3alpha1 => MGA2TOO 3RC

I see target was set to mga3, but i do not think it should be a release blocker as we will miss the party...

Hardware: x86_64 => All

Please add libcanberra-gtk0/lib64canberra-gtk0 in distro.

Still valid in an updated Mageia 3. Yes, the second birthday has come and gone, and this littly monster still lives. Is it also there in Mangeia 4?

CC: (none) => unruh

Yes, and it is a really little monster. 
Issue is to see were is the best place to add a require/suggest I guess.

Hi

problem still valid under mga4 and cauldron.

Under mga4, I already had :
canberra-common-0.30-4.mga4
canberra-gtk-0.30-4.mga4
libcanberra-gtk3_0-0.30-4.mga4
libcanberra0-0.30-4.mga4

After manually installing libcanberra-gtk0, the message "Failed to load module "canberra-gtk-module"" is now gone for good.

Should be the same under cauldron I guess

CC: (none) => npomarede

This is pretty harmless. If you install the GTK+3.x canberra module, it doesn't automatically install the GTK+2.x version. I've added Recommends in the latest package. These are only recommends though, the installer doesn't look at them.

A requires would result in always needing GTK+2.x as well as GTK+3.x. Which maybe makes sense atm, but that should not be the case forever.

The string "Failed to load module 'canberra-gtk-module'" appears in 1230 pages within the site mageia.org and its sub-sites (i.e. the sub-domains), including on 79 pages of bugs.mageia.org. On the web, according to Google, there are 9880 pages including both this string and the word "Mageia". It means that this bug wastes thousand of people's time, leading them to think it is the cause of the unrelated problem they have. Then someone else has to waste his/her time to explain that it is not the case. So I increase the priority to "high".

Moreover, since GnuCash in Mageia 4 is very buggy, I decided to compile the last one. Then, if I try to launch it, I get:

$ ./gnucash
(process:4483): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: No such file or directory
Gtk-Message: Failed to load module "canberra-gtk-module"
**
gnc.gui:ERROR:../../../src/gnome-utils/gnc-main-window.c:3604:gnc_main_window_setup_window: assertion failed: (filename)
Aborted 

These messages are quite unclear to me, but doesn't it mean that, because of this bug, my built GnuCash doesn't work? If yes, this bug is not just an "enhancement". And what is the workaround?

Priority: Low => Normal

(In reply to Henri de Solages from comment #30)
> it is the cause of the unrelated problem they have. Then someone else has to
> waste his/her time to explain that it is not the case. So I increase the
> priority to "high".

Priority is up to the assignee. I consider this low priority. For Mageia 5 the Recommends should avoid this message. I'm totally ok with someone figuring out a good solution and doing the work. Last bit would be to have "rpmsrate-raw" ensure both rpm packages are on the installation media. Because package can either contain "lib" or "lib64" I'm not sure how to do that.

> $ ./gnucash
[..]
> gnc.gui:ERROR:../../../src/gnome-utils/gnc-main-window.c:3604:
> gnc_main_window_setup_window: assertion failed: (filename)
> Aborted 
> 
> These messages are quite unclear to me, but doesn't it mean that, because of
> this bug, my built GnuCash doesn't work? If yes, this bug is not just an
> "enhancement". And what is the workaround?

No, just file a new bug if it happens with the provided gnucash from the distribution. If you compile yourself, ask gnucash developers.

Priority: High => Low

Latest rpm has functionality to solve this. Targeting Mageia 6.

Target Milestone: Mageia 4 => Mageia 6
Severity: enhancement => normal

Olav, you did target Mageia 6 one year ago for this bug report. Is it still true?

The dependency is not possible with current urpmi logic. Moving to Mageia 7.

Target Milestone: Mageia 6 => Mageia 7
CC: (none) => olav

*** Bug 19607 has been marked as a duplicate of this bug. ***

CC: (none) => hamnisdude

Still present with clean MGA6 install, FWIW. 
Installation of one of the lib64canberra packages resolves it.

CC: (none) => andy_jefferson

Olav, if we don't want to require lib64canberra-gtk0 to silence this pointless warning, maybe we could patch gtk+2.0 to silence it ourselves? This warning is pointless, there is no loss of functionality in applications which trigger this warning.

I added stuff like below to the spec. This for the gtk2 and the gtk3 packages.

# ovitters to avoid complaints from 32 bits programs on a 64 arch recommend the
#          32bit library on a 64 bit arch
#          the lua macro changes lib64 into lib
%if 0%{?__isa_bits} == 64
Recommends:»····%{lua:txt = string.gsub(rpm.expand("%{libname_gtk}"), "^lib64","lib"); print(txt)}
%endif


I think this should work, hopefully. In case there's no 32 bit version available rpm should ignore it if I read https://rpm.org/user_doc/dependencies.html correctly.

The Recommends change was reverted as people didn't like that solution. Nicolas Pomarède assisted with a proposed patch. Patch was applied to gtk+2.x and gtk+3.0. This stuff should now be ok in Mageia Cauldron.

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED

No that's just a warning and the recommends end in pulling ton of uneeded stuff…

CC: (none) => thierry.vignaud