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

Thanks, the new output makes the problem clearer.

The buildtools OpenSSL is trying to load its configuration from the
original SDK build path:

/usr/local/oe-sdk-hardcoded-buildpath/.../openssl.cnf

It looks like enable_tools_tarball() adds the buildtools binaries to
PATH, but does not source the scripts under environment-setup.d. The
OPENSSL_CONF value is set by environment-setup.d/openssl.sh, so
OpenSSL falls back to its compiled-in path instead.

I reproduced the same error with the 5.1 buildtools tarball when using
its OpenSSL without sourcing the complete environment. It works when
the environment is sourced normally.

I think the proper fix is for enable_tools_tarball() to import the complete
sourced environment, including the environment-setup.d scripts.

That would also explain why running the test manually over SSH works. I
think this is an issue with how yocto-autobuilder-helper imports the
buildtools environment, rather than with the BitBake HTTPS cache change.

Kind regards
Fredrik

________________________________
From: Richard Purdie <[email protected]>
Sent: Friday, August 14, 2026 11:24 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

On Fri, 2026-08-14 at 20:12 +0000, Fredrik Svensson via lists.openembedded.org wrote:
> 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.

Thanks, I applied it and the result was:

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

which suggests buildtools isn't working quite right. What is odd is
that if I ssh in and run that bitbake-selftest command on the same
build directory, it works and doesn't show the error. I'm not quite
sure what is going on here...

Cheers,

Richard