sobota, 31 grudnia 2016

Ikony w programach uruchamianych na prawach administratora w Plasma 5

Jeśli nic w Plasma 5 nie zmienialiśmy, to uruchamianie programów, które wymagają uprawnień administratora (np. PartitionManager) ukazuje nam okno programu pozbawione ikon. Jeśli chcemy uzyskać w takim programie wygląd okien z ikonami, to można zrobić to na kilka sposobów. Opiszę dwa, gdyż jeden z nich albo wymaga uruchomienia programu GUI na prawach roota, co wydaje się być zbędnym niebezpieczeństwem, albo dość żmudnego ręcznego ustawiania zachowania się tych programów otwieranych w sesji root. Mamy jednakże dwie proste alternatywy.
Pierwsza, to uruchomienie programu z konsoli z wykorzystaniem zmiennych środowiska (na przykładzie PartitionManager):
sudo -E partitionmanager
Oczywiście w miejscu partitionmanager może być dowolny program, który chcemy uruchomić na prawach administratora.
Druga, to dokonanie prostego zabiegu w edycji menu Plasmy. Otwieramy program KDE Menu Editor. Chyba najprościej wybrać z menu, które pojawi się po kliknięciu prawym przyciskiem myszki na "Aktywatorze programów" (czyli na popularnym "K" w panelu). Po otworzeniu się menu wybieramy "Edytuj programy". Znajdujemy wówczas program, który nas interesuje, przechodzimy od zakładki "Zaawansowane" i odznaczamy pozycję "Uruchom jako inny użytkownik". Po zapisaniu tych ustawień możemy się cieszyć wyglądem okien takich programów z widocznymi w nich ikonami.

piątek, 30 grudnia 2016

Otter-Browser wydanie tygodniowe 156

Z lekkim opóźnieniem - PKGBUILD nowego wydania tygodniowego. Jednocześnie - wobec wprowadzenia przez twórców publikacji wydań tygodniowych aplikacji w formacie AppImage, zastanawiam się nad celem dalszego przedstawiania PKGBUILDów wydań tygodniowych. Prosiłbym o opinie. Problemu z publikacjami nie ma żadnego, zwłaszcza, że dla siebie i tak będę kompilował te wydania (wg mnie sprawują się lepiej od AppImage).

QFaktury-Qt5 - ERRATA 2

Wobec wprowadzonych zmian w kodzie, jeszcze jedna poprawka PKGBUILDu.

czwartek, 22 grudnia 2016

QFaktury-Qt5: ERRATA

Poprawiony PKGBUILD dla programu. Obecnie plik QFaktury.desktop ma prawidłowe lokalizacje programu i prawidłową ścieżkę dla jego ikony.

Integracja LibreOffice w Plasma 5

Prawdopodobnie mając zainstalowane "czyste" środowisko oparte o KF5/Qt5 i używając LO zauważyliście, że aplikacja ta nie integruje się z nim. Wygląd jest niespójny, a okna dialogowe w żaden sposób nie chcą przypomnieć tych znanych ze środowiska.
Sam pakiet biurowy nie jest zbudowany z wykorzystaniem bibliotek KDE (zarówno "starych", jak i obecnego KF5). Nawet o Qt nie ma tu mowy. Niemniej jednak, pakiet zawiera możliwość upodobnienia się do stylu używanego środowiska. Możliwości są cztery i są to w kolejności: gtk3, gtk, kde4 oraz generic. Można je wymusić, można też zdać się na wszyty w program automat, który rozpoznając, że dane środowisko, w którym ma pracować LO jest zbudowane z wykorzystaniem gtk3, to uruchamia się z takim "pluginem", jeśli na gtk2 - uruchamia się z "pluginem" gtk, jeśli stwierdzi, że jest to KDE, to uruchamia się z "pluginem" kde4, a ostatecznie jako "generic".
Teoretycznie zatem, gdy mam obecne KDE, to program winien je rozpoznać i uruchomić się z "pluginem" kde4. Uruchomiona w ten sposób aplikacja otrzymuje przede wszystkim dwie warstwy integracji z KDE. Po pierwsze z wyglądu przypominać winna natywną aplikację KDE (Qt), po drugie uzyskuje natywne dla KDE okna dialogowe.
W przypadku KDE program uruchomi się z "pluginem" kde4 jednakże wyłącznie wówczas, gdy znajdzie w systemie bibliotekę kdelibs pochodzącą jeszcze z KDE4 oraz... gdy znajdzie jakiś wystrój dla KDE4. O opcjonalnej zależności LO służącej jego integracji z KDE informuje program podczas instalacji, wymieniając pośród nich także kdelibs. Nie informuje jednak o tym, że w systemie winien się znajdować jakiś wystrój dla aplikacji KDE4, jak np. znajdujący się w repozytoriach breeze-kde4.
Idąc od końca, konsekwencje tego są takie:

  • jeśli w systemie nie będziemy mieć zainstalowanego gtk3 lub gtk2 oraz nie będziemy mieć zainstalowanej biblioteki kdelibs oraz wystroju Plasmy dla aplikacji KDE4, wówczas LO uruchomi się jako "generic" z natywnymi dla LO oknami dialogowymi i wystrojem nieco przypominającym aplikacje zbudowane w JAVA,
  • jeśli w systemie znajdą się biblioteki gtk3 lub gtk2, ale nie znajdzie kdelibs i wystrój dla KDE4, to wówczas aplikacja uruchomi się z wystrojem gtk3 lub gtk2 (obecnie bardzo zbliżonym) i z oknami dialogowymi natywnymi dla tych aplikacji,
  • jeśli w systemie odnaleziona zostanie biblioteka kdelibs, ale nie odnaleziony zostanie wystrój dla KDE4, to wówczas aplikacja uruchomi się z oknami natywnymi dla Plasmy, ale z wystrojem będącym swoistą hybrydą aplikacji Gtk i czegoś, co sam nie potrafię określić,
  • jeśli w systemie znaleziona zostanie biblioteka kdelibs oraz jakiś wystrój dla KDE4, wówczas aplikacja upodobni się do natywnej dla KDE.

Sytuacja, w której mielibyśmy wystrój dla KDE4 i jednocześnie nie mielibyśmy kdelibs, w zasadzie nie powinna zaistnieć i będzie ona wynikiem jakiejś błędnej instalacji takiego wystroju z nieoficjalnego źródła.
Chcąc zatem mieć maksymlanie upodobniające się LO do Plasmy musimy zainstalować kdelibs oraz jakiś wystrój kde4; osobiście polecam breeze-kde4, bowiem tu w istocie dobrze to wygląda (w szczególności w nadchodzącym wydaniu 5.3, gdzie w końcu pozbyto się gradientu w obszarze pasków narzędziowych).
Jak długo taki stan będzie istniał? Myślę, że jeszcze sporo lat, albowiem KDE4 w takich dystrybucjach jak Debian będzie trzymane (nie wiadomo po co) do początku lat 2020. Dla tej wersji nie ma też oficjalnych paczek KF5.
Cóż można powiedzieć jedynie... niestety.

Otter-Browser wersja tygodniowa 155

Zeszłotygodniowe wydanie 154 zostało pominięte, a zatem kolejnym, po 153 stało się 155, którego PKGBUILD właśnie prezentuję.
Nawiasem mówiąc, w repozytorium metakcahura_Arch_Extra dostępne są binarki Otter-Browser robione bezpośrednio z git, które - chyba - mniej więcej odpowiadają wydaniom tygodniowym.

poniedziałek, 19 grudnia 2016

SystemdGenie

Nie wiem jak wielu z Was do zarządzania usługami systemd używa GUI, jednakże - w świecie KDE - od dość dawna dostępna była wtyczka dla KCM pod nazwą systemd-kcm, która doczekała się już wersji 1.2.1. Od dłuższego czasu jest ona również dostępna w repozytorium community.
Ragnar Thomsen, który jest autorem systemd-kcm, postanowił usamodzielnić ten program i zaoferował nam systemdgenie, który nie tak dawno zawitał do repozytorium unstable w KDE w wersji 0.99. Jednocześnie pojawił się również w community (choć wg mnie winien raczej trafić do kde-unstable).
Prawdopodobnie oznacza to już koniec systemd-kcm, którego miejsce zajmie właśnie oddzielny program i to on będzie rozwijany. Pomimo różnicy wersji, systemdgenie obecnie oferuje tę samą funkcjonalność, co systemd-kcm. Warto zatem rozważyć dokonanie zmian i odinstalowanie systemd-kcm, a zainstalowanie systemdgenie.

Więcej informacji znajdziecie na blogu Autora.

LibreOffice 5.3 i 5.4

Tych wersji oficjalnie jeszcze nie ma. Jednakże, ze względu na to, że przynoszą one "wstążkę", która jest absolutnie wymagana przez niektórych użytkowników i jej brak wręcz uniemożliwia pracę w LO, postanowiłem udostępnić PKGBUILDy dla tych rozwojowych wersji. O samej "wstążce" i jej aktywacji przeczytać możecie na dobreprogramy.pl.
Tutaj jedynie klka uwag.
Po pierwsze - z różnych względów, dzisiejsze PKGBUILDy są na pastebinie. Przynajmniej na razie. Trzeba je ściągnąć do jakiegoś katalogu, a następnie stworzyć paczkę. Obie proponowane wersje mogą koegzystować z instalacją libreoffice-fresh bądź libreoffice-still z repozytorium, gdyż umieszczane są w katalogu /opt. Obie nie są również budowane ze źródeł, albowiem proces ic kompilacji nawet na sprawnych komputerach trwa dość długo - PKGBUILDy wykorzystują zatem binarne paczki rpm i przebudowują je do formatu pacmana.
Różnice pomiędzy obu wersjami - oczywiście obok tego, że wersja 5.3 pojawi się już na przełomie stycznia i lutego 2017, a 5.4 około pół roku później i zawierać będzie jakieś dalsze usprawnienia i funkcjonalności w stosunku do 5.3, są takie, że wersja 5.3 jest spolszczona, natomiast 5.4 jest w angielskiej wersji językowej. PKGBUILD dla wersji 5.3 będzie aktualny praktycznie zawsze (dopóki na serwerach istnieć będzie wersja beta2), natomiast w przypadku wersji 5.4, gdy pojawi się nowa wersja (migawka), nie będzie jej już można zbudować z tego PKGBUILDu. Oba programy budują się wyłącznie w wersji 64 bitowej.

To już wyłącznie opis budowania.
Wersja LO 5.3beta2 - należy przekopiować poniższe polecenie:
mkdir build && cd build && wget -c http://pastebin.com/raw/GxucM2Zu && mv GxucM2Zu PKGBUILD && makepkg -sirc
Wersja LO 5.4current (alpha0) - należy przekopiować poniższe polecenie:
mkdir build && cd build && wget -c http://pastebin.com/raw/tVLNUQZ7 && mv tVLNUQZ7 PKGBUILD && makepkg -sirc
W przypadku, gdy wersja 5.4 przestanie się budować (bo aktualna wersja na serwerze będzie już inna niż ta z PKGBUILDu) musimy dokonać edycji PKGBUILD w następujący sposób:
- odwiedzamy stronę z aktualnymi paczkami LO5.4
- pliki paczek mają tu następującą strukturę: master~DATAPUBLIKACJI_GODZINAPUBLIKACJI_LibreOfficeDev_5.4.0.0.WERSJA_Linux_x86-64_deb.tar.gz
- zmianie ulegają te wartości, które zostały przeze mnie podkreślone wielkimi literami,
- przede wszystkim należy się zorientować, czy WERSJA to nadal alpha0, jeśli (i pojawi się tu wersja alpha1, w co wątpię, bowiem ona zwykle trafia w inne miejsce serwera LO), to można zmienić pole pkgver w PKGBUILDzie,
- kopiujemy adres odnośnika programu w wersji rpm (bez żadnych helppack i langpack) i podmieniamy nim wartość pola source w PKGBUILD,
- przed przystąpieniem do budowy paczki, aktualizujemy sumy kontrolne: updpkgsums

Oprócz wspomnianej "wstążki" LO w wersji 5.3 lepiej się integruje z KDE, albowiem nie występuje już gradient okna programu, który raz, że denerwujący, dwa - w skrajnych przypadkach - powodował nieczytelność funkcji w paskach narzędziowych po prawej stronie okna.

AKTUALIZACJA:
Obecnie paczki 5.3.0.0beta2 zostały wycofane z repozytorium pre-release. Nie ma zatem już możliwości budowy tej paczki z podanego przeze mnie PKGBUILDu na pastebin. Niemniej jednak, udało mi się znaleźć w innej lokalizacji tę wersję paczek rpm, zatem osobom zainteresowanym mogę obecnie zaoferować PKGBUILDy następujących wersji:

  • 5.3.0.0.beta2 - wersja spolszczona,
  • 5.3. "daily" - wersja angielska,
  • 5.4. "daily" (master) - wersja angielska
  • eksperymentalna wersja 5.3. "daily" ze spolszczeniem z beta2; tu proszę wziąć pod uwagę, że wersja ta zawiera binarki spolszczające, które są starsze od wersji dostępnej w 5.3. "daily" - wersja zatem nie odpowiada w 100% wersji 5.3. "daily", ale też jest w niektórych aspektach nowsza od wersji 5.3.0.0.beta2.

Aktualizacja słowników systemowych (j.polski)

Wiele programów korzysta ze słowników umożliwiając w ten sposób korektę pisowni. Najpopularniejsze są chyba aspell oraz hunspell (myspell). W przypadku języka polskiego, korzystają one z plików udostępnianych przez aspell-pl oraz hunspell-pl. Paczki te dostarczają słowników udostępnianych przez internetowe wydanie słownika języka polskiego. Zespół stojący za publikacją tych słowników, zmienia je bardzo często. Tymczasem w repozytoriach Archa zwykle znajdują się dość odległe w czasie ich wydania. Trudno zresztą wymagać od opiekunów paczek, by były one aktualizowane co dwa dni, zwłaszcza, że nie zależy od nich funkcjonalność i bezpieczeństwo pracy systemu.
Jeśli ktoś chciałby zatem być bardziej na bieżąco ze słownikami, które używane są przez te programy, to proponuję niewielką zmianę paczek apsell-pl i hunspell-pl.
Po pierwsze musimy uzyskać PKGBUILD tych paczek. Osobiście używam w tym celu pkgbuildera lub yaourta, bo mi najprościej. Jak kiedyś wspomniałem, wspieramy polską myśl informatyczną, zatem posługiwał się będę pkgbuilderem.
1. Uzyskujemy PKGBUILD aspell-pl:
pb -F aspell-pl
2. Przechodzimy do katalogu, w którym znajdziemy rozpakowaną już paczkę:
cd community/aspell-pl
Tu drobna uwaga. Pkgbuilder ściąga skrypty do lokalizacji nazwa_repozytorium/nazwa_paczki. W przypadku yaourt ściągniętą paczkę znajdziemy po prostu w lokalizacji nazwa_paczki.
3. Edytujemy PKGBUILD
Przede wszystkim musimy zdobyć informację o najnowszej, dostępnej wersji słownika. Odwiedzamy zatem stronę SJP.PL i znajdujemy tam wersję słownika odpowiednią dla naszego aspella. W przypadku Archa będzie to plik o nazwie sjp-aspell6-pl-6.0_DATA-0.tar.bz2. Owa "DATA", to data publikacji słownika a jednocześnie numer wersji paczki w Archu.
Dowolnym edytorem edytujemy zatem plik PKGBUILD (możemy wykorzystać nawet sed) i zmieniamy w nim wartość DATA w polu:
pkgver=
na tę, którą poznaliśmy z powyższej strony.
4. Tworzymy paczkę i instalujemy w systemie:
updpkgsums && makepkg -sirc

W przypadku hunspell-pl postępujemy analogicznie, z tym, że ściągamy paczkę hunspell-pl, a odpowieni dla nas wówczas słownik ze strony sjp.pl to sjp-myspell-pl-DATA.zip.

Możemy również zmienić słownik synonimów i wyrazów bliskoznacznych, którym posługuje się LibreOffice na dostarczany przez dobryslownik.pl. Tu sprawa jest jeszcze prostrza. Ściągamy odpowiedni słownik ze powyższej strony, a następnie przechodzimy do Menedżera rozszerzeń w LO (ctrl+alt+E), wciskamy przycisk "Dodaj" i dodajemy plik pl-dict-latest.oxt z lokalizacji, gdzie go zapisaliśmy.

Jeśli powyższe czynności dokonamy dzisiaj, to słowniki aspell i hunspell zostaną zaktualizowane z wersji pochodzącej z 9.08.2016 r. do wersji z 19.12.2016 r., w przypadku słownika dla LO aktualizacja przeniesie nas w czasie o kilka lat, albowiem obecna wersja słownika z podanej wyżej strony pochodzi z 8.11.2016 r.

Różne pulpity wirtualne w Plasma 5

Ponoć brak możliwości indywidualizowania wystroju wirtualnych pulpitów w Plasma 5 jest jednym z większych błędów, jakie dotknęły to środowisko. Wprawdzie nie bardzo wiem, jak błędem może być nigdy nie istniejący brak określonej funkcjonalności, to jednakże rozumiem, że przyzwyczajenie z KDE4 (gdzie możliwość personalizacji pulpitów istniała, przynajmniej w późniejszych wersjach) może powodować frustracje użytkowników.
Natura próżni nie znosi. Skoro jest zapotrzebowanie, to jest i na nie odpowiedź. Niejaki Jonathan Marten napisał program, który udostępnia taką funkcjonalność w Plasma 5 i nazwał go wallpaperswitch.
Program jest jeszcze we wczesnym stadium rozwoju (to dopiero druga rewizja), zatem może jeszcze zawierać jakieś błędy. Program nie występuje jeszcze w repozytoriach Archa ani w AUR. Osobom, którym doskwiera opisywany brak funkcjonalności, polecam zatem skorzystanie z PKGBUILDu, który przygotowałem.
Po instalacji, należy program uruchomić czy to z menu, czy sensowniej chyba ustawiając go jako program uruchamiany wraz ze startem środowiska (oczywiście po uprzednim przetestowaniu). Program umieszcza się w tacce systemowej i stamtąd może być ustawiany. Więcej znajdziecie w pliku README.
W przypadku dostrzeżenia błędów, Autor prosi o ich sygnalizację bezpośrednio na githubie. Ewentualne błędy w paczkowaniu proszę sygnalizować tu, bądź na naszym forum.

wtorek, 13 grudnia 2016

QFaktury - reaktywacja

Swego czasu, kiedy jeszcze wiele firm nie stosowało "chmurowych" rozwiązań fakturujących, popularnością w Polsce, w świecie linuksa, cieszył się program qfaktury. Doczekał się ostatecznie swojej wersji 0.6.2, miał niegdyś nawet swoją stronę domową, a następnie słuch o nim niemalże zaginął. Rozwój programu próbował kontynuować Rafał Rusin, publikując do niego nieco poprawek i tworząc ostatecznie jego wersję 0.6.5. Zestaw łatek stworzył również opiekun tego pakietu w Gentoo.
Tak, czy inaczej - program od lat praktycznie się nie rozwijał, co skutkowało m.in. zmniejszającą się popularnością oraz praktycznym wyrugowaniem go ze wszelkich repozytoriów.
Na przywrócenie go do życia dała się namówić żona sir_lucjana. To dzięki jej pracy, możemy się cieszyć nową odsłoną programu, która została przeportowana do Qt5. Jednocześnie został nieco oczyszczony kod, dodanych kilka funkcjonalności. Kod źrodłowy programu dostępny jest na Githubie od wczoraj. Dla programu stworzyłem PKGBUILD, który umożliwia łatwą instalację programu w Arch Linux i pochodnych.
Zachęcam do testowania i dzielenia się uwagami. Proszę jednak być wyrozumiałym. Celem eksperymentu było przede wszystkim przeforkowanie qfaktur do Qt5, a nie usunięcie błędów, które się w programie znajdowały, czy dodanie mu oczekiwanych funkcjonalności. W zależności od popularności programu pewnie i na to przyjdzie czas.
Zanim jednak się zdecydujecie na pomoc w testach, jedna, ważna uwaga.
Jeśli ktoś z Was ma zainstalowany program np. z AUR (obecnie już nie istnieje), lub użył PKGBUILDów opublikowanych niegdyś przeze mnie i używa tego programu jako programu fakturującego w swojej firmie, zalecam przed instalacją nowej wersji (zresztą zawsze to w tym przypadku czynię) zrobienie sobie kopii zapasowych dokumentów i ustawień programu. Niestety musicie ich szukać. Najprawdopodobniej znajdziecie je w katalogach ~/.config/elinux oraz ~/.local/share/data/ (lub ~/.local/share) i tu w katalogu nazwą www.e-linux.pl lub e-linux.pl. Niestety w zależności od daty i wersji programu swoje dane umieszczał w różnych miejscach. Generalnie przeszukać należy podane lokalizacje, a także główny katalog użytkownika, za katalogami i plikami, których nazwy będą zawierać elinux, e-linux, qfaktury. Niekiedy mogą one być pisane z wielkiej litery. Te istotne dokumenty, czyli historia faktur, kontrahentów itp. winny być w katalogu ~/.local/share/data/elinux (lub podobnej). Plik konfigurujący znajdujący się w ~/.config ma mniejsze znaczenie i - w zasadzie - można spróbować go przed aktualizacją usunąć.
Stworzony obecnie program powinien bez problemu zobaczyć całą historię dotychczasowej wersji programu. Może się okazać jednak, że oczekuje ich w innych wersjach. Stąd też jeśli po instalacji program nie odnajdzie tej historii, musimy się upewnić co do zawartości katalogów, w których poszukuje tych informacji i przenieść dotychczasowe dokumenty ręcznie.
Obecnie program ma dwa pliki konfiguracyjne, który znajdują się w katalogu ~/.config/elinux. Jest to plik konfigurujący sam program o nazwie qfaktury.conf oraz plik z ustawieniami użytkownika o nazwie user.conf. Pierwszy - jeśli nie zostanie znaleziony - utworzony zostanie przy starcie systemu, o stworzenie drugiego poprosi sam program.
Pliki z danymi programu zawarte są w katalogu ~/.local/share/data/elinux/ i do tego katalogu musimy przekopiować nasze faktury i inne ustawienia, by zachować zgodność z dotychczasową wersją. Pliki te, to:

  • customers.xml - zawierający listę kontrahentów,
  • invoice.html - to ostatnia podglądnięta faktura (można sobie ten plik pominąć),
  • products.xml - lista towarów i usług,
  • katalog invoices zawierający wszystkie pliki wystawionych faktur.
W razie wątpliwości - proszę pytać tu lub na forum.

Quick-USB-Formatter na Qt5

Kiedyś powstał dość popularny programik powstały w kręgu osób odpowiedzialnych za dystrybucję Chakra. Służył wyłącznie jednemu celowi - "formatowaniu" popularnych pendrive'ów. Nazywał się quick-usb-formatter i oprócz Chakry zagościł wkrótce w repozytoriach innych dystrybucji. Wydawało się, że program ten przestał być rozwijany. Od jakiegoś czasu trwają jednakże prace nad przeportowaniem go do Qt5. Dla takiej wersji - oczywiście rozwojowej (GIT) - prezentuję PKGBUILD umożliwiający łatwą instalację w Arch Linux i pochodnych.
Pamiętajmy, że program w żadnym przypadku nie "sformatuje" pendrive, który został "potraktowany" przez dd (lub programy, które z niego korzystają lub robią dokładnie to samo co dd) by "wypalić" na nim obraz ISO. Tu wpierw musimy zastosować się do instrukcji m.in. opisanej już na blogu.

Otter-Browser wersja tygodniowa 153

W zasadzie jedynie porządkowo. Nowa wersja tygodniowa #153, która niesie sporo zmian, a przede wszystkim zapowiada kolejną betę. Program zbliża się już chyba do finalnego wydania, lecz kiedy to nastąpi - nie wiem.
PS. Wersja #152 oczywiście była, ale przeoczyłem publikację jej PKGBUILDu.

sobota, 19 listopada 2016

Nadchodzi KDE-Applications 16.12

Wczoraj udostępnione zostały wersje beta (16.11.80) aplikacji, które składać się będą na nową odsłonę KDE Applications. W Archu właśnie są budowane i prawdopodobnie jeszcze dzisiaj trafią do repozytorium kde-unstable. Oczywiście tych, którzy mogą zachęcam do testowania, albowiem m.in. w ten sposób możemy pomóc arojasowi w ich prawidłowym paczkowaniu, a zespołowi KDE w usunięciu ewentualnych błędów jeszcze przed wydaniem, które jest oczekiwane 15.12.2016. W międzyczasie, 1.12. winno się jeszcze ukazać wydanie RC (16.11.90).
Nowe aplikacje niosą w sumie spore zmiany. Nie będę pisał o tym, co zostało przeportowane na KF5, bowiem z punktu widzenia "zwykłego" użytkownika ma to najmniejsze znaczenie. Istotne natomiast jest, że niektóre aplikacje nie będą kontynuowane, zmienił się również proces paczkowania niektórych.
Zacznijmy od tego co nie będzie już kontynuowane. Z KDE Apps wypadają zatem:

  • kde-baseapps; ta grupa paczek istniejąca co najmniej od czasów KDE4 (sorry, pamięć już nie ta, by pamiętać wcześniej) została wydzielona do odrębnych aplikacji. Są to: kdialog, keditbookmarks, kfind, konqueror. Pamiętajmy, że wcześniej wydzielony został również dolphin. Spośród aplikacji, które składały się na dawne kde-baseapps nie będzie już kontynuowane kdepasswd; prawdopodobnie deweloperzy doszli do wniosku, że istniejące narzędzia w systemie są wystarczające, a kdepasswd jedynie je dubluje.
  • kdepim; podobnie jak w przypadku kde-baseapps nie oznacza to, że KDE Apps 16.12 nie będzie mieć swojego programu typu PIM. Aplikacje dotychczas składajace się na kdepim zostały rozdzielone na samodzielne (to jest kontynuacja tego procesu) i obecnie będą to: akonadi-calendar-tools, akonadiconsole, akonadi-import-wizard, akregator, blogilo, grantlee-editor, kaddressbook, kalarm, kmail, kmail-account-wizard, knotes, kontact, korganizer, mbox-importer, pim-data-exporter, pim-sieve-editor, pim-storage-service-manager.
  • kdewebdev; podobnie jak powyższe - rozbite zostały na oddzielne aplikacje: kfilereplace, kimagemapeditor, klinkstatus, kommander)
  • kdgantt2
  • gpgmepp
  • kuser; znów prawdopodobnie deweloperzy doszli do wniosku, że funkcjonujące rozwiązania są wystarczające, a kuser jedynie niepotrzebnie je dublował.
Spośród powyższych aplikacji kdgantt2 i gpgmepp często stanowiły zależności innych paczek. Osoby, które budują aplikacje we własnym zakresie winny zatem sprawdzić jak obecnie paczki te należy budować. Aplikacje, które zostały porzucone (nie rozbite na odrębne) sensownie jest natomiast odinstalować z systemu. 
Ze względu na spore zmiany jakie zachodzą w KDEPIM, poleciłbym po aktualizacji sprawdzenie, czy na pewno mamy zainstalowane to, czego oczekiwaliśmy. Wprawdzie arojas dba o wszelkie zależności i jak na razie wydaje się, że wszystko odbędzie się bezboleśnie dla użytkownika, jednakże poleciłbym poświęcenie chwili na sprawdzenie.

niedziela, 13 listopada 2016

Zrozumieć niezrozumiałe - korzystanie z AUR helperów

Jak niemal wszyscy doskonale wiemy, w Archu istnieje AUR, zawierający "paczki", których nie ma w repozytoriach oficjalnych. Akronim tłumaczy się jako Arch User Repository. Tylko, że w przeciwieństwie do "normalnych" repozytoriów znanych z innych, mainstreamowych dystrybucji, w AUR nie spotkamy paczek binarnych, gotowych do zainstalowania w systemie, a jedynie "przepisy" na ich lokalną (na komputerze użytkownika) budowę. W AUR znajdują się zatem wyłącznie pliki automatyzujące kompilację jakiegoś programu i tworzące z niego paczkę rozpoznawalną przez pacmana, która może być następnie przez niego zarządzana.
Arch zaleca, by korzystanie z AUR odbywało się w nastąpujący sposób:

  1. ściągnięcie tzw. tarballa ze źródłami, bądź obecnie - sklonowanie ich repozytorium z GIT,
  2. przejście do katalogu z PKGBUILD (po ewentualnym wcześniejszym rozpakowaniu źródeł),
  3. wydanie polecenia makepkg z odpowiednimi przełącznikami,
  4. instalacja paczki (oczywiście można to wykonać w jednej linii z makepkg).

Jak zatem zauważyliście, cały proces budowy paczki odbywa się zatem na naszym dysku.
Żadne z narzędzi oficjalnie oferowanych w repozytoriach Archa nie potrafi zarządzać przepisami z AUR bezpośrednio. Przyroda nie znosi próżni, a człowiek ma to do siebie, że jeśli może sobie coś ułatwić, to prędzej, czy później tego dokona. Nie inaczej stało się z AUR. Mamy cały wysyp różnych narzędzi, które automatyzują powyższy proces. Chyba najpopularniejszym pozostaje yaourt pomimo wielkiej niechęci do tego narzędzia deweloperów Archa. Programy tego typu zwane są AUR helperami. Ich działanie obejmuje zwykle możliwość przeszukiwania bazy AUR w poszukiwaniu interesującego nas programu, budowę oraz instalację (mniejsza o to, że ostatecznie i tak instaluje taki program pacman) zbudowanej paczki. Na pierwszy rzut oka, wszystkie te programy zachowują się zatem dokładnie tak samo jak pacman, na którego zresztą stanowią swego rodzaju nakładkę, czy też dla którego są pewnym rozszerzeniem.
Proces kompilacji dokonuje dziesiątek odwołań do plików. Jeśli wykonywany jest na dysku typu HDD jest on powolniejszy, zwykle również konsekwencją tych odwołań do dysku jest spowolnienie działania całego środowiska, czy programów. Większość AUR helperów do procesu kompilacji wykorzystuje katalog /tmp. W Archu nie jest to "zwykły" katalog umieszczony na dysku, ale pewna przestrzeń tworzona w RAM. W ten sposób tworzenie paczki jest nie tylko szybsze, ale również oszczędza nam dysk.
Ma to jednak inne konsekwencje.
Podczas budowania paczki ściągane są źródła, następnie tworzone są dwa katalogi src oraz pkg. W następnym kroku źródła są przenoszone do katalogu src, tam rozpakowywane, potem odbywa się proces kompilacji, a następnie zbudowane w jego wyniku skompilowane już składniki aplikacji, są przenoszone do katalogu pkg, który w dalszej kolejności jest pakowany do jakiejś postaci akceptowalnej przez pacmana - najczęściej tar.xz.
Zwróćmy teraz uwagę, że w katalogu, w którym tworzona jest paczka musimy zarezerwować miejsce dla źródeł i to często dwukrotnie, rozpakowanych źródeł, plików tworzonych podczas kompilacji programu oraz będących jej wynikiem plików binarnych, które również wymagają podwójnego miejsca (raz w src drugi raz w pkg) oraz spakowanej paczki. Standardowo, w przypadku AUR helperów wszystko to odbywa się w RAM, a w zasadzie do dyspozycji tmpfs, w którego części mieści się tmp gdzie paczka jest budowana, w połowie jej rozmiaru (domyślnie dla tmpfs rezerwowana jest połowa dostępnej pamięci RAM).
Pół biedy zatem, gdy za pomocą AUR helpera budujemy stosunkowo niewielką paczkę, która ma stosunkowo niewielkie źródła. Wszystko przebiegnie gładko i po chwili otrzymamy zbudowaną paczkę, gotową do zainstalowania. Jednakże, gdy zamierzamy zbudować jakiś większy program, bądź też całkiem mały, jednakże wymagający sporo miejsca, to bez trudu cała przestrzeń tmp zostanie zajęta na potrzeby budowania paczki. Konsekwencją będzie nie tylko częsty komunikat o braku dostępnego miejsca dla jej budowy, ale nawet problemy w działaniu całego systemu.
Dla uzmysłowienia sobie skali problemu zwróćmy uwagę na stosunkowo niewielką paczkę i zarazem często stosowaną, jaką jest opera-ffmpeg-codecs. Cała paczka, po zbudowaniu liczy zaledwie ok. 3 MB. Dla zbudowania wymaga jednak pobrania źródeł całego chromium, które liczą sobie blisko 460 MB i to w postaci skompresowanej do xz. Po rozpakowaniu sam katalog ze źródłami chromium liczy sobie ok. 2,4 GB. Efekt jest taki, że dla zbudowania stosunkowo małej paczki opera-ffmpeg-codecs wymagany jest obszar ok. 4-5 GB pamięci RAM. Jest oczywiste, że na komputerze, który nie jest wyposażony w co najmniej 6 GB RAM (a i to jest absolutnie graniczną wielkością i zależną od wielu czynników) taka operacja się nie powiedzie. Konsekwencją próby budowy tej paczki na komputerze, który ma nie więcej niż 4 GB RAM może być stopniowy spadek responsywności środowiska (jeśli budujemy jednocześnie korzystając z jakiegoś), aż do oznak zawieszenia się komputera (tak na prawdę, to winny one minąć, niemniej jednak przez dłuższą chwilę komputer będzie zachowywał się jakby był zawieszony).
Dodatkowo musimy jeszcze pamiętać, że nie każdy AUR helper usuwa po sobie pozostałości budowania paczki, które w dalszym ciągu zajmują RAM (tmp).
Innymi słowy - budujmy paczki z głową.

środa, 9 listopada 2016

sobota, 29 października 2016

Google Earth AppImage aktualizacja

Udostępniam nową wersję Google Earth w formacie AppImage. Mam nadzieję, że wszystko zostało wyjaśnione w poprzednim poście. Jednocześnie za kilka dni przestanie być możliwe pobieranie starszej wersji.

poniedziałek, 24 października 2016

Otter-Browser #147

Po usunięciu kilku wydań tygodniowych, ukazało się w końcu pierwsze wydanie nowej wersji 0.9.12, oznaczone nr 147. U mnie jak zwykle PKGBUILD.

piątek, 21 października 2016

Brak ikon "breeze-dark" na liście wyboru

W KF5.27 wdarł się trywialny błąd skutkujący podwójnym wyświetlaniem nazwy Bryza (Breeze) ikon i jednoczesnym brakiem Ciemnej Bryzy (Breeze Dark) na liście wyboru ikon dostępnych w Plasma 5.
Cała sprawa została zgłoszona i naprawiona. Cykl wydawniczy KF powoduje, że poprawione wydanie zostanie dostarczone wraz z KF5.28 na początku listopada. Błąd polega wyłącznie na wadliwej nazwie - motywy ikon obu wersji są w systemie. Jeśli nie chcemy czekać na KF5.28, możemy łatwo problemowi zaradzić, albowiem cały błąd sprowadza się do wadliwej nazwy motywu określonej w pliku /usr/share/icons/breeze-dark/index.theme. Możemy sami plik ten wyedytować i odpowiednio zmienić, możemy również zamienić go udostępnionym już w GIT prawidłowym plikiem.

środa, 19 października 2016

Na froncie Plasmy, czyli coś się wyjaśnia

Do tej pory wiedzieliśmy, że "Plasma 5.8 LTS będzie pierwszym wydaniem LTS w tej serii". Jej wsparcie sięga do kwietnia 2018 r., kiedy to 10.04. ma się ukazać ostatnie wydanie 5.8.9. Podobne informacje przychodziły z "frontu" Qt, które przy okazji wydania Qt5.6 stwierdziło, że to pierwsze wydanie LTS tej serii. Do tej pory nie było natomiast wiadomo jak będzie przebiegać rozwój Plasma 5 oraz kiedy można się spodziewać następnego LTS oraz jak przebiegać będzie dalszy rozwój Plasmy. W sprawie Qt 5 wiadomo od dawna, że obok Qt5.6 LTS wydawane są następne wydania. Zgodnie ze szczątkowymi i enigmatycznymi informacjami, następny LTS Qt 5 spodziewany jest w roku 2018. Teraz już wyjaśnia się nieco więcej. Rozwój Plasma 5 został zaplanowany do sierpnia 2018 r., kiedy ukazać się ma następny LTS serii 5. Prawdopodobnie również będzie miał co najmniej osiemnasto miesięczne wsparcie. Tym samym Plasma 5 towarzyszyć nam będzie co najmniej do roku 2020.
Poszczególne wydania mają się ukazać według następującego harmonogramu:

  • 31.01.2017 - Plasma 5.9
  • 30.05.2017 - Plasma 5.10
  • 26.09.2017 - Plasma 5.11
  • grudzień 2017 - Plasma 5.12
  • kwiecień 2018 - Plasma 5.13
  • sierpień 2018 - Plasma 5.14 LTS

Wydanie Plasma 5.14 oparte ma być o kolejny Qt5 LTS, który spodziewany jest latem 2018 r.
Jak widać spadła ilość nowych wydań Plasma 5 w ciągu roku. Podczas gdy do tej pory ukazywały się 4 wydania, na lata 2017-18 zaplanowane zostały po 3 nowe wydania środowiska.
Oczywiście dalej pojawiać się mają wydania KF5 w comiesięcznym cyklu, aż... do czasu, gdy zostanie to zmienione, bądź odwołane.
Jak na razie - nie pojawiają się jeszcze informacje na temat przyszłej Plasma (lub KDE) 6, jednakże z pewnych strzępów informacji, fragmentów kodu, wydaje się, że prędzej czy później spodziewać się można takiego wydania. Prowadzone są bowiem wstępne ustalenia na temat Qt 6, a biorąc pod uwagę powiązanie KDE i Qt, gdy pojawi się Qt 6, to ruszą prace nad nową wersją środowiska, która oznaczona prawdopodobnie zostanie zwyczajowo taką samą cyfrą jak framework, na którym jest oparte. Pewnie spodziewać się będziemy tego mogli w okresie wspierania kolejnej Plasma 5.14 LTS. To oczywiście spekulacje oparte o owe strzępki informacji oraz historię rozwoju KDE.
Czego możemy się spodziewać w kolejnych wydaniach Plasmy?

Wygląd
Tutaj przewidywany jest dalszy rozwój, wspieranie coraz większej ilości aplikacji, niewielkie retusze. Ciekawiej wygląda zapowiadany wystrój Breeze dla Firefoksa oraz zmiany w zakresie polepszenia ujednolicenia wyglądu aplikacji Qt i Gtk.

Funkcjonalność
Dla osób spragnionych tzw. global menu, dobra informacja. Zapowiadany jest powrót tej funkcji do Plasmy. Co ciekawe, całkiem możliwe, że funkcja ta pojawi się już w Plasma 5.9.
Polepszeniu ma ulec również obsługa lokalizacji.

Wayland
Nowy "serwer" grafiki w linuksie jest oczkiem w głowie twórców KDE. Cóż - moim skromnym zdaniem - obecna implementacja wsparcia Waylanda w KWin znajduje się w fazie alpha jeszcze raczej niż beta. Niestety - z jakiegoś powodu - twórcy KDE ułatwiają nam życie z Plasmą 5 na Waylandzie, umieszczając skrypty, czy programy, które umożliwiają łatwe uruchomienie takiej sesji. Dodatkowo jeszcze Jonathan Riddell oferuje obrazy Neona uruchamiające się w takiej sesji. Jak na razie - więcej z tym kłopotów niż pożytku i według mnie oddanie możliwości uruchomienia Plasma 5 na Waylandzie także osobom, które nie są testerami robi niedźwiedzią przysługę temu środowisku. Niemniej jednak prace nad dalszym wsparciem dla sesji Plasmy w Waylandzie są przewidziane. Zobaczymy co z tego wyjdzie. Konkurencja nie śpi i Fedora 25 w istocie zaproponowała działające obrazy Gnome 3.22 na Waylandzie, które są w pełni fukcjonalne.

Plasma Mobile
Mało kto pamięta, że od dłuższego czasu rozwijana jest mobilna wersja Plasma 5. Także i w tym kierunku trwać mają prace. Szczerze mówiąc, nie mam pojęcia na co liczą twórcy KDE, albowiem bez wsparcia ze strony jakiegokolwiek producenta, czy operatora sieci, projekt jawi się jako wysoce hobbystyczne przedsięwzięcie.

Serwisy sieciowe
Po uruchomieniu KDE Store oraz dodaniu wsparcia dla GDrive w Plasma 5, planowany jest dalszy rozwój w zakresie ułatwienia dostępu do różnych serwisów/usług sieciowych.

Więcej i na podstawie:
https://community.kde.org/Schedules/Plasma_5
Informacja na blogu sebasa


wtorek, 18 października 2016

KGpg-git w AUR a sprawa KF5

W AUR od dłuższego czasu jest skrypt pozwalający na budowę narzędzia do zarządzania GPG w KDE w wersji rozwojowej. Od miesiąca otrzymana paczka - o ile się zbuduje - będzie wadliwa, albowiem 9.09.16 nastąpiło połączenie linii master i frameworks (a to oznaczać powinno, że wraz z KDE-Applications 16.12 otrzymamy już przeportowaną do KF5 aplikację). Od tej pory Kgpg winno być budowane w wersji opartej o KF5. Kwestia zgłoszona, zatem za jakiś czas skrypty winny zostać poprawione. Do tego czasu zapraszam do korzystania z załączonego PKGBUILDa.

poniedziałek, 10 października 2016

Zwiększamy wielkość ikon w tacce systemowej w Plasma 5

Mnie to nie dotyczy, jednakże niektórzy dostrzegają zbyt małą wielkość ikon w tacce systemowej, zwłaszcza w nowej Plasma 5.8. Problem został dostrzeżony i uzyskał status potwierdzonego. Jak na razie dostępne jest pewnego rodzaju obejście powyższej sytuacji. Otwieramy do edycji plik: /usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/config/main.xml i odnajdujemy w nim sekcję:
<entry name="iconSize" type="Int">
      <label>Default icon size for the systray icons, it's an enum which values mean, Small, SmallMedium, Medium, Large, Huge, Enormous respectively. On low DPI systems they correspond to 16, 22, 32, 48, 64, 128 pixels. On high DPI systems those values would be scaled up, depending on the DPI.</label>
      <default>1</default>
    </entry>
W miejscu 1 wpisujemy jakąkolwiek liczbę większą niż jeden. Wydaje się, że 2 będzie właściwa.

Włączamy menu programów klawiszem Meta w Plasma 5.8

Wraz z pojawieniem się Plasma 5.8, zawitała nowa, aczkolwiek ukryta jeszcze, funkcja. Otóż możemy poinstruować KWin, by do otwierania menu programów (zwyczajowo Alt+F1) używał klawisza bez większego znaczenia w świecie linuksa, czyli tzw. Meta (Windows, Super). Niestety jak na razie nie zostały nam dostarczone żadne narzędzia GUI ułatwiające zadanie. Musimy się posłużyć edycją pliku ~/.config/kwinrc. Całość operacji nie powinniśmy przeprowadzać w działającej sesji KWin. Chcąc uzyskać możliwość otwierania menu programów za pomocą Meta, po otworzeniu do edycji ~/.config/kwinrc prawdopodobnie będziemy musieli dodać (bądź zmodyfikować) do jego zawartości następujący wpis:
[ModifierOnlyShortuts]
Meta=org.kde.krunner,/App,,display
Po ponownym uruchomieniu sesji Plasma będziemy się mogli cieszyć menu programów przypisanym do Meta.

Za blogiem Jana Buchara.

niedziela, 9 października 2016

Qt5-webengine 5.7.0-4 psuje aplikacje sieciowe

Wczoraj do repozytoriów trafiła przebudowana wersja paczki qt5-webengine 5.7.0 oznaczona nr 4 (5.7.0-4). Powodem jej przebudowy jest nowa wersja jsoncpp (1.7.7), która również wczoraj pojawiła się w repozytoriach. Instalacja nowej wersji qt5-webengine spowoduje brak możliwości korzystania prawodopodobnie z jakiejkolwiek aplikacji wykorzystującej ten silnik. Sprawdziłem na QupZilla, Otter-Browser (z tym silnikiem), KMail. Wszystkie te aplikacje wprawdzie uruchamiają się, jednakże nie wyświetlają żadnej treści.
Do czasu rozwiązania problemu, należy się zatem powstrzymać z aktualizacją tych paczek i dodać je (tymczasowo) do pola IgnorePkg w /etc/pacman.conf.
Osoby, które już dokonały aktualizacji i spotkały się z błędnym działaniem dotychczas prawidłowo działających aplikacji sieciowych, powinny dokonać cofnięcia wersji do qt5-webengine 5.7.0-3 oraz jsoncpp do wersji 1.7.6-1.

EDIT:
Ukazała się już wersja qt5-webengine 5.7.0-5, która problem zażegnała.

wtorek, 4 października 2016

Tuning Plasma 5 - zmieniamy kolor ekranu powitalnego

W wydaniu Plasma 5.8 znacznie zmieni się ekran powitalny motywu Breeze, który obecnie wyglądać będzie tak:

Jak widzicie, zamiast kolorowego tła jakiejś tapety, mamy jednolity kolor. Jeśli nie podoba się Wam taka kolorystyka, to możemy ją zmienić (uwaga: będzie tak to najbliższej aktualizacji).
W tym celu odszukujemy plik
/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/splash/Splash.qml
i dokonujemy jego edycji (uwaga - oczywiście konieczne są uprawnienia root). Odszukujemy następujący ciąg (mieści się on praktycznie na samym początku):
Rectangle {
    id: root
    color: "black"
i w miejsce słowa black wpisujemy inną, angielską nazwę koloru, jaki nam się podoba np. red.

Przy okazji podzielę się też inną informacją. Otóż w Plasma 5.8 (przynajmniej jest to obserwowalne w 5.7.95, a z informacji z bugzilli nie wynika, by w wydaniu finalnym nastąpić miała jakaś zmiana), nastąpiła pewna regresja. Moduł odpowiedzialny za ustawienia wyglądu ekranu powitalnego widzi wyłącznie te, które zostały dostarczone wraz z tzw. "look & feel", czyli obecnie wystroje Breeze i Oxygen oraz brak ekranu powitalnego. Pomimo tego, że paczka ksplash dostarcza jeszcze "minimal" i "classic", to nie są one widoczne, podobnie jak doinstalowanie jakiegokolwiek wystroju tego ekranu np. z store.kde.org, czy też stworzenie go we własnym zakresie, nie powoduje, że staje się on widoczny w środowisku. 

piątek, 30 września 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.

niedziela, 25 września 2016

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:
Exec=sh -c '/usr/bin/aplikacja'
Oczywiście mogą tu być jeszcze jakieś dodatkowe zmienne.
I tego ostatniego polecenia Plasma nie jest w stanie zinterpretować. Wystarczy jednak umieszczenie go w znaku cudzysłowia i wszystko wraca do normy. Chcąc zatem uruchamiać taki program konsolowy bezpośrednio z menu musimy doprowadzić ową linię do następującej postaci:
Exec="sh -c '/usr/bin/aplikacja'"
I wszystko winno już wrócić do normy.

piątek, 23 września 2016

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.tar.xz.
O ile jednak w przypadku paczek pobieranych ze zdalnych lokalizacji, ich kompresja ma sens, to w przypadku lokalnego budowania paczek na własny użytek, jak się wydaje mija się z celem. Nie tylko uzyskanie paczki trwa dłużej o czas kompresji (który może być całkiem znaczny - zobaczcie sobie ile trwa np. kompresowanie libreoffice-fresh-rpm), ale również wymaga dodatkowej przestrzeni dyskowej (albo zwiększa zapotrzebowanie na tę przestrzeń w tmpfs, co niekiedy prowadzi do zwrócenia informacji, że paczka nie została zbudowana, pomimo tego, że w istocie do formatu nazwa.pkg.tar to nastąpiło).
Tymczasem nieskompresowana paczka jest tak samo dobrze zarządzana przez pacmana, jak i paczka skompresowana. Jedyna różnica, to zabieranie większej ilości miejsca na dysku (jeśli ją tam zostawimy).
Jeśli zatem podzielacie moje spostrzeżenia, to możecie dokonać prostych czynności, które spowodują, że makepkg zaprzestanie kompresowania paczek.
W tym celu, dowolnym edytorem edytujemy plik /etc/makepkg.conf i odszukujemy w nim sekcję EXTENSION DEFAULTS, w której zmieniamy zawartość linii PKGEXT z:
PKGEXT='.pkg.tar.xz'
na
PKGEXT='.pkg.tar'
Od tej chwili makepkg będzie tworzył nieskompresowane paczki. Różnicę w czasie budowania sprawdźcie sobie na wpomnianym wcześniej libreoffice-fresh-rpm.

wtorek, 20 września 2016

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 KDE4 (i to nawet za pośrednictwem kdelibs4support).
Do czasu, gdy arojas dokona odpowiednich zmian, chcącym zbudować te paczki proponuję sięgnięcie po nieco zmieniony PKGBUILD, który umożliwia ich budowę z aktualnymi zależnościami i oczywiście pozbawionych konq-plugins, które są "wbudowane" w konquerora. Tym razem PKGBUILD jest w pastebin, albowiem pochodzi on z mojego zgłoszenia konieczności zmian. Treść widoczną w pastebin należy skopiować jako RAW i zapisać w jakimś katalogu pod nazwą PKGBUILD.

EDIT:
Dzisiaj (22.09.2016) pojawiły się nowe wersje paczek składających na kde-baseapps-git. Proponowana przeze mnie zmiana nie jest już konieczna.

sobota, 17 września 2016

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 przewidzieli. Ignorowanie aktualizacji jest natomiast przez niektórych użytkowników traktowane jako remedium na kłopoty z działaniem systemu. Nic w tym dziwnego - sposób jest nawet opisany w wiki Archa. Zastanówmy się jednakże, czy w każdym przypadku jest to wybór paczki przeznaczonej do ignorowania podczas aktualizacji systemu jest prawidłowy.
Przypomnijmy sobie jak jest konstruowany linux. Jakaś aplikacja zwykle czerpie z czegoś (bibliotek), które są dostępne również innym programom. Aplikacja X jest zatem zależna od biblioteki Y. Ta natomiast może być zależna od jeszcze innej itd. W Archu informacje o zależnościach - często - przekazywane są jedynie jako nazwy programów, bez podania wersji (fakt zdarzają się i takie sytuacje, ale sporadycznie). System wszak ma być zawsze zaktualizowany jako całość. Pół biedy zatem, jeśli do pominięcia przy aktualizacji wybierzemy jakąś paczkę, która jest niezależna od innych. Pół biedy - jeśli wybierzemy taką, która prawidłowo działa w oparciu o inną, jednakże w dość dowolnej wersji. Gorzej, jeśli do ignorowania przeznaczymy paczkę "ze środka".
Oczywiście przykładem będzie nowe środowisko od KDE. Jak wiecie składa się ono z 2 elementów: bibliotek, zwanych KDE Frameworks 5 oraz samego środowiska Plasma 5. Owe biblioteki budowane są w pewien hierarchiczny sposób. Do prawidłowego działania wszystkie wymagają oczywiście Qt 5 w odpowiedniej wersji minimalnej (obecnie - ze względu na Debiana jest to wersja, która jest w nim dostępna). Komponenty składające się na KF5 podzielone są na 3 poziomy (en. tier). Na poziom pierwszy składają się te elementy KF5, które nie są zależne od innych elementów KF5 oraz budowane wyłącznie o zależności w Qt5. Poziom 2 to elementy, których zależnościami są wyłącznie elementy z Poziomu 1 (oczywiście dalszymi zależnościami będą ich zależności). Poziom 3 to elementy zależne od tych, które należą do Poziomu 1 i 2. Oczywiście Poziom 2 zależy od Poziomu 1 w odpowiedniej wersji i podobnie Poziom 3 od odpowiedniej wersji Poziomu 1 i 2. Całość KF5 jest pomyślana natomiast w taki sposób, by zawsze działała jako całość. Wszystkie jej komponenty winny być w tej samej wersji. Elementów wyższych poziomów nie jesteśmy w stanie zbudować zarówno w nowszej, jak i w starszej wersji w stosunku do elementów z niższego poziomu (i to nawet, jeśli się zdarzy, że jakiś element nie został pomiędzy wydaniami zmieniony).
Podobnie dzieje się z Plasmą, która również budowana jest w oparciu o określoną wersję minimalną. Dla przykładu minimalne wymagania nadchodzącego wydania 5.8 to KF 5.26 oraz Qt 5.6.1. Są to wymagania minimalne, które oznaczają, że Plasma 5.8 będzie pracować z KF 5.26 oraz Qt 5.6.1, ale będzie pracować również z KF i Qt w wersjach wyższych niż te deklarowane, natomiast nie ma żadnej gwarancji prawidłowego działania z KF i Qt w wersji niższej. Gdybyśmy budowali to środowisko we własnym zakresie ze źródeł, to musimy mu zapewnić elementy, na których jest budowane przynajmniej w tych minimalnych wersjach. Inaczej budowa się nie powiedzie.
Wrócę do Archa i przypomnę to co napisałem na początku: Arch wspiera wyłącznie pełną aktualizację systemu, a nie aktualizację poszczególnych paczek w nim zawartych oraz zależnością jest "nazwa" określonej paczki, ale już - najczęściej - bez podania jej wersji. Powoduje to, że Archa można oszukać. Można sobie "skonstruować" taki system, w którym będą istniały wszystkie komponenty wymagane przez system, ale niekoniecznie już wszystkie one będą w tej samej (czyt. najnowszej) wersji.
Wprowadzanie do linii IgnorePkg poszczególnych paczek jest typowym zachowaniem osób, które na siłę chcą np. pozostawić sobie starszą wersję jakiegoś oprogramowania bądź też uznają, że jakaś paczka powoduje komplikacje w systemie. Nawet nie dochodząc tego, czy przez przypadek problem nie leży w niewłaściwej konfiguracji systemu.
Niestety, w przypadku takim jak opisany wyżej - ignorowanie aktualizacji poszczególnych paczek KF5 to prośba o destabilizację pracy całego środowiska. Im więcej tych paczek tam się znajdzie, tym bardziej praca w Plasmie będzie przypominać grę na loterii. To może "działać" (tzn. może nam się wydawać, że działa), ale wcale nie musi. Jeśli "działa", to oznacza wyjątkową odporność Plasmy.
Oczywiście opisany tu problem nie dotyczy wyłącznie Plasmy i KF5. Spotkamy się z nim praktycznie w każdym większym środowisku, które są pomyślane właśnie w taki sposób, by były budowane jako całość (w jednej wersji), na podstawie określonych bibliotek w określonych wersjach, które w tych samych wersjach winny być w systemie.
Wracając do środowiska KDE. Jeśli już musimy z jakichś przyczyn "zastabilizować" jego element, to wymaga to od nas odpowiedniej wiedzy i roztropności. KF5 winno być zawsze w tej samej wersji, zatem jeśli musimy mieć jakiś jego element w wersji wcześniejszej niż w repozytorium, to nie należy wpisywać tego elementu do IgnorePkg, ale całą grupę kf5 oraz kf5-aids przeznaczyć jako wyłączoną z aktualizacji i umieścić obie w IgnoreGroup. Jednocześnie wolno zignorować wyłącznie takie wersje KF5, które nie są wymagane do budowy Plasma 5 w określonej wersji. Oznacza to, że musimy mieć świadomość jakiej minimalnej wersji KF5 wymaga Plasma, a to powoduje, że musimy przeglądnąć zawartość plików CMakeLists.txt tej wersji Plasmy. Niekiedy będzie też może zajść potrzeba jej przebudowania w oparciu o KF5 znajdujące się lokalnie w systemie.
Pamiętajmy jednak, że ze względu na cykl wydawniczy KDE możemy w takim przypadku stracić możliwość wsparcia, zaś w przypadku Archa, gdy zgłosimy problem na jakimś forum, czy jego bugzilli, praktycznie jedyna porada jaką uzyskamy, to: zakutalizuj system.

piątek, 16 września 2016

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. Paczka była tworzona w systemie, w którym nie było zenity, przez co pierwsze uruchomienie nie tworzy odpowiedniej pozycji z menu (innymi słowy nie wie co ma zrobić z *.desktop). Alternatywą dla zenity w systemach opartych o Qt jest qarma. Aby system widział ten ostatni program jako zenity musimy jeszcze zrobić dowiązanie dla niego do pliku /usr/bin/zenity.

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 dostarcza wszystkich programów składających się na grupę octopi - pomija octopi-notifier, czyli oprogramowanie, które informuje o możliwych aktualizacjach oprogramowania. Pierwszy... Cóż, wydaje się, że opiekun PKGBUILDu niedokładnie go przemyślał. Otóż skrypt ten w istocie buduje całą gamę programów z grupy octopi. Ba, buduje nawet aż trzy programy octopi-notifier, oparte na trzech różnych bibliotekach (Qt4, Qt5 oraz KF5) i przeznaczone dla trzech różnych środowisk graficznych. I w tym leży problem. Ze względu na konflikt pomiędzy tymi trzema wersjami programu, paczki octopi wprawdzie zbudujemy przy pomocy jakiegoś wrappera AUR, ale ich nie zainstalujemy (być może taką możliwość daje bauerbill, ale nie próbowałem). Nadto jeszcze bezsensownie ściąga zależności konieczne do budowy każdej z tych paczek, pomimo tego, że nie są one nam potrzebne. Wersja Qt4 ściąga oczywiście całą grupę qt4, choć możemy sobie łatwo wyobrazić system wolny już od tego porzuconego oprogramowania. Wersja frameworks ściąga natomiast knotifications i wszystkie jego zależności (w praktyce całą grupę kf5 i jeszcze trochę). Nie sądzę, by te biblioteki były komuś potrzebne do szczęścia w środowisku innym niż Plasma 5. Ten ostatni problem pozostaje, gdy będziemy próbować zbudować octopi lokalnie z pomocą makepkg (tak wiem, niepotrzebne po budowie paczki można usunąć, jednakże po co powodować niepotrzebny ruch w sieci, co jest bardzo istotne dla osób o ograniczonych łączach).
Jeśli zatem dochodzicie do wniosku, że właśnie napiszę: PKGBUILD octopi w AUR jest bez sensu, to macie rację.
Prezentuję zatem dwa PKGBUILDy, które umożliwiają budowę zestawów odpowiednich dla Plasma 5 (to PKGBUILD.kf5) oraz dla innych środowisk (to PKGBUILD.qt5). Wersji Qt4 nie przedstawiam, albowiem może ona mieć znaczenie chyba wyłącznie dla osób, które korzystają jeszcze z KDE4, które nie jest już wspierane w Archu. Wszystkie inne środowiska graficzne, które są w repozytorium Archa oraz w AUR wykorzystują już Qt5 lub KF5. W środowiskach opartych o Gtk lepiej winno się natomiast sprawdzić inne oprogramowanie, jak np. pamac, czy tkPacman.
Jednocześnie, prezentowana przeze mnie wersja umożliwia budowę wersji deweloperskiej (z GIT), a nie wersji "stabilnej". Z tą ostatnią jest bowiem pewien szkopuł. Według twórcy tego oprogramowania, ostatnia wersja stabilna to 0.8.1. Niemniej jednak w dystrybucjach, które dostarczają octopi w repozytoriach, pojawiła się już wersja 0.8.3 (a w przypadku KaOSa to nawet 0.8.92). Takie samo oznaczenie nosi wersja w AUR. Repozytorium programu w GIT nie ma tak otagowanej wersji. Są one tworzone przez "uzupełnienie" wersji 0.8.1 do określonego commitu przez opiekunów tego oprogramowania w dystrybucjach. Zdaje się, że "ton" narzuciło tu Manjaro. W efekcie, gdybym chciał trzymać się prawidłowej wersji stabinej, to musiałbym ją zrobić w oparciu o 0.8.1 (jak wspomniałem, to jest wersja stabilna). Takie oznaczenie jednak, powodowałoby, że próba aktualizacji systemu (z AUR) narzuciłaby konieczność aktualizacji również octopi, albowiem w AUR jest wersja wyższa. Oczywiście nie ma przeszkód dla stworzenia wersji oprogramowania z dokładnie tym samym commitem, jaki jest uwzględniony w AUR. Nie widzę jednak sensu tworzenia bytów, które nie istnieją. Jeśli jednak znajdą się chętni na taką wersję, to jeśli sami nie będą w stanie stworzyć sobie PKGBUILDu, jestem gotowy pomóc.
Jeszcze drobna uwaga: paczka zawiera - jak wspomniałem - dwa PKGBUILDy o nazwach PKGBUILD.kf5 oraz PKGBUILD.qt5. Chcąc zbudować sobie octopi w wybranej wersji albo należy zmienić nazwę odpowiedniego pliku na PKGBUILD, albo wykorzystać możliwości makepkg i wykonać:
makepkg -p PKGBUILD.kf5 - dla Plasma 5
albo
makepkg -p PKGBUILD.qt5 - dla pozostałych środowisk
Oczywiście istnieją alternatywy dla proponowanego rozwiązania. Dla przykładu kuszącą propozycją wydaje się być wprowadzenie jednego PKGBUILD dla wszystkich paczek oprócz octopi-notifier i dwu PKGBUILD dla octopi-notifier, po jednym dla wersji Qt5 i KF5. Ze względu jednak na to, że wszystkie składniki octopi wykorzystują jeden kod źródłowy, takie rozwiązanie dwa razy ściągałoby kod programu. Są jeszcze inne, ale te wymagałyby ingerencji w PKGBUILD przez użytkownika. Najsensownie rozwiązanie wydaje się takie, by sam PKGBUILD prowadził do sprawdzenia, czy w systemie znajduje się knotications i wówczas budował wersję dla Plasma 5, a w przeciwnym przypadku wersję "pure-Qt5". Nie jestem jednak pewny, czy w innych środowiskach, jako zależność na pewno nie pojawi się knotifications, którego jednak środowisko to nie będzie potrafiło wykorzystać. Z tych powodów zatem prezentuję takie rozwiązanie jak wyżej.

EDIT:
Dzięki uwadze użytkownika marekmm, oba PKGBUILDy zostały lekko zmienione (usunięty został błąd przy octopi-notifier).

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 Backports. De facto zatem, twórcy Linux Mint poskładali swą dystrybucję z obcych klocków, przy czym to co mnie najbardziej interesuje w kontekście "największego dopracowania" dystrybucji z Plasmą, to całość tego środowiska jest w nim "obca". Jak to działa? Otóż Linux Mint nie prowadzi dla swojej dystrybucji żadnych paczek z KDE, a to oznacza, że nie istnieje w niej żaden opiekun tak tych paczek, jak i środowiska. Całość KDE stanowią paczki bezpośrednio ściągane z repozytorium innej dystrybucji. Innymi słowy Linux Mint 18 KDE jest w zakresie środowiska KDE w całości uzależniony od tego co robią deweloperzy Kubuntu odpowiedzialni za PPA z backportami.
Mam zatem pytanie, czy za dopracowaną dystrybucję można uznać taką, która praktycznie nie oferuje, bo nie może, żadnego wsparcia dla środowiska z jakim się ukazuje.
Idźmy dalej. Specyfika wydawania nowego środowiska KDE polega na niezależnym tworzeniu trzech różnych jego elementów oraz ścisłym powiązaniu z Qt. Te trzy elementy to KDE Frameworks, Plasma oraz Applications. Każdy z nich ma swój cykl wydawniczy, przy czym - podobnie jak w przypadku LibreOffice - oparty on jest na czasie. Z góry wiadomo kiedy ukaże się nowa "wersja" środowiska, bibliotek i aplikacji, jak również z góry wiadomo kiedy ukażą się poprawki tej wersji. Jednocześnie przebiega proces tworzenia nowej wersji, która ukaże się w zamierzonym czasie. Uwaga: nawet wówczas, gdy nie wszystkie zgłoszone błędy zostały poprawione, nawet wówczas, gdy nie wszystkie zamierzenia zostały wykonane. Jednocześnie poszczególne elementy tego środowiska są tak konstruowane, że są przeznaczone do działania z określoną wersją pozostałych elementów. Często na przykład, by zbudować nowszą wersję środowiska konieczne jest udostępnienie mu nowszej wersji frameworks, czy nowszej wersji Qt. Przypomina to nieco rozwój ciągły. Jednocześnie każda z nowych wersji poszczególnych elementów składających się na KDE jest na bieżąco poprawiana i modernizowana. Naprawiane są również błędy. To oznacza, że np. użytkownik korzystający ze starszej wersji środowiska i dostrzegający w niej jakieś błędy może nie być świadom, że w nowszej wersji te błędy zostały usunięte. Powoduje to, że całe istnienie systemu zgłaszania błędów w KDE ma znaczenie tylko dla ostatniego wydania. Dochodzimy do sedna: w określonym czasie istnieje tylko jedno wydanie KDE i zawsze jest ono najnowsze.
Tymczasem Linux Mint 18 KDE w chwili powstania przynosi Plasmę w wersji 5.6.5, którą w KDE określa się jako "historyczną" i która miała premierę 14.06.2016 r. W chwili wydania Linux Mint 18 KDE wersja Plasmy nosiła numer 5.7.4. Co zatem chce osiągnąć "najbardziej dopracowana dystrybucja z Plasmą" udostępniając swoim użytkownikom wydanie, dla którego nikt nie organizuje już wsparcia?
A propos tego ostatniego - dochodzimy do clou problemu. Otóż zdaniem autora tekstu:
Po ponad dwóch miesiącach dostajemy wersję ze środowiskiem Plasma, która jest warta szczególnego zainteresowania choćby ze względu na zapowiedziany okres wsparcia – poprawki, łatki i uaktualnienia będziemy dostawać do 2021 roku.
Próbowałem się dowiedzieć od eimiego skąd czerpie tę wiedzę. Informacji nie otrzymałem. Prawdopodobnie zatem będzie to interpretacja słów Clema Lefebvre zawartych w informacji o wydaniu.
Linux Mint 18 is a long term support release which will be supported until 2021. It comes with updated software and brings refinements and many new features to make your desktop even more comfortable to use.
Zestawmy te wszystkie informacje ze sobą. Oto mamy dystrybucję, która na starcie przynosi historyczną wersję środowiska, nikt w niej nie jest odpowiedzialny za tworzenie paczek z tym środowiskiem, polegając w całości na paczkach z obcej dystrybucji, nikt też w tej dystrybucji nie odpowiada za jej rozwój, nie ma też wpływu na zmiany ewentualnych błędów w paczkowaniu. Mimo tego dystrybucja ta oferuje wsparcie dla Linux Mint 18 KDE do roku 2021 r. Z dalej idącego stwierdzenia eimiego wynika, że to właśnie w tej dystrybucji (jedynej na świecie) środowisko Plasma otrzyma poprawki, łatki i uakutalnienia do roku 2021 r.
Zejdźmy na ziemię. Jak na razie plany KDE sięgają kwietnia 2018 r. Wówczas skończy się wsparcie dla Plasma 5.8 (oraz prawdopodobnie dla Frameworks 5.26). W międzyczasie, w zwykłym trybie, powstawać będą nowe wersje Plasmy (czyli 5.9, 5.10 itd.) oraz Frameworks (już w przyszłym miesiącu ukaże się 5.27). Wiemy również, że na późną jesień br. planowana jest nowa wersja Qt 5, jak również, że istnieją plany stworzenia nowej wersji Qt 6. Następna wersja Qt z długotrwałym wsparciem jest oczekiwana za około 18 miesięcy. Nie wiadomo jeszcze czy będzie to wersja z linii 5 czy już 6. Zakładając jednakże, że będzie to wersja 5 to znów uzyska ona wsparcie. Prawdopodobnie na dalsze 18 miesięcy, czyli najdalej do końca roku 2019. Jeśli tak się stanie, to mniej więcej do tego momentu liczyć możemy na wydawanie Plasma 5 i jej wsparcie. Tyle wiemy, choć ostatnie informacje są późniejsze niż data proklamowania przez Clema Lefebvre wsparcia Linux Mint 18 KDE do roku 2021.
Teraz już tylko spekulacje, choć nie pozbawione pewnej wiedzy.
Dotychczasowy rozwój KDE, jak również pojawiające się w kodzie pewne "zajawki", pozwalają przyjąć z dużą dozą pewności, że z chwilą pojawienia się Qt 6 przystąpią do prac nad kolejną wersją środowiska KDE, które zostanie oznaczone numerem 6. Przez jakiś czas jeszcze będzie utrzymywana i wspierana wersja 5 (choć prawdopodobnie krócej niż miało to miejsce w przypadku KDE4 - dlaczego tak sądzę, to inna opowieść). Wraz z pojawieniem się Qt 6 wygaszane będzie wsparcie dla Qt 5, aż w końcu przestanie ono być wspierane. Jeśli te fakty nastąpią przed rokiem 2021, to wówczas nic nie jest w stanie zapewnić wsparcia Linux Mint 18 KDE.
Nie mówię tego gołosłownie. Przyglądnijmy się Linux Mint 17 KDE. Ta wersja zawiera KDE4 i ma wsparcie do roku 2019. Jak na razie nie istnieje żaden sposób zainstalowania Plasma 5 w tej wersji Minta. Nie istnieje nawet (przynajmniej oficjalna) możliwość aktualizacji Linux Mint 17 KDE do Linux Mint 18 KDE. Jednocześnie w sierpniu 2015 r. KDE4 zostało porzucone. Dalej wspierany jest wyłącznie jeden element tego środowiska, czyli kde-workspace. Będzie on wspierany tak długo, jak długo wszystkie aplikacje składające się na KDE Applications nie zostaną przeportowane do KF5. Potem i ten element zostanie porzucony. Istnieje możliwość, że stanie się to już w grudniu br., istnieje, że dopiero w kwietniu przyszłego roku. Nie powinno trwać dłużej. Żaden inny element tego środowiska wspacia już nie ma. Podobnie jak i Qt4, na którym jest ono oparte nie ma już wsparcia. Czy zatem twórcy Linux Mint przejęli kod KDE4 i Qt4? Stworzyli stosowny system zgłaszania błędów w tym środowisku? W końcu czy istnieje choć jedna osoba w gronie Linux Mint, która jest w stanie ten kod - w przypadku dostrzeżenia błędów - poprawić? Nie - nie pozostawię tych pytań retorycznymi. Pierwsze nie zostało dokonane, drugie również, a trzecie... skoro pierwsze dwa nie istnieją, to nawet zakładając, że pośród osób dbających o rozwój Linux Mint w wersji KDE istnieją osoby, które potrafiłyby to zrobić, to nie mają takich możliwości. Inna sprawa, czy gdyby w Linux Mint istniały takie osoby, to oddałyby całość środowiska w ręce innej dystrybucji? Pomimo zatem deklaracji, Linux Mint 17 KDE nie oferuje wsparcia (dla środowiska) do roku 2019. Tak samo tylko przypadkiem - gdy Plasma 5 w ogóle dotrwa do tych czasów - będzie mógł zaoferować (ale nie własnymi siłami) wsparcie dla Linux Mint 18 KDE do roku 2021. Dość mętnie zresztą tłumaczy się z owego wsparcia Plasmy do roku 2021 sam Clem Lefebvre.
Cóż - osobiście sądziłem, że tego typu deklaracje bez pokrycia - są w świecie wolnego oprogramowania obce. Zwłaszcza, że Linux Mint jest adresowany do osób najmniej doświadczonych w linuksowym świecie. Niestety słowa Lefebvre o wsparciu Plasmy do roku 2021, bez żadnej refleksji powtarzane w jednym z najpopularniejszych polskich serwisów, można między bajki włożyć.
I dlatego Mint z KDE nie będzie dla mnie nigdy dopracowaną dystrybucją z Plasmą. Ba, mam wątpliwości, czy w ogóle można to nazwać dystrybucją z Plasmą. Nie przeczę przy tym, że Linux Mint ze swoimi natywnymi środowiskami (Cinnamon i MATE) jest wartościowe.

czwartek, 15 września 2016

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 się pod tym adresem.
Uwagi dotyczące paczkowania (i funkcjonowania w Archu) należy zgłaszczać pod tym adresem.
Oczywiście namawiam na korzystanie z naszego forum. Tu również będziemy się starać pomagać w dostosowaniu Archa do nowego środowiska.

Otter-Browser #141

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

środa, 14 września 2016

"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ędzie LTSem ze wsparciem do kwietnia 2018 r. Nic do tej pory nie było wiadomo o LTSie KF, czy też dalszym rozwoju Plasmy obok LTS w wersji 5.8.
Teraz coś się wyjaśnia.
Otóż KF5 w wersji 5.26 również ma stać się LTSem. Jest to jednocześnie minimalne wymaganie dla budowy Plasma 5.8. Samo KF 5.6 ma natomiast minimalne wymaganie w Qt w wersji 5.6. To oznacza, że do kwietnia 2018 r. będziemy mogli cieszyć się stabilną wersją środowiska pochodzącego od KDE, które nie będzie otrzymywać żadnych nowych funkcji, a jedynie poprawki błędów. To środowisko będzie się składać z Qt5.6, KF5.26 oraz Plasma 5.8. Jedyne zmiany funkcjonalności (czego po prostu nie obejmuje LTS) to "kompatybilność" z Waylandem.
Teraz jednak okazuje się, że obok LTS będą wydawane kolejne wersje KDE w swoim dotychczasowym cyklu. Oznacza to, że kolejne wersje KF5 będą się ukazywać co miesiąc (w październiku 5.7 itd.), na wiosnę przyszłego roku zobaczymy Plasmę 5.9 itd., aż do ukazania się Qt 6, które prawdopodobnie spowoduje powstanie "KDE 6", czyli - bowiem nic nie wskazuje, by ten model miał ulec zmianie - otrzymamy KF6 i Plasmę (KDE) 6. Model wydawniczy w wersji "5" będzie natomiast kontynuowany do końca wsparcia Qt5.

sobota, 10 września 2016

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ązany mamy dwa obejścia problemu. Pierwszego nie polecam. Korzystacie na własne ryzyko. Może to doprowadzić do destabilizacji całego systemu. Obejściem tym jest instalacja paczki dbus-x11 z AUR. Raz jeszcze: nie korzystać z tej porady. Przedstawiam, bo gdzieś możecie znaleźć to rozwiązanie jako proponowane.
Do czasu rozwiązania problemu proponuję natomiast inne rozwiązanie, które wykorzystuje składniki systemu i według mojej wiedzy, nie powoduje żadnych niekorzystnych w systemie problemów i powikłań.
Zamiast zatem uruchamiać program w dotychczasowy sposób, uruchamiamy go wydając następujące polecenie:
kdesu dbus-launch nazwa_programu
lub
gksu dbus-launch nazwa_programu
ewentualnie
sudo dbus-launch nazwa_programu
Polecenie wydajemy w konsoli bądź - w przypadku Plasma - korzystając z Krunnera.

środa, 7 września 2016

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 przede wszystkim - wie jakie paczki mu się z tego repozytorium instalują, jak dowiedzieć się jakie paczki ma z określonego repozytorium oraz potrafi dojść do przyczyn problemów z aktualizacją systemu, konfliktującymi pakietami/plikami, zepsutymi zależnościami itd. Wie w końcu co zrobić w sytuacji, gdy system nie bardzo chce dalej pracować, aktualizować się itd.
Spora część użytkowników wprowadza jednak nieoficjalne repozytoria nie mając pojęcia co robi. Dotyczy to szczególnie osób, które z Archem, czy Manjaro (i pochodnymi) mają do czynienia bardzo krótki czas. Wielu z nich wprowadza te repozytoria bo chce mieć nowsze oprogramowanie (np. wówczas, gdy z jakichś powodów paczki w repozytoriach nie są aktualizowane pomimo tego, że oprogramowanie jest dostępne już w nowszej wersji - tak się działo niedawno np. z MATE) albo chce na siłę utrzymać oprogramowanie, które zostało porzucone w repozytoriach (tak jest w dalszym ciągu z KDE4).
Pamiętajcie zatem, że paczki umieszczane w repozytoriach nieoficjalnych mogą być budowane w inny sposób, niż te dostępne w repozytoriach danej dystrybucji. Przede wszystkim mogą być budowane na innych skryptach, niż te, które są używane w systemie. To oznacza, że mogą one mieć inaczej ustawione zależności. Mogą się w tych repozytoriach pojawić również dodatkowe paczki, które nie są w ogóle dostępne w repozytoriach oficjalnych, powiązane jakoś z tymi, które są w repozytoriach nieoficjalnych. Mogą w końcu jakieś źródła być inaczej paczkowane i zamiast jednej paczki będziemy mieć kilka lub odwrotnie. Jeśli osoba odpowiedzialna za budowę tych paczek w sposób właściwy ustawiła konflikty, informacje co dana paczka dostarcza, co zastępuje, to jeszcze pół biedy. Bardzo często jednakże otrzymujemy paczki zbudowane z przynajmniej jedną wadliwą informacją niesioną przez skrypty służące do budowy paczki w takim repozytorium.
I zaczyna być problem.
Dla przykładu weźmy jakąś "nowszą" wersję programu, od tej, która znajduje się w systemie. Zdarzy się często, że po jakimś czasie oprogramowanie w repozytoriach oficjalnych zostanie zaktualizowane. Ba, często będzie też aktualniejsze od oprogramowania w owych repozytoriach nieoficjalnych. Jednakże próba aktualizacji systemu prowadzić będzie do ciągu nierozwiązywalnych zależności, a w efekcie do braku możliwości zaktualizowania jakiegokolwiek programu (pamiętajmy, że Arch wspiera wyłącznie całościową aktualizację systemu, a nie pojedynczej paczki).
Oczywiście istnieje możiwość "odwrócenia" zaistniałej sytuacji i doprowadzenie do aktualizacji systemu. Zanim jednak przedstawię co należy wówczas zrobić, zastanówmy się nad postawionym na wstępie pytaniem. Oczywiście przedstawię wyłącznie swoje zdanie na ten temat (niby czyje miałbym przedstawiać). Nie uzurpuję sobie prawa do obiektywnych w tym zakresie opinii.
W moim przekonaniu reguła jest dokładnie taka sama, jak w przypadku instalowania czegokolwiek z pomocą AUR: jeśli nie wiesz, nie jesteś świadomy tego co robisz - nie rób. Jeśli nie wiesz w jaki sposób budowane są programy w takim repozytorium - nie wprowadzaj go do systemu. Jeśli nie wiesz jakie konsekwencje niesie za sobą instalacja paczek z takiego repozytorium - nie jest ono dla Ciebie. I w końcu - jeśli nie znasz na tyle Archa, by dać sobie radę z ewentualnymi problemami aktualizacyjnymi w przyszłości - nie wprowadzaj takich repozytoriów do systemu. Tylko i wyłącznie wówczas możesz je dodać, gdy stwierdzisz, że przedstawione wyżej problemy nie są Ci obce, dasz sobie radę w przyszłości, możesz się pokusić o dodanie nieoficjalnych repozytoriów do systemu i korzystać z nich. Inaczej sam się prosisz o problemy, destabilizację, a być może nawet - zepsucie systemu. Nadto jeszcze - w przypadku instalacji paczek w wersjach nieoficjalnych musisz trzymać rękę na pulsie i wiedzieć kiedy pojawi się nowa, już stabilna wersja takiego programu i podjąć odpowiednie kroki. Dla przykładu, część oprogramowania występującego w ramach tzw. kde-applications daje się już budować na KF5 i nadaje się do codziennego używania. Niemniej jednak w oficjalnych wydaniach tego zbioru aplikacji nie występują one jeszcze w takich wersjach. To nowe oprogramowanie często - dla odróżnienia od wersji w repozytoriach - miewa (podobnie jak ma to miejsce w AUR) inne nazwy paczek (np. okular i okular-frameworks-git). Gdy wejdzie już stabilne oprogramowanie do repozytoriów, taka paczka może - i najczęściej tak się stanie - pozostać w wersji "starszej", niż paczka oficjalna (w przypadku omawianego tu oprogramowania KDE dzieje się tak zwykle dlatego, że paczki *-kf5/frameworks itp. są budowane z gałęzi noszącej taką nazwę, która w przypadku wydania oficjalnej wersji opartej o KF5 jest łączona z gałęzią master; dotychczasowa gałąź nadal istnieje, ale nie jest już aktualizowana, bowiem akutalizacji podlega wyłącznie gałąź master; prześledźcie sobie np. rozwój gwenview w GIT KDE).
Jeśli jednak mimo wszystko zdecydujesz się na dodanie nowego repozytorium, to musisz wiedzieć co robić, gdy system przestaje się aktualizować, zaczynają występować problemy z instalacją paczek w systemie itd. itp.
Przyjąć należy, że deweloperzy tak Archa, jak i Manjaro (i pozostałych forków) wiedzą co robią i przynajmniej starają się dbać o to, by aktualizacja systemu wykonywana w dowolnym momencie była możliwa. Podobnie ma być możliwość dodania w dowolnym momencie jakiegoś programu do systemu i nie ma prawa wystąpić sytuacja, w której występuje jakiś problem z zależnościami. Gdy zatem próba aktualizacji, bądź instalacji jakiegoś programu powoduje informacje o braku możliwości ich dokonania, to jest to znak, że prawdopodobnie nasz system nie jest w pełni kompatybilny z oficjalnymi repozytoriami. Przyczyny - co do zasady - mogą być dwie (wykluczam dla ułatwienia błąd po stronie deweloperów):
- albo w systemie mamy jakieś oprogramowanie, które nie jest już dalej wspierane przez Archa (tak np. było z chwilą porzucenia KDE4 i przejścia wyłącznie na Plasma 5; ktoś, kto ma jeszcze KDE4 będzie miał problem z aktualizacją systemu),
- albo problem jest wywołany przez paczki wprowadzone do systemu spoza oficjalnych repozytoriów (może to również dotyczyć paczek zbudowanych z AUR).
Pierwsza sytuacja nie jest przedmiotem niniejszego wpisu, niemniej jednak zawsze należy ją rozważyć i wykluczyć. Z pomocą winny przyjść informacje, jakie pojawiają się na głównej stronie Archa (i Manjaro, a także innych dystrybucji).
Jeśli wykluczymy pierwszy z możliwych problemów, przyczyną braku możliwości aktualizacji systemu (czy nawet dodania pojedynczej paczki) szukać musimy raczej w owych "obcych" paczkach. Najczęściej objawi się to wpisem, że pacman nie mógł dokonać aktualizacji (instalacji) albowiem napotkał problem z zależnościami lub, że nie mógł zainstalować jakiejś paczki, albowiem jakieś pliki istnieją już w systemie.
Jeśli instalowane obecnie paczki są również w repozytoriach nieoficjalnych, które podłączyliśmy do systemu, to najprawdopodobniej tu leży przyczyna. W pierwszej kolejności należy zatem zewidencjonować paczki, które są zainstalowane z takiego repozytorium nieoficjalnego. Pomocne okazać się może polecenie:
pacman -Sl nazwa_repozytorium
Po jego wydaniu pojawi się lista paczek w repozytorium, ich wersji oraz informacja, czy dana paczka jest zainstalowana w systemie. Jeśli pośród tych zainstalowanych paczek znajdziemy choćby jedną, która bądź to ma być zainstalowana obecnie, bądź to "należy" do grupy oprogramowania, które chcemy instalować, to sugerowałbym w pierwszej kolejności odinstalowanie wszystkich tych paczek. Nawet bowiem jeśli paczka z repozytorium oficjalnego będzie mieć dokładnie taką samą nazwę i taką samą wersję jak paczka z repozytorium nieoficjalnego, to może się ona różnić skryptem, który ją zbudował i istniejącymi w nim informacjami np. o zależnościach. Oczywiście można sobie zautomatyzować odinstalowanie takich paczek. Polecam jednak ręczne wpisanie listy tych paczek, które wymagają odinstalowania (dbajmy przy tym w pierwszej kolejności o odinstalowanie jakichś metapaczek, albowiem to one są bardzo często powodem problemów). Dlaczego "ręczne", a nie automatyczne? Bowiem - może mi się wydaje - ale mam nad tym procesem większą kontrolę. Łatwiej widzę i ogarniam co się w systemie dzieje. Automat jest fajny, pod jednym warunkiem - robi dokładnie to co zostało zaplanowane i dokładnie to i tylko to, czego od niego chcę i oczekuję. Osobiście słabo ufam nawet najlepszym automatyzacjom działań na paczkach.
Po odinstalowaniu paczek z repozytoriów nieoficjalnych (oczywiście tych kolidujących, uniemożliwiających aktualizację, czy instalację), należy usunąć (bądź zakomentować) takie repozytorium w /etc/pacman.conf i doknać synchronizacji repozytoriów oraz akutalizacji systemu. Przed aktualizacją (a po synchronizacji repozytoriów), warto jeszcze wykonać polecenie:
pacman -Qm
Da ono nam odpowiedź na pytanie jakie paczki mamy zainstalowane spoza repozytoriów (czyli wyświetli wszystkie te paczki, których nie ma w repozytoriach umieszczonych w /etc/pacman.conf, w tym także te instalowane z AUR). Takim paczkom również należy się przyglądnąć. Tu pomocne będzie polecenie:
pacman -Qi nazwa_paczki
W wyniku jego działania dowiemy się m.in. jakich zależności wymaga określona paczka. Pamiętajmy jednak, że w Archu wyświetlane są co do zasady wyłącznie te zależności, które są wymagane bezpośrednio przez tę paczkę (np. jesli jakaś paczka należąca do KDE wymaga jakiejś paczki z KF5, to nie zostaną już wyświetlone zależności owej paczki z KF5, jak np. należące do Qt5, choć te ostatnie są wymagane do prawidowego działania paczki poddanej inspekcji). W ten sposób niekiedy uda się również wyśledzić, co jest przyczyną braku możliwości aktualizacji systemu.
Powinno działać.
Czy stosować zatem, czy nie nieoficjalne repozytoria - pozostawiam Wam, łącznie z odpowiedzą na pytanie na ile to jest bezpieczne.

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.

niedziela, 4 września 2016

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 "czyste" Qt5. Jeśli ktoś jeszcze korzysta z jakiegoś środowiska opartego o Qt4 (nie jest mi znane), wówczas winien skorzystać z możliwości budowy programu na Qt4 (jeśli będzie taka potrzeba, to pomogę w PKGBUILDzie choć nie widzę większego sensu dalszego wspierania Qt4).
Teraz słów kilka o wersji Qt5. Owszem, program buduje się w takiej wersji. Niemniej jednak nie ze skryptu Setup-qt5.sh, który jest dostarczany wraz z programem. Ten skrypt wywołuje jedynie inny skrypt, a mianowicie Setup.qt4.sh, który jak się można domyślić, buduje wersję opartą o Qt4. Budowę trzeba zatem przeprowadzić przez cmake i włączyć opcję KS_PURE_QT. Niemniej jednak wymaga to jeszcze dopracowania przeze mnie. Szczerze, używając Plasma 5 nie mam potrzeby budowania aplikacji na "czystym" Qt5. Niemniej jednak, jeśli będzie zaintersowanie z Waszej strony, to dokończę skrypt również dla takiej wersji.

PS: Poprawiony PKGBUILD. Poprzedni nie uwzględniał extra-cmake-modules w makedepends.