|
|
| (9 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| == Description ==
| |
| <!-- Put a description of the task here.
| |
| -->
| |
| Each new release we create a build target for the next release. This SOP will describe the steps necessary to prepare the new build target.
| |
|
| |
|
| == Action ==
| | {{admon/important|This page has moved [https://docs.pagure.org/releng/sop_adding_side_build_targets.html here]| All Fedora Release Engineering Documentation has moved [https://docs.pagure.org/releng/ here] with source hosted along side the code in the [https://pagure.io/releng releng pagure repository]}} |
| <!-- Describe the action and provide examples
| |
| -->
| |
| Adding a build target is a complicated task. It involves updating koji, CVS, fedora-release package, and a few wiki pages.
| |
|
| |
|
| === Koji ===
| |
| In koji a couple collection tags need to be made, and a target created to tie them together. We create a base collection tag named after the release, and a build tag to hold a few things we use in the buildroots that are not part of the distribution (glibc32/glibc64). Inheritance to the previous release is used for ownership and package data, as well as buildroot content data.
| |
|
| |
| The <code>add-tag</code>, <code>add-tag-inheritance</code>, <code>edit-tag</code>, and <code>add-target</code> commands are used.
| |
| <pre>
| |
| $ koji add-tag --help
| |
| Usage: koji add-tag [options] name
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| --parent=PARENT Specify parent
| |
| --arches=ARCHES Specify arches
| |
|
| |
|
| |
| $ koji add-tag-inheritance --help
| |
| Usage: koji add-tag-inheritance [options] tag parent-tag
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| --priority=PRIORITY Specify priority
| |
| --maxdepth=MAXDEPTH Specify max depth
| |
| --intransitive Set intransitive
| |
| --noconfig Set to packages only
| |
| --pkg-filter=PKG_FILTER
| |
| Specify the package filter
| |
| --force=FORCE Force adding a parent to a tag that already has that
| |
| parent tag
| |
|
| |
| $ koji edit-tag --help
| |
| Usage: koji edit-tag [options] name
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| --arches=ARCHES Specify arches
| |
| --perm=PERM Specify permission requirement
| |
| --no-perm Remove permission requirement
| |
| --lock Lock the tag
| |
| --unlock Unlock the tag
| |
| --rename=RENAME Rename the tag
| |
|
| |
| $ koji add-target --help
| |
| Usage: koji add-target name build-tag <dest-tag>
| |
| (Specify the --help global option for a list of other help options)
| |
|
| |
| Options:
| |
| -h, --help show this help message and exit
| |
| </pre>
| |
|
| |
| For example if we wanted to create the Fedora 14 tags, we would do the following:
| |
| <pre>
| |
| koji add-tag --parent dist-f13-updates dist-f14
| |
| koji add-tag --parent dist-f14 dist-f14-updates
| |
| koji add-tag --parent dist-f14-updates dist-f14-updates-candidate
| |
| koji add-tag --parent dist-f14-updates dist-f14-updates-testing
| |
| koji add-tag --parent dist-f14-updates dist-f14-override
| |
| koji add-tag --parent dist-f14-override --arches=i686,x86_64 dist-f14-build
| |
| koji add-tag-inheritance --priority 1 dist-f14-build dist-f13-build
| |
| koji edit-tag --perm=admin dist-f14-override
| |
| koji edit-tag --lock dist-f14-updates
| |
| koji add-target dist-f14 dist-f14-build
| |
| </pre>
| |
|
| |
| === Git ===
| |
| The pkgdb2branch.py file which is hosted in puppet (modules/gitolite/files/distgit/pkgdb2branch.py) needs to be updated for the new target for making branches.
| |
|
| |
| Update <code>BRANCHES</code> with the new branch information. The branch name maps to the branch that is its parent.
| |
| <pre>
| |
| BRANCHES = {'el4': 'master', 'el5': 'master', 'el6': 'f12',
| |
| 'OLPC-2': 'f7',
| |
| 'master': None,
| |
| 'fc6': 'master',
| |
| 'f7': 'master',
| |
| 'f8': 'master',
| |
| 'f9': 'master',
| |
| 'f10': 'master',
| |
| 'f11': 'master',
| |
| 'f12': 'master',
| |
| 'f13': 'master', 'f14': 'master'}
| |
|
| |
| </pre>
| |
|
| |
| and update <code>GITBRANCHES</code> with the translation from pkgdb branch string to git branch string:
| |
| <pre>
| |
| GITBRANCHES = {'EL-4': 'el4', 'EL-5': 'el5', 'EL-6': 'el6', 'OLPC-2': 'olpc2',
| |
| 'FC-6': 'fc6', 'F-7': 'f7', 'F-8': 'f8', 'F-9': 'f9', 'F-10': 'f10',
| |
| 'F-11': 'f11', 'F-12': 'f12', 'F-13': 'f13', 'F-14': 'f14', 'devel': 'master'}
| |
| </pre>
| |
|
| |
| === PackageDB ===
| |
| {{admon/note||For PackageDB, add the branches you want to be able to make in git when you want to be able to make them. ie, when git early branching for Fedora 9 from rawhide is desired, create the Fedora 9 collection in pkgdb.}}
| |
| The Package Database has two tables that need to be updated with the new release information as well. These are the commands that were run to update for Fedora 9:
| |
|
| |
| <pre>
| |
| $ ssh bastion
| |
| $ ssh db2
| |
| $ sudo -u postgres psql pkgdb
| |
| Password:
| |
| pkgdb=# insert into collection (name, version, koji_name, statuscode, owner) values \
| |
| ('Fedora', '15', 'dist-f15', 1, 100351);
| |
|
| |
| pkgdb=# insert into branch (collectionid, branchname, disttag) \
| |
| select id, 'F-15', '.f15' from collection where name = 'Fedora' and version = '15';
| |
| </pre>
| |
|
| |
| * name and version define the release.
| |
| * koji_name is the tag used for this release in koji.
| |
| * statuscode for a new release will always be 1 (Active).
| |
| * 100351 is Jesse Keating's id. Change this if someone else is the release manager for this release.
| |
| * branchname is the name of the old branch directories in cvs.
| |
| * disttag is the value for disttag in rpm.
| |
|
| |
| === fedora-release ===
| |
| Currently the fedora-release package provides the '''%{?dist}''' definitions used during building of packages. When a new target is created, fedora-release must be built for the collection with new dist definitions.
| |
|
| |
| === Wiki ===
| |
| Various wiki pages need to be updated with the new target information. Below you'll find a (hopefully current) list of pages to change:
| |
| * [[Koji/CurrentKojiTags| Current Koji Tags]]
| |
| * [[PackageMaintainers/GitAdminProcedure| Git Admin Proceedure]]
| |
|
| |
| === Comps ===
| |
| * In the comps module in Fedora Hosted git (ssh://git.fedorarhosted.org/git/comps.git), create and add a new comps file based on the previous release. (Just copying it should be fine.) Add the new file to <code>po/POTFILES.in</code>.
| |
| * When rawhide is retargeted in koji to point to the new release, update the <code>Makefile</code> to target comps-rawhide.xml at the new version
| |
| * Don't forget to <code>git push</code> your changes after committing.
| |
|
| |
| == Verification ==
| |
| <!-- Provide a method to verify the action was successful
| |
| -->
| |
| Given the complexity of all the changes necessary to create a new build target, the best way to verify is to attempt a build. Given that fedora-release has to be built before anything else so that dist tags translate correctly it is a good test case. For example, this was used to test the new Fedora 15 target:
| |
|
| |
| * Use pkgdb to request an F-15 branch of fedora-release
| |
| * Use pkgdb2branch.py to actually make the branch
| |
| * Update fedora-release clone
| |
| * Adjust .spec file in master for new dist defines
| |
| * commit/build
| |
| * Track build in koji to ensure proper tagging is used
| |
|
| |
| What this won't test is translations of dist at tag time given that fedora-release doesn't use dist in it's Release. Verifying with a second package that uses dist is a good idea.
| |
|
| |
| == Consider Before Running ==
| |
|
| |
| * '''FIXME'''
| |
| * Too many to list right now.
| |
|
| |
|
| [[Category:Release Engineering SOPs]] | | [[Category:Release Engineering SOPs]] |
