Guida alla Segnalazione di Bug in Gentoo

1.  Introduzione

Prefazione

Uno dei fattori che ritarda la risoluzione di un bug è il modo con cui questo è segnalato. La presente guida è stata creata con lo scopo di poter aiutare a migliorare la comunicazione tra sviluppatori ed utenti nella risoluzione dei problemi riscontrati. La correzione dei malfunzionamenti è una parte importante, se non cruciale, del processo di garanzia di qualità ("quality assurance") per ogni progetto. Questa guida contribuirà a rendere questo un successo.

Bug!!!!

Durante l'installazione di un pacchetto o lavorando con un programma può capitare improvvisamente il peggio: trovare un bug. I bug (anomalie o malfunzionamenti) si manifestano in vari modi: come fallimenti durante l'emerge oppure segmentation fault (errori di segmentazione riguardanti l'accesso alla memoria). Qualunque sia la causa, il problema sussiste e deve essere corretto. Sono riportati qui alcuni esempi di bug riscontrabili.

$ ./bad_code `perl -e 'print "A"x100'`
Segmentation fault

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Questi errori possono essere abbastanza noiosi. Tuttavia, una volta trovati, è necessario capire cosa è opportuno fare. Le sezioni seguenti mostrano due importanti strumenti per gestire gli errori durante l'esecuzione. Successivamente, verranno brevemente illustrati gli errori di compilazione e le tecniche per gestirli. Il primo strumento per l'identificazione degli errori di esecuzione è gdb.

2.  Debug tramite GDB

Introduzione

GDB, o (G)NU (D)e(B)ugger, è un programma usato per la ricerca di errori di esecuzione che normalmente implicano la corruzione della memoria. In primo luogo, è mostrato cosa l'attività di debug richiede. Una delle cose principali da fare per effettuare il debug di un programma è l'emerge del pacchetto con la variabile d'ambiente FEATURES="nostrip". Questa previene l'eliminazione dei simboli necessari per il debug. Le impostazioni di base prevedono l'eliminazione (strip) dei simboli dai programmi, per lo stesso motivo per cui le pagine man sono compresse con gzip: risparmiare spazio su disco. Ecco un confronto che mostra la variazione della dimensione di uno stesso programma in base alla presenza o meno dei simboli per il debug:

(simboli di debug rimossi)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(simboli di debug intatti)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code

Per completezza, bad_code è il programma che verrà successivamente analizzato con gdb. Come è possibile notare, il programma senza i simboli di debug è di 3140 byte, mentre includendo questi ultimi la dimensione sale a 6364 byte con quasi un radoppio della dimensione! Possono essere fatte ancora due cose per il debug. La prima è di aggiungere l'opzione ggdb alle proprie CFLAGS e CXXFLAGS. Questa opzione aggiunge ulteriori informazioni di debug rispetto a quanto è generalmente incluso. L'effetto di questa opzione verrà mostrato nel seguito. Si riporta come /etc/portage/make.conf potrebbe apparire con le nuove opzioni aggiunte.

CFLAGS="-O1 -pipe -ggdb"
CXXFLAGS="${CFLAGS}"

Inoltre, è possibile aggiungere l'opzione debug alle USE del pacchetto, modificando eventualmente il file package.use:

# echo "category/package debug" >> /etc/portage/package.use

È possibile effettuare nuovamente l'emerge del pacchetto con le modifiche apportate:

# FEATURES="nostrip" emerge package

A questo punto i simboli di debug saranno disponibili nell'eseguibile del programma, permettendo di proseguire con l'analisi ed il debug dello stesso.

Esecuzione del programma con GDB

Si supponga di avere a disposizione un programma di nome "bad_code" e che qualche utente segnali che il programma si blocca, oltre a fornire contestualmente qualche esempio di malfunzionamento. Proseguire testando il programma con uno degli esempi forniti:

$ ./bad_code `perl -e 'print "A"x100'`
Segmentation fault

La segnalazione pervenuta pare quindi giustificata. Essendo il programma ovviamente non funzionante, si è di fronte ad un bug o malfunzionamento. A questo punto è possibile usare il programma gdb per risolvere il problema. È necessario prima eseguire gdb con l'opzione --args, e quindi dare il percorso completo del programma con i relativi parametri:

$ gdb --args ./bad_code `perl -e 'print "A"x100'`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Dovrebbe essere visibile a questo punto il prompt "(gdb)" per l'immissione dei comandi. Come prima attività è necessario eseguire il programma attraverso il comando run, ottenendo un avviso simile al seguente:

(gdb) run
Starting program: /home/chris/bad_code

Program received signal SIGSEGV, Segmentation fault.
0xb7ec6dc0 in strcpy () from /lib/libc.so.6

Dall'esempio è visibile l'avvio del programma, oltre ad una notifica di SIGSEGV, ovvero un segnale di Segmentation Fault. Questa sintomatica mostrata da GDB indica che il programma ha eseguito operazioni non valide portando alla terminazione prematura. GDB permette di vedere anche l'ultima funzione chiamata con il trace del punto in cui il programma termina. Comunque, in questo caso le informazioni mostrate non sono troppo utili, potendoci essere, come in questo caso, chiamate multiple alla funzione strcpy che rendono difficile agli sviluppatori l'individuazione della causa effettiva del problema. Nell'ottica di aiutare gli sviluppatori, è necessario produrre un backtrace. Un backtrace analizza a ritroso tutte le funzioni occorse durante l'esecuzione del programma, sino al manifestarsi del problema. Le funzioni che ritornano (senza causare malfunzionamenti) saranno mostrate in cima al backtrace. Per ottenere un backtrace, dalla linea di comando (gdb), è necessario digitare bt ottenendo un risultato simile al seguente:

(gdb) bt
#0  0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it ()
#2  0x080483ba in main ()

È possibile notare chiaramente la struttura di chiamata. La funzione main() è invocata per prima, seguita dalla funzione run_it() in cui è eseguita una chiamata alla funzione di libreria strcpy() portando al problema. Informazioni come queste aiutano gli sviluppatori a restringere lo spazio di ricerca dei problemi. Ci sono alcune segnalazioni da fare. Per iniziare, non dimenticare di abilitare i simboli di debug attraverso l'opzione FEATURES="nostrip". Con la soppressione dei simboli di debug, il risultato del backtrace sarebbe molto simile al seguente:

(gdb) bt
#0  0xb7e2cdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in ?? ()
#2  0xbfd19510 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000000 in ?? ()
#5  0xb7eef148 in libgcc_s_personality () from /lib/libc.so.6
#6  0x080482ed in ?? ()
#7  0x080495b0 in ?? ()
#8  0xbfd19528 in ?? ()
#9  0xb7dd73b8 in __guard_setup () from /lib/libc.so.6
#10 0xb7dd742d in __guard_setup () from /lib/libc.so.6
#11 0x00000006 in ?? ()
#12 0xbfd19548 in ?? ()
#13 0x080483ba in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0xb7deebcc in __new_exitfn () from /lib/libc.so.6
#17 0x00000000 in ?? ()
#18 0xbfd19560 in ?? ()
#19 0xb7ef017c in nullserv () from /lib/libc.so.6
#20 0xb7dd6f37 in __libc_start_main () from /lib/libc.so.6
#21 0x00000001 in ?? ()
#22 0xbfd195d4 in ?? ()
#23 0xbfd195dc in ?? ()
#24 0x08048201 in ?? ()

Il precedente backtrace contiene un notevole numero di etichette "??". Questo perché, senza i simboli di debug, gdb non è in grado di sapere come il programma è stato eseguito. Quindi, è di cruciale importanza che i simboli di debug non siano disabilitati. Riprendendo la già menzionata opzione -ggdb, è riportato un possibile risultato di backtrace con questa abilitata:

(gdb) bt
#0  0xb7e4bdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it (input=0x0) at bad_code.c:7
#2  0x080483ba in main (argc=1, argv=0xbfd3a434) at bad_code.c:12

È possibile notare la mole di informazioni aggiuntive disponibili per gli sviluppatori. Non solo le informazioni relative alle funzioni sono ora mostrate, ma è anche indicato il numero di riga corrispondente nel codice sorgente. Questo metodo è preferibile se è possibile avere dello spazio extra su disco. Confrontando la dimensione dei file nel caso di, rispettivamente, simboli di debug soppressi, simboli di debug non soppressi ed opzione -ggdb abilitata si ha:

(informazioni di debug rimosse)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(informazioni di debug abilitate)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
(opzione -ggdb abilitata)
-rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code

Come è possibile osservare, con l'aggiunta dell'opzione -ggdb si ottengono 13178 byte in più nella dimensione del file rispetto alla versione con i simboli di debug non soppressi. Comunque, come mostrato precedentemente, questo aumento nella dimensione del file può essere giustificato dalla presenza di informazioni di debug utili per gli sviluppatori. Il backtrace può essere salvato in un file copiando ed incollando il testo mostrato sul terminale (in caso non fosse un terminale basato su X è possibile utilizzare gpm, come illustrato nella documentazione di gpm). Una volta concluso con gdb, è possibile uscire tramite il comando quit:

(gdb) quit
The program is running. Exit anyway? (y or n) y
$

Qui termina l'introduzione all'utilizzo di gdb. L'uso di gdb permette di creare segnalazioni di bug migliori. Sono manifestabili comunque altri tipi di errori che posso causare malfunzionamenti durante l'esecuzione di un programma. Uno fra questi è un improprio accesso ai file. È possibile individuare questi tipi di problemi usando un piccolo ma efficace strumento chiamato strace.

3.  Individuazione degli errori di accesso file attraverso strace

Introduzione

I programmi usano solitamente i file per recuperare informazioni circa la configurazione, accedendo così all'hardware piuttosto che per scrivere file di log. Qualche volta può succedere che un programma tenti di accedere ad un file in modo non corretto. strace è stato sviluppato per fornire aiuto all'individuazione di tali anomalie, tracciando le chiamate di sistema (system call trace, da cui il nome) per l'accesso in memoria e a file. Ipotizziamo, ad esempio, l'esistenza di un programma chiamato foobar2, versione aggiornata di foobar. A seguito dell'aggiornamento a foobar2, si è notato che tutta la configurazione precedentemente fatta per foobar è ignorata. In foobar versione 1, la configurazione prevedeva la scrittura della stringa "foo", ma, in modo anomalo, dopo l'aggiornamento è mostrata la stringa di base "bar".

$ ./foobar2
Configuration says: bar

La precedente configurazione impostava in modo specifico la stringa a "foo". Usando strace è possibile scoprire cosa stia realmente accadendo.

Uso di strace per tracciare il problema

È possibile configurare strace per ottenere un log dei risultati delle chiamate di sistema. Per avere questo è possibile eseguire strace con l'opzione -o[file]. Usare strace su foobar2 come mostrato nell'esempio:

# strace -ostrace.log ./foobar2

L'esecuzione crea un file chiamato strace.log nel percorso corrente. L'analisi del file di log permette di ottenere il seguente risultato (parti rilevanti):

open(".foobar2/config", O_RDONLY)       = 3
read(3, "bar", 3)                       = 3

È stato identificato il problema. Qualcuno ha modificato la directory di configurazione in .foobar2 invece dell'originale .foobar. È possibile osservare inoltre che il programma ha letto come atteso la stringa "bar". In questo caso, è raccomandabile inserire nell'ebuild di foobar2 un messaggio di avviso in merito alla variazione del nome del file di configurazione. È possibile comunque copiare sul file di configurazione .foobar2 il file di configurazione .foobar, modificandolo per produrre i risultati corretti.

Conclusioni

Sin ora è stata posta attenzione sulla ricerca dei malfunzionamenti durante l'esecuzione dei programmi. Questi malfunzionamenti risultano essere problematici quando si tenta di far funzionare i propri programmi. Tuttavia, gli errori di esecuzione sono l'ultima delle preoccupazioni se già risulta impossibile compilare il programma. Si pone ora l'attenzione su come comportarsi in caso di errori durante la compilazione con emerge.

4.  Gestione degli errori di emerge

Introduzione

Gli errori di emerge, come verrà mostrato, possono essere la causa maggiore di frustrazione degli utenti. Segnalare tali errori è considerato un fatto cruciale per garantire il buon stato di salute di Gentoo. Si porta l'attenzione su un semplice ebuild, per il programma foobar2, che contiene alcuni errori di compilazione.

Valutazione degli errori di emerge

Il seguente errore è manifestato durante l'emerge di foobar2:

gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2.o foobar2.c
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1

!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

Il programma sta compilando normalmente quando il processo si arresta improvvisamente presentando un messaggio di errore. Questo particolare errore può essere suddiviso in 3 sezioni differenti: (i) i messaggi di compilazione, (ii) l'errore di compilazione (build error) ed (iii) il messaggio di errore generato da emerge. Il seguente esempio riporta le sezioni appena indicate:

(Messaggi di compilazione)
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2.o foobar2.c

(Errore di compilazione, build error)
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1

(Errore riportato da emerge)
!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

I messaggi di compilazione sono ciò che portano all'errore stesso. Spesso, è buona norma includere almeno 10 righe di informazione di compilazione in modo da permettere allo sviluppatore di comprendere dove e quando l'errore va a manifestarsi.

Assicurarsi con certezza di includere sempre i messaggi di errore in Inglese, anche se la propria lingua di sistema è qualcos'altro. E' possibile passare temporaneamente alla localizzazione Inglese anteponendo LC_ALL=C al proprio comando emerge, in questo modo:

# LC_ALL=C emerge sys-apps/foobar2

Gli errori del make sono il problema attuale e l'informazione di cui lo sviluppatore necessita. Il messaggio "make: ****" indica solitamente dove l'errore si manifesta. Normalmente è possibile copiare ed incollare le 10 linee di testo precedenti per permettere allo sviluppatore di indirizzare il problema. Tuttavia, questo potrebbe non sempre funzionare e verrà quindi mostrato brevemente un metodo alternativo.

L'errore di emerge è cosa emerge stesso intercetta come errore. Qualche volta, questo potrebbe contenere anche alcune importanti informazioni. Solitamente gli utenti commettono un errore inviando semplicemente i messaggi di errore di emerge. Questi in sé non sono molto utili, ma con l'errore emesso dal make e le informazioni di compilazione, uno sviluppatore può individuare quale applicazione e quale pacchetto sta creando effettivamente il problema. Come nota a margine, make è comunemente usato per la gestione del processo di creazione degli eseguibili dei programmi (ma non sempre). Se non è possibile individuare un messaggio di errore "make: ***", è possibile copiare nella segnalazione del problema le 20 linee precedenti l'errore. Questo dovrebbe coprire la maggior parte degli errori di compilazione. Ipotizziamo ora che gli errori siano abbastanza numerosi. Le 10 linee non saranno sufficienti per catturare tutto. A questo scopo entra in gioco la variabile PORT_LOGDIR.

emerge e PORT_LOGDIR

PORT_LOGDIR è una variabile di portage che individua una directory per separare i vari file di log di emerge. In primo luogo emerge deve essere eseguito con PORT_LOGDIR impostata sulla locazione desiderata per contenere i file di log. Ipotizzando l'esistenza della locazione /var/log/portage da usare come directory per i log:

# PORT_LOGDIR=/var/log/portage emerge cate-goria/foobar2

Ora emerge fallirà nuovamente. Tuttavia, questa volta è possibile avere un log con cui è possibile lavorare ed allegarlo alla successiva segnalazione di errore. Il contenuto della directory dei log sarà simile al seguente:

# ls -la /var/log/portage
total 16
drwxrws---   2 root root 4096 Jun 30 10:08 .
drwxr-xr-x  15 root root 4096 Jun 30 10:08 ..
-rw-r--r--   1 root root 7390 Jun 30 10:09 cate-goria:foobar2-1.0:20090110-213217.log

I nomi dei file di log seguono il formato [categoria]:[nome pacchetto]-[versione]:[data].log. Una analisi veloce al file di log mostra l'intero processo di emerge. Questo può essere allegato successivamente come verrà illustrato nella sezione sulla segnalazione dei malfunzionamenti. Ora che è stato appreso come ottenere tutte le informazioni necessarie per la segnalazione del bug, è possibile procedere così per ottenere i file da allegare alle segnalazioni. Tuttavia prima di iniziare a trattare come segnalare un problema, è necessario assicurarsi che nessun altro abbia già segnalato un problema simile. Verrà mostrato nella sezione seguente come effettuare la ricerca di problemi già segnalati da altri utenti.

5.  Ricerca delle segnalazioni mediante Bugzilla

Introduzione

Bugzilla è lo strumento usato da Gentoo per gestire le segnalazioni dei malfunzionamenti. Il Bugzilla di Gentoo è raggiungibile sia tramite protocollo HTTPS che HTTP. HTTPS è disponibile per chi è su reti insicure od è semplicemente paranoico :). Per consistenza, negli esempi a seguire verrà utilizzata la versione HTTPS. Andando all'indirizzo Gentoo Bugs è possibile avere un'idea di come è fatto il Bugzilla di Gentoo.

