rdopkg(1) Manual Page

rdopkg provides multi-step actions where each step is (should be) idempotent so if something fails along the way or human interaction is required, rdopkg drops to shell, let’s you rectify and then continue by running rdopkg --continue (rdopkg -c).

The state is stored in .rdopkg.json file in current directory. Stored action can be inspected (rdopkg status), continued (rdopkg --continue) or aborted (rdopkg --abort). rdopkg will refuse to start new multi-step action if state file is present.

Make .spec file only changes.

Flow:

Example:

Introduce new patches to the package.

This action works with patches branch (see AUTOMAGIC → patches branch). By default, rdopkg resets local patches branch to remote patches branch. You can skip this this with --local-patches to directly use local patches branch as is.

Note that patch is a high level wrapper of update-patches action. If you’re interested in just updating patches in .spec file from local patches branch, try using update-patches action instead.

Don’t forget to git fetch before running the action.

After running rdopkg patch, new commit will contain the changes.

Flow:

Update package to new upstream version.

This action works with patches branch (see AUTOMAGIC → patches branch). After successful rebase, rdopkg will offer to push the rebased patches branch.

Required new-version argument is a new version to rebase on, presumably a git version tag.

Don’t forget to git fetch --all before running the action.

After running rdopkg new-version, new commit will contain the changes.

To just update .spec without touching patches branch, -b/--bump-only can be used. You might also occasionally want to skip fedpkg new-sources step with -n/--no-new-sources. These two options combined give you local-only operation, much like rpmdev-bumpspec:

Flow:

Example:

Clone an RDO package distgit and setup remotes.

clone uses rdoinfo metadata to clone the specified RDO package distgit and also setup relevant remotes to get you packaging quickly.

If your github username differs from your $USER, use -u/--review-user.

Example:

Update .spec file with patches from patches branch.

This is a core low level action used by other actions such as patch and new-version to update dist-git patches from patches branch. See AUTOMAGIC → patches branch for explanation.

update-patches is a rework of now obsolete update-patches.sh script with less restrictions and more features such as optional #patches_base, support for git am %{patches} method of applying patches and smart patches branch detection. It also supports filtering out patches based on matching a regex provided by a magic #patches_ignore comment in the spec file. This is useful, for example, in case the patches branch contains changes that are related to the CI/code review infra, that are useful to keep around but don’t need to end up in the RPM.

Flow:

Example:

Query RDO/distro repos for available package versions.

See rdopkg-adv-requirements(7) for complete example of query and other requirements management actions.

This action uses repoquery to discover latest package versions available from RDO and other repos available on a supported distibution.

See output of rdopkg info for supported releases and distros.

Query specific RELEASE/DIST:

Query all dists of a release and show what’s happening:

Query RDO/distro repos for versions defined in requirements.txt.

See rdopkg-adv-requirements(7) for complete example of reqquery and other requirements management actions.

This action essentially runs rdopkg query on every module/package defined in requirements.txt and prints colorful report to quickly find unmet dependencies. It accepts the same RELEAESE/DIST filter as rdopkg query.

Python module names listed in requirements.txt are mapped to package names using rdopkg.actionmods.pymod2pkg module.

Query requirements.txt from 2015.1 tag:

Query requirements.txt file:

Query .spec Requires (experimental):

Verbosely dump query results to a file and view them:

Inspect requirements.txt vs .spec Requires.

See rdopkg-adv-requirements(7) for complete example of reqcheck and other requirements management actions.

This action parses current requirements.txt from git and checks whether they’re met in the .spec file. Simple report is printed.

Python module names listed in requirements.txt are mapped to package names using rdopkg.actionmods.pymod2pkg module.

Example:

Show pretty diff of requirements.txt.

See rdopkg-adv-requirements(7) for complete example of reqdiff and other requirements management actions.

Use this to see how requirements changed between versions.

See diff between current and latest upstream version (automagic):

See diff between current and specified version:

See diff between two supplied versions:

Build the package in koji.

See rdopkg-adv-building(7) for complete example of building and submitting packages for RDO.

This is esentaially a wrapper over fedpkg build with added value of generating update entries for rdopkg update.

Flow:

Example:

Build the package in copr-jruzicka.

See rdopkg-adv-building(7) for complete example including instructions how to setup copr, obtain permissions, build, submit update, and more.

Please, try to do coprbuild after successful kojibuild to ensure same SRPM for both builds. This will be automated further in the future.

-r/--release and -d/--dist are autodetected from current branch if possible. These are used to select right copr to build in.

Flow:

Example:

Amend last git commit with current dist-git changes and (re)generate the commit message from %changelog.

This simple atomic action is equivalent to running

See AUTOMAGIC → commit message for more information about the generated commit message.

Squash last git commit into previous one. Commit message of previous commit is used.

This simple atomic action is a shortcut for

This is useful for squashing commits created by lower level actions such as update-patches.

Download package source archive.

Currently, Source0 from .spec file is downloaded.

Show information about RDO packaging.

Use this command to find out about:

This command is a human interface to rdoinfo.

Releases/dists/branches overview:

Detailed information about a package:

Filter packages by maintainers:

Show rdoinfo tag changes.

will show per-package new/changed tags in rdoinfo between HEAD~..HEAD.

For an existing package, a list of changed tags is returned

For a new package, full tags dict is returned.

Example:

This is an interface to rdopkg.actionmods.rdoinfo:tags_diff().

Display rdopkg’s local configuration.

This command prints the default configuration that ships with rdopkg out of the box. You can override the individual settings here by using .py files in the configuration directories.

Store your per-user configuration in ~/.rdopkg/conf.d/*.py, or store system-wide configuration in /etc/rdopkg.d/*.py.

update-patches is a core lower level action for updating dist-git .spec file with patches from associated patches branch. rdopkg tries hard to detect the patches branch automagically, it’s usually $BRANCH-patches for $BRANCH dist-git but one patches branch per multiple dist-gits is also supported.

Best illustrated by example, following are all valid patches branches for rhos-5.0-rhel-7 dist-git and they’re searched in that order:

Use rdopkg pkgenv to check detected patches branch.

You can specify remote patches branch by -p/--patches-branch action parameter for actions that use it, such as patch and new-version.

Previously, now obsolete update-patches.sh script required patches_base comment to be present in spec file which indicated git revision on top of which the patches are applied but this is now optional with update-patches action and defaults to .spec Version.

Most common use of patches_base is to specify number of patches on top of patches base (which defaults to spec Version) to skip:

You can set an arbitrary git revision as a patches base:

You shouldn’t need to modify this by hand expect the number of skipped patches as rdopkg manages patches_base as needed.

Actions modifying dist-git generate commit message from %changelog.

First line of commit message is first line from latest %changelog entry.

If there are multiple lines in latest %changelog entry, entire entry is listed in the commit message.

For each "(rhbz#XYZ)" mentioned in latest %changelog entry, "Resolves: rhbz#XYZ" is appended to commit message as required by RHOSP workflow.

If you need to (re)generate commit message after modifying %changelog, use ACTION: amend.

For example following %changelog entry:

will generate following commit message:

rdoinfo is a special utility repository with RDO metadata:

https://github.com/redhat-openstack/rdoinfo

rdopkg uses rdoinfo to

and more.

You can view the rdoinfo metada using rdopkg info.

rdopkg.actionmods.rdoinfo module provides convenient interface to rdoinfo should you want to integrate it into your codez.