pavbaranov Arch

Nie pamiętam już jak długo jestem czynnym uczestnikiem różnego rodzaju forów internetowych dotyczących linuksa. W niektórych uczestniczę w istocie czynnie, inne jedynie przeglądam. Na jednych byłem, na innych jestem teraz. I... i bardzo bym chciał, by tym doradzającym przyświecała tytułowa, łacińska zasada. Medyczna przede wszystkim, ale chyba wszyscy winni sobie ją wziąć do serca i stosować w dowolnej dziedzinie, w której chcą komuś radzić. Do napisania mnie tego felietonu  zainspirowały mnie farmazony znalezione w pewnym  wątku na pewnym forum . Kompletny brak zrozumienia podstaw używanego przez siebie systemu, kompletny brak zrozumienia jego odmienności od innego, spowodował, że dobrą  :) poradą stało się dostarczenie systemowi repozytorium dla innego systemu. W tym przypadku jest to tzw. nieoficjalne repozytorium dla Archa, które ktoś proponuje używać w Manjaro, ale problem dotyczy również repozytoriów/paczek Ubuntu w Debianie (czy odwrotnie) itp. Można tych przykład...

Załóżmy hipotetycznie, że opiekunowie paczek z AUR wywiązują się ze swoich (w dodatku przez samych siebie na siebie nałożonych) obowiązków w sposób celujący, a porzucone oprogramowanie w AUR nie istnieje. Załóżmy nawet, że dotyczy to wyłącznie tych paczek, które z AUR używamy. Przyjęcie takiego założenia oznacza, że nowe PKGBUILDy w AUR będą się pojawiać w przynajmniej dwu sytuacjach: - albo oprogramowanie pojawi się w nowszej wersji, - albo zaistnieje konieczność przebudowania oprogramowania niezależnie od wersji. Zastanówmy się teraz przez chwilę jak budowane jest jakiekolwiek oprogramowanie ze źródeł. Otóż oprócz nielicznych wyjątków (np. słynne update-grub, które jest po prostu plikiem wykonywalnym powłoki zasadniczo z jedną linijką polecenia), wszystkie inne mają jakieś zależności. W dodatku dwojakiej postaci. Jedne są to zależności służące wyłącznie do zbudowania paczki. W późniejszym działaniu programu nie są one konieczne. Drugie uczestniczą zarówno w budowie, jak i...

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

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

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

To krótka przypowieść, jaka naszła mnie po lekturze dwu poradników o instalacji w Manjaro GIMP a oraz LibreOffice ze źródeł. Teksty są bliźniacze, a ich główną tezę można sprowadzić do stwierdzenia: zbudować program i zainstalować poprzez sudo make install . Skoro jest głupia porada, to wymaga jakiejś riposty. Pominę sens budowania programów, które są w repozytoriach, zwłaszcza, że autor nie zaciekawił się opcjami kompilacji, które najczęściej w ogóle przemawiają za podjęciem tego trudu. Pominę też rozważania, czy istotnie dla systemu dobrym jest dostosowanie pod określony procesor zaledwie jednego, czy dwu programów, a nie całego systemu. Można mieć na ten temat bardzo różne zdania, a chętnych odsyłam do wiedzy tych, którzy na kompilacji zęby zjedli, czyli kolegów od Gentoo . Interesuje mnie zgoła co innego. Zastanówmy się wpierw nad owym magicznym sudo make install (oczywiście, o ile autor kodu dostarczył ich reguły, co regułą nie jest). Przed jego wydaniem, program zasadniczo z...

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

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

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

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

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.

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

Pytanie wydaje się być trywialne. Przecież wszyscy wiemy (oczywiście na podstawie Archa): # pacman -S nazwa_pakietu Czyżby? Cóż doczytaliśmy się jednej informacji, ale pominęliśmy inne. Oczywiście, że powyższe polecenie zainstaluje pakiet. Całkiem możliwe, że aplikacja będzie działać. Niemniej jednak pozwolę sobie zauważyć, że posiąwszy powyższą wiedzę nie doczytaliśmy się innej informacji: częściowa aktualizacja nie jest przez pacman wspierana . Zaraz pewnie usłyszę: co ma aktualizacja, w dodatku częściowa do instalacji pakietu. Ano ma. Przyglądnijmy się na początek co zawierają repozytoria Archa. Trywialnie możemy odpowiedzieć: paczki. Tylko, że w przeciwieństwie do dystrybucji wydawniczych, są one "w ciągłym ruchu". Arch linux zainstalowany miesiąc temu nie będzie tym samym systemem, który zainstalowaliśmy dzisiaj i to nawet jeśli w obu wprowadzimy te same pakiety, albowiem nie będą one - przynajmniej w części - te same, ale takie same. Nazwa będzie taka sama, ale już w...

Niekiedy czytamy, że coś możemy zainstalować w Archu poprzez instalację paczki coś-meta. Ot, choćby instalację środowiska graficznego od KDE możemy przeprowadzić w następujący sposób: Install the  plasma-meta  meta-package or the  plasma  group. Istnienie dwu sposobów instalacji (a w zasadzie jeszcze większej ilości) jak zwykle powoduje niezrozumienie i konsternację, choć cała sprawa jest oczywiście wyjaśniona . Mimo tego, spróbuję ją wyjaśnić raz jeszcze. Opiekun jakichś paczek w Archu może stworzyć grupę paczek. Taką grupą jest wspomniana wyżej plasma. Grupa nie jest żadną oddzielną paczką, a jedynie pewnym ułatwieniem dla użytkowników, deklarowanym w PKGBUILD w polu groups . Każda paczka składająca się na daną grupę otrzyma w tym polu deklarację do jakiej grupy paczek należy. Tym samym np. paczka plasma-desktop  czy breeze  otrzymają w tym polu deklarację, że należą one do grupy paczek o nazwie plasma . Grupę taką łatwo możemy podglądnąć, wydając po...

Pamiętam czasy, kiedy obok systemu w komputerze, wiele osób miało dyskietkę ratunkową. Kiedy coś się podziało z systemem, umożliwiała jakiś dostęp do komputera, możliwość naprawy systemu. Zamierzchłe czasy. Im bliżej czasów współczesnych, tym bardziej wielu użytkowników wyzbyło się tej zaradności, która niegdyś powodowała, że system po prostu działał. Teraz system ma działać. Nie ważne co z nim zrobię, do jakiego stanu doprowadzę - on ma działać. Przewidzieć niemal każdą destrukcję, jaką jestem w stanie mu zaserwować - i tak ma działać. Jeśli nie działa, to winna jest zawsze jakaś osoba trzecia. W systemach, które oparte są w dużej mierze na współdziałaniu społeczności, które tworzą różnego rodzaju formuły społecznościowych porad, w takich systuacjach najczęściej pojawia się żądanie takich osób wobec społeczności, by naprawić im to, co sami najczęściej sami zepsuli. Nie mam nic przeciwko temu, bowiem co do zasady, m.in. na tym opiera się istnienie owych społecznościowych systemów. Każd...

Jak niemal wszyscy doskonale wiemy, w Archu istnieje AUR, zawierający "paczki", których nie ma w repozytoriach oficjalnych. Akronim tłumaczy się jako Arch User Repository. Tylko, że w przeciwieństwie do "normalnych" repozytoriów znanych z innych, mainstreamowych dystrybucji, w AUR nie spotkamy paczek binarnych, gotowych do zainstalowania w systemie, a jedynie "przepisy" na ich lokalną (na komputerze użytkownika) budowę. W AUR znajdują się zatem wyłącznie pliki automatyzujące kompilację jakiegoś programu i tworzące z niego paczkę rozpoznawalną przez pacmana, która może być następnie przez niego zarządzana. Arch zaleca, by korzystanie z AUR odbywało się w nastąpujący sposób: ściągnięcie tzw. tarballa ze źródłami, bądź obecnie - sklonowanie ich repozytorium z GIT, przejście do katalogu z PKGBUILD (po ewentualnym wcześniejszym rozpakowaniu źródeł), wydanie polecenia makepkg z odpowiednimi przełącznikami, instalacja paczki (oczywiście można to wykonać w ...

Pacman - przynajmniej wg mnie - jest bardzo dobrym menedżerem pakietów. Jest też - za pomocą pliku /etc/pacman.conf - dość konfigurowalny. Jedną z opcji, jaką możemy tam ustawić, jest ignorowanie aktualizacji paczki. Za funkcję tą odpowiada pole IgnorePkg. Tu możemy wpisywać nazwy paczek, których nie chcemy aktualizować. Teraz muszę coś przypomnieć. Arch Linux jest tak pomyślany, że domyślnym i jedynie wspieranym sposobem aktualizacji, jest aktualizacja globalna. Aktualizujemy zatem cały system, a nie poszczególną paczkę. Także do wyjątków winna należeć systuacja, w której aktualizacja systemu nie obejmuje jakiejś paczki. O prawidłowość działania tego mechanizmu dbają opiekunowie systemu. Czasem jest lepiej - czasem gorzej, ale zaangażowania w prawidłowość działania systemu jako całości, nie możemy odmówić. Powrócę zatem do ignorowania aktualizacji poszczególnej paczki. Jak wspomniałem należy to traktować jako wyjątek. Systemu z niezaktualizowaną paczką opiekunowie Archa nie przewid...

Wraz z wprowadzeniem nowej wersji dbus (na pewno dotyczy wersji 1.10.10) przestały się uruchamiać programy z graficznym interfejsem użytkownika z uprawnieniami root. Problem dotyczy np. Plasmy oraz MATE i Cinnamona (nie wiem, czy innych środowisk również, ale nie wydaje mi się, by był im obcy). W przypadku uruchamiania bezpośrednio ze środowiska zobaczymy wyłącznie, że program chce się uruchomić (np. "skaczący" kursor), ale ostatecznie nie uruchamia się, a uruchamiając (przez sudo) w konsoli otrzymamy informację: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)" Oczywiście można twierdzić, że programy GUI w ogóle nie powinny być uruchamiane na uprawnieniach administratora, niemniej jednak nie jest to rozwiązanie. Niekiedy tego typu programy po prostu są wygodniejsze. Do czasu, gdy problem nie zostanie rozwią...

No właśnie: instalujemy? Ten wpis nie będzie w ogóle o tym, jak tego dokonać (jest to opisane w wiki Archa dość dokładnie), ale o tym, czy w ogóle warto to robić, kiedy i jakie niesie konsekwencje. Lektura różnych forów czy blogów związanych z Archem, Manjaro i innymi dystrybucjami korzystającymi z rodowodu Archa pozwala na stwierdzenie, że niektóre osoby, w określonych sytuacjach, mają chęć dodawania do pacman.conf wpisów do tzw. nieoficjalnych repozytoriów. Tych ostatnich cała masa. Kusi i nęci zatem zamiast budowania czegoś ze źródeł korzystając z PKGBUILDu szybka instalacja programu z repozytorium. Fakt, jest to dobre rozwiązanie, szczególnie dla programów, które się kompilują wieczność. Fakt, ale wyłącznie wówczas, gdy mamy zaufanie do twórcy i opiekuna takiego repozytorium. Czy jest to jednak dobre rozwiązanie? Powiedzmy tak: i tak i nie. Dla świadomego użytkownika - jak najbardziej. Zwykle bowiem wie jakie i dlaczego repozytorium dodał, co chciał w ten sposób osiągnąć i przed...