maj 26, 2008

Wget z powiadomieniem

Podobnie jak wielu innych użytkowników linuksa, moim ulubionym programem do ściągania plików jest stary, poczciwy wget. Nie zawsze chciało mi się jednak sprawdzać czy wget skończył już pobieranie czy nie. Pomocna okazała się libnotify i aplikacja notify-send. Teraz, po skończeniu ściągania mam powiadomienie w prawym dolnym rogu czy pobieranie się udało oraz polecenie użyte do uruchomienia wgeta (czasem mam włączonych kilka wgetów, więc dobrze wiedzieć, który właściwie skończył działać). Wcześniej myślałem, żeby w powiadomieniu kopiowana była ostatnia linia wyjścia wgeta, gdzie zwykle pisze co zostało zrobione, ale w pewnych ekstremalnych warunkach mogłoby to spowodować niepotrzebne komplikacje.

Skrypt można pobrać tutaj: http://ecik.nonlogic.org/sc/wget. Do działania wymaga oczywiście wgeta i paczki libnotify. Na swoim systemie skopiowałem to do ~/bin, które mam ustawione w ścieżce (PATH=$HOME/bin:$PATH; export PATH w ~/.bash_profile).

Powiadomienie wget 1Powiadomienie wget 2

Posted by ecik under wget | Komentarze (2)

marzec 26, 2008

Fedora 9 Beta. Opowiadanie w dwóch aktach.

Akt 1 - wtorek, 25 marca 2008

Zapalony użytkownik Fedory, którego w dodatku można nazwać deweloperem dystrybucji ucieszył się niezwykle, gdy na liście dyskusyjnej szanowany, znany i lubiany Jesse Keating ogłosił wydanie przesuniętej o pięć dni wersji beta Fedory z numerkiem 9. Czym prędzej w swojej muzycznej przeglądarce internetowej włączył odpowiednią stronęi polecił programowi BitTorrent, aby Fedora-9-Beta-Live-x86_64 rozpoczęła swoją drogę na dysk twardy. Czynność ta trwała nieco dłużej, niż szanowny użytkownik mógł przypuszczać, na co wpływ mogła mieć niewielka ilość peerów na początku pobierania. Dzielna społeczność opensource’owa niedługo potem postarała się jednak, by plik był łatwiej ściągalny i dzięki temu wykorzystując maksymalne możliwości przepustowości łącza znalazł się na dysku. Stało się to o godzinie 17:38.

Sprawdźmy sumy SHA1 - pomyślawszy, użytkownik wpisał sha1sum Fedora-9-Beta-Live-x86_64.iso. Jego oczom ukazał się oczekiwany rezultat 424797f7a568726cc76c66735e8b63fb6aaea228. Wtedy wystarczyło już znaleźć odpowiedni nośnik typu RW i zacząć wypalanie. Przebiegło ono bez większych trudności i użytkownik mógł już z uśmiechem na twarzy przystąpić do ponownego uruchomienia komputera i poznania uroku nowej wersji Fedory.

Warto tutaj nadmienić, że najważniejszym powodem, dla którego ów użytkownikowi zależało na sprawdzeniu jakości działania dystrybucji były problemy z dźwiękiem, będące jego zmorą w używanej na co dzień Fedorze 8 (hałas zamiast dźwięku w niektórych aplikacjach uruchamianych przy pomocy WINE lub DosBoksa). Tymczasem komputer zrestartował się i stało się to, czego użytkownik się spodziewał - bo zdarzało się to przy każdej dystrybucji typu Live. Chodzi o “nielubienie się” otwartego sterownika nv z kartą graficzną - zamiast obrazu widać jedynie kolorowe paski.

Trzeba zainstalować binarne sterowniki nVidii - pomyślał - ale najpierw potrzebna jest sieć. Automatycznie wklepał system-config-network-tui i… zdziwił się. Pojawiło się niebieskie okno, które chwilę później znikło. Z niedowierzaniem wpisuje system-config-network-tui raz jeszcze, ale wynik był ten sam. Standardowa metoda konfiguracji sieci nie działała. Zaświtała użytkownikowi taka myśl, że to może być wina wprowadzonego na szerszą skalę w F9 Network Managera. Po starannym sprawdzeniu wszystkich możliwości, skonkludował, że NetworkManager nie daje żadnej konfiguracji z poziomu wiersza poleceń. Próba naprawienia NM zajęła dość wyraźny kawałek czasu. W końcu, nie wytrzymawszy, wyłączył wszystko co z NM związane, zamontował dysk ze swoją Fedorą i skopiował kilka plików konfiguracyjnych i osiągnął zamierzony efekt. Sieć działała.

