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
