First experiences with the OpenSUSE Build Service (OBS). 4

As part of my Openismus training, I was recently tasked with packaging a Qt application using the OpenSUSE Build Service (OBS). Here I’ll try to note my first impressions as well as offer some solutions to problems I encountered.

Note: This was my first attempt at packaging anything and the application I’m packaging (ConferenceGoer) is a personal project which is in an unusably-early state. So let’s ignore all that and focus on OBS itself.

What is OBS

The OBS allows a packager to create packages for multiple distributions and architectures using one spec file for RPM packages or one set of debian packaging files for debian packages. For example, in my OpenSUSE OBS repository I’ve built packages for multiple releases of Fedora, Ubuntu, OpenSUSE, Mandriva and Debian for the i586 and x86_64 architectures from one set of package files.

Despite the “OpenSUSE” in the name, the OBS is useful for other distros as well. For example, the MeeGo project has adopted it as its build-service of choice. I’ve used both and will refer to them as the OpenSUSE OBS and MeeGo OBS.

This is not an OBS how-to. See the OBS tutorial for getting started with OBS.

Some notes (in no particular order)

Generated moc_ files in tarball

One of the problems I ran into while packaging ConferenceGoer was that the tarball that is generated from the Makefile (which is generated from qmake), includes moc_* files. As anyone familiar with Qt knows, these are genereted files. The problem that this causes is that moc_* files generated with a newer version of Qt (4.7 in my case) will not always be compatible with older versions of Qt. As older distros do not package the newer version that you may be developing against, this will cause build problems. The easy fix for this is to remove the moc_* files from the tarball. qmake will regenerate these files for you anyway during the build process making them unnecessary.

Interacting with the OBS

There are 2 ways to interact with the OBS. The first way is using the web interface and the other is using the command-line tool (osc). I found that a mix of these worked best. The web interface can be annoying and slow for certian tasks. Triggering a build and uploading new versions of your files takes far too long. You can use the command line tool much like you would any svn client. You make you local changes, commit them with a message, and repeat. The commit will trigger an automatic rebuild. This seems to happen much faster using osc than with the web-interface. In short, use osc when you can and use the web-interface for watching the packages build status.

OpenSUSE OBS downtime

Annoyingly, the OpenSUSE OBS site seems to be unreachable rather often. It’s also rather slow. The MeeGo OBS is fast and seems reliable though. I’m guessing this has to do with the high load on the OpenSUSE OBS. Still it’s annoying.

Moving from the OpenSUSE OBS to the MeeGo OBS

If you ‘ve managed to get everything working in the OpenSUSE OBS, moving to the MeeGo OBS should be simple. For ConferenceGoer I just needed to remove the ifdef’s for all OS’s other than the redhat-based distros. We then need to remove all Qt version info from the package names. For example, qt4 becomes qt and qmake-qt4 becomes just qmake. MeeGo only has Qt4 packages so this distinction is not needed.

Also to note is that getting access to the MeeGo OBS is a manual process. You’ve got to have a meego acount set up and request access on irc.

Font problem with Qt apps in MeeGo.

Once the package was installed on MeeGo (on the nice netbook we were given at the Dublin conference), I found that the fonts looked terrible. This turned out to be a known bug. Seems you can tweak a config file to get it looking OK but hopefully this is now fixed.

Conclusion

Overall I think the OBS is a very nice tool. It’s rather gratifying to be able to build for so many different distro/version combinations with such little effort. The command-line tool is intuitive and works well. I’d like to be able to access the OpenSUSE OBS instants on a more regular basis however.

I plan on building some new cluttermm packages soon to encourage more people to start testing and using it as well as to practice packaging libraries. So keep an eye on my repository.

4 thoughts on “First experiences with the OpenSUSE Build Service (OBS).

  1. Reply outerway Mar 1, 2011 05:43

    The slowness should not be so much due to amount of jobs being built (that just results in delay), but I think the larger problem is that they use interpreted scripting languages, and with such a large package base, that penalty shows off. It is well known that interpreted languages like Perl can be around 12x slower than a C equivalent. The ruby processes that serve the HTTP interface are no model child either ? as can be seen from their long startup time (the CPU burning they do right after lighttpd start up until they enter the sleep state, as seen in top).

  2. Reply andrew Mar 1, 2011 18:54

    Sometimes, being overloaded can be caused from people possibly un-necessarily adding 20+ different build targets (cough) to their repositories. The ability to be able to build for several distributions is great, but enabling all of them just for fun can of course strain the poor OBS.

  3. Pingback: Doubts in OpenSUSE « It's impossible to be unhappy on a skateboard.

Leave a Reply