<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.ubuntu.bugsquad">
    <title>gmane.linux.ubuntu.bugsquad</title>
    <link>http://blog.gmane.org/gmane.linux.ubuntu.bugsquad</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3756"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3755"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3750"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3749"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3748"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3744"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3743"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3742"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3741"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3740"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3735"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3732"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3731"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3730"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3729"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3727"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3724"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3723"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3722"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3720"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3756">
    <title>[Ubuntu Wiki] Update of "Chromium/Debugging" by uusijani</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3756</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=9&amp;amp;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&amp;gt;&amp;amp;1 | tee gdb-chromium.txt
+ $ chromium-browser --debug 2&amp;gt;&amp;amp;1 | tee gdb-chromium.txt
  (gdb) handle SIG33 pass nostop noprint
  (gdb) set pagination 0
  (gdb) run &amp;lt;arguments, if any&amp;gt;
  }}}
  
- do what you need to do to trigger the crash, then:
+ Do what you need to do to trigger the crash, then:
  
  {{{
  (gdb) backtrace
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -37, +27 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

  (gdb) quit
  }}}
  
+ If the backtrace shows lots of lines with question marks (such as "#5&amp;amp;nbsp;0x083949e0&amp;amp;nbsp;in&amp;amp;nbsp;??&amp;amp;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&amp;gt;&amp;amp;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
  

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-21T16:01:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3755">
    <title>[Ubuntu Wiki] Update of "Chromium/Debugging" by uusijani</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3755</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=10&amp;amp;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&amp;gt;&amp;amp;1 | tee gdb-chromium.txt

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-21T16:02:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3750">
    <title>[Ubuntu Wiki] Update of "Bugs/Responses" by veger</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3750</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=349&amp;amp;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):
  
- ||&amp;lt;tablestyle="background-color: #eee"&amp;gt;Thank you for reporting this bug to Ubuntu.  RELEASE reached EOL on DATE.&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;Please see this document for currently supported Ubuntu releases:&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;https://wiki.ubuntu.com/Releases &amp;lt;&amp;lt;BR&amp;gt;&amp;gt;&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;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.&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;Please feel free to report any other bugs you may find.||
+ ||&amp;lt;tablestyle="background-color: #eee"&amp;gt;Thank you for reporting this bug to Ubuntu. RELEASE reached EOL on DATE.&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases &amp;lt;&amp;lt;BR&amp;gt;&amp;gt;&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;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.&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;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]]

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-19T08:55:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3749">
    <title>apport: removing passwords from "modified.conffile..."</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3749</link>
    <description>&lt;pre&gt;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:
 &amp;gt; username LxxxxxxE
 &amp;gt; password xxxxxxx
maybe even in comments :(

Lars

&lt;/pre&gt;</description>
    <dc:creator>Lars Duesing</dc:creator>
    <dc:date>2012-05-19T07:17:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3748">
    <title>apport: removing passwords from "modified.conffile..."</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3748</link>
    <description>&lt;pre&gt;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:
 &amp;gt; username LxxxxxxE
 &amp;gt; password xxxxxxx
maybe even in comments :(

Lars

&lt;/pre&gt;</description>
    <dc:creator>Lars Duesing</dc:creator>
    <dc:date>2012-05-19T10:21:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3744">
    <title>[Ubuntu Wiki] Update of "DebuggerTalk_it" by fabiomarconi</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3744</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=1&amp;amp;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? ===
  

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-18T16:22:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3743">
    <title>Adding a package special log file to apport</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3743</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Lars Düsing</dc:creator>
    <dc:date>2012-05-18T17:39:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3742">
    <title>[Ubuntu Wiki] Update of "DebuggerTalk_it" by fabiomarconi</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3742</link>
    <description>&lt;pre&gt;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:
||&amp;lt;tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"&amp;gt;&amp;lt;&amp;lt;TableOfContents&amp;gt;&amp;gt;||

== 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&amp;amp;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&amp;amp;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

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-18T15:40:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3741">
    <title>[Community Ubuntu Documentation] Update of "ReportingBugs" by penalvch</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3741</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=174&amp;amp;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.
  
  &amp;lt;&amp;lt;Anchor(translation)&amp;gt;&amp;gt;
  == Filing a translation bug ==

&lt;/pre&gt;</description>
    <dc:creator>Help Ubuntu</dc:creator>
    <dc:date>2012-05-18T05:56:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3740">
    <title>[Ubuntu Wiki] Update of "Bugs/Responses" by fabiomarconi</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3740</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=348&amp;amp;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.
  
- ||&amp;lt;tablestyle="background-color: #eee"&amp;gt; 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.||
+ ||&amp;lt;tablestyle="background-color: #eee"&amp;gt; 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".
  

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-17T10:33:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3735">
    <title>New message for Bug/Responses#Release_has_reached_EOL</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3735</link>
    <description>&lt;pre&gt;Hi,

I would like to propose this text as the default message for Bug/Responses#Release_has_reached_EOL:

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 either a) upgrade and test or b) 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.


I removed some 'please' words from the text, as I often do not include"I've tried recreating this bug with RELEASE and was unable to, given the information you've provided." because the issue is really too old or impossible to retry.
When removing that part, there are 3 sentences starting with 'Please' directly under each other in the current default message.

Any opinions about this proposed change? Is it too commanding/demanding without the 'Please' words?

Regards,
  Maarten

&lt;/pre&gt;</description>
    <dc:creator>Maarten Bezemer</dc:creator>
    <dc:date>2012-05-17T09:57:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3732">
    <title>Core vs. Non-Core definitions</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3732</link>
    <description>&lt;pre&gt;Hiya, all.

This came up (during UDS) in a discussion I had with micahg on IRC, and
came up again today in #ubuntu-bugs with roadmr.  (NOTE: These are the
users' IRC nicks, I do not have their names readily available)

The definition of a bug's importance includes the difference between core
and non-core on this page here: https://wiki.ubuntu.com/Bugs/Importance


There is currently no clear definition of what core or non-core means.  At
every time I have run into a bug that needs its importance set, I've
avoided identifying whether a bug is related to a core or non-core program
(except for Universe and Multiverse package bugs), simply because there is
no clear-cut definition of what is or is not core.

This lack of a definition can sometimes make a recommendation for "medium"
actually end up as "low", and vice versa, based on core-vs-noncore.  This
makes determining importance that much more difficult.

Since this is a critical part of determining a bug's importance, we need
to, in my opinion, do one of the following::
(a) clearly define what applications specifically are or are not core, and
update with each release, or
(b) define what constitutes a core or non-core application/program, or
(c) rewrite the criterion (and therefore the guide) to remove the
difference of core vs. non-core and redefine the bug importance criterion
accordingly.

micahg was in agreement with me that this needs to be defined, so I thought
I would bring this onto the mailing list for discussion and potentially a
final decision be made on this.


So, thoughts?  Opinions?

------
Thomas
LP: trekcaptainusa-tw
BugSquad Member
Ubuntu Member
&lt;/pre&gt;</description>
    <dc:creator>Thomas Ward</dc:creator>
    <dc:date>2012-05-16T01:21:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3731">
    <title>[Ubuntu Wiki] Update of "LibreOfficeBugWrangling_it" by fabiomarconi</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3731</link>
    <description>&lt;pre&gt;Dear Wiki user,

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

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

Comment:
Italian translation

   * Per cortesia non riportare più di un bug per ogni segnalazione.
   * Per cortesia evitare commenti sul tempo necessario alla riparazione, specialmente se non si sono seguiti i fondamentali passi di debugging in seguito descritti. Siate consapevoli che noi tutti vorremmo vedere i bug riparati immediatamente, ma purtroppo gli ostacoli maggiori si incontrano nella riproducibilità e chiarezza della segnalazione.
  
- = Debugging Procedure =
- == Document Issues ==
+ = Procedure per il debugging =
+ == Problemi con il documento ==
  
- === Bug importing a non-MS Office document ===
-   * If you are reporting about importing a non-MS Office document, please attach the document to the bug report before opening in LibreOffice or in any other program. As well, please post a screenshot of how it looks in LibreOffice with a specific description about how it should look.
+ === Anomalia importando un documento non-MS Office ===
+   * Se si intende riportare un bug che riguarda un documento non-MS Office, siete pregati di allegare il file alla segnalazione prima di averlo aperto con LibreOffice o qualsiasi altro programma. Si prega inoltre di allegare uno screenshot di come questo file appare in libreOffice ed una specifica descrizione di come invece dovrebbe apparire.
  
- === Bug exporting to MS Office ===
-   * If you are reporting about how a document looks different exporting to MS Office, please attach the document to the bug report immediately after saving via LibreOffice, but before opening in MS Office. As well, please post a screenshot of how it looks in LibreOffice and then how it shows in MS Office.
+ === Anomalie esportando in MS Office ===
+   * Se si sta segnalando un'anomalia inerente un documento che viene visualizzato diverso esportandolo in MS Office, vi preghiamo di allegarlo alla segnalazione immediatamente dopo l'esportazione via LibreOffice. Inoltre allgare uno screenshot di come il documento appare in LibreOffice ed uno di come viene visualizzato inp MS Office.
  
