mmazur.7thguard.net

Zamiast iść spać łażę po stronach polskich klanów quake'a 2, doda, csa i czego tam ludzie nie wymyślili. Prawdę mówiąc jestem w ciężkim szoku. Ostatnim razem jak ja się tym wszystkim w miarę aktywnie interesowałem, to były sobie klaniki, które sobie pykały, nawet ktoś gdzieś jakieś międzynarodowe ligi organizował. Teraz polskie klany płacą za posiadanie serwera do treningów, uczestniczą w niezliczonej ilości zagranicznych i polskich lig i w ogóle połowy gier w które się teraz gra to ja na oczy nie widziałem.
Ja chyba jestem na to za stary.

Od paru dni budowanie idzie całkiem sprawnie. Aflinta dostał prawa i buduje gnomy (z pewnymi oporami, bo się zatkał na gpgme :), a ja buduję jakąś drobnicę, by sukcesywnie upgrejdował własny system.

Jutro sprawdzanie wyników nauczania z polskiego. To będzie masakra.

Dałem aflincie i adasiemu dostęp do builderów. Aflinta zajęty budową domu, także nie ma czasu. Adasi puścił zlecenie, nie zadziałało. Poprawiłem, adasi puścił zlecenie i nie zadziałało. A powinno. Okazało się, że po raz n-ty zapchało się /var/log na głównym builderze skutkiem czego nic nie działa. Kurwa.

Całe dzisiaj spędziłem na pisaniu tego cholernego streszczenia prezentacji na Jesień Linuksową. Skończywszy, całkiem dumny z tego co spłodziłem, wysłałem tekst honejowi do sprawdzenia. Ten szybko mi udowodnił, że nie umiem pisać po polsku. Fuck.
A na aflintę oczywiście czasu nie miałem. Jutro.

Miał dostać prawa puszczania zleceń na Ac, żeby pobudował gnoma itp., ale akurat siadł builder x86. Pech to pech.

Micrę to stworzył jakiś psychol. Takie małe autko, a przyspieszenie ma jak jakiś ryćkany mercedes. Ruszanie ze wzniesienia zostało poprzedzone efektownym półsekundowym poślizgiem kół przy starcie, a z górki to o mało nie wyskoczyłem. Przy wyjeździe z ośrodka sytuacja się powtórzyła (wyjazd jest perfidny, bo trzeba zrobić dokładnie ten sam manewr, tyle, że skręcając jednocześnie), ale ze względu na mniejszy kąt nachylenia udało mi się uniknąć boksowania kół. Fakt faktem, że z egzaminatorem nas bardzo ładnie wbiło w lewe części foteli (skręcałem w prawo), a ja musiałem się nieźle nakręcić, żeby przez te pół sekundy startowania nie władować się na drugi pas ruchu. Dalsza jazda była równie tragiczna, przy czym po 10 minutach już się w miarę nauczyłem operować tym cholernym gazem. Wyglądało to tak: sprzęgło, bieg, gaz wbijamy (czynność automatyczna, wyuczona), gaz puszczamy jakieś 90% tego cośmy wbili (czynność profilaktyczna, wyuczona przez ostatnie 10 minut szalonego gazowania), sprzęgło puszczamy. Niech mnie ręka boska broni, żebym ja jeszcze raz czymś takim jeździł.

Buildery Acze znowu ruszyły. Nowe ppc ma niezłego kopa i teraz szkoda tego sparca, że się tak przeraźliwie wlecze za wszystkimi.

A ja jutro mam znowu zdawanie na prawo jazdy. Pewnie nie zdam. Ble.

Spidi wczoraj zupgrejdował eu11 do acze, ale już chroota mi nie ustawił, także i tak nic z tego. Blah. Czekam do poniedziałku.

Spidi wczoraj nie naprawił komputerka z ppc, więc Ac nadal stoi. Powiedziałem, że mają z rmfem tydzień po czym port ppc olewam. O.

Z innej beczki - w Ra właśnie wylądowała poprawka na najnowszą dziurę w ssh. Upgrejd bardzo wskazany. A mi na swoim serwerze nie chce się upgrejdować (nie mam raowego ssh), więc po prostu wyblokowałem ssh. Ech zalety adminowania serwerem szkolnym :)

Gadanie z czechem rządzi. Po prostu niesamowite, że w dwóch językach da się dogadać dzięki podobnemu brzmieniu niektórych słów :)

No więc ostateczna diagnoza. Jeśli na prawdziwym systemie jest Ra (pld 1.0 dla niewiedzących), a wewnątrz chroota jest Ac (pld 2.0 dla niewiedzących) i architekturą jest ppc, a do chroota wchodzimy odpalając z pythonowego skryptu os.system("sudo chroot chroot-ac"), to środowisko wewnątrz chroota będzie skażone i aplikacje wątkowe będą się wywalały. Co ciekawe skażenie występuje przy jakiejkolwiek aplikacji odpalanej przez pythona i jest dziedziczone w dół. Zrobiłem takiego testa polegającego na odpaleniu os.system("screen") z pythona. Spod tego screena jakiekolwiek wejście do chroota powodowało znany nam błąd i nie udało mi się tego obejść. Python coś psuł, ale owo psucie objawiało się tylko przy wejściu do środowiska różniącego się glibcem. Przekompilowałem pythona na wersję 2.3 i nie pomogło. Wniosek, że albo glibc 2.2.5 jest skopany, albo kompilacja pod gcc2 daje takie rezultaty (albo oba na raz), przy czym imho to raczej ten ryćkany gcc (który na wszystkim != x86 działa po prostu tragicznie).
Koniec końców jeśli na zewnątrz chroota nie będzie Ra, tylko Ac, to problem nie występuje. Przy obecnej lokalizacji buildera ppc upgrejd jest niemożliwy, ale na szczęście spidi ma mocny desktop, który będzie można zupgrejdować. Obiecał, że zrobi to w poniedziałek. No i git.

