Significant drop in ABRT reports in F22
Michael Catanzaro
mcatanzaro at gnome.org
Mon May 18 12:23:52 UTC 2015
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/046c730c293c5981a09af70ae769183c0a07034a
> 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
More information about the desktop
mailing list