Re: Trying to run build time tests using nosetest for python-pysam
On Fri, Jul 17, 2015 at 07:48:20PM +0200, Andreas Tille wrote: In any case, I have reviewed the test logs again (from the working test-runner configuration). The only failure for the python-pysam package is the compile test-- which looks to be due to the multiarch issue you pointed out. The python3-pysam package has about 37 failures. Most of those look like problems with the python2-python3 transition. See also the upstream bug at https://github.com/pysam-developers/pysam/issues/141 OK, thanks for your research about this. IMHO we should try to run the tests also at package build time - but I'm lost and have no idea how to approach this. :-( I have now commited a rules file that runs Python 2 tests successfully - and IMHO only this is a proper fix for #763218. The latest upload with the new upstream version just left out the testing (which for sure can't fail). The errors on Python 3 are ignored for the moment but I wonder whether we could find some fixes for these as well. In any case I think we should try to bring back the separate tests package (whatever name it might get) and find a way to run the tests since IMHO this is the way to ensure that the modules are running properly. Any opinions? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150722203002.gv9...@an3as.eu
Re: Trying to run build time tests using nosetest for python-pysam
Hi, Andreas, On الأربعاء 22 تـمـوز 2015 13:30, Andreas Tille wrote: I have now commited a rules file that runs Python 2 tests successfully - and IMHO only this is a proper fix for #763218. The latest upload with the new upstream version just left out the testing (which for sure can't fail). Sorry about that. There was no build-time testing when I started working on the package and I didn't question why since it looked like the package had to be installed for testing to work (as was indicated by the comments in debian/rules). I thought that bug report was about the particular issues mentioned there that caused the tests to fail and believed those to be resolved by the latest upstream release. The errors on Python 3 are ignored for the moment but I wonder whether we could find some fixes for these as well. Maybe we should send the test log upstream to see if there is a solution available. In any case I think we should try to bring back the separate tests package (whatever name it might get) and find a way to run the tests since IMHO this is the way to ensure that the modules are running properly. Any opinions? The autopkgtests ran properly the way I had configured it (besides the problem with multiarch renaming). Do you mean to put back the configuration where the autopkgtest runner depends on a separate python-pysam-tests package? In order to upload soon, I suggest that we put back the tests package for the user, but keep autopkgtest independent of it in order to work with Debian CI. I think debugging the original configuration would push us over the autoremoval deadline. Let me know what you think. I have some time to work on the package this week. In fact, I spent some unsuccessful hours two days ago trying to get the build-time testing to work. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55b0475d.5000...@ghraoui.name
Re: Trying to run build time tests using nosetest for python-pysam
Hi Afif, On Wed, Jul 22, 2015 at 06:46:05PM -0700, Afif Elghraoui wrote: The errors on Python 3 are ignored for the moment but I wonder whether we could find some fixes for these as well. Maybe we should send the test log upstream to see if there is a solution available. Good idea. I had debugging switched on to support this. Do you have contact to upstream anyway and would take over this? In any case I think we should try to bring back the separate tests package (whatever name it might get) and find a way to run the tests since IMHO this is the way to ensure that the modules are running properly. Any opinions? The autopkgtests ran properly the way I had configured it (besides the problem with multiarch renaming). May be we ignore this multiarch thing for the moment and discuss it with Debian Python team while users (and dependencies) could at least profit from an updated python-pysam. Do you mean to put back the configuration where the autopkgtest runner depends on a separate python-pysam-tests package? In order to upload soon, I suggest that we put back the tests package for the user, but keep autopkgtest independent of it in order to work with Debian CI. Yes. Keeping the test package has the additional advantage that it does not need another passing the new queue. :-) I think debugging the original configuration would push us over the autoremoval deadline. Let me know what you think. I have some time to work on the package this week. In fact, I spent some unsuccessful hours two days ago trying to get the build-time testing to work. OK, since this is solved now I would be really happy if you could finalise it in the sense above. This leaves me time to help on the medical imaging side where also some autoremovals are pending. Kind regards Andreas. PS: Hope your DM application will be accepted soon. I just have sended my ACK. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150723045533.gc11...@an3as.eu
Re: Trying to run build time tests using nosetest for python-pysam
Hi Afif, On Thu, Jul 16, 2015 at 10:57:17PM -0700, Afif Elghraoui wrote: Hi, Andreas, On الأربعاء 15 تـمـوز 2015 05:21, Andreas Tille wrote: Hi, I tried to add build-time tests for python-pysam[1]. I admit I'm a bit confused about the fact that this involves compiler calls like: ... warning: no files found matching 'tests/tabix_data' writing manifest file 'pysam.egg-info/SOURCES.txt' skipping 'pysam/csamtools.c' Cython extension (up-to-date) building 'pysam.csamtools' extension x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 - fPIC -D_FILE_OFFSET_BITS=64 -D_USE_KNETFILE= -Isamtools -Ipysam -I/usr/include -I/usr/include/python2.7 -c pysam/csamtools.c -o build/temp.linux-x86_64-2.7/pysam/csamtools.o -Wno- error=declaration-after-statement -DSAMTOOLS=1 ... I think this is because of the test/compile_test.py, which is a test script for checking if compilation against pysam and tabix works according to the file header. OK, this seems to be some explanation. and that it finally ends with ... In file included from pysam/cfaidx.c:261:0: pysam/htslib_util.h:12:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes] int hts_get_verbosity(); ^ x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack- protector-strong -Wformat -Werror=format-security -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-2.7/pysam/cfaidx.o -Lpysam -lz -lhts -o build/lib.linux-x86_64-2.7/pysam/cfaidx.so -- Ran 0 tests in 0.010s OK (same result with python3). I wonder what I'm missing here and how the build time test could be properly runned. According to the README file in the tests directory, some of the tests require pysam to be in the PYTHONPATH. To the best of my knowledge this is rectified by the method I used to trigger the test. Could anybody from Python team confirm this? In any case, I have reviewed the test logs again (from the working test-runner configuration). The only failure for the python-pysam package is the compile test-- which looks to be due to the multiarch issue you pointed out. The python3-pysam package has about 37 failures. Most of those look like problems with the python2-python3 transition. See also the upstream bug at https://github.com/pysam-developers/pysam/issues/141 OK, thanks for your research about this. IMHO we should try to run the tests also at package build time - but I'm lost and have no idea how to approach this. :-( Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150717174820.gn13...@an3as.eu
Re: Trying to run build time tests using nosetest for python-pysam
Hi, Andreas, On الأربعاء 15 تـمـوز 2015 05:21, Andreas Tille wrote: Hi, I tried to add build-time tests for python-pysam[1]. I admit I'm a bit confused about the fact that this involves compiler calls like: ... warning: no files found matching 'tests/tabix_data' writing manifest file 'pysam.egg-info/SOURCES.txt' skipping 'pysam/csamtools.c' Cython extension (up-to-date) building 'pysam.csamtools' extension x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 - fPIC -D_FILE_OFFSET_BITS=64 -D_USE_KNETFILE= -Isamtools -Ipysam -I/usr/include -I/usr/include/python2.7 -c pysam/csamtools.c -o build/temp.linux-x86_64-2.7/pysam/csamtools.o -Wno- error=declaration-after-statement -DSAMTOOLS=1 ... I think this is because of the test/compile_test.py, which is a test script for checking if compilation against pysam and tabix works according to the file header. and that it finally ends with ... In file included from pysam/cfaidx.c:261:0: pysam/htslib_util.h:12:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes] int hts_get_verbosity(); ^ x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack- protector-strong -Wformat -Werror=format-security -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-2.7/pysam/cfaidx.o -Lpysam -lz -lhts -o build/lib.linux-x86_64-2.7/pysam/cfaidx.so -- Ran 0 tests in 0.010s OK (same result with python3). I wonder what I'm missing here and how the build time test could be properly runned. According to the README file in the tests directory, some of the tests require pysam to be in the PYTHONPATH. In any case, I have reviewed the test logs again (from the working test-runner configuration). The only failure for the python-pysam package is the compile test-- which looks to be due to the multiarch issue you pointed out. The python3-pysam package has about 37 failures. Most of those look like problems with the python2-python3 transition. See also the upstream bug at https://github.com/pysam-developers/pysam/issues/141 regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a8993d.1070...@ghraoui.name
