[PATCH for l,p,q,r,s,t}] UBUNTU: [Config] add debian/gbp.conf

Kamal Mostafa kamal at canonical.com
Thu May 29 08:39:21 UTC 2014

On Wed, 2014-05-28 at 13:26 +0200, Kamal Mostafa wrote:
> I'd like to apply the following patch (creates debian/gbp.conf) to P, Q,
> R, S, and T.  It has already been applied to Utopic.
> This new two-line file provides a definition for our standard git tag
> syntax (e.g. "Ubuntu-3.15.0-3.7") that can be used by git-buildpackage
> or related tools.

More details about why I want to add this two-line config file
"debian/gbp.conf" to all the Ubuntu kernel branches:
                debian-tag = Ubuntu-%(version)s

About git-buildpackage

There exists a program called 'git-buildpackage'[0] (in an apt-get
package of the same name) which can drive the process of constructing a
Debian package from a git branch, including various pre-validation
steps, running debuild, and automatically adding a correct git tag
constructed from the version number in the changelog.

I have been using[1] git-buildpackage to construct the kernel packages
for upload (and actually a short wrapper script which implements some of
our additional Ubuntu-kernel-specific process steps).

Advantages of using git-buildpackage to do the package construction:

 - Eliminates the very common human-error/typo mistakes that we
frequently make (incorrect git tags like forgetting to insert "-lts",
and generally inconsistent tag syntax).

 - Makes the whole source package build process more consistent, and
allows for us to move towards even more consistency in the future.
Later, we might consider enabling more of git-buildpackages optional
validation steps, or even construct a package-build-bot.

 - Its just a lot easier than trying to follow our complex wiki
instructions, which are mostly valid, but have lots of corner cases and
exceptions -- the places where we often make mistakes.

The two-line gbp.conf file

The purpose of the two-line gbp.conf file is simply to configure
git-buildpackage to create tags with our preferred git tag scheme, on a
per-branch basis.  Specifically, the config file to be checked into the
main Ubuntu kernel branches will configure it to create tags of the


The next step will be that I will want to add a (different) two-line
gbp.conf file to all of our LTS branches, to configure them to be tagged


Side note:  Andy and I have experimented with additional debian/rules
bits that could use the same gbp.conf file in steps like "fdr
insertchanges".  It could print out the correct git tag command for you
to cut-n-paste, as some of our other construction scripts do.

So this means that we now must use git-buildpackage???

No.  See [1].

The presence of the gbp.conf file will affect nothing at all, unless you
choose[1] to use git-buildpackage.

You are welcome to keep using your preferred method of constructing
packages and git tagging, if that's what you prefer[1][1][1].


[0] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.buildpackage.html
[1] ... but nobody's saying that you must use git-buildpackage.

> ---------------- >8 ----------------
> From 3ac646db5e2c9ac349c2c32fa7a198ea33acdcac Mon Sep 17 00:00:00 2001
> From: Kamal Mostafa <kamal at canonical.com>
> Date: Mon, 26 May 2014 12:20:05 +0200
> Subject: UBUNTU: [Config] add debian/gbp.conf
> Defines tag format for 'git buildpackage'.
> Acked-by: Andy Whitcroft <apw at canonical.com>
> Signed-off-by: Kamal Mostafa <kamal at canonical.com>
> ---
>  debian/gbp.conf | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 debian/gbp.conf
> diff --git a/debian/gbp.conf b/debian/gbp.conf
> new file mode 100644
> index 0000000..8ce5fda
> --- /dev/null
> +++ b/debian/gbp.conf
> @@ -0,0 +1,2 @@
> +[buildpackage]
> +debian-tag = Ubuntu-%(version)s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20140529/c58f76e7/attachment.sig>

More information about the kernel-team mailing list