From Fedora Project Wiki

(→‎Tips by type of bug: Graphical User Interfaces)
(69 intermediate revisions by 16 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
[https://bugzilla.redhat.com/bugzilla/index.cgi Bugzilla] is the tracking tool used by the Fedora Project to get feedback from users and developers on bugs and requests for enhancements in Fedora.
[https://bugzilla.redhat.com/bugzilla/index.cgi Bugzilla] is the tracking tool used by the Fedora Project to get feedback from users and developers on bugs and requests for enhancements in Fedora.


Sometimes, new reports are missing information, are inaccurate, or have other flaws.  This wastes valuable time.  The person who reported the bug wastes their time when they file inaccurately, and the developers have to spend more time on the bug, which wastes their time, and may even result in the bug being ignored or forgotten.  This page describes how to file quality bug reports and suggest enhancements in a constructive manner.
Sometimes, new reports are missing information, are inaccurate, or have other flaws.  This wastes valuable time.  The person who reported the bug wastes their time when they file inaccurately, and the developers have to spend more time on the bug, which wastes their time, and may even result in the bug being ignored or forgotten.  This page describes how to file quality bug reports and suggest enhancements in a constructive manner.


{{Admon/tip | The [[Bugs/Common| Fedora common bugs]] page is useful for finding fixes to already known issues.}}
{{Admon/tip |Commonly Reported Bugs|The [[Bugs/Common| Fedora common bugs]] page is useful for finding fixes to already known installation, upgrading or HW/SW related issues.}}


==Process==
==Process==
Line 9: Line 10:
=== Do I need to file a bug? ===
=== Do I need to file a bug? ===


Unless you see a problem already reported in Bugzilla, mentioned in the release notes or other [[Docs|documentation]], listed in the acknowledged by developers on the mailing list, listed on the [[Bugs/Common|common bugs page]], or listed as a broken dependency in the daily Rawhide Report, you should file a bug.  Don't assume that everyone else is also seeing the same problem you are; many bugs are specific to a particular hardware, configuration, or habits of use. Discussing a bug on IRC or the fedora-test-list mailing list can help you diagnose the exact source and co-ordinate with others experiencing the same issue, but it is not a sufficient way to report the bug. It must be reported to Bugzilla so the issue can be properly tracked and will not be lost among the noise of the mailing list.
Unless you see a problem already reported in Bugzilla, mentioned in the release notes or other formal documentation (see http://docs.fedoraproject.org/), acknowledged by developers on a mailing list, listed on the [[Bugs/Common|common bugs page]], or listed as a broken dependency in the daily Rawhide Report, you should file a bug.  Don't assume that everyone else is also seeing the same problem you are; many bugs are specific to a particular hardware, configuration, or habits of use. Discussing a bug on IRC or the fedora-test-list mailing list can help you diagnose the exact source and co-ordinate with others experiencing the same issue, but it is not a sufficient way to report the bug. It must be reported to Bugzilla so the issue can be properly tracked and will not be lost among the noise of the mailing list.


A common practice is to file a bug first, then e-mail the list with a link to the bug report, asking for further assistance.  Many bugs are also filed with no e-mail to the mailing list, so be sure to search Bugzilla for your problem.
A common practice is to file a bug first, then e-mail the list with a link to the bug report, asking for further assistance.  Many bugs are also filed with no e-mail to the mailing list, so be sure to search Bugzilla for your problem.


=== The Bugzilla workflow ===
An overview of the official workflow for Fedora bugs can be found [[BugZappers/BugStatusWorkFlow|here]]. This should help you understand the life cycle of a Fedora bug.


=== Getting Started ===
=== Getting Started ===
Line 27: Line 31:


If a particular software package is heavily used, it is more likely that users will find bugs and/or suggest enhancements to it.  It does not mean that the software is more buggy.
If a particular software package is heavily used, it is more likely that users will find bugs and/or suggest enhancements to it.  It does not mean that the software is more buggy.
[[BugZappers/UnderstandingBugzilla]] has a few technical notes that may help Bugzilla make more sense.


=== Search for Duplicates ===
=== Search for Duplicates ===
Line 32: Line 38:
Very common known bugs are listed at [[Bugs/Common]].
Very common known bugs are listed at [[Bugs/Common]].


It's important to search Bugzilla to make sure your bug hasn't already been reported.  Put some keywords into the "Search" box at the top of any Bugzilla page and hit Enter, or use the [https://bugzilla.redhat.com/query.cgi Advanced Form].
It's important to search Bugzilla to make sure your bug hasn't already been reported.  The easiest way is to do a [https://bugzilla.redhat.com/query.cgi?format=specific keyword search].  Or you can use the [https://bugzilla.redhat.com/query.cgi?format=advanced Advanced Form]. Or you can use [https://bugz.fedoraproject.org/packagename https://bugz.fedoraproject.org/{{Replace|packagename}}]to look for specific bugs for a package (replace {{Replace|packagename}} with the name of the package you are checking).


It's not generally useful to file "I'm experiencing this bug, too" comments, unless there are specific details which might be helpful in tracking down the cause (e.g. you have more detailed debugging information, or a different hardware or software configuration which means a hardware-specific or configuration-specific bug is more widespread than previously thought).
It's not generally useful to file "I'm experiencing this bug, too" comments, unless there are specific details which might be helpful in tracking down the cause (e.g. you have more detailed debugging information, or a different hardware or software configuration which means a hardware-specific or configuration-specific bug is more widespread than previously thought).


If you are experiencing the bug in a more recent version of Fedora than reported in the bug, this is useful to mention.
If you are experiencing the bug in a more recent version of Fedora than reported in the bug, this is useful to mention.
See [[BugZappers/FindingDuplicates]] for more details.


=== Gather Helpful Information ===
=== Gather Helpful Information ===
Line 42: Line 50:
See "Tips by type of bug" below for specific guidance.
See "Tips by type of bug" below for specific guidance.


It is always useful to check /var/log/messages (for everyone) and ~/.xsession-errors (for desktop users) to see if there are any errors or warnings related to your problem.  Some programs also have dedicated files or directories in /var/log which are worth checking.
It is always useful to check {{Path|/var/log/messages}} (for everyone) and {{Path|~/.xsession-errors}} (for desktop users) to see if there are any errors or warnings related to your problem.  Some programs also have dedicated files or directories in {{Path|/var/log}} which are worth checking.


=== Start Filing the Bug ===
=== Start Filing the Bug ===


You can [https://bugzilla.redhat.com/enter_bug.cgi enter a new bug here].
On the home page, you can click the {{Clickable|[https://bugzilla.redhat.com/enter_bug.cgi enter a new bug report]}} link.
 
Or, if you know what the package name is, you can point your browser to [https://bugz.fedoraproject.org/packagename https://bugz.fedoraproject.org/{{Replace|packagename}}] (replace {{Replace|packagename}} with the name of the package). From this point, there are two ways to complete your filling of the bug:
# Click on the {{Clickable|Bugzilla}} link. This leads you on the Bugzilla page for this particular package. Then click on the  {{Clickable|Report a new bug in the {{Replace|packagename}} component in the Fedora Product}}  link in the bottom-left corner of the page.
# Click on the {{Clickable|Bugs}} entry in the main menu of the page then, in the new page, click on the {{Clickable|Open a New Bug in Fedora}} icon.


Read the report template carefully and provide all the requested information, as best you can.
Read the report template carefully and provide all the requested information, as best you can.
Please try to stick to clearly explaining the bug and all necessary information. Adding comments such as 'this needs to be fixed immediately!' or 'this is unacceptable!' is not a good idea: it's only likely to make the maintainers feel as if you are attacking them, and this doesn't help them to fix the problem.


=== Finding the Right Component ===
=== Finding the Right Component ===
Line 60: Line 74:
* Developers do not normally acknowledge bug reports or offer comments unless they have substantial feedback or require more information from you. It does not mean that your bug reports have not been valuable. Keep them coming!
* Developers do not normally acknowledge bug reports or offer comments unless they have substantial feedback or require more information from you. It does not mean that your bug reports have not been valuable. Keep them coming!


* After reporting a bug, you might get feedback from other users, or the developer may change the status and/or resolution of the bug report.  For an explanation:
* After reporting a bug, you might get feedback from other users, or the developer may change the status and/or resolution of the bug report.  For an explanation of the various statuses and resolutions, see [[BugZappers/BugStatusWorkFlow|this page]].


https://bugzilla.redhat.com/bugzilla/page.cgi?id=fields.html#bug_status
* Please keep your report focused on the original issue that was reported. Adding discussions of slightly related (or even entirely unrelated) will only cause the report to become confused and difficult to follow. If you notice a different problem, or when the initial problem is fixed you notice another problem that it was hiding, please file a new report rather than appending comments to the first report.


* If you file a bug against a version of Fedora and it is not fixed or otherwise resolved before the version reaches its End of Life (EOL), someone will need to test a more recent version of Fedora to see if the bug persists, and update the Version field if so.  Otherwise, your bug will be closed.  You will get an e-mail notification if this is the case.  Many bugs are fixed or made obsolete when software is incorporated into new versions of Fedora from upstream programmers.  Older bugs remain in the system for future reference, but re-testing will keep the bug open and "on the radar" for Fedora developers.  See [[BugZappers/HouseKeeping]] for more process information.
* If you file a bug against a version of Fedora and it is not fixed or otherwise resolved before the version reaches its End of Life (EOL), someone will need to test a more recent version of Fedora to see if the bug persists, and update the Version field if so.  Otherwise, your bug will be closed.  You will get an e-mail notification if this is the case.  Many bugs are fixed or made obsolete when software is incorporated into new versions of Fedora from upstream programmers.  Older bugs remain in the system for future reference, but re-testing will keep the bug open and "on the radar" for Fedora developers.  See [[BugZappers/HouseKeeping]] for more process information.
Line 68: Line 82:
=== Command-line interface ===
=== Command-line interface ===


If you need a command-line or programmatic interface to Bugzilla, try: "yum install python-bugzilla" and see the included documentation.  This provides the command "bugzilla".
If you need a command-line or programmatic interface to Bugzilla, try: "dnf install python-bugzilla" and see the included documentation.  This provides the command "bugzilla".


== Tips by type of bug ==
== Things Every Bug Should Have ==


=== Enhancement Requests ===
* '''Version number''': The exact version number of the problem RPM (or a list of suspicious RPMs).  The number in the Version selector field is the version of the Fedora distribution as a whole (9, 10, Rawhide); the RPM version number for a specific component within the distribution will change as updates are released.
* '''Clear description''': Reporting as much as possible about what was happening at the time of the incident, or exact steps about how to reproduce the bug.  Explanation of how what happened differs from what should happen, if it's not obvious.
* '''Diagnostic info''': Any relevant warnings printed on screen, excerpt from system logs around the time of the problem, any troubleshooting dumps available.
* '''Context''': For example, if this is a window manager problem, is it happening under GNOME or KDE?  If this is a network problem, what does the network setup look like?  If an application is being run in an unusual way (emulation, remotely), this should be mentioned.  What related items on the system have been customized?  Use your good judgment and common sense.


* When filing an enhancement request in Bugzilla, add the keyword '''Future<code></code>Feature''' to the report. Make sure you supply enough information and rationale for your enhancement requests to be considered.
Additional information may be requested out of course, depending on the type of bug and affected component.  See "Tips by Type of Bug" below.
* The Fedora Project has the objective to be a platform built exclusively from free and open-source software. Suggestions to include support for proprietary or other legally encumbered software is not constructive. See the [[ForbiddenItems]] page for details about this.
* If you want to make a new feature happen on your own create a wiki page for your feature and get it accepted.  See more on the Feature Process at [[Features/Policy]].
* Requests for new packages to be added to Fedora should not be added to Bugzilla.  Please add them to the wiki instead, on the [[Package maintainers wishlist]].


=== Security-Sensitive===
== Tips by Type of Bug ==
 
We pay special attention to security-sensitive bugs.  Read the [[Security/Bugs|  Security Bugs]]  page to understand the special process.
 
=== SELinux ===


If you encounter a problem where SELinux is denying permission or access inappropriately, include the full text of the AVC message which is logged.  This will be in /var/log/audit/audit.log if auditd is running, or otherwise in /var/log/messages.
{{Anchor|debugging}}
=== Crashes ===
=== Crashes ===


Line 96: Line 103:
* [[JavaStackTraces]]
* [[JavaStackTraces]]


=== Printing ===
=== Wedges, Seizures, and Panics ===


In system-config-printer ("System -> Administration -> Printing" on the Gnome menu), select "Help -> Troubleshoot" from the menu. If the troubleshooting wizard doesn't solve your problem, attach to your bug report the troubleshoot.txt file that results from the end of the process (if you can get that far).
If the entire machine locks up, and complete error output recorded in logfiles or on the screen, try some of the suggestions for  [[Common_kernel_problems#Diagnosing_.22My_machine_locked_up.22|diagnosing machine lockups]] and [[Common_kernel_problems#Crashes.2FHangs|kernel crashes and hangs]].


=== Anaconda Installer ===
=== Hardware-Specific Bugs===


If you are reporting bugs with the Fedora Anaconda installer refer to [[Anaconda/BugReporting]] for details.
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).


=== Kernel ===
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.


See the [[KernelBugTriage]] and [[common kernel problems]] pages for information on debugging and reporting kernel bugs.
PCI and PCI-E devices found by the kernel can be listed with "lspci".


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


See the [[Tools/Virtualization/BugReporting]] page from tips on reporting virt bugs.
You may also find mention of specific devices or drivers in your system logs (run "journalctl").


=== Xorg ===
=== Enhancement Requests ===


Information on debugging Xorg in Fedora is available from the [[Xorg/Debugging]]  page.
* When filing an enhancement request in Bugzilla, add the keyword '''Future<code></code>Feature''' to the report. The Keyword should be added right after submitting the bug. You will see the Keyword input box then. Make sure you supply enough information and rationale for your enhancement requests to be considered.
* The Fedora Project has the objective to be a platform built exclusively from free and open-source software. Suggestions to include support for proprietary or other legally encumbered software is not constructive. See the list of [[forbidden items]] page for details about this.
* If you want to make a new feature happen on your own create a wiki page for your feature and get it accepted.  See more on the Feature Process at [[Features/Policy]].
* Requests for new packages to be added to Fedora should not be added to Bugzilla. Please add them to the wiki instead, on the [[Package maintainers wishlist]].


=== Fonts ===
=== Security-Sensitive===


See [[:Category:Fonts and text QA]].
We pay special attention to security-sensitive bugs.  Read the [[Security_Bugs#Reporting_a_Security_Vulnerability|Reporting a Security Vulnerability]] page to understand the special process of opening a security bug.


=== OpenOffice.org (OOo) ===
===Graphical User Interfaces===
 
OOo is quite big, and it links to and uses a lot of stuff, and so brings up a
lot of problems that are not always OOo bugs, so...
 
* A crash on startup might be a crash in some OpenGL lib, not OOo itself.
* Get the test source at [https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=108799] .
* Run <code>gcc testgl.c -o testgl -lX11 -lGL</code> to compile it.
* If it also crashes, your bug is probably not an OOo bug.
 
* Check that similar applications don't behave the same way, e.g. if Firefox/gedit/glxgears do the same thing as OOo, then it's unlikely to be an OOo bug.
 
* If the crash dialog appears, paste the stacktrace it gives you into your bug report.
 
* Mention if you are using KDE or GNOME, as it often matters. If you have non-Fedora-supplied KDE theme engines installed, try one of the supported ones.
 
* If there is an error/warning message, say what the message is.
 
* If it happens with a particular document, attach the document. If you can, trim the document down to the smallest test case that reproduces the problem. "Scroll to page 912 and the graphic is misplaced" is much less appealing than having a one-page example.
 
* If you think there is something wrong with what is being displayed, attach a screenshot. ''I'' might not understand ''your'' description.


Example: "formula font is wrong"
If you are having trouble with a graphical user interface (GUI), it is often helpful 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).


Is it the font used in the text area for editing the formula, or is it the font used to display the formula? Did you mean the math editor, or did you actually mean formulas in calc?  A screenshot would solve these kinds of questions.
* To take a screenshot, hit the "Print Screen" button on your keyboard, or in GNOME use the ''Screenshot'' application


* Try not to tag things onto bugs with "and this unrelated thing doesn't work" or "yeah that fixed it, but something different is still not the way I want it" -- mutating bugs are really difficult to deal with. There's no problem with opening multiple bugs, and it's easier to merge bugs together if they turn out to be the same thing than to unmunge them into separate bugs.


* If you know you have something unusual about your setup, mention it.
* To get a video of your screen (a "screencast"), you can use either the gnome built-in screen recorder or the [https://sourceforge.net/projects/recordmydesktop/ recordmydesktop] application.


Examples:
** Launching the GNOME built-in video recorder is very easy. Just press the  {{Key|Ctrl}} '''+''' {{Key|Shift}} '''+''' {{Key|Al}} '''+''' {{Key|R}} key combination. By default, the recording – without any sound track –  time is 30 seconds. As soon as the recording is over, the video screencast is available in your {{Path|~/Videos}} folder as a '''.vebm''' file. An easy and very fast way of changing the recording time is to use the following command {{Usercommand|command=gsettings set org.gnome.settings-daemon.plugins.media-keys max-screencast-length {{Replace|duration}}}} where {{Replace|duration}} has to be replaced with the numerical value of the desired recording time in seconds (please don't add any unit).
* ".doc documents created with msword running under wine don't open in OOo" as opposed to just saying ".doc files don't open in OOo"
* "Saving to a samba share doesn't work" versus "saving doesn't work"


* If you can, install the debuginfo and try:
** To use the recordmydesktop application, first install it with: {{Usercommand|command=su -c 'dnf install recordmydesktop'}}. Now launch it from the command line with: {{Usercommand|command=recordmydesktop}} Please refer to the [https://sourceforge.net/projects/recordmydesktop/ |recordmydesktop] documentation for more details on how to use this program.
<pre>
$> gdb /usr/lib/openoffice.org/program/soffice.bin
(gdb) run -writer
(gdb) bt
</pre>
Paste the backtrace in your bug report.


(<code>-writer</code> should be changed accordingly: <code>-calc -impress -math -draw</code>)
=== Information required for bugs in specific components ===


* It's nice when someone finds that a bug was resolved in an update and mentions it in an old, unclosed bug, but it is not so useful when someone adds an unprompted note to say that the problem is still there.
* [[SELinux/Troubleshooting|SELinux]]
* [[How_to_debug_Firefox_problems|Firefox]]
* [[How_to_debug_printing_problems|Printing]]
* [[How to debug installation problems|Anaconda (installer)]]
* [[KernelBugTriage|Kernel]] (also see [[common kernel problems]])
** [[How to debug sound problems|Sound]] (also see [[KernelBugTriage]])
* [[How to debug Virtualization problems|Virtualization]]
* [[How_to_debug_Xorg_problems|X.org]]
* [[:Category:Fonts and text QA|Fonts]]
* [[How to debug OpenOffice problems|OpenOffice.org]]
* [[Bug info Rhythmbox|Rhythmbox]]
* [[How to debug PulseAudio problems|PulseAudio]]
* [[How_to_debug_Dracut_problems|Dracut]]
* [[How_to_use_qemu|QEMU]]
* [[How to debug Systemd problems|Systemd]]
* [[How to debug Wayland problems|Wayland]]


* "This is unacceptable" is not good motivational practice.
=== Filing bugs for multiple releases ===
 
===Updates===
 
If you are seeing update problems in Rawhide, see the [[Testing]] page.  There is also a specific problem with Fedora 11 Alpha; see the [[Fedora 11 Alpha release notes]].
 
===Graphical User Interfaces===


If you are having trouble with a graphical user interface (GUI), it is often helpful to include a screenshot 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).
If your bug is present in more than one Fedora release, you can clone it by clicking {{Clickable|Clone This Bug}} in the top-right corner of the bug report and then assign a different version number in the newly created report.


== Help Wanted ==
== Help Wanted ==
Line 183: Line 173:


[[Category:Bugs]]
[[Category:Bugs]]
[[Category:Debugging]]

Revision as of 02:37, 11 May 2016

Bugzilla is the tracking tool used by the Fedora Project to get feedback from users and developers on bugs and requests for enhancements in Fedora.

Sometimes, new reports are missing information, are inaccurate, or have other flaws. This wastes valuable time. The person who reported the bug wastes their time when they file inaccurately, and the developers have to spend more time on the bug, which wastes their time, and may even result in the bug being ignored or forgotten. This page describes how to file quality bug reports and suggest enhancements in a constructive manner.

Idea.png
Commonly Reported Bugs
The Fedora common bugs page is useful for finding fixes to already known installation, upgrading or HW/SW related issues.

Process

Do I need to file a bug?

Unless you see a problem already reported in Bugzilla, mentioned in the release notes or other formal documentation (see http://docs.fedoraproject.org/), acknowledged by developers on a mailing list, listed on the common bugs page, or listed as a broken dependency in the daily Rawhide Report, you should file a bug. Don't assume that everyone else is also seeing the same problem you are; many bugs are specific to a particular hardware, configuration, or habits of use. Discussing a bug on IRC or the fedora-test-list mailing list can help you diagnose the exact source and co-ordinate with others experiencing the same issue, but it is not a sufficient way to report the bug. It must be reported to Bugzilla so the issue can be properly tracked and will not be lost among the noise of the mailing list.

A common practice is to file a bug first, then e-mail the list with a link to the bug report, asking for further assistance. Many bugs are also filed with no e-mail to the mailing list, so be sure to search Bugzilla for your problem.

The Bugzilla workflow

An overview of the official workflow for Fedora bugs can be found here. This should help you understand the life cycle of a Fedora bug.

Getting Started

If you are new to Fedora's Bugzilla, then the first step is to register an account. It's a quick process, so don't hesitate to get started right away. For details about the account creation process, please consult the bugzilla documentation.

Understanding Bugzilla Culture

Understanding how other people are expecting you to use the system will improve the way your problem is presented, make others more receptive and more likely to fix your bug, and make the experience more pleasant for everyone. If you have never used Bugzilla before or are new to filing bug reports, it may be helpful to read the following pages.

If a particular software package is heavily used, it is more likely that users will find bugs and/or suggest enhancements to it. It does not mean that the software is more buggy.

BugZappers/UnderstandingBugzilla has a few technical notes that may help Bugzilla make more sense.

Search for Duplicates

Very common known bugs are listed at Bugs/Common.

It's important to search Bugzilla to make sure your bug hasn't already been reported. The easiest way is to do a keyword search. Or you can use the Advanced Form. Or you can use https://bugz.fedoraproject.org/<packagename>to look for specific bugs for a package (replace <packagename> with the name of the package you are checking).

It's not generally useful to file "I'm experiencing this bug, too" comments, unless there are specific details which might be helpful in tracking down the cause (e.g. you have more detailed debugging information, or a different hardware or software configuration which means a hardware-specific or configuration-specific bug is more widespread than previously thought).

If you are experiencing the bug in a more recent version of Fedora than reported in the bug, this is useful to mention.

See BugZappers/FindingDuplicates for more details.

Gather Helpful Information

See "Tips by type of bug" below for specific guidance.

It is always useful to check /var/log/messages (for everyone) and ~/.xsession-errors (for desktop users) to see if there are any errors or warnings related to your problem. Some programs also have dedicated files or directories in /var/log which are worth checking.

Start Filing the Bug

On the home page, you can click the enter a new bug report link.

Or, if you know what the package name is, you can point your browser to https://bugz.fedoraproject.org/<packagename> (replace <packagename> with the name of the package). From this point, there are two ways to complete your filling of the bug:

  1. Click on the Bugzilla link. This leads you on the Bugzilla page for this particular package. Then click on the Report a new bug in the <packagename> component in the Fedora Product link in the bottom-left corner of the page.
  2. Click on the Bugs entry in the main menu of the page then, in the new page, click on the Open a New Bug in Fedora icon.

Read the report template carefully and provide all the requested information, as best you can.

Please try to stick to clearly explaining the bug and all necessary information. Adding comments such as 'this needs to be fixed immediately!' or 'this is unacceptable!' is not a good idea: it's only likely to make the maintainers feel as if you are attacking them, and this doesn't help them to fix the problem.

Finding the Right Component

When reporting a bug, it is helpful if you select the right Product, Version and Components. By doing so, you reach the developer/maintainer of the affected software package, which helps resolve the bugs faster. If you assign it to the wrong component, it can be reassigned to the correct one, so never skip filing a bug report just because you couldn't figure out which component to assign it to.

See BugZappers/CorrectComponent for details on how to determine the correct component if you aren't sure.

After Your Bug is Filed

  • Developers do not normally acknowledge bug reports or offer comments unless they have substantial feedback or require more information from you. It does not mean that your bug reports have not been valuable. Keep them coming!
  • After reporting a bug, you might get feedback from other users, or the developer may change the status and/or resolution of the bug report. For an explanation of the various statuses and resolutions, see this page.
  • Please keep your report focused on the original issue that was reported. Adding discussions of slightly related (or even entirely unrelated) will only cause the report to become confused and difficult to follow. If you notice a different problem, or when the initial problem is fixed you notice another problem that it was hiding, please file a new report rather than appending comments to the first report.
  • If you file a bug against a version of Fedora and it is not fixed or otherwise resolved before the version reaches its End of Life (EOL), someone will need to test a more recent version of Fedora to see if the bug persists, and update the Version field if so. Otherwise, your bug will be closed. You will get an e-mail notification if this is the case. Many bugs are fixed or made obsolete when software is incorporated into new versions of Fedora from upstream programmers. Older bugs remain in the system for future reference, but re-testing will keep the bug open and "on the radar" for Fedora developers. See BugZappers/HouseKeeping for more process information.

Command-line interface

If you need a command-line or programmatic interface to Bugzilla, try: "dnf install python-bugzilla" and see the included documentation. This provides the command "bugzilla".

Things Every Bug Should Have

  • Version number: The exact version number of the problem RPM (or a list of suspicious RPMs). The number in the Version selector field is the version of the Fedora distribution as a whole (9, 10, Rawhide); the RPM version number for a specific component within the distribution will change as updates are released.
  • Clear description: Reporting as much as possible about what was happening at the time of the incident, or exact steps about how to reproduce the bug. Explanation of how what happened differs from what should happen, if it's not obvious.
  • Diagnostic info: Any relevant warnings printed on screen, excerpt from system logs around the time of the problem, any troubleshooting dumps available.
  • Context: For example, if this is a window manager problem, is it happening under GNOME or KDE? If this is a network problem, what does the network setup look like? If an application is being run in an unusual way (emulation, remotely), this should be mentioned. What related items on the system have been customized? Use your good judgment and common sense.

Additional information may be requested out of course, depending on the type of bug and affected component. See "Tips by Type of Bug" below.

Tips by Type of Bug

Crashes

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:

Wedges, Seizures, and Panics

If the entire machine locks up, and complete error output recorded in logfiles or on the screen, try some of the suggestions for diagnosing machine lockups and kernel crashes and hangs.

Hardware-Specific Bugs

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").

Enhancement Requests

  • When filing an enhancement request in Bugzilla, add the keyword FutureFeature to the report. The Keyword should be added right after submitting the bug. You will see the Keyword input box then. Make sure you supply enough information and rationale for your enhancement requests to be considered.
  • The Fedora Project has the objective to be a platform built exclusively from free and open-source software. Suggestions to include support for proprietary or other legally encumbered software is not constructive. See the list of forbidden items page for details about this.
  • If you want to make a new feature happen on your own create a wiki page for your feature and get it accepted. See more on the Feature Process at Features/Policy.
  • Requests for new packages to be added to Fedora should not be added to Bugzilla. Please add them to the wiki instead, on the Package maintainers wishlist.

Security-Sensitive

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.

Graphical User Interfaces

If you are having trouble with a graphical user interface (GUI), it is often helpful 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).

  • To take a screenshot, hit the "Print Screen" button on your keyboard, or in GNOME use the Screenshot application


  • To get a video of your screen (a "screencast"), you can use either the gnome built-in screen recorder or the recordmydesktop application.
    • Launching the GNOME built-in video recorder is very easy. Just press the Ctrl + Shift + Al + R key combination. By default, the recording – without any sound track – time is 30 seconds. As soon as the recording is over, the video screencast is available in your ~/Videos folder as a .vebm file. An easy and very fast way of changing the recording time is to use the following command
      gsettings set org.gnome.settings-daemon.plugins.media-keys max-screencast-length <duration>
      where <duration> has to be replaced with the numerical value of the desired recording time in seconds (please don't add any unit).
    • To use the recordmydesktop application, first install it with:
      su -c 'dnf install recordmydesktop'
      . Now launch it from the command line with:
      recordmydesktop
      Please refer to the |recordmydesktop documentation for more details on how to use this program.

Information required for bugs in specific components

Filing bugs for multiple releases

If your bug is present in more than one Fedora release, you can clone it by clicking Clone This Bug in the top-right corner of the bug report and then assign a different version number in the newly created report.

Help Wanted

  • The Fedora Bug Triaging team is actively soliciting new volunteers. If you are interested, Please see the BugZappers page.
  • Quality Assurance also welcomes new volunteers; see QA.