Romhacker's Guide to the Galaxy

Już jakiś czas temu doszedłem do wniosku, że GCC 4.3.3 powinno być dostatecznie bezpieczne do codziennego użytku i kusiła mnie migracja na tę wersję. Większość bugów na bugzilli Gentoo jest zamknięta, a niedobitki to pakiety, których w życiu nie używałem. Postanowiłem więc zakasać rękawy i przystąpić do aktualizacji i przebudowy systemu

Spostrzeżenia i uwagi:
* Odmaskowałem glibc 2.8*, bo nie chciałem się pakować od razu w 2.9
* Najpierw odmaskowałem nowe wersje boost, boost-build i aspella. Wersje ze stable rzekomo nie lubią się z GCC 4.3
* Dodatkowo zaktualizowałem VirtualBoksa do wersji 2.1.4 z overlaya jokey. Wersje 2.1.0+ dodają wsparcie dla GCC 4.3
* Po przełączeniu kompilatora zmieniłem -march na -march=native, żeby przerzucić dobór optymalizacji na kompilator
* emerge -e @system przebiegło bezboleśnie
* Pierwszy problematycznym pakietem przy emerge -e @world okazała się enca. Wystarczyło odmaskować enca i jej zależność - recode
* Dużo później wyłożył się dev86, zależność m.in. VirtualBoksa i kernelowego uvesafb. Wystarczyło odmaskować.
* Dzięki -march=native wyłożyła się oczywiście (z racji boostrapowania) rekompilacja starego GCC, ale to już rozwiązałem za pomocą portage-bashrc-ng i package.*flags.
* Wyłożyła się też Stepmania z roslina. Dodałem do repo stosowną łatkę, głównie dodającą brakujące nagłówki.
* Na koniec wyłożył się stary Amarok. I to byłby najdziwniejszy problem. Po zmniejszeniu MAKEOPTS na -j1 przeszło bez problemu (choć pod GCC 4.1.2 i -j5 było wszystko cacy). Mało tego, później na -j5 i GCC 4.3 poszło jak gdyby nigdy nic. Nie będę nawet starał się tego zrozumieć. Tak będzie lepiej
* Na koniec na wszelki wypadek przekompilowałem kernel i zrobiłem module-rebuild.
* Stary kompilator zostawiłem na potrzeby distcc (o pewnej sztuczce z tym związanej napiszę w późniejszym poście)

Uwagi końcowe:
Wszystko przebiegło pomyślnie i, o ile pamięć służy, było dużo mniej wpadek niż jakiś czas temu przy przejściu na 4.1. Tym razem skończyło się na odmaskowaniu 5 pakietów (+ VirtualBoksa z overlaya) i jednej własnej łatce. Wynik uważam za korzystny. Podczas rekompilacji system był w pełni sprawny. Normalnie z niego korzystałem. Jedyną usterką, jaką zaobserwowałem była ciut ogłupiała konsola Pythona zanim ten został przekompilowany Nowe GCC wypluwa dużo więcej ostrzeżeń, głównie za sprawą domyślnie włączonych -D_FORTIFY_SOURCE=2 i -Wformat-security. Na razie nie zauważyłem cudownych wzrostów wydajności ani zmniejszenia rozmiaru binarek. Z drugiej strony, nie robiłem żadnych pomiarów przed i po. Niemniej jednak efekt placebo jest bardzo satysfakcjonujący Zresztą GCC 4.3 i tak trafi do stable w perspektywie najbliższych tygodni. Przyśpieszyłem tylko nieuniknione O ile jesteście gotowi odmaskować parę pakietów i przekompilować system, mogę wam z powodzeniem polecić tę wersję GCC.

UPDATE:
Nowy VirtualBox właśnie wylądował w portage. Nie jest już potrzebny overlay.
Z mniej optymistycznych wieści:
* cvs wykłada się z "*** %n in writable segment detected ***" przy cvs diff. Na szczęście wystarczyło odmaskować najnowszą wersję.
* zsnes wykłada się z powodu -D_FORTIFY_SOURCE. Jest już na to łatka. Zaraz będzie w roslinie

