; <code>~/.fedora.cert</code> (specific to the Fedora Maintainer) : This cert is generated from [https://admin.fedoraproject.org/accounts/user/gencert this form] in [[Infrastructure/AccountSystem | FAS]]. It should have been generated when you became maintainer. You may need to refresh it when it expires.

+

; <code>~/.fedora.cert</code> (specific to the Fedora Maintainer) : This cert is generated from running <code>fedora-cert -n</code>. It should have been generated when you became maintainer. You may need to refresh it when it expires. You can check if it has expired with <code>fedora-cert -v</code>.

the following are downloaded automatically by fedora-packager-setup and dont need to be manually setup

the following are downloaded automatically by fedora-packager-setup and dont need to be manually setup

Line 41:

Line 41:

==== Koji Config ====

==== Koji Config ====

−

The global local client configuration file for koji is <code>/etc/koji.conf</code>. You should not need to change this from the defaults for building Fedora packages, as running <code>fedora-packager-setup</code> will create a set of configuration files in ~/.koji/ file for your user. These will allow you to use the primary build system as well as secondary arch build systems.

+

The global local client configuration file for koji is <code>/etc/koji.conf</code>. You should not need to change this from the defaults for building Fedora packages.These will allow you to use the primary build system as well as secondary arch build systems.

== The web interface ==

== The web interface ==

Line 163:

Line 163:

== Scratch Builds ==

== Scratch Builds ==

−

Sometime it is useful to be able to build a package against the buildroot but without actually including it in the release. This is called a scratch build. The following section covers using koji directly as well as the fedpkg tool to do scratch builds. To create a scratch build from changes you haven't committed, do the following:

+

Sometimes it is useful to be able to build a package against the buildroot but without actually including it in the release. This is called a scratch build. The following section covers using koji directly as well as the fedpkg tool to do scratch builds. To create a scratch build from changes you haven't committed, do the following:

<pre>

<pre>

Line 178:

Line 178:

Warning: Scratch builds will ''not'' work correctly if your .spec file does something different depending on the value of %fedora, %fc9, and so on. Macro values like these are set by the ''builder'', not by koji, so the value of %fedora will be for whatever created the source RPM, and ''not'' what it's being built on. Non-scratch builds get around this by first re-building the source RPM.

Warning: Scratch builds will ''not'' work correctly if your .spec file does something different depending on the value of %fedora, %fc9, and so on. Macro values like these are set by the ''builder'', not by koji, so the value of %fedora will be for whatever created the source RPM, and ''not'' what it's being built on. Non-scratch builds get around this by first re-building the source RPM.

−

If you are have committed the changes to git and you are in the current branch, you can do a scratch build with fedpkg tool which wraps the koji command line tool with the appropriate options:

+

If you have committed the changes to git and you are in the current branch, you can do a scratch build with fedpkg tool which wraps the koji command line tool with the appropriate options:

The Koji Build System is Fedora's RPM buildsystem. Packagers use the koji client to request package builds and get information about the buildsystem. Koji runs on top of Mock to build RPM packages for specific architectures and ensure that they build correctly.

Everything you need to use Koji (and be a Fedora contributor) can be installed in a single step:

yum install fedora-packager

fedora-packager provides useful scripts to help maintain and setup your koji environment. Additionally, it includes dependencies on the Koji CLI, so it will be installed when you install fedora-packager. The command is called koji and is included in the main koji package. By default the koji tool authenticates to the central server using Kerberos. However SSL and username/password authentications are available. You will need to have a valid authentication token to use many features. However, many of the read-only commands will work without authentication.

In order to interface with the koji server, maintainers will need to run

/usr/bin/fedora-packager-setup

Each user on a system will need to run fedora-packager-setup if they wish to use Koji to build Fedora packages. Each user has their own certificates that authenticate them.

Plague users rejoice!For existing users of plague (the old build system that preceded Koji), fedora-packager-setup will use your existing certificates. If you did not have plague before, it will get the server CA certs and tell you where to get your user cert.

This cert is generated from running fedora-cert -n. It should have been generated when you became maintainer. You may need to refresh it when it expires. You can check if it has expired with fedora-cert -v.

the following are downloaded automatically by fedora-packager-setup and dont need to be manually setup

~/.fedora-upload-ca.cert (The certificate for the Certificate Authority used to sign the user keys.)

It can be manually downloaded from here or fedora-packager-setup or fedora-cert -n should fetch it. using the CLI is prefered.

~/.fedora-server-ca.cert (The certificate for the Certificate Authority used to sign the build system's server keys.)

It can be downloaded manually from here or fedora-packager-setup should fetch it.

The global local client configuration file for koji is /etc/koji.conf. You should not need to change this from the defaults for building Fedora packages.These will allow you to use the primary build system as well as secondary arch build systems.

OptionalThe web interface is optional. You may skip to the
next section if you like.

The primary interface for viewing Koji data is a web application.
It is available at http://koji.fedoraproject.org/koji/ .
Most of the interface is read-only, but with sufficient privileges,
you can log in and perform some additional actions. 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 SSL authentication. In order to log in you will need a
valid SSL certificate and your web browser will need to be configured to trust
the SSL cert. Instructions on how to do this are printed when running
fedora-packager-setup --with-browser-cert.

Using the certificate directly downloaded from the FAS web

interfaceIf you have generated and downloaded the certificate~/.fedora.cert directly from FAS using the form referenced
above, you need to convert it into a format that the browser can understand
using the following command:
openssl pkcs12 -export -in ~/.fedora.cert -CAfile ~/.fedora-upload-ca.cert -out ~/fedora-browser-cert.p12,
where .fedora-upload-ca.cert can be downloaded from the URL

OptionalYou only need to check these instructions if you are intending to authenticate with the web interface with Firefox. Authenticating with the web interface is optional.

Once you have created your FAS account, generated your certificate in the
form posted in the link above and ran
fedora-packager-setup --with-browser-cert, you will need
to import it into your web browser. You can do this in Firefox by doing
the following:

1. Launch Firefox and click on the Edit menu from the toolbar

2. Select Preferences in the sub-menu which appears.

3. This should open the Preferences window where you can switch to the Advanced section

4. In the Advanced section switch to the Encryption tab

5. Click on the View Certificates button and the Certificates window will appear

6. Switch to the Your Certificates tab and click on the Import button

7. Point to where your Fedora Certificate is located and click Open (fedora-packager-setup will have told you where it was saved and will have asked you to set a password for the cert)

You should now be able to see your Fedora Certificate listed under Your Certificates and you should be able to authenticate with the koji web interface.

When authenticated with the Koji web interface, you can setup a notification
requests to make sure you do not miss when a package you care about gets
built. 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.

chain-builds only work when building on the devel/ branch (aka rawhide). To chain-build packages to update a released OS version, set up an override using bodhi requesting packages to be included in the proper buildroot.

Sometimes you want to make sure than one build succeeded before
launching the next one, for example when you want to rebuild
a package against a just rebuilt dependency. In that case
you can use a chain build with:

fedpkg chain-build libwidget libgizmo

The current package is added to the end of the CHAIN list. Colons (:) can be used in the CHAIN parameter to define groups of packages. Packages in any single group will be built in parallel and all packages in a group must build successfully and populate the repository before the next group will begin building. For example:

fedpkg chain-build libwidget libaselib : libgizmo :

will cause libwidget and libaselib to be built in parallel, followed by libgizmo and then the currect directory package. If no groups are defined, packages will be built sequentially.

If a build fail, following builds are cancelled but the builds that already succeeded are pushed to the repository.

Sometimes it is useful to be able to build a package against the buildroot but without actually including it in the release. This is called a scratch build. The following section covers using koji directly as well as the fedpkg tool to do scratch builds. To create a scratch build from changes you haven't committed, do the following:

rpmbuild -bs foo.spec
koji build --scratch rawhide foo.srpm

From the latest git commit:

koji build --scratch rawhide 'git url'

Warning: Scratch builds will not work correctly if your .spec file does something different depending on the value of %fedora, %fc9, and so on. Macro values like these are set by the builder, not by koji, so the value of %fedora will be for whatever created the source RPM, and not what it's being built on. Non-scratch builds get around this by first re-building the source RPM.

If you have committed the changes to git and you are in the current branch, you can do a scratch build with fedpkg tool which wraps the koji command line tool with the appropriate options:

fedpkg scratch-build

if you want to do a scratch build for a specific architecture, you can type:

fedpkg scratch-build-<archs>

<archs> can be a comma separated list of several architectures.

finally is possible to combine the scratch-build command with a specific koji tag in the form:

fedpkg scratch-build --target TARGET

fedpkg scratch-build --help or koji build --help for more information.

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.

Logs can be found via the web interface in the Task pages for the failed task. Alternatively the koji client can be used to view the logs via the watch-logs command. See the help output for more details.

We've tried to make Koji self-documenting wherever possible. The command line tool will print a list of valid commands and each command supports --help. For example:

$ koji help
Koji commands are:
build Build a package from source
cancel-task Cancel a task
help List available commands
latest-build Print the latest rpms for a tag
latest-pkg Print the latest builds for a tag
[...]

$ koji build --help
usage: koji build [options] tag URL
(Specify the --help global option for a list of other help options)
options:
-h, --help show this help message and exit
--skip-tag Do not attempt to tag package
--scratch Perform a scratch build
--nowait Don't wait on build
[...]

In Koji, it is sometimes necessary to distinguish between a package in general, a specific build of a package, and the various rpm files created by a build. When precision is needed, these terms should be interpreted as follows:

Package: The name of a source rpm. This refers to the package in general and not any particular build or subpackage. For example: kernel, glibc, etc.

Build: A particular build of a package. This refers to the entire build: all arches and subpackages. For example: kernel-2.6.9-34.EL, glibc-2.3.4-2.19.

RPM: A particular rpm. A specific arch and subpackage of a build. For example: kernel-2.6.9-34.EL.x86_64, kernel-devel-2.6.9-34.EL.s390, glibc-2.3.4-2.19.i686, glibc-common-2.3.4-2.19.ia64