piątek, 30 września 2016

Octopi z GIT w Archu - errata

Od czterech dni nie zbudujemy już octopi z GIT w Archu (ani w żadnym innym systemie) niezależnie czy będziemy używać PKGBUILDu dostępnego w AUR, czy też u mnie. "Winę" za taki stan rzeczy ponosi zmiana dokonana w kodzie programu, który obecnie jako swoją zależność wymaga również alpm_octopi_utils, czyli Alpm dla Octopi. Autor oczywiście stosowny kod zrobił, a nadto dostarcza również PKGBUILD dla niego. Wystarczy w zasadzie pobrać powyższej zlinkowany PKGBUILD, umieścić go w jakimś katalogu, a następnie zbudować i zainstalować paczkę przed budową Octopi.
Lekko zmienione PKGBUILDy dla Octopi udostępnię prawdopodobnie dzisiaj, choć po zbudowaniu wyżej wymienionej paczki i jej zainstalowaniu w systemie, wszystkie programy Octopi budują się prawidłowo.

EDYCJA:
Skrypty PKGBUILDów zostały zaktualizowane. Dostępne są z poprzedniego wpisu.

niedziela, 25 września 2016

Uruchamiamy program konsolowy w Plasma 5

Obecnie większość aplikacji dostarcza plik *.desktop, który potrafi zinterpretować każde środowisko graficzne, dodać go do menu i uruchomić. Programy konsolowe uruchamiamy najczęściej poprzez uruchomienie emulatora terminala (np. Konsole) i wpisanie tam odpowiedniej komendy. Niektóre programy konsolowe również dostarczają pliki *.desktop. Nic nie stoi na przeszkodzie stworzeniu takiego pliku samodzielnie. I wszystko byłoby cudownie, jednakże często próba uruchomienia takiego programu nie powoduje żadnej reakcji. Ot, jedynie - jeśli ktoś ma to tak ustawione - pooglądamy, że program próbuje się uruchomić, albowiem ukazuje się nam na pasku zadań ikonka, bądź poobraca się nam wskaźnik myszy i... tyle.
Problem daje się łatwo rozwiązać i jest znanym błędem w środowisku Plasmy. Otóż za uruchamianie aplikacji w pliku *.desktop odpowiada polecenie Exec. Dla programów graficznych ma ono (podstawową) strukturę następującą:
Exec=/usr/bin/aplikacja
W przypadku programów konsolowych, będzie to:
Exec=sh -c '/usr/bin/aplikacja'
Oczywiście mogą tu być jeszcze jakieś dodatkowe zmienne.
I tego ostatniego polecenia Plasma nie jest w stanie zinterpretować. Wystarczy jednak umieszczenie go w znaku cudzysłowia i wszystko wraca do normy. Chcąc zatem uruchamiać taki program konsolowy bezpośrednio z menu musimy doprowadzić ową linię do następującej postaci:
Exec="sh -c '/usr/bin/aplikacja'"
I wszystko winno już wrócić do normy.

piątek, 23 września 2016

Przyspieszamy czas tworzenia paczek

Nie, żadne magiczne ustawienia kompilatora. Nie o to chodzi. Program, który "steruje" kompilowaniem paczek zarządzanych przez pacmana, to makepkg. Jest on wykorzystywany nie tylko przy lokalnym tworzeniu paczek z jego pomocą, ale również chyba przez wszystkie tzw. helpery AUR. Program jest sterowany plikiem /etc/makepkg.conf.
Wewnątrz katalogu, w którym następuje budowa paczki, tworzone są dwa podkatalogi: src oraz pkg. W pierwszym następuje budowa (kompilacja) programu. Jeśli to zostanie wykonane bez błędów, skompilowany program wraz ze wszystkimi elementami niezbędnymi do jego działania umieszczany jest w katalogu pkg, którego wewnętrzna struktura odpowiada systemowi katalogów Archa (czy innej dystrybucji). Przynajmniej powinna odpowiadać. Następnie cała zawartość katalogu jest pakowana do pliku tar, który - jeśli domyślnych ustawień makepkg.conf nie zmienimy jest następnie kompresowany (np. do formatu xz. W ten sposób otrzymujemy znane nam paczki pacmana nazwa.pkg.tar.xz.
O ile jednak w przypadku paczek pobieranych ze zdalnych lokalizacji, ich kompresja ma sens, to w przypadku lokalnego budowania paczek na własny użytek, jak się wydaje mija się z celem. Nie tylko uzyskanie paczki trwa dłużej o czas kompresji (który może być całkiem znaczny - zobaczcie sobie ile trwa np. kompresowanie libreoffice-fresh-rpm), ale również wymaga dodatkowej przestrzeni dyskowej (albo zwiększa zapotrzebowanie na tę przestrzeń w tmpfs, co niekiedy prowadzi do zwrócenia informacji, że paczka nie została zbudowana, pomimo tego, że w istocie do formatu nazwa.pkg.tar to nastąpiło).
Tymczasem nieskompresowana paczka jest tak samo dobrze zarządzana przez pacmana, jak i paczka skompresowana. Jedyna różnica, to zabieranie większej ilości miejsca na dysku (jeśli ją tam zostawimy).
Jeśli zatem podzielacie moje spostrzeżenia, to możecie dokonać prostych czynności, które spowodują, że makepkg zaprzestanie kompresowania paczek.
W tym celu, dowolnym edytorem edytujemy plik /etc/makepkg.conf i odszukujemy w nim sekcję EXTENSION DEFAULTS, w której zmieniamy zawartość linii PKGEXT z:
PKGEXT='.pkg.tar.xz'
na
PKGEXT='.pkg.tar'
Od tej chwili makepkg będzie tworzył nieskompresowane paczki. Różnicę w czasie budowania sprawdźcie sobie na wpomnianym wcześniej libreoffice-fresh-rpm.

wtorek, 20 września 2016

KDE-BaseApps na KF5 (rozwiązanie tymczasowe)

KDE-BaseApps to zestaw kilku aplikacji, na które składają się  Konqueror, KFind, KPasswd, KeditBookmarks i KDialog oraz biblioteka libkonq. Portowanie ich do KF5 jest już na tyle zaawansowane, że w następnym wydaniu KDE Applications (16.12) pojawią się one już w takiej wersji.
Obecnie w Archu (Manjaro) można je zbudować z AUR, a stosowne paczki nazywają się konqueror-git, kfind-git, kpasswd-git, keditbookmarks-git,kdialog-git i libkonq-git, przy czym zawsze budują się wszystkie aplikacje składające się na paczkę "bazową" kde-baseapps-git.
Niestety, gdyby ktoś chciał obecnie ją zbudować, to się to nie uda. Makepkg nie wspiera częściowego budowania paczek z grupy składającej się na pkgbase. Tymczasem wciąż jeszcze istnieje paczka konq-plugins-git, która składa się na kde-baseapps-git, natomiast wraz z commitem 68782ee dotychczas rozdzielone konq-plugins zostało włączone do kodu konquerora. Zmianie uległy jednocześnie zależności, albowiem aplikacje te stały się wolne od kodu KDE4 (i to nawet za pośrednictwem kdelibs4support).
Do czasu, gdy arojas dokona odpowiednich zmian, chcącym zbudować te paczki proponuję sięgnięcie po nieco zmieniony PKGBUILD, który umożliwia ich budowę z aktualnymi zależnościami i oczywiście pozbawionych konq-plugins, które są "wbudowane" w konquerora. Tym razem PKGBUILD jest w pastebin, albowiem pochodzi on z mojego zgłoszenia konieczności zmian. Treść widoczną w pastebin należy skopiować jako RAW i zapisać w jakimś katalogu pod nazwą PKGBUILD.

EDIT:
Dzisiaj (22.09.2016) pojawiły się nowe wersje paczek składających na kde-baseapps-git. Proponowana przeze mnie zmiana nie jest już konieczna.

sobota, 17 września 2016

Jak nie używać IgnorePkg

Pacman - przynajmniej wg mnie - jest bardzo dobrym menedżerem pakietów. Jest też - za pomocą pliku /etc/pacman.conf - dość konfigurowalny.
Jedną z opcji, jaką możemy tam ustawić, jest ignorowanie aktualizacji paczki. Za funkcję tą odpowiada pole IgnorePkg. Tu możemy wpisywać nazwy paczek, których nie chcemy aktualizować.
Teraz muszę coś przypomnieć. Arch Linux jest tak pomyślany, że domyślnym i jedynie wspieranym sposobem aktualizacji, jest aktualizacja globalna. Aktualizujemy zatem cały system, a nie poszczególną paczkę. Także do wyjątków winna należeć systuacja, w której aktualizacja systemu nie obejmuje jakiejś paczki. O prawidłowość działania tego mechanizmu dbają opiekunowie systemu. Czasem jest lepiej - czasem gorzej, ale zaangażowania w prawidłowość działania systemu jako całości, nie możemy odmówić.
Powrócę zatem do ignorowania aktualizacji poszczególnej paczki. Jak wspomniałem należy to traktować jako wyjątek. Systemu z niezaktualizowaną paczką opiekunowie Archa nie przewidzieli. Ignorowanie aktualizacji jest natomiast przez niektórych użytkowników traktowane jako remedium na kłopoty z działaniem systemu. Nic w tym dziwnego - sposób jest nawet opisany w wiki Archa. Zastanówmy się jednakże, czy w każdym przypadku jest to wybór paczki przeznaczonej do ignorowania podczas aktualizacji systemu jest prawidłowy.
Przypomnijmy sobie jak jest konstruowany linux. Jakaś aplikacja zwykle czerpie z czegoś (bibliotek), które są dostępne również innym programom. Aplikacja X jest zatem zależna od biblioteki Y. Ta natomiast może być zależna od jeszcze innej itd. W Archu informacje o zależnościach - często - przekazywane są jedynie jako nazwy programów, bez podania wersji (fakt zdarzają się i takie sytuacje, ale sporadycznie). System wszak ma być zawsze zaktualizowany jako całość. Pół biedy zatem, jeśli do pominięcia przy aktualizacji wybierzemy jakąś paczkę, która jest niezależna od innych. Pół biedy - jeśli wybierzemy taką, która prawidłowo działa w oparciu o inną, jednakże w dość dowolnej wersji. Gorzej, jeśli do ignorowania przeznaczymy paczkę "ze środka".
Oczywiście przykładem będzie nowe środowisko od KDE. Jak wiecie składa się ono z 2 elementów: bibliotek, zwanych KDE Frameworks 5 oraz samego środowiska Plasma 5. Owe biblioteki budowane są w pewien hierarchiczny sposób. Do prawidłowego działania wszystkie wymagają oczywiście Qt 5 w odpowiedniej wersji minimalnej (obecnie - ze względu na Debiana jest to wersja, która jest w nim dostępna). Komponenty składające się na KF5 podzielone są na 3 poziomy (en. tier). Na poziom pierwszy składają się te elementy KF5, które nie są zależne od innych elementów KF5 oraz budowane wyłącznie o zależności w Qt5. Poziom 2 to elementy, których zależnościami są wyłącznie elementy z Poziomu 1 (oczywiście dalszymi zależnościami będą ich zależności). Poziom 3 to elementy zależne od tych, które należą do Poziomu 1 i 2. Oczywiście Poziom 2 zależy od Poziomu 1 w odpowiedniej wersji i podobnie Poziom 3 od odpowiedniej wersji Poziomu 1 i 2. Całość KF5 jest pomyślana natomiast w taki sposób, by zawsze działała jako całość. Wszystkie jej komponenty winny być w tej samej wersji. Elementów wyższych poziomów nie jesteśmy w stanie zbudować zarówno w nowszej, jak i w starszej wersji w stosunku do elementów z niższego poziomu (i to nawet, jeśli się zdarzy, że jakiś element nie został pomiędzy wydaniami zmieniony).
Podobnie dzieje się z Plasmą, która również budowana jest w oparciu o określoną wersję minimalną. Dla przykładu minimalne wymagania nadchodzącego wydania 5.8 to KF 5.26 oraz Qt 5.6.1. Są to wymagania minimalne, które oznaczają, że Plasma 5.8 będzie pracować z KF 5.26 oraz Qt 5.6.1, ale będzie pracować również z KF i Qt w wersjach wyższych niż te deklarowane, natomiast nie ma żadnej gwarancji prawidłowego działania z KF i Qt w wersji niższej. Gdybyśmy budowali to środowisko we własnym zakresie ze źródeł, to musimy mu zapewnić elementy, na których jest budowane przynajmniej w tych minimalnych wersjach. Inaczej budowa się nie powiedzie.
Wrócę do Archa i przypomnę to co napisałem na początku: Arch wspiera wyłącznie pełną aktualizację systemu, a nie aktualizację poszczególnych paczek w nim zawartych oraz zależnością jest "nazwa" określonej paczki, ale już - najczęściej - bez podania jej wersji. Powoduje to, że Archa można oszukać. Można sobie "skonstruować" taki system, w którym będą istniały wszystkie komponenty wymagane przez system, ale niekoniecznie już wszystkie one będą w tej samej (czyt. najnowszej) wersji.
Wprowadzanie do linii IgnorePkg poszczególnych paczek jest typowym zachowaniem osób, które na siłę chcą np. pozostawić sobie starszą wersję jakiegoś oprogramowania bądź też uznają, że jakaś paczka powoduje komplikacje w systemie. Nawet nie dochodząc tego, czy przez przypadek problem nie leży w niewłaściwej konfiguracji systemu.
Niestety, w przypadku takim jak opisany wyżej - ignorowanie aktualizacji poszczególnych paczek KF5 to prośba o destabilizację pracy całego środowiska. Im więcej tych paczek tam się znajdzie, tym bardziej praca w Plasmie będzie przypominać grę na loterii. To może "działać" (tzn. może nam się wydawać, że działa), ale wcale nie musi. Jeśli "działa", to oznacza wyjątkową odporność Plasmy.
Oczywiście opisany tu problem nie dotyczy wyłącznie Plasmy i KF5. Spotkamy się z nim praktycznie w każdym większym środowisku, które są pomyślane właśnie w taki sposób, by były budowane jako całość (w jednej wersji), na podstawie określonych bibliotek w określonych wersjach, które w tych samych wersjach winny być w systemie.
Wracając do środowiska KDE. Jeśli już musimy z jakichś przyczyn "zastabilizować" jego element, to wymaga to od nas odpowiedniej wiedzy i roztropności. KF5 winno być zawsze w tej samej wersji, zatem jeśli musimy mieć jakiś jego element w wersji wcześniejszej niż w repozytorium, to nie należy wpisywać tego elementu do IgnorePkg, ale całą grupę kf5 oraz kf5-aids przeznaczyć jako wyłączoną z aktualizacji i umieścić obie w IgnoreGroup. Jednocześnie wolno zignorować wyłącznie takie wersje KF5, które nie są wymagane do budowy Plasma 5 w określonej wersji. Oznacza to, że musimy mieć świadomość jakiej minimalnej wersji KF5 wymaga Plasma, a to powoduje, że musimy przeglądnąć zawartość plików CMakeLists.txt tej wersji Plasmy. Niekiedy będzie też może zajść potrzeba jej przebudowania w oparciu o KF5 znajdujące się lokalnie w systemie.
Pamiętajmy jednak, że ze względu na cykl wydawniczy KDE możemy w takim przypadku stracić możliwość wsparcia, zaś w przypadku Archa, gdy zgłosimy problem na jakimś forum, czy jego bugzilli, praktycznie jedyna porada jaką uzyskamy, to: zakutalizuj system.

piątek, 16 września 2016

Mój pierwszy AppImage - Google Earth

Program, który tym razem udostępniam, proszę traktować jako swego rodzaju test. Postanowiłem bowiem zrobić swój pierwszy AppImage. Z pewnych przyczyn wybór padł na Googe Earth. Wszelkie licencje (jeśli nie zostały umieszczone w środku - jeszcze się do AppImage nie przyzwyczaiłem) są na stronie programu.
Jeśli chcielibyście pomóc - to prosiłbym o ściągnięcie paczki, zapisanie jej w dowolnym miejscu. Po nadaniu plikowi AppImage atrybutu wykonalności, program uruchomimy w konsoli w taki sposób:
cd katalog_z_zapisanym_AppImage
./GoogleEarth-7.1.7.2600-x86_64.AppImage
Oczywiście, można sobie skrócić męki przepisywania tej nazwy, wystarczy użyć <Tab> po rozpoczęciu pisania.
Teraz jeszcze GoogleEarth.
Prosiłbym o informację, czy program uruchamia się, czy też nie, a jeśli nie to dane sprzętu, a przede wszystkim środowisk, w których przyszło program uruchomić.
Uwaga - jak na moje dotychczasowe "paczki" - ta jest całkiem spora, ok. 67MB.

EDIT:
Już widzę pierwszą rzecz. Paczka była tworzona w systemie, w którym nie było zenity, przez co pierwsze uruchomienie nie tworzy odpowiedniej pozycji z menu (innymi słowy nie wie co ma zrobić z *.desktop). Alternatywą dla zenity w systemach opartych o Qt jest qarma. Aby system widział ten ostatni program jako zenity musimy jeszcze zrobić dowiązanie dla niego do pliku /usr/bin/zenity.

Octopi a sprawa Arch Linux

Octopi jest dość popularnym i chyba najlepiej dopracowanym graficznym menedżerem paczek dla systemów zarządzanych przez pacmana. Obecnie octopi, to już nie tylko sam menedżer pakietów, ale również cały zestaw aplikacji, które pozwalają na śledzenie zmian w repozytoriach i informowanie użytkownika o pojawiających się nowych wersjach paczek zainstalowanych w systemie, zarządzanie listą repozytoriów (dokładnie ich listą w pacman.conf), czyszczenie cache pacmana itp. Pomimo tego, że pacman jest doskonałym narzędziem, to jednak w XXI w. chęć zarządzania swoim oprogramowaniem w wygodnej, graficznej formie, nie jest żadną fanaberią.
W przeciwieństwie do dystrybucji pochodnych, oraz np. KaOSa, czy Chakry, w repozytoriach Archa nie znajdziemy octopi (podobnie zresztą jak innych nakładek na pacmana). Skoro przyroda nie znosi próżni, to nic dziwnego, że stosowny skrypt (a nawet skrypty) budujące octopi znajdziemy w AUR. Co do zasady są takie dwa: octopi oraz octopi-git. Drugi z nich nie dostarcza wszystkich programów składających się na grupę octopi - pomija octopi-notifier, czyli oprogramowanie, które informuje o możliwych aktualizacjach oprogramowania. Pierwszy... Cóż, wydaje się, że opiekun PKGBUILDu niedokładnie go przemyślał. Otóż skrypt ten w istocie buduje całą gamę programów z grupy octopi. Ba, buduje nawet aż trzy programy octopi-notifier, oparte na trzech różnych bibliotekach (Qt4, Qt5 oraz KF5) i przeznaczone dla trzech różnych środowisk graficznych. I w tym leży problem. Ze względu na konflikt pomiędzy tymi trzema wersjami programu, paczki octopi wprawdzie zbudujemy przy pomocy jakiegoś wrappera AUR, ale ich nie zainstalujemy (być może taką możliwość daje bauerbill, ale nie próbowałem). Nadto jeszcze bezsensownie ściąga zależności konieczne do budowy każdej z tych paczek, pomimo tego, że nie są one nam potrzebne. Wersja Qt4 ściąga oczywiście całą grupę qt4, choć możemy sobie łatwo wyobrazić system wolny już od tego porzuconego oprogramowania. Wersja frameworks ściąga natomiast knotifications i wszystkie jego zależności (w praktyce całą grupę kf5 i jeszcze trochę). Nie sądzę, by te biblioteki były komuś potrzebne do szczęścia w środowisku innym niż Plasma 5. Ten ostatni problem pozostaje, gdy będziemy próbować zbudować octopi lokalnie z pomocą makepkg (tak wiem, niepotrzebne po budowie paczki można usunąć, jednakże po co powodować niepotrzebny ruch w sieci, co jest bardzo istotne dla osób o ograniczonych łączach).
Jeśli zatem dochodzicie do wniosku, że właśnie napiszę: PKGBUILD octopi w AUR jest bez sensu, to macie rację.
Prezentuję zatem dwa PKGBUILDy, które umożliwiają budowę zestawów odpowiednich dla Plasma 5 (to PKGBUILD.kf5) oraz dla innych środowisk (to PKGBUILD.qt5). Wersji Qt4 nie przedstawiam, albowiem może ona mieć znaczenie chyba wyłącznie dla osób, które korzystają jeszcze z KDE4, które nie jest już wspierane w Archu. Wszystkie inne środowiska graficzne, które są w repozytorium Archa oraz w AUR wykorzystują już Qt5 lub KF5. W środowiskach opartych o Gtk lepiej winno się natomiast sprawdzić inne oprogramowanie, jak np. pamac, czy tkPacman.
Jednocześnie, prezentowana przeze mnie wersja umożliwia budowę wersji deweloperskiej (z GIT), a nie wersji "stabilnej". Z tą ostatnią jest bowiem pewien szkopuł. Według twórcy tego oprogramowania, ostatnia wersja stabilna to 0.8.1. Niemniej jednak w dystrybucjach, które dostarczają octopi w repozytoriach, pojawiła się już wersja 0.8.3 (a w przypadku KaOSa to nawet 0.8.92). Takie samo oznaczenie nosi wersja w AUR. Repozytorium programu w GIT nie ma tak otagowanej wersji. Są one tworzone przez "uzupełnienie" wersji 0.8.1 do określonego commitu przez opiekunów tego oprogramowania w dystrybucjach. Zdaje się, że "ton" narzuciło tu Manjaro. W efekcie, gdybym chciał trzymać się prawidłowej wersji stabinej, to musiałbym ją zrobić w oparciu o 0.8.1 (jak wspomniałem, to jest wersja stabilna). Takie oznaczenie jednak, powodowałoby, że próba aktualizacji systemu (z AUR) narzuciłaby konieczność aktualizacji również octopi, albowiem w AUR jest wersja wyższa. Oczywiście nie ma przeszkód dla stworzenia wersji oprogramowania z dokładnie tym samym commitem, jaki jest uwzględniony w AUR. Nie widzę jednak sensu tworzenia bytów, które nie istnieją. Jeśli jednak znajdą się chętni na taką wersję, to jeśli sami nie będą w stanie stworzyć sobie PKGBUILDu, jestem gotowy pomóc.
Jeszcze drobna uwaga: paczka zawiera - jak wspomniałem - dwa PKGBUILDy o nazwach PKGBUILD.kf5 oraz PKGBUILD.qt5. Chcąc zbudować sobie octopi w wybranej wersji albo należy zmienić nazwę odpowiedniego pliku na PKGBUILD, albo wykorzystać możliwości makepkg i wykonać:
makepkg -p PKGBUILD.kf5 - dla Plasma 5
albo
makepkg -p PKGBUILD.qt5 - dla pozostałych środowisk
Oczywiście istnieją alternatywy dla proponowanego rozwiązania. Dla przykładu kuszącą propozycją wydaje się być wprowadzenie jednego PKGBUILD dla wszystkich paczek oprócz octopi-notifier i dwu PKGBUILD dla octopi-notifier, po jednym dla wersji Qt5 i KF5. Ze względu jednak na to, że wszystkie składniki octopi wykorzystują jeden kod źródłowy, takie rozwiązanie dwa razy ściągałoby kod programu. Są jeszcze inne, ale te wymagałyby ingerencji w PKGBUILD przez użytkownika. Najsensownie rozwiązanie wydaje się takie, by sam PKGBUILD prowadził do sprawdzenia, czy w systemie znajduje się knotications i wówczas budował wersję dla Plasma 5, a w przeciwnym przypadku wersję "pure-Qt5". Nie jestem jednak pewny, czy w innych środowiskach, jako zależność na pewno nie pojawi się knotifications, którego jednak środowisko to nie będzie potrafiło wykorzystać. Z tych powodów zatem prezentuję takie rozwiązanie jak wyżej.

EDIT:
Dzięki uwadze użytkownika marekmm, oba PKGBUILDy zostały lekko zmienione (usunięty został błąd przy octopi-notifier).

Wsparcie dla Plasma 5 w Linux Mint do 2021 r. - czylli dlaczego Mint nie jest najlepszą dystrybucją z Plasmą

Kiedyś powiedziałem sobie, że ten blog winien stronić od felietonów, polemik itp. Zmieniam jednak zdanie. W zasłużonym dla IT portalu dobreprogramy.pl pojawił się niedawno tekst: Linux Mint 18 KDE to najbardziej dopracowana dystrybucja z Plasmą. Może. Nie wnikam. Kilka minut pracy na tym systemie nie upoważnia mnie do jakiegokolwiek twierdzenia o "wyższości" tej dystrybucji nad innymi, choć...
No właśnie. Przyglądnijmy się co pod maską, co jest deklarowane i zastanówmy, czy Linux Mint 18 w ogóle można nazwać dystrybucją z Plasmą, a już na pewno, czy najbardziej dopracowaną.

Mint 18 KDE to Linux Mint 18 ze środowiskiem Plasma 5. Niby nic nadzwyczajnego. Każdy może zrobić sobie dystrybucję z Plasmą. W tym przypadku otrzymujemy "core" z Linux Mint 18, czyli de facto paczki systemu bazowego z Ubuntu 16.04, może nieco ulepszone, nieco oprogramowania własnego oraz... całe środowisko Plasma 5 (w tym frameworks, samo plasma oraz kde applications) z PPA Kubuntu Backports. De facto zatem, twórcy Linux Mint poskładali swą dystrybucję z obcych klocków, przy czym to co mnie najbardziej interesuje w kontekście "największego dopracowania" dystrybucji z Plasmą, to całość tego środowiska jest w nim "obca". Jak to działa? Otóż Linux Mint nie prowadzi dla swojej dystrybucji żadnych paczek z KDE, a to oznacza, że nie istnieje w niej żaden opiekun tak tych paczek, jak i środowiska. Całość KDE stanowią paczki bezpośrednio ściągane z repozytorium innej dystrybucji. Innymi słowy Linux Mint 18 KDE jest w zakresie środowiska KDE w całości uzależniony od tego co robią deweloperzy Kubuntu odpowiedzialni za PPA z backportami.
Mam zatem pytanie, czy za dopracowaną dystrybucję można uznać taką, która praktycznie nie oferuje, bo nie może, żadnego wsparcia dla środowiska z jakim się ukazuje.
Idźmy dalej. Specyfika wydawania nowego środowiska KDE polega na niezależnym tworzeniu trzech różnych jego elementów oraz ścisłym powiązaniu z Qt. Te trzy elementy to KDE Frameworks, Plasma oraz Applications. Każdy z nich ma swój cykl wydawniczy, przy czym - podobnie jak w przypadku LibreOffice - oparty on jest na czasie. Z góry wiadomo kiedy ukaże się nowa "wersja" środowiska, bibliotek i aplikacji, jak również z góry wiadomo kiedy ukażą się poprawki tej wersji. Jednocześnie przebiega proces tworzenia nowej wersji, która ukaże się w zamierzonym czasie. Uwaga: nawet wówczas, gdy nie wszystkie zgłoszone błędy zostały poprawione, nawet wówczas, gdy nie wszystkie zamierzenia zostały wykonane. Jednocześnie poszczególne elementy tego środowiska są tak konstruowane, że są przeznaczone do działania z określoną wersją pozostałych elementów. Często na przykład, by zbudować nowszą wersję środowiska konieczne jest udostępnienie mu nowszej wersji frameworks, czy nowszej wersji Qt. Przypomina to nieco rozwój ciągły. Jednocześnie każda z nowych wersji poszczególnych elementów składających się na KDE jest na bieżąco poprawiana i modernizowana. Naprawiane są również błędy. To oznacza, że np. użytkownik korzystający ze starszej wersji środowiska i dostrzegający w niej jakieś błędy może nie być świadom, że w nowszej wersji te błędy zostały usunięte. Powoduje to, że całe istnienie systemu zgłaszania błędów w KDE ma znaczenie tylko dla ostatniego wydania. Dochodzimy do sedna: w określonym czasie istnieje tylko jedno wydanie KDE i zawsze jest ono najnowsze.
Tymczasem Linux Mint 18 KDE w chwili powstania przynosi Plasmę w wersji 5.6.5, którą w KDE określa się jako "historyczną" i która miała premierę 14.06.2016 r. W chwili wydania Linux Mint 18 KDE wersja Plasmy nosiła numer 5.7.4. Co zatem chce osiągnąć "najbardziej dopracowana dystrybucja z Plasmą" udostępniając swoim użytkownikom wydanie, dla którego nikt nie organizuje już wsparcia?
A propos tego ostatniego - dochodzimy do clou problemu. Otóż zdaniem autora tekstu:
Po ponad dwóch miesiącach dostajemy wersję ze środowiskiem Plasma, która jest warta szczególnego zainteresowania choćby ze względu na zapowiedziany okres wsparcia – poprawki, łatki i uaktualnienia będziemy dostawać do 2021 roku.
Próbowałem się dowiedzieć od eimiego skąd czerpie tę wiedzę. Informacji nie otrzymałem. Prawdopodobnie zatem będzie to interpretacja słów Clema Lefebvre zawartych w informacji o wydaniu.
Linux Mint 18 is a long term support release which will be supported until 2021. It comes with updated software and brings refinements and many new features to make your desktop even more comfortable to use.
Zestawmy te wszystkie informacje ze sobą. Oto mamy dystrybucję, która na starcie przynosi historyczną wersję środowiska, nikt w niej nie jest odpowiedzialny za tworzenie paczek z tym środowiskiem, polegając w całości na paczkach z obcej dystrybucji, nikt też w tej dystrybucji nie odpowiada za jej rozwój, nie ma też wpływu na zmiany ewentualnych błędów w paczkowaniu. Mimo tego dystrybucja ta oferuje wsparcie dla Linux Mint 18 KDE do roku 2021 r. Z dalej idącego stwierdzenia eimiego wynika, że to właśnie w tej dystrybucji (jedynej na świecie) środowisko Plasma otrzyma poprawki, łatki i uakutalnienia do roku 2021 r.
Zejdźmy na ziemię. Jak na razie plany KDE sięgają kwietnia 2018 r. Wówczas skończy się wsparcie dla Plasma 5.8 (oraz prawdopodobnie dla Frameworks 5.26). W międzyczasie, w zwykłym trybie, powstawać będą nowe wersje Plasmy (czyli 5.9, 5.10 itd.) oraz Frameworks (już w przyszłym miesiącu ukaże się 5.27). Wiemy również, że na późną jesień br. planowana jest nowa wersja Qt 5, jak również, że istnieją plany stworzenia nowej wersji Qt 6. Następna wersja Qt z długotrwałym wsparciem jest oczekiwana za około 18 miesięcy. Nie wiadomo jeszcze czy będzie to wersja z linii 5 czy już 6. Zakładając jednakże, że będzie to wersja 5 to znów uzyska ona wsparcie. Prawdopodobnie na dalsze 18 miesięcy, czyli najdalej do końca roku 2019. Jeśli tak się stanie, to mniej więcej do tego momentu liczyć możemy na wydawanie Plasma 5 i jej wsparcie. Tyle wiemy, choć ostatnie informacje są późniejsze niż data proklamowania przez Clema Lefebvre wsparcia Linux Mint 18 KDE do roku 2021.
Teraz już tylko spekulacje, choć nie pozbawione pewnej wiedzy.
Dotychczasowy rozwój KDE, jak również pojawiające się w kodzie pewne "zajawki", pozwalają przyjąć z dużą dozą pewności, że z chwilą pojawienia się Qt 6 przystąpią do prac nad kolejną wersją środowiska KDE, które zostanie oznaczone numerem 6. Przez jakiś czas jeszcze będzie utrzymywana i wspierana wersja 5 (choć prawdopodobnie krócej niż miało to miejsce w przypadku KDE4 - dlaczego tak sądzę, to inna opowieść). Wraz z pojawieniem się Qt 6 wygaszane będzie wsparcie dla Qt 5, aż w końcu przestanie ono być wspierane. Jeśli te fakty nastąpią przed rokiem 2021, to wówczas nic nie jest w stanie zapewnić wsparcia Linux Mint 18 KDE.
Nie mówię tego gołosłownie. Przyglądnijmy się Linux Mint 17 KDE. Ta wersja zawiera KDE4 i ma wsparcie do roku 2019. Jak na razie nie istnieje żaden sposób zainstalowania Plasma 5 w tej wersji Minta. Nie istnieje nawet (przynajmniej oficjalna) możliwość aktualizacji Linux Mint 17 KDE do Linux Mint 18 KDE. Jednocześnie w sierpniu 2015 r. KDE4 zostało porzucone. Dalej wspierany jest wyłącznie jeden element tego środowiska, czyli kde-workspace. Będzie on wspierany tak długo, jak długo wszystkie aplikacje składające się na KDE Applications nie zostaną przeportowane do KF5. Potem i ten element zostanie porzucony. Istnieje możliwość, że stanie się to już w grudniu br., istnieje, że dopiero w kwietniu przyszłego roku. Nie powinno trwać dłużej. Żaden inny element tego środowiska wspacia już nie ma. Podobnie jak i Qt4, na którym jest ono oparte nie ma już wsparcia. Czy zatem twórcy Linux Mint przejęli kod KDE4 i Qt4? Stworzyli stosowny system zgłaszania błędów w tym środowisku? W końcu czy istnieje choć jedna osoba w gronie Linux Mint, która jest w stanie ten kod - w przypadku dostrzeżenia błędów - poprawić? Nie - nie pozostawię tych pytań retorycznymi. Pierwsze nie zostało dokonane, drugie również, a trzecie... skoro pierwsze dwa nie istnieją, to nawet zakładając, że pośród osób dbających o rozwój Linux Mint w wersji KDE istnieją osoby, które potrafiłyby to zrobić, to nie mają takich możliwości. Inna sprawa, czy gdyby w Linux Mint istniały takie osoby, to oddałyby całość środowiska w ręce innej dystrybucji? Pomimo zatem deklaracji, Linux Mint 17 KDE nie oferuje wsparcia (dla środowiska) do roku 2019. Tak samo tylko przypadkiem - gdy Plasma 5 w ogóle dotrwa do tych czasów - będzie mógł zaoferować (ale nie własnymi siłami) wsparcie dla Linux Mint 18 KDE do roku 2021. Dość mętnie zresztą tłumaczy się z owego wsparcia Plasmy do roku 2021 sam Clem Lefebvre.
Cóż - osobiście sądziłem, że tego typu deklaracje bez pokrycia - są w świecie wolnego oprogramowania obce. Zwłaszcza, że Linux Mint jest adresowany do osób najmniej doświadczonych w linuksowym świecie. Niestety słowa Lefebvre o wsparciu Plasmy do roku 2021, bez żadnej refleksji powtarzane w jednym z najpopularniejszych polskich serwisów, można między bajki włożyć.
I dlatego Mint z KDE nie będzie dla mnie nigdy dopracowaną dystrybucją z Plasmą. Ba, mam wątpliwości, czy w ogóle można to nazwać dystrybucją z Plasmą. Nie przeczę przy tym, że Linux Mint ze swoimi natywnymi środowiskami (Cinnamon i MATE) jest wartościowe.

czwartek, 15 września 2016

Plasma 5.7.95 (aka 5.8 Beta)

Właśnie ukazała się wersja testowa (beta) nadchodzącego wydania Plasma 5.8. Paczki zostały udostępnione również w repozytorium kde-unstable w Archu. Wszystkich zapraszam do testowania. Tylko w ten sposób jesteśmy w stanie pomóc, by Plasma była coraz lepsza.
Ze swej strony mogę napisać, że nie dostrzegłem żadnej niestabilności tego środowiska testowego. Oprócz deklarowanych nowości, usunięcia błędów, mogę stwierdzić, że działa ono zauważalnie szybciej.
Osobom, które chciałyby pomóc w testowaniu tego wydania Plasma w Archu, chciałbym przypomnieć, że środowisko to jest budowane na repozytorium testing zatem i ono winno zostać udostępnione oraz system winien być zakutalizowany do wersji paczek tam umieszczonych. W przypadku KDE plusem będą najnowsze paczki KDE Frameworks w wersji 5.26.
Nowa Plasma niesie ze sobą (oprócz usunięcia błędów) nieco zmian wizualnych oraz - ponoć, bowiem mi się tego nie udało uruchomić - "prawdziwe" wsparcie dla Waylanda.
Więcej o wydaniu dowiecie się pod tym adresem.
Uwagi dotyczące paczkowania (i funkcjonowania w Archu) należy zgłaszczać pod tym adresem.
Oczywiście namawiam na korzystanie z naszego forum. Tu również będziemy się starać pomagać w dostosowaniu Archa do nowego środowiska.

Otter-Browser #141

Bez wielu nowości, bez zbędnego komentarza: PKGBUILD.

środa, 14 września 2016

"KDE 5" coś się w końcu wyjaśnia

Dotychczas, w świecie KDE - przynajmniej w jego piątym wydaniu - żyliśmy wg ustalonego cyklu. Nowe wydanie KDE Frameworks pojawiało się co miesiąc, nowe "główne" wydanie Plasma 5 miało się pojawiać 4 razy do roku (ostatnio jednak rzadziej), zaś KDE Applications 3 razy w roku. Pierwsze "zamieszanie" wprowadziło wydanie Qt, które w wersji 5.6 uzyskało status tzw. LTS i to wydanie będzie wspierane przez 3 lata. Pomimo jednak tego, że Qt 5.6 jest LTSem, to "obok" wydawane są kolejne wersje. Obecnie mamy już 5.7, a w listopadzie spodziewane jest 5.8. Ba, przed końcem wsparcia 5.6 spodziewane jest wydanie już 6.0, które jednakże nie ma być takim skokiem "jakościowym" i "technologicznym" jak wydania Qt4, czy Qt5 i być niejako kontynuacją Qt5. Kolejna wersja LTS tego frameworka spodziewana jest w 2018 r.
To jest Qt, które stanowi podstawę budowania oprogramowania KDE.
Nie tak dawno pojawiła się informacja, że nadchodzące wydanie Plasma 5.8 będzie LTSem ze wsparciem do kwietnia 2018 r. Nic do tej pory nie było wiadomo o LTSie KF, czy też dalszym rozwoju Plasmy obok LTS w wersji 5.8.
Teraz coś się wyjaśnia.
Otóż KF5 w wersji 5.26 również ma stać się LTSem. Jest to jednocześnie minimalne wymaganie dla budowy Plasma 5.8. Samo KF 5.6 ma natomiast minimalne wymaganie w Qt w wersji 5.6. To oznacza, że do kwietnia 2018 r. będziemy mogli cieszyć się stabilną wersją środowiska pochodzącego od KDE, które nie będzie otrzymywać żadnych nowych funkcji, a jedynie poprawki błędów. To środowisko będzie się składać z Qt5.6, KF5.26 oraz Plasma 5.8. Jedyne zmiany funkcjonalności (czego po prostu nie obejmuje LTS) to "kompatybilność" z Waylandem.
Teraz jednak okazuje się, że obok LTS będą wydawane kolejne wersje KDE w swoim dotychczasowym cyklu. Oznacza to, że kolejne wersje KF5 będą się ukazywać co miesiąc (w październiku 5.7 itd.), na wiosnę przyszłego roku zobaczymy Plasmę 5.9 itd., aż do ukazania się Qt 6, które prawdopodobnie spowoduje powstanie "KDE 6", czyli - bowiem nic nie wskazuje, by ten model miał ulec zmianie - otrzymamy KF6 i Plasmę (KDE) 6. Model wydawniczy w wersji "5" będzie natomiast kontynuowany do końca wsparcia Qt5.

sobota, 10 września 2016

Naprawiamy brak możiwości uruchomienia programów GUI z uprawnieniami roota

Wraz z wprowadzeniem nowej wersji dbus (na pewno dotyczy wersji 1.10.10) przestały się uruchamiać programy z graficznym interfejsem użytkownika z uprawnieniami root. Problem dotyczy np. Plasmy oraz MATE i Cinnamona (nie wiem, czy innych środowisk również, ale nie wydaje mi się, by był im obcy). W przypadku uruchamiania bezpośrednio ze środowiska zobaczymy wyłącznie, że program chce się uruchomić (np. "skaczący" kursor), ale ostatecznie nie uruchamia się, a uruchamiając (przez sudo) w konsoli otrzymamy informację:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
"Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"
Oczywiście można twierdzić, że programy GUI w ogóle nie powinny być uruchamiane na uprawnieniach administratora, niemniej jednak nie jest to rozwiązanie. Niekiedy tego typu programy po prostu są wygodniejsze.
Do czasu, gdy problem nie zostanie rozwiązany mamy dwa obejścia problemu. Pierwszego nie polecam. Korzystacie na własne ryzyko. Może to doprowadzić do destabilizacji całego systemu. Obejściem tym jest instalacja paczki dbus-x11 z AUR. Raz jeszcze: nie korzystać z tej porady. Przedstawiam, bo gdzieś możecie znaleźć to rozwiązanie jako proponowane.
Do czasu rozwiązania problemu proponuję natomiast inne rozwiązanie, które wykorzystuje składniki systemu i według mojej wiedzy, nie powoduje żadnych niekorzystnych w systemie problemów i powikłań.
Zamiast zatem uruchamiać program w dotychczasowy sposób, uruchamiamy go wydając następujące polecenie:
kdesu dbus-launch nazwa_programu
lub
gksu dbus-launch nazwa_programu
ewentualnie
sudo dbus-launch nazwa_programu
Polecenie wydajemy w konsoli bądź - w przypadku Plasma - korzystając z Krunnera.

środa, 7 września 2016

Instalujemy paczki z nieoficjalnych repozytoriów

No właśnie: instalujemy? Ten wpis nie będzie w ogóle o tym, jak tego dokonać (jest to opisane w wiki Archa dość dokładnie), ale o tym, czy w ogóle warto to robić, kiedy i jakie niesie konsekwencje.
Lektura różnych forów czy blogów związanych z Archem, Manjaro i innymi dystrybucjami korzystającymi z rodowodu Archa pozwala na stwierdzenie, że niektóre osoby, w określonych sytuacjach, mają chęć dodawania do pacman.conf wpisów do tzw. nieoficjalnych repozytoriów. Tych ostatnich cała masa. Kusi i nęci zatem zamiast budowania czegoś ze źródeł korzystając z PKGBUILDu szybka instalacja programu z repozytorium.
Fakt, jest to dobre rozwiązanie, szczególnie dla programów, które się kompilują wieczność. Fakt, ale wyłącznie wówczas, gdy mamy zaufanie do twórcy i opiekuna takiego repozytorium.
Czy jest to jednak dobre rozwiązanie? Powiedzmy tak: i tak i nie. Dla świadomego użytkownika - jak najbardziej. Zwykle bowiem wie jakie i dlaczego repozytorium dodał, co chciał w ten sposób osiągnąć i przede wszystkim - wie jakie paczki mu się z tego repozytorium instalują, jak dowiedzieć się jakie paczki ma z określonego repozytorium oraz potrafi dojść do przyczyn problemów z aktualizacją systemu, konfliktującymi pakietami/plikami, zepsutymi zależnościami itd. Wie w końcu co zrobić w sytuacji, gdy system nie bardzo chce dalej pracować, aktualizować się itd.
Spora część użytkowników wprowadza jednak nieoficjalne repozytoria nie mając pojęcia co robi. Dotyczy to szczególnie osób, które z Archem, czy Manjaro (i pochodnymi) mają do czynienia bardzo krótki czas. Wielu z nich wprowadza te repozytoria bo chce mieć nowsze oprogramowanie (np. wówczas, gdy z jakichś powodów paczki w repozytoriach nie są aktualizowane pomimo tego, że oprogramowanie jest dostępne już w nowszej wersji - tak się działo niedawno np. z MATE) albo chce na siłę utrzymać oprogramowanie, które zostało porzucone w repozytoriach (tak jest w dalszym ciągu z KDE4).
Pamiętajcie zatem, że paczki umieszczane w repozytoriach nieoficjalnych mogą być budowane w inny sposób, niż te dostępne w repozytoriach danej dystrybucji. Przede wszystkim mogą być budowane na innych skryptach, niż te, które są używane w systemie. To oznacza, że mogą one mieć inaczej ustawione zależności. Mogą się w tych repozytoriach pojawić również dodatkowe paczki, które nie są w ogóle dostępne w repozytoriach oficjalnych, powiązane jakoś z tymi, które są w repozytoriach nieoficjalnych. Mogą w końcu jakieś źródła być inaczej paczkowane i zamiast jednej paczki będziemy mieć kilka lub odwrotnie. Jeśli osoba odpowiedzialna za budowę tych paczek w sposób właściwy ustawiła konflikty, informacje co dana paczka dostarcza, co zastępuje, to jeszcze pół biedy. Bardzo często jednakże otrzymujemy paczki zbudowane z przynajmniej jedną wadliwą informacją niesioną przez skrypty służące do budowy paczki w takim repozytorium.
I zaczyna być problem.
Dla przykładu weźmy jakąś "nowszą" wersję programu, od tej, która znajduje się w systemie. Zdarzy się często, że po jakimś czasie oprogramowanie w repozytoriach oficjalnych zostanie zaktualizowane. Ba, często będzie też aktualniejsze od oprogramowania w owych repozytoriach nieoficjalnych. Jednakże próba aktualizacji systemu prowadzić będzie do ciągu nierozwiązywalnych zależności, a w efekcie do braku możliwości zaktualizowania jakiegokolwiek programu (pamiętajmy, że Arch wspiera wyłącznie całościową aktualizację systemu, a nie pojedynczej paczki).
Oczywiście istnieje możiwość "odwrócenia" zaistniałej sytuacji i doprowadzenie do aktualizacji systemu. Zanim jednak przedstawię co należy wówczas zrobić, zastanówmy się nad postawionym na wstępie pytaniem. Oczywiście przedstawię wyłącznie swoje zdanie na ten temat (niby czyje miałbym przedstawiać). Nie uzurpuję sobie prawa do obiektywnych w tym zakresie opinii.
W moim przekonaniu reguła jest dokładnie taka sama, jak w przypadku instalowania czegokolwiek z pomocą AUR: jeśli nie wiesz, nie jesteś świadomy tego co robisz - nie rób. Jeśli nie wiesz w jaki sposób budowane są programy w takim repozytorium - nie wprowadzaj go do systemu. Jeśli nie wiesz jakie konsekwencje niesie za sobą instalacja paczek z takiego repozytorium - nie jest ono dla Ciebie. I w końcu - jeśli nie znasz na tyle Archa, by dać sobie radę z ewentualnymi problemami aktualizacyjnymi w przyszłości - nie wprowadzaj takich repozytoriów do systemu. Tylko i wyłącznie wówczas możesz je dodać, gdy stwierdzisz, że przedstawione wyżej problemy nie są Ci obce, dasz sobie radę w przyszłości, możesz się pokusić o dodanie nieoficjalnych repozytoriów do systemu i korzystać z nich. Inaczej sam się prosisz o problemy, destabilizację, a być może nawet - zepsucie systemu. Nadto jeszcze - w przypadku instalacji paczek w wersjach nieoficjalnych musisz trzymać rękę na pulsie i wiedzieć kiedy pojawi się nowa, już stabilna wersja takiego programu i podjąć odpowiednie kroki. Dla przykładu, część oprogramowania występującego w ramach tzw. kde-applications daje się już budować na KF5 i nadaje się do codziennego używania. Niemniej jednak w oficjalnych wydaniach tego zbioru aplikacji nie występują one jeszcze w takich wersjach. To nowe oprogramowanie często - dla odróżnienia od wersji w repozytoriach - miewa (podobnie jak ma to miejsce w AUR) inne nazwy paczek (np. okular i okular-frameworks-git). Gdy wejdzie już stabilne oprogramowanie do repozytoriów, taka paczka może - i najczęściej tak się stanie - pozostać w wersji "starszej", niż paczka oficjalna (w przypadku omawianego tu oprogramowania KDE dzieje się tak zwykle dlatego, że paczki *-kf5/frameworks itp. są budowane z gałęzi noszącej taką nazwę, która w przypadku wydania oficjalnej wersji opartej o KF5 jest łączona z gałęzią master; dotychczasowa gałąź nadal istnieje, ale nie jest już aktualizowana, bowiem akutalizacji podlega wyłącznie gałąź master; prześledźcie sobie np. rozwój gwenview w GIT KDE).
Jeśli jednak mimo wszystko zdecydujesz się na dodanie nowego repozytorium, to musisz wiedzieć co robić, gdy system przestaje się aktualizować, zaczynają występować problemy z instalacją paczek w systemie itd. itp.
Przyjąć należy, że deweloperzy tak Archa, jak i Manjaro (i pozostałych forków) wiedzą co robią i przynajmniej starają się dbać o to, by aktualizacja systemu wykonywana w dowolnym momencie była możliwa. Podobnie ma być możliwość dodania w dowolnym momencie jakiegoś programu do systemu i nie ma prawa wystąpić sytuacja, w której występuje jakiś problem z zależnościami. Gdy zatem próba aktualizacji, bądź instalacji jakiegoś programu powoduje informacje o braku możliwości ich dokonania, to jest to znak, że prawdopodobnie nasz system nie jest w pełni kompatybilny z oficjalnymi repozytoriami. Przyczyny - co do zasady - mogą być dwie (wykluczam dla ułatwienia błąd po stronie deweloperów):
- albo w systemie mamy jakieś oprogramowanie, które nie jest już dalej wspierane przez Archa (tak np. było z chwilą porzucenia KDE4 i przejścia wyłącznie na Plasma 5; ktoś, kto ma jeszcze KDE4 będzie miał problem z aktualizacją systemu),
- albo problem jest wywołany przez paczki wprowadzone do systemu spoza oficjalnych repozytoriów (może to również dotyczyć paczek zbudowanych z AUR).
Pierwsza sytuacja nie jest przedmiotem niniejszego wpisu, niemniej jednak zawsze należy ją rozważyć i wykluczyć. Z pomocą winny przyjść informacje, jakie pojawiają się na głównej stronie Archa (i Manjaro, a także innych dystrybucji).
Jeśli wykluczymy pierwszy z możliwych problemów, przyczyną braku możliwości aktualizacji systemu (czy nawet dodania pojedynczej paczki) szukać musimy raczej w owych "obcych" paczkach. Najczęściej objawi się to wpisem, że pacman nie mógł dokonać aktualizacji (instalacji) albowiem napotkał problem z zależnościami lub, że nie mógł zainstalować jakiejś paczki, albowiem jakieś pliki istnieją już w systemie.
Jeśli instalowane obecnie paczki są również w repozytoriach nieoficjalnych, które podłączyliśmy do systemu, to najprawdopodobniej tu leży przyczyna. W pierwszej kolejności należy zatem zewidencjonować paczki, które są zainstalowane z takiego repozytorium nieoficjalnego. Pomocne okazać się może polecenie:
pacman -Sl nazwa_repozytorium
Po jego wydaniu pojawi się lista paczek w repozytorium, ich wersji oraz informacja, czy dana paczka jest zainstalowana w systemie. Jeśli pośród tych zainstalowanych paczek znajdziemy choćby jedną, która bądź to ma być zainstalowana obecnie, bądź to "należy" do grupy oprogramowania, które chcemy instalować, to sugerowałbym w pierwszej kolejności odinstalowanie wszystkich tych paczek. Nawet bowiem jeśli paczka z repozytorium oficjalnego będzie mieć dokładnie taką samą nazwę i taką samą wersję jak paczka z repozytorium nieoficjalnego, to może się ona różnić skryptem, który ją zbudował i istniejącymi w nim informacjami np. o zależnościach. Oczywiście można sobie zautomatyzować odinstalowanie takich paczek. Polecam jednak ręczne wpisanie listy tych paczek, które wymagają odinstalowania (dbajmy przy tym w pierwszej kolejności o odinstalowanie jakichś metapaczek, albowiem to one są bardzo często powodem problemów). Dlaczego "ręczne", a nie automatyczne? Bowiem - może mi się wydaje - ale mam nad tym procesem większą kontrolę. Łatwiej widzę i ogarniam co się w systemie dzieje. Automat jest fajny, pod jednym warunkiem - robi dokładnie to co zostało zaplanowane i dokładnie to i tylko to, czego od niego chcę i oczekuję. Osobiście słabo ufam nawet najlepszym automatyzacjom działań na paczkach.
Po odinstalowaniu paczek z repozytoriów nieoficjalnych (oczywiście tych kolidujących, uniemożliwiających aktualizację, czy instalację), należy usunąć (bądź zakomentować) takie repozytorium w /etc/pacman.conf i doknać synchronizacji repozytoriów oraz akutalizacji systemu. Przed aktualizacją (a po synchronizacji repozytoriów), warto jeszcze wykonać polecenie:
pacman -Qm
Da ono nam odpowiedź na pytanie jakie paczki mamy zainstalowane spoza repozytoriów (czyli wyświetli wszystkie te paczki, których nie ma w repozytoriach umieszczonych w /etc/pacman.conf, w tym także te instalowane z AUR). Takim paczkom również należy się przyglądnąć. Tu pomocne będzie polecenie:
pacman -Qi nazwa_paczki
W wyniku jego działania dowiemy się m.in. jakich zależności wymaga określona paczka. Pamiętajmy jednak, że w Archu wyświetlane są co do zasady wyłącznie te zależności, które są wymagane bezpośrednio przez tę paczkę (np. jesli jakaś paczka należąca do KDE wymaga jakiejś paczki z KF5, to nie zostaną już wyświetlone zależności owej paczki z KF5, jak np. należące do Qt5, choć te ostatnie są wymagane do prawidowego działania paczki poddanej inspekcji). W ten sposób niekiedy uda się również wyśledzić, co jest przyczyną braku możliwości aktualizacji systemu.
Powinno działać.
Czy stosować zatem, czy nie nieoficjalne repozytoria - pozostawiam Wam, łącznie z odpowiedzą na pytanie na ile to jest bezpieczne.

Otter-Browser #140

Wydanie tygodniowe #139 nie ukazało się. Od dzisiaj mamy jednak wydanie #140. Wszystkie moje wcześniejsze uwagi, w szczególności dotyczące qtwebkitu preferowanego przez Twórców są nadal aktualne. Przypominam - tej wersji qtwebkit nie ma nawet w AUR. Jeśli ktoś chciałby z niej korzystać, to musi ją zbudować ze źródeł.
Teraz już wyłącznie formalność - nowy PKGBUILD z wersją 0.9.11.dev140.

niedziela, 4 września 2016

KShutDown 4.0 oparty o KF5

Nie tak dawno ukazała się 4 odsłona programu rozszerzającego możliwości opuszczenia systemu integrującego się ze środowiskami spod znaku Qt - KShutDown. Od dłuższego czasu istnieje możliwość budowy tego programu zarówno z wykorzystaniem starych bibliotek KDE4, jak i w oparciu o KF5 lub "czystego" Qt4 oraz Qt5 (o tym jeszcze niżej).
Z jakichś, niewytłumaczalnych dla mnie powodów, pomimo tego, że w Archu KDE4 zostało już dość dawno temu porzucone, program w repozytorium w dalszym ciągu znajduje się w wersji budowanej w oparciu o KDE4 (dokładnie o kdebase-runtime, które oczywiście w dalszym ciągu w repozytoriach jest).
Już wcześniej przedstawiłem PKGBUILDy dla rozwojowej wersji 3.99.x. Obecnie zatem dla stabilnego już wydania 4.0. Prezentowany PKGBUILD buduje paczkę wykorzystując KF5, a zatem sens budowy programu w takiej wersji istnieje dla osób, które używają Plasma 5. Osoby, które korzystają np. z LXQt, Lumina, Hawaii czy Papyros winny raczej zbudować wersję opartą o "czyste" Qt5. Jeśli ktoś jeszcze korzysta z jakiegoś środowiska opartego o Qt4 (nie jest mi znane), wówczas winien skorzystać z możliwości budowy programu na Qt4 (jeśli będzie taka potrzeba, to pomogę w PKGBUILDzie choć nie widzę większego sensu dalszego wspierania Qt4).
Teraz słów kilka o wersji Qt5. Owszem, program buduje się w takiej wersji. Niemniej jednak nie ze skryptu Setup-qt5.sh, który jest dostarczany wraz z programem. Ten skrypt wywołuje jedynie inny skrypt, a mianowicie Setup.qt4.sh, który jak się można domyślić, buduje wersję opartą o Qt4. Budowę trzeba zatem przeprowadzić przez cmake i włączyć opcję KS_PURE_QT. Niemniej jednak wymaga to jeszcze dopracowania przeze mnie. Szczerze, używając Plasma 5 nie mam potrzeby budowania aplikacji na "czystym" Qt5. Niemniej jednak, jeśli będzie zaintersowanie z Waszej strony, to dokończę skrypt również dla takiej wersji.

PS: Poprawiony PKGBUILD. Poprzedni nie uwzględniał extra-cmake-modules w makedepends.