Hey Andreas,
On Tue, Jan 7, 2014 at 11:34 AM, Andreas Tille <[email protected]> wrote: > > If you write to Debian mailing lists people will even tell you that you > should only reply to the list and not to the poster. For sure we are > tolerant to newbies ... but in principle I do not need another copy of a > mail in my inbox. :-) > Fair enough. This is what I should have done in the first place. Sorted now. > > > I have managed to build the package with: > > > > git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid > > --git-ignore-new > > BTW, there is no need to explicit these options since all except the > last one are default and the last one is redundant for a fresh pull > without changes. > Cool. There's a lot to read and lots of tools for the same sort of purpose. I'm getting to grips with it... > > > What happens if you rename the original tarball to: > > > > snp-sites_1? > > You mean to rename the directory, not the tarball, right? > Dpkg-buildsource is clever enough to deal with this automatically. The > point is that the files are *really* missing in the master branch while > they are inside upstream branch. You should not change the upstream > files in the master branch but just add the debian/ dir. Somehow the > repository is mixed up - and I really have no idea why it would build at > your side. What happens if you clone from scratch and try > git-buildpackage? > I have not tried this. I will try it now and report back. Just to be clear, cloning from scratch from the git snp_sites project, not from the debian git project, right? > > > So it seems that the upstream tarball is definitely not what pdebuild or > > git-buildpackage are expecting. > > It is rather that the *content* of the directory is different from the > tarball and this is hat the build log is telling you. > I understand. > > > > > I'm not exactly inventing, but I get your point. > > Yes - I wrote "inventing" because your internal knowledge is in advance > to what outsiders can really see. > Sure. :) > > > At this point, version 1 is the only public version. > > I'll see what I can do to properly tag the snp-sites code. > > Just advise (or if you have commit permission to upstream do it yourself) > to tag the upstream repository with `git tag 1` (or `git tag 1.0` which > would be more convinient tagging). > I will do this now. I do have commit permission. > > > I have dropped the git project entirely and have recreated it. > > So, can you tell me... > > If I'd tag the snp-sites project with version 1.0, would the tag be > > appended to the package name? And would it conform to the Debian > standard? > > If I were you I would wait until upstream is tagged properly. Once this > is done do > > > $ uscan --verbose --report > -- Scanning for watchfiles in . > -- Found watchfile in ./debian > -- In debian/watch, processing watchfile line: > https://github.com/sanger-pathogens/snp_sites/tags > /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz > -- Found the following matching hrefs: > /sanger-pathogens/snp_sites/archive/0.1.tar.gz > Newest version on remote site is 0.1, local version is 1 > => remote site does not even have current version > -- Scan finished > > If this is reporting 1 (or 1.0) you can do `uscan --force-download` > which creates a valid and properly named tarball. Once you have this > tarball you can import it using > > git import-orig --pristine-tar > > as it is written in our policy document and later simply add the debian/ > dir. This workflow usually leads to a properly buildable repository. > Brilliant! Thanks Andreas. I will do this now. Kind regards, Jorge
