[git-buildpackage] git-buildpackage-rpm patchset 2015-11-20

[Markus Lehtonen]

Hi,

On Fri, 2015-11-20 at 18:38 +0100, Guido Günther wrote:
> Hi,
> On Fri, Nov 20, 2015 at 04:39:44PM +0200, Markus Lehtonen wrote:
> > Hello,
> > 
> > I've rebased my patchset(s) at https://github.com/marquiz/git-buildpackage-rpm. The list of branches is the usual:
> >   experimental-rpm
> >   feature/argparse
> >   feature/buildpackage-rpm
> >   feature/fixes
> >   feature/import-srpm
> >   feature/misc
> >   feature/pq-rpm
> >   feature/python-pkg-resources
> > 
> > The 'feature/fixes' branch contains few new fixes that should be quite straightforward to merge.
> 
> I have pulled
> 
>   82999a8ae42477db4c7e2bc6dee7d5f1c3f6c6a0 docs: enable building html docs with docbook2html
>   1fdb6976b3c32828afa2571cdcc95136f70f9b4f buildpackage-rpm: fix crash when creating packaging tags
>   ac020c3e104e2057ae8e9e7b5f95dbe9c12f61ef rpm packaging: bump package version to 0.7.0

Great, thanks!


> Thanks a lot! I'll try to find some to look into the other stuff but
> things are currently piling a bit up here.
> 
> I have left out
> 
>     tests: update rpm test data submodule to a valid commit
> 
> for the moment since it seems I have a valid commit here

I don't think so as .gitmodules still points to my github repo
(git://github.com/marquiz/git-buildpackage-rpm-testdata.git) which does
not contain the commit:
$ git clone --mirror -q
git://github.com/marquiz/git-buildpackage-rpm-testdata.git
$ cd git-buildpackage-rpm-testdata.git/
$ git show bea3aa372447b2fca611f187c2daa55edd8cdb3f
fatal: bad object bea3aa372447b2fca611f187c2daa55edd8cdb3f


> and I think we
> need to rethink the strategy for this submodule. For the deb component
> tests I'm keeping everything in HEAD and set up everything from
> there. The rpm tests need different commits to function which causes/caused
> some breakackge here when pulling in more component tests so I think we
> would be better of needing only a single commit like in the deb
> case. Would that be doable?

I haven't figured out any better way – although I admit that this is not
the most elegant solution. The other branches in the testdata repository
basically represent various test packages (i.e. test repositories can be
constructed from those). I didn't find any nice and easy way to
serialize the test repositories (to construct them at test time) either.
And additional git submodules (per-testpackage submodule) don't work
either because the test repositories usually require multiple branches
(upstream, packaging, pristine-tar) and this is not supported in git
submodules which work on single HEAD commit. Better ideas are welcome,
of course.


> > Have you taken a (fresh) look on the 'feature/argparse' branch? I think I've addressed all the comments.
> 
> Skimmed through it but I'll need to find a longer timeslice to review
> this in depth.
> 
> > Any comments on hte 'feature/misc' branch? That has been around for quite some time but I think it hasn't got any review.
> 
> Pulled in one already. The other stuff looks sane too but it adds more
> code without tests so I need to find the time to add these before
> merging.

One problem is that most of the commands (pull in this case) don't have
any "component tests" yet so adding test cases for e.g. new command line
options is tedious, or, not straightforward at least.


> Cheers and thanks a lot!

Thanks,
  Markus