pavbaranov Arch

Kiedyś, jeszcze w czasach KDE 3.x, odtwarzacz multimedialny Kaffeine był dość popularnym składnikiem wielu dystrybucji, które były konfigurowane z tym środowiskiem. W czasach KDE4 jego rola została przyćmiona. Więcej dystrybucji serwowało to środowisko bądź to z domyślnym Dragon Player, bądź też z SMPlayer lub VLC. Samo Kaffeine, choć zostało sportowane do Qt4/KDE4 raczej też nie rozbawiało wprowadzaniem co rusz to nowych wersji, czy wydań. Projekt wydawał się żyć na uboczu. Pewnie nie pomaga mu również i to, że musi on być "drugim" odtwarzaczem w systemie. Jest on bowiem zależny od jednej z bibliotek rozprowadzanych wraz z VLC. Z niejakim zdziwieniem zatem zobaczyłem dzisiaj, że wypuszczona została nowa wersja oznaczona numerem 2.0.0, która została w całości przeportowana do Qt5/KF5. Otrzymała ona również wsparcie dla DVB-T2. Naprawiono też wiele dostrzeżonych błędów. W repozytoriach Archa (community) znajduje się paczka 1.3.1. Jeśli ktoś chciałby sobie jednak stworzyć wła...

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

Nie było publicznego wydania #124. Dzisiaj pojawiło się natomiast wydanie #125. Od czasu ostatniego, czyli #123 nie nastąpiło wiele zmian. Program zbudujemy ściągając archiwum skryptów niezbędnych do jego utworzenia. Następnie należy je rozpakować, przejść do utworzonego katalogu i tam wykonać makepkg. W konsoli wygląda to tak (zakładam, że polecenie tar wydawane jest w katalogu z pobranym archiwum): tar -zxvf otter-browser-weekly.tar.gz && cd otter-browser-weekly.tar.gz && makepkg -sirc

Wczoraj w repozytoriach pojawiła się wersja 5.22.0-2 frameworka służącego zarządzaniem portfelem w Plasma 5. Wersja ta zawiera patch na jeden z błędów wykrytych w tej paczce. Problem w tym, że po aktualizacji, portfel (kwallet) nie rozpoznaje hasła. Możliwości uporania się z tym błędem jest kilka: cofnąć paczkę do wersji 5.22.0-1 (jeśli mamy downgrade, to downgrade kwallet ), ponoć, bowiem tego nie wypróbowałem - skasowanie portfela i utworzenie go na nowo, przebudowanie paczki lokalnie. Ja zrobiłem to ostatnie i z tego co wiem, u kilku osób to działa. Zatem możecie spróbować. $ yaourt -G kwallet && cd kwallet && updpkgsums && makepkg -sirc Nie wiem dlaczego sumy kontrolne są inne niż w PKGBUILDzie arojasa, stąd wymagana jest aktualizacja. Po zbudowaniu paczki konieczne jest przelogowanie Plasmy. EDIT: Wczoraj wieczorem udostępniona została paczka kwallet-5.22.0-3, która naprawia błąd.

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

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