[gentoo-docs-it] Beta bugzilla-howto.xml

public inbox for gentoo-docs-it@lists.gentoo.org
 help / color / mirror / Atom feed

* [gentoo-docs-it] Beta bugzilla-howto.xml
@ 2007-05-22 17:56 Luigi 'Comio' Mantellini
  2007-05-29 20:18 ` Davide Cendron
  0 siblings, 1 reply; 12+ messages in thread
From: Luigi 'Comio' Mantellini @ 2007-05-22 17:56 UTC (permalink / raw
  To: Traduttori Italiano Gentoo ML

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

mis cuso per il tempo biblio,

vi giro una beta del documento in oggetto, considerando che lo devo
rileggere ancora una volta per beccare errori ed altro.

Intanto se qualcuno vuole spulciare... e darmi qualche hit, benvenga.

luigi

[-- Attachment #2: bugzilla-howto.xml --]
[-- Type: application/xml, Size: 64217 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-22 17:56 [gentoo-docs-it] Beta bugzilla-howto.xml Luigi 'Comio' Mantellini
@ 2007-05-29 20:18 ` Davide Cendron
  2007-05-29 20:47   ` Luigi 'Comio' Mantellini
  2007-05-30 18:58   ` skypjack
  0 siblings, 2 replies; 12+ messages in thread
From: Davide Cendron @ 2007-05-29 20:18 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1.1: Type: text/plain, Size: 562 bytes --]

Il Tuesday 22 May 2007 19:56:02 Luigi 'Comio' Mantellini ha scritto:
> mis cuso per il tempo biblio,
>
> vi giro una beta del documento in oggetto, considerando che lo devo
> rileggere ancora una volta per beccare errori ed altro.
>
> Intanto se qualcuno vuole spulciare... e darmi qualche hit, benvenga.
>
> luigi

Ciao Luigi, ho dato una revisionata al documento, ti invio la mia versione e 
il diff rispetto alla tua :)

Ciao,

-- 
Davide Cendron

Gentoo Documentation Project
Italian Follow Up Translator

http://www.gentoo.org/doc/it/

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: bugzilla-howto.xml --]
[-- Type: text/xml; charset="iso-8859-6"; name="bugzilla-howto.xml", Size: 64357 bytes --]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v 1.10 2007/04/01 10:35:45 nightmorph Exp $ -->

<guide link="/doc/it/bugzilla-howto.xml">
<title>Guida alla Segnalazione di Bug di Gentoo</title>

<author title="Autore">
  <mail link="chriswhite@gentoo.org">Chris White</mail>
</author>
<author title="Revisione">
  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
</author>
<author title="Traduzione">
  <mail link="lmantellini@ieee.org">Luigi 'Comio' Mantellini</mail>
</author>

<abstract>
Questo documento mostra il metodo appropriato per segnalare malfunzionamenti
attraverso l'uso del Bugzilla di Gentoo.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>1.9</version>
<date>2007-04-01</date>

<chapter>
<title>Introduzione</title>
<section>
<title>Prefazione</title>
<body>

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

</body>
</section>
<section>
<title>Bug!!!!</title>
<body>

<p>
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 errori di segmento ("segmentation fault"). Qualunque sia la causa, il
problema sussiste e deve essere corretto. Sono riportati qui alcuni esempi di
bug riscontrabili.
</p>

<pre caption="Un errore in fase di esecuzione (run-time)">
$ <i>./bad_code `perl -e 'print Ax100'`</i>
Segmentation fault
</pre>

<pre caption="Un errore durante l'emerge di un pacchetto">
/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 &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. 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
</pre>

<p>
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 è <c>gdb</c>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Debug tramite GDB</title>
<section>
<title>Introduzione</title>
<body>

<p>
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'<c>emerge</c> dello stesso
con la variabile d'ambiente <c>FEATURES="nostrip"</c>. 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 <c>gzip</c>: risparmiare spazio su
disco. Ecco un confronto che mostra la variazione della dimensione di uno stesso
programma a seconda della presenza o meno dei simboli per il debug:
</p>

<pre caption="Confronto della dimensione dei file">
<comment>(simboli di debug rimossi)</comment>
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
<comment>(simboli di debug intatti)</comment>
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
</pre>

<p>
Per completezza, <e>bad_code</e> è il programma che verrà successivamente
analizzato con <c>gdb</c>. 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 ulteriori
due cose pper il debug. La prima è di aggiungere l'opzione <c>-ggdb</c> alle
<c>CFLAGS</c> ed alle <c>CXXFLAGS</c>. Questa opzione aggiunge ulteriori
informazioni di debug rispetto a quanto è generalmente incluso. L'effetto di
questa opzione verrà mostrato nel seguito. Si riporta come
<path>/etc/make.conf</path> <e>potrebbe</e> apparire con le nuove opzioni
aggiunte.
</p>

<pre caption="Esempio di configurazione make.conf">
CFLAGS="-O1 -pipe -g -ggdb"
CXXFLAGS="${CFLAGS}"
</pre>

<p>
Inoltre, è possibile aggiungere l'opzione <c>debug</c> alle USE del pacchetto,
modificando eventualmente il file <path>package.use</path>:
</p>

<pre caption="Uso di package.use per aggiungere l'opzione debug alle USE di un
pacchetto">
# <i>echo "category/package debug" >> /etc/portage/package.use</i>
</pre>

<note>
Se non fosse già stato fatto in precedenza, potrebbe essere necessario creare la
directory <path>/etc/portage</path>. Se il pacchetto ha già delle impostazioni
USE nel file <path>package.use</path>, allora è necessario proseguire con la
modifica manuale del file attraverso l'editor di testo preferito.
</note>

<p>
È possibile rieffettuare a questo punto l'emerge del pacchetto con le modifiche
apportate:
</p>

<pre caption="Riesecuzione emerge di un pacchetto con le opzioni di debug
attivate">
# <i>FEATURES="nostrip" emerge package</i>
</pre>

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

</body>
</section>
<section>
<title>Esecuzione del programma con GDB</title>
<body>

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

<pre caption="Fallimento di esecuzione del programma bad_code di esempio">
$ <i>./bad_code `perl -e 'print Ax100'`</i>
Segmentation fault
</pre>

<p>
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 <c>gdb</c> per risolvere il
problema. È necessario prima eseguire <c>gdb</c> con l'opzione <c>--args</c>, e
quindi dare il percorso completo del programma con i relativi parametri:
</p>

<pre caption="Esecuzione del programma malfunzionante attraverso GDB">
$ <i>gdb --args ./bad_code `perl -e 'print Ax100'`</i>
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".
</pre>

<note>
È possibile effettuare il debug con l'immagine di memoria del programma
(indicata solitamente con il termine core dump). Questo file immagine contiene
le stesse informazioni che il programma produrrebbe se fosse eseguito con
l'ausilio di <c>gdb</c>. Per effettuare il debug del file di immagine del
programma <c>bad_code</c>, è possibile eseguire <c>gdb ./bad_code core</c>, dove
<c>core</c> indica il nome del file immagine.
</note>

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

<pre caption="Esecuzione del programma in GDB">
(gdb) <i>run</i>
Starting program: /home/chris/bad_code

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

<p>
Dall'esempio è visibile l'avvio del programma, oltre ad una notifica di SIGSEGV,
piuttosto che un 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 <c>bt</c>
ottenendo un risultato simile al seguente:
</p>

<pre caption="Backtrace del programma">
(gdb) <i>bt</i>
#0  0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it ()
#2  0x080483ba in main ()
</pre>

<p>
È 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. Primo è dimenticare di abilitare
i simboli di debug attraverso l'opzione <c>FEATURES="nostrip"</c>. Con la
soppressione dei simboli di debug, il risultato del backtrace sarebbe molto
simile al seguente:
</p>

<pre caption="Backtrace del programma con i simboli di debug soppressi">
(gdb) <i>bt</i>
#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 ?? ()
</pre>

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

<pre caption="Backtrace del programma con l'opzione -ggdb3 abilitata">
(gdb) <i>bt</i>
#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
</pre>

<p>
È 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 <c>-ggdb</c>
abilitata si ha:
</p>

<pre caption="Confronto dimensione file con opzione -ggdb abilitata">
<comment>(informazioni di debug rimosse)</comment>
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
<comment>(informazioni di debug abilitate)</comment>
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
<comment>(flag -ggdb abilitata)</comment>
-rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code
</pre>

<p>
Come è possibile osservare, con l'aggiunta dell'opzione <c>-ggdb</c> 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 <uri link="/doc/it/gpm.xml#doc_chap4">documentazione di
gpm</uri>). Avendo concluso con <c>gdb</c>, è possibile uscire tramite il
comando <c>quit</c>:
</p>

<pre caption="Come uscire da GDB">
(gdb) <i>quit</i>
The program is running. Exit anyway? (y or n) <i>y</i>
$
</pre>

<p>
Qui si conclude l'introduzione all'utilizzo di <c>gdb</c>. L'uso di <c>gdb</c>
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 <c>strace</c>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Individuazione degli errori di accesso file attraverso strace</title>
<section>
<title>Introduzione</title>
<body>

<p>
I programmi usano solitamente i file per recuperare informazioni circa la
configurazione, accesso 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. <c>strace</c> è 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 a memoria e a file. Ipotizzando, 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".
</p>

<pre caption="foobar2 con una configurazione non valida">
$ <i>./foobar2</i>
Configuration says: bar
</pre>

<p>
La precedente configurazione impostava im modo specifico la stringa a "foo".
Usando <c>strace</c> è possibile scoprire cosa stia realmente accadendo.
</p>

</body>
</section>
<section>
<title>Uso di strace per tracciare il problema</title>
<body>

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

<pre caption="Esecuzione di foobar2 attraverso strace">
# <i>strace -ostrace.log ./foobar2</i>
</pre>

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

<pre caption="Contenuto del log di strace (parti rilevanti)">
open(".foobar2/config", O_RDONLY)       = 3
read(3, "bar", 3)                       = 3
</pre>

<p>
È stato identificato il problema. Qualcuno ha modificato la directory di
configurazione in <path>.foobar2</path> invece dell'originale
<path>.foobar</path>. È 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 <path>.foobar2</path> il file di configurazione
<path>.foobar</path>, modificandolo per produrre i risultati corretti.
</p>

</body>
</section>
<section>
<title>Conclusioni</title>
<body>

<p>
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 <c>emerge</c>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Gestione degli errori di emerge</title>
<section>
<title>Introduzione</title>
<body>

<p>
Gli errori di <c>emerge</c>, 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.
</p>

</body>
</section>
<section id="emerge_error">
<title>Valutazione degli errori di emerge</title>
<body>

<p>
Il seguente errore è manifestato durante l'<c>emerge</c> di foobar2:
</p>

<pre caption="Errore occorso 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
</pre>

<p>
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
emesso da <c>emerge</c>. Il seguente esempio riporta le sezioni appena indicate:
</p>

<pre caption="Parti del messaggio di errore">
<comment>(Messaggi di compilazione)</comment>
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

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

<comment>(Errore riportato da emerge)</comment>
!!! 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
</pre>

<p>
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.
</p>

<p>
Gli errori del <c>make</c> sono l'errore 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.
</p>

<p>
L'errore di emerge è cosa <c>emerge</c> 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 (<b>ma non sempre</b>). 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. Ipotizzando 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.
</p>

</body>
</section>
<section>
<title>emerge e PORT_LOGDIR</title>
<body>

<p>
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 <path>/var/log/portage</path> da usare
come directory per i log:
</p>

<note>
Nella configurazione predefinita, la directory <path>/var/log/portage</path> non
esiste, e dovrà essere creata esplicitamente. In caso non fosse creata, portage
fallirà la scrittura dei file di log.
</note>

<pre caption="emerge con PORT_LOGDIR configurata">
# <i>PORT_LOGDIR=/var/log/portage emerge foobar2</i>
</pre>

<p>
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:
</p>

<pre caption="Contenuto della directory PORT_LOGDIR">
# <i>ls -la /var/log/portage</i>
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 2115-foobar2-1.0.log
</pre>

<p>
I nomi dei file di log seguono il formato
[contatore]-[nome pacchetto]-[versione].log. Il contatore è una variabile
speciale che sta a significare la dichiarazione del pacchetto come n-esimo
pacchetto emerso. Questo previene la comparsa di log duplicati e la collisione
degli stessi. 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 fare così per ottenere i file da allegare alle segnalazioni. Tuttavia
prima di iniziare a trattare come segnalare un problema, è necessario
assicurarsi che nessun altro abbià già segnalato un problema simile. Verrà
mostrato nella sezione seguente come effettuare la ricerca di problemi già
segnalati da altri utenti.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Ricerca delle segnalazioni mediante Bugzilla</title>
<section>
<title>Introduzione</title>
<body>

<p>
<uri link="http://www.bugzilla.org">Bugzilla</uri> è 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
<uri link="https://bugs.gentoo.org">Gentoo Bugs</uri> è possibile avere un'idea
di come è fatto il Bugzilla di Gentoo.
</p>

<p>
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.
</p>

<pre caption="Errore emerge di 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 &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. 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
</pre>

<p>
Per iniziare la ricerca, è possibile andare sul <uri
link="https://bugs.gentoo.org/">Bugzilla di Gentoo</uri>.
</p>

<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale del
Bugzilla di Gentoo"/>

<p>
È 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:
</p>

<figure link="/images/docs/bugzie-search.png" caption="Pagina di ricerca di
Bugzilla"/>

<note>
Se si è soliti utilizzare la ricerca avanzata ("Advanced Search") in precedenza,
probabilmente la si preferirà alla ricerca base.
</note>

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

<figure link="/images/docs/bugzie-adv-search.png" caption="Pagina per la
Ricerca Avanzata"/>

<p>
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.
</p>

<figure link="/images/docs/bugzie-content.png" caption="Contenuto"/>

<p>
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, ciononostante sono stati riscontrati una buona dose di bug
inconsueti).
</p>

<p>
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.
</p>

<p>
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:
</p>

<pre caption="Contenuto della Linea di Commento">
menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
<comment>(Rimuovere gli apici ' ')</comment>
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
</pre>

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

<p>
URI, Whitboard 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:
</p>

<figure link="/images/docs/bugzie-comp-search.png" caption="Modulo di ricerca
completo"/>

<p>
È possibile ora premere il tasto Search (Ricerca) ottenendo il risultato
seguente:
</p>

<figure link="/images/docs/bugzie-search-result.png" caption="Risultati della
ricerca"/>

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

<figure link="/images/docs/bugzie-located.png" caption="Segnalazione problema
localizzata"/>

<p>
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.
</p>

<figure link="/images/docs/bugzie-basic-search-result.png" caption="Risultato
ricerca base"/>

<p>
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 sengalazione di malfunzionamento.
</p>

</body>
</section>
<section>
<title>Conclusioni</title>
<body>

<p>
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.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Segnalazione dei malfunzionamenti</title>
<section>
<title>Introduzione</title>
<body>

<p>
In questo capitolo, sarà illustrato come usare Bugzilla per segnalare nuovi bug.
Andando all'indirizzo <uri link="https://bugs.gentoo.org">Gentoo Bugs</uri>
verrà mostrata al seguente pagina:
</p>

<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale di
Bugzilla"/>

<p>
Premere su "Report a Bug - Using the guided format".
</p>

<figure link="/images/docs/bugzie-prod-select.png" caption="Selezione
prodotto"/>

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

<p>
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.
</p>

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

<note>
Verrà mostrato piuttosto un bug il cui prodotto non appartiene a Gentoo
Linux ma ma è stato segnalato sotto quest'ultimo, piuttosto che vedere un bug
che appartiene a Gentoo Linux ed è stato segnalato altrove. Mentre nessuno dei
due è preferibile, il precedente è più accettabile e comprensibile (eccetto che
per i bug relativi al sito web... si potrebbero avere qualche problema di
sorta).
</note>

<p>
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...
</p>

<figure link="/images/docs/bugzie-guide-step1.png" caption="Formato Guidato:
Passo 1"/>

<p>
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 dare le
inforamazioni inerenti alla segnalazione del bug.
</p>

</body>
</section>
<section>
<title>Informazioni Richieste</title>
<body>

<figure link="/images/docs/bugzie-basic.png" caption="Informazioni base"/>

<p>
Le informazioni richieste sono:
</p>

<ul>
  <li>
    Primo, c'è 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).
  </li>
  <li>
    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.
  </li>
  <li>
    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.
  </li>
  <li>
    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.
  </li>
</ul>

<p>
Per il bug di esempio, verranno inserite le seguenti informazioni:
</p>

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

<figure link="/images/docs/bugzie-basic-comp.png" caption="Informazioni base
completate"/>

<ul>
  <li>
    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'è.
  </li>
  <li>
    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 <c>emerge
    --info</c>, schermate di esempio od informazioni simili. Piuttosto, queste
    informazioni andrebbero messe in allegato alla segnalazione del bug.
  </li>
  <li>
    Nel Summary (Riassunto/Sommario), dovrebbero essere inserite la categoria
    del pacchetto, il nome ed il numero di versione.
  </li>
</ul>

<p>
Non includere la categoria nel sommario non è proprio un errore, ma è comunque
raccomandato farlo. Non includendo il nome del pacchetto, comunque, non permette
di capire per cosa la segnalazione di bug è stata aperta, e verrà richiesta
successivamente. Il numero di versione è importante per gli utenti che andranno
a cercare il bug successivamente. Se 20 utenti segnalassero bug senza che
nessuno di esse mettesse il numero di versione, come potrebbero gli utenti
effettuare ricerche per bug simili? Sarebbe neccessario guardare all'interno di
ogni singola segnalazione, cosa non molto difficile da fare per 20 segnalazione,
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:
</p>

<figure link="/images/docs/bugzie-summary.png" caption="Sommario"/>

<p>
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:
</p>

<figure link="/images/docs/bugzie-details.png" caption="Inserimento dettagli"/>

<p>
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:
</p>

<figure link="/images/docs/bugzie-reprod.png" caption="Riproducibilità"/>

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

<figure link="/images/docs/bugzie-results.png" caption="Risultati"/>

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

<figure link="/images/docs/bugzie-addl-info.png" caption="Informazioni
aggiuntive"/>

<p>
In fine andrà selezioneta la severità (Severity) del malfunzionamento, facendo
attenzione su questo aspetto. In molti casi è GIUSTO lascare questo valore
inalterato demandando a qualcun altro l'aumento o la diminuzione. Comunque, se
si aumentando la severità di un malfunzionamento, ci si assicuri di leggerlo
con attenzione assicurandosi di non fare un errore. Nel seguito sono illustrati
i vari livelli di severità.
</p>

<ul>
  <li>
    Blocker (Bloccante) - Il programma semplicemente non vuole installarsi
    oppure è un impedimento maggiore per il sistema. Per esempio un problema su
    <c>baselayout</c> che impedisce l'avvio del sistema andrebbe certamente
    marcato come "Blocker".
  </li>
  <li>
    Critical (Critico) - Il pogramma ha perso dati o ha seri problemi nella
    gestione della memoria durante l'esecuzione. Per esempio, un programma come
    <c>net-tools</c> che fallisce la compilazione può essere marcato come
    critico. Non impedisce l'avvio del sistema, ma è essenziale per l'uso
    quotidiano del sistema.
  </li>
  <li>
    Major (Importante) - Il programma si pianta, ma nulla che possa causare
    danneggiamenti severi del sistema o perdita di informazione.
  </li>
  <li>
    Minor (Minore) - Il programma si pianta ma ci sono soluzioni tampone
    (workaround).
  </li>
  <li>
    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).
  </li>
  <li>
    Trivial (Triviale) - Cose che possono essere come parole scritte male o
    pulizia degli spazi bianchi.
  </li>
  <li>
    Enhancement (Miglioramento) - Una richiesta per abilitare una nuova
    caratteristica in un programma o più specificatamente un <e>nuovo ebuild</e>
  </li>
</ul>

<figure link="/images/docs/bugzie-sev.png" caption="Severità"/>

<p>
In questo esempio verrà impostata a Normal (Normale).
</p>

<p>
Ora è possibile sottomettere la nuova segnalazione di malfunzionamento premendo
sulla casella "Submit Bug Report", quindi potendo vedere il nuovo bug segnalato.
Vedere il
<uri link="https://bugs.gentoo.org/show_bug.cgi?id=97265">Bug 97561</uri>
per un esempio di risultato. È stato inserito il bug! Verrà mostrato come sarà
trattato.
</p>

</body>
</section>
<section>
<title>Richieste Zero-day</title>
<body>

<p>
Sin ora, è stato mostrato cosa fare per segnalare un malfunzionamento. È ora
mostrato cosa è necessario <e>non</e> fare.
</p>

<p>
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 <b>non</b> andrebbe fatto. Questo tipo di richiesta è chiamato zero-day bump
request (o 0-day), essendo fatta lo stesso giorno del rilascio della nuova
versione.
</p>

<impo>
<b>Aspettare <e>almeno</e> 48 ore prima di segnalare una nuova versione sul
Bugzilla di Gentoo.</b> Inoltre, <e>bisogna</e> controllare prima il Bugzilla
prima di inviare la richiesta per essere sicuri che nessun altro l'abbia già
inviata, o che i mantenitori di Gentoo non se ne siano già occupati.
</impo>

<p>
Perché aspettare? In primo luogo, è abbastanza fastidioso chedere 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 n bug, o potrebbero aver già aggiunto il pacchetto nel
Portage come pacchetto mascherato (masked packege).
</p>

<p>
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 è buon riferimento, questo 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.
</p>

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

</body>
</section>
</chapter>

<chapter>
<title>Lavorare con il malfunzionamento</title>
<section>
<body>

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

<figure link="/images/docs/bugzie-new-basic.png" caption="Nuove informazioni
base"/>

<p>
I dettagli inseriti relativi il malfunzionamento sono ora disponibili.
</p>

<figure link="/images/docs/bugzie-new-details.png" caption="Dettagli relativi al
nuovo bug"/>

<p>
Comunque, bug-wranglers (solitamente) non correggerà il problema, è possibile
possibile ri-assegnato a qualcuno che può (oppure lasciare che sia bug-wranglers
a ri-assegnarlo). Per fare questo questo è possibile usare il file metadata.xml
del pacchetto, che è possibile trovare in
<path>/usr/portage/category/package/metadata.xml</path>. Qui è mostrato il file
metadata.xml relativo a foobar2.
</p>

<note>
Per poter ri-assegnare il bug è necessario essere l'autore della segnalazione
di malfunzionamento oppure un membro di alcuni gruppi speciali del Bugzilla di
Gentoo  (come gli sviluppatori di Gentoo).
</note>

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

<p>
Notare la sezione relativa al maintainer. Questa elenca i maintener 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.
</p>

<note>
Una segnalazione di malfunzionamento relativa ad un pacchetto senza file
metadata.xml dovrebbe essere assegnata a maintainer-needed@gentoo.org mentre un
pacchetto che necessita di uno Sviluppatore Gentoo per il mantenimento dovrebbe
essere assegnato a maintainer-wanted@gentoo.org.
</note>

<figure link="/images/docs/bugzie-reassign.png" caption="Riassegnazione della
segnalazione di malfunzionamento"/>

<p>
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
<c>strace</c> 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 informazion bisogna allegarle alla
segnalazione di malfunzionamento. Per ottenere questo, premere "Create A New
Attachment" (Crea un nuovo allegato).
</p>

<figure link="/images/docs/bugzie-new-attach.png" caption="Nuovo allegato"/>

<p>
È possibile allegare il log. Si procede per gradi.
</p>

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

<p>
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 <e>maggior
parte</e> degli allegati è possbile 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).
</p>

<figure link="/images/docs/bugzie-new-attach-comp.png" caption="Nuovo allegato
completato"/>

<p>
Sottomesso il <path>strace.log</path> si avranno effetti nella segnalazione di
malfunzionamento.
</p>

<figure link="/images/docs/bugzie-strace.png" caption="Allegato strace log"/>

<p>
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.
</p>

<pre caption="Esempio di richiesta di allegare un file (config.log)">
configure: error: PNG support requires ZLIB. Use --with-zlib-dir=&lt;DIR&gt;

!!! 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.
</pre>

<p>
È raccomandabile allegare nella segnalazione di malfunzionamento ogni file
menzionato nell'errore.
</p>

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

<pre caption="Creazione di un diff standard">
$ <i>cp file file.old</i>
$ <i>nano file</i>
$ <i>diff -u file.old file</i>
</pre>

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

<pre caption="diff di un sorgente C/C++">
$ <i>cp file.c file.c.old</i>
$ <i>nano file.c</i>
$ <i>diff -up file.c.old file.c</i>
</pre>

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

<pre caption="Diff per la documentazione">
$<i> cp file.xml file.xml.old</i>
$<i> nano file.xml</i>
$<i> diff -Nut file.xml.old file.xml</i>
</pre>

<p>
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.
</p>

<figure link="/images/docs/bugzie-add-email.png" caption="Aggiunta di una email
in CC:"/>

<note>
Gli indirizzi email devono essere registrati nel Bugzilla di Gentoo. Per
inserire più indirizzi email in CC basta separarli con la virgola o con lo
spazio.
</note>

<p>
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. I seguenti
sono i possibili stati che una segnalazione può attraversare durante la sua vita.
</p>

<ul>
  <li>
    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.
  </li>
  <li>
    NEW (Nuova) - Le segnalazioni appena aperte sono considerate nuove.
  </li>
  <li>
    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.
  </li>
  <li>
    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. <b>Non si deve abusare di questa opzione</b>.
    Se uno sviluppatore chiude un bug una seconda o terza volta, probabilmente
    il problema è stato risolto.
  </li>
  <li>
    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.
  </li>
  <li>
    VERFIED (Verificata) - Sono state effettuate le fasi per verificare che la
    segnalazione sia corretta. Questo è solitamente un fatto di QA.
  </li>
  <li>
    CLOSED (Chiusa) - Essenzialmente significa la morte per il malfunzionamento
    e che è stato sepolto sotto il flusso senza fine dei nuovi malfunzionamenti.
  </li>
