https://bugzilla.redhat.com/show_bug.cgi?id=2266544 --- Comment #7 from Fabio Valentini <decathorpe@xxxxxxxxx> --- (In reply to Jens Reimann from comment #6) > As you mentioned, it mostly comes from the `rust2rpm` tool anyway. I noticed > that you assume that 26 is the most recent version, for Fedora 39 it still > is 25. Thus the "old" version. But even that fix is easy. No, I meant what I said. rust2rpm and cargo-rpm-macros are from different packages and are not necessary updated in sync. rust-packaging / cargo-rpm-macros really is at v26 now, whereas I am still working on releasing rust2rpm v26. > About the vendoring, I don't have a list. I am not sure if there's a tool > already to simply check this. What would be cool in any case would be to > have the ability to consume what is present, and vendor the rest. This is not really possible with the way cargo treats crate sources. You can only specify *one* registry replacement. Doing partial vendoring is not feasible. > I might need a bit more time to work through all of those, (especially the > openssl/native-tls stuff) but I will try. For the client side that's simple, > but for the service side the native-tls wasn't possible IIRC. I need to > check back what the issue was, but for the server side it was either pretty > hard, or impossible to get rid of rustls. Thus going "all in" with rustls, > as otherwise the dependency list would have grown even more and one would > have had multiple TLS stacks in a single application. Ok, makes sense to me. Thank you for checking! Then sticking with rustls / ring should be OK. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2266544 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202266544%23c7 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue