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

Hi Andreas,

On Mon, Jan 6, 2014 at 3:37 PM, Andreas Tille <andreas@an3as.eu> wrote:

Hi Jorge,

please stick to open discussion on Debian Med list. I guess you will
not mind if I full quote your prer-technical, non-personal mail.

No problem.

Gmail defaults to reply instead of reply all...

On Mon, Jan 06, 2014 at 11:48:21AM +0000, Jorge Sebastião Soares wrote:
> > I checked the Git repository and for some strange reason the build
> > totally fails because of removed files from upstream source. What
> > happens on your side when you do some
> >
> > git-buildpackage
> >
> > ?
> >
> >
> When I run git-buildpackage I get this:
>
> js21@builder:~/build/snp-sites_1$ git-buildpackage --git-ignore-new
> dh clean --with autoreconf
> dh_testdir
> dh_auto_clean
> dh_autoreconf_clean
> dh_clean
> dpkg-buildpackage -rfakeroot -D -us -uc -i -I
> dpkg-buildpackage: source package snp-sites
> dpkg-buildpackage: source version 1-1
> dpkg-buildpackage: source changed by Jorge Soares <js21@sanger.ac.uk>
> dpkg-source -i -I --before-build snp-sites_1
> dpkg-buildpackage: host architecture amd64
> dpkg-checkbuilddeps: Unmet build dependencies: docbook
> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied;
> aborting
> dpkg-buildpackage: warning: (Use -d flag to override.)
> debuild: fatal error at line 1357:
> dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
> gbp:error: Couldn't run 'debuild -i -I': debuild -i -I returned 29

Hmmm, this is just an unmet build depends which is strange since
it should not be needed for the clean target.

I have managed to build the package with:

git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid --git-ignore-new

On my side I get

...
dh_clean
dpkg-source -i.git -I.git -b snp-sites-1
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building snp-sites using existing ./snp-sites_1.orig.tar.gz
dpkg-source: warning: ignoring deletion of file Makefile.in
dpkg-source: warning: ignoring deletion of file ltmain.sh
dpkg-source: warning: ignoring deletion of file install-sh
...
dpkg-source: warning: ignoring deletion of file autom4te.cache/output.0
dpkg-source: warning: file snp-sites-1/src/Makefile.am has no final newline (either original or modified version)
dpkg-source: warning: file snp-sites-1/src/Makefile.am has no final newline (either original or modified version)
dpkg-source: warning: file snp-sites-1/src/vcf.h has no final newline (either original or modified version)
dpkg-source: info: local changes detected, the modified files are:
snp-sites-1/LICENSE
snp-sites-1/Makefile.am
snp-sites-1/configure.ac
snp-sites-1/snp-sites.txt
snp-sites-1/src/Makefile.am
...
snp-sites-1/tests/helper-methods.c
snp-sites-1/tests/helper-methods.h
snp-sites-1/tests/run-all-tests.c
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/snp-sites_1-1.diff.R6uDKg
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -i.git -I.git -b snp-sites-1 gave error exit status 2
gbp:error: Couldn't run '~/bin/git-pbuilder': ~/bin/git-pbuilder returned 2

It seems the clean target is totally broken or the upstream tarball is
somehow wrong. I never have faced such a problem before.

What happens if you rename the original tarball to:

snp-sites_1?

> > Also when I try a plain pdebuild the process ends in
> >
> > ...
> > dh_install
> > cp: cannot stat 'debian/tmp/usr/bin/snp-sites': No such file or directory
> > dh_install: cp -a debian/tmp/usr/bin/snp-sites debian/snp-sites//usr/bin/
> > returned exit code 1
> >
> >
> This is odd.
> I have been running pbuilder this way:
>
> pdebuild --architecture amd64 --buildresult /home/js21/build_result
> --pbuilderroot "sudo DIST=unstable ARCH=amd64"
>
> And it finishes no problem.

This also results in problems for me (well, I just use plain pdebuild
and have set the variables in ~/.pbuilderrc as suggested in Debian Med
policy. It also shows something very similar to git-buildpackage with
in the end:

...
snp-sites_nogit/tests/check-snp-sites.h
snp-sites_nogit/tests/helper-methods.c
snp-sites_nogit/tests/helper-methods.h
snp-sites_nogit/tests/run-all-tests.c
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/snp-sites_1-1.diff.dmnSDi
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -i.svn -I.svn -b snp-sites_nogit gave error exit status 2

So it seems that the upstream tarball is definitely not what pdebuild or git-buildpackage are expecting.

> > It would help if you could
> > explain how you created the snp-sites_1.orig.tar.gz tarball which
> > is not really available from the upstream site.
> >
> >
> I simply get a fresh git checkout of the snp_sites git project.
> Next I rename the snp_sites directory to snp-sites_1.
> Then I simply
>
> tar cvzf snp-sites_1.orig.tar.gz snp-sites_1
>
> Is this a wrong way to do it?

I think so. You should not simply invent a version number if upstream
does not provide versioned tarballs. You should ask upstream for doing
proper tags for a release since we can not be sure that if upstream does
some changes before a final 1 (or 1.0??) release we will have identical
tarballs when doing a later checkout.

I'm not exactly inventing, but I get your point.
At this point, version 1 is the only public version.
I'll see what I can do to properly tag the snp-sites code.

> Also, should I add the debian folder to the upstream git project?

Oh nooooooo. ;-)
We are *really* happy that there is no such debian/ dir since in the
past we had to deal with wrong / broken / outdated packaging stuff in
such dirs and we regularly advise upstream to delete this if possible.

Sounds sensible. I just had to ask. :)

> If not I need to run git-buildpackage --git-ignore-new in order for it to
> ignore the debian folder.

I somehow have the feeling that it might be a good idea to drop the
snp-sites repository on alioth and recreate it from scratch since the
repository is broken and does not reflect at all what is inside the
upstream tarball.

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?

Kind reagrds,

Jorge