configure: detected GnuTLS version 3.8.2 checking for nettle_MD5Init in -lgnutls... no checking for nettle_MD5Init in -lnettle... yes checking for gnutls_srp_verifier in -lgnutls... yes checking for rustls_client_session_read in -lrustls... no checking for rustls_connection_read in -lrustls... no configure: error: --with-rustls was specified but could not find rustls. !!! Please attach the following file when seeking support: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd_clang_merged_usr-20231206-115013 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 16.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.6+libcxx Python 3.11.7 Available Rust versions: [1] rust-bin-1.73.0 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 8.382_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm php cli (if any): HEAD of ::gentoo commit ccab9e679122bf7ba1d5e556f1687a02903d5ced Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Dec 6 12:52:39 2023 +0000 2023-12-06 12:52:38 UTC emerge -qpvO net-misc/curl [ebuild UD] net-misc/curl-8.3.0-r2 [8.4.0] USE="adns ftp gnutls* gopher* http2* imap kerberos* ldap* openssl pop3 progress-meter rustls* samba* smtp ssh* ssl telnet* tftp verify-sig* -alt-svc* -brotli -hsts* -idn -mbedtls -nghttp3 -rtmp (-sslv3) -static-libs -test -websockets -zstd" ABI_X86="(64) -32 (-x32)" CURL_SSL="openssl -gnutls -mbedtls -rustls"
Created attachment 878060 [details] emerge-info.txt
Created attachment 878061 [details] emerge-history.txt
Created attachment 878062 [details] environment
Created attachment 878063 [details] etc.clang.tar.xz
Created attachment 878064 [details] etc.portage.tar.xz
Created attachment 878065 [details] logs.tar.xz
Created attachment 878066 [details] net-misc:curl-8.3.0-r2:20231207-002543.log
Created attachment 878067 [details] qlist-info.txt
Created attachment 878068 [details] temp.tar.xz
*** Bug 919397 has been marked as a duplicate of this bug. ***
lld fails to find rustls. Upstream PR submitted to try (and prefer) pkg-config. Will backport whatever finally gets merged - we've missed the 8.7.0 release window, not to mention the older versions that are still in-tree.
Fixed in our 8.7.1 package. I'll backport to 8.{5,6}.0.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7046fc5e9c466101184aba00716f9c666c9ca680 commit 7046fc5e9c466101184aba00716f9c666c9ca680 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-03-29 00:27:03 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-03-31 05:51:20 +0000 net-misc/curl: backport rustls detection fix Closes: https://bugs.gentoo.org/919396 Signed-off-by: Matt Jolly <kangie@gentoo.org> net-misc/curl/curl-8.5.0-r3.ebuild | 2 +- net-misc/curl/curl-8.6.0-r1.ebuild | 3 +- .../curl-8.6.0-backport-rustls-detection.patch | 256 +++++++++++++++++++++ 3 files changed, 259 insertions(+), 2 deletions(-)
Please bump the r(elease) for such changes, ie. the old curl-8.6.0-r1.ebuild would become curl-8.6.0-r2.ebuild after this change. This would help in situations when downgrading to a previously known good version, like what happened in https://bugs.gentoo.org/928236#c6 Thanks for your consideration :)
Well, maybe I'm wrong or something*, because I just saw someone do a PR "the right way" (ie. bump-ed the 'r', so it made a new ebuild like kexec-tools-2.0.28-r1.ebuild) then they undid that by force pushing a change that just changed the non-r version of the ebuild (ie. to the already existing kexec-tools-2.0.28.ebuild was added a patch line, just like what happened here in this Gentoo this issue) , as seen here: https://github.com/gentoo/gentoo/pull/36007#event-12304137288 *So maybe this is by the book, I don't know, I haven't read anywhere about how it's supposed to be done ... but it sure seems wrong to me tho :) Cheers!
(In reply to Emanuel Czirai from comment #14) > Please bump the r(elease) for such changes, > ie. > the old > curl-8.6.0-r1.ebuild > would become > curl-8.6.0-r2.ebuild > after this change. > > This would help in situations when downgrading to a previously known good > version, like what happened in https://bugs.gentoo.org/928236#c6 > > Thanks for your consideration :) Not required in this situation. This is a build time failure and users of curl who want to use rustls can now do so (theoretically, there seems to be an issue with git endpoints). Please see the devmanual for clarification on when a revbump is required: https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html Tl;dr: if you were impacted by this you could not build with rustls anyway, so there's no need to revbump and force every curl user to rebuild. If the git endpoints issue needs a patch though, that's a runtime issue and will need a new revision.
Thank you for reply and link to manual. I wasn't impacted by this very issue(ie. curl-8.6.0-r1.ebuild built and ran fine for me). I was impacted by a different issue (which I linked above), which caused me to want to downgrade back to this version(curl-8.6.0-r1.ebuild), but since the ebuild of this version was changed(a patch was added to it), the build that I got out of it was broken (it builds ok, but it runs brokenly) Yet, I knew this very version(curl-8.6.0-r1.ebuild) worked perfectly before! So, if this had it's revision bumped(to curl-8.6.0-r2.ebuild), I would've immediately noticed it's a different revision and not the one that worked perfectly before. Well unless the -r1 ebuild were removed from the repo. I apologize for the misunderstanding, I hope you understand what I meant now. Presumably this wasn't bumped because it was thought that everyone that wanted to use rustls was getting this build time error, but how can you really assume it is so? I was one person who didn't get the build time error at all. And I assumed that whenever someone commits an ebuild to the gentoo repo, it was tested by them to work or at least compile/emerge. So, at least that committer would be one person for whom the ebuild worked, therefore, you can't assume it doesn't build for everyone..., unless you know that committed ebuilds aren't tested to build?! But maybe I'm misunderstanding the reason for not bumping it...
> Presumably this wasn't bumped because it was thought that everyone that wanted to use rustls was getting this build time error, but how can you really assume it is so? From the devmanual: > Examples of changes that can be done without a revision bump are: > > adding a patch to fix a build-time issue that prevented users from building > the package (since it does not affect users who already managed to build > it) unless: it affected runtime behaviour in some way (e.g. -Wformat or > -Wimplicit-function-declaration fixes); the package may have been > miscompiled, or the change is substantial (if adding a huge patch to fix a > problem, the chances of an unexpected issue being introduced by it > are greater). The fix for this issue was a build-time issue that prevented impacted users from building the package. It passed tests and was accepted upstream, so was considered low risk. Unfortunately, a subtle order-of-operations issue occurred which now results in a _runtime_ failure. This will require a revbump to ensure that any impacted users are able to rebuild. > And I assumed that whenever someone commits an ebuild to the gentoo repo, it was tested by them to work or at least compile/emerge. So, at least that committer would be one person for whom the ebuild worked, therefore, you can't assume it doesn't build for everyone..., unless you know that committed ebuilds aren't tested to build?! We don't exhaustively test USE flag combinations when bumping a package; there are simply too many combinations of USE flag and Gentoo system configuration for this to be feasible. Users who choose to differ from the default USE combinations are expected to report errors; in other cases (like this), the tinderboxes (i.e. automated testing) catch a combination that fails to build and it is automatically reported to be addressed by the package maintainer.
Alright, that makes sense. Thank you very much. Sorry for the noise.
