arch bash cakephp conf dauth devops drupal foss git golang information age life linux lua mail monitoring music mysql n900 netlog openstack perf photos php productivity python thesis travel uzbl vimeo web2.0

An rss2email fork that sucks less

Rss2email is a great tool. I like getting all my news messages in my mailbox and using smtp to make the "news delivery" process more robust makes sense.
However, there are some things I didn't like about it so I made a github repo where I maintain an alternative version which (imho) contains several useful improvements, both for end users and for developers/downstreams.
Also, this was a nice opportunity for me to improve my python skills :)

Here is how it compares:

(most of the changes are only in the xdg branch, which is the one I use and test)

criterion official version my fork
code hosting/release process "release" = tarball containing updated code corresponding to various fixes, and snapshots of other projects (dependencies). no version control, not even separate patches. no bug tracker. git. upstream tracking branch, master branch (basic "good stuff" patches), XDG topic branch (my favorite). Does not include code from other projects, rather list dependencies. Github issue tracker
code style dirty (extraneous whitespace, ^M characters, incorrect permissions, loads of bogus [whitespace] changes, ..). The python code itself seems nice though clean
file storage & config all in ~/.rss2email, list of feeds, email address and feeds state go into pickle file. commands like 'r2e add', 'r2e delete', 'r2e list' to manage feeds. feed ids change when feeds get deleted. 'r2e email' to manage email adress. adherence to xdg basedir spec. list of feeds goes into plaintext file, so does email address. state in separate pickle file. removed all the [now pointless] commands.
Temporary disabling of feeds no (if you remove a feed, you loose the state info) yes. comment it out or remove it. state info won't be lost
installation/runtime no Makefile. no reliance on $PATH, locking code in python. Distros are applying patches and/or using custom wrapper scripts smarter wrapperscript that prevents multiple runs, so removed locking code from python. Has Makefile. Easy to package
logging/debugging useful info messages hidden by default, "verbose mode" and error messages using print calls all over the place useful messages on stdout. additional (info/warn/error/..) logging and debuglogging use python module (xdg compliant)
web ui yes no (I don't need it)
windows support yes no (unless somebody ports xdg to windows and updates the wrapper script)

Other then that, there are also some smaller fixes in various places.

I'm using my version "in production" and it works great for me so far.
I have contacted the author and told her about my changes, but no response yet.
For now, you can treat this as an alternative version that stands on it's own. I made an Arch rss2email-xdg-git package in the AUR.

Oh, and I'm liking python :) Pretty nice and powerful language.


* python
* feedparser (4.2 or svn version)
* html2text (2.37 or higher)

We have python-feedparser 4.1-5 in the repos.

Aha, I'll fix that. Thanks
4.1 is actually the last stable release. I just know rss2email ships a bleeding edge version of 4.2, but it's not a hard requirement as 4.1-5 works fine for me, and the package of the official rss2email (, has no version requirement on feedparser (so users get 4.1-5)

PS: If you use Arch you can use python-feedparser-svn from AUR, which gaves you the bleeding edge stuff.

Yeah, I've tested it with both 4.1-5 and -svn from AUR (both work), I was just curious about the discrepancy.

The previous comment was also by me.

Could you please add something like digest mails? So it will check for new items every x hours but will only send the mail with all items of a feed once a day?
Maybe with `r2e update` and `r2e send` for the cronjobs.

I don't think I'll do that anytime soon, as I prefer one mail per post.
Maybe, if I get really bored... In the meanwhile, patches welcome! :)

I use gmail for e-mail and it supports message threading, so while I do get 3 e-mails regarding edits to a wiki page, they are presented as one threaded message that "unfolds" into three separate when I click it.





What is the first name of the guy blogging here?

This comment form is pretty crude. Make sure mandatory fields are entered correctly.
Basic html tags (a,i,b, etc) are allowed, others are sanitized