wtorek, 18 kwietnia 2017

Pozbywamy się niechcianych plików lokalizacyjnych z pomocą pacmana

W Archu wiele programów zawiera wszystkie swoje pliki lokalizacyjne. W ten sposób, instalując jakiś program otrzymujemy nie tylko te pliki, które chcemy, ale także takie, z których na pewno nie skorzystamy. Wprawdzie nie jest są to pliki duże, jednakże skoro nie muszą w naszym systemie istnieć, to po co mają w nim być? Wielu prawdopodobnie spotkało się z takimi narzędziami jak localepurge, czy bleachbit i próbowało zapewne z ich pomocą usuwać te pliki. Po takiej czynności pacman będzie jednakże sygnalizował niespójność pakietów (brak ich części). Od czasu pojawienia się wersji 4.2 pacmana istnieje jednakże znacznie lepsze rozwiązanie. Otóż w pliku /etc/pacman.conf możemy skorzystać z tzw. odwróconych wyrażeń regularnych, które umieścimy w polu NoExtract. W ten sposób pacman zostanie poinstruowany o tym, że z paczki nie ma rozpakować określonych plików i umieścić ich w systemie. Zainstalowane tak paczki nie będą powodowały żadnych informacji o błędach ze strony pacmana. Konieczne jest jednakże bądź to przeinstalowanie wszystkich paczek w systemie, bądź to po prostu poczekanie na kolejne aktualizacje. Pamiętajmy jednak o tym, że wiele paczek nie zawiera polskich plików lokalizacyjnych. Roztropność nakazuje, by pozostawić w systemie te pliki z angielskimi paczkami językowymi (bo te najczęściej mają wszystkie). Stosowna linia w NoExtract może wyglądać tak:
NoExtract = usr/share/locale/* !usr/share/locale/pl/* !usr/share/locale/en_US/* !usr/share/locale/locale.alias usr/share/man/* !usr/share/man/man*
Dziękuję za wskazanie (lata temu) tego sposobu Bartkowi Piotrowskiemu.

środa, 12 kwietnia 2017

Niesforne kolory aplikacji Qt4 w Plasma 5

Zanim doczekamy się, że padnie ostatni bastion oprogramowania opartego o Qt4/kdelibs upłynie pewnie jeszcze sporo wody w Wiśle. Niestety. Niestety też okazuje się, że systemsettings5, który obecny jest w Plasma 5 od samego początku (niegdyś był jeszcze systemsettings4, ale obecnie już go nie ma), nie zawsze sobie radzi z nałożeniem schematu kolorystycznego wybranego przez użytkownika na aplikacje wykorzystujące stary rodzaj bibliotek. Dzieje się tak przede wszystkim, gdy albo sami taki schemat stworzymy, albo wybierzemy go w Ustawieniach Systemowych -> Kolory, czy też wgramy ze store.kde.org. Ba, stosowny błąd, a w zasadzie nawet dwa, został nawet jakiś czas temu zgłoszony. Nie liczyłbym jednak na jego szybkie załatwienie i poniekąd słusznie. Wolę, jeśli praca programistów Plasmy nie jest trawiona na tego typu rzeczy, które w dodatku, prawdopodobnie będą przejściowo jedynie sensowne. Przyglądnijmy się zagadnieniu, które irytujące jest w zasadzie wyłącznie dla osób korzystających z różnego rodzaju DE/WM w linuksie. Otóż, gdy wybierzemy sobie jakiś motyw, który dostarczany jest wraz z Plasmą - nie ma problemu. W zasadzie zostanie on nałożony poprawnie. Tak jest i z Breeze i z Breeze Dark. Gorzej, gdy ich kolorystyka nam nie pasuje. Wówczas bądź to sami zmieniamy, bądż to przeszukujemy w tym celu AUR, bądź udajemy się do sklepu KDE. Wgranie schematu najczęściej dokona zmian w kolorystyce Plasma 5, ale już niekoniecznie dla aplikacji Qt4/kdelibs. O ile jeszcze schematy kolorystyczne wgrywane z AUR choćby niekiedy się nałożą na nie, to już pozostałe w zasadzie nigdy nie. Przyczyna jest prozaiczna. Jeśli tworzymy nowy schemat kolorystyczny dla aplikacji Plasmy, bądź też wgrywamy go ze sklepu KDE, to zostanie on ulokowany w katalogu ~/.local/share/color-schemes/. Aplikacje Qt4/kdelibs będą go poszukiwały jednak w katalogu ~/.kde4/share/apps/color-schemes/. Dodatkowo, często schematy, które pobierane są ze sklepu KDE w systemsettings widziane są pod nazwą, zaś w istocie ich nazwa zaczyna się od jakiejś liczby. I wówczas już wbudowane narzędzia ne potrafią sobie poradzić. Wyjście jednakże jest proste. Niezależnie od tego, czy stworzyliśmy sobie schemat we własnym zakresie, czy też wgraliśmy go ze sklepu KDE, przekopiujmy z katalogu ~/.local/share/color-schemes/ do katalogu ~/.kde4/share/apps/color-schemes/ i to najlepiej jeszcze przed jego wybraniem. Od tej pory kolory wybrane w systemsettings5 winny być prawidłowo nałożone również na aplikacje Qt4/kdelibs.

środa, 5 kwietnia 2017

Łatwa "instalacja" obrazu ISO bezpośrednio w GRUB2

GRUB2 daje możliwość uruchamiania obrazów systemu (ISO) bezpośredniego z dysku. Niestety albo trzeba dokładnie poznać strukturę owego ISO i stworzyć odpowiedni wpis, który GRUB2 rozpoznałby, albo posługiwać się listą gotowych wpisów. W oparciu tę właściwość można sobie przygotować nawet odpowiedni nośnik zawierający kilka systemów. Można sobie też ułatwić życie. W Debianie od lat istnieje narzędzie grub-imageboot, którego źródła są prawdopodobnie w githubie prowadzonym przez formorera ułatwiające to zadanie. Po instalacji, dodaniu ISO do odpowiedniej lokalizacji, musimy jedynie zaktualizować GRUB2 i... wszystko powinno działać. Niestety nie z każdym ISO mi się to udało. Kiedyś istniały skrypty umożliwiające budowę tej paczki w AUR. Nieznane są mi powody ich usunięcia, niemniej jednak znajdują się one nadal w archiwum AUR. Jeśli chcielibyśmy z nich skorzystać należy sklonować archiwum:
git clone https://github.com/aur-archive/grub-imageboot
Przejść do katalogu i stworzyć paczkę:
cd grub-imageboot && makepkg -sirc
Domyślną lokalizacją obrazów ISO, jest /boot/images. Określa ją plik /etc/default/grub-imageboot. Jeśli zdecydujemy się skorzystać z tej lokalizacji, musimy ją stworzyć i skopiować tam interesujący nas obraz systemu a następnie wykonać:
# grub-mkconfig -o /boot/grub/grub.cfg
Od tej chwili, po ponownym uruchomieniu komputera, pośród wpisów w GRUB winien się znaleźć również umożliwiający nam uruchomienie dodanego obrazu systemu.

wtorek, 4 kwietnia 2017

Hardcore - Kompilacja programu pod własny procesor, cz. 3 - qmake errata

Niegdyś popełniłem tekst, który poruszał już tę kwestię. Można jednak nieco prościej. Zakładając, że stworzyliśmy sobie również makepkg.conf, który przekaże kompilatorowi flagi naszego procesora, możemy uprościć PKGBUILD i po prostu w sekcji build, po odpowiednich komendach przekazywanych niekiedy qmake dodać QMAKE_CFLAGS_RELEASE="${CFLAGS}"QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}". Przekaże to qmake zmienne, jakich użyliśmy w makepkg.conf.
Stosowny fragment PKGBUILD może zatem wyglądać tak:
build() {
    cd "$srcdir/$pkgname-$pkgver"

    qmake QMAKE_CFLAGS_RELEASE="${CFLAGS}" \
          QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
    make

}
Oczywiście ścieżka jest przykładowa. Przykładowy jest też zapis qmake, aczkolwiek najczęściej stosowany.

Hardcore - Kompilacja programu pod własny procesor, cz.2 - makepkg.conf

Zasadniczym plikiem, który w Archu (bądź szerzej w dystrybucjach pacmanowych) przekazuje informacje sterujące procesem kompilowania jest makepkg.conf wykorzystywany przez program makepkg. Dla niezaznajomionych, to on jest wykorzystywany przez różne AUR-helpery dla budowania programów z AUR. Z niego korzystamy również kompilując lokalnie program.
Pośród opcji tego pliku znajdziemy również dwie, które powodują, że kompilator języka C/C++ stara się zoptymalizować kod programu pod procesor, jaki tam został zadeklarowany. Są to zmienne: CFLAGS, CXXFLAGS oraz CPPFLAGS.
Standardowo (tj. bezpośrednio po zainstalowaniu pacmana) wyglądają one tak (dla procesorów 64bitowych):
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
Interesujące będą dla nas dwie: march i mtune. W powyższym przykładzie (czyli standardowo), zbudowany z użyciem skryptu makepkg program będzie dostosowany do każdego procesora 64bitowego. Możemy to prosto zmienić, edytując plik /etc/makepkg.conf. Możemy się zdecydować na to, by sam kompilator "odgadł" jakie flagi kompilacyjne winien zastosować. Wówczas w miejscu x86-64 oraz generic wpisujemy native.
Możemy jednak nie wierzyć automatowi i spróbować dokładniej określić jakie flagi winny tu zostać użyte, tak by na pewno odpowiadały naszemu procesorowi. Wpierw musimy jednak poznać te flagi. Wydajemy w tym celu polecenie:
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
Teraz pozostaje nam odnalezienie odpowiednich pozycji po słowach march i mtune oraz ich wpisanie jako zmiennych w pliku /etc/makepkg.conf.
W moim przypadku (mam procesor AMD serii Piledriver) może to wyglądać tak:
CFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong"
lub
CFLAGS="-march=bdver2 -mtune=bdver2 -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=bdver2 -mtune=bdver2 -O2 -pipe -fstack-protector-strong"
Niestety te zmienne nie działają dla programów używających cmake bądź qmake (zob. poradnik, choć niebawem jego uproszczenie) przy kompilacji.
Musimy również pamiętać, że tak zbudowany program może w ogóle nie zadziałać na innym procesorze (np. po jego wymianie). Nie będzie też "przenośny" w tym sensie, że zbudowany z takimi flagami program może nie pracować na innym komputerze, działającym na innym procesorze.