Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 281769 - gnome-panel-2.26.2, gnome-panel-2.26.3 cannot load clock applet
Summary: gnome-panel-2.26.2, gnome-panel-2.26.3 cannot load clock applet
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
: 285444 (view as bug list)
Depends on:
Blocks: gnome2.26
  Show dependency tree
 
Reported: 2009-08-17 14:27 UTC by Christopher Friedt
Modified: 2010-01-31 22:38 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Friedt 2009-08-17 14:27:42 UTC
I had the clock applet working fine for months, and now I am unable to load the clock applet at all. Now, every time that I try to load the clock applet, I get an error with the following message.

The panel encountered a problem while loading "OAFIID:GNOME_ClockApplet". Do you want to delete the applet from your configuration?



Reproducible: Always

Steps to Reproduce:
1.try to add the clock applet to gnome-panel
2.
3.

Actual Results:  
error

Expected Results:  
clock
Comment 1 Christopher Friedt 2009-08-17 14:35:55 UTC
I tried the following, and received the following error. I doubt thhis is a bug in gnome-panel. It just seems like I'm missing a shared library.

gnome-panel --replace --sm-disable

** (gnome-panel:6009): WARNING **: panel-applet-frame.c:1273: failed to load applet OAFIID:GNOME_ClockApplet:
System exception: IDL:Bonobo/GeneralError:1.0 : g_module_open of `/usr/lib/gnome-panel/libclock-applet.so' failed with `libplds4.so.7: cannot open shared object file: No such file or directory'

sketchy workaround:

for i in libnspr4 libplc4 libplds4; do
cd /usr/lib/nspr
ln -sf ${i}.so.{8,7}
cd ..
ln -sf nspr/${i}.so.7 .
done
Comment 2 Rémi Cardona (RETIRED) gentoo-dev 2009-08-17 15:27:38 UTC
Remove your shoddy symlinks and use revdep-rebuild to fix the packages that were broken with the last xulrunner update.

Thanks
Comment 3 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-08-17 22:23:17 UTC
that kind of problem is not supposed to happen since nspr/nss ebuilds should warn you about doing revdep-rebuild and/or preserving in-use libraries until they are not used anymore. You may re-assign or fill another bug at nspr/nss maintainer if you wish.
Comment 4 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-09-18 14:28:15 UTC
*** Bug 285444 has been marked as a duplicate of this bug. ***
Comment 5 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-09-23 11:22:06 UTC
*** Bug 285444 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Santos 2010-01-31 22:38:00 UTC
(In reply to comment #2)
> Remove your shoddy symlinks and use revdep-rebuild to fix the packages that
> were broken with the last xulrunner update.
> 
> Thanks
> 

Actually, your demeaning reply isn't helpful because, in fact, running revdep-rebuild does not solve the problem -- at least not the ACCEPT_KEYWORD="amd64" version of revdep-rebuild.  It looks like another work-around is to add
export LD_LIBRARY_PATH=/usr/lib64/nss 
to one's .profile.  It's less ugly, but it's still a nasty hack.