Re: modify a kernel patch

[Frans Meulenbroeks <fransmeulenbroeks@gmail.com>]

2012/5/8 Bruce Ashfield <bruce.ashfield@windriver.com>:
> On 12-05-08 09:03 AM, Frans Meulenbroeks wrote:
>>
>> 2012/5/8 Bruce Ashfield<bruce.ashfield@windriver.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>:
>
>
> <snip>
>
>
>>>>
>>>> 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
>>>
>>
>> Bruce,
>>
>> Thanks for your help.
>> I'l try to make a small overlay based upon the standard de(throttling? Compression?, collecting?)nzil 7.0
>> layer and send you the diffs.
>> This will take a little bit of time as I want to verify here first
>> that this still has the problem.
>
>
> For anyone following along (all one of them), Frans and I have this
> working now. It was a missing export of GUILT_BASE. I just sent a patch
> to the list for it.
>
> Without that patch, here's what I did in devshell:
>
>
> Here's a log of what I did in devshell:
>
>  >  export GUILT_BASE=meta
>  >  guilt applied
> links/files/lm75.patch
> links/files/lm80.patch
> links/files/mpc8313e-rdb-cardbus.patch
> links/files/reboot.patch
> links/files/eeprom.patch
> links/files/do_mounts.patch
>
>  >  guilt push -f
> Applying patch..links/files/max7311.patch
> Checking patch drivers/gpio/max7311.c...
> Checking patch drivers/gpio/Kconfig...
> Hunk #2 succeeded at 199 (offset 63 lines).
> Checking patch drivers/gpio/Makefile...
> error: while searching for:
> obj-$(CONFIG_GPIO_SX150X)       += sx150x.o
> obj-$(CONFIG_GPIO_VX855)        += vx855_gpio.o
> obj-$(CONFIG_GPIO_ML_IOH)       += ml_ioh_gpio.o
>
> error: patch failed: drivers/gpio/Makefile:42
> Checking patch include/linux/max7311_gpio.h...
> Applied patch drivers/gpio/max7311.c cleanly.
> Applied patch drivers/gpio/Kconfig cleanly.
> Applying patch drivers/gpio/Makefile with 1 rejects...
> Rejected hunk #1.
> Applied patch include/linux/max7311_gpio.h cleanly.
> Patch applied.
>
>  > <resolve conflict> (I used wiggle), but it's a trivial fix
>
>  # guilt needs to know where the last commit is. When using guilt in
>  # development mode, it does autotagging. But while doing a build it
>  # doesn't. So we just tag the top:
>  > git tag standard/default/syrcxx_top
>  > guilt refresh
> Patch links/files/max7311.patch refreshed
>  >  cp meta/patches/standard/default/syrcxx/links/files/max7311.patch <your
> layer>
>  >  guilt push -a
> File series fully applied, ends at patch links/files/max7311.patch
>
> Cheers,
>
> Bruce

Bruce, thanks a lot for your help! Greatly appreciated!

I've verified this at work and noticed that things are not exactly
working as expected (although I was able to create a decent patch).
The max7311.patch I have sent to you also creates a few new files.
Apparently after a quilt refresh of my patch these new files do not
appear in the patch any more (but files that are modified are
updated). Guess this is because the new files are unknown to git.

It might be that it is better to add new files in a separate patch (or
maybe even with something like file://xx.c)
Not sure though as I am not an expert in this area.

Frans.