How to file a bug

We maintain a list of common issues. Check this site first to see if your issue has been reported — and if a solution exists.

As bugs are reported and fixed, developers collect a set of fixes and periodically release improved versions of their software. So, before reporting an issue, it is useful to check if you are using the latest version of a software. The simplest way to get the latest version of software in Fedora is to regularly update your system. Users of Gnome/KDE and other desktop environments can use their default applications to do so. These periodically check for updates and notify users. You can also use the default package manager dnf to check and update your system. Only users with administrator privileges can do so:

If you are using the latest version of the software available in Fedora, then it is likely that the bug has either not been reported, or has been reported but a fix has not yet been released. So, it is useful to search the list of already reported bugs before filing a new report. The Fedora Packages Web application provides a link the open bugs for a package. There is also a convenient shortcut that can be used.

Here, the package name must be the formal name of the package.

If a bug report has already been filed describing the issue, you should provide any extra information you may have. If there is nothing more to add to the report, you should "CC" (carbon-copy) yourself to the report to receive any updates. This can be done by clicking on the "Save changes" button when the "Add me to CC list" option is checked as shown below:

Bugs are filed on Bugzilla and you must have a Bugzilla account to file bugs and interact with them. Once you have created an account on Bugzilla, you can also login using your Fedora account. To use your FAS account to login to Bugzilla, you need to either use the same e-mail address on FAS and on Bugzilla, or if they differ, you can set the Bugzilla e-mail address in your FAS profile explicitly.

The bug tracker will only send e-mail notifications about bugs that a user is involved in. No other e-mails will be sent.

If a bug report for the particular issue has not already been filed, you should file a new one. The easiest way to file a new report is using the "File a new bug" drop down from the right hand side bar in the Fedora Packages Web application.

This redirects to a new bug report template on the bug tracker. The image below shows a new bug template:

The following fields need to be set:

Description of problem:

Explain the issue in more detail here.

Version-Release number of selected component (if applicable):

The version of the package should be specified here. Once the package name is known, the version can be obtained by using the rpm command:

For example:

How reproducible:

How often is the issue observed? Usually, a good answer to this field is one of:

Issues that occur always are easiest for developers to diagnose, since they may also be able to replicate it on their machines to collect more information. If an issue only happens sometimes, developers must spend more time and effort to understand what causes the problem. If an issue was only observed once, it is even harder to debug.

Steps to Reproduce:

These enable other users to verify the bug, and they also inform the developers of what specific steps cause the issue. It makes it much easier for them to look at the source code and pick out the bits that may be faulty.

Actual results:

What is observed when the issue occurs?

Expected results:

What does the user expect that should happen if the software behaved correctly?

Additional info:

Any additional information that may be useful to the maintainer should be added here.

After a bug has been filed, you should keep an eye out for any updates. The bug status workflow documentation describes the different statuses a bug may have. An e-mail notification of any new comments to the report will be sent to everyone involved in the bug report---the reporter, other users, and the maintainer. Often, maintainers will comment with queries to gather more information on the issue. Sometimes other users that experience the same issue may also add more information.

A well reported bug will often be fixed, and the maintainer will make an improved version of the software available to Fedora users. Bodhi will add a comment to the report when this happens. You can help the maintainer by confirming if the improved version works better in the Bodhi.

Once the improved version of the software has passed the QA process, the bug will automatically be closed. Congratulations!

If you have experienced a program crash, it will almost certainly be necessary to include a stack trace with your bug report. Crashes are often difficult to reproduce and even more difficult to fix, so the more information you can provide, the better. You will probably need to install -debuginfo RPMs so your stack trace will have useful debugging symbols. See the following pages for more information:

If you are having trouble with a graphical user interface (GUI), it often helps to include a screenshot or a screencast showing the bug in action. This helps developers find the exact place in the code which is causing the bug, and helps communicate what is going wrong when it is difficult to reproduce (for example, machine-specific layout problems).

A strong indication of a hardware-specific bug is that other people with different hardware should be able to reproduce the bug, but can’t. They also usually involve code that specifically interacts with a peripheral, such a webcam, video card, printer, or sound card (so for instance, it is uncommon for bugs affecting the user interface of a word processor or desktop calculator to be hardware-specific).

If you suspect your bug has something to do with the specific hardware you have, it will be necessary to identify the hardware so targeted action can be taken.

PCI and PCI-E devices found by the kernel can be listed with lspci.

USB devices found by the kernel can be listed with lsusb.

You may also find mention of specific devices or drivers in your system logs (run journalctl).

We pay special attention to security-sensitive bugs. Read the Reporting a Security Vulnerability page to understand the special process of opening a security bug.