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

Re: Exonerate Test Failures



Hi, Canberk and all!

2016-05-24 2:57 GMT+03:00 Canberk Koç <canberkkoc@gmail.com>:
Hello everyone,

I use adt-run to my autopkgtest on exonerate and examine the outputs.
 I saw some failures but test run and give pass results. 
I decide to look their test files and saw they look for missing files error not occur but failure output comes from main test file.
 I take output for you i cannot understand what is wrong. Thanks for your help already.

tmp/autopkgtest.BK2zJD/adttmp/util/fastaremove.test.sh
Have calmodulin in input
** FATAL ERROR **: Could not open list for removal [CALM_HUMAN]
exiting ...
Calmodulin successfully removed

$FASTAREMOVE $INPUTFILE CALM_HUMAN > $OUTPUTFILE 
//UPPER FAİL COMES FROM HERE BUT FUNCTİON WORK AND DELETE FİLES
It seems that here http://anonscm.debian.org/cgit/debian-med/exonerate.git/tree/src/util/fastaremove.c#n76
code expects to get file name as a second argument, but this test
http://anonscm.debian.org/cgit/debian-med/exonerate.git/tree/test/util/fastaremove.test.sh#n27
shows that it expects to remove description string from fasta file, and this string gets interpreted as 'stdin' or file name, containing  one of several fasta records with given descriptions to remove.
/tmp/autopkgtest.BK2zJD/adttmp/util/fastaindex.fastafetch.test.sh
Made index fastafetch.test.idx
/usr/bin/fastafetch fastafetch.test.fasta fastafetch.test.idx CALM_HUMAN
expect 0
>CALM_HUMAN
MADQLTEEQIAEFKEAFSLFDKDGDGTITTKELGTVMRSLGQNPTEAELQDMINEVDADGNGTIDFPEFL
TMMARKMKDTDSEEEIREAFRVFDKDGNGYISAAELRHVMTNLGEKLTDEEVDEMIREADIDGDGQVNYE
EFVQMMTAK
/usr/bin/fastafetch fastafetch.test.fasta fastafetch.test.idx P53_HUMAN
expect 0
>P53_HUMAN
MEEPQSDPSVEPPLSQETFSDLWKLLPENNVLSPLPSQAMDDLMLSPDDIEQWFTEDPGPDEAPRMPEAA
PPVAPAPAAPTPAAPAPAPSWPLSSSVPSQKTYQGSYGFRLGFLHSGTAKSVTCTYSPALNKMFCQLAKT
CPVQLWVDSTPPPGTRVRAMAIYKQSQHMTEVVRRCPHHERCSDSDGLAPPQHLIRVEGNLRVEYLDDRN
TFRHSVVVPYEPPEVGSDCTTIHYNYMCNSSCMGGMNRRPILTIITLEDSSGNLLGRNSFEVHVCACPGR
DRRTEEENLRKKGEPHHELPPGSTKRALPNNTSSSPQPKKKPLDGEYFTLQIRGRERFEMFRELNEALEL
KDAQAGKEPGGSRAHSSHLKSKKGQSTSRHKKLMFKTEGPDSD
/usr/bin/fastafetch fastafetch.test.fasta fastafetch.test.idx A_MISSING_FROM_START
expect 1
** FATAL ERROR **: Could not find identifier [A_MISSING_FROM_START] (missing -F ?)
exiting ...
/usr/bin/fastafetch fastafetch.test.fasta fastafetch.test.idx M_MISSING_FROM_MIDDLE
expect 1
** FATAL ERROR **: Could not find identifier [M_MISSING_FROM_MIDDLE] (missing -F ?)
exiting ...
/usr/bin/fastafetch fastafetch.test.fasta fastafetch.test.idx z_MISSING_FROM_END
expect 1
** FATAL ERROR **: Could not find identifier [z_MISSING_FROM_END] (missing -F ?)
exiting ...
fastaindex fastafetch test OK
For now I saw this:
http://anonscm.debian.org/cgit/debian-med/exonerate.git/tree/src/util/fastafetch.c#n95 - error message appeared here, because
`fasta_index_lookup` call returns -1. It seems that index file, created by call here: 
http://anonscm.debian.org/cgit/debian-med/exonerate.git/tree/test/util/fastaindex.fastafetch.test.sh#n15
doesn't contain descriptions
A_MISSING_FROM_START, M_MISSING_FROM_MIDDLE, z_MISSING_FROM_END.
Previous lines (before errors) in this output shows that it contains sequences with descriptions
P53_HUMAN, CALM_HUMAN. Second argument in run_fastafetch is an integer value, indicating fastafetch.c main function return code.
It is expected to be equal 1, something went wrong and error message is returned instead.

I would suggest to add (in local code) "echo $RESULT" line before this line:

http://anonscm.debian.org/cgit/debian-med/exonerate.git/tree/test/util/fastaindex.fastafetch.test.sh#n38
and look what it prints to output (and why it is not 1) and when to decide how to fix these errors. 
# look for IDs which are missing 
run_fastafetch A_MISSING_FROM_START 1
run_fastafetch M_MISSING_FROM_MIDDLE 1
run_fastafetch z_MISSING_FROM_END 1
// UPPER FAİLS COMES FROM HERE BUT FETCHİNG WORKS 

Best Regards
--
 
Hope this helps.
Please, somebody correct me if my interpretation is wrong.


--
Best wishes,
Tanya.

Reply to: