If a single man can display so much hatred
think only of how much love we all can display together.

Stine Renate H heim

I wrote a Norwegian post explaining my experience at Ut ya. I had taken this blog for dead, and had entirely forgotten that it was syndicated on Planet Debian. I don t want to let Google Translate make this disaster any worse than it is the translation of bullets into balls being particularly bad so the international attention the massacre has garnered in consideration, I am writing an English translation of my experiences. I feel somehow duty-bound to make people aware of what happened, but I don t want to get into anything else but a sober description of the events and some very brief reflections. There are many details I have chosen to omit. Others have written their experiences of the events at Ut ya. I wanted to write mine down as well, and get it out there . Partly, I want to write this down because I m unsure if I will remember all the details at a later point in time, although I think I d prefer it if I couldn t. I m also writing this because people are asking about my experiences and it s much better to have an URL to give them, lest I have to keep going through the same spiel over and over again. Our former Prime Minister and current labour movement demigod Gro Harlem Brundtland had recently left the island. I had been the cameraman for a video interview of her talking about Ut ya, and I was in the media group room encoding the video into a file suitable for YouTube, when someone else in the room startled and said that Twitter was full of messages about a loud explosion in Oslo. As the newspapers brought us information about the extent of the damages, a consensus arose that an informational meeting was in order. As soon as the current round of talks finished, we were gathered into the main hall. The meeting was duly held, and after the statement was made that a TV feed would be made available, I took it upon myself as the local alpha geek to make it happen. Of course, the situation caused both the wireless network and the GPRS networks to become totally unusable. As I was waiting for someone to set up a password, I took the opportunity to face the consequences of having eaten two bits of a microwavable dish called Hold-It the local equivalent of a Hot Pocket and went to the toilet. As I was in there, I first heard agitated shouting, then screams, then gunshots coming from just outside the toilets. More than anything else, it sounded like a toy gun. I was convinced that someone was making a joke in incredibly bad taste and I stormed out of the booth with the intent of halting it. As I tore the door open, I saw two of my comrades hiding in a recessed corner. Their facial expressions left absolutely no doubt that this was no toy. They signalled for me to get back in the booth. I closed the door, did a mental double-take in utter, complete confusion, and opened it again. They were still signalling. Had they not stood there, I would have run straight into the gunman; they saved my life. I looked out into the hallway, and I made eye contact with a young boy lying in a pool of blood. He was motioning for me to help him. I heard more gunshots from inside the building and retreated back inside. As I was trying to think through my next move, I realized that the decidedly insubstantial wood-fiber door would not resist any kind of bullets. I made my way out into the hallway, with the intent of escaping outside. At that point, I was of course not aware that there was an intention to kill as many as possible, so I thought that the open spaces outside would be a place of relative safety. Of course, this proved to be wrong and my life was probably saved a second time by one of the caf volunteers taking me into a hard-to-spot employee s bathroom. We sat there for ninety minutes. Always ready to make a run for it, ready for just about anything. A peculiar group dynamic arose with these two people with whom I had barely previously spoken. We came to share a strange sense of common destiny and gallows humour. One of them had seen the shooter and described the police uniform. I perceived it to be realistic that we were the only ones aware of the wounded outside the toilet. I tried to reach the emergency services, but all their lines were busy; the terror attack in Oslo had probably clogged their lines. I finally got through to the fire services, who could inform me that the police did know about the situation and were on their way. This was to take 90 minutes and by the time we evacuated, the young boy outside my door had perished. The despair I first saw in his eyes as I passed him, fleeing from one room to the other and the empty, blank stare as we left, are burned into me and they are images I will never in my life forget. Finally, the real police arrived. We walked out. I chose the path through the minor conference hall something I now regret. The sight was simply beyond my capacity to describe fully, and so terrifying that I barely remember the sight only the terror it struck in me. There were several people bunched up in a corner, a big amorphous heap of bodies. Some were conscious and yelled at me not to do anything that could startle the police, others lay still. Their bodies were all covered in blood, and a thick pool of blood extended at least a half-metre in all directions around them. The policeman across the hall was screaming orders at me, but he was screaming so loudly that I couldn t make out his words at first. We were first moved into the camp newspaper s offices. There were about eight of us there, I think, in addition to one girl who lay wounded. Towards the end she was drifting in and out of consciousness. We covered her with sweaters to keep her warm and one of us tried to at least temper her bleeding. The bullet had missed her heart, but by the entry wound it was clear that it was not by far. I do not know who this girl was or how she is now. I sat behind and never saw her face. The wounded were evacuated first. I don t remember how long we remained; I had lost all concept of time. In spite of protests from the group who knew him, one kid was put in handcuffs. At the time I didn t understand why, and the policeman seemed to say something almost to the effect that there was no reason for it at all. I didn t see when they undid his cuffs, but I remember thinking that this treatment made a terrible experience even worse for him. I tried my best to comfort him but knew it would be little help. Later, when things stabilised a little, we were told that he was handcuffed because he had come from an unsecured area. The police was extremely good at carefully explaining what was happening and why; this was a big help and I am grateful for it. Eventually we were moved out into the main corridor of the building, where we joined up into a group of about fifty. Only when I saw the two people who saved my life did any emotion other than mild confusion arise. I broke down shivering in tears in one of their arms. After a few seconds, I came back to my senses and realised that this was not the time. I quickly gathered myself, got the shaking under control, and sat down. We were given some chocolate and soda from the kiosk. I remember making an offhand remark that an inability to find joy in free candy was a sure sign of a bad situation. We all laughed out loud. Gallows humour is a coping mechanism, but in retrospect one almost feels guilty for it. We were shown out in a single file with hands above our heads. I remember an intense concern that someone would slip in the steep, muddy slope and create a misunderstanding. Outside, there were more bodies. Some under improvised covers a tarpaulin from the waffle stand, the deflated bouncy castle but some simply lay there. Everyone I met displayed a courage, a mental discipline and unity of purpose far beyond anything one would ever wish to expect from people this young. Everyone conducted themselves with an attitude that could almost be described as stiff upper lip . Safely across the fjord we were offered blankets. I was asked if I was aware of any injuries, and asked to lift my shirt and show my abdominal region. We were shown into the bus which took us to the hotel used by the survivors and their family. I simply cannot describe in any words the relief I felt when I was able to embrace my living comrades. It was completely unlike anything I had ever felt before in my life. The euphoric feeling was tempered only by the realisation that there would be many I could never see again, comrades whom I had taken great pride in calling my friends, with futures in the service of all mankind, futures I had previously found such great joy in pondering and guessing about. The feeling which continues to upset me the most, is the feeling that so many of my comrades left behind grieving families and friends. Torn away senselessly. I do not know how much more than this relatively sober account of the events on Ut ya I can muster. I would, however, like to offer some reflections. First of all, from the bottom of my heart, I want to thank the police who saved the lives of so many still on the island, the holidaymakers who took aboard swimmers into their boats and the rescue services staffed primarily by volunteers who have spared no effort in trying to soften the blow as much as they can. The opportunity to spend time with those comrades who underwent the same experience as myself has also been an immeasurable aid. I was also so relieved to find my very closest friend among the survivors, which has also been an indescribable help. If I can name a single positive in this tragedy: Had he arrived with his automatic weapon fifteen or twenty minutes prior, he would have arrived during the informational meeting, at a time when the major hall was absolutely jam-packed the death toll would be many times what it ended up being. I am agonisingly aware of the meager comfort this provides to those who have been bereft of their closest, but I do find some solace in this. We cannot sweep under a rug that this was without question! a political attack on the labour movement. But it is thankfully also an attack which has been perceived by everyone as an attack on the Norwegian society, and on a symbol of the wide recruitment to the participatory democracy which lies at our very national soul. I cannot thank the Norwegian people, and indeed the people in other nations who have offered their condolences, enough for their shows of support and shared grief. It really has been a tremendous help to me knowing that so many people feel with us. I also want to thank from the bottom of my heart the rock-steadiness of everyone in both the national and local wings of the Labour Party and Labour Youth in supporting us, and the political milieu in general for their resolute steadfastness saving me from losing yet more that I cherish; our freedoms in a participatory democracy. Our Party has lost many of its very brightest youngsters. Personally I feel an angry spite, a deep restless urge to get the wheels of society going again. I want to show his kind that we will not be broken. We re stronger than that. I will not be frightened into silence and passivity. I want to remember the dead, and honor them by carrying on our common work. I want to end this with a request to everyone who reads this, echoing a statement I read by one of my good friends and comrades: Please, don t let me see any messages of hatred, wishes for the death penalty, anything like that. If anyone should be of the belief that anything will improve by murdering this sad little person, they would be profoundly wrong. All attention now should be plowed into caring for those victims and their relatives who did not share my luck, and not giving an audience to a perpetrator who wants one. Tore Sinding Bekkedal

