[OE-core] linux-yocto.do_validate_branches failing since last oe-core update

[Martin Jansa]

Yesterday I've deleted all workspaces where I was getting this error and
since then I haven't seen one.

So maybe the key to reproduce this was to run builds without the fix
applied and then apply the fix and execute another build without removing
the tmp-glibc (so that it tries to do incremental build from the bad state
created before without this fix).

On Wed, Apr 26, 2017 at 2:45 PM, Bruce Ashfield <bruce.ashfield at gmail.com>
wrote:

>
>
> On Wed, Apr 26, 2017 at 8:25 AM, Burton, Ross <ross.burton at intel.com>
> wrote:
>
>> Not sure if it's related to this problem, but this happened in selftest
>> last night:
>>
>> Log data follows:
>> | DEBUG: Executing shell function do_kernel_metadata
>> | ERROR: Could not generate configuration queue for qemux86.
>> | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-
>> selftest/build/build/tmp/work/qemux86-poky-linux/linux-
>> yocto/4.10.9+git999-r0/temp/run.do_kernel_metadata.37215: line 190: spp:
>> command not found
>>
>> | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-
>> selftest/build/build/tmp/work/qemux86-poky-linux/linux-
>> yocto/4.10.9+git999-r0/temp/run.do_kernel_metadata.37215: line 191:
>> kgit: command not found
>>
>> | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-
>> selftest/build/build/tmp/work/qemux86-poky-linux/linux-
>> yocto/4.10.9+git999-r0/temp/run.do_kernel_metadata.37215: line 197: scc:
>> command not found
>>
>> | ERROR: Function failed: do_kernel_metadata (log file is located at
>> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-
>> selftest/build/build/tmp/work/qemux86-poky-linux/linux-
>> yocto/4.10.9+git999-r0/temp/log.do_kernel_metadata.37215)
>>
>
>
> Not related to the patching error, but related to my change where I
> modified
> the native depends.  For whatever reason that ran before the
> do_validate_branches,
> which is what pulls in the dependency.
>
> I can't think of how that could happen, but there seems to be some tasks
> that are now racing.
>
> I'll revisit the patch and put the dependency in both places just to be
> sure.
>
> Bruce
>
>
>>
>>
>> Ross
>>
>> On 25 April 2017 at 14:17, Bruce Ashfield <bruce.ashfield at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 9:09 AM, Richard Purdie <
>>> richard.purdie at linuxfoundation.org> wrote:
>>>
>>>> On Mon, 2017-04-24 at 21:06 -0400, Bruce Ashfield wrote:
>>>> > On Mon, Apr 24, 2017 at 5:27 PM, Richard Purdie
>>>> > <richard.purdie at linuxfoundation.org> wrote:
>>>> > > On Mon, 2017-04-24 at 15:56 -0400, Bruce Ashfield wrote:
>>>> > > >
>>>> > > >
>>>> > > > On Mon, Apr 24, 2017 at 9:54 AM, Bruce Ashfield <bruce.ashfield at g
>>>> > > mail
>>>> > > > .com> wrote:
>>>> > > > >
>>>> > > > >
>>>> > > > > On Mon, Apr 24, 2017 at 9:39 AM, Martin Jansa <martin.jansa at gma
>>>> > > il.c
>>>> > > > > om> wrote:
>>>> > >
>>>> > > >
>>>> > > > Richard/Ross: are you seeing this same thing on the autobuilder ?
>>>> > > >
>>>> > > > There's some incantation or config that I'm missing, I assume
>>>> > > this is
>>>> > > > a straight qemux86 config
>>>> > > > with a bitbake of something like core-image-minimal ?
>>>> > >
>>>> > > We're not seeing this on the autobuilders. I do suspect something
>>>> > > in
>>>> > > the handling of extra patches or cfg fragments from SRC_URI if I
>>>> > > had to
>>>> > > guess. That certainly was the trigger last time I saw this.
>>>> > Yah, that's the kicker, I'm still carrying your patch for binfmt_elf,
>>>> > and I added two of my own
>>>> > + config fragments, and I can't trigger anything.
>>>>
>>>> I managed to reproduce breakage. With master and my separate patch in
>>>> SRC_URI:
>>>>
>>>>
>>> This particular issue should be fixed with with patch I sent, late
>>> Friday night:
>>>
>>> [OE-core] [PATCH] kernel-yocto/kern-tools: fix do_validate_branches
>>> clean stage
>>>
>>> Martin applied it to his builds and is still seeing an issue in the
>>> actual patching phase.
>>> I'm currently not able to reproduce it.
>>>
>>> If you do have that patch applied, I'm definitely interested. If you
>>> don't, and have two
>>> minutes to re-run with that applied .. I'd be interested to hear if the
>>> build works after
>>> that.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>> $ bitbake linux-yocto
>>>> $ bitbake linux-yocto -c kernel_checkout -f
>>>> $ bitbake linux-yocto
>>>>
>>>> ERROR: linux-yocto-4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0
>>>> do_validate_branches: Function failed: do_validate_branches (log file is
>>>> located at /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/linu
>>>> x-yocto/4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0/temp/log.
>>>> do_validate_branches.116726)
>>>> ERROR: Logfile of failure stored in: /media/build1/poky/build/tmp/w
>>>> ork/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e
>>>> 885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726
>>>> Log data follows:
>>>> | DEBUG: Executing shell function do_validate_branches
>>>> | HEAD is now at fe0fb8d Merge tag 'v4.10.9' into standard/base
>>>> | 1493125671.284715: mkdir: cannot create directory ‘.’: File exists
>>>> | 1493125671.370592:
>>>> | 1493125671.3742917: [ERROR] Can't find patch dir at
>>>> ./patches/standard/base
>>>> | 1493125671.3742917: usage: kgit s2q
>>>> | 1493125671.3743172: WARNING: exit code 1 from a shell command.
>>>> | 1493125671.3745801: ERROR: Function failed: do_validate_branches (log
>>>> file is located at /media/build1/poky/build/tmp/w
>>>> ork/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e
>>>> 885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726)
>>>>
>>>> Cheers,
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>>
>>
>>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170427/0dbd59da/attachment-0002.html>