When you shake the tree, things happen..:-). I sent targeted update requests for level 2 (mostly espeakup and grub2).

• Gujarati, Serbian and Tamil complete level 1
• Bulgarian, Esperanto, Japanese complete level 2 and are now full 100%
• Progress for Indonesian in level 1
• Icelandic completes level 2
• Simplified Chinese completes level 3 and is now full 100%
• Hebrew completes level 3
• First update for Wolof since ages

Status for D-I level 1 (core D-I files):

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

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

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

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

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

Full 100% completeness (hall of fame) for 14 languages: Bulgarian, Czech, German, Esperanto, Spanish, French, Italian, Japanese, Kazakh, Dutch, Portuguese, Russian, Slovak, Simplified Chinese

For my day job I build storage systems. A lot of what I do at present involves caring a lot about how different OSes deal with things like new LUNs being presented from a SCSI target, or errors along a subset of the available paths to a device. It will come as no surprise to you to discover that they all suck (for values of all equal to Linux, Solaris, Windows and VMWare). New LUNs are particularly annoying. I'm in the situation that creation and removal of a LUN is exceptionally easy. Hmmm. Maybe I need to back up here a bit first. SCSI has the concept of a target (think, device, eg hard drive). Each target can present multiple logical units. Each of these is assigned a number - a Logical Unit Number. Most devices (a hard drive, or a CDROM drive) will present a single LUN. A storage array will tend to present multiple LUNs; one for each volume that is exported to the host. At the host level each LUN really just looks like a separate device (for Linux /dev/sda and /dev/sdb may well be separate LUNs on the same array, rather than 2 separate arrays/hard drives, for example. At the block device level you don't care about the difference usually). Anyway. For various reasons I end up adding and removing LUNs quite often. And there are ways for the array to indicate that this has happened to the host (the UNIT ATTENTION/REPORT LUNS DATA CHANGED check condition seems to be favoured these days, as a complete Fibre Channel LIP can be disruptive). What I'd like to happen in that case is the host to pick up the check condition and drop and/or add the devices that have changed. Instead everything wants a manual rescan. rescan-scsi-bus tends to be simplest for Linux. Windows wants a manual refresh in Disk Administrator. VMWare a "Rescan HBAs" from vSphere. Solaris a "devfsadm -C" and possibly a "cfgadm -al" first. And all of these can be temperamental about picking up the changes. We've done a lot about hotplug for the desktop user experience, without doing the same level for the server experience. I appreciate that there are situations that you don't want your server to reconfigure things without being told to, but the current situation can be detrimental (for example Linux multipathing will hold a device open even after it's disappeared and is returning an "INVALID LUN" response; it would be much better if it could cleanly close that device and wait for it to return). Storage is capable of being much more than just a single block device these days, and it's a shame that nothing seems to deal fully with that fact. (Yes, yes, I should write and submit patches, but I appreciate that there's not always a simple answer, nor necessarily an answer that works for all situations automatically. Plus, y'know, not enough hours in the day and I hope you all appreciate I've taken a break from watching BSG to write this.)

Bugs I've hit in GNOME 3, in the last 5 minutes:

• gnome-shell's "run" pop-up lost focus and I couldn't get rid of it. Nor could I launch another "run" dialogue, which is my normal route for starting software.
• I tried to coax my web browser into launching a terminal by browsing to file:///usr/bin/gnome-terminal. Instead, it downloaded a copy to ~/Downloads. Fine, no problem, because after another click it launches nautilus to handle the file. (This is not a bug).
• nautilus doesn't know what to do with the file. Apparently I haven't installed a handler for viewing executable files. I'm guessing the copy of gnome-shell isn't +x. nautilus does sensible things when another file (such as a picture) is marked +x, so why doesn't it do so for the opposite case?
• This is such a bizarre error message I try to take a screenshot of it. I take one, then take another (cropped). I try to save the second picture over the first one, but gnome-screenshot complains that it cannot find a file somewhere in /tmp.
• The flash plugin crashed in the middle of streaming an album. I'm almost not allowed to complain about the flash plugin crashing.
• After and around and inbetween all that, I downloaded an .amz file (an Amazon MP3 download file, in fact, of the album I'm failing to stream) which I hoped to run through clamz (a command-line, open source tool that can interpret AMZ files). nautilus offers clamz as a launch option in the right-click menu, but it's not the default handler. If I select "properties" to set the default handler, clamz is not in the list of available handlers.
• After sending the HUP signal to gnome-shell, I've got rid of the "run" pop-up, but now something has happened to it's $PATH and future "run" pop-ups can't find anything in the standard locations, like /usr/bin.
• since the flash plugin died, nothing else seems to be able to make any sound, so I can't play the album I downloaded anyway.

I didn't set out to bug-hunt this morning, I'm actually trying to get some work done. Whilst this is a particularly bad case of stacked-bugs, it's unfortunately, pretty representative of what it's like to try and use a Linux desktop at the moment. Every day I go through a similar experience. I've just had to give up and log out and back in again. The shell path bug above has re-surfaced in a new session. Great. I'm waiting on a delayed laptop at work. I'm very tempted to cancel the order and just use a Mac Air instead (we have one spare). It seems I'm walking the inevitable path of F/OSS desktop frustration and the end for many people seems to be the Mac perhaps I should spare myself the pain of the journey. In the mean time, It's bye-bye to GNOME and off to Xfce for me.

I really should write these a bit more often. Wow, I can't believe it was over 4 years ago that I started having occasional face to face meetings with the ISC DHCP folks. The entire ISC DHCP team (of 5) was in town for an all-hands meeting, and Larissa Shapiro, the Product Manager for DHCP (and BIND) suggested it would be a good opportunity for another catch up. Given the current (bad) state of DHCP 4.2 in unstable, I thought this was an excellent idea, and so we all had lunch on Tuesday. I pretty much set the agenda, and it was

• general state of 4.2.2 in Debian
• situation with GNU/Hurd and their patch to fix an FTBFS (#616290)
• the current FTBFS issues with kFreeBSD (#643569)
• the embedded BIND sources in the DHCP source
• removal of the RFCs from the embedded BIND source (#645760)

The general state of 4.2.2 in Debian In a nutshell, it's a bit of a mess. We've got release critical bugs, build failures, the whole cat and kaboodle. It makes me very sad, because 4.2.2 was the first 4.2 series that I had a chance to upload, and I was very excited to do so, because it contains the hotly desired LDAP patches merged upstream. Unfortunately, it's also got the beginnings of the BIND/DHCP merger that's going to be BIND 10, and that is all a bit of a mess. It's directly responsible for the kFreeBSD FTBFS and the introduction of the RFCs, which are both keeping 4.2.2 out of testing. I gave the ISC folks a high-level overview of how Debian development works, and the normal progression of packages from unstable to testing to stable, and the release process and whatnot, and impressed upon them the implications of the current release critical bugs. I also showed them how Ubuntu development fitted into the picture. Finally, I showed them the popcon statistics for DHCP. I think they found it useful. FTBFS issues on kFreeBSD This was a good segue to #643569. The issue is actually with the embedded BIND sources. I'd already forwarded this bug upstream when it first happened, but I don't know what had happened to it. They seemed to act as if this was the first they'd heard of it. I'm hoping that they can get this fixed in 4.2.3, which is due around the end of the quarter. Embedded BIND sources Since we were already talking about an issue caused by the embedded BIND sources, we moved on to talking about #645760 and the existence of the embedded BIND sources in general. It should be pretty straightforward for them to strip the RFCs out of the source. They've already done it in the past for the DHCP sources, so I'm also hopeful that this will get resolved in 4.2.3. The issue of the embedded BIND sources is apparently a bit more complicated, although the day before our meeting, Michael Gilbert filed #643569 and #645760, so I hope that the ISC folks can take a look at these patches and see if it's feasible to adopt them. Patches for GNU/Hurd Finally we talked about #616290, which I know is near and dear to the GNU/Hurd porters' hearts. We probably spent the most time talking about this. The DHCP developers have concerns about accepting a patch for an OS that they do absolutely no testing on, and also questioned the viability of the OS in general. They stressed that they're fairly thin in numbers relative to what they have on their plate to achieve this year, and so pushed back pretty firmly on accepting the current patch. I relayed the frustration that the Hurd folks were having about a lack of dialogue around the patch (most of the interaction has been via an ISC support person). There was actually a bit of a split between the developers, with one of them appreciating that the Hurd was unlikely to go anywhere as a platform without a working DHCP client, so in some regards, they were condemning the platform by taking the position they were taking. They're going to go away and take another look at the patch and try to come back with some actionable feedback on what needs to change to make it more acceptable to them, so we'll see what comes of this. I'm not particularly optimistic that anything acceptable to the GNU/Hurd folks is likely to happen any time soon, but maybe if the patch gets cleaned up a bit more, I'll just bite the bullet and start applying it to the Debian package. BIND 10 One of the guys is more involved in BIND 10 than DHCP, and asked if I could help out with the packaging of a build dependency for BIND 10. It seemed like #578387 was languishing so I offered to pick it up. I've not packaged a library before, mainly because the library packaging guide has scared me off it (I feel I lack the deep C fu that seems necessary), but I figured that this would be a good learning opportunity, so I'm going to dive in.

There s been a lot of weather here in Seattle this week. It looks like the Tukwila DC s power blipped this morning. It gave me an excuse to update some configs on a few of the OpenVPN endpoints, re-configure some of the shorewall6 stuff, and enter a bunch of hosts and IPs into the BIG-IP s node list. It gives me a quick way to know what needs fixing first when things start breaking and is a lot easier to configure than NAGIOS. If I really wanted to get fancy, I could even write me some hot external monitoring scripts in perl. I am growing fond of this machine.

Debtags for derivative distributions Sometimes I do cool stuff and I forget to announce it. Ok, so I recently announced a new Debtags website. I forgot to say in the announcement that the new website does not only know of Debian packages: see for example this page, at the very bottom it says: "Distributions: oneiric, precise, sid, testing". This means that already, here and now, debtags.debian.net can be used to tag packages from both Debian and Ubuntu, and can easily be extended to cover the entire Debian ecosystem. If you are a package maintainer, you will notice that your maintainer page shows your packages from everywhere. If you want to filter things a bit, for example hide obsolete packages from an old Debian Stable or Ubuntu LTS, just click on the "Settings" link on the top right to configure the page. How it works The magic is in this mergepackages script, which is run daily, and exports merged Packages files at dde.debian.net. The debtags.debian.net concept of Packages and Sources files are just those all-merged.gz and all-merged-sources.gz. The merging is simple: that rebuild script processes files in order, and the first version of a package that is found is chosen as the base for the one that will go in the merged Packages file. Some fields like "Description" are just taken from this pivot package, others like Architecture or dependencies are merged into it. It's arbitrary, but works for me: the result has all the packages with all their possible architectures and dependencies, and is ready to be indexed with apt-xapian-index. At the moment I pull data from Debian and Ubuntu, but you can see that the script can easily be extended to pull data from any Debian-style ftp archive, so any Debian derivative can go in. I've already started negotiations with the Derivatives Census on how to add any Debian derivative and keep the list up to date. How to export tags for your own distribution I'll use Ubuntu as an example since the data is already available. The way you add Debtags to the Ubuntu packages file is just this one:

1. Get the full reviewed tag database
2. Optionally filter out those packages that you are not interested in
3. Tweak this script to build an overrides file.
4. Give the overrides file to your favourite ftp archive building tool.

The make-overrides is a bit rusty: if you improve it, please send me your changes. That is it, nothing else required, no excuses, it's ready, here, now! Hitches and gotchas This merged Packages file is a bit of a hack, and suffers from name conflicts across distributions, where two different softwares are packaged in two different distributions with the same name. Ideally, name conflicts should not happen: if a derivative decided to package kate and call it gedit, they deserve to have it tagged uitoolkit::gtk. I think it's rather important that the whole Debian ecosystem works as much as possible with a single package namespace. However, that reasoning fails if you take time into account: packages get renamed, like git and chromium, and may mean completely different things, for example, if you compare Debian Stable with Debian Sid. This last is a problem caused by debtags only working with package names but not package versions. I have a strategy in mind based on being able to override the stable tag database using headers in debian/control; it still needs some details sorted out, but I'm confident we will be able to address these issues properly soon enough. Why stop at the Debian ecosystem? Why indeed. I'm clearly trying to use FOSDEM, and the CrossDistribution devroom as the venue to discuss just that.

Long time no post. Anyway, I have some good news.

The Gtk code for Aptitude has been merged some time ago into the main development trunk and we now have a release in Experimental.

In case you've been living under a rock these past years, I shouldn't have to tell you what this is about :). Well, just in case.
The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects.

The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page.

We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian.

Help is immediately needed in many areas. Some examples:

• Map out which areas in Debian could benefit from a Summer of Code project and connect the right people with the right projects ideas


• Ideas, Ideas, Ideas for Summer of Code projects

By mid-March, we will need:

• Dedicated documentation to present Debian to the prospective student


• Publicity material to promote the Summer of Code at Debian


• Ideas, Ideas, Ideas for Summer of Code projects

Further in the spring:

• Mentors, people to review proposals, do interviews


• Ideas, Ideas, Ideas for Summer of Code projects

In the summer:

• Mentoring students


• Testing and feedback for projects


• Internal communication with the community

As you can see, there is much work ahead. It's time to pitch out your favorite pet project :)
Remember! The Summer of Code has become a prominent outreach forum for open source organizations. It puts a spotlight on each of them to provide a well-rounded and deep experience of open source development.

Right now, you can help with the Wiki, join us on IRC on #debian-soc on OFTC or join the mailing-list at soc-coordination on alioth.

The short "flyers-friendly" URL for the Summer of Code at Debian is : <http://wiki.debian.org/gsoc>. Publicize it!

See you this summer!

So, at work we have a little single port IP KVM, it is a StarTech SV1107IPEXT - it's not a "bad" bit of kit, if you're completely configured for using it in the way they expect... When you're not, then it throws a NullPointerException when you try to connect with it's Java applet. This morning (mostly because the monitor and keyboard I had been using for building stuff on my desk has gone missing) I decided I'd try again with the device, it's not on our default office network range, mostly because it might not always be in the office, so I quickly added an ip alias using ip addr add 192.168.0.59/24 dev wlan0 on my laptop to bring up a route to it. Navigated to the page and asked it to fire up the Java applet. Straight off, a NullPointerException happens - hmm. So looked at what was being logged by the JVM - it was trying to run ifconfig (no, really, the java applet ran ifconfig... with no path...) which, on my debian laptop, is not in the default path... so I went and make a quick wrapper in ~/bin for it... right - now it can run that... still a NPE, hmm. So look a little closer, it's looking for the MAC address assigned to the IP that you're coming from... no, really! WTF! So I went and hacked my little ifconfig wrapper to rewrite the address for wlan0 to be what the KVM expected it to be, low and behold, I can now run the java client (hoorah!). Why the heck are they doing that though - that's just plain insane! On the plus side, I now have a work around, on the minus side, egad that's ugly!

As sort of new year's resolution I started picking up the habit to work on release critical bugreports for squeeze again. The number is way to high to be healthy, but at least it is (still) below the amount of release critical bugreports for unstable. It will be an uneven fight because it seems that there are quite some people working on weeding out release critical bugreports in unstable, but those who are interested in weeding out releasing critical bugreports in stable seems to be limited, even though it is one of our supported releases and thus should receive quite some attention, at least by the corresponding package maintainers themself. So here is the list that I managed so far:

• 651792: not relevant for squeeze
• 653520: builds on squeeze
• 654568: re-add version information lost in reassign
• 654276: not relevant for squeeze
• 654257: not failing on squeeze
• 654810: not happening on squeeze
• 654459: not relevant for squeeze
• 654406: not release critical at all, shipped as upstream
• 655007: python2.7 isn't default in squeeze
• 655372: doesn't fail in squeeze
• 527403: libjack-dev in squeeze provides libjack0.100.0-dev
• 622903: not relevant for squeeze
• 625764: squeeze has older version of libvelocity-tools-java, not affected
• 654818: does work in squeeze
• 647795: squeeze still has libahven1-dev
• 647796: squeeze still has libahven1-dev
• 636823: not obsolete in squeeze
• 628500: no perl 5.14 in squeeze
• 629255: no perl 5.14 in squeeze
• 629284: no perl 5.14 in squeeze
• 629293: no perl 5.14 in squeeze
• 636132: no perl 5.14 in squeeze
• 636268: no perl 5.14 in squeeze
• 636271: no perl 5.14 in squeeze
• 636517: no perl 5.14 in squeeze
• 636520: no perl 5.14 in squeeze
• 636521: no perl 5.14 in squeeze
• 636522: no perl 5.14 in squeeze
• 636823: not obsolete dependencies in squeeze

That makes 29 squeeze RCs squashed so far, I hope I can keep up with it. Enjoy!

/debian permanent link Comments: 2 Flattr this

Like last year, here s a list of Debian related goals that I d like to achieve this year. I might not have the time to implement all the projects, but I like to write them down to keep me motivated. And maybe it can inspire other people to implement some of them (or to help me).

1. Finish the translation of the Debian Administrator s Handbook The target is to have the book available in April. It would be nice to complete the liberation fund until then so that the book is immediately made available under a DFSG-free license.
2. Update the Debian Administrator s Handbook for Wheezy
Translating the book in English is only the start of the journey. The real challenge is to keep the book up-to-date with each subsequent release of Debian. And Wheezy should hopefully be released in 2012 since the freeze is in June.
3. Design and implement the Debian Package Maintenance Hub It s an ambitious project that aims to merge and replace the PTS, the DDPO and their respective mail variants. It should also standardize the flow of information directed towards package maintainers. I m going to use the DEP process to drive this project. This could easily take most of the year, but hopefully I ll motivate other people to chime in and help.
4. Implement dpkg --check-db and dpkg --repair-db While dpkg is fairly reliable, it s not exempt of bugs and more annoyingly, harddrives/filesystems are not 100% reliable either, thus it happens that some internal database files get corrupted. Given that most files are text based, advanced users can manually fix them but many less skilled users are just left with a broken system that they tend to reinstall. To avoid this, we could provide a command that would try to automatically bring back the internal database to a sane state by looking for a working backup to restore (while at the same time marking some packages as requiring re-installation since we have some indications that they were present).
5. Implement storage of dpkg s internal files in Git This would be an extension of the former idea. Installing a package dpkg-db-history (any idea for a better name?) would setup dpkg hooks that would record every database change in a git repository. This repository could then be used to restore the last working version of the database.

Besides those concrete projects, I want to do better than last year on the topic of funding my Debian work. I will thus reiterate some objectives:

1. Write useful articles for Debian users and Debian contributors. They should complete the pages Mastering Debian, Contributing to Debian 101, Debian Packaging Tutorials, and help me increase the audience of this blog.
2. Write at least one Debian-related ebook (different from the Debian Admin Handbook) and sell it. It could be an ebook targetting testing users since I believe that many more users could benefit from it if they had some better knowledge of the limitations and of the way to mitigate the problems that arise from time to time. Or maybe it could be an ebook for people who want to start contributing to Debian, it could even be bundled with a few hours of mentoring.
3. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products. This means doing 3,5 times better than in 2011. It should be doable given that the sales of the Debian Administrator s Handbook will contribute to this goal (once the translation is over).

That makes up lots of challenges for this year. Feel free subscribe to my newsletter to stay up-to-date with my progress and to get my monthly summary of the Debian/Ubuntu news. It s also a good way to help me reach those goals since you will be informed of all my new projects.

11 comments Liked this article? Click here. My blog is Flattr-enabled.

Just recently arrived from DHL, a solid-run CuBox. I guess nobody who knows me will be surprised when I tell it features an ARM cpu. Specifically an Marvell Armada 510. It features ARMv7 compatibility, with a slight twist of replacing NEON extensions with iWMMX extensions. On the boasting side Armada 510 promises 1080p video decoding and OpenGL ES graphics acceleration (closed source, unfortunately).
The tiny form factor of CuBox is pretty much more than the impressive amount of connectors included;

* Gigabit ethernet
* 2*USB
* eSATA
* HDMI out
* s/pdif optical audio out
* microSD slot
* microUSB serial/jtag port

The last item being important as it makes CuBox unbrickable.. Some will probably lament the lack of WiFi/Bluetooth, but get everything in one device ;). Besides, the USB slots are there to be filled..
Getting started was an slightly rough ride, as in the included Ubuntu (10.04 LTS), X refused to start. After wrongly suspecting that my Display was at fault, turned out the microSD included was slightly corrupted, and some critical contents of xkb-data package were garbage. After reinstall of that package, everything worked, including playing Big Buck Bunny in FullHD with totem.
Biggest disappointment so far is the non-mainline kernel, based on old 2.6.32.9. Some mainline support of Armada 510 exist, but will it work with the proprietary graphics code?

I was on the brink of mindlessly clicking through the ACLU action center as usual to send an email opposing SOPA. But then I read their boilerplate text, and ended up cancelling the letter to my rep and instead sending this quick note to the ACLU:

Your SOPA suggested letter text supports current copyright law, and also backhandedly supports PIPA (the Senate version of the bill). This is far too weak of a position. As a donor, I ask you to take a stronger position that current copyright law unjustly restricts free speech, and that no further enforcement measures should be instituted until that fundamental problem is addressed. At least take on BOTH of these bills strongly. Most of the significant Internet is blacked out today to oppose both bills -- why would you cede so much ground to copyright maximalists? We have the support to oppose and defeat both bills.

For reference, here was their text:

While I believe it's important to protect copyrighted material online, the language of the Stop Online Piracy Act (SOPA) is flawed and will lead to the blocking of lawful content. Unlike the Senate version of the bill, SOPA eliminates the concept of sites 'dedicated to infringing activity' and enables law enforcement to target all sites that contain some infringing content -- no matter how trivial. The potential for impact on non-infringing content is much greater under SOPA than under other versions of this bill. Sites with user-generated content, like YouTube, Twitter, and Facebook, would be especially vulnerable, as one small piece of infringing content could lead to blocking the entire site. Even though proposed changes would narrow the amount of lawful content impacted, the changes don't go far enough. It is still likely that search engines will end up blocking access to perfectly legal online content. Congress should focus not just on the goal of protecting copyright owners, but also protecting the speech rights of consumers and providers who are reading and producing wholly non-infringing content. Congress must eliminate the collateral damage to protected non-infringing content. Only in that way will Congress truly achieve its goal of protecting authors while respecting the constitutional right to free speech.

Maybe I'm overreacting, but I dislike it when good organizations take weak positions unnecessarily. Usually this is not a problem with the ACLU, for me. It doesn't help that I keep seeing this meme everywhere in the anti-SOPA/PIPA conversation: "I agree we need to do something about piracy, but not this..." I don't think we need to do anything to fix violations of an extraordinarily unjust law until the law itself is fixed. I don't find that to be a very radical position.

Once again, lawmakers are considering a stupid protectionist measure and this time it s the US, so it has some effects outside the US too. Once again, some websites have taken themselves offline and caused great inconvenience to their supporters. This is really annoying. Protesting about threats to take websites offline by taking websites offline is as stupid as protesting against a ban on kissing by not kissing. It just demonstrates that you can do without your websites/kisses if you must. I feel it s much better to use websites to distribute information and call people to action, like this epetition for UK citizens and residents, or by asking your associations and suppliers to oppose these measures and their supporters. Wikipedia is probably a bit to blame. Although it called its action a blackout, it wasn t one and there were still many ways to access its information. In fact, if you use NoScript, the banner didn t even display and there s only a line on the front page to say anything is happening. The one that really annoyed me was identi.ca, which even turned off its API so clients just started spewing errors everywhere (I returned to my desk to a stack of retry questions). That stopped some of my websites from distributing a link to the anti-SOPA epetition because they read from my identi.ca stream how much other anti-SOPA activism was hindered? I ve been told that Evan held a vote, but I didn t see it, so I didn t vote and I don t know the turnout or anything. How many people voted for the blackout because they use other sites like twitter more anyway? Banners: yes; Blackouts: no.

Yesterday, I uploaded hdf5 1.8.8 in unstable. This new version, which has been available in experimental for a while, is a major step in the HDF5 packaging. For those who are using this package, besides the switch from version 1.8.6 to 1.8.8, the changes are the following:

• Since upstream is now trying to keep a consistent ABI/API, packages have been renamed from libhdf5-xxx-X.Y.Z (X, Y and Z being the version number) to libhdf5-xxx-7 (7 being the version of the soname)
• The package libhdf5-serial-* have been renamed to libhdf5-7 or libhdf5-dev
• Symbol files have been added for all the libraries.
• arm archs have also libhdf5-openmpi-dev
• Support of HURD, armhf & s390x
• Help is now up to date and the debian/html.tgz.uu removed (thanks to the source format v3.0, two source tarballs are now used)
• A new package hdf5-helpers which contains h5cc, h5c++ and h5fc has been introduced
• Fix many lintian warnings
• Java HDF has been updated to version 2.8

More information about the transition:
http://release.debian.org/transitions/html/hdf5.html TODO: Fix the FTBFS (Fail To Build From Sources) under sparc & ia64.

Those lovely people over at Flickr have finally bitten the bullet and are turning off FlickrAuth in the summer, meaning that all applications that use the Flickr API need to use OAuth. This is something I totally agree with, whilst FlickrAuth works and was clearly an important influence on OAuth, it's a single-service protocol when OAuth has managed to get massive adoption and a huge developer base. The problem I've got is libsocialweb, which has a Flickr module that allows both fetching of your contact's recent photos and uploading images. This uses FlickrAuth so at the end of July will suddenly stop working. I've got enough on my plate at the moment and would love for more people to understand how the entire social spagetti works, so this is a call for a volunteer to work on this, for which I'll obviously be available to offer any guidance and mentoring required. There are two ways of approaching this, the easy way and the slightly harder way. The easy way is to update libsocialweb to use an OAuthProxy instead of a FlickrProxy, and update the module metadata so that Bisho uses the generic OAuth flow instead of a Flickr-specific flow. This should be fairly simple and needs to happen soon so that any distributions that are using libsocialweb don't break in the summer. The harder way is to add Flickr support to gnome-online-accounts, using the Twitter service as an example, and then port the Flickr service in libsocialweb to use gnome-online-accounts to authenticate. I've a proof of concept for the librest-goa integration which will be a useful starting point. This is more of a proof of concept for libsocialweb, we've been looking at moving away from Bisho but haven't done anything substantial yet. Ideally both of these happen, so the current code will continue to work in the future and the GOA work demonstrates how GOA and libsocialweb would work together. So, anyone interested?

The increasing storm of localization NMUs and uploads, related to debconf translations, has an interesting effect: some teams are now incredibly active at pushing translations for their language towards the magic 100%. So, after Danish (effort lead by Joe Hansen) and Dutch (effort lead by Jeroen Schot) which I already mentioned, it seems that the Italian localization team started engines and is now taking off. It will be interesting to watch these teams competing (in a friendly way) to climb in statistics over next months..:-) So, if you're Italian (or speak it well) and want to help, please join the Italian l10n mailing list (debian-l10n-italian on lists.debian.org. If you're Danish or Dutch and want to stay ahread the two others, please joind debian-l10n-danish or debian-l10n-dutch. PS: why did I write "Zou" in this post's title? Because this is a common French interjection for "Whoooosh" and because this is part of the nickname of the tireless and incredibly active, in many places, Francesca Ciceri, aka MadameZou, who's is doing so much for Italian localization (and many other areas in Debian such as the publicity and web team). And that really deserves some lights, trumpets, etc.

Finally I've also find time to test ColorHug on openSUSE 12.1. For my experiences on Debian check previous blog post. Unfortunately on openSUSE calibration is also not that easy. First of all, you have to install patched argyll CMS from multimedia:color_management repository. You can also install gnome-color-management (and colord), but for some reasons they did not offer me any screen for calibration, so I gave up on this and tried manual calibration using Argyll. After looking into documentation, it seems to be pretty straightforward:

$ dispcal -y l -o /tmp/L220x
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Display adjustment menu:
Press 1 .. 7
1) Black level (CRT: Offset/Brightness)
2) White point (Color temperature, R,G,B, Gain/Contrast)
3) White level (CRT: Gain/Contrast, LCD: Brightness/Backlight)
4) Black point (R,G,B, Offset/Brightness)
5) Check all
6) Measure and set ambient for viewing condition adjustment
7) Continue on to calibration
8) Exit
Doing check measurements
  Current Brightness = 190.74
  Target 50% Level  = 36.14, Current = 47.98, error =  6.2%
  Target Near Black =  1.91, Current =  4.11, error =  1.2%
  Current white = x 0.3424, y 0.3179, VDT 5910K DE 2K 18.3
  Target black = x 0.3424, y 0.3179, Current = x 0.3123, y 0.2711, error = 18.06 DE
Press 1 .. 7
1) Black level (CRT: Offset/Brightness)
2) White point (Color temperature, R,G,B, Gain/Contrast)
3) White level (CRT: Gain/Contrast, LCD: Brightness/Backlight)
4) Black point (R,G,B, Offset/Brightness)
5) Check all
6) Measure and set ambient for viewing condition adjustment
7) Continue on to calibration
8) Exit
Commencing device calibration
The instrument can be removed from the screen.
$ dispwin -I /tmp/L220x.icc 
$ dispwin -L

It turned out, that the change after calibration are quite minor here. This is sort of thing I've expected from past experiences with editing photos here, but anyway, now I trust results here even more :-).

Filed under: English Photography Suse 0 comments Flattr this!

I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit.
Secure boot requires that all code that can touch hardware be trustedRight now, if you can run unstrusted code before the OS then you can subvert the OS. Secure boot gives you a mechanism for making sure you only run trusted code, which protects against that. So your UEFI drivers have to be signed, your bootloader has to be signed, and your bootloader must only load a signed kernel. If you've only booted trusted code then you know that your OS is safe. But, unlike trusted boot, secure boot provides no way for you to know that only trusted code was executed. That has to be ensured by OS policy.

This doesn't sound like too much of a problem. But it is. Imagine we have a signed Linux bootloader and a signed Linux kernel, and that these signatures are made with a globally trusted key. These will boot on any hardware using secure boot. Now imagine that an attacker writes a kernel module that sets up a fake UEFI environment, stops the kernel from running code and then executes the Windows bootloader - kind of like kexec, but a little more fiddly. The Windows bootloader believes that it's performing a secure boot, but in fact everything that it believes is trustworthy is the attacker's fake UEFI code. The user's encryption passphrase is logged, the Windows kernel is modified to hide the Linux code and despite everything looking fine your credit card details are on their way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that anything is wrong is that boot will be slightly slowed down.

Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.

