Secondary Arch Releng

Builds

Principles

Never build an NVR before it's built on primary (koji.fedoraproject.org). The code used for a given NVR must match exactly between primary and secondary. koji-shadow uses source RPMs pulled from koji.fp.o, when building manually you should use a git url from pkgs.fedoraproject.org (e.g. git://pkgs.fedoraproject.org/kernel?#5394ba72a9d27667d10801685f71c003a7e205bc for kernel-3.9.6-301.fc19 )

Never build 'real' (i.e. not scratch) packages with code that hasn't been committed to pkgs.fp.o.

Milestone composes (TCs & RCs for alpha, beta and GA) should only ever be done with real packages. Including scratch builds in test composes should be kept to an absolute minimum.

Buildroots and dependencies should match primary as closely as possible. koji-shadow enforces this automatically, the only time you should build a package manually is when something is broken in a way which prevents koji-shadow from building it.

e.g. if eclipse-4.3.0-0.60.git7bf397.fc19 had a previous, broken-on-secondary version of eclipse in its buildroot, you should build eclipse-4.3.0-0.60.git7bf397.fc19 manually.

If not broken, build a single package with koji-shadow -c <config file> --build <nvr> <release>-build

This assumes <config file> specifies prefer_new and import_noarch, and you're using a koji-shadow from git which supports those options in conjunction with building a single NVR (previous versions of koji-shadow, using '--build <nvr>' caused it to match the buildroot exactly).

koji-stalk.py will print any backlog for each distro, if any, every 10 minutes.

koji-shadow should be occasionally manually run against the stable tags (and possibly updates-testing?) to catch any builds that might have been missed by the script (e.g. it crashed, or was stopped for system maintenance or to update the script).

compose.sh composes test releases. It uses the fedora-install-fedora.ks which points to the branched & bleed repos, and does not create source or debuginfo trees. Edit the DATE variable before running it.

compose-milestone.sh composes milestone releases. Ensure there's a $milestone-fedora-install-fedora.ks which points to a repo which was mashed with strict signing (such as what mash-milestone.sh creates). Edit the DATE and MILESTONE variables before running it.

make-bleed.sh creates a bleed repo of packages from the PKGS variable. Edit the PKGS variable before running it.

All of the above should be run from ppc-composer.

koji-stalk.py is a script for monitoring fedmsg and kicking off builds as soon as they finish on primary.

All build scripts (koji-stalk.py and koji-shadow) are currently run from the hub.

All compose and mash scripts, pushing updates, and signing are done from the composer.

koji-stalk.py and sigulsign_unsigned.py are available from the releng git repo.

TC & RC Composes

TCs are Test Composes. They will never be formal releases so the only thing that makes them different from daily ISOs is the package list for the bleed repo is taken from primary's releng ticket for that release/milestone, e.g. https://fedorahosted.org/rel-eng/ticket/5623

Grab the list of NVRs from the ticket, then edit make-bleed.sh and put that (space separated) list in the PKGS variable.

To make life easier for you down the road, it's best to sign those builds now. Run sigulsign_unsigned.py --arch ppc -v fedora-19-secondary <space separated list of NVRs>, and take note of any builds which don't exist yet (then build them, and sign).

Run make-bleed.sh -s ba094068 to build the bleed repos.

ba094068 is the key ID for fedora-19-secondary. As an argument, it is case-sensitive.

Edit compose.sh to reflect the correct DATE label (e.g. f19-20130618-GA-TC5) and run it.

RCs are Release Candidates. They may become formal releases, so we need to ensure that all packages in an RC are signed. RCs also have full source and debuginfo trees generated as well, so they take a little longer to make.

Creating New Mash Configs

Using 19-updates.ppc.mash as an example, replace the configuration name (i.e. '19-updates'), the tag name ('f19-updates'), the key ID ('ba094068'), the repoviewurl, and repoviewtitle with the new information and save it in a new file in /etc/mash.

You will also need to have mash.ppc.conf present and reference it in your mash command line (-c /etc/mash/mash.ppc.conf) to fetch packages from ppc.koji.

Branching

Draft InformationThis section should be considered a draft and is not final or necessarily correct!