Posty

Wyświetlanie postów z wrzesień, 2016

Octopi z GIT w Archu - errata

Od czterech dni nie zbudujemy już octopi z GIT w Archu (ani w żadnym innym systemie) niezależnie czy będziemy używać PKGBUILDu dostępnego w AUR, czy też u mnie. "Winę" za taki stan rzeczy ponosi zmiana dokonana w kodzie programu, który obecnie jako swoją zależność wymaga również alpm_octopi_utils , czyli Alpm dla Octopi. Autor oczywiście stosowny kod zrobił, a nadto dostarcza również PKGBUILD dla niego. Wystarczy w zasadzie pobrać powyższej zlinkowany PKGBUILD, umieścić go w jakimś katalogu, a następnie zbudować i zainstalować paczkę przed budową Octopi. Lekko zmienione PKGBUILDy dla Octopi udostępnię prawdopodobnie dzisiaj, choć po zbudowaniu wyżej wymienionej paczki i jej zainstalowaniu w systemie, wszystkie programy Octopi budują się prawidłowo. EDYCJA: Skrypty PKGBUILDów zostały zaktualizowane. Dostępne są z poprzedniego wpisu .

Uruchamiamy program konsolowy w Plasma 5

Obecnie większość aplikacji dostarcza plik *.desktop, który potrafi zinterpretować każde środowisko graficzne, dodać go do menu i uruchomić. Programy konsolowe uruchamiamy najczęściej poprzez uruchomienie emulatora terminala (np. Konsole) i wpisanie tam odpowiedniej komendy. Niektóre programy konsolowe również dostarczają pliki *.desktop. Nic nie stoi na przeszkodzie stworzeniu takiego pliku samodzielnie. I wszystko byłoby cudownie, jednakże często próba uruchomienia takiego programu nie powoduje żadnej reakcji. Ot, jedynie - jeśli ktoś ma to tak ustawione - pooglądamy, że program próbuje się uruchomić, albowiem ukazuje się nam na pasku zadań ikonka, bądź poobraca się nam wskaźnik myszy i... tyle. Problem daje się łatwo rozwiązać i jest znanym błędem w środowisku Plasmy. Otóż za uruchamianie aplikacji w pliku *.desktop odpowiada polecenie Exec . Dla programów graficznych ma ono (podstawową) strukturę następującą: Exec=/usr/bin/aplikacja W przypadku programów konsolowych, będzie to:

Przyspieszamy czas tworzenia paczek

Nie, żadne magiczne ustawienia kompilatora. Nie o to chodzi. Program, który "steruje" kompilowaniem paczek zarządzanych przez pacmana, to makepkg. Jest on wykorzystywany nie tylko przy lokalnym tworzeniu paczek z jego pomocą, ale również chyba przez wszystkie tzw. helpery AUR. Program jest sterowany plikiem /etc/makepkg.conf . Wewnątrz katalogu, w którym następuje budowa paczki, tworzone są dwa podkatalogi: src  oraz pkg . W pierwszym następuje budowa (kompilacja) programu. Jeśli to zostanie wykonane bez błędów, skompilowany program wraz ze wszystkimi elementami niezbędnymi do jego działania umieszczany jest w katalogu pkg , którego wewnętrzna struktura odpowiada systemowi katalogów Archa (czy innej dystrybucji). Przynajmniej powinna odpowiadać. Następnie cała zawartość katalogu jest pakowana do pliku tar , który - jeśli domyślnych ustawień makepkg.conf  nie zmienimy jest następnie kompresowany (np. do formatu xz . W ten sposób otrzymujemy znane nam paczki pacmana nazwa.pkg.

Otter-Browser wydanie tygodniowe #142

Znów bez rozwodzenia się: PKGBUILD

KDE-BaseApps na KF5 (rozwiązanie tymczasowe)

KDE-BaseApps to zestaw kilku aplikacji, na które składają się  Konqueror, KFind, KPasswd, KeditBookmarks i KDialog oraz biblioteka libkonq. Portowanie ich do KF5 jest już na tyle zaawansowane, że w następnym wydaniu KDE Applications (16.12) pojawią się one już w takiej wersji. Obecnie w Archu (Manjaro) można je zbudować z AUR, a stosowne paczki nazywają się konqueror-git, kfind-git, kpasswd-git, keditbookmarks-git,kdialog-git i libkonq-git, przy czym zawsze budują się wszystkie aplikacje składające się na paczkę "bazową" kde-baseapps-git. Niestety, gdyby ktoś chciał obecnie ją zbudować, to się to nie uda. Makepkg nie wspiera częściowego budowania paczek z grupy składającej się na pkgbase. Tymczasem wciąż jeszcze istnieje paczka konq-plugins-git , która składa się na kde-baseapps-git, natomiast wraz z commitem 68782ee  dotychczas rozdzielone konq-plugins zostało włączone do kodu konquerora. Zmianie uległy jednocześnie zależności, albowiem aplikacje te stały się wolne od kodu

Jak nie używać IgnorePkg

Pacman - przynajmniej wg mnie - jest bardzo dobrym menedżerem pakietów. Jest też - za pomocą pliku /etc/pacman.conf - dość konfigurowalny. Jedną z opcji, jaką możemy tam ustawić, jest ignorowanie aktualizacji paczki. Za funkcję tą odpowiada pole IgnorePkg. Tu możemy wpisywać nazwy paczek, których nie chcemy aktualizować. Teraz muszę coś przypomnieć. Arch Linux jest tak pomyślany, że domyślnym i jedynie wspieranym sposobem aktualizacji, jest aktualizacja globalna. Aktualizujemy zatem cały system, a nie poszczególną paczkę. Także do wyjątków winna należeć systuacja, w której aktualizacja systemu nie obejmuje jakiejś paczki. O prawidłowość działania tego mechanizmu dbają opiekunowie systemu. Czasem jest lepiej - czasem gorzej, ale zaangażowania w prawidłowość działania systemu jako całości, nie możemy odmówić. Powrócę zatem do ignorowania aktualizacji poszczególnej paczki. Jak wspomniałem należy to traktować jako wyjątek. Systemu z niezaktualizowaną paczką opiekunowie Archa nie przewid

Mój pierwszy AppImage - Google Earth

Program, który tym razem udostępniam, proszę traktować jako swego rodzaju test. Postanowiłem bowiem zrobić swój pierwszy AppImage. Z pewnych przyczyn wybór padł na Googe Earth. Wszelkie licencje (jeśli nie zostały umieszczone w środku - jeszcze się do AppImage nie przyzwyczaiłem) są na stronie programu. Jeśli chcielibyście pomóc - to prosiłbym o ściągnięcie paczki, zapisanie jej w dowolnym miejscu. Po nadaniu plikowi AppImage atrybutu wykonalności, program uruchomimy w konsoli w taki sposób: cd katalog_z_zapisanym_AppImage ./GoogleEarth-7.1.7.2600-x86_64.AppImage Oczywiście, można sobie skrócić męki przepisywania tej nazwy, wystarczy użyć <Tab> po rozpoczęciu pisania. Teraz jeszcze GoogleEarth . Prosiłbym o informację, czy program uruchamia się, czy też nie, a jeśli nie to dane sprzętu, a przede wszystkim środowisk, w których przyszło program uruchomić. Uwaga - jak na moje dotychczasowe "paczki" - ta jest całkiem spora, ok. 67MB. EDIT: Już widzę pierwszą rzecz

Octopi a sprawa Arch Linux

Octopi  jest dość popularnym i chyba najlepiej dopracowanym graficznym menedżerem paczek dla systemów zarządzanych przez pacmana. Obecnie octopi, to już nie tylko sam menedżer pakietów, ale również cały zestaw aplikacji, które pozwalają na śledzenie zmian w repozytoriach i informowanie użytkownika o pojawiających się nowych wersjach paczek zainstalowanych w systemie, zarządzanie listą repozytoriów (dokładnie ich listą w pacman.conf), czyszczenie cache pacmana itp. Pomimo tego, że pacman jest doskonałym narzędziem, to jednak w XXI w. chęć zarządzania swoim oprogramowaniem w wygodnej, graficznej formie, nie jest żadną fanaberią. W przeciwieństwie do dystrybucji pochodnych, oraz np. KaOSa, czy Chakry, w repozytoriach Archa nie znajdziemy octopi (podobnie zresztą jak innych nakładek na pacmana). Skoro przyroda nie znosi próżni, to nic dziwnego, że stosowny skrypt (a nawet skrypty) budujące octopi znajdziemy w AUR. Co do zasady są takie dwa: octopi oraz octopi-git . Drugi z nich nie dosta

Wsparcie dla Plasma 5 w Linux Mint do 2021 r. - czylli dlaczego Mint nie jest najlepszą dystrybucją z Plasmą

Kiedyś powiedziałem sobie, że ten blog winien stronić od felietonów, polemik itp. Zmieniam jednak zdanie. W zasłużonym dla IT portalu dobreprogramy.pl pojawił się niedawno tekst:  Linux Mint 18 KDE to najbardziej dopracowana dystrybucja z Plasmą . Może. Nie wnikam. Kilka minut pracy na tym systemie nie upoważnia mnie do jakiegokolwiek twierdzenia o "wyższości" tej dystrybucji nad innymi, choć... No właśnie. Przyglądnijmy się co pod maską, co jest deklarowane i zastanówmy, czy Linux Mint 18 w ogóle można nazwać dystrybucją z Plasmą, a już na pewno, czy najbardziej dopracowaną. Mint 18 KDE to Linux Mint 18 ze środowiskiem Plasma 5. Niby nic nadzwyczajnego. Każdy może zrobić sobie dystrybucję z Plasmą. W tym przypadku otrzymujemy "core" z Linux Mint 18, czyli de facto paczki systemu bazowego z Ubuntu 16.04, może nieco ulepszone, nieco oprogramowania własnego oraz... całe  środowisko Plasma 5 (w tym frameworks, samo plasma oraz kde applications) z PPA  Kubuntu Backpo

Plasma 5.7.95 (aka 5.8 Beta)

Właśnie ukazała się wersja testowa (beta) nadchodzącego wydania Plasma 5.8. Paczki zostały udostępnione również w repozytorium kde-unstable  w Archu. Wszystkich zapraszam do testowania. Tylko w ten sposób jesteśmy w stanie pomóc, by Plasma była coraz lepsza. Ze swej strony mogę napisać, że nie dostrzegłem żadnej niestabilności tego środowiska testowego. Oprócz deklarowanych nowości, usunięcia błędów, mogę stwierdzić, że działa ono zauważalnie szybciej. Osobom, które chciałyby pomóc w testowaniu tego wydania Plasma w Archu, chciałbym przypomnieć, że środowisko to jest budowane na repozytorium testing  zatem i ono winno zostać udostępnione oraz system winien być zakutalizowany do wersji paczek tam umieszczonych. W przypadku KDE plusem będą najnowsze paczki KDE Frameworks w wersji 5.26. Nowa Plasma niesie ze sobą (oprócz usunięcia błędów) nieco zmian wizualnych oraz - ponoć, bowiem mi się tego nie udało uruchomić - "prawdziwe" wsparcie dla Waylanda. Więcej o wydaniu dowiecie

Otter-Browser #141

Bez wielu nowości, bez zbędnego komentarza: PKGBUILD .

"KDE 5" coś się w końcu wyjaśnia

Dotychczas, w świecie KDE - przynajmniej w jego piątym wydaniu - żyliśmy wg ustalonego cyklu. Nowe wydanie KDE Frameworks pojawiało się co miesiąc, nowe "główne" wydanie Plasma 5 miało się pojawiać 4 razy do roku (ostatnio jednak rzadziej), zaś KDE Applications 3 razy w roku. Pierwsze "zamieszanie" wprowadziło wydanie Qt, które w wersji 5.6 uzyskało status tzw. LTS i to wydanie będzie wspierane przez 3 lata. Pomimo jednak tego, że Qt 5.6 jest LTSem, to "obok" wydawane są kolejne wersje. Obecnie mamy już 5.7, a w listopadzie spodziewane jest 5.8. Ba, przed końcem wsparcia 5.6 spodziewane jest wydanie już 6.0, które jednakże nie ma być takim skokiem "jakościowym" i "technologicznym" jak wydania Qt4, czy Qt5 i być niejako kontynuacją Qt5. Kolejna wersja LTS tego frameworka spodziewana jest w 2018 r. To jest Qt, które stanowi podstawę budowania oprogramowania KDE. Nie tak dawno pojawiła się informacja, że nadchodzące wydanie Plasma 5.8 bę

Naprawiamy brak możiwości uruchomienia programów GUI z uprawnieniami roota

Wraz z wprowadzeniem nowej wersji dbus (na pewno dotyczy wersji 1.10.10) przestały się uruchamiać programy z graficznym interfejsem użytkownika z uprawnieniami root. Problem dotyczy np. Plasmy oraz MATE i Cinnamona (nie wiem, czy innych środowisk również, ale nie wydaje mi się, by był im obcy). W przypadku uruchamiania bezpośrednio ze środowiska zobaczymy wyłącznie, że program chce się uruchomić (np. "skaczący" kursor), ale ostatecznie nie uruchamia się, a uruchamiając (przez sudo) w konsoli otrzymamy informację: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)" Oczywiście można twierdzić, że programy GUI w ogóle nie powinny być uruchamiane na uprawnieniach administratora, niemniej jednak nie jest to rozwiązanie. Niekiedy tego typu programy po prostu są wygodniejsze. Do czasu, gdy problem nie zostanie rozwią

Instalujemy paczki z nieoficjalnych repozytoriów

No właśnie: instalujemy? Ten wpis nie będzie w ogóle o tym, jak tego dokonać (jest to opisane w wiki Archa dość dokładnie), ale o tym, czy w ogóle warto to robić, kiedy i jakie niesie konsekwencje. Lektura różnych forów czy blogów związanych z Archem, Manjaro i innymi dystrybucjami korzystającymi z rodowodu Archa pozwala na stwierdzenie, że niektóre osoby, w określonych sytuacjach, mają chęć dodawania do pacman.conf wpisów do tzw. nieoficjalnych repozytoriów. Tych ostatnich cała masa. Kusi i nęci zatem zamiast budowania czegoś ze źródeł korzystając z PKGBUILDu szybka instalacja programu z repozytorium. Fakt, jest to dobre rozwiązanie, szczególnie dla programów, które się kompilują wieczność. Fakt, ale wyłącznie wówczas, gdy mamy zaufanie do twórcy i opiekuna takiego repozytorium. Czy jest to jednak dobre rozwiązanie? Powiedzmy tak: i tak i nie. Dla świadomego użytkownika - jak najbardziej. Zwykle bowiem wie jakie i dlaczego repozytorium dodał, co chciał w ten sposób osiągnąć i przed

Otter-Browser #140

Wydanie tygodniowe #139 nie ukazało się. Od dzisiaj mamy jednak wydanie #140. Wszystkie moje wcześniejsze uwagi , w szczególności dotyczące qtwebkitu preferowanego przez Twórców są nadal aktualne. Przypominam - tej wersji qtwebkit nie ma nawet w AUR. Jeśli ktoś chciałby z niej korzystać, to musi ją zbudować ze źródeł. Teraz już wyłącznie formalność - nowy PKGBUILD z wersją 0.9.11.dev140.

KShutDown 4.0 oparty o KF5

Nie tak dawno ukazała się 4 odsłona programu rozszerzającego możliwości opuszczenia systemu integrującego się ze środowiskami spod znaku Qt - KShutDown . Od dłuższego czasu istnieje możliwość budowy tego programu zarówno z wykorzystaniem starych bibliotek KDE4, jak i w oparciu o KF5 lub "czystego" Qt4 oraz Qt5 (o tym jeszcze niżej). Z jakichś, niewytłumaczalnych dla mnie powodów, pomimo tego, że w Archu KDE4 zostało już dość dawno temu porzucone, program w repozytorium w dalszym ciągu znajduje się w wersji budowanej w oparciu o KDE4 (dokładnie o kdebase-runtime, które oczywiście w dalszym ciągu w repozytoriach jest). Już wcześniej przedstawiłem PKGBUILDy dla rozwojowej wersji 3.99.x. Obecnie zatem dla stabilnego już wydania 4.0. Prezentowany PKGBUILD buduje paczkę wykorzystując KF5, a zatem sens budowy programu w takiej wersji istnieje dla osób, które używają Plasma 5. Osoby, które korzystają np. z LXQt, Lumina, Hawaii czy Papyros winny raczej zbudować wersję opartą o &quo