Podstawowa konfiguracja

Podstawowa konfiguracja repozytorium z oprogramowaniem to fedora, fedora-updates, fedora-updates-testing, fedora-rawhide. Poniżej opis repozytorium.

• fedora – tutaj są wszystkie główne pakiety, bez poprawek. Domyślnie włączone.
• fedora-updates – to repo zawiera wszelkie uaktualnienia, które się ukazują. Domyślnie włączone.
• fedora-updates-testing – to repo zawiera uaktualnienia, które są testowane (jak nazwa wskazuje). Domyślnie wyłączone ponieważ pakiety testowane mogą wpłynąć na stabilność systemu. Jeśli jednak posiadasz włączone warto zainteresować się https://admin.fedoraproject.org/updates/, miejscem gdzie możesz dać znać czy poprawka rozwiązuje zgłoszone problemy.
• fedora-rawhide – repozytorium zawierające pakiety wchodzące w skład nowszej, rozwijanej wersji Fedory (w tej chwili jest to F13). Wyłączone domyślnie z powodu tego, że nie osiąga nigdy statusu wersji stabilnej. W momencie osiągniecia pojawia sie kolejne wydanie a rawhide staje się nowym wydaniem.

Repozytorium można włączać poprzez edycję plików z katalogu /etc/yum.repos.d/. Pokażę na przykładzie fedora-updates-tesing.repo

1. sudo nano /etc/yum.repos.d/fedora-updates-testing.repo
2. Linijkę enabled=0 należy zamienić na enabled=1.

Jeśli używasz yumex`a to należy przejść od opcji Repository Selection View (taka kula ziemska lub planeta) i zaznaczyć te które są interesujące, następnie Profiles i Save. Ostatnia rzecz to Refresh i dostaniemy listę dostępnych poprawek.

Dodatkowe repozytorium

RPMFusion

Instalacja graficzna wyglada następująco. Wybierz i kliknij link do twojej dystrybucji Fedora 10, 11 i 12; Fedora Alpha, Beta, Rawhide, RC, Snapshot lub Preview; RHEL5 lub inna kompatybilna z CentOS. Potem należy zainstalować używając domyslnego wyboru Fedory (zostanie odpalony PackageKit) lub zapisać a potem zainstalować (sudo rpm -ihv nazwa_paczki). W ten sposób instalujemy wersję free, do repozytorum nonfree służą te linki: Fedora 10, 11 i 12; Fedora Alpha, Beta, Rawhide, RC, Snapshot lub Preview; RHEL5 lub inna kompatybilna z CentOS.

Instalacja tesktowa wygląda w taki sposób.

• Fedora 10, 11 i 12
  su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'
• Fedora Alpha, Beta, Rawhide, RC, Snapshot lub Preview
  su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm'
• RHEL5 lub inna kompatybilna z CentOS
  su -c 'rpm -Uvh http://download1.rpmfusion.org/free/el/updates/testing/5/i386/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/i386/rpmfusion-nonfree-release-5-0.1.noarch.rpm'

Adobe

Repo zawiera paczki z flashem, jeśli nie chcesz używać gnash`a (wolna wersja flasha), zainstaluj to repo. Instalacja graficzna polega na kliknięciu linka do paczki i pozwolenie na instalację za pomocą PackageKit.

Instalacja tekstowa
sudo rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm

PlayOnLinux

PlayOnLinux to projekt wspomagający isntalację gier i programów na wine. Posiada sporą bazę skryptów konfigurujących wine pod odpowiednie tytuły. Instalacja graficzna to po prostu kliknięcie i zainstalowanie tego pakietu.

Instalacja tekstowa

sudo rpm -ihv http://mulx.playonlinux.com/rpm/playonlinux-yum-3-3.noarch.rpm

Compiz Fusion

Wszyscy wiedzą co to jest Compiz Fusion a jeśli nie to zapraszam do przeczytania krótkiej notki w Wikipedii. To repozytorium zawiera paczki compiz-fusion dla F9, F10, F11 i F12. Instalacja graficzna polega na kliknięciu w ten link i zainstalowaniu pakietu.

Instalacja tekstowa

sudo rpm -ivh http://leigh123linux.fedorapeople.org/compiz-fusion-release-1-8.noarch.rpm

import ipaddr

ImportError: No module named ipaddr

1. Dołączanie %changelog

Część pliku spec odpowiedzialna za changelog jest wymagana, tak przynajmniej uważa rpmlint oraz tak stoi w dokumentacji Fedory. W dokumentacji distutils nie ma zbyt wielu informacji na ten temat. Jednak naprowadziła mnie ona na proste rozwiązanie a mianowicie

python setup.py bdist_rpm --help

Komenda wyświetla dokładnie to czego potrzeba czyli

--changelog          RPM changelog

To mogłoby załatwić sprawę gdyby nie brak informacji w jakiej postaci ma być changelog. Wszystko wskazuje, że to powinien być plik jednak domyślne formatowanie nie spełniało wymagań i ładnie wypluwało komunikat, że wiersz musi zaczynać się od “*”. Postanowiłem zerknąć do pliku odpowiedzialnego za generowanie paczek rpm /usr/lib64/python2.6/distutils/command/bdist_rpm.py. Na początku pliku wśród listy opcji pojawia się taki tekst

# More meta-data: too RPM-specific to put in the setup script,
# but needs to go in the .spec file — so we make these options
# to “bdist_rpm”.  The idea is that packagers would put this
# info in setup.cfg, although they are of course free to
# supply it on the command line.

No ładnie ale ja z lini poleceń nie mogłem dołączyć changelog więc z pomocą przyszedł plik setup.cfg. Do pustego pliku dodałem linijkę

[bdist_rpm]
changelog = #tutaj tekst changelog oczywiście zaczynający się od *

Należy pamiętać o gwiazdce ropoczynającej każdą wersję oraz o poprawnym formacie daty. Rpm jest bardzo wymagający w tym temacie. Tak przygotowany changelog powinen przejść proces budowania paczki.

2. Dodawanie %post_install i %post_uninstall

Kolejne rzeczy, które musiałem skonfigurować to sekcje kodu uruchamiane po zainstalowaniu paczki i jej odinstalowaniu. Wspomniany wcześniej bdist_rpm –help tak opisuje to

–post-install       Specify a script for the post-INSTALL phase of RPM

building

–post-uninstall     Specify a script for the post-UNINSTALL phase of RPM

building

W tym wypadku jednak nie używałem linii poleceń ani pliku setup.cfg. Te dwie opcje pozwoliły sie zgrabnie dołączyć do pliku setup.py jako argument funkcji setup

options={'bdist_rpm' : {'post_install'  : 'ścieżka_do_pliku', 'post_uninstall'  : 'ścieżka_do_pliku'}}

Bardzo możliwe, że zamiast podawania ścieżek do istniejących plików można wsadzić komendy. W wypadku skryptów mających parę linijek może pojawić się problem, ale nie testowałem.

Z pomocą przychodzi xdebug, który został mi polecony przez Matlasa. Instalację xdebuga pominę bo jest prosta jak drut i można ją znaleźć w dokumentacji. Najważniejsza i najtrudniejsza rzecz to konfiguracja emacsa (jak zawsze zresztą).

A więc zaczynamy od instalacji GEBEN`a, następnie instalujemy CEDET, otwieramy port 9000 na firewallu. Tak wyposażeni możemy zacząć debugowanie. Ale szczerze mówiąc nie piszę tego posta aby opisać jak skonfigurować emacsa do tego (chyba, że ktoś sobie zażyczy). Powodem dla którego piszę ten post jest SElinux, który blokuje port 9000 dla apache, oczywiście tylko jeśli mamy serwer lokalnie na komputerze.  Poniżej wybrane informacje z raportu SELinux.

Summary:

SELinux is preventing /usr/sbin/httpd from connecting to port 9000.

Allowing Access:

If you want to allow httpd to connect to 9000, you can execute
semanage port -a -t PORT_TYPE -p tcp 9000
where PORT_TYPE is one of the following: http_port_t, ldap_port_t, dns_port_t,
mysqld_port_t, ocsp_port_t, postgresql_port_t, kerberos_port_t.

Rozwiązanie jest proste a mianowicie

semanage port -a -t http_port_t -p tcp 9000

Restart apache`a. Koniec.

