Abrt - should this be a feature?

[Rahul Sundaram]

Hi

http://fedoraproject.org/wiki/Features/ABRT

It was broken when tested

https://fedoraproject.org/wiki/QA/Test_Days/2009-02-26

Bug Buddy seems to the default still for GNOME. Why is it in the feature
list? FESCo should reconsider this feature.

Rahul

[Kevin Fenzi]

On Sat, 16 May 2009 01:28:01 +0530
Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote:

>  Hi
>  
>  http://fedoraproject.org/wiki/Features/ABRT
>  
>  It was broken when tested
>  
>  https://fedoraproject.org/wiki/QA/Test_Days/2009-02-26
>  
>  Bug Buddy seems to the default still for GNOME. Why is it in the
>  feature list? FESCo should reconsider this feature. 
Sadly, we were going on the "100%" there from the feature owner. ;( 

I think we should move this off to f12. 
I don't know if we can correct all the places it's mentioned in
relation to f11, but we should try. 

>  
>  Rahul
>   
kevin

[Zdenek Prikryl]

Rahul Sundaram wrote:
>  Hi
>  
>  http://fedoraproject.org/wiki/Features/ABRT
>  
>  It was broken when tested
>  
>  https://fedoraproject.org/wiki/QA/Test_Days/2009-02-26 
Yes, the test day explored several bugs (for this purpose the test day was), but
critical bugs are fixed, some of feature requests are implemented. So imho the
current state of abrt is good :-)

>  Bug Buddy seems to the default still for GNOME. Why is it in the
> feature
>  list? FESCo should reconsider this feature. 
In F11 abrt doesn't replace bb, they can be enabled at the same time. Note that
abrt can catch more crashes than bb can (like non-gnome programs, kernel crashes
[kerneloops], ...).

-- 
Zdenek Prikryl <zprikryl(a)redhat.com&gt;

[Rahul Sundaram]

On 05/18/2009 07:53 PM, Zdenek Prikryl wrote:
>  
>  In F11 abrt doesn't replace bb, they can be enabled at the same time. Note that
>  abrt can catch more crashes than bb can (like non-gnome programs, kernel crashes
>  [kerneloops], ...). 
How can they be enabled at the same time? Where is that information
documented?

Rahul

[Jiri Moskovcak]

Rahul Sundaram wrote:
>  On 05/18/2009 07:53 PM, Zdenek Prikryl wrote:
> > In F11 abrt doesn't replace bb, they can be enabled at the same time. Note that
> > abrt can catch more crashes than bb can (like non-gnome programs, kernel crashes
> > [kerneloops], ...).
>  
>  How can they be enabled at the same time? Where is that information
>  documented?
>  
>  Rahul
>   
Because if the crash is handled by bb abrt won't detect it at all. It's 
the same for applications which have their own crash handlers (like pidgin).

Jirka

[Colin Walters]

On Tue, May 19, 2009 at 6:57 AM, Jiri Moskovcak <jmoskovc(a)redhat.com&gt; wrote:
>  Because if the crash is handled by bb abrt won't detect it at all. It's the
>  same for applications which have their own crash handlers (like pidgin). 
We can disable bug-buddy very easily (trivially) if ABRT is ready (is
it?).  An important concern is having a story to tell the GNOME
project for how we're going to be providing them with bug data.  If
ABRT's server side component had say a filtered list of crashes in
GNOME projects, or some automated way for developers to get at that
data that'd be useful.

[Zdenek Prikryl]

Colin Walters wrote:
>  On Tue, May 19, 2009 at 6:57 AM, Jiri Moskovcak
> <jmoskovc(a)redhat.com&gt; wrote:
> > Because if the crash is handled by bb abrt won't detect it at all. It's the
> > same for applications which have their own crash handlers (like pidgin).
>  
>  We can disable bug-buddy very easily (trivially) if ABRT is ready (is
>  it?).  An important concern is having a story to tell the GNOME
>  project for how we're going to be providing them with bug data.  If
>  ABRT's server side component had say a filtered list of crashes in
>  GNOME projects, or some automated way for developers to get at that
>  data that'd be useful.
>   
ABRT can catch all bugs, which bb can. It is ready in this point of view. But
right now there is no way how to filter out gnome or kde stuff and report it to
their bz. if ABRT detect a problem and an user wants to report it, the report
can go either to our bz or it is just logged or whatever (it depends on
configuration).

