< KojiRedirect page
The web interface
The primary interface for viewing Koji data is a web application . Most of the interface is read-only (providing information such as build logs), but if you are logged in (see below) and have sufficient privileges there are some actions that can be performed though the web. For example:
- Cancel a build
- Resubmit a failed task
- Setup a notification
Those with admin privileges will find additional actions, such as:
- Create/Edit/Delete a tag
- Create/Edit/Delete a target
- Enable/Disable a build host
The web site utilizes Kerberos authentication. In order to log in you will need a valid Kerberos ticket and your web browser will need to be configured to send the Kerberos information to the server.
In Firefox or Mozilla, you will need to use the about:config page to set a few parameters. Use the search term 'negotiate' to filter the list. Change network.negotiate-auth.trusted-uris to the domain you want to authenticate against, e.g .example.com. You can leave network.negotiate-auth.delegation-uris blank, as it enables Kerberos ticket passing, which is not required. If you do not see those two config options listed, your version of Firefox or Mozilla may be too old to support Negotiate authentication, and you should consider upgrading.
In order to obtain a Kerberos ticket, use the kinit command (from the krb5-workstation package).
With Koji you can setup a notification requests, to make sure you do not miss when a package you care about gets build. Login and scroll to the bottom of the page, there you should find a Add a notification link and a list of your configured notifications.
Installing the Koji Cli
yum install koji
There is a single point of entry for most operations. The command is called 'koji' and is included in the main koji package. The koji tool authenticates to the central server using Kerberos, so you will need to have a valid Kerberos ticket to use many features. However, many of the read-only commands will work without authentication.
Initial Fedora setup
In order to interface with the koji server, maintainers will need to run
after installing the koji package for the first time.
Existing users of plague, it will reference certs already existing. If you did not have plague before, it will tell you where to get the certs.
Building a Package
Builds are initiated with the command line tool. To build a package, the syntax is:
$ koji build <build target> <cvs URL>
$ koji build dist-f8 'cvs://cvs.example.com/cvs/dist?rpms/kernel/FC-7#kernel-2_6_20-1_2925_fc7'
The koji build command creates a build task in Koji. By default the tool will wait and print status updates until the build completes. You can override this with the --nowait option. To view other options to the build command use the --help option.
$ koji build --help
There are a few options to the build command. Here are some more detailed explanations of them:
--skip-tag Normally the package is tagged after the build completes. This option causes the tagging step to be skipped. The package will be in the system, but untagged (you can later tag it with the tag-pkg command) --scratch This makes the build into a scratch build. The build will not be imported into the db, it will just be built. The rpms will land under <topdir>/scratch. Scratch builds are not tracked and can never be tagged, but can be convenient for testing. Scratch builds are typically removed from the filesystem after one week. --nowait As stated above, this prevents the cli from waiting on the build task. --arch-override This option allows you to override the base set of arches to build for. This option is really only for testing during the beta period, but it may be retained for scratch builds in the future.
koji build --scratch dist-f8 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/yum/devel#HEAD'
List only tasks requested by you:
koji list-tasks --mine
requeue an already-processed task: general syntax is: koji resubmit [options] taskID
koji resubmit 3
If your package fails to build, you will see something like this:
420066 buildArch (kernel-2.6.18-1.2739.10.9.el5.jjf.215394.2.src.rpm, ia64): open (build-1.example.com) -> FAILED: BuildrootError: error building package (arch ia64), mock exited with status 10
You can figure out why the build failed by looking at the log files. If there is a build.log, start there. Otherwise, look at init.log.
$ ls -1 <topdir>/work/tasks/420066/* <topdir>/work/tasks/420066/build.log <topdir>/work/tasks/420066/init.log <topdir>/work/tasks/420066/mockconfig.log <topdir>/work/tasks/420066/root.log