Re: [yocto] Determining the correct layers for a Beaglebone build.

[Kenny Koller]

Thanks Khem,

At the moment I simply want to build a headless minimal install for a
Beaglebone Black. Once I achieve this I plan to customize the distro for my
device. Here is what I am finding confusing:

This link 
looks to be the place to start. It is the "download" page for the
Beaglebone. It lists, as a build system, Poky 2.3. It lists as a download
"git://git.yoctoproject.org/meta-yocto -b pyro" which in turn contains, as
subdirectories, meta-poky, meta-yocto, and meta-yocto-bsp. But these three
directories already exist when I check out poky. If I ignore this for the
moment the layer index suggests that a dependency is openembedded-core. Has
this been merged in to Poky or must I clone this as well?

meta-ti isn't mentioned. If I search for meta-ti I find this BSP
 which makes me
think that perhaps this work has been merged in to meta-yocto-bsp as no
recent version of Poky is supported.

Regarding the tags: If I check out the pyro branch of poky am I getting
something that is stable and has been tested? I thought perhaps the tags
with `pyro-17.0.0` would point to stable tested commit.

The reason I'm trying to sort all of this out is that when I ran a `bitbake
core-image-minimal` with Poky Pyro it failed. It was missing u-image. All I
did was clone Poky/Pyro and set the MACHINE to beaglebone. It got pretty
far though. It seems to have built the kernel and the device tree binaries.
No signs of the root filesystem or the bootloader (u-image):

core-image-base-beaglebone-20170621162619.testdata.json
core-image-base-beaglebone.testdata.json
core-image-minimal-beaglebone-20170624014756.testdata.json
core-image-minimal-beaglebone.testdata.json
modules--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170621162619.tgz
modules-beaglebone.tgz
zImage
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-am335x-bone-20170621162619.dtb
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-am335x-boneblack-20170621162619.dtb
zImage--4.10.9+git0+ad2e885015_fe0fb8da3d-r0-beaglebone-20170621162619.bin
zImage-am335x-boneblack.dtb
zImage-am335x-bone.dtb
zImage-beaglebone.bin


On Mon, Jun 26, 2017 at 5:18 PM Khem Raj  wrote:

> On Mon, Jun 26, 2017 at 4:35 PM, Kenny Koller
>  wrote:
> > I'm trying to figure out which set of meta layers I need to build a
> distro
> > and images for a Beaglebone Black.
> >
> > I cloned poky and within I see meta-yocto and meta-yocto-bsp. The latter
> has
> > recipes for the Beaglebone.
> >
> > I also found this page which suggests cloning meta-yocto:
> >
> > https://www.yoctoproject.org/downloads/bsps/pyro23/beaglebone
> >
> > Then there is meta-ti. Where does this fit in?
>
> yocto project used beaglebone black as one of its reference boards
> so you can find a default reference yocto BSP for it.
>
> Secondly, meta-ti is TI BSP layer which also supports beaglebone black
> since the board is from TI
>
>
> >
> > Also when I clone say poky should I checkout the branch or a specific
> tag?
> >
>
> you can use git clone git://git.yoctoproject.org/poky -b pyro
> for getting latest stable release.
>
> > It's not clear to me the best way start with a piece of hardware then
> > determine the correct layers.
>
> I would suggest to do a bit more investigation as to what you need.
> meanwhile you can build yocto reference BSP and play with it. There
> are many packages that meta-ti would have that you might need depending
> upon what you plan to do.
>
> >
> > Thanks.
> >
> >
> > --
> > ___
> > 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] [meta-chip] Jenkins, reviews and mailing list

[Petter Mabacker]

On Mon, 2017-06-26 at 17:12 +0100, Andrei Gherzan wrote:
> On Mon, Jun 26, 2017 at 2:29 PM, Trevor Woerner 
> wrote:
> > On Mon, Jun 26, 2017 at 9:21 AM, Andrei Gherzan 
> > wrote:
> > 
> > > We've been testing a setup with meta-raspberrypi which seems to
> > work fine:
> > 
> > > PR to github integrated with a jenkins server and use mailing
> > list for
> > 
> > > discussions.
> > 
> > >
> > 
> > > I propose to copy the same setup to meta-chip too.
> > 
> > 
> > 
> > That's all fine. As the maintainer (thank you!) you're welcome to
> > use
> > 
> > whatever workflow with which you're the happiest... as long as you
> > 
> > update the "Contributing" section of the README :-)
> > 
> 
> Sure. That makes sense.

Hi Andrei,
I fully agree with Trevor, just update the README and lets rock! :) But
like you say I also believe it's good if people can take the time to
also send the patches to mailing list, so we don't risk losing those
valuable discussions that often is initated through the mailing list
(since more people will track the changes that way). My opinion is that
this have work good for meta-raspberrypi, so cannot see any reasons why
it should work great for meta-chip as well.
Let us know when jenkins is up-and-running!
Cheers Petter
> --Andrei Gherzan
> -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Determining the correct layers for a Beaglebone build.

[Khem Raj]

On Mon, Jun 26, 2017 at 4:35 PM, Kenny Koller
 wrote:
> I'm trying to figure out which set of meta layers I need to build a distro
> and images for a Beaglebone Black.
>
> I cloned poky and within I see meta-yocto and meta-yocto-bsp. The latter has
> recipes for the Beaglebone.
>
> I also found this page which suggests cloning meta-yocto:
>
> https://www.yoctoproject.org/downloads/bsps/pyro23/beaglebone
>
> Then there is meta-ti. Where does this fit in?

yocto project used beaglebone black as one of its reference boards
so you can find a default reference yocto BSP for it.

Secondly, meta-ti is TI BSP layer which also supports beaglebone black
since the board is from TI


>
> Also when I clone say poky should I checkout the branch or a specific tag?
>

you can use git clone git://git.yoctoproject.org/poky -b pyro
for getting latest stable release.

> It's not clear to me the best way start with a piece of hardware then
> determine the correct layers.

I would suggest to do a bit more investigation as to what you need.
meanwhile you can build yocto reference BSP and play with it. There
are many packages that meta-ti would have that you might need depending
upon what you plan to do.

>
> Thanks.
>
>
> --
> ___
> 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] [layerindex-web][PATCH] layerindex-web : adding asynchronous task execution

[Diana Thayer]

Hello!

This is a work-in-progress solution to issue 11197 within layerindex-web: 
adding asynchronous task execution.
I used RabbitMQ and Celery. I'm still working with Paul Eggleton on adding 
install instructions for RabbitMQ to
the site's Dockerfile.

Previously, when a user submitted a layer, Django would synchronously send 
emails to users able to publish layers,
such that if an email bounced or otherwise failed, the user submitting the 
layer would see an error.
This patch sends those emails as asynchronous tasks, so any sending errors 
don't reach the user submitting a layer.

Thanks for reviewing this! Here's a brief changelog:

- updated readme to include RabbitMQ as a dependency
- updated settings.py to include RABBIT_BROKER and RABBIT_BACKEND
- added celery to requirements.txt
- defined celery tasks in layerindex/tasks.py
- separated layerindex/update#main into two functions: main (which parses 
sys.argv) and do_update (which accepts options as keyword arguments)
- updated layerindex/views.py to use the send_email task to asynchronously 
message anyone able to publish layers when a new layer is submitted
---
 README   |   5 +-
 layerindex/tasks.py  |  31 +++
 layerindex/update.py | 143 +++
 layerindex/views.py  |   7 ++-
 requirements.txt |   1 +
 settings.py  |   4 ++
 6 files changed, 120 insertions(+), 71 deletions(-)
 create mode 100644 layerindex/tasks.py

diff --git a/README b/README
index 62f739d..cfcc37f 100644
--- a/README
+++ b/README
@@ -14,6 +14,7 @@ In order to make use of this application you will need:
 * Python 3.4+
 * Django 1.8.x - tested with 1.8.17; newer versions may work, but
   the application has not been tested with 1.9 or newer.
+* RabbitMQ 3.6.x - tested with 3.6.10.
 * For production usage, a web server set up to host Django applications
   (not needed for local-only testing)
 * A database supported by Django (SQLite, MySQL, etc.). Django takes
@@ -41,7 +42,9 @@ Setup instructions:
 1. Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and
other settings specific to your installation. Ensure you set
LAYER_FETCH_DIR to an absolute path to a location with sufficient
-   space for fetching layer repositories.
+   space for fetching layer repositories. Modify RABBIT_BROKER
+   and RABBIT_BACKEND to reflect the settings used by your RabbitMQ
+   server.
 
 2. Run the following commands within the layerindex-web directory to
initialise the database:
diff --git a/layerindex/tasks.py b/layerindex/tasks.py
new file mode 100644
index 000..9bb4701
--- /dev/null
+++ b/layerindex/tasks.py
@@ -0,0 +1,31 @@
+from celery import Celery
+from django.core.mail import EmailMessage
+import os
+import time
+
+try:
+  from update import do_update
+except ImportError:
+  from .update import do_update
+
+try:
+  import settings
+except ImportError:
+  # not in a full django env, so settings is inaccessible.
+  # setup django to access settings.
+  from utils import setup_django
+  setup_django()
+  import settings
+
+tasks = Celery('layerindex',
+broker=settings.RABBIT_BROKER,
+backend=settings.RABBIT_BACKEND)
+
+@tasks.task
+def update(**options):
+  return do_update(**options)
+
+@tasks.task
+def send_email(subject, text_content, from_email=settings.DEFAULT_FROM_EMAIL, 
to_emails=[]):
+  msg = EmailMessage(subject, text_content, from_email, to_emails)
+  msg.send()
diff --git a/layerindex/update.py b/layerindex/update.py
index d5c56cd..f1c5039 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -17,7 +17,11 @@ import subprocess
 import signal
 from datetime import datetime, timedelta
 from distutils.version import LooseVersion
-import utils
+
+try:
+import utils
+except ImportError:
+from . import utils
 
 import warnings
 warnings.filterwarnings("ignore", category=DeprecationWarning)
@@ -71,73 +75,32 @@ def prepare_update_layer_command(options, branch, layer, 
updatedeps=False):
 cmd = '%s update_layer.py -l %s -b %s' % (cmdprefix, layer.name, 
branch.name)
 if updatedeps:
 cmd += ' --update-dependencies'
-if options.reload:
+if options.get('reload'):
 cmd += ' --reload'
-if options.fullreload:
+if options.get('fullreload'):
 cmd += ' --fullreload'
-if options.nocheckout:
+if options.get('nocheckout'):
 cmd += ' --nocheckout'
-if options.dryrun:
+if options.get('dryrun'):
 cmd += ' -n'
-if options.loglevel == logging.DEBUG:
+if options.get('loglevel') == logging.DEBUG:
 cmd += ' -d'
-elif options.loglevel == logging.ERROR:
+elif options.get('loglevel') == logging.ERROR:
 cmd += ' -q'
 return cmd
 
-
-def main():
-if LooseVersion(git.__version__) < '0.3.1':
-logger.error("Version of GitPython is too old, please install 
GitPython (python-git) 0.3.1 or later in order to use this script")
-sys.exit(1)
-
-
-parser = 

[yocto] Determining the correct layers for a Beaglebone build.

[Kenny Koller]

I'm trying to figure out which set of meta layers I need to build a distro
and images for a Beaglebone Black.

I cloned poky and within I see meta-yocto and meta-yocto-bsp. The latter
has recipes for the Beaglebone.

I also found this page which suggests cloning meta-yocto:

https://www.yoctoproject.org/downloads/bsps/pyro23/beaglebone

Then there is meta-ti. Where does this fit in?

Also when I clone say poky should I checkout the branch or a specific tag?

It's not clear to me the best way start with a piece of hardware then
determine the correct layers.

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

Re: [yocto] How can I add a library to my SDK

[Khem Raj]

On Mon, Jun 26, 2017 at 12:21 PM, Jimi Damon  wrote:
> TOOLCHAIN_HOST_TASK_append = " zeromq"

you need to add the package meant for sdk host.

TOOLCHAIN_HOST_TASK_append = " nativesdk-zeromq"

also make sure that zeromq recipe has BBCLASSEXTEND   for nativesdk
if not you might have to fix that first.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How can I add a library to my SDK

[Burton, Ross]

On 26 June 2017 at 20:21, Jimi Damon  wrote:

> *TOOLCHAIN_HOST_TASK_append = " zeromq"*
>
> For a target recipe you want TOOLCHAIN_TARGET_TASK_append.

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

[yocto] How can I add a library to my SDK

[Jimi Damon]

Hi,


I've added zeromq to a build by adding the meta-iot-cloud layer. This 
adds zeromq to the target rootfs, but I can't get this added to the host 
rootfs when I create an sdk ( using bitbake -c populate_sdk 
core-image-minimal  ).



I've read about adding something like

*TOOLCHAIN_HOST_TASK_append = " zeromq"*

to my conf/local.conf, however, I only see error messages saying


NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: core-image-minimal-dev-1.0-r0 do_populate_sdk: zeromq not found 
in the feeds (x86_64-nativesdk noarch any all) in 
/media/build/morty/build/tmp/deploy/rpm.
ERROR: core-image-minimal-dev-1.0-r0 do_populate_sdk: This is often 
caused by an empty package declared in a recipe's PACKAGES variable. 
(Empty packages are not constructed unless ALLOW_EMPTY_ = '1' is used.)
ERROR: core-image-minimal-dev-1.0-r0 do_populate_sdk: Function failed: 
do_populate_sdk
ERROR: Logfile of failure stored in: 
/media/build/morty/build/tmp/work/nitrogen6x-fslc-linux-gnueabi/core-image-minimal-dev/1.0-r0/temp/log.do_populate_sdk.20519
ERROR: Task 
(/media/build/morty/sources/poky/meta/recipes-core/images/core-image-minimal-dev.bb:do_populate_sdk) 
failed with exit code '1'



What is the approved way to add a library that was compiled for the 
target to the host  ?






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

Re: [yocto] openssl/Certificate problems when running simple MS IoT Hub sample C application

[Jakob Hasse]

Hello Khem,

thanks for the answer. I'm pretty sure now that it is an ssl problem 
(see below).


On 26.06.2017 16:28, Khem Raj wrote:

On Sun, Jun 25, 2017 at 11:35 PM, Jakob Hasse
 wrote:

Hello,

I'm trying to  run the Mircosoft Azure IoT hub mqtt example
(iothub_client_sample_amqp or simliar) of the C SDK on yocto
(https://github.com/Azure/azure-iot-sdk-c).
On my Ubuntu host machine, everything compiles and works fine, the
application connects to the azure server and sends messages.
In Yocto, I get errors after compiling the whole SDK with all examples, but
the mqtt example is already there, so I assume it's correct. Furthermore, I
could compile it using Intel's meta-iot-cloud layer and only taking the
example application itself into my own layer.

I would suggest to fix all compile errors. If you need support please share
your compile errors here, there might be interesting for people here.
As I said, the application also compiled with the meta-iot-cloud layer 
without errors. Anyway, here are the errors when compiling with the SDK:


[ 67%] Building C object 
iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/iothub_client_sample_mqtt_dm.c.o
cc1: error: include location "/usr/include/azureiot" is unsafe for 
cross-compilation [-Werror=poison-system-directories]

[ 68%] Building C object uamqp/CMakeFiles/uamqp.dir/src/session.c.o
[ 69%] Building C object 
iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/pi_device/pi.c.o
cc1: error: include location "/usr/include/azureiot" is unsafe for 
cross-compilation [-Werror=poison-system-directories]

cc1: all warnings being treated as errors
iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/build.make:86: 
recipe for target 
'iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/pi_device/pi.c.o' 
failed
make[2]: *** 
[iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/pi_device/pi.c.o] 
Error 1

make[2]: *** Waiting for unfinished jobs
Scanning dependencies of target simplesample_http
[ 70%] Building C object 
serializer/samples/simplesample_http/CMakeFiles/simplesample_http.dir/simplesample_http.c.o

cc1: all warnings being treated as errors
iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/build.make:62: 
recipe for target 
'iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/iothub_client_sample_mqtt_dm.c.o' 
failed
make[2]: *** 
[iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/iothub_client_sample_mqtt_dm.c.o] 
Error 1
CMakeFiles/Makefile2:2288: recipe for target 
'iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/all' 
failed
make[1]: *** 
[iothub_client/samples/iothub_client_sample_mqtt_dm/CMakeFiles/iothub_client_sample_mqtt_dm.dir/all] 
Error 2

make[1]: *** Waiting for unfinished jobs
[ 70%] Building C object 
serializer/samples/simplesample_http/CMakeFiles/simplesample_http.dir/linux/main.c.o
[ 70%] Building C object 
uamqp/CMakeFiles/uamqp.dir/src/socket_listener_berkeley.c.o

[ 71%] Linking C static library libuamqp.a
[ 71%] Built target uamqp
[ 72%] Linking C executable simplesample_http
[ 72%] Built target simplesample_http
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2



Now the actual problem:
When I run the application on the Yocto system, it establishes a tcp
connection to the azure server, but then "stops working", until the azure
server sends the tcp fin ack, which the the application acknowlegdes. On TCP
dump I can see that packets were dropped by the kernel.
The tcp problem seems to occur while the azure server is transmitting the
certificate, if I interpret the tcpdump output correctly. But might be just
coincidence. I checked the openssl libs requested by the application and
they are the same on the Ubuntu host and on the Yocto embedded system.

The network is also the same as on the host machine.

I would be very happy for ideas about what went wrong here.

Whats the kernel version on working and non working systems. ?

Ubuntu host: 4.4.0-81-generic
Yocto: 4.1.38-dey+gce24590

The dropped packages in tcpdump are a tcpdump problem, as I found out... 
so nothing to do with the actual problem.


The connection is closed very early by the server, as I saw some 
certificate-related strings, it seems to finish right after the 
application received the openssl certs.
I can reproduce the behavior on the host machine by renaming the 
/etc/ssl/certs/ folder, so I'm pretty sure that it's an openssl problem 
(or finding the certs).


When I try to connect with
openssl s_client -showcerts -connect 13.95.15.251:8883
I get the error: Verify return code: 20 (unable to get local issuer 

[yocto] : cmake and create_symlink using cmake 3.5 and yocto 2.2.2

[Ehrlich Andrei]

Hello everybody,

Please excuse the newbie question I want to ask, but I started with yocto and 
cmake 3 month ago and now I have a couple of recipes based on cmake. One of 
that cmake files installs links using following code:

install(
CODE "execute_process( \
COMMAND ${CMAKE_COMMAND} -E create_symlink \
__tool \
${CMAKE_INSTALL_PREFIX}/bin/tool_${DST_NAME} \
)"

When the code is executed in yocto  the do_install task fails with following 
error:
failed to create symbolic link '/usr/bin/tool_intf': Permission denied

The cmake code attempts to install the links to the root_fs of my development 
host. The code I write recipes for is currently under development and cmake 
files are provided by developers. Therefore I would like to use developers 
cmake files and avoid permanently updating do_install task in my recipe. 
Unfortunately I can't find any possibility to force the cmake recipe to install 
the links to target root_fs. I would be glad to know if somebody has already 
faced a similar problem and probably has a solution for it.

Best regards
Andrei Ehrlich
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] question regarding share state cache and task dependencies.

[Khem Raj]

On Mon, Jun 26, 2017 at 9:16 AM, Koehler, Yannick
 wrote:
> I was wondering, reading about the shared state cache system, why are the 
> task / recipe dependencies being honored when executing a setscene task?  
> Since there is a "sanity" check that no two package write to the same output 
> files, then could we just run the setscene task without honoring the 
> dependencies and get all the files in place at maximum speed ?  Right now, 
> the system seems to install each package dependencies in the same order it 
> was built, but since this is pre-built, I failed to see why the order mater 
> anymore, given the sanity check above.  The dependency should be used to 
> determine what setscene to execute, but then they should just pump out as 
> fast as possible in any given order.

there are quite a few resources available for you.

http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#setscene

http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#shared-state-cache

Then there are couple of books also talking about the concept.

>
> --
> Yannick Koehler
> --
> ___
> 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] question regarding share state cache and task dependencies.

[Koehler, Yannick]

I was wondering, reading about the shared state cache system, why are the task 
/ recipe dependencies being honored when executing a setscene task?  Since 
there is a "sanity" check that no two package write to the same output files, 
then could we just run the setscene task without honoring the dependencies and 
get all the files in place at maximum speed ?  Right now, the system seems to 
install each package dependencies in the same order it was built, but since 
this is pre-built, I failed to see why the order mater anymore, given the 
sanity check above.  The dependency should be used to determine what setscene 
to execute, but then they should just pump out as fast as possible in any given 
order.

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

Re: [yocto] [meta-chip] Jenkins, reviews and mailing list

[Andrei Gherzan]

On Mon, Jun 26, 2017 at 2:29 PM, Trevor Woerner  wrote:

> On Mon, Jun 26, 2017 at 9:21 AM, Andrei Gherzan  wrote:
> > We've been testing a setup with meta-raspberrypi which seems to work
> fine:
> > PR to github integrated with a jenkins server and use mailing list for
> > discussions.
> >
> > I propose to copy the same setup to meta-chip too.
>
> That's all fine. As the maintainer (thank you!) you're welcome to use
> whatever workflow with which you're the happiest... as long as you
> update the "Contributing" section of the README :-)
>

Sure. That makes sense.

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

[yocto] Yocto Project Status WW26’17

[Jolley, Stephen K]

Current Dev Position: Preparing for YP 2.4 M2

Next Deadline: YP 2.4 M2 Cut off is July 17, 2017



SWAT team rotation: Jussi -> Stephano on June 23, 2017.

SWAT team rotation: Stephano -> Maxin on June 30, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team



Key Status/Updates:

·YP 2.4 M1 rc1 is likely to be released as M1. Some issues were found 
but these were comparatively minor and will be addressed in master during M2. 
The QA Report: 
https://wiki.yoctoproject.org/wiki/WW25_-_2017-06-22_-_Full_Test_Cycle_2.4_M1_rc1
 Release Criteria: 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status#Milestone_1_-_Target_June_23.2C_2017

·Various changes merged into master including cleanup of obsoleted 
uclibc related changes, removal of gcc 5.x and ipk/deb package parallelisation 
and various recipe upgrades.

·We have been doing some cleanup of older bugs in the bugzilla, closing 
things which are unlikely to happen, are obsolete or have already been 
completed. This is having a positive effect on many of the bug tracking metrics 
but more work remains to clean things up.



Planned upcoming dot releases:

YP 2.1.3 Cut off May 22, 2017 - Will respin an rc2 and run through QA after YP 
2.4 M1 is done.

YP 2.1.3 Release by June 3, 2017

YP 2.3.1 Cut off May 30, 2017 - Running late, but rc1 should go into QA after 
YP 2.4 M1, YP 2.1.3, and YP 2.2.2 are done.

YP 2.3.1 Release by June 9, 2017

YP 2.2.2 Cut off June 5, 2017 - Will respin an rc2 and run through QA after YP 
2.4 M1 and YP 2.1.3 are done.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Aug 7, 2017

YP 2.3.2 Release by Aug. 18, 2017



Key YP 2.4 Dates are:

YP 2.4 M2 Cut off is July 17, 2017

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017



Tracking Metrics:

WDD 2508 (last week 2602)

(https://wiki.yoctoproject.org/charts/combo.html)



Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features



[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

Re: [yocto] network problems when running simple MS IoT Hub sample C application

[Khem Raj]

On Sun, Jun 25, 2017 at 11:35 PM, Jakob Hasse
 wrote:
> Hello,
>
> I'm trying to  run the Mircosoft Azure IoT hub mqtt example
> (iothub_client_sample_amqp or simliar) of the C SDK on yocto
> (https://github.com/Azure/azure-iot-sdk-c).
> On my Ubuntu host machine, everything compiles and works fine, the
> application connects to the azure server and sends messages.
> In Yocto, I get errors after compiling the whole SDK with all examples, but
> the mqtt example is already there, so I assume it's correct. Furthermore, I
> could compile it using Intel's meta-iot-cloud layer and only taking the
> example application itself into my own layer.

I would suggest to fix all compile errors. If you need support please share
your compile errors here, there might be interesting for people here.

>
> Now the actual problem:
> When I run the application on the Yocto system, it establishes a tcp
> connection to the azure server, but then "stops working", until the azure
> server sends the tcp fin ack, which the the application acknowlegdes. On TCP
> dump I can see that packets were dropped by the kernel.
> The tcp problem seems to occur while the azure server is transmitting the
> certificate, if I interpret the tcpdump output correctly. But might be just
> coincidence. I checked the openssl libs requested by the application and
> they are the same on the Ubuntu host and on the Yocto embedded system.
>
> The network is also the same as on the host machine.
>
> I would be very happy for ideas about what went wrong here.

Whats the kernel version on working and non working systems. ?

>
> Best regards,
> Jakob
>
> --
> Jakob Hasse
> Software Developement
>
> E: jakob.ha...@smart-home-technology.ch
> T: +41 44 552 02 66
>
> Smart Home Technology GmbH
> www.smart-home-technology.ch
>
> --
> ___
> 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] Errors while building imx6qsabresd using fsl-community-bsp repo

[Chandrasekhar S]

Check for proper internet connection and speed. 

 

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Charmi Suchak
Sent: Tuesday, June 20, 2017 4:21 PM
To: yocto@yoctoproject.org
Subject: [yocto] Errors while building imx6qsabresd using fsl-community-bsp repo

 

Hi,

I am new to yocto training and I am trying to build a linux for imx series 
target from NXP. I got the bsp layer along with poky using the following:

repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b daisy
repo sync

Now when I try to build core-image-minimal I get the following errors:

Parsing recipes: 100% 
||
 Time: 00:01:23
Parsing of 1398 .bb files complete (0 cached, 1398 parsed). 1826 targets, 101 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.22.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "imx6qsabresd"
DISTRO= "poky"
DISTRO_VERSION= "1.6.3"
TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa9"
TARGET_FPU= "vfp-neon"
meta  
meta-yocto= "(nobranch):39ec0738d4bdc566eca2724dc35c557955042242"
meta-oe   = "(nobranch):d3d14d3fcca7fcde362cf0b31411dc4eea6d20aa"
meta-fsl-arm  = "(nobranch):0c4de80867c3ab4e9682dd7802d3fd907d1e1a23"
meta-fsl-arm-extra = "(nobranch):c95f3f8b5b347f1b3e77d2d11063207ddb7dc5ec"
meta-fsl-demos= "(nobranch):f141c7d1158b8addbd6f1ed047a1b47c2ed85f8f"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Checksum failure encountered with download of 
http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-20120814.tar.bz2
 - will attempt other sources if available
WARNING: Renaming 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/gnu-config-20120814.tar.bz2
 to 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/gnu-config-20120814.tar.bz2_bad-checksum_550a1f90200546416f8d12b878edfb50
WARNING: Checksum failure encountered with download of 
http://download.savannah.gnu.org/releases/quilt/quilt-0.61.tar.gz - will 
attempt other sources if available
WARNING: Renaming 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/quilt-0.61.tar.gz
 to 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/quilt-0.61.tar.gz_bad-checksum_edff525cc95ce8932e66c2e2bfeabdbf
WARNING: Checksum failure encountered with download of 
ftp://ftp.gnu.org/gnu/automake/automake-1.14.tar.gz - will attempt other 
sources if available
WARNING: Renaming 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/automake-1.14.tar.gz
 to 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/automake-1.14.tar.gz_bad-checksum_1ada9887dbde94d6fbda52bd91543738
WARNING: Checksum failure encountered with download of 
ftp://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz - will attempt other sources 
if available
WARNING: Renaming 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/libtool-2.4.2.tar.gz
 to 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/libtool-2.4.2.tar.gz_bad-checksum_9546fcbc4c15aada3464891bfe3f484b
WARNING: Failed to fetch URL 
http://download.gna.org/cryptodev-linux/cryptodev-linux-1.6.tar.gz, attempting 
MIRRORS if available
WARNING: Failed to fetch URL 
http://gnome-build-stage-1.googlecode.com/files/uuid-1.6.2.tar.gz, attempting 
MIRRORS if available
WARNING: Checksum failure encountered with download of 
http://download.oracle.com/berkeley-db/db-5.3.21.tar.gz - will attempt other 
sources if available
WARNING: Renaming 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/db-5.3.21.tar.gz
 to 
/home/charmi/charmi/charmi/Training/yocto/imx6/fsl-community-bsp/downloads/db-5.3.21.tar.gz_bad-checksum_49429d4ac8880348db65209c82fd2549
WARNING: Failed to fetch URL http://zlib.net/pigz/pigz-2.3.1.tar.gz, attempting 
MIRRORS if available
WARNING: Failed to fetch URL 
http://downloads.sourceforge.net/libusb/libusb-1.0.9.tar.bz2, attempting 
MIRRORS if available
WARNING: Failed to fetch URL 
git://git.freescale.com/imx/linux-2.6-imx.git;branch=imx_3.10.17_1.0.1_ga 
 , 
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: Not a git repository (or any of the parent directories): .git

ERROR: Function failed: Fetcher failure for URL: 
'git://git.freescale.com/imx/linux-2.6-imx.git;branch=imx_3.10.17_1.0.1_ga 
 '. 
Unable to fetch URL from any source.
ERROR: Logfile of failure stored 

[yocto] [meta-selinux] [PATCH] audit 2.7.1 -> 2.7.6

[Huang Qiyu]

From: susanbian 

Upgrade audit from 2.7.1 to 2.7.6

Signed-off-by: susanbian 
---
 recipes-security/audit/{audit_2.7.1.bb => audit_2.7.6.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename recipes-security/audit/{audit_2.7.1.bb => audit_2.7.6.bb} (96%)

diff --git a/recipes-security/audit/audit_2.7.1.bb 
b/recipes-security/audit/audit_2.7.6.bb
similarity index 96%
rename from recipes-security/audit/audit_2.7.1.bb
rename to recipes-security/audit/audit_2.7.6.bb
index 975e6e9..75d4d23 100644
--- a/recipes-security/audit/audit_2.7.1.bb
+++ b/recipes-security/audit/audit_2.7.6.bb
@@ -15,8 +15,8 @@ SRC_URI = 
"http://people.redhat.com/sgrubb/${BPN}/${BPN}-${PV}.tar.gz \
file://auditd.service \
file://audit-volatile.conf \
 "
-SRC_URI[md5sum] = "b224ea6f000c8281e5deee86903ac5ba"
-SRC_URI[sha256sum] = 
"0441790794fd9375dbca598fa0ffb46c57ff37b3a24b94ffec0bbee3215cca09"
+SRC_URI[md5sum] = "55a81bbed973b58a90590c949e71dc3e"
+SRC_URI[sha256sum] = 
"fa65289cffdc95a25bfbdba541f43ee1b12c707090a38fd027dcf9354b9014e7"
 
 inherit autotools pythonnative update-rc.d systemd
 
-- 
2.7.4



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

Re: [yocto] [yocto-docs][PATCH v2] ref-manual: Replace uclibc to musl

[Kristi Rifenbark]

Changhyeok,

Fix is backported to morty (2.2.2) -
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?h=morty=e131c26ee1ab268679f7762dbe26760bd859e0e5

Fix is backported to pyro (2.3.1) -
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?h=pyro=859549a1dbc0b63bc04310a121600ea622509256

Fix is the current master branch (2.4) -
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=ed7e62f5937576d7878eb955fda12c18e787db18

If you want to see these changes in the manual see the published ref-manual
for 2.2.2, 2.3.1, and 2.4.

Thanks,
Kristi

On Tue, Jun 20, 2017 at 9:44 AM, Changhyeok Bae 
wrote:

> Hi Scott, Kristi
>
> Could review my changes?
>
> Thanks
> Changhyeok
>
> 2017-06-12 14:52 GMT+09:00 Changhyeok Bae :
>
>> This patch should be merged in morty (2.2), pryo (2.3), and master branch.
>>
>> Thanks
>> Changhyeok
>>
>> 2017-06-12 13:07 GMT+09:00 Changhyeok Bae :
>>
>>> uClibc Replaced by musl from Yocto 2.2
>>>
>>> Signed-off-by: Changhyeok Bae 
>>> ---
>>>  documentation/ref-manual/ref-variables.xml | 14 +++---
>>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/documentation/ref-manual/ref-variables.xml
>>> b/documentation/ref-manual/ref-variables.xml
>>> index bd9e517..0967e40 100644
>>> --- a/documentation/ref-manual/ref-variables.xml
>>> +++ b/documentation/ref-manual/ref-variables.xml
>>> @@ -5131,9 +5131,9 @@
>>>  is normally the same as the
>>>  >> ame>TARGET_OS.
>>>  The variable can be set to "linux" for
>>> glibc-based systems and
>>> -to "linux-uclibc" for uclibc.
>>> +to "linux-musl" for musl.
>>>  For ARM/EABI targets, there are also
>>> "linux-gnueabi" and
>>> -"linux-uclibc-gnueabi" values possible.
>>> +"linux-musleabi" values possible.
>>>  
>>>  
>>>  
>>> @@ -14152,9 +14152,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
>>> = "${INC_PR}.3"
>>>  
>>>  Specifies the target's operating system.
>>>  The variable can be set to "linux" for
>>> glibc-based systems and
>>> -to "linux-uclibc" for uclibc.
>>> +to "linux-musl" for musl.
>>>  For ARM/EABI targets, there are also
>>> "linux-gnueabi" and
>>> -"linux-uclibc-gnueabi" values possible.
>>> +"linux-musleabi" values possible.
>>>  
>>>  
>>>  
>>> @@ -14283,7 +14283,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
>>> = "${INC_PR}.3"
>>>
>>>  TCLIBC
>>>  
>>> -TCLIBC[doc] = "Specifies GNU standard C library (libc)
>>> variant to use during the build process. You can select 'glibc' or
>>> 'uclibc'."
>>> +TCLIBC[doc] = "Specifies GNU standard C library (libc)
>>> variant to use during the build process. You can select 'glibc' or 'musl'."
>>>  
>>>  
>>>  
>>> @@ -14295,7 +14295,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
>>> = "${INC_PR}.3"
>>>  
>>>
>>>  
>>> -You can select "glibc" or "uclibc".
>>> +You can select "glibc" or "musl".
>>>  
>>>  
>>>  
>>> @@ -14334,7 +14334,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
>>> = "${INC_PR}.3"
>>>  >> >TCLIBC,
>>>  which controls the variant of the GNU standard C
>>> library
>>>  (libc) used during the build
>>> process:
>>> -glibc or
>>> uclibc.
>>> +glibc or
>>> musl.
>>>  
>>>
>>>  
>>> --
>>> 2.7.4
>>>
>>>
>>
>>
>> --
>> Thanks
>> Changhyeok
>>
>
>
>
> --
> Thanks
> Changhyeok
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH] WIP solution to bug-11197: adding asynchronous task execution with celery and rabbitmq

[Diana Thayer]

- updated readme to include RabbitMQ as a dependency
- updated settings.py to include RABBIT_BROKER and RABBIT_BACKEND
- added celery to requirements.txt
- defined celery tasks in layerindex/tasks.py
- separated layerindex/update#main into two functions: main (which parses 
sys.argv) and do_update (which accepts options as keyword arguments)
- updated layerindex/views.py to use the send_email task to asynchronously 
message anyone able to publish layers when a new layer is submitted
---
 README   |   5 +-
 layerindex/tasks.py  |  31 +++
 layerindex/update.py | 143 +++
 layerindex/views.py  |   7 ++-
 requirements.txt |   1 +
 settings.py  |   4 ++
 6 files changed, 120 insertions(+), 71 deletions(-)
 create mode 100644 layerindex/tasks.py

diff --git a/README b/README
index 62f739d..cfcc37f 100644
--- a/README
+++ b/README
@@ -14,6 +14,7 @@ In order to make use of this application you will need:
 * Python 3.4+
 * Django 1.8.x - tested with 1.8.17; newer versions may work, but
   the application has not been tested with 1.9 or newer.
+* RabbitMQ 3.6.x - tested with 3.6.10.
 * For production usage, a web server set up to host Django applications
   (not needed for local-only testing)
 * A database supported by Django (SQLite, MySQL, etc.). Django takes
@@ -41,7 +42,9 @@ Setup instructions:
 1. Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and
other settings specific to your installation. Ensure you set
LAYER_FETCH_DIR to an absolute path to a location with sufficient
-   space for fetching layer repositories.
+   space for fetching layer repositories. Modify RABBIT_BROKER
+   and RABBIT_BACKEND to reflect the settings used by your RabbitMQ
+   server.
 
 2. Run the following commands within the layerindex-web directory to
initialise the database:
diff --git a/layerindex/tasks.py b/layerindex/tasks.py
new file mode 100644
index 000..9bb4701
--- /dev/null
+++ b/layerindex/tasks.py
@@ -0,0 +1,31 @@
+from celery import Celery
+from django.core.mail import EmailMessage
+import os
+import time
+
+try:
+  from update import do_update
+except ImportError:
+  from .update import do_update
+
+try:
+  import settings
+except ImportError:
+  # not in a full django env, so settings is inaccessible.
+  # setup django to access settings.
+  from utils import setup_django
+  setup_django()
+  import settings
+
+tasks = Celery('layerindex',
+broker=settings.RABBIT_BROKER,
+backend=settings.RABBIT_BACKEND)
+
+@tasks.task
+def update(**options):
+  return do_update(**options)
+
+@tasks.task
+def send_email(subject, text_content, from_email=settings.DEFAULT_FROM_EMAIL, 
to_emails=[]):
+  msg = EmailMessage(subject, text_content, from_email, to_emails)
+  msg.send()
diff --git a/layerindex/update.py b/layerindex/update.py
index d5c56cd..f1c5039 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -17,7 +17,11 @@ import subprocess
 import signal
 from datetime import datetime, timedelta
 from distutils.version import LooseVersion
-import utils
+
+try:
+import utils
+except ImportError:
+from . import utils
 
 import warnings
 warnings.filterwarnings("ignore", category=DeprecationWarning)
@@ -71,73 +75,32 @@ def prepare_update_layer_command(options, branch, layer, 
updatedeps=False):
 cmd = '%s update_layer.py -l %s -b %s' % (cmdprefix, layer.name, 
branch.name)
 if updatedeps:
 cmd += ' --update-dependencies'
-if options.reload:
+if options.get('reload'):
 cmd += ' --reload'
-if options.fullreload:
+if options.get('fullreload'):
 cmd += ' --fullreload'
-if options.nocheckout:
+if options.get('nocheckout'):
 cmd += ' --nocheckout'
-if options.dryrun:
+if options.get('dryrun'):
 cmd += ' -n'
-if options.loglevel == logging.DEBUG:
+if options.get('loglevel') == logging.DEBUG:
 cmd += ' -d'
-elif options.loglevel == logging.ERROR:
+elif options.get('loglevel') == logging.ERROR:
 cmd += ' -q'
 return cmd
 
-
-def main():
-if LooseVersion(git.__version__) < '0.3.1':
-logger.error("Version of GitPython is too old, please install 
GitPython (python-git) 0.3.1 or later in order to use this script")
-sys.exit(1)
-
-
-parser = optparse.OptionParser(
-usage = """
-%prog [options]""")
-
-parser.add_option("-b", "--branch",
-help = "Specify branch(es) to update (use commas to separate 
multiple). Default is all enabled branches.",
-action="store", dest="branch", default='')
-parser.add_option("-l", "--layer",
-help = "Specify layers to update (use commas to separate 
multiple). Default is all published layers.",
-action="store", dest="layers")
-parser.add_option("-r", "--reload",
-help = "Reload recipe data instead of updating since last update",
-action="store_true", 

Re: [yocto] [meta-chip] Jenkins, reviews and mailing list

[Trevor Woerner]

On Mon, Jun 26, 2017 at 9:21 AM, Andrei Gherzan  wrote:
> We've been testing a setup with meta-raspberrypi which seems to work fine:
> PR to github integrated with a jenkins server and use mailing list for
> discussions.
>
> I propose to copy the same setup to meta-chip too.

That's all fine. As the maintainer (thank you!) you're welcome to use
whatever workflow with which you're the happiest... as long as you
update the "Contributing" section of the README :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Include meta-qt5 in an eSDK build ?

[Jan-Simon Möller]

Hi !
How can I build an eSDK that includes meta-qt5 ?

The examples I found use the 'traditional' sdk and 
add the classes from meta-qt5.

But I have not seen the eSDK being used, yet.

--
Jan-Simon Möller
dl...@gmx.de

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

[yocto] [meta-chip] Jenkins, reviews and mailing list

[Andrei Gherzan]

Hello all,

We've been testing a setup with meta-raspberrypi which seems to work fine:
PR to github integrated with a jenkins server and use mailing list for
discussions. I recommend people pushing their patches to the mailing list
too even if they send pull requests so people who don't use github that
much can have a chance to be informed on what is changing. We've been
dragging this setup for a couple of months (I think) now and it looks great
especially easing the work of the maintainer.

I propose to copy the same setup to meta-chip too. We will be using the
same server for jenkins (https://yocto-ci.resin.io/) and the github
repository https://github.com/agherzan/meta-chip .  Yes, I am aware of
multiple forks of the same repository but given that this repository saw
some activity lately I will consolidate the work hoping that the other
repositories will contribute back to it.

Any comments?

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

[yocto] Shared State Cache and STAGING_KERNEL_DIR

[Koehler, Yannick]

Hi,

  I am in need of assistance.  I have a package that install headers required 
for a kernel modules build out-of-tree.  To enable the kernel module to build, 
I install the required header files under STAGING_KERNEL_DIR, and it works for 
the first build, subsequent builds failed due to the shared state cache 
artefact missing the files installed in the STAGING_KERNEL_DIR folder as this 
is not part of the output content looked at to build the .ipk files (I assume).

  As such, I would like to understand what would be the correct approach for me 
to have headers shared across multiple package at the kernel level.  I 
understand that for user space, we install to /usr/include and that then gets 
packaged and re-install to the sysroot using STAGING_INCDIR.  Is there a 
similar system for kernel level sharing of header files?

 I am thinking of 2 approach to solve my solution, one would be to install the 
header under STAGING_INCDIR and then add a CFLAGS to my kernel module to 
include the STAGING_INCDIR during compilation.  This looks like a hack to me 
since this folder was not intended to be used for kernel space building.

  Second solution I can think of, is to instruct the Shared State Cache system 
to look for output change in STAGING_KERNEL_DIR and record those, so that they 
get somehow restored.  I have attempted to do so by adding 

 do_install[sstate-outputdirs] += "${STAGING_KERNEL_DIR}"

  statement, but it didn't appear to have worked successfully.

  Any help would be appreciated.

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

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: deploy vfat partition

[Andrei Gherzan]

On Thu, Jun 22, 2017 at 10:11 PM, Matthew McClintock  wrote:

> On Wed, Jun 21, 2017 at 9:26 AM, Andrei Gherzan  wrote:
> > P.S.: Would really be helpful to push a PR to github too so I can merge
> it
> > easier.
>
>
> FYI: https://github.com/agherzan/meta-raspberrypi/pull/86
>
> -M
>

Looks good. Merged in master.
--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip][PATCH 2/2] u-boot: Backport upstream fix for gmac_rockchip

[Romain Perier]

Hi,


Le 18/06/2017 à 00:29, Trevor Woerner a écrit :
> Hi Romain,
>
> I assume this patch is meant to fix an ethernet issue in u-boot? How does
> someone test that ethernet is working from u-boot?

Because it has been merged on upstream and tested by Simon and me.
It only fixes ethernet for 100mbps, another fix for 1gbs is on the way.

Could you retry with ethernet 100mbs ? (in the worst case force your
autonego with ethtool...)

Thanks,
Romain

>
> Here is my firefly booting with these patches:
>
>
>   U-Boot SPL 2017.05 (Jun 17 2017 - 17:12:20)
>   Returning to boot ROM...
>
>   U-Boot 2017.05 (Jun 17 2017 - 17:12:20 -0400)
>
>   Model: Firefly-RK3288
>   DRAM:  1.7 GiB
>   MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
>   *** Warning - bad CRC, using default environment
>
>   In:serial
>   Out:   serial
>   Err:   serial
>   Net:   
>   Warning: ethernet@ff29 (eth0) using random MAC address - 
> 5a:40:1a:28:0e:43
>   eth0: ethernet@ff29
>   Hit any key to stop autoboot:  0 
>
> Here is me configuring the networking stuff in u-boot:
>
>   => setenv ipaddr 192.168.142.20
>   => setenv netmask 255.255.255.0
>   => setenv serverip 192.168.142.1
>
> Then I try pinging my server:
>
>   => ping 192.168.142.1
>   ethernet@ff29 Waiting for PHY auto negotiation to complete... done
>   Speed: 100, full duplex
>   Using ethernet@ff29 device
>
> The next thing I know my firefly is rebooting:
>
>   data abort
>   pc : [<6ada703a>]  lr : [<6ada7dbb>]
>   reloc pc : [<0003303a>]lr : [<00033dbb>]
>   sp : 68d67e48  ip :  fp : 0002
>   r10: 68d77e60  r9 : 68d71ee8 r8 : 
>   r7 : 0001  r6 :  r5 : 002a  r4 : 6adfd04e
>   r3 : 1445  r2 : 148ea8c0 r1 : 018ea8c0  r0 : 6adfd04e
>   Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
>   Resetting CPU ...
>
>
>   U-Boot SPL 2017.05 (Jun 17 2017 - 17:12:20)
>   Returning to boot ROM...

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

Re: [yocto] [raspberrypi][rt] yocto Digest, Vol 81, Issue 118

[Michael Wiesing]

 
Am Montag, 26. Juni 2017 04:32 CEST, yocto-requ...@yoctoproject.org schrieb: 
 
> Send yocto mailing list submissions to
>   yocto@yoctoproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
>   yocto-requ...@yoctoproject.org
> 
> You can reach the person managing the list at
>   yocto-ow...@yoctoproject.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
> 
> 
> Today's Topics:
> 
>1. [meta-chip][PATCH V2 1/3] u-boot-chip: Deploy the
>   sunxi-spl-with-ecc.bin file. (drew.mose...@mender.io)
>2. [meta-chip][PATCH V2 0/3] Initial attempt at flashing
>   instructions. (drew.mose...@mender.io)
>3. [meta-chip][PATCH V2 2/3] chip: Build sunxi-tools-native.
>   (drew.mose...@mender.io)
>4. [meta-chip][PATCH V2 3/3] chip: Add chip-u-boot-scr recipe
>   and flash script (drew.mose...@mender.io)
>5. Current state of linux-raspberrypi-rt? (Paul D. DeRocco)
> 
> 
> --
> 
> Message: 1
> Date: Sun, 25 Jun 2017 15:55:44 -0400
> From: drew.mose...@mender.io
> To: yocto@yoctoproject.org
> Subject: [yocto] [meta-chip][PATCH V2 1/3] u-boot-chip: Deploy the
>   sunxi-spl-with-ecc.bin file.
> Message-ID:
>   
> <25feab71125423652d0a966d0039280b9ec8fe48.1498420110.git.drew.mose...@mender.io>
>   
> 
> From: Drew Moseley 
> 
> Signed-off-by: Drew Moseley 
> ---
>  conf/machine/chip.conf| 1 +
>  recipes-bsp/u-boot/u-boot-chip_git.bb | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/conf/machine/chip.conf b/conf/machine/chip.conf
> index 0a45a2f..8f54067 100644
> --- a/conf/machine/chip.conf
> +++ b/conf/machine/chip.conf
> @@ -21,6 +21,7 @@ KERNEL_IMAGETYPE = "zImage"
>  KERNEL_DEVICETREE = "sun5i-r8-chip.dtb"
>  
>  SPL_BINARY = "sunxi-spl.bin"
> +SPL_ECC_BINARY = "sunxi-spl-with-ecc.bin"
>  UBOOT_BINARY = "u-boot-dtb.bin"
>  UBOOT_MACHINE = "CHIP_defconfig"
>  
> diff --git a/recipes-bsp/u-boot/u-boot-chip_git.bb 
> b/recipes-bsp/u-boot/u-boot-chip_git.bb
> index 8e2be50..f12fae6 100644
> --- a/recipes-bsp/u-boot/u-boot-chip_git.bb
> +++ b/recipes-bsp/u-boot/u-boot-chip_git.bb
> @@ -19,7 +19,13 @@ SRC_URI = " \
>  S = "${WORKDIR}/git"
>  
>  do_compile_append() {
> +install ${B}/spl/${SPL_ECC_BINARY} ${B}/${SPL_ECC_BINARY}
>  install ${B}/spl/${SPL_BINARY} ${B}/${SPL_BINARY}
>  }
>  
>  COMPATIBLE_MACHINE = "chip"
> +
> +do_deploy_append() {
> +install -m 644 ${B}/${SPL_ECC_BINARY} 
> ${DEPLOYDIR}/${SPL_ECC_BINARY}-${PV}-${PR}
> +ln -sf ${SPL_ECC_BINARY}-${PV}-${PR} ${DEPLOYDIR}/${SPL_ECC_BINARY}
> +}
> \ No newline at end of file
> -- 
> 2.7.4
> 
> 
> 
> --
> 
> Message: 2
> Date: Sun, 25 Jun 2017 15:55:43 -0400
> From: drew.mose...@mender.io
> To: yocto@yoctoproject.org
> Subject: [yocto] [meta-chip][PATCH V2 0/3] Initial attempt at flashing
>   instructions.
> Message-ID: 
> 
> From: Drew Moseley 
> 
> * V2:
> 
> Updated README and layer dependencies.
> 
> Added error checking to flashing script
> 
> * V1:
> 
> This set of patches adds the native tools and target components needed to
> reflash the CHIP boards.  Additionally a shell script is added to the deploy
> directory showing how to kick off a flash update. It's not ideal as I've
> hardcoded a max size for the UBI image into the script and didn't see much
> of an alternative. It does function though.
> 
> Drew
> 
> The following changes since commit 0079e6ac10fc371d6f527270c23b887561f717aa:
> 
>   chip: Append to MACHINE_EXTRA_RRECOMMENDS rather than overwriting 
> (2017-06-15 13:37:19 +0100)
> 
> are available in the git repository at:
> 
>   g...@github.com:drewmoseley/meta-chip.git flashing-instructions-v2
> 
> for you to fetch changes up to ddbfd00d73ea022aaa02005393a326d8802dd64a:
> 
>   chip: Add chip-u-boot-scr recipe and flash script (2017-06-25 15:28:54 
> -0400)
> 
> 
> Drew Moseley (3):
>   u-boot-chip: Deploy the sunxi-spl-with-ecc.bin file.
>   chip: Build sunxi-tools-native.
>   chip: Add chip-u-boot-scr recipe and flash script
> 
>  README  | 94 
> -
>  conf/layer.conf |  3 +
>  conf/machine/chip.conf  |  3 +-
>  recipes-bsp/chip-u-boot-scr/chip-u-boot-scr.bb  | 89 +++
>  recipes-bsp/chip-u-boot-scr/files/boot.cmd.full | 32 +
>  recipes-bsp/chip-u-boot-scr/files/boot.cmd.in   | 43 +++
>  recipes-bsp/u-boot/u-boot-chip_git.bb   |  7 ++
>  7 files changed, 269 insertions(+), 2 deletions(-)
>  create 

Re: [yocto] Current state of linux-raspberrypi-rt?

[Paul D. DeRocco]

> From: Trevor Woerner [mailto:twoer...@gmail.com] 
> 
> > Google turns up a lot of stuff about this, but the latest I 
> > found was a
> > thread from 1/5/17 that started with Trevor Woerner posting 
> > a 1MB patch,
> > and that ended with him posting a message saying that it 
> > didn't actually work.
> 
> I posted a v1, which worked great, and continues to work great.
> 
> After posting the v1, lots of feedback was given. One of those pieces
> of feedback was that I shouldn't include the entire defconfig, but
> rather I should use some sort of "savedconfig" setting to generate the
> full config. I had never heard of this before. I asked for more
> clarification but received none. I went ahead with the v2 using this
> "savedconfig" technique. It *appeared* to work (which is why I
> submitted the update to the mailing list), but, after a lot of
> testing, I discovered that this "savedconfig" thing didn't work. The
> defconfig that was generated using this technique was useless and
> nobody could provide any reason why or advice how to fix it.
> 
> So v2 didn't work, but v1 did and still does (we're using it 
> internally).
> 
> But everyone considered v1 to not be acceptable for inclusion for a
> number of reasons, so it never got merged. Besides, that work was for
> a 4.4 kernel, which is now considered "old".
> 
> > Is there anything new on this? I'm trying to do some 
> > compute-intensive
> > audio on an RPi3, and it really needs a real-time kernel.
> 
> Andreas Müller has a meta-raspberrypi fork in which he has an -rt
> recipe for a 4.9 kernel:
> https://github.com/schnitzeltony/meta-raspi-light

Thanks to you and Andreas for doing this.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] Current state of linux-raspberrypi-rt?

[Andreas Müller]

On Mon, Jun 26, 2017 at 7:19 AM, Trevor Woerner  wrote:
> On Sun, Jun 25, 2017 at 10:32 PM, Paul D. DeRocco
>  wrote:
>> Google turns up a lot of stuff about this, but the latest I found was a
>> thread from 1/5/17 that started with Trevor Woerner posting a 1MB patch,
>> and that ended with him posting a message saying that it didn't actually
>> work.
>
> I posted a v1, which worked great, and continues to work great.
>
> After posting the v1, lots of feedback was given. One of those pieces
> of feedback was that I shouldn't include the entire defconfig, but
> rather I should use some sort of "savedconfig" setting to generate the
> full config. I had never heard of this before. I asked for more
> clarification but received none. I went ahead with the v2 using this
> "savedconfig" technique. It *appeared* to work (which is why I
> submitted the update to the mailing list), but, after a lot of
> testing, I discovered that this "savedconfig" thing didn't work. The
> defconfig that was generated using this technique was useless and
> nobody could provide any reason why or advice how to fix it.
>
> So v2 didn't work, but v1 did and still does (we're using it internally).
>
> But everyone considered v1 to not be acceptable for inclusion for a
> number of reasons, so it never got merged. Besides, that work was for
> a 4.4 kernel, which is now considered "old".
>
>> Is there anything new on this? I'm trying to do some compute-intensive
>> audio on an RPi3, and it really needs a real-time kernel.
>
> Andreas Müller has a meta-raspberrypi fork in which he has an -rt
> recipe for a 4.9 kernel:
> https://github.com/schnitzeltony/meta-raspi-light
Yes - I run music sequencer/synthesizer stuff on top of jack on
RPi2/3. So I use RT-kernel by default and am really happy with it.

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

[yocto] network problems when running simple MS IoT Hub sample C application

[Jakob Hasse]

Hello,

I'm trying to  run the Mircosoft Azure IoT hub mqtt example 
(iothub_client_sample_amqp or simliar) of the C SDK on yocto 
(https://github.com/Azure/azure-iot-sdk-c).
On my Ubuntu host machine, everything compiles and works fine, the 
application connects to the azure server and sends messages.
In Yocto, I get errors after compiling the whole SDK with all examples, 
but the mqtt example is already there, so I assume it's correct. 
Furthermore, I could compile it using Intel's meta-iot-cloud layer and 
only taking the example application itself into my own layer.


Now the actual problem:
When I run the application on the Yocto system, it establishes a tcp 
connection to the azure server, but then "stops working", until the 
azure server sends the tcp fin ack, which the the application 
acknowlegdes. On TCP dump I can see that packets were dropped by the 
kernel.
The tcp problem seems to occur while the azure server is transmitting 
the certificate, if I interpret the tcpdump output correctly. But might 
be just coincidence. I checked the openssl libs requested by the 
application and they are the same on the Ubuntu host and on the Yocto 
embedded system.


The network is also the same as on the host machine.

I would be very happy for ideas about what went wrong here.

Best regards,
Jakob

--
Jakob Hasse
Software Developement

E: jakob.ha...@smart-home-technology.ch
T: +41 44 552 02 66

Smart Home Technology GmbH
www.smart-home-technology.ch

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