[OE-core] [PATCH 3/4] kern-tools: fix processing for no branch meta-data

[Patrick Ohly]

On Fri, 2016-12-02 at 16:09 -0500, Bruce Ashfield wrote:
> Lernel meta-data that has patches, but no branches, can trigger an
> error due to no branch specific patch queue.
> 
> This error then cascades to more issues since the tools are using
> a named file in /tmp to store and display error messages to the
> user.
> 
> We fix both issues though the following kern tools tweaks:
> 
>   commit bd9e1d6c9b0a34ff3e19a06999aaf57ffadfd04c
>   Author: Bruce Ashfield <bruce.ashfield at windriver.com>
>   Date:   Fri Dec 2 13:09:40 2016 -0500
> 
>     scc: use mktemp for consolidated output capture
> 
>     To provide useful error messages the tools dump pre-processed
>     files and messages to a temporary file. If multiple users are
>     doing builds, this means they either race, or can have permissions
>     issues.
> 
>     By creating the temporary file via mktemp, we avoid both issues.
>     (We also make sure to clean these up on exit, or /tmp will get
>     polluted quickly).
> 
>   commit a287da4bfe0b4acb8f2b0627bd8e7abd1a1dde26
>   Author: Bruce Ashfield <bruce.ashfield at windriver.com>
>   Date:   Fri Dec 2 13:08:08 2016 -0500
> 
>     patch: do not assume a branch specific patch queue is needed
> 
>     When processing input files per-branch and global patch queues are
>     generated. If the meta-data has not created any branches in the
>     repo, no branch specific queue is required.
> 
>     The tools assumed that one is always valid, and hence would throw a
>     non-zero exit code and stop processing.
> 
>     By testing for a named per-branch queue, we avoid this issue.

Ostro OS runs into the problem while trying to use current OE-core
master:

 .../patch.cmd: line 29: : No such file or directory

| ERROR: Function failed: do_kernel_metadata (log file is located ...)

This commit here fixed it for me. I see that it is already in Ross' mut2
branch, so hopefully that'll land in master soon.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.