Wanna-build states: een uitleg

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.

Als u uw pakket opnieuw wilt compileren, kunt u om wanna-build actions vragen.

Tot slot is ook een flowchart-versie van de wanna-build states beschikbaar, maar merk op dat het niet alles behandelt wat in dit document aan bod komt.

De wanna-build states

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: needs-build, building, uploaded, dep-wait, failed, not-for-us, en installed.

Hun betekenis is als volgt:

needs-build

Een pakket dat als needs-build 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 needs-build 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 needs-build status.
Het is interessant om weten dat de needs-build wachtrij geen FIFO lijst is; in plaats daarvan wordt de lijst gesorteerd volgens de volgende criteria:

De vorige compilatiestatus van een pakket; pakketten die voordien reeds gecompileerd werden krijgen prioriteit over nieuwe pakketten.
prioriteiten (pakketten met de required prioriteit worden gecompileerd voor pakketten met de extra prioriteit)
De sectie waarin zich een pakket bevindt. Deze sortering is gebaseerd op welke pakketten als belangrijker beschouwd worden; zo wordt de sectie games gecompileerd na de sectie base, en zal de sectie libs gecompileerd worden vóór devel.
Een asciibetische sortering op de pakket naam.

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.
Er kunnen nog andere situaties zijn waarin de wachtrij-volgorde genegeerd schijnt te zijn; maar merk op dat dit allemaal uitzonderingen zijn.

building

Een pakket wordt als building 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 building 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 niet aangepast wordt wanneer de compilatie afgewerkt is; dit gebeurt pas wanneer de autobuilder admin antwoordt op de logs.

uploaded

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 uploaded overzetten. Dit betekent dat een pakket in deze status zich (ergens) in de incoming queue bevindt.
Een autobuilder zal een pakket niet meer aanraken eens z'n status uploaded is, tenminste niet tot de volgende upload of totdat een porter manueel de status van een pakket aanpast.

dep-wait

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 dep-wait op de ontbrekende build-dependencies te markeren. Een pakket in die status zal automatisch, zonder menselijke interventie, terug als needs-build gemarkeerd worden wanneer de desbetreffende dependencies beschikbaar zijn.
Oorspronkelijk moest een buildd proberen een pakket te compileren vooraleer de beheerder het handmatig in de dep-wait status zou plaatsen. In augustus 2005 werd er echter extra functionaliteit aan wanna-build toegevoegd die ervoor zorgt dat een pakket automatisch van de installed verplaatst wordt, indien dat van toepassing is.
Er zijn twee specifieke situaties waarbij het kan gebeuren dat een pakket in de dep-wait 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 dep-wait 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 not-for-us gemarkeerd is, of dat in de packages-arch-specific lijst zit.
Als voorbeeld voor dat laatste, overweeg drie pakketten: Een pakket foo, dat alleen voor i386 bestaat; een pakket bar, wat alleen voor m68k bestaat (en dat in grote lijnen dezelfde functionaliteit uitvoert); en een pakket baz dat gecompileerd kan worden met één van foo of bar. Indien de maintainer van het pakket baz nu zou vergeten om bar aan de Build-Depends toe te voegen, en zou hij of zij het toevoegen wanneer wordt opgemerkt dat baz in dep-wait staat voor een niet-bestaande foo voor m68k, dan zal de dep-wait-status voor m68k manueel verwijderd moeten worden door de m68k porters.

BD-Uninstallable

Tijdens debconf9 had Joachim Breitner het idee 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.

failed

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 failed 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 failed 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.
Merk op dat een pakket nooit als failed gemarkeerd zal worden zonder menselijke interventie.

not-for-us

Een aantal specifieke pakketten zijn architectuur-specifiek; zo moet bijvoorbeeld lilo, een i386 boot loader, niet gecompileerd worden op alpha, m68k, of s390. Wanna-build 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)
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 not-for-us; maar gezien het feit dat dat moeilijk te beheren is, wordt het gebruik van not-for-us vandaag de dag afgeraden; autobuilder-beheerders gebruiken daarom best packages-arch-specific in de plaats, wat een lijst is van pakketten specifiek voor één of meerdere architecturen, in plaats van een wanna-build status.
Een pakket in not-for-us of packages-arch-specific zal deze status niet 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 manueel terug in de queue gestoken worden.
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.

installed

Zoals de naam al aangeeft is het zo dat een pakket met de status installed reeds gecompileerd is voor de architectuur waarvoor deze wanna-build database is. Voor de release van Woody veranderde de status van een pakket van uploaded naar installed na de dagelijkse katie runs. Sinds de implementatie van Accepted-autobuild is dit ichter niet meer waar; vandaag de dag gaat een pakket van de status uploaded naar de status installed op het moment dat het in het archief geaccepteerd wordt. Dit betekend dat een pakket gewoonlijk als installed gemarkeerd wordt na, gemiddeld, 15 minuten.

Na deze acht states kent wanna-build ook nog twee -removed states, die eigenlijk grensgevallen zijn. Deze twee states zijn dep-wait-removed en failed-removed. Ze relateren met hun respectieve 'gewone' states als volgt: als een pakket in status failed of dep-wait niet voorkomt in een nieuw Packages-bestand dat aan wanna-build 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 -removed 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 failed-removed terug naar failed verplaatst worden, of van dep-wait-removed terug naar dep-wait voordat de verdere verwerking plaatsvindt.

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.

Dat gezegd zijnde kan je zien in welke status een pakket zich bevindt door naar de buildd stats-pagina te gaan, tenzij het in de status installed is (nu ja; niet als je het niet erg vindt om je door een multi-megabyte <arch>-all.txt bestand te worstelen...).

De compilatielog-resultaten

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 successful, attempted (vroeger failed), given-back, of skipped zijn. Merk op dat, op het buildd log overzicht de prefix maybe- toegevoegd wordt, omdat, onder andere, het feit dat een compilatie daar als failed gemarkeerd kan zijn voor dingen die niet echt 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).

De betekenis van de logresultaten is als volgt:

successful: De compilatie is gelukt. Als de autobuilder-beheerder deze log aankrijgt, dan zal hij het .changes-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.
attempted (vroeger: failed): 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 (maybe-)failed gemarkeerd is, dan wil je waarschijnlijk het bovenstaande lezen, en z'n huidige wanna-build status nakijken.
given-back: 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.
Een pakket dat given-back als resultaat heeft wordt terug als needs-build gemarkeerd; dit wil zeggen dat die automatisch terug opgepikt zal worden door een andere autobuilder wanneer er één beschikbaar is.
skipped: In de tijd tussen het als building 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).

De grafische versie

Om het bovenstaande te illustreren, hebben we ook een flowchart-versie van deze procedure beschikbaar gemaakt. Nogmaals, merk op dat deze niet alles wat in dit document aan bod komt, behandelt.