Hello! Thanks for your replies. So some good news and an issue. I have worked hard to get autpkgtest, hence I have now used the pre-existing testing scripts to use by creating a patch to make it utilise the system-wide mindthegap installation instead of it expecting a local binary. The pre-existing test scripts also use exit flags / status which makes it easier as I don't need to re-write it. The result I now get is as follows, which looks good:
autopkgtest [05:44:25]: test run-unit-test: [----------------------- Invoking simple_test.sh: clean-insert : passed 13-inserts-ref10k : passed 1-SNP : passed 3-SNP*2 : passed snp-before-clean-insert : passed hetero-insert : passed deletion : passed fuzzy-deletion : passed n-in-solid-stretch : passed n-in-before-clean-insert : passed n-after-clean-insert : passed Invoking simple_full_test.sh: full-test find vcf : PASS full-test find breakpoints : PASS full-test fill fasta : PASS full-test fill vcf : PASS contig-test fill fasta : PASS contig-test fill gfa : PASS autopkgtest [05:44:36]: test run-unit-test: -----------------------] autopkgtest [05:44:36]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-test PASS autopkgtest [05:44:36]: @@@@@@@@@@@@@@@@@@@@ summary run-unit-test PASS Now I have corrected the lintian issues, and testing it on my system, the paths are available at either /usr/share/doc/mindthegap or /usr/share/mindthegap depending on what static file it is respectively. I am now left with the following linthian output: I: mindthegap: spelling-error-in-binary usr/bin/MindTheGap writting writing I: mindthegap: hardening-no-bindnow usr/bin/MindTheGap W: mindthegap: new-package-should-close-itp-bug I: mindthegap: description-synopsis-might-not-be-phrased-properly "Performs detection and assembly of DNA insertion variants in NGS read datasets." I: mindthegap: extra-license-file usr/share/doc/mindthegap/LICENSE.gz I: mindthegap: package-contains-documentation-outside-usr-share-doc usr/share/mindthegap/scripts/jenkins/README I: mindthegap: package-contains-documentation-outside-usr-share-doc usr/share/mindthegap/test/contig_test/README I: mindthegap: package-contains-documentation-outside-usr-share-doc usr/share/mindthegap/test/full_test/README E: mindthegap: python-script-but-no-python-dep usr/share/mindthegap/test/scripts/generate_read.py #!python E: mindthegap: python-script-but-no-python-dep usr/share/mindthegap/test/scripts/make_deletions.py #!python E: mindthegap: python-script-but-no-python-dep usr/share/mindthegap/test/scripts/make_snp_deletions.py #!python E: mindthegap: python-script-but-no-python-dep ... use --no-tag-display-limit to see all (or pipe to a file/program) My question is: should I include python as a dependency seeing as linthian is complaining? I initially didn't want to add it as these python files are never used within my autopkgtest, nor do I see why an end user would use these so I thought adding python as a dep would be a dep too many and useless? Please correct me if I should. Now the issue. With my latest commit, it seems like (I really don't know why this happened, I am really certain I popped quilt patches) the files within test and CMakeLists was re-written and is different to what the upstream is. The package building and tests are still successful, but I shouldn't have re-written over these and I am positive I popped them, unless I was really acting stupid at the time and forgot to pop everything. Trying quilt pop -f (-f as these changes are too vast and quilt complains), I cannot package build as it complains I need to dpkg-source --commit(?) first. Doing this will revert back to the initial issue I had with CMake not finding gatb-core even though the patches are still untouched within debian/patches. It's a bit of a headache, as I don't know how to fix this at all. I am also not sure how to revert these commits (if I need to) as all of my autopkgtest changes would get resrt? Hopefully I'm not *too* much of an inconvenience and many thanks :), Shayan Doust July 8, 2019 2:51 PM, "Andreas Tille" <[email protected]> wrote: > Hi, > > On Mon, Jul 08, 2019 at 01:59:23PM +0300, [email protected] wrote: > >> @Shayan: I don't have a reference to cite about the severity of lintian >> errors/warnings/..., but I feel errors and warnings must be dealt with. >> Let us know should you need any help with these. > > My *personal* policy is: > > - Errors need to be fixed. > - I try really hard to fix all warnings (but sometimes I fail) > - I try to fix lintian info. Example: I fix spelling mistakes if > I can expect that upstream will accept a patch or if upstream is > dead and Debian is basically upstream. However, if the development > is a moving target but not very probable that upstream will care > about a spelling patch I leave this untouched. > - I don't care about pedantic lintian issues. > > Here is my ~/.lintianrc > > color=always > display-experimental=no > display-info=yes > pedantic=no > > which reflects what I'm caring about and what I'm ignoring. > >> On 2019-07-08 09:46, Andreas Tille wrote: >> @Andrius: Its fun to work with you as co-mentor. A lot less work >> for me! >> >> @Andreas: Same fun here to get my methods reviewed :) > > :-) > > Kind regards > > Andreas. > > -- > http://fam-tille.de
