Re: python-cyvcf2 test failures (Was: python-pybedtools: fixing the failing tests)
Hi Steffen,
On Fri, Jul 27, 2018 at 07:41:21PM +0200, Steffen Möller wrote:
> >>>
> >>> [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.
Good.
> >> 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.
I do not think that anybody of us is observing "random" README.source
files regularly. I'd consider a bug of severity minor the more
realistic approach that somebody might stumble upon the issue and will
try to fix it.
> >> 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.
As far as I know it was just python-pysam which was not updated to 1.8.
I have not yet checked recently whether this is the case. This is
another cry for more contribution. We **really** need more people doing
regular maintenance and check what package needs an upgrade.
Do you know any specific package which does not work with version 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.
> > 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.
Its a bit of manual work and I really don't know why this is not
somewhere automated - I think it should be easily doable to wrap those
two lines into one script taking a single deb as input and I guess if I
get bored by that manual process 3-4 further times I write something up
...
> >> 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.
Fine.
Kind regards from DebConf 18
Andreas.
--
http://fam-tille.de
Reply to: