SDK and out of tree modules

SDK and out of tree modules

[Andrej Valek]

Hi all,

I have seen, that You have been supporting someone with the similar problem.
So, I would like to ask you as question about current status of failing
task for kernel-devsrc recipe. I have found similar thread about the
same issue, but without final solution
(https://lists.yoctoproject.org/pipermail/yocto/2018-July/042007.html).

I wanted to run populate_sdk_ext on my image (tested on qemuarm and
another arch) with included kernel-devsrc package. It showed me warning
message:
WARNING: image-sdk-1.0-r0 do_populate_sdk_ext: Manifest
build/tmp/sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot
not found?

Mentioned directory has these files:
build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.package_qa
build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.package_write_ipk
build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.packagedata
build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.populate_lic

But the file "manifest-allarch-kernel-devsrc.populate_sysroot" is
missing. I guess, due to do_populate_sysroot[noexec] = "1" in
kernel-devsrc recipe.

Isn't possible to have this package included in image for populate task?
Is it somehow fixed?

Many thanks for support,
Andrej

* sorry if you have received this message multiple times, ...network issues

Re: SDK and out of tree modules

[richard.purdie]

On Tue, 2018-09-25 at 16:51 +0200, Andrej Valek wrote:
> I have seen, that You have been supporting someone with the similar
> problem.
> So, I would like to ask you as question about current status of
> failing task for kernel-devsrc recipe. I have found similar thread
> about the same issue, but without final solution
> (https://lists.yoctoproject.org/pipermail/yocto/2018-July/042007.html
> ).
> 
> I wanted to run populate_sdk_ext on my image (tested on qemuarm and
> another arch) with included kernel-devsrc package. It showed me
> warning
> message:
> WARNING: image-sdk-1.0-r0 do_populate_sdk_ext: Manifest
> build/tmp/sstate-control/manifest-allarch-kernel-
> devsrc.populate_sysroot
> not found?
> 
> Mentioned directory has these files:
> build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.package_qa
> build/tmp/sstate-control/manifest-qemuarm-kernel-
> devsrc.package_write_ipk
> build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.packagedata
> build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.populate_lic
> 
> But the file "manifest-allarch-kernel-devsrc.populate_sysroot" is
> missing. I guess, due to do_populate_sysroot[noexec] = "1" in
> kernel-devsrc recipe.
> 
> Isn't possible to have this package included in image for populate
> task?
> Is it somehow fixed?

Is this with master? I did resolve a number of sdk manifest warnings
recently so before I start looking more closely I'd like to check this
was seen with latest master.

You're right that the noexec would likely cause this issue.

Cheers,

Richard

Re: SDK and out of tree modules

[Andrej Valek]

Hello Richard,

I am working on derivate of pyro branch.
So I have setup new machine based on master (without my modifications),
but the problem is still there.

What I have made:
IMAGE_INSTALL += "kernel-devsrc"

core-image-minimal -c populate_sdk_ext

Now the manifests in directory have different names:
$ find . -name "*kernel*"
./manifest-qemuarm-kernel-devsrc.populate_lic
./manifest-qemuarm-kernel-devsrc.package
./manifest-qemuarm-kernel-devsrc.packagedata
./manifest-qemuarm-kernel-devsrc.package_write_rpm
./manifest-qemuarm-kernel-devsrc.package_qa

So now allarch has been replaced by qemuarm. Seems to be, that something
has been changed in PKG_ARCH.

But warnings are still the same:
WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
allarch x86_64_x86_64-nativesdk (variant '')?
WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
allarch x86_64_x86_64-nativesdk (variant '')?

But why is trying to find nativesdk manifests instead of qemuarm? Isn't
it caused by IMAGE_INSTALL in populate task?
Anyway, the problem is the same. Still couldn't find the
.populate_sysroot manifest file due to mentioned [noxec].

Regards,
Andrej

On 9/25/18 5:22 PM, richard.purdie@linuxfoundation.org wrote:
> On Tue, 2018-09-25 at 16:51 +0200, Andrej Valek wrote:
>> I have seen, that You have been supporting someone with the similar
>> problem.
>> So, I would like to ask you as question about current status of
>> failing task for kernel-devsrc recipe. I have found similar thread
>> about the same issue, but without final solution
>> (https://lists.yoctoproject.org/pipermail/yocto/2018-July/042007.html
>> ).
>>
>> I wanted to run populate_sdk_ext on my image (tested on qemuarm and
>> another arch) with included kernel-devsrc package. It showed me
>> warning
>> message:
>> WARNING: image-sdk-1.0-r0 do_populate_sdk_ext: Manifest
>> build/tmp/sstate-control/manifest-allarch-kernel-
>> devsrc.populate_sysroot
>> not found?
>>
>> Mentioned directory has these files:
>> build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.package_qa
>> build/tmp/sstate-control/manifest-qemuarm-kernel-
>> devsrc.package_write_ipk
>> build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.packagedata
>> build/tmp/sstate-control/manifest-qemuarm-kernel-devsrc.populate_lic
>>
>> But the file "manifest-allarch-kernel-devsrc.populate_sysroot" is
>> missing. I guess, due to do_populate_sysroot[noexec] = "1" in
>> kernel-devsrc recipe.
>>
>> Isn't possible to have this package included in image for populate
>> task?
>> Is it somehow fixed?
> 
> Is this with master? I did resolve a number of sdk manifest warnings
> recently so before I start looking more closely I'd like to check this
> was seen with latest master.
> 
> You're right that the noexec would likely cause this issue.
> 
> Cheers,
> 
> Richard
> 

Re: SDK and out of tree modules

[richard.purdie]

On Wed, 2018-09-26 at 14:22 +0200, Andrej Valek wrote:
> Hello Richard,
> 
> I am working on derivate of pyro branch.
> So I have setup new machine based on master (without my
> modifications),
> but the problem is still there.
> 
> What I have made:
> IMAGE_INSTALL += "kernel-devsrc"
> 
> core-image-minimal -c populate_sdk_ext
> 
> Now the manifests in directory have different names:
> $ find . -name "*kernel*"
> ./manifest-qemuarm-kernel-devsrc.populate_lic
> ./manifest-qemuarm-kernel-devsrc.package
> ./manifest-qemuarm-kernel-devsrc.packagedata
> ./manifest-qemuarm-kernel-devsrc.package_write_rpm
> ./manifest-qemuarm-kernel-devsrc.package_qa
> 
> So now allarch has been replaced by qemuarm. Seems to be, that
> something
> has been changed in PKG_ARCH.
> 
> But warnings are still the same:
> WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> devsrc.populate_sysroot
> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> allarch x86_64_x86_64-nativesdk (variant '')?
> WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> devsrc.populate_sysroot
> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> allarch x86_64_x86_64-nativesdk (variant '')?
>
> But why is trying to find nativesdk manifests instead of qemuarm? 

It will search all the PACKAGE_ARCHS variants in order.

> Isn't it caused by IMAGE_INSTALL in populate task?
> Anyway, the problem is the same. Still couldn't find the
> .populate_sysroot manifest file due to mentioned [noxec].

I've given this a fair bit of thought. Could you try replacing the
[noexec] with:

deltask do_populate_sysroot
deltask do_populate_sysroot_setscene

I think thay may be the right fix. Whether it causes other issues,
we'll see...

Cheers,

Richard

[PATCH 0/1] kernel-devsrc: fix searching for non-existing

[Andrej Valek]

I have tested your proposal fix and it works.
I have removed the _setscene, because _sysroot is enough.
To make recipe consistent, I have also changed the rest of [noexec]s.

Andrej Valek (1):
  kernel-devsrc: fix searching for non-existing manifest files

 meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH 1/1] kernel-devsrc: fix searching for non-existing manifest files

