Opis stanów wanna-build

Na tej stronie znajdują się opisy poszczególnych stanów wanna-build oraz to, co dzieje się z pakietem, kiedy zostaje mu nadany określony stan. Opis ten kierowany jest do opiekunów pakietów Debiana, którzy chcą zrozumieć dlaczego ich pakiet został (lub nie) zbudowany dla określonej architektury. Na stronie znajduje się także opis różnych wyników, jakie mogą znaleźć się w logu.

Na końcu dostępny jest wykres przedstawiający stany wanna-build, ale należy pamiętać że nie zawiera on wszystkiego, o czym jest mowa w tym dokumencie.

Stany wanna-build

Dla każdej wspieranej przez Debiana architektury istnieje baza wanna-build zainstalowana na buildd.debian.org, która zawiera informacje o wszystkich pakietach i ich obecnym stanie kompilacji. Istnieje 8 stanów: needs-build, building, uploaded, dep-wait, BD-Uninstallable, failed, not-for-us oraz installed.

Ich znaczenie jest następujące:

needs-build
Pakiet oznaczony needs-build to pakiet, którego nowa wersja, przeznaczona na inną architekturę, niż obsługiwana przez daną bazę wanna-build, została wgrana przez opiekuna; pakiet taki wymaga ponownej kompilacji. Pakiet o tym stanie nie jest od razu pobierany przez autobuilder, ale będzie, kiedy znajdzie się na początku listy z pakietami do zbudowania. Zazwyczaj mówi się o pakiecie w stanie needs-build że czeka on w kolejce do zbudowania. Warto wspomnieć, że kolejka needs-build nie jest kolejką FIFO, kolejność w niej jest wyznaczana według reguł w następującej kolejności:
  1. Poprzedni stan kompilacji pakietu - pakiety, które były już budowane mają pierwszeństwo przed nowymi pakietami.
  2. priorytety - pakiety z priorytetem required są budowane przed pakietami z priorytetem extra.
  3. Sekcja, w jakiej znajduje się pakiet. Kolejność jest ustawiana wg ważności, np. sekcja games jest budowana po sekcji base, a sekcja libs jest budowana przed devel.
  4. kolejność alfabetyczna wg nazw pakietów.
