[Debian-med-packaging] Bug#938431: Fixing sambamba 0.8.6

[Pjotr Prins]

On Sun, Dec 15, 2019 at 03:15:59AM +0100, Matthias Klumpp wrote:
> The LDC transition went really well this time, I don't think it has
> ever been this smooth! No regressions this time, hurray!

Indeed!

> I had a bit of time to look into the sambamba/biod packages today, and
> fixing them was actually really easy. Originally, I wanted to just
> make use of the upstream-provided Makefiles, but unfortunately it was
> really annoying to make them produce a proper static and dynamic
> library, and then I would still have had the problem of installing all
> pieces to the right locations and to write a pkg-config file.
> Therefore, the way of least resistance was to just use Meson for
> building, as that does everything we need in Debian. Both BioD and
> Sambamba build well with Meson.

That is great. We can add the meson builds in the repos.

> I applied a few tweaks to the packages, that haven't been there
> before: BioD is now built as a shared as well as a static library, so
> applications can choose between the two. That's pretty common in
> Debian, and as a sideeffect this also guarantees that things are
> rebuilt properly when a transition happens. The Sambamba package will
> now prefer statically linking BioD if possible (so BioD is statically
> linked by default now in Debian).
> Additionally both packages now apply the optimization flags upstream
> has set for releases (-O3, no bounds checks, etc.). Combined, these
> two changes should make the Debian builds comparably fast to the
> upstream builds, but I haven't tested that yet.

> There are also two brand new remaining issues: Apparently, for some
> reason, SONAME isn't set correctly for BioD, producing a Lintian error
> - not sure what happens there, and which component is to blame for
> that (Meson or LDC, most likely). Also, Sambamba doesn't *actually*
> build yet:
> ```
> roup -L=-rpath -L=/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
> slicereader.d:71: error: undefined reference to 'cram_to_bam'
> collect2: error: ld returned 1 exit status
> ```
> The cram_to_bam is private in htslib, so it shouldn't be used by other
> applications. Not sure whether htslib or Sambamba needs to be changed
> here, I simply worked around this issue for testing, and when this is
> resolved, Sambamba builds & works.

Sambamba ships with an old version of htslib that is patched for that
function call. I plan to drop CRAM support and htslib. No one I know
uses the CRAM functionality in sambamba.

> Unfortunately I briefly forgot that this issue existed, so I already
> uploaded the new sambamba package with this issue still present (I
> remembered literally the moment the upload finished), so its builds
> will fail. This is probably something for Andreas to look into :-)
> 
> Anyway, I hope this is helpful to you and the resulting binaries are
> performant :-)

Thanks Matthias!

Pj.