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.
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.