(In reply to comment #0)
> http://live.gnome.org/LibgnomeMustDie
> This library will be removed for GNOME 3.
> 
> 
> $:andre\> grep -r "<libgnome" .
> ./src/server.c:                       #include <libgnome/gnome-init.h>
> ./servers/exchange/lib/test-utils.c:  #include <libgnome/gnome-util.h>
> 
> ./configure.in: m4_define([libgnome_minimum_version], [2.0.0]) # XXX Just a
> Guess
> ./configure.in: libgnome-2.0 >= libgnome_minimum_version
> ./configure.in: E_FACTORY_DEPS="libgnome-2.0 $mozilla_nspr"

What's the correct replacement for gnome_program_init with all the features it offers?

> I'm also surprised about this check:
> ./configure.in: AC_MSG_CHECKING(for libgnomeui server directory)
> ./configure.in: GNOMEUI_SERVERDIR="`$PKG_CONFIG --variable=libgnomeui_serverdir
> libgnomeui-2.0`"
> e-d-s does not have a single include for libgnomeui but maybe I simply don't
> get it.

Two lines below:
AC_DEFINE_UNQUOTED(GNOMEUI_SERVERDIR, "$GNOMEUI_SERVERDIR", [Path where we can find gnome_segv2])

(In reply to comment #1)
> What's the correct replacement for gnome_program_init with all the features it
> offers?

See http://live.gnome.org/LibgnomeMustDie ?
If something's missing, add it. Or ask in public.

> AC_DEFINE_UNQUOTED(GNOMEUI_SERVERDIR, "$GNOMEUI_SERVERDIR", [Path where we can
> find gnome_segv2])

Ah. Darn. Is that gnome_segv2 stuff functional at all?!

If I could understand it from the page, I wouldn't ask, really. I also considered this as a public place.

It seems to me that the gnome_segv2 doesn't work, as on my F10 box the eds is able to silently die, no bug-buddy, nothing, whereas evolution usually shows back trace and everything, when saying its bye-bye on something unexpected by devs.

(In reply to comment #2)
> What's the correct replacement for gnome_program_init with all the features it
> offers?

gtk_init() or gtk_init_with_args()

> Ah. Darn. Is that gnome_segv2 stuff functional at all?!

No.  See bug #541111.

(In reply to comment #4)
> gtk_init() or gtk_init_with_args()

Willing to add this to the wikipage?

Done.

Created attachment 133652 [details] [review]
proposed eds patch

for evolution-data-server;

not as that big changes, but I'm not sure, thus rather asking a review.

Matt, thanks for the pointers. One think I do not understand is that it requires gtk+ now, which is kinda strange for the server itself, as that runs in the background. But it works, as far as i can tell. The test_... file seems to not be used.

With respect to bug-buddy, it's not shown when evolution itself starts eds, but when I run eds on the console, then bug-buddy catches it, though claims it doesn't know eds, thus offers only save of the report. We can try to solve it within Matt's above bug, though this change solves it anyway. I'm not sure what to do next.

Yeah, the server should not be linking to GTK+.  I think you can just drop the gtk_init().  bonobo_init_full() will process the command-line arguments.

I think Bug Buddy doesn't know about E-D-S because there's no .desktop file for it.  I guess we could write one and set Hidden=true so it doesn't show up in the Applications menu.  Not sure if that's the right move.

Thing is, libgnomebreakpad.so is a GTK+ module, so Bug Buddy might just be entirely out of reach of the E-D-S server now.

Marking the patch as needs work, but I think you just need to drop the GTK+ linkage in the server.

Just to be official Fer just updated http://live.gnome.org/LibgnomeMustDie :
"gnome_segv program replaced by the libgnomebreakpad.so GTK_MODULE included in bug-buddy."

Bad. It seems the server should depend on gtk+, as it depended on libgnomeui, because otherwise no luck with bug-buddy even when run eds from the console. It seems the bug-buddy is very tight to gtk+. But, apart of this, the server cannot be run out of the X, which is not what we want, as I understand it.

I'm a bit lost (again). Does this really mean that no bug-buddy for eds?

The libgnomebreakpad.so is a GTK+ module, meaning that it will be loaded every time gtk_init() (or g_option_context_parse(), if you added the GTK+ GOptionGroup to the context) is called.
That module requires X and some GDK functions to release X locks that might be there and moreover plain GLib does not offer a way to load modules like GTK+ does.

There's a way around it: you can copy-paste the relevant signal handler code from bug-buddy/gnome-breakpad/gnome-breakpad.cc, remove the GTK+ (and the google-breakpad) parts and ship it within the server. That piece of code has no other external dependencies and if you drop the google-breakpad/GTK+/init pieces, it shouldn't be much more than 200 lines of code.

I'm not sure showing a Bug Buddy window for a backend process crashing is the right thing to do anyway.  The real question is how to make E-D-S clients better detect and handle the situation.  Obviously some thought was given to this in the past because the hooks are there, but it's either bit rotted or never worked very well to begin with.

CC'ing ross since this is more his territory.

(In reply to comment #12)
> I'm not sure showing a Bug Buddy window for a backend process crashing is the
> right thing to do anyway.  The real question is how to make E-D-S clients
> better detect and handle the situation.

Yeah, I definitely agree with you.

won't eds depend on gtk anyway by fixing bug 581288 (libglade -> gtkbuilder)?

From my point of view, just commit patch which will not use gtk+ in server.c and done. No idea how better one can handle sigsegv and not depends on gtk+ stuff (neither copying 200 lines of code from somewhere). So this way and done.

The other parts of eds will still require gtk, as the libedataserverui.

libedataserverui is the -only- part that should require GTK+.

any objections against comment #15?

Personally I have no problem with seeing the entire failed attempt at crash detection removed from evolution-data-server.  eds-dbus removes it too. :)

(In reply to comment #17)
> any objections against comment #15?

No objections.  I agree with Ross, just ditch the crash detection.

Go ahead and commit the rest of the patch.

Created commit 7f5d404 in master.

Just removed all related parts from server.c file.

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

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