Triaging bugs is one of the easiest way to start contributing to Debian. I ll teach you the basics in this article. 1. Prerequisites All interactions with the Debian Bug Tracking System (BTS) happen through email so you need to have an email account with an address that you re willing to make public. All the mail that you send to the BTS will be archived and publicly available through its web-interface. This also means that you should have some spam filters in place because it will inevitably be harvested by spammers. To ensure that this email address is consistently used by the various tools that we re going to use, it s a good idea to put this email address in the DEBEMAIL environment variable. You can also specify your full name in DEBFULLNAME (in case you don t want to use the name associated with your Unix account). You usually do this by modifying ~/.bashrc (if you use bash as login shell):

export DEBEMAIL="hertzog@debian.org"
export DEBFULLNAME="Rapha l Hertzog"

You should also install the devscripts package, it provides the bts command that we re going to use. 2. Find a package or a team with too many bugs You can literally pick any popular software that s in Debian, they almost always get more bug reports than the maintainers can handle. Instead of picking a package, you can also select a packaging team and concentrate your efforts on the set of packages managed by the team. In any case, it s important to receive the bug traffic for the packages that you re going to work on. If you went for a specific package, you should subscribe to the package via the Package Tracking System (there s a subscribe box on the bottom left corner once you selected the source package of interest). If you decided to help a team, there s usually a dedicated mailing list receiving all bug traffic. You can browse a list of packages with the most bugs if you have troubles finding a package to work on. 3. Triage bugs! Bug triaging is all about making sure that bugs are correctly classified so that when a developer looks at the bug list, he can quickly find bugs with all the information required to be able to fix them! 3.1 Adding information to bug Adding supplementary information is easily done just by sending a mail to XXXX@bugs.debian.org (replace XXXX with the bug number). But often you want to reply to a message in the bug history, in that case bts --mbox show XXXX is for you. It will grab the corresponding mailbox and open a mailer (mutt by default) on it. Now you can directly reply in your favorite mailer. 3.2 Classifying bugs The Debian BTS uses tags (click the link and read the doc!) to classify bugs. bts tag XXXX + foo will add the foo tag (replace the + with a to remove a tag). If you want to explain why you re adding a tag, you should instead reply in the bug log as explained above, put control@bugs.debian.org in Bcc (Blind Carbon Copy) and start the body of your message with your tag command:

tag XXXX + foo
thanks

