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.

There's more funny business when using ccache in combination with clang. Last time I suggested that you use the invocation

./configure CC='ccache clang -Qunused-arguments -fcolor-diagnostics'

to get rid of the "argument unused during compilation" warnings.But you still might get loads of warnings that you wouldn't normally get without ccache, such as this example (from the PostgreSQL source code):

extension.c:382:35: warning: equality comparison with extraneous parentheses [-Wparentheses]
 if (( (((control->directory)[0]) == '/') ))
        ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
extension.c:382:35: note: use '=' to turn this equality comparison into an assignment

(This is the opposite of the warning that tells you to put two pairs of parentheses around an assignment used as a truth value.)Or:

path.c:727:7: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign]
 path = (path);
 ~~~~ ^  ~~~~

The problem is, these come from macro expansions, so wouldn't normally see them, because (I guess) the compiler driver is smart enough not to warn about such things when they come from macro expansions.The way ccache works is approximately

1. preprocess the input file
2. look for it in the cache
3. if not found, compile the preprocessed file

What would be better in this situation is

1. preprocess the input file
2. look for it in the cache
3. if not found, compile the original file

And indeed you can turn on that second behavior by setting the obscure environment variable CCACHE_CPP2 (as in, run cpp twice):

export CCACHE_CPP2=yes

Then all these extra warnings disappear.(The ccache man page is worth a read. There are a few interesting settings to play with.)I'm currently playing around with a shell script ccache-clang that looks like this:

CCACHE_CPP2=yes exec ccache clang -Qunused-arguments  test -t 2 && echo -fcolor-diagnostics  "$@"

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.

In this screencast, I implement a new feature in git-annex. I spend around 10 minutes writing haskell code, 10 minutes staring at type errors, and 10 minutes writing documentation. A normal coding session for me. I give a play-by-play, and some thoughts of what programming is like for me these days. <video controls="controls" src="http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg"></video> git-annex coding in haskell.ogg (38 MB) on vimeo Not shown is the hour I spent the next day changing the "optimize" subcommand implemented here into "--auto" options that can be passed to git-annex's get and drop commands.

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!

I am haunted by the nagging fear that I have mailboxes, tucked into a dark corner of an office somewhere, and perhaps even full of checks and important documents, that I don't know exist.

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.

Our MirBSD online manual pages and other assorted BSD documentation (except of course the merely copied ncurses, lynx etc. documentation and the texinfo generated HTML pages) has just gained a major facelift. They look alike in lynx(1) best web browser ever and less(1)/man(1) now, and remind of a DEC VT420 on a CSS capable Buntbrause. Thanks to our contributor XTaran for aid with the colour scheme! Since these are generated from catmanpages, heuristics are used for things like where should bold/underline begin/end (since nroff(1) is not always the brightest but working on that), and hyperlinks can only be generated for other manpage references (whose targets may or may not exist, for example if they aren t part of MirOS base/XFree86 ). But on the other hand, Valid XHTML/1.1 and CSS speaks for itself

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 .

...and not in this other world where you have to deal with a bug reported against apt because installing libreoffice in the distro development branch is not possible:

sudo apt-get install libreoffice
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 libreoffice : Depends: libreoffice-core (= 1:3.4.3-1ubuntu2) but it is not going to be installed
               Depends: libreoffice-writer but it is not going to be installed
               Depends: libreoffice-calc but it is not going to be installed
               Depends: libreoffice-impress but it is not going to be installed
               Depends: libreoffice-draw but it is not going to be installed
               Depends: libreoffice-math but it is not going to be installed
               Depends: libreoffice-base but it is not going to be installed
               Depends: libreoffice-report-builder-bin but it is not
 going to be installed
               Depends: libreoffice-filter-mobiledev but it is not going to be installed
               Depends: libreoffice-java-common (>= 1:3.4.3~) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

And I therefore really admire those folks who are brave enough to triage out bugs reported in Launchpad (current counter: about #850000...in only SEVEN years). Yeah, I know, whining about clueless users is BAD, we should be friendly and gentle and kind and polite and nice and happy, but COME ON DUDE, could you at least think ONE BLOODY SECOND? End of rant.

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.

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

I must admit that I m a bit lost about the conclusions of the Don t fear the fsync()! (lf.org down; google cache) debate. My understanding was that using fsync() was the right thing to do when we cared about data being written to disk. When using cp or tar, I usually care about my data being written to the disk, so why don t they use fsync()? Shouldn t they?

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..:-)

Continuing my series of articles on dpkg s errors, this time I ll cover a pretty common one which has several variations:

Setting up acpid (1:2.0.12-1) ...
rm: cannot remove  /etc/rc1.d/K20acpid': No such file or directory
dpkg: error processing acpid (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 acpid

Even if dpkg is failing and outputting the error message, the real problem is not in dpkg but in the installed package (acpid in the example above). As we already learned, a package contains not only files but also maintainer scripts that are executed at various points of the installation process (see some useful graphics to understand how they are called, thanks to Margarita Manterola). In the introductory example it was acpid s post-installation script that failed, and dpkg is only forwarding that failure back to the caller. The maintainer scripts are stored in /var/lib/dpkg/info/. You can thus inspect them and even modify them if you hit a bug and want to work around it (do this only if you understand what you do!). One common modification is to add set -x at the start of the script and to retry the failing operation. That way you can see what s executed exactly. Here s what the output could look like after the addition of set -x to /var/lib/dpkg/info/acpid.postinst:

$ sudo dpkg --configure acpid
Setting up acpid (1:2.0.12-1) ...
+ dpkg --compare-versions 1:2.0.11-1 lt-nl 1.0.10-3
+ dpkg --compare-versions 1:2.0.11-1 lt-nl 1.0.6-16
+ dpkg --compare-versions 1:2.0.11-1 lt 1.0.6-6
+ rm /etc/rc1.d/K20acpid
rm: cannot remove  /etc/rc1.d/K20acpid': No such file or directory
dpkg: error processing acpid (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 acpid

This output helps you locate the command that is actually failing. Here s it s relatively easy since we have an error message from rm . And the fix is trivial too, we replace rm with rm -f so that it doesn t fail when the file doesn t exist (this is a fake bug I made up for this article I just added a failing rm call but it s inspired by real bugs I experienced). Maintainer scripts are supposed to be idempotent: we should be able to execute them several times in a row without bad consequences. It happens from time to time that the maintainer gets this wrong on the first try it works, so he uploads his package and we discover the problem only later once someone ended up executing the same code twice for some reason.

Follow me on Identi.ca, Twitter, Facebook and Google+. Or subscribe to this blog by RSS or by email.

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

Guus wrote another scientific OpenGL tutorial, storing ordinates as a one-dimensional texture for increased performances.

http://en.wikibooks.org/wiki/OpenGL_Programming/Scientific_OpenGL_Tutorial_02

I also went ahead and added a tutorial on two-sided lighting:

http://en.wikibooks.org/wiki/GLSL_Programming/GLUT/Two-Sided_Surfaces

Remember: this is free documentation that you can share and/or improve upon - make sure you do so