ReportBugs2
Size: 324
Comment:
|
Size: 13276
Comment: Logs upload
|
Deletions are marked like this. | Additions are marked like this. |
Line 5: | Line 5: |
=== 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] <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 participation! [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 Ubuntu. [18:02] <bdmurray> Let's look at a sample bug report - http://launchpad.net/bugs/222278. [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 https://bugs.launchpad.net/ubuntu/+filebug 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> http://launchpad.net/bugs/223455 [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 https://help.ubuntu.com/community/ReportingBugs [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 description. [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 critical. [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 https://wiki.ubuntu.com/Bugs/FindRightPackage [18:27] <bdmurray> This page also contains the names of packages that might be hard to discover. [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 own! [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 http://launchpad.net/bugs/212425 [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 https://wiki.ubuntu.com/DebuggingProcedures [18:46] <bdmurray> If you look at the debugging update-manager page - https://wiki.ubuntu.com/DebuggingUpdateManager [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 fixed! [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 under? [18:50] <bdmurray> Toadinator: early I mentioned the wiki page https://wiki.ubuntu.com/Bugs/FindRightPackage [18:51] <bdmurray> This contains some high level information about when an application is running [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! |
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] <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 participation!
[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 Ubuntu.
[18:02] <bdmurray> Let's look at a sample bug report - http://launchpad.net/bugs/222278.
[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 https://bugs.launchpad.net/ubuntu/+filebug 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> http://launchpad.net/bugs/223455
[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 https://help.ubuntu.com/community/ReportingBugs
[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 description.
[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 critical.
[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 https://wiki.ubuntu.com/Bugs/FindRightPackage
[18:27] <bdmurray> This page also contains the names of packages that might be hard to discover.
[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 own!
[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 http://launchpad.net/bugs/212425
[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 https://wiki.ubuntu.com/DebuggingProcedures
[18:46] <bdmurray> If you look at the debugging update-manager page - https://wiki.ubuntu.com/DebuggingUpdateManager
[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 fixed!
[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 under?
[18:50] <bdmurray> Toadinator: early I mentioned the wiki page https://wiki.ubuntu.com/Bugs/FindRightPackage
[18:51] <bdmurray> This contains some high level information about when an application is running
[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)