Re: [yocto] Recipe availability through eSDK (cppzmq)

[Paul Eggleton]

Hi Trevor,

On Friday, 4 May 2018 3:26:18 PM NZST Trevor Woerner wrote:
> On Wed, May 2, 2018 at 5:19 PM, Paul Eggleton  > wrote:
> > 1) If you want the cppzmq development files to be available *within* the
> > eSDK
> > (so you can write code to use them using the eSDK), even if they are not
> > brought in by way of the image containing a package from the cppzmq
> > recipe,
> > you can install them into the eSDK by running this within the eSDK
> > environment:
> >
> > devtool sdk-install -s cppzmq
> >
> 
> Is sdk-install new? It doesn't show up when I run "devtool help"

It's only available within the eSDK - you won't see it if you run devtool next 
to the build system.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] Recipe availability through eSDK (cppzmq)

[Trevor Woerner]

On Wed, May 2, 2018 at 5:19 PM, Paul Eggleton  wrote:

> 1) If you want the cppzmq development files to be available *within* the
> eSDK
> (so you can write code to use them using the eSDK), even if they are not
> brought in by way of the image containing a package from the cppzmq
> recipe,
> you can install them into the eSDK by running this within the eSDK
> environment:
>
> devtool sdk-install -s cppzmq
>

Is sdk-install new? It doesn't show up when I run "devtool help"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PXE booting ISO image fails with message "Waiting for removable media..."

[Raymond Yeung]

Hi Vincent,


I'd recently gone through similar issue that you're experiencing.  The "Waiting 
for Removable Media" hang had been there for at least 7-8 years.  A workaround 
was put in around 2013.  See here:

https://patchwork.openembedded.org/patch/42291/


Add "debugshell=30" (30 is in second, for timeout, or any other reasonable 
value that you like) to the append
statement in your pxelinux.cfg/default file.  Then you'd timeout when you 
"normally" hangs, break into a shell,
where you could initiate udhcpc to configure networking, after which you could 
transfer your bootable image onto
your RAM, and write out onto your HDD/SSD.

It seems this kernel boot option of debugshell isn't documented officially in 
kernel-parameters.txt file.

You could also look for init-live.sh on your yocto tree, and look for "Waiting 
for Removable Media", and see the
surrounding code to get a fell how this debugshell thing works.

Raymond




Date: Thu, 3 May 2018 14:27:46 +
From: Vincent Daanen 
To: "yocto@yoctoproject.org" 
Subject: [yocto] PXE booting ISO image fails with message "Waiting for
removable media..."
Message-ID:



Content-Type: text/plain; charset="utf-8"

Hi,

We want to deploy image created with Yocto (Rocko) via PXE.
The target board is a Intel-based SBC (AAEON GENE BT05).

At first, we tried with a ISO from Archlinux and the target-board successfully 
booted.

Then we create a ISO using Yocto but boot hangs with a message ?Waiting for 
removable media ...?.
Googling this message points me to this post: 
http://thread.gmane.org/gmane.linux.embedded.yocto.general/20611 which relates 
exactly the same problem, explain why the issue raises, gives an indication to 
how to fix .. and that?s all ?

So at this point, we know that the problem comes from the 
/recipes-core/initrdscripts/files/init-live.sh file.
It seems searching for an /dev/sdx should be protected by a timeout set by 
default to 30 secs but during our trials, no timeout seems to exist.

What we do not understand, is how to highlight the differences between the 
Yocto-based and the Archlinux ISO files so that we can ?unblock? the boot using 
the Yocto-based ISO file.

Is the someone here how could help?

Thanks

Vincent

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

Re: [yocto] Problem with Python when running oe-init-build-env

[Zoran Stojsavljevic]

Hello Ross,

Seems that you are correct. I have checked on my host Fedora 27:

[vuser@localhost bin]$ pwd
/usr/bin
[vuser@localhost bin]$ uname -r
4.16.5-200.fc27.x86_64
[vuser@localhost bin]$ ls -al pyth*
lrwxrwxrwx. 1 root root 7 Mar 14 14:36 python -> python2
lrwxrwxrwx. 1 root root 9 Mar 14 14:36 python2 -> python2.7
-rwxr-xr-x. 1 root root  7128 Mar 14 14:37 python2.7
lrwxrwxrwx. 1 root root 9 Apr  4 17:03 python3 -> python3.6
-rwxr-xr-x. 2 root root 11240 Apr  4 17:03 python3.6
-rwxr-xr-x. 2 root root 11240 Apr  4 17:03 python3.6m
-rwxr-xr-x. 1 root root   388 Jul 28  2017 python3-chardetect
-rwxr-xr-x. 1 root root   387 Nov 16 18:05 python3-coverage
-rwxr-xr-x. 1 root root   396 Jul 28  2017 python3-mako-render
-rwxr-xr-x. 1 root root   392 Jul 28  2017 python3-pyinotify
[vuser@localhost bin]$

I also have checked on my Debian 9.4.0 VM:

user@unassigned-hostname:/usr/bin$ pwd
/usr/bin
user@unassigned-hostname:/usr/bin$ uname -r
4.9.0-6-amd64
user@unassigned-hostname:/usr/bin$ ls -al pyth*
lrwxrwxrwx 1 root root   9 May  3 11:03 python -> python2.7
lrwxrwxrwx 1 root root   9 May  3 11:03 python2 -> python2.7
-rwxr-xr-x 1 root root 3779512 Nov 24 12:33 python2.7
lrwxrwxrwx 1 root root   9 May  3 11:03 python3 -> python3.5
-rwxr-xr-x 2 root root 4747120 Jan 19  2017 python3.5
-rwxr-xr-x 2 root root 4747120 Jan 19  2017 python3.5m
lrwxrwxrwx 1 root root  10 May  3 11:03 python3m -> python3.5m
user@unassigned-hostname:/usr/bin$

Zoran
___


On Thu, May 3, 2018 at 6:00 PM, Burton, Ross  wrote:

> I suggest you have a look through the feed that you link to and see if it
> provides a package which has /usr/bin/python3 in, and if it doesn't then
> just make a python3 -> python3.6 symlink (which is all you need).
>
> Ross
>
> On 2 May 2018 at 20:28, Raymond Yeung  wrote:
>
>> Thanks Zoran.
>>
>>
>> My Linux build machine uses Centos 7.  I thought I'd done the
>> installation to Python 3.6.5.  If this is not Python3 > 3.4.0, then I'm
>> confused.  The link I follow for installation is here:
>> https://janikarhunen.fi/how-to-install-python-3-6-1-on-centos-7.html
>>
>> > python3.6 -V
>>
>> Python 3.6.5
>>
>> >python -V
>>
>> Python 2.7.5
>>
>>
>> Anyway, I realize what went wrong.  I'd Krogoth (a 2016 Poky) running
>> before.  Now as I'm migrating to Rocko (a 2017 Poky), I try to solve a
>> Python versioning issue by installing Python only (as above).  However,
>> there may be other packages I need to update.  After getting latest
>> Reference Manual, download and install latest environment, I no longer have
>> python3 issue.  However, the Python version of why Python3.6 won't satisfy
>> Python > 3.4.0 still puzzles me (though no longer blocking me).
>>
>>
>> Raymond
>>
>>
>> --
>> *From:* Zoran Stojsavljevic 
>> *Sent:* Tuesday, May 1, 2018 11:19 PM
>> *To:* Raymond Yeung
>> *Cc:* yocto@yoctoproject.org
>> *Subject:* Re: [yocto] Problem with Python when running oe-init-build-env
>>
>> Hello Raymond,
>>
>> The problem is that you (talking about your host distro):
>> [1] Do NOT have python3 package installed;
>> [2] Do have python3 package < 3.4.0 version, so you need to upgrade!
>>
>> So, I have no idea which host distro you are using, but:
>> [1] If Debian/Ubuntu, then: apt-get install python3
>>  If Fedora, then dnf install python3
>> [2] If Debian/Ubuntu, then: apt-get update python3
>>  If Fedora, then dnf update python3
>>
>> Hope this helps,
>> Zoran
>> ___
>>
>> On Tue, May 1, 2018 at 10:43 PM, Raymond Yeung 
>> wrote:
>> > I'd just git cloned Rocko and meta-ti.  When I try to source
>> > oe-init-build-env, I got errors:
>> >
>> >
>> > -bash: python3: command not found
>> >
>> > BitBake requires Python 3.4.0 or later as 'python3'.  "python -V" gives
>> > "Python 2.7.9".  "python3" is not in $PATH.  I'd followed some detailed
>> > online description to install Python 3.6 on CentOS 7.  However, after
>> > installation, it looks like I need to invoke it with python3.6.
>> >
>> >
>> > How does this work now?  I suppose the oe-init-build-env script
>> uses/expects
>> > python3, not python3.6.
>> >
>> >
>> > Any insight?
>> >
>> >
>> > Raymond
>> >
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> yocto Info Page 
>> lists.yoctoproject.org
>> Discussion of all things about the Yocto Project. Read our Community
>> Guidelines or learn more about how to participate in other community
>> discussions. Subscribe before posting to bypass moderation.
>>
>>
>> >
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
-- 
___
yocto 

[yocto] PXE booting ISO image fails with message "Waiting for removable media..."

[Vincent Daanen]

Hi,

We want to deploy image created with Yocto (Rocko) via PXE.
The target board is a Intel-based SBC (AAEON GENE BT05).

At first, we tried with a ISO from Archlinux and the target-board successfully 
booted.

Then we create a ISO using Yocto but boot hangs with a message “Waiting for 
removable media ...”.
Googling this message points me to this post: 
http://thread.gmane.org/gmane.linux.embedded.yocto.general/20611 which relates 
exactly the same problem, explain why the issue raises, gives an indication to 
how to fix .. and that’s all ☹

So at this point, we know that the problem comes from the 
/recipes-core/initrdscripts/files/init-live.sh file.
It seems searching for an /dev/sdx should be protected by a timeout set by 
default to 30 secs but during our trials, no timeout seems to exist.

What we do not understand, is how to highlight the differences between the 
Yocto-based and the Archlinux ISO files so that we can “unblock” the boot using 
the Yocto-based ISO file.

Is the someone here how could help?

Thanks

Vincent

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

Re: [yocto] Problem with Python when running oe-init-build-env

[Burton, Ross]

I suggest you have a look through the feed that you link to and see if it
provides a package which has /usr/bin/python3 in, and if it doesn't then
just make a python3 -> python3.6 symlink (which is all you need).

Ross

On 2 May 2018 at 20:28, Raymond Yeung  wrote:

> Thanks Zoran.
>
>
> My Linux build machine uses Centos 7.  I thought I'd done the installation
> to Python 3.6.5.  If this is not Python3 > 3.4.0, then I'm confused.  The
> link I follow for installation is here:  https://janikarhunen.fi/how-
> to-install-python-3-6-1-on-centos-7.html
>
> > python3.6 -V
>
> Python 3.6.5
>
> >python -V
>
> Python 2.7.5
>
>
> Anyway, I realize what went wrong.  I'd Krogoth (a 2016 Poky) running
> before.  Now as I'm migrating to Rocko (a 2017 Poky), I try to solve a
> Python versioning issue by installing Python only (as above).  However,
> there may be other packages I need to update.  After getting latest
> Reference Manual, download and install latest environment, I no longer have
> python3 issue.  However, the Python version of why Python3.6 won't satisfy
> Python > 3.4.0 still puzzles me (though no longer blocking me).
>
>
> Raymond
>
>
> --
> *From:* Zoran Stojsavljevic 
> *Sent:* Tuesday, May 1, 2018 11:19 PM
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Problem with Python when running oe-init-build-env
>
> Hello Raymond,
>
> The problem is that you (talking about your host distro):
> [1] Do NOT have python3 package installed;
> [2] Do have python3 package < 3.4.0 version, so you need to upgrade!
>
> So, I have no idea which host distro you are using, but:
> [1] If Debian/Ubuntu, then: apt-get install python3
>  If Fedora, then dnf install python3
> [2] If Debian/Ubuntu, then: apt-get update python3
>  If Fedora, then dnf update python3
>
> Hope this helps,
> Zoran
> ___
>
> On Tue, May 1, 2018 at 10:43 PM, Raymond Yeung 
> wrote:
> > I'd just git cloned Rocko and meta-ti.  When I try to source
> > oe-init-build-env, I got errors:
> >
> >
> > -bash: python3: command not found
> >
> > BitBake requires Python 3.4.0 or later as 'python3'.  "python -V" gives
> > "Python 2.7.9".  "python3" is not in $PATH.  I'd followed some detailed
> > online description to install Python 3.6 on CentOS 7.  However, after
> > installation, it looks like I need to invoke it with python3.6.
> >
> >
> > How does this work now?  I suppose the oe-init-build-env script
> uses/expects
> > python3, not python3.6.
> >
> >
> > Any insight?
> >
> >
> > Raymond
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> yocto Info Page 
> lists.yoctoproject.org
> Discussion of all things about the Yocto Project. Read our Community
> Guidelines or learn more about how to participate in other community
> discussions. Subscribe before posting to bypass moderation.
>
>
> >
>
> --
> ___
> 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: [yocto] Problem with Python when running oe-init-build-env

[Raymond Yeung]

Thanks Zoran.


My Linux build machine uses Centos 7.  I thought I'd done the installation to 
Python 3.6.5.  If this is not Python3 > 3.4.0, then I'm confused.  The link I 
follow for installation is here:  
https://janikarhunen.fi/how-to-install-python-3-6-1-on-centos-7.html


> python3.6 -V

Python 3.6.5

>python -V

Python 2.7.5


Anyway, I realize what went wrong.  I'd Krogoth (a 2016 Poky) running before.  
Now as I'm migrating to Rocko (a 2017 Poky), I try to solve a Python versioning 
issue by installing Python only (as above).  However, there may be other 
packages I need to update.  After getting latest Reference Manual, download and 
install latest environment, I no longer have python3 issue.  However, the 
Python version of why Python3.6 won't satisfy Python > 3.4.0 still puzzles me 
(though no longer blocking me).


Raymond



From: Zoran Stojsavljevic 
Sent: Tuesday, May 1, 2018 11:19 PM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Problem with Python when running oe-init-build-env

Hello Raymond,

The problem is that you (talking about your host distro):
[1] Do NOT have python3 package installed;
[2] Do have python3 package < 3.4.0 version, so you need to upgrade!

So, I have no idea which host distro you are using, but:
[1] If Debian/Ubuntu, then: apt-get install python3
 If Fedora, then dnf install python3
[2] If Debian/Ubuntu, then: apt-get update python3
 If Fedora, then dnf update python3

Hope this helps,
Zoran
___

On Tue, May 1, 2018 at 10:43 PM, Raymond Yeung  wrote:
> I'd just git cloned Rocko and meta-ti.  When I try to source
> oe-init-build-env, I got errors:
>
>
> -bash: python3: command not found
>
> BitBake requires Python 3.4.0 or later as 'python3'.  "python -V" gives
> "Python 2.7.9".  "python3" is not in $PATH.  I'd followed some detailed
> online description to install Python 3.6 on CentOS 7.  However, after
> installation, it looks like I need to invoke it with python3.6.
>
>
> How does this work now?  I suppose the oe-init-build-env script uses/expects
> python3, not python3.6.
>
>
> Any insight?
>
>
> Raymond
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions. 
Subscribe before posting to bypass moderation.



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

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Alexander Kanavin]

On 05/03/2018 04:37 PM, Peter Kjellerstedt wrote:

# Have dnf always print in verbose mode and print the output to
bb.debug instead of bb.note.


I think this is the best solution actually.


I disagree with changing bb.note to bb.debug for this. It is very good
to be able to look in log.do_rootfs to see what dnf has done (we have
ROOTFS_RPM_DEBUG set by default). Changing the output to debug level
would mean having to run bitbake with -D, which is anything but
desirable.


If I'm reading the bitbake --help right, bb.debug (and bb.note) are 
always written to the log; setting -D level or -v only affects what is 
printed on stdout.



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

[yocto] TI TLK10031 Driver Needed

[Raymond Yeung]

What is the best way to search for existing driver support (in particular, 
driver for TLK10031) in YP?  I search my own Poky source and its build tree, 
but find nothing.  I saw on google returned result mentioning of one instance 
for a similar chip (TLK10232), but don't know which branch/repo it's from.


Thanks,

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

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Peter Kjellerstedt]

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Alexander Kanavin
> Sent: den 3 maj 2018 15:04
> To: Paulo Neves ; Yocto list discussion
> 
> Subject: Re: [yocto] ROOTFS_RPM_DEBUG undocumented
> 
> On 05/03/2018 01:42 PM, Paulo Neves wrote:
> > # Add ROOTFS_RPM_DEBUG to the documentation;
> 
> I'd rather get rid of it, the less variables the better :)
> 
> > # Detect if we are running with debug output and enable the debugging
> > output. This is the most elegant solution but I do not know how to
> > detect if debug log level is turned on;
> 
> I don't think you are meant to detect that; bitbake's debug level is
> not
> meant to affect what is being printed, but merely whether it's printed
> or discarded.
> 
> > # Have dnf always print in verbose mode and print the output to
> > bb.debug instead of bb.note.
> 
> I think this is the best solution actually.

I disagree with changing bb.note to bb.debug for this. It is very good 
to be able to look in log.do_rootfs to see what dnf has done (we have 
ROOTFS_RPM_DEBUG set by default). Changing the output to debug level 
would mean having to run bitbake with -D, which is anything but 
desirable.

> > I am happy to provide a patch upon decision or suggestions.
> 
> Thank you :) Do measure the performance before and after as we don't
> want to introduce a significant slowdown here.
> 
> Alex

//Peter

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

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Alexander Kanavin]

On 05/03/2018 01:42 PM, Paulo Neves wrote:

# Add ROOTFS_RPM_DEBUG to the documentation;


I'd rather get rid of it, the less variables the better :)


# Detect if we are running with debug output and enable the debugging
output. This is the most elegant solution but I do not know how to
detect if debug log level is turned on;


I don't think you are meant to detect that; bitbake's debug level is not 
meant to affect what is being printed, but merely whether it's printed 
or discarded.



# Have dnf always print in verbose mode and print the output to
bb.debug instead of bb.note.


I think this is the best solution actually.


I am happy to provide a patch upon decision or suggestions.


Thank you :) Do measure the performance before and after as we don't 
want to introduce a significant slowdown here.



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

[yocto] ROOTFS_RPM_DEBUG undocumented

[Paulo Neves]

Hello all,

I recently had the problem where the do_rootfs task seemed to hang.
The output where it hang looked like [1] and stayed that way for the
better part of an hour.

When I ran bitbake with -vD arguments not more relevant output was
given [2], also hanging for a lot of time.

As noted in another mailing list post about rootfs hanging[3], the
culprit was the enormous amount of kernel modules which were being
built. I only discovered this because I was able to strace and see
that actually bitbake was not hanging but actually running dnf
install.

When I searched for the code responsible for the invocation of dnf I
notice there is an undocumented variable called ROOTFS_RPM_DEBUG that
enables verbosity of the dnf and prints it out. This would have been
very helpful output for my 'bitbake -vD' invocation, and truly
debugging information would have helped.

What I ask is a decision on which option would better suite this issue:

# Add ROOTFS_RPM_DEBUG to the documentation;
# Detect if we are running with debug output and enable the debugging
output. This is the most elegant solution but I do not know how to
detect if debug log level is turned on;
# Have dnf always print in verbose mode and print the output to
bb.debug instead of bb.note.

I am happy to provide a patch upon decision or suggestions.

Paulo Neves

[1] NOTE: recipe drotag-cloud-image-debug-1.0-r0: task do_rootfs: Started

[2] DEBUG: drotag-cloud-image-debug-1.0-r0 do_rootfs: Executing python
function do_rootfs

[3] https://lists.yoctoproject.org/pipermail/yocto/2017-May/036293.html
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem with Python when running oe-init-build-env

[Burton, Ross]

On 1 May 2018 at 21:43, Raymond Yeung  wrote:

> I'd just git cloned Rocko and meta-ti.  When I try to source
> oe-init-build-env, I got errors:
>
>
> -bash: python3: command not found
>
> BitBake requires Python 3.4.0 or later as 'python3'.  "python -V" gives
> "Python 2.7.9".  "python3" is not in $PATH.  I'd followed some detailed
> online description to install Python 3.6 on CentOS 7.  However, after
> installation, it looks like I need to invoke it with python3.6.
>
>
> How does this work now?  I suppose the oe-init-build-env script
> uses/expects python3, not python3.6.
>

The python3 installation should have created a python3 symlink to
python3.6.  If this didn't happen, create it yourself.

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

Re: [yocto] Can't compile out of tree kernel module when CONFIG_SYSTEM_TRUSTED_KEYRING is set in the kernel configuration

[Martin Townsend]

Hi Bruce,

On Thu, May 3, 2018 at 3:27 AM, Bruce Ashfield  wrote:
>
>
> On Wed, May 2, 2018 at 5:05 PM, Martin Townsend 
> wrote:
>>
>> Hi,
>>
>> I get the following error when compiling a kernel module using the
>> latest version of Rocko (The kernel is not linux-yocto but NXP's
>> freescale linux-imx, maybe this could be a factor) :
>>
>> ERROR: kernel-module-driver-0.1-r0 do_make_scripts: Function failed:
>> do_make_scripts (log file is located at
>>
>> /ws/yocto-rocko/build/tmp/work/mach_1717-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703)
>> ERROR: Logfile of failure stored in:
>>
>> /ws/yocto-rocko/build/tmp/work/mach_1717-cwr-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703
>> Log data follows:
>> | DEBUG: Executing shell function do_make_scripts
>> | make: Entering directory
>> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source'
>> | make[1]: Entering directory
>>
>> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-build-artifacts'
>> |   HOSTCC  scripts/extract-cert
>> |
>> /ws/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/scripts/extract-cert.c:21:25:
>> fatal error: openssl/bio.h: No such file or directory
>> | compilation terminated.
>> | scripts/Makefile.host:107: recipe for target 'scripts/extract-cert'
>> failed
>> | make[2]: *** [scripts/extract-cert] Error 1
>> |
>> /ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/Makefile:560:
>> recipe for target 'scripts' failed
>> |
>>
>> I checked the makefile and extract-cert is only compiled if
>> CONFIG_SYSTEM_TRUSTED_KEYRING is set which we have.
>>
>>  I could install libssl-dev but it doesn't feel right installing this
>> and it's not in the system requirements plus the file openssl/bio.h is
>> in the recipe-sysroot-native directory of the kernel module WORK_DIR.
>
>
> I've run into this plenty of times with newer kernels (4.14+), which is why
> all the linux-yocto recipes have:
>
> DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
> DEPENDS += "openssl-native util-linux-native"
>
> As does my re-worked kernel-devsrc.
>
> So yah, you can just add the dependency to fix the problem.
>
> Bruce
>

Thanks for the swift reply and I tried the suggestions but I'm afraid
the end result is still the same.

The actual kernel builds fine so I'll take a look at this to see if
there are any clues.  I'm guessing do_make_scripts needs tweaking for
an out of tree kernel module recipe to use the recipe_sysroot_native
directory somehow.

Cheers, Martin

>>
>>
>>
>> Any help would be greatly appreciated,
>> Marin.
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto