[git-buildpackage] `gbp import-orig --pristine-tar` with component tarballs

[Nish Aravamudan]

On 06.07.2017 [08:25:14 +0200], Guido Günther wrote:
> Hi,
> On Wed, Jul 05, 2017 at 12:47:49PM -0700, Nish Aravamudan wrote:
> > On Thu, Jun 29, 2017 at 5:59 PM, Nish Aravamudan
> > <nish.aravamudan at canonical.com> wrote:
> > > Hello,
> > >
> > > I *think* I may have found a bug in `gbp import-orig --pristine-tar` with
> > > multiple component tarballs, but I'm not 100% :)
> > 
> > I think I can TL;DR my previous e-mail a bit, hopefully to encourage
> > some feedback:
> > 
> > I think that when `gbp import-orig --pristine-tar --component=...`
> > runs, the treeish's stored in the pristine-tar commits are
> > sub-treeish's of the treeish obtained by untarring the main and all
> > component tarballs. These treeishs, though, are not stored in git at
> > all, as they are synthesized by create_pristinetar_commits in order to
> > invoke `pristine-tar commit` for each tarball. So when you push/pull
> > the reachable objects from the importer repository, the stored
> > treeishs become unresolveable by git.
> > 
> > I'm not sure why they are resolveable by git when doing the import
> > itself. I wonder if there is some local caching going on, but `git
> > push` doesn't just push everything, it only pushes reachable objects
> > (aiui).
> 
> Can you provide steps to reproduce your problem?

Of course, sorry for not providing that earlier! It turns out that after more
reviewing, it's not the component tarballs that are unreproducible, but the orig
tarball itself (in the case of gosa).

Test case:

$ dir=$(mktemp -d)
$ cd $dir
$ pull-debian-source -d gosa
$ mkdir gosa
$ cd gosa
$ git init .
# there are more components, but this is sufficient
$ gbp import-orig --pristine-tar --component=webdav --component=uw-imap --component=systems ../gosa_2.7.4+reloaded2.orig.tar.gz
What will be the source package name? [gosa] 
What is the upstream version? [2.7.4+reloaded2] 
gbp:info: Importing '../gosa_2.7.4+reloaded2.orig.tar.gz' to branch 'upstream'...
gbp:info: Source package is gosa
gbp:info: Upstream version is 2.7.4+reloaded2
gbp:info: Successfully imported version 2.7.4+reloaded2 of ../gosa_2.7.4+reloaded2.orig.tar.gz
$ pristine-tar list
gosa_2.7.4+reloaded2.orig-webdav.tar.gz
gosa_2.7.4+reloaded2.orig-uw-imap.tar.gz
gosa_2.7.4+reloaded2.orig-systems.tar.gz
gosa_2.7.4+reloaded2.orig.tar.gz
$ pristine-tar checkout gosa_2.7.4_reloaded2.orig.tar.gz
pristine-tar: successfully generated gosa_2.7.4+reloaded2.orig.tar.gz
$ diff -q gosa_2.7.4_reloaded2.orig.tar.gz ../gosa_2.7.4_reloaded2.orig.tar.gz
$ echo $?
0
$ git push <somewhere, e.g., git+ssh://nacc@git.launchpad.net/~nacc/+git/gosa-import> master upstream pristine-tar
$ cd ..
$ mkdir gosa_test
$ git clone <somewhere> gosa_test
$ cd gosa_test
$ pristine-tar list
gosa_2.7.4+reloaded2.orig-webdav.tar.gz
gosa_2.7.4+reloaded2.orig-uw-imap.tar.gz
gosa_2.7.4+reloaded2.orig-systems.tar.gz
gosa_2.7.4+reloaded2.orig.tar.gz
$ pristine-tar checkout gosa_2.7.4_reloaded2.orig.tar.gz
fatal: ambiguous argument 'ef482620c30c35481200d24897babedc7087718a^{tree}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: Not a valid object name
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
pristine-tar: command failed: git archive --format=tar ef482620c30c35481200d24897babedc7087718a\^\{tree\} | (cd '/tmp/pristine-tar.Fu741PYlX4' && tar x)

> As I said: the unref'ed trees are recreated on the fly so no need to push
> them. They're not even referenced by commits.

Where did you say this? Sorry, if there was a previous reply to my original
e-mail, I didn't see it.

Is there possibly an issue where the recreation of the unref'd trees on
the fly doesn't work when it applies to the orig tarball itself (which
has components elided from it)?

Thanks,
Nish