All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Bryan Evenson <bevenson@melinkcorp.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Kernel patch is unpacked but not applied
Date: Thu, 27 Jun 2013 01:24:12 -0400	[thread overview]
Message-ID: <51CBCC7C.3080107@windriver.com> (raw)
In-Reply-To: <51CBB4A8.80200@windriver.com>

On 13-06-26 11:42 PM, Bruce Ashfield wrote:
> On 13-06-26 11:08 PM, Bryan Evenson wrote:
>> I am building a custom Linux kernel under poky-dylan and I am having
>> an issue with patches being unpacked but not applied.  I have two
>> layers that have a bbappend file for the kernel.  Generally, this is
>> what each bbappend file looks like:
>>
>> #First .bbappend
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>> COMPATIBLE_MACHINE_mach1 = "mach1"
>> COMPATIBLE_MACHINE_mach2 = "mach2"
>> SRC_URI_append_mach2 = " file://${MACHINE}/${KBRANCH}/0001-blah.patch \
>>      file://${MACHINE}/${KBRANCH}/0002-blah.patch \
>>      "
>>
>> # Increment the recipe revision
>> PRINC := "${@int(PRINC) + 1}"
>>
>> # Second .bbappend
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>> COMPATIBLE_MACHINE_mach1 = "mach1"
>> COMPATIBLE_MACHINE_mach2 = "mach2"
>> SRC_URI_append_mach2 = " file://${MACHINE}/${KBRANCH}/0003-blah.patch \
>>      file://${MACHINE}/${KBRANCH}/0004-blah.patch \
>>      "
>>
>> # Increment the recipe revision
>> PRINC := "${@int(PRINC) + 1}"
>>
>> All of the patch files are properly unpacked, but the last two patches
>> are not being applied.  If I open the devshell for the kernel (bitbake
>> -c devshell linux-yocto-custom) I can see in the git log that the
>> first patch set was applied.  The second patch set exists but is not
>> applied.  If I call "guilt push" repeatedly from the devshell, the
>> patches from the second set are cleanly applied.  My guess is that
>> something doesn't like the second SRC_URI_append call.  Any ideas on
>> how to fix it?
>
> It shouldn't matter. Let me try and set up something that reproduces the
> problem and get back to you.
>
> Strangely .. I'm actively debugging something similar here already, so I
> may be able to re-use it.
>
> Stay tuned.
>
> Out of curiosity, have you tried this on master ?

So I tried to recreate this on master, and things worked for me. Which
I figured would happen, since this will make it harder to fix ... and
that's how it always works out.

I created two layers, with four patches to the main linux Makefile. They
all add something to the description:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_append = " file://0001-makefile-one.patch \
                    file://0002-makefile-two.patch"
 
 

PRINC := "${@int(PRINC) + 1}"

and


FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " file://0003-makefile-three.patch \
                    file://0004-makefile-four.patch"
 
 

PRINC := "${@int(PRINC) + 1}"

.. and alas, the all were applied:

 > grep NAME Makefile
NAME = Displaced Humerus Anterior one two three four

....

Can you send me the exact names of your patches ? I'm wondering if
an already applied check is triggering and preventing the auto push.

Bruce

>
> Cheers,
>
> Bruce
>
>>
>> Thanks,
>> Bryan
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



  reply	other threads:[~2013-06-27  5:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27  3:08 Kernel patch is unpacked but not applied Bryan Evenson
2013-06-27  3:42 ` Bruce Ashfield
2013-06-27  5:24   ` Bruce Ashfield [this message]
2013-06-27 12:50     ` Bryan Evenson
2013-06-27 13:24       ` Bruce Ashfield
2013-06-27 15:19       ` Bruce Ashfield
2013-06-27 15:20       ` Bruce Ashfield
2013-06-27 15:41         ` Bryan Evenson
2013-06-27 16:39           ` Bruce Ashfield
2013-06-27 20:44           ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51CBCC7C.3080107@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=bevenson@melinkcorp.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.