Ponadto, w pewnych okolicznościach, może się zdażyć, że buildd nie obsłuży pakietu z początku kolejki, np. kiedy buildd nie może znaleźć źródeł danego pakietu, wtedy odkłada go z powrotem do kolejki (na zajmowaną wcześniej pozycję, np. na początku kolejki), ale będzie ignorował taki pakiet przez kilka godzin. Inna sytuacja, w której może to się stać, to kiedy osoba portująca na daną architekturę zechce zbudować większy pakiet na swojej szybszej maszynie a mniejsze pakiety zostawi w kolejce na wolniejszej maszynie. Teoretycznie buildd może wprost zażądać innej kolejności sekcji, ale nie jest to często robione.
Mogą wystąpić także inne sytuacje, w których kolejność kolejki zostanie zignorowana, ale należy zauważyć, że są to wyjątki.
building
Pakiet jest oznaczony jako building od momentu pobrania go z początku kolejki wanna-build do momentu wysłania przez administratora odpowiedzi na log. Ponieważ pakiety nie są pobierane z kolejki jeden za drugim, pakiet może być (i zazwyczaj jest) oznaczony jako building przed faktycznym rozpoczęciem budowania, jednakże, ponieważ buildd buduje pakiety wg własnej lokalnej kolejki FIFO, nie trwa to długo. Należy zaznaczyć również, że status pakietu nie jest modyfikowany z chwilą zakończenia budowania, tylko w momencie nadesłania przez administratora odpowiedzi na wygenerowany log.
uploaded
Kiedy próba budowania powiedzie się, log z tej operacji jest wysyłany do administratora autobuildera oraz do buildd.debian.org. Następnie opiekun autobuildera podpisuje plik .changes dołączony do logu i odsyła go do autobuildera. Po otrzymaniu takiej odpowiedzi autobuilder wysyła pakiet i ustawia jego status na uploaded. Jako taki pakiet w tym stanie można znaleźć w kolejce przychodzącej (gdzieś).
Autobuilder nie dotknie więcej pakietu, któremu nadano status uploaded, dopóki nie pojawi się następna wersja kodu lub dopóki osoba portująca nie zmieni stanu pakietu ręcznie.
dep-wait
Kiedy budowanie pakietu nie powiedzie się z powodu brakujących w czasie budowania zależności, opiekun autobuildera wysyła wiadomość do autobuildera z poleceniem usunięcia źródeł pakietu i oznaczenia pakietu jako dep-wait z powodu brakujących zależności. Pakiet w tym stanie zostanie automatycznie, bez ludzkiej interwencji, oznaczony jako needs-build, kiedy tylko wymienione zależności będą spełnione.
Początkowo musiała być podjęta próba zbudowania pakietu, zanim opiekun ręcznie umieszczał go w stanie dep-wait. Jednakże w sierpniu 2005 roku dodano do wanna-build kod, który przenosił pakiet ze stanu installed bezpośrednio do stanu dep-wait jeśli było to konieczne.
Istnieją dwa szczególne przypadki, w których pakiet zostanie oznaczony na zawsze jako dep-wait: pierwszy z nich, to błąd przy opisywaniu zależności dep-wait (czyli oznaczenie pakietu jako dep-wait z powodu pakietu, którego nie ma i nigdy nie będzie), drugi to kiedy w zależnościach podano pakiet, który jest oznaczony jako not-for-us, lub który jest na liście packages-arch-specific.
Jako przykład rozważmy trzy pakiety: pakiet foo, który istnieje tylko dla i386; pakiet bar, który istnieje tylko dla m68k (i który w przybliżeniu dostarcza tych samych funkcji); oraz pakiet baz, który może być budowany zarówno z foo jak i bar. Zakładamy, że opiekun pakietu baz zapomniał dodać bar do Build-Depends, zakładamy także, że on lub ona dodał(a) go kiedy pojawił się komunikat, że baz przeszedł do stanu dep-wait z powodu nieistniejącego foo dla m68k, wtedy dep-wait dla m68k musi być ręcznie zdjęty przez osobę portującą dla m68k.
BD-Uninstallable
Podczas debconf9, Joachim Breitner przedstawił pomysł użycia edos-debcheck do weryfikacji możliwości instalacji wymaganych pakietów, które w przeciwnym razie przejdą do stanu Needs-Build. W tym momencie, wanna-build posiada możliwość sprawdzenia bezpośredniej dostępności pakietów wymienionych w build-dependencies, ale jeśli pakiet nie może być zainstalowany, ponieważ zależy on od pakietu a, który zależy od pakietu b, który zależy od pakietu c (>=1.2.3) a pakiet c wciąż jest w wersji 1.2.2, taka sytuacja nie będzie wykryta a budowanie nie powiedzie się na wczesnym etapie z powodu niedostępnych zależności. Obsłużenie takiej sytuacji było zadaniem administratora buildd, i zazwyczaj zadaniem długotrwałym. Po zastosowaniu łatki BD-Uninstallable nie jest to już problemem. Kiedy pakiet jest w stanie BD-Uninstallable oznacza to, że jeden z wymaganych pakietów nie jest dostępny do instalacji (zarówno natychmiastowej, lub z powodu niedostępności zależności dla wymaganego pakietu). Niestety, wspomniana łatka nie dostarcza informacji, którego dokładnie pakietu brakuje, należy użyć edos-debcheck aby otrzymać takie informacje. Problem budowania będzie jednakże rozwiązany samoistnie, kiedy tylko brakujące zależności będą rzeczywiście dostępne - w tym momencie pakiet zostanie automatycznie przeniesiony ponownie do Needs-Build.
failed
Jeżeli próba budowania nie powiodła się, a opiekun autobuildera zadecyduje, że jest to prawdziwy błąd i nie należy ponawiać operacji, pakiet zostaje oznaczony jako failed. Pozostaje on w tym stanie dopóki osoba portująca nie zadecyduje inaczej lub do czasu pojawienia się nowej wersji. Jednakże, kiedy pojawia się nowa wersja pakietu, który w poprzedniej wersji został oznaczony jako failed, autobuilder zapyta administratora czy powinna być ponowiona próba zbudowania danego pakietu; takie działanie podyktowane jest tym, aby pakiet, którego budowanie najpewniej ponownie nie powiedzie się, nie marnował czasu systemu buildd. Pomimo, że ustawienie stanu pakietu na failed przed próbą zbudowania pakietu prawie nigdy nie jest właściwym działaniem, taka opcja jest dostępna dla administratora autobuildera.
Należy zaznaczyć, że pakiet nigdy nie będzie oznaczony jako failed bez interwencji człowieka.
not-for-us
Niektóre pakiety są specyficzne dla danej architektury, np. lilo, program ładujący dla i386, nie powiniem być budowany dla architektury alpha, m68k lub s390. Jednakże wanna-build nie sprawdza pliku kontrolnego pakietu kiedy tworzy swoją bazę; sprawdzane są: nazwa pakietu i sekcja w jakiej się znajduje, poprzedni stan budowania oraz jego priorytet. Z tego powodu, przy pierwszym załadowaniu pakietu dedykowanego dla konkretnej architektury, który nie powinien być budowany na innych architekturach, buildd podejmie jednak próbę, która oczywiście zakończy się niepowodzeniem jeszcze przed pobraniem i/lub zainstalowaniem zależności wymaganych podczas budowania.
Ponieważ autobuilder nie powinien marnować czasu próbując budować pakiety, które nie są potrzebne dla danej architektury, istniała potrzeba utworzenia listy pakietów, dla których nie powinna być nawet podejmowana próba budowania. Pierwszym rozwiązaniem tego problemu było zastosowanie statusu not-for-us, jednakże, z uwagi na problemy w zarządzaniu, status ten nie jest teraz używany. Opiekunowie autobuildera powinni używać packages-arch-specific, który jest listą pakietów specyficznych dla jednej lub kilku architektur, zamiast korzystać ze statusów wanna-build.
Pakiety w not-for-us lub packages-arch-specific nie pozbędą się tego statusu automatycznie. Jeżeli pakiet wykluczał konkretne architektury poprzez swój plik kontrolny, ale teraz obsługuje więcej architektur, należy ręcznie dodać go do właściwej kolejki.
W przypadku konieczności wprowadzenia takiej zmiany w stosunku do naszego pakietu, należy poinformować o tym odpowiedniego opiekuna buildd. Można się z nimi skontaktować poprzes adres $arch@buildd.debian.org.
installed
Jak sama nazwa sugeruje, pakiet oznaczony jako installed został skompilowany dla architektury, która jest obsługiwana przez daną bazę wanna-build. Przed wydaniem dystrybucji Woody, zmiana stanu pakietu z uploaded na installed następowała po codziennym uruchamianiu katie. Jednakże po zaimplementowaniu Accepted-autobuild, zostało to zmienione. Teraz pakiet przechodzi ze stanu uploaded do installed kiedy zostanie zaakceptowany do przejścia do archiwum. Oznacza to, że pakiet zazwyczaj zostanie oznaczony jako installed średnio po około 15 minutach.

