3Depict : upload request, bug #876620

[D Haley]

Hi Sebastien,

I rolled back history, and had to manually ssh in and hand edit the git
repository on the remote, as pushing with --force is denied by the remote.
[remote rejected] master->master (non fast-forward)

I'm unable to get gbp to generate a byte-for-byte identical tarball,
even if the contents are byte-for-byte identical when unpacked. I'm at a
loss for what to do, as cloning the current repository

$ gbp import-orig  --pristine-tar ../3depict_0.0.20.orig.tar.gz
What is the usptream version? [0.0.20]
...
gbp:info Successfully imported version 0.0.20 of
../3depict_0.0.20.orig.tar.gz

$ mv 3depict_0.0.20.orig.tar.gz 3depict_0.0.20.orig.tar.gz.real

$ gbp buildpackage -S
...
Ctrl+C

$sha1sum *gz*
<completely different SHA1 sums>

This must be a bug in gbp (seems unlikely, but I can find no other
explanation??), as it is not doing what it says it should? It claims it
has successfully imported it (and yes it creates a new tag). There is no
debian/ directory present (which AFAIK is correct).

I've refrained from pushing this changeset, as I don't want to have to
redo the remote history edit, for fear of breaking something.

I'm really at a loss as to what to do - there are too many constraints I
cannot satisfy simultaneously. This is either a problem with the tools
or with my understanding of them - they do not appear to do the job they
claim. I'm quite frustrated and have spent far too much time on this - I
don't know what to do.

Thanks, and apologies for taking up your time.

On 27/09/17 13:13, Sébastien Villemot wrote:
> On Wed, Sep 27, 2017 at 01:10:16AM +0100, D Haley wrote:
>> Dear Sébastien,
>>
>> I have corrected d/control & d/copyright, as well as updating to compat
>> 10. This has been pushed as f513233d7. gbp import-orig --pristine-tar
>> has been used to import the upstream tarball, and have also been pushed.
> 
> Thanks. However something is wrong with the upstream branch: it includes a
> debian/ subdirectory.
> 
> Please fix the upstream branch (possibly by writing history): it should contain
> exactly the files included in upstream tarball. Don't forget to update the
> pristine-tar branch accordingly as needed. One should be able to recreate from
> the git a tarball byte-to-byte identical to the upstream tarball. You can check
> that it works correctly by moving away your local copy of upstream tarball,
> running "gbp buildpackage -S", and verify that the tarball it created is the
> same as upstream tarball.
> 
> Also please document all your changes in debian/changelog (at least adding the
> bump to debhelper compat 10).
> 
>> A quick question : Unless I'm mistaken, it seems that VCS-Git and
>> VCS-Browser are the same (and this is reflected in debian-science
>> policy). Is there a link to explain why we are duplicate this, so I can
>> understand this a bit better? I'm assuming its to do with enforcing
>> https transport?
> 
> The two URLs are not exactly the same. Vcs-Browser has /cgit/ while Vcs-Git has
> /git/.
> 
> Note that the Vcs-Git URL in your debian/control file is wrong, you should
> replace /cgit/ by /git/.
> 
> The Debian Science policy is also outdated on this issue, we should fix it.
> 
> Thanks,
>