madduck's droppings

I just sent this to debian-devel-announce. Hopefully it will be a success!

Dear fellow developers and contributors,

My publisher, Open Source Press, and I were pondering ways to help the F/OSS community (and Debian in particular) over a beer the other day, and the following idea is the result:

We are announcing a bug squashing period, starting now, and ending 14 Dec 2005, 11:59 CET. Squashing a bug gets you a certain number of points (depending mostly on triviality and severity). At the end of the three weeks, the 25 bug squashers with the highest score shall receive a copy of my book, The Debian System, donated by the publisher. If this turns out to be a success, we'll lather-rinse-repeat sometime soon.

Bug squashing is to be done according to the rules listed on the wiki. In particular, everyone is expected to make proper use of usertags to communicate to others that s/he is working on a particular bug. If you are working on a bug, you are expected to send status updates to the bug report at least once in four days, or someone else may announce the intent to lock the bug and take it over after 24 hours. Fixing a bug also involves augmenting the bug report with any relevant information as you go along, and testing the fix with which you came up.

Points will be given to those whose contributions fix a bug. A bug will be considered fixed if a patch addressing the problem has been sent to the BTS and the package's maintainer has not vetoed the patch within five days. Please do not actually close bugs in the BTS (unless you really know what you are doing). Points will only be awarded to patches for bugs which have been reported before this announcement (but you are, of course, welcome to fix any bug -- if it's obvious you aren't trying to cheat and you are otherwise very actively fixing bugs, you may even get points for those too).

After submitting a patch to the BTS, please send a short note to book-bsp ät pobox.madduck.net with the bug number in the subject, and from the email address you used to interact with the BTS. In the message, list any contributors who have helped with the bug, as well as an approximation of the time each of you spent on fixing this bug. Also, document how you have tested your patch.

The amount of points to be awarded depends on the severity of the bug report, as well as the triviality of the patch you came up with. Put differently: while a one-line patch for a wishlist bug might get you 1 point, I could award 100 points for a clean yet elaborate patch to an important bug. Bonus points can be given if you provide reasonable proof of thorough testing of your fix (you could use test-driven development techniques..., also see here), ideally by a third party. Please be aware that bugs fixed by the reporter him/herself will be especially scrutinised.

Anyway, there are no strict rules for the amount of points a patch will get you. In fact, I reserve the right to announce the scores only after the end of the bug squashing period, and I will not answer questions about scores, or address complaints from people who think they have not received enough. However, I shall act as objectively as possible, fair, and honest; for that, I give you my word. I realise this is sketchy and if you don't trust me on this, it's your choice not to participate -- there is no point to argue at this stage. If you have a better suggestion, I would be interested in trying it the next time 'round. Maybe we can establish a good scoring system for the future, but at the moment, no such system exists.

If you have any questions or suggestions, please do not hesitate to speak up (Reply-To set). Do note, however, that my tendonitis forces me to take things slow. For this reason, I would like to apologise in advance should the evaluation of all your contributions extend into the new year.

Thanks to Markus Wirtz of Open Source Press for supporting this idea, and to Steve Langasek and Frank Lichtenheld for their advice.

Steinar, five years of mutt and not a single message sent? :_) And of course I know you meant the index-y key. Spiffy feature, but not what I want/need. For one, it's missing counts of read/total mail.

Mh, noone seemed to notice the smiley in my initial post.

After many painful attempts to organise a security meeting since Debconf5, locking the important players into a room until Debian security issues would all be addressed and solved, it seems that I did succeed at getting the ball rolling. Wiggy's suggestion to make the meeting happen at Oldenburg and thus saving time for Joey and enabling him to attend was fruitful: the Oldenburg Security Summit took place today. Unfortunately, I could not attend, but then I am not an active security contributor these days anyway.

