Co robimy ze sparciem i alphą

The Undefined undefine w aramin.net
Pią, 10 Gru 2004, 23:51:11 CET


On Fri, Dec 10, 2004 at 11:29:23PM +0100, Mariusz Mazur wrote:
> > > <@mmazur> ankry, glibca większość builderów wyciąga do godziny, ppc do
> > >                 dwóch (ale on mieli dwie rzeczy równocześnie, jak w ac
> > > spadnie aktywność, będzie ok), sparc 3,5 (ale gaus ma szybszego, także to
> > > się powinno poprawić), natomiast alpha robi przez 6 godzin
> >
> > codziennie sie buduje glibca? ;)
> 
> No nie, ale jeśli on tak reaguje na glibca, to te wszystkie c++owe bydlaki go 
> zamordują na co najmniej dzień.
no coz ;)

tak abstrahujac od alphy...
z czego wynika ze wszystko sie robi coraz to wolniejsze?
strach powoli instalowac pld na jakims p100... a jeszcze niedawno toto
smigalo...

> > o co chodzi z tym "utrzymywaniem"?
> 
> Żeby alpha była niezależna od reszty builderów i ftpa. Nie mam pomysłów jak to 
> sensownie można by było zrobić (dlatego kompromisem by było wywalenie 
> nieużywanych paczek).
to moze lepiej "na bierzaco" definiowac te nieuzywane/niebudujace sie?
Poprzez EA po prostu? ;)

> > Ale dlaczego nie chcesz budowac qt?
> > Co szkodzi ze sie przemieli?
> > Czy naprawde buildery musza co chwilke cos "super duzego" mielic?
> > Moze po prostu nadac alphie stan unsupported?
> > Czyli w sytuacji gdy cos sie nie buduje/nie dziala - nie przejmowac sie
> > i isc dalej?(ot, z ostatnich dni: ghc i Yap).
> 
> Pomijając podstawowy system na wszystkich arch (czyli jakieś glibce, gcc, czy 
> coś w ten deseń), ja nie planuję łatać niczego, czego sam nie używam. Moja 
> nowa automatyka ma taki fetysz, że nie pozwoli mi przenieść paczki, której 
> poprzednia wersja jest już w głównym drzewku, a która straciła by wsparcie 
> dla jakiejś architektury w wyniku przeniesienia (nie potrafię napisać tego 
> zdania tak, żeby było krótkie i zrozumiałe, więc się wysilcie). Problem jest 
> taki, że w trakcie rozwoju będą się pojawiały nowe wersje różnych programów, 
> które mają sporą szansę na popsucie się na jakiejśtam architekturze. I kto to 
> ma poprawiać? Ja? Osoba wysyłająca zlecenie, którą ni grzeje, ni ziębi 
> jakaśtam alpha?
> Ale pal licho programy. Zabawa się zaczyna z bibliotekami. Jeśli ktoś wyśle 
> nowego libpnga na buildery z opcją upgrade, ale ten się nie zbuduje na jednej 
> arch i na tej jednej arch będę miał pakiety budowane o inną wersję 
> biblioteki, to później będzie to trzeba odkręcać (na dobrą sprawę nie powinno 
> się zdarzyć ze względu na soname i odmowę automatycznego upgrejdu przez 
> poldka).
coz... rozwiazanie proste - uzywac test i upgradowac tylko gdy sie
wszedzie zbuduje...

> Generalnie rzecz biorąc zobaczę jak to wszystko pójdzie w praktyce i czy 
> możliwość wysyłania z upgrade powinna być defaultowa. Tak, czy siak chcę po 
> prostu zawczasu znać potencjalne wyjścia (czyli właśnie np. obcięcie 
> nieużywanych paczek na alphie, czy gdzie tam).
moim zdaniem lepszy bylby mozliwie pelny port(czyli to co sie po prostu
zbuduje...). Inaczej dojdzie do balaganu, bo np nagle zacznie byc cos
tam potrzebne, co bedzie wymagalo przebudowy polowy systemu ;)
(tak jak bylo z np tetexem na ra w sparc...)

> > coz.. odnosnie sparcow - mam:
> > 10 * ultrasparc 10 - 8 jako workstacje,
> 
> A co ty na tych workstacjach używasz?
ja? ;) studenci...
jest zainstalowane pi razy drzwi to samo co w innych salach, czyli
praktycznie pelne kde, wmaker, xfce.... Na zajeciach z "dodatkow"
niedawno byl potrzeby ethereal... Z czego korzystaja najczesciej - nie
mam pojecia.. Ale co jakis czas jak przechodze kolo sal z sunami to
czasami jakis maniak tam siedzi. Rok temu z tego co pamietam ostro
korzystali na nich z javy/djade.

ja na "swojej" korzystam z wmakera, psi, firefoksa, vnc, mpg123/mplayera
do muzyczki(jedyna stacja z glosnikami w pokoju!) i.. takich tam roznych
malych drobiazgow.

-- 
Andrzej 'The Undefined' Dopierała
UNIX && Linux administrator, Adam Mickiewicz University WMiI
PLD Linux Developer             HomePage: http://aramin.net/
JID: undefine w piastlan.net    e-mail: undefine w pld-linux.org




Więcej informacji o liście dyskusyjnej pld-devel-pl