Some time ago, I wrote up how I created RPMs for ruby gems to simplify installation on EL-flavoured distributions.┬áIn the comments for that article, Jordan Sissel pointed me at his fpm tool which I said I’d check out if I ever needed to build any more rubygem RPMs.

Well, that time has come. I wanted to deploy a later version of capistrano across a client’s infrastructure and my previous approach didn’t work so I grabbed fpm and did this:

mkdir ~/tmp/gems
cd ~/tmp/gems
gem install --no-ri --no-rdoc --install-dir . capistrano
find ./cache -name '*.gem' | xargs -rn1 fpm -s gem -t rpm
ls *.rpm
rubygem-capistrano-2.15.4-1.noarch.rpm	rubygem-net-scp-1.1.0-1.noarch.rpm   rubygem-net-ssh-2.6.7-1.noarch.rpm
rubygem-highline-1.6.19-1.noarch.rpm	rubygem-net-sftp-2.1.2-1.noarch.rpm  rubygem-net-ssh-gateway-1.2.0-1.noarch.rpm

Nice and easy. Kudos whack!

The installation of hbase on CentOS is fairly painless thanks to those generous folks at Cloudera. Add their CDH4 repository and you're there: yum install hbase.

However, adding lzo compression for hbase is a little more tricky. There are a few guides describing how to checkout from github, build the extension, and copy the resulting libraries into the right place, but I want a nice, simple RPM package to deploy.

Enter the hadoop-lzo-packager project on github. Let's try and use this to build an RPM I can use to install lzo support for hbase.

Get the source code:

git clone git://github.com/toddlipcon/hadoop-lzo-packager.git

Install the deps:

yum install lzo-devel ant ant-nodeps gcc-c++ rpmbuild java-devel

Build the RPMs:

cd hadoop-lzo-packager
export JAVA_HOME=/usr/lib/jvm/java
./run.sh --no-debs

Et voila – cloudera-hadoop-lzo RPMS ready for installation. But wait… The libs get installed to /usr/lib/hadoop-0.20… That's no good, I want them in /usr/lib/hbase.

So I went ahead & hacked run.sh and template.spec to allow the install dir on the target machine to be specified on the command-line. I can now use a command line something like this:

./run.sh --name hbase-lzo --install-dir /usr/lib/hbase --no-deb

That produces a set of RPMs (binary, source, and debuginfo) with the base name hbase-lzo and libraries installed to /usr/lib/hbase

My changes (plus another small change adding necessary BuildRequires to the RPM spec template) are in my fork of the project on github

When you install an update to a package on an RPM-based system, any configuration files which were originally distributed by the package and that have been changed are not replaced when the package is updated. Instead, rpm creates a new file with the extention ".rpmnew". It is then necessary to manually compare the existing file and the new one and decide how to deal with the new file.

So, the pattern I often need to use is "list all .rpmnew files and the corresponding original file". This is not a particularly complex issue, but is one that I don't use often enough to have at my fingertips. The trick is bash variable substitution; specifically pattern matching: ${variable%pattern}. This deletes the shortest possible match for pattern from the right of the contents of $variable.

An example using .rpmnew files created when upgading OpenNMS:

# ls -1 *.rpmnew| while read f ; do ls -l ${f%\.rpmnew}* ; done
-rw-rw-r-- 1 root root 7285 Jun  3 12:43 database-reports.xml
-rw-rw-r-- 1 root root 8232 Aug 10 19:01 database-reports.xml.rpmnew
-rw-rw-r-- 1 root root 333092 Aug 25 09:25 datacollection-config.xml
-rw-rw-r-- 1 root root 314141 May 11 01:31 datacollection-config.xml.rpmnew
-rw-rw-r-- 1 root root 3395 Jun  3 12:43 jasper-reports.xml
-rw-rw-r-- 1 root root 3664 Aug 10 19:01 jasper-reports.xml.rpmnew
-rw-rw-r-- 1 root root 25887 Aug 10 19:01 log4j.properties
-rw-rw-r-- 1 root root 25887 May 11 01:31 log4j.properties.rpmnew
-rw-rw-r-- 1 root root 19319 Apr 22 16:56 opennms.properties
-rw-rw-r-- 1 root root 19635 Aug 10 19:01 opennms.properties.rpmnew
-rw-rw-r-- 1 root root 9252 Apr 22 16:59 rrd-configuration.properties
-rw-rw-r-- 1 root root 9604 May 11 01:31 rrd-configuration.properties.rpmnew
-rw-r--r-- 1 root root 669444 Jun  3 13:51 snmp-graph.properties
-rw-rw-r-- 1 root root 604457 Aug 10 19:01 snmp-graph.properties.rpmnew

I use the toggl time-tracking service to keep track of the hours I work for my various clients.

toggl make available desktop clients for Windows, Mac, & Linux, but the Linux packages are in .deb format for Ubuntu and, until recently, they did not provide x86_64 packages.

toggl recently released the desktop client as open source so I grabbed it and have built an RPM.

SRPM: TogglDesktop-2.5.1-1.fc12.src.rpm

RPM (Fedora 12, x86_64): TogglDesktop-2.5.1-1.fc12.x86_64.rpm

As I mentioned in a previous post, the MySQL RPMs provided for RHEL/CentOS by percona are not actually compatible with RHEL/CentOS. They use the same package layout as the MySQL-provided RPMs.

Here's how I create my own RPMs having the same package layout as the RHEL/CentOS packages but with the percona highperf patchset applied.

Continue reading

ourdelta provide MySQL packages for various platforms, built with assorted performance/feature patchsets.

Sadly, like the percona builds, the RPM packages for RHEL/CentOS are not upstream-compatible, ie. they package MySQL differently.

I was planning to re-build the ourdelta packages to use the upstream RPM package layout but I've decided to stick with re-building the percona packages as I've already done the work for that.

Anyway, in case it helps someone, here's how to rebuild the ourdelta packages from the SRPM:

rpmbuild --rebuild \
  MySQL-OurDelta-5.0.87.d10-65.el5.src.rpm \
  --define 'ourdelta 1' \
  --define 'mysqlversion 5.0.87' \
  --define 'elversion 5' \
  --define 'patchset d10'