Re: I would like to submit a package to debian-med
Hi Jorge,
On Tue, Jan 07, 2014 at 01:28:06PM +0000, Jorge Sebastião Soares wrote:
> >> $ 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.
> >
> I've done all of this.
Cool. I can now reproduce the creation of the original source tarball
snp-sites_1.0.orig.tar.gz which helps me to verify your steps.
> Before I could import the pristine tar I had to:
>
> git branch upstream
I can confirm this - usually this should be done by pristine tar
automatically (there was no need for this in other cases before) but once
you do this the import works nicely.
> Then I was able to import the original tar ball that was created with uscan.
I then copied over your old debian/ dir and also adapted the version
number since it was only 1 before but now we need 1.0. Feel free to
gbp-pull
since I commited this status now to git.debian.org.
> Running git-buildpackage I get this:
>
> js21@builder:~/clean_build/snp_sites$ git-buildpackage --git-ignore-new
> dh clean --with autoreconf
> dh_testdir
> dh_auto_clean
> dh_autoreconf_clean
> dh_clean
> fatal: Not a valid object name upstream/1
I have never seen this and even if I have a vague guess that it might
have something to do with leaving only "1" as upstream version number in
the debian/changelog the build should not have proceeded up to this point
since it should not have found a matching source tarball (or it grabs
it from your local disk somewhere??).
> I can't seem to find where the problem lies.
>
> Have you come across this before?
I'd recommend to fetch the current status at git.debian.org (best via
gbp-pull
since this also fetches upstream and pristine-tar branch automatically!)
and try git-buildpackage again.
This should build at your site. If it does we can now start working down
the lintian issues. You could try:
lintian -i -I snp-sites_1.0-1_amd64.changes
to review these. Some of them might be (hopefully) self explanatory.
One hint for a typically hard to detect one is
W: snp-sites source: source-nmu-has-incorrect-version-number 1.0-1
Lintian assumes a NMU (Non-maintainer upload) since you have specified
different e-mail addresses in debian/control Uploaders field and in
changelog. I'd recommend using
dch
for creating changelog entries which grabs you favourite maintainer
address from the environment (see `man dch`) and use this address also
in debian/control.
If you have further questions to other lintian issues feel free to ask.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: