pld-builder.new: jak-to-dziala.txt, jak-wysylac-zlecenia.txt - utf8

Tue Nov 16 10:09:52 CET 2010

Author: glen                         Date: Tue Nov 16 09:09:52 2010 GMT
Module: pld-builder.new               Tag: HEAD
---- Log message:
- utf8

---- Files affected:
pld-builder.new:
   jak-to-dziala.txt (1.5 -> 1.6) , jak-wysylac-zlecenia.txt (1.6 -> 1.7) 

---- Diffs:

================================================================
Index: pld-builder.new/jak-to-dziala.txt
diff -u pld-builder.new/jak-to-dziala.txt:1.5 pld-builder.new/jak-to-dziala.txt:1.6

--- pld-builder.new/jak-to-dziala.txt:1.5	Fri Jun 27 19:21:35 2008
+++ pld-builder.new/jak-to-dziala.txt	Tue Nov 16 10:09:47 2010
@@ -1,34 +1,34 @@
-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 
@@ -36,27 +36,27 @@
    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:
    
@@ -64,45 +64,45 @@
      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 at host has³o
+     user at 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

================================================================
Index: pld-builder.new/jak-wysylac-zlecenia.txt
diff -u pld-builder.new/jak-wysylac-zlecenia.txt:1.6 pld-builder.new/jak-wysylac-zlecenia.txt:1.7
--- pld-builder.new/jak-wysylac-zlecenia.txt:1.6	Tue Nov 16 09:07:50 2010
+++ pld-builder.new/jak-wysylac-zlecenia.txt	Tue Nov 16 10:09:47 2010
@@ -1,6 +1,6 @@
-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 at kernel.pl
@@ -10,60 +10,60 @@
   [mmazur at home mmazur]$ gpg --list-secret-keys|grep '@'
   sec  1024D/A1490DA4 2003-08-14 Mariusz Mazur <mmazur at 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
- at 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 at 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
+ at 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 at 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Ä‡".
================================================================

---- CVS-web:
    http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/pld-builder.new/jak-to-dziala.txt?r1=1.5&r2=1.6&f=u
    http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/pld-builder.new/jak-wysylac-zlecenia.txt?r1=1.6&r2=1.7&f=u

