Does bwa really need to be limited to amd64?
Hi, all, As I've mentioned before, I'm trying to get circlator into testing. I requested of the release team to allow it to migrate despite it's being uninstallable on i386 [1]. I was then asked if there was any way to fix that, so I looked into the problematic dependencies. bwa is set to amd64 and kfreebsd-amd64 only. When I looked through the changelog, this looked like it was done a few years ago because of the need for SSE2. In the current debian/rules, I see that SSE2 is only added if the architecture matches amd64, but I don't see anything about this in the upstream Makefile or READMEs. I don't have a chance to test out a build right now, but does anyone see a problem with expanding the architecture list? Thanks and regards Afif 1. https://lists.debian.org/debian-release/2016/04/msg00198.html -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Does bwa really need to be limited to amd64?
Le Fri, Apr 08, 2016 at 01:04:15AM -0700, Afif Elghraoui a écrit : > > As I've mentioned before, I'm trying to get circlator into testing. I > requested of the release team to allow it to migrate despite it's being > uninstallable on i386 [1]. I was then asked if there was any way to fix > that, so I looked into the problematic dependencies. bwa is set to amd64 > and kfreebsd-amd64 only. > > When I looked through the changelog, this looked like it was done a few > years ago because of the need for SSE2. In the current debian/rules, I > see that SSE2 is only added if the architecture matches amd64, but I > don't see anything about this in the upstream Makefile or READMEs. > > I don't have a chance to test out a build right now, but does anyone see > a problem with expanding the architecture list? Hi Afif, BWA failed to build on i386 at version 0.7.5a-1 with the following error, despite the -D_NO_SSE2 option: /usr/lib/gcc/i486-linux-gnu/4.7/include/emmintrin.h:32:3: error: #error "SSE2 instruction set not enabled" https://buildd.debian.org/status/fetch.php?pkg=bwa&arch=i386&ver=0.7.5a-1&stamp=1370353173 I expect that if you try to build it on i386, it will fail again. In any case, for most bioinformatics software that is now developed on amd64, I would not trust output of the programs built successfully on other architectures unless there are good regression tests. So I take the opportunity to say a big thank you to the people working on regression tests right now :) Have a nice day, -- Charles
Re: Bug#820062: orthanc and orthanc-doc: error when trying to install together
Hi Sébastien, [moving back to list to get the testing issue recorded ...] On Fri, Apr 08, 2016 at 02:00:23PM +0200, Sébastien Jodogne wrote: > > > Great! The option "-A" was exactly what I was not able to find by myself. > > > > ... but this should work now. :-) > > :) > > Indeed, I am currently running all my integration tests to be sure that > everything is OK. Hmmm, why not adding these tests as autopkgtest? > I will send a separate acknowledgment once the tests are finished... I am > extremely grateful for your help! You are welcome. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#820062: orthanc and orthanc-doc: error when trying to install together
> > Indeed, I am currently running all my integration tests to be sure that > > everything is OK. > > Hmmm, why not adding these tests as autopkgtest? Actually, running these integration tests requires a network connection and a Docker infrastructure. They are much more involved than the unit tests (the latter being called as a part of the Debian build). I also carry on some manual tests to be sure everything is contained in the proper DEB package. Anyway, for those interested, the integration tests of Orthanc are publicly available in the following repository: https://bitbucket.org/sjodogne/orthanc-tests/ Sébastien-
Re: Bug#820062: orthanc and orthanc-doc: error when trying to install together
On Fri, Apr 08, 2016 at 02:35:35PM +0200, Sébastien Jodogne wrote: > > > Indeed, I am currently running all my integration tests to be sure that > > > everything is OK. > > > > Hmmm, why not adding these tests as autopkgtest? > > Actually, running these integration tests requires a network connection and a > Docker infrastructure. They are much more involved than the unit tests (the > latter being called as a part of the Debian build). I also carry on some > manual tests to be sure everything is contained in the proper DEB package. OK, but you could use the same tests as in the Debian build also as autopkgtest, right? Kind regards Andreas. -- http://fam-tille.de
Re: Packaging parsnp and harvest-tools for Debian
Hi Todd, On Fri, Apr 08, 2016 at 07:11:28AM -0400, Todd Treangen wrote: > > >We intend to package parsnp[1] and when downloading the archive from > >Github[2] I realised that it contains some binaries we need to replace > >by Debian packaged binaries built from the according sources to enable a > >distribution in main Debian. > > fantastic! one question I have; I'm working on a new release that > addresses a few important issues and will add a couple of new > features. I'm not sure on the timing of this, but hope to get it out > soon. If this is after it is integrated into Debian, how difficult is > it to replace/update to the latest version? Once a package made it into Debian its in most cases a matter of 15-30min work to get the update prepared. So in our specific case it makes sense to package the current version (with the initial packaging work on my side + waiting for the initial acceptance on the Debian mirror) and upgrade once you have released the new version. > >However, when calling bin/harvest_linux and the result from packaging > >the output is different: > > harvesttools is the correct one to use; harvest_linux can we replaced > with a build of harvesttools source OK. > >Moreover I wonder where I can find the source for bin/Profile > > agreed, the name is quite generic; no problem to rename if necessary. It would be great if you would come up with a renaing suggestion to make sure we do not invent some name you don't like. > http://www.maths.otago.ac.nz/~dbryant/software/PhiPack.tar Is there any *versioned* tarball and some kind of web page that could be considered a "homepage" which we usually add to our metadata? > >Finally you are shipping a copy of libMUSCLE[5] which has three changes > >applied > > yes, that is correct > > >I think upstream of libMUSCLE would be happy to profit from these > >changes as well. > > ok, alternatively, I was intending to set the max_thread_count to the > maximum available threads on a system. I was unable to successfully > implement this change (via omp_get_thread_num()), so instead, set > this to a large value (64). thoughts/recommendations? This mail goes in CC to our mailing list. May be there are some ideas. > >I plan to apply these to the official Debian package > >since it seems sensible to me and link parsnp against this library > >dynamically. > > agreed, this makes sense OK. > >What do you think? > > all of this sounds great, thanks again for your time/effort getting > parsnp packaged into Debian. You are welcome - thanks for providing parsnp as free software Andreas. -- http://fam-tille.de
Re: Lets maintain libbpp-phyl-omics in Debian Med team
Hi Julien, On Thu, Apr 07, 2016 at 08:57:48AM +0200, Julien Yann Dutheil wrote: > > Sorry, no. You push a tag to github (or whatever repository you might > > use) and uscan will recognise a new version. It will download the > > according tarball and this tarball will be used as source tarball for > > the next package. > > I'm still a bit unclear about that, but let's just get the mentoring and > once I will have done it once, I will know how it works :) I've started with libbpp-core[1] which is now conform to Debian Med policy and fixes two open bugs. I have not yet closed "FTBFS with GCC 6: cannot convert x to y" [2]. It would be great if you as upstream could have a look and make sure it will at least be fixed in the next release (or tell me if it is fixed even in the current release). I'll continue with the other packages in this manner. Kind regards Andreas. [1] https://anonscm.debian.org/git/debian-med/libbpp-core.git [2] https://bugs.debian.org/811657 -- http://fam-tille.de
Re: Does bwa really need to be limited to amd64?
على الجمعـة 8 نيسـان 2016 05:22، كتب Charles Plessy: > BWA failed to build on i386 at version 0.7.5a-1 with the following error, > despite the -D_NO_SSE2 option: > > /usr/lib/gcc/i486-linux-gnu/4.7/include/emmintrin.h:32:3: error: #error > "SSE2 instruction set not enabled" > > https://buildd.debian.org/status/fetch.php?pkg=bwa&arch=i386&ver=0.7.5a-1&stamp=1370353173 > > I expect that if you try to build it on i386, it will fail again. > > In any case, for most bioinformatics software that is now developed on amd64, > I > would not trust output of the programs built successfully on other > architectures unless there are good regression tests. > That's a good point. Thanks for clarifying the situation anyway. > So I take the opportunity to say a big thank you to the people working on > regression tests right now :) Indeed. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Does bwa really need to be limited to amd64?
On Fri, Apr 08, 2016 at 10:58:01PM -0700, Afif Elghraoui wrote: > > على الجمعـة 8 نيسـان 2016 05:22، كتب Charles Plessy: > > > > In any case, for most bioinformatics software that is now developed on > > amd64, I > > would not trust output of the programs built successfully on other > > architectures unless there are good regression tests. > > That's a good point. Thanks for clarifying the situation anyway. May be you can give some hints for such a test to our GSoC students? > > So I take the opportunity to say a big thank you to the people working on > > regression tests right now :) > > Indeed. +1 :-) Kind regards Andreas. -- http://fam-tille.de
Re: Lets maintain libbpp-phyl-omics in Debian Med team
Hi Julien, On Sat, Apr 09, 2016 at 12:19:07AM +0200, Andreas Tille wrote: > > I've started with libbpp-core[1] which is now conform to Debian Med > policy and fixes two open bugs. I have not yet closed "FTBFS with GCC > 6: cannot convert x to y" [2]. It would be great if you as upstream > could have a look and make sure it will at least be fixed in the next > release (or tell me if it is fixed even in the current release). > > I'll continue with the other packages in this manner. I continued with libbpp-seq[3] but this build shows a problem when running the test suite: dh_auto_test make -j1 test ARGS\+=-j1 make[1]: Verzeichnis „/home/andreas/debian-maintain/alioth/debian-med_git/build-area/libbpp-seq-2.2.0/obj-x86_64-linux-gnu“ wird betreten Running tests... /usr/bin/ctest --force-new-ctest-process -j1 Test project /home/andreas/debian-maintain/alioth/debian-med_git/build-area/libbpp-seq-2.2.0/obj-x86_64-linux-gnu Start 1: test_alphabets 1/7 Test #1: test_alphabets ... Passed0.01 sec Start 2: test_sequences 2/7 Test #2: test_sequences ... Passed0.01 sec Start 3: test_io 3/7 Test #3: test_io ..***Exception: Other 0.01 sec terminate called after throwing an instance of 'bpp::IOException' what(): Fasta::appendFromStream: can't read from istream input Start 4: test_containers 4/7 Test #4: test_containers .. Passed0.01 sec Start 5: test_alignment_scores 5/7 Test #5: test_alignment_scores Passed0.01 sec Start 6: test_walker 6/7 Test #6: test_walker .. Passed0.02 sec Start 7: test_bowker 7/7 Test #7: test_bowker .. Passed 76.56 sec 86% tests passed, 1 tests failed out of 7 Total Test time (real) = 76.62 sec The following tests FAILED: 3 - test_io (OTHER_FAULT) Errors while running CTest Makefile:130: die Regel für Ziel „test“ scheiterte make[1]: *** [test] Fehler 8 (Sorry for German locale). Since libcpp-core needed to pass the new queue due to the name change forced by the g++-5 transition you need to use your own libbpp-core-dev package to reproduce this build which hopefully will express the same problem. Could you please comment on this? Kind regards Andreas. > [1] https://anonscm.debian.org/git/debian-med/libbpp-core.git > [2] https://bugs.debian.org/811657 [3] https://anonscm.debian.org/git/debian-med/libbpp-seq.git -- http://fam-tille.de
