Re: Issue with new version of Bowtie

[Fabian Klötzl]

Hi Andreas,

I am having trouble reproducing the issue locally, but reading between
the lines of the template mess, the solution might be as simple as
defining ~KarkkainenBlockwiseSA as noexcept:

~KarkkainenBlockwiseSA() noexcept {
   …
}

The compiler complains, because in C++11 automatically generated
constructors are defined as noexcept, when they do not throw exceptions.
This is the case for InorderBlockwiseSA, which does not have a
user-defined destructor. So the looser ~KarkkainenBlockwiseSA()
overrides a strict function, which is not allowed. As having a
destructor throw exceptions is dangerous and ~KarkkainenBlockwiseSA()
does not seem to throw any, it can be marked as noexcept.

If that doesn't help, try to compile the code with an older C++ version
as it doesn't seem to use any of the new features.

Best,
Fabian

Please choose a free license for gmap

[Alex Mestiashvili]

Hi,

I'm writing you on behalf of the Debian Med team which is a group inside
Debian with the objective to package free software with relevance in
biology and medicine for official Debian.  As you might possibly know we
have created packages also from gmap as you can see on our so
called tasks biology page[1].

According to the Debian Free Software Guidelines[2] which are widely
accepted as Open Source definition the current license is not free since
it forbids the use and distribution of modified copy under some
conditions and also forbids free use of the software in commercial products.

I wonder whether you might consider changing the licensing to some free
license like GPL, BSD or MPL - just anything that has no such
restriction to non-commercial use and use of modified code.  You might
like to know that several other authors of biologic software recently
switched to free licenses (may be most prominently phylib).  The
advantage for you inside Debian would be a higher visibility of gmap
(since we distribute it with metapackages) and a way better quality
assurance since Debian is running several tools to automatically detect
problems inside the distributed software.


Kind regards and thanks for your cooperation

Alex

[1] http://blends.debian.org/med/tasks/bio#gmap
[2] https://www.debian.org/social_contract#guidelines

Re: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

[Andreas Tille]

Hi Fabian,

On Mon, Sep 04, 2017 at 04:22:43PM +0200, Fabian Klötzl wrote:
> > Will do. Forgot to mention to mention that the build fails at the unit
> > tests now. ☺

This issue is solved now.  I provided some needed binaries in
libvcflib-tools under /usr/bin now.

> Done. Upstream already promised to improve the situation with the next
> API update.
> 
> https://github.com/samtools/htslib/issues/587

Cool.  Thanks a lot for your help

Andreas.

-- 
http://fam-tille.de

Re: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

[Fabian Klötzl]

On 04.09.2017 13:38, Fabian Klötzl wrote:
> 
> On 04.09.2017 13:20, Andreas Tille wrote:
>> Fully ACK.  Would you volunteer to create an issue in htslib bug tracker.
>>  
>>> Btw, I had to add -std=c++11 for a successful build.
>>
>> Seems you have build the package locally.  Would you mind pushing your
>> changes to Git?
> 
> Will do. Forgot to mention to mention that the build fails at the unit
> tests now. ☺
> 

Done. Upstream already promised to improve the situation with the next
API update.

https://github.com/samtools/htslib/issues/587

F

Issue with new version of Bowtie

[Andreas Tille]

Hi,

I've moved bowtie from SVN to Git[1] and injected the packaging for the
latest upstream version.  Unfortunately the build ended in:

...
g++ -w -O3 -DCOMPILER_OPTIONS="\"-O3  -Wl,--hash-style=both -DWITH_TBB 
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=.=. 
-fstack-protector-strong -Wformat -Werror=format-security  -g -O2 
-fdebug-prefix-map=.=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -Wl,-z,now\""  -Wl,--hash-style=both 
-DWITH_TBB -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/build/bowtie-1.2.1.1+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security  -g -O2 
-fdebug-prefix-map=/build/bowtie-1.2.1.1+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security  -Wl,-z,relro -Wl,-z,now  \
-fno-strict-aliasing -DBOWTIE_VERSION="\"`cat VERSION`\"" 
-DBUILD_HOST="\"Debian-reproducible\"" -DBUILD_TIME="\"`dpkg-parsechangelog 
--show-field Date`\"" -DCOMPILER_VERSION="\"`g++ -w -v 2>&1 | tail -1 | sed 's/ 
*(.*//'`\"" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE  
-DPREFETCH_LOCALITY=2 -DBOWTIE_MM -DBOWTIE_SHARED_MEM -DNDEBUG -Wall \
-I /usr/include/seqan \
-o bowtie-build-s ebwt_build.cpp \
ccnt_lut.cpp ref_read.cpp alphabet.cpp shmem.cpp edit.cpp ebwt.cpp  
bowtie_build_main.cpp \
-Wl,-z,relro -Wl,-z,now -lz -lpthread -ltbb -ltbbmalloc_proxy 
In file included from ebwt.h:27:0,
 from ebwt_build.cpp:11:
blockwise_sa.h: In instantiation of 'class 
KarkkainenBlockwiseSA > >':
blockwise_sa.h:502:52:   required from here
blockwise_sa.h:203:3: error: looser throw specifier for 
'KarkkainenBlockwiseSA::~KarkkainenBlockwiseSA() noexcept (false) [with 
TStr = seqan::String >]'
   ~KarkkainenBlockwiseSA() {
   ^
In file included from ebwt.h:27:0,
 from ebwt_build.cpp:11:
blockwise_sa.h:165:7: error:   overriding 'virtual 
InorderBlockwiseSA > >::~InorderBlockwiseSA() noexcept'
 class InorderBlockwiseSA : public BlockwiseSA {
   ^~
In file included from ebwt.h:27:0,
 from ebwt_build.cpp:11:
blockwise_sa.h: In instantiation of 'class 
KarkkainenBlockwiseSA > >':
ebwt.h:752:66:   required from 'void 
Ebwt::initFromVector(std::vector&, std::vector&, 
std::vector&, TIndexOffU, const RefReadInParams&, std::ofstream&, 
std::ofstream&, const string&, int, bool, TIndexOffU, TIndexOffU, TIndexOffU, 
int, uint32_t) [with TStr = seqan::String >; TIndexOffU = unsigned int; std::ofstream = 
std::basic_ofstream; std::__cxx11::string = 
std::__cxx11::basic_string; uint32_t = unsigned int]'
ebwt.h:509:17:   required from 'Ebwt::Ebwt(int, int32_t, int32_t, 
int32_t, int32_t, int32_t, int, const string&, bool, bool, TIndexOffU, 
TIndexOffU, TIndexOffU, int, std::vector&, std::vector&, 
std::vector&, TIndexOffU, const RefReadInParams&, uint32_t, 
int32_t, int32_t, bool, bool, bool) [with TStr = 
seqan::String >; 
int32_t = int; std::__cxx11::string = std::__cxx11::basic_string; 
TIndexOffU = unsigned int; uint32_t = unsigned int]'
ebwt_build.cpp:451:13:   required from 'void driver(const string&, 
std::vector&, const string&, bool) [with 
TStr = seqan::String >; std::__cxx11::string = std::__cxx11::basic_string]'
ebwt_build.cpp:625:61:   required from here
blockwise_sa.h:203:3: error: looser throw specifier for 
'KarkkainenBlockwiseSA::~KarkkainenBlockwiseSA() noexcept (false) [with 
TStr = seqan::String >]'
   ~KarkkainenBlockwiseSA() {
   ^
In file included from ebwt.h:27:0,
 from ebwt_build.cpp:11:
blockwise_sa.h:165:7: error:   overriding 'virtual 
InorderBlockwiseSA > >::~InorderBlockwiseSA() noexcept'
 class InorderBlockwiseSA : public BlockwiseSA {
   ^~
Makefile:264: recipe for target 'bowtie-build-s' failed
make[2]: *** [bowtie-build-s] Error 1
make[2]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
debian/rules:17: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
debian/rules:14: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
I: copying local configuration
E: Failed autobuilding of package
...


Could somebody more educated in bowtie (seqan) please have a look?

Kind regards

   Andreas.


[1] https://anonscm.debian.org/git/debian-med/bowtie.git

-- 
http://fam-tille.de

Re: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

[Fabian Klötzl]

On 04.09.2017 13:20, Andreas Tille wrote:
> Fully ACK.  Would you volunteer to create an issue in htslib bug tracker.
>  
>> Btw, I had to add -std=c++11 for a successful build.
> 
> Seems you have build the package locally.  Would you mind pushing your
> changes to Git?

Will do. Forgot to mention to mention that the build fails at the unit
tests now. ☺

Fabian

Re: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

[Andreas Tille]

Hi Fabian,

On Mon, Sep 04, 2017 at 12:47:05PM +0200, Fabian Klötzl wrote:
> On 02.09.2017 14:54, Andreas Tille wrote:
> > The htslib issue remains the same but I have no idea how to fix it.
> 
> The problem is that Allele.h defines a friend function called `json`
> residing in global namespace. However, hts.h already defined a value of
> an enum with the same name, thus the symbols clash. Basically, a
> 
> sed -i 's/json/to_json/' src/Allele.*
> 
> will fix the issue (also one call in Sample.cpp:267). However, in the
> long term hts should stop exporting such generic names. C++ invented
> namespaces and `enum class` exactly to avoid these problems. As htslib
> is pure C, they should prefix their symbols, as everyone else does it.

Fully ACK.  Would you volunteer to create an issue in htslib bug tracker.
 
> Btw, I had to add -std=c++11 for a successful build.

Seems you have build the package locally.  Would you mind pushing your
changes to Git?

Kind regards and thanks for the hints in any case

  Andreas. 

-- 
http://fam-tille.de

Re: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

[Fabian Klötzl]

Hi Andreas,

On 02.09.2017 14:54, Andreas Tille wrote:
> The htslib issue remains the same but I have no idea how to fix it.

The problem is that Allele.h defines a friend function called `json`
residing in global namespace. However, hts.h already defined a value of
an enum with the same name, thus the symbols clash. Basically, a

sed -i 's/json/to_json/' src/Allele.*

will fix the issue (also one call in Sample.cpp:267). However, in the
long term hts should stop exporting such generic names. C++ invented
namespaces and `enum class` exactly to avoid these problems. As htslib
is pure C, they should prefix their symbols, as everyone else does it.

Btw, I had to add -std=c++11 for a successful build.

Best,
Fabian

Re: Python-pysam 0.12 released, could someone please care?

[Andreas Tille]

Hi Afif,

On Mon, Sep 04, 2017 at 12:00:08AM -0700, Afif Elghraoui wrote:
> 
> Well, the build is still not successful. I've filed an issue upstream for one 
> set of test failures [1] and there is another test failure due to a 
> segmentation fault that needs some investigation.

If it would be only the issues you reported [1] I would not mind to
deactivate the tests temporarily.  A segmentation fault is another
issue thought.
 
> If I move bcftools to Unstable now, we'd need to file an RC bug against it to 
> prevent its migration and breaking of the current pysam version in Testing.

Makes sense even if I'd love to get python-pysam rather sooner than
later into unstable.

Kind regards

  Andreas.
 
> 1. https://github.com/pysam-developers/pysam/issues/534
 

-- 
http://fam-tille.de

Re: Python-pysam 0.12 released, could someone please care?

[Afif Elghraoui]

Hi, Andreas,

On September 3, 2017 11:50:05 PM PDT, Andreas Tille  wrote:
>Hi Afif,
>
>I noticed that you commited some promising changes.  They are depending
>from bcftools 1.5 which is only in experimental.  From my point of view
>it makes sense to move bcftools 1.5 to unstable to enable building
>python-pysam in unstable as well.  Any reason to be more carefully and
>stick to experimental?
>

Well, the build is still not successful. I've filed an issue upstream for one 
set of test failures [1] and there is another test failure due to a 
segmentation fault that needs some investigation.

If I move bcftools to Unstable now, we'd need to file an RC bug against it to 
prevent its migration and breaking of the current pysam version in Testing.

regards
Afif

1. https://github.com/pysam-developers/pysam/issues/534

Re: Python-pysam 0.12 released, could someone please care?

[Andreas Tille]

Hi Afif,

On Tue, Aug 29, 2017 at 10:15:00PM -0700, Afif Elghraoui wrote:
> >Could someone please care since I'm a bit offline-ish this week.
> 
> I'll take a look maybe tonight or tomorrow. Thanks for the ping--I hadn't 
> been watching the releases.

I noticed that you commited some promising changes.  They are depending
from bcftools 1.5 which is only in experimental.  From my point of view
it makes sense to move bcftools 1.5 to unstable to enable building
python-pysam in unstable as well.  Any reason to be more carefully and
stick to experimental?

Kind regards

   Andreas.

-- 
http://fam-tille.de