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 'ac-i* ac-athlon' 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 (ac-i* rozwija się na to samo, co ac-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 Ac: - 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ć". - Ja tego nie powiedziałem: w chwili obecnej nie jest ustawiona blokada na puszczanie pakietów o tej samej rel mimo zmiany np. speca. Służy to łatwiejszemu poprawianiu pakietów na okoliczność nie budowania się na niektórych arch (tzn. póki pakiet leży w ready to spokojnie można mu dodać jeszcze parę poprawek i puścić na brakujące arch nie podbijając rel). W pierwszej kolejności do głównego drzewka przenoszę pakiety budujące się na wszystkich arch, także ma się zawsze ten dzień-dwa na powiedzenie mi, cobym się wstrzymał (lub poprawienie). Ten 'workaround' zostanie utrzymany do osiągnięcia około 70-80% stanu pakietów z Ra, czyli jeszcze trochę. W każdym razie nie należy się tym póki co martwić, bo jak przyjdzie pora, to będę trąbił co się zmienia i jak.