[Andrej Valek]

Even if the do_populate_sysroot have had set-up noexec flag, populate_sdk's
tasks were trying to find .populate_sysroot manifest file. Change noexec
flag settings to delete appreciated tasks.

WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm allarch x86_64_x86_64-nativesdk (variant '')?

WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm allarch x86_64_x86_64-nativesdk (variant '')?

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 463305e89a..716e908af8 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -20,12 +20,12 @@ do_install[depends] += "virtual/kernel:do_shared_workdir"
 do_install[depends] += "virtual/kernel:do_install"
 
 # There's nothing to do here, except install the source where we can package it
-do_fetch[noexec] = "1"
-do_unpack[noexec] = "1"
-do_patch[noexec] = "1"
-do_configure[noexec] = "1"
-do_compile[noexec] = "1"
-do_populate_sysroot[noexec] = "1"
+deltask do_fetch
+deltask do_unpack
+deltask do_patch
+deltask do_configure
+deltask do_compile
+deltask do_populate_sysroot
 
 S = "${STAGING_KERNEL_DIR}"
 B = "${STAGING_KERNEL_BUILDDIR}"
-- 
2.11.0

Re: [PATCH 1/1] kernel-devsrc: fix searching for non-existing manifest files

[Khem Raj]

On Wed, Sep 26, 2018 at 6:29 AM Andrej Valek <andrej.valek@siemens.com> wrote:
>
> Even if the do_populate_sysroot have had set-up noexec flag, populate_sdk's
> tasks were trying to find .populate_sysroot manifest file. Change noexec
> flag settings to delete appreciated tasks.
>
> WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm allarch x86_64_x86_64-nativesdk (variant '')?
>
> WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-devsrc.populate_sysroot
> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm allarch x86_64_x86_64-nativesdk (variant '')?
>
> Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
> ---
>  meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 463305e89a..716e908af8 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -20,12 +20,12 @@ do_install[depends] += "virtual/kernel:do_shared_workdir"
>  do_install[depends] += "virtual/kernel:do_install"
>
>  # There's nothing to do here, except install the source where we can package it
> -do_fetch[noexec] = "1"
> -do_unpack[noexec] = "1"
> -do_patch[noexec] = "1"
> -do_configure[noexec] = "1"
> -do_compile[noexec] = "1"
> -do_populate_sysroot[noexec] = "1"
> +deltask do_fetch
> +deltask do_unpack
> +deltask do_patch
> +deltask do_configure
> +deltask do_compile
> +deltask do_populate_sysroot
>

LGTM

>  S = "${STAGING_KERNEL_DIR}"
>  B = "${STAGING_KERNEL_BUILDDIR}"
> --
> 2.11.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/1] kernel-devsrc: fix searching for non-existing manifest files

[Richard Purdie]

On Wed, 2018-09-26 at 15:28 +0200, Andrej Valek wrote:
> Even if the do_populate_sysroot have had set-up noexec flag,
> populate_sdk's
> tasks were trying to find .populate_sysroot manifest file. Change
> noexec
> flag settings to delete appreciated tasks.
> 
> WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> devsrc.populate_sysroot
> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> allarch x86_64_x86_64-nativesdk (variant '')?
> 
> WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> devsrc.populate_sysroot
> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> allarch x86_64_x86_64-nativesdk (variant '')?
> 
> Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
> ---
>  meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 463305e89a..716e908af8 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -20,12 +20,12 @@ do_install[depends] +=
> "virtual/kernel:do_shared_workdir"
>  do_install[depends] += "virtual/kernel:do_install"
>  
>  # There's nothing to do here, except install the source where we can
> package it
> -do_fetch[noexec] = "1"
> -do_unpack[noexec] = "1"
> -do_patch[noexec] = "1"
> -do_configure[noexec] = "1"
> -do_compile[noexec] = "1"
> -do_populate_sysroot[noexec] = "1"
> +deltask do_fetch
> +deltask do_unpack
> +deltask do_patch
> +deltask do_configure
> +deltask do_compile
> +deltask do_populate_sysroot
>  

This triggered some failures in the autobuilder tests:

https://autobuilder.yoctoproject.org/typhoon/#/builders/8/builds/78/steps/7/logs/step1b
https://autobuilder.yoctoproject.org/typhoon/#/builders/19/builds/70/steps/7/logs/step1c
https://autobuilder.yoctoproject.org/typhoon/#/builders/27/builds/77/steps/7/logs/step1c

(https://wiki.yoctoproject.org/wiki/BuildLog#2578 if that is clearer,
the stdio log shows which following log(s) have the errors)

why, I'm not sure...

Cheers,

Richard

Re: [PATCH 1/1] kernel-devsrc: fix searching for non-existing manifest files

[Richard Purdie]

On Wed, 2018-09-26 at 23:30 +0100, Richard Purdie wrote:
> On Wed, 2018-09-26 at 15:28 +0200, Andrej Valek wrote:
> > Even if the do_populate_sysroot have had set-up noexec flag,
> > populate_sdk's
> > tasks were trying to find .populate_sysroot manifest file. Change
> > noexec
> > flag settings to delete appreciated tasks.
> > 
> > WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
> > build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> > devsrc.populate_sysroot
> > not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> > allarch x86_64_x86_64-nativesdk (variant '')?
> > 
> > WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
> > build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> > devsrc.populate_sysroot
> > not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> > allarch x86_64_x86_64-nativesdk (variant '')?
> > 
> > Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
> > ---
> >  meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > index 463305e89a..716e908af8 100644
> > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > @@ -20,12 +20,12 @@ do_install[depends] +=
> > "virtual/kernel:do_shared_workdir"
> >  do_install[depends] += "virtual/kernel:do_install"
> >  
> >  # There's nothing to do here, except install the source where we
> > can
> > package it
> > -do_fetch[noexec] = "1"
> > -do_unpack[noexec] = "1"
> > -do_patch[noexec] = "1"
> > -do_configure[noexec] = "1"
> > -do_compile[noexec] = "1"
> > -do_populate_sysroot[noexec] = "1"
> > +deltask do_fetch
> > +deltask do_unpack
> > +deltask do_patch
> > +deltask do_configure
> > +deltask do_compile
> > +deltask do_populate_sysroot
> >  
> 
> This triggered some failures in the autobuilder tests:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/8/builds/78/s
> teps/7/logs/step1b
> https://autobuilder.yoctoproject.org/typhoon/#/builders/19/builds/70/
> steps/7/logs/step1c
> https://autobuilder.yoctoproject.org/typhoon/#/builders/27/builds/77/
> steps/7/logs/step1c
> 
> (https://wiki.yoctoproject.org/wiki/BuildLog#2578 if that is clearer,
> the stdio log shows which following log(s) have the errors)
> 
> why, I'm not sure...

I think its because:

module-base.bbclass:do_configure[depends] += "make-mod-scripts:do_compile"

and the dependency goes missing when you delete the configure task.

Cheers,

Richard

Re: [PATCH 1/1] kernel-devsrc: fix searching for non-existing manifest files

[Khem Raj]

On Wed, Sep 26, 2018 at 4:12 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Wed, 2018-09-26 at 23:30 +0100, Richard Purdie wrote:
> > On Wed, 2018-09-26 at 15:28 +0200, Andrej Valek wrote:
> > > Even if the do_populate_sysroot have had set-up noexec flag,
> > > populate_sdk's
> > > tasks were trying to find .populate_sysroot manifest file. Change
> > > noexec
> > > flag settings to delete appreciated tasks.
> > >
> > > WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
> > > build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> > > devsrc.populate_sysroot
> > > not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> > > allarch x86_64_x86_64-nativesdk (variant '')?
> > >
> > > WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
> > > build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
> > > devsrc.populate_sysroot
> > > not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
> > > allarch x86_64_x86_64-nativesdk (variant '')?
> > >
> > > Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
> > > ---
> > >  meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > > b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > > index 463305e89a..716e908af8 100644
> > > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > > @@ -20,12 +20,12 @@ do_install[depends] +=
> > > "virtual/kernel:do_shared_workdir"
> > >  do_install[depends] += "virtual/kernel:do_install"
> > >
> > >  # There's nothing to do here, except install the source where we
> > > can
> > > package it
> > > -do_fetch[noexec] = "1"
> > > -do_unpack[noexec] = "1"
> > > -do_patch[noexec] = "1"
> > > -do_configure[noexec] = "1"
> > > -do_compile[noexec] = "1"
> > > -do_populate_sysroot[noexec] = "1"
> > > +deltask do_fetch
> > > +deltask do_unpack
> > > +deltask do_patch
> > > +deltask do_configure
> > > +deltask do_compile
> > > +deltask do_populate_sysroot
> > >
> >
> > This triggered some failures in the autobuilder tests:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/8/builds/78/s
> > teps/7/logs/step1b
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/19/builds/70/
> > steps/7/logs/step1c
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/27/builds/77/
> > steps/7/logs/step1c
> >
> > (https://wiki.yoctoproject.org/wiki/BuildLog#2578 if that is clearer,
> > the stdio log shows which following log(s) have the errors)
> >
> > why, I'm not sure...
>
> I think its because:
>
> module-base.bbclass:do_configure[depends] += "make-mod-scripts:do_compile"
>
> and the dependency goes missing when you delete the configure task.

