-1. Developer wysy³a zlecenie, z u¿yciem client/make-request.sh, na adres
+1. Developer wysyła zlecenie, z użyciem client/make-request.sh, na adres
srpm buildera.
-2. Na koncie srpm buildera skrypt request_handler.py wo³any z procmaila obs³uguje
+2. Na koncie srpm buildera skrypt request_handler.py wołany z procmaila obsługuje
zlecenie.
- a) sprawdza podpis gpg, wyci±ga wszystkie Good sinature from <...>
- je¶li brak -- wypad
- b) szuka w swoim acl.conf czy osoba z Good signature from mo¿e robiæ
+ a) sprawdza podpis gpg, wyciąga wszystkie Good sinature from <...>
+ jeśli brak -- wypad
+ b) szuka w swoim acl.conf czy osoba z Good signature from może robić
cokolwiek, w.p.p wypad
c) xml-parsuje zlecenie (request.py)
- i. je¶li jest to <notifcation ...>, sparawdza uprawnienie
- notify:<builder>, i je¶li OK, to zmienia odpowiednio
- kolejkê spool/req_queue. Je¶li wszystki buildery
- zakoñczy³y ju¿ budowanie danej grupy usuwane s± src rpmy
- z www/srpms/<group-id>/. Generuje stronê ze statystykami
+ i. jeśli jest to <notifcation ...>, sparawdza uprawnienie
+ notify:<builder>, i jeśli OK, to zmienia odpowiednio
+ kolejkę spool/req_queue. Jeśli wszystki buildery
+ zakończyły już budowanie danej grupy usuwane są src rpmy
+ z www/srpms/<group-id>/. Generuje stronę ze statystykami
(www/queue.html).
- ii. je¶li jest to <group ...> to sprawdza czy u¿ytkownik,
- który wys³a³ zlecenie ma uprawnienia src:<nazwa-src-buildera>,
- oraz binary:<builder> dla ka¿dego buildera dla którego jest
- zlecenie. Je¶li OK, to wrzuca zlecenie do spool/queue
+ ii. jeśli jest to <group ...> to sprawdza czy użytkownik,
+ który wysłał zlecenie ma uprawnienia src:<nazwa-src-buildera>,
+ oraz binary:<builder> dla każdego buildera dla którego jest
+ zlecenie. Jeśli OK, to wrzuca zlecenie do spool/queue
3. Na koncie srpm buildera z crona chodzi skrypt srpm_builder.py.
- a) Czyta spool/queue, je¶li s± tam jakie¶ zlecenia, sortuje wg. priorytetu
- (ni¿szy numer == wa¿niejsze zlecenie), a nastêpnie sortuje wg. czasu
- przybycia zlecenia (starsze == wa¿niejsze), wyci±ga je z kolejki i zapisuje
- kolejkê.
- b) Obs³uguje tylko <group ...>.
- c) Buduje w chroot wszystkie pakiety z grupy, kolejkuj±c pliki w spool/ftp/
- oraz spool/buildlogs/. Dodatkowo srpmy s± wrzucane do www/srpms/<group-id>/
- sk±d ci±gn± je bin-buildery.
- d) je¶li nie powiod³o siê budowanie ¿adnego pakietu to wypad
+ a) Czyta spool/queue, jeśli są tam jakieś zlecenia, sortuje wg. priorytetu
+ (niższy numer == ważniejsze zlecenie), a następnie sortuje wg. czasu
+ przybycia zlecenia (starsze == ważniejsze), wyciąga je z kolejki i zapisuje
+ kolejkę.
+ b) Obsługuje tylko <group ...>.
+ c) Buduje w chroot wszystkie pakiety z grupy, kolejkując pliki w spool/ftp/
+ oraz spool/buildlogs/. Dodatkowo srpmy są wrzucane do www/srpms/<group-id>/
+ skąd ciągną je bin-buildery.
+ d) jeśli nie powiodło się budowanie żadnego pakietu to wypad
e) zleceniu nadawany jest numer
f) zlecenie jest wrzucane do spool/req_queue
g) kolejka jest podpisywana kluczem srpm buildera, gzipowana i wrzucana do
h) numer zapisywany jest w www/max_req_no
i) generowanie strony ze statystykami
-4. Na kontach srpm buildera i bin-builderów chodzi
- file_sender.py. Monitoruje on kolejki spool/{buildlogs,ftp}. S± w
+4. Na kontach srpm buildera i bin-builderów chodzi
+ file_sender.py. Monitoruje on kolejki spool/{buildlogs,ftp}. Są w
nich pliki, jak:
faa1f592-437f-446d-b1e6-ac41976c5775
faa1f592-437f-446d-b1e6-ac41976c5775.info
faa1f592-437f-446d-b1e6-ac41976c5775.desc
- Plik .desc jest kontrolny dla file_sender.py. Zawiera email zlecaj±cego
- (do alarmowania), czas skolejkowania (pliki s± wysy³ane dok³adnie
- w kolejno¶ci wrzucania do kolejki), oraz cel (url), gdzie nale¿y
- przes³aæ plik.
+ Plik .desc jest kontrolny dla file_sender.py. Zawiera email zlecającego
+ (do alarmowania), czas skolejkowania (pliki są wysyłane dokładnie
+ w kolejności wrzucania do kolejki), oraz cel (url), gdzie należy
+ przesłać plik.
- Plik .info jest tylko dla buildlogów. Je¶li taki plik istnieje to jest
- przesy³any po przes³aniu w³a¶ciwego pliku (tego bez rozszerzenia). Jest
+ Plik .info jest tylko dla buildlogów. Jeśli taki plik istnieje to jest
+ przesyłany po przesłaniu właściwego pliku (tego bez rozszerzenia). Jest
w nim zapisany status buildloga (OK|FAIL). helpers/buildlogs-mover.sh
- u¿ywa tych plików.
+ używa tych plików.
- Pliki .info i .desc koñcza siê lini±, zawieraj±c± s³owo END. Skrypty
- nic z nimi nie robi± je¶li nie ma tam tego s³owa (transmisja
- niedokoñczona).
+ Pliki .info i .desc kończa się linią, zawierającą słowo END. Skrypty
+ nic z nimi nie robią jeśli nie ma tam tego słowa (transmisja
+ niedokończona).
URLe wspierane jako cel to:
scp://user@host/sciezka/plik
/absolutna/sciezka/do/pliku
- W pliki config/rsync-passwords s± has³a do rsync, w formacie:
+ W pliki config/rsync-passwords są hasła do rsync, w formacie:
- user@host has³o
+ user@host hasło
- scp dzia³a po kluczach (z ~/.ssh)
+ scp działa po kluczach (z ~/.ssh)
5. Na koncie bin-buildera chodzi skrypt request_fetcher.py.
- a) ¶ci±ga $control_url/max_req_no i porównuje ze spool/last_req_no.
- je¶li takie same to wypad.
- b) ¶ci±ga $control_url/queue.gz, dekompresuje, sprawdza podpis (w
- config/acl.conf dla podpisuj±cego u¿ytkownika musi byæ
+ a) ściąga $control_url/max_req_no i porównuje ze spool/last_req_no.
+ jeśli takie same to wypad.
+ b) ściąga $control_url/queue.gz, dekompresuje, sprawdza podpis (w
+ config/acl.conf dla podpisującego użytkownika musi być
"sign_queue:all") [sidenote: konto bin buildera nie potrzebuje
- kluczy gpg innych ni¿ swój i srpm buildera, nie potrzebuje te¿
- acl.conf pe³nego, tylko srpm_builder z sign_queue:all]
+ kluczy gpg innych niż swój i srpm buildera, nie potrzebuje też
+ acl.conf pełnego, tylko srpm_builder z sign_queue:all]
c) wrzuca zlecenia do spool/queue
- d) zapisuje najwiêkszy numer zlecenia wrzuconego w spool/last_req_no.
+ d) zapisuje największy numer zlecenia wrzuconego w spool/last_req_no.
6. Na koncie bin-buildera chodzi skrypt rpm_builder.py.
- a) sprawdzenie loadu, je¶li za wysoki to papa
- b) lockowanie build-slot-N, gdzie N < job_slots, je¶li sie nie da
+ a) sprawdzenie loadu, jeśli za wysoki to papa
+ b) lockowanie build-slot-N, gdzie N < job_slots, jeśli sie nie da
to papa
c) lockowanie building-rpm-for-<builder> (tylko jeden build w chroot
na raz)
- d) Czyta spool/queue, je¶li s± tam jakie¶ zlecenia, sortuje wg. priorytetu
- (ni¿szy numer == wa¿niejsze zlecenie), a nastêpnie sortuje wg. czasu
- przybycia zlecenia (starsze == wa¿niejsze), wyci±ga je z kolejki i zapisuje
- kolejkê.
- e) buduje pakiety, wrzuca pliki do spool/{buildlogs,ftp}. Je¶li nie ma flagi
- test-build to pakiety wrzuca te¿ do /spools/ready/ w chroot (i generuje
+ d) Czyta spool/queue, jeśli są tam jakieś zlecenia, sortuje wg. priorytetu
+ (niższy numer == ważniejsze zlecenie), a następnie sortuje wg. czasu
+ przybycia zlecenia (starsze == ważniejsze), wyciąga je z kolejki i zapisuje
+ kolejkę.
+ e) buduje pakiety, wrzuca pliki do spool/{buildlogs,ftp}. Jeśli nie ma flagi
+ test-build to pakiety wrzuca też do /spools/ready/ w chroot (i generuje
tam idx poldka)
-Budowanie pakietów:
- 1. ¶ci±gniêcie srpm
+Budowanie pakietów:
+ 1. ściągnięcie srpm
2. instalacja srpm
- 3. próba budowania (z --nobuild), wy³apanie "foo is needed by ...",
- instalacja wszystkich takich foo. UWAGA: to nie zawsze dzia³a, np. je¶li
- rpm wywali siê z braku pliku do %include. trzeba napisaæ osobny parser.
+ 3. próba budowania (z --nobuild), wyłapanie "foo is needed by ...",
+ instalacja wszystkich takich foo. UWAGA: to nie zawsze działa, np. jeśli
+ rpm wywali się z braku pliku do %include. trzeba napisać osobny parser.
4. budowanie
- 5. je¶li nie test-build to przerzucenie pakietów do /spools/ready/
- 6. je¶li upgrade, to próba upgrejdu, wywalenie wszystkich przeszkadzaj±cych
- pakietów, chyba, ¿e trzeba by wywaliæ poldka, lub rpm-build.
+ 5. jeśli nie test-build to przerzucenie pakietów do /spools/ready/
+ 6. jeśli upgrade, to próba upgrejdu, wywalenie wszystkich przeszkadzających
+ pakietów, chyba, że trzeba by wywalić poldka, lub rpm-build.
7. upgrade
-W katalogu client jest skrypt nazywaj±cy siê make-request.sh. Odpalamy go
-bez argumentów po czym zagl±damy do pliku ~/.requestrc. Najlepszy bêdzie
-przyk³ad wiêc poni¿ej ustawienia, które trzeba zmieniæ:
+W katalogu client jest skrypt nazywający się make-request.sh. Odpalamy go
+bez argumentów po czym zaglądamy do pliku ~/.requestrc. Najlepszy będzie
+przykład więc poniżej ustawienia, które trzeba zmienić:
requester=mmazur
default_key=mmazur@kernel.pl
[mmazur@home mmazur]$ gpg --list-secret-keys|grep '@'
sec 1024D/A1490DA4 2003-08-14 Mariusz Mazur <mmazur@kernel.pl>
-Mam nadziejê, ¿e teraz jest jasne sk±d siê ten email bierze.
+Mam nadzieję, że teraz jest jasne skąd się ten email bierze.
-Na razie obowi±zuj±cymi ustawieniami s±:
+Na razie obowiązującymi ustawieniami są:
build_mode=ready
f_upgrade=yes
-Po wyrównaniu ilo¶ci pakietów na ftpie z tym co jest w Ra przechodzimy na
+Po wyrównaniu ilości pakietów na ftpie z tym co jest w Ra przechodzimy na
ustawienia:
build_mode=test
f_upgrade=no
-Ale tym na razie nie trzeba siê martwiæ, bo gdy przyjdzie czas, to bêdê
-o tym tr±bi³.
+Ale tym na razie nie trzeba się martwić, bo gdy przyjdzie czas, to będę
+o tym trąbił.
-Teraz æwiczenia praktyczne:
+Teraz ćwiczenia praktyczne:
make-request.sh kernel.spec:LINUX_2_6
make-request.sh qt.spec kadu.spec
make-request.sh -b 'th-i* th-x86_64' nasm.spec
-Pierwszy przyk³ad to puszczenie zlecenia na pakiet kernel z brancha LINUX_2_6.
-Drugi to puszczenie w jednym zleceniu qt i kadu, przy czym je¶li budowanie
-qt siê wywróci, to automatyka nawet nie bêdzie próbowa³a budowaæ kadu.
-Ostatni przyk³ad to puszczenie nasma tylko i wy³±cznie na buildery x86
-(th-i* rozwija siê na to samo, co th-i?86). Zwracam uwagê, ¿e przy
-listowaniu tych buidlerów trzeba je wycytowaæ, ¿eby sz³y jako jeden
+Pierwszy przykład to puszczenie zlecenia na pakiet kernel z brancha LINUX_2_6.
+Drugi to puszczenie w jednym zleceniu qt i kadu, przy czym jeśli budowanie
+qt się wywróci, to automatyka nawet nie będzie próbowała budować kadu.
+Ostatni przykład to puszczenie nasma tylko i wyłącznie na buildery x86
+(th-i* rozwija się na to samo, co th-i?86). Zwracam uwagę, że przy
+listowaniu tych buidlerów trzeba je wycytować, żeby szły jako jeden
argument.
-Ka¿dy dostaje mailem informacje o zleceniach które wysy³a (przy czym maile
-z tymi informacjami przychodz± nie na adres w ~/.requestrc, ale na adres
-zdefiniowany w konfigach buildera, wiêc sugerowa³bym wybieranie aliasa
-@pld-linux.org, ¿eby móc to samemu zmieniaæ, bez konieczno¶ci interwencji
-kogo¶ z bezpo¶rednim dostêpem do odpowiedniego buildera). Je¶li chcesz byæ
-informowany o wszystkich zleceniach, to musisz siê zapisaæ na listê
-pld-logs-builder@pld-linux.org i/lub ¶ledziæ co siê dzieje na
+Każdy dostaje mailem informacje o zleceniach które wysyła (przy czym maile
+z tymi informacjami przychodzą nie na adres w ~/.requestrc, ale na adres
+zdefiniowany w konfigach buildera, więc sugerowałbym wybieranie aliasa
+@pld-linux.org, żeby móc to samemu zmieniać, bez konieczności interwencji
+kogoś z bezpośrednim dostępem do odpowiedniego buildera). Jeśli chcesz być
+informowany o wszystkich zleceniach, to musisz się zapisać na listę
+pld-logs-builder@pld-linux.org i/lub śledzić co się dzieje na
http://src.th.pld-linux.org/queue.html
-Poniewa¿ póki co domy¶lnie pakiety l±duj± w katalogu ready na ftpie i po
-zbudowaniu nowe wersje s± automatycznie upgrejdowane na builderze, wiêc
-przez pewien czas pewnie przydatne bêdzie poni¿sze wywo³anie:
+Ponieważ póki co domyślnie pakiety lądują w katalogu ready na ftpie i po
+zbudowaniu nowe wersje są automatycznie upgrejdowane na builderze, więc
+przez pewien czas pewnie przydatne będzie poniższe wywołanie:
make-request.sh -t nasm.spec
-Skutek bêdzie taki, ¿e pakiet siê zbuduje, ale nie zostanie automatycznie
-zupgrejdowany na builderach, a zamiast w ready wyl±duje w test (póki co
-cieciwa u¿ywa tego do budowania sobie w spokoju jajek 2.6).
+Skutek będzie taki, że pakiet się zbuduje, ale nie zostanie automatycznie
+zupgrejdowany na builderach, a zamiast w ready wyląduje w test (póki co
+cieciwa używa tego do budowania sobie w spokoju jajek 2.6).
Zasady puszczania do Th:
-- Puszczamy zawsze z HEAD i bez bcondów. Odstêpstwa od tej zasady s±
- akceptowalne tylko i wy³±cznie w dobrze uzasadnionych przypadkach. HEAD ma
- na celu ³atwiejsz± orientacjê w zawarto¶ci ftpa. Natomiast brak bcondów jest
- wedle zasady "src.rpm ma siê budowaæ w ¶rodowisku, jakie jest dostêpne na
- ftpie (wyj±tek to oczywi¶cie java) i nie oczekujmy wiedzy tajemnej (jakiego
- bconda u¿yæ) od wszystkich, którzy chc± dany pakiet zbudowaæ".
+- Puszczamy zawsze z HEAD i bez bcondów. Odstępstwa od tej zasady są
+ akceptowalne tylko i wyłącznie w dobrze uzasadnionych przypadkach. HEAD ma
+ na celu łatwiejszą orientację w zawartości ftpa. Natomiast brak bcondów jest
+ wedle zasady "src.rpm ma się budować w środowisku, jakie jest dostępne na
+ ftpie (wyjątek to oczywiście java) i nie oczekujmy wiedzy tajemnej (jakiego
+ bconda użyć) od wszystkich, którzy chcą dany pakiet zbudować".