...where naming "server" the free software project you were developing durung your PhD was possible:

bubulle@mykerinos:~/tmp/server-0.5> ls -l
total 408
-rwxr-x--- 1 bubulle bubulle     50 jan 10  1992 bad
-rwxr-x--- 1 bubulle bubulle     58 jan 10  1992 clear
-rw-r----- 1 bubulle bubulle     57 jan 10  1992 debug
-rwxr-x--- 1 bubulle bubulle     52 jan 10  1992 good
-rw-r----- 1 bubulle bubulle    987 jan 14  1992 local.h
-rwxr-x--- 1 bubulle bubulle     43 jan 10  1992 mine
-rwxr-x--- 1 bubulle bubulle  52140 jan 14  1992 myserver
-rw-r----- 1 bubulle bubulle      0 jan 10  1992 pcsa.in
-rw-r----- 1 bubulle bubulle      0 jan 10  1992 pcsa.out
-rwxr-x--- 1 bubulle bubulle     30 jan 10  1992 pss
-rwxr-x--- 1 bubulle bubulle  40960 jan 10  1992 server
-rw-r----- 1 bubulle bubulle  47906 jan 15  1992 server.c
-rw-r----- 1 bubulle bubulle   4632 jan 15  1992 server.h
-rw-r----- 1 bubulle bubulle     62 jan 10  1992 services
-rwxr-x--- 1 bubulle bubulle 228572 jan 10  1992 sockspy
-rwxr-x--- 1 bubulle bubulle     43 jan 10  1992 theirs

Reading that 50k source file shows:

