Common Tasks of Bugsquad

Here we have a list of common tasks performed by BugSquad members. Feel free to jump in with whatever looks interesting. For a more detailed explanation of what is involved in triaging, please see How To Triage. If you have any more specific questions don't hesitate to join #ubuntu-bugs on IRC ( and give a shout.

Finding the proper source package

Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in Ubuntu. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to Ubuntu. Some hints on finding the right package can be found in Bugs/FindRightPackage.

Confirming problems

If a bug is marked as New, it is helpful for you to try to reproduce the problem, and record the results in Launchpad. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment. When confirming the bug be sure to indicate which version of the package you used. One way to get the package version is via dpkg -l $pkgname where $pkgname is the name of the package you are testing.

Note: Do not confirm your own bugs - confirmation is required from someone other than the original reporter.

Forwarding bugs upstream

You should forward bugs to the authors of the software (upstream), if:

  • You made sure that the bug doesn't occur because of Ubuntu related changes,
  • The bug report is complete.

To learn how to do this, please consult HowToTriage/ForwardingUpstream

How to deal with Feature Requests

If you feel that the bug reported is a non-trivial feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, SpecTemplate and

How to deal with Support Requests

If you feel that the bug reported is a support request disguised as a bug report, please gently introduce the reporter to the Support Tracker located at .

How to deal with suggestions for changing defaults

If you feel that the bug reported is a suggestion for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments.


Many of the reports filed against Ubuntu are actually duplicates of bugs already reported. This can happen after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, reporters don't know how to check if the same bug has already been filed, or it is hard for them to determine if their bug is the same as another. Finding these duplicate bugs and aggregating information in one bug report is a very valuable contribution.

Bugs are duplicates when they have the same root cause. Determining this is a skill that you'll pick up as you become more familiar with a particular package or subsystem. Bugs are not necessarily duplicates if they have the same effects. For example, many different bugs can cause X not to start. Determining which bug a particular report refers to is part of triaging. If in doubt, ask for a second opinion. It is probably also sensible to ask the reporter to take look at the possible duplicate and to help with the decision. Reporters are normally interested in helping with their own bug reports!

For the above reason, bugs filed on the "linux" package should not be marked as duplicates.

When you first look at a new bug, try to find an existing bug in the system that describes the new one. Here's how:

  • Click the "List open bugs" link at the bottom of the bug page or

  • Click the "Bugs" tab at the top of the page
    • Both ways will produce a list of bugs about the same package
  • Look for bugs with similar descriptions or related titles.
  • If they describe the same root cause, decide which report should be the primary one. This should be the one that's the most understandable and contains the most information, not necessarily the oldest (lowest numbered) bug.
  • For the other report, add a comment like this standard reply

    Include: Nothing found for "^== A duplicate ==$"!

    information_little.png This page is part of the Bug Squad’s KnowledgeBase - pages with information about how to triage bugs.

    These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at:

    When you update one of these responses, you should also update the response used by the Firefox extension. These responses can be found in the bazaar branch lp:ubuntu-bugcontrol-tools in the file gm-xml-files/bugsquad-replies.xml. To check out a branch, use

    bzr branch lp:ubuntu-bugcontrol-tools

    Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see this email message), and they can be used when replying to a bug report if merged.

    Not described well

    Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" We'd be grateful if you would then provide a more complete description of the problem.

    We have instructions on debugging some types of problems at

    At a minimum, we need:
    1. the specific steps or actions you took that caused you to encounter the problem,
    2. the behavior you expected, and
    3. the behavior you actually encountered (in as much detail as possible).

    Missing Steps to Recreate Bug

    Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

    * Is this reproducible?
    * If so, what specific steps should we take to recreate this bug?

    This will help us to find and resolve the problem.

    Missing Apport Information

    Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
    apport-collect BUGNUMBER
    When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at

    Package or domain specific questions

    The following packages or type of bugs require the specific debugging information:

  • Then click the "Mark as Duplicate" link at the top left of the bug report page, and enter the number of the primary bug.

By default, searches in Launchpad and mentioned above will only look at Open bugs. It may also be worthwhile to go through the list of Invalid and Won't Fix bugs which you can look for by using an "Advanced Search". There is also a standardized tag for bugs likely to have lots of duplicates -- metabug.

When marking a bug report as a duplicate of another (master) bug report, please also check whether the master bug report is marked as private. If so, the master bug report might not be visible to the current bug reporter. When the parent bug is indeed marked as private please check why it is so. If it's only private because apport makes all bugs private by default, but the coredump has been removed and none of the apport attachments contain anything private, it may be made public. If it does contain confidential information, the bug should remain private and it is better to search for another bug which could be safely marked as the master bug. For any guidance regarding the private status of a master bug and marking another bug as a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs).

Reminder of the Code of Conduct

Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please direct them to

Setting Status

Include: Nothing found for "Header.*$"!

Include: Nothing found for "^----"!

Setting Importance

Include: Nothing found for "Header.*$"!

Include: Nothing found for "^----"!


Don't change this field unless specifically instructed by a developer. In particular, do NOT use this field to record the release of Ubuntu in which the bug was observed: that is not its purpose! It is used by the release team when there is a reason to address the bug in a specific milestone release.

Old Bugs

In many cases bugs reported in earlier versions are still open in our bug tracking system. They may have been fixed upstream without it being noted in Launchpad or the design may have changed so that the issue is no longer relevant. If the bug does not represent a security issue or is otherwise critical, it is very unlikely that the fix will be back-ported to older versions of Ubuntu. When it is fixed in the development branch it is therefore most appropriate to mark it 'Fix Released'. This helps clear the bug tracking system for old cruft.

Back to HelpingWithBugs.


Bugs/CommonTasks (last edited 2011-06-15 18:35:14 by brian-murray)