I have been using Google Reader everyday since I first discovered the service over seven years ago. It is my primary source of news and information and the announcement that Google is, on July 1 this year, set to shut down Reader was something considerably more than just an inconvenience for me.

Over the years, I had looked at other RSS readers but, for a variety of reasons, had invariably found that the speed, simplicity and flexibility that Google Reader offered meant that any dalliances were unsatisfactory and short-lived. I resigned myself to having to settle for an inferior alternative, rather than moving to a genuine replacement.

On the recommendation of @pinboard, I first signed up for a premium account at NewsBlur. It is open source and, given the recommendation from Maciej¹, I was hopeful that it would bridge the gap. Newsblur is a good service (especially considering the rush of signups in the days after the Google announcement), but it has a couple of critical weaknesses for me: no search (yes, you read that correctly—there is no way to search through your feeds) and, less importantly but just as annoying, occasionally sluggish performance.

After a couple of weeks using NewBlur I happily stumbled across CommaFeed, a Reader clone that emulates the austere minimalism of Google Reader. Apart from the fact that it is open source, the other aspect that attracted me to it was the ability to run it on Red Hat’s Platform as a Service offering, OpenShift.

The README on the Github repo explains how to set it all up. Unfortunately, due to an open issue, some manual intervention is required, but it is still a very straightforward and painless process to get your own instance of CommaFeed up and running.

Creat an OpenShift account, log in and add the JBoss 6.0 application (or cartridge as it is called on OpenShift) and the MySQL cartridge. Once your setup is created, add your public SSH key and, under your My Applications tab, copy down your Git repo address, which will be of the form:

1

ssh://76758382475ef809976543@$appname-$namespace.rhcloud.com/~/git/feeds.git/

Then you need to make a local clone of CommaFeed and push it to the Red Hat server:

1
2
3
4
5
6

git clone https://github.com/Athou/commafeed.git
cd commafeed
# add OpenShift as a repo
git remote add openshift -f ssh://76758382475ef809976543@$appname-$namespace.etc…
git merge openshift/master -s recursive -X ours
git push openshift master

This will then trigger a series of hooks that build the application and restart the server. If everything goes well you will see something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] BUILD SUCCESS
remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] Total time: 3:18.195s
remote: [INFO] Finished at: Mon May 20 03:21:37 EDT 2013
remote: [INFO] Final Memory: 42M/185M
remote: [INFO] ------------------------------------------------------------------------
remote: Running .openshift/action_hooks/build
remote: Running .openshift/action_hooks/deploy
remote: hot_deploy_added=false
remote: MySQL already running
remote: Found 127.12.712.712:8080 listening port
remote: Done
remote: Running .openshift/action_hooks/post_deploy
To ssh://76758382475ef809976543@$appname-$namespace.rhcloud.com/~/git/feeds.git/

You now have CommaFeed successfully running on OpenShift. After a couple of minutes, visit the public URL and you will be able to login to your CommaFeed instance. Updating your CommaFeed is as simple as pulling to your local repo, merging and then pushing to openshift master.

Importing directly from Google Reader still seems broken (I was getting errors from builds late this week), but if you import from an existing .opml or .xml file you will see CommaFeed in all it’s glory:

As you can see, it is remarkably similar to the Google Reader interface; a clean, minimalist design that is focussed—quite rightly—on the content. There is an option to load your own .css if you want to apply some additional styling, but for me the base style is just about perfect.

More impressively, in the week or so that I have been using CommaFeed, the developer, Athou, has been committing enhancements and bug fixes several times a day; almost every night, I have pushed changes to OpenShift, reloaded my browser and found a smoother, enhanced feed reader with additional functionality; it is literally growing in leaps and bounds, and is a great reminder of the power of open source².

The performance of OpenShift has also been solid; feeds are delivered seemingly instantaneously and, apart from the slight lag after restarting the application, I haven’t experienced any issues whatsoever in terms of availability.

There are still a couple of areas where CommaFeed can be improved. Most notably, there is an open feature request for a mobile friendly CSS and this is badly needed, the site is pretty much unusable on my phone. With any luck, some enterprising Android developer will build a CommaFeed app (for which I would happily pay good money)…

In any event, if you are looking for a Google Reader replacement, try running CommaFeed (either on your own server or one of Red Hat’s); for a project that is only a couple of months old, it has covered a tremendous amount of ground and will undoubtedly continue to grow and improve.

Notes

1. In conjunction with his great advice about not being a free user.
2. The about page has a donate button: if you want to support an application which I have no doubt will soon be even better than Google Reader, you might want to use it.

I posted a couple of weeks ago about Building Vim and how, using ABS and makepkg it is possible to customize packages in the repositories to suit your individual requirements, in that case with a specific feature set.

One of Arch’s real strengths is in the flexibility that makepkg and PKGBUILDs provide the community; the ability to adapt official packages—or unofficial ones in the AUR—as you see fit. As PKGBUILDs are just shell scripts, the entry level to start playing around with them is quite low¹.

A fairly standard, and simple, example of the type of customization that I might make is with dmenu, the suckless dynamic menu, where the standard package in the Arch repositories is not patched for Xft support. There is a patch for this on the suckless wiki, so it is just a case of making the requisite changes in the PKGBUILD from ABS and building it.

As you can see from the diff below, there is not a lot involved in this exercize; essentially, adding libxft as a dependency, sourcing the patch from the suckless site (and including the hash for it), and then in the build function ensuring that the patch is applied and the Makefile updated with the new library:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

--- PKGBUILD   2013-05-18 09:33:07.156328812 +1200
+++ PKGBUILD   2012-11-14 09:25:15.915335588 +1300
@@ -11,16 +6,22 @@
 pkgdesc="A generic menu for X"
 url="http://tools.suckless.org/dmenu/"
 arch=('i686' 'x86_64')
+groups=('modified')
 license=('MIT')
-depends=('sh' 'libxinerama')
-source=(http://dl.suckless.org/tools/$pkgname-$pkgver.tar.gz)
-md5sums=('9c46169ed703732ec52ed946c27d84b4')
+depends=('sh' 'libxinerama' 'libxft')
+source=(http://dl.suckless.org/tools/$pkgname-$pkgver.tar.gz
+http://tools.suckless.org/dmenu/patches/$pkgname-$pkgver-xft.diff)
+md5sums=('9c46169ed703732ec52ed946c27d84b4'
+         'd448ec9120718b0aedbdb338f4fa69ba')

 build(){
   cd $srcdir/$pkgname-$pkgver
+  patch -p1 < ../$pkgname-$pkgver-xft.diff
+  sed -i 's:-I/usr/local/include/freetype2:-I/usr/include/freetype2:' config.mk
+
   make \

Running makepkg -i will build and install dmenu with Xft support. This is the most straightforward approach. I also, primarily by way of experimentation and in an effort to try an understand how this actually works, have slightly more convoluted examples. msmtp, the SMTP client has a couple of makedepends in libgnome-keyring and texlive-core; the former I have zero use for and the latter is only installed on my desktop, so I have no wish to install it on my laptop just to be able to send emails…

In this case, I modified the PKGBUILD to completely remove the libgnome-keyring dependency and to only build the msmtp documentation in .pdf and .html if texlive-core was already installed on the machine. Unfortunately, I wasn’t able to test for the presence of texlive-core with the standard utilities like type or which, so—as it is installed on all my boxes—I went with expac (pacman -Q would also work):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

--- PKGBUILD    2013-05-18 09:32:07.393095131 +1200
+++ PKGBUILD    2013-05-18 09:31:55.449986364 +1200
@@ -1,7 +1,8 @@
 arch=('i686' 'x86_64')
+groups=('modified')
 license=('GPL3')
 url="http://msmtp.sourceforge.net"
-makedepends=('texlive-core' 'gsasl' 'libgnome-keyring')
+makedepends=('gsasl')
 source=(http://download.sourceforge.net/sourceforge/msmtp/${pkgbase}-${pkgver}.tar.bz2)
 sha1sums=('c0edce1e1951968853f15209c8509699ff9e9ab5')

@@ -12,19 +13,24 @@

 build() {
   cd ${pkgbase}-${pkgver}
-  ./configure --prefix=/usr --sysconfdir=/etc --with-ssl=gnutls
+  ./configure --prefix=/usr --sysconfdir=/etc --with-ssl=gnutls --without-gnome-keyring
   make
-  make -C doc html pdf
+  if [[ -n $(expac -Q '%n' texlive-core) ]]; then
+      make -C doc html pdf
+  fi
 }

 package_msmtp() {
   pkgdesc="A mini smtp client"
-  depends=('gsasl' 'libgnome-keyring')
+  depends=('gsasl')
   install=msmtp.install

   cd ${pkgbase}-${pkgver}
   make DESTDIR="${pkgdir}" install
+
+  if [[ -n $(expac -Q '%n' texlive-core) ]]; then
   make DESTDIR="${pkgdir}" -C doc install-html install-pdf
+  fi

 # Installing example configs and scripts to /usr/share/doc/msmtp

It isn’t necessarily an attractive solution, but it works for me… On the subject of unattractive solutions, as of pacman 4.1, released last month, the packaging standards for VCS PKGBUILDs have been changed, principally around how sources and versioning is handled. For the couple of VCS packages I maintain in the AUR², I have been experimenting with how to capture the pkgver in a way that conforms to the standards and provides people with a meaningful version number.

By default, the version number for these projects from their git repos is not that helpful:

1
2

git describe --always
4861046

After looking through the git logs, and playing around with awk to filter the results, I came up with this:

1
2
3
4
5

pkgver() {
  cd "$_gitname"
  printf '%s\n' "$(awk '/^ / {print $2}' <(git log --grep=version -1))_\
  $(git describe --always)"
}

This prints a more, for me anyway, intelligble package version: vimprobable2-git 1.2.1_c5936cc-1 that relates back to the last stable release and appends the current commit. I’m sure that this could be improved upon; suggestions are welcome.

The other change to note in all of these PKGBUILDs is the inclusion of the groups variable. By adding all of the modified packages from the official repositories to the—imaginatively titled—modified group, I can then add a line to /etc/pacman.conf that prevents those packages from being overwritten on upgrade³:

1

IgnoreGroup = modified

Issuing pacman -Syu, or running checkupdates from a cron job, will notify you that the packages have had a version bump and that they need to be rebuilt. The PKGBUILDs for all of these packages can be found in my bitbucket repo.

Notes

1. As my experiments attest…
2. Vimprobable2-git, Surfraw-git and ruby-build-git.
3. All credit to ataraxia for this idea.

Creative Commons image on Flickr by Wells P. Wilson

Or, “Why you should uninstall Yaourt and embrace makepkg…”

The release of Pacman 4.1 saw the same flurry of posts on the boards, in IRC and the mailing lists about people being “unable” to upgrade or, worse, claiming that pacman was “broken” because their upgrade was failing due to unsatisfied dependencies, that pretty much every pacman upgrade ocassions. How is it possible that so many people can run an operating system designed for competent users without having even a basic understanding of how the package manager—one of the single most critical components of the distribution—works?

Even a cursory perusal of the resulting threads on the boards will quickly identify the common denominator in these cases:

resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: package-query: requires pacman<4.1

package-query is required by yaourt; so these upgrades have been stymied by a package that is in the (unsupported) AUR? There are a multitude of AUR helpers, but yaourt is most commonly used by people who are new to Arch¹ for two reasons. First, it is one of the most “featureful” and secondly, and more to the point of my argument, it can be installed by simply adding an unsupported repo to pacman.conf; thereby effectively bypassing the need for the hapless user ever having to use or understand makepkg.

Consequently, over time, people who are habitually using yaourt -Syu --aur to update both the packages in the supported repositories and those they have installed from the AUR lose the conceptual distinction between the two. yaourt obscures this from them and—if they are completely reliant upon it, as these threads attest they are—they have abnegated responsibility for managing those unsupported packages and in doing so have found themselves incapable of understanding the bind they are in.

This sort of obscuring of fundamental operating principles in the pursuit of “convenience” is anathema to Arch and is precisely the reason I moved away from using yaourt (and indeed from using Ubuntu when I jumped from that sinking ship). Any convenience is purely illusory, in reality it just fosters learned helplessness.

I understand that the yaourt developer(s) was scratching their own itch, and this post is not about maligning the project; but there are significant unintended consequences of giving people a tool that abstracts such a fundamental element of the distribution away from the user, especially for a distribution where you are expected to have complete control and responsbility over your system.

To be clear, I don’t have a complaint with the concept of AUR helpers. I used yaourt initially before switching to aurget and then alighting on cower, or more particularly, a partial wrapper for cower:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#!/bin/sh
# install AUR packages with cower

cd $HOME/Build && cower -d "$1"
builddir="$_"
cd "$builddir" && ${EDITOR:-vi} PKGBUILD || exit

makepkg -si && cd - &>/dev/null

read -p "Remove Build directory? [Y/n]? " yn
if [ "$yn" = "y" ]; then
    printf "\n%s\n" "Removing build directory..."
    rm -rf "$builddir"
else
    printf "%s\n" "Build completed."
fi

This provides me the minimum level of automation I require—essentially only around downloading and installing a package. It doesn’t automatically handle dependencies, nor manage updating the packages; that remains, rightly in my view, my responsibility.

If I were to look to a more fully featured wrapper, I would undoubtedly choose meat, however as on my desktop machine, I only have ~30 AUR packages installed, I don’t really need anything more sophisticated.

So by all means, use an AUR helper. But recognize that it is intended to help you, not preclude you from being able to accomplish the most simple and critical task of system maintenance, updating your package manager. Uninstall yaourt if you are using it and familiarize yourself with makepkg; once you do understand the relationship between the official repositories and the AUR, download cower or meat, they are both much better solutions.

Notes

1. Myself included…

Creative Commons image of crutches by net_efekt on Flickr.