Re: [OE-core][dunfell 04/25] kernel/yocto: ensure that defconfigs are processed first

["Andrey Zhizhikin" <andrey.z@gmail.com>]

Hey guys,

Sorry for jumping into this thread a bit later - I saw that it has
been sorted out already.

On Thu, Jul 23, 2020 at 6:06 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>
>
>
> On Thu, 23 Jul 2020 at 16:05, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>
>> On Thu, Jul 23, 2020 at 9:38 AM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> >
>> > Hi Bruce,
>> >
>> > On Thu, 23 Jul 2020 at 13:27, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> >>
>> >> On Thu, Jul 23, 2020 at 5:34 AM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> >> >
>> >> > Hi Bruce, Steve,
>> >> >
>> >> > Thanks for your replies and the help.
>> >> >
>> >> > On Thu, 23 Jul 2020 at 04:33, Steve Sakoman <steve@sakoman.com> wrote:
>> >> >>
>> >> >> On Wed, Jul 22, 2020 at 3:58 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> >> >> >
>> >> >> > On Wed, Jul 22, 2020 at 5:27 PM Ryan Harkin <ryan.harkin@linaro.org> wrote:
>> >> >> > >
>> >> >> > > Just an FYI, but when this was submitted, my imx7s-warp builds began to fail when building linux-fslc from meta-freescale / meta-freescale-3rdparty.
>> >> >> > >
>> >> >> > > I'm not sure why yet, I've only discovered the problem, but I thought I'd report it in case anyone else sees the problem.
>> >> >> > >
>> >> >> >
>> >> >> > Someone already sent a dunfell backport request for a follow up patch to this.
>> >> >> >
>> >> >> > It went to the poky list, but I just replied to it and copied oe-core.
>> >> >>
>> >> >> Both patches are already in dunfell!
>> >> >>
>> >> >> https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7ecc81baeacaa1149a4947791200e8819c3df677
>> >> >> https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=11089e06bfb3d0defb52825ffba978d085385569
>> >> >
>> >> >
>> >> > Yes, they are present. I guess I should have checked the error messages more closely during git bisect rather than stopping as soon as the build failed.
>> >> >
>> >> > After Bruce's 7ecc81baea patch, I see this error:
>> >> >
>> >> > ERROR: linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0 do_kernel_metadata: Could not locate BSP definition for imx7s-warp/standard and no defconfig was provided
>> >> >
>> >> > Then, after 11089e06bf, I see the error I originally posted from my CI job, but reproduced here from a local build:

This was the patch I've introduced and seeing those errors were quite
a surprise to me. I have also an internal CI that builds
meta-freescale off the dunfell branch - and I never had any issues
with it.

>> >> >
>> >> > ERROR: linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0 do_kernel_configme: Execution of '/data/warp7/workspace-dunfell/build-rpb/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.31899' failed with exit code 1:
>> >> > WARNING: exit code 1 from a shell command.
>> >> >
>> >> > ERROR: Logfile of failure stored in: /data/warp7/workspace-dunfell/build-rpb/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/log.do_kernel_configme.31899
>> >> > Log data follows:
>> >> > | DEBUG: Executing python function extend_recipe_sysroot
>> >> > | NOTE: Direct dependencies are ['/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/meta-arm/meta-arm-toolchain/recipes-devtools/gcc/gcc-cross_arm-9.2.bb:do_populate_sysroot', 'virtual:native:/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', '/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.34.bb:do_populate_sysroot', 'virtual:native:/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/bison/bison_3.5.3.bb:do_populate_sysroot', '/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', '/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot']
>> >> > | NOTE: Installed into sysroot: []
>> >> > | NOTE: Skipping as already exists in sysroot: ['gcc-cross-arm', 'bc-native', 'binutils-cross-arm', 'bison-native', 'quilt-native', 'kern-tools-native', 'patch-native', 'readline-native', 'flex-native', 'automake-native', 'texinfo-dummy-native', 'autoconf-native', 'libtool-native', 'gnu-config-native', 'xz-native', 'gettext-minimal-native', 'libmpc-native', 'gmp-native', 'zlib-native', 'mpfr-native', 'linux-libc-headers', 'attr-native', 'ncurses-native', 'm4-native', 'pkgconfig-native']
>> >> > | DEBUG: Python function extend_recipe_sysroot finished
>> >> > | DEBUG: Executing shell function do_kernel_configme
>> >> > | WARNING: exit code 1 from a shell command.
>> >> > | ERROR: Execution of '/data/warp7/workspace-dunfell/build-rpb/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.31899' failed with exit code 1:
>> >> > | WARNING: exit code 1 from a shell command.
>> >> >
>> >> > I haven't yet looked at what these patches do, but I'm expecting there's something to update in the linux-fslc recipe, unless there's another issue in the defconfig patches.
>> >> >
>> >>
>> >> We've had multiple reports that with those patches the linux-fslc
>> >> recipe is building. So something else may be going on in your setup.

If there were some reports - I haven't seen them...

Bruce, do you happen to have any reference to them? I'm trying to
merge and maintain linux-fslc[-imx] kernels, and so far I've never
seen any failures. Or maybe they were reported on some mailing lists
I'm not in.

>> >
>> >
>> > That's reassuring.
>> >
>> >>
>> >> If you have a set of layers and build steps, can you send them to me ?
>> >> I can spin up a local build and see if I get the same behaviour.
>> >
>> >
>> > Thanks for the offer. I'm based on Linaro's "OE-RPB" setup.
>> >
>> > My own layer is quite simple:
>> > https://git.linaro.org/people/ryan.harkin/meta-warp7.git/log/?h=dunfell
>> >
>> > I mostly provide a new image definition and a simple u-boot patch to change the console UART for our CI system. I don't have a kernel recipe overlaying linux-fslc.
>> >
>> > My basic steps to clone and build are:
>> > --------------------------
>> > mkdir /data/warp7/workspace-dunfell
>> > cd /data/warp7/workspace-dunfell
>> > repo init -u \
>> > https://git.linaro.org/people/ryan.harkin/oe-rpb-manifest.git \
>> > -b dunfell
>> > repo sync
>> >
>> > # link in shared downloads and sstate-cache
>> > ln -s /linaro/oe-rpb/downloads . && ln -s /linaro/oe-rpb/sstate-cache .
>> >
>> > export MACHINE=imx7s-warp ; export DISTRO=rpb ; . setup-environment
>> > bitbake warp7-console-image
>> > --------------------------
>> >
>>
>> I'm spinning up a build now (but as usual, I'm fighting some
>> infrastructure issues and can't get repo to install).
>
>
> It looks like you can stand down on this...
>
>>
>>
>> Steve mentioned two patches ... but can you also confirm that:
>> [kernel-yocto: account for extracted defconfig in elements check] is
>> in the branch you are building ?
>
>
> That patch wasn't in my dunfell branch, so I cherry-picked it from master locally and now the build is working again.
> Meanwhile, doing a "git remote update" and I see the patch is now on top of the dunfell branch as of today, and my build is working again.

Glad to see that it is solved for you! I've run the build for
meta-freescale linux-fslc yesterday - it went through like a breeze...
I don't think there was a significant update on dunfell, but I can
start the build now anyway...

