Hi, I regularly go through most frequent problems reported to ABRT retrace server because it helps me prioritize bugs in Fedora that are assigned to my team. I've noticed a significant drop in number of reports in Fedora 22. It's just two weeks before the final release when many early adopters are already running F22, but the difference in number of reports from F21 and F22 is huge: 64373:904.
12 days before F21 was released, we collected 16081 reports from this version. That's almost 18x more. I don't think we're experiencing such a huge drop in adoption, so I investigated more.
I found out several things which I think are a cause of this:
1) I upgraded my machine, and the new Problem Reporting in Privacy Settings is set not to do automatic reporting, completely ignoring my settings in ABRT from F21.
2) I checked settings in ABRT and automatic settings was enabled, so I thought something was broken because my crashes were not reported automatically. Then (with the help of Jakub Filak) I found out that this had been overridden by the new settings in Privacy.
3) Users are no longer asked if they want to enable automatic reporting when the first crash happens. So unless despite complete lack of any hints they find their way into Privacy settings their crashes are not reported. I can no longer even make ureports manually by clicking on Report in notifications. To report it, I need to do the full BZ report.
With such a decrease in number of reports, ABRT is much less useful to developers and I think we should fix it:
* privacy settings should reflect my settings from ABRT after upgrade. * settings in ABRT and Control Center should be in sync, I understand that the Privacy is master settings overriding app's settings, but there is only one app reporting and it's very confusing for users. * users should be asked if they want to enable automatic reporting after the first crash like in the last.
Jiri
On Thu, May 14, 2015 at 6:27 AM, Jiri Eischmann eischmann@redhat.com wrote:
With such a decrease in number of reports, ABRT is much less useful to developers and I think we should fix it:
- privacy settings should reflect my settings from ABRT after upgrade.
- settings in ABRT and Control Center should be in sync, I understand
that the Privacy is master settings overriding app's settings, but there is only one app reporting and it's very confusing for users.
- users should be asked if they want to enable automatic reporting
after the first crash like in the last.
Seems important and urgent enough to me that the fix should qualify for freeze exception, at a minimum, for Fedora 22.
Jiri Eischmann eischmann@redhat.com wrote: ...
I've noticed a significant drop in number of reports in Fedora 22.
...
Thanks for spotting this Jiri, I agree that it's something to address as a matter of urgency.
As you know, we did a review of the automatic reporting behaviour for F22. One goal here was to replace the automatic reporting dialog that pops up with the first error report - there needs to be a way to show the privacy policy and explain what automatic reporting means. The moment when a user is recovering from a crash is not a good time to do this.
So, the design for F22 was to have GNOME Initial Setup present information about automatic reporting, and prompt the user to enable it. Looking at the situation you describe, one issue could be that users aren't running through initial setup (which is supposed to switch automatic reporting on), because they have already configured their account using Anaconda.
With such a decrease in number of reports, ABRT is much less useful to developers and I think we should fix it:
- privacy settings should reflect my settings from ABRT after upgrade.
- settings in ABRT and Control Center should be in sync, I understand
that the Privacy is master settings overriding app's settings, but there is only one app reporting and it's very confusing for users.
Agree with these two points.
- users should be asked if they want to enable automatic reporting
after the first crash like in the last.
This one I'm not sure about, for some of the reasons explained above. One alternative might be to ensure that initial setup always runs on the first login after upgrade, as a way to present the new privacy options.
Allan
----- Original Message -----
Jiri Eischmann eischmann@redhat.com wrote: ...
I've noticed a significant drop in number of reports in Fedora 22.
...
Thanks for spotting this Jiri, I agree that it's something to address as a matter of urgency.
As you know, we did a review of the automatic reporting behaviour for F22. One goal here was to replace the automatic reporting dialog that pops up with the first error report - there needs to be a way to show the privacy policy and explain what automatic reporting means. The moment when a user is recovering from a crash is not a good time to do this.
So, the design for F22 was to have GNOME Initial Setup present information about automatic reporting, and prompt the user to enable it.
That was done: https://bugzilla.gnome.org/show_bug.cgi?id=744245
Looking at the situation you describe, one issue could be that users aren't running through initial setup (which is supposed to switch automatic reporting on), because they have already configured their account using Anaconda.
This is also a problem for Location services.
With such a decrease in number of reports, ABRT is much less useful to developers and I think we should fix it:
- privacy settings should reflect my settings from ABRT after upgrade.
https://github.com/abrt/abrt/issues/966 was filed about that.
- settings in ABRT and Control Center should be in sync, I understand
that the Privacy is master settings overriding app's settings, but there is only one app reporting and it's very confusing for users.
Agree with these two points.
As far as GNOME is concerned, the ABRT setting is deprecated.
- users should be asked if they want to enable automatic reporting
after the first crash like in the last.
This one I'm not sure about, for some of the reasons explained above. One alternative might be to ensure that initial setup always runs on the first login after upgrade, as a way to present the new privacy options.
We really should remove Anaconda's user creation for Workstation. This has been discussed in other threads.
Cheers
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, May 15, 2015 8:47:46 AM Subject: Re: Significant drop in ABRT reports in F22
----- Original Message -----
Jiri Eischmann eischmann@redhat.com wrote: ...
I've noticed a significant drop in number of reports in Fedora 22.
...
Thanks for spotting this Jiri, I agree that it's something to address as a matter of urgency.
As you know, we did a review of the automatic reporting behaviour for F22. One goal here was to replace the automatic reporting dialog that pops up with the first error report - there needs to be a way to show the privacy policy and explain what automatic reporting means. The moment when a user is recovering from a crash is not a good time to do this.
So, the design for F22 was to have GNOME Initial Setup present information about automatic reporting, and prompt the user to enable it.
That was done: https://bugzilla.gnome.org/show_bug.cgi?id=744245
Looking at the situation you describe, one issue could be that users aren't running through initial setup (which is supposed to switch automatic reporting on), because they have already configured their account using Anaconda.
This is also a problem for Location services.
With such a decrease in number of reports, ABRT is much less useful to developers and I think we should fix it:
- privacy settings should reflect my settings from ABRT after upgrade.
https://github.com/abrt/abrt/issues/966 was filed about that.
- settings in ABRT and Control Center should be in sync, I understand
that the Privacy is master settings overriding app's settings, but there is only one app reporting and it's very confusing for users.
Agree with these two points.
As far as GNOME is concerned, the ABRT setting is deprecated.
- users should be asked if they want to enable automatic reporting
after the first crash like in the last.
This one I'm not sure about, for some of the reasons explained above. One alternative might be to ensure that initial setup always runs on the first login after upgrade, as a way to present the new privacy options.
We really should remove Anaconda's user creation for Workstation. This has been discussed in other threads.
I spoke with David Cantrell about this yesterday, they are working in increased modularity in Anaconda which they hope can be ready for FW23 (not guaranteed), once this is in place hidding the user creation dialogs for the Workstation should be easy.
Christian
On Fri, 2015-05-15 at 08:47 -0400, Bastien Nocera wrote:
As far as GNOME is concerned, the ABRT setting is deprecated.
Well it's obviously unacceptable to have two different settings for the same thing, one of which supercedes the other.
Tangentially related: to be blunt, I have no confidence that the ABRT developers can get the GUI into shape in any reasonable timespan (next 2-3 years) and I'd prefer for us to not ship the GUI at all. Automatic reporting to the retrace server should suffice for us. Even that comes at tremendous cost: out-of-the-box coredumpctl. coredumpctl is an amazing feature for developers (and why I do not use ABRT) and it's a shame that ABRT disables it.
On 05/15/2015 03:35 PM, Michael Catanzaro wrote:
On Fri, 2015-05-15 at 08:47 -0400, Bastien Nocera wrote:
As far as GNOME is concerned, the ABRT setting is deprecated.
Well it's obviously unacceptable to have two different settings for the same thing, one of which supercedes the other.
Tangentially related: to be blunt, I have no confidence that the ABRT developers can get the GUI into shape in any reasonable timespan (next 2-3 years) and I'd prefer for us to not ship the GUI at all.
Sure. It's rocket science to make a GUI according to Gnome HIG, cause it shouldn't have any buttons or features. 2-3 years? I can and I will write an Qt app for ABRT in 2-3 days when our DBus API stabilizes.
I'm wondering what according to you is "in shape" as in my experience most Gnome apps went downhill in terms of usability, features and overall look.
Automatic reporting to the retrace server should suffice for us.
Retrace server is something different and there's no reporting to retrace server - retrace server (surprise) does retracing of core dumps to generate micro reports sent to faf.
https://abrt.readthedocs.org/en/latest/howitworks.html
Even that comes at tremendous cost: out-of-the-box coredumpctl. coredumpctl is an amazing feature for developers (and why I do not use ABRT) and it's a shame that ABRT disables it.
If you ever talked to ABRT developers about these sort of things you would know that there's integration ongoing to use tooling that systemd provides (both coredump hook & journald) so it would be possible to use coredumpctl and abrt alongside.
By tremendous cost you mean you can't use fancy coredumpctl gdb command but with little effort you can write a simple wrapper around abrt-cli that does the very same thing. I agree abrt-cli is not the most usable or intuitive tool but I haven't seen an RFE from you about its missing features. So why you are bashing our project instead of trying to be constructive?
On 2015-05-15 16:41, Richard Marko wrote:
Sure. It's rocket science to make a GUI according to Gnome HIG, cause it shouldn't have any buttons or features. 2-3 years? I can and I will write an Qt app for ABRT in 2-3 days when our DBus API stabilizes.
I'm wondering what according to you is "in shape" as in my experience most Gnome apps went downhill in terms of usability, features and overall look.
Sorry for a bit of a naive question, since I don't know the full span of problems that ABRT needs to solve, but how much UI is needed for a problem reporting app? For a lot of other platforms and apps it's usually a dialog or a checkbox, but perhaps their requirements are very different from ABRT.
For someone who's not a problem-reporting-geek, but happy to help improving Fedora, I found the latest version in F22 such an improvement to the extent that I no longer turn it off on a fresh installation. Previously I had a really hard time reporting crashes and the UI confused me a lot. Big thanks to all the developers who worked on the latest version!
(I turned on automatic reporting on both my systems from today btw, hope the data is useful!) - Andreas
On Fri, 2015-05-15 at 16:41 +0200, Richard Marko wrote:
On 05/15/2015 03:35 PM, Michael Catanzaro wrote:
On Fri, 2015-05-15 at 08:47 -0400, Bastien Nocera wrote:
As far as GNOME is concerned, the ABRT setting is deprecated.
Well it's obviously unacceptable to have two different settings for the same thing, one of which supercedes the other.
Tangentially related: to be blunt, I have no confidence that the ABRT developers can get the GUI into shape in any reasonable timespan (next 2-3 years) and I'd prefer for us to not ship the GUI at all.
Sure. It's rocket science to make a GUI according to Gnome HIG, cause it shouldn't have any buttons or features. 2-3 years? I can and I will write an Qt app for ABRT in 2-3 days when our DBus API stabilizes.
I'm wondering what according to you is "in shape" as in my experience most Gnome apps went downhill in terms of usability, features and overall look.
I think we've gotten off on a bit of a compative tangent here. Lets try to stay constructive.
The ABRT ui has improved _a lot_ in F22, and I'd like to thank you for working on that with Bastien. I don't think there's any need to kick out the current UI (from our side) or throw it all away and start over in Qt (from your side). We just have to smooth out the last remaining rough edges in the user experience.
On 05/15/2015 02:41 PM, Richard Marko wrote:
If you ever talked to ABRT developers about these sort of things you would know that there's integration ongoing to use tooling that systemd provides (both coredump hook & journald) so it would be possible to use coredumpctl and abrt alongside.
There needs to be global off switch to these "feature" and ABRT should be opt in along with systemd-coredump by default.
I had the entire Fedora userbase in the building experiencing high cpu usage and slow down in the desktop due to an screwed up update ( gtk I think ) that caused lotus notes to crash ( cant regal the exact bug number at the moment ) which triggered coredump on top of the notes doing it's own thing.
Needless to say there was a discussion in the office getting rid of Fedora on all workstation that have it as an result of this since it kinda is important to the company that it's staff has a working email client and desktop.
JBG
Surely gnome-abrt does not look as bad as before, but I do not agree that it has improved "a lot." Automatic crash reports are very valuable, but they will work just fine without gnome-abrt. Bugzilla reports are even better, but the UI for this is just not good enough. Continuing to ship it makes us seem less professional.
To be clear: I'm not opposed to continuing to ship the system service that reports crashes automatically. Nor do I propose any changes for F22; it's way too late for that. But I do think we should remove gnome -abrt from the default install in F23.
On Fri, 2015-05-15 at 16:41 +0200, Richard Marko wrote:
Sure. It's rocket science to make a GUI according to Gnome HIG, cause it shouldn't have any buttons or features. 2-3 years? I can and I will write an Qt app for ABRT in 2-3 days when our DBus API stabilizes.
I'm wondering what according to you is "in shape" as in my experience most Gnome apps went downhill in terms of usability, features and overall look.
I'm sorry that my last mail was too harsh.
I find gnome-abrt to be very frustrating to use. Here are some problems I see:
* Random italic and bold text in the "This problem has been reported, but a _Bugzilla_ ticket has not been opened" label. * Problems should not disappear from the list with no indication as to why. (Removing core dumps to free disk space is good. Hiding the history of crashes completely when they're removed is not.) * Problems should not disappear *while they are currently being reported* as that leads to a confusing error message. * The list box on the left is not wide enough, resulting in a small bit of horizontal scrolling. * Above the list box, there is a distinction between My (what? crashes?) and System (what?) crashes that's not relevant or meaningful to users. * System crashes mysteriously disappear from the System list and appear in the My list while being viewed. * I can click the Report button on problems that have already been reported to both the ABRT server and to Bugzilla. Nothing happens when I do. * The word "ABRT" appears in the UI. What's an ABRT? (The string ABRT appears in several other places throughout the UI, and can be replaced by "Problem Reporting.") * The menu allows launching both Preferences and ABRT Configuration, which are separate(!) dialogs. * The window title of the Preferences dialog is Configuration. The window title of the ABRT Configuration dialog is Problem Reporting Configuration. * Both dialogs use the action area (buttons across the bottom of the dialog), which is deprecated. The dialogs should use a header bar and put the buttons there. * The ABRT Configuration dialog uses color question icons. They should be symbolic icons. * The Preferences dialog just needs to be removed. The huge lists of Workflows and Events are way too detailed. This looks good for a power user tool, but apps we ship by default should be simple to use. Hopefully we don't need to go over why each one of these options should not be configurable, except for Bugzilla account details. * If I click Configure on an item in the preferences dialog (e.g. Report to Fedora), the notebook items are too wide for the window, with horizontal scrolling. They start out scrolled to the right, so the leftmost portion of the first letter of each preference is cut off. * Clicking the Report button opens a new window. The application should use only one window. * There is too much blank space before the text Add a screencast. * Add a screencast launches a confusing tool with Stop, Record, Select window, and Close buttons in the bottom-right corner of the screen. It should use GNOME's professional built-in screen recording functionality instead (Ctrl+Alt+Shift+R). * Possible sensitive data is a false positive 99% of the time. Jakub added lots of filters to try to reduce these, but it's still always wrong. * The UI shouldn't mention "Fedora Contrib group members" because that's meaningless to users. * environ, cmdline, backtrace, hostname, comment and reason should not have horizontal scrolling. This makes them all extremely difficult to read. Attempting to scan a backtrace of any length for personal data is a chore, since I have to scroll down a bit, then scroll all the way across to the right, then scroll back to the left, then scroll down a bit more, then scroll all the way across to the right.... * The Forward button is a text button in the bottom right. It should be an icon button in the top right of the header bar. * Search -> Find. Search should be activated automatically by typing, filter (hide) content, and have an icon button in the header bar. We use Find for jumping around between content. * Pressing Ctrl+F should start a Find. * Most importantly, reporting very frequently fails with the message that the backtrace is unusable. That should almost never happen. If sufficient debug info isn't available, it shouldn't be possible to start a report.
I don't intend to file problem reports for these (although I already have for a few). There are just too many issues. The landing screen looks mostly good. The rest of the tool does not.
Retrace server is something different and there's no reporting to retrace server - retrace server (surprise) does retracing of core dumps to generate micro reports sent to faf.
Thanks for the correction. What does faf stand for?
If you ever talked to ABRT developers about these sort of things you would know that there's integration ongoing to use tooling that systemd provides (both coredump hook & journald) so it would be possible to use coredumpctl and abrt alongside.
I actually have many, many issue reports, about half or so of which were promptly fixed by Jakub. In particular, one related to coredumpctl: https://github.com/abrt/abrt/issues/835
I believe we've also discussed it on this list in the past. It's a killer feature that we should enable ASAP. The first time I typed 'coredumpctl gdb' I knew that I would never be able to seriously use a distro without systemd again.
By tremendous cost you mean you can't use fancy coredumpctl gdb command but with little effort you can write a simple wrapper around abrt-cli that does the very same thing.
Hm, "tremendous cost" was too hyperbolic, sorry. I want coredumpctl working out of the box, but it's probably more important to have ABRT by default.
I agree abrt-cli is not the most usable or intuitive tool but I haven't seen an RFE from you about its missing features. So why you are bashing our project instead of trying to be constructive?
I don't care about abrt-cli because it's a CLI tool that most users will never notice or deal with. I don't think I've used it before ever. I do care about Problem Reporting (gnome-abrt).
Michael
Hi Michael,
thank you for pointing out these issues. I tried to answer most them inline.
----- Original Message -----
From: "Michael Catanzaro" mcatanzaro@gnome.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, May 15, 2015 11:26:47 PM Subject: Re: Significant drop in ABRT reports in F22
Surely gnome-abrt does not look as bad as before, but I do not agree that it has improved "a lot." Automatic crash reports are very valuable, but they will work just fine without gnome-abrt. Bugzilla reports are even better, but the UI for this is just not good enough. Continuing to ship it makes us seem less professional.
To be clear: I'm not opposed to continuing to ship the system service that reports crashes automatically. Nor do I propose any changes for F22; it's way too late for that. But I do think we should remove gnome -abrt from the default install in F23.
By that time we should have DBus API even for Bugzilla reports and as Richard mentioned, it should be fairly easy to write a completely new GUI to perfectly fit Gnome's UX. The wheels are in motion, it's just that our team is moving a lot of them. We certainly welcome and appreciate any contributions - send patches! :-)
On Fri, 2015-05-15 at 16:41 +0200, Richard Marko wrote:
Sure. It's rocket science to make a GUI according to Gnome HIG, cause it shouldn't have any buttons or features. 2-3 years? I can and I will write an Qt app for ABRT in 2-3 days when our DBus API stabilizes.
I'm wondering what according to you is "in shape" as in my experience most Gnome apps went downhill in terms of usability, features and overall look.
I'm sorry that my last mail was too harsh.
I find gnome-abrt to be very frustrating to use. Here are some problems I see:
- Random italic and bold text in the "This problem has been reported,
but a _Bugzilla_ ticket has not been opened" label.
- Problems should not disappear from the list with no indication as to
why. (Removing core dumps to free disk space is good. Hiding the history of crashes completely when they're removed is not.)
This is a problem that needs to be addressed in the back-end. We'll take it into account when doing the new DBus API.
- Problems should not disappear *while they are currently being
reported* as that leads to a confusing error message.
Same as above.
- The list box on the left is not wide enough, resulting in a small bit
of horizontal scrolling.
The width of the list box on the left has the been calculated precisely according to the design valid at that time: https://wiki.gnome.org/Design/Apps/Oops https://github.com/abrt/gnome-abrt/commit/046c730c293c5981a09af70ae769183c0a... Resizable width was explicitly rejected by designers.
Granted, in Allan's most recent design, the list seems wider and we'll take a look at it. https://github.com/abrt/gnome-abrt/issues/103
- Above the list box, there is a distinction between My (what?
crashes?) and System (what?) crashes that's not relevant or meaningful to users.
This is again a problem in the back-end.
- System crashes mysteriously disappear from the System list and appear
in the My list while being viewed.
This will be fixed with reworked D-Bus API.
- I can click the Report button on problems that have already been
reported to both the ABRT server and to Bugzilla. Nothing happens when I do.
You should be able to report a problem as many times as you wish because you can send a report via e-mail or you can upload the problem data etc. If "Nothing happens when I do.", then you've found a bug.
- The word "ABRT" appears in the UI. What's an ABRT? (The string ABRT
appears in several other places throughout the UI, and can be replaced by "Problem Reporting.")
Could you please create and issue for that?
- The menu allows launching both Preferences and ABRT Configuration,
which are separate(!) dialogs.
We are going to merge those dialogs, but it's not high in our priorities.
- The window title of the Preferences dialog is Configuration. The
window title of the ABRT Configuration dialog is Problem Reporting Configuration.
- Both dialogs use the action area (buttons across the bottom of the
dialog), which is deprecated. The dialogs should use a header bar and put the buttons there.
- The ABRT Configuration dialog uses color question icons. They should
be symbolic icons.
- The Preferences dialog just needs to be removed. The huge lists of
Workflows and Events are way too detailed. This looks good for a power user tool, but apps we ship by default should be simple to use.
I think we need to go over why each one of these options should not be configurable.
Hopefully we don't need to go over why each one of these options should not be configurable, except for Bugzilla account details.
- If I click Configure on an item in the preferences dialog (e.g.
Report to Fedora), the notebook items are too wide for the window, with horizontal scrolling. They start out scrolled to the right, so the leftmost portion of the first letter of each preference is cut off.
- Clicking the Report button opens a new window. The application should
use only one window.
Is that something in Gnome's HIG? Anyway this is because we need to launch a separate libreport process for reporting. It should be doable with a single window using the new DBus API.
- There is too much blank space before the text Add a screencast.
- Add a screencast launches a confusing tool with Stop, Record, Select
window, and Close buttons in the bottom-right corner of the screen. It should use GNOME's professional built-in screen recording functionality instead (Ctrl+Alt+Shift+R).
ABRT is not a GNOME-only project. The tool provides a bridge between Desktops and libreport. GNOME is not he only Desktop we need to support.
- Possible sensitive data is a false positive 99% of the time. Jakub
added lots of filters to try to reduce these, but it's still always wrong.
Please report false positives so we can do assisted learning :-)
- The UI shouldn't mention "Fedora Contrib group members" because
that's meaningless to users.
- environ, cmdline, backtrace, hostname, comment and reason should not
have horizontal scrolling. This makes them all extremely difficult to read.
I believe this is a matter of preference. For me, wrapped lines are less readable.
Attempting to scan a backtrace of any length for personal data is a chore, since I have to scroll down a bit, then scroll all the way across to the right, then scroll back to the left, then scroll down a bit more, then scroll all the way across to the right....
You don't need to scroll, you can jump by search result.
- The Forward button is a text button in the bottom right. It should be
an icon button in the top right of the header bar.
This can be addressed in reporting UI using the new DBus API.
- Search -> Find. Search should be activated automatically by typing,
This works in the problem list. Or do you mean while reporting?
filter (hide) content, and have an icon button in the header bar. We use Find for jumping around between content.
- Pressing Ctrl+F should start a Find.
- Most importantly, reporting very frequently fails with the message
that the backtrace is unusable. That should almost never happen. If sufficient debug info isn't available, it shouldn't be possible to start a report.
The coredump goes through a sanity check when ABRT generates a core backtrace. There is unfortunately no way of telling whether full retracing will succeed unless you actually try it. Please note that programs crash because they reach an unexpected state so there is a significant probability that so much memory is corrupted that the retracing simply fails.
I don't intend to file problem reports for these (although I already have for a few). There are just too many issues. The landing screen looks mostly good. The rest of the tool does not.
As I said, the reporting "wizard" is part of libreport and it will be much easier to work on it once the new DBus reporting API is in place.
Retrace server is something different and there's no reporting to retrace server - retrace server (surprise) does retracing of core dumps to generate micro reports sent to faf.
Thanks for the correction. What does faf stand for?
FAF stands for Fedora Analysis Framework. https://retrace.fedoraproject.org/faf/ It lives on the same machine as the retrace server because they can benefit from each other's data. Right now, we're internally discussing an even tighter integration of the two.
If you ever talked to ABRT developers about these sort of things you would know that there's integration ongoing to use tooling that systemd provides (both coredump hook & journald) so it would be possible to use coredumpctl and abrt alongside.
I actually have many, many issue reports, about half or so of which were promptly fixed by Jakub. In particular, one related to coredumpctl: https://github.com/abrt/abrt/issues/835
I believe we've also discussed it on this list in the past. It's a killer feature that we should enable ASAP. The first time I typed 'coredumpctl gdb' I knew that I would never be able to seriously use a distro without systemd again.
This is a useful tool and ABRT can do the same thing and more, it can even automatically download debuginfos: https://github.com/abrt/abrt/issues/934 We're going to introduce the tool very soon.
In the meantime, you can enable abrt-journal-core that makes ABRT use coredumpctl: # systemctl disable abrt-ccpp # systemctl enable abrt-journal-core # systemctl start abrt-journal-core
The only downside is that the coredump is saved twice - once in journal and once in ABRT's dumpdir. This is the reason it's not enabled by default, but we're going to solve it in the future.
By tremendous cost you mean you can't use fancy coredumpctl gdb command but with little effort you can write a simple wrapper around abrt-cli that does the very same thing.
Hm, "tremendous cost" was too hyperbolic, sorry. I want coredumpctl working out of the box, but it's probably more important to have ABRT by default.
I agree abrt-cli is not the most usable or intuitive tool but I haven't seen an RFE from you about its missing features. So why you are bashing our project instead of trying to be constructive?
I don't care about abrt-cli because it's a CLI tool that most users will never notice or deal with. I don't think I've used it before ever. I do care about Problem Reporting (gnome-abrt).
Michael
Marek
On 05/18/2015 06:18 AM, Marek Brysa wrote:
By that time we should have DBus API even for Bugzilla reports and as Richard mentioned, it should be fairly easy to write a completely new GUI to perfectly fit Gnome's UX. The wheels are in motion, it's just that our team is moving a lot of them. We certainly welcome and appreciate any contributions - send patches! :-)
I wish I had time to help but don't, sorry. :(
The width of the list box on the left has the been calculated precisely according to the design valid at that time: https://wiki.gnome.org/Design/Apps/Oops https://github.com/abrt/gnome-abrt/commit/046c730c293c5981a09af70ae769183c0a... Resizable width was explicitly rejected by designers. Granted, in Allan's most recent design, the list seems wider and we'll take a look at it. https://github.com/abrt/gnome-abrt/issues/103
I don't have a good solution to this; any number you pick will be theme-dependent. Suffice to say it's no longer wide enough in F22. :(
You should be able to report a problem as many times as you wish because you can send a report via e-mail or you can upload the problem data etc. If "Nothing happens when I do.", then you've found a bug.
I'm not sure what value there is in allowing multiple reports, but anyway: this used to take you through the entire reporting process as though you've never done it before, which was very confusing. At a minimum, there should be a separate workflow for bugs that have previously been reported somehow. But in F22, pressing the button indeed does nothing, as far as I can tell.
- The word "ABRT" appears in the UI. What's an ABRT? (The string ABRT
appears in several other places throughout the UI, and can be replaced by "Problem Reporting.")
Could you please create and issue for that?
Yeah sure.
- environ, cmdline, backtrace, hostname, comment and reason should not
have horizontal scrolling. This makes them all extremely difficult to read.
I believe this is a matter of preference. For me, wrapped lines are less readable.
Attempting to scan a backtrace of any length for personal data is a chore, since I have to scroll down a bit, then scroll all the way across to the right, then scroll back to the left, then scroll down a bit more, then scroll all the way across to the right....
You don't need to scroll, you can jump by search result.
I figured that out after using ABRT for some months. This is really not obvious at all.
- Search -> Find. Search should be activated automatically by typing,
This works in the problem list. Or do you mean while reporting?
I think I was unclear. This is a really easy one to fix: I mean to simply rename "Search" to "Find" because Search is a completely different pattern. (As far as I can tell, the names are arbitrary.)
This is a useful tool and ABRT can do the same thing and more, it can even automatically download debuginfos: https://github.com/abrt/abrt/issues/934 We're going to introduce the tool very soon.
In the meantime, you can enable abrt-journal-core that makes ABRT use coredumpctl: # systemctl disable abrt-ccpp # systemctl enable abrt-journal-core # systemctl start abrt-journal-core
The only downside is that the coredump is saved twice - once in journal and once in ABRT's dumpdir. This is the reason it's not enabled by default, but we're going to solve it in the future.
I can live with that: a small price to pay for coredumpctl. Cool.
Thanks,
Michael
On 05/15/2015 03:35 PM, Michael Catanzaro wrote:
coredumpctl is an amazing feature for developers (and why I do not use ABRT) and it's a shame that ABRT disables it.
New abrt cli now supports features you like plus some more. Please help with testing: https://copr.fedoraproject.org/coprs/rmarko/abrt/
You can also reply to my announcement to devel@ ml.
Regards,
desktop@lists.stg.fedoraproject.org
-
Allan Day -
Andreas Nilsson -
Bastien Nocera -
Chris Murphy -
Christian Schaller -
Jiri Eischmann -
Jóhann B. Guðmundsson -
Marek Brysa -
Matthias Clasen -
Michael Catanzaro -
Richard Marko