Re: python-cyvcf2 test failures (Was: python-pybedtools: fixing the failing tests)
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
Reply to: