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, > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
