sierpień 3, 2008
FEver is a project which aims to make it easy to track upstream in Fedora. All that has to be specified are name of the package to be checked, regular expression and URL. FEver’s task is just to download that URL, look for regular expression and return the newest one. Then, the another script just notifies about it in Bugzilla. It provides enough means to check a lot of packages but it’s not enough. Some of packages have version strings in Release tag etc. The old FEver could not check them.
That’s why it needed to be rewritten. New fever (no longer capitalizing) thanks to its S-Expressions-like syntax will be able to check almost every package. In order to show how it will look like, I’m going to show two examples.
The first one is openarena, nice FPS game based on Quake III engine. We can use yum list openarena to find out that its newest version in repo is 0.7.7. We can also check that its newest available version is 0.7.7 as well. In its download site there are full versions with dots in it however filenames are without it (I always prefer checking filenames most). So what can be done to compare 0.7.7 to 077? Of course dots need to be removed from the first string. Let’s see how the comparison can be done in new fever:
(cmp
(shell "echo $version | tr -d ." (koji_get_dict "openarena"))
(re "/oa(\d+?)(?:\D+).zip" (get "http://openarena.ws/files.html")))
I know it may look a bit complicated but in fact it isn’t; furthermore fever will have some convenient methods for the most frequent cases later. Ok, so let’s analyze how the sexpression works. First, there’s cmp method which just compares two given strings using rpmvercmp algorithm. Next, we have shell (its alias - $ - can also be used) which returns the output of first parameter executed in shell; the second parameter can be either string or dict. If it’s a string, its value is stored as $var variable; if it’s a dict then variables $key = value are created. koji_get_dict is a method which returns (for the time being) four variables: release, version, nvr and relnotag (release without disttag). re function just returns the newest match in second argument in this case; get, as you can guess, just downloads url.
So that’s how openarena can be checked. Let’s check ekg2. Ekg2 is a multi-protocol instant messaging app. Its newest version is 0.2-0.4.rc1. In its official site 0.2-rc1 can be found. So ekg2 has important “rc1″ in release tag but useless “0.4″ before it. This code (which will probably be more elegant in the future) makes it possible to check ekg2:
(cmp
(re ".*-(.*?)-.*\.(.*?)\.fc\d+$" (getitem (koji_get_dict "ekg2") "nvr"))
(re "ekg2-(0.*?).tar.gz" (get "http://ekg2.org/download.php")))
The most important part is the first re. It uses a regular expression to get rid of disttag and every useless part in NVR. So it returns version and last part of release: that are two groups. What does re do with several groups? By default returns them joined by “-” character. It can be changed by adding third parameter and set to e.g. “\1*\2″, where \1 are \2 are group numbers. getitem is an equivalent of python’s operator.getitem.
I hope you like the new fever and will use it when it’s done 
if you have any questions or proposal, feel free to express them 
Posted by ecik under fedora, fever | Komentarze (2)
marzec 26, 2008
Akt 1 - wtorek, 25 marca 2008
Zapalony użytkownik Fedory, którego w dodatku można nazwać deweloperem dystrybucji ucieszył się niezwykle, gdy na liście dyskusyjnej szanowany, znany i lubiany Jesse Keating ogłosił wydanie przesuniętej o pięć dni wersji beta Fedory z numerkiem 9. Czym prędzej w swojej muzycznej przeglądarce internetowej włączył odpowiednią stronęi polecił programowi BitTorrent, aby Fedora-9-Beta-Live-x86_64 rozpoczęła swoją drogę na dysk twardy. Czynność ta trwała nieco dłużej, niż szanowny użytkownik mógł przypuszczać, na co wpływ mogła mieć niewielka ilość peerów na początku pobierania. Dzielna społeczność opensource’owa niedługo potem postarała się jednak, by plik był łatwiej ściągalny i dzięki temu wykorzystując maksymalne możliwości przepustowości łącza znalazł się na dysku. Stało się to o godzinie 17:38.
Sprawdźmy sumy SHA1 - pomyślawszy, użytkownik wpisał sha1sum Fedora-9-Beta-Live-x86_64.iso. Jego oczom ukazał się oczekiwany rezultat 424797f7a568726cc76c66735e8b63fb6aaea228. Wtedy wystarczyło już znaleźć odpowiedni nośnik typu RW i zacząć wypalanie. Przebiegło ono bez większych trudności i użytkownik mógł już z uśmiechem na twarzy przystąpić do ponownego uruchomienia komputera i poznania uroku nowej wersji Fedory.
Warto tutaj nadmienić, że najważniejszym powodem, dla którego ów użytkownikowi zależało na sprawdzeniu jakości działania dystrybucji były problemy z dźwiękiem, będące jego zmorą w używanej na co dzień Fedorze 8 (hałas zamiast dźwięku w niektórych aplikacjach uruchamianych przy pomocy WINE lub DosBoksa). Tymczasem komputer zrestartował się i stało się to, czego użytkownik się spodziewał - bo zdarzało się to przy każdej dystrybucji typu Live. Chodzi o “nielubienie się” otwartego sterownika nv z kartą graficzną - zamiast obrazu widać jedynie kolorowe paski.
Trzeba zainstalować binarne sterowniki nVidii - pomyślał - ale najpierw potrzebna jest sieć. Automatycznie wklepał system-config-network-tui i… zdziwił się. Pojawiło się niebieskie okno, które chwilę później znikło. Z niedowierzaniem wpisuje system-config-network-tui raz jeszcze, ale wynik był ten sam. Standardowa metoda konfiguracji sieci nie działała. Zaświtała użytkownikowi taka myśl, że to może być wina wprowadzonego na szerszą skalę w F9 Network Managera. Po starannym sprawdzeniu wszystkich możliwości, skonkludował, że NetworkManager nie daje żadnej konfiguracji z poziomu wiersza poleceń. Próba naprawienia NM zajęła dość wyraźny kawałek czasu. W końcu, nie wytrzymawszy, wyłączył wszystko co z NM związane, zamontował dysk ze swoją Fedorą i skopiował kilka plików konfiguracyjnych i osiągnął zamierzony efekt. Sieć działała.
Na twarzy użytkownika wyraźne już było zmęczenie spowodowane problemami sieciowymi, więc liczył, że instalacja sterownika graficznego nie sprawi większych problemów. Przeliczył się. Ku jego zdumieniu kmod-nvidia pociągnęło ze sobą takie zależności jak gcc, gcc-c++, binutils czy choćby wget (który nie znajduje się w domyślnym zestawie pakietów Live!). To wszystko dało łącznie 48 MB do pobrania. Łącze nie działało wtedy na najwyższych obrotach, więc użytkownik spasował. Odłożył testowanie na kolejny dzień.
Później jeszcze, poczytał kilka manuali, by dowiedzieć się jak szybko i efektywnie może skonfigurować sieć nie wyłączając nawet NetworkManagera. Cały problem tego dnia polegał na nieznajomości przez niego polecenia route co uniemożliwiło ustawienie poprawnej bramy domyślnej. Ale nauczony doświadczeniem i dokumentami, optymistycznie patrzył w przyszłość…
Akt 2 - środa, 26 marca 2008
Tym razem użytkownik nie włączał już w ogóle trybu graficznego, przy uruchomieniu Live polecił, aby system działał w trzecim poziomie uruchamiania. Dzięki nabytej w dniu wcześniejszym wiedzy, bezproblemowo skonfigurował sieć i mógł szybko rozpocząć ściąganie. W międzyczasie zainteresowało go dlaczego zwykłe moduły do kernela wymagają pakietów związanych z budowaniem paczek i programowaniem. Okazało się, że wprowadzono Akmods, które sprawia, że moduły kernela są kompilowane przy uruchomieniu systemu (jeśli nie zostały wcześniej). Użytkownik uznał to za mądre rozwiązanie dla wersji deweloperskiej dystrybucji, ale w finalnej oczekiwałby jednak starego rozwiązania (bo po co zwykłemu użytkownikowi np. gcc? - pytał retorycznie). Gdy już wszystkie pakiety się poprawnie ściągnęły i zainstalowały, użytkownik poprawił plik xorg.conf (sedem, gdyż Live nie instaluje vima ani emacsa…) i z wielkim oczekiwaniem wpisał telinit 5. Niestety. Ku jego zdumieniu dostał informację, że nie ma odpowiednich plików, by skompilować moduł kernela.
Krótkie dochodzenie wykazało, że przyczyną takiego stanu rzeczy jest fakt, iż wersja kernela, z którą włączył się Live to 2.6.25-0.121.rc5.git4.fc9, natomiast nagłówki i paczka -devel z repozytorium rawhide ściągnęły się w wersji 2.6.25-0.150.rc6.git7.fc9. Potem okazało się, że nagłówków z wersji z bety już w ogóle nie ma w repozytorium. Użytkownik musiał więc uruchomić lynksa i dzięki koji ściągnąć wymagane pakiety. To wszystko zaczęło go jednak coraz bardziej denerwować. Problemy piętrzyły się jak Himalaje.
W końcu osiągnęły Mount Everest. Wszystkie paczki znalazły się na dysku i wystarczyło wpisać akmodsd, by moduł do kernela zaczął się kompilować. I tak działo się przez sekund kilka, aż nagle na ekranie ni stąd, ni zowąd pojawił się komunikat z syslogd, który mówił o błędzie wejścia/wyjścia ext3. System stracił responsywność, wykonanie jakiejkolwiek czynności tym samym stało się niemożliwe. Rozdrażniony użytkownik wyciągnął prawy palec wskazujący i nacisnął przycisk Reset na obudowie. Zraził się bardzo do wydania beta swojej ulubionej dystrybucji…
Posted by ecik under fedora | Komentarze (10)
marzec 3, 2008
Jakiś czas temu natknąłem się na projekt REnouveau, który polega na uruchomieniu na swoim komputerze odpowiedniej aplikacji, która przeprowadziwszy pewne testy, zapisuje ich wynik do plików. Następnie wyniki należy posłać do ekipy ekipy nouveau i w ten jakże prosty sposób możemy wspierać wolny sterownik. Postanowiłem przygotować paczki do tego sympatycznego narzędzia wraz z krótkim opisem co i jak.
Read more…
Posted by ecik under fedora, renouveau, rpm | Komentarze (2)
styczeń 14, 2008
Tym razem zainteresowanych pierwszym kandydatem do wydania kadu zapraszam na wiki projektu, gdzie znajduje się informacja o tym jak uruchomić proste, tymczasowe repo z nowymi pakietami.
Posted by ecik under fedora, kadu, rpm | Komentarze (1)
grudzień 28, 2007
Kolejne wydanie kadu spaczkowane. To co różni to wydanie od poprzednich to totalnie przebudowany spec, stukrotnie piękniejszy od poprzednich
Nie ma submodułu kadu-audacious_mediaplayer, ponieważ nie kompiluje się z nową wersją audaciousa.
Życzę miłego testowania!
http://ecik.nonlogic.org/rpm/kadu/beta1/
Posted by ecik under fedora, kadu, rpm | Komentarze (0)
grudzień 1, 2007
Kilka dni temu wydano nową wersję kadu, a tutaj już gotowe paczki do Fedory ;). Z różnych względów nie mogą one na razie trafić do repozytorium dlatego udostępniam je pod adresem: http://ecik.nonlogic.org/rpm/kadu/. Tamże należy wybrać odpowiednią architekturę i ściągnąć paczki. Do ich instalacji użyć albo rpm -Uvh, albo yum localinstall. Sporo dodatkowych modułów, które były w porzednich wersjach teraz albo nie działają, albo się nie kompilują więc jest ich całkiem mało.
Czy tak czy owak życzę owocnego testowania (bo sam mam na to mało czasu) i zgłaszania mi błędów.
http://ecik.nonlogic.org/rpm/kadu/
Posted by ecik under fedora | Komentarze (0)
listopad 9, 2007
Ja rozumiem, że życie paczkera nie musi być usłane różami.
Rozumiem, że deweloperzy dbają głównie o to, by im wygodnie rozwijało się aplikację.
Rozumiem, że dana aplikacja może wymagać sporego nakładu sił, by się dała zmienić w RPM.
Całkowicie jest dla mnie jasne, że jej struktura nie musi być zgodna z FHS.
Rozumiem i nawet cieszę się, że twórcy pozwalają (pozornie) na pewną dowolność.
Rozumiem, że paczkowanie gier może wymagać pisania dodatkowych wrapperów, aby wszystko mogło być na swoim miejscu.
Raduję się, gdy widzę, że mogę za pomocą podawanych parametrów zmienić domyślne zachowanie aplikacji.
Rozumiem, że to dla dobra potencjalnych użytkowników.
Rozumiem, że to po to, by każdy mógł mieć aplikację niemal dowolnie spersonalizowaną.
Ale…
Dlaczego długie i wytrwałe próby doprowadzenia do tego, by aplikacja się choć uruchamiała mogą zostać skwitowane iście durnym komunikatem:
ERROR: Server has different base game directory (basewsw) than the client (../../usr/share/warsow/)
Tego zrozumieć nie potrafię.
Posted by ecik under fedora, rpm | Komentarze (0)
październik 16, 2007
Wreszcie! - mogą zakrzyknąć ludzie obserwujący to, co się dzieje w kwestii formatu daty w glibc. Otrzymałem wczoraj maila z bugzilli o następującej treści:
The current cvs contains changes according to the results of the poll
Przecierałem oczy ze zdumienia, ale sprawa okazała się prawdą. W polskiej lokalizacji ukazał się dodatkowy komentarz:
% The abday, abmon, and d_fmt information has been changed (back) to match
% the preference expressed in the poll organized to get some concensus.
% The results were not entirely clear on all easpects but the choices
% here seem to have the most support. For more details:
%
% https://bugzilla.redhat.com/show_bug.cgi?id=242296
%
Sam miałem pewne wątpliwości co do ankiety, ale odeszły one w niepamięć, gdy dotarło do mnie, że wreszcie znów w glibc zobaczymy trzyliterowe skróty nazw miesięcy i tygodni. Skrócona data przyjmie zaś format np. 01.01.2007. Oznacza to, że wreszcie nie trzeba będzie stosować mojego własnoręcznie skomponowanego patcha do zmiany format na ludzki (przyznaję, że rzymskie “skróty” nazw miesięcy są niebywale nietrafione).
Wreszcie nadszedł koniec wielomiesięcznej dyskusji na sourceware, z której nie wynikało nic i w której każda strona uparcie trzymała się swoich racji. Osobiście sądzę, że nasza strona miała więcej racji niż przeciwna, niemniej z drugiej strony musiało to wyglądać tak samo.
Najweselsze we wszystkim jest to, że odniosłem wrażenie, że szaleństwo jednak nie zwycięży świata
Posted by ecik under daty, fedora | Komentarze (4)
sierpień 29, 2007
Kilka dni temu przyszła najwyższa pora na zainstalowanie presto czyli plugina dla yuma, dzięki któremu nie trzeba ściągać całych RPM-ów, a jedynie DeltaRPM-y zawierające różnice między dwiema poszczególnymi wersjami danego pakietu. W praktyce umożliwia to ściąganie znacznie mniejszej ilości danych, co jest jak najbardziej pożądane
Aby wgrać presto trzeba ja najpierw oczywiście zainstalować:
yum install yum-presto
Następnie przygotować repozytorium, aby yum wiedział gdzie owych deltarpmów poszukiwać. Aby to zrobić należy w pliku /etc/yum.repos.d/fedora-updates.repo dopisać:
deltaurl=http://lesloueizeh.com/f$releasever/$basearch/updates
I już możemy aktualizować pakiety ciesząc się z zysków jakie mamy Czasem zdarza się, że zyski sięgają nawet ponad 90%!:
Size of all updates downloaded from Presto-enabled repositories: 525K
Size of updates that would have been downloaded if Presto wasn't enabled: 12M
This is a savings of 96 percent
Nie da się ukryć, że robi spore wrażenie. Naturalnie - nie zawsze jest tak dobrze, może się też zdarzyć, że danej paczki nie ma w postaci deltarpm (jeśli zainstalowana jest zbyt stara wersja). Generalnie jednak presto spisuje się nad wyraz dobrze i polecam go zainstalować i przetestować (o ile ktoś tego jeszcze nie zrobił ;)).
Posted by ecik under fedora, presto, yum | Komentarze (4)
lipiec 31, 2007
Last.fm oprócz tego, że wszystkim kojarzy się z fajnym serwisem, w którym możemy dzielić się z innymi słuchaną muzykę, posiada także swojego klienta pozwalającego słuchać stacji radiowych. Spaczkowałem go ostatnio i zgłosiłem nawet review requesta. Niestety, - okazało się, że program zawiera w sobie patentowany kod. Ponieważ nie mam aktualnie chęci zostawania paczkerem livny, umieszczam paczki z last.fm tutaj.
http://ecik.nonlogic.org/rpm/last.fm/ - tam paczka źródłowa i binarna dla x86_64. Jeśli ktokolwiek zbuduje to dla innych architektur niech mi prześle to umieszczę to na serwerze.
Posted by ecik under fedora, rpm | Komentarze (3)
