Date   

Re: meta-zephyr layer

Philip Balister
 

Does that work without poky?

Philip

On 12/12/2016 02:15 PM, Bystricky, Juro wrote:
There is interest in the community to support building Zephyr images
( https://www.zephyrproject.org/ )in Yocto via bitbake recipes.
AFAIK the only way thus far to build Zephyr images is based on command
line/Kconfig, similar to building Linux kernel images.

Building of Zephyr images in Yocto can now be done fairly unobtrusively
via a new layer "meta-zephyr" and specifying a new distro in local.conf:
DISTRO="zephyr"

The repository for the meta-zephyr is here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr.

The new meta-zephyr layer contains several recipes to build (and run
in QEMUs) various Zephyr tests. There is also a sample recipe to build
Zephyr sample "philosophers" with instructions how to run it in QEMU.

This is the first kick at the can.
At present, only x86 and ARM CortexM3 toolchains are supported, with
more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU,
and Xtensa and RISC-V coming in the next release)

The new meta-zephyr is work based on previous original work by
Randy Witt and Richard Purdie, so it is actually a second kick at the can.

This is a work in progress, any feedback is appreciated.

Juro


meta-zephyr layer

Bystricky, Juro
 

There is interest in the community to support building Zephyr images
( https://www.zephyrproject.org/ )in Yocto via bitbake recipes.
AFAIK the only way thus far to build Zephyr images is based on command
line/Kconfig, similar to building Linux kernel images.

Building of Zephyr images in Yocto can now be done fairly unobtrusively
via a new layer "meta-zephyr" and specifying a new distro in local.conf:
DISTRO="zephyr"

The repository for the meta-zephyr is here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr.

The new meta-zephyr layer contains several recipes to build (and run
in QEMUs) various Zephyr tests. There is also a sample recipe to build
Zephyr sample "philosophers" with instructions how to run it in QEMU.

This is the first kick at the can.
At present, only x86 and ARM CortexM3 toolchains are supported, with
more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU,
and Xtensa and RISC-V coming in the next release)

The new meta-zephyr is work based on previous original work by
Randy Witt and Richard Purdie, so it is actually a second kick at the can.

This is a work in progress, any feedback is appreciated.

Juro


Re: Kernel config incremental modification not working.

Paul Eggleton
 

On Mon, 12 Dec 2016 08:41:36 Bruce Ashfield wrote:
On 2016-12-11 02:33 PM, Paul Eggleton wrote:
Can we please have some automated tests covering all of this? Perhaps it
would be worth talking to Francisco Pedraza who is looking at adding
tests under bug
6359:
We are already meeting to talk about this :D
Superb, thanks!

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Can't enable reverse debugging

Bryan Evenson
 

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Monday, December 12, 2016 2:54 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging


On Dec 12, 2016, at 11:12 AM, Bryan Evenson
<bevenson@...> wrote:

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Monday, December 12, 2016 12:48 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging


On Dec 12, 2016, at 6:59 AM, Bryan Evenson
<bevenson@...>
wrote:

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Saturday, December 10, 2016 4:26 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging

On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson
<bevenson@...>
wrote:
I tried a few other things, see below.

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Bryan Evenson
Sent: Thursday, December 08, 2016 2:50 PM
To: yocto@...
Subject: [yocto] Can't enable reverse debugging

I'm on poky/dizzy and I'm getting a segementation fault in my
application that I think may be related to a buffer overflow.
I'm using the Eclipse
plug-in
(on Eclipse Kepler) to debug on the hardware with GDB. I'm
trying to
enable
reverse debugging but I have not had any success and I'm looking
for
some
help.

My target processor is an SAM9G25 (ARM926EJ-S core). I have been
able
to
debug through Eclipse on the target hardware without issue. I
tried
enabling
Reverse Debugging by going to Window->Customize Perspective...-
Command Groups Availability and selecting "Reverse Debugging".
Now
there is a "Reverse Toggle" button on my toolbar, but it is
always grayed
out
whether I have a debug session running or not. I have also tried
entering
the
command "record" from the GDB console after my program breaks
at
main.
When I run the program, I get the error message "Process record:
failed
to
record execution log".
I tried first running my application, pausing the debugger and
then sending
the "record" command. When I continued debugging, I got the
following GDB error:

....x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0
/g
db-
7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected, further debugging may
prove unreliable.

I did some looking around and I couldn't see any reasonable answer
to why
this would happen. I also just noticed that for the Debug
Configurations under Eclipse, the debugger settings tab doesn't
have "Enable Reverse Debugging at startup" option listed for the
C/C++ Remote Application debugging type. Is this option just not
available to me
with my environment?

This could mean many things but one area I know is troublesome is
python support. Sometimes there are issues between fundamental
types,
can you check if the error happens when gdb is running some
pythonic stuff.
Could you explain how to do this? I don't use Python so I'm not
sure if I'm
doing a valid test. I tried to debug a Python script with GDB
through Eclipse and I wasn't successful. I then went through the
command line and was able to remotely run a simple Python script
(print "Hello, Python" once per
second) through GDB. If I issued a "record" command through GDB
first, then when I tried to debug the Python script I'd immediately
get a segmentation fault.

Is there something specific you'd like me to try? If you think the
Python
support may be the issue, is there something I should be verifying is
present or is at a certain version?
Disable python support in gdb and compile it e.g.
I rebuilt gdb. I used the --configure option to verify that my previous gdb
did have the "--with-python" option present and that my newly built gdb did
not have that option anymore. I no longer can produce the " internal-error:
virtual memory exhausted" error, but whenever I try to record I still get the
"Process record: failed to record execution log" when I run the application. If
it helps, here's the configuration output from GDB:

This GDB was configured as follows:
configure --host=x86_64-linux --target=arm-poky-linux-gnueabi
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=~/poky/poky-build/tmp/sysroots/x86_64-
linux/usr/share/gdb-arm926ejste-poky-linux-gnueabi/gdb (relocatable)
--with-jit-reader-dir=~/poky/poky-build/tmp/sysroots/x86_64-
linux/usr/lib/arm-poky-linux-gnueabi/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--with-separate-debug-dir=~/poky/poky-
build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/debug
(relocatable)
--with-zlib
--without-babeltrace

Any additional suggestions would be appreciated.
Can you build an application with out splitting the debug info. May be have
toolchain on target and then compile a program natively and see if that works
For the application I am debugging through Eclipse I am using a self-built SDK to build the application. I verified that the debugging info has not been split out from the executable that I'm using for testing. The target I'm using only has 256MB of flash and 128MB of RAM, so I'm not sure if I'd be able to build the application natively.

Bryan


Re: Can't enable reverse debugging

Khem Raj
 

On Dec 12, 2016, at 11:12 AM, Bryan Evenson <bevenson@...> wrote:

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Monday, December 12, 2016 12:48 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging


On Dec 12, 2016, at 6:59 AM, Bryan Evenson <bevenson@...>
wrote:

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Saturday, December 10, 2016 4:26 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging

On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson
<bevenson@...>
wrote:
I tried a few other things, see below.

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Bryan Evenson
Sent: Thursday, December 08, 2016 2:50 PM
To: yocto@...
Subject: [yocto] Can't enable reverse debugging

I'm on poky/dizzy and I'm getting a segementation fault in my
application that I think may be related to a buffer overflow. I'm
using the Eclipse
plug-in
(on Eclipse Kepler) to debug on the hardware with GDB. I'm trying
to
enable
reverse debugging but I have not had any success and I'm looking
for
some
help.

My target processor is an SAM9G25 (ARM926EJ-S core). I have been
able
to
debug through Eclipse on the target hardware without issue. I
tried
enabling
Reverse Debugging by going to Window->Customize Perspective...-
Command Groups Availability and selecting "Reverse Debugging".
Now
there is a "Reverse Toggle" button on my toolbar, but it is always
grayed
out
whether I have a debug session running or not. I have also tried
entering
the
command "record" from the GDB console after my program breaks at
main.
When I run the program, I get the error message "Process record:
failed
to
record execution log".
I tried first running my application, pausing the debugger and then
sending
the "record" command. When I continued debugging, I got the
following GDB error:

....x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/g
db-
7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected, further debugging may
prove unreliable.

I did some looking around and I couldn't see any reasonable answer
to why
this would happen. I also just noticed that for the Debug
Configurations under Eclipse, the debugger settings tab doesn't have
"Enable Reverse Debugging at startup" option listed for the C/C++
Remote Application debugging type. Is this option just not available to me
with my environment?

This could mean many things but one area I know is troublesome is
python support. Sometimes there are issues between fundamental
types,
can you check if the error happens when gdb is running some pythonic
stuff.
Could you explain how to do this? I don't use Python so I'm not sure if I'm
doing a valid test. I tried to debug a Python script with GDB through Eclipse
and I wasn't successful. I then went through the command line and was able
to remotely run a simple Python script (print "Hello, Python" once per
second) through GDB. If I issued a "record" command through GDB first,
then when I tried to debug the Python script I'd immediately get a
segmentation fault.

Is there something specific you'd like me to try? If you think the Python
support may be the issue, is there something I should be verifying is present
or is at a certain version?
Disable python support in gdb and compile it e.g.
I rebuilt gdb. I used the --configure option to verify that my previous gdb did have the "--with-python" option present and that my newly built gdb did not have that option anymore. I no longer can produce the " internal-error: virtual memory exhausted" error, but whenever I try to record I still get the "Process record: failed to record execution log" when I run the application. If it helps, here's the configuration output from GDB:

This GDB was configured as follows:
configure --host=x86_64-linux --target=arm-poky-linux-gnueabi
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/share/gdb-arm926ejste-poky-linux-gnueabi/gdb (relocatable)
--with-jit-reader-dir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--with-separate-debug-dir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/debug (relocatable)
--with-zlib
--without-babeltrace

Any additional suggestions would be appreciated.
Can you build an application with out splitting the debug info. May be have toolchain on target and then compile a program natively and see if that works


Re: Can't enable reverse debugging

Bryan Evenson
 

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Monday, December 12, 2016 12:48 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging


On Dec 12, 2016, at 6:59 AM, Bryan Evenson <bevenson@...>
wrote:

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Saturday, December 10, 2016 4:26 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging

On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson
<bevenson@...>
wrote:
I tried a few other things, see below.

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Bryan Evenson
Sent: Thursday, December 08, 2016 2:50 PM
To: yocto@...
Subject: [yocto] Can't enable reverse debugging

I'm on poky/dizzy and I'm getting a segementation fault in my
application that I think may be related to a buffer overflow. I'm
using the Eclipse
plug-in
(on Eclipse Kepler) to debug on the hardware with GDB. I'm trying
to
enable
reverse debugging but I have not had any success and I'm looking
for
some
help.

My target processor is an SAM9G25 (ARM926EJ-S core). I have been
able
to
debug through Eclipse on the target hardware without issue. I
tried
enabling
Reverse Debugging by going to Window->Customize Perspective...-
Command Groups Availability and selecting "Reverse Debugging".
Now
there is a "Reverse Toggle" button on my toolbar, but it is always
grayed
out
whether I have a debug session running or not. I have also tried
entering
the
command "record" from the GDB console after my program breaks at
main.
When I run the program, I get the error message "Process record:
failed
to
record execution log".
I tried first running my application, pausing the debugger and then
sending
the "record" command. When I continued debugging, I got the
following GDB error:

....x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/g
db-
7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected, further debugging may
prove unreliable.

I did some looking around and I couldn't see any reasonable answer
to why
this would happen. I also just noticed that for the Debug
Configurations under Eclipse, the debugger settings tab doesn't have
"Enable Reverse Debugging at startup" option listed for the C/C++
Remote Application debugging type. Is this option just not available to me
with my environment?

This could mean many things but one area I know is troublesome is
python support. Sometimes there are issues between fundamental
types,
can you check if the error happens when gdb is running some pythonic
stuff.
Could you explain how to do this? I don't use Python so I'm not sure if I'm
doing a valid test. I tried to debug a Python script with GDB through Eclipse
and I wasn't successful. I then went through the command line and was able
to remotely run a simple Python script (print "Hello, Python" once per
second) through GDB. If I issued a "record" command through GDB first,
then when I tried to debug the Python script I'd immediately get a
segmentation fault.

Is there something specific you'd like me to try? If you think the Python
support may be the issue, is there something I should be verifying is present
or is at a certain version?
Disable python support in gdb and compile it e.g.
I rebuilt gdb. I used the --configure option to verify that my previous gdb did have the "--with-python" option present and that my newly built gdb did not have that option anymore. I no longer can produce the " internal-error: virtual memory exhausted" error, but whenever I try to record I still get the "Process record: failed to record execution log" when I run the application. If it helps, here's the configuration output from GDB:

This GDB was configured as follows:
configure --host=x86_64-linux --target=arm-poky-linux-gnueabi
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/share/gdb-arm926ejste-poky-linux-gnueabi/gdb (relocatable)
--with-jit-reader-dir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--with-separate-debug-dir=~/poky/poky-build/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/debug (relocatable)
--with-zlib
--without-babeltrace

Any additional suggestions would be appreciated.

Thanks,
Bryan


Thanks,
Bryan


Re: update mechanisms

Patrick Ohly
 

On Mon, 2016-12-12 at 09:49 -0600, Mariano Lopez wrote:

On 12/12/16 09:41, Patrick Ohly wrote:
On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote:
In particular the "complexity" column is a bit subjective. Stefano, I
hope you don't mind that I did not quite buy the "easy to use"
characterization of swupdate ;-)
No worry...and I have not written myself. It was inserted by Mariano, so
it looks like that swupdate at least for Mariano is "easy to use".
I think it is correct to point out that customization is required.
Compared to other update mechanism that I tested it was the easier to
implement.
Which "getting started" document or presentation were you using? The
documentation for mender (https://docs.mender.io/) is very
straight-forward (partly of course because it doesn't need to cover many
variations), while for swupdate
(http://sbabic.github.io/swupdate/swupdate.html) I found it less clear
how to begin.
When I did a research in update mechanism, mender wasn't yet available,
and indeed it seems very straight forward (need to test it before final
veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is
by far less complex than the other two
Ease-of-use is not necessarily determined by the complexity. Good
integration and documentation can go a long way towards making a complex
solution easy to use - when sticking to the pre-defined usage patterns.

The opposite is also true: a simple solution may be hard to use if all
one gets is the source code and one first has to reverse-engineer the
usage model.

I agree that the complexity is roughly swupdate < ostree < swupd and
there's also no doubt that the latter two aren't easy to use (mostly due
to lacking documentation and integration), but I'm still not sure what
documentation the "easy to use" verdict for swupdate is based on.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


Re: Can't enable reverse debugging

Khem Raj
 

On Dec 12, 2016, at 6:59 AM, Bryan Evenson <bevenson@...> wrote:

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Saturday, December 10, 2016 4:26 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging

On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson <bevenson@...>
wrote:
I tried a few other things, see below.

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Bryan Evenson
Sent: Thursday, December 08, 2016 2:50 PM
To: yocto@...
Subject: [yocto] Can't enable reverse debugging

I'm on poky/dizzy and I'm getting a segementation fault in my application
that I think may be related to a buffer overflow. I'm using the Eclipse
plug-in
(on Eclipse Kepler) to debug on the hardware with GDB. I'm trying to
enable
reverse debugging but I have not had any success and I'm looking for
some
help.

My target processor is an SAM9G25 (ARM926EJ-S core). I have been able
to
debug through Eclipse on the target hardware without issue. I tried
enabling
Reverse Debugging by going to Window->Customize Perspective...-
Command Groups Availability and selecting "Reverse Debugging". Now
there is a "Reverse Toggle" button on my toolbar, but it is always grayed
out
whether I have a debug session running or not. I have also tried entering
the
command "record" from the GDB console after my program breaks at
main.
When I run the program, I get the error message "Process record: failed
to
record execution log".
I tried first running my application, pausing the debugger and then sending
the "record" command. When I continued debugging, I got the following
GDB error:

....x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/gdb-
7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

I did some looking around and I couldn't see any reasonable answer to why
this would happen. I also just noticed that for the Debug Configurations
under Eclipse, the debugger settings tab doesn't have "Enable Reverse
Debugging at startup" option listed for the C/C++ Remote Application
debugging type. Is this option just not available to me with my environment?

This could mean many things but one area I know is troublesome is
python support. Sometimes there are issues between
fundamental types, can you check if the error happens when gdb is
running some pythonic stuff.
Could you explain how to do this? I don't use Python so I'm not sure if I'm doing a valid test. I tried to debug a Python script with GDB through Eclipse and I wasn't successful. I then went through the command line and was able to remotely run a simple Python script (print "Hello, Python" once per second) through GDB. If I issued a "record" command through GDB first, then when I tried to debug the Python script I'd immediately get a segmentation fault.

Is there something specific you'd like me to try? If you think the Python support may be the issue, is there something I should be verifying is present or is at a certain version?
Disable python support in gdb and compile it e.g.

Thanks,
Bryan


Re: suggestions for version controlling multi-layer reproducible builds?

Richard Leitner
 

Hi,
On 12/12/2016 05:03 PM, Bryan Evenson wrote:

For my setup I have a separate package that is the distribution
version number. Whenever we release an update, the distribution
version number is updated. We then tag all our layers with the
distribution version number for proper record keeping. The Angstrom
distribution was (or maybe still is?) doing something similar and was
the inspiration for our setup.

...


Any time we release an update, no matter how minor, we update the
distribution version package. Otherwise, as you state, you could
have an update that you can't reproduce. We also archive the package
repository and generated image files for each release so we can flash
a board with a previous release and test from there. It can be a
pain to get the process down the first time, but after that a simple
Bash script can take care of all the hard work for you and ensure you
don't skip a step.
I'm using a similar approach, but instead of using a separate "version
package" I'm using the "BUILDNAME" and "DISTRO_VERSION" variables in my
distro.conf.

Then depending on how "large" the release is and which changes it
includes the Major, Minor or Patchlevel of the version is increased.

Furthermore (like Bryan already mentioned) for every release a tag in
every layer containing the DISTRO_VERSION is created.

The layer setup/checkout and build then is automated by a shellscript.
This shellscript takes the version as an argument and produces the
images, source archives, update packages and everything else needed for
a (nearly) reproducible builds.

Hope that helps.

regards,
Richard L


Re: suggestions for version controlling multi-layer reproducible builds?

Bryan Evenson
 

Robert,

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Monday, December 12, 2016 10:20 AM
To: Yocto discussion list <yocto@...>
Subject: [yocto] suggestions for version controlling multi-layer reproducible
builds?


(if there's already a doc section for this somewhere, a pointer to it would be
just ducky.)

if one is building an image for a releasable, commercial product, and that
image involves pulling in numerous layers, then dumping all sorts of
proprietary apps on top of it, what are the possibilities for how to version
number the released images such that, if a client has an issue, they can
identify precisely the state of components that went into the system they're
working with?
For my setup I have a separate package that is the distribution version number. Whenever we release an update, the distribution version number is updated. We then tag all our layers with the distribution version number for proper record keeping. The Angstrom distribution was (or maybe still is?) doing something similar and was the inspiration for our setup.

in addition to all of the layers involved in the build, one has to take into
account that, when critical bugs are identified, an updated RPM might be
sent out and applied, whereupon that system's version number is no longer
perfectly accurate. in the end, the state of someone's running system will be
determined by a possibly huge combination of selected packages, preferred
package versions, build config options, additional user space apps, hot fixes
that have been applied and so on.

what sort of meaningful "version number" can be applied to something like
that? i'm sure at least a few other people have to be doing something like
that, so i'm open to suggestions.

rday

Any time we release an update, no matter how minor, we update the distribution version package. Otherwise, as you state, you could have an update that you can't reproduce. We also archive the package repository and generated image files for each release so we can flash a board with a previous release and test from there. It can be a pain to get the process down the first time, but after that a simple Bash script can take care of all the hard work for you and ensure you don't skip a step.

Bryan


--

==========================================================
==============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
==========================================================
==============


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


Yocto Project Status WW51

Saul Wold <sgw@...>
 


Current Dev Position: YP 2.3 M1 -> M2

Next Deadline: YP 2.3 M1 by Dec. 12, 2016 (TODAY!!)

                        YP 2.3 M2 by Jan 23, 2017


SWAT team rotation: Tracy -> Alejandro

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


Key Status/Updates:

  • Today is the M1 feature freeze deadline. Patches are being processed with a view to merging. We believe all patchsets targeting M1 have been posted apart from tinfoil2 which is imminent and we’re planning to try and include that in M1.

  • We’re continuing to struggle to identify which patches are causing which failures which may delay M1 slightly as it is going to take time to figure this out and ensure builds are stable.

  • We’re considering the best way to handle containers and the current build appliance in the project going forwards. If anyone had input they wish to contribute on that subject, Brian has started a thread on the architecture mailing list.


Proposed upcoming dot releases:

YP 2.0.3 Release by Dec. 9, 2016

YP 2.2.1 Release by Jan. 20, 2017

YP 2.1.3 Release by May. 19, 2017


Key YP 2.3 Dates:

YP 2.3 M1 Cutoff is Dec. 12, 2016

YP 2.3 M1 Release is Dec. 23, 2016

YP 2.3 M2 Cutoff is Jan. 23, 2017

YP 2.3 M2 Release is Feb. 3, 2017

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 3, 2017

YP 2.3 M4 Release is April 28, 2017


Tracking Metrics:

WDD 2437 (last week 2507)

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


Key Status Links for YP:

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

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

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


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



Re: update mechanisms

Mariano Lopez <mariano.lopez@...>
 

On 12/12/16 09:41, Patrick Ohly wrote:
On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote:
In particular the "complexity" column is a bit subjective. Stefano, I
hope you don't mind that I did not quite buy the "easy to use"
characterization of swupdate ;-)
No worry...and I have not written myself. It was inserted by Mariano, so
it looks like that swupdate at least for Mariano is "easy to use".
I think it is correct to point out that customization is required.
Compared to other update mechanism that I tested it was the easier to
implement.
Which "getting started" document or presentation were you using? The
documentation for mender (https://docs.mender.io/) is very
straight-forward (partly of course because it doesn't need to cover many
variations), while for swupdate
(http://sbabic.github.io/swupdate/swupdate.html) I found it less clear
how to begin.
When I did a research in update mechanism, mender wasn't yet available,
and indeed it seems very straight forward (need to test it before final
veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is
by far less complex than the other two


Re: update mechanisms

Patrick Ohly
 

On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote:
In particular the "complexity" column is a bit subjective. Stefano, I
hope you don't mind that I did not quite buy the "easy to use"
characterization of swupdate ;-)
No worry...and I have not written myself. It was inserted by Mariano, so
it looks like that swupdate at least for Mariano is "easy to use".
I think it is correct to point out that customization is required.
Compared to other update mechanism that I tested it was the easier to
implement.
Which "getting started" document or presentation were you using? The
documentation for mender (https://docs.mender.io/) is very
straight-forward (partly of course because it doesn't need to cover many
variations), while for swupdate
(http://sbabic.github.io/swupdate/swupdate.html) I found it less clear
how to begin.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


Re: update mechanisms

Patrick Ohly
 

On Mon, 2016-12-12 at 15:13 +0000, André Draszik wrote:
Hi,

On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote:
I'll do the same for swupd. Editing the sections should be possible
without conflicts, we just have to be more careful about editing the
table concurrently.
It looks as if some highlights about swupdate can equally be said about
swupd:

- dual copy is supported
- my minimal swupd-based rescue initramfs is around 4MB
swupdate has support for a "dual copy
strategy" (http://sbabic.github.io/swupdate/swupdate.html#software-collections) while out-of-the-box (i.e. with what is currently available) meta-swupd and swupd itself don't. So I think it is correct to say that swupdate has some (implementation) advantage here.

The "could be extended to do updates without that risk" in the
"swupd/Failure resilience" section was meant to include a dual-copy
approach. Should that be rephrased to be more explicit? I was thinking
of several possible scenarios:
* single partition: stage files, stop services, update, restart
services or reboot
* dual partition: update inactive partition, swap partitions,
reboot

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


Re: suggestions for version controlling multi-layer reproducible builds?

Christopher Larson <clarson@...>
 


On Mon, Dec 12, 2016 at 8:20 AM, Robert P. J. Day <rpjday@...> wrote:
  if one is building an image for a releasable, commercial product,
and that image involves pulling in numerous layers, then dumping all
sorts of proprietary apps on top of it, what are the possibilities for
how to version number the released images such that, if a client has
an issue, they can identify precisely the state of components that
went into the system they're working with?

  in addition to all of the layers involved in the build, one has to
take into account that, when critical bugs are identified, an updated
RPM might be sent out and applied, whereupon that system's version
number is no longer perfectly accurate. in the end, the state of
someone's running system will be determined by a possibly huge
combination of selected packages, preferred package versions, build
config options, additional user space apps, hot fixes that have been
applied and so on.

  what sort of meaningful "version number" can be applied to something
like that? i'm sure at least a few other people have to be doing
something like that, so i'm open to suggestions.

I don’t think it’s possible for a version number to capture this at all. Better to use a script to capture the state of the system as needed. I.e. write build info to a file on target, and then combine that with a query of the package manager if you use packages for update distribution (though I wouldn’t advise use of packages for update distribution at all, that’s a different discussion :).
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics


suggestions for version controlling multi-layer reproducible builds?

Robert P. J. Day
 

(if there's already a doc section for this somewhere, a pointer to
it would be just ducky.)

if one is building an image for a releasable, commercial product,
and that image involves pulling in numerous layers, then dumping all
sorts of proprietary apps on top of it, what are the possibilities for
how to version number the released images such that, if a client has
an issue, they can identify precisely the state of components that
went into the system they're working with?

in addition to all of the layers involved in the build, one has to
take into account that, when critical bugs are identified, an updated
RPM might be sent out and applied, whereupon that system's version
number is no longer perfectly accurate. in the end, the state of
someone's running system will be determined by a possibly huge
combination of selected packages, preferred package versions, build
config options, additional user space apps, hot fixes that have been
applied and so on.

what sort of meaningful "version number" can be applied to something
like that? i'm sure at least a few other people have to be doing
something like that, so i'm open to suggestions.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: update mechanisms

André Draszik <git@...>
 

Hi,

On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote:
On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
Hi Patrick,

On 30/11/2016 15:59, Patrick Ohly wrote:
I've started a Wiki page
https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
moment, but might as well be mentioned already now.
I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
like to edit for better explanation on some parts. Should I try to edit
directly the page or is it better to discuss it here ?
Use your own judgment. If its uncontroversial, the feel free to edit the
page directly, otherwise let's discuss it here.

If feel that putting information directly into the table is too limiting
(it should be brief), then feel free to start a complete section about
SWUpdate. 

I'll do the same for swupd. Editing the sections should be possible
without conflicts, we just have to be more careful about editing the
table concurrently.
It looks as if some highlights about swupdate can equally be said about
swupd:

- dual copy is supported
- my minimal swupd-based rescue initramfs is around 4MB


Cheers,
Andre'


Re: Can't enable reverse debugging

Bryan Evenson
 

Khem,

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Saturday, December 10, 2016 4:26 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Can't enable reverse debugging

On Fri, Dec 9, 2016 at 8:43 AM, Bryan Evenson <bevenson@...>
wrote:
I tried a few other things, see below.

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Bryan Evenson
Sent: Thursday, December 08, 2016 2:50 PM
To: yocto@...
Subject: [yocto] Can't enable reverse debugging

I'm on poky/dizzy and I'm getting a segementation fault in my application
that I think may be related to a buffer overflow. I'm using the Eclipse
plug-in
(on Eclipse Kepler) to debug on the hardware with GDB. I'm trying to
enable
reverse debugging but I have not had any success and I'm looking for
some
help.

My target processor is an SAM9G25 (ARM926EJ-S core). I have been able
to
debug through Eclipse on the target hardware without issue. I tried
enabling
Reverse Debugging by going to Window->Customize Perspective...-
Command Groups Availability and selecting "Reverse Debugging". Now
there is a "Reverse Toggle" button on my toolbar, but it is always grayed
out
whether I have a debug session running or not. I have also tried entering
the
command "record" from the GDB console after my program breaks at
main.
When I run the program, I get the error message "Process record: failed
to
record execution log".
I tried first running my application, pausing the debugger and then sending
the "record" command. When I continued debugging, I got the following
GDB error:

....x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.7.1-r0/gdb-
7.7.1/gdb/utils.c:1073: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

I did some looking around and I couldn't see any reasonable answer to why
this would happen. I also just noticed that for the Debug Configurations
under Eclipse, the debugger settings tab doesn't have "Enable Reverse
Debugging at startup" option listed for the C/C++ Remote Application
debugging type. Is this option just not available to me with my environment?

This could mean many things but one area I know is troublesome is
python support. Sometimes there are issues between
fundamental types, can you check if the error happens when gdb is
running some pythonic stuff.
Could you explain how to do this? I don't use Python so I'm not sure if I'm doing a valid test. I tried to debug a Python script with GDB through Eclipse and I wasn't successful. I then went through the command line and was able to remotely run a simple Python script (print "Hello, Python" once per second) through GDB. If I issued a "record" command through GDB first, then when I tried to debug the Python script I'd immediately get a segmentation fault.

Is there something specific you'd like me to try? If you think the Python support may be the issue, is there something I should be verifying is present or is at a certain version?

Thanks,
Bryan


Re: update mechanisms

Mariano Lopez <mariano.lopez@...>
 

I
tried to summarize the key aspects of each mechanism in the table
itself. That's something that I haven't seen elsewhere and something
that the page can I tried to be as fair and objective as possible,
please shout if I messed something up or you don't agree with my
summary.

In particular the "complexity" column is a bit subjective. Stefano, I
hope you don't mind that I did not quite buy the "easy to use"
characterization of swupdate ;-)
No worry...and I have not written myself. It was inserted by Mariano, so
it looks like that swupdate at least for Mariano is "easy to use".
I think it is correct to point out that customization is required.
Compared to other update mechanism that I tested it was the easier to
implement.


Re: Kernel config incremental modification not working.

Bruce Ashfield <bruce.ashfield@...>
 

On 2016-12-11 02:33 PM, Paul Eggleton wrote:
On Fri, 09 Dec 2016 11:19:56 Bruce Ashfield wrote:
On 2016-12-09 11:17 AM, Andrea Galbusera wrote:
Hi Bruce,

On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield

<bruce.ashfield@... <mailto:bruce.ashfield@...>>
wrote:
On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:
Hi list

I am working on a project based on the iMX6UL-EVK using the
meta-fsl-arm
layer for the kernel.
In a local layer I have a bbappend recipe containing a patch for
an
extra kernel feature (a framebuffer device) in that kernel as
well as a
.cfg enabling said feature.
The bbappend recipe is located in
recipes-kernel/linux/linux-fslc-imx_%.bbappend and looks like
this:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += " \

file://0001-mxc-4.1.patch \
file://ST7789S.cfg \

"

KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"

The .cfg is located in
recipes-kernel/linux/linux-fslc-imx/ST7789S.cfg
and looks like:
CONFIG_FB_MXS_ST7789S_QVGA=y

The 0001-mxc-4.1.patch patch is correctly applied but the .cfg
is either
ignored or overwritten by some later buyild step since the
resulting
.config after kernel compilation contains:
# CONFIG_FB_MXS_ST7789S_QVGA is not set

I have tried finding the script in the build/.../temp folder
that takes
care of the .cfg file patching but have not been able to find
anything
useful.

Any hints as to where I should start looking for a solution?

Fragment processing using the kernel tools + auditing is only
currently
available to kernel recipes that use the kernel-yocto bbclass. That
opt-in requirement was to ensure that existing recipes and workflows
weren't broken by the new features.

Last time I checked, the meta-fsl* kernel recipes don't use the
kernel-yocto bbclass, so the fragment would be ignored.

I'm taking the processing of fragments and making it universally
available in the upcoming 2.3 release, so what I just described
won't be an issue for much longer.

In the mean time, you have a few options:
- in your bbappend, add "inherit kernel-yocto" and the processing

of fragments will be enabled (I can't say that I've tested
it against that recipe .. but the entire point of the new tasks
is that they are transparent/don't break existing worflows)

- carry a defconfig in your layer, and add it to the SRC_URI. That

defconfig would be the existing kernel recipe's defconfig + your
options

I was just testing one of my layers against your recent patchset on
kernel-yocto when I noticed this thread. My build is broken by commit
476ffd57cf5b6fba40d4e3f5dd913824ab8a8d3d on oe-core
(e38775a1d82e6dc60fc96cf243ecb94be964d9b2 on the poky repo side).

WARNING: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: GIZERO: before 'cmp'
ERROR: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: Function failed: do_kernel_metadata (log file is
located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
rnel_metadata.28274) ERROR: Logfile of failure stored in:
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
rnel_metadata.28274>
Log data follows:
| DEBUG: Executing shell function do_kernel_metadata
| WARNING: GIZERO: before 'cmp'

/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/defconfig
/scratch/gizero/mitysom-5csx-master-build/tmp/work-shared/cyclone5/kernel
-source/arch/arm/configs/socfpga_defconfig differ: byte 1525, line 72

| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_metadata (log file is located at

/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnu
eabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_ke
rnel_metadata.28274) ERROR: Task
(/home/gizero/work/decos/repo-master/poky/../meta-altera/recipes-kernel/li
nux/linux-altera-ltsi_4.1.22.bb:do_kernel_metadata) failed with exit code
'1'

The commit in the patch remove the 'set +e' bits, but the following
legit code path expects the cmp command to have a non-zero return value.
Aha. Indeed that is true. Clearly there aren't many people going
through that path.
Can we please have some automated tests covering all of this? Perhaps it would
be worth talking to Francisco Pedraza who is looking at adding tests under bug
6359:
We are already meeting to talk about this :D

Bruce


https://bugzilla.yoctoproject.org/show_bug.cgi?id=6359

Cheers,
Paul