Posty

Wyświetlanie postów z 2018

Firefox 64 i okna KDE

Użytkownicy KDE od dosyć dawna narzekają na to, że aplikacje oparte o Gtk mają własne okna dialogowe. Mniejsza o to, które są "lepsze", a które "gorsze". To kwestia pewnych przyzwyczajeń. Jeśli 99% aplikacji zachowuje się w określony sposób, to ciężko przestawia się na inne zachowanie pozostałego procenta aplikacji. Zwłaszcza, że są to często wykonywane operacje, które "wchodzą" użytkownikowi w krew. Śpieszę zatem donieść, że przynajmniej Firefox w wersji 64 da się zmusić do używania natywnych okien KDE przy otwieraniu plików, czy też zapisywaniu pobieranych przez tę przeglądarkę treści. Ponoć prezentowana tu sztuczka działa również z niektórymi programami. Ponoć również, niektórym nie działa w ogóle (tu mam jednak wątpliwości, czy zostały spełnione wszystkie elementy, które umożliwiają takie zachowanie Firefox w Plasma). Wpierw musimy odpowiednio przygotować nasz system, w którym muszą być zainstalowane następujące paczki: firefox >=64.0 xdg-des

POLAUR - paczki KDE z łatkami

Od dłuższego czasu w POLAUR, w repozytorium repo-refreshed umieszczam PKGBUILDy dla różnych składników oprogramowania pochodzącego od KDE z tzw. bugfiksami. W największej części są to te, które były zgłaszane w  bugs.kde.org . Stosowane są przeze mnie (i jeśli ktoś chciałby również się dołączyć, to również prosiłbym o ich stosowanie) następujące zasady: 1. Numeracja paczek a. Paczki zawsze mają numer wersji (pkgver) takie jak paczka źródłowa, na którą patch jest nakładany. b. Paczki różnią się wersją "realizacji" (pkgrel), przy czym numer ten jest zawsze wyższy niż wersja w repozytorium, ale zawsze też niższy od wersji, która w repozytorium może się pojawić (np. wskutek koniecznego jej przebudowania ze względu na zmiany innych elementów, tego wymagających). Kolejne wersje z patchami mają zawsze nowy numer pkgrel z zachowaniem powyższej zasady. Przykład: jeśli paczka w repozytorium Archa ma numer np. 5.53.0-1, to pierwszy PKGBUILD z patchem będzie miał wersję 5.53.0-1.1,

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl . Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu  gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia. Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma. Inny forumowicz poleca zatem... dodanie repozytorium nexus  do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify. Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wnios

A jak alias

Wielu użytkowników linuksa narzeka na straszliwą konieczność pracy w konsoli. Na to, że wszystko tu trzeba wpisywać itd. itp. i bez tego ani rusz, a polecenia konsolowe to katorga dla "normalnego" człowieka. I kto by spamiętał to wszystko. Pomijam prawdziwość twierdzenia o konieczności wpisywania wszystkiego w konsoli. Obecne środowiska graficzne i programy dla nich, oferują spore możliwości praktycznie kompletnego pominięcia używania poleceń konsolowych. Niemniej jednak z różnych przyczyn może okazać się, że korzystanie z konsoli dla określonych zastosowań jest albo jedyną możliwością, albo po prostu bywa wygodniejsze. Niemniej jednak sam zauważam, że niektóre polecenia są zbyt długie, by je spamiętać. Ot, choćby: # reflector --verbose --country 'Poland' -l 5 -p http --sort rate --save /etc/pacman.d/mirrorlist Oszczędźmy naszą pamięć. Z pomocą przychodzi nam "alias", dzięki któremu w swoim środowisku możemy przyporządkować w zasadzie dowolne ciągi zna

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy? 1. Synchronizacja repozytoriów dla zabawy Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy , a za jakiś czas instalować program poprzez pacman -S ? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi. Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium. Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje

Jak uniknąć problemów z Antergosem

Przyglądając się problemom, jakie dostarcza Antergos wielu użytkownikom od kilku lat, spróbuję zestawić w punktach kilka porad, które zminimalizują najczęściej występujące z nim kłopoty. 1. Usunięcie plików *-meta. Niemal wszystkie instalacje (pierwsze) Antergosa odbywają się z użyciem tzw. meta paczek. To jeden ze sposobów instalacji zespołu większej ilości programów w Archu. Meta paczki nie zawierają żadnych binarek. Są to jedynie paczki niosące informacje o tym, że jakieś paczki mają zostać w systemie zainstalowane. Treść PKGBUILDów takich paczek zawiera w polu depends listę paczek do zainstalowania. Taka instalacja powoduje, że późniejsza próba odinstalowania jednej z paczek umieszczonych w depends pociągnąć za sobą może chęć odinstalowania "połowy" systemu, albo spotkamy się z informacją o tym, że odinstalowanie czegoś nie jest możliwe. Rozwiązanie Po zainstalowaniu Antergosa, przeszukujemy system pod kątem zainstalowanych paczek z "meta" w nazwie. Ich nazwy wy

Przyciski OK i Anuluj aplikacji Gtk jak w Qt

Przyciski potwierdzenia lub wycofania się z jakiejś operacji (OK/Anuluj) w oknach dialogowych aplikacji zbudowanych w oparciu o Gtk są zamienione miejscami w stosunku do standardowych okien w środowiskach korzystających z Qt. Oprócz pewnego dyskomfortu, kwestii estetyki, przede wszystkim skutkuje to gorszą organizacją pracy. Na całe szczęście można to w prosty sposób zmienić. Jeśli korzystamy z aplikacji zbudowanych na Gtk+2.x musimy dokonać edycji pliku ~/.gtkrc-2.0 , jeśli korzystamy z aplikacji zbudowanych na Gtk+3.x edytujemy plik ~/.config/gtk-3.0/settings.ini , w obu przypadkach dodając linię: gtk-alternative-button-order = 1 . To powinno wystarczyć, by we wszystkich aplikacjach wykorzystywanych w środowiskach zbudowanych na Qt (np. Plasma, LXQt, Lumina) miejsca przycisków OK oraz Anuluj były w tych samych miejscach. Na podstawie porady z BBS Arch Linux .

Są manadynki i są truskawki - Strawberry

Znany i lubiany odtwarzacz Clementine utknął od dwu lat na wersji 1.3.1, która sama w sobie nie jest zła, ale w dalszym ciągu oparta jest o Qt4. Wprawdzie rozwój nowej wersji na Qt5 trwa już dłuższy czas i jest ona raczej bezproblemowo używalna, to jednakże i tu niewiele się dzieje ostatnio, by przybliżyć wersję opartą o nowszy framework. Dla tych, którzy chcą się pozbyć w końcu Qt4 ze swoich systemów istnieje zatem opcja w postaci instalacji clementine-qt5-git  (wraz z kilkoma odmianami, które już niekoniecznie są do znalezienia w AUR), albo... Od jakiegoś czasu współpracujący z projektem Clementine Player, Jonas Kvinge rozpoczął prace nad forkiem tej aplikacji, która od początku powstaje w oparciu o Qt5 - jest nią Strawberry . I choć napisałem, że "truskawka", to jednak autor odwołuje się do inspiracji nazwą zespołu The Strawbs  (mam nadzieję, że o ten zespół mu chodzi, a nie o inny, o takiej samej nazwie). Mamy zatem nowy, o niewielkich wymaganiach odtwarzacz Strawberr

LibreOffice 6.1

Z różnych powodów nowe wydanie chyba najpopularniejszego pakietu biurowego open source jest ważne. W wielu miejscach, nawet w popularnych serwisach, które nie zajmują się tematyką komputerową na co dzień, zostało to opisane. Czuję się zatem zwolniony z obowiązku opisywania tego po raz kolejny. Chętnych do zapoznania się ze zmianami odsyłam do ich listy . Pozwalam sobie napisać o tej nowej wersji jednakże z innego powodu i z punktu widzenia osoby używającej Plasma 5 jako podstawowego środowiska graficznego w moim systemie. Otóż w końcu zaimplementowana została obsługa wtyczki VCL, która uwzględnia i współpracuje z Qt5. W przypadku wykrycia przez LO, że uruchomienie następuje w tym środowisku ładowana jest wtyczka gtk3_kde5, która oferuje pewien zakres wsparcia dla zintegrowania się pakietu w Plasma 5. Podstawowym VCL pozostaje gtk3 i na nim owa wtyczka jest oparta. Z częścią konsekwencji z niej wynikających. Otóż dzięki działaniu wtyczki, LO uzyskuje natywny dostęp do okien dialogowych

POLAUR teraz dzięki polaur

Dzięki pracy naszego forumowicza nycko123 nasze repozytorium dorobiło się prostego narzędzia umożliwiającego podstawowe nim zarządzanie. Narzędzie nazywa się... a jakże inaczej... polaur i dostępne jest w naszym repozytorium . Tutaj znajduje się plik PKBGBUILD umożliwiający budowę paczki. Samo narzędzie to zaledwie jeden plik skryptu powłoki. Dzięki jego działaniu możliwe jest: - zapoznanie się z dostępnymi repozytoriami, - przeglądanie ich zawartości, - pobieranie wybranych źródeł paczek. Pobrane źródła znajdziecie w ~/.cache/polaur/nazwa_repozytorium/nazwa_paczki. I w zasadzie tyle, bowiem w przeciwnym razie tekst byłby dłuższy od skryptu.

Cudze chwalicie, swego nie znacie - pak

Dzięki pracy naszego forumowicza nycko123 powstała (bo już jest) i powstaje (bo będzie lepsza) swego rodzaju nakładka na pacmana (a także asp) stanowiąca jednocześnie podstawowy tzw. AURhelper. Po co kolejna, skoro już tyle ich jest? O to spytajcie autora, jednakże ze swej strony mogę wyliczyć jej niewątpliwe zalety. Przede wszystkim jest to skrypt w czystym języku powłoki. Zaledwie jeden plik wykonywalny, jeden konfiguracyjny oraz spolszczenie. W porównaniu z wieloma innymi tego typu narzędziami nie wymaga on zatem instalacji w systemie dużej ilości zależności. Tam, gdzie to możliwe, posługuje się systemowymi narzędziami. W zakresie, w jakim stanowi on menedżer paczek wykorzystuje po prostu pacmana. Z całą jego składnią. Jednocześnie składnię tę rozszerza. Instalując bowiem opcjonalną zależność asp, umożliwia również proste ściągnięcie źródeł paczek z repozytoriów. Oficjalnych na pewno. Jeśli chodzi o nieoficjalne - tu gorzej, albowiem najczęściej tych źródeł po prostu nie ma, a jeś

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 ź

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 GIMP a 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 z

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

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 p

POLAUR - POL Arch User Repository

Miło mi poinformować, że od wczoraj zostało udostępnione repozytorium Polskiej społeczności Archa . Wespół z kolegami, będziemy tam oferować PKGBUILDy, które z jakichś powodów nie chcemy (choćby tymczasowo) umieszczać w AUR. Być może część z nich, kiedyś, zostanie udostępnione w AUR, ale część na pewno się nigdy tam nie znajdzie. Do korzystania z repozytorium nie zachęcamy, ale oddajemy je Wam. Możecie budować paczki, które są w poszczególnych repozytoriach. Zostały one przez nas zbudowane, zainstalowane i uruchomione. Każda z paczek przeszła proces walidacji co najmniej narzędziem namcap . Niemniej jednak, zwłaszcza paczki znajdujące się w dwu repozytoriach proszę traktować jako wysoce eksperymentalne i ich użytkowanie odradzam wszystkim, którzy nie czują się na siłach przynajmniej do przywrócenia systemu do stanu sprzed ewentualnej awarii i poznali tak elementarne czynności, jak uruchomienie systemu w konsoli, gdy nie podnosi się środowisko graficzne, nawiązanie połączenia sieciowe

Kameleonowe katalogi Breeze

Ot, taki sobie mały "ficzer". Przynajmniej część z nas ma "wysublimowany" gust estetyczny. Najczęściej objawia się to w tym, że nic takiej osobie nie pasuje w gotowych zestawach. To, kolor nie taki, to nie takie ikony. Zaczynamy szukać lub zmieniać we własnym zakresie. Na końcu prawie już ucieszeni swoim dziełem znów dochodzimy, że coś jest nie tak. Tym razem podobają nam się domyślne ikony Breeze w KDE. Ich wygląd nam się podoba. I kompletność. Zmieniwszy jednak schemat kolorystyczny Bryzy nie jesteśmy zachwyceni kolorami jakie przyjmują ikony katalogów. No gryzie się :) Wprawdzie można to żmudnie dostosować dzięki pewnym narzędziom, które w Plasmę zostały wbudowane. Jest jednak rozwiązanie prostrze. Otóż Andreas Kainz (o ile wiem, jeden z współtwórców zespołu VDG , albo osoba z nimi jakoś związana) stosunkowo niedawno udostępnił "odpad z produkcji" jakim jest Breeze Raibow Folders . Jak na razie nie jest planowane, by znalazł się on ponownie w master, a

qStopMotion wersja Qt5

Niedawno pojawiło się nowe wydanie - wersja 2.4.0 - programu do przechwytywania zdjęć z kamer podłączonych do komputera (stopklatka) - qStopMotion . Nie wiem jak poprzednie, ale tę wersję można zbudować również w oparciu o Qt5. Nie wiem również z jakich powodów w AUR jest wersja budująca się jeszcze na Qt4. Ze względu na to, że nic nie stoi na przeszkodzie budowie programu opartego o nowszą wersję, a Qt4 odchodzi już powoli od nas, postanowiłem zrobić PKGBUILD właśnie dla programu w takiej wersji. Kilka uwag o tym PKGBUILDzie. Dla rozróżnienia wersji, proponowana przeze mnie paczka nazywana jest qstopmotion-qt5. Program zbudowany z mojego zastępuje wersję z AUR i jednocześnie dostarcza ten program (nie jest możliwa koegzystencja obu wersji). Program jest budowany z użyciem qt5-multimedia, stąd nie zawiera dwu sugerowanych zależności: gstreamer oraz ffmpeg - gdyby się z jakichś przyczyn okazało, że program nie działa w pełni funkcjonalnie, prawidłowo, to proszę zbudować ją wpierw z

LibreOffice 6.0 a natywna wtyczka Qt5

Sporo zamieszania się zrobiło z nowym wydaniem LibreOffice 6.0 oraz istnieniu w tym wydaniu natywnej wtyczki Qt5, która polepszyłaby integrację tego pakietu w środowiskach opartych o ten framework. Dość, że pojawiły się nawet fake newsy o tym, że: " Użytkownicy KDE/Plazmy będą zadowoleni z nowej wtyczki dla Visual Components Library, która łączy się z biblioteką Qt5 i zapewnia pełne wsparcie dla funkcji tej biblioteki w LibreOffice, w tym obsługi wskaźnika myszy, kursorów i okien dialogowych ". Przyznam, że nie wiem, gdzie autor tego tekstu widział ową wtyczkę, jak również skąd wziął informację, a tym bardziej, że zapewnia pełne wsparcie dla Qt 5 w LibreOffice 6.0. Dość powiedzieć, że obie oficjalnie paczkowane przez Document Foundation wersje LO6.0 (rpm oraz deb) nie są kompilowane z tą wtyczką. Nie zawiera ich też żadna z przeglądniętych przeze mnie paczek w dystrybucjach, które tę wersję już udostępniły (Arch, OpenSUSE Tumbleweed, czy nawet KaOS). Jedyna zapowiedź jaką zna

Transmission pozbawiony błędu CVE-2018-5702

Sieć przeszła informacja o dziurze w programie. Ba, nawet została okraszona informacją, że wstrętni twórcy tej aplikacji nie robią nic, a problem poważny, dotyczy bezpieczeństwa. Jak się okazuje problem został załatany . Fakt, w Archu (a zatem i w dystrybucjach pokrewnych) jeszcze nie ma nowej paczki z uwzględnieniem tego patcha. Problem został zgłoszony dzisiaj (17.01.2018), a zatem pewnie już niebawem zostanie poprawiony. Niemniej jednak używający transmission mogą się poczuć zaniepokojeni. Dla nich przygotowałem PKGBUILD, zbudowany w oparciu o tzw. nightly builds , które uwzględniają poprawkę bezpieczeństwa. PKGBUILD jest jedynie przebudowanym z oficjalnego repozytorium. Zmiany są następujące: - paczka źródłowa, na podstawie której budowana jest paczka dla Archa to "nighthly builds" (dokładnie uwzględniająca commit reb5d1a79cb , - usunięte zostały patche, które zostały nałożone w "nightly builds". Innych zmian nie dokonywałem.

Plasma 5.12 LTS Beta udostępniona

Z około dwutygodniowym opóźnieniem ukazała się wczoraj wersja Beta nowej odsłony środowiska graficznego Plasma. Oznaczona numerem 5.12 (w przypadku bety to 5.11.95) jest drugim wydaniem o przedłużonym wsparciu (18 miesięcy, o ile pamiętam). Oczekujący jakichś niesamowitych nowości muszą się poczuć zawiedzeni (choć nikt ich nie zapowiadał). Nowa Plasma nie jest bowiem niczym innym, jak po prostu kolejnym wydaniem poprawkowym dla całej serii Plasma 5. Usunięto część błędów, jakie pojawiały się w poprzednich wydaniach. Z rzeczy istotniejszych (bowiem owe błędy można naprawić nawet we własnym zakresie) wg zapowiedzi Plasma ma teraz jeszcze mniejszy apetyt na zasoby komputera. Jest to również pierwsze wydanie, gdzie możliwość pracy w sesji Wayland osiągnęło również status LTS. W tym ostatnim przypadku kilka informacji. Osoby, które używają kart graficznych NVidia nie uruchomią sesji Plasmy w Wayland na sterownikach zamkniętych. Część programów (choć to nie jest kwestia samego środowiska g