On Thu, Jul 23, 2020 at 9:38 AM Ryan Harkin <[email protected]> wrote:
>
> Hi Bruce,
>
> On Thu, 23 Jul 2020 at 13:27, Bruce Ashfield <[email protected]> wrote:
>>
>> On Thu, Jul 23, 2020 at 5:34 AM Ryan Harkin <[email protected]> wrote:
>> >
>> > Hi Bruce, Steve,
>> >
>> > Thanks for your replies and the help.
>> >
>> > On Thu, 23 Jul 2020 at 04:33, Steve Sakoman <[email protected]> wrote:
>> >>
>> >> On Wed, Jul 22, 2020 at 3:58 PM Bruce Ashfield <[email protected]> 
>> >> wrote:
>> >> >
>> >> > On Wed, Jul 22, 2020 at 5:27 PM Ryan Harkin <[email protected]> 
>> >> > 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:
>> >
>> > 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.
>
>
> 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).

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 ?

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:
>> >> > > 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 <[email protected]> wrote:
>> >> > >>
>> >> > >> On Mon, Jul 6, 2020 at 6:29 AM Bruce Ashfield 
>> >> > >> <[email protected]> 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 <[email protected]> 
>> >> > >> > wrote:
>> >> > >> > >
>> >> > >> > > From: Bruce Ashfield <[email protected]>
>> >> > >> > >
>> >> > >> > > 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 <[email protected]>
>> >> > >> > > Signed-off-by: Richard Purdie 
>> >> > >> > > <[email protected]>
>> >> > >> > > (cherry picked from commit 
>> >> > >> > > e6845327b69396d843a2f3c4c3ac9400ae9caedf)
>> >> > >> > > Signed-off-by: Steve Sakoman <[email protected]>
>> >> > >> > > ---
>> >> > >> > >  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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140902): 
https://lists.openembedded.org/g/openembedded-core/message/140902
Mute This Topic: https://lists.openembedded.org/mt/75336267/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to