Getting mpich2 1.3.1 on Debian and Ubuntu

  • 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

Feedback on Gandi hosting?

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?


Mini DebConf Paris 2010

So, I’m (almost) back from the first edition of MiniDebConf Paris, which was a success thanks to the great organizing skills in panic mode of Carl Chenet and Mehdi Dogguy. I think that everybody is already looking forward to the next edition.

I met lots of people, and it was great to be able to finally put faces on names from the french free software community. I gave two talk there, the first one on Debian and Ubuntu (slides), the second one on Debian Quality Assurance (slides), which both went well (I think).

I also hacked a bit:

  • I added tags and “claimed by” to UDD Bugs Search.
  • I worked on my piuparts replacement (which really needs a sexy name ; I’m open to suggestions), processing the results, making some improvements to the script, and filing 16 RC bugs.

If you want to help me, here are some easy tasks that need takers (it’s unlikely that I’ll be able to tackle them anytime soon):

  • One missing thing in UDD Bugs Search is information about the deferred/delayed queue. Unfortunately, the ftp-masters’ status information is not available in a machine-parseable format.
    • Improve dak code to also export the data in a machine-parseable format (JSON, YAML). I was told the changes are to be done in dak/
    • Write the corresponding UDD importer (actually, that’s a 30 mins job for me, so I could easily find time to do it if the data was available).

    Update: done!

  • Another missing thing is comments (as on I don’t really have good ideas about how to implement them, so if you want to tackle that with your own idea, go ahead. (It’s probably easy to setup a copy of bugs.cgi on alioth if you are not a DD). The CGI is in Ruby.
  • Help me process the logs of my piuparts replacement, and file the bugs. I don’t have any good scripts to automate bug filings yet. You need a good understanding of packages dependencies and maintainers scripts, but it’s a good way to learn, too. (I would need to regenerate the full results first, so talk to me if you are interested)

One of the other things I’d like to do is discuss ways to improve the synchronization of UDD (currently, it’s synchronized at arbitrary times, while we could sync Sources+Packages just after dinstall, for example).

How to demotivate people (Re: Making Debian Responsible For Its Actions)

In my Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ, I wrote The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable).

Zed A. Shaw just provided a very good example of that. Quoting the most juicy parts:

It’s simply a tactic to make sure that you are stuck on Debian.

If we look at this problem from an open source perspective, Debian is at a minimum being a horrible citizen.

What is happening is control is not aligned with responsibility. Debian has taken control of the software package and recrafted it for their very narrow set of system administrator users. However, they refuse to take responsibility for the defect and quality problems they create. Instead I end up being responsible for their mistakes, which is wrong.

If Debian is in control, then Debian should be made responsible. That’s the only way to get them to change it. If they don’t want to be responsible, then they should let me be in control.

I’m imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen.

If you write software and you’re sick of Debian screwing up your gear, then shoot me ideas for how we can make this happen. I think that if enough of us band together to make Debian responsible for its actions we can actually get them to start asking us before they package our software to find out how we think it should be packaged.

On the technical part of the post:

The problem that Zed is experiencing is unknown to me, and also to the Debian and Ubuntu bug trackers. To my knowledge, rubygems doesn’t not require openssl or net/scp to work, and a simple grep through the sources kind-of confirms that. But of course, that blog post was written as a rant, not as a proper bug report.

My best guess is that the gem that Zed is installing requires openssl and net/scp. But of course, rubygems can’t just depend on all the libraries that applications or libraries installed via rubygems could possibly require. Regarding openssl, we had a problem in Ruby because of the licensing situation of Ruby (dual licensed GPLv2+ and Ruby license, linked with openssl, which might raise some eyebrows), so it was split off the main standard library package until recently (and, apparently, in the version Zed is using). For net/scp, it is not part of the standard library, and not a dependency of rubygems, so I don’t see why Zed expects it to be installed.

On the rest of the post:

Following my last post, several people volunteered to help with Ruby on Debian (and Ubuntu). In particular, Laurent Arnoud has been doing some fantastic work fixing the pkg-ruby-extras team’s RC bugs. Also, all the messages of support both in the comments of my last post were very much appreciated.

But I’m really wondering why the Ruby community generates so many poisonous people. All my work on Debian is done on a volunteer basis, and it’s really hard to get so much shit from it.