Na twarzy użytkownika wyraźne już było zmęczenie spowodowane problemami sieciowymi, więc liczył, że instalacja sterownika graficznego nie sprawi większych problemów. Przeliczył się. Ku jego zdumieniu kmod-nvidia pociągnęło ze sobą takie zależności jak gcc, gcc-c++, binutils czy choćby wget (który nie znajduje się w domyślnym zestawie pakietów Live!). To wszystko dało łącznie 48 MB do pobrania. Łącze nie działało wtedy na najwyższych obrotach, więc użytkownik spasował. Odłożył testowanie na kolejny dzień.

Później jeszcze, poczytał kilka manuali, by dowiedzieć się jak szybko i efektywnie może skonfigurować sieć nie wyłączając nawet NetworkManagera. Cały problem tego dnia polegał na nieznajomości przez niego polecenia route co uniemożliwiło ustawienie poprawnej bramy domyślnej. Ale nauczony doświadczeniem i dokumentami, optymistycznie patrzył w przyszłość…

Akt 2 - środa, 26 marca 2008

Tym razem użytkownik nie włączał już w ogóle trybu graficznego, przy uruchomieniu Live polecił, aby system działał w trzecim poziomie uruchamiania. Dzięki nabytej w dniu wcześniejszym wiedzy, bezproblemowo skonfigurował sieć i mógł szybko rozpocząć ściąganie. W międzyczasie zainteresowało go dlaczego zwykłe moduły do kernela wymagają pakietów związanych z budowaniem paczek i programowaniem. Okazało się, że wprowadzono Akmods, które sprawia, że moduły kernela są kompilowane przy uruchomieniu systemu (jeśli nie zostały wcześniej). Użytkownik uznał to za mądre rozwiązanie dla wersji deweloperskiej dystrybucji, ale w finalnej oczekiwałby jednak starego rozwiązania (bo po co zwykłemu użytkownikowi np. gcc? - pytał retorycznie). Gdy już wszystkie pakiety się poprawnie ściągnęły i zainstalowały, użytkownik poprawił plik xorg.conf (sedem, gdyż Live nie instaluje vima ani emacsa…) i z wielkim oczekiwaniem wpisał telinit 5. Niestety. Ku jego zdumieniu dostał informację, że nie ma odpowiednich plików, by skompilować moduł kernela.

Krótkie dochodzenie wykazało, że przyczyną takiego stanu rzeczy jest fakt, iż wersja kernela, z którą włączył się Live to 2.6.25-0.121.rc5.git4.fc9, natomiast nagłówki i paczka -devel z repozytorium rawhide ściągnęły się w wersji 2.6.25-0.150.rc6.git7.fc9. Potem okazało się, że nagłówków z wersji z bety już w ogóle nie ma w repozytorium. Użytkownik musiał więc uruchomić lynksa i dzięki koji ściągnąć wymagane pakiety. To wszystko zaczęło go jednak coraz bardziej denerwować. Problemy piętrzyły się jak Himalaje.

W końcu osiągnęły Mount Everest. Wszystkie paczki znalazły się na dysku i wystarczyło wpisać akmodsd, by moduł do kernela zaczął się kompilować. I tak działo się przez sekund kilka, aż nagle na ekranie ni stąd, ni zowąd pojawił się komunikat z syslogd, który mówił o błędzie wejścia/wyjścia ext3. System stracił responsywność, wykonanie jakiejkolwiek czynności tym samym stało się niemożliwe. Rozdrażniony użytkownik wyciągnął prawy palec wskazujący i nacisnął przycisk Reset na obudowie. Zraził się bardzo do wydania beta swojej ulubionej dystrybucji…

Posted by ecik under fedora | Komentarze (10)

marzec 3, 2008

REnouveau

Jakiś czas temu natknąłem się na projekt REnouveau, który polega na uruchomieniu na swoim komputerze odpowiedniej aplikacji, która przeprowadziwszy pewne testy, zapisuje ich wynik do plików. Następnie wyniki należy posłać do ekipy ekipy nouveau i w ten jakże prosty sposób możemy wspierać wolny sterownik. Postanowiłem przygotować paczki do tego sympatycznego narzędzia wraz z krótkim opisem co i jak.

