Hi Mo, Mattia, On Tue, Jan 08, 2019 at 08:16:58PM +0100, Guido Günther wrote: > On Tue, Jan 08, 2019 at 06:19:32PM +0100, Mattia Rizzolo wrote: > > On Thu, Jan 03, 2019 at 06:00:18PM +0100, Guido Günther wrote: > > > > It's quite strange that I cannot reproduce this problem anymore > > > > on the commit in question. > > > > > > > > @Mattia: Are you able to reproduce this problem? > > > > Weird, indeed I can't reproduce this right now :\ > > So upsetting, consider how many headaches it gave me over the years. > > > > > That does not work you want to use gbp export-orig to export the > > > tarballs and pass the subtarball names with --component (it's symmetric > > > to the import) since you otherwise lack the needed trees. Check the tb > > > package. So far I don't see a bug here. > > > > > > gbp export-orig --component contrib > > > > Could you please explain what `gbp export-orig` does? > > I never heard of that command, and till now I always called > > `pristine-tar checkout ../foobar_ver.tar.xz`. And to be honest I expect > > that to work regardless of what wrapper was used to do the initial > > `pristine-tar commit`. > > > > What particulare tree are you expecting? > > The only thing I can think of is a tree with the main tarball without > > the additonal tarball committed, are you having `export-orig` generate > > such a thing each time somehow (how would you get the same sha1??) > > You need a tree that has the component's tarball dirs dropped: > > https://github.com/agx/git-buildpackage/blob/master/gbp/scripts/export_orig.py#L77 > > gbp-buildpackage uses the same code when generating tarballs.
Is there still an issue with opencv and it's additional tarball that I could reproduce? > Cheers, > -- Guido
