piątek, 9 listopada 2018

A jak alias

Wielu użytkowników linuksa narzeka na straszliwą konieczność pracy w konsoli. Na to, że wszystko tu trzeba wpisywać itd. itp. i bez tego ani rusz, a polecenia konsolowe to katorga dla "normalnego" człowieka. I kto by spamiętał to wszystko.
Pomijam prawdziwość twierdzenia o konieczności wpisywania wszystkiego w konsoli. Obecne środowiska graficzne i programy dla nich, oferują spore możliwości praktycznie kompletnego pominięcia używania poleceń konsolowych. Niemniej jednak z różnych przyczyn może okazać się, że korzystanie z konsoli dla określonych zastosowań jest albo jedyną możliwością, albo po prostu bywa wygodniejsze.

Niemniej jednak sam zauważam, że niektóre polecenia są zbyt długie, by je spamiętać. Ot, choćby:
# reflector --verbose --country 'Poland' -l 5 -p http --sort rate --save /etc/pacman.d/mirrorlist
Oszczędźmy naszą pamięć. Z pomocą przychodzi nam "alias", dzięki któremu w swoim środowisku możemy przyporządkować w zasadzie dowolne ciągi znaków pod łatwiejszą do zapamiętania nazwę, w dodatku łatwo zawsze dostępną. Jeśli nie zdarzy się kataklizm, sami nie skasujemy takiego aliasu, to raz zdefiniowane będzie funkcjonować wiecznie.
Zamiast zatem ww. ciągu możemy wstawić dowolną inną nazwę, np. mirror (to wyłącznie przykład). Wówczas po wpisaniu w konsoli wyrazu: mirror, system (a w zasadzie, to bash), sam podporządkuje przypisane mu polecenie i je wykona.
Jak to zrobić?

Zaczynamy od otwarcia w dowolnym edytorze tekstu plik ~/.bashrc (jeśli korzystamy z bash) i dopisujemy ciąg, który ma postać:
alias nazwa='polecenie'
Opierając się na przywołanym poleceniu reflectora, będzie to wyglądać następująco:
alias mirror='sudo reflector --verbose --country 'Poland' -l 5 -p http --sort rate --save /etc/pacman.d/mirrorlist'
które po wpisaniu w konsoli polecenia: mirror - podmieni nam listę serwerów źródlanych udostępnionych w systemie na taką, która jest ograniczona do pięciu najbardziej aktualnych polskich serwerów (akurat pięciu serwerów w Polsce nie ma) i posortuje je w kolejności od oferowanej najwyższej szybkości transferu.

Poprzedzające polecenie reflector, sudo pojawia się tutaj, z uwagi na to, że winno ono zostać wykonane z uprawnieniami administratora. Jeśli jakieś polecenie tego nie wymaga, to oczywiście je pomijamy.

Po zapisaniu pliku .bashrc musimy jeszcze poinformować bash o wprowadzeniu zmian, co zrobimy poprzez wydanie w konsoli polecenia:
source ~/.bashrc
W przeciwnym przypadku będzie ono dostępne dopiero od następnej sesji.

Jak nam się polecenie znudzi, bądź uznamy, że inne będzie dla nas łatwiejsze do zapamiętania, to po prostu zmienimy alias w ~/.bashrc.

Zwracam jednak uwagę na jedną rzecz. Aliasem można zmienić domyślne działanie polecenia, o czym system nas nie poinformuje. Dla przykładu, jeśli z jakiegoś powodu chcielibyśmy dać taki alias:
alias ls='sudo pacman -Syu'
to "stracimy" w systemie polecenie ls, a w jego miejsce pojawi się komenda, która zaktualizuje nam system. Z drugiej strony, w ten sposób możemy zmodyfikować domyślne działanie jakiegoś polecenia, o ile nam na tym zależy, czyli dla przykładu dodać kolorowanie do wyników poleceń (bo to akurat bezpieczne - nie zmieni nam działania programu, a jedynie uczyni go czytelniejszym).

Tak czy inaczej - ostrożności nigdy za wiele.

Co na prawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekazywane są pacmanowi.
Otóż zakładając, że paczki w repozytoriach budowane są prawidłowo, a nie mamy żadnej podstawy twierdzić inaczej, to w danym momencie, w repozytorium, które jest w 100% zsynchronizowane z głównym repozytorium Archa są paczki, które zostały zbudowane na podstawie swoich zależności, które są wymagane do poprawnej ich  pracy. Z drugiej strony paczki - jeśli to nie jest bezwzględnie wymagane - nie zawierają informacji o tym w jakiej wersji ma być jakaś paczka, od której są zależne. Taka informacja nie jest też przekazywana pacmanowi w żaden sposób.
Jeśli zatem wykonamy czynności, jakie opisałem na wstępie, to może się zdarzyć, że zostanie zainstalowana paczka w wersji, która wymaga swojej zależności również w określonej wersji. Jeśli owa zależność w systemie będzie już zainstalowana, to nie zostanie zaktualizowana. Efekt łatwy do przewidzenia - system będzie działać wadliwie.

Prawidłowo zatem w każdym przypadku:
pacman -Syu

2. Instalacja paczki bez aktualizacji systemu
Przeczytawszy poprzedni punkt już chyba wszystko wiadomo - instalacja paczki poprzez:
pacman -S paczka
nie ma żadnego sensu. Albo operacja taka się nie uda, albo wywoła skutek jak poprzednio, czyli dopuścimy się częściowej, a niewspieranej, aktualizacji systemu przy okazji instalacji jakiejś paczki. Oczywiście w niektórych przypadkach może się zdarzyć, że wszystko przebiegnie prawidłowo. To jednak przypadek.
Zasadniczo w opisany wyżej sposób można instalować paczkę, jeśli jesteśmy pewni, że od ostatniej synchronizacji baz pacmana z repozytorium oraz aktualizacji systemu w repozytoriach nie pojawiły się nowe wersje paczek, które mamy już zainstalowane w systemie. Zdecydowanie lepszym sposobem, a już zawsze, gdy dość dawno nie dokonywaliśmy aktualizacji systemu jest:
pacman -Syu paczka

3. Aktualna lista serwerów źródłowych
No właśnie, pacman wypisuje różne komunikaty, a bardzo często pozostają one bez żadnej reakcji. Zadowalamy się, że "aktualizacja się powiodła". W zakresie opisywanym jeden z częściej popełnianych błędów jest związany z aktualizowaniem paczki pacman-mirrorlist. Ta paczka jest dość często aktualizowana i przynosi ze sobą wyłącznie jeden plik mirrolist, który zawiera aktualną na dzień wydania listę serwerów źródlanych Archa. Jeśli jednak w systemie istnieje już plik /etc/pacman.d/mirrorlist, to aktualizacja tej paczki powoduje jedynie wgranie do tej lokalizacji nowej listy, ale pod nazwą mirrorlist.pacnew, który to plik oczywiście nie jest "czytany" przez pacman podczas aktualizacji systemu. Jeśli zatem nie dokonamy zmiany nazwy tego pliku na mirrorlist to system nadal będzie się "aktualizował" z serwerów źródlanych, które mogą nie być już aktualne. Pamiętajmy przy tym, że pacman "czyta" listę udostępnionych mu serwerów w kolejności wskazanej w pliku /etc/pacman.d/mirrorlist i po nawiązaniu udanego połączenia z pierwszym serwerem z listy "zadowala się" nim i to z niego następuje aktualizacja, nawet jeśli serwery umieszczone poniżej są aktualniejsze.
Pamiętajmy również, że sama zmiana nazwy mirrorlist.pacnew na mirrorlist nic nie da albowiem wszelkie serwery na tej liście są zakomentowane. Musimy usunąć znak "#" sprzed nazwy Server.
Osobiście dla odnawiania listy serwerów stosuję jednak program reflector z taką listą poleceń:
reflector --verbose --latest 5 --sort rate --save /etc/pacman.d/mirrorlist
W ten sposób dostarczanych mi jest do systemu pięć najświeższych serwerów posegregowanych od tego, który spośród nich oferuje najszybszy transfer do najwolniejszego. Oczywiście można sobie zrobić dla takiej komendy jakiś alias, bo będzie wygodniej.
Oczywiście to nie jedyne sposoby, gdyż z pierwszej strony Archa w sekcji Tools możemy znaleźć przydatne narzędzia do sprawdzania i generowania listy serwerów, a nadto są inne jeszcze narzędzia od reflectora.

4. Bezsensowne ignorowanie aktualizacji paczek
Dość częstą praktyką jest dodawanie do pacman.conf jakichś paczek, bo nam się wydaje, że lepiej będzie tak działać. Oczywiście, że można, ba nawet niekiedy trzeba, ale... Zwróćmy uwagę na to jak są budowane paczki w Archu. W danym momencie, w repozytorium winny znajdować się paczki, które umożliwiają poprawną pracę w tym systemie. Oznacza to m.in., że te, które ze względu na jakieś swoje zależności wymagają przebudowania, zostały przebudowane po wprowadzeniu do repozytoriów nowej wersji swej zależności. Jeśli zatem z jakiegoś powodu do IgnorePkg dodamy którąkolwiek z tych paczek, to jesteśmy na dobrej drodze do spowodowania, że system będzie działać wadliwie. Jeśli zatem już umieszczamy coś w IgnorePkg to róbmy to z głową i na pewno nie umieszczajmy tu niczego ze względu na jakąś paczkę budowaną z AUR. To paczka z AUR ma być dostosowana do paczek systemowych, a nie odwrotnie.

Krótko mówiąc - można wszystko, ale róbmy to z głową.

czwartek, 4 października 2018

Jak uniknąć problemów z Antergosem

Przyglądając się problemom, jakie dostarcza Antergos wielu użytkownikom od kilku lat, spróbuję zestawić w punktach kilka porad, które zminimalizują najczęściej występujące z nim kłopoty.

1. Usunięcie plików *-meta.
Niemal wszystkie instalacje (pierwsze) Antergosa odbywają się z użyciem tzw. meta paczek. To jeden ze sposobów instalacji zespołu większej ilości programów w Archu. Meta paczki nie zawierają żadnych binarek. Są to jedynie paczki niosące informacje o tym, że jakieś paczki mają zostać w systemie zainstalowane. Treść PKGBUILDów takich paczek zawiera w polu depends listę paczek do zainstalowania. Taka instalacja powoduje, że późniejsza próba odinstalowania jednej z paczek umieszczonych w depends pociągnąć za sobą może chęć odinstalowania "połowy" systemu, albo spotkamy się z informacją o tym, że odinstalowanie czegoś nie jest możliwe.

Rozwiązanie
Po zainstalowaniu Antergosa, przeszukujemy system pod kątem zainstalowanych paczek z "meta" w nazwie. Ich nazwy wyglądają w następujący sposób "nazwa_czegoś-meta-dalsza_charakterystyka_paczki", ot choćby - instalując całą Plasmę w ten sposób mamy paczkę "plasma-meta".
Wyszukujemy u siebie:
pacman -Qs metaTeraz odinstalować należy każdą z tak znalezionych paczek.

Uwaga
W ten sposób pozbywamy się nałożonego nam kagańca, ale z drugiej strony istnieje łatwość odinstalowania paczek niezbędnych systemowi. O ile odinstalowanie jakiejś aplikacji, która wcześniej była w pliku "meta" nie stanowi już problemu i nie zrobi w systemie niczego złego, to już nad odinstalowaniem komponentów środowiska należy się zastanowić dwa razy i w razie wątpliwości spytać.

2. LightDM
Antergos używa LigthDM jako menedżer logowania. Wymyślony niegdyś w Canonical DM nie jest obecnie intensywnie rozwijany (Ubuntu i pochodne z niego zrezygnowały), co powoduje, że niekiedy możemy się spotkać z problemami po aktualizacjach systemu (nie oznacza to, że z innym DM nie będzie). Dodatkowo LigthDM uniemożliwia sesję w Wayland tych DE, które już mają taką możliwość (np. GNOME, Plasma). Problematyczny jest również jego oparty o technologię webową greeter. Możecie zatem rozważyć sobie zmianę tego DM na inny. Jedyna zaleta, to efekt estetyczny dla domyślnych tematów środowisk wspieranych przez Antergosa.
Proponuję dla środowisk:
a. GNOME - GDM
b. Plasma, LXQt (inne oparte o Qt5, jak choćby Lumina) - SDDM
c. Xfce4, MATE, Cinnamon (inne oparte na Gtk) - LXDM

Zmiana odbywa się w kilku ruchach:
1. Należy znaleźć odpowiedni DM w repozytorium i go zainstalować w systemie np.
pacman -Syu sddm2. Uruchamiamy nowy DM, np.:
systemctl enable sddm -f3. Restartujemy DM (uwaga nastąpi wylogowanie, zapiszcie co potrzebujecie) np.:
systemctl stop lightdm(w tym momencie winno nastąpić wylogowanie i system winien uruchomić się z wybranym, nowym DM).

3. Paczki z repozytorium AntergosW repozytorium Antergosa od czasu do czasu znajdują się paczki, których nie ma w repozytoriach Archa (z których Antergos bezpośrednio korzysta), ale są w AUR. Często paczki tu oferowane są tak konstruowane, by tzw. aur-helpery nie chciały ich aktualizować z AUR. Niestety rozwiązania przyjęte w Antergos nie są najlepsze i najlepiej skorelowane z Archem i AUR w tym zakresie. Otóż, gdy paczka z AUR przejdzie do repozytorium Archa jest od tej chwili aktualizowana przez jego zespół. Nie ma znaczenia, czy ta paczka, wcześniej budowana z AUR w repozytoriach Antergosa jeszcze istnieje, czy też została już usunięta. W naszym systemie pozostajemy z paczką starszą niż dostępna, która jest jednocześnie widoczna jako nowsza (to użycie epoch w PKGBUILD, co dla Was nie ma znaczenia) - pacman takiej paczki nie zaktualizuje. Jeśli zatem zobaczycie w systemie coś takiego (przykład z innego wątku):
ostrzeżenie: pepper-flash: local (1:26.0.0.137-1) jest nowsze niż extra (31.0.0.108-1)to oznacza, że spotkaliście się z takim problemem. Ostrzeżenie musi mieć taką postać:
a. wskazywać, że lokalna (local) paczka jest nowsza niż w repozytorium (extra, core, community, multilib),
b. numer wersji paczki "nowszej" musi mieć postać "1:jakieś.liczby",
c. numer wersji paczki w repozytorium musi mieć postać "jakieś.liczby",
d. "jakieś.liczby" z paczki w repo muszą mieć wartość większą (>) niż "jakieś.liczby" paczki lokalnej.
Spełnienie łącznie powyższych warunków oznacza, że wbrew ostrzeżeniu (ważny jest ppkt. b), paczka w repozytorium jest nowsza niż lokalna.
Dokonujemy instalacji tej paczki:
pacman -Syu paczka
4. Repozytoria AntergosaTu już sobie sami mocno rozważcie. Osobiście uważam, że lepszym rozwiązaniem jest ich przeniesienie na koniec listy repozytoriów udostępnionych w /etc/pacman.conf. Twierdzę tak dlatego, że niekiedy twórcy Antergosa nie nadążają z aktualizacjami swoich paczek względem paczek w Archu. Stosując się do tej porady dalej będziecie mieć dostępne paczki (tam ich jest 5 na krzyż) z Antergosa, ale bez kłopotów z aktualizacją całego systemu z Archa. Jeśli takie kłopoty wówczas napotkacie, to diagnoza gdzie szukać jest prosta.
Bezwzględnie to zalecam, jeśli Antergosowi udostępniliście repozytoria testowe Archa. 

czwartek, 20 września 2018

Przyciski OK i Anuluj aplikacji Gtk jak w Qt

Przyciski potwierdzenia lub wycofania się z jakiejś operacji (OK/Anuluj) w oknach dialogowych aplikacji zbudowanych w oparciu o Gtk są zamienione miejscami w stosunku do standardowych okien w środowiskach korzystających z Qt. Oprócz pewnego dyskomfortu, kwestii estetyki, przede wszystkim skutkuje to gorszą organizacją pracy. Na całe szczęście można to w prosty sposób zmienić.
Jeśli korzystamy z aplikacji zbudowanych na Gtk+2.x musimy dokonać edycji pliku ~/.gtkrc-2.0, jeśli korzystamy z aplikacji zbudowanych na Gtk+3.x edytujemy plik ~/.config/gtk-3.0/settings.ini, w obu przypadkach dodając linię: gtk-alternative-button-order = 1. To powinno wystarczyć, by we wszystkich aplikacjach wykorzystywanych w środowiskach zbudowanych na Qt (np. Plasma, LXQt, Lumina) miejsca przycisków OK oraz Anuluj były w tych samych miejscach.

Na podstawie porady z BBS Arch Linux.

wtorek, 4 września 2018

Są manadynki i są truskawki - Strawberry

Znany i lubiany odtwarzacz Clementine utknął od dwu lat na wersji 1.3.1, która sama w sobie nie jest zła, ale w dalszym ciągu oparta jest o Qt4. Wprawdzie rozwój nowej wersji na Qt5 trwa już dłuższy czas i jest ona raczej bezproblemowo używalna, to jednakże i tu niewiele się dzieje ostatnio, by przybliżyć wersję opartą o nowszy framework. Dla tych, którzy chcą się pozbyć w końcu Qt4 ze swoich systemów istnieje zatem opcja w postaci instalacji clementine-qt5-git (wraz z kilkoma odmianami, które już niekoniecznie są do znalezienia w AUR), albo...

Od jakiegoś czasu współpracujący z projektem Clementine Player, Jonas Kvinge rozpoczął prace nad forkiem tej aplikacji, która od początku powstaje w oparciu o Qt5 - jest nią Strawberry. I choć napisałem, że "truskawka", to jednak autor odwołuje się do inspiracji nazwą zespołu The Strawbs (mam nadzieję, że o ten zespół mu chodzi, a nie o inny, o takiej samej nazwie).

Mamy zatem nowy, o niewielkich wymaganiach odtwarzacz Strawberry, którego wygląd jest bliźniaczy do Clementine/Amarok 1.4. Obecna wersja to 0.2.1 i raczej wskazuje na dość wczesny stan swego rozwoju. Niemniej jednak jest ona już w pełni funkcjonalna. Przynajmniej jako podstawowy odtwarzacz plików audio. Nie oferuje np. streamingu stacji internetowych. Jeśli zatem ktoś tego wymaga, to niestety tu jeszcze takiej funkcjonalności nie znajdzie. Aplikacja dostępna jest także wyłącznie w języku angielskim.

Ci, którzy chcieliby wypróbować mają do wyboru wydanie 0.2.1 oraz dwie wersje rozwojowe: "zwykłą" oraz "full". Różnice między tymi dwiema widać będzie praktycznie wyłącznie, gdy zbudujemy je na tzw. cleanchoocie lub gdy w systemie nie będziemy mieć xine i/lub vlc. Otóż Strawberry w pełni wykorzystuje jedynie silnik gstreamer, aczkolwiek możliwym jest również wykorzystanie xine oraz VLC. Budując na cleanchroot wersje 0.2.1 lub jej odpowiednik z GIT otrzymamy taką, która będzie bazować wyłącznie na gstreamer, podczas, gdy wersja "full" wykorzysta wszystkie możliwe. W wolnym czasie postaram się wrzucić do POLAUR inne wersje PKGBUILD, które lekko inaczej będą próbowały budować tę paczkę.

A teraz zachęcam do testowania.

czwartek, 16 sierpnia 2018

LibreOffice 6.1

Z różnych powodów nowe wydanie chyba najpopularniejszego pakietu biurowego open source jest ważne. W wielu miejscach, nawet w popularnych serwisach, które nie zajmują się tematyką komputerową na co dzień, zostało to opisane. Czuję się zatem zwolniony z obowiązku opisywania tego po raz kolejny. Chętnych do zapoznania się ze zmianami odsyłam do ich listy. Pozwalam sobie napisać o tej nowej wersji jednakże z innego powodu i z punktu widzenia osoby używającej Plasma 5 jako podstawowego środowiska graficznego w moim systemie. Otóż w końcu zaimplementowana została obsługa wtyczki VCL, która uwzględnia i współpracuje z Qt5. W przypadku wykrycia przez LO, że uruchomienie następuje w tym środowisku ładowana jest wtyczka gtk3_kde5, która oferuje pewien zakres wsparcia dla zintegrowania się pakietu w Plasma 5. Podstawowym VCL pozostaje gtk3 i na nim owa wtyczka jest oparta. Z częścią konsekwencji z niej wynikających. Otóż dzięki działaniu wtyczki, LO uzyskuje natywny dostęp do okien dialogowych Plazmy. Dla osób pracujących w tym środowisku to duże ułatwienie, bowiem okna dialogowe aplikacji Gtk+3 są zupełnie inne, co zwykle powoduje konieczność zmiany przyzwyczajeń dla jednego tylko programu. Z drugiej strony jednak, konsekwencją przyjętego rozwiązania jest to, że cały wystrój pakietu czerpany jest z ustawień Plazmy dla aplikacji Gtk3 (wyjątkiem są ikony, które można zmieniać wyłącznie dla tego pakietu). Również z jego konsekwencjami. Jeśli zatem ktoś korzysta z jakiegoś rozwiązania, które umożliwia jednolity wygląd aplikacji Gtk w Plazmie, to sprawa jest w pełni załatwiona. Standardowo z Plazmą dostarczane mogą być dwa wystroje dla aplikacji Gtk: Breeze i Breeze Dark. Również niektóre inne dostępne tematy oferują także odpowiednie pliki zapewniające jednolitość wystroju. Niestety ze względu na rozwiązania przyjęte w obozie GNOME, jakakolwiek ingerencja w kolorystykę wystroju Plazmy pozostanie bez żadnego wpływu na tę w aplikacjach Gtk+3 otwieranych w tym środowisku. Nie liczcie na to, że zaznaczenie opcji "Nałóż kolory na programy spoza Qt" przyniesie jakikolwiek efekt.
Estetom pozostaje zatem albo pozostanie przy rozwiązaniu dostarczanemu wraz z Plazmą (wystrój Breeze/Breeze Dark dla Plazmy oraz aplikacji Gtk), albo znalezienie jakiegoś innego motywu, który zapewnia taki sam zestaw kolorów dla aplikacji Gtk, jaki oferuje dla Plazmy, albo sięgnięcie po jakiś motyw Gtk i wymuszenie go również dla samej Plazmy. Pozostali nie mają łatwo. Kiedyś jeszcze opiszę dokładnie jak narzucić wybraną przez siebie kolorystykę Plazmy dla aplikacji Gtk3. Dzisiaj tylko wspomnę, że kluczem sukcesu jest plik gtk.css, który można samemu "ujednolicić" z wybranym przez siebie schematem kolorystycznym. Rozwiązanie, które wydaje się być najmniej czasochłonnym (oprócz rozwiązań gotowych), to znalezienie takiego motywu dla Gtk3, który w największym stopniu kolorystycznie odpowiada naszym upodobaniom, skopiowanie wybranego przez siebie tematu dla aplikacji Gtk3 do ~/.local/share/themes i nadanie mu jakiejś własnej nazwy, przeniesienie pliku gtk.css w odpowiednie miejsce w tym katalogu, a następnie jego wybór dla aplikacji Gtk, otworzenie takiej aplikacji i skopiowanie kolorystyki do środowiska Plazmy. Ani to proste, ani nie daje 100% efektów, niemniej jednak lepsze niż napisanie całego gtk.css (no, chyba, że ktoś ma to perfekcyjnie opanowane), niemniej jednak daje efekt lepszy niż dysonans powodowany niechęcią współpracy aplikacji Gtk3 w jakimkolwiek innym środowisku.
Zasadniczym jednak profitem udostępnienia wtyczki gtk3_kde5 jest możliwość rezygnacji z biblioteki kdelibs (wraz z jej zależnościami) o ile ta była utrzymywana w Plasma 5 wyłącznie dla zapewnienia jednolitego wyglądu oraz zachowania się LO w Plazma 5. Oczywiście o ile nie mamy w systemie jeszcze jakichś innych aplikacji rodem z KDE4. Prawdopodobnie również będziecie mogli wówczas uwolnić się od Qt4 (o ile również nie macie w systemie aplikacji zbudowanych na tym toolkicie). Tak kdelibs, jak i Qt4 przeszły już na zasłużoną emeryturę i to dłuższy czas temu. Przypominam również, że stosując VCL KDE4 mogliście dokonać zmian w celu wymuszenia działania tej wtyczki. Sprawdźcie sobie ustawienia w pliku /etc/profile.d/libreoffice-fresh.sh/csh i/lub w ustawieniach startujących wraz z Plazmą (np. takie rozwiązanie było preferowane w OpenSUSE i stało się w miarę powszechne), lub w innych jeszcze ustawieniach zmiennych środowiskowych.

POLAUR teraz dzięki polaur

Dzięki pracy naszego forumowicza nycko123 nasze repozytorium dorobiło się prostego narzędzia umożliwiającego podstawowe nim zarządzanie. Narzędzie nazywa się... a jakże inaczej... polaur i dostępne jest w naszym repozytorium. Tutaj znajduje się plik PKBGBUILD umożliwiający budowę paczki. Samo narzędzie to zaledwie jeden plik skryptu powłoki. Dzięki jego działaniu możliwe jest:
- zapoznanie się z dostępnymi repozytoriami,
- przeglądanie ich zawartości,
- pobieranie wybranych źródeł paczek.
Pobrane źródła znajdziecie w ~/.cache/polaur/nazwa_repozytorium/nazwa_paczki.
I w zasadzie tyle, bowiem w przeciwnym razie tekst byłby dłuższy od skryptu.