What do you mean by patches not being applied correctly? temp/log.do_patch has the output from patch so that might show that you've a patch that applies with lots of fuzz and is applied incorrectly.
Ross On 2 November 2017 at 11:46, Alan Martinovic <alan.martino...@senic.com> wrote: > I see, so I can't use the devshell to debug why the patch hasn't been > correctly applied. > > The answer you gave help for debugging actual build and configure problems. > Debugging patching seems to be out scope for this thread. > Will start a new one. > > > On Thu, Nov 2, 2017 at 12:13 PM, Burton, Ross <ross.bur...@intel.com> > wrote: > >> The patching is done by a bbclass (patch.bbclass) and helper modules >> (meta/oe/lib/patch.py), so you can't execute it like a shell task (such as >> do_compile). >> >> Ross >> >> On 2 November 2017 at 11:05, Alan Martinovic <alan.martino...@senic.com> >> wrote: >> >>> Thanks for the suggestions >>> Am currently implementing both of them and am trying to understand how >>> the patching is done. >>> >>> In the temp directory I can see all the tasks. >>> For some reasons the patch wasn't applied correctly and I'm debugging >>> why. >>> >>> I have patches from before which are being correctly applied, one of >>> them being "0001-sun8i-configs-Add-CONFIG_BOOTCOUNT_LIMIT-ENV-for-men.p >>> atch". >>> Am using that one just as a reference for this example. >>> I want to see the steps done to apply the patch so I do: >>> >>> temp$ grep -r 0001-sun8i-configs * >>> temp$ grep -r quilt * >>> >>> I am expecting to see some commands related to the patching process in >>> one of the run scripts. >>> For example, "quilt" followed by some arguments or >>> "0001-sun8i-configs-Add-CONFIG_BOOTCOUNT_LIMIT-ENV-for-men.patch" being >>> applied >>> by some other tool instead of quilt. >>> >>> I only end up with some findings in the log files (log.do_fetch, >>> log.do_unpack which don't tell me much). >>> >>> >>> Where are the steps that apply the patches located? >>> >>> Be Well :) >>> Alan >>> >>> >>> >>> >>> I've gotten to the >>> >>> On Wed, Nov 1, 2017 at 8:05 PM, Alex Kiernan <alex.kier...@hivehome.com> >>> wrote: >>> >>>> On 1 November 2017 at 17:38, Alan Martinovic <alan.martino...@senic.com >>>> > wrote: >>>> >>>>> I'm just upgrading to pyro and have some issues with u-boot-fw-utils. >>>>> >>>>> The error fails at do_compile stage which looks like this: >>>>> >>>>> do_compile () { >>>>> oe_runmake ${UBOOT_MACHINE} >>>>> oe_runmake env >>>>> } >>>>> >>>>> >>>>> The error is: >>>>> >>>>> Log data follows: >>>>> | DEBUG: Executing shell function do_compile >>>>> | NOTE: make -j 16 CROSS_COMPILE=arm-senic-linux-gnueabi- >>>>> CC=arm-senic-linux-gnueabi- gcc -march=armv7ve -mfpu=neon-vfpv4 >>>>> -mfloat-abi=hard -mcpu=cortex-a7 >>>>> --sysroot=/home/alan/senic-os-update/build/tmp-glibc/work/se >>>>> nic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-senic/v2017 >>>>> .03+gitAUTOINC+5233f17333-r0/recipe-sysroot >>>>> -O2 -pipe -g -feliminate-unused-debug-types >>>>> -fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glib >>>>> c/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-se >>>>> nic/v2017.03+gitAUTOINC+5233f17333-r0=/usr/src/debug/u-boot- >>>>> fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0 >>>>> -fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glib >>>>> c/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-se >>>>> nic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot-native= >>>>> -fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glib >>>>> c/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-se >>>>> nic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot= >>>>> -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed V=1 >>>>> | ERROR: oe_runmake failed >>>>> | make -f ./Makefile silentoldconfig >>>>> | make -f ./scripts/Makefile.build obj=scripts/basic >>>>> | cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 >>>>> -fomit-frame-pointer -o scripts/basic/fixdep >>>>> scripts/basic/fixdep.c >>>>> | /bin/sh: 1: cc: not found >>>>> >>>>> >>>>> I would assume this is a to specific error to ask help about. It seems >>>>> that the compiler isn't being called correctly (it's called as cc, >>>>> which isn't the full compiler name). >>>>> Suggestions are welcome but that isn't the reason for my post. >>>>> >>>>> >>>> Guessing... apply this in your recipe: >>>> >>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/rec >>>> ipes-bsp/u-boot/files/default-gcc.patch?h=pyro >>>> >>>> -- >>>> Alex Kiernan >>>> Senior Engineering Manager >>>> >>>> hivehome.com <http://www.hivehome.com> >>>> >>>> >>>> >>>> Hive | London | Cambridge | Houston | Toronto >>>> The information contained in or attached to this email is confidential >>>> and intended only for the use of the individual(s) to which it is >>>> addressed. It may contain information which is confidential and/or covered >>>> by legal professional or other privilege. The views expressed in this email >>>> are not necessarily the views of Centrica plc, and the company, its >>>> directors, officers or employees make no representation or accept any >>>> liability for their accuracy or completeness unless expressly stated to the >>>> contrary. >>>> Centrica Connected Home Limited (company no: 5782908), registered in >>>> England and Wales with its registered office at Millstream, Maidenhead >>>> Road, Windsor, Berkshire SL4 5GD. >>>> >>> >>> >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto