Introducing the Debian packaging tutorial

February 17th, 2011 by lucas

One of the common complains about Debian packaging is that it’s hard to learn because, while there is quite a lot of high-quality documentation, it is often written more as a reference manual than as a tutorial: it’s great if you already know everything and want to check some detail, but not so great if you want to learn everything from scratch.

I have been volunteered (i.e, someone decided I volunteered) for a “Debian packaging” tutorial at work, so I decided to give a try at tackling this issue. I also volunteered (voluntarily this time) for a similar talk at RMLL 2011 to make sure I would be forced to do the work and prepare the actual tutorial. I’m also considering teaching this next year in Licence Pro ASRALL, but I haven’t made up my mind about it yet.

The result is a work in progress (hey, I still have a lot of time), but in the release-early-release-often tradition, I’m making it public now in the hope that someone will pick up the idea and do all the work for me (you never know).

I’ve decided to create a set of slides using Latex Beamer. The current version can be found here. The sources are available in a git repository, and all contributions are welcomed (including plain comments or suggestions). The last slide is the current TODO list.

Re: “please send a patch”

February 15th, 2011 by lucas

It seems that Matthew Palmer misread my blog post as a complaint against developers asking for patches in exchange of pet feature requests. He really should pay more attention, since I gave “pet feature requests” as an example of case where it would be appropriate to ask for a patch:

Of course, there are cases where it’s perfectly reasonable to ask for a patch: when the task is expected to take hours, or when the result is of limited interest to everybody except the demander.

But even then, it’s not clear. This morning I got an email from a someone involved in PHP packages maintenance, who said that Bugs Search @ UDD was a great tool, but that he would love to have a way to list all bugs affecting packages with the implemented-in::php debtag.
To produce a working patch for this would probably take him at least an hour. You need to set up a copy of the CGI on alioth, understand the DB structure, dig into the code, etc. If you don’t understand SQL and Ruby, it could be a really difficult process. Also, it’s probably quite uninteresting for him to do that, since he is unlikely to stick around developing UDD.
Instead, it didn’t take me more than 5 minutes to produce a one-liner.
The net result for Debian in that case? 55 minutes saved by a developer.

Update:
Torsten Werner wrote an angry reply to my post. It’s true that yesterday’s episode triggered my blog post, because I felt quite frustrated to have to provide a patch for something that simple, and would have preferred to use the time for a Debian task where I would be more efficient. But I was not particularly angry at that episode, since that’s something I’ve seen on several occasions. That’s also why I did not mention any team in particular.
The feature request I was making was reasonable, and cannot really be considered a pet feature request (though I might be biased with my QA hat on): mentionning in the dak templates used for bug closure that packages removed from Debian can still be found on snapshot.d.o. The fact that he thinks that addressing this himself turns him into a slave raises interesting questions.

“Please send a patch”

February 15th, 2011 by lucas

There’s a frequent pattern in the Debian community where someone would suggest an improvement to some package or service, and the person responsible for it would reply with “please send a patch”.

Of course, there are cases where it’s perfectly reasonable to ask for a patch: when the task is expected to take hours, or when the result is of limited interest to everybody except the demander.
But often, it would be much more efficient for the person responsible for the service to take 5 or 10 minutes to make the change, than for the demander to spend half an hour learning how to contribute to this service, writing an untestable patch, and sending it back to the person responsible for the service for integration.

It is important to see this problem as the issue of maximizing the usefulness of the resources we have. Often, we are in a situation where we could either:

  • spend 30 minutes on a service we don’t know, just to push one change
  • spend 30 minutes making three or more changes that others would like to see in a service we know

It would be much better if, instead of saying “Please send a patch”, people would say “Are you interested in contributing a patch, or should I make the change myself?”. Remember that each time you ask someone to take some time to contribute a patch in an area where he is not an efficient contributor, you take some time away from him that could be used to contribute something in an area where he is efficient.

mutt + notmuch = perfect mail setup?

February 6th, 2011 by lucas

Following Our Leader, I’ve just switched to using notmuch with mutt for searching (instead of maildir-utils, previously). I strongly recommend this setup to all mutt users.

As a bonus, accented characters (é, è, …) are now handled correctly while searching, which is quite useful in french.

Giving up on Ruby packaging

January 2nd, 2011 by lucas

I have finally reached a decision regarding my involvement in the Debian Ruby packaging efforts. I have decided to stop. This has been a very hard decision to make. I have invested huge amounts of time in that work over the years. I still love the language, and will continue to use it on a daily basis for my own developments. I still hope that it will succeed. I know that some people will be disappointed by that decision (and that others will think “your work was useless anyway, people should use RVM and rubygems”).

But I also know that I won’t be able to push for all the required changes alone. I just don’t have the time, nor the motivation. For the record, here are the changes I would have liked to see in the Ruby community.

The core Ruby development community should mature.
The core Ruby development community is still dominated by Japanese developers. While not a bad thing in itself, it is easily explained by the fact that the main development mailing list, where most of the important decisions are taken, is in japanese. ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead.

The release management process should also improve. Currently, it looks like a total mess. The following Ruby development branches are actively maintained:
ruby_1_8 (106 commits over the last six months)
ruby_1_8_6 (4 commits over the last six months)
ruby_1_8_7 (35 commits over the last six months)
ruby_1_9_1 (4 commits over the last six months)
ruby_1_9_2 (227 commits over the last six months)
trunk (1543 commits over the last six months)

While the state of the ruby_1_8_6 and ruby_1_9_1 branches is clear (very important bugfixes only), the state of all of the other branches is rather unclear.
What’s the stable Ruby branch? 1.8 or 1.9? If it’s 1.9, why are people still actively developing in the ruby_1_8 branch? How long will they continue to be maintained in parallel, dividing the manpower? Is a Ruby 1.8.8 release to be expected? Will it be ABI/API compatible with 1.8.7? Is the ruby_1_8_7 branch really bugfixes-only? How much testing of it has been done? If it’s bugfixes-only and regression-free, I should push it to Debian squeeze, due to be released in a few weeks. But would you recommend that? Due to past breakages in the ruby_1_8_7 branch, it’s unlikely that we will do it.
Is the ruby_1_9_2 a regression-free, bugfix-only branch? If yes, isn’t 227 commits over 6 months a lot? What will be the version of the next release of “trunk”? When is it expected? Will it be ABI-compatible with the current ruby_1_9_2 branch? API-compatible?
New releases in the 1.8.7 and 1.9.2 branches were done on december 25th. Why were they no betas or RCs allowing wider testing? How much testing has been done behind the scenes?

Most of those questions have no clear answer. The Ruby development community should build a common understanding of the status of the various branches, and of their release expectations. Releasing on december 25th of each year sounds fun, but is releasing when everybody is on vacation really a good idea?

It would be fantastic to have something similar to Python Enhancement Proposals in the Ruby community. But having open discussions in english about the major issues would already be great.

Ruby is not just the interpreter.
The Ruby development community should clearly define what the Ruby platform is. There are some big players, like Rails, and newer interpreter releases should not be done before ensuring that those big players still work.

Also, since we have alternative Ruby interpreters, like JRuby, Rubinius and MacRuby, we need a clear process on how they integrate with the rest of the ecosystem. For example, having each of them rely on their own outdated fork of the whole stdlib is ridiculous, since it’s not where they compete.

The Ruby community should acknowledge that RVM and Rubygems are not for everybody. People who say so should be laughed at. Of course, RVM and Rubygems are nice tools for some people. But it is completely wrong to believe that compiling from source using RVM should be the standard way of installing Ruby, or that all people interested in installing Redmine should know that Ruby has its own specific packaging system. The Ruby community should work with their target platforms to improve how Ruby is distributed instead of reinventing the wheel. That includes Debian, but also RedHat-based distros, for example. It is likely that it won’t be possible to reach a one-size-fits-all situation. But that’s real life.

