[git-buildpackage] git-mock [was: Re: Bug#771215: git-buildpackage: please merge support for gbp pq-rpm]

[Guido Günther]

Hi Tzafrir,
On Tue, Dec 30, 2014 at 11:16:37AM +0100, Tzafrir Cohen wrote:
> On Sun, Dec 28, 2014 at 02:27:51PM +0100, Tzafrir Cohen wrote:
> > On Sun, Dec 28, 2014 at 01:22:27PM +0100, Guido Günther wrote:
> > 
> > > ======================================================================
> > > ERROR: test suite for <class 'tests.component.rpm.test_pq_rpm.TestPqRpm'>
> > 
> > Speaking of tests, I think that the following should also be included in
> > the branch (unless I missed it elsewhere):
> > 
> >   http://git.tzafrir.org.il/cgit/git-buildpackage.git/commit/?id=b2d8fa3bdb750ddf974cb605de4e5f0c9b4281cb
> > 
> > That repo also has a brute-force rebase of buildpackage-rpm on top of
> > 0.6.22 (just that command. Others are still missing).
> 
> On top of that I now have an initial version of --git-mock - using mock
> as a chroot builder for rpm packages. I basically copied the way
> pbuilder is used (created a separate git-mock and used it as a builder).
> Mock is already installed by default with its own permission elavtion
> handler.
> 
> http://git.tzafrir.org.il/cgit/git-buildpackage.git/commit/?h=buildpackage-rpm&id=03e38ad87c882d62ce9f54709fcf8c535edc36fa
> 
> (I finally have clone URLs listed, but this is a single commit)
> 
> Basic usage:
> 
>   gbp buildpackage-rpm --git-mock --git-dist=epel-6
> 
> Some notes:
> * It runs mock twice. Once for generating the srpm and once for
>   generating the package from that. This is because some packages have
>   platform-dependent macros that may be expanded at srpm-build time.
> 
>   Avoiding that and using rpmbuild directly would have been faster.
> 
> * I currently (for the sake of simplicity) avoid interpreting any
>   define-s sent in the command line and just assume the spec will be in
>   ./SPECS, sources in ./SOURCES, place the SRPM under ./SRPMS (I
>   consider it temporary).
> 
> * I don't have a good default for the resulting files. Currently I place
>    the results under ./results/<dist>/<arch>
> 
> What do you think?

I think that's great. The shell script needs some more work but the
python side needs surprisingly few modifications.

In the long run we need to think about on howto support different
builders like pbuilder and sbuild but that's a different issue.

I've cc'ed the gbp list on that in case somebody wants to pick up form there.
Cheers,
 -- Guido