środa, 28 czerwca 2017

LibreOffice 5.4RC1 oraz 6.0alpha0

Od jakiegoś czasu są rozwijane wersje, które stanowić będą następców obecnych wydań LO. Ciekawostką, że wersja 5.4.x będzie ostatnią w linii 5.x, a dostępna od przyszłego roku będzie już linią 6.x. Wersje testowe 5.4 są już dostępne ze strony LO, także dla linuksa, jednakże - jak zwykle - są to wydania deb i rpm. Oczywiście są udostępnione także źródła. Wersja rozwojowa 6.0 jest głębiej ukryta i dostępna bezpośrednio z serwerów Document Foundation. W odróżnieniu od 5.4RC1 w tej wersji nie możemy się jeszcze spodziewać spolszczenia, choć możliwe jest oczywiście korzystanie z polskich słowników, czy innych reguł pisania. Jak zwykle namawiam osoby, które są chętne do testowania, by choćby w ten sposób włączyły się w rozwój oprogramowania. Jest jeszcze czas, by usunąć jakieś ewentualne niedoróbki. Jeśli zatem ktoś zechciałby się włączyć, to mogę zaproponować obie wersje pakietów (w przypadku 6.0 także z "instrukcją obsługi" jak ją aktualizować) dla Archa (także dystrybucji pochodnych). Oba pakiety są przebudowywane z oryginalnych paczek rpm i mogą zostać zainstalowane obok libreoffice-fresh/still. Nie ingerują też w żaden sposób w ustawienia wersji z repozytorium. Nie będę tym razem zamieszczał PKGBUILDu - gdyby ktoś zechciał się zdecydować - proszę o kontakt.

czwartek, 22 czerwca 2017

Dlaczego nie instalować pojedynczych paczek innych gałęzi systemu

Dystrybucje linuksowe zwykle zawierają "przejściowe" repozytoria, gdzie testowane są nowe paczki. Niektóre dystrybucje, z owych repozytoriów tworzą nawet niemal oddzielne gałęzie swych dystrybucji, a społecznościowa gawiedź dośpiewuje całą resztę, upatrując np. w Debian Testing ucieleśnienia dystrybucji rolling release. Zostawmy jednak Debiana, skupmy się na Archu i pokrewnych. W Archu dostępnych jest kilka repozytoriów. Podobnie w Manjaro. W strukturze repozytoriów tego pierwszego znajdziemy repozytoria z "dopiskiem" testing i dwa repozytoria z "dopiskiem" unstable (kde i gnome). Struktura gałęzi Manjaro jest praktycznie przeniesiona z Debiana, choć absolutnie niewiele ma z nim wspólnego. Ograniczę się do omówienia Archa, jednakże to samo ma zastosowanie do innych dystrybucji rolling release (to jest kluczowe), na pewno natomiast ma to 100% zastosowanie do dystrybucji, gdzie paczki zarządzane są przez pacmana. Otóż pojawiają się wpisy omawiające sposób zainstalowania pojedynczej paczki z innej gałęzi (repozytorium testowego, niestabilnego) danej dystrybucji. Jest to bardzo nieodpowiedzialny pomysł, choć realizowany wg zasady: chcącemu nie dzieje się krzywda. Oczywiście, że istnieje możliwość zainstalowania czegokolwiek, skądkolwiek i w jakiejkolwiek wersji. Zastanówmy się jednak co to oznacza i czy na pewno "możliwość" oznaczna, że "można". Przede wszystkim należy przypomnieć jedną sprawę: pacman nie wspiera częściowej aktualizacji. Uświadomijmy sobie również, że taka instalacja nowej wersji z testowego repozytorium jest niczym innym, jak właśnie dokonaniem częściowej aktualizacji. Operacja może się udać. Program zainstalowany w ten sposób może działać prawidłowo. Może jednakże nie działać wcale, może okazać się działającym wadliwie (np. niestabilnie). Może też doprowadzić do destabilizacji całego systemu, a w skrajnych przypadkach po prostu go nie uruchomimy ponownie (w obu przypadkach, gdy np. zmieniliśmy jakiś kluczowy jego element, bibliotekę, na która jest zależnością innych paczek). Dlaczego tak się dzieje? Otóż dystrybucje takie jak Arch są robione w taki sposób, że ich deweloperzy starają się zapewnić właściwą pracę zaktualizowanego systemu. Paczki znajdujące się w określonym repozytorium są budowane w taki sposób, że ich zależności znajdują się w tym właśnie repozytorium. Owe zależności oznaczają nie tylko "nazwę paczki", ale też jej określoną wersję, która w tym repozytorium się znajduje. Paczki w repozytorium "stabilnym" winny zatem być w korelacji ze sobą. W repozytorium testowym będą paczki skorelowane ze sobą. Jeśli zatem jakaś paczka będzie wymagała jakiejś zależności w określonej wersji, to owa paczka w takiej wersji się znajdzie. I odwrotnie - jeśli jakaś zależność spowoduje konieczność przebudowania jakiejś paczki, to taka przebudowana paczka tam się znajdzie. To właśnie dlatego pacman nie wspiera częściowej aktualizacji. Musimy sobie uświadomić jeszcze jedną rzecz. Otóż w przeciwieństwie np. do APTa, w PKGBUILD bardzo rzadko znaleźć można określenie wersji konkretnej paczki stanowiącej zależność. Przy instalacji poszczególnej paczki nie zostajemy zatem powiadomieni o tym, że jakaś paczka nie jest kompatybilna z wersją instalowaną. Arch (Manjaro) - to Arch. Bardzo prosta w budowie dystrybucja, jednak trzeba o nią dbać, a nie gwałcić ją na siłę. Chyba, że doskolane wiemy co robimy, wiemy, że instalacja czegoś pociąga konieczność zmiany innej paczki itd. itp. Co zatem zrobić, jeśli z jakiejś przyczyny bardzo musimy mieć wersję paczki znajdującej się w gałęzi (repozytorium) innym niż używane? Trudno - innej drogi nie ma - choćby czasowo musimy zainstalować wszystkie paczki w tej samej wersji (testowej), w jakiej potrzebujemy mieć określoną (jedną) paczkę. W Archu robimy to "ręcznie" udostępniając repozytoria testowe. W Manjaro możemy wydać polecenie:
sudo pacman-mirrors -g -b testing (lub unstable)
I dokonać pełnej aktualizacji:
sudo pacman -Syu
Jeśli później zechcemy wrócić do "gałęzi" poprzedniej, powinniśmy w Archu zakomentować repozytoria testowe, w Manjaro wykonać:
sudo pacman-mirrors -g -b stable (lub testing)
I... dokonać pełnej aktualizacji systemu z jednoczesnym wgraniu w miejsce istniejących lokalnie wersji paczek, tych, które znajdują się na serwerze, nawet jeśli są one w wersji niższej od lokalnej:
sudo pacman -Syuu

Naprawiamy wadliwe źródła w PKGBUILD

Zdarza się, że przy budowie jakiejś paczki z AUR otrzymujemy taki błąd:
==> BŁĄD: Błąd podczas pobierania http://jakiś_adres
Przerywam...
Najczęściej powodem tego błędu jest wadliwy adres źródła. Może to być spowodowane tym, że zmianie uległa wersja programu, a źródeł starej już nie ma, może być spowodowane zmianą adresu źródła, powodem może być też, że źródła w ogóle zostały usunięte, może to być też jakiś czasowy problem z połączeniem. Ostatnie - proste - można spróbować po chwili. Na całkowite usunięcie źródeł możemy nie zaradzić wcale. Jedyne co mogę sugerować to poszukanie w necie, czy gdzieś nie są one oferowane w innej lokalizacji. W tej sytuacji powinniśmy jednak mieć pewność co do poprawności paczki oferowanej nie przez jej autora. Pierwsze dwa są dość proste do naprawienia. Generalna zasada: odszukać źródła. Wchodzimy na stronę AUR z PKGBUILDem, znajdujemy URL źródła, przechodzimy i czytamy co się zmieniło. Oczywiście informujemy również opiekuna takiej paczki w AUR o zaistniałym problemie. Możemy też przedstawić mu wyniki analizy naszego skromnego dochodzenia - korekta w AUR może się pojawić szybciej. W każdej z poniższych sytuacji wykorzystujemy sposób instalacji paczek bez tzw. aurhelperów. Przypomnę zasady: - ściągamy tzw. źródła budowania paczki z AUR np.:
git clone https://aur.archlinux.org/nazwa_paczki.git
- w katalogu, z którego wydaliśmy to polecenie powstanie podkatalog o nazwie nazwa_paczki, przechodzimy do niego:
cd nazwa_paczki
- dalsze operacje wykonujemy na pliku PKGBUILD, który znajdziemy w tym katalogu. 1. Oferowana jest nowa wersja i nie jest dostępna stara. Po pierwsze oflagujmy paczkę w AUR jako nieakutalny (ramka po prawej stronie). Po drugie, w zależności od tego, czy czujemy się na siłach, możemy spróbować zainstalować paczkę w nowszej wersji. W tym celu: - zmieniamy zawartość pola pkgver na taką wersję, z jaką napotkaliśmy się na stronie domowej programu, - dokonujemy ewentualnej zmiany w polu source na korespondujący z nową wersją; jeśli w tym polu będzie adres posługujący się zmienną wersji źródła (tj. zobaczymy np. coś takiego:
jakiś_adres/coś-$pkgver_coś
to PKGBUILD posługuje się zmienną ($pkgver) w celu ustalenia adresu źródła - w tej sytuacji nie powinniśmy mieć potrzeby dokonywania jakichkolwiek zmian, jeśli jednak w adresie tym znajdziemy jakieś cyfry wskazujące na właśnie co zmienioną wersję w polu pkgver to i w adresie musimy je zmienić. - sprawdzamy, czy pozostałe sekcje PKGBUILD posługują się ewentualną zmienną numeru wersji ($pkgver), czy też jej numerem - w tym drugim przypadku zmieniamy na nowy numer wersji, - wykonujemy polecenie:
updpkgsums && makepkg -sirc
- liczymy na to, że operacja się udała. Jeśli operacja się nie udała, pozostaje nam czekać na podbicie wersji w AUR bądź zwrócić się do społeczności o pomoc. Chyba, że sami jesteśmy w stanie poradzić sobie z problemem. W tym ostatnim przypadku dobrze jest choćby w komentarzach na AUR podać rozwiązanie. 2. Zmianie uległ adres źródła. Po pierwsze zawiadamiamy o tym opiekuna paczki w AUR. Po drugie zmieniamy zawartość pola source na właściwy adres (najprościej będzie nam po prostu go wkleić w miejsce dotychczasowego) wykonujemy polecenie:
updpkgsums && makepkg -sirc
3. Źródła zostały usunięte, ale znajdują się w innej lokalizacji. Jeśli jesteśmy ich pewni, to postępujemy dokładnie tak samo jak w punkcie 2. 4. Czasowy problem z dostępem do serwera ze źródłami. Jak już napisałem - poczekać. Jeśli jednak bardzo nam zależy na szybszym zbudowaniu paczki, możemy spróbować znaleźć w necie jakiejś alternatywnej lokalizacji źródeł i postąpić jak w punkcie 2.

środa, 21 czerwca 2017

Czy muszę mieć uprawnienia root, by sprawdzić możliwość aktualizacji?

Oj, tam. Psioczymy niekiedy na nasz system (Arch), a nie znamy jego możliwości. Psioczymy na przykład, że aby sprawdzić możliwość aktualizacji systemu musimy wydać jakieś polecenie, wpisać hasło administratora i dopiero potem dowiemy się, czy aktualizacja jest możliwa. Innymi słowy, wpisujemy w terminalu:
sudo pacman -Syu
No dobrze, a czy korzystając z dobrodziejstw zainstalowanych wraz z pacmanem nie możemy napisać:
checkupdates
...? Nie musimy wpisywać haseł administratora, niczego. Po chwili uzyskamy informację czy jest, czy też nie jest możliwa aktualizacja systemu.

wtorek, 20 czerwca 2017

Aplikacje KDE pozwolą na roota. Bezpieczeństwo i wolność

Nie tak dawno - tu i ówdzie - podniosła się wrzawa, że KDE w imię bezpieczeństwa odbiera wolność użytkownikom, uniemożliwiając wykonywanie działań wymagających uprawnień administratora w aplikacjach KDE. To nic, że "problem" dotyczył wyłącznie trzech aplikacji: kate, kwrite i dolphin. To nic, że dotknął jedynie tych dystrybucji, które zaoferowały KF w wersji co najwyżej 5.33 oraz jednocześnie aplikacje z wersji 17.04.0. Jednocześnie z opublikowaniem tej wersji, zostało wprowadzone obejście, umożliwiające edycję plików wymagających uprawnień administratora przez kate i kwrite. Mimo wszystko problem był, a w zasadzie to został sztucznie rozdmuchany, zwłaszcza, że już w chwili jego (problemu) tworzenia była znana informacja na temat zmian, jakie w 2017 r. czekają KIO z KF5. Realizując założenia zmian w KIO na ten rok, już 13.05.2017 r. zostało udostępnione publicznie KF5.34, które przywróciło możliwość edycji plików wymagających uprawnień administratora przez kate i kwrite bez bez wspomnianego obejścia (gwoli pełnej informacji, KDE Applications 17.04.0 pojawiło się publicznie 20.04.2017 r.). Od tej chwili możliwe była zatem edycja np. plików systemowych, a przy próbie ich zapisu system prosił o hasło administratora. Wszystko dzięki zmianom w KIO i połączeniu go z mechanizmem polkit. Tym samym zwiększono bezpieczeństwo bez zmian funkcjonalności. Pozostał "problem" jedynie z dolphinem, który uniemożliwiał operacje na plikach systemowych (inna sprawa, że prawidłowo skompilowany krusader takich problemów nie miał i nie ma). Stąd też np. powstawały forki typu dolphin-root, różniące się od oryginału wyłącznie cofnięciem zmiany uniemożliwiającej takie działania. Ba, dolphin-root pojawił się nawet w repozytoriach niektórych dystrybucji. Śpieszę zatem donieść, że i ten "problem" przestanie niebawiem istnieć. Otóż wprowadzone niedawno przez Chinmoya Ranjana Pradhana zmiany w KIO zostały właśnie połączone z kodem KF5 i już w nadchodzącym wydaniu KF5.36 (planowane na 8.07.2017 r.) dolphin odzyska możliwość pracy również na plikach systemowych. Mechanizm wprowadzonej zmiany ten sam, jak w przypadku kate i kwrite, czyli wykorzystanie polkit. Jeśli ktoś bardzo chciałby skorzystać z tej funkcjonalności obecnie, to musiałby zbudować KF5 z git i niestety nie wystarczy samo KIO, albowiem zmiany nadchodzące w wydaniu 5.36 są na tyle duże, że nie jest możliwym budowa samego KIO z git bez zbudowania komponentów, na których się opiera. Można ewentualnie spróbować użyć udostępnionych patchy (dla dolphin), jednakże ich wbudowanie wymaga również spatchowanej wersji KIO (tj. dodania tych funkcjonalności, które właśnie zostały tam wprowadzone (dot. JobUiDelegate). Teraz pozostaje mieć nadzieję, że z wprowadzonych mechanizmów z czasem zaczną korzystać inne aplikacje wykorzystujące Xy, a umożliwiające pracę w przestrzeni administratora. Problem bowiem nie jest tak trywialny, jak się niektórym wydaje, że dotyczy to tylko i wyłącznie wprowadzenia do systemu niezamierzonych zmian przez użytkownika.

poniedziałek, 19 czerwca 2017

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy:
[DEB_Arch_Extra]
SigLevel = Optional TrustAll
Server = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/
Nadto musimy jeszcze dodać klucz:
gpg --receive-keys BF8B66E01192CBA2E72201294B4E7A9523ACD201
Instalujemy megasync oraz - jeśli chcemy - dowolny dodatek do naszego menedżera plików. Od tej pory możemy się cieszyć łatwym dostępem do dość potężnej chmury. Oczywiście, o ile mamy tam utworzone konto.

czwartek, 15 czerwca 2017

Aplet informujący o aktualizacjach w Archu

Choć zrobiony w istocie z myślą o Archu, to sądzę, że prawidłowo będzie działał w każdym systemie korzystającym z checkuptades - oto pojawił się nowy, integrujący się z Plasmą 5, aplet informujący nas o możliwych aktualizacjach systemu. Nazwa jaką przyjął w sklepie KDE to Arch Linux System Tray Update Notifier and Upgreader i jej przeczytanie trwa chyba dłużej niż budowa tego programiku. Jak wspomniałem, aplet wykorzystuje checkupdates, a dzięki temu nie potrzebuje uprawnień administratora. Posiada podstawową możliwość konfiguracji ograniczającą się do ustawienia częstotliwości sprawdzania aktualizacji (którą to funkcję można również wymusić niezależnie od ustawień) oraz możliwości pomijania numeru wersji przy opisach paczek przeznaczonych do aktualizacji. Nadto - gdy takie się pojawią - możliwe jest wywołanie pacmana i przeprowadzenie aktualizacji systemu. Dla osób korzystających z Plasma 5 oraz niekorzystających z Octopi to obecnie chyba jedyne takie narzędzie. Zainstalować je możemy albo przez mechanizm GHNS, albo za pomocą tzw. OCS-install, albo... wykorzystując taki PKGBUILD.

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. Bez tych programów, plasma-vault nie zbuduje krypt. Pierwszy z nich zainstalujemy z repozytorium, drugi musimy zbudować z AUR. Program integruje się z Plasma doskonale, rezyduje w tacce systemowej i to stąd mamy dostęp zarówno do tworzenia krypt, jak i ich obsługi. Program tak prosty w obsłudze, że nie wymaga chyba żadnego komentarza.

środa, 14 czerwca 2017

Kolorystyka aplikacji wykorzystujących kdelibs w Plasma 5

Kiedyś już pisałem co zrobić, by zmusić do działania LibreOffice, tak by respektowało kolorystykę ustawioną w Plasma. Niestety jednak nie zawsze to działa. Czas zatem na brutalne metody. Najpierw jednak chwila refleksji. Otóż LibreOffice jest aplikacją, która usiłuje się upodobnić do środowiska. Jeśli niczego nie zmieniamy i jeśli pracujemy w środowisku, które LibreOffice rozpozna jako KDE, to próbuje upodobnić się do... KDE4. Co zatem powoduje, że rozpoznaje to środowisko jako KDE? Otóż istnienie w systemie starej biblioteki KDE4 o nazwie kdelibs. Skoro tak, to ustawienia właśnie dla KDE4 będą respektowane przez LibreOffice (podobnie jak wszystkich innych aplikacji, które jeszcze nie zostały przeportowane do Qt5/KF5, jak choćby amarok). Teoretycznie sama Plasma winna zapewnić spójność wyglądu aplikacji KDE4/Qt4 z jej ustawieniami. Niestety nie zawsze jej to wychodzi. I tu właśnie pora sięgnąć po owe brutalne metody, o których wspomniałem. Przede wszystkim musimy sobie uświadomić gdzie są przechowywane ustawienia kolorystyczne Plasmy oraz aplikacji KDE4. W jednym i drugim przypadku jest to plik o nazwie kdeglobals, który jednakże w obu tych wersjach nieznacznie się różni. Natywne aplikacje KF5 wykorzystują plik znajdujący się w ~/.config/. Aplikacje KDE4 (i te, które z tych ustawień korzystają) poszukują tego pliku w ~/.kde4/share/config. Zasadniczo oba pliki w zakresie ustawień kolorystycznych winny być takie same. W przypadku wystąpienia różnic (np. LibreOffice ma odmienną kolorystykę), należy dokonać przekopiowania odpowiednich ustawień z pierwszego do drugiego pliku. Od tej chwili wszystko powinno być już w porządku.

Opowieść o tym jak baloo zżera zasoby komputera

Wraz z akonadi, to część KDE, który podawany jest zwykle jako argument na bezsensowność tego środowiska, jego przerośnięcie i ogromny apetyt na zasoby. Już nie tylko RAM, ale i CPU, którego potrafi zagospodarować np. cały jeden rdzeń. Komputer zwalnia, źle pracuje. Wszystkiemu oczywiście winne baloo. Czyżby? Nie na darmo mówi się, że największy błąd oprogramowania siedzi przed komputerem i z niego "korzysta". Ów element zwany użyszkodnikiem może jednak pomóc baloo. Kiedyś już pisałem o tym, jak można ustawić ten komponent. Także wyłączyć. Załóżmy jednak, że chcemy z niego korzystać i jednocześnie nie chcemy, by zużywał 100% rdzenia CPU, czy np. 1 (i więcej) GB RAM. Czy to możliwe? Oczywiście. U mnie np. baloo zużywa ok. 2MB RAM i zasadniczo pomijalny ma apetyt na CPU. Zwykle zużycie wynosi poniżej 1%, a najczęściej sobie śpi. Otóż częstą przyczyną nadmiernego zużywania zasobów przez baloo jest nakazanie mu indeksowania nieistniejących katalogów. W wielu dystrybucjach baloo jest domyślnie włączane. Jego pierwotnym ustawieniem jest indeksowanie katalogu domowego użytkownika wraz z wszystkimi podkatalogami. Jednocześnie nie indeksuje plików ukrytych, oraz niektórych typów plików. Indeksuje również nie tylko nazwy, ale i zawartość plików. W niektórych dystrybucjach, instalator zakładając konto użytkownika, jednocześnie stworzy w nim domyślne katalogi, które przyjmą angielskie nazwy. Wystarczy by użytkownik dokonał w jakikolwiek sposób (czy to programowo, czy też ręcznie) ich zmian np. na polskie odpowiedniki oraz jednocześnie wykasował zbędne już katalogi i wówczas baloo zaczyna mieć apetyt na olbrzymie ilości zasobów. Niestety baloo nie wie, że jakiś katalog został usunięty i próbuje go zindeksować. Podobnie będzie się działo również, gdy jakieś katalogi wykluczyliśmy z indeskowania, a następnie katalog ten został skasowany. Prosty trick polega na tym, by pamiętać o bardzo podstawowych zasadach: Kiedy zmieniamy nazwy, bądź kasujemy jakieś katalogi, które podlegają indeksowaniu, bądź też zostały przez nas z indeksowania wyłączone, to - wstrzymajmy albo nawet lepiej wyłączmy baloo, - po dokonaniu zmian w strukturze katalogów zmieńmy odpowiednio ustawienia w baloo, a w szczególności usuńmy zbędne, bo nieistniejące katalogi, które znajdują się w jego ustawieniach, - włączmy od nowa baloo i pozwólmy mu chwilę w spokoju ponownie zindeksować bazę. W ten sposób, po chwili, gdy dokona pierwszego (czyli nowego) indeksowania, gdzie w istocie zapotrzebowanie na zasoby może być widoczne (ale bez przesady, to w porywach 3 do 5% CPU mojego niezbyt wypasionego APU i nieco większe od wskazanego wyżej zapotrzebowanie na RAM), baloo stanie się praktycznie niewidoczny dla systemu. Pamiętajmy jednak o wykluczeniu z indeksowania zbędnych plików (czyli zbędnych katalogów bądź zbędnych typów).

sobota, 3 czerwca 2017

Hardcore - Kompilacja programu pod własny procesor, cz. 4 - cmake

Kontynuując ten mini cykl, pozostało mi jeszcze jedno narzędzie do automatycznego sterowania procesem kompilacji, które oporne jest na ustawienia makepkg.conf - jest nim często stosowany w "świecie" Qt - cmake. Dotychczasowe sztuczki nie pomagają. W zasadzie, to stosowne wpisy winny być umieszczone w pliku CMakeLists.txt i można byłoby się pokusić o wykorzystanie np. sed w tym celu. Wydaje się jednak, że istnieje prostrza możliwość. Problem jedynie w tym, że nie mam 100% pewności, że ona działa prawidłowo. W przeciwieństwie do innych, cmake nie informuje nas, czy kompiluje program z wykorzystaniem flag właściwych dla naszego procesora. Sztuczka polega na delikatnej ingerencji w PKGBUILD. Dodać musimy pewien wpis, w zasadzie w dowolnym miejscu przed budową programu. Ja do tego używam sekcji prepare, zatem stosowny, dodatek może wyglądać tak:
prepare() { export CFLAGS=-march=native export CXXFLAGS=-march=native }
I w zasadzie tyle. W powyższym przykładzie użyłem możliwości gcc "odgadnięcia" na jakim procesorze przychodzi mu kompilować program, czyli flagi native. Wówczas nawet nie jest konieczne ustawienie flagi mtune, albowiem sam kompilator przyporządkuje taką samą jak dla march. Oczywiście zamiast native można użyć konkrentej flagi dla naszego procesora oraz również wprowadzić zmienną mtune dla niego właściwą.

czwartek, 1 czerwca 2017

Brak możliwości aktualizacji lub instalacji pakietów - zablokowana baza

Arch oferuje doprawdy świetne narzędzie do obsługi pakietów. Niemniej jednak zbliża się już koniec drugiej dekady XXI w. i przyzwyczajenia użytkowników, czy też ich oczekiwania w zakresie jakiegoś prostego, graficznego menedżera paczek są duże i poniekąd można je uznać za uzasadnione. Tymczasem pacman czuje się jak ryba w wodzie wyłącznie w konsoli. Natura nie znosi próżni, stąd też już od dawna powstają takie graficzne menedżery. Ostanio - głównie za sprawą ich domyślnego instalowania w dystrybucjach pochodnych - popularność zyskały pamac oraz octopi. Oba te programy oferują, działające nieustannie w tle, małe narzędzia monitorujące możliwość aktualizacji pakietów. W ich konfiguracji można sobie zmienić częstotliwość aktualizacji. Jeśli nic nie zmienimy w systemie, to owe narzędzia zainstalują się wraz ze wspomnianymi menedżerami i ustawione będą (o ile pamiętam) na sprawdzanie aktualizacji raz dziennie. Zwykle oznacza to, że rozpoczynają swe działanie zaraz po pierwszym uruchomieniu komputera w danym dniu. Jeśli aktualizacje są dostępne, to programy te pokażą stosowną informację w tacce systemowej. Zanim to nastąpi są ciche i nieme. W żaden sposób nie sygnalizują swego działania w tle. Użytkownik zatem nie ma żadnej wiedzy, czy w danym momencie narzędzie wykonuje swoją pracę, czy nie. Zdarzyć się może, że chcemy zainstalować jakąś paczkę właśnie wówczas, gdy omawiane narzędzie będzie sobie spokojnie wykonywało pracę w tle. Wówczas pojawi się informacja, że nie jest to możliwe i pojawi się informacja:
błąd: nie udało się zainicjować transakcji (nie udało się zablokować bazy danych) błąd: nie udało się zablokować bazy danych: Plik istnieje jeśli jesteś pewien, że menedżer pakietów nie jest już uruchomiony, możesz usunąć /var/lib/pacman/db.lck
Oczywiście rozwiązanie mamy podane wprost. Niemniej jednak kilka słów wytłumaczenia dlaczego tak się dzieje. Otóż owe działające w tle narzędzia dokonują synchronizacji bazy pacmana (pomijam tu kwestię bezpieczeństwa, albowiem muszą one w tym celu uzyskać uprawnienia administratora, a skoro nie podajemy im hasła, to oznacza, że cały czas działając w tle posiadają takie uprawnienia, co delikatnie mówiąc obniża bezpieczeństwo naszego systemu). Każde działanie pacmana dotyczące jego bazy (a takim jest jej synchronizacja) dokonuje jej zamknięcia, by uniemożliwić w tym samym czasie działanie innej instancji pacmana, która również do tej bazy chce mieć dostęp. Efektem jest, że pojawi się w systemie (zasadniczo) tymczasowy plik /var/lib/pacman/db.lck. Jak napisałem - uniemożliwi on synchronizację baz pacmana, aktualizację systemu, instalację paczek, czy ich odinstalowanie. W takiej sytuacji, jeśli mamy zainstalowane narzędzie informujące o dostępnych aktualizacjach (domyślne np. w Antergosie czy Manjaro), możemy chwilę odczekać i zobaczyć co się dzieje, a próbę instalacji czy odinstalowania pakietów bądź aktualizacji systemu po niej ponowić. Możemy również przerwać ów proces działający w tle bądź to w ogóle z niego wychodząc, bądź to po prostu kasując plik db.lck (oczywiście uprawnienia administratora są niezbędne). To ostatnie będzie też właściwym i jedynym rozwiązaniem, jeśli z jakiegoś powodu baza pozostanie zablokowana pomimo, że żadne narzędzie w tle nie działa. Dzieje się tak najczęściej wówczas, gdy proces synchronizacji bazy został przerwany (choćby nieświadomie przez wyjście z systemu podczas działania takiego narzędzia informującego o aktualizacji). Cóż, osobiście raczej nie korzystam z owych notyfikatorów, bowiem zdecydowanie lepszym jest dla mnie konsolowe narzędzie checkupdates, które robi to znacznie szybciej. Niestety też, zarówno octopi, jak i pamac wprowadzają je do naszych systemów, czy tego chcemy, czy nie. W przypadku octopi niebawem podam dwa rozwiązania jak się pozbyć tych notyfikatorów, a mimo tego nadal się cieszyć możliwościami graficznego menedżera pakietów.