From Fedora Project Wiki

(New page: == Apport == This plan obsoletes the old Apport plan - see Features/Apport. == Mailing List Discussions == May 2008: [https://www.redhat.com/archives/fedora-devel-list/2008-May/msg0...)
 
 
(One intermediate revision by one other user not shown)
Line 7: Line 7:


June 2008: [https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01250.html apport/breakpad and fedora] - Further refined after discussions at FUDCon.
June 2008: [https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01250.html apport/breakpad and fedora] - Further refined after discussions at FUDCon.
== Breakpad ==
We will probably want to package [http://code.google.com/p/google-breakpad/ Breakpad] for this. But there are a couple of problems:
# It's already built into bug-buddy, so we get file conflicts
#* use <code>%configure --program-prefix=%{name}- ...</code>
# It's not well-packaged - they don't install any of the headers needed for a <code>-devel</code> subpackage
#* Fix up the automake stuff, send patches upstream
# It's designed soley for tracing the ''current'' process, so it's not useable as a separate crash-handler process
#* Write our own code to convert an ELF core to a minidump
#** Using their headers that define the minidump format
#** Contribute code back upstream
#* Or: "Fix" breakpad to allow dumping a different process
#** Breaks some of their assumptions (e.g. that the code will run inside the crashing process)
#** Might be outside the scope of the upstream project
Fwiw, if breakpad is packaged separately, we should certainly port bug-buddy to build against system-breakpad. But wouldn't apport or an equivalent solution obsolete bug-buddy anyway ?

Latest revision as of 20:11, 5 December 2008

Apport

This plan obsoletes the old Apport plan - see Features/Apport.

Mailing List Discussions

May 2008: Apport - A general overview of technologies involved.

June 2008: apport/breakpad and fedora - Further refined after discussions at FUDCon.

Breakpad

We will probably want to package Breakpad for this. But there are a couple of problems:

  1. It's already built into bug-buddy, so we get file conflicts
    • use %configure --program-prefix=%{name}- ...
  2. It's not well-packaged - they don't install any of the headers needed for a -devel subpackage
    • Fix up the automake stuff, send patches upstream
  3. It's designed soley for tracing the current process, so it's not useable as a separate crash-handler process
    • Write our own code to convert an ELF core to a minidump
      • Using their headers that define the minidump format
      • Contribute code back upstream
    • Or: "Fix" breakpad to allow dumping a different process
      • Breaks some of their assumptions (e.g. that the code will run inside the crashing process)
      • Might be outside the scope of the upstream project

Fwiw, if breakpad is packaged separately, we should certainly port bug-buddy to build against system-breakpad. But wouldn't apport or an equivalent solution obsolete bug-buddy anyway ?