git-ubuntu build

[Bryce Harrington]

On Wed, Jun 07, 2023 at 06:41:14PM -0700, Steve Langasek wrote:
> Hi folks,
> 
> As git-ubuntu sees increasing use, including for such things as requests for
> sponsorship of Debian merges, I've had an itch to scratch regarding the
> complexity of passing correct flags to dpkg-buildpackage, so I spent some
> time prototyping a git-ubuntu wrapper for it.
> 
> bzr-builddeb hasn't been useful for general work on Ubuntu packages for
> quite a while, but the behavior of this wrapper is inspired by it. 
> Hopefully some of you will find using this tool pleasantly familiar!
> 
> The intent is that this will eventually become a git-ubuntu subcommand,
> though there are some namespace questions to sort out first - the obvious
> name for such a command IMHO would be 'git-ubuntu build' but that already
> exists and does other things.

It does not exist, actually!  I recall we dropped it a few years ago,
see see f2dc622e.  I recall at the time it was intended to one day bring
it back, but the plan was to reimplement - as you're doing - but also
build it up from first principles with ample test case coverage.  The
original subcommand lacked tests, but tried to do a bit too much (it
included wrapping lxd, running lint, etc.) and the lack of tests made
maintenance a bit scary.  So, I'd encourage making matching tests as you
go.  :-)

That said, though, I've wondered if 'build' may not necessarily be the
ideal jargon, anyway.  Since the (prepare-upload args) step can trigger
a git push, and because this is done principly when uploading, it feels
more like a submission-style workflow than a build; "build" also implies
you're creating some form of artifact for local use, which in this case
you're not, really.

So, I'd suggest that even though 'git-ubuntu build' is not used, you may
still want to think more anyway about if there's a better term.


> From initial feedback, I know a lot of developers are using sbuild to build
> their source packages rather than invoking dpkg-buildpackage directly.  I
> would like to provide a corresponding wrapper for sbuild as a next step - I
> would suggest this should eventually be called 'git-ubuntu sbuild'.
> 
> Anyway, I've been using this script in anger for a week, so I'd like to
> welcome other folks to give it a try now as well.
> 
> To get started:
> 
>  git clone lp:git-ubuntu
>  cd git-ubuntu
>  sudo mk-build-deps -i -r . (or: sudo apt build-dep .)
>  export PATH=$PATH:$(pwd)/sandbox
> 
>  then cd to a git-ubuntu repo, and:
> 
>  gu-build
> 
> Note that this calls the equivalent of `git-ubuntu prepare-upload args`
> under the hood, so will push to a launchpad branch under your user.
> 
> Why this is useful:
> 
> - the syntax 'dpkg-buildpackage $(git-ubuntu prepare-upload args)' is
>   onerous and repetitive - but we want to encourage inclusion of these
>   headers in .changes files, as this lets us automate closure of git-ubuntu
>   MPs
> - there are certain options that can be inferred as correct for any
>   git-ubuntu repo (-i -I)
> - orig.tar.xz should be reconstituted or downloaded when needed, without
>   extra commands (we have pristine-tar branches in git-ubuntu which often
>   save having to do a duplicate download; having to clone a git repository
>   *and* apt source the package is meh)
> - getting the correct options to dpkg-buildpackage by hand for a package
>   merge is tedious; this automates -v and -sa arguments.

Very cool, and I'll have to look at what you're doing to automate the
-sa arguments, I hadn't figured out a good solution there.

Btw, you may already be doing this but I've found in scripting this
myself that it's worthwhile to check the $(git ubuntu prepare-upload
args) run for exit codes before passing its output along; there are
situations where it fails.

In addition, I always do a grep "^Vcs-Git" on the produced changes file,
since if prepare-upload fails (or you're using an old git-ubuntu version
that doesn't have it), you can accidentally end up producing a valid
.changes file that doesn't have the Vcs info.

Bryce