DPI908/SBR600 Koji Lab

Purpose

To use and become familiar with the koji tool.

Koji is a client-server system which allows you to queue builds within the Fedora build farm. This permits you to test whether your package builds on multiple different architectures, which is especially useful when you don't otherwise have access to the machines of each architecture. For example, if you are working on a 32-bit PC, you won't be able to directly test builds on a 64-bit PC architecture (x86_64), nor non-PC architectures such as ARM, MIPS, PA-Risc, IA64, S390, Sparc, and PowerPC.

Background Resources

• Fedora Wiki - Using Koji

Required Resources

Before starting this lab, you will need:

1. A Fedora Account System (FAS2) account.
2. The SRPMs from the previous lab.

Preparation

• Follow the procedure on the UsingKoji page on the Fedora wiki for setup instructions.

Steps

Koji is a client-server system. Your computer runs the client software, which will submit the build job to a koji build hub. The build task will go through several states as it is picked up from the koji hub by a builder (a separate server system which retrieves jobs from the koji-hub and builds them) and that build either succeeds or fails.

The main use of the Koji system is to test builds on systems of a different architecture (such as an s390 mainframe) or a different release (such as Fedora 23 when you're running Fedora 22) as well as to prepare the final builds for release.

Queueing the Build Request

To queue the build request on the main koji server, used for primary architecture builds (i386, x86_64, and ARM):

1. Issue the command: koji build f18 --scratch yourSRPM
   • f18 (called the Target) instructs koji to build the package using the packages available in the Fedora 18 distribution, and prepare it for inclusion in that distribution. Note: for versions of Fedora prior to f16, use dist-fXX where XX is the release.
   • The --scratch option causes koji to build the package but not tag it for the target (i.e., not to include it in Fedora). To perform a build that will be passed to Bodhi for distribution, substitute --rebuild for --scratch and use a git URL for the package (do not do this until you have passed the package review and sponsor procedures!).
2. You can either follow the progress of the build by leaving the command running, or you may interrupt the koji command by pressing Ctrl-C once the message "this may be safely interrupted" is printed. Record the taskID printed for future reference.

To queue the build request on the koji server for another architecture, substitute arch-koji for the koji command. For example: s390-koji build f18 --scratch foo*.src.rpm -- note that many of the koji servers handle multiple architectures -- e.g., the s390 server handles two architectures (s390 and s390x).

Use Koji to build a scratch package for each of the following architectures:

• Primary architectures (submit using the "koji" command):
  • i386 (32-bit AMD/Intel)
  • x86_64 (64-bit AMD/Intel)
  • armv7hl (32-bit ARM with FPU)
• s390 mainframe architectures (use the S390 koji server):
  • s390
  • s390x
• PowerPC architectures (use the PPC koji server):
  • ppc (32-bit)
  • ppc64 (64-bit)
• additional ARM architecture (use the armv6 koji server):
  • armv6hl / Pidora (ARM architecture optimized for armv6 (Raspberry Pi))
    • Note: See this blog post for details on accessing the Pidora koji system.

Viewing the Build Request Status

You can view the status of a task through:

• The original koji command, if you did not interrupt it.
• The command: koji watch-task taskID
• Using the web interface.
  • For the primary arch koji system, go to https://koji.fedoraproject.org
  • For any of the secondary arch koji system, go to https://arch.koji.fedoraproject.org (e.g., http://arm.koji.fedoraproject.org for the ARM koji web interface)
  • For the Pidora koji system, go to http://koji.pidora.ca

Solving Architecture-Specific Errors Identified with Koji

Arch-Specific Conditionals

If your package does not build on a particular architecture using the same spec file contents as on the primary architectures, you can use architecture-specific conditionals to include or exclude parts of the spec file.

To include parts of a specfile only on a particular architecture (ppc in this example):

%ifarch ppc
BuildRequires: foo
%endif

To exclude parts of a specfile only on a particular architecture:

%ifnarch ppc
BuildRequires: bar
%endif

You can also use %else to specify alternation:

%ifarch ppc
%configure --baz
%else
%configure --qux
%endif

Excluding an Architecture

If a package will not build on a particular architecture, perhaps because the BuildRequires are not available on that arch, you can specify that the package should be excluded from that arch:

ExcludeArch: ppc

If a package only applies to a certain architecture -- for example, it is CPU-specific microcode -- it can be marked as such:

ExclusiveArch: x86_64

Note that ExcludeArch is preferred over ExclusiveArch except where the package is definitely architecture-specific.

Arch Macros
Some architectures exist in multiple versions. In these cases, a macro is provided which expands to all of the arch names within a family; for example, to exclude all of the ARM varients, use ExcludeArch: %{arm}

Deliverable

Create a blog post describing your experience. Include:

• Notes on what you did, and what worked and didn't work.
• How long the overall process took, and the koji build for each architecture (contrast this with the mock and rpmbuild times).
• The results, including a link to your SRPM if it was modified from your previous lab, and interesting snippets from the log files.
• Your reflections on the tools, process, and experience.