Awareness of existing user configurations in software feature upgrades

Registered by Jason Warner

Back when everyone had an xorg.conf and a lot of the X bugs were due to
malformed config files, we would collect the files and run them through
checkers. Brian Murray ran a bot that'd test xorg.confs in bugs posted
to launchpad for instance. Found quite a few issues that way. These
days xorg.conf's are rare and hardly anyone hand-edits them so we don't
do this anymore (although maybe we should...)

But the concept could be applied more generally for config files of all

The most effective thing you can do (IMHO) is create apport hooks for
every application that installs a config file, that looks for and
attaches that file when a user files a bug via 'ubuntu-bug package'.
The hooks are trivial python scripts, basically just:

   from apport.hookutils import *
   from os import path

   def add_info(report):
       if ui.yesno("Would you like to include your ~/.myconf?"):
           attach_file_if_exists(report, path.expanduser('~/.myconf'), 'MyConf')

[You can omit the yesno prompt if you're absolutely certain there's no
chance of sensitive info in the config file, or if you programmatically
strip out or hide that info.]

Copy your hook to /usr/share/apport/package-hooks locally, and test it
out yourself. Once you have it working the way you think it should,
post it to the package's bug tracker (ubuntu-bug <package>), and make
sure to mark it as a patch. A package maintainer will review and
incorporate it into the package.

Next, wait, and let a nice database of config files accumulate in

Then, run a launchpadlib script to download all the configs. Weed out
all the dupes. Keep track of the package version.

Now make a test that iterates through all the config files, launching
the program, and testing if it successfully loads or exits/crashes.
If the app has a test suite, bonus, run that too.

Finally, go file bug reports (both in launchpad and upstream) for the
failures that occur.

Blueprint information

Not started
Bryce Harrington
Needs approval
Series goal:
Milestone target:

Related branches



[laney] Can this be done at another level than the individual package, or in a way that we can share with Debian? I imagine that most of this is boilerplate so perhaps we could add an extra debhelper/cdbs command that will generate the apport hook based on a list of configuration files (in Debian the tool could instead generate /usr/share/bug/<pkg>/script) files, in Ubunu the aforementioned package-hooks file). This will both reduce code duplication in packages and allow us to share this important source of debugging information with upstream.


Work Items

This blueprint contains Public information 
Everyone can see this information.