[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#416871: ITP: debreaper -- bring peace to the poor souls of crashed applications



On Sat, Mar 31, 2007, Josselin Mouette wrote:
> >  What's the advantage over bug-buddy?  Can't bug-buddy be extended to
> >  implement similar functionality?
> I examined both possibilities and it turned out too complicated without
> re-using the reportbug modules. Hence the choice of python.
> 
> The advantage over bug-buddy and reportbug is that it uses the email
> configuration that was already setup by the user, whether it is based on
> evolution, balsa or icedove. It does not rely on a working MTA or a
> specific MUA. 

 Sounds like some gnome-reportbug or gnome-reportbug-ng; could you
 integrate with one these two and provide the added functionality in
 some form of plugin?  Either the GNOME MUA detection and/or the SEGV
 handling capabilities would make nice additions to the reportbug*
 packages.

> >  Would it make sense to integrate a kernel level SEGV handler instead of
> >  going via libgnomeui?  I was under the impression that this is what the
> >  Ubuntu folks achieved [1]; this seems more generic as it would cover
> >  other DE (Xfce, KDE) but also other application crashes such as web
> >  server, databases etc.
> Debreaper is not the signal handler itself. It is simple enough to be
> called by any signal handler, be it in the kernel, in the glibc or in
> the UI libraries. It should be possible to use it in any environment, as
> the UI is interchangeable (currently there's a text UI and a GTK+ one).
> The only thing that's bound to GNOME is the way to detect the MUA, but
> it could be changed as well.

 Ok; if you think it's a generic crash reporting tool, I think it makes
 sense to keep it separate from pkg-gnome, perhaps working within one of
 the reportbug SCMs or starting a new one; we can then take the decision
 to use it in GNOME instead of bug-buddy when that makes sense.

-- 
Loïc Minier



Reply to: