Ubuntu Open Week - Reporting Bugs - Brian Murray - Mon, Nov 2, 2009
1 [21:00] <bdmurray> Hi! So I'm here to talk about to how to report bugs about Ubuntu as there are a couple of different ways you can do it. 2 [21:00] <bdmurray> Additionally, I'll cover how to make your bug report more likely to get fixed! 3 [21:01] <bdmurray> And that don't include bribery. ;-) 4 [21:01] <bdmurray> Let's start of by talking about what exactly constitutes a bug. 5 [21:01] <bdmurray> In computer software it is an error or a flaw that causes it to behave in ways for which it wasn't designed. 6 [21:02] <bdmurray> Some of these can result in crashes, others may have a subtle effect on functionality, others can be spelling errors. 7 [21:02] <bdmurray> By reporting these issues you can help to make Ubuntu even better than it already is. 8 [21:02] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu and quite a few other projects. 9 [21:02] <bdmurray> Let's look at a sample bug report - http://launchpad.net/bugs/410318. 10 [21:03] <bdmurray> There are four things here that I want to point out. 11 [21:03] <bdmurray> 1) The bug's title or summary is ' 12 [21:03] <bdmurray> [i945gm] noticed "[XvMC] fail to init batch buffer" in log files' 13 [21:04] <bdmurray> 2) In the Affects table you'll see that this bug report affects 'xserver-xorg-video-intel (Ubuntu)' this is the package / application which with the bug is about. 14 [21:04] <bdmurray> 3) Bugs have an "Bug description" which is filled out when you are reporting a bug. 15 [21:05] <bdmurray> 4) You'll notice the first bug comment contains multiple attachments with supporting information about the bug. 16 [21:06] <bdmurray> So far I've talked a little about what a bug is and what the reports look like. Are there any questions so far? 17 [21:06] <bdmurray> question - bdmurray: How did the attachments get there? 18 [21:07] <bdmurray> I'll be covering that shortly but they showed up because I reported the bug using an application on my Ubuntu system. 19 [21:08] <bdmurray> So how can we report bugs to Launchpad? 20 [21:08] <bdmurray> They can be reported via the web interface at https://bugs.launchpad.net/ubuntu/ after searching for a package. 21 [21:08] <bdmurray> For example, I searched for firefox and was returned the following results - https://launchpad.net/ubuntu/+search?text=firefox. 22 [21:09] <bdmurray> Now I can file a bug about firefox-3.5, since that is the version I have, using the "Report a bug" button. 23 [21:09] <bdmurray> You start by filling out the summary which becomes the bug's tile. After which you are asked for 'Futher information' which becomes the bug's description. 24 [21:09] <bdmurray> Both of which we saw earlier in the sample bug report. 25 [21:10] <bdmurray> The description should contain at a minimum the following - 26 [21:10] <bdmurray> 1) The release of Ubuntu that you found the bug in. 27 [21:10] <bdmurray> 2) The version of the package you found the bug in. 28 [21:10] <bdmurray> You can find that out using a command like 'apt-cache policy firefox-3.5' 29 [21:11] <bdmurray> 3) What you expected to happen. 30 [21:11] <bdmurray> and 4) What happened instead. 31 [21:11] <bdmurray> You also have the opportunity to add an attachment, or bug tags, to your bug when you are reporting it via the web interface by clicking "Extra options". 32 [21:12] <bdmurray> Back to Amaranth's question... 33 [21:12] <bdmurray> A better way to report a bug is using apport which is an automated problem report application included with Ubuntu. 34 [21:13] <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. 35 [21:13] <bdmurray> Let's say that you have encountered a bug with Firefox. 36 [21:13] <bdmurray> You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem". 37 [21:13] <bdmurray> Apport will start collecting 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. 38 [21:14] <bdmurray> An example of a bug reported using the "Report a Problem" menu item is http://launchpad.net/bugs/463789. 39 [21:14] <bdmurray> Looking at that bug you'll see information in the description regarding the DistroRelease, the package and version, and kernel version among other things. 40 [21:15] <bdmurray> All of which was collected automatically for you by apport. 41 [21:15] <bdmurray> The "Report a Problem" functionality has been integrated into a lot of applications. 42 [21:15] <bdmurray> However, not every application has a help menu - take compiz for example. 43 [21:16] <bdmurray> For cases like that we have a command line utility 'ubuntu-bug' or 'apport-cli'. 44 [21:17] <bdmurray> For example I'd use 'ubuntu-bug compiz' to report a bug compiz. This will call apport which will gather information for my bug report. 45 [21:18] <bdmurray> You can also use a process id as an arguement to ubuntu-bug to report a bug about a specific process. 46 [21:18] <bdmurray> Using apport is the preferred way to report bugs as they contain detailed information about the application and your system. 47 [21:19] <bdmurray> Additionally, there are package hooks for various packages, like the xserver-xorg-video-intel bug report I showed earlier. These hooks will gather specific log files that will be useful for the developers. 48 [21:19] <bdmurray> Further information about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs. 49 [21:20] <bdmurray> Now is good time for some questions - which I see we already have. ;-) 50 [21:20] <bdmurray> 13:09 < alyssum> QUESTION: How do you determine which package a bug affects? What if you are not sure which one of several options? 51 [21:21] <bdmurray> I'll actually cover that shortly. 52 [21:22] <bdmurray> 13:16 < akgraner> QUESTION: what if everytime you use apport to file a bug you get "closed b/c a package was out of date" and you just updated/upgraded ? 53 [21:22] <bdmurray> That sounds like something that might happen if you were running the development release of Ubuntu. 54 [21:23] <bdmurray> Its possible that the mirror you are using is a bit behind the archives. 55 [21:23] <bdmurray> < lifer999> QUESTION: How do I ensure my bug is not a duplicate? 56 [21:24] <bdmurray> One thing to do is search the existing bug reports about the package you are going to file a bug about. 57 [21:24] <bdmurray> Additionally, Launchpad will recommend bugs that the bug you are reporting is a possibly a duplicate of. 58 [21:25] <bdmurray> Its also rather easy to mark a bug as a duplicate of another so if you aren't positive yours is a duplicate feel free to report it. 59 [21:26] <bdmurray> Even though another bug report is about not having sound in Ubuntu if you don't have the exact same hardware it is likely that your bug is not a duplicate of that one. 60 [21:27] <bdmurray> < brobostigon> QUESTION:Is there a cli app to use to report bugs, 61 [21:27] <bdmurray> especially on low end systems, with xorg, that cant deal 62 [21:27] <bdmurray> with heavy browsers.? 63 [21:27] <bdmurray> ubuntu-bug will use whatever browser you have installed 64 [21:28] <bdmurray> additionally it is possible to save a bug report for filing later from a different system 65 [21:28] <bdmurray> you'd use 'apport-cli -f -p <package name>' and then choose to "K: Keep report file for sending later or copying to somewhere else" 66 [21:31] <bdmurray> How can we make our bug reports more useful for the developers? 67 [21:32] <bdmurray> Choosing the right package or application the bug is about is critical. 68 [21:32] <bdmurray> If a bug does not have a package assigned to it is much less likely to get looked at by anyone let alone the developer of that application. 69 [21:32] <bdmurray> Some helpful hints for finding the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage. 70 [21:33] <bdmurray> n particular this page contains the names of packages that might be hard to discover. 71 [21:33] <bdmurray> it] 72 [21:33] <bdmurray> For example, bugs about the kernel in Karmic Koala should be reported about 'linux'. 73 [21:33] <bdmurray> Also feel free to join the #ubuntu-bugs channel if you need help identifying the proper package. 74 [21:34] <bdmurray> That is where members of the bug squad hang out and we'll be happy to help. 75 [21:34] <bdmurray> If you have already reported a bug about Ubuntu but didn't use apport to report it - fear not! 76 [21:34] <bdmurray> It is still possible to use apport to gather information for bugs already reported. 77 [21:34] <bdmurray> This can be done using the command 'apport-collect' and the number of the bug to which you want to add information. 78 [21:35] <bdmurray> An example of this can be found in http://launchpad.net/bugs/461343. 79 [21:35] <bdmurray> The reporter originally reported the bug about gst0.10-python but it looks more likely to be a sound driver bug so they were asked to run 'apport-collect -p alsa-base 461343'. 80 [21:35] <bdmurray> The -p was used in this case so information will be gathered about a different package, alsa-base, rather than the package the bug is filed about. 81 [21:36] <bdmurray> Generally you don't need that option and can just 'apport-collect' and the bug number. 82 [21:37] <bdmurray> So if you've previously reported a bug about Ubuntu go back and check to see if it still exists in Karmic. If it doesn't close it! ;-) If not use apport-collect to gather some more information about it. 83 [21:37] <bdmurray> And now some more questions 84 [21:38] <bdmurray> < openweek5> QUESTION: when does a problem change from *you've not it 85 [21:38] <bdmurray> Intalled / configured correctly, mate* to *yes, that does 86 [21:38] <bdmurray> appear to be like a bug, report it* ? 87 [21:39] <bdmurray> most packages don't require configuration so we err on the side of things being bugs until discovered otherwise 88 [21:39] <bdmurray> Are there any more questions? 89 [21:41] <bdmurray> < rtagger> QUESTION: If i know that the bug is fixed by adding 2 lines in 90 [21:41] <bdmurray> 2 files, should I prepare a complete patch or better inform 91 [21:41] <bdmurray> about the files and lines inline? 92 [21:42] <bdmurray> A complete patch, as an attachment, would be better. It is possible to flag attachments as patches which can then be searched for. Additionally, that'll be much easier to apply than copying stuff out of a comment. 93 [21:43] <bdmurray> 13:41 < alyssum> QUESTION: What do we do if no one is responding to a bug we reported (even though other people can confirm it)? 94 [21:44] <bdmurray> One thing that can help if the package is not only in Ubuntu - is forwarding the bug to the upstream developers. 95 [21:44] <bdmurray> https://wiki.ubuntu.com/Bugs/Upstream 96 [21:45] <bdmurray> After verifying the upstream version of the software is affected too of course! 97 [21:45] <bdmurray> 13:42 < nameiner> QUESTION: I have a problem with my battery not being recognized after suspend. Which package is this most likely related to? 98 [21:46] <bdmurray> I'd start at the highest level, likely gnome-power-manager if that is where you don't see the battery. 99 [21:46] <bdmurray> Moving on 100 [21:46] <bdmurray> An important part of a bug's life cycle is it entering the Confirmed status. 101 [21:47] <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. 102 [21:47] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your own! 103 [21:47] <bdmurray> From a practical standpoint what this means is that you should include extremely detailed steps to recreate the bug in it's description so anyone, not just a developer, could confirm it. 104 [21:47] <bdmurray> Click here, do this, do that... 105 [21:48] <bdmurray> It is far better to have too much detail than not enough! 106 [21:48] <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, or creating a screencast, using gtk-recordmydesktop as an example. 107 [21:48] <bdmurray> An example of a bug with a screencast is http://launchpad.net/bugs/212425. 108 [21:48] <bdmurray> The screencast clearly shows how to recreate the problem which is very helpful. 109 [21:49] <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! 110 [21:49] <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. 111 [21:50] <bdmurray> You can find the list of debugging procedures at https://wiki.ubuntu.com/DebuggingProcedures. 112 [21:50] <bdmurray> Okay, I got through the last bits I wanted to cover. 113 [21:50] <bdmurray> Are there any further questions? 114 [21:51] <bdmurray> Also regarding 13:41 < alyssum> QUESTION: What do we do if no one is responding to a bug we reported (even though other people can confirm it)? 115 [21:52] <bdmurray> It can also help to bring the bug up in the #ubuntu-bugs channel or on the bugsquad mailing list. 116 [21:54] <bdmurray> 13:54 < nameiner> QUESTION: How long does it usually take till someone replies to a bug report. 117 [21:55] <bdmurray> It really depends on the package the bug report is about. Each package in Launchpad has separate subscriptions with different people subscribed to each one. 118 [21:56] <bdmurray> Okay, well that's all I have. Thanks everyone! 119 [21:57] <bdmurray> And if need any help reporting a bug, or finding the package to report a bug on you can find members of the Ubuntu bugsquad in the #ubuntu-bugs IRC channel.
MeetingLogs/openweekKarmic/BugReport (last edited 2009-11-03 03:52:49 by 99-21-107-94)