pavbaranov Arch

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śc

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

UWAGA: Wraz z instalacją harfbuzz 1.4.x prezentowane tu rozwiązanie nie jest już prawidłowe i spowoduje błędy w systemie! Szczerze powiedziawszy, to nie widziałem jeszcze tyle osób narzekających na to, czego używa, jak w świecie linuksa. Tym razem poradnik dla osób narzekających na niewłaściwy wygląd czcionek. Jeśli te, które są dostępne zaraz po instalacji Wam nie pasują z jakiejś przyczyny, to radzę spróbować zainstalować czcionki z patchami tzw. infinality. Można to zrobić "przez mękę", bawiąc się w budowanie tych paczek z AUR, a następnie mozolnie konfigurując, można prościej, dopisując odpowiednie repozytorium do ich listy dla pacmana, a następnie instalując odpowiednie paczki. Ograniczę się do tej ostatniej opcji. Też bywam leniwy. Więcej o Infinality dowiecie się z oficjalnej strony . Instalację rozpoczynamy od edycji pliku /etc/pacman.conf i dopisaniu odpowiedniego repozytorium: [infinality-bundle] Server = http://bohoomil.com/repo/$arch W następnej kole

Kompilując program w Arch Linux makepkg wykorzystuje ustawienia w pliku /etc/makepkg.conf. Tam można m.in. wymusić kompilację uwzględniającą określony rodzaj procesora. Innymi słowy, program skompilowany na danej maszynie winien - przynajmniej w teorii - być do niej bardziej dostosowany. Ma to swoje oczywiste konsekwencje. Program tak zbudowany może nie działać na innym komputerze, który ma inny - choćby nieco - procesor. Także po wymianie procesora możemy zostać niemiło zaskoczeni. Niektóre programy nie lubią też takiej, "wymuszonej" kompilacji. Ustawienia w /etc/makepkg.conf są jednakże ignorowane, gdy program jest prekompilowany z użyciem qmake, bądź cmake. Nie oznacza to, że nie można w tych przypadkach skompilować go z użyciem odpowiednich flag. W pierwszej części napiszę jak to zrobić dla qmake. Po pierwsze musimy mieć skrypty umożliwiające budowę paczki dla Archa. Możemy je stworzyć we własnym zakresie, możemy - jeśli program ma zostać przerobiony z dostępnych w rep

Przynajmniej w teorii. Szczególnie dla posiadaczy tradycyjnych dysków talerzowych. Na czym polega trick? Otóż aby program się uruchomił musi być wpierw wczytany do pamięci. Zanim to system uczyni musi wpierw go odczytać z dysku. Te są szybsze lub wolniejsze, jednakże nie ma jeszcze tak szybkich dysków, które dorównywałyby operacjom wykonywanym w pamięci RAM. Stąd też, gdyby program na dysku był mniejszego rozmiaru, to powinien on zostać szybciej uruchomiony. Nawet jeśli potem - już w RAM - komputer musiałby dokonać jego dekompresji. Spróbujmy zatem poddać kompresji program wykonywalny tak, jak to czynimy w przypadku różnego rodzaju dokumentów. Narzędzia kompresujące programy wykonywalne znane są na niemal każdy system operacyjny. Od dawna jest też znane takie narzędzie dla linuksa. Mi znane jest jedno, choć nie wykluczam, że jest takich więcej. Tym programem kompresującym jest Ultimate Packer for eXecutables  - w skrócie upx. Z podanej wyżej strony dowiecie się więcej, w tym również o

Osoby użytkujące Arch Linux w stabilnej wersji nigdy nie powinny się spotkać z omawianym tu "błędem". Niemniej jednak tylko wówczas, gdy ograniczą się do stosowania programów znajdujących się w oficjalnych repozytoriach. Tu bowiem osoby odpowiedzialne za utrzymywanie paczek, z chwilą, gdy dochodzi do zmian jakichś bibliotek dbają o przebudowanie paczek i dostosowanie ich do nowych wersji. Niemniej jednak wielu z używających Archa buduje paczki także z AUR. Najczęściej to właśnie programy pochodzące z AUR nagle zaprzestaną działać. Przypomnę, albowiem szczególnie dla osób, które zmieniły dystrybucję z *buntupochodnych na Archa, czy - częściej - Manjaro: w AUR nie znajdują się żadne paczki. Tu są wyłącznie "przepisy" na podstawie których następuje lokalne budowanie paczki i jej instalacja. Jeśli jednocześnie opiekun takiej aplikacji w AUR "nie zauważy", że dokonane zostały jakieś zmiany w repozytoriach, które wymagają jego reakcji lub nawet pomimo tego, my n

Istnieje możliwość, że spotkacie się z takim błędem: konta pocztowe (IMAP) w KMail 5.0 są prawidłowo skonfigurowane, poczta pobrana, ale lista maili pozostaje pusta. Prawdopodobnie za taki stan rzeczy odpowiedzialne jest wadliwe skonfigurowanie Akonadi. Zwykle, zaraz po instalacji używa ono SQLite3 jako silnika bazodanowego. Wszystko fajnie, mniejsze to od MariaDB, ale... no właśnie - nie zawsze z nową odsłoną KMail zadziała to prawidłowo. Informacje o rodzaju używanego silnika przez Akonadi zawarte są w pliku: ~/.config/akonadi/akonadiserverrc Najwygodniej jest plik ten edytować po prostu jakimkolwiek edytorem tekstowym (plain). Zanim jednak do tego przystąpimy należy Akonadi zatrzymać: $ akonadictl stop Następnie edytujemy wspomniany wyżej plik i w miejscu: Driver = QSQLITE3 w sekcji: [%General] wpisujemy: Driver = QMYSQL Pozostaje jeszcze - dla pewności - skasować dotychczasową bazę Akonadi: $ rm -r ~/.local/share/akonadi (oczywiście jak chcecie możecie zrobić sobie je

W przypadku nieoczekiwanego wyłączenia się programu, automatycznie uruchamiany jest proces coredump, który powoduje zrzut różnych informacji, które programistom mogą pomóc w rozwiązaniu problemu. Niemniej jednak, dla zwykłego użytkownika jest to proces zbyteczny, zajmuje miejsce, a nadto w owych zrzutach mogą być różne informacje, do których niekoniecznie chcielibyśmy, by ktokolwiek miał dostęp (co prawda są one niby czytelne wyłącznie dla roota, jednakże nie jest to w zasadzie żadne zabezpieczenie przed osobą, która potrafi się do partycji głównej "dobrać", nawet nieznając hasła root). Z punktu widzenia zwykłego użytkownika usługa ta może być po prostu zbędna. Wyłączenie można przeprowadzić w zasadzie na dwu poziomach. W przestrzeni użytkownika (userspace) oraz pozostałej. Wyłączenie pierwszej powoduje, że programy uruchamiane w userspace nie będą dokonywały zrzutów, jeśli niespodziewanie się wyłączą. Wyłączenie również drugiej powoduje, że coredump jest wyłączone dla wszy

Wszyscy znamy "zegarek" na panelu. Nie znam dystrybucji, która domyślnie go by tam nie umieszczała. Jest on jednak bardzo ograniczony w swoich możliwościach. Co może zrobić? Wyświetlić czas, pokazać kalendarz. Tyle. Innymi słowy spełnia swoją rolę. A gdyby tak... Oprócz wyświetlania bieżącego czasu, oprócz pokazywania kalendarza, mógł wyświetlić również terminarz naszych zajęć, jeśli te mamy w Google Calendar, mógł wyświetlić pogodę... Jeśli czegoś takiego potrzebujecie, to z pomocą przychodzi plazomid Event Calendar . Przyznam, że zacząłem go używać i wydaje się być dość ciekawym rozwiązaniem. Oczywiście o ile nasze zajęcia przechowujemy w Google Calendar i jeśli wystarcza nam prognoza pogody z OpenWeatherMap . Po kliknięciu na zegar, otwiera się okno, w którym pokazywany jest kalendarz na miesiąc (tu żadnej zmiany) z podkreślonym dniem (niestety - przynajmniej jak na razie w jednym kolorze) dniem, w którym mamy zaplanowane jakieś zajęcie. Obok niego wyświetla się dwutygod

W repozytorium AUR są dostępne skrypty budujące niegdyś dość popularny i dobrze oceniany wystrój dla KDE o nazwie Helium. Pomijając, że jest to stara wersja (6.0.0, podczas, gdy dostępna jest już 7.1.0), to PKGBUILD budujący paczkę jest wadliwy. Po pierwsze winien być pakowany jako "any", a nie dla rodzaju systemu (32/64-bitowy), to nadto umieszcza swoje pliki w wadliwym miejscu. Przynajmniej jeśli chodzi o Plasmę. Prawidłowy PKGBUILD wyglądać winnien tak: pkgname=plasma5-theme-helium _pkgname=Helium pkgver=7.1.1 pkgrel=1 pkgdesc="Transparent theme based on air and eleonora. but giving it an extra touch" arch=('any') license=('GPL') url="http://kde-look.org/content/show.php/Helium?content=125471" depends=('plasma-desktop')  conflicts=('plasma-theme-gremix' 'plasma-theme-helium') source=("http://kde-look.org/CONTENT/content-files/125471-Helium.tar.xz") md5sums=(' f0a03eaa13b09e19