#1138824#5
Date:
2026-06-04 10:35:06 UTC
From:
To:
Hello,

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"

Thanks,
Andrius

#1138824#12
Date:
2026-06-09 19:20:14 UTC
From:
To:
Why is the rebuild needed?

Cheers

#1138824#17
Date:
2026-06-09 19:52:05 UTC
From:
To:
Hi,


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.

Paul

#1138824#22
Date:
2026-06-10 06:35:26 UTC
From:
To:
Hi,

Paul is right, there was an ABI breakage in rdkit, rebuilding coot will
cure its autopkgtests and allow rdkit to migrate.

Andrius

#1138824#27
Date:
2026-06-10 07:00:13 UTC
From:
To:
No, this will only paper over the issue in rdkit (as Paul also said).
ABI breakage in rdkit needs to be fixed in rdkit.

Cheers

#1138824#32
Date:
2026-07-01 10:03:06 UTC
From:
To:
This needs to be fixed in rdkit, reassigning.
#1138824#45
Date:
2026-07-29 07:37:26 UTC
From:
To:
Hi,
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

#1138824#50
Date:
2026-07-29 08:02:16 UTC
From:
To:
Hi,

That was fast:

|we do not guarantee ABI stability from one release to the next. One
|should assume that dependencies that link against RDKit shared libs will
|need to be rebuilt against a new RDKit release. Code changes should,
|however, generally not be required. Any time that is the case, it will
|be covered in the release notes

So I guess we should go with option 3 above?


Michael