> 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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
