Some years ago, I faced a 900 word limit for the first time. My question to the editor: Can I write the column in German?

WordPress currently has an annoying bug where you cannot add images easily using the in-built editor. Instead of a pop-up being shown with the image setting details, you are sent to another page. Once you choose the image size etc, you go to a blank page. Until that s fixed, there is a work-around. It s not exactly pretty but it does work. I have assumed you have uploaded your images to the media library first. First, type up what you want your blog entry to say. The save it as a draft which is the button in the blue circle in the screenshot. Then click the add image icon which will bring up the warning to go to the image selection page. This page should be a pop up on the same screen but is not (and is the bug). On the image selection page choose Image library which is the blue circle and edit the meta-data such as the name caption etc. Once you are happy with your decisions, click the Insert into Post button (red circle) which goes to a blank screen. The blank screen actually does have data in it. You will need to view source which will show something like: The stuff in the win.send_to_editor is what you want. You will also need to change the backslash-quotes to plain quotes, so the code I would use is You then enter this information back into your post (click back a few times in your browser). Also, make sure you have your editor set for HTML and not Visual for it to work. With that small bit of HTML, I have a nice set of home-grown tomatoes, or whatever else you want.

And so there went a day of work. Minutes done, come back tomorrow

---

Okok, more text: We did lots of stuff. There was breakfast, soon after we had Lunch, and guess, Dinner also. Now, would you please come back tomorrow?

---

Anyways, we did some things. One of those was to have PostgreSQL 9.0 and to enable the replication to the machine any DD can access. Which is, from today on, ries.debian.org. And for the first time ever (since that time ftp-master got closed to the public), DDs can now see the live status of the archive, literally a second after a package got accepted a dak ls on ries will show you that fact. Torsten worked on fixing up old remnants of code and database entries around contents and also tackled a problem between our usage of SQLalchemy and the python multiprocessing module. He also started working on the source contents and was weird enough to get us standardized logging into a dak tool. Mark worked with DSA on the Postgres 9.0 upgrade to fix what was to fix in out database and did some tests with our environment in squeeze and coordinated changes in python-apt needed for multiarch and xz. He then started working on some larger database changes around the built-using feature. I myself started off with getting generate-packages-sources to behave when there is an error instead of silently ignoring that. I also did a bit of groundwork to enable us to do NEW processing adding overrides for all affected binary packages, not just those from the architecture currently uploaded. That will allow stuff like linux-2.6 to pass NEW just once, not once per architecture. That involves a new field in our dsc files and the status of that is tracked in Bug #619131.

I have been working on gjay to add support for Music Player Daemon where I had what initially looked like a strange problem. When WITH_MPDCLIENT was defined, the program would crash in all sorts of wierd places when the main program structure had this: But would work fine when it was: I tried changing the structure to just void *blah to see if it made a difference and it didn t. The program would crash every time. The answer was pretty simple in the end. The WITH_MPDCLIENT is defined in the file config.h and not every c source file was including it. Needless to say, they should! So half the program was using one version of the structure and the other was using another; no wonder the whole program was a mess because anything beyond this entry in the structure would be a few bytes out. With that little insanity out of the way i can get back to making gjay work with mpd.

It seems that once again, the squirrel has it right:- <iframe allowfullscreen="allowfullscreen" frameborder="0" height="390" src="http://www.youtube.com/embed/5_mZrUkzabk" title="YouTube video player" width="480"></iframe> For those of you reading this via a planet, or similar, please click on the title of this post to see the video I ve embedded above. (Please note, may contain language that offends some)

Let's assume that all low-level and file-layout work is done, and we need specifications how to make Debian high-level package managers multi-arch aware.

What we have now: only one package of the same name can be installed in the system, and packages can declare dependencies only against packages of the same architecture.

What, hence, needs to be specified:
a) are certain packages of the same name but different arches co-installable or not;
b) allow to specify foreigh arches in dependencies.

Then, how our high-level multi-arch spec could be written?

a) new field 'MultiArchCoinstallable: yes' for co-installable packages;
b) new dependency syntax: package_name[:[!]arch[,arch]...], for example: 'perl' (assuming 'perl:native' for forward dependencies like 'Depends' or 'Recommends', and 'perl:any' for Conflicts and Breaks), 'perl:amd64', 'perl:amd64,i386', 'perl:!i386', 'perl:native', 'perl:any'.

That's all. Looks easy and mostly intuitive, doesn't it? However, some people are going to implement this instead.

I recently deployed my node.js proxy server, removing all traces of Apache2 from my main server. During the course of this transition I discovered:

Bugs in my code

Not unexpected, in all honesty. There were two main issues; the first was relating to how I handled the 304 response, the second was relating to how I performed rewrites for my mercurial repository vhost.

Bugs in node.js

Given how new node.js is there wasn't a huge surprise here either, although I thought I'd been good testing against 0.2.x. As it turned out I needed to run the more recent 0.4.x to avoid a couple of issues:

• HTTP headers are lower-cased
• ECONNREFUSED was not being caught the way that I expected.

In short I have a backported node.js package for Squeeze which is almost worthless. I'll update it in the near future. For the moment:

cd node-v0.4.3/
./configure --without-ssl --prefix=/opt/node-0.4.3 && make && make install
ln -fs /opt/node-0.4.3  /opt/node

Oddities in thttpd

thttpd is what actually runs my websites and I discovered during some extended debugging sessions that it just does not like HTTP requests starting with a doubled "/" character. For example this works fine:

wget http://www.acme.com/software/thttpd/

But this fails:

wget http://www.acme.com//software/thttpd/

Previously it seems that Apache was (silently) fixing this up before it proxied requests. Now I have to do it myself, no big thing, but still a surprise.

All in all it was worth it to be able to run:

dpkg --purge libapache2-mod-rpaf \
             apache2.2-common \
             apache2.2-bin \
             apache2-utils \
             apache2-mpm-prefork \
             apache2 \
             libaprutil1-dbd-sqlite3 \
             libaprutil1-ldap \
             libaprutil1 \
             libapr1

ObQuote: "Bad news. The fog's getting thicker." - Airplane!

I've just made a couple of software releases:

• larch version 0.19. This used to be known as btree, but others are using that name, so I changed it. This is my copy-on-write B-tree library for Python.
  • see http://liw.fi/larch/ for more information
  • see http://liw.fi/larch/NEWS/ for changes
• obnam version 0.15, and then the obligatory brown paper bag version 0.15.1 to fix a build issue under pbuilder. Obnam is my backup program.
  • see http://braawi.org/obnam/ for more information

This is the first release of Obnam this year. Below is a summary of the changes. My apt repository has binary packages for amd64, i386, and armel. I've started mentoring someone to help me maintain the Debian packages, and hope to start uploading Obnam and its dependencies to Debian within a few weeks. Obnam is still in ALPHA, but the only missing thing for moving to BETA is encryption support. There's a bunch of bugs that need to be fixed, but I'm not going to block the BETA on them. I'd be very interested to hear any feedback on this version. Bugs fixed:

• Manual page GPL copyright blurb is now properly marked up as a comment. (Thanks, Joey Hess.)
• README now links to python-lru correctly. (Thanks, Erik Johansson.)

Improvements and other changes:

• Filenames and directories are backed up in sorted order. This should make it easier to know how far obnam's gotten.
• The location where backups are stored is now called the repository, instead of the store. Suggested by Joey Hess.
• The repository and the target directory for restored data are now both created by Obnam, if they don't already exist. Suggested by Joey Hess.
• Better control of logging, using the new --trace option.
• Manual page now explains making backups a little better.
• Default value for --lru-size reduced to 500, for great improvement in memory used, without, it seems, much decrease in speed.
• obnam verify now reports success explicitly. Based on question from Joey Hess.
• obnam verify now accepts both non-option arguments and the --root option. Suggested by Joey Hess.
• obnam forget now accepts "generation specifiers", not just numeric generation ids. This means that obnam forget latest works.
• I/O statistics are logged more systematically.
• obnam force-lock introduced, to allow breaking a lock left behind if obnam crashes. But it never does, of course. (Well, except if there's a bug, like when a file changes at the wrong moment.)
• obnam genids introduced, to list generation ids without any other data. The old command obnam generations still works, and lists other info about each generation as well, but that's sometimes bad for scripting.
• The --dump-memory-profile option now accepts the value simple, for reporting basic memory use. It has such a small impact that it's the default.
• Obnam now stores the version of the on-disk format in the repository. This should allow it to handle repositories created by a different version and act suitably (hopefully without wiping all your backups).

I have been working in the last weeks in the removal of the last pieces of KDE 3 from the Debian archive and I have found there are a lot of packages that is sad having to remove. If you are looking for a good idea/excuse to learn and improve your KDE 4 / C++ /Qt4 skills, have to do a small application for school or you just feel like some useful coding, here is the list:

• creox real-time guitar effects
• kbarcode barcode and label printing application for KDE
• kbiff KDE mail notification utility
• KKBSwitch keyboard layout indicator for KDE (see this post also)
• kmyfirewall iptables based firewall configuration tool for KDE
• kpogre a graphical administrator tool for PostgreSQL
• kredentials KDE taskbar applet to update kerberos/AFS credentials
• ksociograma technical educational software to make sociograms
• ktechlab circuit simulator for microcontrollers and electronics
• qalculate-kde Powerful and easy to use desktop calculator KDE version
• score-reading-trainer trainer for reading music notes

Note that I do not list here software whose port in KDE 4 is being developed although it is still not finished and therefore it is not packaged in Debian. By the way, even if all those packages are being removed from Debian testing and unstable, they will remain in Squeeze, so you can keep using them or install it from there.

This weekend we did run a booth at Chemnitzer Linuxtage. As always, it was a joy to be at this event. We had great discussions and talks with guests and exhibitors, I also enjoyed a small number of lectures. The booth did run well, beside some quirks. Some pictures can be found here.

Projects I've been working on are, if not bearing fruit, at least showing promise. git-annex is growing up a nice community that nags me about things like Mac OSX and FAT filesystem support. It's great to have their feedback, it's been leading to fast improvement, even though I've only gotten two patches to my haskell code. :) New users are finding Branchable despite us not knowing how to market it. Sometimes a new site springs up overnight fully formed, having been developed on a laptop and git pushed to us. I get a vicarious thrill over whatever our users are doing, be it driving to Mongolia or watering plants with arduino.

