At The MIT Kerberos Consortium s 2010 conference, Josh Howlett and Sam Hartman delivered a talk on Moonshot. Slides should be up in a day or so. We reported on status and gave a brief overview. The new material was apropos for the venue. At the bar BOF back in March at IETF 77, we received several comments on Moonshot s limitations. It doesn t work well for services that require rapid authentications for multiple requests. There s not a good story for use when a Moonshot service needs to contact another service. There isn t a good standardized mechanism for mapping in domain-specific policy. We presented a proposal that Luke and Sam developed to optionally provide a Kerberos ticket as part of moonshot authentication. This scales from a service that simply generates its own service tickets all the way through resource domains that have many services and complex policy and provide the client a TGT. Clients can implement the feature in order to achieve better performance. Server can implement the feature in order to get delegation support within a resource domain and to get policy mapping. Luke has prototyped a version of this service involving a service ticket. We plan on briefly mentioning a desire to have extensible fast reauthentication support at the ABFAB meeting in IETF 79. However in the interest of getting the working group off to a good start we re going to focus on the well understand parts of the system and formally propose this extension after IETF 79.

Debian so far had a nice experience with the Google Summer of Code and this year, Google is going to run the Google Code-in. We have applied and would now need some help from you all.
In the words of the official announcement: Google Code-in, Google s contest to introduce pre-university students to the many kinds of contributions that make open source software
development possible, is starting on November 22, 2010. Google is inviting students worldwide to produce a variety of open source code,
documentation, training materials and user experience research for the organizations participating this year. These tasks include:

• Code: Tasks related to writing or refactoring code
• Documentation: Tasks related to creating/editing documents
• Outreach: Tasks related to community management and outreach/marketing
• Quality Assurance: Tasks related to testing and ensuring code is of high quality
• Research: Tasks related to studying a problem and recommending solutions
• Training: Tasks related to helping others learn more
• Translation: Tasks related to localization
• User Interface: Tasks related to user experience research or user interface design and interaction

I have applied on behalf of Debian and we now need a series of short tasks (1-2 weeks work) to propose in all these areas.
The selected mentoring organizations will be announced on November 5th 2010.
As you can see, this is an interesting project as the individual tasks are closer in size to an RC bug and encompass a wider range of areas than the Summer of Code. I set up a welcome page and a tasks page.
Please fill in your tasks ideas ASAP. You can also volunteer to help as admin and/or mentor.
We will be using the usual communication channels used for the Summer of Code:

• IRC: #debian-soc on irc.debian.org
• ML: soc-coordination@lists.alioth.debian.org

Three thousand lines of code is not a huge program, but it is enough to get a pretty good feel for a language. Now that I've completed my first real Haskell program I feel that I've gotten over several of the humps in the learning curve and am starting to get a good feel for it. Actually, I've written closer to five thousand lines, since there were several big refactorings. One was when I stopped manually threading my program state around and added a StateT monad. I did know from the beginning I would need one, but it seemed easier and a better learning exercise to let the program start out with a vesigial tail and gills before growing up into a modern Haskell program. (I suppose it's still written in baby-Haskell, really..) Another refactoring came when I realized I needed to use a custom data type, not String, to represent keys. That was a great experience in type-based refactoring. Being able to keep typing ':make' and landing on the next bit of code that needed fixing was great, and simply adding that one type exposed several non-obvious bugs. I found myself writing code that is much more solid and reusable than normally comes easily. And yet it's also very malleable. Actually, pulling out better data types and abstractions can get a bit addictive. When I realized that I had a similar three-stage control flow being used for each of git-annex's subcommands, and factored that control flow out into a function that used the 3 data types below, I felt I'd gone down that rabbit hole perhaps far enough for now.

type SubCmdStart = String -> Annex (Maybe SubCmdPerform)
type SubCmdPerform = Annex (Maybe SubCmdCleanup)
type SubCmdCleanup = Annex Bool

(That will allow for some nice parallelism later though, and removed dozens of lines of code, so was worth it.) Since git-annex is a very Real World Haskell type program, there is a lot of impure code in it. I could probably do better at factoring out more pure code. I count 117 impure functions, and only 37 pure. Anyhow, from my perspective of a long-time perl programmer, some other random impressions..

• ghc --make is handy, but every time it spits out a new 13 mb executable I can feel my laptop's SSD groan!
• It was surpisingly easy to get into nasty situations with recursive dependencies between the 19 haskell modules I wrote. Sometimes solving them was really messy. I lost hours to this. More time than I've lost to the problem in all other languages combined over 15 years. It's not clear to me if it was due to the overall design of my program, or if Haskell's types tend to encourage this problem. Or if there's some simple "please let me have recursive dependencies" switch to ghc that I missed..
• I'm used to being able to use man to get at mutiple books worth of detailed documentation for perl, and work easily offline or with limited bandwidth. With Haskell, I spend much more time searching online for documentation than I an comfortable with (although Hoogle is pretty neat). And the haddock-produced documentation is often pretty sketchy. The saving grace is that the source to any library function is a click away, and tends to be very readable.
• I'm used to being able to use pretty much any Unix syscall by name from perl: mkdir, chmod, rename, etc. In Haskell, there is a Windows smell to the names, like createDirectoryIfMissing and setPermissions. And there are pointless distinctions like renameFile vs renameDirectory. These long names are not memorable and I have to look them up every time. Most of POSIX is available, but it's scattered amoung many disparate libraries, and I can't find an interface for sysconf(3) at all. There is a certian temptation, that I am so far resisting, to make a library for C/perl refugees that exports the sane Unix names for everything.
• Anything involving the IO monad, or probably most monads, has a certian level of syntactic clumsiness about it. Compare:

  if ($flag foo  && length $l = <>)  
  

  vs

  foo <- getFlag "foo"
  l <- getLine
  if (foo && not $ null l)
      then do
  

  When writing lots of impure code, that got old, and while I could use ifM, or make up some other similar thing, its syntax would also be somewhat clumsy.
• The fixity levels for a lot of stuff seems a bit off. I too often found myself writing error $ "foo: " ++ (show bar) or return $ Just $ ... (Still a lot better than Scheme thanks to $!)
• I've leveled up a couple times now, but this particular video game seems to have more levels going up and up, forever. Can't even see the top from here!

After having looked back at the first months of this blog, I also want to look forward and see how I can improve its content. If you re a Debian/Ubuntu user and/or contributor, I want this blog to be a truly useful resource for you. What kind of articles would you like me to write? I have lots of ideas but I can t do everything. I ll share some of them so that you can discuss them:

• New in Debian testing: a regular column covering changes affecting testing users.
• Short presentations of software available in Debian/Ubuntu (like debaday.debian.net used to do).
• Articles covering wishlist bugs on developers-reference so that they can be easily reused to improve the documentation!
• Interviews of Debian contributors.
• Description of small tasks that one can do to start contributing.

Pleases discuss and share your ideas in the comments. Don t limit yourself to the above list, you know better than me what you need: tell me what kind of documentation was lacking in your daily usage of Debian/Ubuntu, or what could have been better explained while you tried to contribute to Debian/Ubuntu. While I set no limits on Debian/Ubuntu topics that I accept to cover, my main focus is around documentation for end-users and/or contributors. If you prefer you can also send your feedback with Identi.ca, Twitter or leave a comment in the entry for this article in my facebook page.

11 comments Support my work

Last week I went to the sea side, and came back with a fianc e. Bliss.

Like you most likely know, I've been at the openSUSE Conference last week. I've been representing Debian through a talk about Debian - The Project and its Resources, covering services and resources that are usable and useful for other distributions too. The invitation to submit talks were sent to various projects and distributions because of the set topic on Collaboration across Borders for the conference. My impression was that very few distributions have followed the invitation, I am only aware of some Fedora people that have attended. Vincent Untz from GNOME gave a combined keynote with Cornelius Schumacher from KDE. The abstract of my talk and the slides are available from the conference website. The talk was well received and interested people also asked about some of the services like how our buildd network works, or whether the screenshots service has support for localized images too, or if it would be expandable for more general usage of non-Debian based distributions. One topic raised was with respect to the whohas tool: A mapping layer/tool/database for package names. We divert from upstream naming schemes for consistency reasons, like with our library, Perl and Python naming schemes. Other distributions have similar approaches but a different naming scheme. To make inter-distribution tools really useful it would require to have some layer that is able to map the package name from one distribution to another one. One idea for it that was thrown in was to use upstream homepage, but not all packages do have proper homepages, some only live in some git repository, others would either like to link to sourceforge's project page instead of the project's homepage, and other tricky issues. Something unique is clearly called for here and needed to get stored in the package's metadata. Apart from my talk and the occasional mentioning of openSUSE is on my desktop, but I run Debian on my server I noticed that the beverage of openSUSE is their own beer. Taste is a tough topic, personally I rather prefer our Debian wine. And I missed the chance to seduce them into playing Mao, I forgot to bring playing cards along. I hope to get a second chance at anoter event.

/debian permanent link Comments: 3

I'm thinking about getting a Kindle, and I thought I'd write down some thoughts, even if they're a bit jumbled, and invite commentary. Good: One thing I really like, living here in Italy, is that I would be able to get English language books instantaniously, and not pay shipping or import duties on them. Whatever disadvantages there may be, that is a huge advantage. Closely tied to that: if we ever move back to the US, shipping all our books will be very expensive. Having some of them in an electronic format would lighten that load considerably. It's fairly cheap. At $180, it's not something I'd want to treat carelessly, but it's significantly less expensive than various existing tables. Long battery life means it's not something you have to worry much about. E-ink looks like it's easier on the eyes than LCD screens. I'm not sure, but also its slow update speed might be a "feature not a bug" in the sense that you're not so easily distracted by the internet being just one click away. Bad: I love having real, physical books in my house. I grew up in a house full of books, and I want the same thing for my daughter. I like being able ot look through them, pick one up, and read about something. Real books are very convenient, as long as you're not lugging around hundreds of them. I like not having to worry too much about dropping them, about getting a bit of water on one or that sort of thing. You can cart them around in a backpack with little worry, take them to the beach, and so on. As far as I can tell, Knuth's books are not available for, nor would appear like they do on paper. That's the golden standard for me: once "The Art of Computer Programming" looks good on an e-reader, it will be really and truly ready. We're not there yet. It's not general purpose. Like I said above, maybe this is good for reading, but there are also times when it'd be nice to have a general purpose device, with email, maps, applications, and so on. A while back, Amazon announced some sort of beta program for a kindle SDK. I haven't heard much of anything since. So it looks like it's not really possible to code for it, which is a bit disappointing. I like to have that option available, even if I don't always exercise it. Unknown: The pricing: sometimes Kindle versions are cheaper (especially, in my case, considering shipping, and, potentially, import duties), but sometimes they aren't, which seems a bit unfair, given that you cannot sell the book if you don't like it. I'm not sure how it would work out for me in the aggregate. Digital Rights Management, or DRM, means you can't, say, sell someone a "used" ebook. This is, in some ways, understandeable, because it's not like an e-book degrades with time as a physical one might. Were it possible to sell on your old books, that might radically change the market. I could see that having both good consequences (cheaper books), but also negative ones for authors (less money). I suppose this topic merits a post or two, or even an entire book of its own, because it's a complicated subject without, in my opinion, "easy" answers. Suffice it to say, though, that there are some drawbacks, but I suppose it's also nice that Amazon "knows" which books I have, so even if I switch to a different reader, I still have my books. And it's good that authors can get paid to work on a book. Not having actually bought it yet, I have no idea how it actually 'feels' to read a book with one. I love curling up with a good book, something I certainly can't do with my laptop. The Kindle looks light and small enough that it could work, but maybe it's just too high tech and sleek to provide that same comfortable coziness. Or maybe I'm just a luddite where books are concerned?
Do you have one? Do you use it? For all kinds of books or just certain kinds (technical books, cheap 'fun' reads, whatever...)? What's the experience like?

Two kids, their really busy mother and my paid job leave me without much time to blog or do Debian related work lately (well, at least on my free time, I do Debian related things at work, but mostly as a user, not as a developer). Anyway, a couple of weeks ago I decided it was time to upgrade my home servers to Squeeze and I did it, but it was harder than expected. At home I'm using two old laptops as servers, an old Aluminium PowerBook and an Asus EeePC; the Asus was installed to replace an older PowerBook (a really old one, BTW) that I was using as home server since my father gave it to me. The plan was to use OpenVZ on the Asus to move all the PowerPC services to a couple of Virtual Environments, but as I wanted to migrate and change almost all the services I never got enough free time to finish the job and when the old PowerBook hardware failed I replaced it with another PowerBook that I wasn't using anymore, but instead of reinstalling the machine I did a clean Lenny install using a kernel with support for linux-vserver (OpenVZ does not work on PowerPC) and transformed the old machine installation (it was an Etch installation at the time) into a Virtual Private Server that run on the new hardware. Having both systems running I upgraded the VPS to Lenny and, as usually happens, left the things as they were without consolidating the services into only one machine, as I initially planned. With this state of affairs I upgraded the Asus to Squeeze without much trouble (in fact I installed a kernel without OpenVZ support, as the services I use from this laptop were running on the host and not on a VE) and did the same with the PowerPC host, but to my surprise the linux-vserver VPS failed to start with a message that seemed to imply that the VServer support was not enabled. I should have filled a bug on the BTS then, but as I looked into how to solve the issue I found bugs saying that the meaning of the message was that I had no support for linux-vserver and I needed to start the VPS ASAP, as it was the machine that runs my SMTP server. Before doing a restore of my last backup I did some digging and found a lot of messages recommending to move OpenVZ and Linux-VServer virtual machines to LXC and decided to give it a try. First I built a container on the Asus and it worked OK, after that I did the same on the PowerPC, but the script failed; luckily the patch was trivial, the problem was on the /usr/lib/lxc/templates/lxc-debian script; it uses arch to get the Debian architecture, but for powerpc it gives ppc instead of powerpc, so it needs to be fixed on the script (Note to self: I have to submit bug + patch to the lxc package to fix it). After creating this container and trying it I tried to boot my old VPS with a LXC configuration:

• For the network I used a veth device attached to a bridge (I was already using a local bridge and the /etc/network/interfaces file on the container was right, as it was the one that I copied from the old real machine).
• I also reviewed the containers' /etc/rc*.d contents, disabling the hardware related services (to do that I just followed the template script actions).

After a couple of tries I noticed that the system was not booting because it was missing the devices files needed; to fix it I copied the /dev directory of my first LXC test and using a chroot I also removed the udev packages from the container. After that last changes the machine booted as expected and all services were running OK. To summarize, I decided to do the move to LXC and fixed the configuration to boot the virtual machines on each restart:

• First I moved the machines to /var/lib/lxc/, putting each container in a sub directory that includes the machine's config file and its rootfs.
• Once I had that I linked the /var/lib/lxc/$CONTAINER/config files of the machines I want to boot on each host restart with names of the form /etc/lxc/$CONTAINER.conf and adjusted the /etc/default/lxc file accordingly:
• To try everything I rebooted the machine and all worked fine.

I know that LXC is still missing some functionality (I hate the way the container stop function kills everything instead of doing a run-level change, I guess I'll be using hacks until I move to a newer kernel with the proper support enters into Debian), but having the code on the mainline kernel is a great bonus and the user level utilities are good enough for my home needs... and I hope they'll arrive to a point where we'll be able to migrate the OpenVZ containers at work (we are using Proxmox and the support of the OpenVZ patchset is starting to worry us). On my next post: The Freak Firewall or The Story of a HA Firewall based on OpenBSD's pf running on Debian GNU/kFreeBSD hosts.

I use ratpoison as window manager on my ASUS EeePC netbook nemo for more than two years now. But although I m very happy with ratpoison in the EeePC, there are two feature wishes which have been refused by upstream: One is more flexibel window name matching for the unmanage command. The other one is focus follows mouse between ratpoison frames. Well, I always guessed that it was possible, but it took until now to find outhow to implement focus follows mouse for ratpoison. There s an ancient but still useful tool called Not a Window Manager (nawm) which is a small awk-like interpreter offering mostly window handling functions. The following .nawmrc implements focus follows mouse in nawm:

window newwin;  # stores window to raise
window lastwin; # stores previous window to prevent race conditions
leave  
    lastwin = currentwindow;
 
enter  
    newwin = pointerwindow();
    if (name(newwin) != "" && newwin != lastwin)  
        raise newwin;
        sync;
     
 

The leave hook is necessary to prevent flapping between two windows if switched between them via ratpoison s commands. I also had to add the following hook to my .ratpoisonrc to work around some cases where ratpoison s own window switching didn t work anymore. Only happened with more than one frame with one frame banishing the mouse cursor was annoying, so I filtered that case:

addhook switchwin exec if [  ratpoison -c fdump fgrep -o frame wc -l  -gt 1 ]; then ratpoison -c banish; fi

Unfortunately nawm has been removed from Debian Sid about a year ago due to being buggy and orphaned. There was not upstream development for seven years or so either. So for the moment you can get nawm either from Debian Lenny or from snapshot.debian.org. But I had to fix a segfault in nawm when calling name() on a window without name to be able to use it at all, so you will probably have to rebuild it anyway with the following patch:

diff -u nawm-0.0.20030130/builtins.c nawm-0.0.20030130-patched/builtins.c
--- nawm-0.0.20030130/builtins.c        2010-10-25 06:00:02.000000000 +0200
+++ nawm-0.0.20030130-patched/builtins.c        2010-10-25 04:15:25.000000000 +0200
@@ -546,8 +546,12 @@
     *name = gcstrdup("");
   else
      
-      *name = gcstrdup((char *)nm);
-      XFree(nm);
+      if ((char *)nm)  
+        *name = gcstrdup((char *)nm);
+        XFree(nm);
+        else  
+        *name = gcstrdup("");
+       
      
  

And yes, I m thinking about adopting and reintroducing the nawm package into Debian Sid. But I d prefer if anyone could give me a hint how to do this with more current and still maintained tools (or a patch against ratpoison :-). I looked into suckless-tools, but I haven t found anything in there which provides hooks on X events. And the Perl module Tk seems to be able to set X event hooks, but only within the application being written itself.

As requested by our beloved leader, here s my report on this year s Google Summer of Code 2010 Mentor Summit. The summit took place in Google s HQ in Mountain View, California and was what they call an unconference . In the beginning of the unconference the attendees had 10 minutes to write down proposals for a session and put them on a huge white board. After that, every attendee voted for the sessions in which he was interested by putting a small sticker on the proposal. This way we could evaluate the interest on a specific topic and schedule the sessions to the differently sized rooms according to their interest. Neat trick! The the rest of the summit was basically like a conference: we had 11 tracks filled with 5-6 sessions per day, which ran from 10:00 to 17:30. Google provided shuttle buses from our wonderful hotel to the googleplex in the morning and back to the hotel in the evening. The hotel was very nice, it was equipped a swimming pool and a hot tub (both outside), which was extensively used in the morning and of course during the night. Speaking of the night, Google sponsored Thai food in the first night and ye olde Pizza and Beer in the second. Some of the attendees brought their keyboard, guitar, bass and electric clarinet, and where playing some sweet ass Jazz and Pop (on special request ). The sessions itself where not quite what I expected. I expected some proper talks about specific topics, but it was more like and open discussion round where everyone was invited to participate. For some topics it worked pretty well, for others not. It was still totally worth coming, since you meet a lot of like minded people and there is plenty stuff to talk about. Of course I was very exited to see the googleplex. And the rumors are true: the googleplex seems to be a very nice place to work. They provide free breakfast, lunch and dinner for their employees. They have micro kitchens everywhere where you can grab free snacks and beverages. There are lot s of toys lying around, they have bicycles everywhere on the campus which you can just grab to move from one building to another. There is a dinosaur on the yard, a spaceship over the stairwell and lots of other things (testing on the toilet, anyone?), and we have probably only seen a small fraction, since we were not allowed to leave the restricted areas for the unconference. Despite the horrible yet lag (leaving Germany on Friday morning and leaving San Francisco on Sunday night), I m glad I was able to attend to the summit and can only recommend aspiring mentors and students to participate to the next summer of code!

I didn t quite believe what I was seeing until I searched and found several other people noticing the same behaviour. For background, Facebook recently introduced the concept of groups not in the sense we ve been used to, but more like lists. Groups are supposed to be to lists what databases are to bits of paper. You can add friends to groups to organise them, send them group emails, run a collective mailing list, and so on. Except that in practice, this is another really good way of exploiting lazy users. See, there are some things to know about groups:

• you don t have to opt in to one; friends can add you and that s it no confirmation necessary
• it seems that even if the group is closed, members can add other members without any controls
• if you re added and you switched off email notifications in general, you don t even know it
• the group gets an email address, which sprays inbound mail to every member until they get fed up and switch it off

The second point may be wrong it s very unclear exactly what permission is afforded to a group member and when or where information about the group membership is published. Since my day job is in private education, this immediately makes me think of two terrifying scenarios:

1. A student inadvertently gets added to a large group and nobody notices because there is so much other traffic. Whatever my other privacy settings, anything I or anyone else posted to the group is now visible to him this is the same as the previous group arrangement. The difference is that he can now go on and add anyone else Mark Zuckerberg himself even without any kind of checks by the group administrator. A membership system like this quickly spirals out of control.
2. Somebody with a grudge maybe I took too long fixing their PC adds me to a group with, shall we say, inappropriate or unsavoury content while I m away on holiday and tips off the child protection officer. Better yet, he first sends an email to all staff expressing horror and asking them to verify this in case it s his computer lying. Now there are multiple witnesses to the fact that I was a member of this group, and I return from the sea side to find a P45 on the door mat.

Unlike free software, I can t fix this. Fortunately, I have: enabled every email notification under the sun; few and trustworthy friends; according to my profile, no interests or contact details whatsoever; and no care for groups. I m happy with my lists, thanks all the same.

I launched raphaelhertzog.com this summer (taking over the English content of my former multi-lingual blog), when I decided that I would be more serious about blogging on Debian/Ubuntu related topics. On September, I decided to write 2 articles per week and up to now I managed to keep the schedule. Two of my articles were published by Linux Weekly News, those are much more researched than the average blog article (they are tagged with [LWN] in the list below). The most popular articles Most people read my blog through the RSS feed which happens to be syndicated on Planet Debian and Planet Ubuntu. According to the feedburner s statistics, the top-5 articles are:

1. 5 reasons why I still contribute to Debian after 12 years (32700 views)
2. [LWN] Understanding Membership Structures in Debian and Ubuntu (31700 views)
3. Social Micropayment Can Foster Free Software, Discover Flattr (30100 views)
4. Everything you need to know about conffiles: configuration files managed by dpkg (29900 views)
5. How to make 110.28 EUR in one month with free software and Flattr (29400 views)

But I also have occasional readers visiting my blog because my articles are announced on Identi.ca, Twitter and Facebook (and they circulate on social networks, thanks to those who are sharing them!). The top-5 articles according to the statistics of my website are:

1. 5 reasons why I still contribute to Debian after 12 years (6000 views)
2. [LWN] Can Debian offer a Constantly Usable Testing distribution? (5000 views)
3. Understanding Debian s release process (1500 views)
4. Flattr FOSS (1400 views, not an article but I regularly blog about this project)
5. Can Debian achieve world domination without being on Facebook? (1100 views)

The most flattered Since I am using Flattr on my blog, it can be interesting to see the articles which generated lots of flattr micro-donations. The top-3 articles are my articles about Flattr (1, 2, 3). Excluding articles related to Flattr, the top-5 is:

1. 5 reasons why I still contribute to Debian after 12 years (12 flattr)
2. The secret plan behind the 3.0 (quilt) Debian source package format (10 flattr)
3. How to use multiple upstream tarballs in Debian source packages? (5 flattr)
4. [LWN] Understanding Membership Structures in Debian and Ubuntu (4 flattr)
5. Do You Want a Free Debian Book? Read on. (4 flattr)

Most articles get 2 to 3 flattr clicks. The most commented I usually get 4-5 comments on most articles but some generate much more feedback:

1. [LWN] Can Debian offer a Constantly Usable Testing distribution? (40 comments)
2. 5 reasons why I still contribute to Debian after 12 years (22 comments)
3. Can Debian achieve world domination without being on Facebook? (15 comments)
4. How to generate different dependencies on Debian and Ubuntu with a common source package (14 comments)
5. [LWN] Understanding Membership Structures in Debian and Ubuntu (12 comments)

Factoids Here are my conclusions based on the above figures:

• Writing about your Debian/Ubuntu work and your long term involvement makes for highly popular content that spreads well.
• In-depth and well researched articles (like those written for LWN) do not generate more flattr revenues than the average article even if they take 4 to 8 times as long to write.
• People are more likely to flattr you for your free software contribution than for the value they get out of your article.
• People care a lot about the Debian release process, and like to discuss the topic.

If you also appreciate the above-linked articles, you should click here to subscribe to my email newsletter.

4 comments Support my work

Sunday. A good day to take some time to myself, and get some much needed excercise. And the pseudo-meditation that comes with it: That's one of the factors I love the most about cycling. It's possibly my favorite way of just idling, of allowing for the time to pass without me noticing, just watching the movie of life, watching the world go around me with very little effort. I just love cycling. I have posted here several mentions of the Ciclot n: Every month, the last Sunday, our city government closes a ~32Km circuit to make it for cycling (and skating, and walking, and jogging, and other human-powered locomotion) use. Whenever I am in the city and have the possibility, I do the Ciclot n. Two months ago, I even did it twice in a row, for a total of almost 70Km. But this Sunday was not the last Sunday of the month! So, why am I writing this? Well, because when I left home today at ~10AM, I thought it was. Only when I reached Circuito Interior and had a this is full of cars moment, I remembered October has 31 days. And next Sunday I'll very probably be in Oaxaca city (for the Hackmitin 04h4ck4 2010). And I didn't want to miss the fun of a nice Sunday ride! I don't care if streets are closed just for bikes I am used to riding in traffic. Of course, this meant I would not take the central lanes in Circuito Interior on the way back, taking the ~10 bridges (which are quite tiring, to be honest!). It also meant I was free to make my own route. So, I thought, a nice small ~20-30Km ride will do. I'll just get to Eje 2 Sur or so, and back by another route (i.e. Plutarco E. Calles or so). But as I got closer to Reforma, I realized that every Sunday (independent of a Ciclot n), Reforma is closed for the "Paseos Dominicales" - Shorter than a Ciclot n, but still a nice way to share the streets with other cyclists. So I headed for Reforma. Part of Reforma (from the ngel roundabout westward) was closed due to a precisely cyclist race. But from there eastwards we had the street for us. Good, lets head downtown. The surprise came when I saw that it was not only towards downtown, but passing Av. Ju rez, Reforma continued to be closed just for cyclist use northwards. Great! Lets see how far does it go. The first surprise there: A couple of days ago, it was the "Noche de los Alebrijes". The alebrijes are a beautiful and very elaborated Mexican typical handicraft, depicting psychodelic dragons or dragonic representations of animals. Of course, alebrijes are usually ~30cm long... But here we had huge ones! And verrrry elaborated! How much so? You tell me. And as I started off... A nice thing about cycling is that you get to meditate. My body continued cycling, taking care not to run over the kids that are not so proficient, stoping at each red light... At some point, my mind entered back the body, and I realized we were passing by Tlatelolco (ok, to be honest, the picture was taken when crossing southwards, on my way back), about to cross Circuito Interior on the North, in that symbolically very strange place where Paseo de la Reforma (a long, beautiful avenue named after the war that marked the complete separation between church and Mexican state, in 1860) becomes two streets... Calzada de los Misterios and Calzada de Guadalupe. And, yes, it is among the greatest peregrination routes in the world. On December 12, the Holiday of the Guadalupe Virgin, up to 7 million people go visit her temple. And also around here, when my mind was busy inside my body, I noticed a pair from the Un paseo a ciegas (roughly translated, a blind ride) program was riding just by me. I knew about this program, but had never seen them before So I took the opportunity to get to know this program. Basically: Two people ride a tandem bike. The one in front, as always, drives and steers. The one in the back is a blind person, who gets the amazing sensation of freedom and enjoyment that only a bike gives you. Un paseo a ciegas is held every Sunday at 9AM except for the last Sunday every month. And I definitively want to be part of it! They told me the program has been adopted as well in Puebla, and if I recall correctly, it will soon be started in Quer taro and Guadalajara. Anyway, by then I realized the ride was probably going to reach the Bas lica, a very impressive church I had just visited for the first time ever a couple of weeks ago. And yes we went all the way up Guadalupe until the place where the street gets impossible to bike on, then left along a small street, and back to the South by Misterios. Then, all the way along Reforma again, saying goodbye to Cuitlahuac, Jos de San Mart n, Sim n Bol var, El Caballito, Cristobal Col n, Cuauhtemoc, La Palmera, El ngel... And back home. Of course, not without the sight of some bizarre signs we enjoy so much to find, point at and laugh. Have I ever told you, my nameless reader, that I love this city? I love getting surprised with so many great things. I love the distances I can safely ride on my bike without ever being far from a bike repair shop (which are only needed when they are far away). I love being surrounded by people breathing their freedom to take the streets. I love the safety of our wide, long streets (and no, I'm not joking here Mexico City is among the safest places for cyclists I have been to). I love its weather, that allows me to go out and enjoy the street at any time of year. And I love biking in it, one of the best ways to get to know so many bits of the city I would have never ventured into otherwise.

My humble RC bug squashing efforts for this week. I've saved them all up, because I don't want to spam Planet Debian too much... or alternatively, because I've been feeling ill Thursday/Friday and didn't do anything at all.

• #598619 in x11vnc NMU'd, after one false start, but at least I learnt something.
• #586849 and #586838 in mgltools- utpackages,geomutils confirmed fixed.
• Patch written for #592417 in mgltools-utpackages.
• Verified and NMU'd patch for #410130 in cryptonit.
• #590383 in rabbitmq-server confirmed fixed.
• Investigated why #589194 in openclipart hadn't been closed, although it was Anibal who eventually sponsored the patch.
• #599988 in lwjgl fixed and uploaded.
• Confirmed #599959 in sawfish closed from last week, after it got binNMUs.
• Patch finally written for #593856 in gnucash.

Note that quite a few of these were "cheating" by just closing bugs that someone else had written a patch/comment for, and the mgltools-* ones are in non-free software, so they won't have the same impact on the RC bug stats. Also, I've mentioned the gnucash and sawfish ones before, but they'll definitely be counted in the stats now..

The FSF has published criteria under which it would endorse hardware as being 'free hardware'. My guess on the number of companies that would be interested in this policy in its current form: 0 My reason for that is fairly simple:

Any product-related materials that mention the FSF endorsement must not also carry endorsements or badges related to proprietary software, such as "Works with Windows" or "Made for Mac" badges, because these would give an appearance of legitimacy to those products, and may make users think the product requires them. However, we don't object to clear factual statements informing the user that the product also works with specific proprietary operating systems.

In other words, "if you're going to be using our badge to say that your hardware is free, you must not be using the official badges that show it also works with other operating systems." Or, also: "if you want to make your product more attractive to the 10% of users who prefer free solutions, you must in the process make it less attractive to the 90% of users who don't (yet)." I don't think that's going to fly.

One big change in the recent OASIS v0.2 release is the replacement of Str by Pcre. The big advantage of Pcre is that it can be used in multi-threaded environment, whereas it is not recommended to do so with Str. Since OASIS is used by the OCsigen part of OASIS-DB, we need to make it work safely with Lwt with multiple users at the same time. Note that, we can probably use Str directly with Lwt, because it is not really multi-threaded. But we want to be safe on this point and Pcre is a very powerful library. But the OCaml Pcre library depends on an external C library (pcre). This is not a problem on Linux et al, where it is shipped with the OS by default. But on Windows, you need to build it yourself. We want to do it using Microsoft Visual Studio 2008, mainly because OCaml was compiled with it -- and it seems the most natural way to build C library on Windows. As usual, building Open Source C libraries using MS Visual Studio, is not the most common way to process. However, the use of CMake enables a simple way to do it. Here is how we can compile pcre and pcre-ocaml for Windows:

• Download pcre and unzip it. We use 7.7, which is not the latest version, but the one matching GODI configuration
• Create c:\pcre\build and c:\pcre\pcre-7.7, beware that you should avoid spaces in the name, there is a small bug in OCaml with spaces for C options
• Download and install cmake
• Run cmake-gui and point the sources to the location of your unzipped pcre directory
• Run Configure a first time
• Choose Visual Studio 9 2008 generator
• You should get the configuration display as following:

• Change the CMAKE_INSTALL_PREFIX to c;\pcre\pcre-7.7, don't select BUILD_SHARED_LIBS
• Run Configure again
• Run Generate
• Start MS Visual Studio 2008
• Open the PCRE solution located in c;\pcre\build

• Choose Solution: Release
• Generate the target ALL_BUILD
• If you don't have already administrator rights, restart Visual Studio with administrator rights
• Generate the target INSTALL
• Go to c:\pcre\pcre-7.7\lib and copy pcre.lib to libpcre.lib, to avoid name clashes with the future OCaml library
• Download and unzip pcre-ocaml
• Start a Visual Studio command line and run a cygwin shell inside it (e.g. my script to run cygwin shell with Visual Studio 2008)
• Change directory to lib directory of the unzipped source of pcre-ocaml
• Apply this patch, if it is not already applied
• Edit make_msvc.bat and set the variables PCRE_H and PCRE_LIB to good values set PCRE_H=C:\pcre\pcre-7.7\include and set PCRE_LIB=C:\pcre\pcre-7.7\lib\libpcre.lib
• Run make_msvc.bat

The best way to test your newly created OCaml pcre library is to try to compile an example from the examples directory of pcre-ocaml itself. Sylvain Le Gall is an OCaml consultant at OCamlCore SARL

While I have spent countless hours working on the new source format known as 3.0 (quilt) , I ve just realized that I have never blogged about its features and the reasons that lead me to work on it. Let s fix this. The good old 1.0 format Up to 2008, dpkg-source was only able to cope with a single source format (now named 1.0 ). That format was used since the inception of the project. While it worked fine for most cases, it suffered from a number of limitations mainly because it stored the Debian packaging files as a patch to apply on top of the upstream source tarball. This patch can have two functions: creating the required files in the debian sub-directory and applying changes to the upstream sources. Over time, if the maintainer made several modifications to the upstream source code, they would end up entangled (and undocumented) in this single patch. In order to solve this problem, patch systems were created (dpatch, quilt, simple-patchsys, dbs, ) and many maintainers started using them. Each implementation is slightly different but the basic principle is always the same: store the upstream changes as multiple patches in the debian/patches/ directory and apply them at build-time (and remove them during cleanup). Design goals for the new formats When I started working on the new source package format, I set out to get rid of all the known limitations and to integrate a patch system in dpkg-source. I wanted to clear up the situation so that learning packaging only requires to learn one patch system and would not require modifying debian/rules to use it. I picked quilt because it was popular, came with a large set of features, and was not suffering from NIH syndrome. This lead to the 3.0 (quilt) source format. I also created 3.0 (native) as a distinct format. 1.0 was able to generate two types of source packages (native and non-native) but I did not want to continue with this mistake of mixing both in a single format. The KISS principle dictated that the user should pick the format of his choice, put it in debian/source/format and be done with it. Now the build can rightfully fail when the requirements are not met instead of doing something unexpected as a fallback. Features of 3.0 (quilt) This is the format that replaces the non-native variant of the 1.0 source format. The features below are specific to the new format and differentiate it from its ancestor:

• Supports compression formats other than gzip: bzip2, lzma, xz.
• Can use multiple upstream tarballs.
• Can include binary files in the debian packaging.
• Automatically replaces the debian directory present in the upstream tarball (no repacking required).
• Creates a new quilt-managed patch in debian/patches/ when it finds changes to the upstream files.

Features of 3.0 (native) This format is very similar to the native variant of the 1.0 source format except for two things:

• it supports compression formats other than gzip: bzip2, lzma, xz.
• it excludes by default a bunch of files that should usually not be part of the tarball (VCS specific files, vim backup files, etc.)

Timeline Looking back at the history is interesting. This project already spans multiple years and is not really over until a majority of packages have switched to the new formats.

• January 2008: the discussion how to cope with patches sanely rages on debian-devel@lists.debian.org. My initial decisions are the result of this discussion.
• March 2008: I have implemented the new formats and I request feedback. dpkg 1.14.17 (uploaded to experimental) is the first release supporting them.
• April 2008: I ask ftpmasters to support the new source packages in #457345.
• June 2008: Lenny freeze. dpkg is not supposed to change anymore. Several changes concerning the new source formats are still accepted in the following months given that this code is not yet used in production and must only be present so that lenny can cope with new source packages once squeeze starts using them.
• February 2009: Lenny release.
• March 2009: Work on squeeze has started, ftpmasters have done nothing to support new source formats, I submit a patch in #457345 to speed things up. I start a wiki page to track the project s progress and to answer common questions of maintainers.
• November 2009: After an ftpmaster sprint, it s now possible to upload new source packages in unstable. This draws massive attention to the new format and some people start complaining about some design decisions. The implementation of 3.0 (quilt) changes a lot during this month. dpkg in lenny is even updated to keep up with those changes.
• March 2010: Up to now, I was planning to let dpkg-source build new source packages by default at some point in the future. After several rounds of discussions, I agree that it s not the best course of action and decides instead to make debian/source/format mandatory. The maintainer must be explicit about the source format that s/he wants to use.
• October 2010: The new source formats are relatively popular, a third of the source packages have already switched: see the graph. The squeeze freeze in August clearly stopped the trend, hopefully it will continue once squeeze is released.
• June 2013: Project is finished?

As you can see this project is not over yet, although the most difficult part is already behind me. For my part, the biggest lesson is that you won t ever get enough review until your work is used within unstable. So if you have a Debian project that impacts a lot of people, make sure to organize an official review process from the start. And specifying your project through a Debian Enhancement Proposal is probably the best way to achieve this. If you appreciate the work that I put into this project, feel free to join Flattr and to flattr dpkg from time to time. Or check out my page Support my work .

12 comments Support my work

I recently uploaded new upstream versions of two neat small X tools to Debian Experimental:

• xrootconsole displays on a transparent or shaded layer on the root window what it gets as input on STDIN, from a FIFO or from a file, and
• keynav, a way to control your mouse cursor efficiently with the keyboard.

Both packages introduce several new features and I d be happy if users of these packages in Debian Sid or Debian Sid users curious about them could test the versions in Debian Experimental. xrootconsole 0.6 + patches xrootconsole saw no love since 2006 with the last maintainer upload having been in 2002. Nevertheless it never got kicked out of Debian just because of this. The package had been forcibly orphaned just less than a year ago. So it s no big wonder that this new upstream version I packaged was released already back in 2004. :-) But besides packaging a new upstream version, bumping Standards-Version and debhelper compatibility, fixing tons of lintian warnings and some bugs, I also added two patches which add new features not (yet) available upstream:

• UTF-8 support: Upstream xrootconsole just drops all bytes where the 8th bit is set which only allows ASCII. Miroslav Jezbera submitted a patch to allow at least displaying localized text containing single byte 8 bit characters as used in all ISO-Latin encodings. Inspired by the patch to add UTF-8 support to ratmenu, I wrote a patch to add UTF-8 support for xrootconsole, too.
• ANSI color support: Last year, Julien Viard de Galbert, who is also active in Debian, posted a patch in his blog to support ANSI colors as produced by many log colorizers like e.g. loco (RIP), colortail, lwatch, or ccze. (Didn t get colortail and lwatch to work with xrootconsole yet, though.) I included this patch and made it compatible with my UTF-8 support patch. The patch raises the memory consumption per displayed character by one byte, but effectively I just saw an overall memory usage increase of about 25% which seems acceptable.

Of course I informed upstream about these feature patches, but I haven t got any feedback yet. But I got feedback from Julien Viard de Galbert, and he ll join me in packaging xrootconsole as co-maintainer. keynav 0.20101014.3067 I adopted the Debian package of keynav recently, subscribed to the keynav mailing list (well, it s a Google group), got a nice welcome mail from the very friendly upstream developer Jordan Sissel who offered to help with any keynav issues. I told him what features I d like to see in keynav to fit better the setup where I m using it. And just a few days later there was a new upstream release including both features I suggested, some more neat new features, and one bug fix. Jordan Sissel writes in the upstream changelog (emphasis and italic text by me):

• Added restart command. Makes keynav restart. Useful for binding a key to reload the config.
• Added loadconfig command. This lets you include additional config files to load on the command line or in one of the default keynavrc files. (requested by Axel Beckert) and already in use here.
• keynav will now restart if it receives SIGHUP or SIGUSR1
• Map Enter by default to warp,click 1,end (requested by Axel Beckert)
• Fix a bug causing the point under the mouse cursor to not click through the keynav window in certain conditions. Reported via mailing list by Eric Van Dewoestine and Krister Svanlund.

Both packages will be reuploaded to Debian Sid (Unstable) after the release of Debian Squeeze (currently testing ).

It was for a very long time (I think back from PyconIT 2) that I wanted to contribute to python. About a month and a half ago I started reading all the documentation I could about development processes & workflows, mercurial stuff (I don't have commit right, so I prefer working on a DVCS than on SVN), bugs management and so.

The big advantage of Unison on Windows is that it allows quite easily to synchronize between Windows and Linux. For those who need to work on Windows with the same set of files as on Linux, this is a big plus. Other tools do it as well, but the 2-way sync of Unison is quite nice. When you need to compile a software on Linux and Windows, you can modify both side at the same time and (almost) don't have problems. On Windows, the .unison and unison.log are located into your %HOMEPATH%, which the upper directory of the classic Documents folder. In the directory .unison, you will find the .prf files that describe your unison profiles. As usual, default.prf in this directory is the default profile. Basic The basic tips are:

• use fastcheck = true in your default.prf
• disable directory indexing

You can also disable virus live scan -- if you think it is safe!!!! SSH Using ssh under Windows is always a challenge. As a matter of fact, this tool doesn't match Windows context and it is not as integrated as in Linux/BSD. There is Putty which can help you. It has a good support for remote shell but it is not very easy to setup with Unison. Putty and OpenSSH doesn't have precisely the same set of options and Unison relies on some not available in Putty. There is a script called ssh2plink.bat that can help you using Putty's plink as with Unison. I used it for a while, but this didn't give the expected throughput. The best option is to use the ssh command provided by Cygwin. In this case you have at the same time good throughput and unison integration. I explain here how to configure you Cygwin's ssh to use a SSH key. You can bypass the following steps, if you wish to use a password or if you have already setup your ssh to connect to the target computer. Launch Cygwin's setup.exe and select openssh for installation. To add a SSH key, launch the cygwin shell:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
[...]

Copy the file .ssh/id_rsa.pub to your target computer's .ssh/authorized_keys. You should be aware that the file format can be Windows EOL style (in this case use dos2unix to convert the file) and if you copy/paste from a dos box, some end of lines are added and you should remove them from the authorized_keys, to have a single line key. Once, you have installed your ssh key into target computer, you should try to connect directly from the cygwin shell.

$ ssh XXX

Now, you can configure sshcmd = c:\cygwin\bin\ssh.exe to your default.prf. Using Cygwin's ssh allow you to get ~2MB/s (or more) when you only get ~100KB/s using ssh2plink.bat. If you have any other tips to improve Unison on Windows, I will be happy to test them and post it here.