czwartek, 5 grudnia 2019

Przywracamy działanie drukarek w CUPS 2.3.0

Co najmniej wraz z nastaniem CUPS 2.3.0 (choć problemy zgłaszane były już w późnych wersjach serii 2.2.x) część (i to spora) drukarek odmówiła współpracy. Nie było też możliwości ich zainstalowania. Problem związany był ze zmianą dokonaną w CUPS polegającą na tym, że przestał on "przyjmować" te PPD (czyli ogólnie sterowniki drukarek), które miały wpisane "Custom" w różnych deklaracjach. Obecnie CUPS przyjmował tam "Other", a "Custom" powodowało, że drukarki stawały się tańszą lub droższą, niemniej jednak wyłącznie ozdobą naszych biur i domów.
Sama zmiana dokonana w CUPS nie była zachcianką jego deweloperów, a powodowana była chęcią uniknięcia sygnalizowanego innego błędu powodującego wykrzaczanie się cupsd. I wszystko dobrze, ale spowodowała unieruchomienie znacznej ilości urządzeń.
Problem nie dotyczy wyłącznie Archa i jego pochodnych, ale dotknął niemal wszystkich w miarę świeżych dystrybucji.
Oczywiście owe PPD winny zostać przerobione przez ich twórców, jednakże znakomita ich część w przypadku "wspierania" linuksa ogranicza się do wypuszczenia sterownika i zapomnienia o nim.
Zasadniczo problemu by nie było, albowiem w tego typu sytuacjach często z pomocą przychodzi cofnięcie CUPS do poprzedniej wersji działającej. Tu jednak pojawił się kolejny problem, a mianowicie w takiej sytuacji koniecznym jest cofnięcie trzech paczek: cups, libcups oraz cups-filters - zasadniczo wszystkie muszą pochodzić z tego samego czasu (tj. być zbudowane w tym samym okresie). Tak przeprowadzona operacja kończyła się najczęściej jednak informacją "Filter failed", co sygnalizowało błąd z cups-filters. I słusznie, albowiem ta paczka wymaga przebudowy wraz z wprowadzeniem do systemu nowej wersji poppler, a ten się pojawił. I znów - w normalnych warunkach wystarczającym remedium powinno być przebudowanie cups-filters na nowym poppler. Niestety to się nie udawało. Cofnięcie poppler do wersji z okresu, w którym wyszły cups-filters nawet nie należało rozważać, albowiem pociągałoby to za sobą konieczność przebudowy znacznej ilości paczek (lub również ich cofnięcia), które muszą być budowane na określonej wersji poppler.
Zatem totalny pat.
Problem jednakże przeleciał różne fora, listy mailingowe. Proponowane rozwiązanie sprowadzało się do edycji pliku PPD i w zależności od porad bądź to usunięciu wszystkich deklaracji ze słowem "Custom" bądź jego zastąpienia słowem "Other'. W części przypadków rozwiązanie takie działało, ale w części drukarka nadal niczego nie była w stanie wydrukować.
Ostatecznie pojawiła się łatka w CUPS, która wejdzie do wersji 2.3.1. Wraz z zespołem POLAUR i kolegów z naszego IRC udało się nam stworzyć PKGBUILD, który buduje cups oraz libcups z nałożoną łatką. CUPS działa prawidłowo, pozwala na instalację drukarek z "wadliwym" PPD oraz drukowanie na nich dokumentów.
PKGBUILD zmienionego cups, jest dostępny w POLAUR pod adresem:
.
Można go zainstalować ściągając, czy kopiując w dowolny sposób zawartość wszystkich plików, które tam są, a następnie budując paczkę z pomocą makepkg.
Prościej można to wykonać z zastosowaniem naszego pak:
pak -P repo-refreshed/cups
Jak zwykle w przypadku PKGBUILDów umieszczanych w repo-refreshed, paczka nosi taki numer wersji, który spowoduje jej aktualizację, w przypadku pojawienia się nowej wersji w repozytorium Archa. W takim przypadku - w zależności od wprowadzonych zmian - albo nie będzie zachodzić już konieczność dalszej opieki nad naszą wersją, albo zostanie udostępniona nowa wersja PKBGUILD. Proszę śledzić wątek na naszym forum: .

W rozwiązaniu problemu chciałbym podziękować naszym kolegom, głównie sir_lucjan oraz arch-jest-super.

piątek, 11 października 2019

Nadchodzi Qt5.14 - nadchodzą kłopoty

W repozytorium kde-unstable pojawiła się pierwsza beta Qt 5.14. Wstępne problemy z niewłaściwym wyświetlaniem elementów Plazmy zostały opanowane (jeśli ktoś używa, to należy bezwzględnie zaktualizować system z uwzględnieniem najnowszej wersji qt5-svg 5.14.0beta1-2). Pozostał jeszcze jeden problem, który wymaga ręcznej ingerencji. Otóż w przypadku, gdy pojawia się ekran blokady SDDM wpisanie hasła powoduje wyłącznie ponowne pojawienie się tego ekranu. Na całe szczęście można przejść do TTY by przynajmniej wyłączyć poprawnie komputer. Można, ale można też łatwo problem rozwiązać. Należy wykasować cache SDDM:
# rm -r /var/lib/sddm/.cache
i od tej chwili znów można się cieszyć normalną funkcjonalnością blokadą ekranu.

piątek, 31 maja 2019

Oprogramowanie 4kdownload w POLAUR

Od pewnego czasu w POLAUR dostępne są aplikacje rozprowadzane przez 4kdownload.com. Są one również dostępne w AUR, ale w nieco innej wersji. Zdecydowałem się na taki ruch, by nieco ułatwić życie osobom, które tego programu używają. Zanim przejdę do informacji o tym, jaka jest zasadnicza różnica między aplikacjami w POLAUR, a w AUR, muszę coś wytłumaczyć.
Otóż oprogramowanie 4kdownload.com jest rozprowadzane na licencjach EULA i nie posiada otwartych źródeł. W przypadku wersji dla linuksa dostępne jest ono w dwu paczkach binarek, obu deklarowanych jako budowanych dla Ubuntu w wersji 64 bitowej. Sama aplikacja (dowolna) pochodząca z 4kdownload.com jest swego rodzaju graficzną nakładką na ffmpeg, korzystając ze porzuconej już gałęzi tego oprogramowania w wersji 2.8. FFMpeg jest dostarczany na licencji GPL3.
Twórcy aplikacji 4kdownload.com, przygotowując swoje paczki dla Ubuntu dostarczają w tych paczkach biblioteki ffmpeg2.8, przy czym gdzieś mają to, że w ten sposób naruszają licencję tego oprogramowania (mogą oczywiście je dostarczać, ale zgodnie z GPL3 nie mogą im zmienić licencji na własnościową, a tak należałoby traktować postanowienia licencji oprogramowania z 4kdownload.com oraz mają obowiązek dostarczać również źródła użytego oprogramowania na licencji GPL3, czego nie robią). Niemniej jednak, budowana statycznie paczka aplikacji 4kdownload.com z wykorzystaniem bibliotek ffmpeg2.8 wbudowanych w te paczki działa i w przeciwieństwie do paczek ffmpeg2.8 budowanych z AUR nie wymaga okresowego jej przebudowania.
Zasadnicza różnica budowanych paczek z POLAUR i AUR jest zatem taka, że w AUR mamy PKGBUILDy dla aplikacji 4kdownload.com zawierające same GUI (same aplikacje), zaś ich zależnością jest ffmpeg2.8, które należy oddzielnie zbudować z AUR (co na niezbyt wydajnych maszynach może sporo trwać). W przypadku paczek budowanych z POLAUR otrzymujemy zawsze dwie paczki: zasadniczą aplikację pochodzącą z 4kdownload.com oraz dostarczane wraz z tą paczką ffmpeg2.8, które nazywa się 4k-ffmpeg i nie jest budowane ze źródeł, lecz jak całość "konwertowane" z paczki dla Ubuntu na paczkę pacmana. Paczki aplikacji oraz 4k-ffmpeg mają inne numery wersji, bowiem aplikacja 4kdownload.com jest dostarczana w bieżącej wersji udostępnianej przez twórców, zaś ffmpeg2.8 w wersji 2.8 (prawdopodobnie odpowiadającej 2.8.15, ale nawet mi się nie chce zbyt zajmować tym z jakich źródeł budowane są te biblioteki, które są dostarczane w paczkach 4kdownload.com). Taki sposób budowania paczek uniemożliwia ich instalację poprzez wydanie polecenia makepkg -i (a i polaur sobie z tym nie poradzi; zob. aktualizację wpisu, albowiem obecnie nie ma problemu z instalacją tych paczek z pomocą polaur)
Dlatego też budując paczki 4kdownload.com z POLAUR musimy postąpić nieco inaczej niż zazwyczaj.
Przede wszystkim musimy dokonać ściągnięcia źródeł niezbędnych do budowy paczki. Źródła te muszą być w formie "plain" - czystego tekstu. Możemy skorzystać np. z wget, możemy dokonać sklonowania całego repozytorium, ale najprościej będzie skorzystać z aplikacji polaur.
polaur -L
wybieramy cyfrę, przy której widnieje wpis aur-rebased (obecnie to 1), następnie d, a następnie cyfrę odpowiadającą paczce, którą chcemy zbudować z widocznej listy. Jeśli nie dokonamy żadnych zmian, to przechodzimy do katalogu z pobranymi źródłami:
cd ~/.cache/polaur/aur-rebased/nazwa_paczki
wykonujemy budowanie paczek:
makepkg -src
oraz instalujemy z pomocą pacmana:
pacman -U *.pkg.*
Jeśli którakolwiek aplikacja z 4kdownload.com jest już zainstalowana w systemie z POLAUR i chcemy doinstalować inną aplikację tego twórcy również z POLAUR, to za pomocą pacmana należy wówczas zainstalować wyłącznie paczkę aplikacji, a nie grupę zbudowanych paczek (co robi ostatnie z poleceń), a zatem:
pacman -U nazwa_paczki

AKTUALIZACJA

Dzięki Damianowi, od dzisiaj dostępny jest nowy skrypt polaur. Zatem jeśli mamy go zainstalowany wystarczy:
polaur -L
wybór repozytorium aur-rebased, wybór b i wskazanie cyfry programu, który nas interesuje.

PS: Tekst powstał z uwagi na niesamowite trudności, jakie komuś sprawia zbudowanie 4kvideodownloader i dyskusji, która prowadzi na manowce, ze stwierdzeniem, że w Manjaro nie da się zbudować tych paczek. Da się "zbudować", bowiem nie polega to na budowaniu i da się zainstalować, choć Manjaro nie jest w żaden sposób przez POLAUR wspierane.

wtorek, 29 stycznia 2019

Przywracanie dotychczasowego wyglądu kickoff w Plasma 5.15

Nadchodzące wydanie Plasma 5.15 powita użytkowników wyglądem Kickoff w "starym" stylu, przypominającym nieco to, co niektórzy być może pamiętają z czasów KDE4. Jest to wynik zaakceptowania zgłoszonego "błędu", który rzekomo powodował, że nowi użytkownicy gubili się w dotychczasowym, domyślnym jego wyglądzie.
Obecnie w Plasma 5.14.90, oraz w nadchodzącym wydaniu będzie on zatem wyglądał tak:

Może się to podobać, niekoniecznie musi. Być może w istocie dla osób, które mają problemy z czytaniem, dotychczasowy mechanizm "Type to search", o czym zresztą sam Kickoff oznajmiał będzie to sporym ułatwieniem. Niemniej jednak mi się to kompletnie nie podoba i według mnie psuje dotychczasowy, estetyczny wygląd Kickoff. Nie tylko mi jak się okazuje. Dlatego też filipwise postanowił zachować dotychczasowy wygląd i udostępnił go w sklepie KDE pn. Unibody Kickoff. W obecnej wersji wystarczy dodać plasmoid mechanizmem GHNS, dokonać restartu Plazmy i ponownie cieszyć się starym, sprawdzonym wyglądem Kickoff:
Przy okazji, kod dostępny jest na github, zaś w POLAUR dodałem PKGBUILD umożliwiający budowę plasma-dekstop zachowującą stary wygląd (występuje jako plasma-desktop-legacy).

poniedziałek, 28 stycznia 2019

Przyspieszamy aktualizację Archa

Jednym ze sposobów przyspieszenia aktualizacji oraz zmniejszenia wielkości danych ściąganych przy tej okazji z internetu jest użycie tzw. delta upgrade. Niestety nie wszystkie serwery to oferują. Znając taki serwer można się jednak pokusić o wprowadzenie odpowiednich zmian.

Przede wszystkim zaczynamy od serwera. W tej chwili znam jedynie takie dwa, w tym jeden z dalekiego RPA. Zasadniczym krokiem jest zmiana pliku /etc/pacman.d/mirrorlist i dodanie na pierwszym miejscu serwera oferującego delta upgrades. Posiłkując się listą z powyższego odnośnika dodajemy zatem:

Server = http://archlinux.uk.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch
Można też dodać drugi serwer z RPA:
Server = http://archlinux.za.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch 
Dokonujemy zmian w pliku /etc/pacman.conf poprzez:
1. usunięcie znaku # sprzed:
- w sekcji [options]
#UseDelta    = 0.7
- w sekcji #Misc options
#UseDelta
2. instalujemy paczkę xdelta3
I... w zasadzie cieszymy się nową funkcjonalnością.
Niestety powyższe serwery nie oferują delta upgrades dla repozytoriów core, extra community. Jeśli zatem korzystamy z innych repozytoriów musimy wprowadzić nieco inne zmiany. Plik /etc/pacman.d/mirrorlist pozostawiamy bez zmian. Dokonujemy edycji wyłącznie pliku /etc/pacman.conf i w sekcjach odpowiadających za repozytoria core, extra, community wprowadzamy powyżej istniejącego tam wpisu:
Include = /etc/pacman.d/mirrorlist
wpis:
Server = http://archlinux.uk.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch
Przy następnych aktualizacjach czy instalacjach powinniśmy odczuć zarówno szybszą instalację, jak i powinno pobierać się mniej informacji. To ostatnie szczególnie winno zadowolić posiadaczy łącz o limitowanej transmisji danych.
Powyższe rozwiązanie ma jednak wadę, albowiem w żaden automatyczny sposób nie sprawdzimy czy serwer ten jest na bieżąco synchronizowany z głównym repozytorium Archa.

Więcej na temat powyższych serwerów znajdziecie w wątku na BBS Archa.

 

środa, 23 stycznia 2019

Konfiguracja gładzika w Plasma Wayland

W sesji Plasma Wayland, za obsługę gładzika (tochpad) odpowiada libinput. Z wiki Archa dowiedzieć się możemy, że biblioteka ta w tej sesji nie posiada żadnych ustawień (z linii poleceń, pliku konfiguracyjnego), a całość obsługi tego urządzenia możemy przeprowadzić z narzędzi konfigurujących dostarczanych wraz ze środowiskiem.
W przypadku Plazmy, takie narzędzie jest dostarczane i od wielu lat znajdziemy je pośród ustawień Urządzeń wejściowych w Ustawieniach systemowych. Dla wielu osób sporym zaskoczeniem może być jednak wejście w te ustawienia w Plazmie uruchomionej w sesji Wayland. Całość ustawień będzie poszarzała i żadne ustawienia nie będą dostępne. Błąd? Oczywiście. Jest nawet zgłoszony (a to jedno z kilku).
Co ciekawe jednak wszelkie ustawienia gładzika są dostępne także w sesji Wayland. Trzeba jedynie moduł zarządzania tymi ustawieniami wywołać z konsoli:
kcmshell5 kcm_touchpad
Korzystając z ustawień gładzika w taki sposób wszelkie opcje będą dostępne.

środa, 12 grudnia 2018

Firefox 64 i okna KDE

Użytkownicy KDE od dosyć dawna narzekają na to, że aplikacje oparte o Gtk mają własne okna dialogowe. Mniejsza o to, które są "lepsze", a które "gorsze". To kwestia pewnych przyzwyczajeń. Jeśli 99% aplikacji zachowuje się w określony sposób, to ciężko przestawia się na inne zachowanie pozostałego procenta aplikacji. Zwłaszcza, że są to często wykonywane operacje, które "wchodzą" użytkownikowi w krew.
Śpieszę zatem donieść, że przynajmniej Firefox w wersji 64 da się zmusić do używania natywnych okien KDE przy otwieraniu plików, czy też zapisywaniu pobieranych przez tę przeglądarkę treści. Ponoć prezentowana tu sztuczka działa również z niektórymi programami. Ponoć również, niektórym nie działa w ogóle (tu mam jednak wątpliwości, czy zostały spełnione wszystkie elementy, które umożliwiają takie zachowanie Firefox w Plasma).

Wpierw musimy odpowiednio przygotować nasz system, w którym muszą być zainstalowane następujące paczki:

  1. firefox >=64.0
  2. xdg-desktop-portal
  3. xdg-desktop-portal-kde

W następnej kolejności musimy poinformować aplikacje Gtk (tu Firefox), aby używał okien natywnych KDE poprzez uruchomienie zmiennej:
GTK_USE_PORTAL=1
Możemy to oczywiście zrobić globalnie dla wszystkich aplikacji, możemy z takim parametrem wywołać Firefox. Osobiście dodałem eksport tej zmiennej do pliku ~/.xprofile i jak na razie Firefox zachowuje się zgodnie z oczekiwaniami, a nie dostrzegam jakichś innych, niepożądanych problemów.
Stosowny plik winien zatem zawierać wpis:
export GTK_USE_PORTAL=1

(SUPLEMENT)
Powyższe rozwiązanie jest właściwe jednakże wyłącznie dla Plasma pracującej w sesji Xów. Plasma-Wayland nie "odczyta" ~/.xprofile. W tym przypadku, teoretycznie (dlaczego "teoretycznie" o tym za chwilę) powinniśmy dokonać edycji pliku ~/.config/environment.d/envvars.conf i tutaj dodać:
GTK_USE_PORTAL=1
W zasadzie tego typu rozwiązanie winno umożliwić również pracę z natywnymi oknami dialogowymi Plasmy w Firefox także w sesji Wayland.

Napisałem wcześniej "teoretycznie", gdyż - znów teoretycznie dla Xów moglibyśmy stosowny wpis dodać do ~/.xinitrc. Sprawdzałem - niekoniecznie to chce działać. I to nie tylko w moim przypadku. W sieci pojawiają się też pomysły na rozwiązanie sprawy poprzez stworzenie pliku firefox.desktop dla danego użytkownika i dodanie odpowiednich wpisów. Znów -powiem: u mnie nie bardzo chce to działać i trudno mi powiedzieć dlaczego.

niedziela, 9 grudnia 2018

POLAUR - paczki KDE z łatkami

Od dłuższego czasu w POLAUR, w repozytorium repo-refreshed umieszczam PKGBUILDy dla różnych składników oprogramowania pochodzącego od KDE z tzw. bugfiksami. W największej części są to te, które były zgłaszane w bugs.kde.org.
Stosowane są przeze mnie (i jeśli ktoś chciałby również się dołączyć, to również prosiłbym o ich stosowanie) następujące zasady:
1. Numeracja paczek
a. Paczki zawsze mają numer wersji (pkgver) takie jak paczka źródłowa, na którą patch jest nakładany.
b. Paczki różnią się wersją "realizacji" (pkgrel), przy czym numer ten jest zawsze wyższy niż wersja w repozytorium, ale zawsze też niższy od wersji, która w repozytorium może się pojawić (np. wskutek koniecznego jej przebudowania ze względu na zmiany innych elementów, tego wymagających). Kolejne wersje z patchami mają zawsze nowy numer pkgrel z zachowaniem powyższej zasady.
Przykład:
  • jeśli paczka w repozytorium Archa ma numer np. 5.53.0-1, to pierwszy PKGBUILD z patchem będzie miał wersję 5.53.0-1.1, następny 5.53.0-1.2 itd.
Taki sposób umożliwia aktualizację do wersji z repozytorium Archa, gdy nowe wersje paczek (także pkgrel) się pojawią.
UWAGA: może się zdarzyć, że będzie tu jakiś "przeskok" wersji np. po pkgrel x-1.1 będzie x-1.3, a gdzieś "zgubiona" zostanie wersja x-1.2; proszę się nie obawiać, wynika to wyłącznie z faktu, że prawdopodobnie u siebie z jakichś przyczyn przebudowałem w międzyczasie paczkę i ona uzyskała "brakującą" numerację.
c. Jeśli w repozytorium Archa pojawi się nowa wersja paczki, która naprawia ten sam błąd, który wcześniej został poprawiony przeze mnie w PKGBUILDzie w POLAUR, to taki PKGBUILD jest z niego usuwany.
d. Jeśli w repozytorium Archa pojawi się nowa wersja paczki, ale nie zawiera patchy, które wcześniej udostępniłem, to w POLAUR pojawi się nowa wersja paczki dostosowana do aktualnej numeracji wersji w repozytorium Archa z zachowaniem reguły z pkt. 1 a i b.
Patche
a. Patche pochodzą z repozytorium GIT KDE. Mogą pochodzić także z phabricator.kde.org. W każdym przypadku, podczas budowania paczki jesteście powiadamiani o tym jaki patch zostaje nałożony zgodnie z następującymi zasadami:
- patch odnoszący się do bugs.kde.org oznaczony jest przez "KDEBUG numer_zgłoszenia"; jeśli patch naprawia więcej niż jedno zgłoszenie, najczęściej są podawane wszystkie, choć sama łatka może być jedna,
- inne patche są oznakowane "Dnumer_phabricator".
W pierwszym przypadku przeglądnąć tak zgłoszenie, jak i sam patch można poprzez wpisanie "numer_zgłoszenia" na stronie bugs.kde.org. W drugim przypadku przez wpisanie Dnumer_phabricator na stronie phabricator.kde.org.
- w nielicznych przypadkach stosuję opisowe oznaczenie łatki (jeśli - co niezmiernie rzadkie - nie będzie ona miała swojego odzwierciedlenia ani w bugs.kde.org ani w phabricator.kde.org).
Informacje o patchach
Podczas budowy paczek jesteście powiadamiani o tym jaki patch jest nakładany oraz - o ile wiem - w jakiej wersji oczekiwana jest jego implementacja. Ostatnią zasadę - tak wyraźną - wprowadziłem w tym tygodniu, a zatem nie wszystkie PKGBUILDy zostały jeszcze do tego dostosowane. Jeśli nie wiem w jakiej wersji zostanie patch uwzględniony, niekiedy opisuję to w PKGBUILDzie (kiedy jest spodziewany). Stosowna informacja podczas kompilacji paczki wygląda np. tak:
Add KDEBUG 123123 patch; fix in 5.15.0
Oczywiście w ten sam sposób jest to opisane w PKGBUILDzie. W starszych wersjach opis odnoszący się do tego w jakiej wersji oczekiwane jest wdrożenie patcha występuje wyłącznie w PKGBUILDzie.
Również z moich ogłoszeniach na forum pojawia się informacja o tym jakie łatki zostały uwzględnione. Przed budową paczki możecie sobie ocenić, czy warto.
Konieczność budowy wszystkich paczek z POLAUR
Krótko: nie istnieje. Możecie budować wybrane. Jeśli będzie taka okoliczność istnieć to PKGBUILD zostanie tak przygotowany, że uniemożliwi budowę paczki, jeśli inny pakiet z POLAUR nie jest zbudowany i zainstalowany. Informacja o tym pojawi się również w ogłoszeniach.
Częstotliwość ukazywania się
Staram się dodawać łatki na bieżąco. Zwykle tuż przed pojawieniem się nowej wersji nie dodaję już nowych łatek do POLAUR. Mogłoby się tak zdarzyć wyjątkowo, gdyby błąd był poważny, a arojas z jakiegoś powodu nie zareagował.
Rodzaje łatanych błędów
Staram się dodawać patche tylko na poważniejsze błędy. Moim zdaniem szkoda męczyć komputer tylko dlatego, że w kolejnym wydaniu np. jakieś okno będzie ładniej wyglądało. Jeśli ktoś jednak i takie łatki chciałby mieć nałożone - proszę zgłaszać w odpowiednim miejscu. Niektóre jednak z tego typu łatek powędrują do repozytorium pkg-trunk.
Testowanie paczek z nałożonymi łatkami
Wszystkie paczki są przeze mnie budowane i testowane. Bugfiksy z bugs.kde.org przechodzą też testy deweloperskie. Bugfiksy z phabricator.kde.org również, ale mogą one nie być przetestowane przez deweloperów tak wnikliwie. Są one jednak zawsze przez nich zaakceptowane.
Proszę jednakże zwrócić uwagę na to jaki ja mam system (jest zawsze w stopce), jakich repozytoriów używam oraz, że... mam jeden komputer. Nie mam zatem możliwości sprawdzenia jak się zachowuje taka paczka na każdej, możliwej konfiguracji sprzętowej.
W razie wątpliwości - wiecie gdzie mnie szukać.
PS: UWAGA - O ile paczki z POLAUR nadają się dla Archa oraz jego bezpośrednich forków /czyt. takich, które korzystają z jego repozytoriów bezpośrednio/ to najprawdopodobniej nie będą właściwe dla Manjaro - proszę ich tu nie używać. Nie udzielam też absolutnie żadnego wsparcia użytkownikom Manjaro, którzy zbudują sobie paczki na podstawie moich PKGBUILDów.

wtorek, 4 grudnia 2018

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl. Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia.
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.
Inny forumowicz poleca zatem... dodanie repozytorium nexus do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, że przecież aktualną paczkę spotify dało się rozpakować i "działa jak portable".

I w takim momencie ręce opadają.

Po pierwsze - o ile istnieje jakaś możliwość w dodawaniu repozytoriów nieoficjalnych do Archa, albowiem są one budowane w oparciu o paczki z Archa, to dodawanie takiego repozytorium do Manjaro, szczególnie w wersji "stable" jest proszeniem się o kłopoty. To nic, że dodana paczka może nie pracować, ale doprowadzić to również może do podmiany paczek, które dostarczane są wraz z Manjaro i zbudowane (mam nadzieję) w oparciu o paczki dostępne w tej dystrybucji przez paczki z innej. Wiadomo również, że paczki udostępniane w repozytorium stable Manjaro są w stosunku do Archa opóźnione o jakiś czas (różny). Można oczywiście twierdzić, że przy rozważnym "gospodarowaniu" takim systemem z pomieszanymi repozytoriami nic się nie stanie. Problem jednakże w tym, że skoro jeden użytkownik innemu radzi bez zająknięcia tego typu operację, to oznacza wyłącznie, że poziom świadomości na temat używanego systemu niekoniecznie musi być wysoki.

Po drugie - wprowadzanie do systemu obcych paczek przez ich rozpakowanie (mniejsza o to, czy to deb, czy rpm - bo to najczęściej stosowane "porady"). Dokonując prostego rozpakowania (ar) paczki deb, bądź też stosując do tego dpkg lub rpm (są takie kretyńskie porady dostępne w sieci) nie mamy żadnego wpływu na to jak one zostaną rozpakowane. Jeśli taka paczka zawiera jakiś plik o takiej samej nazwie i w takiej samej lokalizacji, jaką już mamy w systemie, to rozpakowane w ten sposób paczki deb, czy rpm po prostu dokonają nadpisania paczki systemowej przez tę, która z niej pochodzi. Zwróćmy teraz uwagę, że szczególnie paczki deb są bardzo często budowane w oparciu o bardzo stare komponenty w stosunku do tych, które są w Archu, czy nawet w Manjaro. Czym ryzykujemy - pomijam już inne kwestie i aby skrócić wpis napiszę wyłącznie - ot, choćby tym, że po "udanej" instalacji takiej paczki możemy być bardzo krótko zadowoleni. Do zrestartowania systemu, który może się już w ogóle nie obudzić.

Będę to powtarzać jak mantrę, bo jak widzę roztropności w narodzie brak: do instalacji jakichkolwiek programów w Archu (i pochodnych) służy wyłącznie pacman. Jeśli paczki nie ma należy ją zbudować na podstawie odpowiednio napisanego PKGBUILDu (są nawet miejsca, gdzie można zgłaszać zapotrzebowanie). Każde inne działanie jest działaniem przeciwko własnemu systemowi. Nie liczcie, że potem ktokolwiek będzie Wam w stanie pomóc. Jedyne wyjątki od tej reguły, to instalacja paczek w tzw. uniwersalnych formatach.

A najśmieszniejsze (o ile w ogóle komukolwiek do śmiechu) jest to, że napisanie poprawnego PKGBUILDu instalującego nową wersję spotify nie trwa dłużej niż kilkadziesiąt sekund.

piątek, 9 listopada 2018

A jak alias

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

czwartek, 4 października 2018

Jak uniknąć problemów z Antergosem

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

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

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

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

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

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

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

czwartek, 20 września 2018

Przyciski OK i Anuluj aplikacji Gtk jak w Qt

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

Na podstawie porady z BBS Arch Linux.