[Debian-med-packaging] Bug#966470: fix for #966470: biobambam2 autopkgtest failures

John Marshall John.W.Marshall at glasgow.ac.uk
Mon Aug 10 12:04:05 BST 2020


Étienne Mollier wrote:
> I had a look at the autopkgtest failure affecting biobambam2,
> and since these segmentation faults were showing up only in my
> autopkgtest environment, and not when using the package directly
> on my system, it felt like a missing dependency.  So I trapped
> system calls issued by the `bamsormadup` command using `strace`
> within the run-unit-test script, and it turned out the program
> was searching for a libz.so library.
> 
> After appending the zlib1g-dev package to dependencies of the
> biobambam2 package,

It is in fact libmaus2 that is dlopening "libz.so", so it would be better to add to the dependencies of that package, which is a prerequisite of biobambam2.

However this is really a bug in libmaus2, as it is incorrect to use that file with that name at runtime [1]. So the better fix would be to patch libmaus2 to use the runtime filename ("libz.so.1") that is provided by Debian's zlib1g (and ensure that libmaus2 depends on zlib1g -- without ‑dev) in anticipation of upstream libmaus2 making a similar fix.

Thus (as Debian controls exactly the libz.so.1 filename, unlike for the upstream patch):

+++ b/src/libmaus2/lz/ZlibInterface.hpp
@@ -53,7 +53,7 @@ namespace libmaus2
                        static std::string getDefaultZLibName() {
                                return
                                        "../lib/libz_cf.so\ti386:sse4_2,i386:pclmulqdq\n"
-                                       "libz.so\t\n";
+                                       "libz.so.1\t\n";
                        }

    John


[1] https://gitlab.com/german.tischler/libmaus2/-/issues/31


More information about the Debian-med-packaging mailing list