This has been a minor annoyance for the last few months, and I've finally figured out how to fix it: Sometime within the last few months, an upgrade prevented Chromium from finding its application icon with the result that when minimised (or displayed in the panel window list or Alt-Tab) it used the default application icon. It looks to me as if the problem is that Chromium is now looking for chromium-browser.svg but chromium.svg is what's on my debian system. To restore, all you need to do is:

$ mkdir -p ~/.local/share/icons/hicolor/scalable/apps
$ cd ~/.local/share/icons/hicolor/scalable/apps
$ ln -s /usr/share/icons/hicolor/scalable/apps/chromium.svg chromium-browser.svg

great, done. Now my chromium windows don't look the same as my mrxvt windows in Alt-Tab, they're quite clearly Chromium windows. The icon now looks like this: rather than an icon i'd insert here if i knew what its filename is it looks like a white window with a blue title bar and a thinner blue bar at the bottom (about half the height/thickness of the "title bar") I've spent half an hour searching for it and have given up anyone know what it is? alternatively, use cp rather than ln just in case some future upgrade removes or renames the chromium.svg file How to set the application icon for chromium is a post from: Errata

Thanks to Zach and the Seattle R User Group for the invitation. Earlier this evening I gave a talk about R, C++ and our Rcpp package, focussing on the why, how, what, who, and "one more thing" higher-level aspects of extending R. This was supposed to be an hour long, and with the examples at the end went a little over, butat least nobody started to snore. The slides are now up at the top of my presentations page.

Long time has passed since last entry in this blog. Moderation panel is full of spam comments. It s still unclear if I will ever will continue it. However, given what is happening in my country these days, I *must* write at least one entry, just to put a number there. 632305222316434 Everyone who disagrees with criminal behaviour of Russian president, government and all those rascals, must do that.

Conrad Sanderson made a first 2.4.1 bug fix release of Armadillo. We now have RcppArmadillo release 0.2.33 on CRAN which contains it. earlier today. The NEWS entry below summarises the changes.

0.2.33  2011-12-07
    o   Upgraded to Armadillo release 2.4.1
          * added .resize()
          * fix for vector initialisation

Courtesy of CRANberries, there is also a diffstat reports for 0.2.33 relative to 0.2.32 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.

It s been a couple days since I returned from this year s WebKitGTK+ hackfest in A Coru a, Spain. The weather was very nice, not too cold and not too rainy, we had great food, great drinks and I got to meet new people, and hang out with old friends, which is always great! I think this was a very productive hackfest, and as usual a very well organized one! Thanks to the GNOME Foundation for the travel sponsorship, to our friends at Igalia for doing an awesome job at making it happen, and to Collabora for sponsoring it and granting me the time to go there! We got a lot done, and although, as usual, our goals list had many items not crossed, we did cross a few very important ones. I took part in discussions about the new WebKit2 APIs, got to know the new design for GNOME s Web application, which looks great, discussed about Accelerated Compositing along with Joone, Alex, Nayan and Martin Robinson, hacked libsoup a bit to port the multipart/x-mixed-replace patch I wrote to the awesome gio-based infrastructure Dan Winship is building, and some random misc. The biggest chunk of time, though, ended up being devoted to a very uninteresting (to outsiders, at least), but very important task: making it possible to more easily reproduce our test results. TL;DR? We made our bots and development builds use jhbuild to automatically install dependencies; if you re using tarballs, don t worry, your usual autogen/configure/make/make install have not been touched. Now to the more verbose version! The need For a couple years now we have supported an increasingly complex and very demanding automated testing infrastructure. We have three buildbot slaves, one provided by Collabora (which I maintain), and two provided by Igalia (maintained by their WebKitGTK+ folks). Those bots build as many check ins as possible with 3 different configurations: 32 bits release, 64 bits release, and 64 bits debug. In addition to those, we have another bot called the EWS, or Early Warning System. There are two of those at this moment: one VM provided by Collabora and my desktop, provided by myself. These bots build every patch uploaded to the bugzilla, and report build failures or passes (you can see the green bubbles). They are very important to our development process because if the patch causes a build failure for our port people can often know that before landing, and try fixes by uploading them to bugzilla instead of doing additional commits. And people are usually very receptive to waiting for EWS output and acting on it, except when they take way too long. You can have an idea of what the life of an EWS bot looks like by looking at the recent status for the WebKitGTK+ bots. Maintaining all of those bots is at times a rather daunting task. The tests require a very specific set of packages, fonts, themes and icons to always report the same size for objects in a render. Upgrades, for instance, had to be synchronized, and usually involve generating new baselines for a large number of tests. You can see in these instructions, for instance, how strict the environment requirements are yes, we need specific versions of fonts, because they often cause layouts to change in size! At one point we had tests fail after a compiler upgrade, which made rounding act a bit different! So stability was a very important aspect of maintaining these bots. All of them have the same version of Debian, and most of the packages are pinned to the same version. On the other hand, and in direct contradition to the stability requirement, we often require bleeding edge versions of some libraries we rely on, such as libsoup. Since we started pushing WebKitGTK+ to be libsoup-only, its own progress has been pretty much driven by WebKitGTK+ s requirements, and Dan Winship has made it possible to make our soup backend much, much simpler and way more featureful. That meant, though, requiring very recent versions of soup. To top it off, for anyone not running Debian testing and tracking the exact same versions of packages as the bots it was virtually impossible to get the tests to pass, which made it very difficult for even ourselves to make sure all patches were still passing before committing something. Wow, what a mess. The explosion^Wsolution So a few weeks back Martin Robinson came up with a proposed solution, which, as he says, is the nuclear bomb solution. We would have a jhbuild environment which would build and install all of the dependencies necessary for reproducing the test expectations the bots have. So over the first three days of the hackfest Martin and myself hacked away in building scripts, buildmaster integration, a jhbuild configuration, a jhbuild modules file, setting up tarballs, and wiring it all in a way that makes it convenient for the contributors to get along with. You ll notice that our buildslaves now have a step just before compiling called updated gtk dependencies (gtk is the name we use for our port in the context of WebKit), which runs jhbuild to install any new dependencies or version bumps we added. You can also see that those instructions I mentioned above became a tad simpler. It took us way more time than we thought for the dust to settle, but it eventually began to. The great thing of doing it during the hackfest was that we could find and fix issues with weird configurations on the spot! Oh, you build with AR_FLAGS=cruT and something doesn t like it? OK, we fix it so that the jhbuild modules are not affected by that variable. Oh, turns out we missed a dependency, no problem, we add it to the modules file or install them on the bots, and then document the dependency. I set up a very clean chroot which we could use for trying out changes so as to not disrupt the tree too much for the other hackfest participants, and I think overall we did good. The aftermath By the time we were done our colleagues who ran other distributions such as Fedora were already being able to get a substantial improvements to the number of tests passing, and so did we! Also, the ability to seamlessly upgrade all the bots with a simple commit made it possible for us to very easily land a change that required a very recent (as in unreleased) version of soup which made our networking backend way simpler. All that red looks great, doesn t it? And we aren t done yet, we ll certainly be making more tweaks to this infrastructure to make it more transparent and more helpful to the users (contributors and other people interested in running the tests). If you ve been hit by the instability we caused, sorry about that, poke mrobinson or myself in the #webkitgtk+ IRC channel on FreeNode, and we ll help you out or fix any issues. If you haven t, we hope you enjoy all the goodness that a reproducible testing suite has to offer! That s it for now, folks, I ll have more to report on follow-up work started at the hackfest soon enough, hopefully =).

<object data="https://upload.wikimedia.org/wikipedia/commons/d/de/Aspect-ratio-4x3.svg" type="image/svg+xml"> https://upload.wikimedia.org/wikipedia/commons/d/de/Aspect-ratio-4x3.svg</object> <object data="https://upload.wikimedia.org/wikipedia/commons/f/f8/Aspect-ratio-16x9.svg" type="image/svg+xml"> https://upload.wikimedia.org/wikipedia/commons/f/f8/Aspect-ratio-16x9.svg</object> It seems that nearly all computer monitors have now switched from a 4:3 aspect ratio popular several years ago to a "wide screen" 16:10 and now mostly to an even wider 16:9. But screen sizes are usually measured by their diagonal length and those sizes have not changed. For example, before I had my Thinkpad X201, I had a X60 and a X35. They are similar laptops in the same product line with 12.1" screens. But 12.1" describes the size along the diagonal and the aspect ratio switched from 4:3 to 16:10 between the X60 and the X201. As the screen stretched out but maintained the same diagonal length, the area shrunk: from 453 square centimeters to 425. But screens are not only getting smaller, they are also getting less useful. The switch to wider aspect ratios is done so that people can watch wide screen movies while using a larger proportion of their screens. Of course, the vast majority of people's time on their laptops is not spent watching wide screen movies but in programs like browsers, word processors, and editors. Because most of our writing systems lay out documents from top to bottom, the tools we most frequently use to display (and then scroll through) the things we read primarily use vertical screen space -- the dimension that is shrinking. If you have a desktop monitor, you might rotate the whole thing 90 degrees and "solve" the problem. If you're on a laptop though (as I usually am) this is clearly not an option. I am not the first person to be annoyed by this trend. In fact, many recent desktop UI changes are designed to work around this issue. In the free software world, both Unity and GNOME 3 have made efforts to hide, merge, or otherwise get ride of title bars, menu bars, and panels that take up dwindling vertical space. I use Awesome which I've mostly set up to do two side-by-side terminals with very little in the way of menu bars. Applications are the worst offenders and the solutions for those things that won't run in a terminal (or people that don't want to live there) are still lacking. I have been using Firefox's Tree Style Tab extension to move tabs to the side and hand-customized toolbars that squeeze everything I need (i.e., back, forward, stop, refresh, and URL bar) onto a single menu bar. But the situation still drives me crazy. I'd love to hear what others are doing.

Prepare a location to run juju and install it:

mkdir ~/party
cd ~/party
sudo apt-get install juju

Initialize your juju environment. Be sure to add juju-origin: ppa to your environment, along with filling in your access-key and secret-key from your Amazon AWS account. Note that control-bucket and admin-secret should not be used by any other environment or juju won t be able to distinguish them. Other variables are good to set now too. I wanted my instances close to me, use I set region: us-west-1 . I also wanted a 64bit system, so using the AMI list, I chose default-series: oneiric , default-instance-type: m1.large and default-image-id: ami-7b772b3e

juju
$EDITOR ~/.juju/environments.yaml

Get my sbuild charm, and configure some types of builders. The salt should be something used only for this party; it is used to generate the random passwords for the builder accounts. The distro and releases can be set to whatever the mk-sbuild tool understands.

bzr co lp:~kees/charm/oneiric/sbuild/trunk sbuild-charm
cat >local.yaml <<EOM
builder-debian:
    salt: some-secret-phrase-for-this-party
    distro: debian
    releases: unstable
builder-ubuntu:
    salt: some-secret-phrase-for-this-party
    distro: ubuntu
    releases: precise,oneiric
EOM

Bootstrap juju and wait for ec2 instance to come up.

juju bootstrap

Before running the status, you can either accept the SSH key blindly, or use ec2-describe-instances to find the instance and public host name, and use my wait-for-ssh tool to inject the SSH host key into your ~/.ssh/known_hosts file. This requires having set up the environment variables needed by ec2-describe-instances , though.

ec2-describe-instances --region REGION
./sbuild-charm/wait-for-ssh INSTANCE HOST REGION

Get status:

juju status

Deploy a builder:

juju deploy --config local.yaml --repository $PWD local:sbuild-charm builder-debian

Deploy more of the same type:

juju add-unit builder-debian
juju add-unit builder-debian
juju add-unit builder-debian

Now you have to wait for them to finish installing, which will take a while. Once they re at least partially up (the builder user has been created), you can print out the slips of paper to hand out to your party attendees:

./sbuild-charm/slips   mpage -1 > /tmp/slips.ps
ps2pdf /tmp/slips.ps /tmp/slips.pdf

They look like this:

Unit: builder-debian/3
Host: ec2-256-1-1-1.us-west-1.compute.amazonaws.com
SSH key fingerprints:
  1024 3e:f7:66:53:a9:e8:96:c7:27:36:71:ce:2a:cf:65:31 (DSA)
  256 53:a9:e8:96:c7:20:6f:8f:4a:de:b2:a3:b7:6b:34:f7 (ECDSA)
  2048 3b:29:99:20:6f:8f:4a:de:b2:a3:b7:6b:34:bc:7a:e3 (RSA)
Username: builder
Password: 68b329da9893

To admin the machines, you can use juju itself, where N is the machine number from the juju status output:

juju ssh N

To add additional chroots to the entire builder service, add them to the config:

juju set builder-debian release=unstable,testing,stable
juju set builder-ubuntu release=precise,oneiric,lucid,natty

Notes about some of the terrible security hacks this charm does:

• enables password-based SSH access (and locks the default ubuntu account), so party attendees don t need anything but the ssh client itself to get to the builders.
• starts rngd -r /dev/urandom to create terrible but plentiful entropy for the sbuild GPG key generation.

Enjoy!

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

It has been a while since I blogged but I've been very busy, with my new job and this new blog! New job! I quitted my job last September, and found another one that I started in October. I'm now the lead developer of eNovance Labs, where I work on the OpenStack project. So far, this allowed me to contribute heavily to the Debian packaging of OpenStack. New blog! In the meantime, I took some time to redesign my personal homepage and this blog, which is now using Hyde, the Python equivalent of Jekyll, which is in Ruby. Since I dislike Ruby (sorry), I preferred to use a Python based generator, and I admit Hyde is really cool. Since I really suck at Web design, this one is obviously based on Twitter's bootstrap

This is a less useful writeup now than it would be six months ago when I was first going to do it, but oh well. Some people are still stuck running the Sun Java JDK for a while longer, and maybe it will be useful. Due to a variety of silly reasons too long to get into, the non-free Sun JDK comes with some encryption functionality disabled, particularly 256-bit AES. Those who want to use it have to download and install two replacement JAR files, which are not redistributable. While the Sun JDK is packaged for Debian in squeeze for those who have to use it (usually for legacy applications that haven't been ported to OpenJDK 7), the JCE policy files cannot be packaged. The hardest part of this is that, due to how the Sun JDK is packaged and where the files have to be installed, it's tricky to install them without having to redo that work each time the Sun JDK is upgraded or reinstalled. I wrote up instructions and packaging files for building packages that do the right thing, including across version upgrades of the Sun JDK. If you still have to use the Sun JDK, take a look. (And work on converting your software to work with OpenJDK 7 for the wheezy release!)

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

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.