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

[Bruce Ashfield]

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 gmail
> > .com> wrote:
> > >
> > >
> > > On Mon, Apr 24, 2017 at 9:39 AM, Martin Jansa <martin.jansa at gmail.c
> > > om> wrote:
> > > > I'm still seeing this with your "kernel-yocto/kern-tools: fix
> > > > do_validate_branches clean stage" patch applied:
> > > >
> > > >
> > > > | DEBUG: Executing shell function do_patch
> > > > | ERROR: Could not apply patches for qemux86.
> > > > | ERROR: Patch failures can be resolved in the linux source
> > > > directory work-shared/qemux86/kernel-source)
> > > > |
> > > > | [ERROR] Can't find patch dir at .kernel-meta/
> > > > | usage: kgit s2q
> > > > | ERROR: Function failed: do_patch (log file is located at linux-
> > > > yocto/1_4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-
> > > > r0/temp/log.do_patch.44497)
> > > > NOTE: recipe linux-yocto-
> > > > 1_4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0: task do_patch:
> > > > Failed
> > > >
> > > Well bugger.
> > >
> > > I'll start another set of builds.
> > >
> > I had this on a build loop all day without any luck. I also enlisted
> > a few others around the office
> > to build master and see if they could cause an issue .. again, no
> > luck.
> >
> > 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.

Bruce

gmail garbled and and paste below:

-------------------


% git describe

v4.10.9-378-gff739b66b0bc


% git whatchanged

commit ff739b66b0bc5cd65bcc26d4556736309f4b180c

Author: Bruce Ashfield <bruce.ashfield at windriver.com>

Date:   Fri Jul 8 11:32:11 2016 -0400


    makefile: comment two


    Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>


:100644 100644 a027ca58d9ff... 2402e34170b5... M        Makefile


commit 238fd7383ebb99f080febdfb31d680b43fbb7438

Author: Bruce Ashfield <bruce.ashfield at windriver.com>

Date:   Fri Jul 8 11:31:34 2016 -0400


    makefile: comment one



    Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>


:100644 100644 3d994e6df89a... a027ca58d9ff... M        Makefile


commit 5376026f981849bee7d1789c67b81e1e758ef6f0

Author: invalid_git config <unknown at unknown>

Date:   Mon Apr 24 20:48:24 2017 -0400


    The kernel makes the assumption that all PT_LOAD sections are
continous, at

    least to the point where PT_PHDR is contained. If there are holes
between

    the PT_LOAD sections, the calculation load_addr + exec->e_phoff fails to

    correctly locate the phdrs.



    This change notices where phdrs are located in some other PT_LOAD
section

    other than the first one and corrects the offsets used.



    This is useful where userspace wants to rewrite elf files but can't
guarantee

    that all PT_LOAD sections are continuous without holes without
potentially

    creating large holes in the binaries. I was unable to find any ELF spec

    which requires continuous PT_LOAD sections or that PT_PHDR be in the
first

    PT_LOAD section.



    Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>


:100644 100644 422370293cfd... 392dab375b63... M        fs/binfmt_elf.c
-------------------


>
> Cheers,
>
> Richard
>



-- 
"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/20170424/24a90d96/attachment-0002.html>