(update: yesterday's version was using http://wiki.debian.org/Teams/ReleaseTeam as reference, while http://www.debian.org/intro/organization is the one that's up-to-date. Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!)...and Martin zobel (who's apparently forgotten on the page). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, luk, HE). Hat off, guys (only guys there, yet another place for d-w to show up).

Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, HE). Hat off....

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.

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.

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.

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.

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.

I am playing with the thought of using IMAP to send email from my mobile clients. The way this works is that mail is actually placed into a Maildir locally and synchronised with the IMAP server using a tool such as offlineimap. The Courier IMAP server supports such an outbox feature, for other servers you can use inotify or a cron job (I am planning to publish a writeup about my new mail setup sometime soon, so no scripts linked here yet). Anyway, it's trivial to get it working, and Dann Frazier has written it all up. The question is more whether I want to, or not. I am soliciting feedback. The advantages of using an IMAP-synchronised outbox are:

• The ability to review all mail to be sent while still offline. Using mutt, you can even edit them after "sending" but before they are actually sent. Undoubtedly, doing this often should be a hint to take more time before sending a message. However, at times there are good reasons why one might want to change a message which was composed e.g. on the plane (or not send it at all), and having to remove the message from the MTA queue and recreate it with the desired changes is unnecessarily time-intensive.

• Wherever you may roam, you can send mail even if port 25 is blocked (provided that the IMAP or SSH ports are open).

• All your mail is sent by a single host, so you don't have to worry about blacklisted IPs or disclosing information about your whereabouts.

• It's trivial to post-process mail, including training spamfilters with it (as ham) through a server-side pickup script, as well as e.g. checking for missing attachments locally (you need a local sendmail script for reasons documented here).

Any solution with advantages comes with disadvantages, and these are:

• Added complexity and brittleness: having mutt pipe mail to a custom sendmail-replacement script, which puts a message in place for synchronisation with offlineimap, and a server-side cron-job calling another custom script which pipes the mail(s) to be sent to the real sendmail binary all just seems a little less trustworthy than good ol' postfix delivering mail via a TLS-encrypted, client-cert or SASL-authenticated SMTP channel to a known mail relay.
• It's non-trivial to get meaningful notifications in case delivery of a message failed.
• Messages are only sent after IMAP synchronisation carried the mails to the server and the server-side pickup process sent them on. In my setup, this could introduce a delay of 30 minutes even when online, which may be rather undesirable in urgent matters. On the other hand, such delays could easily serve to reduce stress levels (I realise that's not a problem with a technical solution though).

Can you think of any other advantages or disadvantages? Do you use an IMAP-synchronised outbox and would like to share your experiences with me? Or do you have yet another solution? Write to me! NP: OSI: Free

Last night I decided to install etch on my pre-built MythTV system. The process is documented here

I recently learned that HP updated their Debian compatibility matrix to include Debian 4.0 a.k.a etch (which is obviously great, and I hope more major vendors would include this type of compatibility information.) Clicking around, I find it somewhat funny that if you go to the certification information for Red Hat or Novell SuSE (now there's a great name slowly dying...), you'll find a Debian logo, a Red Flag logo and a Mandriva logo. But no Red Hat or Novell/SuSE logos. Do they want their customers to try Red Flag, Mandriva or Debian instead of the Big Two(tm)? Because on the Debian page, there's no Red Hat or Novell/SuSE logo...

This FUD is not spreadable, but it does make… , and was previously noted in Mexico last year.