mailx implementation that won't barf on UTF-8 encoded GECOS information?

Dear Lazyweb,

I've been having problems with cron jobs that mail their output, because they always manage to garble non-ASCII characters into some unreadable crap.

Upon closer inspection, the real culprit seems to be mailx: no single mailx implementation out there seems to have come to terms with the fact that most contemporary operating systems have their GECOS information encoded in UTF-8, rather than in ASCII.

I had very high hopes for the Heirloom implementation of mailx, except that it, too, fails at encoding mail headers in UTF-8.

I'm thus wondering if there's anything I might have overlooked, perhaps a mailx setting that would enforce encoding of the From, To and Subject lines to UTF-8, or otherwise another mailx implementation that in fact does acknowledge the fact that most operating systems these days have their GECOS information encoded in UTF-8?

Q: How to configure /etc/pulse/client.conf for remote audio sink?

I've spent the last couple of months wondering this and could not find an answer on the otherwise excellent PulseAudio wiki, so I thought that I'd ask the Lazy Web:

How can I configure /etc/pulse/client.conf to prefer a specific remote audio sink and to automatically fall back to localhost only when that remote sink is not available via Avahi?

I'm already aware of the paprefs applet, but it requires me to manually select the remote audio sink, every time I get back home, which is not what I want.

Instead, I need the PA daemon on this laptop to always try connecting to audio.lan then to localhost and to dynamically switch back and forth between those two hosts according to info provided by the Avahi PA module: if audio.lan is reachable and an audio sink is found, switch to that; if not, fall back to localhost; if audio.lan re-appears on the Avahi radar, switch back to it.

Surely there must be a way to achieve that, but how?

PS: audio.lan runs PA in System mode with IP-based ACL, if it makes any difference.

wanted: 'lspci -vvv' output for Geode SC1100, SC1200, SC1400

As I'm trying to better document which Geode models bear which PCI vendor and device ID, I'd need volunteers to e-mail me the output of 'lspci -vvv' for their Geode SC1100, SC1200, SC1400 -based hardware. Please send the result to my iki.fi address. Thanks!

PS: the part that interests me is the PCI ID of all Geode CPU and Companion Chips shown by 'lspci'. This requires setting several additional levels of verbosity, because this information is hidden from the normal 'lspci' output.

wanted: Geode "Red Cloud" GX2 hardware

Ever since X server 1.5 was released, various regressions started affecting our GX2 code in xf86-video-geode. We couldn't figure out what went wrong since our GX2 code hadn't changed in ages and we couldn't think of any ABI or API migration that would cause these regressions.

Well, it turns out that someone had quietly rewritten part of the X server core, which broken things from under our feet.

In the end, the change required to restore operation was minimal, but it nonetheless caused problems for several thin client users who complained loudly while the xf86-video-geode team scratched their head wondering what went wrong.

Still, it essentially meant that GX2 users suffered through Intrepid and Jaunty without a solution in sight, which is of course unacceptable. I'm also aware of at least one startup who lost a fairly lucrative LTSP maintenance contract, simply because their customer's GX2-based thin clients could not be made to work on Ubuntu since Hardy. Ouch!

In order to prevent this from ever happening again and to ensure that regressions get noticed before they reach critical mass, I'd like to solicit a hardware donation: something GX2-based with a small hard-disk or CompactFlash socket and 100baseT Ethernet.

My contact info can be found on my homepage. Please make sure that you contact me upfront to agree on the delivery method, before sending me any hardware.

Thanks!