
<!DOCTYPE html><html><body><div dir="auto">On June 20, 2026 11:32:22 AM GMT+02:00, Sebastian Andrzej Siewior <sebastian@breakpoint.cc> wrote:<br>>On 2026-06-20 10:46:02 [+0200], Fabian Grünbichler wrote:<br>>> I can take care of this, but not right away.<br>><br>>Don't worry, no need to rush. I just try to collect the data and if it<br>>is a low hanging fruit…<br><br>It shouldn't be complicated, just lacking time<br>atm. Because of the need to update the binding<br>crates which are vendored it requires an extra<br>upstream component tarball. We did similar<br>transitions/updates in the past, e.g. for<br>libgit2.<br><br>I will see if a compatible-with-3.x variant is<br>possible and close the bug when its uploaded.<br><br>>> rustc IMHO has all the the right metadata for<br>>> knowing it is part of libssl transitions, you<br>>> cannot determine this by looking at things<br>>> depending on openssl? rustc has a b-d on<br>>> libs-dev, and the cargo binary package built<br>>> from this source has a dependency on <br>>> libssl3t64..<br>><br>>I picked it up recently thinking due to the libssl-dev dependency. But<br>>cargo depends on libssl3t64. Hmmm. If this has been like that in April<br>>where I did the first rebuild then I might need to check my tooling…<br><br>I haven't double checked, but it should be like<br>that for basically ever (at least since the rustc<br>cargo source package merger, and before that it<br>would have been true for src:cargo instead :)).<br><br>Fabian<br></div></body></html>