In other languages: English (en) 中文（中国大陆） (zh-cn) [edit]

文档摘要:

Purpose: To describe steps for reporting bugs in language comfortable to novices.

Audience: Linux users unfamiliar with bug reporting

Assumptions: The user is running Fedora Linux, has access to the internet, and generally understands how to use computer software.

Related Documents: Bugs and feature requests

Note: This page is intended to be more beginner friendly than Bugs and feature requests, and includes less technical information. Hopefully, this page won't scare away a new user as the other might.

Lead Writer: danielsmw

How to File a Bug Report

This page describes a procedure for reporting software bugs to Fedora developers. A bug is defined as "an error, flaw, mistake, failure, fault or 'undocumented feature' in a computer program that prevents it from behaving as intended" (Wikipedia). This page focuses specifically on the use of Red Hat's Bugzilla system for Fedora. Users may, however, find the information helpful for other Bugzilla implementations as well.

Bug reporting is an essential part of how Fedora improves software. Without user feedback, many problems will remain unresolved, so learning to use the Bugzilla reporting tool is an important end-user skill. With this in mind, remember that not everything you may use in Fedora is necessarily the responsibility of the Fedora project and its package maintainers. If you are using ForbiddenItems, for example, you should not submit a bug to the Fedora developers. You should also not file a bug report with Fedora if you installed software from source instead of using Fedora's package manager.

Fedora is an operating system, and the Fedora Project does not own or have responsibility for every program running on the computer. Please check the ForbiddenItems list before filing a bug report. Any bug in a program or utility listed on this page cannot be resolved by the Fedora Project team.

Why do we file bugs?

As a user, encountering bugs that hinder your work (or play) can often be frustrating, at best. Oftentimes, ignoring bugs and just finding a different way to get your job done makes your immediate end-user experience more efficient. In the long run, however, failing to report bugs means that problems you may have encountered will never be resolved. Unlike the experience many people have when reporting bugs to large software companies, open source users will find that software developers often reply to bug reports and engage the user personally though electronic means.

What does this mean for you? It means that by reporting a bug, you can be sure that it will be paid attention to. It may not be fixed immediately, but the programmers who maintain the software you use are aware about issues that arise under your reported circumstances, and can work to resolve those problems for the future.

Creating a Bugzilla Account

Bugzilla an open source bug-tracking tool used for managing reports of issues, defects, and features by users. Bugzilla is usually accessed via a web interface - in other words, you use it through your web browser, and you will not need to download any new software. To submit a bug using Bugzilla, you must first create a user account.

Point your browser to the account creation page.
Request an account using your legitimate email address.
Check your mail until you receive an account creation confirmation.
Follow the link the email to continue account creation. Fill in the requested fields, and sumbit the form.

Note that if you do not act on the email confirmation within three days, it will expire. In this case, you will need to start from the beginning again.

Once you have created an account, you can login to Bugzilla with your email address and password.

Gathering Information

Before reporting a bug, collect as much relevant information as possible. As you collect this information, make sure you at least know the following:

Whether or not the bug has already been reported
The name and version of the buggy software,
A description of what you were doing, and what you were trying to do, when the error occurred,
The operating system you are running, and
Your computer's architecture.

Alone, however, this information is rarely enough for developers to resolve the reported issue. Consider reporting other information such as other running applications, any peripherals (printers, scanners, camera) that the software might have been interacting with, concurrent issues with other software (another program was malfunctioning at the same time), and the time and date at which the error occurred. The more information the developer can see, the more clues he has as to the source of the malfunction.

Avoiding Duplicate Bug Reports

Sometimes, the most important information you can research is whether or not the bug has already been reported. When the same bug is reported several times in Bugzilla, developers are slowed down by having to read all of them redundantly. In the Bugzilla system, use the search feature to see if you can find an already-reported version of your bug.

After clicking on the "Search Existing Bugs" link, you should see this simple bug-searching form.

After you have logged into Bugzilla, look for your Most Common Actions pane on the left and click the "Search Existing Bugs" link (see figure under Filing a Bug Report). Once you have arrived at the search form, you can play with the different options and use various keywords to search for a bug that matches your issue. The Advanced Search tab offers more flexibility, but is also very complex. The simple form should be enough to verify the existence of a bug report. Choose Fedora as the product unless you are confident that another choice is better here.

The importance of determining whether or not a bug has already been filed cannot be stressed enough. If in doubt, it is always better to file a bug than to ignore it; however, developers can be slowed down by the weight of duplicate bug reports, so ensure that you conduct a thorough search before filing yours.

Finding Common Information

Your bug report will almost always contain the information listed above. More often than not, though, additional information will be needed. It is important to know ways to determine frequently needed data about your bug. This might involve using a terminal. To open a terminal in Gnome, click Applications->System Tools->Terminal.

Software Version: The version often be found within the Help menu in a graphical program. For a console utility, the program's man page should tell you what flag to use to print out the version (oftentimes, this involves typing --version after the command). To view the man page, type man program, where program is the software you are trying to check.
Operating System: There are many ways to determine the operating system you are running, but running uname -sr in a terminal is one way to do it.
Architecture: Two of many ways to determine the architecture of your processor are with uname -p and arch.

To run any of the commands above, such as uname, just type your full command in the terminal window and press [ Enter ].

Reproducing Errors

Oftentimes, the information you send the developer just isn't enough. In order to understand what was going on "under the hood", so to speak, the developer will need to reproduce the error on his own. Therefore, be ready to provide the developer with step-by-step instructions on how he should be able to reproduce the error. If you feel that there the error is only related to the program, then a good place to tell him to start might simply be running that program.

While a pixel-by-pixel description of how you clicked on things is probably not necessary, it is important that you describe the basic outline of how you made the bug appear. For example, a program may have several different methods of printing a document: a keyboard shortcut, a menu item, or a taskbar button, perhaps. You need to tell the developer which method produced the error.

Filling Out a Bug Report

The common actions pane at bugzilla.redhat.com. Click "Enter a new bug report" to begin.

Once you have successfully logged into the Bugzilla system and collected the necessary data, you can start to file the report. Again, remember to make sure your bug hasn't already been filed by somebody else.

After logging in at https://bugzilla.redhat.com, you should see a side pane with common actions. Click on "Enter a new bug report".

After starting your bug report, you will be prompted to choose the project your bug is in. If you are experiencing a bug using Fedora Linux, then you should probably click "Fedora" here. The next menu will present options for categories within the project you selected. If you found a bug in some software, you should probably just click "Fedora". Each category has a short caption to help you choose one. If you find an error in the documentation, for example, you may want to click "Fedora Documentation" instead.

If, for some reason, you really just can't decide where your bug belongs, don't give up. Just submit it somewhere, and the developers will reassign it to the appropriate project if necessary.

Once you have selected your bug's category, you will need to fill out the actual report. There are two methods for doing this; you can use the standard form or the guided form. The standard form is less verbose but easier to use if you know what you're doing. The guided form is recommended for new users.

Either way, make sure you have all the information you collected earlier, and start to fill in the fields.

Guided Form

The guided form provides an easy step-by-step method for filing bugs. By default, however, you will see the standard form. To switch to the guided form, click "Guided" in the second sentence on the page ("You may also use the Guided bug entry page for a easier step by step method."). The guided form involves three steps.

First, determine if your bug has already been reported. The first step will allow you to search through bugs on record so you can ensure that your bugs is not already registered in Bugzilla.

Next, you need to give detailed information about your bug. Fill in each of the queries:

Component: Choose the name of the software that is giving you trouble. Depending on your bug, this might also be a software application, a documentation file, or another component of Fedora.
Hardware Platform: This is your architecture that we determined earlier. If, for some reason, you are unsure of your platform, you can probably choose i386; however, make an effort to be sure of your architecture if you can.
URL: This is an optional field, and you can leave it out unless it applies to you.
Summary: Fill in a short, one sentence description of the problem. For example, "Saving file in .tiff format causes program to exit."
Details: This is your long version of the issue. Be as specific as possible. Make sure to give a rational, complete depiction of the problem; saying "The print button is broken" does not describe the problem enough.
Reproducibility: This is a very important field. Does this happen every time you follow some procedure? Does it only happen on Tuesdays? Was it only once?
Steps to Reproduce: As discussed earlier, provide the steps you followed to reach the bug. If the problem cannot be reproduced, say so in "Reproducibility" and give the steps to the best of your memory.
Actual Results: What happened when you reached the bug?
Expected Results: What do you think was supposed to happen?
Additional Information: If there's anything else you feel the developer need to know, you can put it here. This might be an error message from console output, or it might be the model of your camera that was connected when the bug occurred.
Severity: When reporting the severity of the issue, be reasonable. Try to be objective. Remember that, although the error may inconvenience you, it may not actually be a big deal. Each severity level has a caption that should help you decide.
Security: If you have identified a security-compromising problem, it needs to be noted here. These can often be serious issues.

In guided mode, there is no button for creating an attachment. If you have a screenshot, error log, stack trace, or any other important information you want to submit, you'll have to use the "Create a new Attachment" link on the bug after you submit it.

Finally, click submit, and check your email periodically for updates on the problem or clarification questions from developers.

Search

How to file a bug report/zh-cn

Contents