| Summary: | devtool modify fails on kernel recipes when using a recipe space kernel-meta | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jaewon Lee <jaewon> |
| Component: | Scripts and Tools | Assignee: | Jaewon Lee <jaewon> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | alejandr, bluelightning, randy.macleod, ross.burton |
| Version: | unspecified | ||
| Target Milestone: | 2.6 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
After some debugging, we found that devtool-source.bbclass is moving local files to "oe-local-files" directory. The problem comes because in kernel-yocto.bbclass it's looking for the kmeta files in "${WORKDIR}/$f" when in this case it's actually in "${WORKDIR}/../oe-local-files/$f" (because devtool-source.bbclass moved it there)
If I change the code to look in that oe-local-files directory, or change devtool-source.bbclass to not move the kmeta files from workdir, the issue goes away.
There seems to be a patch that solves a very similar issue:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6e182aaa760c3be689e694e06d9ed0f4b66b1497
The problem remains after applying the patch however because the fix comes in after the
if not res:
raise DevtoolError('Extracting source for %s failed' % pn)
line that is raising the error.
res = tinfoil.build_targets(pn,
task,
handle_events=True)
and before this, the task is set to do_configure task if building kernel to make sure we are done with the source code and we can safely move everything to oe-local-files.
Usually this is okay on a normal kernel build because when we run do_configure we are not using any local files, but when we're using recipe space kernel-meta, do_kernel_configme is expecting the kernel to be in the recipe space.
We see two possible solutions: 1. create softlinks from oe-local-files to workdir before we call do_configure task. This would require calling tinfoil twice, once for do_validate_branches, (just to unpack the sources) create the symlinks, and once to call do_configure to create the .config for that kernel the other way is we avoid moving local files to oe-local-files only for the kernel (in devtool-source.bbclass). If required we can even populate the oe-local-files directory later after devtool extracts the source. Another option (maybe the simplest) is to add another check in kernel-yocto.bbclass when adding to includes:
elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
includes="$includes -I${WORKDIR}/../oe-local-files/$f"
which will add it from where devtool-source.bbclass moved it to in oe-local-files
Hello Jaewon, (In reply to comment #3) > Another option (maybe the simplest) is to add another check in > kernel-yocto.bbclass when adding to includes: > > elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then > includes="$includes -I${WORKDIR}/../oe-local-files/$f" > > which will add it from where devtool-source.bbclass moved it to in > oe-local-files Does this affect any other workflow?, will this not cause any problems for people NOT using a recipe space kernel-meta? Hi Alejandro, (In reply to comment #4) > Hello Jaewon, > > (In reply to comment #3) > > Another option (maybe the simplest) is to add another check in > > kernel-yocto.bbclass when adding to includes: > > > > elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then > > includes="$includes -I${WORKDIR}/../oe-local-files/$f" > > > > which will add it from where devtool-source.bbclass moved it to in > > oe-local-files > > Does this affect any other workflow?, will this not cause any problems for > people NOT using a recipe space kernel-meta? doesn't seem like it will because it's an elif at the end of the block |
Using recipe space kernel-meta for our kernel, for example: meta-my_bsp_layer/ `-- recipes-kernel `-- linux `-- linux-yocto |-- bsp-standard.scc |-- bsp.cfg `-- standard.cfg If you run devtool modify virtual/kernel, we are running into an error: ERROR: Could not generate configuration queue and in the logs we see that it's because it couldn't find the source kmeta files which are used as inputs to generate the kernel config.