FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-09-2010, 08:38 AM
Tomas Mraz
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

> 18:53:17 <ajax> i've heard a modest amount of complaints that abrt is doing more harm than good
> 18:53:53 <ajax> along multiple axes, but in particular it's simply too much data for apps like firefox and evo for maintainers to respond to
> 18:54:22 <ajax> i don't have any particular suggestions for this (well, i do, but i'll be politic), but it's something i'd like to see discussed from the distro planning POV
> 18:54:44 <nirik> yeah, came up on the list recently again as well.
> 18:55:11 <vinzv> hi
> 18:56:15 <ajax> is this something people want to talk about here next week, or should it be more of a fedora-devel issue
> 18:56:38 <nirik> I did note that totem and rhythumbox (I can't spell that to save my life) have the vast majority of bastens bugs.
> 18:57:23 <nirik> I wonder if we could get abrt to have a maintainer opt out thing that would be easy to change by maintainers?
> 18:57:35 <nirik> right now it's blacklist is in the package itself.
> 18:58:18 <nirik> or if we could have them file in another place. ;(

ABRT already looks up for the duplicate backtraces. Wouldn't it be the
easiest way to add some special keyword such as "abrtcatchall" or
something and if ABRT found an non-CLOSED bug with this keyword it would
append a new backtrace to the bug instead of opening a new one. This
should be fairly simple to implement. Of course ABRT would not append a
duplicate backtrace that is already added to the bug.

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 08:55 AM
Jiri Moskovcak
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

On 12/09/2010 10:38 AM, Tomas Mraz wrote:
>> 18:53:17<ajax> i've heard a modest amount of complaints that abrt is doing more harm than good
>> 18:53:53<ajax> along multiple axes, but in particular it's simply too much data for apps like firefox and evo for maintainers to respond to
>> 18:54:22<ajax> i don't have any particular suggestions for this (well, i do, but i'll be politic), but it's something i'd like to see discussed from the distro planning POV
>> 18:54:44<nirik> yeah, came up on the list recently again as well.
>> 18:55:11<vinzv> hi
>> 18:56:15<ajax> is this something people want to talk about here next week, or should it be more of a fedora-devel issue
>> 18:56:38<nirik> I did note that totem and rhythumbox (I can't spell that to save my life) have the vast majority of bastens bugs.
>> 18:57:23<nirik> I wonder if we could get abrt to have a maintainer opt out thing that would be easy to change by maintainers?
>> 18:57:35<nirik> right now it's blacklist is in the package itself.
>> 18:58:18<nirik> or if we could have them file in another place. ;(

sure we can, but I'm bit afraid that a lot of maintainers would disable
it even without a good reason, so there should be a policy for that

and we're working on feature
http://fedoraproject.org/wiki/Features/RetraceServer which should fix
the problems with uncomplete backtraces, so at least this complaint
won't apply anymore ...
>
> ABRT already looks up for the duplicate backtraces. Wouldn't it be the
> easiest way to add some special keyword such as "abrtcatchall" or
> something and if ABRT found an non-CLOSED bug with this keyword it would
> append a new backtrace to the bug instead of opening a new one. This
> should be fairly simple to implement. Of course ABRT would not append a
> duplicate backtrace that is already added to the bug.
>

So it would store all bt for one component into one bug? This feels like
"raping" bugzilla, which is not ready to be used with tool like ABRT,
but we can do it as a temporary solution...

J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 08:59 AM
Jiri Moskovcak
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

On 12/09/2010 10:55 AM, Jiri Moskovcak wrote:
> On 12/09/2010 10:38 AM, Tomas Mraz wrote:
>>> 18:53:17<ajax> i've heard a modest amount of complaints that abrt is doing more harm than good
>>> 18:53:53<ajax> along multiple axes, but in particular it's simply too much data for apps like firefox and evo for maintainers to respond to
>>> 18:54:22<ajax> i don't have any particular suggestions for this (well, i do, but i'll be politic), but it's something i'd like to see discussed from the distro planning POV
>>> 18:54:44<nirik> yeah, came up on the list recently again as well.
>>> 18:55:11<vinzv> hi
>>> 18:56:15<ajax> is this something people want to talk about here next week, or should it be more of a fedora-devel issue
>>> 18:56:38<nirik> I did note that totem and rhythumbox (I can't spell that to save my life) have the vast majority of bastens bugs.
>>> 18:57:23<nirik> I wonder if we could get abrt to have a maintainer opt out thing that would be easy to change by maintainers?
>>> 18:57:35<nirik> right now it's blacklist is in the package itself.
>>> 18:58:18<nirik> or if we could have them file in another place. ;(
>
> sure we can, but I'm bit afraid that a lot of maintainers would disable
> it even without a good reason, so there should be a policy for that
>
> and we're working on feature
> http://fedoraproject.org/wiki/Features/RetraceServer which should fix
> the problems with uncomplete backtraces, so at least this complaint
> won't apply anymore ...
>>
>> ABRT already looks up for the duplicate backtraces. Wouldn't it be the
>> easiest way to add some special keyword such as "abrtcatchall" or
>> something and if ABRT found an non-CLOSED bug with this keyword it would
>> append a new backtrace to the bug instead of opening a new one. This
>> should be fairly simple to implement. Of course ABRT would not append a
>> duplicate backtrace that is already added to the bug.
>>
>
> So it would store all bt for one component into one bug? This feels like
> "raping" bugzilla, which is not ready to be used with tool like ABRT,
> but we can do it as a temporary solution...
>
> J.

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)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 11:08 AM
"Jˇhann B. Gu­mundsson"
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 11:19 AM
Alexander Kurtakov
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

On 02:18:47 pm Thursday, December 09, 2010 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?

Having a non-reproducible bug reported is never helpful. How am I supposed to
fix something that neither I nor the reporter can reproduce?

Alex

>
> JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 11:27 AM
Jiri Moskovcak
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

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.. reporter doesn't know how to reproduce, devel
doesn't know either so the bug stays open until the release EOL without
any progress and both maintainer and reporter are just frustrated they
had to spend time on it...

on the other hand I agree that silencing ABRT is not a way to go, I'd
rather see some ideas/hints of how to improve the reports for specific
packages so devels are willing to look at them...

e.g.: If evo is added to blacklist without any hints how to make ABRT
reports usable for evo (yes I have few and they should be in F15), then
it will just stay in the blacklist forever and nothing gets improved..
and after some time we'll have 99% of the packages blacklisted because
it's just sooo convenient ...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 12:04 PM
Ralf Corsepius
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

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
21 debuginfos, just to be finally able to submit a report, then notice
this report is worthless (no reproducer) and thus is very likely to be
will be ignored, isn't helpful to users either and drives them away from
ABRT.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 12:59 PM
Jiri Moskovcak
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

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)

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...

> 21 debuginfos, just to be finally able to submit a report, then notice
> this report is worthless (no reproducer) and thus is very likely to be
> will be ignored, isn't helpful to users either and drives them away from
> ABRT.
>

..and this should go away with the
http://fedoraproject.org/wiki/Features/RetraceServer


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?

Jirka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 01:52 PM
Ralf Corsepius
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

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
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).

> 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.

[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".

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 02:09 PM
"Clyde E. Kunkel"
 
Default ABRT opt-out (was Summary/Minutes from today's FESCo meeting)

On 12/09/2010 08:59 AM, Jiri Moskovcak wrote:
> <snip>
> - 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)
> <snip>
> Jirka

Currently, abrt says the debuginfo packages are missing, but doesn't
download any and does not allow me to download them. Used to be a msg
about what the download cmd should be. This is rawhide, up-to-date.

Regards,
OldFart
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org