Debian Squeeze 6.0

As predicted - the release is starting this weekend 5/6 February 2011. IRC channels are starting to buzz -- irc.debian.org #debian-release - and there's also a live commentary session at http://identi.ca/debian

For many people, this is yawn-worthy: Debian stable is seen as old, outdated, outmoded. This is the climax of two years work.

Debian 6.0 will be supported for the lifetime of this release + one year if the past few releases are a guide.

A wrap up release 5.0.9 is planned for the previous Debian 5.0 [Etch Lenny] which will be supported for another year.

Debian works on many machine architectures: it's the upstream for Ubuntu and many other Debian derivatives: it works in many languages, has 1034 developers and maintainers maintaining 28693 packages [last number may vary fractionally depending on machine/architecture].

This is big - and I'm pleased and proud to be part of it. Oh, and there's now over 80 parties worldwide to celebrate :)

[UPDATE - Thanks to my colleagues who pointed out my mistake - Debian 4.0 was Etch, 5.0 is Lenny, 6.0 is Squeeze and 7.x will be Wheezy. Developer/maintainer and party numbers also updated]

As a site that discusses a variety of programming languages, I thought it would be good to have syntax highlighting for the code snippets. This blog runs Movable Type so it had to fit in with the setup I have already. So I found the Syntax Highlighter module ok and the initial installation went fine, it was simply:

1. Download the .zip archive
2. Unzip the archive into a temporary directory
3. Copy the plugins/SyntaxHighlighter directory to my plugins directory
4. Copy the mt-static/plugins/SyntaxHighlighter directory to static/plugins

You then need to edit the HTML Head template and add to the bottom of it the following line:

<$MTSyntaxHighlighterInclude$>

Next, I like to use Markdown as my markup language. But you can only have one type text filter. Another plugin called FormatStack solves this. Create a new stack and put Syntax Highlighter before Markdown. You can then create documents with both sorts of tags and it works quite nicely, well almost. Mid Century Problems This is probably not a Mid-Century specific problem but the modern templates or styles may cause a problem. You ll find you switch styles and suddenly, no more syntax highlighting. The problem is the onLoad functions get overloaded. Some styles have an onload property on their body. You ll see lines similiar to

 <body id="blogbase" class="whatever" onload="mtEntryOnLoad">

This onload event stops other onload events, which means Syntax Highlighter cannot do its thing. The fix is rather simple, you just adjust the templates so they look like the following:

<body id="blogbase" class="mt-entry-archive layout-wtt">
<script type="text/javascript">
 mtAttachEvent("load", mtEntryOnLoad);
</script> 

After doing this and publishing it all worked! You may also see this sort of problem with other plugins that use the mtAttachEvent() Javascript call. Reducing Includes By default, the script includes all syntaxes it knows. If you want to only include some, you do this by specifying what brushes you want. For example if you only will highlight perl and python scripts then you can change the line to:

<$MTSyntaxHighlighterInclude brush="perl,python"$>

Syntax Themes The other attribute the Include line will take is theme. There are several themes but default is alternating white on grey with the rest being variations on light text on a dark background.

I just got a Zoom 5341 modem to replace a very sketchy old Motorola model and so far it seems to work fine. However, the Comcast self-install switch process was not seamless. After you plug your new modem in the process starts fine, capturing your session and prompting you for your account. However at the next step it prompts you to download the Windows or Mac only client, directing you to an address http://cdn/.... It is at this point you can get stuck if you're behind a Netgear router (I have a WNDR3700) and probably others. The simple problem is that, for whatever reason, the factory firmware in this router does not pass on the domain search suffix through its inbuilt DHCP client. Without that, cdn doesn't resolve to anything, so you can't download the self-help tool and you're effectively stuck at a "can not find this page" screen. If you google at this point you can find many people who have hit this problem, and various information from erroneous suggestions that you've been hacked (?) to most people just giving up and moving into Comcast phone support hell. Assuming you now don't have internet access, you can complete the process with a quick swizzle. Somebody might be able to correct me on this, but I don't think you want to run the self-install tool from an actual computer plugged directly into the modem if you have a router in the picture, because the wrong MAC address will get registered. So, your best solution is to turn everything off, plug your computer directly into the modem, turn it on, get an address, download the tool, turn everything off, plug the router back-in to the modem and then run the self install tool. At this point, everything just worked fine for me. Netgear should probably fix this by correctly passing through the domain search suffixes in their routers. Comcast should probably fix this by doing some sort of geo-ip lookup to give clients a fully-qualified address in that webpage to download the tool even if their router is broken (or really, does downloading that file really require a content-delivery network?). You can probably fix this by running Openwrt on your router before you start. Otherwise, the Zoom modem and the Netgear WNDR3700 seem to make a very nice combination which I would reccommend.

The Debian Press Team will provide a live coverage of today's squeeze release (Yaaay!) via identi.ca. Follow us at http://identi.ca/debian.

One of the many Free Software projects I work on is JFFNMS, which is a network management system written in PHP. In light that the last IPv4 address blocks have now been allocated to APNIC it s probably timely to look at how to manage network devices in a new IPv6 world. First you need to get the basics sorted out and for that it is best to use the net-snmp command line utilities to check all is well. Then its onto what to do in JFFNMS itself. Now fixed with proper markup, I hope.

    strlcpy(hostname, a1, sizeof(hostname));
        if ((pptr = strchr (hostname, ':')))  
            remote_port = strtol (pptr + 1, NULL, 0);
         

Special Agent 6 All devices that are capable of being managed with SNMP have an agent. It s basically the SNMP server on the router, switch or server. The first step is to make sure it can accept and send traffic using IPv6. Depending on what the device is, it can be real simple. For example, my little Juniper router its a matter of setting the community and access control, just like IPv4 settings:

csmall@juniper1# set snmp community public clients 2001:db8:62:d0::/64

And then run snmpget on the command line to check

csmall@elmo$ snmpget -v 1 -c public udp6:2001:44b8:62:d0::4 system.sysObjectID.0
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.41

We have success! For Linux systems that use net-snmp you will need to make the snmp daemon listen on UDPv6 ports as well as adjusting the access control. Access control is a matter of adding com2sec6 lines to /etc/snmp/snmpd.conf They are the same format as com2sec lines and are reasonably straight forward. Next, get the daemon to listen to requests on the IPv6 ports as well. The snmpd(8) man page says:

By default, snmpd listens for incoming SNMP requests on UDP port 161 on all IPv4 interfaces. However, it is possible to modify this behaviour by specifying one or more listening addresses as arguments to snmpd.

It wouldn t of killed them to put comma separated list somewhere, now would it? My /etc/default/snmpd file now looks like:

SNMPDOPTS= -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid udp:127.0.0.1,udp6:[::1]:161

The bits in bold are the changes. Then its a quick check:

csmall@elmo$ snmpget -v 1 -c public udp6:[::1] system.sysObjectID.0
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

And we have working agents! JFFNMS Changes OK, we have a working IPv6 network and snmp works across our network so we can query devices. JFFNMS uses PHP so all should be well, shouldn t it? Database Tables This is an almost classic problem with converting IPv4 to IPv6. You have 15 bytes for a IP address string 111.222.333.444 . Ipv6 can be much larger than that. JFFNMS has things like

  CREATE TABLE  hosts (
    [...]
   ip  char(20) NOT NULL default '',

A simple fix to use a char(39) or varchar(39) will do the trick. Fixing the JFFNMS code One of the most troubling problems with the host entries is that the values entered by a user can be a hostname, IP address or IP address and port separated by a colon. There are lots of bits of code that separate out the port or address by just finding the colon or use non-IPv6 aware functions like gethostbyname() that will need to be fixed. I ve got a function to check for an IPv6 address, using the inet_pton() function.

  function is_ipv6($addr)
 
  $net_addr = @inet_pton($addr);
  if ($net_addr === FALSE   strlen($net_addr) < 16)
    return FALSE;
  return TRUE;
 

PHP functions PHP still has the old IPv4 only functions, but unlike libc does not have the Address Family independent functions. The most significant absence is the replacement functions for gethostbyname(). There is dnsgetrecord() but it is quite low-level (it won t recurse lookups if you get alias or CNAME results). It s a little hit and miss in PHP-land with what functions work with IPv6 addresses and what ones do not. fsockopen() and file() do work with IPv6. PHP and SNMP To query remote devices using SNMP, JFFNMS uses the PHP SNMP functions. Unfortunately, while there is some IPv6 support in PHP, it doesn t extend to the SNMP functions. The library does it, as the net-snmp command lines use the same library, it is just that the small shim between the script and net-snmp that is PHP gets in the way. Looking at the PHP code itself you find things like

    strlcpy(hostname, a1, sizeof(hostname));
        if ((pptr = strchr (hostname, ':')))  
            remote_port = strtol (pptr + 1, NULL, 0);
         

which definitely need to be fixed for IPv6. There is also some simple address lookup going on somewhere as well which will also need to fixed. In short, JFFNMS won t be doing SNMP based queries over IPv6 until php5-snmp can do it. Reachability JFFNMS also has a different sort of query called a reachability type. It s essentially a ping from the server running JFFNMS out to the device being managed. It uses fping to do this work, but there is also a program called fping6. It s a simple matter of checking the address type and then selecting fping or fping6 to do the reachability work. The JFFNMS code soon to be pushed into git has this change in it now. Anything Else? The next stage is to find anything else that will work with IPv6. A likely candidate is the TCP and UDP port types as they use nmap to discover the ports and the fsockopen() function call to poll it. fsockopen() does handle IPv6 addresses if you escape them in square brackets.

Sven has been very busy getting a new Debian ncurses packages into order. With the multiple changes made and the fact that so many things depend on the shared libraries, we decided that it is best to put the first cut of these packages into experimental.

We're now using the Quilt 3.0 source format for our packages, which means that we should have a better handle on the patches, especially as they all now have Dep-3 patch tags .

So what has changed, why should you go over and try the experimental packages?

• First, it will help us with checking the packages actually work, Sven has tried them out (I will be soon) but the more testing the better.
• We've updated the upstream patch level (basically the upstream version) on this set of packages.
• New package! ncurses-examples which are all the example programs that shows you what ncurses can do.

If you use dh-make with CDBS then you need to know that CDBS is no longer a package type, but is a rules format. This is where it should of been in the first place and for a few versions of dh-make there was this half-hearted attempt to change it over. Version 0.57 has the right fixes and just got uploaded. I'm not sure how many people actually use CDBS on new packages anymore, but it should work fine now. Oh, and dh-make is now of Alioth git repository instead of subversion.

No real terribly exciting updates lately but all important in their own way. ncurses A new version of ncurses got uploaded into sid. It should hopefully fix the backspace versus delete problem some of the FreeBSD people have been having with some of the terminal emulators. Oh, and if you are pining for the good old days when 8 colours and 64kB of memory was good enough for everyone, checkout ncurses-examples which have a bunch of interesting things you can do with curses, including some games. Anyone remeber the tower of Hanoi? dh-make dh-make, the tool to take a raw tar (or zip) archive and make a Debian package has been updated too. One of the interesting side-effects of maintaining dh-make is you find out (usually through bug reports) the little changes that happen to the Debian package build process. Most people, including myself, though the main big thing between versions 1 and 2 and version 3 of the source formats was the inclusion of quilt patches right inside the source files. And probably for the sake of "main things" this is true. What I didn't realise is that dpkg-source has changed in other ways too. Bug 580804 tripped this one up. For most people, you run dh_make, fix some things up and use debuild. If you didn't have the original tar file (perhaps you got the source from git or svn) you just use --creatorig and it copies the current directory into ../whatever-1.2.3.orig Source format 3 doesn't like this. Previously it would find that there was no orig.tar.gz archive but there was a orig directory and make the archive from that. Now you have to do it yourself and dh_make does it like that too. pidgin-musictracker Now this should of been a pretty simple stock-standard upstream upgrade. Download the file, uupdate, debuild and release. The problem is that upstream didn't fix their po files. These are the translation files that convert the raw english texts in a program into whatever language. This means the first time you run the build process, you have no diff file. However when you run it the second time, part of the install target rebuilds the po files (mainly the line references), you have differences and then a big diff file of these po updates. The real fix is to make sure your po files are up to date before you release! The trick is that they don't automatically and I have been caught myself; though it happens in the release testing phase (because my release testing involves usually building the debian archive so I see my own problem). irc came to the rescue again. Someone there suggested getting dpkg-source to ignore the changes. The way you do that is put parameters into debian/source/options. I wanted to ignore the changes to the po and pot files so my file has:

extend-diff-ignore=po/.*\.pot?

I put that in and it works!

Mudlet I've been playing text based multi-user games on and off for years, or perhaps that's decades. When I first started playing them, all you had was telnet. Then this program called TinyFugue appeared which is still shipped by Debian. The generic term for these sorts of games are MUDs, or Multi User Dungeons. Anyhow, I recently came across a new MUD client called Mudlet. It's a very slick program and works quite well. The way it does its triggers (reactions to what the mud sends you) and aliases (reactions to what you type) is done well and is fast. For some people you may have 100s of potiential matches on a incoming or outgoing line so you want it to be fast. After trying it out, my next reaction was "ok, so is it packaged in Debian?". To my surprise, it wasn't so the only obvious thing to do was for me to package it. It is now sitting in the NEW queue waiting for our ever-overloaded ftp masters to have a look at it. While the program is done well, as shipped it doesn't play too well with a Linux system. The package carries about 4 different other packages around. I've changed that now so it uses the system libraries and fonts. All of them are shipped in Debian and I'm sure they individually get more attention and love then I would give them being a sub-part of the main package. It of course cuts down on build times and archive sizes too. I still play muds, no matter what client. For me there they're fun on two levels. The first is the puzzles and gameplay of the MUD itself. I play some MUDs run by Iron Realms who continuously update them, giving you new challenges. The second level is the scripting and customisation you can do. Instead of typing "sip health" you can write some scripts to check your health level and get the script to do it. Mudlet (and a lot of other MUD clients) use the Lua langauge to do this scripting. It's a little funny language but is easy to learn and use. You won't be able to build some epic programs with it, but for scripting it is pretty good. Languages in Hunspell Mudlet uses the hunspell library for spell checking. I have, of course, linked it with the Debian library. The difficulty now is what language? I was surprised that when you intialise the library, you specify what language files to use right there. Now for me its simple, the english dictionaries should be used! What I don't undertand is if there is a way of determining the right dictionary globally for a user. I first though it would be one of the locale parameters, those LC_whatever fields. Mine is en_AU.UTF8, which there is no dictionary for as I'd use en_US or en_UK. I could possibly patch Mudlet and find a dialog box somewhere where you can set the language, but to me an environment variable makes more sense. Does anyone use the DICTIONARY variable, for example?

DebianNYC is having a Squeeze release/super bowl party this Sunday. It is in Park Slope, Brooklyn, and there will be both super bowl watchers and Debian installers/hackers who didn't know the super bowl was this weekend. For more information and to RSVP, see the wiki.Someone in IRC had the bright idea to have a "upgrade to half-broken testing" party in a few weeks. This sounds a lot more fun - and educational. We have been having so many events lately that I am a bit worried about having things too close together, so I guess we'll take it as it comes and people want to organize things. In the near future, we could have a Novice Night in Brooklyn, a Novice Night in the Bronx, a workshop on configuration management of clusters, and now this testing upgrade party.

It was completely non-obvious; In some cases I had to figure it out by reading kFreeBSD source code; I write it down here so it s not forgotten ;-) This is a short guide on how to boot Debian GNU/kFreeBSD via network on a diskless machine, using GRUB as the bootloader.

Step 1: Configure your DHCP/TFTP environment to load GRUB from network. See the PXE GRUB documentation for details.

Step 2: Rebuild kfreebsd-8 package with BOOTP and BOOTP_NFSROOT options, as described in upstream handbook. They need to be added to the debian/arch/*/*.config file for your architecture. This kernel can still be used for normal, disk-based boot, but it will issue DHCP requests to attempt network boot every time you start it.

Step 3: Put your kFreeBSD in TFTP directory and configure GRUB to load it. This requires only one command in grub.cfg. My setup:

set timeout=1
set default=0 menuentry Debian GNU/kFreeBSD
echo Loading kFreeBSD
kfreebsd /beastie/boot/kfreebsd-8.1-1-amd64.gz
echo Booting
boot

Step 4: Build a directory tree with your GNU/kFreeBSD userland, and export it via NFS. I copied it from an existing Debian GNU/kFreeBSD install, but I suppose debootstrap could do the job as well.

Step 5: kFreeBSD mounts root NFS in readonly mode initially, and Debian userland turns out to be very unhappy with that. If you want things to work you ll need to either setup tmpfs in a few places (e.g. /tmp) or adjust fstab so that / is remounted as writable by the INIT scripts. Example fstab line:

192.168.1.3:/srv/netboot/beastie / nfs rw 0 0

This, however, will only work if mount_nfs(8) is in your system. And (well, too bad) it hasn t been packaged yet. So you can copy it from a FreeBSD base tarball, along with its dependencies (/lib/libc.so.7, /libexec and /etc/netconfig).

Step 6: Finally the system boots, but you ll soon notice that file locks don t work. This breaks some daemons (rsyslog), dpkg, apt and possibly a lot other things. Actual (i.e. non-local) file locking on NFS requires a running lock daemon, both on client and on server. However, since FreeBSD lockd isn t packaged either, and you probably don t need global locks anyway, I suggest you disable it with nolockd mount option.
The tricky part is that as explained in mount_nfs manpage, nolockd will only be honored when performing the initial mount, and it will be silently ignored if used while updating the mount options. So fstab is not an option.
The only way I could find of telling the kernel to use arbitrary options when mounting / is by sending them via DHCP. Use the following options in your dhcpd.conf:

option option-130 code 130 = text;
option option-130 nolockd ;

Et voil . A Debian GNU/kFreeBSD system running completely in diskless mode. Enjoy!

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	574
Affecting Squeeze:	2
Squeeze only:	2
Remaining to be fixed in Squeeze:	0

Of these 0 bugs, the following tags are set:

Pending in Squeeze:	0
Patched in Squeeze:	0
Duplicates in Squeeze:	0
Can be fixed in a security Update:	0
Contrib or non-free in Squeeze:	0
Claimed in Squeeze:	0
Delayed in Squeeze:	0
Otherwise fixed in Squeeze:	0

Ignoring all the above (multiple tags possible) 0 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 2 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

Mutt mail indexing on steroids! I've been using external mail indexing with Mutt for quite a while now. Before now I haven't given Notmuch a try, as it seemed too much experimental at the time of my initial review of mail indexing tools. As there is nothing better than a long oversea flight to perpetrate new hacks, I've now not only tested it, but also switched to Notmuch without looking back at maildir-utils for a split second. Getting started with Notmuch is trivial:

• Notmuch is notmuch in Debian (and maintained by upstream author, thanks!)
• notmuch setup asks a few questions about the user and then prepare a template ~/.notmuch-config, which is good enough to start
• notmuch new does a first run of indexing (which might take a while, depending on the size of your maildirs)

Some performance figures: (1) the size of the index is a bit larger than the size of the mails (on my laptop: 535 Mb of index vs 375 Mb of mails stored in 60 maildirs); (2) even if the underlying indexing engine is the same (Xapian) as maildir-utils, Notmuch is much faster. With my setup it is so fast that I've added it as a hook triggered by offlineimap at the end of each synchronization:

    zack@usha:~$ grep -B 1 hook .offlineimaprc
    [Account Upsilon]
    postsynchook = notmuch new

With the big round of new mail downloaded in the morning, it hardly takes more than a few seconds to update Notmuch index, while with other periodic downloads Notmuch almost invariably reports "... in almost no time" (i.e. less than 1 second). Integrating Notmuch with Mutt The basic integration I want between Mutt and a mail indexer is the ability of stating a search query interactively and then jump to a fresh Maildir containing search results only. Additionally, given that Notmuch has neat thread reconstruction abilities, I also want to be able to reconstruct on the fly the thread corresponding to the currently highlighted mail: it comes handy when a thread has been split across different maildirs, archived, or the like. To that end, I've cooked up a little helper, called mutt-notmuch, that enables to trigger mail searches via a Mutt macro (F8 being my choice) and reconstruct threads via another (F9). Check the manpage for the 2-liner configuration snippet for your ~/.muttrc. Arguably, some of the logics of mutt-notmuch could disappear by adding support for a --output=symlinks flag to Notmuch. A bug report requesting that is pending: too bad oversea flights are not as good for accessing the Internet as they are for perpetrating hacks! Download

• mutt-notmuch - Notmuch (of a) helper for Mutt
• mutt-notmuch.1 (html)- mutt-notmuch manpage

The Mancoosi Team has recently published the details of a study we conducted analyzing different packages managers available in debian. The goal of this study was to compare MPM (the mancoosi package manager) to other legacy solvers and try to get a big picture regarding of the state of the art. A similar study was conduct during EDOS and the results are still available here. As I wrote few months ago, MPM is a proof of concept that we wrote to test the behavior of a number of solvers that have been developed for the MISC competition in a real world scenario. These results do not show anything new w.r.t. the experience of a lot of poeple dueling daily with their machines in order to install a new piece of software. In a nutshell, we have shown that apt-get, aptitude, smart and cupt perform pretty well when used only with one baseline (for example a stable release) : this conforms with the experience of the majority of users of debian based systems. However problems start to arise when a user start mixing more then one baseline putting a lot of stress on the solver in order to find a satisfying solution. This solution of course exists, but it is cleverly hidden in the dependency structure of more then 40K packages... MPM is not as fast as other package solvers (say 10 seconds for mpm, while apt-get is able to find a solution in 3 second), but is remarkably stable. It is always able to find a satisfying solution, even in the harder cases where all the other failed. In these experiments MPM uses the postdam solver aspcud. This solver uses only GPL components and it would be a good candidate for inclusion in debian (there are actually a couple of ITP already filled for clasp and gringo). The results (with a lot of details) are published on the mancoosi website (a more detailed report is in the works). Enjoy ! During fosdem the Mancoosi team that authored this work (Roberto, Ralf, Zack and Me) will be around, so, please stop us for a chat ! And don't miss Ralf's talk !!

So Debian 6.0 "Squeeze" is due to be released this weekend. I've been doing my part annoying the release team with various risky last minute changes for not-formally-RC bugs. The best of these was making kFreeBSD CD images be actually used by d-i. Which had been silently ignoring them (so nobody noticed), and then I "broke" it to at least complain that it couldn't use them, and is now entirely fixed. Anyhow, there are these Debian release parties planned in 68 locations worldwide, this weekend. I have never been to a Debian release party. The timing is never right. The nearest one is 6 hours away, so I won't be making the trip. But yesterday I had a crazy idea, and I seem to have done enough that I can't back out now. announcing the Debian Party Line mumble.debian.net is a mumble server. Mumble is a nice system for doing group voice chats. I will be hosting a kind of virtual release party there, on February 5th and 6th. We'll follow the progress of the release, maybe have some scheduled events (if someone wants to do a talk or tutorial session). And at the end we'll hear what it sounds like when we all get Squeezed. So, should be fun, assuming my servers don't melt down due to bandwidth use. Hope to chat with you there! Please visit its page for details and to RSVP.

Another year, another FOSDEM. Yay, I m attending again! The biggest open source event in Europe, with more than 200 conferences and 5,000 people.

This year I will be talking about KDE on Windows. Sunday, 10.15, CrossDesktop Room (H.1309). If you are interested in helping us with KDE on Windows development, in making use of KDE on Windows for your application, or just want to use your favorite KDE applications on Windows, then you should come.

For as long as I have known Mike, he s been maintaining one of the largest (and most widely used) package: Iceweasel, Debian s default web browser. It s effectively Mozilla s Firefox although it has been renamed to avoid some rules enforced by Mozilla s trademark policy. But we might see Firefox back in Debian read on to know Mike s plans. His story is also very interesting in that he went from simple user to Iceweasel maintainer, and now he s working for Mozilla Corporation. But you already knew that contributing to free software is a good way to grow skills and gain experience that are valuable on the job market, right? My questions are in bold, the rest is by Mike. Who are you? I am Mike Hommey. I am French, even if my name doesn t sound so. I have been a GNU/Linux user since 1995, using Debian since 1999, and started packaging in 2003. After a long time in the NM queue, I became a DD in 2005. The main reason I started being actively involved is quite selfish: I wanted some things done, and I just did them. My first packages were extensions for the Mozilla Suite, the old one that directly inherited from Netscape Communicator. Later on, I wanted some of these extensions to work with the new kid on the block: Phoenix; or maybe it was already Firebird. By then, integrating extensions was a hassle, and the mozilla-browser maintainer had come up with a script that would make it easier for extension packages. So I ported that script for use with Phoenix/Firebird and sent it to the BTS. Then Phoenix/Firebird became Firefox, and it grew a real extension manager. Except that is was entirely not suited for extensions installed by the packaging system. So I made it work better. And made a few more changes to make Firefox work better. All through patches or NMUs. Then I became co-maintainer, then Firefox couldn t keep its name and became Iceweasel, and, fast-forward until today, I m now taking care of Iceweasel/Xulrunner and Iceape in stable, unstable, experimental and an external repository. This 8 years-long story (wow, I hadn t even realized it had been that long until I wrote it) tells you something: newcomers shouldn t be afraid to stick their hands anywhere, even in big packages. I was only a Mozilla and Phoenix end-user when I started. Apart from Mozilla-related packaging, I also happen to (co-)maintain some other packages in Debian, most notably webkit, though I haven t been very active in the pkg-webkit team recently. There are several reasons for that, the main one being that there are other team members getting the job done. And I can t say that much about the pkg-mozilla team, since there are effectively no other team members. What s your biggest achievement within Debian? I am quite proud that Squeeze will be the first Debian release where Iceweasel works on all supported architectures. Previously, we only knew the package compiled on all these architectures. Starting with Squeeze, we know it passes several of the test suites coming with the source code. This ensures most of the browser is functional. It was actually far from being the case before, as it appeared when the test suites were first enabled. I think it is very important to have properly working packages on all our supported architectures. The current evolution of hardware shows how important it still is. Who would have thought a few years back that we would see ARM or MIPS based netbooks today ? What are your plans for Debian Wheezy? For Debian Wheezy, I would like to improve Iceweasel/Icedove/Iceape integration with the packaging system. Something that would allow to use the apt database to find extensions or plugins, on top of the current behaviour. I also want to improve desktop integration, most notably for KDE. Another thing I d like to see happen is to package google breakpad independently (its source code is currently embedded in chromium and iceweasel, though not built, as far as I know), and have our Mozilla products builds be able to send their crash reports upstream. It is very important that upstream gets direct visibility over what crashes on GNU/Linux systems. It helps making them aware of issues that would otherwise probably remain unnoticed, as there are much more users using distributions packages than upstream tarballs. And not all Debian users report crashes to the BTS. I know at least Fedora and SuSE are already doing it. More importantly, I want to avoid the sad situation we got with Squeeze, where we re going to release a 18 months old Iceweasel. We got there for a combination of reasons, one being that I was preparing for a freeze in December 2009 and focusing on getting 3.5 in shape instead of the then upcoming 3.6. The result was that we didn t get 3.6 packages before upstream released 3.6.3 in April 2010. By then it was too late, considering the uncertainty of the release schedule, to update reverse dependencies and get 3.6 ready for Squeeze. Things are different for 4.0. I m already getting ahead of things, and while reverse dependencies haven t been taken care of, all beta releases have been made available through http://mozilla.debian.net/, usually within hours after upstream release (sometimes even a few hours before official announcement, but always after availability on ftp.mozilla.org). A great share of our patches were also pushed upstream. Several things made that possible:

• I m now closely following upstream trunk
• I m starting to prepare packages when candidate builds are distributed upstream, which usually happens a few days ahead for betas, and more than a week ahead for stable releases.
• I automated part of the package building process, and have a beefy build machine. I m getting near being able to provide nightly builds of upstream trunk.

There will be a couple major upstream releases until Wheezy comes along, and I want to make them available early in unstable, even if that means breaking reverse dependencies until they are fixed. Finally, I would like to get other people involved, starting with the Icedove maintainer. Volunteers are very much welcome, for any kind of involvement: bug triaging, documentation (which we are deeply lacking), testing, code People interested can contact the pkg-mozilla team list. As the Debian packaging gets less time consuming, I should be able to spend more time mentoring, which should help. If you could spend all your time on Debian, what would you work on? I actually have been working almost full time on Debian for a few months during a more-or-less purposeful unemployment period. That s when I attempted to add an alert popup when Iceweasel or extensions are upgraded (which was eventually removed because not working very effectively). That s when I worked on Iceweasel 3.6 and the first 4.0 betas. That s when I pushed more than 70 patches upstream, and got upstream commit access. I know for a fact that keeping up with upstream and answering bug reports is already time consuming, and time comes in finite quantity. Working full time on Debian allows to do more than that, as I ve been able to experience first hand. Unfortunately, that doesn t help pay the bills, so it would be best if time could be shared with other persons. Like, actual members in the pkg-mozilla team. Anyways, if I were to work full time on Debian again, I d like to do more than packaging, and help improve some of our infrastructure, most notably the buildd network, to grow some automated way to get packages built on all or some of our architectures. Call that PPA if you want, though I don t think we need something exactly like PPA. We sure do have porter boxes, but there is a huge overhead to get packages built there: you need to first try, then see you lack build dependencies, then wait for admins to install them, then come back and launch your build, and finally come back again much later to see how it went. And that s when it goes smoothly. Repeat for each architecture. It s already cumbersome when it s a small package, so imagine when it s Iceweasel. I d like to be able to push a (signed) .dsc somewhere, say I want it built on that and that architecture, and get binary packages and logs back. It could then be up to developers to distribute them, or not. Sometimes, you re just interested in test suite results. Another related wish would be a way to access build trees of failed builds, possibly on the buildd where it failed. What s the biggest problem of Debian? Lack of contributors, lack of contributors, and lack of contributors. It can sound weird to say that in a community of 1000+ people. But the sad reality is that we ve seen, repeatedly, calls for help in various places from various understaffed teams (most often of effectively one member) for years. So there is obviously a problem getting people to invest time in these teams either on the long term, or at all. I know this is not a very significant metric, but it already should say a lot: I wouldn t be surprised if more than 2/3 of the number of source lines of code in Debian come from less than 5% of the number of packages in the archive, and see less than 5% of the DD/DM population involved. If someone feels like doing the actual math, I m curious to know how far I m from reality, and in what direction. We also lack manpower to be able to make our release development smoother. In a perfect world where manpower is not a scarce resource, we should work on $release+1 when $release is being frozen. Said otherwise, we should have been able to start working on Wheezy in August 2010, or even earlier. You ve been working for Mozilla Corporation for a few months. How does the work look like and what are you working on? I am actually not working full time for MoCo; I am only contracting for 4 days a week. That was a request I made to keep having enough spare time for Debian or other activities. I am working from home, and am pretty much free about when I work, as long as I work long enough. I take advantage of this freedom and the saved commuting time to live a healthier life by doing some sports in the daytime (which also happens to be cheaper). I mostly work with Taras Glek and other people on various aspects of Firefox startup performance. This involves pretty interesting low-level stuff, in which I actually got involved before being contracted. This work has nothing to do with packaging Iceweasel, though I can have a few opportunities to do things somehow related. You told in your blog that you were discussing with Mozilla how Debian could use the Firefox trademark. Can you tell us a bit about the progress you made? I have got an informal approval of the patches we are applying to the Iceweasel 4.0 beta packages. There are a few concerns about using the system cairo library, and the embedded copy of libpng needs to be used to have support for the animated PNGs that are used in the user interface and that are required in Firefox feature-set. Other than that, there are pretty much no objection on the technical side. We managed to get to some common ground as to how to manage stable updates and more generally, changes to our packages, but I m still waiting for an actual agreement draft. While I, as the maintainer, am fine with the way it should look according to my discussions with the people involved at Mozilla, I ll seek review from my fellow Debian Developers when I ll have something to show. I haven t decided yet how this will reflect on the Debian packages, though. For example, would Iceweasel stay? But I do hope Wheezy will get Firefox back. Is there someone in Debian that you admire for their contributions? Not someone, but all past, present and future release team members. This is a team that receives a lot of critics (and I indirectly gave one a few paragraphs ago), yet manages to keep doing an amazing job and its members are very committed to their task. I admire their dedication.

---

Thank you to Mike for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

8 comments Liked this article? Click here. My blog is Flattr-enabled.

I have submitted an talk about the Haskell programming language to the organizers of GNUnify, a Free Software conference in Pune, India, on 11th and 12th of Februrary, and they accepted. The talk will be similar to the one I gave to the FOSSEE group. If you are at GNUnify and want to exchange key signatures or chat, just talk to me.

I changed (once again) to awesome and AIR applications doesn t work here. One of the apps I heavily use based on AIR is TweetDeck. So I tried old clients that were once an alternative like HootSuite but not having support for both kind of RTs (Native and Quote) is a pain in the ass. Then I remembered I installed once TweetDeck for Google Chrome on my browser and never give it a chance, because it was not exactly the same as the AIR-based app. Now it only lacks proper relation between followers and no-followers in each account when there are multiple accounts configured. So yesterday was the day to try it, the right day. It even has notification support, and customized by column!

Hello I ve taken a step back and looked at the synopsis of the Config::Model man
pages. Boy, I m not proud of what I ve released. Except the ones I ve reworked recently, most of them are worthless. The next release of Config::Model will feature new synopsis. Each synopsis will contain a valid example that can be run with a cut n'paste in a test file. The code in the synopsis will actually do something visible. Here s an example extracted from the next version of Config::Model::Dumper:

 use Config::Model ;
 use Log::Log4perl qw(:easy) ;
 Log::Log4perl->easy_init($WARN);
 # define configuration tree object
 my $model = Config::Model->new ;
 $model ->create_config_class (
    name => "MyClass",
    element => [
        [qw/foo bar/] =>  
            type => 'leaf',
            value_type => 'string'
         ,
        baz =>  
            type => 'hash',
            index_type => 'string' ,
            cargo =>  
                type => 'leaf',
                value_type => 'string',
             ,
         ,
    ],
 ) ;
 my $inst = $model->instance(root_class_name => 'MyClass' );
 my $root = $inst->config_root ;
 # put some data in config tree the hard way
 $root->fetch_element('foo')->store('yada') ;
 $root->fetch_element('bar')->store('bla bla') ;
 $root->fetch_element('baz')->fetch_with_id('en')->store('hello') ;
 # put more data the easy way
 my $step = 'baz:fr=bonjour baz:hr="dobar dan"';
 $root->load( step => $step ) ;
 # dump data
 print $root->dump_tree;

Feel free to log bugs on Debian BTS or on CPAN RT if the next synopsis still have problems. All the best