From wxl at ubuntu.com Tue Nov 4 20:14:13 2014 From: wxl at ubuntu.com (Walter Lapchynski) Date: Tue, 4 Nov 2014 12:14:13 -0800 Subject: how to triage crashes? Message-ID: I hope this is not a topic I didn't see discussed elsewhere, but I have a crash that the upstream developer claims is resolved: https://bugs.launchpad.net/ubuntu/+source/lxlauncher/+bug/1236109 How can I replicate this? Do I just go by the word of the developer? -- @wxl Lubuntu Release Manager, Head of QA Ubuntu PPC Point of Contact Ubuntu Oregon LoCo Team Leader From brian at ubuntu.com Tue Nov 4 20:22:40 2014 From: brian at ubuntu.com (Brian Murray) Date: Tue, 4 Nov 2014 12:22:40 -0800 Subject: how to triage crashes? In-Reply-To: References: Message-ID: <20141104202240.GQ3611@murraytwins.com> On Tue, Nov 04, 2014 at 12:14:13PM -0800, Walter Lapchynski wrote: > I hope this is not a topic I didn't see discussed elsewhere, but I > have a crash that the upstream developer claims is resolved: > https://bugs.launchpad.net/ubuntu/+source/lxlauncher/+bug/1236109 > > How can I replicate this? Do I just go by the word of the developer? I'd first use the Ubuntu Error Tracker to see if it is true, rather than spending time trying to recreate the bug etc.... http://errors.ubuntu.com/bug/1236109 That url will look up the crash in the Error Tracker corresponding to Launchpad bug 1236109. This is a bit complicated though since the developer said it was a crash in the dependent package, libmenu-cache, and not in lxlauncher. However, since we have the following versions of libemenu-cache3 in the archive: $ rmadison libmenu-cache3 libmenu-cache3 | 0.5.1-1ubuntu1 | trusty/universe | amd64, arm64, ... libmenu-cache3 | 0.6.1-1 | utopic/universe | amd64, arm64, ... libmenu-cache3 | 1.0.0-1 | vivid/universe | amd64, arm64, ... and the problem page doesn't list any Utopic (14.10) instances of the crash it does seem likely that the crash is fixed. Does that all make sense? -- Brian Murray Ubuntu Bug Master -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From noreply at ubuntu.com Wed Nov 5 08:37:16 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 05 Nov 2014 08:37:16 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Kernel/Debugging/Backlight=22_by?= =?utf-8?q?_jnikula?= Message-ID: <20141105083716.21410.6582@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Kernel/Debugging/Backlight" page has been changed by jnikula: http://wiki.ubuntu.com/Kernel/Debugging/Backlight?action=diff&rev1=30&rev2=31 Comment: link to sysfs backlight interface documentation The file {{{actual_brightness}}} contains the currently set brightness level. Reading {{{brightness}}} results in the same number. In {{{max_brightness}}} is the maximum number allowed to be written into {{{brightness}}}. While the ACPI {{{/proc}}} interface uses percentage levels, the ''sysfs'' interface uses index numbers between 0 and the maximum brightness. - /!\ TODO: might be that actual_brightness queries the values on read, while brightness only returns the value written last. bl_power has no effect, what is it supposed to do? + See the kernel documentation of [[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/stable/sysfs-class-backlight|sysfs class backlight]] interface for the definitive description of the attributes. {{{ #> grep . /sys/class/backlight/acpi_video0/* From es20490446e at gmail.com Mon Nov 10 01:27:23 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 10 Nov 2014 02:27:23 +0100 Subject: What if users warned about critical bugs? Message-ID: <5460147B.3010001@gmail.com> Perhaps asking users in documentation to mail the Ubuntu Bug Control team when they find a critical bug would be a good idea. What do you think? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From teward at trekweb.org Mon Nov 10 05:59:23 2014 From: teward at trekweb.org (Thomas Ward) Date: Mon, 10 Nov 2014 00:59:23 -0500 Subject: What if users warned about critical bugs? In-Reply-To: <5460147B.3010001@gmail.com> References: <5460147B.3010001@gmail.com> Message-ID: <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> I... don't see your logic here. When I read your statement I have a thousand questions show up in my head: How would a user know what a critical bug is? Better question, why would they need to email bug control? And where in the documentation would you put this? Further, while bugs may be 'critical' and need attention, does everyone on bug control really need to be notified of every critical bug? I'm curious what your reasoning for asking this question is. Mind explaining how you came up with this suggestion/idea? ------ Thomas *Sent from my iPhone. Please excuse any typos, as they are likely to happen by accident.* > On Nov 9, 2014, at 20:27, Alberto Salvia Novella wrote: > > Perhaps asking users in documentation to mail the Ubuntu Bug Control team when they find a critical bug would be a good idea. What do you think? > > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality From es20490446e at gmail.com Mon Nov 10 16:11:52 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 10 Nov 2014 17:11:52 +0100 Subject: What if users warned about critical bugs? In-Reply-To: <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> Message-ID: <5460E3C8.1030003@gmail.com> Thomas Ward: > How would a user know what a critical bug is? Instead of asking to report critical bugs, you can ask "if the bug causes data corruption or renders the system temporally or permanently unusable, please warn about it to the Bug Control team". Thomas Ward: > why would they need to email bug control? So the team can set importance early, instead these bugs remain unnoticed in a pool of reports. Thomas Ward: > And where in the documentation would you put this? On . Thomas Ward: > Further, while bugs may be 'critical' and need attention, does > everyone on bug control really need to be notified of every critical > bug? There are only 47 known critical bugs for all the supported releases, and only 14 affecting Utopic. Probably the Bug Control team would be receiving less than 10 emails for every circle of 6 months. Thomas Ward: > Mind explaining how you came up with this suggestion/idea? Because I noticed many critical bugs only get marked as such after a long time has passed. Charles Profit: > What would make this any different than a normal bug report? Nearly no critical bug would go unnoticed into releases, and broken systems would be unusable for the shortest period of time. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From teward at trekweb.org Mon Nov 10 16:37:48 2014 From: teward at trekweb.org (Thomas Ward) Date: Mon, 10 Nov 2014 11:37:48 -0500 Subject: What if users warned about critical bugs? In-Reply-To: <5460E85E.6000205@gmail.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <5460E85E.6000205@gmail.com> Message-ID: I think we need to really tread carefully here... On Mon, Nov 10, 2014 at 11:31 AM, Nio Wiklund wrote: > Den 2014-11-10 17:11, Alberto Salvia Novella skrev: >> Thomas Ward: >>> How would a user know what a critical bug is? >> >> Instead of asking to report critical bugs, you can ask "if the bug >> causes data corruption or renders the system temporally or permanently >> unusable, please warn about it to the Bug Control team". > > I think this is a good idea, definitely worth trying :-) We need to be really careful with how we define 'data corruption'. There are cases, such as in the nginx package, where data is overwritten by the package because it ships defaults. If the configuration files, and/or included default file directories, get overwritten, this can cause 'data corruption via overwriting', but that's not a Critical bug, that's a case where the user used the default location controlled by the package manager, not necessarily a bug in the package itself. If we define 'data corruption' to be, say, a partition-wide corruption, that's different than a few configs being deleted or corrupted but. being repairable or replaceable. Therefore, we need to explicitly define 'data corruption' in context of how we want something to be determined as 'critical'. From es20490446e at gmail.com Mon Nov 10 17:44:44 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 10 Nov 2014 18:44:44 +0100 Subject: What if users warned about critical bugs? In-Reply-To: References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <5460E85E.6000205@gmail.com> Message-ID: <5460F98C.4010800@gmail.com> Thomas Ward: > We need to be really careful with how we define 'data corruption'. > There are cases, such as in the nginx package, where data is > overwritten by the package because it ships defaults. If the > configuration files, and/or included default file directories, get > overwritten, this can cause 'data corruption via overwriting', but > that's not a Critical bug, that's a case where the user used the > default location controlled by the package manager, not necessarily a > bug in the package itself. If the warned bug is not a critical one, the team can simply set it with another priority. And I think the "data corruption" meaning is easily understood taking into account the communicative context, or overwriting configuration is not data corruption. Brendan Perrine: > If this gets to all users how can we make sure there are not people > that think this bug affects me therefore it is critical which could > make lots of mistakes. Or a user that is like I want this fixed badly > therefore it is critical. In the last term the Bug Control team is who sets the importance, not the reported. Brendan Perrine: > How would this be any different than a bug that ends up in red on the > bug tracker that makes an install fail. Nothing, as the bug would be tracked in Launchpad equally. Brendan Perrine: > A bug tag on launchpad like iso-testing-critical for bugs that caused > a failed testcase could be something to make triaging easier and > would encourage people to use the tracker and would work on top of > the already existing infrastructre. Why putting "critical" to a tag when there's already a field for priorities? How can adding a new tag to the list of 123 we have encourage people to use the tracker? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From teward at trekweb.org Mon Nov 10 17:56:46 2014 From: teward at trekweb.org (Thomas Ward) Date: Mon, 10 Nov 2014 12:56:46 -0500 Subject: What if users warned about critical bugs? In-Reply-To: <5460F98C.4010800@gmail.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <5460E85E.6000205@gmail.com> <5460F98C.4010800@gmail.com> Message-ID: On Mon, Nov 10, 2014 at 12:44 PM, Alberto Salvia Novella wrote: > > Brendan Perrine: >> If this gets to all users how can we make sure there are not people >> that think this bug affects me therefore it is critical which could >> make lots of mistakes. Or a user that is like I want this fixed badly >> therefore it is critical. > > In the last term the Bug Control team is who sets the importance, not the > reported. The only way this can work is if people familiar with the package / issue actively are alerted about the criticality issue. In those cases, though, they're likely already watching the bugs in the specific packages. So how does this expedite processing of the bugs? As well, we're going to have a lot of users who aren't familiar with the importance criterion, emailing in and saying "Oh, this is critical", because they don't read the importance requirements, and we're probably going to get higher amounts of incorrectly-reported items in the bug control inbox. > > > Brendan Perrine: >> How would this be any different than a bug that ends up in red on the >> bug tracker that makes an install fail. > > Nothing, as the bug would be tracked in Launchpad equally. If this makes it no different than any other bug, how does notifying Bug Control about potentially critical bugs make any real difference? Just because we set the importance does not mean it gets fixed faster. > > Brendan Perrine: >> A bug tag on launchpad like iso-testing-critical for bugs that caused >> a failed testcase could be something to make triaging easier and >> would encourage people to use the tracker and would work on top of >> the already existing infrastructre. > > Why putting "critical" to a tag when there's already a field for priorities? > How can adding a new tag to the list of 123 we have encourage people to use > the tracker? This. There's no need for a 'critical' tag. If we had a 'critical' tag we'd need the additional tags for every other importance and that's not necessarily needed. ------ Thomas From es20490446e at gmail.com Mon Nov 10 23:16:11 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Tue, 11 Nov 2014 00:16:11 +0100 Subject: What if users warned about critical bugs? In-Reply-To: References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <5460E85E.6000205@gmail.com> <5460F98C.4010800@gmail.com> Message-ID: <5461473B.7090407@gmail.com> Thomas Ward: > The only way this can work is if people familiar with the package / > issue actively are alerted about the criticality issue. In those > cases, though, they're likely already watching the bugs in the > specific packages. So how does this expedite processing of the bugs? By making Launchpad to short those first when visiting a project bug section, even for a package maintainer or somebody willing to report bugs upstream while triaging. Thomas Ward: > As well, we're going to have a lot of users who aren't familiar with > the importance criterion, emailing in and saying "Oh, this is > critical", because they don't read the importance requirements, and > we're probably going to get higher amounts of incorrectly-reported > items in the bug control inbox. So better to change saying it is critical for telling it renders the system temporally or permanently unusable. Thomas Ward: > Just because we set the importance does not mean it gets fixed faster. Because critical flaws are discovered sooner, it also allows to work on them sooner. To stop watering weeds for watering trees. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From nio.wiklund at gmail.com Mon Nov 10 16:31:26 2014 From: nio.wiklund at gmail.com (Nio Wiklund) Date: Mon, 10 Nov 2014 17:31:26 +0100 Subject: What if users warned about critical bugs? In-Reply-To: <5460E3C8.1030003@gmail.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> Message-ID: <5460E85E.6000205@gmail.com> Den 2014-11-10 17:11, Alberto Salvia Novella skrev: > Thomas Ward: >> How would a user know what a critical bug is? > > Instead of asking to report critical bugs, you can ask "if the bug > causes data corruption or renders the system temporally or permanently > unusable, please warn about it to the Bug Control team". I think this is a good idea, definitely worth trying :-) > Thomas Ward: >> why would they need to email bug control? > > So the team can set importance early, instead these bugs remain > unnoticed in a pool of reports. > From es20490446e at gmail.com Wed Nov 12 00:54:41 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 12 Nov 2014 01:54:41 +0100 Subject: Now there's a list of bugs for fixing Message-ID: <5462AFD1.5010608@gmail.com> Now Lists of Bugs include reports ready to be fixed by developers: It's amazing how much clarity this simple method gives. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From webmaster at ubuntu.com Tue Nov 18 15:42:33 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Tue, 18 Nov 2014 15:42:33 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pope?= =?utf-8?q?y?= Message-ID: <20141118154233.24468.12110@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Help Wiki" for change notification. The "ReportingBugs" page has been changed by popey: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=270&rev2=271 Comment: Move the list of "do not" to the bottom <> ||<>|| + + = How to report bugs = + + Ubuntu uses [[Launchpad]] to keep track of bugs and their fixes. This page will guide you through the steps required to file a good and detailed report. + + == Create a Launchpad account == + + If you don’t already have one - you need to [[https://help.launchpad.net/YourAccount/NewAccount|create a Launchpad account]]. This will allow you to file new bugs and comment on existing ones. + + == Determine if the bug is really a bug == + + You should not file a bug if you are: + + * '''Requesting new software:''' you should follow the guidelines at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages + * '''Requesting support:''' there are a multitude of ways you can get help using Ubuntu, such as the [[https://answers.launchpad.net/ubuntu|Launchpad answer tracker]], the [[http://askubuntu.com/|Ask Ubuntu]] site, the [[http://www.ubuntuforums.org/|Ubuntu forums]], the [[irc://irc.freenode.net/#ubuntu|#ubuntu]] channel on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server, and the [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-users|ubuntu-users]] mailing list. + * '''Discussing features and existing policy:''' this belongs to the [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss|ubuntu-devel-discuss]] mailing list. + * '''Proposing features and ideas:''' you should submit your idea to the [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss|ubuntu-devel-discuss]] mailing list. + * '''Filing a bug against a program not provided by an Ubuntu package:''' You should file a bug in that program's bug tracking interface. Instructions are generally available on the program's web site. + + /!\ If you want to file a translation or misspelling bug, follow the instructions [[#translation|here]]. + + == Perform a survey of your problem == + + First, check the release notes for your version of Ubuntu: + * [[http://www.ubuntu.com/getubuntu/releasenotes/1004|Ubuntu 10.04 LTS (Lucid Lynx)]] + * [[http://www.ubuntu.com/getubuntu/releasenotes/1204|Ubuntu 12.04 LTS (Precise Pangolin)]] + * [[https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues|Ubuntu 14.04 (Trusty Tahr)]] <
> + Second, check Launchpad for any duplicates, and make note of this. + + === Desktop Applications === + + For [[https://wiki.ubuntu.com/DebuggingProcedures#Desktop_Applications|desktop applications]], if you find an already reported bug that is exactly like the problem you have, please feel free to add this information to the existing report, rather than opening a new one. However, if you have any doubt as to it being the same or not, please file a separate report. + + [[#Top|Back to top]] + + == Reporting an application crash in the development release == + + Please report an application crash via the methods outlined below and at [[https://wiki.ubuntu.com/DebuggingProgramCrash]]. + + If an application crashes, and you're using a development release, Apport should start automatically, raising an appropriate bug report for you to complete in Launchpad. This report is subsequently processed by [[Apport Retracing Service]], in order to provide developers with debugging information that make it easier to fix the problem. + + == Reporting an application crash in the stable release == + + Apport may come disabled by default. To enable it, edit the file: + {{{ + /etc/default/apport + }}} + + and change: + {{{ + enabled=0 + }}} + + to: + {{{ + enabled=1 + }}} + + /!\ Even when enabled, apport will not upload crash reports to Launchpad for a stable release (see [[https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921|bug #994921]]). Instead, crash reports are uploaded to [[http://errors.ubuntu.com]]. To file a report on Launchpad anyway, one may open the following file via a command line: {{{ + gksudo gedit /etc/apport/crashdb.conf + }}} and change: {{{ + 'problem_types': ['Bug', 'Package'], + }}} to: {{{ + # 'problem_types': ['Bug', 'Package'], + }}} + Save, close, and try to file the crash report again via: {{{ + ubuntu-bug /var/crash/_my_crash_report.crash + }}} + + /!\ apport will appear to upload a crash report, but only actually does so if whoopsie is installed. Whoopsie is installed by default for users of ubuntu-desktop, but for users of alternative desktops, or for server users, whoopsie has to be installed manually with ''apt-get install whoopsie''. See [[https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1001630|bug #1001630]] for details. + + == Reporting a system crash == + + If your system lockups up, freezes, logs you out, etc., then this is not an application crash, but a system crash. Please see below, and consult the following article for these types of problems [[https://help.ubuntu.com/community/DebuggingSystemCrash]]. + + == Reporting non-crash hardware and desktop application bugs == + + The method for reporting bugs in Ubuntu is by using the tool “ubuntu-bug”, otherwise known as '''Apport'''. When reporting a bug, you must tell Apport which program or [[https://help.ubuntu.com/community/InstallingSoftware#What%20is%20a%20package?|package]] is at fault. + + === Collecting information from a specific package === + + Press Alt+F2 to open the “Run Command” screen: + + ||{{attachment:unity-ubuntu-bug-pkgname.png|Filing a bug with the “Run Command” screen}}|| + + Then, type `ubuntu-bug ` and press Enter. If you’re not sure which package has the problem, refer to the instructions for [[https://wiki.ubuntu.com/Bugs/FindRightPackage|finding the right package]]. + + === Collecting information about a program with a window open === + + If you want to file a bug about an application but you don't know what that application's package name is, if it has an open window you are in luck. + + In a terminal execute the command 'ubuntu-bug -w'. + + ||{{attachment:ubuntu-bug-w.png | terminal with ubuntu-bug -w }}|| + + After you close the dialog the next window that you click on will have a problem report created for the package that created the window. + + === Collecting information from a currently running program === + + To file a bug against a program that is currently running, open the System Monitor application and find the ID of the process. + + ||{{attachment:system-monitor-id-new.png | System Monitor Processes tab }}|| + + Then type "ubuntu-bug " followed by the process ID into the “Run Command” screen. + + ||{{attachment:unity-ubuntu-bug-pid.png | Filing a bug with the “Run Command” screen and a process ID}}|| + + == Filing a general bug against no particular package == + + If you’re not sure which package is affected by the bug, type `ubuntu-bug` in the “Run Command” screen and press Enter. This will guide you through a series of questions to gather more information about the bug and help you assign it to the appropriate package. + + [[#Top|Back to top]] + + == Complete the bug report filing process == + + After running one of the above commands, Apport (the Ubuntu bug reporter) will gather information about the bug. + + ||{{attachment:apport-1.png | Apport collecting information about the bug}}|| + + A window will then pop up, asking you if you want to report the bug. Click "Send Report" if you wish to proceed, or click "Content of the report" if you want to review the information Apport collected. + + ||{{attachment:apport-problem-report.png | Apport asking you to send the report}}|| + + Apport will then upload the problem information to Launchpad, and a new browser window will then open to inform you that the bug report is being processed. + + ||{{attachment:information-upload.png | Apport uploading the problem information}}|| + + ||{{attachment:process-data2.png | Launchpad processing the bug report data}}|| + + After the bug report data has been processed, a new page will open that will ask you for the bug report's title. The bug title will appear in all bug listings so make sure it represents the bug well. When you're done, click "Next". + + ||{{attachment:bug-title2.png | Launchpad asking for a bug title}}|| + + A search will then occur based on the title you gave to the bug report, and will show potentially similar ones. If one of these seems to be the exact bug you're reporting, click its title, then "Yes, this is the bug I'm trying to report". If not, click "No, I need to report a new bug". + + ||{{attachment:bug-search.png | Launchpad search results about the bug title}}|| + + Launchpad will then ask you for further information. It's important that you specify three things: + + 1. What you expected to happen + 1. What actually happened + 1. If possible, a minimal series of steps necessary to make it happen, where step 1 is "start the program" + + Fill in the description field with as much information as you can, it is better to have too much information in the description than not enough. + + ||{{attachment:more-informations2.png | Launchpad asking for further information}}|| + + At then bottom of the page, there are some extra options you can use to make your bug report more complete: + + * '''This bug is a security vulnerability:''' Please check this '''''only''''' if your bug report describes a behaviour that could be exploited to compromise your security or safety, as well as cause issues such as identity theft or "hi-jacking". + * '''Tags:''' You can add here [[http://wiki.ubuntu.com/Bugs/Tags|tags]] that pertain to your bug report. The predefined values should be left alone. + * '''Include an attachment:''' Using this option, you can add supporting attachments to explain or help others reproduce the bug. This might include a screenshot, a video capture of the problem or a sample document that triggers the fault. If necessary, additional attachments can be added after the bug is reported via '''Add a comment/attachment''' at the bottom of the page. Please check [[https://wiki.ubuntu.com/DebuggingProcedures]] for anything further information to provide. It is vital for developers to get this information, as it contains the minimum requirement information necessary for a developer to begin working on your bug. + * Please note that if one files a bug against the [[https://launchpad.net/ubuntu/+source/linux|linux]] kernel package, you do not need to add as an attachment the terminal command: + {{{ + lspci -vvnn + lspci -vnvn + }}} + + This is due to how [[Launchpad]] automatically generates this as an additional attachment. + + ||{{attachment:extra-options2.png | Launchpad presenting extra options}}|| + + When you're done, click "Submit bug report". + + = Tips and tricks = + + == Filing bugs when off-line == + + In the event that you have an issue with your Internet connection or want to file a bug for another system you can still do this using apport. + + First, on the target system, gather the information in a file: + + * For a bug report about a system crash:<
>`apport-cli -p` ''``'' `--save bug.crash` + * For a bug report about any other issue:<
>`apport-cli -f -p` ''``'' `--save bug.apport` + + You will need to answer a few questions, which will vary depending on which package the bug report is about. Relevant system information, including the package name, is then saved on the target system, in the current directory. The extension indicates if it is a crash report or another kind of report. If you decide to rename the report file, please keep the `.apport` or `.crash` extension. + + When the file is ready, copy it to the system you intend to use for filing the report. There you can then file the report:<
> + `ubuntu-bug -c` ''``'' + + /!\ 'ubuntu-bug -c x.crash' does not work for crash reports from stable Ubuntu releases (see [[#Stable_release|note about stable releases above]]). + + If this is to be added to an existing bug report, also use the -u option:<
> + `ubuntu-bug -c` ''``'' `-u` ''``'' + + You will need to answer a few questions, and a web browser will be launched to complete the bug report. Please do not attach the `.apport` or `.crash` file to the report, as this is not the same as performing the above mentioned steps. + + == Filing bugs at Launchpad.net == + + If for some reason you cannot file a bug using the ''Apport'' tool you can file one via [[https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect | Launchpad's own bug report form]]. When doing so it is best if you have determined which package it should be filed against. Read '[[http://wiki.ubuntu.com/Bugs/FindRightPackage|finding the right package]]' for guidance or use [[ http://launchpad.net/ubuntu/ | Launchpad's package search feature ]]. We don't recommend this method for most bug reports because they will likely be missing crucial information, use ubuntu-bug if you can! + + To file a bug against a specific package you can also use a URL like the following: + + `http://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect` + + where PACKAGENAME is the name of the source package about which you want to file the bug report. + + In the event that you want to request a piece of software be packaged for Ubuntu please follow the instructions in the [[ https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting%20a%20new%20package%20for%20Ubuntu | wiki ]]. + + == Crashes == + + If an application crashes, [[https://wiki.ubuntu.com/Apport|Apport]] will start automatically, raising an appropriate bug report for you to complete in Launchpad. This provides developers with rich debugging information that will make it easier to fix the problem. + + ||{{attachment:apport-1.png}}|| + + == Error: The launchpadlib Python module is not installed == + + If one gets the following error while trying to perform apport-collect: {{{ + ERROR: The launchpadlib Python module is not installed. This functionality + is not available. + }}} please install the following package: {{{ + sudo apt-get -y install python-launchpadlib + }}} + + === Package libreoffice not installed and no hook available, ignoring === + + If one attempts to apport-collect and gets the error message: {{{ + Package libreoffice not installed and no hook available, ignoring + }}} one has to install the following package: {{{ + sudo apt-get -y install libreoffice + }}} + + === Crash reports === + + If your attachment is a crash report (ex. found in directory /var/crash), please do not attach it to an existing report. Instead, file a new report via a terminal so that [[https://help.ubuntu.com/community/ApportRetracingService|Apport Retracing Service]] may process it: + {{{ + ubuntu-bug my_crash_report.crash + }}} + + === Non-crash userspace bugs === + + Sometimes it is useful to take a picture (with a camera or via PrtSc button), or [[https://help.ubuntu.com/community/Screencast|screencast]] of the problem to demonstrate how you reproduced it, what the bug specifically shows, and the impact it has. + + <> + + == Filing a translation bug == + + You should file a translation bug if you are experiencing one of the following issues: + + * Wrong translations or spelling mistakes for languages other than English in applications + * Errors in spellcheckers or language support + * A string from an application not available for translation in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] + * An application from the Ubuntu main repository not available for translation in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] + * A translation made in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] and not updated in the Ubuntu language packs + * A duplicate translation template (the same application can be translated in two different places) in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] + * A template/translation no longer used in Ubuntu and that should be disabled from [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] + In case of doubt, you can always [[http://wiki.ubuntu.com/Translations/Contact|contact the Translations team]]. + + All translation issues should be filed against the [[https://bugs.launchpad.net/ubuntu-translations | Ubuntu Translations project]]. From there the bugs will be triaged and assigned to the right person and package. + + [[#Top|Back to top]] + + = Getting advice = + + Still have doubts about the bug report filing process? You can ask someone on [[irc://irc.freenode.net/#ubuntu-bugs|#ubuntu-bugs]] on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server or on the [[https://lists.ubuntu.com/mailman/listinfo/Ubuntu-bugsquad|bugsquad mailing list]]. + + [[#Top|Back to top]] = Bug reporting etiquette = @@ -43, +300 @@ * '''Please do not solicit non-original reporters to post comments, attachments, etc.''' * '''Please do not attach anything to another persons report.''' <
> Adding undesired attachments when not asked by a triager or developer creates spammy E-Mail traffic for those subscribed, clutters up the bug report with undesired attachments, and hinders the bug getting addressed quickly. As well, your attachments are subject to deletion at the discretion of developers and triagers. - = How to report bugs = - - Ubuntu uses [[Launchpad]] to keep track of bugs and their fixes. This page will guide you through the steps required to file a good and detailed report. - - == Create a Launchpad account == - - If you don’t already have one - you need to [[https://help.launchpad.net/YourAccount/NewAccount|create a Launchpad account]]. This will allow you to file new bugs and comment on existing ones. - - == Determine if the bug is really a bug == - - You should not file a bug if you are: - - * '''Requesting new software:''' you should follow the guidelines at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages - * '''Requesting support:''' there are a multitude of ways you can get help using Ubuntu, such as the [[https://answers.launchpad.net/ubuntu|Launchpad answer tracker]], the [[http://askubuntu.com/|Ask Ubuntu]] site, the [[http://www.ubuntuforums.org/|Ubuntu forums]], the [[irc://irc.freenode.net/#ubuntu|#ubuntu]] channel on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server, and the [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-users|ubuntu-users]] mailing list. - * '''Discussing features and existing policy:''' this belongs to the [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss|ubuntu-devel-discuss]] mailing list. - * '''Proposing features and ideas:''' you should submit your idea to the [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss|ubuntu-devel-discuss]] mailing list. - * '''Filing a bug against a program not provided by an Ubuntu package:''' You should file a bug in that program's bug tracking interface. Instructions are generally available on the program's web site. - - /!\ If you want to file a translation or misspelling bug, follow the instructions [[#translation|here]]. - - == Perform a survey of your problem == - - First, check the release notes for your version of Ubuntu: - * [[http://www.ubuntu.com/getubuntu/releasenotes/1004|Ubuntu 10.04 LTS (Lucid Lynx)]] - * [[http://www.ubuntu.com/getubuntu/releasenotes/1204|Ubuntu 12.04 LTS (Precise Pangolin)]] - * [[https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues|Ubuntu 14.04 (Trusty Tahr)]] <
> - Second, check Launchpad for any duplicates, and make note of this. - - === Desktop Applications === - - For [[https://wiki.ubuntu.com/DebuggingProcedures#Desktop_Applications|desktop applications]], if you find an already reported bug that is exactly like the problem you have, please feel free to add this information to the existing report, rather than opening a new one. However, if you have any doubt as to it being the same or not, please file a separate report. - - [[#Top|Back to top]] - - == Reporting an application crash in the development release == - - Please report an application crash via the methods outlined below and at [[https://wiki.ubuntu.com/DebuggingProgramCrash]]. - - If an application crashes, and you're using a development release, Apport should start automatically, raising an appropriate bug report for you to complete in Launchpad. This report is subsequently processed by [[Apport Retracing Service]], in order to provide developers with debugging information that make it easier to fix the problem. - - == Reporting an application crash in the stable release == - - Apport may come disabled by default. To enable it, edit the file: - {{{ - /etc/default/apport - }}} - - and change: - {{{ - enabled=0 - }}} - - to: - {{{ - enabled=1 - }}} - - /!\ Even when enabled, apport will not upload crash reports to Launchpad for a stable release (see [[https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921|bug #994921]]). Instead, crash reports are uploaded to [[http://errors.ubuntu.com]]. To file a report on Launchpad anyway, one may open the following file via a command line: {{{ - gksudo gedit /etc/apport/crashdb.conf - }}} and change: {{{ - 'problem_types': ['Bug', 'Package'], - }}} to: {{{ - # 'problem_types': ['Bug', 'Package'], - }}} - Save, close, and try to file the crash report again via: {{{ - ubuntu-bug /var/crash/_my_crash_report.crash - }}} - - /!\ apport will appear to upload a crash report, but only actually does so if whoopsie is installed. Whoopsie is installed by default for users of ubuntu-desktop, but for users of alternative desktops, or for server users, whoopsie has to be installed manually with ''apt-get install whoopsie''. See [[https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1001630|bug #1001630]] for details. - - == Reporting a system crash == - - If your system lockups up, freezes, logs you out, etc., then this is not an application crash, but a system crash. Please see below, and consult the following article for these types of problems [[https://help.ubuntu.com/community/DebuggingSystemCrash]]. - - == Reporting non-crash hardware and desktop application bugs == - - The method for reporting bugs in Ubuntu is by using the tool “ubuntu-bug”, otherwise known as '''Apport'''. When reporting a bug, you must tell Apport which program or [[https://help.ubuntu.com/community/InstallingSoftware#What%20is%20a%20package?|package]] is at fault. - - === Collecting information from a specific package === - - Press Alt+F2 to open the “Run Command” screen: - - ||{{attachment:unity-ubuntu-bug-pkgname.png|Filing a bug with the “Run Command” screen}}|| - - Then, type `ubuntu-bug ` and press Enter. If you’re not sure which package has the problem, refer to the instructions for [[https://wiki.ubuntu.com/Bugs/FindRightPackage|finding the right package]]. - - === Collecting information about a program with a window open === - - If you want to file a bug about an application but you don't know what that application's package name is, if it has an open window you are in luck. - - In a terminal execute the command 'ubuntu-bug -w'. - - ||{{attachment:ubuntu-bug-w.png | terminal with ubuntu-bug -w }}|| - - After you close the dialog the next window that you click on will have a problem report created for the package that created the window. - - === Collecting information from a currently running program === - - To file a bug against a program that is currently running, open the System Monitor application and find the ID of the process. - - ||{{attachment:system-monitor-id-new.png | System Monitor Processes tab }}|| - - Then type "ubuntu-bug " followed by the process ID into the “Run Command” screen. - - ||{{attachment:unity-ubuntu-bug-pid.png | Filing a bug with the “Run Command” screen and a process ID}}|| - - == Filing a general bug against no particular package == - - If you’re not sure which package is affected by the bug, type `ubuntu-bug` in the “Run Command” screen and press Enter. This will guide you through a series of questions to gather more information about the bug and help you assign it to the appropriate package. - - [[#Top|Back to top]] - - == Complete the bug report filing process == - - After running one of the above commands, Apport (the Ubuntu bug reporter) will gather information about the bug. - - ||{{attachment:apport-1.png | Apport collecting information about the bug}}|| - - A window will then pop up, asking you if you want to report the bug. Click "Send Report" if you wish to proceed, or click "Content of the report" if you want to review the information Apport collected. - - ||{{attachment:apport-problem-report.png | Apport asking you to send the report}}|| - - Apport will then upload the problem information to Launchpad, and a new browser window will then open to inform you that the bug report is being processed. - - ||{{attachment:information-upload.png | Apport uploading the problem information}}|| - - ||{{attachment:process-data2.png | Launchpad processing the bug report data}}|| - - After the bug report data has been processed, a new page will open that will ask you for the bug report's title. The bug title will appear in all bug listings so make sure it represents the bug well. When you're done, click "Next". - - ||{{attachment:bug-title2.png | Launchpad asking for a bug title}}|| - - A search will then occur based on the title you gave to the bug report, and will show potentially similar ones. If one of these seems to be the exact bug you're reporting, click its title, then "Yes, this is the bug I'm trying to report". If not, click "No, I need to report a new bug". - - ||{{attachment:bug-search.png | Launchpad search results about the bug title}}|| - - Launchpad will then ask you for further information. It's important that you specify three things: - - 1. What you expected to happen - 1. What actually happened - 1. If possible, a minimal series of steps necessary to make it happen, where step 1 is "start the program" - - Fill in the description field with as much information as you can, it is better to have too much information in the description than not enough. - - ||{{attachment:more-informations2.png | Launchpad asking for further information}}|| - - At then bottom of the page, there are some extra options you can use to make your bug report more complete: - - * '''This bug is a security vulnerability:''' Please check this '''''only''''' if your bug report describes a behaviour that could be exploited to compromise your security or safety, as well as cause issues such as identity theft or "hi-jacking". - * '''Tags:''' You can add here [[http://wiki.ubuntu.com/Bugs/Tags|tags]] that pertain to your bug report. The predefined values should be left alone. - * '''Include an attachment:''' Using this option, you can add supporting attachments to explain or help others reproduce the bug. This might include a screenshot, a video capture of the problem or a sample document that triggers the fault. If necessary, additional attachments can be added after the bug is reported via '''Add a comment/attachment''' at the bottom of the page. Please check [[https://wiki.ubuntu.com/DebuggingProcedures]] for anything further information to provide. It is vital for developers to get this information, as it contains the minimum requirement information necessary for a developer to begin working on your bug. - * Please note that if one files a bug against the [[https://launchpad.net/ubuntu/+source/linux|linux]] kernel package, you do not need to add as an attachment the terminal command: - {{{ - lspci -vvnn - lspci -vnvn - }}} - - This is due to how [[Launchpad]] automatically generates this as an additional attachment. - - ||{{attachment:extra-options2.png | Launchpad presenting extra options}}|| - - When you're done, click "Submit bug report". - - = Tips and tricks = - - == Filing bugs when off-line == - - In the event that you have an issue with your Internet connection or want to file a bug for another system you can still do this using apport. - - First, on the target system, gather the information in a file: - - * For a bug report about a system crash:<
>`apport-cli -p` ''``'' `--save bug.crash` - * For a bug report about any other issue:<
>`apport-cli -f -p` ''``'' `--save bug.apport` - - You will need to answer a few questions, which will vary depending on which package the bug report is about. Relevant system information, including the package name, is then saved on the target system, in the current directory. The extension indicates if it is a crash report or another kind of report. If you decide to rename the report file, please keep the `.apport` or `.crash` extension. - - When the file is ready, copy it to the system you intend to use for filing the report. There you can then file the report:<
> - `ubuntu-bug -c` ''``'' - - /!\ 'ubuntu-bug -c x.crash' does not work for crash reports from stable Ubuntu releases (see [[#Stable_release|note about stable releases above]]). - - If this is to be added to an existing bug report, also use the -u option:<
> - `ubuntu-bug -c` ''``'' `-u` ''``'' - - You will need to answer a few questions, and a web browser will be launched to complete the bug report. Please do not attach the `.apport` or `.crash` file to the report, as this is not the same as performing the above mentioned steps. - - == Filing bugs at Launchpad.net == - - If for some reason you cannot file a bug using the ''Apport'' tool you can file one via [[https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect | Launchpad's own bug report form]]. When doing so it is best if you have determined which package it should be filed against. Read '[[http://wiki.ubuntu.com/Bugs/FindRightPackage|finding the right package]]' for guidance or use [[ http://launchpad.net/ubuntu/ | Launchpad's package search feature ]]. We don't recommend this method for most bug reports because they will likely be missing crucial information, use ubuntu-bug if you can! - - To file a bug against a specific package you can also use a URL like the following: - - `http://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect` - - where PACKAGENAME is the name of the source package about which you want to file the bug report. - - In the event that you want to request a piece of software be packaged for Ubuntu please follow the instructions in the [[ https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting%20a%20new%20package%20for%20Ubuntu | wiki ]]. - - == Crashes == - - If an application crashes, [[https://wiki.ubuntu.com/Apport|Apport]] will start automatically, raising an appropriate bug report for you to complete in Launchpad. This provides developers with rich debugging information that will make it easier to fix the problem. - - ||{{attachment:apport-1.png}}|| - - == Error: The launchpadlib Python module is not installed == - - If one gets the following error while trying to perform apport-collect: {{{ - ERROR: The launchpadlib Python module is not installed. This functionality - is not available. - }}} please install the following package: {{{ - sudo apt-get -y install python-launchpadlib - }}} - - === Package libreoffice not installed and no hook available, ignoring === - - If one attempts to apport-collect and gets the error message: {{{ - Package libreoffice not installed and no hook available, ignoring - }}} one has to install the following package: {{{ - sudo apt-get -y install libreoffice - }}} - - === Crash reports === - - If your attachment is a crash report (ex. found in directory /var/crash), please do not attach it to an existing report. Instead, file a new report via a terminal so that [[https://help.ubuntu.com/community/ApportRetracingService|Apport Retracing Service]] may process it: - {{{ - ubuntu-bug my_crash_report.crash - }}} - - === Non-crash userspace bugs === - - Sometimes it is useful to take a picture (with a camera or via PrtSc button), or [[https://help.ubuntu.com/community/Screencast|screencast]] of the problem to demonstrate how you reproduced it, what the bug specifically shows, and the impact it has. - - <> - - == Filing a translation bug == - - You should file a translation bug if you are experiencing one of the following issues: - - * Wrong translations or spelling mistakes for languages other than English in applications - * Errors in spellcheckers or language support - * A string from an application not available for translation in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] - * An application from the Ubuntu main repository not available for translation in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] - * A translation made in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] and not updated in the Ubuntu language packs - * A duplicate translation template (the same application can be translated in two different places) in [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] - * A template/translation no longer used in Ubuntu and that should be disabled from [[http://translations.launchpad.net/ubuntu|Launchpad Translations]] - In case of doubt, you can always [[http://wiki.ubuntu.com/Translations/Contact|contact the Translations team]]. - - All translation issues should be filed against the [[https://bugs.launchpad.net/ubuntu-translations | Ubuntu Translations project]]. From there the bugs will be triaged and assigned to the right person and package. - - [[#Top|Back to top]] - - = Getting advice = - - Still have doubts about the bug report filing process? You can ask someone on [[irc://irc.freenode.net/#ubuntu-bugs|#ubuntu-bugs]] on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server or on the [[https://lists.ubuntu.com/mailman/listinfo/Ubuntu-bugsquad|bugsquad mailing list]]. - - [[#Top|Back to top]] = Other languages = From es20490446e at gmail.com Wed Nov 19 16:04:35 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 19 Nov 2014 17:04:35 +0100 Subject: What if users warned about critical bugs? In-Reply-To: <5460147B.3010001@gmail.com> References: <5460147B.3010001@gmail.com> Message-ID: <546CBF93.2020607@gmail.com> Alberto Salvia Novella: > Perhaps asking users in documentation to mail the Ubuntu Bug Control > team when they find a critical bug would be a good idea. Added as . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From webmaster at ubuntu.com Wed Nov 19 16:03:04 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Wed, 19 Nov 2014 16:03:04 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_es20?= =?utf-8?q?490446e?= Message-ID: <20141119160304.28044.13059@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Help Wiki" for change notification. The "ReportingBugs" page has been changed by es20490446e: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=271&rev2=272 ||<>|| + = How to report bugs = Ubuntu uses [[Launchpad]] to keep track of bugs and their fixes. This page will guide you through the steps required to file a good and detailed report. + == Create a Launchpad account == If you don’t already have one - you need to [[https://help.launchpad.net/YourAccount/NewAccount|create a Launchpad account]]. This will allow you to file new bugs and comment on existing ones. + == Determine if the bug is really a bug == @@ -26, +29 @@ * '''Filing a bug against a program not provided by an Ubuntu package:''' You should file a bug in that program's bug tracking interface. Instructions are generally available on the program's web site. /!\ If you want to file a translation or misspelling bug, follow the instructions [[#translation|here]]. - + + == Perform a survey of your problem == First, check the release notes for your version of Ubuntu: @@ -34, +38 @@ * [[http://www.ubuntu.com/getubuntu/releasenotes/1204|Ubuntu 12.04 LTS (Precise Pangolin)]] * [[https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues|Ubuntu 14.04 (Trusty Tahr)]] <
> Second, check Launchpad for any duplicates, and make note of this. - + + === Desktop Applications === For [[https://wiki.ubuntu.com/DebuggingProcedures#Desktop_Applications|desktop applications]], if you find an already reported bug that is exactly like the problem you have, please feel free to add this information to the existing report, rather than opening a new one. However, if you have any doubt as to it being the same or not, please file a separate report. [[#Top|Back to top]] + == Reporting an application crash in the development release == Please report an application crash via the methods outlined below and at [[https://wiki.ubuntu.com/DebuggingProgramCrash]]. If an application crashes, and you're using a development release, Apport should start automatically, raising an appropriate bug report for you to complete in Launchpad. This report is subsequently processed by [[Apport Retracing Service]], in order to provide developers with debugging information that make it easier to fix the problem. + == Reporting an application crash in the stable release == @@ -77, +84 @@ /!\ apport will appear to upload a crash report, but only actually does so if whoopsie is installed. Whoopsie is installed by default for users of ubuntu-desktop, but for users of alternative desktops, or for server users, whoopsie has to be installed manually with ''apt-get install whoopsie''. See [[https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1001630|bug #1001630]] for details. + == Reporting a system crash == If your system lockups up, freezes, logs you out, etc., then this is not an application crash, but a system crash. Please see below, and consult the following article for these types of problems [[https://help.ubuntu.com/community/DebuggingSystemCrash]]. + == Reporting non-crash hardware and desktop application bugs == The method for reporting bugs in Ubuntu is by using the tool “ubuntu-bug”, otherwise known as '''Apport'''. When reporting a bug, you must tell Apport which program or [[https://help.ubuntu.com/community/InstallingSoftware#What%20is%20a%20package?|package]] is at fault. + === Collecting information from a specific package === @@ -93, +103 @@ Then, type `ubuntu-bug ` and press Enter. If you’re not sure which package has the problem, refer to the instructions for [[https://wiki.ubuntu.com/Bugs/FindRightPackage|finding the right package]]. + === Collecting information about a program with a window open === If you want to file a bug about an application but you don't know what that application's package name is, if it has an open window you are in luck. @@ -103, +114 @@ After you close the dialog the next window that you click on will have a problem report created for the package that created the window. + === Collecting information from a currently running program === To file a bug against a program that is currently running, open the System Monitor application and find the ID of the process. @@ -113, +125 @@ ||{{attachment:unity-ubuntu-bug-pid.png | Filing a bug with the “Run Command” screen and a process ID}}|| + == Filing a general bug against no particular package == If you’re not sure which package is affected by the bug, type `ubuntu-bug` in the “Run Command” screen and press Enter. This will guide you through a series of questions to gather more information about the bug and help you assign it to the appropriate package. [[#Top|Back to top]] + == Complete the bug report filing process == @@ -170, +184 @@ When you're done, click "Submit bug report". + + == Warn about a critical bug == + + If the bug you just reported causes '''data corruption''' or renders the system temporally or permanently '''unusable''', please [[mailto:Ubuntu Bug Control team ?subject=Please, set this bug importance as critical|warn the Ubuntu Bug Control team]] about it. + + = Tips and tricks = == Filing bugs when off-line == @@ -193, +213 @@ You will need to answer a few questions, and a web browser will be launched to complete the bug report. Please do not attach the `.apport` or `.crash` file to the report, as this is not the same as performing the above mentioned steps. + == Filing bugs at Launchpad.net == If for some reason you cannot file a bug using the ''Apport'' tool you can file one via [[https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect | Launchpad's own bug report form]]. When doing so it is best if you have determined which package it should be filed against. Read '[[http://wiki.ubuntu.com/Bugs/FindRightPackage|finding the right package]]' for guidance or use [[ http://launchpad.net/ubuntu/ | Launchpad's package search feature ]]. We don't recommend this method for most bug reports because they will likely be missing crucial information, use ubuntu-bug if you can! @@ -205, +226 @@ In the event that you want to request a piece of software be packaged for Ubuntu please follow the instructions in the [[ https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting%20a%20new%20package%20for%20Ubuntu | wiki ]]. + == Crashes == If an application crashes, [[https://wiki.ubuntu.com/Apport|Apport]] will start automatically, raising an appropriate bug report for you to complete in Launchpad. This provides developers with rich debugging information that will make it easier to fix the problem. ||{{attachment:apport-1.png}}|| + == Error: The launchpadlib Python module is not installed == @@ -220, +243 @@ sudo apt-get -y install python-launchpadlib }}} + === Package libreoffice not installed and no hook available, ignoring === If one attempts to apport-collect and gets the error message: {{{ @@ -228, +252 @@ sudo apt-get -y install libreoffice }}} + === Crash reports === If your attachment is a crash report (ex. found in directory /var/crash), please do not attach it to an existing report. Instead, file a new report via a terminal so that [[https://help.ubuntu.com/community/ApportRetracingService|Apport Retracing Service]] may process it: @@ -235, +260 @@ ubuntu-bug my_crash_report.crash }}} + === Non-crash userspace bugs === Sometimes it is useful to take a picture (with a camera or via PrtSc button), or [[https://help.ubuntu.com/community/Screencast|screencast]] of the problem to demonstrate how you reproduced it, what the bug specifically shows, and the impact it has. <> + == Filing a translation bug == @@ -258, +285 @@ [[#Top|Back to top]] + = Getting advice = Still have doubts about the bug report filing process? You can ask someone on [[irc://irc.freenode.net/#ubuntu-bugs|#ubuntu-bugs]] on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server or on the [[https://lists.ubuntu.com/mailman/listinfo/Ubuntu-bugsquad|bugsquad mailing list]]. [[#Top|Back to top]] + = Bug reporting etiquette = Thank you for reading this article. This will guide you on how best to present your bug report so that it gets addressed as soon as possible. While this is targeted to the new bug reporter, experienced reporters would find these tips invaluable in getting their bugs looked at by a developer and ultimately fixed. + == All bug reports == @@ -291, +321 @@ * '''Please check to see if you problem is a regression.''' <
> If your bug is a regression, it is most helpful to have it bisected. If it is a linux kernel issue, one would consult the article on [[https://wiki.ubuntu.com/Kernel/KernelBisection|bisection]]. Report your bisect results in the report. * '''Please do not run apport-collect more than once per release tested.''' <
> For example, if you originally reported a bug in Trusty via Apport, and then could reproduce it in Utopic, only run apport-collect once in Trusty. This minimizes unnecessary E-Mail traffic to those subscribed to your report and keeps the report efficient. + == Hardware bug reports (linux kernel, xorg, sound, etc.) == * '''Before filing your report, please update your BIOS, and hardware firmware (CF card readers, SSDs, USB 3.0 controllers, DVD/CD drives, external USB drives, etc.) to the newest available from your vendor.''' <
> Outdated and buggy BIOS and firmware is a common cause of a variety of hardware issues (ex. freezing after lightDM login, intermittent wireless, suspend/hibernate not working, intermittent touchpad, certain keys on keyboard not working correctly, card readers not working, and kernel panics after plugging USB drive in). Also, please don't make the invalid argument that because it works in Windows, but doesn't in linux, this isn't caused by an outdated BIOS. This is due to how buggy BIOS problems may manifest themselves in linux, but not in Windows, and vice versa. As well, because BIOS vendors typically test to Windows only and make release notes commenting on results to it, it wouldn't advise on if a problem in linux is resolved by it. Hence, one should update anyways, even if your problem isn't specifically mentioned. In addition, BIOS updates are for collateral damage avoidance. For more about BIOS updates, please see [[https://help.ubuntu.com/community/BiosUpdate|here]]. @@ -311, +342 @@ * [[https://help.ubuntu.com/community/ReportingBugs_de|Deutsch]] [[#Top|Back to top]] + = See Also = * Netiquette Guidelines - [[http://www.ietf.org/rfc/rfc1855.txt]] From es20490446e at gmail.com Thu Nov 20 18:47:00 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 20 Nov 2014 19:47:00 +0100 Subject: What if users warned about critical bugs? In-Reply-To: <20141120150046.GC5279@murraytwins.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <20141120150046.GC5279@murraytwins.com> Message-ID: <546E3724.5030307@gmail.com> Brian Murray: > I think this is a false assumption, in that the people setting the bug's > importance to critical know the definition of critical and are able to > independently judge the bug's importance. Some Launchpad user reporting > or experiencing the bug report is much more likely to think their bug > report is critical. Subsequently, I think your numbers are quite low and > optimistic. > > Another consideration is that the Ubuntu Bug Control mailing list is > moderated so any emails sent to it will need to be approved by an > administrator. I'd like it if a different system were used. Perhaps we could direct those warnings to me for a while, collect metrics, and decide on those. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From es20490446e at gmail.com Thu Nov 20 21:44:01 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 20 Nov 2014 22:44:01 +0100 Subject: What if users warned about critical bugs? In-Reply-To: <20141120105845.c2548845d10cbc839270b5b0@gmail.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <20141120150046.GC5279@murraytwins.com> <546E3724.5030307@gmail.com> <20141120105845.c2548845d10cbc839270b5b0@gmail.com> Message-ID: <546E60A1.7030201@gmail.com> Brendan Perrine: > I don't think pinging Brian Murray or other bug squad admins would be > good if it ends up someone thinks ubiquity is broken when it was a bad > burn or dd of an iso or bad md5sum.This is what the iso testing > tracker is for. Better to shade these details after having metrics on hand. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From es20490446e at gmail.com Fri Nov 21 03:14:14 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Fri, 21 Nov 2014 04:14:14 +0100 Subject: What if users warned about critical bugs? In-Reply-To: <546E9DA0.4050606@ubuntu.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <20141120150046.GC5279@murraytwins.com> <546E9DA0.4050606@ubuntu.com> Message-ID: <546EAE06.5030108@gmail.com> C de-Avillez: > I will try to stress the above a bit more: users in general will always > assume their bug is high/critical (it is, by definition, affecting their > work!). > > We did have it, sort of, on for a while -- and we found that importance > would have to be controlled. We used to spend a nice amount of time > correcting importance. Samewise with moving to triaged, or fix released, > or wontfix. What do you see when you look at ? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From hggdh2 at ubuntu.com Fri Nov 21 16:20:35 2014 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Fri, 21 Nov 2014 10:20:35 -0600 Subject: What if users warned about critical bugs? In-Reply-To: <546EAE06.5030108@gmail.com> References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <20141120150046.GC5279@murraytwins.com> <546E9DA0.4050606@ubuntu.com> <546EAE06.5030108@gmail.com> Message-ID: On Thu, Nov 20, 2014 at 9:14 PM, Alberto Salvia Novella wrote: > C de-Avillez: >> >> I will try to stress the above a bit more: users in general will always >> assume their bug is high/critical (it is, by definition, affecting their >> work!). >> >> We did have it, sort of, on for a while -- and we found that importance >> would have to be controlled. We used to spend a nice amount of time >> correcting importance. Samewise with moving to triaged, or fix released, >> or wontfix. > > > What do you see when you look at ? I am pretty sure I know the definitions for importance values but, anyway, thank you for pointing them to me. This, on the other hand, does not explain or justify giving end-users access to setting importance (or even understanding how to set it). Our experience on Ubuntu, and my personal experience when doing support work professionally, still shows me that end-users should not have access to importance, as implemented in LP. So, even if we are to allow end-users (the original posters) to email BugControl stating a bug is critical -- but *NOT* changing importance directly -- I have serious doubts about how effective it will be. This would be different if LP supported user-view of importance and impact *separate* from bug importance as seen by the technical resource -- developer or triager. But it does not. Going on. We can try, perhaps by setting a new ML for that. But definitely NOT by having the OP email BugControl. We can then verify how much overhead it will be. At least for the beginning, I do not expect many emails, but that might change as this new channel gets to be known. From es20490446e at gmail.com Fri Nov 21 23:33:32 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sat, 22 Nov 2014 00:33:32 +0100 Subject: What if users warned about critical bugs? In-Reply-To: References: <5460147B.3010001@gmail.com> <4119DC42-DE2A-4F11-9731-6E886D7FFF48@trekweb.org> <5460E3C8.1030003@gmail.com> <20141120150046.GC5279@murraytwins.com> <546E9DA0.4050606@ubuntu.com> <546EAE06.5030108@gmail.com> Message-ID: <546FCBCC.2090100@gmail.com> Alberto Salvia Novella: > What do you see when you look at ? C de-Avillez: > I am pretty sure I know the definitions for importance values but, > anyway, thank you for pointing them to me. What I mean is if you feel that users could tell which the appropriate importance is by reading . C de-Avillez: > Our experience on Ubuntu, and my personal experience when doing > support work professionally, still shows me that end-users should not > have access to importance, as implemented in LP. It could be, but it would be nice testing with an interface whose descriptions are concise for anyone. C de-Avillez: > So, even if we are to allow end-users (the original posters) to email > BugControl stating a bug is critical -- but*NOT* changing importance > directly -- I have serious doubts about how effective it will be. It depends on how much false positives there will be. Alberto Salvia Novella: > We can try, perhaps by setting a new ML for that. But > definitely NOT by having the OP email BugControl. I think we will be able to decide this better after having some metrics, as it isn't the same moderating 1 mail a month or 25. C de-Avillez: > We can then verify how much overhead it will be. Better to test first with a personal email, so we can omit setting up all that infrastructure with the risk of jumping it later on. C de-Avillez: > At least for the beginning, I do not expect many emails, but that > might change as this new channel gets to be known. We can take metrics till, for example, some weeks after Ubuntu 14.10 has been released; when users usually report the greatest quantity of bugs. Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3748 bytes Desc: S/MIME Cryptographic Signature URL: From webmaster at ubuntu.com Mon Nov 24 04:25:15 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Mon, 24 Nov 2014 04:25:15 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141124042515.20859.58233@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Help Wiki" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=274&rev2=275 Comment: 1) Added support note on headless system. 2) Re-worded intro paragraph to etiquette as it was out of place now that it's been moved. = Tips and tricks = - == Filing bugs when off-line == + == Filing bugs when offline or using a headless setup == - In the event that you have an issue with your Internet connection or want to file a bug for another system you can still do this using apport. + In the event that you have an issue with your internet connection, want to file a bug for another system, or have trouble reporting from a headless setup, you can still do this using apport. First, on the target system, gather the information in a file: @@ -286, +286 @@ [[#Top|Back to top]] - = Getting advice = - - Still have doubts about the bug report filing process? You can ask someone on [[irc://irc.freenode.net/#ubuntu-bugs|#ubuntu-bugs]] on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server or on the [[https://lists.ubuntu.com/mailman/listinfo/Ubuntu-bugsquad|bugsquad mailing list]]. - - [[#Top|Back to top]] - - = Bug reporting etiquette = + Following bug reporting etiquette best presents your Launchpad report so that it gets addressed as soon as possible. As well, it minimizes unnecessary pain points for developers, triagers, and original reporters. - Thank you for reading this article. This will guide you on how best to present your bug report so that it gets addressed as soon as possible. While this is targeted to the new bug reporter, experienced reporters would find these tips invaluable in getting their bugs looked at by a developer and ultimately fixed. - == All bug reports == @@ -305, +297 @@ * '''Please do not complain because someone sent what one perceives to be a automated or "canned" response'''. <
> If the response is asking you to do something that you have't done (ex. test the latest development release, file a new report, etc.) do it, as it would get you closer to having your bug fixed faster. Complaining about this is inconsiderate of the Ubuntu triagers and developers who are saving time in comparison to hand typing every single character in an e-mail that goes out their inbox. * '''Please test the latest version of the package that is considered responsible for the problem.''' <
> For bugs in the [[https://launchpad.net/ubuntu/+source/linux|Linux (Ubuntu)]] package, unless the upstream maintainer or kernel developer notes otherwise, if a new mainline kernel comes out, and you haven't tested with it, you run the strong risk of it not being attended to upstream. * '''Please do not post comments such as “Me too!”, “+1”, “bump”, “same here”, etc.''', as it is largely unhelpful, produces spammy e-mail traffic to everyone subscribed to the report, and quite often turns out not to be the same root cause. Instead, please follow the below mentioned procedures. - * '''Please do not post URLs of requested information.''' <
> For example, links to pastebin.com, paste.ubuntu.com, dropbox.com, etc. If a triager or developer asks you for some information on reproducing or testing, please do not make them dumpster dive by just posting a URL, or saying you already did something in some other report. Instead, put the full reproduction or testing results into the report itself, and if you have to, then post the link. + * '''Please do not post URLs of requested information.''' <
> For example, links to pastebin.com, paste.ubuntu.com, dropbox.com, etc. If a triager or developer asks you for some information on reproducing or testing, please do not make them dumpster dive by just posting a URL, or saying you already did something in some other report. Instead, put the full reproduction or testing results into the report itself, uncompressed and untarred, and if you have to, then post the link. * '''Please do not stack multiple issues into one report'''. <
> For example, jamming suspend and hibernate into one report, reporting multiple [[https://wiki.ubuntu.com/Hotkeys/Troubleshooting|hotkey]] problems into one report (ex. Fn+F3 doesn't turn off my laptop WiFi, Fn+Right doesn't turn the brightness on my [[https://wiki.ubuntu.com/Kernel/Debugging/Backlight|backlight]] down, my brightness settings are not remembered after reboot, etc.). Please make one report for each individual problem. * '''Please do not complain about how long it takes to fix a bug.''' <
> This goes along with saying things like severity of your bug is high so it should be fixed immediately, “I cannot believe it’s not fixed…”, XYZ person(s) do not care about fixing bugs, etc. Especially, if you have not followed the directions mentioned in this article, let alone contributed code upstream. This type of behavior is unconstructive, irritating to others who read your e-mail, and spammy. We all want to see every bug fixed as soon as possible! Naturally, bugs being fixed is limited to reproducibility and clarity of the bug report, the actual impact the bug has on the community, and available developer resources. * '''Please keep the bug report as objective as possible.''' <
> It is desired for you to provide a fact based, technical impact statement on you, your environment, and the potential or actual impact on the community at large. @@ -331, +323 @@ * '''Please do not solicit non-original reporters to post comments, attachments, etc.''' * '''Please do not attach anything to another persons report.''' <
> Adding undesired attachments when not asked by a triager or developer creates spammy E-Mail traffic for those subscribed, clutters up the bug report with undesired attachments, and hinders the bug getting addressed quickly. As well, your attachments are subject to deletion at the discretion of developers and triagers. + = Getting advice = + + Still have doubts about the bug report filing process? You can ask someone on [[irc://irc.freenode.net/#ubuntu-bugs|#ubuntu-bugs]] on the [[https://help.ubuntu.com/community/InternetRelayChat|Freenode IRC]] server or on the [[https://lists.ubuntu.com/mailman/listinfo/Ubuntu-bugsquad|bugsquad mailing list]]. + + [[#Top|Back to top]] = Other languages = From webmaster at ubuntu.com Thu Nov 20 19:00:28 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Thu, 20 Nov 2014 19:00:28 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_es20?= =?utf-8?q?490446e?= Message-ID: <20141120190028.12369.277@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Help Wiki" for change notification. The "ReportingBugs" page has been changed by es20490446e: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=272&rev2=273 == Warn about a critical bug == - If the bug you just reported causes '''data corruption''' or renders the system temporally or permanently '''unusable''', please [[mailto:Ubuntu Bug Control team ?subject=Please, set this bug importance as critical|warn the Ubuntu Bug Control team]] about it. + If the bug you just reported causes '''data corruption''' or renders the system temporally or permanently '''unusable''', please [[mailto:Alberto Salvia Novella ?subject=Please, set this bug importance as critical|warn about it]]. = Tips and tricks = From noreply at ubuntu.com Sun Nov 30 12:53:03 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 30 Nov 2014 12:53:03 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingPrintingProblems=22_by_?= =?utf-8?q?pascal-devuyst?= Message-ID: <20141130125303.30216.58542@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingPrintingProblems" page has been changed by pascal-devuyst: http://wiki.ubuntu.com/DebuggingPrintingProblems?action=diff&rev1=94&rev2=95 If a print job fails, a job viewer with the failed job ("Stopped" state) and pop-up window telling that the job has problems will appear. If you click the "Diagnose" button, the troubleshooting wizard will open. Do not delete the job before having completed the wizard. Take care to choose the printer with which the problem occured. In the "Test Page" step you do not need to print anything, nor to wait. Mark the stopped job in the integrated job viewer, click "No" at the question and then "Forward". After that save the file and attach it to the bug report. = AppArmor Protection of the printing system = - From Gutsy on the security of the CUPS printing system is improved by using App``Armor. Unfortunately, the configuration is not perfect yet, especially if third-party printer drivers are used. If you have any problems with printing, try deactivating the App``Armor protection with {{{sudo aa-complain cupsd}}}. If this helps, look for messages containing '''audit''' in the {{{/var/log/messages}}} file. These show which components are accessed by the printing system for which there is no explicit permission given in {{{/etc/apparmor.d/usr.sbin.cupsd}}}. You can re-activate App``Armor via {{{sudo aa-enforce cupsd}}}. Report a bug to the package '''cups''', so that we can correct the default configuration of App``Armor. + From Gutsy on the security of the CUPS printing system is improved by using App``Armor. Unfortunately, the configuration is not perfect yet, especially if third-party printer drivers are used. First make sure the apparmor-utils package is installed. If you have any problems with printing, try deactivating the App``Armor protection with {{{sudo aa-complain cupsd}}}. If this helps, look for messages containing '''audit''' in the {{{/var/log/syslog}}} file. These show which components are accessed by the printing system for which there is no explicit permission given in {{{/etc/apparmor.d/usr.sbin.cupsd}}}. You can re-activate App``Armor via {{{sudo aa-enforce cupsd}}}. Report a bug to the package '''cups''', so that we can correct the default configuration of App``Armor. = Capturing print job data = Often it is needed to find out what actually got sent to the printer in order to determine whether the problem is caused by the application or by the printing subsystem. For that it is the easiest way to capture the job data from the application so that it can analyzed whether it is already broken or not. To do so, follow these steps: <
>