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

Hi Andreas,

On Tue, Jan 7, 2014 at 2:08 PM, Andreas Tille <andreas@an3as.eu> wrote:

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.

Done.

> 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 had created the pristine tarball with:

uscan --force-download

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.

I had not realised that gbp would create the pristine tarball on it's own.

I start to like gbp. :)

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.

One of the first bugs pointed out by lintian:

$ lintian -i snp-sites_1.0-1_amd64.changes
W: snp-sites source: package-needs-versioned-debhelper-build-depends 9
N:
N:    The package either doesn't declare a versioned build dependency on
N:    debhelper or does not declare a versioned build dependency on a new
N:    enough version of debhelper to satisfy the declared compatibility level.
N:
N:    The required version of debhelper is not guaranteed to be satisfied in
N:    all supported releases of Debian and therefore this may lead to a build
N:    failure.
N:
N:    Recommended practice is to always declare an explicit versioned
N:    dependency on debhelper equal to or greater than the compatibility level
N:    used by the package, even if the versioned dependency isn't strictly
N:    necessary. Having a versioned dependency also helps with backports to
N:    older releases and correct builds on partially updated systems.
N:
N:    Note if you are using a compat level, which is marked as experimental,
N:    such as compat 9 in debhelper 8.1.3, then please override this tag.
N:
N:    Refer to the debhelper(7) manual page for details.
N:
N:    Severity: minor, Certainty: certain
N:
N:    Check: debhelper, Type: source
N:

Because I am using compat level 9 I guess I can override this flag?

Also, this one has been worrying me for quite sometime:

W: libsnp-sites1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libsnp-sites.so.1.0.0 usr/lib/x86_64-linux-gnu/libsnp-sites.so
N:
N:    Although this package is not a "-dev" package, it installs a
N:    "libsomething.so" symbolic link referencing the corresponding shared
N:    library. When the link doesn't include the version number, it is used by
N:    the linker when other programs are built against this shared library.
N:
N:    Shared libraries are supposed to place such symbolic links in their
N:    respective "-dev" packages, so it is a bug to include it with the main
N:    library package.
N:
N:    However, if this is a small package which includes the runtime and the
N:    development libraries, this is not a bug. In the latter case, please
N:    override this warning.
N:
N:    Refer to Debian Policy Manual section 8.4 (Development files) for
N:    details.
N:
N:    Severity: normal, Certainty: possible
N:
N:    Check: shared-libs, Type: binary, udeb
N:

I'm not yet sure how to fix it, but I'll see what I can do.

Regards,

Jorge