11649 2017-06-12 23:17:47 +0000 kernel-yocto.bbclass doesn't catch missing config.queue 2017-08-16 00:54:45 +0000 1 1 6 Yocto Project Subprojects Kernel kernel-configuration 2.2 x86 Multiple RESOLVED FIXED Backport to 2.3.1 & 2.2.2 Medium normal 2.4 M4 1 klapperichpaul bruce.ashfield yp.kernel.watcher yp.watcher --- --- Don't know oldest_to_newest 74033 0 klapperichpaul 2017-06-12 23:17:47 +0000 kernel-yocto.bbclass contains the following lines: meta_dir=$(kgit --meta) configs="$(scc --configs -o ${meta_dir})" if [ -z "${configs}" ]; then bbfatal_log "Could not find configuration queue (${meta_dir}/config.queue)" fi My $(meta_dir) didn't contain a config.queue and I should have been show the error in the if statement above. Unfortunately, scc produces the helpful output: [ERROR]: no configuration queue found in outdir (.kernel-meta) Since this gets stored in the configs variable, the -z test fails and the error is not shown. Instead a different error is thrown later on when the bad ${configs} is used. scc does return an exit status of 1 in this case. Thus I think kernel-yocto.bbclass should be changed to meta_dir=$(kgit --meta) configs="$(scc --configs -o ${meta_dir})" if [ $? -ne 0 ]; then bbfatal_log "Could not find configuration queue (${meta_dir}/config.queue)" fi Alternatively, maybe it would be good to test for the existence of '${meta_dir}/config.queue' 74038 1 bruce.ashfield 2017-06-13 07:20:55 +0000 That is indeed the right fix, catching the error twice .. but not reporting it properly once. I'll tweak the fix slightly to check the error code and then propagate the scc error message directly, but otherwise, it is the same. 75876 2 bruce.ashfield 2017-08-16 00:54:45 +0000 commit aa7fc34dc4c07c3e22539249999282dd6b3cf1e6 Author: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Tue Jun 13 03:26:17 2017 -0400 kernel-yocto: propagate configuration errors to bbclass As pointed out by klapperichpaul@johndeere.com, missing configuration fragments were being picked up twice, once by the tools and once by the bbclass. Unfortunately, the tools error message was being detected as configs, and hence no error was reported at all. Rather than catching the output of the tools, we can instead check the return code and propagate the error message from the tools directly to the user. [YOCTO #11649] (From OE-Core rev: 960652416e2390337df6d9734375d6829ceb6420) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>