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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
