(This has ended up longer than I intended, largely because I felt I should then get into why. I'm aware I haven't got into all the nuances, so I hope readers familiar with the area will appreciate this is the compact version.)

Thorsten had a rant last week about PGP keysigning problems. He apologises for his tone, but that's not the issue I take with his rant.

It starts "Keysigning is useless". And yet his complaints seem to be:

• Dealing with the private half of your GPG key securely involves some faff (in this case booting with a live CD and having to set things up ready to keysign).
• He doesn't get on with caff.
• People reject email from machines with invalid HELOs and perform other anti spam measures on ISP access ranges (I'm not clear if it's just greylisting or outright rejects as that's not made clear).
• PGP/MIME is a protocol violation (yes, but it's much better than inline OpenPGP. Unless you have to deal with RT, which mangles it. *sigh*)

Torsten does say that he'll continue to do keysigning on a per-person basis, so it doesn't sound like he's completely given up. I'm posting this largely so other Debian related people don't get the idea that it's not important to think about keysigning.

Why should we care?

Firstly, let's clarify what I mean when I sign someone else's key. If I sign your key then I think that I believe you hold the private part of a key that has your name and an email address I believe I can use to contact you on it. It means I have seen government issued ID that matches that name. It also means that I have interacted with you (and watched others interact with you) under that persona. In short I am happy that the key is a reasonable digital representation of your identity - something signed by it either comes from you or has involved the key being compromised or you coerced  into using it against your will.

Why is this useful?

It gets useful thanks to the web of trust; ie the idea that there are a bunch of people I trust partially to sign other keys, and if enough of them have signed a key then I can have a reasonable expectation that the key belongs to the person I want to talk to. Which means I might be prepared to send private data to them. Or Debian might be prepared to accept an upload from them. Which, when you're dealing with a community that spans the planet and where most of the contributors haven't met each other, is pretty freakin' useful - I, as part of Debian's keyring team, don't need to personally be able to identify every Debian developer. All I need to do is be able to trust other DDs to be able to do so. (Though maybe I'm missing out on something here - perhaps Debian should be paying for Gunnar and me to travel the world verifying fingerprints. \o/)

(I still do mass keysignings btw. I'm picky about which keys I actually sign - this is in no way intended as a slight against those I don't, but a mass keysigning at least lets me know that the people involved are happy to exchange fingerprints. Though, FWIW, I normally have ID on me and frequently have fingerprint slips, so if you know me and want me to sign your key/want to sign mine then by all means ask me when you see me!)

Knowing full well that it will cause many of my readers to tut and roll their eyes at me I derive slight pleasure from confessing that I have now eaten at McDonalds on 6 continents. To make it worse I only did so in Asia and Australia so I could say I had.

It does lead me into a slightly more valid ramble. I'm not particularly bothered about eating on my own. I like food (even if I'm picky about what I like), but I prefer it with company. This means I'm not particularly great about being organised to cook complicated things when I'm on my own; largely the whole thing just turns into dealing with hunger. It also mean I'm bad at finding nice places to eat out while travelling. Which, when you're travelling for a month to some interesting places, is a bit of a bugger. I've got a bit better at actually going to nice places, and trying not to bolt my food into me so I can get out ASAP but instead enjoy it. A book helps. Also places that aren't quite as busy (which if you have no agenda is nicely achieved by letting your body clock desync from the world around you). Unfortunately I didn't really do so until after Hong Kong. Guess I'll just have to go back at some point...

(More on my travels at some point, maybe. I've started the tortuous journey home now.)

Being a bit of a freak I actually tend to read my boot output. Well, when I'm not using that time to go grab a cup of coffee first thing on a Monday morning. However I don't always find Debian's default output as clear as I'd like (especially when I haven't had that coffee yet, or when I'm half watching a remote machine boot over its serial console). ISTR that RedHat had much nicer boot output (I'm talking about text based here, not the fancy Plymouth stuff) with a row of OK/FAILED etc down the right hand side that made it nice and obvious what was happening. Of course we can do that with Debian, at least for packages that use the lsb-base logging functions. Drop the following into /etc/lsb-base-logging.sh and enjoy a slightly prettier boot. I'm slowly filing wishlist bugs with patches for those bits and pieces I use that don't use lsb-base for their init script logging.

# Colour our init scripts output

# int log_end_message (int exitstatus)
log_end_msg () {
    # If no arguments were passed, return
    if [ -z "${1:-}" ]; then
        return 1
    fi

    retval=$1

    log_end_msg_pre "$@"

    # Only do the fancy stuff if we have an appropriate terminal
    # and if /usr is already mounted
    if log_use_fancy_output; then
        RED=`$TPUT setaf 1`
        GREEN=`$TPUT setaf 2`
        YELLOW=`$TPUT setaf 3`
        NORMAL=`$TPUT sgr0`
        $TPUT hpa $((`$TPUT cols` - 12))
    else
        RED=''
        GREEN=''
        YELLOW=''
        NORMAL=''
    fi

    if [ $1 -eq 0 ]; then
        /bin/echo -e " [   ${GREEN}OK${NORMAL}   ]"
    elif [ $1 -eq 255 ]; then
        /bin/echo -e " [${YELLOW}WARNING!${NORMAL}]"
    else
        /bin/echo -e " [ ${RED}FAILED${NORMAL} ]"
    fi
    log_end_msg_post "$@"
    return $retval
}

log_action_end_msg () {
    log_action_end_msg_pre "$@"
    if [ -z "${2:-}" ]; then
        end=""
    else
        end=" ($2)"
    fi

    /bin/echo -n "${end}"

    # Only do the fancy stuff if we have an appropriate terminal
    # and if /usr is already mounted
    if log_use_fancy_output; then
        RED=`$TPUT setaf 1`
        BLUE=`$TPUT setaf 4`
        NORMAL=`$TPUT sgr0`
        $TPUT hpa $((`$TPUT cols` - 12))
    else
        RED=''
        BLUE=''
        NORMAL=''
    fi


    if [ $1 -eq 0 ]; then
        /bin/echo -e " [  ${BLUE}DONE${NORMAL}  ]"
    else
        /bin/echo -e " [ ${RED}FAILED${NORMAL} ]"
    fi
    log_action_end_msg_post "$@"
}

(This is mostly for my own future reference, because I keep trying to search for details on it and not finding exactly what I want. I forget where I even found the basis for this, though there are lots of similar snippets out there. I've not tried it with a concurrency based boot so it may well look horrible under that.)

I've recently been fixing up my VDR setup to work with FreeSat and make it brother/parent friendly. I've applied the EPG patches to get the 7 day guide, setup an autologging in user under gdm with vdr-sxfe running and that left getting the remote working. For some reason my old serial dongle wasn't happy with lirc - it got detected ok, and would show some signal when buttons were pressed but didn't work with the old config. The entire hardware of the box has changed, so it seems likely something isn't quite right (in particular the lirc drivers spew out warnings about SMP bits so I should probably try the dongle under a single core setup to rule that out, but there's also a move to 64 bit involved).

The easy solution to have something sorted for Christmas was to pickup a cheap remote from eBay. This ended up being a Cyberlink remote + USB dongle combo. Worked just fine when plugged in, turning up as a normal input device and the obvious keys doing the obvious things. I wanted all the keys to work though, as I'd got used to having a lot of the VDR functions instantly accessible rather than having to work my way through the menus. Various searches suggested I'd need to use LIRC to access the odder keys. That seemed a lot of hassle for something that was doing the decoding itself. Some playing with xev turned up keycodes for a number of the keys, but there were still a few missing (and important ones at that, such as Red/Green/Yellow/Blue). Further digging found me a suggestion of an Xorg keyboard map that would map the KEY_RED etc from the evdev device into something workable under X. And then I found inputlirc via the Debian package. This is really bloody neat - point it at an evdev device and it will present all of the KEY_* codes out as lirc keys. If you pass the -g parameter it makes sure the key presses only go to lirc as well. Exactly what I want and a doddle to setup - no messing with a big configuration file, just edit /etc/defaults/inputlirc to point to the correct /dev/input/by-id/ file, add the -g to the options in that file and restart.

Now the main remaining task is to get it working with BBC/ITV HD.

I'm due a new laptop; my Portege R200 is over 4 years old now, I find it much slower than my desktop (no surprise; P-M 1.2GHz/1.2GB vs Core 2 2GHz/4GB), it's had a new battery and it has an annoying whine on the screen unless you press the side in just the right way. It's still better for long periods of use than my EEE 901, which is why I keep it. In particular I'm off to LCA2010 in January, along with some associated travel beforehand, and I'll want more than the EEE for that, but probably not a brand new laptop. Which meant that when the R200 started throwing disk errors recently I wasn't particularly happy.

Having decided it wasn't worth buying a new 1.8" drive I looked for alternatives. eBay offered plenty of options for 1.8" IDE to CF adaptors and I picked up a Kingston 32GB CF card from eBuyer. I copied across the data from the old drive using a USB adaptor, frobbed grub sufficiently that I got it installed on the CF, then swapped out the drive for the adaptor + CF. I had to do the swap a few times; the first I forgot to have a kernel with ext2 support (the HDD was ext3, but I went back to ext2 for the CF). The second I'd done my usual trick of forgetting to populate /dev with things like console and sda* (ie enough to get to the point where udev will run). And then grub needed some prodding to boot without intervention. I got there in the end and I'm currently writing this from said laptop.

I've made a few changes to the Debian install in an attempt to make things smoother; basically the same tricks people have been using on EEEs or other slow SSD devices. No swap, Iceweasel synchronous toolkit writes disabled, filesystems mounted with noatime, /tmp on tmpfs, various daemons that I don't really use disabled. It's still noticably slower than with the HDD, particularly on writes. However it's quieter and as long as it lasts for the next 3 months I'm happy (plus after that I can reuse the 32G CF card somewhere else, which I couldn't have done with a 1.8" HDD as easily).

Now, back to eyeing the Lenovo X200s (ugly, trackpoint but 1440x900 display, good battery life) and Toshiba R600 (slower, lower res but pretty and trackpad).as potential replacements. Maybe there'll be something even shinier in 12" by next year...