[yocto] force flag and taint logging

Paul Eggleton paul.eggleton at linux.intel.com
Tue Jan 27 10:36:36 PST 2015


Hi Ezekiel,

On Tuesday 27 January 2015 10:50:03 ezekiel at sanborndeasis.net wrote:
> Since picking up Dizzy I have noticed 
> 
> "... is tainted from a forced run"
> 
> log line appears to stick forever once I have forced a fetch or compile on a
> component. The change to bring this in is here:
> 
> https://code.amazon.com/packages/Zeus-poky/commits/60c40e5db57da094ab5ecfadf
> 8e07dc6251bec66 
> 
> It appears to me that the resultant taint file for a component, once made,
> never goes away.  It only effectively forces a fetch or recompile once, but
> the file itself remains. So in effect, with the new log message, once I
> taint a task I will forever see this log message even though it does not
> appear to actually do anything.
> 
> In other words, from core image-minimal
> 
> $ bitbake zlib -f -c fetch
> $ bitbake zlib
> 
> ---> at this stage I see the log and I see all the dependent tasks of fetch
> rerun as expected. WARNING:  .../meta/recipes-core/zlib_1.2.8.bb.do_fetch
> is tainted from a forced run
> 
> ---> but if I bitbake zlib again, zlib has already been built post the force
> fetch, so I dont see bitbake actually rebuild anything. BUT I still get the
> warning message. The warning message fires based on the presence of the
> taint file and it is still there in he component folder within stamps. $
> bitbake zlib
> 
> WARNING:  .../meta/recipes-core/zlib_1.2.8.bb.do_fetch is tainted from a
> forced run
> 
> Is there something I am missing here? It appears to be a misleading log
> message.

When you force a task, the means by which we do that is adjusting (tainting) 
the task's signature; this is so that other tasks that depend upon that tasks 
also get forced to re-execute, which is almost always what you want. However, 
unless you want those other tasks to just spring back to the previous output 
on the next build, that tainted state needs to be preserved across builds, so 
it doesn't go away, no. The only way to get rid of it is to do a clean on the 
recipe e.g. bitbake -c clean zlib. I'll grant you that this is not obvious and 
it's arguable that the tainted state should possibly go away if the task re-
executes by itself. (The idea of this being a "taint" and the need for a 
warning stems from the usage where you're modifying some intermediate state of 
the build e.g. temporary source code in the workdir, and then re-running the 
task with -f, in which case the result of the build is potentially not 
reproducible from the metadata).

The question I would have is, why do you feel the need to force the task in 
this case, particularly with a task like do_fetch? In general I view -f (and 
also -C) as something you use when the system's normal ability to figure out 
task dependencies hasn't worked, and thus it ought to be viewed more as a 
debugging tool, but I may be missing what you're trying to do.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the yocto mailing list