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.

3 Responses to “Volume of bugs about Ubuntu is our fault”

  1. on 29 Aug 2011 at 11:27 pm Gillom

    This post is interesting, it reminds me some times ago (about Lucid testing) Matt Zimmerman posting on Planet too about the same bugs flood and crying: hey guys stop reporting useless things !!! I’ve replied him to pay attention and improve the tool(s) used to report, e.g Apport. Since this date Apport is stronger and more clever but still need more work: see piti blog.
    Well, too many bugs is an issue and duplicates is a pain. That said, quality of coding and packaging is an other problem: what a nightmare ubiquity is !!! (and we can add some others that are show stoppers in many cases: mostly due to some “exotic” formatting and installers/headers not dealing with them (or not enough tested before sending them in the repo, so why continuing that way and whinning ?))
    An other trouble source is non genuine packages found somewhere (ppa, debian repo, exotic deb) and mixed with ubuntu packages/settings. As Ubuntu makes lot of customization, apt-get/dpkg/… should restrict such possibilities.
    Want to add a common issue too: the rolling disto game e.g upgrading/dist-upgrading. I cant says how many times i’ve resolved problem simply by purging/reinstalling packages due to crappy uninstalling process with old setting/config left behind.

    Here i stop whinning but yes devs/designers need to follow strong rules and pay attention to all the steps installing/removing/cleaning/formatting and of course the main key is to use/create/improve clever tools, not to close launchpad door !!!

  2. on 07 Sep 2011 at 8:06 pm Ben Root

    Interesting, but I am concerned that there is the risk of inadvertently filtering out a real future bug. You have the potential of never hearing about them, which is a very bad thing.

    Instead, I vote for smarter automatic duplicate detection and making it easy for bug handlers to add bug signatures for filtering, preferably as a button on the report page.

    Actually, to go a step forward, what if we could attach troubleshooting and/or reported solution information to a bug signature that could be sent back to the user through apport?

  3. on 08 Sep 2011 at 7:51 am Brian Murray

    @Ben – You are welcome to review my work, regarding the type of bugs that are being filtered out, as others have done.

    Regarding smarter automatic duplicate detection I blogged about this (http://www.murraytwins.com/blog/?p=106) a little bit ago and covered the work I’ve been doing creating duplicate signatures for package installation failures, ubiquity bug reports and more recently DKMS build failures.

Feed on comments to this Post

Leave a Reply