The Shoes of the Fisherman's Wife Are Some Jive-Ass Slippers

The Missing Motivational Poster

Inspired by ECLM 2008: The Missing Rant.

Building RPMs in SCons

Here's a recipe I've developed for building a RPM in SCons with out too much mucking around. My big issue with RPM is the whole /usr/src/redhat thing which is silly from a permissions point of view, and also prevent multiple users on the same machine from building at the same time.

import string, os

# Sources for RPM

arch = 'i386'

sources = [
    'foo.spec',
    'foo-upstream.tar.gz',
    'bippity.patch',
    'flippity.patch',
]

# Create RPM build environment

env = Environment()

env.Append(
    ENV = {'HOME': os.environ['HOME']},
    TARFLAGS = '-z')

# Build tar file of sources

tarfile = env.Tar(
    'foo.tar.gz',
    sources)

# Build RPM from tarfile with included spec

rpm_defines = {
    '_topdir': Dir('#build').abspath,
}

rpm = env.Command(
    'rpm_dummy',
    tarfile,
    'rpmbuild %s -tb %s' % (
        string.join(['--define "%s %s" ' % (i[0], i[1])
                     for i in rpm_defines.items()], ' '),
        tarfile[0]))

# Take care of creating and removing various temporary directories
# required by RPM.

env.AddPreAction(rpm, Delete('#build'))

env.AddPreAction(rpm, [Mkdir('#build/SPECS'),
                       Mkdir('#build/BUILD'),
                       Mkdir('#build/RPMS/%s' % arch)])

env.AddPostAction(rpm, [Delete('#build/BUILD'),
                        Delete('#build/SPECS')])

# Clean up after ourselves

env.Clean(rpm, ['#build/BUILD', '#build/SRPMS', '#build/RPMS'])

I like the use of pre and post actions here to create the directory structure expected by RPM and the cleanup of it afterwards. Running scons -c will delete all the generated RPM files as well as the tar file of sources.

Oh yeah, installing and using ccache is absolutely essential for debugging RPM files.

Because All the Cool Kids are Doing It

$ history|awk '{a[$2]++} END{for(i in a){printf "%5d\t%s\n",a[i],i}}'|sort -rn|head
   68   ls
   51   cd
   35   ssh
   34   svn
   33   git
   25   less
   25   ./bbc
   19   rm
   14   mv
   14   erlc

I think running ls is the command line equivalent of saying umm when you need something to fill an awkward silence.

Getting Started with smbpython

After many false starts, Samba is starting to acquire some client-side scripting support. The language being used is Python, although Swig is being used to generate bindings. At a later stage perhaps other scripting languages might be supported.

At the moment the Python bindings are in their infancy, but it's still possible to do some useful things. To start hacking on the Samba Python bindings check out a copy of the source from Subversion and build as per usual:

$ svn co svn://svn.samba.org/samba/branches/SAMBA_4_0
[...stuff...]
$ cd SAMBA_4_0/source
$ ./autogen.sh && ./configure.developer && make
[...more stuff...]

Now these commands will build a complete Samba environment including the Python bindings. For the moment we will be working directly out of the build directory and not bother installing libraries, executables, etc. The only tweak we need to do is to set LD_LIBRARY_PATH to point at the shared libraries we have just built and then run a Python executable with all the Samba goodies compiled in:

$ export LD_LIBRARY_PATH=`pwd`/bin/shared
$ bin/smbpython
Python 2.5.1 (r251:54863, Oct  5 2007, 13:38:40) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

What can we do from here? I'm hoping to write some more entries about some of the existing Python bindings, starting with tdb and ldb.

Thanks to Jelmer Vernooij for taking my bits and pieces of decrepit Swig bindings and turning it into something useful.

No Worrie's

SCons Builder for Ragel

Here's a SCons builder for the Ragel State Machine Compiler, based on the one for SWIG included in the SCons distribution.

#            tastes like -*- python -*-

"""Tool-specific initialisation for ragel."""

import SCons.Util
import SCons.Tool
import SCons.Action

def generate(env):

    c_file, cxx_file = SCons.Tool.createCFileBuilders(env)
    c_file.suffix['.rl'] = '.c'

    c_file.add_action('.rl', SCons.Action.Action('$RAGELCOM', '$RAGELCOMSTR'))

    env['RAGEL'] = 'ragel'
    env['RAGELFLAGS'] = SCons.Util.CLVar('')

    env['RLCODEGEN'] = 'rlcodegen'
    env['RLCODEGENFLAGS'] = SCons.Util.CLVar('')

    env['RAGELCOM'] = \
        '$RAGEL $RAGELFLAGS $SOURCE | $RLCODEGEN $RLCODEGENFLAGS -o $TARGET'

def exists(env):
    return env.Detect(['ragel', 'rlcodegen'])

How to patch and rebuild a RPM package

Here's a nice tutorial on how to make a patch to a program distributed as a SRPM file. I would also recommend installing ccache and maybe distcc as finding and fixing bugs in a RPM build usually involves compiling the same source files over and over again.

The Geekiest Place to Hang Out

The Provably-Secure Mutual Authentication and Key Establishment Protocols Lounge.

Sheep Jigsaw

Another Stevey Blog Rant About Emacs

Here. It's quite long and complicated. I wish I had time to write that much stuff about Emacs. Anyway, some choice quotes about whether you should learn Emacs Lisp:

"First, recognize that Emacs Lisp isn't going anywhere. Emacs is not going to magically become programmable in Python or Ruby or JavaScript or Perl overnight ... [Emacs Lisp] will never be obsolete knowledge. You might as well start learning it now, and reap the benefits now."

On Lisp syntax:

"If you do it enough, eventually you'll enjoy programming in Emacs-Lisp, no matter how much you hate it initially ... you'll initially dislike Emacs-Lisp's syntax; it's virtually guaranteed. Fortunately, it doesn't really have much in the way of syntax; almost everything follows the exact same s-expression form. So you should get past the syntax pretty quickly, and in a few weeks you'll start liking it just fine.

Kind of reminds me of people who dislike using tabs as syntax when writing Python code for the first time. I'm poking around with Ruby at the moment and having to put end everywhere is actually pretty annoying.

I've done some bits and pieces of Emacs Lisp programming over the years and it is quite seductive, for lack of a better word. I think that's the nature of functional programming though once you really get in to it.