Ubuntu Open Week - Reporting Bugs - Brian Murray - Mon, Apr 28, 2008

see also Saturday session.

[18:01] <bdmurray> I'm here to talk to you today about how to report bugs about Ubuntu as there are various different ways you can do it.
[18:01] <bdmurray> Additionally, I'll cover how to make your bug report more likely to get fixed!
[18:01] <bdmurray> Perhaps you are wondering what exactly is a bug?
[18:02] <bdmurray> In computer software it is an error or a flaw that makes it behave in ways for which it wasn't designed.
[18:02] <bdmurray>  Some of these can result in crashes, others may have a subtle effect on functionality, others can be as simple as spelling errors.
[18:02] <bdmurray> By reporting these issues you can help to make Ubuntu even better than it already is.
[18:03] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu.
[18:03] <bdmurray> Let's look at a sample bug report -
[18:03] <bdmurray> There are four things here that I want to point out.
[18:04] <bdmurray> 1) The bug's title or summary is 'upgrade hangs in checkViewDepends()'
[18:04] <bdmurray>  2) In the Affects table you'll see that this bug report affects 'update-manager (Ubuntu)' this is the package / application which with the bug is about.
[18:04] <bdmurray> 3) Bug's have an "Bug description" which is filled out when you are reporting a bug.
[18:05] <bdmurray> 4) And you'll notice there are four bug comments each containing an attachment with supporting information about the bug.
[18:05] <bdmurray> Are there any questions about what a bug is or what a bug report looks like?
[18:07] <Amaranth> I guess not.
[18:07] <bdmurray> Okay, moving on then!
[18:07] <bdmurray> So, how can bugs be reported to Launchpad?
[18:07] <bdmurray> They can be reported via the web interface at
[18:08] <bdmurray> Here you start by  filling out the summary which becomes the bug's tile.
[18:08] <bdmurray> After which you are asked for the package affected and for 'Futher information' which becomes the bug's description.
[18:08] <bdmurray> The description should contain at a minimum the following information:
[18:08] <bdmurray> 1) The release of Ubuntu that you found the bug in.
[18:09] <bdmurray> This is important as there are multiple different versions of Ubuntu that are currently supported.
[18:09] <bdmurray> 2) The version of the package you found the bug in.
[18:09] <bdmurray> 3) What you expected to happen
[18:09] <bdmurray> and ...
[18:09] <bdmurray> 4) What happened instead
[18:10] <bdmurray> Additionally, you also have the opportunity to add an attachment to your bug when you are reporting it via the web interface.
[18:10] <bdmurray> Another way to report a bug is using apport an automated problem report application included with Ubuntu.
[18:11] <bdmurray> The advantage to using apport is that it automatically collects information about the release of Ubuntu you are using and the version of the package / application that you are reporting the bug about.
[18:11] <bdmurray> Let's say that you have encountered a bug with Firefox.
[18:11] <bdmurray> You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem".
[18:12] <bdmurray> Apport will start collecing information about your bug and then open a new browser window where you enter the bug's summary / title and then enter the bug's description.
[18:12] <bdmurray> An example of a bug reported using the "Report a Problem" menu item is
[18:12] <Amaranth> Not just firefox, that's how you report bugs against firefox
[18:13] <bdmurray> Right, lots of applications have the "Report a Problem" functionality integrated into them.
[18:14] <bdmurray> Looking at the bug 223455 you'll notice that a lot of information has been gathered automatically including the release of Ubuntu, "DistroRelease", the package and version, and the kernel version among other things.
[18:14] <bdmurray> All of these help to make your bug report more complete and potentially easier to fix!
[18:15] <bdmurray> Apport also has a command line interface, called apport-cli, where you can report a bug about a specific package via 'apport-cli -f -p PACKAGE'.
[18:16] <bdmurray> This is useful for applications without a GUI interface like irssi, mutt, and apache.
[18:16] <bdmurray> Additionally, with apport-cli you can specify a process id number via 'apport-cli -f -P PID'.
[18:17] <bdmurray> Using apport is the prefereed way to report bugs about Ubuntu as they contain detailed information about the application and your system.
[18:18] <bdmurray> Further infromation about reporting bugs can be found at .
[18:18] <bdmurray> Are there any questions about how to report bugs to Launchpad or using apport?
[18:19] <Amaranth> <bullgard4> QUESTION:  Launchpad Bugs requires me to name a project where the bug belongs to. This repels me often from reporting a bug as there is no list where I can select from the 'project' that you want to know. Where can I find such a list?
[18:21] <bdmurray> A 'project' is a software project that uses Launchpad and Ubuntu is one of the 'projects' that use Launchpad.  Other examples of projects are jokosher, inkscape and bughelper.
[18:21] <bdmurray> I think your question is actually about finding the name of the package to report the bug about.  Is that correct bullgard4?
[18:22] <Amaranth> bdmurray: Yes
[18:23] <bdmurray> Okay, not to dodge your question but I'm planning on covering that next actually.  Are there any other questions about the material covered so far?
[18:23] <Amaranth> <mbt> QUESTION: Is there a non-Web interface way to report bugs to LP?
[18:24] <bdmurray> Yes, it is possible to send e-mail to '' to report a new bug.  However, your e-mail must be GPG signed.
[18:25] <bdmurray> You can find additional information about using the e-mail interface at .
[18:28] <bdmurray> Earlier there was a question about identifying the right package to report your bug about.
[18:29] <bdmurray> This is a critical part of making your bug report more likely to get fixed.
[18:30] <bdmurray> If your bug does not have a package assigned it is much less likely to get looked at by anyone, let alone by the developer of the application you are having an issue with.
[18:30] <bdmurray> Some helpful hints for fidnign the proper package are at
[18:31] <bdmurray> That wiki page contains the names of packages that may be hard to discover.
[18:31] <bdmurray> For example, bugs about the kernel in Hardy Heron should be reported about the 'linux' package.
[18:33] <bdmurray> Additionally there are instructions on how to find out the name of a running application.  Which you might need to do if the application doesn't have apport "Report a Problem" functionality.
[18:36] <bdmurray> Are there any questions about identifying the package to file a bug about?
[18:38] <bdmurray> < _stink_> QUESTION: Let's say I find a bug in a project that's small,  and I notify the dev directly. Should I still file the bug on  LP?
[18:39] <bdmurray> If that package is one that is included with Ubuntu it should be reported to Launchpad.
[18:39] <bdmurray> This will allow us to keep track of status of the bug "upstream" and incorporate the fix into Ubuntu.
[18:41] <bdmurray> An important part of a bug's life cycle is it entering the Confirmed or Triaged status.
[18:41] <bdmurray> When a bug is Confirmed it means that someone has been able to recreate the bug or believes sufficient information has been included in the bug report for a developer to start working on it.
[18:42] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your own!  This defeats the purpose of the Confirmed status.
[18:42] <bdmurray> What this means though is that you should include extremely detailed steps to recreate the bug in it's description.
[18:43] <bdmurray> If they are detailed enough anyone using the same software should be able to confirm the bug report, not just a developer.
[18:43] <bdmurray> It is far better to have too much detail than not enough.
[18:44] <bdmurray> Some fairly simple things you can do to make your bug report easier for someone to confirm or triage are including a screenshot via Print Screen.
[18:44] <bdmurray> Taking a digital picture of the bug if it is one that won't show up in a screenshot.
[18:45] <bdmurray> It is even possible to take a "screencast", capture video of your desktop, using an application like istanbul.
[18:46] <bdmurray> An example of a bug with a screencast is .
[18:47] <bdmurray> Having a screencast makes the steps to recreate the bug easy to see and can help overcome language barriers.
[18:48] <bdmurray> One of the best ways to make your bug report more likely to be fixed is to follow the debugging procedures for the package or subsystem the bug is about!
[18:48] <bdmurray> These have been written by bug triagers or the developer of the software and following them will help you create a more detailed bug report.
[18:48] <bdmurray> You can find the list of debugging procedures at
[18:49] <bdmurray> Are there any questions about how to report a bug about Ubuntu and making a detailed and complete bug report?
[18:52] <bdmurray> <toobuntu> QUESTION: If the wrong package was initially assigned to the bug, and later the reporter realizes that it should be changed or the dev marks it as invalid, does a new bug need to be filed or can the O.P. change the package name?
[18:52] <bdmurray> That's a good question.
[18:53] <bdmurray> Yes, it is possible for the original reporter to change the package name for a bug report.
[18:53] <bdmurray> Let's look at bug
[18:54] <bdmurray> You can see right now that it affects "Ubuntu" this is the distribution in general.
[18:54] <bdmurray> The package can be changed by clicking on one of the downward arrow type things.
[18:55] <bdmurray> A new part of the page will be revealed where you can see the package name is blank.  Here you can add the right package name.
[18:55] <bdmurray> <Leviath> QUESTION: When to report a bug to the developers of the  software and when Launchpad?
[18:56] <bdmurray> Ubuntu contains a lot of software that isn't developed by the distribution so this is a very relevant question.
[18:57] <bdmurray> Let's consider inkscape for example.  The package we ship can be slightly different from the upstream version.
[18:58] <bdmurray> So, if you have the bug with Ubuntu's version of inkscape the bug should be reported to Launchpad about the inkscape package in Ubuntu.
[18:58] <bdmurray> Then you could "forward" the bug to the inkscape upstream project.
[18:59] <bdmurray> Ideally, this should be done after confirming that the bug exists in the upstream version of inkscape.
[18:59] <bdmurray> Otherwise we are causing unnecessary work for the upstream developers.
[19:00] <bdmurray> I'm afraid that's all I have time for.  However, if you have any questions about this class or reporting bugs about Ubuntu you can find myself and the rest of the bugsquad in #ubuntu-bugs.  Thanks for coming!

MeetingLogs/openweekhardy/ReportBugs1 (last edited 2008-08-06 16:19:41 by localhost)