[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Packaging mindthegap (Was: [MoM] Packaging mindthemap)



Hello, 

All received and acknowledged. Thanks for your time! 

Shayan Doust

July 10, 2019 7:04 AM, "Andreas Tille" <andreas@an3as.eu> wrote:

> Hi,
> 
> I pushed some other minor changes
> 
> Secure URI in watch file:
> Very simple - may be caused due to wrong initial advise of mine
> 
> Convert remaining Python2 script:
> I missed that yesterday in my 2to3 conversion
> 
> Just keep on asking if you need more advise for the remaining lintian
> issues or the package split.
> 
> Kind regards
> 
> Andreas.
> 
> On Tue, Jul 09, 2019 at 05:11:03PM +0200, Andreas Tille wrote:
> 
>> 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
> 
> --
> http://fam-tille.de


Reply to: