Build Service/Tips and Tricks

From openSUSE

Revision as of 09:35, 15 January 2009

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

Most of the informations are gathered from the buildservice-mailinglist.

Disable build of packages

There is a way to disable single packages to be built. One way to disable building of packages is to use the 'osc' commandline client. Just use

osc meta pkg -e <project> <package>

and add the <disable>-Tag to the package metadata. You can either use:

<disable arch="<build-arch>"/>
 

or

<disable repository="<name-of-build-repository>"/>

or both, like:

<disable repository="SLES_9" arch="x86_64"/>

Another way is to use the webclient and click the appropriate button while showing the package in question.

Aborting currently building package

osc abortbuild <project> <package> <repo> <arch>

Expansion errors

If you get something like

expansion error have choice for inet-daemon needed by imap: inetd xinetd

for a package, then you have two options:

• the quick fix is to add one of the above packages (inetd or xinetd) to your BuildRequires
• 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.

Known 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:9

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

See

 osc ls --help 

for more details.

Handling builds inside the Build Service specially

If you use your spec file in other places than in the Build Service and for some reason you need to distinguish, you can use the macro %opensuse_bs, like

%if 0%{?opensuse_bs}
# bs-specific part here
%endif

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:

 /usr/bin/install: cannot create regular file `/usr/lib/libfoo.so.0.0`: Permission denied

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 which are just needed as build requirement for other packages or just needed because the Project wants to distribute a complete set of packages for endusers, there is the _aggregate feature in the build service.

A package which is "linked" in a new project via aggregate needs no rebuild in this new project. It is enough to make the binaries from the original project available in the new project.

Here are some arguments pro and contra _link or _aggregate:

Example of a _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 like this:

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

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.

<link project='openSUSE:Factory' package='tse3'>
  <patches>
    <apply name="patch" />
  </patches>
</link>

Including patches in linked packages

To append a patch to the spec file, you either have to create a patch for the spec file which adds the patch to the spec file, or use the <add> command:

<link project='openSUSE:Factory' package='tse3'>
  <patches>
    <add name="patch" />
  </patches>
</link>

This will append the patch on top of all other patches to the .spec file and build it with that patch applied.

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 can may postpone your package builds way more 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..:

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
  </aggregate>
</aggregatelist>

If the repository names don't match you can specify a mapping with the <repository> element (source is the repository name from the original package):

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
    <repository target="openSUSE_10.2" source="SUSE_10.2" />
    <repository target="openSUSE_10.1" source="SUSE_10.1" />
  </aggregate>
</aggregatelist>

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 dependend 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.

 <repository name="openSUSE_10.3">
   <path project="openSUSE:Tools" repository="openSUSE_10.3"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
 </repository>

Another example: Add the NonFree and Update repositories to a 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 becames quite often incompatible, while all other packages are not allowed to become incompatible by policy):

<repository name="openSUSE_10.2">
   <path project="openSUSE:10.2:Update" repository="standard"/>
   <path project="openSUSE:10.2:NonFree" repository="standard"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

How is a buildenvironment defined?

It's defined /usr/lib/build/configs/$distro.conf in the build package. Here comes a description of the fields in this file:

Preinstall: <packages>

The packages that need to be unpacked for build environment setup. This is basically everything that is needed to get rpm/dpkg running, i.e. glibc and the like.

Runscripts: <packages>

A subset of the preinstall packages. It describes which packages need to have their postinstall scripts run.

Required: <packages>

These are the packages that make the "normal" build environment, i.e. stuff like gcc, autoconf, automake and the like.

Support: <packages>

Convenience packages, like "vim" or "strace". The difference to "Required" is that the automatic rebuild detection does not look at support packages, i.e. you don't get an automatic rebuild if "strace" is changed.

This list also includes some "-devel" packages and other subpackages of the "Required" packages to keep the Required list small. (I.e. we don't need both "zlib" and "zlib-devel" in Required because both are built from the same source)

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.

So, the default package list is

Preinstall + Required + Support + packages from dependency expansion.

Some words about the other fields:

Keep: <packages>

We really need those packages. Normally, subpackages of the package that we want to build don't get installed. But even if we want to build the "patch" package, we need a working patch program to apply patches from the specfile. So we have "Keep: patch". The preinstalled packages are automatically added to this list.

Prefer: <positive-package>

Prefer: -<negative-package>

This information is used to break ambiguities.

Ignore: <package>:<package>

This breaks dependencies for the package expansion step.

Ignore: portmap:syslogd

means that we don't need an installed syslogd if we have to install the portmap package.

Building a package, which needs an X-Server during build

> 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.

Using different spec files for different platforms

In an ideal world, you would have a single spec file which worked 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", which 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.

A good example package which actually uses this is the "net-snmp-main-snapshot" package in the net-snmp project.

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 informations for build.opensuse.org or use the "-u username:password" option

• curl -n -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'

  or

  curl -u username:password -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'

For more "commands" have a look at the API documentation.

List available packages in a distro

When you don't know the exact name of the package you need for your build, you can either use the web search or osc ls -b.

Example: which package contains mysql development files on Ubuntu?

#           <repository> <arch> <project>
$ osc ls -b -r standard -a i586 Ubuntu:7.10 | grep 'mysql.*dev'
libmysqlclient15-dev_5.0.45-1ubuntu3_i386.deb
# -> the package is called "libmysqlclient15-dev"

Enabling rpmlint checks in buildservice repositories

Please have a look at the RpmLint page and this chapter.

Building xxbit packages for other architectures (baselibs)

See Build Service/baselibs.conf