Ciao a tutti. Ho aggiornato un paio di pagine del sito di Debian, delle quali sono mantenitore. Qualcuno potrebbe revisionarle e caricarle sul CVS? Grazie, Giovanni. -- Giovanni Mascellani <mascellani@poisson.phc.unipi.it> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org
#use wml::debian::template title="Autobuilder network" #use wml::debian::translation-check translation="1.21" maintainer="Giovanni Mascellani" <p>La rete di buildd è un 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 è formata 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 è necessaria 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 o amd64). 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ò questo metodo era facilmente soggetto ad errori ed estremamente costoso in termini di tempo, ma è stato 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 è capace di mantenere quasi automaticamente le varie distribuzioni Debian aggiornate. </p> <h2>Come funziona buildd?</h2> <p><em>Buildd</em> è il nome che di solito si dà ai programmi utilizzati della rete, ma in realtà è però diviso in parti diverse:</p> <dl> <dt>wanna-build</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'è un database centrale per ogni architettura che memorizza lo stato dei pacchetti, la loro versione e qualche altra informazione. </dd> <dt><a href="http://packages.debian.org/buildd">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. Una volta che la compilazione viene approvata da un amministratore, carica il pacchetto nell'archivio appropriato. </dd> <dt><a href="http://packages.debian.org/sbuild">sbuild</a></dt> <dd> è responsabile dell'effettiva compilazione dei pacchetti in chroot isolate. Si assicura che tutte le dipendenze di compilazione siano soddisfatte, poi, utilizzando comandi standard di Debian, avvia la compilazione. I log di compilazione sono aggiunti al <a href="http://buildd.debian.org">database dei log di compilazione</a>. </dd> <dt><a href="http://packages.debian.org/quinn-diff">quinn-diff</a></dt> <dd> confronta la lista dei pacchetti disponibili per due diverse architetture ed elenca le differenze (comparando un file Sources ed un file Packages). </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à lo 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à aggiunto 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à della lista sono lo stato della precedente compilazione (<em>Out-Of-Date</em>, "non aggiornato", oppure <em>Uncompiled</em>, "non compilato"), la priorità del pacchetto, la sua sezione ed il suo nome. Inoltre, per evitare che alcuni pacchetti rimangeno sempre in fondo alla coda e non vengano mai compilati, le priorità sono aggiustate dinamicamente man mano che il tempo di attesa aumenta.</p> <p>Se la compilazione ha successo su tutte le architetture, il mantenitore non avrà bisogno di fare niente. Tutti i pacchetti binari saranno caricati nell'archivio corrispondente. Se la compilazione non finisce con successo, il pacchetto entrerà in uno stato speciale (<em>Build-Attempted</em>, "compilazione tentata", per compilazioni fallite che non sono state ancora revisionate dagli amministratori, <em>Failed</em>, "fallito", una volta che il fallimento è stato revisionato e riportato come bug, oppure <em>Dep-Wait</em>, "aspetta le dipendenze", se presentano dipendenze di compilazione non 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>. Se un pacchetto sta bloccando una transizione tipicamente le priorità di compilazione vengono aggiustate su richiesta del Team di Rilascio. Altre richieste di questo tipo non saranno accettate, dal momento che il pacchetto guadagna automaticamente priorità man mano che rimane nella coda.</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 è consultare i codici sorgente e la documentazione disponibile. Inoltre, la sezione <a href="$(HOME)/doc/manuals/developers-reference/pkgs#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é informazioni sui <a href="$(HOME)/doc/manuals/developers-reference/tools#tools-builders">\ compilatori di pacchetti</a> e <a href="$(HOME)/doc/manuals/developers-reference/tools#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 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ò anche 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> <h2>Contattare gli amministratori dei nodi buildd</h2> <p>Gli amministratori responsabili per i nodi buildd di una particolare architetture possono essere raggiunti all'indirizzo <email arch@buildd.debian.org>, per esempio <email i386@buildd.debian.org>.</p> <hrline /> <p><small>Questa introduzione alla rete di buildd è stata scritta mettendo insieme pezzetti appartenenti a Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine, Javier Fernández-Sanguino e Philipp Kern.</small></p>
#use wml::debian::template title="Stati di wanna-build: una spiegazione" BARETITLE="true" #use wml::debian::translation-check translation="1.21" maintainer="Giovanni Mascellani" <p>Questa pagina tenta di spiegare qual è il significato di ciascuno degli stati di wanna-build e cosa succede ad un pacchetto quando è in ciascuno stato. È principalmente scritto per il manutentori che stanno cercando di capire come mai il loro pacchetto è o non è stato 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ò che è menzionato in questa pagina.</p> <h2>Gli stati di wanna-build</h2> <p>Per ogni architettura supportata da Debian c'è un database wanna-build installato su buildd.debian.org, che contiene lo stato corrente di tutti i pacchetti. Esistono otto stati: <em>Needs-Build</em>, <em>Building</em>, <em>Uploaded</em>, <em>Dep-Wait</em>, <em>BD-Uninstallable</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 è questo:</p> <dl> <dt><a name="needs-build">Needs-Build (<q>compilazione necessaria</q>)</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 è stato ancora preso da nessun nodo compilatore, ma che presto lo sarà (non appena una macchina è disponibile ed il pacchetto è in cima alla lista). Spesso si dice che <q>un pacchetto è nella coda di ricompilazione</q> quando si vuole intendere che è in stato di <em>Needs-Build</em>.<br /> È interessante notare che la cosa dei <em>Needs-Build</em> non è in realtà una coda FIFO; al contrario, l'ordinamento utilizzato è basato su questi criteri: <ol> <li>Stato precedente di compilazione; pacchetti che sono già stati compilati in passato ricevono una priorità maggiore 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 è basato su quali sezioni sono considerate più importanti; 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ò accadere 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à nella coda (dove tornerà subito nella posizione che aveva prima, ossia in testa), ma lo ignorerà per 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ù grandi sulle macchine più potenti, lasciando i più piccoli alle macchine più lente. Una macchina di compilazione teoricamente può anche 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 (<q>in compilazione</q>)</a></dt> <dd>Un pacchetto è marcato 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é buildd 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 (<q>caricato sul server</q>)</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à digitalmente il file .changes incluso nel log e lo rimanderà al demone di compilazione, che a sua volta caricherà il pacchetto compilato sul server ed imposterà il suo stato a <em>Uploaded</em>. Un pacchetto in questo stato può quindi essere trovato da qualche parte nella coda incoming.<br /> Un nodo di buildd non toccherà più un pacchetto se il suo stato è <em>Uploaded</em>, perlomeno fino a che non sarà disponibile una sua versione o fino a che un porter modificherà manualmente lo stato del pacchetto.</dd> <dt><a name="dep-wait">Dep-Wait (<q>aspetta le dipendenze</q>)</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à automaticamente marcato, senza necessità di 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ò nell'agosto del 2005 è stato 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 è il caso.<br /> Ci sono due casi particolari nei quali può accadere che un pacchetto rimanga per sempre in stato <em>Dep-Wait</em>, ossia quando si è sbagliato a scrivere il nome di una dipendenza di compilazione (cosicché il pacchetto rimarrà perpetuamente in <em>Dep-Wait</em> su un pacchetto che non esiste e che mai esisterà) e quando una dipendenza è dichiarata 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ò essere 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> è in 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="bd-uninstallable">BD-Unistallable (<q>??</q>)</a></dt> <dd>Durante il Debconf9, <a href='http://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Joachim Breitner ha avuto l'idea</a> di utilizzare edos-debcheck per verificare l'installabilità delle dipendenze di compilazione senza far entrare necessariamente il pacchetto nello stato Needs-Build. In realtà wanna-build aveva già la capacità di controllare la disponibilità delle dipendenze di compilazione immediate; però non si sarebbe accorto, per esempio, di un pacchetto a che dipendeva da un pacchetto b, che a sua volta dipendeva da c (>= 1.2.3), quando c era ancora alla versione 1.2.2. Chiaramente, in questo caso la compilazione sarebbe fallita molto presto a causa di dipendenze mancanti, ma l'amministratore del nodo di compilazione avrebbe dovuto rendersi conto manualmente di questo fatto, perdendoci un certo tempo. Dopo l'aggiunta dello stato BD-Uninstallable questo non è più un problema. Quando un tuo pacchetto è nello stato BD-Uninstallable, vuol dire che alcune sue dipendenze non sono installabili (possono essere dipendenze dirette o parti mancanti più profonde dell'albero delle dipendenze). Purtroppo questa modifica non rende wanna-build in grado di fornire informazioni su quale pacchetto manca esattamente; per favore, usa edos-debcheck per capirlo. Il problema, comunque, sarà risolto automaticamente non appena le dipendenze richieste diventano disponibili; a quel punto il pacchetto sarà automaticamente spostato nello stato Needs-Build.</dd> <dt><a name="wanna-build-state-failed">Failed (<q>fallito</q>)</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 è marcato come <em>Failed</em>. Un pacchetto non lascerà questo stato fino a quanto un porter lo deciderà o fino a quando sarà disponibile una nuova versione. Comunque, quando è disponibile una nuova versione di un pacchetto che era marcato <em>Failed</em> nella versione precedente, la macchina di compilazione chiederà al suo amministratore se veramente il pacchetto deve essere elaborato nuovamente o no; questo per evitare di sprecare risorse se è chiaro che l'operazione fallirà di nuovo. Benché dare per fallita una compilazione che non si è provata è molto difficilmente la cosa giusta da fare, l'opzione di farlo è però disponibile 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 (<q>non per noi</q>)</a></dt> <dd>Certi pacchetti sono specifici per un'architettura; per esempio, <tt>lilo</tt>, un boot loader per i386, non dovrà essere 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, è necessario un modo per identificare tali pacchetti. La prima soluzione a questo problema è stata <em>Not-For-Us</em>; però, dal momento che è difficile da mantenere, è oggi deprecata; i mantenitori di buildd dovrebbero usare al suo posto <em>packages-arch-specific</em>, che non è uno stato di <em>wanna-build</em>, ma una lista di pacchetti specifici per una o più architetture.<br /> Un pacchetto in <em>Not-For-Us</em> o in <em>packages-arch-specific</em> <strong>non</strong> lascerà automaticamente 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 (<q>installato</q>)</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ò, questo non è più vero; oggi un pacchetto passa da <em>Uploaded</em> a <em>Installed</em> quando è accettato nell'archivio, ossia dopo circa quindici minuti.</dd> </dl> <p>Oltre a questi otto 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> è questo: quando un pacchetto in stato <em>Failed</em> o <em>Dep-Wait</em> non compare più in un file Packages passato a <em>wanna-build</em> – ossia quando quest'ultimo si rendo conto che il pacchetto è stato rimosso – le informazioni relative non sono cancellate, perché la mancanza del pacchetto potrebbe essere semplicemente dovuta ad un problema temporaneo, o ad un rimozione provvisioria (il pacchetto ricomparirà nell'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 è possibile 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ì succedeva anche prima che ftp-master fosse ad accesso ristretto; poiché <em>wanna-build</em> necessità di un lock a livello di database anche durante la semplice lettura, era necessario essere nel gruppo giusto (wb-<arch>) per accedere direttamente al un database.</p> <p>Tuttavia, è possibile vedere lo stato di un pacchetto andando sulla <a href="http://buildd.debian.org/stats/">pagina delle statistiche di buildd</a>, tranne che se è nello stato <em>Installed</em> (a meno che non ti dia problemi andare a cercare nei lunghissimi file "<arch>-all.txt"...).</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ò essere <em>successful</em> (<q>riuscito</q>), <em>failed</em> (<q>fallito</q>), <em>given-back</em> (<q>restituito</q>), <em>skipped</em> (<q>saltato</q>). 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 è il seguente:</p> <dl> <dt><a name="successful">successful</a></dt> <dd>La compilazione si è conclusa con successo. Dopo aver ricevuto il log, l'amministratore del nodo firmerà il file <code>.changes</code> e lo rimanderà indietro, in modo che venga caricato nell'archivio.</dd> <dt><a name="failed">failed</a></dt> <dd>La compilazione è fallita. Ci sono un sacco di ragioni per cui questo può accadere, che sarebbero difficili da elencare. Se un tuo pacchetto è marcato <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 è fallita 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à quindi 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>, è stata caricata una sua nuova versione oppure il suo stato su wanna-build è stato modificato manualmente da un responsabile del port. Quando una di queste azioni viene eseguita, una mail viene inviata al nodo, che quindi non compilerà il pacchetto (ma genererà un 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, è disponibile 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: OpenPGP digital signature