With the development of rebuildd and the fact that several people are interested in re-using my scripts, I feel the need to explain how this stuff works.

Grid’5000

First, Grid’5000 is a research platform used to study computer grids. It’s not really a grid (it doesn’t use all the classic grid middleware such as Globus). Grid’5000 is composed of 9 sites, each hosting from 1 to 3 clusters. Inside clusters, nodes are usually connected using gigabit ethernet, and sometimes another high speed network (Myrinet, Infiniband, etc). Clusters are connected using a dedicated 1OG ethernet network. Grid’5000 is in a big private network (you access it through special gateways), and one can access each node from any other node directly (no need for complex tunnelling).

Using Grid’5000 nodes

When you want to use some nodes on Grid’5000, you have to use a resource manager to say “I’d like to use 50 nodes for 10 hours”. Then your job starts. At that point, you can use a tool called KaDeploy to install your own system on all the nodes (think of it as “FAI for large clusters”). When KaDeploy finishes, the nodes are rebooted in your environment, and you can connect as root. At that point, you can basically break the nodes the way you want, since they will be restored at the end of your job.

Running Debian QA tasks on Grid’5000

None of that was Debian-specific. I will now try to explain how QA tasks are run on Grid’5000. The scripts mentioned below are in the debcluster directory of the collab-qa SVN repository.

When the nodes are ready, the first node is chosen to play a special role (it’s called the master node from now on). A script is run on the master node to prepare it. This consists in mounting a shared NFS directory, and run another script located on this shared NFS directory to install a few packages, configure some stuff, and start a script (masternode.rb) that will schedule the tasks on all the other nodes.

masternode.rb is also responsible for preparing the other nodes. Which consists in mounting the same shared NFS directory, and executing a script (preparenode.rb) that installs a few packages and configures some stuff. After the nodes have been prepared, they are ready to execute tasks.

To execute a task, masternode.rb connects to the node using ssh and executes a script in the shared directory. Those scripts are basically wrappers around lower-level tools. Examples are buildpackage.rb, and piuparts.rb.

Now, some specific details:

• masternode.rb schedules tasks, not builds. Tasks are commands. So it is possible, in a single Grid’5000 job, to mix a piuparts test on Ubuntu and an archive rebuild on Debian. When another QA task is created, I just have to write another wrapper.
• Tasks are scheduled using “longest job first”. This doesn’t matter with piuparts tests (which are usually quite short) but is important for archive rebuilds: some packages take a very long time to build. If I want to rebuild all packages in about 10 hours, openoffice.org has to be the first build to start, since building openoffice.org takes about 10 hours itself… So one node will only build openoffice.org, and the other nodes will build the other packages.
• I use sbuild to build packages, not pbuilder. pbuilder’s algorithm to resolve build-dependencies is a bit broken (#141888, #215065). sbuild’s is broken as well (#395271, #422879, #272955, #403246), but at least it’s broken in the same way as the buildds’, so something that doesn’t build on sbuild won’t build on the buildds, and you can file bugs.
• I use schroot with “file” chroots. The tarballs are stored on the NFS directory. Which looks ineffective, but actually works very well and is very flexible. A tarball of a build environment is not that big, and this allows for a lot of flexibility and garantees that my build environment is always clean. If I want to build with a different dpkg-dev, I just have to:
  • cp sid32.tgz sid32-new.tgz
  • add the chroot to schroot.conf
  • tell buildpackage.rb to use sid32-new instead of sid32
• Logs and (if needed) resulting packages are written to the NFS directory.

Comments and questions welcomed :)

DebConf7 finished today. This was my first DebConf, and probably not my last one :-) I had a really interesting time in Edinburgh, despite the weather (but at least we are prepared for DebConf8 now!). The organization team really did a fantastic work, the venue was gorgeous, etc, etc, etc.

Again, I was positively surprised by how nice everybody was at DebConf. It’s weird to think that the same people are part of the regular flames on the mailing lists. Which proves that most flames are just caused by people being passionate about Debian, and looking for the best for the project, and not by people trying to be annoying, like one could think :)

I gave a talk about the usual QA stuff I’m doing: archive-wide rebuilds, piuparts runs, and how to make all this more efficient by working inside the collab-qa project. So far, it’s not like a lot of people have been joining the project, which is kind of a failure. But at least everybody seem to think that the idea is good.

