extensible SDK build failure

extensible SDK build failure

[Russell Peterson]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

Hello, all.

I’m trying to build the eSDK for my platform and I just can’t figure out why dnf can’t find kernel-devsrc.  It’s there, I added it.  The “normal SDK” uses it and builds fine.  Just no luck with the eSDK.
Any help out there?  Poky is pyro.  aarch64 SoC target platform with an x86 build host (CentOS 7.3).  Basically I just bitbake -c do_populate_sdk_ext core-image-full.  I do have a linux kernel recipe that pulls the kernel from the standard kernel.org <http://kernel.org/> repo.

ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp --nogpgcheck install kernel-devsrc' returned 1:
Added oe-repo repo from file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017 UTC.
No package kernel-devsrc available.
Error: Unable to find a match
 
ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
ERROR: Logfile of failure stored in: /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
ERROR: Task (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk) failed with exit code '1'

[-- Attachment #2: Type: text/html, Size: 3811 bytes --]

Re: extensible SDK build failure

[Paul Eggleton]

Hi Russell,

It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK variable at the global level, which you really don't want to do if you're going to be building buildtools-tarball (which eSDK will build as a dependency). I'd suggest moving that setting to your image recipe.

Cheers,
Paul

On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> Hello, all.
> 
> I’m trying to build the eSDK for my platform and I just can’t figure out why dnf can’t find kernel-devsrc.  It’s there, I added it.  The “normal SDK” uses it and builds fine.  Just no luck with the eSDK.
> Any help out there?  Poky is pyro.  aarch64 SoC target platform with an x86 build host (CentOS 7.3).  Basically I just bitbake -c do_populate_sdk_ext core-image-full.  I do have a linux kernel recipe that pulls the kernel from the standard kernel.org <http://kernel.org/> repo.
> 
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp --nogpgcheck install kernel-devsrc' returned 1:
> Added oe-repo repo from file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
> Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017 UTC.
> No package kernel-devsrc available.
> Error: Unable to find a match
>  
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> ERROR: Logfile of failure stored in: /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> ERROR: Task (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk) failed with exit code '1'


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: extensible SDK build failure

[RUSSELL PETERSON]

[-- Attachment #1: Type: text/plain, Size: 4767 bytes --]

Thank you for the response, Paul. You were correct that I had the TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my image bb file and things seem far more sane... although I must admit I am not 100% sure why it works but I will study it a bit and figure it out. Thanks for your help.

I have run into another issue while trying to generate the eSDK in that there appears to be an issue with building harfbuzz. From what I can tell, this appears to be an issue with the search paths for the autoreconf call. The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 directory FIRST and therefore not getting the one in harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has the correct m4_pattern_allow.

Do you think that's a bug or something with my recipe? Seems like I just want to reverse the -I options... but I don't know how, exactly.

/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/ --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/ --force

../../../autoconf-2.69/lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded from...
| configure.ac:22: the top level
| configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
| If this token and others are legitimate, please use m4_pattern_allow.
| See the Autoconf documentation.
| autoreconf: /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf failed with exit status: 1
| ERROR: Function failed: do_configure (log file is located at /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)

> On July 31, 2017 at 9:50 AM Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>
>
> Hi Russell,
>
> It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK variable at the global level, which you really don't want to do if you're going to be building buildtools-tarball (which eSDK will build as a dependency). I'd suggest moving that setting to your image recipe.
>
> Cheers,
> Paul
>
> On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> > Hello, all.
> >
> > I’m trying to build the eSDK for my platform and I just can’t figure out why dnf can’t find kernel-devsrc. It’s there, I added it. The “normal SDK” uses it and builds fine. Just no luck with the eSDK.
> > Any help out there? Poky is pyro. aarch64 SoC target platform with an x86 build host (CentOS 7.3). Basically I just bitbake -c do_populate_sdk_ext core-image-full. I do have a linux kernel recipe that pulls the kernel from the standard kernel.org <http://kernel.org/> repo.
> >
> > ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp --nogpgcheck install kernel-devsrc' returned 1:
> > Added oe-repo repo from file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
> > Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017 UTC.
> > No package kernel-devsrc available.
> > Error: Unable to find a match
> >
> > ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > ERROR: Logfile of failure stored in: /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> > ERROR: Task (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk) failed with exit code '1'
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

[-- Attachment #2: Type: text/html, Size: 5256 bytes --]

Re: extensible SDK build failure

[Russell Peterson]

FYI: For those interested…

Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta layer and directly set the acpaths variable to the STAGING native directory and that seems to work fine.  Works for now but I will try to come up with a cleaner, more generic fix.

acpaths = “-I ${STAGING_DATADIR_NATIVE}/aclocal/“


Regards,

Russell


> On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON <bluehills7@comcast.net> wrote:
> 
> Thank you for the response, Paul. You were correct that I had the TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my image bb file and things seem far more sane... although I must admit I am not 100% sure why it works but I will study it a bit and figure it out. Thanks for your help.
> 
> I have run into another issue while trying to generate the eSDK in that there appears to be an issue with building harfbuzz. From what I can tell, this appears to be an issue with the search paths for the autoreconf call. The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 directory FIRST and therefore not getting the one in harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has the correct m4_pattern_allow.
> 
> Do you think that's a bug or something with my recipe? Seems like I just want to reverse the -I options... but I don't know how, exactly.
> 
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/ --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/ --force
> 
> ../../../autoconf-2.69/lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded from...
> | configure.ac:22: the top level
> | configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
> | If this token and others are legitimate, please use m4_pattern_allow.
> | See the Autoconf documentation.
> | autoreconf: /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf failed with exit status: 1
> | ERROR: Function failed: do_configure (log file is located at /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)
> 
> > On July 31, 2017 at 9:50 AM Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> > 
> > 
> > Hi Russell,
> > 
> > It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK variable at the global level, which you really don't want to do if you're going to be building buildtools-tarball (which eSDK will build as a dependency). I'd suggest moving that setting to your image recipe.
> > 
> > Cheers,
> > Paul
> > 
> > On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> > > Hello, all.
> > > 
> > > I’m trying to build the eSDK for my platform and I just can’t figure out why dnf can’t find kernel-devsrc. It’s there, I added it. The “normal SDK” uses it and builds fine. Just no luck with the eSDK.
> > > Any help out there? Poky is pyro. aarch64 SoC target platform with an x86 build host (CentOS 7.3). Basically I just bitbake -c do_populate_sdk_ext core-image-full. I do have a linux kernel recipe that pulls the kernel from the standard kernel.org <http://kernel.org/> repo.
> > > 
> > > ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp --nogpgcheck install kernel-devsrc' returned 1:
> > > Added oe-repo repo from file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
> > > Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017 UTC.
> > > No package kernel-devsrc available.
> > > Error: Unable to find a match
> > > 
> > > ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > > ERROR: Logfile of failure stored in: /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> > > ERROR: Task (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk) failed with exit code '1'
> > 
> > 
> > -- 
> > 
> > Paul Eggleton
> > Intel Open Source Technology Centre
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: extensible SDK build failure

[RUSSELL PETERSON]

[-- Attachment #1: Type: text/plain, Size: 7765 bytes --]

Frustrating in that I can't get the eSDK to fully build. I'm past the issue
with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
below. Anyone seen this before? From what I can tell these tasks are being
executed out of the run queue.  Not all the messages are from cve-check but most.

Anyone seen this?



ERROR: Task attr-native.do_cve_check attempted to execute unexpectedly
ERROR: Task binutils-native.do_cve_check attempted to execute unexpectedly
ERROR: Task dbus-glib.do_cve_check attempted to execute unexpectedly
ERROR: Task libtool-native.do_cve_check attempted to execute unexpectedly
ERROR: Task fixesproto.do_cve_check attempted to execute unexpectedly
ERROR: Task bc.do_cve_check attempted to execute unexpectedly
ERROR: Task lsof.do_cve_check attempted to execute unexpectedly
ERROR: Task python-setuptools-native.do_cve_check attempted to execute
unexpectedly
ERROR: Task libxrandr-native.do_cve_check attempted to execute unexpectedly
ERROR: Task libpciaccess.do_cve_check attempted to execute unexpectedly
ERROR: Task xf86driproto.do_cve_check attempted to execute unexpectedly
ERROR: Task ncurses-native.do_cve_check attempted to execute unexpectedly

On August 1, 2017 at 8:55 PM Russell Peterson <bluehills7@comcast.net> wrote:

FYI: For those interested…

Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta layer
and directly set the acpaths variable to the STAGING native directory and that
seems to work fine. Works for now but I will try to come up with a cleaner,
more generic fix.

acpaths = “-I ${STAGING_DATADIR_NATIVE}/aclocal/“

Regards,

Russell

> 
>     On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON <bluehills7@comcast.net> wrote:
> 
>     Thank you for the response, Paul. You were correct that I had the
>     TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my
>     image bb file and things seem far more sane... although I must admit I am
>     not 100% sure why it works but I will study it a bit and figure it out.
>     Thanks for your help.
> 
>     I have run into another issue while trying to generate the eSDK in that
>     there appears to be an issue with building harfbuzz. From what I can tell,
>     this appears to be an issue with the search paths for the autoreconf call.
>     The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 directory
>     FIRST and therefore not getting the one in
>     harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has
>     the correct m4_pattern_allow.
> 
>     Do you think that's a bug or something with my recipe? Seems like I just
>     want to reverse the -I options... but I don't know how, exactly.
> 
>     /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf
>     --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/
>     --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/
>     --force
> 
>     ../../../autoconf-2.69/lib/autoconf/specific.m4:368:
>     AC_USE_SYSTEM_EXTENSIONS is expanded from...
>     | configure.ac:22: the top level
>     | configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
>     | If this token and others are legitimate, please use m4_pattern_allow.
>     | See the Autoconf documentation.
>     | autoreconf:
>     /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf
>     failed with exit status: 1
>     | ERROR: Function failed: do_configure (log file is located at
>     /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)
> 
>         > > 
> >         On July 31, 2017 at 9:50 AM Paul Eggleton <paul.eggleton@linux.intel.com>
> >         wrote:
> > 
> >         Hi Russell,
> > 
> >         It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK
> >         variable at the global level, which you really don't want to do if you're
> >         going to be building buildtools-tarball (which eSDK will build as a
> >         dependency). I'd suggest moving that setting to your image recipe.
> > 
> >         Cheers,
> >         Paul
> > 
> >         On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> > 
> >             > > > 
> > >             Hello, all.
> > > 
> > >             I’m trying to build the eSDK for my platform and I just can’t figure out
> > >             why dnf can’t find kernel-devsrc. It’s there, I added it. The “normal
> > >             SDK” uses it and builds fine. Just no luck with the eSDK.
> > >             Any help out there? Poky is pyro. aarch64 SoC target platform with an
> > >             x86 build host (CentOS 7.3). Basically I just bitbake -c
> > >             do_populate_sdk_ext core-image-full. I do have a linux kernel recipe
> > >             that pulls the kernel from the standard kernel.org <http://kernel.org/>
> > >             repo.
> > > 
> > >             ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf.
> > >             Command
> > >             '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf
> > >             -y -c
> > >             /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf
> > >             --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d
> > >             --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
> > >             --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none
> > >             --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp
> > >             --nogpgcheck install kernel-devsrc' returned 1:
> > >             Added oe-repo repo from
> > >             file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
> > >             <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
> > >             Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017
> > >             UTC.
> > >             No package kernel-devsrc available.
> > >             Error: Unable to find a match
> > > 
> > >             ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed:
> > >             do_populate_sdk
> > >             ERROR: Logfile of failure stored in:
> > >             /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> > >             ERROR: Task
> > >             (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk)
> > >             failed with exit code '1'
> > > 
> > >         > > 
> >         --
> > 
> >         Paul Eggleton
> > 
> >         Intel Open Source Technology Centre
> >         --
> > 
> >         _______________________________________________
> >         yocto mailing list
> >         yocto@yoctoproject.org
> >         https://lists.yoctoproject.org/listinfo/yocto
> > 
> >     > 

[-- Attachment #2: Type: text/html, Size: 7240 bytes --]

Re: extensible SDK build failure

[Andrea Galbusera]

[-- Attachment #1: Type: text/plain, Size: 7332 bytes --]

Hi,

On Wed, Aug 2, 2017 at 8:34 PM, RUSSELL PETERSON <bluehills7@comcast.net>
wrote:

> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
> below. Anyone seen this before? From what I can tell these tasks are being
> executed out of the run queue.  Not all the messages are from cve-check
> but most.
>
> Anyone seen this?
>
Are you using devtool to work on recipes/sources? If so, try to run
'devtool reset -a' before building the eSDK.

>
>
> ERROR: Task attr-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task binutils-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task dbus-glib.do_cve_check attempted to execute unexpectedly
> ERROR: Task libtool-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task fixesproto.do_cve_check attempted to execute unexpectedly
> ERROR: Task bc.do_cve_check attempted to execute unexpectedly
> ERROR: Task lsof.do_cve_check attempted to execute unexpectedly
> ERROR: Task python-setuptools-native.do_cve_check attempted to execute
> unexpectedly
> ERROR: Task libxrandr-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task libpciaccess.do_cve_check attempted to execute unexpectedly
> ERROR: Task xf86driproto.do_cve_check attempted to execute unexpectedly
> ERROR: Task ncurses-native.do_cve_check attempted to execute unexpectedly
>
> On August 1, 2017 at 8:55 PM Russell Peterson <bluehills7@comcast.net>
> wrote:
>
> FYI: For those interested…
>
> Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta
> layer
> and directly set the acpaths variable to the STAGING native directory and
> that
> seems to work fine. Works for now but I will try to come up with a cleaner,
> more generic fix.
>
> acpaths = “-I ${STAGING_DATADIR_NATIVE}/aclocal/“
>
> Regards,
>
> Russell
>
> On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON <bluehills7@comcast.net>
> wrote:
>
> Thank you for the response, Paul. You were correct that I had the
> TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my
> image bb file and things seem far more sane... although I must admit I am
> not 100% sure why it works but I will study it a bit and figure it out.
> Thanks for your help.
>
> I have run into another issue while trying to generate the eSDK in that
> there appears to be an issue with building harfbuzz. From what I can tell,
> this appears to be an issue with the search paths for the autoreconf call.
> The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 directory
> FIRST and therefore not getting the one in
> harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has
> the correct m4_pattern_allow.
>
> Do you think that's a bug or something with my recipe? Seems like I just
> want to reverse the -I options... but I don't know how, exactly.
>
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/
> recipe-sysroot-native/usr/bin/autoconf
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-
> poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-
> poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/
> --force
>
> ../../../autoconf-2.69/lib/autoconf/specific.m4:368:
> AC_USE_SYSTEM_EXTENSIONS is expanded from...
> | configure.ac:22: the top level
> | configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
> | If this token and others are legitimate, please use m4_pattern_allow.
> | See the Autoconf documentation.
> | autoreconf:
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/
> recipe-sysroot-native/usr/bin/autoconf
> failed with exit status: 1
> | ERROR: Function failed: do_configure (log file is located at
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-
> linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)
>
> On July 31, 2017 at 9:50 AM Paul Eggleton <paul.eggleton@linux.intel.com>
> wrote:
>
> Hi Russell,
>
> It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK
> variable at the global level, which you really don't want to do if you're
> going to be building buildtools-tarball (which eSDK will build as a
> dependency). I'd suggest moving that setting to your image recipe.
>
> Cheers,
> Paul
>
> On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
>
> Hello, all.
>
> I’m trying to build the eSDK for my platform and I just can’t figure out
> why dnf can’t find kernel-devsrc. It’s there, I added it. The “normal
> SDK” uses it and builds fine. Just no luck with the eSDK.
> Any help out there? Poky is pyro. aarch64 SoC target platform with an
> x86 build host (CentOS 7.3). Basically I just bitbake -c
> do_populate_sdk_ext core-image-full. I do have a linux kernel recipe
> that pulls the kernel from the standard kernel.org <http://kernel.org/>
> repo.
>
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf.
> Command
> '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/
> buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf
> -y -c
> /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/
> buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/
> none/etc/dnf/dnf.conf
> --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/
> x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-
> r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d
> --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-
> nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
> --installroot=/scratch/russell/yocto-00dc025f/work/
> x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-
> r0/sdk/image/opt/poky/2.3.1/sysroots/none
> --setopt=logdir=/scratch/russell/yocto-00dc025f/work/
> x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp
> --nogpgcheck install kernel-devsrc' returned 1:
> Added oe-repo repo from
> file:///scratch/russell/yocto-00dc025f/work/x86_64-
> nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
> <file:///scratch/russell/yocto-00dc025f/work/x86_64-
> nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
> Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017
> UTC.
> No package kernel-devsrc available.
> Error: Unable to find a match
>
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed:
> do_populate_sdk
> ERROR: Logfile of failure stored in:
> /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/
> buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> ERROR: Task
> (/labhome/russell/src/bf/poky/meta/recipes-core/meta/
> buildtools-tarball.bb:do_populate_sdk)
> failed with exit code '1'
>
> --
>
> Paul Eggleton
>
> Intel Open Source Technology Centre
> --
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 8896 bytes --]

Re: extensible SDK build failure

[Russell Peterson]

[-- Attachment #1: Type: text/plain, Size: 9007 bytes --]

Thanks for the help but, no.  I’m just trying to build the eSDK via the normal bitbake process.

Russell

> On Aug 4, 2017, at 11:52 AM, Andrea Galbusera <gizero@gmail.com> wrote:
> 
> Hi,
> 
> On Wed, Aug 2, 2017 at 8:34 PM, RUSSELL PETERSON <bluehills7@comcast.net <mailto:bluehills7@comcast.net>> wrote:
> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
> below. Anyone seen this before? From what I can tell these tasks are being
> executed out of the run queue.  Not all the messages are from cve-check but most.
> 
> Anyone seen this?
> 
> Are you using devtool to work on recipes/sources? If so, try to run 'devtool reset -a' before building the eSDK. 
> 
> 
> 
> 
> ERROR: Task attr-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task binutils-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task dbus-glib.do_cve_check attempted to execute unexpectedly
> ERROR: Task libtool-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task fixesproto.do_cve_check attempted to execute unexpectedly
> ERROR: Task bc.do_cve_check attempted to execute unexpectedly
> ERROR: Task lsof.do_cve_check attempted to execute unexpectedly
> ERROR: Task python-setuptools-native.do_cve_check attempted to execute
> unexpectedly
> ERROR: Task libxrandr-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task libpciaccess.do_cve_check attempted to execute unexpectedly
> ERROR: Task xf86driproto.do_cve_check attempted to execute unexpectedly
> ERROR: Task ncurses-native.do_cve_check attempted to execute unexpectedly
> 
> On August 1, 2017 at 8:55 PM Russell Peterson <bluehills7@comcast.net <mailto:bluehills7@comcast.net>> wrote:
> 
> FYI: For those interested…
> 
> Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta layer
> and directly set the acpaths variable to the STAGING native directory and that
> seems to work fine. Works for now but I will try to come up with a cleaner,
> more generic fix.
> 
> acpaths = “-I ${STAGING_DATADIR_NATIVE}/aclocal/“
> 
> Regards,
> 
> Russell
> 
> On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON <bluehills7@comcast.net <mailto:bluehills7@comcast.net>> wrote:
> 
> Thank you for the response, Paul. You were correct that I had the
> TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my
> image bb file and things seem far more sane... although I must admit I am
> not 100% sure why it works but I will study it a bit and figure it out.
> Thanks for your help.
> 
> I have run into another issue while trying to generate the eSDK in that
> there appears to be an issue with building harfbuzz. From what I can tell,
> this appears to be an issue with the search paths for the autoreconf call.
> The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 directory
> FIRST and therefore not getting the one in
> harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has
> the correct m4_pattern_allow.
> 
> Do you think that's a bug or something with my recipe? Seems like I just
> want to reverse the -I options... but I don't know how, exactly.
> 
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/
> --force
> 
> ../../../autoconf-2.69/lib/autoconf/specific.m4:368:
> AC_USE_SYSTEM_EXTENSIONS is expanded from...
> | configure.ac:22 <http://configure.ac:22/>: the top level
> | configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
> | If this token and others are legitimate, please use m4_pattern_allow.
> | See the Autoconf documentation.
> | autoreconf:
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf
> failed with exit status: 1
> | ERROR: Function failed: do_configure (log file is located at
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)
> 
> On July 31, 2017 at 9:50 AM Paul Eggleton <paul.eggleton@linux.intel.com <mailto:paul.eggleton@linux.intel.com>>
> wrote:
> 
> Hi Russell,
> 
> It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK
> variable at the global level, which you really don't want to do if you're
> going to be building buildtools-tarball (which eSDK will build as a
> dependency). I'd suggest moving that setting to your image recipe.
> 
> Cheers,
> Paul
> 
> On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> 
> Hello, all.
> 
> I’m trying to build the eSDK for my platform and I just can’t figure out
> why dnf can’t find kernel-devsrc. It’s there, I added it. The “normal
> SDK” uses it and builds fine. Just no luck with the eSDK.
> Any help out there? Poky is pyro. aarch64 SoC target platform with an
> x86 build host (CentOS 7.3). Basically I just bitbake -c
> do_populate_sdk_ext core-image-full. I do have a linux kernel recipe
> that pulls the kernel from the standard kernel.org <http://kernel.org/> <http://kernel.org/ <http://kernel.org/>>
> repo.
> 
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf.
> Command
> '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf
> -y -c
> /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf
> --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d
> --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
> --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none
> --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp
> --nogpgcheck install kernel-devsrc' returned 1:
> Added oe-repo repo from
> file:///scratch/russell/yocto- <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>00dc025f/work/x86_64- <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>nativesdk-pokysdk-linux/ <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>buildtools-tarball/1.0-r0/oe- <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>rootfs-repo <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>
> <file:///scratch/russell/ <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>yocto-00dc025f/work/x86_64- <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>nativesdk-pokysdk-linux/ <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>buildtools-tarball/1.0-r0/oe- <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>rootfs-repo <file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo>>
> Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017
> UTC.
> No package kernel-devsrc available.
> Error: Unable to find a match
> 
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed:
> do_populate_sdk
> ERROR: Logfile of failure stored in:
> /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> ERROR: Task
> (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk)
> failed with exit code '1'
> 
> --
> 
> Paul Eggleton
> 
> Intel Open Source Technology Centre
> --
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto <https://lists.yoctoproject.org/listinfo/yocto>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto <https://lists.yoctoproject.org/listinfo/yocto>

[-- Attachment #2: Type: text/html, Size: 13468 bytes --]

Re: extensible SDK build failure

[Paul Eggleton]

Hi Russell,

On Wednesday, 2 August 2017 8:34:11 PM CEST RUSSELL PETERSON wrote:
> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
> below. Anyone seen this before? From what I can tell these tasks are being
> executed out of the run queue.  Not all the messages are from cve-check but
> most.

So there are certain classes that will interfere with the ability of the eSDK 
to lock down the configuration, I wasn't aware of it but cve-check.bbclass is 
apparently one of them. Try adding this to your configuration:

SDK_INHERIT_BLACKLIST = "buildhistory icecc cve-check"

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: extensible SDK build failure

[Russell Peterson]

Thanks, Paul.

That helped, however, I still see some of the same “unexpected” errors for perf tasks as well as my virtual/kernel tasks.  

I presume SDK_INHERIT_BLACKLIST excludes the use of the class for the SDK… but I am unclear as to why I see these errors with my linux-yocto-xxx.bb recipe/tasks.

Thanks again.

Russell


> On Aug 7, 2017, at 2:49 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 
> Hi Russell,
> 
> On Wednesday, 2 August 2017 8:34:11 PM CEST RUSSELL PETERSON wrote:
>> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
>> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
>> below. Anyone seen this before? From what I can tell these tasks are being
>> executed out of the run queue.  Not all the messages are from cve-check but
>> most.
> 
> So there are certain classes that will interfere with the ability of the eSDK 
> to lock down the configuration, I wasn't aware of it but cve-check.bbclass is 
> apparently one of them. Try adding this to your configuration:
> 
> SDK_INHERIT_BLACKLIST = "buildhistory icecc cve-check"
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre

Re: extensible SDK build failure

[Priyanshu Sharma]

[-- Attachment #1: Type: text/plain, Size: 210 bytes --]

Hi Russell,

I'm also hitting the same "unexpected" errors for my linux-yocto-xxx.bb
recipe/tasks while building extensible SDK for my platform. How did it work
for you?

Warm Regards,
Priyanshu Sharma

[-- Attachment #2: Type: text/html, Size: 336 bytes --]