Comment 4 for bug 172754

I wish I'd noticed this bug before implementing the Java one and making the problem worse. :-) This is something I'd be interested in working on in my spare time, but I'm not sure what the interface should look like.

Here's what the current scripts do:

apportcheckresume:
- is invoked by apport's upstart job if /var/lib/pm-utils/status exists
- receives no information from the caller
- creates a KernelOops report and attaches some pertinent information
- associates the bug with the kernel package (which has a hook which will do more stuff)

gcc_ice_hook:
- is invoked by gcc itself when an ICE occurs
- receives a path to the compiler executable and a file containing preprocessed output (command line args)
- creates a Bug report and attaches only what it was given
- leaves apport to do the rest (including figure out which package to file on)

kernel_crashdump:
- is invoked by apport's upstart job if /var/crash/vmcore exists
- receives no information from the caller
- creates a KernelCrash report and attaches some pertinent information
- associates the bug with the kernel package (which has a hook which will do more stuff)

kernel_oops:
- is invoked by kerneloops when it detects an oops
- receives a text blob containing the oops data (stdin)
- creates a KernelOops report and attaches some pertinent information
- associates the bug with the kernel package (which has a hook which will do more stuff)

package_hook:
- is invoked by apt when it detects a package install/upgrade failure
- receives a package name, a log file and an error message from the caller (command line args and stdin)
- creates a Package report and attaches the above information
- associates the report with the package which failed
- the general hook has a bunch of logic to further try to find the right package

java_uncaught_exception:
- is invoked by the JVM when a Java program crashes due to an uncaught exception
- receives a list of key/value pairs from the caller and attaches them directly to the report (stdin)
- has some logic to figure out the ExecutablePath based on the URL of the main class (passed in)
- leaves apport to do the rest (including figure out which package to file on)

There isn't really that much common code here that I see, just:

- instantiating the Report object
- adding the information provided by the caller, if any
- calling .add_*_info as appropriate

It might be nice to have a standard way to pass in key/value pairs from the caller, and a convenience function for parsing it and putting it in the report, but that's all that I see which is common. All of the above scripts would still require mostly custom code to do their jobs.