Last modified 4 years ago Last modified on 01/22/10 17:38:25

Adding a new Release

$ tg-admin --config=prod.cfg shell
>>> rel = Release(name='f7', long_name='Fedora 7',
                  id_prefix='FEDORA', dist_tag='dist_fc7')

Note: when adding a new release, you'll probably want to refresh the metrics right away.

>>> from import refresh_metrics
>>> refresh_metrics()

Modifying an individual update

$ tg-admin --config=prod.cfg shell
>>> update = PackageUpdate.byTitle('cairo-1.4.8-1.fc7')
>>> print update
    Release: Fedora 7
     Status: pending
       Type: enhancement
      Notes: Update to latest cairo release.  Fixes various error-handlng paths
           : that are known to fix crashes.
  Submitter: behdad
  Submitted: 2007-06-09 12:15:04
>>> update.request = 'testing'

Run post-request actions on updates

The initial steps of the push process involve updating the tags on all of the builds, then mashing repositories based on those tags. Upon completion, the request_complete() method is called on every PackageUpdate, which assigns itself an update id, sends out the announcements, etc. In cases where something went wrong during the push process, and some updates need to be cleaned up by hand, you can do the following to recover.

  • Somehow get a list of updates that need to be pushed. You can do this by copying parts of the bodhi logfile, such as:
    [bodhi.masher] DEBUG 2007-07-09 14:54:25,902 Moving gimp-2.2.16-1.fc7 from dist-fc7-updates-candidate to dist-fc7-updates-testing
    [bodhi.masher] DEBUG 2007-07-09 14:54:26,494 Moving perl-Gearman-Server-1.09-1.fc7 from dist-fc7-updates-candidate to dist-fc7-updates-testing

...or you can get the package names by doing some PackageUpdate?.select(), or whatever.

import turbomail ; turbomail.start_extension()
for line in file('update-list', 'r').readlines():
    update = PackageUpdate.byTitle(line.split()[5]).request_complete()
    print update.title

Interact with bodhi's koji session

$ tg-admin --config=prod.cfg shell
>>> from bodhi.buildsys import get_session
>>> koji = get_session()
>>> builds = koji.listTagged('dist-f7-updates', latest=True)

Push updates through the Masher by hand

$ tg-admin --config=prod.cfg shell
>>> import turbomail ; turbomail.start_extension()
>>> from bodhi import masher ; masher.start_extension()
>>> masher.masher.queue( != None))

Pickle bodhi's database

Bodhi's database can be saved and restored using the tool.

$ ./bodhi/tools/ save

Unlocking a Release

$ tg-admin --config=prod.cfg shell
>>> Release.byName('F8').locked = False

Deleting a release, and everything associated with it

$ ./bodhi/tools/rmrelease f7

Modifying the Masher State

When mashing updates, the Masher leaves behind a MASHING file, which contains the list of updates and a list of successfully composed repositories. If for some reason you need to modify this file, it's simply a serialized pickle, which can be modified like so:

>>> import pickle
>>> state = pickle.load(file('/mnt/koji/mash/updates/MASHING'))
>>> state['composed_repos'].remove('/mnt/koji/mash/updates/f9-updates-testing-090505.2026')
>>> pickle.dump(state, file('/mnt/koji/mash/updates/MASHING', 'w'))

Importing builds from an existing koji tag

When bodhi started supporing EPEL packages, we had to import all of the existing testing builds as updates into the system. Doing this was fairly simple:

from bodhi.buildsys import get_session
koji = get_session()
el4 = Release.byName('EL-4')
el4_builds = koji.listTagged('dist-4E-epel-testing')
for build in el4_builds:
        b = PackageBuild.byNvr(build['nvr'])
        print "Skipping existing build: ", build['nvr']
    except SQLObjectNotFound:
        p = Package.byName(build['package_name'])
    except SQLObjectNotFound:
        p = Package(name=build['package_name']) 
    b = PackageBuild(nvr=build['nvr'], package=p)
    u = PackageUpdate(title=build['nvr'], release=el4, notes='', submitter=build['owner_name'], status='testing', type='bugfix')
    print "Created update: %s" % u.title