Created attachment 896481 [details] emerge --info '=net-misc/curl-9999::gentoo' Hello everyone, I'm on a mission to fix -9999 ebuilds in Gentoo. Here is about net-misc/curl. There's an error about Secure Transport, which from what I understand is some legacy crud in the network stack.
Created attachment 896482 [details] emerge -pqv '=net-misc/curl-9999::gentoo'
Created attachment 896483 [details] /var/tmp/portage/net-misc/curl-9999/temp/build.log
Hi Philippe, Ensuring that all of the live ebuilds build at a given point in time may be challenging; they often exist to serve as templates for ebuild updates and enable quick testing and aren't expected to always be in a buildable state. Unfortunately your assessment of the build failure here is incorrect - Secure transport throws a warning. ``` configure: WARNING: Secure-Transport is enabled for TLS but it does not support TLS 1.3 ``` The actual cause of this failure is called out in the Portage error: ``` * ERROR: net-misc/curl-9999::gentoo failed (configure phase): * need to update ebuild * * Call stack: * ebuild.sh, line 136: Called src_configure * environment, line 2910: Called multilib-minimal_src_configure * environment, line 2233: Called multilib_foreach_abi 'multilib-minimal_abi_src_configure' * environment, line 2483: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 2188: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 2186: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure' * environment, line 699: Called multilib-minimal_abi_src_configure * environment, line 2227: Called multilib_src_configure * environment, line 2786: Called die * The specific snippet of code: * grep -q Requires.private libcurl.pc && die "need to update ebuild"; * ``` This is because curl upstream recently began generating the libcurl.pc file, eliminating the need for our workaround and making our implementation cause build failures. The fix for this has been staged alongside some other live ebuild changes pending feedback for a little while and will be merged shortly: https://github.com/gentoo/gentoo/pull/37238
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e3f2977eec5889630abbc33504d4817c47058b47 commit e3f2977eec5889630abbc33504d4817c47058b47 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-06-21 11:39:38 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-06-29 06:52:54 +0000 net-misc/curl: wire up live ebuild for openssl-quic Thanks to dev-libs/openssl exposing a QUIC API from 3.2, cURL is able to use OpenSSL as a QUIC backend. This commit enables users to select between the `curl_quic_ngtcp2` and `curl_quic_openssl` backends via their associated USE_EXPAND and provides a mechanism to easily add more backends as they are implemented. It also renames the live ebuild's `nghttp3` USE to `http3` to support its use as a generic feature flag, and to align with net-analyzer/wireshark and www-serners/nginx. Finally, we get to drop a disgusting pkg-config workaround thanks to some upstream efforts that render it irrelevant (and detrimental to a successful build). Closes: https://github.com/gentoo/gentoo/pull/37238 Closes: https://bugs.gentoo.org/934993 Signed-off-by: Matt Jolly <kangie@gentoo.org> net-misc/curl/curl-9999.ebuild | 70 ++++++++++++++++-------------------------- net-misc/curl/metadata.xml | 4 ++- 2 files changed, 30 insertions(+), 44 deletions(-)
Yes you are correct, the reason is indeed the pkg-config hack in the ebuild not being needed anymore. Patch 140baa2 should do. ``` Ensuring that all of the live ebuilds build at a given point in time may be challenging; they often exist to serve as templates for ebuild updates and enable quick testing and aren't expected to always be in a buildable state. ``` It does not have to be either-or, getting at least the base system building is an attainable goal with tangible benefits, if only for testing as you say. These -9999 builds eventually trickle down into the testing ebuilds so at least to me it makes sense to maintain them. By the by, I don't understand the criterion for moving packages to the stable keyword, is this documented anywhere? What is the deciding factor for demoting packages into ~testing?
(In reply to Philippe Michaud-Boudreault from comment #5) > It does not have to be either-or, getting at least the base system building > is an attainable goal with tangible benefits, if only for testing as you > say. These -9999 builds eventually trickle down into the testing ebuilds so > at least to me it makes sense to maintain them. Sure, but people do look at them when releases get cut. In the case of curl, Kangie ends up updating curl-9999 quite a bit, but he had some pending patches for QUIC first.
(In reply to Philippe Michaud-Boudreault from comment #5) > By the by, I don't understand the criterion for moving packages to the > stable keyword, is this documented anywhere? What is the deciding factor > for demoting packages into ~testing? https://devmanual.gentoo.org/keywording/index.html
