All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Beckerus <hans.beckerus@gmail.com>
To: Jerrod Peach <peachj@lexmark.com>
Cc: yocto <yocto@yoctoproject.org>
Subject: Re: Problem with applying a patch using default -pnum
Date: Thu, 07 Mar 2013 20:43:24 +0100	[thread overview]
Message-ID: <5138EDDC.70403@gmail.com> (raw)
In-Reply-To: <CA+QkY1Bbstb5N=8fC-LSfS6c1xVaW39+rkLHcJtHT-Fonba+vQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]

On 2013-03-07 8:11, Jerrod Peach wrote:
> Hans,
>
> Are you sure you're seeing the patch system use $WORKDIR instead of $S 
> as the root for patching?  I've had to do a lot of patching in our own 
> layers recently and I've always seen $S used as the root for the 
> patch.  Are you explicitly setting S = "${WORKDIR}/git"?  That's what 
> we do for our git recipes.  That's how you get the system to recognize 
> the source somewhere other than just $WORKDIR.
>
> As for specifying a different -pnum, you absolutely can do that like so:
>
> /SRC_URI += "file://my-change.patch*;striplevel=X*"/
>
> X is the pnum that you want.  Its default value is 1.
>
> You may also find this page useful -- it contains all sorts of hints 
> for setting up your recipes in a Yocto-standard way:
>
> https://wiki.yoctoproject.org/wiki/Recipe_&_Patch_Style_Guide
>
> That's where I learned about striplevel and the preference for it over 
> the deprecated pnum parameter.
>
> Kind regards,
>
> Jerrod
>
>
Hi Jarod. Thanks, the pointer you gave will most certainly be of great 
aid. I will try the striplevel approach
instead of writing my own do_patch() override.
Regarding how certain I am that the root folder is ${WORKDIR} when 
patching, not at all ;)
In my do_patch() function is simply did `pwd` and it was not set to ${S} 
as I set it to.
That does not mean that the built-in patch system is using ${WORKDIR}, I 
am aware of that.
Things here is, even though my patch is placed in ${W} and I set ${S} to 
eg. ${W}/git/some/folder,
why would it not work? In another package I set ${S} to ${WORKDIR}/git 
and it works
just fine. I can not understand why setting ${S} to something else 
breaks the logic?
It's not that bitbake can not find the patch file, it definitely does 
that, but the -pnum seems to get
messed up. But maybe that is the whole point of having the striplevel=X 
in the first place.

Hans


>
>
>
>
> On Thu, Mar 7, 2013 at 7:33 AM, Hans Beckérus <hans.beckerus@gmail.com 
> <mailto:hans.beckerus@gmail.com>> wrote:
>
>     On Thu, Mar 7, 2013 at 1:12 PM, Hans Beckérus
>     <hans.beckerus@gmail.com <mailto:hans.beckerus@gmail.com>> wrote:
>     > Hi. More problems ;)
>     > I have a patch file that needs to be applied to a source tree
>     and the
>     > patch file is copied properly to the ${WORKDIR} directory.
>     > So far so good. But, the problem with this source tree is that it is
>     > not built from the traditional root folder of the repo.
>     > This means I need to change ${S} to point somewhere else. This also
>     > causes the patch system to fail!
>     > I did an override of do_patch() in my .bb and that seems to
>     work, but
>     > I do not like to use overrides unless I really have to.
>     > So basically, is there some way to tell the built-in patch system to
>     > use a different -pnum value?
>     > If there is, I could stick with the do_patch() as provided by
>     default.
>     >
>     > Hans
>
>     Hmm, ok a correction from my side. Forget parts of what I said ;)
>     The patch system does not seem to use the value of ${S}, it is using
>     ${WORKDIR} as the root for patching, this is also where the patch file
>     is placed. The problem in my case does not seem to be that is built
>     from a non-standard path. The reason why it fails seems to be because
>     the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git. The
>     patch file does include git as part of the source path for obvious
>     reasons. What am I doing wrong? Having actual source code in
>     ${WORKDIR}/git I assume is very common for git based downloads.
>
>     Hans
>     _______________________________________________
>     yocto mailing list
>     yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>     https://lists.yoctoproject.org/listinfo/yocto
>
>


[-- Attachment #2: Type: text/html, Size: 7109 bytes --]

  reply	other threads:[~2013-03-07 19:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07 12:12 Problem with applying a patch using default -pnum Hans Beckérus
2013-03-07 12:33 ` Hans Beckérus
2013-03-07 19:11   ` Jerrod Peach
2013-03-07 19:43     ` Hans Beckerus [this message]
2013-03-07 21:01       ` Jerrod Peach
2013-03-07 21:22         ` Hans Beckerus
2013-03-07 18:14 ` Paul Eggleton
  -- strict thread matches above, loose matches on Subject: below --
2013-03-08  1:49 Daniel Lazzari
2013-03-08 17:10 ` Hans Beckérus

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=5138EDDC.70403@gmail.com \
    --to=hans.beckerus@gmail.com \
    --cc=peachj@lexmark.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.