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.
