In this blog I share technical information, write about projects I'm involved with, or about cool/fun/interesting stuff I find.

rmail: reviving upstream maintaince

15 de Fevereiro de 2015, por Antonio Terceiro - 0sem comentários ainda

It is always fun to write new stuff, and be able to show off that shiny new piece of code that just come out of your brilliance and/or restless effort. But the world does not spin based just on shiny things; for free software to continue making the world work, we also need the dusty, and maybe and little rusty, things that keep our systems together. Someone needs to make sure the rust does not take over, and that these venerable but useful pieces of code keep it together as the ecosystem around them evolves. As you know, Someone is probably the busiest person there is, so often you will have to take Someone’s job for yourself.

rmail is a Ruby library able to parse, modify, and generate MIME mail messages. While handling transitions of Ruby interpreters in Debian, it was one of the packages we always had to fix for new Ruby versions, to the point where the Debian package has accumulated quite a few patches. The situation became ridiculous.

It was considered to maybe drop it from the Debian archive, but dropping it would mean either also dropping feed2imap and sup or porting both to other mail library.

Since doing this type of port is always painful, I decided instead to do something about the sorry state in which rmail was on the upstream side.

The reasons why it was not properly maintained upstream does not matter: people lose interest, move on to other projects, are not active users anymore; that is normal in free software projects, and instead of blaming upstream maintainers in any way we need to thank them for writing us free software in the first place, and step up to fix the stuff we use.

I got in touch with the people listed as owner for the package on, and got owner permission, which means I can now publish new versions myself.

With that, I cloned the repository where the original author had imported the latest code uploaded to rubygems and had started to receive contributions, but that repository was inactive for more than one year. It had already got some contributions from the sup developers which never made it in a new rmail release, so the sup people started using their own fork called “rmail-sup”.

Already in my repository, I have imported all the patches that still made sense from the Debian repository, did a bunch of updates, mainly to modernize the build system, and did a 1.1.0 release to This release is pretty much compatible with 1.0.0, but since I did not test it with Ruby versions older than than one in my work laptop (2.1.5), I bumped the minor version number as warning to prospective users still on older Ruby versions.

In this release, the test suite passes 100% clean, what always gives my mind a lot of comfort:

$ rake
/usr/bin/ruby2.1 -I"lib:." -I"/usr/lib/ruby/vendor_ruby" "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test*.rb"
Loaded suite /usr/lib/ruby/vendor_ruby/rake/rake_test_loader

Finished in 2.096916712 seconds.

166 tests, 24213 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

79.16 tests/s, 11546.95 assertions/s

And in the new release I have just uploaded to the Debian experimental suite (1.1.0-1), I was able to drop all of the patches and just use the upstream source as is.

So that’s it: if you use rmail for anything, consider testing version 1.1.0-1 from Debian experimental, or 1.1.0 from if you into that, and report any bugs to the [github repository]( My only commitment for now is keep it working, but if you want to add new features I will definitively review and merge them.

DebConf 14: Community, Debian CI, Ruby, Redmine, and Noosfero

1 de Setembro de 2014, por Antonio Terceiro

This time, for personal reasons I wasn’t able to attend the full DebConf, which started on the Saturday August 22nd. I arrived at Portland on the Tuesday the 26th by noon, at the 4th of the conference. Even though I would like to arrive earlier, the loss was alleviated by the work of the amazing DebConf video team. I was able to follow remotely most of the sessions I would like to attend if I were there already.

As I will say to everyone, DebConf is for sure the best conference I have ever attended. The technical and philosophical discussions that take place in talks, BoF sessions or even unplanned ad-hoc gathering are deep. The hacking moments where you have a chance to pair with fellow developers, with whom you usually only have contact remotely via IRC or email, are precious.

That is all great. But definitively, catching up with old friends, and making new ones, is what makes DebConf so special. Your old friends are your old friends, and meeting them again after so much time is always a pleasure. New friendships will already start with a powerful bond, which is being part of the Debian community.

Being only 4 hours behind my home time zone, jetlag wasn’t a big problem during the day. However, I was waking up too early in the morning and consequently getting tired very early at night, so I mostly didn’t go out after hacklabs were closed at 10PM.

Despite all of the discussion, being in the audience for several talks, other social interactions and whatnot, during this DebConf I have managed to do quite some useful work.

debci and the Debian Continuous Integration project

I gave a talk where I discussed past, present, and future of debci and the Debian Continuous Integration project. The slides are available, as well as the video recording. One thing I want you to take away is that there is a difference between debci and the Debian Continuous Integration project:

  • debci is a platform for Continuous Integration specifically tailored for the Debian repository and similar ones. If you work on a Debian derivative, or otherwise provides Debian packages in a repository, you can use debci to run tests for your stuff.
    • a (very) few thinks in debci, though, are currently hardcoded for Debian. Other projects using it would be a nice and needed peer pressure to get rid of those.
  • Debian Continuous Integration is Debian’s instance of debci, which currently runs tests for all packages in the unstable distribution that provide autopkgtest support. It will be expanded in the future to run tests on other suites and architectures.

A few days before DebConf, Cédric Boutillier managed to extract gem2deb-test-runner from gem2deb, so that autopkgtest tests can be run against any Ruby package that has tests by running gem2deb-test-runner --autopkgtest. gem2deb-test-runner will do the right thing, make sure that the tests don’t use code from the source package, but instead run them against the installed package.

Then, right after my talk I was glad to discover that the Perl team is also working on a similar tool that will automate running tests for their packages against the installed package. We agreed that they will send me a whitelist of packages in which we could just call that tool and have it do The Right Thing.

We might be talking here about getting autopkgtest support (and consequentially continuous integration) for free for almost 2000 4000 packages. The missing bits for this to happen are:

  • making debci use a whitelist of packages that, while not having the appropriate Testsuite: autopkgtest field in the Sources file, could be assumed to have autopkgtest support by calling the right tool (gem2deb-test-runner for Ruby, or the Perl team’s new tool for Perl packages).
  • make the autopkgtest test runner assume a corresponding, implicit, debian/tests/control when it not exists in those packages

During a few days I have mentored Lucas Kanashiro, who also attended DebConf, on writing a patch to add support for email notifications in debci so maintainers can be pro-actively notified of status changes (pass/fail, fail/pass) in their packages.

I have also started hacking on the support for distributed workers, based on the initial work by Martin Pitt:

  • updated the amqp branch against the code in the master branch.
  • added a debci enqueue command that can be used to force test runs for packages given on the command line.
  • I sent a patch for librabbitmq that adds support for limiting the number of messages the server will send to a connected client. With this patch applied, the debci workers were modified to request being sent only 1 message at a time, so late workers will start to receive packages to process as soon as they are up. Without this, a single connected worker would receive all messages right away, while a second worker that comes up 1 second later would sit idle until new packages are queued for testing.


I had some discusion with Christian about making Rubygems install to $HOME by default when the user is not root. We discussed a few implementation options, and while I don’t have a solution yet, we have a better understanding of the potential pitfalls.

The Ruby BoF session on Friday produced a few interesting discussions. Some take away point include, but are not limited to:

  • Since the last DebConf, we were able to remove all obsolete Ruby interpreters, and now only have Ruby 2.1 in unstable. Ruby 2.1 will be the default version in Debian 8 (jessie).
  • There is user interest is being able to run the interpreter from Debian, but install everything else from Rubygems.
  • We are lacking in all the documentation-related goals for jessie that were proposed at the previous DebConf.


I was able to make Redmine work with the Rails 4 stack we currently have in unstable/testing. This required using a snapshot of the still unreleased version 3.0 based on the rails-4.1 branch in the upstream Subversion repository as source.

I am a little nervous about using a upstream snapshot, though. According to the "roadmap of the project ": the only purpose of the 3.0 release will be to upgrade to Rails 4, but before that happens there should be a 2.6.0 release that is also not released yet. 3.0 should be equivalent to that 2.6.0 version both feature-wise and, specially, bug-wise. The only problem is that we don’t know what that 2.6.0 looks like yet. According to the roadmap it seems there is not much left in term of features for 2.6.0, though.

The updated package is not in unstable yet, but will be soon. It needs more testing, and a good update to the documentation. Those interested in helping to test Redmine on jessie before the freeze please get in touch with me.


I gave a lighting talk on Noosfero, a platform for social networking websites I am upstream for. It is a Rails appplication licensed under the AGPLv3, and there are packages for wheezy. You can checkout the slides I used. Video recording is not available yet, but should be soon.

That’s it. I am looking forward to DebConf 15 at Heidelberg. :-)

