Como relatar um bug
- Antes de relatar um bug
- Relatando um bug
- Advice for specific bug types
- Information required for bugs in specific components
- More reading
The purpose of this document is to give step by step instructions on filing bugs in Fedora. For more information about using Bugzilla, see the Bugs section of the Quick Docs.
A software bug does not necessarily need to be a software crash. Any undesired behaviour in software can be filed as a bug. The package maintainer can then look at the bug report and decide the best course of action.
|Anyone can file bugs: All users are encouraged to file any bugs they run into. Bug filing is not limited to only software developers.|
Existem alguns termos que são comumente usados neste documento:
Bug: Um bug é qualquer comportamento em um software que parece inesperado/indesejado.
Rastreador de bugs: O sistema de rastreamento de bugs do Fedora em https://bugzilla.redhat.com.
Pacote: Cada software que está disponível no Fedora tem um nome de pacote formal que é usado pelo rastreador de bug e outras ferramentas de infraestrutura. Os pacotes podem ser pesquisados usando o Fedora dist-git.
Mantenedor: Um corpo de voluntários que cuidam dos pacotes de software fornecidos no Fedora. Eles são chamados de "mantenedores de pacotes". Eles acompanham os bugs, ajudam com problemas e geralmente agem como intermediários entre os desenvolvedores do software e os usuários do Fedora.
QA: Garantia de qualidade é o processo de garantir que o software funcione conforme o esperado.
Bodhi: O aplicativo web de QA do Fedora.
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.
We maintain a list of common issues. Check this site first to see if your issue has been reported — and if a solution exists.
Conforme os bugs são relatados e corrigidos, os desenvolvedores coletam um conjunto de correções e lançam periodicamente versões aprimoradas de seus softwares. Portanto, antes de relatar um problema, é útil verificar se você está usando a versão mais recente de um software. A maneira mais simples de obter a última versão do software no Fedora é atualizar regularmente o seu sistema. Os usuários do GNOME/KDE e outros ambientes gráficos podem usar seus aplicativos padrão para fazer isso. Eles verificam periodicamente se há atualizações e notificam os usuários. Você também pode usar o gerenciador de pacotes padrão
dnf para verificar e atualizar seu sistema. Apenas usuários com privilégios de administrador podem fazer isso:
$ sudo dnf update --refresh
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/<nome do pacote>
nome do pacote deve ser o nome formal do pacote.
|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.|
|Pesquisa avançada: você também pode usar os recursos de pesquisa avançada do rastreador de bug para restringir sua pesquisa. No entanto, isso não é necessário.|
Se um relatório de bug já foi preenchido descrevendo o problema, você deve fornecer qualquer informação extra que possa ter. Se não houver mais nada a acrescentar ao relatório, você deve adicionar a si mesmo em "CC" (cópia carbono) no relatório para receber quaisquer atualizações. Isso pode ser feito clicando no botão "Save changes" (salvar alterações) quando a opção "Add me to CC list" (Adicionar-me à lista de CC) estiver marcada, conforme mostrado abaixo:
|Use sua conta Fedora: Você pode usar sua conta Fedora para entrar no Bugzilla. Isso é preferível, pois sua conta Fedora também pode ser usada para entrar em todos os outros serviços do Fedora.|
Os bugs são relatados na instância do bugzilla do Fedora, e você deve ter uma conta lá para registrar os bugs ou interagir com eles. Uma conta requer um endereço de e-mail válido e pode ser criada aqui (clique em "Register"). O rastreador de bugs só enviará notificações por e-mail sobre bugs em que o usuário esteja envolvido. Nenhum outro e-mail será enviado.
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:
Component: This will be set to the name of the package.
Version: You should set this to the version of Fedora that you observed the bug on.
Summary: You should provide a useful short summary of the issue here.
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: These fields are optional and need not 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 -q <packagename>
$ rpm -q gnome-software gnome-software-3.28.2-1.fc28.x86_64
How often is the issue observed? Usually, a good answer to this field is one of:
Always: the issue is observed each time.
Sometimes: the issue occurs, but not each time.
Only once: the issue was only observed once.
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.
What is observed when the issue occurs?
What does the user expect that should happen if the software behaved correctly?
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.
|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 email@example.com. You should keep an eye out for e-mails from this address, and add it to your "no-spam" lists.|
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!
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:
|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.
Requests for new packages to be added to Fedora should not be filed in Bugzilla.
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
USB devices found by the kernel can be listed with
You may also find mention of specific devices or drivers in your system logs (run
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.
These are some more resources for those looking to report better bugs by providing more information: