Bridge Linux: Instalacja – zakończenie

Niniejszy tekst jest kontynuacją wpisu: Bridge Linux: Instalacja – część III

W tej – niestety, ostatniej już :–( – części serii o instalacji Bridge'a, zajmiemy się następującymi, dwiema kwestiami: pierwszą aktualizacją systemu oraz spolszczeniem środowiska graficznego. Tym samym, nasz, "świeżo" zainstalowany, Bridge Linux zostanie ostatecznie przygotowany do samodzielnego funkcjonowania.

Z uwagi na fakt, że niedawno wydano Bridge'a 2012.5 (millertechnologies.net i distrowatch.com ), który zawiera nowsze wersje wielu pakietów (programów), niezbędna była modyfikacja bieżącej części wpisu i uwzględnienie "nowych warunków", a zmiany te dotyczą, zwłaszcza, aktualizacji systemu. Dlatego, zamieszczony poniżej, opis pierwszego upgrade'u Bridge'a uwzględnia dwie wersje systemu: 2012.4 i 2012.5.

Mea culpa!

Zanim przejdziemy do kwestii informatycznych, chciałbym przeprosić wszystkich Czytelników, zwłaszcza tych, którzy oczekiwali na opublikowanie bieżącej części wpisu o instalacji Bridge'a. Zdaję sobie sprawę i w pełni rozumiem, że dla kogoś, kto – po przeczytaniu trzech poprzednich części wpisu – nadal był zainteresowany poznawaniem dystrybucji i tajników jej instalacji, a być może, potrzebował dalszego wsparcia w tym zakresie, absolutnie żadne wyjaśnienia powodów opóźnienia nie będą wystarczające. Tym niemniej, chcąc wytłumaczyć się z zaistniałej sytuacji, muszę powiedzieć, że pracując ostatnio po 11 – 12 godzin na dobę, a w dodatku – o całkowicie różnych porach dnia – naprawdę, brakowało mi sił na blogowanie. Poza tym, dodatkowy zamęt wprowadzały kolejne zmiany w repozytoriach Archa, co miało bezpośredni wpływ na przebieg i sposób aktualizacji Bridge'a: to, co, jednego dnia, udało się uaktualnić we wpisie, niekoniecznie pozostawało aktualnym, następnego.

Summa summarum – jeszcze raz bardzo gorąco przepraszam, mając nadzieją, że Czytelnicy wybaczą mi i, co najmniej, równie chętnie i obficie, jak poprzednio – wyłączywszy część I :–) – przyozdobią swymi komentarzami niniejszą część wpisu.

Materiały i narzędzia.

Przed przystąpieniem do pierwszej aktualizacji, warto zapoznać się, z czym będziemy mieć do czynienia i jak to funkcjonuje; wskazane jest (i to bardzo!) poznanie tego wszystkiego, czym się będziemy posługiwać i na czym przyjdzie nam działać.

tworzywo

Arch, na którym bazuje Bridge Linux, jest dystrybucją ciągłą, więc zawartość jego repozytoriów zmienia się, praktycznie, bez ustanku. Kolejne edycje tego typu dystr, a zatem, również Archa, czy Bridge'a, nie są tworzone po to, by aktualizować zainstalowany system (ten aktualizowany jest "na bieżąco", w toku swojego działania), ale po to, by w przypadku "świeżych" instalacji nie trzeba było spędzać wielu godzin, aktualizując system i oprogramowanie.

Jeżeli, więc, zainstalowaliśmy Bridge'a w wersji 2012.4, nie ma potrzeby instalowania wydania 2012.5. Wskazane jest, jednak, uaktualnienie systemu, o ile nie było jeszcze przeprowadzane.

pacman i packer w jednym stali domu...

Zasadniczo, menadżerem pakietów w dystrach opartych na Archu, jest pacman. Program ten został stworzony przez Judda Vineta, twórcę Archa, w 2002 roku i jest bardzo rozbudowanym narzędziem, o, naprawdę, szerokim wachlarzu możliwości (według niektórych użytkowników, pacman, to dzieło, niemal doskonałe): instalacja programów oraz ich usuwanie, wyszukiwanie dostępnych i zainstalowanych pakietów, a także wyświetlanie o nich informacji, czy wreszcie, aktualizacja poszczególnych programów, jak i całego systemu. Nie ma sensu zamieszczanie tutaj opisu wszystkich jego opcji (a jest tego dość sporo) i wspomnieć wystarczy o tych, które wykorzystamy podczas upgrade'u Bridge'a (tych Czytelników, natomiast, którzy mają ochotę dowiedzieć się o pacmanie trochę więcej, odsyłam do strony domowej projektu, jego polskiej i angielskiej wiki oraz do manpages ):

pacman -Sy				– aktualizacja bazy pakietów
pacman -Su				– aktualizacja systemu
pacman -Syu				– aktualizacja bazy pakietów oraz upgrade systemu
pacman -S nazwa_pakietu	– instalacja pakietu wraz z pakietami zależnymi

Bridge Linux, dzięki domyślnie zainstalowanemu programowi packer, daje możliwość instalacji oprogramowania ze społecznościowego repozytorium AUR, natychmiast po uruchomieniu i to, bez konfigurowania czegokolwiek. Więcej! Sama dystrybucja używa kilku społecznościowych, pochodzących z AUR, pakietów, jak choćby, opisywany packer, czy – dość trwale związane z innymi elementami systemu: fontconfig-ubuntu, freetype2-ubuntu i cairo-ubuntu.

Packer jest, napisanym w bash'u, skryptem, obsługującym, prócz AUR‑a, również repozytoria "standardowe". Intencją autora, Matthew Brueniga, było zastąpienie yaourta – innego narzędzia do zarządzania pakietami z Arch-Linux User Repository – oraz prostsze i szybsze korzystanie z jego funkcjonalności. Poza tym, packer – wykorzystując pacmana – "umie" instalować także pakiety z głównych repozytoriów, czy nawet zaktualizować system. Jego opcje podobne są do tych, którymi dysponuje pacman:

packer -Syu				– aktualizacja bazy pakietów oraz upgrade systemu
packer -S nazwa_pakietu	– instalacja pakietu wraz z pakietami zależnymi

Jak widać, packer nie posiada możliwości oddzielenia aktualizacji bazy pakietów od upgrade'u systemu, a operacje te, można wykonać jedynie łącznie. Skrypt ten nie potrafi również usuwać pakietów (nawet tych z AUR‑a) i w zakresie tym, trzeba używać pacmana (więcej informacji o packerze znajdziemy na wiki projektu ).

Uwaga!  Twórca Bridge'a zaleca, by packera uruchamiać z konta i na prawach zwykłego użytkownika, podając jako argument to, iż pliki PKGBUILD, z których budowane są pakiety, mogą czasami zawierać złośliwe instrukcje, szkodliwe dla systemu:

Osobiście, wcale nie stosuję się do tego zalecenia i każdorazowo, wbrew niemu, uruchamiam packera na koncie roota. Dotychczas (odpukać w niemalowane drewno) nie wydarzyło się nic złego, a system działa stabilnie i sprawnie. Stanowczo, jednak, odradzam takie postępowanie (zwłaszcza początkującym użytkownikom), bo jego skutki mogą być, naprawdę, poważne (z koniecznością reinstalacji systemu, włącznie)!

Wszyscy na miejsca! Akcja!!!

Uwaga!  Zanim przejdziemy do konkretnych działań, muszę – dla własnego bezpieczeństwa – wyjaśnić pewną, ogólną kwestię. Otóż...

większość czynności i możliwych sytuacji starałem się dokładnie i szczegółowo opisać, mimo to, proszę, aby poniższy materiał potraktować, wyłącznie, jako informacyjny i ze wszech miar, przykładowy – aktualizacja Bridge'a, przeprowadzana na innym sprzęcie, w innym czasie oraz w innych warunkach, może, pod wieloma względami, znacząco odbiegać od tej, opisanej tutaj! Wiąże się to, głównie, z dynamiką i różnorodnością zmian, mających miejsce w repozytoriach Archa, które powodują, iż nie da się przewidzieć wszystkich, ewentualnych okoliczności, jakie mogą wystąpić podczas upgrade'u systemu (ot, chociażby, kwestia glibc, która miała miejsce ostatnio – aktualizacja świeżej instalacji Bridge'a i wcześniejszych ).

Powracając, jednak, do meritum...

Załóżmy, że właśnie zakończyliśmy instalację Bridge'a (z dowolnym środowiskiem graficznym, dla dowolnej architektury) i przystępujemy do jego pierwszej aktualizacji. Uruchamiamy, zatem, system z twardego dysku i logujemy się na konto zwykłego użytkownika (nie roota!).

Pierwszy krok, jaki należy wykonać, to upewnić się, czy działa połączenie z internetem, a jeżeli tak nie jest – podłączyć je i/lub skonfigurować (u tych osób, które łączą się z siecią przy użyciu kabla, wszystko, najprawdopodobniej, działa "z automatu"; użytkownicy WIFI muszą, natomiast, skonfigurować połączenie).

Kiedy połączenie jest już aktywne i działa poprawnie, uruchamiamy terminal / konsolę, logujemy się na konto roota i możemy przystąpić do pierwszej aktualizacji systemu.

Uwaga!  Logowanie na konto roota można pominąć, ale wówczas, pacmana należy uruchamiać poprzez sudo, np., sudo pacman -Syu.

Bridge Linux 2012.4

W przypadku Bridge'a 2012.4, aktualizację systemu musimy przeprowadzić w trzech etapach. Uruchomienie, bowiem:

[code=]pacman -Syu[/code]

skutkuje takim, oto, wynikiem:

Wprawdzie, gdybyśmy nie chcieli przerywać instalacji i na pytanie:

[code=]:: Czy chcesz anulować obecną operację :: i zaktualizować te pakiety teraz? [T/n] [/code]

odpowiedzieli negatywnie ([n] + [Enter]), system, w większości zaktualizowałby się, jednak, ze względu na to, że dobrą praktyką jest aktualizacja menadżera pakietów w pierwszej kolejności (bez względu na to, jakiej dystrybucji używamy), co sugeruje, zresztą, sam pacman:

[code=]:: Następujące pakiety powinny być zaktualizowane najpierw : pacman [/code]

zdecydowanie zaleca się podjęcie próby jego upgade'u. Niestety, w przypadku Bridge'a 2012.4, kończy się to w taki sposób:

Wynika to stąd, że pacman, dostępny zaraz po instalacji w wersji 4.0.2, nie za bardzo chce się dać zaktualizować do zawartej w repozytorium, wersji 4.0.3, a winę ponosi, jak zwykle, system zależności.

Jeżeli w tym momencie zwątpiliście w powodzenie akcji, to spieszę poinformować, że zupełnie niepotrzebnie, a zgodnie z powiedzonkiem: na choroby są sposoby, również i z tej sytuacji jest, całkiem proste, wyjście – podział upgrade'u systemu na etapy:

Po pierwsze, odczytujemy z serwerów dane o repozytoriach i dostępnych w nich pakietach. W tym celu wykonujemy:

[code=]pacman -Sy[/code]

Uwzględniając to, że chwilę wcześniej uruchamialiśmy pacmana z parametrem '‑Syu', nie ma teraz konieczności ponownego pobierania danych o zawartości repozytoriów (stąd, brakuje tu stosownego zrzutu ekranu). Jednakowoż, jeśli, w "normalnych warunkach", od tego momentu rozpoczniemy aktualizację Bridge'a, wykonanie powyższej czynności, będzie, jak najbardziej, wskazane, a nawet, niezbędne.

Po drugie, aktualizujemy pacmana, co sprowadza się do wydania polecenia:

[code=]pacman -S pacman[/code]

Nie jest to, tak naprawdę, nic innego, jak ponowna instalacja pacmana, a dokładniej – nowszej jego wersji. Efekt działania, wydanej powyżej komendy, jest następujący:

Na widoczne powyżej pytanie, należy, oczywiście, odpowiedzieć twierdząco, tzn., wystarczy, że naciśniemy [Enter], ale to samo uzyskamy, naciskając [t], a następnie [Enter]:

Na marginesie...

Warto, przy okazji, poświęcić chwilkę pytaniom, które w trakcie działania zadają, uruchamiane w konsoli, programy lub skrypty, na przykład, pacman, albo packer. Dla zdecydowanej większości tych zapytań istnieje odpowiedź domyślna – można ją wybrać, wciskając, po prostu, [Enter], bez potrzeby podawania, symbolizującego ją znaku, mimo że zawsze pojawia się on w podpowiedzi, a dodatkowo, zapisany jest wielką literą – to, właśnie, dzięki tej cesze, możemy określić, która z dostępnych odpowiedzi, jest tą domyślną. Nic, oczywiście, nie stoi na przeszkodzie, by zawsze używać sposobu "tradycyjnego" ([znak] + [Enter]), bez względu na to, którą odpowiedź chcemy wybrać.

Spójrzmy, zatem, na ostatnio wykonywaną operację, w trakcie której zadane zostało pytanie:

[code=]Kontynuować instalację? [T/n][/code]

W tym przypadku, odpowiedź twierdząca jest domyślną – stąd literka [T], a nie [t]. Oznacza to, że naciskając sam [Enter] (bez wpisywania [t] i [n]), zgodzimy się na kontynuowanie instalacji.

Warto zwracać uwagę nie tylko na same pytania, ale także na to, jak wyglądają, zamieszczone za nimi, podpowiedzi, by czasem, z rozpędu, nie zatwierdzić odpowiedzi odwrotnej do żądanej.

Ze względu na to, że pacman nie będzie już aktualizowany w ramach upgrade'u systemu, wraz z innymi pakietami, trzeba teraz wykonać dwie czynności, które – w przypadku Bridge'a 2012.5 – będą miały miejsce, dopiero po zakończeniu aktualizacji.

Zgodnie z planem, przystąpmy, zatem, do ustanowienia keyringa. W tym celu, wykonujemy:

[code=]pacman-key --init[/code]

Operacja ta zajmie nieco czasu, ale nie ma powodów do niepokoju – to, po prostu, musi trochę potrwać. Na koniec, jeżeli wszystko przebiegnie bez problemów, ujrzymy następujący obraz:

Po utworzeniu keyringa przyjdzie pora na jego instalację i wypełnienie odpowiednimi kluczami. Wykonujemy, zatem:

[code=]pacman-key --populate archlinux[/code]

W praktyce, wygląda to, mniej-więcej, w ten sposób:

Powyższe zrzuty nie prezentują, oczywiście, całości procesu wypełniania keyringa danymi, a jedynie jego rozpoczęcie i zakończenie. Na ich przykładzie, jednak, wyraźnie widać, że jest to działanie interaktywne i wymaga, by użytkownik, oddzielnie dla każdego klucza, wyraził zgodę na jego podpisanie.

Po trzecie, wykonujemy upgrade systemu, czyli uruchamiamy:

[code=]pacman -Su[/code]

lub (na wypadek, gdyby, w międzyczasie, zawartości repozytoriów uległa zmianom):

[code=]pacman -Syu[/code]

Oczywiście, możliwe jest również przeprowadzenie aktualizacji systemu za pomocą packera. Bezpieczniejszym, jednakże, rozwiązaniem – zwłaszcza dla początkujących użytkowników – jest, zgodnie z radą Daltona Millera (twórcy i developera Bridge'a), użycie pacmana. Niemniej, nie oznacza to, że zupełnie pominiemy packera, że nie będziemy z niego, w ogóle, korzystać. Przeciwnie – po zakończeniu upgrade'u pakietów z oficjalnych repozytoriów Archa, zajmiemy się także tymi z AUR‑a. Zaznaczyć, przy tym, trzeba, że taka, właśnie, kolejność aktualizacji jest najbardziej logiczna – chroni przed instalacją, nie zawsze najnowszych wersji programów (pakietów) z repozytorium użytkowników.

Skoro wiemy już, co, kiedy i jak trzeba robić, najwyższa, zatem, pora przystąpić do dzieła:

Jak widać na powyższym zrzucie, menadżer, tuż przed rozpoczęciem aktualizacji, zadaje kilka pytań dotyczących zamiany niektórych pakietów. Wynika to z faktu, że Arch, podobnie, jak inne dystrybucje, nie "stoi w miejscu", ale rozwija się i zmienia, a przeobrażeniom tym podlega także podstawowe oprogramowanie, co może być następstwem różnych sytuacji, np., połączenie się projektów, porzucenie projektu, pojawienie się nowego, lepszego rozwiązania etc. Na pytania, o których była tu mowa, powinniśmy, zatem, odpowiedzieć twierdząco – w przeciwnym, bowiem, wypadku może dojść tego, że w systemie pozostaną przestarzałe i zdezaktualizowane pakiety, pozbawione wsparcia.

Po tym, pacman wyświetli listę wszystkich, przeznaczonych do aktualizacji, pakietów:

Wyrażenie zgody (wystarczy nacisnąć [Enter]) na kontynuowanie instalacji, sprawi, że pacman zacznie pobierać nowe wersje pakietów – operacja ta zajmie trochę czasu, warto, więc, uzbroić się w cierpliwość... chociaż, niestety, efekt końcowy nie będzie satysfakcjonujący:

Jak widać, jeden z pakietów (a konkretnie – filesystem), nie ma ochoty poddać się aktualizacji i znowu trzeba uciec się do niewielkiego tricku. Wykonujemy, zatem:

To spowoduje, że zaktualizują się wszystkie pakiety, poza, "stawiającym opór", filesystemem.

Zauważmy, że żadne pakiety nie są, tym razem, pobierane, a pacman, wykorzystując te dane, które "ściągnął z netu" poprzednio, od razu przystępuje do instalacji nowych pakietów. Zmiany, jakie zachodzą w repozytoriach Archa oraz ich dynamika, powodują, że całkiem pokaźna ilość pakietów wymaga upgrade'u i musi on, siłą rzeczy, zabrać trochę czasu – dlatego, cierpliwość będzie znów, bardziej, niż wskazana :–):

Po tym, gdy pacman zainstaluje ostatni z pakietów, nadejdzie pora na to, by zająć się kwestią, pominiętego wcześniej, filesystemu. Istnieje, oczywiście, sposób, by uaktualnić ten pakiet, ale najpierw, musimy przyjrzeć się plikom, które uniemożliwiły jego upgrade, od ich, bowiem, typu zależy rodzaj działań, jakie należy podjąć. Dla przypomnienia, pliki te, to:

[code=]/var/lock[/code]

oraz

[code=]/var/run[/code]

Zajrzyjmy, zatem, do katalogu /var:

Obydwa pliki, jak widać, to dowiązania symboliczne – powinno, zresztą, tak być w większości przypadków. W takiej sytuacji, nie pozostaje nic innego, jak wymusić instalację, sprawiającego problem, pakietu, czyli wykonać:

[code=]pacman -S filesystem -‑force[/code]

lub

[code=]pacman -Sf filesystem[/code]

Po zakończeniu tej operacji, wskazane jest, ponownie uruchomić komputer.

Jeśli, natomiast, zdarzyłoby się, iż /var/lock oraz /var/run byłyby zwykłymi katalogami, jak, np., /var/cache, czy /var/empty – należałoby wówczas wykonać:

[code=]rm -rf /var/run /var/lock[/code]

Następnie:

[code=]pacman -Syu[/code]

I na koniec, podobnie, jak w poprzednim przypadku, zresetować komputer.

Zgodnie z tym, o czym pisałem na wstępie, Bridge, oprócz pakietów z repozytoriów oficjalnych, domyślnie instaluje także kilka, które pochodzą z AUR. Stąd, jeżeli chcemy dokonać absolutnie pełnej aktualizacji systemu, musimy również zająć się oprogramowaniem nieoficjalnym, a więc, skorzystać z packera. Wykonujemy, zatem, w konsoli:

[code=]packer -Syu[/code]

Uwaga!  Jeszcze raz przypominam, że packera należy uruchamiać na prawach zwykłego użytkownika (proszę nie sugerować się tym, że w przypadku opisywanej tu instalacji, postąpiono inaczej)!

W praktyce, wygląda to następująco:

Jak widać, spośród dziesięciu, zainstalowanych z AUR, pakietów, cztery wymagają upgrade'u. Zgadzamy się, by packer kontynuował instalację (wystarczy nacisnąć [Enter]) i przystępujemy do aktualizacji:

Ze względu na to, że packer został uruchomiony bez parametru --noedit, będzie oferował, przy każdym instalowanym pakiecie, możliwość edytowania pliku PKGBUILD – jeżeli nie chcemy z tego korzystać, musimy, za każdym razem, nacisnąć [n] oraz [Enter]. Łatwiej, więc, po prostu, uruchomić program z parametrem --noedit:

[code=]packer -Syu --noedit[/code]

W opisywanej tu, przykładowej instalacji, nie skorzystałem, jednak z tego wariantu.

W kolejnym kroku, packer pobierze właściwe dane i zacznie tworzyć (kompilować) odpowiedni pakiet, który zainstaluje, wywołany przez niego, pacman (tak, tak, także w przypadku instalacji pakietów z AUR, packer korzysta z pacmana).

No zakończenie, resetujemy komputer:

a po kolejnym jego uruchomieniu, cieszymy się w pełni aktualnym oprogramowaniem.

Bridge Linux 2012.5

W porównaniu z wersją 2012.4, aktualizacja najnowszego wydania Bridge'a, jest prostsza i – co oczywiste – trwa znacznie krócej, a wynika to, między innymi, stąd, że mniej pakietów wymaga upgrade'u. Naturalnie, kilka działań przebiegać będzie w zbliżony, czy nawet identyczny sposób, jak wcześniej, a być może zaistnieje też konieczność skorzystania z podobnych rozwiązań i/lub tricków... ale, nie uprzedzając faktów, przejdźmy do omawiania konkretów...

Analogicznie, jak w przypadku wcześniejszego wydania dystrybucji, po – mam nadzieję, łatwej, szybkiej i bezbłędnej instalacji oraz bezproblemowym starcie nowego systemu – uruchamiamy konsolę, a w niej – przechodzimy na konto roota:

Następnie, identycznie, jak w przypadku Bridge'a 2012.4, rozpoczynamy aktualizację software'u z repozytoriów oficjalnych i – tak samo, jak w tamtym wydaniu – zaraz na początku, pojawia się sugestia, by w pierwszej kolejności przeprowadzić upgrade samego pacmana:

Oczywiście, zgadzamy się na to, a następnie – na kontynuowanie instalacji i...

o dziwo, nowa wersja pacmana oraz pakiet archlinux-keyring instalują się bez problemów:

Po zakończeniu instalacji – zgodnie z wyświetloną na koniec, podpowiedzią – wykonujemy:

[code=]pacman-key --init[/code]

oraz:

[code=]pacman-key --populate archlinux[/code]

Jak widać, dwie ostatnie czynności są identyczne, jak te, wykonywane w wydaniu 2012.4, zaraz po (w tamtym wypadku – "ręcznej") instalacji pacmana.

Uwaga!  Dla przypomnienia: proszę zauważyć, że każdy z kluczy podpisywany jest oddzielnie, a zgodę na to, każdorazowo, wyraża się poprzez naciśnięcie [t] oraz [Entera]!

Ponieważ poprzednio uruchomioną aktualizację systemu przerwaliśmy, by móc przeprowadzić upgrade menadżera pakietów, teraz musimy rozpocząć ją ponownie. Uruchamiamy, zatem:

[code=]pacman -Syu[/code]

Tym razem, jak widać na zamieszczonym poniżej zrzucie, pacman przedstawi wykaz pakietów, wymagających aktualizacji i będzie oczekiwać na jej zatwierdzenie (lub zaniechanie). Zgadzamy się, oczywiście, na przeprowadzenie tej operacji i naciskamy [Enter] (lub [t] i [Enter]):

Niestety, w Bridge'u 2012.5 – podobnie, jak w przypadku wcześniejszego wydania – istnieje też problem z aktualizacją pakietu filesytem.

Skoro mamy do czynienia z identycznym problemem, najskuteczniejsze będzie użycie takich sposobów, które sprawdziły się już w jego rozwiązywaniu. Na początek, wykonujemy, zatem, aktualizację z pominięciem problematycznego pakietu:

Raz jeszcze wyrażamy zgodę na zastąpienia niektórych pakietów, po czym, ujrzymy spis tych elementów, które mają zostać poddane aktualizacji:

Zezwalamy, rzecz jasna, na to, by pacman kontynuował instalację nowych pakietów, po czym, uzbrojeni w cierpliwość, oczekujemy na zakończenie tej operacji.

Gdy czynności instalacyjne i aktualizacyjne zakończą się sukcesem, sprawdzamy – podobnie, jak miało to miejsce w przypadku Bridge'a 2012.4 – co zawiera katalog /var:

Następnie – w zależności od tego, czy /var/lock oraz /var/run są katalogami, czy dowiązaniami symbolicznymi – podejmujemy odpowiednie działania (ich pobieżny opis znajaduje się wyżej, w części, dotyczącej Bridge'a 2012.4):

W tym momencie warto zresetować komputer, a po ponownym uruchomieniu systemu, trzeba jeszcze zająć się aktualizacją pakietów z AUR. W tym celu, ponownie, uruchamiamy konsolę i wykonujemy (z konta i na prawach zwykłego użytkownika):

[code=]packer -Syu[/code]

lub – jeśli nie chcemy edytować PKGBUILD'ów:

[code=]packer -Syu --noedit[/code]

Jak widać, w Bridge'u 2012.5 domyślnie zainstalowanych jest mniej pakietów z AUR, bo jedynie siedem, a nie, jak w wersji 2012.4 – dziesięć. Dwa, spośród nich, wymagają upgrade'u, na który wyrażamy, oczywiście, zgodę:

Po skompilowaniu i instalacji ostatniego z pakietów, Bridge będzie w pełni zaktualizowany, aż do momentu, gdy w repozytoriach nie pojawią się nowe wersje software'u. Stąd, dobrym nawykiem jest sprawdzanie stanu repozytoriów: "ręcznie", używając w konsoli pacmana / packera, albo za pomocą innego, odpowiedniego oprogramowania i dbanie, by system zawsze był "up to date".

Operacja: "Polski Most", czyli polonizujemy Bridge'a.

Wypowiedzi pisane mają, niestety, to do siebie, że ich autorom jest niezwykle trudno wykpić się z popełnionych błędów merytorycznych lub nieścisłości, czy też różnych lapsusów językowych i chochlików, szczególnie, że czytelnicy, mając wszystko czarno na białym, mogą, z łatwością, wytykać i piętnować wszystkie takie "wpadki". Zdesperowany "mówca" może, w ostateczności, próbować wyprzeć się swoich słów, stwierdzając: "Nie, ja tego nie powiedziałem!", tymczasem, "pisarz", z takiej ewentualności skorzystać, po prostu, nie może.

Uwzględniając powyższe relacje pomiędzy prawami czytelników i powinnościami autorów, tym bardziej czuję się w obowiązku, aby w ramach odpowiedzialności za własne słowa, sprostować jedną z moich wcześniejszych wypowiedzi, która jest bezpośrednio związana z omawianą dziś tematyką. Wszakże, przyznanie się do winy jest połową przebaczenia...

W poprzedniej części, fragment, który opisuje modyfikacje pliku /etc/locale.gen, zatytułowałem:

Stuprocentowo pewne i prawdziwe jest w nim to, że wprowadzenie zmian w powyższym pliku, doprowadzi do spolszczenia "nie-graficznej" części systemu (np., komunikatów w konsoli); nie do końca, natomiast, słusznie, tytuł ten sugeruje, że poprawki w pliku /etc/locale.gen nie wywrą żadnego wpływu na lokalizację środowiska graficznego.

Jak, zatem, można się domyślać, czynności, które, w przypadku Bridge'a, prowadzą do pełnej zmiany języka, zależne są od jego wydania.

Na początek, przypomnijmy sobie, jakie zabiegi konfiguracyjne, mające na celu spolonizowanie systemu, wykonywaliśmy podczas instalacji:

[item]po pierwsze, w zakresie lokalizacji, doprowadziliśmy plik /etc/rc.conf do postaci:[/item]

[code=]# LOCALIZATION # ---‑-------- HARDWARECLOCK="UTC" TIMEZONE="Europe/Warsaw" KEYMAP="pl" CONSOLEFONT= CONSOLEMAP="pl" LOCALE="pl_PL.UTF-8" DAEMON_LOCALE="yes" USECOLOR="yes"[/code]

[item]po drugie, w /etc/X11/xorg.conf.d/01-keyboard-layout.conf ustawiliśmy "polską" klawiaturę:[/item]

[code=]Section "InputClass" Identifier "keyboard-layout" Driver "evdev" MatchIsKeyboard "yes" Option "XkbLayout" "pl" EndSection[/code]

[item]po trzecie, w /etc/locale.gen aktywowaliśmy polską lokalizację:[/item]

[code=](...) pl_PL.UTF-8 UTF‑8 pl_PL ISO‑8859-2 (...)[/code]

i – opcjonalnie – "wyłączyliśmy" język angielski:

[code=]#en_AG UTF‑8 #en_AU.UTF-8 UTF‑8 #en_AU ISO‑8859-1 #en_BW.UTF-8 UTF‑8 #en_BW ISO‑8859-1 #en_CA.UTF-8 UTF‑8 #en_CA ISO‑8859-1 #en_DK.UTF-8 UTF‑8 #en_DK ISO‑8859-1 #en_GB.UTF-8 UTF‑8 #en_GB ISO‑8859-1 #en_HK.UTF-8 UTF‑8 #en_HK ISO‑8859-1 #en_IE.UTF-8 UTF‑8 #en_IE ISO‑8859-1 #en_IE@euro ISO‑8859-15 #en_IN UTF‑8 #en_NG UTF‑8 #en_NZ.UTF-8 UTF‑8 #en_NZ ISO‑8859-1 #en_PH.UTF-8 UTF‑8 #en_PH ISO‑8859-1 #en_SG.UTF-8 UTF‑8 #en_SG ISO‑8859-1 #en_US.UTF-8 UTF‑8 #en_US ISO‑8859-1 #en_ZA.UTF-8 UTF‑8 #en_ZA ISO‑8859-1 #en_ZM UTF‑8 #en_ZW.UTF-8 UTF‑8 #en_ZW ISO‑8859-1[/code]

Dlaczego zwracam na to tak szczgólną uwagę?

Wymienione wyżej czynności sprawią, że w terminalu, Bridge Linux zacznie "mówić" po polsku (bez względu na to, czy używać będziemy KDE, GNOME. LXDE, Xfce, Openboksa). Również większość środowisk graficznych, choć nie wszystkie, akceptuje tę konfigurację, uznając ją za własne preferencje lokalizacyjne (stąd, przełączenie w nich języka, na polski, nie jest związane z koniecznością instalacji dodatkowych pakietów, a jeżeli w /etc/locale.gen skonfigurowana jest wyłącznie polska lokalizacja – nie ma nawet potrzeby modyfikowania ustawień językowych, bo system jest spolszczony, od razu, przy pierwszym uruchomieniu z twardego dysku). Na dobrą sprawę, jedynie KDE wymaga kilku, dodatkowych zabiegów polonizacyjnych, a ponadto, każdy program, który nie jest rozwijany w ramach żadnego ze środowisk graficznych, np., LibreOffice.

Przyjrzyjmy się, więc, jak to wygląda w praktyce...

Zakładając, że w trakcie instalacji Bridge'a, lokalizacja systemu została skonfigurowana według, zamieszczonego wyżej, opisu, a w pliku /etc/locale.gen, ustawiony jest, wyłącznie, język polski, po wcześniejszym resecie komputera (z konta roota lub poprzez sudo), bądź bezpośrednio, po zakończeniu aktualizacji, w przypadku KDE, wydajemy, w konsoli, polecenie:

[code=]pacman -S kde‑l10n-pl libreoffice.pl[/code]

i, oczywiście, potwierdzamy, naciśnięciem [Entera].

Po instalacji kde-l10n-pl i libreoffice.pl, uruchamiamy System Settings (Ustawienia systemowe), a w nich, wybieramy ikonkę Locale (Ustawienia regionalne):

W okienku Country/Region & Language (Kraj/region i język), uaktywniamy zakładkę Languages (Języki), a następnie, na liście dostępnych języków Available Languages, po lewej stronie okna, zaznaczamy Polski i, za pomocą, umieszczonej pośrodku, ikonki ze strzałką, bądź dwuklikiem, przerzucamy wybrany język do listy Preffered Languages (Preferowane języki):

Jeżeli wszystko przebiegło zgodnie z powyższym planem, pozostaje zatwierdzić zmiany, przy użyciu, znajdującego się w prawym, dolnym rogu, przycisku Zastosuj i potwierdzić komunikat, między innymi, o tym, że wprowadzone zmiany zadziałają, w pełni, po ponownym zalogowaniu do KDE:

Rzućmy jeszcze, na koniec, okiem, jak wygląda spolszczenie LibreOffice'a:

I można wylogować się z KDE lub, po prostu, ponownie uruchomić komputer:

Wykonanie, opisanych wyżej czynności, doprowadzi do niemal całkowitego spolszczenia KDE. Niestety, nawet, mimo dużej staranności, z jaką zainstalujemy odpowiednie pakiety i dokonamy wymaganych zmian w ustawieniach – jeden z elementów środowiska, a konkretnie, kdm (KDE Display Manager), pozostanie nadal w wersji angielskiej...

Dlaczego?

Wynika to, z istniejącego w kdm buga w zakresie obsługi lokalizacji, a cały problem sprowadza się do tego, iż zmiana, w ustawieniach systemowych, języka okna logowania na polski, wydaje się być całkowicie ignorowana przez menadżera wyświetlania. Dzieje się tak, ponieważ w pliku /usr/share/config/kdm/kdmrc, w przypadku wyboru języka polskiego, w miejsce "pl_PL.UTF-8", znajduje się samo "pl". Cała reszta jest już logiczna i prosta: kdm, nie rozpoznawszy lokalizacji, ustawia w oknie logowania domyślny język angielski.

I choć dla sporej, jak mi się wydaje, grupy użytkowników, a zwłaszcza tych, którzy korzystając z KDE, włączają auto-logowanie, opisywany błąd, nie będzie mieć jakiegokolwiek znaczenia, to jednak warto poznać sposób jego ominięcia, tym bardziej, że wcale nie jest to trudne.

Uruchamiamy, zatem, konsolę, a w niej, po przejściu na konto roota lub używając sudo w trybie zwykłego użytkownika, np., przy pomocy nano, otwieramy plik /usr/share/config/kdm/kdmrc:

Następnie, tak, jak pokazuje to powyższy zrzut, odnajdujemy linię tekstu, w której zapisany jest język okna logowania, czyli, konkretnie, fragment:

[code=][X-*-Greeter] (...) Language=pl (...)[/code]

i nanosimy stosowną poprawkę:

[code=][X-*-Greeter] (...) Language=pl_PL.UTF-8 (...)[/code]

Zapisujemy, wprowadzone do pliku zmiany ([ctrl] + [o]) i wychodzimy z nano ([ctrl] + [x]), a przy ponownym uruchomieniu systemu, okno logowania będzie wyglądać następująco:

Należy, ponadto, pamiętać o tym, by "poprawić" plik /usr/share/config/kdm/kdmrc, zawsze, gdy dokonamy zapisu zmian konfiguracji ekranu logowania w Ustawieniach systemowych, pomimo tego, że w związku z naszą ręczną modyfikacją, język będzie wyświetlany tu nieprawidłowo:

W tym miejscu chciałbym bardzo podziękować mojemu Drogiemu Koledze, Slawulowi, za to, że uświadomił mi istnienie błędu w kdm i podpowiedział, w jaki sposób można sobie z nim poradzić. Wielkie dzięki, Mistrzu! ;–)

...a co z osobami, które nie korzystają z KDE?

W związku, z przyjętymi wyżej, założeniami, jeżeli używamy Bridge'a z GNOME 3 / Cinnamon, LXDE, Xfce lub Openboksem, nie musimy nic więcej robić, a cały system będzie, w mniejszym lub większym stopniu, spolszczony – niestety, z uwagi na to, iż "od zawsze" korzystam z KDE, nie za szczególnie znam inne środowiska; stąd, nie jest mi wiadomo, czy istnieje jakaś metoda, aby zwiększyć stopień ich spolszczenia (zwłaszcza, Openboksa), niż to, co miałem możliwość zobaczyć, instalując poszczególne wersje Bridge'a:

[item]Xfce:[/item][image=BLPic146][join][image=BLPic147]

[item]GNOME 3 (Shell):[/item][image=BLPic148][join][image=BLPic149]

[item]Cinnamon:[/item][image=BLPic150][join][image=BLPic151]

[item]LXDE:[/item][image=BLPic152][join][image=BLPic153]

[item]Openbox:[/item][image=BLPic154][join][image=BLPic155]

W przypadku innych, niż KDE, środowisk graficznych, uruchomienie polskiej lokalizacji jest, jak widać, o wiele prostsze, bo nie wymaga wykonywania żadnych, dodatkowych czynności, poza, mającym miejsce w trakcie instalacji Bridge'a, odpowiednim skonfigurowaniem systemu.

To już, naprawdę, koniec.

W związku z tym, iż niniejszy wpis jest ostatnią częścią serii o instalacji Bridge'a, chciałbym raz jeszcze podziękować tym, którzy przeczytali wszystkie poprzednie i, mimo sporego opóźnienia w publikacji bieżącego odcinka, nadal byli zainteresowani zajrzeniem do niego. Bardzo dziękuję!

Pragnę również wyrazić nadzieję, że swoim dotychczasowym blogowaniem o Bridge'u udało mi się przybliżyć tę dystrybucję i nieco ją wypromować, a seria o instalacji, okazała się (i okaże się jeszcze nie raz) pomocna osobom zdecydowanym zainstalować dystro, chociażby na próbę.

Oczywiście, zakończenie niniejszej serii, nie oznacza, że na moim blogu przestaną pojawiać się wpisy o Bridge Linuksie, ale nie będą to już, najprawdopodobniej, kilkuodcinkowce (chociaż, tego też nie mogę wykluczyć). Mam już nawet parę nowych pomysłów, które chciałbym zrealizować, o ile, oczywiście, nie zostanę zlinczowany w komentarzach poniżej... :–)