Ubuntu Wiki

We welcome reports of defects in Ubuntu that help us make Ubuntu a better product.

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

  ubuntu-bug xorg

The ubuntu-bug script will automatically include a lot of files and information we need for troubleshooting problems. Also be sure to include:

• A detailed description of the defect you found.

• Steps or conditions to reproduce or a measurement of the frequency of how often it occurs

• If it is a regression, make sure to indicate the last working version

• A photo of the screen (if it involves graphical corruption or weirdness)

• For crashes: A full backtrace

Take time to analyze the problem and write a good report, and especially include a detailed description of the problem, including steps to reproduce it. Defect reports which do not define the issue needing to be fixed are likely to be closed as ambiguous.

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.

Please be aware that a LOT of people file bug reports to Ubuntu, way more than we can respond to. We try to focus on the highest quality defect reports, so spending some time making a good report can help a lot.

Troubleshooting

Before reporting the defect you've found, take some time to analyze and isolate it:

X/Troubleshooting

A good defect report treats the issue scientifically, isolating when the problem happens and does not happen. Variables should be varied, such as configuration settings, driver versions, and so on. We provide snapshots of upstream versions of things in the xorg-edgers PPA; testing those to identify the issue is fixed or not fixed is invaluable.

Choosing a Good Title

Your title should communicate two things: The symptom being seen, and whatever is unique or unusual about the system in question.

Examples:

One Defect, One Person Per Report

In your defect report, focus on one specific issue. It is not uncommon to have several different unrelated bugs, but it makes it hard to track the issue to closure with them all in one report.

Similarly, often several people will see the same symptom, but X failures tend to have very similar symptoms even though the underlying bugs are unrelated. So we will focus on only the original reporter's issue. Don't report 'me too' on someone else's defect report.

Do's and Don't's

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. Maybe X is utterly broken, or the buggy machine lacks a network connection, or some other problem.

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

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). Due to the volume, automated scripts do the first level triaging to help sort out the high quality bug reports from the low.

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 defect report or not an issue requiring a fix at the distro level. If neither of those apply, the bug will be marked Triaged, which marks it ready for the next step.

Once a report has made it to Triaged, the defect report 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 the upstream 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.

Frequently Answered Questions

Q. My bug got marked 'Confirmed', what does that mean?

A. In Ubuntu-X the Confirmed state means the bug appears to have the necessary information for it to be reviewed by a developer. We employ scripts to move bugs to the Confirmed state when they have certain required files. The scripts don't check the description of the problem, so it's entirely possible for the script to mark a bug Confirmed that is later found to not be valid due to an ambiguous description or something.

Q. There are a lot of bugs reported in Launchpad, does Ubuntu really plan to fix all of them?

A. Ubuntu does not fix every bug. Actually most X.org bugs are fixed by upstream. Ubuntu's principle role is an 'integrator' which means we try to *get* the fixes and bring them to you. In some cases this involves fixing the issue ourselves, sometimes it means backporting a fix from upstream, and sometimes it means waiting until upstream has put out a new release of their code for us to incorporate. We don't have an omniscient view of every issue solved by every upstream change, so we don't always know exactly what fixed what (sometimes even upstream doesn't know.) This is why we sometimes just have to ask bug reporters to re-test with the newer versions and keep us informed.

Q. I encountered a serious problem with the released version of Ubuntu and filed a bug report about it. Why hasn't anyone answered it? Don't you support your releases?

A. The Launchpad bug tracker is mainly used by our development team to remove defects from the version of Ubuntu currently under development. Ubuntu also has both paid and volunteer technical support teams who focus on providing support for the releases, however they have separate tools for tracking support requests -- i.e., the support crew generally don't operate in the bug tracker. So, yes, releases are most definitely supported, but the bug tracker isn't the right place to ask for help.

Q. What kinds of bug reports will get developer attention in the released version of Ubuntu?

A. In general we try to avoid injecting a lot of random of changes into the released version of Ubuntu, since every change carries some risk of causing unexpected regressions. Each change needs to be carefully reviewed and thoroughly tested, and go through a stringent approval process. We only do this for defects that are well understood, with a clearly identified patch that is simple enough to see from the code whether it's unlikely to cause regressions. We generally only undertake the process once there has been a fix isolated and confirmed as fixing the problem.