[Ubuntu Wiki] Update of "DebuggingUbiquity" by jibel

[Ubuntu Wiki]

Dear Wiki user,

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

The "DebuggingUbiquity" page has been changed by jibel:
http://wiki.ubuntu.com/DebuggingUbiquity?action=diff&rev1=48&rev2=49

  
  = Crash report handling =
  
- Many Ubiquity bugs arrive in the form of cut-and-pastes from its crash helper dialog. In simple cases, these are often enough to completely diagnose the bug and allow a developer to fix it, which is why the crash dialog exists. However, if the crash occurs in `install.py` (the component of Ubiquity that actually constructs and configures the newly-installed system), then in Dapper a combination of technical awkwardness and lack of developer time means that the traceback from the crash dialog often ends like this:
+ If you're running the development release, most Ubiquity bugs are reported by apport and the right log files are attached to the bug report. 
+ 
+ If the log files are not attached and want to analyze them locally logs are:
+ 
+  * During installation or from a Live Session:
+ {{{
+ /var/log/syslog
+ /var/log/partman
+ /var/log/installer
+ }}}
+ 
+  * After installation from running system installer log files are stored in the directory ```/var/log/installer/```
+ 
+ These are often enough to completely diagnose the bug and allow a developer to fix it. 
+ 
+ Sometimes, the developer will need more information than what is actually in the log files. In this case, if you know and can reproduce the defect you can run Ubiquity in '''debug mode'''. To run Ubiquity in debug mode, from a Live Session, open a terminal (On Unity Press <Super> to display the dash then enter '''terminal''' in the search field then <Enter>) and start Ubiquity with:
  
  {{{
- RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and /var/log/syslog
+ $ ubiquity -d
  }}}
  
- (Edgy installations will produce a more verbose traceback.)
- 
- This traceback is moderately useless on its own, and you must not mark bugs as duplicates on the basis that they both contain a traceback such as this. In Dapper, the real error is hidden in /var/log/installer/syslog, so if the reporter didn't attach that, ask for it, and for /var/log/syslog and /var/log/partman as well for good measure. Look for the traceback from the crash dialog in /var/log/installer/syslog and then trace up a little bit; the real error should be there, often in the form of a subprocess exiting non-zero.
- 
- Standard text for asking for log files in Dapper: {{{
- Could you please attach /var/log/installer/syslog, /var/log/syslog, and /var/log/partman to this bug, following the directions in http://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs? Thanks in advance.
- }}}
- 
- Standard text for asking for log files in >= Edgy: {{{
- Could you please attach /var/log/syslog and /var/log/partman to this bug, following the directions in http://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs? Thanks in advance.
- }}}
- 
- Don't ask for `/var/log/installer/syslog` if the version of ubiquity in the log is `1.1.12` or greater (Edgy or later). Those versions of ubiquity send all log messages apart from certain detailed partitioning log messages to `/var/log/syslog`, and `/var/log/installer/syslog` no longer exists.
  
  Please do not assign ubiquity bugs to anyone unless you're a ubiquity developer or you manage a ubiquity developer. Please don't reject ubiquity bugs unless you're a ubiquity developer. In general, please try to refrain from causing unnecessary extra bug mail noise for ubiquity developers or from taking items off their to-do lists without consulting them first.