6 Local Building #

Every build that happens on the server can also be executed locally in the same environment using the osc tool. All you need is to check out the source code and run osc build to run 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.

6.1 Generic Local Build Options #

Frequently, local builds are undertaken on local checkouts of source packages that already reside on an OBS server - for example, to test changes before commiting them to the server.

It is also possible to trigger a local build in an arbitrary local directory containing sources, without any corresponding source package on an OBS server. (However, osc will still need a connection to the server in order to download build dependencies.) The following text describes what the source directory should contain, at a minimum.

Independent 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

In the typical case of source packages locally checked out from an OBS server, this is already the case. To build an existing package, the general procedure is as follows:

If you have not done so yet, set up your project as shown in Section 5.1, “Setting Up Your Home Project”.
In the terminal, choose or create a directory on a local partition that has enough space to hold the package sources.
Check out the project that contains the package:
```
geeko > osc checkout PROJECT PACKAGE
```
This creates a PROJECT/PACKAGE directory in the current directory.
Change into the directory:
```
geeko > cd PROJECT/PACKAGE
```
The simplest way to run a build is just to call the osc build command. osc will try to detect your installed OS and build for it if possible.
```
geeko > osc build
```
However, you may also manually 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
```

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.

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

6.2 Advanced Local 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 shortcomings. For one it is not safe against attacks, so you must not build sources or using build dependencies from a resource which you do not trust. Furthermore the environment is not fully isolated and runs on 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 also build locally 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 environment, use:
```
geeko > osc wipe --vm-type=VM
```