All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: modify a kernel patch
Date: Tue, 8 May 2012 08:42:25 -0400	[thread overview]
Message-ID: <4FA914B1.3060602@windriver.com> (raw)
In-Reply-To: <CACW_hTbZze5nfCsuy097zUmyEs=0s6HT=y-q9af5fFd150bJRg@mail.gmail.com>

On 12-05-08 03:18 AM, Frans Meulenbroeks wrote:
> 2012/5/7 Bruce Ashfield<bruce.ashfield@windriver.com>:
>> On 12-05-07 03:29 PM, Frans Meulenbroeks wrote:
>>>
>>> 2012/5/7 Bruce Ashfield<bruce.ashfield@windriver.com>:
>>>>
>>>> On 12-05-07 10:41 AM, Frans Meulenbroeks wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Not sure what the best place is to mail this (the YP list or oe-core
>>>>> or oe-devel or ...)
>>>>> Apologies if this is the wrong place.
>>>>>
>>>>> The problem I'm facing is the following:
>>>>> I have a kernel with some additional drivers that are not upstreamed
>>>>> because they are very specifc.
>>>>> I'm moving from oe-classic to denzil and from 2.6.38 to 3.2.
>>>>> Now some of the patches do not apply any more.
>>>>> In oe-classic I would have gone to the kernel work dir, fix the issue,
>>>>> do a quilt refresh and copy the patch back (there is a patch that
>>>>> contains our driver)
>>>>> However, denzil uses guilt instead of quilt
>>>>>
>>>>> If I do a devshell of virtual/kernel and want to do with guilt what I
>>>>> used to do with quilt I run into a problem.
>>>>> guilt status says: Patches directory does not exist, try guilt-init
>>>>> and indeed there is no patches dir like there was in oe-classic
>>>>
>>>>
>>>>
>>>> Do you have guilt installed locally ? You are likely using the
>>>> native guilt. To keep patch lists separate on a per-branch basis
>>>> and to be able to capture them on th meta-branch, there are some
>>>> patches to guilt that move the patch directory location.
>>>
>>>
>>> Guilt natively complained about a mismatch with the git version (my
>>> work system is still ubuntu 10.04).
>>> If I do a bitbake -c devshell virtual/kernel and use guilt there, I
>>> get the error on the patches directory that I mentioned above.
>>> It was my idea that I then would get the oe version in my path but I
>>> did not really verify that. Then again under devshell I did not get
>>> complaints about the git version. Will verify this tomorrow (I have no
>>> access to the build system from here).
>>>>
>>>>
>>>> Are you working on top of linux-yocto-3.2 ? Or some other 3.2 tree ?
>>>
>>>
>>> I downloaded the denzil tarball from yoctoproject.com. I made some
>>> config changed and added a few local patches (bringing things over
>>> from my 2.6.38 oe-classic kernel).
>>>
>>> Should I have gotten a patches dir in my tmp/work/mymachine/linux* dir
>>> (I have my own machine mpc8313e based)
>>
>>
>> The patches are pulled underneath the kernel tree itself, so that
>> they can be incorporated with other git manipulations of the tree
>> and shared as appropriate.
>>
>> So the patches directory exists in ${S}/meta/patches/$branch_name
>>
> Ok found that dir. However....
> It is still not clear to me how to use this though.
>
> What I did was start a devshell for virtual/kernel.
> Within the devshell guilt is in the path, but still it does not work
> (I also tried invoking guilt with the full path).
>  From my devshell window:
>
> frans@frans-desktop:~/poky-denzil-7.0-build/tmp/work/syrcxx-poky-linux-uclibc/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.23/linux$
> which guilt
> /home/frans/poky-denzil-7.0-build/tmp/sysroots/x86_64-linux/usr/bin/guilt
> frans@frans-desktop:~/poky-denzil-7.0-build/tmp/work/syrcxx-poky-linux-uclibc/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.23/linux$
> /home/frans/poky-denzil-7.0-build/tmp/sysroots/x86_64-linux/usr/bin/guilt
> status
> Patches directory doesn't exist, try guilt-init
>
> This is with the standard denzil 7.0 release.
>
> I've also been to the meta/patches dir and tried guilt status in there
> but to no avail.
> (or should I have manually made a symlink or so

There's nothing extra that should have to be done, I use guilt during patch
carry forward and tree generation, it's simply a matter of a few
environment variables.

That being said, I've largely replaced guilt with mbox manipulations,
so I'm a bit concerned about bit rot.

Is there any way you can get me access to your layer and patches ?
A simple test run is probably the easiest way for me to see what's
happened.

>
> Not sure what I am doing wrong.
> Is there a small example or some doc on how to do this? or can someone
> give a few commands that would show how to modify an existing patch
> (or create a new one) with patch?

There are docs, but if guilt next, or guilt push -f aren't working, they
won't be of much use.

> (btw noticed that the patches are also in
> .git/refs/patches/...
> however the guilt doc says:
> In Guilt, all the patches are stored in .git/patches/$branch/, where $branch ...

That's an unmodified guilt, you can't commit and track the series if you
let guilt store information under .git, so I created a variable and
relocated it.

>
> Also tried to add a symlink from .git/patches to .git/refs/patches but
> that did not help either.
>
> Thanks for any suggestion!

I can easily give you the raw git commands to make this work, but the guilt
path is supposed to be the gentle entry to the process. We need to
diagnose what is happening .. and I need to see it happen in front of
me, so I can try a few things.

Cheers,

Bruce

> Frans



  reply	other threads:[~2012-05-08 12:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 14:41 modify a kernel patch Frans Meulenbroeks
2012-05-07 14:48 ` Bruce Ashfield
2012-05-07 19:29   ` Frans Meulenbroeks
2012-05-07 19:36     ` Bruce Ashfield
2012-05-08  7:18       ` Frans Meulenbroeks
2012-05-08 12:42         ` Bruce Ashfield [this message]
2012-05-08 13:03           ` Frans Meulenbroeks
2012-05-08 13:22             ` Bruce Ashfield
2012-05-08 19:20             ` Bruce Ashfield
2012-05-08 22:40               ` Autif Khan
2012-05-09  1:12                 ` Bruce Ashfield
2012-05-09  4:31                   ` Khem Raj
2012-05-09 14:11               ` Frans Meulenbroeks
2012-05-09 14:14                 ` Bruce Ashfield
2012-05-09 14:27                   ` Frans Meulenbroeks
2012-05-09 14:40                     ` 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=4FA914B1.3060602@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=fransmeulenbroeks@gmail.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.