wget ftp://ftp.cc.uoc.gr/mirrors/linux/fedora/linux/development/rawhide/source/SRPMS/supervisor-3.0-0.4.a10.fc16.src.rpm

The simplest way to build an RPM for our CentOS release is to use the --rebuild option of rpmbuild:

rpmbuild --rebuild supervisor-3.0-0.4.a10.fc16.src.rpm

Wait a few seconds for it to finish and then your binary RPM package will be in ~/<your_building_env>/RPMS/....

To satisfy dependencies, you will also need the package python-meld3. So, download and rebuild it:

wget ftp://ftp.cc.uoc.gr/mirrors/linux/fedora/linux/development/rawhide/source/SRPMS/python-meld3-0.6.7-4.fc16.src.rpm
rpmbuild --rebuild python-meld3-0.6.7-4.fc16.src.rpm

Having built RPM packages for supervisor and python-meld3, you can now transfer them to a testing box and install them:

yum localinstall /path/to/supervisor.rpm /path/to/python-meld3
yum install python-elementtree

We also installed elementtree as this is a dependency missing from the supervisor spec file (note to self: file a bug report).

Finally, try to start supervisord:

/etc/init.d/supervisord start

Surprisingly, it complains about the missing elementtree!

Starting supervisord: Traceback (most recent call last):
  File "/usr/bin/supervisord", line 5, in ?
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ?
    working_set.require(__requires__)
  File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: elementtree

Checking the requirements file at: /usr/lib/python2.4/site-packages/supervisor-3.0a10-py2.4.egg-info/requires.txt there are no special version requirements:

meld3 >= 0.6.5
elementtree
[iterparse]
cElementTree >= 1.0.2

After some investigation on the supervisor-users mailing list, I found a message that indicated that setuptools.setup() should be used instead of distutils.core.setup() in the setup.py script.

So, the dependency resolution depends on the way the package has been installed! I didn’t even bother to patch setup.py… Knowing that the dependencies are correctly installed, I commented out the elementtree line and also the meld3 line as this caused the same error.

So, my /usr/lib/python2.4/site-packages/supervisor-3.0a10-py2.4.egg-info/requires.txt file looks like this:

#meld3 >= 0.6.5
#elementtree
[iterparse]
cElementTree >= 1.0.2

Now supervisor starts without errors:

# /etc/init.d/supervisord start
Starting supervisord:                                      [  OK  ]
# cat /var/log/supervisor/supervisord.log
2011-05-12 02:56:08,221 CRIT Supervisor running as root (no user in config file)
2011-05-12 02:56:08,267 INFO RPC interface 'supervisor' initialized
2011-05-12 02:56:08,267 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2011-05-12 02:56:08,271 INFO daemonizing the supervisord process
2011-05-12 02:56:08,272 INFO supervisord started with pid 21337

This is what it takes to run supervisord 3 in CentOS 5 or RHEL 5. If you have any comments and suggestions, please let me know in the comments below.

Related Articles

• High CPU usage while running CentOS as guest on Virtualbox or VMware
• Sticking with CentOS, RPMforge and yum-priorities for now
• YUM-Priorities Configuration for a CentOS Desktop
• Awaiting CentOS 6
• My running dog

There is an ongoing discussion about it at LWN you might find interesting.

Related Articles

• The Complete Fedora Kernel Headers
• Build a single native kernel module
• Software that detects violations of open source licenses
• Kernel 2.6.17 and lirc_gpio driver
• Get my kernel headers script

mkdir ~/rpmbuild \
    ~/rpmbuild/BUILD \
    ~/rpmbuild/RPMS \
    ~/rpmbuild/SOURCES \
    ~/rpmbuild/SPECS \
    ~/rpmbuild/SRPMS

Now, create the file ~/.rpmmacros and put the following basic macros in it:

%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags  -j3
%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

The %_topdir macro is set to the path of the root directory of your RPM building environment, /home/[user]/rpmbuild in this case.

The %_smp_mflags macro usually contains only the -j (–jobs) option for the make command, which defines the number of jobs (make commands) that may run simultaneously. Usually, this is set to the number of CPU cores plus one. So, on a dual core CPU, the smp flags are set to -j3.

The %__arch_install_post macro contains various checks that should be run on the files in the BUILDROOT location. I trust Fedora guys and use the defaults check-rpaths and check-buildroot on Fedora and CentOS. This macro is optional.

All macros that are set in ~/.rpmmacros override the system-wide macros that have been set in other locations. To check which paths are checked for macro files, enter the following command:

rpm --showrc | grep macrofiles

The following command shows the current configuration for RPM building:

rpm --showrc

All the available macros can be found in /usr/lib/rpm/macros.

Related Articles

• How To Build RPM Packages on Fedora
• chroot Environment Howto
• SPEC File Directory
• Running supervisor 3 on CentOS 5
• Build a single native kernel module

This plugin allows repositories to have different priorities. Packages in a repository with a lower priority can’t be overridden by packages from a repository with a higher priority even if repo has a later version.

Here follows my yum repositories configuration:

# Custom builds
[local-rpms]
name=Local Yum Repository
baseurl=ftp://192.168.0.70/pub/linux/centos/$releasever/$basearch/
enabled=1
gpgcheck=0
#gpgkey=
priority=1
# core packages
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=10
#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=10
#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons
#baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=10
#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=10
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=20
#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=20
[adobe-linux-i386]
name=Adobe Systems Incorporated
baseurl=http://linuxdownload.adobe.com/linux/i386/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
priority=30
# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag
# URL: http://rpmforge.net/
[rpmforge]
name = Red Hat Enterprise $releasever - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1
priority=40

Here are some notes:

• A repository’s priority is rated like this: the smaller the priority number, the higher the priority of the repository. Packages from a specific repository cannot override (upgrade) packages of a repository with higher priority (smaller priority number).
• In the above setup, the repository with the highest priority is my Local RPM repository. This repo contains custom builds of packages. Custom builds means that I have enabled or disabled specific compilation-time switches or that I have used a patch that is not yet used in the mainstream package. Usually, when I create custom builds of RPMs, I know what I am doing and, of course, I do not want my custom RPMs to be overridden by packages from other repositories, even official ones. So, this repository has the highest priority (priority=1).
• base, updates, addons, extras are the official CentOS repositories and they all have priority 10.
• As you can see in the above setup, centosplus and contrib repositories are not enabled. However, I have set a priority number that is between (priority=20) the priority number of the official repositories and the priority number of the 3rd party repositories.
• Next comes Adobe‘s yum repository (priority=30) and finally RPMforge (priority=40). These are both 3rd party repositories. I highly recommend that you choose your 3rd party repositories carefully and set their priorities wisely. I would also advise against setting the same priority on two or more 3rd party repositories, unless you are 100% certain that they complement each other. If I ever use any other 3rd party repository, it will get a priority higher than 40 and so on.

So, this is how I have configured priorities on yum repositories at the moment. Note that this configuration is used on my desktop. On my Xen Dom0 and the four DomUs, which by the way all run CentOS, I use EPEL instead of RPMforge. Remember, it’s your own software needs that govern the use of 3rd party repositories.

Your feedback is welcome.

Related Articles

• Sticking with CentOS, RPMforge and yum-priorities for now
• Local YUM Repository
• Fedora Server vs CentOS
• Running supervisor 3 on CentOS 5
• Zim – a Desktop Wiki

While using EPEL+RPMfusion I tried to rebuild several Fedora SRPMs for use in CentOS. Many of them were built without dependency issues, but soon I came to a dead-end with some packages (also known as Dependency Hell™) which required me to upgrade some core CentOS packages which in turn required the upgrade of some other core packages, which is generally considered a Very Bad Thing™ to do. This was an expected thing to happen, since Fedora uses newer versions of software than RHEL. Also, this somehow reminded me the reason why I had switched to CentOS; spending the least possible time hacking around the operating system, that is. So, I quickly abandoned EPEL and RPMfusion. I liked the idea behind that effort though, so it won’t be a surprise if you find me in #epel.

Having read the above two paragraphs, one might think that I somehow do not value RPMforge as much as EPEL. This is not correct. While EPEL sticks to the Fedora procedures, thus leaving almost no room for collaboration with other 3rd party repositories, RPMforge is the result of the collaborative work of some well-known RPM packagers for RHEL and compatible linux distributions and also provides high quality RPMs. BTW, there are times that I prefer projects driven by a small community rather than a very big one, such as the Fedora Community.

Apart from the above repositories, I also use Adobe‘s yum repository for the Flash plugin and the official Open Office RPM distribution (excluding JRE) from OpenOffice.org.

So, I’ve found myself happy with CentOS and I think I’ll stick with it for a while. Hopefully, not having to deal with so many bugs like it happened in Fedora will leave me with some more free time to get some things done in my own open-source projects or contribute to other projects.

Related Articles

• YUM-Priorities Configuration for a CentOS Desktop
• Awaiting CentOS 6
• Fedora Server vs CentOS
• Running supervisor 3 on CentOS 5
• Almost saying goodbye to innovation

RPM

For RPMs you need two command line utilities, rpm2cpio and cpio. Extracting the contents of the RPM package is a one step process:

rpm2cpio mypackage.rpm | cpio -vid

If you just need to list the contents of the package without extracting them, use the following:

rpm2cpio mypackage.rpm | cpio -vt

The -v option is used in order to get verbose output to the stdout. If you don’t need it, you can safely omit this switch. For more information about the cpio options, please refer to the cpio(1) manual page.

DEB

DEB files are ar archives, which contain three files:

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

As you might have already guessed, the needed archived files exist in data.tar.gz. It is also obvious that unpacking this file is a two-step process.

First, extract the aforementioned three files from the DEB file (ar archive):

ar vx mypackage.deb

Then extract the contents of data.tar.gz using tar:

tar -xzvf data.tar.gz

Or, if you just need to get a listing of the files:

tar -tzvf data.tar.gz

Again the -v option in both ar and tar is used in order to get verbose output. It is safe not to use it. For more information, read the man pages: tar(1) and ar(1).

If anyone knows a one step process to extract the contents of the data.tar.gz, I’d be very interested in it!

Update

As Jon suggested in the comment area, the contents of data.tar.gz can be extracted from the DEB package in a one step process as shown below:

ar p mypackage.deb data.tar.gz | tar zx

That will do it.

Related Articles

• Choosing a format for data backups – tar vs cpio
• How To Build RPM Packages on Fedora
• VeriTAR – Verify checksums of files within a TAR archive
• Verify a burned CD/DVD image on Linux
• Linux Tips – Pack I

Anyway, I still package a bunch of RPMs for my systems. I decided to upload some of the spec files. These are available in this directory. There are many more, but they need a bit of polishing.

Some notes:

• The nvidia-legacy spec file generates RPMs for the OpenGL libraries and the NVidia Legacy driver (for GF2 for example). These packages do not replace any core Fedora files. The official installation script from NVidia replaces some files and it should not be used.
• These spec files are completely unsupported. Don’t send me emails about them, unless you find any mistakes in them. For information about building RPMs on Fedora refer to my relevant small article.
• The spec files are for software that does not exist in the repos mentioned above (except for kernel modules, for which I don’t wish to wait until Livna releases new versions). I haven’t submitted any of them to Extras or Livna because I don’t have the time to update them in time. The files comply with the Fedora packaging guidelines and naming schemes.
• Dependencies in the alexandria and ruby-related spec files were updated by Leeksoup for FC5. I don’t use this software anymore, so I appreciate it :-)

Packaging is art :-)

Related Articles

• Fedora Core 5
• How To Build RPM Packages on Fedora
• File and Directory diff in color in Midnight Commander
• GNOME 2.14, Rawhide, SUSE and more…
• Sticking with CentOS, RPMforge and yum-priorities for now

What Is An RPM Package?

In simple terms, an RPM package is an advanced form of a container for other files. Generally, it includes:

1. The program to be installed plus all the necessary files that accompany this program.
2. Information about the program and the RPM package itself.
3. Information about the program’s dependencies, which means info about what other software needs to be installed, so your program to function correctly in the system.
4. Information about potential conflicts between the program and other software that is currently installed in the system.
5. Actions that need to be performed when the program is installed/upgraded/removed.

But, this is enough with the theory. For more information, refer to the links at the Further Reading section of this article.

Prerequisites

The following are needed in order to build RPM Packages.

• The development tools. All the utilities that are needed to compile a program, including the compiler itself.
• A SPEC file for the particular program you want to create an RPM package for. A SPEC file contains all the information regarding the program’s details, its dependencies, the compilation options etc. For more info on writing SPEC files, refer to the links at the Further Reading section of this article.

Things You Need To Do Once

There are a couple of thing you need to do before starting building your RPMs. These mainly include the installation of the core development tools and the creation of the building environment for your user.

Install the core development tools using YUM. As root:

# yum groupinstall "Development Tools"

Next, create the building environment for your user. Fortunately, Fedora includes some neat utilities that greatly simplify this procedure. First, use YUM to install them (as root):

# yum install rpmdevtools

Then, create the directory structure in your home directory by issuing the command (as a user):

$ rpmdev-setuptree

That’s it.

Build That RPM!

Provided that you have a SPEC file for your program, you can build the binary RPM package by issuing the command:

$ rpmbuild -bb --clean myprogram.spec

If you need to build the package for a different architecture, you can set the --target option, like in the example below:

$ rpmbuild -bb --clean --target i686 myprogram.spec

Please note that you should never build RPM packages using root.

Dependencies

Some programs may need additional development libraries in order to be compiled. You can use YUM to install these needed libraries (-devel packages) or programs. If the operation finishes succesfully, you’ll find your RPM package in the ~/rpmbuild/RPMS/ directory.

Further Reading

This small article’s goal was to get you started with art of RPM packaging by setting up the environment for RPM building. It’s a "Batteries Not Included!" article though. Information about how to write SPEC files is not available here. It would be pointless, as there are some excellent resources for this purpose. So, prepare for some real reading ladies and gentlemen:

1. Chapter 4. Building RPM Packages of the Fedora Core Developer’s Guide by Tammy Fox, Havoc Pennington – General information about the SPEC file sections.
2. Chapter 8. Creating RPMs: An Overview of the RPM Guide by Eric Foster-Johnson – In depth information about SPEC files.
3. Packaging Guidelines by Tom ‘spot’ Callaway – Information specific to writing SPEC files for Fedora Core.
4. Package Naming Guidelines by Tom ‘spot’ Callaway – Information specific to Fedora RPM naming scheme.
5. RPM scriptlet recipes – Some extremely useful notes regarding the actions that need to be performed when a package is installed/upgraded/removed from the system, which should be included in the relevant sections of the SPEC file.
6. Maximum RPM – Taking the RPM Package Manager to the Limit – An excellent book about the RPM Package Manager, by Edward C. Bailey, Paul Nasrat, Matthias Saou, Ville Skyttä.

Changes

Wed 23 Jan, 2008

This article has been updated to reflect the changes in the package names for rpmdevtools. The old package, named fedora-rpmdevtools, is now known as rpmdevtools. Also, the utility that sets up the initial rpmbuild directory tree is now called rpmdev-setuptree (old name was: fedora-buildrpmtree).

Related Articles

• Build a single native kernel module
• SPEC File Directory
• The Complete Fedora Kernel Headers
• How to extract RPM or DEB packages
• The road to Alexandria…