gmane.linux.ubuntu.bugsquad

[Ubuntu Wiki] Update of "Chromium/Debugging" by uusijani

Ubuntu Wiki — 2012-05-21T16:01:58

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "Chromium/Debugging" page has been changed by uusijani:
http://wiki.ubuntu.com/Chromium/Debugging?action=diff&rev1=9&rev2=10

Comment:
restructuring, language

  ## page was renamed from Chromium/Debug
+ If Chromium crashes and you want to file a bug upstream, use their [[http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux|linux template]]. Always include the output from the following command:
- When you want to file a bug, it should be filed '''upstream''' using this '''[[http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux|linux template]]'''.
- Please always include the result of the following command:
- {{{
- dpkg -l | grep chromium-}}}
- 
- = Debugging Chromium crashes =
- 
- If chromium crashes and if you want to file a '''[[http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux|bug upstream]]''', you need to provide a proper backtrace for your crash.
- 
- It could be accomplished using '''gdb''' and some debug packages.
- 
- If you know nothing about gdb, the generic instructions are available here: [[https://wiki.ubuntu.com/Backtrace|Backtraces with gdb]]
- 
- The debug package for chromium is called '''chromium-browser-dbg''' (it's big, ~75MB). It could be installed and removed like any other packages.
- 
- Note: you may need other debug packages if the backtrace shows lines like "#5  0x083949e0 in ?? ()".
- In that case, you need the corresponding -dbg or -dbgsym packages.
- Instructions about those are available in [[https://wiki.ubuntu.com/DebuggingProgramCrash|DebuggingProgramCrash]]
- 
- Once done, open a terminal and proceed as follow:
  
  {{{
+ $ dpkg -l | grep chromium-
+ }}}
+ 
+ You'll need to provide a [[https://wiki.ubuntu.com/Backtrace|backtrace]]. It can be produced using gdb, with the help of debugging symbols.
+ 
+ == Getting a backtrace ==
+ Debugging symbols come in packages that can be [[InstallingSoftware|installed just any other software package]] in Ubuntu. The debugging symbols package for Chromium is called ''chromium-browser-dbg''. Once you've installed it, open a terminal and proceed as follows:
+ 
+ {{{
- chromium-browser --debug 2>&1 | tee gdb-chromium.txt
+ $ chromium-browser --debug 2>&1 | tee gdb-chromium.txt
  (gdb) handle SIG33 pass nostop noprint
  (gdb) set pagination 0
  (gdb) run <arguments, if any>
  }}}
  
- do what you need to do to trigger the crash, then:
+ Do what you need to do to trigger the crash, then:
  
  {{{
  (gdb) backtrace
< at >< at > -37, +27 < at >< at >

  (gdb) quit
  }}}
  
+ If the backtrace shows lots of lines with question marks (such as "#5&nbsp;0x083949e0&nbsp;in&nbsp;??&nbsp;()"), you're likely to need additional debugging symbols packages. To find out which libraries Chromium is loading, try:
- Check the file '''gdb-chromium.txt''' to see if it contains symbols (as few "?? ()" as possible).
- If not, please locate and install the missing debug package(s) and retry.
  
- Note: ''ldd /usr/lib/chromium-browser/chromium-browser'' could give you a clue of which libs are loaded, and http://packages.ubuntu.com/ could tell you in which package they live.
+ {{{
+ $ ldd /usr/lib/chromium-browser/chromium-browser
+ }}}
  
- Once you feel it's good enough, you may attach the file '''gdb-chromium.txt''' to your bug report.
+ Then look for corresponding -dbg or -dbgsym packages in the repositories.
  
- Note: since chromium is multi-process (it spawns several processes, such as the sandbox and all renderers), the stack may be useless, depending on where the crash occurs. You can then try with --single-process (after --debug). If it is still not enough, you can try inferring from the upstream chrome debugging tips: http://code.google.com/p/chromium/wiki/LinuxDebugging
+ == Debugging child processes ==
+ Since Chromium normally spawns several processes (such as the sandbox and renderers), the backtrace from the browser process may not be useful (unless it is the main process that crashes). For catching backtraces from Chromium's child processes, you should run Chromium with --single-process:
+ 
+ {{{
+ $ chromium-browser --debug --single-process 2>&1 | tee gdb-chromium.txt
+ }}}
+ 
+ Then proceed as above with gdb.
+ 
+ Once you feel your backtrace file (gdb-chromium.txt) is sufficient, attach it to your bug report.
+ 
+ == External links ==
+  * [[http://code.google.com/p/chromium/wiki/LinuxDebugging|Upstream debugging instructions]]
+ 
  ----
  CategoryDebugging

[Ubuntu Wiki] Update of "Chromium/Debugging" by uusijani

Ubuntu Wiki — 2012-05-21T16:02:45

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "Chromium/Debugging" page has been changed by uusijani:
http://wiki.ubuntu.com/Chromium/Debugging?action=diff&rev1=10&rev2=11

Comment:
typo: just +like any

  You'll need to provide a [[https://wiki.ubuntu.com/Backtrace|backtrace]]. It can be produced using gdb, with the help of debugging symbols.
  
  == Getting a backtrace ==
- Debugging symbols come in packages that can be [[InstallingSoftware|installed just any other software package]] in Ubuntu. The debugging symbols package for Chromium is called ''chromium-browser-dbg''. Once you've installed it, open a terminal and proceed as follows:
+ Debugging symbols come in packages that can be [[InstallingSoftware|installed just like any other software package]] in Ubuntu. The debugging symbols package for Chromium is called ''chromium-browser-dbg''. Once you've installed it, open a terminal and proceed as follows:
  
  {{{
  $ chromium-browser --debug 2>&1 | tee gdb-chromium.txt

Re: [Ubuntu Wiki] Update of "Bugs/Responses" by veger

Tom Hill — 2012-05-21T16:34:45

True, but adding the meaning next to it would teach them the meaning.

On 21 May 2012, at 15:53, Brian Murray <brian-GeWIH/nMZzLQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: [Ubuntu Wiki] Update of "Bugs/Responses" by veger

Brian Murray — 2012-05-21T14:53:22

Not everybody may know what EOL stands for, perhaps putting the words in
it or avoiding the acronym at all would be more informative.

--
Brian Murray
Ubuntu Bug Master

Re: apport: removing passwords from "modified.conffile..."

Nigel Babu — 2012-05-20T16:45:13

Hi Lars,

You could probably look at what I had done for the rhythmbox apport
hook.[1]  Take a look at the mask_values() function.

[1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/rhythmbox/oneiric/view/head:/debian/source_rhythmbox.py

Regards
Nigel



On Sat, May 19, 2012 at 3:51 PM, Lars Duesing
<lars.duesing-7oc6RrGaw49LT8YB/y1Xvw< at >public.gmane.org> wrote:

Re: Adding a package special log file to apport

Lars Duesing — 2012-05-18T21:01:52

Hi Brian,


Thanks for your offer!
 If you want to have a look at 
https://code.launchpad.net/~lars.duesing/ubuntu/precise/aiccu/aiccu-apport-fix 
I would be pleased!

Lars

[Ubuntu Wiki] Update of "Bugs/Responses" by veger

Ubuntu Wiki — 2012-05-19T08:55:54

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "Bugs/Responses" page has been changed by veger:
http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=349&rev2=350

  
  If the specific release has reached EOL per https://wiki.ubuntu.com/Releases and there is not enough information to work on the bug, then you can set to '''Incomplete''' and use the following response (Note RELEASE and DATE are placeholders):
  
- ||<tablestyle="background-color: #eee">Thank you for reporting this bug to Ubuntu.  RELEASE reached EOL on DATE.<<BR>>Please see this document for currently supported Ubuntu releases:<<BR>>https://wiki.ubuntu.com/Releases <<BR>><<BR>>I've tried recreating this bug with RELEASE and was unable to, given the information you've provided.  Please either a) upgrade and test or b) increase the verbosity of the steps to recreate it so we can try again.<<BR>><<BR>>Please feel free to report any other bugs you may find.||
+ ||<tablestyle="background-color: #eee">Thank you for reporting this bug to Ubuntu. RELEASE reached EOL on DATE.<<BR>>See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases <<BR>><<BR>>I've tried recreating this bug with RELEASE and was unable to, given the information you've provided.  Please upgrade to the latest version and re-test. If the bug is still reproducable, increase the verbosity of the steps to recreate it so we can try again.<<BR>><<BR>>Do feel free to report any other bugs you may find.||
  
  == An idea to improve Ubuntu ==
   Note: If it is a request to add a feature to a '''specific program''' it should be '''forwarded to the upstream developers instead.''' See: [[Bugs/HowToTriage#Forwarding%20upstream|Forwarding Bugs Upsteam]]

apport: removing passwords from "modified.conffile..."

Lars Duesing — 2012-05-19T07:17:35

Hi again,

I have another problem: How to remove passwords from apport-attachments 
which are automagically added?
I have searched for modified_conffile throughout the sources, but cannot 
find anything, except in test-scenarios...
In the file /etc/aiccu.conf and modified.conffile..etc.aiccu.conf.txt 
there are sensitive login-information:
 > username LxxxxxxE
 > password xxxxxxx
maybe even in comments :(

Lars

apport: removing passwords from "modified.conffile..."

Lars Duesing — 2012-05-19T10:21:48

Hi again,

I have another problem: How to remove passwords from apport-attachments 
which are automagically added?
I have searched for modified_conffile throughout the sources, but cannot 
find anything, except in test-scenarios...
In the file /etc/aiccu.conf and modified.conffile..etc.aiccu.conf.txt 
there are sensitive login-information:
 > username LxxxxxxE
 > password xxxxxxx
maybe even in comments :(

Lars

Re: New message for Bug/Responses#Release_has_reached_EOL

Maarten Bezemer — 2012-05-19T08:57:15

Hello,

I have updated the page with this text:


Thank you for reporting this bug to Ubuntu. RELEASE reached EOL on DATE.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases 

I've tried recreating this bug with RELEASE and was unable to, given the information you've provided. Please upgrade to the latest version and re-test. If the bug is still reproducable, increase the verbosity of the steps to recreate it so we can try again.

Do feel free to report any other bugs you may find.


Thanks for your input.
Regards,
  Maarten

Re: Adding a package special log file to apport

Brian Murray — 2012-05-18T19:31:05

Well, if the aiccu package generates multiple binary packages then you'd
want to name it source_aiccu.py so the package hook would be run for
every binary package.

There are also lots of examples on most ubuntu systems in
/usr/share/apport/package-hooks.  Additionally, there are some
convenience functions for adding information in hookutils.py like
attach_file_if_exists which was mentioned in the code snippet.

Oh and you initially mentioned you only want this for crashes, so keepng
in mind that package hooks are also run when someone uses 'ubuntu-bug
aiccu', you'd probably want:

        if report['ProblemType'] == 'Crash':
            attach_file_if_exists(...)

Also if you need the changes to package sponsored or SRU'ed (you'd
probably want it in Precise), I am happy to help.

--
Brian Murray

Re: Adding a package special log file to apport

Daniel Manrique — 2012-05-18T19:09:52


Look here for information on how to add package hooks to do stuff like this:

https://wiki.ubuntu.com/Apport/DeveloperHowTo#Package_Hooks

In brief (and don't believe me too much, I've never done it, I'm just reading
the docs and comparing against what a package I know does this has):

- Add a Python script/file/hook to your package (say, aiccu.py) with something
like this:

from apport.hookutils import *

def add_info(report, ui=None):
    attach_file_if_exists(report, '/var/log/aiccu.log', key='aiccuLog')
    report['SecretMessage'] = 'my hook was here'


- Make sure your package installs it in /usr/share/apport/package-hooks/aiccu.py.

- Daniel

[Ubuntu Wiki] Update of "DebuggerTalk_it" by fabiomarconi

Ubuntu Wiki — 2012-05-18T16:22:09

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "DebuggerTalk_it" page has been changed by fabiomarconi:
http://wiki.ubuntu.com/DebuggerTalk_it?action=diff&rev1=1&rev2=2

Nell'arena pratica, io posso mostrare come utilizzare per il debug un progetto GNU automake. Ad esempio, ci potrebbe essere un campo teorico su come strutturare la scrittura di un debugger. (There could be a theoretical area such as how to structure writing a debugger. (Quelli per ruby e Python sono interessanti qui).

- In passato, qualcuno mi chieset ''"cosa c'è di affascinante in un debugger?"'' Oppure un'osservazione fatta da un imprenditore fù "''Non ho mai usato un debugger, io '''scrivo''' codice''". As a systems administrator one is often confronted with lots of code that you didn't write. You suspect the code might not even be written all that well, but you are more sure that there isn't much in the way of documentation or comments in the code. And you've got a problem to solve. Here is where a debugger comes into play.
+ In passato, qualcuno mi chieset ''"cosa c'è di affascinante in un debugger?"'' Oppure un'osservazione fatta da un imprenditore fù "''Non ho mai usato un debugger, io a malapena '''scrivo''' codice''". In veste di amministratore di sistema, chiunque è sempre a confronto con una moltitudine di codice che non ha scritto. Si potrebbe sospettare che il codice non sia stato scritto perfettamente, e che sicuramente non ci sia molta documentazione o commenti nel codice. Nel caso si abbia un problema da risolvere, qui entra in gioco il debugger.

- I've also heard the observation that you don't need a debugger because you go into a Bash, Python or Ruby shell and just start typing statements in the language. Again if you have a high-level idea of what's going on, that's great. However the hardest part here is getting the context correct. I need a `foo` object from class `Foo` and then need to hook the `bar` object from class `Bar` which means importing or requiring module `baz` into `foo` before I can call this method `fubar` that is of interest to me. With a debugger you work on code that purports to work and largely does. So for the most part, most of the necessary setup has been done for you. In a sense a ''good'' debugger is really not all that different than a shell, it's just that the context has already been set up for you. We'll see that in the Python debugger later.
+ Ho anche sentito dire che voi non avete bisogno di un debugger perchè state usando una shell Bash, Python o Ruby ed avete appena iniziato a scrivere le dichiarazioni. Io ho bisogno di un oggetto `foo` dalla classe `Foo` e quindi devo agganciare la `bar` aggetto dalla classe `Bar` che significa importare o richiedere il modulo `baz` in `foo` prima che io possa chiamare ciò `fubar` che è interessante per me. Con un debugger si lavora sul codice ed in maniera estesa. Quindi a grandi linee, la maggior parte dei necessari setup sono stati fatti per voi. Con il proposito che un buon debugger non è per nulla diverso da una shell, semplicemente il contesto è già stato preimpostato. Vedremo questo in seguito nel debugger Phyton.

=== Why model debuggers off of gdb? ===

Adding a package special log file to apport

Lars Düsing — 2012-05-18T17:39:58

Hi all,
Is there any way to add a log file to apport on crash of a specific  
package?
I need /var/log/aiccu.log on crash of aiccu...

Thanks,
Lars

[Ubuntu Wiki] Update of "DebuggerTalk_it" by fabiomarconi

Ubuntu Wiki — 2012-05-18T15:40:35

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "DebuggerTalk_it" page has been changed by fabiomarconi:
http://wiki.ubuntu.com/DebuggerTalk_it

Comment:
Italian translation started

New page:
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||

== Introduzione ==
Praticamente affronteremo una discussione sui debugger che ho scrittto o sui quali ho lavorato [[http://bashdb.sf.net|GNU bash]], [[http://bashdb.sf.net/remake|GNU make]], [[http://bashdb.sf.net/pydb|Python]],e [[http://rubyforge.org/projects/ruby-debug/|Ruby]]. Gli agomenti affrontati andranno dallo storico al pratico.

Nell'arena pratica, io posso mostrare come utilizzare per il debug un progetto GNU automake. Ad esempio, ci potrebbe essere un campo teorico su come strutturare la scrittura di un debugger. (There could be a theoretical area such as how to structure writing a debugger. (Quelli per ruby e Python sono interessanti qui).

In passato, qualcuno mi chieset ''"cosa c'è di affascinante in un debugger?"'' Oppure un'osservazione fatta da un imprenditore fù "''Non ho mai usato un debugger, io '''scrivo''' codice''". As a systems administrator one is often confronted with lots of code that you didn't write. You suspect the code might not even be written all that well, but you are more sure that there isn't much in the way of documentation or comments in the code. And you've got a problem to solve. Here is where a debugger comes into play.

I've also heard the observation that you don't need a debugger because you go into a Bash, Python or Ruby shell and just start typing statements in the language. Again if you have a high-level idea of what's going on, that's great. However the hardest part here is getting the context correct. I need a `foo` object from class `Foo` and then need to hook the `bar` object from class `Bar` which means importing or requiring module `baz` into `foo` before I can call this method `fubar` that is of interest to me. With a debugger you work on code that purports to work and largely does. So for the most part, most of the necessary setup has been done for you. In a sense a ''good'' debugger is really not all that different than a shell, it's just that the context has already been set up for you. We'll see that in the Python debugger later.

=== Why model debuggers off of gdb? ===

Because it is
  * fairly complete --- suggests how to expand lesser debuggers (e.g. `pdb` and Ruby's `debug`). For example, consider signal handling.
  * well known --- learning one helps learn another. It helps ''programs'' learn too!
  * it's there --- why invent a new interface? Because is GPL can cull from gdb manual, with citation

=== Issues in Writing or Using a Debugger ===

  * Speed --- debuggers can slow down your program
  * Matching virtual reality to reality; which naturally leads to...
  * [[http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs|Heisenbugs]] (and speed contributes to this as well)
== GNU bash ==

=== Historical stuff ===

The sordid history of `trap DEBUG`. Originally like other signals, it came ''after'' a statement. But for debugging you need to stop before. Think "`rm -fr /`" and when you'd like to know about it. It took about 2 years after I posted a suggestion for the change to get into bash (and I never got an acknowledgment about this). Debug support was going way too slowly. About 4 years between those releases.

So I forked the bash code to add debug support and timestamped history. This code was incorporated into bash 3.0. Many thanks to Masatake YAMATO.

=== Practical example ===

 * [[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`''

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''

At this point we should have seen three paradigms of debugging that will come up over again in the other debuggers:
 * line tracing
 * invoking from the debugger at the outset
 * calling the debugger (somehow) from inside the program.

There's one more technique that's a little hard to use in bash but is more prevalent elsewhere
 * post-mortem debugging.

=== Work since the talk ===

In 2008, I did something in between a port and a rewrite of this to support `ksh` and `zsh` and colorized output via *pygments*. As before, changes were needed in the shells themselves to support more accurate location reporting and to be able to do more program introspection. Much to my delight, these enhancements were done quickly and with little involvement on my part. But this means you do need a recent release of these shells. The debugger code is maintained on `github`. See [[http://github.com/rocky/zshdb]] and [[http://github.com/rocky/kshdb]].

== GNU make ==

I have a short (13 minute) [[http://showmedo.com/videos/video?name=linuxBernsteinMakeDebug1&fromSeriesID=40|video]] which is really intended to be the first part of a more extended example.

=== Historical stuff ===

It's [[http://freshmeat.net/articles/view/889/#comment-31152|deja vu all over again]].

What needed to be done (same as in bash):
  * better position location reporting
  * keep target stack (like a call stack)
  * get tracing working first and then add a interactive command loop

=== Practical example ===

Method I use to solve a Makefile problem:
 * use normal make (until failure)
 * run again with `remake -x`
 * if above doesn't work narrow target and run with `remake -X` ''target''

Show:

 * make basic debugging: `make -d basic`
 * make tracing: `remake -x`
 * post-mortem debugging
 * 'step' and 'next'
 * showing dependencies and `write` command
 * Debugging a automake-generated Makefile.


=== Future ===

What's there now is good enough for me. If it's not for others, I encourage involvement. ;-)

The original version was somewhere between 3.80 and 3.81. In 2008, a fresh conversion was done for 3.81 Some of this could possibly get folded back into GNU Make but it may mean a ''regression'' in coding style. (Dan Fabulich once expressed interest in doing this.)

== Python ==

=== Historical stuff ===

There are two gdb-like debuggers. The stock python debugger, [[http://docs.python.org/lib/module-pdb.html|pdb]], and one that grew from that, called `pydb`. The name `pydb` is because at about the time `pdb` was developed Richard Wolff was working in parallel on a debugger to be embedded on [[http://www.gnu.org/software/ddd|ddd]]. He has since retired and with his blessing I've taken over the name and have been sort of maintaining the ddd embedding as well.

Stack frame display dilemma: do Python programmers draw their trees with the [[http://groups.google.com/group/comp.lang.python/browse_thread/thread/90cbcd03f37294a1/caa85f727c28353a|roots at the bottom]]?


=== Practical example ===

I have a short 15-minute [[http://showmedo.com/videos/video?name=pythonBernsteinPydbIntro&fromSeriesID=28|video]] showing off some non-pdb things.

Example: how `ipython` handles `help` --- signal handling (initially added by Matt Fleming as part of a Google 2006 Summer-of-code project. Possibly some of the thread debugging features.

=== Recent and Future work ===

Integration into [[http://ipython.scipy.org/moin/|ipython]] was recently done. Release 1.21 added a number of usability conveniences like better command completion, and [[http://docs.python.org/lib/module-pydoc.html|pydoc]] help.

Remote debugging. This is needed to hook into many IDEs like Eric, IDLE, winpdb (and therefore SPE), and Eclipse. The bad news though is that each IDE has defined it's own protocol for working remotely.

In late 2008, I started working on a complete rewrite. Some features planned:

  * remote debugging
  * much more modular (and more along the lines of `ruby-debug`)
  * distribution via egg package(s)

''Code is available at http://code.google.com/p/pydbgr/''

== Ruby ==

There are in fact two ruby debuggers. `debug` which comes with the base Ruby install and [[http://rubyforge.org/projects/ruby-debug/|ruby-debug]] by Kent Sibilev. Both are roughly gdb like. Kent's debugger is I think is coded the cleanest of any debugger I've seen (although it does have some warts). Each command is its own class. By way of comparison,
in the stock Python debugger a command module is used. Commands are methods in this (sub)class whose names start with the "do_". This is a pattern akin to one used in unit testing where tests start with "test_". But having a class per command is cooler.  It means that commands can have ''properties''. One property in `ruby-debug`  is whether you can run this command if the program has crashed. (The `help` command you can run, but the `step` command you can't).


=== Practical Example ===

`require 'debug'` trick? Stopping in a Rails unit test.

''Note: since this talk, `ruby-debug` has become the de-facto debugger that is used in Ruby, JRuby, Ruby/Rails, merb and other frameworks. The successor to the `require 'debug'` trick is now `require 'ruby-debug/debugger'` or some variation of that. See [[http://bashdb.sourceforge.net/ruby-debug.html#SEC18|Calling the debugger from inside your Ruby Program]] and [[http://bashdb.sourceforge.net/ruby-debug.html#SEC72|The Debugger Module]] for even more detail.''

=== Future Work ===

 * Aptana and Eclipse plugin (Done sometime in 2007 via ruby-debug-base.)
 * Documentation (largely done in 2007; see [[http://bashdb.sf.net/ruby-debug.html]] and [[http://bashdb.sf.net/ruby-debug/index.html]])
 * Regression tests. (Largely done in 2007.)
 * More closely like gdb (Much progress here too; caused some incompatible changes.)
 * Complete rewrite for Ruby 1.9? ''This code is avaliable at https://github.com/rocky/rb-trepanning''
----
CategoryDebugging

[Community Ubuntu Documentation] Update of "ReportingBugs" by penalvch

Help Ubuntu — 2012-05-18T05:56:03

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Community Ubuntu Documentation" for change notification.

The "ReportingBugs" page has been changed by penalvch:
http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=174&rev2=175

Comment:
Added note about how do not apport-collect unless O.R. or asked == Adding Apport Debug Information to an Existing Launchpad Bug ==

  
  == Adding Apport Debug Information to an Existing Launchpad Bug ==
  
- If you have already reported a bug directly via Launchpad, but want to add additional debugging information via ''Apport'' to the bug report, you can do this by running the command `apport-collect bug_number` via "Run Application" or terminal window.
+ If you have already reported a bug directly via Launchpad, but want to add additional debugging information via ''Apport'' to the bug report, you can do this by running the command `apport-collect bug_number` via "Run Application" or terminal window. If you are not the original reporter, please do not apport-collect to a bug report unless specifically asked of you by a developer or triager.  Running apport-collect when not asked creates spammy E-Mail traffic for those subscribed, clutters up the bug report with undesired attachments, and hinders the bug getting addressed quickly. Instead, please open a new report via ubuntu-bug.
  
  <<Anchor(translation)>>
  == Filing a translation bug ==

[Ubuntu Wiki] Update of "Bugs/Responses" by fabiomarconi

Ubuntu Wiki — 2012-05-17T10:33:20

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "Bugs/Responses" page has been changed by fabiomarconi:
http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=348&rev2=349

Determining whether a bug report is actually a support request can be quite challenging, but if you decide the bug is a support request you can convert it to such by clicking "Convert to a question" at the top of the bug's web page. This will mark the bug as "Invalid", create a new question in the answer tracker and link it to the bug. In the comment dialog that you receive, post a comment to inform the reporter about your action, and advise them to use the support tracker for any future problems.

- ||<tablestyle="background-color: #eee"> Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We understand the difficulties you are facing, but it is better to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. You can also find a valid support at http://askubuntu.com or posting your question in the support forum of your local Ubuntu's community. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs.||
+ ||<tablestyle="background-color: #eee"> Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We understand the difficulties you are facing, but it is better to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. You can also find a valid help posting your problem in the support forum of your [[http://loco.ubuntu.com/|local Ubuntu's community]] or asking at http://askubuntu.com. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs.||

It is also a good idea to change the source package beforehand if it's set incorrectly, so that the question will be associated with the correct package in the answer tracker, or edit the question afterwards and assign it to the correct package. If it doesn't pertain to a specific package, change it to "Ubuntu".

Re: New message for Bug/Responses#Release_has_reached_EOL

Andrea Corbellini — 2012-05-17T14:44:30

Hi,

On 17/05/12 11:57, Maarten Bezemer wrote:
 > and test or b) increase the verbosity of the steps to recreate
 > it so we can try again.

It looks good to me overall. There's just one thing that should be 
changed: I'd remove the "either" word and rephrase the sentence more or 
less in this way: "Please upgrade to the latest version and re-test. If 
the bug is still reproducible, increase the verbosity ..."

I would also include a link to an help page explaining how to perform 
the upgrade, i.e. https://help.ubuntu.com/community/PreciseUpgrades

Thanks,
Andrea C.

Re: New message for Bug/Responses#Release_has_reached_EOL

Maarten Bezemer — 2012-05-17T14:25:52

I agree with the requirement to update to a non-EOL version, I had been 
wondering about this earlier as well.
It was already in the original text and I did not want to modify it too much. 
How about this:



Thank you for reporting this bug to Ubuntu. RELEASE reached EOL on DATE.
See this document for currently supported Ubuntu releases: 
https://wiki.ubuntu.com/Releases 

I've tried recreating this bug with RELEASE and was unable to, given the 
information you've provided. Please upgrade, test again and if required 
increase the verbosity or update of the steps to reproduce it so we can try 
again.

Do feel free to report any other bugs you may find.



So it is (more) explicit that the OP should update to a non-EOL version before 
increasing the verbosity of the steps to reproduce.

Regards,
  Maarten

On Thursday 17 May 2012 23:19:52 George Patterson wrote:
given

Re: New message for Bug/Responses#Release_has_reached_EOL

George Patterson — 2012-05-17T13:19:52

I also agree with the idea except that it should be a requirement to
upgrade before re-testing otherwise those triaging will required to
run a now EOL install (even a VM) in order to confirm the steps
required to reproduce the bug and then do the same thing with the
current release to check if it has been fixed or no longer an issue.
The developers and other interested people will also need access to
the older version of the release.

This is assuming that I have read the proposed wording correctly.

Regards


George

On 17 May 2012 22:59, P.L. Francisco Javier <fco.plj-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: New message for Bug/Responses#Release_has_reached_EOL

P.L. Francisco Javier — 2012-05-17T12:59:28

It looks good for me, +1
On May 17, 2012 4:57 AM, "Maarten Bezemer" <maarten.bezemer-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
wrote: