sobota, 11 listopada 2017

Koniec 32 bitowych paczek w Arch Linux

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

wtorek, 31 października 2017

AMDGPU dla GCN1 i GCN2 i kerneli >=4.13

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

wtorek, 24 października 2017

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

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

poniedziałek, 23 października 2017

KDEPIM bez kopii zapasowej?

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

Qt 5.10 beta 1

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

niedziela, 17 września 2017

KMarkdownWebViewer

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

Plasma 5.10.95 aka 5.11Beta

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

sobota, 26 sierpnia 2017

Żegnamy QupZillę

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

sobota, 29 lipca 2017

Zarządzanie zaporą sieciową w Plasma 5

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

piątek, 28 lipca 2017

Powrót z przeszłości: Kooka

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

Huen, czyli kolorystyka Plasmy na podstawie tapety

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

sobota, 1 lipca 2017

FocusWriter a sprawa polska

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

środa, 28 czerwca 2017

LibreOffice 5.4RC1 oraz 6.0alpha0

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

czwartek, 22 czerwca 2017

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

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

Naprawiamy wadliwe źródła w PKGBUILD

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

środa, 21 czerwca 2017

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

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

wtorek, 20 czerwca 2017

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

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

poniedziałek, 19 czerwca 2017

MEGA a sprawa Arch Linux

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

czwartek, 15 czerwca 2017

Aplet informujący o aktualizacjach w Archu

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

Plasma i Strażnik Krypt

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

środa, 14 czerwca 2017

Kolorystyka aplikacji wykorzystujących kdelibs w Plasma 5

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

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

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

sobota, 3 czerwca 2017

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

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

czwartek, 1 czerwca 2017

Brak możliwości aktualizacji lub instalacji pakietów - zablokowana baza

Arch oferuje doprawdy świetne narzędzie do obsługi pakietów. Niemniej jednak zbliża się już koniec drugiej dekady XXI w. i przyzwyczajenia użytkowników, czy też ich oczekiwania w zakresie jakiegoś prostego, graficznego menedżera paczek są duże i poniekąd można je uznać za uzasadnione. Tymczasem pacman czuje się jak ryba w wodzie wyłącznie w konsoli. Natura nie znosi próżni, stąd też już od dawna powstają takie graficzne menedżery. Ostanio - głównie za sprawą ich domyślnego instalowania w dystrybucjach pochodnych - popularność zyskały pamac oraz octopi. Oba te programy oferują, działające nieustannie w tle, małe narzędzia monitorujące możliwość aktualizacji pakietów. W ich konfiguracji można sobie zmienić częstotliwość aktualizacji. Jeśli nic nie zmienimy w systemie, to owe narzędzia zainstalują się wraz ze wspomnianymi menedżerami i ustawione będą (o ile pamiętam) na sprawdzanie aktualizacji raz dziennie. Zwykle oznacza to, że rozpoczynają swe działanie zaraz po pierwszym uruchomieniu komputera w danym dniu. Jeśli aktualizacje są dostępne, to programy te pokażą stosowną informację w tacce systemowej. Zanim to nastąpi są ciche i nieme. W żaden sposób nie sygnalizują swego działania w tle. Użytkownik zatem nie ma żadnej wiedzy, czy w danym momencie narzędzie wykonuje swoją pracę, czy nie. Zdarzyć się może, że chcemy zainstalować jakąś paczkę właśnie wówczas, gdy omawiane narzędzie będzie sobie spokojnie wykonywało pracę w tle. Wówczas pojawi się informacja, że nie jest to możliwe i pojawi się informacja:
błąd: nie udało się zainicjować transakcji (nie udało się zablokować bazy danych) błąd: nie udało się zablokować bazy danych: Plik istnieje jeśli jesteś pewien, że menedżer pakietów nie jest już uruchomiony, możesz usunąć /var/lib/pacman/db.lck
Oczywiście rozwiązanie mamy podane wprost. Niemniej jednak kilka słów wytłumaczenia dlaczego tak się dzieje. Otóż owe działające w tle narzędzia dokonują synchronizacji bazy pacmana (pomijam tu kwestię bezpieczeństwa, albowiem muszą one w tym celu uzyskać uprawnienia administratora, a skoro nie podajemy im hasła, to oznacza, że cały czas działając w tle posiadają takie uprawnienia, co delikatnie mówiąc obniża bezpieczeństwo naszego systemu). Każde działanie pacmana dotyczące jego bazy (a takim jest jej synchronizacja) dokonuje jej zamknięcia, by uniemożliwić w tym samym czasie działanie innej instancji pacmana, która również do tej bazy chce mieć dostęp. Efektem jest, że pojawi się w systemie (zasadniczo) tymczasowy plik /var/lib/pacman/db.lck. Jak napisałem - uniemożliwi on synchronizację baz pacmana, aktualizację systemu, instalację paczek, czy ich odinstalowanie. W takiej sytuacji, jeśli mamy zainstalowane narzędzie informujące o dostępnych aktualizacjach (domyślne np. w Antergosie czy Manjaro), możemy chwilę odczekać i zobaczyć co się dzieje, a próbę instalacji czy odinstalowania pakietów bądź aktualizacji systemu po niej ponowić. Możemy również przerwać ów proces działający w tle bądź to w ogóle z niego wychodząc, bądź to po prostu kasując plik db.lck (oczywiście uprawnienia administratora są niezbędne). To ostatnie będzie też właściwym i jedynym rozwiązaniem, jeśli z jakiegoś powodu baza pozostanie zablokowana pomimo, że żadne narzędzie w tle nie działa. Dzieje się tak najczęściej wówczas, gdy proces synchronizacji bazy został przerwany (choćby nieświadomie przez wyjście z systemu podczas działania takiego narzędzia informującego o aktualizacji). Cóż, osobiście raczej nie korzystam z owych notyfikatorów, bowiem zdecydowanie lepszym jest dla mnie konsolowe narzędzie checkupdates, które robi to znacznie szybciej. Niestety też, zarówno octopi, jak i pamac wprowadzają je do naszych systemów, czy tego chcemy, czy nie. W przypadku octopi niebawem podam dwa rozwiązania jak się pozbyć tych notyfikatorów, a mimo tego nadal się cieszyć możliwościami graficznego menedżera pakietów.

środa, 31 maja 2017

Packagekit umożliający instalację pakietów bez uprawnień administratora

Prawdopodobnie nikt, kto korzysta z KDE nie musiał instalować packagekit. Wraz z wersją Plasma 5.10 pojawiła się jednak nowa wersja aplikacji Discover (plasma-discover), która w opcjonalnych zależnościach posiada flatpak oraz packagekit-qt5. Obie rozszerzają możliwości Discover na instalację przez tą aplikację innych programów. Umożliwiają również instalowanie ich za pomocą Krunnera. Pierwsza instaluje paczki flatpak. Druga instaluje paczki z repozytorium. Pewnie wielu z Was zdziwi zachowanie tej aplikacji przy instalowaniu pakietów. Otóż w standardowej instalacji Archa (i pewnie innych pochodnych dystrybucji) próba zainstalowania jakiejkolwiek aplikacji przez Discover oznajmi jedynie, że przebiega instalacja i... po chwili program zostanie zainstalowany. Dodatkowo zostanie on zainstalowany systemowo, w katalogu głównym linuksa. Nie tylko bez pytania o pozwolenie (czyt. hasło administratora), ale również bez oznajmiania jakie zależności zostaną zainstalowane. Co ciekawe odinstalowanie za pomocą Discover jakiegokolwiek programu uprawnień administratora już wymaga. Cóż... to, że mało mi się taki pomysł podoba, to jedno. Czas jednak znaleźć winnego i spróbować sytuację naprawić. Po pierwsze za problem odpowiada packagekit, który jest instalowany jako zależność packagekit-qt5. To on (i jego ustawienia polkit) powoduje, że w pamięci cały czas przebywają dwa procesy umożliwiające instalację czegokolwiek bez uprawnień administratora. Po drugie możliwości naprawy są trzy (dziękuję V1del z BBS Archa oraz nintyfanowi z dobreprogramy.pl). Pierwsza, to usunięcie bądź zmiana nazwy pliku /var//usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules. Druga to usunięcie z grupy wheel konta użytkownika. Od tej pory chcąc zainstalować bądź odinstalować cokolwiek za pomocą Discover, będzie on wymagał podania hasła. Niestety nie poinformuje nas jednakże o tym jakie są instalowane wraz z programem zależności. Trzecia opcja, choć ograniczająca nowe możliwości Plasma 5.10 jest według mnie najlepsza. Nie instalować packagekit-qt5 jako opcjonalnej zależności Discover, a i w ogóle rozważyć sensowność instalowania tej paczki. Dość mało podoba mi się rezydująca w pamięci usługa, która uzyskała uprawnienia administratora, która może dowolnie instalować w systemie cokolwiek bez mojej zgody.

Brak możliwości aktualizacji i instalacji paczek w Antergosie

Od pewnego czasu, jak świat długi i szeroki, dochodzą informacje o niesamowitym problemie związanym z aktualizacją, bądź instalacją paczek w Antergosie. Wszystkiemu winni są oczywiście ludzie. Tym razem deweloperzy Antergosa, który swoją nową paczkę antergos-keyring, która odpowiada za wprowadzenie do systemu kluczy GPG umożliwiających sprawdzenie autentyczności pakietów, podpisali jakimiś wadliwymi kluczami. Innymi słowy paczka *.sig jest wadliwa. Nie mam ochoty dochodzić co jest zrobione źle, zwłaszcza, że nie mam wpływu na poprawę tego pliku. Mogę jedynie przedstawić proste rozwiązanie. Kiedy zatem otrzymujecie błąd, tego typu (może ich być więcej, to jedynie przykład):
błąd: antergos-keyring: signature from "Antergos Build Server (Automated Package Build System) " is unknown trust :: Plik /var/cache/pacman/pkg/antergos-keyring-20170524-1-any.pkg.tar.xz jest uszkodzony (Niepoprawny lub uszkodzony pakiet (podpis PGP)). Czy chcesz go usunąć? [T/n]
Odpowiadacie na to pytanie przecząco: "n". Oczywiście instalacja nie dochodzi do skutku. W systemie jednakże pozostaje wadliwie podpisana, ale dostarczająca prawidłowych kluczy GPG paczka antergos-keyring. Teraz należy ją zainstalować w systemie:
# pacman -U /var/cache/pacman/pkg/antergos-keyring-20170524-1-any.pkg.tar.xz
Nie dziwcie się - tym razem paczka zainstaluje się bez problemów, albowiem pakiety instalowane z lokalnych lokalizacji nie są walidowane kluczami GPG. Po dokonaniu powyższego dalsza aktualizacja winna być już bezproblemowa.

wtorek, 30 maja 2017

ABS is dead, long live asp

ABS, dotychczasowe narzędzie służące w Archu do pobierania kodu źródłowego paczek (nie mylić z kodem samych aplikacji) zakończyło swój byt. Wcale to jednak nie oznacza, że jesteśmy zdani na ręczne przekopiowanie wszystkich niezbędnych plików służących budowie paczki. Otóż, prawdopodobnie już u każdego z nas zagościł niewielki programik asp. Tak niewielki, że można go było przeoczyć. Ów programik z powodzeniem może służyć właśnie do tego, do czego dotychczas służył ABS. Po pierwszym uruchomieniu powstanie nam katalog ~/.cache/asp. Potem, gdy będziemy chcieli pobrać kod niezbędny do budowy paczki wystarczy wpisać:
asp export nazwa_repozytorium/nazwa_paczki
Stosowny katalog z wszystkimi plikami, które służą jej budowaniu zostanie utworzony w miejscu wydania powyższego polecenia. Sam kod oraz nieco więcej o użyciu programu znajdziecie na githubie.

niedziela, 28 maja 2017

KMail pobiera i pobiera widok katalogu. I co z tym zrobić?

Zdarza się niekiedy, że KMail powita nas takim ekranem:
W zasadzie nie jest to problem. Trzeba poukładać sobie od nowa skrzynkę, pobrać wiadomości itd. itp. Problem, gdy nie mamy na to czasu. Wówczas... proste rozwiązanie. Otwieramy konsolę, wpisujemy:
akonadictl restart
i po chwili możemy się cieszyć poprawnie działającym KMail.

sobota, 27 maja 2017

Jak prawidłowo zainstalować pakiet w dystrybucji ciągłej?

Pytanie wydaje się być trywialne. Przecież wszyscy wiemy (oczywiście na podstawie Archa):
# pacman -S nazwa_pakietu
Czyżby? Cóż doczytaliśmy się jednej informacji, ale pominęliśmy inne. Oczywiście, że powyższe polecenie zainstaluje pakiet. Całkiem możliwe, że aplikacja będzie działać. Niemniej jednak pozwolę sobie zauważyć, że posiąwszy powyższą wiedzę nie doczytaliśmy się innej informacji: częściowa aktualizacja nie jest przez pacman wspierana. Zaraz pewnie usłyszę: co ma aktualizacja, w dodatku częściowa do instalacji pakietu. Ano ma. Przyglądnijmy się na początek co zawierają repozytoria Archa. Trywialnie możemy odpowiedzieć: paczki. Tylko, że w przeciwieństwie do dystrybucji wydawniczych, są one "w ciągłym ruchu". Arch linux zainstalowany miesiąc temu nie będzie tym samym systemem, który zainstalowaliśmy dzisiaj i to nawet jeśli w obu wprowadzimy te same pakiety, albowiem nie będą one - przynajmniej w części - te same, ale takie same. Nazwa będzie taka sama, ale już wersja niekoniecznie. Deweloperzy Archa zapewniają, by paczki dostępne w repozytorium w danym dniu, czy chwili były odpowiednio przebudowane, jeśli tego wymagają ich zależności. To natomiast oznacza, że pobierając pakiet dzisiaj, może on być zbudowany na podstawie innych zależności niż ten sam pakiet sprzed miesiąca. Nawet jeśli wersja pakietu będzie taka sama. Taki nowo przebudowany pakiet będzie się różnił numerem archowego wydania (inne pkgrel, czyli ostatnia cyfra w wersji paczki). Sam pacman działa natomiast w ten sposób, że dokonując aktualizacji systemu synchronizuje on bazę lokalną z bazą w repozytorium i wprowadza ewentualne zmiany do systemu. Jeśli zatem mamy system zainstalowany jakiś czas temu (nawet tego samego dnia), to może się zdarzyć, że pomiędzy ostatnią aktualizacją systemu, a próbą zainstalowania pakietu nastąpiły jakieś zmiany w paczkach, czego już nie uwzględnia nasza instalacja. Dlatego też prawidłowe instalowanie paczek zawsze winna poprzedzić aktualizacja systemu. Zatem chcąc zainstalować jakikolwiek pakiet wydajmy:
# pacman -Syu pakiet
Tylko wówczas możemy być w miarę pewni, że instalowany pakiet będzie działać prawidłowo.

Paczka nie może być zainstalowana albowiem jakiś plik znajduje się już w systemie.