/*
Unix file server for Pathworks for DOS.
Version 0.5.
Copyright (C) Andrew Tridgell 1992.

I wonder if we could re-package this for Debian, 16 years after. Anyone feeling like ITP this?

Following the first phase, the second and final phase of the Penny and Martin adventure ended last Friday at Wellington airport. I am now 11 500 metres high on my way from Bangkok to Zurich, looking back at seven days on the New Zealand South Island, another in Wellington, and a night in Melbourne. Here s the summary of the 2200km we travelled, with selected photos inline. Penny has more pictures in her Flickr album.

• Thursday: ferry from Wellington to Picton and on to Amberley, where we stayed with Penny s sister Janey.
• Friday: via Christchurch to Lake Tekapo for a lovely swim in turquoise water, before we set up the tent at Lake Pukaki with Mount Cook in the distance. Camping with a car isn t all bad.
• Saturday: via Wanaka en route to Haast Pass with a stopover at the Gates of Haast for some rock hopping and full body immersion in the icy water (yes, Penny went in all the way, too). From Haast, we took the beautiful road to Jackson Bay and back, before heading into Cascade Valley for another night of camping, this time with millions of sandflies forcing us to dress appropriately. NB: please, no new offers for fashion modeling contracts, I am already fully booked. Penny might appreciate them though, especially if she gets to wear white socks.
• Sunday: fled the valley as if running for life (think final scene of Hitchcock s Birds) to prevent further sandfly attacks and headed north to the Fox and Franz Josef Glaciers, where we got soaked in heavy rain. Reached Greymouth in time for the tour of the local Monteith brewery and spent the night recovering from the camping in the Charles Court Motel. Monteith s Munich-style Golden lager beer is actually quite reminiscent of Munich-style lager! I also got to take three girls to the men s toilet to see the world s coolest urinal.
• Monday: the bad weather followed us up the west coast to Punakaiki but didn t deter us from taking a short hike to the pancake rocks, nor from visiting the seal colony at Cape Foulwind later in the day. I found out how much Penny loves Nikau trees. From there, headed west for Lewis Pass and passed up on camping due to the heavy rainfall. Instead, we booked into the Maruia Springs Resort Hotel and indulged in hot springs recreation and camping-stove-cooked pasta in the room.
• Tuesday: the weather in Kaikoura, which we reached around noon the next day, wasn t any better, which foiled our diving plans, so we continued on to Picton and decided to cut our road trip short by one day to give us more time tying up loose ends in Wellington.
• Wednesday: got up early to rent diving equipment for two dives at Karaka point, where we inspected (and swam through) an old ship s wreck. We also collected around 20 scallops, which we brought to Penny s parents and enjoyed them cooked in ginger and garlic for a late lunch. The ferry took us back to Wellington that night, where I got to see Eagle vs. Shark, a Kiwi movie starring Jemaine Clement from the Flight of the Conchords and music composed by local bands, foremost of which The Phoenix Foundation. I have to side with Penny: it s an enjoyable flick but probably not worth watching multiple times.
• Thursday: following breakfast at the Olive cafe, we went on shopping sprees (I found a store selling Icebreaker gear at 50% ), chilled in the afternoon, fetched excellent Sushi at the Wasabi Sushi Train, and finally saw The Phoenix Foundation play a free concert at Frank Kitts Park.

My New Zealand beer top-ten, in reverse order: Monteith s Original, Monteith s Black, Mac s Great White, Monteith s Golden, Monteith s Celtic, Monteith s Pilsener, Emerson s Pilsener, Mac s Hop Rocker, Emerson s 1812 India Pale Ale, and (drum-roll): Mac s Sassy Red. Yum! The Emerson beers get no links because the brewery website uses Flash. Thanks, Penny, for a fabulous two weeks! NP: The Flower Kings: Back in the World of Adventures

Well, I guess it's time to talk.

I mentioned in my last post some back troubles. These aren't really news - I've had those for a long time. The news is the discovery in early January that there's some sort of growth / lesion / tumour on that spot causing me further problems now.

So I've been for tests. The MRI was a couple weeks ago. The CT scan earlier today. I have an angiogram tomorrow to map it further. The idea in my head was to wait until I had something interesting to tell people. A plan, knowledge, all the rest.

Well, I don't have that yet. But where two days ago, I was thinking that tomorrow was just a day of tests, it seems that as part of the angiogram an embolism is possible - that's where they try to cut off the blood supply to a tumour to make later surgery a bit easier. It carries risks. It carries a night in the ICU and another night in a ward. Surgery would need to follow within two weeks.

So I still have nothing to tell people. I'm used to being one of the ones with the answers handy. I'm obviously a bit nervous, but more in anticipation.

Thoughts and love are appreciated. We get started at 7am pacific.

On the 20th of January (8 days before the start of linux.conf.au) I advertised contest to write blog posts related to computer security for the conference Planet [1]. The aim of the contest was to encourage (by money prizes) people who had no prior experience in computer security to get involved by writing blog posts. The rules permitted security professionals to enter but only for an honourable mention, the money was reserved for people without prior experience. The money that I initially advertised was a fraction of what was reserved for prizes, the idea being that if the contest went well then the prize pool could be easily increased but that if it didn’t go well then there would only be one small prize for someone to win by default. At the time I considered a single entry winning by default to be the worst case scenario. The eventual result was that there was only one entry, this was from Martin Krafft on the point of keysigning [2]. Martin has prior experience in the computer security field which excludes him from a money prize, but he gets the only honourable mention. From a quick conversation with him it seems that his desire from entering the contest was to get his ideas about weaknesses in the keysigning process spread more widely, so this seems like a fairly ideal result for him. I agree with Martin that there are significant issues related to the keysigning process, but my ideas about them are a little different (I’ll blog about it later). His point about people merely checking that the picture matches on the ID and not verifying what the ID means is significant, the fact is that the vast majority of people are not capable of recognising ID from other countries. Other than requiring passports (which differ little between countries) I can’t think of a good solution to this problem. Congratulations Martin! It is a good post and a worthy entry. Now as to why the contest failed. I spoke to some people at the end of the conference about this. One delegate (who I know has the skills needed to produce a winning entry) said that I advertised it too soon before the conference and didn’t give delegates time to write entries. While I can’t dispute his own reasons for not entering I find it difficult to believe that more than a small proportion of delegates had that motivation. The LCA Planet had some lengthy posts by other delegates, and the guy who won second prize in the hack-fest spent something like 20 hours coding on his entry during the conference time (I suspect that my contest had the potential for a better ratio of work to prize money). Also the 8 days before the conference started was a good time to write entries for the contest. One suggestion was that I propose that the conference organisers run such a contest next year. The problem with this is that it’s difficult to say “I tried this and failed, could you please try it too”. If nothing else I would need some significant reasons to believe that the contest has the potential to be more successful before attempting it on a larger scale. If the contest had been backed by the LCA organisers then it might have been more successful, but that possibility seems unlikely (and there is scope for an event to be more successful than mine while still being a failure). The reason that I consider it unlikely that official support would make it more successful is that I first advertised the event on my blog (syndicated to the conference Planet). Everyone who has a blog and attends the conference can be expected to have read about it. I then advertised it on the conference mailing list which I believe had as subscribers a large portion of the people who have enough spare time to create a blog specifically for the purpose of entering such a contest. A blogging contest related to a conference but which had a wider scope (IE not limited to one field but instead covering anything related to the conference) might be successful. If someone wants to run such a contest next year then it’s probably worth doing. Of course I have not given up on the plan of getting more people involved in computer security, expect to see some blog posts from me in the near future with other approaches to this. Suggestions would be appreciated.

• [1] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [2] http://madduck.net/blog/2008.01.28:on-the-point-of-keysigning/

Share This

Public Service Announcement: The LinuxBIOS project, a Free Software project which intends to replace the proprietary BIOS found in most computers these days, has been renamed to coreboot. The old name has become quite a misnomer in recent years; the name LinuxBIOS created the impression that it's a drop-in BIOS-replacement and that it's using Linux or is Linux-specific in any way. Neither is the case.

• coreboot is not a BIOS in the sense that it provides the legacy BIOS callbacks / interrupt routines. Instead, coreboot is just a small hardware initialization firmware. It does some basic hardware init, then hands over control to one of many possible payloads. This can be a boot loader such as FILO (or GRUB2, which shall ultimately replace FILO) if you want to boot from disk, or Plan 9, or memtest86, or a Linux kernel, or OpenBIOS/OpenFirmware/SmartFirmware, or...
• coreboot is not Linux or Linux-specific. Yes, it can indeed use Linux kernels as payload (i.e., you put the Linux kernel in your flash ROM chip together with coreboot) or boot a Linux kernel indirectly using FILO/GRUB2. But as mentioned above it can also be used (together with the fitting payload) to boot other OSes or systems such as Plan 9, Windows, FreeBSD, and others.

The initial author and project leader of LinuxBIOS/coreboot, Ron Minnich, explains in more detail why the renaming was done in his original announcement on the coreboot mailing list.

I finally got around to finishing MyTab on Sunday, the group finance web app I’d been promising my housemates for a while. I’m not exactly sure how to describe it, but it’s kinda the equivalent to that sheet of paper on your fridge that you use to share bills around the house. I wrote it mainly for my current house to use, but if other people find it useful, then that’s great. It’s got RSS feeds and some shiny AJAX, which proves that I’m totally down with the kids. (However, the Javascript is optional and it also supports email notifications, so I’m also down with the adults.) It’s my first experience writing a Django app, which was mostly an enjoyable experience. In somewhat of an experiment, it’s released under that crazy Affero GPL license. Patches welcome, as usual.

In the past I was not blogging small things if they were not worth a full blog entry on their own (or if I did not have the time to make up a full entry of it :). Inspired by the example of Raphaël Hertzog <hertzog@debian.org> with "News for Debian developers" for <debian-devel-announce@lists.debian.org>, I am intending to do the same on a monthly basis about my own Debian related work. This first entry about January 2008 also covers a few things from the last month of 2007. General News

• Trusted Computing
  
  After having taken over some rotting ITP bugs, Debian has now all the important packages to support Trusted Computing on platforms containing a TPM chip. The packages are not in good enough quality for release, but there is still some time left to fix that. Looking forward to make lenny supporting TPM properly out of the box, as well as aiming for making Debian the best TPM enabled distribution available.
  
  Currently, the TSS software stack consists of trousers, tpm-tools, opencryptoki, libengine-tpm-openssl, and ecryptfs-utils.
  
  
• Smartcards
  
  I am using smartcards since a while to hold GnuPG, LUKS, and OpenSSL keys/certificates. Thanks to Jonas Meurer <mejo@debian.org> for applying a fix and a patch of mine to cryptsetup. Together with my uploads of gnupg-pkcs11-scd, pam-pkcs11 and pcsc-omnikey, I can now use Debian out of the box with smartcards for authentification, not relaying on patched or private packages anymore.
  
  The next aim is to integrate smartcard support into debian-installer. It should be possible to use/store keys or certificates for encrypted filesystems directly from/to a smartcard during installation time.
  

Package News

• botan-devel
  
  The Botan library is maintained upstream in a stable release branch and a development release branch. Before, I was uploading as versioned source packages, botan1.4 and botan1.5. To be a bit more consistent, the two source packages are named botan and botan-devel now.
  
  
• gitosis
  
  Tommi Virtanen <tv@eagain.net> has written a marvelous tool to securely manage hosted git repositories, named gitosis. Having always looked for an elegant sollution to maintain git repositories through push/pull over SSH only, this package made an excellent addition to the Debian archive.
  
  
• gnunet
  
  GNUnet, more precisely the gnunet, gnunet-gtk and gnunet-qt packages where mainly maintained the last years by Arnaud Kyheng <Arnaud.Kyheng@free.fr> with me playing co-maintainer.
  
  Arnaud has become busy within the last months, so I took over a more active role on its maintenance. Currently, all gnunet related packages are in sync and in its latest upstream version available in the archive. There is even a new sibling, gnunet-fuse.
  
  
• icedove-l10n
  
  After one and a half year of pushing its maintainer without any effect at all, I finally took over the unmaintained icedove-locales package in October 2007. I immediately changed the package to the proper naming scheme (icedove-l10n-*) which was an outstanding issue since August 2006.
  
  In the last weeks, I have added unofficial localizations for Galizian, Nepali and Ukrainian, now supporting 38 localizations in total. Icedove localizations are now in good shape again, always matching the Icedove version and no longer lagging behind.
  
  
• iceowl-l10n
  
  Following iceweasel-l10n and icedove-l10n, there are finally also localizations for iceowl (Mozilla Sunbird) available. Populating packages for iceowl-extension (Mozilla Lightning) from the same source package is a bit trickier package-wise, but will be available soon too.
  
  
• iceweasel-l10n
  
  In September 2007, Robert Milan <rmh@debian.org> on behalf of the Catalan/Valencian Debian translator team asked me to remove the iceweasel-l10n-roa-es-val package. Unfortunately, this localization is related to a long standing cultural and political dispute between the Catalan speaking Spanish people and the City of Valencia. Additionally, the localization itself is of poor quality. Of course, I removed the package in unstable immediately and prepared an upload for stable at the same time.
  
  As usual, me asking something on debian-release results in first beeing ignored, then denied and third, two month after my request, beeing privately asked to upload nevertheless. This is one of the reasons I sometimes fully understand fellow maintainers not carring about stable at all anymore, it has become indeed too much of a hassle.
  
  
• traceroute
  
  For the last decade, Debian was shipping an implementation of traceroute originating from BSD. After I took over the package in late 2006, it became clear to me that Debian should not maintain its very own version of traceroute. Therefore, I replaced traceroute in August 2007 with an implementation from Dmitry K. Butskoy <Dmitry@Butskoy.name>. Apart from the fact, that this modern implementation is better in every way (faster, cleaner, less bugs), it has an active upstream maintainer and is used by different other Linux distributions too.
  
  
• syslinux
  
  Thanks to the work of Robert Milan <rmh@debian.org>, syslinux has now 64-bit CPU detection in unstable (2:3.55-2) and experimental (2:3.60-2) again.
  
  

Team News

• Debian Forensics
  
  Unfortunately, Debian has at the moment very few forensic related packages in the archive.
  
  Christophe Monniez <dfence.242@gmail.com> maintains a lot of forensic related packages on behalf of his Debian based forensic LiveCD. Beeing interested to see them in Debian, I am mentoring him now how to merge them properly into Debian where possible, and maintain them in the official archive. We have formed an Alioth project for this purpose. Packages are maintained in git, everyone is welcome to join.
  
  
• Debian Website
  
  After having offered my help to maintain the Debian Consultants list, I got added to the webwml team. Doing Debian consultancy myself, this is just another way of helping out Debian from time to time by adding, removing and updating some entries of like-minded people in a list.
  
  

I went back to work today after something like a total of 6 weeks off. (2 weeks vacation, 4 weeks unpaid leave). The month of January went pretty quickly really. The week in hospital with Sarah was a blur. The week and a half afterwards was also pretty much a blur. Then we had the week where things went a bit backwards, and then we had this week, a few days of which were spent up north at an inn in Little River, Mendocino County. Heck, let's just call the entire month a blur and be done with it. Sarah's doing pretty well now. Surgery on the 3rd, discharged on the 9th, back in the Emergency Room on the 21st with tachycardia. Concerns about the incision weeping on the 21st, and again on the 28th. General increase in pain on the 28th, along with a few sleepless nights preceding. But now, with a doubling of her beta blockers, some antibiotics, pain killers, anti-inflammatories and sleeping tablets, she's feeling a bit more human again, if not like a human pill bottle. The surgical folks want to see her again on Monday to follow up how the incision is going since they prescribed the antibiotics. The weeping has calmed down significantly, but hasn't gone away completely. A couple more months to go before we can call her "recovered".

I'm really pleased to announce here that one of the projects Maj and I have been working on for a long time has finally come to fruition. Today Wikitravel Press launched its first two Open Content printed guidebooks -- Wikitravel Chicago and Wikitravel Singapore. When we started Wikitravel back in 2003 (!), our sincere hope was that at some point in the future, people would be able to carry Wikitravel guidebooks with them on a trip. I think that mobile technology is excellent, and it's amazing how much you can read on a cell phone or PDA these days. But there's still something so convenient about a printed guidebook: it never runs out of batteries; you don't need an uplink to read it; you don't have to worry about it getting stolen because you flashed it out in the wrong caf or restaurant. To be honest, I thought that one of the "traditional" guidebook publishers would step in and use Wikitravel content in their guides. But that didn't happen, and along with our partner Jani Patokallio, Maj and I decided to start a publishing company ourselves. Thus Wikitravel Press, and our first two books. We have a number of other books in the pipeline, and our hope is to have a few dozen available by the end of the year, and a few hundred by the end of the following year. I'm working on the Wikitravel guide to Montreal, and Maj and I are collaborating on Buenos Aires. We're taking a 6-week trip to Argentina in February/March, so this should be a great time for research. I heartily encourage any writers or editors who are interested in working on travel books to contact Wikitravel Press about your ideas of bringing Wikitravel content to print. I think this is a great opportunity for people who want to encourage Open Content, or who want to get into the travel writing field, or who just love the idea of wikis-to-books. tags: wikitravel wikitravelpress travel guidebook singapore chicago

With pristine-tar version 0.5, I've added a new feature: The ability to easily inject enough information into a git repository so that a pristine tarball can later be regenerated from that repository. If a package's upstream branch contains the upstream source corresponding to the tarball to be imported, it's very simple to use.

joey@kodama:~/src/fbreader> pristine-tar commit ~/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz 
pristine-tar: committed fbreader_0.8.12.orig.tar.gz.delta to branch pristine-tar

Otherwise, you also have to specify a tag (or any tree-ish really) where the upstream source can be found.

joey@kodama:~/src/fbreader> pristine-tar commit ~/fbreader_0.8.9.orig.tar.gz upstream/0.8.9
pristine-tar: committed fbreader_0.8.9.orig.tar.gz.delta to branch pristine-tar

Here's what it puts in the pristine-tar branch that it creates. In this example, the delta files are 40-some kilobytes, which is much nicer than if I'd had to check the 2 megabyte tarballs into git directly.

joey@kodama:~/src/fbreader> git checkout pristine-tar 
Switched to branch "pristine-tar"
joey@kodama:~/src/fbreader> ls -l
total 104
-rw-r--r-- 1 joey joey 46583 Jan 31 21:26 fbreader_0.8.12.orig.tar.gz.delta
-rw-r--r-- 1 joey joey    40 Jan 31 21:26 fbreader_0.8.12.orig.tar.gz.id
-rw-r--r-- 1 joey joey 45267 Jan 31 21:26 fbreader_0.8.9.orig.tar.gz.delta
-rw-r--r-- 1 joey joey    40 Jan 31 21:26 fbreader_0.8.9.orig.tar.gz.id

Don't forget to push the pristine-tar branch to your server for safekeeping.

joey@kodama:~/src/fbreader> git push origin pristine-tar

Once a tarball's delta is checked in, you can easily and quickly regenerate the original tarball.

joey@kodama:~/src/fbreader> pristine-tar checkout ../fbreader_0.8.12.orig.tar.gz
pristine-tar: successfully generated ../fbreader_0.8.12.orig.tar.gz

Yes, it's really the same file. :-)

joey@kodama:~/src/fbreader> md5sum ~/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz ../fbreader_0.8.12.orig.tar.gz 
8045abe1acc75dbdd220400df541f23f  /home/joey/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz
8045abe1acc75dbdd220400df541f23f  ../fbreader_0.8.12.orig.tar.gz

The above example is from the perspective of a maintainer of a Debian package. But this can also be used by the authors who generate the pristine tarballs in the first place. Check them into git using pristine-tar. Then you can regenerate any tarball you've ever released using just your project's git repository.

joey@kodama:~/src/pristine-tar> pristine-tar commit ../pristine-tar_0.5.tar.gz tags/0.5
pristine-tar: committed pristine-tar_0.5.tar.gz.delta to branch pristine-tar

One word of warning: For pristine-tar to check out the tarball, git needs to be able to check out the tree that you referred to when you committed it in the first place. If that was a tag that you've told git to delete, you're SOL. If it was a branch and the branch has changed in the meantime, that's fine, so long as git can find the original id that is stored in the .tar.gz.id file.

---

I hope that tools like git-import-orig and git-debimport can get support for automatically calling pristine-tar commit when importing tarballs into git, and that tools like git-buildpackage and gitpkg can use it to check out the tarballs.

So today is the last day of the 2008 Synfig January Challenge. It is hopefully the first of many synfig challenges, I hope that the February one will be for a new splash screen for Synfig. My entry is fairly simple and boring compared to the other entries, but it represents one thing about Synfig that I think about a lot: we need more developers! Anyway, here it is: There is nothing special in it, but I put up the source code too. Also, I've been informed that there will be an Open Video Developer meeting on Friday February 1st 2008 at 21:00 UTC on irc.freenode.net in #openvideo. Should be an interesting meeting, sounds like at least Synfig, Blender and Cinelerra people will be there, hopefully many more.

On January 26th 2008, the OCaml community has its first meeting in Europe. There was 5 different talks, including one from me. The meeting was pretty constructive and i think some great things should come out of it. In this post, i will focus on the Debian maintainer point of view. The meeting was organized by me, with the help of Garbriel Kerneis and Vincent Balat. I wish to thank Mme Turgis from ENST/ParisTech who has made possible all this to happen. Introduction: I announce the creation of OCamlCore, a SS2L. It will provide commercial support for OCaml and related products. It will also provide community with some resources (including a GForge, a planet, some SCM repository...) For now, i will open administration to Debian people who wish to help (for root rights) and from the whole community for other task (gforge and general administration). For now, i will choose alone who can administrate and who cannot... This is not a very open position, but this server is also for my company. Xavier Leroy give us a nice talk that has let us see some future direction:

• OCaml 3.11 will have native dynlink
• hope to integrate GHC like type system (GADT: Generalized Algebraic Data Types)
• need to work on parallelism, following different paradigm

But above all, Xavier talked about the fact that there is a lack of manpower at INRIA and invited the community to build tools and other things (including a CPAN like distribution) to make the language more widespread. He also stated that a lot of things will stay in place in the name of backward compatibility. OCsigen Vincent Balat has given us a nice talk about OCsigen, a new framework for programming web application. This program is already in Debian and it is at the root of Debian discussion about moving .cm[ao] into libxxx-ocaml package. This new framework allows to program web application using continuation, which should ease a lot of aspect. It also features static type checking, including static verification of the generated HTML pages. GODI I was impressed to see G. Stolpmann coming to the meeting. Unfortunately, i cannot follow the whole talk, since i have some phone call to make, in order to book the restaurant. From what i have seen, it seems that GODI is growing, in term of manpower. They have some issues with OCaml 3.10, because of camlp4 and some packages. At the end of the conference, he was pushing for a more general use of GODIVA. In particular, it requires to have a very uniform way of building software. It should be the foundation of a build standard for OCaml software. In my humble opinion, i don't agree on this point. Basically, its proposal was based on configure/make all, which is too C style way of doing. It is not bad, but just exclude ocamlbuild enabled software. ocamlbuild Nicolas Pouillard has made an introduction on how to use ocamlbuild. I have discovered how it was working, since i didn't have time to work on this topic. It seems a good thing. I hope to be able to try it at some point. The conclusion was about modifying ocamlbuild to allow the use of multiple plugins. For now, the plugin is a separate file which is compiled first and then loaded, as a special case. Nicolas is looking for a full OCaml way to handle this for multiple plugins. OCaml in Debian I have spoken about different aspect of Debian packaging. After a short introduction and some history about OCaml in Debian, I come to some conclusions/problems:

• we have an early integration, which makes Debian handle a lot of packages, but this is due to a long history
• we still are not able to cope with libraries incompatibilities when rebuilding, we only have addressed ocaml package ABI problem
• the debian package management system is not really compliant with the OCaml way of creating libraries, which is our main problem
• native compilation is broken on 3 arches (Xavier Leroy told us that this should be solved for ARM)
• use of Alioth has made us more efficient to integrate packages
• Debian team are working by step: from time to time we begin to integrate a lot of packages, mostly because of some maintainers wishing to integrate a software with a lot of dependencies

Talking with Xavier give me some additional informations:

• ARM is fixed, it should compile with Debian stable on ARM, he explains that the problem is related to the multi ABI flavor of ARM
• he says that we should not have any problem concerning bytecode stripping of executable, if there is still some we should find the OCaml library that triggers this behavior
• I realize that this behavior can be triggered by ocamlmakefile, that still have a "-custom" option
• he promises me that he will send me a simple test to find custom bytecode application (combination of "file X" and a specific string at the end of the file)

At the end of the presentation, there were some questions. I discover that many people are ignoring the ABI problem with OCaml and its libraries. They seem to discover that it requires regular rebuild of our packages. I also have a discussion about the fact that Debian binary distribution doesn't fit developers need. It seems that developers prefer to have the source of libraries they compile and also the most recent release. But at the same time, people avoid using GODI, which also have the problem of needing to wait for a particular library to be released... After some discussion, I point that some companies prefer to live in a frozen world, which Debian stable can provide. Living in a frozen world helps company developers to have the same environment from the beginning to the end of a project - which can last years. It also help to avoid build environment de-synchronization between company developers. There was also a question about interaction between installed OCaml package and GODI software. I cannot answer it, expect with a "patches are welcome". OCaml on a JVM using OCaml-Java Xavier Clerc explained us how he has achieved running a full OCaml environment on a JVM. This work was pretty impressive, because he was able to compile OCaml top level and provide it as an applet. This is something amazing (and working). He stated also that this should allow to do some binding with java graphical user interface from OCaml. I was pretty busy with a phone call (to a restaurant for the dinner), so i don't have attend the whole conference. Anyway, the project is promising, but it needs to recompile every library using its compiler. I think this is not suited for Debian for now. Workshop The workshop was shorter than it should have been. This is due to accumulated time shift during the day. However, it was pretty interesting, because everybody can talked almost freely. The initial discussion was about the "Unicode situation". This was a question about Unicode in Unison, but there is no real solution about it. For reader information, unison has problem with filename containing UTF-8 char. In particular when syncing two directories which are on two file system with a different encoding on each. Even if the file can be represented on the two file systems, the comparison (between UTF-8 and ISO8859-15) fails. This is because the comparison is a byte to byte comparison. We discuss further the idea of OSR (OCaml standard recommendation) which was briefly discussed in the morning. I think David Teller (who have also done a great part of the IRC retranscription) was very keen on this idea. I invited Nicolas Pouillard to discuss the three following subjects. About camlp4 documentation, Nicolas told people about the he set up. About ocamlfind and ocamlbuild, he went back to the multiple plugin problems. About ocamlbuild and GODI, Gerd, Nicolas and Xavier tried to build a list of what metadata can be shared. This includes list of files to be installed (PLIST in GODI). Concerning the "feedback from the Gallium", Xavier explains that he has done this in the morning (which is true). I think that Xavier implicitly agreed on the fact that if this kind of event happens again, he can do another talk about future of OCaml. Concerning Summer of Code, I just remind that people can write description of Google Summer of Code project in the cocan wiki. Another one remind about Jane St Capital summer of code. Points concerning common interfaces raise the discussion about OSR. The organization of next year events doesn't raise particular interest. I think people would be interested to have one next year, if something comes out of this meeting.

I live in a cooperative living group, and during the fall semester a person who we’d invited to live with us who is a dwarf and relies on a scooter for most of his transportation decided he’d like to move in. Unfortunately, while he can get out of his scooter and come inside by himself, we had no stepless entrances such that he could bring his scooter inside to protect it from the angry Cambridge winter. Mmm, frozen batteries. So, we’re a coop and we maintain the house ourselves—so we decided to build one, of course. A ramp up to the back porch! Nevermind the fact that we need to sink four-foot foundation holes in the ground in January. We got started right away at the beginning of IAP, while people were still trickling back into town from all over the country. First we surveyed out where the posts should be sunk: Then it was time for excavating the holes where concrete would eventually be poured. This involved a power auger of DOOM: It’s advertised as a 2-man tool. Two 200-pound construction workers, that is. We had to put four people on it plus one person with a shovel clearing dirt to make it manageable, and even then it was a pain. There’s a delicate rhythm you have to get into to avoid getting the bit stuck—DOWN. UP. CLEAR. And inevitably there are rocks and roots that have to be dealt with. We lucked out with a fairly warm weekend to do the digging on, but on the first day we still had to deal with a couple inches of frozen ground: There was also some fun stuff involving having to clear away our (frozen) mulch containers and use a concrete cutter on a weird old concrete pathway that used to run through the same area: Next we mixed and poured concrete: And placed hardware in the concrete to hold the posts: Framing: Eventually it became functional, woo: And done! (except for metal handrail): This all took place over the course of about three weeks. And now our scooter-bound housemate can bring his wheels inside! The house still isn’t totally accessible to wheelchairs/scooters, but at least the first floor is. It really brings me pride to see things like this go from start to finish here. We can do it! This guy who is moving in has really influenced my life—he’s really good at making people feel comfortable talking to him, and for me it’s gone from “wow this is awkward, I have no idea what to say” to “talking to a person with different physical abilities and characteristics seems normal”. And that’s made me a better person.

I speculate that most of what we do for Debian squares with what others do for their respective distro. Thus, it should be possible to identify a conceptual workflow applicable to all distros, consolidate individual workflows on a per-package basis, and profit from each other. Jonathan let me have the after-afternoon-coffee slot of the Distro Summit for an impromptu discussion on the various workflows used by distros for packaging. The discussion round was very short-notice and despite the announcement sent to the conference mailing list, only ten people showed up: two people familiar with Fedora, and ( versus ) eight Debianites. Regardless, I think the discussion was success- and fruitful. We were able to identify a one-to-one mapping between the Fedora and Debian workflows, even though we use different techniques:

• both distros separate original software ( orig tarball ) from modifications made to fit the software in with the rest of the distro.
• Fedora keeps the .spec file, which references the original tarball, alongside any patch files in a per-release directory in their CVS tree, e.g. /mdadm/fedora8 and /glibc/rawhide. To obtain a source tree, the contributor checks out the CVS subtree, downloads the tarball according to the .spec file, and merges the two. There is a tool to automate this, obviously. This process is regularly executed to produce source RPMs .
• Debian keeps the original tarball next to a diff.gz file on the mirrors, along with a dsc file which refers to them both. Tools like dget take the URL to the dsc file to download all three, then invoke dpkg-source to unpack the tarball and apply the diff. Individual patch files are either stored in ./debian/patches/ (and applied by the diff), or they don t exist (meaning that all modifications are concatenated in the diff.gz file.

Many Debian package maintainers use version control systems to maintain the ./debian directory, and if patch files are stored in ./debian/patches/, then Debian and Fedora both store patch files in a version control repository, which seems awful. Just as I am only one of many who are experimenting with VCS-based workflows for Debian packaging, the Fedora people are also considering the use of version control for packaging. Unlike Fedora, who seem to try to standardise on bzr, I try to cater for the plethora of version control systems in use in Debian, anticipating the impossibility of standardising/converging on a single tool across the entire project. It seems that our two projects are both at the start of a new phase in packaging, a paradigm shift . What better time could there be for us to listen to each other and come up with a workflow that works for both projects? My suggestion currently centres around a common repository for each package across all (participating) distros, and feature branches. Specifically, given an upstream source tree, modifications made during packaging for a given distro fall into four categories:

• upstream changes, such as bug fixes in the original code, or simple things like manpage typos.
• (Linux) distro stuff, such as init.d scripts or Linux-ifications, which upstream doesn t care about or doesn t want.
• .deb/.rpm-specific changes, like the ./debian directory or the .spec file.
• distro-specific modifications, like policy compliance and the like.

Given a version control system with sufficient branching support, I imagine having different namespaces for branches: upstream-patches/*, distro/*, rpm/* or debian/*. Now, when building the Debian package, I d apply upstream-patches/*, distro/*, deb/* and debian/* in order, while my colleague from the Fedora project would apply upstream-patches/*, distro/*, rpm/* and fedora/*, before calling the build tools and uploading the package. There are surely problems to be overcome. Pascal Hakim mentioned patch dependencies, and I can t necessarily say with a clear conscience that my workflow isn t too complicated to be unleashed into the public yet. But if we find a conceptual workflow applicable to more than one distro, it should be possible to implement a higher-level tool to implement it. Also, the above is basically patch maintenance, not the entire workflow. Bug tracking system integration is going to play a role, as well as other aspects of daily distro packaging. I ll leave those for future time. For me, this is the start of a potentially fruitful cooperation and I hope that interested parties from other distros jump on. For now, I suggest my mailing list for discussion. You can also find some links on the Debian wiki.

Tomorrow (January 28th), I'll be in Munich for this: http://www.mobile-monday.de/web/guest/android Unfortunately, the event filled up super fast and I barely managed to squeeze in, so there are probably no spaces left. Still, if anyone would like to meet up afterwards, send me an email soonish. If you managed to get in, and would like to see a demo of Hecl, let me know, because I'd like to have the chance to show that off some too! Hopefully it will be a valuable experience. Android is a pretty convincing system in many ways, but of course has yet to fully come into contact with reality, so I'm curious to meet some of the people involved and hear about it from them. I really hope it doesn't end up being a rehash of information that's available on the web, as it's a two hour drive from Innsbruck.

As during previous keysigning events, such as DebConf7 and DebConf6, I turned up to the LCA 2008 keysigning event with my ID card issued by the Transnational Republic. Previously, this act has caused people to to get rather upset. I have explained my motivation and rationale in response to the thread; yet, my reputation as keysigning subverter precedes me. I maintain that I am not subverting the web of trust in any way. I conduct this experiment mainly out of interest, and to sensibilise participants of the web of trust. Even though I stated previously that I would no longer attend keysigning events, I couldn t pass up this opportunity on the other side of the planet. Fifty-seven people exchanged data and glances at ID cards with me. In total, 9 people asked about this ID card, mostly out of curiosity, but only one person flat out refused to sign my key. This leaves 47 who apparently accepted it. If you disagree with my approach, please do not sign my keys, 0x330c4a75 and 0x667c7088 (but do read my arguments, please). I will not import signatures I receive for a while, so if you have already sent your signatures by the time you read this, send me a note and I ll delete them. Keep in mind that you are not authenticating the ID. You are authenticating my identity. And unless we ve interacted or you otherwise know who I am and that I am the same person as is using this key for the work through which you know me, you should not sign my key. Also note that I continue to stick to my policy and will only sign keys of people that I know . Thus, if you want my signature and we have not previously interacted, you have four more days until the conference is over. Update: a couple of people replied, including Paul Wayper. I ve since had an interesting discussion with him but still want to address two points in his post here: The ID presented is not fake , it is simply issued by an entity that is not considered official . Its data are all correct, which I am happy to prove to anyone who cares. Second: if the web of trust were to die if everyone did what I was doing, would it live forever and improve continuously if we continue such mass signings based entirely on IDs? Noone can know how to verify IDs from all countries that issue them, introducing fakes is trivial (as my experiment and this message hopefully show). I think it s a case of quality versus quantity. Whether you buy my point that you need to ask yourself what you are actually proving to the web of trust with your signature (and sign (or not) accordingly), or whether you are signing an identity (what is identity?), I would suggest to concentrate more on educating people. At the keysigning at DebConf7 in Edinburgh, we split people into smaller groups around well-connected keys. Within each group, prior to the keysigning, experienced key owners would take a short time to talk about the process and explain its goals. Specifically, they would make it explicit that there is no obligation to sign ones key, similar to what Jonathan said in this message prior to the LCA keysigning. My experiment yielded a small discussion on the LCA chat mailing list, which is worth a read if you haven t seen it yet.

I have uploaded a new version of DebTorrent to experimental and to my personal repository. This new version implements the unique piece numbers, which has been planned for quite some time now. Well, it's finally here. To summarize, unique piece numbers keep torrent's alive longer, by assigning files unique piece numbers that never get reused in that torrent. New files get new piece numbers added to the end, but peers in the old torrent can still share most of the old files with peers in the new torrent (in fact, it's the same torrent, but old and new peers have different ideas about what it contains). The creation of torrents from Packages files has also changed, as now 2 torrents are created, one for whatever arch the Packages file was for, and one for the Architecture:all files. Since the Arch:all files are the same for all architectures, this also allows for more sharing of common files between peers on different architectures. This change required a change in the cache directories, which is described in more detail in the NEWS file, but is handled almost automatically. The only thing to do is the make sure to do an apt-get update after upgrading so that the torrents can be restarted. There was also some changes in the statistics reporting. In the client, the uploaded and downloaded statistics will now persist over restarts so that you can see how much you've done over a longer period. The tracker status page also got an update, and now shows the total uploaded and downloaded bytes for each torrent, as well as some more descriptive names for some of the torrents. Due to the large changes in this release, I opted for uploading to experimental (and my repository) for now, so that it can be tested a bit. Please do test it, and let me know of any bugs, problems or concerns that you may have. Here is the changelog:

• Add support for unique piece numbers
  • increases duration of oft-updated torrents so that more peers can participate
  • currently supported only by debian testing and unstable
  • see http://wiki.debian.org/DebTorrent/UniquePieces for more info
• Switch to using 2 torrents per Packages file: one for architecture- specific files, and one for architecture-independent files
  • also added a new script splitcachefor_all to ease the upgrade
• Use python-debian for all reading of RFC 822 type files
  • also requires python-apt
• Add torrent names to the tracker display
• Make the download/upload statistics persist over restarts
• Report more and better statistics on the tracker's info page

I filed an HP support request on 22 January. On 23 January, I received the following mail: Your support request regarding,HP LaserJet 3052 All-In-One E-Mail Support, was received 1/22/2008, 9:41:14 AM. Your unique ID is 532458. A support engineer will be getting back to you, via email, within the next business day to address your issue. We appreciate your patience. By 28 January I had not heard back from them. Why do they even bother to send such auto-replies?