Archive for the 'Gentoo Linux' Category

TT-RSS 1.5.5 in Portage

I have blogged about TT-RSS just recently. And when Andrew Dolgov, TT-RSS’s initiator and main contributor released version 1.5.5, I thought I’d try to improve the ebuild a bit, given that it is in Portage now.

So I added a ‘daemon’ USE flag, which makes it easy for Gentoo users to get TT-RSS to update the RSS feeds. When you emerge www-apps/tt-rss with USE=daemon, it will now install an init script to start the ‘ttrssd’ daemon (or multiple, if you have multiple TT-RSS instances on your host). This is the preferred way to keep the feeds updated, according to TT-RSS’s documentation.

So, if you need a great, centralised (i.e. synchronised state amongst your computers, phones, etc.) news aggregator that runs on your own server / web host, give tt-rss a try! And if you’re a Gentoo user, I’d appreciate if you could test the new ebuild’s features (USE=daemon), and give feedback here or open a bug report if there is anything that could be improved further.

Reading news the way I like it

I have been using Tiny Tiny RSS (or TT-RSS) (www-apps/tt-rss in Gentoo) as my news aggregator since the end of 2008. It is a web application (written in PHP) that provides a great news aggregator UI. Since it’s a web application, you can use it from anywhere with just a browser, and thus have all your feeds in the same state (read/starred/…), anywhere you are. Think of it as Google Reader, but without Google knowing exactly what news articles you’re interested in, since you can run TT-RSS on your own server / web host.
So, TT-RSS alone was great already, but the UI is more suitable for when you have a mouse and a big browser window, than for using it from your phone.

Recently I discovered the Android App TT-RSS Reader which solves exactly that problem. It connects to your TT-RSS instance via an API, and brings all your feeds, with all their states just as on the web interface, to your Android device. The interface is specifically designed for touch screens, so it’s much easier to navigate through your feeds and articles than via the web interface. Furthermore, it can cache articles and images, which you can trigger while on WiFi before leaving the house, and then read everything on the way in Offline mode, to save mobile traffic, which is expensive and/or slow for some. When you’re back on WiFi, you switch back to Online mode, and TT-RSS Reader synchronises your state to your TT-RSS instance. Absolutely awesome 🙂

A couple of quick screenshots from the web interface (TT-RSS):

… and the Android App (TT-RSS Reader):

Update (2011-07-03): Shortly after posting this, hwoarang offered to take TT-RSS from the Sunrise Overlay into Gentoo’s main repository (Portage), with me proxy-maintaining it. So now it’s even easier to get TT-RSS onto your Gentoo-powered server.

emerge output ends up as attachment.bin when sent with nail / Heirloom mailx

I really like the command line mailer Heirloom mailx (formerly nail), and now there is even a current version in portage again (still under the name mail-client/nail, but that doesn’t matter), so that’s even better. I use it on all servers, since it’s just convenient – it can handle attached files, UTF-8 etc. without any problems.

But there was one problem that bothered me for months already: It involved my script, which basically just calls /usr/bin/emerge -upvDN --nospinner world for the host and all virtual servers, and then sends the output to me.

The problem: emerge’s output always ended up as ‘attachment.bin’, attached to the (otherwise empty) mail, although I piped it into mail -s "Updates for $DATE" root where it should come out as the mail body. I knew that Heirloom mailx does that, as soon as it doesn’t “like” one of the characters in the input, but I couldn’t think of a reason why it would do that with emerge’s supposedly plain-ASCII output.

Today I had enough of it, and fired up hexdump to investigate said ‘attachment.bin’, using the following command:
hexdump -e '1/1 "%03d \n"' attachment.bin | sort -u
It outputs the unique decimal values of any byte occurring in ‘attachment.bin’ as a sorted list. I expected to find something above 127 – but the highest occurring value was 122 (“z”). I then checked the top part of the list, and to my surprise, found 008 (backspace) there. After removing those by piping the output through tr -d '\010' (8dec = 10oct, and tr needs octal values), Heirloom mailx no longer put the text into ‘attachment.bin’. It now appears in the mail’s body, where it belongs.

By the way, those backspaces (when interpreted) change
Calculating dependencies ... done!
Calculating dependencies... done!
… so removing them is not a big loss. I’d like to know though, why they are there in the first place, even though the output doesn’t go to a TTY.