An introduction to the Debian Continuous Integration project

1 de Junho de 2014, por Antonio Terceiro

Debian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages.

A new version of any of these packages can potentially break some functionality in the ruby package.

And that dependency graph is very small. Looking at the dependency graph for, say, the rails package will make your eyes bleed. I tried it here, and GraphViz needed a PNG image with 7653×10003 pixels to draw it. It ain’t pretty. Installing rails on a clean Debian system will pull in another 109 packages as part of the dependency chain. Again, as new versions of those packages are uploaded the archive, there is a probability that a backwards-incompatible change, or even a bug fix which was being worked around, might make some funcionality in rails stop working. Even if that probability is low for each package in the dependency chain, with enough packages the probability of any of them causing problems for rails is quite high.

And still the rails dependency chain is not that big. libreoffice will pull in another 264 packages. gnome will pull in 1311 dependencies, and kde-full 1320 (!).

With a system this big, problems will arrive, and that’s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for.

While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions.

Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree).

In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification.

Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information.

Durign the holiday break last year, I decided to give it a shot. I initially called the codebase dep8. Later I renamed it to debci, since it could potentially also run other other types of test suites in the future. Since early January, run an instance of debci for the Debian Project.

The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at every hour, and at the end of each batch a “global status” is updated.

Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events.

Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%.

There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system.

This is just the beginning. debci is under a good rate of development, and you can expect to see a constant flux of improvements. In special, I would like to mention a few people who are giving amazing contributions to the project:

  • Martin Pitt has been working on improving debci to support parallel and distributed workers. Being the current autopkgtest maintainer, Martin also already got some bug fixes and fixes into autopkgtest motivated by debci use cases.
  • Brandon Fairchild is a GSOC student working on improving the debci web interface to provide more useful information, display information for multiple suites and architectures, plus making the UI work even without Javascript enabled.
  • Lucas Kanashiro is another GSOC student, who is working on investigating patterns among packages that fail their test suites, so that we can figure out how we can fix them, or if there are classes of failures that are actually caused by problems in the debci infrastructure.

how-can-i-help: oportunidades de contribuição com o Debian

11 de Fevereiro de 2014, por Antonio Terceiro

Já faz um tempo desde o meu último post, e pra esse novo vou retomar o assunto do anterior — como começar a colaborar com o Debian, inspirado num post recente do Stefano.

O how-can-i-help é um programa que te mostra oportunidades de colaboração relacionadas aos pacotes que estão instalados no seu sistema: pacotes que precisam de novos mantenedores, pacotes que estão com bugs críticos, pacotes que estão com bugs críticos e vão ser removidos da testing, etc.

Outro tipo de possível contribuição que o how-can-i-help vai listar e que vai ser bastante útil pra quem quer começar são bugs com a tag “gift”, ou seja bugs que o mantenedor do pacote marcou como fáceis para serem resolvidos por novos colaboradores.

Por padrão o how-can-i-help vai rodar toda vez que você instalar um pacote, mas também você também pode rodar ele digitando how-can-i-help manualmente no terminal.

Então, se você quer começar a contribuir com o Debian, você pode começar agora mesmo com:

  $ apt-get install how-can-i-help

OBS: o how-can-i-help está disponível no jessie/testing, unstable e wheezy-backports.

Participando do projeto Debian - como começar

18 de Junho de 2013, por Antonio Terceiro

O objetivo deste post é informar pessoas interessadas em contribuir com o Debian sobre por onde começar. Existem várias formas de contribuir com o Debian: você pode contribuir com empacotamento/desenvolvimento, artwork, triagem de bugs, tradução, documentação, divulgação, suporte a outros usuários, atividades administrativas, organização da presença do Debian em eventos, e por aí vai.

