Note: This post was written in March 14-15 and posted after our return. When I think about L beck, the first thing that strikes me is the feeling of history underfoot. It struck me most when we set foot inside the Marienkirche. I had never quite felt a wave of a feeling of stepping back in time like that before. The stones on the floor were uneven and imperfect. L beck has had a wet and snowy winter, so the city had spread sand everywhere: sidewalks and roads. Walking into any grand church, I could hear the sound of sand under the shoes of everyone nearby, and feel it under my own shoes. I think I will long associate with L beck the feeling of walking into a grand old church, looking up at the top of the old building at seemingly impossible heights, while feeling the grit of sand and uneven stone beneath my feet. Marienkirche isn t perfect, like some American churches I ve been in, such as the Basilica of Notre Dame. It doesn t have a lot of gold, either, and both of these attributes are wonderful. Look at a column of bricks, and you can see that each brick isn t exactly like its neighbor, and the entire column isn t perfectly straight. Lots of things in L beck are so old that they aren t perfectly straight, and it made me think that our American notion of always having to fix such things might be somewhat off sometimes. Look up, and you see the frescos from the 1300s, revealed after many years after the building was struck by an allied bombing raid in 1942. This heavily damaged the building and knocked down plaster from the walls and ceiling, revealing the old artwork. Many parts of Marienkirche were lost as a result of the bombing, which perhaps adds to its slightly sparse and ancient feel. The church bells were sadly melted and crashed to the ground due to the bombing, and have been left exactly where they fell as a memorial. Look down, and you see the uneven floor, and the concrete slabs above where important people were buried under the floor an attribute common to many of the churches we visited. It was common to see dates of graves from the 1600s and 1700s, though in some places it would go as far back as the 900s. The main part of the church has no heating or cooling, and visiting it on a day just a bit above freezing adds to the feeling of, well, old. Marienkirche has to be my favorite sight in L beck. Walking around the city, I get a similar feel. Many streets and sidewalks are made of stone. The streets that weren t damaged in the war have rows of beautiful old facades. Walk down many streets, and every so often I d see a little tunnel ( just wide enough for a coffin ) that goes under the street-facing houses to a nice little inner courtyard. These are open to the public, but tend to be very quiet and somewhat private. In the courtyard are smaller houses, which would have originally been used by the less wealthy. We also saw the L beck Dom (cathedral), which had a small museum about the destruction due to the Royal Air Force bombing in 1942. It was very sad to see the photo of the Dom in ruins, still smoking, even now. I can only imagine what it must have felt like to residents of L beck to wake up to see many of their priceless centuries-old landmarks and places of worship so horribly destroyed and all of this for little strategic purpose really focused on the morale of the enemy civil population . It s sad that the allies would do such a short-sighted and terrible thing. Europeans have long had to live with the legacy of war upon war, while we Americans have rarely had to see the consequences of war up close. I think it would be good for more of us to visit these sites and come up face to face with what a bomb can do, and then perhaps we will be more judicious with them in the future. Shifting gears now to where we stayed: Andreas & Sigrid, with whom we stayed, have a beautiful 500-year-old house, with lots of original wood beams exposed, and some very old paintings on the walls and ceilings. Nearby were excellent bakeries and a chocolate shop. Terah and I visited it today and bought some very good chocolate. And this brings me to the second thing I ll remember: Andreas & Sigrid s children, Lukas and Rahel. Now, Terah knows no German, I know only a little bit, and the children know no English. So it was a bit slow getting to know each other to start out, but we managed to work around the communication barrier and had a great time. Terah played board games with Rahel, while with me, she kept inventing games to play: hiding somewhere, saying Hallo! , and laughing at how many unsuccessful attempts I might make to find her. I showed Lukas the camera on my Droid, which he used a lot, though a racing game on Terah s iPod Touch was more exciting. They both enjoyed looking at videos of American trains a bit, but especially pictures of our house and yard with Jacob and Oliver. They tried to teach me the German words for things, and also made futile attempts to correct my pronunciation! When we were leaving today, Rahel came over and gave me a kiss on the hand, then the same to Terah s hand, then a little kiss on one of our suitcases. It was touching and sweet. This was one of those experiences no guidebook prepared me for, and no tour bus would have provided. It is something neat to make friends with children despite the large language barrier. On to the rest of the visit We had arrived a little late into Hamburg. After getting our bags and some Euros at an ATM, the next step was to find the bus to L beck. No signs for it were evident, so I found an information desk. The person at the desk was carrying on a conversation in German with the person ahead of me in line. I figured an information desk person in a busy airport would speak English, and was all ready to ask Sprechen Sie Englisch? , but when I walked up, he got a polite smile, and said, Good morning! How can I help? Guess I m obvious. He directed me to the bus, gave me a brochure about it, and told me what time it would leave. Terah and I found the spot to wait, and for a moment I stepped inside the airport terminal. Terah won t let me forget that someone came up to her and asked a question in German, whereas I was spoken to in English. Anyhow, we found the bus, managed to communicate with the driver that doesn t speak English, and sat next to the friendly person that was talking to Terah. He turned out to be a violin player from Munich, and we had a great conversation for the next hour he asking questions about the USA, us asking questions about Germany and Munich. At one point, he commented, You two are so open minded and you re also Americans! He sounded surprised. We exchanged email addresses at the train station. Andreas found us there, and we walked through the city to his house, with him pointing out the sights along the way. L beck is a beautiful city, and though it was damaged in World War II, much of the really old parts still remain. The famous Holstentor Gate has a museum inside, which was fascinating to visit. On Sunday, we went to church with the family we were staying with, Andreas helpfully translating for us. There I met a British Python programmer, which was fun. His wife is a social worker, which was fun for Terah. Monday it was time to get on the train to Berlin. We again walked through a cold and rainy city to the Hauptbahnhof, ready to head to Berlin. There we got on a train to Hamburg, then an ICE train to Berlin. Despite having just a few minutes for a connection in Hamburg, it all went perfectly smoothly. The train left Leipzig about 10 seconds late the clock inside turned over to the minute, then the doors closed and we were off. Impressive. Note: the rest of my photos from L beck are available on Flickr.

