[RFR] wml://www.debian.org/dutch/devel/buildd/wanna-build-states.wml
Dag iedereen,
In de git-opslagplaats webwml werd de vertaling van
dutch/devel/buildd/wanna-build-states.wml bijgewerkt.
In bijlage de bijgewerkte vertaling en een diff-bestand met de wijzigingen
tegenover de vorige versie.
--
Met vriendelijke groet,
Frans Spiesschaert
diff --git a/dutch/devel/buildd/wanna-build-states.wml b/dutch/devel/buildd/wanna-build-states.wml
index 06bfdda772e..7a927fdacba 100644
--- a/dutch/devel/buildd/wanna-build-states.wml
+++ b/dutch/devel/buildd/wanna-build-states.wml
@@ -1,13 +1,16 @@
#use wml::debian::template title="Wanna-build states: een uitleg" BARETITLE="true"
-#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28" maintainer="Wouter Verhelst"
+#use wml::debian::translation-check translation="e94a8736fb66463fe305fff8fd1d7c61341d298d" maintainer="Wouter Verhelst"
- <p>Deze pagina probeert uit te leggen wat elke wanna-build status
+ <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>
+ Als u uw pakket opnieuw wilt compileren, kunt u om <a href="https://release.debian.org/wanna-build.html";>wanna-build actions</a> vragen.
+ </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
@@ -49,7 +52,7 @@ hun huidige compilatiestatus. Er zijn acht states:
</li>
<li>De sectie waarin zich een pakket bevindt. Deze sortering
is gebaseerd op welke pakketten als belangrijker beschouwd
- worden; zo wordt de sectie <em>games</em> gecompileerd
+ worden; zo wordt de sectie <em>games</em> gecompileerd
na de sectie <em>base</em>, en zal de sectie <em>libs</em>
gecompileerd worden vóór <em>devel</em>.
</li>
#use wml::debian::template title="Wanna-build states: een uitleg" BARETITLE="true"
#use wml::debian::translation-check translation="e94a8736fb66463fe305fff8fd1d7c61341d298d" maintainer="Wouter Verhelst"
<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>
Als u uw pakket opnieuw wilt compileren, kunt u om <a href="https://release.debian.org/wanna-build.html";>wanna-build actions</a> vragen.
</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 pakketten en
hun huidige compilatiestatus. Er zijn acht 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 <q>een
pakket staat in de wachtrij om opnieuw gecompileerd te worden</q>
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; pakketten die
voordien reeds gecompileerd werden krijgen prioriteit over
nieuwe pakketten.
</li>
<li>prioriteiten (pakketten met de <em>required</em> prioriteit
worden gecompileerd voor pakketten met de <em>extra</em>
prioriteit)
</li>
<li>De sectie waarin zich een pakket bevindt. Deze sortering
is gebaseerd op welke pakketten als belangrijker beschouwd
worden; zo wordt de sectie <em>games</em> gecompileerd
na de sectie <em>base</em>, en zal de sectie <em>libs</em>
gecompileerd worden vóór <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 pakket 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 pakketten 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)
voordat 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 pakket uploaden en z'n status naar
<em>uploaded</em> overzetten. Dit betekent dat een pakket 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 />
Oorspronkelijk moest een buildd proberen een pakket te
compileren vooraleer de beheerder het handmatig in de
<em>dep-wait</em> status zou plaatsen. In augustus 2005 werd er
echter extra functionaliteit aan wanna-build toegevoegd die
ervoor zorgt dat een pakket automatisch van de <em><a
href='#installed'>installed</a></em> verplaatst wordt, indien
dat van toepassing is.<br />
Er zijn twee specifieke situaties 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="bd-uninstallable">BD-Uninstallable</a></dt>
<dd>Tijdens debconf9 had <a
href='https://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Joachim
Breitner het idee</a> om met edos-debcheck de installeerbaarheid van
build-dependencies te controleren van pakketten die normaal in de
'needs-build' status zouden gaan. Op dat ogenblik had wanna-build wel
de mogelijkheid om de onmiddelijke beschikbaarheid van een pakket te
detecteren; maar als een pakket niet geïnstalleerd kon worden omdat het
afhangt van pakket a dat afhangt van pakket b dat op zijn beurt afhangt
van pakket c (>=1.2.3) waarbij c nog op versie 1.2.2 is, dan werd
dat niet gedetecteerd, en mislukte de compilatie omwille van
niet-beschikbare build-dependencies. Uitzoeken wat daar mis liep was
een handmatig proces voor de buildd-beheerder, en één dat gewoonlijk
nogal veel tijd nodig had. Met de BD-Uninstallable wijziging is dit
niet langer een probleem. Als je pakket zich in BD-Uninstallable
bevindt, dan betekent dat dat één van de build-dependencies niet
installeerbaar is (hetzij onmiddelijk, hetzij omdat een deel van z'n
afhankelijkheidsboom niet beschikbaar is). Helaas is er geen
informatie beschikbaar over welk pakket precies het probleem
veroorzaakt; gelieve edos-debcheck te gebruiken om dit uit te vinden.
Het probleem zal zichzelf echter automatisch oplossen eens de afwezige
afhankelijkheden terug beschikbaar zijn, en op dat ogenblik zal je
pakket automatisch terug naar Needs-Build verplaatst worden.
</dd>
<dt><a name="wanna-build-state-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 pakket <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 pakket wanneer het zijn database opbouwt; alleen naar de
naam, de sectie, en de prioriteit van een pakket. 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 pakketten 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</strong> 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.<br />
Als je dit ooit tegenkomt, dan kan je de relevante
buildd-beheerder vragen dit te doen door ze te mailen op
$arch@buildd.debian.org.
</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="https://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 acht 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> voordat 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="https://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 <q><arch>-all.txt</q> bestand te
worstelen...).
</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
https://buildd.debian.org) kan terechtkomen). Het
compilatielog-resultaat kan één van <em>successful</em>,
<em>attempted</em> (vroeger <em>failed</em>), <em>given-back</em>, of
<em>skipped</em> zijn.
Merk op dat, op <a href="https://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 (of, vice versa, soms is een pakket dat
een successful status heeft eigenlijk stuk en moet het opnieuw
gecompileerd worden).</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">attempted</a> (vroeger: failed)</dt>
<dd>De compilatie heeft niet nul geretourneerd, wat aangeeft dat die
waarschijnlijk mislukt is. 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">De 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: