For Debian s birthday, Francesca Ciceri of the Debian Publicity team suggested that developers blog about their first experiences with Debian . I found this a good idea so I m going to share my own early experience. It s quite different from what happens nowadays Before speaking of my early Debian experience, I have to set some context. In my youth, I have always been a Windows user and a fan of Bill Gates. That is until I got Internet at home at that point, I got involved in Usenet and made some friends there. One of those made me discover Perl and it has been somewhat of a revelation for me who had only been programming in Visual Basic, Delphi or ObjectPal. Later the same friend explained me that Perl was working much better on Linux and that Debian Linux installs it by default so I should try this one. I had no idea of what Linux was, but given how I loved Perl, I was eager to try his advice. So I got myself a Tri-Linux CD with Debian/RedHat/Slackware on it and started the installation process (which involved preparing boot floppies). But I did not manage to get the graphical interface working despite lots of fiddling with Xfree86 s configuration file. So I ended up installing RedHat and used it for a few months. But since many of the smart guys in my Usenet community were Debian users, I persisted and finally managed to get it to work! After a few months of usage, I was amazed at everything that was available for free and I wanted to give back. I filed my first bug report in July 1998, I created my first Debian packages in August 1998 and I got accepted as an official Debian developer in September 1998 (after a quick chat over the phone with Martin Schulze or James Troup I never understood the name of my interlocutor on the phone and I was so embarassed to have to use my rusty English over the phone that I never asked). That s right, it took me less than 3 months to become a Debian developer (I was 19 years old back then). I learned a lot during those months by reading and interacting with other Debian developers. Many of those went away from Debian in the mean time but some of them are still involved (Joey Hess, Manoj Srivastava, Ian Jackson, Martin Schulze, Steve McIntyre, Bdale Garbee, Adam Heath, John Goerzen, Marco D Itri, Phil Hands, Lars Wirzenius, Santiago Vila, Matthias Klose, Dan Jacobowitz, Michael Meskes, ). My initial Debian work was centered around Perl: I adopted dpkg-ftp (the FTP method for dselect) because it was written in Perl and had lots of outstanding bug reports. But I also got involved in more generic Quality Assurance work and tried to organize the nascent QA team. It was all really a lot of fun, I could take initiatives and it was clear to me that my work was appreciated. I don t know if you find this story interesting but I had some fun time digging through archives to find out the precise dates if you want to learn more about what I did over the following years, I maintain a webpage for this purpose.

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

With Debian s 19th anniversary approaching, I thought it would be nice to look back at dpkg s history. After all, it s one of the key components of any Debian system. The figures in this article are all based on dpkg s git repository (as of today, commit 9a06920). While the git repository doesn t have all the history, we tried to integrate as much as possible when we created it in 2007. We have data going back to April 1996 In this period between April 1996 and August 2012:

• 146 persons contributed to dpkg (result of git log --pretty='%aN' sort -u wc -l)
• 6948 commits have been made (result of git log --oneline wc -l)
• 3133612 lines have been written/modified (result of git log --stat perl -ne 'END print $c $c += $1 if /(\d+) insertions/;')

Currently the dpkg source tree contains 28303 lines of C, 14956 lines of Perl and 6984 lines of shell (figures generated by David A. Wheeler s SLOCCount ) and is translated in 40 languages (but very few languages managed to translate everything, with all the manual pages there are 3997 strings to translate). The top 5 contributors of all times (in number of commits) is the following (result of git log --pretty='%aN' sort uniq -c sort -k1 -n -r head -n 5):

1. Guillem Jover with 2663 commits
2. Rapha l Hertzog with 993 commits
3. Wichert Akkerman with 682 commits
4. Christian Perrier with 368 commits
5. Adam Heath with 342 commits

I would like to point out that those statistics are not entirely representative as people like Ian Jackson (the original author of dpkg s C reimplementation) or Scott James Remnant were important contributors in parts of the history that were recreated by importing tarballs. Each tarball counts for a single commit but usually bundles much more than one change. Also each contributor has its own habits in terms of crafting a work in multiple commits. Last but not least, I have generated this 3 minutes gource visualization of dpkg git s history (I used Planet s head pictures for dpkg maintainers where I could find it). <iframe allowfullscreen="allowfullscreen" frameborder="0" height="281" src="http://www.youtube.com/embed/1x9-Etj1Ew4?fs=1&amp;feature=oembed" width="500"></iframe> Watching this video made me realize that I have been contributing to dpkg for 5 years already. I m looking forward to the next 5 years And what about you? You could be the 147th contributor see this wiki page to learn more about the team and to start contributing.

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

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...

Some people may have noticed that a thread has recently started about Xen on debian-devel. To sum up the whole story, here it is. Guido Trotter and myself asked Adam Heath, the current official maintainer of Xen, if it was possible to help him (bug #342249) to package Xen 3.
He did not answer to our messages, as he seems to be MIA, so we started with Jeremy Bouse, Ralph Passgang and Yvette Chanco to work and we created a project on Alioth in order to package the latest release. We started our development from the package Ralph made previously. We don't know really why, but Bastian Blank, from the Debian kernel team, uploaded his own package of Xen 3, ignoring our request to work on our side, arguing that this was the work of kernel team to maintain Xen. It seems that actually, the kernel team only pretend to maintain the Dom0 and DomU kernel images, probably as soon as Xen in included in the vanilla kernel, and that Bastian took the decision alone to maintain the hypervizor and userspace tools. Today, we have functionnal and splitted packages of Xen 3, available on the Subversion repository. I made Xen packages with the latest development version of our packages and the Xen testing version. They are available from:

deb http://naquadah.org/~jd/debian/xen stable main

Official backports will be uploaded to backports.org as soon as we will have uploaded a version to sid. But for now, we have to cancel or bypass the upload Bastian made...

Over the past months we've been working on a big change in the debian installer, removing base-config from the installation process. Doing this has required a great many changes, some of them user-visible. The installer now configures the timezone, users and passwords, and apt all in the first stage instead of after rebooting. Some preseed values have been removed or changed, including base-config/early_command and base-config/late_command. The biggest change of all, the the hardest to get working, has been moving of the selection of tasks and the installation of all packages into the first stage of the installer. Now tasksel pops up a debconf question that looks like any other question d-i asks, and the installation of packages is hidden behind a nice clean progress bar, and if any packages use debconf to ask questions, d-i will display those questions using its frontend too. I'd include a screenshot, but really, it's just another progress bar, how boring is that? By the way, if you maintain a debian package and it prompts without using debconf (when debconf is available), then your package will obviously break this, and it's well past time to fix it. I think that all the packages d-i installs do use debconf except for possibly a few like libc during upgrades. Upgrades are theoretically possible at this step for any packages debootstrap installs, so those will need to be fixed too. This has been a long, long time coming. Some milestones include:

• 1998: Wichert Akkerman and others do the design of debconf, and first draft of its specification. Without debconf, none of this would be possible.
• 1999: At linuxworld, I see Stormix's Debian-based install. I remember discussing with them about how debconf could be used to clean up the install process. I don't remember what kind of hack they used to avoid the long dpkg log interspersed with the occsional question that a Debian install involved back then.
• 1999: I begin writing the debconf program. And promoting its use.
• 2000: Randolph Chung begins writing cdebconf; d-i begins.
• 2000: Randolph writes the passthrough frontend for debconf. At the time this was expected to be used by tools like aptitude (deity?) to integrate debconf into their GUIs, but it mostly just rotted for a long time unused. Looking back this was a contribution of unexpected significance.
• 2001: I visit Progeny, they show me their implementation of a progress bar running over a Debian installation. It's a special-purpose hack, but it works.
• 2001: debconf enters Debian policy
• 2003: debconf becomes the policy-accepted standard way to do installation prompting
• 2003: Adam Heath adds --status-fd to dpkg.
• 2005 (Jan): Matt Zimmerman dusts of the passthrough frontend and makes it usable to pass debconf questions from debconf running in a chroot up to cdebconf running in d-i.
• 2005 (Jan): Michael Vogt makes apt support status fds too.
• 2005 (Fall): Ubuntu pulls most of the above peices together and fixes some bugs, gets a progress bar running over apt with debconf passthrough.
• 2005 (Dec): Colin Watson and I develop debconf-apt-progress, rest of the pieces fall into place for using this stuff in Debian.

So yeah, this has been in er, progress for 8 years, and at least three Debian derived distributions have come up with thier own approaches in between with only the last one being quite similar to the end result, and the other two being rather dead. I don't know whether this is a study in how Debian is slow, or a study in how we do eventually come up with infrastructure that is done right and ends up being used by everyone. Or both.

Artist: Mr. Garrison Lyrics
Song: Merry Fucking Christmas Lyrics
Mr. Garrison: I heard there is no Christmas
In the silly Middle East
No trees, no snow, no Santa Claus
They have different religious beliefs They believe in Muhammad
And not in our holiday
And so every December
I go to the Middle East and say… “Hey there Mr. Muslim
Merry fucking Christmas
Put down that book the Koran
And hear some holiday wishes. In case you haven’t noticed
It’s Jesus’s birthday.
So get off your heathen Muslim ass
and fucking celebrate. There is no holiday season in India I’ve heard
They don’t hang up their stockings
And that is just absurd! They’ve never read a Christmas story.
They don’t know what Rudolph is about
And that is why in December
I’ll go to India and shout… Hey there Mr. Hinduist
Merry fucking Christmas
Drink eggnog and eat some beef
And pass it to the missus. In case you haven’t noticed
It’s Jesus’s birthday
So get off your heathen Hindu ass
and fucking celebrate! Now I heard that in Japan
Everyone just lives in sin
They pray to several gods
And put needles in their skin. On December 25th
All they do is eat a cake
And that is why I go to Japan
And walk around and say… Hey there Mr. Shintoist
Merry fucking Christmas
God is going to kick your ass
You infidelic pagan scum. In case you haven’t noticed
There’s festive things to do
So lets all rejoice for Jesus
And Merry fucking Christmas to you. On Christmas day I travel round the world and say,
Taoists, Krishnas, Buddhists, and all you atheists too,
Merry Fucking Christmas, To You! (Clapping) Thank you Mr. hat

Your results:
You are Superman

Superman 75% Spider-Man 65% Green Lantern 55% Iron Man 45% Robin 40% Supergirl 40% Catwoman 35% The Flash 30% Batman 30% Wonder Woman 25% Hulk 20%

You are mild-mannered, good, strong and you love to help others.

Click here to take the “Which Superhero are you?” quiz…