Here is a pointer for slides for tonight s bar bof. It s likely that we will only be using the diagram slide.moonshot-ietf77-01

Rule number one in regression testing is to not depend on volatile data. Which I seem to have violated in file t/02simple.t in the Perl package Finance::YahooQuote. Which lead the automated Perl test scripts to remind me for a few days now that the full company name for symbol IBM no longer corresponded to what I had encoded. Not really a bug, but a failure in tests anyway. So without further ado: a new version 0.23 of Finance::YahooQuote which addressed this issue is now in the Debian queue and on CPAN and my local yahooquote page.

When in California last year I visited the NoiseBridge [1] Hackerspace. I was very impressed with what I saw, good equipment and very friendly people. The general concept of a HackerSpace is that it is an environment to support random creative projects. The first picture is a sign near the door which is clearly visible to anyone who is leaving, it encourages people to be AWESOME and EXCELLENT by cleaning up after themselves (and maybe others). I think that this demonstrates the core of what is needed to get such a community project going. Generosity towards others was on display everywhere, there was some free fruit on a table as well as a bottle of Port for anyone to drink. Someone had written a note saying that it s not an insecure Port (a computer security joke). Someone had created an artwork that resembled an advert which some idiots had mistaken for a terrorist bomb (the creature displaying the Impudent Finger). The main (only?) phone in NoiseBridge is apparently a VOIP phone, it is located next to an old pay-phone along with some Magnetix and other toys that can be used by curious people of any age. Magnetix have had repeated safety problems that caused recalls so maybe such things are best placed in an 18+ environment. When I visited about 10 people were working on electronics projects. There were a number of soldering irons in use and some serious test equipment (including a couple of CROs) was available. The people doing the soldering were eager to teach other people about their work. Other equipment that was available included some serious industrial sewing machines and some drill presses. A lot of that equipment is unreasonably expensive to buy for personal use and is also rather bulky to store, having it available in a central location is a great service for the community. Finally Noisebridge has a lot of space. There are rooms that could be used for giving small lectures and couches in the central area for people to relax and have impromptu meetings. Of course they had wireless net access too. Australian Hacker Spaces Kylie Willison has written about the Adelaide Hackerspace which sounds promising [2]. The Connected Community Hackerspace is a new one in Melbourne [3]. It operates out of the homes of members so it s not nearly as big as Noisebridge (which has a substantial property rented for 24*7 operation). I hope that we can get something running permanently in the Melbourne city area in the near future. The Noisebridge membership dues are $80 per month (or $40 for starving hackers). I would pay that for a comfortable chair in a convenient city location with net access surrounded by cool people!

• [1] https://www.noisebridge.net/wiki/Noisebridge
• [2] http://kyliewillison.blogspot.com/2010/03/adelaide-hackerspace.html
• [3] http://groups.google.com/group/connected-community-hackerspace

Note: I wrote most of this before Neil Williams' recent comments on the 3.0 family of formats, so despite the timing this isn't really a reaction to that although I do have a couple of responses. On the whole I think I agree that the Lintian message is a bit heavy-handed and I'm not sure I'm thrilled about the idea of the default source format being changed (though I can see why the dpkg maintainers are interested in that). That said, as far as I personally am concerned, there is a vast cognitive benefit to me in having as much as possible be common to all my packages. Once I have more than a couple of packages that require patching and benefit from the 3.0 (quilt) format as a result, I find it in my interest to use it for all my non-native packages even if they're patchless right now, so that for instance if they need patches in the future I can handle them the same way. It's not unheard of for me to apply temporary patches even to packages I actively maintain upstream, so I don't discount those either. I haven't decided what to do with my native packages yet; unless they're big enough for bzip2 compression to be worthwhile, there doesn't seem to be much immediate advantage to 3.0 (native). Anyway, on to the main body of this post: I've been one of the holdouts resisting use of patch systems for a long time, on the basis that I felt strongly that dpkg-source -x ought to give you the source that's actually built, rather than having to mess around with debian/rules targets in order to see it. Now that the 3.0 (quilt) format is available to fix this bug, I felt that I ought to revisit my resistance and start trying to use it. Migrating to it from monolithic diffs is of course a bit more work than migrating to it from other patch systems, so it's taken me a little while to get round to it. I'd been thinking about holding off until there was better integration with revision control (e.g. bzr looms), as I feel that patch files really ought to be an export format, but I eventually decided that I shouldn't let the perfect be the enemy of the good. I have enough experience with co-maintaining packages that use build-time patch systems to be able to compare my reactions. After experimenting with a couple of small packages, I moved over to the deep end and converted openssh a few weekends ago, since quite a few people have requested over the years that the Debian changes to openssh be easier to audit. This was a substantial job - over 6000 lines of upstream patches - but not actually as much work as I expected. I took a fairly simplistic approach: first, I unapplied all the upstream patches from my tree; then I ran bzr di interdiff -q /dev/stdin /dev/null >x, reduced it to a single logically-discrete patch, applied it to a new quilt patch using quilt fold, and repeated until x was empty. This was maybe an hour or two of work, and then I went through and tagged all the patches according to DEP-3, which took another few hours. After the first pass, I ended up with 38 patches and a much clearer idea of what has been forwarded upstream and what hasn't; I currently have 5 patches to forward or eliminate, down from 18. Good things:

• I don't lose any of my history. Since all the patches remain applied to the tree in revision control (this is what dpkg-source -x gives you, so it's the natural representation in revision control too), bzr blame works just as you'd expect and displays both upstream and Debian changes at once. I rely on tools like blame a lot, and I really hate the way build-time patch systems make it hard to use revision control when the tree is in a built state, so this was a hard requirement for me.
• I've used patch tagging before, so I was expecting some benefits, but viscerally I feel much more in control. It's so much less laborious now to see what I need to do by way of forwarding. I don't regret waiting for 3.0 (quilt) to become available, but I hadn't realised quite how much I was being held back beforehand.
• Adding new patches is pretty natural, much more so than with build-time patch systems. You can create and apply the patch, test-build, and commit when it works. I much prefer this over having to clean the tree before committing (or commit just part of the tree, which is error-prone). The more that committing to a Debian package feels like committing to an upstream project, the better.
• There's definitely something to be said for patch-tracker being more useful. It deals with DEP-3 to the extent of linkifying URLs, although it might be nice if patch descriptions were displayed on the overview page for each version.

Bad things:

• It's a bit awkward to set things up when checking out from revision control; I didn't really want to check in the .pc directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout. This is sort of the reverse of the previous problem, where users had to do something special after dpkg-source -x, and I consider it less serious so I'm willing to put up with it. I ended up with a rune in debian/rules that ought to live somewhere more common.
• Everything ends up represented twice in revision control: the patch files, plus the changes to the patched files themselves. I'm OK with this although it is a little inelegant.
• Although I haven't had to do it yet, I expect that merging new upstream releases will be a bit harder. bzr will deal with resolving conflicts in the patched files themselves, and that's why I use a revision control system after all, but then I'll have to go and refresh all the patches and will probably end up doing some of the same conflict resolution a second time. I think the best answer right now is to quilt pop -a, force a merge despite the modified working tree, and then quilt push && quilt refresh -pab until I get back to the top of the stack, modulo slight fiddliness when a patch disappears entirely; thus effectively using quilt's conflict resolution rather than bzr's. I suppose this will serve as additional incentive to reduce my patch count. I know that people have been working on making this work nicely with topgit, although I'm certainly not going to put up with the rest of git due to that; I'm happy to wait for looms to become usable and integrated. :-)
• It would be nice if there were some standard DEP-3 way to note that a patch has been accepted or rejected upstream, beyond just putting it in the description. In particular, it seems to me that listing patches accepted upstream could be used to speed up the process of merging new upstream releases.

On the whole I'm satisfied with this, and the benefits definitely outweigh the costs. Thanks to the dpkg team for all their work on this!

I have been a developer with Debian since 2001 but my work has decreased steadily as my career and home life get busier. I think I'm at a point where I need to create a clean break and take a step away. But here is my problem: I am the only and founding DD on the NVIDIA packaging team. There is a DM now that works on libvdpau but despite attempts to have more DD's join, only Debian users have answered the call on a part-time or patch submitting basis. So does anybody want to take to the packaging of these babies before I mostly likely orphan them? Andres Mejia would of course keep libvdpau. Thank you for your attention.

Note: I wrote most of this before Neil Williams' recent comments on the 3.0 family of formats, so despite the timing this isn't really a reaction to that although I do have a couple of responses. On the whole I think I agree that the Lintian message is a bit heavy-handed and I'm not sure I'm thrilled about the idea of the default source format being changed (though I can see why the dpkg maintainers are interested in that). That said, as far as I personally am concerned, there is a vast cognitive benefit to me in having as much as possible be common to all my packages. Once I have more than a couple of packages that require patching and benefit from the 3.0 (quilt) format as a result, I find it in my interest to use it for all my non-native packages even if they're patchless right now, so that for instance if they need patches in the future I can handle them the same way. It's not unheard of for me to apply temporary patches even to packages I actively maintain upstream, so I don't discount those either. I haven't decided what to do with my native packages yet; unless they're big enough for bzip2 compression to be worthwhile, there doesn't seem to be much immediate advantage to 3.0 (native). Anyway, on to the main body of this post: I've been one of the holdouts resisting use of patch systems for a long time, on the basis that I felt strongly that dpkg-source -x ought to give you the source that's actually built, rather than having to mess around with debian/rules targets in order to see it. Now that the 3.0 (quilt) format is available to fix this bug, I felt that I ought to revisit my resistance and start trying to use it. Migrating to it from monolithic diffs is of course a bit more work than migrating to it from other patch systems, so it's taken me a little while to get round to it. I'd been thinking about holding off until there was better integration with revision control (e.g. bzr looms), as I feel that patch files really ought to be an export format, but I eventually decided that I shouldn't let the perfect be the enemy of the good. I have enough experience with co-maintaining packages that use build-time patch systems to be able to compare my reactions. After experimenting with a couple of small packages, I moved over to the deep end and converted openssh a few weekends ago, since quite a few people have requested over the years that the Debian changes to openssh be easier to audit. This was a substantial job - over 6000 lines of upstream patches - but not actually as much work as I expected. I took a fairly simplistic approach: first, I unapplied all the upstream patches from my tree; then I ran bzr di interdiff -q /dev/stdin /dev/null >x, reduced it to a single logically-discrete patch, applied it to a new quilt patch using quilt fold, and repeated until x was empty. This was maybe an hour or two of work, and then I went through and tagged all the patches according to DEP-3, which took another few hours. After the first pass, I ended up with 38 patches and a much clearer idea of what has been forwarded upstream and what hasn't; I currently have 5 patches to forward or eliminate, down from 18. Good things:

• I don't lose any of my history. Since all the patches remain applied to the tree in revision control (this is what dpkg-source -x gives you, so it's the natural representation in revision control too), bzr blame works just as you'd expect and displays both upstream and Debian changes at once. I rely on tools like blame a lot, and I really hate the way build-time patch systems make it hard to use revision control when the tree is in a built state, so this was a hard requirement for me.
• I've used patch tagging before, so I was expecting some benefits, but viscerally I feel much more in control. It's so much less laborious now to see what I need to do by way of forwarding. I don't regret waiting for 3.0 (quilt) to become available, but I hadn't realised quite how much I was being held back beforehand.
• Adding new patches is pretty natural, much more so than with build-time patch systems. You can create and apply the patch, test-build, and commit when it works. I much prefer this over having to clean the tree before committing (or commit just part of the tree, which is error-prone). The more that committing to a Debian package feels like committing to an upstream project, the better.
• There's definitely something to be said for patch-tracker being more useful. It deals with DEP-3 to the extent of linkifying URLs, although it might be nice if patch descriptions were displayed on the overview page for each version.

Bad things:

• It's a bit awkward to set things up when checking out from revision control; I didn't really want to check in the .pc directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout. This is sort of the reverse of the previous problem, where users had to do something special after dpkg-source -x, and I consider it less serious so I'm willing to put up with it. I ended up a rune in debian/rules that ought to live somewhere more common.
• Everything ends up represented twice in revision control: the patch files, plus the changes to the patched files themselves. I'm OK with this although it is a little inelegant.
• Although I haven't had to do it yet, I expect that merging new upstream releases will be a bit harder. bzr will deal with resolving conflicts in the patched files themselves, and that's why I use a revision control system after all, but then I'll have to go and refresh all the patches and will probably end up doing some of the same conflict resolution a second time. I think the best answer right now is to quilt pop -a, force a merge despite the modified working tree, and then quilt push && quilt refresh -pab until I get back to the top of the stack, modulo slight fiddliness when a patch disappears entirely; thus effectively using quilt's conflict resolution rather than bzr's. I suppose this will serve as additional incentive to reduce my patch count. I know that people have been working on making this work nicely with topgit, although I'm certainly not going to put up with the rest of git due to that; I'm happy to wait for looms to become usable and integrated. :-)
• It would be nice if there were some standard DEP-3 way to note that a patch has been accepted or rejected upstream, beyond just putting it in the description. In particular, it seems to me that listing patches accepted upstream could be used to speed up the process of merging new upstream releases.

On the whole I'm satisfied with this, and the benefits definitely outweigh the costs. Thanks to the dpkg team for all their work on this!

I own a Samsung SGH-X160. It s just a mobile phone for telephoning and writing SMS messages. I was sitting in a train last weekend and wanted to add a note to my task list in T9, but the phone didn t know Eclipse. I wanted to add Eclipse to the dictionary, but instead the phone crashed (rebooted). I tried it multiple times and it s reproducible: Grab your SGH-X160, add a new task (Aufgabenliste -> Optionen -> Neu), type 3254, T9 will suggest Eckh, press zero to toggle T9 s suggestion until it gives you the option to add the word to the dictionary, press adding (Zuf gen), correct the word to Eclipse, press OK. Your phone will go blank and then present you the boot splash for a half minute. I want to file a bug and grab the source code to fix this bug. Oh, that is not possible, because the OS on the mobile phone is not free (libre) software.

Fedora uses Plymouth to provide a flicker free boot for quiet some time now. Debian has packages in experimental but it took some patches to get these working. After adding a Debian logo the boot splash actually looks quiet nice. The initramfs and init scripts do need some more work but it's basically working. Thanks a lot Daniel for merging these so quickly! To enable Plymouth you first need to set up KMS in the initramfs. For an intel based card you can do this by either adding

i915 modeset=1

to /etc/initramfs-tools/modules or by setting

i915.modeset=1

on the kernel command line. Then install plymouth, set a default theme and update the initramfs:

aptitude install plymouth plymouth-plugins-all
plymouth-set-default-theme solar
update-initramfs -u

Finally add splash to the kernel's command line (e.g. by adding it to /etc/default/grub). Afterwards reboot and you should see the solar flares: We're still not fully there yet since we need a newer gdm for a flicker free handover. Fortunately the Debian GNOME maintainers have already prepared a new package in svn. We also need proper support for encrypted disks, asking for the passphrase works with this fix but cryptsetup needs support for it.

Regarding my previous post on source format 3.0, I think it came across that I was blaming lintian entirely which would be unfair.

(As a side-note, a bug in serendipity XMLRPC resulting in all entries having comments disabled has led to a welcome effect of spreading the discussion more widely than a series of comments on my own site could have achieved. I'm happy with this state of affairs, so it you want to comment, either contact me by private email or put your comments on your own blog. I won't be enabling comments any time soon.)

The extended information behind the lintian warning is one thing (I've explained my position on that to Russ privately) - my main objection is to how such a warning was pushed into lintian and the entire use 3.0 or be damned approach that seems to be being adopted.

IMHO, source format 3.0 is not good enough to be the standard dpkg source format for a simple reason: It offers nothing to well maintained packages. Not all packages need NMU's - ever. Not all packages have patches - ever. Native packages and packages with the Debian maintainer upstream gain nothing from 3.0, as far as I can see.

I have 67 source packages - after much very careful consideration, I have found that a handful of those (less than 10) actually benefit from 3.0 and the rest are all unaffected. None of the packages that I will keep on 1.0 have ever had an NMU since I've been maintainer, most are either native or entirely under my sole upstream control. I will decide whether Debian gets a .tar.gz or a .tar.bz2 and although I generally offer both for download where I can, I see no reason to adopt .tar.bz2 as my default for Debian packaging.

Adding a redundant directory and file is obnoxious. I fail to see why debian/source-format would not have been perfectly suitable. Nevertheless, I will do what is necessary to avoid 3.0 until there is a compelling technical reason to adopt it.

The imperative for those in favour of 3.0 is to convince me that there is a reason TO change, not to make it difficult for me NOT to change. I do not need any reason to avoid 3.0 other than I do not have a good enough reason to move from 1.0. Making developers feel like luddites or incompetent merely because the proponents of 3.0 have failed to convince others to move to 3.0 is just insulting. You want me to use 3.0? Explain why I should bother - the current "reasons" on the Wiki page are simply not good enough and any rehash of those will be ignored. Come up with something new or respect my decision and let me get on with more important stuff.

Note: This post written March 13, and posted after our return. Yesterday was a day of travel. We said goodbye to Jacob and Oliver in the morning. We had thought a lot about how to tell Jacob what was happening and when to tell him. Ultimately, he doesn t really understand time or distance very well yet, and we know that he worries about the unknown. So although he knew about the visit to Indiana for awhile, he didn t know that Terah and I would be going somewhere until th emorning. He wasn t pleased, but seemed to take it well. We told him that we re going to a hotel in Germany and reminded him of other times we ve gone to a hotel. I also reminded him that sometimes a babysitter comes to our house while Terah and I go somewhere else, but we always come back later. That seemed to help. We got to the Indianapolis International Airport in plenty of time for our flight. They have built a completely new terminal building; the old one we were familiar with is now abandoned. The new building is beautiful, sunny, open, and even inspiring. I was impressed. Newark Liberty International, on the other hand, had all the ambiance of a Greyhound station across from the county jail. It reminded me a lot of Chicago Midway, which I used to go through regularly: dark, a bit run down (water stains on the ceilings), and nowhere near enough seating in the gate areas. We wound up standing for an hour before our flight left (late). The food court in Concourse C was something special. As we were witting there, Terah remarked on the constant stream of passengers that walked up to the food court, glanced around, and made a look of THESE are my choices? Which was our exact reaction a few minutes before. Yep, it s the first food court I ve been in where McDonald s was the upscale choice. The sit-down Mexican Cafe had hamburgers with mexi-fries as its main attractions. Terah tried out the dodgy pizza place while I tried out the even more dodgy Chinese/sushi place (I was not silly enough to try sushi there). Ultimately we decided that perhaps the point of the food court was to make us eager for airplane food. The choices in Indianapolis sure put that to shame: TGI Fridays was a real gourmet option compared to the choices in Newark. I was really a bit embarrassed; Newark is a major international airport, and many visitors to the United States will be greeted by a foul-smelling food court and a dingy airport. Yay for being welcoming? Well, really we had a good day of travel and I shouldn t be ragging on the Newark airport so much, so I ll say something positive: there s a pharmacy right behind the food court, which is probably a very convenient location to meet the needs of many diners. Anyhow, our flight left Newark about an hour late, at about 7PM Eastern. As I write this, it s about 7:30 CET (1AM Eastern) and our plane will be on the ground in about an hour. I m excited for the coming week! I got some sleep on the plane, but not a lot. I m hoping that I will have the energy for a good weekend.

As a complete outsider and with my obvious bias as a Debian Developer: how can anybody call Ubuntu a community distribution when it's obvious that Canonical and Mark Shuttleworth can, and will, take decisions for reasons that are not made clear, and with only little or no community involvment? This rethorical question refers, of course, to the current debate about purple vs. brown and the best position of the window close button (Bug report and LWN coverage.) Conclusion? Let's be fair and call it a community support commercial distribution. Perhaps we should found a non-profit to award a (trademarked) True Community Effort label to operating system distributions where no commercial body has the final say?

Ben Hutchings writes:

You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.

You are missing the point - the planned switch of the default format isn't considered a good approach by quite some people. If something new gets introduced, switching to it should be done in wake manner. Other tools do that too, so why can't a central package as dpkg use that approach? I especially want to mention that a point release update for stable was required to get it working in stable like it should.

Overview The German supermarket chain Aldi has been running in Australia for 8 years now [1]. Their standard practice for a long time has been to offer regular special deals on a few items of consumer electronics every week, my chocolate fridge is one thing I bought from Aldi [2]. Today Aldi have started selling Noise Canceling Headphones [3]. These headphones are badged by Bauhn but that name is apparently applied to random products from cheap manufacturers, it may be an Aldi name that is applied to stuff that they sell. The headphones cost $69AU which is really cheap. But the deal will probably end in less than a week when stock runs out. Noise canceling headphones can be used in server rooms and other noisy environments. Every company that has a server room should buy a few sets. One of the features of noise-canceling is that it works best on low frequencies and on regular sounds it specifically doesn t block human voice well. In some noisy environments it will be easier to hear people talk if you wear such headphones! Noise canceling headphones are also very useful to people who are on the autism spectrum and other people who get more annoyed by noise pollution than average people. I have been wearing my Bose headphones on public transport and when walking around in the city, this not only stops traffic noise but it also helps to avoid people thinking that I want to talk to them. Features The first picture shows me wearing the Bauhn NC headphones, it s from the right to show the controls for the built-in MP3 player. I have not yet tested the MP3 functionality. It appears that as the controls are one power button, buttons for next/previous track, and for controlling the volume. This is fairly poor for MP3 functionality, ideally you would want to have a display to see a list of tracks, maybe have directories to store files, etc. I guess this could be a convenient feature on occasion, but you wouldn t buy the headphones for the MP3 functionality.
The next two pictures show a comparison of the Bauhn headset with the Bose QC-15 headset that I bought last year [4]. The cases of the Bauhn and Bose devices are almost exactly the same size and of a very similar shape, the Bose case is tapered and indented and also has a finer weave on the cloth covering it looks much nicer. Both devices come with an adapter for an airline socket and with a detachable cable. They also both have pouches attached to the inside of the case with velcro. But the Bauhn headphones come with an adapter for the 6.5mm TRS connector which could be convenient if you want to plug them in to a larger amplifier, the basic connector is 3.5mm in both cases. The Bauhn device uses a standard TRS connector at the headphone end while the Bose QC-15 use a special connector that matches the shape of the headset and which has a TRRS plug (to cater for the high/low volume switch), so it seems that a damaged Bauhn cable could be replaced cheaply while a replacement Bose cable would have to be purchased from Bose (presumably at great expense and delay). The Bauhn case also has a velcro attached pocket for storing business cards (or maybe a name tag or something). The supplied cable for the Bauhn is described as being 5 feet long which isn t quite long enough to reach a tower PC that is sitting on the floor. The Bose has a cable that is about a foot longer (maybe 6 feet total), but due to the non-standard connector you can t replace it. I presume that I could easily buy a 4 meter cable for the Bauhn headphones, but I could of course buy an extension cable to use with the Bose. Bose advertise the QC-15 headphones as having 35 hours of battery life from a single AAA battery. Aldi advertise the Bauhn headset as having 5 hours of battery life when NC is turned on and they use two AAA batteries. It s widely regarded that rechargeable batteries don t last as long as the batteries used for estimating the battery life (which presumably are the most expensive long-life batteries available). I ve found a single rechargeable AAA battery to last well over 5 hours in my Bose headphones, so it seems that battery life is considerably worse for the Bauhn device. One feature of the Bauhn device is that it can be used without any batteries for playing external music. The Bose headphones can t be used at all without a battery. So while the Bauhn will use the batteries faster it will at least be usable when the batteries run out. But if you are buying headphones for the purpose of avoiding noise then the Bose headphones are simply better. Comfort The Bose headphones have significantly deeper ear wells than the Bauhn about 23mm vs 18mm. If your ears stick out more than 18mm (as mine apparently do) then this is a good reason for choosing Bose. The Bose headphones are a tighter fit, the spring that pushes the ear-pieces together is stronger. But they have better padding so this doesn t cause me any discomfort. Also the Bose headphones have better passive noise reduction due to having a more snug fit around the ears. I ve worn my Bose headphones on a flight from the US to Australia with hardly a break and they were quite comfortable I would never want to do that with the Bauhn headphones. Noise Reduction I tested the Bose and Bauhn products against three noise scenarios, external music, an air-conditioner, and a car engine. The Bose headphones made good reductions of the noise from the external music (Numb by Linkin Park) and the air-conditioner. The Bauhn headphones did little to stop Linkin Park and was not very effective against the air-conditioner noise. I think that this is largely due to the lack of passive noise reduction, the air-conditioner in question makes little vibration noise and the sound of rushing air is generally immune to active noise cancellation. Both headphones were very effective when in a car with the engine idling. The engine noise of vehicles seems to fall in an ideal frequency range for active cancellation. Music Quality When listening to Youtube music played on my Thinkpad I could not notice any quality difference between the two sets of headphones. I did notice that the Bose headphones seemed to have a greater response in the higher frequency range, but that doesn t necessarily mean that one set is better than the other. Maybe if I was listening to FLAC0 encoded music that I had personally ripped from a CD then I would notice a difference. But for most people the Bauhn music quality should be good enough. Design Quality The Bose product is solidly designed, while the Bauhn product appears cheap in every way. Opening the battery compartment on the Bauhn headphones is difficult and if you do it wrong you could easily break the lid off, I expect that every set of Bauhn headphones that is used by children will be broken in a small amount of time but it should still be fully functional with a broken lid. The matt finish of the Bose headphones should hide minor scratches much better than the shiny Bauhn headphones. The Bauhn headphones also have lower quality plastic parts, it appears that the molds used were designed cheaply and without adequate care to prevent marking the final product. The design flaws that affect usage of the Bauhn product are the shallow ear wells, the poor fit of the cushions around the ears (which is probably mostly due to a weak spring pressing the ear cups to the wearer s head), and the battery compartment lid which is difficult to open and appears prone to breakage. The other flaws are all cosmetic. I wonder whether the Bauhn product was made by one of the big name manufacturers who deliberately reduced the quality to avoid competing with their more expensive products. It seems that the major flaws could have been corrected at design time with almost no increase in manufacturing costs. Recommendations If you can afford the Bose QuietComfort 15 Acoustic Noise Cancelling Headphones then they are really worth the extra expense, I have no regrets at all about spending about $320US (including tax) on my Bose QC-15. The Bauhn product is good for when you want something cheap, for example a set to be used in a server room, or for the use of children. I bought a Bauhn headset for a friend who is a pilot, he spent $1,100 on a noise-canceling headset for his plane but had never got around to buying one for recreational use I expect that he will allow his children to use his new Bauhn headphones, if they get broken it s only a $69 expense. The second cheapest NC headphones I ve seen on offer in Australia is Harvey Norman selling Phillips HN-110 Noise Canceling Headphones for $100AU [5]. Amazon sells Philips HN 110 Folding Noise-Canceling Headphones for $50US but doesn t seem to ship them outside the US (at least not to Australia). JB Hifi also has some NC headphones on sale in Australia [6], but they are more expensive at $219 for AKG and $319 for Sennheiser. Also the models they sell are on-ear which means that they will inherently have very little passive noise reduction and will also annoy anyone who doesn t like having their ears squashed. If I was buying NC headphones for my own use and didn t want to spend $300US then I would either buy the Philips HN 110 Folding Noise-Canceling Headphones from Amazon and get a friend in the US to post them to me or I would buy them from Harvey Norman. But the Bauhn product is good if you want cheap headphones to stop engine noise and give reasonable quality when playing music.

• [1] http://aldi.com.au/
• [2] http://etbe.coker.com.au/2010/02/28/chocolate-fridge/
• [3] http://aldi.com.au/au/html/offers/2827_12539.htm
• [4] http://etbe.coker.com.au/2009/12/20/bought-the-qc-15/
• [5] http://www.harveynorman.com.au/product/1255509334278/phillips-full-size-noise-reduction-headphones
• [6] http://www.jbhifi.com.au/portable/mp3-players/head-phones/noise-cancelling/

Neil Williams writes:

The new lintian addition "missing-debian-source-format" is starting to remind me of a pestering nanny. I use source format 3.0 only where I see a technical benefit and that - so far - is restricted to packages that use a .tar.bz2 upstream and one or two with really tricky patching requirements.

You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.

A while ago Ganneff wondered weather it would be possible to make the matcher extension of rxvt-unicode also pick up something like #12345 and turn it into a link into the BTS. It isn't or rather, it wasn't. The idea got stuck in my head and invested some time to make it happen. Here is the quick'n'dirty diff to make it happen:

--- /usr/lib/urxvt/perl/matcher.distrib	2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda	2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
 # Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
 
 my $url =
-   qr 
+   qr (?:
       (?:https?:// ftp:// news:// mailto: file:// \bwww\.)
       [a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
       (
          \([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)  # Allow a pair of matched parentheses
          [a-zA-Z0-9\-\@;\/?:&=%\$_+*~]  # exclude some trailing characters (heuristic)
       )+
+      ) \#[0-9] 4, 
     x;
 
 sub on_user_command  
@@ -145,6 +146,7 @@
          my @begin = @-;
          my @end = @+;
          if (!defined($col)   ($-[0] <= $col && $+[0] >= $col))  
+            $match =~ s/^#/http:\/\/bugs.debian.org\//;
             if ($launcher !~ /\$/)  
                return ($launcher,$match);
               else  

The diff is intentionally small so it is clear what is happening here. And it should give ideas for other extensions that one would like to make. I don't consider it though flexible enough to submit it upstream. Enjoy anyway!

The new lintian addition "missing-debian-source-format" is starting to remind me of a pestering nanny.

I use source format 3.0 only where I see a technical benefit and that - so far - is restricted to packages that use a .tar.bz2 upstream and one or two with really tricky patching requirements. It is literally one or two as well - out of 67 source packages which I maintain (more than some of those nagging me to change).

Packages for which I am upstream and all my native packages will stick with source format 1.0 - because there is no technical reason to migrate. Packages where I'm not upstream but which continue to use .tar.gz and have minimal or absent patching needs will also stay with 1.0 indefinitely. (I can't see how dpkg can drop 1.0 support, even after multiple stable releases after Squeeze.)

I've no interest in being side-tracked into a pointless "discussion" with those who have already made up their minds that nobody could possibly think that 3.0 is unwelcome or uninteresting. Nagging me won't help - I don't consider 3.0 worth using and I see no technical reasons to adopt it blindly.

Rick Steves is known for writing books, and producing public TV shows, about travel to Europe. He encourages people to get out of their comfort zone, advocates staying in homes instead of hotels, and giving yourself permission to struggle to communicate in a land of unfamiliar language. That way, you get to experience not just the landmarks, but the culture and history. That was the approach we favored in our recent trip to Europe, and after being there (and seeing tour groups), I think Rick Steves is right on. On the plane to Europe, I read his Travel as a Political Act. This is not a guidebook, but more a book about the philosophy of travel. As usual with my book reviews, unless indicated otherwise, all quotes here come from the book. He starts out with this statement:

I ve taught people how to travel. I focus mostly on the logistics: finding the right hotel, avoiding long lines But that s not why we travel. We travel to have enlightening experiences, to meet inspirational people, to be stimulated, to learn, and to grow. Travel has taught me the fun in having my cultural furniture rearranged and my ethnocentric self-assuredness walloped.

I read this book mostly on the plane to Hamburg, or the week prior to leaving. I can credit Rick Steves directly for encouraging me to strike up a conversation with a random German on the bus from Hamburg to L beck, which I ll discuss here in a couple of days. Probably the biggest lament from Rick Steves is that the people that really ought to travel the ones that are so sure that their ways are correct and best are least likely to do so.

Make a decision that on any trip you take, you ll make a point to be open to new experiences, seek options that get you out of your comfort zone, and be a cultural chameleon trying on new ways of looking at things and striving to become a temporary local. My best vacations have been both fun and intensely educational Travel challenges truths that we were raised thinking were self-evident and God-given. Leaving home, we learn that other people find different truths to be self-evident. We realize that it just makes sense to give everyone a little wiggle room.

The book is set with an introductory encouragement to travel, followed by seven vignettes of different countries he s visited, and descriptions of how it s impacted him. He gave a lesson of the opening of the German Reichstag (parliament building), which he was present for in 1999. He was surrounded by teary-eyed Germans and a few tourists so preoccupied with trivialities forgotten camera batteries, needing a Coke, the lack of air-conditioning that they were missing out on this once-in-a-lifetime opportunity to celebrate a great moment with the German people. He comments that we can learn from other countries that no one country has a monopoly on good ideas, and it is plenty patriotic to insist what we adopt good ideas (such as drug policy) from other countries and adopt them for our own. Particularly touching to me was the description and photo of a memorial in El Salvador, very much looking like the American Vietnam memorial except that one remembering loved ones lost fighting the United States. How many Americans even know that we were involved in a damaging war in El Salvador? A large part of his book was, for me, preaching to the choir, as this comment illustrated:

In the European view, America is trapped in an inescapable cycle to feed its military-industrial complex: As we bulk up our military, we look for opportunities to make use of it. (When your only tool is a hammer, you treat every problem like a nail.) And then, when we employ our military unwisely, we create more enemies which makes us feel the need to grow our military even more. If an American diplomat complained to his European counterpart, America is doing all the heavly lifting when it comes to military, the European might respond, Well, you seem to be enjoying it. We re building roads and bridges instead.

That s a sentiment I ve agreed with for quite some time already, and as such, some parts of the book moved slowly for me though I imagine his target audience included people that had never seriously considered these arguments before. Then there were surprising facts:

by the end of World War I, an estimated half of all the men in France between the ages of 15 and 30 were casualties. When some Americans, frustrated at France s reluctance to follow us into a war, call the French surrender monkeys, I believe it shows their ignorance of history.

And again, I d agree with him on that point. The vignette on Iran was particularly interesting, as he described his experiences in person, they sounded far different than the picture we often get in the media. I have realized, incidentally, that I am terrible at writing book reviews. So rather than inflict more paragraphs upon you with this one, I ll summarize by saying that this is a touching, informative, and motivational book, which I highly recommend. I ll leave you with this quote:

Mark Twain wrote, Travel is fatal to prejudice, bigotry, and narrow-mindedness. These wise words can be a reallying cry for all travelers once comfortably back home. When courageous leaders in our community combat small-mindedness and ignorance travelers can stand with them in solidarity.

I didn t travel to make some sort of statement or as a political act. But I was enriched in many ways by travel of course the obvious ones of contemplating the history of a 900-year-old beautiful church, but also in seeing the different character of different cities, being with two families for a couple of days, and seeing different approaches to common problems. I am very glad I wasn t shut off from this behind a tinted window in a tour bus.

We, the Debian Orbital Alignment Team (DOA team), have released eclipse 3.5.2-1 to Debian unstable today after nearly seven month of work and 612 commit to our git repository. Many thanks to our hero Niels Thykier (222 commits). Without him we wouldn t have eclipse in Debian now. Thanks to Pablo Duboue, Adnan Hodzic, and Adrian Perez for their work on the Debian package. Last but not least, I want to thank Alexander Kurtakov and Andrew Overholt for eclipse-build, which we use to build eclipse. You should have modern hardware, if you want to build eclipse. It will need three gigabytes free disk space, two gigabytes memory, and at least 12 minutes to build, but it can need hours (on old hardware or if you have not enough memory). Update: Four days later we released 3.5.2-2 to Debian unstable. Today eclipse 3.5.2-2 was synced to Ubuntu 10.04 (lucid).

Yay! The dlr-languages package has been migrated to testing, which means that it will be included in squeeze, the next release of Debian. Jo has uploaded the -2 version and it is now in sid. This version addresses the issues brought up in the Ubuntu Feature Freeze exception (FFe) bug, so I expect that it will be accepted shortly. Still lots of ifs , but this is pretty exciting for me, since this is my first debian package, and I ve been intending to get it in for over two years. I m not just sitting on my hands while this happens. I ve been working with Ivan, Ankit, Dino and Michael to get the next version of the package put together. I m currently merging Ivan s latest branch into the changes I ve made for DFSG compliance. Dino recommended that the next release include IronRuby 1.0 and IronPython 2.6.1, which should be released by upstream around the middle of April.