- === Bug Importing from MS Office ===
-   * If you are reporting about how a document looks importing from MS Office, please save the file in MS Office, then before opening in any other program, attach the document to the bug report. As well, please post a screenshot of how it looks in LibreOffice and then how it shows in MS Office.
+ === Anomalie importando da MS Office ===
+   * Se si sta segnalando un'anomalia riguardo a come un documento viene visualizzato se importato da MS Office, siete pregati di salvarlo in formato MS Office, quindi prima di aprirlo con qualsiasi altro programma, allegarlo alla segnalazione. Inoltre allegare uno screenshot di come il documento appare in LibreOffice e di come appare in MS Office.
  
- === Bug Exporting to Adobe PDF ===
-   * If you are reporting about how a document looks exporting to Adobe Reader, please attach the file to the bug report before and after exporting to PDF. As well, provide screenshots of how it looks in LibreOffice and Adobe Reader.
+ === Anomalie esportando in Adobe PDF ===
+   * Se si sta segnalando un anomalia riguardo a come un documento viene visualizzato se esportato in formato Adobe Reader, siete pregati di allegare il file alla segnalazione prima e dopo l'esportazione in formato PDF. Inoltre allegare uno screenshot di come viene visualizzato sia in LibreOffice che in Adobe Reader.
  
- === Bug Importing PDF ===
-   * If you are reporting about how a PDF document looks importing into Draw, please attach the file to the bug report before importing into Draw. As well, provide screenshots of how it looks in LibreOffice and Adobe Reader.
+ === Anomalie importando PDF ===
+   * Se si sta segnalando un'anomalia riguardo a come un documento PDF viene visualizzato iportandolo in Draw, siete pregati di allegare il file alla segnalazione prima di averlo importato in Draw. Inoltre, allegare uno screenshot di come il documento è visualizzato sia in LibreOffice che in Adobe Reader.
  
