Extras/TreeMaintenance

Notes for maintaining the extras tree. This is for signers and other folks working directly on the master extras tree.

This does the following:
 * The master tree lives on the machine that heads the buildsys server.
 * If you have access to it you login as the tree manangement user.
 * To sign newly built packages run:, e.g.   or
 * collect a list of newly built packages
 * sign the packages
 * move the packages into their final tree
 * prune old package releases
 * update the metadata
 * update the repoview
 * sync to mirror master
 * email fedora-extras-list with the list of updated/added packages
 * run post-scripts like upgradecheck, repoclosure


 * Available options:
 * force metadata/repoview update for repos
 * stripped pushing, that is without running: repoprune, repoview, post-update scripts
 * just continue/complete a previous push, don't add any new builds from needsign


 * Tools that can be used separately:,  ,  ,   - except for the sync script they all take a distribution release/name as argument.

PushPackage.py Extras PushPackage.py Extras [regexp]
 * Pushing packages manually prior to a normal "extras-push" (this can also push to a frozen dist):

Examples: PushPackage.py Extras development libfoo PushPackage.py Extras development libfoo libbar libbaz PushPackage.py Extras development lib.\* PushPackage.py Extras development 'lib*' PushPackage.py Extras development .\* This signs and installs the chosen packages into the repository, but does not update the metadata, does not sync, and does not send a mail either.


 * If you need to do maintenance on the tree (ex: remove old/broken/wrong packages, clean up items, run tools manually, etc) then you can cd to ~/extras-tree and that will take you to the top of the extras directory structure. You can remove files directly from there to change things around.
 * Once you have finished removing or modifying files in the tree you will need to remake the metadata to do this you run:  for the releases you've changed.
 * Then you sync the tree manually.


 * Additional optional Python scripts without a corresponding  wrapper script can be called in a less convenient form in the pushscript path, like:    lists the needsign queue, the "Extras" argument refers to the configuration module to load.   rebuilds the files which are used to detect new packages,   runs the multi-lib copying and resolving manually.   updates the comps.xml files from cvs. As a side-note, ,   and   could be executed like that, too, if the wrapper-scripts were missing.

In the future there will be more things involved in pushing packages but for right now this is what we have. Remember to keep your ssh key for accessing the buildsys server system safe.

When the pushscript is configured to run with pushtotesting = True, there's rudimentary support for updates-testing kind of repositories. These repos must be added to the configuration with a testing/ prefix to the dist number, to keep them separate from the stable repos. Then from the single plague-results needsign repo, packages are pushed to the testing repos instead. Examples: epel-push testing/5 epel-push all or: Push.py EPEL testing/5 Push.py EPEL all An add-on script can push sets of test packages from testing to the stable repos (and generates build report information). It takes Python regular expressions as build-job name arguments (i.e. src.rpm %name): ToStable.py EPEL 5 foo bar baz ToStable.py EPEL 5 '.*' epel-push -c 5 A subsequent run of the main pushscript is needed to complete the repository changes.

To push a package from plague-results directory to a stable repository directly, it is possible to override the pushtotesting mode with the PushPackage.py helper script described above by adding the --stable option at the end. It also takes Python regexp as build-job name args: PushPackage.py EPEL 5 foo bar baz --stable epel-push -c 5