Bug 13808

Summary: do_task[noexec] = "" marks task noexec, which is inconsistent with docs
Product: [Build System, Metadata & Runtime] BitBake Reporter: Chris Laplante <mostthingsweb>
Component: bitbakeAssignee: Richard Purdie <richard.purdie>
Status: IN PROGRESS IMPLEMENTATION --- QA Contact:
Severity: normal    
Priority: Medium+ CC: hiago, kergoth, michael.opdenacker, mostthingsweb, poky.bs.watcher, poky.watcher, randy.macleod, richard.purdie
Version: 3.0.1   
Target Milestone: 6.2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Chris Laplante 2020-02-21 20:23:49 UTC
The manual says that to make a task noexec, you need to set its noexec flag to "1". But as currently implemented, setting the flag to anything (including an empty string) will cause it to be noexec. This is problematic because it makes conditional noexec impossible (at least without an anonymous Python function), e.g.:

do_task[noexec] = "${@"1" if condition else ""}"

This is because getTasks (a local function inside add_tasks of lib/bb/build.py) only checks to see if the flag is present. It doesn't validate the contents.

This is also true of nostamp and fakeroot.

I suggest teaching getTasks to check for "1" for noexec, nostamp, and fakeroot, and reject other values.
Comment 1 Randy MacLeod 2020-02-27 15:45:50 UTC
Richard is concerned that this could break other layers. Have you tested a large collection of YP layer with a fix? A 3.1 fix is possible but we need to be reassured about the impact.
Comment 2 Chris Laplante 2020-02-27 15:52:31 UTC
(In reply to comment #1)
> Richard is concerned that this could break other layers. Have you tested a
> large collection of YP layer with a fix? A 3.1 fix is possible but we need
> to be reassured about the impact.

I have not. Perhaps for 3.1 we can "deprecate" it by adding a bb.warn when a noexec flag is set to anything other than "1"? This should give some visibility to how many recipes are actually relying on it. Then in 3.2 we could consider fixing it entirely.
Comment 3 Randy MacLeod 2020-02-28 17:49:05 UTC
Chris, I guess the next step is to send a patch that does the deprecation for 3.1 so see if anyone in the wider community objects.
Comment 4 Randy MacLeod 2021-04-29 15:47:40 UTC
Chris, did this happen ? If not please move to 3.4. -- Randy
Comment 5 Chris Laplante 2021-08-17 15:52:17 UTC
Sorry for the delay. The deprecation warning is implemented in master-next as of June 2nd, 2021. I would propose pushing out completely "fixing" this (namely, changing it so that setting to something other than '1' has no effect) until a later milestone to give people some time to migrate. Maybe 3.5 or 3.6?
Comment 6 Randy MacLeod 2022-11-03 15:14:52 UTC
Richard said he'd look at this bug.
Comment 7 Hiago De Franco 2026-02-22 21:39:10 UTC
Hello, I would like to work on this bug. I hit this warning and looks like something cool to work on, and for me to learn. Can anybody help me about the progress and the current situation?

Thanks