- == Printing ==
-  * For issues printing from LibreOffice please report this against cups first via the Terminal: &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; {{{ubuntu-bug cups}}} &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; It could end up being an issue with LibreOffice, but it's best to start with cups in order to rule it out. As well, please follow all steps noted in https://wiki.ubuntu.com/DebuggingPrintingProblems .
+ == Stampa ==
+  * Per problemi durante la stampa con LibreOffice, vi preghiamo di aprire la segnalazione dapprima contro cups via terminale: &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; {{{ubuntu-bug cups}}} &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; Potrebbe anche essere un problema in LibreOffice, ma è meglio iniziare da cups in modo da poterlo così escludere. Inoltre vi preghiamo di seguire le istruzioni contenute in [[https://wiki.ubuntu.com/DebuggingPrintingProblems_it|DebuggingPrintingProblems_it]] .
  
- == Crashes ==
+ == Crash ==
- === LibreOffice Crashes but System Still Functional ===
-  * For instances when only LibreOffice crashes but you can still use the OS without hard rebooting, please report this via via Apport and ensure you have all the LibreOffice debug symbols installed (libreoffice-dbg, uno-libs3-dbg, and ure-dbg). For more on this please see https://wiki.ubuntu.com/Apport . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash.
-  * In the rare instance that after you followed the above, apport did not kick in, please provide a backtrace, valgrind, and strace following https://wiki.ubuntu.com/DebuggingProgramCrash .
+ === LibreOffice crasha ma il sistema rimane funzionante ===
+  * Nei casi in cui solamente LibreOffice crasha ed il sistema rimane comunque funzionante, vi preghiamo di segnalare il bug utilizzando [[https://wiki.ubuntu.com/Apport_it|Apport]] assicurandosi di avere preventivamente installato i simboli di debug (libreoffice-dbg, uno-libs3-dbg, and ure-dbg). Inoltre, se il bug si verifica durante l'apertura di un particolare documento o la sua lavorazione, vi preghiamo di allegarlo alla segnalazione fornendo anche una dettagliata descrizione, click per click, su come riprodurre il crash.
+  * Nei rari casi che anche seguendo la procedura sopraelencata Apport non si avvii, vi preghiamo di allegare alla segnalazione un backtrace, valgrind e strace seguendo le istruzioni in [[https://wiki.ubuntu.com/DebuggingProgramCrash_it|DebuggingProgramCrash_it]].
  
  === The Whole System Hangs or Boots to the Login Screen ===
   * For instances when your using LibreOffice and either the system hangs requiring a hard reset or your booted to the login screen, this is a bug in either xorg or the kernel. Please follow https://help.ubuntu.com/community/DebuggingSystemCrash . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash.

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-15T09:24:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3730">
    <title>[Ubuntu Wiki] Update of "LibreOfficeBugWrangling_it" by fabiomarconi</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3730</link>
    <description>&lt;pre&gt;Dear Wiki user,

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

The "LibreOfficeBugWrangling_it" page has been changed by fabiomarconi:
http://wiki.ubuntu.com/LibreOfficeBugWrangling_it?action=diff&amp;amp;rev1=2&amp;amp;rev2=3

Comment:
Italian translation done

   * Nei casi in cui solamente LibreOffice crasha ed il sistema rimane comunque funzionante, vi preghiamo di segnalare il bug utilizzando [[https://wiki.ubuntu.com/Apport_it|Apport]] assicurandosi di avere preventivamente installato i simboli di debug (libreoffice-dbg, uno-libs3-dbg, and ure-dbg). Inoltre, se il bug si verifica durante l'apertura di un particolare documento o la sua lavorazione, vi preghiamo di allegarlo alla segnalazione fornendo anche una dettagliata descrizione, click per click, su come riprodurre il crash.
   * Nei rari casi che anche seguendo la procedura sopraelencata Apport non si avvii, vi preghiamo di allegare alla segnalazione un backtrace, valgrind e strace seguendo le istruzioni in [[https://wiki.ubuntu.com/DebuggingProgramCrash_it|DebuggingProgramCrash_it]].
  
- === The Whole System Hangs or Boots to the Login Screen ===
-  * For instances when your using LibreOffice and either the system hangs requiring a hard reset or your booted to the login screen, this is a bug in either xorg or the kernel. Please follow https://help.ubuntu.com/community/DebuggingSystemCrash . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash.
+ === Il sistema si blocca o compare la schermata di login ===
+  * Nel caso in cui, utilizzando LibreOffice, il sistema si blocca o si riavvia la sessione si è di fronte ad un bug relativo a Xorg o al kernel. Si prega di consultare https://help.ubuntu.com/community/DebuggingSystemCrash . Inoltre, se ciò accade durante l'apertura o la lavorazione di un particolare documento, vi preghiamo di allegarlo alla segnalazione fornendo anche una dettagliata descrizione, click per click, su come riprodurre il crash.
  
- == Regressions ==
+ == Regressioni ==
-  * For regressions, it is helpful to perform a binary bisect ("bibisect") to narrow down which commit specifically caused the problem. For instructions please see http://sweetshark.livejournal.com/7683.html .
+  * Per le regressioni, è di valido aiuto eseguire un binary bisect ("bibisect") per isolare la specifica commit che ha introdotto il bug. Per istruzioni vedere http://sweetshark.livejournal.com/7683.html .
  
- == Wishlists ==
-  * For Wishlist reports, many of these are requests to implement a feature in LibreOffice found in MS Office. A broad but good rule of thumb is if you want LibreOffice to do something that MS Office does (MS Office compatibility expectation), please document how specifically MS Office does it, then how LibreOffice does not or does not do well that which you desire. Please keep in mind, pocket cases exist where LibreOffice intentionally does not do what MS Office does (ex. leap year implementation https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/456100).
+ == Implementazioni ==
+  * Usare le segnalazioni per l'implementazione in Libreoffice di una caratteristica presente in MS Office se si vuole ottenenere la stessa funzionalità (aspettativa di compatibilità con MS Office). Vi preghiamo di documentare specificamente come viene svolta da MS Office e quindi come LibreOfficenon la svolge o la svolge differentemente. Ricordiamo che in alcuni casi Libreoffice, intenzionalmente, non si comporta come MS Office (es. implementare il salto dell'anno https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/456100).
  
- = Triaging LibreOffice Bugs =
+ = Triaging dei bug in LibreOffice =
  
- == Writer and Calc ==
+ == Writer e Calc ==
-  * For bugs in Writer, it is helpful to check to see if the problem exists in AbiWord. For bugs in Calc, it is helpful to check to see if the problem exists in Gnumeric. Sometimes, AbiWord and Gnumeric give the bug reporter a usable workaround to the problem (and vice versa). If a workaround is found, feel free to document it in the report. As well, while not quite apples and oranges code wise, it gives LibreOffice developers code to base a patch on.
+  * Per i bug in Writer, è buona norma verificare su il bug si presenta anche in Abiword, mentre per i bug in Calc verificare se presenti anche in Gnumeric. Talvolta, AbiWord e Gnumeric forniscono un valida soluzione temporanea al problema (e vice versa). Se si trova una soluzione temporanea, si prega di documentarla nella segnalazione. Potrebbe anche fornire agli sviluppatori LibreOffice una base di codice per sviluppare una patch.
  
- == Wishlist Reports ==
-  * For Wishlist reports, they most likely should be marked Won't Fix Wishlist. This is due to how Ubuntu diverts very little from the LibreOffice upstream source release, and upstream's rapid maintenance cadence. &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; A Won't Fix Wishlist stock reply:
+ == Segnalazioni Wishlist ==
+  * Per le segnalazioni Wishlist, esse saranno marcate Won't Fix Wishlist. Ciò è dovuto al fatto che la versione  Ubuntu differisce molto poco dal rilascio upstream ed upstream ha una cadenza di manutenzione rapida. &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; A Won't Fix Wishlist stock reply:
  
  ||&amp;lt;tablestyle="background-color: #eee"&amp;gt;Thank you for reporting this and helping making Ubuntu better. Regarding this report:&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;- This is a clearcut upstream issue. Your welcome to send this to the developers of the software by following the instructions at http://wiki.documentfoundation.org/BugReport . If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status.&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;- Marking LibreOffice Packaging and libreoffice (Ubuntu) =&amp;gt; Won't Fix Wishlist. This does not mean the issue will not be cared about, but if it is cared about (even by Ubuntu/Canonical contributors), it is done upstream at LibreOffice.||
  
- == How to Forward Bugs Upstream ==
+ == Come avanzare i bug Upstream ==
-  * Once marked Triaged, a report may be filed upstream using the [[https://www.libreoffice.org/get-help/bug/|LibreOffice Bug Submission Assistant]] &amp;lt;&amp;lt;FootNote(Or in the old fashioned way at https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice)&amp;gt;&amp;gt;.
+  * Una volta marcata Triaged, una segnalazione potrà essere inviata upstream utilizzando il [[https://www.libreoffice.org/get-help/bug/|LibreOffice Bug Submission Assistant]] &amp;lt;&amp;lt;FootNote(Or in the old fashioned way at https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice)&amp;gt;&amp;gt;.
  
-   * Once a remote bug watch has been added to a bug report, it is helpful to append [Upstream] to the beginning of the bug title. This helps in searching for bugs reports by title. Please do not append this unless a remote bug watch has been added to the report as this creates confusion on which bugs have been reported upstream and which have not.
+   * Dopo che un remote bug watch è stato aggiunto alla segnalazione, è utile farne precedere il titolo da [Upstream]. Ciò aiuterà nella ricerca delle segnalazioni in funzione del titolo. Per cortesia non aggiungere [Upstream] fino a quando un remote bug watch è stato aggiunto alla segnalazione onde evitare di creare confusione tra i bug segnalati upstream e quelli no.
  
  ----
  CategoryBugSquad

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-15T11:04:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3729">
    <title>[Ubuntu Wiki] Update of "DebuggerTalk" by rocky-bernstein</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3729</link>
    <description>&lt;pre&gt;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&amp;amp;rev1=28&amp;amp;rev2=29

Comment:
Revice for more recent activity

  
  In the practical arena, I could show how to use to debug an GNU automake project. There could be a theoretical area such as how to structure writing a debugger. (The ones for Ruby and Python are interesting here.)
  
- In the past people have asked me in the past, ''"what's the fascination with the debugger thing?"'' Or another favorite remark from a contractor is "''I never use a debugger, I just '''write''' code''". 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 the past people have asked me in the past, ''"what's the fascination with the debugger thing?"'' Or another favorite remark from a contractor is "''I never use a debugger, I just '''write''' code''". 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. W
 e'll see that in the Python debugger later.
  
- === Why gdb? ===
+ === Why model debuggers off of gdb? ===
  
- Because it is 
+ 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
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -29, +29 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

  
  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. 
+ 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 ===
  
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -37, +37 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

   * 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.
+ 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: 
+ 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.
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -49, +49 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

  
  === Work since the talk ===
  
- In 2008, I did something in between a port and a rewrite of this to support `ksh` and `zsh`. 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]].
+ 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&amp;amp;fromSeriesID=40|video]] which is really intended to be the first part of a more extended example. 
+ I have a short (13 minute) [[http://showmedo.com/videos/video?name=linuxBernsteinMakeDebug1&amp;amp;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]]. Lessons learned in forking a project 
+ 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
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -71, +71 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

   * run again with `remake -x`
   * if above doesn't work narrow target and run with `remake -X` ''target''
  
- Show: 
+ Show:
  
   * make basic debugging: `make -d basic`
   * make tracing: `remake -x`
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -79, +79 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

   * 'step' and 'next'
   * showing dependencies and `write` command
   * Debugging a automake-generated Makefile.
-  
+ 
  
  === Future ===
  
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -91, +91 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

  
  === 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. 
+ 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]]? 
+ 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&amp;amp;fromSeriesID=28|video]] showing off some non-pdb things. 
+ I have a short 15-minute [[http://showmedo.com/videos/video?name=pythonBernsteinPydbIntro&amp;amp;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.
  
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -106, +106 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

  
  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. 
+ 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:
  
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -114, +114 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

    * 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).
+ 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. 
+ `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.''
  
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -132, +134 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;

   * 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?
+  * Complete rewrite for Ruby 1.9? ''This code is avaliable at https://github.com/rocky/rb-trepanning''
  ----
  CategoryDebugging
  

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-15T08:45:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3727">
    <title>fixing bugs</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3727</link>
    <description>&lt;pre&gt;Hi all, I would like to make Ubuntu better fixing bugs. Could you give
me some pages where I can find new bugs (quite easy, if possible), please?

Also I would like to know if http://harvest.ubuntu.com/ is active and up
to date.

Thanks in advance

&lt;/pre&gt;</description>
    <dc:creator>Alessandro Losavio</dc:creator>
    <dc:date>2012-05-13T17:53:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3724">
    <title>[Ubuntu Wiki] Update of "DebuggingScreenLocking/HowScreenLockingWorks" by aquaherd</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3724</link>
    <description>&lt;pre&gt;Dear Wiki user,

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

The "DebuggingScreenLocking/HowScreenLockingWorks" page has been changed by aquaherd:
http://wiki.ubuntu.com/DebuggingScreenLocking/HowScreenLockingWorks?action=diff&amp;amp;rev1=12&amp;amp;rev2=13

Comment:
Details for xubuntu added

  
  (This section needs to be completed.)
  
- = XFCE (Xubuntu, Mythbuntu) =
+ = Xfce 4 (Xubuntu, Mythbuntu) =
  
- (This section needs to be completed.)
+ Screen locking is handled by the `xflock4` script that is a small command dispatcher to the following commands:
+  
+  * `xscreensaver-command` when found `xscreensaver` running
+  * `gnome-screensaver-command` when found `gnome-screensaver` running
+  * `slock` when available
+  * `xlock` when the above three options failed
+ 
+ First found from the above will be called with the appropriate parameters.
  
  ----
  CategoryBugSquad

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-13T09:21:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3723">
    <title>(unknown)</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3723</link>
    <description>&lt;pre&gt;Hi

i ve got a problem with ubuntu recently

i can't open the ubutu library and i've got this ;message instead

 

E:Encountered a section with no Package: header, E:Problem with MergeList /var/lib/apt/lists/archive.canonical.com_dists_precise_partner_binary-i386_Packages, E:The package lists or status file could not be parsed or opened.

 

can someone explain how to do?

thank you

 

Maurice EXPOSITO
&lt;/pre&gt;</description>
    <dc:creator>Maurice EXPOSITO</dc:creator>
    <dc:date>2012-05-12T15:13:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3722">
    <title>[Bug #975197] Validity against 'linux'</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3722</link>
    <description>&lt;pre&gt;https://bugs.launchpad.net/ubuntu/+source/linux/+bug/975197

This bug was referenced on IRC in #ubuntu-bugs on freenode.

When I looked at this, it was marked 'confirmed' against the 'linux'
package.

I am not certain it is valid against the 'linux' package, as the package
does not necessarily have anything to directly deal with mounting at boot
time.

Should this be marked as 'Opinion' and then filed as a bug against whatever
controls samba mounting?

------
Thomas
LP ID: trekcaptainusa-tw
Ubuntu Member
BugSquad Member
&lt;/pre&gt;</description>
    <dc:creator>Thomas Ward</dc:creator>
    <dc:date>2012-05-13T16:11:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3720">
    <title>Just joined: Advice before I start making changes?‏</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3720</link>
    <description>&lt;pre&gt;
Hello all,

I would like to help out working with Ubuntu bugs, and I just joined.  Is there a meeting time or other event in the near future for me to sync up with someone on IRC or other live chat to guide me through working on simple tasks for the team?

As some background, I am a Masters student with specialization in systems and machine intelligence (a.k.a. "AI"). Despite my "specialization", I try to keep my skills up in low-level programming (assembly, C not plus plus, Java, electronics) like I am now to not cripple my job seeking potential.
I have been working with Linux on my home, workstation, and small fileservers since Debian "Sarge" / Ubuntu Dapper. I want to help with Ubuntu development to learn and pad my CV. Note my only experience with Linux is as a USER - my closest to development I've gotten so far is compiling my own kernel for video drivers a few years back. However, I have co-op work experience in both "sides" of bugs - 4+8 months as a tester creating test cases and filing bugs, 4 months as a developer fixing bugs (from other testers). Although I have no triage experience (aside from sending a bug back to triage if it doesn't apply to me), I would like to get involved in triage so I can get a good grasp of how everything "fits together" in the codebase.

As noted, I don't want to jump in and make a mess of things, so I would like to have some guidance to get started on some of the easy tasks. Note my location is Canada, EST, but my schedule is extremely flexible at the moment. If a meeting can't be arranged, another idea is assign me some task and I'll report back when I've completed it or need help to complete it.

Thank you,
Patrick       -- 
Ubuntu-bugsquad mailing list
Ubuntu-bugsquad-nLRlyDuq1AZFpShjVBNYrg&amp;lt; at &amp;gt;public.gmane.org
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
&lt;/pre&gt;</description>
    <dc:creator>Patrick Santos</dc:creator>
    <dc:date>2012-05-10T20:17:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3716">
    <title>[Ubuntu Wiki] Update of "LibreOfficeBugWrangling_it" by fabiomarconi</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.bugsquad/3716</link>
    <description>&lt;pre&gt;Dear Wiki user,

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

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

Comment:
Italian translation

New page:
&amp;lt;&amp;lt;Include(Debugging/Header)&amp;gt;&amp;gt;
||&amp;lt;tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; background-image: url('https://librarian.launchpad.net/1812570/bugsquad.png'); background-repeat: no-repeat; background-position:  98% 0.5ex; margin: 0 0 1em 1em; padding: 0.5em;"&amp;gt;'''Contents'''&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;&amp;lt;&amp;lt;TableOfContents&amp;gt;&amp;gt;||

= Come fare una segnalazione =

 * Vi preghiamo di non segnalare bug inerenti LibreOffice senza avere prima letto questa pagina ed avere eseguito le necessarie azioni riportate in seguito. La mancata inosservanza causerà ritardi nell'indirizzamento della vostra segnalazione.
 * Vi preghiamo di segnalare tutti i vostri bug in LibreOffice eseguendo nel terminale: &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; {{{ubuntu-bug &amp;lt;PACCHETTO&amp;gt;}}} &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; dove &amp;lt;PACCHETTO&amp;gt; è lo specifico pacchetto nel quale è stato rinvenuto il problema. Per esempio, se si ha un problema importando un documento con Writer: &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; {{{ubuntu-bug libreoffice-writer}}}
 * Un semplice modello di segnalazione di bug: &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; 
||&amp;lt;tablestyle="background-color: #eee"&amp;gt; 1) lsb_release -rd &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; 2) apt-cache policy libreoffice-writer &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; 3) What is expected to happen in Writer is (cosa dovrebbe succedere) &amp;lt;PRECISE ISTRUZIONI PASSO-PASSO&amp;gt;. &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; 4) What happened instead is...(cosa invece accade...) &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; WORKAROUND: Perform the following steps:...||
 * Per cortesia non riportare più di un bug per ogni segnalazione.
 * Per cortesia evitare commenti sul tempo necessario alla riparazione, specialmente se non si sono seguiti i fondamentali passi di debugging in seguito descritti. Siate consapevoli che noi tutti vorremmo vedere i bug riparati immediatamente, ma purtroppo gli ostacoli maggiori si incontrano nella riproducibilità e chiarezza della segnalazione.

= Debugging Procedure =
== Document Issues ==

=== Bug importing a non-MS Office document ===
  * If you are reporting about importing a non-MS Office document, please attach the document to the bug report before opening in LibreOffice or in any other program. As well, please post a screenshot of how it looks in LibreOffice with a specific description about how it should look.

=== Bug exporting to MS Office ===
  * If you are reporting about how a document looks different exporting to MS Office, please attach the document to the bug report immediately after saving via LibreOffice, but before opening in MS Office. As well, please post a screenshot of how it looks in LibreOffice and then how it shows in MS Office.

=== Bug Importing from MS Office ===
  * If you are reporting about how a document looks importing from MS Office, please save the file in MS Office, then before opening in any other program, attach the document to the bug report. As well, please post a screenshot of how it looks in LibreOffice and then how it shows in MS Office.

=== Bug Exporting to Adobe PDF ===
  * If you are reporting about how a document looks exporting to Adobe Reader, please attach the file to the bug report before and after exporting to PDF. As well, provide screenshots of how it looks in LibreOffice and Adobe Reader.

=== Bug Importing PDF ===
  * If you are reporting about how a PDF document looks importing into Draw, please attach the file to the bug report before importing into Draw. As well, provide screenshots of how it looks in LibreOffice and Adobe Reader.

== Printing ==
 * For issues printing from LibreOffice please report this against cups first via the Terminal: &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; {{{ubuntu-bug cups}}} &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; It could end up being an issue with LibreOffice, but it's best to start with cups in order to rule it out. As well, please follow all steps noted in https://wiki.ubuntu.com/DebuggingPrintingProblems .

== Crashes ==
=== LibreOffice Crashes but System Still Functional ===
 * For instances when only LibreOffice crashes but you can still use the OS without hard rebooting, please report this via via Apport and ensure you have all the LibreOffice debug symbols installed (libreoffice-dbg, uno-libs3-dbg, and ure-dbg). For more on this please see https://wiki.ubuntu.com/Apport . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash.
 * In the rare instance that after you followed the above, apport did not kick in, please provide a backtrace, valgrind, and strace following https://wiki.ubuntu.com/DebuggingProgramCrash .

=== The Whole System Hangs or Boots to the Login Screen ===
 * For instances when your using LibreOffice and either the system hangs requiring a hard reset or your booted to the login screen, this is a bug in either xorg or the kernel. Please follow https://help.ubuntu.com/community/DebuggingSystemCrash . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash.

== Regressions ==
 * For regressions, it is helpful to perform a binary bisect ("bibisect") to narrow down which commit specifically caused the problem. For instructions please see http://sweetshark.livejournal.com/7683.html .

== Wishlists ==
 * For Wishlist reports, many of these are requests to implement a feature in LibreOffice found in MS Office. A broad but good rule of thumb is if you want LibreOffice to do something that MS Office does (MS Office compatibility expectation), please document how specifically MS Office does it, then how LibreOffice does not or does not do well that which you desire. Please keep in mind, pocket cases exist where LibreOffice intentionally does not do what MS Office does (ex. leap year implementation https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/456100).

= Triaging LibreOffice Bugs =

== Writer and Calc ==
 * For bugs in Writer, it is helpful to check to see if the problem exists in AbiWord. For bugs in Calc, it is helpful to check to see if the problem exists in Gnumeric. Sometimes, AbiWord and Gnumeric give the bug reporter a usable workaround to the problem (and vice versa). If a workaround is found, feel free to document it in the report. As well, while not quite apples and oranges code wise, it gives LibreOffice developers code to base a patch on.

== Wishlist Reports ==
 * For Wishlist reports, they most likely should be marked Won't Fix Wishlist. This is due to how Ubuntu diverts very little from the LibreOffice upstream source release, and upstream's rapid maintenance cadence. &amp;lt;&amp;lt;BR&amp;gt;&amp;gt; A Won't Fix Wishlist stock reply:

||&amp;lt;tablestyle="background-color: #eee"&amp;gt;Thank you for reporting this and helping making Ubuntu better. Regarding this report:&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;- This is a clearcut upstream issue. Your welcome to send this to the developers of the software by following the instructions at http://wiki.documentfoundation.org/BugReport . If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status.&amp;lt;&amp;lt;BR&amp;gt;&amp;gt;- Marking LibreOffice Packaging and libreoffice (Ubuntu) =&amp;gt; Won't Fix Wishlist. This does not mean the issue will not be cared about, but if it is cared about (even by Ubuntu/Canonical contributors), it is done upstream at LibreOffice.||

== How to Forward Bugs Upstream ==
 * Once marked Triaged, a report may be filed upstream using the [[https://www.libreoffice.org/get-help/bug/|LibreOffice Bug Submission Assistant]] &amp;lt;&amp;lt;FootNote(Or in the old fashioned way at https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice)&amp;gt;&amp;gt;.

  * Once a remote bug watch has been added to a bug report, it is helpful to append [Upstream] to the beginning of the bug title. This helps in searching for bugs reports by title. Please do not append this unless a remote bug watch has been added to the report as this creates confusion on which bugs have been reported upstream and which have not.

----
CategoryBugSquad
CategoryDebugging

&lt;/pre&gt;</description>
    <dc:creator>Ubuntu Wiki</dc:creator>
    <dc:date>2012-05-09T19:52:28</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.ubuntu.bugsquad">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.ubuntu.bugsquad</link>
  </textinput>
</rdf:RDF>

