1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
|
#use wml::debian::template title="Stati di wanna-build: una spiegazione" BARETITLE="true"
#use wml::debian::translation-check translation="e94a8736fb66463fe305fff8fd1d7c61341d298d" 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 i 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>
Se avete bisogno di una ricompilazione del vostro pacchetto, potete richiedere
una delle <a href="https://release.debian.org/wanna-build.html">azioni
wanna-build</a>
</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>dipendenze di compilazione non installabili</q>)</a></dt>
<dd>Durante il Debconf9, <a href='https://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="https://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="https://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 https://buildd.debian.org). Il
risultato del log di compilazione può essere <em>successful</em> (<q>riuscito</q>),
<em>attempted</em> (<q>tentato</q>, in passato era <em>failed</em>, <q>fallito</q>),
<em>given-back</em> (<q>restituito</q>),
<em>skipped</em> (<q>saltato</q>). Notare che sulle
<a href="https://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">attempted</a> (in passato: failed)</dt>
<dd>La compilazione ha restituito uno stato non-zero, ciò indica che
probabilmente è 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>
|