In last two weeks these components were crashing the most:
1. kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
2. xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
3. tracker seen 9653 times (8% of all reports) http://retrace.fedoraproject.org/faf/problems/83012/ RHBZ#837905, RHBZ#918591 http://retrace.fedoraproject.org/faf/problems/20553/ RHBZ#903774
4. gnome-shell seen 7868 times (6% of all reports) http://retrace.fedoraproject.org/faf/problems/20295/ RHBZ#827158, RHBZ#905168 http://retrace.fedoraproject.org/faf/problems/248426/
5. mate-conf seen 4784 times (4% of all reports) http://retrace.fedoraproject.org/faf/problems/446110/ RHBZ#916033, RHBZ#918641, RHBZ#920689 http://retrace.fedoraproject.org/faf/problems/445664/ RHBZ#916033
Hot problems:
ID Components Count ------------------------------------------------------- 586553 kernel 5681 258569 kernel 5527 244577 xulrunner 5265 294757 xulrunner 3761 446110 mate-conf 3554 20295 gnome-shell 2933 176336 kernel 1781 57483 blueman 1768 575658 kernel 1765 26879 kernel 1752
URL: http://retrace.fedoraproject.org/faf/problems/hot/
Long-term problems:
ID Components Count ------------------------------------------------------- 258569 kernel 8818 244577 xulrunner 7674 20295 gnome-shell 7651 57483 blueman 5813 83012 tracker 5321 100106 gnome-packagekit 5317 574995 kernel 4006 221206 kernel 3885 26879 kernel 3624 176336 kernel 3493
URL: http://retrace.fedoraproject.org/faf/problems/longterm/
Most destabilized components:
Component Jump Graph ---------------------------------------------------------- kernel 1117 ???????
setroubleshoot 541 ???????
xulrunner 334 ???????
nepomuk-core 2 ???????
xscreensaver 203 ???????
Most stabilized components:
Component Jump Graph ---------------------------------------------------------- gjs -202 ???????
tracker 268 ???????
mate-conf -161 ???????
pulseaudio -49 ???????
gnome-packagekit -29 ???????
Server URL: http://retrace.fedoraproject.org/faf/ Report a bug: https://github.com/abrt/faf/issues/new Server sources: https://github.com/abrt/faf
On 03/21/2013 02:50 PM, Richard Marko wrote:
In last two weeks these components were crashing the most:
kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
These two quite popular problems both contain proprietary modules so I would like to use this opportunity to start a discussion about inclusion of reports containing proprietary or non-supported modules in our statistics.
My questions are: - are these helpful or not? - should we exclude them from our statistics completely or provide a way to hide them?
Cheers,
On Thu, Mar 21, 2013 at 10:13 AM, Richard Marko rmarko@redhat.com wrote:
On 03/21/2013 02:50 PM, Richard Marko wrote:
In last two weeks these components were crashing the most:
kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
These two quite popular problems both contain proprietary modules so I would like to use this opportunity to start a discussion about inclusion of reports containing proprietary or non-supported modules in our statistics.
My questions are:
- are these helpful or not?
For the kernel, no. ABRT won't even file to bugzilla if the proprietary taint flag is set, so we will never look at them. If someone manually files it, we close it as WONTFIX unless they can recreate it without that module loaded.
- should we exclude them from our statistics completely or provide a way to
hide them?
For the kernel, I would exclude it them from the statistics.
josh
Josh Boyer wrote, at 03/21/2013 11:18 PM +9:00:
On Thu, Mar 21, 2013 at 10:13 AM, Richard Marko rmarko@redhat.com wrote:
On 03/21/2013 02:50 PM, Richard Marko wrote:
In last two weeks these components were crashing the most:
kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
These two quite popular problems both contain proprietary modules so I would like to use this opportunity to start a discussion about inclusion of reports containing proprietary or non-supported modules in our statistics.
My questions are:
- are these helpful or not?
For the kernel, no. ABRT won't even file to bugzilla if the proprietary taint flag is set, so we will never look at them.
Oh, does this explain that xscreensaver (which I am the maintainer) was listed as "most destabilized components" with 203 jumps, however I did not receive such many bug reports? (I guess most of these crash reports are related to hacks using OpenGL, so maybe many of them are related to proprietary X drivers??)
Regards, Mamoru
On 03/21/2013 04:16 PM, Mamoru TASAKA wrote:
Josh Boyer wrote, at 03/21/2013 11:18 PM +9:00:
On Thu, Mar 21, 2013 at 10:13 AM, Richard Marko rmarko@redhat.com wrote:
On 03/21/2013 02:50 PM, Richard Marko wrote:
In last two weeks these components were crashing the most:
kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
These two quite popular problems both contain proprietary modules so I would like to use this opportunity to start a discussion about inclusion of reports containing proprietary or non-supported modules in our statistics.
My questions are:
- are these helpful or not?
For the kernel, no. ABRT won't even file to bugzilla if the proprietary taint flag is set, so we will never look at them.
Oh, does this explain that xscreensaver (which I am the maintainer) was listed as "most destabilized components" with 203 jumps, however I did not receive such many bug reports?
No, these are not yet reported to bugzilla but the server already caught multiple similar reports. If the bugzilla ticket is not created by one of the reporters, the server will create it automatically after some time.
(I guess most of these crash reports are related to hacks using OpenGL, so maybe many of them are related to proprietary X drivers??)
Not sure, take a look at these: http://retrace.fedoraproject.org/faf/problems/525874/ http://retrace.fedoraproject.org/faf/problems/615049/
Regards,
On Thu, 2013-03-21 at 16:43 +0100, Richard Marko wrote:
Not sure, take a look at these: http://retrace.fedoraproject.org/faf/problems/525874/ http://retrace.fedoraproject.org/faf/problems/615049/
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- ajax
On 03/21/2013 06:30 PM, Adam Jackson wrote:
On Thu, 2013-03-21 at 16:43 +0100, Richard Marko wrote:
Not sure, take a look at these: http://retrace.fedoraproject.org/faf/problems/525874/ http://retrace.fedoraproject.org/faf/problems/615049/
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- ajax
- the state is synced with associated bugzilla tickets periodically - if the problem doesn't have bugzilla ticket it's not possible to change it's state, would like such option?
--Jirka
On Thu, 2013-03-21 at 19:09 +0100, Jiri Moskovcak wrote:
On 03/21/2013 06:30 PM, Adam Jackson wrote:
On Thu, 2013-03-21 at 16:43 +0100, Richard Marko wrote:
Not sure, take a look at these: http://retrace.fedoraproject.org/faf/problems/525874/ http://retrace.fedoraproject.org/faf/problems/615049/
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to
change it's state, would like such option?
It would be nice to be able to close reports, yes. What would be really nice is the ability to mention retrace server PRs directly in bodhi update metadata instead of needing to make a bugzilla for it, but I'd take "promote to bugzilla" too.
- ajax
On Thu, Mar 21, 2013 at 7:09 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to change
it's state, would like such option?
I wouldn't worry about it too much as such. Developers typically track their bugs in bugzilla (and you've said that all reports eventually get into bugzilla), encouraging everyone to have one more system to track issues is just added overhead.
It would start to be interesting if the report could be marked as "fixed in bodhi update NNNN" and abrt would show this to the user with a "your problem has been fixed, please update". Still, that's more of an integration with other systems that adding extra user-modifiable states to faf. Mirek
On Thu, 2013-03-21 at 19:16 +0100, Miloslav Trmač wrote:
On Thu, Mar 21, 2013 at 7:09 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to change
it's state, would like such option?
I wouldn't worry about it too much as such. Developers typically track their bugs in bugzilla (and you've said that all reports eventually get into bugzilla), encouraging everyone to have one more system to track issues is just added overhead.
Right, I'm not sure it makes sense methodologically to 'close issues in faf'. faf is meant to track the occurrence of crashes/bugs, not track work on fixing them. At least in my conception, the concept of 'the bug being closed' just doesn't really apply to faf.
I suppose what would make more sense is to allow the maintainer of a package to force creation of a BZ report associated with the faf report, instead of waiting for faf or a reporter to do it?
It would start to be interesting if the report could be marked as "fixed in bodhi update NNNN" and abrt would show this to the user with a "your problem has been fixed, please update". Still, that's more of an integration with other systems that adding extra user-modifiable states to faf. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 03/21/2013 07:20 PM, Adam Williamson wrote:
On Thu, 2013-03-21 at 19:16 +0100, Miloslav Trmač wrote:
On Thu, Mar 21, 2013 at 7:09 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to change
it's state, would like such option?
I wouldn't worry about it too much as such. Developers typically track their bugs in bugzilla (and you've said that all reports eventually get into bugzilla), encouraging everyone to have one more system to track issues is just added overhead.
Right, I'm not sure it makes sense methodologically to 'close issues in faf'. faf is meant to track the occurrence of crashes/bugs, not track work on fixing them. At least in my conception, the concept of 'the bug being closed' just doesn't really apply to faf.
I suppose what would make more sense is to allow the maintainer of a package to force creation of a BZ report associated with the faf report, instead of waiting for faf or a reporter to do it?
- ok, that's +2 for manual bz tickets -> https://github.com/abrt/faf/issues/149
It would start to be interesting if the report could be marked as "fixed in bodhi update NNNN" and abrt would show this to the user with a "your problem has been fixed, please update". Still, that's more of an integration with other systems that adding extra user-modifiable states to faf. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 03/21/2013 07:16 PM, Miloslav Trmač wrote:
On Thu, Mar 21, 2013 at 7:09 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to change
it's state, would like such option?
I wouldn't worry about it too much as such. Developers typically track their bugs in bugzilla (and you've said that all reports eventually get into bugzilla), encouraging everyone to have one more system to track issues is just added overhead.
It would start to be interesting if the report could be marked as "fixed in bodhi update NNNN" and abrt would show this to the user with a "your problem has been fixed, please update". Still, that's more of an integration with other systems that adding extra user-modifiable states to faf.
- ok, that's +2 for integration with bodhi -> https://github.com/abrt/faf/issues/148
Mirek
On Thu, 2013-03-21 at 19:16 +0100, Miloslav Trmač wrote:
On Thu, Mar 21, 2013 at 7:09 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to change
it's state, would like such option?
I wouldn't worry about it too much as such. Developers typically track their bugs in bugzilla (and you've said that all reports eventually get into bugzilla), encouraging everyone to have one more system to track issues is just added overhead.
That only works if abrt manages to figure out that a given problem matches a given bugzilla.
And, uh, as a developer, I already deal with at least two bugzillas daily. And I _like_ that abrt tracks reports outside of bugzilla. I'm entirely comfortable with issuing updates with comments like "fixes crash report NNN, fixes bug MMM".
But if I can't ever close old problem reports, then I can't use the crash reporting system to tell me what my current hottest problems are. So no, I really don't care about one more system to track issues, particularly not one that I can already log in to with existing Fedora credentials (OpenID even!).
- ajax
On 03/21/2013 09:50 PM, Adam Jackson wrote:
On Thu, 2013-03-21 at 19:16 +0100, Miloslav Trmač wrote:
On Thu, Mar 21, 2013 at 7:09 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
How are problem reports like this updated? How do I say "I built a Mesa that I think fixes this problem, please change its state to MODIFIED"?
- the state is synced with associated bugzilla tickets periodically
- if the problem doesn't have bugzilla ticket it's not possible to change
it's state, would like such option?
I wouldn't worry about it too much as such. Developers typically track their bugs in bugzilla (and you've said that all reports eventually get into bugzilla), encouraging everyone to have one more system to track issues is just added overhead.
That only works if abrt manages to figure out that a given problem matches a given bugzilla.
And, uh, as a developer, I already deal with at least two bugzillas daily. And I _like_ that abrt tracks reports outside of bugzilla. I'm entirely comfortable with issuing updates with comments like "fixes crash report NNN, fixes bug MMM".
But if I can't ever close old problem reports, then I can't use the crash reporting system to tell me what my current hottest problems are. So no, I really don't care about one more system to track issues, particularly not one that I can already log in to with existing Fedora credentials (OpenID even!).
- ajax
- I agree, there is no reason to not provide an option to manually close the reports if abrt fails to match it with bugzilla or bodhi update
- that's actually on our todo for some time - allow developer to close the problem with some comment (a solution?) which then can be shown in abrt client when someone hits the same problem
--Jirka
On 03/21/2013 03:13 PM, Richard Marko wrote:
On 03/21/2013 02:50 PM, Richard Marko wrote:
In last two weeks these components were crashing the most:
kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
These two quite popular problems both contain proprietary modules so I would like to use this opportunity to start a discussion about inclusion of reports containing proprietary or non-supported modules in our statistics.
My questions are:
- are these helpful or not?
- it depends - helpful for what? - for showing that there is a big problem with some proprietary module? => yes
- to get it fixed by kernel developers? => probably not, they usually can't do much about it (can't there be a problem triggered by proprietary module which is actually a bug in kernel??)
- to make a point when trying to convince the author of the proprietary module to fix it? => yes
- should we exclude them from our statistics completely or provide a
way to hide them?
- exclude => no - add an option so devels can filter them out => yes
--Jirka
Cheers,
-- Richard Marko
On Thu, 2013-03-21 at 15:30 +0100, Jiri Moskovcak wrote:
On 03/21/2013 03:13 PM, Richard Marko wrote:
On 03/21/2013 02:50 PM, Richard Marko wrote:
In last two weeks these components were crashing the most:
kernel seen 45496 times (36% of all reports) http://retrace.fedoraproject.org/faf/problems/586553/ http://retrace.fedoraproject.org/faf/problems/258569/
xulrunner seen 12020 times (9% of all reports) http://retrace.fedoraproject.org/faf/problems/244577/ http://retrace.fedoraproject.org/faf/problems/294757/
These two quite popular problems both contain proprietary modules so I would like to use this opportunity to start a discussion about inclusion of reports containing proprietary or non-supported modules in our statistics.
My questions are:
- are these helpful or not?
- it depends - helpful for what?
- for showing that there is a big problem with some proprietary
module? => yes
- to get it fixed by kernel developers? => probably not, they usually
can't do much about it (can't there be a problem triggered by proprietary module which is actually a bug in kernel??)
Even when this is the case, the fact that they can't see the source to the proprietary module makes it next to impossible for the kernel devs to debug. That's why all proprietary tainted reports pretty much go to the round filing cabinet.
So, what to do about things like:
http://retrace.fedoraproject.org/faf/problems/464418/
where the crash occurs in end user code?
Frame # Function Binary Source Line 0 Vlarge_mat_vec_mult::__Vconfigure /ourwork/projects/shmuel/DudyTests/Verilator_large_mat_vec_mult/RunOctave/Vlarge_mat_vec_mult.oct
Can these be excluded somehow? Ignore anything not in /usr?
Am 22.03.2013 03:42, schrieb Orion Poplawski:
So, what to do about things like:
http://retrace.fedoraproject.org/faf/problems/464418/
where the crash occurs in end user code?
Frame # Function Binary Source Line 0 Vlarge_mat_vec_mult::__Vconfigure /ourwork/projects/shmuel/DudyTests/Verilator_large_mat_vec_mult/RunOctave/Vlarge_mat_vec_mult.oct
Can these be excluded somehow? Ignore anything not in /usr?
And ignore anything in /usr/local