</ul>

<p>
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:
</p>

<figure link="/images/docs/bugzie-reso.png" caption="Malfunzionamento risolto"/>

<p>
Poco sotto, verrà mostrato quanto segue:
</p>

<figure link="/images/docs/bugzie-options.png" caption="Opzioni del bug"/>

<p>
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 posso presentarsi tipi di
soluzioni differenti. Ecco una piccola lista:
</p>

<ul>
  <li>
    FIXED (Risolto) - Il malfunzionamento è risolto, seguire le istruzioni
    per risolvere il problema.
  </li>
  <li>
    INVALID (Invalido) - Non è stato fatto qualcosa come specificatamente
    documentato, causando il malfunzionamento.
  </li>
  <li>
    DUPLICATE (Duplicato) - Non è stata usata questa guida ed è stata riportata
    una segnalazione duplicata.
  </li>
  <li>
    WORKSFORME (Funziona per me) - Lo sviluppatore/utente assegnatario della
    segnalazione non può riprodurre l'errore.
  </li>
  <li>
    CANTFIX (Non risolvibile) - Qualcosa non può essere risolta per certe
    circostanze. Queste circostanze saranno segnalate alla persona che ha preso
    la segnalazione.
  </li>
  <li>
    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.
  </li>
  <li>
    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 originari del programma può avvenire in
    alcuni modi. Questi includono mail 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.
  </li>
</ul>

<p>
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.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Ebuild di test</title>
<section>
<title>Ottenere i file</title>
<body>

<p>
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 aver anche bisogno che l'utente provi direttamente il
nuovo ebuild per loro, in modo da poter essere sicuri che funzioni bene:
</p>

<figure link="/images/docs/bugzie-ebuild-request.png" caption="Richiesta di
test dell'ebuild"/>

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

<pre caption="Impostazione della variabile PORTDIR_OVERLAY">
PORTDIR_OVERLAY="/usr/local/portage"
</pre>

<p>
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 per i file in cui copiare la patch. Le
directory dei file contengono i digest (md5sum dei file per una particolare
versione del pacchetto) e 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:
</p>

<pre caption="Creazione directory per la categoria (sys-apps) ed il pacchetto
(foobar2)">
# <i>mkdir -p /usr/local/portage/sys-apps/foobar2/files</i>
</pre>

<note>
L'opzione <c>-p</c> nel comando <c>mkdir</c> crea non solo la directory che si
vuole ma anche tutte le directory superiori mancanti (in questo caso sys-apps e
foobar2).
</note>

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

</body>
</section>
<section>
<title>Verifica dell'ebuild</title>
<body>

<p>
Il processo per creare un ebuild usabile da emerge è molto semplice. Bisogna
creare un file "Manifest" ed un file per i digest per l'ebuild. Questo può
essere fatto con il comando <c>ebuild</c> eseguito come segue:
</p>

<pre caption="Creaazione del file Manifest e dei file per i digest">
# <i>ebuild foobar2-1.0.ebuild digest</i>
&gt;&gt;&gt; Generating digest file...
&lt;&lt;&lt; foobar2-1.0.tar.bz2
&gt;&gt;&gt; Generating manifest file...
&lt;&lt;&lt; foobar2-1.0.ebuild
&lt;&lt;&lt; files/digest-foobar2-1.0
&lt;&lt;&lt; files/foobar2-1.0-Makefile.patch
&gt;&gt;&gt; Computed message digests.
</pre>

<p>
È possibile verificare l'ebuild vedendo se funziona come dovrebbe.
</p>

<pre caption="Verifica attraverso l'uso di emerge -pv">
# <i>emerge -pv foobar2</i>

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
</pre>

<p>
Sembra che abbia funzionato come dovrebbe. Si noti il testo "[1]" alla fine
della linea "[ebuild]". Questo punta a <path>/usr/local/portage</path>, che
contiene l'overlay creato poco fa. Andando avanti si installa il pacchetto con
emerge.
</p>

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

<p>
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.
</p>

</body>
</section>
<section>
<title>Conclusioni</title>
<body>

<p>
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 <mail>chriswhite@gentoo.org</mail>.
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.
</p>

</body>
</section>
</chapter>
</guide>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: bugzilla-howto.xml.diff --]
[-- Type: text/x-diff; charset="iso-8859-6"; name="bugzilla-howto.xml.diff", Size: 44760 bytes --]

--- bugzilla-howto.xml.ori	2007-05-25 13:58:45.000000000 +0200
+++ bugzilla-howto.xml	2007-05-29 22:15:24.000000000 +0200
@@ -50,14 +50,14 @@

 <p>
 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 errori di segmento ("segmentation fault"). Qualunque sia la
-causa, il problema sussiste e deve essere corretto. Sono riportati qui alcuni
-esempi di bug riscontrabili.
+capitare improvvisamente il peggio: trovare un bug. I bug (anomalie o
+malfunzionamenti) si manifestano in vari modi: come fallimenti durante l'emerge
+oppure errori di segmento ("segmentation fault"). Qualunque sia la causa, il
+problema sussiste e deve essere corretto. Sono riportati qui alcuni esempi di
+bug riscontrabili.
 </p>

-<pre caption="Un errore a tempo di esecuzione (o di run-time)">
+<pre caption="Un errore in fase di esecuzione (run-time)">
 $ <i>./bad_code `perl -e 'print Ax100'`</i>
 Segmentation fault
 </pre>
@@ -93,12 +93,12 @@
 </pre>

 <p>
-Questi errori possono essere abbastanza noiosi. Tuttavia, una volta trovati,
-è necessario capire cosa è opportuno fare. Le sezioni seguenti mostrano due
+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 è <c>gdb</c>.
+Successivamente, verranno brevemente illustrati gli errori di compilazione e le
+tecniche per gestirli. Il primo strumento per l'identificazione degli errori di
+esecuzione è <c>gdb</c>.
 </p>

 </body>
@@ -115,17 +115,17 @@
 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 debuggare un programma è l'<c>emerge</c> dello stesso con la
-variabile d'ambiente <c>FEATURES="nostrip"</c>. Questa previene l'eliminazione
-dei simboli necessari per il debug. L'impostazioni di base prevedono
-l'eliminazione (strip) dei simboli dai programmi, per lo stesso motivo per cui
-le man page sono compresse con <c>gzip</c>: risparmiare spazio su disco. 
-Ecco un confronto che mostra la variazione della dimensione di uno stesso
+da fare per effettuare il debug di un programma è l'<c>emerge</c> dello stesso
+con la variabile d'ambiente <c>FEATURES="nostrip"</c>. 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 <c>gzip</c>: risparmiare spazio su
+disco. Ecco un confronto che mostra la variazione della dimensione di uno stesso
 programma a seconda della presenza o meno dei simboli per il debug:
 </p>

 <pre caption="Confronto della dimensione dei file">
-<comment>(simboli di debug strippati)</comment>
+<comment>(simboli di debug rimossi)</comment>
 -rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
 <comment>(simboli di debug intatti)</comment>
 -rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
@@ -154,7 +154,8 @@
 modificando eventualmente il file <path>package.use</path>:
 </p>

-<pre caption="Uso di package.use per aggiungere l'opzione debug alle USE di un pacchetto">
+<pre caption="Uso di package.use per aggiungere l'opzione debug alle USE di un
+pacchetto">
 # <i>echo "category/package debug" >> /etc/portage/package.use</i>
 </pre>

@@ -170,7 +171,8 @@
 apportate:
 </p>

-<pre caption="Riesecuzione emerge di un pacchetto con le opzioni di debug attivate">
+<pre caption="Riesecuzione emerge di un pacchetto con le opzioni di debug
+attivate">
 # <i>FEATURES="nostrip" emerge package</i>
 </pre>

@@ -186,9 +188,10 @@
 <body>

 <p>
-Supponendo di avere a disposizione un programma di nome "bad_code". Qualche
-utente segnala che il pogramma si pianta oltre a fornire contestualmente qualche
-esempio di malfunzionamento. Testando il programma con uno degli esempi forniti:
+Si supponfa di avere a disposizione un programma di nome "bad_code" e che
+qualche utente segnali che il programma si pianta, oltre a fornire
+contestualmente qualche esempio di malfunzionamento. Proseguire testando il
+programma con uno degli esempi forniti:
 </p>

 <pre caption="Fallimento di esecuzione del programma bad_code di esempio">
@@ -198,10 +201,10 @@

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

 <pre caption="Esecuzione del programma malfunzionante attraverso GDB">
@@ -218,16 +221,16 @@
 <note>
 È possibile effettuare il debug con l'immagine di memoria del programma
 (indicata solitamente con il termine core dump). Questo file immagine contiene
-le stesse informazioni che il programma produrrebbe se fosse eseguito con 
+le stesse informazioni che il programma produrrebbe se fosse eseguito con
 l'ausilio di <c>gdb</c>. Per effettuare il debug del file di immagine del
 programma <c>bad_code</c>, è possibile eseguire <c>gdb ./bad_code core</c>, dove
 <c>core</c> indica il nome del file immagine.
 </note>

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

 <pre caption="Esecuzione del programma in GDB">
@@ -242,13 +245,13 @@
 Dall'esempio è visibile l'avvio del programma, oltre ad una notifica di SIGSEGV,
 piuttosto che un Segmentation Fault. Questa sintomatica mostrata da GDB indica
 che il programma ha eseguito operazioni non valide portando alla terminazione
-prematura. GDB permete di vedere anche l'ultima funzione chiamata con il trace
+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, chiamte
-multiple alla funzione strcpy che ne rendono difficoltosa per gli sviluppatori
+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
+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 <c>bt</c>
@@ -273,7 +276,7 @@
 simile al seguente:
 </p>

-<pre caption="Backtrace del program con i simboli di debug soppressi">
+<pre caption="Backtrace del programma con i simboli di debug soppressi">
 (gdb) <i>bt</i>
 #0  0xb7e2cdc0 in strcpy () from /lib/libc.so.6
 #1  0x0804838c in ?? ()
@@ -329,11 +332,11 @@
 </p>

 <pre caption="Confronto dimensione file con opzione -ggdb abilitata">
-<comment>(debug symbols stripped)</comment>
+<comment>(informazioni di debug rimosse)</comment>
 -rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
-<comment>(debug symbols enabled)</comment>
+<comment>(informazioni di debug abilitate)</comment>
 -rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
-<comment>(-ggdb flag enabled)</comment>
+<comment>(flag -ggdb abilitata)</comment>
 -rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code
 </pre>

@@ -343,9 +346,9 @@
 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 termintale
-(in caso non fosse un terminale basato su X è possibile utilizzare gpm, come
-illustrato nella <uri link="/doc/en/gpm.xml#doc_chap4">documentazione di
+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 <uri link="/doc/it/gpm.xml#doc_chap4">documentazione di
 gpm</uri>). Avendo concluso con <c>gdb</c>, è possibile uscire tramite il
 comando <c>quit</c>:
 </p>
@@ -408,7 +411,8 @@
 <p>
 È possibile configurare <c>strace</c> per ottenere un log dei risultati delle
 chiamate di sistema. Per ottenere questo è possibile eseguire <c>strace</c> con
-l'opzione <c>-o[file]</c>. Applicando <c>straced</c> su foobar2:
+l'opzione <c>-o[file]</c>. Usare <c>strace</c> su foobar2 come mostrato
+nell'esempio:
 </p>

 <pre caption="Esecuzione di foobar2 attraverso strace">
@@ -432,9 +436,9 @@
 <path>.foobar</path>. È 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 copiando sul file di configurazione
-<path>.foobar2</path> il file di configurazione <path>.foobar</path>
-modificandolo per produrre i risultati corretti.
+del file di configurazione. È possibile comunque copiare sul file di
+configurazione <path>.foobar2</path> il file di configurazione
+<path>.foobar</path>, modificandolo per produrre i risultati corretti.
 </p>

 </body>
@@ -448,7 +452,7 @@
 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
-impossbile compilare il programma. Si pone ora l'attenzione su come comportarsi
+impossibile compilare il programma. Si pone ora l'attenzione su come comportarsi
 in caso di errori durante la compilazione con <c>emerge</c>.
 </p>

@@ -498,9 +502,8 @@
 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 emesso da <c>emerge</c>. Il seguente esempio riporta le sezioni appena
-indicate:
+(ii) l'errore di compilazione (build error) ed (iii) il messaggio di errore
+emesso da <c>emerge</c>. Il seguente esempio riporta le sezioni appena indicate:
 </p>

 <pre caption="Parti del messaggio di errore">
@@ -541,7 +544,7 @@
 L'errore di emerge è cosa <c>emerge</c> 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 se non sono molto utili, ma con l'errore emesso dal
+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
@@ -568,7 +571,7 @@
 </p>

 <note>
-Nella configurazione di default, la directory <path>/var/log/portage</path> non
+Nella configurazione predefinita, la directory <path>/var/log/portage</path> non
 esiste, e dovrà essere creata esplicitamente. In caso non fosse creata, portage
 fallirà la scrittura dei file di log.
 </note>
@@ -604,7 +607,7 @@
 prima di iniziare a trattare come segnalare un problema, è necessario
 assicurarsi che nessun altro abbià già segnalato un problema simile. Verrà
 mostrato nella sezione seguente come effettuare la ricerca di problemi già
-segnalati da altri utenti. 
+segnalati da altri utenti.
 </p>

 </body>
@@ -672,21 +675,23 @@
 link="https://bugs.gentoo.org/">Bugzilla di Gentoo</uri>.
 </p>

-<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale del Bugzilla di Gentoo"/>
+<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale del
+Bugzilla di Gentoo"/>

 <p>
 È 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  avviat
+ad individuare tra i risultati le segnalazioni duplicate. Una volta avviata
 l'interrogazione, dovrebbe essere raggiunta la pagina:
 </p>

-<figure link="/images/docs/bugzie-search.png" caption="Pagina di ricerca di Bugzilla"/>
+<figure link="/images/docs/bugzie-search.png" caption="Pagina di ricerca di
+Bugzilla"/>

 <note>
-Se si è soliti utilizzare la ricerca avanzata ("Advanced Search") in
-precedenza, probabilmente la si preferirà alla ricerca base.
+Se si è soliti utilizzare la ricerca avanzata ("Advanced Search") in precedenza,
+probabilmente la si preferirà alla ricerca base.
 </note>

 <p>
@@ -694,31 +699,31 @@
 accedere alla pagina per la Ricerca Avanzata.
 </p>

-<figure link="/images/docs/bugzie-adv-search.png" caption="Pagina per la Ricerca Avanzata"/>
+<figure link="/images/docs/bugzie-adv-search.png" caption="Pagina per la
+Ricerca Avanzata"/>

 <p>
 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 Bubzilla.
+su Bugzilla.
 </p>

-<figure link="/images/docs/bugzie-content.png" caption="Contentenuto"/>
+<figure link="/images/docs/bugzie-content.png" caption="Contenuto"/>

 <p>
 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).
-<!-- che vuol dire but we've seen a fair share of strange bug
-reports?-->
+improbabile, ciononostante sono stati riscontrati una buona dose di bug
+inconsueti).
 </p>

 <p>
 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. 
+e di non individuare alcuna segnalazione.
 </p>

 <p>
@@ -731,37 +736,40 @@

 <pre caption="Contenuto della Linea di Commento">
 menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
-<comment>(Remove the quotes ' ')</comment>
+<comment>(Rimuovere gli apici ' ')</comment>
 menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
 </pre>

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

 <p>
-URI, Whitboard e Keywords possono essere ignorate.  Ciò che è stato inserito sin
+URI, Whitboard 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:
 </p>

-<figure link="/images/docs/bugzie-comp-search.png" caption="Modulo di ricerca completo"/>
+<figure link="/images/docs/bugzie-comp-search.png" caption="Modulo di ricerca
+completo"/>

 <p>
 È possibile ora premere il tasto Search (Ricerca) ottenendo il risultato
 seguente:
 </p>

-<figure link="/images/docs/bugzie-search-result.png" caption="Risultati della ricerca"/>
+<figure link="/images/docs/bugzie-search-result.png" caption="Risultati della
+ricerca"/>

 <p>
-Solo due segnalazioni! È possibile selezionare la prima segnalazione con
+Solo due segnalazioni! È possibile selezionare la prima segnalazione con la
 sufficiente sicurezza che sia quella per cui è stata fatta la ricerca.
 </p>

-<figure link="/images/docs/bugzie-located.png" caption="Segnalazione problema localizzata"/>
+<figure link="/images/docs/bugzie-located.png" caption="Segnalazione problema
+localizzata"/>

 <p>
 Non solo la segnalazione individuata è quella cercata, ma è anche stata risolta.
@@ -770,7 +778,8 @@
 se non fosse stata utilizzata la ricerca avanzata.
 </p>

-<figure link="/images/docs/bugzie-basic-search-result.png" caption="Risultato ricerca base"/>
+<figure link="/images/docs/bugzie-basic-search-result.png" caption="Risultato
+ricerca base"/>

 <p>
 4 segnalazioni aggiuntive! Sarebbero state ovviamente ancora maggiori per
@@ -788,8 +797,9 @@
 <p>
 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.
+malfunzionamento, o comunque un malfunzionamento non segnalato. Verrà mostrato
+il processo di segnalazione di malfunzionamenti per la sottomissione di nuovi
+bug.
 </p>

 </body>
@@ -804,17 +814,19 @@

 <p>
 In questo capitolo, sarà illustrato come usare Bugzilla per segnalare nuovi bug.
-Andando all'indirizzo <uri link="https://bugs.gentoo.org">Gentoo Bugs</uri> 
+Andando all'indirizzo <uri link="https://bugs.gentoo.org">Gentoo Bugs</uri>
 verrà mostrata al seguente pagina:
 </p>

-<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale di Bugzilla"/>
+<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale di
+Bugzilla"/>

 <p>
 Premere su "Report a Bug - Using the guided format".
 </p>

-<figure link="/images/docs/bugzie-prod-select.png" caption="Selezione prodotto"/>
+<figure link="/images/docs/bugzie-prod-select.png" caption="Selezione
+prodotto"/>

 <p>
 Come è possibile osservare, <b>maggiore</b> enfasi è stata posta
@@ -827,14 +839,14 @@
 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.
+Gentoo Infrastructure o infra (nell'assunzione che infra abbia accesso ai mirror
+e rsync potendo apportare correzioni direttamente). Questo è semplicemente come
+non dovrebbe funzionare.
 </p>

 <p>
-Altra comune idea errata occorre con le segnalazione di errori relativamente la
-Documentazione. Per esempio, un utente trova un errore nella
+Un'altra comune idea sbagliata avviene con le segnalazione di errori
+relativamente alla Documentazione. Per esempio, un utente trova un errore nella
 <uri link="/proj/en/releng/catalyst/">Documentazione di Catalyst</uri>. La
 tendenza generale è di compilare il form di segnalazione sotto la voce
 Documentazione Utente, che è assegnata al <uri link="http://gdp.gentoo.org">GDP
@@ -850,28 +862,29 @@
 Verrà mostrato piuttosto un bug il cui prodotto non appartiene a Gentoo
 Linux ma ma è stato segnalato sotto quest'ultimo, piuttosto che vedere un bug
 che appartiene a Gentoo Linux ed è stato segnalato altrove. Mentre nessuno dei
-due è preferibile, il precedente è più accettabile e comprensibile (eccetto
-che per i bug relativi al sito web... si potrebbero avere qualche problema di
+due è preferibile, il precedente è più accettabile e comprensibile (eccetto che
+per i bug relativi al sito web... si potrebbero avere qualche problema di
 sorta).
 </note>

 <p>
 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...
+relativo ad un ebuild. Selezionando la voce Gentoo Linux verrà presentato il
+processo di inserimento passo-passo, procedendo quindi con il passo 1...
 </p>

-<figure link="/images/docs/bugzie-guide-step1.png" caption="Formato Guidato: Passo 1"/>
+<figure link="/images/docs/bugzie-guide-step1.png" caption="Formato Guidato:
+Passo 1"/>

 <p>
-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
-sengnalato 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
-dare le inforamazioni inerenti la segnalazione del bug.
+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 dare le
+inforamazioni inerenti alla segnalazione del bug.
 </p>

 </body>
@@ -929,7 +942,8 @@
   </li>
 </ul>

-<figure link="/images/docs/bugzie-basic-comp.png" caption="Informazioni base completate"/>
+<figure link="/images/docs/bugzie-basic-comp.png" caption="Informazioni base
+completate"/>

 <ul>
   <li>
@@ -955,12 +969,12 @@
 Non includere la categoria nel sommario non è proprio un errore, ma è comunque
 raccomandato farlo. Non includendo il nome del pacchetto, comunque, non permette
 di capire per cosa la segnalazione di bug è stata aperta, e verrà richiesta
-successivamente. Il numero di versione è importante per gli utenti che
-andranno a cercare il bug successivamente. Se 20 utenti segnalassero bug senza
-che alcuno mettesse il numero di versione, come potrebbero gli utenti effettuare
-ricerche per bug simili? Sarebbe neccessario guardare all'interno di ogni
-singola segnalazione, cosa non molto difficile da fare per 20 segnalazione, ma
-se fossero 200... non sarebbe affatto facile. Dopo tutte le informazioni del
+successivamente. Il numero di versione è importante per gli utenti che andranno
+a cercare il bug successivamente. Se 20 utenti segnalassero bug senza che
+nessuno di esse mettesse il numero di versione, come potrebbero gli utenti
+effettuare ricerche per bug simili? Sarebbe neccessario guardare all'interno di
+ogni singola segnalazione, cosa non molto difficile da fare per 20 segnalazione,
+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:
 </p>
@@ -970,7 +984,7 @@
 <p>
 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 insetimento dei
+informazioni inerenti il malfunzionamento. Un esempio di inserimento dei
 dettagli:
 </p>

@@ -978,10 +992,9 @@

 <p>
 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:
+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:
 </p>

 <figure link="/images/docs/bugzie-reprod.png" caption="Riproducibilità"/>
@@ -1000,14 +1013,15 @@
 mostra l'inserimento di informazioni aggiuntive:
 </p>

-<figure link="/images/docs/bugzie-addl-info.png" caption="Informazioni aggiuntive"/>
+<figure link="/images/docs/bugzie-addl-info.png" caption="Informazioni
+aggiuntive"/>

 <p>
 In fine andrà selezioneta la severità (Severity) del malfunzionamento, facendo
 attenzione su questo aspetto. In molti casi è GIUSTO lascare questo valore
 inalterato demandando a qualcun altro l'aumento o la diminuzione. Comunque, se
 si aumentando la severità di un malfunzionamento, ci si assicuri di leggerlo
-con attenzione assicurdosi di non fare un errore. Nel seguito sono illustrati
+con attenzione assicurandosi di non fare un errore. Nel seguito sono illustrati
 i vari livelli di severità.
 </p>

@@ -1019,7 +1033,7 @@
     marcato come "Blocker".
   </li>
   <li>
-    Critical (Critico) - Il pogramma ha perso dati od ha seri problemi nella
+    Critical (Critico) - Il pogramma ha perso dati o ha seri problemi nella
     gestione della memoria durante l'esecuzione. Per esempio, un programma come
     <c>net-tools</c> che fallisce la compilazione può essere marcato come
     critico. Non impedisce l'avvio del sistema, ma è essenziale per l'uso
@@ -1070,12 +1084,12 @@
 <body>

 <p>
-Sin ora, è stato mostrato cosa fare per sengnalare un malfunzionamento. È ora
+Sin ora, è stato mostrato cosa fare per segnalare un malfunzionamento. È ora
 mostrato cosa è necessario <e>non</e> fare.
 </p>

 <p>
-Supponendo di seguire con attenzione la pianificazione di un progeggo, ed
+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,
@@ -1089,12 +1103,12 @@
 <b>Aspettare <e>almeno</e> 48 ore prima di segnalare una nuova versione sul
 Bugzilla di Gentoo.</b> Inoltre, <e>bisogna</e> controllare prima il Bugzilla
 prima di inviare la richiesta per essere sicuri che nessun altro l'abbia già
-inviata, o che i maintainer di Gentoo non se ne siano già occupati.
+inviata, o che i mantenitori di Gentoo non se ne siano già occupati.
 </impo>

 <p>
 Perché aspettare? In primo luogo, è abbastanza fastidioso chedere agli
-sviluppatori di tralasciare quello che stanno facendo solo per aggiungere una 
+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
@@ -1105,16 +1119,17 @@
 </p>

 <p>
-Essere intelligenti quando si prova e si richiede 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
-è buon riferimento, questo sarà apprezzato dagli sviluppatori che hanno già un
-buon carico di lavoro. Se sono passati molti giorni dal rilascio e nella
-sicurizza 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.
+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 è buon riferimento, questo 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.
 </p>

 <p>
@@ -1139,21 +1154,23 @@
 (Application component).
 </p>

-<figure link="/images/docs/bugzie-new-basic.png" caption="Nuove informazioni base"/>
+<figure link="/images/docs/bugzie-new-basic.png" caption="Nuove informazioni
+base"/>

 <p>
 I dettagli inseriti relativi il malfunzionamento sono ora disponibili.
 </p>

-<figure link="/images/docs/bugzie-new-details.png" caption="Nedattagli relativi al nuovo bug"/>
+<figure link="/images/docs/bugzie-new-details.png" caption="Dettagli relativi al
+nuovo bug"/>

 <p>
 Comunque, bug-wranglers (solitamente) non correggerà il problema, è possibile
-possibile ri-assegnato a qualcuno che può (oppure lasciare hce sia bug-wranglers
+possibile ri-assegnato a qualcuno che può (oppure lasciare che sia bug-wranglers
 a ri-assegnarlo). Per fare questo questo è possibile usare il file metadata.xml
 del pacchetto, che è possibile trovare in
-<path>/usr/portage/category/package/metadata.xml</path>.
-Qui è mostrato il file metadata.xml relativo a foobar2.
+<path>/usr/portage/category/package/metadata.xml</path>. Qui è mostrato il file
+metadata.xml relativo a foobar2.
 </p>

 <note>
@@ -1192,17 +1209,18 @@
 essere assegnato a maintainer-wanted@gentoo.org.
 </note>

-<figure link="/images/docs/bugzie-reassign.png" caption="Riassegnamento della segnalazione di malfunzionamento"/>
+<figure link="/images/docs/bugzie-reassign.png" caption="Riassegnazione della
+segnalazione di malfunzionamento"/>

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

 <figure link="/images/docs/bugzie-new-attach.png" caption="Nuovo allegato"/>
@@ -1214,7 +1232,7 @@
 <ul>
   <li>
     File - Questa è la locazione del file nella propria macchina. In questo
-    esempio, la locazione di <path>strace.log</path>. Usare il tasto "Browse..."        
+    esempio, la locazione di <path>strace.log</path>. Usare il tasto "Browse..."
     per selezionare il file, od inserire direttamente il percorso del file nel
     campo testuale.
   </li>
@@ -1231,8 +1249,8 @@
     allegati, è trascurabile.
   </li>
   <li>
-    Comment (Commento) - Commenti che saranno visibili con l'allegato. Puoi
-    elaborare sull'allegato qui, se nessario.
+    Comment (Commento) - Commenti che saranno visibili con l'allegato. È
+    possibile approfondire qui l'allegato, se nessario.
   </li>
 </ul>

@@ -1240,7 +1258,7 @@
 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" (scogliato). Le altre opzioni sono "select form list" per
+"auto-detect" (sconsigliato). Le altre opzioni sono "select form list" per
 selezionare da una lista, che è la più usata di frequente. Per la <e>maggior
 parte</e> degli allegati è possbile usare il tipo testo (text/plain) ad
 eccezione dei file binari come le immagini (per cui è possibile usare image/gif,
@@ -1248,7 +1266,8 @@
 (per cui è possibile usare il tipo application/octet-stream).
 </p>

-<figure link="/images/docs/bugzie-new-attach-comp.png" caption="Nuovo allegato completato"/>
+<figure link="/images/docs/bugzie-new-attach-comp.png" caption="Nuovo allegato
+completato"/>

 <p>
 Sottomesso il <path>strace.log</path> si avranno effetti nella segnalazione di
@@ -1277,12 +1296,12 @@

 <p>
 È raccomandabile allegare nella segnalazione di malfunzionamento ogni file
-mensionato nell'errore.
+menzionato nell'errore.
 </p>

 <p>
-Qualche volta uno sviluppatore potrebbe chiedere di allegare un diff oppure
-una patch per un file. Un file diff può essere ottenuto attraverso:
+Qualche volta uno sviluppatore potrebbe chiedere di allegare un diff oppure una
+patch per un file. Un file diff può essere ottenuto attraverso:
 </p>

 <pre caption="Creazione di un diff standard">
@@ -1304,9 +1323,8 @@

 <p>
 Il gruppo della documentazione potrebbe richiedere la combinazione di opzioni
-<b>-Nt</b> come l'opzione <b>-u</b>. Queste essenzialmente effettuano
-l'espansione delle tabulazioni. I comandi seguenti generano un diff di questo
-tipo:
+<b>-Nt</b> con <b>-u</b>, che principalmente hanno a che fare con l'espansione
+delle tabulazioni. I comandi seguenti generano un diff di questo tipo:
 </p>

 <pre caption="Diff per la documentazione">
@@ -1318,16 +1336,17 @@
 <p>
 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 Gentto. I caso fossero interessati all'evoluzione del
+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.
 </p>

-<figure link="/images/docs/bugzie-add-email.png" caption="Aggiunta di una email in CC:"/>
+<figure link="/images/docs/bugzie-add-email.png" caption="Aggiunta di una email
+in CC:"/>

 <note>
-Gli indirizzi email devono essere registrati nel Bugzilla di Gentoo. Per 
+Gli indirizzi email devono essere registrati nel Bugzilla di Gentoo. Per
 inserire più indirizzi email in CC basta separarli con la virgola o con lo
 spazio.
 </note>
@@ -1341,7 +1360,7 @@

 <ul>
   <li>
-    UNCONFIRMED (Non Confermata) - Generalmente questa opzione non si vede 
+    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.
@@ -1359,11 +1378,11 @@
     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. <b>Non si deve abusare di questa opzione</b>.
-    Se uno sviluppatore chiude un bug una seconda o terza volte, probabilmente
+    Se uno sviluppatore chiude un bug una seconda o terza volta, probabilmente
     il problema è stato risolto.
   </li>
   <li>
-    RESOLVED (Risolta) - Una ferma decisione è stata presa sul bug. Solitamente
+    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.
@@ -1383,7 +1402,7 @@
 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 ottenendo la seguente
+a proposito questo. Il malfunzionamento ora è risolto e si ottiene la seguente
 schermata:
 </p>

@@ -1396,8 +1415,8 @@
 <figure link="/images/docs/bugzie-options.png" caption="Opzioni del bug"/>

 <p>
-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
+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 posso presentarsi tipi di
 soluzioni differenti. Ecco una piccola lista:
 </p>
@@ -1462,19 +1481,20 @@
 <p>
 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 aver anche bisogno che l'utente provi direttamente
-il nuovo ebuild per loro, in modo da poter essere sicuri che funzioni bebe:
+il problema e potrebbero aver anche bisogno che l'utente provi direttamente il
+nuovo ebuild per loro, in modo da poter essere sicuri che funzioni bene:
 </p>

-<figure link="/images/docs/bugzie-ebuild-request.png" caption="Richiesta di test dell'ebuild"/>
+<figure link="/images/docs/bugzie-ebuild-request.png" caption="Richiesta di
+test dell'ebuild"/>

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

 <p>
-Si vogliono creare le directory opportune per inserire l'ebuild da testare 
+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 per i file in cui copiare la patch. Le
 directory dei file contengono i digest (md5sum dei file per una particolare
 versione del pacchetto) e ogni altro file che non sia incluso nell'archivio
 standard (patch, script di init.d, ecc...). Questa è la sottodirectory "files"
-nella direcotry del pacchetto stesso. Per generare questa directory:
+nella directory del pacchetto stesso. Per generare questa directory:
 </p>

-<pre caption="Creazione directory per la categoria (sys-apps) ed il pacchetto (foobar2)">
+<pre caption="Creazione directory per la categoria (sys-apps) ed il pacchetto
+(foobar2)">
 # <i>mkdir -p /usr/local/portage/sys-apps/foobar2/files</i>
 </pre>

@@ -1505,7 +1526,7 @@

 <p>
 È possibile andare avanti e scaricare i file. Primo, scaricare l'ebuild nella
-directroy <path>/usr/local/portage/sys-apps/foobar2</path>, quindi aggiungere
+directory <path>/usr/local/portage/sys-apps/foobar2</path>, quindi aggiungere
 la patch in <path>/usr/local/portage/sys-apps/foobar2/files</path>. È possibile
 proseguire con la verifica dell'ebuild.
 </p>
@@ -1518,8 +1539,8 @@

 <p>
 Il processo per creare un ebuild usabile da emerge è molto semplice. Bisogna
-creare un file "Manifest" ed un file per i dgest per l'ebuild. Questo può essere
-fatto con il comando <c>ebuild</c> eseguito come segue:
+creare un file "Manifest" ed un file per i digest per l'ebuild. Questo può
+essere fatto con il comando <c>ebuild</c> eseguito come segue:
 </p>

 <pre caption="Creaazione del file Manifest e dei file per i digest">
@@ -1534,8 +1555,7 @@
 </pre>

 <p>
-È possibile verificare l'ebuild vedendo se funziona come ci si aspetta che
-faccia.
+È possibile verificare l'ebuild vedendo se funziona come dovrebbe.
 </p>

 <pre caption="Verifica attraverso l'uso di emerge -pv">
@@ -1561,10 +1581,10 @@
 <pre caption="Risultato dell'emerge">
 # <i>emerge foobar2</i>
  Calculating dependencies ...done!
-<comment>(compile info snipped)</comment>
+<comment>(informazioni di compilazione tagliate)</comment>
 >>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
  * Applying foobar2-1.0-Makefile.patch ...                                    [ ok ]
-<comment>(compile info snipped)</comment>
+<comment>(informazioni di compilazione tagliate)</comment>
 >>> Merging sys-apps/foobar2-1.0 to /
 >>> chris +sandbox(preinst)
 --- /usr/
@@ -1588,14 +1608,14 @@
 <body>

 <p>
-Questo conclude l'howto sul funzionamento di Bugzilla. Sperando che sia trovato
-utile dall'utente. Per domande, commenti, idee riguardanti questo documento,
-inviare una mail all'indirizzo <mail>chriswhite@gentoo.org</mail>.
-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.
+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 <mail>chriswhite@gentoo.org</mail>.
+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.
 </p>

 </body>

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 20:18 ` Davide Cendron
@ 2007-05-29 20:47   ` Luigi 'Comio' Mantellini
  2007-05-29 20:58     ` Davide Cendron
  2007-05-30 18:58   ` skypjack
  1 sibling, 1 reply; 12+ messages in thread
From: Luigi 'Comio' Mantellini @ 2007-05-29 20:47 UTC (permalink / raw
  To: gentoo-docs-it

Dato che il diff comprende molti allineamenti agli 80 caratteri, non
riesco ad identificare le correzioni vere e proprie.

Trovato anomalie significative? 

ciao

luigi

Il giorno mar, 29/05/2007 alle 22.18 +0200, Davide Cendron ha scritto:
> Il Tuesday 22 May 2007 19:56:02 Luigi 'Comio' Mantellini ha scritto:
> > mis cuso per il tempo biblio,
> >
> > vi giro una beta del documento in oggetto, considerando che lo devo
> > rileggere ancora una volta per beccare errori ed altro.
> >
> > Intanto se qualcuno vuole spulciare... e darmi qualche hit, benvenga.
> >
> > luigi
> 
> Ciao Luigi, ho dato una revisionata al documento, ti invio la mia versione e 
> il diff rispetto alla tua :)
> 
> Ciao,
> 
-- 
Luigi 'Comio' Mantellini

The three laws of users:

1. A user may not injure a sysadmin, or through inaction,
   allow a sysadmin to come to harm.
2. A user must obey the orders given it by sysadmins except
   where such orders would conflict with the First Law.
3. A user must protect its own existence as long as such
   protection does not conflict with the First or Second Law.

-- 
gentoo-docs-it@gentoo.org mailing list

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 20:47   ` Luigi 'Comio' Mantellini
@ 2007-05-29 20:58     ` Davide Cendron
  2007-05-29 21:44       ` Michele Caini
  0 siblings, 1 reply; 12+ messages in thread
From: Davide Cendron @ 2007-05-29 20:58 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Il Tuesday 29 May 2007 22:47:16 Luigi 'Comio' Mantellini ha scritto:
> Dato che il diff comprende molti allineamenti agli 80 caratteri, non
> riesco ad identificare le correzioni vere e proprie.
>
> Trovato anomalie significative?
>
> ciao
>
> luigi
>

Niente di particolare, a parte un pò di errori ortografici, forse dovuti alla 
fretta (succede :), e difatti la revisione da altre paia di occhi è sempre 
una buona prassi) e la frase non tradotta, di cui avevi lasciato un commento 
^_^


Volendo essere pignolo c'è solo qualche parte in cui la traduzione non è 
abbastanza fluida: se fosse possibile, ti consiglio di rileggere interamente 
il documento, e risistemare eventualmente le parti dove vedi che il discorso 
s'intrippa un pò :P (questo documento è abbastanza/molto importante, meglio 
aspettare un pò di giorni in più ma pubblicarlo al massimo del suo splendore 
8) )

Ciao,

-- 
Davide Cendron

Gentoo Documentation Project
Italian Follow Up Translator

http://www.gentoo.org/doc/it/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 20:58     ` Davide Cendron
@ 2007-05-29 21:44       ` Michele Caini
  2007-05-29 21:47         ` Luigi 'Comio' Mantellini
  2007-05-29 21:50         ` Davide Cendron
  0 siblings, 2 replies; 12+ messages in thread
From: Michele Caini @ 2007-05-29 21:44 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Se volete, posso dare un'occhiata e rivisitarlo io, correggendo e
modificando dove mi sembra ostico.
Così sono due occhi in più. Poi ovviamente liberi di applicare o scartare le
mie "patch".
Fatemi sapere, se vi interessa.

Michele

[-- Attachment #2: Type: text/html, Size: 265 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 21:44       ` Michele Caini
@ 2007-05-29 21:47         ` Luigi 'Comio' Mantellini
  2007-05-29 21:50         ` Davide Cendron
  1 sibling, 0 replies; 12+ messages in thread
From: Luigi 'Comio' Mantellini @ 2007-05-29 21:47 UTC (permalink / raw
  To: gentoo-docs-it

ok

io non posso toccarlo se non sabato/domenica. Usa la versione di
Davide (vedi mail precedente) come base di partenza.

grazie

luigi

Il 29/05/07, Michele Caini<skypjack@gmail.com> ha scritto:
> Se volete, posso dare un'occhiata e rivisitarlo io, correggendo e
> modificando dove mi sembra ostico.
> Così sono due occhi in più. Poi ovviamente liberi di applicare o scartare le
> mie "patch".
> Fatemi sapere, se vi interessa.
>
> Michele
>


-- 
Luigi 'Comio' Mantellini

The three laws of users:

1. A user may not injure a sysadmin, or through inaction,
   allow a sysadmin to come to harm.
2. A user must obey the orders given it by sysadmins except
   where such orders would conflict with the First Law.
3. A user must protect its own existence as long as such
   protection does not conflict with the First or Second Law.
--
gentoo-docs-it@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 21:44       ` Michele Caini
  2007-05-29 21:47         ` Luigi 'Comio' Mantellini
@ 2007-05-29 21:50         ` Davide Cendron
  2007-05-30 19:06           ` skypjack
  1 sibling, 1 reply; 12+ messages in thread
From: Davide Cendron @ 2007-05-29 21:50 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

Il Tuesday 29 May 2007 23:44:02 Michele Caini ha scritto:
> Se volete, posso dare un'occhiata e rivisitarlo io, correggendo e
> modificando dove mi sembra ostico.
> Così sono due occhi in più. Poi ovviamente liberi di applicare o scartare
> le mie "patch".
> Fatemi sapere, se vi interessa.
>
> Michele

Ottimo direi, magari parti dalla mia revisione, così ti risparmi il lavoro di 
correggere nuovamente gli errori ortografici.

Vai, review'em all! >:-)

-- 
Davide Cendron

Gentoo Documentation Project
Italian Follow Up Translator

http://www.gentoo.org/doc/it/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-30 18:58   ` skypjack
@ 2007-05-30 17:45     ` Luigi 'Comio' Mantellini
  2007-05-30 19:57       ` skypjack
  0 siblings, 1 reply; 12+ messages in thread
From: Luigi 'Comio' Mantellini @ 2007-05-30 17:45 UTC (permalink / raw
  To: gentoo-docs-it

Il fatto è che la versione inglese è troppo colloquiale (ma credo chesia
un "problema" di tutti i documenti).

Diventa ostico certe volte tradurre frasi che sono un semplice
intercalare.

Ho tentato di leggerlo molte volte (passo però il correttore solo alla
fine della fiera, dopo le review) per cercare di vedere quanto filare,
ma alcuni punti devo dire che è proprio dura.

Ora, leggo questa versione (vi siete aggiunti come traduttori? spero di
sì!) e nel we faccio il bugzilla (e ripasso la procedura :P).

ciao

luigi

Il giorno mer, 30/05/2007 alle 20.58 +0200, skypjack ha scritto:
> Ciao ragazzi.
> In particolare per Scen e Comio, vi allego la versione del documento
> rivisitata. In pratica, ho corretto alcuni errori ortografici che erano
> sfuggiti (spero di averli tolti tutti) e SENZA BASARMI SUL TESTO
> INGLESE cercato di rendere più "leggibile" il tutto, nel senso che ho
> introdotto sinonimi per eliminare ripetizioni, riorganizzato alcune
> frasi che mi sembravano un po' contorte e cose simili.
> Non ho modificato ne stravolto il documento, tranquilli.
> La traduzione, per altro, non era niente male, molto comprensibile a
> parer mio, ma ho cercato di immedesimarmi in uno che usa bugzilla per
> la prima volta e che quindi legge la guida per imparare (che poi, sarei
> io!! ;-) .
> Spero di essere stato di aiuto. ve la allego.
> Per il diff, scusate se vi chiedo di farvelo da voi, ma vado di
> ultra-fretta e ho finito appena in tempo di rileggerla (mi sono accorto
> solo ora che è già tardissimo!).
> 
> Ciao,
> Michele
> 
> ps: il diff se volete averlo va fatto con la versione di Scen, sono
> partito da quella, come avete suggerito.
-- 
Luigi 'Comio' Mantellini

The three laws of users:

1. A user may not injure a sysadmin, or through inaction,
   allow a sysadmin to come to harm.
2. A user must obey the orders given it by sysadmins except
   where such orders would conflict with the First Law.
3. A user must protect its own existence as long as such
   protection does not conflict with the First or Second Law.

-- 
gentoo-docs-it@gentoo.org mailing list

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 20:18 ` Davide Cendron
  2007-05-29 20:47   ` Luigi 'Comio' Mantellini
@ 2007-05-30 18:58   ` skypjack
  2007-05-30 17:45     ` Luigi 'Comio' Mantellini
  1 sibling, 1 reply; 12+ messages in thread
From: skypjack @ 2007-05-30 18:58 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Ciao ragazzi.
In particolare per Scen e Comio, vi allego la versione del documento
rivisitata. In pratica, ho corretto alcuni errori ortografici che erano
sfuggiti (spero di averli tolti tutti) e SENZA BASARMI SUL TESTO
INGLESE cercato di rendere più "leggibile" il tutto, nel senso che ho
introdotto sinonimi per eliminare ripetizioni, riorganizzato alcune
frasi che mi sembravano un po' contorte e cose simili.
Non ho modificato ne stravolto il documento, tranquilli.
La traduzione, per altro, non era niente male, molto comprensibile a
parer mio, ma ho cercato di immedesimarmi in uno che usa bugzilla per
la prima volta e che quindi legge la guida per imparare (che poi, sarei
io!! ;-) .
Spero di essere stato di aiuto. ve la allego.
Per il diff, scusate se vi chiedo di farvelo da voi, ma vado di
ultra-fretta e ho finito appena in tempo di rileggerla (mi sono accorto
solo ora che è già tardissimo!).

Ciao,
Michele

ps: il diff se volete averlo va fatto con la versione di Scen, sono
partito da quella, come avete suggerito.

[-- Attachment #2: bugzilla-howto.xml --]
[-- Type: application/xml, Size: 62826 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-29 21:50         ` Davide Cendron
@ 2007-05-30 19:06           ` skypjack
  0 siblings, 0 replies; 12+ messages in thread
From: skypjack @ 2007-05-30 19:06 UTC (permalink / raw
  To: gentoo-docs-it

Scusate, mi sono accorto solo ora che manca anche l'attributo lang="it"
in <guide ...>, mi sono dimenticato di aggiungerlo e mancava anche nei
vostri.

Ciao,
Michele

------------------------------------

 [ Michele Caini ]

 keyserver.linux.it
 Key fingerprint = 1E3A FCC9 EBCE F1A4 8BE6  57B5 F241 455D ACFD 0691

-- 
gentoo-docs-it@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-30 19:57       ` skypjack
@ 2007-05-30 19:22         ` Davide Cendron
  0 siblings, 0 replies; 12+ messages in thread
From: Davide Cendron @ 2007-05-30 19:22 UTC (permalink / raw
  To: gentoo-docs-it

[-- Attachment #1.1: Type: text/plain, Size: 845 bytes --]

Revisione bugzilla-howto.xml Part 2 8)

C'erano ancora un pò di robette da sistemare (ho anche ritradotto qualche 
frase, che purtroppo era stata mal interpretata e conseguentemente tradotta 
erroneamente).

> > Ora, leggo questa versione (vi siete aggiunti come traduttori? spero
> > di sì!) e nel we faccio il bugzilla (e ripasso la procedura :P).
>
> No, niente aggiunta come traduttori. Non credo sia necessario, in fondo
> abbiamo solo dato una mano (ed è sempre un piacere), ma lascio a Scen
> l'ultima parola.
>

Quoto Michele, non occorre, stiamo facendo solo una piccola opera di 
revisione, ma il documento l'ha tradotto per intero Luigi (per cui la maggior 
parte della fatica l'ha fatta lui :P)

-- 
Davide Cendron

Gentoo Documentation Project
Italian Follow Up Translator

http://www.gentoo.org/doc/it/

[-- Attachment #1.2: bugzilla-howto.xml --]
[-- Type: text/xml, Size: 64601 bytes --]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v 1.10 2007/04/01 10:35:45 nightmorph Exp $ -->

<guide link="/doc/it/bugzilla-howto.xml" lang="it">
<title>Guida alla Segnalazione di Bug in Gentoo</title>

<author title="Autore">
  <mail link="chriswhite@gentoo.org">Chris White</mail>
</author>
<author title="Revisione">
  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
</author>
<author title="Traduzione">
  <mail link="lmantellini@ieee.org">Luigi 'Comio' Mantellini</mail>
</author>

<abstract>
Questo documento mostra il metodo appropriato per segnalare malfunzionamenti
attraverso l'uso del Bugzilla di Gentoo.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>1.9</version>
<date>2007-04-01</date>

<chapter>
<title>Introduzione</title>
<section>
<title>Prefazione</title>
<body>

<p>
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.
</p>

</body>
</section>
<section>
<title>Bug!!!!</title>
<body>

<p>
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.
</p>

<pre caption="Errore in fase di esecuzione (run-time)">
$ <i>./bad_code `perl -e 'print Ax100'`</i>
Segmentation fault
</pre>

<pre caption="Errore durante l'emerge di un pacchetto">
/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 &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. 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
</pre>

<p>
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 è <c>gdb</c>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Debug tramite GDB</title>
<section>
<title>Introduzione</title>
<body>

<p>
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'<c>emerge</c> del pacchetto
con la variabile d'ambiente <c>FEATURES="nostrip"</c>. 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 <c>gzip</c>: 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:
</p>

<pre caption="Confronto della dimensione dei file">
<comment>(simboli di debug rimossi)</comment>
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
<comment>(simboli di debug intatti)</comment>
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
</pre>

<p>
Per completezza, <e>bad_code</e> è il programma che verrà successivamente
analizzato con <c>gdb</c>. 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 <c>-ggdb</c> alle
<c>CFLAGS</c> ed alle <c>CXXFLAGS</c>. Questa opzione aggiunge ulteriori
informazioni di debug rispetto a quanto è generalmente incluso. L'effetto di
questa opzione verrà mostrato nel seguito. Si riporta come
<path>/etc/make.conf</path> <e>potrebbe</e> apparire con le nuove opzioni
aggiunte.
</p>

<pre caption="Esempio di configurazione make.conf">
CFLAGS="-O1 -pipe -g -ggdb"
CXXFLAGS="${CFLAGS}"
</pre>

<p>
Inoltre, è possibile aggiungere l'opzione <c>debug</c> alle USE del pacchetto,
modificando eventualmente il file <path>package.use</path>:
</p>

<pre caption="Uso di package.use per aggiungere l'opzione debug alle USE di un
pacchetto">
# <i>echo "category/package debug" >> /etc/portage/package.use</i>
</pre>

<note>
Se non fosse già stato fatto in precedenza, potrebbe essere necessario creare la
directory <path>/etc/portage</path>. Se il pacchetto ha già delle impostazioni
USE nel file <path>package.use</path>, allora è necessario proseguire con la
modifica manuale del file attraverso l'editor di testo preferito.
</note>

<p>
È possibile effettuare nuovamente adesso l'emerge del pacchetto con le modifiche
apportate:
</p>

<pre caption="Rieseguire l'emerge di un pacchetto con le opzioni di debug
attivate">
# <i>FEATURES="nostrip" emerge package</i>
</pre>

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

</body>
</section>
<section>
<title>Esecuzione del programma con GDB</title>
<body>

<p>
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:
</p>

<pre caption="Fallimento di esecuzione del programma bad_code di esempio">
$ <i>./bad_code `perl -e 'print Ax100'`</i>
Segmentation fault
</pre>

<p>
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 <c>gdb</c> per risolvere il
problema. È necessario prima eseguire <c>gdb</c> con l'opzione <c>--args</c>, e
quindi dare il percorso completo del programma con i relativi parametri:
</p>

<pre caption="Esecuzione del programma malfunzionante attraverso GDB">
$ <i>gdb --args ./bad_code `perl -e 'print Ax100'`</i>
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".
</pre>

<note>
È possibile effettuare il debug con l'immagine di memoria del programma
(indicata solitamente con il termine core dump). Questo file immagine contiene
le stesse informazioni che il programma produrrebbe se fosse eseguito con
l'ausilio di <c>gdb</c>. Per effettuare il debug del file di immagine del
programma <c>bad_code</c>, è possibile eseguire <c>gdb ./bad_code core</c>, dove
<c>core</c> indica il nome del file immagine.
</note>

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

<pre caption="Esecuzione del programma in GDB">
(gdb) <i>run</i>
Starting program: /home/chris/bad_code

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

<p>
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 <c>bt</c>
ottenendo un risultato simile al seguente:
</p>

<pre caption="Backtrace del programma">
(gdb) <i>bt</i>
#0  0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it ()
#2  0x080483ba in main ()
</pre>

<p>
È 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 <c>FEATURES="nostrip"</c>. Con
la soppressione dei simboli di debug, il risultato del backtrace sarebbe molto
simile al seguente:
</p>

<pre caption="Backtrace del programma con i simboli di debug soppressi">
(gdb) <i>bt</i>
#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 ?? ()
</pre>

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

<pre caption="Backtrace del programma con l'opzione -ggdb3 abilitata">
(gdb) <i>bt</i>
#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
</pre>

<p>
È 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 <c>-ggdb</c>
abilitata si ha:
</p>

<pre caption="Confronto dimensione file con opzione -ggdb abilitata">
<comment>(informazioni di debug rimosse)</comment>
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
<comment>(informazioni di debug abilitate)</comment>
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
<comment>(flag -ggdb abilitata)</comment>
-rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code
</pre>

<p>
Come è possibile osservare, con l'aggiunta dell'opzione <c>-ggdb</c> 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 <uri link="/doc/it/gpm.xml#doc_chap4">documentazione di
gpm</uri>). Una volta concluso con <c>gdb</c>, è possibile uscire tramite il
comando <c>quit</c>:
</p>

<pre caption="Come uscire da GDB">
(gdb) <i>quit</i>
The program is running. Exit anyway? (y or n) <i>y</i>
$
</pre>

<p>
Qui termina l'introduzione all'utilizzo di <c>gdb</c>. L'uso di <c>gdb</c>
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 <c>strace</c>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Individuazione degli errori di accesso file attraverso strace</title>
<section>
<title>Introduzione</title>
<body>

<p>
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. <c>strace</c> è 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. Ipotizzare, 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".
</p>

<pre caption="foobar2 con una configurazione non valida">
$ <i>./foobar2</i>
Configuration says: bar
</pre>

<p>
La precedente configurazione impostava im modo specifico la stringa a "foo".
Usando <c>strace</c> è possibile scoprire cosa stia realmente accadendo.
</p>

</body>
</section>
<section>
<title>Uso di strace per tracciare il problema</title>
<body>

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

<pre caption="Esecuzione di foobar2 attraverso strace">
# <i>strace -ostrace.log ./foobar2</i>
</pre>

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

<pre caption="Contenuto del log di strace (parti rilevanti)">
open(".foobar2/config", O_RDONLY)       = 3
read(3, "bar", 3)                       = 3
</pre>

<p>
È stato identificato il problema. Qualcuno ha modificato la directory di
configurazione in <path>.foobar2</path> invece dell'originale
<path>.foobar</path>. È 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 <path>.foobar2</path> il file di configurazione
<path>.foobar</path>, modificandolo per produrre i risultati corretti.
</p>

</body>
</section>
<section>
<title>Conclusioni</title>
<body>

<p>
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 <c>emerge</c>.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Gestione degli errori di emerge</title>
<section>
<title>Introduzione</title>
<body>

<p>
Gli errori di <c>emerge</c>, 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.
</p>

</body>
</section>
<section id="emerge_error">
<title>Valutazione degli errori di emerge</title>
<body>

<p>
Il seguente errore è manifestato durante l'<c>emerge</c> di foobar2:
</p>

<pre caption="Errore occorso 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
</pre>

<p>
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 messaggi di compilazione,
l'errore di compilazione (build error) ed il messaggio di errore emesso da
<c>emerge</c>. Il seguente esempio riporta le sezioni appena indicate:
</p>

<pre caption="Parti del messaggio di errore">
<comment>(Messaggi di compilazione)</comment>
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

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

<comment>(Errore riportato da emerge)</comment>
!!! 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
</pre>

<p>
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.
</p>

<p>
Gli errori del <c>make</c> 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.
</p>

<p>
L'errore di emerge è cosa <c>emerge</c> 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 (<b>ma non sempre</b>). 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. Ipotizzare 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.
</p>

</body>
</section>
<section>
<title>emerge e PORT_LOGDIR</title>
<body>

<p>
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 <path>/var/log/portage</path> da usare
come directory per i log:
</p>

<note>
Nella configurazione predefinita, la directory <path>/var/log/portage</path> non
esiste, e dovrà essere creata esplicitamente. In caso non fosse creata, portage
fallirà la scrittura dei file di log.
</note>

<pre caption="emerge con PORT_LOGDIR configurata">
# <i>PORT_LOGDIR=/var/log/portage emerge foobar2</i>
</pre>

<p>
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:
</p>

<pre caption="Contenuto della directory PORT_LOGDIR">
# <i>ls -la /var/log/portage</i>
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 2115-foobar2-1.0.log
</pre>

<p>
I nomi dei file di log seguono il formato
[contatore]-[nome pacchetto]-[versione].log. Il contatore è una variabile
speciale che sta a significare la dichiarazione del pacchetto come n-esimo
pacchetto emerso. Questo previene la comparsa di log duplicati e la collisione
degli stessi. 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 abbià già segnalato un problema simile. Verrà
mostrato nella sezione seguente come effettuare la ricerca di problemi già
segnalati da altri utenti.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Ricerca delle segnalazioni mediante Bugzilla</title>
<section>
<title>Introduzione</title>
<body>

<p>
<uri link="http://www.bugzilla.org">Bugzilla</uri> è 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
<uri link="https://bugs.gentoo.org">Gentoo Bugs</uri> è possibile avere un'idea
di come è fatto il Bugzilla di Gentoo.
</p>

<p>
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.
</p>

<pre caption="Errore emerge di 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 &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. 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
</pre>

<p>
Per iniziare la ricerca, è possibile andare sul <uri
link="https://bugs.gentoo.org/">Bugzilla di Gentoo</uri>.
</p>

<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale del
Bugzilla di Gentoo"/>

<p>
È 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:
</p>

<figure link="/images/docs/bugzie-search.png" caption="Pagina di ricerca di
Bugzilla"/>

<note>
Se si è soliti utilizzare la ricerca avanzata ("Advanced Search") in precedenza,
probabilmente la si preferirà alla ricerca base.
</note>

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

<figure link="/images/docs/bugzie-adv-search.png" caption="Pagina per la
Ricerca Avanzata"/>

<p>
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.
</p>

<figure link="/images/docs/bugzie-content.png" caption="Contenuto"/>

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

<p>
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.
</p>

<p>
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:
</p>

<pre caption="Contenuto della Linea di Commento">
menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
<comment>(Rimuovere gli apici ' ')</comment>
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
</pre>

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

<p>
URI, Whitboard 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:
</p>

<figure link="/images/docs/bugzie-comp-search.png" caption="Modulo di ricerca
completo"/>

<p>
È possibile ora premere il tasto Search (Ricerca) ottenendo il risultato
seguente:
</p>

<figure link="/images/docs/bugzie-search-result.png" caption="Risultati della
ricerca"/>

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

<figure link="/images/docs/bugzie-located.png" caption="Segnalazione problema
localizzata"/>

<p>
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.
</p>

<figure link="/images/docs/bugzie-basic-search-result.png" caption="Risultato
ricerca base"/>

<p>
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 sengalazione di malfunzionamento.
</p>

</body>
</section>
<section>
<title>Conclusioni</title>
<body>

<p>
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.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Segnalazione dei malfunzionamenti</title>
<section>
<title>Introduzione</title>
<body>

<p>
In questo capitolo, sarà illustrato come usare Bugzilla per segnalare nuovi bug.
Andando all'indirizzo <uri link="https://bugs.gentoo.org">Gentoo Bugs</uri>
verrà mostrata la seguente pagina:
</p>

<figure link="/images/docs/bugzie-homepage.png" caption="Pagina principale di
Bugzilla"/>

<p>
Premere su "Report a Bug - Using the guided format".
</p>

<figure link="/images/docs/bugzie-prod-select.png" caption="Selezione
prodotto"/>

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

<p>
Nonostante questo, qualche utente invierà segnalazioni di malfunzionamento degli
ebuild nella categoria Portage Development (presupponendo che il team di
portage gestisca anche l'albero dei pacchetti in portage) o nella categoria
Gentoo Infrastructure o infra (presupponendo che il team per L'infrastruttura
abbia accesso ai mirror e rsync potendo apportare correzioni direttamente): le
cose però non funzionano in questa maniera.
</p>

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

<note>
È preferibile piuttosto vedere un bug il cui prodotto non appartiene a Gentoo
Linux ma che è stato segnalato sotto quest'ultimo, piuttosto che vedere un bug
che appartiene a Gentoo Linux ma segnalato altrove. Mentre nessuno dei due casi
è preferibile, il precedente è più accettabile e comprensibile (eccetto che per
i bug relativi al sito web... si potrebbe avere qualche problema di sorta).
</note>

<p>
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...
</p>

<figure link="/images/docs/bugzie-guide-step1.png" caption="Formato Guidato:
Passo 1"/>

<p>
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 una grande quantità di energie ai
responsabili della 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.
</p>

</body>
</section>
<section>
<title>Informazioni Richieste</title>
<body>

<figure link="/images/docs/bugzie-basic.png" caption="Informazioni base"/>

<p>
Le informazioni richieste sono:
</p>

<ul>
  <li>
    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).
  </li>
  <li>
    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.
  </li>
  <li>
    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.
  </li>
  <li>
    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.
  </li>
</ul>

<p>
Per il bug di esempio, verranno inserite le seguenti informazioni:
</p>

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

<figure link="/images/docs/bugzie-basic-comp.png" caption="Informazioni base
completate"/>

<ul>
  <li>
    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'è.
  </li>
  <li>
    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 <c>emerge
    --info</c>, schermate di esempio od informazioni simili. Piuttosto, queste
    informazioni andrebbero messe in allegato alla segnalazione del bug.
  </li>
  <li>
    Nel Summary (Riassunto/Sommario), dovrebbero essere inserite la categoria
    del pacchetto, il nome ed il numero di versione.
  </li>
</ul>

<p>
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 nessuno di
loro indicasse il numero di versione, come potrebbero gli utenti effettuare
ricerche per bug simili? Sarebbe neccessario 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:
</p>

<figure link="/images/docs/bugzie-summary.png" caption="Sommario"/>

<p>
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:
</p>

<figure link="/images/docs/bugzie-details.png" caption="Inserimento dettagli"/>

<p>
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:
</p>

<figure link="/images/docs/bugzie-reprod.png" caption="Riproducibilità"/>

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

<figure link="/images/docs/bugzie-results.png" caption="Risultati"/>

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

<figure link="/images/docs/bugzie-addl-info.png" caption="Informazioni
aggiuntive"/>

<p>
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, cercare di intepretarne il
significato molto attentamente assicurandosi di non commettere errori. Di
seguito sono illustrati i vari livelli di severità.
</p>

<ul>
  <li>
    Blocker (Bloccante) - Il programma semplicemente non vuole installarsi
    oppure è un impedimento maggiore per il sistema. Per esempio un problema su
    <c>baselayout</c> che impedisce l'avvio del sistema andrebbe certamente
    marcato come "Blocker".
  </li>
  <li>
    Critical (Critico) - Il programma ha perso dati o ha seri problemi nella
    gestione della memoria durante l'esecuzione. Per esempio, un programma come
    <c>net-tools</c> che fallisce la compilazione può essere marcato come
    critico. Non impedisce l'avvio del sistema, ma è essenziale per l'uso
    quotidiano del sistema.
  </li>
  <li>
    Major (Importante) - Il programma flliasce, ma nulla che possa causare
    danneggiamenti severi del sistema o perdita di informazione.
  </li>
  <li>
    Minor (Minore) - Il programma fallisce ma ci sono soluzioni tampone
    (workaround).
  </li>
  <li>
    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).
  </li>
  <li>
    Trivial (Triviale) - Cose come parole scritte male o pulizia degli spazi
    bianchi in eccesso.
  </li>
  <li>
    Enhancement (Miglioramento) - Una richiesta per abilitare una nuova
    caratteristica in un programma o più specificatamente un <e>nuovo ebuild</e>
  </li>
</ul>

<figure link="/images/docs/bugzie-sev.png" caption="Severità"/>

<p>
In questo esempio verrà impostata a Normal (Normale).
</p>

<p>
Ora è possibile sottomettere la nuova segnalazione di malfunzionamento premendo
sulla casella "Submit Bug Report", quindi si potrà vedere il nuovo bug
segnalato. Vedere il
<uri link="https://bugs.gentoo.org/show_bug.cgi?id=97265">Bug 97561</uri>
per un esempio di risultato. Ora che il bug è stato inserito, verrà mostrata la
modalità di gestione dello stesso.
</p>

</body>
</section>
<section>
<title>Richieste Zero-day</title>
<body>

<p>
Sin ora, è stato mostrato cosa fare per segnalare un malfunzionamento. Ora verrà
mostrato cosa è necessario <e>non</e> fare.
</p>

<p>
La maggior parte degli utenti, che magari seguono con attenzione la
pianificazione di un progetto, se accedono alla pagina web di quest'ultimo e
notano il rilascio di una nuova versione da pochi minuti, la maggior parte
delle volte accedono velocemente al Bugzilla di Gentoo per segnalare la
disponibilità della nuova versione, chiedendo di aggiungerla prima possibile a
Portage. Questo è esattamente ciò che <b>non</b> andrebbe fatto. Questo tipo di
richiesta è chiamato zero-day bump request (o 0-day), essendo fatta lo stesso
giorno del rilascio della nuova versione.
</p>

<impo>
<b>Aspettare <e>almeno</e> 48 ore prima di segnalare una nuova versione sul
Bugzilla di Gentoo.</b> Inoltre, <e>bisogna</e> controllare almeno il Bugzilla
prima di inviare la richiesta per essere sicuri che nessun altro l'abbia già
inviata, o che i mantenitori di Gentoo non se ne siano già occupati.
</impo>

<p>
Perché aspettare? In primo luogo, è abbastanza fastidioso chedere 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 packege).
</p>

<p>
Essere intelligenti quando si testano 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 buon
senso comune è più che sufficiente, e agendo in tal senso gli sviluppatori, che
hanno già un buon carico di lavoro, ne saranno grati. 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.
</p>

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

</body>
</section>
</chapter>

<chapter>
<title>Lavorare con il malfunzionamento</title>
<section>
<body>

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

<figure link="/images/docs/bugzie-new-basic.png" caption="Nuove informazioni
base"/>

<p>
I dettagli inseriti relativi al malfunzionamento sono ora disponibili.
</p>

<figure link="/images/docs/bugzie-new-details.png" caption="Dettagli relativi al
nuovo bug"/>

<p>
Comunque, bug-wranglers (solitamente) non correggerà il problema, è possibile
ri-assegnato a qualcuno che può farlo (oppure lasciare che sia bug-wranglers a
ri-assegnarlo). Per fare questo è possibile usare il file metadata.xml del
pacchetto, che è possibile trovare in
<path>/usr/portage/categoria/pacchetto/metadata.xml</path>. Qui è mostrato il
file metadata.xml relativo a foobar2.
</p>

<note>
Per poter ri-assegnare il bug è necessario essere l'autore della segnalazione di
malfunzionamento oppure un membro di alcuni gruppi speciali del Bugzilla di
Gentoo (come gli sviluppatori di Gentoo).
</note>

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

<p>
Notare la sezione relativa al maintainer. Questa elenca chi mantiene il
pacchetto, in questo caso Chris White (autore di questo documento). L'email
riportata è chriswhite@gentoo.org. Queste informazioni saranno usate per
ri-assegnare il bug alla persona corretta. Fatto questo, premere il
pallino a fianco di "Reassign bug to" e riempire il campo successivo con
l'email.
</p>

<note>
Una segnalazione di malfunzionamento relativa ad un pacchetto senza file
metadata.xml dovrebbe essere assegnata a maintainer-needed@gentoo.org mentre un
pacchetto che necessita di uno Sviluppatore Gentoo per il mantenimento dovrebbe
essere assegnato a maintainer-wanted@gentoo.org.
</note>

<figure link="/images/docs/bugzie-reassign.png" caption="Riassegnazione della
segnalazione di malfunzionamento"/>

<p>
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
<c>strace</c> 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 informazion bisogna allegarle alla
segnalazione di malfunzionamento. Per ottenere questo, premere "Create A New
Attachment" (Crea un nuovo allegato).
</p>

<figure link="/images/docs/bugzie-new-attach.png" caption="Nuovo allegato"/>

<p>
È possibile allegare il log. Si procede per gradi.
</p>

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

<p>
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 <e>maggior
parte</e> degli allegati è possbile 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).
</p>

<figure link="/images/docs/bugzie-new-attach-comp.png" caption="Nuovo allegato
completato"/>

<p>
Sottomesso il <path>strace.log</path> si avranno effetti nella segnalazione di
malfunzionamento.
</p>

<figure link="/images/docs/bugzie-strace.png" caption="Allegato strace log"/>

<p>
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.
</p>

<pre caption="Esempio di richiesta di allegare un file (config.log)">
configure: error: PNG support requires ZLIB. Use --with-zlib-dir=&lt;DIR&gt;

!!! 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.
</pre>

<p>
È raccomandabile allegare nella segnalazione di malfunzionamento ogni file
menzionato nell'errore.
</p>

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

<pre caption="Creazione di un diff standard">
$ <i>cp file file.old</i>
$ <i>nano file</i>
$ <i>diff -u file.old file</i>
</pre>

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

<pre caption="diff di un sorgente C/C++">
$ <i>cp file.c file.c.old</i>
$ <i>nano file.c</i>
$ <i>diff -up file.c.old file.c</i>
</pre>

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

<pre caption="Diff per la documentazione">
$<i> cp file.xml file.xml.old</i>
$<i> nano file.xml</i>
$<i> diff -Nut file.xml.old file.xml</i>
</pre>

<p>
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.
</p>

<figure link="/images/docs/bugzie-add-email.png" caption="Aggiunta di una email
in CC:"/>

<note>
Gli indirizzi email devono essere registrati nel Bugzilla di Gentoo. Per
inserire più indirizzi email in CC basta separarli con la virgola o con lo
spazio.
</note>

<p>
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.
</p>

<ul>
  <li>
    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.
  </li>
  <li>
    NEW (Nuova) - Le segnalazioni appena aperte sono considerate nuove.
  </li>
  <li>
    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.
  </li>
  <li>
    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. <b>Non si deve abusare di questa opzione</b>.
    Se uno sviluppatore chiude un bug una seconda o terza volta, probabilmente
    il problema è stato risolto.
  </li>
  <li>
    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.
  </li>
  <li>
    VERIFIED (Verificata) - Sono state effettuate le fasi per verificare che la
    segnalazione sia corretta. Questo è solitamente un fatto di QA.
  </li>
  <li>
    CLOSED (Chiusa) - Essenzialmente significa la morte per il malfunzionamento
    e che è stato sepolto sotto il flusso senza fine dei nuovi malfunzionamenti.
  </li>
</ul>

<p>
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:
</p>

<figure link="/images/docs/bugzie-reso.png" caption="Malfunzionamento risolto"/>

<p>
Poco sotto, verrà mostrato quanto segue:
</p>

<figure link="/images/docs/bugzie-options.png" caption="Opzioni del bug"/>

<p>
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:
</p>

<ul>
  <li>
    FIXED (Risolto) - Il malfunzionamento è risolto, seguire le istruzioni
    per risolvere il problema.
  </li>
  <li>
    INVALID (Invalido) - Non è stato fatto qualcosa come specificatamente
    documentato, causando il malfunzionamento.
  </li>
  <li>
    DUPLICATE (Duplicato) - Non è stata usata questa guida ed è stata riportata
    una segnalazione duplicata.
  </li>
  <li>
    WORKSFORME (Funziona per me) - Lo sviluppatore/utente assegnatario della
    segnalazione non può riprodurre l'errore.
  </li>
  <li>
    CANTFIX (Non risolvibile) - Qualcosa non può essere risolta per certe
    circostanze. Queste circostanze saranno segnalate alla persona che ha preso
    la segnalazione.
  </li>
  <li>
    WONTFIX (Non si vuole risolvere) - Questo è usualmente applicato ai nuovi
    ebuild o alle richieste di nuove opzioni. Essenzialmente lo sviluppatore
    non vuole aggiungere certe opzioni perché non necessarie, o esistono
    alternative migliori, oppure la richiesta è errata. Qualche volta potrebbe
    essere data una soluzione per considerare il problema risolto.
  </li>
  <li>
    UPSTREAM (Al progetto originale) - 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 mail-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.
  </li>
</ul>

<p>
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.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Ebuild di test</title>
<section>
<title>Ottenere i file</title>
<body>

<p>
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:
</p>

<figure link="/images/docs/bugzie-ebuild-request.png" caption="Richiesta di
test dell'ebuild"/>

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

<pre caption="Impostazione della variabile PORTDIR_OVERLAY">
PORTDIR_OVERLAY="/usr/local/portage"
</pre>

<p>
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 per i file in cui copiare la patch. Le
directory dei file contengono i digest (md5sum dei file per una particolare
versione del pacchetto) e 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:
</p>

<pre caption="Creazione directory per la categoria (sys-apps) ed il pacchetto
(foobar2)">
# <i>mkdir -p /usr/local/portage/sys-apps/foobar2/files</i>
</pre>

<note>
L'opzione <c>-p</c> nel comando <c>mkdir</c> crea non solo la directory che si
vuole ma anche tutte le directory superiori mancanti (in questo caso sys-apps e
foobar2).
</note>

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

</body>
</section>
<section>
<title>Verifica dell'ebuild</title>
<body>

<p>
Il processo per creare un ebuild usabile da emerge è molto semplice. Bisogna
creare un file "Manifest" ed un file per i digest per l'ebuild. Questo può
essere fatto con il comando <c>ebuild</c> eseguito come segue:
</p>

<pre caption="Creazione del file Manifest e dei file per i digest">
# <i>ebuild foobar2-1.0.ebuild digest</i>
&gt;&gt;&gt; Generating digest file...
&lt;&lt;&lt; foobar2-1.0.tar.bz2
&gt;&gt;&gt; Generating manifest file...
&lt;&lt;&lt; foobar2-1.0.ebuild
&lt;&lt;&lt; files/digest-foobar2-1.0
&lt;&lt;&lt; files/foobar2-1.0-Makefile.patch
&gt;&gt;&gt; Computed message digests.
</pre>

<p>
È possibile verificare l'ebuild vedendo se funziona come dovrebbe.
</p>

<pre caption="Verifica attraverso l'uso di emerge -pv">
# <i>emerge -pv foobar2</i>

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
</pre>

<p>
Sembra che abbia funzionato come dovrebbe. Si noti il testo "[1]" alla fine
della linea "[ebuild]". Questo punta a <path>/usr/local/portage</path>, che
contiene l'overlay creato poco fa. Andando avanti si installa il pacchetto con
emerge.
</p>

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

<p>
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.
</p>

</body>
</section>
<section>
<title>Conclusioni</title>
<body>

<p>
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 <mail>chriswhite@gentoo.org</mail>.
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.
</p>

</body>
</section>
</chapter>
</guide>

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-docs-it] Beta bugzilla-howto.xml
  2007-05-30 17:45     ` Luigi 'Comio' Mantellini
@ 2007-05-30 19:57       ` skypjack
  2007-05-30 19:22         ` Davide Cendron
  0 siblings, 1 reply; 12+ messages in thread
From: skypjack @ 2007-05-30 19:57 UTC (permalink / raw
  To: gentoo-docs-it

> Il fatto è che la versione inglese è troppo colloquiale (ma credo
> chesia un "problema" di tutti i documenti).

Di molti, "purificarle" rappresenta forse lo sforzo più grande delle
traduzioni iniziali. Per gli aggiornamenti è più facile, ovvio.

> Diventa ostico certe volte tradurre frasi che sono un semplice
> intercalare.

Se posso permettermi di dare un suggerimento, solitamente le riscrivo
anche un po' diverse ma cercando di mantenere il senso, perché la mera
traduzione non è quasi mai facile e comprensibile.

> Ho tentato di leggerlo molte volte (passo però il correttore solo alla
> fine della fiera, dopo le review) per cercare di vedere quanto filare,
> ma alcuni punti devo dire che è proprio dura.

Spero di averti sciolto qualche nodo... :-)

> Ora, leggo questa versione (vi siete aggiunti come traduttori? spero
> di sì!) e nel we faccio il bugzilla (e ripasso la procedura :P).

No, niente aggiunta come traduttori. Non credo sia necessario, in fondo
abbiamo solo dato una mano (ed è sempre un piacere), ma lascio a Scen
l'ultima parola.

Ciao,
Michele

------------------------------------

 [ Michele Caini ]

 keyserver.linux.it
 Key fingerprint = 1E3A FCC9 EBCE F1A4 8BE6  57B5 F241 455D ACFD 0691

--
gentoo-docs-it@gentoo.org mailing list

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2007-05-30 19:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-22 17:56 [gentoo-docs-it] Beta bugzilla-howto.xml Luigi 'Comio' Mantellini
2007-05-29 20:18 ` Davide Cendron
2007-05-29 20:47   ` Luigi 'Comio' Mantellini
2007-05-29 20:58     ` Davide Cendron
2007-05-29 21:44       ` Michele Caini
2007-05-29 21:47         ` Luigi 'Comio' Mantellini
2007-05-29 21:50         ` Davide Cendron
2007-05-30 19:06           ` skypjack
2007-05-30 18:58   ` skypjack
2007-05-30 17:45     ` Luigi 'Comio' Mantellini
2007-05-30 19:57       ` skypjack
2007-05-30 19:22         ` Davide Cendron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox