pavbaranov Arch

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

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

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

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}" i  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.

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