From noreply at ubuntu.com Tue Jun 2 11:54:10 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 02 Jun 2015 11:54:10 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Kernel/Debugging/Backlight=22_by?= =?utf-8?q?_penalvch?= Message-ID: <20150602115410.2035.6826@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Kernel/Debugging/Backlight" page has been changed by penalvch: http://wiki.ubuntu.com/Kernel/Debugging/Backlight?action=diff&rev1=33&rev2=34 Comment: As per LP#1460088 added acpi_osi= . * {{{echo 8 > /sys/class/backlight/intel_backlight/brightness}}} * Please comment on if the brightness changes. * Reboot with just kernel parameter video.use_bios_initial_backlight=0 and make a comment on if you can now alter the backlight with hotkeys or a brightness applet. + * Reboot with just kernel parameter acpi_osi= and make a comment on if you can now alter the backlight with hotkeys or a brightness applet. * If using a v3.13.x+ series kernel, reboot with just kernel parameter video.use_native_backlight=1 and make a comment on if you can now alter the backlight with hotkeys or a brightness applet. * If your backlight hotkeys are Fn+Left and Fn+Right, add kernel parameter atkbd.softraw=0 to /boot/grub/menu.lst . Then, switch to any console, e.g. Ctrl+Alt+F1, login by root account and execute:<
> {{{showkey -s}}} <
> <
> Then, press Fn+Left and Fn+Right key to check the code that shows up on screen. Post the results to the report. For example: <
> <
> Fn+Left: <
> 0xe0 0x4c 0xe0 0xcc <
> <
> Fn+Right: <
> 0xe0 0x54 0xe0 0xd4 From ubuntu at desserud.org Tue Jun 9 20:19:08 2015 From: ubuntu at desserud.org (Hans Joachim Desserud) Date: Tue, 09 Jun 2015 22:19:08 +0200 Subject: Now that 10.04 has reached end of life... In-Reply-To: <5558FDDD.2090605@trekweb.org> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> <5558FDDD.2090605@trekweb.org> Message-ID: Hello again and thanks for your answers. > If the bug has a Lucid and a non-Lucid target, then > I believe that "Won't Fix" for the Lucid target and "Invalid" for later > release targets since the package was removed from those releases is a > proper course of action. I ended up closing the bug as Invalid and adding a comment explaining the situation. > run a script I developed that uses the > API of Launchpad to close those bugs (I did this for Karmic bugs a > while > ago) and comment why that "Won't Fix" status was set. Ok, that sounds good. I'll leave these alone then. I figured it was probably no point looking these up and closing the manually, if a script could do the same job. I did remember *someone* had run such a script a while back, but not who. > The problem here is the permissions for bug statuses. The "Won't Fix" > status and the "Triaged" status can only be set by users/bots in the > Bug > Control group. I know. I supposed I should get around to applying for that some day. :) --- mvh / best regards Hans Joachim Desserud http://desserud.org PS. My apologies to Thomas Ward which will receive two copies of this email because I failed to send it to the list the first time. From ubuntu at desserud.org Tue Jun 9 20:29:48 2015 From: ubuntu at desserud.org (Hans Joachim Desserud) Date: Tue, 09 Jun 2015 22:29:48 +0200 Subject: Now that 10.04 has reached end of life... In-Reply-To: <5558FD83.4000607@gmail.com> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> <5558FD83.4000607@gmail.com> Message-ID: <1c58efc880e450ea2b543a1ee84bc929@webmail.domeneshop.no> Hans Joachim Desserud: >> As we all know, Ubuntu 10.04 reached end of life at the end of last >> month. Right before this happened I looked over the bug reports >> affecting this release I am subscribed to check whether they were >> still reproducible on later releases. Alberto Salvia Novella: > Not worth the effort. If the bug is really important, someone will > confirm it when using the operating system or performing manual > testing. > It's much faster to test if a software works than confirming all the > unconfirmed reports. Hmm, well, they might be reported or show up in some cases. These were mainly straight-forward reproducible bugs though. I reckon most developers will be looking for bugs affecting the current development release. Which means they might miss out on issues which were reported earlier and haven't been updated the last couple of releases. Of course it might be argued that these are low priority since few people are complaining and/or they concern edge cases. However, the bugs are still present and reproducible, it's just at a glance unclear whether that still remains the case x releases later. So my part is updating them to reflect that they are still present. Hans Joachim Desserud: >> Since it no longer exists in Ubuntu, I doubt these issues will be >> fixed, unless they are addressed upstream or repackaged in Ubuntu. >> Which is a bit sad, but I that also means they are padding out the >> list of open bugs, making it harder to find actual issues. > Non necessarily. Although it would be good to remove those old bugs, > you can just filter releases using tags. Sure, that gives you a more updated image of the current situation. But there might be bugs reported in the past which are still present. > On the other hand, I proposed a long time ago that a bot should clean > those by asking the user for confirmation while setting the report > status to "incomplete". It's tricky problem. On the one hand, I'm tempted to agree, because there's various older reports around affecting versions which are no longer available. On the other side though, the bugs might still be there even though people haven't commented in a year or two, because all the necessary information is already contained in the bug report. --- mvh / best regards Hans Joachim Desserud http://desserud.org From es20490446e at gmail.com Wed Jun 10 13:51:56 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 10 Jun 2015 15:51:56 +0200 Subject: Now that 10.04 has reached end of life... In-Reply-To: <1c58efc880e450ea2b543a1ee84bc929@webmail.domeneshop.no> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> <5558FD83.4000607@gmail.com> <1c58efc880e450ea2b543a1ee84bc929@webmail.domeneshop.no> Message-ID: <557840FC.4070006@gmail.com> Hans Joachim Desserud: > These were mainly straight-forward reproducible bugs though. I reckon > most developers will be looking for bugs affecting the current > development release. The idea is that we have more bugs than what we can work on, so right now is better to spend time on known ones. -------------- 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 louisangelini at gmail.com Thu Jun 11 09:23:18 2015 From: louisangelini at gmail.com (Louis Angelini) Date: Thu, 11 Jun 2015 10:23:18 +0100 Subject: Black screen Message-ID: Hi. I recently installed Kubuntu and I think that the plasma desktop is the greatest thing I've ever seen. It's because of how much I like it that I'm contacting you as I've developed the famous kubunu black screen twice. Once with 15.04 and once with 14.04. I reverted back to 14.04 after it happened the first time as I figured it would be more stable. I'm sure that ye are aware of the problem already but just in case I said I'd send a quick email I ran the following commands to fix it mv ~/.kde ~/.kde.old mv ~/.cache ~/.cache.old shutdown -r now Do you know of something that I could update or anything I could do that could fix this issue. I use my laptop for work and sometimes I need it urgently. I might have to go back to plain old ubuntu if this issue occurs again but I really really don't want to. Thanks Louis Angelini From jordanh at sent.com Thu Jun 11 15:24:33 2015 From: jordanh at sent.com (Jordan Hewitt) Date: Thu, 11 Jun 2015 08:24:33 -0700 Subject: Black screen In-Reply-To: References: Message-ID: <2826256.fYIchmN5l5@sumo> Hi, Louis, I think this may be an issue with the video driver. What video card are you using? On Thursday, June 11, 2015 10:23:18 AM Louis Angelini wrote: > Hi. I recently installed Kubuntu and I think that the plasma desktop > is the greatest thing I've ever seen. > It's because of how much I like it that I'm contacting you as I've > developed the famous kubunu black screen twice. Once with 15.04 and > once with 14.04. I reverted back to 14.04 after it happened the first > time as I figured it would be more stable. > > I'm sure that ye are aware of the problem already but just in case I > said I'd send a quick email > > I ran the following commands to fix it > > mv ~/.kde ~/.kde.old > mv ~/.cache ~/.cache.old > shutdown -r now > > Do you know of something that I could update or anything I could do > that could fix this issue. > I use my laptop for work and sometimes I need it urgently. I might > have to go back to plain old ubuntu if this issue occurs again but I > really really don't want to. > > Thanks > > Louis Angelini From noreply at ubuntu.com Sat Jun 13 12:55:56 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sat, 13 Jun 2015 12:55:56 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Bug_statuses=22_by_penalvch?= Message-ID: <20150613125556.27113.92852@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=74&rev2=75 Comment: 1) As per LP#1463553 and others, clarified Confirmed for linux (Ubuntu) as defined by the Ubuntu Kernel Team. 2) UbuntuBugControl > Ubuntu Bug Control * Like Invalid reports, Expired reports do not show up in default searches. * '''Confirmed''': + * For all packages except for linux (Ubuntu): - * Another reporter has experienced the same issue. This can come in the form of a duplicate report or a comment. + * Another reporter has experienced the same issue. This can come in the form of a duplicate report or a comment. - * {{{Confirmed}}} reports 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 report is applicable to Ubuntu in general, and not hardware failure, lack of knowledge, etc. + * 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). + * In general, please don't confirm your own bugs, unless there is a documented exception by the development group of the package. + * Only for linux (Ubuntu): + * Confirmed means the original reporter has at least attached the minimum amount of information to begin triaging. + * The original reporter has provided previously requested information. * '''Triaged''': - * A member of [[UbuntuBugControl]] believes that the report describes a genuine issue in enough detail that a developer could start working on a fix. + * A member of [[Ubuntu Bug Control|https://wiki.ubuntu.com/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 for the developer to fix it. * While not a requirement, a report's Ubuntu task status should be Triaged before any upstream forwarding occurs. * With reports about '''linux''': Triaged means that the original reporter has tested with the latest upstream mainline kernel they can technically test to. From noreply at ubuntu.com Tue Jun 16 11:04:04 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 16 Jun 2015 11:04:04 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Tags=22_by_penalvch?= Message-ID: <20150616110404.14205.58192@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=201&rev2=202 Comment: As per https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1464365/comments/3 further clarified regression-release and regression-update. 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. This also applies to a development release where an update introduces a regression prior to its official release.|| - || [[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. This would not apply to a development release where a regression was introduced prior to its official release.|| || [[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=needs-bisect|needs-bisect]] || This is for when a bisect is requested or required to fix the bug. || From noreply at ubuntu.com Thu Jun 18 16:22:11 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 18 Jun 2015 16:22:11 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingKVM=22_by_serge-hallyn?= Message-ID: <20150618162211.21966.4973@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingKVM" page has been changed by serge-hallyn: http://wiki.ubuntu.com/DebuggingKVM?action=diff&rev1=7&rev2=8 = Debugging procedure = + * If it is easily reproducible, try building from upstream git and reproducing. Then bisect + * [ todo - give example ] + * Try a newer kernel if available + * If KSM is enabled, see whether disabling it helps = Reporting a bug = From noreply at ubuntu.com Fri Jun 19 14:56:12 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 19 Jun 2015 14:56:12 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22walterorlin/debugging-debian-ins?= =?utf-8?q?taller=22_by_walterorlin?= Message-ID: <20150619145612.10769.25447@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "walterorlin/debugging-debian-installer" page has been changed by walterorlin: http://wiki.ubuntu.com/walterorlin/debugging-debian-installer New page: <> ||'''Contents'''<
><>|| = Introduction = The first few times you have to report a problem with a debian installer image not installing can be frustrating as switching to a tty and using ubuntu-bug is not possible in the limited busybox session but this allow for the alternate install for lubuntu on the oldest machines to work. Getting the debug information when this breaks can be frustrating. However, to triage these bugs without logs is really hard to get the developers the info needed. = How to file = With debian-installer ubuntu-bug from a shell will not work. The debian-installer busy box enviorment is quite limited in what commands you can use. Even commands like less are not available. There are a few options available here that work well. 1. Download the debug logs from another computer on the lan. 2. mount a filesystem and attach them after booting into a working system. = Bug tags = Bug tags specific to the package or area should be included here for reporters so they can tag their bug report. It will also be useful for triagers. The Bugs/Tags wiki page should then be modified to include these tags. = Debugging procedure = In depth debugging procedures for this particular package or subsystem. This usually is information about the log files to gather and what to look for in them. = How to Triage = Information that will facilitate the triaging of bugs for this package or subsystem. Remind triagers of the bug tags in use for this particular package. == Stock Reply == A stock reply to be used for initial bug reports basically asking for the stuff in "How to file". The Bugs/Responses page should include this reply. == How to Forward == In the event that the package or subsystem has an upstream bug tracker this section should contain detailed steps to forward a bug to that tracker. Some packages may just link to the general "How to Forward" page for another bug tracker like Gnome's bugzilla or freedesktop.org's bug tracker. = Known bugs = Description of known bug reports that may receive duplicates and how to recognise them. This information should be obtained by looking for bugs tagged as 'metabug'. '''Open''' || '''Bug''' || '''Subject''' || '''Symptom''' || || [[https://launchpad.net/bugs/8896|8896]] || The subject from LP || This bug can be identified by ... || '''Closed''' || '''Bug''' || '''Subject''' || '''Symptom''' || || [[https://launchpad.net/bugs/8896|8896]] || The subject from LP || This bug can be identified by ... || = Non-bugs = How to recognise common issues arising from hardware failures, common feature requests and other invalid bugs for this category. Advice how triage them and stock responses. ---- CategoryBugSquad CategoryDebugging From ubuntu at desserud.org Sun Jun 21 15:03:17 2015 From: ubuntu at desserud.org (Hans Joachim Desserud) Date: Sun, 21 Jun 2015 17:03:17 +0200 Subject: Now that 10.04 has reached end of life... In-Reply-To: <557840FC.4070006@gmail.com> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> <5558FD83.4000607@gmail.com> <1c58efc880e450ea2b543a1ee84bc929@webmail.domeneshop.no> <557840FC.4070006@gmail.com> Message-ID: <29a870a56fb892686b3720b568791f30@webmail.domeneshop.no> >> These were mainly straight-forward reproducible bugs though. I reckon >> most developers will be looking for bugs affecting the current >> development release. > > The idea is that we have more bugs than what we can work on Yes, I'm aware. It's a bit unfortunate, but I try to help out. :) > so right > now is better to spend time on known ones. I have to admit I don't fully understand how you define as a known bug here. I guess I should clarify that I'm talking about bugs I've either confirmed or comment on in some way in the past. If a bug is reported (and confirmed), I would count it among known issues. What isn't known in most of these cases is whether the bug has survived through years of new versions and releases. It may have been resolved, either upstream or a new version of a depending library or something else. However, if it remains, it still something affecting the latest development release which should be fixed. --- mvh / best regards Hans Joachim Desserud http://desserud.org From es20490446e at gmail.com Mon Jun 22 00:53:03 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 22 Jun 2015 02:53:03 +0200 Subject: Now that 10.04 has reached end of life... In-Reply-To: <29a870a56fb892686b3720b568791f30@webmail.domeneshop.no> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> <5558FD83.4000607@gmail.com> <1c58efc880e450ea2b543a1ee84bc929@webmail.domeneshop.no> <557840FC.4070006@gmail.com> <29a870a56fb892686b3720b568791f30@webmail.domeneshop.no> Message-ID: <55875C6F.709@gmail.com> Hans Joachim Desserud: > What isn't known in most of these cases is whether the bug has survived > through years of new versions and releases. If this happens, it is a clear signal that the software quality is not very good. In my opinion 99% of bugs should be catches just after writing the code, by doing unit testing on each method been used. There is an old saying in Japan which says "if you have not the time to prevent errors, I expect you to have the time for solving them". So when I see buggy software, I know there is no excuse. Simply some developer is writing crazily and leaving the dirty work to others, and nobody preventing it. The simplest test-case would have cached most of these errors. There are applications that I use frequently that never fail; like Gimp, Audacity, Blender, Owncloud, and many from KDE. On the other hand many GNOME applications, although I love the concept of simplicity, usually look more like prototypes. So my personal choice has been to assume that the software is published with a decent quantity of bugs, decent to fix them on a decent time-frame. If not I believe the problem is human not technical, and that's what needs improvements. Other formula is simply bailing water while leaving the hole open. -------------- 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 Tue Jun 23 17:55:49 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 23 Jun 2015 17:55:49 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22walterorlin/debugging-debian-ins?= =?utf-8?q?taller=22_by_walterorlin?= Message-ID: <20150623175549.5720.85539@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "walterorlin/debugging-debian-installer" page has been changed by walterorlin: http://wiki.ubuntu.com/walterorlin/debugging-debian-installer?action=diff&rev1=1&rev2=2 = How to file = - With debian-installer ubuntu-bug from a shell will not work. The debian-installer busy box enviorment is quite limited in what commands you can use. Even commands like less are not available. There are a few options available here that work well. 1. Download the debug logs from another computer on the lan. 2. mount a filesystem and attach them after booting into a working system. + With debian-installer ubuntu-bug from a shell will not work. The debian-installer busy box enviorment is quite limited in what commands you can use. Even commands like less are not available. There are a few options available here that work well. 1. Download the debug logs from another computer on the lan. 2. mount a filesystem and attach them after booting into a wor1. >From another machine on the local network, If debian installer comes up with a red screen saying failed ot install go through and try again and it is still broken at red screen if you use the keyboard to navigate to the go back back button it will bring you to a menu of all of the various steps of the installation. If you go all the way to the bottom of this list there is an option to save debug logs. Press enter with the cursor on this option. Then for a computer on the local network. Press to save debug logs on web. IT will give you an ip address from an embeded webserver. now from another computer on the same network or even the host if it is a virtual machine download all of the debug files. IF it is a linux system and easy way to get all the files and save them to another computer is to run wget -r on the ip address from the machine failing to install. + king system. + + + 1. From another machine on the local network, If debian installer comes up with a red screen saying failed ot install go through and try again and it is still broken at red screen if you use the keyboard to navigate to the go back back button it will bring you to a menu of all of the various steps of the installation. If you go all the way to the bottom of this list there is an option to save debug logs. Press enter with the cursor on this option. Then for a computer on the local network. Press to save debug logs on web. IT will give you an ip address from an embeded webserver. now from another computer on the same network or even the host if it is a virtual machine download all of the debug files. IF it is a linux system and easy way to get all the files and save them to another computer is to run `wget -r` on the ip address from the machine failing to install which will save all the debug files. Otherwise you will need to dowload and save these files manually. + + Then since ubuntu-bug does not work in the busy box enviornment from this computer open a webbrowser and login to https://launchpad.net and go to https://launchpad.net/ubuntu/+source/debian-installer and press the report bug button. Then enter in your bug report and attach all the files saved as debug logs. Currently launhcpad lets me attach one file per comment manually. + + 2. = Bug tags =