As people on Gammu mailing lists probably already noticed, I don't have enough time for Gammu in past months. Simply mi priorities have shifted and can not spend so much time there anymore. I've decided to make clear cut what I'm going to do and what not. First of all I'm not going to put any extra effort on support for platforms I don't use. Today's release of Wammu no longer includes Windows binaries (they were broken anyway). Gammu releases will include them as long as they do not need extra effort. The very same applies to Ubuntu packages. Sorry, but backporting packages which are using up to date tools from Debian sid is more effort than I can put into it. Of course volunteers are welcome for both areas. For phones support, I will limit my attention to things I'm interested in or use daily (what means AT phones, Meego and possibly Symbian). Others (especially S40 Nokia phones) can not expect much support from me. And of course I still plan to maintain the projects themselves, Debian packages and packages in openSUSE Build Service.

Filed under: English Gammu 0 comments Flattr this!

It's quite some time since I haven't nagged fellow translators about Debian Installer translation status. D-I development, these days, has ups and down. The team is quite loose and activity has not been that high after Debconf. Still, enough changes took place since squeeze for localization completeness to drop to about 93% for languages that were previously 100% when we released squeeze. So, this week, I felt the need to send a call for translation updates. As usual, this woke up several translators and a bunch of updates were committed. I suspect that more will come over the next days. Sadly, as usual, the call for translation lead to several translators sending me their updates directly instead of committing them to SVN. This is unfortunately something I probably have to live with even though I keep explaining and documenting how to do things. I suspect that nobody really imagines the hassle it is when you have to check and commit files and files and files and files..... Any, here's the status for D-I level 1 (core D-I files):

• 9 languages 100% for all sublevels: bg cs de fr it ko pt ru th
• 2 languages 99%: ja si
• 1 language 96%: eu
• 3 languages 95%: eo sk zh_CN
• 5 langauges 94%: ast be fa ga sv
• 5 languages 93%: bn gu lo nb tr
• 7 languages 92%: es id nl pl ro sl uk
• 5 languages 91% et hu mr vi zh_TW

Your language is not listed here? This is because its statistics are lower and it had no single update since the release of squeeze. See the the full statistics page for details about rankings and statistics for levels, sublevels and all the crap that's described in the beautiful D-I internationalization and localization documentation. In the upcoming weeks, I'll try to continue giving updates about the progress of this effort. The only demotivating part is that I already know it will lead to gazillion of exchanges by mail with people asking about how to help...leading me to explain over and over and over and over always the same thing. Sometimes, I wonder why I took time to write all these documentation and statistics pages.... So, before you jump on your mail client and write me a mail asking me how to help in translating D-I in Northern Bechuanalese (ijekavian variant)....please join debian-i18n and/or debian-boot lists, read available documentation, check existing PO files and try to get in touch with existing teams and/or individuals. Learn a bit about SVN and figure out how to commit things. Read documentation. Ask about robots that can notify you when a file changes. Read documentation. Read documentation. In short, try to help yourself first before expecting me to hold your hands. I like holding hands and helping people. It's only that you are so many folks that I can't help you individually. But, of course, if you mail me, I'll answer anyway.. And, of course, I'll keep posting updates and nagging you guys. And, of course, we'll have more complete languages for wheezy than we had for squeeze.

There are several reasons why someone would want to build a custom kernel for their Android phone. In my case, this is because I wanted performance counters (those used by the perf tool that comes with the kernel source). In Julian Seward s case, he wanted swap support to overcome the limited memory amount on these devices in order to run valgrind. In both cases, the usual suspects (AOSP, CyanogenMod) don t provide the wanted features in prebuilt ROMs. There are also several reasons why someone would NOT want to build a complete ROM for their Android phone. In my case, the Nexus S is what I use to work on Firefox Mobile, but it is also my actual mobile phone. It s a quite painful and long process to create a custom ROM, and another long (but arguably less painful thanks to ROM manager) process to backup the phone data, install the ROM, restore the phone data. And if you happen to like or use the proprietary Google Apps that don t come with the AOSP sources, you need to add more steps. There are however tricks that allow to build a custom kernel for the Nexus S and use it with the system already on the phone. Please note that the following procedure has only been tested on two Nexus S with a 2.6.35.7-something kernel (one with a stock ROM, but unlocked, and another one with an AOSP build). Also please note that there are various ways to achieve many of the steps in this procedure, but I ll only mention one (or two in a few cases). Finally, please note some steps rely on your device being rooted. There may be ways to do without, but I m pretty sure it requires an unlocked device at the very least. This post doesn t cover neither rooting nor unlocking. Preparing a build environment To build an Android kernel, you need a cross-compiling toolchain. Theoretically, any will do, provided it targets ARM. I just used the one coming in the Android NDK:

$ wget http://dl.google.com/android/ndk/android-ndk-r6b-linux-x86.tar.bz2
$ tar -jxf android-ndk-r6b-linux-x86.tar.bz2
$ export ARCH=arm
$ export CROSS_COMPILE=$(pwd)/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-

For the latter, you need to use a directory path containing prefixed versions (such as arm-eabi-gcc or arm-linux-androideabi-gcc), and include the prefix, but not gcc . You will also need the adb tool coming from the Android SDK. You can install it this way:

$ wget http://dl.google.com/android/android-sdk_r12-linux_x86.tgz
$ tar -zxf android-sdk_r12-linux_x86.tgz
$ android-sdk-linux_x86/tools/android update sdk -u -t platform-tool
$ export PATH=$PATH:$(pwd)/android-sdk-linux_x86/platform-tools

Building the kernel For the Nexus S, one needs to use the Samsung Android kernel tree, which happens to be unavailable at the moment of writing due to the kernel.org outage. Fortunately, there is a clone used for the B2G project, which also happens to contain the necessary cherry-picked patch to add support for the PMU registers on the Nexus S CPU that are needed for the performance counters.

$ git clone -b devrom-2.6.35 https://github.com/cgjones/samsung-android-kernel
$ cd samsung-android-kernel

You can then either start from the default kernel configuration:

$ make herring_defconfig

or use the one from the B2G project, which enables interesting features such as oprofile:

$ wget -O .config https://raw.github.com/cgjones/B2G/master/config/kernel-nexuss4g

From then, you can use the make menuconfig or similar commands to further configure your kernel. One of the problems you d first encounter when booting such a custom kernel image is that the bcm4329 driver module that is shipped in the system partition (and not in the boot image) won t match the kernel, and won t be loaded. The unfortunate consequence is the lack of WiFi support. One way to overcome this problem is to overwrite the kernel module in the system partition, but I didn t want to have to deal with switching modules when switching kernels. There is however a trick allowing the existing module to be loaded by the kernel: compile a kernel with the same version string as the one already on the phone. Please note this only really works if the kernel is really about the same. If there are differences in the binary interface between the kernel and the modules, it will fail in possibly dangerous ways. To use that trick, you first need to know what kernel version is running on your device. Settings > About phone > Kernel version will give you that information on the device itself. You can also retrieve that information with the following command:

$ adb shell cat /proc/version

With my stock ROM, this looks like the following:

Linux version 2.6.35.7-ge382d80 (android-build@apa28.mtv.corp.google.com) (gcc version 4.4.3 (GCC) ) #1 PREEMPT Thu Mar 31 21:11:55 PDT 2011

In the About phone information, it looks like:

2.6.35.7-ge382d80
android-build@apa28

The important part above is -ge382d80, and that is what we will be using in our kernel build. Make sure the part preceding -ge382d80 does match the output of the following command:

$ make kernelversion

The trick is to write that -ge382d80 in a .scmversion file in the kernel source tree (obviously, you need to replace -ge382d80 with whatever your device has):

$ echo -ge382d80 > .scmversion

The kernel can now be built:

$ make -j$(($(grep -c processor /proc/cpuinfo) * 3 / 2))

The -j part is the general rule I use when choosing the number of parallel processes make can use at the same time. You can pick whatever suits you better. Before going further, we need to get back to the main directory:

$ cd ..

Getting the current boot image The Android boot image living in the device doesn t contain only a kernel. It also contains a ramdisk containing a few scripts and binaries, that starts the system initialization. As we will be using the ramdisk coming with the existing kernel, we need to get that ramdisk from the device flash memory:

$ adb shell cat /proc/mtd awk -F'[:"]' '$3 == "boot" print $1 '

The above command will print the mtd device name corresponding to the boot partition. On the Nexus S, this should be mtd2.

$ adb shell
$ su
# dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=4096
2048+0 records in
2048+0 records out
8388608 bytes transferred in x.xxx secs (xxxxxxxx bytes/sec)
# exit
$ exit

In the above command sequence, replace mtd2 with whatever the previous command did output for you. Now, you can retrieve the boot image:

$ adb pull /sdcard/boot.img

Creating the new boot image We first want to extract the ramdisk from that boot image. There are various tools to do so, but for convenience, I took unbootimg, on github, and modified it slightly to seemlessly support the page size on the Nexus S. For convenience as well, we ll use mkbootimg even if fastboot is able to create boot images. Building unbootimg, as well as the other tools rely on the Android build system, but since I didn t want to go through setting it up, I figured a minimalistic way to build the tools:

$ git clone https://github.com/glandium/unbootimg.git
$ git clone git://git.linaro.org/android/platform/system/core.git

The latter is a clone of git://android.git.kernel.org/platform/system/core.git, which is down at the moment.

$ gcc -o unbootimg/unbootimg unbootimg/unbootimg.c core/libmincrypt/sha.c -Icore/include -Icore/mkbootimg
$ gcc -o mkbootimg core/mkbootimg/mkbootimg.c core/libmincrypt/sha.c -Icore/include
$ gcc -o fastboot core/fastboot/ protocol,engine,bootimg,fastboot,usb_linux,util_linux .c core/libzipfile/ centraldir,zipfile .c -Icore/mkbootimg -Icore/include -lz

Once the tools are built, we can extract the various data from the boot image:

$ unbootimg/unbootimg boot.img
section sizes incorrect
kernel 1000 2b1b84
ramdisk 2b3000 22d55
second 2d6000 0
total 2d6000 800000
...but we can still continue

Don t worry about the error messages about incorrect section sizes if it tells you we can still continue . The unbootimg program creates three files:

• boot.img-mk, containing the mkbootimg options required to produce a working boot image,
• boot.img-kernel, containing the kernel image,
• boot.img-ramdisk.cpio.gz, containing the gzipped ramdisk, which we will reuse as-is.

All that is left to do is to generate the new boot image:

$ eval ./mkbootimg $(sed s,boot.img-kernel,samsung-android-kernel/arch/arm/boot/zImage, boot.img-mk)

Booting the image There are two ways you can use the resulting boot image: one-time boot or flash. If you want to go for the latter, it is best to actually do both, starting with the one-time boot, to be sure you won t be leaving your phone useless (though recovery is there to the rescue, but is not covered here). First, you need to get your device in the fastboot mode, a.k.a. boot-loader:

$ adb reboot bootloader

Alternatively, you can power it off, and power it back on while pressing the volume up button. Once you see the boot-loader screen, you can test the boot image with a one-time boot:

$ ./fastboot boot boot.img
downloading 'boot.img'...
OKAY [ 0.xxxs]
booting...
OKAY [ 0.xxxs]
finished. total time: 0.xxxs

As a side note, if fastboot sits waiting for device , it either means your device is not in fastboot mode (or is not connected), or that you have permissions issues on the corresponding USB device in /dev. Your device should now be starting up, and eventually be usable under your brand new kernel (and WiFi should be working, too). Congratulations. If you want to use that kernel permanently, you can now flash it after going back in the bootloader:

$ adb reboot bootloader
$ ./fastboot flash boot boot.img
sending 'boot' (2904 KB)...
OKAY [ 0.xxxs]
writing 'boot'...
OKAY [ 0.xxxs]
finished. total time: 0.xxxs
$ ./fastboot reboot

Voil .

It's quite some time since I haven't nagged fellow translators about Debian Installer translation status. D-I development, these days, has ups and down. The team is quite loose and activity has not been that high after Debconf. Still, enough changes took place since squeeze for localization completeness to drop to about 93% for languages that were previously 100% when we released squeeze. So, this week, I felt the need to send a call for translation updates. As usual, this woke up several translators and a bunch of updates were committed. I suspect that more will come over the next days. Sadly, as usual, the call for translation lead to several translators sending me their updates directly instead of committing them to SVN. This is unfortunately something I probably have to live with even though I keep explaining and documenting how to do things. I suspect that nobody really imagines the hassle it is when you have to check and commit files and files and files and files..... Any, here's the status for D-I level 1 (core D-I files):

• 9 languages 100% for all sublevels: bg cs de fr it ko pt ru th
• 2 languages 99%: ja si
• 1 language 96%: eu
• 3 languages 95%: eo sk zh_CN
• 5 langauges 94%: ast be fa ga sv
• 5 languages 93%: bn gu lo nb tr
• 7 languages 92%: es id nl pl ro sl uk
• 5 languages 91% et hu mr vi zh_TW

Your language is not listed here? This is because its statistics are lower and it had no single update since the release of squeeze. See the the full statistics page for details about rankings and statistics for levels, sublevels and all the crap that's described in the beautiful D-I internationalization and localization documentation. In the upcoming weeks, I'll try to continue giving updates about the progress of this effort. The only demotivating part is that I already know it will lead to gazillion of exchanges by mail with people asking about how to help...leading me to explain over and over and over and over always the same thing. Sometimes, I wonder why I took time to write all these documentation and statistics pages.... So, before you jump on your mail client and write me a mail asking me how to help in translating D-I in Northern Bechuanalese (ijekavian variant)....please join debian-i18n and/or debian-boot lists, read available documentation, check existing PO files and try to get in touch with existing teams and/or individuals. Learn a bit about SVN and figure out how to commit things. Read documentation. Ask about robots that can notify you when a file changes. Read documentation. Read documentation. In short, try to help yourself first before expecting me to hold your hands. I like holding hands and helping people. It's only that you are so many folks that I can't help you individually. But, of course, if you mail me, I'll answer anyway.. And, of course, I'll keep posting updates and nagging you guys. And, of course, we'll have more complete languages for wheezy than we had for squeeze.

Using plain C arrays of coordinates, instead of Vertex Buffer Objects, confused some readers. I did it so that the very first tutorials would be simpler. However, it also appears that plain C arrays are not supported at all starting with OpenGL 3.0. Plus, specifying offsets is done differently in each case, and people will use VBOs in the end for performances. So the basic tutorials are now rewritten to use VBOs It took me longer than expected!

http://en.wikibooks.org/wiki/OpenGL_Programming#The_basics_arc

So, this story begins in January 2001, when I applied in the Debian New Maintainer Process. I wanted to maintain Geneweb, which I was using to publish my genealogy research results. And I wanted to keep it up-to-date while upstream was doing a quite fast development. Moreover, I quickly noticed that Geneweb had big trouble in respecting the way data is organized on a Debian system, and respect the FHS. How to have weveral users able to publish their data on the same server without compromizing the overall system security, etc. Upstream development didn't really care about that. Daniel de Rauglaudre is an excellent genealogist and developer but he was not interested in making Geneweb clean "the Debian way". For instance, at that time, it wasn't easy to setup a server, where genealogy databases could be published without having to manually launch a daemon in user mode at each reboot. Arranging this was indeed my first contribution. I contributed a few patches to make it easier to turn Geneweb into something FHS-compliant...and I developed init scripts and an organization allowing one to have shared databases after system reboots. That was rapidly a great introduction to Debian maintainer scripts and even security-related challenges. And all this....because I needed it. Basically, in 2001, the geneweb package adopted the organization it still has in Debian and Ubuntu, 10 years later:

• daemon optionnally launched at boot time, listening on a configurable port
• daemon running with an unprivileged account
• local group of users allowed to "publish" their data by putting files in /var/lib/geneweb (should now be moved to /srv, I guess)
• related maintenance of this with debconf (including keeping local modifications made *out* of debconf, which is sometimes neglected by maintainers)

While doing so, I was going through the New Maintainer Process. The Debian developer who had signed my key was Sam Tardieu, of of those longstanding "Freenix" dudes I was sometimes hanging around. I don't remember who did write my advocacy. Michael Mattice was my first Application Manager. Interestingly, here are the three first questions he asked my as part of the Policy and Procedures check :

• Firstly, can you explain the key points of the Social Contract and DFSG?
• Donald Knuth, author of TeX, insists that no-one has the right to modify the source code of TeX, and that any changes must be made using "change files" (a sort of patch file). Furthermore, any modification of TeX which produces something which fails the "trip test" (a regression test suite) may not be called TeX. So how come TeX (in the guise of tetex-*) is in main?
• What is Debian's (current) approach to non-free software? Why?
• Debian was offered a Debian-specific license to package a certain piece of software (I forget which). Would we put it in main?

Mike actually asked the questions on February 17th and I probably answered immediately. Unfortunately it seems that I lost my answers. Maybe they are in some archive somewhere. Would be interesting to see how I ended giving an answer about the TeX exception.:-) Immediately, Mike moved to the Tasks and Skills step and checked my geneweb and lifelines packages (I already prepared a package for that other genealogy software). From my records, he found a few lintian warnings, which I probably made my best to fix, then later on, on March 12th, he answered me that thigns were OK and he was marking the T&S step as passed...handing things over to the NM database, asking me what username I wanted on debian.org (obviously, you know what I answered to this!). Then nothing happened..:-) I was not that impatient, but finally, around June 27th, I politely mailed NM Frontdesk (I guess) to get news...and I got a very quick answer by Martin Michlmayr. Martin was indeed worried about the situation (he told me I was on his radar....fun as, many years later, as many DDs, Martin probably went on mine because of pending localization work..:-)) Finally, Martin decided he was not entirely happy with the (maybe too short) processing for P&P and proposed me (very politely, you know how Martin is!) to do it again. So, some more questions...:-) Here, I have the answers. Really fun ro read. Hang on, pure bubulle style, very verbose!