But what tag should you add? When a bug is submitted, you should try to reproduce the bug. If you can reproduce it, then tag the bug confirmed (example in #641710). If you can t, you should request more information (ex: a sample document triggering the bug, a configuration file, the output of some relevant command, etc.) until you can reproduce it or conclude that it was a user mistake. When you request supplementary information due to this, you should tag the bug unreproducible moreinfo (example in #526774). moreinfo should be later dropped when the requested information are provided, and unreproducible should be dropped if those information were enough to actually help reproduce the bug (example in #526774). During that initial evaluation, it s also worth differentiating packaging bugs (which are specific to Debian) from upstream bugs (which are relevant also for non-Debian users). The latter should be tagged upstream (and forwarded upstream if the bug is reproducible or contains enough information for the upstream developers, example in #635112). If you saw a (viable) patch in the bug log, the bug should be tagged patch . This is usually done by the patch submitter but sometimes it s forgotten (example in #632460). Take care though to not reinstate the patch tag if it was initially set but then dropped by the package maintainer after a review of the patch. If the title of the bug report is not descriptive enough, you can change it with a retitle XXXX new-title command (example in #170850). You can also change the severity of the bug report depending on the impact of the problem (with a command severity XXXX new-severity , what a surprise!). Request for new features are wishlist , most documentation problems are minor . On the other side of the scale, you can use important for bugs that are very annoying but that should not block a release. serious , grave and critical are used for release critical bugs, check the official definitions of the severities (examples in 502738 or #506498). 3.3 Closing non-bugs and bugs that are already fixed If your analysis of the bug report is that it s not really a bug but a user mistake, then you should close it by sending a mail to XXXX-done@bugs.debian.org with some explanations of the user s mistake so that he can get past his problem (example in #592853). If the problem was a real bug, but one that is apparently already fixed, you should try to quickly find the version that fixed the bug. If you can t find it in the changelog (there s a link to it in the PTS, or you can use /usr/share/doc/package/changelog.Debian.gz), you ll make the safe assumption that the upstream version you re currently using is the first one where this is fixed. Then you send a mail to XXXX-done@bugs.debian.org but you start your mail with Version: version-that-fixed-the-bug and continue with a small explanation of why you believe the bug to be fixed by this version (example in #122948). 3.4 Reassigning misfiled bug reports Bug reports are not always filed against the proper package. Users file bugs against applications where they experience the bugs, but the real bug might be in an underlying library or application. When that happens, you should use the reassign XXXX correct-package version command to get it filed against the correct package. The version parameter is optional but should be provided if possible, it should be the oldest version that we know to have the problem (example in #626232). 3.5 Forwarding bugs Forwarding bugs means opening bug reports in the upstream bug tracker for issues that have been reported in Debian but that applies to the upstream (unmodified) source code. Be sure to include all the relevant information and a link to the corresponding Debian bug. Depending on the upstream bug tracker, you might have to open an account to be able to file new bug reports. On the Debian side, you must record that a bug has been forwarded with bts forwarded XXXX upstream-bug-url . upstream-bug-url is the URL corresponding to the upstream bug report you created (ex: http://projects.ciarang.com/p/feed2omb/issues/21/ recorded in #609345 ). If the upstream authors fix the bug you reported, you can tag the Debian bug with fixed-upstream so that it s easier to find bugs to close when the next upstream release comes out (example in #637275). 3.6 Updating version information The Debian BTS uses version tracking to know which package versions are affected by a given bug. It s particularly important to have correct version information for release critical bugs since it might affect the migration of packages to testing. You can learn more on this topic here: http://wiki.debian.org/HowtoUseBTS. 4. More advice Colin Watson wrote a constructive rant explaining some mistakes that bug triagers are often doing. While it refers mainly to Ubuntu s launchpad, the advice apply equally as well to Debian. Check it out to become a better bug triager! Note that you can refer to this article with this shorter URL: http://raphaelhertzog.com/go/bugtriaging/

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

One comment Liked this article? Click here. My blog is Flattr-enabled.

The fifth in a series; see also parts 1, 2, 3, and 4. One piece of advice we got in Mexico went like this: the nicer a place looks, the worse the food and prices will be. Roadside taco stands will be great, and nice-looking restaurants not so much. That seemed to be accurate. We only tried one real nice-looking restaurant and it was very good (though pricy), but it may have been sort of an exception. But perhaps the most interesting bit about eating in Mexico wasn t the food. It s the adventure. We ate one day at Guadalajara s San Juan de Dios market. In that huge labyrinth somewhere was a set of restaurants. They d tend to have a small cooking area, usually just open, and a few tables. We chose one. And at this point, I have to take brief detour and explain something. There are a lot of people in Mexico that do things for tips, and quite often without being asked. Some other examples might be washing a car s windshield at a stoplight. So anyhow, we had ordered our food, and before long, a guy wanders down the aisle and plonks down a boombox. And turns it on. And then he pulled out a microphone, which we quite soon realized was connected to the boombox. (I guess making it more of a karaoke box.) Anyhow, he started singing a song decently and seemed to be enjoying it. About 45 seconds into it, a competing boombox man plonked down a competing boombox 25 feet away, turned it on, and yes, you guessed it pulled out a microphone and started singing a different song. Worse than the first person but louder. Eventually the boombox people left and our lunchtime conversation could resume. But pretty soon a drum guy showed up. He had a bunch of drums on a strap so he could just walk around and play them. He apparently decided that an excellent place to play them would be directly behind my head. I did not entirely agree with his decision, but hey, it beat the competing karaoke guys. Eventually the drum guy left, and somehow between the time I looked down to get out money to pay our bill and the time I had it counted out, a clown had shown up and made several balloon animals for our boys. I tipped him, we paid, and then headed on. You might think from this story that this would be an annoying series of events. And honestly, if it had happened in a big mall in the USA, it would probably have been both annoying and creepy. But really I enjoyed it. The fact that dueling karaoke happened, despite sounding really awful, was pretty funny and really seeing this whole parade of people was interesting too. It made American restaurants seem a little boring. You always know what s going to happen here (and if something surprising does happen, the place probably gets a bad review on Yelp.) Interesting things sometimes happen at mealtimes in Mexico and I like it that way. I had a torta ahogada (drowned sandwich) at that restaurant. And at this point, another brief aside. I m the kind of person that can go to an average American restaurant, see items on the menu helpfully indicated as spicy, order one, and genuinely wonder if other people would find them spicy, because I either don t notice spiciness at all, or maybe notice a tiny bit if I concentrate really hard. Others, meanwhile, might take a bite and lunge for the water. Having said that, I know people that lived in Thailand for awhile and I have nowhere near their tolerance for spiciness. So, having been in Mexico a whole 24 hours or so, I decided not to follow Jonathan s wise lead in ordering a torta with the spicy sauce on the side. I figured I hadn t had anything spicy yet, so maybe this was would be nice and mild for me. Via Jonathan s translation, I ordered it with the spicy sauce. I believe the phrase I heard him use was con chile . The waitress looked at me, gave me an amused the American is ordering it con chile? Hahaha . sort of smile, and went off. Pretty soon our food arrived. (The food always seems to arrive pretty soon in Mexico, by the way.) Oliver was having a bit of a culture shock that day, and mostly refusing to eat (once hunger got the best of him later, he really enjoyed Mexican food.) But the rest of us dug in, including me. I enjoyed my torta. It was spicy, but not too bad. I took some big bites (it was, after all, a thick sandwich) and was really enjoying it. For about a minute. Slowest-acting spiciness I ve had in awhile. Then it hit me. Spiciness, and lots of it. I took a big gulp of my horchata (a creamy sweet rice drink that I found at many restaurants). That helped. A little. I really liked the torta and ate it, but it wouldn t surprise me if the waitress noticed how extremely quickly a drank my horchata Another interesting experience was in Guanajuato. It was raining as we walked towards the Guanajuato market. Their market was large and similar in concept to the Guadalajara one, though a lot smaller. The restaurants were all in a row, in a side of the building that was open to the outside. Most were on the ground level but it looked like a restaurant or two were upstairs. As we approached, all of a sudden people were yelling at us. First it was a guy on the second story, then pretty soon people at the restaurants on the first floor did so as well. They were yelling rapidly in Spanish, waving their menus around in the air. I m imagining they were naming foods they sold or reasons to eat there, but I don t know enough Spanish to know. As we walked down the long row of restaurants, the ones we left behind would quiet down in disgust and other hopeful restaurant owners would take up the yelling and waving cause. I imagine if we did some time-lapse videography and walked up and down that row, we could produce an effect not unlike the sound of a dot-matrix printer going back and forth on the page. Anyhow, we selected one of the quieter restaurants pretty much random. The others then quieted down until another person chanced to walk past at which point it would get loud again. The lunch there was good but I think I mainly will remember it for the selection process! On our way into Guanajuato, we stopped at a wonderful roadside taco place. In typical fashion, they had a large vertical pork thing (I don t know the proper word for it) from which they would carve off meat on the spot anytime someone ordered something with pastor. We found a table. And we ordered a few tacos and such. They were usually a few pesos each (working out to less than a dollar), small round things on a soft tortilla, with meat, cilantro, and onion on top. And typically delicious. They had very little in common with an American taco . We d often order a few, and if we wanted more, just order more. They were made quickly enough for that. Tacos were very similar from one restaurant to the next. My favorite flavors were pastor (pork), chorizo (sausage), and bistec (beef steak). A restaurant in Guadalajara sadly I ve forgotten its name, since we kept calling it the potato place had what I might call a Mexican version of the loaded baked potato, with a meat, queso (cheese), a delicious sauce with a flavor unlike anything I d had before, and some garnish. But really my favorite thing from that restaurant was their amazing juices. I am not much of a juice drinker normally, but in Mexico I went for them whenever they were offered. What passes as fruit juice in the USA has about as much resemblance to a real Mexican fruit juice as Taco Bell has to a real Mexican taco stand. (Very little, in case that wasn t crystal clear.) That particular restaurant offered three types of juices, which were, if I m remembering right, aguas, frescas, and jugos. I has a jugo verde (green juice) on the first visit there. It was good, but the one I can still remember was called, I think, the fresa fresca (fresh strawberry juice). And it was incredible. I m not sure how to describe it, other than real. One observation before I end. It seemed a common thread at some Mexican roadside taco stands to not have soap in their restrooms. Instead there would be a plastic cup holding I kid you not powder-form Tide laundry detergent. It was amusing anyhow. My hands left those places extremely soft and smelling like laundry. One of the last restaurants we visited on our trip was in Ajijic, near the Chapala lake. It was actually right on the lake and served seafood. This was the only restaurant with prices as high as I d be used to in the United States. I ordered a stew served in a stone bowl. It came out sizzling, and since the very thick stone bowl retains heat well, it kept sizzling the entire time I was eating. It was excellent as usual. Coming up in part 6: some thoughts on returning to the United States, our decision to visit, communication, and tips for anyone else considering a first visit to Mexico.

Two days after my first update, here's a progress report about D-I l10n? Status for D-I level 1 (core D-I files):

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

So, Japanese and Sinhala reached 100%. Great effort by Danishka Davin, the translator from Sri Lanka, who also sent me impressive pictures of a local FLOSS event, apparently taken at the booth of HanthanaLinux, a local distro based on Debian. I had many privat email discussions with translators. Several of them were used to send me updates, which I committed in the past. I really want them to be able to commit themselves. So, I end up explaining how to svn+ssh on Alioth and remotely debugging their setup. I have to say this is really painful...:-) So, I may end up again in committing what they sent to me..:-(

Matthias Klose, the tireless force behind the Debian / Ubuntu gcc, python, and what have you packages, sent me a minimal patch to let littler build when the ld linker uses the --as-needed option (as Ubuntu builds now do): all it took was a little reordering of arguments. With that, I did a little cleanup as it has been a while since version 0.1.3. The brief (upstream) ChangeLog is as follows:

2011-09-15  Dirk Eddelbuettel  <edd>
        * configure.in: Mark as release 0.1.4
        * Makefile.am: Applied patch by Mathias Klose to prevent FTBFS with
          'ld --as-needed', cf LP bug 770980.
        * littler.c: A few small tweaks suggested by 'gcc -Wall'
        * examples/install2.r: Added a second R package installer example
        * examples/update.r: Switch to '/usr/bin/r -t' as shebang line
        * examples/fsizes.r: Dito
        * littler.c: Update copyrights to 2011
        * README: Idem

littler provides r (pronounced littler), a shebang / scripting / quick eval / pipelining front-end to the the R language and data analysis environment. As usual, our code is available via our svn archive or from tarballs off my littler page and the local directory here. A fresh package is in Debian's incoming queue and will hit mirrors shortly.

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.

The fourth in a series; see also parts 1, 2, and 3. This post is going to be more a photolog than a narrative, and I apologize in advance for it being a bit disjointed. I ve already touched on these themes a bit in the other post, but now it s time to focus on them. Immediately after leaving the airport, it s quite clear that things are a little different. Trees are square. People ride around in the backs of pickups sometimes on top of piles of debris. Left turns are made in front of other lanes of traffic going the same way. But those are just the things obvious from the road. It s a lot of fun to enjoy the differences. First, the ubiquitous square trees. They look pretty, and are found all over. I also found carefully-manicured trees in cone shapes, more cylindrical shapes, etc. It seems that tree care is taken seriously in Mexico. It was also not uncommon to see the bottom few feet of a tree painted white. A park in Guanajuato had a whole bunch of trees carefully trimmed. And from up on the mountain, it still looked impressive (the green area behind the dome). Driving in Mexico was interesting for a lot of reasons. The highways there aren t quite as limited access as the freeways in the USA. It was quite common to see bicyclists, walkers, a mule, or some cattle ambling along the side of the road. Roadside taco stands don t require taking an exit. You just pull off the road because it s right there. Some sights were a bit surprising. Cattle in a pickup, with rope, for instance. Or cattle crossing the highway on the overpass. Street vendors were everywhere. Stop at a red light and someone might spring from the side of the road and suddenly start washing your windshield (expecting a tip); try to sell you flowers, juice, or bug zappers; or even throw business card-sized advertisements for adult websites into any open windows they can find. One night we saw an incredible fire juggler. I would have tipped him well but he was too far away to do so before the light turned green. Mexico s history stretches back into prehistoric times, and we saw the Teuchitlan ruins at Guachimontones one day. It was truly a remarkable feeling to be able to walk down the middle of the ancient ball court, or to climb up one pyramid and see the other from it. It s not exactly architecture, but Jacob and Oliver sure enjoyed visiting the hot springs at Bosque de la Primavera. Jacob still remembers that where the steam is, the water is 200 degrees, and we CAN T TOUCH IT THERE! Back in Guadalajara, here s a photo from the inside of the grand old cathedral. Compared to the cathedrals we saw in Europe, this was of a similar general size and design, and perhaps only slightly newer. But one big difference: worshipers outnumbered tourists at every Mexican cathedral I saw, whether in the center of Guadalajara or at a rainy intersection in Guanajuato or a plaza in Tlaquepaque. It made them feel more alive, and perhaps more sacred as well. One surprise was seeing people sitting on the steps of the cathedral in downtown Guadalajara selling trinkets such as beads. I think the only other place I had seen something like that was in New Orleans. All of Guadalajara s Centro was beautiful. Much of it survives from colonial days; I think a person could spend days exploring its museums and buildings. Way too many of my 900 photos were taken in Centro to post on the blog, but just for flavor, here s one of the less than historic scenes. Yes, that is a bus shaped like a tequila bottle. Fountains were beautiful and common across Mexico. A few of them were easily reachable by boys, and ours sure loved those. There was a lot of public art, including this interesting chair/skeleton/I m not sure what it is: And, just for good measure while walking around Centro, they tossed in an apparent Redundant Array of Inexpensive Typewriters. I don t know what they were doing, but there were about a dozen guys sitting out in the sun typing on their manual typewriters on their identical tables. And who can leave Guadalajara without seeing one of North America s most impressive traffic circles. I ve got to hand it to the Mexicans for making something that is normally really boring into an interesting work of art. Over in Guanajuato, a lot of driving takes place in the city s vast underground tunnel system. Here s a scene emerging from one of them. Guanajuato was already getting decorated for Mexican independence day festivities (Sept. 15-16) while we were there. Here s a typical Guanajuato street scene. Many of the streets were closed to traffic and perhaps not wide enough to handle vehicles anyway. Those streets had a wonderful peaceful and slow feel to them. I feel that I ve barely done the trip justice with this post. The feelings of walking down a beautiful Guanajuato street, or stepping into a Spanish cathedral, or even seeing a bunch of guys with typewriters, just can t be replicated. It s brimming with history and character, and shouldn t be missed.

If you're a German citizen and haven't signed the petition against a new data retention law, then sign it immediately, please. There are approximately [UPDATE]five twenty-five*[/UPDATE] hours left (after that you can still sign the petition until 2011-10-06, but it won't help in the endeavour to cause a public meeting of the petition committee). If you know somebody, who hasn't signed, get the word to them. [UPDATE]* According to netzpolitik.org the deadline for triggering a public meeting of the petition committee was moved to 2011-09-14 23:59 (CEST), which gives you another 24 hours to sign the petition in time (or get others to sign it). Please use that time![/UPDATE] [UPDATE2 (2011-09-14)]netzpolitik.org moved the entry about the deadline change to a new blog post, thus I've updated the link above. If you need instructions for the signing process, you can watch Endspurt: Petition gegen die Vorratsdatenspeicherung .[/UPDATE2 (2011-09-14)] [UPDATE3 (2011-09-14)]We did it! Keep it up![/UPDATE3 (2011-09-14)]

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.

A couple of weeks ago my old laptop decided to rest forever, and I was forced to impose some economic pressure onto the consumption of the planet resources by acquiring a new one. Fortunately this happened while I am still here in Canada, where it is reasonably cheaper to get a decent laptop than it is in Brazil. Although I did not have the budget I wanted for buying a really kick ass laptop, I was able to buy a decent one, an HP Pavilion G6 1B74CA. I went on 4 different shops with a USB stick loaded with Debian Live to check whether all the hardware would work ok. I always asked one of the salesman before rebooting the laptops, but it was funny to see the reactions of the different employees who came by to check what I was doing: some of them barely noticed that GNOME was not Windows XYZ, and and some asked whether I was hacking the laptops. Unfortunately, I wasn t able to find a single laptop in which the wireless worked out of the box with the Squeeze kernel, which sucks. I searched over the internet a lot, and it seems that even the vendors recommended by the FSF do not provide laptops with wireless cards that work without non-free blobs. Other issue I had was with the Intel graphics. After the kernel enables the modesetting, the backlight goes to the minimum and it looks like you have no video. There are a couple of workarounds in the internet, and the one in which you add acpi_osi=Linux acpi_backlight=vendor to the kernel parameters makes the laptop turn on by itself in the morning. This is probably caused by broken ACPI handling in the BIOS, who almost always is written by people on crack. The other issues I had were related to the keyboard. First, the BIOS came by default with Access keys mode enabled, which means that by default pressing F2-F12 actually activated the multimedia keys instead of the real function keys. It was disapointing to hit F12 and have my wireless turned off. After disabling this in the BIOS setup, it was OK. Well, not quite: for some reason, Fn+F4 did not generate the expected keycodes. After some research on the internet, I found a interesting Ubuntu bug . It seems that the latest and greatest version of Windows starts its video setup application via the Meta+P shortcut ( Meta is the actual name of what Windows people call the Windows key ). Guess what the morons writing the HP BIOS did yes, they made the keys Fn+F4 (where F4 has video setup as its multimedia key ) generate the keycodes for Meta+P! It would be a lot easier for everyone in the world if the people at Microsoft just make their stuff listen to both Meta+P and the video setup keycode, which is generated by every laptop out there, to activate the Windows screen setup thing. This way the very smart dudes writing BIOS at HP wouldn t need to make Fn+F4 generate the keycodes for Meta+P and break every single desktop that is not procuced at Redmond.

For the longest time, I went by the nick "Yoe" when I went on IRC. When I chose this nick for myself, I was sixteen, and the Internet computer at the local public library had an IRC client installed that I tried out. Obviously, my first choice of nick -- "wouter", a fairly common first name in Dutch-speaking regions -- was already chosen, so I had to come up with something else. If I'd realized that I'd still be using this nick today, seventeen years later, I might have chosen that nick with a bit more care... Over the years, some people have asked me what the nickname meant, where it came from. I've never really told anyone the entire story, mainly because it was somewhat embarrasing. But hey, we've all been 16, right? In the early nineties, there was a show on TV called "Het huis van wantrouwen". On this show, they had a running joke involving a short clip of Belgian members of parliament informally voting on a subject by raising hands (literally); the joke was that this clip was dubbed with a bunch of people saying "Yoe, de manne" -- which is dutch for something along the lines of "Yo, guys". As a young geeky teenager, I found this joke way more funny than it actually was; and as such, a few years later, during one of the more weird episodes of my life, I started pranking people by sneaking up to them from behind and shouting "Yoe, de manne" right next to their ears. I even managed to do this to one of our teachers who was walking on the playground. This was just around the time when I first tried out this "IRC" thing. It didn't take me too long to realize I was the only person who thought this "joke" was funny; but somehow the nick stuck, and here we are, 17 years later, I'm still using it. Or, well, I was. As of today, if you want to catch me on IRC, you'll find me going by "wouter" instead of "Yoe". Of course someone had registered that nick several years ago, but then he hadn't been using it in years, and so after a quick request to the OFTC admins they made it available for me. Whee.

A bug-fix release RQuantLib 0.3.8 is now on CRAN and in Debian. RQuantLib combines (some of) the quantitative analytics of QuantLib with the R statistical computing environment and language. Thanks to Helmut Heiming who noticed a side-effec t from the DiscountCurve functions: the Quantlib-global variable determining the evaluation date was overriden; this could affect subsequent curve-related pricers. This is now fixed, and we added a new function setEvaluationDate to set this date from R too. We added this call in some of the examples in the manual pages. Otherwise two very minor build system tweaks were added, but no other changes were made Thanks to CRANberries, there is also a diff to the previous release 0.3.7. Full changelog details, examples and more details about this package are at my RQuantLib page.

As I wrote in part 1, my family and I were in Mexico recently. Today I ll write about the places we stayed. We spent most of the time in a room we rented in a private home in Guadalajara. My friend Jonathan had found it for us, and it was not too far from his home. The owner was a grandmother, and across the courtyard was more family, including a granddaughter close in age to our boys. They enjoyed playing together. It was really a perfect arrangement for us. There s no better way to be a part of local life when traveling than to stay in someone s house. Here s our bedroom: Notice the glass slats in the window it s a nifty, though not airtight, alternative to our regular windows. More on that later. More of the inside: We had a bit of a language barrier while in Mexico, though never anything significant. My Spanish vocabulary started with almost nothing and I reached maybe a few dozen words by the time we left. Terah knew some Spanish from high school and college, and my friend was fluent. Our hostess also knew a little English. But we all communicated well enough. Terah or Jonathan would help translate when needed. As I d seen before, the children would say things to each other, but never seemed to be bothered that their playmates didn t understand what was being said. They just had a great time anyhow. On Sunday afternoon, when we came back from our activities, there was a buzz of activity. Children everywhere outside, running and playing. Adults too, chatting. We didn t know exactly what was happening, but sent Jacob and Oliver out to play anyhow (which they were eager to do). The yard was enclosed by a wall, so children could pretty much run around without lots of supervision. Eventually they were invited to have some birthday cake (ah ha!) it was one of the children s birthday. Jacob and Oliver actually were served the first two pieces of cake (as the amigos ). Everyone seemed so friendly, warm, and welcoming. Each morning started with breakfast at the house, followed by a scene like this: That s Jacob and Oliver, looking to see if Jonathan had arrived for the day yet. I often noticed in Mexico that I was unsure if I was inside or outside. Here in Kansas, we can have a string of summer days that each exceed 110F (44C) or a few weeks in winter that never get above 15F (-9C), even in daytime. And then we have some pleasant days like right now, too or rain blowing sideways at 60MPH. In general, we spend a lot of effort keeping the outside, well, out. It is quite clear that this isn t a problem in the Guadalajara area. Some restaurants could have been described as buildings with large, open windows so you feel a lot of breeze while inside. Or perhaps as a simple shade roof with a few supports on the edges, so you re never really inside at all (sort of like going under a small shade tent outdoors). To the extent that windows could close, many of them couldn t be made airtight. It was clear that in that area, people spend more energy finding ways to invite the outdoors in rather than to keep it out, thanks to the year-round moderate climate. Perhaps the best example of this surprised me one evening. We were arriving in Guanajuato, an old silver mining town in the mountains, and were going to spend the night at Hotel Socav n, which had been recommended to us by a local friend of Jonathan s. From the street, the hotel looked tiny. But walk in, and you get in this old-looking (and feeling) entry tunnel: That s the front desk, apparently cut out of it there on the right. We asked to see some of the rooms before buying apparently a normal request around there. The innkeeper agreed, and gave us keys and directions to find them on the third floor. It included going up 2 flights of stairs, passing through a courtyard, and going up another flight. It was after dark, and the hotel was dimly lit something I was fine with. I thought we were stepping out into a beautiful atrium with some potted plants in the center of the building something fairly common in some nicer hotels. Until I felt rain on my head. Then I realized that the courtyard, which began two floors up from the street, was open to the sky. Beautiful! Here was the view from out room door: And down the hall : After getting home, a Google happened to turn up some reviews of this hotel. I was so annoyed at what some people wrote! One person gave them only 3 stars because they didn t have air conditioning, had poor water pressure, and lots of steps . Someone else complained of the dark entry tunnel something I couldn t help but smiling about the moment I entered. My review, which should hopefully get posted soon, is certainly different. I gave them 5 stars, because if I wanted a Super 8 with generic fluorescent lighting and the same layout as thousands of other hotels, I would have gone to Nebraska instead of Mexico. Most homes and local hotels in the region don t have air conditioning because they don t need it, and that s just how water pressure is in Mexico (due to needing to pump it from municipal supplies to private storage tanks overhead). And who doesn t appreciate entering a hotel through a brick tunnel? Ah, sigh This should give you some idea of the kind of travel we like: part of the point of traveling is enjoying the differences from home, and I think it is a huge mistake to be annoyed at everything that is different. Enjoy the differences! Finally, here s a photo of the staircase in the home we stayed in, which I thought was fascinating:

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!

This works in debian update-alternatives --install /usr/bin/x-session-manager x-session-manager \
/usr/bin/gnome-session-fallback 100 --slave /usr/share/man/man1/x-session-manager.1.gz \
x-session-manager.1.gz /usr/share/man/man1/gnome-session.1.gz gives it a much higher priority than gnome-session so is unlikely to be bumped by any other session managers that might get installed/upgraded how to set gnome-fallback as the default session for gnome3 & gdm3 is a post from: Errata

How to set gnome-fallback as the default session for gnome3 & gdm3. The easiest way to do it in debian is to use update-alternatives to "install" a new alternative x-session-manager.

update-alternatives --install /usr/bin/x-session-manager x-session-manager \
/usr/bin/gnome-session-fallback 100 --slave /usr/share/man/man1/x-session-manager.1.gz \
x-session-manager.1.gz /usr/share/man/man1/gnome-session.1.gz

This gives gnome-session-fallback a much higher priority than gnome-session so is unlikely to be bumped by any other session managers that might get installed/upgraded Setting gnome-fallback as the default session is a post from: Errata

My family and I (including our boys) are just back from a great visit to Mexico. It was my first time there, and also the first time our boys have been outside the USA. I ll be writing about all the fun stuff in the posts to come, so you ll have to bear with me on this one as I describe why we did something that appears to horrify a segment of Americans. About a year ago, I wrote a review of Travel as a Political Act by Rick Steves. Rick s point wasn t actually directly political in the conventional sense, but summed up as:

I ve taught people how to travel. I focus mostly on the logistics: finding the right hotel, avoiding long lines But that s not why we travel. We travel to have enlightening experiences, to meet inspirational people, to be stimulated, to learn, and to grow. Travel has taught me the fun in having my cultural furniture rearranged and my ethnocentric self-assuredness walloped.

He speaks of giving onesself permission to have a conversation with someone that doesn t speak a language you know, for instance. I got an email this spring from my longtime friend Jonathan Hall, who had moved to Mexico a couple of years ago. He invited my family and me to go to Mexico, generously offered to host us and show us around, and specifically mentioned my review of Rick Steves as a reason to do so, this was immediately intriguing. Due to his other plans, it was also something of a limited-time offer. Those of you that don t live in the USA may not know what sort of stories we get about Mexico over here. Most of them involve either illegal immigration to the USA or the Mexican drug war. Occasionally there is some sort of drug-related violence on the US side of the border as well, which always makes the news. There are a lot of people that have the perception that Mexico is a dangerous place to be. Terah even knows some people that grew up in Mexico and are too afraid to return. So we did some research, asked some questions, and it became pretty clear that yes, some parts of Mexico are dangerous, but many parts are really quite safe, and Jonathan had invited us to one of those. The reactions we got from Americans when we told them of our plan ranged from excitement that we would get to visit a beautiful country to concern and worry about our safety. Besides that, I knew almost no Spanish and Terah had a few high school and college classes years ago to go on. And, we knew that Mexico would, in many ways, be more different from the USA than Germany was. We concluded that this would get us out of our comfort zone in a significant way, have lots of great things to do, be a good experience for the boys, and something that we wouldn t do without Jonathan. So we bought the tickets for it! As you might notice, I m quite glad we did. I ll follow up with the details in the next stories, but for today I ll end with the story of getting there. It involves two cute boys, so of course it ll be interesting. Jacob is almost 5 and Oliver is 2, and neither one of them had flown for over a year. Despite leaving home at 5AM to drive to the airport (about an hour away), they were both awake and alert. Jacob was jabbering away the whole way there. He enjoyed the security process and found it interesting I had to explain that they were checking to make sure everyone was following the airplane rules. Then as we walked to our gate, he pressed his face against every window, looking at the parked airplanes in the dark. Oliver would see him doing this and run over to join him. With a bit of help, he noticed some airplanes had United Express painted on them, and others had American with an AA on them. He would talk about American AA and United Express airplanes for the rest of the week whenever he heard one in the sky. I sat between the boys on our flight to Dallas, and Terah was in the row ahead of us. This is how Jacob spent most of the flight. And Oliver, who had the aisle seat, enjoyed paging through the inflight magazines, safety brochure, wifi instruction card, and airsickness bag. The real highlight came at the Dallas/Ft. Worth (DFW) airport, where we had a connection. And the reason: we needed to take a train to get to our connecting gate. The DFW Skylink system really works very well but the boys cared most that it s a TRAIN. It was difficult to get them both away from it when we got off. They wanted to see it leave, stay and watch the next one come, etc. Jacob was only happy when he realized he could see the Skylink trains running high above the window at our departure gate for Guadalajara. The 2.5-hour flight to Guadalajara got a little long for them, but they managed OK. We struck up several conversations with friendly people that knew English as we waited in various lines. It seems to be something of a rarity for American families with young children and no Mexican heritage to visit Mexico. People went out of their way to be friendly and welcoming even the customs officials. It felt like a great start to the visit. One Mexican man who was chatting with me encouraged me to learn some Spanish. I said my wife knows some, and that I had tried to learn some German back when I took foreign language classes. Laughing, he said, Why would you do that? Not as an insult; it just genuinely didn t seem useful to him. I think they were happy and proud that someone wanted to visit Mexico and was excited about it! More to come.

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.