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