Revolution blahg

The late Fedora Summer coder

mapleoin@bluepink.ro (Oin Maple) — Sun, 25 Jul 2010 14:00 GMT

I started my Fedora Summer Coding last week. Although most people started almost two months ago, I chose (and was allowed to – Yay, FSC!) a different schedule because I just finished college last week.

This summer I’ll be working on a new project for Fedora – Copr. Fedora Copr will allow any Fedorian to have their own package repository with packages built and hosted by Fedora’s Infrastructure. My mentor this summer will be Toshio, I’ve always enjoyed working with him and this summer will be no different. Here is my actual FSC proposal. Although the things written in that proposal are turning out to be a bit inaccurate, it’s still a good bird’s eye view of what I’m going to do this summer.

So about the first week. Things started really slow. I did a lot of orientation, certainly more than I thought I would. I hadn’t used TurboGears2 before, though I had worked with TurboGears 1.x on Fedora’s pkgdb. When I started out I had only a TG2 automatically generated skeleton app – well it’s mostly the same now, though at least I now know a lot more about what’s in there. The fact that I had to start it up myself meant I had to learn a lot of things about TG2 that I would’ve normally just copied from other parts of a fully-functional project. And that was a great experience. In a way it’s fulfilling to be able to pioneer things in this way ;). I’m trying to only ask my mentor questions about designing the actual app and solve my “How do I … in TurboGears/Python?” questions elsewhere. My mentor has always given me a lot of independence when working on things and that feels really good, though at times I feel inexperienced. There’s the thought that the project I’m working on will be used by a lot of technical users and I’m really not sure what my decisions’ impact will be on the whole project.

I’m mostly on time with my mock-up schedule because I had set the first week for orienteering. I also wrote the DB schema for Coprs, though that was on the second week. That doesn’t mean I’m ahead of schedule however, because I’ll probably have a lot to work on the Copr controllers, and a lot of documenting and designing.

I’m proud that I setup testing after a day of wading through the scattered documentation of TurboGears2 testing. There’s mostly no documentation on testing on the TurboGears2.0 docs website. So I went to the python nose webpage. But they don’t have any info on the TurboGears2 web helpers which I needed to use. So I went to pylonshq docs about testing, but they use a slightly different syntax because they’re using paste.fixture. I finally found the TurboGears2.1 testing docs which was what I really needed. It turns out that TurboGears 2.x uses WebTest.

So now I have testing. My project is not supposed to have any web interface at this point, so writing tests is the easiest way to prove that things are actually working.

This next week I’ll probably get some work done on Copr controllers. Implementing the ability to CRUD Coprs and Repos.

Cum să actualizezi metadatele yum în mod automat

mapleoin@bluepink.ro (Oin Maple) — Thu, 18 Mar 2010 14:00 GMT

Unul dintre lucrurile care mă enervează cel mai tare ca utilizator desktop la yum e că de fiecare dată când vreau să caut sau să instalez un pachet, trebuie să aștept câteva secunde bune până își actualizează metadatele pentru toate depozitele active. Astăzi am avut timp să caut o metodă de a scăpa de neplăcerea asta și a fost destul de simplu de găsit.

Rezolvarea nu este să dezactivăm complet actualizarea metadatelor, pentru că am putea încerca să instalăm pachete a căror dependințe au fost actualizate și a căror versiune exactă nu se mai găsește în depozit => dependency hell.

Se pare că există un program yum-updatesd (su -c "yum install yum-updatesd") care poate actualiza automat metadatele.

După ce l-am instalat, putem modifica /etc/yum/yum-updatesd.conf dacă vrem să facem lucruri dubioase, cum ar fi să îl lăsăm să instaleze actualizări automat — pentru că trăim într-o utopie în care actualizările nu strică niciodată nimic — sau, mai puțin dubios, doar să le descarce.

Acum că am terminat cu setările, putem porni serviciul cu:

 $ su -c "service yum-updatesd start"
 $ cacamaca

Și îl putem pune să se pornească automat la fiecare boot:

 $ su -c "chkconfig yum-updatesd on"

Cum să peticești un rpm (patch rpm)

mapleoin@bluepink.ro (Oin Maple) — Mon, 30 Nov 2009 12:00 GMT

