Provided by: gitpkg_0.27_all bug

NAME

       gitpkg - export a Debian source package from nominated git revisions

SYNOPSIS

       gitpkg branch [origbranch]

DESCRIPTION

       If gitpkg is run in a git(1) repo with a single 'branch' specified, then it will do a git-
       archive export of that branch to the DEB_DIR directory.  If the package is  Debian  native
       it will simply create a source package from it.  If the package has a Debian version, then
       an orig tarball will be expected to already exist for it.  If an  orig  tarball  does  not
       already  exist  then what happens next depends on the value of the gitpkg.create-fake-orig
       configuration option (described below).

       If gitpkg is invoked with two branches specified, then the first branch will  be  exported
       as  the  unpacked  complete  source,  while  the  second  branch  will be exported for the
       orig.tar.gz.  This allows all local changes to the source to be recorded in the  resulting
       diff.gz  if  a  pristine  upstream  branch  exists  in the repository.  If an orig tarball
       already exists for the version at 'branch' then what happens next depends on the value  of
       the gitpkg.force-overwrite-orig configuration option (described below).

       The  'branch'  should  always  have  a  debian/ dir and may be any tree-ish object that is
       accepted by git-archive(1).  The 'origbranch', if supplied,  should  usually  not  have  a
       debian/ dir.

CONFIGURATION OPTIONS

       Almost  all  gitpkg  configuration  is  handled  using  git-config(1)  now.  The following
       configuration options are supported:

       gitpkg.deb-dir
              May be set to override the default destination  directory  for  exported  packages.
              Default  is  '../deb-packages'.  Available to hook scripts as DEB_DIR.  This may be
              overridden on the command line with the --deb-dir=path option.

       gitpkg.build-rootcmd
              May be set to override the default command used  to  get  root  for  package  build
              operations.  Default is 'fakeroot'.  Available to hook scripts as BUILD_ROOTCMD.

       gitpkg.prebuild-target
              May  be set to a target or targets from debian/rules which will be called after the
              debian source tree is exported, but before  the  source  package  is  built.   Some
              packages  may  use  this  to  generate  autoconf  files  or  the like, which should
              generally not be in the repo, but which should be in the distributed package.   The
              target  is invoked using the BUILD_ROOTCMD.  A common use for this hook would be to
              call the package's 'clean' target.  This hook is  unset  by  default  since  gitpkg
              0.18.   Previous  to  that  it  defaulted  to  the clean target.  Available to hook
              scripts as PREBUILD_TARGET.

       gitpkg.orig-compressor
              May be set to override the default compression for  an  exported  package.orig.tar.
              Default  is  'gzip'.   For  format  3.0  packages, valid values also include xz and
              bzip2.  Available to hook scripts as ORIG_COMPRESSOR.

       gitpkg.orig-compress-level
              An optional compression level to use with gitpkg.orig-compressor.  1 is usually the
              fastest  and  9  is  usually  the  smallest, with the precise details of everything
              between being up to the chosen  compressor.   Default  is  unset  (which  will  use
              whatever   the   compressor   default   is).    Available   to   hook   scripts  as
              ORIG_COMPRESS_LEVEL.

       gitpkg.deb-compressor
              May be set to override the default compression used by dpkg-source(1) for  exported
              packages.   Default  (if  unset)  is to use whatever dpkg-source wants to use.  For
              format 3.0 packages, valid values also include xz and  bzip2.   Available  to  hook
              scripts as DEB_COMPRESSOR.

       gitpkg.deb-compress-level
              An  optional compression level to use with gitpkg.deb-compressor.  1 is usually the
              fastest and 9 is usually the smallest,  with  the  precise  details  of  everything
              between  being  up  to  the  chosen  compressor.   Default is unset (which will use
              whatever the dpkg-source default is, currently '9').  Available to hook scripts  as
              DEB_COMPRESS_LEVEL.

       gitpkg.dpkg-source
              May  be  set to pass arbitrary options verbatim to dpkg-source(1) when building the
              source package.  Use with caution and at your own risk.  To pass  multiple  options
              to  dpkg-source you must set this option multiple times (ie. using git config --add
              for each option) due to the otherwise amusing quoting requirements for options such
              as  "--format=3.0 (native)".   Default  is empty.  Available to hook scripts as the
              indexed array DPKG_SOURCE_OPTS.  Do not use this to set the dpkg-source(1) -Z or -z
              options, they should instead be set using the deb-compressor and deb-compress-level
              options respectively.  This  may  be  overridden  on  the  command  line  with  the
              --dpkg-source=arg  option,  which  likewise  must  be  passed multiple times to set
              multiple options.

       gitpkg.create-fake-orig
              Sometimes both upstream source and debian support really are  intermingled  into  a
              single  branch of the repo but you'd still like to make a 'non-native' package from
              it.  gitpkg can fake an orig tarball from such a tree out  of  everything  but  the
              contents  of  the  debian/  directory.   Setting  this  option to 'true' makes that
              behaviour the default if a single treeish is passed to gitpkg and no  corresponding
              orig  tarball  is  found.   Setting  this  option to 'false' will make gitpkg fail,
              reporting an error, if a single treeish is passed and  no  orig  tarball  with  the
              correct  version  already  exists  for  it (and none was retrieved by a hook script
              prior to it being needed).  If this option is unset then the user will be  prompted
              for the correct thing to do if this situation arises.  Default is unset.  Available
              to hook scripts as CREATE_FAKE_ORIG.

       gitpkg.force-overwrite-orig
              This option controls  the  behaviour  of  gitpkg  if  an  'origbranch'  treeish  is
              specified  and the corresponding orig.tar for the 'branch' already exists.  If this
              is set to 'true', then the orig.tar will be overwritten with the  repo  source  (to
              reuse  an existing orig.tar simply call gitpkg with only the single debian 'branch'
              treeish you wish to export).  If this is set to 'false', then it is a hard error to
              attempt  to  export the upstream source again when the orig.tar already exists, and
              gitpkg will terminate and scold you if you try.  If  unset  you  will  be  prompted
              about  whether  to overwrite it or not, and the build will continue using whichever
              of the two  you  selected.   Default  is  unset.   Available  to  hook  scripts  as
              FORCE_OVERWRITE_ORIG.

       gitpkg.keep-unpacked-source
              This option controls whether or not the unpacked source directory is kept after the
              package export and exit hook have  successfully  completed.   If  this  is  set  to
              'true', the unpacked source will be retained.  If set to 'false' or unset then that
              directory will be removed as the final operation before gitpkg exits if  all  prior
              operations completed successfully.  Default is unset.  Available to hook scripts as
              KEEP_UNPACKED_SOURCE.  This  may  be  overridden  on  the  command  line  with  the
              --keep-unpacked-source=bool option (where 'no' or 'false' will not keep it, and any
              other value, including nothing, will).

SCRIPT HOOKS

       User defined scripts can be invoked from a number  of  points  during  the  package  build
       process.   They  are  sourced  into  gitpkg  as  bash  shell  snippets, in most cases in a
       subshell, so they can read state variables and perform external actions, but cannot  alter
       the  running configuration once a build is in progress.  If a hook returns with a non-zero
       status, then gitpkg will be terminated.  (Hooks that do terminate gitpkg should take  some
       care  not  to  leave too much of a mess, but also should leave enough clues intact for the
       user to diagnose and fix whatever the problem was.  Useful and informative error  messages
       should be barked to stderr before exiting in this way.)

       Hook scripts may be installed on the host system outside of the repo tree, or sourced from
       version controlled files in the repo itself.  Both methods have advantages and  risks  for
       different  use  cases.   Hook  scripts  are  activated by the local admin, by setting each
       relevant git-config(1) option with the path to the script to be executed.   Paths  may  be
       absolute  or  relative to the directory which that hook is called from.  If a hook is set,
       the script must exist when it is called.  Care should be taken to only enable them for use
       by  trusted  source  trees when hooking into files in the repo itself.  Usually you should
       enable them on a per-repo basis with git-config(1) rather than at a --global  or  --system
       level.

   A brief admonition against getting hooked:
       You should avoid complicated in-package hook arrangements becoming essential for exporting
       your package source.  If you need them to create a particular package correctly, and  need
       strict version binding with the source being released, and they aren't useful to any other
       package at all ...  then you're quite probably doing something, or several  things,  quite
       wrong.   Else  you're  in  such deep shit working around some broken build system that you
       don't need me to tell you about it.  Either way, local admin  has  to  enable  your  hooks
       before they can run, so if you want to be friendly to others (and yourself), then keep the
       'normal' packaging work strictly inside the usual package building tools,  and  leave  the
       gitpkg  hooks  free  for  other  local  admins to wrap whatever automation it is they need
       around things.  If a particular version  of  the  package  source  needs  some  particular
       actions  performed on it prior to the first source package build, then the PREBUILD_TARGET
       option from above is most probably what you want rather than one of  these  hooks.   Other
       people  can  use  that  again later without needing to have gitpkg around.  The aim is for
       this to Help You.  For some values of All Of You.  So do be careful to  avoid  letting  it
       screw  other  people over if the hook isn't called, and/or let them know what they need to
       do instead if it isn't.  Ok then, there's the barb to watch out for, so back to the  point
       again:

   Hook points
       The available hook points are listed below in roughly the order that they would usually be
       invoked:

       gitpkg.package-config-hook
              This hook runs in the top level directory of the repo gitpkg was invoked in,  prior
              to any operations taking place, with all git-config(1) sourced options available to
              it.  No detailed information about the package itself  is  available  in  the  hook
              environment  yet,  not  even its name or version, only the tree-ish(es) that gitpkg
              was passed by the user, but the hook may run  its  own  self-checks  based  on  the
              current (possibly 'dirty') contents of the working tree that gitpkg was invoked in.

              This  hook  is  able  to  modify  the gitpkg configuration variables for subsequent
              operations.  It can perform operations on the repo if needed, but since it needs to
              be  committed  to the repo before it will ever be called, that may not be so useful
              here in practice.  Basically, it can do anything it  pleases,  it's  just  a  shell
              script, nothing else has really begun yet, and it has been sourced into the topmost
              shell level of gitpkg.

              Its operation is different from the admin-config-hook in only one respect, the path
              to  this hook must be relative to the TLD of the repo, and the revision of the file
              that will be sourced is checked out from the  'branch'  tree-ish  that  gitpkg  was
              requested to export.  The file must exist in that version at the path given.

              Available to hook scripts as PACKAGE_CONFIG_HOOK.

       gitpkg.admin-config-hook
              This  hook  is  run  after  the package-config-hook returns, and differs from it in
              operation only by reading a static file from the  current  filesystem  rather  than
              extracting a version controlled one from the repo being exported.

              This  can be used by the local admin to override any package specific options, that
              may have been set by the package-config-hook,  with  site  specific  configuration.
              This  is  a policy control, not a security one.  Security was all over when you let
              the package-config-hook run, this just lets you override it without having to  fake
              up a new commit changing the package hook.

              This  is  the  last hook to run that is able to modify the gitpkg configuration and
              set environment options that will be visible to later  hooks.   Available  to  hook
              scripts  as ADMIN_CONFIG_HOOK.  This may be overridden on the command line with the
              --admin-config-hook=path option.

       gitpkg.pre-export-hook
              This hook runs in the top level directory of the repo, after the package  name  and
              version  have  been  determined, and with the final package configuration including
              any tweaking by the previous hooks.  It cannot  alter  any  configuration  options,
              only act upon them or terminate gitpkg.

              This can be used to do things like invoke pristine-tar or prefetch an existing orig
              tarball from some foreign source.  It may perform operations on  the  repo  if  any
              such  are  desired,  or any other last minute check that needs to be done before we
              actually get about the task of exporting the source we want packaged.

              Available to hook scripts as PRE_EXPORT_HOOK.

       gitpkg.deb-export-hook
              This hook  runs  in  the  top  level  directory  of  the  exported  debian  source,
              immediately  after  the  source  has been exported from the requested tree-ish, and
              immediately prior to the PREBUILD_TARGET being invoked (if  provided).   It  cannot
              alter  any  configuration options, only act upon them or terminate gitpkg.  If this
              hook terminates gitpkg, the exported source directory will be left  on  the  system
              for  the  user  to  inspect.  Subsequent invocations of gitpkg for the same release
              version will overwrite it though.  Available to hook scripts as DEB_EXPORT_HOOK.

       gitpkg.orig-export-hook
              This hook runs in the top  level  directory  of  the  exported  'upstream'  source,
              immediately  after  the  source  has  been exported from the provided tree-ish, and
              prior to it being compressed into a tarball.  It  cannot  alter  any  configuration
              options,  only  act upon them or terminate gitpkg.  If this hook terminates gitpkg,
              the exported source directory will be left on the system for the user  to  inspect.
              Subsequent  invocations  of  gitpkg  for the same release version will overwrite it
              though.

              This hook is only invoked if the upstream 'origbranch' actually  is  exported  from
              the  repository.   If  an  existing  orig.tar  is found or has been created by some
              earlier hook (and it is not being  overwritten,  see  force-overwrite-orig  above),
              then  the  operations this hook would perform are presumed to have already happened
              for this tarball and it is skipped.

              It is not safe to assume that this hook will  be  executed  before  or  after  deb-
              export-hook,  and  it  may  in fact be run in parallel with it at some point in the
              future.  They both will be entered after  pre-export-hook  returns,  and  exit-hook
              will not begin until (at least) after both have returned.  What else happens in the
              middle of all that we make no firm promises about at this stage.

              Available to hook scripts as ORIG_EXPORT_HOOK.

       gitpkg.exit-hook
              This hook runs in the directory where the  package  .dsc  was  deposited  by  dpkg-
              source(1),  after all internal gitpkg operations have successfully completed.  It's
              too late to alter any configuration options, or even to  terminate  gitpkg  really.
              You  can  pretty much do what you like from this one, anything that goes wrong from
              here on is your own doing.  Available to hook scripts as EXIT_HOOK.   This  may  be
              overridden on the command line with the --exit-hook=path option.

   Hook Environment
       The  following variables are made available for hook scripts, in addition to those already
       listed as shadowing a git-config option from above.  Not all of them are  valid/useful  at
       all  hook points, see the hook documentation above for the exceptions applying to specific
       hooks.

       GITPKG_HOOK_API
              Permits hook scripts to query what interfaces are available to them.  Has only  two
              numeric  components  separated  by  a '.' of which the number to the right of point
              will get incremented every time we add some new variable a hook  might  access,  or
              add  some  new knob it might tweak where existing interfaces have not have changed.
              If we do screw up and need to change some current interface, the number to the left
              will get bumped.  The current API version is 0.2

   Available in API version 0.1
       These variables have been available to hooks since gitpkg version 0.13

       GITPKG_TREEISH
              The user-passed debian 'branch' tree-ish that gitpkg was invoked to export.

       GITPKG_ORIG_TREEISH
              The 'origbranch' tree-ish that gitpkg was invoked with.  This will be empty if only
              a single 'branch' tree-ish was specified.

       DEB_SOURCE
              The name of the source package to create, without any versioning.  As seen  in  the
              Source: field of dpkg-parsechangelog(1).

       DEB_VERSION
              The  version  of  the  source package to create, without any epoch.  As seen in the
              name of the .diff.gz and .dsc files.

       UPSTREAM_VERSION
              The version of the source package to create, without any debian version.   As  seen
              in  the  name  of  the  orig tarball.  For native packages this will be the same as
              DEB_VERSION.

       DEB_ORIG
              The full versioned filename of the orig tarball to use or create.  This variable is
              empty for native packages without a Debian version part.

       DEB_DSC
              The full filename of the package .dsc that will be or has been created.

       DEB_PACKAGE
              The directory name of the debianised source tree to pass to dpkg-source(1).

       REPO_DIR
              An  absolute path to the top level directory of the git repo we are exporting from.
              Usually, if you need to look out of the tree  that  you  were  dropped  in,  you're
              probably doing something (at the) wrong (time), but there are exceptions, and being
              able to query git-config options is one of them.  That's mostly what  this  one  is
              for  right now.  See the repo-config-helper documented below.  Be careful if you do
              use it for much else.

   Available in API version 0.2
       These variables have been available to hooks since gitpkg version 0.24

       GITPKG_AOPTS
              An associative array containing the command  line  options  not  parsed  by  gitpkg
              itself  which  can be used to override the behaviour of a hook.  The array is keyed
              on the names of the options with  the  '--'  removed.   If  an  option  was  passed
              multiple  times,  only  the  last  value  passed will be stored in this array.  For
              example:

               $ gitpkg --my-option=foo --option2 --opt=oops --opt='bar baz'

              Will give:

               ${GITPKG_AOPTS[my-option]} = "foo"
               ${GITPKG_AOPTS[option2]}   = ""
               ${GITPKG_AOPTS[opt]}       = "bar baz"

       GITPKG_IOPTS
              An indexed array containing the command line options not parsed  by  gitpkg  itself
              which  can  be  used  to  override  the behaviour of a hook. The array contains the
              literal option strings passed and so can  be  used  to  access  options  which  are
              intended to be passed multiple times.  For example:

               $ gitpkg --my-option=foo --option2 --opt=oops --opt='bar baz'

              Will give:

               ${GITPKG_IOPTS[0]} = "--my-option=foo"
               ${GITPKG_IOPTS[1]} = "--option2"
               ${GITPKG_IOPTS[2]} = "--opt=oops"
               ${GITPKG_IOPTS[3]} = "--opt=bar baz"

              The extract_values_for_option function in repo-config-helper (see below for details
              of it) can be used to further parse this array to obtain all  the  value(s)  for  a
              specific option.

   Hook Library
       There  are some canned hook scripts for various tasks available in /usr/share/gitpkg/hooks
       which currently include:

       cowpoke-exit-hook
           A simple exit hook which sends the exported package off for building using cowpoke(1).
           To enable it:

            $ git config gitpkg.exit-hook /usr/share/gitpkg/hooks/cowpoke-exit-hook

           Additional git-config(1) configuration options:

           gitpkg-cowpoke-exit-hook.ask-first
                   If  'true' prompt for confirmation before calling cowpoke.  Default is to just
                   go ahead and do it.

           gitpkg-cowpoke-exit-hook.options
                   May include any other options to pass verbatim to cowpoke.  To  pass  multiple
                   options,  set  this  multiple  times,  once  for  each  option.   This  may be
                   overridden on the command line with the --cowpoke=arg option,  which  likewise
                   must be passed multiple times to set multiple options.

       dpkg-buildpackage-exit-hook
           A  simple  exit  hook  to build binary packages locally with dpkg-buildpackage(1).  To
           enable it:

            $ git config gitpkg.exit-hook /usr/share/gitpkg/hooks/dpkg-buildpackage-exit-hook

           Additional git-config(1) configuration options:

           gitpkg-dpkg-buildpackage-exit-hook.ask-first
                   If 'true' prompt for confirmation before calling  dpkg-buildpackage.   Default
                   is to just do it.

           gitpkg-dpkg-buildpackage-exit-hook.options
                   May  include any other options to pass verbatim to dpkg-buildpackage.  To pass
                   multiple options, set this multiple times, once for each option.  This may  be
                   overridden  on  the command line with the --dpkg-bp=arg option, which likewise
                   must be passed multiple times to set multiple options.

           gitpkg-dpkg-buildpackage-exit-hook.build-log
                   If set 'false' don't save a log of the build process, the default is to record
                   one.

       pristine-tar-pre-export-hook
           A  hook  to  extract  an  orig  tarball  using pristine-tar.  Which orig to extract is
           determined by the package version of the 'branch' tree-ish.  To enable it:

            $ git config gitpkg.pre-export-hook /usr/share/gitpkg/hooks/pristine-tar-pre-export-hook

           If a pristine-tar branch is not found in the repo, then gitpkg will be terminated.

       quilt-patches-deb-export-hook
           This hook reads a list of revision ranges suitable for  git-format-patch(1)  from  the
           file  debian/source/git-patches,  one per line, and exports them to the debian/patches
           directory in a form suitable for (format 3.0) quilt packages.  It is not required  for
           creating such packages, but permits you to separate out individual patches however you
           please from the default single patch that is otherwise created by dpkg-source.

           To enable it:

            $ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook

           The contents of debian/source/git-patches may include comments (on any line  beginning
           with  a  #),  empty lines, and expressions of a range of commits.  The revision ranges
           may include $DEB_VERSION, $UPSTREAM_VERSION, $DEB_REF  or  $UPSTREAM_REF.   The  first
           pair  will  be  substituted with the version of the package being exported, the second
           pair with those version strings after mangling by sanitise_git_ref to remap them to  a
           legal  git  refname.   Using  the sanitised versions is to be preferred in most cases.
           For example:

            # Export all commits between these two treeishes,
            # based on the version of the package being exported.

            upstream/$UPSTREAM_REF..patches/$DEB_REF

       debcherry-deb-export-hook
           This hook invokes git-debcherry(1) to find and export patches to the  upstream  source
           in  a  form  suitable  for use with (format 3.0) quilt packages.  It allows for a more
           natural (and automatic) workflow than the quilt-patches hook above  by  searching  for
           patches made to the packaging branch that have not yet been applied upstream.

           To enable it:

            $ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/debcherry-deb-export-hook

           In  order  to  use this hook, a ${DEB_ORIG}.commit file must be created which contains
           the treeish of the exported upstream source in the repository.  This will  be  created
           automatically (if this hook is enabled) when you export an upstream tarball by passing
           both branch and origbranch to gitpkg, or if you use the  pristine-tar-pre-export-hook,
           which determines an appropriate commit corresponding to the tarball.  If your upstream
           tarball is created using some other mechanism you will need to  ensure  that  file  is
           created yourself.

           If  using  this  hook, you may wish to document that in your repository with something
           similar to the text  in  /usr/share/doc/gitpkg/examples/README.debcherry-export  as  a
           convenience  to  other  users. Your package will still be exportable without this hook
           enabled, it just won't have the upstream patches individually  separated  out  into  a
           quilt series.

   Hook Library Helpers
       These  are  even  more  trivial  snippets,  for  operations which may be shared by several
       scripts.  Also found in /usr/share/gitpkg/hooks.  Usually these would be sourced by  other
       scripts rather than being hooked to directly.

       repo-config-helper
           Provides  a  simple  wrapper  around `git config`, which ensures it is called from the
           repo tree where any repo-specific config options may be  stored.   Useful  to  scripts
           which aren't called from inside the repo tree, but which do have git-config options of
           their own to query.

           Provides the sanitise_git_ref shell function which remaps character strings  that  are
           illegal to use in a git refname.

           Provides  the extract_values_for_option shell function which can be used to extract an
           array of the values for a particular option from GITPKG_IOPTS.

           See the content of that file itself for more detailed documentation on  the  functions
           that it provides.

INTERACTIVIY

       If  you  intend  to call gitpkg from your own scripts, then you should note that there are
       two situations when it may prompt interactively by default.  There is  no  One  True  Sane
       Default  for  these  cases,  so it's better to just ask the user and continue than to make
       them start the whole process again in the  likely  case  where  they  have  called  gitpkg
       directly.   For  details,  see the gitpkg.force-overwrite-orig and gitpkg.create-fake-orig
       config options above.  You should set both explicitly to the  behaviour  that  you  desire
       from them if gitpkg should never become interactive.

WORKFLOW

       Though  gitpkg explicitly does not try to force any particular workflow procedure upon you
       in order to make full use of it, it probably is worth making quick mention of at least one
       simple way to manage Debian packages in git.

       One  common  repo  structure  is  to keep pristine upstream source on one branch, which is
       updated either directly from  an  upstream  repo  or  by  importing  tar  archives  to  it
       periodically,  with  the  Debian  patched source on another branch.  In this situation the
       task of preparing a new upstream release from a tarball might look a bit like this:

          Check out the upstream branch
        $ cd myrepo
        $ git checkout upstream

          Remove all old upstream files from the repo
        $ rm -rf $(all_files_except .git)

          Unpack the new tarball in their place
        $ tar zxf $new_upstream.tar.gz

          Let git figure out what is renamed/new/gone by itself.
          Make sure you don't have things like vim .swp files lurking
          in the tree still at this point.
        $ git add .
        $ git commit -a
        $ git tag v$upstream_version

          Prepare the Debian branch
        $ git checkout debian
        $ git merge upstream
        $ $(update changelog and other debian patches etc.)
        $ git commit -a
        $ git tag v${upstream_version}-$debian_version

          Make a release
        $ gitpkg v${upstream_version}-$debian_version v$upstream_version
        $ cd ../deb-packages/mypackage && dpkg-buildpackage ...

SEE ALSO

       git-debimport(1), git-debcherry(1),  git(1),  git-archive(1),  git-config(1),  git-format-
       patch(1), gitattributes(5), dpkg-source(1), cowpoke(1).

AUTHOR

       gitpkg was written by Ron <ron@debian.org>.

                                        September 28, 2014                              GITPKG(1)