Description of problem: After having updated from FC6 to F7, I'm still using the GNOME desktop. Sometimes having problems to add an applet to the gnome-panel: If selecting the applet from the applet selection box and clicking on "Add", after some seconds getting an error prompt containing: The panel encountered a problem while loading "OAFIID:GNOME_MiniCommanderApplet".Do you want to delete the applet from your configuration? The same happens sometimes directly when logging in via gdm (it seems the gnome-panel containing applets cannot be rebuilt). Version-Release number of selected component (if applicable): gnome-panel-2.18.3-1.fc7 How reproducible: Very often, not always. Steps to Reproduce: 1. Login into the gnome desktop 2.Tray to add some applet to the panel 3. Actual results: Rejected with the message: The panel encountered a problem while loading "OAFIID:GNOME_MiniCommanderApplet".Do you want to delete the applet from your configuration? Expected results: Applet is added Additional info: 1. Never had such problems in FC6 2. Most times, the problem occurs when logging in via NX/2x client
The behaviour does not depend from the applet. It likewise appears for example with the clock applet.
I found out that rm -rf /tmp/orbit-<user> helps (until the next time the problem occurs).
I had the same issue and removing /tmp/orbit-<user> fixed one problem but created another. I had to remove anything related to the <user> in the /tmp directory. I needed to rm -rf orbit-<user> rm -rf virtual-<user>* rm -rf ksocket-<user> rm -f mapping-<user> rm -rf gconfd-<user> All the problems occurred after using switching user. I am not sure which one was the final fixer but I deleted all files in the /tmp related to the user.
Similar issue, applied fix above in Comment #3, and it worked. Difference was in my case it was 1. ALL applets threw up the error. 2. It only happened on an XWindows connection; the console did not have the problem. If anyone wants the contents of the /tmp files for debugging, I've saved them.
bug # 200232 may be related (should be marked duplicate of this?)
*** Bug 200232 has been marked as a duplicate of this bug. ***
This happens periodically on all of my F7 boxes. I think it results from bonobo-activation-server not exiting on session logout. Killing that process fixes it, but I haven't yet found the proper place to call a script and kill it. This problem happens on my wife's account often, and it drives her nuts because the error dialog is almost meaningless, even to me.
After monkeying with this a while back, I was able to make a few observations regarding this bug, which others might find helpful: 0) This bug can consistently be reproduced by deleting the /tmp/orbit-$USER/bonobo-activation-server-ior state file, logging in as that $USER on any virtual terminal / X display number, logging out, then logging in as that same $USER on SOME OTHER virtual terminal / X display number. This state file seems to contain a "stale" ORB reference when sessions occur on differing virtual terminals. 1) Once this state file is deleted and subsequently recreated the next time the user logs in, they will not get these error messages again, so long as they continue to use the same virtual terminal for their gnome sessions each time they log in. 2) The OAFIID error messages only occur each time a user logs into their gnome desktop via an X display/virtual terminal other than the first one they logged into in which the bonobo-activation-server state file was initially created. For instance, if Jane logs into gnome on the first/default X session on display :0 (located at ctrl+alt+f7) for the first time, logs out, then later starts a new login session and logs into her gnome desktop on display :1 (located at ctrl+alt+f9 on my box) because Joe is already logged in on display :0, she will get the error messages for each gnome panel applet that is trying to load. The applets cannot load because the bonobo-activation-server-ior state file is telling them that they need to work with an ORB process associated with an X session using the virtual terminal / display number specified by the state file at the time of its creation, i.e. at the first log in where the bonobo-activation-server-ior did not already exist. More simply stated, in this example the ORB state file (or the bonobo-activation-server process itself?) is still referencing display :0, while the user is on display :1, hence the applets spit out the error messages. 3) Therefore, if you delete /tmp/orbit-$USER/bonobo-activation-server-ior each time after logging out, the $USER in question will not get these error messages the next time they log into their desktop, regardless of what virtual terminal they log in to. Any workarounds should be derived from these facts, until such time as this bug is Fixed. Personally, I have since installed fedora 8 (backup, wipe partition, then fresh install), where multiple user desktops and login sessions seem to be handled much more smoothly (including audio - Yay, ConsoleKit!), and this bug does not seem to be present.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
CAnnot be reproduced in F9!