Some people in the Ruby community should stop behaving like assholes. As one of the Debian Ruby maintainers, I have been routinely accused of creating crippled packages on purpose (FTR, I don’t think that the Debian packages are crippled, despite what the rumors says). Debian is not the only target of that. Just yesterday, someone called for abandonning YARV (the new Ruby VM in Ruby 1.9), calling it Yet Another Random Vailure. This kind of comments is really hurting the people who are investing their free time in Ruby, and is turning away people who consider getting involved. In Debian, we have had a lot of problems getting people to help with Ruby maintenance since they are getting shit from the community all the time.

So, what’s the future for Ruby in Debian?

  • For the interpreter, the two other maintainers, Akira Yamada and Daigo Moriwaki, are of course free to continue their work, and I wish them good luck.
  • For the pkg-ruby-extras team, which maintains most of the Ruby libraries and applications, the future is less clear. The team was already badly understaffed, and I feel that I should probably clean up its status by orphaning/removing the packages that are unmaintained otherwise. This won’t affect all the packages that the team maintains: some packages (like redmine) are actively maintained, and will stay.
  • For me, it just means I will have more time for other things (possibly not Free Software-related). If things improve dramatically, I might also come back to Ruby packaging at some point.

Update: there’s also a number of interesting comments about this post on this site.
Update 2: First, thanks a lot for all the interesting comments. I will make some follow-up posts trying to summarize what was said. It seems that this post also triggered some reactions on ruby-core@, with Charles Olivier explaining the JRuby stdlib fork, and Yui Naruse clarifying that all questions are welcomed on ruby-core@. This is great, really.

Trouble connecting with Nokia N900 as 3G modem?

December 25th, 2010 by lucas

If you are having trouble connecting to the Internet using your Nokia N900 as a 3G modem with Network Manager, you should check those bugs.

(In short: bug fixed upstream, but affecting the version in Debian. Using the package from Ubuntu works.)

Merry christmas!

December 25th, 2010 by lucas

Seen on The Ruby Reflector (a blog aggregator for the Ruby community):

Under no circumstance should you install Ruby, Rubygems or any Ruby-related packages from apt-get. This system is out-dated and leads to major headaches. Avoid it for Ruby-related packages. We do Ruby, we know what’s best. Trust us.

(source)

It’s always nice to see people appreciate your work. :-)

Getting mpich2 1.3.1 on Debian and Ubuntu

December 12th, 2010 by lucas

  • If you are running Debian squeeze or Debian unstable:
    mpich2 1.3.1 is available in Debian experimental. Add experimental to your /etc/apt/sources.list, then apt-get install mpich2/experimental

  • If you are running Ubuntu natty:
    mpich2 1.3.1 is available in the universe repository.

  • If you are running Ubuntu lucid or Ubuntu maverick:
    a backport has been requested, but they usually take some time to be processed. In the meantime, unofficial backports are available from http://people.debian.org/~lucas/mpich2/.

Feedback on Gandi hosting?

November 16th, 2010 by lucas

For the last few years, I’ve been a mostly happy customer of Sivit (now bought by Nerim). But recently, technical problems have become more frequent, and today, for the first time, a crash made me lose some data which was rather painful to restore from backups. Also, they are still stuck on with an ancient 2.6.16 kernel.

So, I’m looking into alternatives, and a promising one is Gandi hosting, based on virtual machines like Sivit.

  • Would you recommend it for a mission-critical server?
  • What’s your uptime? When was the last time your server had an unscheduled outage?
  • When was the last time you lost data because of Gandi?
  • What are the limits due to the Xen-based hosting? Can you run your own kernel (like the squeeze one)? Can you build additional modules (like tun)?
  • What else should I know?

Thanks!

Triaging X Strike Force bugs with UDD Bugs Search

November 3rd, 2010 by lucas

Thanks to the work of Julien Viard de Galbert, UDD Bugs Search just gained the ability to help the triaging of X Strike Force bugs.

He worked on the patch by installing his own copy of bugs.cgi on alioth. Don’t hesitate to do the same with your team!