Today, I had some business in Bonn, so Janis Voigtl nder invited me to hold a guest lecture in his advanced functional programming course, maybe telling the students more about real world use of Haskell, given that he teaches mostly the theoretical foundations. I chose to discuss an experience I made while implementing SAT-Britney, namely that for the sake of good runtime and memory performance, it may be neither ideal to evaluate a list fully lazily, nor fully strict, but to have something in between. For the talk, I demonstrated this by a small example, showed how to use the GHCi debugger to get some insight in the evaluation order of things, how to benchmark the program and read the ghc statistics and a profiling chart, and finally how to get the most out of GHC s List Fusion. I wanted to also touch on QuickCheck, but skipped it to finish in time. The full text of my talk (including graphs) is available, but in German; if you want an English version convince your prof to invite me for a guest lecture as well. Afterwards I sat down with one of the students of the course, Helmut Grohne, who happened to take part in the Debian bug squashing party last weekend and had filed a release critical bug against the Haskell grammar generator frown (no better link available, homepage seems to be down) to debug the problem. It quickly became clear that the bug was introduced by me (can you spot it?) when trying to make it compile with a modern GHC slightly embarrassing for me.

Flattr this post

Updating the bios on my X200 Tablet was surprisingly simple in Debian. Often, updating bios requires some sort of Windows or Dos boot disk and all kinds of machinations to make that happen. Lenovo provides an iso image to update the bios which alleviates some of these problems, but as the X series don't have built-in CDROM drives (and I don't have an ultrabay), All you have to do is download the iso, install syslinux aptitude install syslinux, and configure grub to start memdisk and boot off of the iso. You can do this by copying the iso to your boot partition (cp 7wuj43uc.iso /boot/;), copying memdisk to the boot partition (cp /usr/lib/syslinux/memdisk /boot/;) and adding an entry to your grub.cfg like the following (putting it in /etc/grub.d/40_custom is probably the most reasonable):

menuentry "Thinkpad x200 BIOS Upgrade to 3.19"  
       insmod part_msdos
       insmod ext2
       set root='(hd0,msdos1)'
       linux16 /memdisk iso
       initrd16 /7wuj43uc.iso
 

Note that your configuration will be slightly different depending on whether you have a separate /boot partition (I do) or not. Then you just need to boot the laptop, select the bios upgrade option in grub, and tell the program that you really do want to upgrade the bios and that you really do have a full battery and the laptop plugged into an AC adapter. The major idea for this method came from ThinkWiki's entry.

Updating the bios on my X200 Tablet was surprisingly simple in Debian. Often, updating bios requires some sort of Windows or Dos boot disk and all kinds of machinations to make that happen. Lenovo provides an iso image to update the bios which alleviates some of these problems, but as the X series don't have built-in CDROM drives (and I don't have an ultrabay), All you have to do is download the iso, install syslinux aptitude install syslinux, and configure grub to start memdisk and boot off of the iso. You can do this by copying the iso to your boot partition (cp 7wuj43uc.iso /boot/;), copying memdisk to the boot partition (cp /usr/lib/syslinux/memdisk /boot/;) and adding an entry to your grub.cfg like the following (putting it in /etc/grub.d/40_custom is probably the most reasonable):

menuentry "Thinkpad x200 BIOS Upgrade to 3.19"  
       insmod part_msdos
       insmod ext2
       set root='(hd0,msdos1)'
       linux16 /memdisk iso
       initrd16 /7wuj43uc.iso
 

Note that your configuration will be slightly different depending on whether you have a separate /boot partition (I do) or not. Then you just need to boot the laptop, select the bios upgrade option in grub, and tell the program that you really do want to upgrade the bios and that you really do have a full battery and the laptop plugged into an AC adapter. The major idea for this method came from ThinkWiki's entry.

Persian, Italian and Russian back to 100%. Progress for Serbian. Full stats are here Status for D-I level 1 (core D-I files):

• 17 languages 100%: bg de eo fa fr gu hi it ja nb nl pl pt ru sk th zh_CN
• 8 languages 99%: bs cs es fa ko mr si ta te
• 2 languages 98%: eu sv
• 1 language 96%: eu sr sv
• 7 languages 95%: be bn dz he kk tr uk
• 4 languages 94%: ar ast ga ro
• 4 languages 93%: el hu km lo
• 2 languages 92%: id sl
• 4 languages 91%: et pa vi zh_TW
• others are 90% or below

Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.):

• 9 languages 100%: de es fa fr pt ru si sk zh_CN
• 13 languages 99%: be cs da eo id it ja kk nl sl sv th uk
• 5 languages 98%: bg ca eu pt_BR ro
• 1 language 96%: nb
• 3 langauges 95%: el fi he
• 7 languages 94%: ar ast dz gl hr vi zh_TW
• 1 language 93%: is
• 8 languages 92%: bn bs hu ko ne pl sr tr
• 9 languages 91%: ga gu ka km lt mk mr ta te
• others are 90% or below

Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

• 10 languages 100%: cs de fa fr nb nl pt ru sk sv
• 16 languages 99%: be bg bs ca el eo es fi ga gl he is ja th tr zh_CN
• 2 languages 97%: hu uk
• others are 90% or below

So, full 100% completeness (hall of fame) for: German, Persian French, Portuguese, Russian, Slovak

I recently put together a reading list on Project Moonshot for a friend. If you have seen discussions of Moonshot but not known where to get started understanding the technology, here is a fairly good initial list. It s long, but take a look starting at the beginning and let us know what you think.Take a look at http://www.project-moonshot.org/. Specifically, http://www.project-moonshot.org/sites/default/files/moonshot-feasibility-analysis.pdf and http://www.project-moonshot.org/sites/default/files/moonshot-briefing-ietf-78.pdf That briefing paper contains outdated versions of the technical
specifications.
Please see http://tools.ietf.org/html/draft-ietf-abfab-arch-00 http://tools.ietf.org/html/draft-ietf-abfab-gss-eap and http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming
and http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml O, yeah, and for the totally cool stuff that is still being designed
please see http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed and http://tools.ietf.org/html/draft-mrw-abfab-trust-router

Procps-ng, the debian, Fedora and OpenSuSE fork of procps had another release today. This is a bugfix release that fixes some important bugs that have cropped up in 3.3.0 pgrep crashes, pgrep -u not finding processes and a problem with top forest view have all been fixed. An important addition to this release is that test scripts have now been added using the Dejagnu framework. This framework tests most of the programs that ship with procps-ng. There is only 100 tests so far and they are only tested for Linux architecture, but we expect to increase this test count and sophistication with each release. The test scripts even found long-present but unknown bugs in the package. For example, running ps with output flags around the signal masks work as expected in Linux, but fail on kFreeBSD. This is due to the unusual output of the relevant lines on that architecture. This is not a new bug, bug has been around for quite some time; noone ever noticed (or reported) it. The Debian package has already been built and uploaded to the master FTP server. Oh, and it is the first package with my new GPG key!

It s been busy lately, and I haven t had the time to blog. With the change in job, various travel, and settling into a new routine, I ve not done as much writing of late. But life marches on, and before memories grow too fleeting, I think I should share a few. We recently changed the arrangements for the boys. Instead of them each having their own room in which they sleep and sometimes play, we purchased a bunk bed. Oliver graduated from his crib to the lower bunk, and Jacob has the higher bunk. This has, predictably, created a few opportunities for behavior issues. Overall, it s going well, and they appreciate their new, more open, play room. Both boys sleep with their stuffed animals. Jacob calls his my friends . He still likes his butterfly, which he has had since he was an infant. He sometimes talks about how much he loves his friends, and how they like to get hugs, and how they are happy. Jacob continues to enjoy reading. He has a toy low-res camera and he even recorded a video of himself reading Brown Bear, Brown Bear. Oliver s vocabulary is coming alive and is fun to watch. Jacob has taken to trying to teach Oliver how to say things. One day, Jacob saw a number like 451 on the side of a train, producing a conversation like this: Oliver, can you say four hundred and fifty-one? Four dred iffy on! You got it!!! YAY! Today as I was walking past Oliver s train track on the floor, he grabbed me by the hand, had me sit down, and kept holding on to make sure I d stay right where he wanted me as he pointed and talked all about his trains. Aww. One cold and windy Saturday morning, the boys were getting restless. What to do, we thought? I decided to bring out one of the manual typewriters from my collection. Oliver loved watching it do things as he pressed buttons. Jacob enjoyed spelling mom . New problem: boys fighting over how long each one s turn at the typewriter is. This has gone on for a month now. Ahh, winter. A few weeks ago, Jacob informed us that he built an antenna out of blocks. He was REALLY proud of it, and even, incredibly, insisted I take his picture with it! I m pleased to have a 5-year-old that calls this structure an antenna instead of a skyscraper or tower or some such thing ;-) We took a train trip to Portland, OR, recently. That s about 2.5 days on the train each way. It went pretty well we had quite a bit of excitement though it got a little long for the boys at times. One evening, Jacob excitedly noted that the sky was almost really dark blue, just like my song! Wow. That was a song he made up in New York in summer 2010. Jacob enjoyed collecting leaves as we walked around in Portland. He would then stash his pile of leaves outside the door of whatever building we d enter, then hope to find them still there when we got back out. It usually worked out OK for him.

Conrad Sanderson made the official 2.4.0 release of Armadillo last evening. This was wrapped into RcppArmadillo release 0.2.32 which arrived on CRAN earlier today. The NEWS entries summarising the changes since the 2.2.* series, we already saw most of this with the two prerelease 0.2.30 and 0.2.31:

0.2.32  2011-12-04
    o   Upgraded to Armadillo test release 2.4.0 "Loco Lounge Lizard"
    o   Minimal changes relative to 0.2.31 based on 2.3.92, next section is
        relative to the previous stable release series 2.2.* of Armadillo
          * added shorter forms of transposes: .t() and .st()
          * added optional use of 64 bit indices, allowing matrices to have
            more than 4 billion elements 
          * added experimental support for C++11 initialiser lists
          * faster pinv()
          * faster inplace transpose
          * faster handling of expressions with diagonal views
          * fixes for handling expressions with aliasing and submatrices
          * fixes for linking on Ubuntu and Debian systems
          * fixes for inconsistencies in interactions between matrices and
            cubes 
          * refactored code to eliminate warnings when using the Clang C++
            compiler 
          * .print_trans() and .raw_print_trans() are deprecated

Courtesy of CRANberries, there is also a diffstat reports for 0.2.32 relative to 0.2.31 As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This weekend, we held a combined Debian Bug Squashing Party and Ubuntu Local Jam in Portland, OR. A big thank you to PuppetLabs for hosting! Thanks to a brilliant insight from Kees Cook, we were able to give everyone access to their own pre-configured build environment as soon as they walked in the door by deploying schroot/sbuild instances in "the cloud" (in this case, Amazon EC2). Small blips with the mirrors notwithstanding, this worked out pretty well, and let people start to get their hands dirty as soon as they walked in the door instead of spending a lot of time up front doing the boring work of setting up a build environment. This was a big win for people who had never done a package build before, and I highly recommend it for future BSPs. You can read about the build environment setup in the Debian wiki, and details on setting up your own BSP cloud in Kees's blog. (And the cloud instances were running Ubuntu 11.10 guests, with Debian unstable chroots - a perfect pairing for our joint Debian/Ubuntu event!) So how did this curious foray into a combined Ubuntu/Debian event go? Not too shabby:

• Roughly 25 people participated in the event - a pretty good turnout considering the short notice we gave. Thanks to everyone who turned up!
• Multiarch patches were submitted for 14 library packages by 9 distinct contributors
• Four of these people submitted their first patch to Debian!
• Three more contributors worked on patches that were not submitted to Debian by the end of the event, but we will stalk them and see to it that their patches make it in ;)
• 8 Ubuntu Stable Release Updates were looked at for verification of fixes
• 7 of these fixes were successfully verified (one bug was not reproducible)
• 6 of those packages have already been moved to the -updates pocket, where all of Ubuntu's users can now benefit from them

When all was said and done, we didn't get a chance to tackle any wheezy release critical bugs like we'd hoped. That's ok, that leaves us something to do for our next event, which will be bigger and even better than this one. Maybe even big enough to rival one of those crazy, all-weekend BSPs that they have in Germany...

On Sunday, I brought up EC2 instances to support the combined Debian Bug Squashing Party/Ubuntu Local Jam that took place at PuppetLabs in Portland, OR, USA. The intent was to provide each participant with their own sbuild environment on a 64bit machine, since we were going to be working on Multi-Arch support, and having both 64bit and 32bit chroots would be helpful. The host was an Ubuntu 11.10 (Oneiric) instance so it would be possible to do SRU verifications in the cloud too. I was curious about the juju provisioning system, since it has an interesting plugin system, called charms , that can be used to build out services. I decided to write an sbuild charm, which was pretty straight forward and quite powerful (using this charm it would be possible to trigger the creation of new schroots across all instances at any time, etc). The juju service itself works really well when it works correctly. When something goes wrong, unfortunately, it becomes nearly impossible to debug or fix. Repeatedly while working on charm development, the provisioning system would lose its mind, and I d have to destroy the entire environment and re-bootstrap to get things running again. I had hoped this wouldn t be the case while I was using it during production on Sunday, but the provisioner broke spectacularly on Sunday too. Due to the fragility of the juju agents, it wasn t possible to restart the provisioner it lost its mind, the other agent s couldn t talk to it any more, etc. I would expect the master services on a cloud instance manager to be extremely robust since having it die would mean totally losing control of all your instances. On Sunday morning, I started 8 instances. 6 came up perfectly and were excellent work-horses all day at the BSP. 2 never came up. The EC2 instances started, but the service provisioner never noticed them. Adding new units didn t work (instances would start, but no services would notice them), and when I tried to remove the seemingly broken machines, the instance provisioner completely went crazy and started dumping Python traces into the logs (which seems to be related to this bug, though some kind of race condition seems to have confused it much earlier than this total failure), and that was it. We used the instances we had, and I spent 3 hours trying to fix the provisioner, eventually giving up on it. I was very pleased with EC2 and Ubuntu Server itself on the instances. The schroots worked, sbuild worked (though I identified some additional things that the charm should likely do for setup). I think juju has a lot of potential, but I m surprised at how fragile it is. It didn t help that Amazon had rebooted the entire West Coast the day before and there were dead Ubuntu Archive Mirrors in the DNS rotation. For anyone else wanting to spin up builders in the cloud using juju, I have a run-down of what this looks like from the admin s perspective, and even include a little script to produce little slips of paper to hand out to attendees with an instance s hostname, ssh keys, and builder SSH password. Seemed to work pretty well overall; I just wish I could have spun up a few more. :) So, even with the fighting with juju and a few extra instances that came up and I had to shut down again without actually using them, the total cost to run the instances for the whole BSP was about US$40, and including the charm development time, about US$45. UPDATE: some more details on how to avoid the glitches I hit.

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

It took quite a lot of effort to persuade all decision makers to make this happen, but here it is: A new Debian buildd is being hosted at Karlsruhe Institute of Technology, to support the s390(x) ports. Its name is zemlinsky. So we've got some redundancy now and despite them being some sort of fringe architectures, they're looking pretty good. s390x is currently bootstrapped in the archive and it's progressing pretty quick. This new fast builder is one of the reasons why the slope is so steep.

Pointing people at the Debian Machine Usage Policies (DMUP) is pretty helpful to get a consent, with relation to network usage and acceptable use of the machines themselves. In this case the hardest part was drafting a user agreement that allows other non-university persons to log into the box, which is crucial to have it maintained by the Debian System Administrators.

Thanks to all the people at IPD Reussner, Steinbuch Centre for Computing and BelW who helped me getting this done.

Mika and I will be traveling this winter in the Seattle area and in Japan. The current plan is to be in Seattle December 19 through 28 and then in Japan from December 28 through January 12. After that, we will fly back to Boston for the MIT Mystery Hunt where, as punishment for winning last year, our team is running this year's hunt. We will be in Tokyo for New Years and then traveling around Japan for much of the rest of the time. We hope to visit Hokkaido and Aomori and to travel there from Tokyo along Japan's Western coast through Kanazawa and Niigata. We're still figuring out where we will visit and what we will do in both places. If you are interested in meeting up for dinner or drinks in either place (or in organizing a talk or meeting), please get in touch and let's try to figure something out.

Handy command line arguments for gpg:

gpg --list-options show-photos --fingerprint 0xdc6dc026

This is nice to examine someone s PGP photo. You can also include it in --verify-options, depending on how/when you want to see the photo (for example, when doing key signings). If gpg doesn t pick the right photo viewer, you can override it with --photo-viewer 'eog %I' or similar.

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

On Saturday evening I started talking with M nica about Bug Squashing Parties and how they work. I am not sure how it happened, we started doing one. Then it was too fun to stop :P NMUs by M nica:

• t1lib #646470 This one had a patch by Colin Watson and Lo c Minier
• torcs: #646469 and 636009
• slsqlite: #646487
• webdruid: #646499
• vilistextum: #646501

Funny, there were a couple of NMUs by others uploading patchs by M nica. NMUs by Ana:

• uw-imap: #646481 This one had a patch by Aur lien Jarno.
• remind: #643466
• sipcalc: #646502
• libcsoap: #643420
• tuxpaint: #556509 With patch by Georgios M. Zarkadas.

I also closed #646449 (libosip2) that has been fixed in a new release upload, sponsored a NMU to Sven Joachim who had a patch sitting in the BTS for a month NMU-fixing #646147 (lie), sponsored dbus-c++ and reviewed for sponsoring a new version inspircd.

At work we use .procmailrc files generated by CGIpaf to let non-technical users create forwards, out-of-office mails, etc. and any combination thereof. This also has the advantage that we can filter out double bounces and spam (which also prevents us from being listed in spammer blacklists). Unfortunately autofs (seems independent if autofs4 or autofs5 is used) seems to be unreliable if there are bursts of mount or umount requests, resulting either in File or directory not found error message while trying to access the home directory of a user, or Directory not empty error messages if the automounter tries to remove the mount point after unmounting. In that case a not mounted directory owned by root is left over. In the end both cases lead to procmail behaving as if that user does not have a .procmailrc which looks like sporadically lost mails to those who forward all mails. (The mails then can be found in the local default INBOX for that user.) Additionally there are similar issues when the NFS servers are not available. The most effective countermeasure we found so far was adding tests to the global /etc/procmailrc to check if the user s home directory exists and belongs to the correct user:

# -----------------
# Global procmailrc
# -----------------
# For debugging, turn off if everything works well
VERBOSE=1
LOGFILE=/var/log/procmail.log
# This only works with bourne shells, $SHELL defaults to the user's
# login shell. And by experience dash seems not work, so we use bash.
OLDSHELL=$SHELL
SHELL=/bin/bash
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $LOGNAME is not set for some reason. (Just to be sure our paths
# later on are not senseless.
:0
* ? test -z "$LOGNAME"
 
    LOG="Expected variable LOGNAME not set. "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME is not readable. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -r /home/$LOGNAME
 
    LOG="Home of user $LOGNAME not readable: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME has wrong owner. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -O /home/$LOGNAME
 
    LOG="Home of user $LOGNAME has wrong owner: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
[ ]

If you want to store a copy of these mails for debugging purposes on every delivery attempt, replace /dev/null with some Maildir or mbox only accessible for root. One small but important part was to explicitly declare bash as shell for executing the tests, otherwise mails for users with tcsh or zsh as login shell filled up the mail queue and never get delivered (if the SHELL variable never gets fixed). Only drawback so far: This leads to more lagging e-mail on e-mail bursts also for those users who have no .procmailrc because procmail can t check if there s really no .procmailrc. Extensive procmail documentation can be found online at the Procmail Documentation Project as well as in the man pages procmail(1), procmailrc(5) and procmailex(5).

Alexander has already announced the final results of this weekend's BSP, but I'd like to add my personal thanks. So, kudos to all attendees, for helping to make the BSP such a success and also to my employer for the generous budget and my colleagues, especially Wolfram to whose initiative we owe this BSP, for helping out before, during and after the party. All in all it's been an event well worth repeating!

Uff. Two and a half days of hunting release critical bugs ended yesterday evening. It think it was quite a success. According to the statistics we closed 23 bugs with direct uploads, we created patches for 11, 9 bugs got solved by package removals, 6 will be closed by uploads via the delayed queue, 2 bugs were closed as unreproducible, and 9 other bugs where closed as well (e.g. already fixed in older version). On the other hand we opened 3 and upgraded 6 bugs to be release critical. So in the end, we solved about... 60 bugs! Wow, I'm really impressed! I'm also really pleased how well we integrated the newbs. As I already mentioned, when planing for this BSP started, we were a bit worried about the DD / non-dd ratio, but in the end everything worked out very well. All of those, who registered as interested users where able to fix some rc bugs, or help sort out some BTS hickups, e.g. bugs opened with package a but closed in package b. And as a special pleasure it seems, that the longest outstanding rc bug might be fixed soonish, too :) I'd also like to thank Pengutronix for hosting and sponsoring the BSP! The infrastructure worked very well: You arrived, plugged in your notebook, had a local mirror, IPv6 and fast enough connection to the outside. They also provided lots of snacks, cooked food and drinks (later they complained Debian people won't drink enough; apparently they calculated with way more drinks) and a general good atmosphere. PS: To the best of my knowledge, it was also the greenest bug squashing party ever, with most foods and all the electricity coming from certified ecological production. Cool, eh?

Thanks to some advice from Philipp Kern I have now got my Galaxy S running CyanogenMod 7.1.0 which is based on Android 2.3.7 [1]. CyanogenMod has lots of configuration options that seem to be lacking in the stock releases and also supports some advanced features such as OpenVPN and a command-line. I can t properly compare CyanogenMod to the stock Android as I ve only used versions 2.1 and 2.2 of the stock Android. Presumably some of the things that I like about CyanogenMod are in the stock Android 2.3.7 release. The process of updating a phone is difficult and has some risk. Fortunately Samsung provided Download mode in the BIOS to allow recovery. If you mess up the process of updating a Galaxy S and you can get Download mode by holding down volume-down, home, and then power buttons then you can almost certainly recover (so don t panic). The CyanogenMod people don t provide any documentation on upgrading from Android 2.2 (which is what Optus is still shipping AFAIK). So you will probably have some difficulty when upgrading a Galaxy S that you get in Australia (it seems that Optus is the only company shipping them in volume). As an aside if you want to buy a Gel Case for a Galaxy S in Australia then visit an Optus store. It seems that Optus is the only phone store that hasn t run out their Galaxy S accessories in favor of the Galaxy S2. I have previously written about the Galaxy S and Three Networking [2]. Now that I have the Galaxy S as my primary phone on the Virgin network all my data corruption problems are solved, the problem is entirely related to Three. With CyanogenMod there is an option to be able to toggle the LED Flash as a torch from the drop-down menu, this makes the lack of such a LED on the Galaxy S even more of an annoyance. I have also discovered that the Galaxy S apparently doesn t have a status LED! This makes it the only phone that I ve ever owned that has no clear way of informing me when the battery is charged! It s also really useful to have a flashing LED to indicate low battery when running a full screen app, and to have a flashing LED to indicate that email has been received. Someone should design a phone with multiple LEDs to indicate different things. I d like to have one LED to indicate charging status and another to indicate whether there is unread email or SMS. Whatever the cost of including a LED during manufacture it would have to be almost nothing compared to the ~$500 sale price of a phone. Wikipedia says The Samsung Galaxy S features a PowerVR graphics processor, yielding 20 million triangles per second, making it the fastest graphics processing unit in any smartphone at the time of release. Also, upon release, the Galaxy S was both the first Android phone to be certified for DivX HD, and at 9.9 mm was the thinnest smartphone available . I don t care about any of that, I want a phone with decent battery life, a LED Flash , and a status LED. The main benefit I get from the Galaxy S over the Xperia X10 is the greater storage. The Xperia X10 has a total of 1G of storage and only 465M of that is available for application install. My Galaxy S has 16G of internal storage of which 1.8G is available for phone apps and 13G is available for pictures and other mass storage. Having 1.8G for phone apps and internal phone storage used by such apps (which includes the offline IMAP cache) is a massive benefit, enough to outweigh the lack of a staus LED and a Flash LED. What I Really Want I d rather have a Samsung Galaxy Note. The Note has a LED flash, a 5.3 screen with 1280*800 resolution which is much better for running as a SSH client and also good for web browsing. I m not inclined to spend money on a phone now, so I ll probably use the Galaxy S until Virgin offers me a new phone or someone just gives me a new phone (I can always hope). One of the many nice features in the Galaxy Note is a built in stylus. When using my current phones for web browsing I sometimes find it difficult to have a touch registered to the desired part of the screen, this is a real problem with the Opera web browser which requires a long press to open a URL in a new tab.

