X-Git-Url: https://git.tld-linux.org/?p=TLD.git;a=blobdiff_plain;f=pld-builder.new%2Fjak-wysylac-zlecenia.txt;fp=pld-builder.new%2Fjak-wysylac-zlecenia.txt;h=e771eb4c56a73c6c6ff9115198b9c6ec93f08f8e;hp=0000000000000000000000000000000000000000;hb=90809c8fec988489786ce00247d9a4150070748b;hpb=ab3934fab858112cd552359b18cb980ea07c310b diff --git a/pld-builder.new/jak-wysylac-zlecenia.txt b/pld-builder.new/jak-wysylac-zlecenia.txt new file mode 100644 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 + +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ć".