Zobaczyłem taki komunikat.

b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02)

b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed soon (official deadline was July 2008).

b43-phy0 warning: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website.

git clone http://git.bu3sch.de/git/b43-tools.git
cd b43-tools/fwcutter
make
cd ..

export FIRMWARE_INSTALL_DIR="/lib/firmware"
wget http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2
tar xjf broadcom-wl-4.178.10.4.tar.bz2
cd broadcom-wl-4.178.10.4/linux
sudo ../../fwcutter/b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o

Po tej operacji dmesg pokazuje komunikat który mnie się bardzo podoba.

Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ]
b43 ssb0:0: firmware: requesting b43/ucode13.fw
b43 ssb0:0: firmware: requesting b43/b0g0initvals13.fw
b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23)

Polecam wszystkim.

Jako argument bierze ścieżkę do katalogu w którym foldery musi spakować i po kolei pakuje do plików tar.bz2. Polecam dodanie do crontaba użytkownika root tak jak back-in-time.

Kod do pobrania, oczywiście dostępny na licencji GPLv3.

Załóżmy, że posiadasz mały formularz stworzony w QtDesigner i dopisałeś do tego trochę swojego kodu.

from PyQt4 import QtCore, QtGui
import sys
class Ui_MainWindow(object):
    def setupUi(self, MainWindow):
        MainWindow.setObjectName("MainWindow")
        MainWindow.resize(365, 222)
        self.centralwidget = QtGui.QWidget(MainWindow)
        self.centralwidget.setObjectName("centralwidget")
        self.pushButton = QtGui.QPushButton(self.centralwidget)
        self.pushButton.setGeometry(QtCore.QRect(110, 70, 114, 27))
        self.pushButton.setObjectName("pushButton")
        MainWindow.setCentralWidget(self.centralwidget)
        self.retranslateUi(MainWindow)
        QtCore.QMetaObject.connectSlotsByName(MainWindow)
    def retranslateUi(self, MainWindow):
        MainWindow.setWindowTitle(QtGui.QApplication.translate("MainWindow", "MainWindow", None, QtGui.QApplication.UnicodeUTF8))
        self.pushButton.setText(QtGui.QApplication.translate("MainWindow", "Click", None, QtGui.QApplication.UnicodeUTF8))
class MyForm(QtGui.QMainWindow):
    def __init__(self, parent=None):
        QtGui.QWidget.__init__(self, parent)
        self.ui = Ui_MainWindow()
        self.ui.setupUi(self)
if __name__ == "__main__":
    app = QtGui.QApplication(sys.argv)
    myapp = MyForm()
    myapp.show()
    sys.exit(app.exec_())

Powyższy kod powstał już po edycji pliku z QTDesignera, do pliku wynikowego przetworzonego w pyuic4 dorzuciłem dwa dodatkowe bloki kodu. Inicjalizację formatki oraz klasę MyForm. Teraz ten plik zawiera całość kodu, który otwiera mini formatkę z jednym przyciskiem nad czym będziemy pracować. Pozwolę sobie omijać fragmenty kodu i podawać tylko istotne zmiany. Wiem, że w wypadku częstych zmian formatki lepiej jest ją trzymać w osobnym pliku i importować ale na potrzeby tego tutoriala jest to jeden plik.

Do pliku dodajemy kod podpinający sygnał clicked() do naszego przycisku i wykonujący stworzoną przez nas akcję. Dodajemy to do klasy MyForm.

QtCore.QObject.connect(self.ui.pushButton, QtCore.SIGNAL("clicked()"), self.MessageBox)

Następnie piszemy funkcję MessageBox która wyświetli okienko potwierdzające, że akcja została wykonana.

def MessageBox(self):
    box = QtGui.QMessageBox(self)
    box.setWindowTitle(self.tr("information"))
    box.setText(self.tr("You have clicked button"))
    box.setStandardButtons(QtGui.QMessageBox.Ok)
    box.exec_()

Ten plik po uruchomieniu wyświetli okno z jednym przyciskiem po kliknięciu którego wyświetli się messagebox. Teraz zabierzemy się za tłumaczenie programu. Przechodzimy do sedna.

Wymienione przeze mnie funkcje odpowiadają za tworzenie plików .ts do tłumaczeń. Konwencja używania funkcji jest następująca, translate() używane jest dla tekstów będących poza klasami (QTDesigner wszystko wsadza do funkcji translate(), funkcja wymaga podnia kontekstu w jakim znajduje sie łańcuch), funkcja tr() jest dla wszelkich łańcuchów będących w środku klas a trUtf8() dla łańcuchów UTF8. Proste jak drut a przykłady użycia są w kodzie.

Następnym krokiem jest zmodyfikowanie aplikacji aby ładowała tłumaczenie automatycznie na podstawie zmiennej &LANG. Dodajemy kod do funkcji inicjalizującej (jako, że nie jestem pewny o czym piszę to mam na myśli if __name__ == “__main__”:)

locale = QtCore.QLocale.system().name()
appTranslator = QtCore.QTranslator()
if appTranslator.load("okno_ui_" + locale):
    app.installTranslator(appTranslator)

Dzięki temu program będzie uruchamiał odpowiednie tłumaczenie, jeśli plik z tłumaczeniem nie zostanie odnaleziony zostanie załadowany domyślny język(w tym wypadku angielski gdyż taki został użyty w kodzie). Dla języka polskiego program będzie próbował załadować tłumaczenie z pliku okno_ui_pl_PL.qm. Nie jest konieczne dodawanie rozszerzenia .qm. Takich plików jeszcze nie mamy, najpierw należy stworzyć plik .pro zawierający wszelkie pliki .ui, .py, .pyw oraz .ts (co ładnie rozwija się w translation source). Ja zazwyczaj nie dodaję plików .ui z powodu tego, że formularze przerabiam potem troszkę na własną rękę poprawiając kod i później mam zamieszanie w pliku .ts. Trudno mi powiedzieć czy jest to dobra czy zła praktyka, mam zbyt małe doświadczenie. Drobne uaktualnienie odnośnie dodawania plików .ui, w tej chwili jednak wolę trzymać formularz stworzony w QtDesigner w osobnym pliku, przyspiesza to dokonywanie zmian. Jednak dla potrzeb tego poradnika jest to wsadzone do jednego pliku, mniej plików = mniejsze zamieszanie. Oto plik .pro.

SOURCES = okno_ui.py
TRANSLATIONS = okno_ui_pl_PL.ts

W wypadku dodawania plików .ui potrzebna jest linijka FORMS =. Następnie wykonujemy polecenie pylupdate4 a jako argument podajemy stworzony plik .pro i otrzymujemy gotowy plik .ts który mozna przetłumaczyć. Tłumaczenia robimy w programie QtLinguist, a gotowe pliki .ts przetwarzamy programem lrelease-qt4 który tworzy nam pliki .qm. Koniec pracy. Jeśli w katalogu aplikacji znajdzie się plik .qm dla odpowiedniego języka systemowego to tłumaczenie zostanie załadowane w innym wypadku program otworzy się  w języku angielskim.

W wypadku jeśli chcemy dołożyć tłumaczenie nalęzy po prostu dodać odpowiedni plik .ts do posiadanego pliku .pro i ponownie uruchomić pylupdate4, QtDesigner, lrelease-qt4 i tak w koło Macieju.

Dziękuję za uwagę.