Una delle cose più frustranti per gli sviluppatori ed identificatori di bug è trovare segnalazioni di malfunzionamenti duplicati. Queste hanno un costo in tempo di valutazione, tempo che gli sviluppatori potrebbero usare per lavorare su problemi più importanti. Spesso questo può essere evitato con alcuni semplici metodi di ricerca. Si introduce quindi il modo per ricercare malfunzionamenti ed identificare eventuali segnalazioni simili. Per il seguente esempio, si ipotizza di usare l'errore dell'emerge del pacchetto xclass.

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Per iniziare la ricerca, è possibile andare sul Bugzilla di Gentoo.

Figura 5.1: Pagina principale del Bugzilla di Gentoo

È necessario selezionare la voce "Query Existing bug reports". La ragione per cui si debba scegliere questa opzione rispetto la ricerca base è perché la ricerca base tende a produrre risultati vaghi ostacolando spesso gli utenti ad individuare tra i risultati le segnalazioni duplicate. Una volta avviata l'interrogazione, dovrebbe essere raggiunta la pagina:

Figura 5.2: Pagina di ricerca di Bugzilla

Procedendo tramite la selezione della voce "Advanced Search" è possibile accedere alla pagina per la Ricerca Avanzata.

Figura 5.3: Pagina per la Ricerca Avanzata

