Ubuntu Wiki

The official way to report defects against Ubuntu's Xorg is:

This lets you attach a lot of common debugging data. But it's not enough!!

Include a detailed description of the problem.

• A good description

• Step-by-step directions for how you reproduced it

• When was your system last working properly?

• photo of the screen

If your report doesn't have a good description, and there's no relevant errors in your log files, your bug will be closed as not actionable and you'll be referred here. Don't be upset - the always-busy X package maintainers get a LOT of bug reports and need to focus their limited time on well-described problems. Instead, read this page and try again, making your new bug report a well-described problem.

Keep in mind that the Launchpad bug tracker is a development tool, not for technical support - Ubuntu does have volunteer and paid technical support staff but none of them frequent the bug tracker. In particular, if you're using a released version of Ubuntu, you probably should start with the technical support channels.

Be Specific, Especially in the Title

X symptoms are often generic things like "booted with black screen", or "crashed", or "sluggish performance". Two distinct bugs can have the same symptoms but different causes. The more specific you are, the less likely some other confused reporter will spam your bug report with irrelevant messages.

Focus on One Issue

The rule is "One Defect, One Person Per Report". Don't almalgamate every issue you find after an update. Otherwise, the maintainer will just pick one at random and all your other issues will be ignored. Instead, do a separate report for each distinct issue.

It's cheap and easy for the maintainers to dupe your reports together if it can be proven they all have the same cause.

Banish 'Random' from Your Vocabulary

Many times it's unclear what is causing the X problem. But words like "randomly", "unexpectedly", "intermittently", etc. just gives the impression you haven't given your problem much thought or study.

If you simply can't characterize it, consider holding off on filing a bug report until you have a better understanding and can describe it more specifically.

Use !!Science!!

Treat writing your bug report like you would writing a chemistry lab report.

Write down the procedure for producing the issue. Specify expected results and actual results. Identify variables - what has changed recently about your system, what makes your system unique, what you're doing when the problem occurs. Take lots of measurements - how many times a day did it happen? Does it happen only when you're on the computer, or also (only?) when idle? Make a hypothesis and attempt to disprove it. Repeat the experiment and see if you get the same results.

Keep Calm and Carry On

Bugs can be frustrating, and X bugs particularly so, especially when it feels like no one is paying attention to your bug reports.

But don't give in to the dark side. Losing your cool and ranting can be quite unproductive, and just makes you look bad for all posterity. Instead keep discussions civil, and follow the Ubuntu Code of Conduct. There are millions of Ubuntu users, and thousands of bug reports and just a handful of people to work on fixes -- it simply is not humanly possible to give a personal reply to every bug report.

Be Prepared to Roll Up Your Sleeves

Bug reports are a way to engage with the developers. It's not a support request, it's a way to participate in the development process itself. It may be limited to just testing the fix and verifying it works, or it could be extensively technical. Be ready to do some work, and be clear if you have time or technical limits you want to have honored.

Often, the more involved the reporter is at following up with new info, chasing down leads, locating patches or work arounds to test, and trying out variants, the more likely the bug will catch someone's interest and lend a hand.

Reporting Bugs from a Different Machine

Apport does a good job of collecting information on certain kinds of bugs. By default, it tries to launch your web browser to complete the bug filing. But sometimes you can't do this. You can make apport capture bug data manually like this:

   apport-bug --save /tmp/foo.apport

Then copy that foo.apport file to the machine you want to file the bug from (using scp, rsync, a usb drive, or whatever), and then file it like this:

  apport-bug ~/foo.apport

For the situation where apport automatically captured a crash dump from a crash or X lockup, but you can't file it from the sick machine, you will find the file in your /var/crash directory on the sick machine. Copy that over to another machine and file it from there, like above:

  apport-bug /path/to/file.crash

The crash files can be unpacked (like if you only want certain files):

  mkdir ~/tmp
  apport-unpack /path/to/file.crash ~/tmp/

What Next?

Once your X bug is reported, a triager may mark it Incomplete with questions or request some info, or mark as a dupe of a known issue, file it upstream, or determine it's not actually an X bug and move it somewhere else. Due to the volume of reports, automated scripts are used to help with triage; please be patient, these bots are not very smart.

If there is no reply from you within a month or two, the bug report may be closed as expired. You should feel free to reopen it once you have the needed information.

If your bug is forwarded upstream, you should participate in the discussions there. You may need to register an account on bugs.freedesktop.org to do so. If upstream finds a fix, it will be evaluated for possible inclusion in Ubuntu, if the fix is straightforward and seems safe.

If a fix is found and backported, you'll be asked to test and verify that it solves the issue. Often the fix can't be rolled out until someone validates it.