Found what I was asking for with: bitbake -e <package>
going through the output, there are mentions of patch_do_patch(). I've traced it to meta/classes/patch.bbclass. However, trying to execute just the patching for the recipe doesn't work. buildā« bitbake -c patch u-boot-fw-utils-senic ... ERROR: Task do_patch does not exist for target u-boot-fw-utils-senic (/home/alan/senic-os-update/oe/../meta-senic/recipes-bsp/u-boot/u-boot-fw-utils-senic_2017.03.bb:do_patch). Close matches: do_fetch do_unpack ERROR: Command execution failed: 1 On Thu, Nov 2, 2017 at 1:51 PM, Alan Martinovic <alan.martino...@senic.com> wrote: > That I can't see the changes for that particular patch in the source (by > manually checking the source for the changes). > Other patches are applied correctly, I can trace them in the sources. > > I have no "temp/log.do_patch" and find notions of patches (both the > successfully and unsuccessfully applied ones) only in the log.do_fetch and > log.do_unpack steps. > > Is there a way to grep through how a recipe looks like when all the > inherited parts have been expanded? > There seems to be a do_patch task (http://www.yoctoproject.org/ > docs/2.3/ref-manual/ref-manual.html#patching-dev-environment) > which I would grep for in that expanded recipe. > > For more insight, the current recipe (the one I'd like to see expanded) > looks like this: > > $ cat u-boot-fw-utils-senic_2017.03.bb > SUMMARY = "U-Boot bootloader fw_printenv/setenv utilities" > LICENSE = "GPLv2+" > LIC_FILES_CHKSUM = "file://Licenses/README;md5= > a2c678cfd4a4d97135585cad908541c6" > SECTION = "bootloader" > DEPENDS = "mtd-utils" > > require recipes-bsp/u-boot/u-boot-fw-utils-mender.inc > > SRCBRANCH = "senic/v2017.03" > SRC_URI = "git://g...@github.com/getsenic/senic-os-uboot.git; > protocol=ssh;branch=${SRCBRANCH} > <http://g...@github.com/getsenic/senic-os-uboot.git;protocol=ssh;branch=$%7BSRCBRANCH%7D>; > \ > file://boot.cmd \ > > file://0001-sun8i-configs-Add-CONFIG_BOOTCOUNT_LIMIT-ENV-for-men.patch > \ > file://0002-sunxi-common-Remove-variables-used-by-Mender.patch > \ > file://default-gcc.patch" > > SRC_URI_remove = "file://0003-Integration-of-Mender-boot-code-into-U-Boot. > patch" > SRC_URI_append = " file://0001-Integration-of- > Mender-boot-code-into-U-Boot.patch" > > SRCREV = "5233f173335a61b1e2b9120c55422a8d60ff7ffe" > PV = "v2017.03+git${SRCPV}" > S = "${WORKDIR}/git" > > # For Mender.io integration > BOOTENV_SIZE = "0x20000" > PROVIDES += "u-boot-fw-utils" > RPROVIDES_${PN} += "u-boot-fw-utils" > > INSANE_SKIP_${PN} = "already-stripped" > EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC} > ${CFLAGS} ${LDFLAGS}" V=1' > EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS} > ${LDFLAGS}" V=1' > > inherit uboot-config > > do_compile () { > oe_runmake ${UBOOT_MACHINE} > oe_runmake env > } > > do_install () { > install -d ${D}${base_sbindir} > install -d ${D}${sysconfdir} > install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_ > printenv > install -m 755 ${S}/tools/env/fw_printenv > ${D}${base_sbindir}/fw_setenv > install -m 0644 ${S}/tools/env/fw_env.config > ${D}${sysconfdir}/fw_env.config > } > > do_install_class-cross () { > install -d ${D}${bindir_cross} > install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_ > printenv > install -m 755 ${S}/tools/env/fw_printenv > ${D}${bindir_cross}/fw_setenv > } > > SYSROOT_DIRS_append_class-cross = " ${bindir_cross}" > > PACKAGE_ARCH = "${MACHINE_ARCH}" > BBCLASSEXTEND = "cross" > > > > > On Thu, Nov 2, 2017 at 12:50 PM, Burton, Ross <ross.bur...@intel.com> > wrote: > >> 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.patch". >>>>> 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