Posty

FFMpeg2.8 jako zależność jakichś paczek po aktualizacji x265

Jeśli ktoś ostatnio aktualizował Archa, bądź ma to w zamiarze, a używa z jakichś powodów ffmpeg2.8 spotka się z komunikatem nierozwiązywalnych zależności: nie udało się rozwiązać zależności: instalacja x265(2.8-1) przerwanej zależność ‚li bx265.so=151-64’ wymaganych przez ffmpeg2.8 To nie jest akurat problem, bowiem usunięcie niewspieranej już przez Archa wersji ffmpeg (2.8 jest obecnie w AUR) umożliwi dalszą instalację. Problemem może stać się fakt, że niektóre aplikacje wymagają właśnie tej wersji jako swej zależności. Gorzej, gdy kod takich aplikacji jest zamknięty (np. 4KVideoDownloader) i w zasadzie nic już więcej zrobić nie można, jak pogodzić się z koniecznością pożegnania się z taką aplikacją. Czyżby? Może jednak nie w każdym przypadku. Wpierw spróbujmy zainstalować ffmpeg2.8, ale nie z repozytoriów binarnych (np. aur-archlinux), ale budując go w systemie: git clone https://aur.archlinux.org/ffmpeg2.8 && cd ffmpeg2.8 && makepkg -sirc (pamiętajmy o dodaniu ...

Przeczytano w sieci: umożliwiamy podmontowanie urządzenia z Androidem

Jeśli wciąż masz problemy z podmontowaniem jakiegokolwiek urządzenia z Androidem, to wydaj na prawach administratora następujące polecenie: sed 's/ACTION/ACTION!="bind", ACTION/' /usr/lib/udev/rules.d/69-libmtp.rules | sudo tee /etc/udev/rules.d/69-libmtp.rules > /dev/null Dopisze ono regułę o treści: ACTION!="bind", ACTION!="add" GOTO="libmtp_rules_end" w miejsce ACTION!="add" GOTO="libmtp_rules_end" znajdującej się w pliku /usr/lib/udev/rules.d/69-libmtp.rules . Od tej chwili, po ponownym podłączeniu urządzenia z Androidem nie powinno być już z nim problemów. Jeśli są (bądź dla pewności) możecie jeszcze wydać polecenie: udevadm control --reload-rules (oczywiście na prawach administratora), które przeładuje reguły dla udev. Trzeba jeszcze pamiętać o tym, że powyższy plik należy do paczki libmtp i sprawdzać jak się zachowa nasz system po jej aktualizacji. Całość znaleziona na reddicie .

Przeczytano w sieci: poprawiamy wygląd czcionek w SystemSettings

KDE Frameworks 5.45 wprowadziło dużo dobrych zmian. Okazuje się jednak, że jedna z nich skutkuje wadliwym wyglądem czcionek w Ustawieniach systemowych (a najprawdopodobniej też i innych, używających qqc2-desktop-style. Problem nie występuje zawsze i zależy od specyficznych ustawień określonych czcionek i ich wielkości. Okazuje się, że jest to pokłosiem commitu, który miał poprawić renderowanie czcionek . Istnieją różne sposoby na poprawę tego wyglądu, jednakże niekoniecznie przynoszą one efekty. Autor commitu zaleca tymczasowo dokonanie edycji pliku /usr/lib/qt/qml/QtQuick/Controls.2/org.kde.desktop/Label.qml , odnalezienie w nim linii zaczynającej się od renderType: i zakomentowanie jej, oraz dopisanie nowej o treści: renderType: Text.QtRendering . Ponowny start Ustawień systemowych winien odbyć się już bez problemów i to niezależnie od tego jak mamy ustawione czcionki w systemie.

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

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

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