== Ubuntu Open Week - Reporting Bugs - Brian Murray - Mon, Apr 28, 2008 == see also [[MeetingLogs/openweekhardy/ReportBugs2|Saturday session]]. {{{ [18:01] 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] Additionally, I'll cover how to make your bug report more likely to get fixed! [18:01] Perhaps you are wondering what exactly is a bug? [18:02] In computer software it is an error or a flaw that makes it behave in ways for which it wasn't designed. [18:02] 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] By reporting these issues you can help to make Ubuntu even better than it already is. [18:03] Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu. [18:03] Let's look at a sample bug report - http://launchpad.net/bugs/222278 [18:03] There are four things here that I want to point out. [18:04] 1) The bug's title or summary is 'upgrade hangs in checkViewDepends()' [18:04] 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] 3) Bug's have an "Bug description" which is filled out when you are reporting a bug. [18:05] 4) And you'll notice there are four bug comments each containing an attachment with supporting information about the bug. [18:05] Are there any questions about what a bug is or what a bug report looks like? [18:07] I guess not. [18:07] Okay, moving on then! [18:07] So, how can bugs be reported to Launchpad? [18:07] They can be reported via the web interface at https://bugs.launchpad.net/ubuntu/+filebug [18:08] Here you start by filling out the summary which becomes the bug's tile. [18:08] After which you are asked for the package affected and for 'Futher information' which becomes the bug's description. [18:08] The description should contain at a minimum the following information: [18:08] 1) The release of Ubuntu that you found the bug in. [18:09] This is important as there are multiple different versions of Ubuntu that are currently supported. [18:09] 2) The version of the package you found the bug in. [18:09] 3) What you expected to happen [18:09] and ... [18:09] 4) What happened instead [18:10] Additionally, you also have the opportunity to add an attachment to your bug when you are reporting it via the web interface. [18:10] Another way to report a bug is using apport an automated problem report application included with Ubuntu. [18:11] 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] Let's say that you have encountered a bug with Firefox. [18:11] You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem". [18:12] 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] An example of a bug reported using the "Report a Problem" menu item is http://launchpad.net/bugs/223455 [18:12] Not just firefox, that's how you report bugs against firefox [18:13] Right, lots of applications have the "Report a Problem" functionality integrated into them. [18:14] 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] All of these help to make your bug report more complete and potentially easier to fix! [18:15] 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] This is useful for applications without a GUI interface like irssi, mutt, and apache. [18:16] Additionally, with apport-cli you can specify a process id number via 'apport-cli -f -P PID'. [18:17] Using apport is the prefereed way to report bugs about Ubuntu as they contain detailed information about the application and your system. [18:18] Further infromation about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs . [18:18] Are there any questions about how to report bugs to Launchpad or using apport? [18:19] 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] 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] I think your question is actually about finding the name of the package to report the bug about. Is that correct bullgard4? [18:22] bdmurray: Yes [18:23] 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] QUESTION: Is there a non-Web interface way to report bugs to LP? [18:24] Yes, it is possible to send e-mail to 'new@bugs.launchpad.net' to report a new bug. However, your e-mail must be GPG signed. [18:25] You can find additional information about using the e-mail interface at https://help.launchpad.net/BugTrackerEmailInterface . [18:28] Earlier there was a question about identifying the right package to report your bug about. [18:29] This is a critical part of making your bug report more likely to get fixed. [18:30] 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] Some helpful hints for fidnign the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage [18:31] That wiki page contains the names of packages that may be hard to discover. [18:31] For example, bugs about the kernel in Hardy Heron should be reported about the 'linux' package. [18:33] 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] Are there any questions about identifying the package to file a bug about? [18:38] < _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] If that package is one that is included with Ubuntu it should be reported to Launchpad. [18:39] This will allow us to keep track of status of the bug "upstream" and incorporate the fix into Ubuntu. [18:41] An important part of a bug's life cycle is it entering the Confirmed or Triaged status. [18:41] 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] 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] What this means though is that you should include extremely detailed steps to recreate the bug in it's description. [18:43] If they are detailed enough anyone using the same software should be able to confirm the bug report, not just a developer. [18:43] It is far better to have too much detail than not enough. [18:44] 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] Taking a digital picture of the bug if it is one that won't show up in a screenshot. [18:45] It is even possible to take a "screencast", capture video of your desktop, using an application like istanbul. [18:46] An example of a bug with a screencast is https://bugs.launchpad.net/ubuntu/+source/libwnck/+bug/212425 . [18:47] Having a screencast makes the steps to recreate the bug easy to see and can help overcome language barriers. [18:48] 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] 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] You can find the list of debugging procedures at https://wiki.ubuntu.com/DebuggingProcedures [18:49] Are there any questions about how to report a bug about Ubuntu and making a detailed and complete bug report? [18:52] 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] That's a good question. [18:53] Yes, it is possible for the original reporter to change the package name for a bug report. [18:53] Let's look at bug https://bugs.launchpad.net/ubuntu/+bug/223772 [18:54] You can see right now that it affects "Ubuntu" this is the distribution in general. [18:54] The package can be changed by clicking on one of the downward arrow type things. [18:55] 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] QUESTION: When to report a bug to the developers of the software and when Launchpad? [18:56] Ubuntu contains a lot of software that isn't developed by the distribution so this is a very relevant question. [18:57] Let's consider inkscape for example. The package we ship can be slightly different from the upstream version. [18:58] 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] Then you could "forward" the bug to the inkscape upstream project. [18:59] Ideally, this should be done after confirming that the bug exists in the upstream version of inkscape. [18:59] Otherwise we are causing unnecessary work for the upstream developers. [19:00] 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! }}}