Este post é uma tentativa de dar a minha visão sobre como começar a contribuir com o Debian. É possível que o conteúdo seja um pouco enviesado para contribuição com desenvolvimento/empacotamento, porque é isso que eu faço, mas eu fiz um esforcinho pra ser genérico.

Talvez faltem informações, ao algumas coisas estejam confusas. Fique a vontade pra postar um comentário lá no final.

Coisas pra se ter em mente, antes de qualquer coisa

Quem pode colaborar com o Debian

No Debian, a contribuição de todos é bem-vinda. Qualquer pessoa que tenha o conhecimento e habilidade necessários para uma determinada tarefa pode começar a contribuir com o projeto agora.

A maioria das atividades no Debian não requer nenhum tipo de permissão especial. A forma exata como a contribuição é feita depende muito da atividade específica, por isso não vou entrar em detalhes aqui.

Uma das poucas atividade que não pode ser feitas por qualquer pessoa é o upload de pacotes. Qualquer pessoa pode manter um pacote no Debian, mas o upload do pacote para os servidores do projeto precisa ser feito por um desenvolvedor oficial (mais detalhes abaixo).


Praticamente toda comunicação do projeto se dá em listas de discussão e canais no IRC. Você provavelmente vai querer se inscrever nas listas de discussão do seu interesse, e frequentar um ou mais canais no IRC.

O idioma utilizado no projeto Debian é o inglês

Lembra quando te diziam na época da escola que inglês é importante? Pois é. Para participar do Debian não é necessário ser 100% fluente, mas conseguir ler é fundamental, e conseguir escrever, ainda que só o básico, ajuda muito.

Mas não se deixe impedir por deficiências no inglês: participar de um projeto internacional vai melhorar muito o seu inglês (experiência própria), então com o tempo você vai se sentir cada vez mais à vontade.

Existe uma lista de desenvolvimento em português, que pode ser usada pra tirar dúvidas, mas na minha experiência o trabalho de verdade acontece em inglês.

Fazendo a lição de casa

Todos temos dúvidas, e como o Debian tem um escopo imenso, é normal que você não saiba alguma coisa. Ninguém sabe tudo. Mas é importante que você pesquise antes de perguntar. Primeiro porque existe a probabilidade de alguém já ter tido aquela dúvida antes, e a resposta pra ela pode já existir e estar arquivada. Segundo, porquê as pessoas que estão no projeto a mais tempo acham bem chato responder às mesmas perguntas de novo e de novo.

É possível que você não encontre a resposta para a sua dúvida. Nesse caso, não hesite em perguntar. Uma leitura interessante relacionada é o How To Ask Questions The Smart Way, que dá várias dicas de como fazer perguntas da forma mais eficiente possível. Especialmente numa discussão por email, uma pergunta feitas com todas as informações necessárias para que te seja dada uma resposta pode te economizar vários dias!

Pra contribuições nas áreas de desenvolvimento e empacotamento, você vai querer ler:

Note que os items acima representam bastante documentação. Não precisa ler tudo de uma vez só antes de fazer uma contribuição, mas saiba que cedo ou tarde as respostas pra dúvidas que você tem podem estar neles.

Formas de começar

Eu diria que existem 2 formas de começar: a primeira é fazer parte de um time existente; a segunda, específica para contribuição com desenvolvimento/empacotamento, é escolher um pacote pra contribuir. Começar se juntando a um time na minha opinião é mais fácil.

Fazendo parte de uma equipe

Hoje em dia, uma grande parte das atividades do Debian acontecem no contexto de times específicos. No Wiki do projeto há uma lista de times existentes que hoje lista mais de 130 times. Existem times de empacotamento de software em linguagens específicas (como a equipe de Ruby, do qual eu faço parte) ;existem times focados em um conjunto de pacotes relacionados, como os times de empacotamento do GNOME, do KDE, do Xfce; existem times transversais, como o time de segurança, o time de publicidade, o time de controle de qualidade, etc. Dá uma olhada lá na lista de times.

