pld-builder.new/jak-wysylac-zlecenia.txt

   1 W katalogu client jest skrypt nazywający się make-request.sh. Odpalamy go
   2 bez argumentów po czym zaglądamy do pliku ~/.requestrc. Najlepszy będzie
   3 przykład więc poniżej ustawienia, które trzeba zmienić:
   4
   5   requester=mmazur
   6   default_key=mmazur@kernel.pl
   7
   8 Przy czym:
   9
  10   [mmazur@home mmazur]$ gpg --list-secret-keys|grep '@'
  11   sec  1024D/A1490DA4 2003-08-14 Mariusz Mazur <mmazur@kernel.pl>
  12
  13 Mam nadzieję, że teraz jest jasne skąd się ten email bierze.
  14
  15 Na razie obowiązującymi ustawieniami są:
  16
  17   build_mode=ready
  18   f_upgrade=yes
  19
  20 Po wyrównaniu ilości pakietów na ftpie z tym co jest w Ra przechodzimy na
  21 ustawienia:
  22
  23   build_mode=test
  24   f_upgrade=no
  25
  26 Ale tym na razie nie trzeba się martwić, bo gdy przyjdzie czas, to będę
  27 o tym trąbił.
  28
  29 Teraz ćwiczenia praktyczne:
  30
  31   make-request.sh kernel.spec:LINUX_2_6
  32   make-request.sh qt.spec kadu.spec
  33   make-request.sh -b 'th-i* th-x86_64' nasm.spec
  34
  35 Pierwszy przykład to puszczenie zlecenia na pakiet kernel z brancha LINUX_2_6.
  36 Drugi to puszczenie w jednym zleceniu qt i kadu, przy czym jeśli budowanie
  37 qt się wywróci, to automatyka nawet nie będzie próbowała budować kadu.
  38 Ostatni przykład to puszczenie nasma tylko i wyłącznie na buildery x86
  39 (th-i* rozwija się na to samo, co th-i?86). Zwracam uwagę, że przy
  40 listowaniu tych buidlerów trzeba je wycytować, żeby szły jako jeden
  41 argument.
  42
  43 Każdy dostaje mailem informacje o zleceniach które wysyła (przy czym maile
  44 z tymi informacjami przychodzą nie na adres w ~/.requestrc, ale na adres
  45 zdefiniowany w konfigach buildera, więc sugerowałbym wybieranie aliasa
  46 @pld-linux.org, żeby móc to samemu zmieniać, bez konieczności interwencji
  47 kogoś z bezpośrednim dostępem do odpowiedniego buildera). Jeśli chcesz być
  48 informowany o wszystkich zleceniach, to musisz się zapisać na listę
  49 pld-logs-builder@pld-linux.org i/lub śledzić co się dzieje na
  50 http://src.th.pld-linux.org/queue.html
  51
  52 Ponieważ póki co domyślnie pakiety lądują w katalogu ready na ftpie i po
  53 zbudowaniu nowe wersje są automatycznie upgrejdowane na builderze, więc
  54 przez pewien czas pewnie przydatne będzie poniższe wywołanie:
  55
  56   make-request.sh -t nasm.spec
  57
  58 Skutek będzie taki, że pakiet się zbuduje, ale nie zostanie automatycznie
  59 zupgrejdowany na builderach, a zamiast w ready wyląduje w test (póki co
  60 cieciwa używa tego do budowania sobie w spokoju jajek 2.6).
  61
  62 Zasady puszczania do Th:
  63
  64 - Puszczamy zawsze z HEAD i bez bcondów. Odstępstwa od tej zasady są
  65   akceptowalne tylko i wyłącznie w dobrze uzasadnionych przypadkach. HEAD ma
  66   na celu łatwiejszą orientację w zawartości ftpa. Natomiast brak bcondów jest
  67   wedle zasady "src.rpm ma się budować w środowisku, jakie jest dostępne na
  68   ftpie (wyjątek to oczywiście java) i nie oczekujmy wiedzy tajemnej (jakiego
  69   bconda użyć) od wszystkich, którzy chcą dany pakiet zbudować".