Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
User Guide › Usage › Local Building
ContentsContents
User Guide
  1. About this Guide
  2. I Concepts
    1. 1 Supported Build Recipes and Package Formats
  3. II Setup
    1. 2 osc, the Command Line Tool
    2. 3 Project Configuration
  4. III Usage
    1. 4 Basic OBS Workflow
    2. 5 Local Building
    3. 6 Using Source Services
    4. 7 Staging Workflow
Navigation←→
User Guide › Usage › Local Building
Top
←→

5 Local Building

Abstract

Every build which happens on the server can also be executed locally in the same environment using the osc tool. All what you need is to checkout the source code and build the build recipe. The following explains it for RPM format, but it works for any. osc will download needed binaries and execute the local build.

5.1 Generic build options
5.2 Advanced Build Environment Handling
5.3 Spec File Specials (RPM)
5.4 Kiwi Appliance Specials (KIWI)

5.1 Generic build options

Independend of the build format you need at least one source file as build description. The file name and structure is format specific. You can find some supported formats described below. To build your build format, you need:

  • the original source archive. Instead of that the package may contain a _service file which describes how to create it, for example by downloading it or building it from a SCM repository. It can also be used to create the build description file. Find more details about it in the source service chapter.

  • optional patches which changes the original source code to fix problems regarding security, the build process, or other issues

  • other files which do not fall into one of the previous categories

For existing packages, this is already the case. To build an existing package, the general procedure is as follows:

  1. If you have not done so yet, set up your project as shown in Section 4.1, “Setting Up Your Home Project”.

  2. In the terminal, choose or create a directory on a local partition that has enough space to hold the package sources.

  3. Check out the project that contains the package: 

    geeko > osc checkout PROJECT PACKAGE

    This creates a PROJECT/PACKAGE directory in the current directory.

  4. Change into the directory: 

    geeko > cd PROJECT/PACKAGE

  5. The simplest way to run a build is just to call the build command. osc will try to detect your installed OS and build for it if possible. 

    geeko > osc build

    However, you may also manualy specify the build target. For example openSUSE Tumbleweed for x86_64, you want to create the RPM package: 

    geeko > osc build openSUSE_Tumbleweed x86_64

  6. It will download the required dependencies and execute the build script. Therefore it needs to ask for root permissions in most cases.

    Successful Build
    [   15s] RPMLINT report:
[   15s] ===============
[   16s] 2 packages and 0 specfiles checked; 0 errors, 0 warnings.
[   16s]
[   16s]
[   16s] venus finished "build PACKAGE.spec" at Fri Sep  1 11:54:31 UTC 2017.
[   16s]

/var/tmp/build-root/openSUSE_Tumbleweed-x86_64/home/abuild/rpmbuild/SRPMS/PACKAGE-VERSION-0.src.rpm

/var/tmp/build-root/openSUSE_Tumbleweed-x86_64/home/abuild/rpmbuild/RPMS/noarch/PACKAGE-VERSION-0.noarch.rpm
    Unsuccessful Build
    [    8s] venus failed "build PACKAGE.spec" at Fri Sep  1 11:58:55 UTC 2017.
[    8s]

The buildroot was: /var/tmp/build-root/openSUSE_Tumbleweed-x86_64

    A successful build of a spec file ends with the creation of the RPM and SRPM files.

  7. For a detailed log, see the file /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/.build.log.

5.2 Advanced Build Environment Handling

The default build environment for local builds is usually chroot. While this is simplest environment and is therefore easy and fast to handle, it has also a number of shortcummings. For one it is not safe against attacks, so you must not build sources or using build dependendencies from a resource which you do not trust. Furthermore the environment is not fully isolated and runs not the kernel the target distribution runs. This means esp image builds and kernel/hardware specific builds may fail or won't produce the same result. The server side is usually set to inside of KVM therefore to avoid this.

  • You can build also local in KVM (if your hardware supports it) by running 

    geeko > osc build --vm-type=kvm --vm-memory=MB

  • Another important virtualization mode is qemu. This can be used to build for a foreign hardware architecture even when the distribution is not prepared for the qemu user land emulator. However, this qemu system emulator approach will be much slower. 

    geeko > osc build --vm-type=qemu --vm-memory=MB REPOSITORY ARCHITECTURE

  • You may want to jump inside of a the build environment for debugging purposes. This can be done via the following command: 

    geeko > osc shell --vm-type=VM

  • To remove the build environemnt, use: 

    geeko > osc wipe --vm-type=VM

5.3 Spec File Specials (RPM)

To create an RPM package, you need a spec file.

  • A file with the extension .changes can be used to document the package history, but it is not required.

  • OBS specific RPM macros which are set are: %_project and %_repository

5.4 Kiwi Appliance Specials (KIWI)

KIWI appliance builds create images which can be used for direct consument. Note: builds in non-VM environments do fail often due to the bootloader setup. Use osc build --vm-type=kvm for local building. OBS is evaluating kiwi builds at least two times. One time for the build host dependencies and another time for the target distribution used inside of the image. For container builds a third evaluation happens to find the base container.

kiwi builds inside of OBS need to fullfil following requirements:

  • config.xml files need to be renamed to a filename with .kiwi suffix.

  • repositories which are used must use either a URL which starts with the OBS download prefix or they must be written in obs://PROJECT/REPOSITORY syntax.

OBS extends kiwi functionality with following options:

  • A repository defined as obsrepositories:/ will used the expanded list of repositories as defined in the proejct meta. This is useful when moving kiwi image descriptions between projects, for example for development and release builds.

  • An exclusive architecture list to build for can be defined with an xml comment OBS-ExclusiveArch: ARCH_LIST

  • An excluded architecture list to skip builds can be defined with an xml comment OBS-ExcludeArch: ARCH_LIST

  • A list of profiles to build can be defined via an xml comment OBS-Profiles: PROFILE_LIST

    This can also be handled via _multibuild flavor lists by setting a fixed string of OBS-Profiles: @BUILD_FLAVOR@

  • Packages get picked usually in a fixed order from the most important repository in OBS. This happens independend of the version number of the packages. Set the xml comment OBS-UnorderedRepos to disable the repository order handling and to have a more similar behaviour as with plain package manager builds. Note: this can result into switching repositories between builds and is therefore less reproducible.

  • Container builds can specify a specific repository which shall be used for searching the base container. Use the xml comment OBS-Imagerepo:$REPOSITORY_URL for this. The repository url may be in obs://$PROJECT/$REPOSITORY style.

  • Container builds can specify additional tags via OBS-AddTag:$TAG. (kiwi limits it to one tag) in obs://$PROJECT/$REPOSITORY style.

→Chapter 6 Using Source Services←Chapter 4 Basic OBS Workflow
Print this page

© 2019 SUSE