Ho finito di tradurre una pagina del sito Web di Debian che avevo iniziato molto tempo fa, ma poi lasciato cadere nel dimenticatoio. Si tratta di devel/buildd/wanna-build-states.wml, che vi allego per la revisione e, se non ci sono problemi, per essere messa in CVS. Allego anche l'aggiornamento (molto lieve[1]) di un'altra pagina che avevo già tradotto io (devel/buildd/index.wml) e la traduzione di una terza pagina ancora (devel/buildd/operation.wml) che avevo sottoposto il lista tempo fa, ma che non ha mai ricevuto risposta. Anche per queste due vi chiedo di rileggerle e, se possibile, caricarle sul CVS. [1] http://cvs.debian.org/webwml/english/devel/buildd/index.wml.diff?r1=1.14&r2=1.15&cvsroot=webwml&diff_format=h Ciao a tutti e buon Ferragosto! Giovanni. -- Giovanni Mascellani <g.mascellani@gmail.com> Pisa, Italy Web: http://giomasce.altervista.org SIP: g.mascellani@ekiga.net Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70)
#use wml::debian::template title="Autobuilder network" BARETITLE="true" #use wml::debian::translation-check translation="1.15" maintainer="Giovanni Mascellani" <p>La rete di buildd �n sottoprogetto di Debian che aiuta a velocizzare la ricompilazione dei pacchetti per tutte le architetture che <a href="$(HOME)/ports/">Debian al momento supporta</a>. Questa rete �ormata da svariate macchine (i nodi buildd) che utilizzano uno specifico pacchetto software, chiamato <em>buildd</em>, per prendere i pacchetti dall'archivio Debian e ricompilarli per l'architettura richiesta.</p> <h2>Come mai �ecessaria la rete di buildd?</h2> <p>La distribuzione Debian supporta <a href="$(HOME)/ports/">un buon numero di architetture</a>, ma i mantenitori dei pacchetti in genere compilano i binari solo per una sola architettura (di solito i386). Gli sviluppatori di altre architetture devono prestare attenzione a quando escono nuove versioni di ogni pacchetto e ricompilarle, se vogliono stare al passo con la distribuzione Intel.</p> <p>Quando fu iniziata Debian/m68k (il primo port non Intel) tutto questo veniva fatto manualmente: gli sviluppatori controllavano sulla mailing list degli upload la presenza di nuovi pacchetti e ne prendevano alcuni per compilarli. Annunciando su una mailing list cosa si stava per fare si evitava che un pacchetto venisse compilato due volte. �evidente che per�esto metodo era facilmente soggetto ad errori ed estremamente costoso in termini di tempo, ma �tato per lungo tempo l'unico modo di mantenere le distribuzioni non i386.</p> <p>Il demone di compilazione rende automatica la maggior parte di questo processo. Consiste di una serie di script (scritti in Perl e Python), che sono stati modificati molte volte nel corso del tempo in modo da aiutare i porter in molti compiti. Sono finalmente diventati un sistema che �apace di mantenere quasi automaticamente una distribuzione Debian non i386 aggiornata. </p> <h2>Come funziona buildd?</h2> <p><em>Buildd</em> �l nome che di solito si d�i programmi utilizzati della rete, ma in realt� per�viso in parti diverse:</p> <dl> <dt><a href="http://svn.cyberhqz.com/svn/wanna-build/";>wanna-build</a></dt> <dd> un tool che coordina la (ri)compilazione dei pacchetti attraverso un database che mantiene la lista dei pacchetti e del loro stato. C'�n database centrale per ogni architettura che memorizza lo stato dei pacchetti, la loro versione e qualche altra informazione. </dd> <dt><a href="http://svn.cyberhqz.com/svn/wanna-build/";>buildd</a></dt> <dd> un demone che controlla periodicamente il database mantenuto da <em>wanna-build</em> e chiama <em>sbuild</em> per compilare i pacchetti. Tiene traccia delle compilazioni fallite e riuscite e carica i pacchetti nell'archivio una volta che il log di compilazione �tato accettato dall'amministratore. </dd> <dt><a href="http://packages.debian.org/sbuild";>sbuild</a></dt> <dd> �esponsabile dell'effettiva compilazione dei pacchetti in chroot isolate. Per fare questo principalmente utilizza tool standard di Debian, ma tiene anche conto delle dipendenze di compilazione e di altre sottigliezze. </dd> <dt><a href="http://packages.debian.org/quinn-diff";>quinn-diff</a></dt> <dd> riempie il database di wanna-build con i nuovi pacchetti. Confronta la lista dei pacchetti disponibili ed elenca le differenze (comparando un file Sources ed un file Packages). Altre informazioni su quinn-diff sono disponibili <a href="http://buildd.debian.org/quinn-diff/";>qui</a>. </dd> <dt>andrea</dt> <dd> un tool che genera alcune dipendenze di compilazioni automaticamente ed integra questi dati a dipendenze aggiunte manualmente. </dd> </dl> <p>Tutte queste parti <a href="operation">operano</a> insieme per far funzionare la rete di buildd.</p> <h2>Cosa deve fare uno sviluppatore Debian?</h2> <p>In realt�o sviluppatore Debian medio non deve esplicitamente usare la rete di buildd. Quando carica un pacchetto nell'archivio (binari compilati per una certa architettura), questo sar�ggiunto al database di ogni architettura (nello stato <em>Needs-Build</em>, ossia "compilazione necessaria"). Le macchine di compilazione interrogheranno il database chiedendo quali pacchetti sono in quello stato e prenderanno continuamente pacchetti dalla lista. I criteri di priorit�ella lista sono lo stato della precedente compilazione, la priorit�el pacchetto, la sua sezione ed infine il suo nome.</p> <p>Se la compilazione ha successo su tutte le architetture, il mantenitore non avr�isogno di fare niente. Tutti i pacchetti binari saranno caricati nell'archivio principale della loro architettura. Se la compilazione non finisce con successo, il pacchetto entrer�n uno stato speciale (<em>Failed</em>, "fallito", oppure <em>Dep-Wait</em>, "aspetta le dipendenze", se ha dipendenze di compilazione o di installazione che non sono disponibili). Gli amministratori della rete di buildd controlleranno i pacchetti che non sono stati compilati con successo e ne daranno comunicazione al mantenitore, generalmente aprendo un bug nel Bug Tracking System.</p> <p>A volte un pacchetto impiega molto tempo per essere compilato per una certa architettura, e questo gli impedisce di entrare in <a href="$(HOME)/devel/testing">testing</a>. Sfortunatamente il pacchetto dovr�spettare finch�na macchina non lo prende. Gli amministratori di buildd non accetteranno richieste di velocizzare la compilazione di un pacchetto, perch�a lista delle priorit� stata fissata.</p> <p>Puoi controllare lo stato di ogni tentativo fatto da buildd per compilare i pacchetti che appartengono ad ogni mantenitore controllando i <a href="http://buildd.debian.org/bymaint.php";>log di buildd</a>. Questi log possono essere raggiunti anche dal Riassunto dei Pacchetti di un Mantenitore (Packages' Maintainer Overview).</p> <p>Per maggiori informazioni sui diversi stati dei pacchetti puoi leggere <a href="wanna-build-states">"stati di wanna-build"</a>.</p> <h2>Dove posso trovare altre informazioni?</h2> <p>Ovviamente, il miglior modo di capire come funziona la rete i buildd �onsultare i codici sorgente e la documentazione disponibile. Inoltre, la sezione <a href="$(HOME)/doc/manuals/developers-reference/ch-pkgs#s-porting">\ Porting and being ported</a> della <a href="$(HOME)/doc/manuals/developers-reference/">Debian Developers Reference</a> contiene altre informazioni su come funziona, nonch�nformazioni sui <a href="$(HOME)/doc/manuals/developers-reference/ap-tools#s-tools-builders">\ compilatori di pacchetti</a> e <a href="$(HOME)/doc/manuals/developers-reference/ap-tools#s-tools-porting">\ tool per il porting</a> che sono utilizzati nel processo di costruzione e mantenimento della rete di buildd.</p> <p>Sono disponibili <a href="http://buildd.debian.org/stats/";>alcune statistiche sulla rete di buildd</a>.</p> <h2>Come faccio a installare il mio nodo buildd personale?</h2> <p>Ci sono molte ragioni per cui uno sviluppatore (o un utente) potrebbe voler metter su e far funzionare un sistema buildd:</p> <ul> <li>Per testare localmente se le dipendenze di compilazione di un pacchetto sono correttamente definite (p. es. compilando il pacchetto nell'ambiente di buildd).</li> <li>Per aiutare nel port su una certa architettura (quando sono necessari nodi buildd).</li> <li>Per valutare l'effetto di una certa patch o ottimizzazione del compilatore su un grande numero di pacchetti.</li> <li>Per utilizzare tool che analizzano pacchetti cercando errori comuni e che lavorano sui pacchetti compilati, operazione che pu�che essere necessaria per fare analisi sul codice sorgente, per esempio come work-around per pacchetti che usano <tt>dpatch</tt>.</li> </ul> <p>Qui puoi trovare ulteriori informazioni su come <a href="setting-up">installare un nodo buildd</a>.</p> <hrline /> <p><small>Questa introduzione alla rete di buildd �tata scritta mettendo insieme pezzetti appartenenti a Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine e Javier Fern�ez-Sanguino.</small></p>
#use wml::debian::template title="Funzionamento della rete di buildd" BARETITLE="true"
#use wml::debian::translation-check translation="1.8" maintainer="Giovanni Mascellani"
<p>Il cuore del sistema è il database di <tt>wanna-build</tt>, che tiene traccia
delle versioni e degli stati di ogni pacchetto. <tt>quinn-diff</tt> confronta
ogni giorno la lista dei pacchetti dell'architettura considerata con la lista
dei pacchetti sorgente, e compila una lista dei pacchetti che devono essere
ricompilati, impostandoli nel database allo stato di <tt>Needs-Build</tt>
("compilazione necessaria").</p>
<p>Tutti i demoni di compilazione (ce ne possono essere più di uno) interrogano
regolarmente il database cercando tali pacchetti e ne prendono alcuni facendoli
entrare nello stato <tt>Building</tt> ("in compilazione"). Ovviamente questo può
essere anche fatto manualmente da un utente, per esempio nei casi in cui la
compilazione automatica non sia possibile. Qui possiamo vedere anche un secondo
scopo di <tt>wanna-build</tt>: si assicura che la stessa versione di un
pacchetto non venga compilata due volte.</p>
<div class="center"><a name="autobuilder34"></a>
<img src="scheme.png" alt="Schema di funzionamento di buildd">
<p><strong>Figura:</strong> Stati dei pacchetti e transizioni</p>
</div>
<p>Se tutto va a buon fine, il pacchetto terminato verrà caricato sul server ed
entrerà in un altro stato, <tt>Uploaded</tt> ("caricato"). Dopodiché verrà
copiato nell'archivio di Debian, in modo da apparire nella lista dei
pacchetti aggiornati per l'architettura considerata. Questa lista sarà poi
inserita nel database, ed il pacchetto entrerà nello stato <tt>Installed</tt>
("installato") e vi rimarrà fino alla prossima versione del pacchetto
sorgente.</p>
<p>Esistono molto altri stati; tra di essi: <tt>Failed</tt> ("fallito") serve
per i pacchetti la cui compilazione è fallita a causa di errori nei sorgenti.
Si suppone che gli errori saranno corretti in una versione successiva
(ovviamente una volta notificato il problema), quindi una nuova versione del
pacchetto entrerà direttamente nello stato <tt>Needs-Build</tt>, ma con una
notifica del precedente errore. Insieme a questo stato viene memorizzata una
descrizione dell'errore. Lo stato <tt>Dep-Wait</tt> ("aspetta le dipendenze")
viene utilizzato quando un pacchetto ha bisogno di un qualche altro pacchetto
per essere compilato, ma tale dipendenza non può essere soddisfatta perché il
secondo pacchetto ancora non è stato compilato. Questo stato memorizza anche una
lista dei pacchetti e delle relative versioni richiesti, e, quando tutte
diventano disponibili, lo stato ritorna a <tt>Needs-Build</tt>.</p>
<p>Come abbiamo detto prima, il demone di compilazione prende i pacchetti da
compilare dall'archivio. Diamoci un'occhiata più da vicino: se ha qualche
pacchetto da compilare, utilizza <tt>sbuild</tt> per l'effettivo processo di
compilazione, e per ogni esecuzione viene inviato un log via email al
mantenitore del demone. Questo lo visiona e decidere cosa fare del pacchetto:
caricarlo nell'archvio, impostarlo a <tt>Failed</tt> o a <tt>Dep-Wait</tt>,
fare dei cambiamenti alle dipendenze di compilazione e riprovare, ecc... Se
il pacchetto viene accettato, il demone lo sposta in un directory di upload,
dalla quale tutti i pacchetti sono periodicamente caricati sul server.</p>
<p>Controllare i file di log è l'unico intervento umano nell'intero processo,
se non ci sono errori. Ci sono due buone ragioni per non eliminare anche questo
passaggio: primo, ogni tanto una compilazione sembra essere andata a buon fine,
ma in realtà è fallita per ragioni che la macchina non può individuare. Inoltre
un upload diretto implicherebbe una firma PGP automatica dei file generati,
fatta con una chiave non protetta da una passphrase. Questo sarebbe un problema
di sicurezza inaccettabile.</p>
<p>Lo script <tt>sbuild</tt> sostanzialmente chiama tool standard di Debian per
compilare i sorgenti. In realtà dà anche una mano effettuando delle operazioni
di "ordinaria amministrazione", ma la sua vera specialità sono le dipendenze di
compilazione. Spesso dei pacchetti hanno bisogno di altri pacchetti installati
per poter essere compilati, per esempio compilatori e librerie. Non è molto
intelligente tenere tutti questi pacchetti sempre installati, e spesso non è
neanche possibile per via di conflitti. Le dipendenze di compilazioni dicono
semplicemente a <tt>sbuild</tt> di cosa ha bisogno ogni pacchetto. Questo può
quindi installare le dipendenze prima di compilare e rimuoverle subito dopo.</p>
<p>Le dipendenze di compilazione possono essere parzialmente generate
automaticamente, controllando le dipendenze del pacchetto binario generato dai
sorgenti. Questo è quello che fa <tt>andrea</tt>: analizzare la lista dei
pacchetti per i386 e mappare i pacchetti delle librerie nei corrispondenti
pacchetti di sviluppo. A queste dipendenze ne aggiunge altre impostate
manualmente, quando non possono essere generate automaticamente, come per
esempio compilatori o tool speciali.</p>
<hr>
<p><small>Materiale sviluppato da Roman Hodek per il sesto International
Linux-Kongress 1999.</small></p>
#use wml::debian::template title="Stati di wanna-build: una spiegazione" BARETITLE="true"
#use wml::debian::translation-check translation="1.18" maintainer="Giovanni Mascellani"
<p>Questa pagina tenta di spiegare qual �l significato di ciascuno degli stati
di wanna-build e cosa succede ad un pacchetto quando �n ciascuno stato. �principalmente scritto per il manutentori che stanno cercando di capire come mai
il loro pacchetto � non �tato compilato per una particolare architettura.
Inoltre viene fornita una spiegazione per ogni possibile risultato del log.</p>
<p>�anche disponibile un <a href="#graphlink">diagramma di flusso</a> che
rappresenta gli stati di wanna-build; tuttavia esso non copre tutto ci�e �enzionato in questa pagina.</p>
<h2>Gli stati di wanna-build</h2>
<p>Per ogni architettura supportata da Debian c'�n database wanna-build
installato su buildd.debian.org, che contiene lo stato corrente di tutti i
pacchetti. Esistono sette stati: <em>Needs-Build</em>, <em>Building</em>,
<em>Uploaded</em>, <em>Dep-Wait</em>, <em>Failed</em>, <em>Not-For-Us</em> e
<em>Installed</em>.</p>
#<p>Their meaning is as follows:</p>
<p>Il loro significato �uesto:</p>
<dl>
<dt><a name="needs-build">Needs-Build ("compilazione necessaria")</a></dt>
<dd>Un pacchetto marcato <em>Needs-Build</em> ha appena visto un upload di
una nuova versione da parte del suo mantenitore, ma per un'architettura
diversa da quella di questo database di wanna-build; deve quindi essere
ricompilato. Se lo stato �em>Needs-Build</em> vuol dire che non �tato
ancora preso da nessun nodo compilatore, ma che presto lo sar�non appena
una macchina �isponibile ed il pacchetto �n cima alla lista). Spesso si
dice che "un pacchetto �ella coda di ricompilazione" quando si vuole
intendere che �n stato di <em>Needs-Build</em>.<br />
�interessante notare che la cosa dei <em>Needs-Build</em> non �n realt�una coda FIFO; al contrario, l'ordinamento utilizzato �asato su questi
criteri:
<ol>
<li>Stato precedente di compilazione; pacchetti che sono gi�tati
compilati in passato ricevono una priorit�aggiore di quelli nuovi.
</li>
<li>Priorit�pacchetti con priorit�em>required</em> sono compilati
prima di pacchetti con priorit�em>extra</em>).
</li>
<li>Sezione in cui sta il pacchetto. Questo ordinamento �asato su
quali sezioni sono considerate pi�ortanti; per esempio, la
sezione <em>games</em> viene compilata dopo la sezione <em>base</em>
e la sezione <em>libs</em> viene compilata prima della sezione
<em>devel</em>.
</li>
<li>Ordinamento alfabetico sul nome del pacchetto.</li>
</ol>
Inoltre, sotto certe condizioni, pu�cadere che una nodo compilatore
non prenda il pacchetto in cima alla cosa; per esempio, se un demone di
compilazione non trova i sorgenti di un pacchetto lo rimetter�ella coda
(dove torner�ubito nella posizione che aveva prima, ossia in testa), ma lo
ignorer�er alcune ore. Un altro esempio dove questo potrebbe accadere �una rete con molti nodi di compilazione; in tal caso i porter per
quell'architetture potrebbero scegliere di compilare i pacchetti pi�ndi
sulle macchine pi�enti, lasciando i pi�coli alle macchine pi�te.
Una macchina di compilazione teoricamente pu�che richiedere
esplicitamente un diverso ordinamento delle sezioni, ma questo in genere non
viene fatto.<br />
Ci potrebbero essere altre situazioni in cui potrebbe sembrare che la coda
non viene rispettata, ma sono tutte eccezioni.
</dd>
<dt><a name="building">Building ("in compilazione")</a></dt>
<dd>Un pacchetto �arcato come <tt>Building</tt> dal momento in cui un nodo
buildd lo prende dalla cima della coda di wanna-build fino al momento in cui
l'amministratore del nodo risponde al log. Siccome i pacchetti non sono
presi uno per uno, un pacchetto potrebbe essere (ed in genere �in questo
stato anche prima che la compilazione sia effettivamente iniziata; comunque,
poich�uildd compila i pacchetti nella propria coda locale secondo un
meccanismo FIFO, non dovrebbe mancare molto a che l'operazione venga
effettivamente eseguita. Inoltre bisogna notare che lo stato di un pacchetto
<strong>non</strong> viene modificato una volta che la compilazione �terminata, ma solo quando l'amministratore della macchina che lo ha
compilato risponde al log di compilazione.</dd>
<dt><a name="uploaded">Uploaded ("caricato sul server")</a></dt>
<dd>Quando una compilazione va a buon successo, un log dell'operazione viene
inviato all'amministratore della macchina che l'ha eseguita ed a
buildd.debian.org. L'amministratore firmer�igitalmente il file .changes
incluso nel log e lo rimander�l demone di compilazione, che a sua volta
caricher�l pacchetto compilato sul server ed imposter�l suo stato a
<em>Uploaded</em>. Un pacchetto in questo stato pu�indi essere trovato
da qualche parte nella coda incoming.<br />
Un nodo di buildd non toccher�i�pacchetto se il suo stato �<em>Uploaded</em>, perlomeno fino a che non sar�isponibile una sua
versione o fino a che un porter modificher�anualmente lo stato del
pacchetto.</dd>
<dt><a name="dep-wait">Dep-Wait ("aspetta le dipendenze")</a></dt>
<dd>Quando un pacchetto fallisce a causa di dipendenze di compilazione non
soddisfatte, il mantenitore della macchina che ha provato ad elaborarla
invia un'email alla macchina stessa, dicendo di cancellare i sorgenti e di
marcale il pacchetto come <em>Dep-Wait</em> sulle dipendenze mancanti. Un
pacchetto in questo stato verr�utomaticamente marcato, senza necessit�i
intervento umano, come <em>Needs-Build</em>, una volta che dette dipendenze
diventano disponibili.<br />
Tempo fa ogni pacchetto doveva effettivamente vedere almeno un tentativo di
compilazione prima che il mantenitore lo mettesse manualmente in stato
<em>Dep-Wait</em>. Per�ll'agosto del 2005 �tato aggiunto del codice in
wanna-build che sposta direttamente un pacchetto da
<em><a href="#installed">Installed</a></em> a <em>Dep-Wait</em>, se �l
caso.<br />
Ci sono due casi particolari nei quali pu�cadere che un pacchetto
rimanga per sempre in stato <em>Dep-Wait</em>, ossia quando si �bagliato
a scrivere il nome di una dipendenza di compilazione (cosicch�l pacchetto
rimarr�erpetuamente in <em>Dep-Wait</em> su un pacchetto che non esiste e
che mai esister�e quando una dipendenza �ichiarata su un pacchetto
marcato <em>Non-Per-Noi</em> o nella lista di pacchetti specifici per
un'architettura (<em>packages-arch-specific</em>).<br />
Come esempio per l'ultimo caso, si considerino tre pacchetti: <tt>foo</tt>,
che esiste solo per <tt>i386</tt>, <tt>bar</tt>, che esiste solo per
<tt>m68k</tt> (e che fa sostanzialmente lo stesso lavoro) e <tt>baz</tt>,
che pu�sere compilato con <tt>foo</tt> o con <tt>bar</tt>. Se il
mantenitore di quest'ultimo dovesse dimenticarsi di aggiungere <tt>bar</tt>
alle dipendenze di compilazione e non si accorgesse della notifica che
<tt>baz</tt> �n stato <tt>Dep-Wait</tt> sul pacchetto non esistente
<tt>foo</tt> per <tt>m68k</tt>, in tal caso lo stato <tt>Dep-Wait</tt> per
l'architettura <tt>m68k</tt> dovrebbe essere modificato manualmente da un
porter.</dd>
<dt><a name="wanna-build-state-failed">Failed ("fallito")</a></dt>
<dd>Se un tentativo di compilazione fallisce ed il mantenitore del nodo
decide che si tratta realmente di un fallimento, e che quindi la
compilazione non deve essere tentata nuovamente, il pacchetto �arcato come
<em>Failed</em>. Un pacchetto non lascer�uesto stato fino a quanto un
porter lo decider� fino a quando sar�isponibile una nuova versione.
Comunque, quando �isponibile una nuova versione di un pacchetto che era
marcato <em>Failed</em> nella versione precedente, la macchina di
compilazione chieder�l suo amministratore se veramente il pacchetto deve
essere elaborato nuovamente o no; questo per evitare di sprecare risorse se
�hiaro che l'operazione fallir�i nuovo. Bench�are per fallita una
compilazione che non si �rovata �olto difficilmente la cosa giusta da
fare, l'opzione di farlo �er�sponibile al mantenitore del nodo.<br />
Nota che un pacchetto non sar�strong>mai</strong> marcato <em>Failed</em>
senza l'intervento umano.</dd>
<dt><a name="not-for-us">Not-For-Us ("non per noi")</a></dt>
<dd>Certi pacchetti sono specifici per un'architettura; per esempio,
<tt>lilo</tt>, un boot loader per i386, non dovr�ssere compilato per
alpha, m68k o s390. Comunque, <em>wanna-build</em> non consulta i file di
controllo dei pacchetti per generare il suo database, ma solo il nome del
pacchetto, la sua sezione, il suo stato precedente e la sua priorit�In
questo modo la prima volta che viene caricato un pacchetto esistente solo
per alcune architetture un tentativo di compilazione viene lanciato in ogni
caso (ma fallisce prima ancora che le dipendenze di compilazione siano
scaricare ed installate).<br />
Siccome i nodi di buildd non dovrebbero perdere tempo a cercare di compilare
pacchetti inutili per quell'architettura, �ecessario un modo per
identificare tali pacchetti. La prima soluzione a questo problema �tata
<em>Not-For-Us</em>; per�al momento che �ifficile da mantenere, �ggi
deprecata; i mantenitori di buildd dovrebbero usare al suo posto
<em>packages-arch-specific</em>, che non �no stato di
<em>wanna-build</em>, ma una lista di pacchetti specifici per una o pi�chitetture.<br />
Un pacchetto in <em>Not-For-Us</em> o in <em>packages-arch-specific</em>
<strong>non</strong> lascer�utomaticamente questo stato; se un pacchetto
prima escludeva una data architettura che ora supporta nel suo file di
controllo, deve essere riaccodato <strong>manualmente</strong>.<br />
Se ti trovi in questa situazione, puoi chiedere che questa operazione venga
fatta scrivendo agli opportuni mantenitori di buildd, che possono essere
raggiunti su $arch@buildd.debian.org.</dd>
<dt><a name="installed">Installed ("installato")</a></dt>
<dd>Come il nome suggerisce, un pacchetto marcato <em>Installed</em> �correttamente compilato per l'architettura del database di wanna-build.
Prima del rilascio di Woody lo stato di un pacchetto veniva cambiato da
<em>Uploaded</em> a <em>Installed</em> dopo l'esecuzione giornaliera di
<em>katie</em>. Con l'implementazione di
<a href="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html";>Accepted-autobuild</a>,
per�uesto non �i�o; oggi un pacchetto passa da <em>Uploaded</em> a
<em>Installed</em> quando �ccettato nell'archivio, ossia dopo circa
quindici minuti.</dd>
</dl>
<p>Oltre a questi sette stati, <em>wanna-build</em> conosce anche altri due
stati per pacchetti rimossi, che sono usati solamente in casi molto
eccezionali. Questi due stati sono <em>Dep-Wait-Removed</em> e
<em>Failed-Removed</em>. Il loro rapporto con le loro versioni
<q>normali</q> �uesto: quando un pacchetto in stato <em>Failed</em> o
<em>Dep-Wait</em> non compare pi�un file Packages passato a
<em>wanna-build</em> – ossia quando quest'ultimo si rendo conto che il
pacchetto �tato rimosso – le informazioni relative non sono
cancellate, perch�a mancanza del pacchetto potrebbe essere semplicemente
dovuta ad un problema temporaneo, o ad un rimozione provvisioria (il
pacchetto ricomparir�ell'archvio, basta dargli tempo). In questo caso il
pacchetto viene spostato nell'opportuno stato di rimozione, in modo che le
informazioni relative al fallimento della sua compilazione siano preservate.
Se il pacchetto dovessere riapparire in un successivo file Packages passato
a <em>wanna-build</em>, verrebbe direttamente riportato da
<em>Failed-Removed</em> a <em>Failed</em> o da <em>Dep-Wait-Removed</em> a
<em>Dep-Wait</em>.</p>
<p>Non �ossibile accedere ai database di <em>wanna-build</em>
direttamente: tali database sono installati su ftp-master.debian.org, che �una macchina ad accesso ristretto, e solo i nodi di buildd hanno una chiave
SSH che permette loro di interagire con il database relativo alla loro
architettura. Cos�uccedeva anche prima che ftp-master fosse ad accesso
ristretto; poich�em>wanna-build</em> necessit�i un lock a livello di
database anche durante la semplice lettura, era necessario essere nel gruppo
giusto (wb-<arch&rt;) per accedere direttamente al un database.</p>
<p>Tuttavia, �ossibile vedere lo stato di un pacchetto andando sulla
<a href="http://buildd.debian.org/stats/";>pagina delle statistiche di
buildd</a>, tranne che se �ello stato <em>Installed</em> (a meno che non
ti dia problemi andare a cercare nei lunghissimi file
"<arch>-all.txt"...). Altrimenti ci sono delle pagine disponibili su
<a href="http://crest.debian.org/";>crest.debian.org</a>, basate sull'analisi
dei file <arch>-all.txt, che permettono di leggere pi�odamente
(almeno dal punto di visto umano) qual �o stato di un pacchetto.</p>
<h2>I risultati della compilazione</h2>
<p>Quando un pacchetto viene compilato da sbuild (il componente di buildd che
si occupa della compilazione vera e propria) un log dell'operazione viene
inviato per email all'amministratore del nodo ed a logs@buildd.debian.org
(in modo che possa essere visualizzato su http://buildd.debian.org). Il
risultato del log di compilazione pu�sere <em>successful</em> ("riuscito"),
<em>failed</em> ("fallito"), <em>given-back</em> ("restituito"),
<em>skipped</em> ("saltato"). Notare che sulle
<a href="http://buildd.debian.org/";>pagine di buildd</a> viene aggiunto il
prefisso <em>maybe-</em> (forse), perch�tra le altre cose, in passato, il
fatto che una compilazione fosse marcata come <em>failed</em> per motivi che non
erano un <em>reale</em> fallimento ha generato confusione (e, del resto, a volte
un pacchetto che sempra essere stato compilato con successo in realt� errato e
deve essere compilato nuovamente).
</p>
<p>Il significato dei risultati di compilazione �l seguente:</p>
<dl>
<dt><a name="successful">successful</a></dt>
<dd>La compilazione si �onclusa con successo. Dopo aver ricevuto il
log, l'amministratore del nodo firmer�l file <code>.changes</code>
e lo rimander�ndietro, in modo che venga caricato nell'archivio.</dd>
<dt><a name="failed">failed</a></dt>
<dd>La compilazione �allita. Ci sono un sacco di ragioni per cui
questo pu�cadere, che sarebbero difficili da elencare. Se un tuo
pacchetto �arcato <em>(maybe-)failed</em> prova a leggere quanto
riportato sopra e controlla il suo stato di wanna-build</dd>
<dt><a name="given-back">given-back</a></dt>
<dd>La compilazione �allita a causa di problemi temporanei del nodo
che l'ha tentata; potrebbe darsi, per esempio, di problemi di rete,
mancanza del pacchetto sorgente nel file sources.list, spazio disco
insufficiente o altro ancora.<br />
Un pacchetto restituito con il codice <em>given-back</em> verr� nuovamente marcato come <em><a href="#needs-build">needs-build</a></em>,
e sar�uindi automaticamente preso da un altro nodo disponibile.</dd>
<dt><a name="skipped">skipped</a></dt>
<dd>Prima che la compilazione iniziasse, ma dopo che il pacchetto � stato preso dal nodo buildd e marcato come
<em><a href="#building">building</a></em>, �tata caricata una sua
nuova versione oppure il suo stato su wanna-build �tato modificato
manualmente da un responsabile del port. Quando una di queste azioni
viene eseguita, una mail viene inviata al nodo, che quindi non
compiler�l pacchetto (ma generer�n log per descrivere il fatto che
ci�accaduto).</dd>
</dl>
<h2><a name="graphlink">La versione grafica</a></h2>
<p>Per illustrare tutto quanto spiegato, �isponibile un
<a href="wanna-build.png">diagramma di flusso</a> della procedura. Notare che
non contiene tutti gli aspetti menzionati in questo documento.</p>
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente