Bugzilla/Guida ai rapporti dei Bug
This article explains how to report bugs on the Gentoo Bugzilla.
See Bugzilla/Guide for the recommended method of reporting bugs for Gentoo.
Consigli e Best practices
- Rileggere il testo prima dell'invio, il testo non può essere modificato in seguito. Inoltre, qualsiasi testo inserito in una segnalazione di bug verrà solitamente inviato immediatamente via e-mail a molte persone. Scrivi in un linguaggio preciso e pulito ed evita discorsi colloquiali. Suggerimento: Immagina di avere una sola possibilità nella tua vita di scrivere questo importantissimo bug report. Sai che il destinatario può leggere l'inglese, ma non è la sua lingua madre.
Cercare i duplicati, prima di creare un nuovo bug.
- Resta in tema - Un bug ticket viene utilizzato per i rapporti tecnici e le chiacchiere dovrebbero essere evitate. Conservali nei channel (forum, IRC o mailing list).
- Conferma l'esistenza deol bugsolo una volta - Non aiuta a risolvere il problema se tu e un'altra persona lo segnalate due volte. Ma se il tuo sistema e quello del bug confermato differiscono in modo ovvio e sarebbe utile saperlo, aggiungi queste informazioni.
- Apri un bug ticket per argomento - Solitamente questo significa non più di un pacchetto e un bug per ticket. Se il tuo problema non viene discusso su un bug, cercane uno correlato al tuo problema o crea un nuovo rapporto. Non dirottare i bug.
- Non si parla di bug TRACKER. - Questi bug sono meta bug. Se vuoi aggiungere informazioni utili, aggiungile a un bug secondario correlato o crea un nuovo bug.
- Opzionale: Consulenti Gentoo forniscono anche supporto commerciale per bug ed ebuild.
- Allega i log al bug ticket se il ticket riguarda problemi durante il runtime o l'installazione.
Packages/ebuild
Si dovrebbero sempre aggiungere le informazioni sulla configurazione del sistema per la segnalazione di un bug. Per fare questo, creare un nuovo attachment e incollare il contenuto di:
user $emerge --info > /tmp/emerge--info.txtProblemi al momento del build (emerge fallito)
- Prima scrivi la versione esatta del pacchetto nel titolo della segnalazione di bug, ad es. sys-apps/package-2.3-r4
- Aggiungi una breve descrizione al titolo.
- Allega i log al bug ticket
Problemi durante il funzionamento
I file e le informazioni di interesse in ordine di priorità:
- La versione esatta del pacchetto nel titolo della segnalazione di bug, ad es. sys-apps/package-2.3-r4 si arresta in modo anomalo con errore: Impossibile procedere...
- Descrizione del problema, in modo che altri possano riprodurlo:
- Come viene eseguito il programma (sulla console, in un terminale, come demone, in quale runlevel ecc.)
- Qualsiasi output di errore
- Ciò che fa crashare il programma, comportarsi male, non avviarsi
- C'è una soluzione?
- Qual era l'ultima versione funzionante del pacchetto, se presente?
- Cosa è cambiato per non farlo funzionare?
- Allega i log al bug ticket
Segnalare un aumento della versione; una nuova versione upstream è disponibile da un po'
- Cerca su Bugzilla prima di inviare una richiesta di bump - c'è già un bug aperto? L'albero di Portage locale è stato sincronizzato ultimamente; è già su Portage?
- Evita le richieste bump zero-day (attendere almeno 48 ore dopo l'annuncio del rilascio)
- E' stato effettivamente rilasciato da fonti upstream, o è solo contrassegnato nell'albero dei sorgenti? Alcuni progetti segnano un rilascio nell'albero molto tempo prima che venga rilasciato ufficialmente.
- Assicurati di menzionare se compila e funziona bene sulla tua architettura. Qualsiasi altra informazione utile fornita è benvenuta.
- Aggiungi un collegamento al sito Web a monte
- Fornisci un link o un elenco di bug corretti o nuove funzionalità (a volte chiamato changelog)
- Scrivi un riepilogo nella forma app-editors/vim-12.3.5 version bump
Opzioni
- Funziona una semplice copia o l'ebuild necessita di modifiche? (dipendenze modificate, file di patch obsoleti)
- Testa l'ebuild in un overlay locale prima di inviare gli allegati
- Fornire patch per le modifiche proposte all'ebuild, con una spiegazione facoltativa delle modifiche (il nome del file deve corrispondere al nuovo numero di versione, non al vecchio)
- Fornire file aggiuntivi (initd, file unit) come allegati separati (se necessario)
- Non incollare i file direttamente nei commenti; usa gli allegati.
Richiesta di un nuovo pacchetto; richiesta ebuild
Se si richiede una nuova ebuild per un software da aggiungere a Portage, è necessario trovare o diventare un manutentore per il pacchetto.
Se esiste già una segnalazione di bug per il pacchetto, puoi aiutare mantenendo aggiornate le informazioni sul pacchetto. Se aggiungi un componente -VERSION al pacchetto atom, allora questo può essere aggiornato con nuove versioni nel tempo mentre il bug report non viene mantenuto per mostrare che c'è un interesse continuo nel vederlo integrato nell'albero di portage.
Se non esiste alcuna segnalazione di bug per il pacchetto, è possibile inviare una segnalazione di bug nel progetto Gentoo Linux e nel componente Nuovo pacchetto.
Il Riepilogo della tua segnalazione di bug dovrebbe elencare un atom di pacchetto (preliminare) categoria/pacchetto, magari con un suffisso -VERSION, seguito da una breve descrizione canonica del pacchetto (la voce DESCRIZIONE variabile in un ebuild). È importante disambiguare il nome del nuovo pacchetto: se l'upstream usa nomi diversi per lo stesso software, magari un'abbreviazione oltre al nome completo, dovresti menzionarli entrambi (tutti) nel Sommario in modo che altre persone possano trovare segnalazioni di bug sullo stesso software. Se più (gruppi di) persone tengono traccia di diverse segnalazioni di bug riguardanti virtualmente la stessa richiesta di ebuild, questo raddoppierà lo sforzo di ricerca e sviluppo di ebuild e dividerà le persone che hanno un interesse comune.
Dovresti collegarti al sito web upstream (la variabile HOMEPAGE in un ebuild) usando il campo URL. Dovresti fornire un elenco di funzionalità nella Descrizione della segnalazione di bug. Questo potrebbe essere preso direttamente dal sito Web originale o da un manuale o altra documentazione e potrebbe essere utilizzato in seguito per il tag longdescription in metadata.xml.
Puoi allegare un ebuild e i relativi file che dovrebbero andare nell'albero di portage direttamente al bug report, oppure puoi usare il campo See also per fare riferimento a un git pull request .
Puoi aiutare a sviluppare il pacchetto impostando un local overlay con i tuoi ebuild, metadati, patch e altri file ausiliari. Se hai bisogno di supporto tecnico per lo sviluppo del tuo ebuild, molte persone sarebbero felici di [1].
Pacchetto XY deve essere contrassegnato stabile
For developers, the devmanual has more extensive information on stable requests.
Se un pacchetto viene compilato e funziona senza problemi sul sistema per più di 30 giorni e non è ancora contrassegnato come stabile puoi creare una richiesta stabile.
Everybody can request a stabilization. Users do not need to worry about filling all fields or details in the bug. The maintainer (or Proxied Maintainer) will CC the arches.
To request stabilization of a package, file a new bug under the Stabilization component taking care to complete two special bug fields:
Package list- a fully qualified package per line, optionally followed by a space-delimited list of architectures to target. If no architecture list is provided, all architectures inCCare assumed. Formerly, this field was calledAtoms to stabilizeand contained fully qualified atoms, which is also still supported.Runtime testing required- indicates if additional runtime testing should be performed beyond build and tests passing. If undefined the arch tester should use their best judgement
Examples:
| Summary | foo-libs/libbar-1.2.3 stabilization request |
|---|---|
| CC | amd64 x86 |
| Runtime testing required | No |
| Package list | foo-libs/libbar-1.2.3 (old syntax, still supported: =foo-libs/libbar-1.2.3) |
| Explanation |
|
| Summary | app-foo/bar-1.2.3 and app-foo/baz-4.5.6 stabilization request |
|---|---|
| CC | amd64 arm x86 |
| Runtime testing required | Yes |
| Package list | app-foo/bar-1.2.3 |
| app-foo/baz-4.5.6 amd64 x86 | |
| Explanation |
|
Kernel
File e informazioni di interesse per i rapporti di bug relativi al kernel in ordine di priorità:
- Quale kernel e versione vengono utilizzati, su quale architettura, ad es. gentoo-sources-3.4.2-r2 su x86_64
- Il file di configurazione del kernel dovrebbe essere allegato al bug report (/usr/src/linux/.config)
- Un elenco di tutti i dispositivi nel sistema può essere acquisito con lspci -k
- Devono essere allegati i file di registro durante l'inizializzazione del kernel (/var/log/dmesg o /var/log/messages)
Su richiesta, un kernel git-bisect potrebbe essere fatto per identificare le patch difettose
Supplemental information for bug reports
| Information | when needed | How to collect |
|---|---|---|
| SRC_URI reachable? | download failed | GENTOO_MIRRORS="" ebuild foo-1.2.ebuild fetch
|
| OpenGL version | Games with OpenGL | glxinfo -B
|
| linked libraries | Dependency is missing | Add missing dependency, compile, check with lddtree |
Trackers
Tracker-Bugs are virtual bugs to cluster bugs with the same topic.
Vedi anche
- Bugzilla/Guide — covers the recommended method of forensically reporting specific details of bugs within Gentoo.
- Contributing to Gentoo — explains how users can contribute to the development of Gentoo
- GitHub Pull Requests — how to contribute to Gentoo by creating pull requests on GitHub.
- Gentoo's Bugzilla site