The statistics of the "who wrote Linux x.y.z" series date back to at least 2.6.20. According to my experience talking with users and Free Software enthusiasts, those statistics really make a dent in the public perception of who is giving back upstream. Obviously, one should not take a single upstream, even if it is as important as the Linux kernel, as a measure of how much a given Free Software entity is giving back upstream overall. But users still seem to be fascinated by them. As a result, I have often had to answer the question: why Debian doesn't show up on those statistics?. My answer has always been something along the lines that Debian Developers who maintain Linux kernel packages, the almighty Debian Kernel Team, do that mostly as part of their volunteer engagement in Debian. As a consequence, they do not earmark their contributions as if they worked for a company and they add up to the hobbyist count instead (although you can you can routinely spot individual Debian Kernel Team members among the most active contributors for specific Linux releases). The above is the true and honest answer. But every time I've given it, I couldn't help feeling that the user who asked went home with a "yeah, well" afterthought. If you don't want to take my word of it, fine. Here is what Greg K-H had to say about Debian contributions in a recent blog post about the stable Linux kernel:

I would personally like to thank the Debian kernel developers, specifically Ben Hutchings, Maximilian Attems, Dann Frazier, Bastian Blank, and Moritz Muehlenhoff. They went above and beyond what any "normal" developer would have done, ferreting patches out of the kernel.org releases and the different vendor kernels and bug tracking systems, backporting them to the 2.6.32 kernel, testing, and then forwarding them on to me. Their dedication to their user community is amazing for such a "volunteer" group of developers. I firmly believe that without their help, the 2.6.32 kernel would not have been the success that it was. The users of Red Hat and SuSE products owe them a great debt. Buy them a beer the next time you see them, they more than deserve it.

I'll take good care of following his wise advice. Please do the same.

---

(Thanks to Sylvestre for pointing me to Greg's blog post.)

OK, not really... DRBD 8.3.7 is an official part of the Linux kernel since 2.6.33, and thanks to Dann Frazier we also have a backport of that patch in Debian's 2.6.32 kernel as well.

Until yesterday, the DRBD source package in Debian built a -utils and a -source package, the latter was now dropped. From now on, users no longer need to recompile the DRBD module after a kernel upgrade.

HP announced support for Debian 4.0 ('etch') on ProLiants today. See the HP/Debian page for details.

Users of subversion may have noticed that the svn_load_dirs script was removed from Debian due to a lack of a license from upstream. So far, attempts to get a DFSG-free licensed version have failed, so I've begun a new python implementation that is licensed under GPLv2. 0.1 is functional and uses the same syntax as the original, but is missing a few features that prevent it from being a drop-in replacement. I hope to remedy this in the coming weeks.

I've been working with RPM macros quite a bit lately, and I've noticed some interesting properties. Though mostly obvious after the fact, they are surpisingly underdocumented. Macros don't seem to deal with floating point values. This works:

%define five 5
%if 0% ?five  <= 5
  %define string A
%else
  %define string B
%endif

While this causes a parse error:

%define five 5.3
%if 0% ?five  <= 5
  %define string A
%else
  %define string B
%endif

Quoting integers makes comparisons lexical. This will evaluate to false:

%define five 5
%if "0% ?five " == "5"
Perhaps the most frustrating one for me was that commented out macros are expanded. This has surprising results if your macro expands to multiple lines. Say my spec file includes the following:
%description
#%foo                                                                           
blah

And foo happens to expand to multiple lines:
%define foo one\
two\
three

My description will end up being:
Description :
two
three
blah

Andrew, I bought those wootoff lights as well, and have them connected to a hub on my mythtv system so I can activate them with a remote. I use the hub-ctrl.c utility from this page with this simple wrapper script that searches for the hub:

#!/bin/sh
bus=$(lsusb   grep TUSB2046   cut -d' ' -f2)
dev=$(lsusb   grep TUSB2046   cut -d' ' -f4   sed 's/:$//')
port=4
hubctrl=/home/dannf/hub-ctrl
if $hubctrl -b "$bus" -d "$dev" -v   grep "Port $ port :"   grep -q power; then
  toggle=0
else
  toggle=1
fi
$hub-ctrl -b "$bus" -d "$dev" -P "$port" -p "$toggle"

Note that not all hubs implement the port power feature - but luckily I had an unused one laying around that does. Unfortunately, one of my lights won't spin unless the physical power switch on the light is toggled - hopefully that's not true for yours.

svn-load, a DFSG-free replacement for svn_load_dirs, is now in unstable. John Wright has been working on adding support for doing preset pattern-based moves, which I hope will be ready in the next upload.

I suffer from an in ability to successfully monitor multiple sources of information. For example, I rarely check on lists that I have procmailed out to their own folder. If its a list I need to stay on top of, I have to dump it to my primary inbox. For one list, I even dump messages to my inbox *and* keep a copy in a subfolder. That way I can keep on top of what's going on, but also keep a low-barrier-to-delete since I know I have an archival copy. I do think its important for me to check e-mail regularly, but there is some part of my brain that considers e-mail to be a time sink, and prevents me from going beyond what it considers the bare-minimum: Inbox messages. Another instance of this disorder struck me with RSS. There are web pages that I check every day, and not all of them have RSS feeds. I played with a few different RSS readers a while back, and decided that straw was my favorite. But I could not get myself in the habit of bringing up a second application. Later I started using Firefox, and I thought I'd have better luck with something like Sage. But even that was easy to avoid because it requires actually opening up the sage panel. I would either never check it or, in times of boredom, check it too often. Since then I've given up on RSS readers. These days I've stolen an idea from Alex Chiang and just keep a bookmark folder called "daily" and one called "monthly". Every morning I hit the "Open All in Tabs" item in the daily folder, and quickly ctrl-w through pages w/ no new content. My daily folder includes things like bug reports I'm monitoring for activity, gitweb views of files where I'm waiting for a fix, blogs, parcel tracking, comics, wiki watch lists, etc. Since a few of these pages are rather important, I always remember to do it and therefore force myself to browse the others as well. Most days I spend less than 10 minutes "wasting time" going through them. Its strange to both be aware of poor working habits, yet know from years of experience that I'll be more successful if I work around them rather than trying to retrain myself.

A new version of kernel-package in Incoming at the time of writing adds support for creating a package which contains the Linux kernel debug image. This means the debugging information for the modules in the kernel image package, and the uncompressed vmlinux image. This builds on suggestions and code from Troy Heber, Theodore Y. Ts o, and Dann Frazier. As support for kexec/kdump support becomes more real, it will be very useful to be able to build kernels that have debugging information available, but not necessarily to install the debugging information on every single client system. The .ko object files are stripped of the debugging information before they are placed in the standard linux-image installation package. However, before that, a copy of the vmlinux and unstripped .ko files are saved in a debuginfo package, and everything except for the debugging information is removed from them using objcopy --keep-only-debug. This means that if someone ends up with a crash dump, they can send it to a support engineer and only the support engineer needs to install the debuginfo package and use the crash utility to debug the crash dump. It s also useful for developers, since the debuginfo information can be stored somewhere outside of /lib for storing its debug information, for example. This is useful for keeping the size of the root partition small, for those who keep / separate from /usr. The locations used are compatible also with SystemTap, which provides free software infrastructure to simplify the gathering of information about the running Linux system. This assists diagnosis of a performance or functional problem. SystemTap eliminates the need for the developer to go through the tedious and disruptive instrument, recompile, install, and reboot sequence that may be otherwise required to collect data. Also, I had to clear out some FUD about kernel-package from the ircbot dpkg on the OFTC Debian IRC channel, since someone had implied that kernel-package was some how obsolete. As can be seen, it is being actively developed, and features are being added apace.

HP has posted a capabilities matrix for Debian 5.0 ('lenny'). Its linked off of the easier-to-remember url: hp.com/go/debian.

Here's a shell script I wrote to stuff non-free firmware bits into an existing lenny installer image. It currently can operate on either a initrd.gz file or an isolinux-based iso image. I've only tested it on a netboot initrd.gz and a netinst iso, but it should work on larger images as well. If you need support for some other media type or architecture, let me know.

Continuing with my mission to control the power to some dumb USB-powered lights... Dann Frazier confirmed my theory that a USB hub would indeed do the job. I'd already found the hub-ctrl.c program he mentioned, but couldn't get it to work with my built-in USB ports of my laptop. It seems it all depends on whether the hub will support per-port power switching or not. (lsusb -v will tell you). So off to the mighty institution that is Fry's Electronics I went. The first two attempts failed, as did a borrowed hub. It seems most (at least the cheap one) use a Genesys Logic chipset, which does not support per-port power control. Fortunately I chose products that weren't in blister packs, so I was able to return them to Fry's in as-new condition and try again. Now that I knew USB hubs would do the trick, I did some more targeted searching, and found this thread where someone had been messing around with hubs to do what sounded like what I wanted. (Incidentally, this email in the thread also provided a nice looking Python program. I'm going to look at refitting it to use the "real" Python USB module.) I emailed the poster to ask him what brand of hub he was using. The answer was the Linksys 4-port hub So I managed to track down one of them last night. Yes, it works, but the downside is the hub itself requires external power, which is a bit unfortunate. Not only do I need to use a hub to make these lights software controllable, I have to plug the hub into a power outlet. Bleh.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

I needed to query a card to get its permanent mac address (the value programmed into the card, even if the admin has ifconfig'd it differently). This can be done with the linux kernel's ethtool API, but the ethtool command doesn't currently support it and google didn't know how either. I had to figure it out myself. Now google, you no longer have an excuse - I expect you to know next time I ask.

We escorted Sarge to its last home. 3.1r8 is done, thanks to all the people who made it possible. A big thanks goes to James Troup, our ftpmaster of the day doing all the grunt work of getting a new point release out of the door. To bring in a more personal feeling of who makes this all possible, here is a list of people contributing uploads to 3.1r8 (mostly people from our fabulous Security Team):

• Alberto Gonzalez Iniesta
• dann frazier
• Darren Salt
• Devin Carraway
• Florian Weimer
• Gregory Colpart
• Julien Cristau (who is glad that he finally got rid of xfree86)
• Luk Claes
• Martin Pitt
• Michael Koch
• Moritz Muehlenhoff
• Noah Meyerhans
• Patrick Schoenfeld
• Roland Mas
• Russ Allbery
• Sean Finney
• Steffen Joeris
• Thijs Kinkhorst

I would also like to thank dann frazier, Luk Claes, Martin Zobel-Helas and Neil McGovern for helping with the preparation of the point release.

2.6.24 kernels targeted for etch are available for testing in etch-proposed-updates. Some architectures are missing for this first upload, but fixes are pending for the next upload.

Last week I did again some work on nagios-plugins. After the announcement of Dann Frazier to upload NMU to fix a trivial bug, I thought it’s time again to give some extra care to the package. So I prepared 1.4.11-2 fixing the important bugs and uploaded it. I also commited some minor fixes to the svn, so these issues will get fixed by the next upload. Since the development of policyd-weigh stalled and unfortunately maybe get stuck, I was looking for an alternative, which maybe found with postfwd. It’s quite flexible but it also will take more time (and care!) to get a reliable configuration, which maybe effective as policyd-weight (still) is right now. While checking the dependencies for postfwd I noticed that Net::DNS::Async isn’t available in Debian (yet). So I decided to create a package starting with dh-make-perl, join the Debian Perl Group and let it review. Damyan Ivanov was so kind to review and upload it, Gregor Herrmann did also give some much useful hints. Thanks to both! And yes, I also found time to step forward with NM, since I was overloaded the last weeks with usual work and life. Thank to my AM to be so appreciative.

For those unfamiliar with the project, etch-and-a-half has the goal of making the existing etch release work on more hardware, but with minimal risk to existing etch users. This will be done by *adding* new kernel packages to the existing release. Kernel selection isn't final yet - the kernel team would like to use 2.6.24 if it proves itself stable in time; 2.6.22 is the backup choice. etch-and-a-half isn't restricted to kernel updates by-definition; new X drivers, or proven-safe X driver updates are reasonable candidates as well (though at this point, no changes have been proposed). An oft-asked question is around updating desktop packages, e.g. new versions of GNOME/KDE. This is beyond the scope of etch-and-a-half because it introduces a great deal more change than just additional hardware support, its wouldn't be a transparent upgrade to existing etch users, and we cannot say with a high level of confidence that it wouldn't introduce regressions for existing users. That said - a localized change to a package that adds support for new hardware and clearly doesn't break existing hardware is a valid candidate for any stable release. Such requests should be submitted to the SRM team like any other stable update request. The current plan for etch and a half is to release as part of a point release. 4.0r4 is the planned point release, since 4.0r3 is planned to have a quick turnaround to fix issues with 4.0r2. This means that pre-release bits will be made available via proposed-updates - testers are greatly appreciated. There is no plan to add support for etch-and-a-half to the etch branch of d-i. Rather, support will likely be added in a beta of the lenny installer. A wiki page exists here, and a coordination list has been setup on teams.debian.net.

There have been several long-term wishlist bugs on Mutt to include the (in?)famous "sidebar" patch. It adds a panel on the left side of the screen to list mailboxes with message counts. We do ship several patches with Debian's Mutt package that are not considered for inclusion by the upstream authors, but this one is different. It touches the core of the UI renderer and adds extensive counting of messages. There's been quite a hype about the patch, it was even included in the (now discontinued [1]) mutt-ng fork. Unfortunately, the patch was technically questionable, it was written for the Mutt tarballs and didn't easily apply to CVS, and most versions floating around contained lots of cruft like backup files and temporary editor files. Furthermore, it is far from bug-free and even segfaults occasionally. Some months ago we decided we would build a second binary package to put the patch in so we don't destabilize the standard package. Thanks Dann Frazier, we got a clean patch, Adeodato had the right idea on how to build two binaries from the same, differently-patched source (make install would run havoc, the trick was to build the patched version before the regular one), and I resolved some more involved conflicts with the maildir-mtime patch. So, finally, there it is: mutt-patched. Disclaimer: As said, there are bugs. YMMV. On related news, there's now also a -dbg package now for the victims of the IMAP and header cache segfaults that we still see sometimes. Update: The sidebar patch was not the reason for the creation of mutt-ng, but many mutt-ng users were using it because of this patch. Update 2008-01-08: [1] mutt-ng used to be a Mutt fork. It is now maintained as a patch collection for Mutt.

Adeodato mentioned using ctrlproxy, so I thought I'd ramble a bit about my experience w/ IRC proxies in general. dircproxy was the first IRC proxy software I tried. It did the job, but the thing that annoyed me the most was that only one client could connect at a time. I'd get home and realize I was still connected at work, and then have to login and send a kill signal to xchat. When I found out about ctrlproxy, and that it supports multiple clients, I was very excited. It did the job, but occasionally it would hang and need to manually killed/restarted, and it had this weird problem of writing logs for one channel to the log file of another. Most recently (and for probably a year now) I've been using bip. I immediately hit an issue with one server - bip would constantly reconnect/disconnect. Upstream immediately went to work on the problem, determined it was a bug in the server itself, and (iirc) sent the server maintainers a patch. Now that's support! bip has been stable for me for nearly 2 years now. I'd also suggest comparing the bug pages for dircproxy, ctrlproxy, and bip. That's not always a good way to measure relative stability, but it resembles my experience in this instance.