Last week, I had to put my daily (real) work off for a bit, to get some rest. I took this occasion to implement a few ideas I had for the Buildd Status Pages. Mainly, I wanted to get rid of my external dependencies which are:

• https://buildd.debian.org/build.php which shows all build logs available for a package. It s nice and simple, but old and not easy to read. In my opinion, it s almost useless because it takes some time to realize (visually) what happened to the package (there are no colors to distinguish successful builds from failures, text is not aligned, etc ).
• https://buildd.debian.org/fetch.cgi which shows the content of a build log given a package, a version, an architecture and a time-stamp identifying the log file (you can see this as an example). The page works, there is no real need to rewrite it, modify it or whatever. It just does its job perfectly, but it was my last external dependency

Besides of getting rid of external dependencies, there were also a few feature requests (#618676, #612174, #518526) waiting for a while and it was good time to fix them. Hopefully, there are related to what I was fixing. The final version is now deployed and can be used. The implemented changes are :

• From the regular package view, you have now a link to all logs available for that packages (click on Logs in the table), or all logs for a specific architecture (click on old in the table, for you preferred architecture).
• The listing of available build logs has now its own new page. The default listing shows everything, i.e. every version available and everywhere known architecture (just like the old page did before). But now, you get with that the build time and disk space consumed during the build, when available. Furthermore, it groups the logs by version so that it becomes easier to see that all that group are logs for the same version . And you can also show build logs for a specific architecture by choosing one (links in rows) ; or restrict on versions, in a similar way. And, of course, there are some additional colors in each row to distinguish successful builds from those who failed.
• The page that fetches the log is now available from other pages. And this removes the last external dependency.
• All pages have an appropriate HTML title set (yeah, it s a shame that I didn t fix that since the first deployment).

I think that I tested well enough this new version and it works okay. Nevertheless, if you encounter a bug or a strange behavior, please don t hesitate to contact me (either by mail or on irc) or submit a bug report against buildd.debian.org. The next steps (probably) are :

• add the last feature that pkg.cgi has which the ability to select a list of packages according to their maintainer (or co-maintainer).
• a better integration with P-A-S files.
• show tail of logs for build failures.
• ask wb-adm if build.cgi, bymaint.php, fetch.php, info.cgi are still needed/useful. If you do use use/need them, please speak up before they get removed.
• if you have any other idea, do submit a bugreport.

The Background If you weren't online last Friday you probably have missed the big news announcement on the various community distribution websites. The main pages of them got replaced by a placeholder announcing the birth of The Canterbury Project. People started to wonder whether it is an April fool's prank or for real. This blog post is meant to shine a bit more light on it and address one comment received about it. If you go to the news item on the Debian site you'll get your answer about that it indeed was an April fool's prank. The idea for doing something in coordination with other distributions came to me when I thought about last year's (or was it already two year's ago?) prank that the various web cartoon sites pulled: they replaced their main page with the page of another cartoonist. My original idea was actually along that lines. So I started to dig up website contacts from different distributions, I was aiming at the big names in the community distribution sector. Given that my time is pretty limited these days with renovating the house we plan to live in soonish I knew I had to let in others in within Debian. I though didn't want to involve too many people, for several reasons: it should be a surprise to as many as possible, but more importantly, I didn't want to shy away other distributions by an overwhelming Debian involvement. That's also part of the reason why I didn't contact many Debian based distributions. So first contacts where made, a dedicated IRC channel used for coordination, and people involved joined in. Then the thing happened which the Free Software community is so well known for: additional ideas came in, two people independently addressed me whether it wouldn't be better that instead of a circle replacement of the frontpage, why not display the same page on all of them. And one of them added that a corresponding news item might make sense. So there we were, having to think about text to put into two things: the news item and the replacement page itself. At this stage Alexander threw in a project name with a background that was adopted. Francesca started with an idea for the news item, I started to put quotes in and asked for ones from the other involved people that fit their distribution well. Klaas came up with a template for the replacement page that we tweaked. Fortunately we ended up being five distributions and the colors of the banner did match the distribution ones rather well (except for one, we had to tweak the color of one banner). The Credits We were all set, and actually everything went fine. And it definitely caught the attention. This blog post goes out in thanks to the following people:

• For Arch Linux: Pierre Schmitz and Dieter Plaetinck thanks for joining in on such a short notice!
• For Debian: Alexander Reichle-Schmehl (thanks for the name!), David Pr vot, Francesca Ciceri (thanks for gathering contact information!) and Martin Zobel-Helas (thanks for webserver setting tweaks).
• For Gentoo: Robin H. Johnson thanks for the best quote for the news item!
• For Grml: Michael Prokop thanks for the great live CD and your input!
• For openSUSE: Thomas Schmidt and Klass Freitag thanks for the perfect website theme and the best mocked up news item!
• ... and most of all, to the to be left unnamed person from the distribution that didn't join in in the end: a lot of thanks has to go in that direction because of the invaluable input. The actual idea about the additional news item is to be accounted to that person, and the Canterbury logo was tweaked there too.

I hopefully haven't forgotten anyone. There surely were some more people involved in the other distributions, and I guess the named people weren't aware of all the ones involved inside Debian. Feel free to drop missing names in the comments. Addressing Feedback Finally, let me address one concern raised: someone claimed that the real joke with this prank was that we would consider collaboration to be a joke. Actually, the total opposite is the case here. That it was possible to pull it off should be proof enough that Collaboration Across Borders actually is possible. And the background information put into the news section of the replacement site is real. Also, my personal quote in the news item was meant dead honest. I do believe that DEX has a limited point of view and only tackles part of the problem. Unfortunately, for such efforts to really come to life it takes people with a really long breath and dedication to it. Efforts like the VCS-PKG and the Freedesktop Games effort are more or less stalled. Even though a lot of people do believe in stronger collaboration to be a good thing, the basis is not working out too well. I'm in the fortunate position that for some of the packages I maintain there is exchange between packagers from different distributions to avoid common troubles. If it can't be done in the big it should at least be tried in the small. I want to specifically highlight again one part of the updates in the replacement page: the CrossDistro track at this year's FOSDEM. This one was more than fruitful, on several levels. From what I've heard a lot of discussion happened besides the talks too, and connections got established. It doesn't sound unlikely like this might be done again next year. So again, thanks for enjoying this April fool's prank, thanks to everyone who helped to deliver it, and especially a lot of thanks to the people who this might have got thinking of possibilities to improve on the collaboration front!

/debian permanent link Comments: 8 Flattr this

Alright. If you ever come into the same situation I was in and need a newer kernel (2.6.32 or up, perhaps also 2.6.31) on some system with old iptables package (versions below 1.4.0 I think, 1.3.5 in my case: CentOS5/RHEL5), you might get this helpful error message when using the iprange module in your iptables rules: iptables: Unknown error 18446744073709551615 Or even more helpful, if you use iptables-restore to load your rules, you will get an error in the line containing the COMMIT statement (iptables-restore: line X failed). The reason for this is that the netfilter guys have removed an interface to the iprange module in kernel version 2.6.31 or 2.6.32 (see my bug report at #711 of the netfilter bugzilla). Just posting this so it might hopefully help others if they get into the same situation.

3 days left! I recurrently got asked not only how to contribute to Debian, but more importantly how to get involved, i.e. become part of the project and stay around for a while. In case you're a student excited about Free Software and Debian, there are only 3 days left (deadline April 8th) for applying to the Google Summer of Code program and work with Debian this summer. According to my past experience as GSoC mentor and admin, the program offers a wonderful opportunity to become part of a Free Software project like Debian. Think twice before missing it! The proposed idea list contains several projects that might have a significant impact on Debian. The list includes a pet peeve of mine (developer package repositories) and many many more. If you are a student, I suggest you to read a recent blog post by Ana that contains a nice overview of some project ideas, as well as info for applying.

As seen in some mailinglist discussion:

"It seems to be a common belief between some developers that users should have to read dozens of pages of documentation before attempting to do anything.
"I m happy that not all of us share this elitist view of software. I thought we were building the Universal Operating System, not the Operating System for bearded gurus."

I think this is an interesting quote as it shows an important misunderstand of what Debian is for many people. Debian (and Linux in general) was in its beginnings quite complicated and often not very easy to use. People still felt a deep relieve to have it and a strong love. Why? Because it's not so much about about how you can use it, but how you can fix it. A system that only has a nice surface and hides everything below it, that does in a majority of cases just what you most likely want it is nice. But if the only options are "On", "Off" and perhaps some "something is not working as it should, try to fix it" (aka "Repair") it is essentially a form of paternalism: There is your superior that decided what is good for you, you would not understand it anyway, just swallow what you get. Not very surprisingly many people to be in the position of the inferior of a computer (the less the more stupid the computer is, but even modern computers are still stupid enough for most people). So what those people want is not necessarily a system that can only be used after reading a dozen pages of documentation, but a system they know they can force to do what they want even if that might then mean reading some pages of documentation. So a good software in that sense might have some nice interface and some defaults working most of the time. But more importantly it has a good documentation, easy enough internals so one can grasp them and be transparent enough that one can understand why it is currently not working and what to do against this and then allowing enough user interference to fix it. If all I get offered is some "interface for users too stupid to understand it anyway" and all options to fix it are checking and unchecking all boxes and restarting a lot or perhaps some gracious offer of "There is the source code, just read that spaghetti code, you can there see anything it does though you might need to build a debug version just to see why it does not work" then I would not call any strong feelings against this situation "elitist".

Mandatory warning: What follows is for testing only, and insecure (root all over the place, giving access to host devices from the container, etc.). Problem of the day

• It d be nice to package Wayland. It s been split in several repositories: one for the core protocol/library implementation; one for the demo compositor and clients.
• Easy? Not quite, mesa needs to be rebuilt against the library. Doing so on a system running stable doesn t seem too good: some newer libraries might be needed; and using make install could make it harder to remember additional bits installed all over the place ($DESTDIR is our friend but that might mean more work on the build system side to get everything detected).
• What about having the whole development environment running in a Linux container? That s what I investigated.

Giving Linux containers a try

• Start from a squeeze system.
• apt-get install lxc, read its README.Debian, get the mount point set up.
• Copy the /usr/lib/lxc/templates/lxc-debian template somewhere as lxc-squeeze, and edit it:
  • Replace dhcp-client with dhcp3-client.
  • Replace lenny with squeeze.
  • Specify a better mirror than ftp.debian.org.
• Create a lxc-test directory, and create a container: ./lxc-squeeze -p lxc-test.
• Start the container, which gives access to a console: lxc-start -n test -f lxc-test/config (the test name passed through -n can be used to call lxc-stop -n test). Use root/root to get in.
• Edit /etc/apt/sources.list to point to sid instead, and dist-upgrade (using squeeze to start with means fewer headaches while bootstrapping, in case sid breaks or gets into some transition).
• Try lxc-stop and lxc-start to make sure the container can be stopped and restarted at will.

Getting devices

• First things first (and unless I missed something), udev + LXC = fail. So let s install it, note that it can t be configured, edit /var/lib/dpkg/info/udev.postinst, add exit 0 at the top, and dpkg --configure udev.
• Now, some devices are needed under /dev. Using mknod would be too easy, that s called a container for a reason. So let s edit the config file (the one passed to lxc-start earlier) to add a few devices (see below for an example).
• Once that done, restart (lxc-stop/lxc-start) the container, mknod on those devices is now possible.
• Input devices are not considered here, only video output is wanted for this test case. [This post might be edited if some examples get added later.]

Example, with a Radeon card, KMS enabled, let s assume those devices are wanted:

crw-rw---- 1 root video 226, 0 Apr  5 02:34 /dev/dri/card0
crw-rw---- 1 root video  29, 0 Apr  5 02:34 /dev/fb0
crw------- 1 root root    4, 7 Apr  5 02:34 /dev/tty7
crw------- 1 root root    4, 8 Apr  5 02:34 /dev/tty8

Note the major, minor right between owner groups and dates, and edit the config file accordingly, adding those lines (watch the syntax, it doesn t like extra whitespaces):

lxc.cgroup.devices.allow = c 226:0 rwm
lxc.cgroup.devices.allow = c 29:0 rwm
lxc.cgroup.devices.allow = c 4:7 rwm
lxc.cgroup.devices.allow = c 4:8 rwm

Once the container restarted, create the devices:

cd /dev
mkdir -p dri
mknod -m 666 dri/card0 c 226 0
mknod -m 666 fb0       c 29 0
mknod -m 666 tty7      c 4 7
mknod -m 666 tty8      c 4 8

Getting serious

• apt-get install xorg
• startx
• strace -f can help diagnose issues. If /dev/dri/card0 shows up with ENODEV, an old libdrm could even remove that device, so running mknod is needed again (but not sufficient)
• A likely cause of such issues might be that an X server already ran (or is still running) on the host system. Disabling the display manager on the host, rebooting, and trying startx from the container again should give better results (that s what happened here).
• If startx just works , just use ^Z then bg to put it in the background.
• Move on to installing a random window manager (e.g. awesome) and mesa-utils, and enjoy!

Enjoy:

export DISPLAY=:0
awesome &
# this is not a benchmark:
glxgears &
# direct rendering:
glxinfo egrep '(direct renderer)'

which printed here:

direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on ATI RS690

Today I shot an image of a bear my daughter gave to my wife for mothers day. This week I am also including a behind the scenes shot that shows how cheap my home "studio" is. In case you can't tell that is my bed with t-shirt covered boxes on it. All the light for this image comes from the window. After a little editing of the image the final outcome is what you see at the top of this post.

Since I m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month. Multi-Arch work I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure. I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible. After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month. With the arrival of dpkg 1.16.0, it s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan. If you re curious about Multi-Arch, you might want to read this article of Steve Langasek as well. Bug triage for dpkg in launchpad At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified. Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It s a bit frustrating as I tend to mark many reports Incomplete because there s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information. But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support). I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports. Misc dpkg work The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field. I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field. Developers-reference work The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the Developer duties chapter (see #548867). We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don t get more reviews and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can t interfere). In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian. We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered. Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it. It was not pleasant for anyone. I don t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some soul into it. But it s a real challenge when you seek a consensus and that the interest in reviewing changes is so low. DVD shop listed on debian.org In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case). A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it. Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing. Debian column on OMG! Ubuntu I have always been a firm believer that it s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in. I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu s CTO reveals DEX: an effort to close the gap with Debian. It s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian s values are relayed further, and OMG! Ubuntu s large audience also helps me develop my own blog. Work on my book I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April. This means that the work on the English translation could start in may. Work on my blog Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out. I interviewed Christian Perrier (Debian s translation coordinator) and also Bdale Garbee (chair of Debian s technical committee). I finished my series of Debian Cleanup Tips with 2 supplementary articles:

• Identify cruft that can be removed from your Debian system
• Remove automatically installed packages

The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo. Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above). Thanks Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects. See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

Here I write a little bit about my experiences running GRUB2 with a PowerPC Mac (actually, an iBook G4), since the current documentation is lacking in many places (outdated, incorrect, etc.). Some of what I say is platform agnostic, though, and may be of interest to users of GRUB in general.

Basics using GRUB2 with PowerPC First of all, it is important to understand (at least superficially) how botting on a Mac works. One of the first programs that run in your Mac is the OpenFirmware. It works with more or less the same purpose of a BIOS in a regular x86 system. The basic idea is the same: get the computer running with whatever programs you want it to run. The implementation, though, differs quite a bit. First of all, OpenFirmware (OF) usually presents itself as a command-line interface that is programmable, differently from the common day BIOSes from x86 boxes. As it is programmable, it is more flexible, but this flexibility comes at the price of an increased complexity. I may write some things more in a future article, if there is any interest. For now, it just suffices to say that to get to the OF prompt in a Mac, you have to press a combination keys during the time that your Mac gives a chime when you turn it on. At that moment, you have to press (simulaneously) Cmd + Option + O + F. (Note: the Cmd key is the key that has an Apple drawn on it, usually on the side of the space bar).

Limitations of Open Firmware Differently from usual BIOSes of x86 computers, Open Firmware can read the contents of a partition in your HD (or other devices), as long as it is formatted in the original HFS format (not in HFS+ or one of its descendents). This is the reason why some older versions of Linux create an HFS partition in your HD, even if you don't intent to run or use anything besides Linux. The yaboot bootloader consists of, among other things, one binary that is understandable by OpenFirmware. That binary is a file called yaboot, after the name of the booloader. As an aside, you have to indicate to OF what is the file that you want it to load during the boot process, so that it knows what to do. The way to indicate this is to "bless" the file (and the folder that contains it). Some ways to bless a file are to, for example, use the bless command in MacOS X or the hattrib -b command from hfsutils. Files in an HFS filesystem have two attributes that many other filesystems don't: a creator ID (the "application" that created the file) and the type ID (which determines what kind of file it is). OpenFirmware, in particular, looks for files with the type tbxi for the bootstrap process. The yaboot binary is loaded by OF into memory and, then, control is passed to the yaboot program, which then reads its configuration file (yaboot.conf) from the same folder where the binary was in. The file yaboot.conf contains instructions for yaboot to do its job. The file yaboot.conf is very similar in construction to configurations of an older bootloader for x86 computers, lilo.conf. Also, in a way similar to what LILO requires, after you install some new kernel, change some parameter in the configuration file, etc., you have to run a program that will set up everything so that the boot process can know of your new configuration. With LILO, this command was called lilo, while with yaboot the command is called ybin (which, essentially, takes care of putting yaboot.conf in the bootstrap/HFS partition and blesses the yaboot binary).

Going to GRUB2 One of the characteristics of yaboot (which is left as an exercise to the reader to determine if it is a drawback or not) is exactly the way that changes in the configuration have to be copied to the special HFS partition: the step of running ybin. GRUB2 (and its older sibling, GRUB legacy) do away with that: during boot-time, it can understand the filesystems that you have in your computer and interactively load whatever you want from there, also from a command-line like OF, before any (regular) operating system has even been started. But how do you start GRUB2? Well, the way that this is performed is copying a binary to that special HFS partition. Here things start to be hairy, because GRUB2 has a lot of functionality, but it comes at the price of it consuming a lot of space (especially if you are using encrypted partitions or some kind of logical volume managements with some journalling filesystem that allows files to be compressed etc. on top of it). The list goes on. Usually, that special HFS partition only has 800KB, which, BTW, is the size of an old 3.5" floppy used with older Macs (note: due to some contraints on partitions and aligments of such partitions on cylinders, it is not uncommon for disk partitioning software to create partitions slighly larger than 800KB, but not much larger than that). A full-featured binary of GRUB2 to be placed on that HFS partition can have much more than those 800KB. But how do you get that binary, in the first place? And how do you fit that in the HFS partition?

Creating the GRUB2 binary To answer the first question, you have to construct it from your grub-ieee1275 package (I'm assuming here that you are using Debian or Ubuntu, but similar instructions may apply to other distributions). Then, a first step would be to create such binary with:

 mkdir /tmp/foo
 cd /tmp/foo
 cp -a /usr/lib/grub/powerpc-ieee1275/* .
 grub-mkimage -O powerpc-ieee1275 -o ../grub.img *.mod

The last command of these create an executable named grub.img that is callable from OF and which contains every module from grub-ieee1275. This executable that I call here grub.img is called, in GRUB2 parlance, the core image and it it seems to be named core.img in many systems. On my system, with those commands, the binary grub.img is about 1208KB, which is 50% larger than that 800KB partition. And you would like it to be much smaller, becase you want to still have your yaboot bootloader by default while you are evaluating your bootloaders (or using it as a backup plan). As GRUB2 follow a modular design, you can mix and match the features that you want. This already hints you to the way we can fit it in the HFS partition, and it is always the same story: just trim the fat.

Creating the configuration file You will also have to have GRUB2 configuration's file (or you will have to play with way more commands than you'd want to). An important distinction here is that you usually have 2 or more partitions on your Mac:

• the special bootstrap/HFS partition where OF is going to look at (I'll call it /dev/hda2 here);
• the partition where your / filesystem resides (denoted by /dev/hda3 here);
• some partition to hold /boot (I don't have one of these, but let's say that it is /dev/hda7 for our discussion purposes), usually containing your kernels and initial ramdisks.
• other partitions.

With this in mind, you can With Let's say that this last one, in Linux parlance, is /dev/hda3 (as is the case of this author), and optionally a partition where your Linux kernel resides (people usually use it to store the /boot subtree of a Linux filesystem). Let's say that this last one is /dev/hda7. Then, you would compose something like the following as a configuration file for GRUB2 (named grub.cfg):

insmod part_apple
insmod ext2
set root='(hd,apple7)'
menuentry "Linux"  
    linux /vmlinux root=/dev/hda3
    initrd /initrd
 

There are one two important points here that deserve more comments:

• Note that, differently from a regular x86 system, in a Mac system with only one HD the way that you specify an HD does not have a trailing zero. For instance, in the case above of the variable root, we have (hd,apple7), while in a "common PC" we would have the (hd part replaced with (hd0. That's something that you should make your distribution aware of, if they aren't yet. As an addendum, I don't know how it works with systems with more than one HD, as I only have (PowerPC) Macs that are notebooks. If you can share any experiences, please do.
• One point of caution here: what GRUB2 calls root is not necessarily the root of your filesystem (i.e., the partition that holds /), but the device that everything that is "not fully qualified" is interpreted as being relative to. The "not fully qualified" above means anything that is not prefixed with GRUB's device notation. As an example, (hd,apple2)/boot/vmlinux if fully qualified for GRUB's purpose, while /boot/vmlinux is not.

Putting it all together The next step is to just copy the files grub.img and grub.cfg to the special HFS partition. You can do that using hmount, hcopy, and humount or you can use the regular Linux hfs module to copy to that partition. Then, boot your system, get into the OF prompt and execute:

boot hd:2,grub.img

Here, the 2 above is a reference to my HFS partition. Substitute that with yours, appropriately. You will then see the common (familiar?) GRUB prompt and, from there, everything else that you know will (hopefully) work.

The list of modules that "Works for Me(TM)" As I mentioned above, I use a subset of all modules that come with grub-ieee1275 to create my grub.img binary. Here is the list of modules that I use and that gives me a reasonably sized bootloader:

bitmap.mod        datehook.mod  gzio.mod         lsmmap.mod      reboot.mod          terminal.mod
bitmap_scale.mod  datetime.mod  halt.mod         memdisk.mod     regexp.mod          test.mod
blocklist.mod     echo.mod      help.mod         memrw.mod       relocator.mod       trig.mod
boot.mod          elf.mod       hexdump.mod      minicmd.mod     scsi.mod            true.mod
bufio.mod         ext2.mod      hfs.mod          msdospart.mod   search.mod          video.mod
cat.mod           fat.mod       hfsplus.mod      normal.mod      search_fs_file.mod  video_fb.mod
cmp.mod           font.mod      ieee1275_fb.mod  part_apple.mod  search_fs_uuid.mod  videoinfo.mod
configfile.mod    fshelp.mod    linux.mod        part_msdos.mod  search_label.mod
cpio.mod          gettext.mod   loadenv.mod      parttool.mod    setjmp.mod
crypto.mod        gfxmenu.mod   loopback.mod     probe.mod       sleep.mod
date.mod          gfxterm.mod   ls.mod           read.mod        suspend.mod

Just for the record, my grub.img file has 624KB, and that can certainly be shrunk.

The command line that "Works for Me(TM)" to create the image Actually, I lied when I told you that I used the lines above to create my grub.img file, because I'm lazy and I don't want to type the .img extension. I also embed my configuration file in the binary that I create with GRUB2, so that I don't have two files to copy to my HFS partition, but only one. I do that with:

grub-mkimage -c grub.cfg -o ../grub -O powerpc-ieee1275 -d . *.mod

OK. No more lies here. The nice aspect of GRUB is that one you install that image, you don't have to touch that HFS partition anymore: you simply update your regular filesystem's /boot/grub/grub.cfg file (which is usually performed when you install a new kernel, at least with Debian) and you're ready to go. The good way to do that is to use a minimal configuration file embedded in your grub binary in your HFS partition that will hook into the system's /boot/grub/grub.cfg to read newer kernels and leave the HFS partition (and your system's NVRAM) alone. Here is what I am using right now:

search --no-floppy --fs-uuid --set=root 35d26869-f7c9-4852-a9b8-100314560c34
set prefix=($root)/boot/grub
configfile /boot/grub/grub.cfg

You will, of course, want to modify the file above as you install newer kernels (perhaps even that unsupported operating system from that fruity company, who knows?). Don't forget to change the UUID's, and partition numbers to fit your needs. Well, that's it. I hope that it helps somebody out there, as the information that I got otherwise was way outdated, incomplete, etc. to keep up with GRUB2 from these days. Now, let's go patch the tools that we have so that not everybody who wants to use GRUB2 have to learn about its workings. Oh, of course, you can now have your kernels in ext4, btrfs, xfs etc. partitions without the fear that your bootloader won't load them.

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).

1. Let s start with a few common bugs reported over the past few weeks:
   • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
   • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
   • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
   • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
   • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
   • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
   • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
   • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
   • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
   • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
   • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
   • [KiBi] xterm: new upstream, to unstable.
   • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
   • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
   • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
   • [KiBi] libxp to unstable, nothing fancy, that s libxp
   • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
   • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
   • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
   • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
   • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
   • [KiBi] siliconmotion video driver: to unstable.
   • [KiBi] pixman: new upstream release candidate, to experimental
   • [Sean] last but not least: many compiz packages to experimental.

For the past couple years I had been reading very little, two or three books a year.

For the past month my average has been two books per week.

The culprit is the Amazon Kindle 3 I bought during my stay in the US. I just can not recommend it enough. For starters, it is quite affordable at $139. The image quality is wonderful, and reading in daylight or even in direct sunlight is pleasant. This is a welcome change from a backlit screen as the eyes get noticeably less strained. The format of the device is even more convenient than of a real book (the size is perfect for plain text, start thinking about the Kindle DX if and only if you intend to read PDFs). The Kindle is quite thin and convenient to hold (and you do not need to keep it from closing as with paperback bindings). Battery life is on the order of weeks. Extra functionality (e.g., web browsing) is available, but not convenient, but that is almost an advantage as distractions are kept at bay. The Amazon store is great, I have already shelled out over $50 with little remorse (my time is much more expensive than the measly $9.99 a typical book costs). There are quite a few free books around too. And to top it off, the "screensaver" with pictures of writers is a very nice touch.

The Kindle is also useful for going through longer articles you would normally be reading on your laptop. The Chrome extension Send to Kindle has worked well for me, do check it out.

The most important drawback of the Kindle is that it is slow to turn pages, so it is not easy to browse a book. Turning a page takes a second or so. This is extremely annoying when reading in non-linearly, e.g. taking in study material, when you constantly need to go back to check up details of previous material. A PDF interpreter is available, but the screen is too small to show a full PDF page (a Kindle DX or an iPad would probably be better) and scrolling is painful because of the delays. Wireless seems to drain the battery noticeably, there have been a few cases where I forgot to turn it off and found a dead Kindle a few days later. I wish the WiFi connection would manage itself intelligently somehow.

The Kindle drove the point home for me that dead-tree books will be going the way of vinyl soon, much sooner than I had expected. And for good reasons. Go order now if you do not have an e-book reader yet (and do not forget to order a sleeve too, given the time you will be spending carrying the device it will come in very handy).

If you have been using Lintian you may also know that it has some limitations. One of these are that Lintian always checks every package isolated from each other unlike other tools like piuparts. It has its advantages (such as not requiring all dependencies being present) but it also has it disadvantages. Currently Lintian emits a binary-without-manpage -tag if the package contains a binary without a manpage. At first glance this appears reasonable, but it really is too simple (#512645). Basically Lintian complains about the missing manpage even if the manpage will always be present. A simple case is package foo depends on foo-data, the binary is in foo and the manpage is in foo-data. A live example of this is gedit and gedit-common[1]. The problem is that Lintian does not know if a given package is going to processed or not. Lintian does have a few cross package checks; namely binary checks can see the source package if it is available. This can be done with a bit of clever sorting (quote from Lintian source code):
# [...] (the sort is to make sure that source packages are
# before the corresponding binary packages--this has the advantage that binary
# can use information from the source packages if these are unpacked)
This works rather well, but its scope is very limited. Particularly it is no help, if we need to check if the manpage missing in foo might be in foo-data. This is what #513663 is all about. In January I branched the Lintian code and started working on grouping packages from the same source together. Yesterday I finished refactoring Lintian to do just that. However, this in itself is not very useful if the checks cannot take advantage of this. So today I sat down and extended our manpages check a bit and posted the results to the Lintian mailing list. [1]http://packages.debian.org/sid/gedit http://packages.debian.org/sid/gedit-common

For the whole week, I ve been in Bangalore for the GNOME.Asia 2011 hackfest. I ve been delegated by Stefano to represent Debian here, and my employer EDF has agreed to cover for travel costs since they are very interested in first-hand information the future of the Linux desktop and sharing our work on scientific computing. It s been a really exciting week; I ve spent quite some time packaging missing pieces of GNOME 3.0 (well, the release candidate versions of course) in experimental, together with Fred Peters. I think it s reaching a usable state now, so we ll probably soon provide metapackages to make it easily installable. The latest developments of the Shell make it a very exciting piece of software, with a strong focus on usability. Many things were written about it, but in the end my main criticism would be that it lacks some functionality - for example, the combined clock/weather/locations applet will be greatly missed. The good news is that it is extremely customizable, and with all the libraries being made accessible through GObject introspection, there are many features that are accessible from it. If you know how to write JavaScript, now is the time to write your favorite extension. On the good news front, Vincent Untz also spent a lot of time improving the so-called legacy mode , which is more and more starting to look like the Shell without special effects, and with all the features from gnome-panel 2.x that are still here. We will try in Debian to cover all uses cases that there were for GNOME 2 with GNOME 3 technology, so that panel lovers are not left behind. I ve also proposed an update to the dh_gsettings proposal, which will provide the same functionality as dh_gconf and allow to easily set distribution-specific overrides. It is still missing a way to set mandatory settings, which might come as a problem for some corporate users, but this is planned for a future version of GSettings. Today, we re having a business track where I and representatives of other companies (Oracle, Lanedo, Dexxa) are sharing experiences about making money with free software. Unfortunately the local organizers didn t manage to gather many people, despite our being in a city with an incredible number of IT industries. Tomorrow, the public conference starts, and this should be the opposite: we re expecting around 1000 people, which is a great achievement for a free software conference. For an unrelated topic, being around so many GNOME hackers has some interesting side effects; I ve been added to Planet GNOME. So, hey, hello Planet GNOME readers!

pushing cross-distro collaboration to the next level In case you've missed the announcement, today it's a memorable day for Free Software. Please join the following distributions in welcoming Canterbury, the next generation community distribution:

• http://www.debian.org
• http://www.gentoo.org
• http://www.grml.org
• http://www.opensuse.org
• http://www.archlinux.org

---

Kudos to the, yet unnamed, representatives of the above derivatives who have come up with and coordinated this initiative.

This month I built two systems with identical hardware component (except for the case). Here s the list of components:

• Case 1: Silverstone Sugo SG02-F white
• Case 2: Arctic Cooling Silentium T11 white
• Motherboard: ASRock 880GMH/USB3 R2.0
• Processor: AMD Phenom X4 840 boxed
• Memory: Corsair XMS3 2x 2 GiB DDR3-1333
• Hard drive: Samsung SpinPoint F3 1 TB
• Power supply: be quiet! Pure Power 430W

Cases often don t meet my high requirements. Many cases are sharp-edged, bad designed (inside and outside), use cheep plastic, and/or vibrate, because the hard drives confer their vibration to the case. The Sugo SG02-F case is not perfect, but I will recommend it. The Silentium T11 case has no shard edges, but I won t recommend it. Too much plastic and optical not appealing. You probably have to replace the boxed CPU heat sink and use a better power supply if you want a silent system. How well do these components work with Ubuntu 10.10 (and probably other recent GNU/Linux distributions)? Perfectly. Everything that I tested worked:

• The USB 2.0 and USB 3.0 ports work with everything plugged in (mouse, keyboard, flash drives).
• Audio works (only stereo output tested; 5.1 sound was available in Pulseaudio)
• 2D and 3D graphics work with the free (libre) radeon driver (Compiz runs)
• LAN works

jrollins and i recently did a bunch of cleanup work on debirf, with the result that debirf 0.30 can now build all the shipped example profiles without error (well, as long as debootstrap --variant=fakechroot is working properly -- apprently that's not the case for fakechroot 2.9 in squeeze right now, which is why i've uploaded a backport of 2.14). To try to avoid getting into a broken state again, we set up an autobuilder to create the images from the three example profiles (minimal, rescue, and xkiosk) for amd64 systems. The logs for these builds are published (with changes) nightly at:

git://debirf.cmrg.net/debirf-autobuilder-logs

But even better, we are also publishing the auto-generated debirf images themselves. So, for example, if you've got an amd64-capable machine with a decent amount of RAM (512MiB is easily enough), you can download a rescue kernel and image into /boot/debirf/, add a stanza to your bootloader, and be able to reboot to it cleanly, without having to sort out the debirf image creation process yourself. We're also providing ISOs so people who still use optical media don't have to format their own. Please be sure to verify the checksums of the files you download. The checksums themselves are signed by the OpenPGP key for Debirf Autobuilder <debirf@cmrg.net>, which i've certified and published to the keyserver network. What's next? It would be nice to have auto-built images for i386 and other architectures. And if someone has a good idea for a new example profile that we should also be auto-building, please submit a bug to the BTS so we can try to sort it out.Tags: debirf

For the second time, I chose an iMac as a computer at work. I like a lot its simplicity. Only one cable, few options, a big screen and that's all. The other manufacturer where it is easy to order has a complex offer. Is the computer for playing ? for the office ? at home or in a company ? A public one, a private one ? I nervously installed Debian as soon as the machine arrived. What if it did not work, would I have to use OS X for the next three or four years ? Luckily, everything went well, and the procedure is much simpler than it looks: install rEFIt, shrink the system partition with diskutil, add two partitions for Debian and its virtual memory with Disk Utility, and restart on the Squeeze installation CD-ROM, be guided by the installer, make sure to install the GRUB on the Debian partition, not on the master boot record. Just in case I would suddenly need it, I also installed the proprietary ATI drivers, that provide graphical acceleration. I then installed Grid Engine, to take the best out of the hyper-threaded four cores of the processor. The README.Debian file is very clear and allows a simple configuration in a couple of minutes. Being a beginner, I still had to try two times, because at the beginning I was using localhost instead of a more proper name for the machine. It also took me some time to find two key parameters: slots for executing multiple jobs simultaneoutly, and priority to avoid the calculations freeze my desktop, because it is still just a desktop computer. I do not know if under OS X recent iMacs heat that much, but in these times of heater restrictions, I can conveniently heat my hands on the aluminum case of the machine. However, I am a bit worried for this summer, when restrictions will be on air conditioning.

So, the first half of my spring challenge is over. I managed to run the 50km version of Paris Eco-Trail on Saturday. 50km, this is what was advertized... The reality was 55km and, believe me, these extra 5K were worth a lot of pain..:-). I managed to complete the whole run in 6h36. As you can see, a lot slower (about 8.5km/h) than marathon races (where I managed to keep a 11.5 km/h pace) but, eh, marathons don't have 1000m positive slope! Eco-Trail is a great race. The start was in Versailles Castle park, with 5 kilometers around the Grand Canal and a few more in the castle's neighbourhood, so that the 1500-runners crowd can be a little bit dispersed before we start the forests' single track trails. Then, after 8K, we enter forests, which we won't leave until km 45, except a few street crossing here or there. Paris forests (Satory, Versailles, V lizy, Meudon, Fausses-Reposes, Saint-Cloud) are great in the springtime. The weather was a little bit "hot", which explains the quite high ratio of non finishers (11% for the 50K trail and nearly 15% for the 80K race). I managed well until KM44 where cramps began to appear. The difference between road races and trail races are rhythm differences: nobody (except the very first runners) is running when climbing hills, that would be virtual suicide. So, you have to manage this as well. My goal was keeping a 6'/km pace on the first 15K, which was quite achieved. Later on, the succession of hills makes it impossible to use one's pace as a reference. The point is mostly keeping things smooth, arrive at first food point on KM26 in very good shape and drink, drink, drink. After a 5mins stop at KM26, I started the hardest part of the trail, until KM44: this part is mostly made of ups and downs and is the real challenge: legs start burning, downhill running becomes harder and harder and you need to save some energy for the final kilometers. The second food point was in St-Cloud park, with a very nice view on the Eiffel Tower, far far away. That one is the Grail to reach...but, when here, we already have more than a marathon in our legs. So, the stop is quite longer (about 10 minutes), just to be sure about "drink, drink, drink" (eating is nearly a no-no at this point). The final 10K along river Seine, from Saint-Cloud to Eiffel Tower were really though. I was alternating walk and running, in attempts to avoid cramps (I still remember my 35K trail back in June, where I completed the last 3K with cramps in both legs, a real nightmare). I still managed to run most of the time, though very slowly. Most of us were indeed looking like zombies when crossing a small park on le Saint-Germain with kids playing football and families hanging around, enjoying the (still nice) weather. Now, even a 3-meter high climbing means walking..:-) The final kilometer was fun: at that point, you know you'll make it and you try to look proud and fine while running among the Eiffel Tower neighbourhood tourist crowd. And the applauses for the final 500meters are the real final gift with dozens of people yelling your name (it was written along with our numbers, of course!). Yay. I finally managed to finish 416th out of 1291 finishers, 50th in my age/gender category. Not that bad for the first test beyond 42K. Now the challenge is "rest, rest, rest" until April 10th and the Paris Marathon. The first marathon of my second half-century. I, of course, know that this one will be really hard. No idea, indeed, what goal I should set. Certainly not my marathon personal best (3h40'). I think I would probably already be happy to finish in less than 4 hours. If I feel really really well, I'll set 3h49' as my goal (that was my time in Paris Marathon last year). We'll see if that's crazy or not. Doh, I really have weird ideas for the gifts I offer myself for my birthday...

Bdale is a long-time Free Software believer, he has been contributing even before Debian existed in the prehistoric era of free software. Anyone who went to a big Free Software conference has seen one of his colorful t-shirts. Or maybe you have heard the story where he got his beard shaved by Linus Torvalds to raise funds to protect the Tasmanian Devil. More seriously Bdale has played and continue to play a number of important roles in the Debian community. He also represents one of the biggest corporate sponsors (both for DebConf and for the servers that Debian owns): Hewlett Packard. My questions are in bold, the rest is by Bdale. Who are you? I made my first personal contribution of source code to what we now call Free Software in 1979. I started with HP in 1986 and for nearly a decade have served the company as Chief Technologist for Open Source & Linux. I am president of Software in the Public Interest, which is the umbrella organization providing legal and financial existence for Debian in the USA. I also represent users, developers, and Debian interests on a number of boards including at the Linux Foundation and the Freedombox Foundation. I m happily married with two children. Many people in Debian have met some or all of my family. They all joined me for Debconf in Edinburgh, and my daughter Elizabeth also attended in Caceres and New York. I joined Debian in 1994. I ve been responsible for a number of packages essential to our base system continuously since that time. But I ve also contributed to the project in many other ways over the years. I ran the first server that was fully dedicated to Debian. Ideas of mine influenced the development of project infrastructure, from the early design of our mirror network to structuring the archive around a package pool . I started or made significant early contributions to 5 ports of Debian to non-i386 architectures. I served as Debian Project Leader (DPL) in 2002-2003, was acting Secretary for a while, and have served on the Technical Committee for a number of years. Over the years, I ve also had some interesting hobbies. I helped design, build, and program pieces of various amateur radio satellites. I enjoy making physical things, and have many tools for working in wood and metals. My son and I are very active in the world of high power model rockets. And with my partner (and fellow Debian developer!) Keith Packard I m now running a small business making and selling open hardware and open source avionics for hobby rockets. You can read more about that at http://altusmetrum.org. You re the chair of the Debian technical committee. Can you quickly explain the role of this committee? I think many people assume the Technical Committee has a larger role in Debian than it really does. Section 6 of Debian s constitution defines the official role of the Technical Committee. Most importantly, the committee exists as a last resort place to resolve technical conflicts between Debian developers that they are unable to resolve by themselves. Most of the power in Debian is left in the hands of individual developers, who are usually able to collaborate with each other to make good technical decisions. So the Technical Committee s resolution process has only rarely been needed, which I think is a very good thing. From my point of view, the technical committee is not working. In many cases, the committee does not take any (timely) decision and just waits until the underlying situation has evolved to a point where the intervention of the committee is no longer needed. Do you agree with this and how can you explain it? I think it s very important for all of us to remember that everyone working on Debian does so voluntarily, and people who volunteer their time generally deserve a measure of respect and appreciation for their efforts. No issue is brought to the Technical Committee unless resolving it is expected to be really difficult, or at least contentious. And often, the issues brought to the committee have been as much or more about personality than technology. That makes some of them really hard to solve. So I do not agree that the technical committee is not working. It seems to me that the decisions that bog down and take a long time are the ones where arguments start out or become emotional instead of technical. In this context, if committee members can help lead public and private discussions in a way that causes a situation to evolve to the point where a decision is no longer needed, that may be healthier for the project in the long term than a quick vote that satisfies some contributors at the expense of others. The last important change that was made to try to revive the committee was the addition of two new members (Don Armstrong and Russ Allbery). Is there anything else that could be tried? The biggest improvement I could personally wish for is something people sending issues to the committee can help with. As the ultimate technical decision making body for a project whose output is mostly software, the more a request can be put in terms of a decision about source code, the easier it will be for us to make a decision. That won t always be possible, but when we re forced to try and dream up alternatives and then figure out whether anyone would actually be willing to write the code to implement those alternatives, the process takes a lot longer than choosing between competing patch sets or deciding whether a patch should be included. Besides your role in the technical committee, you have held the role of mediator/facilitator/advisor on numerous occasions. Because you re an old wise bearded guy who travels a lot and knows many Debian contributors I would like to thank you for all this work that few people notice. Are there been times where this has been a real burden for you? Thank you for mentioning this. I ve put a lot of my heart into Debian over the years, largely because it s a project and a community that continues to amaze and inspire me. I feel fortunate to have been able to meet and work on Debian with so many outstanding people from around the world. Many are now my friends, with all the silly and serious things being a friend implies. I ve been asked for and have given advice many times. I ve helped celebrate birthdays, marriages, new jobs, and the arrival of children. Sadly, I have also found myself having to try and find the right words to mark the loss of some of these friends The only time any of this feels like a burden is when there s some important problem that many people care about, that I m working behind the scenes to help fix, but can t really talk about publicly without causing more harm than good. It s distressing to have people think you don t care or aren t helping, when really you re doing everything you possibly can just not in a publicly visible way. Of course I understand that this is an impossible situation. If you can t see what s happening, there s no way to know if something is happening or not. That s why I advocate doing as much as possible in Debian, and SPI, and everywhere else I contribute in as open a way as possible. You have been Debian Project Leader and you promoted the vision of Debian as the Universal Operating System. What does universal mean for you? The biggest thing to me at the time was the idea that Debian could be anything. Those who chose to work on Debian would ultimately determine what Debian became. I also wanted to make sure we thought about as broad a set of potential users and collaborators as possible. But this vision provided a framework for pursuing a whole range of worthwhile increases in Debian s scope of utility, some of which I articulated in my DPL platforms, some others put forward. Internationalization, porting to more supported architectures, our inclusive and evolving approaches to accepting new developers and new packages, and so forth. I think this vision has served us well, and it pleases me that it has stayed a part of our collective thinking for so long. We re again in Debian s electoral period, what do you think of the work done by the current DPL? I m very happy with what I ve observed of Stefano s activities during his first year as DPL. He has an obvious enthusiasm for Debian, communicates well both in one to one interactions and in front of a crowd, and I think represents Debian very well. It is interesting that he s running unopposed for re-election this year. I choose to interpret that as evidence he s doing a good job, the project is running well, and nobody feels the need to try and take the job away From him. I m glad he s willing to continue in this role for another year. What s the most important thing that Debian should achieve in the wheezy timeframe? I don t yet have a very crisp personal wish-list for wheezy. But I would certainly like to see multiarch support finally completed! I m also very interested to see what comes from the CUT work. You have been an early supporter of multiarch , a project to allow easy installation of foreign architecture packages. It s on good track for Wheezy. Do you think it s an important milestone? My original motivation for requesting multiarch support was to enable support for 32-bit x86 binaries on ia64 Itanium systems, in the time leading up to the sarge release. I ended up creating the ia32-libs package, which I m not proud of. The emergence of 64-bit extensions to x86 (the amd64 architecture) made this a much broader issue. Today, I run a 64 bit kernel and a 32 bit user space on my notebook. There are problems with just moving entirely to 64 bit but I would like to be able to run some applications that work with large data sets in full 64 bit mode!

---

Thank you to Bdale Garbee for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

4 comments Liked this article? Click here. My blog is Flattr-enabled.

I m online again. (In case you didn t notice, duh ) Seems as if we (the Telco/ISP guy and me) just needed to look at it hard enough for it to go away first he could dial in, using my account data, which I probably should change now, then herc with ppp(8) and pppoe(8) was working (although at about 50 KiB/s down, he showed me 508 KiB/s a rate I had never achieved with his WiXP), then I took my notebook, which worked with pppoe(4). Now herc s working again. (Maybe altq(9) can explain the slowdown? Hm, from debian.netcologne.de I get 500 so it looks okay.)
But eurynome isn t, oh the joy. Luckily, gecko2 who administers its host system just woke up. Things we do want to see: the Telco/ISP guy accepting that I run MirBSD on a P-233MMX box with Hercules graphics card and a 9 monitor with no comment other than considering its age (and that it usually runs 24/7) as partial cause for the bug. Thanks, Netcologne! Things we don t want to see:
Mar 26 10:40:02 blau /bsd: signal 11 received by (screen:16857) UID(2999) EUID(2999), parent (screen:19111) UID(2999) EUID(2999)
Suddenly the Dungeon collapses!! - You die... (luckily, I get it about once a year only) ObCoffeeSpices: Marrakech (Cumin, Allspice, Cumin Aroma) though, due to its relative strength compared to the others, the only coffee spice I have left. And another hint: pre-warming the coffee cup with hot water, so it doesn t cool down too fast with the amounts of milk I put in, rocks. I just wore the Squeeze Release (FOSDEM, Spacefun) T-Shirt to the bakery and got asked by a neighbour: Oh, a Debian fan? Developer, even now imagine the typical informed interested guy talk for a conference booth of your OS of choice here. How proud he was to get his wife and himself Windows -free at home; how he likes to tinker a bit (if he s got any time left), which has become harder with Windows; how his time constraints have him at OpenSuSE currently but asked how squeeze is; and the usual complaints at places like $ork where they have to use Windows and MSIE (apparently you can t centrally manage Firefox, eh, good someone tells me, because that s what we do ). Wow. Anyway, it s spring, so people, wear your shirts. (Hrm, what do I make of the fact that this is my only Debian shirt although I m thinking how to get Tartan Trousers if money were no issue and nobody had ever commented on my various BSD, FOSDEM, FrOSCon, etc. wear )