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.