Re: [MoM] Packaging mindthegap (Was: [MoM] Packaging mindthemap)
Hi,
our mails crossed. Please read the mail I wrote after building
the package. I think it answers most of the questions. The one
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
Could be answerd by: Just move these dirs to
usr/share/doc/mindthegap
Finally these data are not needed to run the package and are basically
documentation for the user.
I hope everything else is answered by my other mail.
Thanks a lot for your work on this and making that fast progress
Andreas.
On Tue, Jul 09, 2019 at 02:50:06PM +0000, hello@shayandoust.me wrote:
> 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=0Re: 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" <andreas@an3as.eu> wrote:
>
> > Hi,
> >
> > On Mon, Jul 08, 2019 at 01:59:23PM +0300, merkys@debian.org 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
>
>
--
http://fam-tille.de
Reply to: