Am So., 15. Dez. 2019 um 10:16 Uhr schrieb Pjotr Prins <pjotr2...@thebird.nl>: > [...] > > 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.
That's something I forgot in my last mail: I didn't create PRs, because Meson support was upstream once but was removed. Also because it's understandable if upstream projects want to reduce the amount of ways a software can be built. As it happens though, I have already created (by accident) build definitions that work for the current upstream code of BioD/Sambamba. I've created PRs for those now. Having this upstream would obviously be great, and if there are issues with it, I can help. (The definitions are really straightforward to use though) See https://github.com/biod/BioD/pull/54 and https://github.com/biod/sambamba/pull/419 Integration with CI is possible, but your Travis YAML will become a bit bigger ^^ > > 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. It certainly wasn't needed for the tests :-D I don't think we should silently comment that out from the Debian builds though... > > 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! If the last issues can be fixed, this may just be in time for the next Ubuntu LTS release, which is probably something that you'll want ;-) Currently, BioD fails to build on x86: https://buildd.debian.org/status/fetch.php?pkg=libbiod&arch=i386&ver=0.2.3%2Bgit20191120.b8eecef-1&stamp=1576379323&raw=0 This issue looks trivial to me, it's probably a matter of using size_t instead of plain ints. There's of course also the question of whether we need to support x86 with this package, but in any case, this FTBFS will block the package in unstable until it has either been removed from i386 or the build failure has been fixed. The good news is that the package builds on arm64 now though - yay? ^^ Sambamba is only failing on missing cram_to_bam, so once that's fixed, it should be good to go as well. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
