Ubuntu Open Week - Reporting Bugs - Brian Murray - Sat, May 3, 2008

see also Monday session. need to be fixed before presentation of the tool !

=== jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: | How to ask questions: | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See to filter out channel noise | "Reporting Bugs" - Brian Murray
[17:58] <jcastro> ok, next up is Reporting Bugs with Brian Murray
[17:59] <jcastro> this session was done on Monday but we scheduled one today to get maximum 
[17:59] <bdmurray> Hi, I'm Brian Murray and I'm Ubuntu's bug master.
[18:00] <bdmurray> I'm here to talk today about how to report bugs about Ubuntu as there are 
various ways you can do it.
[18:00] <bdmurray> Additionally, I'll cover how to make your bug report more complete and 
therefore more likely to get fixed!
[18:00] <bdmurray> Perhaps you are wondering what exactly is a bug?
[18:01] <bdmurray> In computer software it is an error or a flaw that makes it behave in ways 
for which it wasn't designed.
[18:01] <bdmurray> Some of these can result in crashes, others may have a subtle effect on 
functionality, others can be spelling errors.
[18:01] <bdmurray>  By reporting these issues you can help to make Ubuntu even better than it 
already is.
[18:02] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by 
[18:02] <bdmurray> Let's look at a sample bug report -
[18:03] <bdmurray> There are 4 things there that I want to point out.
[18:03] <bdmurray> 1) The bug's title or summary is 'upgrade hanges in checkViewDepends()'
[18:04] <bdmurray> 2) In the affects table, below the title, you'll see that this bug report 
affects 'update-manager (Ubuntu)'
[18:04] <bdmurray> This is the package / application which the bug is about
[18:04] <bdmurray> 3) Below that is the bug's description, labelled "Bug description" ;), 
which is filled out when you are reporting a bug
[18:05] <bdmurray> 4) You'll also notice that there are 5 comments, 4 of which contain 
attachments with supporting information about the bug.
[18:05] <bdmurray> 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] <bdmurray> < wolfger> QUESTION: if something is behaving as designed, but we don't  
like it, is it bug report material?
[18:08] <bdmurray> 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] <bdmurray> < smeg0l> QUESTION when do determine if it's a hardware faily or a bug ?
[18:10] <bdmurray> Determining whether or not a bug report is due to faulty hardware can be 
quite tricky.
[18:11] <bdmurray> 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] <bdmurray> Moving on - How can bugs be reported to Launchpad?
[18:12] <bdmurray> They can be reported via the web interface at where you start by filling out the summary which 
becomes the bug's tile.
[18:12] <bdmurray> After which you are asked for the package affected and for 'Futher 
information' which becomes the bug's description.
[18:12] <bdmurray> The description should contain at a minimum the following:
[18:13] <bdmurray> 1) The release of Ubuntu that you found the bug in.
[18:13] <bdmurray> This is important as there is more than 1 supported release of Ubuntu out 
there right now.
[18:13] <bdmurray> 2) The version of the package you found the bug in.
[18:14] <bdmurray> 3) The behaviou that you expected to happen
[18:14] <bdmurray> and 4) What happened instead
[18:14] <bdmurray> You also have the opportunity to add an attachment to your bug when you 
are reporting it via the web interface.
[18:15] <bdmurray> Another way to report a bug is using apport an automated problem report 
application included with Ubuntu.
[18:15] <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:15] <bdmurray> Let's say that you have encountered a bug with Firefox.
[18:15] <bdmurray> You can use apport to report the bug by going to Firefox's "Help" menu and 
choosing "Report a Problem".
[18:16] <bdmurray> 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] <bdmurray> Let's look at a bug reported using the "Report a Problem" menu item
[18:17] <bdmurray>
[18:17] <bdmurray> 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] <bdmurray> All of this information is gathered for you automatically.
[18:18] <bdmurray> The "Report a Problem" functionality has been integrated into lots of 
applications and is the preferred way to report a bug.
[18:19] <bdmurray> 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] <bdmurray> Additionally, you can also specify a process id number via 'apport-cli -f 
-P PID'.
[18:19] <bdmurray> Further information about reporting bugs can be found at
[18:20] <bdmurray> Are there any questions about how you can report a bug?
[18:21] <bdmurray> < 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] <bdmurray> In that case you could use apport-cli -f -p firefox-3.0 for example
[18:22] <bdmurray> Also when you are running a development release of Ubuntu apport will 
watch for application crashes and report those
[18:23] <bdmurray> < 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] <bdmurray>  sense") cases problems for you and for lthe other people inv
[18:24] <bdmurray> 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] <bdmurray> Possibly there is a bug in the documentation or the software's 
[18:26] <bdmurray> 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] <bdmurray> So how can we make our bug reports more useful for developers?
[18:26] <bdmurray> Choosing the name of the package or application the bug is about is 
[18:27] <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.
[18:27] <bdmurray> Some helpful hints for finding the proper package are at
[18:27] <bdmurray> This page also contains the names of packages that might be hard to 
[18:27] <bdmurray> For example, bugs about the kernel in Hardy Heron should be reported about 
the 'linux' package.
[18:28] <bdmurray> Additionally, members of the Ubuntu bug squad are available in the 
#ubuntu-bugs cahnnel if you need help identifying the proper package.
[18:29] <bdmurray> After the bug is reported in Launchpad an important part of its life cycle 
is it entering the Confirmed status.
[18:29] <bdmurray> 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] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your 
[18:30] <bdmurray> This will make the Confirmed status less useful.
[18:30] <bdmurray> 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] <bdmurray> 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] <bdmurray> And not every bug triager may now all the intricacies of that application.
[18:32] <bdmurray> So by putting extremely detailed steps in your bug report you are 
increasing the chances of it being confirmed.
[18:32] <bdmurray> It is far better to have too much detail than not enough!
[18:33] <bdmurray> Some fairly simple things you can do to make your report easier for 
someone to confirm are including a screenshot.
[18:33] <bdmurray> Or you can create a screencast, a movie of your desktop, using an 
application like istanbul.
[18:34] <bdmurray> Let's take a look at
[18:34] <bdmurray> This bug has a screencast attached to it
[18:35] <bdmurray> Their description of how to reproduce the bug is pretty good but is a 
little hard to understand
[18:36] <bdmurray> By watching the screencast though, bug triagers are able to clearly see 
what steps we should take to recreate the bug.
[18:37] <bdmurray> Are there any more questions at this point in time?
[18:38] <bdmurray> < 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] <bdmurray> There are some crash reports about KDE applications reported by apport.
[18:41] <bdmurray> In regards to integration with the KDE crash handler, I'm not certain but 
will look into it.
[18:42] <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 your bug is about.
[18:44] <bdmurray> Bug triagers and software developers have written up a variety of these 
debugging procedures.
[18:44] <bdmurray> A list of them can be found at
[18:46] <bdmurray> If you look at the debugging update-manager page -
[18:47] <bdmurray> 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] <bdmurray> Providing information like that makes your bug report much more complete
[18:49] <bdmurray> And a bug report with more relevant information is more likely to get 
[18:49] <bdmurray> 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 
[18:50] <bdmurray> Toadinator: early I mentioned the wiki page
[18:51] <bdmurray> This contains some high level information about when an application is 
[18:51] <bdmurray> For example when your system boots and you see the "Ubuntu" logo that is 
the usplash package
[18:52] <bdmurray> Also printing bugs should generally be reported about cupsys and then they 
will be moved to the proper package if necessary
[18:53] <bdmurray> Additionally, there is information about how to find out what application 
an open window belongs to
[18:53] <bdmurray> < 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] <bdmurray> The functionality of apport is integrated into an application via the 
package 'liblaunchpad-integration1'
[18:56] <bdmurray> And I'm fairly certain this is a patch that Ubuntu carries for the package 
with that integration
[18:56] <bdmurray> Any more questions?
[18:58] <bdmurray> Okay, then thanks for coming to the class on How to Report bugs
[18:58] <bdmurray> If you need any help reporting a bug please come to the #ubuntu-bugs 
channel on freenode
[18:58] <bdmurray> Thanks! 

MeetingLogs/openweekhardy/ReportBugs2 (last edited 2008-08-06 16:25:13 by localhost)