Just added a TDeb test build branch for multistrap to test out the changes in the next version of the emdebian-tdeb binary package - specifically:

Move em_installtdeb into the emdebian-grip-server package so that the emdebian-tdeb package can be slimmed down to only contain what will become useful for other maintainers to use in their debian/rules files and for translators when the time comes to implement DEP-4. CDBS rules / patches to follow... bug reports against dpkg and debhelper to follow ...

DEP-4 itself is being restarted and refreshed but with some problems on alioth currently, I'm going to (try and) keep the document up to date via SGML and people.debian.org.

The changes are now in Emdebian SVN and I'm starting testing with my own packages first. Multistrap for PO and po4a-build testing, dpkg-cross for debconf testing, some others for testing with build systems other than CDBS, then the discussions will restart on debian-devel and I'll upload the TDeb support scripts to unstable.

There are a variety of things which need to happen before these scripts become useful, including:

• dpkg support for XC-Package-Type: tdeb
• debhelper support for dh_gentdeb,
• inevitable bug fixing in emdebian-tdeb

Why is the package called emdebian-tdeb? Simple - that's where the scripts have lived until now and the hope is that dpkg-gentdeb can migrate into dpkg-dev and dh_gentdeb into debhelper - eventually.

By all means play with the scripts and follow the example multistrap branch above to see what kind of changes might be needed in your own packages. I'll post again when I've worked out the changes needed in packages like dpkg-cross which only need TDebs for debconf support. (This is the easiest mode of TDeb usage but it's also the most useful during a release cycle - maintainers make a single change and then a nominated i18n boss-person - take a guess who - can update the all your debconf translations in one upload without a binary build - eventually possibly not even needing any bug reports, just a simple email advance warning.

What I've got to work on still is how the generation of an updated TDeb creates a new debian diff / debian.tar.gz to accompany the upload. For that I need XC-Package-Type: tdeb support in dpkg....

Sample output from the viewpoint of a translator updating a package already converted to support a TDeb:

neil@sylvester:tdeb-test$ dpkg-gentdeb -t

Set the changelog message to version 2.1.15+t0 first, closing any relevant bugs!

 dch -v 2.1.15+t0 

neil@sylvester:tdeb-test$ dch -v 2.1.15+t0 TDeb test

neil@sylvester:tdeb-test$ dpkg-gentdeb -t

Building TDeb update: 2.1.15+t0

 (192 entries)

Discard doc/pod/1/da/multistrap (65 of 177 strings; only 36.72% translated; need 50%).

Discard doc/pod/1/da/device-table.pl (5 of 19 strings; only 26.31% translated; need 50%).

Processing untranslated files for pod/multistrap (1) . . .

Processing untranslated files for device-table.pl (1) . . .

Processing de translations for pod/multistrap (1). . .

Processing de translations for device-table.pl (1). . .

Processing fr translations for pod/multistrap (1). . .

Processing fr translations for device-table.pl (1). . .

Processing pt translations for pod/multistrap (1). . .

Processing pt translations for device-table.pl (1). . .

dpkg-gencontrol -pmultistrap-tdeb -Pdebian/multistrap-tdeb -cdebian/control

dpkg --build debian/multistrap-tdeb ../multistrap-tdeb_2.1.15+t0_all.tdeb 

dpkg-deb: building package  multistrap-tdeb' in  ../multistrap-tdeb_2.1.15+t0_all.tdeb'.

neil@sylvester:tdeb-test$ dpkg -c ../multistrap-tdeb_2.1.15+t0_all.tdeb

drwxr-xr-x root/root         0 2011-06-08 21:06 ./

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/pt/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/pt/LC_MESSAGES/

-rw-r--r-- root/root      6427 2011-06-08 21:06 ./usr/share/locale/pt/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/vi/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/vi/LC_MESSAGES/

-rw-r--r-- root/root      6963 2011-06-08 21:06 ./usr/share/locale/vi/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/fr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/fr/LC_MESSAGES/

-rw-r--r-- root/root      6789 2011-06-08 21:06 ./usr/share/locale/fr/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/da/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/locale/da/LC_MESSAGES/

-rw-r--r-- root/root     16311 2011-06-08 21:06 ./usr/share/locale/da/LC_MESSAGES/multistrap.mo

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/pt/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/pt/man1/

-rw-r--r-- root/root     33963 2011-06-08 21:06 ./usr/share/man/pt/man1/multistrap.1

-rw-r--r-- root/root      4471 2011-06-08 21:06 ./usr/share/man/pt/man1/device-table.pl.1

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/vi/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/fr/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/fr/man1/

-rw-r--r-- root/root     33969 2011-06-08 21:06 ./usr/share/man/fr/man1/multistrap.1

-rw-r--r-- root/root      4708 2011-06-08 21:06 ./usr/share/man/fr/man1/device-table.pl.1

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/da/

drwxr-xr-x root/root         0 2011-06-08 21:06 ./usr/share/man/da/man1/

I'm also going to DebConf11



On the RoadTrip! all the way hrough France, Belgium, Netherlands, Germany, Austria, Slovenia, Croatia, Bosnia-Herzegovina (Banja Luka) in an MX5.

I've got a lot of things to talk to people about @ DebConf this year... you won't be able to tell if I'm just buying you a beer or trying to badger you about your packages!! Just note that TDebs have been already agreed (in terms of how TDebs work in the archive) with ftp-master at a previous meeting in Extremadura and I'm being badgered by a Release Manager and an ex-DPL to get TDebs implemented real soon now, so it is going to happen and hopefully in time for Wheezy - it's just a matter of fixing the bugs. The quicker everyone has a look at the new scripts (which have been completed re-written and immensely simplified since I first tried a dumb conversion of em_installtdeb) and the likely changes needed in packages, the quicker I can get the bugs out of the scripts.

More documentation to follow, I'll be updating the SGML whenever practical and the actual DEP just as soon as I get commit access back.

Since my laptop features WWAN connectivity, I purchased a 3G mobile broadband plan from SFR, a French mobile phone company. I took the cheapest one available: 250 MB per month for 10 .

Optimizing transparent proxy by SFR While browsing, I was curious about the fact that there were multiple accesses to non-public IP, like 10.141.0.4. I was browsing the mobile version of Le Monde, a French daily newspaper. I enabled Chromium developer tools and watched what happened in the Network tab. All images were served from IP like 10.141.0.4. Looking at the HTML source code, I discovered that <img> tags were rewritten to point to those images. The smaller one were identical to the original one but the larger ones (more than 50 KB) were of reduced quality (and therefore reduced size). <img> tags were not the only one to be rewritten. <style> and <script> tags that were pointing to external resources (with a src attribute) were also rewritten to include the CSS or the javascript inline. Before:

<script src="http://s1.lemde.fr/js/lib/jquery/1.5.1/jquery.js"></script>

After:

<script oldSrc="http://s1.lemde.fr/js/lib/jquery/1.5.1/jquery.js" NG="replaced">
/*!
 * jQuery JavaScript Library v1.5.1
 *
 * Copyright 2011, John Resig
 * Dual licensed under the MIT or GPL Version 2 licenses.
 * http://jquery.org/license
 * [...] */
</script>

This means that each page that includes jQuery, a popular javascript library, as an external resource, will be turned into a page that includes the whole jQuery code which is about 85 KB. Each page will weight more than 85 KB instead of relying on an external and cacheable resource. Nowadays, most browsers support HTTP keep-alive which allows to serve multiple resources into a single request. There are two cases:

1. If the resource is served from the same server as the HTML page, keep-alive would enable to get almost the same result without hindering the cache: the browser would first request the HTML page, then the javascript resource into the same TCP connection. There is a small penalty of about 100 ms to let the browser request the second resource. The browser may decide to open another connection because the initial document is not loaded yet. Some browsers may even negotiate this additional connection before needing it. In this case, it can use this idle connection at no cost. Otherwise, we may fall in the second case.
2. If the resource is served from another server (like in the example above) or if the browser does not have an idle connection ready for reuse, it would download the resource in parallel with the help of another connection. It will only costs about 300 ms of additional time due to the establishment of a new TCP connection with the server. Those 300 ms are a very small price to pay compared to the 2 seconds needed to download 85 KB for each page. Moreover, other static resources will likely be downloaded from the same server and therefore, this is 300 ms the first time and about 100 ms for additional resources (round-trip time for a new HTTP request into the same TCP connection).

UPDATED: In a previous version of this article, I confused pipelining and keep-alive mechanisms. While keep-alive allows to reuse an existing connection to download a new resource, only one request at a time by connection could be issued. Pipelining allows to push additional requests in the same TCP connection without waiting for answers. As noted by ric Daspet in a comment, pipelining is disabled for most browsers. However, keep-alive is well supported. Searching on the web for oldSrc and NG="replaced", I find very little information about what is used. It seems that such a feature may also break some scripts, like TinyMCE, trying to get additional resources relative to the path where the script is installed. It appears that SFR is using a product from Flash Networks called Harmony Gateway. I have asked SFR more info about this and if it was possible to disable the use of this feature but got no answer so far. I have retried a bit later and there was no rewriting for Javascript and CSS. Images were still degraded and served by a special server. The next day, my requests did not travel through a transparent proxy anymore (no more Via header in answers). Each try was done at a different location. The proxies may be installed at some locations only and configured differently. Another explanation is that SFR silently disabled this functionality for my account. If it was done correctly, such an accelerator service could be be proposed as an opt-out option since most users would appreciate faster page downloads. If you care about network neutrality, you can disable this option. Of course, it needs to be properly advertised, for example as a free option in your mobile plan.

Setting up our own optimizing proxy Google provides mod_pagespeed as a solution to optimize a website on the fly. This is an Apache module. It is targeted at optimizing your own website but since Apache can act as a regular proxy, it seems possible to enable mod_pagespeed for any website. That s pretty easy to setup if you don t mind using a precompiled version of mod_pagespeed. Download mod_pagespeed. I have downloaded the 64bit version for Debian.

# touch /etc/default/mod-pagespeed
# dpkg -i ~/download/mod-pagespeed-beta_current_amd64.deb
Selecting previously deselected package mod-pagespeed-beta.
(Reading database ... 277699 files and directories currently installed.)
Unpacking mod-pagespeed-beta (from .../mod-pagespeed-beta_current_amd64.deb) ...
dpkg: dependency problems prevent configuration of mod-pagespeed-beta:
 mod-pagespeed-beta depends on apache2.2-common; however:
  Package apache2.2-common is not installed.
dpkg: error processing mod-pagespeed-beta (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mod-pagespeed-beta
# apt-get install -f
[...]
Unpacking apache2.2-common (from .../apache2.2-common_2.2.19-1_amd64.deb) ...
Processing triggers for man-db ...
Setting up apache2.2-common (2.2.19-1) ...
[...]
# apt-get install apache2-mpm-worker
[...]
Unpacking apache2-mpm-worker (from .../apache2-mpm-worker_2.2.19-1_amd64.deb) ...
Setting up apache2-mpm-worker (2.2.19-1) ...
Starting web server: apache2.
# a2enmod proxy_http
Considering dependency proxy for proxy_http:
Enabling module proxy.
Enabling module proxy_http.
To to activate the new configuration, you need to run:
  /etc/init.d/apache2 restart

Then, we modify /etc/apache2/mods-enabled/proxy.conf:

ProxyRequests On
<Proxy *>
    AddDefaultCharset off
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Proxy>

Of course, this makes little sense to run the proxy on your laptop since you don t want to download the non-optimized content over your WWAN link. You need to run it on another server and therefore allow your laptop to access it. Also, we need to modify /etc/apache2/mods-enabled/pagespeed.conf to add the directive ModPagespeedDomain * to let mod_pagespeed rewrite any page. You should restart Apache after that. Now, check if the proxy is working:

$ curl -six http://localhost:80 http://www.lemonde.fr/   grep ^X-Mod-Pagespeed
X-Mod-Pagespeed: 0.9.17.7-716

All is working! Let s try a very simple site, like Debian Backports. It features one HTML file and two CSS files: We downloaded a total of 8 KB (compression included). Let s use our proxy and try again: mod_pagespeed succeeds in reducing the size of the HTML file and combined the CSS files. Moreover, it minified the resulting CSS file. There seems to be a bug in Chromium that display incorrect transfert sizes (including in the timeline representation) when using a proxy. I have checked with Wireshark that the overall quantity transferred was about 8 KB. The gain is very thin here but you can imagine that you will get better results on larger sites. mod_pagespeed seems to handle well most sites. However, it only optimizes pages that already are in its cache. The first time you grab a page, you will get the unoptimized version. I don t know if it is the expected behaviour.

As usual many people requested travel sponsorship to attend DebConf 11 and are now waiting eagerly on the outcome of their request. We are sorry, that we can t give you much details yet. To give you an idea of the time line, here is a small explanation of the process. About 100 people requested travel sponsorship. In total that would about 50 000 Euro. Problem is currently we don t exactly know, how much money we may spend on travel sponsorship ourselves (By the way: If a potential sponsor is reading this, please contact us; DebConf also accepts donations). So, we formed a team of 13 persons (the mail only lists twelve, one was added later). The team members will start to rate each and every single request in two criteria: Contributor Level and sponsorship amount. With limited amounts we obviously want to sponsor those first, who contribute a lot to Debian, preferably if they don t travel first class. After that s done, we ll have a long, but ordered list, but the team still needs to meet and discuss different cases and similar. Our team isn t really small and consists of people living all over the world, it s quite hard to actually schedule a meeting everyone can attend. (Which is not a bug, but a feature: More people from more countries should in the end result in a fair rating of the sponsorship requests.) So, in the end, we ll meet on 19th of June. Sounds late, please keep in mind, that every team member has to rate all sponsorship requests (including some research) and all of them are volunteers with actual daytime jobs. But even if you don t hear anything from us short after that date, don t panic! As said we really don t know, yet, how much money we can spend on travel sponsorship. Our sponsor-hunting-team is constantly working on the acquisition of more money, so every now and then the budget for travel sponsorship gets increased, meaning that we can mail a couple of more people on our ordered list. So it might take a while, till we get to all, but we try very hard to do so.

I m just back from spending a few days volunteering with the tornado recovery effort in Joplin, MO. The biggest image that remains in my mind is of the first time I saw a person picking through a large pile of rubble. The person was standing on top of what used to be a house. Now it was a pile of wood, glass, carpet, siding, and roofing material. I m sure there was hope for finding some treasure or other maybe a photo album or videos of children. In any case, it made me feel so lucky, even unfairly lucky, to have not had to go through that. This scene was repeated several times, but mostly the houses that devastated appeared abandoned by the time we were there, now two weeks after the event. But I heard stories, and lots of them. The victims of the storm, who were perhaps trying to rebuild that part of their house that got smashed by a tree or a pickup, or trying to get their intact belongings out before abandoning the house, or whatever, were mostly surprisingly upbeat. They were working out in 95-degree heat, many without electricity, running water, or sewer service. Almost every person I met that suffered a loss from the tornado wanted to tell their story. Many also told of their plans for the future, which were full of hope and even upbeat. These were people doing a hard job in terrible conditions and still showing hope. Another testament to the disaster was the most unusual set of vehicles you ve ever seen parked at any hotel you can care to think of, for at least an hour-and-a-half radius in the direction I came from. Besides the usual cars and minivans, there might be FEMA vehicles, electric company trucks, Red Cross vans, construction trucks of every kind, police and law enforcement from all over, etc. There was quite obviously an influx of people helping out in Joplin. My primary task there was to provide communications support for the effort as an amateur radio operator. Amateurs (or hams ) are something of a volunteer first responder of sorts during times of crisis; most of us own and are very familiar with operating equipment that can communicate over very long distances without the need for any on-site infrastructure. Amateur radio was the only method of communication for some Joplin hospitals in the immediate aftermath. The communications emergency is over, but the response isn t. I was assigned to work with the Salvation Army. They were doing a lot of things in Joplin, and had hundreds of volunteers working with them. I don t think I even know what many of them were doing I do know they had set up several warehouses across the city working with donating clothing, food, etc. The part I was involved with was primarily the canteen operation. The SA sent in food service trucks from several parts of the country. These trucks would roam up and down the streets in the damaged area, trying to get past every single street several times a day. Anybody that we could see would be offered food and water. No strings attached, no questions asked. This included homeowners, electric line workers, construction crews, sanitation workers, and quite a few nonprofit groups that sent well-meaning and useful volunteers into the area but didn t think to provide them with a large supply of water due to sending them into an area without any. Oops. In any case, with extreme heat and no running water, conditions were dangerous. The canteens also knew of certain at-risk families that were living in homes that were mostly intact in the disaster areas, and made a special point to check in on them. They also generally looked to make sure that people looked like they were healthy. Each canteen also had a counselor on board that would visit with people while we quickly prepared their meal they all seemed to welcome that. Amateur Radio s Role The operation of this size had quite a logistics challenge. I d hear of things like an unexpected need of 70 lunches, or a semi showing up with donations before there was space, or an unexpected but very welcome donation of a large quantity of ice cream without a place to store it (so the canteen trucks, which have freezers, needed to pick it up quickly). That s where us hams came in. Each canteen had an amateur radio operator on board. Each major location also had a ham stationed there, and the head of operations also often had a shadow a ham that would follow him around wherever he went to relay messages back and forth. We also had hams with pickups (with radios in them, of course) that could transport things around the city to places that needed them, hams at headquarters managing all the communication and generally investigating questions that didn t have immediately obvious answers, etc. Radios were used instead of cellphones for a few reasons. One big one is that everybody on the operation can hear what everyone else s needs are, since it s a group communications situation rather than one-to-one. It s easy to give a general alert to everyone ( come get your ice cream now please! ) and people that have suggestions can chime in. This came in extremely handy more than once. Also, it frees the people doing other jobs from having to spend time chasing someone s voicemail, finding phone numbers, etc; that gets delegated to us in some cases. I heard from the head of canteen operations, for whom this was the first disaster he d worked that had amateur radio support, how wonderful it was to have this going on. I also heard a secondhand report that some police officers that were also amateurs had listened to our operation and reported that we sound more professional than 911 dispatch and do a better job. On Sunday I was assigned to a canteen. This meant I didn t have a lot of radio traffic to pass, so although I had it in my ear all day, I wasn t actively talking on the radio very much. So I rode in back, helping hand out water, carry meals to people, and so forth. On Saturday, I was the shadow for the head of operations. That was a difficult task, because he barely ever moved at a pace slower than a run, sometimes would abruptly zip out somewhere, etc. But it was also enlightening and vital. He was a real get it done sort of guy, and was the key to quite a few things. Having someone available to relay questions to and from him was a good thing. And today I worked as a transport person and at headquarters. Due to not having a pickup there, I didn t actually get called on much to transport things, but in general between jobs the whole time I d act as a runner if needed, or simply try to figure out the details of how things were run for next time. I wound up taking net control (being the control operator at headquarters, and generally managing communications so that people don t talk over each other and such) for about an hour. So I got to do a little of just about every amateur radio task. Thoughts I am thankful for the opportunity to go, and the good feeling of helping people in need the first I ve ever had the chance to do that in a disaster. It s a good feeling to have a skill that is useful and appreciated. Sometimes it felt like handing out food and water is something pretty small in the scheme of things. But on the other hand, it gives people a chance to have contact with someone that cares, an opportunity to have people that can notice problems drive by a few times a day, and an opportunity to help meet people s basic needs. And sometimes in a fluid situation, there might be more volunteers than are needed, so I did spend some time sitting waiting for the next task. But overall, I m convinced that the work I helped facilitate was a good thing and provided a good and needed service in Joplin. This has been quite the experience and I m sure it s changed me too, though I don t yet know how.

I'm trying to resume some activity in OSM maintenance. As many people, I mapped most parts ofmy neighbourhood, as one can see when looking at Maurepas, France on the map. I stopped about 20 months ago because it was becoming too addictive..:-) I'll start resuming this work by focusing on things I can easily map: my tracks from running sessions. What's good in them is that I know most of these places by heart and can easily remember the terrain features when working on the map. Also, it means only a few dozens of minutes to work on a GPS track, so that's manageable. Another goal I set to myself is improving the map around our country house in Normandy. As you can see there, there is much more to do...but when I'm over there, I have more free time..:-) So, let's see if I can manage my addictability!

As I write this, it's the morning of June 5th, 1981. A few people scattered across the US are waking up, going in to work, sitting down at their terminal with a coffee, and reading Usenet. Usenet is only getting a trickle of posts each day -- it's still in that period where it's easy to read every message posted to it. Many things lie in Usenet's future. It's still running A-News, which doesn't even have a real From header yet. Later this year it will switch over to B-News, and volume will begin to increase. In 1987 there will be The great renaming. And of course in 1994, the first spam will be posted to Usenet. But that's all a long way off, here in 1981. Right now, they're talking about 500 mb disk drives that only cost $38000. And rms is inciting flames about nuclear proliferation. And Postel is publishing an RFC for the new Mail Transfer Protocol. Good morning, Usenet. Who knows what will come next in this fledgeling electronic communications medium! a ten year real-time historical exhibit This morning, I'm announcing a new site: Olduse.net It's Usenet, updated in real time as it was thirty years ago. Planned to be available for the next ten years, unless I run out of inodes (again). If you missed it the first time around, this is your chance to follow Usenet's flowering. made possible by

• Henry Spencer at the University of Toronto, Department of Zoology, who archived Usenet. Back when it was really uncool and really expensive. Our view onto Usenet is thus slightly centric to Canada and Zoology, but that's ok.
• David Wiseman, who hauled 141 magtapes in a pickup truck.
• Many who worked to rescue data off the tapes. Including from the deleted stuff at the ends.
• Rich Skrenta, who somehow got a copy of the archive out from under the Google borg. Although one of the tar files is truncated. Just saying.
• The creator of Telehack, who pointed me in the right direction, ending my multi-year quest to find the archive. And if you think this is neat, Telehack will blow you away.
• The developers of Haskell, which enabled me to whip up a B-News to C-News converter, a custom uucp, date parsers for every crazy date format ever used on Usenet, and suitible queue data structures in a rock solid, maintainable way, in 500 lines of code written over 12 hours. When I realized I also needed an A-News to B-News converter, I knew it was worth it to have done things right, because that took only 43 more lines, and worked 100% on the first run! My code repository for olduse.net is here.

---

PS: You can post to olduse.net, but it won't show up for at least 30 years. :)

My last update about running activities is dated back to Paris Marathon (April 10th). Time for a new update, then. After a very busy end March-early April, with that crazy succession of 55km Ecotrail and 42km Paris marathon with only two weeks between both, I needed a kind of "break". Moreover, I had another goal set with the 35m trail race named "Trail des Cerfs", on May 15th, in my neighbourhood. So, end of April was a little bit quieter. Still, one week after Paris marathon, I completed a very hard trail run in Seine Valley: only 18km, but about 600-700m positive slope. That was indeed a good moutain-style run (yes, in Seine valley....) and a good way to check that I recovered quite well. Later on, I slowed down a little with even a Sunday (24th) where I *didn't run at all*..:-).. Just a few short uns during the week and a short Saturday run. Well, that was indeed Easter Sunday and Monday is a holiday in France, so I ran an half-marathon on 25th...:-)...on a loop where I already have some references, the fastest being 1h46. This time it was 1h52'...but, well, that was two weeks after a marathon... Still, a small pain at the back of my ankle decided me to stop running long distances until May 15th. So, I only did short trainings up to no more than 12km, even during my stay in Germany for SambaXP. As a consequence, I was very well for the 35km (600m positive slope) Trail des Cerfs, which I completed in 3h31', 168th out of 328 runners. More interestingly, I completed it in negative split with a much faster second half, ending up at about 12km/h. For seomthing that (given the slope and the nature of the paths) is comparable to a marathon, that's very promising. The rest of May was spent quietly with a standard training and progressively resuming longer distances. I originally planned to do my spring solo marathon on May 28th in Versailles Castle park, but I stopped at km28 and completed the distance two days after with a 14km run..:-)... Stopping was wiser as I was feeling that the last loop would have been a great pain. That was indeed the first time I give up on a marathon. I prefer this to happen for a non official race, after all! June will not see any "big goal". I might be running one race somewhere in my neighbourhood but the point will mostly be accumulating kilometers before summer. Summer (which includes DebConf that makes training a little bit more hectic) will not see any race, probably (unless I find one in banja Luka!) but more some specific preparation for Berlin marathon. Here, the "safe" target for me is, first, breaking my record. I'm probably not ready for 3h30 and even 3h35 might be difficult. It seems that I'm now reaching a barrier where progress becomes harder. Before Berlin, I'll run the Bois d'Arcy half-marathon, two weeks before. Last year, I managed to set a very good mark, there, with 1h37. Not sure that i'll try to break this only two weeks before Berlin. After Berlin? We'll see, but my last big goal of the year will be the 67km "Le Puy-Firminy" night race, in November (no web site, this is indeed a "small" local race). Yet another adventure beyond marathon distances, in the unknown...

Erich Schubert's blog post reminded me that I've been meaning to writeup a post detailing how I'm keeping parts of my $HOME in git repositories. My goal has been to keep my home directory in a version control system effectively. I have a number of constraints however. I want the system to be modular. I don't always need X related config files in my home directory. Sometimes I want just my zsh related files and my emacs related files. I have multiple machines I check email from, and on those want to keep my notmuch/offlineimap files in sync, but I don't need these on every machine I'm on, expecially since those configurations have more sensitive data. I played around with laysvn for a while, but it never really seemed comfortable. I more recently discovered that madduck had started a "vcs-home" website and mailing list, talking about doing what I'm trying to do. I'm now going with madduck's idea of using git with detached work trees, so that I can have multiple git repositories all using $HOME as their $GIT_WORK_TREE. I have a script inspired by his vcsh script that will create a subshell where the GIT_DIR, GIT_WORK_TREE variables are set for me. I can do my git operations related to just one git repository in that shell, while still operating directly on my config files in $HOME, and avoiding any kind of nasty symlinking or hardlinking. Since I am usually using my script to allow me to quickly "move in" to a new host, I named my script "movein". It can be found here. Here's how I'll typically use it:

    stew@guppy:~$ movein init
    git server hostname? git.vireo.org
    path to remote repositories? [~/git] 
    Local repository directory? [~/.movein] 
    Location of .mrconfig file? [~/.mrconfig] 
    stew@guppy:~$ 

This is just run once. It asks me questions about how to setup the 'movein' environment. Now I should have a .moveinrc storing the answers I gave above, I have a stub of a .mrconfig, and an empty .movein directory. Next thing to do is to add some of my repositories. The one I typically add on all machines is my "shell" repository. It has a .bashrc/.zshrc, an .alias that both source and other zsh goodies I'll generally wish to be around:

    stew@guppy:~$ ls .zshrc
    ls: cannot access .zshrc: No such file or directory
    stew@guppy:~$ movein add shell
    Initialized empty Git repository in /home/stew/.movein/shell.git/
    remote: Counting objects: 42, done.
    remote: Compressing objects: 100% (39/39), done.
    remote: Total 42 (delta 18), reused 0 (delta 0)
    Unpacking objects: 100% (42/42), done.
    From ssh://git.vireo.org//home/stew/git/shell
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .zshrc
    .zshrc

So what happened here is that the ssh://git.vireo.org/~/git/shell.git repository was cloned with GIT_WORK_TREE=~ and GIT_DIR=.movein/shell.git. My .zshrc (along with a bunch of other files) has appeared. Next perhaps I'll add my emacs config files:

    stew@guppy:~$ movein add emacs       
    Initialized empty Git repository in /home/stew/.movein/emacs.git/
    remote: Counting objects: 77, done.
    remote: Compressing objects: 100% (63/63), done.
    remote: Total 77 (delta 10), reused 0 (delta 0)
    Unpacking objects: 100% (77/77), done.
    From ssh://git.vireo.org//home/stew/git/emacs
     * [new branch]      emacs21    -> origin/emacs21
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .emacs
    .emacs
    stew@guppy:~$ 

My remote repositry has a master branch, but also has an emacs21 branch, which I can use when checking out on older machines which don't yet have newer versions of emacs. Let's say I have made changes to my .zshrc file, and I want to check them in. Since we are working with detached work trees, git can't immediately help us:

    stew@guppy:~$ git status
    fatal: Not a git repository (or any of the parent directories): .git

The movein script allows me to "login" to one of the repositories. It will create a subshell with GIT_WORK_TREE and GIT_DIR set. In that subshell, git operations operate as one might expect:

    stew@guppy:~ $ movein login shell
    stew@guppy:~ (shell:master>*) $ echo >> .zshrc
    stew@guppy:~ (shell:master>*) $ git add .zshrc                                       
    stew@guppy:~ (shell:master>*) $ git commit -m "adding a newline to the end of .zshrc"
    [master 81b7311] adding a newline to the end of .zshrc
     1 files changed, 1 insertions(+), 0 deletions(-)
    stew@guppy:~ (shell:master>*) $ git push
    Counting objects: 8, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (6/6), done.
    Writing objects: 100% (6/6), 546 bytes, done.
    Total 6 (delta 4), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/shell.git
       d24bf2d..81b7311  master -> master
    stew@guppy:~ (shell:master*) $ exit
    stew@guppy:~ $ 

If I want to create a brand new repository from files in my home directory. I can:

    stew@guppy:~ $ touch methere
    stew@guppy:~ $ touch mealsothere
    stew@guppy:~ $ movein new oohlala methere mealsothere
    Initialized empty Git repository in /home/stew/git/oohlala.git/
    Initialized empty Git repository in /home/stew/.movein/oohlala.git/
    [master (root-commit) 7abe5ba] initial checkin
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 mealsothere
     create mode 100644 methere
    Counting objects: 3, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 224 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/oohlala.git
     * [new branch]      master -> master

Above, the command movein new oohlala methere mealsothere says "create a new repository containing two files: methere, mealsothere". A bare repository is created on the remote machine, a repository is created in the .movein directory, the files are committed, and the new commit is pushed to the remote repository. New on some other machine, I could run movein add oohlala to get these two new files. The movein script maintains a .mrconfig file, so that joeyh's mr tool can be used to manage the repositories in bulk. Commands like "mr update", "mr commit", "mr push" will act on all the known repositories. Here's an example:

    stew@guppy:~ $ cat .mrconfig
    [DEFAULT]
    include = cat /usr/share/mr/git-fake-bare
    [/home/stew/.movein/emacs.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/emacs.git' 'emacs.git' '../../'
    [/home/stew/.movein/shell.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/shell.git' 'shell.git' '../../'
    [/home/stew/.movein/oohlala.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/oohlala.git' 'oohlala.git' '../../'
    stew@guppy:~ $ mr update
    mr update: /home/stew//home/stew/.movein/emacs.git
    From ssh://git.vireo.org//home/stew/git/emacs
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/oohlala.git
    From ssh://git.vireo.org//home/stew/git/oohlala
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/shell.git
    From ssh://git.vireo.org//home/stew/git/shell
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: finished (3 ok)
    stew@guppy:~ $ mr update        

There are still issues I'd like to address. The big one in my mind is that there is no .gitignore. So when you "movein login somerepository" then run "git status", It tells you about hundreds of untracked files in your home directory. Ideally, I just want to know about the files which are already associated with the repository I'm logged into.

Erich Schubert's blog post reminded me that I've been meaning to writeup a post detailing how I'm keeping parts of my $HOME in git repositories. My goal has been to keep my home directory in a version control system effectively. I have a number of constraints however. I want the system to be modular. I don't always need X related config files in my home directory. Sometimes I want just my zsh related files and my emacs related files. I have multiple machines I check email from, and on those want to keep my notmuch/offlineimap files in sync, but I don't need these on every machine I'm on, expecially since those configurations have more sensitive data. I played around with laysvn for a while, but it never really seemed comfortable. I more recently discovered that madduck had started a "vcs-home" website and mailing list, talking about doing what I'm trying to do. I'm now going with madduck's idea of using git with detached work trees, so that I can have multiple git repositories all using $HOME as their $GIT_WORK_TREE. I have a script inspired by his vcsh script that will create a subshell where the GIT_DIR, GIT_WORK_TREE variables are set for me. I can do my git operations related to just one git repository in that shell, while still operating directly on my config files in $HOME, and avoiding any kind of nasty symlinking or hardlinking. Since I am usually using my script to allow me to quickly "move in" to a new host, I named my script "movein". It can be found here. Here's how I'll typically use it:

    stew@guppy:~$ movein init
    git server hostname? git.vireo.org
    path to remote repositories? [~/git] 
    Local repository directory? [~/.movein] 
    Location of .mrconfig file? [~/.mrconfig] 
    stew@guppy:~$ 

This is just run once. It asks me questions about how to setup the 'movein' environment. Now I should have a .moveinrc storing the answers I gave above, I have a stub of a .mrconfig, and an empty .movein directory. Next thing to do is to add some of my repositories. The one I typically add on all machines is my "shell" repository. It has a .bashrc/.zshrc, an .alias that both source and other zsh goodies I'll generally wish to be around:

    stew@guppy:~$ ls .zshrc
    ls: cannot access .zshrc: No such file or directory
    stew@guppy:~$ movein add shell
    Initialized empty Git repository in /home/stew/.movein/shell.git/
    remote: Counting objects: 42, done.
    remote: Compressing objects: 100% (39/39), done.
    remote: Total 42 (delta 18), reused 0 (delta 0)
    Unpacking objects: 100% (42/42), done.
    From ssh://git.vireo.org//home/stew/git/shell
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .zshrc
    .zshrc

So what happened here is that the ssh://git.vireo.org/~/git/shell.git repository was cloned with GIT_WORK_TREE=~ and GIT_DIR=.movein/shell.git. My .zshrc (along with a bunch of other files) has appeared. Next perhaps I'll add my emacs config files:

    stew@guppy:~$ movein add emacs       
    Initialized empty Git repository in /home/stew/.movein/emacs.git/
    remote: Counting objects: 77, done.
    remote: Compressing objects: 100% (63/63), done.
    remote: Total 77 (delta 10), reused 0 (delta 0)
    Unpacking objects: 100% (77/77), done.
    From ssh://git.vireo.org//home/stew/git/emacs
     * [new branch]      emacs21    -> origin/emacs21
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .emacs
    .emacs
    stew@guppy:~$ 

My remote repositry has a master branch, but also has an emacs21 branch, which I can use when checking out on older machines which don't yet have newer versions of emacs. Let's say I have made changes to my .zshrc file, and I want to check them in. Since we are working with detached work trees, git can't immediately help us:

    stew@guppy:~$ git status
    fatal: Not a git repository (or any of the parent directories): .git

The movein script allows me to "login" to one of the repositories. It will create a subshell with GIT_WORK_TREE and GIT_DIR set. In that subshell, git operations operate as one might expect:

    stew@guppy:~ $ movein login shell
    stew@guppy:~ (shell:master>*) $ echo >> .zshrc
    stew@guppy:~ (shell:master>*) $ git add .zshrc                                       
    stew@guppy:~ (shell:master>*) $ git commit -m "adding a newline to the end of .zshrc"
    [master 81b7311] adding a newline to the end of .zshrc
     1 files changed, 1 insertions(+), 0 deletions(-)
    stew@guppy:~ (shell:master>*) $ git push
    Counting objects: 8, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (6/6), done.
    Writing objects: 100% (6/6), 546 bytes, done.
    Total 6 (delta 4), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/shell.git
       d24bf2d..81b7311  master -> master
    stew@guppy:~ (shell:master*) $ exit
    stew@guppy:~ $ 

If I want to create a brand new repository from files in my home directory. I can:

    stew@guppy:~ $ touch methere
    stew@guppy:~ $ touch mealsothere
    stew@guppy:~ $ movein new oohlala methere mealsothere
    Initialized empty Git repository in /home/stew/git/oohlala.git/
    Initialized empty Git repository in /home/stew/.movein/oohlala.git/
    [master (root-commit) 7abe5ba] initial checkin
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 mealsothere
     create mode 100644 methere
    Counting objects: 3, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 224 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/oohlala.git
     * [new branch]      master -> master

Above, the command movein new oohlala methere mealsothere says "create a new repository containing two files: methere, mealsothere". A bare repository is created on the remote machine, a repository is created in the .movein directory, the files are committed, and the new commit is pushed to the remote repository. New on some other machine, I could run movein add oohlala to get these two new files. The movein script maintains a .mrconfig file, so that joeyh's mr tool can be used to manage the repositories in bulk. Commands like "mr update", "mr commit", "mr push" will act on all the known repositories. Here's an example:

    stew@guppy:~ $ cat .mrconfig
    [DEFAULT]
    include = cat /usr/share/mr/git-fake-bare
    [/home/stew/.movein/emacs.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/emacs.git' 'emacs.git' '../../'
    [/home/stew/.movein/shell.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/shell.git' 'shell.git' '../../'
    [/home/stew/.movein/oohlala.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/oohlala.git' 'oohlala.git' '../../'
    stew@guppy:~ $ mr update
    mr update: /home/stew//home/stew/.movein/emacs.git
    From ssh://git.vireo.org//home/stew/git/emacs
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/oohlala.git
    From ssh://git.vireo.org//home/stew/git/oohlala
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: /home/stew//home/stew/.movein/shell.git
    From ssh://git.vireo.org//home/stew/git/shell
     * branch            master     -> FETCH_HEAD
    Already up-to-date.
    mr update: finished (3 ok)
    stew@guppy:~ $ mr update        

There are still issues I'd like to address. The big one in my mind is that there is no .gitignore. So when you "movein login somerepository" then run "git status", It tells you about hundreds of untracked files in your home directory. Ideally, I just want to know about the files which are already associated with the repository I'm logged into.

Hello, this is the official project report for the Debian GSoC admins and everyone. It s been few days since the official coding phase started. Most of the time I ve been figuring out the details regarding integration of non-x86 images to the Eucalyptus IaaS and working on the ARM image, as you ll learn later. I m also in the process of starting to design the set of tools we ll be delivering as part of the project. The project s goal is to be a useful resource for Debian developers and porters. I ve joined some porters list in order to learn what are the things they are struggling with and how the project can help to address them. I ll be starting a wiki page with such topics. Bonding period:
Bonding period has been more fruitful than I expected. As mentioned in my previous post, Steffen and I got in touch with the Eucalyptus team, since they show their early interest on the project. We are coordinating cooperation between our teams. Besides my mentor and I defined to start working on the ARM image. Coordination went OK. We ll be having meetings every two weeks. Project Status:
Resuming Dominique s work I began working on the ARM image. Aur lien s work was a great resource. Currently I have a working and updated Debian testing ARM image using the versatile kernel that can be used under qemu-arm. I m currently making tests and figuring out the next phase which is cloudify it. Over this weekend I expect to finish on that side and then began on the design and implementation of the tools that will be the project s result.

Until now I haven t faced much issues, but the Eucalyptus part since the docs are targeting x86 and amd_64 archs. However I think I can run qemu-arm on top. I ll talk to them about the idea.

Future plans: week 3: - Finish tests with the ARM image. - Design the base tool-set, thinking integration with dpkg-buildpackage and qemubuilder. week 4-8: - Write the necessary code. mid-term evaluation. Other bits: Latest days have been quite busy for me, since I m still have to attend class, my semester ends in five weeks. This week was quite overwhelming with media , my University published an article (Spanish) about me and the program. I m the third student of the CS school participating in GSoC, in the past we had Gentoo Project and KDE students. Later, a local Cable TV program interview me on the same matter, it went fine. I managed to talk about Debian and what we do (we get free Advertising yay!) :) also about Google s Summer of Code program and invited students to participate both in FLOSS projects and the program. Still don t know if they have put it on air, I think it will be next week.

The beginning of this Google Summer of Code has been busy and pretty cool. Not a lot of code was produced but I did learn a lot of things.

During this GSoC I will work on the next generation JDK. This means that I will (and I already have) compile the JDK. That s pretty awesome but it requires a lot of power. That s why Tom Marble created me an account on his 8 CPUs machine to help me.
Since I m probably going to sign some packages, I created a new GPG key with a 4096 RSA strength.
My old key was:

pub 1024D/F144A319 2008-10-18

And the new key is:

pub 4096R/EE2BBBC7 2011-05-03

I cross signed my keys using this great tutorial.

I read some documentation about Jigsaw and watched Tom s talk at DebConf 10.
I have spent a little more than a week to understand the current OpenJDK packaging to be able to rebuild it. I have learnt from where do the sources come from. The current packaging is a little hard to understand. There are sources that come from IcedTea, OpenJDK, and more.

After being able to rebuild the OpenJDK 6 package, I have downloaded the source of the OpenJDK 8 and Jigsaw. I used the Mercurial forest to get the sources.

For OpenJDK 8:
hg clone http://hg.openjdk.java.net/jdk8/jdk8 jdk8
cd jdk8 && sh get_sources.sh

For Jigsaw:
hg clone http://hg.openjdk.java.net/jigsaw/jigsaw jigsaw
cd jigsaw && sh get_sources.sh

I have managed to build the sources of OpenJDK 8 and Jigsaw using the same steps:
cd jigsaw
. jigbuild
. jdk/make/jdk_generic_profile.sh
export ALLOW_DOWNLOADS=true
make sanity
make all

Jigsaw specific:
make modules-sanity
make modules

Each build took several minutes. But they were successful. Tom helped me a lot to build OpenJDK 8 and Jigsaw by giving me a solution. For example, after getting the Mercurial forest, there were still missing source files and the build failed. Tom told me that I needed to export a environement variable: ALLOW_DOWNLOADS=true.
After building Jigsaw, I was able to see that the version string is not legal in Debian and that is a real problem.
I have written some simple Hello World examples to compile and run with Jigsaw. To modularize a program, it needs to contain a module-info.java files. This file includes the modules needed to run the program and the main class to run. For a classic hello world, the module-info.java files looks like:

module test.hello @ 1
requires jdk.base @ 7-ea;
class test.hello.Main;


Tom gave me some packages to build: jtharness and jtreg. I succesfully built jtharness using CDBS and its Ant helper but I ll have to repackage it to use javahelper instead of CDBS. I still didn t try to build jtreg because it requires jtharness.

My next plan is to get jtharness and jtreg packaged with javahelper soon and understand what modules does what in Jigsaw. Understaning modules will help me to write some more complex examples. I hope to start working on Jigsaw a little more soon (when I my internship will end [next week]).

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work, then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. I have been Doing some work towards Debian Rolling At the start of the month, the discussions about Debian rolling were still very active on debian-devel. Declaring that testing would be rolling did not make it (as I hoped), the argument that some RC bugs last for far too long in that distribution carried the discussion and thus the most consensual proposition ended up being the one of Josselin Mouette were rolling would be testing plus a few selected cherry-picked packages from unstable. I believe it s a workable solution if we only care about a subset of architectures. Otherwise the same reasons that keep the fixed packages out of testing would probably also apply for rolling. Given this, I did setup britney (the software that controls testing) on my laptop to investigate how we can create rolling. It turns out britney is a very specialized software with very few configuration knobs. At the same time Joachim Breitner made a proposition that immediately grabbed my attention. He suggests to use SAT solvers to find out the set of packages that should migrate from unstable to testing. I thought that rolling would be a good testbed for this new implementation of britney (which he calls SAT-britney) so I jumped right in this project. I was not at all familiar with this science field, so I looked up quite some documentation: I learned that all SAT solvers expect the problem to be presented in CNF form, and that DIMACS was the file format of choice to represent those boolean constraints. Several SAT solvers are available in Debian and picosat appears to be one of the best. Then I started some early coding/prototyping to play with the concept. You can find the result in this git repository, you can grab a copy with git clone git://git.debian.org/~hertzog/sat-britney.git. There s not much yet, except some Python code to generate a SAT problem that can be fed to a SAT solver. But I really look forward to this project. Representing Debian during Solutions Linux During the second week, I spent 3 days in Paris to help manage the Debian booth at Solutions Linux. We have responded to lots of queries but most visitors already knew Debian, and many of them use it at work and/or at home. We tried to recruit those people as new members for Debian France, the local association. We also sold all our remaining goodies. The Ubuntu people were interviewed by France 3 (an important TV channel) and we took this opportunity (with the consent of the Ubuntu guys) to show our Debian t-shirts in the background: you can watch the video here (in French), you can see me with Carl Chenet at 1:21. We have also been interviewed by Intelli n TV: here and here (both in French). I m not very good at this exercise. Improving dpkg triggers The third week was a vacation week, in theory I should have stayed away from my computer but I really wanted to take this opportunity to improve the state of dpkg triggers in Debian. I already covered my work in another article: Trying to make dpkg triggers more useful and less painful. The result is not merged yet, I just asked a question to all package maintainers who are using triggers to be able to decide whether I ll merge it as is, or if I can make the new behavior the default one. Supporting users after Alioth s migration When I came back from my vacation, many services provided by Alioth.debian.org were non-functional after a migration to a new setup that involves two machines instead of one. Given that I used to be an Alioth admin, I know that in those periods you tend to be get bogged down on many user support requests. So I re-joined #alioth on IRC and tried to help a bit. I did investigate some of the reported problems and prepared fixes (updated scripts, configuration files, etc.) for some of the issues. I also created a list of remaining issues that should have lasted only a few days but that s still active because there are still regressions left. The most important things still missing are:

• proper support for delegation of rights. We used ACL setup by the admins in the past. With the new FusionForge, each project admin should be able to delegate rights to external roles . There s a Debian Developer role already but trying to grant him right fails
• access to the Ultimate Debian Database. Many tools rely on this database to work.
• anonymous FTP access to download project files.
• clear guidelines on how we re supposed to deal with websites that are updated by VCS hooks.
• clear guidelines on how we re supposed to deal with personal git repositories

Improving the 3.0 (quilt) source format I have made some proposals to change the way the new source format would work. The goals are to be less painful for packagers who are using a VCS, and to avoid unexpected changes slipping through a new patch generated by dpkg-source. It seems that the proposals are relatively consensual so I ll implement them at some point. Missing in action on my blog I did a lots of stuff for Debian between travel and vacation, and in the remaining time, I did not manage to write many articles for my blog. In fact, besides the article on my triggers work mentioned above I only published one interview: People behind Debian: Steve Langasek, release wizard. I ll try to do better this month! Thanks Many thanks to the people who gave me 151.61 in May. See you next month for a new summary of my activities.

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

Network effects are such a pernicious thing. They give us the internet, but they also give us an internet full of monopolistic worse-is-better players that use network effects to stifle improvements and competition. Sometimes the best you can manage is to be a parasite. facebook So I'm back on facebook ... sort of. My strategy for facebook is to be as near to a featureless datapoint as I can. I won't post anything. I entered as bad quality information as I could get away with. I turned all privacy controls off, on the theory that this way I don't have to worry about facebook eroding privacy since everything about me on facebook is aggressively public. By never posting anything to facebook, I am trying to fight the network effect; trying to avoid increasing the value of facebook due to me being on it. I've adblocked the text entry field on facebook just to avoid the temptation. I want to erase the Like buttons too. Technologically, I think a good approach would be a browser plugin that does these things while extracting all available content and optionally sending it to a RECAP-type system. I only friend people who I need to keep up with and who have little or no other internet presence. This is because I am aware that each person I friend still propels facebook's network effect a little bit; even though they'll never see any useful information from me, they will know that they are able to talk to me via facebook. I only log into facebook once a week or so (this is easy when you're not interacting with it anyway), and read whatever sample of farmville and other posts facebook selects as "important" (worse than usual probably since I never give it feedback). So people I friend can't rely on me reading everything they do, which reduces the value a little more. I will probably delete this account occasionally, and then re-add it later. Just often enough to be really annoying. twitter Similarly, I no longer gate my identi.ca account to twitter, and have deleted as many tweets as I could stand to (one click and one keypress per tweet; no mass-delete; ugh!), and protected my account to avoid accidential new tweets leaking out. Since twitter is not quite as evil as facebook I feel slightly less bad about exposing more of my social graph there. Only the folks who are too lame to get on an OpenMicroBlogging site like identi.ca. phone Of course there was a network effect with the telephone as well, and while it got deregulated it's still pretty bad, and also a technology that I mostly dislike using. Oddly my phone behavior is backwards to the other two networks; I only make outgoing phone calls, never answering the phone (unless real life intervenes very severely). I listen to some random fraction of my voice mail and read whatever ones manage to get machine-transcribed.

When I installed my new laptop, I decided to switch from sleepd to GNOME Power Manager (GPM). The rationale behind this decision was to get screen dimming for free while keeping other features because GPM uses UPower which uses pm-suspend and pm-powersave behind the scene. This means that it is easy to execute scripts on suspend or when the AC is unplugged by putting them in /etc/pm. I don t use a full GNOME desktop. My desktop is running FVWM which is just a window manager. However, I already use some parts of the GNOME environment:

• GDM as a display manager because it is the only one that is able to handle ConsoleKit correctly. This means that GDM is able to register your session to ConsoleKit and make it active. Without that, you won t be considered as the user sitting in front of the screen and DBus won t allow you to interact with most of your hardware unless you add yourself to a lot of groups. ConsoleKit enables the at_console property used by most policies.
• Network Manager to handle both wired and wireless connections. Connecting to some random AP using only command line tools is rather cumbersome (assume that the AP is using WPA). Connecting to a broadband network with a 3G dongle is even more cumbersome.
• GNOME bluetooth applet because interacting with BlueZ bluetooth stack is now done with DBus only and the command line tools have been removed. Therefore, you need to write your own tools or use this small applet that do most of the work for you.

What s working It happens that most of the features just do not work. However, suspend when closing the lid works fine. The icon in the systray works fine too (but there is a small bug). The screen dimming feature on idle also works (but there are annoying bugs with it). The visual feedback when pressing brightness keys works too.

What s not working It seems that I am not the only one to have problem with GPM: there are currently 115 bugs opened in the Debian BTS. If you want to get some debug output from gnome-power-manager, run it with --verbose flag. --debug flag does nothing (and supersedes --verbose).

Nothing happens when pressing the power button I have configured GPM to ask me what to do when I press the power button. But when I press the button, nothing happens. Looking at the source, here is the snippet of code that is executed:

1 2 3 4 5 6 7

if (policy == GPM_ACTION_POLICY_INTERACTIVE) GpmSession *session; egg_debug ("logout, reason: %s", reason); session = gpm_session_new (); gpm_session_logout (session); g_object_unref (session);

In fact, this is not GPM that will ask you the question, but GNOME session manager because GPM triggers logout. If you don t run a full GNOME session, nothing will happen. My workaround is just to set the action to Suspend .

Does not sleep when idle GPM is configured to go to sleep after 2 hours on AC or 30 minutes on battery. This does not work for me because idle detection is delegated to external programs. There are four variables used by GPM to determine if we are idle:

• session_idle which is the idle hint from ConsoleKit,
• idle_inhibited which is set when another program asks to disable idle detection (a video player which does not want the screen to be dimmed),
• suspend_inhibited which means a program do not want we going to sleep (a music player for example)
• x_idle which tells if X is idle or not (someone is moving the mouse or typing on the keyboard).

To allow GPM to suspend when we are idle, x_idle and session_idle must be true while suspend_inhibited and idle_inhibited must be false. For screen dimming purpose, you just need to have x_idle set to true and idle_inhibited set to false. Currently, only GNOME Screensaver seems to tell ConsoleKit if the session is idle or not. XScreenSaver does not contain anything about this. I am using xautolock with xlock and I am pretty sure they won t tell GPM if I am idle. You can use dbus-send to circumvent this problem:

1 2 3 4 5 6 7 8 9 10 11

$ dbus-send --system --dest=org.freedesktop.ConsoleKit \ > --type=method_call --print-reply --reply-timeout=2000 \ > /org/freedesktop/ConsoleKit/Manager \ > org.freedesktop.ConsoleKit.Manager.GetCurrentSession method return sender=:1.6 -> dest=:1.106 reply_serial=2 object path "/org/freedesktop/ConsoleKit/Session1" $ dbus-send --system --dest=org.freedesktop.ConsoleKit \ > --type=method_call --print-reply --reply-timeout=2000 \ > /org/freedesktop/ConsoleKit/Session1 \ > org.freedesktop.ConsoleKit.Session.SetIdleHint boolean:true method return sender=:1.6 -> dest=:1.108 reply_serial=2

While I understand what is the rationale behind those choices (no code duplicate and allowing external programs to hinder power management), it lacks some fallback in case you don t use GNOME Screensaver (which is the key component here). I first though this was bug #594706 but this is not the case. I have opened (and closed) bug #628755. UPDATED: Jump to the conclusion for an updated solution for this problem.

Brightness is not restored to the previous value after idle When GPM undims the screen, it does not restore the previous value. It seems to be bug #617310 which is marked as fixed in upstream. I did not investigate it.

Wrong number of batteries reported I only have one battery but after one suspend/resume cycle, GPM thinks I have two. Maybe this is a bug of UPower. Maybe this is bug #606434. I did not investigate it. Maybe there is an happy interaction with bug #456280.

Inability to set configure actions when the UPS runs out of battery This is bug #390602. In addition to laptop batteries, UPower also supports UPS. In this case, GPM displays a special icon to tell if the UPS is fully charged. However, there is no possibility to execute special actions when the UPS is unplugged, like hibernate after 10 minutes or something like this. This seems to be a problem with the interface because looking with gconftool-2, we can spot variables like low_ups or critical_ups which allow to set actions when the UPS is almost out of battery. Moreover, the UPS icon only displays after one suspend/resume cycle but I am too lazy to report and debug this issue. Since, the icon disappear if I restart GPM, I am confident that the bug is in GPM.

Conclusion The conclusion is that GPM is not really that buggy but it really needs to be run in a full-blown GNOME desktop. The main problem is not really GPM. New technologies like UPower and ConsoleKit get pushed by freedesktop.org initiative, they get implemented by GNOME (and, I suppose, KDE) because they have tons of people following the appropriate mailing lists and any alternative just gets crushed by all those unpublicized changes. UPDATED: I got several helpful comments about this problem. There are two possible solutions:

1. Use xfce4-power-manager. It handles brightness control in a better way and don t need an external program to tell when the current session is idle. It still needs a session manager to ask what to do when using the power button. The drawback to this solution is that you start to pull another desktop environment into your environment. You had some parts of GNOME and now you have some parts of XFCE. This solution was proposed by Sylvain Collilieux.
2. Use gnome-session, gnome-screensaver and keep gnome-power-manager. As pointed by Julien Valroff, gnome-screensaver needs gnome-session to detect idleness. However, gnome-session starts a whole GNOME desktop. Again, there are two solutions. The first one is to replace gnome-session by something lighter implementing the bare minimum to make gnome-screensaver happy. Another suggestion is to configure gnome-session to start your favorite environment.

I start mine from ~/.xsession and here is what I have added at the top of it:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# If not done, restart ourself with gnome-session if [ -z "$SESSION_MANAGER" ]; then [ -d ~/.config/autostart ] mkdir ~/.config/autostart rm -f ~/.config/autostart/* cat <<EOF > ~/.config/autostart/xsession.desktop [Desktop Entry] Name=Xsession Comment=Start .xsession Exec=$(readlink -f $0) Type=Application X-GNOME-Autostart-enabled=true EOF exec gnome-session --autostart=$HOME/.config/autostart fi # Otherwise, keep starting stuff # [...] exec fvwm-crystal

I know it has been a while, but after reading a blog post by Anand Kumria over at planet.debian.org I decided to have a quick look at one of the problems he described.

Basically, Anand wants to force the local resolver to be used for each and every network connection, may that connection be established manually or via NetworkManager. He wrote that fixing this configuration for every new connection manually is tedious, and I fully agree on that. So here is a solution to do this all automatically, using resolvconf:

After installing the resolvconf package every time /etc/resolv.conf is to be updated resolvconf takes care of that. Using the files in /etc/resolvconf this process can be controlled and the resulting file modified to fit one own's needs.

So at first we would like the local resolver to be used for every connection. This works by simply adding the "nameserver 127.0.0.1" directive to the /etc/resolvconf/resolv.conf.d/head file. Simple as that. Every time /etc/resolv.conf gets generated the contents of the head file are actually used as /etc/resolv.conf's header.

Using this method the local resolver is used for every connection. But Anand wanted to use only the local resolver and discard any resolvers possibly obtained via DHCP for example. Guess what, this is also possible using resolvconf.

Adding TRUNCATE_NAMESERVER_LIST_AFTER_127="yes" to /etc/default/resolvconf does exactly that. Now every nameserver directive after the 127.0.0.1 one is ignored and will not make it into /etc/resolv.conf. You can of course add more nameservers to the head file above the 127.0.0.1 directive.

Problem fixed I guess.
Don't forget to re-connect to the network or manually force re-creation of /etc/resolv.conf so the changes you made get populated. I really hope this is of use to some of you facing similar problems.

As you all probably know by know, DNSSEC has been enabled on the root ('.') since July 2010. And on most TLDs like .com shortly thereafter (in the specific case of .com, since March 2011). The Debian guide to turning on DNSSEC is useful but some things you need to know (after using it for a week or so).

BIND loves IPv6.

If you have 'listen-on-v6', set to yes and you roam to a non-IPv6 network. Your name resolutions can take 30+ seconds.Since I roam from a some networks they do have IP6 and some that do not, I have had to turn this setting off to achieve reasonable performance

Each new network requires manual intervention

Just like Andrew Cowie, I'm trying to get new features in NetworkManager. by blogging.My use case is simple if a bit geeky use the local resolver on my system irregardless of what I get dynamically (via DHCP) or automagically (via SLAAC).I can do this manually for each network I connect to, but it quickly looses its appeal.

Very little software takes advantage of DNSSEC (yet).

Apart from the happy DNSSEC campers, very little takes advantage of DNSSEC yet.Kind of like the early days of IP6. It would be nicer if websites stored the fingerprint of the SSL website in DNS and it could be cross-checked against what was sent.The effort to do so is underway at the IETF by the name of DANE.In fact publishing SSH key fingerprints via DNS is already possible RFC4255 but I am unaware of deployed support.

Things are progressing, and I suspect now is a great moment to get involved if you have spare time, in making it significantly harder for 3rd-parties to censor the Internet for everyone.

I've made a first release of GNOME Prepaid Manager a couple of days ago after switching to GTK+3, GSettings and PyGObject's GObject introspection but it still wasn't that useful since the very common Huawei chipsets (present in many UMTS USB sticks) weren't working due to some missing code in ModemManager. Thanks to Dan's great description I just got around to add that which should make ppm useful to more people. This blog is flattr enabled.

I was invited to be part of one of the panels to be present this Thursday (June 2) in a forum that promises to be interesting. The forum is organized by the Science and Technology comission of the Senate of the Republic (of Mexico ;-) ), Universidad Aut noma Metropolitana and Mozilla M xico. The day will be opened by Sen. Francisco Javier Castell n Fonseca and Richard Stallman; starting at 10:00, we will have thematic panels on:

• Education
• Government
• Industry
• Civil society

The full program (as well as details of interest of those that can physically attend) is attached to this post. I am looking forward to this forum. Not only it is a good opportunity to get our work known in one of those places where it matters, but it's also being organized by several interesting people I'm sure will have something interesting to contribute. And of course, we lacked time to build a better, more complete and more coherent proposal but there is a good probability we will have further such contacts. You might find interesting to read on the list we have been discussing; subscription seems to be open (although access to the archives is not Maybe it will be later on? In any case, I'm saving a mbox ;-) )

Attachment	Size
Activity program	352.37 KB

Puppet labs's use of the term puppetmaster is rather clever (in contrast to other un-necessarily offensive uses of "master" in the software world). While I appreciate the clever name, I'm less impressed with the concept. At May First/People Link we've spent the last several years (including the last couple months in earnest) working to transition management of our 90-some servers from a collection of hand-written bash scripts to puppet. Over the years, we've worked hard to keep our servers as secure as possible. We have a team of about a half dozen people who all have root access on all servers. It's all key-based access. To help mitigate a disaster if one person's keys were compromised, we've implemented monkeysphere on all servers, allowing us to easily revoke access. After spending so much time thinking through our root-access strategy and fully implementing the monkeysphere to reduce our exposure to a single point of vulnerability, I was disappointed by puppet's use of a puppet master. For those less familiar with puppet, it goes something like this: One server (or god forbid multiple servers), run an externally accessible daemon. Each and every server on your network runs a daemon as root that periodically communicates with the puppet master, receives new instructions, and then (again, as root) executes these instructions. In other words, if your puppet master is compromised, I'm not sure exactly what you would need to do, short of rebuilding every server in your network. To make matters worse, it seems as though some users generate and store all server ssh keys (private and public) on the puppet master and then push the private keys to their respective nodes. That means an intruder doesn't need to write to the puppet master, just reading these keys would be enough to compromise all servers in your network. There must be a better way. Puppet without masters After some web-searching, I found a promising thread on the puppet list asking what's lost without a puppet master. This thread lead to a couple other blogs by people who have worked out a system for using puppet without a master. It turns out that there are two distinct points of centralization with puppet. One is the puppet master (as described above). In addition, there is a concept called storeconfigs - which allows each node in the network to store information in a central database. For example, one server can store a request for an account to be setup on a backup server. The next time the backup server runs, it checks the storeconfigs, finds the request, and creates the user. It's possible to run puppet with storeconfigs but without running a puppet master (that avoids the hassle of running the puppet daemons, while providing the convenience of centralization). For our purposes, however, we decided to forego both the puppet master and storeconfigs. We did not want any form of centralization that would provide an additional point of vulnerability. As is common with puppet, we are storing our puppet recipes in a git repository. And, we are publishing to a single, canonical git repository on the Internet. On each node, we have two git repositories - one is a bare repo (that we can push to) and the other is a checked out repo (in /etc/puppet) that is read by puppet. The bare repo has a post-update hook the changes into the /etc/puppet directory, pulls in the changes from the bare repository, and runs puppet against the newly checked out files. Therefore, we can apply new puppet recipes to any server on the network with

git push <server>

No daemons: neither a master daemon nor a puppet daemon running on the node using up memory or providing a potential security hole. The git push happens over an ssh connection - since all system administrators already have root-level ssh access on every server - there is no need to grant any additional access above what we already have. Pushing works great - but with 90 nodes we don't want to have to push to 90 servers everytime we want a change made. That's where the canonical git repository comes in. A cron job runs a script on each node once an hour that runs git remote update from /etc/puppet. The script then checks the time stamp on the most recent gpg-signed tag and compares it with the time stamp of the current commit. If the most recent gpg-signed tag is newer, it verifies that the tag came from a list of authorized gpg keys (the very same gpg keys used by the monkeysphere to grant root level ssh access). If the gpg signature of the tag can be properly verified, then the changes are merged and puppet is run on the new recipes. What about privacy? One of the benefits of a puppet master setup is that nodes get configuration details on a need-to-know basis. The puppet master doesn't share the entire puppet repo - only the compiled manifest for the node with which it's communicating. Our solution to this problem was to go screaming in the other direction. As you might notice from our support wiki and ticket system, we generally favor transparency. Since we are publishing our entire puppet git repo publicly, there seems little point in trying to hide one node's configuration details from another node. That also means each node carries around about 4Mb of extra weight in the form of disk space for the git repo. That seems like a small price to pay for the resource savings of not running a puppetd process all the time. More differences As I've read the puppet lists, faqs and documentation, I've found yet more ways our use of puppet diverges from the norm. The first is a little thing really - most people seem to store all their node configurations in a single nodes.pp file. I'm not sure why. Fortunately, puppet's include syntax allows globbing, so we've created a directory and gave each server it's own .pp file. This arrangement makes it much easier to parse the configuration with tools other than puppet (like, Q. How many servers do we have? A. ls wc -l). Backup and Nagios monitoring without storeconfigs More significantly - there are some things we can't do since we are not using storeconfigs. While many puppet users add a variable, like $nagios = true before including their sshd class (which then causes the sshd class to store a configuration for the nagios server to monitor ssh on the node in question), we were forced to come up with alternatives. My first solution was to simply list all the servers that needed to be monitored in the server node configuration file for the nagios server. Ditto for the backup servers. This approach, however, proved cumbersome and error prone. When adding a new node, I now have to edit three files instead of one. And, how can I easily tell if all nodes have their nagios and/or backup configurations set? The solution was rather simple - there's more than one way to store a config for another node. Our nagios server is called jojobe.mayfirst.org and our backup server is luisa.mayfirst.org. A typical node.pp file looks like this:

node pietri.mayfirst.org  
  # node config goes here
 
if ( $fqdn == "jojobe.mayfirst.org )  
  nagios_montior   "pietri":  
 
if ( $fqdn == "luisa.mayfirst.org )  
  backup_access   "pietri":  
 

This way all configuration related to pietri stays in a single file. Host keys and granting access between servers storeconfigs is commonly used to distribute host ssh keys. Every node that is added to puppet has it's ssh host key stored centrally and then re-distributed to every other node. That way, you can ssh from node to node without ever getting the ssh fingerprint verification. Avoiding that prompt is particularly important when backing up from one server to another via automated scripts. storeconfigs can additionally be used to copy user's public ssh keys - thus granting user access between servers. Our solution to this problem: monkeysphere. Rather than maintaining our own private data store of keys, we publish (and sign) our ssh keys via the web of trust. In addition to server keys, each one of our servers' root user has an ssh-enabled gpg key (also publicly signed by us). By configuring each server to trust our system administrators' gpg keys for verifying other keys, we can both avoid the ssh fingerprint manual verification step and we can grant a root user on one server access to another server by simply dropping root@$server.mayfirst.org into an authorizeduserids file on the target server. There's no question - the setup was rather tedious (we're using runit to maintain an ssh-agent for each root user), however, now that's in place (and configured via puppet), it's a breeze to add new servers. The only extra step we have to take is to confirm and sign each new server's keys. This "extra" step not only allows our servers to verify each other, but also allows our users to verify the servers as well, so it's hardly an extra step at all. Shared modules There's a vibrant community of third party module developers for puppet. Rather than figure out the intricacies of having puppet configure sshd, for example, you can install a contributed sshd module and then you simply add:

include sshd

And you get a default sshd setup. Many of these modules are fairly well developed, offering the ability to easily customize your setup in a number of different ways. Unfortunately, most of the modules assume you are using storeconfigs and if you are not, they will either fail to work right or you will get noisy errors. At first, this seemed like a problem. However, as I built our puppet recipes, I found myself increasingly frustrated with the third party modules that we could use. Configuring servers is hard - and requires constant debugging and trouble shooting. puppet already provides a layer of abstraction between you and the server you are setting up. Given the benefits of puppet, I'm willing to spend the time learning the puppet syntax and asking the rest of our system administrators to do the same. This layer of abstraction is further compounded by our use of git to store the configurations (not a problem if you are git hero - but most of us are already struggling to get a handle on using git). Again, all seems worth it for the pay off. Now enter the puppet module. In addition to learning puppet syntax (and struggling with git) you now need to understand how the third party module works. With software programming, I typically don't need or want to learn how a library or class does what it does - that's the beauty of object-oriented programming: it hides the complexity. But when it comes to configuring the servers that I will be responsible for debugging and maintaining, I really need to know exactly what is happening. To further compound the problem, I found myself wading through third party module code designed to work on Debian, Ubuntu, CentOS, Redhat, gentoo... and more. We run entirely on Debian - we don't need any of this extra code. And, once I got rid of all the other operating systems, I was still left with a complex module that allows you to configure software in ways we'll never need. In the end, we tore out most of these third party modules and replaced them with file and exec puppet resources that did exactly what we needed them to do. Our code base is now much smaller and simpler. Not just a whiner I have a lot more to whine about (like why native resources for things like nagios that are so easily handled with the file resource?). However - the remarkable thing about puppet is that it's flexible. Despite some fairly substantial problems with the "typical" use of puppet, the program provides enough flexibility for us to use it in a way that fully meets our needs. After having built my own bash-based set of configuration scripts and deeply exploring puppet, I have a great appreciation for the difficulty of building system configuration software (we considered and rejected cf-engine and chef as not being any better). And, if you are still not convinced that puppet will work fo you ... you might consider a package I learned about after going down the puppet route: slack.