Koji/ExternalRepoServerBootstrap

From FedoraProject

Jump to: navigation, search

Contents

[hide]

Bootstrapping a new External Repo Koji build environment

These are the steps involved in pointing a new Koji server at external repositories so that it can be used for building. This assumes that the Koji hub is up, appropriate authentication methods have been configured, the Koji repo administration daemon (kojira) is properly configured and running, and at least one Koji builder (kojid) is properly configured and running. All koji cli commands assume that the user is a Koji admin. If you need help with these tasks, see the ServerHowTo .

$ koji add-tag dist-foo
$ koji add-tag --parent dist-foo --arches "i386 x86_64 ppc ppc64" dist-foo-build
$ koji add-external-repo -t dist-foo-build  dist-foo-external-repo http://repo-server.example.com/path/to/repo/for/foo/\$arch/
$ koji add-target dist-foo dist-foo-build
$ koji add-group dist-foo-build build
$ koji add-group dist-foo-build srpm-build

You can find out what the is in the current groups for Fedora by running koji list-groups dist-f9-build against the Fedora Koji instance. This is probably a good starting point for your minimal buildroot and srpm creation buildroot.

$ koji add-group-pkg dist-foo-build build <pkg1> <pkg2> .....
$ koji add-pkg --owner <kojiuser> dist-foo <pkg1> <pkg2> .....


Regenerating your repo

koji doesn't monitor external repositories for changes. new repositories will be generated when packages you build land in a tag that populates the buildroot or you manually regenerate the repository. you should be sure to regularly regenerate the repositories manually to pick up updates.

$ koji regen-repo dist-foo-build

Examples of urls to use for external Repositories

all these examples use mirrors.kernel.org please find the closest mirror to yourself. Note that the Fedora minimal buildroots download ~100Mb then build dependencies on top. these are downloaded each build you can save alot of network bandwidth by using a local mirror or running through a caching proxy.

Fedora 10

http://mirrors.kernel.org/fedora/releases/10/Everything/\$arch/os/
http://mirrors.kernel.org/fedora/updates/10/\$arch/

CentOS 5 and EPEL

http://mirrors.kernel.org/centos/5/os/\$arch/
http://mirrors.kernel.org/centos/5/updates/\$arch/
http://mirrors.kernel.org/fedora-epel/5/\$arch/

Example tags and targets

In the simplest setup, where you just want to build against what is available in the external repositories, you may want to go with a simple layout of dist-fX-build tags inheriting one another, and dist-fX-updates tags and targets that inherit the dist-fX-build tag and have external repos attached to them. This way, a dist-fY-build or dist-fY-updates tag will not automatically inherit the external repos of your dist-fX tags.

Tags

dist-f10-updates               - This is where the external repos for f10 release and f10 updates are attached
 `- dist-f10-build             - This is the f10 build target with the 'build' and 'srpm-build' group inherited from dist-f9-build,
     |                           so that your buildroot gets populated but you do not have to maintain these groups for each
     |                           seperate release.
     `- dist-f9-build          - etc.
         `- dist-f8-build      - etc.

Targets

Each dist-fX-build tag has a dist-fX-updates child tag, and each dist-fX-updates tag has a corresponding dist-fX-updates-candidate build target.