Reporting
ContentsBRTableOfContents(2) |
Bug Reporting
The lifecycle of a bug report begins, unsurprisingly, with the preliminary report. How a bug is initially reported can have a huge effect on how it's handled and how quickly it gets fixed. Indeed, your bug may be closed as invalid if it doesn't at least include the basics!
If you do nothing else, at least remember: BR Always include /var/log/Xorg.0.log when reporting X bugs!
Troubleshooting
If you'd like to do some investigation beyond just reporting the bug, please see the page:
["X/Troubleshooting"]
Choosing a Good Title
Your title should communicate two things: The symptom you're seeing, and whatever is unique or unusual about your system. Otherwise, your bug may not get proper attention.
Examples:
BAD: |
Crashes randomly |
BAD: |
Crazy screen issues on boot |
BAD: |
Multiple problems with CD today |
BAD: |
Not able to login or start X after updating |
GOOD: |
Screen briefly corrupts during boot with -nv (NVidia 6100) |
GOOD: |
[fglrx] atieventsd crashed with SIGSEGV in XextAddDisplay() |
GOOD: |
[Hardy Alpha-3] Alt-CD (only) selected wrong driver (Matrox / BenQ FP91+) |
GOOD: |
[Gutsy] Periodic crashes w/ high CPU on Dell Latitude D505 (-intel 855GM) |
GOOD: |
[Dapper,Edgy] Wrong default refresh rates on 16:10 LCD panels |
GOOD: |
After update to -intel 2.0-0ubuntu3, X fails with 'Invalid mode' error |
Do's and Don't's
DON'T: |
Assume "they must already know about this" and skip reporting |
DO: |
Look for existing bug reports that exactly matches your problem, and if not file a new bug |
DON'T: |
Assume a "similar" bug is exactly what you're seeing |
DO: |
File a new bug, but mention the ID's of all bugs that sound similar. Someone can easily dupe them together later. |
DON'T: |
Add "me too" responses to an existing bug. Wastes everyone's time. |
DO: |
Add missing data (photos, logs) to add to an existing bug's "knowledge base" and to provide ample evidence that you indeed have the exact same issue. Or if you just wish to be notified, then Subscribe yourself to the bug. If in doubt, file a new bug, and reference the one you think might be a dupe, and let the experts decide. |
DON'T: |
Post bugs with only a brief description of the problem |
DO: |
Post steps to reproduce, relevant logs, config files, and data (see table below) For Xorg issues, ALWAYS ATTACH YOUR /var/log/Xorg.0.log |
DON'T: |
Assume "everyone" is seeing this same bug |
DO: |
90% of the time you are seeing something abnormal that others aren't. Consider what is unique about your system, any recent changes made, and so on. |
DON'T: |
Assume others will "just know" how the bug occurs |
DO: |
Itemize the exact steps that result in the issue. Can you reproduce it at will? |
DON'T: |
Fire and forget. Abandoned bugs rarely get fixed. |
DO: |
Follow up on your bug from time to time, even if it seems ignored. Report if the issue goes away or remains when new Ubuntu's come out. |
DON'T: |
Rant about the bug "driving away new users", threaten to "go back to windows or some other distro" unless the bug is fixed, or complain the bug is not getting enough attention. None of this helps get the bug fixed; it just makes people sad. |
DO: |
Follow the [http://www.ubuntu.com/community/conduct Ubuntu Code of Conduct] and keep discussions civil, even if you're frustrated. There are thousands of bugs and just a handful of people to work on them, and we can't fix everything overnight. If you're not getting fast enough response on a bug, then in addition to improving the report, you can try reporting it upstream, make mention of the bug directly to developers via mailing lists or irc, or even undertaking troubleshooting and analysis procedures yourself. Half the work of solving a bug is reproducing it, so if you have the bug, you're already halfway to a solution! |
What to Include in Bug Reports
Problem class: |
Things to Include: |
General X bug |
Description of problem |
Paste in output of lspci -nn | grep VGA |
|
Attach /var/log/Xorg.0.log |
|
Wrong resolutions, refresh rates, or monitor specs |
Resolution, rate, or other parameter expected |
Resolutions, rates, or other parameters actually obtained |
|
/etc/X11/xorg.conf |
|
/var/log/Xorg.0.log |
|
Paste in output of lspci -nn | grep VGA |
|
output of sudo ddcprobe |
|
output of xrandr |
|
Wrong font dpi or size |
Are you running GNOME, KDE, XFCE, or ...? |
Affected (and unaffected) applications |
|
/var/log/Xorg.0.log |
|
output of sudo ddcprobe |
|
Screenshot showing font differences |
|
X crash, lockup, freeze, exit, or doesn't start/shutdown |
Detailed description of problem |
Get a full backtrace (["X/Backtracing"]) |
|
List any versions you tried that did not have this issue |
|
Steps to reproduce |
|
How complete is the X failure? BR + Does ctrl+alt+f1 take you to a console? BR + Does ctrl+alt+backspace restart X? BR + Does mouse pointer still move? BR + Does the keyboard LED come on when hitting the CAPSLOCK key? + Can you ssh into the system from another computer? |
|
/var/log/Xorg.0.log |
|
/var/log/Xorg.0.log.old |
|
~/.xsession-errors |
|
Keyboard, touchpad, and mouse issues |
Description of the problem |
/var/log/Xorg.0.log |
|
output of xprop -root |
|
output of gconftool-2 -R /desktop/gnome/peripherals |
|
Screen display corruption |
Photo of the screen |
Description of the problem |
|
Does it also occur if DRI is disabled? |
|
/var/log/Xorg.0.log |
|
Bad video playback |
/etc/X11/xorg.conf |
/var/log/Xorg.0.log |
|
output of lspci -vvnn |
What Next?
Once your X bug is reported, it will be reviewed and triaged. The triager may mark it Incomplete and ask some questions or request additional information (if you're curious, or would like to participate in triaging, see ["X/Triaging"]).
If there is no reply from you within a month or two, the bug report may be closed as out of date / invalid (otherwise the tracker fills up with inactive bugs and gets confusing). You should feel free to reopen it once you have the needed information.
Once you've submitted your replies, a second round of triaging takes place to evaluate if the bug is a Duplicate of another bug or not an issue requiring a fix. If neither of those apply, the bug will be marked Triaged, which marks it ready for the research step.
In the research step, the bug may be assigned to a developer or forwarded to an upstream bug tracker. If it is forwarded upstream, you should also subscribe to that bug report so you can answer questions or run tests for those developers.
Once a fix is found either in Ubuntu or upstream, the Ubuntu developers will take the fix and package it for Ubuntu. They may ask for people to test and verify the fix before uploading it.