UPDATE 2:
Po odpaleniu debuggera w emulatorze snes9x odkryłem problem na linii FORTIFY_SOURCE i glibc 2.8. Ma on wpływ na programy używające sprintf (i inne jego warianty) do doklejania tekstu do końca bufora w taki sposób:

sprintf(buf, "%sfail", buf);

Teoria jest taka, że taki kod jest nieprawidłowy i nie powinno się tak pisać. W praktyce mamy wiele programów, które tego nadużywają. Kilka wystąpień znalazłem nawet w źródłach kernela. Błąd występuje tylko przy włączonym FORTIFY_SOURCE i optymalizacji -O2 (i pewnie wyższych. Na szczęście jest na to łatwe obejście. Wystarczy nałożyć tę łatkę na glibc. Przywraca on stare zachowanie. Po nałożeniu łatki nie trzeba przekompilowywać systemu, ale jeśli bardzo chcecie, to proszę bardzo Gdyby ktoś chciał poczytać więcej o tym bugu, zapraszam tutaj.

Co prawda w tak zwanym międzyczasie wyszedł jeden snapshot, a źródła drugiej bety były dostępne parę dni wcześniej, ale postanowiłem wstrzymać się z tym postem aż do oficjalnej premiery. Post ten będzie raczej moją osobistą listą zaobserwowanych zmian na plus. Ostatnio dość często bywam na bugzilli KDE i zgłaszam niedoróbki, które rzucają mi się w oczy. I muszę przyznać, że znakomita większość zgłoszonych przeze mnie usterek została usunięta w KDE 4.2 beta2 lub w trunku, a to, co pozostało to drobiazgi, na które mogę przymknąć oko.

Moje spostrzeżenia:
+ Usunięto crash Plasmy przy ponownym wejściu do konfiguracji plazmoida.
+ W nowej becie ani raz nie pojawiło mi się tajemnicze puste miejsce na panelu.
+ Nowe powiadomienia w systrayu można wyłączyć, choć na razie wymaga to edycji plasma-appletsrc.
+ Problem z dziwnym zachowaniem efektów z pełnoekranowymi oknami można obejść wyłączając "unredirect fullscreen windows".
+ Pasek zadań znowu wyładniał
- Nadal nie działa mi wyświetlanie nazwy pulpitu przy przełączaniu (w trybie composite, w normalnym działają).

Jest też parę innych niedoróbek, które naprawiono za późno na beta2, ale są naprawione w svn. Oto mój zestaw łatek, w większość wygenerowanych z svn:
* ark-libarchive-emit.patch - poprawka na pustą listę plików przy archiwach tar.gz/tar.gz2 w Arku, moja własna łatka
* dolphin-tabs.patch - sprawia, że nowe karty w Dolphinie respektują tryb podzielonego widoku
* kwin-screen-edges.patch - poprawka na powracające ustawienia rogów ekranu
* libkonq-copytomenu.patch - poprawka na duplikaty ostatnio wybranych katalogów w Kopiuj/Przenieś do
* okular-cbz-fix.patch - poprawka na crash przy otwieraniu archiwów CBZ
* okular-cbz-multidir.patch - poprawka na wielokatalogowe archiwa CBZ
* okular-menubar.patch - poprawka na znikające menu po wyjściu z trybu pełnoekranowego
* plasma-workspace-fix-extender.patch - poprawka na błędne ukrywanie

W moim katalogu files jest jeszcze parę innych łatek, w tym moja próba poprawienia popupów z nazwą pulpitu, poprawka na jeden niegroźny warning i obejście na niekompilujące się pykde4.

Dodam jeszcze, że pod nvidia-drivers w wersji 180.16 nie ma już wycieków pamięci, dzięki czemu daje się już całkiem normalnie pracować. Jeśli używacie 180.11 albo 180.06, upgrade jest wysoce zalecany.

KDE 4.2 beta2 działa u mnie całkiem dobrze. Nie mogę narzekać. Już nie potrafiłbym wrócić do używania KDE 3.5. Od samych screenshotów swojego starego pulpitu robi mi się strasznie dziwnie Po raz pierwszy od dawna mam uczucie, że mój pulpit jest ładny i funkcjonalny jednocześnie. KDE 4.2 to zaiste jedna dziesiąta odpowiedzi na życie, wszechświat i całą resztę

Kolejny post, kolejna wersja KDE4 Tym razem będzie krótko, bo i zmian wiele nie uraczyłem:

+ Ark jest nieco mądrzejszy, ale poważniejszych zmian należy spodziewać się dopiero w KDE 4.2
+ Poprawiono błąd, który powodował, że po ściągnieciu nowego stylu Plasma, był wybrany niewłaściwy styl z listy
+ Nowa wersja znacznie szybciej się włącza, ale nie pojawił mi się splash. Nie wiem czy to celowe.
- Skróty klawiszowe nadal chodzą dość dziwnie. Podobno ma się to zmienić w KDE 4.2.
- Przewijanie w Dolphinie nadal dziwnie powolne, ale nie wiem czy to nie wina Nvidii

Już lada dzień premiera finalnej wersji KDE 4.1. Wiele osób zapewne przejdzie przy jej okazji na KDE4. Inne, podobnie jak ja, poczekają na KDE 4.2 i/lub nowe sterowniki od Nvidii, na których będzie to żwawiej chodzić. Bo w gruncie rzeczy poza skrótami klawiszowymi, które nie chodzą jak trzeba, mierzi mnie właśnie to uczucie powolnego działania. Mam nadzieję, że z jakieś pół roku, kiedy wyjdzie KDE 4.2, wszyscy zapomnimy o tych bolączkach.

Ponieważ nie mogę się doczekać finalnego wydania KDE 4.1, zainstalowałem sobie ostatnio jego pierwszą betę z repozytorium kdesvn-portage i muszę przyznać, że dość szybko nabiera to kształtu. Wiele rzeczy zmieniło się na plus, ale parę irytujących bugów sprawia, że z migracją wstrzymam się co najmniej do KDE 4.1 final.

Moje odczucia:
+ W końcu w miarę kompletna konfiguracja panela
+ Chodzi wyraźniej szybciej niż 4.0
+ Nareszcie można wyłączyć powiadomienia dźwiękowe, uff
+ Dzięki folderview można mieć ikony pulpitu, które zachowują się bardziej "tradycyjnie"
+ Odpowiednio skonfigurowane folderview naprawdę ułatwia życie, a dzięki tej łatce nie narzuca się wyglądem
+ Dolphin jest niesamowicie wygodny
+ Podoba mi się zunifikowane API do zakładek
+ Gwenview dostało mocnego kopa i jest teraz naprawdę szybkie
- Na nvidia-drivers konsole potrafi dziwnie przymulić przy włączonej przezroczystości
- Brak "udawanej" przezroczystości, a jednak czasem by się przydała
- Własne skróty klawiszowe coś nie działają
- Ark nie chce działać z archiwami tar.gz/tar.bz2
- Okazjonalne błędy przezroczystości w zasobniku systemowym
- Device notifier nie pokazuje udziałów NFS
- Klasyczne menu trochę odbiega funkcjonalnością od poprzednika
- Nie można zamienić menu pulpitu na kmenu jak w KDE3 (fluxbox-style)
- Brak kio_rar

Do mety już naprawdę niedaleko. Przyszłość zapowiada się ciekawie. Pozostaje tylko czekać

Od dłuższego czasu używałem baselayouta w wersji 2.0.0_rc6. Chodziło to to całkiem zgrabnie. Włączało i wyłączało się dużo szybciej niż baselayout-1.12.x. Jednak natura bardzo nie lubi stać w miejscu. I w ten sposób z drzewa Portage wyleciała wyżej wymieniona wersja, a jej miejsce zastąpił fork o nazwie OpenRC. Z początku podchodziłem do sprawy ze sporą dozą sceptycyzmu. Obawiałem się, że out-sourcing systemu startowego może negatywnie wpłynąć na jego jakość. No, ale w końcu przezwyciężyłem strach zainstalowałem OpenRC (oczywiście zrobiłem najpierw backupa... tak, do ciebie piję, lazy_bum ). Ogólnie rzecz biorąc, jest bardzo fajnie. Zyskałem nawet parę sekund podczas startu. Szczegóły dot. migracji i pułapek, na jakie się natknąłem, znajdziecie poniżej.

Dodałem odpowiednie wpisy do package.unmask i package.keywords. Potem odmaskowałem udeva, bo OpenRC domaga się nowszej wersji. Biorąc do serca ostrzeżenia, odmaskowałem też nowsze splash-utils i wygenerowałem ponownie initrd ze splashem. Dobra, na razie żadnych problemów. Merdżnąłem openrc-0.2-r2. Przyszła kolej na zabawę z konfiguracją.

Ustawienia z /etc/conf.d/rc przeniosły się do /etc/rc.conf. Parę zmiennych zniknęło, wszystkie są teraz pisane małymi literami. Parę starych skryptów wyleciało, pojawiło się parę nowych. Wyleciał m.in. clock, którego miejsce zajął hwclock. Ustawienia strefy czasowej powinno się teraz przechowywać w /etc/timezone, a nie jako zmienną w /etc/conf.d/clock. Automatycznie ładowane moduły dopisuje się do /etc/conf.d/modules zamiast /etc/modules.autoload.d/*. Ebuild powinien teoretycznie automatycznie przenieść te rzeczy gdzie trzeba. Nie wiedzieć czemu u mnie tak się nie stało.

Niemniej jednak system włączył się mniej więcej poprawnie. Czemu mniej więcej? Dodana w ostatniej chwili łatka multilib skopała mark_service_* w skryptach sieciowych. Neostrada wymagała restartu net.ppp0, żeby zadziałać. Poprawiłem ręcznie dwie linijki i wszystko zaczęło śmigać. Potem przeczytałem, że w wersji GIT ten błąd został ładniej naprawiony. A że apetyt rośnie w miarę jedzenia, postanowiłem zainstalować openrc-9999 z oficjalnego drzewa.

I tu w sumie spotkało mnie najwięcej niespodzianek. Pierwsza sprawa, /etc/modules.autoload.d poleciało w kosmos. Tak po prostu, bez ostrzeżenia. Kod migrujący nie wygląda za ciekawie. Może mnie oczy mylą, ale wyraźnie najpierw KASUJE modules.autoload.d, a POTEM próbuje importować ustawienia. Jakaś bzdura. Na szczęście miałem kopię. Poza tym jedna zmiana, o której wyczytałem w commit-logu: ustawianie kodowania konsoli zostało wydzielone do skryptu termencoding. Dodałem go profilaktycznie do runlevelu boot.

Merdżując coś, zauważyłem błąd z KV_MINOR, a rc-update pokazywało, że cryptoloop wymaga nieistniejącego checkroot. Na to pierwsze już dodano łatkę. Można też odmaskować nowsze module-init-tools i problem z głowy. Co do cryptoloopa, starczyło przemerdżować util-linux. Zdaje się, że w międzyczasie poprawiono skrypt startowy. Nie, żebym tego używał

Ostatnim problemem jest to, że OpenRC jest... za szybkie Zanim modem od Neostrady zdążył się zsynchronizować, już uruchomione było net.ppp0, które wykładało się na łopatki. Co ciekawe, błąd pojawił się dopiero w wersji GIT, nie w 0.2. Czyżby coś popsuli? W każdym razie, problem rozwiązałem malutkim skryptem, który sprawdza czy modem jest "operational" i opóźnia net.ppp0 do skutku. O tym workaroundzie postaram się napisać w oddzielnym poście.

Na deser, dla tych, którzy dotrwali do końca, parę obrazków:
Baselayout-2.0.0_rc6
OpenRC 0.2
OpenRC GIT

Jak widać nie zyskałem wiele - tylko 4 sekundy. lazy_bum zyskał troszkę więcej. Szczerze mówiąc, nie spodziewałem się żadnego przyśpieszenia, bo Baselayout 2.0.0_rc6 to praktycznie to samo co OpenRC. Z wykresów najbardziej intrygujący jest ten z wersji GIT. Czas dokładnie ten sam, co w OpenRC 0.2, ale przepustowość półtora raza większa! Nie wiem skąd ten efekt, ale narzekać nie będę