>
> Great, thanks for your help folks.
>
> Regards,
> Ryan.
>
>
>
>>
>>
>> Bruce
>>
>>
>> > Right now, I've pinned oo-core to my last known working build from before your recent defconfig patch, so you'll want to go into layer/openembedded-core and checkout the latest commits.
>> >
>> > For reference, my pinned commit:
>> > cabaf5654d  2020-07-06  iso-codes: switch upstream branch master -> main                [Hongxu Jia]
>> >
>> > Local testing tells me that the repo works fine for me all the way up to just before your commit, at this point:
>> > 2399fdf98a  2020-07-03  classes/archive: do_configure should not depend on do_ar_p..    [Joshua Watt]
>> >
>> > I'm building on an Ubuntu 18.04 host locally.
>> >
>> > Regards,
>> > Ryan.
>> >
>> >
>> >>
>> >>
>> >> Bruce
>> >>
>> >> > Regards,
>> >> > Ryan.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> Steve
>> >> >>
>> >> >> > > Here's a link to my failing build for reference:
>> >> >> > > https://ci.linaro.org/job/warp7-openembedded-dunfell/67/DISTRO=rpb,MACHINE=imx7s-warp,label=docker-buster-amd64/consoleText
>> >> >> > >
>> >> >> > > And a snippet from the failure:
>> >> >> > >
>> >> >> > > ERROR: linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0 do_kernel_configme: Execution of '/srv/oe/build/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.7123' failed with exit code 1:

Oh, this is actually a good reminder: I have to bump up the kernel
version! It's been merged into the linux-fslc repo, but I didn't
update recipes so far... Vacation time... :) Latest update would
include v5.4.51 tag.

>> >> >> > > WARNING: exit code 1 from a shell command.
>> >> >> > >
>> >> >> > > ERROR: Logfile of failure stored in: /srv/oe/build/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/log.do_kernel_configme.7123
>> >> >> > > Log data follows:
>> >> >> > > | DEBUG: Executing python function extend_recipe_sysroot
>> >> >> > > | NOTE: Direct dependencies are ['virtual:native:/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/bison/bison_3.5.3.bb:do_populate_sysroot', '/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', '/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.34.bb:do_populate_sysroot', '/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', 'virtual:native:/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', '/srv/oe/build/conf/../../layers/meta-arm/meta-arm-toolchain/recipes-devtools/gcc/gcc-cross_arm-9.2.bb:do_populate_sysroot']
>> >> >> > > | NOTE: Installed into sysroot: []
>> >> >> > > | NOTE: Skipping as already exists in sysroot: ['bison-native', 'kern-tools-native', 'binutils-cross-arm', 'quilt-native', 'patch-native', 'bc-native', 'gcc-cross-arm', 'flex-native', 'texinfo-dummy-native', 'gnu-config-native', 'readline-native', 'libtool-native', 'automake-native', 'autoconf-native', 'xz-native', 'linux-libc-headers', 'gmp-native', 'libmpc-native', 'mpfr-native', 'zlib-native', 'gettext-minimal-native', 'attr-native', 'm4-native', 'ncurses-native', 'pkgconfig-native']
>> >> >> > > | DEBUG: Python function extend_recipe_sysroot finished
>> >> >> > > | DEBUG: Executing shell function do_kernel_configme
>> >> >> > > | WARNING: exit code 1 from a shell command.
>> >> >> > > | ERROR: Execution of '/srv/oe/build/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.7123' failed with exit code 1:
>> >> >> > > | WARNING: exit code 1 from a shell command.
>> >> >> > > |
>> >> >> > > NOTE: recipe linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0: task do_kernel_configme: Failed
>> >> >> > > ERROR: Task (/srv/oe/build/conf/../../layers/meta-freescale/recipes-kernel/linux/linux-fslc_5.4.bb:do_kernel_configme) failed with exit code '1'
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >> > > On Mon, 6 Jul 2020 at 17:38, Steve Sakoman <steve@sakoman.com> wrote:
>> >> >> > >>
>> >> >> > >> On Mon, Jul 6, 2020 at 6:29 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> >> >> > >> >
>> >> >> > >> > We have a fixup patch for this one in test right now, so we don't want
>> >> >> > >> > this patch, without the follow up.
>> >> >> > >> >
>> >> >> > >> > But this is useful for dunfell, since it was an unexpected behaviour
>> >> >> > >> > that needed to be fixed.
>> >> >> > >>
>> >> >> > >> Thanks, I'll drop this patch from the pull request and include it
>> >> >> > >> along with the fixup patch in next week's patch set.
>> >> >> > >>
>> >> >> > >> Steve
>> >> >> > >>
>> >> >> > >> > On Mon, Jul 6, 2020 at 12:11 PM Steve Sakoman <steve@sakoman.com> wrote:
>> >> >> > >> > >
>> >> >> > >> > > From: Bruce Ashfield <bruce.ashfield@gmail.com>
>> >> >> > >> > >
>> >> >> > >> > > It is uncommon that a BSP definition and a defconfig are used in
>> >> >> > >> > > a single configuration. That being said, it is a valid way to
>> >> >> > >> > > organize kernel configuration meta data.
>> >> >> > >> > >
>> >> >> > >> > > When a defconfig is used, either on the src_uri or from in
>> >> >> > >> > > the kernel tree, it is normally expected that it is the baseline,
>> >> >> > >> > > with all options applied on top of it.
>> >> >> > >> > >
>> >> >> > >> > > With this commit, we detect either type of defconfig and ensure
>> >> >> > >> > > that it is used first, followed by the fragments in their
>> >> >> > >> > > previous order. This allows existing configuration stacks to
>> >> >> > >> > > remain the same, while ensuring that a defconfig combined stack
>> >> >> > >> > > works as expected.
>> >> >> > >> > >
>> >> >> > >> > > Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
>> >> >> > >> > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> >> >> > >> > > (cherry picked from commit e6845327b69396d843a2f3c4c3ac9400ae9caedf)
>> >> >> > >> > > Signed-off-by: Steve Sakoman <steve@sakoman.com>
>> >> >> > >> > > ---
>> >> >> > >> > >  meta/classes/kernel-yocto.bbclass | 33 ++++++++++++++++++++-----------
>> >> >> > >> > >  1 file changed, 21 insertions(+), 12 deletions(-)
>> >> >> > >> > >
>> >> >> > >> > > diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
>> >> >> > >> > > index 5bc627066e..41d8620e67 100644
>> >> >> > >> > > --- a/meta/classes/kernel-yocto.bbclass
>> >> >> > >> > > +++ b/meta/classes/kernel-yocto.bbclass
>> >> >> > >> > > @@ -131,7 +131,7 @@ do_kernel_metadata() {
>> >> >> > >> > >                         else
>> >> >> > >> > >                                 cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
>> >> >> > >> > >                         fi
>> >> >> > >> > > -                       sccs="${WORKDIR}/defconfig"
>> >> >> > >> > > +                       in_tree_defconfig="${WORKDIR}/defconfig"
>> >> >> > >> > >                 else
>> >> >> > >> > >                         bbfatal "A KBUILD_DEFCONFIG '${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
>> >> >> > >> > >                 fi
>> >> >> > >> > > @@ -153,14 +153,24 @@ do_kernel_metadata() {
>> >> >> > >> > >         patches="${@" ".join(find_patches(d,''))}"
>> >> >> > >> > >         feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
>> >> >> > >> > >
>> >> >> > >> > > -       # a quick check to make sure we don't have duplicate defconfigs
>> >> >> > >> > > -       # If there's a defconfig in the SRC_URI, did we also have one from
>> >> >> > >> > > -       # the KBUILD_DEFCONFIG processing above ?
>> >> >> > >> > > -       if [ -n "$sccs" ]; then
>> >> >> > >> > > -           # we did have a defconfig from above. remove any that might be in the src_uri
>> >> >> > >> > > -           sccs_from_src_uri=$(echo $sccs_from_src_uri | awk '{ if ($0!="defconfig") { print $0 } }' RS=' ')
>> >> >> > >> > > +       # a quick check to make sure we don't have duplicate defconfigs If
>> >> >> > >> > > +       # there's a defconfig in the SRC_URI, did we also have one from the
>> >> >> > >> > > +       # KBUILD_DEFCONFIG processing above ?
>> >> >> > >> > > +       src_uri_defconfig=$(echo $sccs_from_src_uri | awk '{ if ($0=="defconfig") { print $0 } }' RS=' ')
>> >> >> > >> > > +       # drop and defconfig's from the src_uri variable, we captured it just above here if it existed
>> >> >> > >> > > +       sccs_from_src_uri=$(echo $sccs_from_src_uri | awk '{ if ($0!="defconfig") { print $0 } }' RS=' ')
>> >> >> > >> > > +       if [ -n "$in_tree_defconfig" ]; then
>> >> >> > >> > > +               sccs_defconfig=$in_tree_defconfig
>> >> >> > >> > > +               if [ -n "$src_uri_defconfig" ]; then
>> >> >> > >> > > +                       bbwarn "[NOTE]: defconfig was supplied both via KBUILD_DEFCONFIG and SRC_URI. Dropping SRC_URI defconfig"
>> >> >> > >> > > +               fi
>> >> >> > >> > > +       else
>> >> >> > >> > > +               # if we didn't have an in-tree one, make our defconfig the one
>> >> >> > >> > > +               # from the src_uri. Note: there may not have been one from the
>> >> >> > >> > > +               # src_uri, so this can be an empty variable.
>> >> >> > >> > > +               sccs_defconfig=$src_uri_defconfig
>> >> >> > >> > >         fi
>> >> >> > >> > > -       sccs="$sccs $sccs_from_src_uri"
>> >> >> > >> > > +       sccs="$sccs_from_src_uri"
>> >> >> > >> > >
>> >> >> > >> > >         # check for feature directories/repos/branches that were part of the
>> >> >> > >> > >         # SRC_URI. If they were supplied, we convert them into include directives
>> >> >> > >> > > @@ -187,11 +197,10 @@ do_kernel_metadata() {
>> >> >> > >> > >         # expand kernel features into their full path equivalents
>> >> >> > >> > >         bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE})
>> >> >> > >> > >         if [ -z "$bsp_definition" ]; then
>> >> >> > >> > > -               echo "$sccs" | grep -q defconfig
>> >> >> > >> > > -               if [ $? -ne 0 ]; then
>> >> >> > >> > > +               if [ -z "$sccs_defconfig" ]; then
>> >> >> > >> > >                         bbfatal_log "Could not locate BSP definition for ${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
>> >> >> > >> > >                 fi
>> >> >> > >> > > -
>> >> >> > >> > > +       else
>> >> >> > >> > >                 # if the bsp definition has "define KMETA_EXTERNAL_BSP t",
>> >> >> > >> > >                 # then we need to set a flag that will instruct the next
>> >> >> > >> > >                 # steps to use the BSP as both configuration and patches.
>> >> >> > >> > > @@ -206,7 +215,7 @@ do_kernel_metadata() {
>> >> >> > >> > >         elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
>> >> >> > >> > >         if [ -n "${elements}" ]; then
>> >> >> > >> > >                 echo "${bsp_definition}" > ${S}/${meta_dir}/bsp_definition
>> >> >> > >> > > -               scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes} ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
>> >> >> > >> > > +               scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes} $sccs_defconfig $bsp_definition $sccs $patches ${KERNEL_FEATURES}
>> >> >> > >> > >                 if [ $? -ne 0 ]; then
>> >> >> > >> > >                         bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
>> >> >> > >> > >                 fi
>> >> >> > >> > > --
>> >> >> > >> > > 2.17.1
>> >> >> > >> > >
>> >> >> > >> > >
>> >> >> > >> >
>> >> >> > >> >
>> >> >> > >> >
>> >> >> > >> > --
>> >> >> > >> > - Thou shalt not follow the NULL pointer, for chaos and madness await
>> >> >> > >> > thee at its end
>> >> >> > >> > - "Use the force Harry" - Gandalf, Star Trek II
>> >> >> > >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > - Thou shalt not follow the NULL pointer, for chaos and madness await
>> >> >> > thee at its end
>> >> >> > - "Use the force Harry" - Gandalf, Star Trek II
>> >>
>> >>
>> >>
>> >> --
>> >> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> >> thee at its end
>> >> - "Use the force Harry" - Gandalf, Star Trek II
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>
> 



-- 
Regards,
Andrey.