Re: [bitbake-devel] [PATCH v2] fetch2/wget: reuse  cached HTTPS connections

The failure happens while the new self-test is generating its temporary certificate, before it exercises the HTTPS connection cache. Unfortunately, the test currently redirects both stdout and stderr to /dev/null, so the log only contains the exit status.

I reproduced the command in an AlmaLinux 8 container using the same Yocto 5.1 buildtools, where it succeeds. This therefore looks specific to the alma8-vk-2worker, possibly its crypto/FIPS configuration or local state.

I will prepare a small follow-up patch which captures the OpenSSL output and includes it in the log. A rerun with that patch should expose the actual reason.

________________________________
From: Richard Purdie <[email protected]>
Sent: Friday, August 14, 2026 3:21 PM
To: Fredrik Svensson (svsvenss) <[email protected]>; [email protected] <[email protected]>
Cc: Mathieu Dubois-Briand <[email protected]>
Subject: Re: [bitbake-devel] [PATCH v2] fetch2/wget: reuse cached HTTPS connections

Hi,

On Wed, 2026-08-12 at 17:03 +0000, Fredrik Svensson via lists.openembedded.org wrote:
> The checkstatus() path reuses cached connections for HTTP requests, but
> uses urllib's standard HTTPSHandler for HTTPS. Each HTTPS availability
> check therefore creates a new TCP connection and performs a new TLS
> handshake.
>
> Add HTTPS equivalents of the existing cached connection and request
> handler. Preserve the SSL context selected by BB_CHECK_SSL_CERTS and
> extend FetchConnectionCache keys so HTTPS connections are kept separate
> from HTTP connections, different certificate policies and CA files, and
> different proxy tunnels.
>
> Add a local TLS self-test which proves two HTTPS HEAD requests use one
> TCP/TLS connection. The test also verifies that a connection established
> with certificate checking disabled is not reused after checking is
> enabled.
>
> In an ABBA benchmark against BitBake master, 4,283 remote sstate
> availability misses averaged 761.639 seconds without this change and
> 254.742 seconds with it. This reduced the check by 66.55%, a 2.990x
> speedup. The benchmark had no matching mirror objects, so it isolates
> availability checks rather than download and unpack time.
>
> Signed-off-by: Fredrik Svensson <[email protected]>

Thanks for the patch, this looked good to me and we did merge it. We then started seeing:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/4378/steps/15/logs/stdio

which is probably worker specific and occuring on alma8 (which we do
use buildtools tarball on). Have you any idea why that might be
breaking?

Cheers,

Richard