this dependency seems redundant for devsrc

>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/1] kernel-devsrc: fix searching for non-existing manifest files

[Andrej Valek]

Ok, so we can do this, like in image.bbclass:

do_fetch[noexec] = "1"
do_unpack[noexec] = "1"
do_patch[noexec] = "1"
do_configure[noexec] = "1"
do_compile[noexec] = "1"
do_install[noexec] = "1"
deltask do_populate_sysroot

Should I take a care of it?

Regards,
Andrej

On 9/27/18 1:52 AM, Khem Raj wrote:
> On Wed, Sep 26, 2018 at 4:12 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>
>> On Wed, 2018-09-26 at 23:30 +0100, Richard Purdie wrote:
>>> On Wed, 2018-09-26 at 15:28 +0200, Andrej Valek wrote:
>>>> Even if the do_populate_sysroot have had set-up noexec flag,
>>>> populate_sdk's
>>>> tasks were trying to find .populate_sysroot manifest file. Change
>>>> noexec
>>>> flag settings to delete appreciated tasks.
>>>>
>>>> WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest
>>>> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
>>>> devsrc.populate_sysroot
>>>> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
>>>> allarch x86_64_x86_64-nativesdk (variant '')?
>>>>
>>>> WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest
>>>> build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-kernel-
>>>> devsrc.populate_sysroot
>>>> not found in qemuarm armv5te armv5e armv5t armv5 armv4t armv4 arm
>>>> allarch x86_64_x86_64-nativesdk (variant '')?
>>>>
>>>> Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
>>>> ---
>>>>  meta/recipes-kernel/linux/kernel-devsrc.bb | 12 ++++++------
>>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
>>>> b/meta/recipes-kernel/linux/kernel-devsrc.bb
>>>> index 463305e89a..716e908af8 100644
>>>> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
>>>> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
>>>> @@ -20,12 +20,12 @@ do_install[depends] +=
>>>> "virtual/kernel:do_shared_workdir"
>>>>  do_install[depends] += "virtual/kernel:do_install"
>>>>
>>>>  # There's nothing to do here, except install the source where we
>>>> can
>>>> package it
>>>> -do_fetch[noexec] = "1"
>>>> -do_unpack[noexec] = "1"
>>>> -do_patch[noexec] = "1"
>>>> -do_configure[noexec] = "1"
>>>> -do_compile[noexec] = "1"
>>>> -do_populate_sysroot[noexec] = "1"
>>>> +deltask do_fetch
>>>> +deltask do_unpack
>>>> +deltask do_patch
>>>> +deltask do_configure
>>>> +deltask do_compile
>>>> +deltask do_populate_sysroot
>>>>
>>>
>>> This triggered some failures in the autobuilder tests:
>>>
>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/8/builds/78/s
>>> teps/7/logs/step1b
>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/19/builds/70/
>>> steps/7/logs/step1c
>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/27/builds/77/
>>> steps/7/logs/step1c
>>>
>>> (https://wiki.yoctoproject.org/wiki/BuildLog#2578 if that is clearer,
>>> the stdio log shows which following log(s) have the errors)
>>>
>>> why, I'm not sure...
>>
>> I think its because:
>>
>> module-base.bbclass:do_configure[depends] += "make-mod-scripts:do_compile"
>>
>> and the dependency goes missing when you delete the configure task.
> 
> this dependency seems redundant for devsrc
> 
>>
>> Cheers,
>>
>> Richard
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: SDK and out of tree modules

[RUSSELL PETERSON]

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

I have started looking at this more closely and I have a few questions. Hope someone knows or has seen these issues before.

1. When running create_filtered task list I see failures. This is mainly due to the fact that the sdkbasepath getting renamed to tmp-renamed-sdk fails. I have bypassed this to get around it but it seems like it should work. Renaming <...>/sdk-ext/image/opt/poky/2.4.1 to <...>sdk-ext/image/tmp-renamed-sdk doesn't seem to work.

2. Understanding the sstate-cache took some time but I think I understand the basic idea now. The problem I was seeing relates to the fact that my build directory and my temp directory are on different disks. Hence, when I delete the build directory, the cache gets deleted. I would think that making core-image-full again would regenerate the sstate-cache but it does not. The only way I see the sstate-cache regenerated is by deleting the tmp directory completely and starting over. Without the cache, building the sdk-ext fails with about 5000 "should have been setscened" errors. As the ext sdk clearly has a dependency there... why isn't the state cache re-created?? Probably just don't quite understand state yet, I guess.

3. Finally, I have the ext sdk built... tried to install it... failed with an error telling me TMPDIR has changed and I need to rebuild or change it back. I assume this is related to me setting TMPDIR in the original local.conf? Anyone else see this? Seems like unless TMPDIR is set to the default (TOPDIR/tmp) the SDK won't work??

Regards,

Russell

> On July 25, 2018 at 9:01 AM RUSSELL PETERSON <bluehills7@comcast.net> wrote:
>
>
> So, this seems broken to me. I managed to get around this issue (sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?) by appending PACKAGE_EXTRA_ARCHS with the MACHINE_ARCH for my bsp. While PACKAGE_ARCHS now has a duplicate in it (it already includes MACHINE_ARCH as well as PACKAGE_EXTRA_ARCH), the python code in staging_populate_sysroot seems to require this or it looks for the wrong manifest file.
>
> Also, when building the eSDK, dnf seems very confused about what packages are compatible. It's looking for my SoC arch packages... but then won't accept aarch64 as being compatible. I needed to set:
>
> ALL_MULTILIB_PACKAGE_ARCHS =+ " ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}"
>
> to get /etc/dnf/vars/arch to update correctly. This is a bit tedious. I'm now having a similar issue because dnf doesn't seem to like an arch of x86_64-nativesdk. Do I update ALL_MULTILIB_PACKAGE_ARCHS again?? Ug.
>
> --Russ
>
>
> > On July 24, 2018 at 8:36 AM RUSSELL PETERSON <bluehills7@comcast.net> wrote:
> >
> >
> > I am running Poky Rocko at the HEAD (just updated yesterday) and see the following when I attempt to build the eSDK:
> >
> > sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?
> >
> > I see this has been an issue with others as well. It looks like Paul had a fix around April but then the trail went silent so I'm not sure if there was a fix or if that fix went into Rocko. Anyone?
> >
> > --Russ
> >
> > > On July 21, 2018 at 4:42 PM Russell Peterson <bluehills7@comcast.net> wrote:
> > >
> > >
> > > No, just the standard SDK. I was having issues building the eSDK back when we used pyro and never fully figured it out… but we have since upgraded to rocko. I should revisit the eSDK and see if it works for me now or find the root cause since it sounds useful.
> > >
> > > Thanks, Khem.
> > >
> > > —Russ
> > >
> > >
> > > > On Jul 21, 2018, at 1:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > > >
> > > > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson <bluehills7@comcast.net> wrote:
> > > >>
> > > >> Hello,
> > > >>
> > > >> I have been building some modules using the SDK for a while now. This is mostly for development flow purposes but we have had a few customers doing this as well. To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host. Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app). Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe? I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).
> > > >>
> > > >
> > > > are you using extensible SDK ? in that case I think do_make_scripts
> > > > from module-base.bbclass should be helpful
> > > >
> > > >> —Russ
> > > >>
> > > >> --
> > > >> _______________________________________________
> > > >> yocto mailing list
> > > >> yocto@yoctoproject.org
> > > >> https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > --
> > > _______________________________________________
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> > --
> > _______________________________________________
> > 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: 6687 bytes --]

Re: SDK and out of tree modules

[RUSSELL PETERSON]

So, this seems broken to me.  I managed to get around this issue (sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?) by appending PACKAGE_EXTRA_ARCHS with the MACHINE_ARCH for my bsp.  While PACKAGE_ARCHS now has a duplicate in it (it already includes MACHINE_ARCH as well as PACKAGE_EXTRA_ARCH), the python code in staging_populate_sysroot seems to require this or it looks for the wrong manifest file.

Also, when building the eSDK, dnf seems very confused about what packages are compatible.  It's looking for my SoC arch packages... but then won't accept aarch64 as being compatible.  I needed to set:

ALL_MULTILIB_PACKAGE_ARCHS =+ " ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}"

to get /etc/dnf/vars/arch to update correctly.  This is a bit tedious.  I'm now having a similar issue because dnf doesn't seem to like an arch of x86_64-nativesdk.  Do I update ALL_MULTILIB_PACKAGE_ARCHS again??  Ug.

--Russ
 

