Posty

Wyświetlanie postów z maj, 2016

Kaffeine 2.0

Kiedyś, jeszcze w czasach KDE 3.x, odtwarzacz multimedialny Kaffeine był dość popularnym składnikiem wielu dystrybucji, które były konfigurowane z tym środowiskiem. W czasach KDE4 jego rola została przyćmiona. Więcej dystrybucji serwowało to środowisko bądź to z domyślnym Dragon Player, bądź też z SMPlayer lub VLC. Samo Kaffeine, choć zostało sportowane do Qt4/KDE4 raczej też nie rozbawiało wprowadzaniem co rusz to nowych wersji, czy wydań. Projekt wydawał się żyć na uboczu. Pewnie nie pomaga mu również i to, że musi on być "drugim" odtwarzaczem w systemie. Jest on bowiem zależny od jednej z bibliotek rozprowadzanych wraz z VLC. Z niejakim zdziwieniem zatem zobaczyłem dzisiaj, że wypuszczona została nowa wersja oznaczona numerem 2.0.0, która została w całości przeportowana do Qt5/KF5. Otrzymała ona również wsparcie dla DVB-T2. Naprawiono też wiele dostrzeżonych błędów. W repozytoriach Archa (community) znajduje się paczka 1.3.1. Jeśli ktoś chciałby sobie jednak stworzyć wła

HARDCORE - Kompilacja programu pod własny procesor, cz. 1 - qmake

Kompilując program w Arch Linux makepkg wykorzystuje ustawienia w pliku /etc/makepkg.conf. Tam można m.in. wymusić kompilację uwzględniającą określony rodzaj procesora. Innymi słowy, program skompilowany na danej maszynie winien - przynajmniej w teorii - być do niej bardziej dostosowany. Ma to swoje oczywiste konsekwencje. Program tak zbudowany może nie działać na innym komputerze, który ma inny - choćby nieco - procesor. Także po wymianie procesora możemy zostać niemiło zaskoczeni. Niektóre programy nie lubią też takiej, "wymuszonej" kompilacji. Ustawienia w /etc/makepkg.conf są jednakże ignorowane, gdy program jest prekompilowany z użyciem qmake, bądź cmake. Nie oznacza to, że nie można w tych przypadkach skompilować go z użyciem odpowiednich flag. W pierwszej części napiszę jak to zrobić dla qmake. Po pierwsze musimy mieć skrypty umożliwiające budowę paczki dla Archa. Możemy je stworzyć we własnym zakresie, możemy - jeśli program ma zostać przerobiony z dostępnych w rep

Otter-Browser #125

Nie było publicznego wydania #124. Dzisiaj pojawiło się natomiast wydanie #125. Od czasu ostatniego, czyli #123 nie nastąpiło wiele zmian. Program zbudujemy ściągając archiwum skryptów niezbędnych do jego utworzenia. Następnie należy je rozpakować, przejść do utworzonego katalogu i tam wykonać makepkg. W konsoli wygląda to tak (zakładam, że polecenie tar wydawane jest w katalogu z pobranym archiwum): tar -zxvf otter-browser-weekly.tar.gz && cd otter-browser-weekly.tar.gz && makepkg -sirc

Niedziałający KWallet 5.22.0-2

Wczoraj w repozytoriach pojawiła się wersja 5.22.0-2 frameworka służącego zarządzaniem portfelem w Plasma 5. Wersja ta zawiera patch na jeden z błędów wykrytych w tej paczce. Problem w tym, że po aktualizacji, portfel (kwallet) nie rozpoznaje hasła. Możliwości uporania się z tym błędem jest kilka: cofnąć paczkę do wersji 5.22.0-1 (jeśli mamy downgrade, to downgrade kwallet ), ponoć, bowiem tego nie wypróbowałem - skasowanie portfela i utworzenie go na nowo, przebudowanie paczki lokalnie. Ja zrobiłem to ostatnie i z tego co wiem, u kilku osób to działa. Zatem możecie spróbować. $ yaourt -G kwallet && cd kwallet && updpkgsums && makepkg -sirc Nie wiem dlaczego sumy kontrolne są inne niż w PKGBUILDzie arojasa, stąd wymagana jest aktualizacja. Po zbudowaniu paczki konieczne jest przelogowanie Plasmy. EDIT: Wczoraj wieczorem udostępniona została paczka kwallet-5.22.0-3, która naprawia błąd.

Mniejszy program, to szybsze uruchomienie aplikacji

Przynajmniej w teorii. Szczególnie dla posiadaczy tradycyjnych dysków talerzowych. Na czym polega trick? Otóż aby program się uruchomił musi być wpierw wczytany do pamięci. Zanim to system uczyni musi wpierw go odczytać z dysku. Te są szybsze lub wolniejsze, jednakże nie ma jeszcze tak szybkich dysków, które dorównywałyby operacjom wykonywanym w pamięci RAM. Stąd też, gdyby program na dysku był mniejszego rozmiaru, to powinien on zostać szybciej uruchomiony. Nawet jeśli potem - już w RAM - komputer musiałby dokonać jego dekompresji. Spróbujmy zatem poddać kompresji program wykonywalny tak, jak to czynimy w przypadku różnego rodzaju dokumentów. Narzędzia kompresujące programy wykonywalne znane są na niemal każdy system operacyjny. Od dawna jest też znane takie narzędzie dla linuksa. Mi znane jest jedno, choć nie wykluczam, że jest takich więcej. Tym programem kompresującym jest Ultimate Packer for eXecutables  - w skrócie upx. Z podanej wyżej strony dowiecie się więcej, w tym również o

Program nie może się uruchomić, bowiem brakuje jakiejś biblioteki

Osoby użytkujące Arch Linux w stabilnej wersji nigdy nie powinny się spotkać z omawianym tu "błędem". Niemniej jednak tylko wówczas, gdy ograniczą się do stosowania programów znajdujących się w oficjalnych repozytoriach. Tu bowiem osoby odpowiedzialne za utrzymywanie paczek, z chwilą, gdy dochodzi do zmian jakichś bibliotek dbają o przebudowanie paczek i dostosowanie ich do nowych wersji. Niemniej jednak wielu z używających Archa buduje paczki także z AUR. Najczęściej to właśnie programy pochodzące z AUR nagle zaprzestaną działać. Przypomnę, albowiem szczególnie dla osób, które zmieniły dystrybucję z *buntupochodnych na Archa, czy - częściej - Manjaro: w AUR nie znajdują się żadne paczki. Tu są wyłącznie "przepisy" na podstawie których następuje lokalne budowanie paczki i jej instalacja. Jeśli jednocześnie opiekun takiej aplikacji w AUR "nie zauważy", że dokonane zostały jakieś zmiany w repozytoriach, które wymagają jego reakcji lub nawet pomimo tego, my n

KMail 5.0 i kłopoty z wyświetlaniem poczty IMAP

Istnieje możliwość, że spotkacie się z takim błędem: konta pocztowe (IMAP) w KMail 5.0 są prawidłowo skonfigurowane, poczta pobrana, ale lista maili pozostaje pusta. Prawdopodobnie za taki stan rzeczy odpowiedzialne jest wadliwe skonfigurowanie Akonadi. Zwykle, zaraz po instalacji używa ono SQLite3 jako silnika bazodanowego. Wszystko fajnie, mniejsze to od MariaDB, ale... no właśnie - nie zawsze z nową odsłoną KMail zadziała to prawidłowo. Informacje o rodzaju używanego silnika przez Akonadi zawarte są w pliku: ~/.config/akonadi/akonadiserverrc Najwygodniej jest plik ten edytować po prostu jakimkolwiek edytorem tekstowym (plain). Zanim jednak do tego przystąpimy należy Akonadi zatrzymać: $ akonadictl stop Następnie edytujemy wspomniany wyżej plik i w miejscu: Driver = QSQLITE3 w sekcji: [%General] wpisujemy: Driver = QMYSQL Pozostaje jeszcze - dla pewności - skasować dotychczasową bazę Akonadi: $ rm -r ~/.local/share/akonadi (oczywiście jak chcecie możecie zrobić sobie je

QupZilla 2.0

Od blisko 2 miesięcy w miarę popularna, szczególnie u osób korzystających ze środowisk opartych o Qt5 przeglądarka QupZilla jest już dostępna w wersji 2.0.0.  Wersja ta przynosi szereg poprawek, ale przede wszystkim jest pierwszą, która korzysta z nowego silnika. Miejsce dotychczasowego webkitu w wersji Qt zajął qt5-webengine. To fork silnika blink wykorzystywanego przez Chromium/Chrome i wiele innych przeglądarek do frameworka Qt5. Nie będę się rozpisywał, czy to dobry, czy zły krok - każdy może sobie ocenić to sam. Jedno jest pewne - QupZilla wykorzystując silnik będący pochodną blinka na pewno nie jest już tak "lekka" jak dotąd była. Zapotrzebowanie na zasoby komputera, a w szczególności na RAM wzrosło. To jednak nie cecha samej przeglądarki a właśnie owego silnika, który niezależnie od tego, czy napędza Chromium, Operę, czy QupZillę pochłania RAM w zawrotnym tempie wraz z każdą otwartą kartą. Osobiście jednak zaobserwowałem dwie dobre strony stosowania qt5-webengine w mie

Przyspieszamy usługę CUPS przy starcie systemu

Niemal nic tak nie wkurza człowieka, jak długie włączanie się systemu, gdy właśnie potrzebujemy na nim coś szybko zrobić. Każda sekunda wówczas może się liczyć. Nie będę teraz opisywał wszystkich sztuczek. Zajmę się tylko usługą CUPS, którą większość osób korzystających z drukarki uruchamia automatycznie przy strarcie systemu. Najczęściej jest podnoszona usługa o nazwie org.cups.cupsd.service . U mnie w systemie powodowało to kilku, czy nawet kilkunasto sekundową zwłokę w załadowaniu się systemu, zwłaszcza, gdy drukarka nie była podłączona do komputera. Rozwiązanie jest proste. Zamiast powyższej usługi uruchamiamy "gniazdo" (nie wiem jak to powinno zostać prawidłowo przetłumaczone) - socket: sudo systemctl enable org.cups.cupsd.socket oraz, aby skorzystać już w tej sesji z tej usługi: sudo systemctl start org.cups.cupsd.socket Oczywiście należy też deaktywować usługę dotychczas stosowaną: sudo systemctl disable org.cups.cupsd.service I w zasadzie tyle. Od tej pory usług

Radzimy sobie z: GPG: odbiór z serwera kluczy nie powiódł się: brak dirmngr

Od dłuższego już czasu Arch wprowadził podpisywanie paczek kluczem gpg. W zasadzie wszystko winno przebiegać bezboleśnie nawet, gdy trzeba owe klucze dodać. Niestety zdarza się (mi się niegdyś zdarzyło), że próba dodania klucza GPG zwraca następujący błąd: sudo pacman-key -r ID_KEY gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: Wywołanie connect dla IPC nie powiodło się gpg: odbiór z serwera kluczy nie powiódł się: Brak dirmngr Na nic nie zdają się również "zwykłe" próby poradzenia sobie w takich przypadkach, jak: # pacman-key --init # pacman-key --refresh-keys # pacman-key --populate Dalej otrzymujemy powyższy błąd. Nic straconego. Prawdopodobnie wydanie następującej komendy: dirmngr < /dev/null && sudo -i dirmngr < /dev/null spowoduje, że po jej użyciu klucze będzie już można dodawać bez żadnych problemów.

NanoPlayer - prosty odtwarzacz YouTube

Od jakiegoś czasu szukałem małej aplikacji, która umożliwiałaby odtwarzanie zawartości YouTube niezależnie od przeglądarki. Tak wiem, są tego typu aplikacje jak SMTube, a niektóre aplikacje audio-wideo umożliwiają również odtwarzanie tych zawartości. Aplikacja miała mieć możliwość prostego wyszukania treści w serwisie i jego odtworzenia. SMTube niby to oferuje, ale tak na prawdę jest to tylko niezależna od przeglądarki internetowej wyszukiwarka zawartości YouTube, która dla odtworzenia filmów wymaga już SMPlayer. Trudno to uznać za rozwiązanie "małe". Udało mi się znaleźć NanoPlayer , który spełnia w zasadzie wszystkie moje wymagania pomimo swej bardzo wczesnej jeszcze wersji. Nadto oferuje blokowanie reklam. Po kilku podejściach do PKGBUILDu prezentuję skrypty, które umożliwiają zbudowanie tej aplikacji. Test namcap wykaże, że plik wykonywalny nie znajduje się w swej "zwykłej" lokalizacji. Fakt. Dzieje się tak dlatego, że aplikacja z jakiegoś powodu musi swoje kom

Otter-Browser #123

Ukazało się właśnie nowe wydanie tygodniowe. Bez zbędnych komentarzy PKGBUILD. Przypominam, że po zmianach wprowadzonych w pacman 5.0.1, plik *.install nie jest już wymagany. # Maintainer: boenki <boenki at gmx dot de> # Maintainer: pavbaranov # Contributor: sir_lucjan pkgname=otter-browser-weekly _pkgname=otter-browser _pkgver=0.9.11 _weekver=123 pkgver=${_pkgver}.dev${_weekver} _devver=${_pkgver}-dev${_weekver} pkgrel=1 pkgdesc="Web browser controlled by user, not vice-versa" arch=('i686' 'x86_64') url="http://$_pkgname.org" license=('GPL3') depends=('qt5-multimedia' 'hicolor-icon-theme' 'qt5-webengine') makedepends=('cmake' 'qt5-tools') optdepends=('gstreamer0.10-ugly-plugins' 'hunspell' 'qtwebkit') conflicts=('otter-browser-git' 'otter-browser' 'otter-browser*' 'otter-browser-beta*' 'otter-browser-webengine-weekly&#

Tuning: wyłączamy core-dump

W przypadku nieoczekiwanego wyłączenia się programu, automatycznie uruchamiany jest proces coredump, który powoduje zrzut różnych informacji, które programistom mogą pomóc w rozwiązaniu problemu. Niemniej jednak, dla zwykłego użytkownika jest to proces zbyteczny, zajmuje miejsce, a nadto w owych zrzutach mogą być różne informacje, do których niekoniecznie chcielibyśmy, by ktokolwiek miał dostęp (co prawda są one niby czytelne wyłącznie dla roota, jednakże nie jest to w zasadzie żadne zabezpieczenie przed osobą, która potrafi się do partycji głównej "dobrać", nawet nieznając hasła root). Z punktu widzenia zwykłego użytkownika usługa ta może być po prostu zbędna. Wyłączenie można przeprowadzić w zasadzie na dwu poziomach. W przestrzeni użytkownika (userspace) oraz pozostałej. Wyłączenie pierwszej powoduje, że programy uruchamiane w userspace nie będą dokonywały zrzutów, jeśli niespodziewanie się wyłączą. Wyłączenie również drugiej powoduje, że coredump jest wyłączone dla wszy

Poprawiamy Plasma 5 - tuning środowiska cz. 2

Mała, magiczna sztuczka, która może (głównie) przyspieszyć otwieranie aplikacji w Plasma 5. Znana od lat, bo jeszcze z czasów KDE4, ale i w Plasma 5 funkcjonuje. Niektóre dystrybucje wprowadzają tę zmianę OTB. Zatem bardzo krótko: mkdir -p ~/.compose-cache ln -sfv /run/user/$UID/ /home/$USER/.compose-cache Wiele nie zyskacie - średni czas uruchamiania aplikacji winien się skrócić o jakieś 50-150ms, ale ta świadomość :)

Budujemy paczki z AUR bez yaourt, czy innego wrappera

Ze względu na to, że do świata Archa najczęściej droga prowadzi z innych dystrybucji, w internecie krążą różne mity. Tym razem wspomnę jedynie o tych związanych z AUR. Co rusz można się dowiedzieć, że repozytorium AUR to "takie PPA" (ze świata *buntu), czy nieoficjalne repozytoria znane innym dystrybucjom. Otóż nic bardziej błędnego. Podczas, gdy w PPA, czy w nieoficjalnych repozytoriach (Archowi takie również są znane) znajdziemy paczki binarne, to AUR jest jedynie składnicą "przepisów" pozwalających jedynie na skompilowanie programu ze źródeł i stworzenie z nich paczki, którą można zarządzać przez pacmana. Owe "przepisy" są po prostu instrukcjami, które potrafią odczytać narzędzia systemowe Archa. Praktycznie wszelkie narzędzia, jakie możemy wywołać w powłoce (np. bash). Co to oznacza dla użytkownika? Cóż - m.in. to, że skoro może być w tych "przepisach" dowolna co do zasady komenda, to biorąc pod uwagę, że nie istnieje jakakolwiek weryfikacja

HTTraQt-qt5

Aplikacja HTTraQt  służąca do pobierania stron internetowych w celu ich późniejszego przeglądania od dawna jest dostępna w AUR . Niemniej jednak wciąż jest to jeszcze wersja budowana w oparciu o Qt4. HTTraQt natomiast daje się zbudować z użyciem Qt5. Aplikacja ta jest swoistym GUI dla httrack, zatem wymaga jego uprzedniego zbudowania (dostępne w AUR ).  Samą wersję Qt5 aplikacji najwygodniej zbudować pobierając skrypty z AUR, a następnie podmieniając istniejący plik PKGBUILD na następujący. pkgname=httraqt-qt5 _pkgname=httraqt name=HTTraQt pkgver=1.4.7 pkgrel=3 pkgdesc="Is the clone from WinHTTrack tool. GUI is based on Qt5 libriaries." arch=('i686' 'x86_64') url="http://qt-apps.org/content/show.php/HTTraQt?content=155711" depends=('qt5-multimedia' 'qt5-base' 'httrack>=3') makedepends=('cmake') source=("http://freefr.dl.sourceforge.net/project/$pkgname/$_pkgname-$pkgver.tar.gz") conflicts=('

Nomacs 3.2.0

Ze względu na to, że nomacs nadal w repozytoriach jest w wersji 3.0.0, postanowiłem przedstawić przeróbkę oficjalnego PKGBUILDu umożliwiającego jego budowę w aktualnej wersji 3.2.0. PKGBUILD wykorzystuje wtyczki z gałęzi Master z GIT, zatem każda budowa może się nieco różnić od siebie. Z tego powodu PKGBUILD pomija sprawdzanie sumy kontrolnej pobranych wtyczek. Dla zbudowania pakietu niezbędny jest również plik nomacs.install, który pobieramy z oficjalnych źródeł paczki . Więcej o nowej wersji programu przeczytacie na blogu Salvadhora . PKGBUILD: # Maintainer: speps <speps at aur dot archlinux dot org> pkgname=nomacs pkgver=3.2.0 pkgrel=1 pkgdesc="A Qt image viewer" arch=(i686 x86_64) url="http://www.nomacs.org/" license=('GPL3') depends=('qt5-svg' 'exiv2' 'libraw' 'opencv' 'desktop-file-utils') makedepends=('cmake' 'qt5-tools') install="$pkgname.install" source=("http

KShutDown 3.99.1Beta

Ukazała się nowa wersja testowa KShutDown . Tym razem postanowiłem przedstawić alternatywny PKGBUILD (w stosunku do poprzedniego), wykorzystujący autorski skrypt. Zmianie uległa również nazwa. Obecnie wersja, jaką proponuję nazywa się kshutdown-kf5, albowiem jest przeznaczona dla środowisk wykorzystujących KDE Frameworks 5 i budowana jest z ich wykorzystaniem. Biorąc pod uwagę, że możliwe jest również zbudowanie wersji opartej wyłącznie o Qt5 posunięcie takie wydaje się być celowe. PKGBUILD: pkgname=kshutdown-kf5 _pkgname=kshutdown pkgver=3.99.1beta pkgrel=1 pkgdesc='Shutdown Utility for KDE' arch=('i686' 'x86_64') url='http://kshutdown.sourceforge.net/' license=('GPL') depends=('knotifyconfig' 'kidletime' 'hicolor-icon-theme') makedepends=('cmake' 'gcc-libs' 'automoc4' 'xdg-utils') install="$_pkgname.install" conflicts=('kshutdown' 'kshutdown-qt5') pr

Otter-Browser #121

Wprawdzie dzisiaj ukazało się dziesiąte wydanie beta Otter-Browser, to ja najpierw realizuję zaległości. Wydanie tygodniowe 121. Zresztą jak się wydaje, wydanie to nie odbiega (przynajmniej znacząco od beta 10). PKGBUILD: # Maintainer: boenki <boenki at gmx dot de> # Maintainer: pavbaranov # Contributor: sir_lucjan pkgname=otter-browser-weekly _pkgname=otter-browser _pkgver=0.9.10 _weekver=121 pkgver=${_pkgver}.dev${_weekver} _devver=${_pkgver}-dev${_weekver} pkgrel=1 pkgdesc="Web browser controlled by user, not vice-versa" arch=('i686' 'x86_64') url="http://$_pkgname.org" license=('GPL3') depends=('qt5-multimedia' 'hicolor-icon-theme' 'desktop-file-utils' 'qt5-webengine') makedepends=('cmake' 'qt5-tools') optdepends=('gstreamer0.10-ugly-plugins' 'hunspell' 'qtwebkit') conflicts=('otter-browser-git' 'otter-browser' 'otter-bro