ABRT?

David Tardon dtardon at redhat.com
Thu Jul 17 07:52:30 UTC 2014


Hi,

On Wed, Jul 16, 2014 at 12:22:51PM +0300, Elad Alfassa wrote:
> On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann <eischmann at redhat.com>
> wrote:
> > ad 1) I think ABRT offers two ways to create backtraces etc. Either on
> > their server or on your machine. AFAIK ABRT started preferring the
> > former option because users don't have to install all the debug tools to
> > report a problem, but if their server is overloaded it may take ages to
> > create a bug report.
> >
> 
> Some users have extremely slow upload speeds, so uploading a 100MB core
> dump takes ages.
> Downloading the debuginfo is also a problem for people with slow download
> speed.

So maybe these users might prefer not to use abrt? There are also users
with very high upload/download speeds, for whom neither is a problem...

> 
> Fedora executables and shared objects are compiled with a minimized form of
> debuginfo. It allows creating a simple backtrace even when you don't have
> the huge -debuginfo packages installed, when the only downside for this
> case is that you'll not have source line names, only symbol names and the
> name of the shared object they came from.
> 
> I think that if we want to improve ABRT's UX, we need to get rid of the
> retrace server AND the debuginfo downloading, an generate the backtrace for
> the bugreport without these.

Yeah, why not. Because it is already hard to get an idea about the
reason for the crash from the backtrace, let's make it even harder!
</sarcasm>

Frankly, rather than that, it would be much better to disable abrt bug
reporting completely.

> The backtrace will take less than a minute to generate (in most cases) and
> is better than nothing.

No, it is not. From packager's POV it is worse than nothing, as it
forces me to spend time on the bug, even though the expectation of
successuful identification of the problem is practically zero.

D.


More information about the desktop mailing list