Several members of the testing security and Ubuntu security team met with Joey, Branden, and several other interested parties and discussed a number of pressing issues. Minutes will be made available soon. Based on this meeting, we can probably expect followups on IRC (#debian-security/irc.oftc.net), and hopefully, Debian will soon be in control of the security situation again -- better than ever before thanks to a possible integration of the various teams.

Uh, but I am not here to speculate. Nevertheless, it's good to see some first steps in the right direction, which right now seems to be the consolidation of the existing security team, and the formalisation of the processes to make it easier for others to contribute on non-embargoed issues.

In the mean time, the Neptun project, as well as the IT support group of the Department of Information Technology and Electrical Engineering, both at the ETH Zurich, have announced their financial support of at least 5,000 CHF (~ 2750€), very possibly twice that or even more, to cover for travel expenses for the attendees of the security summit, and possible future meetings. As soon as the formalities are taken care of, I shall make an official announcement about the funding. Cool! Thanks a lot, ETH!

Alex,

I thought you admitted yourself that blogging is not the right way to complain about things happening elsewhere. So what was this all about?

The email I sent to debian-user was not a subtle publicity ploy, but a stupid error on my part. If you sit back and think outside your box for a second, you'll see how such a post actually hurts my reputation and casts bad publicity upon my book, instead of promoting it further. Had you been in my flat at the time buffy told me about a new mail from me to debian-user, you could have witnessed the purposeful destruction of neurons as I was banging my head against the table, wall, and whatever else was solid and hard and close by at the time.

After all, my post could be read by some (namely the authors of the Debian Bible) as some passive-aggressive slap in their faces, which I absolutely did not intend. Please, David, Jaldhar, and Mako, accept my apology for this incident.

My message was (meant to go privately) to a reviewer of the Debian Bible, not because I wanted to get him to buy my book instead (he obviously already owns the bible), but rather to let him know that I thought my book matched the description of one of the two books he was looking for, namely the one about Debian and just Debian. Of course there's self-interest involved, and of course I want to sell more copies of my book, but that's not because I am low on cash, but rather because I want my dinner with Peter Gabriel (see the last FAQ).

Had I been low on cash, then I wouldn't have sold 50 copies of the book at debconf with zero profit. And I wouldn't have mailed almost two dozen copies for free to Debian contributors in developing countries, or would not ship CD sets to those in need just like that. And in case you care: my publisher and I donate one Euro for every sold book to the Debian project. That's about 15% of what I make off each book. The other 85% are going to a separate stash with "my Debian funds" written on it, for later use towards promoting and/or helping Debian. Before you ask: this is my personal thing and I don't know exactly how I will use these funds yet. Certainly not, however, to become rich.

I know some people got annoyed over my seemingly aggressive market development practices following the release of my book. Aggressive marketing was not my intention, I hate it just as much as you do. I very much appreciated that some took their time to tell me about their concerns in private, and it's largely thanks to them that I realised this. My "marketing" was driven by pure enthusiasm rather than the wicked business person I couldn't be anyway. And even though it wasn't easy to suppress my excitement and pride about the work of ten months finally being "out there", I believe I successfully scaled down and kept quiet(er) about it after LinuxTag, only mentioning my work when directly relevant or called for.

Anyway, thank you for the apology and the 0,03 €. Let me know if more piles up. I'll put it to my Swiss Debian account then. And while you're at it, you could also transfer the money you owe me since the sale of my T-shirts at the LOTS.

Erich, I don't see copy on write branches working conveniently for you in the use-case you describe. Think about it: let's say /etc/services is unchanged across all machines, so when you add 12345/tcp myport to the master, you would expect the physical file in the checkout on the other machines to just change automatically, without a checkout. What you want is for /etc/services to be a cross-network-symlink to the master file, until you write to it, at which point is should become a regular file under version control. I don't know of any way to support this.

In your situation, you have two solutions to look at:

1. configure the machines to run a regular replay/merge/whatever with cron. you would need some sort of additional intelligence to deal with conflicts (e.g. reverse the merge and send mail) and handle restarting of daemons.
2. configure the master archive with hooks that push any changes to the other machines. This requires you to keep track of all machines from the master archive, and it sucks because of all the other reasons that push approaches suck.

I hope I am making sense, and sorry for the "it's not possible". I'd love to be shown wrong.

I was told my previous hackergotchi on planet was stolen from Windoze XP. Thus I felt obliged to change it. It's not like I want to endorse sucky products. This one's thanks to Kitschcity.

Update: azeem convinced me to stop being childish and put a real picture up. So I did.

Mr. Zugschlus:

whois: /usr/bin/mkpasswd

Who would have thought that blogs have such an incredibly rapid turnaround? It's a speed record. Even faster than the speed of light on planet!

Thanks Clint, you really made my day just a little painless.

(... he says, kneeling in front of the keyboard on kneepads and finishing a paper due tomorrow...)

Oh, wouldn't it be great if zsh could ignore /\.(aux|dvi|ps|pdf|bbl|toc|lo[tfg])$/ when collecting suggestions to complete the first argument following /^vim?/ ? Hey, zsh god, is this how you want me to beg?

aj, you forgot the vegetables.

Wow, after 2:15 hours of continuous IRC hacking, my brain is fried and at least 3-4 people followed the introduction (thanks to bignose for the editing) to Manoj's packaging art I gave in #pkg-zope. I think it was successful, but there are lessons to be learnt:

• Prepare a simple example. I planned to do so, but today was just too bad a day and I did not get to it.
• Do your own hacking somewhere where people can see it, e.g. on alioth (if it isn't down), in a publicly readable directory. Consider typescript.
• Have two people, or more. Manoj helped out a lot, but he wasn't prepared, so I felt sorry for putting him on the spot. Two people are needed when a problem arises: then one can fix it while the other fields peripheral questions.
• Have the log appear live on the web somewhere, so late-joiners can catch up.
• Grow an extra 30 fingers. Learn Dvorak. Man, my fingers ache.

What is good though is that as the demonstrator, you have to type everything twice -- into the shell and into the IRC window. That gives the people following the demo twice as much time to try things themselves.

I think we should have more demos of this kind in our community.

Update: I had to give up the wiki on my server and the Debian admins have not yet had the time to incorporate the pages into the Debian wiki proper.

Anyway, I suggest against the use of arch, which is a bit too cumbersome. Have a look at some of the other VCS to do what you want. For instance, I just published a typescript from a recent presentation on using modern VCS for Debian packaging, in which I use git for the same workflow.

For a couple of months, I've had some ideas floating through my head about how to improve the upload process for Debian and address the following problems:

• require developers to run lintian, linda, piuparts against their packages prior to an upload.
• allow for the upload to pull from a version control system directly.
• require developers to build the package locally but do not require them to upload potentially large packages over slow uplinks.
• add the ability for certain packages to require more than a single DD signature to be accepted for upload.
• possibly others...

Here's the scheme I am envisioning, which has its shortcomings, but which seems like an interesting approach worth more thought, at least IMHO:

• A developer team maintains a package in a repository. When it's time to make a release, one developer checks out the package. Alternatively, conventional (non-versioned) packaging may be done (urks!).
• S/he builds it, tests it, and runs the various checkers against the result. Each checker outputs a certificate.
• When the developer deems the package ready, s/he sends a control email to some dak script, with the following info:
  • the hash sums of the source package files
  • the certificates of all the checkers s/he ran against the package
  • information on how to obtain the source package (svn co, baz get, wget, etc.) (think: plugin architecture)
  • his/her digital signature covering all these data
• On the side of dak, the script would
  • check whether the signature was made by a DD.
  • check whether the DD is a member of the maintainer team. If not, the script may impose additional requirements (more below)
  • verify the presence of the various required certificates (configurable per project, maybe)
  • check whether a single DDs signature + certificates are enough; some critical packages like login or similar may require more DDs to check the package and sign it off.
  • if there are enough signatures and certificates according to the package's policy, the dak script would go and obtain the source package from the source listed (e.g. a HEAD-checkout from the etch branch, or a simple wget)
  • if from a repository, it would build the source package according to a standard method (to be defined).
  • it then verifies the hash sums on the source package files. Here there's an expected problem with stuff like dates in the diff.gz and tar.gz files, which would cause the hashsums to be different. Maybe instead have the dak script pull the source package off at the point in time the signature was made?
  • if that passes, send the source package off to the buildds.

I am not sure how to do certificates by tools like linda and lintian. I don't see an obvious cryptographic solution to those challenges. In fact, it seems impossible without DRM (yeah, let's DRM lintian and linda & Co.!). But I suppose the question should be: build a system that no DD can crack (why?), or build one that's easy to use so that noone would think about going out of his/her way to subvert it? I tend towards the second... we can always tar-and-feather those that actively subvert the process.

This is all an initial braindump and I am looking forward for your input (on IRC, preferably).

PS: previously I would have sent this off to -devel. Now that I blog, this seems a better place. At least it won't drag with it endless discussions. I really just want to get the idea out right now since I don't have much time to do more anyway.

Manoj (thanks to Jaldhar, I finally know how to pronounce your name... it would be spelt "Manosch" in German and bears resemblance to the name of one of the greater German child book authors)... uh, so where was I?

Oh yeah, Manoj has a really interesting way to manage packages with GNU arch, which I have started to adopt for my packages. The approach gets rid of things like dpatch (yes!) and simply manages additional features and debianisation in separate branches. Read the last paragraph of this entry if you can't be bothered with the rest.

Even though bazaar still has its rough edges, it's a pleasure to work with the guys making it possible, and bugs have quick turnaround times. This is one of the reasons why I chose to adopt Manoj's method together with bazaar for pkg-zope as well as pkg-mdadm. I have started to document the process on the pkg-zope wiki.

The only real drawback of Manoj's method is that it has a steep learning curve. Thus, Mario (the other mdadm maintainer) and I had the idea to hold a live session on IRC in which to demonstrate the use of arch and allow people to ask questions.

We are meeting for this live demonstration and Q&A session tomorrow, Thursday 11 August 2005, at 19:00 hours GMT in the #pkg-zope channel on irc.debian.org, and you are cordially invited to join. I'll also log the session and make it available online afterwards. Hope to see you there.

I found the first Debian couple. Finally. Names anonymised to protect the innocent, and crazily abridged:

21:20 < reverend> Family and friends, we welcome you today to witness the cross
                  signing of Jane's and Joe's keys.
21:20 < reverend> Keysigning is a promise, made in the hearts of two people who know
                  each other, which takes some computation to fulfill.
21:20 < reverend> Within the web of trust, keysigning encompasses all of the net's
                  most important relationships.
21:20 < reverend> If anyone present can show just cause as to why these keys should
                  may or should
21:20 < reverend> not be legally cryptographically together, you should now declare
                  it, or
21:20 < reverend> hereafter hold your peace.
21:20 < reverend> Joe, Did you sign Jane's key, so that in good times and in
                  bad, your certification shall tell anybody of your trust in her key?
21:21 < reverend> Jane, did you sign Joe's key, so that in good times and in
                  bad, your certification shall tell anybody of your trust in her key?
21:22 < reverend> It is my Pleasure to pronounce your keys signed and you two
                  cryptographically married.
21:22 < reverend> Joe, you may kiss the bride! :)
21:22  * Joe kisses Jane _once_!
21:23  * someone throws some rice at the happy pair!
21:23  * Jane dances happily round Joe
21:23 < madduck> Ah, look at how they wander off to a shared future.

Blogging lesson three: it can be a major source of friction. Oh man!

Stargirl and I single-handedly decided that debconf6 will host the showdown of the first Debian assassins game ever. The rules of the game are quite simple: Everyone gets a target person assigned, randomly and secretly. Your task is to "assassinate" this person according to a set of rules. No violence involved, this is just the name of the game. If you "killed" your target, s/he has to disclose his/her target, which then becomes your next goal. In the end, the one with the largest number of "kills" wins.

The process of "assassination" is governed by a few rules:

• you must touch/brush/pet/whack your target with a pair of (clean) socks on the head.
• no other participant of the of the game may witness this act. If someone does, your mission failed. You must wait 24 hours before you can retry (but now your target knows whom to watch out for).
• you are not allowed to "attack" in the person's own room or house.
• bathrooms are off-limit.
• never talk about the game to anyone.

So we need to work on a proper crypto protocol to have this run over the Internet. Extra challenge: no trusted single party must be allowed to coordinate (as used to be the case when we played this in college). I bet Bruce Schneier will love to talk about this.

Anyway, let this resonate and see what comes up. I think we should have the game going soon for added surprises. So, about the crypto... any ideas? My Applied Cryptography book is at the office...

Hanna refers me to the Assassin's Guild pages, but I am not sure whether we shouldn't just keep it simple.

I am not sure, but if I hear "pop the trunk" the next time, I might implode and turn into a large black hole.

If you really think that Launchpad strives to take control over information, I think you are wrong. It exists precisely because Savannah, GForge, Sourceforge, insert-your-favourite-here suck --- or rather: because they do not meet today's needs anymore. More importantly, they are software that everyone can install and run, so you are not forced to use a single centralised instance. Thus, I think your comparison with Google and Microsoft falls short.

Nevertheless, it is possible that Canonical's Launchpad will become a central repository of information used by all kinds of distributions, simply because Debian and Ubuntu have enough inertia and cooperation. If Canonical were to choose to disallow raw access to their databases, I think they'd make a great mistake, and I believe they know that. Of course, there is always the problem with security-related stuff in the bugs database... but under certain conditions, access to that should even be possible.

The social dynamics at this year's debconf actually led me to install a blog. No idea whether I am the type of person to blog, but we'll see.

I have another 3 hours left here at HUT and am surprisingly not looking forward to finally getting back home (which is usually the case when I have been gone for a while). It was a blast, and that's all I shall say. If you want emotions, see the mailing list or planet (e.g. here and there).

I want to especially thank the organisers and all volunteers who have done an incredible job, and whom I felt not to have received enough recognition --- not because people did not want to recognise it, but we were all just too busy to try to fit all the things to do here into the 24 hours of daylight at HUT.

I am also grateful to everyone who has provided me with constructive feedback to my projects, my plans, my (online) personality (you know who you are... please keep it coming!), and many other topics. Having had a chance to get to know you all will probably completely change the way I think about the Debian community and work with and for the project. I think that's a good thing.

Goodbye to all. And thanks again for a fascinating week.