So, I’m not the only one looking a solution for this problem.

Basically I want my RSS reader to fetch things (images for example) needed to display every entry during updates, so I can read them offline. Images in most feed entries are referenced remotely (http://), which are usually not downloaded until the entry is actually viewed. Some feeds use enclosures but that works more like an attachment rather than for content.

I’ve tried quite a few RSS readers and Straw seems to be the only one that does full automatic image fetch during updates. However Straw’s development has been stalling, and the latest version seems to be quite unstable.

Liferea has been my RSS reader for quite a while, and so I’ve decided to do it myself with (hopefully) the simplest way possible: a Liferea conversion filter which parses a feed and fetches things for offline reading.

At the moment it works by looking for <img> tags and fetches the image using wget, and then replaces the original image src to point to the local one.

It’s a pretty simple perl script. I have written it in a way so it can be extended it to parse and fetch other things in the future, maybe embedded videos for example. It currently downloads all images, one by one. It also checks if a file is already downloaded or not. You can change $SAVE_PATH in the script as needed.

You can git (yes, git) the script at git://pigeond.net/offline_filter.git. Or alternatively get the latest version here, or browse the repo at http://pigeond.net/git/?p=offline_filter.git.

To use it, set the script as the conversion filter for the feed you want to have things downloaded and it should just work.

Now I can read all the really important stuff on the train, like xkcd and failblog ;).

For those who need SCIM while running 32-bit apps on a 64-bit system outside chroot, there are two things (at least for me) needed.

Apart from the obvious that you need SCIM installed in the 32-bit chroot, you’ll need to set SCIM_MODULE_PATH to point to the 32-bit SCIM libdir. For instance, my iceweasel32 script looks like:

#!/bin/sh
export CHROOT=/chroot/testing.32

export GTK_PATH=${CHROOT}/usr/lib/gtk-2.0

export LD_LIBRARY_PATH=${CHROOT}/lib:${CHROOT}/usr/lib:/lib32:/usr/lib32

export SCIM_MODULE_PATH=${CHROOT}/usr/lib/scim-1.0

export MOZ_PLUGIN_PATH=${CHROOT}/usr/lib/mozilla/plugins

linux32 ${CHROOT}/usr/lib/iceweasel/firefox-bin "$@"

Secondly, you’ll need to add a symlink in /usr/lib32/gtk-2.0/2.10.0/immodules for the chroot’s /usr/lib/gtk-2.0/2.10.0/immodules/im-scim.so. Not the cleanest way I have to say, but it works.

It was about 8 months ago when I started using vimpress. And I’ve actually modified it a bit since then. So far I’ve made two tiny changes.

The first is checking for vim python support before doing anything. I did this because in Debian vim (vim.basic) isn’t compiled with python support, and I prefer vim.basic over vim.gtk or vim.gnome as my default vim (and as for the reason, see my previous vimpress post.

The second is adding a :BlogSave command. Basically sending and saving an entry without publishing it, i.e. saving it as a draft, which I do a lot myself.

I’ve kept it in my git repo now at git://pigeond.net/vimpress.git

Gitweb at http://pigeond.net/git/?p=vimpress.git

A couple of weeks ago, one of the fellows (yes, you, MSmith) from the Island Virtual Airways, the virtual airline based on FlightGear, poked me and was asking me if there is a way to show only their airline pilots on FGMap. After spending a few coding train trips, I’ve added a very simple pilot filtering feature. Currently you can filter by the callsign and the aircraft. It also has query string support, so you can do things like http://mpmap02.flightgear.org/?pilots_filter_callsign=blah

Check it out at http://mpmap02.flightgear.org/. Code is in my usual git repo.

Enjoy…

This is a test…

Well, not really.

I was looking for an alternative to posting blog entries using the web interface, and was randomly trying a few apps in Debian. There were drivel and gnome-blog but they don’t seem to support tags. BloGTK seems to, but there’s something weird about how it does, and it doesn’t support multiple categories. BloGTK is also being removed from Debian.

Then I came across vimpress - a vim plugin for wordpress. It’s simple, but it does what I needed. You can get a list of your blog entires, post a new blog, or even edit an existing blog. So I’m testing it with this blog entry and see how it goes.

The only small rant, not to vimpress, but to Debian’s vim, is that vimpress needs vim’s python support, but it’s not built into the vim.basic binary, which I prefer over vim.gtk or vim.gnome. One of the reasons is when I ctrl-z to background vim, and then foreground it (fg), it sometimes (not all the time) gets stuck unless I hit ctrl-c. This does not happen with vim.basic, but only vim.gtk and vim.gnome.

I did try to trace it and it is when the function mch_suspend calling pause(), which causes vim to wait for a signal.

Perhaps I should report to vim later…

I’ve been keeping a git repo of my own for FlightGear for quite some time. I was using Tailor for importing CVS into git, since git-cvsimport seems to be an issue with the branches in FlightGear’s CVS. Tailor is very powerful, and work among over 10 different revision control systems.

On the other hand, I’ve been having some issues with tailor. Not until much much much later (about a week ago) that I discovered the cause and possibly the remedy. At the same time one of the FlightGear developers Tim Moore has figured out why git-cvsimport wasn’t happy, and more importantly how to make it happy.

And so I’ve re-imported FlightGear and SimGear source from scratch and it’s been going well so far. But for those who have been using my repo, you will have to re-clone it again.

I’ve also imported the FlightGear data repo, but beware, it’s rather big even for git. The bare repo is almost 1G. So if you’re happy with your current CVS checkout, I suggest you not to bother with my git one. Mind you, that’s the entire history. Considering a checkout is about 1.7G, that’s not too bad. I’ve also set a 512kB/s limit for my git upstream, just in case there are like 20 people cloning the data repo at the same time :)