On apport and other matters

[David Farning]

We have good news on apport's status and progress.

As for status, until we started using apport-retrace.  It was not very
heavily used or tested.  Many of the bug reports are actually viewed as
spam;(  imagine that.

Martin has been great to work with.  He had been working rapidly to
implement features that we have asked for.

Dealing with the new Feisty Bugs.  -retace can now pull crash report
straight from LP.

apport -s -d #bugnumber

will pull the necessary files that are attached to that bug number and
direct the output to the standard output.  Cool.

The next step is to automatically send the retraced stack back to LP as
a new attachment.  The code that files the original crash report can be
recycled to upload the new attachment.  Martin has placed a LP request
to implement a method to add an attachment to an existing bug.

Running -retrace can fail in the situation where -retrace is calling
different versions of packages than the system on which -retrace is
being run.  I am working on modifying pbuilder to deal with this
situation.  Basically, -retrace is run in a clean chroot via some shell
scripts.  I don't think that it will scale well.  It should get us
started.

Generating and storing -dbgsym files.  Currently, the build system
automatically generates -dbgsyms while the packages are being built.
Martin has a cron job which pull the -dbgsyms into his p.u.c repo.  The
main point of failure is the cron job.  Other known missing packages are
those in -updates and -security.  He is working with the build admins to
correct this problem.  Finally, packages that have not been rebuilt
since ddeb was set up have not been generated.

Working backwards, I think that any packages we are missing we can
request to be rebuilt.  Martin is working on the -updates and -security.
It will take a bit of time to work out the kinks before -dbgsyms can
become a proper repo.

Historical -dbgsym files.  We are often running into the situation where
the crash report requires versions of -dbgsym files that have been
replaced with newer version.  As I understand it, the main problem is
size.  It is going to take up a lot of space is store old -dbgsyms.  I
will file a issue report requesting that older version be saved for a
while.  We need to set up some sort of storage policy as to what we
would like saved and for how long.  I am guessing 'please save
everything... forever' would get rejected quickly.

thanks
-- 
David Farning <dfarning at gmail.com>