On Thu, Apr 27, 2017 at 12:32 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> 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). > Interesting. Thanks for letting me know .. I'll try and set up the same steps here. I was worried that all your build were still breaking on this, and yet I couldn't make it happen. Hopefully this will lead me to the root cause. Bruce > > On Wed, Apr 26, 2017 at 2:45 PM, Bruce Ashfield <bruce.ashfi...@gmail.com> > wrote: > >> >> >> On Wed, Apr 26, 2017 at 8:25 AM, Burton, Ross <ross.bur...@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-se >>> lftest/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-se >>> lftest/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-se >>> lftest/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-se >>> lftest/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.ashfi...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Tue, Apr 25, 2017 at 9:09 AM, Richard Purdie < >>>> richard.pur...@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.pur...@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@g >>>>> > > mail >>>>> > > > .com> wrote: >>>>> > > > > >>>>> > > > > >>>>> > > > > On Mon, Apr 24, 2017 at 9:39 AM, Martin Jansa <martin.jansa@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/w >>>>> ork/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e >>>>> 885015_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" >> > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core