I also gave a lightning talk about Debian Package of the Day, which I didn’t plan to give originally (I think I never prepared slides in such a short time). I think it was well received, and we even got a new submission half an hour after the talk.

I even managed to clear some tasks on my TODO list during Debconf, the most visible one being the “automated monthly mails to maintainers of packages with serious problems”. I was quite afraid of being flamed, but I sent 250 mails, and only one person replied aggressively. I also got a lot of positive feedback, so the next batch will probably use slightly less strict criterias.

And of course, the most important result of debconf was the numerous discussions, that resulted in a lot of good and interesting ideas.

You probably all know tetrinet – if you don’t, you should really try that game. There are several servers for that game out there, and one of them is tetrinetx. It is packaged in Debian, but it has several problems:

• It doesn’t support tetrifast mode. So you have to deal with that stupid 1-second delay before the next block appears.
• The code is truly horrible. From main.c:

  #include "dns.c"
  #include "utils.c"
  #include "net.c"
  #include "crack.c"
  #include "game.c"

  That gives you an idea, right ?

A few years ago, I worked with a few friends on improving tetrinetx. This resulted in:

• Massive code cleanup
• Tetrifast support
• Stats stored in an MySQL DB, so you can compute nice stuff (time wasted per day, etc)
• More stats: blocks drop rate, etc.

This is hosted on sourceforge under the name tetrinetx-ng, but it hasn’t seen any activity for the last two years.

It would really be great if a tetrinet fan could take over the project and start making it alive again. Then tetrinet.debian.net could support tetrifast ;)

Also, I could try to setup a server with tetrinetx-ng. Someone wants to host tetrifast.debian.net for me ? Needed: MySQL DB + Apache (for the stats), + not being afraid of insecure code (doesn’t need to run as root)

I am considering switching from SVN to a distributed SCM for my personal stuff. I had a look at git and mercurial, but neither really support branching a sub-directory:

Often, I am working on a big private project, and, while working on a sub-project (stored inside the project’s repository), I’d like to share that sub-project with others. So there are actually two problems:

• being able to checkout/branch/clone a sub-directory
• possibility to control access on a per-directory basis

SVN only partially meets my needs with that (it’s possible to checkout a sub-directory directly, for example with svn co svn://svn.debian.org/svn/pkg-ruby-extras/tools/ruby-pkg-tools). I think that it’s possible to do fine-grained access control
using libapache2-svn, but I haven’t tried yet.

It seems that mercurial can do that, using the forest extension. But you have to convert the specific directory into a repository, with a complex step to keep the history.

Amongst the distributed SCM, is there one that supports that ? (at least the sub-directory branching part)

Consider the following command:
echo <(cat /etc/{motd,passwd})

(you can replace "echo" with any command that takes one file as argument and cannot take it as stdin)

It's obvious that the goal is to expand this to:
echo <(cat /etc/motd /etc/passwd)

Then to:
echo /dev/fd/63

However, it doesn't work like this:
$ echo <(cat /etc/{motd,passwd}) ++ cat /etc/motd ++ cat /etc/passwd + echo /dev/fd/63 /dev/fd/62 /dev/fd/63 /dev/fd/62

But bash doesn't work like this. Brace expansion is done first, but inside parameters of the command (that is, <(cat /etc/{motd,passwd})) not words. So when <(cat /etc/{motd,passwd}) is expanded, the prefix is <(cat /etc/, the suffix is ")", so it's expanded to <(cat /etc/motd) <(cat /etc/passwd).

After reporting a bug about that, Chet Ramey gave me the correct way to reach the initial goal:
cat <(eval cat /etc/\{passwd,motd})

Just received that, in reply to a mail I sent:

This email is from X.

My email address (X@Y.com) is protected against spam and viruses by MailInBlack.

Please click on the following link in order to identify yourself to me and to allow your message to reach me.
http://192.168.0.252/v/?C8BEF10E72C&tmstp=20070316084314&tk=message_confirm&tkid=7951&lang=2

This needs to be done only once, for this email and all future email correspondence.

Thank you for your understanding.

X

MailInBlack seems to be a french company. No wonder why they guarantee that 100% of spams are stopped. (To be fair, I am not sure yet of who fucked up, it might be the admin)