czwartek, 15 marca 2018

Wiadomości z POLAUR - repozytorium debug

Powstało nowe repozytorium debug, w którym będziemy umieszczać PKGBUILDy umożliwiające budowę paczek z tzw. symbolami debugowania. Obecnie znajdują się tam PKGBUILDy paczek wchodzących w skład grup kf5, kf5-aids oraz plasma bez żadnych innych zmian w stosunku do oryginału w Arch z wyjątkiem dodania budowania owych symboli.
Zbudowane z tego repozytorium paczki umożliwią Wam lepsze zgłaszanie błędów czy to w bugzilli Archa, czy - jak na razie - w KDE.
Niebawem pewnie dodam również paczki przynajmniej głównych aplikacji składających się na grupę kde-applications. Być może znajdą się tam również paczki aplikacji budowanych w wersjach rozwojowych z innych naszych repozytoriów.
Paczki będą aktualizowane wraz z ich aktualizacją w repozytorium Archa.

Wiadomości z POLAUR - amarok-git. Koniec zasadniczych prac

Wczoraj sygnalizowałem stan prac nad amarok-git w POLAUR. Do wczoraj amarok-git był zubożony obsługę Mygpo-qt5. Wydaje się, że problem został rozwiązany i od dzisiaj amarok-git buduje się już prawidłowo z libmygpo-qt5. Ta ostatnia paczka nie wymaga już w żaden sposób qjson w dowolnej wersji (Qt4 jaką znajdziecie w repozytorium, czy Qt5, jaką znajdziecie u nas). Przy okazji prac nad amarok-git przebudowie uległ również qjson-qt5, który obecnie nie powinien w żaden sposób kolidować z wersją z repozytorium Archa, a jednocześnie powinien umożliwić budowę programów na nim opartych.

Mam zatem przyjemność oddać w Wasze ręce pierwszą - i jedyną obecnie - wersję amaroka wolną od Qt4 oraz kdelibs, a nawet od kdelibs4support. To "czysta" wersja budowana wyłącznie o biblioteki, które obecnie mają wsparcie. Jest też - nieskromnie pisząc - jedyną obecnie wersją opartą o prawidłowy zestaw zależności przez amarok-git wymaganych.

Oczywiście jest to wersja rozwojowa. Jeszcze nie ukazała się oficjalnie nawet beta amaroka funkcjonującego w oparciu o KF5. Część funkcji może tu nie działać w ogóle, bądź prawidłowo. Niemniej jednak po to ją zrobiłem, aby osoby, które chcą się w jakikolwiek sposób włączyć w prace nad tą wersją miały możliwość działania. Obecna wersja buduje się bez tzw. symboli debugowania i w przypadku konieczności zgłoszenia jakiegoś problemu na bugs.kde.org Wasze zgłoszenie będzie mało użyteczne. Przed zgłoszeniem warto zatem przebudować amarok-git z użyciem symboli debugujących. Jest to bardzo proste, można zbudować amaroka tak od razu, bądź - jeśli chcecie by taka wersja powstała - to zrobię ją z przyjemnością. Cała operacja polega na zmianie flagi Release na Debug w linii -DCMAKE_BUILD_TYPE= oraz dodać pole option=(debug !strip) gdzieś przed prepare.

Teraz już wyłącznie o instalacji i do zabawy.
Niemal wszystkie zależności niezbędne do zbudowania amarok-git są dostępne w repozytoriach Archa. Wyjątkiem jest libmygpo-qt5. W AUR znajdziecie paczkę libmygpo-qt5-git, która może posłużyć do budowy amarok-git pod warunkiem, że została zbudowane nie dalej niż 8.03.2018. Możecie również skorzystać z libmygpo-qt5 z naszego repozytorium, które jest w wersji 1.0.9 z dwiema łatkami koniecznymi do prawidłowego zbudowania amarok-git. Wybór rozwiązania należy do Was. Po zbudowaniu libmygpo-qt5 i zainstalowaniu go w systemie możecie przystąpić do budowy i wypróbowania amarok-git.

Raz jeszcze tylko uczulam - paczka zbudowana z POLAUR - póki co, będzie zastępowana przez niewłaściwie budowaną paczkę o takiej samej nazwie z AUR. Proszę zatem nie stosować wszelkich aurhelperów do aktualizacji paczek z AUR bowiem Wasz trud pójdzie na marne i dobra paczka zostanie zastąpiona złą.

wtorek, 13 marca 2018

Wiadomości z POLAUR - falkon-git

Podobnie jak w poprzednim poście. Po co utrzymywać w POLAUR falkon-git, skoro jest paczka o tej samej nazwie w AUR? Otóż - zgodnie z przyjętymi regułami POLAUR, będą tam te PKGBUILDy, które różnią się od tych, które występują w repozytorium Archa bądź w AUR. W tym przypadku różnica jest według mnie spora.
Otóż, AURowy PKGBUILD buduje paczkę z "czystego" GIT falkona. W naszym przypadku jest nieco inaczej.
Po pierwsze, doszedłem do wniosku, że osoby korzystające z falkona to przede wszystkim użytkownicy środowisk zbudowanych na Qt. W związku z tym postanowiłem, że "nasz" falkon będzie budowany bez wsparcia dla gnome-keyring, które niekiedy powoduje nieprzewidziane problemy w tego typu środowiskach. W naszym jest zatem wsparcie wyłącznie dla kwallet.
Po drugie - i ważniejsze - (choć wymagać to będzie jeszcze pewnych zmian) nasz falkon-git, w przeciwieństwie do AURowego budowany jest z tłumaczeniami.
Po trzecie - polska lokalizacja falkona została uzupełniona (proszę o ewentualne uwagi). Mam nadzieję, że obecnie spolszczone jest niemal 100% aplikacji - więcej, niż w wersji stabilnej.
Po czwarte - obecna wersja nie ma włączonych funkcji eksperymentalnych, czyli możliwości obsługi "nowych" wtyczek. Jak na razie ich nie ma, a budowa odpowiednich zależności jest mocno czasochłonna, nadto działa obecnie wyłącznie z Qt5.9.
Podobnie jak w przypadku amarok-git, ze względu na tę samą nazwę paczki, jaką nosi "oryginał" w AUR, aktualizację musicie wykonywać wyłącznie z użyciem naszego PKGBUILDu. Wszelkie aurhelpery spowodują zainstalowanie wersji z AUR.

Wiadomości z POLAUR - amarok-git

Kiedy powstawał nasz PKGBUILD dla aplikacji amarok w wersji budowanej bezpośrednio z GIT w AUR były dwie paczki: amarok-git oraz amarok-kf5-git. Obecnie jest już jedna - wyłącznie amarok-git.
Wprowadzając naszą wersję kierowałem się głównie tym, że ani jedna, ani druga paczka z AUR nie umożliwiała zbudowania aplikacji. U źródeł leżał fakt, że obie powstawały jeszcze, gdy amarok był aplikacją KDE4, choć w GIT posiadającą swoją własną gałęź kf5 budowaną już w oparciu o KDE Frameworks 5. W ten sposób istniał amarok-git budowany z gałęzi głównej (master) na podstawie bibliotek KDE4 oraz amarok-kf5-git, który budowany był na podstawie KF5 z gałęzi kf5. To wszystko stało się przeszłością z chwilą opublikowania ostatniego wydania amaroka budowanego na podstawie KDE4, czyli wersji 2.9. Wkrótce gałąź kf5 zastąpiła master. W ten sposób próba budowy amarok-git kończyła się niepowodzeniem ze względu na niespełnione zależności, a przy próbie budowy amarok-kf5-git uzyskiwaliśmy informację o braku źródeł.
Publikując zatem amarok-git w wersji POLAUR stwierdziłem, że stan to przejściowy, umożliwiający jedynie do czasu wyprostowania się sytuacji w AUR na budowę aktualnej wersji amaroka wprost z GIT w oparciu o KF5. W zamiarze było też usunięcie go jak tylko rozwiązanie tej sytuacji się pojawi.
W istocie - 3 dni temu z AUR zniknęło amarok-kf5-git, pozostało natomiast amarok-git budowane z obecnej gałęzi master, czyli z wykorzystaniem bibliotek KF5. Jak to określa changelog - nastąpiło połączenie amarok-git z amarok-kf5-git. Z POLAUR jednak amarok-git nie zniknął. Przynajmniej na razie.
Dlaczego?
Otóż przygotowany obecnie PKGBUILD obecnej wersji amarok-git w AUR jest moim zdaniem wadliwy. Autor obecnej wersji dokonał bowiem automatycznego przeniesienia zależności wymaganych do budowy starego amarok-kf5-git do obecnej wersji kompletnie nie zauważając, że zależności określone w CMakeLists.txt uległy zmianie w stosunku do czasów, kiedy budowało się amarok-kf5-git. Obecne zależności amarok-git z AUR są albo zbędne (np. kdelibs4support), albo nie zostały uwzględnione (np. kirigami2).
Postanowiłem zatem, że do czasu poprawienia PKGBUILDu w POLAUR będzie funkcjonowała nasza wersja. Nie bardzo chciałbym wprowadzać dla niej jakąś inną nazwę - wszak amarok-git jest nazwą prawidłową, zgodną z zasadami Arch Linux. Jeśli zatem jej nie zmienię, to uczulam, że decydując się na budowę z naszego PKGBUILDu (nota bene ulegnie on pewnej przebudowie w niedalekim czasie) musicie konsekwentnie go stosować i jednocześnie nie używać różnego rodzaju aurhelperów do aktualizacji paczek z AUR lub samego amarok-git, albowiem w ten sposób dostaniecie paczkę wprawdzie prawdopodobnie prawidłową, jednakże ze złymi zależnościami, co w efekcie prowadzić może to przypadkowego usunięcia którejś z zależności, a w efekcie program przestanie działać. Zbudowany natomiast zostanie wyłącznie dlatego, że umożliwi to wcześniejsza budowa naszej paczki.

niedziela, 11 marca 2018

Jak nie instalować programów ze źródeł

To krótka przypowieść, jaka naszła mnie po lekturze dwu poradników o instalacji w Manjaro GIMPa oraz LibreOffice ze źródeł. Teksty są bliźniacze, a ich główną tezę można sprowadzić do stwierdzenia: zbudować program i zainstalować poprzez sudo make install. Skoro jest głupia porada, to wymaga jakiejś riposty.
Pominę sens budowania programów, które są w repozytoriach, zwłaszcza, że autor nie zaciekawił się opcjami kompilacji, które najczęściej w ogóle przemawiają za podjęciem tego trudu. Pominę też rozważania, czy istotnie dla systemu dobrym jest dostosowanie pod określony procesor zaledwie jednego, czy dwu programów, a nie całego systemu. Można mieć na ten temat bardzo różne zdania, a chętnych odsyłam do wiedzy tych, którzy na kompilacji zęby zjedli, czyli kolegów od Gentoo.
Interesuje mnie zgoła co innego.
Zastanówmy się wpierw nad owym magicznym sudo make install (oczywiście, o ile autor kodu dostarczył ich reguły, co regułą nie jest). Przed jego wydaniem, program zasadniczo został już skompilowany. W katalogu, w którym dokonywaliśmy budowy programu istnieją już stosowne binarki (i ewentualnie inne jego, niebinarne nawet, elementy). Wydając powyższe polecenie instruujemy make by dokonało ich instalacji w systemie. Binarki te lądują w miejscach określonych skryptem budującym program. Niemal zawsze (i stąd wymagane jest owe sudo) przekopiowanie ich odbywa się do katalogów zastrzeżonych dla administratora systemu. W tych samych katalogach instalowane są również paczki wprowadzane do systemu za pośrednictwem menedżera pakietów. Jaki zatem problem skoro wszystko odbywa się zgodnie z regułami sztuki?
Problemów wcale nie mało. Wymienię w punktach, by oszczędzić Waszego czasu.
Po pierwsze - w systemach, w których istnieje menedżer pakietów, za ich instalację, przechowywanie informacji o zainstalowanych pakietach, lokalizacji poszczególnych elementów składających się na taką paczkę oraz wielu jeszcze innych aspektach - służy i wyłącznie ten menedżer pakietów. I aż się prosi o stwierdzenie: koniec kropka.
Po drugie - budowa i instalacja w sposób klasyczny (czyli opisany przez autora) - w żaden sposób nie przekazuje menedżerowi pakietów informacji o zainstalowaniu takiej aplikacji. Instalując w klasyczny sposób aplikacje, umieszczamy w katalogach na nie przeznaczonych różne pliki, które mogą kolidować z jakimiś paczkami instalowanym przez menedżera pakietów. Próba instalacji takiej paczki (a także innych instalowanych wraz z nią) nie powiedzie się, albowiem pacman wykryje, że w systemie plików znajduje się już plik o takiej samej nazwie. Na nic się w tym momencie zda próba jego wykorzystania do identyfikacji do jakiego pakietu należy dany plik (pacman -O plik). Ta skończy się podaniem prawidłowej z punktu widzenia pacmana informacji, że plik ten nie należy do żadnego pakietu, ale nie oznacza to, że ów plik nie należy do żadnej aplikacji. W tym momencie dokonanie niemal dowolnej operacji dla uzdrowienia tej sytuacji może skończyć się spektakularnym błędem. Wystarczy? Dla mnie tak.
Po trzecie - o ile pacman dokonując instalacji paczek sprawdza właśnie powyższą sytuację i w przypadku wykrycia istniejącego już w systemie pliku uniemożliwia dalszą instalację i daje czas na ochłonięcie administratorowi i zidentyfikowanie błędu oraz rozwiązanie problemu, to instalacja poprzez sudo make install nie zauważy takiego problemu. Wszak administrator systemu nakazał mu zainstalowanie w konkretnej lokalizacji konkretnego pliku. Jeśli w systemie będzie już istniał taki sam plik, jednakże dostarczany przez inną paczkę, to ów plik zostanie nadpisany nowym. Mam dalej pisać co może to spowodować? Wystarczy?
Po czwarte - kompilując i instalując paczki w sposób podany przez autora, zdajemy się na to, co autor danego rozwiązania przewidział w plikach konfigurujących kompilację. Tak stworzona aplikacja może się różnić lokalizacją poszczególnych plików składających się na daną aplikację od systemu przyjętego w Archu (a w ślad za nim w Manjaro). Taka aplikacja może, ale nie musi działać prawidłowo. Nieprawidłowo natomiast będzie wyglądała ona z punktu widzenia struktury i hierarchii katalogów w Archu.

I tyle, bo nie chce mi się więcej rozpisywać na temat dlaczego oba poradniki są typowym przykładem dezinformacji, z których skorzystanie może zrobić więcej szkody niż pożytku. Na koniec tylko jedna kwestia. Bowiem skoro nie tak, jak autor wskazał, to jak?
Otóż jedynym poprawnym sposobem instalacji programów ze źródeł w Archu (ale tak na prawdę, to w dowolnej dystrybucji) jest stworzenie odpowiedniej paczki rozpoznawanej przez menedżer pakietów i zainstalowanie jej w systemie za jego pomocą. W przypadku Archa (i pochodnych) wykorzystujemy w tym celu PKGBUILD. Możemy go stworzyć we własnym zakresie, możemy skorzystać z istniejącego rozwiązania (wszak oba programy wskazane przez autora dostępne są w repozytoriach i mają swoje PKGBUILDy), jeśli nie wiemy jak tego dokonać samemu, mamy też co najmniej kilka możliwości z jakich możemy skorzystać (AUR, BBS Archa, nasze forum).

I nie byłbym sobą, gdybym nie napisał: kochani autorzy skończmy z dezinformacją. Skończmy z podawaniem błędnych rozwiązań. Nawet jeśli jakieś rozwiązanie działa, to nie oznacza, że jest ono prawidłowe. Umieszczajmy rozwiązania wyłącznie takie, co do których jesteśmy w 100% przekonani, że są one prawidłowe i - przede wszystkim, że - nikomu proponowane przez nas rozwiązanie nie zaszkodzi.

wtorek, 6 marca 2018

Kanał IRC dla społeczności POLAUR

Od dzisiaj został uruchomiony kanał IRC #polaur na freenode.net. Kanał służyć ma kontaktom we wszelkich kwestiach związanych z naszym repozytorium POLAUR. To jeszcze jedno miejsce, gdzie możecie mieć z nami kontakt. Tutaj możemy przedyskutować tak prawidłowość naszych PKGBUILDów, działania paczek na nich zbudowanych, jak i nawet tego typu kwestie jak związane z planowanym utworzeniem repozytorium paczek, czy wyborem programów, jakie chcielibyśmy wziąć w naszą opiekę.

niedziela, 4 marca 2018

KDE Frameworks 5.44RC - dla testerów

Bez szumnych zapowiedzi, albowiem w przypadku KF5 tak to już nie funkcjonuje. W pierwszą sobotę miesiąca biblioteki składające się na KDE Frameworks 5 otrzymują tag release candidate. Od czasu, kiedy mamy platformę dzielenia się z Wami paczkami (tj. PKGBUILDami, na paczki może przyjdzie czas), postanowiliśmy chętnym do testowania nadchodzącego oprogramowania oferować także możliwość wypróbowania kolejnych wersji RC KF5. Od wczoraj zatem w naszym repozytorium jest również dostępny zbiór PKGBUILDów umożliwiający skompilowanie KF5.44RC Osoby, które chciałyby się włączyć do testowania nadchodzących frameworków - zapraszamy szczerze. Używam od wczoraj i nie bardzo jestem w stanie zauważyć jakichś problemów. Siła open source tkwi jednak m.in. w nas, którzy mogą twórcom tego oprogramowania pomóc także w ten sposób, że zanim ukaże się wersja "stabilna" zostanie ona przetestowana na większej ilości sprzętu niż dostępny dla nich. Kilka uwag. Jeśli ktoś zdecydowałby się na testy, to proszę zaznajomić się z dwoma plikami tekstowymi. Jeden wyświetla się pod repozytorium i głosi konieczność przebudowania kimageformats w momencie, gdy system zostanie zaktualizowany do paczki openexr 2.2.1 (obecnie jest w staging i czeka na przebudowę innych jeszcze paczek). Drugi plik, może ważniejszy to how2build.txt, który próbuje wskazać kolejność budowania paczek KF5. Ta kolejność ma znaczenie! Paczki budowane w innej kolejności albo nie zbudują się wcale, albo nie będą działać tak, jak to zaprogramowali twórcy. Z uwagi na to, że głównie ja jestem twórcą i opiekunem tych PKGBUILDów, wszelkie uwagi proszę w dowolnej formie zgłaszać mi. Możliwości sporo: zgłoszenia issues lub pull requests, nasze forum, czy nawet system komentarzy pod tym wpisem. W przeciwieństwie do repozytorium repo-refreshed PKGBUILDy znajdujące się w tym repozytorium nie będą dostawać żadnych poprawek, które nie są przeznaczone dla nadchodzącego wydania KF5.44. Proszę też śledzić wątek na naszym forum, albowiem tutaj będę sygnalizował wszelkie zmiany, jakie w KF5.44RC będzie należy dokonać. Jednocześnie chciałbym zapowiedzieć, że taki sam mechanizm zaproponujemy Wam dokładnie za miesiąc, a potem w kolejnych miesiącach. W kwietniu zatem będziecie się mogli spodziewać KF5.45RC, w maju (uwaga - ważne wydanie, albowiem na nim oparte będzie Plasma 5.13, a nie wiem, czy nie udostępnię jakiejś wczesnej wersji) KF5.46RC itd.