Mam problem. PLD też ma problem. Właściwie rzecz biorąc to problem jest jeden i ten sam. Otóż automatyka służąca do budowania pakietów na wszystkich builderach na raz jest napisana w pythonie i... przez to nie działa. Jeśli wewnątrz chroota skompiluję sobie programik używający -pthreads (jest to standardowy programik używany przez ./configure, do sprawdzania, czy w systemie jest wsparcie dla wątków; zwany dalej conftest) i odpalę go, to ślicznie zadziała. Jeśli z zewnątrz chroota zrobię 'sudo chroot ~/chroot /tmp/conftest' to też ślicznie zadziała. Jeśli natomiast z zewnątrz chroota odpalę skrypt pythonowy który będzie robił os.system("sudo chroot ~/chroot /tmp/conftest"), to ów conftest się ślicznie wypieprzy wpadając w pętlę przy wywołaniu mmapa. Dla ciekawskich podaję jak wywołanie tego mmapa wygląda:
mmap(NULL, 2147483647, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
Chyba dla każdego jest jasne, czemu to nie ma prawa działać. Pomijając odpalanie przez pythona w każdym innym przypadku drugi argument mmapa jest taki, jaki powinien i całość działa jak trzeba. Jestem zły. Naprawienie tego pewnie będzie graniczyło z cudem, gdyż na zewnątrz chroota jest PLD1.0, a wewnątrz coś, co ma się stać PLD2.0 (hgw kiedy, gdyż przez ten błąd prace są wstrzymane), więc żaden normalny deweloper pythona/glibca/whatever nie zechce ruszyć czterych liter i sprawdzić co jest nie tak. Jedyna nadzieja w znalezieniu workaroundu. Chociaż. Gdyby ten błąd był powtarzalny gdzie indziej... czy któryś z czytelników byłby tak miły i powtórzył taką operację na jakiejś innej dystrybucji? Albo wymyślił jakiś workaround pozwalający zniwelować zgubny wpływ pythona na środowisko (od razu mówię, że os.system("./ble.sh") nie zadziała). Help.
Brb. Właśnie do mnie dotarło, że nikt poza mną pewnie nie ma ppc. Będę musiał coś wymyślić :/

Brata (lat trzy) mam chorego i jutro siedzę z nim w domu zamiast iść do szkoły. To będzie ciekawe.

Krytyka konstruktywna inaczej jest niesamowicie irytująca. Już ostatkiem sił się powstrzymuję od flejmów.
Na tego glibca to ja już nie mam siły. Chyba skończy się tym, że jutro zrobię sobię test case i będę debuggował aż skubańca upoluję. WRRRRRRR.

Jadę na pogrzeb prababci. Jak zwykle przy tego typu okazjach nie czuję absolutnie nic.

A glibc na ppc dostał pierdolca i przy puszczaniu zleceń na budowanie jakiegoś pakietu pthreadsy odmawiają posłuszeństwa (sig11). Przy ręcznym zalogowaniu i puszczeniu rpmbuild działa jak trzeba. Wziąłem od spidiego jego własny kompilat glibcowy i o dziwo zadziałało. Wniosek - robimy rebuild glibców... no i dupa. Oczywiście coś się stało i na żadnej arch glibcy się budować nie chcą. Podejżewałem ostatnie zmiany przy okazji nptl, revertnąłem je, ale i tak kupa. Pewnie któryś patch coś pieprzy, ale mi się nie chce sprawdzać. Zieeeeeew. Chyba to poczeka do jutra.

Przez ostatnie cztery dni sieć działała w kratkę (przy czym więcej nie działała jak działała), także się trochę nadenerwowałem na niemożność zrobienia czegokolwiek konstruktywnego przez weekend. No ale jakoś to było. Wczoraj admin posklejał całość gumą do żucia, a dzisiaj wymienił serwer i wszystko działa jak trzeba :)

Hehe. Jak się robi za głównego w jakimś projekcie, to wszyscy tylko krytykują. Już się przyzwyczaiłem i coraz mniej czasu spędzam na zwalczaniu chęci odflejmowania się takiemu delikwentowi (a pokusa jest, oj jest). Ależ my mamy społeczeństwo. Wszyscy są tacy wredni i tylko mnie z tej wredoty krytykują. Bo z jakiegoż innego powodu mieli by to robić?

Już kilkukrotnie zapowiadałem, że Ac przechodzi w 'wolną' (as in liberty, not beer) fazę rozwoju gdzie więcej osób będzie mogło puszczać pakiety do zbudowania i wystawienia na ftpie i za każdym takim terminem okazywało się, że i tak zostało mi w cholerę do zrobienia. Zaczynam rozumieć na czym polega terminarz 'będzie jak będzie' i czym jest powodowany :).
A qt się mieli i mieli i mieli. Na ppc zajęło mu to 23 godziny. Na skwarku nadal się mieli (to już 29 godzin) i niby jest już gdzieś blisko końcówki, ale strasznie powoli się to końcówkowkuje. Szybszy builder ppc już jest, tylko admin leń i nie chce przenieść czego trzeba. Natomiast szybszego skwarka niestety nie ma :/. Jeśli ktoś ma gdzieś pod ręką szybkiego i pewnego skwarka z linuksem na pokładzie i mógłby go udostępnić na potrzeby pld, to prosimy się zgłaszać do biura obsługi klienta. Blah. Robienie dystrybucji jednocześnie na cztery architektury (z tym, że x86 z osobnymi kompilatami na 386, 586, 686 i athlona), jest jednak upierdliwe.