• Q: Do you know (and can you explain) the difference between free speech and free beer? Is Debian mainly about free speech or free beer? My answer: Free speech means that one is able to say what one wants, without any constraint. No one can tell you what you should say. Mozilla is free software. A free beer, on the other hand, is a beer that you don't be charged for. You may drink a free beer but maybe cannot be free to choose the beer you want to drink...:-). Internet Explorer is a free beer. By chance, we french-speaking people have two different words for this (libre and gratuit). Some people have even adopted "libre software " for being used instead of "free software".
• Q: The e-mail client pine is in non-free. Can you tell me the difference between main, contrib and non-free? My answer (typos and horrible English not corrected...): Packages in main are OK with Debian Free Software Guidelines (which defin what is considered "free" by Debian) and all other requirements of the Debian Policy. Packages in contrib are OK witgh DFSG bu may break some other constraints. For instance, they may be wrappers for non-free packages (the old netscape wrappers were good examples. The setiathome package is also another example as it requires the download of the setiathome client which is not free, because source code is not available). Very buggy packages may also be placed into contrib instead of main (a QA requirement). Pakages in non-free are not conform to DFSG. Simply speaking they are not "free software" as defined by DFSG. Some of them because their licence prohibits redistribution, or redistribution of derived work (the french package of Bernard Gaulle fot Latex could fall there).
• Q: Do you agree to uphold the Social Contract and the DFSG? Answer: Yes I do (wow! I'm back 16 years down to my wedding day...:-)) (Doh, already kidding with fellow DDs)
• Q: If you are accepted as a Debian developer, you will get accounts on the Debian machines. Have you read the Debian Machine Usage Policies (DMUP) at http://www.debian.org/devel/dmup ? Do you accept them? My answer: I did read the DMUP and I fully accept them.
• Q: What are Non-Maintainer Uploads (NMUs) and when would you do an NMU? Answer: This is an update for a package which is done by someone who is *not* the official package maintainer (I guess I give the correct english definition : I read the translated dev. reference....). First of all, a NMU should be done after trying to get in contact with the official package maintainer. I don't know if this is the awaited answer, but this point looks important to me. This is the only way for verifying that (s)he is not working on the same problem. NMU's are the most welcome during freeze phases when they correct bugs rated "severe" of higher. They are also welcome when they come from Debian Security Manager(s) for correcting security-related bugs. Another NMU source are those which are needed for ports to work. As a recent, and probably not very experienced package manager, I would probably be very prident with NMU's anyway...:-)
• Q: Tell me 3 different methods to close a bug in the BTS. Answer: Well, If I have properly understood Dev. Reference, there are two recommended methods and a third which is discouraged :
  1. properly use the debian/changelog file (by adding "Closes: Bug#xxxxx" statements in it). The bug will automagically be closed by the archive maintenance software
  2. by mail by sending the .changes file to xxxxx-done@bugs.debian.org, xxxxx being the bug number
  3. by sending a "close" command to control@bugs.debian.org
  The latter should never be used, says Dev. Reference. I must admit that I don't know why it is still mentioned. There is certainly a good reason. I'm not aware of another method...
• Q: What would you do if a bug was reported against your package and you are not able to fix it yourself? Answer: First, I would double check with upstream author(s) if this cannot be fixed by him/her/them.... Then, I would probably ask for help and/or advice in debian-qa if the bug is critical, grave or serious. If it is normal, I would ask on debian-devel or maybe think more about possible solutions.... If the bug still cannot be fixed and is "severe" or higher, I would either consider orphaning it (not being able to fix it may mean that I do not have the skills for maintaining it properly) or having it adopted by someone else. I don't think there is a unique answer there. The key point for me is certainly "ask for help in debian-qa". (OK, not the best answer ever...)
• Q: You've just heard about this great program and would like to package > it, what would you do? Answer: First, check on the WNPP page. The purpose here is avoiding having two people working on the same package. Then, assuming no on,e works on it, open a bug against wnpp speudo-package with a copy to debian-devel. The "bug" should include a short description of the package and what I intend to do for packaging. The URL for downloading sources for the program should be given. The subject of the bug report is normalized. The bug report should be of the "wishlist" class. When the new package is ready and uploaded for the first time, it should include the appropriate statement for closing the wnpp bug.
• Q: Do you know what 'lintian' is? Why is it useful? Answer: It is a set of tools for making automatic checks of packages. It may detect some bugs, common errors, Debian Policy violations and so on. This is a very useful tools for polishing packages. For instance, in my "geneweb" unofficial package, the last remaining lintian report is about the creation of a /var/geneweb directory which violates Debian Policy.
• Q: What does version 3.4-2.1 mean? What Debian control file would you put this in? (Hint: NMU). Answer: This is the Debian package of version 3.4 of program "foo". The current package version in the distribution was -2 and someone made a NMU of this package. This would be put in debian/changelog
• Q: You have a package in contrib, why would it have to go there? What could you do (in theory at least) to get it into main? Answer: The package in consistent with DFSG but other constraints are not respected. The most probable reason is being dependent of "non-free" packages (there may be other reasons but none comes to my mind at this time....). In that case, I should try to make it independent of these packages. For instance, trying to replace a "Depends: netscape-base" line by a "Depends: www-browser" line...if it may be done, of course!
• Q: If you had a file in your package which usualy gets changed by a user for local settings, how doyou make sure your next version of the package doesn't overwrite it? Answer: By putting its name into the debian/conffiles line. By the way, I guess you're meaning "changed by a local system administrator for local settings" here, don't you? (hey, answering a question with another one, good trick, man...)
• Q: What would you do if you wanted to retire from the project and let other developers maintainer your packages? Answer: The correct term is "orphan" the package. Make a bug report against wnpp (with a normalised subject starting with O, see Dev. Ref). The bug severity is "normal". If this is an important package for the distribution, the bug should be of "important" severity and the bug report should have a subject beginning with RFA (Request For Azdoption). In that case, an announce in debian-devel is also asked. In both cases, a new package should be uploaded with Debian QA Group as maintainer.

What a bunch of questions..:-). Reading my answers ten years after, I see that some answers are somehow naive but, after all, they're not so bad. I really remember spending hours in writing them (my English was somehow more shaky at that time) The last question was: "Please tell me about about yourself and what you intend to do for Debian". Here, Martin opened a big can of worms..:-) So, you'll learn about this in the next episode..:-)

Hot on the heels of the PostgreSQL 9.1.0 release I am happy to announce that the final version is now packaged for Debian unstable, the current Ubuntu development version Oneiric , and also in my Ubuntu backports PPA for Ubuntu 10.04 LTS, 10.10, and 11.04. Enjoy trying out all the cool new features like builtin synchronous replication or per-column collation settings for correctly handling international strings, or an even finer-grained access control for large environments. Please see the detailled explanation of the new features. As already announced a few days ago, 9.0 is gone from Ubuntu 11.10, as it is still only a development version and not an LTS. 9.1 will be the version which the next 12.04 LTS will support, so this slightly reduces the number of major upgrades Ubuntu users will need to do. However, 9.0 will still be available in Debian unstable and backports, and the Ubuntu backports PPA for a couple of months to give DB administrators some time to migrate.

