Psi i Pidgin - solucje

Wszystko zaczęło się gdy zażyczyłem sobie SSLa do Google Talk na Psi... Znalazłem jakieś QCA w systemie ale SSLa nie było. Dopiero w README doczytałem, że do QCA potrzebne jest QCA-TLS aby Psi łapał szyfrowanie. Jednak w systemie miałem OpenSSLa 0.9.8e ... co zrobiłem ?

[Psi]

Wywaliłem OpenSSL 0.9.8e - który miałem zainstalowany.
Skompilowałem czyste QCA [http://delta.affinix.com/download/qca/qca-1.0.tar.bz2]
Skompilowałem OpenSSL 0.9.6m [http://www.openssl.org/source/openssl-0.9.6m.tar.gz], który domyślnie zagnieździł się w /usr/local/ssl
Skompilowałem plugin QCA niezbędny do działania SSLa w Psi [http://delta.affinix.com/download/qca/qca-tls-1.0.tar.bz2]:

./configure --with-openssl-inc=/usr/local/ssl/include --with-openssl-lib=/usr/local/ssl/lib

Uruchomiłem wcześniej zainstalowane Psi. Psi obsługuje już SSLa.

[Pidgin]
Bardzo spodobał mi się Pidgin [http://pidgin.im/pidgin/home/]. Jednak na wstępie miałem z nim już problemy. Otóż po zaimportowaniu listy kontaktów z serwera Gadu-Gadu podczas wyszukiwania przez wpisywanie gdb wyrzucał jakieś błąd sprawdzającej chyba długość stringu, a po kolejnym uruchomieniu wyskakiwał błąd, że nie można czytać blist.xml, że został skopiowany do blist.xml~ i, że jest źle.

Zajrzałem więc do ~/.purple/blist.xml~ - okazało się, że jest tam moja stara lista kontaktów, tylko są w niej jakieś dziwne krzaki. Doszedłem do wniosku, że to coś z kodowanie nie tak :/ Wszedłem więc do mojego kadu i wyeksportowałem listę do pliku kontakty.txt. Jednak po zaimportowaniu Jej do pidgina nadal było źle. Metodą prób i błędów znalazłem solucję. Otworzyłem plik z eksportem kotantków z kadu (kontakty.txt) w leafpad i zapisałem go ponownie ustawiając w Zapisz jako ... kodowanie na CP1250 CR+LF jako cp1250_kontakty.txt. Po zaimportowaniu kontaktów z tak przygotowanego pliku do Pidgina krzaczki zniknęły. Jednak to nie koniec :/ Otóż pidgin błędnie koduje znaczki (u mnie w nazawach grup). Otwieramy plik (kodowany jako utf-8) ~/.purple/blist.xml, ręcznie szukamy nieprawidłowo wpisanych znaków i je poprawiamy. U mnie osobiście występowały w nazwach grup w znaczniku name="". Po wprowadzeniu poprawek zapisujemy plik na razie pod jakąś inną nazwą (u mnie n_blist.xml) kodowany jako utf-8 (wszystko można wykonać na przykład w leafpad) Zamykamy pidgina. Pidgin błędnie zapisał nazwy do pliku blist.xml jednak nasz plik n_blist.xml jest poprawiony :) podmieniamy więc plik blist.xml na nasz własny, odpalamy pidgina i cieszymy się :)

Ładny terminal

Najlepiej działającym u mnie terminalem jest urxvt. Udało mi siew końcu ustawić dla niego przezroczystość. Oto mój plik .Xdefaults:

URxvt.background: black
URxvt.foreground: white
URxvt.font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso8859-2
URxvt.scrollBar: false
URxvt.tintColor: white
URxvt.shading: 20
URxvt.inheritPixmap: true
URxvt.saveLines: 777
URxvt.geometry: 110x40
#URxvt.loginShell: true

System kontroli wersji podstawy

Zostałem ostatnio zmuszony do używania systemu kontroli wersji. No i dobrze. Na reszcie się czegoś nowego nauczę. Bardzo dobry tutorial, poleconym mi przez Łukasza, opisuje wszystko co trzeba wiedzieć aby z niego korzystać.

Do czego używać SVNa i dlaczego używać SVNa.

1) Każda zmiana jest logowana wraz z nazwą użytkownika. Wiesz więc kto co i kiedy zmienił w kodzie.
2) Gdy okazuje się, że program nie działa możesz jednym poleceniem wrócić do poprzedniego stanu - stanu w którym działał.
3) W razie utraty plików odzyskasz je z SVNa.

To tylko kilka cech, które zauważyłem. Na pewno bardziej zaawansowani użytkownicy podali by znacznie więcej argumentów. Jednak te wystarczają aby spróbować nauczyć się choć podstaw tego narzędzia. SVN trzyma informacje o projektach w swojej bazie. Musimy wybrać sobie katalog, gdzie svn będzie trzymał swoje informacje. Powiedzmy, że dla użytkownika dziubdziub będzie to katalog svn w jego katalogu domowy. Jako użytkownik dziubdziub wydajemy polecenie:

svnadmin create --fs-type fsfs /home/dziubdziub/svn

Polecenie to stworzy "bazę danych" dla SVN a. Teraz możemy zacząć z niego korzystać. Powiedzmy, że w katalogu public_html tworzymy stronę internetowa dziubdziub. Mamy więc katalog /home/dzibdziub/public_html/dziubdziub w którym są pliki naszej strony internetowej. Jeżeli chcemy je włączyć do naszego systemu kontroli wydajemy polecenie:

svn import /home/dziubdziub/public_html/dziubdziub file:///home/dziubdziub/svn/dziubdziub -m 'Pierwszy import. (działa)'

Co właśnie zrobiliśmy. Już omawiam:

svn - uruchomiliśmy program svn
import - z opcją importowania istniejącego projektu do Jego bazy danych (drugie polecenie to zawsze import)
/home/dziubdziub/public_html/dziubdziub - projektu znajdującego się w tym katalogu
file:///home/dziubdziub/svn/dziubdziub - i zaimportować go do katalogu SVN file:///home/dziubdziub/svn/ jako dziubdziub - SVN założy sobie swój własny katalog dziubdziub i będzie w nim trzymał pliki naszego projektu.
-m "Pierwszy import. (działa)" - Każdy "import" musimy jakoś opisać. W opis wpisujemy zmiany, których dokonaliśmy, oraz możemy zaznaczyć czy coś działa, co zaczęło działać, a może coś było do dokończenia...

Kilka słów komentarza. SVN tworzy swój własny "system plików"... Po zajrzeniu do /home/dziubdziub/svn zobaczymy tylko kilka nic nie mówiących nam plików i katalogów. Aby oglądać ten system plików wydajcie polecenie:

svn ls file:///home/dziubdziub/svn/
svn ls file:///home/dziubdziub/svn/dziubdziub

Zobaczymy nasze pliki :) Istnieją też komendy svn rm, svn mkdir i kilka innych analogicznych do poleceń dostępnych w powłoce Linuksa. Jeżeli wywołamy:

svn log file:///home/dziubdziub/svn/
svn info file:///home/dziubdziub/svn/dziubdziub

Dowiemy się jakie zmiany zaszły w naszych plikach. Powinniśmy teraz wykonać checkout-a. W tym celu przejdźmy do katalogu /home/dziubdziub/public_html (katalog niżej niż projekt), zmieńmy nazwę projektowi (lub usuńmy go, ja jednak wolę zmienić nazwę i nie usuwac plików na wypadek, gdyby SVN nawalił) mv dziubdziub dziubdziub_bak. Teraz katalog dziubdziub nie istnieje. Możemy teraz wykonać checkout svn checkout file:///home/dziubdziub/svn/dziubdziub. Co się stało ? SVN przeniósł zapisane przez siebie pliki do katalogu. Została sprawdzona poprawność naszego importu i coś jeszcze :)... Otóż po wykonaniu w katalogu projektu (w każdym z katalogów) okazuje się, że znajduje się katalog .svn. Dzięki niemu nie będziemy musili podawać ścieżki przy wykonywaniu poleceń svn log, svn info. Po wykonaniu checkout a możemy edytować swoje pliki i zmieniać je, tak jak wcześniej. Kiedy dokonamy zmian i chcemy odnotować je w naszym SVN możemy najpierw sprawdzić co nasz SVN odnotował. Sprawdzamy to wchodząc do katalogu z projektem i wpisujemy komendę svn status. Odpowiednie zmiany, usunięcia, dodania będą oznaczone odpowiednimi literkami. Powiedzmy, że utworzyliśmy plik opis.txt. Wtedy svn status wyrzuci nam:

? opis.txt

Musi więc dodać go do naszego SVN svn add opis.txt:

A opis.txt

I odnotować zmiany w naszym repozytorium. svn commit -m "Plik z opisem do programu." okraszając go odpowiednim komentarzem. Ale halo halo ! Ci, którzy zamiast czytać dalej spróbują wywołać svn log stwierdzą... Nić się nie zmieniło... A no właśnie. Musimy ponownie wejść katalog niżej cd .. skasować katalog rm -fr dziubdziub i wykonać checkout. svn checkout file:///home/dziubdziub/svn/dziubdziub Pliki zostaną przywrócone a svn log pokaże kolejną zmianę. Zwrócę jeszcze tylko uwagę na pewien drobiazg. Checkout (i commit) podają na dole numerek... checkout zawsze przywróci nam ostatnio opisaną wersję programu. A co jeżeli chcielibyśmy na przykład pierwsza ? Nic prostrzego. Powiedzmy, że chcielibyśmy wersję numer 1 (musi taka istnieć, jeżeli taka nie istenieje program zwróci błąd). Ponownie kasujemy katalog dziubdziub i wykonujemy polecenie svn checkout -r 1 file:///home/dziubdziub/svn/dziubdziub i analogicznie w zależności, do jakiego stanu chcecie przywrócić swój projekt.

Checkouta robimy tylko za pierwszym razem kolejne zmiany po wykonaniu commit (wcześniej add, del itd...) wykonaujemy komendą svn up

SVNa można używać także do utrzymywania porządków w plikach systemowych - szczególnie jeżeli jest wielu adminów, którzy wprowadzają wiele zmian.