Now that I sent an update about my running activities, I have to report about what I'm doing these weeks in Debian to try keeping a fair balance for those of you who read this blog through Planet Debian. Most January was spent in preparing the release of squeeze. Of course, I didn't work directly on the release, not being involved in the release team. However, last bits of preparation for Debian Installer as well as rushing out the last remaining bits of localization work took most of my time. After the release of squeeze, time came to resume back some activities. First of all, on the l10n front, I resumed the work on "l10n NMUs", trying to get old l10n bugs fixed. I restarted proposing NMUs or, more precisely, help to perform translation updates rounds to these maintainers. Most of them had "old" l10n bugs because of the freeze. So, I indeed did not end up in doing many NMUs...but got several l10n bugs closed anyway. Work being resumed in unstable also lead to many changes in packages' debconf templates (new packages using debconf, packages introducing new templates, etc.). As these are the trigger for Smith reviews (reviews of English in debconf templates and packages' description, this activity, which was very low during the freeze, resumed again (we'll soon celebrate the 4th anniversary of this project). I also decided to invest more time in D-I again. The D-I team is currently more active than it was last years. Thanks to a few individual, work resumed in some areas and bug triaging has been very active. I recently resyned a nice improvement which had been contributed by a user to iso-scan, then polished by Frans Pop. This will allow to choose among several different ISO images when installing Debian from a USB stick while, previously, only the first found was being used. I also worked with a new translator, to prepare the activation of Uyghur translation in D-I. Some work happend in the pkg-fonts team. I had a few fonts adopted by the team, as part of the general effort to get rid of defoma. I sent patches for a few others, but many remain. If you maintain font packages, please help us in getting rid of defoma. Changes are easy to do; ask the team if you need help (pkg-fonts-devel@lists.alioth.debian.org). Samba packages also ate a significant part of my time. First of all, DSA-2175 lead to prepare fixes for samba in squeeze and lenny. Then, upstream released samba 3.5.8 which I uploaded to unstable. I briefly considered trying to get the Stable Release managers approval to push that version in squeeze, but the number of fixes made by upstream was discouraging. So, I chose to examine them slowly and cherry-pick those I consider important enough to warrant an upload for squeeze. More git wizardry learned doing so (thanks to Julien Cristau for his help). And I now have a pending proposal for three of these fixes (that represent 14 atomic patches from upstream) to be included in squeeze.

The first two months of this year have seen me quite busy preparing for my March-April peak of activity. So, most of these were spent accumulating kilometers, mostly on trail runs with mud, slope, obstacles, etc.

• January: 240km, 21h17', 3000m positive slope
• February: 170km, 15h10', 1900m positive slope

January was meant to accumulate kilometers, which succeeded quite well..:-). Not as crazy as November 2010 (close to 300km) but the point was also testing a few long runs, over 25km and up to 32. February saw my first official race, with Bullion half-marathon. This is a nice race which I already ran last year. It features small roads in the Rambouillet Forest. Not the best place to achieve a personal best because the race is not flat, with two hills in the first half. Moreover, I was just recovering from a small flu, so I wasn't really planning to achieve a PB. Still, I managed to do it in 1h39'49", two minutes more than my PB. Moreover, I managed to do it in a small negative split, with first half in 50'38" and second half in 49'11". More encouraging, I ran a 35km solo trail the next week-end after this and completed it fairly well with the pace I plan for the 50km Eco-Trail. Still, that flu introduced some minor perturbation in this preparation and, thus, I included more activity in early March. I was originally planning to run Paris half-marathon on 6th, but an invitation for a friends 50th birthday made me cancel that one. So, most of the first 3 weeks of March were spent in 15-18km style runs, plus running daily to go to and back from work. The last preparation was today with a short 12km run with all equipment needed for Eco-Trail (backpack, 2lit. waterbag) and the targeted pace (10km/h). So, on Saturday, will be the Paris Eco-trail 50km race from Versailles Castle to Eiffel Tower....through woods in the South and South-West neighbourhood, with 1000m positive slope. This will be my first ultra race, so I'm a little bit in a grey area, here. As a consequence, the only ambition is finishing. I expect it to be in aroung 5h30 or so. Most importantly, I have to keep reserves, as, two weeks later, I'll run my yearly Paris marathon. Two long distance races in two weeks...we'll see if I'm crazy or not..:-) Now, I'm heading for a quiet week: grow glucides reserves, eat pasta, do one or two footings...and wait for Saturday! You may want to watch my blog on Sunday to see whether I survived this first stage.

I posted a brief snippet of code on Friday which was my initial stab at a reverse HTTP proxy in Javascript (using node.js). Over the past couple of days I've tidied it up, added a command line parser, and made it flexible enough that it works for me. My node reverse HTTP proxy is now both documented ( a little ) and available for further eyeballs. Usage is pretty much:

$ node ./node-reverse-proxy.js --config ./path/to/config.file.js

The configuration file defines lists of virtual hosts along with the destination back-ends to proxy to - which is usually going to be a server running upon a high port on the loopback adapter, but might not be. In addition to that we can perform rewrites such as:

/**
  * Handler for wildcard host: *.repository.steve.org.uk
  *
  */
'([^.]*).repository.steve.org.uk':
     
        /**
         * Rewrites for static files - these will be handled via a
         * separate virtual host.
         */
        'rules':  
            '^/robots.txt':  'http://repository.steve.org.uk/robots.txt',
            '^/favicon.ico': 'http://repository.steve.org.uk/favicon.ico',
         ,
      ,

That says requests for http://chronicle.repository.steve.org.uk/robots.txt will be redirected to http://repository.steve.org.uk/robots.txt. Alternatively we can invoke javascript for each request matching a pattern:</p.>

    /**
     * static.steve.org.uk will mostly proxy to 127.0.0.1:1008
     * but files beneath /private/ have an IP-based ACL.
     */
    'static.steve.org.uk':
     
        host: 'localhost',
        port: '1008',
        'functions':  
            '/private': (function(orig_host, vhost,req,res)  
                var remote = req.connection.remoteAddress;;
                if ( ( remote != "80.68.85.46" ) &&
                     ( remote != "82.41.51.252" ) &&
                     ( remote != "89.16.161.34") &&
                     ( remote != "89.16.161.98" ) )
                 
                    res.writeHead(403);
                    res.write( "Denied access to " + req.url  + " from " + remote );
                    res.end();
                 
            ),
         
     ,

Fun stuff. It was live for my server, replacing apache, for a few hours today. I need to add some trivial HTTP Basic-Auth handling then it will go back. Otherwise I hope it is vaguely useful to others, and that the provided examples explain things neatly. ObQuote: "Only one thing alive with less than four legs can hear this frequency" - Superman.

AltOS 0.9.2 Minor update to ground station software Bdale and I are pleased to announce the release of AltOS version 0.9.2. AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based microcontroller firmware and Java-based ground station software. AltosUI Just a few bug fixes AltOS version 0.9.2 is a minor release with just a couple of fixes:

• Mac OS X graphing repaired. The 0.9 release was missing a file required to support the graphing feature (jcommon.jar). This has been added.
• Fixed multiple flight log downloading. Attempts to download more than one recorded flight log would fail in weird ways. The failures have been addressed and additional diagnostics are presented when things go wrong.
• You can see the AltOS version number in the Configure AltosUI dialog box now. This should make it easier to tell what you ve got installed.
• Post-flight graphing tool. This lets you explore the behaviour of your rocket after flight with a scroll-able and zoom-able chart showing the altitude, speed and acceleration of the airframe along with events recorded by the flight computer. You can export graphs to PNG files, or print them directly.

No Firmware Update AltOS version 0.9.2 does not include any firmware changes. We re still busy testing the Kalman filter code; that ll be in the next major release.

A bit more than a month ago, I had the random idea to try building and selling a web site, at the same time. The idea was that the more people bid, and requested features, the more I'd work on it. It didn't work out. I got a bit of money out of it, but certainly not enough to cover my time at an hourly rate. I suppose the lesson is that a month simply isn't a lot of time for something to mature: it'd probably be best to work on something on and off for a year, give it some time for traffic to build up, and so on, if the goal is to sell it. However, in any case, I think I'm pretty convinced that my next projects, like LiberWriter, will involve for-pay products. At heart, I'm not really a business guy, so picking the simplest possible business model probably makes sense: you pay me, I give you something. Hopefully, I'll be able to write about those in the "you win some column", but I thought I'd let people know how the experiment went.

Will drive to Chemnitz now. Maybe meet me there. No booth, just visiting to meet everyone again, rather spontaneous.

Quite probably, the best thing got for myself during the last year was my Kindle. I just love it! It has changed the way I interact with knowledge, and saved me from hours of boredom. But it has also taught me the value of scribbling along the book pages and of underlining passages. Yes, I hold a deep regard for my regular (paper) books, and I never scribble on them, not even on text books. In any case, I can scribble on a post-it or something like that. Still, when you underline or comment on a passage in the Kindle, what can you do with your annotation? Well, not much. Annotations (called clippings in Kindlespeak) are stored on an easily accessible My Clippings.txt text file, very easy to parse and work with. So, I devoted yesterday evening to coming up with a first prototype of an app that I think can be very useful if you use clippings extensively: It displays each clipping with its base information separately, allows you to filter on the specific book to which each clipping is related as well as on the clipping type. So, if it interests you, clone it away from github!

git://github.com/gwolf/kindleclip.git

Written in Ruby, Gtk (Glade). No further libraries are (currently?) needed. The code is far from beautiful, but is a first stab towards functionality. Any comments welcome!

For the users of Debian Squeeze we, the KVIrc maintainers, plan to upload the soon-to-be-released upstream bug fix release 4.0.4, packages of RC2 are available. RC2 is most likely going to be identical to the final 4.0.4 release. The update will be, if the SRMs agree (still need to ask them, but I wanted to wait for the final version before I do that), uploaded to stable-proposed-updates, maybe squeeze-updates and fix a few nasty bugs, which some users might experience, including graphical glitches when used under Gnome (upstream bug #1010), some crashes (e.g. upstream bugs #878, #879, #1093, #1098 and some without bug numbers like r4796), a regression in the Perl scripting support and a lot of translation updates (btw: if you use KVIrc and the translation for your mothertounge is lacking, consider to help! Coordinate your efforts on IRC.) Apart from that I just uploaded a new SVN snapshot of 4.1 into Sid, the next will follow in about ten days unless you report bugs, which make an earlier upload necessary. ;-)

A bit of history One of the greatest criticisms of Debian is that its release cycles are too long. Debian stable release is seen as often as Ubuntu s LTS release. As a server solution this doesn t present a problem at all, it can even seen as a pro. However, for desktop use and for your average Joe who needs to have the latest software and is unable to get it, this may well present a problem. Of course he can always turn to backports to get what he needs but by the time you have finished reading this very sentence, Joe has already moved to Ubuntu. For those who are completely unaware how things work within Debian, let me try to shed some light. Debian has 3 main branches:

• stable
• testing
• unstable

Unstable , is a branch used mainly by developers, where the latest changes to the software they are working on are made. Usually, after approximately 10 days this software is pushed to testing , branch which is going to become next Debian stable release. For comparison, in the process of a new Ubuntu release at one point in this process, changes from testing/unstable are frozen where Ubuntu fixes bugs until they are ready to release new Ubuntu release. Debian s testing branch is said by some to be more stable then most of the stable distributions out there. Last but not least is stable branch, which follows the (in)famous mantra it s released when it s ready , although last two releases have been released in a more timely manner. Okay, so what is Debian CUT? The idea stretches back more then 2 years, to Joey Hess proposing the idea of Constantly Usable Testing . For users/developers who can t wait ~2 years to see new Debian release, they usually turn to Debian testing branch. To clarify, testing images are released weekly, but most of us in Debian don t recommend you jump to testing by installing it from weekly image, but rather by upgrading from stable. To make the situation even worse, these builds frequently don t work due to all the changes that have been pushed from unstable. But this is where Constantly Usable Testing idea comes in, where the installer is always installable and you re already using what s going to be next stable release. You wouldn t have to worry about whether the next update is going to break your system, but would get regular security updates, while the big updates would come in shape of new testing snapshot versions. Frequency of release of these snapshots is ought to be on monthly basis, so you can plan on seeing the next release on April 6th (exactly one month after the current release, provided of course if there are no showstopper bugs). To sum it all up, you wouldn t have to wait ~2 years before new Stable release shows up, nor (in case you have already switched to testing) would you have to worry whether your next update will break your system. You would get your updates in form of timely (ie: monthly) snapshots until it s time for major milestone which would turn out to be new Debian release. Even though this might be long term goal, in these early stages no one can guarantees this. Rolling release? The simplest way to explain this concept is that there are two types of Linux distributions: one with milestone version numbers and other where new updates keep coming through their rolling release cycles. Some of the rolling distributions are Gentoo and Arch Linux, while on the other side you have RedHat and Suse. Novell announced that OpenSuse is moving to rolling release with project codename Tumbleweed. It s also worth mentioning that Debian already has its rolling counters and perfect examples are: LMDE and aptosid. It is a way to continuously develop software, a way that best fits Debian as a platform where software is continuously developed. Especially because most of its greatest values could get lost with the release of that big stable version . Perfect case of that could be the almost drop of Chromium in Squeeze. Another great example could be Android, which is criticised most for its versioning. Companies are refusing to release new Android versions to their current phones, because they want you to buy new phone with latest Android version, even though your current one is perfectly capable of running latest Android. Personally, I m sure the future will reveal that rolling releases are the future, towards which all Linux platforms should be heading. Perhaps the definition of rolling releases I gave earlier is why I believe this project has such bright future ahead of it. Debian would be somewhat of a hybrid of this definition, it would be rolling release until it s time to mark a big milestone with a version number, and before you know it, we re rolling again. Unofficial Debian Monthly Testing Snapshot Release (version 2011.03 final) Michael Gilbert took on a big responsibility, trying experimentally to prove the feasibility of such a project. He has released a first wheezy snapshot installer (versioned 2011.03) as a test for the development community to try out and evaluate. Please read official announcement along with download links. While you can use this snapshot to have constantly working installer, after it is installed you could move to testing altogether if you wish. Conclusion As I have already mentioned, this project is still in the development/experimental stage, which makes all of this its very conception. Also, apart from rumors of Ubuntu becoming rolling release, if Ubuntu is to get its rolling release this how it s going to get it If you d like to find out more about Debian CUT, I suggest you read Raphael Hertzog s article A constantly usable testing distribution for Debian , and watch the video of Joey Hess CUT BoF on DebConf10 in NYC. Of course, if you d like to get involved into this project, please use the project s mailing list. If you have any comments, please do share, as I d be happy to answer any of your questions.