## page was renamed from MeetingLogs/openweekhardy/ReportBug2 == Ubuntu Open Week - Reporting Bugs - Brian Murray - Sat, May 3, 2008 == see also [[MeetingLogs/openweekhardy/ReportBugs1|Monday session]]. https://bugs.launchpad.net/ubuntu/+source/reportbug-ng/+bug/175508 need to be fixed before presentation of the tool ! {{{ === jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Reporting Bugs" - Brian Murray [17:58] ok, next up is Reporting Bugs with Brian Murray [17:59] this session was done on Monday but we scheduled one today to get maximum participation! [17:59] Hi, I'm Brian Murray and I'm Ubuntu's bug master. [18:00] I'm here to talk today about how to report bugs about Ubuntu as there are various ways you can do it. [18:00] Additionally, I'll cover how to make your bug report more complete and therefore more likely to get fixed! [18:00] Perhaps you are wondering what exactly is a bug? [18:01] In computer software it is an error or a flaw that makes it behave in ways for which it wasn't designed. [18:01] Some of these can result in crashes, others may have a subtle effect on functionality, others can be spelling errors. [18:01] By reporting these issues you can help to make Ubuntu even better than it already is. [18:02] Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu. [18:02] Let's look at a sample bug report - http://launchpad.net/bugs/222278. [18:03] There are 4 things there that I want to point out. [18:03] 1) The bug's title or summary is 'upgrade hanges in checkViewDepends()' [18:04] 2) In the affects table, below the title, you'll see that this bug report affects 'update-manager (Ubuntu)' [18:04] This is the package / application which the bug is about [18:04] 3) Below that is the bug's description, labelled "Bug description" ;), which is filled out when you are reporting a bug [18:05] 4) You'll also notice that there are 5 comments, 4 of which contain attachments with supporting information about the bug. [18:05] So, that's what a bug report looks like. Are there any questions about the format of a bug report or what a bug is? [18:07] < wolfger> QUESTION: if something is behaving as designed, but we don't like it, is it bug report material? [18:08] Yes, that is a valid bug however it is ultimately up to the developers of that particular piece of software whether or not they will fix it. [18:09] < smeg0l> QUESTION when do determine if it's a hardware faily or a bug ? [18:10] Determining whether or not a bug report is due to faulty hardware can be quite tricky. [18:11] Most of those bug reports would be about the kernel and by looking at kernel log files we can help you determine whether or not it is a hardware or software issue. [18:11] Moving on - How can bugs be reported to Launchpad? [18:12] They can be reported via the web interface at https://bugs.launchpad.net/ubuntu/+filebug where you start by filling out the summary which becomes the bug's tile. [18:12] After which you are asked for the package affected and for 'Futher information' which becomes the bug's description. [18:12] The description should contain at a minimum the following: [18:13] 1) The release of Ubuntu that you found the bug in. [18:13] This is important as there is more than 1 supported release of Ubuntu out there right now. [18:13] 2) The version of the package you found the bug in. [18:14] 3) The behaviou that you expected to happen [18:14] and 4) What happened instead [18:14] You also have the opportunity to add an attachment to your bug when you are reporting it via the web interface. [18:15] Another way to report a bug is using apport an automated problem report application included with Ubuntu. [18:15] 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:15] Let's say that you have encountered a bug with Firefox. [18:15] You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem". [18:16] Apport will start collecing information about your bug and then open a new window where you enter the bug's summary / title and then enter the bug's description. [18:17] Let's look at a bug reported using the "Report a Problem" menu item [18:17] http://launchpad.net/bugs/223455 [18:17] At the bottom of the description you'll see information regarding the DistroRelease, the package and version, and kernel version among other things. [18:18] All of this information is gathered for you automatically. [18:18] The "Report a Problem" functionality has been integrated into lots of applications and is the preferred way to report a bug. [18:19] Additionally, apport has a command line interface, called apport-cli, where you can report a bug about a specific package via 'apport-cli -f -p PACKAGE' which is useful for non GUI applications. [18:19] Additionally, you can also specify a process id number via 'apport-cli -f -P PID'. [18:19] Further information about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs [18:20] Are there any questions about how you can report a bug? [18:21] < lyzium> Question: can apport initialise outside given example. If firefox crashes on start you are unable to launch the "report a problem" option [18:21] In that case you could use apport-cli -f -p firefox-3.0 for example [18:22] Also when you are running a development release of Ubuntu apport will watch for application crashes and report those [18:23] < Lardarse> QUESTION: Do you find that the differences between the developer's definition of a bug (to quote you: "an error or a flaw that makes it behave in ways for which it wasn't designed") and the end-users definition (to word it in the same way, it's usually something along the lines of "an error or a flaw that makes it behave in ways that don't make [18:23] sense") cases problems for you and for lthe other people inv [18:24] Ubuntu is designed for "human beings" and if an application behaves in a way that doesn't make sense then their is something wrong. [18:25] Possibly there is a bug in the documentation or the software's description. [18:26] That bug report won't have as a high of priority as a crash report or other bugs but it still is a valid bug. [18:26] So how can we make our bug reports more useful for developers? [18:26] Choosing the name of the package or application the bug is about is critical. [18:27] 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. [18:27] Some helpful hints for finding the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage [18:27] This page also contains the names of packages that might be hard to discover. [18:27] For example, bugs about the kernel in Hardy Heron should be reported about the 'linux' package. [18:28] Additionally, members of the Ubuntu bug squad are available in the #ubuntu-bugs cahnnel if you need help identifying the proper package. [18:29] After the bug is reported in Launchpad an important part of its life cycle is it entering the Confirmed status. [18:29] Pedro will talk about this more in the next class, but 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:29] Any Launchpad user can confirm a bug report, but please don't confirm your own! [18:30] This will make the Confirmed status less useful. [18:30] 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. [18:31] Let's take OpenOffice for example, there are phenomenal amount of things you can do in the Word Processor or the Spreadsheet parts of it. [18:31] And not every bug triager may now all the intricacies of that application. [18:32] So by putting extremely detailed steps in your bug report you are increasing the chances of it being confirmed. [18:32] It is far better to have too much detail than not enough! [18:33] Some fairly simple things you can do to make your report easier for someone to confirm are including a screenshot. [18:33] Or you can create a screencast, a movie of your desktop, using an application like istanbul. [18:34] Let's take a look at http://launchpad.net/bugs/212425 [18:34] This bug has a screencast attached to it [18:35] Their description of how to reproduce the bug is pretty good but is a little hard to understand [18:36] By watching the screencast though, bug triagers are able to clearly see what steps we should take to recreate the bug. [18:37] Are there any more questions at this point in time? [18:38] < BonesolTeraDyne> QUESTION: Are there any plans to make a KDE version of Apport, or to at least give the KDE crash handler some sort of LP integration? [18:40] There are some crash reports about KDE applications reported by apport. [18:41] In regards to integration with the KDE crash handler, I'm not certain but will look into it. [18:42] 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 your bug is about. [18:44] Bug triagers and software developers have written up a variety of these debugging procedures. [18:44] A list of them can be found at https://wiki.ubuntu.com/DebuggingProcedures [18:46] If you look at the debugging update-manager page - https://wiki.ubuntu.com/DebuggingUpdateManager [18:47] You'll see there is a how to file section, there we have instructions about which log files we need if your bug is about upgrading from one release to another [18:47] Providing information like that makes your bug report much more complete [18:49] And a bug report with more relevant information is more likely to get fixed! [18:49] QUESTION: If you wanted to report a bug, but are unsure what the bug is for (ex: it could belong to one of many programs) how would you know what package to file it under? [18:50] Toadinator: early I mentioned the wiki page https://wiki.ubuntu.com/Bugs/FindRightPackage [18:51] This contains some high level information about when an application is running [18:51] For example when your system boots and you see the "Ubuntu" logo that is the usplash package [18:52] Also printing bugs should generally be reported about cupsys and then they will be moved to the proper package if necessary [18:53] Additionally, there is information about how to find out what application an open window belongs to [18:53] < gscholz> QUESTION: Coming back to apport, how do you include the functionality into an applications menu (report a problem)? Do you write a patch against the source code? I guess these are no upstream features, or is this a kind of generic GNOME functionality? How do you select the applications worth this feature? [18:55] The functionality of apport is integrated into an application via the package 'liblaunchpad-integration1' [18:56] And I'm fairly certain this is a patch that Ubuntu carries for the package with that integration [18:56] Any more questions? [18:58] Okay, then thanks for coming to the class on How to Report bugs [18:58] If you need any help reporting a bug please come to the #ubuntu-bugs channel on freenode [18:58] Thanks! }}}