Re: [yocto] extensible SDK build failure

[Priyanshu Sharma]

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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 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  
> 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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] extensible SDK build failure

[Russell Peterson]

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  wrote:
> 
> Hi,
> 
> On Wed, Aug 2, 2017 at 8:34 PM, 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.
> 
> 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  > 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  > 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  >
> 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 

Re: [yocto] extensible SDK build failure

[Andrea Galbusera]

Hi,

On Wed, Aug 2, 2017 at 8:34 PM, 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.
>
> 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 
> 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 
> 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 
> 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 
> repo.
>
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke 

Re: [yocto] extensible SDK build failure

[RUSSELL PETERSON]

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  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  
> 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 
> > 
> > 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 

Re: [yocto] 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  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  
> > 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  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
> > >  
> > > 
> > > 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
> > > 

Re: [yocto] extensible SDK build failure

[RUSSELL PETERSON]

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  
> 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  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
> >  
> > 
> > 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: [yocto] 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  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
>  
> 
> 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] extensible SDK build failure

[Russell Peterson]

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  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
 

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'-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto