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.

środa, 21 czerwca 2017

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.

wtorek, 20 czerwca 2017

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 bez wspomnianego obejścia (gwoli pełnej informacji, KDE Applications 17.04.0 pojawiło się publicznie 20.04.2017 r.). Od tej chwili możliwe była zatem edycja np. plików systemowych, a przy próbie ich zapisu system prosił o hasło administratora. Wszystko dzięki zmianom w KIO i połączeniu go z mechanizmem polkit. Tym samym zwiększono bezpieczeństwo bez zmian funkcjonalności. Pozostał "problem" jedynie z dolphinem, który uniemożliwiał operacje na plikach systemowych (inna sprawa, że prawidłowo skompilowany krusader takich problemów nie miał i nie ma). Stąd też np. powstawały forki typu dolphin-root, różniące się od oryginału wyłącznie cofnięciem zmiany uniemożliwiającej takie działania. Ba, dolphin-root pojawił się nawet w repozytoriach niektórych dystrybucji. Śpieszę zatem donieść, że i ten "problem" przestanie niebawiem istnieć. Otóż wprowadzone niedawno przez Chinmoya Ranjana Pradhana zmiany w KIO zostały właśnie połączone z kodem KF5 i już w nadchodzącym wydaniu KF5.36 (planowane na 8.07.2017 r.) dolphin odzyska możliwość pracy również na plikach systemowych. Mechanizm wprowadzonej zmiany ten sam, jak w przypadku kate i kwrite, czyli wykorzystanie polkit. Jeśli ktoś bardzo chciałby skorzystać z tej funkcjonalności obecnie, to musiałby zbudować KF5 z git i niestety nie wystarczy samo KIO, albowiem zmiany nadchodzące w wydaniu 5.36 są na tyle duże, że nie jest możliwym budowa samego KIO z git bez zbudowania komponentów, na których się opiera. Można ewentualnie spróbować użyć udostępnionych patchy (dla dolphin), jednakże ich wbudowanie wymaga również spatchowanej wersji KIO (tj. dodania tych funkcjonalności, które właśnie zostały tam wprowadzone (dot. JobUiDelegate). Teraz pozostaje mieć nadzieję, że z wprowadzonych mechanizmów z czasem zaczną korzystać inne aplikacje wykorzystujące Xy, a umożliwiające pracę w przestrzeni administratora. Problem bowiem nie jest tak trywialny, jak się niektórym wydaje, że dotyczy to tylko i wyłącznie wprowadzenia do systemu niezamierzonych zmian przez użytkownika.

poniedziałek, 19 czerwca 2017

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-keys BF8B66E01192CBA2E72201294B4E7A9523ACD201
Instalujemy megasync oraz - jeśli chcemy - dowolny dodatek do naszego menedżera plików. Od tej pory możemy się cieszyć łatwym dostępem do dość potężnej chmury. Oczywiście, o ile mamy tam utworzone konto.