vmario techblog

Na swoim Arch Linuksie pracuję pod GNOME, ale korzystam z kilku aplikacji KDE, w tym z Kile, który jest edytorem LaTeX-a. Przygotowałem dziś sprawozdanie z laboratorium, które chciałem wydrukować bezpośrednio z przeglądarki KDVI, jednak ta opluła mnie błędem /bin/bash: cupsdoprint: command not found. Pomyślałem, że może to wina kdemod3, które zawiera ten programik w jakimś oddzielnym pakiecie. Okazało się jednak, że wspomniany program znajduje się w systemie w katalogu /opt/kde/bin/ i powłoka bash widzi go, zarówno z konta użytkownika, jak i roota.

Postanowiłem zatem obejść problem, eksportując sprawozdanie do PDF-a i drukując za pomocą Evince. Niestety, z poziomu Kile nie udało się to ze względu na błędy w osadzaniu plików EPS (buntował się albo TeX, albo Evince, zależnie od użytego sposobu). Pozostał tylko wydruk do PDF-a z poziomu KDVI.

Rzuciłem jednak okiem na Options w oknie wydruku KDVI i zmieniłem opcję Print system currently used z CUPS na Generic UNIX LPD Print System. Ku mojemu zdziwieniu, wydruk ruszył, a co jeszcze bardziej zaskakujące, jakość okazała się lepsza niż w pierwszym obejściu problemu (wydruk był bardziej „gładki”).

Od czasu do czasu miewam coś w rodzaju przebłysku inteligencji, co na ogół objawia się tym, że usprawniam jakiś fragment mojego otoczenia, który od dawna mnie irytował.

Ostatnio padło na zbyt szerokie okno przeglądarki internetowej. Przyzwyczajony jestem do maksymalizowana okna Firefoksa, jednak w czasach coraz większych rozdzielczości ekranu nawyk ten niesie ze sobą pewną niedogodność. Otóż niektórzy twórcy stron nie ograniczają szerokości bloków z treścią, co owocuje wyświetlaniem zbyt długich wierszy tekstu, które po prostu nie nadają się do czytania.

Czytaj dalszą część wpisu »

Jeżeli wygenerujemy sobie klucz SSH (nazwijmy go test_id_dsa), korzystając z OpenSSH:

$ ssh-keygen -t dsa

to PuTTY przy próbie autoryzacji tym kluczem wesoło zamiga do nas komunikatem Unable to use key file „C:\test_id_dsa” (OpenSSH SSH-2 private key).

Zagadką jest dla mnie, dlaczego tego klucza nie przekonwertuje sobie w locie na swój własny format, ani nawet nie podpowie użytkownikowi, że ten może zrobić to ręcznie. Na szczęście, my wiemy, co robić.

Uruchamiamy PuTTYgen (PuTTY Key Generator), wybieramy Conversions -> Import key, importujemy klucz (jeżeli jest zabezpieczony hasłem, zostaniemy o nie zapytani) i klikamy Save private key. Otrzymujemy klucz test_id_dsa.ppk, który będzie akceptowany przez PuTTY’ego.

Jeżeli z jakichś powodów chcemy dokonać konwersji kluczy pod Linuksem, instalujemy PuTTY’ego, po czym wydajemy polecenie:

$ puttygen test_id_dsa -o test_id_dsa.ppk

Niedawno pisałem o tym, jak uporać się z uprawnieniami do urządzenia USB, reprezentującego programator AVR. Niedawno okazało się, że podobny trick pozwala zamontować lustrzankę Canon EOS 1000D.

Niestety, aparat, a konkretnie umieszczona w nim karta pamięci, nie jest widziana jako zwykły zewnętrzny dysk, ale jako urządzenie obsługiwane przez bibliotekę gphoto2. W przypadku Archa kończy się to tym, że po podłączeniu aparatu GNOME się buntuje: Błąd podczas inicjowania aparatu cyfrowego: -53: Nie udało się zawłaszczyć urządzenia USB.

Aby rozwiązać ten problem i uzyskać odpowiednie uprawnienia, dopisałem do mojego /etc/udev/rules.d/95-myrules.rules (nie edytowałem 54-gphoto.rules, żeby nic mi tego nie nadpisało przy kolejnej aktualizacji; poza tym wolę swoje wpisy trzymać w oddzielnym pliku):

ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="317b", ATTRS{product}=="Canon Digital Camera", GROUP="camera", MODE="0664"

Oczywiście, należy dodać się do grupy camera:

# gpasswd -a użytkownik camera

Niestety, funkcjonalność dostarczana przez gphoto2 okazuje się trochę uboga. Zdjęcia można pobrać bez problemu, jednak przy ich usuwaniu pojawiają się problemy (zwłaszcza, gdy chce się usunąć kilka na raz). Skopiować czegokolwiek na kartę w ogóle mi się nie udało. Poza tym, przed importowaniem zdjęć z za pomocą digiKama należy odmontować aparat z poziomu GNOME, gdyż inaczej digiKam nie będzie mógł uzyskać dostępu do danych. A może ktoś zna rozwiązanie tych problemów?

PS. Pliki RAW można wywołać za pomocą plugina do GIMP-a o nazwie ufraw. W Archu jest on dostępny w paczce gimp-ufraw.

Stanąłem przed zadaniem rozdzielenia sygnału telewizyjnego na dwa telewizory. Zdawało mi się, że zakup rozgałęźnika rozwiąże cały problem. Okazało się jednak, że nie wziąłem pod uwagę jednego — w powszechnym użyciu są dwa standardy złącz: złącze F, w które był wyposażony rozgałęźnik, oraz zwykłe złącze antenowe (Belling-Lee connector, IEC 169-2 connector, TV aerial plug), w które wyposażone są odbiorniki i gniazdo z sygnałem. Byłem tą niespodzianką lekko skonfundowany, w końcu student elektroniki powinien sobie z tak podstawowych rzeczy zdawać sprawę.

Czytaj dalszą część wpisu »

Kilka tygodni temu spotkała mnie niespodzianka, gdy na uczelni, po przejściu do drugiej sali, wyciągnąłem laptopa z plecaka. Kilkanaście minut wcześniej zamknąłem pokrywę, przyzwyczajony, że w takiej sytuacji, przy braku zasilacza, system automatycznie przejdzie w stan wstrzymania. Niestety, komputer był rozgrzany, bo cały czas pracował. Okazało się, że z menu GNOME w Archu (System -> Wyłączanie komputera) w ogóle znikły opcje dotyczące wstrzymania i hibernacji.

Przyczyną problemów jest chyba jakieś zamieszanie wokół HAL-a. Na szczęście na forum Archa można znaleźć proste rozwiązanie: do konfiguracji w pliku /etc/PolicyKit/PolicyKit.conf dopisujemy

<match action="org.freedesktop.hal.power-management.suspend">
<return result="yes"/>
</match>
 
<match action="org.freedesktop.hal.power-management.hibernate">
<return result="yes"/>
</match>
 
<match action="org.freedesktop.hal.power-management.shutdown">
<return result="yes"/>
</match>

Pierwsza opcja odpowiada za wstrzymanie, druga za hibernację, trzecia za wyłączanie systemu. Co prawda, opcja wyłączania jest dostępna i bez tego wpisu, ale ktoś dopisał ją na forum z komentarzem wskazującym, że może być ona przydatna do wyłączania laptopa przy krytycznie niskim poziomie naładowania akumulatora.

Zmiany powinny być widoczne w systemie od razu, bez restartowania czegokolwiek. W razie problemów można zapoznać się z drugim rozwiązaniem.

Chciałem dziś uruchomić płytę VCD na Ubuntu. Niby prosta rzecz, ale Totem uraczył mnie komunikatem:

Totem nie może odtworzyć tego nośnika (Video CD),
mimo że w systemie obecna jest odpowiednia wtyczka.

Rozpoczęły się boje, googlowanie i instalowanie odtwarzaczy. Ku mojemu zdumieniu okazało się, że problemy z odtwarzaniem VCD na Ubuntu są rzeczą normalną. Najprostszym rozwiązaniem jest zainstalowanie SMPlayera, czyli nakładki na MPlayera, który przenosi ten odtwarzacz w XXI wiek (czyt. czyni go przyjemnym w obsłudze). W SMPlayerze wystarczy wybrać Otwórz -> VCD i… usłyszeć film, bo z zobaczeniem może być różnie. Na komputerze, z którego skorzystałem karta graficzna (coś od ATI) jechała na sterowniku vesa, który nie miał zamiaru wspierać XVideo. Pozostało więc tylko skorzystać z gołego X11: Opcje -> Ustawienia -> Główne -> Wideo -> x11. Na szczęście komputer to udźwignął i film można oglądać nawet na pełnym ekranie.

Problemy ze sterownikami to zresztą oddzielna bajka. ati też nie chce włączyć XVideo, fglrx z repozytorium również, z tym, że można skorzystać z wyjścia gl, ale cóż z tego, skoro fglrx gryzie się z monitorem i obraz podczas normalnej pracy jest przesunięty o parę pikseli i miejscami lekko rozmazany (rozdzielczość zdaje się być niezmieniona)? Oczywiście, można by spróbować z fglrx bezpośrednio od producenta, ile jednak można walczyć z komputerem, by obejrzeć VCD?

Wróćmy jednak do naszych odtwarzaczy. To, że SMPlayer rozwiązał problem, nie oznacza przecież, że z ciekawości nie sprawdzimy, jak z VCD radzą sobie inne. gxine? Rewelacja! Przez chwilę wyświetla nawet menu filmu, a przy okazji potrafi rozpocząć odtwarzanie od losowej sceny (sic!). VLC? Przycina dźwięk, o ile w ogóle uruchomimy płytę, bo trzeba wiedzieć, że domyślną ścieżkę