Dodatkowo, poza wymienionymi ośmioma statusami, wanna-build obsługuje także dwa statusy -removed: dep-wait-removed oraz failed-removed. Są one powiązane z odpowiadającymi zwykłymi statusami w następujący sposób: kiedy pakiet w stanie failed lub dep-wait nie pojawia się się w nowym pliku Packages, który zasila bazę wanna-build – kiedy wydaje się, że pakiet został usunięty – informacje o takim pakiecie nie są usuwane, ponieważ może być tak, że brak pakietu w pliku Packages jest tymczasowym błędem, lub że pakiet został tymczasowo usunięty z jakiegoś powodu (ale kwestią czasu jest jego ponowne pojawienie się w archiwum). W takim przypadku zamiast naprawdę usuwać pakiet, jest on przenoszony do stanu -removed, aby utrzymać informację dlaczego nie udała się próba budowania albo czego jeszcze brakuje. Kiedy pakiet ponownie pojawi się w pliku Packages, który zasila bazę wanna-build, zostanie on przeniesiony z failed-removed do failed lub z dep-wait-removed do dep-wait przed wykonaniem jakichkolwiek operacji.

Nie jest możliwy bezpośredni dostęp do bazy wanna-build. Baza jest zainstalowana na ftp-master-debian.org, który jest hostem z ograniczonym dostępem i tylko sieci autobuilder mają klucze SSH, które pozwalają im na dostęp do bazy wanna-build dla obsługiwanych przez nich architektur. Przed ograniczeniem dostępu do ftp-master zdarzało się, że wanna-build zakładało blokadę na bazę przy dostępie do niej (nawet podczas odczytu danych), i żeby uzyskać bezpośredni dostęp do bazy należało być we właściwej grupie (wb-<arch>).

Jak wspomniano, można obejrzeć jaki status posiada pakiet poprzez stronę statystyk buildd. Wyjątkiem są pakiety, które posiadają status installed (chyba że nie przeszkadza nam przekopanie się przez wielomegabajtowy plik "<arch>-all.txt").

Log z wynikiem budowania

Kiedy pakiet zostanie zbudowany przez sbuild (element składowy buildd, który wykonuje właściwe budowanie), wysyłana jest wiadomość, która zawiera log z wynikami przeprowadzonej operacji, do administratora autobuildera oraz na adres logs@buildd.debian.org (może się to zakończyć na http://buildd.debian.org). Wynik budowania może być jednym z następujący: successful, attempted (poprzednio znany jako failed), given-back lub skipped. Należy zauważyć, że na stronie z opisem logów buildd został dodany prefiks maybe-, miedzy innymi dlatego, że status operacji może być oznaczony jako failed, mimo że naprawdę nie zakończył się błedem, co w przeszłości wprowadzało zamieszanie (lub, innymi słowy, czasami pakiet, który na pozór został zbudowany poprawnie, w rzeczywistości był uszkodzony i wymagał zbudowania na nowo).

Znaczenie poszczególnych wyników w logu:

successful
Budowanie powiodło się. Kiedy opiekun autobuildera otrzyma taki log, wyodrębnia zawarty plik .changes, podpisuje go i odsyła z powrotem do autobuildera, co powoduje wysłanie pakietu na serwer.
attempted (poprzednio: failed)
Proces budowania zwrócił niezerową wartość, co może oznaczać błąd. Ponieważ może być wiele powodów, dlaczego proces budowania się nie powiódł, a wymienianie ich wszystkich byłoby nudne, nie podjęto takiej próby w tym miejscu. Jeżeli pakiet został oznaczony jako (maybe-)failed, należy zapoznać się z dołączonym opisem i sprawdzić jego obecny status w wanna-build.
given-back
Proces budowania nie powiódł się z powodu przejściowego problemu z autobuilderem, np. problemy z siecią, niedostępność źródeł pakietu z aktualnego pliku sources.list, brak miejsca na dysku itp.
Pakiet oznaczony jako given-back jest jednocześnie ponownie oznaczany jako needs-build, dlatego będzie automatycznie obsłużony przez autobilder, kiedy ten będzie gotowy.
skipped
Miedzy tym, jak pakiet zostanie pobrany przez autobuilder i i oznaczony jako building a próbą budowania pojawia się nowa wersja pakietu, lub osoba portująca z innego powodu ręcznie zmieni status wanna-build. W takim przypadku wysyłana jest wiadomość do autobuildera, który oznacza pakiet jako nie do budowania; sbuild widzi to i pomija budowanie (pomimo tego, wysyłany jest log z tym wynikiem, który opisuje zaistniałą sytuację).

Wersja graficzna

Aby zilustrować powyższe, utworzyliśmy schemat blokowy opisanej procedury. Ponownie zwracamy uwagę, że nie zawiera on wszystkich rzeczy opisanych w tym dokumencie.