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.

Zrób sobie koło ratunkowe

Pamiętam czasy, kiedy obok systemu w komputerze, wiele osób miało dyskietkę ratunkową. Kiedy coś się podziało z systemem, umożliwiała jakiś dostęp do komputera, możliwość naprawy systemu. Zamierzchłe czasy. Im bliżej czasów współczesnych, tym bardziej wielu użytkowników wyzbyło się tej zaradności, która niegdyś powodowała, że system po prostu działał. Teraz system ma działać. Nie ważne co z nim zrobię, do jakiego stanu doprowadzę - on ma działać. Przewidzieć niemal każdą destrukcję, jaką jestem w stanie mu zaserwować - i tak ma działać. Jeśli nie działa, to winna jest zawsze jakaś osoba trzecia. W systemach, które oparte są w dużej mierze na współdziałaniu społeczności, które tworzą różnego rodzaju formuły społecznościowych porad, w takich systuacjach najczęściej pojawia się żądanie takich osób wobec społeczności, by naprawić im to, co sami najczęściej sami zepsuli. Nie mam nic przeciwko temu, bowiem co do zasady, m.in. na tym opiera się istnienie owych społecznościowych systemów. Każdy jednak musi się uzbroić w pewne instrumenty, które umożliwią naprawę systemu samemu.
Poniżej staram się przedstawić kilka podstawowych zasad, które to ułatwią. Pomijam te oczywiste, jak tworzenie kopii zapasowej. Tekst ten jest pisany przez użytkownika systemu Arch Linux, używającego otwartych sterowników oraz GRUB2. I z tego punktu widzenia będzie on pisany. Poniższe porady zatem mogą, ale nie muszą się przydać innym osobom.

1. Zabezpieczmy sobie drugi kernel
Przyznam, że sławetny "kernel panic", użytkując linuksa od bardzo wielu już lat widziałem bodaj dwa razy. Raz, gdy wadliwie skompilowałem sobie kernel. Niemniej jednak nie można usypiać. Zawsze zatem w systemie mam dwa kernele (o ile jakiegoś nie testuję). W przypadku stosowania wolnych sterowników graficznych, większego problemu nie ma. W przypadku zamkniętych, najczęściej konieczne będzie by ów dodatkowy kernel był w tej samej, działającej wersji, albowiem najczęściej moduły dostarczane przez paczki tych sterowników umożliwiają ich instalowanie wyłącznie w kernelu określonej wersji. Zainstalujmy zatem sobie oprócz tego, który używamy na co dzień, jakiś jeszcze jeden. Nie znam programu startowego linuksa, który nie umożliwiłby uruchomienie systemu z innego kernela. Instalując nową wersję kernela, jeśli coś pójdzie nie po naszej myśli i po restarcie spotka nas przykra niespodzianka, najczęściej będziemy mogli wystartować system z drugiego kernela, spróbować dojść do tego co spowodowało destrukcję, naprawić... Przede wszystkim jednak - system zasadniczo będzie nadawał się do pracy.

2. Zabezpieczmy sobie dostęp do systemu w trybie ratunkowym
Niektóre systemy są tak skonfigurowane, że domyślnie w GRUB powstaje pozycja "recovery" ("tryb ratunkowy" itp.). Niekiedy się przydaje. Domyślnie w Arch Linuksie takiej pozycji nie ma (nie będę tu tłumaczyć dlaczego). Nie ma jednak najmniejszego problemu by ją dodać. Po co taka pozycja, jeśli zastosowaliśmy się do poprzedniej rady i do komputera dostęp możemy mieć? Otóż niekiedy umożliwi naprawienie systemu działającego na określonym kernelu. Niekiedy przecież wadliwie zainstaluje się jakieś środowisko, źle wgrają Xy. Sam kernel działać będzie poprawnie. Interwencji wymagać będzie inny element systemu.
Osoby korzystające z GRUB2 zrobią to edytując plik:
/etc/default/grub
Przypominam, że edycję musimy przeprowadzić z uprawnieniami administratora systemu.
W powyższym pliku odszukujemy linię o treści:
GRUB_DISABLE_RECOVERY=true
i zmieniamy ją na:
GRUB_DISABLE_RECOVERY=false
Teraz należy jeszcze utworzyć nowy skrypt GRUB2:
grub-mkconfig -o /boot/grub/grub.cfg
Od tej chwili pośród opcji startowych systemu pojawi się pozycja "recovery", z której będziemy mogli korzystać, gdy będziemy zmuszeni wejść do systemu w celu jego naprawy.
UWAGA: Skorzystanie z powyższej pozycji da nieograniczone możliwości dostępu do systemu, albowiem otrzymamy go na prawach administratora.
Konieczne jest zatem, aby doskonale wiedzieć co się w tym momencie robi. Jeśli nie ma się pewności, to najlepiej od razu przejść na uprawnienia zwykłego użytkownika:
su <nazwa_użytkownika>
3. Naucz się korzystać z chroot
Chroot to narzędzie umożliwiające dostęp z jednego działającego linuksa do drugiego i umożliwiające wykonywanie na nim czynności (w konsoli). Czynności te wykonywane będą bezpośrednio na tym systemie i z użyciem jego instalacji.
By nie przedłużać tego wpisu odeślę do poświęconego tej komendzie, tu jedynie wspomnę, że zawsze warto mieć gotowy dysk ratunkowy.

4. Downgrade
Zdarza się niekiedy, że zaktualizowane aplikacje nie działają tak jak powinny, podczas gdy ich starsze wersje działały prawidłowo. Nie zawsze mamy na tyle czasu, by dociekać co jest przyczyną wadliwego działania i próbować to naprawić, czy też czekać na poprawioną wersję w repozytorium. Pomocne może okazać się narzędzie downgrade lub downgrader. Umożliwi nam ono cofnięcie wersji zainstalowanego pakietu a także ewentualne zablokowanie aktualizacji tak cofniętej paczki.
Pamiętajmy również, że jeśli nie czyściliśmy cache pacmana, to znajdziemy tam także starsze wersje paczek. Ich instalację możemy przeprowadzić wydając polecenie:
pacman -U /var/cache/pacman/pkg/nazwa_paczki
5. Repozytorium Seblu
Pamiętajmy również o istnieniu repozytorium ALA w seblu.net. To archiwum m.in. paczek jakie dla Archa były robione od sierpnia 2013 r. W razie zaistnienia potrzeby prosto możemy stamtąd zainstalować pojedynczą paczkę, a nawet uruchomić sobie Archa z repozytorium na określoną datę.

6. Nauczmy się... podstawowych poleceń
Nie wymaga to komentarza. Tu jednak chciałbym przypomnieć o jednym tylko poleceniu pacmana. Zdarza się, że w naszym systemie zainstalujemy paczki nowsze niż są w repozytorium (z AUR, z repozytorium nieoficjalnego, budując we własnym zakresie). Jeśli zaobserwujemy, że system nie działa jak powinien, nie uruchamiają się jakieś programy, być może warto będzie sięgnąć po polecenie, które umożliwi nam dokonanie aktualizacji wraz z ewentualnym cofnięciem paczek zainstalowanych lokalnie do wersji obecnych na serwerze. W takim przypadku powinniśmy wydać polecenie:
pacman -Syyuu

Wiem, że to wierzchołek góry lodowej, niemniej jednak mam nadzieję, że będzie pomocny. Nie wykluczam, że kiedyś jeszcze powrócę do tego tematu, a o chroocie czytajcie niebawem.

Otter-Browser 0.9.91 wersja tygodniowa 166

Wracamy do tygodniowego cyklu. PKGBUILD dla wersji jak w tytule.

piątek, 3 marca 2017

Ksmoothdock

Chociaż możliwości Plasmy w zakresie tworzenia paneli są spore i można bez problemu zaprojektować sobie swój własny "dock" przy użyciu wyłącznie narzędzi, które dostępne są w każdym jej wydaniu, to co jakiś czas pokazują się gotowe rozwiązania tego typu. Nie inaczej jest z pamiętającym czasy KDE 3.x Ksmoothdock, które od wersji 5.x zostało przebudowane tak, by mogło współdziałać z Plasma 5. Narzędzie proste, łatwe i mało zasobożerne. Dla osób, które przyzwyczajone są do robienia wszystkiego w GUI niestety również mało komfortowe w obsłudze, gdyż programy, jakie będziemy mogli obsługiwać z tego panelu musimy konfigurować przez zmianę lub dodanie odpowiednich plików *.desktop do katalogu ~/.ksmoothdock. Inne opcje można już ustawić dość prosto w programie. Niestety jednak nie udało mi się zmusić panelu do autoukrywania, co powoduje - jak dla mnie - niewielki sens jego używania. Niemniej jednak, gdyby ktoś chciał wykorzystać, to załączam PKGBUILD aktualnej wersji 5.0.1.

Otter-Browser 0.9.91 dev165

Z lekkim opóźnieniem przedstawiam PKGBUILD dla wersji 0.9.91 wydanie tygodniowe 165 (kilka wydań zostało wycofanych). Tym razem paczka, która powstanie będzie się nieco różnić, albowiem dodałem do niej "Flat icons for Otter-Browser", o których pisałem już wcześniej. Do czasu oficjalnego dołączenia ich do Otter-Browser, proponuję właśnie takie rozwiązanie.