Posty

Wyświetlanie postów z lipiec, 2016

Zbieramy użyteczne informacje w przypadku błędów w aplikacji

Ze względu na sposób paczkowania w Archu (a co za tym idzie wszystkich jego pochodnych, w tym Manjaro, jak również wszystkich systemów, które wykorzystują pacmana) użyteczne dla programistów informacje, w przypadku błędów aplikacji, zbiera się nieco inaczej. Podstawowe informacje może dostarczyć uruchomienie programu w konsoli i sprawdzenie komunikatów, które w ten sposób uzyskujemy. Niekiedy będą to informacje użyteczne, np. że program nie potrafi znaleźć jakiejś biblioteki, niekiedy jednak program nie uruchamia się, bądź też w sposób niekontrolowany wyłącza, a terminal dostarcza nam jedynie suchej informacji o zrzucie pamięci itp. Jeśli taki wynik przedstawimy komukolwiek, kto zechce nam pomóc, to najczęściej będzie to bezwartościowa informacja, która nie jest w stanie nawet wyjaśnić, czy błąd tkwi w samym programie, czy jest związany z paczkowaniem, czy kompilacją. Nie będzie też wiadomo czy i w jaki sposób taką aplikację można naprawić. Z pomocą przychodzi uruchomienie programu po

Sprawdzamy ile RAM zabiera nam jakaś aplikacja

Na wstępie, by nie było nieporozumień: poniżej prezentowane rozwiązanie jest wspólnym dziełem dwu użytkowników Archa: graysky 'ego oraz grimscythe , a zostało zaprezentowane w wątku na forum Archa. Jest na tyle proste i ciekawe, że postanowiłem je przybliżyć. Po wykonaniu poniżej przedstawionych operacji, wywołanie skryptu z nazwą programu jako parametru pokaże ile pamięci RAM jest zajmowanych przez ten program. Do dzieła. Otwieramy jakikolwiek edytor tekstu (czyli np. nano, kwrite, kate, gedit itp.) i umieszczamy tam następujące linie basha: #!/bin/bash ps -A --sort -rss -o comm,rss | grep $1 | awk '{ sum+=$2 } END { print sum/1024 }' Zamykamy i zapisujemy, nadając mu jakąkolwiek, łatwą do zapamiętania przez nas nazwę. Koledzy z BBS zaproponowali appusage.sh . Może być. Dla ułatwienia sobie korzystania ze skryptu nadajemy mu uprawnienia wykonywalne: chmod +x appusage.sh Teraz jeszcze warto byłoby umieścić ów skrypcik w katalogu widzianym przez system. Domyśln

Kernele z patchem CK

Pewnie większość użytkowników Archa dawno już spotkała się z tzw. kernelami Cona Kolivasa, czy też z patchami BFS lub CK. Część z nas ich używa. Teoretycznie kernel Manjaro winien zawierać te patche już od dość dawna, jednakże kiedy go ostatni raz sprawdzałem (wczoraj) nie był wyposażony w te łatki. Na bieżąco nowe wersje kernela udostępnia w postaci binarnej użytkownik graysky , a zatem nie musimy ich kompilować. Co ciekawe, w jego repozytorium dostępnych jest bardzo wiele odmian dostosowanych do poszczególnych rodzajów procesora, a nie tylko wersje dla architektury 32 i 64 bitowej. Kompilacja jest zatem konieczna wyłącznie osobom, które z jakichś przyczyn chciałyby dokonać większych zmian w swoich kernelach. Dla nich są skrypty w AUR , które radzę dokładnie przeglądnąć, albowiem można w nich poustawiać sporo opcji. Jeśli ktoś chciałby dokładniej to poznać - zapraszam do dyskusji, czy to tutaj, czy na forum . Oprócz kerneli z najnowszej linii, są jeszcze repozytoria, w których można

Otter-Browser #134

Kolejna wersja beta zbliża się dużymi krokami, jak na razie pojawiło się wydanie tygodniowe #134 i jesteśmy o tydzień bliźsi pierwszego wydania stablinego. Tymczasem PKGBUILD , a więcej - jak zwykle - dowiecie się ze strony programu i z githuba .

KDE Applications 16.08Beta

Właśnie ukazała się nowa odsłona aplikacji od KDE. Oczywiście dzięki arojasowi jest już dostępna dla Archa w repozytorium [kde-unstable] . Jeśli ktoś chciałby z niej skorzystać, to przypominam, że należy uruchomić to repozytorium oraz repozytorium [testing] albowiem programy trafiające do [kde-unstable] są budowane na podstawie aplikacji mieszących się właśnie w testing. W pliku /etc/pacman.conf należy zatem usunąć znak "#" przed [testing] oraz figurującym pod nim " Include = /etc/pacman.d/mirrorlist" oraz najlepiej na samej górze listy udostępnionych repozytoriów dodać: [kde-unstable] Include = /etc/pacman.d/mirrorlist Z informacji niezbyt miłych: - Blogilo nie potrafi jak na razie używać protokołu Bloggera - konieczna jest nowa biblioteka libkgapi, - nie działają kody QR w kaddressbook - wersja prison nie jest kompatybilna z Plasmą, Jak zwykle w przypadku udostępniania przez arojasa paczek w kde-unstable nie są dostępne pliki lokalizacyjne. Jeśli

AzPainterB

Kolega Salvadhor stwierdził , że w Archu i Manjaro mamy jedynie "zwykłego" AzPaintera. Siadło mi na ambit :) Oto PKGBUILD umożliwiający budowę nowego AzPainterB 1.0.2. O samym programie więcej oczywiście na blogu Salvadhora.

Skracamy czas instalacji

Wraz z nastaniem pacmana w wersji 5.x zarządanie bazą man zostało z nim zintegrowane. Powoduje to, że baza ta jest przebudowywana praktycznie w każdym przypadku na końcu instalacji paczek. W niektórych przypadkach trwa to długo. Z odsieczą przyszedł znany w świecie Archa graysky  tworząc mandb-ondemand, który skraca ten proces. Skrypty dostępne są w AUR , a kod źródłowy na githubie . Cały proces instalacji ogranicza się do zbudowania i zainstalowania paczki w systemie. Nie wymaga żadnej ingerencji. Zatem: pb -S mandb-ondemand PS: Jeśli chcielibyście wiedzieć co oznacza tajemnicze pb , to nie jest to kwestia przyzwyczajenia do moich inicjałów, a postanowienie wspierania polskiej myśl informatycznej. Od tej chwili PKGBUILDer , którego autorem jest Kwpolska zastąpi tu yaourt, czy packera. Program dostępny jest w AUR , także w wersji GIT  i kiedyś go pewnie omówię ( źródła ).

Paczki deb i rpm w Archu

Co jakiś czas pojawiają się pośród użytkowników Archa, czy Manjaro rozpaczliwe głosy związane z próbą zainstalowania paczek pochodzących z najpopularniejszych dystrybucji, a w zasadzie paczek oferowanych w formacie deb lub rpm. Najczęściej głosy te pochodzą od bardzo świeżych użytkowników naszej dystrybucji. Co gorsza dotyczą one często sterowników, albo aplikacji, które i tak są oferowane w AUR albo w jakchś repozytoriach. Ze względu na dostępność w repozytoriach Archa dpkg oraz rpm w ślad za takim "lamentem" idzie cudowna podpowiedź: zainstaluj sobie dpkg/rpm i za pomocą tego menedżera zainstaluj paczkę w systemie. Czy coś takiego ma szansę powodzenia? Oczywiście. Menedżer paczek jest wszak aplikacją wyspecjalizowaną w m.in. ich instalacji. I wszystko wydaje się wspaniałe. STOP. Niestety nic nie jest wspaniałe. Nie tak się to robi i tak instalacji aplikacji pakowanych dla obcych dystrybucji się nie robi. Kiedy o tym pisałem, spotykałem się z najpopularniejszym pytaniem

Ładniejsze czcionki w linuksie

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

Nomacs 3.4.0

Z jakichś niezbadanych dla mnie przyczyn, Nomacs w Archu dostępny jest jeszcze w wersji 3.0, podczas, gdy obecna to już 3.4. Jej budowa trwa chwilę, zatem proponuję wykonać: yaourt -G nomacs cd nomacs wget -c http://pastebin.com/raw/Jr4d8WVn mv Jr4d8WVn PKGBUILD makepkg -sirc

Poprawiamy zbyt duże ikony w systray w Plasma 5.7

Wraz z przebudowaniem od początku kodu odpowiedzialnego za wyświetlanie tzw. tacki systemowej w Plasma 5.7 niektórzy borykają się z problemem zbyt dużych ikon, które się w niej pojawiły po aktualizacji. Problem został dostrzeżony i naprawiony . Poprawka prawdopodobnie pojawi się w wersji 5.7.3, której można oczekiwać 3.08. Do tego czasu trzeba sobie jednak jakoś radzić. Są dwa rozwiązania. Pierwsze to przebudować plasma-workspace, używając PKGBUILDu wersji 5.7.2 z repozytorium dodając do niego łatkę . Nie przedstawiam PKGBUILDu, albowiem rozwiązanie drugie wydaje się szybsze. Niemniej jednak, gdyby ktoś chciał zaprowadzić bezwzględny porządek w systemie, a nie potrafił tego samodzielnie dokonać, to proszę zgłosić w komentarzach, a uzupełnię informację o stosowne skrypty do przebudowania paczki. Drugie rozwiązanie wydaje się być banalne. Otóż m.in. za wielkość ikon odpowiadają ustawienia w pliku  /usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml . N

Otter-Browser wydanie tygodniowe 133

Tym razem już bez zbędnej zwłoki - PKGBUILD .

Otter-Browser wydanie tygodniowe 132

Sorki za opóźnienie. Nieco spowodowane perturbacjami z qt5-webengine. Obecnie działa. Jak zwykle PKGBUILD .

Plasma 5.8 LTS - czyżby pierwsze jaskółki Plasma 6/KDE 6?

Następne wydanie środowiska KDE - Plasma 5.8 uzyskuje status LTS i będzie wspierane przez osiemnaście miesięcy od chwili wydania (planowane na 18.10.2016 r.). Wydanie to jako wymaga wersji Qt 5.6, która również uzyskała status LTS (3 letnie wsparcie). Co ciekawe, przynajmniej jak na razie, w zapowiedziach wydań , aż do końca kwietnia 2018 r. nie pojawiają się nowe wydania Plasmy. Czyżby Plasma 5.8 mogła być ostatnim wydaniem? Podobnie wszak stało się z kdeworkspace 4.11, który równolegle funkcjonował wraz z Plasma 5 przez szereg miesięcy (około półtora roku). Jak na razie plany Qt sięgają po wersję 5.8, która wstępnie była planowana na koniec 2016 r. Rewolucja raczej nie grozi, zwłaszcza, że Plasma 5.8 będzie utrzymywana aż do kwietnia 2018 r. Niemniej jednak zaczyna to wyglądać jak pierwsza przymiarka do powstania nowej wersji Plasmy, czy KDE (jakkolwiek się nie będzie nazywać). Oznaczenie Plasmy 5.8 mianem LTS oznacza, że w tej wersji nie pojawią się raczej jakiekolwiek nowe funkcj

AppImage, Snappy, Flatpak - Cz. 4 - Refleksja końcowa

Udało mi się zapoznać z 3 rodzajami "bundli". W zasadzie czterema, albowiem z jeszcze jednym w czasach, gdy używałem Chakry. Tam wówczas, bo już obecnie tak nie jest, aplikacje Gtk były umieszczane również w swoich "kontenerach" - rozwiązanie zbliżone do omawianych. Pozostałe, wprawdzie istniejące, jakoś nie ściągnęły mej uwagi po próbie przeszukania dostępnych aplikacji. Na placu boju pozostały zatem: appimage, flatpak i snappy. Każde rozwiązanie ma pewnie swoje zalety i wady - pora na bardzo subiektywną refleksję. Spośród tych trzech, na pewno nie będę używał snappy. Nie dość, że skomplikowane, używające bez sensu systemd (tzn. wiem do czego go używa, ale nie znajduję wytłumaczenia na to po co go używa), to przede wszystkim kompletnie nieużyteczne. Być może w jakimś systemie, być może osobie bardziej zdeterminowanej ode mnie w próbie uruchomienia tu czegokolwiek, uda się coś uruchomić. Mi się nie udało. Biorąc pod uwagę moją wiedzę jako użytkownika systemów linu

AppImage, Snappy, Flatpak - Cz.3 Snappy

Od końca. Poległem. Instalacja snapów rozpoczyna się od instalacji, a następnie skonfigurowania paczki snapd. Widzicie do "d" w nazwie? Tak, jest to program i usługa systemd. Bez systemd nie zadziała na żadnym systemie. Wbrew temu, co twierdzi PR Canonicala. To znaczy oni o tym nie wspominają. Twierdzą natomiast, że ich pomysł jest powszechny i zadziałać ma docelowo na każdym systemie. Nie jest to prawdą. Instalacja jest prosta. Pacman jak zwykle rozwiąże każdy problem. Potem trzeba podnieść usługę. Całe szczęście to socket, a zatem nie będzie bez sensu zaśmiecał pamięci. Potem już sama przyjemność: można jednym poleceniem - w tym przypadku snap - przeglądać, instalować, odinstalować, oraz robić wiele rzeczy z paczkami snap. Można je instalować zarówno ze "sklepu" jak i z plików lokalnych. Ba, jedna z usług zapewnia również automatyczne aktualizowanie paczek. Super. To zaczynamy. Przegląd paczek. Nie jest ich jak na razie wiele, a ich wybór jest poniekąd dziwny. M

Niesforne qtwebengine 5.7.0

W kilku wpisach sygnalizowałem wadliwą pracę wszelkich przeglądarek wykorzystujących qtwebengine. Okazało się, że problem spowodowany jest przez niekonsekwentne wyłączenie pewnej optymalizacji w qt5-webengine. Obecnie do repozytorium trafiła przebudowana paczka w wersji 5.7.0-2. Wraz z nią zniknęły problemy aplikacji wykorzystujących tę odmianę blinka. Qupzilla 2.x, czy Otter-Browser (z tym silnikiem) pracują już prawidłowo.

Plasma 5.7 i Qt 5.7 w Archu i co z tego wynika

Po dwu tygodniach testowania Plasma 5.7 Beta (5.6.95) (można się było z nią zapoznać z kde-unstable ), dwa dni temu pojawiło się jej stabilne wydanie, które trafiło do repozytorium testing . Pewnie gdzie indziej przeczytacie sporo o nowościach środowiska, ale... osobiście uważam, że wystarczająca jest wizyta na stronie kde oraz przeglądnięcie erraty. Podzielę się zatem z Wami wrażeniami z korzystania z Plasmy w tej wersji. Od razu mówię - moja wersja jej wyglądu nie jest dostarczana ze środowiskiem. Dotychczasowe doświadczenia z Plasmą 5 wskazują na dość znaczne jej "przywiązanie" do tematu Breeze, którego używanie w istocie sprawia, że działa ona lepiej niż z różnymi tematami, motywami, a nawet zestawami ikon, które dostępne są w zarówno w repozytoriach różnych dystrybucji, w AUR, jak i na kde-look.org. Nie mówię już o próbach użycia tematów z KDE4, które wcześniej czy później skończy się pokazową wywrotką środowiska (w najgorszym przypadku), a na co dzień powoduje błędy, kt

Otter-Browser #131

Więcej przeczytacie jak zwykle na stronie projektu . Zmian nieco jest, włącznie z "dopuszczeniem" jako jeszcze jednego silnika, alternatywnie rozwinanego projektu qtwebkit . Swoją drogą - mocno kibicuję, albowiem pochodna Blinka, jaką jest qtwebengine mocno mnie nie zadowala. Doprawdy nie rozumiem zachwytów Blinkiem. Jeden z gorszych silników, jakie istnieją na rynku. Przynajmniej jeśli chodzi o żarcie (bo inaczej się wyrazić nie mogę) zasobów. Budowa Otter-Browser z mojego PKGBUILDu ponownie umożliwia zbudowanie przeglądarki w opaciu zarówno o qt5-webengine, jak i qt5-webkit. Ponownie, albowiem pomimo upływu dwu tygodni od publikacji Otter-Browser, zespół Qt nie zrobił nic, by silnik qtwebengine prawidłowo działał i nie zanosi się na to. Dyskusja w którą w końcu się włączył jakiś deweloper Qt wykazuje iście "korporacyjne" podejście. Niestety - nic z tego nie będzie i będziemy musieli poczekać do czasów qtwebengine 5.8. Wówczas być może qtwebengine zacznie działa

AppImage, Snappy, Flatpak... - Cz.2 Flatpak

Druga przygoda z "bundlami", czyli flatpak. Pierwsza różnica w porównaniu do AppImage - by korzystać z tego typu paczek konieczna jest instalacja ich menedżera oraz wykonanie kilku czynności, które umożliwią - przynajmniej w teorii - pracę z programami spaczkowanymi w tym standardzie. W Archu menedżera flatpaków znajdziemy w repozytorium extra  lub możemy zainstalować wersję rozwojową kompilowaną z AUR (flatpak-git). To nie wszystko. Po instalacji musimy dodać odpowiednie klucze publiczne oraz biblioteki uruchomieniowe (runtime). Dopiero potem możemy przystąpić do instalacji programów, które instalujemy bądź repozytoriów (czyli dokładnie jak w przypadku każdej dystrybucji), bądź też z lokalnie pobranego pliku (tak np. zainstalujemy LibreOffice). Po dodaniu repozytoriów możemy je przeglądać, możemy instalować, aktualizować, czy odinstalować aplikacje. Sam flatpak po prostu oferuje wszystko to, co każdy inny menedżer pakietów znany z linuksa. Wprawdzie składni należy się nauczy

AppImage, Snappy, Flatpak... i wiele innych. Cz. 1 - AppImage

Już jakiś miesiąc po publikacji Ubuntu 16.04 blogerzy linuksowi całego świata zauważyli "nowy system paczkowania" jakim Ubuntu nazywa swoje snappy, czy snaps (raz tak, raz inaczej o nim pisze, zatem sam nie wiem jak się nazywa). Pewnie gdyby informacja nie pochodziła od Canonicala, pewnie wszyscy przeszliby koło niej jak koło AppImage, Autopackage, 0install, czy xdg-apps (obecnie Flatpak). Co ciekawe... przeszli, skoro najstarszy z wymienionych wyżej (a przecież nie wszystkich) systemów uniwersalnego paczkowania dla linuksa obecny jest na rynku od... 2002 roku. Biorąc ten fakt pod uwagę, w zasadzie kończą się dyskusje na temat, że o to w tej chwili, dzięki oprogramowaniu Canonicala, które dostępne jest na różne systemy, firmy produkujące komercyjne i zamknięte oprogramowanie, rzucą się w ramiona linuksa i zaczną na ten system produkować swoje ulubione Photoshopy itp. Pies z kulawą nogą tego nie chce. Skoro przez całe lata nikt się tym nie zainteresował, to nowy "standar