Problems using apport-chroot for local crash analysis

[Alain Kalker]

I would like to use the extensive features of apport to assist with
local crash analysis, but am running into several problems.

The scenario:

On a network of machines, there is a machine, called <victim>, on which
a program crashes. Another machine, <coroner>, is designated to do crash
analysis, in particular retracing, using apport-chroot.

Because the crashes may involve locally developed or unreleased
packages, they don't necessarily need to be reported to Launchpad.

Problem #1: How do I setup apport to send crash reports to a local
machine and not to Launchpad?

For the sake of argument, let's suppose the crash reports will simply be
copied over to <coroner> for analysis.

Problem #2: The report generated right after a crash happens, doesn't
include the required field Package in the report. Only when the user
clicks on "Report Problem", this information is included, including an
incomplete stack trace (see Problem #3), but I want to be able to do
unattended crash reporting.

I reported this problem originally as a bug: LP: #487759 [1], and Martin
Pitt explained that this info isn't collected right after the crash for
performance reasons.
He suggested that I use apport-retrace's -R option to rebuild the crash
report. The problem is that this requires me to also use the -o option.
Unfortunately, this causes apport-retrace to attempt a retrace. Back to
square one (well, Problem #3 actually).

Problem #3: The backtrace from a crash report (even after retracing on
<coroner> is incomplete (no function parameters, often even no function
names at all).

When I view a crash report on <victim>, it contains an incomplete
stacktrace. Reasonable, as <victim> doesn't have the necessary debugging
symbol packages installed.
But when I analyze a crash on <coroner> using apport-chroot in retrace
mode, the stack trace is still incomplete. It seems that (still have to
verify that) apport-chroot/retrace doesn't do a new retrace if the crash
report already contains one.

Any help with this will be greatly appreciated.

Thanks to Martin Pitt for creating such a wonderfully useful tool!

Kind regards,

Alain