> On July 24, 2018 at 8:36 AM RUSSELL PETERSON <bluehills7@comcast.net> wrote:
> 
> 
> I am running Poky Rocko at the HEAD (just updated yesterday) and see the following when I attempt to build the eSDK:
> 
> sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?
> 
> I see this has been an issue with others as well.  It looks like Paul had a fix around April but then the trail went silent so I'm not sure if there was a fix or if that fix went into Rocko.  Anyone?
> 
> --Russ
> 
> > On July 21, 2018 at 4:42 PM Russell Peterson <bluehills7@comcast.net> wrote:
> > 
> > 
> > No, just the standard SDK.  I was having issues building the eSDK back when we used pyro and never fully figured it out… but we have since upgraded to rocko.  I should revisit the eSDK and see if it works for me now or find the root cause since it sounds useful.
> > 
> > Thanks, Khem.
> > 
> > —Russ
> > 
> > 
> > > On Jul 21, 2018, at 1:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > > 
> > > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson <bluehills7@comcast.net> wrote:
> > >> 
> > >> Hello,
> > >> 
> > >> I have been building some modules using the SDK for a while now.  This is mostly for development flow purposes but we have had a few customers doing this as well.  To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app).  Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe?  I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).
> > >> 
> > > 
> > > are you using extensible SDK ? in that case I think do_make_scripts
> > > from module-base.bbclass should be helpful
> > > 
> > >> —Russ
> > >> 
> > >> --
> > >> _______________________________________________
> > >> yocto mailing list
> > >> yocto@yoctoproject.org
> > >> https://lists.yoctoproject.org/listinfo/yocto
> > 
> > -- 
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: SDK and out of tree modules

[RUSSELL PETERSON]

I am running Poky Rocko at the HEAD (just updated yesterday) and see the following when I attempt to build the eSDK:

sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?

I see this has been an issue with others as well.  It looks like Paul had a fix around April but then the trail went silent so I'm not sure if there was a fix or if that fix went into Rocko.  Anyone?

--Russ

> On July 21, 2018 at 4:42 PM Russell Peterson <bluehills7@comcast.net> wrote:
> 
> 
> No, just the standard SDK.  I was having issues building the eSDK back when we used pyro and never fully figured it out… but we have since upgraded to rocko.  I should revisit the eSDK and see if it works for me now or find the root cause since it sounds useful.
> 
> Thanks, Khem.
> 
> —Russ
> 
> 
> > On Jul 21, 2018, at 1:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > 
> > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson <bluehills7@comcast.net> wrote:
> >> 
> >> Hello,
> >> 
> >> I have been building some modules using the SDK for a while now.  This is mostly for development flow purposes but we have had a few customers doing this as well.  To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app).  Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe?  I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).
> >> 
> > 
> > are you using extensible SDK ? in that case I think do_make_scripts
> > from module-base.bbclass should be helpful
> > 
> >> —Russ
> >> 
> >> --
> >> _______________________________________________
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> 
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: SDK and out of tree modules

[Russell Peterson]

No, just the standard SDK.  I was having issues building the eSDK back when we used pyro and never fully figured it out… but we have since upgraded to rocko.  I should revisit the eSDK and see if it works for me now or find the root cause since it sounds useful.

Thanks, Khem.

—Russ


> On Jul 21, 2018, at 1:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson <bluehills7@comcast.net> wrote:
>> 
>> Hello,
>> 
>> I have been building some modules using the SDK for a while now.  This is mostly for development flow purposes but we have had a few customers doing this as well.  To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app).  Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe?  I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).
>> 
> 
> are you using extensible SDK ? in that case I think do_make_scripts
> from module-base.bbclass should be helpful
> 
>> —Russ
>> 
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: SDK and out of tree modules

[Khem Raj]

On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson <bluehills7@comcast.net> wrote:
>
> Hello,
>
> I have been building some modules using the SDK for a while now.  This is mostly for development flow purposes but we have had a few customers doing this as well.  To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app).  Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe?  I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).
>

are you using extensible SDK ? in that case I think do_make_scripts
from module-base.bbclass should be helpful

> —Russ
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

SDK and out of tree modules

[Russell Peterson]

Hello,

I have been building some modules using the SDK for a while now.  This is mostly for development flow purposes but we have had a few customers doing this as well.  To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app).  Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe?  I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).

—Russ