sobota, 11 listopada 2017

Koniec 32 bitowych paczek w Arch Linux

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

wtorek, 31 października 2017

AMDGPU dla GCN1 i GCN2 i kerneli >=4.13

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

wtorek, 24 października 2017

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

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

poniedziałek, 23 października 2017

KDEPIM bez kopii zapasowej?

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

Qt 5.10 beta 1

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

niedziela, 17 września 2017

KMarkdownWebViewer

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

Plasma 5.10.95 aka 5.11Beta

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