CVS webwml/dutch/devel/buildd
Update of /cvs/webwml/webwml/dutch/devel/buildd
In directory gluck:/tmp/cvs-serv30235
Added Files:
Makefile wanna-build-states.wml
Log Message:
Intial translation
--- /cvs/webwml/webwml/dutch/devel/buildd/Makefile 2004/12/22 17:17:57 NONE
+++ /cvs/webwml/webwml/dutch/devel/buildd/Makefile 2004/12/22 17:17:57 1.1
include $(subst webwml/dutch,webwml/english,$(CURDIR))/Makefile
--- /cvs/webwml/webwml/dutch/devel/buildd/wanna-build-states.wml 2004/12/22 17:17:57 NONE
+++ /cvs/webwml/webwml/dutch/devel/buildd/wanna-build-states.wml 2004/12/22 17:17:57 1.1
#use wml::debian::template title="Wanna-build states: an explanation" BARETITLE="true"
#use wml::debian::translation-check translation="1.6"
<p>Deze pagina probeert uit te leggen wat elke wanna-build status
betekent, en wat er met een pakket zal gebeuren als het zich in
die status bevindt. Het doelpubliek bestaat uit Debian pakket
maintainers die proberen te begrijpen waarom hun pakket al dan
niet gecompileerd is voor een bepaalde architectuur. Daarnaast
wordt een verduidelijking gegeven van de verschillende
log-resultaten.</p>
<p>Tot slot is ook een flowchart-versie van de wanna-build states <a
href="#graphlink">beschikbaar</a>, maar merk op dat het niet alles
behandelt wat in dit document aan bod komt.</p>
<h2>De wanna-build states</h2>
<p>Voor elke architectuur die Debian ondersteunt is er een wanna-build
database geïnstalleerd op buildd.debian.org, met daarin alle pakkets en
hun huidige compilatiestatus. Er zijn zeven states:
<em>needs-build</em>, <em>building</em>, <em>uploaded</em>,
<em>dep-wait</em>, <em>failed</em>, <em>not-for-us</em>, en
<em>installed</em>.</p>
<p>Hun betekenis is als volgt:</p>
<dl>
<dt><a name="needs-build">needs-build</a></dt>
<dd>Een pakket dat als <em>needs-build</em> gemarkeerd staat werd
door zijn maintainer in een nieuwe versie geuploaded, maar voor
een andere architectuur dan die waarvoor deze wanna-build
database is; daardoor is een hercompilatie noodzakelijk. Als de
status <em>needs-build</em> is, dan is het nog niet opgepikt
door een autobuilder, maar dat zal wel gebeuren (op het moment
dat er één beschikbaar is wanneer dit specifieke pakket zich
bovenaan de lijst bevindt). Mensen zeggen gewoonlijk "een
pakket staat in de wachtrij om opnieuw gecompileerd te worden"
wanneer ze het hebben over een pakket in de
<em>needs-build</em> status.<br>
Het is interessant om weten dat de <em>needs-build</em> wachtrij
geen FIFO lijst is; in plaats daarvan wordt de lijst gesorteerd
volgens de volgende criteria:
<ol>
<li>De vorige compilatiestatus van een pakket; pakkets die
voordien reeds gecompileerd werden krijgen prioriteit over
nieuwe pakkets.
</li>
<li>prioriteiten (pakkets met de <em>required</em> prioriteit
worden gecompileerd voor pakkets met de <em>extra</em>
prioriteit)
</li>
<li>De sectie waarin zich een pakket bevindt. Deze sortering
is gebaseerd op welke pakkets als belangrijker beschouwd
worden; zo wordt de sectie <em>games</em> gecompileerd voor
na de sectie <em>base</em>, en zal de sectie <em>libs</em>
gecompileerd worden voor <em>devel</em>.
</li>
<li>Een asciibetische sortering op de pakket naam.</li>
</ol>
Daarnaast is het zo dat, onder bepaalde omstandigheden, het kan
gebeuren dat een buildd niet het pakket bovenaan de lijst zal
nemen voor compilatie; bijvoorbeeld, wanneer een buildd de
broncode van een gegeven pakket niet kan vinden zal hij het
terug in de queue steken (waar het dan opnieuw op z'n vorige
positie zal terechtkomen, dus bovenaan de lijst), maar hij zal
het pakket voor een aantal uren negeren. Een ander voorbeeld
waar zich dit kan voordoen is wanneer een architectuur meerdere
autobuilders heeft; in dat geval kunnen de porters van die
architectuur ervoor kiezen om grotere pakketten op hun snellere
autobuilders te compileren, terwijl ze de kleinere aan de
tragere machines overlaten. Theoretisch gezien kan een buildd
verder ook expliciet een andere sectie-volgorde opvragen, maar
dat wordt gewoonlijk niet gedaan.<br>
Er kunnen nog andere situaties zijn waarin de wachtrij-volgorde
genegeerd schijnt te zijn; maar merk op dat dit allemaal
uitzonderingen zijn.
</dd>
<dt><a name="building">building</a></dt>
<dd>Een package wordt als <em>building</em> gemarkeert vanaf het
moment dat een autobuilder het oppikt bovenaan de wanna-build
wachtrij tot het moment dat de autobuilder-beheerder een
antwoord stuurt op de log. Vermits packages niet één per één uit
de wachtrij gehaald worden betekent dit dat een pakket als
<em>building</em> gemarkeerd kan zijn (en gewoonlijk ook is)
vooraleer de compilatie daadwerkelijk gestart is; maar vermits
buildd de pakketten in zijn lokale wachtrij op FIFO-basis
compileert, zou het niet te lang meer mogen duren. Daarnaast is
het belangrijk te weten dat de status van een pakket
<strong>niet</strong> aangepast wordt wanneer de compilatie
afgewerkt is; dit gebeurt pas wanneer de autobuilder admin
antwoordt op de logs.
</dd>
<dt><a name="uploaded">uploaded</a></dt>
<dd>Als de poging tot compilatie succesvol was, dan wordt een
build log verstuurd naar de autobuilder admin en naar
buildd.debian.org. De autobuilder admin zal dan het
.changes-bestand dat zich in die log bevindt, ondertekenen, en
terugsturen naar de autobuilder. In reactie daarop zal de
autobuilder het package uploaden en z'n status naar
<em>uploaded</em> overzetten. Dit betekent dat een package in
deze status zich (ergens) in de incoming queue bevindt.<br>
Een autobuilder zal een pakket niet meer aanraken eens z'n
status <em>uploaded</em> is, tenminste niet tot de volgende
upload of totdat een porter manueel de status van een pakket
aanpast.
</dd>
<dt><a name="dep-wait">dep-wait</a></dt>
<dd>Als het compileren van een pakket niet lukt door ontbrekende
build-dependencies, dan zal de autobuilder-beheerder een mail
sturen naar de autobuilder, waarbij hij hem instrueert om de
broncodes van het pakket te verwijderen en het pakket als
<em>dep-wait</em> op de ontbrekende build-dependencies te
markeren. Een pakket in die status zal automatisch, zonder
menselijke interventie, terug als <em>needs-build</em>
gemarkeerd worden wanneer de desbetreffende dependencies
beschikbaar zijn.<br>
Dit betekent dat er maar twee specifieke situaties zijn waarbij
het kan gebeuren dat een pakket in de <em>dep-wait</em> status
blijft; deze zijn wanneer een tikfout zich voorgedaan heeft bij
het specifiëren va de dep-wait dependencies (zodat het pakket
zich in de <em>dep-wait</em> status bevindt voor een pakket dat
niet bestaat en ook nooit zal bestaan) en wanneer een
build-depencency gedeclareerd is op een pakket dat als
<em>not-for-us</em> gemarkeerd is, of dat in de
<em>packages-arch-specific</em> lijst zit.<br>
Als voorbeeld voor dat laatste, overweeg drie pakketten: Een
pakket <tt>foo</tt>, dat alleen voor <tt>i386</tt> bestaat; een
pakket <tt>bar</tt>, wat alleen voor <tt>m68k</tt> bestaat (en
dat in grote lijnen dezelfde functionaliteit uitvoert); en
een pakket <tt>baz</tt> dat gecompileerd kan worden met één van
<tt>foo</tt> of <tt>bar</tt>. Indien de maintainer van het
pakket <tt>baz</tt> nu zou vergeten om <tt>bar</tt> aan de
Build-Depends toe te voegen, en zou hij of zij het toevoegen
wanneer wordt opgemerkt dat <tt>baz</tt> in <em>dep-wait</em>
staat voor een niet-bestaande <tt>foo</tt> voor <tt>m68k</tt>,
dan zal de <em>dep-wait</em>-status voor <tt>m68k</tt> manueel
verwijderd moeten worden door de <tt>m68k</tt> porters.
</dd>
<dt><a name="failed">failed</a></dt>
<dd>Als een compilatiepoging mislukt is, en de
autobuilder-beheerder beslist dat het daadwerkelijk een
mislukking is die niet opnieuw geprobeerd moet worden, dan zal
het pakket als <em>failed</em> gemarkeerd worden. Een pakket zal
deze status niet verlaten totdat een porter beslist dat dat een
goed idee is, of totdat een nieuwe versie beschikbaar is. Wel is
het zo dat, wanneer een nieuwe versie beschikbaar is van een
pakket dat eerder als <em>failed</em> gemarkeerd was, de
autobuilder z'n beheerder eerst zal vragen of het pakket
opnieuw gecompileerd moet worden; dit is opdat pakketten die
duidelijk niet gecompileerd zullen kunnen worden, geen buildd
tijd zullen verspillen. Hoewel dit zelden nodig is, is de
mogelijkheid beschikbaar voor de autobuilder-beheerder.<br>
Merk op dat een package <strong>nooit</strong> als
<em>failed</em> gemarkeerd zal worden zonder menselijke
interventie.
</dd>
<dt><a name="not-for-us">not-for-us</a></dt>
<dd>Een aantal specifieke pakketten zijn architectuur-specifiek;
zo moet bijvoorbeeld <tt>lilo</tt>, een i386 boot loader, niet
gecompileerd worden op alpha, m68k, of s390.
<em>Wanna-build</em> kijkt echter niet naar de control file van
een package wanneer het zijn database opbouwt; alleen naar de
naam, de sectie, de dringendheid, en de prioriteit van een
package. Daardoor zal na de eerste upload van een
architectuur-specifiek pakket dat niet op een andere
architectuur gecompileerd moet worden, toch een poging gedaan
worden op andere architecturen (deze zal echter mislukken nog
voor de build-dependencies gedownloaded en geïnstalleerd
zijn)<br>
Vermits autobuilders geen tijd moeten verspelen aan het
compileren van packages die niet interessant zijn voor hun
architectuur, is er een manier nodig om pakketten op te sommen
waarvoor zelfs een poging om ze te compileren niet noodzakelijk
is. De eerste oplossing voor dit probleem was
<em>not-for-us</em>; maar gezien het feit dat dat moeilijk te
beheren is, wordt het gebruik van <em>not-for-us</em> vandaag de
dag afgeraden; autobuilder-beheerders gebruiken daarom best
<em>packages-arch-specific</em> in de plaats, wat een lijst is
van pakketten specifiek voor één of meerdere architecturen, in
plaats van een wanna-build status.<br>
Een pakket in <em>not-for-us</em> of
<em>packages-arch-specific</em> zal deze status
<strong>niet</em> uit zichzelf verlaten; als jouw pakket een
gegeven architectuur in zijn control file expliciet niet
bevatte, maar die nu wel bevat, dan moet je pakket
<strong>manueel</strong> terug in de queue gestoken worden.
</dd>
<dt><a name="installed">installed</a></dt>
<dd>Zoals de naam al aangeeft is het zo dat een pakket met de
status <em>installed</em> reeds gecompileerd is voor de
architectuur waarvoor deze wanna-build database is. Voor de
release van Woody veranderde de status van een pakket van
<em>uploaded</em> naar <em>installed</em> na de dagelijkse katie
runs. Sinds de implementatie van <a
href="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html";>Accepted-autobuild</a>
is dit ichter niet meer waar; vandaag de dag gaat een pakket van
de status <em>uploaded</em> naar de status <em>installed</em> op
het moment dat het in het archief geaccepteerd wordt. Dit
betekend dat een pakket gewoonlijk als <em>installed</em>
gemarkeerd wordt na, gemiddeld, 15 minuten.
</dd>
</dl>
<p>Na deze zeven states kent <em>wanna-build</em> ook nog twee
-removed states, die eigenlijk grensgevallen zijn. Deze twee states
zijn <em>dep-wait-removed</em> en <em>failed-removed</em>. Ze
relateren met hun respectieve 'gewone' states als volgt: als een
pakket in status <em>failed</em> of <em>dep-wait</em> niet voorkomt
in een nieuw Packages-bestand dat aan <em>wanna-build</em> gevoed
wordt – als het er op lijkt dat het verwijderd is – dan
wordt de informatie van dat pakket niet weggegooid, vermits het
mogelijk is dat het niet verschijnen van het pakket in het
Packages-bestand maar een tijdelijk probleem is, of dat het pakket
tijdelijk verwijderd is om één of andere reden (maar dat het, mits
wat geduld, wel terug zal komen). In zo'n geval wordt het pakket
daarom naar een <em>-removed</em> status gebracht, zodat de
informatie over waarom de compilatie mislukt is, of waar het op aan
het wachten is, behouden kan worden. Zou het pakket dan ooit in een
nieuw Packages-bestand dat aan wanna-build gevoed wordt, voorkomen,
dan zal het van <em>failed-removed</em> terug naar <em>failed</em>
verplaatst worden, of van <em>dep-wait-removed</em> terug naar
<em>dep-wait</em> vooraleer de verdere verwerking plaatsvindt.</p>
<p>
Het is niet mogelijk om de wanna-build database rechtstreeks te
bevragen; deze database is geïnstalleerd op ftp-master.debian.org,
wat een beperkte host is, en enkel autobuilders hebben een
SSH-sleutel die hen toelaat om de wanna-build database van hun
architectuur te manipuleren. Dit was zelfs het geval voor
ftp-master beperkt was; vermits wanna-build een database-level
lock doet bij het benaderen, zelfs al gaat het alleen over lezen,
van de gegevens, moest je in de juiste groep zijn
(wb-<arch>) om een wanna-build database rechtstreeks te
kunnen beheren.
</p>
<p>Dat gezegd zijnde kan je zien in welke status een pakket zich
bevindt door naar <a href="http://buildd.debian.org/stats/";>de
buildd stats-pagina</a> te gaan, tenzij het in de status
<em>installed</em> is (nu ja; niet als je het niet erg vindt om je
door een multi-megabyte "<arch>-all.txt" bestand te
worstelen...). Alternatief zijn er een aantal webpagina's
beschikbaar via <a
href="http://crest.debian.org/";>crest.debian.org</a>, die
gebaseerd zijn op het parsen van de
<arch>-all.txt-bestanden, en die een makkelijker leesbare
manier geven (tenminste voor mensen) om te zien in welke status
een pakket zich bevindt.
</p>
<h2>De compilatielog-resultaten</h2>
<p>
Als een pakket gecompileerd is door sbuild (het onderdeel van
buildd wat de eigenlijke compilatie doet), dan wordt een log met
het compilatieresultaat via e-mail verzonden naar de
autobuilder-beheerder en naar logs@buildd.debian.org (zodat het op
http://buildd.debian.org) kan terechtkomen). Het
compilatielog-resultaat kan één van <em>successful</em>,
<em>failed</em>, <em>given-back</em>, of <em>skipped</em> zijn.
Merk op dat, op de <a href="http://buildd.debian.org";>het buildd
log overzicht</a> de prefix <em>maybe-</em> toegevoegd wordt,
omdat, onder andere, het feit dat een compilatie daar als
<em>failed</em> gemarkeerd kan zijn voor dingen die niet
<em>echt</em> een mislukte compilatie zijn, in het verleden
verwarring gezaaid heeft.</p>
<p>De betekenis van de logresultaten is als volgt:</p>
<dl>
<dt><a name="successful">successful</a></dt>
<dd>De compilatie is gelukt. Als de autobuilder-beheerder deze log
aankrijgt, dan zal hij het <code>.changes</code>-bestand dat
zich in de log bevindt eruit halen, dit ondertekenen, en zo
terugsturen naar de autobuilder, wat tot gevolg zal hebben dat
het pakket geuploaded wordt.</dd>
<dt><a name="failed">failed</a></dt>
<dd>De compilatie is mislukt. Vermits er een groot aantal redenen
kan zijn waarom een compilatie mislukt, zou het heel wat werk
vergen om ze allemaal op te noemen, dus er wordt geen poging
gedaan om dat te doen. Als één van jouw pakketten als
<em>(maybe-)failed</em> gemarkeerd is, dan wil je waarschijnlijk
het bovenstaande lezen, en z'n huidige wanna-build status
nakijken.
</dd>
<dt><a name="given-back">given-back</a></dt>
<dd>De compilatie is mislukt door een tijdelijk probleem met de
autobuilder; voorbeelden zijn netwerkproblemen, het niet
bereikbaar zijn van de broncode van het te compileren pakket met
de huidige sources.list, weinig schijfruimte, en andere.<br>
Een pakket dat <em>given-back</em> als resultaat heeft wordt
terug als <em><a href="#needs-build">needs-build</a></em>
gemarkeerd; dit wil zeggen dat die automatisch terug opgepikt
zal worden door een andere autobuilder wanneer er één
beschikbaar is.
</dd>
<dt><a name="skipped">skipped</a></dt>
<dd>In de tijd tussen het als <em>building</em> markeren van een
pakket door een autobuilder en de compilatiepoging was een
nieuwe versie van dit pakket geuploaded, of heeft een porter de
wanna-build status om een andere reden aangepast. Wanneer zich
dat voordoet wordt een mail naar de autobuilder gestuurd,
waardoor die het pakket zal markeren alszijnde dat die niet
gecompileerd moet worden; sbuild zal dit zien, en zal de
compilatie overslaan (hoewel een compilatielog met dit resultaat
verzonden wordt, waarin het feit dat dit gebeurd is, weergegeven
wordt).
</dd>
</dl>
<h2><a name="graphlink">The grafische versie</a></h2>
<p>Om het bovenstaande te illustreren, hebben we ook een <a
href="wanna-build.png">flowchart-versie</a> van deze procedure
beschikbaar gemaakt. Nogmaals, merk op dat deze niet alles wat in dit
document aan bod komt, behandelt.</p>
Reply to: