ś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.