Pokazywanie postów oznaczonych etykietą instalacja. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą instalacja. Pokaż wszystkie posty

sobota, 26 października 2013

Jak zepsuć Gentoo, czyli wywal sobie GCC jednym kliknięciem

Tak naprawdę to nie zepsułam sobie Gentoo na dobre. W sumie nic drastycznego nie zrobiłam. Aż tak zdolna nie jestem.


Jesienne porządki

Zacznijmy od tego, że zapchało mi się Portage. Aktualizacje nie chciały się przeprowadzać, bo nie było miejsca. Zajrzałam do /usr/ i /var/ i faktycznie - były równo pozapychane. Pogrzebałam w internetach na ten temat i na oficjalnym forum Gentoo wyczytałam, że pomaga na to wyczyszczenie katalogów /usr/portage/distfiles oraz /var/tmp/portage. Nie ma to żadnego wpływu na funkcjonowanie systemu, najwyżej aktualizacja potrwa nieco dłużej, bo Portage będzie musiało ściągnąć sobie źródełka, które wywaliłam. No spoko, czyścimy. Szybkie komendy rm -r /usr/portage/distfiles/* oraz rm -r /var/tmp/portage/* - parę sekund i gotowe. Miejsca od razu mnóstwo się zrobiło. Super!

Jednak nie do końca tak super. Miejsca było mnóstwo, ale aktualizacje nie chciały lecieć. Podobno miałam za stary kompilator GCC, starszy niż 4.6. Sprawdziłam wersję poleceniem eix gcc i pokazało się, że mam wersję... 4.7.3. Wtf? No to spróbuję sobie przekompilować GCC. Nie ma tak dobrze. Okazało się, że wersja jest w porządku, za to profil jest wyłączony. Musiałam więc go jakoś włączyć. Na szczęście jest polecenie gcc-config -l, które potwierdza, że profil faktycznie jest wyłączony i pokazuje dostępne wersje. Wygląda to tak: * gcc-config: Active gcc profile is invalid! [1] x86_64-pc-linux-gnu-4.7.3. Jak widać, miałam tylko jeden do wyboru, przez co na pewno wybrałam właściwy. Żeby ustawić sobie profil, trzeba wpisać gcc-config 1, tym razem bez set, co jest trochę dziwne, bo zwykle jest set. No ale jak tam chcą. Potem jeszcze musiałam dopisać polecenia . /etc/profile (ze spacją), a następnie fix_libtool_files.sh 4.6.3 (poprzednia wersja, którą można sobie sprawdzić genlop -l | grep sys-devel/gcc, jeśli jej nie pamiętacie). Wpisałam i pomogło. Jeden problem z głowy.


Emake Failed!

Skoro jeden z głowy, to domyślacie się zapewne, że to jeszcze nie koniec. Aktualizacje dalej nie chciały iść, bo pakiet Systemtap, od którego zależy między innymi Icedtea wywalał mi emake failed. Moja wersja Systemtapa to ostatnia stabilna, czyli 1.6. Co ciekawe, już dawno nie było jakiejś nowszej stabilnej, wszystkie mają tyldę i to się nie zmienia.


Miałam do wyboru - albo zmienić sobie w kompilacji j2 na j1, albo wgrać sobie wersję niestabilną. Próbowałam z 1.7, ale dupa blada - dalej emake failed. Usunęłam więc wybór wersji, niech sobie bierze, co chce. Wzięło 2.2 i już się nie posypało. Wszystkie aktualizacje, a było ich trochę, poleciały bez problemów.

Dla przypomnienia: kiedy wybierałam konkretną niestabilną wersję, czyli 1.7, to wpisywałam w /etc/portage/package.keywords info o tej wersji, czyli =dev-util/systemtap-1.7 ~amd64 - ze znakiem równości i ~amd64 na końcu, bo mam architekturę amd64. Natomiast kiedy pozwalam systemowi wybrać sobie najwyższą dostępną wersję, bez zastrzeżenia, którą konkretnie, to zmieniam wpis na dev-util/systemtap ~amd64 i wtedy leci 2.2.


Jądro kompiluję, bo czemu nie

Systemtap po ostatecznym skompilowaniu powiedział mi, że chciałby 3 zmiany w jądrze do poprawnego funkcjonowania. Były to:
  • (KPROBES) - this can be enabled in 'Instrumentation Support -> Kprobes' - u mnie było pod General Settings, więc jeśli nie możecie tego znaleźć, to się nie martwcie,
  • (RELAY) - this can be enabled in 'General setup -> Kernel->user space relay support (formerly relayfs)' - było na swoim miejscu,
  • (DEBUG_FS) - this can be enabled in 'Kernel hacking -> Debug Filesystem' -  to też.
Tak w ogóle, to korzystam z genkernela, ale jestem n00bkiem i mi wolno. Wolę powoli obcinać niepotrzebne elementy, niż użerać się z tym, żeby w ogóle system odpalił.


W przygotowaniu

Napiszę niebawem o aktualizacji Gruba z 0.97 na 2 (i co można z tym zrobić), o problemach z Eclipse i konieczności grzebania w overlayach oraz o tym, dlaczego Netbeans się głupio aktualizuje.

wtorek, 5 marca 2013

OMG, nie widzę napisów w VLC, czyli dlaczego useflagi są ważne

Mój blog dorobił się już jednego komentarza i to od osoby kompletnie mi nieznanej, co mnie bardzo cieszy i zachęca do pisania dalej.  Już można komentować bez logowania :)

Nazwałam bloga Mam Gentoo, nie Man Gentoo, dlatego postaram się opisywać tu swoje przygody z Gentoo, nie przepisywać manuala. Manual już istnieje, można go poczytać tutaj i jest naprawdę niezły.


Ratunku, nic nie widzę!

Moim ulubionym linuksowym odtwarzaczem wideo jest VLC, dlatego znalazł się obowiązkowo na moim nowym systemie. Jeżeli ktoś z was używa Windowsa i zastanawia się nad przejściem na Linuksa, to zapewniam, że VLC jest świetnym odpowiednikiem odtwarzacza Media Player Classic, podobnie się obsługuje, łatwo instaluje i ogólnie nie robi problemów.

Krótko po instalacji Gentoo postanowiłam obejrzeć sobie film z napisami. Włączam więc film, ładuję napisy... i nic. Nie ma napisów. Próbuję jeszcze raz. I jeszcze raz. Nadal nic. Sprawdzam plik tekstowy, może jest pusty? Nie, wszystko wydaje się być w porządku. Próbuję jeszcze raz.

O, jednak są napisy. Tylko niestety mają jakieś 2 mm wysokości. No to sobie poczytałam.

Sprawdzam ustawienia napisów w VLC. Ustawiam jak największą czcionkę, jednak i tak to nic nie daje. Przy okazji wklejam, gdzie to znaleźć, bo jest nieco schowane, a przydatne, bo według mnie domyślna czcionka jest zbyt mała.


Nie, nie mam na myśli tego dwumilimetrowego maczku. Udało mi się w końcu znaleźć rozwiązanie tego problemu i w dole ekranu pokazały się normalnej wielkości literki.


Flagi USE

W innych systemach programy wiedzą lepiej od ciebie, co mają zawierać i jak się zachowywać. W przypadku Gentoo decydujemy o tym sami. Jak coś chcemy mieć, to wgrywamy, jeśli nie, to nie. Wskazanie, która funkcja ma być aktywna, a która wyłączona, to właśnie flagi.
Oczywiście są flagi domyślne, ale nie są one obowiązkowe. Można je wyrzucić dopisując minus. Mój blog ma domyślnie jakiś szablon. Gdyby działał jak Gentoo, można by było dopisać coś w stylu blog/mamgentoo -szablon i wyświetlałby się sam tekst.


Lokalnie czy globalnie?

Sprawa jest ogólnie prosta. Jeżeli flaga będzie używana często, warto dopisać ją do flag globalnych w /etc/portage/make.conf (wracając do przykładu z blogiem: wszystkie blogi mają szablon). Jeżeli chcemy użyć jej tylko do konkretnego pakietu (tylko mamgentoo ma szablon) lub wyjątkowo gdzieś wyłączyć (wszystkie blogi oprócz mamgentoo mają szablon), zmieniamy plik /etc/portage/package.use. Listę dostępnych flag można znaleźć na przykład tutaj.


A jak to w końcu było z VLC?

Okazało się, że flaga fladze nierówna. Znalazłam informację, że do prawidłowego wyświetlania napisów jest potrzebna flaga truetype. Była ona dopisana w zestawie globalnym, ale VLC o tym nie wiedziało, dlatego wpisałam w konsoli polecenie USE="truetype" emerge vlc. No i git! Zadziałało! Ale tylko do najbliższej aktualizacji...
Wkurzyłam się. Nie będę przecież przed każdym filmem przeinstalowywać odtwarzacza. Pogrzebałam zatem po różnych forach i znalazłam rozwiązanie - VLC chce nie tylko flagi truetype, ale także fontconfig. Zrobiłam wpis w package.use z obiema flagami specjalnie dla VLC. DZIAŁA! I co najważniejsze - pamięta.


IRC w konsoli, czyli program prawdę ci powie

Czasem bywa tak, że instalowany program sam upomni się o flagę, jeśli nie dopiszesz mu czegoś, co jest typowe. Przykładem może być XChat, praktyczny i użyteczny klient irca. Zainstalowałam go za pomocą zwykłego emerge. Po zakończeniu instalacji, program sam mi powiedział, że będzie działać tylko w konsoli i jeśli chcę używać okienek, to mam dopisać mu flagę gtk. Pewnie, że chcę! Wgrałam XChata na nowo z tą flagą i po chwili mogłam cieszyć się wygodnym interfejsem graficznym.
Jednak nie każdy program jest taki miły, dlatego zawsze przed instalacją warto sprawdzić, co dostaniemy w pakiecie. Zaoszczędzi nam to sporo czasu, który przyda się przy grzebaniu lub innej kompilacji. Gentoo to w końcu pod tym względem studnia bez dna.



poniedziałek, 4 marca 2013

O zależnościach i instalowaniu ze źródeł

Szykuję kilkuczęściową notkę, w której opowiem wam, jak instalowałam Gentoo i na co warto zwrócić uwagę, kiedy robicie to po raz pierwszy. Jednak zajmie to trochę czasu, a chciałam napisać coś konstruktywnego poza przywitaniem się.

Jak już wspominałam w poprzedniej notce, instalowałam programy ze źródeł. Pomimo tego, że używałam Debiana w wersji testowej, to programy ściągane z repozytorium i tak sprawiały, że mój komp zajeżdżał stęchlizną.

No dobra, powiecie, w takim razie po prostu sobie ściągaj źródła, kompiluj i nie zrzędź. Właśnie to było najbardziej wkurzające na Debianie. Teoretycznie wystarczyło zwykle wpisać ./configure, make, make install, w praktyce wyglądało to jednak gorzej.

Właściwie każdy program potrzebuje zależności - jakichś dodatkowych pakietów, dzięki którym w ogóle może się zainstalować i poprawnie działać. No i Debianowa konsola przy instalacji programu X wyrzucała mi

Jeśli chcesz mieć X, zainstaluj zależności A i B.
W porządku, instalujemy. Jednak potem okazywało się, że zależność A potrzebuje kolejnych zależności C i D, natomiast do B trzeba ściągnąć jeszcze E, F i G, które z kolei nie pójdą bez H i I, którą w sumie masz na kompie, ale w nowszej wersji, a tu jest potrzebna starsza. Inne programy z kolei wolałyby nową, no i masz problem. A nawet jeśli nie masz, to i tak spędzisz pół dnia na kompie ściągając te cholerne zależności. Możesz też się w końcu wkurzyć i zainstalować inny, mniej uciążliwy program albo ściągnąć staroć z repo.


Instalowanie ze źródeł nie jest takie straszne

Wiele osób myśli, że instalacja programów w dystrybucjach takich jak Gentoo to coś strasznego. Tymczasem jest to równie proste jak na tych uznawanych za "łatwiejsze". Dużą zaletą Gentoo są programy dostępne w nowych wersjach. Nie ma więc obaw, że babcia wejdzie ci do pokoju i powie, że używała tego w młodości ;)

Jedyne, co musisz zrobić, to wpisać w konsoli emerge [nazwa programu] i już. Zależności sprawdzą i pościągają się same. Oczywiście, musisz spojrzeć, czy na kompie nie dzieje się coś, czego nie chcesz, ale zwykle wszystko jest w porządku.


Jak sprawdzić, które wersje wybranego programu są dostępne?

Najlepiej wejść na packages.gentoo.org i znaleźć to, co nas interesuje. Pojawi się wówczas tabelka podobna do tej:


Po lewej znajdują się kolejne wersje programu, natomiast na górze architektury. Moja to amd64 i właśnie tę rubryczkę sprawdzam. Na zielono zaznaczone są stabilne wersje, które ściągną się po prostu po wpisaniu emerge [nazwaprogramu], na żółto wersje niestabilne, a na czerwono wersje najbardziej niestabilne-zamaskowane. Żółte i czerwone też można ściągnąć, ale Gentoo musi o tym wiedzieć, więc trzeba dopisać coś w pliku /etc/portage/package.accept_keywords. Na przykład, do instalacji nowej wersji mojej ulubionej przeglądarki Opera, muszę dopisać tam linijkę
=www-client/opera-12.14_p1738 ~amd64
po czym puszczam normalnie emerge opera i leci.
Tyle, że taka linijka sprawi, że program uczepi się wersji 12.14_p1738 nie będzie się aktualizować dalej - bo w końcu mówię, że chcę TĘ KONKRETNĄ WERSJĘ. Natomiast jeśli wpiszę
www-client/opera ~amd64
to zainstaluje się najwyższa niestabilna (zwróćcie uwagę, że przy amd64 jest ~tylda).

Ogólnie lepiej instalujcie wersje stabilne, zwłaszcza jeśli dopiero zaczynacie z Gentoo tak jak ja. No chyba, że bardzo wam zależy na jakimś programie i wiecie, że niestabilna wersja nie powinna posypać wam systemu. Ale naprawdę, uważajcie.


Czytaj manuala!

Bo manual naprawdę wie dużo więcej niż taki n00bek jak ja ;)

Inną sprawą są flagi USE, bez których program czasem nie nadaje się do niczego, ale o tym w innym odcinku :)