ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)

[Jiri Moskovcak]

On 12/09/2010 03:52 PM, Ralf Corsepius wrote:
> On 12/09/2010 02:59 PM, Jiri Moskovcak wrote:
>> On 12/09/2010 02:04 PM, Ralf Corsepius wrote:
>>> On 12/09/2010 01:27 PM, Jiri Moskovcak wrote:
>>>> On 12/09/2010 01:08 PM, "Jóhann B. Guðmundsson" wrote:
>>>>> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
>>>>>> Just a wild idea - ABRT detects the dupes even locally so we can make
>>>>>> ABRT to allow reporting the bug to bz only if it happened more then
>>>>>> once
>>>>>> (or some other threshold):)
>>>>>
>>>>> Dont we loose hard to catch odd ball bugs if that's implemented?
>>>>>
>>>>> JBG
>>>>
>>>> yes, but those bugs are usually the reason why maintainers are
>>>> complaining about ABRT..
>>>
>>> Reporters also complain about this for the same reason:
>>>
>>> Reporters who are facing an ABRT alert, which complains about missing
>>> 179 debuginfos (+ have to contact their sys admin to become root and run
>>> debuginfo-install), who then notice that debuginfo-install installs only
>>
>> - debuginfo-install is just a fallback if ABRT fails to retrieve the
>> debuginfo itself (and ABRT doesn't need the root privs, as is *does not*
>> install the packages, it just unpacks them)
> ?!?
>
> It has never done so for me (on fedora 13 + fedora 14). ABRT always

- that's unfortunate, and if you're interested we can try to find out 
why it fails for you... maybe the explanation how ABRT gets the 
debuginfo will help:

ABRT extracts the build-id hashes from the coredump using:

$ eu-unstrip -n -c coredump

and then "asks":

$ yum whatprovides /usr/lib/debug/.build-id/<HASH>.debug

to determine packages containing the missing debuginfo.. this fails if 
the package is too old (for rawhide even few days is old) or debuginfo 
repo is not in sync and I bet there is even more situation where it 
fails... but after this first try is done, ABRT tries to generate 
backtrace using gdb and then ABRT rates the backtrace... if the rating 
is lower then 4 it refuses to report it and suggest you to try 
debuginfo-install to install the missing debuginfo which ABRT fails to 
find/download... debuginfo-install is usually more successful in finding 
some debuginfo packages, but there is no versioned dependency between 
package and debuginfo so it can install the wrong debuginfo package 
(then you have foo-1.2-1 and foo-devel-1.2-2).. but sometimes it works 
fine..

> instructs me to run debuginfo-install, which will fail for obvious
> reasons in a normal user environment and thus requires me to become root
> (On "real ordinary user" systems I usually deinstall ABRT).

- if the debuginfo is the main problem you have with ABRT (ok, you don't 
like the gui, but that's other problem) you can do:

$ yum remove abrt-addon-ccpp && service abrtd restart

this will disable the C/C++ crash handler and leave just koops and 
python and for those no debuginfo is needed..

>
>> the 179 dinfos reported by ABRT and 21 debuginfos downloaded is because
>> ABRT reports the number of missing *debuginfo files*, but
>> debuginfo-install reports number of *debuginfo packages* which can
>> contain those 179 files...
>
> Nope. ABRT complained about a huge number of missing debuginfo hashes.
>

yes -> debuginfo hashes == debuginfo files and one debuginfo package 
contains many debuginfo files... so if ABRT complains about 100 missing 
hashes it might be covered by 1 debuginfo package

> [BTW: I am referring to a real world example: Yesterday, thunderbird
> crashed for me. I ended up with 21 debuginfo filling up my / partition
> and my report having been filed as a duplicate of in
> https://bugzilla.redhat.com/show_bug.cgi?id=656969].
>
>
>> To put out the coming flame before it starts - let's create other thread
>> with subject "ABRT improvements" where everyone interested will write
>> his RFE, I make a wiki page from it and then we can have a vote about
>> priorities of those RFEs with the final word from FESCo... What do you
>> think?
> Good idea.
>
> As you know, I consider ABRT to be a promissing idea, but am critical
> towards the current ABRT client side, which I, openly said, consider to
> be "mostly unusable".
>

The last version of the gui is based on design I got from one of our UI 
people, I am not a gui designer, so I just code what I'm told to... so 
if you have some reasonable hints how to make it more user friendly, 
then please open a bz for it or send them as RFE in the proposed "rfe 
storming"

Jirka