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

Why is the rebuild needed?

Cheers

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

Hi,

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

Andrius

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

This needs to be fixed in rdkit, reassigning.

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

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

Hi,

Seems so. We will have to switch to static libraries in
bin:librdkit-dev, and, in turn, adapt src:coot and src:votca to use them.

Andrius

Hello,

Bug #1138824 in rdkit reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debichem-team/rdkit/-/commit/0354a5d6a5b8c90da52a50225db76f05c5dd0c6b

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1138824

Hello,

I created branch 'switch-to-static' on Salsa to attempt switching rdkit
to static libraries only. I successfully replaced dynamic libraries with
static ones and made postgres cartridge link statically. What I wasn't
able to do is to switch to static linking in Python bindings. Hence
tag:help.

Best,
Andrius

Hello,

I have managed to switch rdkit to static-only libraries in branch
'switch-to-static' on Salsa. The package is uploaded to experimental for
trying it out. Most of the packages depending on python3-rdkit rebuild
as before. Only two packages declare dependency on librdkit-dev: coot
and votca. The latter, src:votca, does not seem to need this dependency
in first place (#1149310), but there are problems with src:coot which
fails by complaining about faulty rdkit-targets.cmake. This is most
likely true as I did not inspect the installed *.cmake definitions -
will do it when I have time.

I would like to ask the co-maintainers to review the resulting package
in experimental. Are my changes OK, does the package look maintainable?
I had to patch the buildsystem a bit to statically link python wrappers,
but the patch is rather small.

Best,
Andrius