It’s still in a very early stage (I’ve started coding it yesterday), but it’s basic functionality is already there: You can query the BTS, filter the list of bugreports in realtime by typing something and view the full bugreports in HTML. You can even provide additional information for existing bugs or create new bugreports. It currently only supports icedove and mutt as mailclient but adding other clients is very easy. This tool is not designed to replace reportbug, it rather aims for the newbie users feeling uncomfortable typing their mails in vi and would rather have something to point and click. Maybe I can merge the code with reportbug, but after a quick look at it’s code it seems that this will not be as easy as I thought in the beginning. The code is available here. You’ll need python-qt3 to run it. Update: The screencast was created with byzanz via
$ byzanz-record -c -l -d 45 reportbug-ng.gif
Hint: Best to switch the desktop resolution to something like 800×600 before recording — resizing the gif afterwards is very expensive (cpu- and memory wise).

Today are provincial elections in The Netherlands, one of the least visible governments in this country, so it's hard to decide what would be a good choice. Add to that that the chosen members will in turn choose the (national) Senate. I have never been fond of package deals. I do not necessarily vote for the same party on the provincial level as I do nationally, because these two layers deal with distinctly different classes of decisions. After casting my vote I returned home with a little doubt of whether I'd made the right choice, until I realised which 9 parties I didn't vote for. The fact that my vote did not go to the parties that I don't trust our province or senate with is far more useful than the relatively small difference between the candidates I considered.

Christian is talking about problems with suspend-to-RAM and suspend-to-disk and the major cause of issue being the non-free Conexant HSF modem driver.

Since I got my new laptop I had my share of issues with suspend-to-*.

At the beginning everything worked fine, out of the box. Then (I think) I realized that my video card (damned ATI) was not working in accelerated mode, so I decided to fix that and since the card is too new to be even listed as existing on radeon driver's support page, I had to use fglrx.

Then I made the DRI work but suspend-to-ram ceased to work (after a few testing->experimental; experimental--> upstream updates, both ways); I started using the experimental driver (8.31.5-1) which proved to be stable enough (this time) just for suspend-to-disk, if it had dri enabled, or suspend-to-ram, if not having DRI enabled.

I even made a patch to help the maintainer update faster the package (I added a get-orig-source rule in debian/rules).

Now I have ported the patches in the debian package and updated it to 8.33.6 and I am running that. Problems include: consoles are not accessible, but suspend-to-ram and dri work. I will submit a bug with the patch to updated fglrx package.

I expect that I'll try soon to update to 8.34.8 in the hope that I will get all the things working: suspend-to-*, consoles, dri.

Now, this is one cool project (and video) from Alan Carvalho de Assis (and friends), as announced on the LinuxBIOS mailing list: LinuxBIOS with X Server Inside (YouTube video). The setup: LinuxBIOS + a Linux kernel + BusyBox + a tiny X11 server (Kdrive) + the Matchbox window manager + rxvt. All of this in a normal BIOS chip (2 MB), without any hard drive connected (who needs hard drives when you can fit everything in the BIOS just fine)... The thing boots into BusyBox in less than 6 seconds, then in ca. 2 seconds into X11 + rxvt. There's probably even room for improvement there... It seems there will be an OGG Theora version of the video soon, and I hope a small HOWTO about the project, too. More LinuxBIOS-related screenshots and videos are available in the wiki btw., and a bunch more will follow soon...

So the security team decided to kick Wordpress from Etch since they assume it won’t be sanely maintainable over the course of 30-36 months. This practice surprises me a bit, especially since upstream plans to support the 2.0.x series until 2010 and the package is currently very well maintained by Kai Hendry. So what’s the problem? Is it manpower? I guess not, since Kai even offered to provide security updated packages when they become available, which was rejected with a friendly “EOD for me.“. Anyway, since my blog will become unsupported soon, I need to switch to something else. So dear lazyweb, what is the next best alternative to WP available in Etch? I need good comment spam protection and an option to import my old wordpress entries.

I recently wrote an article or two about distributed version control systems.

I've been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.

However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.

So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn't (or isn't very well). Also, git is complex to pick up for me, and I certainly don't want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it's had for awhile, and I couldn't find even one advantage of it over Mercurial. So off I went with Mercurial.

I quickly learned a bit of a philosophical difference from Darcs to Mercurial.

Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.

It is exactly this Darcs behavior that permits both is excellent "darcs send" feature (still unmatched in any other VCS), but also causes its hang problems.

I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.

It is easy to get started with Mercurial. The mq system -- similar to quilt or other patch-management programs -- is really quite an amazing hybrid between patch management and version control. I frankly don't see any need for other patch-management tools anymore.

Mercurial has a "patchbomb" feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.

I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I'm going to keep my personal code in Darcs for the moment because "darcs send" is still easier than "hg email", but that may change before long, depending on how my experience goes.

I'd encourage others to give Mercurial a try. The community is also very nice and helpful.

I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.

After asking for useable CA Software, I have finally settled on using EasyRSA. This is what I did to come across the packaging shortcomings of EasyRSA in Debian. Storing your CA Be sure that your CA is stored in a secure place. Don’t store it online, and make it accessible only to yourself. In my opinion, storing the the CA in a cryptoloop container file on a small 32 MB USB stick is a good idea. Cryptloop is rather easy today and available in the stock Linux kernel. I commonly use grml-crypt to manage the crypto loopback stuff:

sudo grml-crypt start /media/usb4/cryptoloop $MOUNTPOINT

Gotcha: don’t confuse sudo’s “password” prompt with grml-crypt’s “Enter LUKS passphrase” prompt, the cryptoloop password won’t bring you anywhere on the sudo prompt. Preparing the CA directory For the CA, create a dedicated directory in the mounted cryptoloop file system. You’re originally supposed to copy the entire EasyRSA directory tree in there, but I’d recommend to only link the files from your system’s EasyRSA directory to automatically take advantage of distribution updates. You’ll need at least these links:

lrwxrwxrwx 1 mh mh   56 Dec 25 23:23 openssl.cnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
lrwxrwxrwx 1 mh mh   52 Dec 25 23:22 pkitool -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool
lrwxrwxrwx 1 mh mh   60 Dec 25 23:23 whichopensslcnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf

ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf .

Configuring your CA The only thing you cannot link is the vars file which contains your CA’s local settings:

export EASY_RSA=“$(pwd)”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=$($EASY_RSA/whichopensslcnf $EASY_RSA)
export KEY_DIR=“$EASY_RSA/keys”
# Issue rm -rf warning
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus.de”
export KEY_EMAIL=“mh+easyrsa-mh-openvpn@zugschlus.de”
export PKCS11_MODULE_PATH=“dummy”
export PKCS11_PIN=“dummy”

Comments have been removed from this file. Better copy the file from /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars and edit it to your needs. I added the two PKCS11 variables since you won’t otherwise be able to issue certificate requests. Creating the CA Next, decide on a shell instance where you will do most operations, and source vars in there. Next, run /usr/share/doc/openvpn/examples/easy-rsa/2.0/clean-all. If you do this in a directory of an already-in-use EasyRSA CA, you’ll need to restore your backup. To actually initialize the CA, run pkitool --initca --pass. If you do not give the --pass parameter, you’ll create a CA that can issue certificates without asking for a passphrase, which might not be a brilliant idea. Choose a reasonably secure pass phrase. Creating Certificates - the simple and suboptimal way You can now simply proceed to create an arbitrary number of pairs of “private” keys and associated certificate by simply calling pkitool <clientname> and/or pkitool --server <servername>. Depending on your security policy, you can mandate the private keys to be protected by a passphrase (adding --pass to the command lines), but you’ll have the expense of being asked for the passphrase every time you start a new openvpn daemon. Creating Certificates the Right Way I have put the “private” in quotes since the keys created this way are not really private: The key was created on the box hosting the CA, was stored on the local (crypted) file system and needs to be moved to the target system via a secure channel. Doing so the right way is harder than expected, so it is usually the better way to keep the private key really private by creating it directly on the target system. On the target system, you need OpenVPN installed, and openssl. After the certificate was created, you can remove openssl again. Creating a private key is part of a key-pair generation process that also leaves a certificate request. The contents of the certificate request is public, and you can safely move it to the CA box and convert it to a certificate by signing the request. You only need to make sure that nobody exchanges your target system’s certificate request for her own before you sign it as you might end up certifying a wrong identity. For the rest of this document we’re going to assume that you have ssh access to the target system and have verified the ssh host key, so that you can be reasonably sure to be connected to the right system. To create a certificate request, you can use this script, which I have called create-easyrsa-cert-req:

#!/bin/bash
set -u
TMPDIR=“/tmp”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=“/usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf”
export KEY_DIR=“$TMPDIR/keys.$$”
mkdir -p $KEY_DIR
export KEY_SIZE=1024
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus”
export KEY_OU=“$(hostname --fqdn)”
export KEY_EMAIL=“mh+$(hostname)-ovpn-cert@zugschlus.de”
export DEBUG=1
umask 077
if [ “$ 1:-foo ” != “server” ]; then
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr $(hostname)
else
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr --server $(hostname)
fi
mv $TMPDIR/keys.$$/* .
rm -rf $TMPDIR/keys.$$

When called without parameters, it creates a certificate request for an OpenVPN client certificate, and when you call it with “server” as parameter, it will create a server certificate request. In any case, it will leave two files in the current directory. They are named after the current host name, and have the extensions .csr and .key. The .key file is your private key. keep it private! The .csr file is the certificate request which you can now move to the keys subdirectory of your CA directory via scp or other means such as an USB stick. To do the actual signing, invoke pkitool --sign <hostname> and enter the CA passphrase. You can ignore the error message that there was no .key file to chmod. Gotcha, when signing a server certificate, use pkitool --server --sign <hostname>. Move Certificate to the target host You can now move the certificate to the target system. Since you’re probably going to need the root certificate and the certificate revocation list as well, you can move the .key file (if created on the CA system), the .crt file, and ca.crt to the target system. These files are public, so there is no need for a secure channel. Revoking Certificates Since an OpenVPN server’s only means of authentication is to check whether the certificate presented by a client is signed by the “right” CA, the only way to revoke VPN access is to revoke the certificate. This is also done on the CA system by calling /usr/share/doc/openvpn/examples/easy-rsa/2.0/revoke-full <client-name>. This creates a crl.pem file which contains a list of all revoked certificates. You need to have a mechanism to distribute that list to all systems that might need it, and it is recommended to have this automated. Remember, if you do not distribute the .crl file, the systems are not going to know about revoked certificates.

"Second Life runs on 2,000 Intel and AMD servers in two co-location facilities in San Francisco and Dallas. The company has a commitment to open source, with servers running Debian Linux and the MySQL database. Linden Lab chose Debian Linux because the software is suited to scaling massively with a small IT staff, said Linden Lab CTO Cory Ondrejka. MySQL allows the server farms to scale horizontally, by adding large numbers of low-power servers as needed, rather than vertically, which would have required Second Life to run on a few, powerful systems, Miller said."
Joe Miller is VP of platform and technology development for Linden Lab.
Source: http://www.informationweek.com/news/showArticle.jhtml?articleID=197800179

We know that, but sometimes we spend more time and effort with pointless discussions. Discussions are good, don't get me wrong, but they need to start and end. Get a life, go squash some bugs, package something NEW and upload to experimental, write documentation or tell the word who else is using Debian. Debian is bigger than our own egos and debates.

Don't you care that Second Life uses Debian? Aren't you a Second Life user? I'm not a Second Life user, but if Joe Miller come out and tell the word that they use something else, a lot will go and say 'look, Debian is better than that, but the world don't care let us keep fighting'. Debian aims to be a universal operating system, and the universe is bigger than OFTC and lists.debian.org.

Last weekend I attended the Chemnitzer Linux-Tage, which have been, again, a very nice event. They have a really nice Social Event and very good overall service for people that do stuff for the event (like giving a talk, running a booth). If only they would have similar good connection with trains, its always annoying to go there. :) I had a talk on Sunday afternoon, a bit about Xen on Debian, and just judging from the feedback I got right after the talk my performance was not too bad. My slides are available in case you want to read them. (They are in german only). Fixed two little mistakes people told me after the talk. I also used the CLT to get another sponsor for this years DebConf, yay. Hopefully it works at Cebit too. :) The weekend only has one big bad thing - my Ibook decided to die. It just want let me turn it on again. Plays a sound, but nothing else happens. The few times it decided to boot it didnt run for long. Some minutes and it completly hang. BAAD. Especially a day before I want to use it to give a talk. Damn thing. Now I need to finally get me the new laptop I am planning to get since December. So, looking bad at what suggestions I got in December (thanks to all who sent mails!): - Someone suggested looking at Lenovo T60s. Well, fine, except that their largest display is 15”, and I want more. I dont care much about the weight, so that doesnt count. Also, if it would be IBM still I (maybe) would consider it, but at the same time I got two people telling me to not look at Lenovos, they had bad experience with them… - A suggestion lead me to a site of a notebook manufacturer that only runs if you allow flash in your browser. No thanks, they dont want my money. - HP business notebooks seem to have a good support within people reading my blog (or better - Planet Debian). - And finally, people have been happy with Dell notebooks. So I compared Dell and HP, both times the business notebook class. And currently want to buy a HP nw9440 one. Will get damn expensive, but a similar Dell would only be 100EUR less, and well, HP does care way more for Linux then Dell ever did (or will do)… BTW: We have to many mails on Debian lists!

In case anyone is relying on me to point them to the funniest episodes of The Show with Zefrank, this (today’s) is one, especially if you spend any time on Friendster or that odd new generation Myspace.com (when I was young, we had a public_html directory, and we knew how to set permissions on it! I also truthfully walked nearly a mile in freezing weather and snow uphill to get to the school bus). Apparently, The Show will be done for good in just under two weeks. Who knows where all the fans will go?

Petr Kratochvil made this comment about his web site:

"For people interested in green living and environment. We're building an ecological house and we want to support 40 others in their ecological living by giving them 10,000. We have only one planet and we have to take really good care of it now."

Visit his site if you want details of how to take a shot at the 10k (summary: mail them some proof of your greenness and post on their forums, then it pays out if they raise a million). This money-raising site is produced by a company doing similar work to us, but I'll be watching this with interest. There's not much choice of eco houses, so maybe its forum will offer up some tips for greening older houses too.

Tasks 0.3 is out! The main new features are internationalisation and category filtering. A complete list of user-visible changes:

• Translatable (thanks Jordi Mallach)
• Add a category combo in the edit dialog to select categories, and a category filter in the main window
• When adding new tasks if the view if filtered, put the task in that category (Emmanuele Bassi)
• Don't embolden completed high priority tasks
• Show task count in the title bar
• Use the stock Add button
• Enable building on GTK+ 2.8

I also had a few translations:

• nl (Espen Stefansen)
• nl (Wouter Bolsterlee, Chrisph Brill)
• pl (Tomasz Dominikowski)
• id (Arief Utama)
• pt_BR (Bruno Boaventura)
• fr (Bruno Bord)
• gl (Alejandro Riveira Fern ndez)
• sk (ja@disorder)
• vi (Nguyen Thai Ngoc Doy)
• el (Stagros Giannouris)
• cs (Vitezslav Kotrla)
• et (Priit Laes)
• eu (Mikel Olasagasti)
• sv (Andreas Henriksson)
• it (Emmanuele Bassi)
• tr (Tuyan Ozipek)
• es (Adolfo Gonz lez Bl zquez)
• de (Christoph Brill)
• ca (Jordi Mallach)

Sources are available on the OpenedHand Projects site, and packages for Ubuntu Edgy, Ubuntu Feisty, and Debian Sid are in my repository. Adam Williamson has also packaged Tasks into Mandriva Contrib.

I originally was quite reluctant to post on Planet Debian about the DPL race, but hey, this is the campaigning period, anyway. My choice not to go into too much detail about what I'll do about Debian seems to spark some confusion. I initially thought of adding a rather verbose explanation for that to my platform; but as the initial version of my platform got quite long and convoluted, it got cut. Perhaps that wasn't a very good idea, so here goes: One observation I've made over the years is that DPL candidates often come up with all sorts of grandiose plans about what should be done to improve Debian. These plans are usually the result of some observation they've made, and consequently some thinking they've put in so as to come up with what they think is the most reasonable solution to the problem at hand. The only problem with this approach is that, if you're not involved in whatever you have ideas on, you'll probably end up suggesting things which the people that are involved do not think is a good idea to do. Which would consequently mean that you'll either have to do it all by yourself (since you can't force DDs to do something against their will, and we have a constitution to back that up), or that they convince you that it's not a good idea, and you end up not doing whatever you promised to do during your campaign anyway. First, this is silly. If you don't know whether you can or will keep a promise, you should not make it. But apart from that, it's also a problem; if you get elected mainly because you promise to do one thing and then don't end up doing it, or do something else instead, then you've got yourself a very good reason not to be liked in the community. Which isn't something a DPL should aim for, I believe. So rather than coming up with a detailed plan of all the things I'd do once elected, I decided to come up with a detailed plan of all the things that need work. The exact stuff that gets done about them would then be decided after having a chat (on IRC or otherwise) with the people involved, directly or otherwise, and after considering what other people's opinion on the matter is, if I know said opinion. Does that give me a carte blanche, as Julien suggests? Well, yes and no. Yes, because every Debian Developer who runs for DPL is essentially asking for a carte blanche; after all, the DPL has the ability to speak for the developer body, unless overruled by GR. No, because I don't think doing whatever I want and everyone else be damned is an even remote sign of maturity, and because I promised not to seek the controversy in making decisions (while not avoiding it at all cost either).

On Tuesday the 23rd of January I shaved off my beard after spending 107 days growing it, see above for the final beard pic. It was an interesting experiment and it's something that I recommend trying, but I couldn't keep it.

Having a beard is more effort than being clean-shaven. Eating is more difficult when you are trying to keep your beard out of your food. If you get the full beard (as I did) then the moustache at the sides of your mouth will get into your food (particularly bad for ice-cream). I guess that the benefit of having a waxed moustache would be that the wax would keep it out of the way of the food - the waxed moustache wasn't just an issue of style!

Madduck suggests that when you drink Guinness you "push your lips past the head and draw up only the dark stuff". Of course that won't work if you have a moustache as you don't want a moustache that's soaked in beer!

Immediately after cutting off my beard I didn't shave for almost a week and experienced much less discomfort than I had preveiously experienced when not shaving for that period. I think that having been used to having a beard an amount of hair that would previously annoy me is not noticable. Also it
seems that the hair was initially softer after I cut off the beard. Maybe shaving somehow makes the hair grow tougher.

When I had the beard I thought that I hadn't adjusted my body image to match, as every time I looked in the mirror I felt surprised to see it. Once it was gone my new look initially seemed more odd to me than my previous appearance, and it took me a number of weeks to get used to not having a beard.






When shaving off my beard I decided to do it in stages, firstly I did a "goatee" cut and then just a moustache. The moustache is a little lop-sided, but I was in a hurry and didn't plan to keep it for long.

The Chemnitzer Linux-Tage are over and I'm back home. Again it was an outstanding event. Starting from the overall organisation to the social event (and their quiz) to the catering... I'm still stuffed with the buffet of the social event :) The first thing in the morning I did a workshop about Debian package building. It was very well visited; only two seats were left empty. The visitors were very good; understood most very fast and corrected me a couple of times, when I did copy'n paste mistakes. It was fun to do that, and I got good feedback. BTW: If you need a small example to show someone how to create a Debian package, you might want to take a look an gnujump. The templates created by dh_make work nearly out of the box (so you can concentrate on explaining what is done, instead of fixing stuff to get it working), while the resulting package has still place for improvements (.menu and .desktop files; splitting the package into a arch dependent and an arch independent; etc.) And most important: It is compiles quite fast, while you still have something to show, so your visitors will see, that you indeed did something. Talking about the feedback I got after the workshop: One guy asked me about a way to check for conflicting packages, and we all wondered, that there's nothing scripted available, yet. So I promised to hack something together to at least check for conflicting files. The result is available at conflict finder (and later an svn.schmehl.info, as soon as I find out how to setup webdav/svn to allow read access to some repositories and not others). To check for packages your package should conflict with, you need to first build your package (or we won't know which files are in your package) and give the path to the resulting .deb as the first parameter to the script. If you have a Contents-foo.gz file somewhere on your hard disc, you can specify the path to that file as the second parameter (if you use apt-file or have a local mirror, it'll try to find it; if everything fails the script will try to download one). Then the script will check for each file of your Debian-Package if there is any other package having the same file. Sounds cool, but is damn slow; the repeated zgrep over the Contents-File is quite time consuming. For a quite small package (xdialog) it took nearly 15 minutes to complete. Wow, when I hacked it together, I wouldn't have thought it would be that slow. As far as I know Alexander Wirt is already working on an improved version using some kind of database (and perl).

I was thinking about mentors.debian.net and how much it's useful and unknown for many DDs and potential contributors. I don't think our GForge installation (http://alioth.debian.org) reached its full potential (in terms of audience) but is more known than mentors.

I like the mentors documentation on how a non-DD can upload packages to their repository, and almost everything else there except for the need to create yet another account in a website. I would be glad to see the code move to nm.d.o/mentors, but being less hungry why not some integration with Alioth?

I think that if we add OpenID support into GForge and push that to Alioth, services like mentors will benefit instantly any Debian contributor (DD or not) using svn.d.o, for example. I have no knowledge on GForge internals, but feedback from a GForge hacker if this feature is planned or if this contribution would be welcome will be appreciated. That would be great hear the opinions from alioth and mentors admins.

In other words: I want my Alioth OpenID and i'm sure you can think about new interesting use cases (eg.: forums, debian-community anyone?).

Brett Parker suggested educating all users about line-endings - sadly, I think there are more users than I have time to educate (even with a web page that makes the basic point, I think there will still be lots of questions) and also, I think stuff on the Windows side should handle their bad decision - they came along last, didn't they? Jon Atkinson commented:

"WinSCP deals with line endings properly, and is free software. It also has a NC-style interface, which I prefer to the Filezilla interface. http://www.winscp.net/"

Thanks. I'll suggest that some users try WinSCP instead of Filezilla. Ben Hutchings commented:

"Version 4 of SFTP introduced the SSH_FXF_TEXT open flag, but OpenSSH is still stuck at version 3."

Why no version 4 in OpenSSH yet, then?

The first fruit of my work on Debian IA64 packages for Mondo Rescue are now on http://people.debian.org/~andree/packages/. It took a bit longer than I had anticipated and there was a bit of an interruption while I stayed on beautiful Norfolk Island for two weeks.

Everything should be fine and dandy apart from the fact that restores will currently miserably fail on IA64 because parted2fdisk expects an older version of parted than what Etch and Sid contain.

So, why publish IA64 packages at all if they don't even work, I hear you scream. Well, firstly I thought I give a bit of an update and show that things are actually moving forward. Secondly, maybe I'm lucky and someone is interested in helping out with getting parted2fdisk to work with newer versions of parted or (better) in getting mondo migrated to using parted natively on all platforms (pending Bruno's approval).

Other than that, the packages have a few user-visible improvements and fixes across all supported architectures and they bring the Debian packages a fair bit closer to upstream - see the changelogs for details.

As usual, check out the new packages, let me know if something doesn't (or does) work, get involved! ;-)

I like to listen to Nova 96.9's stream, and I'd been doing it really sloppily at home by quitting the MythTV front-end running on the TV, and just running mplayer with the URL of the stream. I really wanted to be able to play the stream through MythTV. So a few weeks ago I did a spot of searching and up came MythStream, which appeared to be just the ticket. I'd already done a few sloppy unpackaged installations of things on the MythTV machine, and I wanted to stop this, so I held off installing it until I had time to make a package of it. Today I finally had time to make said package (which is here if anyone else is interested) and it works a treat for what I want to do. It looks like it has plenty of other features that I don't really need but will explore anyway.