Re: Git repository of htslib is lacking pristine-tar
Le Tue, Jul 28, 2015 at 12:19:10PM +0200, Andreas Tille a écrit :
>
> $ gbp clone ssh://git.debian.org/git/debian-med/htslib.git
> $ cd htslib
> $ gbp buildpackage
> gbp:info: Orig tarball 'htslib_1.2.1.orig.tar.gz' not found at '../tarballs/'
> gbp:error: Pristine-tar couldn't checkout "htslib_1.2.1.orig.tar.gz": fatal: Path 'htslib_1.2.1.orig.tar.gz.delta' does not exist in 'refs/heads/pristine-tar'
> pristine-tar: git show refs/heads/pristine-tar:htslib_1.2.1.orig.tar.gz.delta failed
>
> I tried:
>
> $ pristine-tar commit ../htslib_1.2.1.orig.tar.gz v1.2.1
> pristine-tar: failed to find ref using: git show-ref v1.2.1
>
> which I took from bedtools debian/README.source. It seems that the 'v'
> in front of the version number in the end needs to be left our here. I
> commited an according README.source
Hi Andreas,
indeed, "pristine-tar commit" takes a tarball and a git tag as arguments, and
the htslib upstream authors tag their releases with plain version numbers,
without "v" on front.
For htslib, I am sorry that I did not run "pristine-tar commit" well. I should
have used the following command:
pristine-tar commit /tmp/htslib_1.2.1.orig.tar.gz 1.2.1
instead, I used:
pristine-tar commit /tmp/htslib-1.2.1.tar.gz 1.2.1
As a result, git-buildpackage did not manage to find the pristine-tar information.
htslib-1.2.1.tar.gz is the name of the file downloaded by uscan
(htslib_1.2.1.orig.tar.gz) is a symlink, and I picked it up by mistake. Sorry
again for this. Fortunately, the instructions that we discussed on this
list and that you used as README.source are correct about which file name to use.
In any case, please note that uscan or apt-get source can also provide you with
an upstream tarball if you are connected to Internet. Since it regularly
happens that people mess up with the pristine-tar branch (for example by
forgetting to push it), this is an important workaround to remember.
> I admit I'm not yet convinced that the chance to enable upstream pull
> requests are worth the drawback that other team members have trouble
> to follow an undocumented workflow.
It is not just about pull requests, it is about working with the same Git
history as Upstream. When building fails, I find this property to be
very important.
I do not want to be a blocker, but on packages like htslib, I do not want to
work with the pristine tarball workflow. Given that I am obviouly unable to
follow your pace, I will understand if you remove my name from the Uploaders
field and go ahead without me. But if you do that for all my packages,
maybe you will have too much work as well ... so we must compromise :)
I think that the main problem is that I did not manage to document the workflow
on time before reducing my activity. Otherwise, I think that it works fine.
Nevertheless, there may be changes in the future, for instance to harmonise
with DEP 14.
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: