Re: python-cyvcf2 test failures (Was: python-pybedtools: fixing the failing tests)
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.
> 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).
> 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.
> 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].
> 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.
Kind regards
Andreas.
[1] https://wiki.debian.org/UsingSymbolsFiles
--
http://fam-tille.de
Reply to: