Converting a RHEL Workstation to a Server

My laptop is my Demo machine.  I need to be able to run the Red Hat cloud Suite of software on it.  I want to install this software the same way a customer would.  However, much of this software is server side software, and my machine was registered as a workstation. This means the Red Hat Content network won’t show me the server yum repositories.  Here is how I converted my machine to be a server.

Continue reading

Installing RPM Build Dependencies

If you ever want to build and RPM, you need to make sure that the things it requires are installed. These are listed in the SPEC file on lines that begin with BuildRequires.  Installing these by hand is time consuming enough that it should be automated.  Here’s a first hack in Python.


import sys
import re

build_re = re.compile('BuildRequires:.*')
compare_re = re.compile('.*=.*')

def main():
    if (len(sys.argv) > 1):
        spec = open(sys.argv[1])
        for line in spec:
            if build_re.match(line):
                for token in line.rsplit(" "):
                    if build_re.match(token):
                    if compare_re.match(token):
                    token = token.rstrip(" ,\n\r")
                    if len(token) > 0:
                        print token

if __name__ == "__main__":

To use it, save in a file called and run:

sudo yum install `./ ~/rpmbuild/SPECS/krb5.spec`

Project Values

When a group forms, one of the things it does, over time, is develop values.  Different development teams have different values, and people that come into the development process have to learn and adopt those values.   One value of the FreeIPA project that is very different from other recent projects of mine is this:  The main code repository is only for “published” code.  Work in progress should happen elsewhere.  The main git repository should be easily readable.

Continue reading

Found ‘${BUILDROOT}’ in installed files; aborting

If you get the above mentioned error while building an RPM, here’s what it means.  rpmbuild has executed the script:


This looks through the files that are set to be installed in your rpm to see if any of them contain the embedded path used to build or install them in the rpmbuild process.    For example, I have my ~/.rpmmacros file set to up with the following entry:

%_topdir %(echo $HOME)/rpmbuild

which means that I build in  /home/ayoung/rpmbuild.  Underneath this directory, I see, amongst other things, the subdirectory BUIOLDROOT.  The current wisdom says that an RPM should use BUILDROOT as the target for any installs.  This is the set of files that get packaged up for the final RPM.  The files here then get checked to see if they have this path embedded in them.  For example, when building rubygem libxml, I see:

+ /usr/lib/rpm/check-buildroot
Binary file /home/ayoung/rpmbuild/BUILDROOT/rubygem-libxml-ruby-1.1.4-1.young.x86_64/usr/lib/ruby/gems/1.8/gems/libxml-ruby-1.1.4/lib/ matches
Found ‘/home/ayoung/rpmbuild/BUILDROOT/rubygem-libxml-ruby-1.1.4-1.young.x86_64’ in installed files; aborting

There is a simple work around.  in ~/.rpmmacros, add the line:

%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

Which is,  think, a typo, but it shuts off the check.  However, I wouldn’t advise doingthis.

In the case of libxml, the paths are there as an artifact of the build process.  The .so carried the full path to the directory in which it was build as a way to link to the source files, for debuggins.  I can see the path by running:

objdump –dwarf

I don’t have a final solution, because I need to work through the gem install process, but the end effect will be

  1. Remove an non-essential files that have this path in them
  2. rewrite the path in the remaining files to be the correct location in the final installed location in the rpm

Update:  Since this is a ruby binary RPM, the correct thing to do is to move the gem install into the %build stage and then copy it into ${BUILDROOT}.  It currently happens in the %install stage.  RPM is wise enogh to do much magic in the BUILD stage, such as producing the debuginfo rpm and so on.

Could Maven use a single directory for archives.

Maven is too important a part of too many projects for most Java developers to ignore. However, some of the decisions made in building with Maven are suspect, mostly the blind download of binary files from a remote repository. While Maven gets more and more Open Source clean, there are still issues, and the biggest is building Maven itself. Both Debian and Fedora have fairly old versions of Maven, in the range of 2.0.7 as of this writing. Considering that the GA is 2.2.0 and There is work on 3.0, we risk a pretty serious divide in the Open Source Java world of we don’t keep up with Maven, and get a clean way to build it.

Continue reading

Hacking the Palm Pre from Fedora

My work machine is a Fedora 11 (F11) X86_64 system. The palm development SDK is distributed as a series of .deb packages, specifically targeted at an 32 bit Ubuntu 8 system. While I have the advantage of having a 32bit Debian system at home, so I was able to run through the setup process for development, ideally I would be able to attach to and control the Pre from my work machine.

The first step is to download the .deb files onto the F11 machine. I actually only needed the novacom deb, which in my case is novacom_1.0.38_i386.deb. Deb files are accessable using ar (happy talk like a pirate day!).

In a new and empty directory, run
ar -vxf ~/novacom_1.0.38_i386.deb

And you will see the three contained files:

control.tar.gz data.tar.gz debian-binary

Extract the data file using tar

tar -zxf data.tar.g

This will add a usr directory with the binaries in


Novacom is a two piece effort: a daemon an a client. First make sure you can run the daemon.

First, lets see the file type:

file novacomd

novacomd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

Let’s see what libraries it requires:

ldd novacomd => (0x008f1000) => /lib/ (0x0078a000) => not found => /lib/ (0x00110000)
/lib/ (0x006ae000)

Note that the USB library is missing. I have it installed on my system, but only the 64 bit version. To get the 32 bit version, first, figure out what the 32 bit vversion is named.

yum search libusb


And install

sudo yum install libusb.i586

F11 and the RHEL based approach for running 32bit apps on 64 makes this fairly easy to do. Unlike Debian based system which pretty much require you building a chroot if you are going to run a significant amount of 32 bit binaries, Red Hat based systems put 64 bit libraries into /usr/lib64 and 32 bit libraries int /usr/lib, so they don’t conflict. Now lddd shows we have everything:

ldd novacomd => (0x00262000) => /lib/ (0x008a5000) => /usr/lib/ (0x00770000) => /lib/ (0x00263000)
/lib/ (0x006ae00)

And we can now run this. Since it is talking straight to hardware, it insists on running as root:

[2009/9/22 11:40:48] novacomd version novacomd-62 starting…
[2009/9/22 11:40:48] novacomctl socket ready to accept
[2009/9/22 11:40:48] need to run as super user to access usb


sudo ./novacomd
[2009/9/22 11:41:11] novacomd version novacomd-62 starting…
[2009/9/22 11:41:11] novacomctl socket ready to accept
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] going online
[2009/9/22 11:41:11] novacom_register_device:188: dev ‘e851588c804e8caa722490a0314ce9782dd4d9a4’ via usb type castle-linux

No we turn our attention to the client piece.

file novacom
novacom: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
[ayoung@ayoung novacom]$ ldd novacom =>  (0x00173000) => /lib/ (0x006d2000)
/lib/ (0x006ae000)

So we are ready to run.  There is no novaterm in this deb.  Instead, you run novacom in terminal mode.  A little noted line in that I will make big here is:

./novacom $* -t open tty://0