The third in my serious about my family s recent visit to Mexico see also part 1 and part 2. Shopping in Mexico was probably the thing I was least prepared for. I probably had the biggest wins of the trip shopping, and also the biggest fails (though they weren t all that significant). It seems to me that shopping is all about serendipity. You almost have to be good at impulse buying. I normally try hard to resist impulse purchases, preferring to research and compare carefully before making a decision. That attitude didn t serve me well in Mexico, and when I was able to overcome it, I got some great purchases. Around here, some of the best places to shop are the ones that have been in business for decades. Anderson Office Supply in Newton, KS, for instance, has been around for over 100 years, and has in stock, even everything from a ribbon for my slightly obscure 1940s typewriter to local history books. Moler s Camera in Wichita often meets or beats the online stores prices, and has better service. But in Mexico the best places seemed to be packed into a large crowded shopping area, or a dusty stand along a road, or a guy selling stuff on a plaza somewhere. Here is Guadalajara s market (San Juan de Dios): It s an incredible open-air market. We spent quite some time there, even ate lunch, and yet I m sure we saw only a small fraction of what they had. It was a cramped place, with small booths and tiny aisles, but all sorts of interesting things. Although I did appreciate walking quickly past the raw pork and fish corner. Terah bought some genuine extract of vanilla there, at a good price. Some of the street vendors were selling what I think were butterfly toys they had some sort of launcher that would launch them in the air, and they d flutter and float down to the ground. We saw them mainly in Guadalajara Centro on our first day, and I (unwisely, it turns out) thought, Hmm, a plastic toy our boys would love it, but I don t want to buy it on our first day. Besides, I m sure we ll see them all over or online. Wrong on both counts. So there s one of my fails. My greatest win came on the road back from Guachimontones (an ancient pyramid site). Every so often along that country road, there would be a vendor with a table selling something or other. I saw some paintings out my window, thought neat , but and here you can see how terrible an impulse buyer I am didn t actually put together that we should turn around and look at them until 10 minutes later after a bathroom stop for Jacob. We went back, and I picked out a beautiful painting on canvas of those pyramids at sunset. And the charge: 200 pesos (about $17 USD). Incredible and incredibly cheap, and there is a great place on my wall for it. The vendor was also the artist. I am kicking myself for only buying one. (No photo yet as it was too big to practically transport by plane.) Another memorable purchase was this one: This was another roadside find. We were driving through Ajijic, and I noted a rug vendor along the side of the road. I had walked past a rug vendor in the Guadalajara market, so I was keeping my eye out. I made a note to stop there on our way back out of Ajijic. So we did. This is a rug made in the Zapotec tradition, all hand-made, with natural dyes and wool. It was 550 pesos (about $46 USD), which I considered to also be a pretty good deal for what it was. I have no idea how many hours went into creating it, but I m sure it was many. My luck in shops wasn t so good. We visited Tlaquepaque, which had lots of shops selling beautiful things. But the prices there were higher than I d pay for similar things back home. Tonala s shops were too inconveniently located to be practical with what were then tired boys, so we didn t go in there. I m not used to shopping without planning, and perhaps am not very good at it. On the other hand, I really enjoyed making those two purchases, and only regret not buying another 200-peso painting! Maybe next time I m in Mexico, I ll even buy something on the first day there. Terah will be so proud..

This month, I will have been with Canonical for 5 years. It s been fantastic, but I ve decided to move on. Next week, I m going to start working for Google, helping out with ChromeOS, which I m pretty excited about. I m sad to be leaving Canonical, but I comfort myself by knowing that I m not leaving Ubuntu or any other projects I m involved in. I believe in Ubuntu, I use it everywhere, and I m friends with so many of its people. And I m still core-dev, so I ll continue to break^Wsecure things as much as I can in Ubuntu, and continue working on getting similar stuff into Debian. :) For nostalgic purposes, I dug up my first security update (sponsored by pitti), and my first Ubuntu Security Notice. I m proud of Ubuntu s strong security record and how far the security feature list has come. The Ubuntu Security Team is an awesome group of people, and I m honored to have worked with them. I m looking forward to the new adventures, but I will miss the previous ones.

2011, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

As many people reading this may know, my wife Jyoti was in the World Trade Center on 9/11. When the first plane hit, she joined some colleagues at her employers offices on the 78th floor of the South Tower to see what was going on. A few minutes later she went downstairs to her desk on the 77th floor to call me and tell me about it. That's when the second plane hit. Everyone on the 78th floor was instantly killed as she would have been if she had decided to stay. She and some friends, covered in debris and soaked in jet fuel, blinded by thick black smoke made their way down 77 flights of stairs (the elevators were out of action) and even though she was seven months pregnant with our daughter at the time she went all the way down without stopping to rest. An NYPD officer Ramon Suarez helped her out and to an ambulance. He went back to rescue others and died half an hour later when the North Tower collapsed. I was at home. After getting ready and saying my morning prayers, I was leisurly preparing breakfast before starting the day. I started getting phone calls asking "Is Jyoti ok?" Of course she was. Why wouldn't she be? I somehow don't remember who said it first but I was told to turn on the TV because a plane had hit the World Trade Center. I spent the rest of the morning glued to the screen in horror as information on what exactly had happened. Absolutely the lowest moment of my life was when I saw, in real time, the twin towers fall. It was several more hours before I actually got to talk to Jyoti on the phone, confirmation that she was still alive. I didn't get to actually see her and hold her until the next day owing to the curfew around Manhattan. So that's what happened that day. We have repeatedly been told "Never forget" but truth be told some of the details are already fading from my memory. For my wife too, while she occasionally had panic attacks at first, every day life is foremost now and it is only on days like this that her ordeal comes to mind. Our daughter Shailaja is now 10 years old and an honor roll student who just started 4th grade. She knows the story but is not affected by it. These are good things in my opinion. What the jihadists want most of all is apocalypse. They wanted the world to change course but ten years later America remains as generous, bull-headed, lively, spiritual, garish and crude as ever. That's the sweetest revenge lovers of life can have. Don't give up your rights and your daily routines to fear but make the bastards give up theirs. Or as the cliche goes, the terrorists will win.

Given his theory of the masses, critical theorist Raymond Williams would probably have not liked or believed in the concept of social engineering: The are in fact no masses, but only ways of seeing people as masses.

A few days ago I blogged about my main computer s configuration files and desktop s appearance and today I managed to add a few little tweaks to those, they are:

• Google s contacts list integrated into Mutt
• a cleaner and nicer Login screen

Curious to know how you can easily integrate your Google s contacts into Mutt? Well, you should be able to achieve that within a few minutes after reading this small HowTo: 1. Download and install goobook as explained here. 2. Setup a .goobookrc file into your Home directory. It should look like this: 3. Add the relevant configuration bits into your /etc/Muttrc file:

set query_command="goobook query '%s'"
bind editor <Tab> complete-query
macro index,pager a "<pipe-message>goobook add<return>" "Add sender's address to your Google contacts"

4. Your configuration should be good to go now, so here s a few examples on goobook s usage within Mutt:

• Use TAB if you want to auto-complete a mail address when specifying the To: field.
• Use the A key if you want to add sender s address to your Google contacts.
• Use the Q key for querying your contacts list.

We can now move on on customizing your Login Screen running GDM3. Let s begin with a screenshoot: I definitely love it, it s clear and clean and most of all it has everything I need, no extra toolbars or menus. If you agree with me, open up the /etc/gdm3/greeter.gconf-defaults file and do the needed changes. This is how your greeter.gconf-defaults file should look like:

/desktop/gnome/background/picture_filename      /path/to/your/dusty-bg/file # dusty's background can be downloaded here.
/desktop/gnome/interface/gtk_theme              Darklooks # this is my main theme, feel free to adapt that to your needs.
/apps/gdm/simple-greeter/logo_icon_name         debian-swirl # this is the default on Debian's systems.
/desktop/gnome/sound/event_sounds               false # I don't like hearing any sound when when I am prompted to insert my user's details on the Login Screen.
/apps/gdm/simple-greeter/disable_user_list      true # users list will be disabled, you won't be able to select your username from a list but you'll have to insert that yourself.
/apps/metacity/general/compositing_manager      false # default, no need to change this.
/apps/gnome-power-manager/ui/icon_policy        never # default, no need to change this.

We are close to the end but we are missing an important detail: how can you safely remove bottom s toolbar and menus for a clearer and cleaner Login Screen? Open up the /var/lib/gdm3/.gconf.mandatory/%gconf-tree.xml file, search for the <dir name= general > section and apply the following change:

- <entry name="compositing_manager" mtime="1315580582" type="bool" value="false"/>
+ <entry name="compositing_manager" mtime="1315580582" type="bool" value="true"/>

But what if you prefer keeping the toolbar as it is, but you definitely don t like seeing the Accessibility icon appearing on your Login Screen? On the same file as above, search for the <dir name= accessibility > section and modify the following string as it follows:

- <entry name="enable" mtime="1315580582" type="bool" value="true"/>
+ <entry name="enable" mtime="1315580582" type="bool" value="false"/>

See you on my next blog post and don t forget to have a look at my GitHub s repository! Oh and follow me on Twitter!

Today was my last race before Berlin marathon on Sept. 25th. Berlin is meant to be one of the three "peaks" of my running year, after the succession of Paris Ecotrail (55km) and Paris marathon in two weeks in April....and before a 67km night race in November (Le Puy-Firminy). I was worried about my shaky training last weeks because of some pain in an ankle which I partly twisted while running on a very steep trail in early August. So, I planned running an half-marathon today in Bois d'Arcy, very close to my place. Last year saw me completing this one in 1h37. Of course, no way this time to try this again: the point was running at my planned marathon pace (5'05"/km) for the first 18-19km and "see what happens" later on. Even trying this two weeks before a marathon is....unrecommended! I made this fairly well, with a 5'/km pace for the first 10km, then a little slowdown between km10 and 15 (mostly because I was running all alone in large and very straight alleys in the forest)....and a very very long sprint from km 18.5 with speeds up to 4'40"/km, and a final 400m where I was kinda flying (1'37"). So, finally, I end up with a very promising 1h43'19", much below the planned 1h45, and my second half-marathon time ever. Now, two weeks mostly resting as the goal will be keeping this 5'05" pace in Berlin, for a targeted 3h35 (which is kinda ambitious considering my lack of speed work during last weeks while I was trying to recover this injured ankle). See you in Berlin on 25th....

With this release come two long-awaited improvements:

• database speedups;
• fix for iTunes timing out after 30 minutes.

This is the best response to this (simplistic) claim about net access and revolt in Egypt featured in the New York Times: [m] In a widely circulated American Political Science Association conference paper, Yale scholar Navid Hassanpour argues that shutting down the internet made things difficult for sustaining a centralized revolutionary movement in Egypt. But, he adds, the shutdown actually encouraged the development of smaller revolutionary uprisings at local levels where the face-to-face interaction between activists was more intense and the mobilization of inactive lukewarm
[m] maybe we ll have some more fiber optic cable cuts in silicon valley and then the revolution will happen

So, Rugby World Cup 2011 began yesterday. Tricky for us europeans to watch those games in New Zealand, particularly during the week. So, I think I'll mostly tape the games that happen in the morning (New Zealand's evening) or night (NZ afternoon)....and try to avoid my work colleagues to spoil results. One game per day will be mostly what we'll be watching, so expect me talking about scrums, offsides, tries, etc. in this blog, for about 1.5 months until October 23rd. The opening ceremony was great, with many references to New Zealand's roots and culture as well as the rugby traditions and values. Its closing with fireworks all over Auckland were apparently very nice...unfortunately they were ruined by the broadcasting of the infamous TF1 TV channel here. Yes, unfortunately RWC games are mostly broadcasted on TF1 here, a channel that usually never broadcasts rugby. This already was a big PITA for RWC2007 and I fear it will be the same this time, particularly for games of the french team. The opening game between Tonga and New Zealand was without surprise. Tonga were indeed crushed very quicly in 1st half, mostly because being too weak in defense on the outside game. All Blacks rear players were very inspired and nearly didn't miss anything during that lahftime, which lead to 29-3 after 4 minutes. Impressive. However, All Blacks game vanished during 2nd halftime and Tonga could even score a try after a really impressive 10 minutes pick and go battle. That made me happy for the Tonga players (half of them do indeed play in France...). In 45 minutes, we'll have the opening for France, against Japan. That should theoretically be easy but, well, anything can happen. We'll see!

One of the big things that seems to cause a learning curve for many new contributors for Linux and other projects that make a big effort with code review is the process of putting patches together in a way that makes the code review process more smoothly. This is a fairly straightforward thing but it takes a bit of getting used to for people who aren t used to the idea of patches and commits as a means of communication rather than just a mechanical thing you do to get changes into the codebase. In cases I ve seen the difficulty . I m mostly going to talk about this in the Linux context where patches are reviewed by e-mail but the same ideas apply if you re using a tool like gerrit to do the reviews; it s also mostly focused on detailed review rather than design level review. The basic idea is fairly simple the goal is to make it as easy as possible for someone to read and understand the change that s being made.

• Make sure the code matches the coding style of the code being modified.
• Make patches as small and self contained as possible having many patches is much easier than having complicated patches.
• Provide a changelog clearly describing everything that s going on in the patch.

