Hello Liubov, On 7/20/18 2:57 PM, Liubov Chuprikova wrote: > ... > > On Sun, 8 Jul 2018 at 01:23 Steffen Möller <[email protected] > <mailto:[email protected]>> wrote: > > - cyvcf2 is in a new version 0.9.0 now, but, well, tests fail. > > > There was a new upstream version recently in which one of the tests > (issue44) was supposed to be fixed, but hadn't yet [1]. I tried to dig > into this and its other test failures, but they seem to be quite > tricky for me. So I think, Steffen's claim for someone's help with > cyvcf2 and its dependency htslib still remains on the table: > > > It comes > with its own version of htslib, which may well contribute to the > situation since I had nothing better to do than to substitute it with > the one the distribution ships. Is anybody close to upstream on this > list to have a look? > > > With regards, > Liubov > > [1] https://github.com/brentp/cyvcf2/issues/89#issuecomment-406354822
I think we got as far. also with the help by upstream, that if we take upstream's regular code base, everything compiles and installs as expected. This leaves it to a failing assert in the htslib library. I have finally compared the htslib of cyvcf2 with the original htslib 1.8 version and found that these two have diverged a bit. I came to the conclusion that we should then not substitute that subdirectory with our repository's htslib 1.8. On a sidenote, because of incompatibilities with existing packages we have htslib in experimental (the latest version of htslib is now 1.9). The update was once performed only because of cyvcf2 if I recall correctly. I had a look at 1.9 but need to learn about gcc symbol files, first. Concerning cyvcf2 I want to wait for a reply from upstream on https://github.com/brentp/cyvcf2/issues/91 . Do you also think that it would be fine to keep cyvcf2 statically linked against that local fork of htslib? Cheers, Steffen
