This howto lists some small unsorted tips and tricks to work with the build service. Most of these tips should be included in other sides and removed from here. The intention of this site is to get a first place for gathering information that should be more documented or be fixed as soon as possible.

Expansion errors

the quick fix is to add one of the above packages (inetd or xinetd) to your BuildRequires

another way to fix this is to set a preference in you project config with : osc meta -e prjconf <Project> and add the line: Prefer: xinetd

the long term fix is to write a mail to opensuse-buildservice mailinglist and ask to add one of the files to the .dsc file of the repository, so other packages with the same problem can be fixed automatically.

Find Packages in a Project

Sometimes you would like to find out how a package is named, specifically in a base project to use it in the BuildRequires line. There is a tricky osc call to find that out.

This command:

osc ls -b -r standard -a i586 Fedora:20

lists all binary packages in Fedora 20. Pick the package name from the output.

See

osc ls --help

for more details.

Building 32bit rpms with local build only

If you want to build a 32bit package locally on a x84_64 machine, try:

linux32 build foo.spec

Note that osc build does this for you.

Permission denied errors

If your package builds locally without any problem but you get error messages like:

when you try to build the same package in the buildservice, please remember that the buildservice currently only supports building in the chroot environment (and your package doesn't seem to use DESTDIR resp. RPM_BUILD_ROOT at the moment).

Just add the line:

# norootforbuild

to your specfile and you'll see the same (btw: ugly) failures in your local build environment: fix these errors first before submitting to the buildservice...

_link and _aggregate

The difference between _link and _aggregate

To avoid rebuilds of packages that are just needed as build requirement for other packages or just needed because the Project wants to distribute a complete set of packages for end-users, there is the _aggregate feature in the build service.

A package that is "linked" in a new project via aggregate is not rebuilt in the new project and the binaries from the original project will be updated in the new project whenever they change.

Here are some arguments pro and contra _link or _aggregate:

Reason

_link

_aggregate

Comment

No source change is needed.

X

Aggregate is possible, but slows down your build and requires double space. Better build directly against the other repository.

I need some changes in the source for my project.

X

The original package does not build on all needed distributions or architectures.

X

X

The best way could be to have two different pseudo packages: one that uses the _aggregate function to always get just the binary packages from the original project and one that uses the _link function to build the package for the rest. (But the easiest way is certainly to ask the original maintainer to enable the missing distributions/architectures in his project.)

Make sure to not confuse package linking with project linking which is an additional feature of the build service. It is described on a project Linking page.

Examples for links

Example of a simple _link

Create a new package in your project (the name can be the same as the original package - but this is not essential) and add a file named _link with content like this:

<link project='openSUSE:Factory' package='tse3'/>

Linking against another OBS instance

If you're running a local OBS instance and just want to link some packages from the official Build Service or any other OBS instance with an available api server, add a _link-file like this:

<link project='openSUSE.org:openSUSE:Factory' package='tse3'/>

This will link the package tse3 from the openSUSE:Factory project from the Build Service instance openSUSE.org into your project.

For this example, your Build Service Admin has created an empty project named openSUSE.org in your local instance containing the line:

<remoteurl>https://api.opensuse.org/public</remoteurl>

in the project definition. No further administration work is needed.

Patches against linked packages

> Today I tried to link a package from another project to my project which
> wasn't a problem. Then I checked out the new package with osc but I only
> find a "_link"-file in the package dir. So how can I add a patch for
> example or how can I modify the specfile?

Files may be added to the linked project alone. Files in the linked project replace those with the same name
in the original project. This also includes the specfile. A patch-file can be used to
patch files in the original project without overwriting them. The patch must then be specified in the
_link file.

Adding patch files in linked packages

To have a new patch file applied to the source (in addition to any patch files already listed in the spec file), you could create a patch for the spec file that adds the patch to the spec file and apply using <apply>, but there is an easier way using the <add> command:

This will add 'mybugfix.patch' to the spec file's list of patches to apply (this works by the build service inserting the appropriate lines into the spec file for you). The new patch will be applied after any existing patches already defined in the spec file. Of course, 'mybugfix.patch' must exist in your linked project.

The <add> command also supports the attributes 'popt="NUMBER"' to add a -pNUMBER argument to %patch, 'dir="some/dir"' to change do some/dir before applying the patch and 'after="NUMBER"' to add %patch just after line with number NUMBER.

Adding a line at the top of the spec file

To add a line at the top of the spec file (for example a %define), you don't need to patch the spec file. Instead you can use <topadd>:

Examples for aggregates

Example of an _aggregate

Create a new package in your project (the name can be the same as the original package - but this is not essential) and add a file named _aggregate with content like this. Please note that _aggregates are considered as bad style usually, because the project requires double space, the build service may postpone your package builds and the risk of incompatible breakages is rather high. Usually it is better to build against further repositories like explained below to get access to packages from other repositories..:

Adding multiple repositories to a project

Adding multiple repositories to a project is very handy if a package depends (Requires or BuildRequires) on more than one Build Service repositories.

osc meta -e prj <project name>

This will open project meta editor, add more repositories under any target using <path "projectname"/>. Please note that it is not needed to add dependent repositories. The following example adds only one repository from openSUSE:Tools project. But this one builds against the openSUSE:10.3/standard repo, so all these packages gets used as well.

Another example: Add the NonFree and Update repositories to an openSUSE:10.2 project. The base openSUSE:10.2/standard repo is not needed, because both of them builds against it as well. Please note that adding the :Update project usually can lead to the situation that users will need to have all updates or they run into trouble, while building for the base distribution should work for users with and without updates. The only exception, where the :Update repo is needed are kernel modules (because the Linux kernel quite often becomes incompatible, while all other packages are not allowed to become incompatible by policy):

How is a buildenvironment defined?

That's about all there is to know about the build environment setup. Oh, we also do dependency expansion here, so packages needed because of package dependencies automatically get added to the "Required" list.

Building a package that needs an X-Server during build

This is the solution for "RuntimeError: Gtk couldn't be initialized" error. It's because of a bug version of python-gobject on openSUSE 12.3

> the package XXXXXX requires an X-server (or
> at least a DISPLAY) to build (without changing the configuration
> files).
>
> Can I access an X-Server in the buildservice?
> What are the required changes in my spec file?
You can run an Xvfb (start it in your specfile) to workaround this problem.

As example, you can use something like the lines below in your specfile:

Using different spec files for different platforms

In an ideal world, you would have a single spec file that would work on all RPM-based platforms past, present, and future. In reality, though, often a single spec file either isn't possible, or would require so many %if branches in your spec file that it would be unreadable.

Fortunately, the build service has a way in which you can use multiple spec files for individual platforms.

Imagine that you have a package named "foo" and a spec file in it called "foo.spec". Let's assume that this spec file works great for SUSE-based distributions like openSUSE, SLES, and SLED, but differences in the package layout mean that you really need a separate spec file to build for a completely different distribution like Fedora. If the repository in the build service is named "Fedora_Extras_6", you can create a spec file called "foo-Fedora_Extras_6.spec" that will be built only for that platform instead of using "foo.spec".

The only real downside to this is that it only works on an individual repository basis. There is no way to use a single spec file for multiple repositories. Revisiting the example above, if you wanted to build "foo" for Fedora Extras 4, 5 and 6, you would have to create three spec files: "foo-Fedora_Extras_4.spec", "foo-Fedora_Extras_5.spec", and "foo-Fedora_Extras_6.spec" even if each of these spec files is exactly the same.

Removing disabled but built packages from a repository

Currently the Webfrontend doesn't support this. In osc simply type:

osc wipebinaries <projectname>

You can also "talk" directly with the buildservice-API to solve this. If you want to remove all build rpms which are marked as disabled for a whole repository (in this example: home:foo), try the following way:

Create a ~/.netrc file containing your login information for build.opensuse.org or use the "-u username:password" option

Enabling rpmlint checks in buildservice repositories

Building xxbit packages for other architectures (baselibs)

How to control a Release number of resulted packages

Normally BuildService handle a Release tags automatically, so the content Release: field is replaced by tuple CI_CNT.B_CNT, where CI_CNT is a number of commits and B_CNT is a number of rebuilds (when the rebuild is triggered).

This behavior is an equivalent of

Release: <CI_CNT>.<B_CNT>

in prjconf (accessible via osc meta prjconf -e [PROJECT]).

You are able to improve it. For example for import of jpackage.org RPMs you can define in prjconf

Release: %%{?release_prefix}.<CI_CNT>.<B_CNT>

where rpm macro %{release_prefix} is defined in a spec file.
The resulting rpm will have a release number compatible with both - projects jpackage.org and openSUSE. That means you will be able to upgrade your SUSE packages to jpackage.org ones.

Or in your specfile, if your package was generate by jenkins job 123, you can directly say

Release: <CI_CNT>.<B_CNT>.j123

The resulting rpm will have '.j123' appended to its normal build release number, so that you later can review the jenkins job that initiated the build.

How to fix "does not exist" when trying to delete a project

When the backend has a timeout, you can end up with an inconsistent state between the api database and
the backend. To delete such a project just edit it's meta file with osc:

osc meta prj -e <projectname>

save it, and remove it afterwards:

osc rdelete <projectname>

Build of a SLES 11 SP1 LiveCD

Tested with kiwi-3.74-5.101.1
Install clicfs-1.1.3-3.1.x86_64.rpm and liblzma0-4.999.9beta-11.1.x86_64.rpm on the build system and copy these files to the repository directory that you configured in your /usr/share/kiwi/image/isoboot/suse-SLES11/config.xml

Modify the file /usr/share/kiwi/image/isoboot/suse-SLES11/config.xml
and added the following line to <packages type="bootstrap"> section
<package name="clicfs"/>

It might be a bug, it didn't work with this line (CD doesn't boot)

<packages type="bootstrap" profiles="std">

but with type=image the CD works fine:

<packages type="image" profiles="std">

kiwi --createhash /usr/share/kiwi/image/isoboot/suse-SLES11

Modify the config.xml for your Live CD (not the config.xml you just edited) to use clicfs:
<type primary="true" boot="isoboot/suse-SLES11" flags="clic">iso</type>

Setup a SLES 10 SP2/SP3 KIWI image with squashfs and aufs

My build host was a SLES 10 SP2 x86_64, too.

This is just a quick guide, take a look at the other KIWI documentations.

Step 1 Installing KIWI

Note: You may will find some packages on the SLES 10 SDK repository.
I installed the current kiwi-3.01-93.1 from

Note: the aufs and squashfs module gets installed to /lib/modules/<kernel>/updates/. Make sure the kernel modules fit to the kernel you are installing in the KIWI image.

Now it is time to modify the config.xml (boot/initrd image) to find the aufs and squashfs module. Maybe you copy the directory before editing, because after updating kiwi the config.xml probably will be overwritten.

cd /usr/share/kiwi/image/isoboot/suse-SLES10
vi config.xml

It is very important to add aufs and squashfs to the <drivers type="drivers"> section add the lines, without these modules the LiveCD will not be found.

Perform a nightly build from a VCS checkout

If you would like to use the _service file technique and avoid parsing/editing the .spec file and even allow for sharing of version information with debian packaging try https://github.com/boombatower/obs-git-update. Otherwise keep reading.

You need a machine with cron and osc for that.

Prepare a working directory with a VCS checkout of your code and a checkout of your package from the build service. Prepare a spec file template with a placeholder in the version field. That may look like this:

Name: monitord
Version: ##TIMESTAMP##
Requires: alsa
...

Prepare a shell script doing a local update, the preparation of the tarball, modification of the spec-file and the upload to the build service.