abrtd - how to remove

[T.C. Hollingsworth]

On Wed, Dec 14, 2011 at 11:19 AM, Patrick O'Callaghan
<pocallaghan at gmail.com> wrote:
> On Tue, 2011-12-13 at 19:39 +0100, Ralf Corsepius wrote:
>> On 12/13/2011 03:26 PM, Alan Cox wrote:
>> > On Tue, 13 Dec 2011 07:57:54 -0500
>> > Genes MailLists<lists at sapience.com>  wrote:
>> >
>> >>
>> >>    I just had the lovely experience of abrt trying to be helpful - a GUI
>> >> crash - and wanting to download 1.2 GB of debuginfo files including
>> >> things it quite obviously (to a human) does not need.
>> >
>> > It's not bright in some cases. Just tell it not to. The newest version of
>> > abrt will upload dumps to a server to crunch instead which is a lot more
>> > sociable.
>>
>> Which file sizes are you talking about?
>>
>> If these files are getting too big, users with, say GSM or low-bandwidth
>> upstream connections may disagree.
>>
>> At least around here, it's common that a home user's DSL or cable
>> connection's upstream bandwidth is a magnitude smaller than his
>> downstream bandwidth.
>
> I would expect that in both cases abrt is still uploading the dump,
> except that in the local case it's also uploading symbols, so the upload
> is larger. Or is this wrong?

When not using the retrace server, abrt usually just uploads the text
backtrace, not the coredump.  (I believe you can instruct it to do so,
but it doesn't do so by default and I have never needed to.)  When
using the retrace server, abrt anonymously uploads the coredump to the
retrace server, creates a text backtrace, and sends that back to your
computer, whereupon you can submit the text backtrace to bugzilla or
do whatever else you want to with it.

In my experience, the coredump being uploaded is several orders of
magnitude smaller than the debuginfo packages I'd need to download to
perform a backtrace locally, so it still saves me time even though my
download speed is 3x faster than my upload speed.

-T.C