Posty

Wyświetlanie postów z 2017

Małe a cieszy: uksmstat

Kiedyś ten programik był w AUR. Obecnie go już nie ma. Jest użyteczny wyłącznie dla osób, które mają kernele z UKSM . Do takich należą np. linux-uksm czy linux-pf oraz... mój własny. Znów zatem krótko: PKGBUILD (tym razem to nie mój wynalazek, a oryginalny PKGBUILD, który niegdyś znajdował się w AUR) i wszystko jasne.

Małe a cieszy: swapusage

Postanowiłem prezentować małe, użyteczne narzędzia. Sporo takich znajdziecie w repozytoriach, czy w AUR, w tym cyklu skupię się jednak na tych, których tam nie ma i będę dawać do nich PKGBUILDy. Na pierwszy ogień - swapusage . Nazwa mówi wszystko. Programik, który sprawdzi co siedzi w swap i ile go zużywa, a nadto przekaże nam informację o numerze procesu takiej aplikacji. Proste? Banalnie. Zatem już wyłącznie PKGBUILD i możecie używać. Jeśli nie wiecie jednak co dalej z taką wiedzą robić - również proste: nie używać, chyba, że wyłącznie po to, by wiedzieć. PS: Co robić z PKGBUILDami, które tu prezentuję również już nie piszę. Pisałem wiele razy jak należy w takich przypadkach tworzyć i instalować paczkę.

Naprawiamy błąd w KDE

KDE jest jedynie przykładem. Podany poniżej sposób można dostosować do dowolnego programu. Trzeba mieć jedynie źródła i odrobinę chęci. Niemniej jednak ostrzegam: PROPONOWANE ROZWIĄZANIE JEST PRZEZNACZONE WYŁĄCZNIE DLA ŚWIADOMYCH UŻYTKOWNIKÓW . Pozostałym proponuję skorzystać z oferowanej przez nas pomocy na forum . Truizmem jest stwierdzenie, że nie istnieje oprogramowanie pozbawione wad. Zawsze znajdzie się jakiś błąd. W przypadku Archa i KDE mamy komfortową sytuację, albowiem opiekunowie paczek napiętnowanych przez Qt są po prostu bardzo dobrzy. Oczywiście zdarzają się wpadki, jednakże są one często i to na poziomie testowania (repozytoria testing i kde-unstable) wychwytywane i naprawiane. Jeśli zatem chodzi o samą jakość paczek to jest tu po prostu przednio. Niemniej jednak urodą Archa jest to, że dostarcza on zasadniczo oprogramowanie najnowsze i to w miarę możliwości takie, jakim go widzi tzw. upstream. Przyjęcie tej zasady oznacza, że mniejsze lub większe błędy zostaną dostarczo

Zrozumieć niezrozumiałe: instalacja programów w wersjach rozwojowych (git)

W AUR sporo jest skryptów umożliwiających budowę paczek w wersjach rozwojowych. Zwykle noszą one dodatkowe oznaczenia dev/devel, git, bzr, svn, cvs, hg itp. Odróżnijmy wpierw paczki *-dev/devel. Z takim rozszerzeniem winny pojawiać się takie wersje rozwojowe programów, które są w jakiś sposób "ustabilizowane" przez twórców. Innymi słowy - "numerowane" wersje rozwojowe. Przykładem takim niech będzie GIMP, który stosuje bardzo stary system oznaczania swoich wersji, gdzie pierwsza cyfra oznacza wersję, druga cyfra wskazuje na wydanie, a trzecia wskazuje na wersję poprawkową. Dodatkowo jeszcze wydania uważane za deweloperów za stabilne oznaczane są kolejną parzystą liczbą, zaś wydania rozwojowe, które prowadzą do następnych wydań stabilnych oznaczane są liczbą nieparzystą. Stąd GIMP 2.8.22, to ostatnia wersja stabilna (8) drugiego (2) wydania GIMPa, będąca dwudziestą drugą wersją poprawkową dla wydania 2.8. Niedawno ogłoszona wersja 2.9.8 jest rozwojową (9) wersją, któr

Zbuduj sobie LibreOffice AppImage

Oczywiście w repozytorium Archa są nawet dwie wersje LibreOffice (still i fresh). Są jeszcze różne wersje w AUR. Z różnych względów jednakże możemy chcieć mieć inną wersję niż ta, którą zainstalować możemy z repozytorium. Także taką, która będzie z nią koegzystować i nie naruszy nam naszego "produkcyjnego" pakietu. Oczywiście możliwą jest taka instalacja w przypadku wersji z repozytorium oraz niektórych z AUR. Możliwym jest też odpowiednie dostosowanie PKGBUILDów do swoich potrzeb. Proponuję jednakże inne, szybkie rozwiązanie, które umożliwi Wam na przykład testowanie przyszłych wersji, ewentualne włączenie się w rozwój tego pakietu czy też do jakichkolwiek innych celów będziecie chcieć to wykorzystać. Owe rozwiązanie to AppImage. Przede wszystkim muszę zaznaczyć, że w ogóle nic nie musicie robić. AppImage kilku wersji LO jest oferowane przez LibreOffice AppImage Package - wystarczy ściągnąć odpowiedni dla siebie plik, nadać mu uprawnienia wykonywalne i ma działać. Niemnie

Przywracamy działanie gimagereader-qt5 na enchant 2

Niezbyt wiele mamy aplikacji stanowiących GUI dla silników OCR w linuksie, zatem każdą z nich należy pielęgnować. W świecie oprogramowania opartego o Qt 5, spośród stale rozwijanych w zasadzie istnieje jedynie gImageReader. W AUR znajdziemy dwa PKGBUILDy: gimagereader oparty jeszcze o Qt 4 oraz gimagereader-qt5 oparty o Qt 5. Pierwszym nie będę się zajmować. Najwyższy czas, by dawno już porzucone Qt 4 odeszło w mroki dziejów. Niestety po psikusie, jakim było wprowadzenie enchant w wersji 2 do repozytorium (extra), aplikacja ta przestaje działać. Pominąwszy pewne perturbacje, jakie były w międzyczasie, dzisiaj już udaje się przywrócić możliwość działania gImageReaderowi. Niestety nie podam Wam co i jak należy zmienić w istniejących PKGBUILDach w AUR. Jeśli chcecie używać, to będziecie się musieli zdać na moje rozwiązanie. Zacznijmy od tego, że gImageReader wymaga do swojego działania i budowy qtspell, ten natomiast wymaga enchant. Obecna sytuacja w repozytoriach i w AUR jest następująca

Antergos, Gnome 3 i Wayland

I jakoś im nie po drodze. Gnome 3 od dłuższego już czasu, jako domyślny rodzaj sesji wybiera tę w Waylandzie. W standardowej instalacji Antergosa nie tylko, że zostanie wybrana sesja w Xach, to w ogóle nie będziemy mieć możliwości uruchomienia sesji w Waylandzie. Nie oznacza to, że Gnome 3 jest tam jakiś "inny" niż ten, który dostępny jest w innych dystrybucjach, a w szczególności w Archu. Dodatkowo są to praktycznie te same paczki, co w Archu. Dlaczego zatem Gnome 3 w Antergosie nie można uruchomić w Waylandzie? Odpowiedź jest bardzo prosta. Wszystkiemu winien tzw. Display Manager, którym we wszystkich środowiskach, z którymi można postawić Antergosa jest lightdm z autorskim (bodaj) greeterem . To właśnie LightDM nie wspiera (jeszcze) sesji w Waylandzie. Dla twórców Antergosa sesja w Waylandzie nie jest najważniejsza, a twierdzą że LightDM sprawuje im się znakomicie, nadto umożliwiając zachowanie tego samego wystroju dla wszystkich środowisk "wspieranych" przez An

Dlaczego dystrybucje wydawnicze i KDE to nieporozumienie

Tytuł to pewien skrót, albowiem poprawny winien brzmieć: dlaczego dystrybucje o wydawniczym modelu niedostosowanym do wydań oprogramowania KDE oraz bez repozytoriów typu backport, które są do owych wydań dostosowane, to nieporozumienie. Jak widzicie - nie tylko się nie zmieści, ale i nikt go nie przeczyta. Najpierw w skrócie o tym jak wyglądają tzw. wydawniczy model dystrybucji linuksa. Otóż po fazie testów jest publikowana wersja. Najczęściej faza testów trwa jakiś czas i wówczas - również najczęściej - całe oprogramowanie, jakie znajduje się w repozytorium zostaje zamrożone w swoich wersjach. W chwili wydania mamy zatem ściśle określone elementy w takiej dystrybucji, które swoją aktualność miały w chwili zamrożenia wydania. Oczywiście jeśli ten element nie uległ jakiejś zmianie, to w chwili wydania jest również aktualny. Jeśli jednak wyszła nowa wersja takiego oprogramowania, to najczęściej nie zostanie ona uwzględniona w wydaniu finalnym. Dodatkowo, najpopularniejsza spośród dystryb

Lumina Desktop Environment 1.4.0

For some reason, we have very outdated version of Lumina DE in AUR. So, I decided to prepare PKGBUILD for current version. It's 1.4.0. By the way, I changed a bit qmake flags used to build it. Original version of PKGBUILD provides only English version of this desktop environment, but Lumina has been translated for many lanugages (it's still work in progress). My version of PKGBUILD builds Lumina with translations. PKGBUILD builds package with proper localizations for files in /etc and for man and add license agreement, also. You can easily download PKGBUILD from here and place it in any directory. After this you should: 1. navigate to directory with PKGBUILD 2. make a package for Arch and install it makepkg -sirc Please remember check qmake line in it. It must be only one line. Very simple, I think so. Lumina DE requires fluxbox as window manager. I would like to thank marcin82 from Polish Arch Community for his creative support in creation of this PKGBUILD Po polsku (to

Brak możliwości utworzenia nowego katalogu w Dolphin [kde-unstable]

Testujący rozwiązania z repozytorium kde-unstable najtrafili najprawdopodobniej na problem braku możliwości utworzenia nowego katalogu w Dolphin (17.11.80 na KF5.40 oraz Qt5.10beta4). Problem został zgłoszony i został też naprawiony , a związany jest ze zmianami wprowadzonymi w Qt5.10. Dopadł zatem wyłącznie użytkowników używających Qt5.10 z kde-unstable . Jego rozwiązanie jednak, trafi dopiero do KIO 5.41, które oczekiwane jest 9.12.2017 r. Wcześniej spodziewać należy się finalnej wersji Qt 5.10, która planowo ukazać się ma 30.11.2017 r. Dzięki spostrzegawczości i wiedzy użytkownika @rog131 z BBS Archa dość szybko udało mi się temu problemowi zaradzić, tworząc dla KIO PKGBUILD z patchem (gdyby link do pastebin przestał działać, proszę mnie powiadomić - umieszczę gdzie indziej). Rozwiązanie jest tymczasowe i wierzę, że niebawem pojawi się wersja przygotowana przez Antonio Rojasa. Wprawdzie w przygotowanym PKGBUILDzie paczka nosi pkgrel 2, jednakże rozważcie sobie, czy nie lepiej d

KDE Apps 17.11.80 (17.12 beta) dostępne

Zespół KDE udostępnił wczoraj wersję beta zestawu swoich aplikacji, które ukażą się w grudniu . Jest to wydanie o tyle przełomowe, że usunięto z niego wszystkie aplikacje, które nie zostały przeportowane na KF5/Qt5. Skutkiem tego kroku będzie i to, że pakiety lokalizacyjne (kde-l10n-*) również nie będą udostępniane, albowiem są one konieczne wyłącznie dla aplikacji KDE4. Oprócz tych zmian, nie będą dalej rozwijane niektóre aplikacje (jak np. blogilo) - więcej wyżej w odnośniku do wydania. Dla używających Arch Linux, niestrudzony Antonio Rojas (arojas) przygotował paczki zawierające cały zestaw aplikacji KDE 17.11.80. Oczywiście osoby, które mogą się włączyć, są przeze mnie zachęcane, by przetestować te aplikacje i zgłaszać ewentualne błędy tak w samych paczkach, jak i w aplikacjach. Przypominam - pierwszy rodzaj błędów sygnalizujemy w Archu, drugi bezpośrednio w KDE. Chcący wypróbować KDE Apps 17.11.80 muszą udostępnić pacmanowi dwa repozytoria: kde-unstable oraz testing (ze względu

Koniec 32 bitowych paczek w Arch Linux

Stało się. Po wcześniejszej zapowiedzi , ostatecznie 8.11.2017 r. 32-bitowe paczki straciły wsparcie w Arch Linux. Do końca listopada paczki tego typu będą sukcesywnie wycofywane z repozytoriów, a potem nawet z archiwów. Pozostają paczki multilib. Wprawdzie jeszcze do repozytoriów wchodzą nowe paczki 32-bitowe, ale nie ma już takiego obowiązku. Dla użytkowników Archa w wersji 32-bit pozostają zatem trzy rozwiązania: - jeśli mogą, albowiem sprzęt ich na to pozwala, powinni zmienić wersję na 64-bitową, - jeśli rozwiązanie to nie jest możliwe, albowiem posiadają 32-bitowe maszyny, mogą sięgnąć po społecznościową kontynuację 32-bitowego Archa, które nazywa się ArchLinux32 , - trzecia jest ostatecznością - zmiana dystrybucji. W przypadku kontynuacji Archa jako ArchLinux32, należy dotychczasową listę mirrorów w /etc/pacman.d/mirrorlist zamienić na dostępne obecnie mirrory ArchLinux32 , następnie zainstalować paczkę archlinux32-keyring-transition i dokonać aktualizacji systemu, czyli: 1. Z

AMDGPU dla GCN1 i GCN2 i kerneli >=4.13

Jak część z Was wie, od jakiegoś czasu użytkownicy posiadający w swych zestawach karty graficzne AMD zbudowane w architekturze GCN1 (Southern Islands) oraz GCN2 (Sea Islands) mogą korzystać z dwu rodzajów sterowników otwartych: ati, zwany również radeon (paczka xf86-video-ati) oraz amdgpu (paczka xf86-video-amdgpu). Mogą również korzystać z własnościowych sterowników Catalyst, jednakże nie polecam tego rozwiązania, albowiem od końca 2015 roku projekt ten nie jest już rozwijany, a nadto wymaga sporych zmian w systemie. Pozostańmy zatem przy dwu otwartoźródłowych rozwiązaniach. Pamiętajmy, że wsparcie dla GCN1 i GCN2 w kernelu jest w dalszym ciągu określane jako " eksperymentalne ". Niemniej jednak - o ile wiem - we wszystkich kernelach obecnie oferowanych jest ono włączone. Musimy również pamiętać, że wsparcie to jest z wersji kernela na kernel lepsze, a zatem w przypadku korzystania z kernela linux-lts (obecnie to wersja 4.9) sensowniej będzie użyć sterownika ATI. Pozostań

Nadzieja na lepszą integrację LibreOffice ze środowiskami opartymi o Qt5

Nie. Absolutnie nic nie wskazuje na to, by LibreOffice miało zostać przepisane z użyciem Qt5. Mowa tylko o mechaniźmie wtyczki VCL, która umożliwia mimifikację wyglądu LO do natywnego w danym środowisku. Obecnie mamy cztery takie wtyczki: gtk2, gtk3, kde4 oraz "natywną". Cały proces winien przebiegać bez udziału użytkownika, choć można go wymusić. Obecnie, chcąc najbardziej upodobnić wygląd LO do np. Plasma 5, musimy zainstalować kdelibs oraz wystrój breeze dla KDE4. Wówczas jest lepiej, co nie znaczy idealnie. Proces przepisania wtyczki VLC dla KDE4 wydawał się nieunikniony, jednakże nie stanowił priorytetu prac. Niemałym zaskoczeniem dla mnie, było zatem ogłoszenie podczas LibreOffice Conference 2017 informacji o pracach w tym zakresie. Za przepisanie wtyczki odpowiedzialną jest Katarina Behrens, a całość w znacznym stopniu zawdzięczamy władzom Monachium, które postanowiły sponsorować te prace. W rezultacie winien poprawić się nie tylko wygląd LO w Plasma 5, natywne okna d

KDEPIM bez kopii zapasowej?

Niemal do miejskich legend przeszły utiskiwania nad brakiem łatwego programu do robienia kopii zapasowej w KDEPIM (Kontact, KMail,...). Fakt. W przeglądając opcje w menu programów składających się na KDEPIM nie znajdziemy czegoś takiego. Czy jednak fakt, że nie znaleźliśmy czegoś upoważnia nas do stwierdzenia, że czegoś nie ma? Antarktydy też nie ma, bo jej nie widziałem. Podobnie jak setek tysięcy innych rzeczy. Czas uderzyć się w pierś i powiedzieć: w błędzie byliśmy. Od bardzo dawna już (KDEApps 16.12), instalując grupę kdepim w Archu dostaniemy wraz z nią pim-data-exporter a wraz z nim zainstalują się dwa programy: pimsettingexporter oraz pimsettingexporterconsole. Pierwszy to wygodny program z GUI, drugie narzędzie konsolowe służące temu samemu celowi - eksportowi ustawień wszystkich programów składających się na KDEPIM oraz ewentualnie również archiwizowanych przezeń danych do pliku zip. Nie muszę chyba dodawać, że łatwo ów plik zip potem wczytamy do programu. Program jest prosty

Qt 5.10 beta 1

Od pewnego czasu w repozytorium kde-unstable dostępne są paczki pierwszej bety, nadchodzącego wydania Qt 5.10. Oprócz nich otrzymamy tam jeszcze kilka paczek z grup kf5 oraz plasma , które wymagały przebudowania w oparciu o nowsze biblioteki. Oczywiście, jak zwykle, powiedziałbym bierzcie i testujcie :) Tym razem jednak zamiast tego, pewne ostrzeżenie. Zapewnie wiecie doskonale, że niektóre środowiska są oparte o te biblioteki. Spośród tych już dojrzałych w mniejszym, czy większym stopniu to Plasma 5 (wraz z frameworkiem KF5) oraz LXQt. Także kilka dopiero przebijających się, jak np. Deepin DE, czy Liri. O ile niezbędne paczki z KDE zostały przebudowane w oparciu o Qt 5.10, to w przypadku innych środowisk musicie dowiedzieć się, czy i które (bo na pewno nie wszystkie) paczki składające się na dane środowisko będą wymagać przebudowy. To jednak jeszcze przysłowiowe małe piwo. Otóż Qt 5.10, przynajmniej w wersji Beta 1, robi psikusa użytkownikom Plasma 5. Po zainstalowaniu jest być moż

KMarkdownWebViewer

Czternastego września nie tylko ukazała się testowa wersja Plasma 5.11, ale aplikacje KDE uzyskały nowy element , dzięki którym te spośród nich, które wykorzystują KParts (np. Ark) są w stanie wyświetlić prawidłowo (tj. z formatowaniem) tzw. tekst markdown . Pliki w takim formacie (najczęściej noszące rozszerzenie *.md) często znajdziemy np. w pobranych źródłach programu. Jak dotychczas nie pojawiła się stosowna paczka w Archu, jednakże przygotowałem dla Was PKGBUILD. Jeśli chcecie z niego skorzystać, to znajduje się na pastebinie . Trzeba go skopiować do jakiegoś katalogu, a następnie skorzystać z możliwości makepkg. Wersja PKGBUILDu przedstawiona przeze mnie wykorzystuje qt5-webengine. Możliwe jest też skorzystanie z qt5-webkit. W takim przypadku należy dodać do sekcji depends qt5-webkit (bowiem możecie jej nie mieć w systemie) oraz dodać dla cmake opcję -DUSE_QTWEBKIT=TRUE . Wspomnieć należy, że obok już dostępnego KMarkdownWebView trwają prace nad podobnym rozszerzeniem dla KText

Plasma 5.10.95 aka 5.11Beta

Zgodnie z planem wydawniczym, 14.09. pojawiła się wersja 5.11 Beta środowiska Plasma. Dzięki pracy nieocenionego Antonio Rojasa (arojas) pojawiła się ona również w repozytorium kde-unstable Archa. Korzystając już z niej od kilku dni nie napotykam na jakieś problemy ze stabilnością. Jest nieco nowości: Ustawienia Systemowe uzyskały dodatkowy tryb wyglądu, powiadomienia historię, menedżer zadań (ale tylko ów domyślny) dorobił się pewnych dodatkowych opcji... Myślę jednak, że z punktu widzenia użytkownika dwa usprawnienia są najistotniejsze. Od tej wersji Plasmy będziemy się mogli cieszyć elementem o nazwie plasma-vault. Jest to aplikacja umożliwiająca przechowywanie plików w zaszyfrowanych katalogach. Druga rzecz, która mnie cieszy - obecnie można bezpośrednio z aktywatora programów otworzyć możliwość edycji ustawień danego programu. Mała rzecz, a cieszy i jest bardzo wygodna. Więcej w odnośniku wyżej. Oczywiście zachęcam do testowania, albowiem tylko w ten sposób osoby, które nie są i

Żegnamy QupZillę

QupZilla towarzyszy mi mniej więcej od czasu, gdy Rekonq przestał być rozwijany. Teraz QupZilla odchodzi. Na szczęście nie aplikacja, a nazwa jedynie. Od następnego wydania (powinno być w sierpniu lub wrześniu, a w każdym razie wkrótce po opublikowaniu Qt 5.9.2) nazywać się będzie Falkon i jednocześnie staje się kolejną aplikacją rozwijaną pod auspicjami KDE. Nie zdziwcie się zatem, że przy jakiejś aktualizacji pacman będzie chciał odinstalować qupzillę i w jej miejsce umieścić falkona. Osoby korzystające z qupzilla-git będą prawdopodobnie musiały same przebudować sobie PKGBUILD (jak ktoś chce, to służę). Obecna rewizja (2.1.99.efff69b7b2) tworzy swój własny katalog z profilami w ~/.config/falkon. Dla zachowania swojego starego profilu konieczne jest zatem przeniesienie zawartości ~/.config/qupzilla do ~/.config/falkon. Podobnie tworzony jest nowy plik ~/.config/Falkonrc, który również możemy podmienić zawartością ~/.config/QupZillarc by móc korzystać z Falkona dokładnie w tym miejsc

Zarządzanie zaporą sieciową w Plasma 5

Podzielone są głosy, czy istnieje potrzeba używania firewall na desktopie. Pewnie - i słusznie - większość stwierdziłaby, że reguły sieciowe winny być zdefiniowane w routerze. Niemniej jednak są osoby, które chcą je ustawiać w swoich komputerach. Powiedzmy sobie szczerze: choć linux dysponuje potężnymi narzędziami do regulacji zasad ruchu sieciowego, to dla zwyłego użytkownika ich ręczne ustawianie to czarna magia. W KDE4 istniał kiedyś moduł dla Ustawień Systemowych o nazwie kcm-ufw, który prosto zarządzał właśnie UFW. Moduł ten nie doczekał się jednak przepisania na Plasma 5 i z końcem roku powinien definitywnie wypaść ze świata KDE. W międzyczasie powstała nowa dystrybucja o nazwie Nitrux , która oprócz zmian w zakresie wyglądu Plasma 5 dostarcza również kilku aplikacji rozwijanych w ramach projektu. Pomiędzy nimi jest też Nomad Firewall . Aplikacja doczekała się wersji... 0.1, niemniej jednak jest ona funkcjonalna i na pewno dużo prościej przez nią zarządzać regułami zapory sieciow

Powrót z przeszłości: Kooka

W zamierzchłych czasach narzędziem do skanowania oferowanym w ramach KDE była Kooka. O ile pamiętam, to nigdy nie ukazała się oficjalnie jej wersja dla KDE4, gdzie została zastąpiona przez skanlite. Ta pierwsza ponad skanowanie dokumentu dodawała możliwość jego rozpoznania przez jeden z trzech silników OCR. Tym samym kooka stawała się namiastką programów typu Recognita dla KDE. Namiastką, albowiem samo rozpoznawanie tekstu w linuksie, szczególnie polskiego tekstu, było bardzo ułomne. Obecnie nieco zapomnieliśmy o tej funkcjonalności komputerów i większość dokumentów jest po prostu zapisywanych w nieedycyjnych formatach graficznych, w tym w pdf. Obecnie takim narzędziem jest np. gimagereader dostępny w AUR w dwu wersjach: używającej bibliotek Gtk+ , przez co lepiej nadaje się dla środowisk o nie opartych oraz używającej Qt5 . Niemniej jednak, jak feniks z popiołu odradza się Kooka, która w większym stopniu zintegrowana jest z Plasmą (oparta o KF5). Aplikacja działa i na pewno nadaje si

Huen, czyli kolorystyka Plasmy na podstawie tapety

Jakiś czas temu pojawił się w sklepie KDE dodatek do Plasmy, który umożliwia dostosowanie kolorystyki panelu do aktualnej tapety. Daje nawet trzy różne opcje owego dostosowania, które w efekcie dają kolor panelu w zależności od wyboru dominującego koloru tapety. Aplikacja nazywa się Huen i można ją pobrać ze sklepu, a następnie zainstalować skryptem znajdującym się w paczce (dostarczony jest również skrypt aplikację usuwający). Po instalacji program pojawia się w menu i można z niego korzystać w dwu dostępnych opcjach: jedna, w której zdajemy się na automatyzm w niej zawarty i druga, która umożliwia nam dostosowanie ustawień bardziej pod siebie. Po zaakceptowaniu zmian pojawia się w ustawieniach systemowych nowy wygląd pulpitu o nazwie Huen, który został przez nią zbudowany. Nie podoba mi się natomiast, że kompilując program dołączonym skryptem odbywa się ona z uprawnieniami roota. Między innymi z tego powodu postanowiłem zrobić dla Was PKGBUILD . Zdecydowanie więcej niż ode mnie dowi

FocusWriter a sprawa polska

Ewentualnie innych języków, na które aplikacja ta została przetłumaczona. Z pewnego powodu prosty procesor tekstu FocusWriter wprawdzie buduje pliki lokalizacyjne (*.qm), ale ich nie przenosi w prawidłowe miejsce. Ot, prawdopodobna wpadka przy pracy z plikiem *.pro. W efekcie zbudowana z AUR aplikacja będzie działać wyłącznie w języku angielskim, choć mogłaby również w polskim. Istnieje bardzo proste obejście problemu. Podczas budowania paczki należy dokonać edycji pliku PKGBUILD i w sekcji package po: make INSTALL_ROOT="$pkgdir/" install dopisać: cp translations/*.qm $pkgdir/usr/share/focuswriter/translations Ewentualnie jeszcze trzeba będzie wybrać polski język interfejsu już w samej aplikacji. EDIT: Wszystko wskazuje na to, że wersja FocusWriter 1.6.5-2 dostępna od 3.07.2017 r. w AUR buduje już poprawnie paczkę i nie trzeba stosować powyższej sztuczki. Wersja focuswriter-git nie wymaga już również dodawania żadnych wpisów.

LibreOffice 5.4RC1 oraz 6.0alpha0

Od jakiegoś czasu są rozwijane wersje, które stanowić będą następców obecnych wydań LO. Ciekawostką, że wersja 5.4.x będzie ostatnią w linii 5.x, a dostępna od przyszłego roku będzie już linią 6.x. Wersje testowe 5.4 są już dostępne ze strony LO , także dla linuksa, jednakże - jak zwykle - są to wydania deb i rpm. Oczywiście są udostępnione także źródła. Wersja rozwojowa 6.0 jest głębiej ukryta i dostępna bezpośrednio z serwerów Document Foundation. W odróżnieniu od 5.4RC1 w tej wersji nie możemy się jeszcze spodziewać spolszczenia, choć możliwe jest oczywiście korzystanie z polskich słowników, czy innych reguł pisania. Jak zwykle namawiam osoby, które są chętne do testowania, by choćby w ten sposób włączyły się w rozwój oprogramowania. Jest jeszcze czas, by usunąć jakieś ewentualne niedoróbki. Jeśli zatem ktoś zechciałby się włączyć, to mogę zaproponować obie wersje pakietów (w przypadku 6.0 także z "instrukcją obsługi" jak ją aktualizować) dla Archa (także dystrybucji poc

Dlaczego nie instalować pojedynczych paczek innych gałęzi systemu

Dystrybucje linuksowe zwykle zawierają "przejściowe" repozytoria, gdzie testowane są nowe paczki. Niektóre dystrybucje, z owych repozytoriów tworzą nawet niemal oddzielne gałęzie swych dystrybucji, a społecznościowa gawiedź dośpiewuje całą resztę, upatrując np. w Debian Testing ucieleśnienia dystrybucji rolling release. Zostawmy jednak Debiana, skupmy się na Archu i pokrewnych. W Archu dostępnych jest kilka repozytoriów. Podobnie w Manjaro. W strukturze repozytoriów tego pierwszego znajdziemy repozytoria z "dopiskiem" testing i dwa repozytoria z "dopiskiem" unstable (kde i gnome). Struktura gałęzi Manjaro jest praktycznie przeniesiona z Debiana, choć absolutnie niewiele ma z nim wspólnego. Ograniczę się do omówienia Archa, jednakże to samo ma zastosowanie do innych dystrybucji rolling release (to jest kluczowe), na pewno natomiast ma to 100% zastosowanie do dystrybucji, gdzie paczki zarządzane są przez pacmana. Otóż pojawiają się wpisy omawiające sposób

Naprawiamy wadliwe źródła w PKGBUILD

Zdarza się, że przy budowie jakiejś paczki z AUR otrzymujemy taki błąd: ==> BŁĄD: Błąd podczas pobierania http://jakiś_adres Przerywam... Najczęściej powodem tego błędu jest wadliwy adres źródła. Może to być spowodowane tym, że zmianie uległa wersja programu, a źródeł starej już nie ma, może być spowodowane zmianą adresu źródła, powodem może być też, że źródła w ogóle zostały usunięte, może to być też jakiś czasowy problem z połączeniem. Ostatnie - proste - można spróbować po chwili. Na całkowite usunięcie źródeł możemy nie zaradzić wcale. Jedyne co mogę sugerować to poszukanie w necie, czy gdzieś nie są one oferowane w innej lokalizacji. W tej sytuacji powinniśmy jednak mieć pewność co do poprawności paczki oferowanej nie przez jej autora. Pierwsze dwa są dość proste do naprawienia. Generalna zasada: odszukać źródła. Wchodzimy na stronę AUR z PKGBUILDem, znajdujemy URL źródła , przechodzimy i czytamy co się zmieniło. Oczywiście informujemy również opiekuna takiej paczki w AUR

Czy muszę mieć uprawnienia root, by sprawdzić możliwość aktualizacji?

Oj, tam. Psioczymy niekiedy na nasz system (Arch), a nie znamy jego możliwości. Psioczymy na przykład, że aby sprawdzić możliwość aktualizacji systemu musimy wydać jakieś polecenie, wpisać hasło administratora i dopiero potem dowiemy się, czy aktualizacja jest możliwa. Innymi słowy, wpisujemy w terminalu: sudo pacman -Syu No dobrze, a czy korzystając z dobrodziejstw zainstalowanych wraz z pacmanem nie możemy napisać: checkupdates ...? Nie musimy wpisywać haseł administratora, niczego. Po chwili uzyskamy informację czy jest, czy też nie jest możliwa aktualizacja systemu.

Aplikacje KDE pozwolą na roota. Bezpieczeństwo i wolność

Nie tak dawno - tu i ówdzie - podniosła się wrzawa , że KDE w imię bezpieczeństwa odbiera wolność użytkownikom, uniemożliwiając wykonywanie działań wymagających uprawnień administratora w aplikacjach KDE. To nic, że "problem" dotyczył wyłącznie trzech aplikacji: kate, kwrite i dolphin. To nic, że dotknął jedynie tych dystrybucji, które zaoferowały KF w wersji co najwyżej 5.33 oraz jednocześnie aplikacje z wersji 17.04.0. Jednocześnie z opublikowaniem tej wersji, zostało wprowadzone obejście, umożliwiające edycję plików wymagających uprawnień administratora przez kate i kwrite. Mimo wszystko problem był, a w zasadzie to został sztucznie rozdmuchany, zwłaszcza, że już w chwili jego (problemu) tworzenia była znana informacja na temat zmian, jakie w 2017 r. czekają KIO z KF5. Realizując założenia zmian w KIO na ten rok, już 13.05.2017 r. zostało udostępnione publicznie KF5.34, które przywróciło możliwość edycji plików wymagających uprawnień administratora przez kate i kwrite bez

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra] SigLevel = Optional TrustAll Server = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive

Aplet informujący o aktualizacjach w Archu

Choć zrobiony w istocie z myślą o Archu, to sądzę, że prawidłowo będzie działał w każdym systemie korzystającym z checkuptades - oto pojawił się nowy, integrujący się z Plasmą 5, aplet informujący nas o możliwych aktualizacjach systemu. Nazwa jaką przyjął w sklepie KDE to Arch Linux System Tray Update Notifier and Upgreader i jej przeczytanie trwa chyba dłużej niż budowa tego programiku. Jak wspomniałem, aplet wykorzystuje checkupdates , a dzięki temu nie potrzebuje uprawnień administratora. Posiada podstawową możliwość konfiguracji ograniczającą się do ustawienia częstotliwości sprawdzania aktualizacji (którą to funkcję można również wymusić niezależnie od ustawień) oraz możliwości pomijania numeru wersji przy opisach paczek przeznaczonych do aktualizacji. Nadto - gdy takie się pojawią - możliwe jest wywołanie pacmana i przeprowadzenie aktualizacji systemu. Dla osób korzystających z Plasma 5 oraz niekorzystających z Octopi to obecnie chyba jedyne takie narzędzie. Zainstalować je m

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11 . Sam program w Archu dostępny jest w AUR . Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryf

Kolorystyka aplikacji wykorzystujących kdelibs w Plasma 5

Kiedyś już pisałem co zrobić, by zmusić do działania LibreOffice, tak by respektowało kolorystykę ustawioną w Plasma. Niestety jednak nie zawsze to działa. Czas zatem na brutalne metody. Najpierw jednak chwila refleksji. Otóż LibreOffice jest aplikacją, która usiłuje się upodobnić do środowiska. Jeśli niczego nie zmieniamy i jeśli pracujemy w środowisku, które LibreOffice rozpozna jako KDE, to próbuje upodobnić się do... KDE4. Co zatem powoduje, że rozpoznaje to środowisko jako KDE? Otóż istnienie w systemie starej biblioteki KDE4 o nazwie kdelibs. Skoro tak, to ustawienia właśnie dla KDE4 będą respektowane przez LibreOffice (podobnie jak wszystkich innych aplikacji, które jeszcze nie zostały przeportowane do Qt5/KF5, jak choćby amarok). Teoretycznie sama Plasma winna zapewnić spójność wyglądu aplikacji KDE4/Qt4 z jej ustawieniami. Niestety nie zawsze jej to wychodzi. I tu właśnie pora sięgnąć po owe brutalne metody, o których wspomniałem. Przede wszystkim musimy sobie uświadomić gdz

Opowieść o tym jak baloo zżera zasoby komputera

Wraz z akonadi, to część KDE, który podawany jest zwykle jako argument na bezsensowność tego środowiska, jego przerośnięcie i ogromny apetyt na zasoby. Już nie tylko RAM, ale i CPU, którego potrafi zagospodarować np. cały jeden rdzeń. Komputer zwalnia, źle pracuje. Wszystkiemu oczywiście winne baloo. Czyżby? Nie na darmo mówi się, że największy błąd oprogramowania siedzi przed komputerem i z niego "korzysta". Ów element zwany użyszkodnikiem może jednak pomóc baloo. Kiedyś już pisałem o tym, jak można ustawić ten komponent. Także wyłączyć. Załóżmy jednak, że chcemy z niego korzystać i jednocześnie nie chcemy, by zużywał 100% rdzenia CPU, czy np. 1 (i więcej) GB RAM. Czy to możliwe? Oczywiście. U mnie np. baloo zużywa ok. 2MB RAM i zasadniczo pomijalny ma apetyt na CPU. Zwykle zużycie wynosi poniżej 1%, a najczęściej sobie śpi. Otóż częstą przyczyną nadmiernego zużywania zasobów przez baloo jest nakazanie mu indeksowania nieistniejących katalogów. W wielu dystrybucjach baloo

Hardcore - Kompilacja programu pod własny procesor, cz. 4 - cmake

Kontynuując ten mini cykl, pozostało mi jeszcze jedno narzędzie do automatycznego sterowania procesem kompilacji, które oporne jest na ustawienia makepkg.conf - jest nim często stosowany w "świecie" Qt - cmake . Dotychczasowe sztuczki nie pomagają. W zasadzie, to stosowne wpisy winny być umieszczone w pliku CMakeLists.txt i można byłoby się pokusić o wykorzystanie np. sed w tym celu. Wydaje się jednak, że istnieje prostrza możliwość. Problem jedynie w tym, że nie mam 100% pewności, że ona działa prawidłowo. W przeciwieństwie do innych, cmake nie informuje nas, czy kompiluje program z wykorzystaniem flag właściwych dla naszego procesora. Sztuczka polega na delikatnej ingerencji w PKGBUILD. Dodać musimy pewien wpis, w zasadzie w dowolnym miejscu przed budową programu. Ja do tego używam sekcji prepare , zatem stosowny, dodatek może wyglądać tak: prepare() { export CFLAGS=-march=native export CXXFLAGS=-march=native } I w zasadzie tyle. W powyższym przykładzie użyłem możliwośc