We provide an extension of the notion of hooks to be symptom based and interactive. "ubuntu-bug" without parameters would then show the available symptoms, and the symptom hooks can do some (limited) interactivity to get more information from the user, and finally figure out which package to file it against and which information to collect.

Release Note

It is now possible to do symptom-based bug reporting in addition to reporting them against a package. This is particularly useful for symptoms like sound or external storage problems, where functionality is spread out across many packages. Calling "ubuntu-bug" without arguments will list known symptoms, interactively walk through debugging steps, and select the appropriate package against which to file the bug report.


Apport package hooks help tremendously to collect specific information for a bug report. However, in some cases it is quite hard for the reporter to figure out which package to file a bug against, especially for functionality which spans multiple packages. For example, sound problems are divided between the kernel, alsa, pulseaudio, and gstreamer.

In other cases, the information needed for a particular bug may vary depending on the type of symptom being experienced. Currently the apport hooks for a package workaround this by asking for all possible data for any appropriate symptom, even if unneeded, but this makes apport-based bug reports much bigger than they need to be.

For a lot of debugging scenarios, the user needs to do an action during the debugging process, or needs to answer further questions interactively. This currently needs to happen in the bug report trail, but it would be better to ask these questions during the initial data collection to get better structured bug reports.

User stories




Extend apport.ui.UserInterface API with new methods:

Create a new class apport.ui.HookUi which encapsulates functions which hooks can call. This will do the necessary marshaling/signaling to call the UI methods in the GUI thread. In addition to above methods, this will also wrap the existing ui_info_message(self, title, text) and ui_error_message(self, title, text).

Pass current HookUI object to hooks by extending the current API: add_info(report, ui). For backwards compatibility, it should still be possible to run hooks with the add_info(report) API.

Running commands as root

Add new function apport.hookutils.root_command_output() which runs a command as root and returns its output, similar to the current command_output(). This will detect the currently used desktop environment and call gksu/kdesudo/sudo accordingly.


Symptom scripts are put into /usr/share/apport/symptoms/ and need to define a method run(report, ui). By a combination of interactive questions and automatic system tests this method needs to determine the affected package and return it.

It can optionally add information to the passed report object, such as tags. After that, Apport adds package related information and calls the package hooks as usual. Before run() is called, Apport already added the OS and user information to the report object.

Symptom bugs should be tagged with apport-symptom.


If the user canceled an interactive question for which the hook requires an answer, the hook should raise StopIteration, which will stop the bug reporting process.


Fully document hooks, symptoms, and interactivity in doc/package-hooks.txt. Also explain how to set tags.

Drop hooks documentation from Apport/DeveloperHowTo wiki page and replace it with a link to doc/package-hooks.txt in the apport source through

Test/Demo Plan


DesktopTeam/Specs/Karmic/SymptomBasedBugReporting (last edited 2009-08-31 09:06:04 by pitti)