vcdx:///dev/hda  :audio-track=0

należy zmienić na

vcd:///dev/hda  :audio-track=0

Innych już odechciało mi się sprawdzać…

Jak widać, z oglądaniem filmów VCD na Ubuntu są dziwne problemy. Na szczęście DVD odtwarzają się bez niespodzianek, chociażby w Totemie.

digiKam należy do moich ulubionych programów, mam z nim jednak jeden poważny problem — nie potrafię go zintegrować z GNOME-owym Nautilusem. W szczególności daje to o sobie znać, gdy chcę wydrukować zdjęcia w fotolabie albo po prostu skopiować je komuś na pendrive’a. Otóż digiKam pozwala mi otagować zdjęcia (np. „Do wydruku”), ale cóż z tego, jeżeli otagowanych zdjęć nie mogę skopiować na nośnik? Zwykłe Ctrl+C i Ctrl+V nie działa, gdyż najwyraźniej Nautilus i digiKam różnie podchodzą do kwestii przechowywania plików w schowku. Szukałem czegoś w opcjach digiKama, ale znalazłem tylko możliwość wypalenia płyty, a przecież nie o to mi chodzi. Wiem, że, przynajmniej kiedyś, tagi digiKama można było za pomocą odpowiedniego protokołu przeglądać w Konquerorze, nic mi jednak nie wiadomo na temat podobnych możliwości w Nautilusie.

Miałem więc do wyboru: kombinować i googlować, lub napisać skrypcik, który od ręki rozwiąże problem. I tak powstał DigikamCopier (żeby było zabawniej, niedługo po wydaniu RiverCopiera).

Czytaj dalszą część wpisu »

Pracuję obecnie nad przeportowaniem pewnego projektu napisanego w Pythonie na Linuksie do środowiska Windows. Ze względu na uciążliwą instalację Pythona i niezbędnych bibliotek na Windows chciałem skorzystać z py2exe, by otrzymać łatwy do przenoszenia plik wykonywalny. Problemy, które przy tym powstały to materiał na kilka wpisów, teraz jednak wspomnę tylko o jednym.

Otóż pewna biblioteka zgłasza podczas działania programu wyjątek. Nie jest to nic istotnego i w przypadku uruchomienia aplikacji w interpreterze Pythona dostajemy tylko śmieci w konsoli. Gorzej jest w przypadku pliku exe, gdyż po zamknięciu programu użytkownika straszy okienko „Errors occurred” zachęcające do przejrzenia loga: „See the log file ‘ścieżka do logu’ for details”. W rzeczy samej, w nazwa_aplikacji.exe.log mamy zapisane wspomniane ostrzeżenia, tylko po co one użytkownikowi?

Na szczęście możemy nakłonić py2exe, by zrezygnował z logowania błędów. Odnajdujemy plik boot_common.py, który u mnie znajduje się tu

C:\Python25\Lib\site-packages\py2exe\boot_common.py

i po linijce

sys.stdout = Blackhole()

dopisujemy

sys.stderr = Blackhole()

Rozwiązanie powstało na podstawie hacka opisanego na stronie py2exe.

Jestem w posiadaniu odtwarzacza iRiver T10. Nabyłem go ze względu na dobrą jakość dźwięku, możliwość odtwarzania plików Ogg Vorbis i długi czas pracy na baterii. Zasadniczą wadą, jaka dała się we znaki po pewnym czasie użytkowania, okazał się brak sortowania playlisty. Utwory odtwarzane są w takiej kolejności, w jakiej trafiły do pamięci urządzenia. Okazuje się, że nawet po zripowaniu płyty pliki wynikowe są rozrzucone po dysku i podczas kopiowania nie jest zachowana ich kolejność. Prawdopodobnie dałoby się rozwiązać problem za pomocą jakiegoś menedżera plików lub odtwarzacza audio, który pozwoliłby posortować pliki i przenieść je na urządzenie. Postanowiłem jednak spróbować napisać własny program, ucząc się przy okazji Pythona i PyGTK. W końcu tak wiele osób twierdzi, że gdy się nie ma jakiegoś programu na Linuksa, to przecież można go sobie napisać, korzystając chociażby z bogactwa języków skryptowych.

Prace rozpocząłem ponad półtora miesiąca temu i co kilka dni dopisywałem trochę kodu, wprowadzałem poprawki i usprawnienia. Koniec końców otrzymałem aplikację, która spełnia moje wymagania, choć dla kogoś innego może okazać się kłopotliwa w obsłudze. Niemniej jestem zadowolony z efektu, a także z tego, że zapoznałem się bliżej z Gitem, Pythonem i tworzeniem interfejsów graficznych z użyciem Glade i PyGTK. Sam Python okazał się przyjaznym językiem, za to PyGTK przysporzyło mi wiele problemów. Myślę, że warto je opisać, by pomóc innym, a także zachęcić do upartego pokonywania trudności.

Czytaj dalszą część wpisu »