Hi Andreas, On 7/27/18 5:06 PM, Andreas Tille wrote: > Hi Steffen, > > On Fri, Jul 27, 2018 at 03:00:58PM +0200, Steffen Möller wrote: >>> 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. > Can you specify this bit by may be attaching a patch and making suggesting > upstream to forward their changes to htslib. We'll definitely get into > a maintenance hell if we get several different versions flying around in > different packages. We should at least try hard to make upstream talk to > each other - that's finally part of our Debian maintainers job.
>From how I perceived it, we have everything prepared for that. And I am very confident that this exchange will now happen. >> I came to the >> conclusion that we should then not substitute that subdirectory with our >> repository's htslib 1.8. > If there is no better clue that could be a short term workaround but > please make sure you talk to upstream (may be both sides htslib and > cyvcf2). Hm. Mixed feelings here. I am not exactly sure about what you mean but this is an upstream issue in my mind. Let me summarise the situation in the README.source and then observe/remind at later releases. >> On a sidenote, because of incompatibilities with existing packages we >> have htslib in experimental (the latest version of htslib is now 1.9). > We should make some effort to upgrade this soon - there is no point > for waiting until I worked down a different stock of todo items. It is a bit annoying but that there are these version incompatibilities. We cannot just go and substitute the 1.7 version. > >> 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. > If all else fails rename it to *.symbols_ and commit your changes. > I might volunteer to check this issue (if nobody else will beat me > with it), The wimpy approach would be to forget the old symbols > file and create one from scratch according to the Wiki doc[1]. Thank you for that pointer. I'll educate myself on that. > >> 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? > Temporary if all other means would fail - and than with filing a bug > against the package to set some signal that there is remaining work to > do. Ok, I'll do that. > [1] https://wiki.debian.org/UsingSymbolsFiles > Cheers, Steffen
