From lyz at ubuntu.com Thu Dec 4 21:40:00 2014 From: lyz at ubuntu.com (Elizabeth K. Joseph) Date: Thu, 4 Dec 2014 13:40:00 -0800 Subject: Triaging Documentation bugs In-Reply-To: References: <5480C7B2.7090205@canonical.com> Message-ID: Forwarding this to ubuntu-bugsquad for some advice (was accidentally addressed to ubuntu-bug previously). On Thu, Dec 4, 2014 at 1:37 PM, Elizabeth K. Joseph wrote: > On Thu, Dec 4, 2014 at 12:44 PM, Peter Matulis > wrote: >> A discussion has surfaced within a doc bug [1] about how to triage bugs. >> Specifically, how to apply the Confirmed and Triage statuses. The bug >> contains differing points of view and I was wondering if others could >> take a look. Maybe I'm missing something. >> >> [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 > > My understanding is that this should be marked "Incomplete" since it's > been looked at (not "New") but we're still trying to gather enough > information to determine whether it's a bug or not (so can't "Confirm" > it). > > -- > Elizabeth Krumbach Joseph || Lyz || pleia2 > http://www.princessleia.com -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com From wxl at ubuntu.com Fri Dec 5 16:18:46 2014 From: wxl at ubuntu.com (Walter Lapchynski) Date: Fri, 5 Dec 2014 08:18:46 -0800 Subject: Triaging Documentation bugs Message-ID: >> On Thu, Dec 4, 2014 at 12:44 PM, Peter Matulis >> wrote: >>> A discussion has surfaced within a doc bug [1] about how to triage bugs. >>> [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 >> My understanding is that this should be marked "Incomplete" since it's >> been looked at (not "New") but we're still trying to gather enough >> information to determine whether it's a bug or not (so can't "Confirm" >> it). Confirmed means that someone else sees that there's a problem. Ideally, this occurs when there are a series of steps to repeat the bug. How does that apply to the documentation? Just as Peter describes in the bug: someone needs to find the deficiency through following the instructions. Ideally, someone changes the description to have very clear sections of "steps to reproduce," "expected results," and "actual results." When the bug triager can confirm this themselves and has enough information that a clear fix can be derived (whether through a patch or simply describing the problem and its causes enough), then it can be triaged. Since information has been provided and the bug is stalled at confirming it, it's not incomplete. Waiting for confirmation is not equivalent to incomplete status. It would be nice for there to be a "not confirmed" status, but there's not. That being said, it stays "new." -- @wxl Lubuntu Release Manager, Head of QA Ubuntu PPC Point of Contact Ubuntu Oregon LoCo Team Leader From teward at trekweb.org Fri Dec 5 16:30:08 2014 From: teward at trekweb.org (Thomas Ward) Date: Fri, 05 Dec 2014 11:30:08 -0500 Subject: Triaging Documentation bugs In-Reply-To: References: Message-ID: <5481DD90.8000802@trekweb.org> I think we need to keep in mind this is the 'server guide' and might not apply to the same policies as standard Ubuntu bug triage. Especially since the Documentation Team has ownership over that project. The Bug Squad works in Ubuntu bugs, but the documentation bugs are not necessarily under the Ubuntu Bug Triage processes. I am not a member of the Documentation team, but if the Server Guide (and other Documentation Team governed bugs) are subject to standard Ubuntu Bug Triage rules, then Walter's response here is accurate. I believe this merits additional discussion between the Bug Triagers and the Documentation Team to determine whether documentation bugs fall under the same triage procedures as standard bugs or not. (It stands to reason that since it's documentation and not fixable code/packaging bugs like most Ubuntu bugs, it might be a case of different statuses and different guidelines, kind of like the special workflow bugs.) On 12/05/2014 11:18 AM, Walter Lapchynski wrote: >>> On Thu, Dec 4, 2014 at 12:44 PM, Peter Matulis >>> wrote: >>>> A discussion has surfaced within a doc bug [1] about how to triage bugs. >>>> [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 >>> My understanding is that this should be marked "Incomplete" since it's >>> been looked at (not "New") but we're still trying to gather enough >>> information to determine whether it's a bug or not (so can't "Confirm" >>> it). > Confirmed means that someone else sees that there's a problem. > Ideally, this occurs when there are a series of steps to repeat the > bug. How does that apply to the documentation? Just as Peter describes > in the bug: someone needs to find the deficiency through following the > instructions. Ideally, someone changes the description to have very > clear sections of "steps to reproduce," "expected results," and > "actual results." > > When the bug triager can confirm this themselves and has enough > information that a clear fix can be derived (whether through a patch > or simply describing the problem and its causes enough), then it can > be triaged. > > Since information has been provided and the bug is stalled at > confirming it, it's not incomplete. Waiting for confirmation is not > equivalent to incomplete status. It would be nice for there to be a > "not confirmed" status, but there's not. That being said, it stays > "new." > ------ Thomas LP: ~teward From wxl at ubuntu.com Fri Dec 5 16:40:07 2014 From: wxl at ubuntu.com (Walter Lapchynski) Date: Fri, 5 Dec 2014 08:40:07 -0800 Subject: Triaging Documentation bugs In-Reply-To: <5481DD90.8000802@trekweb.org> References: <5481DD90.8000802@trekweb.org> Message-ID: Oops, forgot to include the documentation and OP in my reply so I'm leaving my original response below. Please reply all folks. Anywho, the documentation is as much code as a web page is and let's remember that various Ubuntu web sites are managed on Launchpad and held by the same triage processes. In fact, it appears to be XML, e.g.: https://bazaar.launchpad.net/~ubuntu-core-doc/serverguide/trunk/files/head:/serverguide/C/ That being said, I'm not sure we need to treat this differently, but if the Documentation Team sees some reason to have a unique workflow, that's certainly something we can discuss. wxl On Fri, Dec 5, 2014 at 8:30 AM, Thomas Ward wrote: > I think we need to keep in mind this is the 'server guide' and might not > apply to the same policies as standard Ubuntu bug triage. Especially > since the Documentation Team has ownership over that project. > > The Bug Squad works in Ubuntu bugs, but the documentation bugs are not > necessarily under the Ubuntu Bug Triage processes. I am not a member of > the Documentation team, but if the Server Guide (and other Documentation > Team governed bugs) are subject to standard Ubuntu Bug Triage rules, > then Walter's response here is accurate. > > I believe this merits additional discussion between the Bug Triagers and > the Documentation Team to determine whether documentation bugs fall > under the same triage procedures as standard bugs or not. (It stands to > reason that since it's documentation and not fixable code/packaging bugs > like most Ubuntu bugs, it might be a case of different statuses and > different guidelines, kind of like the special workflow bugs.) > > > On 12/05/2014 11:18 AM, Walter Lapchynski wrote: >>>> On Thu, Dec 4, 2014 at 12:44 PM, Peter Matulis >>>> wrote: >>>>> A discussion has surfaced within a doc bug [1] about how to triage bugs. >>>>> [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 >>>> My understanding is that this should be marked "Incomplete" since it's >>>> been looked at (not "New") but we're still trying to gather enough >>>> information to determine whether it's a bug or not (so can't "Confirm" >>>> it). >> Confirmed means that someone else sees that there's a problem. >> Ideally, this occurs when there are a series of steps to repeat the >> bug. How does that apply to the documentation? Just as Peter describes >> in the bug: someone needs to find the deficiency through following the >> instructions. Ideally, someone changes the description to have very >> clear sections of "steps to reproduce," "expected results," and >> "actual results." >> >> When the bug triager can confirm this themselves and has enough >> information that a clear fix can be derived (whether through a patch >> or simply describing the problem and its causes enough), then it can >> be triaged. >> >> Since information has been provided and the bug is stalled at >> confirming it, it's not incomplete. Waiting for confirmation is not >> equivalent to incomplete status. It would be nice for there to be a >> "not confirmed" status, but there's not. That being said, it stays >> "new." >> > > > ------ > Thomas > LP: ~teward -- @wxl Lubuntu Release Manager, Head of QA Ubuntu PPC Point of Contact Ubuntu Oregon LoCo Team Leader From peter.matulis at canonical.com Fri Dec 5 20:06:00 2014 From: peter.matulis at canonical.com (Peter Matulis) Date: Fri, 05 Dec 2014 15:06:00 -0500 Subject: Triaging Documentation bugs In-Reply-To: References: <5481DD90.8000802@trekweb.org> Message-ID: <54821028.7080305@canonical.com> On 12/05/2014 11:40 AM, Walter Lapchynski wrote: > Oops, forgot to include the documentation and OP in my reply so I'm > leaving my original response below. Please reply all folks. > > Anywho, the documentation is as much code as a web page is and let's > remember that various Ubuntu web sites are managed on Launchpad and > held by the same triage processes. In fact, it appears to be XML, > e.g.: > https://bazaar.launchpad.net/~ubuntu-core-doc/serverguide/trunk/files/head:/serverguide/C/ > > That being said, I'm not sure we need to treat this differently, but > if the Documentation Team sees some reason to have a unique workflow, > that's certainly something we can discuss. I don't see any reason why we would need a special workflow. That would just lead to unwarranted complications. I just wanted to make sure everyone is in agreement on how to use bug statuses. To recap, 1. 'Confirmed' normally precedes 'Triage' 2. 'Confirmed' never follows 'Triage' 3. If 'Triage' is ever used before 'Confirmed' the latter is implied 4. The current state of 'New' is the proper one for the bug in question [1]. [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 Peter Matulis Server Guide cheerleader and Bug Squad member From wxl at ubuntu.com Fri Dec 5 20:07:53 2014 From: wxl at ubuntu.com (Walter Lapchynski) Date: Fri, 5 Dec 2014 12:07:53 -0800 Subject: Triaging Documentation bugs In-Reply-To: <54821028.7080305@canonical.com> References: <5481DD90.8000802@trekweb.org> <54821028.7080305@canonical.com> Message-ID: On Fri, Dec 5, 2014 at 12:06 PM, Peter Matulis wrote: > 1. 'Confirmed' normally precedes 'Triage' > 2. 'Confirmed' never follows 'Triage' > 3. If 'Triage' is ever used before 'Confirmed' the latter is implied > 4. The current state of 'New' is the proper one for the bug in question [1]. > [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 Yep. Thanks for your help! -- @wxl Lubuntu Release Manager, Head of QA Ubuntu PPC Point of Contact Ubuntu Oregon LoCo Team Leader From gunnarhj at ubuntu.com Sat Dec 6 02:13:54 2014 From: gunnarhj at ubuntu.com (Gunnar Hjalmarsson) Date: Sat, 06 Dec 2014 03:13:54 +0100 Subject: Triaging Documentation bugs In-Reply-To: <54821028.7080305@canonical.com> References: <5481DD90.8000802@trekweb.org> <54821028.7080305@canonical.com> Message-ID: <54826662.2030703@ubuntu.com> Re: status of https://bugs.launchpad.net/serverguide/+bug/1327173 Let me summarize the background: * The bug reporter claimed that a spot in the server guide is not correct. * Peter M. asked for clarifications, and the status was set to "incomplete". * A couple of days later, the bug reporter provided the requested info in the form of precise suggestions for changes. * Since nobody acted after that, the bug was autoexpired due to the "incomplete" status. * I happened to see that. To make sure the bug report would not be accidentally forgotten, I changed the status from "incomplete" to "triaged". * Peter M. thanked me by disagreeing on the "triaged" status. So why did I choose "triaged" and not "new"? Simply because I think that the bug report contains all info that a server guide maintainer could ever need to start working, and I found the info provided by the bug reporter convincing. The ball is in the maintainers' court. That's what "triaged" is about. Quote from https://wiki.ubuntu.com/Bugs/Bug%20statuses : "Triaged: - A member of UbuntuBugControl believes that the report describes a genuine bug in enough detail that a developer could start working on a fix. (also see tip below) - Use this when you are confident that it should be looked at by a developer and has enough information" On 2014-12-05 21:06, Peter Matulis wrote: > On 12/05/2014 11:40 AM, Walter Lapchynski wrote: >> ... if the Documentation Team sees some reason to have a unique >> workflow, that's certainly something we can discuss. > > I don't see any reason why we would need a special workflow. That > would just lead to unwarranted complications. Excellent. Then https://wiki.ubuntu.com/Bugs/Bug%20statuses applies. > I just wanted to make sure everyone is in agreement on how to use bug > statuses. > > To recap, > > 1. 'Confirmed' normally precedes 'Triage' > 2. 'Confirmed' never follows 'Triage' > 3. If 'Triage' is ever used before 'Confirmed' the latter is implied No. Those points are your own invention. There is nothing at the "Bug statuses" page which supports the idea that a bug must be "confirmed" before "triaged". They are different beasts. Didn't you just say that we don't need a special workflow? Btw, a LP bug can get the status "confirmed" just by anybody out there stating that the bug affects him/her. > 4. The current state of 'New' is the proper one for the bug in > question [1]. > > [1]: https://bugs.launchpad.net/serverguide/+bug/1327173 It doesn't look new to me, but sure, if you say so. I think "triaged" is appropriate. It's probably a matter of judgement. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj From noreply at ubuntu.com Fri Dec 5 16:39:38 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 05 Dec 2014 16:39:38 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/FindRightPackage=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141205163938.23229.84108@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/FindRightPackage" page has been changed by penalvch: http://wiki.ubuntu.com/Bugs/FindRightPackage?action=diff&rev1=133&rev2=134 Comment: Due to LP#997711 et. al. clarified suspend and hibernate are two different issues, and preferred package to start is linux. Usual candidate packages are the kernel (file bugs under the "linux" package) and network-manager. - === Suspend, Hibernate, and Resume === + === Suspend and Hibernate === - Suspend, hibernate, and resume functionality is provided by three different packages: + Suspend and hibernate are are treated as two completely different issues, necessitating one bug report for each. While there are many different packages responsible for : + * [[#Kernel|The kernel]] implements the actual suspending and resuming and is generally the responsible package when there are any hardware-related failures after resume. Please file all bugs against the package linux first, unless you know exactly the root cause commit in the code for the responsible package. This is how the high majority of suspend/hibernate bugs are due to outdated BIOS, and buggy driver implementations, versus userspace bugs. * `gnome-power-manager` (in Ubuntu and Edubuntu) is responsible for setting policy on when the system should be suspended or resumed and signaling the system to do so. * `pm-utils` is responsible for getting the system into a state where it can be suspended or hibernated, and handling any cleanup after resume. - * [[#Kernel|The kernel]] implements the actual suspending and resuming and is generally the responsible package when there are any hardware-related failures after resume. If you are unsure which package is causing the problem, a safe bet is the kernel (package 'linux'), ''but make sure the bug title includes "suspend" or "hibernate"''. From webmaster at ubuntu.com Fri Dec 5 16:44:39 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Fri, 05 Dec 2014 16:44:39 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141205164439.23006.78606@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=275&rev2=276 Comment: Clarified when to file a general bug. == 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. + First, please review potential package candidates [[https://wiki.ubuntu.com/Bugs/FindRightPackage|here]]. Only after reviewing this, if are still 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]] From es20490446e at gmail.com Sat Dec 6 18:23:17 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sat, 06 Dec 2014 19:23:17 +0100 Subject: Triaging Documentation bugs In-Reply-To: <54826662.2030703@ubuntu.com> References: <5481DD90.8000802@trekweb.org> <54821028.7080305@canonical.com> <54826662.2030703@ubuntu.com> Message-ID: <54834995.2080703@gmail.com> Gunnar Hjalmarsson: > There is nothing at the "Bug > statuses" page which supports the idea that a bug must be "confirmed" > before "triaged". Probably very few users will confirm documentation bugs. -------------- 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 gunnarhj at ubuntu.com Sat Dec 6 18:51:45 2014 From: gunnarhj at ubuntu.com (Gunnar Hjalmarsson) Date: Sat, 06 Dec 2014 19:51:45 +0100 Subject: Triaging Documentation bugs In-Reply-To: <54834995.2080703@gmail.com> References: <5481DD90.8000802@trekweb.org> <54821028.7080305@canonical.com> <54826662.2030703@ubuntu.com> <54834995.2080703@gmail.com> Message-ID: <54835041.7080204@ubuntu.com> On 2014-12-06 19:23, Alberto Salvia Novella wrote: > Gunnar Hjalmarsson: >> There is nothing at the "Bug statuses" page which supports the idea >> that a bug must be "confirmed" before "triaged". > > Probably very few users will confirm documentation bugs. Actually it happens, and when it does, it can be useful information. But it would make no sense to consider it a prerequisite for stating that a bug is ready for the maintainers to deal with by setting the status "triaged". -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj From noreply at ubuntu.com Sun Dec 7 22:20:30 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 07 Dec 2014 22:20:30 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Tags=22_by_penalvch?= Message-ID: <20141207222030.10512.20771@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Tags" page has been changed by penalvch: http://wiki.ubuntu.com/Bugs/Tags?action=diff&rev1=195&rev2=196 Comment: 1) As per LP#1398585 clarified kernel-fixed-upstream. 2) + kernel-fixed-upstream & kernel-bug-exists-upstream. 3) RM'ed confusing apostrophes. 4) Clarified patch. 5) Misc. minor presentation fixes. == Different ways you can help == || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=bitesize|`bitesize`]] || This bug is easy to fix and suitable for new contributors. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=bitesize|bitesize]] || This bug is easy to fix and suitable for new contributors. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-artwork|`needs-artwork`]] || A bug that needs new artwork to be created || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-artwork|needs-artwork]] || A bug that needs new artwork to be created || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-coding|`needs-coding`]] || A bug that needs new source code to be written || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-coding|needs-coding]] || A bug that needs new source code to be written || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-design|`needs-design`]] || A bug that needs UI design done first || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-design|needs-design]] || A bug that needs UI design done first || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging|`needs-packaging`]] || Packaging requests - software that isn't packaged for Ubuntu yet || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging|needs-packaging]] || Packaging requests - software that isn't packaged for Ubuntu yet || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-sound|`needs-sound`]] || A bug that needs new sound to be created || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-sound|needs-sound]] || A bug that needs new sound to be created || == Generic bug tags == || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-bug|`apport-bug`]] || A bug reported using "Report a Problem" in an application's Help menu contains lots of details! || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-bug|apport-bug]] || A bug reported using "Report a Problem" in an application's Help menu contains lots of details! || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-collected|`apport-collected`]] || A bug that has had apport-collect ran against it which will contain additional information || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-collected|apport-collected]] || A bug that has had apport-collect ran against it which will contain additional information. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-crash|`apport-crash`]] || A crash reported by apport - Ubuntu's automated problem reporter || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-crash|apport-crash]] || A crash reported by apport - Ubuntu's automated problem reporter. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-package|`apport-package`]] || A bug reported by apport when a package operation failed || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-package|apport-package]] || A bug reported by apport when a package operation failed. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=package-conflict | `package-conflict`]] || A bug reported by apport when a package operation failed due to a conflict with a file provided by another package || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=package-conflict|package-conflict]] || A bug reported by apport when a package operation failed due to a conflict with a file provided by another package. || - || [[https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=derivatives|`derivatives`]] || Bugs related to Derivatives || + || [[https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=derivatives|derivatives]] || Bugs related to Derivatives. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=desktop-file|`desktop-file`]] || The bug requests the addition/fix of a .desktop file. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=desktop-file|desktop-file]] || The bug requests the addition/fix of a .desktop file. || - || [[https://launchpad.net/ubuntu/+bugs?field.status:list=FIXRELEASED&field.tag=fix-to-verify|`fix-to-verify`]] || A bug that is Fix Released and should be verified when performing iso testing of daily builds or milestones || + || [[https://launchpad.net/ubuntu/+bugs?field.status:list=FIXRELEASED&field.tag=fix-to-verify|fix-to-verify]] || A bug that is Fix Released and should be verified when performing iso testing of daily builds or milestones. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs|`ftbfs`]] || Bugs describing build failures of packages. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs|ftbfs]] || Bugs describing build failures of packages. || - || [[https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=gobuntu|`gobuntu`]] || Bugs related to Gobuntu || + || [[https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=gobuntu|gobuntu]] || Bugs related to Gobuntu. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=hw-specific|`hw-specific`]] || A bug that requires a specific piece of hardware to duplicate || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=hw-specific|hw-specific]] || A bug that requires a specific piece of hardware to duplicate. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=iso-testing|`iso-testing`]] || A bug found when performing iso testing and also tracked at https://iso.qa.ubuntu.com/ || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=iso-testing|iso-testing]] || A bug found when performing [[https://iso.qa.ubuntu.com/|iso testing]]. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=likely-dup|`likely-dup`]] || The bug is likely a duplicate of another bug but you can't find it. (Maybe an upstream bug too.) || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=likely-dup|likely-dup]] || The bug is likely a duplicate of another bug ((maybe an upstream bug too) but you can't find it. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=manpage|`manpage`]] || This bug is about a package's manpage being incorrect. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=manpage|manpage]] || This bug is about a package's manpage being incorrect. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=metabug|`metabug`]] || This bug has a high probability of duplicate reports being filed. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=metabug|metabug]] || This bug has a high probability of duplicate reports being filed. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=multiarch|`multiarch`]] || This bug is due to an issue with the new [[http://wiki.debian.org/Multiarch|multiarch triplet paths]], this can be build time, install time, or run time issues. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=multiarch|multiarch]] || This bug is due to an issue with the new [[http://wiki.debian.org/Multiarch|multiarch triplet paths]], this can be build time, install time, or run time issues. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=nautilus-desktop-icons|`nautilus-desktop-icons`]] || Bugs related to the Nautilus desktop, especially the alignment, display and grid of icons. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=nautilus-desktop-icons|nautilus-desktop-icons]] || Bugs related to the Nautilus desktop, especially the alignment, display and grid of icons. || - || [[https://launchpad.net/ubuntu/+bugs?orderby=-importance&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Invalid&field.status%3Alist=Won%27t+Fix&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.status%3Alist=Fix+Released&field.tag=needs-devrelease-testing&search=Search|`needs-devrelease-testing`]] || A bug that existed in a previous release of Ubuntu and needs to be tested in the latest development release || + || [[https://launchpad.net/ubuntu/+bugs?orderby=-importance&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Invalid&field.status%3Alist=Won%27t+Fix&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.status%3Alist=Fix+Released&field.tag=needs-devrelease-testing&search=Search|needs-devrelease-testing]] || A bug that existed in a previous release of Ubuntu and needs to be tested in the latest development release. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-reassignment|`needs-reassignment`]] || A bug that was reported about the wrong package but the package maintainer isn't sure which package it belongs to || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-reassignment|needs-reassignment]] || A bug that was reported about the wrong package but the package maintainer isn't sure which package it belongs to. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=packaging|`packaging`]] || The bug is likely to be a packaging mistake. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=packaging|packaging]] || The bug is likely to be a packaging mistake. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=screencast|`screencast`]] || This bug report includes a screencast of the bug in action! || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=screencast|screencast]] || This bug report includes a screencast of the bug in action! || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=string-fix|`string-fix`]] || This bug is a string fix (not code) and is great for new contributors. For spelling and grammatical errors. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=string-fix|string-fix]] || This bug is a string fix (not code) and is great for new contributors. For spelling and grammatical errors. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=touch|`touch`]] || an issue with touch support in applications or X || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=touch|touch]] || an issue with touch support in applications or X. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=triage-mentoring-available|`triage-mentoring-available`]] || This bug has been identified as one that could use some additional information and another triager is offering guidance for getting that information. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=triage-mentoring-available|triage-mentoring-available]] || This bug has been identified as one that could use some additional information and another triager is offering guidance for getting that information. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=units-policy|`units-policy`]] || A bug that violates the UnitsPolicy || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=units-policy|units-policy]] || A bug that violates the UnitsPolicy. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=unmetdeps|`unmetdeps`]] || Bugs that indicate packages not being installable due to missing dependencies. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=unmetdeps|unmetdeps]] || Bugs that indicate packages not being installable due to missing dependencies. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=upgrade-software-version|`upgrade-software-version`]] || Bugs that request new software versions - please help reviewing them carefully. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=upgrade-software-version|upgrade-software-version]] || Bugs that request new software versions - please help reviewing them carefully. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=work-intensive|`work-intensive`]] || triaging requires intensive work to validate/reproduce || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=work-intensive|work-intensive]] || triaging requires intensive work to validate/reproduce. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=dist-upgrade|`dist-upgrade`]] || A bug that was encountered when upgrading between releases of Ubuntu || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=dist-upgrade|dist-upgrade]] || A bug that was encountered when upgrading between releases of Ubuntu. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=testcase|`testcase`]] || A bug which contains a test case - steps to recreate the bug || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=testcase|testcase]] || A bug which contains a test case - steps to recreate the bug. || == Application Specific Tags == - ##These tags are pulled from other wiki pages - you can determine which one by looking at the bit after "Include(". So the first set are pulled from the DebuggingNetworkManager wiki page. - ## - ## The line below makes moinmoin explode why? It used to work before the upgrade on 2008-08-06 - ##<> - === Cheese Specific === + Tags Apport adds while collecting information for Cheese Webcam Booth. || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=gstreamer-error|`gstreamer-error`]] || Bug is related to bad drivers and not Cheese; ''Switch bug to related package(`linux` for missing/bad drivers)''|| + || [[https://launchpad.net/ubuntu/+bugs?field.tag=gstreamer-error|gstreamer-error]] || Bug is related to bad drivers and not Cheese. ''Switch bug to the linux package for missing/bad drivers.''|| - || [[https://launchpad.net/ubuntu/+bugs?field.tag=gstreamer-ok|`gstreamer-ok`]] || Video gstreamer input works fine (drivers seem fine), most likely a Cheese bug || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=gstreamer-ok|gstreamer-ok]] || Video gstreamer input works fine (drivers seem fine), most likely a Cheese bug. || - - ##It appears the "Bug Tags" section of the DebuggingNetworkManager page was removed in revision 48, so there's no longer anything to include here... (see https://wiki.ubuntu.com/DebuggingNetworkManager?action=diff&rev1=47&rev2=48 ) - ##=== Network Manager === - ##<> === Unity === The full list of tags for Unity is maintained at: [[Unity/FilingBugs#Bug_Tags]], including: - || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+source/compiz/+bugs?field.tag=unity|`unity`]] || Compiz bugs which are affecting Unity || + || [[https://launchpad.net/ubuntu/+source/compiz/+bugs?field.tag=unity|unity]] || Compiz bugs which are affecting Unity. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=running-unity|`running-unity`]] || Bugs reported by people who are running Unity || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=running-unity|running-unity]] || Bugs reported by people who are running Unity. || - || [[https://launchpad.net/unity/+bugs?field.tag=needs-design|`needs-design`]] || A bug that needs UI design done first. || + || [[https://launchpad.net/unity/+bugs?field.tag=needs-design|needs-design]] || A bug that needs UI design done first. || - || [[https://launchpad.net/unity/+bugs?field.tag=backlog|`backlog`]] || Things that design has done and has finished on that needs to be implemented. || + || [[https://launchpad.net/unity/+bugs?field.tag=backlog|backlog]] || Things that design has done and has finished on that needs to be implemented. || === Update Manager === + <> == Other specific bug tags == === Ayatana === + Specific bugs concerning parts of the [[https://launchpad.net/ayatana|Ayatana project]]. || '''Tag''' || '''Use case''' || - ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=app-menu|`app-menu`]] || Bugs related to the [[DesktopExperienceTeam/ApplicationMenu|App Menu]] that will be used for the first time in the Ubuntu Maverick Netbook Edition. || + ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=app-menu|app-menu]] || Bugs related to the [[DesktopExperienceTeam/ApplicationMenu|App Menu]]. || - ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-applet|`indicator-applet`]] || Bugs related to the use of the Indicator Applet that are not in the 'indicator-applet' package (no Application Indicators!) || + ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-applet|indicator-applet]] || Bugs related to the use of the Indicator Applet that are not in the 'indicator-applet' package (no Application Indicators). || - ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-application|`indicator-application`]] || Bugs related to the use of Indicator Application that are not in the 'indicator-application' package || + ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-application|indicator-application]] || Bugs related to the use of Indicator Application that are not in the 'indicator-application' package. || - ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=trayaway|`trayaway`]] || Bugs related to the [[NotificationAreaTransition|Notification Area transition]].|| + ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=trayaway|trayaway]] || Bugs related to the [[NotificationAreaTransition|Notification Area transition]]. || === Hardware Specific === || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ac97-jack-sense|`ac97-jack-sense`]] || This bug deals with headphone sense for AC'97 based codecs (0401) || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ac97-jack-sense|ac97-jack-sense]] || This bug deals with headphone sense for AC'97 based codecs (0401). || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=hda-jack-sense|`hda-jack-sense`]] || This bug deals with headphone sense for HDA based codecs (0403) || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=hda-jack-sense|hda-jack-sense]] || This bug deals with headphone sense for HDA based codecs (0403). || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=macbook|`macbook`]] || These bugs deal with Mac Book systems || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=macbook|macbook]] || These bugs deal with Mac Book systems. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=macbookpro|`macbookpro`]] || These bugs deal with Mac Book Pro systems || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=macbookpro|macbookpro]] || These bugs deal with Mac Book Pro systems. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ps3|`ps3`]] || Some bug reports are about people running Ubuntu on a Playstation 3 || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ps3|ps3]] || Some bug reports are about people running Ubuntu on a Playstation 3. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ume|`ume`]] || These bugs deal with Ubuntu Mobile and Embeded systems || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ume|ume]] || These bugs deal with Ubuntu Mobile and Embeded systems. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=armel|`armel`]] || These bugs deal with Ubuntu arm systems || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=armel|armel]] || These bugs deal with Ubuntu arm systems. || === Historical Tags === - These tags were relevant previously for Ubuntu bugs and may still appear in some bugs. The needs retracing tags are added automatically for Gutsy. + These tags were relevant previously for Ubuntu bugs and may still appear in some bugs. || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-amd64-retrace|`need-amd64-retrace`]] || The bug contains a crash report that needs retracing with `apport-retrace` on `amd64` || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-amd64-retrace|need-amd64-retrace]] || The bug contains a crash report that needs retracing with `apport-retrace` on `amd64`. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-i386-retrace|`need-i386-retrace`]] || The bug contains a crash report that needs retracing with `apport-retrace` on `i386` || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-i386-retrace|need-i386-retrace]] || The bug contains a crash report that needs retracing with `apport-retrace` on `i386`. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-powerpc-retrace|`need-powerpc-retrace`]] || The bug contains a crash report that needs retracing with `apport-retrace` on `powerpc` || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-powerpc-retrace|need-powerpc-retrace]] || The bug contains a crash report that needs retracing with `apport-retrace` on `powerpc`. || - === Kernel Specific === || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-kerneloops|`apport-kerneloops`]] || This Kernel Oops was reported using apport. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-kerneloops|apport-kerneloops]] || This Kernel Oops was reported using apport. || - || [[https://launchpad.net/ubuntu/+bugs?field.searchtext=linux&field.tag=bitesize|`bitesize` ]] || With regards to the kernel, this includes things like enabling modules and changing kernel config options || + || [[https://launchpad.net/ubuntu/+bugs?field.searchtext=linux&field.tag=bitesize|bitesize]] || With regards to the kernel, this includes things like enabling modules and changing kernel config options. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=cherry-pick|`cherry-pick`]] || A kernel bug that has a git commit SHA from the upstream kernel || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=cherry-pick|cherry-pick]] || A kernel bug that has a git commit SHA from the upstream kernel. || - || [[https://launchpad.net/ubuntu/+bugs?field.tags_combinator=ALL&field.tag=hibernate+resume|`hibernate resume`]] || This bug was triggered by a hibernate/resume failure || + || [[https://launchpad.net/ubuntu/+bugs?field.tags_combinator=ALL&field.tag=hibernate+resume|hibernate resume]] || This bug was triggered by a hibernate/resume failure. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kernel-bug|`kernel-bug`]] || A "BUG:" message output was noted in the logs but it did not contain an Oops || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kernel-bug|kernel-bug]] || A "BUG:" message output was noted in the logs but it did not contain an Oops. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kernel-oops|`kernel-oops`]] || This bug causes a kernel Oops message || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kernel-oops|kernel-oops]] || This bug causes a kernel Oops message. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-testing|`needs-upstream-testing`]] || This bug needs to be tested with the upstream kernel - https://wiki.ubuntu.com/KernelMainlineBuilds || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-testing|needs-upstream-testing]] || This bug needs to be tested with the [[https://wiki.ubuntu.com/KernelMainlineBuilds|upstream kernel]]. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kernel-fixed-upstream|kernel-fixed-upstream]] || This bug is not reproducible with the latest [[https://wiki.ubuntu.com/KernelMainlineBuilds|upstream kernel]] version available that allows the reporter to test it, and the version is higher than the Ubuntu kernel after [[http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html|mapping]]. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kernel-bug-exists-upstream|kernel-bug-exists-upstream]] || This bug is reproducible with the latest [[https://wiki.ubuntu.com/KernelMainlineBuilds|upstream kernel]] version available that allows the reporter to test it, and the version is higher than the Ubuntu kernel after [[http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html|mapping]]. || - || [[https://launchpad.net/ubuntu/+bugs?field.tags_combinator=ALL&field.tag=suspend+resume|`suspend resume`]] || This bug was triggered by a suspend/resume failure || + || [[https://launchpad.net/ubuntu/+bugs?field.tags_combinator=ALL&field.tag=suspend+resume|suspend resume]] || This bug was triggered by a suspend/resume failure. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=xorg-needs-kernel-fix|`xorg-needs-kernel-fix`]] || This is an xorg bug which is dependent on a kernel patch || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=xorg-needs-kernel-fix|xorg-needs-kernel-fix]] || This is an xorg bug which is dependent on a kernel patch. || For more tags see [[Kernel/Tagging|Kernel/Tagging]]. === Kubuntu Specific === || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=guidance-powermanager|`guidance-powermanager`]] || This kde-guidance bug is in powermanager || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=guidance-powermanager|guidance-powermanager]] || This kde-guidance bug is in powermanager. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-displayconfig|`kde-guidance-displayconfig`]] || This kde-guidance bug is in displayconfig || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-displayconfig|kde-guidance-displayconfig]] || This kde-guidance bug is in displayconfig. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-mountconfig|`kde-guidance-mountconfig`]] || This kde-guidance bug is in mountconfig || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-mountconfig|kde-guidance-mountconfig]] || This kde-guidance bug is in mountconfig. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-serviceconfig|`kde-guidance-serviceconfig`]] || This kde-guidance bug is in serviceconfig || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-serviceconfig|kde-guidance-serviceconfig]] || This kde-guidance bug is in serviceconfig. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-userconfig|`kde-guidance-userconfig`]] || This kde-guidance bug is in userconfig || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-userconfig|kde-guidance-userconfig]] || This kde-guidance bug is in userconfig. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-wineconfig|`kde-guidance-wineconfig`]] || This kde-guidance bug is in wineconfig || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=kde-guidance-wineconfig|kde-guidance-wineconfig]] || This kde-guidance bug is in wineconfig. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-report|`needs-upstream-report`]] || This bug needs the report to be forwarded to the upstream project || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-report|needs-upstream-report]] || This bug needs the report to be forwarded to the upstream project. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-sync|`needs-upstream-sync`]] || This bug has been forwarded to the upstream project which has released a fix that has not been merged yet || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-sync|needs-upstream-sync]] || This bug has been forwarded to the upstream project which has released a fix that has not been merged yet. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=upstream|`upstream`]] || This bug is reported to the upstream project || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=upstream|upstream]] || This bug is reported to the upstream project. || === More specific === || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=a11y|`a11y`]] || This bug is an accessibility problem. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=a11y|a11y]] || This bug is an accessibility problem. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-hook|`apport-hook`]] || This bug is about modifying or adding an apport hook for a package. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-hook|apport-hook]] || This bug is about modifying or adding an apport hook for a package. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=dxteam|`dxteam`]] || This bug is specifically targeted by Canonical developers, only to be associated with the 'notifications' tag. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=dxteam|dxteam]] || This bug is specifically targeted by Canonical developers, only to be associated with the 'notifications' tag. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ec2-images|`ec2-images`]] || This bug is related to Ubuntu on [[https://help.ubuntu.com/community/EC2StartersGuide|EC2]]. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ec2-images|ec2-images]] || This bug is related to Ubuntu on [[https://help.ubuntu.com/community/EC2StartersGuide|EC2]]. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=java-headless|`java-headless`]] || This bug is related to a Java program or library that could run headless but depends on a full Java environment (including graphics and sound) || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=java-headless|java-headless]] || This bug is related to a Java program or library that could run headless but depends on a full Java environment (including graphics and sound). || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ldap|`ldap`]] || This bug is a LDAP problem. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ldap|ldap]] || This bug is a LDAP problem. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=linuxfirmwarekit|`linuxfirmwarekit`]] || This bug contains Linux firmware kit test results. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=linuxfirmwarekit|linuxfirmwarekit]] || This bug contains Linux firmware kit test results. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=ngo|`ngo`]] || This bug affects [[NGO|NGOs]]. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=ngo|ngo]] || This bug affects [[NGO|NGOs]]. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=notifications|`notifications`]] || This bug is related to the notification system (notify-osd) introduced in Jaunty || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=notifications|notifications]] || This bug is related to the notification system (notify-osd). || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=nscd|`nscd`]] || This bug deals with nscd which is part of the glibc package || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=nscd|nscd]] || This bug deals with nscd which is part of the glibc package. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=usability|`usability`]] || This bug is a usability problem. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=usability|usability]] || This bug is a usability problem. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=rtl|`rtl`]] || This bug is a right-to-left problem. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=rtl|rtl]] || This bug is a right-to-left problem. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=uec-images|`uec-images`]] || This bug is related to the Ubuntu Enterprise Cloude (UEC) [[http://uec-images.ubuntu.com/releases|images]] || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=uec-images|uec-images]] || This bug is related to the Ubuntu Enterprise Cloude (UEC) [[http://uec-images.ubuntu.com/releases|images]]. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=xinerama|`xinerama`]] || This bug is a xinerama problem. Multiple-monitor configuration. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=xinerama|xinerama]] || This bug is a xinerama problem. Multiple-monitor configuration. || === Patch specific === - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch|`patch`]] || This bug has a patch attached to it || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch|patch]] || A patch in its final form, and can immediately be released into the appropriate Ubuntu repository as outlined in [[https://wiki.ubuntu.com/Bugs/Patches]]. A raw patch copied from an external location, or possible/test/draft patches wouldn't fit this criteria. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-accepted-debian|`patch-accepted-debian`]] || This bug has a patch attached to it that has been accepted by Debian || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-accepted-debian|patch-accepted-debian]] || This bug has a patch attached to it that has been accepted by Debian. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-accepted-upstream|`patch-accepted-upstream`]] || This bug has a patch attached to it that has been accepted by upstream || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-accepted-upstream|patch-accepted-upstream]] || This bug has a patch attached to it that has been accepted by upstream. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-forwarded-debian|`patch-forwarded-debian`]] || This bug has a patch attached to it that has been forwarded to Debian. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-forwarded-debian|patch-forwarded-debian]] || This bug has a patch attached to it that has been forwarded to Debian. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-forwarded-upstream|`patch-forwarded-upstream`]] || This bug has a patch attached to it that has been forwarded upstream || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-forwarded-upstream|patch-forwarded-upstream]] || This bug has a patch attached to it that has been forwarded upstream. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-needswork|`patch-needswork`]] || This bug has a patch attached to it that needs some work done on it || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-needswork|patch-needswork]] || This bug has a patch attached to it that needs some work done on it. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected|`patch-rejected`]] || This bug has a patch attached to it that was not included in Ubuntu || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected|patch-rejected]] || This bug has a patch attached to it that was not included in Ubuntu. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected-debian|`patch-rejected-debian`]] || This bug has a patch attached to it that has been rejected by Debian || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected-debian|patch-rejected-debian]] || This bug has a patch attached to it that has been rejected by Debian. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected-upstream|`patch-rejected-upstream`]] || This bug has a patch attached to it that has been rejected by upstream || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected-upstream|patch-rejected-upstream]] || This bug has a patch attached to it that has been rejected by upstream. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-upstreaminput|`patch-upstreaminput`]] || This bug has a patch attached to it that has been forwarded upstream and requires their input or incorporation || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-upstreaminput|patch-upstreaminput]] || This bug has a patch attached to it that has been forwarded upstream and requires their input or incorporation. || === Regression specific === See the [[http://qa.ubuntu.com/reports/regression/regression_tracker.html|regression tracker]] for a list of these bugs and [[QATeam/RegressionTracking]] for more information. || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-release|`regression-release`]] || A bug in a release that was not present in a previous release. Should be used together with a separate tag for the release the regression was found in. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-release|regression-release]] || A bug in a release that was not present in a previous release. Should be used together with a separate tag for the release the regression was found in. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-update|`regression-update`]] || A bug in a stable release that was introduced by a package from -updates || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-update|regression-update]] || A bug in a stable release that was introduced by a package from -updates. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-proposed|`regression-proposed`]] || A bug in a stable release of Ubuntu that was found when testing a package from -proposed || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-proposed|regression-proposed]] || A bug in a stable release of Ubuntu that was found when testing a package from -proposed. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-retracer|`regression-retracer`]] || An apport crash bug report that was identified by the retracer as having the same characteristics as a fixed crash report || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=regression-retracer|regression-retracer]] || An apport crash bug report that was identified by the retracer as having the same characteristics as a fixed crash report. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-bisect|`needs-bisect`]] || This is for when a bisect is requested or required to fix the bug. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-bisect|needs-bisect]] || This is for when a bisect is requested or required to fix the bug. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-bisect|`performing-bisect`]] || The reporter, developer, or triager is in the process of performing a bisection. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-bisect|performing-bisect]] || The reporter, developer, or triager is in the process of performing a bisection. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=bisect-done|`bisect-done`]] || Add when a bisect has been completed and the offending commit(s) identified. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=bisect-done|bisect-done]] || Add when a bisect has been completed and the offending commit(s) identified. || === SRU Specific === See StableReleaseUpdates for more information. || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-done|`verification-done`]] || A Stable Release Update bug with a package in -proposed that has been confirmed to fix the bug || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-done|verification-done]] || A Stable Release Update bug with a package in -proposed that has been confirmed to fix the bug. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-failed|`verification-failed`]] || A Stable Release Update bug with a package in -proposed that has been verified to not fix the bug || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-failed|verification-failed]] || A Stable Release Update bug with a package in -proposed that has been verified to not fix the bug. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-needed|`verification-needed`]] || A Stable Release Update bug with a package in -proposed needing testing || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-needed|verification-needed]] || A Stable Release Update bug with a package in -proposed needing testing. || === X Specific === From noreply at ubuntu.com Sun Dec 7 22:23:11 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 07 Dec 2014 22:23:11 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingUpdateManager=22_by_pen?= =?utf-8?q?alvch?= Message-ID: <20141207222311.10531.44911@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingUpdateManager" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingUpdateManager?action=diff&rev1=46&rev2=47 Comment: 1) RM'ed apostrophes as confusing. 2) RM'ed EOL upgrade paths. = Bug Tags = || '''Tag''' || '''Use case''' || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=lucid2precise|`lucid2precise`]] || Bugs related to upgrades from Lucid Lynx (10.04) to Precise Pangolin (12.04) || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=lucid2precise|lucid2precise]] || Bugs related to upgrades from Lucid Lynx (10.04) to Precise Pangolin (12.04). || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=oneiric2precise |`oneiric2precise`]] || Bugs related to upgrades from Oneiric Ocelot (11.10) to Precise Pangolin (12.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=natty2oneiric |`natty2oneiric`]] || Bugs related to upgrades from Natty Narwhal (11.04) to Oneiric Ocelot (11.10) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=maverick2natty |`maverick2natty`]] || Bugs related to upgrades from Maverick Meerkat (10.10) to Natty Narwhal (11.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=lucid2maverick |`lucid2maverick`]] || Bugs related to upgrades from Lucid Lynx (10.04) to Maverick Meerkat (10.10) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=hardy2lucid|`hardy2lucid`]] || Bugs related to upgrades from Hardy Heron (8.04) to Lucid Lynx (10.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=karmic2lucid|`karmic2lucid`]] || Bugs related to upgrades from Karmic Koala (9.10) to Lucid Lynx (10.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=jaunty2karmic|`jaunty2karmic`]] || Bugs related to upgrades from Jaunty Jackalope (9.04) to Karmic Koala (9.10) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=intrepid2jaunty|`intrepid2jaunty`]] || Bugs related to upgrades from Intrepid Ibex (8.10) to Jaunty Jackalope (9.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=hardy2intrepid|`hardy2intrepid`]] || Bugs related to upgrades from Hardy Heron (8.04) to Intrepid Ibex (8.10) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=gutsy2hardy|`gutsy2hardy`]] || Bugs related to upgrading from Gutsy Gibbon (7.10) to Hardy Heron (8.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=feisty2gutsy|`feisty2gutsy`]] || Bugs related to upgrading from Feisty Fawn (7.04) to Gutsy Gibbon (7.10) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=edgy2feisty|`edgy2feisty`]] || Bugs related to upgrading from Edgy Eft (6.10) to Feisty Fawn (7.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=dapper2hardy|`dapper2hardy`]] || Bugs related to upgrades from Dapper Drake (6.06) to Hardy Heron (8.04) || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=cdrom-upgrade|`cdrom-upgrade`]] || Bugs related to an upgrade from CD-ROM or DVD media || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=cdrom-upgrade|cdrom-upgrade]] || Bugs related to an upgrade from CD-ROM or DVD media. || The previously described tags are specific to the [[UpdateManager]] application, if you need more general tags please visit [[Bugs/Tags]] page. From es20490446e at gmail.com Wed Dec 10 11:16:52 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 10 Dec 2014 12:16:52 +0100 Subject: I'm running an experiment about reporting upstream Message-ID: <54882BA4.3040004@gmail.com> I'm going to make an experiment: I'm going to ask users to report bugs upstream themselves by providing clear instructions about how to do so. For that I'm going to set bugs status to incomplete. But I'll be subscribed to the bug report and, if it expires, I'll tell upstream myself. The goal is to figure out if reporting upstream can be delegated to users. Just wanted to make clear that every affected report will be equally attended during this test. -------------- 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 Wed Dec 10 13:38:30 2014 From: teward at trekweb.org (Thomas Ward) Date: Wed, 10 Dec 2014 08:38:30 -0500 Subject: I'm running an experiment about reporting upstream In-Reply-To: <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> Message-ID: <9436DD6A-5DEB-48D0-94F8-454F027C134E@trekweb.org> CC bug squad because I left them off by accident. > On Dec 10, 2014, at 08:36, Thomas Ward wrote: > > While I know for almost fact users cannot handle that themselves, I want to question the scope of your experiment. > > For which bugs are you going to be working on for this? For which release? For which packages? > > > ------ > Thomas > > >> On Dec 10, 2014, at 06:16, Alberto Salvia Novella wrote: >> >> I'm going to make an experiment: I'm going to ask users to report bugs upstream themselves by providing clear instructions about how to do so. >> >> For that I'm going to set bugs status to incomplete. But I'll be subscribed to the bug report and, if it expires, I'll tell upstream myself. >> >> The goal is to figure out if reporting upstream can be delegated to users. Just wanted to make clear that every affected report will be equally attended during this test. >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad From es20490446e at gmail.com Wed Dec 10 14:41:10 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 10 Dec 2014 15:41:10 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> Message-ID: <54885B86.1030101@gmail.com> Thomas Ward: > For which bugs are you going to be working on for this? For which release? For which packages? For any. -------------- 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 Wed Dec 10 14:56:34 2014 From: teward at trekweb.org (Thomas Ward) Date: Wed, 10 Dec 2014 09:56:34 -0500 Subject: I'm running an experiment about reporting upstream In-Reply-To: <54885B86.1030101@gmail.com> References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> Message-ID: I think there may be several teams who have established special workflows and should not be covered by this. As well, if packages I watch are affected by this it will mess up my procedures for maintaining the NGINX packages as well as others. I think you should restrict your scope before running this experiment. *Sent from my iPhone. Please excuse any typos, as they are likely to happen by accident.* > On Dec 10, 2014, at 09:41, Alberto Salvia Novella wrote: > > Thomas Ward: >> For which bugs are you going to be working on for this? For which release? For which packages? > > For any. > > > From rohangarg at ubuntu.com Wed Dec 10 14:58:45 2014 From: rohangarg at ubuntu.com (Rohan Garg) Date: Wed, 10 Dec 2014 15:58:45 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: <54882BA4.3040004@gmail.com> References: <54882BA4.3040004@gmail.com> Message-ID: On Wed, Dec 10, 2014 at 12:16 PM, Alberto Salvia Novella wrote: > I'm going to make an experiment: I'm going to ask users to report bugs > upstream themselves by providing clear instructions about how to do so. > > For that I'm going to set bugs status to incomplete. But I'll be subscribed > to the bug report and, if it expires, I'll tell upstream myself. > > The goal is to figure out if reporting upstream can be delegated to users. > Just wanted to make clear that every affected report will be equally > attended during this test. > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > This is already the case for any KDE bugs that you may encounter. See the Kubuntu bug triage policy here [1] for an explanation. Cheers Rohan Garg [1] https://community.kde.org/Kubuntu/Policies#Bug_Triage From gunnarhj at ubuntu.com Wed Dec 10 15:05:00 2014 From: gunnarhj at ubuntu.com (Gunnar Hjalmarsson) Date: Wed, 10 Dec 2014 16:05:00 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> Message-ID: <5488611C.4020306@ubuntu.com> Den 2014-12-10 15:56, Thomas Ward skrev: > I think there may be several teams who have established special > workflows and should not be covered by this. As well, if packages I > watch are affected by this it will mess up my procedures for > maintaining the NGINX packages as well as others. I think you should > restrict your scope before running this experiment. Without questioning that there may be special workflows established in some teams, I think it's generally a good idea to encourage a reporter of a quality bug, which is upstream in nature but was initially filed against an Ubuntu package, to also file it upstream. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj From es20490446e at gmail.com Wed Dec 10 19:44:04 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 10 Dec 2014 20:44:04 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> Message-ID: <5488A284.5050801@gmail.com> Thomas Ward: > If packages I watch are affected by this it will mess up my > procedures for maintaining the NGINX packages as well as others. It will only affect packages whose developers asked to track bugs in an external bug tracker; as KDE, GNOME, Linux, VirtualBox, and so did. NGINX tracks its bugs in Launchpad. Projects fully tracked in Launchpad won't be affected. Thomas Ward: > I think there may be several teams who have established special > workflows and should not be covered by this. Since all the affected bugs are tracked in an upstream bug tracker, that tracker policies would still arbitrate the real triaging. Moreover, I have reported some bugs that didn't affect me upstream and when I was asked questions I didn't know what to answer. That's when I suspected that reporting upstream by a different person could be a waste of time. Rohan Garg: > This is already the case for any KDE bugs that you may encounter. So it seems somebody before me concluded that reporting upstream is an affordable task for the user and time consuming for a bug squad. I still won't say that, but sure it's worth testing and get some figures. 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 rohangarg at ubuntu.com Wed Dec 10 21:09:02 2014 From: rohangarg at ubuntu.com (Rohan Garg) Date: Wed, 10 Dec 2014 22:09:02 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: <5488A284.5050801@gmail.com> References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> <5488A284.5050801@gmail.com> Message-ID: > Rohan Garg: >> This is already the case for any KDE bugs that you may encounter. > > So it seems somebody before me concluded that reporting upstream is an > affordable task for the user and time consuming for a bug squad. > > I still won't say that, but sure it's worth testing and get some figures. The reason Kubuntu went with that approach is because we wanted the developers to directly interact with the bug reporter instead of Kubuntu Developers trying to spend trying to reproduce the bug and then reporting it upstream. That way if the developer has any follow up questions, we don't have to waste time following up with the end user with more questions. Just thought I'd share some insight why Kubuntu has that policy in place :) Cheers Rohan Garg From brian at ubuntu.com Wed Dec 10 21:30:34 2014 From: brian at ubuntu.com (Brian Murray) Date: Wed, 10 Dec 2014 13:30:34 -0800 Subject: I'm running an experiment about reporting upstream In-Reply-To: <54882BA4.3040004@gmail.com> References: <54882BA4.3040004@gmail.com> Message-ID: <20141210213034.GE9664@murraytwins.com> On Wed, Dec 10, 2014 at 12:16:52PM +0100, Alberto Salvia Novella wrote: > I'm going to make an experiment: I'm going to ask users to report > bugs upstream themselves by providing clear instructions about how > to do so. > > For that I'm going to set bugs status to incomplete. But I'll be > subscribed to the bug report and, if it expires, I'll tell upstream > myself. I think it would be a good idea to identify these bug reports with a tag so that if you are "hit by a bus" we can easily find these bug reports. Additionally, it would also allow other people to watch the experiment. -- 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 stephen.webb at canonical.com Wed Dec 10 21:40:27 2014 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Wed, 10 Dec 2014 16:40:27 -0500 Subject: I'm running an experiment about reporting upstream In-Reply-To: <5488A284.5050801@gmail.com> References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> <5488A284.5050801@gmail.com> Message-ID: <5488BDCB.5050808@canonical.com> On 12/10/2014 02:44 PM, Alberto Salvia Novella wrote: > Thomas Ward: >> If packages I watch are affected by this it will mess up my >> procedures for maintaining the NGINX packages as well as others. > > It will only affect packages whose developers asked to track bugs in an external bug tracker; as KDE, GNOME, Linux, > VirtualBox, and so did. > > NGINX tracks its bugs in Launchpad. Projects fully tracked in Launchpad won't be affected. I don't see why you would single out one particular upstream bug tracker for special treatment. If someone, for example, files a bug against the Compiz package in Ubuntu I'd want to see it sent upstream to Compiz, which happens to track its upstream bugs in Launchpad. It's just not reasonably scalable to expect the Ubuntu triageurs to do all the upstreaming themselves. It's unclear why a project participant would _not_ want to see their bugs reported upstream unless the bugs is exclusively related to Ubuntu packaging. -- Stephen M. Webb From noreply at ubuntu.com Wed Dec 10 01:58:49 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 10 Dec 2014 01:58:49 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22LibreOfficeBugWrangling=22_by_pe?= =?utf-8?q?nalvch?= Message-ID: <20141210015849.15576.90213@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "LibreOfficeBugWrangling" page has been changed by penalvch: http://wiki.ubuntu.com/LibreOfficeBugWrangling?action=diff&rev1=25&rev2=26 Comment: Due to LP#1400959 specified removing openoffice.org first. = How to file a bug = * Please do not report a LibreOffice bug without first reading this wiki article and performing all the relevant actions mentioned here. Failure to do so may delay your bug getting addressed as quickly as possible. - * First, before filing a bug report, please make sure you install the full LibreOffice suite to avoid [[https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-libreoffice-split|package split collatoral damage]], by executing at a terminal: + * First, before filing a bug report, please make sure you uninstall all openoffice.org packages first, then install the full LibreOffice suite to avoid [[https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-libreoffice-split|package split collatoral damage]], by executing at a terminal: || {{{sudo apt-get -y install libreoffice}}}|| * Please file all your LibreOffice bugs by executing at the Terminal: <
> {{{ubuntu-bug }}} <
> <
> where is the specific package you found the problem in. For example, if you have a document import issue with Writer: <
> {{{ubuntu-bug libreoffice-writer}}} From es20490446e at gmail.com Fri Dec 12 15:41:06 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Fri, 12 Dec 2014 16:41:06 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> <5488A284.5050801@gmail.com> Message-ID: <548B0C92.4070000@gmail.com> Rohan Garg: > The reason Kubuntu went with that approach is because we wanted the > developers to directly interact with the bug reporter > instead of Kubuntu Developers trying to spend trying to reproduce the > bug and then reporting it upstream. And why you decided to set its status to "invalid"? Wouldn't this prevent downstream contributors to find and fix KDE bugs themselves? Brian Murray: > I think it would be a good idea to identify these bug reports with a > tag so that if you are "hit by a bus" we can easily find these bug > reports. > Additionally, it would also allow other people to watch the > experiment. Tag added to as "asked-to-upstream". Stephen M. Webb: > I don't see why you would single out one particular upstream bug > tracker for special treatment. If someone, for example, files a bug > against the Compiz package in Ubuntu I'd want to see it sent upstream > to Compiz, which happens to track its upstream bugs in Launchpad. The real topic of this conversation is not about reporting upstream, but about who shall fill a new report when that is required for reporting to upstream. -------------- 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 rohangarg at ubuntu.com Fri Dec 12 15:47:15 2014 From: rohangarg at ubuntu.com (Rohan Garg) Date: Fri, 12 Dec 2014 16:47:15 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: <548B0C92.4070000@gmail.com> References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> <5488A284.5050801@gmail.com> <548B0C92.4070000@gmail.com> Message-ID: > And why you decided to set its status to "invalid"? Wouldn't this prevent > downstream contributors to find and fix KDE bugs themselves? > Primarily because it's not a bug introduced by Kubuntu Devs or a fault of any patches in Kubuntu. Cheers Rohan Garg From es20490446e at gmail.com Fri Dec 12 19:17:57 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Fri, 12 Dec 2014 20:17:57 +0100 Subject: I'm running an experiment about reporting upstream In-Reply-To: References: <54882BA4.3040004@gmail.com> <035C4AAE-2010-40C3-AD52-EB900786A669@trekweb.org> <54885B86.1030101@gmail.com> <5488A284.5050801@gmail.com> <548B0C92.4070000@gmail.com> Message-ID: <548B3F65.8080500@gmail.com> Rohan Garg: > Primarily because it's not a bug introduced by Kubuntu Devs or a fault > of any patches in Kubuntu. So you thought it would bring better quality to Kubuntu if its contributors concentrated in bugs specific to the distribution. Is it that? -------------- 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 noreply at ubuntu.com Fri Dec 12 15:31:13 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 12 Dec 2014 15:31:13 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Tags=22_by_es20490446e?= Message-ID: <20141212153113.12442.59787@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Tags" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Tags?action=diff&rev1=196&rev2=197 - ## page was renamed from https:/wiki.ubuntu.com/Bugs/Tags - ## page was renamed from linex - ## page was renamed from Bugs/Tags - ## page was renamed from BugSquad/Tags - ||<>|| <> Tags provide us ways to group bugs across packages, easily find certain types of bugs or divide a package's bug reports into smaller parts.<
><
>Below are some standard tags and information about when to use the tag when working on bug reports about Ubuntu. + == Different ways you can help == @@ -21, +17 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging|needs-packaging]] || Packaging requests - software that isn't packaged for Ubuntu yet || || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-sound|needs-sound]] || A bug that needs new sound to be created || + == Generic bug tags == || '''Tag''' || '''Use case''' || @@ -28, +25 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-collected|apport-collected]] || A bug that has had apport-collect ran against it which will contain additional information. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-crash|apport-crash]] || A crash reported by apport - Ubuntu's automated problem reporter. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-package|apport-package]] || A bug reported by apport when a package operation failed. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=asked-to-upstream|asked-to-upstream]] || The user was asked to report the bug upstream himself. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=package-conflict|package-conflict]] || A bug reported by apport when a package operation failed due to a conflict with a file provided by another package. || || [[https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=derivatives|derivatives]] || Bugs related to Derivatives. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=desktop-file|desktop-file]] || The bug requests the addition/fix of a .desktop file. || @@ -55, +53 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=dist-upgrade|dist-upgrade]] || A bug that was encountered when upgrading between releases of Ubuntu. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=testcase|testcase]] || A bug which contains a test case - steps to recreate the bug. || + == Application Specific Tags == === Cheese Specific === @@ -63, +62 @@ || '''Tag''' || '''Use case''' || || [[https://launchpad.net/ubuntu/+bugs?field.tag=gstreamer-error|gstreamer-error]] || Bug is related to bad drivers and not Cheese. ''Switch bug to the linux package for missing/bad drivers.''|| || [[https://launchpad.net/ubuntu/+bugs?field.tag=gstreamer-ok|gstreamer-ok]] || Video gstreamer input works fine (drivers seem fine), most likely a Cheese bug. || + === Unity === @@ -73, +73 @@ || [[https://launchpad.net/unity/+bugs?field.tag=needs-design|needs-design]] || A bug that needs UI design done first. || || [[https://launchpad.net/unity/+bugs?field.tag=backlog|backlog]] || Things that design has done and has finished on that needs to be implemented. || + === Update Manager === <> + == Other specific bug tags == @@ -88, +90 @@ ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-applet|indicator-applet]] || Bugs related to the use of the Indicator Applet that are not in the 'indicator-applet' package (no Application Indicators). || ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-application|indicator-application]] || Bugs related to the use of Indicator Application that are not in the 'indicator-application' package. || ||[[https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=trayaway|trayaway]] || Bugs related to the [[NotificationAreaTransition|Notification Area transition]]. || + === Hardware Specific === @@ -100, +103 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=ume|ume]] || These bugs deal with Ubuntu Mobile and Embeded systems. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=armel|armel]] || These bugs deal with Ubuntu arm systems. || + === Historical Tags === These tags were relevant previously for Ubuntu bugs and may still appear in some bugs. @@ -108, +112 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-amd64-retrace|need-amd64-retrace]] || The bug contains a crash report that needs retracing with `apport-retrace` on `amd64`. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-i386-retrace|need-i386-retrace]] || The bug contains a crash report that needs retracing with `apport-retrace` on `i386`. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=need-powerpc-retrace|need-powerpc-retrace]] || The bug contains a crash report that needs retracing with `apport-retrace` on `powerpc`. || + === Kernel Specific === @@ -126, +131 @@ For more tags see [[Kernel/Tagging|Kernel/Tagging]]. + === Kubuntu Specific === || '''Tag''' || '''Use case''' || @@ -138, +144 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-report|needs-upstream-report]] || This bug needs the report to be forwarded to the upstream project. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-upstream-sync|needs-upstream-sync]] || This bug has been forwarded to the upstream project which has released a fix that has not been merged yet. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=upstream|upstream]] || This bug is reported to the upstream project. || + === More specific === @@ -157, +164 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=uec-images|uec-images]] || This bug is related to the Ubuntu Enterprise Cloude (UEC) [[http://uec-images.ubuntu.com/releases|images]]. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=xinerama|xinerama]] || This bug is a xinerama problem. Multiple-monitor configuration. || + === Patch specific === || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch|patch]] || A patch in its final form, and can immediately be released into the appropriate Ubuntu repository as outlined in [[https://wiki.ubuntu.com/Bugs/Patches]]. A raw patch copied from an external location, or possible/test/draft patches wouldn't fit this criteria. || @@ -170, +178 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-rejected-upstream|patch-rejected-upstream]] || This bug has a patch attached to it that has been rejected by upstream. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=patch-upstreaminput|patch-upstreaminput]] || This bug has a patch attached to it that has been forwarded upstream and requires their input or incorporation. || + === Regression specific === See the [[http://qa.ubuntu.com/reports/regression/regression_tracker.html|regression tracker]] for a list of these bugs and [[QATeam/RegressionTracking]] for more information. @@ -183, +192 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=needs-bisect|performing-bisect]] || The reporter, developer, or triager is in the process of performing a bisection. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=bisect-done|bisect-done]] || Add when a bisect has been completed and the offending commit(s) identified. || + === SRU Specific === See StableReleaseUpdates for more information. @@ -192, +202 @@ || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-failed|verification-failed]] || A Stable Release Update bug with a package in -proposed that has been verified to not fix the bug. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=verification-needed|verification-needed]] || A Stable Release Update bug with a package in -proposed needing testing. || + === X Specific === For X tags please check [[X/Tagging|X Tagging]] with all the official X tags From es20490446e at gmail.com Sun Dec 14 13:32:24 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 14 Dec 2014 14:32:24 +0100 Subject: The bottleneck is triaging Message-ID: <548D9168.50000@gmail.com> Metrics suggest that the bottleneck of bug management is in triaging, not in fixing. Fixing evolution: http://tinyurl.com/n7qt359 Triaging evolution: http://tinyurl.com/kyf8h54 So what will improve efficacy of bug management right now will be improvements on how to triage more easily. -------------- 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 contact at ekimia.fr Sun Dec 14 13:46:54 2014 From: contact at ekimia.fr (Michel Memeteau - EKIMIA) Date: Sun, 14 Dec 2014 14:46:54 +0100 Subject: The bottleneck is triaging In-Reply-To: <548D9168.50000@gmail.com> References: <548D9168.50000@gmail.com> Message-ID: Alberto , the solution is not to flag bugs as won't fix when you don't understand them correctly like this one : https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1371274 Please don't do that if you are not 100% sure of what you are doing. <------------------------------------------------------------------------------------------------------------------> Michel Memeteau - Directeur. Notre Boutique Ordinateurs GNU/Linux : http://shop.ekimia.fr 49 chemin de l'union 13720 La Bouilladisse - France. Fixe : +33 (0) 972308334 Mobile : +33(0) 624808051 <------------------------------------------------------------------------------------------------------------------> 2014-12-14 14:32 GMT+01:00 Alberto Salvia Novella : > Metrics suggest that the bottleneck of bug management is in triaging, not in > fixing. > > Fixing evolution: http://tinyurl.com/n7qt359 > Triaging evolution: http://tinyurl.com/kyf8h54 > > So what will improve efficacy of bug management right now will be > improvements on how to triage more easily. > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > From teward at trekweb.org Sun Dec 14 14:17:28 2014 From: teward at trekweb.org (Thomas Ward) Date: Sun, 14 Dec 2014 09:17:28 -0500 Subject: The bottleneck is triaging In-Reply-To: <548D9168.50000@gmail.com> References: <548D9168.50000@gmail.com> Message-ID: <548D9BF8.4060302@trekweb.org> On 12/14/2014 08:32 AM, Alberto Salvia Novella wrote: > Metrics suggest that the bottleneck of bug management is in triaging, > not in fixing. I'm going to come out and say that you haven't defined the scope of your metrics or your method of assessing the metrics. Therefore, I can only assume your metrics are about current bug states, rather than historically analyzing Fixed vs. "Fixed After Triaged". If that is the case, these metrics don't accurately reflect anything in the 'process' at all. You need to explain how you got those metrics and what was actually assessed before the metrics can be a good reflection of any status. So, I ask: What information is your metrics based on: In-depth historical analysis of the bug statuses to determine if having anything marked "Triaged" has any real impact on non-Main packages? Or just the current 'bug status' of the individual bugs? Or just a general overview of bug status over time? (Also, a single month of time, and two data points in your diagram, is not an accurate or usable sample of data for metrics analyzing a process - I'd suggest your metrics be expanded to start at the beginning of a dev cycle and take data points monthly up until the end of the dev cycle for a release and then show the metrics) > > Fixing evolution: http://tinyurl.com/n7qt359 > Triaging evolution: http://tinyurl.com/kyf8h54 > > So what will improve efficacy of bug management right now will be > improvements on how to triage more easily. > Are you certain that's the only bottleneck? Part of me believes that another potential bottleneck is *not* actually the triage process - rather the hurdle of finding individuals willing to maintain the Universe software. As it currently stands, Universe is community supported, so patches and fixes end up on the Community's radar instead of the developers in Main. This was the case with the `nginx` package before I kind of took it under my wing. It is also the case with many other packages still in Universe, including utility tools that network analysts and developers use very day such as Wireshark, in that patches are not actively backported to them (which results in unfixed issues and security holes, the latter of which is not necessarily on the Community radar, but is still relevant to mention). Also, as well, (in the message after the one I'm replying to now), Michel Memeteau makes a good point: Marking bugs as "Won't Fix" or a status that is not relevant in the specific case are another bottleneck - triagers who don't fully understand what should be done. As the bug referenced by Michel had its status reversed by Marc Deslauriers, I won't dwell on this, but the point is still made. Thomas From es20490446e at gmail.com Sun Dec 14 16:22:41 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 14 Dec 2014 17:22:41 +0100 Subject: The bottleneck is triaging In-Reply-To: References: <548D9168.50000@gmail.com> Message-ID: <548DB951.3060400@gmail.com> Thomas Ward: > I'm going to come out and say that you haven't defined the scope of > your metrics or your method of assessing the metrics. Sorry, that's true. You can analyse that in . Thomas Ward: > Are you certain that's the only bottleneck? > > Part of me believes that another potential bottleneck is not > actually the triage process - rather the hurdle of finding > individuals willing to maintain the Universe software. The metric is for Ubuntu as a hole. So it would indicate that if a project doesn't gather enough development attention it isn't because people isn't interested in helping Ubuntu, but that particular project. Michel Memeteau: > Alberto , the solution is not to flag bugs as won't fix when you don't > understand them correctly like this one : > > https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1371274 > > Please don't do that if you are not 100% sure of what you are doing. This is not related with the topic in this thread. You are welcome to open a new conversation, but not to hijack ongoing ones. Thomas Ward: > Marking bugs as "Won't Fix" or a status that is not relevant in the > specific case are another bottleneck - triagers who don't fully > understand what should be done. Google stated a long time ago that Chrome is Chromium with the capability of running proprietary code. Chromium developers closed it upstream because patching that bug is equal to building a second Chrome browser. -------------- 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 Sat Dec 13 07:05:09 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Sat, 13 Dec 2014 07:05:09 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141213070509.16322.31958@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=276&rev2=277 Comment: Due to LP#1402095 added support note on EoL releases, and upgrading with third-party software installed. == All bug reports == + * '''Please do not file bug reports about End-of-Life operating systems.''' <
> This includes release of Ubuntu, and alternative operating systems. Expecting Ubuntu to provide interoperability with an insecure, end-of-life operating system is simply irresponsible, and inconsiderate of the finite resources of the Ubuntu Community. Information regarding supported Ubuntu releases are available [[https://wiki.ubuntu.com/Releases|here]]. Please see the website of the vendor of the operating system for EOL and support information. * '''Please do not speculate on what you think is or isn't a duplicate report.''' <
> For example, "I googled around and found bug report number..." This is largely unhelpful as it tends not to be a duplicate, and already has been or easily done by triagers and developers. Instead, if you are the original reporter, ensuring the report has all the requested testing information performed would be the fastest way to ensure your bug is resolved as soon as possible. If you are not the original reporter, it's best to file a new report, so that necessary debugging attachments are reviewed. It is a common misconception that filing a potential duplicate report is wasteful. Filing a new report is quite helpful, and is preferred to ease triaging. * '''Please do not quote Wikipedia and other non-primary resource information as fact on [[Launchpad]].''' * '''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. @@ -303, +304 @@ * '''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. * '''Please provide all relevant information from [[https://wiki.ubuntu.com/DebuggingProcedures]] when you first report your bug'''. <
> This is one of the top reasons why bugs do not get marked [[https://wiki.ubuntu.com/Bugs/Status|Triaged]], as the minimum requirements for triaging, and dealing with the problem by a developer are not provided. * '''Please avoid arguing with triagers and developers.''' <
> If a triager or developer asks you to provide information, just provide the information as requested. An example of this is claiming exemption because you or someone else filed a bug report upstream or downstream (which is publicly viewable, and has no restrictions on who can file). You are being asked for this information so that it would provide more information on how to fix the problem. Also, not everyone has access to the hardware you are reporting against, or reproduce the problem as advised in the report. Having you provide the information helps eliminate the difficulty in fixing your bug. If you have a strong disagreement with what a triager or developer is asking of you, please resolve it with them directly via personal message, not on the bug report. This avoids turning a bug development report into a “let’s talk about talking about the problem” tangent, distracting from having your bug solved. The Ubuntu community takes a favor to objective, technical discourse. - * '''Please do not report bugs about software in [[PPA]]s.''' <
> This is because software in PPAs are not provided by the official Ubuntu repositories. Instead, the PPA homepage would have a contact point and preference of the PPA provider. The exception is [[LibreOffice]] as per [[https://lists.launchpad.net/libreoffice/msg00072.html|this mail]], as LibreOffice is too big to be tracked via email: as described in the mail, file a bug on Launchpad with tag `ppa`. + * '''Please do not report bugs about software in [[PPA]]s.''' <
> This is because software in PPAs are not provided by the official Ubuntu repositories, and in turn not supported. Instead, the PPA homepage would have a contact point and preference of the PPA provider. The exception is [[LibreOffice]] as per [[https://lists.launchpad.net/libreoffice/msg00072.html|this mail]], as LibreOffice is too big to be tracked via email: as described in the mail, file a bug on Launchpad with tag `ppa`. + * '''Please do not report upgrade failures when you have installed software that is self-compiled, from a third party deb not provided by the Ubuntu repositories, or from a PPA.''' In order to maximize your upgrade success, all this software would need to be uninstalled, or replaced with the corresponding software from the Ubuntu repositories if it is mandatory to keep. * '''Please do not add project tasks to bug reports that are invalid because they are not supported'''. <
> For example, if you were using the LibreOffice PPA and reported a bug against the package libreoffice (Ubuntu), which would be marked Status Invalid, please do not add the Launchpad Project [[https://launchpad.net/df-libreoffice|df-libreoffice]] to the report, or change the package libreoffice (Ubuntu) to the project df-libreoffice. The purposes of adding the upstream project to a report is to track valid bugs in Ubuntu that are valid upstream, and may have been reported upstream, not to start another upstream bug tracker. * '''When posting new comments to a Launchpad report, please do not reply and include every past comment made.''' <
> Doing so makes it onerous to read a report, and is wasteful. Instead just make your new comment, or just include the relevant portion of a previous comment you are responding to. * '''Please do not announce in a report you did not file, that you filed a new report.''' From noreply at ubuntu.com Sun Dec 14 12:06:07 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 14 Dec 2014 12:06:07 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingProcedures=22_by_penalv?= =?utf-8?q?ch?= Message-ID: <20141214120607.2493.79441@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingProcedures" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingProcedures?action=diff&rev1=117&rev2=118 Comment: Funnelled all GNOME application articles into one URL as it has required stacktrace information applicable to all GNOME applications. * [[Unity/FilingBugs|Unity]] * [[DebuggingAyatana|Ayatana project]] - * [[DebuggingBanshee|Banshee]] * [[DebuggingEmacs|Emacs]] - * [[DebuggingEvince|Evince Document Viewer]] - * [[DebuggingEvolution|Evolution Mail]] * [[DebuggingFirefox|Firefox Web Browser]] + * [[DebuggingGNOME|GNOME applications - Applets, Banshee, Evince, Evolution, Gconf, Network Manager, Power Manager, Screensaver (screen locking), System Tools]] - * [[DebuggingGNOME|GNOME applications]] - * [[DebuggingGNOMEApplets|GNOME applets]] - * [[DebuggingGNOMEPowerManager|GNOME power manager]] - * [[DebuggingGnomeSystemTools|GNOME System Tools]] - * [[DebuggingScreenLocking|GNOME Screensaver (and screen locking)]] - * [[DebuggingGconf|Gconf]] * [[DebuggingGwibber|Gwibber]] * [[DebuggingKDE|KDE applications]] * [[https://wiki.ubuntu.com/LibreOfficeBugWrangling|LibreOffice]] * [[DebuggingGnash|Gnash Flash plugin]] - * [[DebuggingNetworkManager|Network Manager]] * [[DebuggingModemmanager|Modem Manager]] * [[DebuggingTelepathy|Telepathy framework]] * [[DebuggingJava|Java]] From noreply at ubuntu.com Sun Dec 14 10:37:45 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 14 Dec 2014 10:37:45 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingProgramCrash=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141214103745.23562.12860@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingProgramCrash" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingProgramCrash?action=diff&rev1=119&rev2=120 Comment: RM'ed erroneous / as running command verbatim caused it not to work. If there is no -dbg package: - 1. Create an `/etc/apt/sources.list.d/ddebs.list` by running the following line at a terminal: + 1. Create an `/etc/apt/sources.list.d/ddebs.list` by running the following line at a terminal: {{{ - {{{ - echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | \ + echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list }}} - sudo tee -a /etc/apt/sources.list.d/ddebs.list - }}} - 1. Stable releases (not alphas and betas) require two more lines adding to the same file, which is done by the following terminal command: + 1. Stable releases (not alphas and betas) require two more lines adding to the same file, which is done by the following terminal command: {{{ - {{{ echo "deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse - deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | \ + deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list }}} - sudo tee -a /etc/apt/sources.list.d/ddebs.list - }}} You may also add these lines using the Synaptic Package Manager: * Choose ''Synaptic'' via the ''System > Administration'' menu. * Choose ''Software Sources'' or ''Repositories'' via the ''Settings'' menu, and click on the ''Third-Party Software'' tab. * Click the ''Add'' button and enter each ''deb ...'' line as above one by one and click the ''Add Source'' button (you will have to add these lines one at a time). - 1. Import the debug symbol archive signing key: + 1. Import the debug symbol archive signing key: {{{ - {{{ - sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 + sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 }}} - }}} - 1. Then run + 1. Then run: {{{ - {{{ - sudo apt-get update + sudo apt-get update }}} - }}} to update your package list or click the ''Reload'' button if you used the Synaptic Package Manager. - 1. The debug symbol packages have the '-dbgsym' suffix attached, so to install the debug symbols for the package 'yelp', you first run: + 1. The debug symbol packages have the '-dbgsym' suffix attached, so to install the debug symbols for the package 'yelp', you first run: {{{ - {{{ - apt-cache policy yelp + apt-cache policy yelp }}} - }}} This will show you the version number currently installed (we'll use 2.22.1-0ubuntu2.8.04.1 in this example). '''NOTE:''' 'yelp' [which is the package name of "Help and Support" located under the 'System' menu] is ''just an example'' and '''not''' a part of the command: 'yelp' is only used to demonstrate the procedure. You must replace 'yelp' with the name of the package you want to debug. - 1. Install the debug symbols: + 1. Install the debug symbols: {{{ - {{{ - sudo apt-get install yelp-dbgsym=2.22.1-0ubuntu2.8.04.1 + sudo apt-get install yelp-dbgsym=2.22.1-0ubuntu2.8.04.1 }}} - }}} You can also use the Synaptic Package Manager to search for 'yelp-dbgsym' and install it from there. The above procedure will install the debug symbol package for yelp only. Chances are that yelp uses shared libraries in other packages and debug symbols for them might be required in order to obtain a readable stack trace or perform other debugging tasks. - You can download the following [[attachment:list-symbols-packages-v2.1.sh |shell script (list-symbols-packages-v2.1.sh)]] to resolve all the dependencies. Attaching a debugger to an already running process may require elevated privileges even if you own the process. The following invocation will print out the list of files to install. + You can download the following [[attachment:list-symbols-packages-v2.1.sh |shell script (list-symbols-packages-v2.1.sh)]] to resolve all the dependencies. Attaching a debugger to an already running process may require elevated privileges even if you own the process. The following invocation will print out the list of files to install. {{{ - {{{#!highlight bash sudo bash ./list-symbols-packages-v2.sh -p $(pidof yelp)}}} - To automatically install them apt can be called with the input from the script. The script is invoked with {{{-t}}} for a terse output without the descriptions of the packages and error messages are suppressed. + To automatically install them apt can be called with the input from the script. The script is invoked with {{{-t}}} for a terse output without the descriptions of the packages and error messages are suppressed {{{ - - {{{#!highlight bash - sudo bash ./list-symbols-packages-v2.sh -t -p $(pidof yelp) 2>/dev/null|\ + sudo bash ./list-symbols-packages-v2.sh -t -p $(pidof yelp) 2>/dev/null | xargs -d $'\n' sudo apt-get install }}} - xargs -d $'\n' sudo apt-get install }}} /!\ Version 2 of this script makes it compatible with the newer GDB (which no longer loads all libraries at startup by default). -v2 currently only works if you run it against a currently-executing binary (i.e., with '-p $(pidof '). The [[attachment:list-symbols-packages.sh|older version]] of the script is also available. @@ -104, +86 @@ === How do we remove all this stuff after getting the trace and get back to a normal system? === - You can remove all debug symbol packages and the ddebs repositories with the following commands: + You can remove all debug symbol packages and the ddebs repositories with the following commands: {{{ - - {{{ sudo apt-get remove \.*-dbgsym sudo rm /etc/apt/sources.list.d/ddebs.list - sudo apt-get update + sudo apt-get update }}} - }}} - === References === * Announcement: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-September/000195.html == The Xorg server == + - The X server will by default trap its own crashes and dump a stack trace in /var/log/Xorg.0.log. However, this stack trace is modified by the signal handler itself. To get a "normal" crash, which will trigger a core dump (and ''apport'' reporting), add this to your /etc/X11/xorg.conf: + The X server will by default trap its own crashes and dump a stack trace in /var/log/Xorg.0.log. However, this stack trace is modified by the signal handler itself. To get a "normal" crash, which will trigger a core dump (and ''apport'' reporting), add this to your /etc/X11/xorg.conf: {{{ - {{{ Section "ServerFlags" Option "NoTrapSignals" "true" - EndSection + EndSection }}} - }}} Please see [[X/Debugging]] for how to debug Xorg server crashes. == Info for the BugSquad == From es20490446e at gmail.com Wed Dec 17 16:20:37 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 17 Dec 2014 17:20:37 +0100 Subject: How can I figure out which package triggered this wrong upgrade? Message-ID: <5491AD55.10501@gmail.com> In , how can I figure out which package triggered the wrong upgrade? Thank you. -------------- 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 brian at ubuntu.com Wed Dec 17 16:26:47 2014 From: brian at ubuntu.com (Brian Murray) Date: Wed, 17 Dec 2014 08:26:47 -0800 Subject: How can I figure out which package triggered this wrong upgrade? In-Reply-To: <5491AD55.10501@gmail.com> References: <5491AD55.10501@gmail.com> Message-ID: <20141217162647.GS30743@murraytwins.com> On Wed, Dec 17, 2014 at 05:20:37PM +0100, Alberto Salvia Novella wrote: > In , how > can I figure out which package triggered the wrong upgrade? This could be the following bug: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-331/+bug/1401390 -- 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 es20490446e at gmail.com Wed Dec 17 20:11:49 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 17 Dec 2014 21:11:49 +0100 Subject: How can I figure out which package triggered this wrong upgrade? In-Reply-To: <20141217162647.GS30743@murraytwins.com> References: <5491AD55.10501@gmail.com> <20141217162647.GS30743@murraytwins.com> Message-ID: <5491E385.2070207@gmail.com> Alberto Salvia Novella: > In , how > can I figure out which package triggered the wrong upgrade? Brian Murray: > This could be the following bug: > https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-331/+bug/1401390 Does the following demonstrate it?: Bug 1401390 description (http://tinyurl.com/pbytwqa): > The libhwloc-plugins package need to depend on ocl-icd-libopencl1 (>= > 1.0) | libopencl1 rather than just on libopencl1, since the nvidia > driver provides libopencl1 too now. Bug 1403008 APT log (http://tinyurl.com/op73el8): > Remove from libhwloc-plugins (1.8-1ubuntu1) ... > Removing nvidia-opencl-icd-331-updates (331.113-0ubuntu0.0.4) ... > Removing nvidia-libopencl1-331 updates (331.113-0ubuntu0.0.4) ... > Removing nvidia-331-updates etc. (331.113-0ubuntu0.0.4) ... > Removing all DKMS Modules > Done. -------------- 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 noreply at ubuntu.com Sun Dec 14 19:43:22 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 14 Dec 2014 19:43:22 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Backtrace=22_by_penalvch?= Message-ID: <20141214194322.27351.32230@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Backtrace" page has been changed by penalvch: http://wiki.ubuntu.com/Backtrace?action=diff&rev1=39&rev2=40 Comment: Added support note on disabling apport. <> ||<>|| + + = Introduction = + - A backtrace shows a listing of which program functions are still active. Since functions are nested when they are called, the program must record where it left one function, to jump into an inner one. It does this on the stack, which we dump for the backtrace. + A backtrace shows a listing of which program functions are still active. Since functions are nested when they are called, the program must record where it left one function, to jump into an inner one. It does this on the stack, which we dump for the backtrace. By getting a backtrace at the point of a bug, a developer may be able to isolate where that bug is, because it will narrow down to the function, or even the line, that caused the erroneous behaviour. + = Prepare your environment to gather a backtrace = + + By default, a program called [[https://wiki.ubuntu.com/Apport|apport]] is enabled and running, which preempts gdb. However, to gather a backtrace manually, apport needs to be disabled first. One may do this via a terminal: {{{ + sudo nano /etc/default/apport }}} + + and change: {{{ + enabled=1 }}} + + to: {{{ + enabled=0 }}} + + save, close, and restart. + + == Kubuntu == + - When using KDE the KDE Crash Handler will intercept debugging information. However, it is possible to disable the KDE Crash Handler when you are launching an application by passing the --nocrashhandler argument to the application. For example, 'kget --nocrashhandler' instead of 'kget'. + When using KDE, the KDE Crash Handler will intercept debugging information. However, it is possible to disable the KDE Crash Handler when you are launching an application by passing the --nocrashhandler argument to the application. For example, running the program from a terminal via: {{{ + kget --nocrashhandler + + = Applications using Mono = + + To obtain a backtrace from a Mono application such as Beagle or F-Spot, use Mono's {{{--debug}}} option, e.g.{{{ + mono --debug /usr/lib/f-spot/f-spot.exe }}} = Generation = <> - 1. Please ensure you have packages with debug symbols installed. You can do this by following the instructions at DebuggingProgramCrash. + 1. Please ensure you have packages with debug symbols installed. You can do this by following the instructions at DebuggingProgramCrash. - 1. Make sure the GNU Debugger is installed. {{{ + 1. Make sure the GNU Debugger is installed. {{{ - sudo apt-get install gdb + sudo apt-get install gdb }}} + 1. Start the program under control of `gdb` via a terminal (some programs run as root, so one would use {{{sudo gdb}}} instead of just {{{gdb}}} below): {{{ - }}} - 1. Start the program under control of `gdb`: {{{ gdb 2>&1 | tee ~/gdb-.txt (gdb) handle SIG33 pass nostop noprint (gdb) set pagination 0 (gdb) run - }}} (If the program must run as root, use {{{sudo gdb}}} instead of just {{{gdb}}} above.) + }}} - 1. The program will start. Perform any actions necessary to reproduce the crash. If the program hangs but doesn't crash you can press ctrl+c in gdb while the program is frozen and then continue with the next step. + 1. The program will start. Perform any actions necessary to reproduce the crash. If the program hangs but doesn't crash you can press ctrl+c in gdb while the program is frozen and then continue with the next step. 1. Retrieve a backtrace: {{{ (gdb) backtrace full (gdb) info registers (gdb) x/16i $pc (gdb) thread apply all backtrace - (gdb) quit + (gdb) quit }}} - }}} 1. Attach the complete output from GDB, contained in gdb-.txt, in your bug report. You will find the file in your home directory /home//. - - = Applications using Mono = - - To obtain a backtrace from a Mono application such as Beagle or F-Spot, use Mono's {{{--debug}}} option, e.g.{{{ - mono --debug /usr/lib/f-spot/f-spot.exe - }}} = Already running programs = - You can ask GDB to attach to a program that's already running. This is useful for debugging things that start up, but crash when you perform a particular task. + You can ask GDB to attach to a program that's already running. This is useful for debugging things that start up, but crash when you perform a particular task. - 1. Make sure the GNU Debugger is installed. {{{ + 1. Make sure the GNU Debugger is installed. {{{ - sudo apt-get install gdb + sudo apt-get install gdb }}} - }}} 1. Find the process ID of : {{{ - pidof + pidof }}} - }}} - 1. Start `gdb`: {{{ + 1. Start `gdb` (some programs run as root, so one would use {{{sudo gdb}}} instead of just {{{gdb}}} below): {{{ gdb 2>&1 | tee gdb-.txt (gdb) handle SIG33 pass nostop noprint (gdb) set pagination 0 - (gdb) attach + (gdb) attach }}} - }}} (If the program is running as root, use {{{sudo gdb}}} instead of just {{{gdb}}} above.) 1. Continue the : {{{ - (gdb) continue + (gdb) continue }}} - }}} - 1. The program will continue running. Perform any actions necessary to reproduce the crash. If the program hangs but doesn't crash you can press ctrl+c in gdb while the program is frozen and then continue with the next step. + 1. The program will continue running. Perform any actions necessary to reproduce the crash. If the program hangs but doesn't crash you can press ctrl+c in gdb while the program is frozen and then continue with the next step. 1. Retrieve a backtrace: {{{ (gdb) backtrace full (gdb) info registers (gdb) x/16i $pc (gdb) thread apply all backtrace - (gdb) quit + (gdb) quit }}} - }}} 1. Attach the complete output from GDB, contained in gdb-.txt, in your bug report. Note that you can also set logging to a file like this: {{{ (gdb) set logging file gdb-.txt - (gdb) set logging on + (gdb) set logging on }}} - }}} = Core Files = - You are also able to retrace a core file if you have one produced. (I believe these are disabled by default) + You are also able to retrace a core file if you have one produced (I believe these are disabled by default). 1. Load the core file into the debugger {{{ - gdb -c 2>&1 | tee gdb-.txt + gdb -c 2>&1 | tee gdb-.txt }}} - }}} 2. Retrieve a backtrace of the crash: {{{ (gdb) backtrace full (gdb) info registers (gdb) x/16i $pc (gdb) thread apply all backtrace - (gdb) quit + (gdb) quit }}} - }}} 3. Attach the complete output from GDB, contained in gdb-.txt, in your bug report. You will find the file in your home directory /home//. = Other resources = + * [[http://live.gnome.org/GettingTraces|Another useful how-to]] = Summary in script form = You can automate backtrace collection [[#generation|as described above]] using this Bourne shell script: - * save it somewhere in your $PATH - * make it executable + * make it executable {{{ - - {{{ #!/bin/sh - #--------------------------------------------------------------------- usage() { cat< Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Tags" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Tags?action=diff&rev1=197&rev2=198 || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-collected|apport-collected]] || A bug that has had apport-collect ran against it which will contain additional information. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-crash|apport-crash]] || A crash reported by apport - Ubuntu's automated problem reporter. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=apport-package|apport-package]] || A bug reported by apport when a package operation failed. || - || [[https://launchpad.net/ubuntu/+bugs?field.tag=asked-to-upstream|asked-to-upstream]] || The user was asked to report the bug upstream himself. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=package-conflict|package-conflict]] || A bug reported by apport when a package operation failed due to a conflict with a file provided by another package. || || [[https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=derivatives|derivatives]] || Bugs related to Derivatives. || || [[https://launchpad.net/ubuntu/+bugs?field.tag=desktop-file|desktop-file]] || The bug requests the addition/fix of a .desktop file. || @@ -207, +206 @@ For X tags please check [[X/Tagging|X Tagging]] with all the official X tags + + == Experiments tags == + + || '''Tag''' || '''Use case''' || + || [[https://launchpad.net/ubuntu/+bugs?field.tag=asked-to-upstream|asked-to-upstream]] || The user was asked to report the bug upstream himself. || + || [[https://launchpad.net/ubuntu/+bugs?field.tag= notified-as-critical|notified-as-critical ]] || The user asked the bug to be marked as critical. || + + ---- Go back to '''[[BugSquad]]'''.<
> [[CategoryBugSquad]] From noreply at ubuntu.com Thu Dec 18 00:35:49 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 18 Dec 2014 00:35:49 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingEvince=22_by_penalvch?= Message-ID: <20141218003549.7937.10250@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingEvince" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingEvince?action=diff&rev1=17&rev2=18 Comment: 1) Overhauled article. 2) Modified reporting bugs upstream as per upstream preference https://bugzilla.gnome.org/show_bug.cgi?id=741689 . = Introduction = - [[http://gnome.org/projects/evince/|Evince]] is the default application in Ubuntu for opening .pdf, .ps, .djvu and other similar types of files. + [[http://gnome.org/projects/evince/|Evince]] is the default application in Ubuntu for opening .pdf, .ps, .djvu, and other supported files as outlined by the project. + = Not a bug = - Most bugs related to Evince fall into 3 categories: - 1. Evince crashes when I open a specific document (or when I open it and perform a specific action, like scroll, zoom or rotate) - 1. Evince does not display ("render") the document correctly - 1. Evince displays the document as it should, but then doesn't print it correctly - = Common issues = + The following specific cases are not bugs to report: - == Dvi files == + == Evince can't display dvi files == - Evince uses texlive to render .dvi files. If you cannot open a .dvi file (error message "Unable to open document. DVI document has incorrect format"), install the '''texlive''' package and try again. (There's [[https://bugs.launchpad.net/ubuntu/+source/evince/+bug/42410|bug report #42410]] about correcting this error message) + Evince uses texlive to render .dvi files. If you cannot open a .dvi file (error message "Unable to open document. DVI document has incorrect format"), install the '''texlive''' package and try again. (There's [[https://bugs.launchpad.net/ubuntu/+source/evince/+bug/42410|bug report #42410]] about correcting this error message). - == CJK fonts == + == Evince can't display CJK fonts == CJK stands for Chinese-Japanese-Korean. A pdf that includes such text but lacks the embedded fonts will not render correctly unless you install the package '''poppler-data'''. = Debugging procedure = + In all reports, please ensure you attach uncompressed/untarred document that the issue is reproducible with. + == Crash or Freeze == - In case Evince crashes, follow standard [[DebuggingProgramCrash]] procedures. + If Evince crashes, follow report this following [[https://wiki.ubuntu.com/ReportingBugs]]. == Rendering issues == - - If the crash/incorrect rendering appears only with a specific document, obtaining that document will help. Here's a stock reply to use in this case: - - {{{ - Thank you for taking the time to report this bug and helping to make Ubuntu even better! It would be quite helpful if you attach the document you are having a problem with so we can better recreate this bug and work on fixing it. Thanks in advance. - }}} Once you have the document and have confirmed it doesn't render as it's supposed to in Evince, you have to find the right package for this bug. Evince uses: * [[http://poppler.freedesktop.org/|libpoppler]] for rendering pdf files @@ -45, +38 @@ * [[http://cairographics.org/|libcairo]] for 2D vector graphics Try opening it with different viewers to try and isolate the problem: - * Adobe Reader (package '''acroread''', available in the [[http://medibuntu.org/|Medibuntu]] repository) - * Xpdf (package '''xpdf-reader''') - * ePdfView - * okular - * for .ps files: ghostscript - * for .djvu files: djVuLibre (package '''djview4''') + * PDF + * Adobe Reader - package [[https://launchpad.net/ubuntu/+source/acroread|acroread]] in Precise only, or Adobe Reader via the latest [[https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa|WINE]]. + * Xpdf - package [[https://launchpad.net/ubuntu/+source/xpdf|xpdf]] + * Okular - package [[https://launchpad.net/ubuntu/+source/okular|okular]] + * ePdfView - package [[https://launchpad.net/ubuntu/+source/epdfview|epdfview]] in Precise only + * PostScript (.ps) + * ghostscript + * .djvu + * djVuLibre - package [[https://launchpad.net/ubuntu/+source/djview4|djview4]] When pdf files don't include the embedded fonts used in the document, then if Ubuntu doesn't have the specific font installed, it will search for the nearest equivalent, using '''fc-match '''. @@ -58, +54 @@ == Printing problems == - Sometimes, when a document printed from evince doesn't print correctly, it is not a problem with Evince, but with cups, or the specific printer driver. + It is best to file printing problems following [[https://wiki.ubuntu.com/DebuggingPrintingProblems]] first. If it turns out to be a bug in Evince, it may be reassigned. + = Triage responses = - = Other issues = + No document attached: {{{ + Thank you for taking the time to report this and helping to make Ubuntu better. Could you please attach an example document that demonstrates this issue? }}} - == How to Forward == + = Reporting bugs upstream = + Once the report has been marked Triaged, then one would want to next gather the required information necessary to forward to the appropriate upstream tracker. This includes the version Evince, poppler, and cairo via a terminal: {{{ + apt-cache policy evince libcairo2 libpoppler[0-9] }}} - * Upstream Evince bugs are at http://bugzilla.gnome.org/browse.cgi?product=evince + * Evince: [[http://bugzilla.gnome.org/browse.cgi?product=evince]] - * Upstream Poppler bugs are at http://bugs.freedesktop.org/query.cgi + * Poppler: [[http://bugs.freedesktop.org/query.cgi]] - == Backporting Fixes == + = Backporting Fixes = - Bug fixes are normally backported to all supported Ubuntu releases (you can see which releases are still supported [[http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Release_history|here]]). + Bug fixes are reviewed for backporting to all [[https://wiki.ubuntu.com/Releases|supported Ubuntu releases]] following [[https://wiki.ubuntu.com/StableReleaseUpdates]]. - However, this is not always possible, for example when the code architecture has changed significantly. This means that sometimes bugs are marked as "Fix Released" even when they have been fixed only in recent versions of evince/poppler/etc. ---- CategoryDebugging From noreply at ubuntu.com Thu Dec 18 13:00:47 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 18 Dec 2014 13:00:47 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingEvince=22_by_penalvch?= Message-ID: <20141218130047.9748.22674@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingEvince" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingEvince?action=diff&rev1=18&rev2=19 Comment: As per upstream suggestion noted in https://bugzilla.gnome.org/show_bug.cgi?id=741695 . Once the report has been marked Triaged, then one would want to next gather the required information necessary to forward to the appropriate upstream tracker. This includes the version Evince, poppler, and cairo via a terminal: {{{ apt-cache policy evince libcairo2 libpoppler[0-9] }}} + As well, if reporting an Evince crash, one may post the backtrace as a comment, and bugzilla will wrap it up into a button to expand out. * Evince: [[http://bugzilla.gnome.org/browse.cgi?product=evince]] * Poppler: [[http://bugs.freedesktop.org/query.cgi]] From webmaster at ubuntu.com Sun Dec 21 11:10:12 2014 From: webmaster at ubuntu.com (Help Ubuntu) Date: Sun, 21 Dec 2014 11:10:12 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141221111012.31019.99451@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=277&rev2=278 Comment: 1) RM'ed all double spaces before/after titles as it makes it harder to scroll through sections when editing. 2) Added common objections to BIOS updates w/ rationale. ||<>|| - = 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 == @@ -30, +27 @@ /!\ 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: @@ -39, +35 @@ * [[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 == @@ -84, +77 @@ /!\ 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 === @@ -103, +93 @@ 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. @@ -114, +103 @@ 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. @@ -125, +113 @@ ||{{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 == First, please review potential package candidates [[https://wiki.ubuntu.com/Bugs/FindRightPackage|here]]. Only after reviewing this, if are still 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 == @@ -184, +170 @@ 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:Alberto Salvia Novella ?subject=Please, triage this critical bug|warn about it]]. - = Tips and tricks = @@ -213, +197 @@ 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! @@ -225, +208 @@ 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 == @@ -243, +225 @@ 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: {{{ @@ -252, +233 @@ 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: @@ -260, +240 @@ 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 == @@ -284, +262 @@ 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]] - = Bug reporting etiquette = @@ -315, +292 @@ * '''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]]. + * '''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 issues. For example, 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 (this is by no means an exhaustive list). In addition, BIOS updates are for collateral damage avoidance. Here are some statement that don't justify keeping your BIOS outdated: {{{ + "It works in Windows, but doesn't in linux, so this isn't caused by my buggy and outdated BIOS." + }}} Buggy BIOS problems may manifest themselves in linux, but not in Windows, and vice versa. <
><
> {{{ + "It doesn't say anything in the release notes about linux/Ubuntu, so I don't need to upgrade my buggy and outdated BIOS" + }}} BIOS vendors typically test and have release note commentary about Windows only, so it wouldn't ever advise on if a problem in linux is resolved by it. <
><
> {{{ + "I didn't change anything in the BIOS, and this problem started happening after restarting from an update, so this is not due to my buggy and outdated BIOS." + }}} Updates to Ubuntu can cause buggy BIOS problems to manifest that the prior version did not. The solution is to update a buggy and outdated BIOS, not rely on unintentional WORKAROUNDs. <
><
> {{{ + "It's Ubuntu's job to provide me a way to update my buggy and outdated BIOS, so I'm not updating." + }}} The responsibility to keep the BIOS updated lies solely with owner of the hardware. However, as a courtesy to the Ubuntu Community, update methods that may not have been offered by your BIOS vendor are available [[https://help.ubuntu.com/community/BiosUpdate|here]]. <
><
> {{{ + "Updating my buggy and outdated BIOS is risky." + }}} Everything one does with any operating system, application, or hardware has some level of risk, from upgrading software (upgrade breaks functionality or security), to servicing hardware (static electricity, accidently bend/break the hardware, etc.). However, one simply eliminates or largely minimizes these risks with common sense techniques. In the case of a BIOS update, one ensures the power supply is not interrupted during the upgrade. As well, one may contact their computer vendor for further advice. <
><
> {{{ + "I don't feel like updating my buggy and outdated BIOS." + }}} This is not respecting the additional effort triagers and developers would have to put in to not only look at the code to see if it is correct (which is difficult enough), but to also think of all the ways a non-compliant BIOS could manifest problems given the code change. * '''One report, per person, per hardware combination, per bug'''. <
> Many [[https://launchpad.net/ubuntu/+source/linux|Linux]] package, hardware, and other non-user space bugs are hardware dependent on both the hardware itself, and what other hardware the problematic hardware is connected to. For more on this please see [[https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue|here]], and further below in this article. * '''Please do not post comments to another persons report, claiming you have the same or similar hardware or problem.''' <
> Instead, please file a separate report, and make comments there. This is because no one can verify if you would have the same problem or not, because your hardware can not be analyzed. Also, vendors can have different parts under the hood of the same model line. * ''' Please do not attempt to apport-collect to another persons report.''' <
> Running apport-collect when not specifically 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 immediate deletion at the discretion of developers and triagers. Instead, please open a new report via ubuntu-bug. Please note that attempting to run `apport-collect bug_number` against a [[https://launchpad.net/ubuntu/+source/linux|linux]] package bug report, while booted into a [[https://wiki.ubuntu.com/Kernel/MainlineBuilds|mainline]] linux kernel will not work. This is due to how Ubuntu does not provide support for mainline kernels. For more on this, please see [[https://wiki.ubuntu.com/Kernel/MainlineBuilds#Kernel.2BAC8-FAQ.2BAC8-DebuggingMainlineBuildsSupport.Does_the_kernel_team_support_the_mainline_kernel_builds.3F|here]]. @@ -341, +329 @@ * [[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 Wed Dec 24 17:23:35 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 24 Dec 2014 18:23:35 +0100 Subject: Didn't you know? Message-ID: <549AF697.2030703@gmail.com> Merry Christmas! -------------- 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 noreply at ubuntu.com Wed Dec 24 01:55:09 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 24 Dec 2014 01:55:09 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingProgramCrash=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20141224015509.23496.49596@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingProgramCrash" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingProgramCrash?action=diff&rev1=120&rev2=121 Comment: 1) Sectionized debug symbol installations. 2) Added distinctive support note on dbg/dbgsym overlap may cause issues. 3) Misc. presentation fixes. <> ||<>|| - This document describes how to debug Ubuntu package crashes and install debug packages on Ubuntu, which will aid in providing information for bugs. + = Introduction = + This document describes how to install debug packages on Ubuntu, allowing one to provide information regarding providing detailed information when manually performing: + 1. A [[Backtrace]]. + 1. A [[Valgrind]], if the program crashes with a "Segmentation fault" or "Bus error". + 1. An [[Strace]]. + - == Using apport-retrace == + = Using apport-retrace = If you want to debug a crash in packaged Ubuntu software, [[https://wiki.ubuntu.com/Apport|Apport]] will usually pick it up, create a `.crash` report in `/var/crash/` and report the crashed program. From there it is easiest to use [[http://manpages.ubuntu.com/apport-retrace|apport-retrace]]. @@ -31, +36 @@ If you do not want an interactive gdb session but just want it to update the already existing `.crash` file with fully symbolic stack traces, you can select the third option. + = Installing debug symbols manually = - == Debug Symbol Packages == - If you want to debug a crash in a project you are developing yourself or from a third-party package, or need the debug symbols for particular libraries very often, it is helpful to install those permanently into your system. - First, check if there is a package with a -dbg suffix in the main Ubuntu repositories. These are the debug symbol packages, and are equivalent to '-dbgsym' described below. You can safely use either one, but not both at once. Try installing the package, adding -dbg to its name, for example: - {{{ + If you want to debug a crash from an application provided by Ubuntu, you are developing yourself, provided by a third-party, or need the debug symbols for particular libraries very often, it is helpful to install the relevant debugging packages. + + == Built-in debug symbol packages (*-dbg) == + + For many, but not all, packages, one can simply add a -dbg suffix to the package name to install it. For example:{{{ sudo apt-get install xserver-xorg-core-dbg }}} - if the package in question is the ''xserver-xorg-core'' package. - If there is no -dbg package: + == Non-built-in debug symbol packages (*-dbgsym) == + For additional debug symbols that are not built-in, one must add an additional repository. /!\ Please take care to not install both debug symbols for a given package name, as this may cause problems. Your package manager will not check for this overlap and prevent it from happening. For example:{{{ + libprotobuf-c1-dbg + libprotobuf-c1-dbgsym + }}} Here are the steps to add this repository: - 1. Create an `/etc/apt/sources.list.d/ddebs.list` by running the following line at a terminal: {{{ + 1. Create an `/etc/apt/sources.list.d/ddebs.list` by running the following line at a terminal:{{{ - echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list }}} + echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list + }}} - 1. Stable releases (not alphas and betas) require two more lines adding to the same file, which is done by the following terminal command: {{{ + 1. Stable releases (not development, alphas, or betas) require two more lines adding to the same file, which is done by the following terminal command:{{{ echo "deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse - deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list }}} + deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list + }}} You may also add these lines using the Synaptic Package Manager: + * Choose ''Synaptic'' via the ''System > Administration'' menu. + * Choose ''Software Sources'' or ''Repositories'' via the ''Settings'' menu, and click on the ''Third-Party Software'' tab. + * Click the ''Add'' button and enter each ''deb ...'' line as above one by one and click the ''Add Source'' button (you will have to add these lines one at a time). + 1. Import the debug symbol archive signing key:{{{ + sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 + }}} + 1. Then run:{{{ + sudo apt-get update + }}} to update your package list or click the ''Reload'' button if you used the Synaptic Package Manager. + 1. The debug symbol packages have the '-dbgsym' suffix attached, so to install the debug symbols for the yelp package, you first run:{{{ + apt-cache policy yelp + }}} This will show you the version number currently installed (we'll use 2.22.1-0ubuntu2.8.04.1 in this example). '''NOTE:''' yelp (which is the package name of "Help and Support" located under the 'System' menu) is just an example, and would have to be replaced by the name of the package you want to debug. + 1. Install the debug symbols:{{{ + sudo apt-get install yelp-dbgsym=2.22.1-0ubuntu2.8.04.1 + }}} You can also use the Synaptic Package Manager to search for yelp-dbgsym and install it from there. + == Manually finding required debug symbols == - You may also add these lines using the Synaptic Package Manager: - * Choose ''Synaptic'' via the ''System > Administration'' menu. - * Choose ''Software Sources'' or ''Repositories'' via the ''Settings'' menu, and click on the ''Third-Party Software'' tab. - * Click the ''Add'' button and enter each ''deb ...'' line as above one by one and click the ''Add Source'' button (you will have to add these lines one at a time). - 1. Import the debug symbol archive signing key: {{{ - sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 }}} + The above procedure will install the debug symbol package for yelp only. For many packages, they use libraries shared between different packages. Hence, in order to obtain a readable/more readable stacktrace, or perform other debugging tasks, one must find the debug symbols for these shared libraries. For example, if one had attached gdb to an application and got the following output:{{{ + Reading symbols from /usr/lib/x86_64-linux-gnu/libffi.so.6...(no debugging symbols found)...done. + Loaded symbols for /usr/lib/x86_64-linux-gnu/libffi.so.6 + }}} This would indicate that the relevant debug symbols are not installed. However, this by itself wouldn't necessarily be enough information to know which package exactly needs the debug symbols. Hence, one may go to [[http://packages.ubuntu.com/]] and paste into the "Search the contents of packages" keyword box:{{{ + x86_64-linux-gnu/libffi.so.6 + }}} choose the appropriate Distribution from the drop down, and click Search. This would reveal that the package is libffi6. A check in Synaptic reveals the debug package libffi6-dbg. + == Automatically installing all debug symbols == - 1. Then run: {{{ - sudo apt-get update }}} - to update your package list or click the ''Reload'' button if you used the Synaptic Package Manager. - 1. The debug symbol packages have the '-dbgsym' suffix attached, so to install the debug symbols for the package 'yelp', you first run: {{{ - apt-cache policy yelp }}} - This will show you the version number currently installed (we'll use 2.22.1-0ubuntu2.8.04.1 in this example). - '''NOTE:''' 'yelp' [which is the package name of "Help and Support" located under the 'System' menu] is ''just an example'' and '''not''' a part of the command: 'yelp' is only used to demonstrate the procedure. You must replace 'yelp' with the name of the package you want to debug. + This procedure would install every debug symbols, versus only the ones you may need, or are interested in. You can download the following [[attachment:list-symbols-packages-v2.1.sh |shell script (list-symbols-packages-v2.1.sh)]] to resolve all the dependencies. Attaching a debugger to an already running process may require elevated privileges even if you own the process. The following invocation will print out the list of files to install. + {{{ + sudo bash ./list-symbols-packages-v2.sh -p $(pidof yelp) + }}} To automatically install them apt can be called with the input from the script. The script is invoked with {{{-t}}} for a terse output without the descriptions of the packages and error messages are suppressed:{{{ + sudo bash ./list-symbols-packages-v2.sh -t -p $(pidof yelp) 2>/dev/null | xargs -d $'\n' sudo apt-get install }}} /!\ Version 2 of this script makes it compatible with the newer GDB (which no longer loads all libraries at startup by default). -v2 currently only works if you run it against a currently-executing binary (i.e., with '-p $(pidof '). The [[attachment:list-symbols-packages.sh|older version]] of the script is also available. + = Uninstalling all debug symbols = - 1. Install the debug symbols: {{{ - sudo apt-get install yelp-dbgsym=2.22.1-0ubuntu2.8.04.1 }}} - You can also use the Synaptic Package Manager to search for 'yelp-dbgsym' and install it from there. - The above procedure will install the debug symbol package for yelp only. Chances are that yelp uses shared libraries in other packages and debug symbols for them might be required in order to obtain a readable stack trace or perform other debugging tasks. + You can remove all debug symbol packages and the ddebs repositories with the following commands:{{{ + sudo apt-get remove \.*-dbgsym \.*-dbg + sudo rm /etc/apt/sources.list.d/ddebs.list + sudo apt-get update + }}} + = The Xorg server = - You can download the following [[attachment:list-symbols-packages-v2.1.sh |shell script (list-symbols-packages-v2.1.sh)]] to resolve all the dependencies. Attaching a debugger to an already running process may require elevated privileges even if you own the process. The following invocation will print out the list of files to install. {{{ - sudo bash ./list-symbols-packages-v2.sh -p $(pidof yelp)}}} + Depending on the circumstances, X server will trap its own crashes and dump a stack trace in /var/log/Xorg.0.log. However, this stack trace is modified by the signal handler itself. If apport is not catching the crash, add this to your /etc/X11/xorg.conf:{{{ - To automatically install them apt can be called with the input from the script. The script is invoked with {{{-t}}} for a terse output without the descriptions of the packages and error messages are suppressed {{{ - sudo bash ./list-symbols-packages-v2.sh -t -p $(pidof yelp) 2>/dev/null | xargs -d $'\n' sudo apt-get install }}} - - /!\ Version 2 of this script makes it compatible with the newer GDB (which no longer loads all libraries at startup by default). -v2 currently only works if you run it against a currently-executing binary (i.e., with '-p $(pidof '). The [[attachment:list-symbols-packages.sh|older version]] of the script is also available. - - a. Now you make a [[Backtrace]]. - a. You can also run [[Valgrind]], if the program crashes with a "Segmentation fault" or "Bus error". - a. Optionally, you may be asked to produce an [[Strace]]. - a. You can also provide this file : '''~/.xsession-errors''' - - === How do we remove all this stuff after getting the trace and get back to a normal system? === - - You can remove all debug symbol packages and the ddebs repositories with the following commands: {{{ - sudo apt-get remove \.*-dbgsym - sudo rm /etc/apt/sources.list.d/ddebs.list - sudo apt-get update }}} - - === References === - - * Announcement: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-September/000195.html - - == The Xorg server == - - The X server will by default trap its own crashes and dump a stack trace in /var/log/Xorg.0.log. However, this stack trace is modified by the signal handler itself. To get a "normal" crash, which will trigger a core dump (and ''apport'' reporting), add this to your /etc/X11/xorg.conf: {{{ Section "ServerFlags" Option "NoTrapSignals" "true" - EndSection }}} + EndSection - Please see [[X/Debugging]] for how to debug Xorg server crashes. + }}} Please see [[X/Debugging]] for how to debug Xorg server crashes. - == Info for the BugSquad == + = Info for the BugSquad = + If you're trying to apport-retrace a crash report from a bug that didn't happen on the same Ubuntu release as the one you're running, it would be easiest to just virtualize the environment it is reproducible in. However, if this would not be available to you, one may perform the following example. Say that you're running Trusty and the crash happened on Precise: - If you're trying to `apport-retrace` a crash report from a bug that didn't happen on the same Ubuntu release as the one you're running, do the following: - - Say that you're running `Gutsy` and the crash happened on `Feisty`: - - 0. This will create a minimal `feisty` system. {{{ + 0. This will create a minimal Precise system:{{{ - sudo mkdir -p /chroots/feisty + sudo mkdir -p /chroots/precise - sudo debootstrap feisty /chroots/feisty/}}} + sudo debootstrap precise /chroots/precise/ + }}} - 0. Now you change into this minimal `feisty` system. {{{ + 0. Now change into this minimal precise system:{{{ - sudo chroot /chroots/feisty}}} + sudo chroot /chroots/precise + }}} - 0. edit `/etc/apt/sources/list` and all the repositories you need, especially Martin's ddeb repository. + 0. Edit /etc/apt/sources/list and add all the repositories you need, including the ddeb repository. - 0. {{{ + 0. Execute the following in a terminal:{{{ - apt-get update; apt-get install gdb apport}}} + sudo apt-get update; sudo apt-get install gdb apport + }}} - 0. use `apport-retrace` as you're used to. + 0. use apport-retrace as you're used to. For more information on dealing with bug reports [[Apport]] see [[Bugs/ApportRetraces]]. From noreply at ubuntu.com Wed Dec 24 05:27:43 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 24 Dec 2014 05:27:43 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingEvince=22_by_penalvch?= Message-ID: <20141224052743.18789.38812@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingEvince" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingEvince?action=diff&rev1=20&rev2=21 Comment: As per https://bugzilla.gnome.org/show_bug.cgi?id=741695 updated with high majority of applicable debugging symbols. In all reports, please ensure you attach an uncompressed/untarred document that the issue is reproducible with. - == Crash or Freeze == + == Crash == - If Evince crashes, please report this following [[https://wiki.ubuntu.com/ReportingBugs]]. + If Evince crashes in the latest development release of Ubuntu, please gather a backtrace with all debugging symbols installed, as upstream may not reproduce the issue:{{{ + sudo apt-get install libxml2-dbg libcroco3-dbgsym librsvg2-dbg libogg-dbg libvorbis0a-dbgsym libltdl7-dbgsym libtdb1-dbg libvorbis-dbg libcanberra0-dbg libcanberra-gtk3-0-dbg libcanberra-gtk3-module-dbg gtk3-engines-unico-dbgsym dconf-gsettings-backend-dbgsym gvfs-libs-dbgsym gvfs-dbg libunity-gtk3-parser0-dbgsym unity-gtk3-module-dbgsym overlay-scrollbar-gtk3-dbgsym libgraphite2-3-dbg libframe6-dbgsym libgrail6-dbgsym libxdmcp6-dbg libxau6-dbg libdatrie1-dbgsym libgcc1-dbg libexpat1-dbgsym libgpg-error0-dbgsym libgeis1-dbgsym libffi6-dbg libselinux1-dbgsym libxcb1-dbg libpng12-0-dbgsym libfreetype6-dbgsym libxext6-dbg libmirclient8-dbgsym libxkbcommon0-dbgsym libwayland-client0-dbg libwayland-cursor0-dbg libwayland-server0-dbg libxdamage1-dbg libxcomposite1-dbg libxcursor1-dbg libxrandr2-dbg libxinerama1-dbg libfontconfig1-dbg libatk-bridge2.0-0-dbg lixfixes3-dbg libxi6-dbg libx11-6-dbg libgcrypt11-dbg zlib1g-dbg libglib2.0-0-dbg libgdk-pixbuf2.0-0-dbg libcairo2-dbg libatk1.0-dbg libpango1.0-0-dbg libgtk-3-0-dbg libgnome-desktop-3-10-dbgsym libsecret-1-0-dbgsym libgcrypt20-dbg libxcb-shm0-dbg libxcb-render0-dbg libpcre3-dbg libatspi2.0-0-dbg libharfbuzz0b-dbgsym libmircommon3-dbgsym libmirprotobuf0-dbgsym libboost1.55-dbg libstdc++6-4.9-dbg liblcms2-dbg libtiff5-dbgsym libjpeg-turbo8-dbg libjbig0-dbgsym libxrender1-dbg libprotobuf9-dbgsym poppler-dbg liblzma5-dbgsym + }}} == Rendering issues == From saqman2060 at gmail.com Wed Dec 24 21:04:54 2014 From: saqman2060 at gmail.com (Istimsak Abdulbasir) Date: Wed, 24 Dec 2014 16:04:54 -0500 Subject: Didn't you know? In-Reply-To: <549AF697.2030703@gmail.com> References: <549AF697.2030703@gmail.com> Message-ID: Merry Christmas On Wed, Dec 24, 2014 at 12:23 PM, Alberto Salvia Novella < es20490446e at gmail.com> wrote: > Merry Christmas! > > > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > > -- "Collaboration is the new innovation" (Istimsak Abdulbasir, 2013) -------------- next part -------------- An HTML attachment was scrubbed... URL: From harish.b310 at gmail.com Thu Dec 25 04:21:38 2014 From: harish.b310 at gmail.com (Harish Babu) Date: Wed, 25 Dec 2014 04:21:38 +0000 Subject: =?ISO-8859-1?Q?Re=3Aexecdirgen_v?= Message-ID: http://travestigokce.com/ziothebj/eoiykaecrgxrnjmdauymczapsiknltzuezyqwq.jgcmenroqupxecivmumolgprsshixuecbfpxovby Harish Babu -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Fri Dec 26 02:20:13 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 26 Dec 2014 02:20:13 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Bug_statuses=22_by_penalvch?= Message-ID: <20141226022013.13916.84842@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Bug statuses" page has been changed by penalvch: http://wiki.ubuntu.com/Bugs/Bug%20statuses?action=diff&rev1=72&rev2=73 Comment: 1) RM'd 2x linefeed prior to Headings as it doesn't make space in presentation. 2) Not all valid reports are bugs (i.e. certain issues that are Wishlist, Opinion, etc.). 3) Misc. presentation fixes. ## page was renamed from BugSquad/ManagingStatus <> + A report's status is a reflection of the current development state of what is being reported. - Bug statuses are a reflection of the current state of a bug report. + The status of a report can be modified by clicking on the current status in the yellow line, towards the top of the page. This will reveal a sub menu of statuses to choose from. You can then set a new status via the drop down box. - The status of a bug report can be modified by clicking on the current status in the yellow line, which will reveal a sub menu. You can then set a new status in the drop down box. - - Below is a list of bug statuses, their meaning and when to use them: + Below is a list of report statuses, their meaning, and when to use them: * '''New''': - * Bugs are submitted with this status, + * Reports are submitted with this status. - * They sometimes lack information '''and''' + * They sometimes lack information. - * All of them should be untriaged + * All of them should be untriaged. * '''Incomplete''': - * If you have to ask the reporter questions, set the bug to {{{Incomplete}}} + * If you have to ask the reporter questions, set the report to Incomplete. - * Ask the submitter to provide any necessary information in a comment, and make sure you subscribe yourself to the bug report so you will get any updates to the bug via e-mail. + * When you ask the reporter to provide any necessary information in a comment, and make sure you subscribe yourself to the report so you will get any updates to the report via e-mail. - * <> - * If anyone, including you, comments on the bug, the 60 day expiration clock is reset. + * If anyone, including you, makes a comments, the 60 day expiration clock is reset. + * For more on this, please see [[https://wiki.ubuntu.com/Bugs/Responses]]. * '''Opinion''': - * The status 'opinion' means there is a difference of opinion around a particular bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed. The idea is that bugs can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going. + * This means there is a difference of opinion around a the report and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed. The idea is that reports can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going. - * This status 'opinion' is considered an experiment, and will be closely monitored. + * This status is considered an experiment, and will be closely monitored. * '''Invalid''': - * This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter + * This status should be used when the report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter. - * This should also be used if the reported problem is not a bug at all, but for example user error + * This should also be used if the reported problem is not a bug at all. For example, user's lack of knowledge on how something works, hardware failure, or fixed after updating a buggy, and outdated BIOS. - * It should be used conservatively as bugs marked as Invalid no longer show up in default searches + * It should be used conservatively as reports marked as Invalid no longer show up in default searches. - * Be sure to triple-check a bug before you invalidate it + * Be sure to triple-check a report before you invalidate it. * '''Expired''' - * This status is similar to Invalid, but is meant specifically for bugs that have been Incomplete for too long. (See above.) + * This status is similar to Invalid, but is meant specifically for reports that have been Incomplete for too long (see above). * This status is only able to be set by using launchpadlib or the email interface. - * Like Invalid bugs, Expired bugs do not show up in default searches. + * Like Invalid reports, Expired reports do not show up in default searches. * '''Confirmed''': - * Another reporter has experienced the same bug, this can come in the form of a duplicate bug or a bug comment + * Another reporter has experienced the same issue. This can come in the form of a duplicate report or a comment. - * {{{Confirmed}}} bugs require confirmation from '''someone other than the original reporter''' + * {{{Confirmed}}} reports require confirmation from '''someone other than the original reporter'''. - * This helps ensure that the bug is applicable to Ubuntu in general, and not a problem with the reporter's system, therefore... - * Please don't confirm your own bugs! + * This helps ensure that the report is applicable to Ubuntu in general, and not hardware failure, lack of knowledge, etc. + * In general, please don't confirm your own bugs, unless there is a documented exception by the development group of the package (ex. linux). * '''Triaged''': - * A member of [[UbuntuBugControl]] believes that the report describes a genuine bug in enough detail that a developer could start working on a fix. ''(also see tip below)'' + * A member of [[UbuntuBugControl]] believes that the report describes a genuine issue in enough detail that a developer could start working on a fix. - * Use this when you are confident that it should be looked at by a developer '''and''' has enough information + * Use this when you are confident that it should be looked at by a developer '''and''' has enough information for the developer to fix it. - * While not a requirement a bug's Ubuntu task status will be Triaged before any upstream forwarding occurs + * While not a requirement, a report's Ubuntu task status should be Triaged before any upstream forwarding occurs. - * With bugs about '''linux''' Triaged means that the bug has been tested with the upstream mainline kernel + * With reports about '''linux''': Triaged means that the original reporter has tested with the latest upstream mainline kernel they can technically test to. - * For process bugs (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) triaged means the action has been approved by the relevant developers. + * For process reports (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) Triaged means the action has been approved by the relevant developers. * '''In Progress''': - * You have assigned the bug '''to yourself''', and you're going to fix it '''right now''' by submitting a [[https://wiki.ubuntu.com/Bugs/Patches|patch]]. + * You have assigned the report '''to yourself''', and you're going to address it '''right now''' by submitting a [[https://wiki.ubuntu.com/Bugs/Patches|patch]]. - * This status is not for if one is simply debugging a bug (ex. bisecting, testing out a patch provided by someone else, you have a work around, etc.). + * This status is not for if one is simply debugging (ex. bisecting, testing out a patch provided by someone else, you have a work around, etc.). - * /!\ '''Never''' assign bugs to others. + * /!\ '''Never''' assign a report to others. - * /!\ If there has been an assignee for more than six months without a fix or response, one could unassign him and revert the status. + * /!\ If there has been an assignee for more than six months without a fix or response, one could unassign them and revert the status. * '''Fix Committed''': - * Ubuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla) + * Ubuntu task: the changes are pending, and to be uploaded soon. - * {{{Fix Committed}}} is also used when an updated package exists in a -proposed repository i.e. hardy-proposed + * {{{Fix Committed}}} is also used when an updated package exists in a -proposed repository (i.e. trusty-proposed). - * {{{Fix Committed}}} is '''not''' to be used when a patch is attached to a bug + * {{{Fix Committed}}} is '''not''' to be used when a patch is attached to a report. - * Upstream bug task: the fix is in CVS/SVN/bzr or committed to some place + * Upstream task: the fix is in bzr/CVS/git/SVN, or committed to some place. * '''Fix Released''': - * Ubuntu bug task: a fix was uploaded to an official Ubuntu repository + * Ubuntu task: a fix was uploaded to an official Ubuntu repository. - * N.B. This '''does not''' include -proposed i.e. hardy-proposed + * N.B. This '''does not''' include -proposed (i.e. trusty-proposed). - * Please don't hesitate to add a changelog as a comment, so people know in which package version a bug was fixed + * Please don't hesitate to add a changelog as a comment, so people know in which package version the fix was released in. - * If a bug is fixed in the current development release, it is {{{Fix Released}}}. If the bug also [[StableReleaseUpdates | needs to be fixed]] in a stable release, use the "Target to release" link to nominate it for that release. + * If the current development release has the fix applied, it is {{{Fix Released}}}. If a [[StableReleaseUpdates|stable release needs to be fixed]] also, use the "Target to release" link to nominate it for that release. - * Upstream bug task: a release tarball was announced and is publicly available + * Upstream task: a release tarball was announced and is publicly available. * '''Won't Fix''': - * This status is sometimes used when the bug fix is too controversial + * This status is sometimes used when the fix is too controversial. - * It is most often used for bugs with a release target that will not be fixed in that particular release but may be fixed later + * It is most often used for a report with a release target that will not be fixed in that particular release but may be fixed later. - * It may also be used for feature requests that the developers do not want to implement + * It may also be used for feature requests that the developers do not want to implement. /!\ the following status changes are restricted to members of [[UbuntuBugControl]] or package maintainers: - * moving to Triaged, or WONTFIX + * Moving to Triaged, or Won't Fix. - * moving ''from'' WONTFIX + * Moving ''from'' Won't Fix. - * targeting to a specific Ubuntu release + * Targeting to a specific Ubuntu release. - === Frequently Asked Questions === - ''If you have a question, please feel free to ask it by emailing the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad|BugSquad mailing list]] with your question.'' + ''If you have a question, please feel free to ask it by emailing the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad|BugSquad mailing list]] with your question.'' - * What is the appropriate status if the bug's reporter later says the bug no longer exists but the related changelog does not note a fix? + * What is the appropriate status if the original reporter later says the issue no longer exists but the related changelog does not note a fix? - * See the first point under "Invalid", the bug does not have sufficient information. + * See the first point under "Invalid", the report does not have sufficient information. - * What should a triager do if there is consensus ''among users and developers'' that an issue is valid but there is no good solution? + * What should a triager do if there is consensus ''among users and developers'' that an issue is valid but there is no good solution? - * Keep the bug open with a status of "Wishlist" or "Triaged", depending on the severity. + * Keep the report open with a status of "Triaged", and/or mark it with [[Importance]] "Wishlist", depending on the severity. - * Should the bug reporter reset the bug status to "New" if providing more information to an "Incomplete" bug? + * Should the original reporter reset the report status to "New" if providing more information to an "Incomplete" report? - * Yes. + * Yes. - * When converting a question to a bug, can the bug status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the bug? + * When converting a question to a report, can the status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the issue? - * Make a judgment call: as long as ''more than one person'' experiences the bug, the proper status is "Confirmed". + * Make a judgment call: as long as ''more than one person'' can reproduce it, the proper status is "Confirmed". - * What should a triager do if a bug needs more information, including steps to reproduce, but the original reporter is not available to provide it? + * What should a triager do if a report needs more information, including steps to reproduce, but the original reporter is not available to provide it? - * Mark the bug as Invalid with a comment that the reporter should provide the information and reopen the bug by resetting its status to 'New'. + * Mark the report as Invalid, with a comment that the reporter should provide the information, and reopen the report by resetting its status to 'New'. - * What is the appropiate bug status for issues caused by faulty hardware? - * The appropriate bug status for such issues is "Invalid". - - ||{{attachment:IconHelp2.png}}Not yet an [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member? If you notice a bug having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the bug to ''Triaged'' for you. Paste the bug number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the bug should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to [[Bugs/Importance]]. Someone will notice your comment and set it for you, although not necessarily immediately.|| + ||{{attachment:IconHelp2.png}}Not yet a [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member? If you notice a report having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the report to ''Triaged'' for you. Paste the report number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the report should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to [[Bugs/Importance]]. Someone will notice your comment and set it for you, although not necessarily immediately.|| - ---- CategoryBugSquad From noreply at ubuntu.com Mon Dec 29 01:44:58 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Mon, 29 Dec 2014 01:44:58 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingEvince=22_by_penalvch?= Message-ID: <20141229014458.3963.12889@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingEvince" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingEvince?action=diff&rev1=21&rev2=22 Comment: Added additional PDF, ps, and djvu alternate testing methods. Try opening it with different viewers to try and isolate the problem: * PDF - * Adobe Reader - package [[https://launchpad.net/ubuntu/+source/acroread|acroread]] in Precise only, or Adobe Reader via the latest [[https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa|WINE]]. + * Firefox's built-in PDF Viewer - package [[https://launchpad.net/ubuntu/+source/firefox|firefox]] + * Okular - package [[https://launchpad.net/ubuntu/+source/okular|okular]] * Xpdf - package [[https://launchpad.net/ubuntu/+source/xpdf|xpdf]] + * Adobe Reader + * All releases - Install the Windows version of Adobe Reader via the latest [[https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa|WINE]]. - * Okular - package [[https://launchpad.net/ubuntu/+source/okular|okular]] + * In Precise only - package [[https://launchpad.net/ubuntu/+source/acroread|acroread]] * ePdfView - package [[https://launchpad.net/ubuntu/+source/epdfview|epdfview]] in Precise only + * Chromium's built-in PDF Viewer - package [[https://launchpad.net/ubuntu/+source/chromium-browser|chromium-browser]] * PostScript (.ps) - * ghostscript + * gv - package [[https://launchpad.net/ubuntu/+source/ghostscript|ghostscript]] * .djvu - * djVuLibre - package [[https://launchpad.net/ubuntu/+source/djview4|djview4]] + * djview4 - package [[https://launchpad.net/ubuntu/+source/djview4|djview4]] + * xdvi - packge [[https://launchpad.net/ubuntu/+source/texlive-bin|texlive-binaries]] When pdf files don't include the embedded fonts used in the document, then if Ubuntu doesn't have the specific font installed, it will search for the nearest equivalent, using '''fc-match '''. From es20490446e at gmail.com Mon Dec 29 02:50:52 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 29 Dec 2014 03:50:52 +0100 Subject: Please, consider reflecting on the Canonical Contributor Agreement Message-ID: <54A0C18C.2060506@gmail.com> Hi, this is Alberto; who is currently coordinating Ubuntu papercuts quality. I wanted to bring up a topic which I have been thinking about five months from now, and after speaking with the appropriate people and deliberating about it; I conclude it really needs to change. Canonical Contributor Agreement (http://tinyurl.com/q2lwggl): > We may license the Contribution under any license, including > copyleft, permissive, commercial, or proprietary licenses. Probably this has been done for keeping code copy-left while being able to charge telephony manufacturers for using libre software, instead of just giving it freely to leechers under a non copy-left license. But there's a problem with that, which is it overrides the social contract with people to code to belong to the world not to a group of individuals; making the system abusive by design. It's like telling that an autocracy is better because its drivers have extra flexibility to do whatever will be needed in future, which is also a proven method for sinking projects and communities. So please address the root causes that let to this issue, so we have a healthy environment for everyone. Thanks for your understanding. -------------- 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 stephen.webb at canonical.com Mon Dec 29 04:58:09 2014 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Sun, 28 Dec 2014 23:58:09 -0500 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A0C18C.2060506@gmail.com> References: <54A0C18C.2060506@gmail.com> Message-ID: <54A0DF61.2020502@canonical.com> On 12/28/2014 09:50 PM, Alberto Salvia Novella wrote: > > But there's a problem with that, which is it overrides the social contract with people to code to belong to the world > not to a group of individuals; making the system abusive by design. > > It's like telling that an autocracy is better because its drivers have extra flexibility to do whatever will be needed > in future, which is also a proven method for sinking projects and communities. > > So please address the root causes that let to this issue, so we have a healthy environment for everyone. I think you will find that there is no conflict between any vaguely defined "social contract" and the requirements for acceptable code submission to a software project. If you could enumerate the abuses engendered by asking for a grant of license I'd be happy to address them individually. In order to accept code contribution to a Canonical-led software project a small number of conditions need to be satisfied. Among these conditiona are a strict minimum level of demonstrable code quality (we do no want buggy code), applicability (we do not want irrelevant code), and the same rights as the author (an explicit rights grant, also known as the CLA). You will find upon a close reading of the various source code distribution licenses that they do not harbour any requirements that arbitrary code contributions must be accepted upstream. In fact, you will not find any examples of Free or open source software projects anywhere that unconditionally accept arbitrary code contributions. It's just not a thing. If you truly believe that the original works of an author or authors belong not to them individually but to some larger collective, you would probably be more effective talking to legislators to get the copyright and patent laws in your local jurisdiction struck down, and best of luck with that. Mean time we will continue asking the authors of contributions to agree to share the specific rights in their work if they want it accepted into a Canonical-led project. That's the best way to guarantee fairness for everyone. -- Stephen M. Webb From stephen.webb at canonical.com Mon Dec 29 18:09:57 2014 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Mon, 29 Dec 2014 13:09:57 -0500 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A16B2E.8070102@gmail.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> Message-ID: <54A198F5.8080305@canonical.com> I have removed most of the CC: on this discussion because I don't believe such spam is appropriate (and it fills my mailbox with list rejections). On 12/29/2014 09:54 AM, Alberto Salvia Novella wrote: > Stephen M. Webb: >> I think you will find that there is no conflict between any vaguely >> defined "social contract" and the requirements for acceptable code >> submission to a software project. > > That social contract is . The GPL is not a social contract, it is a legal agreement defining the terms of use and distribution of a work of software. It deals exclusively with downstream distribution of software and expressly does not mention how upstream projects are to be run. If you wish to reference a social contract from the Free Software Foundation, you would be better off using the GNU Manifesto [1] which explicitly enumerates a set of rights and entitlements the Free Software Foundation believes are a part of the social contract between individuals. Please read it closely: I believe you will not find among those enumerated rights any kind of entitlement that your changes must be accepted upstream. If you can find such a right enumerated, please let me know; I have some tasteless "easter eggs" I want to add to some widely-used programs distributed by the FSF. As I said previously, all upstream project have a set of conditions, express or implied, they require any contribution to fulfil before acceptance. Your arguments that having any such set of restrictions contravenes "the social contract" or is invalid under the GNU General Public License still remains to be made. > Stephen M. Webb: >> If you truly believe that the original works of an author or authors >> belong not to them individually but to some larger collective, you >> would probably be more effective talking to legislators to get the >> copyright and patent laws in your local jurisdiction struck down, and >> best of luck with that. Mean time we will continue asking the >> authors of contributions to agree to share the specific rights in >> their work if they want it accepted into a Canonical-led project. >> That's the best way to guarantee fairness for everyone. > > Putting the agreement under the United Kingdom law wasn't my objection, but to take nearly unlimited power over the code. Yes, the rhetorical techniques of vagueness ("power over the code") and pathos [2] ("unlimited power!!!1!") can be powerful tools, but as an engineer I prefer facts. Here are some of the facts involved when I decide to accept or reject a contribution in any of the several Canonical-led projects for which I am responsible. In almost all jurisdictions copyright law grants the original author of a work a set of rights over the use of that work, including the right to license or restrict the use of that work, either for free or for a fee, to another legal person (which could be an individual or a business entity). Other users of the copyright work do not have such rights, even if they have been granted permission by the author to use the work. Because the power over use of copyrighted works is balanced in favour of the original author (as it should be), it puts any business that makes use of the copyrighted work at the mercy of that author. For example, an organization that provides a software program used to operate a general-purpose computer might accept a small contribution to improve the performance of the program on a particular device. The contribution is then included in the software program and distributed widely. Subsequently, the author of the contribution revokes or changes the license terms, forcing the organization to remove the contribution at its expense and disrupting its business, possibly even terminating it. This is certainly not the intended consequence of copyright or patent law, but certainly a very real possibility, and one which has been used in practice on several high-profile occasions. The effective alternatives to preventing this very real threat to a business attempting to use Free or open source software are: (1) accept absolutely no outside contributions ever or (2) require a non-revokable symmetric grant of copyright powers from the original author of outside contributions (such as the CLA). A third alternative is that the business investigate the individual contributor with background checks and judge them individually as worthy contributors, but nobody wants that and ain't nobody got time for that. Remember, at no time does the CLA remove or restrict any enumerated rights of the original author nor does it accrue more rights to the licensee than the original author already has. The CLA simply grants similar rights as the original author to the licensee. It does restrict the malicious use of the original author's enumerated rights with respect to the licensee, and that's the point. I can see how some selfish people would object to that restriction, but I am not convinced by that as a logical argument to remove the CLA as a requirement for the acceptance of an upstream software contribution. Fact is, when it comes time for me to accept or reject a contribution, I must outright reject any from an author who has not proven good will, and that proof is the CLA. > Stephen M. Webb: >> If you could enumerate the abuses engendered by asking for a grant of >> license I'd be happy to address them individually. > > As I said, this is like telling a autocracy is good because their drivers have never done something bad. > > It's something that elicits distrust itself, and usually finishes with people working less and less for the project; > even when they are paid for it. So, you can not enumerate the abuses engendered by asking for a grant of license. That's OK, you simply make my point for me, thank you. I can certainly point you at cases [3] showing how "intellectual property" laws are twisted and maliciously abused. It's true that there is a strong element of distrust involved, but trust has to work both ways. The CLA codifies that trust explicitly. Puts it in writing, all nice and legal-like. If a potential contributor objects to that, I can only assume they have malicious intent and I do not want their contribution in my project(s). [1] https://www.gnu.org/gnu/manifesto.html#content [2] http://en.wikipedia.org/wiki/Pathos [3] http://www.groklaw.net/ -- Stephen M. Webb From ubuntu at treblig.org Mon Dec 29 12:31:12 2014 From: ubuntu at treblig.org (Dr. David Alan Gilbert) Date: Mon, 29 Dec 2014 12:31:12 +0000 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A0DF61.2020502@canonical.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> Message-ID: <20141229123112.GA19648@gallifrey> * Stephen M. Webb (stephen.webb at canonical.com) wrote: > On 12/28/2014 09:50 PM, Alberto Salvia Novella wrote: > > > > But there's a problem with that, which is it overrides the social contract with people to code to belong to the world > > not to a group of individuals; making the system abusive by design. > > > > It's like telling that an autocracy is better because its drivers have extra flexibility to do whatever will be needed > > in future, which is also a proven method for sinking projects and communities. > > > > So please address the root causes that let to this issue, so we have a healthy environment for everyone. > > I think you will find that there is no conflict between any vaguely defined "social contract" and the requirements for > acceptable code submission to a software project. If you could enumerate the abuses engendered by asking for a grant of > license I'd be happy to address them individually. > > In order to accept code contribution to a Canonical-led software project a small number of conditions need to be > satisfied. Among these conditiona are a strict minimum level of demonstrable code quality (we do no want buggy code), > applicability (we do not want irrelevant code), and the same rights as the author (an explicit rights grant, also known > as the CLA). That's very misleading. I don't think any reading of Alberto's mail is objecting to code review. > You will find upon a close reading of the various source code distribution licenses that they do not harbour any > requirements that arbitrary code contributions must be accepted upstream. In fact, you will not find any examples of > Free or open source software projects anywhere that unconditionally accept arbitrary code contributions. It's just not > a thing. CLAs are indeed common practice; however ones that allow relicensing of contributions under arbitrary commercial licenses are much rarer and those are objectionable, and I think you realise that's what Alberto was objecting to. > If you truly believe that the original works of an author or authors belong not to them individually but to some larger > collective, you would probably be more effective talking to legislators to get the copyright and patent laws in your > local jurisdiction struck down, and best of luck with that. Mean time we will continue asking the authors of > contributions to agree to share the specific rights in their work if they want it accepted into a Canonical-led project. > That's the best way to guarantee fairness for everyone. Of course we're all free to fork the canonical code to a project that doesn't have the same CLA, so it's not a vast issue; but as is I can not contribute to a subproject that requires contributions under the current CLA. Dave > > -- > Stephen M. Webb > > _______________________________________________ > Mailing list: https://launchpad.net/~ubuntu-bugcontrol > Post to : ubuntu-bugcontrol at lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol > More help : https://help.launchpad.net/ListHelp -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ From es20490446e at gmail.com Mon Dec 29 14:54:38 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 29 Dec 2014 15:54:38 +0100 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <20141229123112.GA19648@gallifrey> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> Message-ID: <54A16B2E.8070102@gmail.com> Stephen M. Webb: > I think you will find that there is no conflict between any vaguely > defined "social contract" and the requirements for acceptable code > submission to a software project. That social contract is . David Alan Gilbert: > I don't think any reading of Alberto's mail is objecting to code review. Exactly. Stephen M. Webb: > If you truly believe that the original works of an author or authors > belong not to them individually but to some larger collective, you > would probably be more effective talking to legislators to get the > copyright and patent laws in your local jurisdiction struck down, and > best of luck with that. Mean time we will continue asking the > authors of contributions to agree to share the specific rights in > their work if they want it accepted into a Canonical-led project. > That's the best way to guarantee fairness for everyone. Putting the agreement under the United Kingdom law wasn't my objection, but to take nearly unlimited power over the code. Stephen M. Webb: > If you could enumerate the abuses engendered by asking for a grant of > license I'd be happy to address them individually. As I said, this is like telling a autocracy is good because their drivers have never done something bad. It's something that elicits distrust itself, and usually finishes with people working less and less for the project; even when they are paid for it. -------------- 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 phillip.szelat at gmail.com Tue Dec 30 01:15:40 2014 From: phillip.szelat at gmail.com (phillip) Date: Tue, 30 Dec 2014 02:15:40 +0100 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A198F5.8080305@canonical.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> <54A198F5.8080305@canonical.com> Message-ID: <4642B8CF-974C-49D5-8A27-45E8B611C401@gmail.com> Hi, What I don't understand is: "2.3 Outbound License Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses." There is absolutely no reason to license it as proprietary software in the future? Why not just use something like: "We may license the Contribution under any free and opensoure license" ? Phillip From es20490446e at gmail.com Tue Dec 30 02:08:01 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Tue, 30 Dec 2014 03:08:01 +0100 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A198F5.8080305@canonical.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> <54A198F5.8080305@canonical.com> Message-ID: <54A20901.7040202@gmail.com> Stephen M. Webb: > That social contract is . Stephen M. Webb: > The GPL is not a social contract, it is a legal agreement defining > the terms of use and distribution of a work of software. I thought it would be well understood written that way, but I can be more explicit if needed: The social contract, the purpose of any copy-left license, is the work to always remain libre; so anyone can enjoy it the way they wish. While the license is the legal mean for that goal. When you give the option to re-license the work under a non copy-left license, the original purpose is gone. The company has privileges on the code over the rest of people, which concludes in a rigid development ecosystem where a few really own the software and the rest are the manpower. Stephen M. Webb: > Yes, the rhetorical techniques of vagueness ("power over the code") > and pathos [2] ("unlimited power!!!1!") can be powerful tools, but as > an engineer I prefer facts. As lean system engineer, prize in physics, computer engineering student, and member of the club of the human resources of my university with about 6000 hours of training in leadership, coaching and emotional intelligence (and some more delusional stuff that never mattered); this is what I have to say: The fact is companies where workers are the ones who takes decisions are by far much successful than those where decisions are made by a few. And this is because nobody has a brain as big as it will require to control everything, and nobody has as expertise as accurate as all the people in the front lines put together. Moreover, it's emotionally exhausting to handle such an amount of responsibility put on one person. Managers tend to feel attached, and finish paying attention to nobody; while answering pervasively to everything. As specimen, the company that you pursue to imitate: Stephen M. Webb: > Because the power over use of copyrighted works is balanced in favour > of the original author (as it should be), it puts any business that > makes use of the copyrighted work at the mercy of that author. For > example, an organization that provides a software program used to > operate a general-purpose computer might accept a small contribution > to improve the performance of the program on a particular device. The > contribution is then included in the software program and distributed > widely. Subsequently, the author of the contribution revokes or > changes the license terms, forcing the organization to remove the > contribution at its expense and disrupting its business, possibly > even terminating it. This is certainly not the intended consequence > of copyright or patent law, but certainly a very real possibility, > and one which has been used in practice on several high-profile > occasions. As far as I know, it's not possible to revoke any license grant you have given in the past; so the license itself protects against abuse from the original author. And even if this wasn't the case, it won't be necessary the contribution agreement to give the power to publish under any license; but only to the same one and subsequent. Stephen M. Webb: > So, you can not enumerate the abuses engendered by asking for a grant > of license. That's OK, you simply make my point for me, thank you. Instead of repeating myself, I'm going to ask you a question: What do you think my purpose is? -------------- 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 Tue Dec 30 20:15:48 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Tue, 30 Dec 2014 21:15:48 +0100 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A2D534.8090308@canonical.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> <54A198F5.8080305@canonical.com> <54A20901.7040202@gmail.com> <54A2D534.8090308@canonical.com> Message-ID: <54A307F4.7050704@gmail.com> Stephen M. Webb: > Aren't you violating the GPL by requiring a copyright license for > contributions to your projects? As I said, this is not about the license itself; but about who owns the software and what kind of organization it encourages. Stephen M. Webb: > If you're going to contribute code under the GPL, you can't apply > addition restrictions on how it's used without violating the GPL. Exactly: the purpose of this conversation is nobody to be able to restrict the code that is published. Stephen M. Webb: > In fact under most jurisdictions the default is that a project is > unable to use your contributions at all under copyright without > express written consent. Then having a written consent is a good idea. Stephen M. Webb: > The Free Software Foundation requires that express written consent be > in the form of total transfer of copyright to themselves. I believe that is giving bad example, using a method that only will have trustworthiness in foundations. Stephen M. Webb: > The express written consent in the form of Canonical's CLA only > requires a grant of the same rights as the copyright holder has, > without any change to their existing rights. I see the point: you think there's no difference between that who holds the copyright to be an developer or a company, because they both could make the code non copy-left if they wished. Well, there's a subtle difference: if someone owns the code he has written, it's a limited amount of code. But if someone collects code written by other people, it can be a big amount of a system. Stephen M. Webb: > I don't want to you be able to license you project under anything > except the GPL if I contribute to it. Rather I would say: I know to what I want to contribute, and that's different than what you are proposing. Stephen M. Webb: > Why should I make a contribution to your project if you're going to > make money off it and I'm not? You're getting the fruits of my > labour for free, I should get a cut of your profits. I have no complains about this. Stephen M. Webb: > Q: I'm not going contribute to you project unless you accept all my > conditions. > > A: I'm not going to accept your contributions to my project unless > you accept all of my conditions. The symmetry is delicious. It's OK, > you can continue to use my work for free. The relationship, therefore, is based on fear. Stephen M. Webb: > They will simply remain in the vast ranks of those who profit from my > work without compensating me in any way. You don't see that compensation because the mediator is no longer the money, but other people also giving their work for free to you. That doesn't mean that getting paid as much as you can isn't important, but that the abundance this relationship enables has value itself for the individual. Speaking more clearly: a job is fulfilling when it fulfils both your pocket and your heart. So losing the pocket just a bit for making extra good makes you happier, and the person where people go to do business with. And getting paid for something doesn't mean getting paid for everything. Much of my work is given freely, because it's something I have done for my own needs and I'm unwilling to make a business of all. So I give that to other people so they can enjoy it too, while I put my earning where it's more profitable (both economically and emotionally). Stephen M. Webb: > I am entitled to use your work for free and to be able to decide what you do to provide it to me, because I benefit from it and I want it. Not my way of thinking. In fact I would never considered this kind of people in my target audiences, do you? Stephen M. Webb: > You're evil and you're leeching from the creators and users of Free > software! I don't think so. What I think is this particular decision is a mistake. Stephen M. Webb: > [1]http://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate GPL FAQ - Developer Violate: > Strictly speaking, the GPL is a license from the developer for others > to use, distribute and change the program. The developer itself is > not bound by it, so no matter what the developer does, this is not a > “violation” of the GPL. GPL FAQ - Developer Violate: > However, if the developer does something that would violate the GPL > if done by someone else, the developer will surely lose moral > standing in the community." -------------- 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 gunnarhj at ubuntu.com Tue Dec 30 20:53:11 2014 From: gunnarhj at ubuntu.com (Gunnar Hjalmarsson) Date: Tue, 30 Dec 2014 21:53:11 +0100 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A307F4.7050704@gmail.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> <54A198F5.8080305@canonical.com> <54A20901.7040202@gmail.com> <54A2D534.8090308@canonical.com> <54A307F4.7050704@gmail.com> Message-ID: <54A310B7.60609@ubuntu.com> On 2014-12-30 21:15, Alberto Salvia Novella wrote: This cross-posting to multiple lists is annoying. Can you please stop that? -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj From es20490446e at gmail.com Tue Dec 30 21:51:17 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Tue, 30 Dec 2014 22:51:17 +0100 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A310B7.60609@ubuntu.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> <54A198F5.8080305@canonical.com> <54A20901.7040202@gmail.com> <54A2D534.8090308@canonical.com> <54A307F4.7050704@gmail.com> <54A310B7.60609@ubuntu.com> Message-ID: <54A31E55.7010908@gmail.com> Gunnar Hjalmarsson: > This cross-posting to multiple lists is annoying. Can you please stop that? Okay. -------------- 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 stephen.webb at canonical.com Tue Dec 30 16:39:16 2014 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Tue, 30 Dec 2014 11:39:16 -0500 Subject: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement In-Reply-To: <54A20901.7040202@gmail.com> References: <54A0C18C.2060506@gmail.com> <54A0DF61.2020502@canonical.com> <20141229123112.GA19648@gallifrey> <54A16B2E.8070102@gmail.com> <54A198F5.8080305@canonical.com> <54A20901.7040202@gmail.com> Message-ID: <54A2D534.8090308@canonical.com> On 12/29/2014 09:08 PM, Alberto Salvia Novella wrote: > > Instead of repeating myself, I'm going to ask you a question: > What do you think my purpose is? I don't feel particularly compelled to do your work for you. I will, however, address the usual concerns an a FAQ-like format. Q: You use the GNU Public License (GPL) when you distribute your software, and the GPL prevents you from placing additional restrictions on contributed code. Aren't you violating the GPL by requiring a copyright license for contributions to your projects? A: No, the GPL prevents you from placing additional restrictions on distributed code, not on contributed code. Accepting a contribution always requires additional restrictions, be they quality and applicability restrictions or in the case of an organization like the Free Software Foundation, full and express transfer of all authorship rights as far as legally possible in the local jurisdiction of the contributor. The CLA addresses upstream contribution, the GPL addresses downstream distribution. The Free Software Foundation themselves expressly agree that the GPL applies only to downstream distributions, not upstream contributions [1]. Strictly speaking, the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a “violation” of the GPL. Q: If I let you use some of the code I write, I should have a say in how you use it., including whether you use it to make money. A: Well, yes and no. If you're going to contribute code under the GPL, you can't apply addition restrictions on how it's used without violating the GPL. Sections 7 and 10 of the GPLv3 explicitly state that. Copyright law, which is the framework on which the GPL is enforced, does allow you to make such additional restrictions. In fact under most jurisdictions the default is that a project is unable to use your contributions at all under copyright without express written consent. The Free Software Foundation requires that express written consent be in the form of total transfer of copyright to themselves. The express written consent in the form of Canonical's CLA only requires a grant of the same rights as the copyright holder has, without any change to their existing rights. Q: I don't want to you be able to license you project under anything except the GPL if I contribute to it. A: That's nice. Q: Why should I make a contribution to your project if you're going to make money off it and I'm not? You're getting the fruits of my labour for free, I should get a cut of your profits. A: Sure. You're already getting a good deal of value from the fruits of my labour for free. I'd like to see you give something back in return, but I don't require it. It's nice that you'd contribute to my further development of the software you're using, and I appreciate being able to feed and clothe my family. If you think the exchange is unfair and you're entitled to more value than you're already receiving, you can try to use that contribution to generate your own revenue directly. Q: I'm not going contribute to you project unless you accept all my conditions. A: I'm not going to accept your contributions to my project unless you accept all of my conditions. The symmetry is delicious. It's OK, you can continue to use my work for free. Q: Requiring a CLA for contributions is destroying people's willingness to contribute. Aren't you concerned you're going to kill the goose that lays the golden eggs? A: Nice allegory. I always liked folk tales. Some individuals refuse to compensate in kind for the free stuff they're using because of the CLA. They have their varied and various reasons. Nobody is going to force them to contribute. It makes me sad when some individuals with something potentially good to contribute refuse to do so for whatever reason, but I defend their right to do so. They will simply remain in the vast ranks of those who profit from my work without compensating me in any way. Also, removing the CLA would kill the allegorical goose even faster. Q: The CLA is discouraging people from using your software. Can't you just get rid of the CLA? A: The vast, vast majority of people using my software have no idea what a CLA is. Getting rid of the CLA would not change that. Getting rid of the CLA would not force me to accept more upstream contributions either. Q: I am entitled to use your work for free and to be able to decide what you do to provide it to me, because I benefit from it and I want it. A: That's not a question. Q: You're evil and you're leeching from the creators and users of Free software! A: Well, I am a creator and user of Free software. You use my work for free and you seem to derive value from it without giving anything back. What was your question again? [1] http://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate -- Stephen M. Webb