Na minha opinião a melhor forma de começar é fazer parte de um time. A chave aqui é escolher uma equipe com a qual você se identifique, o que ajuda a manter a sua motivação. Se você desenvolve em Perl, dê uma olhada no time de Perl. Se você se interessa por tipografia, dê uma olhada no time de fontes. Se você usa KDE e se interessa pelo KDE mais do que alguém normalmente se interessaria pelo seu desktop, confira o time KDE. Se você não é um(a) desenvolvedor(a), procure um dos vários times que lidam com outros tipos de atividades que podem te interessar.

Escolhido o time, você provavelmente vai querer assinar a(s) lista(s) de discussão do time, frequentar o canal do time do IRC, e começar a entender o que o time faz e como ele funciona. Se o time tiver uma lista de tarefas, tente atacar um item da lista. Se você tiver sorte os itens podem até estar classificados em níveis de dificuldade.

Se a equipe for relacionada a empacotamento, você vai querer aprender empacotamento. Acho que uma boa forma de começar a aprender é instalar o pacote packaging-tutorial e abrir /usr/share/doc/packaging-tutorial/packaging-tutorial.pdf no seu leitor de PDF favorito. Verifique se existem bugs nos pacotes do time; escolha um bug, tente reproduzí-lo no seu sistema local. Se você conseguir reproduzir, tente consertar.

Uma vez que você tenha uma contribuição a um pacote, você vai precisar que essa contribuição seja revisada por alguma outra pessoa do time, e de um desenvolvedor oficial pra fazer o upload do pacote corrigido. Normalmente em times encontrar um desenvolvedor para fazer uploads não deve ser difícil.

Escolhendo um pacote

Se você não está interessado(a) em contribuir com desenvolvimento ou empacotamento, pule essa sessão. :-)

Outra forma de começar é escolher um pacote pra contribuir. Assim como no caso das equipes, escolha um pacote que seja do seu interesse, ou seja, um pacote que você usa. Pode ser uma aplicação que você usa sempre, uma biblioteca que está instalada no seu sistema como dependência de algum outro pacote. Tente começar com um pacote simples/pequeno.

O Debian tem uma base de dados de pacotes que precisam de ajuda, seja porque o mantenedor atual está sem tempo pra manutenção e quer que alguém passe a ser o mantenedor, seja porque o pacote já está órfão a um tempo, ou seja porque o mantenedor atual queira compartilhar a manutenção com outra(s) pessoa(s). Essa base de dados se chama WNPP, e existe um interface pra pesquisar por esses pacotes em

Uma boa forma de descobrir um pacote que precisa de um pouco de carinho pra você começar é instalar o pacote devscripts e executar o comando wnpp-alert. Ele vai listar todos os pacotes que estão instalados no seu sistema e estão órfãos, ou precisam de co-mantenedores.

Você vai querer aprender sobre empacotamento. Uma boa forma de começar a aprender é instalar o pacote packaging-tutorial e abrir /usr/share/doc/packaging-tutorial/packaging-tutorial.pdf no seu leitor de PDF favorito.

Não consigo pensar numa boa forma de escolher um pacote. Eu diria o seguinte:

  1. escolha uns 2 ou 3 pacotes
  2. dê uma olhada na lista de bugs de cada pacotes
  3. escolha um bug de um dos pacotes, tente reproduzí-lo no seu sistema local.
  4. Se você conseguir reproduzir, tente consertar. A forma exata de como consertar vai depender muito do bug, então não posso ser mais específico.
  5. se você não entender o bug, ou não conseguir reproduzir, talvez você queira relatar isso no bug report. Talvez você queira voltar para o passo 3.

Se você escolheu um pacote, leia a documentação sobre o WNPP, e faça o procedimento pra dizer que você quer adotar o pacote. Verifique se existem novas versões do pacotes lançadas pelo desenvolvedor original (que a gente chama no Debian de upstream). Tente atualizar pra essa versão.

Quando você tiver o pacote pronto, você vai precisar encontrar um desenvolvedor oficial pra revisar o pacote. Essa pessoa vai revisar o seu trabalho, eventualmente pedir pra você fazer algumas (ou muitas) correções ou melhorias no pacote, e por fim vai fazer o upload.

Caso você queira começar por um pacote, o grupo de orientação (‘mentors’) é um bom lugar pra começar, tanto em termos de orientação como em termos de achar um desenvolvedor pra revisar o seu pacote fazer o upload pra você.