czwartek, 28 grudnia 2017

Małe a cieszy: uksmstat

Kiedyś ten programik był w AUR. Obecnie go już nie ma. Jest użyteczny wyłącznie dla osób, które mają kernele z UKSM. Do takich należą np. linux-uksm czy linux-pf oraz... mój własny. Znów zatem krótko: PKGBUILD (tym razem to nie mój wynalazek, a oryginalny PKGBUILD, który niegdyś znajdował się w AUR) i wszystko jasne.

Małe a cieszy: swapusage

Postanowiłem prezentować małe, użyteczne narzędzia. Sporo takich znajdziecie w repozytoriach, czy w AUR, w tym cyklu skupię się jednak na tych, których tam nie ma i będę dawać do nich PKGBUILDy. Na pierwszy ogień - swapusage. Nazwa mówi wszystko. Programik, który sprawdzi co siedzi w swap i ile go zużywa, a nadto przekaże nam informację o numerze procesu takiej aplikacji. Proste? Banalnie. Zatem już wyłącznie PKGBUILD i możecie używać. Jeśli nie wiecie jednak co dalej z taką wiedzą robić - również proste: nie używać, chyba, że wyłącznie po to, by wiedzieć. PS: Co robić z PKGBUILDami, które tu prezentuję również już nie piszę. Pisałem wiele razy jak należy w takich przypadkach tworzyć i instalować paczkę.

czwartek, 21 grudnia 2017

Naprawiamy błąd w KDE

KDE jest jedynie przykładem. Podany poniżej sposób można dostosować do dowolnego programu. Trzeba mieć jedynie źródła i odrobinę chęci. Niemniej jednak ostrzegam: PROPONOWANE ROZWIĄZANIE JEST PRZEZNACZONE WYŁĄCZNIE DLA ŚWIADOMYCH UŻYTKOWNIKÓW. Pozostałym proponuję skorzystać z oferowanej przez nas pomocy na forum. Truizmem jest stwierdzenie, że nie istnieje oprogramowanie pozbawione wad. Zawsze znajdzie się jakiś błąd. W przypadku Archa i KDE mamy komfortową sytuację, albowiem opiekunowie paczek napiętnowanych przez Qt są po prostu bardzo dobrzy. Oczywiście zdarzają się wpadki, jednakże są one często i to na poziomie testowania (repozytoria testing i kde-unstable) wychwytywane i naprawiane. Jeśli zatem chodzi o samą jakość paczek to jest tu po prostu przednio. Niemniej jednak urodą Archa jest to, że dostarcza on zasadniczo oprogramowanie najnowsze i to w miarę możliwości takie, jakim go widzi tzw. upstream. Przyjęcie tej zasady oznacza, że mniejsze lub większe błędy zostaną dostarczone wraz z jakąś aktualizacją, nawet jeśli paczkujący są świadomi takich błędów. Ot, nie tak dawno mieliśmy do czynienia z wprowadzeniem Qt 5.10, które powodowało, że kliknięcie w tzw. widoku folderu na jakąkolwiek ikonę prawym klawiszem myszy wyświetlało dwa, zamiast jednego okna menu. Oczywiście w takim przypadku można cofnąć odpowiednie paczki do poprzedniej wersji, można też - o ile są już zrobione - spróbować nałożyć łatkę, która błąd winna usunąć. I tym ostatnim rozwiązaniem się zajmiemy. Przygotujmy zatem nasz stół pracy. Przede wszystkim źródła wiedzy. Cóż, oprócz różnych list mailingowych, kanałów IRC, czy forów internetowych, zasadniczo mamy dwa źródła w takim przypadku. Pierwszym jest strona raportowania błędów w oprogramowaniu KDE, drugim to strona, na której przedstawiane są prace nad rozwojem dystrybucji. Dodatkową jest repozytorium kodu KDE. Z pierwszego i drugiego dowiemy się, czy uciążliwy dla nas błąd został naprawiony. Z drugiego, a przede wszystkim z trzeciego ściągniemy odpowiednią łatkę, choć zdarza się, że pojawiają się one też na pierwszym. Musimy zatem ustalić błąd, ustalić łatkę, pobrać ją i nałożyć. Proste? Oczywiście, ale jak to zrobić? Oczywiście możemy poprosić opiekunów paczek w Archu o dodanie łatki. Niekiedy w istocie są one nakładane bez naszych próśb (tak było z łatką na wyżej opisany błąd). Nawet jednak, gdy poprosimy, to nie wymagajmy od nich, by nasza prośba została od razu wysłuchana. To społecznościowa dystrybucja, gdzie każdy oprócz dbania o paczki, które ma pod swoją opieką ma jeszcze tuzin innych spraw na głowie. Co najmniej. Możemy zatem również zrobić to samo, co zrobiłby opiekun, tyle, że we własnym zakresie. Tworzenie PKGBUILDów (czy ich - jak w tym przypadku zmiana) to nie żadne voodoo nie do pojęcia, żadna czarna magia. Stworzenie paczki nie spowoduje awarii elektrowni, a i w domu korki nie wyskoczą. Ręczę. Skoro będziemy zmieniać PKGBUILD to jest on nam konieczny. Najprościej posłużyć się tu asp (choć np. popularny yaourt też sobie z tym poradzi). Ostatecznie możemy ściągnąć ręcznie. Ja opiszę pierwszy sposób. Zaczynamy od aktualizacji bazy asp oraz zaimportowania na lokalny komputer interesujących nas źródeł paczek - w moim przypadku będzie to KIO - oraz do przejścia do katalogu, który zostanie utworzony:
asp update && apt export kio && cd kio
Mamy już źródła, teraz czas je zmieniać. Na podanych przeze mnie wyżej stronach źródeł odszukujemy to co nas interesuje. Powiedzmy, że chodzi taki błąd. Jak widzimy na stronie bugs.kde.org, istnieje dla niego jakieś rozwiązanie. Możemy przeglądnąć również prace nad tym błędem i ich testowanie na phabricator.kde.org. My przechodzimy jednak do repozytorium KIO (oczywiście klikając w odnośnik do commitu), która przenosi nas w świat tajemniczego kodu źródłowego. Dla nas istotna jest informacja, że łatka (patch) jest i w formie, z której będziemy chcieli skorzystać (plain) możemy ją odkryć pod... uwaga... tajemniczym odnośnikiem patch. Mamy już zatem indywidualny adres łatki, to owe https://cgit.kde.org/kio.git/patch/?id=TUTAJ_CIĄG_CYFR_I_LITER. Możemy ten adres skrócić do pierwszych ośmiu cyfr. Zidentyfikuje nam tę samą łatkę. Powracamy w tym momencie do pobranych wcześniej źródeł paczki Archa i dokonujemy edycji PKGBUILDu. Interesować nas będą wyłącznie następujące pozycje: pkgrel, sources oraz sekcja prepare (jeśli jej nie ma, to będziemy musieli stworzyć; w przypadku oprogramowania KDE najczęściej istnieje, albowiem w niej zakładany jest katalog build). Pierwszą pozycję (pkgrel) możemy jakoś zmienić, by odróżnić swoją paczkę od paczki oryginalnej. Nie jest to jednak konieczne. Pamiętajmy jednakże, że nadanie "wyższego" numeru spowoduje, że gdy znajdzie się taka paczka w repozytorium, to nie zostanie ta paczka zaktualizowana, nadanie jakiegokolwiek numeru "połówkowego", czy niezmienienie go w ogóle spowoduje, że nowa wersja tej paczki zostanie wgrana w miejsce przez nas stworzonej. Tak, źle i tak nie dobrze? Nie! Ingerujecie w system, a zatem od tej chwili odpowiedzialność za niego przechodzi na Was. Musicie o niego zadbać, przy aktualizacji sprawdzać co, jak i dlaczego ulega zmianie i w zależności od tej wiedzy dostosować swoje działania. Druga pozycja (sources) jest ważniejsza. Tutaj bowiem poinformujemy, że do dotychczasowych źródeł chcemy coś dodać. Posiłkując się przykładem KIO, obecne źródła aktualnej paczki 5.41.0-1 wyglądają tak:
source=("https://download.kde.org/stable/frameworks/${pkgver%.*}/${pkgname}-${pkgver}.tar.xz"{,.sig})
My chcemy do niego dodać patch na błąd 386364. Musimy zatem w tych źródłach poinformować makepkg, że oprócz nich ściągnąć ma jeszcze patch, który zidentyfikowaliśmy wcześniej. Dopisujemy zatem do źródeł https://commits.kde.org/kio/ca2364d9. Osobiście polecam nazwać tak ściągnięty patch w jakikolwiek sposób, który byłby dla nas czytelny, np. kdebug-386364.patch. Źródła patcha przyjmą zatem postać:
kdebug-386364.patch::https://commits.kde.org/kio/ca2364d9
Cała sekcja sources wyglądać winna w tym momencie tak:
source=("https://download.kde.org/stable/frameworks/${pkgver%.*}/${pkgname}-${pkgver}.tar.xz"{,.sig} "kdebug-386364.patch::https://commits.kde.org/kio/ca2364d9")
Jak na razie poinformowaliśmy makepkg, by jedynie dodatkowe źródła zostały ściągnięte. Musimy jeszcze poinformować go, by przed rozpoczęciem budowy paczki nałożył patch. Przechodzimy do sekcji prepare i dodajemy w niej
patch -p1 -i ../kdebug-386364.patch
Wcześniej musimy jednak poinformować skąd ów patch ma być nałożony. W tej samej sekcji musimy zatem zmienić katalog:
cd $pkgname-$pkgver
Cała sekcja od tej chwili wyglądać winna tak:
prepare() { mkdir -p build cd $pkgname-$pkgver patch -p1 -i ../kdebug-386264.patch patch -p1 -i ../kdebug-386364.patch }
Zamykamy edycję PKGBUILDu zapisując go i wydajemy jeszcze polecenie do aktualizacji sum kontrolnych:
updpkgsums
Teraz już możemy zbudować paczkę. Jeśli wierzymy w swoje umiejętności możemy również ją od razu zainstalować, odinstalować wszelkie zależności służące do budowy paczki oraz skasować katalogi, w których nastąpiło budowanie i tworzenie paczki. Jednym poleceniem:
makepkg -sirc
Polecam jednakże weryfikację zbudowanej paczki (a wcześniej PKGBUILDu) poleceniem namcap. Proste? Powiedzmy, że tak. Teraz jednak przyszedł czas na kubeł zimnej wody. Nikt nikomu nie gwarantuje, że taka łatka w istocie poprawi działanie. Może poprawić jeden element, może popsuć inny. Wszak to jest jak zespół naczyń połączonych. Patchowanie wymaga pewnej wiedzy i pewnej staranności od tego, kto to robi. Przede wszystkim jednak od tego momentu - powtórzę - dokonaliście ingerencji w system, którego używacie. Musicie nad nim zatem przejąć pełniejszą kontrolę oraz sami o niego dbać. W przypadku zgłaszania jakichkolwiek błędów w KDE, czy też szukając pomocy na forach musicie poinformować o tym, że Wasz system w jakiś sposób odbiega od oczekiwanego oryginału.

piątek, 15 grudnia 2017

Zrozumieć niezrozumiałe: instalacja programów w wersjach rozwojowych (git)

W AUR sporo jest skryptów umożliwiających budowę paczek w wersjach rozwojowych. Zwykle noszą one dodatkowe oznaczenia dev/devel, git, bzr, svn, cvs, hg itp. Odróżnijmy wpierw paczki *-dev/devel. Z takim rozszerzeniem winny pojawiać się takie wersje rozwojowe programów, które są w jakiś sposób "ustabilizowane" przez twórców. Innymi słowy - "numerowane" wersje rozwojowe. Przykładem takim niech będzie GIMP, który stosuje bardzo stary system oznaczania swoich wersji, gdzie pierwsza cyfra oznacza wersję, druga cyfra wskazuje na wydanie, a trzecia wskazuje na wersję poprawkową. Dodatkowo jeszcze wydania uważane za deweloperów za stabilne oznaczane są kolejną parzystą liczbą, zaś wydania rozwojowe, które prowadzą do następnych wydań stabilnych oznaczane są liczbą nieparzystą. Stąd GIMP 2.8.22, to ostatnia wersja stabilna (8) drugiego (2) wydania GIMPa, będąca dwudziestą drugą wersją poprawkową dla wydania 2.8. Niedawno ogłoszona wersja 2.9.8 jest rozwojową (9) wersją, która po zakończeniu nad nią prac ukaże się w przyszłości jako wersja 2.10.0. W AUR temu wydaniu odpowiada gimp-devel. Obecnie to 2.9.8, ale w tym roku mieliśmy już i 2.9.4 i 2.9.6. Jeśli się pokaże 2.9.10, to i taką tam wersję otrzymamy. Do czasu ogłoszenia nowego "ustabilizowanego" wydania wersji rozwojowej, ostatnią taką wersją będzie 2.9.8. Opiekun takiej paczki w AUR przez cały okres funkcjonowania takiej wersji winien dbać o spełnienie jej zależności. Jeśli odpowiednich paczek (w odpowiednich wersjach) nie ma w repozytoriach, to winien tak skonstruować PKGBUILD by umożliwił zbudowanie programu, także zapewniając również w AUR odpowiednie paczki stanowiące zależności. Zasadniczo też, w przypadku wydania nowej wersji rozwojowej powinien on zapewnić aktualizację PKGBUILDu do tej wersji. Jeśli tego nie zrobi to możemy ją oflagować jako nieaktualną. Inaczej przedstawia się sprawa w przypadku pozostałych wersji rozwojowych (dla uproszczenia będę je zwał "paczkami GIT"). Paczki tego typu nie mają wersji w tym rozumieniu, które wskazałem wyżej. One podlegają mniej lub bardziej intensywnemu, jednakże ciągłemu rozwojowi. Oczywiście tak program w AUR, jak i otrzymana paczka będzie mieć jakiś numer. Niemniej jednak należy sobie uzmysłowić kilka rzeczy. W dalszej części, niech za przykład takiej paczki posłuży gimp-git. Prawidłowo skonstruowana paczka GIT winna automatycznie generować numer wersji podcza"as swej budowy. Dlaczego? Otóż w zasadzie wszystkie paczki z repozytoriów kontroli wersji są budowane w taki sposób, że w pierwszej kolejności dokonywane jest klonowanie repozytorium, czyli pobieranie na komputer lokalny aktualnego w tym momencie stanu ("migawki") repozytorium, gdzie składowany jest kod tej aplikacji. Zwróćmy uwagę - gimp-git nosi w AUR numer wersji 1:2.9.4.1760.g2a7a53b384-1 (pomińmy pierwszą i ostatnią jedynkę, bo nie mają one tu znaczenia). Ta wersja sugerowałaby, że gimp-git jest zasadniczo w wersji 2.9.4, a zatem jest "starszy" od gimp-devel (2.9.8). Nic bardziej mylącego. Otóż wersja jaką widzimy w AUR to jest wersja, która odpowiada wersji, jaka posłużyła opiekunowi tej paczki do stworzenia PKGBUILDu w chwili, gdy zbudował sobie lokalnie taką paczkę. Dzieje się tak dlatego, że pole pkgver w PKGBUILD (linia 7) jest automatycznie generowane na podstawie sklonowanego repozytorium z GIT w dacie budowy paczki. Za wygenerowanie tej wersji odpowiada sekcja pkgver (linie 35-38, a dokładnie w tym przypadku linia 37). Kiedy w sklonowanym repozytorium GIT wydamy to samo polecenie, to otrzymamy również jakiś nr wersji (np. gdybym budował gimp-git podczas pisania tego tekstu, to otrzymałbym program ten w "wersji" 2.9.8.11.g6fee1a413f). Zasadniczo nie istnieje żadna potrzeba "podbijania" numeru wersji paczek GIT w AUR wówczas, gdy pojawia się w kodzie źródłowym jakaś zmiana, która powodowałaby, że owa "wersja" będzie się różnić od wersji, jaka jest widoczna w AUR. PKGBUILD winien być natomiast przebudowany gdy ze względu np. na kompilację wymaga on innych zależności. Może być również podbita jego wersja wówczas, gdy program wymaga przebudowania (np. dlatego, że nowe wersje zależności, jakie pojawiły się w systemie skutkować winny przebudowaniem w ich oparciu również takiego programu GIT i to nawet wówczas, gdy nie uzyskamy w ten sposób nowej "wersji" tego programu). Dobrze, ale co to dla Ciebie oznacza Szanowny Czytelniku? W sumie - proste: w przypadku paczek GIT wyłączny ciężar dbania o ich aktualność i działanie spoczywa na Tobie. Niestety na tym nie koniec. Nie koniec na tym, by dbać o aktualność i działanie samej paczki. Musimy również - niekiedy zadbać o aktualność zależności. Te ostatnie mogą występować jako pakiety znajdujące się w repozytorium, ale mogą również występować jako paczki GIT. Weźmy ów przykład gimp-git. Na podstawie PKGBUILDu, który znajduje się w AUR dzisiaj nie zbudujemy GIMPa. Wersja 2.9.8 wymaga jako zależności m.in. gegl w wersji nie niższej niż 0.3.24 oraz babl w wersji nie niższej niż 0.1.38. W repozytorium Archa (nawet uwzględniając testing) mamy dzisiaj gegl 0.3.20 i babl 0.1.30. Jednocześnie PKGBUILD gimp-git został tak napisany, że z jednej strony jako zależności wymaga babl (czyli paczkę z repozytorium) wskazując na minimalną jej wersję 0.1.27, z drugiej strony wymagając gegl-git w wersji nie niższej niż 0.3.15. Wiemy już, że w takich wersjach albo nie buduje się GIMP 2.9.8. Jednocześnie przy sprawdzaniu zależności, w pierwszym przypadku (babl) stwierdzi, że wymagana wersja jest w systemie (lub w repozytorium) zaś w drugim przypadku (gegl) albo stwierdzi, że jej nie ma i wówczas ją trzeba zbudować z AUR, a w takim przypadku otrzymamy wersję wymaganą przez GIMP 2.9.8, choć niewymaganą przez PKGBUILD gimp-git (bo będzie to wersja 0.3.26.1). Gimp-git zbuduje się jednak, gdy będziemy mieć w systemie zainstalowaną babl-git. W przypadku obu tych zależności w wersjach GIT z jednym wszak zastrzeżeniem. Babl-git zbudowaliśmy przynajmniej w chwili gdy pojawiła się wersja 0.1.30, a w przypadku gegl-git, gdy pojawiła się wersja 0.3.20. Może się jednak zdarzyć, że mamy owe paczki zbudowane pomiędzy wersją 0.1.27 a 0.1.30 (babl) lub 0.3.15 a 0.3.20 (gegl) i w takim przypadku program się nie zbuduje, choć teoretycznie - zgodnie z PKGBUILDem - powinien. Fakt dzisiaj ów PKGBUILD gimp-git jest do zmiany (w ogóle jest do zmiany od samego początku), jednakże tak, czy inaczej wskazuje to na możliwe problemy, jakie użytkownik paczki GIT może napotkać. Pamiętać przy tym również należy, że budując paczki w wersjach innych niż te, które są w repozytorium i zastępując te wersje, wersjami zbudowanymi (obojętnie w jaki sposób - mogą to być jakieś paczki GIT, mogą to być paczki, które zaktualizowaliśmy do innej, stabilnej wersji, ale nowszej niż jest w repozytorium) może okazać się, że wprowadzimy do systemu paczki "zbyt nowe". Wprawdzie właśnie budowana paczka będzie działać, ale inna paczka, której zależnościami były te same paczki, które są zależnościami właśnie zbudowanej paczki będzie wymagać przebudowy (w najlepszym razie), albo zbudowania jej również w wersji GIT, albo z jakimiś patchami itd. itp. W ostateczności po prostu w ogóle działać nie będzie. Pamiętajmy jeszcze, że określona wersja paczki GIT będzie aktualna praktycznie stale, nawet jeśli nowsza, stabilna jej wersja będzie dostępna już w repozytorium. Podsumowując krótko. Paczki GIT to zabawa dla bardzo zaawansowanych użytkowników, którzy są bardzo świadomi swego systemu. Wiedzą o nim wszystko co trzeba wiedzieć by... tak na prawdę, by samemu utrzymywać dystrybucję. Wiesz co i jak oraz kiedy należy zbudować, przebudować? Jakie konsekwencje powoduje wprowadzenie nowych wersji paczek do systemu? Które z programów opartych o paczkę w wersji nowszej w sytemie należy przebudować? Jak ewentualnie nakładać patche umożliwiające przebudowanie paczek w oparciu o nowsze zależności? Kiedy przebudować paczki GIT i czy w ogóle o tym będziecie pamiętać? A to dopiero wierzchołek góry lodowej. Innymi słowy - nie wiesz, nie jesteś świadomy konsekwencji używania paczek GIT to ich po prostu nie używaj. Jeśli z jakiegoś powodu musisz, to sensownie jest rozglądnąć się za jakimś appimage czy flatpak, bo tu mogą się one w istocie lepiej sprawdzić. Nawet jeśli nie będzie dostępnego flatpak, czy appimage w wersji, którą chcecie, to na podstawie dostępnych szkieletów zbudować taką paczkę. Paczki GIT pozostawcie osobom, które doprawdy wiedzą co robią. Zwłaszcza, że ewentualna pomoc dla osób, które ich w systemie używają jest bardzo trudna. Nikt nie tylko nie spodziewa się hiszpańskiej inkwizycji, ale nikt nie spodziewa się, że ktoś przedstawia swój system jako np. Arch, ale de facto jest on Archem wyłącznie w jakimś stopniu, czyli... nim po prostu nie jest.

piątek, 8 grudnia 2017

Zbuduj sobie LibreOffice AppImage

Oczywiście w repozytorium Archa są nawet dwie wersje LibreOffice (still i fresh). Są jeszcze różne wersje w AUR. Z różnych względów jednakże możemy chcieć mieć inną wersję niż ta, którą zainstalować możemy z repozytorium. Także taką, która będzie z nią koegzystować i nie naruszy nam naszego "produkcyjnego" pakietu. Oczywiście możliwą jest taka instalacja w przypadku wersji z repozytorium oraz niektórych z AUR. Możliwym jest też odpowiednie dostosowanie PKGBUILDów do swoich potrzeb. Proponuję jednakże inne, szybkie rozwiązanie, które umożliwi Wam na przykład testowanie przyszłych wersji, ewentualne włączenie się w rozwój tego pakietu czy też do jakichkolwiek innych celów będziecie chcieć to wykorzystać. Owe rozwiązanie to AppImage. Przede wszystkim muszę zaznaczyć, że w ogóle nic nie musicie robić. AppImage kilku wersji LO jest oferowane przez LibreOffice AppImage Package - wystarczy ściągnąć odpowiedni dla siebie plik, nadać mu uprawnienia wykonywalne i ma działać. Niemniej jednak są osoby, które wolą coś zrobić samemu, albowiem mogą wówczas w większym stopniu zindywidualizować swój system. Dla nich poniższa instrukcja, która zresztą wykorzystuje ten sam skrypt, który wykorzystany jest przez twórców LibreOffice AppImage. Zatem do dzieła. Wpierw jednak muszę zaznaczyć, że obecny skrypt wykorzystuje dpkg, które musimy zainstalować. Niemniej jednak, by istnienie dpkg w Archu nie podkusiło kogoś do instalacji za jego pomocą paczek deb w przyszłości postaram się przerobić skrypt, by posługiwał się bsdtar, który doskonale radzi sobie również z paczkami w formacie deb. Muszę jeszcze opisać Wam co ów tajemniczy skrypt robi. Otóż zasadniczą jego funkcją jest przekonwertowanie istniejącego pakietu LibreOffice w formacie deb do jednego pliku AppImage. Można też skryptowi przekazać pewne zmienne, które umożliwią większą kontrolę nad otrzymywaną paczką. O tym jednak później. Zaczynamy od instalacji appimage-git oraz dpkg - oba znajdują się w AUR i nie będę opisywał jak je instalować; to jest już wszędzie, a przede wszystkim na wiki Archa. W następnej kolejności ściągamy skrypt make_libreoffice_appimage i nadajemy mu uprawnienia do wykonywania.
wget - c https://raw.githubusercontent.com/antoniofaccioli/libreoffice-appimage/master/make_libreoffice_appimage && chmod +x make_libreoffice_appimage
Mamy już przygotowane w zasadzie wszystko, co niezbędne jest to budowy LibreOffice w formacie AppImage. Jak wspomniałem wyżej - skryptowi można przekazać określone polecenia, które służyć będą do budowy paczki. Po pierwsze możemy przekazać mu z jakiej gałęzi chcemy zbudować LO. Do wyboru mamy still, fresh (obie odpowiadają wersjom, które są w repozytoriach Archa) oraz daily (czyli codzienna migawka wersji rozwojowej, obecnie jest to linia 6.x). Możemy również wskazać konkretną wersję pakietu, w takim nazewnictwie jak oferuje LibreOffice. Po drugie - obecnie nie mamy wyboru - wskazujemy tylko 64 bitową wersję paczki, czyli x86-64. Obecnie nie zbudujemy jeszcze wersji 32-bitowej, ale w przypadku Archa wersja taka i tak byłaby bez sensu. Po trzecie - przekazujemy informację o paczkach lokalizacyjnych, które mają zostać wbudowane. Do wyboru jest standard (zbuduje z następującymi paczkami lokalizacyjnymi: en-GB, it, ar, zh-CN, zh-TW, fr, de, ja, ko, pt, pt-BR, es, ru), full (zbuduje ze wszystkimi dostępnymi, a wybierać język będziemy mogli później), opcja zbudowania z konkretną lokalizacją (w przypadku języka polskiego będzie to pl) oraz "N", która zbuduje wyłącznie podstawową paczkę z amerykańskim angielskim. Jeśli dana paczka lokalizacyjna nie zostanie odnaleziona, pakiet zbuduje się także wyłącznie w tej ostatniej opcji. Po czwarte możemy zdecydować, czy paczka zawierać ma pliki pomocy dostępne bez połączenia z siecią. Po piąte możemy zdecydować, czy paczka ma mieć możliwość aktualizacji. W tym przypadku musimy dodatkowo zainstalować zsync-curl z AUR (wersja dostępna to git). Po szóste możemy swoją paczkę podpisać sygnaturą GPG. Trzy ostatnie opcje włączamy poprzez Y i wyłączamy poprzez N. Przykładowa linia poleceń dla przetestowania LibreOffice w wersji rozwojowej ("dziennej") ze spolszczeniem (którego obecnie nie ma, być może się pojawi - wówczas zbuduje wersję spolszczoną), bez możliwości aktualizacji oraz bez plików pomocy i bez podpisu to:
./make_libreoffice_appimage daily x86-64 pl N N N
I możemy testować LibreOffice do woli bez ingerowania w swój system. Uwaga - paczka pojawi się w podkatalogu o nazwie out w katalogu, gdzie wydaliśmy polecenie pakowania. W katalogu tym również pojawi się podkatalog (w tym przypadku LibreOfficeDev) zawierający wszystko co było niezbędne do budowania. Ten katalog możemy spokojnie usunąć.

czwartek, 7 grudnia 2017

Przywracamy działanie gimagereader-qt5 na enchant 2

Niezbyt wiele mamy aplikacji stanowiących GUI dla silników OCR w linuksie, zatem każdą z nich należy pielęgnować. W świecie oprogramowania opartego o Qt 5, spośród stale rozwijanych w zasadzie istnieje jedynie gImageReader. W AUR znajdziemy dwa PKGBUILDy: gimagereader oparty jeszcze o Qt 4 oraz gimagereader-qt5 oparty o Qt 5. Pierwszym nie będę się zajmować. Najwyższy czas, by dawno już porzucone Qt 4 odeszło w mroki dziejów. Niestety po psikusie, jakim było wprowadzenie enchant w wersji 2 do repozytorium (extra), aplikacja ta przestaje działać. Pominąwszy pewne perturbacje, jakie były w międzyczasie, dzisiaj już udaje się przywrócić możliwość działania gImageReaderowi. Niestety nie podam Wam co i jak należy zmienić w istniejących PKGBUILDach w AUR. Jeśli chcecie używać, to będziecie się musieli zdać na moje rozwiązanie. Zacznijmy od tego, że gImageReader wymaga do swojego działania i budowy qtspell, ten natomiast wymaga enchant. Obecna sytuacja w repozytoriach i w AUR jest następująca: mamy enchant w wersji 2.1.2, która jest oznaczona jako nieaktualna, oraz wersjonowane qtspell i gimagereader-qt5. Niestety pomimo doprowadzenia przez twórcę qtspell możliwości jego budowy na enchant 2, udaje się je zbudować wyłącznie na aktualnej wersji enchant, której nie ma w repozytorium. Dlatego też musimy dokonać zbudowania enchant w najnowszej dostępnej wersji 2.1.3, na nim dopiero zbudować qtspell. Nie udało mi się jednak tej sztuczki dokonać przez nałożenie patcha na wersję, która jest dostępna w AUR. Koniecznym stało się zbudowanie nowej paczki qtspell-git. Dopiero na niej można zbudować gImageReader-qt5. Przyznam, że nie próbowałem budować wersji dostępnej w AUR. Od pewnego czasu używam wersji budowanej z git albowiem zmiany jakie się tam dokonują w stosunku do ostatniego wydania są poważne. Dlatego też taką wersję proponuję. Krótko jedynie przypomnę: ściągamy PKGBUILD, umieszczamy w jakimś katalogu i za pomocą makepkg budujemy oraz instalujemy paczkę. Kolejność tutaj musi być następująca: enchant, qtspell-git, gimagereader-qt5-git. Dodatkowo - przynajmniej u mnie tak wystąpiło - musiałem zrestartować komputer po zainstalowaniu enchant (choć doprawdy nie wiem dlaczego okazało się to konieczne). Teraz już zatem same PKGBUILDy dla: enchant 2.1.3, qtspell-git, gimagereader-qt5-git. W razie problemów - wiecie gdzie mnie szukać :)

czwartek, 30 listopada 2017

Antergos, Gnome 3 i Wayland

I jakoś im nie po drodze. Gnome 3 od dłuższego już czasu, jako domyślny rodzaj sesji wybiera tę w Waylandzie. W standardowej instalacji Antergosa nie tylko, że zostanie wybrana sesja w Xach, to w ogóle nie będziemy mieć możliwości uruchomienia sesji w Waylandzie. Nie oznacza to, że Gnome 3 jest tam jakiś "inny" niż ten, który dostępny jest w innych dystrybucjach, a w szczególności w Archu. Dodatkowo są to praktycznie te same paczki, co w Archu. Dlaczego zatem Gnome 3 w Antergosie nie można uruchomić w Waylandzie? Odpowiedź jest bardzo prosta. Wszystkiemu winien tzw. Display Manager, którym we wszystkich środowiskach, z którymi można postawić Antergosa jest lightdm z autorskim (bodaj) greeterem. To właśnie LightDM nie wspiera (jeszcze) sesji w Waylandzie. Dla twórców Antergosa sesja w Waylandzie nie jest najważniejsza, a twierdzą że LightDM sprawuje im się znakomicie, nadto umożliwiając zachowanie tego samego wystroju dla wszystkich środowisk "wspieranych" przez Antergosa. Nie oznacza to, że nie jest możliwym uruchomienie Gnome 3 także w Antergosie w sesji Waylanda. Pierwsze co musimy zrobić to zainstalować GDM (powinien zresztą w systemie być):
# pacman -Syu gdm
Następne czynności warto wykonywać już w trybie konsolowym, po "zabiciu" sesji Gnome 3. Ja zwykle robię coś takiego w ten sposób, że wylogowuję się ze środowiska, przechodzę do innej konsoli (np. Ctrl+Alt+F2), a następnie wstrzymuję DM (w przypadku lightdm):
# systemctl stop lightdm
Przez chwilę zostaniemy "przerzuceni" do konsoli, w której uruchomiony był DM, zatem powracamy do poprzedniej (Alt+F2) i wydajemy polecenia:
# systemctl disable lightdm && systemctl enable gdm && systemctl start gdm
Pierwsze z poleceń informuje systemd, by nie używał lightdm, drugie, by podnosił gdm przy każdym starcie systemu, trzecie startuje sesję gdm. Od tej chwili powinniście mieć możliwość pracy w Gnome 3 w Antergosie w sesji Waylanda. Pozostanie pewnie kwestia dopracowania sobie odpowiedniego wystroju itp. Pamiętajcie jednak, że Wayland nie jest dobrym wyborem dla wszystkich. O ile większych problemów nie zaznacie w przypadku korzystania ze wszystkich sterowników otwartych oraz - być może również amdgpu-pro (ale to nie jest sterownik, który wspiera Archa), to w przypadku sterowników własnościowych NVidia możecie doznać jakichś problemów i to pomimo inkorporowania przez Gnome patchy NVidii. Dotyczy to zwłaszcza aplikacji, które nie wspierają natywnie Waylanda.

wtorek, 28 listopada 2017

Dlaczego dystrybucje wydawnicze i KDE to nieporozumienie

Tytuł to pewien skrót, albowiem poprawny winien brzmieć: dlaczego dystrybucje o wydawniczym modelu niedostosowanym do wydań oprogramowania KDE oraz bez repozytoriów typu backport, które są do owych wydań dostosowane, to nieporozumienie. Jak widzicie - nie tylko się nie zmieści, ale i nikt go nie przeczyta. Najpierw w skrócie o tym jak wyglądają tzw. wydawniczy model dystrybucji linuksa. Otóż po fazie testów jest publikowana wersja. Najczęściej faza testów trwa jakiś czas i wówczas - również najczęściej - całe oprogramowanie, jakie znajduje się w repozytorium zostaje zamrożone w swoich wersjach. W chwili wydania mamy zatem ściśle określone elementy w takiej dystrybucji, które swoją aktualność miały w chwili zamrożenia wydania. Oczywiście jeśli ten element nie uległ jakiejś zmianie, to w chwili wydania jest również aktualny. Jeśli jednak wyszła nowa wersja takiego oprogramowania, to najczęściej nie zostanie ona uwzględniona w wydaniu finalnym. Dodatkowo, najpopularniejsza spośród dystrybucji wydawniczych, jaką jest rodzina Ubuntu ma ściśle określone daty (a w zasadzie miesiące) wydań. Pojawia się zawsze w kwietniu i październiku. Oprogramowanie tam uwzględnione - często - pochodzi sprzed bodaj trzech miesięcy przed pojawieniem się takiego wydania i stanowi paczki źródłowe przejęte z Debian Sid. Niektóre dystrybucje wydawnicze udostępniają repozytoria z nowszymi wersjami oprogramowania, tzw. backports. Te repozytoria zawierają jednak zwykle wyłącznie część paczek, a nie wszystkie jakie są w niej zawarte. Jednocześnie przez cały okres życia takiego wydania, dana dystrybucja chwali się, że "wspiera" to wydanie. Pół biedy, gdy twórcy takiej dystrybucji wyraźnie stwierdzają czego owe wsparcie dotyczy. Dobrym przykładem może tu być Debian, który wyraźnie stwierdza, że w okresie funkcjonowania Debian Stable zapewnia jedynie poprawki bezpieczeństwa, a wersje oprogramowania nie zostają zmienione. Dużo częściej jednak twórcy dystrybucji posługują się wyłącznie nośnym PR-owym stwierdzeniem "zapewniamy wsparcie" i na tym poprzestają. Mało kto już doczyta się, że np. zauważone błędy należy zgłaszać w ten sposób, że jeśli dotyczą one paczkowania, to winny być one zgłoszone opiekunom tych paczek, jeśli natomiast błąd dotyczy samego oprogramowania, to winien być zgłoszony jego twórcom. Ogólnie mówiąc - jeśli znajdziemy błąd i np. po przeanalizowaniu informacji o tym jak dany program winien być skompilowany, zauważymy, że brakuje jakiejś zależności, to jest to błąd opiekunów paczki (to jedynie przykład). Jeśli jednak wszystko wskazuje na to, że paczka jest poprawnie zbudowana, to najczęściej błąd został popełniony przez twórców danej aplikacji, czy biblioteki. Jednocześnie musimy sobie zdać sprawę z tego, że praktycznie nie istnieje dystrybucja, która przejmowałaby kod źródłowy określonej aplikacji i zapewniała mu opiekę przez cały okres trwania danego wydania. Owe poprawki bezpieczeństwa najczęściej są zapewniane w ten sposób, że na istniejący kod nakłada się patch, który często (choć nie tylko) pochodzi od twórców aplikacji, bądź po prostu został zaimplementowany do rozwijanego kodu. Przejdźmy teraz do modelu wydawniczego oprogramowania skupionego pod szyldem KDE. Dla jasności, będę musiał coś zagmatwać. Otóż musimy pamiętać o tym, że oprogramowanie to nie jest samodzielne w tym sensie, że niemal zawsze wymaga jakiegoś elementu pochodzącego z frameworka Qt, który - choć z dużym udziałem programistów KDE - jest jednakże oddzielnie rozwijany. Na oprogramowanie KDE składają się zatem: - framework Qt 5, - framework KDE Framework 5, - środowisko graficzne Plasma 5, - aplikacje dostarczane w ramach KDE Applications, - pozostałe aplikacje rozwijane pod szyldem KDE (np. Caligra, Krita i wiele innych). Framework Qt 5 Biblioteki Qt nie istnieje jakiś z góry zadany standard wydawniczy. Od wydania 5.6 mamy jednak zawsze dwie linie wydawnicze: "zwykłą" (bieżącą, aktualną) oraz LTS. Owe "bieżące" zwykle mają około roczny okres wsparcia, wersje LTS - trzyletni. Nigdy nie jest z góry wiadome, która wersja uzyska status LTS (do tej pory mieliśmy dwa takie przypadki, choć wcześniejsze wydania też były wspierane dłużej niż przez rok). Okres wsparcia poszczególnych wydań "bieżących" oraz LTS może (i tak jest) częściowo zachodzić na siebie. Obecnie zatem mamy dwa wydania LTS: 5.6, którego okres wsparcia ukończy się w marcu 2019 oraz 5.9 ze wsparciem do maja 2020 r. Spośród dwu wydań, jakie były pomiędzy, Qt 5.7 nie ma już wsparcia, a wsparcie Qt 5.8 skończy się w styczniu 2018. Co ciekawe, wsparcie dla Qt 5.5 skończy się nieco później, bo w marcu przyszłego roku. Framework KF5 To jakby pierwsza "warstwa", która budowana jest na Qt 5 i rozszerza jego funkcje umożliwiając pracę środowiskom graficznym (głównie Plasma 5, jednakże co raz częściej inne środowiska budowane na Qt 5 sięgają po KF5) oraz aplikacjom KDE. Tutaj przyjęty model wydawniczy jest prosty. W pewnym uproszczeniu można powiedzieć, że istnieje jedno wydanie KF5. Pierwsze, pochodzące z lipca 2014 r. Każde następne wydanie jest wersją poprawkową, choć nie istnieje żadna reguła, która uniemożliwia wprowadzanie zmian w zakresie funkcjonalności KF5, czy też uniemożliwiająca "dodanie" jakiegoś frameworku do obecnie rozwijanych (tak było np. z Baloo, które z aplikacji stało się frameworkiem). Okres funkcjonowania danego wydania KF5 jest bardzo krótki i wynosi około miesiąca (nowe wydanie pojawia się obecnie w drugą sobotę każdego miesiąca). Niezmiernie rzadko zdarza się, by pomiędzy wydaniami pojawiła się jakaś poprawka (o ile pamiętam, a używam KF5 bodaj od wersji 5.0, albo 5.1, to sytuacja taka zaszła dwa razy wobec dwu jego elementów). W zasadzie nikt nigdy nie stwierdził oficjalnie, że któraś wersja KF5 jest wersją LTS, choć mówiło się tak przy okazji dwu wydań. Trudno jednak uzyskać potwierdzenie takiej informacji na stronach KDE. Plasma 5 Obecnie wykrystalizował się następujący model wydawniczy: - wydania LTS, - wydania bieżące. Podobnie jak w przypadku Qt 5 LTS, tak i w przypadku Plasma 5 nie jest z góry wiadome, które wydanie stanie się LTS, choć z odpowiednim wyprzedzeniem informacja taka jest podawana. Jak do tej pory zawsze pojawienie się wydania LTS Plasma 5 było związane z pojawieniem się Qt 5 LTS. Obecnie istnieje jedno wydanie Plasma 5 LTS i jest to wersja 5.8, której ostatnie wydanie poprawkowe będzie miało miejsce na początku kwietnia 2018. W tym czasie, od końca stycznia 2018 będzie już dostępne nowe wydanie Plasma 5 LTS o numerze 5.12, które uzyskało wsparcie do (przynajmniej tak winno być) września 2019 r. Oprócz wersji LTS istnieją jeszcze wydania "bieżące", które obecnie pojawiają się cztery razy do roku i mają wsparcie przez trzy miesiące (tj. w okresie trzech miesięcy od daty wydania otrzymują pięć poprawek). Terminy ukazywania się poprawek obu rodzajów wydań są ściśle określone i wyznacza je tzw. ciąg Fibonacciego. KDE Applications Obecnie od dłuższego już czasu zestaw aplikacji składający się na KDE Applications pojawia się trzy razy do roku, w ściśle określonych miesiącach: kwietniu, sierpniu oraz grudniu. Wsparcie ich oferowane jest tylko w ramach danego wydania i otrzymują one zawsze trzy wersje poprawkowe. Pozostałe aplikacje rozwijane w ramach KDE Te aplikacje nie mają żadnych reguł odnośnie przyjętego modelu wydawniczego. Mogą istnieć takie, w których przyjęty został jakiś model wydawniczy, mogą być zupełnie swobodnie rozwijane, a nowe wersje ukazują się wówczs, gdy tak zdecydują twórcy tego oprogramowania, zaś wersje poprawkowe - gdy istnieje taka potrzeba. Co oznacza wsparcie i wersje poprawkowe Poszczególne wydania wszystkich elementów składających się na oprogramowanie rozwijane w ramach KDE cechuje dwojaka natura. Otóż nadanie danemu elementowi jakiegoś numeru wersji oznacza zastabilizowanie jego funkcjonalności. Przez okres jego wsparcia nie pojawi się tu żadna nowa funkcja (wyjątek to Plasma 5.8 w zakresie wsparcia Waylanda). Nowe funkcje mogą, ale nie muszą zawitać w nowym wydaniu. W przypadku wszystkich innych z wyżej wymienionych grup, z wyjątkiem aplikacji, które nie składają się na KDE Applications, do nowego wydania mogą trafić jakieś nowe elementy (nowe "aplikacje"), ale mogą z niego zostać usunięte. Np. do Plasma 5.11 trafiło Plasma Vault, ale z KDE Applications 15.12 wypadną wszystkie nieprzeportowane do KF5/Qt5 a nadto Blogilo. W okresie swego "życia", wszystkie elementy uzyskują "wsparcie", które ogranicza się do wprowadzania poprawek dostrzeżonych błędów oraz w zakresie tłumaczeń. Należy zauważyć, że te błędy, których nie udało się naprawić w ramach danego wydania, w nowym wydaniu nie zostają "porzucone". Ich naprawą zajmą się nowe wydania. Dlatego można powiedzieć, że każde "wyższe" wydanie danego oprogramowania KDE jest wydaniem poprawkowym dla poprzedniego. Plasma 5.11 przyniosła nowy składnik (Plasma Vault), przyniosła zmiany w zakresie funkcjonalności (Ustawienia systemowe), ale również i można powiedzieć przede wszystkim, stanowiła wersję poprawkową dla Plasma 5.11. Podobnie dzieje się w przypadku aplikacji składających się na KDE Applications, a nawet w przypadku owych "pozostałych" aplikacji, zwłaszcza tych, które zostały już przeportowane do KF5. Zależności Bez piekła tym razem. Każdy składnik oprogramowania rozwijany w ramach KDE ma zwykle ustawioną minimalną wersję oprogramowania/bibliotek/frameworku, od którego zależy. Plasma 5.12 nie zbudujemy na KF5 w wersji niższej niż 5.39. KF5.39 nie zbudujemy na Qt wcześniejszej niż 5.9 itp. itd. Również poszczególne elementy w ramach KF5 są zależne od siebie, albowiem możliwość ich budowania jest uzależniona od tzw. Tier, w których są zgrupowane. Te z pierwszej grupy wymagają określonego extra-cmake-modules oraz określonej wersji Qt 5, te z Tier 2, wymagają określonej wersji z Tier 1, na której są budowane. Podobnie z Tier 3. Innymi słowy tworzy się pewna "piramida" zależności. Faktem jest natomiast, że np. nowa wersja środowiska nie musi wymagać najnowszej wersji KF5. Może się ją dać zbudować na wcześniejszej wersji. Nowa wersja a dostrzeżone błędy Jak widać z tego co wyżej, nowe wersje oprogramowania z KDE są jednocześnie wersjami poprawkowymi poprzednich. Te poprzednie ukończyły już okres swego wsparcia. Ogólnie sprowadza się to do stwierdzenia, że po okresie wsparcia nie możemy już liczyć na "naprawienie" błędu w ramach niewspieranej już wersji. Obecnie też - i słuszcznie - zgłaszając taki błąd w niewspieranej już wersji, po prostu zostanie się pouczonym o tym, że wyszło nowe wydanie i by sprawdzić, czy również błąd występuje. Dlaczego nie zrobi tego z reguły sam opiekun? Bowiem on nie ma tego samego systemu/środowiska/komputera, co ten, który błąd zgłasza. Ponownie wśród dystrybucji wydawniczych Z tego co napisałem wyżej można już wyciągnąć jakieś wnioski. Podstawowy jest taki, że oprogramowanie KDE to elementy dość skomplikowanej układanki. Wprawdzie - niekiedy - daje się zbudować jakiś jego element w opaciu o wcześniej wydane. Jeśli jednak nowsza wersja oparta jest o jakiś element, który utracił już wsparcie, to w jaki sposób owe wspacie Wam zostanie udzielone? Co z tego, że np. deweloperzy Kubuntu chwalą się wprowadzeniem do testów Plasma 5.11.3, skoro i tak oparte będzie ono o wersję KF5, która straciła już wsparcie? Jednocześnie nikt w owych dystrybucjach wydawniczych nie zapewni użytkownikowi wsparcia we własnym zakresie. Żaden znany mi zespół nie przejął kodu oprogramowania KDE. I słusznie, bowiem lepiej byłoby się już wdrożyć w ogóle w prace nad oprogramowaniem KDE w ramach tego projektu. Dodatkowo trudno też liczyć na wsparcie twórców oprogramowania, skoro oni rozwijają już coś nowszego. Zgłaszanie takich błędów co najwyżej doda im zbędnej pracy. Czy istnieje idealna dla KDE dystrybucja wydawnicza? Powiem inaczej - nie wiem. Nie interesuje mnie to zbytnio by przeglądać je wszystkie. Niemniej jednak można sobie wyobrazić, że taką dystrybucją byłaby wyłącznie taka, która skupia się na wydaniach LTS tak Plasmy, jak i Qt, a jednocześnie - właśnie w ramach owych np. backports - oferuje nowe wersje oprogramowania i KF5. Dystrybucje wydawnicze inaczej ułożone po prostu większego sensu nie mają. Mit regresji i braku stabilności Pomijam już szermowanie słowem "stabilność" i "możliwa regresja" na lewo i prawo przez zwolenników dystrybucji wydawniczych. Pomijam, że wynika to ze strachu przed nieznanym. Jeszcze częściej trudno jest w ogóle sprecyzować co znaczy "stabilność" w takim przypadku. Bez wdawania się w zbędne szczegóły po kilkuletnim już używaniu oprogramowania spod KDE z cyfrą 5, mogę stwierdzić tylko tyle: przypadki regresji sporadycznie się zdarzają. Najczęściej są one naprawiane dość szybko, w przypadku Plasma 5 otrzymując poprawki w ramach początkowego okresu wsparcia. Czy było ich wiele? Bodaj jedna, czy dwie. Dwie regresje, a nie zamierzona sytuacja. Niestety są jeszcze takie "regresje", które są wynikiem zamierzonym. Dla przykładu jakiś czas temu okna dialogowe drukowania w KDE zostały pozbawione zakładki "zaawansowane". Pozbawione zostały, albowiem miało to przejść do Qt. Niby przeszło, jednakże nie do końca. W zasadzie nawet bardziej "niby", albowiem zakładki tej jak nie było - tak nie ma. Błąd w Qt wisi od dłuższego już czasu i nic nie wskazuje na to, by ktoś się nad nim chciał pochylić. Natomiast - oprócz fazy testowej (która nie dotyczy zwykłych użytkowników; mówię tu o oprogramowaniu w wersjach przed oficjalnym wydaniem) - nie spostrzegłem od długiego czasu jakichś problemów ze stabilnością KDE. Ale cóż - już to wiele razy mówiłem - albo jestem urodzonym szczęściarzem i "u mnie działa", albo potrafię zadbać o swój system.

piątek, 24 listopada 2017

Lumina Desktop Environment 1.4.0

For some reason, we have very outdated version of Lumina DE in AUR. So, I decided to prepare PKGBUILD for current version. It's 1.4.0. By the way, I changed a bit qmake flags used to build it. Original version of PKGBUILD provides only English version of this desktop environment, but Lumina has been translated for many lanugages (it's still work in progress). My version of PKGBUILD builds Lumina with translations. PKGBUILD builds package with proper localizations for files in /etc and for man and add license agreement, also. You can easily download PKGBUILD from here and place it in any directory. After this you should: 1. navigate to directory with PKGBUILD 2. make a package for Arch and install it
makepkg -sirc
Please remember check qmake line in it. It must be only one line. Very simple, I think so. Lumina DE requires fluxbox as window manager. I would like to thank marcin82 from Polish Arch Community for his creative support in creation of this PKGBUILD Po polsku (to nie jest tłumaczenie) W AUR mamy bardzo przestarzałą wersję środowiska graficznego Lumina. Dodatkowo PKGBUILD jest wadliwy. Wadliwą jest także paczka stworzona na podstawie praktycznie tego samego PKGBUILDu, która znajduje się w repozytoriach Manjaro. Postanowiłem przygotować nowy PKGBUILD, który w stosunku do tego, który możecie znaleźć w AUR wnosi następujące zmiany: 1. Buduje paczkę wraz z tłumaczeniami. Nie są one jeszcze ukończone, ale lepszy rydz niż nic. 2. Lokalizacja plików dostarczanych przez paczkę jest zgodna ze standardem Archa. 3. Dodaje treść licencji. PKGBUILD pobrać można z pastebin.com i umieścić w dowolnym katalogu, a następnie przejść do niego i wydać tam polecenie:
makepkg -sirc
Pamiętajcie, by sprawdzić, że linia qmake jest tylko jedna. Nie ma prawa się "dzielić". Lumina DE wymaga jako menedżera okien fluxbox, który musi być również zainstalowany, by prawidłowo pracowała. Chciałbym podziękować @marcin82 z Polskiej Społeczności Archa za nieocenioną pomoc w tworzeniu tego PKGBUILDu.

niedziela, 19 listopada 2017

Brak możliwości utworzenia nowego katalogu w Dolphin [kde-unstable]

Testujący rozwiązania z repozytorium kde-unstable najtrafili najprawdopodobniej na problem braku możliwości utworzenia nowego katalogu w Dolphin (17.11.80 na KF5.40 oraz Qt5.10beta4). Problem został zgłoszony i został też naprawiony, a związany jest ze zmianami wprowadzonymi w Qt5.10. Dopadł zatem wyłącznie użytkowników używających Qt5.10 z kde-unstable. Jego rozwiązanie jednak, trafi dopiero do KIO 5.41, które oczekiwane jest 9.12.2017 r. Wcześniej spodziewać należy się finalnej wersji Qt 5.10, która planowo ukazać się ma 30.11.2017 r. Dzięki spostrzegawczości i wiedzy użytkownika @rog131 z BBS Archa dość szybko udało mi się temu problemowi zaradzić, tworząc dla KIO PKGBUILD z patchem (gdyby link do pastebin przestał działać, proszę mnie powiadomić - umieszczę gdzie indziej). Rozwiązanie jest tymczasowe i wierzę, że niebawem pojawi się wersja przygotowana przez Antonio Rojasa. Wprawdzie w przygotowanym PKGBUILDzie paczka nosi pkgrel 2, jednakże rozważcie sobie, czy nie lepiej dać inną wersję, albowiem prawdopodobnie oryginalna paczka z kde-unstable również będzie nosić takie oznaczenie.

sobota, 18 listopada 2017

KDE Apps 17.11.80 (17.12 beta) dostępne

Zespół KDE udostępnił wczoraj wersję beta zestawu swoich aplikacji, które ukażą się w grudniu. Jest to wydanie o tyle przełomowe, że usunięto z niego wszystkie aplikacje, które nie zostały przeportowane na KF5/Qt5. Skutkiem tego kroku będzie i to, że pakiety lokalizacyjne (kde-l10n-*) również nie będą udostępniane, albowiem są one konieczne wyłącznie dla aplikacji KDE4. Oprócz tych zmian, nie będą dalej rozwijane niektóre aplikacje (jak np. blogilo) - więcej wyżej w odnośniku do wydania. Dla używających Arch Linux, niestrudzony Antonio Rojas (arojas) przygotował paczki zawierające cały zestaw aplikacji KDE 17.11.80. Oczywiście osoby, które mogą się włączyć, są przeze mnie zachęcane, by przetestować te aplikacje i zgłaszać ewentualne błędy tak w samych paczkach, jak i w aplikacjach. Przypominam - pierwszy rodzaj błędów sygnalizujemy w Archu, drugi bezpośrednio w KDE. Chcący wypróbować KDE Apps 17.11.80 muszą udostępnić pacmanowi dwa repozytoria: kde-unstable oraz testing (ze względu na to, że kde-unstable budowane jest na podstawie testing). I tu uwaga. W repozytorium kde-unstable znajdują się obecnie nie tylko paczki KDE Apps 17.11.80, ale również wersja beta4 nadchodzącego wydania Qt 5.10. Tym samym, dokonując aktualizacji systemu wprowadzimy do niego konsekwentnie KDE Apps 17.11.80, Qt 5.10beta4 oraz kilka paczek Plasma 5/KF5, które wymagały przebudowania z uwagi na inną wersję Qt. Nie znajdują się tam natomiast inne paczki, które prawdopodobnie również mogą wymagać przebudowania (niekiedy nawet budujący paczki nie są świadomi, że coś wymaga przebudowania, albowiem teoretycznie nie powinno). Pierwszą kandydatką do tego (ale muszę to sprawdzić dokładniej, a problem w tym, że nie chce się zbudować obecnie) jest QupZilla. Całkiem możliwe, że po aktualizacji mogą Wam odmówić współpracy niektóre programy budowane z AUR. Trzeba je będzie przebudować.

sobota, 11 listopada 2017

Koniec 32 bitowych paczek w Arch Linux

Stało się. Po wcześniejszej zapowiedzi, ostatecznie 8.11.2017 r. 32-bitowe paczki straciły wsparcie w Arch Linux. Do końca listopada paczki tego typu będą sukcesywnie wycofywane z repozytoriów, a potem nawet z archiwów. Pozostają paczki multilib. Wprawdzie jeszcze do repozytoriów wchodzą nowe paczki 32-bitowe, ale nie ma już takiego obowiązku. Dla użytkowników Archa w wersji 32-bit pozostają zatem trzy rozwiązania: - jeśli mogą, albowiem sprzęt ich na to pozwala, powinni zmienić wersję na 64-bitową, - jeśli rozwiązanie to nie jest możliwe, albowiem posiadają 32-bitowe maszyny, mogą sięgnąć po społecznościową kontynuację 32-bitowego Archa, które nazywa się ArchLinux32, - trzecia jest ostatecznością - zmiana dystrybucji. W przypadku kontynuacji Archa jako ArchLinux32, należy dotychczasową listę mirrorów w /etc/pacman.d/mirrorlist zamienić na dostępne obecnie mirrory ArchLinux32, następnie zainstalować paczkę archlinux32-keyring-transition i dokonać aktualizacji systemu, czyli: 1. Zmiana /etc/pacman.d/mirrorlist
sudo rm /etc/pacman.d/mirrorlist && sudo nano /etc/pacman.d/mirrorlist
z treścią:
Server = http://arch32.mirrors.simplysam.us/$arch/$repo Server = https://archlinux32.mirror.roelf.org/$arch/$repo Server = https://mirror.archlinux32.org/$arch/$repo Server = https://32.arlm.tyzoid.com/$arch/$repo
2. Instalacja paczek "transformacji" (m.in. klucze)
sudo pacman -Syy archlinux32-keyring-transition
3. Aktualizacja systemu
sudo pacman -Syuu
Niestety, obecnie niektóre paczki w tych repozytoriach są w starszych wersjach niż w repozytorium Archa. Wykonanie powyższych komend cofnie zatem je do wersji z archlinux32 (prawdopodobnie można by to obejść rezygnując w ostatnim poleceniu z "drugiego" -u, jednakże - jak zwykle nie polecam takich rozwiązań). Również paczki znajdujące się w cache pacmana, w przypadku aktualizacji, ponownej instalacji, będą instalowane stamtąd, a nie z nowych repozytoriów. Celowym wydaje się ich usunięcie poprzez pacman -Sc (czy nawet pacman -Scc). Osoby wybierające pierwsze rozwiązanie nie będą miały lekko. Nie istnieje bowiem żadne narzędzie zmiany architektury systemu, automatyzujące ten proces i nie wymagające jego reinstalacji. Pomijając bowiem paczki "any", pozostałe muszą być zamienione swoimi 64-bitowymi odpowiednikami. Szerzej proces migracji został opisany w wiki Archa oraz na jego forum. Sam tego nie robiłem, zatem odsyłam do wiedzy osób, które mają tu doświadczenie. Przypominam jedynie, że jeśli pośród programów (i sterowników!) dotychczas wykorzystywanych są takie, które występują wyłącznie w architekturze 32-bitowej, wówczas koniecznym będzie dołączenie do listy repozytoriów tzw. [multilib] oraz instalacja odpowiednich paczek lib32-*.

wtorek, 31 października 2017

AMDGPU dla GCN1 i GCN2 i kerneli >=4.13

Jak część z Was wie, od jakiegoś czasu użytkownicy posiadający w swych zestawach karty graficzne AMD zbudowane w architekturze GCN1 (Southern Islands) oraz GCN2 (Sea Islands) mogą korzystać z dwu rodzajów sterowników otwartych: ati, zwany również radeon (paczka xf86-video-ati) oraz amdgpu (paczka xf86-video-amdgpu). Mogą również korzystać z własnościowych sterowników Catalyst, jednakże nie polecam tego rozwiązania, albowiem od końca 2015 roku projekt ten nie jest już rozwijany, a nadto wymaga sporych zmian w systemie. Pozostańmy zatem przy dwu otwartoźródłowych rozwiązaniach. Pamiętajmy, że wsparcie dla GCN1 i GCN2 w kernelu jest w dalszym ciągu określane jako "eksperymentalne". Niemniej jednak - o ile wiem - we wszystkich kernelach obecnie oferowanych jest ono włączone. Musimy również pamiętać, że wsparcie to jest z wersji kernela na kernel lepsze, a zatem w przypadku korzystania z kernela linux-lts (obecnie to wersja 4.9) sensowniej będzie użyć sterownika ATI. Pozostańmy zatem przy kernelu z linii 4.13 dostarczanym w repozytorium. Są to trzy kernele: linux, linux-zen oraz linux-hardened. Na tych kernelach możemy pokusić się o uruchomienie sterownika AMDGPU i cieszyć się jego, ponoć lepszą, wydajnością. Nie ograniczymy się jednak wyłącznie do zainstalowania sterownika xf86-video-amdgpu, albowiem po jego instalacji i tak system będzie pracować albo na sterowniku ATI albo na modesetting. Instalację musimy rozpocząć od sprawdzenia kilku rzeczy. Po pierwsze musimy upewnić się, czy nasza karta jest zbudowana w architekturze GCN1 lub GCN2. Niestety na nic przyjdą tu informacje, jakie o karcie potrafią nam przekazać takie programy jak np. inxi, czy systemowe polecenie lspci, choć będą one pomocne. Na ich podstawie bowiem możemy określić jak nazywa się nasze GPU. Polecam konsolowe inxi, bo daje pełniejszą wiedzę. Zaczynamy zatem od wydania polecenia:
inxi -Gxx
Wyświetli się nam m.in. pozycja "Card" a obok niej nazwa naszego układu. Wyposażeni w taką wiedzę, próbujmy szukać szczęścia pośród informacji dostępnych np. w wikipedii. Niestety niekiedy trzeba będzie poszukać w niej dalej, co pozostawiam już Waszej domyślności. Jeśli nasz układ został zbudowany w architekturze GCN1 lub GCN2 możemy przystąpić do dalszych działań. Upewnijmy się, że kernel został odpowiednio zbudowany i dostarcza wsparcia dla AMDGPU. Wydajmy polecenie:
zgrep -i CONFIG_DRM_AMDGPU /proc/config.gz
Pośród zwróconej odpowiedzi musimy znaleźć CONFIG_DRM_AMDGPU_SI=Y dla układów GCN1 lub CONFIG_DRM_AMDGPU_CIK=Y dla układów GCN2. Jeśli nie zobaczymy ich, to musimy przebudować kernel, albo... pozostać przy sterownikach ATI. Załóżmy, że zarówno nasza karta, jak i wykorzystywany kernel umożliwia nam spróbowanie pracy na AMDGPU. W pierwszej kolejności instalujemy sterownik:
# pacman -Syu xf86-video-amdgpu
Pamiętajmy jednak, że paczka ta wcale nie jest konieczna do działania sterownika AMDGPU. Ten jest bowiem wbudowany w kernel. Paczka powoduje natomiast przyspieszenie działania Xorg, zawierając sterownik DDX. To oznacza, że możemy się cieszyć akceleracją, ale wyłącznie 2D. Za akcelerację 3D odpowiada mesa-vdpau (i lib32-mesa-vdpau dla aplikacji 32bitowych w środowisku 64bitowym). Teraz, prawdopodobnie, mamy w systemie oba sterowniki: ATI oraz AMDGPU. W takim układzie, system uruchomi się na sterowniku ATI. Po pierwsze, prawdopodobnie kernelowi przekazany zostało wyłącznie wywołanie modułu radeon. Po drugie i tak ATI (lub modesettings) pozostanie w takim układzie domyślny. Możemy to zmienić na dwa sposoby. Pierwszy, to zmiana pliku /etc/mkinitcpio.conf i poinformowanie kernela tak o tym, by moduł amdgpu został wywołany i to wywołany jako pierwszy (przed radeon). Potem musimy jeszcze przebudować obraz kernela, a zatem (nano jest tylko przykładowym edytorem):
# nano /etc/mkinitcpio.conf
Odszukujemy sekcję MODULES i dopisujemy tam amdgpu umieszczając przed radeon. Wpis ma wyglądać tak (trzykropek zastępuje inne, ewentualnie istniejące w tym wpisie moduły):
MODULES="... amdgpu radeon ...
Teraz należy przebudować obraz kernela:
# mkinitcpio -p linux
W miejscu linux wpisujemy nazwę kernela do przebudowania. Drugą metodą, jest umieszczenie radeon pośród tzw. blacklists. Możemy tego dokonać również na dwa sposoby. Pierwszym jest utworzenie pliku (nazwa przykładowa) /etc/modprobe.d/blacklist.conf, w którym wpisujemy: blacklist radeon. Drugim to dopisanie do modułów kernela: modprobe.blacklist=radeon. W drugim przypadku, używając GRUB2, dokonujemy edycji pliku /etc/default/grub (nie będę się już powtarzać, wyżej zostało opisane w jaki sposób edytować pliki systemowe), odszukujemy sekcję GRUB_CMDLINE_LINUX_DEFAULT i tam dopisujemy modprobe.blacklist=radeon. Stosowna sekcja (znów "..." zastępuje inne wpisy) wyglądać winna tak:
GRUB_CMDLINE_LINUX_DEFAULT="... modprobe.blacklist=radeon ..."
Teraz trzeba przebudować GRUB (ale o tym dalej). W przypadku kernela linii 4.13 musimy mu jeszcze przekazać instrukcję, by podniósł moduł amdgpu oraz nie podnosił radeonsi. W przypadku GRUB2, w tej samej linii co poprzednio dopisujemy: - dla GCN1:
GRUB_CMDLINE_LINUX_DEFAULT "...amdgpu.si_support=1 radeon.si_support=0..."
- dla GCN2:
GRUB_CMDLINE_LINUX_DEFAULT "...amdgpu.cik_support=1 radeon.cik_support=0..."
Po dokonaniu tych wszystkich wpisów przeładowujemy GRUB2:
# grub-mkconfig -o /boot/grub/grub.cfg
Do pełni szczęścia brakuje nam jeszcze akceleracji 3D. Jeśli zatem nie mamy jej jeszcze uruchomionej, to instalujemy sterownik mesa-vdpau. Od tej chwili, po restarcie winniśmy się cieszyć nowym sterownikiem. Sprawdzamy np. przez inxi. Teraz kilka uwag, czyli czas podzielić się innymi doświadczeniami. Po pierwsze - mam ustawiony tzw. early start KMS z wpisanym modułem amdgpu przed radeon, co teoretycznie winno wystarczyć, by ten pierwszy ładował się jako domyślny. Z drugiej jednak strony umieściłem radeon w blacklist. Z jakiegoś powodu dopiero takie rozwiązanie pomogło, a obecnie nie chce mi się bawić w sprawdzanie innych, skoro takie rozwiązanie działa prawidłowo. Po drugie i ważniejsze. W przypadku mojej karty, próba odszukania czy jest należy on do GCN1, czy GCN2 uparcie przynosiła informację, że należy do Southern Islands, a zatem stosowne wpisy dla kernela, to SI. Wprowadzenie jednak takich parametrów dla kernela nic jednak nie dawało, albowiem jest on rozpoznawany jako GCN2 (CIK). Dopiero użycie takich parametrów spowodowało pracę AMDGPU. Proponuję zatem wykonanie startu na próbę wpierw z jednym, a potem z drugim parametrem. Jeden z nich będzie prawidłowy i taki należy wprowadzić do pliku konfigurującego GRUB2. Po trzecie. Istnieje jeszcze sterownik AMDGPU-PRO. Pomijam już sam fakt, że nie ma on wsparcia dla Arch Linux (jest to sterownik własnościowy i rozpowszechniany jest wyłącznie jako paczka deb lub rpm; stosowne PKGBUILDy znajdują się jednak w AUR), to ten sterownik w żaden sposób nie jest przeznaczony dla układów GCN1 i GCN2. Niech Was zatem przez przypadek nie zwiedzie zarówno zbliżona nazwa, jak i to, że w tym przypadku "pro" wcale nie oznacza, że coś jest lepsze. Po prostu nie jest przeznaczone dla tych układów. Tekst powstał m.in. w oparciu o materiał w wiki Archa i tam też więcej się dowiecie.

wtorek, 24 października 2017

Nadzieja na lepszą integrację LibreOffice ze środowiskami opartymi o Qt5

Nie. Absolutnie nic nie wskazuje na to, by LibreOffice miało zostać przepisane z użyciem Qt5. Mowa tylko o mechaniźmie wtyczki VCL, która umożliwia mimifikację wyglądu LO do natywnego w danym środowisku. Obecnie mamy cztery takie wtyczki: gtk2, gtk3, kde4 oraz "natywną". Cały proces winien przebiegać bez udziału użytkownika, choć można go wymusić. Obecnie, chcąc najbardziej upodobnić wygląd LO do np. Plasma 5, musimy zainstalować kdelibs oraz wystrój breeze dla KDE4. Wówczas jest lepiej, co nie znaczy idealnie. Proces przepisania wtyczki VLC dla KDE4 wydawał się nieunikniony, jednakże nie stanowił priorytetu prac. Niemałym zaskoczeniem dla mnie, było zatem ogłoszenie podczas LibreOffice Conference 2017 informacji o pracach w tym zakresie. Za przepisanie wtyczki odpowiedzialną jest Katarina Behrens, a całość w znacznym stopniu zawdzięczamy władzom Monachium, które postanowiły sponsorować te prace. W rezultacie winien poprawić się nie tylko wygląd LO w Plasma 5, natywne okna dialogowe z Plasmy 5, ale również dzięki temu winniśmy uzyskać wsparcie dla sesji Plasmy w Waylandzie oraz dla Hi-DPI. Niestety nic nie wiadomo na razie kiedy możemy oczekiwać działającej wtyczki. Mój podgląd do rozwojowej, planowanej na przełom stycznia i lutego 2018, wersji 6.0 nie wskazuje jeszcze na to, by była ona tam dostępna choćby w zalążku.

poniedziałek, 23 października 2017

KDEPIM bez kopii zapasowej?

Niemal do miejskich legend przeszły utiskiwania nad brakiem łatwego programu do robienia kopii zapasowej w KDEPIM (Kontact, KMail,...). Fakt. W przeglądając opcje w menu programów składających się na KDEPIM nie znajdziemy czegoś takiego. Czy jednak fakt, że nie znaleźliśmy czegoś upoważnia nas do stwierdzenia, że czegoś nie ma? Antarktydy też nie ma, bo jej nie widziałem. Podobnie jak setek tysięcy innych rzeczy. Czas uderzyć się w pierś i powiedzieć: w błędzie byliśmy. Od bardzo dawna już (KDEApps 16.12), instalując grupę kdepim w Archu dostaniemy wraz z nią pim-data-exporter a wraz z nim zainstalują się dwa programy: pimsettingexporter oraz pimsettingexporterconsole. Pierwszy to wygodny program z GUI, drugie narzędzie konsolowe służące temu samemu celowi - eksportowi ustawień wszystkich programów składających się na KDEPIM oraz ewentualnie również archiwizowanych przezeń danych do pliku zip. Nie muszę chyba dodawać, że łatwo ów plik zip potem wczytamy do programu. Program jest prosty i prowadzi użytkownika niemal za rękę. Mam jednak pytanie do tłumacza: w jaki sposób wpadł na to, by angielskie "PIM Setting Exporter" przetłumaczyć na "Eksporter ustawień ZIO", a komentarz "PIM Setting Exporter allows to save all data from PIM apps and restore them in other system." przetłumaczyć jako "Eksport/Import ustawień ZIO"? W ten bowiem - kompletnie chyba dla nikogo nic nie znaczący - sposób przedstawia nam się program w menu. Co jeszcze ciekawsze, jeśli chcemy archiwizować jedynie pocztę KMail, to odpowiednia usługa jest dostępna bezpośrednio w programie. Wystarczy odnaleźć Ustawienia -> Ustawienia okresowego archiwizowania i... możemy zapomnieć. Usługa będzie pracować w tle, wygodnie za nas tworząc odpowiednie kopie. Możemy sobie określić ile owych kopii ma być tworzonych, gdzie mają być przechowywane. Znów prosto i przyjemnie. Zatem... jak nie ma, jak jest...? :)

Qt 5.10 beta 1

Od pewnego czasu w repozytorium kde-unstable dostępne są paczki pierwszej bety, nadchodzącego wydania Qt 5.10. Oprócz nich otrzymamy tam jeszcze kilka paczek z grup kf5 oraz plasma, które wymagały przebudowania w oparciu o nowsze biblioteki. Oczywiście, jak zwykle, powiedziałbym bierzcie i testujcie :) Tym razem jednak zamiast tego, pewne ostrzeżenie. Zapewnie wiecie doskonale, że niektóre środowiska są oparte o te biblioteki. Spośród tych już dojrzałych w mniejszym, czy większym stopniu to Plasma 5 (wraz z frameworkiem KF5) oraz LXQt. Także kilka dopiero przebijających się, jak np. Deepin DE, czy Liri. O ile niezbędne paczki z KDE zostały przebudowane w oparciu o Qt 5.10, to w przypadku innych środowisk musicie dowiedzieć się, czy i które (bo na pewno nie wszystkie) paczki składające się na dane środowisko będą wymagać przebudowy. To jednak jeszcze przysłowiowe małe piwo. Otóż Qt 5.10, przynajmniej w wersji Beta 1, robi psikusa użytkownikom Plasma 5. Po zainstalowaniu jest być może i lepiej, może niekiedy będzie też "stabilniej", zapewne też duża część błędów dostrzeżonych dotychczas w poprzednich wersjach Qt została usunięta. Jeden jednak jest - przynajmniej dla mnie - dokuczliwy i pojawił się dopiero w tej wersji. Otóż po instalacji Qt 5.10 beta 1, prawdopodobnie (nie wiem, czy dotyka to wszystkich) zostaniecie pozbawieni możliwości drukowania z aplikacji budowanych z wykorzystaniem Qt. Nie ma znaczenia, czy to aplikacja korzystająca tylko z tych bibliotek, czy też należąca do KDE. Drukować można było, a obecnie nie. Nie przeszkadza to jednak w drukowaniu z aplikacji które nie wykorzystują Qt. Bez problemu wydrukować można z np. LibreOffice, czy z GIMPa. Problem nie dotyczy wyłącznie Arch Linuksa. Został przeze mnie zgłoszony na BBS Archa, jednakże nie jest on związany z samą budową paczek. Zgłosiłem go także na QTBUG, gdzie uzyskałem potwierdzenie od użytkownika OpenSUSE Thumbleweed z repozytoriami Krypton, że problem wystąpił również w tamtej dystrybucji. Innych, które korzystają z Qt 5.10 - nie znam. Co ciekawe, choć większość osób zdaje się potwierdzać istnienie tego błędu, to nie dotyczy on wszystkich. Mimo wszystko - choćby czasowo, choćby na nieroboczym komputerze - proponuję się wdrożyć do testów z nową wersją Qt. Potem będzie mniej narzekania, że coś nie działa. No niestety - całość testów działa w ten sposób, że im więcej będzie nas, testujących, tym większe prawdopodobieństwo, że duża część dostrzeżonych obecnie błędów zostanie wyeliminowana. Dla osób, które są zainteresowane zgłoszonym błędem polecam stosowną dyskusję na BBS Archa (i poniżej) oraz samo zgłoszenie w QTBUG-63954. AKTUALIZACJA: Dzisiaj błąd QTBUG-63954 uzyskał status krytycznego, co oznacza, że bez jego naprawy Qt 5.10 nie zostanie wydane. AKTUALIZACJA 2 Zgodnie z otrzymaną informacją, błąd został już naprawiony w obecnej (tj. po ukazaniu się Qt 5.10 beta 1) wersji Qt.

niedziela, 17 września 2017

KMarkdownWebViewer

Czternastego września nie tylko ukazała się testowa wersja Plasma 5.11, ale aplikacje KDE uzyskały nowy element, dzięki którym te spośród nich, które wykorzystują KParts (np. Ark) są w stanie wyświetlić prawidłowo (tj. z formatowaniem) tzw. tekst markdown. Pliki w takim formacie (najczęściej noszące rozszerzenie *.md) często znajdziemy np. w pobranych źródłach programu. Jak dotychczas nie pojawiła się stosowna paczka w Archu, jednakże przygotowałem dla Was PKGBUILD. Jeśli chcecie z niego skorzystać, to znajduje się na pastebinie. Trzeba go skopiować do jakiegoś katalogu, a następnie skorzystać z możliwości makepkg. Wersja PKGBUILDu przedstawiona przeze mnie wykorzystuje qt5-webengine. Możliwe jest też skorzystanie z qt5-webkit. W takim przypadku należy dodać do sekcji depends qt5-webkit (bowiem możecie jej nie mieć w systemie) oraz dodać dla cmake opcję -DUSE_QTWEBKIT=TRUE. Wspomnieć należy, że obok już dostępnego KMarkdownWebView trwają prace nad podobnym rozszerzeniem dla KTextEditor, które usprawni aplikacje wykorzystujące ten element KF5 (np. Kate, KDevelop). Wszystko natomiast przybliża nas do usprawnienia możliwości wyświetlania kolejnego formatu przez przeglądarkę Okular.

Plasma 5.10.95 aka 5.11Beta

Zgodnie z planem wydawniczym, 14.09. pojawiła się wersja 5.11 Beta środowiska Plasma. Dzięki pracy nieocenionego Antonio Rojasa (arojas) pojawiła się ona również w repozytorium kde-unstable Archa. Korzystając już z niej od kilku dni nie napotykam na jakieś problemy ze stabilnością. Jest nieco nowości: Ustawienia Systemowe uzyskały dodatkowy tryb wyglądu, powiadomienia historię, menedżer zadań (ale tylko ów domyślny) dorobił się pewnych dodatkowych opcji... Myślę jednak, że z punktu widzenia użytkownika dwa usprawnienia są najistotniejsze. Od tej wersji Plasmy będziemy się mogli cieszyć elementem o nazwie plasma-vault. Jest to aplikacja umożliwiająca przechowywanie plików w zaszyfrowanych katalogach. Druga rzecz, która mnie cieszy - obecnie można bezpośrednio z aktywatora programów otworzyć możliwość edycji ustawień danego programu. Mała rzecz, a cieszy i jest bardzo wygodna. Więcej w odnośniku wyżej. Oczywiście zachęcam do testowania, albowiem tylko w ten sposób osoby, które nie są informatykami, mogą pomóc usprawnić Plasmę zanim się ona jeszcze pojawi w wydaniu stabilnym. Możemy też pomóc w ewentualnych kwestiach związanych z paczkowaniem. Dostrzeżone błędy należy zgłaszać - w pierwszym przypadku na bugzilli KDE, w drugim na specjalnie uruchomionym wątku w BBS Archa. W pierwszym przypadku, zgłaszając błędy w środowisku, pamiętajmy o tym, by dołączyć użyteczne informacje, a w szczególności wynik tzw. debugowania. Bez nich zgłoszenia są bezużyteczne dla programistów. Pamiętajmy też, że archowe paczki są budowane w wersji Release, a zatem nie zawierają symboli debbugowania. Chcąc prawidłowo zgłosić błąd proszę się wpierw zaznajomić z tekstem na wiki Archa. Inaczej wyłącznie zaśmiecamy bugzillę KDE dostarczając programistom więcej kłopotów niż pożytku.

sobota, 26 sierpnia 2017

Żegnamy QupZillę

QupZilla towarzyszy mi mniej więcej od czasu, gdy Rekonq przestał być rozwijany. Teraz QupZilla odchodzi. Na szczęście nie aplikacja, a nazwa jedynie. Od następnego wydania (powinno być w sierpniu lub wrześniu, a w każdym razie wkrótce po opublikowaniu Qt 5.9.2) nazywać się będzie Falkon i jednocześnie staje się kolejną aplikacją rozwijaną pod auspicjami KDE. Nie zdziwcie się zatem, że przy jakiejś aktualizacji pacman będzie chciał odinstalować qupzillę i w jej miejsce umieścić falkona. Osoby korzystające z qupzilla-git będą prawdopodobnie musiały same przebudować sobie PKGBUILD (jak ktoś chce, to służę). Obecna rewizja (2.1.99.efff69b7b2) tworzy swój własny katalog z profilami w ~/.config/falkon. Dla zachowania swojego starego profilu konieczne jest zatem przeniesienie zawartości ~/.config/qupzilla do ~/.config/falkon. Podobnie tworzony jest nowy plik ~/.config/Falkonrc, który również możemy podmienić zawartością ~/.config/QupZillarc by móc korzystać z Falkona dokładnie w tym miejscu, w którym skończyliśmy pracę w QupZilli.

sobota, 29 lipca 2017

Zarządzanie zaporą sieciową w Plasma 5

Podzielone są głosy, czy istnieje potrzeba używania firewall na desktopie. Pewnie - i słusznie - większość stwierdziłaby, że reguły sieciowe winny być zdefiniowane w routerze. Niemniej jednak są osoby, które chcą je ustawiać w swoich komputerach. Powiedzmy sobie szczerze: choć linux dysponuje potężnymi narzędziami do regulacji zasad ruchu sieciowego, to dla zwyłego użytkownika ich ręczne ustawianie to czarna magia. W KDE4 istniał kiedyś moduł dla Ustawień Systemowych o nazwie kcm-ufw, który prosto zarządzał właśnie UFW. Moduł ten nie doczekał się jednak przepisania na Plasma 5 i z końcem roku powinien definitywnie wypaść ze świata KDE. W międzyczasie powstała nowa dystrybucja o nazwie Nitrux, która oprócz zmian w zakresie wyglądu Plasma 5 dostarcza również kilku aplikacji rozwijanych w ramach projektu. Pomiędzy nimi jest też Nomad Firewall. Aplikacja doczekała się wersji... 0.1, niemniej jednak jest ona funkcjonalna i na pewno dużo prościej przez nią zarządzać regułami zapory sieciowej. Po instalacji mamy dostępną zarówno samodzielną aplikację, jak i moduł uruchamiany przez Ustawienia systemowe. Nie byłbym sobą, gdybym nie zrobił dla niej PKGBUILDu. Prezentowany jest w wersji "git", gdyż aplikacja jest dość intensywnie rozwijana. Jeśli ktoś chciałby ją w wersji "stabilnej" :) 0.1 i nie wiedziałby jak przerobić PKGBUILD dla jej uzyskania, to proszę o kontakt.

piątek, 28 lipca 2017

Powrót z przeszłości: Kooka

W zamierzchłych czasach narzędziem do skanowania oferowanym w ramach KDE była Kooka. O ile pamiętam, to nigdy nie ukazała się oficjalnie jej wersja dla KDE4, gdzie została zastąpiona przez skanlite. Ta pierwsza ponad skanowanie dokumentu dodawała możliwość jego rozpoznania przez jeden z trzech silników OCR. Tym samym kooka stawała się namiastką programów typu Recognita dla KDE. Namiastką, albowiem samo rozpoznawanie tekstu w linuksie, szczególnie polskiego tekstu, było bardzo ułomne. Obecnie nieco zapomnieliśmy o tej funkcjonalności komputerów i większość dokumentów jest po prostu zapisywanych w nieedycyjnych formatach graficznych, w tym w pdf. Obecnie takim narzędziem jest np. gimagereader dostępny w AUR w dwu wersjach: używającej bibliotek Gtk+, przez co lepiej nadaje się dla środowisk o nie opartych oraz używającej Qt5. Niemniej jednak, jak feniks z popiołu odradza się Kooka, która w większym stopniu zintegrowana jest z Plasmą (oparta o KF5). Aplikacja działa i na pewno nadaje się do skanowania. Jej możliwości OCR ograniczone przez silniki: ocrad, gocr i kadmos. Pierwsze dwa są dostępne w repozytorium, ostatni jest przedsięwzięciem komercyjnym. Załączam PKGBUILD, który umożliwia budowę wersji "git" tej aplikacji. Jeśli chcemy korzystać z możliwości OCR musimy zainstalować co najmniej jeden z wyżej wymienionych silników.

Huen, czyli kolorystyka Plasmy na podstawie tapety

Jakiś czas temu pojawił się w sklepie KDE dodatek do Plasmy, który umożliwia dostosowanie kolorystyki panelu do aktualnej tapety. Daje nawet trzy różne opcje owego dostosowania, które w efekcie dają kolor panelu w zależności od wyboru dominującego koloru tapety. Aplikacja nazywa się Huen i można ją pobrać ze sklepu, a następnie zainstalować skryptem znajdującym się w paczce (dostarczony jest również skrypt aplikację usuwający). Po instalacji program pojawia się w menu i można z niego korzystać w dwu dostępnych opcjach: jedna, w której zdajemy się na automatyzm w niej zawarty i druga, która umożliwia nam dostosowanie ustawień bardziej pod siebie. Po zaakceptowaniu zmian pojawia się w ustawieniach systemowych nowy wygląd pulpitu o nazwie Huen, który został przez nią zbudowany. Nie podoba mi się natomiast, że kompilując program dołączonym skryptem odbywa się ona z uprawnieniami roota. Między innymi z tego powodu postanowiłem zrobić dla Was PKGBUILD. Zdecydowanie więcej niż ode mnie dowiecie się z dołączonego filmu.

sobota, 1 lipca 2017

FocusWriter a sprawa polska

Ewentualnie innych języków, na które aplikacja ta została przetłumaczona. Z pewnego powodu prosty procesor tekstu FocusWriter wprawdzie buduje pliki lokalizacyjne (*.qm), ale ich nie przenosi w prawidłowe miejsce. Ot, prawdopodobna wpadka przy pracy z plikiem *.pro. W efekcie zbudowana z AUR aplikacja będzie działać wyłącznie w języku angielskim, choć mogłaby również w polskim. Istnieje bardzo proste obejście problemu. Podczas budowania paczki należy dokonać edycji pliku PKGBUILD i w sekcji package po:
make INSTALL_ROOT="$pkgdir/" install
dopisać:
cp translations/*.qm $pkgdir/usr/share/focuswriter/translations
Ewentualnie jeszcze trzeba będzie wybrać polski język interfejsu już w samej aplikacji. EDIT: Wszystko wskazuje na to, że wersja FocusWriter 1.6.5-2 dostępna od 3.07.2017 r. w AUR buduje już poprawnie paczkę i nie trzeba stosować powyższej sztuczki. Wersja focuswriter-git nie wymaga już również dodawania żadnych wpisów.

środa, 28 czerwca 2017

LibreOffice 5.4RC1 oraz 6.0alpha0

Od jakiegoś czasu są rozwijane wersje, które stanowić będą następców obecnych wydań LO. Ciekawostką, że wersja 5.4.x będzie ostatnią w linii 5.x, a dostępna od przyszłego roku będzie już linią 6.x. Wersje testowe 5.4 są już dostępne ze strony LO, także dla linuksa, jednakże - jak zwykle - są to wydania deb i rpm. Oczywiście są udostępnione także źródła. Wersja rozwojowa 6.0 jest głębiej ukryta i dostępna bezpośrednio z serwerów Document Foundation. W odróżnieniu od 5.4RC1 w tej wersji nie możemy się jeszcze spodziewać spolszczenia, choć możliwe jest oczywiście korzystanie z polskich słowników, czy innych reguł pisania. Jak zwykle namawiam osoby, które są chętne do testowania, by choćby w ten sposób włączyły się w rozwój oprogramowania. Jest jeszcze czas, by usunąć jakieś ewentualne niedoróbki. Jeśli zatem ktoś zechciałby się włączyć, to mogę zaproponować obie wersje pakietów (w przypadku 6.0 także z "instrukcją obsługi" jak ją aktualizować) dla Archa (także dystrybucji pochodnych). Oba pakiety są przebudowywane z oryginalnych paczek rpm i mogą zostać zainstalowane obok libreoffice-fresh/still. Nie ingerują też w żaden sposób w ustawienia wersji z repozytorium. Nie będę tym razem zamieszczał PKGBUILDu - gdyby ktoś zechciał się zdecydować - proszę o kontakt.

czwartek, 22 czerwca 2017

Dlaczego nie instalować pojedynczych paczek innych gałęzi systemu

Dystrybucje linuksowe zwykle zawierają "przejściowe" repozytoria, gdzie testowane są nowe paczki. Niektóre dystrybucje, z owych repozytoriów tworzą nawet niemal oddzielne gałęzie swych dystrybucji, a społecznościowa gawiedź dośpiewuje całą resztę, upatrując np. w Debian Testing ucieleśnienia dystrybucji rolling release. Zostawmy jednak Debiana, skupmy się na Archu i pokrewnych. W Archu dostępnych jest kilka repozytoriów. Podobnie w Manjaro. W strukturze repozytoriów tego pierwszego znajdziemy repozytoria z "dopiskiem" testing i dwa repozytoria z "dopiskiem" unstable (kde i gnome). Struktura gałęzi Manjaro jest praktycznie przeniesiona z Debiana, choć absolutnie niewiele ma z nim wspólnego. Ograniczę się do omówienia Archa, jednakże to samo ma zastosowanie do innych dystrybucji rolling release (to jest kluczowe), na pewno natomiast ma to 100% zastosowanie do dystrybucji, gdzie paczki zarządzane są przez pacmana. Otóż pojawiają się wpisy omawiające sposób zainstalowania pojedynczej paczki z innej gałęzi (repozytorium testowego, niestabilnego) danej dystrybucji. Jest to bardzo nieodpowiedzialny pomysł, choć realizowany wg zasady: chcącemu nie dzieje się krzywda. Oczywiście, że istnieje możliwość zainstalowania czegokolwiek, skądkolwiek i w jakiejkolwiek wersji. Zastanówmy się jednak co to oznacza i czy na pewno "możliwość" oznaczna, że "można". Przede wszystkim należy przypomnieć jedną sprawę: pacman nie wspiera częściowej aktualizacji. Uświadomijmy sobie również, że taka instalacja nowej wersji z testowego repozytorium jest niczym innym, jak właśnie dokonaniem częściowej aktualizacji. Operacja może się udać. Program zainstalowany w ten sposób może działać prawidłowo. Może jednakże nie działać wcale, może okazać się działającym wadliwie (np. niestabilnie). Może też doprowadzić do destabilizacji całego systemu, a w skrajnych przypadkach po prostu go nie uruchomimy ponownie (w obu przypadkach, gdy np. zmieniliśmy jakiś kluczowy jego element, bibliotekę, na która jest zależnością innych paczek). Dlaczego tak się dzieje? Otóż dystrybucje takie jak Arch są robione w taki sposób, że ich deweloperzy starają się zapewnić właściwą pracę zaktualizowanego systemu. Paczki znajdujące się w określonym repozytorium są budowane w taki sposób, że ich zależności znajdują się w tym właśnie repozytorium. Owe zależności oznaczają nie tylko "nazwę paczki", ale też jej określoną wersję, która w tym repozytorium się znajduje. Paczki w repozytorium "stabilnym" winny zatem być w korelacji ze sobą. W repozytorium testowym będą paczki skorelowane ze sobą. Jeśli zatem jakaś paczka będzie wymagała jakiejś zależności w określonej wersji, to owa paczka w takiej wersji się znajdzie. I odwrotnie - jeśli jakaś zależność spowoduje konieczność przebudowania jakiejś paczki, to taka przebudowana paczka tam się znajdzie. To właśnie dlatego pacman nie wspiera częściowej aktualizacji. Musimy sobie uświadomić jeszcze jedną rzecz. Otóż w przeciwieństwie np. do APTa, w PKGBUILD bardzo rzadko znaleźć można określenie wersji konkretnej paczki stanowiącej zależność. Przy instalacji poszczególnej paczki nie zostajemy zatem powiadomieni o tym, że jakaś paczka nie jest kompatybilna z wersją instalowaną. Arch (Manjaro) - to Arch. Bardzo prosta w budowie dystrybucja, jednak trzeba o nią dbać, a nie gwałcić ją na siłę. Chyba, że doskolane wiemy co robimy, wiemy, że instalacja czegoś pociąga konieczność zmiany innej paczki itd. itp. Co zatem zrobić, jeśli z jakiejś przyczyny bardzo musimy mieć wersję paczki znajdującej się w gałęzi (repozytorium) innym niż używane? Trudno - innej drogi nie ma - choćby czasowo musimy zainstalować wszystkie paczki w tej samej wersji (testowej), w jakiej potrzebujemy mieć określoną (jedną) paczkę. W Archu robimy to "ręcznie" udostępniając repozytoria testowe. W Manjaro możemy wydać polecenie:
sudo pacman-mirrors -g -b testing (lub unstable)
I dokonać pełnej aktualizacji:
sudo pacman -Syu
Jeśli później zechcemy wrócić do "gałęzi" poprzedniej, powinniśmy w Archu zakomentować repozytoria testowe, w Manjaro wykonać:
sudo pacman-mirrors -g -b stable (lub testing)
I... dokonać pełnej aktualizacji systemu z jednoczesnym wgraniu w miejsce istniejących lokalnie wersji paczek, tych, które znajdują się na serwerze, nawet jeśli są one w wersji niższej od lokalnej:
sudo pacman -Syuu

Naprawiamy wadliwe źródła w PKGBUILD

Zdarza się, że przy budowie jakiejś paczki z AUR otrzymujemy taki błąd:
==> BŁĄD: Błąd podczas pobierania http://jakiś_adres
Przerywam...
Najczęściej powodem tego błędu jest wadliwy adres źródła. Może to być spowodowane tym, że zmianie uległa wersja programu, a źródeł starej już nie ma, może być spowodowane zmianą adresu źródła, powodem może być też, że źródła w ogóle zostały usunięte, może to być też jakiś czasowy problem z połączeniem. Ostatnie - proste - można spróbować po chwili. Na całkowite usunięcie źródeł możemy nie zaradzić wcale. Jedyne co mogę sugerować to poszukanie w necie, czy gdzieś nie są one oferowane w innej lokalizacji. W tej sytuacji powinniśmy jednak mieć pewność co do poprawności paczki oferowanej nie przez jej autora. Pierwsze dwa są dość proste do naprawienia. Generalna zasada: odszukać źródła. Wchodzimy na stronę AUR z PKGBUILDem, znajdujemy URL źródła, przechodzimy i czytamy co się zmieniło. Oczywiście informujemy również opiekuna takiej paczki w AUR o zaistniałym problemie. Możemy też przedstawić mu wyniki analizy naszego skromnego dochodzenia - korekta w AUR może się pojawić szybciej. W każdej z poniższych sytuacji wykorzystujemy sposób instalacji paczek bez tzw. aurhelperów. Przypomnę zasady: - ściągamy tzw. źródła budowania paczki z AUR np.:
git clone https://aur.archlinux.org/nazwa_paczki.git
- w katalogu, z którego wydaliśmy to polecenie powstanie podkatalog o nazwie nazwa_paczki, przechodzimy do niego:
cd nazwa_paczki
- dalsze operacje wykonujemy na pliku PKGBUILD, który znajdziemy w tym katalogu. 1. Oferowana jest nowa wersja i nie jest dostępna stara. Po pierwsze oflagujmy paczkę w AUR jako nieakutalny (ramka po prawej stronie). Po drugie, w zależności od tego, czy czujemy się na siłach, możemy spróbować zainstalować paczkę w nowszej wersji. W tym celu: - zmieniamy zawartość pola pkgver na taką wersję, z jaką napotkaliśmy się na stronie domowej programu, - dokonujemy ewentualnej zmiany w polu source na korespondujący z nową wersją; jeśli w tym polu będzie adres posługujący się zmienną wersji źródła (tj. zobaczymy np. coś takiego:
jakiś_adres/coś-$pkgver_coś
to PKGBUILD posługuje się zmienną ($pkgver) w celu ustalenia adresu źródła - w tej sytuacji nie powinniśmy mieć potrzeby dokonywania jakichkolwiek zmian, jeśli jednak w adresie tym znajdziemy jakieś cyfry wskazujące na właśnie co zmienioną wersję w polu pkgver to i w adresie musimy je zmienić. - sprawdzamy, czy pozostałe sekcje PKGBUILD posługują się ewentualną zmienną numeru wersji ($pkgver), czy też jej numerem - w tym drugim przypadku zmieniamy na nowy numer wersji, - wykonujemy polecenie:
updpkgsums && makepkg -sirc
- liczymy na to, że operacja się udała. Jeśli operacja się nie udała, pozostaje nam czekać na podbicie wersji w AUR bądź zwrócić się do społeczności o pomoc. Chyba, że sami jesteśmy w stanie poradzić sobie z problemem. W tym ostatnim przypadku dobrze jest choćby w komentarzach na AUR podać rozwiązanie. 2. Zmianie uległ adres źródła. Po pierwsze zawiadamiamy o tym opiekuna paczki w AUR. Po drugie zmieniamy zawartość pola source na właściwy adres (najprościej będzie nam po prostu go wkleić w miejsce dotychczasowego) wykonujemy polecenie:
updpkgsums && makepkg -sirc
3. Źródła zostały usunięte, ale znajdują się w innej lokalizacji. Jeśli jesteśmy ich pewni, to postępujemy dokładnie tak samo jak w punkcie 2. 4. Czasowy problem z dostępem do serwera ze źródłami. Jak już napisałem - poczekać. Jeśli jednak bardzo nam zależy na szybszym zbudowaniu paczki, możemy spróbować znaleźć w necie jakiejś alternatywnej lokalizacji źródeł i postąpić jak w punkcie 2.

środa, 21 czerwca 2017

Czy muszę mieć uprawnienia root, by sprawdzić możliwość aktualizacji?

Oj, tam. Psioczymy niekiedy na nasz system (Arch), a nie znamy jego możliwości. Psioczymy na przykład, że aby sprawdzić możliwość aktualizacji systemu musimy wydać jakieś polecenie, wpisać hasło administratora i dopiero potem dowiemy się, czy aktualizacja jest możliwa. Innymi słowy, wpisujemy w terminalu:
sudo pacman -Syu
No dobrze, a czy korzystając z dobrodziejstw zainstalowanych wraz z pacmanem nie możemy napisać:
checkupdates
...? Nie musimy wpisywać haseł administratora, niczego. Po chwili uzyskamy informację czy jest, czy też nie jest możliwa aktualizacja systemu.

wtorek, 20 czerwca 2017

Aplikacje KDE pozwolą na roota. Bezpieczeństwo i wolność

Nie tak dawno - tu i ówdzie - podniosła się wrzawa, że KDE w imię bezpieczeństwa odbiera wolność użytkownikom, uniemożliwiając wykonywanie działań wymagających uprawnień administratora w aplikacjach KDE. To nic, że "problem" dotyczył wyłącznie trzech aplikacji: kate, kwrite i dolphin. To nic, że dotknął jedynie tych dystrybucji, które zaoferowały KF w wersji co najwyżej 5.33 oraz jednocześnie aplikacje z wersji 17.04.0. Jednocześnie z opublikowaniem tej wersji, zostało wprowadzone obejście, umożliwiające edycję plików wymagających uprawnień administratora przez kate i kwrite. Mimo wszystko problem był, a w zasadzie to został sztucznie rozdmuchany, zwłaszcza, że już w chwili jego (problemu) tworzenia była znana informacja na temat zmian, jakie w 2017 r. czekają KIO z KF5. Realizując założenia zmian w KIO na ten rok, już 13.05.2017 r. zostało udostępnione publicznie KF5.34, które przywróciło możliwość edycji plików wymagających uprawnień administratora przez kate i kwrite bez bez wspomnianego obejścia (gwoli pełnej informacji, KDE Applications 17.04.0 pojawiło się publicznie 20.04.2017 r.). Od tej chwili możliwe była zatem edycja np. plików systemowych, a przy próbie ich zapisu system prosił o hasło administratora. Wszystko dzięki zmianom w KIO i połączeniu go z mechanizmem polkit. Tym samym zwiększono bezpieczeństwo bez zmian funkcjonalności. Pozostał "problem" jedynie z dolphinem, który uniemożliwiał operacje na plikach systemowych (inna sprawa, że prawidłowo skompilowany krusader takich problemów nie miał i nie ma). Stąd też np. powstawały forki typu dolphin-root, różniące się od oryginału wyłącznie cofnięciem zmiany uniemożliwiającej takie działania. Ba, dolphin-root pojawił się nawet w repozytoriach niektórych dystrybucji. Śpieszę zatem donieść, że i ten "problem" przestanie niebawiem istnieć. Otóż wprowadzone niedawno przez Chinmoya Ranjana Pradhana zmiany w KIO zostały właśnie połączone z kodem KF5 i już w nadchodzącym wydaniu KF5.36 (planowane na 8.07.2017 r.) dolphin odzyska możliwość pracy również na plikach systemowych. Mechanizm wprowadzonej zmiany ten sam, jak w przypadku kate i kwrite, czyli wykorzystanie polkit. Jeśli ktoś bardzo chciałby skorzystać z tej funkcjonalności obecnie, to musiałby zbudować KF5 z git i niestety nie wystarczy samo KIO, albowiem zmiany nadchodzące w wydaniu 5.36 są na tyle duże, że nie jest możliwym budowa samego KIO z git bez zbudowania komponentów, na których się opiera. Można ewentualnie spróbować użyć udostępnionych patchy (dla dolphin), jednakże ich wbudowanie wymaga również spatchowanej wersji KIO (tj. dodania tych funkcjonalności, które właśnie zostały tam wprowadzone (dot. JobUiDelegate). Teraz pozostaje mieć nadzieję, że z wprowadzonych mechanizmów z czasem zaczną korzystać inne aplikacje wykorzystujące Xy, a umożliwiające pracę w przestrzeni administratora. Problem bowiem nie jest tak trywialny, jak się niektórym wydaje, że dotyczy to tylko i wyłącznie wprowadzenia do systemu niezamierzonych zmian przez użytkownika.

poniedziałek, 19 czerwca 2017

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy:
[DEB_Arch_Extra]
SigLevel = Optional TrustAll
Server = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/
Nadto musimy jeszcze dodać klucz:
gpg --receive-keys BF8B66E01192CBA2E72201294B4E7A9523ACD201
Instalujemy megasync oraz - jeśli chcemy - dowolny dodatek do naszego menedżera plików. Od tej pory możemy się cieszyć łatwym dostępem do dość potężnej chmury. Oczywiście, o ile mamy tam utworzone konto.

czwartek, 15 czerwca 2017

Aplet informujący o aktualizacjach w Archu

Choć zrobiony w istocie z myślą o Archu, to sądzę, że prawidłowo będzie działał w każdym systemie korzystającym z checkuptades - oto pojawił się nowy, integrujący się z Plasmą 5, aplet informujący nas o możliwych aktualizacjach systemu. Nazwa jaką przyjął w sklepie KDE to Arch Linux System Tray Update Notifier and Upgreader i jej przeczytanie trwa chyba dłużej niż budowa tego programiku. Jak wspomniałem, aplet wykorzystuje checkupdates, a dzięki temu nie potrzebuje uprawnień administratora. Posiada podstawową możliwość konfiguracji ograniczającą się do ustawienia częstotliwości sprawdzania aktualizacji (którą to funkcję można również wymusić niezależnie od ustawień) oraz możliwości pomijania numeru wersji przy opisach paczek przeznaczonych do aktualizacji. Nadto - gdy takie się pojawią - możliwe jest wywołanie pacmana i przeprowadzenie aktualizacji systemu. Dla osób korzystających z Plasma 5 oraz niekorzystających z Octopi to obecnie chyba jedyne takie narzędzie. Zainstalować je możemy albo przez mechanizm GHNS, albo za pomocą tzw. OCS-install, albo... wykorzystując taki PKGBUILD.

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. Bez tych programów, plasma-vault nie zbuduje krypt. Pierwszy z nich zainstalujemy z repozytorium, drugi musimy zbudować z AUR. Program integruje się z Plasma doskonale, rezyduje w tacce systemowej i to stąd mamy dostęp zarówno do tworzenia krypt, jak i ich obsługi. Program tak prosty w obsłudze, że nie wymaga chyba żadnego komentarza.

środa, 14 czerwca 2017

Kolorystyka aplikacji wykorzystujących kdelibs w Plasma 5

Kiedyś już pisałem co zrobić, by zmusić do działania LibreOffice, tak by respektowało kolorystykę ustawioną w Plasma. Niestety jednak nie zawsze to działa. Czas zatem na brutalne metody. Najpierw jednak chwila refleksji. Otóż LibreOffice jest aplikacją, która usiłuje się upodobnić do środowiska. Jeśli niczego nie zmieniamy i jeśli pracujemy w środowisku, które LibreOffice rozpozna jako KDE, to próbuje upodobnić się do... KDE4. Co zatem powoduje, że rozpoznaje to środowisko jako KDE? Otóż istnienie w systemie starej biblioteki KDE4 o nazwie kdelibs. Skoro tak, to ustawienia właśnie dla KDE4 będą respektowane przez LibreOffice (podobnie jak wszystkich innych aplikacji, które jeszcze nie zostały przeportowane do Qt5/KF5, jak choćby amarok). Teoretycznie sama Plasma winna zapewnić spójność wyglądu aplikacji KDE4/Qt4 z jej ustawieniami. Niestety nie zawsze jej to wychodzi. I tu właśnie pora sięgnąć po owe brutalne metody, o których wspomniałem. Przede wszystkim musimy sobie uświadomić gdzie są przechowywane ustawienia kolorystyczne Plasmy oraz aplikacji KDE4. W jednym i drugim przypadku jest to plik o nazwie kdeglobals, który jednakże w obu tych wersjach nieznacznie się różni. Natywne aplikacje KF5 wykorzystują plik znajdujący się w ~/.config/. Aplikacje KDE4 (i te, które z tych ustawień korzystają) poszukują tego pliku w ~/.kde4/share/config. Zasadniczo oba pliki w zakresie ustawień kolorystycznych winny być takie same. W przypadku wystąpienia różnic (np. LibreOffice ma odmienną kolorystykę), należy dokonać przekopiowania odpowiednich ustawień z pierwszego do drugiego pliku. Od tej chwili wszystko powinno być już w porządku.

Opowieść o tym jak baloo zżera zasoby komputera

Wraz z akonadi, to część KDE, który podawany jest zwykle jako argument na bezsensowność tego środowiska, jego przerośnięcie i ogromny apetyt na zasoby. Już nie tylko RAM, ale i CPU, którego potrafi zagospodarować np. cały jeden rdzeń. Komputer zwalnia, źle pracuje. Wszystkiemu oczywiście winne baloo. Czyżby? Nie na darmo mówi się, że największy błąd oprogramowania siedzi przed komputerem i z niego "korzysta". Ów element zwany użyszkodnikiem może jednak pomóc baloo. Kiedyś już pisałem o tym, jak można ustawić ten komponent. Także wyłączyć. Załóżmy jednak, że chcemy z niego korzystać i jednocześnie nie chcemy, by zużywał 100% rdzenia CPU, czy np. 1 (i więcej) GB RAM. Czy to możliwe? Oczywiście. U mnie np. baloo zużywa ok. 2MB RAM i zasadniczo pomijalny ma apetyt na CPU. Zwykle zużycie wynosi poniżej 1%, a najczęściej sobie śpi. Otóż częstą przyczyną nadmiernego zużywania zasobów przez baloo jest nakazanie mu indeksowania nieistniejących katalogów. W wielu dystrybucjach baloo jest domyślnie włączane. Jego pierwotnym ustawieniem jest indeksowanie katalogu domowego użytkownika wraz z wszystkimi podkatalogami. Jednocześnie nie indeksuje plików ukrytych, oraz niektórych typów plików. Indeksuje również nie tylko nazwy, ale i zawartość plików. W niektórych dystrybucjach, instalator zakładając konto użytkownika, jednocześnie stworzy w nim domyślne katalogi, które przyjmą angielskie nazwy. Wystarczy by użytkownik dokonał w jakikolwiek sposób (czy to programowo, czy też ręcznie) ich zmian np. na polskie odpowiedniki oraz jednocześnie wykasował zbędne już katalogi i wówczas baloo zaczyna mieć apetyt na olbrzymie ilości zasobów. Niestety baloo nie wie, że jakiś katalog został usunięty i próbuje go zindeksować. Podobnie będzie się działo również, gdy jakieś katalogi wykluczyliśmy z indeskowania, a następnie katalog ten został skasowany. Prosty trick polega na tym, by pamiętać o bardzo podstawowych zasadach: Kiedy zmieniamy nazwy, bądź kasujemy jakieś katalogi, które podlegają indeksowaniu, bądź też zostały przez nas z indeksowania wyłączone, to - wstrzymajmy albo nawet lepiej wyłączmy baloo, - po dokonaniu zmian w strukturze katalogów zmieńmy odpowiednio ustawienia w baloo, a w szczególności usuńmy zbędne, bo nieistniejące katalogi, które znajdują się w jego ustawieniach, - włączmy od nowa baloo i pozwólmy mu chwilę w spokoju ponownie zindeksować bazę. W ten sposób, po chwili, gdy dokona pierwszego (czyli nowego) indeksowania, gdzie w istocie zapotrzebowanie na zasoby może być widoczne (ale bez przesady, to w porywach 3 do 5% CPU mojego niezbyt wypasionego APU i nieco większe od wskazanego wyżej zapotrzebowanie na RAM), baloo stanie się praktycznie niewidoczny dla systemu. Pamiętajmy jednak o wykluczeniu z indeksowania zbędnych plików (czyli zbędnych katalogów bądź zbędnych typów).

sobota, 3 czerwca 2017

Hardcore - Kompilacja programu pod własny procesor, cz. 4 - cmake

Kontynuując ten mini cykl, pozostało mi jeszcze jedno narzędzie do automatycznego sterowania procesem kompilacji, które oporne jest na ustawienia makepkg.conf - jest nim często stosowany w "świecie" Qt - cmake. Dotychczasowe sztuczki nie pomagają. W zasadzie, to stosowne wpisy winny być umieszczone w pliku CMakeLists.txt i można byłoby się pokusić o wykorzystanie np. sed w tym celu. Wydaje się jednak, że istnieje prostrza możliwość. Problem jedynie w tym, że nie mam 100% pewności, że ona działa prawidłowo. W przeciwieństwie do innych, cmake nie informuje nas, czy kompiluje program z wykorzystaniem flag właściwych dla naszego procesora. Sztuczka polega na delikatnej ingerencji w PKGBUILD. Dodać musimy pewien wpis, w zasadzie w dowolnym miejscu przed budową programu. Ja do tego używam sekcji prepare, zatem stosowny, dodatek może wyglądać tak:
prepare() { export CFLAGS=-march=native export CXXFLAGS=-march=native }
I w zasadzie tyle. W powyższym przykładzie użyłem możliwości gcc "odgadnięcia" na jakim procesorze przychodzi mu kompilować program, czyli flagi native. Wówczas nawet nie jest konieczne ustawienie flagi mtune, albowiem sam kompilator przyporządkuje taką samą jak dla march. Oczywiście zamiast native można użyć konkrentej flagi dla naszego procesora oraz również wprowadzić zmienną mtune dla niego właściwą.