Hi Andreas, On Mon, Jan 6, 2014 at 3:37 PM, Andreas Tille <[email protected]> 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 <[email protected]> > > 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
