- from https://github.com/pld-linux/pld-builder.new

[TLD.git] / pld-builder.new / jak-wysylac-zlecenia.txt

diff --git a/pld-builder.new/jak-wysylac-zlecenia.txt b/pld-builder.new/jak-wysylac-zlecenia.txt
new file mode 100644 (file)
index 0000000..e771eb4
--- /dev/null
+++ b/pld-builder.new/jak-wysylac-zlecenia.txt
@@ -0,0 +1,69 @@
+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
+
+Przy czym:
+
+  [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.
+
+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
+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ł.
+
+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
+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
+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:
+
+  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).
+
+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ć".