The aim of Debian is to integrate software produced by other projects to create a complete operating system based on free software. In recent years, the project has faced increasingly delayed and unpredictable releases. Most notably, the release process of Debian 3.1 was characterized by major delays. Initially announced for December 1, 2003, the software was finally released in June 2005: a delay of one and a half years. Since then, the project has made a number of improvements to its release process.

Version	Date	Months
1.1	1996-06-17
1.2	1996-12-12	6
1.3	1997-06-02	6
2.0	1998-07-24	14
2.1	1999-03-09	7
2.2	2000-08-14	17
3.0	2002-07-19	23
3.1	2005-06-06	35

Past Problems

• Release management was not very organized and release updates were posted only infrequently. Because of this and the lack of a roadmap, freezes were often announced out of the blue.
• Due to the unorganized nature of the release, several new and unexpected blockers were found during the release process, leading to delays.
• The unexpected delays meant that software was frozen for a long time, in the case of Debian 3.1 for over a year. When this release was finally published, many components were already out of date and would often not meet user demands.
• The fact that Debian has experienced significant delays with several of its recent releases has led to problems with the image of the project. There is a perception that Debian is slow and cannot meet deadlines. This is also associated with frustration in the developer and user community.

Solutions

• The project has implemented better release management structures. In particular, Debian moved from a single release manager to a team during the 3.1 release cycle. The release is now handled by two release managers with the help of several release assistants.
• A release date for the next release was set well in advance and there is more planning.
• Release announcements are sent more frequently and various information sources have been implemented through which developers can stay informed about the release status.
• Release targets have been defined better and there is a distinction between blockers and goals. Only blockers hold up the release whereas goals can be postponed for a future release. For example, the XFree86 to X.org transition and the integration of AMD64 support were blockers, while LSB 3.1 compatibility and SE Linux support were only goals for Debian 4.0.
• The release team has shifted the responsibility of achieving targets to specific developers and teams. There are also better criteria now defining these responsibilities. For example, criteria have been published that architectures need to fulfil for inclusion in Debian 4.0 and there is a page indicating the status of each architecture.
• The release team is increasingly giving encouragement to developers to help out with software packages and bugs which normally do not fall into their domain.
• A staged freeze has been implemented according to which software is frozen in stages according to its importance. The toolchain and base system are frozen earlier than the majority of package. The majority of software is now frozen when most blockers have been resolved.
• The use of the experimental repository has been promoted to make sure that the main development repository is in a good shape most of the time.

Outstanding problems

• Developers still need to be convinced that targets can be met, that deadlines are real and that Debian can release on time.

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

• it was dead simple to make a working one
  
• the documentation is really verbose and complete
• there is a default behaviour for every ebuild, even for a minimalist ebuild
• if your ebuild has a special need, the ebuilt can override the default behaviour by redefining the function (target, in debian/rules-speech), but you don't need to, in most cases
• there are some already defined classes which can be inherited to obtain a tweaked default behaviour (imagine typical cmake build system, typical autotools build system, typical kde build system - and iirc, this can include build dependencies)
• all the information about the package is centralized in one file which is human readable from the start, plus that is obvious, or one can understand fast what a field/function/variable means from the start, without digging through the documentation continuously
  

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.

As I'm nearing the completion of my PhD, I'm starting to write about the findings from my research. The aim of my PhD is to investigate quality improvement in free software projects. After some exploratory studies about quality in free software, I decided to focus on release management as one problematic area in which improvement is possible. My approach is to study the development process of projects and to investigate ways how these processes can be improved. The hope is that such improvements will lead to increased levels of quality in the software produced by free software projects. With regard to release management, I'm focusing especially on large and complex projects, in which hundreds of volunteers need to be coordinated during release preparations. I've been looking particularly at time based release management since my exploratory studies have shown that there is significant interest in this release management strategy. The main question of my research is how and why time based release management works for large free software projects. In my first series of postings, I will introduce the seven free software projects I have studied in depth during my research. For each project, I will briefly summarize what problems the project faced in the past, what changes they have implemented to address these problems, and what outstanding problems they still have.

Now that I've got MythStream working very nicely, it's reminded me of my other wish: to be able to play music from the iTunes library on Sarah's laptop through MythTV somehow. This leads one to an excursion into the slightly documented Digital Audio Access Protocol. Life seemed fairly good until iTunes 7.0 came out with a new version of the protocol, which seems to have broken the hell out of anything that isn't >= iTunes 7.0, which is a bit of a shame, since I only learned of DAAP at around this time, so I've never been able to experiment with using a third party DAAP client. www.opendaap.org sounds all promising, but it's really just a bunch of links to projects that don't seem to have done much for years, or only implement the iTunes 4.0 version of the protocol, which is reasonably well documented. There's a few implementations of DAAP servers that will talk the pre-iTunes 7.0 version of the protocol (which I believe that iTunes 7.0+ will work with fine), but that's not what I want. All of our music is already in iTunes, and I believe DAAP doesn't give you write-access, so it's not like we could stick all of our music on Linux and play it through iTunes the other way, because we'd still be wanting to buy music from the iTunes Store, and it'd all get very messy. So I'm trying to find out if anyone's doing any work on reverse-engineering DAAP 7.0. So far, my searching hasn't turned up anything interesting. Update A bit more searching turned up this, which suggests that even legitimate DAAP protocol licensees were caught with their pants down by this change, and so products like this one have a disclaimer about what versions of iTunes they'll work with. Sad.

We the undersigned petition the Prime Minister to promote the use of Open Document Format within the UK government.

Government documents must be available for tens if not hundreds of years. Currently much electronic documentation is stored in proprietary formats, such as Microsoft's .doc format. In order to allow future generations access to these documents it is imperative that they be in a fully documented standard. Open Document Format (ISO/IEC 26300:2006) is now the international document standard and as such should be supported by the Government.

The Weston Mercury - News: Council chief probe costs 34k

This happened in North Somerset and I remember something similar happening in West Norfolk. When will councillors stop using expensive lawyers to defend themselves at the taxpayers' expense?

opensource - epetition response

Ambivalent reply from the PM's office.

Town and parish councils

Kewstoke is used as a case study, but the link goes nowhere now...

The Irascible Professor-commentary of the day 02-08-07. Movie star teachers.

I've given up watching hero-teacher films. It's really not like that. I guess the oppressive bureaucracy of state education, with pressure from executive teachers to fiddle the student numbers, wouldn't make a good film.

The Irascible Professor-commentary of the day 03-06-07. Why I hope mhy children won't become educators.

Don't let your children grow up to become salesm^Wteachers.

NO2ID:newsletter 66

"Saturday, 10th March - King's Lynn street stall to advertise forthcoming public meeting, from 10am. Volunteers needed! Contact kings.lynn@no2id.net or text/call James on 07778 966395."

Tories want to free (software) Whitehall

The shadow chancellor gets all over the BBC as a result of his party's latest conversion.

Neighbourhood Fix-It

Another better-than-local-councils system from MySociety.

Concerto for blunt instrument: Ode to the No Longer Active

"We held a place for you // But you were busy // You've been so busy lately."

It's been a good few days on our trip to South by Southwest. We flew out of Montreal on Tuesday afternoon with temperatures around -22C and got to Houston that evening with a temperature of 77F. Nice. We stayed in a Best Western near the airport in Houston, but with the Houston Rodeo currently going on, we didn't see much point in staying in the overcrowded city. So yesterday morning we did a nice drive from H-town to San Antonio, with a stop in Schulenberg for lunch at the Oakridge Smokehouse. We checked into the Quality Inn and Suites - Northwoods just inside the 1604 loop, and took a well-deserved nap before going for a stroll on River Walk and getting dinner at Casa Rio, right on the water. This morning we drove from San Antonio to Austin, with lunch in New Braunfels. Great Mexican food at El Tapatio, which was nice. After negotiating Austin's perpetually crappy I-35 traffic, we checked into the venerable Driskill Hotel right by the Austin Convention Centre and 6th Street, and took a break for a while. To top off our driving week, we headed up to Pflugerville where our friends Armand and Barbie Geddyn live -- operators of Austin's local SubGenius clench, the Ministry of Truth. Fun folks, and we got to do some grilling (fresh shrimp from the coast) and hang out with old pals. Tomorrow is the first day of registration for SxSW, and we're going to have a Quebecker meetup at the Registrants' Lounge at Brush Creek Park at 4:30PM. Should be a good time. I still have to put the finishing touches on my presentation for Saturday afternoon, so I'll probably spend tomorrow in the hotel room or in a nearby Internet caf . My presentation is at 3:35PM on Saturday; I'll post the slides here and on SlideShare after it's over. tags: travel sxsw07 minitru austin houston san antonio schulenberg new braunfels

CACert on certifi.ca I've had some good feedback from CACert users on certifi.ca this week. The OpenID server now supports CACert certs, and it's a pretty active community, so folks have been very supportive. Thanks to all for your feedback and help. tags: cacert certifi.ca

Here are some scenarios for ways that I want to use Debian on semi-embedded and embedded devices. So far there's not a good way to accomplish most of these, and each scenario needs at best a different approach, from flashybrid to Embdebian to ADS root builder to hand hacked images. That will change, I hope, if the grand unified scheme I'm plotting comes to fruition. If some of these scenarios interest you, please check out the design at http://wiki.debian.org/RootSync. openmoko First, install Debian to a 2 gb microSD card in the phone, using d-i. Bog-standard Debian install (except for it being g-i running on a cell phone!), standard partitioning. Boot the install and use it for a while. Install more stuff and tweak the system. Now you want to remove that microSD card, to save power. So, unmount it, and remove it. Debian continues running; all the files you normally use, including everything needed to boot the system, have already been copied over to the flash. If the flash gets too full, just delete any files you don't need right now. If you later find you're missing a file, just plug the microSD back in, mount it, and you can access the file again. This is also an easy way to do a backups, a simple command can sync your changes up to the microSD card. Also the microSD card can be plugged into a different openmoko phone, chrooted into, a command run, the phone rebooted, and it's been taken over, now running the same Debian install. Great party trick. ;-) slug with a 32 mb USB stick This is my sister's nslu2 box, that only does one thing, really: Dial up to the internet and route packets to the access point. It's also nice to get Debian security updates from time to time. And I don't want to have a noisy hard drive on it, so it runs from a small USB stick. The initial install is done to USB drive, then I add the USB stick to the picture, boot the nslu2 up, configure ppp, run it, and I can remove the drive, it's ready to run in embedded mode from the USB stick. Later I need to apply a security update, so I plug in the USB drive, mount it, run aptitude, and I'm done, just unmount the USB drive again, and the USB stick now has updated versions of the necessary files. true embedded system development A company is creating a real embedded arm system, it needs to run from 64 mb of flash, with a fair chunk for their own application, and a fair chunk free for user data. An engineer is using his development system to work on creating the jffs2 filesystem that will go on the production hardware. He starts by untarring the Debian armel port to a drive, and copies in the custom application. Then he sets up an empty jffs2 filesystem on mtdblockN. After rebooting the system, the jffs2 contains the files needed to boot Debian on its own. The engineer runs the custom application, and the jffs2 is now ready to run that too. But it's getting a bit tight for space on the jffs2. Time for busybox. He runs "busybox install [long list of busybox commands]", replacing lots of core commands with their smaller busybox versions. After a few reboots, all the init scripts are hacked up to work with the busybox stuff. (Argh.. Debian should work with it by default. Anyone want patches?) Maybe he goes on to run mklibs or do something with uclibc. This might take a few iterations to get right, but he doesn't worry about screwing up the system -- he knows that at any point he can delete all the files on the jffs2, reboot, and be back to his unmodified system on the disk drive. Once everything is ready, he can load the jffs2 onto production hardware and the new embedded system is ready to be tested and qualified. slug thick client My nslu2 box, used for handling some USB devices like my UPS, security camera, etc. When the network is up, and the storage server is up, it can nfs mount root, but that doesn't work when the power goes out and the server needs to come down. I want it to keep working in that case, as a kind of detached thick client. After hacking nfs root support into d-i at some future point :-) I have it booting with nfs root already. There's around 3 mb of unused flash on the slug, so I set up a jffs2 partition using that, and through some trial and error get the right files on there to let the system keep running in a degraded mode when the nfs mount goes down. 3 mb does fill up pretty quickly if the camera notices motion, but it's good enough, so I decide not to put a USB stick on the box.

Last weekend I had great fun during my first cal otada with my Friends in Picamoixons, very near Valls in Tarragona. While it's already a tradition for my friends, this was the first time I went there, after having missed many other opportunities probably due to my overcommitment to triathlon training a few years ago. So on Friday we drove up North to Catalunya, and arrived quite late to Frago's house in the center of the town, where we slept in two packed rooms and the terrace after getting some beers in Dune. Early next morning we met Frago's friends and bought the necessary vegetables and wine for our great lunch, and soon after we were in the middle of some olive field outside Picamoixons, where we prepared a big fire and the cal ots. A cal ot is a special type of onion which grows in the area, which ends up being very long and thin. After cutting part of the green leaves, they are cooked over the flames, which carbonises the first few layers of the onion, but leaves the inner part ready for consumption. After this, you just need to pull from the inner leaves to get rid of the burnt stuff and eat the rest with a delicious and typical sauce for cal ots. So far, so good. What if your group of friends has extended the tradition, allowing for extra fun bits? In our cal otades, after you've peeled the cal ot, you keep the carbonised stuff. It's valuable ammo, which will soon be thrown at others' faces. Trying to remain clean is futile, you soon are covered by sauce and black stuff all over your head and clothes. This was real fun! After eating part of the group went up a mountain to visit an arab tower, which helped me not to get totally drunk before the night. When it got dark, we were all back to our positions around the fire, chatting and listening to varied music, while we waited for the lunar eclipse. The eclipse was impressive, seen from the country side, with absolutely no luminic contamination. My friend Jordi carefully prepared his camera to do a good photograph series of the event, and the results were impressive. When the eclipse was about to be full, it was great to see a miriad of stars appear in the sky, previously hidden by the perfect full moonlight. We were just too lucky that the weather fixed up just on time to have a completely clear sky.

The lunar eclipse, as seen from the Catalan countryside. Pics by Jordi Jover. Many were quite tired by 3 or so, so we started setting up tents and went to sleep by 4. Sunday was a slow day, dedicated to cleaning up our stuff and eating leftovers cooked on a new fire. We were back in Val ncia at 8PM or so and even after showering and cleaning my hair with shampoo, my head still smelled like smoke. Actually, I think it might still smell a tiny bit today. In short, a lovely weekend, which I hope to repeat next year. Too bad the lunar eclipse bit will be missing for quite a few more years. :)

Last weekend I had great fun during my first cal otada with my Friends in Picamoixons, very near Valls in Tarragona. While it's already a tradition for my friends, this was the first time I went there, after having missed many other opportunities probably due to my overcommitment to triathlon training a few years ago. So on Friday we drove up North to Catalunya, and arrived quite late to Frago's house in the center of the town, where we slept in two packed rooms and the terrace after getting some beers in Dune. Early next morning we met Frago's friends and bought the necessary vegetables and wine for our great lunch, and soon after we were in the middle of some olive field outside Picamoixons, where we prepared a big fire and the cal ots. A cal ot is a special type of onion which grows in the area, which ends up being very long and thin. After cutting part of the green leaves, they are cooked over the flames, which carbonises the first few layers of the onion, but leaves the inner part ready for consumption. After this, you just need to pull from the inner leaves to get rid of the burnt stuff and eat the rest with a delicious and typical sauce for cal ots. So far, so good. What if your group of friends has extended the tradition, allowing for extra fun bits? In our cal otades, after you've peeled the cal ot, you keep the carbonised stuff. It's valuable ammo, which will soon be thrown at others' faces. Trying to remain clean is futile, you soon are covered by sauce and black stuff all over your head and clothes. This was real fun! After eating part of the group went up a mountain to visit an arab tower, which helped me not to get totally drunk before the night. When it got dark, we were all back to our positions around the fire, chatting and listening to varied music, while we waited for the lunar eclipse. The eclipse was impressive, seen from the country side, with absolutely no luminic contamination. My friend Jordi carefully prepared his camera to do a good photograph series of the event, and the results were impressive. When the eclipse was about to be full, it was great to see a miriad of stars appear in the sky, previously hidden by the perfect full moonlight. We were just too lucky that the weather fixed up just on time to have a completely clear sky.

The lunar eclipse, as seen from the Catalan countryside. Pics by Jordi Jover. Many were quite tired by 3 or so, so we started setting up tents and went to sleep by 4. Sunday was a slow day, dedicated to cleaning up our stuff and eating leftovers cooked on a new fire. We were back in Val ncia at 8PM or so and even after showering and cleaning my hair with shampoo, my head still smelled like smoke. Actually, I think it might still smell a tiny bit today. In short, a lovely weekend, which I hope to repeat next year. Too bad the lunar eclipse bit will be missing for quite a few more years. :)

"Second Life runs on 2,000 Intel and AMD servers in two co-location facilities in San Francisco and Dallas. The company has a commitment to open source, with servers running Debian Linux and the MySQL database. Linden Lab chose Debian Linux because the software is suited to scaling massively with a small IT staff, said Linden Lab CTO Cory Ondrejka. MySQL allows the server farms to scale horizontally, by adding large numbers of low-power servers as needed, rather than vertically, which would have required Second Life to run on a few, powerful systems, Miller said."
Joe Miller is VP of platform and technology development for Linden Lab.
Source: http://www.informationweek.com/news/showArticle.jhtml?articleID=197800179

We know that, but sometimes we spend more time and effort with pointless discussions. Discussions are good, don't get me wrong, but they need to start and end. Get a life, go squash some bugs, package something NEW and upload to experimental, write documentation or tell the word who else is using Debian. Debian is bigger than our own egos and debates.

Don't you care that Second Life uses Debian? Aren't you a Second Life user? I'm not a Second Life user, but if Joe Miller come out and tell the word that they use something else, a lot will go and say 'look, Debian is better than that, but the world don't care let us keep fighting'. Debian aims to be a universal operating system, and the universe is bigger than OFTC and lists.debian.org.

