Sprzątanie w Debianie, czyli jak usunąć stare pakiety.

Debian to system, który – na podstawie założeń twórców i moich doświadczeń – bez problemu można zaktualizować do kolejnej wersji. Jednak – jak pokazuje praktyka – nie zawsze zostaną przy tym usunięte wszystkie zbędne pakiety. Szczególnie, jeśli korzystamy z dodatkowych, nieoficjalnych repozytoriów. Poniżej quick’n’dirty sposób na półautomatyczne znalezienie i usunięcie pakietów, które nie mają już kandydata do instalacji z repozytorium.

Dziś siadłem na chwilę do starego desktopa, na którym działa Lenny. Taki pochodzący z upgrade od Sarge, przez Etch i parę wersji testowych, na dodatek nie wg release notes. Stwierdziłem (po odpaleniu mp3 z netu, które uruchomiło się w beep media player), że są jakieś stare pakiety typu proftpd-common, a miejsce na / się kończy. Pakiety stare, czyli takie z Sarge/Etch. Postanowiłem zrobić porządek. Szybki gógiel nie dał rozwiązania, a przyszedł mi do głowy prosty algorytm, więc stanęło na DIY.

Wyświetlenie pakietów, które są zainstalowane (lub ich pliki konfiguracyjne), a które nie są z Lenny’ego. Dodatkowo zapisujemy wynik do 2delete.txt w celu dalszej obróbki.

dpkg -l | awk '{print $2}' | perl -ne 'chomp; $res=`wajig policy $_ | \
grep lenny`; print $_,$/ if $?' | tee 2delete.txt

Założenie jest takie, że w /etc/apt/sources.list wszystkie wpisy odnoszą się do lenny. Jeśli mamy także stable, to należy zmienić grep lenny na egrep „lenny|stable”. Przed zrobieniem czegoś więcej należy przejrzeć listę w 2delete.txt i usunąć wrażliwe pakiety. Oraz te, które chcemy zatrzymać, mając na uwadze fakt, że powyższe polecenie wyświetli także pakiety zainstalowane ręcznie, np. własny kernel.

Jak już jesteśmy pewni, że wiemy co robimy (w przypadku usunięcia zbyt wielu pakietów możemy ładnie i łatwo zepsuć system do takiego stopnia, że bez liveCD nie przywrócimy go do działania) i że w pliku 2delete.txt nie ma jakichś jednak potrzebnych pakietów, to możemy spróbować automatycznie usunąć pakiety z listy (po jednym):

cat 2delete.txt | xargs wajig purge

Wynikowi powyższego warto się przyjrzeć, w szczególności błędom podczas przetwarzania. W moim przypadku wynikały one z zależności pomiędzy usuwanymi bibliotekami. Jednak wywołanie ich razem, w jednym poleceniu wajig purge rozwiązało problem.

Na koniec możemy zobaczyć, czy pojawiły się jakieś „sierotki” czyli wydajemy polecenie deborphan lub orphaner. Po usunięciu sierotek możemy spróbować wywołać dla pewności nasz pierwszy skrypt. A następnie zrestartować system (czyli tzw. chwila prawdy, czy się nie pomyliliśmy). U mnie działa.

Pyjama – czemu warto zgłaszać błędy w aplikacjach.

Niedawno Zal zachwycał się Pyjamą. Ja zachwycam się trochę mniej (patrz komentarze), ale i tak uważam to za wygodne narzędzie do integracji z Jamendo, na pewno wygodniejsze niż korzystanie bezpośrednio ze strony.

Główny bug, który mi się rzucił w oczy, to brak możliwości eksportu ulubionych albumów z Pyjamy do Jamendo. Zgłosiłem buga i… jeszcze tego samego dnia dostałem odpowiedź (taką miłą, z dziękuję i w ogóle), że bug jest, ale po stronie Jamendo. Nie mają API do ustawiania ulubionych, playlist (hmm?, na to chyba jest obejście…) itp. I raczej nieprędko się to zmieni (a szkoda).

W każdym razie Pyjama złapała kolejnego plusa – za szybką reakcję na błędy. Plus, pertraktuję dodanie workarounda. Skoro nie może być całkiem dobrze, to może chociaż będzie wygodniej. 😉

Virtualbox i własny kernel

Krótkie howto jak w Debianie Lenny korzystać z własnego kernela (tu: 2.6.30.5) i Virtualbox.

W związku z remasteringiem Knoppiksa na potrzeby Anonymiksa zainteresowałem się bliżej rozwiązaniami do wirtualizacji. Kiedyś (3 lata temu?) korzystałem z VMware Playera, który idealny nie był. Trochę za sprawą licencji, trochę za sprawą tego, że nie do końca pozwalał na tworzenie własnych obrazów. IIRC dało się je zrobić, z użyciem qemu. Także bootowaniem z CD było trzeba powalczyć. Z kolei remastering Knoppiksa na fizycznej maszynie jest jak najbardziej wykonalny, ale niewygodny – rebooty, uruchamianie Knoppiksa itd. Aż się prosi o wirtualizację.

Sporo dobrego słyszałem ostatnio o Virtualbox. Niestety, wersja w Debianie zrobiona jest pod konkretny kernel. Ponieważ znajomi korzystają, postanowiłem się zapytać, w jaki sposób. Okazuje się, że nie korzystają z wersji dystrybucyjnej, a z wersji bezpośrednio od producenta, czyli przez dodanie

deb http://download.virtualbox.org/virtualbox/debian lenny non-free

do /etc/apt/sources.list, a następnie apt-get install virtualbox-3.0. Tyle, że także korzystają z dystrybucyjnego kernela. Co mnie szczerze mówiąc zdziwiło, bo lapek i dystrybucyjny kernel jakoś mi ze sobą nie pasują (nie żeby nie działało, bo działa). Albo ja po prostu jestem dziwny i lubię mieć nowe i na miarę (I, ricer), albo jeszcze mam czas na takie zabawy. 😉

W każdym razie korzystanie z dystrybucyjnego kernela wydało mi się nieporozumieniem. Niemal takim nieporozumieniem, jak praca na fizycznej maszynie i rebooty (tak, wiem, przesadzam). FAQ na stronie i dokumentacja na pierwszy rzut oka nie przewidują takiej możliwości. Poszukałem więc rozwiązania ma własną rękę (pomoc na IRC jest przereklamowana). Nie pamiętam słów kluczowych do wyszukiwarki, ale ostatecznie trafiłem na ten wpis (dead link). Rozwiązanie jest – jak widać – bardzo proste.

Dla porządku, dla niespikających: należy pobrać paczkę .deb właściwą dla naszego systemu ze strony producenta i zainstalować ją (apt-get install pakiet.deb). Podczas instalacji, wykryty zostanie brak modułu i zostaniemy zapytani, czy chcemy zbudować tenże moduł dla aktualnie działającego kernela. Wymagane są oczywiście źródła (headers?) w /usr/src i narzędzia do kompilacji kernela. Zakładam, że jak ktoś ma custom kernel, to wie, co potrzebne. Wadą rozwiązania jest konieczność pamiętania o dpkg-reconfigure virtualbox po każdej zmianie kernela w celu zbudowania modułu dla nowej wersji. Dla 2.6.30.5 działa bez problemu.