From noreply at ubuntu.com Thu May 7 00:17:01 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 07 May 2015 00:17:01 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggerTalk=22_by_rocky-bernste?= =?utf-8?q?in?= Message-ID: <20150507001701.18801.5797@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggerTalk" page has been changed by rocky-bernstein: http://wiki.ubuntu.com/DebuggerTalk?action=diff&rev1=31&rev2=32 * [[http://bashdb.sourceforge.net/bashdb.html#PS4|PS4]] trick * Using to debug SYSV start/stop scripts. - * debugger `set_trace` trick? ''Note: `set_trace` is depricated in favor of `debugger`'' + * debugger `set_trace` trick? ''Note: `set_trace` is deprecated in favor of `debugger`'' Note: if you are going to debug `configure` scripts, you want the `readarray` builtin. ''This has since been encorporated into bash 4.0 and is not needed in that and later versions'' @@ -139, +139 @@ gem install trepanning The code is on github in https://github.com/rocky/rb-trepanning . + + == Debuggers since the talk == + + === Devel::Trepan === + + After years of hesitation, I wrote a [[https://metacpan.org/pod/Devel::Trepan|debugger for Perl]]. The reason I waited so long is that Perl has always had a powerful debugger. But it was yet another one-off any other debugger. And the code was like too many other debuggers, one file with 10K lines. (It's not the 10K I mind, my debugger probably has that many lines too; its the fact that it is all in one file.) + + === trepanjs === + + [[https://www.npmjs.com/package/trepanjs|trepanjs]] is a debugger for nodejs. It is more '''gdb''-like. However, command syntax follows Javascript notation, is does its predecessor "node debug" instead of a shell-like command set that ''gdb'' follows. For example you write: + + list(5) + + rather than: + + list 5 + ---- CategoryDebugging From noreply at ubuntu.com Thu May 7 00:17:54 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 07 May 2015 00:17:54 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggerTalk=22_by_rocky-bernste?= =?utf-8?q?in?= Message-ID: <20150507001754.18643.60367@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggerTalk" page has been changed by rocky-bernstein: http://wiki.ubuntu.com/DebuggerTalk?action=diff&rev1=32&rev2=33 === trepanjs === - [[https://www.npmjs.com/package/trepanjs|trepanjs]] is a debugger for nodejs. It is more '''gdb''-like. However, command syntax follows Javascript notation, is does its predecessor "node debug" instead of a shell-like command set that ''gdb'' follows. For example you write: + [[https://www.npmjs.com/package/trepanjs|trepanjs]] is a debugger for nodejs. It is more gdb-like. However, command syntax follows Javascript notation, is does its predecessor "node debug" instead of a shell-like command set that ''gdb'' follows. For example you write: list(5) From noreply at ubuntu.com Thu May 7 00:28:22 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 07 May 2015 00:28:22 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggerTalk=22_by_rocky-bernste?= =?utf-8?q?in?= Message-ID: <20150507002822.18860.45382@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggerTalk" page has been changed by rocky-bernstein: http://wiki.ubuntu.com/DebuggerTalk?action=diff&rev1=33&rev2=34 Nowadays there are number of choices for debuggers. - I rewrote the ''ruby-debug'' for Ruby 1.9 and 2.1 to make it less Rube-Goldberg. But this code needs a patched Ruby. You can get at:https://sourceforge.net/projects/ruby-debugger-runtime/. After that is installed: + I rewrote the ''ruby-debug'' for Ruby 1.9 and 2.1 to make it less Rube-Goldberg. But this code needs a patched Ruby. You can get at: https://sourceforge.net/projects/ruby-debugger-runtime/. After that is installed: gem install trepanning From ubuntu at desserud.org Sun May 17 20:24:31 2015 From: ubuntu at desserud.org (Hans Joachim Desserud) Date: Sun, 17 May 2015 22:24:31 +0200 Subject: Now that 10.04 has reached end of life... Message-ID: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> Hi all, 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. For those that were, I added a comment, updated the tags and in some cases forwarded bug reports to Debian. But I also found two categories of bugs I didn't know how to deal with, so I thought I'd check with others. 1. Bugs which are targeted to the lucid series [1]. These are usually fixed in a newer release but targeted to lucid and/or other releases for SRU purposes. If I remember correctly, somone had a script which would go through all bugs targeted to a particular release and close them with a message explaining the release had reached EOL. I think this was run the last time a release reached EOL. Should this be a regular thing, and the script re-run for lucid? (Note, I am talking about bugs _targeted_ towards a release, not tagged with one. The tagged ones might still be perfectly reproducible in newer releases, so I understand that we can't simply close them without investigating further.) 2. The second case I found was bugs where I couldn't check if the bug persisted because the package had been removed from newer releases of Ubuntu. Meaning that once 10.04 reached EOL, there was no longer any supported Ubuntu release where package was available. As an example, see for instance bug 565110 [2]. How does one proceed with bugs like this? 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. I checked to see if there were any default response for this kind of situation, but failed to find any. I guess a combination of [3] and [4] might make sense, but I'm not sure on how to phrase it. [1] https://bugs.launchpad.net/ubuntu/lucid/+bugs [2] https://bugs.launchpad.net/ubuntu/+source/hanzim/+bug/565110 [3] https://wiki.ubuntu.com/Bugs/Responses#Old_untouched_bugs [4] https://wiki.ubuntu.com/Bugs/Responses#Packages_not_provided_by_Ubuntu -- mvh / best regards Hans Joachim Desserud http://desserud.org From es20490446e at gmail.com Sun May 17 20:43:47 2015 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 17 May 2015 22:43:47 +0200 Subject: Now that 10.04 has reached end of life... In-Reply-To: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> Message-ID: <5558FD83.4000607@gmail.com> Hans Joachim Desserud: > 2. The second case I found was bugs where I couldn't check if the bug > persisted because the package had been removed from newer releases of > Ubuntu. Meaning that once 10.04 reached EOL, there was no longer any > supported Ubuntu release where package was available. As an example, see > for instance bug 565110 [2]. How does one proceed with bugs like this? In this case, I would just set its status as "won't fix". 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. 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. 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. 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". -------------- 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 Sun May 17 20:45:17 2015 From: teward at trekweb.org (Thomas Ward) Date: Sun, 17 May 2015 16:45:17 -0400 Subject: Now that 10.04 has reached end of life... In-Reply-To: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> References: <92e13fab67bb676bcf3dae32d75bad79@webmail.domeneshop.no> Message-ID: <5558FDDD.2090605@trekweb.org> Hello! On 05/17/2015 04:24 PM, Hans Joachim Desserud wrote: > ... I also found two categories of bugs I didn't know how to deal > with, so I thought I'd check with others. > > 1. Bugs which are targeted to the lucid series [1]. These are usually > fixed in a newer release but targeted to lucid and/or other releases > for SRU purposes. If I remember correctly, somone had a script which > would go through all bugs targeted to a particular release and close > them with a message explaining the release had reached EOL. I think > this was run the last time a release reached EOL. Should this be a > regular thing, and the script re-run for lucid? > > (Note, I am talking about bugs _targeted_ towards a release, not > tagged with one. The tagged ones might still be perfectly reproducible > in newer releases, so I understand that we can't simply close them > without investigating further.) Lucid would be "Won't Fix" if it's a series-targeted bug (not a tag). A comment that Lucid is EOL can go with it, and you should make a note in the response that if it is reproduced in later releases to make a note as such in the bug. Lucid only went EOL recently, and I know a series of bugs were autoclosed. Others can go through and close these kinds of bugs without incident I believe. > > 2. The second case I found was bugs where I couldn't check if the bug > persisted because the package had been removed from newer releases of > Ubuntu. Meaning that once 10.04 reached EOL, there was no longer any > supported Ubuntu release where package was available. As an example, > see for instance bug 565110 [2]. How does one proceed with bugs like > this? > > 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. I checked > to see if there were any default response for this kind of situation, > but failed to find any. I guess a combination of [3] and [4] might > make sense, but I'm not sure on how to phrase it. Tricky, but if the package doesn't exist, you still close the bug as "Won't Fix" for Lucid. We can close it as such because it doesn't exist in later releases. 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. However, in these cases you should comment as such with these changes, like with the previous bug case of "Won't Fix" with the only difference being that you explain that the package is no longer present in later releases. (Although you don't necessarily have to do this if the package is removed from later releases, given the package isn't present. > > [1] https://bugs.launchpad.net/ubuntu/lucid/+bugs > [2] https://bugs.launchpad.net/ubuntu/+source/hanzim/+bug/565110 > [3] https://wiki.ubuntu.com/Bugs/Responses#Old_untouched_bugs > [4] > https://wiki.ubuntu.com/Bugs/Responses#Packages_not_provided_by_Ubuntu > 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 had planned on the first of June to look through bugs still targeted against Lucid, and 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. However, that'd only hit bugs that are targeted against the Lucid series, not bugs that aren't specifically in that target series which are against Lucid. Thomas From webmaster at ubuntu.com Mon May 25 20:16:59 2015 From: webmaster at ubuntu.com (Help Ubuntu) Date: Mon, 25 May 2015 20:16:59 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20150525201659.612.53207@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=284&rev2=285 Comment: 1) RM'ed 10.04 as EOL. 2) Added supported release entires. == Perform a survey of your problem == - First, check the release notes for your version of Ubuntu: + First, check the release notes for your version of Ubuntu for any known issues: - * [[http://www.ubuntu.com/getubuntu/releasenotes/1004|Ubuntu 10.04 LTS (Lucid Lynx)]] - * [[http://www.ubuntu.com/getubuntu/releasenotes/1204|Ubuntu 12.04 LTS (Precise Pangolin)]] + * [[https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes|Ubuntu 12.04 LTS (Precise Pangolin)]] - * [[https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues|Ubuntu 14.04 (Trusty Tahr)]] <
> + * [[https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes|Ubuntu 14.04 (Trusty Tahr)]] + * [[https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes|Ubuntu 14.10 (Utopic Unicorn)]] + * [[https://wiki.ubuntu.com/VividVervet/ReleaseNotes|Ubuntu 15.04 (Vivid Vervet)]] <
> Second, check Launchpad for any duplicates, and make note of this. + === Desktop Applications === From noreply at ubuntu.com Sun May 31 01:06:58 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 31 May 2015 01:06:58 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Kernel/Debugging/Backlight=22_by?= =?utf-8?q?_penalvch?= Message-ID: <20150531010658.15092.81325@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=31&rev2=32 Comment: RM'ed cat /proc/version as already provided via the apport process. * {{{sudo fwts method > fwts_method}}} * {{{dmesg | grep 'ACPI: Video' > video}}} * {{{sudo dmidecode > dmidecode.log}}} - * {{{cat /proc/version > version}}} == Testing for a work around == From noreply at ubuntu.com Sun May 31 01:18:25 2015 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 31 May 2015 01:18:25 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Kernel/Debugging/Backlight=22_by?= =?utf-8?q?_penalvch?= Message-ID: <20150531011825.15395.72160@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=32&rev2=33 Comment: RM'ed dmesg as already provided from the apport process. * Please note this must be done after the prior command, as it uses the newly created DSDT.dat to create the file to attach DSDT.dsl. * {{{sudo fwts > fwts}}} * {{{sudo fwts method > fwts_method}}} - * {{{dmesg | grep 'ACPI: Video' > video}}} * {{{sudo dmidecode > dmidecode.log}}} == Testing for a work around ==