]> TLD Linux GIT Repositories - TLD.git/blobdiff - pld-builder.new/jak-wysylac-zlecenia.txt
- moved to separate repo
[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
deleted file mode 100644 (file)
index e771eb4..0000000
+++ /dev/null
@@ -1,69 +0,0 @@
-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ć".