Ir para o conteúdo

Software livre Brasil

Tela cheia
 Feed RSS


28 de Maio de 2009, 0:00 , por Software Livre Brasil - | 1 pessoa seguindo este artigo.
In this blog I share technical information, write about projects I'm involved with, or about cool/fun/interesting stuff I find.

Building a Debian package out of a Rubygems' .gem file

17 de Outubro de 2010, 0:00, por Software Livre Brasil

This post is sort of a status update on ongoing work in Debian's Ruby packaging infrastructure, i.e. the tools used to package Ruby libraries and applications (not the Ruby interpreters themselves) for Debian. We have recently added two new utilities to ruby-pkg-tools:

  • gem2tgz, a tool to convert .gem files into source tarball suitable for being used as a Debian upstream tarball. This is needed because unfortunately several useful Ruby libraries and applications are only officially released in the .gem format.
  • a ruby buildsystem for debhelper, which will automatically build standards-compliant Debian Ruby packages.

To follow the steps in this post, you'll need to build ruby-pkg-tools from the pkg-ruby-extras team subversion repository (e.g., you need ruby-pkg-tools 0.18, which is not in the archive yet). You can also browse the source.

First you have to download a .gem file. Let's took fast_gettext as an example. Enter a temporary directory and download the latest version of the .gem:

$ wget

Now we need to convert that .gem file into a source tarball to be used by the Debian package:

$ gem2tgz fast_gettext-0.5.10.gem libfast-gettext-ruby-0.5.10.tar.gz

Then uncompress the source tarball, and change to the extracted source directory:

$ tar xzf libfast-gettext-ruby-0.5.10.tar.gz
$ cd libfast-gettext-ruby-0.5.10/

Inside the source directory, you need the generate the Debian package files. For now, you'll use good old dh_make:

$ dh_make -f ../libfast-gettext-ruby-0.5.10.tar.gz --single

Then we have an almost "ready" Debian package. It still misses several documentation issues that need manual checking, but for the sake of the example in this post it is good enough already.

I normally remove all the example files dh_make generates for us:

