sobota, 29 lipca 2017

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 sieciowej. Po instalacji mamy dostępną zarówno samodzielną aplikację, jak i moduł uruchamiany przez Ustawienia systemowe. Nie byłbym sobą, gdybym nie zrobił dla niej PKGBUILDu. Prezentowany jest w wersji "git", gdyż aplikacja jest dość intensywnie rozwijana. Jeśli ktoś chciałby ją w wersji "stabilnej" :) 0.1 i nie wiedziałby jak przerobić PKGBUILD dla jej uzyskania, to proszę o kontakt.

piątek, 28 lipca 2017

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ę do skanowania. Jej możliwości OCR ograniczone przez silniki: ocrad, gocr i kadmos. Pierwsze dwa są dostępne w repozytorium, ostatni jest przedsięwzięciem komercyjnym. Załączam PKGBUILD, który umożliwia budowę wersji "git" tej aplikacji. Jeśli chcemy korzystać z możliwości OCR musimy zainstalować co najmniej jeden z wyżej wymienionych silników.

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 dowiecie się z dołączonego filmu.

sobota, 1 lipca 2017

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.

środa, 28 czerwca 2017

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 pochodnych). Oba pakiety są przebudowywane z oryginalnych paczek rpm i mogą zostać zainstalowane obok libreoffice-fresh/still. Nie ingerują też w żaden sposób w ustawienia wersji z repozytorium. Nie będę tym razem zamieszczał PKGBUILDu - gdyby ktoś zechciał się zdecydować - proszę o kontakt.

czwartek, 22 czerwca 2017

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 zainstalowania pojedynczej paczki z innej gałęzi (repozytorium testowego, niestabilnego) danej dystrybucji. Jest to bardzo nieodpowiedzialny pomysł, choć realizowany wg zasady: chcącemu nie dzieje się krzywda. Oczywiście, że istnieje możliwość zainstalowania czegokolwiek, skądkolwiek i w jakiejkolwiek wersji. Zastanówmy się jednak co to oznacza i czy na pewno "możliwość" oznaczna, że "można". Przede wszystkim należy przypomnieć jedną sprawę: pacman nie wspiera częściowej aktualizacji. Uświadomijmy sobie również, że taka instalacja nowej wersji z testowego repozytorium jest niczym innym, jak właśnie dokonaniem częściowej aktualizacji. Operacja może się udać. Program zainstalowany w ten sposób może działać prawidłowo. Może jednakże nie działać wcale, może okazać się działającym wadliwie (np. niestabilnie). Może też doprowadzić do destabilizacji całego systemu, a w skrajnych przypadkach po prostu go nie uruchomimy ponownie (w obu przypadkach, gdy np. zmieniliśmy jakiś kluczowy jego element, bibliotekę, na która jest zależnością innych paczek). Dlaczego tak się dzieje? Otóż dystrybucje takie jak Arch są robione w taki sposób, że ich deweloperzy starają się zapewnić właściwą pracę zaktualizowanego systemu. Paczki znajdujące się w określonym repozytorium są budowane w taki sposób, że ich zależności znajdują się w tym właśnie repozytorium. Owe zależności oznaczają nie tylko "nazwę paczki", ale też jej określoną wersję, która w tym repozytorium się znajduje. Paczki w repozytorium "stabilnym" winny zatem być w korelacji ze sobą. W repozytorium testowym będą paczki skorelowane ze sobą. Jeśli zatem jakaś paczka będzie wymagała jakiejś zależności w określonej wersji, to owa paczka w takiej wersji się znajdzie. I odwrotnie - jeśli jakaś zależność spowoduje konieczność przebudowania jakiejś paczki, to taka przebudowana paczka tam się znajdzie. To właśnie dlatego pacman nie wspiera częściowej aktualizacji. Musimy sobie uświadomić jeszcze jedną rzecz. Otóż w przeciwieństwie np. do APTa, w PKGBUILD bardzo rzadko znaleźć można określenie wersji konkretnej paczki stanowiącej zależność. Przy instalacji poszczególnej paczki nie zostajemy zatem powiadomieni o tym, że jakaś paczka nie jest kompatybilna z wersją instalowaną. Arch (Manjaro) - to Arch. Bardzo prosta w budowie dystrybucja, jednak trzeba o nią dbać, a nie gwałcić ją na siłę. Chyba, że doskolane wiemy co robimy, wiemy, że instalacja czegoś pociąga konieczność zmiany innej paczki itd. itp. Co zatem zrobić, jeśli z jakiejś przyczyny bardzo musimy mieć wersję paczki znajdującej się w gałęzi (repozytorium) innym niż używane? Trudno - innej drogi nie ma - choćby czasowo musimy zainstalować wszystkie paczki w tej samej wersji (testowej), w jakiej potrzebujemy mieć określoną (jedną) paczkę. W Archu robimy to "ręcznie" udostępniając repozytoria testowe. W Manjaro możemy wydać polecenie:
sudo pacman-mirrors -g -b testing (lub unstable)
I dokonać pełnej aktualizacji:
sudo pacman -Syu
Jeśli później zechcemy wrócić do "gałęzi" poprzedniej, powinniśmy w Archu zakomentować repozytoria testowe, w Manjaro wykonać:
sudo pacman-mirrors -g -b stable (lub testing)
I... dokonać pełnej aktualizacji systemu z jednoczesnym wgraniu w miejsce istniejących lokalnie wersji paczek, tych, które znajdują się na serwerze, nawet jeśli są one w wersji niższej od lokalnej:
sudo pacman -Syuu

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 o zaistniałym problemie. Możemy też przedstawić mu wyniki analizy naszego skromnego dochodzenia - korekta w AUR może się pojawić szybciej. W każdej z poniższych sytuacji wykorzystujemy sposób instalacji paczek bez tzw. aurhelperów. Przypomnę zasady: - ściągamy tzw. źródła budowania paczki z AUR np.:
git clone https://aur.archlinux.org/nazwa_paczki.git
- w katalogu, z którego wydaliśmy to polecenie powstanie podkatalog o nazwie nazwa_paczki, przechodzimy do niego:
cd nazwa_paczki
- dalsze operacje wykonujemy na pliku PKGBUILD, który znajdziemy w tym katalogu. 1. Oferowana jest nowa wersja i nie jest dostępna stara. Po pierwsze oflagujmy paczkę w AUR jako nieakutalny (ramka po prawej stronie). Po drugie, w zależności od tego, czy czujemy się na siłach, możemy spróbować zainstalować paczkę w nowszej wersji. W tym celu: - zmieniamy zawartość pola pkgver na taką wersję, z jaką napotkaliśmy się na stronie domowej programu, - dokonujemy ewentualnej zmiany w polu source na korespondujący z nową wersją; jeśli w tym polu będzie adres posługujący się zmienną wersji źródła (tj. zobaczymy np. coś takiego:
jakiś_adres/coś-$pkgver_coś
to PKGBUILD posługuje się zmienną ($pkgver) w celu ustalenia adresu źródła - w tej sytuacji nie powinniśmy mieć potrzeby dokonywania jakichkolwiek zmian, jeśli jednak w adresie tym znajdziemy jakieś cyfry wskazujące na właśnie co zmienioną wersję w polu pkgver to i w adresie musimy je zmienić. - sprawdzamy, czy pozostałe sekcje PKGBUILD posługują się ewentualną zmienną numeru wersji ($pkgver), czy też jej numerem - w tym drugim przypadku zmieniamy na nowy numer wersji, - wykonujemy polecenie:
updpkgsums && makepkg -sirc
- liczymy na to, że operacja się udała. Jeśli operacja się nie udała, pozostaje nam czekać na podbicie wersji w AUR bądź zwrócić się do społeczności o pomoc. Chyba, że sami jesteśmy w stanie poradzić sobie z problemem. W tym ostatnim przypadku dobrze jest choćby w komentarzach na AUR podać rozwiązanie. 2. Zmianie uległ adres źródła. Po pierwsze zawiadamiamy o tym opiekuna paczki w AUR. Po drugie zmieniamy zawartość pola source na właściwy adres (najprościej będzie nam po prostu go wkleić w miejsce dotychczasowego) wykonujemy polecenie:
updpkgsums && makepkg -sirc
3. Źródła zostały usunięte, ale znajdują się w innej lokalizacji. Jeśli jesteśmy ich pewni, to postępujemy dokładnie tak samo jak w punkcie 2. 4. Czasowy problem z dostępem do serwera ze źródłami. Jak już napisałem - poczekać. Jeśli jednak bardzo nam zależy na szybszym zbudowaniu paczki, możemy spróbować znaleźć w necie jakiejś alternatywnej lokalizacji źródeł i postąpić jak w punkcie 2.