* modify a kernel patch @ 2012-05-07 14:41 Frans Meulenbroeks 2012-05-07 14:48 ` Bruce Ashfield 0 siblings, 1 reply; 16+ messages in thread From: Frans Meulenbroeks @ 2012-05-07 14:41 UTC (permalink / raw) To: yocto 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 Hence my question: What is a good workflow to modify a kernel patch. Or, what magic incantation do I need to give to guilt to make it working. Any suggestion is greatly appreciated. Have fun! Frans. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 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 0 siblings, 1 reply; 16+ messages in thread From: Bruce Ashfield @ 2012-05-07 14:48 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto 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. Are you working on top of linux-yocto-3.2 ? Or some other 3.2 tree ? > > Hence my question: > What is a good workflow to modify a kernel patch. > Or, what magic incantation do I need to give to guilt to make it working. See above. Bruce > > Any suggestion is greatly appreciated. > > Have fun! > Frans. > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-07 14:48 ` Bruce Ashfield @ 2012-05-07 19:29 ` Frans Meulenbroeks 2012-05-07 19:36 ` Bruce Ashfield 0 siblings, 1 reply; 16+ messages in thread From: Frans Meulenbroeks @ 2012-05-07 19:29 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto 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) > > >> >> Hence my question: >> What is a good workflow to modify a kernel patch. >> Or, what magic incantation do I need to give to guilt to make it working. > > > See above. > > Bruce > Thanks! Frans ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-07 19:29 ` Frans Meulenbroeks @ 2012-05-07 19:36 ` Bruce Ashfield 2012-05-08 7:18 ` Frans Meulenbroeks 0 siblings, 1 reply; 16+ messages in thread From: Bruce Ashfield @ 2012-05-07 19:36 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto 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 Cheers, Bruce >> >> >>> >>> Hence my question: >>> What is a good workflow to modify a kernel patch. >>> Or, what magic incantation do I need to give to guilt to make it working. >> >> >> See above. >> >> Bruce >> > Thanks! Frans ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-07 19:36 ` Bruce Ashfield @ 2012-05-08 7:18 ` Frans Meulenbroeks 2012-05-08 12:42 ` Bruce Ashfield 0 siblings, 1 reply; 16+ messages in thread From: Frans Meulenbroeks @ 2012-05-08 7:18 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto 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 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? (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 ... Also tried to add a symlink from .git/patches to .git/refs/patches but that did not help either. Thanks for any suggestion! Frans ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-08 7:18 ` Frans Meulenbroeks @ 2012-05-08 12:42 ` Bruce Ashfield 2012-05-08 13:03 ` Frans Meulenbroeks 0 siblings, 1 reply; 16+ messages in thread From: Bruce Ashfield @ 2012-05-08 12:42 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-08 12:42 ` Bruce Ashfield @ 2012-05-08 13:03 ` Frans Meulenbroeks 2012-05-08 13:22 ` Bruce Ashfield 2012-05-08 19:20 ` Bruce Ashfield 0 siblings, 2 replies; 16+ messages in thread From: Frans Meulenbroeks @ 2012-05-08 13:03 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto 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>: >>>>> >>>>> >>>>> 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 ker> > Cheers > > Belen > > > On 08/05/2012 13:23, "Frans Meulenbroeks" <fransmeulenbroeks@gmail.com> > wrote: > >>2012/5/8 Barros Pena, Belen <belen.barros.pena@intel.com>: >>> Hi Frans, >>> >>> Thank you so much for agreeing to talk to us. Outside working hours >>>should >>> be no problem. What time would be good for you? >>> >>> >>> If you are ok with it, I'd like to record our conversation: it means I >>> don't need to take lots of notes and I can focus on talking to you. >>>Using >>> Skype makes the recording easier: would you mind if we use that instead >>>of >>> the phone? My Skype ID is belenbarrospena. >>> >>> All the best, >>> >>> Belen >>> >>> >>Hi Belen, >> >>Recording is no problem. Tonight I'm a little bit low on time, but I >>think tomorrow evening I'm fairly flexible (this may still change >>though, my life is sometimes somewhat hectic). >>20.30 or so will probably work for me, but if you prefer earlier or >>later that is also probably no problem. >>And recording is also no problem. >> >>Best regards, Frans > > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > nel 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). >>>>> >>>>> >>>>>> > Cheers > > Belen > > > On 08/05/2012 13:23, "Frans Meulenbroeks" <fransmeulenbroeks@gmail.com> > wrote: > >>2012/5/8 Barros Pena, Belen <belen.barros.pena@intel.com>: >>> Hi Frans, >>> >>> Thank you so much for agreeing to talk to us. Outside working hours >>>should >>> be no problem. What time would be good for you? >>> >>> >>> If you are ok with it, I'd like to record our conversation: it means I >>> don't need to take lots of notes and I can focus on talking to you. >>>Using >>> Skype makes the recording easier: would you mind if we use that instead >>>of >>> the phone? My Skype ID is belenbarrospena. >>> >>> All the best, >>> >>> Belen >>> >>> >>Hi Belen, >> >>Recording is no problem. Tonight I'm a little bit low on time, but I >>think tomorrow evening I'm fairly flexible (this may still change >>though, my life is sometimes somewhat hectic). >>20.30 or so will probably work for me, but if you prefer earlier or >>later that is also probably no problem. >>And recording is also no problem. >> >>Best regards, Frans > > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > >>>>> 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 > Bruce, Thanks for your help. I'l try to make a small overlay based upon the standard denzil 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. Best regards, Frans ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-08 13:03 ` Frans Meulenbroeks @ 2012-05-08 13:22 ` Bruce Ashfield 2012-05-08 19:20 ` Bruce Ashfield 1 sibling, 0 replies; 16+ messages in thread From: Bruce Ashfield @ 2012-05-08 13:22 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto 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>: >>>>>> >>>>>> >>>>>> 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 ker> >> Cheers >> >> Belen >> >> >> On 08/05/2012 13:23, "Frans Meulenbroeks"<fransmeulenbroeks@gmail.com> >> wrote: >> >>> 2012/5/8 Barros Pena, Belen<belen.barros.pena@intel.com>: >>>> Hi Frans, >>>> >>>> Thank you so much for agreeing to talk to us. Outside working hours >>>> should >>>> be no problem. What time would be good for you? >>>> >>>> >>>> If you are ok with it, I'd like to record our conversation: it means I >>>> don't need to take lots of notes and I can focus on talking to you. >>>> Using >>>> Skype makes the recording easier: would you mind if we use that instead >>>> of >>>> the phone? My Skype ID is belenbarrospena. >>>> >>>> All the best, >>>> >>>> Belen >>>> >>>> >>> Hi Belen, >>> >>> Recording is no problem. Tonight I'm a little bit low on time, but I >>> think tomorrow evening I'm fairly flexible (this may still change >>> though, my life is sometimes somewhat hectic). >>> 20.30 or so will probably work for me, but if you prefer earlier or >>> later that is also probably no problem. >>> And recording is also no problem. >>> >>> Best regards, Frans >> >> --------------------------------------------------------------------- >> Intel Corporation (UK) Limited >> Registered No. 1134945 (England) >> Registered Office: Pipers Way, Swindon SN3 1RJ >> VAT No: 860 2173 47 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> > > nel 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). >>>>>> >>>>>> >>>>>>> >> Cheers >> >> Belen >> >> >> On 08/05/2012 13:23, "Frans Meulenbroeks"<fransmeulenbroeks@gmail.com> >> wrote: >> >>> 2012/5/8 Barros Pena, Belen<belen.barros.pena@intel.com>: >>>> Hi Frans, >>>> >>>> Thank you so much for agreeing to talk to us. Outside working hours >>>> should >>>> be no problem. What time would be good for you? >>>> >>>> >>>> If you are ok with it, I'd like to record our conversation: it means I >>>> don't need to take lots of notes and I can focus on talking to you. >>>> Using >>>> Skype makes the recording easier: would you mind if we use that instead >>>> of >>>> the phone? My Skype ID is belenbarrospena. >>>> >>>> All the best, >>>> >>>> Belen >>>> >>>> >>> Hi Belen, >>> >>> Recording is no problem. Tonight I'm a little bit low on time, but I >>> think tomorrow evening I'm fairly flexible (this may still change >>> though, my life is sometimes somewhat hectic). >>> 20.30 or so will probably work for me, but if you prefer earlier or >>> later that is also probably no problem. >>> And recording is also no problem. >>> >>> Best regards, Frans >> >> --------------------------------------------------------------------- >> Intel Corporation (UK) Limited >> Registered No. 1134945 (England) >> Registered Office: Pipers Way, Swindon SN3 1RJ >> VAT No: 860 2173 47 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> > > >>>>>> 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 >> > > Bruce, > > Thanks for your help. > I'l try to make a small overlay based upon the standard denzil 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. Sounds good. I'm just concerned that this didn't work right out of the box. Bruce > > Best regards, Frans ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 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 14:11 ` Frans Meulenbroeks 1 sibling, 2 replies; 16+ messages in thread From: Bruce Ashfield @ 2012-05-08 19:20 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto 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 denzil 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 > > Best regards, Frans ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-08 19:20 ` Bruce Ashfield @ 2012-05-08 22:40 ` Autif Khan 2012-05-09 1:12 ` Bruce Ashfield 2012-05-09 14:11 ` Frans Meulenbroeks 1 sibling, 1 reply; 16+ messages in thread From: Autif Khan @ 2012-05-08 22:40 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto On Tue, May 8, 2012 at 3:20 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > > 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. Thanks! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-08 22:40 ` Autif Khan @ 2012-05-09 1:12 ` Bruce Ashfield 2012-05-09 4:31 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Bruce Ashfield @ 2012-05-09 1:12 UTC (permalink / raw) To: Autif Khan; +Cc: yocto On 12-05-08 6:40 PM, Autif Khan wrote: > On Tue, May 8, 2012 at 3:20 PM, Bruce Ashfield > <bruce.ashfield@windriver.com> wrote: >> >> 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. > > Thanks! Does this mean you are the one person that was following!? :) Cheers, Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-09 1:12 ` Bruce Ashfield @ 2012-05-09 4:31 ` Khem Raj 0 siblings, 0 replies; 16+ messages in thread From: Khem Raj @ 2012-05-09 4:31 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto On Tue, May 8, 2012 at 6:12 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > > Does this mean you are the one person that was following!? :) LOL ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-08 19:20 ` Bruce Ashfield 2012-05-08 22:40 ` Autif Khan @ 2012-05-09 14:11 ` Frans Meulenbroeks 2012-05-09 14:14 ` Bruce Ashfield 1 sibling, 1 reply; 16+ messages in thread From: Frans Meulenbroeks @ 2012-05-09 14:11 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-09 14:11 ` Frans Meulenbroeks @ 2012-05-09 14:14 ` Bruce Ashfield 2012-05-09 14:27 ` Frans Meulenbroeks 0 siblings, 1 reply; 16+ messages in thread From: Bruce Ashfield @ 2012-05-09 14:14 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto On 12-05-09 10:11 AM, Frans Meulenbroeks wrote: > 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. Yes, that's a property of guilt. I used to carry a patch to git to actually fix that behaviour, but I was since educated on the subtleties about why it's better to have new files explicitly added by the user before git (and hence guilt) will pick them up. > > 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. When working with any rejected patch under git/guilt/git-am, I am now in the habit of checking git status, git adding the files I want, and then issuing the tag and guilt refresh. Scripts are great for this as well. That's my suggestion on how to deal with new files. Cheers, Bruce > > Frans. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-09 14:14 ` Bruce Ashfield @ 2012-05-09 14:27 ` Frans Meulenbroeks 2012-05-09 14:40 ` Bruce Ashfield 0 siblings, 1 reply; 16+ messages in thread From: Frans Meulenbroeks @ 2012-05-09 14:27 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto 2012/5/9 Bruce Ashfield <bruce.ashfield@windriver.com>: > On 12-05-09 10:11 AM, Frans Meulenbroeks wrote: >> >> >> >> 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. > > > Yes, that's a property of guilt. I used to carry a patch to git to > actually fix that behaviour, but I was since educated on the subtleties > about why it's better to have new files explicitly added by the > user before git (and hence guilt) will pick them up. > > >> >> 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. > > > When working with any rejected patch under git/guilt/git-am, I am now > in the habit of checking git status, git adding the files I want, and > then issuing the tag and guilt refresh. Scripts are great for this > as well. > > That's my suggestion on how to deal with new files. > > Cheers, > > Bruce > Seems like a decent flow to me. Actually I probably rework my patch to indeed add the new files separately as files. The good news is that after this exercise my kernel with most of the patches added builds and works! Only issue left seems to be 3 new locally added drivers that refer to of_register_platform_driver and of_unregister_platform_driver This used to be there in 2.6.38 but has been removed in (iirc) 2.6.39. Guess I can/have to sort this out.... Best regards, Frans. PS: probably we should in the wiki or manual or so have some howto's to describe common tasks like the above one (the making of the kernel patch that is). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: modify a kernel patch 2012-05-09 14:27 ` Frans Meulenbroeks @ 2012-05-09 14:40 ` Bruce Ashfield 0 siblings, 0 replies; 16+ messages in thread From: Bruce Ashfield @ 2012-05-09 14:40 UTC (permalink / raw) To: Frans Meulenbroeks; +Cc: yocto On 12-05-09 10:27 AM, Frans Meulenbroeks wrote: > 2012/5/9 Bruce Ashfield<bruce.ashfield@windriver.com>: >> On 12-05-09 10:11 AM, Frans Meulenbroeks wrote: >>> > >>> >>> >>> 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. >> >> >> Yes, that's a property of guilt. I used to carry a patch to git to >> actually fix that behaviour, but I was since educated on the subtleties >> about why it's better to have new files explicitly added by the >> user before git (and hence guilt) will pick them up. >> >> >>> >>> 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. >> >> >> When working with any rejected patch under git/guilt/git-am, I am now >> in the habit of checking git status, git adding the files I want, and >> then issuing the tag and guilt refresh. Scripts are great for this >> as well. >> >> That's my suggestion on how to deal with new files. >> >> Cheers, >> >> Bruce >> > > Seems like a decent flow to me. > Actually I probably rework my patch to indeed add the new files > separately as files. > > The good news is that after this exercise my kernel with most of the > patches added builds and works! > Only issue left seems to be 3 new locally added drivers that refer to > of_register_platform_driver and of_unregister_platform_driver > This used to be there in 2.6.38 but has been removed in (iirc) 2.6.39. > Guess I can/have to sort this out.... If you can't get it working, give a shout, there's a few ppc guys around that we can ping :) > > Best regards, Frans. > > PS: probably we should in the wiki or manual or so have some howto's > to describe common tasks like the above one (the making of the kernel > patch that is). Definitely. I've got a set of things I'll be documenting for the 1.3 release as part of the stabilization, fit and finish theme. This is one of them. This was a good reminder of the gap :) Cheers, Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-05-09 14:40 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.