Wouter asks why I wrote pommed instead of patching pbbuttonsd. First things first, pommed was originally named mbpeventd and targeted only at the MacBook Pro and MacBook laptops. The port to the PowerBook and iBook (which is what Wouter uses, I think) wasn’t a goal at first. pommed handles the hotkeys events and the ambient light sensors (if available) and that’s it. Nothing more. pbbuttonsd does a lot of other things that other pieces of software can handle far better than it does. I never ran it on my PowerBook and stuck to pmud; it did just what I needed it to do, and it did well. The kernel handled the LCD backlight all by itself, and I had no need for either the volume +/- keys or the eject key. When I got my MacBook Pro, I took a look at the various ways to get the hotkeys to work. Well, nothing worked. I discovered that pbbuttonsd was also available on i386/amd64 and gave it a try. IIRC I had to build it on amd64, and the Makefile already raised a couple of mental flags. But oh well. Then I tried to configure it, and discovered a gazillion configuration options, half of them unneeded. Anyway, I got to the point where it would run, and obviously there was some patching to be done to get it to play nice with the MacBook Pro. To put it simply: looking at the code made me cry. It’s horrible. Incredibly complicated and obfuscated for no good reason. At that point, patching was out of the question. Moreover, I never liked pbbuttonsd that much, for various reasons, ranging from its “let’s do everything!” policy to its SHM interface for the GUIs (come on, that’s the 21st century knocking at your door). So, in a nutshell:

• it’s a nightmare to configure
• it does a lot of things that I do not want it to do
• I really can’t look at that code for more than 30 seconds without yelling at it
• it’s faster to just write something new from scratch than to clean up pbbuttonsd
• DBus looked like a nice thing to play with, and this was an opportunity to give it a shot

I really like the KISS approach and the traditional UNIX way of doing things, so I tend to dislike most one size fits all software. It took me, what, 2 hours to build the first version of mbpeventd which handled the LCD and the keyboard backlight. That’s all the features I needed, past that point everything else was just pure bonus. As for the name… mbpeventd really sucked as a name, and it wasn’t a good name anymore once the PowerBook support got added. I did not want to go with something like “appled” because I did not want to use the name “Apple”, but that was the closest match. Then I thought “hmm, why not … translate it … pommed? … sold!”. The name is funny for both Corsac and I because it’s a fortune cookie from one of the IRC channels we’re both hanging on; as it happens, the fortune is about Apple hardware and how users can get lost with a one button mouse. So, why use pommed? Use it if you want something lightweight, fast and simple which won’t try to do everything for you. And you can even patch it and send me the patches!

Julien Cristau and I have finished putting Xorg 7.2 in to experimental, so have at it! Julien did most of the work on this release, including the server and libs. The transition to git appears to be paying off already, as we're all moving towards running the bleeding edge stuff mainly because it's so easy to do now. This should give us the ability to take a more active role in upstream development. I've already sorta taken on responsibility for some of the upstream documentation (don't ask me how that happened) but now that things are moving I'll be looking to do work in the code as well. I wouldn't be surprised if other XSF members start to do the same.

One thing that has always surprised me is how few people talk to speakers after they have finished their lecture. A lecture might have many questions and the questions may be cut off, but when the speaker leaves the room they will usually do so alone.

When I give lectures at conferences I'm always happy to spend more time talking to people who are interested in the topic and disappointed that so few people choose to do so. It seems that other people have similar experiences, there have been several occasions when I have invited speakers to join me for lunch and no-one else has shown interest in joining us.

Usually the most significant factor in making someone offer a talk at a Linux conference is the opportunity to teach other people about the technology that they are working on. People with that motivation will take the opportunity to teach people at lunch, dinner, whenever.

Linux Conf Au has an event called the "Professional Delegates Networking Session" which is regarded by some people as the way to meet speakers (about half the delegates don't attend so the ratio of speakers to delegates is significantly better than at other conference events). But it seems to me that it's more efficient to just offer to buy them dinner. When I worked for Red Hat the maximum value for a gift I could accept was $100US, I expect that Red Hat has not changed this policy since then and that most companies that employ speakers at Linux conferences have similar policies. $100US is more than a meal costs at most restaurants that are near a Linux conference.

If I was a manager at a company that sent employees to a Linux conference I would first send email to some speakers who were working in areas of Linux development that were related to the projects that the employees were working on. I would ask the speakers if they would be interested in having dinner bought for them by my company and give them the option of bringing one or two friends along for a free meal (the friends would probably be people who work in similar areas).

I have not been active with SELinux recently. I was seriously lacking motivation, and recently the old server I was using to test my SELinux stuff died because of a hardware failure. But these days I installed vmware, and in order to try it out, I decided to install a SELinux Debian etch system. Then I also updated my policy packages. I actually did quite some progress on the packages; I not only merged the latest upstream SVN version, I also fixed a couple of Debian policy issues (or worked around them), and added some new functionality. First of all, I extended the update tool (now called update-selinux-policy). It will not only install the current version of each module, but also rerun autodetection and install additional modules if you added software in the meantime (it won't do the relabeling for you, though). This should make system administration a lot easier. The packages now come with a -dev companion, which includes the interface files. The README.Debian file details how you can use this to build a custom policy module, and the policygentool included will actually generate a template for you. This should make the development of policy modules a lot easier. Grab the policy packages from my experimental refpolicy directory. Note: while they share the "refpolicy" source name with the packages in Debian main, they are packaged independently. Manoj is maintaining the official packages, and I never learned how his Makefiles work, so I'm sticking to my own packaging for my development stuff. Oh, and for me they don't work in enforcing strict mode at boot yet. Policy is still incomplete for Debian (but down to ~25 audit errors). Targeted mode works in enforcing at boot time. The main issue seems to be the way Debians init ramdisk is working and the /dev directory is populated. I don't think I'll keep the packages updated frequently, sorry, and I don't think I'll have time to get enforcing working for strict, either. :-(

Enrico, you forgot your own advanced ways of wasting time (and have some fun). ;) Here are the summaries of the candidate DPL platforms, in one sentence each: 93sam

Once we don’t Select a friendly community where the packages towards a lot of software, community are most noticeable use to show their packages towards a problem good job.

aigarius

While I were elected DPL, I have to time leave Debian Developers Corner Site, map Search about it should not have not be Even if he has, the NM; process is before.

ajt

Ideally, I’d expect that we ought to make It work together in Linux and a DPL review of the community and October firmware resolutions recall vote maybe That’s been some of stuff I’ve been a server near you United States.

hertzog

The sponsorship, principle.

sho

I believe admit volunteers to scratch our bug tracking system I do what I would like LowThresholdNmu to happen again; Admit it has rhymes with a few of it Debian; is to be really like to automatically see them.

sjr

To the web site, map Search Not Published Yet Back to the Debian Project Select a server near you United States; the web Site, map Search Not Published Yet Back to the debian For other contact information, See the Debian Project Select a server near you United States.

stratus

It is today in the web team, the users: and waited supergroups i will that any Debian support: this change our major Desktop, with Lenny development website, we’ve now almost our official status and how a statistics page.

svenl

To the ban.

wouter

I am of a native Dutch is not an area where possible.

These summaries have been generated by the following script:

for i in 93sam aigarius ajt hertzog sho sjr stratus svenl wouter; do
  echo $i
  lynx -dump -nolist http://www.debian.org/vote/2007/platforms/$i dadadodo -c 1 - 2> /dev/null
done
It is somehow subobtimal, as aigarius and sjr’s summaries show: the headers and footers of the page have some influence, but well… it was fun anyways.

I just had a total Mr & Mrs. Smith moment. You know the bit where they're standing in the elevator, listening to the elevator music. Waiting for the door to open.

That would be the waiting time between the water breaking, causing us to page the midwife and her phoning us back. =)

The advice: Sleep now, relax.

And so shall it be. =)

(Update: 9am)
Contractions are 6 minutes apart, but still the kind she can sleep through, so she is. Spoke to the midwife, and she advises more rest. Next update with her, assuming nothing eventful, is around 1pm.

(Update: 2pm)
Contractions have slowed to every 12 minutes, but have increased in intensity. Just spoke to the midwife, who gave some tips about moving things along. She just got into the birthing centre after 3 hours of being on the road. It's usually a 30 minute trip, and she lives near us. She thinks that it will be fine, though, given that she was mostly stuck behind snow plows. Next phone call in 2 hours.

(Update: 4:30pm)
Contractions up to 5 minutes apart, lasting about 45 seconds each. We're enjoying a relaxing afternoon watching X-files. She's convinced that she's talking fine through her contractions, but her sister did a great impression:

Well, as I was saying, I ...

(she crouches over)

Oh there's one. Yup.. I'm having a contraction..

(pause)

Yup. Well. I can still talk through them.

Mhm, yup. Sure you can. =)

The midwife called us to check in. Angie described herself as "impatient". Otherwise everything seems to be going as normal. The midwife will call us again in an hour or so to sort out plans for the evening, probably including a visit to us at home since we're close enough to where she lives.

(Update: 6pm)
We've hit the magical number of contractions: every 4 minutes for 45 seconds. Apparently we're supposed to phone after two hours of this, but we phoned after one. My bad, but this is when we had planned to talk anyway. She answered the phone when we paged the midwife, and was sufficiently unable to talk that she handed to phone over to me. The midwife will be here for an in-person visit in about an hour (subject to speed of traffic)

(Update: 7:30pm)
At 7, I went out to shovel a space for the midwife to park. It turns out she drives a cute little VW bug. so at 7:15, I dig her out of the snowbank she got wedged into because I hadn't dug enough of a spot. 7:30, we're now both inside. =) Temperature is being taken, contraction charts being reviewed, etc.

(Update: 8:15pm)
The midwife just left. Right now Angie's 2cm dilated. Apparently there are multiple membranes, and they haven't all broken. This is a good thing because it continues to protect the child and give it manuverability. Charlotte will be back in 2 hours to see how we're doing.

---

I'll update this entry with random little updates, and post a new one when we head out.

Joey Hess writes about automated system testing in his anti-platform. That's one of the things that I'd like to work on, some day, when I have some free time again. There's two things I would like to do next in this area. First are improvements to piuparts so divide the tests it does into smaller bits, and to add a plugin framework so that it becomes easy to write new tests. The current piuparts code isn't really well suited for this, but the whole program is only a few hundred lines of code, so even if it had to be rewritten completely from scratch, it shouldn't take more than a couple of weeks of full time work (piuparts development is often slow because you need to run tests on large parts of the archive). The other thing would be to test upgrades not of individual packages, which piuparts does now, but of entire systems, preferably in emulated machines instead of chroots. This would probably need a new tool. The third of these two things would be to start adding automatic tests to packages so that we can test whether they work when they're installed. Ian Jackson did some work on a tool for this, but we need to use the tool. Ideally, we would have a setup where packages get tested automatically, continuously (daily, if possible) and results are reported instantly. At the moment, piuparts results need to be filtered manually, and that's a pain. Adding a "package health indicator" the PTS based on these automatic tests would be cool. We could even have a "Debian big board" web page, with a small square for each package, colored green if it's bug free and passes automatic tests; colored cyan if there's only bugs of severity normal or below, or a problem with some of the automatic tests; colored pink if there's a bug of severity important, or all automatic tests fail; and colored red if there's bugs of severity higher than important. This would give an overview to the health of Debian with a glance.

Why you won't be voting for me for DPL this year. Or, my plans for Debian stuff over the next year (or three). Most of these plans embody larger themes and directions that I feel Debian should take. I am a strong beliver that working code and getting stuff done is the best way to work toward larger goals, so I won't bother to try to explain the larger goals. constantly usable testing This is so important that it has its own page. This is my first public posting of that proposal, and it should not be considered finished. I plan to finish it, and get to work on it. website www.debian.org is deprecated, but this is not obvious to either users or developers. That's because it's not formally deprecated, we just treat it like it is: We don't use it for anything new. Instead we have wikis, planet, times.debian.net, etc, etc, etc, etc. Unfortunatly that has created a bit of a mess for users, who are still often stuck trying to use www.debian.org, or who can't find new stuff that is on other sites. A solution could be creating an alternate starting point for users, to help them learn about Debian, install it, and point them to docs and all the other useful sites once they're more involved and using Debian. I hope to find time to work on and promote such a thing. I plan to continue moving stuff that needs to be maintained actively and grow off of www.debian.org to the wiki (as I've done with some of d-i stuff, for example), and encourage others to do so as well. Anything under /devel/ on www.debian.org is an especially good candidate for the wiki. double the archive sync frequency again Now that we've switched to updating the archive twice a day, and dealt with the (minor) issues caused by it, it should be easier to increase it to a frequency that is more likely to cause noticible turnaround time improvements and thus speed up some development. As it is, many people sleep through one or the other archive update. So I support doubling it to four times a day, or more (six seems better). automated whole system testing Automated whole system testing is important because Debian needs to keep working in so many obscure and annoying to test situations. Does d-i work on m68k? Does the desktop task install properly and work? Does debootstrap install a usable system on every architecture? If we rely on user reports, things can fall through the cracks entirely or not be noticed for too long. I've been running a d-i lab for a few years, which tries to automatically test installs on 6 architectures. However, between the current kernel not supporting several of my test machines due to hardware and software bugs, and the general time sync of keeping a rack of aging and obscure test boxes working, this has not been very useful lately. I feel that the solution is emulation: It should be possible to run Debian under emulation for most architectures. I hope to get an absurdly powerful server donated, and switch my test lab over to running in emulation on it. developer (virtual) machines The other benefit of emulation is that everything needed for testing stuff under emulation can be easily distributed to others. Getting developer accessible machines for certian architectures has been a problem in Debian. Emulated systems can sidestep this problem. All that's needed is a collection of documents and/or bootable images that developers can use to set up virtual machines for as many architectures as possible. We have steps in this direction. Hercules contains documentation for how to install in it using d-i. There is a kernel flavor and d-i boot images for mips on qemu. Having to ssh out to a DSA adminned box to deal with a buld failure on $ARCH, and having to wait for build deps to be installed should begin to feel antequated and quaint. It is. find the next nslu2 Debian's support for the nslu2 is an excellent development. It opens up using Debian for a whole new set of tasks, that need low-powered, semi-embedded, commodity hardware, that before were the province of special-purpose embedded distros. It also blew the popcon numbers for arm through the roof. We need to find the next nslu2-like target and get to work on it. I'm hoping that it will be a wireless router, because that's the only thing I'm not running Debian on now. :-) But it could also be a cell phone, or PDA..

Lots of short, sharp items today that I want to get down.

LinuxQuestions.org supports OpenID First, I'm psyched to see that LinuxQuestions Wiki now supports OpenID. Jeremy gave the scoop in The LQ Wiki Now Supports OpenID. I was glad to see that LQ's on the OpenID path. It's a really strong community site, and I think it'll benefit greatly from opening up the authentication process. tags: linuxquestions jeremy garcia lqwiki openid

Wikia and OpenID Angela Beesley had some comments on my Journal/7 Vent se CCXV posting about wikiHow's support of OpenID. In that posting, I said that I thought companies with lots of wikis, like Wikia or wiki farms, might have a disincentive to participate in the OpenID network. Angela put me straight on the issue in a post on WikiAngela about OpenID. I'm glad to hear that Wikia is considering supporting the protocol. Then again, it's hard to believe that an Open Content, Open Source company is really going to go out of its way to avoid open standards and open login. tags: wikia openid angela

DemoCampMontreal1 I had a good time last night at DemoCampMontreal1. I gave the first demo -- on, of course, the MediaWiki OpenID extension -- and I had some technical difficulties that didn't let me show off all the functionality. Which was kind of a bummer, but there were lots of questions about it from the audience, so that kind of made up my time. The room was packed, by the way -- pretty much anyone who's anyone in Montreal tech was there. I'm looking forward to DemoCampMontreal2 on 29 March! tags: democampmontreal1 openid montreal demo

certifi.ca One of the best ways to establish credentials on the Web is to use a signed SSL certificate in your browser. It's fast, incredibly secure, and once you get it set up you can just forget it. They're also practically immune to phishing. Unfortunately, most people don't even know what browser certificates are, how they work, or what to do with them. Consequently, most Web sites don't support browser certificate authentication. Vicious cycle. But, one of the cool things about OpenID is that you can disconnect the authentication method from the Web site you're using. Most OpenID identity providers still use username/password combos for authentication, which is why critics have said that the standard is vulnerable to phishing attacks. I wanted to see if it were possible to set up an OpenID identity provider that used browser certificates as the only authentication system. So, in my copious free time, I've hacked up certifi.ca. It's based on the cool PHP OpenID Server that JanRain made, but I've ripped out all the password stuff, and now it runs on luscious certificatey goodness. I'm going to be enhancing the service in the near future, but I wanted to get feedback from folks interested in OpenID as soon as possible. I'm using it for my primary OpenID delegate, and it seems to be working great. Please give it a try and let me know what you think (admin@certifi.ca). tags: openid pkix ca browser certificates certifi.ca

DemoCampMontreal1 on Montreal Poutine There's an article on DemoCampMontreal1 on Midnight Poutine. That's me up on the stage, in the photo! tags: me democampmontreal1 midnight poutine

Nepean Hotspurs Selects win On Saturday, a Muslim girl named "Azzy" Mansour, from Ontario playing in a soccer tournament in Laval was ejected from the tournament (by a Muslim referee, notably) for wearing a hijab -- reportedly because it was a safety hazard. (Montreal Gazette story, registration required.) Admirably, her entire team forfeited the tournament in protest. I'm not excited about Quebec's reactionary activity around Muslim, Sikh, and other religious community's different clothing rules. However, I understand that Quebecois -- and French people -- have a different idea of personal freedom than Americans. I try to be understanding and put myself in the Quebec headspace for this kind of stuff. Mostly, though: I admire the soccer team, the Nepean Hotspurs Selects, for standing up for their teammate and their friend. A lot of teams might have gone ahead and played without her, and it took some courage to drop out of a tournament they'd had high hopes for. They're sixth-grade girls, but they've learned something about integrity that most adults never learn. Kudos to them. tags: quebec hijab soccer nepean hotspurs selects