su -c 'rpm -ivh http://hicham.fedorapeople.org/lightspark/lightspark-release-0-1.noarch.rpm'
su -c 'yum install lightspark lightspark-mozilla-plugin'

Wg. autorów należy mieć dodane repozytorium rpmfusion. Następnie w Firefox`ie należy uruchomić wtyczkę przechodząc do konfiguracji Add-Ons i włączyć Shockwave Flash 10.0 r423. Jest to wersja na dzień dzisiejszy, potem może ulec zmianie więc trzeba będzie metodą prób i błędów ją włączać. Dla użytkowników Ubuntu 10.04 paczki czekają na launchpadzie.
Powodzenia! Trzeba walczyć z flashem.

Lightspark dla F13 to wpis z FLLOGa

sudo wget -O /etc/yum.repos.d/fedora-firefox4.repo http://kut.as/firefox4-beta
yum -y install firefox4

Voila! Firefox4 Beta jest zainstalowany.
Jeśli interesują Was inne programy których nie ma w repo to można zajrzeć na http://repos.fedorapeople.org/. Na razie jest skromna lista ale możliwe, że będzie się powiększać.

Firefox4 Beta repo to wpis z FLLOGa

su -c 'cd /etc/yum.repos.d/ && wget baseroot.info/devilish.repo'

A potem już tradycyjnie

sudo yum install django-extensions

.
Następnie dodajemy django-extensions do pliku settings i jazda. Podpowiem jedną komendę

./manage.py shell_plus

Resztę można odnaleźć w dokumentacji, do której odsyłam.
Pokój.

django-extensions w repo devilish to wpis z FLLOGa

Instalacja jest prosta jak drut.

yum install vnstat

Konfiguracja jest odrobinę bardziej skomplikowana ale nie jest to „rocket science” jak mówią na wschodzie. Mianowicie odnajdujemy plik /etc/cron.d/vnstat i usuwamy komentarz z linii

*/5 * * * * vnstat /usr/sbin/vnstat.cron

To powinno załatwić nam monitorowanie eth0 jako domyślnego interfejsu po wykonaniu polecenia vnstat -u -i eth0. Ja jednakże nie korzystam z eth0 tylko z wlan0 i aby monitorować go musiałem otworzyć plik /etc/sysconfig/vnstat i zmienić tam eth0 na wlan0.

Ciekawe jakie transfer będę miał. Staram się używać internetu normalnie, jak zawsze, aby ten test miał jakikolwiek sens.

Pozdro

Monitorowanie transferu za pomocą vnstat. to wpis z FLLOGa

import ipaddr

ImportError: No module named ipaddr

Poprawiamy google app engine helper for Django. to wpis z FLLOGa

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.

Jak dołączyć %changelog, %post_install i %post_uninstall do pliku spec używając distutils i setup.py to wpis z FLLOGa

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.

W jednym domu stali Emacs, xdebug, httpd i SElinux to wpis z FLLOGa

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.

Odpicuj backintime to wpis z FLLOGa

Jako posiadacz takowych, mam rawhide jak również Ubuntu 8.10, ostatnio straciłem swoją kartę sieciową Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 03) . Ostrzegam przed instalacją wyżej wymienionych systemów posiadaczy takiej karty sieciowej.

Jest to najwidoczniej błąd kernela w wersji 2.26.27-rc1. Podaję link do buga na kernel.org oraz na redhat.com.

Trzymam kciuki za szybką naprawę, bo na moim rawhide nie działa wifi i akutalizować nie mogę

Niedobry sterownik e1000e to wpis z FLLOGa

Moja niewiedza w sprawie Broadcom to wpis z FLLOGa