From Fedora Project Wiki

About me

I'm the head systems administrator for the Mathematice Department at the University of Houston. We use Fedora extensively on the desktop, and I'm interesting in useful scientific and sysadmin applications into the distro. Along with a few more games, of course.

I work on the Packaging:Committee. I was a very early FESCo member, back when the 'E' meant 'Extras', but left years ago.

I have probably over a thousand completed package reviews at this point. I don't really do them any longer, but if you really need something reviewed, feel free to ask me. IRC is best.

What I'm Doing

Outside of committee work and trying to clean up the packaging guidelines, I'm spending most of my time trying to enhance the packaging experience by simplifying specfiles. Lately (early 2016) I've been adding macros to EPEL in order to enable more packages to build there without needing specfile changes. This benefits Fedora by having fewer specfiles that have outdated constructs which get copied into other packages without thought.

I'm also working to hide as much bizarre specfile magic as possible behind macros.

RPM, Lua, and stuff

I've been playing around with the Lua interpreter built into RPM and found cool things. This has enabled me to make some neat macros to simplify packaging.

RPM includes a "rex" module, which is a thirteen year old version of the usual Lua Lrexlib rex module. It's ancient, but it does work to allow some better regex matching stuff. Supposedly it supports standard Posix extended regular expressions but it doesn't appear to support things like [:digit:]. The rpm docs on this ([1]) say pretty much nothing and what they do say is at least partially wrong.

There is only one function in the rex table: newPOSIX. RPM's default init.lua file sets = rex.newPosix (as well as defining a few other useful utility bits) but RPM doesn't actually install that file anywhere. I will probably add one to Fedora at some point to add in my debugging infrastructure.

So you can do:

local triple = rex.newPOSIX('^[0-9]+,[0-9]+,[0-9]+$')

and, then make use of the triple like:

if triple:match('0,3,2') then

match returns nil if no match, and 1.0 (not true) if there was a match.

The gmatch function doesn't make a whole lot of sense to me. From experimentation and reading the source, I've found that it accepts two arguments: the string to match against the regex, and a function. It returns 0 (not false or nil if the match fails, and 1.0 if the match succeeds. I have no idea why these values differ from the preceding match function.

The function passed to gmatch is called if there is a match. The first argument is the portion of the string which matched. The second argument is a table/array containing all of the captured matches. Why the code doesn't just return this table, I don't know. So the only reasonable thing, I guess, is to have this weird function store its arguments in globals and if you get a positive value back from gmatch then look in those globals for the info you need. So:

local triple = rex.newPOSIX('^([0-9]+),([0-9]+),([0-9]+)$')
z = triple:gmatch('100,567,999', function(m,c) match = m; captures = c; end)
if z > 0 then

Please don't ask me why; I have no idea at all.


Occasionally people ask how I have my editor set up so that it yells about specfile issues. I use vim (though I also use emacs, so no editor wars please) and have the syntastic module set up to call rpmlint whenever I open or save a file.

Install Plug according to its installation instructions.

In my .vimrc I have:

call plug#begin('~/.vim/plugged')
Plug 'scrooloose/syntastic'
call plug#end()
let g:syntastic_spec_rpmlint_args = ""

Open vim and enter :PlugUpdate and then restart vim or :so ~/.vimrc.

If you're editing a spec and rpmlint complains about something it shouldn't, just create a file in there with the spec and add options and filters. For example:

setOption('NetworkEnabled', True)

will quiet the editor when working on the zsh specfile and check that the source URLs are correct.

Bug me at: