The eSDK generation assumes that DL_DIR is downloads/ under the build directory,
and puts files such as a freshly buily uninative tarball in there expecting
bitbake will find it later.

Whilst ${TOPDIR}/downloads/ is in fact the default value for DL_DIR in
bitbake.conf, and any instances of DL_DIR are removed from the original
local.conf, there is still the possibility that other layers could contain a
site.conf that assigns DL_DIR.

If this happens the errors are quite mysterious as it fails to find the
uninative tarball and so the hashes all change, and eSDK building fails.

Ensure that this cannot happen by explicitly assigning the DL_DIR that we
require, instead of assuming that the default value will be used.

[ YOCTO #10439 ]

Signed-off-by: Ross Burton <>
 meta/classes/populate_sdk_ext.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
index ddf3962..0f0525d 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -282,6 +282,8 @@ python copy_buildsystem () {
             # Write a newline just in case there's none at the end of the 
+            f.write('DL_DIR = "${TOPDIR}/downloads"\n')
             f.write('INHERIT += "%s"\n' % 'uninative')
             f.write('UNINATIVE_CHECKSUM[%s] = "%s"\n\n' % 
(d.getVar('BUILD_ARCH', True), uninative_checksum))
             f.write('CONF_VERSION = "%s"\n\n' % d.getVar('CONF_VERSION', 

Openembedded-core mailing list

Reply via email to