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

[Markus Lehtonen]

Hi,



On 27/11/15 17:38, "Guido Günther" <agx at sigxcpu.org> wrote:

>Hi Markus,
>On Fri, Nov 27, 2015 at 04:43:56PM +0200, Markus Lehtonen wrote:
>[..snip..]
>> > > 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.
>> 
>> I played around with one idea I had earlier and came up with a solution
>> to the problem of storing test package git repositories. Please see the
>> 'feature/component-tests' branch in my Github repository
>> https://github.com/marquiz/git-buildpackage-rpm
>>
>> Now, all test data is available in submodule 'HEAD' - test package git
>> repositories are serialized as patches (and some additional data) in
>> separate subdiretories. The branch also contains two patches for
>> buildpackage-rpm (cherry-picked from the 'feature/buildpackage-rpm'
>> branch) that are needed for the buildpackage-rpm unit tests to pass. It
>> also contains one "optional" patch that makes names of the per-testcase
>> temporary directories more user friendly.
>
>Awesome! This makes the rpm and deb component tests use the same
>"strategy" (the rpm ones being far more complete). Running the tests
>fails on me with:
>
>nosetests -x
>ERROR: Basic test of native pkg
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "/var/scratch/src/git-buildpackage/git-buildpackage/tests/component/rpm/test_buildpackage_rpm.py", line 116, in test_native_build
>    self.init_test_repo('gbp-test-native')
>  File "/var/scratch/src/git-buildpackage/git-buildpackage/tests/component/rpm/__init__.py", line 58, in init_test_repo
>    dirname = os.path.basename(cls.orig_repos[pkg_name].path)
>KeyError: 'gbp-test-native'
>
>though. This is the first error. I have the full log attached.

Oh, sorry, there was erroneous glob in my patch. I pushed a fixed version into my branch. It should work now, please test.


>Two further things:
>
>* please add gbp_*/ to .gitignore in the data repo so we don't get any
>  untracked content after running the tests.

Hmm, no gbp_* temporary directories should be created under the data (tests/component/rpm/data) directory. They should be created in the cwd of the user which should be topdir of gbp.


>* It seems manage.py uses lots of code from gbp. Wouldn't it be better
>  to reuse this. We can do this at a later time though, having the test
>  data for the component tests correct is much more important.

Yeah, there's a lot of similar code - doing similar things, variable names etc (although it's technically written from scratch). A lot of it is copied from my previous 'bootstrap.py' from the same repository. I specifically wrote it independently, in order to cut the circular dependency between the data repository and gbp api. The amount of overlapping code is not that big IMO, although there is more than I probably anticipated, initially. We can revisit this later, if needed.


>> If you're not going to merge this in the near future, please update the
>> rpm test data submodule into a valid commit. Currently, it points into
>> some local commit of yours or something as I pointed out in my earlier
>> email.
>
>I'd be happy to pull this in in general. There are some details with
>
>    common/buildpackage: support for different archive formats
>
>which I need to work out but that can be done afterwards as well.

Is there something specific? At least it shouldn't affect (deb )buildpackage at all because zip archives are not supported there.


Thanks,
   Markus