I have never felt inclined to create content for Youtube due to the low resolution of the display and the fact that only one format is supported (Flash which is totally non-free). The existence of blip.tv has inspired my interest in creating videos for distribution on the net. blip.tv has higher resolution than Youtube and supports multiple formats. Currently the multiple format support is limited to allowing users to upload whatever they want and then Flash (FLV) will be provided for download in addition to the original file(s). So for example I could upload MPEG4 and Quicktime movie files for the same content which would result in three download options (MPG, MOV, and FLV). It would be nice if they could support more formats as the default (maybe support transcoding to OGG), but it s certainly a lot better than Youtube. So the question then is how to create content. One option that I plan to use is Istanbul - the GNOME desktop session recorder [1]. It will record everything that happens on the desktop (or a section of the desktop) to an OGG file while also optionally recording audio input. This allows the creation of tutorials for performing various tasks on the computer. Another option is to do animation, either completely computer generated or by combining a set of JPEG files into an animation file. This doesn t interest me to the degree necessary to make me invest the necessary time. But the most common way of producing video content is via a camera. So the question becomes what camera to get. My current camera is a Sony Cyber-shot DSC-T5 [2]. It is a 5.1 mega-pixel camera with 3* optical zoom and supports 640*480 resolution movies at up to 30 fps. The quality of photos and video that it produces seems to be quite good, I don t have any particular problem with the camera that I want to address by purchasing a new one, so a major aim of buying a new camera was the fact that it s a few years old and something better must be available at a low price! I asked for advice about this on my local LUG mailing list. One piece of advice that was offered by several people was to use a Digital Video camera with Firewire output to record quality video. They spoke about common digital cameras as point and shoot with the acronym P&S - which seems to be used as a term of abuse by people who are really into cameras. If using a DV camera with Firewire support (which is apparently a really important feature) then apparently Kino [4] is the program to use to capture the raw video data. While the advice in regard to a digital video camera sounds good I m not going to take it. Such DV cameras start at about $300 and appear to be physically larger. While a larger camera (with a larger lens) will give better quality pictures and higher frame rates with lower levels of ambient light I am planning to do my serious video recording in a controlled environment with reasonable lighting. Really I m not THAT serious about video recording, so I don t plan to spend $300 or more - I ll accept the lower quality as a trade-off for lower price and greater convenience. I have seen an advert for a camera described as a DC-777 at a good price from DirectBuy.com.au [3]. The camera in question is one that has no reviews anywhere on the net and seems to be a re-badged version of someone else s camera. It initially sounded quite good with 11mega-pixel resolution, but the fine print shows that it has a 7MP CCD and uses interpolation to get a higher resolution. Also the movie capability is 640*480 at 30fps (the same as my Sony). So the benefit of using the DC-777 would be the rotating display which can face the same direction as the lens thus allowing someone who is making a video of themself to see what they are creating. This doesn t seem to be $200 worth of benefit, but the camera might be a reasonable deal for someone who doesn t already have a decent P&S digital camera. Another interesting piece of advice I received from my local LUG was that the amount of time taken to get a good image (which determines the shutter speed on a good camera or the maximum frame rate for video) is determined in part by the size of the elements in the CCD. So with all other things being equal a camera that supports higher resolution will require longer exposure. For my use the benefit of higher resolution photos is often for the purpose of cropping pictures of objects that were too far away to allow completely zooming in. 3* optical zoom (as implemented in my current camera) is a limit when photographing objects that are far away in good light conditions (in poor light it s often a factor of the lens size). In the past when looking at digital cameras I would make the resolution of the picture the prime criteria - with the idea that bigger is better. But now it seems that the smart thing to do is to make optical zoom the prime criteria for general purpose camera use. Also having a larger lens is a significant benefit, but as the overall volume of the camera is going to be roughly proportional to the radius of the lens cubed it can t get that big without some serious compromises on portability. Obviously an SLR [5] offers significant quality benefits. But if you are unwilling to spend so much money a good result can be obtained by what are sometimes called Big Zoom Digital cameras. These are cameras with a body shape that resembles a SLR, they vary in size between the P&S cameras and SLRs, and have fixed lenses that are significantly larger than those of P&S cameras. I gave such a camera to a relative for Christmas and I was very impressed by the quality of pictures and movies that it produced. I chose a Kodak camera with 12* optical zoom which was quite impressive (unfortunately the 15* model had sold out). One of the benefits of a Big Zoom Digital camera over a DSLR is that as there is no option to replace the lens there is also no possibility to get dust inside the camera (which is apparently a problem with SLR cameras). For my own use I plan to stick with my Sony Cybershot. I can t get anything significantly better for an amount of money that I am prepared to spend, and I also don t really want a larger camera. So I think I ll buy a tripod (or maybe two tripods of different sizes), that should deliver a real benefit for my photography without costing much. Update: One thing I forgot to mention is the film speed rating (AKA the ISO number) [6]. A higher ISO number means that the camera can take faster pictures in less light. The Wikipedia page reports that camera manufacturers are permitted to interpret the ISO scheme in several different ways, so they can essentially just make stuff up. Probably the best that can be said for the ISO number is that any camera which advertises it is aimed at more serious users and is therefore likely to be of higher quality. I m sure that if I was to spend $700 or more then I would get a camera with an advertised ISO number that actually means something, but I don t have any plans to ever do that. Matt made a good comment that the quality of the glass matters. For an SLR you can consider the lens quality independently of the quality of the rest of the camera. But for cheap cameras it s just a matter of the entire package.

• [1] http://live.gnome.org/Istanbul


• [2] http://www.dcresource.com/reviews/sony/dsc_t5-review/


• [3] http://www.directbuy.com.au/moreinfo.php?txt_itemcode=DC-777&txt_searchstring=DC-777&txt_from=3&catcode=45


• [4] http://www.kinodv.org/


• [5] http://en.wikipedia.org/wiki/Single-lens_reflex_camera


• [6] http://en.wikipedia.org/wiki/Film_speed

This code allows unattended ssh(1) processes, like the ones started by cron(8), to access the SSH keys stored by a running ssh-agent(1) (which will probably have been started in a screen(1) instance). Be sure to understand the security implications of persistent ssh-agent processes and passwordless keys.

#!/bin/sh -e
import_ssh_agent()  
  local pid
  for pid in $(pgrep -u "$LOGNAME" -x -f /bin/bash); do
    local var="$(grep -z '^SSH_AUTH_SOCK=' /proc/$pid/environ   true)"
    [ "$var" ]   continue
    eval "$var"
    export SSH_AUTH_SOCK
    break
  done
 
[ "$SSH_AUTH_SOCK" ]   import_ssh_agent
# now the script can run commands like:
ssh -o BatchMode=yes hostname command

I've been fooling around with "git" lately - it's useful for local projects where I don't want to have to set up a remote server, and it also seems to be "the way the wind is blowing" - lots of open source projects are starting to use it, so I might as well familiarize myself with how it works. The github service seems to be very popular at the moment, and it's not hard to see why. They've created a very useful service, and give it away completely free for open source use. That's a pretty good deal! It's also an easy to use site that's well integrated with git, so you can see lots of stuff graphically instead of fooling around with command line tools. However, I have a nagging doubt. Github apparently bases everything around the developer. In other words, projects hosted there are mostly attached to a developer who 'owns' the project, rather than existing on their own. There are a few exceptions - there seems to be a 'rails' role account to manage Rails, rather than having it belong to, say, DHH, so it's not impossible to do something in a project-centric fashion, but it doesn't seem to be very common either. What I'm wondering is what sort of effects this might have in the long term. Github, and git itself, make it very easy to 'fork' projects. Could, or will this lead to a situation where people don't try so hard to get their code in the 'official' branch? What happens when someone loses interest in their project? Sure, someone else can fork their repository, but if all the links were pointing to the first guy, because he was the main hacker on a project for X years, they're not going to switch overnight even if guy B takes over maintanance. And in the meantime, casual searchers might turn up the 'dead' branch, or simply be confused as to who's doing what. This could make things confusing for someone who just wants to check out some code and start using it.... trying to sort out various revisions and ancestry of a project could be quite discouraging. At the Apache Software Foundation, on the other hand, people are obviously very important, but projects are the organizational unit that people get involved with, and a lot of emphasis is placed on not having one big benevolent dictator, but on having a group of people who make decisions and act as arbiters of what goes into the project. People can come and go as they please, but the project, and, importantly, the links to it, remain the same over time (barring any big, unforeseen blowups). As far as I can tell, this is not a git problem, but something related to how github organizes their site. And, of course, it's possible that I have simply missed something due to my lack of knowledge of git, and not being more than superficially familiar with github. Even if I'm right, it shouldn't take that much effort for github to create a system where it's possible for multiple people to 'own' a project.

...and there was a distinct feeling of deja vu. At least the procedure itself was nowhere near as long (under 2 hours). On Thursday, Sarah had some day-surgery to have her sternal wires removed. The top one was causing her some discomfort because the skin there was the thinnest (whether that in itself was related to any of the previous incision complications remains uncertain). The surgical team popped in to pre-op to autograph their work (seriously, they initialled her chest) before they started, and asked if she wanted just the top wire removed, or all of them. We consulted the Magic Eight Ball application on my phone, and it gave a resoundingly affirmative response, so she got them all removed. Despite removing them all being a bit more surgically invasive, I think this is for the best. It means none of the other wires can cause any problems down the track requiring yet another trip to the operating room. They also did some scar revision on the top part of the scar, where it was a bit stretched (from the previous complications), so incisionally speaking, she's had almost as much incision work done as the original heart surgery. Ironically, this made the plastic surgery (laser treatment and steroid injections) she had late last year largely redundant. She took the dressing off the incision this morning, and we had our first look at it. It certainly looks a lot better than before, so fingers crossed it won't get infected this time, and the overall long-term result will look better.

Ever wanted to get a nicer console font than the default one delivered with Debian? First you need to get a nice font. I chose console-terminus:

$ sudo aptitude install console-terminus

that alone won t change anything but install a whole bunch of new fonts into /usr/share/consolefonts/. To enable one of them, you have to edit /etc/console-tools/config:

set SCREEN_FONT=Uni3-Terminus16

Optional: comment out the following lines with SCREEN_FONT_vc*, so every terminal will have the same settings. To test the new font:

$ sudo /etc/init.d/console-screen.sh start

The new font kicks in at the second half of the boot process, which is fixable but sufficient for me. I think the new font is much easier to the eyes than the default one, especially on big monitors with high resolutions.

Sarah came up a great idea for us to do over the long, long weekend after New Years. She wanted to go to the Grand Canyon, and hike in it. I, also enjoying hiking trips, went along.

We organized the trip rather late, I think on the 27th of Dec from my parents house (I think my mom enjoys being around for trip planning since it reminds her of the trips she should plan). Given our late planning we could only get a reservation at Phantom Ranch for the night of the 1st. So the trip plan was get back to SF on 30 Dec 2008. Take bart from the airport, sleep/pack (in either order), then drive to Williams, AZ on the 31st. Take a bus the to Grand Canyon on the 1st, hike down to Phantom Ranch, sleep, hike back up to the top, see the Grand Canyon from the top. Take a bus back to Williams and drive somewhere near the Hoover Dam. Sleep. Drive, see the Hoover Dam, get to Las Vegas, and see the Cirque du Soleil show Ka. Sleep. Drive home.

So that was the plan, now for the execution. We got back to SF on time and picked up our bags from the baggage claim without any issue. The next morning we got up and moving. The optimistic hope was that we would be on the road by 8am to Williams, then stop in Fresno for gear and food. It turns out we weren't ready to go until 10, so we got hiking poles and fake crampons at the REI in SF. We also did our grocery shopping in SF. We were on the road to Williams by noon. We shared the driving Sarah took the parts with traffic, I took the 4 and two lane highways. The fortunate part about this is that I drove through the San Joaquin. One the way there, it was basically IFR conditions (I had no instruments), so I was driving through a cloud (some call it fog) and I couldn't see anything that wasn't on the road. It was really pretty but not the best for a road with lots of ups, downs and turns. I felt like a race car driver. The other interesting part (at least while I was driving) was going through the Mojave desert at sundown. I don't think Sarah has any pictures, but it was very pretty.

Finally we arrived in Williams, AZ and got to the Grand Canyon Railway Hotel, at 2345hrs, (for those counting that means we were on the road for 10h 45m). We checked in by 2358hrs on 31 Dec 2008. So we stood by the fire for two minutes, counted down, and kissed for New Years.

In the morning, things went as expected, we backed our bags to hike 10 miles, and put the rest of the stuff in the car. We got in a van that took us to the Grand Canyon. Our driver up to the Grand Canyon was very nice and showed us the sites along the way. We also met two Japanese exchange students on their way to see the Grand Canyon.

On the way was slow since we took a lot of pictures (Sarah has them all since I lots my 1GB SD card before it made its way into my camera). Unfortunatly, Sarah got tired on the way down, and also hurt her ankle. So we stumbled our way to Phantom Ranch around 1600. From the time we got to the ranch until supper at 1830, we laid back and relaxed, we needed it, our feed were sore and Sarah iced her ankle. The food at Phantom Ranch was good, not great, and there was enough of it after being on our feet all day. At end end of the day, we slept, as planned. In the morning we got up for the early breakfast. Again, it was decently, but not great, but there was enough food. Unfortunatly, Sarah was sick (She'd figured out how to deal with her ankle though) (Oh, and she isn't pregnant). So we harrassed the rangers, got some imodium, and started on our way back up the Bright Angel Trail, we took the Bright Angel Trail down and were planning on the South Kaibab trail up but the Bright Angel Trail has places to stop the South kaibab trail doesn't. Again were were planning on an early 630hrs start, but started a little later at 745hrs. We used our poles with gusto on the way back up and made it up by 1345, 6hrs on the way back up, the same time it took us to get down. The rest of the daylight hours was spent taking the village bus around the Grand Canyon village and seeing the sights from the top.

After the Grand Canyon, we drove to Kingman, stayed there, then continued on, saw the Hoover Dam, it is like Itaipu, but less political and taller, then went on to vegas. In Vegas we saw the inside of a couple hotels, I spent $1 on a slot machine, then we say Ka. Ka is an amazing show, I don't think it really suck in until after the show was over all the things the performers pulled off. That said, the stage itself was an engineering marvel that I watched almost as much as the performers.

After Vegas, the drive back was mostly uneventful, the fog in San Joaquin was a little lighter, but still heavy, Mojave is prettier at sunset and it is still good to sleep in my own bed.

Yesterday evening I received a quite nice mail - the people behind Linux New Media and the LNM Award asked me if I want to participate in the Jury for the 2009 edition of it. Sure I want. :) The process seems to be a very simple one (good), the Jury members make nominations for the various categories and then later on vote on them. Now, while I already thought about it and know candidates I will nominate, what about you? I list the categories for this years edition below. Do you think something/someone/whatever should be nominated in those categories? Why? Note that only products/projects/people/organizations/whatever that have been very significant in 2008 should be nominated. This editions categories are - Outstanding Contribution to Open Source / Linux / Free Software

• Most Linux / Open Source-Friendly Hardware Vendor
• Most Innovative Open Source Project
• Best Open Source Contribution for Mobile Devices
• Best Open Source Programming Language
• Most Significant Contribution for Security in Open Source

If you want, feel free to tell me what you think should go in those categories. Leave a comment here or send me email. If you also add a little reasoning why, even better.

After lot of development, I finally decided to release new testing release of Gammu. The biggest changes are in SMS daemon, which got lot of improvements and is now in separate binary gammu-smsd. It can log better (support for syslog and Windows Event Log has been added), it can work as a proper daemon or Windows Service, it can be debugged easier (Gammu logs go to same log as other messages, SQL queries can be logged), can reload configuration on the fly. In libGammu, debugging has also improved (you can now use callback to process messages), some memory leaks were fixed and some minor bugs has been fixed. Command line interface now supports text for text messages to be entered through parameter and not only using standard input, it has a new command chekfirmware which obsoletes UsePhoneDB configuration option and other bug fixes has happened, for example messages sending is now again working on Windows. And last but not least, SMS daemon, all related things and gammu configuration files now have man pages, which boosts documentation level from none to almost perfect ;-). As a special bonus for Czech users, Gammu translation is now more complete and all new man pages are translated to Czech. Full list of changes:

• Fix some memory leaks found by cppcheck.
• Fix unsafe sprintf usage in some modules.
• Improve debugging facilities to use state machine debug configuration when possible.
• Separate SMS daemon out of gammu binary.
• SMSD now requires [gammu] section in config file.
• UsePhoneDB option replaced by chekfirmware command.
• Added pkgconfig support for gsmsd (SMSD library).
• Debug logging can be handled by custom function in application.
• SMSD log now includes gammu log messages.
• SMSD now can log to syslog.
• SMSD can now deamonize itself.
• All callbacks can now pass user data along.
• SMSD can now write PID file.
• Added man pages for gammu-smsd(1), gammu-smsdrc(5) and gammurc(5).
• SMSD can now natively run as a Windows service (bug #451).
• SMSD debugging can be now enabled by DebugLevel directive.
• Proper reconnecting support for MySQL.
• Better error logging of PostgtreSQL SMSD service.
• SMSD now properly frees allocated memory.
• SMSD now handles SIGHUP for rereading configuration.
• Added LSB init script for SMSD.
• SMSD can now log to stderr/stdout.
• RunOnReceive now can get IDs of received messages.
• Avoid duplicating of same code in command line and tests for messages displaying.
• New binary gammu-smsd-inject to inject messages to SMSD.
• Gammu binary now does not support any SMSD operations.
• Sending TEXT message now accepts text using -text parameter.
• Improved logging differentiation of SMSD log messages.
• Properly remove messages from queue when sending fails (bug #778).
• Use own test handler instead of asserts.
• Separate gammu and libgammu messages, libgammu no longer sets textdomain.
• Use po4a for translating man pages.
• Dump more information in dct3trac, thanks to Duncan Salerno.
• SMSD cal log to Windows Event Log.
• Added man pages for SMSD backend services.
• Dropped static configuration files for MSVC, they were broken anyway and CMake now works good with MSVC.
• Script gammu-config supports also cdialog.
• Reduce stack usage on message composing (fixes crash on Windows).
• Fixed returned saved location on AT engine.
• Added support for dropping privileges in SMSD.

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental as soon as they will go through NEW queue.

I just moved my blog from blosxom to ikiwiki. Slowly, but surely, my web-related infrastructure for gag.com and related sites is all moving to ikiwiki+git... I shoved in a rewrite rule to map the old top-level URL to the new one, and ensured that my rss feed will only contain new posts. However, all the "permanent" article paths changed. Oh well. I'm much happier now!

With all the parts, the raw boards, and the solder paste stencil for the TeleMetrum board now in hand, you'd think we'd be about ready to load and reflow a board. Not quite! The 0402 passives are going to require lots of magnification for me to place accurately. And the solder paste has a finite working life. That leads me to want to prepare all the parts in advance so that there's minimal fumbling around during the "pick and place" phase of the operation. So, I've been transferring the passive parts from the cut auto-load tapes they came in to plastic prescription medicine bottles I've been collecting for the purpose. Miraculously, these happen to be a near-perfect size for the sticky labels provided by Digi-Key with each part! My next step will be to label the bins on the Mini Muffin Pans I bought to stage the parts for placement. Then I'll load the bins with parts, and hopefully that'll make picking and placing with tweezers and inspection microscope go reasonably quickly. Hopefully tomorrow!

I feel I should comment on the whole DebGem thing. About a week ago, the guys from that project mailed me, stating that they were about to go public, and if I would please have a look at it before they would do so and perhaps give some constructive criticism. So I did. I must say I wasn't very impressed, initially. What you get there is what the name suggests: a Ruby Gem, but then just repackaged as a Debian package. As in, files laid out exactly the same way. As in, still not FHS compliant. As in, many other problems. I came up with a list of problems that was quite long, and they've fixed most of them; but the fundamental problem that RubyGems are peculiar beasts, making it hard, if not impossible, for Debian people to package them so that they adhere to Debian's strict quality requirements remains, and this service does not (or cannot) solve that. To be sure, it's a step in the right direction, which will ease the maintenance of Ruby software on many a Debian system, and for that they deserve praise. However, it is not a solution; much more work needs to be done and it needs to be done within the Ruby community.

Word is out that there will be a 2009 edition of the Google Summer of Code. I have some follow-up ideas based on last year's mentoring for both Debian and R, but there will be a better time and place to discuss possible project ideas.

I'm going to re-do my blog sometime soon.The host my current blog is running on is going to retire "anytime soonish" (I happen to be responsible for that, so I will know when). So I will need to move my blog someplace else (I want to merge it into my regular web page, too). Right now, it's based on an ancient version of Pyblosxom with a couple of custom hacks, and is pretty much unmaintainable.So I'm also looking for an appropriate blog software, but I'm not yet sure about my requirements, so I don't have a clear software favorite yet. I don't need a browser based editor, and I'm not interested in interactive features such as comments or trackbacks.Mnemosyne is one of my favourites, because it's a rather low-level, bare-bones approach. Its templating is XML-based (KID) and it's Python.Ikiwiki actually calls itself a "wiki compiler", but I know that some people use it for their blogs. It also does valid XHTML, although its templating isn't designed for XML safety.Features that I would like to have:

• XHTML output, ensuring valid XML, and appropriate templating
• File-based data storage, no MySQL
• Python preferred, but pretty much 'Anything but PHP'
• Static rendering / caching
• Tag based organization
• Search engine optimization (static pages, sensible URIs)
• Atom and RSS 2.0 output, ensuring valid XML

I guess I'll just end up writing a blog software for myself. The current text files are an odd mixture of HTML and plain text anyway, so I'll need to write an importer for the old data myself anyway (plus then I can also do some URI mapping to redirect old links). My current web pages are generated via an XSLT transformation, so I maybe just re-use that for templating.The thing which probably gives the largest issues is pagination of list views. (Especially when you want the pagination to be stable even when new entries are added while a user is browsing the pages, which is nice to have because of search engines and links). I don't think a fully static rendering will work here.

I'm going to re-do my blog sometime soon.The host my current blog is running on is going to retire "anytime soonish" (I happen to be responsible for that, so I will know when). So I will need to move my blog someplace else (I want to merge it into my regular web page, too). Right now, it's based on an ancient version of Pyblosxom with a couple of custom hacks, and is pretty much unmaintainable.So I'm also looking for an appropriate blog software, but I'm not yet sure about my requirements, so I don't have a clear software favorite yet. I don't need a browser based editor, and I'm not interested in interactive features such as comments or trackbacks.Mnemosyne is one of my favourites, because it's a rather low-level, bare-bones approach. Its templating is XML-based (KID) and it's Python.Ikiwiki actually calls itself a "wiki compiler", but I know that some people use it for their blogs. It also does valid XHTML, although its templating isn't designed for XML safety.Features that I would like to have:

• XHTML output, ensuring valid XML, and appropriate templating
• File-based data storage, no MySQL
• Python preferred, but pretty much 'Anything but PHP'
• Static rendering / caching
• Tag based organization
• Search engine optimization (static pages, sensible URIs)
• Atom and RSS 2.0 output, ensuring valid XML

I guess I'll just end up writing a blog software for myself. The current text files are an odd mixture of HTML and plain text anyway, so I'll need to write an importer for the old data myself anyway (plus then I can also do some URI mapping to redirect old links). My current web pages are generated via an XSLT transformation, so I maybe just re-use that for templating.The thing which probably gives the largest issues is pagination of list views. (Especially when you want the pagination to be stable even when new entries are added while a user is browsing the pages, which is nice to have because of search engines and links). I don't think a fully static rendering will work here.[Update: Sean pointed out that by using title-only in archive pages I can avoid having to paginate. Thanks! I also received TONS of software recommendations. Ranging from PHP over bash (URGH, I want valid XHTML) to mod_lisp based (no special Apache modules, please. Should run everywhere.)]

Joey, I really like rel-vcs proposal. On the other side it misses few good things which were already found for Vcs-* fields (there is already no XS- prefix for quite a long time). First it misses information about branch. On git, you will automatically get a master, but for SVN, you need to point to some branch, otherwise you get really lot of stuff. And I think that practise should be same as for Vcs-Svn - to point the field to trunk URL. The second thing which this proposal misses is Vcs-Browser. It would not be useful for tools like webcheckout, but it would be great to have support for it in browsers or in plugins such as Operator. How about using type="browser" for this?

It's always enlightning how some people see how Debian works. Or not. It seems to get more and more common that instead of filing a bugreport people seem to consider it appropriate to rather rant in their blogs about it. That will definitely get things fixed and done and motivates everyone involved to work on the issues that they get notified about only through third-party. And of course it's absolutely alright to change an application directly, not use dpkg-divert or similar, and then complain wildly about how unfair an upgrade of the package replaced that file. And, Andrew, there wasn't a DSA about CVE-2008-2236 because it was considered a too minor issue for that. Thanks for the fish. Did you btw. try the version from the upcoming lenny release? It's not like it's not directly installable in etch because of dependencies... Only once I would hope that people that are that deeply involved in Debian (like, being Debian Developers or long-time contributors) would do things like random users do: File the things they are annoyed with, even if they are as minor and awkward as some of the bugreports I receive for wesnoth.