August 2011


Ubuntu29 Aug 2011 02:49 pm

Over the past six months or so I’ve been looking at package installation failure bug reports and started noticing that we have allowed the reporting of a lot of bug reports that we really shouldn’t have.

As one example dpkg reports multiple types of failures when it is unable to deal with a local deb file. Encountering a short read while working with the deb file is the most common error and is indicative of a hardware or memory issue on the system. While we could provide the bug reporter support on how to determine where the issue lies and how to test the hardware this is not a bug report and does not belong as a bug report Launchpad.

To prevent further bug reports like this I’ve updated apt, which creates most apport-package bug reports, to not report the issue if it is due to a short read. Additionally, I’ve cleaned up most of these bugs that were already reported in Launchpad and as a part of that process I tagged this type of bug ‘short-read’. Querying Launchpad today there are approximately 202 of these short read bug reports that we really didn’t need and were cluttering up our bug lists.

This is just one example though – there are many more cases like this…

210 bug reports where the package installation failure was due to a segfault in an underlying part of the package installation process. (These are better reported as a crash on that underlying part.)

153 package installation bug reports where there was an fsys-tarfile error.

94 package installation bug reports where there was an I/O error on the file system containing ‘/’, ‘/usr’ or ‘/var’.

82 bug reports regarding package installation failures where a local deb file was inaccessible likely due to hardware or memory issues.

53 bug reports regarding package installation failures where the deb file was corrupted again likely due to hardware issues.

27 bug reports regarding package installation failures where there was a failure when writing the contents of the package to disk.

13 bug reports regarding package installation failures where there was a failure to read the contents of the package.

At least 40 bug reports where people were trying install a package on a Live Media build of Ubuntu and needed a new version of update-initramfs for the package installation to work.

So far that’s a total of 874 package installation failures that we didn’t really need reported in Launchpad. But wait there’s more! I’ve very recently been looking at ubiquity bug reports and come to find out a lot of these are due to media or hardware errors too. I’ve tagged some of these ‘squashfs-error’ and others ‘media-error’ depending on which type of error message appeared in the system’s syslog. The total of these two tags is 204 bug reports.

This brings our grand total of unnecessary bug reports, for this experiment, to 1,078 and this doesn’t include bugs with an extraordinary number of duplicates like a ubiquity bug affecting the behavior of debconf with hundreds of duplicates.

The point being that when we look at bugs that have been created in Launchpad by an automatic process we should look at whether or not we really need this specific type of bug report and if not prevent it from being reported at all. If you aren’t sure how to stop bugs from being reported or clean up hundreds of bugs at once I’m happy to help.

Ubuntu11 Aug 2011 10:01 am

As a part of the Oneiric development cycle I wanted to work on dealing with the overwhelming number of package installation failure bug reports. These are identifiable by the tag apport-package and a ProblemType of Package in the bug description. These reports are currently created when a package fails to install on a development release of Ubuntu or a stable release. This is useful since we have more than 15,000 packages in the archive there are likely some that are not used by people who use the development release. However, this is problematic for stable and development releases when there is no automatic duplicate detection of these bug reports as you end up in a situation where the same failure is reported multiple times and your bug list becomes cluttered.

Thankfully Martin Pitt added in support to apport for a duplicate signature for any type of apport bug report. I’ve now uploaded a version of apport in Oneiric that creates a DuplicateSignature for package installation failures using information from the dpkg terminal log file that will then allow the retracer to automatically mark duplicates of package install failures! This is even more useful now that Michael Vogt has modified dpkg so that apport receives the dpkg terminal log untranslated. I’ve also made it so that when the bug is reported if there is a conflict between two packages trying to use the same file the bug report is tagged ‘package-conflict’.

What about all those existing package installation failures? Well I happen to have a local cache of all the DpkgTerminalLog file attachments from apport-package bug reports. I used the same method used in apport to create the duplicate signature for all those existing apport-package bug reports. Then using the md5sum, thanks Kees, of those duplicate signatures I was able to identify approximately 200 bug reports that were duplicates of other package installation failures! And of course I went through and tagged all the already reported ‘package-conflict’ bug reports I could find.