La figura precedente mostra come dovrebbe apparire la pagina per la Ricerca Avanzata. Anche se può sembrare opprimente di primo acchito, si mostreranno alcune semplici aree per limitare i risultati (piuttosto vaghi) delle ricerche su Bugzilla.

Figura 5.4: Contenuto

Il primo campo è la descrizione breve del malfunzionamento. Qui è possibile inserire semplicemente il nome del pacchetto che presenta il problema. Se la ricerca non restituisce risultati, è possibile provare a rimuovere il nome del pacchetto nel caso nessuno lo abbia inserito nel sommario (cosa altamente improbabile, ciò nonostante sono stati riscontrati una buona dose di bug inconsueti).

Prodotto (Product), Componente (Component) e Versione (Version) dovrebbero essere impostati ai valori di base. Ciò impedisce di essere troppo specifici e di non individuare alcuna segnalazione.

Il Commento (Comment) è la parte più importante. È da usare per elencare ciò che appare essere una istanza specifica dell'errore. Inoltre, dovrebbe essere filtrato ogni simbolo di punteggiatura per impedire che Bugzilla possa interpretare i risultati dei commenti in modo errato. Il seguente è un esempio di errore di emerge del pacchetto xclass:

menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
(Rimuovere gli apici ' ')
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu

Il precedente esempio è abbastanza specifico su dove trovare il bug senza necessità di guardare attraverso le altre segnalazioni di fallimento di compilazione di xclass.

