poniedziałek, 13 kwietnia 2020

AUR dla Manjaro?


Załóżmy hipotetycznie, że opiekunowie paczek z AUR wywiązują się ze swoich (w dodatku przez samych siebie na siebie nałożonych) obowiązków w sposób celujący, a porzucone oprogramowanie w AUR nie istnieje. Załóżmy nawet, że dotyczy to wyłącznie tych paczek, które z AUR używamy. Przyjęcie takiego założenia oznacza, że nowe PKGBUILDy w AUR będą się pojawiać w przynajmniej dwu sytuacjach:
- albo oprogramowanie pojawi się w nowszej wersji,
- albo zaistnieje konieczność przebudowania oprogramowania niezależnie od wersji.
Zastanówmy się teraz przez chwilę jak budowane jest jakiekolwiek oprogramowanie ze źródeł. Otóż oprócz nielicznych wyjątków (np. słynne update-grub, które jest po prostu plikiem wykonywalnym powłoki zasadniczo z jedną linijką polecenia), wszystkie inne mają jakieś zależności. W dodatku dwojakiej postaci. Jedne są to zależności służące wyłącznie do zbudowania paczki. W późniejszym działaniu programu nie są one konieczne. Drugie uczestniczą zarówno w budowie, jak i są wymagane następnie do działania programu. Są jeszcze trzecie - zależności opcjonalne, które również niekiedy są wymagane w procesie budowania paczki. Wszystkie one w chwili budowania tej paczki występują w jakichś wersjach, które aktualnie mamy w systemie. Nie wnikając w szczegóły - są tego typu programy, które zadowolą się niemal dowolną wersją owych zależności, albo też jakąś wersją minimalną, ale są też i takie, które po każdej zmianie (aktualizacji) zależności będą wymagać swej przebudowy. Inaczej działać nie będą. Ta druga sytuacja wymaga od opiekuna paczki w AUR, by po pojawieniu się w repozytorium Archa paczek, na których jest zbudowana dokonał odpowiednich zmian, które zasygnalizują jej użytkownikowi, że wymagana jest ponowna kompilacja paczki.
Przy prawidłowo utrzymywanej instalacji Archa, powinniśmy go mieć aktualizowanego na bieżąco. Zatem paczki budowane z AUR winny być budowane na wersjach swych zależności takich, jakie są dostępne w repozytoriach Archa (i lokalnie w naszym systemie). Jeśli używamy paczek z AUR oznacza to również, że nasze, lokalnie budowane paczki będą dostosowane do aktualnych wersji oprogramowania, które zostało zainstalowane z repozytoriów Archa. Tak skonstruowany system winien działać prawidłowo.
Paczka w AUR nie będzie również wymagać swej przebudowy tak długo, jak długo w repozytorium Archa nie pojawi się nowa wersja jej zależności, której konsekwencją będzie przebudowa.
Ba, może okazać się, że jakaś paczka w AUR wymagać będzie wersji swojej zależności takiej, jaka jest w Archu (sporadycznie, ale zdarzają się takie sytuacje).
Dla niemal wszystkich dystrybucji pochodnych od Archa, korzystanie z AUR jest bez żadnego wpływu. Dystrybucje te wykorzystują bowiem bezpośrednio repozytoria Archa, co najwyżej wprowadzając jakieś swoje, mało istotne z punktu spójności systemu, paczki do swoich repozytoriów (wyjątkiem był, a i to nie w całym zakresie, Antergos, ale ten już nie istnieje). Użytkownicy tych dystrybucji pochodnych mogą zatem korzystać w pełni z dobrodziejstw AUR, są powiadamiani o konieczności zmian, przebudowy paczek z AUR itd. itp.
Spośród znanych mi dystrybucji pochodnych, jest tylko jedna, która dysponuje własnymi repozytoriami oraz umożliwia instalację paczek z AUR. To Manjaro. Ba, nawet ich sztandarowe narzędzie do zarządzania paczkami - pamac - rozszerzać może swe działanie również na AUR. Jednocześnie paczki - choć w bardzo dużej ilości bezpośrednio pochodzące z repozytoriów Archa - są w tym systemie opóźniane o jakiś czas. Od godzin, po tygodnie.
I to wystarcza, by stwierdzić: AUR nie jest dla Manjaro. Niezależnie od tego jak osoby rozwijające Manjaro, czy jego użytkownicy będą zaklinać rzeczywistość - AUR nie nadaje się do stosowania wprost w tej dystrybucji. Oczywiście, że oprogramowanie zbudowane z AUR w tym systemie może działać, ale jeśli tak się dzieje, to jest to przypadek, a nie reguła. Zasadniczo też PKGBUILD paczki z AUR będzie mógł być zastosowany w Manjaro w tym sensie, że doprowadzi na tej dystrybucji do zbudowania paczki, która z nielicznymi wyjątkami będzie działać. Użytkownik Manjaro korzystający z AUR musi mieć jednak wiedzę o niebo większą od użytkownika Archa (i każdej innej jego pochodnej), albowiem będzie musiał wiedzieć kiedy ma dokonać przebudowy paczki i dlaczego. Żadnej pomocy ze strony opiekunów w AUR nie otrzyma, albowiem to repozytorium dostosowane jest do Archa, a nie do Manjaro. Ba, narzędzia dostępne w Manjaro, a zarządzające oprogramowaniem - w przypadku włączenia im obsługi AUR - będą go informować o konieczności przebudowy paczki pomimo tego, że w Manjaro akurat nie jest to wymagane. Gdy później w Manjaro zostaną zaktualizowane paczki w repozytoriach, które w istocie będą wymagać przebudowania paczki z AUR, to w żaden sposób nie zostanie on o tym poinformowany. Użytkownik taki jest zdany sam na siebie i to on musi wiedzieć, że określona paczka wymaga przebudowania i to pomimo tego, że system twierdzi, że jest aktualny.
Wisienką na torcie jest deklaracja, że Manjaro jest adresowane do mniej obeznanych z systemem użytkowników niż użytkownicy Archa, wymaga nieco mniejszej wiedzy.

sobota, 28 marca 2020

Częsty "crash" baloo

Niestety, jak się wydaje, lmdb z którego korzysta baloo sprawia ostatnio sporo problemów i są zamysły by go w baloo porzucić. Owe problemy sprowadzają się do bardzo częstego wywalania się baloo i różnych jego modułów, które możemy zaobserwować już podczas startu systemu. Jeśli obserwujemy takie zjawisko u siebie, to do czasu, gdy baloo zostanie przebudowane przez KDE, być może pomocnym będzie następujące rozwiązanie.
Otwieramy konsolę i wpisujemy:
balooctl purge && balooctl enable
Jeśli baloo u Was działa prawidłowo, nie jest to konieczne. Pierwsze polecenie dokona usunięcia bazy danych indeksów, zaś drugie ponownie uruchomi baloo (bowiem najprawdopodobniej nie będzie działać).

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