Cross‐linking #443671. (This one is presumably much easier to land.)

Quick context:

• cpp_redis had its CMake config completely reworked in ceph/cpp_redis@3bcded9
• the above happened after ceph/ceph@7aeac65
• the next change to the cpp_redis submodule in ceph was to remove it entirely in ceph/ceph@c6ddf86, but this only hits with ceph 20.0.0
• therefore: no backportable ceph/ceph change we could fetchpatch, meaning we will in fact have to touch the files using either third-party or our own patches

Since those are static strings which are unlikely to change (since the next canonical change will probably be the removal of the files), using substituteInPlace --replace-fail would be functionally equivalent with some upsides (shorter than a patch, no extra files, no external dependency).

If Ceph 20 were to release right now it'd solve a lot of problems (Python 3.12/PyO3, CMake, also Arrow I think), but Tentacle is currently in an RC1 phase.

This is not a review, just context.

ceph won't build for me (x86_64), or more precisely the python3.11-cryptography build fails two tests and even retrying doesn't seem to help.

@vcunat what is the error you're getting? I managed to build ceph on x86_64-linux. Although, I should note I'm also buiding with the python3.11-tkinter fix.

It's some assertions in TestOpenSSLMemoryLeaks.test_x25519_pubkey_from_private_key and TestOpenSSLMemoryLeaks.test_write_pkcs12_key_and_certificates.
280i1ryj9gl098cnkrq8h75gky5jyrf1-python3.11-cryptography-40.0.1.log

It's some assertions in TestOpenSSLMemoryLeaks.test_x25519_pubkey_from_private_key and TestOpenSSLMemoryLeaks.test_write_pkcs12_key_and_certificates. 280i1ryj9gl098cnkrq8h75gky5jyrf1-python3.11-cryptography-40.0.1.log

If you're building on staging-next, the OpenSSL version was bumped to 3.6.0 in #447713. There are reports of memory leaks in OpenSSL 3.6.0 (see openssl/openssl#28888, openssl/openssl#28770, and openssl/openssl#28757).

That could explain why I can build it by layering the python311.tkinter fix and this PR on top of nixos-unstable (I'm still using OpenSSL 3.5.2).

Another detail is that ceph uses cryptography v40 instead of the v45 that's on nixos-unstable... This could also be the cause of the memory leak...

EDIT: I'm currently building ceph.python.pkgs.cryptography with the previously mentioned OpenSSL bump to check if I can reproduce the build failure.

Yes, what I tested was this PR merged to its target (staging-next).

I've managed to reproduce the build failure after using OpenSSL 3.6.0 to build cryptography v40.

I was trying to find out which version of cryptography fixed the issue and I narrowed it down to:

• 42.0.1 - present
• 42.0.4 - fixed

Unfortunately, bash decided to delete itself from my Nix store and now my system can't boot :)

pyca/cryptography@42.0.1...42.0.4

Presumably it is pyca/cryptography#10322, as backported in pyca/cryptography@0e0e46f. Just disabling the tests seems the way to go.

I fail to see why this needs to target staging-next. But the time-wise difference is small, as staging-next should merge to master this weekend, so we need those fixes anyway even if they're not that much related.

On master this PR fixes ceph build for me.

I fail to see why this needs to target staging-next. But the time-wise difference is small, as staging-next should merge to master this weekend, so we need those fixes anyway even if they're not that much related.

it was because this was still not working without the tkinter fix , which was only available on staging-next

OK. That one got to master a few minutes ago.