sobota, 19 listopada 2016

Nadchodzi KDE-Applications 16.12

Wczoraj udostępnione zostały wersje beta (16.11.80) aplikacji, które składać się będą na nową odsłonę KDE Applications. W Archu właśnie są budowane i prawdopodobnie jeszcze dzisiaj trafią do repozytorium kde-unstable. Oczywiście tych, którzy mogą zachęcam do testowania, albowiem m.in. w ten sposób możemy pomóc arojasowi w ich prawidłowym paczkowaniu, a zespołowi KDE w usunięciu ewentualnych błędów jeszcze przed wydaniem, które jest oczekiwane 15.12.2016. W międzyczasie, 1.12. winno się jeszcze ukazać wydanie RC (16.11.90).
Nowe aplikacje niosą w sumie spore zmiany. Nie będę pisał o tym, co zostało przeportowane na KF5, bowiem z punktu widzenia "zwykłego" użytkownika ma to najmniejsze znaczenie. Istotne natomiast jest, że niektóre aplikacje nie będą kontynuowane, zmienił się również proces paczkowania niektórych.
Zacznijmy od tego co nie będzie już kontynuowane. Z KDE Apps wypadają zatem:

  • kde-baseapps; ta grupa paczek istniejąca co najmniej od czasów KDE4 (sorry, pamięć już nie ta, by pamiętać wcześniej) została wydzielona do odrębnych aplikacji. Są to: kdialog, keditbookmarks, kfind, konqueror. Pamiętajmy, że wcześniej wydzielony został również dolphin. Spośród aplikacji, które składały się na dawne kde-baseapps nie będzie już kontynuowane kdepasswd; prawdopodobnie deweloperzy doszli do wniosku, że istniejące narzędzia w systemie są wystarczające, a kdepasswd jedynie je dubluje.
  • kdepim; podobnie jak w przypadku kde-baseapps nie oznacza to, że KDE Apps 16.12 nie będzie mieć swojego programu typu PIM. Aplikacje dotychczas składajace się na kdepim zostały rozdzielone na samodzielne (to jest kontynuacja tego procesu) i obecnie będą to: akonadi-calendar-tools, akonadiconsole, akonadi-import-wizard, akregator, blogilo, grantlee-editor, kaddressbook, kalarm, kmail, kmail-account-wizard, knotes, kontact, korganizer, mbox-importer, pim-data-exporter, pim-sieve-editor, pim-storage-service-manager.
  • kdewebdev; podobnie jak powyższe - rozbite zostały na oddzielne aplikacje: kfilereplace, kimagemapeditor, klinkstatus, kommander)
  • kdgantt2
  • gpgmepp
  • kuser; znów prawdopodobnie deweloperzy doszli do wniosku, że funkcjonujące rozwiązania są wystarczające, a kuser jedynie niepotrzebnie je dublował.
Spośród powyższych aplikacji kdgantt2 i gpgmepp często stanowiły zależności innych paczek. Osoby, które budują aplikacje we własnym zakresie winny zatem sprawdzić jak obecnie paczki te należy budować. Aplikacje, które zostały porzucone (nie rozbite na odrębne) sensownie jest natomiast odinstalować z systemu. 
Ze względu na spore zmiany jakie zachodzą w KDEPIM, poleciłbym po aktualizacji sprawdzenie, czy na pewno mamy zainstalowane to, czego oczekiwaliśmy. Wprawdzie arojas dba o wszelkie zależności i jak na razie wydaje się, że wszystko odbędzie się bezboleśnie dla użytkownika, jednakże poleciłbym poświęcenie chwili na sprawdzenie.

niedziela, 13 listopada 2016

Zrozumieć niezrozumiałe - korzystanie z AUR helperów

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:

  1. ściągnięcie tzw. tarballa ze źródłami, bądź obecnie - sklonowanie ich repozytorium z GIT,
  2. przejście do katalogu z PKGBUILD (po ewentualnym wcześniejszym rozpakowaniu źródeł),
  3. wydanie polecenia makepkg z odpowiednimi przełącznikami,
  4. instalacja paczki (oczywiście można to wykonać w jednej linii z makepkg).

Jak zatem zauważyliście, cały proces budowy paczki odbywa się zatem na naszym dysku.
Żadne z narzędzi oficjalnie oferowanych w repozytoriach Archa nie potrafi zarządzać przepisami z AUR bezpośrednio. Przyroda nie znosi próżni, a człowiek ma to do siebie, że jeśli może sobie coś ułatwić, to prędzej, czy później tego dokona. Nie inaczej stało się z AUR. Mamy cały wysyp różnych narzędzi, które automatyzują powyższy proces. Chyba najpopularniejszym pozostaje yaourt pomimo wielkiej niechęci do tego narzędzia deweloperów Archa. Programy tego typu zwane są AUR helperami. Ich działanie obejmuje zwykle możliwość przeszukiwania bazy AUR w poszukiwaniu interesującego nas programu, budowę oraz instalację (mniejsza o to, że ostatecznie i tak instaluje taki program pacman) zbudowanej paczki. Na pierwszy rzut oka, wszystkie te programy zachowują się zatem dokładnie tak samo jak pacman, na którego zresztą stanowią swego rodzaju nakładkę, czy też dla którego są pewnym rozszerzeniem.
Proces kompilacji dokonuje dziesiątek odwołań do plików. Jeśli wykonywany jest na dysku typu HDD jest on powolniejszy, zwykle również konsekwencją tych odwołań do dysku jest spowolnienie działania całego środowiska, czy programów. Większość AUR helperów do procesu kompilacji wykorzystuje katalog /tmp. W Archu nie jest to "zwykły" katalog umieszczony na dysku, ale pewna przestrzeń tworzona w RAM. W ten sposób tworzenie paczki jest nie tylko szybsze, ale również oszczędza nam dysk.
Ma to jednak inne konsekwencje.
Podczas budowania paczki ściągane są źródła, następnie tworzone są dwa katalogi src oraz pkg. W następnym kroku źródła są przenoszone do katalogu src, tam rozpakowywane, potem odbywa się proces kompilacji, a następnie zbudowane w jego wyniku skompilowane już składniki aplikacji, są przenoszone do katalogu pkg, który w dalszej kolejności jest pakowany do jakiejś postaci akceptowalnej przez pacmana - najczęściej tar.xz.
Zwróćmy teraz uwagę, że w katalogu, w którym tworzona jest paczka musimy zarezerwować miejsce dla źródeł i to często dwukrotnie, rozpakowanych źródeł, plików tworzonych podczas kompilacji programu oraz będących jej wynikiem plików binarnych, które również wymagają podwójnego miejsca (raz w src drugi raz w pkg) oraz spakowanej paczki. Standardowo, w przypadku AUR helperów wszystko to odbywa się w RAM, a w zasadzie do dyspozycji tmpfs, w którego części mieści się tmp gdzie paczka jest budowana, w połowie jej rozmiaru (domyślnie dla tmpfs rezerwowana jest połowa dostępnej pamięci RAM).
Pół biedy zatem, gdy za pomocą AUR helpera budujemy stosunkowo niewielką paczkę, która ma stosunkowo niewielkie źródła. Wszystko przebiegnie gładko i po chwili otrzymamy zbudowaną paczkę, gotową do zainstalowania. Jednakże, gdy zamierzamy zbudować jakiś większy program, bądź też całkiem mały, jednakże wymagający sporo miejsca, to bez trudu cała przestrzeń tmp zostanie zajęta na potrzeby budowania paczki. Konsekwencją będzie nie tylko częsty komunikat o braku dostępnego miejsca dla jej budowy, ale nawet problemy w działaniu całego systemu.
Dla uzmysłowienia sobie skali problemu zwróćmy uwagę na stosunkowo niewielką paczkę i zarazem często stosowaną, jaką jest opera-ffmpeg-codecs. Cała paczka, po zbudowaniu liczy zaledwie ok. 3 MB. Dla zbudowania wymaga jednak pobrania źródeł całego chromium, które liczą sobie blisko 460 MB i to w postaci skompresowanej do xz. Po rozpakowaniu sam katalog ze źródłami chromium liczy sobie ok. 2,4 GB. Efekt jest taki, że dla zbudowania stosunkowo małej paczki opera-ffmpeg-codecs wymagany jest obszar ok. 4-5 GB pamięci RAM. Jest oczywiste, że na komputerze, który nie jest wyposażony w co najmniej 6 GB RAM (a i to jest absolutnie graniczną wielkością i zależną od wielu czynników) taka operacja się nie powiedzie. Konsekwencją próby budowy tej paczki na komputerze, który ma nie więcej niż 4 GB RAM może być stopniowy spadek responsywności środowiska (jeśli budujemy jednocześnie korzystając z jakiegoś), aż do oznak zawieszenia się komputera (tak na prawdę, to winny one minąć, niemniej jednak przez dłuższą chwilę komputer będzie zachowywał się jakby był zawieszony).
Dodatkowo musimy jeszcze pamiętać, że nie każdy AUR helper usuwa po sobie pozostałości budowania paczki, które w dalszym ciągu zajmują RAM (tmp).
Innymi słowy - budujmy paczki z głową.

środa, 9 listopada 2016