poniedziałek, 30 maja 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łasną, lepiej integrującą się ze środowiskami opartymi o Qt5, to załączam PKGBUILD. Być może uda mi się wyodrębnić samą bibliotekę libvlc (a w zasadzie nie tyle ją wyodrębnić, co zbudować, albowiem na razie w tym drugim zakresie jest ona oporna), wówczas - najprawdopodobniej - Kaffeine mogłoby istnieć w systemie niezależnie od VLC.

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 repozytoriach, bądź AUR skryptów - skopiować je do dowolnego katalogu. W tym drugim przypadku, używam:
yaourt -G nazwa_programu
albowiem jest mi najwygodniej.
Przechodzimy do katalogu, w którym mamy skrypty i edytujemy PKGBUILD. Bardzo ogólnie ujmując, składa się on z dwu części:

  • pierwszej, w której wprowadzane są pewne deklaracje dla makepkg, gdzie znajdziemy m.in. informacje o tym, skąd skrypt ma pobrać źródła i
  • drugiej, w której umieszczane są instrukcje służące budowie paczki.

Tę drugą dość łatwo rozpoznać, albowiem po jakiś słowie nastąpi seria znaków: "() {". Np.  build() {.
W pierwszej części, np. na jej końcu umieszczamy zatem deklaracje dla kompilatora, które poinformują go o tym, pod jaki procesor chcemy zbudować paczkę. Dodajemy tam dwa wpisy:
CFLAGS="-march=FLAGA1 -mtune=FLAGA2"
CXXFLAGS="-march=FLAGA1 -mtune=FLAGA2"
Oczywiście możemy jeszcze precyzyjniej wskazać jakich opcji ma użyć kompilator.
W miejscu FLAGA1, FLAGA2, wpisujemy flagi właściwe dla naszego procesora, jeśli ich nie znamy, to wskaże je nam polecenie:
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
Możemy również pójść na pewne skróty, albowiem gcc od wersji 4.2 wprowadził flagę "native". Kompilator sam winien rozpoznać właściwe ustawienia dla naszego procesora i ich użyć. Wówczas powyższe deklaracje przyjmą postać:
CFLAGS="-march=native"
CXXGLAGS="-march=native"
Teraz odszukujemy sekcję rozpoczynającą się od: "build() {". Będzie w niej linia rozpoczynająca się od qmake (lub qmake-qt5) dla aplikacji budowanych z użyciem Qt5 lub qmake-qt4, dla zanikającego już, ale nadal obecnego Qt4. Tutaj, w poleceniach przekazywanych qmake musimy dodać:
CONFIG+=LINUX_INTEGRATED \
        QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
        QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}" 
Sekcja ta może przyjąć zatem następujący wygląd:
build() {
cd build 
qmake PREFIX=/usr \
CONFIG+=LINUX_INTEGRATED \
         QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}" 
make
}
W zasadzie powinno wystarczyć. Wydajemy teraz polecenie:
makepkg -s
(ewentualnie z innymi opcjami) i mamy nadzieję, że tak skompilowany program będzie działał na naszym komputerze lepiej od skompilowanego z użyciem flag generic i jedynie zadeklarowaniem 32 bądź 64 bitowego procesora.
Pozostaje jeszcze to sprawdzić (namcap) i zainstalować wykorzystując
pacman -U nazwa_paczki

środa, 25 maja 2016

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

wtorek, 24 maja 2016

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.

poniedziałek, 23 maja 2016

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 wspieranych przez narzędzie programach. Tu zajmę się wyłącznie podstawami jego stosowania i obsługi. Zanim jednak to tego przejdę - jedna uwaga: program wykonuje operacje na plikach wykonywalnych. Nie każdy program, który zostanie "potraktowany" przez upx będzie się nadawał do użytku. Nie każdy też się potem uruchomi. Koniecznie zatem albo wykonajmy kopię zapasową takiego programu, albo liczmy się z koniecznością ponownego jego zainstalowania. Szczególną ostrożność polecam wszędzie tam, gdzie program jest inicjowany przy starcie systemu. Jeśli nie wiecie jak się dostać do systemu bez uruchomionego środowiska, to powstrzymajcie się z kompresowaniem takich programów.
W pierwszej kolejności zaopatrujemy się w upx. Prosto, albowiem znajduje się on w repozytoriach Archa:
# pacman -S upx
Teraz już przystąpić możemy do kompresowania wybranych przez nas programów. Co do zasady znajdziemy je w /usr/bin, niekiedy również w katalogach programów w /opt, jeśli macie jakieś programy instalowane lokalnie, w /home to również i tu. Składnia jest prosta, a program niemal bezobsługowy. Polecam korzystanie z przełącznika best, albowiem upx wówczas sam dobierze najlepsze  kompresowanie dla danego rodzaju programu.
upx --best nazwa_pliku_wykonalnego
Pamiętajmy przy tym, że:

  • jak wspomniałem - warto zrobić kopię, może nam to zapewnić sam program przy użyciu opcji -k lub --backup,
  • jeśli polecenie wywołujemy z katalogu, do którego zwykły użytkownik nie ma dostępu do zapisu (/usr/bin, /opt/), to wykonać je musimy z uprawnieniami administratora,
  • kompresja programu może trwać dosyć długo, zwłaszcza, gdy użyjemy przełączników uruchamiających najlepszą możliwą kompresję.
Po wykonaniu polecenia, jeśli wszystko się powiodło możemy się cieszyć mniejszym programem, który przynajmniej teoretycznie winien się szybciej uruchamiać. Zaoszczędzi nam również nieco miejsca na dysku. Niektóre programy nie skompresują się, o czym zostaniemy powiadomieni. UPX nie skompresuje nam np. zbyt małych programów. Nie ma to sensu. Jeśli program nie będzie się uruchamiał po jego skompresowaniu, wówczas należy przywrócić kopię lub go przeinstalować. Sam program również pozwala na zdekompresowanie programu:
upx -d nazwa_programu
Polecam zatem wykonać próbę uruchomienia programu bezpośrednio po jego skompresowaniu, gdy jeszcze pamiętamy, co wykonywaliśmy, albo po prostu zapisanie gdzieś dokonywanych operacji.
Oczywistym winno być, że kompresji musimy poddać program po każdej jego aktualizacji.
Na jak dużą kompresję liczyć możemy? Cóż - to zależy już od danego programu. Bodaj jednym z lepszych przykładów jest program master-pdf-editor, który dla Archa jest przebudowywany z binarki udostępnionej przez autorów tego programu. W jego przypadku kompresja (na moim komputerze, bo nie wykluczam, że na innym systemie może być inna) sięga 42%, a rozmiar pliku zmniejsza się z 19743320 do 8281320 bajtów.
Oczywiście więcej o opcjach programu dowiecie się po wydaniu polecenia:
upx --help

sobota, 21 maja 2016

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 nie przebudujemy takiej paczki, to spotkać się możemy z sytuacją, w której wczoraj jeszcze działająca aplikacja nagle przestała działać. Uruchamiając taką aplikację w środowiskach graficznych najczęściej po prostu nic się nie wydarzy. Klikniemy na nazwę aplikacji, ta jakby się uruchamiała, ale po chwili nie ma jej śladu.
W takiej sytuacji najlepiej jest wywołać program z konsoli. Wówczas - być może - czegoś się dowiemy. Bardzo często będzie to informacja typu ("foo" jest tu dowolną nazwą):
(...) /usr/lib/foo.so.1 don't exist
Jeśli zobaczymy, że jest to jakiś plik, którego rozszerzenie to so, so.CYFRA, to chodzi o to, że program, który uruchamiamy - jeśli wcześniej się uruchamiał - nie jest przeznaczony do działania z wersją biblioteki, jaką mamy aktualnie w systemie. Jeśli w konsoli nie uzyskamy informacji o miejscu położenia biblioteki, to w pierwszej kolejności lokalizujemy ją. Skorzystamy z polecenia locate (jeśli ktoś w systemie nie ma, to można zainstalować paczkę mlocate, bądź posłużyć się jakimkolwiek innym programem przeszukującym dysk za plikami, np. na pewno zainstalowanym find).
locate foo.so.1
W ten sposób uzyskamy lokalizację tej biblioteki. Teraz korzystamy z pacmana:
pacman -Qo /usr/lib/foo.so.1
W wyniku uzyskamy informację do jakiej paczki należy /usr/lib/foo.so.1. Powiedzmy, że jest to paczka foo w wersji 1.2.3.
Przydałoby się dowiedzieć jaką wersję tej paczki oferuje Arch w repozytorium stabilnym i pozostałych. Znów skorzystamy z pacmana bądź yaourta:
pacman -Ss foo
lub jeśli mamy ją z AUR np.:
yaourt foo
Powinno nas to naprowadzić na to, skąd mamy zainstalowaną paczkę. Możemy jeszcze sprawdzić informacje o tym czyją jest zależnością, czy też w jaki sposób została ona zainstalowana:
pacman -Qi foo
Możemy przeglądnąć również dziennik logów pacmana, by dowiedzieć się kiedy, przy jakiej okazji tę paczkę zainstalowaliśmy. Znajduje się on w pliku /var/log/pacman.log. Jest to plik tekstowy, zatem przeglądać można go w dowolny sposób. W AUR znajduje się jednak wygodna przeglądarka tego pliku o nazwie pacmanviewer.
Wyposażeni w taką wiedzę powinniśmy teraz zadecydować, czy:
- cofnąć paczkę do działającej wersji (ale uwaga, wówczas inny program, który ściągnął właśnie tę bibliotekę w obecnej wersji może przestać działać),
- spróbować skompilować niedziałający program w oparciu o nową bibliotekę,
- (tak są jeszcze inne rozwiązania, ale na tyle ryzykowne i niepolecane, że nie będę o nich pisać; część z nas je zna, jeśli zna, to te rozwiązania są wyłącznie do nich adresowane, albowiem trzeba być bardzo mocno świadomym, co robimy i dlaczego; w związku z tym nie będę ich tu polecać).
Pierwsze dokonujemy - najwygodniej - narzędziem downgrade (jest w AUR). W drugim przypadku polecam następujące działanie:
yaourt -G foo && cd foo
Ściągnęliśmy "przepisy" umożliwiające budowę paczki i przeszliśmy do katalogu, w którym się one znajdują.
Teraz trzeba przeglądnąć PKGBUILD, albowiem, być może będzie on wymagać właśnie określonej wersji biblioteki. Jeśli tak jest możemy spróbować z wersjami rozwojowymi (git, svn, bzr itp.), albo udać się na stronę programu, gdzie być może uzyskamy jakieś informacje. Po ewentualnym dostosowaniu PKGBUILDu wydajemy polecenie:
makepkg -si
To oczywiście pewien schemat działania. Nie zawsze pomoże. Nie jest nawet w 100% polecany (albowiem niekiedy programy są przeznaczone do pracy z określonymi wyłącznie bibliotekami). Jeśli się powiodło - fajnie. Jeśli nie - trzeba szukać jakiegoś innego rozwiązania.

piątek, 20 maja 2016

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 jej kopię).
Teraz należy jeszcze uruchomić Akonadi:
$ akonadictl start
Od tej chwili, prawdopodobnie, będziecie się mogli już cieszyć prawidłowym działaniem KMail. W programie tym trzeba będzie na nowo skonfigurować konto i... dać mu sporo poczekać, by pobrał wszystkie wiadomości i je sobie poukładał.

czwartek, 19 maja 2016

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 miejsce qt5-webkit. Przeglądarka nie ma już wycieków pamięci, które się jej zdarzały. Wydaje się być też stabilniejsza. Trzecia cecha, to więcej stron internetowych się otwiera prawidłowo. Cóż - widać doskonałych rozwiązań nie ma, choć wydaje się, że zbudowanie przeglądarki opartej o Gecko i Qt5 mogłoby być krokiem w dobrym kierunku.
W repozytorium Archa nadal dostępna jest jednakże wyłącznie stara, oparta o qtwebkit/qt5-webkit wersja 1.8.9. Przyznam, że nie znam przyczyn takiego stanu rzeczy. W AUR dostępna jest m.in. wersja qupzilla-git, która budowana jest na podstawie aktualnie rozwijanego kodu w gałęzi 2.0.0. Jest to zatem wersja 2.0.0 wraz ze wszelkimi commitami, jakie od 30.03.2016 r. do kodu tego zostały dołączone. Stabilna wersja 2.0.0. nie jest zatem dostępna nigdzie.
Jeśli ktoś chciał używać stabilnej wersji, to udostępniam dla niej PKGBUILD (ściągnięty plik trzeba rozpakować do jakiegoś katalogu).
Decydując się na budowanie wersji opartej o qt5-webengine proszę wziąć pod uwagę, że:

  • silnik ten nie jest doskonały i ma szereg irytujących błędów,
  • wersja qt5-webengine, która pozwala na zbudowanie QupZilla 2.0.0. to minimum 5.6, ale nawet ona nie odpowiada najnowszemu blinkowi,
  • pomimo zastosowania zdecydowanie nowszego silnika, autorzy programu nie zdecydowali się na zmianę tzw. user agent, zatem przeglądarka w dalszym ciągu na niektórych stronach przedstawia się jako starsza niż jest w rzeczywistości,
  • z chwilą udostępnienia qt5.7, a wraz z nim qt5-webengine, niezależnie od tego, czy pojawi się nowa wersja przeglądarki proponowałbym jej przebudowanie - wprowadzany silnik będzie zdecydowanie nowszy, oparty o Chromium 49,
  • budujący przeglądarkę  wyłącznie dla środowisk opartych o Qt5 i niewykorzystujących libgnome-keyring mogą spokojnie usunąć tę paczkę z pól PKGBUILDu, gdzie się one znajdują, podobnie jak usunąć integrację przeglądarki z GNOME (sekcja build linia GNOME_INTEGRATION=true oraz znak "\" umieszczony na końcu linii powyżej,
  • prezentowany PKGBUILD umożliwia zbudowanie QupZilli wyłącznie w oparciu o Qt5,
  • używając QupZilli na co dzień, uważam, że lepszą alternatywą jest jej budowa w wersji rozwojowej (czyli qupzilla-git), jednakże wiem, że są osoby, których nikt nie przekona, że taka wersja może być stabilniejsza od "stabilnej" - dla tych osób prezentowany PKGBUILD.
PS: Wraz z niniejszym wpisem staram się zmienić sposób udostępniania przeze mnie plików. Są one umieszczone na dropboksie, a link umożliwiający ściągnięcie pliku powinien być dostępny po kliknięciu. W przypadku niniejszego wpisu - słowa PKGBUILD. Niestety, jako człowiek już w mocno podeszłym wieku, dla mnie dropbox, to nowinka w stosowaniu. Szczególnie w taki sposób. W przypadku jakichkolwiek błędów uprzejmie proszę o poinformowanie mnie o tym. Postaram się naprawić.

środa, 18 maja 2016

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ługa podnoszona będzie sprawnie przy starcie systemu i przejdzie w tryb "nasłuchiwania". Kiedy wydane zostanie polecenie drukowania, systemowi zostanie udostępniona drukarka i wszystko powinno przebiegać jak należy.

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.

sobota, 14 maja 2016

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 komponenty zawierać w jednym katalogu, czego nie powinno się robić tworząc jakiś katalog w /usr/bin. Wylądowała zatem w opt.
PKGBUILD:
# Maintainer: pavbaranov

pkgname=nanoplayer
pkgver=0.1b
pkgrel=2
pkgdesc="Extremely simple YouTube video viewer with adblock support"
arch=('i686' 'x86_64')
url="http://nanoplayer.sourceforge.net/"
license=('GPL2')
depends=('qt5-webkit')
makedepends=('imagemagick')
optdepends=('gst-libav' 'gst-plugins-ugly' 'gst-plugins-bad')
source=(http://sourceforge.net/projects/nanoplayer/files/NanoPlayer.zip/download
        $pkgname.desktop)
md5sums=('1a461d4384df09c7f19a1d1eac5ec23f'
         '9f720ce8442af33c2204a730b8bdc62c')

prepare() {
    cd $srcdir/NanoPlayer
    for i in *.ico; do convert "$i" "$i.png"; done
    mv NanoPlayer.ico.png nanoplayer.png
}

build() {
    cd ${srcdir}/NanoPlayer
    qmake-qt5 NanoPlayer.pro PREFIX=/usr
    make       
}

package() {
  install -Dm755 "${srcdir}"/NanoPlayer/NanoPlayer/NanoPlayer "${pkgdir}"/opt/NanoPlayer/nanoplayer
  install -Dm644 "${srcdir}"/NanoPlayer/data/filters.txt "${pkgdir}"/opt/NanoPlayer/data/filters.txt
  install -Dm644 "${srcdir}"/NanoPlayer/nanoplayer.png "${pkgdir}"/usr/share/pixmaps/nanoplayer.png
  install -Dm644 "${srcdir}"/${pkgname}.desktop "${pkgdir}"/usr/share/applications/${pkgname}.desktop
  mkdir -p "${pkgdir}"/usr/bin 
  ln -s /opt/NanoPlayer/nanoplayer "${pkgdir}"/usr/bin/nanoplayer
  }

nanoplayer.desktop
[Desktop Entry]
Type=Application
Name=NanoPlayer
GenericName=YouTube Player
Exec=/opt/NanoPlayer/nanoplayer
Icon=/usr/share/pixmaps/nanoplayer.png
Categories=AudioVideo

Po ściągnięciu tych plików, a przed wywołaniem komendy makepkg proszę wydać polecenie:
updpkgsums
Mam nadzieję, że i Wam się przyda.

EDIT:
Do poprawnego wyświetlania zawartości z YT potrzebne jest zainstalowanie pluginów gstreamera: bad, ugly i libav. Są one w optdepends, albowiem kod programu nie wymaga ich do swego zbudowania, ani do uruchomienia samego programu. Bez tych opcjonalnych zależności program nie będzie jednak wyświetlał treści i dekodował dźwięku. Powyżej już zmieniony PKGBUILD, ale sama instalacja paczki jedynie poinformuje o opcjonalnych zależnościach, które trzeba doinstalować odrębnie.

środa, 11 maja 2016

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' 'otter-browser-webkit-weekly')
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('a70a333199035703b55908337b2095ce')

build() {
  cd ${_pkgname}-${_devver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr" \
-DENABLE_QTWEBKIT=OFF
  make
}

package() {
  cd ${_pkgname}-${_devver}
  make DESTDIR=$pkgdir install
}

czwartek, 5 maja 2016

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 wszystkich sytuacji.
Pamiętajmy jednak, że wyłączając coredump możemy jednocześnie pozbawić się możliwości usunięcia jakichś awarii związanych z oprogramowaniem.

1. Wyłączenie coredump w userspace
Dokonujemy edycji pliku /etc/systemd/coredump.conf, odnajdujemy linijkę, którą domyślnie ma postać:
# Storage=external
i zmieniamy na:
Storage=none
Teraz jeszcze musimy o tym poinformować systemd:
# systemctl daemon-reload

2. Zerujemy przestrzeń dyskową dla zrzutów
Edytujemy plik /etc/security/limits.conf i dopisujemy:
* hard core 0
pod sekcją, która wygląda tak:
#<domain>      <type>  <item>         <value>

3. Zmieniamy ustawienia sysctl
Edytujemy bądź tworzymy plik: /etc/sysctl.conf i dopisujemy w nim:
fs.suid_dumpable = 0
Można też przekompilować kernel i w ogóle wyłączyć taką możliwość.

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ść :)

środa, 4 maja 2016

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 owych skryptów, ani też użytkowników, którzy je umieszczają w AUR (z wyjątkiem tej, przeprowadzanej na własnej skórze użytkowników), to "przepisy" te należy czytać. Jak mamy przepis kulinarny, w którym będzie napisane, by dodać arszenik, to też przecież nie zrobimy takiej potrawy.
Co to oznacza dalej? Jeśli to jedynie "przepis" na zbudowanie paczki, a pacman potrafi zarządzać dopiero paczką, to nie służy on do obsługi repozytorium AUR.
Nadto trzeba mieć świadomość, że pomimo tego, że w wiki Archa znajdziemy wielokrotnie jakieś instrukcje polecające instalację jakiegoś programu z AUR, to tak samo wiki (z wyjątkiem oficjalnego podręcznika), jak i AUR nie znajduje się pod opieką deweloperów tej dystrybucji. Arch udostępnia jedynie narzędzie do przeszukiwania repozytorium AUR, które obecnie mieści się na githubie. Brak wsparcia dla AUR przez Archa oznacza, że co do zasady nie trafią do jego repozytoriów narzędzia rozszerzające możliwości pacmana o obsługę AUR (tzw. wrappery). Nie znajdzecie zatem tu popularnego - choć odsądzanego od czci i wiary - yaourt, czy jakiegokolwiek innego.
Nadeszła zatem ta chwila, gdy jesteśmy po świeżej instalacji Archa i właśnie zacieramy ręce ze znanym hasłem w ustach: no i co by tu jeszcze spieprzyć, panowie. AUR jest świetną skarbnicą takich możliwości.
No, ale jak zainstalować z AUR cokolwiek, skoro brak ulubionego yaourta? Jogurt kupujemy w sklepie, a my zajmiemy się możliwościami, jakie tkwią w samym Archu. Przecież paczki budowane z AUR są według tych samych receptur, jakie obowiązują dla paczek umieszczanych w jego repozytoriach. Narzędzia zatem muszą w Archu być. I są.

W pierwszej kolejności trzeba zainstalować zbiór podstawowych programów, które służą rozwojowi paczek - należą one do grupy base-devel. Instalujemy:
# pacman -S base-devel
potwierdzając, że chcemy zainstalować wszystkie paczki. Co do zasady żaden program, który składa się na tę grupę nie będzie znajdował się w zależnościach służących do budowy pakietu (makedepends), zatem bez tego ani rusz. Z drugiej strony, jeśli jakikolwiek program służący do budowania paczki nie znajduje się w tej grupie, to winien on być dodany do makedepends. 
W tej chwili jesteśmy wstępnie przygotowani do budowy paczki z AUR (a także z oficjalnych repozytoriów, czy z innych miejsc, gdzie podawane są PKGBUILDy i pozostałe skrypty umożliwiające ich budowę).
Polecam jednak zaopatrzenie się również w walidatora PKGBUILD i paczek o nazwie namcap:
# pacman -S namcap
Wyszukujemy interesujący nas program w AUR na stronie: https://aur.archlinux.org/packages/
W ramce po prawej stronie znajdujemy "akcje" jakie możemy wykonać. Wpierw jednak czytamy komentarze. Już z nich możemy się bowiem wiele dowiedzieć. Zakładając, że wszystko jest ok, przeglądamy PKGBUILD. Musimy się bowiem upewnić, że to co chcemy zainstalować w istocie zostanie zainstalowane, a nie trafiliśmy na jakiegoś dowcipnisia. Wiemy co jest napisane - ok, nie wiemy, nie rozumiemy - to albo sięgamy po wiedzę bardziej doświadczonych użytkowników, albo ryzykujemy (wszak czy nie to robimy korzystając z wrapperów?).
Ze wspomnianej ramki ściągamy snapshot (Download snapshot), paczkę tar.gz, która zawiera całość skryptów. Najlepiej ją umieścić w jakimś katalogu, który służył nam będzie do budowania paczek, np. ~/builds. Po ściągnięciu do katalogu snapshota, rozpakowujemy go:
tar -zxvf nazwa_snapshota.tar.gz
W katalogu utworzy się nowy katalog o nazwie_snapshota. Przechodzimy do niego. W katalogu tym znajdziemy plik PKGBUILD oraz ewentualnie inne pliki służące do budowy paczki, takie jak pliki instalacyjne (*.install), czy różne patche (chyba, że te są pobierane bezpośrednio z sieci). Możemy teraz także dostosować PKGBUILD do swoich potrzeb. Należałoby się także upewnić, czy PKGBUILD jest prawidłowy. Do tego służy nam ów wspomniany wcześniej walidator:
namcap PKGBULD
Jeśli weryfikacja odbędzie się prawidłowo (czyli namcap nie zwróci nic, po wywołaniu przejdzie do lini promptu) - możemy przystąpić do budowy paczki. Jeśli coś zwróci, to PKGBUILD nie jest prawidłowy (lub namcap zadziałał niewłaściwie) - wówczas albo modyfikujemy PKGBUILD (jeśli wiemy co robimy), albo sięgamy po wiedzę bardziej doświadczonych użytkowników, albo... ryzykujemy.
Budową paczki zajmie się program makepkg. Wydajemy pierwsze polecenie:
makepkg -s
Przełącznik "-s", który do niego został dodany służy sprawdzeniu zależności. Jeśli pola depends i makedepends zawierają jakieś zależności, których w naszym systemie nie ma, to o ile znajdują się one w repozytoriach Archa (bądź szerzej udostępnionych w pliku /etc/pacman.conf), zostaną one dociągnięte i zainstalowane, a paczka będzie dalej budowana. Jeśli jednak makepkg zwraca informację o nierozwiązanych zależnościach i nie może ich pobrać, to co do zasady należałoby przyjąć, że jakieś zależności znajdują się w AUR. Tych makepkg nie umie automatycznie zainstalować. Musimy je sami wyszukać i zbudować przed budową naszego pakietu.
Jeśli budowa się powiodła, w katalogu, w którym budowaliśmy paczkę zostanie ona utworzona i będzie nosić nazwę rozpoczynającą się od nazwy_snapshota i kończyć rozszerzeniem pkg.tar.xz. Oprócz tego zobaczymy tam dwa katalogi: src oraz pkg. Pierwszy zawiera źródła programu oraz efekty ich kompilacji, drugi mieści - w pewnym uproszczeniu - niespakowaną paczkę *.pkg.tar.xz. Warto teraz po raz drugi sięgnąć po namcap tyle, że teraz wywołać go na paczce:
namcap nazwa_paczki.pkg.tar.xz
Jeśli wszystko przebiegnie prawidłowo, a przede wszystkim nie otrzymamy informacji o błędach w paczce (oznaczone one będą przez E), to możemy paczkę instalować:
# pacman -U nazwa_paczki.pkg.tar.xz
Jeśli jednakże namcap pokazał nam jakieś błędy, to mamy czas na ich naprawę w PKGBUILD. Po tej czynności wywołujemy polecenie:
makepkg -Rf
Przełącznik "-R" powoduje przebudowanie (przepakietowanie) paczki z uwzględnieniem nowego PKGBUILDu na podstawie już skompilowanych źródeł. Czynność ta zajmuje wiele mniej czasu niż budowanie paczki ze źródeł (ich kompilację). Przełącznik "-f" nadpisze wcześniej zbudowaną paczkę; jeśli ją wcześniej usuniemy - nie musimy go używać.
Po udanym zbudowaniu paczki i zainstalowaniu jej w systemie, możemy usunąć pozostałości po budowaniu, takie jak katalogi src i pkg, czy też całość katalogu, w którym paczka była budowana. Pamiętajmy jednak, że tak zbudowana paczka nie trafi do katalogu /var/cache/pacman/pkg.
Osobiście sugerowałbym co najmniej pozostawienie skryptów budujących paczkę (i ewentualnie ściągniętych źródeł), szczególnie gdy dokonaliśmy jakichś zmian w PKGBUILD. Pamiętajmy bowiem, że całość AUR jest poza obszarem zainteresowania twórców paczek w Archu. O ile zatem - co do zasady - system zbudowany z repozytoriów Archa (w tym poszczególne aplikacje) winien działać, to zasada ta nie obowiązuje już w przypadku programów budowanych z AUR. Często się zdarza, że do systemu dostarczone są np. nowe biblioteki, które nie posłużyły budowaniu paczki z AUR i po ich instalacji, taka aplikacja z AUR przestaje działać. Wówczas trzeba ją przebudować (jeśli się da) i zainstalować od nowa przebudowaną wersję. Stąd też dobrze mieć swój PKGBUILD, który temu służył.

Powyższe oczywiście nie wyczerpuje (i nie było to moim zamiarem) całości kwestii związanych z budową paczek. Polecam w tym zakresie wiki Archa, rozpoczynając od materiału o AUR. Przyda się również inna wiedza, prezentowana w ramce po prawej stronie. Mam nadzieję jednak, że prezentowany wyżej tekst przyda się szczególnie osobom, które w Archu znalazły się po raz pierwszy.
 

 
 

poniedziałek, 2 maja 2016

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=('httraqt')
license=('GPL')
install=${pkgname}.install

prepare() {
mkdir -p build
sed 's|USE_QT_VERSION 4|USE_QT_VERSION 5|g' -i httraqt/CMakeLists.txt
}

build() {
cd build
cmake ../$_pkgname \
-DUSE_QT_VERSION=5 \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE=Release
make
}

package() {

make -C build DESTDIR="$pkgdir" install
}
md5sums=('ac913f58521c7a3e302cc2ecebecd819')

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=("https://github.com/nomacs/nomacs/releases/download/$pkgver/nomacs-$pkgver-source.tar.bz2"
        "https://github.com/nomacs/nomacs-plugins/archive/master.zip"
)
md5sums=('2f453b4106c395b0c5316563e67d9255'
         'SKIP')

prepare() {
  mv nomacs-plugins-master $pkgname-$pkgver/plugins
  cd $pkgname-$pkgver
  [ -d b ] || mkdir b

}

build() {
  cd $pkgname-$pkgver/b
  cmake .. -DCMAKE_INSTALL_PREFIX=/usr
  make -j1
}

package() {
  cd $pkgname-$pkgver/b
  make DESTDIR="$pkgdir/" install
}

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')
provides=('kshutdown')
source=("http://downloads.sourceforge.net/$_pkgname/$_pkgname-source-$pkgver.zip")
sha256sums=('36533e9abd40a25d227e3a9cf1163269ac1120993c6ab50dcd45b7846b5f24f3')

build() {
cd kshutdown-3.99.1beta
./Setup-kf5.sh
}

package() {
  cd $srcdir/kshutdown-3.99.1beta/build.tmp
  make DESTDIR="$pkgdir" install
}

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-browser*' 'otter-browser-beta*' 'otter-browser-webengine-weekly' 'otter-browser-webkit-weekly')
install=otter.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('b77451f2f46c1fd21a00943fedc93bd3')

build() {
  cd ${_pkgname}-${_devver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr" \
-DENABLE_QTWEBKIT=OFF
  make
}

package() {
  cd ${_pkgname}-${_devver}
  make DESTDIR=$pkgdir install
}