Message ID | 1476464668-18886-1-git-send-email-ross.burton@intel.com |
---|---|
State | Accepted |
Commit | bc2e6f5eab47e869dbc4a3eacfe759b9b1cacaee |
Headers | show |
diff --git a/meta/classes/populate_sdk_ext.bbclass b/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 original f.write('\n') + 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', False))
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 <ross.burton@intel.com> --- meta/classes/populate_sdk_ext.bbclass | 2 ++ 1 file changed, 2 insertions(+) -- 2.8.1 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core