Hi, On Tue, Jun 09, 2026 at 09:52:05PM +0200, Paul Gevers wrote: > On 6/9/26 21:20, Sebastian Ramacher wrote: > > > I want to request binNMU of coot to rebuild it against librdkit-dev >= > > > 202603.2-1: > > > > > > nmu coot_1.1.18+dfsg-5 . amd64 arm64 loong64 ppc64el riscv64 . > > > unstable . > > > -m "Rebuild with librdkit-dev >= 202603.2-1" > > > > Why is the rebuild needed? > > > I expect this is in reaction to bug #1139447 with is about rdkit not > migrating (due to autopkgtest regression). Looking in the log I see: > > 69s /usr/libexec/coot-1: symbol lookup error: > /usr/lib/x86_64-linux-gnu/coot/libcoot-lidia-core.so.0: undefined symbol: > _ZN5RDKit17common_properties8_CIPRankB5cxx11E > > Usually that means an ABI breakage and rebuilds paper over that.
I have complained about this here: https://github.com/rdkit/rdkit/pull/8765#issuecomment-5114438834 But I am wondering what to do here in case upstream is not planning to bump their API, it has been a while and we shipped a few releases with the dropped/renamed(?) symbols. I guess the options are: 1. Hold our nose, rebuild coot as requested and add versioned deps. Are there any other reverse deps of librdkit1t64? I don't think so. 2. Bump librdkit1t64 to librdkit1d (would that work? do we need something like librdkit1z to sort after 1t64?). 3. Drop the shared libraries, because we are dealing with scientific software. I'll see what the rdkit guys say first. Michael
