I found several threads in the forums regarding this issue http://forums.gentoo.org/viewtopic.php?t=116636 is one. When I go to the command line I can run /usr/sbin/bonobo-activation-sysconf --config-file-path and the output is: ------------------- configuration file is: /var/tmp/portage/libbonobo-2.4.3/image//etc/bonobo-activation/bonobo-activation-config.xml ------------------- because bonobo-activation isn't working properly, panel, gnome-settings daemon and nautilus fail to start at login leaving Gnome in a pretty much useless state. The system is close to a fresh install - base + xfree86 + gnome. I've tried emerging versions of libbonobo from 2.4.0 to 2.4.3 and all have the same problem. Reproducible: Always Steps to Reproduce: 1. log in to gnome 2. 3. Actual Results: everything but the window manager fails to start leaving gnome in a useless state with no way to launch applications etc. Expected Results: it's expected to work - looks like the build hard coded some bad paths in the libbonobo package. This is an alpha DS10 466Mhz with 1G of ram The install is roughly base + xfree86 + gnome (and a couple of other little things) I assume the others that have posted about the problem in the forums were on x86 based systems. I can't find any way to work around the bug.
Do you have a /etc/bonobo-activation/bonobo-activation-config.xml file? That's where my system looks when I run "/usr/sbin/bonobo-activation-sysconf --config-file-path"
yes -- that file exists. But the binary is looking in the wrong spot and it seems to have been compiled in wrong.
I can't reproduce on x86 with libbonobo-2.4.3. Looking through the build. The "--config-file-path" looks up the variable that is set in the configure stage with: Makefile.in: -DSERVER_CONFDIR=\"$(sysconfdir)\" This is set in the libbonobu-2.4.3 ebuild by using econf for the configure stage, which sets sysconfdir to /etc (it's default anyway). That's all background however. I'm most curious if you could do the following. o) open up /usr/portage/gnome-base/libbonobo/libbonobo-2.4.3.ebuild in a text editor like vim o) look for the following, # comment out next bump (#31708) #MAKEOPTS="${MAKEOPTS} -j1" o) uncomment the MAKEOPTS line so it looks like # comment out next bump (#31708) MAKEOPTS="${MAKEOPTS} -j1" o) try and emerge libbonobo again. If the problem is fixed by that, then we'll have to set libbonobo back to being no-parrallel-buildable. Thanks very much, please report back.
Same problem. I grabbed a tar file of just the Makefiles while it was building if you think that would help anybody. Where do the settings for the configure stage come from? Is it possible that a file is somehow corrupt in my setup that needs fixing. I haven't changed anything, but based on those posts in the message boards, I'm also not the only one with this problem. -Charlie
can you attach the Makefile from the utils/ dir ?
Created attachment 24391 [details] utils/Makefile as requested Here is the Makefile from the utils directory as requested.
If it's helpful, I'm having the exact same problem and here's some info on my setup: Gentoo 1.4, brand new stage 3 install, immediately followed by an "emerge -u system". First I emerged xfree86, configred it, and it worked. Then I emerged gnome, and it does not work. Every time any gnome program tries to start, I get error messages about an inability to register with bonobo activation. So I can't use gnome. I've tried libbonobo 2.4.0, 2.4.2, and 2.4.3, with the same restuls each time. Like the original poster, running "bonobo-activation-sysconf --config-file-path" always returns the bogus path "/var/tmp/portage/libbonobo-2.4.3/image//etc/bonobo-activation/bonobo-activation-config.xml" and complains abou being unable to find the config file. I even tried making a symlink from the bogus path to the correct one. bonobo-activation-* stopped complaining about being unable to find the config file, but gnome programs still would not run; they had the same problem as before.
Oh yeah one more thing -- the error message I get when nautilus tries to start says it is "error code 3". Also, this may be relevant: When emerging gnome, it died on the package XML-Parser-2.31-r1. It complained about the date on a file in my perl installation being wrong. I looked at the file and the date was Febuary 9. This was on Febuary 8 when the problem happened. I touched the file with the current date, and tried to emerge XML-Parser-2.31-r1 again. It complained about yet another one having an invalid date. I looked and this other file had a date that was one day in the future. I touched it, and then XML-Parser built just fine. I don't know how these files got dates one day in the future. The date was never wrong on my system, as far as I know. (If it was, it somehow mysteriously fixed itself, because I didn't have to correct the date later). I don't know if that's relevant, but it is the only thing in the gnome emerge that was not complete smooth sailing.
add a line reading 'USE_DESTDIR="1"' to the libbonobo ebuild and rebuild, see if that helps ?
That worked! Only some applications that were compiled with the bogus version of libbonbo need to recompiled now... I tried to start nautilus, and instead of the usual problem with bonobo-activation, it segfaulted. So I re-emerged it, and it works now. So far I've had to re-emerge nautilus, libglade, and epihphany. I guess anything that crashes in the next few days here I'll assume needs to be re-emerged, or needs to have a library re-emerged. If it turns out to be a real problem I'll just look in the emerge log file and re-emerge everything that was installed as a prereq for gnome and came after libbonobo originally did.
hmmm... that seemed to fix it for me as well
I experienced the exact same problem using a mostly clean system (x86 - Pentium-M), working from a 1.4 LiveCD with an up-to-date portage tree. The fix from comment 9 worked, though I then experienced the same segfaults as mentioned in comment 10.
Sort of weird that it introduces crashes.. can't really think of a reason why.
I had the same problem and the USE_DESTDIR did it for me as well.. Is there any way of re-emerging the whole gnome dependecy tree automatically? I already recompiled nautilus and ephy but I get some weird errors in Gnome now like missing color choosers in the "Background preferences" window and missing file locator elements in various programs. I realize this must be bonobo related, but i have no clue about which packages to re-emerge.
I had the same problem, and would like to confirm that USE_DESTDIR fixed the issue. I had decided to 'emerge -U gnome', after which this happened: Typing 'startx' cause X Windows to start, display my solid black background with the X cursor, the quit immediately. Changing my SESSION from 'gnome' to 'kde-3.1.5' allowed me to start X Windows successfully, and I was then able to figure out that my Gnome install was borked. After using the USE_DESTDIR fix and re-emerging libbonobo, I believe Gnome started to boot into the window manager and I could start applications, but none of my panels worked correctly (including the task bar). Re-emerging Orbit and Orbit2 corrected this. For good measure, I re-emerged most of the Gnome packages and everything seems to be working fine now.
@ comment #14 : no, apart maybe from using 'emerge -e', but that rebuilds a whole lot more. You could check gnome meta (gnome-base/gnome) for most relevant deps. In conclusion, I'm not sure why this only affects a few people and not all of them. It makes me suspect it is not libbonobo alone, but some combination with the Gentoo tools setup.
although this seems to be a one time ill-reproducable case, i added USE_DESTDIR to the libbonobo ebuild
