W katalogu client jest skrypt nazywajcy si make-request.sh. Odpalamy go
bez argumentw po czym zagldamy do pliku ~/.requestrc. Najlepszy bdzie
przykad wic poniej ustawienia, ktre 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 skd si ten email bierze.

Na razie obowizujcymi ustawieniami s:

  build_mode=ready
  f_upgrade=yes

Po wyrwnaniu iloci pakietw 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 bd
o tym trbi.

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 przykad to puszczenie zlecenia na pakiet kernel z brancha LINUX_2_6.
Drugi to puszczenie w jednym zleceniu qt i kadu, przy czym jeli budowanie
qt si wywrci, to automatyka nawet nie bdzie prbowaa budowa kadu.
Ostatni przykad to puszczenie nasma tylko i wycznie na buildery x86
(ac-i* rozwija si na to samo, co ac-i?86). Zwracam uwag, e przy
listowaniu tych buidlerw trzeba je wycytowa, eby szy jako jeden
argument.

Kady dostaje mailem informacje o zleceniach ktre wysya (przy czym maile
z tymi informacjami przychodz nie na adres w ~/.requestrc, ale na adres
zdefiniowany w konfigach buildera, wic sugerowabym wybieranie aliasa
@pld-linux.org, eby mc to samemu zmienia, bez koniecznoci interwencji
kogo z bezporednim dostpem do odpowiedniego buildera). Jeli 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://ep09.pld-linux.org/~buildsrc/queue.html

Poniewa pki co domylnie pakiety lduj w katalogu ready na ftpie i po
zbudowaniu nowe wersje s automatycznie upgrejdowane na builderze, wic
przez pewien czas pewnie przydatne bdzie ponisze wywoanie:

  make-request.sh -t nasm.spec

Skutek bdzie taki, e pakiet si zbuduje, ale nie zostanie automatycznie
zupgrejdowany na builderach, a zamiast w ready wylduje w test (pki co
cieciwa uywa tego do budowania sobie w spokoju jajek 2.6).

Zasady puszczania do Ac:

- Puszczamy zawsze z HEAD i bez bcondw. Odstpstwa od tej zasady s
  akceptowalne tylko i wycznie w dobrze uzasadnionych przypadkach. HEAD ma
  na celu atwiejsz orientacj w zawartoci ftpa. Natomiast brak bcondw jest
  wedle zasady "src.rpm ma si budowa w rodowisku, jakie jest dostpne na
  ftpie (wyjtek to oczywicie java) i nie oczekujmy wiedzy tajemnej (jakiego
  bconda uy) od wszystkich, ktrzy chc dany pakiet zbudowa".

- Ja tego nie powiedziaem: w chwili obecnej nie jest ustawiona blokada na
  puszczanie pakietw o tej samej rel mimo zmiany np. speca. Suy to
  atwiejszemu poprawianiu pakietw na okoliczno nie budowania si na
  niektrych arch (tzn. pki pakiet ley w ready to spokojnie mona mu doda
  jeszcze par poprawek i puci na brakujce arch nie podbijajc rel). W
  pierwszej kolejnoci do gwnego drzewka przenosz pakiety budujce si na
  wszystkich arch, take ma si zawsze ten dzie-dwa na powiedzenie mi, cobym
  si wstrzyma (lub poprawienie). Ten 'workaround' zostanie utrzymany do
  osignicia okoo 70-80% stanu pakietw z Ra, czyli jeszcze troch. W kadym
  razie nie naley si tym pki co martwi, bo jak przyjdzie pora, to bd
  trbi co si zmienia i jak.


