Bug 9605

Summary: Extensible SDK installer fails if the local.conf used to build it contains variable in DL_DIR
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Henry Bruce <henry.bruce>
Component: devtools / tool chainAssignee: Paul Eggleton <bluelightning>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: meta.mr.watcher, meta.watcher
Version: 2.1   
Target Milestone: 2.2 M1   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
esdk preparing_build_system.log none

Description Henry Bruce 2016-05-06 17:52:37 UTC 
Created attachment 3169 [details]
esdk preparing_build_system.log

I built an extensible sdk with vanilla poky and MACHINE=quemx86.
In local.conf I set DL_DIR as follows:
YOCTODIR = "/home/hbruce/yocto"
DL_DIR ?= "${YOCTODIR}/downloads"

When I run resulting esdk installer I get the error
./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-2.1+snapshot.sh -d sdk
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.1+snapshot
===================================================================================
You are about to install the SDK to "/home/hbruce/Projects/esdk-test/sdk". Proceed[Y/n]? Y
Extracting SDK.....done
Setting it up...
Extracting buildtools...
Preparing build system...
ERROR: SDK preparation failed: see /home/hbruce/Projects/esdk-test/sdk/preparing_build_system.log

I have attached the log. See you can an error
OSError: [Errno 2] No such file or directory: '${YOCTODIR}/downloads/uninative/ea00bc964ab2e30b63ee696529f78640aff3f07e36e871d8e08d3bcc15de8061'

I can also see that the installer has created a directory ${YOCTODIR}
Comment 1 Henry Bruce 2016-05-06 21:29:17 UTC 
This behavior can be avoided by blacklisting DL_DIR (and SSTATE_DIR if it follows the same 'variable within a variable' pattern).

Add the following to local.conf
SDK_LOCAL_CONF_BLACKLIST_append = " DL_DIR SSTATE_DIR"

Thanks for Paul for the fix.
Comment 2 Paul Eggleton 2016-05-10 03:09:18 UTC 
I've sent a patch to blacklist this variable by default since it's the simplest way to handle this - in the much less likely event that someone does want to specify a relative DL_DIR that they *do* want to go into the eSDK, they can whitelist it at the same time.