why proprietary relicensing is unacceptable for a Free Software enthusiast The past few months have witnessed a large debate about copyright assignment, which seems to has neared its peak around the time Project Harmony has released version 1.0 of its agreement templates. (Note: I use the expression "copyright assignment" in this post, but I'd happily include into it both actual Copyright Assignment Agreements CCAs and Contributor License Agreements CLAs, as both could be used to permit various forms of proprietary relicensing.) Mark Shuttleworth has been one of the most prominent voices campaigning in favor of copyright assignments (to for-profit companies). A couple of interesting blog posts of his where this is evident are "On balancing economic power in the FLOSS ecosystem" and "The responsibilities of ownership". Voices against the opportunity of increasing the popularity of copyright assignments are aplenty and it is pointless to repeat good arguments which I find fully convincing. If you are interested in the subject, here are a few good reads I recommend:

• "Some thougts on copyright assignment", seminal essay (circa end of 2009) by Michael Meeks that provides a good coverage of copyright assignment basics and effects on the surrounding ecosystem
• Richard Fontana's "The trouble with Harmony"; in particular, I recommend taking a close look at "The illusion of constraint" part

What I would like to add to the debate is the point of view of a Free Software enthusiast, not unlike yours truly. I contribute to Free Software not because it is superior to proprietary software in either its software products or in its development methodology. (It actually is superior in many cases, but that's just not my primary motivation.) I do contribute to Free Software to build a world in which users are in complete control of the software they run. Let's assume we have a broken toaster at home. We are all free to (1) open it up and try to repair it by ourselves. If we don't have the needed knowledge, we are free to (2) hand it over to a person that we trust and who does have the needed knowledge to repair it. That failing, we can (3) ask the toaster producer to repair it for us. Many people like me simply don't accept to live in a world where, once all the toasters will be software-driven, the only repair option will be (3), just because the toaster software is proprietary. (Given various kind of [broken] metaphors have been used to explain copyright assignments, it seemed sensible to propose my broken toaster metaphor in exchange.) When I contribute to some Free Software project, I not only care about being able myself to get a Free Software licensed copy of the whole product (i.e. the original software product + my own contribution). I care that all recipients of the product, present and future, will be able to get that contribution with enough freedoms attached to put them in control of the software that includes it. This desire can be fulfilled with a varying degree of success, depending on the license of the code base I contribute to. For instance, I find more pleasant to contribute to a copyleft licensed code base than to a weak-/non-copyleft licensed one, and more pleasant to contribute to an AGPL-ed web app than to a copyleft web app. It also means that, given the option, I will not allow the code base maintainer to re-license my contribution under terms that allow distributing it without suitable freedoms attached. Different contributors will be ready to accept different re-licensing promises, but the mere fact we are debating all this and that companies like Canonical feel the need of campaigning for copyright assignments is evidence that many contributors like me exists and actually have a problem with allowing downstream relicensing of their contributions. What is feared the most is of course proprietary relicensing. According to my moral horizon this is the case not because the company might end up gaining money out of my code: I wouldn't have a problem with that. The reason is rather that the company will be able to distribute my own code in a way that grants less freedoms to users than those that were implicitly "agreed upon" when the contribution has been written. In that respect, I can't help thinking at harmony agreements as a large scale smoke screen experiment meant to convince volunteers that copyright assignments are something Free Software needs. By exploiting the creative-commons-like "it's easy, just choose one" scheme, Harmony takes the chance of offering misleading options such as the one labeled "any OSI approved license". Via that option, which is seemingly fine, the copyright recipient will be allowed to relicense the contribution under some non-copyleft license (e.g. BSD) and from there do essentially what they want. All in all, companies campaigning for copyright assignments seem to have failed to understand two main points. The first one is that contributors motivated by Free Software ideals want the code to remain free not only for themselves, but for all recipients of the code. I'm not claiming that all contributors to FOSS projects belong to this category, but the fact that there is a considerable amount of such people is undeniable. Hoping that they will be fooled by tricks like the "any OSI approved license" agreement is foolish. The second is that while volunteer Free Software communities do respect companies that provide huge amounts of code contributions, they also expect companies to figure out by themselves which business models make their businesses sustainable. Telling volunteers that current business models are not sustainable without proprietary relicensing is worthless. Volunteers just don't care. They want software freedom guarantees and are not willing to renounce to them in exchange of the wealth of companies, not even under the (implicit) threat that otherwise those companies will be forced to reduce the amount of their code contributions.

---

Update: explain in the initial note why my reasoning here encompasses both CCAs and CLAs. Thanks Tollef for noticing that it wasn't clear.

I have turned off comments on my blog - there was too much spam, and I'm not planning to invest the time to fix that properly. On the one hand, this is a shame - it removes an opportunity for other people to respond to what I might write. On the other hand, the idea that this was any kind of two-way conversation was always a badly-maintained illusion. I didn't have any kind of notifications set up to tell me when comments arrived; so I rarely read them, and almost never replied. I don't want to build a commercial enterprise or a "community". So for the moment, if you want to get in touch, email me. If you want to respond publically, write your own damn blog post. :)

The Wrong Answer story from these tales from the interview brings back some memories I ve written this code (well, I got halfway through it before I realised precisely how stupid an idea it was), and I ve counselled more than one developer against trying it again (always unsuccessfully, much to my chagrin and that of anyone who had to deal with it in the future, I m sure). The reason people do it is twofold:

1. It s more fun to write this sort of code than the sort that actually solves a real problem; and
2. Schema manipulation in SQL databases sucks rocks. There s usually limited (or at least painful) introspection capabilities, and manipulating the schema is annoying and usually is deeply balls, performance wise.

If the resources that have been spent building these databases-on-databases over the years were instead redirected into fixing problem 2, above, then it probably wouldn t be a problem any more. On the other hand, problem 1 would still exist, for which the only solution is regular beatings. Remember: always whack your programmers on the back of the head at least once a week. Even if you don t know why, they do.

... or TDDD and DEP8 context As a nice byproduct of the huge "rolling" discussion we had back in April/May, various people have brainstormed about applying Test-Driven Development (TDD) techniques to Debian development. Here is a brief summary of some opinions on the matter:

• a seminal conversation on identi.ca
• a couple of blog posts by Lars, discussing the general problem of how to use TDD in distribution development and to a lesser extent its instantiation to Debian
• a separate post by Daniel stressing the specific TDD advantage of increasing the confidence of maintainers in making far reaching changes

... and hey, they've also coined the cool TDDD acronym, which I hereby took the freedom to re-target to Test-Driven Development in Debian. Having a cool acronym, we are already half-way to actually having the process up and running *g*. more testing I believe Debian needs more testing and I've been advocating for that since quite a while e.g. at DebConf10, as one of the main goals we should pursue in the near future. Of course advocating alone is not enough in Debian to make things happen and that is probably why this goal has been (thus far) less successful that others we have put forward, such as welcoming non-packaging contributors as Debian Project members. There are important reasons for increasing testing in Debian. quality assurance Quality Assurance has always been, and still is, one of the distinctive traits of Debian. I often say that Debian has a widespread culture of technical excellence and that is visible in several places: the Debian Policy process, lintian, piuparts, periodic full archive rebuilds, the EDOS/Mancoosi QA tools, the cultural fact that maintainers tend to know a lot about the software they're packaging rather than only about packaging, the we release when it's ready mantra, etc. But caring about quality is not a boolean, it's rather something that should be continuously cherished, refining quality requirements over time. By simply maintaining the status quo in its QA tools and processes, Debian won't remain for long a distribution who could claim to care about package quality. Others will catch up and are in fact already doing that. In particular, we surely have room for improvements in our quality tools and processes for:

• Build time package testing. Several packages run their build-time test suites during package build. This aspect is somewhat supported by the Debian policy; we also do a best effort attempt to run build-time test suites via debhelper (starting from version 7). At the same time we could probably campaign more to encourage maintainers to look for build-time test suites which do not follow common Makefile target naming or, fwiw, which don't rely on make at all. TodoList.add("investigate and possibly file bug report against policy to encourage maintainers to run build-time test suites")
TodoList.add("investigate and possibly file bug report against lintian to spot the presence of [non-invoked] build-time test suites")
• Runtime package testing (AKA "as-installed package testing"). Some kinds of test-suites are difficult to run at build-time (e.g. complex applications that don't offer easy way to re-configure on the fly their filesystem paths) and some others are plainly impossible to run without having the packages to be tested properly setup (e.g. running services that are accessible only through the network) or an isolated, throw-away testbed (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not currently in use neither in Debian nor, indirectly, in any of its derivatives. autopkgtest (AKA DEP8) is a step in this direction; I will get back to it later on in this post.
• Integration testing. When applied in the context of distributions, integration testing is about testing package combinations, task (as in tasksel) combinations, basic system functionalities, automated installations, etc. This is the aspect that Lars has discussed the most (and in which he seems to be interested the most) so I don't feel like adding much. Still, it's interesting to note that on this front Debian has an important potential to exploit. The large base of its developers and the fact that the average Debian user is technical savvy mean that we can potentially collect a lot of test cases. It's "just" (with well-deserved double quotes) a matter of deciding a standard interface for test case submissions and developing a most likely virtualized test runner. At that point a continuous integration service that periodically run and publishes results can be setup independently from the rest of the Debian infrastructure and offered to interested eyes, such as Release Team's. Any taker?
• Automated code analysis and in particular automated bug finding is something which is becoming more and more common and finally, after decades of research viable. Successful proprietary tools and businesses are aplenty (a nice and very fun read on the subject is the story of Coverity), as well as FOSS solutions. For instance, the Linux kernel is routinely using Coccinelle to automatically find bugs and even produce the corresponding patches. Add to the above the fact that Debian is one of the largest software collection in existence (and quite probably the largest collection of Free software in existence) and is upstream of the packaging of that software for the most part. That turns Debian into a very peculiar platform for large scale automated code analyses. Not that we can aim at fixing all the bugs we are going to find, or even hope to tame all the false positives we are going to find. But we can offer an important service to the whole ecosystem of Free software and use it to pinpoint important class of bugs from a distribution point of view, such as nasty security bugs (as long as they can be automatically found ). DACA is a very good step in the right direction, even though it is still in its infancy.

reducing inertia Inertia is a recurring topic among Debian lovers (and haters). It is often argued how difficult it is to make changes in Debian, both small and large, due to several (alleged) hindrances such as the size of the archive, the number of ports, the number of maintainers that should agree before proceeding with a cross-package change, etc. It's undeniable that the more code/ports/diversity you have, the more difficult is to apply "global" changes. But at least for what concerns the archive size, I believe that for the most part it's just FUD: simply debunking the self-inflicted culture about how "dangerous" doing NMUs is might go and has already gone, imho a long way to fight inertia. Adding per-package and integration tests will make us go another long way in reducing inertia when it comes to performing archive-wide changes. Indeed if a package you are not entirely familiar with has extensive test suites, and if they still pass after your changes, you can be more confident in your changes. The barrier to contribution, possibly via NMU, gets reduced as a result. And if your change will turn out to be bad but still not spot by the test suites, then you can NMU (or otherwise contribute) again to extend the test suite and make the life easier for future contributors to that package. It smells a lot like an useful virtuous cycle to me. autopkgtest / DEP8 how you can help Of all the above, the topic that intrigues me the most is as-installed package testing. Work on that front has been started a few years ago by Ian Jackson when he was working for Canonical. The status quo is embodied by the autopkgtest package. At present, the package contains of various tools and the following two specs:

1. README.package-tests provides a standard format to declare per-package tests using the new debian/tests/control file. Tests come as executable files which will be run by the adt-run tool in a testbed where the package(s) to be tested is already installed. This part of the specs has been reified as DEP8 which I'm (supposedly) co-driving with Iustin Pop and Ian (for well-deserved credits).
2. README.virtualisation-sever describes the interface among the test runner and the testbed. A nice separation is provided among the runner and the testbed, enabling different testbed environments with a varying degree of isolation: you can have a "null" testbed which runs tests on your real machines (needless to say, this is highly discouraged, but is provided by the adt-virt-null tool), a chroot testbed (adt-chroot), or a XEN/LVM based testbed (adt-virt-xenlvm).

The specs allow for several runtime testing scenarios and look quite flexible. The tools on the other hand suffer a bit of bitrot, which is unsurprisingly given they haven't been used much for several years. At the very minimum the following Python development tasks are in need of some love:

• The usage of python-apt needs to be ported to recent API, as several used methods and attributes are now gone.
• Porting from dchroot to schroot is needed for the adt-virt-chroot backend.
• A kvm backend for the test runner would be nice.

If you are both interested in TDDD and grok Python, the above and many others tasks might whet your appetite. If this is the case don't hesitate to contact me, I'll be happy to provide some guidance.

---

Note: this post is the basis for the TDDD BoF that I will co-host with Tom Marble at DebConf11. If you plan to come, we will appreciate your thoughts on this matter as well as your help in getting the autopkgtest toolchain up and running again.

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004. He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details. Raphael: Who are you? Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK. I ve contributed to various free software projects over the years but Debian is without doubt the one I m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source Program Office and work on various free software and open source activities, both internally and within the community. Raphael: How did you start contributing to Debian? Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities. I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project. Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk. Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities. Raphael: What s your biggest achievement within Debian? Martin: I m particularly proud of a number of achievements:

• New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
• Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
• DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
• Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help? Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong. So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists. There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices. A bigger problem is that while we ve implemented a great solution for NAS devices, we haven t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI. Raphael: What are your plans for Debian Wheezy? Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian s money and other assets are held by affiliate organizations around the world. My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months. Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support? Martin: First of all, I should make it clear that I don t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I ll just make sure that procedures are followed and expenses tracked and reported properly. Having said that, in my opinion, it s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one and there are many other efforts that are worth promoting if you promote one, where do you stop? So while it sounds worthwhile, it s probably better for Debian to stay out of it. But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE. Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian or people start a family and no longer have time. I can take myself as an example since I don t have nearly as much time as I did in the past when I was a student. I guess there are different ways to deal with this problem one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don t have the answers to these questions but it s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors. Raphael: What motivates you to continue to contribute year after year? Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It s amazing how much I ve learned about other cultures because of my involvement in Debian and how many friends I ve made over the years all around the world. Raphael: Do you have wishes for Debian Wheezy? Martin: Not really. I m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I m particularly pleased about the plans to adopt a time-based freeze. Raphael: Is there someone in Debian that you admire for their contributions? Martin: There are many people I admire greatly. I d like to mention Joey Hess because he s a great example to follow. He doesn t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

---

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

Our adventurous friends Eric and Katie had invited us to join them on a hike in the Grand Canyon over the 4th of July weekend. As this struck us as something we'd never have considered doing otherwise, we thought we'd accept their kind offer. We're so glad we did. It was quite a bit of traveling just to get there. We flew out of San Jose on Thursday night, got into Las Vegas, rented a car, and then drove to Peach Springs, Arizona, where we stayed the night. We didn't get in at the Grand Canyon Caverns Inn until around midnight, and we had to get up again for a 5:00am departure (I think we actually got away by more like 5:30am), to drive to the Hualapai Hilltop, where the trail head was. Zoe handled all of this very well. She didn't end up falling asleep in the car until about 10:30pm I think, and dealt with the transfer out of the car at midnight very well and went back to sleep. The drive to the Hualapai Hilltop, along Indian Road 18, took about an hour. We had to dodge a bit of livestock on the road. The road itself was sealed and of good quality. We remarked on the way back out that as soon as you left the Havasupai Reservation and entered the Hualapai Reservation that there was a distinct degradation in the quality of the road. We parked at the Hilltop, and got ourselves organised, and commenced our descent by about 7:10am. The first 1.5 miles was very steep. There were a bunch of switchbacks and there was a fair few people coming up the other way already. There were also a few mule trains coming in the opposite direction that we had to dodge. The mule trains have right of way, so we had to stop and get out of the way to let them pass. Zoe thought they were pretty cool because they invariably had a few dogs with them as well, and she thinks dogs are awesome. The remaining 6.5 miles (it was an 8 mile/13 kilometre hike in total) were fairly easy. There was a lot of variety in terrain. Rocks, sand, dirt. It wasn't all in the sun, which was made it more comfortable. Heat wise, I think it was in the high 30's Celsius, with pretty much no humidity, so it didn't feel too uncomfortable. Towards the end, as we got near the water, there was a distinct change in the canyon. There was more greenery, and we started hearing insects and seeing bird life. When we first saw the water, it was hard not to just jump in, it looked so inviting. The total hiking time was about 4 hours 45 minutes, which included a reasonable stop to give Zoe some breakfast. We arrived in the village at around midday. Unfortunately the lodge wasn't ready for check ins until 1pm, so we had to twiddle our thumbs for a little bit. Zoe handled the hike incredibly well. We used a Macpac Possum child carrier that Nigel had passed down to us, and she didn't complain the whole time. She even took a nap in it. We were very relieved that it wasn't a problem for her. Sarah carried her, and I carried everything else. (I'm so glad I didn't see the photo of how I looked until well afterwards). In hindsight we probably brought too much stuff, but we didn't really know what to expect down there, so we'd rather have too much than too little. The village completely exceeded my expectations. I had this (silly) mental picture of it being just the lodge and not much else, but somewhere between 450 and 700 people live in the village. It had two general-type stores, a cafe that was pretty much like a fast food/takeaway place, an elementary school, and some sort of basic medical clinic. There was also a small general purpose community centre of some sort. The main store had pretty much everything you'd need in the food department. The cafe frequently ran out of various different things, but you weren't going to go hungry. For the remainder of Friday, we just stayed put in the village and let Zoe stretch her legs. Eric and Katie and their kids explored the first set of falls down from the village, unofficially named Rock Falls. On Saturday, we all hiked down to Havasu Falls. We met a couple of other families (amusingly both from the Bay Area) along the way, so we had some interesting conversations. I have no idea how long the hike was. Havasu Falls was impressive. Quite tall and narrow at the top, and quite loud. Zoe was impressed. We took her for a bit of a swim in the pools in the bottom. We had lunch there, and then Zoe and Sarah stayed there (Zoe took a nap in the KinderKot (also courtesy of Nigel) in the shade by the falls, and I took the Macpac with a water bladder in it to refill it at the spring in the campground, which was further down stream, and to check out Mooney Falls with Eric and Katie (and their kids), which was further downstream again from the campground. Mooney Falls was pretty insane. A lot taller than Havasu Falls, and a lot more treacherous to get to the bottom of. Parts of it were vertical. Chains and rickety ladders were involved. Caves were involved. I'm so glad I didn't have Zoe in the Macpac, because on multiple occasions, the top of it got bashed into rocks, so without having Sarah with me also to act as a guide, there's no way I could have safely descended with Zoe in the backpack. My favourite photo illustrating how crazy this was is this one that I took of Eric and Katie. This photo highlights some of the craziness involved to get down. I pretty much got to the bottom, had a quick look around and left Eric and Katie to it, because I figured Zoe would have woken up by now, and was probably bored. Turned out I had all of the sunscreen with me as well. So I climbed back up, and trekked back to the campground, refilled at the spring, and headed back up to Havasu Falls. After we reunited, we then hiked back up to the village, which to be honest, was the hardest bit of hiking we did. I was carrying Zoe in the Macpac, and it was hot, and it was mostly loose sand all the way. We were very glad to get back to the village. Zoe started showing signs of coming down with a cold and a cough, so we decided to cut short our stay in the village and leave on Sunday instead of Monday. We'd been tossing up between getting a helicopter or horses out. We ended up opting for the helicopter after learning that the horses still took about 3.5 hours, and you basically had no control over the animal. We were dubious as to how Zoe would go being bounced around on the back of a horse for that long. The helicopter ride also took all of about 5 minutes. The tribal members get first dibs on the helicopter, and there had been a death in the village, and I think a lot of people had come to the village for the viewing (the casket itself was flown out earlier on Sunday morning for a burial out of the village), so I suspect there was a higher number of tribal passengers than usual. We didn't get out until 2pm. Again, Zoe was incredibly good. She just hung out with us while we waiting for a flight out. There were plenty of dogs for her to be entertained by, and some other kids. She also took a pretty decent nap. So we finally got out, and got back to our car, and then the heavens opened. It absolutely poured down with rain. Sarah was keen to check out Hoover Dam, so we decided to stay near Boulder City in Nevada, and got a suite in the Hacienda Hotel and Casino for cheap. The next day was the Monday public holiday for Independence Day, and we were tossing up whether or not to take Zoe to a doctor to get her checked to see if she had bronchitis (we've been a bit gun-shy about bronchitis since the time she came down with it when we were in Australia). She ended up falling asleep in the car while we were hunting around for an Urgent Care facility that was open, so we decided to let her sleep and drove to Las Vegas. After she woke up, we took her to see the flamingos at Flamingo and the lions at MGM Grand. Zoe absolutely loved all the lights, sights and sounds of Las Vegas. In the afternoon, we took her to a doctor, and got the "first child, huh?" from the doctor (she didn't have bronchitis). After that, we went and briefly checked out Hoover Dam (just walked half way across the bridge in front of it and walked across the dam itself). The following day, we packed up and spent the morning on the Las Vegas strip again. This time we went to the Venetian (Zoe thought the gondolas were pretty cool) and then we flew out in the afternoon. So it was a lovely little family vacation. We ended up spending about as much time in Las Vegas as we did in the Grand Canyon, but that was okay. I'd really like to go back to Supai again, but I'm not sure if the stars will align themselves appropriately. If we did, knowing what I know now, I'd take a lot less food and put all of the luggage on a horse, and just hike in with the minimum of stuff. I'd probably be game to hike out as well if the bulk of the luggage was on a horse. Photos from the trip are here.

Short version arrival was quite easy, the arrival wiki page is now up-to-date and my photos are uploaded every day to this Flickr set. I had a small problem departing from CDG to Zagreb after scanning my suit twice and complaining that it had too many electronic devices, they had me remove my Nexus S, Nokia N950 and Kindle 3 from the suit pockets and then scanned that all lot again. After that another security guy asked me to open my suitcase and started squishing my Ligo cheese and declaring in a grave voice that it was too soft to be legal . As I kept calm and explained the DebConf cheese party to him, he looked around, put the cheese back in the bag and said ok, ok, off you go . So I still have that softness for the party. I heard an even better anecdote from our next years hosts when they were travelling trough Germany, a border official asked a typical so, what are you here for? question. They answered that they were in transit for an IT conference and gave him the invitation letter. He read the letter, nodded and then said: DebConf, huh? So, who was the author of the Linux kernel? and when after the initial shock they gave the right answer, they were immediately waved trough. Now that s what I call good border security. I met up with the guys in the Zagreb airport caf , which was immediately after exiting the secure zone. We waited for dkg to arrive and get his baggage. The passport check too a couple of minutes, but the baggage claim looked to be taking almost a half an hour. After that was sorted out, we took out some local money in one of the 5 ATMs around and went to the bus. We were waived to just put our bags into the bus luggage space and get on, the driver went around to sell us tickets just before we drove off. It was one of the most comfortable and well air-conditioned buses I have been on in a long time. We were in the Zagreb bus station in less than half an hour. Then a funny part started an old man came up to dkg and immediately asked Are you going to Banja Luka? , and when he said yes, the man started dragging us along to the bus station saying that there is a bus to there that will leave in a couple minutes, but we were in luck, so we should follow him right to the bus. Driven by curiosity, we went on. The man dragged us to the far side of the bus terminal bus stops where there was a minibus with Bosnian number plates, but no official designation as a passenger transit bus and no other passengers. They asked a reasonable 120 kuna for the trip, but they looked very shady to me, so we refused. I think that if we agreed and we were lucky enough that they actually did get us to Banja Luka, the price would have risen along the way, for example using the highway tolls as an excuse. After getting cursed at by the old man and being demanded to buy him a beer for his efforts, we went upstairs to the real bus station where we were told that there were two buses to Banja Luka: one at 15:00 and another at 16:30, but that those two buses arrive in Banja Luka almost at the same time, so we got us tickets for the latter bus and went to a local bar to get some food and drinks. I somehow managed to get sausages in deepfried bread that for some reason cost almost triple of a hamburger and fries that others got, but it sure helped to pass the time and after all those 9 was not a bad price for a good meal. We were a bit surprised by the bus drivers asking us to pay 1 (or 8 kuna) for bags to be put into bus bag storage, especially as we for several minutes could not quite understand what they want of us as neither of them spoke either English, Russian or German. I don t remember when was the last time I crossed a real (i.e. non-Shengen) border in a bus, so getting out of the bus and walking one-by-one to the border official was a new experience. On the other border of two bus drivers collected the passports an then brought them back later, so that was less painful. And by then we were in Bosnia! And of the things that greeted us was a billboard for the casino in Banja Luka Hotel Bosna. By the time we got to Banja Luka, dkg had already made friends with an official from Croatian ministry of regional development that sat behind us on the bus and knew English very well (after living in Canada for some time). The bus station in Banja Luka looked almost abandoned like the bus stopped in the field with only a few taxi drivers and a bunch of buildings some distance away showing that this was indeed part of civilization. The taxi drivers would take you to the venue for 8-10 KM 5 or 50-100 kuna (if their meter is broken and you look to be really ignorant of the exchange rates). If you walk on a bit, there is a bus station with an ATM taking Visa cards and a bit further on a bus stop that will take you to the centre of the city for 1.5 KM. The train station looked fully abandoned when we went there, only a news kiosk was working there. The bus driver reacted well to the name Hotel Bosna and wave toward it when we passed by it. It is hard to miss, especially the blinking Casino sign or the white pillars with black letters Hotel Bosna on top. You just get off at the bus station Central and walk back a couple hundred meters. Then see all you Debian friends drinking in the cool bar and walk around the corner to the main entrance of the hotel to check in. The rooms are looking really great this is the best DebConf location that I have been to (I was not in Argentina). Soft beds with linens changed daily, nice air conditioning, towels (changed daily, if used), good shower, It is lacking in the speed and power of its free WiFi and in some place there is a clear impression that the hotel was built as a top of the line hotel a couple decades ago, but somehow has fallen into a disrepair since. Or it is simply used much more than expected. So far I would say that the DebCamp is running full steam two hacklabs have desks, chairs, power and network connection, one of them even has sufficient air conditioning. The network works great for me so far, at least in the venue. The hotel wireless is barely usable to read a blog post, preferably without photos. The food is being served well and on time. So far for lunch and dinner you walk up to the reception and get a food ticket based on your room number and go to the M level for the food (the M level is between the ground floor, labelled as PR , and first floor) where for breakfast and dinner there is a buffet, but for lunch you sit at a table and they bring you food. Vegetarians should clearly say vegetarian while pointing at themselves to get the special vegetarian option. So far food has been very good, except that that they often run out of popular items, such as fries, in the buffet. You can also ask for beer and other extra drinks with your food, but know that they cost extra up to 2.5KM for a beer, for example.

On the bus heading to the airport to go to DebConf 11, I chanced to sit down beside an older Croatian gentleman. If I've ever met another Croatian living in Portland before now, they did not have occasion to make themselves known to me. He spoke highly of Tito at some length, and of Tito's success at holding the Russians at bay in the 1960s when the rest of the Communist block was being held there by the thumb of the Russian military. If I've ever met another person living anywhere who approved of Tito, they've not had occasion to make that opinion known to me either. Wacky experiences like that are why I love Portland's mass transit network.

I would have probably dismissed as not realistic enough for even The Daily Show this kind of story, had someone suggested it a few months ago: Rupert Murdoch s corporation (owner of FOX News, Wall Street Journal, News of the World, etc) would have been found to have illegally accessed other people s voicemails. These included voicemails from a cellphone belonging to a recently-murdered girl, which interfered with the police. And they had also bribed Scotland Yard officers for information, and actively covered it up. The story would close one of Britain s biggest newspapers, and force the resignation of various government and Scotland Yard officials. That it would lead to the first high-profile investigation under the Foreign Corrupt Practices Act of an American corporation bribing British officials. That one of the central figures in the scandal would suddenly die at a young age. That there was a question of how the former editor of Murdoch s newspaper whom he steadfastly defended until one day he didn t would be taken from jail to testify before Parliament. That CNN would live stream a hearing of a British Parliamentary subcommittee instead of the news conference given by the President of the United States. And that during this committee hearing, some guy would attack Rupert Murdoch who, until then, looked like he had a few drinks too many the night before with a shaving cream pie. And that Rupert Murdoch s newspapers and TV channels would portray News Corp. as a victim of the liberal press in all this, and that they should just be left alone. So maybe the last one was believable, but my goodness. Just when it couldn t get any stranger, a SHAVING CREAM PIE?!

See previous post for the rationale. I ve then started migrating my mail using evolution. First I ve installed dovecot and set it up so as to store my mail inside my $HOME/Maildir/ dir. Evolution will run dovecot on demand through a pipe, instead of through network access like with regular remote IMAP servers. So dovecot won t be started as a daemon. I ve been inspired by Roland s setup for this (even though I not using offlineimap). Inside Evolution, I ve configured a second mail profile, for this local IMAP server, using the custom command to connect to server :
"MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap" I ve migrated my existing mail folders using copy to function on all top-level mail folders from the local evolution storage, to copy them to the IMAP folders. Note that some folders that include a dot ( . ) need to be renamed, as the dot is a path separator for IMAP. I ve adapted Evolution s vfolders definitions so as to take into account the active remote folders instead of the local ones, and that s it, the mail is migrated. I m using fetchmail + procmail to fetch mail from remote servers and to deliver it to the Maildirs, using dovecot s deliver program, with something like : DELIVER="/usr/lib/dovecot/deliver" :0: w
$DELIVER I ve migrated the filters of evolution to server-side Sieve rules so that dovecot s deliver sorts incoming mail in the right Maildirs. The dovecot config needs to be adapted to activate the sieve plugin (dovecot-sieve Debian package), in /etc/dovecot/conf.d/15-lda.conf : protocol lda
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
log_path = /tmp/dovecot-deliver-errors.log
info_log_path = /tmp/dovecot-deliver.log

The original Evolution filters rules were stored in $HOME/.config/evolution/mail/filters.xml, so I wrote a quick python DOM parsing tool to extract the (long) list of definitions and generate Sieve rules for the $HOME/.dovecot.sieve config file (in which folder hierarchy uses a . path separator instead of a / ). The sieve-test program can be used to check is sieve rules function as you want. Now this is all setup, I only need to configure notmuch to index all the Maildirs. But this is left to another post.

When I recently switched my blog over to Jekyll as my blog/site generation platform, one of the driving forces was implementing comments. I ve been a comment-free blogger for years, but I ve just decided to change my opinions on things and see what happens. (Turns out: you get some cool comments. And a lot of spam.) However, the standard advice when it comes to handling comments with Jekyll is use Disqus (or, very occasionally, some other Insert-Javascript-Here cloud commenting service). Not being one to stand for the conventional wisdom, and given that I m allergic to the cloud , I decided to go a different way an all-static comment handling system for Jekyll. First off, you need a way to render comments inside Jekyll. This was disturbingly easy with Jekyll s plugin system. With around 30 lines of Ruby, it was done. It simply reads a pile of YAML files from a _comments directory, and adds them to the individual blog post objects in the templating system, which can then be iterated over when rendering a post. Obviously, you need to also adjust your blog post templates to suit. This is fairly straightforward; just render each of page.comments in a list. Adding a comment submission form is also necessary, and similarly trivial. The only moving part in this whole system is the bit of code that handles comment form submissions. The simplest way to handle it, which is what I ve gone with, is a few lines of PHP that writes the contents of the form out as YAML and e-mails it to me. Although I m not a fan of PHP for web applications, this is sort of job is where PHP excels it s ubiquitous, trivial to deploy, and easy to understand (in small doses). Using a CGI or anything larger (like, say, a sinatra app) would be massive overkill. Since I m still a control freak at heart, I m hand-moderating all comments by the simple expedient of having all blog comments e-mailed to me¹, and I have to import them into the blog and re-upload. Mutt makes this trivial; I ve got a script that I trigger by pressing C (for comment) that pipes the message to formail to strip the RFC2822 header, then drops the rest into my blog s _comments directory. A quick rake upload and they re published. If you re not as obsessive as me about hand-moderating your comments, it wouldn t be hard to write a slightly different PHP script that commits the comment directly to a git repo² and re-renders the site. All you d have to do when you wanted to make a new post is merge those new comment commits from the live git repo and go to work. This would then be a completely static site (with all the performance benefits that implies) with immediate-gratification comments. So, if you re suspicious of the cloud, or just want to be the cool kid whose blog comments load even when people have turned cookies off, check out my Jekyll static comments plugin.

We already studied one weird error of dpkg, let s do another one:

Unpacking replacement libexo-common ...
dpkg: error processing /var/cache/apt/archives/libexo-common_0.6.1-1_all.deb (--unpack):
 unable to open '/usr/share/doc/exo/html/C/images/exo-preferred-applications-internet.png.dpkg-new': No such file or directory

Rather difficult to understand on the first look right? Let s see in detail what s usually happening when you get this error. The first hint comes from the file extension .dpkg-new . This extension is used by dpkg to unpack the updated files near the old files. When everything has been unpacked, they are renamed over the old files. The failure happens precisely when dpkg tries to rename the file (in fact when it tries to fsync() it before the rename) but why does it fail? Usually because there are unexpected symlinks (or bind mounts) involved that resulted in two different files being installed in the same directory. For example consider package that provides /dir1/a-file and /dir2/a-file. Now imagine that on the target system, /dir1 is a real directory but /dir2 is a symbolic link that points to /dir1. When dpkg processes /dir1/a-file.dpkg-new everything is fine, but when it tries to process /dir2/a-file.dpkg-new it will fail because that file is the same than /dir1/a-file.dpkg-new which has already been renamed. Diagnosing further the problem requires to understand why there s a symlink instead of a real directory. It might be two packages that were badly coordinated, or a problem in the package itself because it lacks some code that drops the symlink in the preinst (so that dpkg installs the real directory instead of keeping the symlink). There might be variations in the way two files end up sharing the same directory, but this simple example should have clarified the nature of the underlying problem.

Subscribe to this blog by RSS, by email or on Facebook.

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

Keeping an eye on something with a webcam is really easy: just a matter of setting up for example (c)vlc to multicast from /dev/videoX to the network, and done. Example:

# Streaming:
cvlc v4l2:///dev/video0 --no-audio --sout "#transcode vcodec=mp2v,vb=3072 :std access=udp,mux=ts,dst=224.0.0.1 "
# Playing, possibly on a remote machine:
vlc udp://@224.0.0.1:1234

Notes:

• v4l2 vs. v4l depending on the distribution (sid vs. squeeze).
• Triple slash needed, two for the v4l[2]:// part, one for the device (/dev/video0).
• Why this address? See Wikipedia s Multicast address article.

Possible problems:

• If switches don t have IGMP snooping enabled, throwing multicast at them turns it into plain broadcast. In other words: instead of having packets sent to the hosts subscribed to that multicast address, everyone gets those packets, polluting the network.
• Trying to stream from multiple devices may fail, due to USB bandwidth issues. At least that can be seen with two random devices using the uvcvideo module, getting No space left on device when the second (c)vlc is started.

Where to go from here:

• fswebcam to the rescue! It can capture a frame from a given device. The following options are particularly useful: --resolution to request a specific resolution (the device will fall back to another resolution if the requested one is unavailable); --frames to specify the number of frames to capture (lower noise, but possibly higher blurriness).
• A tiny python wrapper around it makes it possible to set various webcams, with different options (number of frames, delay between two captures, resolution), operating at the same time thanks to the help of the threading module. To avoid encountering the same bandwidth issue, a tiny lock ensures a single fswebcam instance runs at a time.
• That also makes it possible to save all images as videoX-timestamp.jpg and to log rotate them after a while, for further viewing/reviewing during a given time window.
• Thanks to ImageMagick, it s also trivial to process the captured images:

  # Only keep a rectangle of width W, height H, starting at the point (X,Y):
  convert -crop WxH+X+Y capture.jpg capture.jpg
  # Include a timestamp on the top-left corner:
  convert -box white -font Fixed -draw "text 2,12 \"$timestamp\"" capture.jpg capture.jpg
  

• Keeping a videoX-current.jpg symlink for each /dev/videoX device is trivial.
• Add to that a lightweight webserver and a single page showing the most recent capture for each device thanks to the symlinks, with a meta refresh of say 5 seconds, and tada! Keeping an eye on multiple things at once. Of course that s not a real video, but that can fulfill some needs.

Right now I am sitting in the train to the airport for going to DebCamp/DebConf 11 in Banja Luka, Bosnia and Herzegovina. During DebCamp amongst other things I am going to work on finishing up the last bits on getting daily/weekly Debian Live autobuilds back for wheezy. This spring Jimmy Kaplowitz offered to help with the task of overseeing the debian-live autobuilder and to coordinate necessary bits with cdimage.debian.org. Having them on cdimage.d.o became recently possible as Steve McIntyre offered to make a VM available for us (live-build requires root privileges, and naturally, you would not want to let that run on the host system itself, that is why in the past it was not possible to build them on cdimage.d.o). The remaining issues are, and this is why the autobuilds are not yet back since spring, that live-build still needs two things: a couple of tweeks for wheezy, and the autobuild stuff need to be properly integrated into live-build itself. That will happen as an additional binary package live-build-cron with a bunch of debconf questions, so that everyone and his dog can setup a debian-live autobuild server on his own machine. The initial upload (which will not yet work, do not bother to try) was uploaded to experimental this week and cleared the new queue, now looking forward to get this all finished up and resulting in a live-build uploaded to unstable by the end of the week. In the second week, Jimmy arrives, I will be introducing him to live-build and the various little things to watch for and hopefully manage to persuade him to take over the autobuilds maintenance. Having all images that are based on packages solely from the stable/testing/unstable archives moved to cdimage.d.o is freeing up ressources on live.debian.net which did the job in the past since etch. Ben Armstrong volunteered to help with overseeing the live.d.n instance of live-build-cron that will build more then once per day images for si, with the only difference that they will not use live-* from the archive but the latest snapshots from our git snapshots repository. This will be a big help for the development as eventually we will be autotesting these images for various things. Last but not least, thanks to both Jimmy and Ben for all your kindness, patience and help with this during the last couple of months. We have interesting times ahead.

Recently I was at a pub and there was an advert for pub tokens displayed on the window. Seemed like a cute idea:

• Buy & donate tokens which can be spent (only) on beer.

Perfect for friends, family, remote hackers/developers & similar. When I got home I checked out their site. Seemed simple and nice enough, with good coverage (in terms of local drinking establishments that would accept their tokens). I decided to sign up, with the intention of gifting my sister with some delicious beer. Unfortunately that's where it all went wrong. I tend to act the same on all new sites. Partly to amuse myself, partly to get a feel for how safe/secure/good the site is, I'll try to login with a few different values. You know you're in trouble when you see responses like this:

SELECT * FROM cms_module_pubtokens_users where email = '"'' AND
   password =''"' LIMIT 1
Fatal error: Call to a member function FetchRow() on a non-object in
  /home/pubtokens/U79P18WQ/htdocs/includes/functions.php on line 291

Suffice it to say I sent them an email, then poked them on twitter, but to no avail. In conclusion they don't get my money, and I couldn't recommend them to anybody else at this point either. As I'm not a customer at least I can rest easy knowing my details haven't been compromised at any point over the past few months. ObQuote: "It can't rain all the time" - The Crow

For those of you that aren t familiar, please read about the Eternal September, which refers to the lasting damage to a community when vast numbers of newbies suddenly enter and dramatically harm the quality and usefulness if discussions.

• Email: 24 years
• Usenet: 13 years
• Facebook: 2 years
• Google Plus: ?

Sanjog Misra, who uses Rcpp for Monte Carlo Markov Chain (MCMC) analyses in quantitative marketing, kindly set me a short example of Rcpp use. The example is based on a blog post by Darren Wilkinson which itself discusses and compares the suitability of R, Python, Java or C for MCMC analysis, using the Gibbs sampler as a concrete example. Darren's post is worth checking out: he stresses the rather pragmatic aspects of how fast and/or easy it is to write the code, rather than just the mere runtime. As such, he is not too concerned with a speed advantage of Python over R which he sees at a factor of around 2.4, leaving him to continue to prototype in R. Similarly, with C 'only' being faster than Java by a factor of two, he prefers Java for the numerically more demanding parts. We do of course advocate the use of Rcpp to combine the best aspects of R and C++, respectively. This Gibbs sampler example provides a nice backdrop. So working with Darren's example, consider the same Gibbs sampler for a bivariate distribution (and apologies for the lack of latex typesetting on my blog)

f(x,y) = k x^2 exp( -x y^2 - y^2 + 2y - 4x)

where the conditional distributions are

f(x y) = (x^2)*exp(-x*(4+y*y))               ## a Gamma density kernel
f(y x) = exp(-0.5*2*(x+1)*(y^2 - 2*y/(x+1))  ## a Gaussian kernel

Sanjog then spotted and corrected a small error in the variance expression in Darren's derivation; this is now acknowledged on Darren's website. Full details are in the R script now committed in SVN. The R code for the Gibbs sample can therefore be written as follows below. Note that this uses thinning to minimize serial correlation in the conditional densities--which renders the computation more demanding as 'N times thin' draws have to be generated:

## Here is the actual Gibbs Sampler
## This is Darren Wilkinsons R code (with the corrected variance)
## But we are returning only his columns 2 and 3 as the 1:N sequence
## is never used below
Rgibbs <- function(N,thin)  
    mat <- matrix(0,ncol=2,nrow=N)
    x <- 0
    y <- 0
    for (i in 1:N)  
        for (j in 1:thin)  
            x <- rgamma(1,3,y*y+4)
            y <- rnorm(1,1/(x+1),1/sqrt(2*(x+1)))
         
        mat[i,] <- c(x,y)
     
    mat
 

A second variant can be computed using the R bytecode compiler which appeared with the recent release of R 2.13.0 (and which we analysed in this blog post from April). This is as easy as

## We can also try the R compiler on this R function
RCgibbs <- cmpfun(Rgibbs)

Thanks to Rcpp and the inline package, we can also write a C++ variant that can be built and launched from R with ease. The C++ code is assigned to an R text variable gibbscode. (And we used to typeset such code on the blog as a character string, ie in a faint red color---but have now switched to highlight it as if it were freestanding C++ code. It really is passed as a single string to R which then uses the cxxfunction() to compile, link and load a C++ function built around the code. See previous posts on the inline package for more.)

## Now for the Rcpp version -- Notice how easy it is to code up!
gibbscode <- '

  using namespace Rcpp;   // inline does that for us already
  // n and thin are SEXPs which the Rcpp::as function maps to C++ vars
  int N   = as<int>(n);
  int thn = as<int>(thin);
  int i,j;
  NumericMatrix mat(N, 2);
  RNGScope scope;         // Initialize Random number generator
  // The rest of the code follows the R version
  double x=0, y=0;
  for (i=0; i<N; i++)  
    for (j=0; j<thn; j++)  
      x = ::Rf_rgamma(3.0,1.0/(y*y+4));
      y = ::Rf_rnorm(1.0/(x+1),1.0/sqrt(2*x+2));
     
    mat(i,0) = x;
    mat(i,1) = y;
   
  return mat;             // Return to R
'
# Compile and Load
RcppGibbs <- cxxfunction(signature(n="int", thin = "int"),
                         gibbscode, plugin="Rcpp")

It is noteworthy how the code logic is essentially identical between the basic R version, and the C++ version. Two nested loops control draws of x from a Gamma distribution, conditional on y, as well as draws of y from a Normal, conditional on x. Add a small amount of parameter passing to obtain the parameters N and thin, allocation of a results matrix and setup of the random number generator state to remain consistent with R, as well as a return of the matrix---and that is all. As Darren's code uses the GNU GSL in its C variant, I also became interested in seeing how a C/C++ hybrid variant using our RcppGSL package would fare. The code is below.

gslgibbsincl <- '
  #include <gsl/gsl_rng.h>
  #include <gsl/gsl_randist.h>
  using namespace Rcpp;  // just to be explicit
'
gslgibbscode <- '
  int N = as<int>(ns);
  int thin = as<int>(thns);
  int i, j;
  gsl_rng *r = gsl_rng_alloc(gsl_rng_mt19937);
  double x=0, y=0;
  NumericMatrix mat(N, 2);
  for (i=0; i<N; i++)  
    for (j=0; j<thin; j++)  
      x = gsl_ran_gamma(r,3.0,1.0/(y*y+4));
      y = 1.0/(x+1)+gsl_ran_gaussian(r,1.0/sqrt(2*x+2));
     
    mat(i,0) = x;
    mat(i,1) = y;
   
  gsl_rng_free(r);
  return mat;           // Return to R
'
## Compile and Load
GSLGibbs <- cxxfunction(signature(ns="int", thns = "int"),
                        body=gslgibbscode, includes=gslgibbsincl,
                        plugin="RcppGSL")

This code is similar to the version using just Rcpp, but we need to allocate space for the GSL random generator object (and later release that memory allocation), and we do of course call the GSL functions. This also necessitates declaring the function using the two header files listed as arguments for the include argument of cxxfunction(). So how is the performance? The script (now committed in Rcpp's SVN repo as examples/RcppGibbs/RcppGibbs.R, and also part of the next release) creates the output below when running in non-interactive mode (whereas interactive mode creates a few charts too):

edd@max:~/svn/rcpp/pkg/Rcpp/inst/examples/RcppGibbs$ r RcppGibbs.R
Replication # 1 complete 
Replication # 2 complete 
Replication # 3 complete 
Replication # 4 complete 
                    N=1000 N=5000 N=10000 N=20000
Elasped Time (R)     0.124  2.650  10.511  41.773
Elasped Time (RC)    0.081  1.916   7.594  30.280
Elapsed Time (Rcpp)  0.003  0.076   0.306   1.221
Elapsed Time (Rgsl)  0.002  0.049   0.196   0.784
SpeedUp Rcomp.       1.530  1.380   1.380   1.380
SpeedUp Rcpp        41.330 34.870  34.350  34.210
SpeedUp GSL         62.000 54.080  53.630  53.280
               test replications elapsed  relative user.self sys.self
4  GSLGibbs(N, thn)           10   7.845  1.000000      7.84        0
3 RcppGibbs(N, thn)           10  12.218  1.557425     12.22        0
2   RCgibbs(N, thn)           10 312.296 39.808286    311.98        0
1    Rgibbs(N, thn)           10 420.953 53.658764    420.59        0

The first block is a hand-computed comparison using four sets of parameters; the second block uses the excellent rbenchmark package to compare ten runs at twenty-thousand draws. We see a nominal increase in performance due to the bytecode compiler, saving roughly 38 percent which seems appropriate given that the R code mostly controls the loops; actual work in undertaken in the already compiled RNG functions. The Rcpp variant is about 34 times faster than the pure R code. Sanjog reported higher increases on his OS X machines (and Darren's post echos a similar order of magnitude). However, on my i7 running Linux I always obtained an improvement in the mid- to high thirties. That is certainly already a rather pleasant result. What surprised and stunned me at first was that the GSL solution scores an improvement of around 53 times (close to the factor of 60 reported by Darren). A closer look at the code (shown above) makes it clear that there are very few compute-intensive operations outside of the RNG draws. I validated this further with a second study timing just one million draws each from a Gaussian and Gamma using R via Rcpp, and using the GSL. It turns out that the R code is about 2.5 times slower for random draws from the Gamma distribution than the GSL. Inspection of the source code---in files src/nmath/rgamma.c for R and randist/gamma.c for the GSL shows why. R uses a much more complex (and presumably more precise) algorithm. I may follow up with Martin Maechler to see if we can illustrative the numerical benefits of this more expensive approach---this blog entry is getting long enough already. So to sum up: Gibbs sampling is a somewhat resource-heavy Monte Carlo Markov Chain method for investigating multivariate distributions. R excels at quick and simple explorations, albeit at somewhat slower execution speed. The Rcpp package can help by providing easy means to accelerate simulations by a significant factor. The example discussed here is now in SVN repository for Rcpp and will be part of the next release.

Updated 2011-07-16: Darren has just updated his comparison; fixed two typos here too.

Squashing release critical (RC) bugs is one of the most helpful way to contribute to Debian. Because those are the bugs that we need to get rid of in order to release the next stable version. Let s see how you can help. The process is really simple:

1. Find a RC bug that you can fix
2. Prepare a fixed package
3. Send the patch to the BTS
4. Get your fixed package uploaded

I have already covered points 2 and 3 in a former article: How to prepare patches for Debian packages. So I m not going to repeat myself in this article, instead I ll cover how to find a release critical bug to fix and how to get your package uploaded. Find a RC bug with UDD The Ultimate Debian Database (UDD) provides a neat interface to query the bug tracking system: http://udd.debian.org/bugs.cgi. The form contains many options to customize the query, we ll try explain some. First, at the top, you can decide to list bugs based on whether or not they affect testing/stable/unstable. Indeed, thanks to version tracking the BTS knows if a bug applies to the version of the package present in a given distribution. I suggest you pick a choice that includes sid because that s where you re going to push your fixed package. If sid is not affected by the bug, you can t do much about it (except if you want to join the release team and help ensure updates are flowing from unstable to testing). I usually go for wheezy and sid because that filters out packages which are not in testing (and are thus not blocking the next release). Then you have lots of filters to further reduce the list of bugs. It s important to reduce the noise as you typically have several hundreds of RC bugs at a given time. I suggest you the following settings for a start, but you re free to try other combinations depending on what you want to achieve (I ll give some examples later):

• ignore bugs tagged patch (a fix is already available);
• ignore bugs tagged pending (a fix has already been committed to the VCS repository);
• ignore bugs newer than 7 days (that s the time we should leave for the maintainer to take care of the bug by himself);

I usually sort the results by source package so that I immediately see if several RC bugs are affecting the source package. And I might add popularity contest information to get a feel of whether the package is widely used or not. You can see the results of the suggested query here. Other interesting queries:

• List of RC bugs blocking the migration of their package (i.e. affecting unstable but not testing, with different version in both distributions).
• List of RC bugs on packages that you can adopt (i.e. bugs affecting any distribution but on orphaned packages, sorted by decreasing popularity).

Find a RC bug with rc-alert The downside of the above method is that you get bugs on packages that you don t know at all and that you might not care about. Some of them might even be better removed instead of fixed. With the rc-alert command (provided by the devscripts package), you will get a list of RC bugs
on packages that are installed on your computer. It should be much more restrictive. And you have command line options to further filter the list just like with the UDD form. Bonus feature: you can also filter by debtags allowing you to restrict the bugs to packages which are implemented in programming languages that you know.

$ rc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python
Package: gwibber
Bug:     608724
Title:   gwibber bypasses certificate checking when providing the login/password for OAuth
Flags:   [     S  ] (security)
Dists:   [STU] (stable, testing, unstable)
Debtags: implemented-in::python, interface::x11, role::program, uitoolkit::gtk, works-with::im, x11::application
[...]

Get your fixed package uploaded Usually sending the patch to the BTS is more than enough. The maintainer or another Debian developer will pick it up at some point. But if you re interested in becoming a Debian maintainer/developer, it might be worth to push your changes more quickly and get credited by a proper upload with your name. Instead of just preparing a patch, you should also prepare a fixed package following the rules of a Non-Maintainer Upload. Put this package somewhere online (for example on mentors.debian.net). When you send your patch to the BTS, include the link to the updated package and express your wish to get this update sponsored. If you haven t heard anything from the maintainer after 2-3 days, try to find a sponsor on debian-mentors@lists.debian.org. NMUs are easier to review than completely new packages and many Debian developers like to kill RC bugs, so there s a good chance that you ll find someone. Now happy RC bug-squashing! And if you really enjoy it, you can subscribe to debian-bugs-rc (~3000 mails per month)

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

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