Re: I would like to submit a package to debian-med

Hey Andreas,

On Tue, Jan 7, 2014 at 11:34 AM, Andreas Tille <andreas@an3as.eu> 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