sage@guug This January, I held an updated version of my "Gitify your life" talk at sage@guug, which is the Munich chapter of the German Unix User Group. Once again, it was quite successful and turnout was about three times that of normal attendance. Afterwards, I was asked if I would be willing to hold the same talk at the German Unix User Group's Spring Meeting in 2014 as the programme for 2013 has been finalized for quite some time, already. Obviously, I said I would be willing to do that and will submit the talk once registration opens. Open Source Days By the way, I am writing this post from a hotel room in Copenhagen. Tomorrow, there will be a world first... "Gitify your life" will not only be held as a talk, it will be expanded into a full three hour workshop (with the option of extending it if there's interest as the room will be free after my workshop). Having never held a workshop of this scope, I am really looking forward to this experience. Besides enabling me to get people up and running with their personal data, this will allow me to see where new users are having issues with vcsh. I keep hearing of people not getting their heads around the concept easily, but no matter how many promises of updates to my docs I get while helping them, no one really follows through with that promise once they know how to use vcsh. Maybe I will find someone willing to follow through and/or simply gather enough material for docs 2.0. Your place? As an aside, and I will probably try to put a real announcement together as well, if you know of a conference, user group or other place where a lightning talk, a full talk, or a workshop about one or all of these topics would fit, please let me know. I will gladly submit proposals to or accept invitations from most places as long as I can spread this message. Especially if the venue happens to be reasonably close to Southern Germany, covers travel cost, or if they can guarantee video recording of the talk. Joey Hess has speculated if the talk isn't really called "git naked" as I seem to keep on giving that particular talk at venues which don't have video recordings. Please help me make Joey happy... ...with a video recording, I mean.

I just received a WD 500GB Blue, to replace the hard drive of my wife's computer. First thing after unpacking: start to test. And I was right to do it... there are bad blocks on it. The story: I tend to do proactive replacement of hard drive, to avoid losing too much data or be in hurry when the current one fails. There are two ways to monitor a hard drive:

• install smartmontools, it is the most proactive tool for detecting a hard drive that will fail
• just monitor your log using logcheck and logcheck-database

Logcheck is pretty straightforward to install. It scans your log every two hours and send you a report of what is happening. It is not a very precise tool and you have to tune it a little bit to just send you what is relevant (install extra rules to ignore what you know is not of interest). Whenever you start to see log entry like that:

Jan 24 18:16:08 foo kernel: [ 1965.343980] ata5.00: exception Emask 0x50 SAct 0x39 SErr 0x800 action 0x6 frozen
Jan 24 18:16:08 foo kernel: [ 1965.343991] ata5.00: irq_stat 0x08000000, interface fatal error
Jan 24 18:16:08 foo kernel: [ 1965.344001] ata5: SError:   HostInt  
Jan 24 18:16:08 foo kernel: [ 1965.344036] ata5.00: failed command: READ FPDMA QUEUED
Jan 24 18:16:08 foo kernel: [ 1965.344055] ata5.00: cmd 60/08:00:18:31:44/00:00:1a:00:00/40 tag 0 ncq 4096 in
Jan 24 18:16:08 foo kernel: [ 1965.344059]          res 40/00:2c:e6:c2:fd/00:00:26:00:00/40 Emask 0x50 (ATA bus error)
Jan 24 18:16:08 foo kernel: [ 1965.344071] ata5.00: status:   DRDY  
Jan 24 18:16:08 foo kernel: [ 1965.344081] ata5.00: failed command: WRITE FPDMA QUEUED

It is a good time to think about changing your hardrive -- but it is maybe too late. Smartmontools (aka smartd) is dedicated tool to monitor hard drives and do a good job. I think it is not installed by default in Debian, but it should be. It scans your hard drive for SMART capabilities and monitor the health of the HD using internal tools. In the case of bad blocks, you will start to see entry like that:

Feb 17 14:05:17 bar smartd[1268]: Device: /dev/sda [SAT], 1 Currently unreadable (pending) sectors
Feb 17 14:35:17 bar smartd[1268]: Device: /dev/sda [SAT], 1 Currently unreadable (pending) sectors

Obviously when you see this log, it is also a good time to change your hard drive. In the case of my wife's HD, I just got data from logcheck. It means that the error is not that important (transient failure, something is wrong but the HD can cope with it). But I still decided to get a new one for my wife. Whenever, I receive a new drive, the first thing I do is to check it for errors. You can do that using the program badblocks in write mode. It takes ages to test (count up to 1 day for 1TB on USB), but at the end you know that you have a good candidate -- where it is worth install your data. You just have to follow this procedure

1. dmesg grep sd
2. try to find what drive is the one you want to test in the output of 1.
3. cfdisk /dev/sdX, sdX being the drive you want to test
4. check that what you see in cfdisk is what you expect to test: right name and capacity for the drive
5. sudo badblocks -wvs /dev/sdX
6. run sudo tail -f /var/log/syslog in parallel just in case
7. wait

If some errors appears in /var/log/syslog, you know something bad is happening. Whenever you have a single failing block, don't think it is ok. It is NOT ok for a HD to start its life with failing blocks. In this case, repack the drive and send it for replacement ASAP. In the case of my hard drive: smartd mail:

The following warning/error was logged by the smartd daemon:
Device: /dev/sda [SAT], 15 Currently unreadable (pending) sectors

syslog entries:

Mar  2 20:52:57 foo kernel: [ 8317.419715] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar  2 20:52:57 foo kernel: [ 8317.419724] ata4.00: irq_stat 0x40000008
Mar  2 20:52:57 foo kernel: [ 8317.419732] ata4.00: failed command: READ FPDMA QUEUED
Mar  2 20:52:57 foo kernel: [ 8317.419747] ata4.00: cmd 60/80:00:00:af:08/00:00:28:00:00/40 tag 0 ncq 65536 in
Mar  2 20:52:57 foo kernel: [ 8317.419750]          res 41/40:00:65:af:08/00:00:28:00:00/40 Emask 0x409 (media error) <F>
Mar  2 20:52:57 foo kernel: [ 8317.419758] ata4.00: status:   DRDY ERR  
Mar  2 20:52:57 foo kernel: [ 8317.419764] ata4.00: error:   UNC  
Mar  2 20:52:57 foo kernel: [ 8317.423959] ata4.00: configured for UDMA/133

I am not blaming any particular brand (like Western Digital), all computer parts I have ever bought had to follow the same procedure and it is a known fact that computer parts as a non-zero percentage of chance to be DOA (dead on arrival) or after a few weeks. But as a consumer you should be aware of that and take action to avoid spending 10h configuring your computer to see it failing after a week... The waste of time to test is a win on the long term.