(The same applies to Windows, of course. Windows 7 allows you to disable driver integrity checks. Windows 8 will have to forbid that when the system's using secure boot)
LicensingGPLv3 has various requirements for signing keys to be available. Microsoft's new requirement that systems support the installation of user keys would let users boot their own modified bootloaders, so that may end up being sufficient to satisfy the license. But we're then beholden on Microsoft - if they remove that requirement then users lose that freedom, and suddenly we're in an awkward licensing situation. There are ongoing conversations about exactly what we're able to do here, but it's not a solved problem.
Key distributionThe UEFI spec doesn't describe or mandate a central certifying authority. Microsoft require that everyone carry their key. We could generate our own, but we have much less sway with vendors. There's no way to guarantee that all hardware vendors will generate our key. And, obviously, if we generate a key, we can't just hand the private half out to others. That means that it becomes impossible for people to produce derivative versions of Linux distributions without getting their own key. The kind of identity verification that would be required for getting such a key is likely to be expensive, and also fairly likely to require that the distribution have a legally registered company in order to facilitate the identity verification. Think Extended Validation certificates, not Startssl Free. Hobbyist Linux distributions will be a thing of the past.
Doesn't custom mode fix this?Microsoft's certification requirements now state that all systems must support a custom mode, implying that it will be possible for a user to install their own keys. Linux vendors would then be able to ship with their own keys on the install media and impose their own policies. Everyone's happy. It's not really good enough, though. People have spent incredible amounts of time and effort making it easy to install Linux by doing little more than putting a CD in a drive. Asking them to go into the firmware and reconfigure things adds an extra barrier that restricts the ability to install Linux to more technically skilled users. And it's even worse than that. This is the full description of the requirement for custom mode:

1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
   
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
   
3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

There's a few things missing from this, namely:

• Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Vendors are using the UEFI transition to differentiate themselves by coming up with their own unique firmware interfaces. Custom mode is going to look different everywhere.
• Any description of the key format. A raw binary representation of the key? An EFI_SIGNATURE_DATA struct? A base64 encoding of one, further protected with ROT13? We just don't know.
• Any way to use custom mode for unattended installs. It's a firmware interface that requires a physically present user. Want to install a few thousand machines over the network? This isn't a scalable approach
• and this one's nitpicking, but there's not actually any requirement that the user be able to add keys - a vendor could conform to this language by only letting users delete keys. This is actually ok as long as the user deletes Pk, because then we'll effectively be back in setup mode and can install our own keys from the installer, but it still results in some practical problems

So no, custom mode doesn't make everything ok. Custom mode with a mandated UI and a documented key format would be much closer, but it wouldn't solve the problem of unattended automated installs.
SummaryWe can write the code required to support secure boot on Linux in a minimal amount of time - in fact, most of it's now done. But significant practical problems remain, and so far we have no workable solutions for any of them.

comments

The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the starsand in the middle you see the blue centerlight pop and everybody goes Awww!

~Jack Kerouac