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/.
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?
November 3rd, 2010 by lucas
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!
October 31st, 2010 by lucas
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
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).
- Another missing thing is comments (as on bts.turzimmer.net). 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).
October 30th, 2010 by lucas
Launchpad bug #643691: Please sync ubuntu-dev-tools 0.103 (universe) from Debian experimental (main)
Did development of ubuntu-dev-tools move from Ubuntu to Debian? :-)
September 29th, 2010 by lucas
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.
September 18th, 2010 by lucas
Many changes to the UDD-backed Debian Bugs Search:
- moved to http://udd.debian.org/bugs.cgi
- new filters:
- Bugs affecting stable
- Packages with outdated binaries in squeeze or sid
- Packages with different versions in squeeze and sid (that need to migrate)
- Packages which are newer in Ubuntu than in sid (good candidates for patches)
- Much nicer layout
- Some SQL optimization
September 18th, 2010 by lucas
After my last blog post on Ruby in Debian and Ubuntu, I got a few offers for help, which is excellent.
So I’ve decided to update this wiki page with pointers to the various team resources, and some examples of tasks that newcomers can do.
I’d like to stress that many pending tasks are really doable by someone not very qualified in Debian packaging. They are not done just because nobody has the time to do them. Some good examples are the libinotify-ruby, libimage-size-ruby, libffi-ruby RC bugs.
September 14th, 2010 by lucas
After a few hours of hacking, I came up with Debian Bugs Search. This Ultimate Debian Database tool enables to query different kinds of Debian bugs (especially RC bugs using a multi-criteria search. It is aimed at being a replacement for the unofficial RC Bugs tracker, which has some bugs and fails to display the correct status for some bugs (Debian Bugs Search sees 450 RC bugs affecting squeeze, vs 278 for the unofficial RC bugs tracker).
While Debian Bugs Search still lacks some features that the unofficial RC bugs tracker has, it also brings some new features. The main advantage is that it makes it easy to find some classes of “interesting” bugs, for example:
RC bugs affecting squeeze and sid, tagged patch, sorted by time of last change. Why weren’t they fixed using the patch?
RC bugs affecting squeeze and sid, tagged pending, sorted by time of last change. Why weren’t they fixed by an upload if they were tagged pending a long time ago?
Bugs affecting squeeze but not sid, and marked as done. Why didn’t the fixed packages migrate to testing?
I’m open to suggestions of improvements, bug reports, or better, patches. Since it is UDD-based, it is quite easy to add more information. My own TODO list is:
- add popcon information (also enable sorting by popcon)
- add a way to display/hide additional columns (popcon, package’s versions)