URI, Whiteboard e Keywords possono essere ignorate. Ciò che è stato inserito sin ora dovrebbe essere sufficiente per individuare il bug. Bisogna comunque prestare attenzione a quanto inserito:

Figura 5.5: Modulo di ricerca completo

È possibile ora premere il tasto Search (Ricerca) ottenendo il risultato seguente:

Figura 5.6: Risultati della ricerca

Solo due segnalazioni! È possibile selezionare la prima segnalazione con la sufficiente sicurezza che sia quella per cui è stata fatta la ricerca.

Figura 5.7: Segnalazione problema localizzata

Non solo la segnalazione individuata è quella cercata, ma è anche stata risolta. Controllando l'ultimo commento è possibile apprendere la soluzione e sapere come fare per risolvere il problema. Ora, verrà mostrato cosa sarebbe accaduto se non fosse stata utilizzata la ricerca avanzata.

Figura 5.8: Risultato ricerca base

4 segnalazioni aggiuntive! Sarebbero state ovviamente ancora maggiori per pacchetti più grossi. Tuttavia, tramite questi semplici strumenti, è possibile limitare in modo significativo la ricerca per provare e localizzare una specifica segnalazione di malfunzionamento.

Conclusioni

Ipotizzando di aver cercato senza riuscire ad individuare alcun rapporto relativo al malfunzionamento. Ci si ritrova a questo punto un nuovo malfunzionamento, o comunque un malfunzionamento non segnalato. Verrà mostrato il processo di segnalazione di malfunzionamenti per la sottomissione di nuovi bug.

6.  Segnalazione dei malfunzionamenti

Introduzione

In questo capitolo, sarà illustrato come usare Bugzilla per segnalare nuovi bug. Andando all'indirizzo Gentoo Bugs verrà mostrata al seguente pagina:

Figura 6.1: Pagina principale di Bugzilla

Premere su "Report a Bug - Using the guided format".

Figura 6.2: Selezione prodotto

Come è possibile osservare, maggiore enfasi è stata posta sull'inserimento della segnalazione di malfunzionamento nel posto giusto. La categoria Gentoo Linux è dove la maggior parte dei malfunzionamenti andrebbe segnalata.

Nonostante questo, qualche utente invierà segnalazioni di malfunzionamento degli ebuild nella categoria Portage Development (nell'assunzione che il team di portage gestisca anche l'albero dei pacchetti in portage) o nella categoria Gentoo Infrastructure o infra (nell'assunzione che infra abbia accesso ai mirror e rsync potendo apportare correzioni direttamente). Questo è semplicemente come non dovrebbe funzionare.

Un'altra comune idea sbagliata avviene con la segnalazione di errori relativamente alla Documentazione. Per esempio, un utente trova un errore nella Documentazione di Catalyst. La tendenza generale è di compilare il form di segnalazione sotto la voce Documentazione Utente, che è assegnata al GDP (Gentoo Documentation Project), quando invece dovrebbe andare ad un membro del gruppo di Release Engineering. Come regola di buon senso, solo la documentazione sotto http://www.gentoo.org/doc/* è di competenza del GDP. Mentre quella sotto http://www.gentoo.org/proj/* è di competenza dei rispettivi gruppi di sviluppo.

Il malfunzionamento sarà segnalato nella sezione Gentoo Linux essendo un bug relativo ad un ebuild. Selezionando la voce Gentoo Linux verrà presentato il processo di inserimento passo-passo, procedendo quindi con il passo 1...

Figura 6.3: Formato Guidato: Passo 1

Il primo passo è molto importante (come indicato anche dal testo in rosso). Qui è dove cercare per verificare se altri utenti non abbiamo avuto ancora lo stesso problema. Se si evita questo passo ed è presente già un altro bug segnalato simile a quello che si vuol inserire, allora questo verrà etichettato come DUPLICATE (DUPLICATO) facendo sprecare quantità di sforzo per la QA (Quality Assurance/Garanzia di Qualità). Per dare un'idea, il numero dei bug che sono depennati sopra sono tutti bug duplicati. Andando al passo 2 è possibile fornire le informazioni inerenti alla segnalazione del bug.

Informazioni Richieste

Figura 6.4: Informazioni base

Le informazioni richieste sono:

• Primo, è presente la voce Product (Prodotto). Il prodotto limiterà la segnalazione ad una specifica area di Gentoo, come Bugzilla (per i bug relativi a bugs.gentoo.org), Docs-user (per le correzioni della Documentazione Utente) o Gentoo Linux (per malfunzionamenti degli ebuild e problemi simili).
• La voce Component (Componente) è dove si verifica esattamente il problema, più specificatamente quale parte del prodotto selezionato è affetta da malfunzionamento. Questo campo rende la classificazione più facile.
• La voce Hardware platform (Piattaforma hardware) indica su quale architettura si manifesta l'anomalia. Se si sta eseguendo su una SPARC, si dovrebbe indicare SPARC.
• La voce Operating System (Sistema Operativo) indica quale è il sistema operativo usato. Essendo Gentoo considerata una "Meta-distribuzione" potrebbe essere eseguita su altri sistemi operativi oltre al canonico Linux.

Per il bug di esempio, verranno inserite le seguenti informazioni:

• Product - Gentoo Linux (essendo un problema di ebuild)
• Component - Application (è un problema di una applicazione, foobar2)
• Hardware Platform - All (Questo problema è indipendente dalla piattaforma)
• Operation System - All (Potrebbe occorre su ogni tipo di sistema operativo)

Figura 6.5: Informazioni base completate

• Il Build Identifier è essenzialmente l'User Agent del browser utilizzato per la segnalazione del bug (per scopi di tracciamento). Questo valore può essere lasciato così com'è.
• La URL è opzionale ed è usata per puntare a informazioni rilevanti presenti su un altro sito (bugzilla principale del programma, note di rilascio sulla pagina principale del pacchetto, ecc...). Non si deve mai utilizzare l'URL per puntare a copie dei messaggi d'errore, log, risultati di emerge --info, schermate di esempio od informazioni simili. Piuttosto, queste informazioni andrebbero messe in allegato alla segnalazione del bug.
• Nel Summary (Riassunto/Sommario), dovrebbero essere inserite la categoria del pacchetto, il nome ed il numero di versione.

Non includere la categoria nel sommario non è proprio un errore, ma è comunque raccomandato farlo. Non includere il nome del pacchetto, comunque, non permette di capire per cosa la segnalazione di bug è stata aperta, e verrà richiesto successivamente. Il numero di versione è importante per gli utenti che andranno a cercare il bug successivamente. Se 20 utenti segnalassero bug ma senza che nessuno di loro indicasse il numero di versione, come potrebbero gli utenti effettuare ricerche per bug simili? Sarebbe necessario guardare all'interno di ogni singola segnalazione, cosa non molto difficile da fare per 20 segnalazioni, ma se fossero 200... non sarebbe affatto facile. Dopo tutte le informazioni del pacchetto, bisognerebbe includere anche una piccola descrizione dell'incidente. Ecco un esempio:

Figura 6.6: Sommario

Queste semplici regole possono rendere la gestione della segnalazione di bug molto più facile. Il passo successivo sono i dettagli. Qui verranno inserite le informazioni inerenti il malfunzionamento. Un esempio di inserimento dei dettagli:

Figura 6.7: Inserimento dettagli

Ora gli sviluppatori sono a conoscenza che è stata inserita una segnalazione di malfunzionamento, potendo quindi provare a riprodurlo. La riproducibilità indica quanto un problema sia ricorrente. Nell'esempio, l'errore può essere riprodotto ogni volta semplicemente eseguendo foobar2. Si inseriscono le informazioni:

Figura 6.8: Riproducibilità

È stato spiegato come è possibile trovare il bug. Il passo successivo è spiegare quali siano stati gli effetti ottenuti e quali sarebbero dovuti essere.

Figura 6.9: Risultati

È possibile fornire informazioni aggiuntive. Queste possono essere informazioni come stack trace, sezioni dei log di strace, e cosa molto importante il risultato del comando emerge --info. Il seguente esempio mostra l'inserimento di informazioni aggiuntive:

Figura 6.10: Informazioni aggiuntive

Infine andrà selezionata la severità (Severity) del malfunzionamento, facendo attenzione su questo aspetto. In molti casi è GIUSTO lasciare questo valore inalterato demandando a qualcun altro l'aumento o la diminuzione. Comunque, se si aumenta la severità di un malfunzionamento, non si trascuri il leggerlo con attenzione assicurandosi di non fare un errore. Nel seguito sono illustrati i vari livelli di severità.

• Blocker (Bloccante) - Il programma semplicemente non vuole installarsi oppure è un impedimento maggiore per il sistema. Per esempio un problema su baselayout che impedisce l'avvio del sistema andrebbe certamente marcato come "Blocker".
• Critical (Critico) - Il programma ha perso dati o ha seri problemi nella gestione della memoria durante l'esecuzione. Per esempio, un programma come net-tools che fallisce la compilazione può essere marcato come critico. Non impedisce l'avvio del sistema, ma è essenziale per l'uso quotidiano del sistema.
• Major (Importante) - Il programma si pianta, ma nulla che possa causare danneggiamenti severi del sistema o perdita di informazione.
• Minor (Minore) - Il programma si pianta ma ci sono soluzioni tampone (workaround).
• Normal (Normal) - Impostazione base. Nell'insicurezza è bene lasciare questa impostazione a meno che non sia un nuovo ebuild od una modifica di aspetto, (come spiegato sotto per ulteriori informazioni).
• Trivial (Triviale) - Cose che possono essere come parole scritte male o pulizia degli spazi bianchi.
• Enhancement (Miglioramento) - Una richiesta per abilitare una nuova caratteristica in un programma o più specificatamente un nuovo ebuild

Figura 6.11: Severità

In questo esempio verrà impostata a Normal (Normale).

Ora è possibile sottomettere la nuova segnalazione di malfunzionamento premendo sulla casella "Submit Bug Report", quindi si potrà vedere il nuovo bug segnalato. Vedere il Bug 97561 per un esempio di risultato. È stato inserito il bug! Verrà mostrato come sarà trattato.

Richieste Zero-day

Sin ora, è stato mostrato cosa fare per segnalare un malfunzionamento. È ora mostrato cosa è necessario non fare.

Supponendo di seguire con attenzione la pianificazione di un progetto, ed accedendo alla pagina web del progetto si nota il rilascio di una nuova versione da pochi minuti! La maggior parte degli utenti accederebbe velocemente al Bugzilla di Gentoo per segnalare la disponibilità della nuova versione, chiedendo di aggiungerla prima possibile al Portage. Questo è esattamente ciò che non andrebbe fatto. Questo tipo di richiesta è chiamato zero-day bump request (o 0-day), essendo fatta lo stesso giorno del rilascio della nuova versione.

Perché aspettare? In primo luogo, è abbastanza fastidioso chiedere agli sviluppatori di tralasciare quello che stanno facendo solo per aggiungere una nuova versione uscita da appena 15 minuti. La richiesta zero-day sarà marchiata come INVALID (Invalida) o LATER (Successivamente), poiché gli sviluppatori sono già occupati nella risoluzione dei problemi. In secondo luogo, gli sviluppatori sono solitamente informati in anticipo relativamente ai rilasci delle nuove versioni, dato che seguono da vicino il progetto principale. In molti casi, avranno già aperto un bug, o potrebbero aver già aggiunto il pacchetto nel Portage come pacchetto mascherato (masked package).

Essere intelligenti quando si prova e si richiedono nuove versione dei pacchetti. Ricercare con Bugzilla prima di inviare una richiesta di aggiunta: è stato già aperto un bug? Il sistema è stato sincronizzato di recente; è già nel Portage? È stato realmente rilasciato dagli sviluppatori principali? Il buonsenso comune è sufficiente, e sarà apprezzato dagli sviluppatori che hanno già un buon carico di lavoro. Se sono passati molti giorni dal rilascio e nella sicurezza che non ci siano già altre richieste aperte relativamente alla nuova versione (e che non sia ancora nel Portage), allora è possibile aprire una nuova segnalazione, menzionando se il pacchetto compila ed è eseguibile sulla propria architettura. Ogni altra informazione fornita è comunque benvenuta.

Per vedere le ultime versioni dei pacchetti preferiti nel Portage, allora è sempre bene compilare segnalazioni con intelligenza.

7.  Lavorare con il malfunzionamento

Osservando la segnalazione di malfunzionamento, è possibile vedere le informazioni fornite sino al passo precedente. È da notare che la segnalazione è stata assegnata a bug-wranglers@gentoo.org. Questo è l'assegnatario di base per le segnalazioni di malfunzionamento inerenti le componenti applicative (Application component).

Figura 7.1: Nuove informazioni base

I dettagli inseriti relativi al malfunzionamento sono ora disponibili.

Figura 7.2: Dettagli relativi al nuovo bug

Comunque, bug-wranglers (solitamente) non correggerà il problema, pertanto bisognerà ri-assegnarlo a qualcuno che può farlo (oppure lasciare che sia bug-wranglers ad effettuare la ri-assegnazione ). Per fare questo questo è possibile usare il file metadata.xml del pacchetto, che è possibile trovare in /usr/portage/category/package/metadata.xml. Qui è mostrato il file metadata.xml relativo a foobar2.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<herd>chriswhite</herd>
<maintainer>
<email>chriswhite@gentoo.org</email>
<name>Chris White</name>
</maintainer>
<longdescription lang="en">
Foobar2 is a package that uses a configuration file to display a word.
</longdescription>
</pkgmetadata>

Notare la sezione relativa al maintainer. Questa elenca i mantenitori del pacchetto, in questo caso Chris White (autore di questo documento). La email riportata è chriswhite@gentoo.org. Queste informazioni saranno usate per ri-assegnare il bug alla giusta persona. Fatto questo, premere Reassign bug to e riempire con la email.

Figura 7.3: Riassegnazione della segnalazione di malfunzionamento

Quindi premere il tasto "Commit" affinché le informazioni siano aggiornate. Il malfunzionamento è stato riassegnato a Chris White. Subito dopo, è possibile notare la risposta da parte del mantenitore. Viene richiesto di vedere un log di strace per mostrare come il programma sta accedendo al file di configurazione. Seguire a tale scopo le istruzioni all'uso di strace fornite nella prima parte del documento. Ottenute le informazioni bisogna allegarle alla segnalazione di malfunzionamento. Per ottenere questo, premere "Create A New Attachment" (Crea un nuovo allegato).

Figura 7.4: Nuovo allegato

È possibile allegare il log. Si procede per gradi.

• File - Questa è la locazione del file nella propria macchina. In questo esempio, la locazione di strace.log. Usare il tasto "Browse..." per selezionare il file, od inserire direttamente il percorso del file nel campo testuale.
• Description (Descrizione) - Descrizione di poche parole dell'allegato. Verrà inserito il file di log di strace.log in quanto autoesplicativo.
• Content Type (Tipo di contenuto) - Tipo del file allegato.
• Obsoletes (Rende obsoleto) - Se ci sono allegati inviati in precedenza, questa opzione permette di dichiararli obsoleti. Non avendo precedenti allegati, è trascurabile.
• Comment (Commento) - Commenti che saranno visibili con l'allegato. È possibile approfondire e integrare qui l'allegato, se necessario.

Riguardo al Content Type, ci sono alcuni dettagli. È possibile selezionare la voce "patch" per sottomettere una patch. Atrimenti, è possibile chiedere a Bugzilla di determinare il tipo del file in automatico tramite la voce "auto-detect" (sconsigliato). Le altre opzioni sono "select form list" per selezionare da una lista, che è la più usata di frequente. Per la maggior parte degli allegati è possibile usare il tipo testo (text/plain) ad eccezione dei file binari come le immagini (per cui è possibile usare image/gif, image/jpeg o image/png in funzione del tipo) e dei file compressi come .tar.bz2 (per cui è possibile usare il tipo application/octet-stream).

Figura 7.5: Nuovo allegato completato

Sottomesso il strace.log si avranno effetti nella segnalazione di malfunzionamento.

Figura 7.6: Allegato strace log

Come è stato accennato prima, a volte gli ebuild segnalano nell'errore di emerge di allegare un qualche file. L'esempio seguente mostra un possibile messaggio di errore.

configure: error: PNG support requires ZLIB. Use --with-zlib-dir=<DIR>

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/config.log

!!! ERROR: dev-php/php-5.0.3-r1 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.

È raccomandabile allegare nella segnalazione di malfunzionamento ogni file menzionato nell'errore.

Qualche volta uno sviluppatore potrebbe chiedere di allegare un diff oppure una patch per un file. Un file diff può essere ottenuto attraverso:

$ cp file file.old
$ nano file
$ diff -u file.old file

Per i sorgenti C/C++, è aggiunta l'opzione -p per mostrare quale funzione chiama il codice su cui il diff si applica:

$ cp file.c file.c.old
$ nano file.c
$ diff -up file.c.old file.c

Il gruppo della documentazione potrebbe richiedere la combinazione di opzioni -Nt con -u, che principalmente hanno a che fare con l'espansione delle tabulazioni. I comandi seguenti generano un diff di questo tipo:

$ cp file.xml file.xml.old
$ nano file.xml
$ diff -Nut file.xml.old file.xml

Il diff è stato dunque generato. Durante la creazione del diff, è possibile che altri utenti trovino la segnalazione di malfunzionamento attraverso una ricerca con il Bugzilla di Gentoo. In caso fossero interessati all'evoluzione del malfunzionamento, allora è possibile inserire la mail nel campo "Add CC" come mostrato sotto. È possibile tenere traccia di altri bug attraverso lo stesso meccanismo.

Figura 7.7: Aggiunta di una email in CC:

Dopo tutto questo lavoro, la segnalazione di malfunzionamento può essere marchiata con vari stati. Questo è solitamente fatto dagli sviluppatori di Gentoo e qualche volta dall'utente che ha segnalato il bug stesso. Di seguito sono riportati i possibili stati che una segnalazione può attraversare durante la sua vita.

• UNCONFIRMED (Non Confermata) - Generalmente questa opzione non si vede spesso. Questa significa che l'utente ha aperto una segnalazione di malfunzionamento attraverso il metodo avanzato e non era certo che fosse un reale malfunzionamento.
• NEW (Nuova) - Le segnalazioni appena aperte sono considerate nuove.
• ASSIGNED (Assegnata) - Quando la segnalazione è stata validata dalla persona a cui è stata assegnata, solitamente riceve lo stato ASSIGNED finché il problema non è risolto. Questa permette di sapere che la segnalazione è stata accettata come valida.
• REOPENED (Riaperta) - Qualcuno ha risolto un bug ma la soluzione non sembra fattibile o comunque il problema persiste. A questo punto, è possibile riaprire la segnalazione. Non si deve abusare di questa opzione. Se uno sviluppatore chiude un bug una seconda o terza volta, probabilmente il problema è stato risolto.
• RESOLVED (Risolta) - È stata presa una sicura decisione sul bug. Solitamente passa per lo stato FIXED per indicare che il bug è stato risolto ed il problema è chiuso anche se altre varie soluzioni sono possibili. Questo aspetto verrà approfondito successivamente.
• VERIFIED (Verificata) - Sono state effettuate le fasi per verificare che la segnalazione sia corretta. Questo è solitamente un fatto di QA.
• CLOSED (Chiusa) - Essenzialmente significa che il bug è chiuso definitivamente e verrà sepolto sotto il flusso senza fine dei nuovi malfunzionamenti.

Nel seguito di questo documento, verrà prima trovato un errore nel log di strace, questo verrà corretto e la segnalazione verrà posta come RESOLVED FIXED menzionando che nella nuova versione del programma è stata modifica la locazione dei file di configurazione. Verrà aggiornato l'ebuild con un messaggio di avviso a proposito questo. Il malfunzionamento ora è risolto e si ottiene la seguente schermata:

Figura 7.8: Malfunzionamento risolto

Poco sotto, verrà mostrato quanto segue:

Figura 7.9: Opzioni del bug

Ciò dà l'opzione per la riapertura della segnalazione se desiderato (cioè lo sviluppatore pensa che sia risolto ma non lo è per l'utente). Il malfunzionamento è ora ufficialmente risolto! Tuttavia possono presentarsi tipi di soluzioni differenti. Ecco una piccola lista:

• FIXED (Risolto) - Il malfunzionamento è risolto, seguire le istruzioni per risolvere il problema.
• INVALID (Invalido) - Non è stato fatto qualcosa come specificatamente documentato, causando il malfunzionamento.
• DUPLICATE (Duplicato) - Non è stata usata questa guida ed è stata riportata una segnalazione duplicata.
• WORKSFORME (Funziona per me) - Lo sviluppatore/utente assegnatario della segnalazione non può riprodurre l'errore.
• CANTFIX (Non risolvibile) - Qualcosa non può essere risolta per certe circostanze. Queste circostanze saranno segnalate alla persona che ha preso la segnalazione.
• WONTFIX (Non si vuole risolvere) - Questo è usualmente applicato ai nuovi ebuild od alle richieste di nuove opzioni. Essenzialmente lo sviluppatore non vuole aggiungere certe opzioni perché non necessarie, od esistono alternative migliori, oppure la richiesta è errata. Qualche volta potrebbe essere data una soluzione per considerare il problema risolto.
• UPSTREAM (Al progetto principale) - Il malfunzionamento non può essere risolto dagli sviluppatori di Gentoo, ed è richiesto che la segnalazione sia inviata agli sviluppatori che attualmente sviluppano il programma. La comunicazione con gli sviluppatori originali del programma può avvenire in alcuni modi. Questi includono mailing-list, canali IRC, oltre a sistemi per la segnalazione di malfunzionamenti (come Bugzilla). Se non si è sicuri come contattarli è possibile chiederlo nella segnalazione in modo che qualcuno possa indicare la via migliore.