The result here should be something that s easy for people to review. Keeping in line with the coding style is just a generally good idea for code legibility which is obviously a key thing for people reading the code to review it. Having a clear description of the change means that the reviewer knows what the patch is supposed to do and can verify that the patch does that rather than having to spend effort figuring out if whatever the code is doing is intentional. Making changes small and simple makes them much easier to think about the idea itself is easier to keep in your head and there s fewer things to check so the process of validating things is easier. It s not just about making life easier for reviewers. The process of making simple changes and describing them clearly can be really helpful for spotting issues when writing code; it forces you to think through what s being done much more clearly than might happen otherwise. There s also an ongoing benefit to anyone working with the code in the future. Since each change ends up including at least some explanation of what the code is supposed to do and since revision control systems generally have some equivalent of git annotate it s usually reasonably straightforward to find the changes that introduced the code that you re looking at. Small changes with good changelog entries mean it s much more likely that the changelog will provide a useful explanation as to what the author was thinking and explain why the code is the way that it is. It s much harder for documentation to go missing from the SCM than it is for it to go missing elsewhere, and it s much more likely that documentation in the commit is going to be up to date than external documentation, especially prewritten design documentation. In the context of large scale reviews the usual technique is to combine reviews of individual changes with a read through of the final code after all the individual changes have been applied. Often the build up of the code through incremental changes is a enough to show the overall design but a read through of the final code can be helpful in allowing people to understand where things are going.

Posted from Santa Rosa, California, United States.

One of the reasons why I m moving from a laptop to a cloud lifestyle [1] is that laptops suck nowadays. Engineering Trade-offs Laptops have always had disadvantages when compared to desktop systems. The screen has to be smaller, the keyboard is inconveniently small on the smaller laptops and netbooks, you don t get PCI slots (CardBus isn t nearly as good), you usually can t have multiple hard drives and expansion options for other things are limited. Also due to the difficulty in designing a computer that uses a small volume it s very difficult to repair a laptop and there are no realistic options for upgrading the motherboard to use a faster CPU etc. This is OK, it s engineering trade-offs that we have to deal with. CPU Speed Modern laptops however have some bad design choices. Firstly they appear to be trying to compete with desktop systems for CPU speed. This was reasonable when desktop systems had 200MHz CPUs which dissipated about 15W (see the Wikipedia page about CPU power dissipation) but now that desktop CPUs are dissipating 65W at the low end and more than 100W at the high end it s really not practical to try and compete. My Thinkpad T61 has a T7500 CPU that can dissipate 35W, getting that much heat out of a laptop case is a significant engineering challenge no matter how you do it. It s a pity that no-one seems to be making laptops with large screens that have a low-power CPU. Sure it takes a moderate amount of CPU power to use a large display for games or playing video, but if you want to use a laptop for work purposes then not much CPU power is required. For tasks which take a lot of CPU power you can offload it to the cloud, I can ssh to a server to do compiles, and one of my clients is setting up an Adobe After Effects render farm [2] (in the broadest sense of the word Cloud can include a server accessed by ssh and a few servers on the LAN running After Effects). Thin Laptops The next problem is laptops being thin, it is really convenient to have a thin laptop, but the thinner it is the smaller the fans have to be and the faster the cooling air has to travel through small heat sinks. At the best of times this results in more noise from the cooling fan (which really isn t so bad). But it also increases the rate at which dust builds up inside the case and insulates the heat sink. When a laptop is thin and light for convenience and also wide to have a large display it just can t be that strong, so laptops tend to bend. If I put an Australian 10c piece (the size of a US Quarter) under one of the feet of my Thinkpad T61 the other three feet touch the desk! Presumably the laptop would bend in every way imaginable if you were to put it on your lap which of course you can t do because there are cooling vents in the bottom so it can give you a hot lap and an overheated laptop. My first Thinkpad was 61mm high according to the IBM spec sheet. I measured my latest one at 34mm. As 61mm wasn t too bad I think I could survive now with a laptop that was 45mm high and had more strength and less cooling problems. My Thinkpad T61 currently has some serious cooling problems, I suspect that something is broken inside. As it s out of warranty I took it apart but couldn t find anything wrong, so I guess I ll have to pay to get it repaired. This will be the third time I ve had a Thinkpad repaired because of cooling problems, but the first time one has been out of warranty. I blame the engineering trade-offs required to make them thin. Portable Desktop/Server systems If you want a small portable computer that delivers great performance then a Mac Mini seems to be a good option [3]. The people who use a laptop at their desk at work and their desk at home would probably be better served by a Mac Mini. The Mac Mini can be purchased with SSD storage to reduce the risk of data loss due to being dropped. Admittedly the Mac Mini needs to be plugged in before it can be used, but if you had a USB Ethernet device and a USB hub then only three cables would be required, power, USB, and video one more cable than the typical office laptop use with Ethernet and power. Some modern laptop/netbook systems (such as the Thinkpad T61 and the EeePC 701) seem to be designed to use the keyboard as part of the cooling system. If you run it with the lid closed then it becomes significantly hotter. This makes laptops unsuitable for use as a portable server. Probably one exception to this is the Apple laptops which have a rubbery keyboard that doesn t allow air flow of course anyone who likes the feel of a real keyboard won t buy an Apple laptop for that reason (but a keyboard that has one really hot section above the CPU doesn t feel great either). In the past I ve used laptops as servers once they become unsuitable for their primary use, probably in future I won t be able to do that. ARM Laptops There are some laptops and tablets with ARM CPUs that should dissipate little heat. But I m not aware of any such devices that I consider to be practical Linux laptops. I ve done some work with iPaQ s running Familiar in the past, it was a nice system but it was a niche market and everything was different from every other system I ve ever used. That made all the work take longer. What would be ideal is an ARM based laptop (not netbook a big screen is good) that boots from a regular CF or SD card (so the main storage can be installed in another machine to fix any boot failures) and which is supported by a major Linux distribution. Does anyone know of any work towards such a goal?

• [1] http://etbe.coker.com.au/2011/09/08/laptop-to-cloud-lifestyle/
• [2] http://help.adobe.com/en_US/AfterEffects/9.0/WS3878526689cb91655866c1103a4f2dff7-79a2a.html
• [3] http://www.apple.com/au/macmini/

Even though Enrico is not smiling on this picture, he s one of the friendliest Debian person that I know. I always enjoy his presentations because he can t refrain from inserting jokes or other funny tricks. That said he s serious too, there s lots of good stuff that he has developed over the years (starting with Debtags) and he has put a lot of effort in reforming the New Maintainer process. Read on to learn more about his various projects. Raphael: Who are you? Enrico: Hi, I m Enrico Zini, a DD from Italy. I m 35 and I work as a freelance Free Software developer. One of my historical roles in Debian is taking care of Debtags, but that is not all I do: my paid work led me to write and maintain some weather forecast related software in Debian, and recently I gained a Front Desk hat, and then a DAM hat. Raphael: How did you start contributing to Debian? Enrico: It was 2001, I was at uni, I was using Debian. At some point I wanted to learn packaging so I read through the whole Policy from top to bottom. Then I thought: why package only for myself? . There were many DDs at my uni, and it only seemed natural to me to join Debian as well. Evidently this was also natural for Zack [Note from editor: Stefano Zacchiroli], who had become DD 6 months earlier and didn t hesitate to advocate me. I found the Policy and the Developer s Reference to be very interesting things to read, and I welcomed my AM s questions as an excuse to learn more. I completely understand those people who have fun trying to answer all the questions in the NM templates while they wait for an AM. With my super DAM powers I can see that my AM report was submitted on October 16, 2001 by my AM Martin Michlmayr, and that James Troup created my account 9 days later, on October 25. Raphael: You have a special interest in the New Maintainer (NM) Process since you are a Debian Account Manager (DAM) and a member of the NM Frontdesk. Thanks to your work the process is much less academic/bureaucratic than it used to be. Can you remember us the main changes? Enrico: One of the first things I noticed when I become a Front Desk member is that there was a tendency to advocate people too early, thinking by the time they ll get an AM, they ll know enough . Unfortunately, this didn t always work, and once the real NM process started it would turn into a very long and demotivating experience both for the applicant and for the AM. So we tried raising the bar on advocacies, and that seems to have helped a lot. If people join NM when they are ready, it means that NM is quick and painless both for them and their AMs, who are therefore able to process more applicants. We also did a rather radical cleanup of the NM templates , which are a repository of questions that Application Managers can ask to their applicants. We realized that AMs were just sending the whole templates to their applicants, so we moved all non-essential questions to separate files, to drastically reduce the amounts of questions that are asked by default. Other improvements in the NM process came from other parts of Debian: nowadays there are lots of ways to learn and gradually gain experience and reputation inside the project before joining NM, which means that we get many candidates who we can process quickly. For example, packages can now be uploaded via sponsors, and the Mentors project helps new contributors to find sponsors and get their first packages reviewed. Then one can now become Debian Maintainer and take full responsibility of their own packages, gaining experience and reputation. The idea of working in teams also helped: big teams like the Perl, Python, KDE, Ocaml, Haskell teams (and many more) are excellent entry points for people who have something to package. But Debian is not just for packagers, and one could join teams like the Website team, the Press and Publicity team, the Events and Merchandise team or their local translation team. Becoming DDs the non-uploading way is not just for non-technical people: one could enjoy programming but not packaging. An interesting way to get involved in that way is to help writing or maintaining some of the many Debian services. Note that I m not suggesting this as a way to learn how to program, but as a way to get involved in Debian by writing code. Finally, we started to appreciate the importance of having people activities in Debian explicitly visible, which means that the more obviously good work one has done in Debian, the less questions we need to ask. Jan Dittberner s DDPortfolio is an excellent resource for AMs and Front Desk, and I m maintaining a service called minechangelogs that for people who have done lots of work in Debian is able to fully replace the Tasks&Skills parts of the NM process. Raphael: What are your plans for Debian Wheezy? Enrico: For Wheezy I hope to be able to streamline and simplify Debtags a bit more. At Debconf11 I had a conversation with FTP-masters on how to make some tags more official, and I now have to work a bit more on that. I d also like to considerably downsize the codebase behind the debtags package, now that its job is quite clear and I don t need to experiment with fancy features the way I did in the past. I have to say that I enjoy programming more than I enjoy packaging, so most of my plans in Debian are not tied to releases. For example, I d like to finish and deploy the new NM website codebase soon: it would mean to have a codebase that s much easier to maintain, and in which it s much easier to implement new features. I d also like to design a way to allow maintainers to review the tag submission to their own packages instead of having to wait for me or David Paleino to do a regular review of all the submissions. Finally, I d like to promote the usage of apt-xapian-index in more cutting-edge packaging applications. And to design a way to maintain up to date popcon information in one s local index. And improve and promote those services that I maintain, and I tend to often have ideas for new ones. Raphael: If you could spend all your time on Debian, what would you work on? Enrico: If I could spend all my time on Debian, I would do a lot of software development: I love doing software development, but most of my development energy is spent on my paid work. I guess I would start my all your time in Debian by taking better care of the things that I m already doing, and by promoting them better so that I wouldn t end up being the only person maintaining them. After that, however, I reckon that I do have a tendency of noticing new, interesting problems in need(?) of a solution, and I guess I would end up wildly experimenting new ideas in Debian much like a victorian mad scientist. Which reminds me that I most definitely need minions! Where can I find minions? Raphael: You re the author of the Debian Community Guidelines. I have always felt that this document should be more broadly advertised. For example by integrating it in the Developer s Reference. What do you think? Enrico: The DCG was really a collection of tips to improve one s online communication, based on ideas and feedback that I collected from pestering many experienced and well-respected people for some time. Like every repository of common sense, I think it should be widely promoted but never ever turned into law. It wouldn t be a bad idea to mention it in the Developer s Reference, or to package it as a separate file in the developers-reference package. The reasons I haven t actively been pushing for that to happen are two: there isn t much in the DCG that is specific to Debian, and I don t have the resources to do a proper job maintaining it. It d be great if somebody could take over its maintenance and make it become some proper, widespread, easy-to-quote online reference document, like one of those HOWTOs that all serious people have read at some point in their lives. Raphael: What s the biggest problem of Debian? Enrico: It s sometimes hard to get feedback or help if you work on something unusual. That is partly to be expected, and partly probably due to me not having yet learnt how to get people involved in what I do. Raphael: What motivates you to continue to contribute year after year? Enrico: Debian keeps evolving, so there is always something to learn. And Debian is real, so everything I do is constantly measured against reality. What more intellectual stimulation could one possibly want? Raphael: Is there someone in Debian that you admire for their contributions? Enrico: I don t think I could reasonably list everyone I admire in Debian: pretty much in every corner of the project there is someone, sometimes not very well known, who is putting a lot of Quality in what they do. Someone who decided that X should work well in Debian or that Debian should work well for Y or that Z is something Debian people can rely on and makes sure that it is so. Those are the people who make sure Debian is and will be not just a hobby, but a base upon which I can rely for my personal and working life.

---

Thank you to Enrico 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.

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