Hi Étienne, On Thu, Nov 12, 2020 at 05:45:44PM +0100, Étienne Mollier wrote: > While working on updating the libmaus2 to version 2.0.762, the > program routine-update caught the version 2.0.764, which failed > to build, apparently due to a new dependency not yet part of > Debian, the brand new headers-only libsecrecy: > > https://gitlab.com/german.tischler/libsecrecy/ > > I'm finishing the update of libmaus2 to version 2.0.762, > although it is already outdated, because the current version > 2.0.743 in unstable is too old for the newer version of its > biobambam2 reverse dependency.
Sounds pretty sensible. > I am also not sure of the time > it would take to get the libsecrecy into the archive given that > the freeze is two months from now. Given that ftpmaster is soooooo fast since some time I have no doubt we will manage this. If you want to start a new package (which looks pretty straightforward from a short look) you can do so. Otherwise I might have some spare cycles tomorrow. > There is also this lintian warning about missing symbols in this > shared library which is nagging me: > > W shared-library-lacks-prerequisites > usr/lib/x86_64-linux-gnu/libmaus2/2.0.743/libmaus2_scram_mod.so > > The lintian recommendation about putting flags such as -lc did > not give much effect. I'm suspecting some peculiarity in the > way the library is linked, but I'm not sure if there is such > corner case possible, or if I'm just missing something somewhere > else. > > I pushed changes on Salsa for further review, as I'm not > entirely sure yet that the library can be released as is: > > https://salsa.debian.org/med-team/libmaus2 > > I'm still running additionnal builds to catch eventual > regressions on arm64 and ppc64el, just in case. Very cool. Please let us know the result. Kind regards Andreas. -- http://fam-tille.de
