OpenSSL 4.0 is in experimental. This package fails to build against it:
|  thread 'main' (778032) panicked at /rust/deps/openssl-sys-0.9.111/build/main.rs:472:5:
|
|  This crate is only compatible with OpenSSL (version 1.0.2 through 1.1.1, or 3), or LibreSSL 3.5
|  through 4.2.x, but a different version of OpenSSL was found. The build is now aborting
|  due to this version mismatch.

This did not pop up earlier because of missing openssl dependency and
rustc was not among those packages to build on my list. This error looks
familiar and the included rust crate is probably an older version.
There is a packaged one which is newer because a lot of rust- packages
failed and then it resolved on its own for most of them.

Sebastian

I can take care of this, but not right away.

rustc IMHO has all the the right metadata for
knowing it is part of libssl transitions, you
cannot determine this by looking at things
depending on openssl? rustc has a b-d on
libs-dev, and the cargo binary package built
from this source has a dependency on
libssl3t64..

rustc doesn't use packaged crates.

Fabian

Don't worry, no need to rush. I just try to collect the data and if it
is a low hanging fruit…

I picked it up recently thinking due to the libssl-dev dependency. But
cargo depends on libssl3t64. Hmmm. If this has been like that in April
where I did the first rebuild then I might need to check my tooling…

Okay.

Sebastian

It shouldn't be complicated, just lacking time
atm. Because of the need to update the binding
crates which are vendored it requires an extra
upstream component tarball. We did similar
transitions/updates in the past, e.g. for
libgit2.

I will see if a compatible-with-3.x variant is
possible and close the bug when its uploaded.

I haven't double checked, but it should be like
that for basically ever (at least since the rustc
cargo source package merger, and before that it
would have been true for src:cargo instead :)).

Fabian