[buildd-tools-devel] Making sbuild releases

[Wookey]

+++ Wookey [2014-09-29 12:41 +0100]:
> +++ Roger Leigh [2014-09-28 09:45 +0100]:
> > On Thu, Sep 25, 2014 at 10:10:30PM +0100, Wookey wrote:
> > > +++ Benjamin Drung [2014-09-25 16:50 +0200]:
> > > > Hi,
> > > > 
> > > > due to some bugs (#700522, #714883, #756265), I like to offer my help to
> > > > maintain sbuild. Do you have any rules for committing to the git
> > > > repository and for doing releases?
> > > 
> > > I'd like some advice on procedure too.
> > 
> > I'll add notes on how to make a release to git, i.e. what to tag,
> > test and run to make the release tarball.  It's not too involved,
> > but it probably needs writing down.

I found the HACKING file which actually gives some useful details.

However it seys to use 'make check' which is good advice but as a
makefile is not built directly in the source tree you need to run it
elsewhere. It seems to build in debian/build but running make check in
there does not work due to 'wrong number of ../' 

Running make -f debian/rules/Makefile check works OK

(Is there a reason that we don't run make check during the normal
package build? That is generally deemed good practice?)

It also tells you to use ./configure --enable-maintainer-mode which now gives:
configure: WARNING: unrecognized options: --enable-maintainer-mode.
but make distcheck does now run.  I guess enable-maintainer-mode is obsolete now?

make distcheck fails near the end with recipie for target 'distcleancheck' failed:
EROR: files left in build directory after distclean 
<list of manpages>

It does make an sbuild-ver dir and tarball, which is good, but
does it _inside_ the sbuild git dir, which seems wrong. Should I be
invoking it some other way? or is this just because it didn't complete?

make check at this point works OK, which I guess is what the HACKING
file intended people to do, despite listing the actions with make
check first?

Also ./bootstrap currently runs autoreconf, but the normal package
build doesn't. In line with the rest of debian we should probably be
re-autoconfing during build. Anybody have philosophical obhjections to
that?

So all this more-or less works, but it seems that the HACKING file is
slightly out of date, and I may not be issuing quite the right runes as
there is some breakage. 

I'll prod about some more. Is there a place where our 'upstream'
releases go? I note that
https://alioth.debian.org/projects/buildd-tools/ only has v0.55 (may
2007) so I guess that's not the place :-)
Or do we just immediately use the orig.tar.gz created to make a debian
-1 release?

I've now pushed my changes to master (for 0.64.3) so you can play with
basically what I have (I have one pending commit for the NEWS file and
changing UNRELEASED -> unstable and adding me to uploaders -
i.e. actually making a release, but I've not pushed that due to the
above confusion/breakage).

OK. So here is a procedure that works for me:

git clone git://git.debian.org/git/buildd-tools/sbuild
!patch (attached) (patch -p2 < 0.63-release.patch) to update NEWS,  UNRELEASED -> unstable!
in that dir do
scripts/git-tag-release
./bootstrap
./configure
make distcheck (make distcleancheck fails due to leftover manpages)
make check (passes, optional)
mv sbuild-0.64.3.tar.gz ../sbuild-0.64.3.orig.tar.gz
sudo rm -r sbuild-0.64.3  (tidying up due to failed distcleancheck?)
make distclean (more tidying?)
dpkg-buildpackage

That process generates a sensibly-sized orig.tar.gz of 570K (i.e not
full of build artifacts), and plausible-looking packages with the
right versions, so apart from the man-page distcleancheck issue may be
somewhere near the expected procedure.

Am I doing anything wrong to have the distcleancheck failure and orig
tarball that needs copying up a level, or does it just need fixing?

Should I be using the generated-then-unpacked sbuild.orig.tar.gz to do
the debian dpkg-buildpackage step (as opposed to the git checkout) -
or does it not actually matter?

Should I update the HACKING file to clarify the stuff I've stumbled over above?

I realise these are a lot of dumb questions, but without having done
this before it seems easy to make a wrong assumption about exactly how this is
intended to be used.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/