The late Fedora Summer coder

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.

Comments

Cum să actualizezi metadatele yum în mod automat

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"
Comments

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

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"
Comments

Linux - After install work

It’s distro-hopping season again and I chose debian this time. I might explain my reasons for that somewhere else. Here’s a list of stuff I need to do on every install in order to get comfy with my new distro. (There’s a sort of meme floating around).
I use gnome!

  • Get 6 virtual desktops.
  • Set some basic can’t-live-without-keybindings Ctrl+_number_ for switching between desktops and Alt+T for launching a gnome-terminal.
  • Clean up my desktop. I really hate every kind of clutter on my desktop, so I delete everything. Almost everything can just be deleted, except for the Home, Trash and Computer icons. Fire up gconf-editor and go to apps>nautilus>desktop to uncheck everything. While we’re at it, let’s also enabling deleting in nautilus (it normally only lets you send stuff to Trash), by checking enable_delete in nautilus>preferences. Nautilus>Edit>Preferences>Behaviour – always open in browser windows – so it doesn’t spam me with 1000 windows to the world.
  • Next is <package manager=""> install bash-completion and adding this to my .bashrc: . /etc/bash_completion.
  • Time to get my .vimrc from wherever i happen to be keeping it at the time. you can check it out now here.
  • Nowadays, as I’ve got really lazy, I also set up automatic login (you can do that from System>Administration>Login Window. That basically bypasses gdm.
  • Get myself into some better groups like: wheel/admin/sudo, storage/disk(so nautilus can mount disks), by editing /etc/group.
  • You might also want to take a look at http://art.gnome.org if you’re the type. I know it’s a bit outdated, but the interface is a whole lot better than *-look.org
  • Here’s a list of apps I use regularly: Firefox, gnome-terminal, vim, ipython, git, xchat, evolution, pidgin, deluge, banshee/amarok, gnome-mplayer.
Comments
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.