We will develop client-side applications which assist the user in reporting a bug to Malone.


A client-side application allows us to automatically collect information from the system which will be helpful in analyzing the bug report. This will save oodles of time for developers and those involved in bug triage, resulting in more bugs being triaged, more bugs being closed, and a higher quality Ubuntu.

Use cases


This specification describes a GUI client which requires a running X session. It is also desirable to develop a command line tool for reporting bugs on servers or reporting bugs when X is broken, but this should become a separate specification.



In order to not duplicate functionality, we use the existing Malone web UI instead of creating two more desktop UIs (for Gnome and KDE). The local agent will collect debugging information, direct the user to the Malone bug page, and makes sure that the debugging information is sent to Malone and gets attached to the new bug report.

The workflow and data collection is very similar to the current apport crash detection system, so we will extend the apport libraries and frontend to support general bug reporting, and then treat crash reports as a special case of bug report.

Frontend workflow

  1. If the frontend is invoked from a running application, it already knows which package contains the bug. If it is called from "System -> Help -> Report a bug", it should ask for the source package name, or "I don't know" (in which case we are going to report a generic distribution bug).

  2. Display an indefinite progress bar dialog asking the user to wait while debug data is collected.
  3. Submit the debug information to Malone's temporary holding area ("cloakroom") and record the handle for it.
  4. Open the +filebug page with extra_info=<token> URL argument and close the local frontend. The +filebug page is opened in a new Firefox (Ubuntu/Xubuntu) or Konqueror (Kubuntu) window. Launchpad will then guide the user through the bug filing process (including the suggestion to check whether the bug was already reported). (Note: HTTP POST is not possible with externally calling firefox with an URL.)

Data submission

The Launchpad cloakroom will accept a MIME multipart message. Message parts with Content-Disposition: inline will be included as comments, while those with Content-Disposition: attachment will become attachments. The first inline message part will be appended to the user's summary of the bug, while subsequent inline message parts will be included as additional comments.


Collected debug data

apport collects various useful debug data and assembles a MIME/multipart document (instead of the currently-used debcontrol format). Large file attachments like core dumps will use gzip content encoding for compression.

The following information will be always collected:

If the bug is filed against a particular package (when specifying a package when using System -> Help -> Report a bug), this additional information will be collected:

If we have an associated process (if we get called from launchpad integration's menu), we additionally collect:

If the bug report is a crash, additionally collect the following:


The proposed workflow is similar to the current crash reporting in apport. The following changes are necessary to apport:

Data preservation and migration

No data migration needs to happen.

If disk space in Launchpad becomes an issue, it is possible to remove large bug attachments like core dumps from closed and duplicate bug reports. Data in bug comments should be preserved forever.


Using the GUI:

Using the ubuntu-bug script:


BugReportingTool (last edited 2008-08-06 16:21:00 by localhost)