Come segnalare un bug

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.

Terminologia

Ci sono alcuni termini che sono utilizzati in questo documento:

  • Bug: Un bug è un qualsiasi comportamento indesiderato o inatteso che appare in un software.

  • Tracciatore di bug: È il sistema di tracciamento di Fedora raggiungibile a https://bugzilla.redhat.com.

  • Pacchetto: Ogni software disponibile su Fedora ha un nome di pacchetto formale che è utilizzato dal tracciatore di bug e da altri strumenti dell’infrastruttura. I pacchetti possono essere cercati utilizzando Fedora dist-git.

  • Manutentore: Un volontario che tiene cura ti un pacchetto software fornito su Fedora. Ci si riferisce a loro come "manutentori dei pacchetti". Tengono traccia dei bug, aiutano nei problemi, e in generale fungono da intermediari tra gli sviluppatori del software e gli utenti di Fedora.

  • QA: L’assicurazione di qualità è il processo per assicurare che il software funzioni come previsto.

  • Bodhi: L’applicazione Web del QA di Fedora.

Prima di segnalare un bug

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.

Passo 1: Controllare l’ultima versione

Quando sono raccolti e sistemati dei bug, gli sviluppatori preparano un insieme di aggiustamenti e periodicamente rilasciano nuove versioni del proprio software. Per cui, prima di segnalare un problema, è utile controllare di stare utilizzando l’ultima versione del software. Il modo più semplice per ottenere l’ultima versione di un software su Fedora è di aggiornare in modo regolare il proprio sistema. Utenti di Gnome/KDE e altri ambienti desktop possono utilizzare le applicazioni predefinite per farlo. Esse controllano periodicamente alla ricerca di aggiornamenti e notificano l’utente. Si può anche utilizzare il gestore dei pacchetti predefinito dnf per controllare e aggiornare il proprio sistema. Solo gli utenti con i privilegi di amministratore possono farlo:

$ sudo dnf upgrade --refresh

Passo 2: Controllare bug già segnalati

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 del pacchetto>

La stringa nome del pacchetto deve essere il nome formale del pacchetto.

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.
20180825 how to file a bug gs
Figure 1. Ricerca di Gnome software tramite l’applicazione Web di Fedora Packages.
Ricerc avanzata: Si può anche utilizzare la ricerca avanzata del tracciatore di bug per restringere una ricerca. Tuttavia non è un passo necessario.

Se un bug è stato già segnalato con la descrizione del problema, si possono aggiungere altre informazioni utili. Se non c’è nulla da aggiungere, ci si può aggiungere con "CC" (copia carbone) per ricevere eventuali aggiornamenti futuri. Questo può essere fatto cliccando il pulsante "Save changes" quando l’opzione "Add me to CC list" è selezionata come mostrato di seguito:

20180825 how to file a bug cc list
Figure 2. La lista dei CC contiene tutti gli utenti che saranno notificati quando ci saranno aggiornamenti nella segnalazione.

Segnalare un bug

Passo 0: Creare un account Bugzilla

Utilizzare il proprio account Fedora: Si può utilizzare il proprio account Fedora per autenticarsi su Bugzilla. È il metodo preferito, perché con lo stesso account si può autenticare in tutti gli altri servizi di Fedora.

I bug sono segnalati nell’istanza bugzilla di Fedora, per cui è necessario possedere un account per creare un bug o interagire con essi. Un account richiede un indirizzo email valido e può essere creato qui (cliccare su "Register"). Il tracciatore di bug invierà soltanto email di notifica sui bug che ci si è iscritti. Non verranno inviate altre email.

Passo 1: Segnalare un nuovo 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 using the "File a new bug" drop down from the right hand side bar in the Fedora Packages Web application.

20180825 how to file a bug new bug shortcut
Figure 3. L’applicazione Web di Fedora Packages fornisce una scorciatoia comoda per segnalare nuovi bug.

La scorciatoia reindirizza nel tracciatore di bug in una nuova segnalazione con un modello predefinito. L’immagine di seguito mostra il modello predefinito per un nuovo bug:

20180825 how to file a bug new bug
Figure 4. Il modello predefinito per un nuovo bug.

È necessario compilare i seguenti campi:

  • Componente: Il nome del pacchetto.

  • Versione: La versione di Fedora in cui il bug è stato osservato.

  • Sommario: Un breve sommario che descrive il problema.

  • Descrizione: Una descrizione più dettagliata che descrive il problema. Contiene già il modello predefinito, che viene spiegato di sotto.

  • Allegati: File che forniscono maggiori informazioni sul problema possono essere caricati nella segnalazione del bug utilizzando il corrispettivo pulsante. Esempi sono istantanee dello schermo, file di log, registrazioni dello schermo.

  • Gravità, Hardware, SO: Questi campi sono opzionale e possono non essere impostati.

Descrizione del problema:

Spiegare il problema in dettaglio in questo campo.

Numero di versione-rilascio dei componenti selezionati (se applicabile):

La versione del pacchetto dovrebbe essere qui specificata. Una volta che si viene a conoscenza del nome del pacchetto, la versione la si può ottenere utilizzando il comando rpm:

$ rpm -q <nome del pacchetto>

Per esempio:

$ rpm -q gnome-software
gnome-software-3.28.2-1.fc28.x86_64

Come si riproduce:

Quanto spesso viene osservato il problema? Di solito una buona risposta per questo campo è una delle seguenti:

  • Sempre: il problema viene riscontrato ogni volta.

  • Qualche volta: il problema viene riscontrato qualche volta.

  • Solo una volta: il problema è stato riscontrato una sola volta.

I problemi che occorrono sempre sono i più facili da diagnosticare per gli sviluppatori, perché sono capaci di replicarli nelle loro macchine per ottenere maggiori informazioni. Se un problema accade solo qualche volta, gli sviluppatori devono spendere più tempo ed energie per capire cosa causa il problema. Se un problema è stato osservato solamente una volta, è ancora più difficile da diagnosticare.

Segnalazioni bug dettagliati rendono più facile il bug da aggiustare: se possibile, si dovrebbe investigare sui passi necessari per far accadere il problema, scrivendoli nella sezione successiva:
Nel dubbio inviare sempre una segnalazione: Se non si è sicuri di un bug, si dovrebbe sempre inviare la segnalazione. I manutentori possono dare seguito alla segnalazione con domande per acquisire più informazioni.

Passi per riprodurre:

I passi permettono altri utenti di verificare il bug, e possono inoltre informare gli sviluppatori di specifici passi che causano il problema. Rende molto più facile controllare il codice sorgente e isolare le parti che possono essere fallate.

Risultato attuale:

Cosa viene osservato quando il problema occorre?

Risultato aspettato:

Cosa l’utente si aspettava di accadere se il software avesse funzionato correttamente?

Informazioni aggiuntive:

Qualsiasi informazione aggiuntiva che può tornare utile ai manutentori può essere aggiunta in questa parte.

Passo 2: Seguire le segnalazioni aperte

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.

Chiedi per istruzioni: Se il manutentore chiede maggiori informazioni ma non è chiaro come devono essere raccolte, è lecito domandare istruzioni esplicite.
Notifiche email: Le notifiche email sono inviate da zilla@redhat.com. Si dovrebbe tenere un occhio su questo indirizzo email e di aggiungerlo nella lista dei "no-spam".

Passo 3: Provare gli aggiornamenti

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.

20180825 how to file a bug qa
Figure 5. L’applicazione Bodhi aggiunge commenti informando gli utenti di un aggiornamento che dovrebbe sistemare il bug.
Aiuta a provare gli aggiornamenti: Tutti gli utenti possono aiutare a provare le nuove versioni del software. Maggiori informazioni riguardo ciò si possono trovare qui. Notare che richiede un account Fedora.

Una volta che la versione migliorata del software ha superato il processo QA, il bug verrà automaticamente chiuso. Congratulazioni!

Advice for specific bug types

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:

Enhancement Requests

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 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 Changes Process.

  • Requests for new packages to be added to Fedora should not be filed in Bugzilla.

Graphical User Interfaces

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

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.