Uwaga: Oryginał jest nowszy niż to tłumaczenie.
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:- Poprzedni stan kompilacji pakietu - pakiety, które były już budowane mają pierwszeństwo przed nowymi pakietami.
- priorytety - pakiety z priorytetem required są budowane przed pakietami z priorytetem extra.
- 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.
- kolejność alfabetyczna wg nazw pakietów.
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 https://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.