Do you want to set up your own TV station, schedule videos and broadcast them on the air? Using free software? With video on demand support using free and open standards? Included a web based video stream as well? And administrate it all in your web browser from anywhere in the world? A few years now the Norwegian public access TV-channel Frikanalen have been building a system to do just this. The source code for the solution is licensed using the GNU LGPL, and available from github. The idea is simple. You upload a video file over the web, and attach meta information to the file. You select a time slot in the program schedule, and when the time come it is played on the air and in the web stream. It is also made available in a video on demand solution for anyone to see it also outside its scheduled time. All you need to run a TV station - using your web browser. There are several parts to this web based solution. I'll mention the three most important ones. The first part is the database of videos and the schedule. This is written in Django and include a REST API. The current database is SQLite, but the plan is to migrate it to PostgreSQL. At the moment this system can be tested on beta.frikanalen.tv. The second part is the video playout, taking the schedule information from the database and providing a video stream to broadcast. This is done using CasparCG from SVT and Media Lovin' Toolkit. Video signal distribution is handled using Open Broadcast Encoder. The third part is the converter, handling the transformation of uploaded video files to a format useful for broadcasting, streaming and video on demand. It is still very much work in progress, so it is not yet decided what it will end up using. Note that the source of the latter two parts are not yet pushed to github. The lead author want to clean them up a bit more first. The development is coordinated on the #frikanalen IRC channel (irc.freenode.net), and discussed on the frikanalen mailing list. The lead developer is Benjamin Bruheim (phed on IRC). Anyone is welcome to participate in the development.

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (78.31 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Debian packaging I wanted to update publican to the latest upstream release but I stopped after a few hours of work during which I filed two bugs that a modicum of testing should have caught before release. So I decided to wait for the next minor release. I uploaded python-django 1.4.4 and 1.4.5, new upstream maintenance and security releases which thus went into wheezy. I also prepared a stable update of Django (1.2.3-3+squeeze5) which required me to backport the last 2 sets of security patches. I uploaded a new revision of wordpress to fix a problem with TinyMCE (#700289) and to update/add many translation files (#697208). Bug reporting and misc fixes Live-build issue. I experienced some intermittent failures when building HDD live images with live-build on armel. Daniel Baumann directed me to the problematic piece of code (the oversizing of the image size was not enough) so I committed a small fix by increasing the oversizing factor to 6%. Live-config issue. I also reported another issue that I diagnosed in live-config (#701788), namely that the script which setups sudo was failing when the default user is root. git-buildpackage issue. I filed #700411 after noticing that git-import-orig imported the debian directory provided by upstream. Those directories are not used with 3.0 (quilt) source package and their presence in the upstream branch is thus harmful: any change to the upstream debian directory will result in conflicts when you merge a new upstream release in your packaging branch. rubygems integration. Later I had to package a bunch of ruby applications that were using Bundler and I wanted to reuse as many packaged ruby modules that I could. But for this, those modules had to provide the required rubygems meta-information. I filed #700419 to request those on rake-compiler and with the help of C dric Boutillier (and others on #debian-ruby), we identified a bunch of ruby modules which could get those with a simple recompilation. I filed bin-nmu requests in #700605. Misc bugs. simple-cdd offers to select profiles to install but I noticed that the associated debconf template was not translated (#700915). The startup scripts (provided by initscripts) in charge of activating the swap are supposed to handle a noswap kernel command line option to disable swap. In #701301, I reported that the option was not working correctly if quiet was present first in the command line due to spurious break statements. Debian France Administrative work. We were late for some legal procedures so I wrote the report of the last general assembly and sent it to the Tribunal d instance of Sarreguemines to record the changes in the administrative board. I also completed the special register of the association, it s a notebook that is legally required and that must document any important change in the governance structure of the association (new members of the board, headquarters change, new bylaws, etc.). Galette developments. Debian France is funding a few enhancements to the Galette free software that we re using to manage the association. I am in touch with the Galette developer to answer his questions and ensure that his work will meet our needs. Librement I have been looking for talented developers who have a genuine interest in my Librement project. I want to fund the initial development of the project but I don t have the means to fund it entirely. So I really wanted to find developers who would find an interest beside the money that I would pay. I got in touch with the team of developers from Scopyleft and they look like very good candidates. But they re heavy users of the Scrum development method and asked me to play the role of product owner . So I started to describe the project with user stories (i.e. create the backlog in the Scrum jargon), you can have a look at them here on trello.com. If you re interested by the topic of free software funding, feel free to review and to send me your comments. My goal is clearly to have a minimal viable product with the first iteration(s) that I fund and then use the platform itself to fund further developments of the project. Thanks See you next month for a new summary of my activities.

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

This post is just a status update for the Openstack packaging, after the next version froze last week. The Openstack bi-annual summit of next April will take place this year in Portland, Oregon, and if everything goes as plan, Grizzly will be released just before the summit. Grizzly will be out a bit before the next Ubuntu in April, as releases are following the one of Ubuntu. Openstack uses town names for it s release names: Austin, Bextar, Cactus (2011.1), Diablo (2011.2), Essex (2012.1), Folsom (2012.2), Grizzly (2013.1). I started to seriously work on the Openstack packaging in October, and never stopped working on its packaging until now. Slowly, but surely, preparing all the packages and their dependency python modules. One package at a time, working all this every day. Folsom works now pretty well and can be used in production, and I maintain it for security (along with Essex, which is in Wheezy). Then Grizzly was frozen last week, on the 22nd of February, with the G3 release. As I already worked on packaging the G2 release in January, managing the packaging of G3 was fast. On late Sunday, I had a repository with Grizzly built, and its corresponding python (build-)dependencies. But while just building your own repository is easy, having all the dependencies in Debian is a lot more work. As of today, if I include all the python modules, I have (at least) touch around 50 packages in total when working on Openstack. Many of them were simply built from scratch. The only python dependency that needs an upgrade in Experimental, so that all dependencies are satisfied, is a new version of pep8. The rest of is new python modules that were not in Debian, and which are currently waiting in the NEW queue for ftp masters approval: python-pecan, python-tablib, python-wsme and websockify. Some of these python modules have been waiting there for a long time, like python-pecan (it s been waiting in the NEW queue for more than 35 days now), some like websockify and python-wsme have been uploaded only this week. I really hope it can be possible to have all of Grizzly in Debian before the next Openstack summit (this depends mainly on the ftp-masters). Note that I do not intend to apply security patches in Grizzly until it is released as the new Openstack stable. So use my private Grizzly repository as your own risk. I intend to fix this by working on some constant integration to have nightly builds, like many people are doing with Openstack. If you want to try it out: deb http://archive.gplhost.com/debian grizzly main

About 5-6 weeks ago, I wrote about the Wheezy release progress, so it is about time for another update. According to UDD, we are down to 204 RC bugs (down from 249, since my last post). It is not quite the 2.4 RC bugs per day actually it is about 1.1 RC bug a day. Unfortunately, we do not appear to be fixing bugs faster than we are reporting them at the moment. If you look at Richard Hartmann s post from last week, then we had 206 RC bugs left. Even worse, we appear to have regressed between week 7 and 8 of this year (194 to 206). If you want the Wheezy release to happen soon, please consider helping us by providing bug fixes that comply with the Wheezy freeze policy. If the pace of RC bug fixes do not pick up, the alternative is that the release team deals with the bugs. Note that deals generally falls into one of 2 categories. Either we defer/ignore the problem for Wheezy[1] or we remove affected packages from Wheezy/testing. Particularly, if we have to remove packages, they may take reverse dependencies with them as collateral damage. I do not like these tools anymore than you do. But if the RC bugs fixes are not coming in, it is the only two tools we have left. [1] Meaning that at best the bug fix will occur at Wheezy point release at worst, not at all.

Hi planet.ocaml.org. Just a quick post to thanks Marek Kubica for his help on the planet.ocaml.org spring cleaning. Here are the feeds that have been removed:

• Red Lizard Software

http://redlizards.com/blog/feed/?tag=ocaml

• Alp Mestan

http://blog.mestan.fr/feed/?cat=16

• Arlen Cuss

http://www.sairyx.org/tag/ocaml/feed/

• Daniel Patterson

http://blog.dbpatterson.com/rss

• Victor Nicollet, cannot find any feeds on the new blog

http://www.nicollet.net/toroidal/ocaml/feed/

• OCaml Hackers

http://ocamlhackers.ning.com/profiles/blog/feed?tag=ocaml&xn_auth=no

• Mauricio Fernandez, offline

http://eigenclass.org/R2/feeds/rss2/all

• Christopher Conway, no OCaml-related posts since 2008

http://procrastiblog.com/category/ocaml/feed

• Liquidsoap, cannot find the HTML blog on the website

http://savonet.sourceforge.net/liquidsoap.rss Here is the feed that have been added:

• Marc Simpson

http://newblog.0branch.com/rss.xml Here are the feeds that have been updated:

• Jane Street Capital now points to

https://ocaml.janestreet.com/?q=rss.xml

• Jamie Brandon now points to

http://scattered-thoughts.net/atom.xml

• Mihamina Rakotomandimby now points to

http://www.rktmb.org/feed/tag/ocaml/atom

• Dario Teixeira now points to

http://nleyten.com/feed/tag/ocaml/atom

• Erik de Castro Lopo now points to but FP-Sydney has been removed

http://www.mega-nerd.com/erikd/Blog/index.rss20

• Y-Node now points to

http://y-node.com/blog/feeds/latest/ If you want that we had back your blog, please follow the howto add your feed to planet. We didn't have removed feed on purpose, this was just a way to get rid of a lot of 404, And don't forget, planet.ocamlcore.org is now served by planet.ocaml.org! Update your feed reader.

Also this year I registered a booth in the name of the Debian Project at Chemnitzer Linux-Tage. Unfortunalety this is the second time in the row, that we seem to be short of manpower while preparing the booth. Actually just one person was able to commit his available time. A general offer was announced by 3 people (including me). This makes me a little sad, cause CLT is a very community driven event which is really nice organized. I always liked to chat and discuss with very interesting people from other projects and visitors. As the CLT runs a 6 track lecture program with commonly very good lectures, it is not possible to get the booth running into good shape with such a small amount of volunteers. If you feel you are interested into visiting the Chemnitzer Linux-Tage and want to make our booth a success like last years for the Debian Project, please have a look into my announcment and our coordination wiki. So please ... let come more brave people into our band wagon! Don't wait to long! Registration period for (possibly sponsored) Booth tickets (read here) ends on 4th March, many thanks!

Some of our customers are using central CUPS systems for managing their printer infrastructure. In the last years the demand for support printing (called Airprint) from mobile apple products increased. This worked well for us on Debian squeeze as documented here (updated scrips). I tried this on a fresh installed Debian wheezy amd64, but no printer was found on any IOS device. Hmm .... let's see if the printer is announces via avahi:

$ avahi-browse -a   grep -i print
+   eth0 IPv6 Kyocera FS-1020D @ service                    Internet Printer     local
+   eth0 IPv6 AirPrint Kyocera @ service                    Internet Printer     local
+   eth0 IPv4 Kyocera FS-1020D @ service                    Internet Printer     local
+   eth0 IPv4 AirPrint Kyocera @ service                    Internet Printer     local

WTF?!? Fortunately we have an Ubuntu 12.04 running in our office and printing from IOS devices works without problems (without copying any files to /etc/avahi/services/):

$ avahi-browse -a   grep -i print
+   eth2 IPv6 Ricoh Aficio MP C2800 @ printing              Internet Printer     local
+   eth2 IPv6 Ricoh Aficio MP 171 @ printing                Internet Printer     local
+   eth2 IPv4 Ricoh Aficio MP 171 @ printing                Internet Printer     local
+   eth2 IPv4 Ricoh Aficio MP C2800 @ printing              Internet Printer     local

I just copied the whole configuration over to my wheezy system, but it didn't worked out. I tried this all on a kfreebsd-i386 system again without success. Sorry, but I don't understand the source of this issue. Cups on wheezy has the same upstream version as on precise. Avahi-daemon on wheezy is just one minor version ahead off precise. Is this a bug/incompatibility in cups and/or avahi? A missing patch compared to the packages of precise? Is this a configuration problem? Update: Looking into LP #1054495 and the debdiff of cups 1.5.3-0ubuntu6 indicates, that there seems modifications beside simple changes of mime configurations files. Update: The fix for LP #1054495 does really fix the problem on wheezy too. With the help of Didier Raboud I was able test a binary package with this fixapplied on our test setup. The good news is, there are no extra modifications needed beside just configuring cups to export it's printers for enabling support for iOS devices. I opened #700961 and hopefully release managment will accept this fix for wheezy. Hints, rants and comments could be send to 'blog - at - waja - dot - info' or via @blogwajainfo.

If you are comming from an old SCM like subversion, you may have difficulties to internalize the new workflow. Peter Cottle created Learn Git Branching which is really nice.

Server management on daily basis in a growing environment could be a challenge. Most of the tasks is here done with ClusterSSH in help with a homebrew mail notification. Unfortunately this workflow is not scaling well for 200+ systems. I had a look into apt-dater but this seems not to fit our workflow. FAI looks a bit overengineered at the first glance. Maybe Puppet is an option? There seems to be many extensions for it, unfortunately ruby is needed on every single node. Is there a CTO-compatible overview about puppet, any other alternatives? ;) Update: Many thanks for the hints from Andr Lu s Lopes, Stig Sandbeck Mathisen, Phil Miller, Steve Kemp, Andrew Latham, Bob Proulx and Natxo Asenjo

• Chef
  • Packaged in Debian
  • Upstream Debian packages (no recent one)
• CFEngine3
  • No ruby/perl/python dependencies
  • Light, fast
  • (A bit) harder to understand
  • Packaged in Debian
  • Upstream Debian packages
• Salt
  • Very young
  • Packaged in Debian
• Ansible
  • Very flexible
  • Easy to understand
  • Relies on ssh
  • Open ITP
  • PPA
• MCollective
  • Framework for building server orchestration and parallel job execution
  • Could extend for example Puppet or Chef
  • Packaged in Debian
  • Upstream Debian packages (no recent one)
• Foreman
  • Puppet dashboard and node classifier
  • Open ITP
  • Upstream Debian packages

Old but conceptual still valid: www.infrastructures.org, for example Bootstrapping an Infrastructure Other thoughts: push- or pull-infrastructure? Software footprint (on nodes and your central instance)! Hints, rants and comments could be send to 'blog - at - waja - dot - info' or via @blogwajainfo.

Server management on daily basis in a growing environment could be a challenge. Most of the tasks is here done with ClusterSSH in help with a homebrew mail notification. Unfortunately this workflow is not scaling well for 200+ systems. I had a look into apt-dater but this seems not to fit our workflow. FAI looks a bit overengineered at the first glance. Maybe Puppet is an option? There seems to be many extensions for it. Is there a CTO-compatible overview about puppet, any other alternatives? ;) Hints, rants and comments could be send to 'blog - at - waja - dot - info'.

In January, I did a TV-shop ad -style post on a little script called lintian-overrider and it prompted Simon to ask:

That s a great tool, but don t you fear it makes unjustified overrides too easy ?

In my experience, people sometimes have issues writing overrides (justified or not). In fact it sometimes leaves them really frustrated with Lintian. If that frustration eventually leads to them reject Lintian, then we are doing the project a disservice. I will quote Russ Allbery as I believe he covered when he wrote:

I care most about all of the regular Debian developers [...] continuing to use Lintian, so that Lintian can stay as effective as it is now at getting people to make archive-wide changes. [...] This only works if we can get nearly everyone uploading packages to run Lintian all the time.

If a handful of people adds overrides for tags they should not have, then we can fix that (e.g. by filing a bug against their packages). But it is unlikely that we will ever make them run Lintian again once they have boycott it.

We are searching a motive for a painting or a painting itself for a quite while now. This should find it's place in our living room. Unfortunately we didn't found one, which matched our both prospect and/or wasn't compatible with the rest of our living room. Yesterday we stumbled upon a motive which was quite nice, but was too small and it was neighter possible to get it in a bigger size nor to find out who was the origin painter of the picture. Now we are searching for the name of the picture and/or the painter. Any hints appreciated at 'blog - at - waja - dot - info'. A photo with higher resolution can be found here Update: Okay ... an unknown people (many thanks) hinted me, that google image search is the tool that could be very usefull. Google revealed that the painter is Inna Panasenko. P.S. Is it noticeable that I'm in vacation mode? ;)

Are you consuming a way too much coffee and have reached the junkie level like me? Maybe coffeestats.org can help out and visualize your coffee usage.

(insert here: I've been to FOSDEM, I got a nasty flu, and other $lame_excuses for the delay in sending out this report) Dear Project Members, here's the monthly DPL activity report, this time for January 2013. About the next DPL This is the last DPL report before the start of the election process for the next term: around early March, about 20 days from now, the Secretary will send out the call for nominations. I'd like to respond (also) here to inquiries I'm receiving these days: I will not run again as DPL. So you have about 20 days to mob^Wconvince other DDs to run, or decide to run yourself. Do not to wait for the vary last minute, as that makes for lousy campaigns. I'm available to give feedback about my DPL experience to prospective candidates, ... and also to join mobbing^Wconvincing actions toward potential candidates. Just contact me. Call for helps

• Last year delegation for Google Summer of Code Admins 1 has expired and the program for 2013 will likely start soon. I'm looking for volunteer admins for this year, to organize Debian activities in the program. If you're interested, please contact me.
• In January we had a couple of related discussions on -project about DFSG 10 and maintaining an authoritative list of DFSG-free licenses. The latter would be an important contribution to the Free Software "political" ecosystem. An ikiwiki-based infrastructure to maintain such a list has been created by ftp-masters but needs to be populated. At this point we need volunteers willing to review licenses already present in main and fill them in. If you're interested, please review the discussion and manifest yourself on debian-dak@lists.d.o, where coordination about this work will happen.

Assets

• The long standing issue of writing a proper (outbound) trademark policy for Debian marks has been completed. I've reviewed on -project outstanding items from the last discussion, and documented how they've been implemented in a new policy draft. Later on, I've published the updated policy draft on our website.
• Complementary to the above, Ian Jackson has summarized the state of the discussion about our (inbound) trademark policy, i.e. what to do when accepting in the Debian archive software subject to trademark. It looks like we are close to conclusion on that front too.
• I've worked with representatives of Debian France, on the shared interest in having the association become a Debian Trusted Organization (per Constitution 9.3). We're not yet ready to start the 2 weeks discussion period to accept the orga as such (see Constitution 5.1.11), but I'd like to do that soon. So I encourage all of you to find out about the association, which is run by well-known project members.

Cloud Images Work has gone on also on the front of supporting Debian installation in public "clouds". Thanks to Arnaud Patard, Jose Miguel Parrella Romero, Pierre Couzy, and Gianugo Rabellino, we now have Debian testing images for Microsoft Azure. Together with Amazon EC2, this is the second large provider supporting Debian via images maintained by Debian Developers. More providers are welcome, exactly as more hardware/CD vendors shipping Debian are always welcome. If you want to contribute support for other providers just show up on the -cloud mailing list and say so. Some documentation effort in view of Wheezy are in need of help too, in order to let our users know about "cloud" options, see #695681. DPL helpers The DPL helpers experiment goes on. We have had 2 more IRC meetings in January (see the minutes). Documentation of the "team" communication channels (mailing list, IRC, Git, etc.) is now available from the DPL wiki page. Talks I've given an invited Debian talk at Polytech'Grenoble, as part of a free software event organized for students of local universities. Slides of the talk are available. I'd like to thank Vincent Danjean for the event organization. Let's release Wheezy now!
Cheers.

---

PS the day-to-day activity log for January 2013 is available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.201301

The UEFI bootloader that the Linux Foundation have been working on has just been released. That means we now have two signed bootloaders available - this one and shim.
Does this mean Linux distributions can now support Secure Boot?They've actually been able to for a while. Ubuntu shipped with Secure Boot support last October, and Fedora shipped with Secure Boot support in January. Both used Shim rather than the Linux Foundation loader, and Shim's also being used by a variety of smaller distributions. The LF loader is a different solution to the same problem.
Is the Linux Foundation the preferred loader for distributions?Probably not in most cases. One of the primary functional differences between Shim and the LF loader is that the LF loader is based around cryptographic hashes rather than signing keys. This means that the user has to explicitly add a hash to the list of permitted binaries whenever a distribution updates their bootloader or kernel. Doing that involves being physically present at the machine, so it's kind of a pain.
Why use it at all, then?Being hash based means that you don't need to maintain any signing infrastructure. This means that distributions can support Secure Boot without having to change their build process at all. Shim already supports this use case (and some distributions are using it), but the LF loader has nicer UI for managing it.
Any other reasons?Actually, yes. Shim implements Secure Boot loading in a less than entirely ideal way - it duplicates the firmware's entire binary loading, validation, relocation and execution code. This is necessary because the UEFI specification doesn't provide any mechanism for adding additional authentication mechanisms. The main downside of this is that the standard UEFI LoadImage() and StartImage() calls don't work under Shim. The LF loader hooks into the low-level security architecture and installs its own handlers, which means the standard UEFI interfaces work. The upshot is that you can use bootloaders like Gummiboot or efilinux without having to modify them to call out to Shim.
Why doesn't Shim do the same?The UEFI architecture is slightly complicated. The UEFI specification itself defines the upper layers of the firmware, basically covering everything that UEFI applications and operating systems need. It doesn't define the lower layers of a UEFI implementation. Those are contained in the UEFI Platform Initialization spec, and that's what defines the security architecture interfaces that the LF loader hooks into. The problem is that it's completely valid to implement the UEFI specification without implementing the Platform Initialization specification, and if anyone does that then the LF loader will fail.
Can't you try both approaches?Yes, and that's actually pretty much the plan now. I'm working on integrating the LF loader's UI and security code into Shim with the aim of producing one loader that'll satisfy the full set of use cases, and James is happy with this.
Which should I use?Depends. If you want to support gummiboot (and aren't willing to patch it to call out to Shim), you'll need to use the LF loader. If you want to use key-based signing setups to avoid forcing re-enrolment on updates, you'll need to use Shim. If you're somewhere in the middle, you can probably use either. Once we've got the code merged, you won't have to make a choice.

comments

Well, I had a very nice run at the start of this year in writing journal entries nearly every day, and then I seem to have gotten much quieter. This is not actually because less stuff is going on, but I started working on larger projects without meaningful daily progress, and I also got drawn into some very rewarding creative work that has kicked my schedule in the ass. Schedules are something that I've always struggled with. I'm fairly convinced that I have even more than the natural human tendency towards a longer than 24-hour schedule. (I lived in 28-hour days and 6-day weeks for one full quarter when I was a college student and rather liked it, but it wasn't practical enough to stay with.) This means that, without applying a lot of discipline, I tend to stay up later and later because I'm engaged in interesting things and don't want to stop, and then drift further and further out of sync with the world. When I was just out of college and working as just another member of a team that wasn't very close-knit, I just shrugged and let it happen. I used to get into work at about two or three in the afternoon and work until well past midnight. It had some lovely properties, such as getting to work most of my "day" after everyone else had left and the building was quiet. Unfortunately, it's really not compatible with a lead position that requires interaction with people and quite a few meetings and other types of coordination. Given that I can't just let my schedule go wherever, I realized a year or two ago that I do much better if I can stick to a fairly reliable and consistent schedule and go to bed at a regular time, even if I'm involved in something. It cuts off my evenings in a way I don't like, but it makes mornings much more pleasant and it makes it easier to schedule and stick with various chores like exercise. But it's remarkably hard to get back into that mode once I've gotten out of it, particularly when I get caught up in things in the evenings. This meander is mostly my way of getting these thoughts out of my head and on a screen in front of me so that I'll think about them and build up enough willpower to go back to a regular schedule. It really is worth it; I was keeping one through most of January and it had a lot to do with why January was awesome. Hopefully a more sustantive update tomorrow.