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 <bluehil...@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 <bluehil...@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.eggle...@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

Reply via email to