Buildery

[Witold Filipczyk]

On Tue, Jan 14, 2003 at 02:24:07PM +0100, Andrzej Krzysztofowicz wrote:
> > On Tue, Jan 14, 2003 at 11:29:38AM +0100, Andrzej Krzysztofowicz wrote:
> > > > 
> > > > Stacja bezdyskowa - chodziło o nowe komputery, dedykowane do budowania.
> > > > Nie warto kupować dysku, lepiej zainwestować w RAM.
> > > > Po zbootowaniu system będzie chodził nonstop.  Bezdyskowość nie jest tu istotna.
> > > 
> > > A co z OpenOffice ?
> > > Zmalaly wymagania do jego przebudowy, czy skadis wykombinujesz 6+ GB
> > > ramdysku ???
> > 
> > To jest wyjątek, potwierdzający regułę.
> > Trzeba być utalentowanym, żeby napisać taki program.
> 
> Znaczy builder PLD przestanie go wspierac ?

Dla tego jednego speca można poświęcić oddzielny builder.

> > > > Wszystkie devele i inne pakiety potrzebne do zbudowania powinny być brane
> > > > oczywiście z tego samego źródła.
> > > > Napisałem skrypt poldekbuild, który instaluje potrzebne pakiety i uruchamia
> > > > rpmbuilda.
> > > > Instalacja wszystkiego od nowa, zapewni to, że pakiety będą budowane zawsze
> > > > w tym samym środowisku.  Nie będzie sytuacji, że zwykły user nie da rady
> > > > przebudować pakietu, bo czegoś nie miał zainstalowanego a na builderach
> > > > było.
> > > > Dlatego ramdysk tutaj przyspieszyłby trochę. 
> > > 
> > > IMO, ramdysk ma duze szanse byc przyczyna zmniejszenia stabilnosci systemu.
> > > Juz nie raz sie zdarzaly rozne OOM podczas budowania: czy to spowodowane
> > > bledami kompilatora, czy czyms innym...
> > 
> > To nie jest winą ramdysku, a błędów w systemie, które i tak trzeba poprawić.
> 
> Poprawisz ?

Jak będzie trzeba to poprawię.

> Jak zagwarantujesz, ze proces przebudowywania speca sie nie zapetli dla
> ktorejs z architektur ?

A dlaczego miałby się zapętlić?
 
> Jak masz zasoby dyskowe na ramdysku (pamiec przydzielana dynamicznie), to
> OOM w userspace powoduje, ze zaczyna brakowac pamieci kernelowi (na ramdysk).
> Konsekwencje sa bardziej przykre (prawdopodobienstwo zwisu wieksze).

Jest quota.  Buildery będą miały dużo RAMu.

> > > > > Apropos strony głównej, to jakbyś słuchał kłoczka to też wiedziałbyś, że 
> > > > > nie ma możliwości umieszczenia tam linków.
> > > > 
> > > > Nie pamiętam co kloczek mówił.  Możliwości są, kwestia koncepcji.
> > > 
> > > Czasem nie jest to problem natury prawnej... ?
> > 
> > W Polsce ludzi prawem straszysz?
> 
> Ja strasze ? To chodzi o cywilne, nie karne.

Nie można na stronie głównej umieścić tekstu:
"Dziekujemy firmom:
<li><a href="http://f1">f1</li>
<li><a href="http://f2">f2</li>
<li><a href="http://f3">f3</li>
za udostępnienie sprzętu." ?

> > > > Będzie też kolejka SRPMS do przebudowania i RPMów do podpisania.
> > > > Na każdej kolejce będzie operował w nieskończonej pętli jakiś skrypt.
> > > > Będzie brał pierwszy (najstarszy) element z kolejki, przetwarzał
> > > > go i zapisywał wyniki w innych kolejkach (katalogach).
> > > > Jeśli kolejka jest pusta proces zasypia na określony czas.
> > > 
> > > Np. potrzebne jest przebudowanie glibc z powodu jakiegos problemu security.
> > > A w kolejce jest na poczatku OO i mamy 24h z glowy. Zreszta zupelnie
> > > bezsensownie, bo i tak za chwile trzeba to bedzie puscic jeszcze raz.
> > 
> > Na OpenOffice nie starczy pamięci ;-)
> > Zawsze można przesunąć pakiet na początek kolejki (ręczna interwencja
> > lub automatycznie).  Builderów będzie dużo, kolejki będą krótkie (kapitalizm).
> 
> Jak to zrobic jednoczesnie dla wszystkich architektur ?
> (Priorytetyzacja rozwiazywala problem.)

for i in $ARCH
do
  touch -m -t czas pakiet.spec
done

Można dodać priorytet, żeby wstawiał pakiet w odpowiednie miejsce w kolejce.
Kolejki będą krótkie!

> > > > NFS zapewnia prostotę. Przy połączeniach 1Mbit/s i szybszych nie powinno
> > > > być dużych opóźnień.
> > > Sprawdzales co sie dzieje, gdy sie pojawia duze straty na takim polaczeniu?
> > 
> > Nie.
> > Pisałem, że jestem za lokalnymi builderami.
> 
> Tzn. tam, gdzie serwer cvs ?

Tam gdzie są składowane src.rpm.

-- 
Witold Filipczyk
<witekfl w poczta.onet.pl>