• [1] http://www.cyanogenmod.com/
• [2] http://etbe.coker.com.au/2011/11/21/galaxy-xperia-android-network/

here's my report about RC bug related activities for the last week. besides working on the bugs mentioned below I've also documented my RCBW work flow for the NMUs, just in case it's interesting for others.

• #615705 dasher: "dasher: ftbfs with gold or ld --no-add-needed"
  add patch from M nica Ram rez Arceda, upload to DELAYED/2
• #628590 siggen: "please make siggen depends on oss-compat"
  add missing dependency, do a QA upload
• #633453 drac: "drac: fails to install due to incorrect dependencies in init.d LSB header"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #634451 src:hwinfo: "hwinfo: FTBFS: /usr/include/dbus-1.0/dbus/dbus.h:29:33: fatal error: dbus/dbus-arch-deps.h: No such file or directory"
  add patch from Simon McVittie, upload to DELAYED/2
• #638379 xine-ui: "xine-ui: fatal error: curl/types.h: No such file or directory"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #639772 src:slrn: "slrn: FTBFS: checking for the slang library and header files ... no"
  point configure to multiarched slang, upload to DELAYED/2
• #639991 guile-1.8-non-dfsg: "guile-1.8-non-dfsg fails to build from source in unstable"
  add patch from Ubuntu / Matthias Klose, upload to DELAYED/2
• #640439 src:gtk-nodoka-engine: "gtk-nodoka-engine: FTBFS: nodoka_style.c:1279: undefined reference to sqrt'"
  add patch from Ubuntu / Micah Gersten, upload to DELAYED/2
• #640883 libnet-ldap-perl: "regression: breaks $ldap->start_tls()"
  add patch from Peter Marschall, taken from upstream's "next" branch (pkg-perl)
• #643339 src:most: "most: build fails on configure-step (couldn't find slang.h)"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #643371 src:dasher: "dasher: FTBFS: game_mode_helper.cpp:327:15: error: format not a string literal and no format arguments [-Werror=format-security]"
  add patch from Eric Alexander, upload the DELAYED/2
• #649066 libmason-perl: "libmason-perl and mason: error when trying to install together"
  upload new upstream release, package prepared by Florian Schlichting (pkg-perl)

Right, so I am at the BSP in Hildesheim. Arrived somewhere Friday, leave in a few hours, and in the meantime I managed to break all our 3 archives at least once. Yay. But heck, I also managed to get them back to work (with help from the FTPTeam too), so it was a good thing. We are back on one code revision for security, backports and main archive. Security also changed to the newer style of handling the buildd repositories and is now also using daks own method of writing packages files instead of using apt-ftparchive. And while I was at it I also created 3 new sections, got a SHA256SUMS file in addition to the MD5SUMS for the debian-installer images (thanks Joeyh for the quick reaction), enabled DM uploads for backports and implemented various other smaller fixes and cleanups.