-- 
Zdenek Prikryl <zprikryl(a)redhat.com&gt;

[Jaroslav Reznik]

----- "Zdenek Prikryl" <zprikryl(a)redhat.com&gt; wrote:

>  Colin Walters wrote:
>  > On Tue, May 19, 2009 at 6:57 AM, Jiri Moskovcak
>  <jmoskovc(a)redhat.com&gt; wrote:
>  >> Because if the crash is handled by bb abrt won't detect it at all.
>  It's the
>  >> same for applications which have their own crash handlers (like
>  pidgin).
>  > 
>  > We can disable bug-buddy very easily (trivially) if ABRT is ready
>  (is
>  > it?).  An important concern is having a story to tell the GNOME
>  > project for how we're going to be providing them with bug data.  If
>  > ABRT's server side component had say a filtered list of crashes in
>  > GNOME projects, or some automated way for developers to get at that
>  > data that'd be useful.
>  > 
>  
>  ABRT can catch all bugs, which bb can. It is ready in this point of
>  view. But
>  right now there is no way how to filter out gnome or kde stuff and
>  report it to
>  their bz. if ABRT detect a problem and an user wants to report it, the
>  report
>  can go either to our bz or it is just logged or whatever (it depends
>  on
>  configuration). 
KDE have brand new Dr. Konqui - in term of features it's quite similar to
what ABRT offers but it's KDE only. Still I think it's better to use it
for KDE crashes. It's part of 4.3 (in rawhide) - so F12 stuff.

But try it - there are still some bugs. Some nice features are starring
usefulness of bug (eg. no backtraces), duplicates etc. with nice easy 
to use GUI for users.

For sysconfigs we have SCTCPBRT now, it's more BRT than your BRT :-)
Actually it could be part of your BRT if you're interested, it's our
internal tool to report sysconfigs bugs.

Jaroslav

>  -- 
>  Zdenek Prikryl <zprikryl(a)redhat.com&gt;
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Colin Walters]

On Thu, May 21, 2009 at 8:47 AM, Zdenek Prikryl <zprikryl(a)redhat.com&gt; wrote:
>  ABRT can catch all bugs, which bb can. It is ready in this point of view. But
>  right now there is no way how to filter out gnome or kde stuff and report it to
>  their bz. if ABRT detect a problem and an user wants to report it, the report
>  can go either to our bz or it is just logged or whatever (it depends on
>  configuration). 
That sounds fine, the filtering/export is something we can add later.

I forgot to mention the most important thing, which is that right now
bug-buddy is limited in usefulness to the GNOME project because of the
-debuginfo split; concretely because stack traces in bugzilla are
essentially just lots of "??".  To pick a random one,
http://bugzilla.gnome.org/show_bug.cgi?id=565819

I'm reading the architecture page now, but I'm not seeing how ABRT
works in this respect.  Does ABRT have a "retracer" server component
like Apport/Breakpad, or does it somehow ensure -debuginfo gets
installed on the client?  Or does it rely on a modified gdb to
just-in-time fetch the data from an ABRT web service?  Something else?

Basically, if ABRT solves this problem we should just replace
bug-buddy without hesitation.  Should we consider this in an F11
update, or move to F12?

[Matej Cepl]

Colin Walters, Thu, 21 May 2009 10:35:39 -0400:
>  I'm reading the architecture page now, but I'm not seeing how
> ABRT works
>  in this respect.  Does ABRT have a "retracer" server component like
>  Apport/Breakpad, or does it somehow ensure -debuginfo gets installed on
>  the client?  Or does it rely on a modified gdb to just-in-time fetch the
>  data from an ABRT web service?  Something else? 
http://fedoraproject.org/wiki/Features/DebuginfoFS it slipped to Fedora 
12 but when it is ready, it should take of debuginfo, right?

Matej

[Jiri Moskovcak]

Matej Cepl wrote:
>  Colin Walters, Thu, 21 May 2009 10:35:39 -0400:
> > I'm reading the architecture page now, but I'm not seeing how ABRT works
> > in this respect.  Does ABRT have a "retracer" server component like
> > Apport/Breakpad, or does it somehow ensure -debuginfo gets installed on
> > the client?  Or does it rely on a modified gdb to just-in-time fetch the
> > data from an ABRT web service?  Something else?
>  
>  http://fedoraproject.org/wiki/Features/DebuginfoFS it slipped to Fedora 
>  12 but when it is ready, it should take of debuginfo, right?
>  
>  Matej
>   
Yes, that is the intention, but for now we simply use debuginfo-install, 
  which really far from optimal solution :-/ If some has better idea how 
to get usefull BT without installing the debuginfo packages it'll be 
more than welcome...

Jirka

[Jan Kratochvil]

On Fri, 22 May 2009 15:10:33 +0200, Jiri Moskovcak wrote:
>  Yes, that is the intention, but for now we simply use
> debuginfo-install,  
>   which really far from optimal solution :-/ If some has better idea how  
>  to get usefull BT without installing the debuginfo packages it'll be  
>  more than welcome... 
Without any debuginfos still as all the rpms are built using gcc option
-fasynchronous-unwind-tables GDB will print the backtraces correctly but only
with numeric addresses (no function names) and without any function parameters
or local variables printed.

In some specific cases IIRC the backtrace will stop at some point.  These
cases should be fixed and there are just missing bugreports/reproducers for
them.  I do not know of such case offhand myself now, if it did happen at all.

One should also write down build-ids (sort of =NVRs) to be able to later
retrace the numerical backtraces on some debuginfo-featuring server.


Regards,
Jan

[Matej Cepl]

Jan Kratochvil, Fri, 22 May 2009 15:28:01 +0200:
>  In some specific cases IIRC the backtrace will stop at some point. 
>  These cases should be fixed and there are just missing
>  bugreports/reproducers for them.  I do not know of such case offhand
>  myself now, if it did happen at all. 
Would it make sense to do some kind of test-day-in-the-middle-of-way 
(meaning testing just for collecting bug reports knowing very well, that 
it isn't ready yet)?

Matěj

[Jan Kratochvil]

On Fri, 22 May 2009 17:44:03 +0200, Matej Cepl wrote:
>  Jan Kratochvil, Fri, 22 May 2009 15:28:01 +0200:
>  > In some specific cases IIRC the backtrace will stop at some point. 
>  > These cases should be fixed and there are just missing
>  > bugreports/reproducers for them.  I do not know of such case offhand
>  > myself now, if it did happen at all.
>  
>  Would it make sense to do some kind of test-day-in-the-middle-of-way 
>  (meaning testing just for collecting bug reports knowing very well, that 
>  it isn't ready yet)? 
Tried x86_64 Firefox backtracing with and without debuginfo and it works OK.
So if there exist such problems they are some exception which can get fixed
and does not need to change the project design.


Regards,
Jan

[Christoph Höger]

Does abrt offer the installation of degubinfo for the just-crashed
application? Packagekit should make that a two click operation.

[Zdenek Prikryl]

Christoph Höger wrote:
>  Does abrt offer the installation of degubinfo for the just-crashed
>  application? Packagekit should make that a two click operation.
>   
If an user wants to report a crash, abrt will install all needed debuginfos. For
the installation abrt uses debuginfo-install, so all needed dependencies are
installed too.

-- 
Zdenek Prikryl <zprikryl(a)redhat.com&gt;