Bugzilla/Bug report guide/it

Informazioni generali
 Rileggere il testo prima della presentazione , le modifiche non sono reversibili e il testo non può essere modificato in seguito. Ogni testo entrato in un bug report sarà inviato via e-mail immediatamente a molta gente.

 Cercare i duplicati , forse qualcun altro ha già segnalato il problema. La creazione di una nuova segnalazione è guidata, leggere attentamente le istruzioni. Una volta che la categoria è stata scelta, verrà mostrato un elenco di segnalazioni di bug recentemente inserite per evitare duplicati.


 *  Rimanere sempre sul tema  - un bug tracker viene utilizzato per rapporti tecnici e le chiacchiere dovrebbero essere evitate. Queste si possono fare nel forum, IRC o nella mailing-list.
 *  Confermare solo l'esistenza di un problema alla volta.  - Non aiuta a risolvere il problema se tu ed un'altra persona lo segnalate doppiamente. Ma se il vostro e quello dei sistemi di conferma differiscono in modo evidente e che sarebbe utile sapere, aggiungere queste informazioni.
 *  Non dirottare altri bugs.  - Se il tuo problema non si trova su nessuna discussione relativa ai bug, cerca un problema correlato o crea un nuovo report.
 *  Nessun discorso sul bugs tracker.  - Quei bugs sono meta bugs. Se si desidera aggiungere informazioni utili, aggiungerle ad un relativo sottobug o creare un nuovo bug.

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:

Problemi al momento del build

 * L'esatta versione del pacchetto nel titolo del rapporto bug; ad esempio sys-apps/package-2.3-r4
 * Se possibile, aggiungere il messaggio di errore al titolo
 * Il file di log è in
 * Se il file di log è troppo grande da caricare, comprimerlo: e caricare build.log.gz da questa directory
 * Il risultato del comando emerge --info 

Problemi durante il funzionamento
I file e le informazioni di interesse in ordine di priorità:


 * L'esatta versione del pacchetto nel titolo del rapporto bug; ad esempio sys-apps/package-2.3-r4 crashes with error: Cannot proceed...
 * Descrizione del problema, in modo che altri possano riprodurlo:
 * Come viene eseguito il programma (sulla console, in un terminale, come un demone, in quale runlevel etc.)
 * Qualsiasi messaggio di errore
 * Ciò che manda in crash il programma, comportamenti errati, non si avvia
 * C'è una soluzione?
 * Qual è stata l'ultima versione di lavoro del pacchetto, se del caso?
 * Che cosa è cambiato per renderlo non funzionante?
 * L'uscita di emerge --info
 * L'uscita di emerge -pv  per vedere rapidamente quali sono le dipendenze

Pacchetto XY è stato rilasciato in nuova versione

 * Search Bugzilla before posting a bump request - is there already a bug open? Has the local Portage tree been synced lately; is it already in Portage?
 * Avoid zero-day bump requests (wait at least 48 hours after the release announcement)
 * Has it actually been released by upstream sources, or is it just marked in the source tree? Some projects mark a release in the tree long time before it is officially released.
 * Be sure to mention if it compiles and runs well on your arch. Any other helpful information you provide is most welcome.
 * Add a link to the upstream website
 * Give a link or list of fixed bugs or new features (sometimes called changelog)
 * Write a summary in the form app-editors/vim-12.3.5 version bump


 * Se la nuova versione non ha bisogno di modifiche al contenuto della ebuild, si prega di indicarlo
 * Verificare l'ebuild in una overlay locale prima di inviare allegati
 * Fornire le patch per le modifiche degli ebuild proposte, con la spiegazione opzionale delle variazioni (il nome del file deve corrispondere al nuovo numero di versione, non a quello vecchio)
 * Fornire file aggiuntivi (initd, file unità) come allegati separati (se necessario)
 * Non incollare ebuilds o altri contenuti dei file ebuild direttamente in commenti; utilizzare gli allegati per questo


 * Does a simple copy work, or does the ebuild need changes? (changed dependencies, obsolete patch files)
 * Test the ebuild in a local overlay before submitting attachments
 * Provide patches for proposed ebuild edits, with optional explanation of changes (file name should match the new version number, not old)
 * Provide additional files (initd, unit files) as separate attachments (as needed)
 * Do not paste files directly into comments; use attachments.

Pacchetto XY dovrebbe essere in Portage

Se si richiede una nuova ebuild per un software da aggiungere a Portage, è necessario trovare o diventare un manutentore per il pacchetto:


 * Link al sito a monte nella segnalazione di bug
 * Dare un link o un elenco di caratteristiche
 * Fornire un ebuild e le patch che sono stati testati nella overlay locale (è possibile ottenere aiuto in IRC o nei forum con quello)
 * Contattare le persone su Sunrise Overlay

If no bug report exists for the package, you can file a bug report under the Gentoo Linux project and the component New package.

The Summary of your bug report should list a (preliminary) package atom category/package, perhaps with a -VERSION suffix, followed by a canonical short description of the package (the DESCRIPTION variable in an ebuild). It is important to disambiguate the name of the new package: if upstream uses different names for the same software, perhaps an abbreviation as well as the full name, you should mention both (all) of these in the Summary so that other people can find bug reports about the same software. If several (groups of) people track different bug reports about virtually the same ebuild request, this will duplicate the effort of ebuild research and development, and will divide people who have a common interest.

You should link to the upstream website (the HOMEPAGE variable in an ebuild) using the URL field. You should provide a list of features in the Description of the bug report. This may well be taken directly from the upstream website or from a manual or other documentation, and could be used later for the longdescription tag in metadata.xml.

You can attach an ebuild and related files that should go into the portage tree directly to the bug report, or you can use the See also field to refer to a git pull request.

You can help develop the package by setting up a local overlay with your ebuilds, metadata, patches and other auxiliary files. If you need technical support with your ebuild development, many people would be glad to help.

Pacchetto XY deve essere contrassegnato stabile

Un pacchetto è costruito e ha lavorato senza problemi nel sistema per più di 30 giorni, ma è ancora contrassegnato come instabile:

Kernel
File e informazioni di interesse per i rapporti di bug relativi al kernel in ordine di priorità:


 * Quale kernel e relativa versione vengono utilizzati e su quale architettura; ad esempio gentoo-sources-3.4.2-r2 on x86_64
 * Il file di configurazione del kernel deve essere allegato al bug report
 * Un elenco di tutti i dispositivi del sistema può essere acquisita con lspci -k
 * I files di log durante l'inizializzazione del kernel devono essere allegati or

Vedi anche

 * Bugzilla guide
 * Contributing to Gentoo
 * Gentoo Github - Aiutare il progetto Gentoo e considerare l'invio di un Pull Request via GitHub