Building sipXecs using the openSUSE Build Service and OSC

From SIPfoundry sipXecs IP PBX, The Open Source SIP PBX for Linux - Calivia

Jump to: navigation, search

Contents

openSUSE Build Service

Novell / SUSE created a public service for building packages called the openSUSE Build Service. Build Service not only builds packages for openSUSE and SLE/SLED distributions, but also Red Hat RHEL, CentOS and Fedora. It can build for x86 (i386 / i586) and also 64bit x86_64 architectures. Building for PPC and PPC64 is not yet publicly available since there is no secure virtual machine environment for this architecture available according to Novell. Registration to the build service is open and everyone interested can create an account. Once you have an account you can create a project that will be called home:<your login name>. The SuSE Build Service automatically creates repositories where all packages that are successfully built are put. These repositories can directly be used for installations. Automatic re-builds are triggered if any of the dependencies change. Detailed build logs are available.

SuSE also offers an offline tool called OSC. OSC is a python application that allows managing the SUSE build service from the command line. It should be possible to find a version for any Linux distribution. On CentOS5 osc-0.120-6.1 is known to work. OSC is similar to subversion as it allows to version control tarballs and spec files uploaded to the build service. The commands are very similar to svn. OSC also allows building locally on your machine. This shall be further described below.

The home:sipfoundry project

There currently is a project called home:sipfoundry that builds the current sipXecs mainline. Go to http://software.opensuse.org/search and search for e.g. the package "sipxecs".

Building on a local machine with OSC

Often it would be great if you could build the sipXecs project or a specific package for an architecture or even Linux distribution that is different from what you have running on your developer workstation. This is easy to do with OSC.

  1. Create an account with Novell. Upon first use of OSC it asks for a username/password for the Build Service. You can then checkout any project you like, even if it is not yours, so not sure why credentials are needed, but they are
  2. Install a version of OSC that works in your environment. The openSUSE:Tools repo likely includes it for your distro.
  3. check-out the home:sipfoundry project: osc co home:sipfoundry
  4. cd into the directory of the package you want to build
  5. use "osc repos" to get a list of available repositories
  6. build locally: osc build --no-verify openSUSE_10.3 i586 <package>.spec (this will build for the openSUSE 10.3 distribution, using the 32bit i586 architecture). Sometimes the first build attempt seems to fail. Try again letting OSC clean the build root.

The local copy of the project you want to build can include local modifications. With this RPM builds can be tested before checkin in changes to svn, so that from now on RPM builds should be rarely broken ;)

How do the files get uploaded to the Build Service?

Currently this is a manual process and the idea is to do this on a e.g. weekly basis. It will trigger a complete rebuild, which typically takes 12 to 24 hours, dependent on server load. The Build Service automatically updates the revision numbers. Tarballs and .spec files need to be manually uploaded. The .spec file needs to be separate as the Build Service seems unable to extract it from the tarball. In addition, a patch is required on top of the current mainline to add the necessary BuildRequires into the .spec files. See here: http://track.sipfoundry.org/browse/XX-6294.

Useful Links

Can mock be used instead of OSC?

Yes, with this same patch applied building using "mock" is also possible, provided that mock has access to a repository that includes all the dependencies. Using OSC makes this easier as it automatically taps into the project's repository to install dependencies.

Nice Improvements

If you find this interesting and would like to help improving it, here are some suggestions:

  1. svn revision numbers are not propagated into builds done from tarballs.
  2. The sipXecs build system conventions do not fully comply with standards set by Red hat and SUSE. rpm lint tests turned on for openSUSE 11.1 are not passed and cause the builds to fail
  3. Automatic (e.g. weekly) upload of new tarballs and .spec files from svn would be nice
  4. It builds RPMs, but does not run unit tests. Doing both would be nice.
  5. Getting rid of dependencies. We still seem to have too many dependencies. Reducing them should be a goal.
Personal tools