Qualche volta, prima che il malfunzionamento possa essere risolto, uno sviluppatore potrebbe richiedere di testare un ebuild aggiornato. Nel capitolo successivo si analizzeranno gli ebuild per il test.

8.  Ebuild di test

Ottenere i file

Ipotizzando di aver segnalato di recente un malfunzionamento per la correzione della compilazione di foobar2, ora gli sviluppatori potrebbero trovare quale sia il problema e potrebbero avere anche bisogno che l'utente provi direttamente il nuovo ebuild per loro, in modo da poter essere sicuri che funzioni bene:

Figura 8.1: Richiesta di test dell'ebuild

Qui viene usato un vocabolario piuttosto confuso. In primo luogo, verrà mostrato cosa è un overlay. Un overlay è una directory speciale come /usr/portage, la cui differenza è che quando si esegue il comando emerge --sync, i file contenuti non sono cancellati. Fortunatamente, una directory speciale /usr/local/portage è creata per questo scopo. È possibile impostare l'overlay del portage in /etc/portage/make.conf aprendolo con l'editor di testo preferito ed aggiungendo le seguenti righe alla fine:

PORTDIR_OVERLAY="/usr/local/portage"

Si vogliono creare le directory opportune per inserire l'ebuild da testare ipotizzando di metterlo in sys-apps/foobar2. Nel secondo commento della segnalazione è richiesta una directory files in cui copiare la patch. Le directory dei file ogni altro file che non sia incluso nell'archivio standard (patch, script di init.d, ecc...). Questa è la sottodirectory files nella directory del pacchetto stesso. Per generare questa directory:

# mkdir -p /usr/local/portage/sys-apps/foobar2/files

È possibile andare avanti e scaricare i file. Primo, scaricare l'ebuild nella directory /usr/local/portage/sys-apps/foobar2, quindi aggiungere la patch in /usr/local/portage/sys-apps/foobar2/files. È possibile proseguire con la verifica dell'ebuild.

Verifica dell'ebuild

Il processo per creare un ebuild usabile da emerge è molto semplice. Bisogna creare un file Manifest per l'ebuild. Questo può essere fatto con il comando ebuild eseguito come segue:

# ebuild foobar2-1.0.ebuild manifest
>>> Creating Manifest for /usr/local/portage/sys-apps/foobar2

È possibile verificare l'ebuild vedendo se funziona come dovrebbe.

# emerge -pv foobar2

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] sys-apps/foobar2-1.0  0 kB [1]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage

Sembra che abbia funzionato come dovrebbe. Notare il testo "[1]" alla fine della linea "[ebuild]". Questo punta a /usr/local/portage, che contiene l'overlay creato poco fa. Proseguire installando il pacchetto tramite emerge.

# emerge foobar2
 Calculating dependencies ...done!
(informazioni di compilazione tagliate)
>>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
 * Applying foobar2-1.0-Makefile.patch ...                                    [ ok ]
(informazioni di compilazione tagliate)
>>> Merging sys-apps/foobar2-1.0 to /
>>> chris +sandbox(preinst)
--- /usr/
--- /usr/bin/
>>> /usr/bin/foobar2

Nella prima sezione è stato visto come dovrebbe avvenire l'emerge. Nella seconda è stato mostrato come la patch fornita sia stata applicata con successo con il messaggio di stato "[ ok ]" posto a destra della riga. L'ultima sezione mostra che il programma compila grazie alla patch funzionante. Ora è possibile andare ad informare gli sviluppatori che la patch proposta funziona e che possono eseguire l'invio della correzione sul portage.

Conclusioni

Questo conclude la guida sul funzionamento di Bugzilla, e l'autore spera che sia risultata utile all'utente. Per domande, commenti, idee riguardanti questo documento, inviare una mail all'indirizzo Chris White. Ringraziamenti speciali a moreon per la sua nota sull'opzione "-g" ed i messaggi di errore del compilatore, gli utenti del canale #gentoo-bugs per l'aiuto sul bug-wrangling, Griffon26 per le sue note sulle necessità del maintainer, robbat2 per i suggerimenti in generale e fox2mike per le correzioni e le aggiunte al documento.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.