[Debian-med-packaging] Inconsistencies in pristine-tar of several packages

[Andreas Tille]

Hi Roland,

On Sat, May 17, 2014 at 04:52:22PM +0200, rf at q-leap.de wrote:
> 
> $ git clone https://alioth.debian.org/anonscm/git/debian-med/bambamc.git
> Cloning into 'bambamc'...

Comment (with no relation to the issue you are reporting):  I personally
made good experiences by using

   gbp-clone ssh://git.debian.org/git/debian-med/bambamc.git

Just a hint.

> $ cat bambamc_0.0.49.orig.tar.gz.id
> 42e2174057f8272780c3d112fb6933d1df9dde12
> $ git checkout 42e2174057f8272780c3d112fb6933d1df9dde12
> fatal: Cannot switch branch to a non-commit.

I can confirm this.
 
> The reason why this goes by unnoticed is, that git-build-package actually
> doesn't check the <pkg>_<upstream_version>.orig.tar.gz.id file where the
> commit id corresponding to the upstream tag of <upstream_version> should
> be stored. Rather it browses the commit log, looks for a commit message
> corresponding to the pristine tar commit and then explicitly creates the 
> the orig.tar.gz (see the verbose output below).
> 
> -----Output of git-buildpackage  --git-pristine-tar --git-verbose ------
> gbp:debug: ['git', 'log', '--pretty=format:%H', '--grep=pristine-tar .* bambamc_0.0.49\\.orig.tar\\.', 'pristine-tar', '--']                                          
> gbp:debug: Found pristine-tar commit at '974d7a19102e9845111ccfc0366495a44083fb9f'
> gbp:debug: ['git', 'log', '-n1', '--pretty=format:%s', '974d7a19102e9845111ccfc0366495a44083fb9f']                                                                    
> gbp:debug: Determined compression type 'gzip'
> gbp:debug: ['git', 'branch', '--no-color']
> gbp:debug: /usr/bin/pristine-tar [] ['checkout',
> '/archive/nfehren/pkg/upstream/debmed/bio-dev/bambamc/bambamc_0.0.49.orig.tar.gz']                                   
> -------------------------------------------------
> 
> Now the following questions arise (in general but explained using bambamc):
> - is <pkg>_<upstream_version>.orig.tar.gz.id ignored on purpose? If yes,
>   what's its use?

I have no idea.

> - What happened to the git repo that the commit id referenced in
>   bambamc_0.0.49.orig.tar.gz.id got lost?

I have no idea as well.  I'm just blindly following our team policy document
git hints and doing

   git import-orig --pristine-tar <tarball>

expecting it to work nicely (and never observed a problem in the
described workflow).

> - Shouldn't we fix bambamc_0.0.49.orig.tar.gz.id to contain the correct
>   commit $(git show-ref --tags -s upstream/0.0.49)

Well, I'm fine with anything that is fixing a potential issue (even if I
can not really see in what situation this could cause a problem).
 
> In my opinion <pkg>_<upstream_version>.orig.tar.gz.id should hold a
> valid git sha1 corresponding to the commit where the corresponding
> upstream source was imported. Only that way, the correspondence between
> the imported upstream source and the tar generated by pristine-tar
> checkout can be unambiguously established. Of course, you might argue
> that building the source package will fail if its not so, but I wouldn't
> consider that clean development ...

I'm fine with any enhancement that might make things cleaner.  However,
we should also document in our policy document what to do and how to
prevent this issue in the future.
 
> Maybe more recent versions of git-buildpackage work differently (didn't
> have the time to check), but I doubted since then somebody should have
> noticed the inconsistencies.

I never faced any trouble when using git-buildpackage which was caused
by the issue you are describing.

Kind regards

       Andreas. 

-- 
http://fam-tille.de