Read more…

Posted by ecik under fedora, renouveau, rpm | Komentarze (1)

styczeń 14, 2008

Kadu-0.6.0-rc1

Tym razem zainteresowanych pierwszym kandydatem do wydania kadu zapraszam na wiki projektu, gdzie znajduje się informacja o tym jak uruchomić proste, tymczasowe repo z nowymi pakietami.

Posted by ecik under fedora, kadu, rpm | Komentarze (1)

styczeń 6, 2008

Kadu-0.6.0-beta2

Ściągamy nowe kadu. Dodano moduł agent. Miłego testowania.

http://ecik.nonlogic.org/rpm/kadu/beta2/

Posted by ecik under Bez kategorii | Komentarze (0)

grudzień 28, 2007

Kadu-0.6.0-beta1

Kolejne wydanie kadu spaczkowane. To co różni to wydanie od poprzednich to totalnie przebudowany spec, stukrotnie piękniejszy od poprzednich ;)

Nie ma submodułu kadu-audacious_mediaplayer, ponieważ nie kompiluje się z nową wersją audaciousa.

Życzę miłego testowania! :)

http://ecik.nonlogic.org/rpm/kadu/beta1/

Posted by ecik under fedora, kadu, rpm | Komentarze (0)

grudzień 19, 2007

Kadu 0.6.0-alpha2

Tym razem spaczkowanie zajęło trochę więcej czasu, ale w końcu jest.

Zapraszam do ściągania i testowania Kadu 0.6.0-alpha2 :)

http://ecik.nonlogic.org/rpm/kadu/alpha2/

Posted by ecik under kadu, rpm | Komentarze (0)

grudzień 14, 2007

Najpopularniejsze wideo w polskim YouTube

Dzisiaj przypadkiem dowiedziałem się co jest najpopularniejszym wideo w polskiej wersji YouTube’a. Nie da się ukryć, że jest to zaskakujące:

youtube

Pozostaje tylko pogratulować rodakom dobrego gustu muzycznego :) Oby tak dalej!

Posted by ecik under inne, muzyka, pink floyd | Komentarze (5)

grudzień 1, 2007

Kadu 0.6.0 alpha1

Kilka dni temu wydano nową wersję kadu, a tutaj już gotowe paczki do Fedory ;). Z różnych względów nie mogą one na razie trafić do repozytorium dlatego udostępniam je pod adresem: http://ecik.nonlogic.org/rpm/kadu/. Tamże należy wybrać odpowiednią architekturę i ściągnąć paczki. Do ich instalacji użyć albo rpm -Uvh, albo yum localinstall. Sporo dodatkowych modułów, które były w porzednich wersjach teraz albo nie działają, albo się nie kompilują więc jest ich całkiem mało.

Czy tak czy owak życzę owocnego testowania (bo sam mam na to mało czasu) i zgłaszania mi błędów.

http://ecik.nonlogic.org/rpm/kadu/

Posted by ecik under fedora | Komentarze (0)

listopad 9, 2007

Ja rozumiem…

Ja rozumiem, że życie paczkera nie musi być usłane różami.
Rozumiem, że deweloperzy dbają głównie o to, by im wygodnie rozwijało się aplikację.
Rozumiem, że dana aplikacja może wymagać sporego nakładu sił, by się dała zmienić w RPM.
Całkowicie jest dla mnie jasne, że jej struktura nie musi być zgodna z FHS.
Rozumiem i nawet cieszę się, że twórcy pozwalają (pozornie) na pewną dowolność.
Rozumiem, że paczkowanie gier może wymagać pisania dodatkowych wrapperów, aby wszystko mogło być na swoim miejscu.
Raduję się, gdy widzę, że mogę za pomocą podawanych parametrów zmienić domyślne zachowanie aplikacji.
Rozumiem, że to dla dobra potencjalnych użytkowników.
Rozumiem, że to po to, by każdy mógł mieć aplikację niemal dowolnie spersonalizowaną.

Ale…

Dlaczego długie i wytrwałe próby doprowadzenia do tego, by aplikacja się choć uruchamiała mogą zostać skwitowane iście durnym komunikatem:

ERROR: Server has different base game directory (basewsw) than the client (../../usr/share/warsow/)

Tego zrozumieć nie potrafię.

Posted by ecik under fedora, rpm | Komentarze (0)

Next Page »