On Sun, May 1, 2011 at 10:31 PM, Bruce Ashfield <[email protected]> wrote: > On Sun, May 1, 2011 at 11:56 PM, Khem Raj <[email protected]> wrote: >> On Sun, May 1, 2011 at 7:40 PM, Bruce Ashfield <[email protected]> >> wrote: >>> On Sun, May 1, 2011 at 9:14 PM, Khem Raj <[email protected]> wrote: >>>> Hi >>>> >>>> I am trying to test this patch >>>> >>>> http://uclibc.org/~kraj/perf-tool-Fix-gcc-4.6.0-issues.patch >>>> >>>> to fix the build using gcc 4.6.0 but the kernel patching for yocto is >>>> not as usual as other recipes >>>> since it uses entire set of tooling around it. >>>> >>>> I tried to look around for documentation and few references I found >>>> >>>> https://wiki.pokylinux.org/wiki/Wind_River_Kernel >>>> >>>> discourages putting patches in metadata. and in another document it >>>> says it uses git to do patching but does not explain how. >>>> >>>> So if someone can explain in simple terms how to patch a linux-yocto >>>> would be really helpful from a >>>> developer POV or any documentation will be helpful. >>>> >>>> How do people develop/test patches on linux-yocto I understand >>>> eventually they are desired to be part >>>> of linux-yocto git but that comes after they are tried and tested locally >>>> >>>> I would have preferred to have the usual SRC_URI patching atleast for >>>> local testing. As of now >>>> it seems not to use normal OE recipe procedures. >>> >>> Are you actually not seeing this work ? I put in place compatibility >>> with existing patching via the SRC_URI for just this reason. A patch >>> specified in the SRC_URI will be picked up by the tools and applied >>> to the end of the BSP branch during the patching phase. >>> >> >> if it worked. I would not be writing this email :) > > :) you never know, I didn't see your error message so I didn't want > to presume. > > But I spoke too soon earlier, I had a bbappend in my layers that > meant I was modifying the wrong SRC_URI to have your patch > applied. > > When I modified the right SRC_URI like so: > > +SRC_URI = > "git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta\ > + file://perf-tool-Fix-gcc-4.6.0-issues.patch" > > (i.e. the obvious way) > > I see the patch applied to the end of my BSP branch: > >> git branch > master > meta > yocto/base > yocto/eg20t > yocto/emgd > yocto/gma500 > yocto/standard/arm-versatile-926ejs > yocto/standard/base > yocto/standard/beagleboard > yocto/standard/common-pc-64/base > yocto/standard/common-pc-64/jasperforest > yocto/standard/common-pc-64/sugarbay > yocto/standard/common-pc/atom-pc > * yocto/standard/common-pc/base > > commit 2500f7dc4d6c0d8b2f5ddad6369ee4541456533a > Author: Kyle McMartin <[email protected]> > Date: Mon May 2 01:26:49 2011 -0400 > > commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream. > > GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf > due to the -Werror=unused-but-set-variable flag. > > I've gone through and annotated some of the assignments that had side > effects (ie: return value from a function) with the __used annotation, > and in some cases, just removed unused code. > > In a few cases, we were assigning something useful, but not using it in > later parts of the function. > > kyle@dreadnought:~/src% gcc --version > gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3) > > Cc: Ingo Molnar <[email protected]> > LKML-Reference: <[email protected]> > Signed-off-by: Kyle McMartin <[email protected]> > [ committer note: Fixed up the annotation fixes, as that code > moved recently ] > Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> > [Backported to 2.6.38.2 by deleting unused but set variables] > Signed-off-by: Thomas Meyer <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> > [Backported to linux-yocto kernel git version] > Signed-off-by: Khem Raj <[email protected]> > > I did modify the patch format slightly, since git am needs to be able to > grok the patch for it to apply. > > Did you get any sort of error message when your patch didn't apply ? >
yes it would not apply the patch and instead complained it could not checkout a branch because tree was dirty I dont have exact message handy. I will see if I can reproduce it > Cheers, > > Bruce > >> >>> It has definitely worked during all the development cycles, so if you >>> are seeing it not work, it's a bug and I'll fix it. >>> >>> Cheers, >>> >>> Bruce >>> >>>> >>>> Thanks >>>> -Khem >>>> >>>> _______________________________________________ >>>> Openembedded-core mailing list >>>> [email protected] >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >>>> >>> >>> >>> >>> -- >>> "Thou shalt not follow the NULL pointer, for chaos and madness await >>> thee at its end" >>> >>> _______________________________________________ >>> Openembedded-core mailing list >>> [email protected] >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >>> >> >> _______________________________________________ >> Openembedded-core mailing list >> [email protected] >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end" > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
