Einen Fehler melden
Dieses Dokument bietet eine Schritt-für-Schritt-Anleitung zum Melden von Fehlern in Fedora. Weitere Informationen zur Verwendung von Bugzilla finden Sie in der Kurzanleitung unter Abschnitt „Fehler“.
Ein Softwarefehler muss nicht zwangsläufig zu einem Softwareabsturz führen. Jedes unerwünschte Verhalten einer Software kann als Fehler gemeldet werden. Der Paketbetreuer kann den Fehlerbericht dann prüfen und über das weitere Vorgehen entscheiden.
| Jeder kann Fehler melden: Alle Benutzer sind aufgerufen, gefundene Fehler zu melden. Die Meldung von Fehlern ist nicht nur Softwareentwicklern vorbehalten. |
Terminologie
In diesem Dokument werden einige Begriffe häufig verwendet:
-
Bug: Ein Bug ist jedes Verhalten in einer Software, das unerwartet/unerwünscht erscheint.
-
Bug-Tracker: Das Fedora-Fehlererfassungssystem unter https://bugzilla.redhat.com.
-
Paket: Jede in Fedora verfügbare Software hat einen offiziellen Paketnamen, der vom Bugtracker und anderen Infrastrukturwerkzeugen verwendet wird. Pakete können über Fedora dist-git gesucht werden.
-
Maintainer: A body of volunteers that takes care of the software packages provided in Fedora. These are referred to as "package maintainers". They keep track of bugs, help with issues, and generally act as middlemen between the developers of the software and Fedora users.
-
QA: Quality assurance is the process of ensuring that the software works as intended.
-
Bodhi: The Fedora QA Web Application.
Vor dem Melden eines Bugs
Ask Fedora — the community support forum — is a good place to start if you’re not sure if you’ve encountered a bug. Sometimes what is perceived as a bug is a misunderstanding or a question. The Ask Fedora community can help you figure out if you’ve encountered a bug — and if it’s specific to Fedora or is in the upstream package.
Step 0: Check the Common Issues page
We maintain a list of common issues. Check this site first to see if your issue has been reported — and if a solution exists.
Step 1: Check for the latest version
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:
$ sudo dnf upgrade --refresh
Schritt 2: Schauen Sie nach bereits gemeldeten Bugs
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.
https://bugz.fedoraproject.org/<Paketname>
Hierbei muss der Paketname der offizielle Name des Pakets sein.
| Finding the name of the package: If you do not know the formal package name of the software, you can use the Fedora Packages Web Application to search for it and view the list of bugs there. |
| Advanced searching: You can also use the advanced search features of the bug tracker to narrow down your search. However, this is not necessary. |
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:
Einen Fehlerbericht erstellen
Schritt 0: Erstellen Sie ein Bugzilla-Konto
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.
Step 1: Filing a new bug
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 to look up the package in the Fedora Packages Web application, and use the "File a new bug report" link provided on the page.
This redirects to a new bug report template on the bug tracker. The image below shows a new bug template:
Folgende Felder müssen ausgefüllt werden:
-
Component: Dies wird auf den Namen des Pakets gesetzt.
-
Version: Bitte setzen Sie dies auf die Fedora-Version, bei der der Fehler aufgetreten ist.
-
Summary: Hier sollten Sie eine kurze, hilfreiche Zusammenfassung des Problems schreiben.
-
Description: More detailed information about the issue should be provided here. It already contains a template, which is explained below.
-
Attachment: Files that provide more information of the issue can be uploaded with the bug report using the button here. E.g,, screen-shots, log files, screen recordings.
-
Severity, Hardware, OS: Diese Felder sind optional und müssen nicht ausgefüllt werden.
Description of problem:
Schildern Sie das Problem hier genauer.
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:
$ rpm -q <Paketname>
Zum Beispiel:
$ rpm -q gnome-software gnome-software-3.28.2-1.fc28.x86_64
How reproducible:
Wie häufig tritt das Problem auf? Üblicherweise lautet eine gute Antwort auf diese Frage:
-
Always: das Problem tritt immer auf.
-
Sometimes: das Problem tritt auf, aber nicht immer.
-
Only once: das Problem trat nur einmal auf.
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.
| Detailed bug reports make bugs easier to fix: If possible, you should try to investigate what steps cause the issue to happen and provide these steps in the next section: |
| Submit a report even if unsure: If you aren’t sure of what to fill in, you should still submit the bug report. Maintainers can follow up with questions to gather more information. |
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:
Was erwartet der Benutzer, wenn die Software korrekt funktioniert?
Additional info:
Alle zusätzlichen Informationen, die für den Betreuer nützlich sein könnten, sollten hier hinzugefügt werden.
Schritt 2: Beobachten eingereichter Berichte
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.
| Ask for instructions: If the maintainers ask for more information but it is unclear how it should be gathered, it is perfectly OK to ask the maintainers for explicit instructions. |
| E-mail notifications: The notifications are sent from bugzilla@redhat.com. You should keep an eye out for e-mails from this address, and add it to your "no-spam" lists. |
Schritt 3: Aktualisierungen testen
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.
| Help test updates: All users can help by testing new versions of software. More information on this can be found here. Note that this requires a Fedora account. |
Once the improved version of the software has passed the QA process, the bug will automatically be closed. Congratulations!
Hinweise zu bestimmten Fehlertypen
Abstürze
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:
Verbesserungsvorschläge
| Most enhancement requests should be filed upstream. If the software is missing a feature you think it should have, you generally want to file that in the upstream project’s bug tracker. Feature requests in Fedora Linux are generally changing defaults, enabling disabled-by-default features, etc. |
-
When filing an enhancement request in Bugzilla, add the keyword
Future Featureto 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 Changes Process.
-
Anfragen zur Aufnahme neuer Pakete in Fedora sollten nicht in Bugzilla eingereicht werden.
Grafische Benutzeroberflächen
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).
Hardware-spezifische Fehler
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.
Die vom Kernel gefundenen PCI- und PCI-E-Geräte können mit lspci aufgelistet werden.
Die vom Kernel gefundenen USB-Geräte können mit lsusb aufgelistet werden.
You may also find mention of specific devices or drivers in your system logs (run journalctl).
Sicherheitsrelevanz
Wir legen besonderen Wert auf sicherheitsrelevante Fehler. Auf der Seite Melden einer Sicherheitslücke finden Sie Informationen zum genauen Ablauf beim Melden eines Sicherheitsfehlers.
More reading
These are some more resources for those looking to report better bugs by providing more information:
-
Bugzilla etiquette: how to be polite in bug related conversations on the bug tracker.
-
A general introduction on how to file good bugs (available in multiple languages).
-
An introduction to Stacktraces---information software provides about where the fault may lie.
-
Using
coredumpctlto gather more information for bug reports.
Want to help? Learn how to contribute to Fedora Docs ›