O să vă descriu cum am aplicat un petec pentru unul dintre pachetele pentru care sunt responsabil la fedora: calibre, în timp ce așteptam să-mi vină pizza http://www.fedoraproject.ro/am-lansat-fedora-12-avans . Petecul este răspunsul la un bug report: https://bugzilla.redhat.com/show_bug.cgi?id=537525 . Calibre verifică de fiecare dată când este pornit dacă pe situl oficial a apărut o nouă versiune și dacă a apărut, îl anunță pe utilizator printr-un pop-up că trebuie să actualizeze aplicația. Cum fedora are propriul management al pachetelor și deci și al actualizărilor, este recomandat ca pachetele noi să fie instalate folosind yum; deci mesajul trebuie eliminat.

Mai întâi trebuie să descărcăm sursele actuale ale rpm-ului (în momentul în care am scris patchul, în repo-uri cea mai recentă versiune era 0.6.21-1, acum ar trebui să fie una cu patchul deja aplicat):

  $ yumdownloader --source calibre

și să le despachetăm:

  $ rpm -ivh calibre-0.6.21-1.fc12.src.rpm

Comanda va crea un nou director rpmbuild, cu subdirectoarele SPECS și SOURCES. În SPECS avem fișierul care ține toate informațiile despre cum se va construi pachetul: calibre.spec, iar în SOURCES avem sursele pachetului și toate patchurile pe care le-am creat până acum:

  $ tree rpmbuild/
  rpmbuild/
  |-- SOURCES
  |   |-- calibre-0.6.21-nofonts.tar.gz
  |   |-- calibre-cssprofiles.patch
  |   |-- calibre-manpages.patch
  |   `-- generate-tarball.sh
  `-- SPECS
  `-- calibre.spec

Mai avem de făcut un pas, ca să putem umbla prin sursele programului. Trebuie să dezarhivăm arhiva calibre-0.6.21-nofonts.tar.gz. Următoarea comandă dezarhivează și aplică patchurile pe care le avem deja:

  $ cd rpmbuild/SPECS
  $ rpmbuild -bp calibre.spec

Au apărut mai multe directoare după comanda asta:

  $ ls rpmbuild/
  BUILD  BUILDROOT  RPMS  SOURCES  SPECS  SRPMS

Cel care ne interesează este BUILD, în care au apărut sursele peticite ale programului.

Atunci când e pornit, dacă există o versiune mai nouă, calibre va afișa următorul mesaj în fereastra pop-up:

calibre has been updated to version 0.6.24. See the new features. Visit the download page?

Ca să aflăm din ce fișier vine fereastra de pop-up putem să căutăm pur și simplu o parte din textul de mai sus în sursele calibre:

  $ cd rpmbuild/BUILD/calibre/
  $ find .|xargs grep "has been updated"

Dacă ignorăm fișierele de localizare, vom afla sursa pop-up-ului:

  ./calibre/src/calibre/gui2/main.py:                    _('%s has been updated to version %s. '

Mergând în fișierul respectiv vedem că acel cod face parte dintr-o funcție numită update_found:

 
  def update_found(self, version):
  os = 'windows' if iswindows else 'osx' if isosx else 'linux'
  url = 'http://%s.kovidgoyal.net/download_%s'%(__appname__, os)
  self.latest_version = '

Ne interesează ca modificarea pe care o vom aduce să fie cât mai lizibilă pentru cei care vor modifica pachetul nostru mai târziu și să fie cât mai ușor de revenit la versiunea nemodificată. Dacă ne uităm mai atent în main, găsim următorul cod:

  if not opts.no_update_check:
  self.update_checker = CheckForUpdates()
  QObject.connect(self.update_checker,
  SIGNAL('update_found(PyQt_PyObject)'), self.update_found)
  self.update_checker.start()

Codul verifică dacă programul a fost pornit cu opțiunea no_update_check. Ar complica prea mult lucrurile dacă am modifica programul în așa fel încât să pornească de fiecare dată cu opțiunea asta așa că mai bine comentăm codul aici, ca să nu mai verifice opțiunea și deci să nu mai caute niciodată update-uri. E soluția cea mai simplă.

Ca să facem un petec ca la carte, vom face așa:

Facem o copie a fișierului main.py:

  $ cd ~/rpmbuild/BUILD/calibre/src/calibre/gui2/
  $ cp main.py main.py.no_update
  După care modificăm *fișierul inițial* și comentăm codul respectiv așa:
  # if not opts.no_update_check:
  #     self.update_checker = CheckForUpdates()
  #     QObject.connect(self.update_checker,
  #             SIGNAL('update_found(PyQt_PyObject)'), self.update_found)
  #     self.update_checker.start()

Ca să generăm petecul vom folosi gendiff din directorul de deasupra directorului rădăcină:

    $ cd ~/rpmbuild/BUILD
    $ gendiff calibre .no_update
    diff -up calibre/src/calibre/gui2/main.py.no_update calibre/src/calibre/gui2/main.py
    --- calibre/src/calibre/gui2/main.py.no_update	2009-11-16 14:21:55.200387171 +0200
    +++ calibre/src/calibre/gui2/main.py	2009-11-16 14:22:10.400510757 +0200
    @@ -221,11 +221,11 @@ class Main(MainWindow, Ui_MainWindow, De
    self.latest_version = ' '
    self.vanity.setText(self.vanity_template%dict(version=' ', device=' '))
    self.device_info = ' '
    -        if not opts.no_update_check:
    -            self.update_checker = CheckForUpdates()
    -            QObject.connect(self.update_checker,
    -                    SIGNAL('update_found(PyQt_PyObject)'), self.update_found)
    -            self.update_checker.start()
    +        # if not opts.no_update_check:
    +        #     self.update_checker = CheckForUpdates()
    +        #     QObject.connect(self.update_checker,
    +        #             SIGNAL('update_found(PyQt_PyObject)'), self.update_found)
    +        #     self.update_checker.start()
    ####################### Status Bar #####################
    self.status_bar = StatusBar(self.jobs_dialog, self.system_tray_icon)
    self.setStatusBar(self.status_bar)

Totul arată bine, deci putem să-l punem în surse:

  $ gendiff calibre .no_update > ~/rpmbuild/SOURCES/calibre-no-update.patch

Acum trebuie să modificăm spec-ul, adăugând un nou petec, incrementând release-ul, menționând motivul pentru petec și scriind modificarea în Changelog:

  @@ -1,6 +1,6 @@
  Name:           calibre
  Version:        0.6.21
  -Release:        1%{?dist}
  +Release:        2%{?dist}
  Summary:        E-book converter and library management
  Group:          Applications/Multimedia
  License:        GPLv3
  @@ -18,6 +18,7 @@
  Source1:        generate-tarball.sh
  Patch0:         %{name}-cssprofiles.patch
  Patch1:         %{name}-manpages.patch
  +Patch2:         %{name}-no-update.patch
  BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
  BuildRequires:  python >= 2.6
  @@ -72,6 +73,9 @@
  # don't append calibre1 to the name of the manpages. No need to compress either
  %patch1 -p1 -b .manpages
  +# don't check for new upstream version (that's what packagers do)
  +%patch2 -p1 -b .no-update
  +
  # dos2unix newline conversion
  %{__sed} -i 's/\r//' src/calibre/web/feeds/recipes/*
  @@ -239,6 +243,9 @@
  %{_mandir}/man1/*
  %changelog
  +* Sat Nov  29 2009 Ionuț C. Arțăriși

Gata. Asta a fost tot :). Acum putem reconstrui pachetul cu noile patchuri:

  $ cd ~/rpmbuild/SPECS/
  $ rpmbuild -ba calibre.spec

Și putem reinstala noul pachet:

  $ su -c "yum localinstall -y --nogpgcheck ~/rpmbuild/RPMS/x86_64/calibre-0.6.21-2.fc12.x86_64.rpm"

The Productive Programmer

mapleoin@bluepink.ro (Oin Maple) — Fri, 18 Sep 2009 14:00 GMT

Today I read The Productive Programmer .

I’ve already got a bunch of books piled up and waiting to be read, some of which I’ve reached the middle of and some of which I’ve read only the introduction to. I was bored today and this looked like an easy read that I could drop at any time. It is an easy read, but the fact is, it’s very catchy. It draws you in and doesn’t want to be let go. It’s a great way to spend half a day.

This could have been another one of those “94 things you need to know” books, but I think this title is way better. The tips are divided into 2 big sections and a few separate chapters within each one, giving the book some structure. One of the strange things about it is that its advice spans across 3 different platforms (*nix, OS X and Windows) and they’re all mingled together in the same chapter. I was put off by this at first, but after I’d gotten into the book a bit I realized that it is, in fact, a good idea. The whole theme of the book is programmer productivity and the reason it has this title and not a cheesy title with numbers like “94.3 productivity tips for programmers” is that the tips aren’t what’s important. The book is there to hit people in the head with and open their minds. You aren’t supposed to just use the tips provided, that’s unimportant. What’s important is that you have a shock and realize that you’ve been the wrong kind of lazy as a programmer. You’ve stopped automating, you’ve become a machine; in the author’s own words, computers have started “getting together late at night to make fun of their users”. As soon as I realized what this book was really about, I started reading the Windows tips as well. I also stopped a few times to look in my distro’s repository for tools that I had known of, but never used before, only now understanding their true purpose. There are many applications that seem just trendy at first, until you realize that even a small productivity boost is a big productivity boost. (Go check out gnome-do , I’d heard about it years ago, but never tried it until now).
The book contains tips ranging from application launchers, Firefox’s magic address bar, bash scripting commands to office productivity tips for killing distractions. Once again, the mindset is important, not the tips themselves. The big take-away from this book is beginning to constantly judge everything you do as a programmer. This isn’t new advice (at least for those who have read The Pragmatic Programmer”, which by the way is mentioned several times in this book), but I find it’s better emphasized in this book. At one point in the book, the author explains how it took his team one hour to devise a Ruby script to automate some simple task that would’ve required 10 minutes if done manually and finally only needed doing 5 times. One could say there was a loss in productivity, but as the author points out, one would be wrong. Those 50 minutes would’ve been spent with the brain turned off, whereas the hour writing the script was spent learning, focusing, practicing, gaining knowledge that can later be used on a different project. Some of us would probably have gotten bored in those 50 minutes and fallen into procrastination. That doesn’t happen when you’ve got a complex problem to solve.
That was the first part of the book, Mechanics. The second part, Practice is a bit harder to read, as it’s not just disparaged tips on very different applications. They’re quite two separate books actually. The majority of the examples in Part IIare java (they’re mostly readable even for someone who doesn’t speak the exact dialect of OOP that java uses) and this part is mostly about software construction as Steve McConnell would say, but it’s also about Java. I learned a new acronym: YAGNI which basically means that thinking ahead is bad. This is probably one of the advices that I feel the least guilty about, but which I sometime observe in people around me. Never program a feature you don’t urgently have a need for.
One of the good points of this book is the originality with which the ideas are expressed. Most of these ideas aren’t new, especially to anyone who’s read other software engineering books. The text is spiced up with little narratives of different adventures from the author’s experience as a consultant and there is also an Ancient Philosophers chapter and an explanation of the PacMan game’s way of functioning (although I didn’t understand how that’s supposed to make the game less enjoyable).

Beginning packaging for Fedora

mapleoin@bluepink.ro (Oin Maple) — Fri, 11 Sep 2009 10:00 GMT

With GSOC now over, which I should write a blogpost about soon, I’ve taken a break from pkgdb and web programming and started developing another skill.

The fact that this page is empty has been bugging me for too much time, so I set out to fix it. I also wanted to find out more about the packaging process and the road of a package before it gets accepted into fedora’s official repos which is a bit complex. This knowledge would also help me better understand the parts of pkgdb which packagers interact with.

It was not my first time trying to make a package for fedora. I think this is actually my third time. I’d given up before, scared by all the different tools and scattered documentation. In a previous life, I had made some AUR packages, but the experience is a lot different. I’m now starting to get used to all the different tools that I was scared of before, like mock and rpmlint and I can now find my way around the fedora wiki for package related information. There is a wealth of information in the wiki, but you need a lot of patience.

I started slow, with quite a complex application to package: Calibre. Having all those different distros is great when you’re a packager, because you have somewhere to look for help and the Debian package of calibre helped me a lot. It took me about two days to get a somewhat acceptable version of calibre packaged, which I then posted to redhat’s bugzilla. The following days I found more small apps to be packaged and it became easier and easier for me to do it. Last night for example, I was just browsing Hacker News as usual when I found a link to facebook’s opensourcing of their web server framework . I just rushed to the download and installation instructions page and I quickly got it packaged. I’m not saying it’s perfect, it probably needs a lot of improvement, but it was fun to do. It’s fun to think that you’re making things easier for someone and learning a lot at the same time. I now have 5 packages waiting to be reviewed and I’ve found someone willing to sponsor me into the packager group. Anyone in a package-review mood? ;)

My journey into the packaging world has been enlightening so far and the good thing is I’m just beginning. There’s a whole new world to be discovered out there and also another part of the fedora community.

Emacs la Ceata

mapleoin@bluepink.ro (Oin Maple) — Tue, 18 Aug 2009 19:40 GMT

Să folosesc blogul ăsta și altfel decât până acum.

Dacă mă are cineva în feed reader și vrea să meargă la o mică (o juma’ de duzină de oameni) prezentare emacs în politehnică, cu oamenii din Ceata (probabil e stricat situl în momentul ăsta), știți cum să mă contactați. Întâlnirea va avea loc mâine probabil după ora 18 în sediul Cetei din unul din căminele din Poli.

Ceata e o organizație de studenți din Politehnică interesați de tehnologii libere.

FUDCon Berlin

mapleoin@bluepink.ro (Oin Maple) — Mon, 29 Jun 2009 20:20 GMT

I just got back from this year’s EMEA FUDCON in Berlin with Nicu . I didn’t have time to write anything while I was there because so much was happening all the time.

FUDCon and LinuxTag

LinuxTag wasn’t really the purpose of our visit, but we got free tickets so I checked the place out for a while. There were lots of booths and some speeches (mostly in German). There were also some activities, but I really didn’t get to any of them since most appeared to be German-only. I was a bit disappointed, eLiberatica had way better talks and guests.

FUDCon was nice. The first day was a little slow to start, but the BarCamp session the next day was very interesting and diverse. More of that would’ve been nice. Some of the cool topics I enjoyed were: koji at CERN, git for hackers, Fedora EKG and UI Design. The last day was mostly random hacking by people who already had something to work on. I did a bit of pkgdb hacking on my own and then went Berlinxploring.

Berlin

The city was awesome. I haven’t been to a lot of different countries, but right now Berlin is my favourite. Its public transportation is awesome, the people are polite, friendly and everyone can speak English. There were a lot of trees everywhere, the temperature was really cool and there were wild bunnies in the parks! I separated from the crowd two times to go visit the city and I got to see some stuff I would’ve missed otherwise. It was also cool because what I did was basically ride the train and get off whenever I would see something interesting. I went to the Brandenburg gate and the Governmental district and also got a closer look of the bombed church. I also went to a cool flea market.

German Beer

The best part of the whole conference were the nights out at the restaurant, I think. I and Nicu were lucky to tag along to a few people from Red Hat before the majority of people had arrived. We got to see some nice places that way, especially thanks to Jesse’s iphone. I got to eat indian food, assembly line sushy and we were also at the local Zoo. I soon found out that my English was a bit slow and so I couldn’t keep up with their constant witty joking so I sort of gave up and switched into listening mode.
The nights-at-the-restaurant got better and better as more people arrived. We went to a small restaurant right under the railways for free pizza (thanks Red Hat!) where I met a few of the newly arrived people and had some interesting chats mostly about fedora and Red Hat.
The next day we went looking for a Sudanese restaurant, but ended up at a Cuban restaurant with cool waitresses. I got to taste the first real German beer and socialised with some of the other European guys which was really fun.
The last night was the best night. We had interesting discussions about fonetics(!), German beer, the Dutch language and RMS among other things. They also had the greatest dark German beer, which I forgot the name of. Real traditional German beer really doesn’t compare with any other beer. It’s a whole different beverage and an awesome one.

Conclusion

Overall I think it was a great experience. I got to meet a lot of interesting and smart people from all over the world who all shared a passion for their work and for Fedora.
So these are sort of the words to Nicu’s photos which explain the rest, only better.