Posted qui 05 set 2013 23:59:23 -03


Coding standards

  • Uses Semantic Versioning.
  • Respect the existing coding style.
  • Be clear: easy audability must be one of keyringer's requirements.

Release workflow

Go to develop branch and start a new release

git checkout develop

Prepare the source code:

$EDITOR keyringer # and update KEYRINGER_VERSION
$EDITOR ChangeLog
VERSION="`./keyringer | head -n 1 | cut -d ' ' -f 2`"

Create and upload a new release:

make release

Tag the release:

git tag -s $VERSION -m "Keyringer $VERSION"

Update the debian branch:

make debian

Push everything:

git push --tags

Build the package from the debian Git branch:

gbp buildpackage

Run lintian (or add it to your pbuilder hooks):

lintian --info --display-info --pedantic --color auto build-area/keyringer_$VERSION*.changes

Then go back to the develop branch and push everything:

git checkout develop
git push --all

Cleanup symlink:

rm ../keyringer_$VERSION.orig.tar.bz2


  • gbp import-orig takes care of running pristine-tar commit, of merging of the tag and orig tarball into the upstream branch, and then it merges the result into the debian branch. With the above configuration, it also runs git-dch to do the bulk of the work in debian/changelog.
  • To build a development package, checkout the debian branch, merge master, run git-dch --auto --snapshot and build.

Packaging workflow

We recommend this packaging workflow.

Adding or changing a subcommand

When adding a new subcommand or changing subcommand behavior, ensure:

  • Documentation is updated.
  • Manpage is updated.
  • Shell completions are updated.

Test environment


keyringer test init ~/temp/tests/keyringer


keyringer test teardown -y


Run just once:

cd share/man
po4a-gettextize -f text -m keyringer.1.mdwn -p keyringer.pot