Zdarza się, że przy aktualizacji lub instalacji jakichś paczek w systemie pojawia się informacja, że jakiś plik znajduje się już w systemie plików. Potem otrzymujemy jedynie informację, że żadna paczka nie została zainstalowana, czy zaktualizowana. Nie jest to żaden problem i gdy tylko będziemy postępować właściwie rozwiązanie zawsze się znajdzie. Wpierw jednak jestem winien jedno wytłumaczenie. Dla użytkowników innych menedżerów paczek dziwnym może się wydawać, że skoro jakiś jeden pakiet nie może być zainstalowany, to inne pakiety również. Otóż pacman nie wspiera aktualizacji pojedynczej paczki. I słusznie - Arch jest dystrybucją ciągłą i paczki dostępne w repozytorium są (winny być) zawsze już przebudowane, gdy nowe wersje ich zależności wprowadzone zostały do repozytorium. Wracamy. Przede wszystkim wszelkie rozwiązania typu skasować plik, który koliduje, sforsować instalację nowej paczki itp., które są niekiedy pokazywane jako remedium na wszystkie bolączki nie są właście. W nieszczęśliwych przypadkach istnieje możliwość, że zepsujemy sobie w ten sposób system, który nie wstanie już przy ponownym uruchomieniu. W mniej nieszczęśliwych nie wstanie środowisko, bądź jakiś jego element, czy aplikacja. Kiedy zatem zobaczymy coś takiego:
error: could not prepare transaction error: failed to commit transaction (conflicting files) package: /path/to/file exists in filesystem Errors occurred, no packages were upgraded.
lub wersji polskiej
błąd: nie można przygotować transakcji błąd: nie udało się wykonać transakcji (konfliktujące pliki) pakiet: /jakaś_ścieżka_do/pliku znajduje się już w sytemie Wystąpiły błędy, żaden pakiet nie został zaktualizowany
to w pierwszej kolejności należy sprawdzić o co chodzi. Przede wszystkim błąd taki oznacza, że jakaś nowa paczka dostarcza jakiś plik, który z jakiegoś powodu (jest zawarty w innej paczce, został stworzony przez użytkownika, jest pozostałością po niedokładnie usuniętej paczce) znajduje się już w systemie. Z powyższej informacji wiemy dwie ważne rzeczy: jaki plik uniemożliwia instalację nowej paczki oraz gdzie się znajduje. W tej chwili z pomocą przychodzi pacman. Wydajemy polecenie:
pacman -Qo /jakaś_ścieżka_do_konfliktującego/pliku
Ową ścieżkę i nazwę pliku znajdziemy w informacji o błędzie. W wyniku działania powyższego polecenia otrzymamy informację jaki pakiet jest właścicielem pliku uniemożliwiającego aktualizację, czy instalację nowej paczki. W zasadzie możliwe rozwiązania są dwa: - albo otrzymujemy informację, że żaden pakiet nie jest właścicielem tego pliku, - jakaś paczka jest właścicielem określonego pliku. Pierwszy przypadek możliwy jest w sytuacji, gdy albo został on stworzony przez użytkownika, albo jest pozostałością jakiegoś programu (np. gdy paczkę usunęliśmy z systemu pozostawiając w nim jego pliki konfiguracyjne), albo... został zainstalowany z pominięciem pacmana (skrypt, "paczka" od producenta oprogramowania, albo "cudowne" rozwiązanie - instalacja za pomocą dpkg lub rpm takich paczek). W pierwszych dwu przypadkach rozwiązanie jest proste - w istocie możemy spokojnie usunąć taki konfliktujący plik i ponowić instalację, która winna przebiegać już prawidłowo. Ostatnie powód konfliktu jest bardziej złożony i w ogóle nie powinien wystąpić, albowiem nie powinniśmy w ogóle zainstalować żadnego programu z ominięciem pacmana (wyjątki to paczki typu appimage, czy flatpak). Jeśli z jakiegoś powodu musimy w systemie zainstalować paczkę, która jest rozpowszechniana w formatach nieobsługiwanych przez pacmana, czy też jest jakimś skryptem, to dla takiej paczki winniśmy wykonać PKGBUILD, by pacman zawarł ją w swej bazie danych. Podobnie dla paczki tworzonej ze źródeł winniśmy zrobić PKGBUILD, a nie instalować jej w "tradycyjny" sposób. Wykonanie PKGBUILDu w takich sytuacjach i stworzenie paczki pacmana oraz jej instalacja z użyciem tego narzędzia spowoduje, że znajdzie się ona w bazie pacmana, a późniejsze odpytanie jej o właściciela pliku (-Qo) zwróci nam informację do jakiej paczki on należy. W tej ostatniej zatem sytuacji najsensowniejszym rozwiązaniem jest odinstalowanie wadliwie zainstalowanej aplikacji w systemie i ponowienie instalacji. Wówczas również nie powinniśmy mieć błędów w instalacji. Co w takim razie w drugiej sytuacji, gdy jakaś paczka jest właścicielem określonego pliku? Proponuję lekko odmienne rozwiązanie niż opisane w wiki Archa. Otóż w takiej sytuacji, w pierwszej kolejności powinniśmy sprawdzić skąd pochodzi paczka zawierająca ten sam plik. Teoretycznie najprościej będzie nam przeszukać repozytoria i AUR jakimś aurhelperem. Może to być graficzny program jak octopi, pamac, czy pkgbrowser, może to być np. trizen, pkgbuilder, czy najpopularniejszy yaourt. W tym ostatnim przypadku po prostu wpisujemy:
yaourt paczka
i w efekcie otrzymamy informację o tym, skąd pochodzi paczka uniemożliwiająca nam instalację (będzie przy niej stosowna informacja). Jeśli paczka nie znajdzie się ani w repozytorium, ani w AUR, a nadto nie zrobiliśmy jej we własnym zakresie, to istnieje prawdopodobieństwo, że z jakiegoś powodu paczka ta wypadła już z repozytorium bądź z AUR. Znów w zależności od pozyskanych informacji postępujemy odmiennie: - jeśli obie paczki zawierające ten sam plik pochodzą z oficjalnych repozytoriów Archa, to w pierwszej kolejności odwiedzamy stronę główną i szukamy informacji, czy błąd taki nie został w jakiś sposób opisany; jeśli tak postępujemy zgodnie ze znalezionym opisem, jeśli nie, to zgłaszamy błąd, występujący zaś problem możemy rozwiązać we własnym zakresie (jeśli potrafimy) odpowiednio przygotowując PKGBUILD dla którejś paczki (bądź obu), albo poczekać na rozwiązanie problemu przez opiekunów, - jeśli jedna paczka pochodzi z AUR, to błąd zgłaszamy opiekunowi paczki w AUR, samą paczkę najlepiej odinstalować i ewentualnie, jeśli nadal nam potrzebna, stworzyć nowy PKGBUILD dla niej bądź poczekać na reakcję opiekuna, - tak samo podchodzimy do sprawy, gdy kolidująca paczka pochodzi z niezależnego repozytorium, - jeśli obie paczki pochodzą z niezależnych repozytoriów - należy zgłosić błąd ich opiekunom, a najlepiej sprawdzić, czy repozytoria te są jeszcze aktywne, albowiem zdarza się, że ich rozwój został porzucony; w takim przypadku najsensowniej jest odinstalować paczkę bądź obie i - jeśli nadal ich potrzebujemy - poszukać nowszego bądź innego rozwiązania np. w AUR bądź stworzyć PKGBUILD samemu; w przypadku gdy paczka pochodzi z porzuconego repozytorium, warto się zastanowić nad usunięciem go w ogóle z systemu. - podobnie podchodzimy do sprawy, jeśli kolidującymi paczkami są paczki z niezależnych repozytoriów i z AUR. Praktycznie w żadnym przypadku natomiast nie stosujemy sforsowania instalacji, używając przełącznika --force, albowiem może to doprowadzić (i zwykle doprowadzi) do uszkodzenia bazy pacmana oraz możliwych i bardzo prawdopodobnych błędów przy późniejszych działaniach na systemie zainstalowanych paczek. Krótkie podsumowanie: 1. Jedynie wówczas usuwamy kolidujący plik i ponawiamy aktualizację, gdy wiemy, że plik ten jest osierocony. 2. Nigdy nie stosujemy pacman -Syu --force lub podobnego rozwiązania. 3. Jeśli błędne paczki pochodzą z repozytorium Archa, a nie istnieje rozwiązanie opisane na jego stronie domowej, to zgłaszamy błąd i wstrzymujemy się z aktualizacją do czasu naprawienia. 4. Niemal w każdej innej sytuacji, odinstalowujemy paczkę, która nie pochodzi z oficjalnego repozytorium, zgłaszamy błąd opiekunowi takiej paczki (w AUR, w niezależnym repozytorium), samą zaś paczkę najsensowniej odinstalować i w zależności od umiejętności bądź to przygotować dla takiej aplikacji nowy PKGBUILD i zbudować od nowa, bądź to poczekać na rozwiązanie przez opiekunów

poniedziałek, 15 maja 2017

Plasma 5.10 beta

Właśnie zawitała pierwsza, publiczna przymiarka do nadchodzącego z końcem maja nowego wydania środowiska Plasma 5.10. O nowościach dowiecie się z powyższego odnośnika. Jednocześnie z tym wydaniem, nowe paczki zawitały również do Archa. Są one dostępne w repozytorium kde-unstable, w którym również znajduje się już trzecie wydanie bety Qt 5.9 (przy okazji przypominam, że będzie ona kolejnym LTSem, co akurat w świecie Archa ma niewielkie znaczenie). Jeśli zatem macie czas i ochotę, to jak zwykle w takich sytuacjach polecam instalację tej wersji, choćby na testowych (czy nawet na wirtualnych) maszynach. Jeśli nie jesteście informatykami bezpośrednio pracującymi przy tych projektach, to sygnalizowanie błędów Antonio Rojasowi oraz na bugzilli KDE jest jedyną możliwością pomocy twórcom. Przy okazji przypomnę, że chcąc raportować błędy warto sobie przyswoić instrukcję z wiki Archa (wprawdzie na moim blogu również zostało to podane, ale ów tekst wymaga pewnych korekt, których dokonam w wolnej chwili). Jest to tym bardziej istotne, że standardowe paczki Archa nie niosą ze sobą informacji podobnych do paczek *-dbg znanych choćby z Debiana i pochodnych. Tym samym zgłaszanie błędów tylko i wyłącznie twierdząc, że jakiś błąd istnieje nie niesie ze sobą żadnej użytecznej informacji dla deweloperów. Jeśli ktoś zatem zdecydowałby się na testy, to przypominam, że do pliku pacman.conf powinniśmy dodać wpis:
[kde-unstable] Include = /etc/pacman.d/mirrorlist
Jednocześnie ze względu na to, że paczki te są budowane w oparciu o repozytorium testowe, winniśmy - przynajmniej czasowo - udostępnić naszemu systemowi także te repozytoria. EDIT: Pierwsze dostrzeżone wadliwe działanie. Otóż obecny od jakiegoś czasu Discover (Odkrywca), który umożliwia instalowanie niektórych elementów środowiska, a który został obecnie wyposażony o wsparcie dla flatpak i snappy, niestety nie działa bez doinstalowania opcjonalnego flatpak. Cały problem jest związany z budowaniem tej paczki z flatpak jako zależnością budowy (makedepends). Jeśli przebudujemy paczkę bez flatpak, paczka buduje się prawidłowo, nie wymaga flatpak, ale oczywiście ich teraz nie wspiera. EDIT: Wstępna diagnoza jest taka, że programu plazma-discover w ogóle nie należy instalować. Uzyskuje uprawnienia do całego dysku, umożliwiając instalację paczek bez uprawnień administratora (usuwając trzeba już podać), ale co jeszcze gorsze program ma jakiś wyciek pamięci, albowiem jego wyłączenie nie powoduje, że program zostaje wyzwolony z pamięci.

niedziela, 14 maja 2017

Ostatnia deska ratunku - uruchomienie linuksa z prawami administratora

Kiedyś już pisałem o tym, że warto sobie za wczasu zrobić ratunkowe koło. Niemniej jednak zwykle Polak mądr po szkodzie. Często czytam, że "po aktualizacji system mi się nie uruchamia". Ów system najczęściej jest utożsamiany ze środowiskiem graficznym. No, to nie do końca "system się nie uruchamia", ten najczęściej się uruchomił, jednakże z jakiegoś powodu nie uruchamia się tryb graficzny. Nawet jednak w takiej sytuacji i również wówczas, gdy nie zadbaliśmy wcześniej o ustawienie sobie pozycji recovery w GRUB będziemy mogli uruchomić "sesję ratunkową", która da nam dostęp do trybu konsolowego na prawach administratora. Wówczas już można zrobić z systemem wszystko co niezbędne. Wystarczy bowiem do linii startowej w GRUB dodać polecenie:
systemd.unit=rescue.target
i system uruchomi się grzecznie prosząc o podanie hasła administratora. Z sesji tej wychodzimy wpisując:
exit
i nastąpi dalsze podnoszenie systemu już ze środowiskiem. Pamiętać jednak musimy, że udostępniona w opisany tu sposób sesja administratora nie podnosi takich usług jak np. sieć, zatem trzeba będzie ją podnieść odrębnie i ustanowić połączenie. Źródło to jak zwykle wiki Archa.

wtorek, 18 kwietnia 2017

Pozbywamy się niechcianych plików lokalizacyjnych z pomocą pacmana

W Archu wiele programów zawiera wszystkie swoje pliki lokalizacyjne. W ten sposób, instalując jakiś program otrzymujemy nie tylko te pliki, które chcemy, ale także takie, z których na pewno nie skorzystamy. Wprawdzie nie jest są to pliki duże, jednakże skoro nie muszą w naszym systemie istnieć, to po co mają w nim być? Wielu prawdopodobnie spotkało się z takimi narzędziami jak localepurge, czy bleachbit i próbowało zapewne z ich pomocą usuwać te pliki. Po takiej czynności pacman będzie jednakże sygnalizował niespójność pakietów (brak ich części). Od czasu pojawienia się wersji 4.2 pacmana istnieje jednakże znacznie lepsze rozwiązanie. Otóż w pliku /etc/pacman.conf możemy skorzystać z tzw. odwróconych wyrażeń regularnych, które umieścimy w polu NoExtract. W ten sposób pacman zostanie poinstruowany o tym, że z paczki nie ma rozpakować określonych plików i umieścić ich w systemie. Zainstalowane tak paczki nie będą powodowały żadnych informacji o błędach ze strony pacmana. Konieczne jest jednakże bądź to przeinstalowanie wszystkich paczek w systemie, bądź to po prostu poczekanie na kolejne aktualizacje. Pamiętajmy jednak o tym, że wiele paczek nie zawiera polskich plików lokalizacyjnych. Roztropność nakazuje, by pozostawić w systemie te pliki z angielskimi paczkami językowymi (bo te najczęściej mają wszystkie). Stosowna linia w NoExtract może wyglądać tak:
NoExtract = usr/share/locale/* !usr/share/locale/pl/* !usr/share/locale/en_US/* !usr/share/locale/locale.alias usr/share/man/* !usr/share/man/man*
Dziękuję za wskazanie (lata temu) tego sposobu Bartkowi Piotrowskiemu.

środa, 12 kwietnia 2017

Niesforne kolory aplikacji Qt4 w Plasma 5

Zanim doczekamy się, że padnie ostatni bastion oprogramowania opartego o Qt4/kdelibs upłynie pewnie jeszcze sporo wody w Wiśle. Niestety. Niestety też okazuje się, że systemsettings5, który obecny jest w Plasma 5 od samego początku (niegdyś był jeszcze systemsettings4, ale obecnie już go nie ma), nie zawsze sobie radzi z nałożeniem schematu kolorystycznego wybranego przez użytkownika na aplikacje wykorzystujące stary rodzaj bibliotek. Dzieje się tak przede wszystkim, gdy albo sami taki schemat stworzymy, albo wybierzemy go w Ustawieniach Systemowych -> Kolory, czy też wgramy ze store.kde.org. Ba, stosowny błąd, a w zasadzie nawet dwa, został nawet jakiś czas temu zgłoszony. Nie liczyłbym jednak na jego szybkie załatwienie i poniekąd słusznie. Wolę, jeśli praca programistów Plasmy nie jest trawiona na tego typu rzeczy, które w dodatku, prawdopodobnie będą przejściowo jedynie sensowne. Przyglądnijmy się zagadnieniu, które irytujące jest w zasadzie wyłącznie dla osób korzystających z różnego rodzaju DE/WM w linuksie. Otóż, gdy wybierzemy sobie jakiś motyw, który dostarczany jest wraz z Plasmą - nie ma problemu. W zasadzie zostanie on nałożony poprawnie. Tak jest i z Breeze i z Breeze Dark. Gorzej, gdy ich kolorystyka nam nie pasuje. Wówczas bądź to sami zmieniamy, bądż to przeszukujemy w tym celu AUR, bądź udajemy się do sklepu KDE. Wgranie schematu najczęściej dokona zmian w kolorystyce Plasma 5, ale już niekoniecznie dla aplikacji Qt4/kdelibs. O ile jeszcze schematy kolorystyczne wgrywane z AUR choćby niekiedy się nałożą na nie, to już pozostałe w zasadzie nigdy nie. Przyczyna jest prozaiczna. Jeśli tworzymy nowy schemat kolorystyczny dla aplikacji Plasmy, bądź też wgrywamy go ze sklepu KDE, to zostanie on ulokowany w katalogu ~/.local/share/color-schemes/. Aplikacje Qt4/kdelibs będą go poszukiwały jednak w katalogu ~/.kde4/share/apps/color-schemes/. Dodatkowo, często schematy, które pobierane są ze sklepu KDE w systemsettings widziane są pod nazwą, zaś w istocie ich nazwa zaczyna się od jakiejś liczby. I wówczas już wbudowane narzędzia ne potrafią sobie poradzić. Wyjście jednakże jest proste. Niezależnie od tego, czy stworzyliśmy sobie schemat we własnym zakresie, czy też wgraliśmy go ze sklepu KDE, przekopiujmy z katalogu ~/.local/share/color-schemes/ do katalogu ~/.kde4/share/apps/color-schemes/ i to najlepiej jeszcze przed jego wybraniem. Od tej pory kolory wybrane w systemsettings5 winny być prawidłowo nałożone również na aplikacje Qt4/kdelibs.

środa, 5 kwietnia 2017

Łatwa "instalacja" obrazu ISO bezpośrednio w GRUB2

GRUB2 daje możliwość uruchamiania obrazów systemu (ISO) bezpośredniego z dysku. Niestety albo trzeba dokładnie poznać strukturę owego ISO i stworzyć odpowiedni wpis, który GRUB2 rozpoznałby, albo posługiwać się listą gotowych wpisów. W oparciu tę właściwość można sobie przygotować nawet odpowiedni nośnik zawierający kilka systemów. Można sobie też ułatwić życie. W Debianie od lat istnieje narzędzie grub-imageboot, którego źródła są prawdopodobnie w githubie prowadzonym przez formorera ułatwiające to zadanie. Po instalacji, dodaniu ISO do odpowiedniej lokalizacji, musimy jedynie zaktualizować GRUB2 i... wszystko powinno działać. Niestety nie z każdym ISO mi się to udało. Kiedyś istniały skrypty umożliwiające budowę tej paczki w AUR. Nieznane są mi powody ich usunięcia, niemniej jednak znajdują się one nadal w archiwum AUR. Jeśli chcielibyśmy z nich skorzystać należy sklonować archiwum:
git clone https://github.com/aur-archive/grub-imageboot
Przejść do katalogu i stworzyć paczkę:
cd grub-imageboot && makepkg -sirc
Domyślną lokalizacją obrazów ISO, jest /boot/images. Określa ją plik /etc/default/grub-imageboot. Jeśli zdecydujemy się skorzystać z tej lokalizacji, musimy ją stworzyć i skopiować tam interesujący nas obraz systemu a następnie wykonać:
# grub-mkconfig -o /boot/grub/grub.cfg
Od tej chwili, po ponownym uruchomieniu komputera, pośród wpisów w GRUB winien się znaleźć również umożliwiający nam uruchomienie dodanego obrazu systemu.

wtorek, 4 kwietnia 2017

Hardcore - Kompilacja programu pod własny procesor, cz. 3 - qmake errata

Niegdyś popełniłem tekst, który poruszał już tę kwestię. Można jednak nieco prościej. Zakładając, że stworzyliśmy sobie również makepkg.conf, który przekaże kompilatorowi flagi naszego procesora, możemy uprościć PKGBUILD i po prostu w sekcji build, po odpowiednich komendach przekazywanych niekiedy qmake dodać QMAKE_CFLAGS_RELEASE="${CFLAGS}"QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}". Przekaże to qmake zmienne, jakich użyliśmy w makepkg.conf.
Stosowny fragment PKGBUILD może zatem wyglądać tak:
build() {
    cd "$srcdir/$pkgname-$pkgver"

    qmake QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
          QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
    make

}
Oczywiście ścieżka jest przykładowa. Przykładowy jest też zapis qmake, aczkolwiek najczęściej stosowany.

Hardcore - Kompilacja programu pod własny procesor, cz.2 - makepkg.conf

Zasadniczym plikiem, który w Archu (bądź szerzej w dystrybucjach pacmanowych) przekazuje informacje sterujące procesem kompilowania jest makepkg.conf wykorzystywany przez program makepkg. Dla niezaznajomionych, to on jest wykorzystywany przez różne AUR-helpery dla budowania programów z AUR. Z niego korzystamy również kompilując lokalnie program.
Pośród opcji tego pliku znajdziemy również dwie, które powodują, że kompilator języka C/C++ stara się zoptymalizować kod programu pod procesor, jaki tam został zadeklarowany. Są to zmienne: CFLAGS, CXXFLAGS oraz CPPFLAGS.
Standardowo (tj. bezpośrednio po zainstalowaniu pacmana) wyglądają one tak (dla procesorów 64bitowych):
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
Interesujące będą dla nas dwie: march i mtune. W powyższym przykładzie (czyli standardowo), zbudowany z użyciem skryptu makepkg program będzie dostosowany do każdego procesora 64bitowego. Możemy to prosto zmienić, edytując plik /etc/makepkg.conf. Możemy się zdecydować na to, by sam kompilator "odgadł" jakie flagi kompilacyjne winien zastosować. Wówczas w miejscu x86-64 oraz generic wpisujemy native.
Możemy jednak nie wierzyć automatowi i spróbować dokładniej określić jakie flagi winny tu zostać użyte, tak by na pewno odpowiadały naszemu procesorowi. Wpierw musimy jednak poznać te flagi. Wydajemy w tym celu polecenie:
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
Teraz pozostaje nam odnalezienie odpowiednich pozycji po słowach march i mtune oraz ich wpisanie jako zmiennych w pliku /etc/makepkg.conf.
W moim przypadku (mam procesor AMD serii Piledriver) może to wyglądać tak:
CFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong"
lub
CFLAGS="-march=bdver2 -mtune=bdver2 -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=bdver2 -mtune=bdver2 -O2 -pipe -fstack-protector-strong"
Niestety te zmienne nie działają dla programów używających cmake bądź qmake (zob. poradnik, choć niebawem jego uproszczenie) przy kompilacji.
Musimy również pamiętać, że tak zbudowany program może w ogóle nie zadziałać na innym procesorze (np. po jego wymianie). Nie będzie też "przenośny" w tym sensie, że zbudowany z takimi flagami program może nie pracować na innym komputerze, działającym na innym procesorze.

sobota, 25 marca 2017

KDE Applications 17.04beta

Wczoraj zadebiutowała nowa odsłona zbioru aplikacji KDE. Oczywiście jest to wersja beta (17.03.80). Przed ostatecznym wydaniem, które ma nastąpić 20 kwietnia ukaże się jeszcze wersja kandydująca RC (17.03.90), która winna być dostępna 6 kwietnia.
W repozytorium kde-unstable, arojas udostępnił już paczki w tej wersji, umożliwiając w ten sposób ich testowanie i zgłaszanie ewentualnych błędów.
Jeśli zatem ktoś miałby ochotę w owe testy się włączyć, to musi dodać do listy repozytoriów pacmana repozytorium kde-unstable oraz udostępnić repozytorium testing, albowiem kde-unstable jest tworzone na podstawie paczek z tego repozytorium.
Pośród nowości kilka aplikacji zostało przeportowanych do Qt5/KF5, porzucone zostały także dwie paczki: kommander oraz pim-storage-service-manager, które wypadałoby usunąć, jeśli dotychczas z nich korzystamy. O zmianach więcej przeczytacie w społecznościowym komunikacie.
Ewentualne dostrzeżone błędy prosimy zgłaszać na forum Archa. Błędy w samych programach winny być zgłaszane na bugzilli KDE. Mamy jeszcze około 3 tygodni, by programy te mogły stać się lepsze.

sobota, 18 marca 2017

Wydania tygodniowe Otter-Browser

Od dłuższego czasu prezentowałem PKGBUILDy, które umożliwiały budowę tygodniowych wydań Otter-Browser. Od wydania #166 na AUR dostępna jest taka wersja. Zaprzestaję zatem prezentowania własnych PKGBUILDów, albowiem nie ma to sensu. Jeśli ktoś używał moich, to proponuję ich odinstalowanie i zainstalowanie wersji z AUR.

czwartek, 9 marca 2017

Wyjaśnić niewyjaśnione, czyli meta paczki i grupy paczek

Niekiedy czytamy, że coś możemy zainstalować w Archu poprzez instalację paczki coś-meta. Ot, choćby instalację środowiska graficznego od KDE możemy przeprowadzić w następujący sposób:
Install the plasma-meta meta-package or the plasma group.
Istnienie dwu sposobów instalacji (a w zasadzie jeszcze większej ilości) jak zwykle powoduje niezrozumienie i konsternację, choć cała sprawa jest oczywiście wyjaśniona. Mimo tego, spróbuję ją wyjaśnić raz jeszcze.
Opiekun jakichś paczek w Archu może stworzyć grupę paczek. Taką grupą jest wspomniana wyżej plasma. Grupa nie jest żadną oddzielną paczką, a jedynie pewnym ułatwieniem dla użytkowników, deklarowanym w PKGBUILD w polu groups. Każda paczka składająca się na daną grupę otrzyma w tym polu deklarację do jakiej grupy paczek należy. Tym samym np. paczka plasma-desktop czy breeze otrzymają w tym polu deklarację, że należą one do grupy paczek o nazwie plasma.
Grupę taką łatwo możemy podglądnąć, wydając polecenie:
pacman -Sg nazwa_grupy
Samą interesującą nas nazwę grupy możemy zobaczyć wydając polecenie:
pacman -Si/Qi nazwa_paczki
i odszukując w niej pole Grupy. Grupy, albowiem ta sama paczka należeć może do więcej niż jednej grupy paczek.
Meta paczka jest natomiast oddzielną paczką (ot, przykład plasma-meta). Zwykle, każda paczka dostarcza nam do systemu jakieś pliki. W przeciwieństwie do tego typu paczek, paczki meta nie dostarczają żadnych plików, zawierają wyłącznie informacje dla pacmana w polu depends, z której wynika, że paczka meta zależy od jakichś - już "zwykłych" - paczek.

Prześledźmy konsekwencje używania jednego i drugiego rozwiązania.
Jeśli instalujemy jakąś meta paczkę, wówczas zainstalowane zostaną wszystkie paczki zadeklarowane w polu depends PKGBUILDu. Nie mamy żadnej władzy nad tym jakie paczki zostaną zainstalowane. Zostaną bowiem zainstalowane wszystkie wymienione w depends. W omawianym przypadku plasma-meta niezależnie zatem od tego, czy np. mamy w sytemie, czy nie mamy jakiekolwiek urządzenie korzystające z połączenia Bluetooth, zostanie nam zainstalowana paczka bluedevil zapewniająca integrację urządzeń Bluetooth z Plasmą. Od tej pory też, ze względu na "trzymające" je powiązanie zapewniające przez meta paczkę, wszystkie te aplikacje będą zachowywały się łącznie. Jeśli będziemy dokonywać aktualizacji systemu, to będzie ona dokonywała się również poprzez ową meta paczkę, zatem zmiana (w zasadzie dodanie) zadeklarowanych w niej paczek w polu depends spowoduje, że zainstalowane zostaną nowo zadeklarowane paczki. Usunięcie jakiejś paczki z tego pola spowodować może natomiast, że dotychczasowa paczka zostanie uznana za osieroconą.
Owa meta paczka uniemożliwi również odinstalowanie poszczególnych paczek instalowanych w systemie przez nią. Jeśli zatem zauważyliśmy, że mamy w systemie zbędne nam bluedevil i spróbujemy je odinstalować, to otrzymamy informację:
sudo pacman -R bluedevil
sprawdzanie zależności…
błąd:  nie udało się przygotować transakcji (nie udało się rozwiązać zależności)
:: plasma-meta: usuwanie bluedevil zależność przerw 'bluedevil'
Dopiero dodanie parametru -Rc umożliwi odinstalowanie takiej paczki, ale odinstaluje również paczkę plasma-meta.
Samo odinstalowanie meta paczki jest natomiast bez problemu możliwe i nie pociąga za sobą odinstalowania paczek, które ona dostarczyła (oczywiście przy odinstalowaniu bez podania parametru -s). Pamiętajmy jednak, że jeśli wpierw zainstalowaliśmy jakieś paczki składające się na meta paczkę, a następnie samą tę paczkę, to "kaskadowe" usunięcie owej meta paczki spowoduje wyłącznie usunięcie jej oraz tych paczek, które zostały przez nią zainstalowane. Nie spowoduje usunięcia paczek, które zainstalowaliśmy uprzednio, a które są jej zależnościami.
W moim przypadku (mam Plasmę zainstalowaną przez wybór paczek z grupy) instalacja plasma-meta dostarcza mi wyłącznie paczki: archlinux-appstream-data, bluedevil, discover, kirigami2 i plasma-meta.
Usunięcie plasma-meta wraz z zależnościami powoduje wyłącznie usunięcie tych, dostarczonych wraz z nią paczek i jej samej:
sudo pacman -Rcns plasma-meta
sprawdzanie zależności…
:: plasma-desktop opcjonalnie wymaga discover: manage applications installation from the launcher

Pakiet (5)                Obecna wersja  Zmiana     

archlinux-appstream-data  20170223-1     -15,89 MiB
bluedevil                 1:5.9.3-1       -1,83 MiB
discover                  5.9.3-2        -10,85 MiB
kirigami2                 2.0.0-1         -0,31 MiB
plasma-meta               5.9-2            0,00 MiB

Odzyskane miejsce na dysku:  28,88 MiB

:: Czy chcesz usunąć te pakiety? [T/n]
Nieco inaczej zachowuje się instalacja programów z pomocą grupy. Tutaj jeśli wydamy polecenie instalacji paczek składających się na grupę, otrzymamy informację o tym jakie paczki składają się na daną grupę, oraz że domyślnie zostanie zainstalowana cała grupa:
sudo pacman -S plasma
:: Jest 39 pakietów w grupie plasma:
:: Repozytorium extra
  1) bluedevil  2) breeze  3) breeze-gtk  4) discover  5) drkonqi  6) kactivitymanagerd  7) kde-cli-tools  8) kde-gtk-config
  9) kdecoration  10) kdeplasma-addons  11) kgamma5  12) khotkeys  13) kinfocenter  14) kmenuedit  15) kscreen
  16) kscreenlocker  17) ksshaskpass  18) ksysguard  19) kuiserver  20) kwallet-pam  21) kwayland-integration  22) kwin
  23) kwrited  24) libkscreen  25) libksysguard  26) milou  27) oxygen  28) plasma-desktop  29) plasma-integration
  30) plasma-nm  31) plasma-pa  32) plasma-sdk  33) plasma-workspace  34) plasma-workspace-wallpapers  35) polkit-kde-agent
  36) powerdevil  37) sddm-kcm  38) systemsettings  39) user-manager

Wybierz pakiety (domyślnie=wszystkie):
W tym momencie możemy albo zaakceptować domyślny wybór, albo spośród widocznych nam paczek zainstalować wyłącznie te, które nas interesują używając do tego cyfr widocznych przy nazwach poszczególnych paczek. Dokonać możemy dowolnego wyboru. Konsekwencją będzie to, że podczas aktualizacji, zostaną zaktualizowane wyłącznie te paczki, które zostały zainstalowane w powyższy sposób. Jeśli zatem do grupy paczek dołączy jakaś nowa, to owa nowa paczka nie zostanie zainstalowana w systemie (chyba, że stanowi zależność jakichś innych zainstalowanych paczek). Odinstalowanie poszczególnych paczek składających się na grupę również jest możliwe, chyba, że dana paczka jest zależnością innej jeszcze.

W Archu istnieje absolutna dowolność instalacji. To użytkownik decyduje jakie paczki i w jaki sposób mają zostać zainstalowane. Są jednakże dystrybucje pochodne od Archa, które posługują się meta paczkami. Wówczas okazuje się, że odinstalowanie czegoś nam zbędnego nie jest możliwe ze względu na istnienie w systemie owej meta paczki.

Oczywiście do niczego nie namawiam, a jedynie mam nadzieję, że w pewnym stopniu udało mi się przybliżyć te kwestie.