$ rm -f debian/*.ex debian/*.EX

The next step is to change debian/rules so that it will use our custom Debhelper build system. It's just a matter of adding an extra argument for the dh call. The final rules file must look like this:

#!/usr/bin/make -f

%: dh --buildsystem=ruby $@

Now we build the package. I normally use debuild for that.

$ debuild

After the build lintian will complain a lot, because our package has lots of unchanged dh_make boilerplate, but as fas as this post is concerned, the point is that the package will install the code correctly.

You can check the contents of the package with debc, to make sure everything will be where it should. Our custom debhelper buildsystem is installing Ruby libraries to /usr/lib/ruby/vendor_ruby, so it will available to all Ruby versions installed.

Now that the package is built, you can install and test it:

$ sudo dpkg -i ../libfast-gettext-ruby_0.5.10-1_i386.deb
$ irb -rfast_gettext
>> FastGettext.add_text_domain 'mutt', :path => '/usr/share/locale'; 1
=> 1
>> FastGettext.text_domain = 'mutt' => "mutt" >> FastGettext.locale = 'pt_BR' => "pt_BR" >> include FastGettext::Translation => Object >> _('Delete') => "Remover"

I tried the above with both irb (currently Ruby 1.8's irb) and irb1.9.1 (Ruby 1.9.2's irb), and it worked fine.

This custom buildsystem still misses proper handling for some special cases:

  • C extensions. They must be installed under /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/${ARCH}/
  • Libraries that are specific to a single Ruby version. This is the case for example of libraries that got included in Ruby 1.9.x itself but are still useful for Ruby 1.8, or even C extensions that do not compile under Ruby 1.9.x. Those libraries must be installed under /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/ for pure-Ruby libraries and /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/${ARCH}/ for C extensions.
  • Applications. Normally an application should use a single and well-known Ruby version, e.g. either Ruby 1.8 or Ruby 1.9.2. So that no matter which is the default Ruby version (the one started when ruby is invoked), the application will work the same.

Next steps include providing a dh-make-ruby tool that will convert the extracted tarball into a proper Ruby Debian package. This tool will eliminate the need for all the manual steps listed above after the gem2tgz invocation and before the package build (debuild).

dh-make-ruby will use the Rubygems metadata that gem2tgz puts inside the generated tarball to automatically fill important files in the package, such as debian/control and debian/copyright. It will also generate a debian/rules that is ready to go for most packages. Hopefull the generated source package will also as lintian-clean as possible.

There is an existing implementation of dh-make-ruby out there, which will be surely taken into account when building our own.

There is also lots of documentation that needs to be written/updated, and all help we get will be appreciated.

A better svn diff

6 de Outubro de 2010, 0:00, por Software Livre Brasil

Since I started using git, every time I need to use Subversion again I suffer. The output of `git diff` is so nice compared to the one produced `svn diff` that it hurts. I've alredy been struggling with that previously.

Now I think I've achieved the perfect solution to make `svn diff` behave just like `git diff`. I've documented it in this post hoping to help other poor souls like me who still have to use Subversion now and then.

Step 1: install colordiff. It's installed on Debian, so the installation required me no effort at all.

Step2 (optional): configure colordiff to use your preferred set of colors. My ~/.colordiffrc contains the following, to match the same colors used by default by `git diff`:


Step 3: create a script to be called by Subversion when running `svn diff`. In my case, I called it svn-diff and stored it in ~/bin (which is in my $PATH), but you can put it in /usr/local/bin or any other directory that is in your $PATH. The contents of ~/bin/svn-diff is the following:


 colordiff -u -L "${3}" -L "${5}" "${6}" "${7}"


After creating the script, you need to make it executable:

$ chmod +x ~/bin/svn-diff

Step 4: tell Subversion to use your script instead of plain diff on `svn diff`. To do that, locate the "helpers" section in your Subversion configuration file (~/.subversion/config), and set the diff-cmd setting to the name you gave to your custom script (svn-diff in my case):

diff-cmd = svn-diff

There is only one thing missing with regard to `git diff`: the nice pager behaviour. Git invokes that system pager in a way that less will receives the options "-FRSX". These options make less exit imediately if the output fits in one terminal screen and output the ANSI sequences (and thus colors) generated by colordiff in raw format, among other things. I couldn't find a way to emulate this: since `svn diff` will call our custom  diff command once for each changed file, we can't call the pager inside svn-diff. A comprimise is doing `svn diff | less -FRSX` , or setting the LESS environment variable to 'FRSX' and doing simply `svn diff | less`.

That's it! Now you can almost forget you are using Subversion (until you need to do some merging).

Getting more out of Gwibber

6 de Julho de 2010, 0:00, por Software Livre Brasil

Gwibber has frustrated me as a microblog reader. A minor issue I have with it is that sometimes I just can't post/reply through it. I don't know whether it is related to the microblogging services have crashed, which is not Gwibber's fault, but it would be nice if if at least warned the user with a "could not send your post" error message.

But the major issue I have with it is that I cannot see enough back in time: since I definitively do not check it all the time, I often lose posts that were not done in the last 24 hours. I tried to solve this by unfollowing people that post a lot, but it did not solve the problem.

I've had read that the Twitter API , which is supported by StatusNet at, supports a count argument, which indicated how many posts will be provided, and that it defaults to 20.

Then I did what every programmer should do: look at the source code. I looked inside the implementation of account support in Gwibber source code, and found out that it already uses this parameter, although there is no user interface for setting it. Every account has a receive_count attribute that defines how many posts will be fetched from the servers, and it defaults to 20.

While there is no UI for receive_count, you'll need to set this attribute directly in gconf. I used gconf-editor for that, but there are a couple of other options out there. Go to apps/gwibber/accounts, find your accounts, and add a new integer key/value pair there, with key "receive_count", and the value you want to.


setting receive_count with gconf-editor

Distraction-free writing with vim and awesome

4 de Junho de 2010, 0:00, por Software Livre Brasil - 1Um comentário

I've recently learn about distraction-free text editing from Lucas, and really liked the idea. Turns outs it is pretty easy to implement it with my beloved vim text editor.

Removing all distraction while using the console vim is trivial. I just need to switch my awesome workspace to full-screen layout, and that's it. The terminal window running vim will take the entire screen space, and then it's me and vim. No menus, no buttons, nothing.

Achieving the same effect with gvim is a bit more tricky: besides putting the awesome workspace to use full-screen layout, you have to turn off both the menus and the toolbar. To do that, I mapped the F11 and F12 keys to turn the menus off and on, respectively, by adding the following lines to my ~/.gvimrc:

map <F11> :set guioptions-=m<CR>:set guioptions-=T<CR>
map <F12> :set guioptions+=m<CR>:set guioptions+=T<CR>


You can check out the result in the above screeshot. Yes, that is my entire screen.

The tip for toggling menu and toolbars came from the vim wiki.

You ask me: what's the point of running gvim if you are disabling the menus and the toolbar? Several reasons: the fonts look nicer in gvim, the colors are better than the console ones, and I can turn the menu back on if I need (for example to do something I do not remember the command for).

A little more impressive

16 de Maio de 2010, 0:00, por Software Livre Brasil

Impressive is a slide presentation application. Not a presentation authoring  application, it does very well a single job: presenting. To create the slides, you can use LaTeX and Beamer, or export a PDF file from, or (put your favorite slide authoring tool here). Impressive is packaged in Debian, and probably in other operating systems as well, so using it requires no effort at all.

Impressive has very nice features, such as an overview screen displaying thumbnails of all slides, zooming, highlighting specific areas of the slides, a spotlight that follows the mouse and even the possibility of scripting your presentations with arbitrary Python code.

Another great impressive feature is its collection of transition effects.I've just sent out a small contribution, adding a new transition effect: fade in/fade out: the current slide is faded out to black, and then faded the black in the next slide.


This seems to be the default transition effect in Apple's Keynote, and I must admit that it is very cool and I wanted it. :-)

So, with the patch I've just sent out, I hope to contribute with making impressive a little more impressive than it already is.

update(17/05): I already got a reply from Impressive's author Martin Fiedler, and the transition was already included in the subversion repository. His implementation is a lot better than mine. :-)