środa, 17 stycznia 2018

Transmission pozbawiony błędu CVE-2018-5702

Sieć przeszła informacja o dziurze w programie. Ba, nawet została okraszona informacją, że wstrętni twórcy tej aplikacji nie robią nic, a problem poważny, dotyczy bezpieczeństwa. Jak się okazuje problem został załatany. Fakt, w Archu (a zatem i w dystrybucjach pokrewnych) jeszcze nie ma nowej paczki z uwzględnieniem tego patcha. Problem został zgłoszony dzisiaj (17.01.2018), a zatem pewnie już niebawem zostanie poprawiony. Niemniej jednak używający transmission mogą się poczuć zaniepokojeni. Dla nich przygotowałem PKGBUILD, zbudowany w oparciu o tzw. nightly builds, które uwzględniają poprawkę bezpieczeństwa. PKGBUILD jest jedynie przebudowanym z oficjalnego repozytorium. Zmiany są następujące: - paczka źródłowa, na podstawie której budowana jest paczka dla Archa to "nighthly builds" (dokładnie uwzględniająca commit reb5d1a79cb, - usunięte zostały patche, które zostały nałożone w "nightly builds". Innych zmian nie dokonywałem.

wtorek, 16 stycznia 2018

Plasma 5.12 LTS Beta udostępniona

Z około dwutygodniowym opóźnieniem ukazała się wczoraj wersja Beta nowej odsłony środowiska graficznego Plasma. Oznaczona numerem 5.12 (w przypadku bety to 5.11.95) jest drugim wydaniem o przedłużonym wsparciu (18 miesięcy, o ile pamiętam). Oczekujący jakichś niesamowitych nowości muszą się poczuć zawiedzeni (choć nikt ich nie zapowiadał). Nowa Plasma nie jest bowiem niczym innym, jak po prostu kolejnym wydaniem poprawkowym dla całej serii Plasma 5. Usunięto część błędów, jakie pojawiały się w poprzednich wydaniach. Z rzeczy istotniejszych (bowiem owe błędy można naprawić nawet we własnym zakresie) wg zapowiedzi Plasma ma teraz jeszcze mniejszy apetyt na zasoby komputera. Jest to również pierwsze wydanie, gdzie możliwość pracy w sesji Wayland osiągnęło również status LTS. W tym ostatnim przypadku kilka informacji. Osoby, które używają kart graficznych NVidia nie uruchomią sesji Plasmy w Wayland na sterownikach zamkniętych. Część programów (choć to nie jest kwestia samego środowiska graficznego) ma też jakieś problemy w przypadku takiego korzystania (np. Kontact) i to nawet jeśli stosowne zmiany zostały już wprowadzone do kodu. Od wczorajszej nocy stosowne paczki trafiły już do repozytorium [kde-unstable] Archa. Możemy zatem je przetestować, zgłościć ewentualne błędy, tak by wydanie spodziewane w pierwszych dniach lutego (6.02. - także przesunięte o tydzień w stosunku do pierwotnego harmonogramu) było lepsze. Pamiętajmy, że paczki w [kde-unstable] są budowane na podstawie paczek z [testing]. Chcąc wypróbować to wydanie musimy zatem udostępnić również i to repozytorium. I jeszcze jedna uwaga - osoby, które zdecydują się na testowanie, winny raczej spróbować "czystej" sesji Plasma 5.12, a dopiero do niej "dokładać" swoje własne ustawienia, ulubione aplety. W ten tylko sposób będziecie wiedzieć czy ewentualny błąd leży w samej Plasma, czy też jest wynikiem działania jakiegoś apletu, widżetu, czy nawet niestandardowego wystroju. I jeszcze garść linków dla testerów: Ogólnymi wrażeniami z użytkowania można się podzielić w wątkach: na oficjalnym forum Archa oraz na naszym forum. Tutaj też uzyskacie (szczególnie na pierwszym) ewentualną informację odnośnie tego, czy błąd leży po stronie opiekunów Archa i coś zostało po prostu źle spaczkowane, czy też należy go zgłosić w KDE. Błędy należy zgłaszać: na bugzillach Archa poprzedzając informację przez dodanie [kde-unstable] (najlepiej) i/lub KDE. Pamiętajmy przy tym, że zgłoszenie błędu jako obserwacji zachowania najczęściej nic nie daje oraz o tym, że paczki Archa są budowane bez flagi Debug, która umożliwia "analizę przypadku". Najczęściej zatem trzeba będzie taką paczkę przekompilować, ale w tym zakresie otrzymacie już stosowną pomoc na obu forach.

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ąć.