[yocto] [meta-tensorflow][PATCH] tensorflow: fix logger issue on python 3.8

[Chen Qi]

We met the following error with python 3.8.

  TypeError: _logger_find_caller() takes from 0 to 1 positional arguments but 2 
were given

Backport a patch to fix this issue.

Signed-off-by: Chen Qi 
---
 ...ensorFlow-on-Python-3.8-logger-issue.patch | 55 +++
 .../tensorflow/tensorflow-native_1.13.0.bb|  1 +
 .../tensorflow/tensorflow_1.13.0.bb   |  1 +
 3 files changed, 57 insertions(+)
 create mode 100644 
recipes-framework/tensorflow/files/0001-Fix-TensorFlow-on-Python-3.8-logger-issue.patch

diff --git 
a/recipes-framework/tensorflow/files/0001-Fix-TensorFlow-on-Python-3.8-logger-issue.patch
 
b/recipes-framework/tensorflow/files/0001-Fix-TensorFlow-on-Python-3.8-logger-issue.patch
new file mode 100644
index 000..714cfed
--- /dev/null
+++ 
b/recipes-framework/tensorflow/files/0001-Fix-TensorFlow-on-Python-3.8-logger-issue.patch
@@ -0,0 +1,55 @@
+From db8840ea06bee6c8384d88edba2faa027ed74c02 Mon Sep 17 00:00:00 2001
+From: Yong Tang 
+Date: Sun, 3 Nov 2019 19:52:04 +
+Subject: [PATCH] Fix TensorFlow on Python 3.8 logger issue
+
+This fix tries to address the issue raised in 33799
+where running tensorflow on python 3.8 (Ubuntu 18.04)
+raised the following error:
+```
+TypeError: _logger_find_caller() takes from 0 to 1 positional arguments but 2 
were given
+```
+
+The issue was that findCaller changed in Python 3.8
+
+This PR fixes the issue.
+
+This PR fixes 33799
+
+Signed-off-by: Yong Tang 
+
+Upstream-Status: Backport 
[https://github.com/tensorflow/tensorflow/pull/33953/commits/ea3063c929c69f738bf65bc99dad1159803e772f]
+
+Signed-off-by: Chen Qi 
+---
+ tensorflow/python/platform/tf_logging.py | 13 +++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+diff --git a/tensorflow/python/platform/tf_logging.py 
b/tensorflow/python/platform/tf_logging.py
+index 813bcb89be..4862e70e4d 100644
+--- a/tensorflow/python/platform/tf_logging.py
 b/tensorflow/python/platform/tf_logging.py
+@@ -57,9 +57,18 @@ def _get_caller(offset=3):
+ f = f.f_back
+   return None, None
+ 
+-
+ # The definition of `findCaller` changed in Python 3.2
+-if _sys.version_info.major >= 3 and _sys.version_info.minor >= 2:
++if _sys.version_info.major >= 3 and _sys.version_info.minor >= 8:
++  def _logger_find_caller(stack_info=False, stacklevel=1):  # pylint: 
disable=g-wrong-blank-lines
++code, frame = _get_caller(4)
++sinfo = None
++if stack_info:
++  sinfo = '\n'.join(_traceback.format_stack())
++if code:
++  return (code.co_filename, frame.f_lineno, code.co_name, sinfo)
++else:
++  return '(unknown file)', 0, '(unknown function)', sinfo
++elif _sys.version_info.major >= 3 and _sys.version_info.minor >= 2:
+   def _logger_find_caller(stack_info=False):  # pylint: 
disable=g-wrong-blank-lines
+ code, frame = _get_caller(4)
+ sinfo = None
+-- 
+2.17.1
+
diff --git a/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb 
b/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb
index 48635a5..4aa76ba 100644
--- a/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb
+++ b/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb
@@ -9,6 +9,7 @@ SRC_URI = 
"git://github.com/tensorflow/tensorflow.git;branch=r1.13 \
file://0001-use-local-bazel-to-workaround-bazel-paralle-issue.patch 
\
file://0001-grpc-Define-gettid-only-for-glibc-2.30.patch \
file://0001-fix-compilation-error.patch \
+   file://0001-Fix-TensorFlow-on-Python-3.8-logger-issue.patch \
   "
 S = "${WORKDIR}/git"
 
diff --git a/recipes-framework/tensorflow/tensorflow_1.13.0.bb 
b/recipes-framework/tensorflow/tensorflow_1.13.0.bb
index e541895..7502f34 100644
--- a/recipes-framework/tensorflow/tensorflow_1.13.0.bb
+++ b/recipes-framework/tensorflow/tensorflow_1.13.0.bb
@@ -20,6 +20,7 @@ SRC_URI = 
"git://github.com/tensorflow/tensorflow.git;branch=r1.13 \
file://CROSSTOOL.tpl \
file://yocto_compiler_configure.bzl \
file://0001-fix-compilation-error.patch \
+   file://0001-Fix-TensorFlow-on-Python-3.8-logger-issue.patch \
   "
 
 S = "${WORKDIR}/git"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48549): https://lists.yoctoproject.org/g/yocto/message/48549
Mute This Topic: https://lists.yoctoproject.org/mt/71446733/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-tensorflow][PATCH] tensorflow: fix compilation error

[Chen Qi]

Fix the following compliation error.

  error: cannot convert 'std::nullptr_t' to 'Py_ssize_t {aka long int}' in 
initialization

This patch references: https://github.com/tensorflow/tensorflow/issues/34197

Signed-off-by: Chen Qi 
---
 .../files/0001-fix-compilation-error.patch| 58 +++
 .../tensorflow/tensorflow-native_1.13.0.bb|  1 +
 .../tensorflow/tensorflow_1.13.0.bb   |  1 +
 3 files changed, 60 insertions(+)
 create mode 100644 
recipes-framework/tensorflow/files/0001-fix-compilation-error.patch

diff --git 
a/recipes-framework/tensorflow/files/0001-fix-compilation-error.patch 
b/recipes-framework/tensorflow/files/0001-fix-compilation-error.patch
new file mode 100644
index 000..995b83b
--- /dev/null
+++ b/recipes-framework/tensorflow/files/0001-fix-compilation-error.patch
@@ -0,0 +1,58 @@
+From c1d33029372d7b4d3b5cc1d52d92c414c97ca763 Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Fri, 21 Feb 2020 11:45:04 +0800
+Subject: [PATCH] fix compilation error
+
+This fix references https://github.com/tensorflow/tensorflow/issues/34197.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chen Qi 
+---
+ tensorflow/python/eager/pywrap_tfe_src.cc   | 2 +-
+ tensorflow/python/lib/core/bfloat16.cc  | 2 +-
+ tensorflow/python/lib/core/ndarray_tensor_bridge.cc | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/tensorflow/python/eager/pywrap_tfe_src.cc 
b/tensorflow/python/eager/pywrap_tfe_src.cc
+index 9ce500bc08..6c6cb215f2 100644
+--- a/tensorflow/python/eager/pywrap_tfe_src.cc
 b/tensorflow/python/eager/pywrap_tfe_src.cc
+@@ -1216,7 +1216,7 @@ static PyTypeObject TFE_Py_Tape_Type = {
+ sizeof(TFE_Py_Tape),  /* tp_basicsize */
+ 0,/* tp_itemsize */
+ _Py_Tape_Delete,  /* tp_dealloc */
+-nullptr,  /* tp_print */
++NULL,  /* tp_print */
+ nullptr,  /* tp_getattr */
+ nullptr,  /* tp_setattr */
+ nullptr,  /* tp_reserved */
+diff --git a/tensorflow/python/lib/core/bfloat16.cc 
b/tensorflow/python/lib/core/bfloat16.cc
+index fde3a83770..9b8fa97958 100644
+--- a/tensorflow/python/lib/core/bfloat16.cc
 b/tensorflow/python/lib/core/bfloat16.cc
+@@ -317,7 +317,7 @@ PyTypeObject PyBfloat16_Type = {
+ sizeof(PyBfloat16),// tp_basicsize
+ 0, // tp_itemsize
+ nullptr,   // tp_dealloc
+-nullptr,   // tp_print
++NULL,   // tp_print
+ nullptr,   // tp_getattr
+ nullptr,   // tp_setattr
+ nullptr,   // tp_compare / tp_reserved
+diff --git a/tensorflow/python/lib/core/ndarray_tensor_bridge.cc 
b/tensorflow/python/lib/core/ndarray_tensor_bridge.cc
+index 0d5838505f..50c1f885f4 100644
+--- a/tensorflow/python/lib/core/ndarray_tensor_bridge.cc
 b/tensorflow/python/lib/core/ndarray_tensor_bridge.cc
+@@ -86,7 +86,7 @@ PyTypeObject TensorReleaserType = {
+ 0,/* tp_itemsize */
+ /* methods */
+ TensorReleaser_dealloc,  /* tp_dealloc */
+-nullptr, /* tp_print */
++NULL, /* tp_print */
+ nullptr, /* tp_getattr */
+ nullptr, /* tp_setattr */
+ nullptr, /* tp_compare */
+-- 
+2.17.1
+
diff --git a/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb 
b/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb
index fa9b04c..48635a5 100644
--- a/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb
+++ b/recipes-framework/tensorflow/tensorflow-native_1.13.0.bb
@@ -8,6 +8,7 @@ SRC_URI = 
"git://github.com/tensorflow/tensorflow.git;branch=r1.13 \
file://0001-SyntaxError-around-async-keyword-on-Python-3.7.patch \
file://0001-use-local-bazel-to-workaround-bazel-paralle-issue.patch 
\
file://0001-grpc-Define-gettid-only-for-glibc-2.30.patch \
+   file://0001-fix-compilation-error.patch \
   "
 S = "${WORKDIR}/git"
 
diff --git a/recipes-framework/tensorflow/tensorflow_1.13.0.bb 
b/recipes-framework/tensorflow/tensorflow_1.13.0.bb
index 223044f..e541895 100644
--- a/recipes-framework/tensorflow/tensorflow_1.13.0.bb
+++ b/recipes-framework/tensorflow/tensorflow_1.13.0.bb
@@ -19,6 +19,7 @@ SRC_URI = 
"git://github.com/tensorflow/tensorflow.git;branch=r1.13 \
file://BUILD.yocto_compiler \
file://CROSSTOOL.tpl \
file://yocto_compiler_configure.bzl \
+   file://0001-fix-compilation-error.patch \
   "
 
 S = 

[yocto] [meta-tensorflow][PATCH 2/2] layer.conf: depend on meta-python2

[Chen Qi]

bazel-native needs python2-native, so depend on meta-python2.
Also update the README file.

Signed-off-by: Chen Qi 
---
 README.md   | 4 
 conf/layer.conf | 1 +
 2 files changed, 5 insertions(+)

diff --git a/README.md b/README.md
index dbd349e..a04946a 100644
--- a/README.md
+++ b/README.md
@@ -33,6 +33,10 @@ URI: git://github.com/openembedded/meta-openembedded.git
 layers: meta-python, meta-oe
 branch: master
 revision: HEAD
+
+URI: git://git.openembedded.org/meta-python2
+branch: master
+revision: HEAD
 ```
 ### 2. Based on Wind River Linux
 Wind River Linux (CI/CD branch)
diff --git a/conf/layer.conf b/conf/layer.conf
index a1ad84d..0da7b2e 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -17,6 +17,7 @@ LAYERDEPENDS_meta-tensorflow = " \
 core \
 meta-python \
 openembedded-layer \
+meta-python2 \
 "
 
 LAYER_PATH_meta-tensorflow = "${LAYERDIR}"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48546): https://lists.yoctoproject.org/g/yocto/message/48546
Mute This Topic: https://lists.yoctoproject.org/mt/71443349/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-tensorflow][PATCH 1/2] bazel-native: inherit pythonnative to fix do_compile error

[Chen Qi]

The compilation process needs python (python2) to be there, so
fix it by making bazel-native inherit pythonnative.

Signed-off-by: Chen Qi 
---
 recipes-devtools/bazel/bazel-native_0.21.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-devtools/bazel/bazel-native_0.21.0.bb 
b/recipes-devtools/bazel/bazel-native_0.21.0.bb
index 3395c2f..03c3e8d 100644
--- a/recipes-devtools/bazel/bazel-native_0.21.0.bb
+++ b/recipes-devtools/bazel/bazel-native_0.21.0.bb
@@ -9,7 +9,7 @@ SRC_URI = 
"https://github.com/bazelbuild/bazel/releases/download/${PV}/bazel-${P
file://0001-HttpDownloader-save-download-tarball-to-distdir.patch \
 "
 
-inherit native
+inherit native pythonnative
 
 INHIBIT_SYSROOT_STRIP = "1"
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48547): https://lists.yoctoproject.org/g/yocto/message/48547
Mute This Topic: https://lists.yoctoproject.org/mt/71443350/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

[Sangeeta Jain]

From: akuster 
Sent: Friday, 21 February, 2020 7:01 AM
To: Richard Purdie ; Jain, Sangeeta 
; Mittal, Anuj ; akuster808 
; yocto@lists.yoctoproject.org
Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv 
; Yeoh, Ee Peng ; Chan, Aaron 
Chun Yew ; sjolley.yp...@gmail.com; 
Tummalapalli, Vineela 
Subject: Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)


On 2/20/20 2:44 PM, Richard Purdie wrote:

I discussed this quickly in bug triage today with Armin. We agreed

that:



* The openssh bug is minor and doesn't affect release

* Anuj resolved one of the bugs as being execution error so again it

doesn't affect release

* The bash issue does affect release



We're proposing we build and release an rc3 with the bash CVE reverted.

This would also include the bitbake memory optimisation during parsing

which merged.



We wouldn't rerun the manual QA for rc3, just check the automated test

results.





Does anyone have any objection to that? If not, QA should see an rc3

email but we're just expecting to check the test results if that works

for everyone?
Works for me.


Sound good from QA perspective. Verifying automated test results and ptest 
results should be good.






Vineela: Not sure how this affects release process, we'll just have to

figure that out.

List them as Known issues?
Release should be done on rc3. Status of bugs can be updated in 
‘header-intel.txt’. Just my thoughts!


- armin






Cheers,



Richard







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48545): https://lists.yoctoproject.org/g/yocto/message/48545
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

[Armin Kuster]

On 2/20/20 2:44 PM, Richard Purdie wrote:
> I discussed this quickly in bug triage today with Armin. We agreed
> that:
>
> * The openssh bug is minor and doesn't affect release
> * Anuj resolved one of the bugs as being execution error so again it
> doesn't affect release
> * The bash issue does affect release
>
> We're proposing we build and release an rc3 with the bash CVE reverted.
> This would also include the bitbake memory optimisation during parsing
> which merged.
>
> We wouldn't rerun the manual QA for rc3, just check the automated test
> results.
>
> Does anyone have any objection to that? If not, QA should see an rc3
> email but we're just expecting to check the test results if that works
> for everyone?
Works for me.
>
> Vineela: Not sure how this affects release process, we'll just have to
> figure that out.

List them as Known issues?

- armin
>
> Cheers,
>
> Richard
>
>
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48544): https://lists.yoctoproject.org/g/yocto/message/48544
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

[Richard Purdie]

I discussed this quickly in bug triage today with Armin. We agreed
that:

* The openssh bug is minor and doesn't affect release
* Anuj resolved one of the bugs as being execution error so again it
doesn't affect release
* The bash issue does affect release

We're proposing we build and release an rc3 with the bash CVE reverted.
This would also include the bitbake memory optimisation during parsing
which merged.

We wouldn't rerun the manual QA for rc3, just check the automated test
results.

Does anyone have any objection to that? If not, QA should see an rc3
email but we're just expecting to check the test results if that works
for everyone?

Vineela: Not sure how this affects release process, we'll just have to
figure that out.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48543): https://lists.yoctoproject.org/g/yocto/message/48543
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Debugging gdb built by Yocto

[Khem Raj via Lists.Yoctoproject.Org]

On Thu, 2020-02-20 at 08:52 -0500, Patrick Doyle wrote:
> On Wed, Feb 19, 2020 at 5:19 PM Richard Purdie
>  wrote:
> > On Tue, 2020-02-18 at 11:26 -0500, Patrick Doyle wrote:
> > > Does anybody have any tips or tricks for how I might debug the
> > > (cross-canadian) gdb built by Yocto's SDK?
> > Do you perhaps want gdb-cross-mipsel ?
> > 
> > cross-canadian is designed to be run as part of the SDK.
> Thank you.  That is, indeed, what I want.  It demonstrates the same
> problem, and I can debug it.
> 
> Aside... it's quite a mind bending experience to debug gdb with gdb
> :-)
> 
> Just imagine...
> 
> $ gdb gdb-cross-mipsel
> (gdb) break main
> (gdb) run
> (gdb)
> 
> That last "(gdb)" prompt is from the gdb I'm debugging :-)
> 
> Also aside... and totally off topic, except that I'm sure some might
> be wondering why I feel the need to debug gdb...
> 
> I am trying to understand why I can't get stack traces from cores
> file
> on a mipsel system.  At the moment (after strategic additions of
> breakpoints, printf statements, and more breakpoints, and lots of
> internet combing), I am chasing down a rabbit hole related to the
> facts that the MIPS build uses/produces PIE code (Position
> Independent
> Executables, which is somehow different than Position Independent
> Code), a new ELF tag (MIPS_RLD_MAP_REL) was added 5 years ago to
> binutils, gdb looks for that tag, but the musl dynamic loader is not
> aware of it.  I don't know if this is the root cause of my problem or
> just (another) rabbit hole.  If anybody has any suggestions, I'm all
> ears.

You must be on to something here, since musl does not do anything with
MIPS_RLD_MAP*, does this all work well with glibc/mips in same settings
?

> 
> --wpd
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48542): https://lists.yoctoproject.org/g/yocto/message/48542
Mute This Topic: https://lists.yoctoproject.org/mt/71406927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [psplash][PATCH 1/1] psplash-fb: Avoid racing issues on reading fb0

[Khem Raj]

On 2/20/20 9:58 AM, Andrei Gherzan wrote:

Hi,

On Fri, Feb 14, 2020 at 7:32 AM Khem Raj > wrote:


On 2/13/20 2:30 AM, Andrei Gherzan wrote:
 > When starting psplash as early as possible in the boot process,
the fb
 > device node might not be ready. This patch adds a loop on reading the
 > fb0 device with a timeout of 5 seconds.
 >
 > Signed-off-by: Andrei Gherzan mailto:and...@gherzan.ro>>
 > ---
 >   psplash-fb.c | 5 -
 >   1 file changed, 4 insertions(+), 1 deletion(-)
 >
 > diff --git a/psplash-fb.c b/psplash-fb.c
 > index 6603572..6700a3b 100644
 > --- a/psplash-fb.c
 > +++ b/psplash-fb.c
 > @@ -137,6 +137,7 @@ psplash_fb_new (int angle, int fbdev_id)
 >     struct fb_fix_screeninfo fb_fix;
 >     int                      off;
 >     char                     fbdev[9] = "/dev/fb0";
 > +  int retries = 0;
 >
 >     PSplashFB *fb = NULL;
 >
 > @@ -156,7 +157,9 @@ psplash_fb_new (int angle, int fbdev_id)
 >
 >     fb->fd = -1;
 >
 > -  if ((fb->fd = open (fbdev, O_RDWR)) < 0)
 > +  while ((fb->fd = open(fbdev, O_RDWR)) < 0 && retries++ <= 100)
 > +       usleep(5);
 > +  if (fb->fd < 0)

i wonder if there should be a different way to ensure this dependency
perhaps sd_notify for systemd or udev notification maybe ..


That makes sense. The only issue is that in my use-case, initramfs 
doesn't have systemd. And usually, you will be wanting to run a splash 
way before any init system. What is your proposal with udev 
notifications? Can you expand that?




something like 
https://www.tecmint.com/udev-for-device-detection-management-in-linux/




Regards,
Andrei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48541): https://lists.yoctoproject.org/g/yocto/message/48541
Mute This Topic: https://lists.yoctoproject.org/mt/71238022/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] How to setup debug environment for image running in target board? #toolchain #yocto

[amern2k16]

I'm working with NXP iMX8QXPMEK evaluation board.  I downloaded bsp release 
L4.19.35_1.1.0_MX8QXP from following site:
https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/embedded-linux-for-i.mx-applications-processors:IMXLINUX?tab=Design_Tools_Tab
This bsp release is for Yocto Project 2.7 (Warrior)
I built yocto project for this bsp release.  I copied built image into sd card 
and then booted NXP board from sd card.  I need to step through USB Host 
Subsystem source code running in embedded linux kernel?
There is a serial connection between my NXP evaluation board and my PC.  
Micro-USB Debug port in NXP board is connected to USB port in my PC.  How do I 
setup debugging environment so I can see source code and symbols running in my 
NXP board?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48539): https://lists.yoctoproject.org/g/yocto/message/48539
Mute This Topic: https://lists.yoctoproject.org/mt/71432780/21656
Mute #toolchain: 
https://lists.yoctoproject.org/mk?hashtag=toolchain=6691583
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Lots of basehash related errors

[Quentin Schulz]

Hi Dmitri,

On Thu, Feb 20, 2020 at 08:02:57AM -0800, Dmitri Toubelis wrote:
> Hi,
> 
> I'm migrating from yocto morty to zeus and I'm receiving a whole lot of 
> errors like this:
> 
> > 
> > ERROR: When reparsing
> > /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_wic,
> > the basehash value changed from
> > 8dd96e09d0b7defa552e586e626933ca37ace5180918ea65addbfcb6c1247b1c to
> > e38fae3f400b3e3de114fcd668d46a1f7c3eec436ec72962e78df906714a6fb0. The
> > metadata is not deterministic and this needs to be fixed.
> > ERROR: The following commands may help:
> > ERROR: $ bitbake loopedge-std -cdo_image_wic -Snone
> > ERROR: Then:
> > ERROR: $ bitbake loopedge-std -cdo_image_wic -Sprintdiff
> > 
> > ERROR: When reparsing
> > /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_ext4,
> > the basehash value changed from
> > a8209ab35324ce59bb193b80871c12c492f69f42fd97b03801165bd4a12670f6 to
> > 1ab2d25ef217fe87b4cce1106d122acd4286043b04dcd74d98df30a01aa6a0b9. The
> > metadata is not deterministic and this needs to be fixed.
> > ERROR: The following commands may help:
> > ERROR: $ bitbake loopedge-std -cdo_image_ext4 -Snone
> > ERROR: Then:
> > ERROR: $ bitbake loopedge-std -cdo_image_ext4 -Sprintdiff
> > 
> > ERROR: When reparsing
> > /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_tar,
> > the basehash value changed from
> > c5ab62cac832e502a338d59124efc690e66560a4e877bc4ba3487c3a734c2497 to
> > bb7ca72863614cb5c9915eb502259b1ffa8b98992f7ad3280d1e049a1824b930. The
> > metadata is not deterministic and this needs to be fixed.
> > ERROR: The following commands may help:
> > ERROR: $ bitbake loopedge-std -cdo_image_tar -Snone
> > ERROR: Then:
> > ERROR: $ bitbake loopedge-std -cdo_image_tar -Sprintdiff
> > 
> 
> I search around for answers and there are here are reasons and solutions for 
> this that I found:
> - to make sure any date related variables are excluded from basehash via 
> `do_task_name[vardepsexclude] = "DATE DATETIME"`
> - clears state cache with `bitbake image -c cleansstate`
> - delete tmp directory and build from scratch
> 
> Here is my observation and interpretation:
> - this messages occur when running with pristine build directory, i.e. it 
> only contains 2 files in `conf` dir - `local.conf` and `bblatyers.conf`, so I 
> can rule out contamination from a previous run.
> - same messages reapeat over and over totalling ~900 errors at the end of the 
> run
> - I have few custom classes and I removed them from the image to rule out 
> contamination from my own code.
> - Tasks that give this error are coming from image.bbclass from poky and none 
> of them have been altered in any way.
> - The image build runs through the end but because bitbake exits with 
> non-zero exit code it breaks lots of our tools, so just ignoring them is a 
> bad option.
> 

I've had this before with a vendor layer. The culprit was the distro
having some weird USERADDEXTENSION messing up with everything.

How we found out what it was was by uncommenting:
https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/siggen.py#n187
187 to 189.

Then you go to tmp/stamps/...your-recipe.../ and you'll have more
sigdata in there. Use bitbake-diffsigs between the both and you'll find
which variable messes up with your build.

Hope this helps, good luck!

Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48538): https://lists.yoctoproject.org/g/yocto/message/48538
Mute This Topic: https://lists.yoctoproject.org/mt/71431201/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Lots of basehash related errors

[Alexander Kanavin]

It's an issue with a recipe in your custom layer. If you can show the
layer, we may be able to help.

Are you sure a current timestamp isn't sneaked into the build by
something in that layer?

Alex

On Thu, 20 Feb 2020 at 17:03, Dmitri Toubelis <
dmitri.toube...@litmusautomation.com> wrote:

> Hi,
>
> I'm migrating from yocto morty to zeus and I'm receiving a whole lot of
> errors like this:
>
> ERROR: When reparsing
> /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_wic,
> the basehash value changed from
> 8dd96e09d0b7defa552e586e626933ca37ace5180918ea65addbfcb6c1247b1c to
> e38fae3f400b3e3de114fcd668d46a1f7c3eec436ec72962e78df906714a6fb0. The
> metadata is not deterministic and this needs to be fixed.
> ERROR: The following commands may help:
> ERROR: $ bitbake loopedge-std -cdo_image_wic -Snone
> ERROR: Then:
> ERROR: $ bitbake loopedge-std -cdo_image_wic -Sprintdiff
>
> ERROR: When reparsing
> /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_ext4,
> the basehash value changed from
> a8209ab35324ce59bb193b80871c12c492f69f42fd97b03801165bd4a12670f6 to
> 1ab2d25ef217fe87b4cce1106d122acd4286043b04dcd74d98df30a01aa6a0b9. The
> metadata is not deterministic and this needs to be fixed.
> ERROR: The following commands may help:
> ERROR: $ bitbake loopedge-std -cdo_image_ext4 -Snone
> ERROR: Then:
> ERROR: $ bitbake loopedge-std -cdo_image_ext4 -Sprintdiff
>
> ERROR: When reparsing
> /srv/yocto/poky/meta-loopedge/meta-loopedge-dist/recipes-core/images/loopedge-std.bb:do_image_tar,
> the basehash value changed from
> c5ab62cac832e502a338d59124efc690e66560a4e877bc4ba3487c3a734c2497 to
> bb7ca72863614cb5c9915eb502259b1ffa8b98992f7ad3280d1e049a1824b930. The
> metadata is not deterministic and this needs to be fixed.
> ERROR: The following commands may help:
> ERROR: $ bitbake loopedge-std -cdo_image_tar -Snone
> ERROR: Then:
> ERROR: $ bitbake loopedge-std -cdo_image_tar -Sprintdiff
>
> I search around for answers and there are here are reasons and solutions
> for this that I found:
> - to make sure any date related variables are excluded from basehash via
> `do_task_name[vardepsexclude] = "DATE DATETIME"`
> - clears state cache with `bitbake image -c cleansstate`
> - delete tmp directory and build from scratch
>
> Here is my observation and interpretation:
> - this messages occur when running with pristine build directory, i.e. it
> only contains 2 files in `conf` dir - `local.conf` and `bblatyers.conf`, so
> I can rule out contamination from a previous run.
> - same messages reapeat over and over totalling ~900 errors at the end of
> the run
> - I have few custom classes and I removed them from the image to rule out
> contamination from my own code.
> - Tasks that give this error are coming from image.bbclass from poky and
> none of them have been altered in any way.
> - The image build runs through the end but because bitbake exits with
> non-zero exit code it breaks lots of our tools, so just ignoring them is a
> bad option.
>
> So, am I doing something obviously wrong? It is a known issue in zeus? And
> if so is there a known workaround?
>
> Thanks in advance.
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48537): https://lists.yoctoproject.org/g/yocto/message/48537
Mute This Topic: https://lists.yoctoproject.org/mt/71431201/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Bitbake returning non-zero due to sstate errors

[Paul Barker]

On Thu, 20 Feb 2020 at 12:04, Richard Purdie
 wrote:
>
> On Thu, 2020-02-20 at 11:59 +, Paul Barker wrote:
> > I'm now looking into this...
> >
> > In sstate_checkhashes() we mark sstate as available if
> > fetcher.checkstatus() succeeds. Then at a later point
> > sstate_setscene() calls sstate_installpkg() calls pstaging_fetch()
> > calls fetcher.download() to actually get the sstate artifact. If the
> > artifact is removed from the mirror between these two accesses (due
> > to an sstate mirror clean up running in parallel to a build), or if
> > there is an intermittent download failure we could see checkstatus()
> > succeed then download() fail.
> >
> > I don't think we should ignore all setscene errors but in the
> > specific case where it's the download step that fails I think that
> > should be a warning. Or it could be an error by default with a
> > variable we can set to turn it into a warning. Does that sound
> > reasonable? If so I'll work up a patch.
>
> Thinking about the code, I'm not sure how you're generically going to
> tell the difference between a setscene task that fails as the file
> disappeared compared to a setscene failure with another real error? :/
>
> We could make all failed setscene tasks warnings but I think that
> buries actual real errors.
>
> This is probably why I've not changed the code before now.
>
> Special exit code values? :/
>
> I'm open to proposals.
>
> I know we could put in some configuration option but in general I hate
> these as it just means more test matrix combinations and more ways for
> people to see different behaviours. They have a time/place but I'm not
> sure its here.

I agree - I really don't want to have to add additional complexity
here. But I do think we need to fix this in some way, others are
affected by this as can be seen from previous discussions. And in the
case of a public sstate mirror we can't control when users decide to
run builds, there will always be the chance of a user running a build
on an old commit while old sstate artifacts are cleaned or starting a
build just as the mirror is taken offline for some maintenance.

I think we might be able to make this work if we can avoid adding any
new conditional logic to the fetcher itself. I can see that almost
every call to logger.error() is followed by raising an error - perhaps
we could rework the code to include all the relevant info in the
raised error object and allow higher level code to catch the exception
and decide what to do with it. Because once logger.error() is called,
knotty counts an error and bitbake will exit non-zero even if the
error is safely handled. Once the fetcher simply raises exceptions in
the case of failed downloads we could handle this neatly in
sstate.bbclass. Would that be a viable way forward? Or would that
break the other fetcher use cases?

Thanks,
Paul
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48535): https://lists.yoctoproject.org/g/yocto/message/48535
Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto-dev standard/base][PATCH] tipc: fix successful connect() but timed out

[Bruce Ashfield]

merged

Bruce

On Tue, Feb 18, 2020 at 3:03 AM  wrote:
>
> From: Tuong Lien 
>
> In commit 9546a0b7ce00 ("tipc: fix wrong connect() return code"), we
> fixed the issue with the 'connect()' that returns zero even though the
> connecting has failed by waiting for the connection to be 'ESTABLISHED'
> really. However, the approach has one drawback in conjunction with our
> 'lightweight' connection setup mechanism that the following scenario
> can happen:
>
>   (server)(client)
>
>+- accept()|  | wait_for_conn()
>|  |  |connect() ---+
>|  |<---[SYN]-| > sleeping
>|  |  *CONNECTING   |
>|->*ESTABLISHED   | |
>   |[ACK]>*ESTABLISHED  > wakeup()
> send()|[DATA]--->|\> wakeup()
> send()|[DATA]--->| |   > wakeup()
>   .   .  .   . |-> recvq   .
>   .   .  .   . |   .
> send()|[DATA]--->|/> wakeup()
>close()|[FIN]>*DISCONNECTING|
>   *DISCONNECTING | |
>   |  ~~> schedule()
>| wait again
>.
>.
>| ETIMEDOUT
>
> Upon the receipt of the server 'ACK', the client becomes 'ESTABLISHED'
> and the 'wait_for_conn()' process is woken up but not run. Meanwhile,
> the server starts to send a number of data following by a 'close()'
> shortly without waiting any response from the client, which then forces
> the client socket to be 'DISCONNECTING' immediately. When the wait
> process is switched to be running, it continues to wait until the timer
> expires because of the unexpected socket state. The client 'connect()'
> will finally get ‘-ETIMEDOUT’ and force to release the socket whereas
> there remains the messages in its receive queue.
>
> Obviously the issue would not happen if the server had some delay prior
> to its 'close()' (or the number of 'DATA' messages is large enough),
> but any kind of delay would make the connection setup/shutdown "heavy".
> We solve this by simply allowing the 'connect()' returns zero in this
> particular case. The socket is already 'DISCONNECTING', so any further
> write will get '-EPIPE' but the socket is still able to read the
> messages existing in its receive queue.
>
> Note: This solution doesn't break the previous one as it deals with a
> different situation that the socket state is 'DISCONNECTING' but has no
> error (i.e. sk->sk_err = 0).
>
> Fixes: 9546a0b7ce00 ("tipc: fix wrong connect() return code")
> Acked-by: Ying Xue 
> Acked-by: Jon Maloy 
> Signed-off-by: Tuong Lien 
> Signed-off-by: David S. Miller 
> Signed-off-by: He Zhe 
> ---
> This patch is from v5.6-rc2.
> The wrong one is from v5.5.
>
>  net/tipc/socket.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/net/tipc/socket.c b/net/tipc/socket.c
> index f9b4fb9..693e890 100644
> --- a/net/tipc/socket.c
> +++ b/net/tipc/socket.c
> @@ -2441,6 +2441,8 @@ static int tipc_wait_for_connect(struct socket *sock, 
> long *timeo_p)
> return -ETIMEDOUT;
> if (signal_pending(current))
> return sock_intr_errno(*timeo_p);
> +   if (sk->sk_state == TIPC_DISCONNECTING)
> +   break;
>
> add_wait_queue(sk_sleep(sk), );
> done = sk_wait_event(sk, timeo_p, tipc_sk_connected(sk),
> --
> 2.7.4
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8389): 
https://lists.yoctoproject.org/g/linux-yocto/message/8389
Mute This Topic: https://lists.yoctoproject.org/mt/71406921/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Debugging gdb built by Yocto

[Patrick Doyle]

On Wed, Feb 19, 2020 at 5:19 PM Richard Purdie
 wrote:
> On Tue, 2020-02-18 at 11:26 -0500, Patrick Doyle wrote:
> > Does anybody have any tips or tricks for how I might debug the
> > (cross-canadian) gdb built by Yocto's SDK?
> Do you perhaps want gdb-cross-mipsel ?
>
> cross-canadian is designed to be run as part of the SDK.
Thank you.  That is, indeed, what I want.  It demonstrates the same
problem, and I can debug it.

Aside... it's quite a mind bending experience to debug gdb with gdb :-)

Just imagine...

$ gdb gdb-cross-mipsel
(gdb) break main
(gdb) run
(gdb)

That last "(gdb)" prompt is from the gdb I'm debugging :-)

Also aside... and totally off topic, except that I'm sure some might
be wondering why I feel the need to debug gdb...

I am trying to understand why I can't get stack traces from cores file
on a mipsel system.  At the moment (after strategic additions of
breakpoints, printf statements, and more breakpoints, and lots of
internet combing), I am chasing down a rabbit hole related to the
facts that the MIPS build uses/produces PIE code (Position Independent
Executables, which is somehow different than Position Independent
Code), a new ELF tag (MIPS_RLD_MAP_REL) was added 5 years ago to
binutils, gdb looks for that tag, but the musl dynamic loader is not
aware of it.  I don't know if this is the root cause of my problem or
just (another) rabbit hole.  If anybody has any suggestions, I'm all
ears.

--wpd
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48534): https://lists.yoctoproject.org/g/yocto/message/48534
Mute This Topic: https://lists.yoctoproject.org/mt/71406927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Bitbake returning non-zero due to sstate errors

[Martin Jansa]

On Thu, Feb 20, 2020 at 11:26:54AM +, Paul Barker wrote:
> In my new CI setup I'm using an sstate mirror which seems to have some
> occasional download issues. This results in the setscene task failing.
> For example:
> 
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> file://fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz
> anywhere. The paths that were searched were:
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: No suitable staging package found
> ERROR: Logfile of failure stored in:
> /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-r0/temp/log.do_package_write_ipk_setscene.10524
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk_setscene: Failed
> WARNING: Setscene task
> (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> failed with exit code '1' - real task will be run instead
> 
> As indicated in the final warning message there the real tasks run
> since no sstate artifact is available. These tasks succeed:
> 
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk: Succeeded
> 
> The result is a successful build of the desired images. However, the
> build is marked as a failure due to those sstate errors:
> 
> Summary: There were 11 ERROR messages shown, returning a non-zero exit code.
> 
> Is this the expected behaviour? The final images are built correctly.
> I can't see any simple way to mask those setscene errors but I might
> be missing something.
> 
> The full log can be seen at
> https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> I'm on the zeus branch here, I'll try to re-test on master later if I
> can.

See this previous discussion which includes patches for bitbake and
oe-core to change them to warnings:
https://marc.info/?l=openembedded-core=150403687120408=2

Because it was rejected I'm parsing the bitbake output to see if all
ERROR: messages were only about setscene tasks as mentioned in the same
thread much later:
https://marc.info/?l=openembedded-core=157504616302317=4


signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48533): https://lists.yoctoproject.org/g/yocto/message/48533
Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Bitbake returning non-zero due to sstate errors

[Richard Purdie]

On Thu, 2020-02-20 at 11:59 +, Paul Barker wrote:
> I'm now looking into this...
> 
> In sstate_checkhashes() we mark sstate as available if
> fetcher.checkstatus() succeeds. Then at a later point
> sstate_setscene() calls sstate_installpkg() calls pstaging_fetch()
> calls fetcher.download() to actually get the sstate artifact. If the
> artifact is removed from the mirror between these two accesses (due
> to an sstate mirror clean up running in parallel to a build), or if
> there is an intermittent download failure we could see checkstatus()
> succeed then download() fail.
> 
> I don't think we should ignore all setscene errors but in the
> specific case where it's the download step that fails I think that
> should be a warning. Or it could be an error by default with a
> variable we can set to turn it into a warning. Does that sound
> reasonable? If so I'll work up a patch.

Thinking about the code, I'm not sure how you're generically going to
tell the difference between a setscene task that fails as the file
disappeared compared to a setscene failure with another real error? :/

We could make all failed setscene tasks warnings but I think that
buries actual real errors.

This is probably why I've not changed the code before now.

Special exit code values? :/

I'm open to proposals.

I know we could put in some configuration option but in general I hate
these as it just means more test matrix combinations and more ways for
people to see different behaviours. They have a time/place but I'm not
sure its here.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48532): https://lists.yoctoproject.org/g/yocto/message/48532
Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

[Mikko Rapeli]

Hi,

On Thu, Feb 20, 2020 at 12:55:43PM +0100, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 08:14:04AM +, mikko.rap...@bmw.de wrote:
> > On Wed, Feb 19, 2020 at 10:57:41PM +0100, Martin Jansa wrote:
> > > > DEPENDS_class-target += "systemd"
> > > 
> > > You surely meant
> > > DEPENDS_append_class-target = " systemd"
> > > here
> > 
> > Yes, quite likely. Tough reason why += doesn't work is a mystery to me :)
> > 
> > I hack things until "bitbake -e" shows the right things for the recipes.
> 
> I agree it's a bit confusing at first (I was doing the same long time
> ago, before bitbake -e was even showing the history of evaluation), but
> everybody who uses bitbake often should learn this simple difference:
> 
> FOO_append_override = " bar"
>   is "conditional" append, so it will append "bar" only when "override" is
> being used
> 
> FOO_override += "bar"
>   always appends to "FOO_override" and then it overrides whole "FOO" variable

Thanks for this explanation!

> There are other more subtle differences like "+=" adds leading space,
> _append doesn't and _append is processed later (which is important when
> appending to variable set with ?=), but the above difference is a must
> to know.
> 
> Also
> FOO_append += "bar"
> is just silly way how to add leading space to the value, one should
> always use
> FOO_append = " bar"
> when appending to space separated list (like DEPENDS).

Hmm. I would rather see FOO_append += "bar" being used every time when
spaces are expected. It's way too easy to forget the extra space which causes
annoying and hard to debug issues, and is often missed in reviews too.

Cheers,

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48531): https://lists.yoctoproject.org/g/yocto/message/48531
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Bitbake returning non-zero due to sstate errors

[Paul Barker]

On Thu, 20 Feb 2020 at 11:36, Richard Purdie
 wrote:
>
> On Thu, 2020-02-20 at 11:26 +, Paul Barker wrote:
> > In my new CI setup I'm using an sstate mirror which seems to have
> > some
> > occasional download issues. This results in the setscene task
> > failing.
> > For example:
> >
> > ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> > do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> > file://fd/sstate:qt3d:armv7at2hf-neon-linux-
> > gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> > neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> > 74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-
> > neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> > neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> > 74_package_write_ipk.tgz
> > anywhere. The paths that were searched were:
> > /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> > /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> > ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> > do_package_write_ipk_setscene: No suitable staging package found
> > ERROR: Logfile of failure stored in:
> > /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-
> > linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-
> > r0/temp/log.do_package_write_ipk_setscene.10524
> > NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> > do_package_write_ipk_setscene: Failed
> > WARNING: Setscene task
> > (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-
> > qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> > failed with exit code '1' - real task will be run instead
> >
> > As indicated in the final warning message there the real tasks run
> > since no sstate artifact is available. These tasks succeed:
> >
> > NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> > do_package_write_ipk: Succeeded
> >
> > The result is a successful build of the desired images. However, the
> > build is marked as a failure due to those sstate errors:
> >
> > Summary: There were 11 ERROR messages shown, returning a non-zero
> > exit code.
> >
> > Is this the expected behaviour? The final images are built correctly.
> > I can't see any simple way to mask those setscene errors but I might
> > be missing something.
> >
> > The full log can be seen at
> > https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> > I'm on the zeus branch here, I'll try to re-test on master later if I
> > can.
>
> We've discussed this before and it can be argued either way.
>
> Personally, I worry about why artefacts "disappear" and this is why its
> an error, files should not be disappearing part way through a build.
>
> From a bitbake perspective, a task really did fail and task failures
> are errors. The fact it was able to recover is a bonus.
>
> Perhaps it should be a warning now we have levels of warnings that are
> meaningful. Previously we threw so many, this would have been one more
> lost amongst many. I know many people don't like the behaviour.

I'm now looking into this...

In sstate_checkhashes() we mark sstate as available if
fetcher.checkstatus() succeeds. Then at a later point
sstate_setscene() calls sstate_installpkg() calls pstaging_fetch()
calls fetcher.download() to actually get the sstate artifact. If the
artifact is removed from the mirror between these two accesses (due to
an sstate mirror clean up running in parallel to a build), or if there
is an intermittent download failure we could see checkstatus() succeed
then download() fail.

I don't think we should ignore all setscene errors but in the specific
case where it's the download step that fails I think that should be a
warning. Or it could be an error by default with a variable we can set
to turn it into a warning. Does that sound reasonable? If so I'll work
up a patch.

Thanks,
Paul
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48530): https://lists.yoctoproject.org/g/yocto/message/48530
Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

[Martin Jansa]

On Thu, Feb 20, 2020 at 08:14:04AM +, mikko.rap...@bmw.de wrote:
> On Wed, Feb 19, 2020 at 10:57:41PM +0100, Martin Jansa wrote:
> > > DEPENDS_class-target += "systemd"
> > 
> > You surely meant
> > DEPENDS_append_class-target = " systemd"
> > here
> 
> Yes, quite likely. Tough reason why += doesn't work is a mystery to me :)
> 
> I hack things until "bitbake -e" shows the right things for the recipes.

I agree it's a bit confusing at first (I was doing the same long time
ago, before bitbake -e was even showing the history of evaluation), but
everybody who uses bitbake often should learn this simple difference:

FOO_append_override = " bar"
  is "conditional" append, so it will append "bar" only when "override" is
being used

FOO_override += "bar"
  always appends to "FOO_override" and then it overrides whole "FOO" variable

There are other more subtle differences like "+=" adds leading space,
_append doesn't and _append is processed later (which is important when
appending to variable set with ?=), but the above difference is a must
to know.

Also
FOO_append += "bar"
is just silly way how to add leading space to the value, one should
always use
FOO_append = " bar"
when appending to space separated list (like DEPENDS).

Cheers,

> -Mikko
> 
> > On Wed, Feb 19, 2020 at 10:48 PM Mikko Rapeli  wrote:
> > 
> > > Hi,
> > >
> > > On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> > > > Hello,
> > > >
> > > > I have a recipe that builds a library. The recipe specifies an
> > > additional package "${PN}-systemd" along with other systemd related
> > > variables and finally it instructs that the package should be built with
> > > "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended
> > > this recipe to nativesdk because I need this library on it. When trying to
> > > build the corresponding nativesdk package, the build fails at the
> > > configuration step (i.e. "do_configure") claiming it cannot find the
> > > package systemd.
> > > >
> > > > Is there a way I can install the -already-generated libraries into my
> > > SDK (potentially via the corresponding nativesdk recipe) without having to
> > > rebuild the package? Or do I need to somehow include such systemd package
> > > in my sdk (which I don't think I need at all)?
> > > >
> > > > Any hints and pointers as to were to look at are very well appreciated.
> > > > Thanks.
> > >
> > > Make the systemd dependency for target only, e.g. DEPENDS_class-target +=
> > > "systemd"
> > > etc.
> > >
> > > There may be relevant use cases to build some of systemd components or
> > > tools
> > > to native or nativesdk targets too. In that case add BBCLASSEXTEND +=
> > > "nativesdk" etc
> > > in a bbappend to systemd.
> > >
> > > Hope this helps,
> > >
> > > -Mikko
> > >


signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48529): https://lists.yoctoproject.org/g/yocto/message/48529
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Bitbake returning non-zero due to sstate errors

[Richard Purdie]

On Thu, 2020-02-20 at 11:26 +, Paul Barker wrote:
> In my new CI setup I'm using an sstate mirror which seems to have
> some
> occasional download issues. This results in the setscene task
> failing.
> For example:
> 
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> file://fd/sstate:qt3d:armv7at2hf-neon-linux-
> gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> 74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-
> neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> 74_package_write_ipk.tgz
> anywhere. The paths that were searched were:
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: No suitable staging package found
> ERROR: Logfile of failure stored in:
> /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-
> linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-
> r0/temp/log.do_package_write_ipk_setscene.10524
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk_setscene: Failed
> WARNING: Setscene task
> (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-
> qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> failed with exit code '1' - real task will be run instead
> 
> As indicated in the final warning message there the real tasks run
> since no sstate artifact is available. These tasks succeed:
> 
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk: Succeeded
> 
> The result is a successful build of the desired images. However, the
> build is marked as a failure due to those sstate errors:
> 
> Summary: There were 11 ERROR messages shown, returning a non-zero
> exit code.
> 
> Is this the expected behaviour? The final images are built correctly.
> I can't see any simple way to mask those setscene errors but I might
> be missing something.
> 
> The full log can be seen at
> https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> I'm on the zeus branch here, I'll try to re-test on master later if I
> can.

We've discussed this before and it can be argued either way.

Personally, I worry about why artefacts "disappear" and this is why its
an error, files should not be disappearing part way through a build.

>From a bitbake perspective, a task really did fail and task failures
are errors. The fact it was able to recover is a bonus.

Perhaps it should be a warning now we have levels of warnings that are
meaningful. Previously we threw so many, this would have been one more
lost amongst many. I know many people don't like the behaviour.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48528): https://lists.yoctoproject.org/g/yocto/message/48528
Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Bitbake returning non-zero due to sstate errors

[Paul Barker]

In my new CI setup I'm using an sstate mirror which seems to have some
occasional download issues. This results in the setscene task failing.
For example:

ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
do_package_write_ipk_setscene: Fetcher failure: Unable to find file
file://fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz
anywhere. The paths that were searched were:
/builds/SanCloudLtd/sancloud-arago/build/sstate-cache
/builds/SanCloudLtd/sancloud-arago/build/sstate-cache
ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
do_package_write_ipk_setscene: No suitable staging package found
ERROR: Logfile of failure stored in:
/builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-r0/temp/log.do_package_write_ipk_setscene.10524
NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
do_package_write_ipk_setscene: Failed
WARNING: Setscene task
(/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
failed with exit code '1' - real task will be run instead

As indicated in the final warning message there the real tasks run
since no sstate artifact is available. These tasks succeed:

NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
do_package_write_ipk: Succeeded

The result is a successful build of the desired images. However, the
build is marked as a failure due to those sstate errors:

Summary: There were 11 ERROR messages shown, returning a non-zero exit code.

Is this the expected behaviour? The final images are built correctly.
I can't see any simple way to mask those setscene errors but I might
be missing something.

The full log can be seen at
https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
I'm on the zeus branch here, I'll try to re-test on master later if I
can.

Thanks,
Paul
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48527): https://lists.yoctoproject.org/g/yocto/message/48527
Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Yocto Project Status WW07'20

[Richard Purdie]

On Thu, 2020-02-20 at 07:46 +, Jain, Sangeeta wrote:
> Planned upcoming dot releases:
>  YP 2.7.3 built and in QA
>  
> I didn’t see any notification for this build. Am I missing something?

No, its due to be built but isn't built yet!

I think that was meant to say 3.0.2, sorry about any confusion.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48526): https://lists.yoctoproject.org/g/yocto/message/48526
Mute This Topic: https://lists.yoctoproject.org/mt/71424332/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-openssl102-fips][PATCH] openssh: refresh patches to 8.2p1

[Yi Zhao]

Please ignore this. I have sent V2 with clean commit message.


//Yi

On 2/20/20 5:19 PM, Yi Zhao wrote:

Issue: LINCD-1151

Refresh patches to openssh-8.2p1.
Reference:
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-7.7p1-fips.patch
(commit 51f5c1c99f1d20e48328edde666061d0ce0da83b)

(LOCAL REV: NOT UPSTREAM) -- send to meta-openssl102-fips on 20200220

Signed-off-by: Yi Zhao 
---
  .../0001-conditional-enable-fips-mode.patch   |  54 ++--
  ...ps.patch => 0001-openssh-8.2p1-fips.patch} | 300 --
  .../openssh/openssh-6.6p1-ctr-cavstest.patch  |  35 +-
  .../openssh/openssh-6.7p1-kdf-cavs.patch  |  35 +-
  recipes-connectivity/openssh/openssh_fips.inc |   2 +-
  5 files changed, 202 insertions(+), 224 deletions(-)
  rename recipes-connectivity/openssh/openssh/{0001-openssh-8.0p1-fips.patch => 
0001-openssh-8.2p1-fips.patch} (57%)

diff --git 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
index a0f496a..942fda6 100644
--- 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
+++ 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -1,4 +1,4 @@
-From 60204df9d1f54f581f9ddc5443228550cadd4b4b Mon Sep 17 00:00:00 2001
+From ef6490841a73b4f71ca35e09328c6a8b0ad9dba9 Mon Sep 17 00:00:00 2001
  From: Hongxu Jia 
  Date: Sat, 21 Dec 2019 13:03:23 +0800
  Subject: [PATCH] conditional enable fips mode
@@ -56,10 +56,10 @@ index 359204f..346255a 100644
log_init(__progname, log_level, log_facility, log_stderr);
   
  diff --git a/sftp.c b/sftp.c

-index b66037f..ca263ac 100644
+index ff14d3c..a633200 100644
  --- a/sftp.c
  +++ b/sftp.c
-@@ -2387,6 +2387,7 @@ main(int argc, char **argv)
+@@ -2390,6 +2390,7 @@ main(int argc, char **argv)
size_t num_requests = DEFAULT_NUM_REQUESTS;
long long limit_kbps = 0;
   
@@ -68,10 +68,10 @@ index b66037f..ca263ac 100644

sanitise_stdfd();
msetlocale();
  diff --git a/ssh-add.c b/ssh-add.c
-index ebfb8a3..b7d59bc 100644
+index 8057eb1..19f3da2 100644
  --- a/ssh-add.c
  +++ b/ssh-add.c
-@@ -577,6 +577,7 @@ main(int argc, char **argv)
+@@ -628,6 +628,7 @@ main(int argc, char **argv)
SyslogFacility log_facility = SYSLOG_FACILITY_AUTH;
LogLevel log_level = SYSLOG_LEVEL_INFO;
   
@@ -80,10 +80,10 @@ index ebfb8a3..b7d59bc 100644

sanitise_stdfd();
   
  diff --git a/ssh-agent.c b/ssh-agent.c

-index 9c6680a..d701479 100644
+index 7eb6f0d..1409044 100644
  --- a/ssh-agent.c
  +++ b/ssh-agent.c
-@@ -1104,6 +1104,7 @@ main(int ac, char **av)
+@@ -1196,6 +1196,7 @@ main(int ac, char **av)
size_t npfd = 0;
u_int maxfds;
   
@@ -92,10 +92,10 @@ index 9c6680a..d701479 100644

sanitise_stdfd();
   
  diff --git a/ssh-keygen.c b/ssh-keygen.c

-index cb4982d..84dd269 100644
+index feafe73..9b832f6 100644
  --- a/ssh-keygen.c
  +++ b/ssh-keygen.c
-@@ -2800,6 +2800,7 @@ main(int argc, char **argv)
+@@ -3140,6 +3140,7 @@ main(int argc, char **argv)
extern int optind;
extern char *optarg;
   
@@ -104,10 +104,10 @@ index cb4982d..84dd269 100644

sanitise_stdfd();
   
  diff --git a/ssh-keyscan.c b/ssh-keyscan.c

-index 5de0508..0644261 100644
+index a5e6440..e56a9d1 100644
  --- a/ssh-keyscan.c
  +++ b/ssh-keyscan.c
-@@ -663,6 +663,7 @@ main(int argc, char **argv)
+@@ -675,6 +675,7 @@ main(int argc, char **argv)
extern int optind;
extern char *optarg;
   
@@ -116,7 +116,7 @@ index 5de0508..0644261 100644

seed_rng();
TAILQ_INIT();
  diff --git a/ssh-keysign.c b/ssh-keysign.c
-index 6cfd5b4..23cf403 100644
+index 3e3ea3e..4804c42 100644
  --- a/ssh-keysign.c
  +++ b/ssh-keysign.c
  @@ -173,6 +173,7 @@ main(int argc, char **argv)
@@ -128,10 +128,10 @@ index 6cfd5b4..23cf403 100644
fatal("%s: pledge: %s", __progname, strerror(errno));
   
  diff --git a/ssh-pkcs11-helper.c b/ssh-pkcs11-helper.c

-index 3bcc244..6a78a1a 100644
+index 17220d6..1af0c2e 100644
  --- a/ssh-pkcs11-helper.c
  +++ b/ssh-pkcs11-helper.c
-@@ -325,6 +325,7 @@ main(int argc, char **argv)
+@@ -332,6 +332,7 @@ main(int argc, char **argv)
extern char *__progname;
struct pollfd pfd[2];
   
@@ -140,22 +140,22 @@ index 3bcc244..6a78a1a 100644

seed_rng();
TAILQ_INIT(_keylist);
  diff --git a/ssh.c b/ssh.c
-index 0724df4..9178673 100644
+index 49331fc..06836dd 100644
  --- a/ssh.c
  +++ b/ssh.c
-@@ -598,6 +598,7 @@ main(int ac, char **av)
-   struct ssh_digest_ctx *md;
+@@ -606,6 +606,7 @@ main(int ac, char **av)
u_char conn_hash[SSH_DIGEST_MAX_LENGTH];
+   size_t n, len;
   
  +	ssh_enable_fips_mode();

/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
sanitise_stdfd();
   
  diff --git a/sshd.c b/sshd.c

-index 2bf8939..c75e34a 100644
+index b86d682..304bf01 100644
  --- a/sshd.

[yocto] [meta-openssl102-fips][PATCH V2] openssh: refresh patches to 8.2p1

[Yi Zhao]

Refresh patches to openssh-8.2p1.
Reference:
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-7.7p1-fips.patch
(commit 51f5c1c99f1d20e48328edde666061d0ce0da83b)

Signed-off-by: Yi Zhao 
---
 .../0001-conditional-enable-fips-mode.patch   |  54 ++--
 ...ps.patch => 0001-openssh-8.2p1-fips.patch} | 300 --
 .../openssh/openssh-6.6p1-ctr-cavstest.patch  |  35 +-
 .../openssh/openssh-6.7p1-kdf-cavs.patch  |  35 +-
 recipes-connectivity/openssh/openssh_fips.inc |   2 +-
 5 files changed, 202 insertions(+), 224 deletions(-)
 rename recipes-connectivity/openssh/openssh/{0001-openssh-8.0p1-fips.patch => 
0001-openssh-8.2p1-fips.patch} (57%)

diff --git 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
index a0f496a..942fda6 100644
--- 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
+++ 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -1,4 +1,4 @@
-From 60204df9d1f54f581f9ddc5443228550cadd4b4b Mon Sep 17 00:00:00 2001
+From ef6490841a73b4f71ca35e09328c6a8b0ad9dba9 Mon Sep 17 00:00:00 2001
 From: Hongxu Jia 
 Date: Sat, 21 Dec 2019 13:03:23 +0800
 Subject: [PATCH] conditional enable fips mode
@@ -56,10 +56,10 @@ index 359204f..346255a 100644
log_init(__progname, log_level, log_facility, log_stderr);
  
 diff --git a/sftp.c b/sftp.c
-index b66037f..ca263ac 100644
+index ff14d3c..a633200 100644
 --- a/sftp.c
 +++ b/sftp.c
-@@ -2387,6 +2387,7 @@ main(int argc, char **argv)
+@@ -2390,6 +2390,7 @@ main(int argc, char **argv)
size_t num_requests = DEFAULT_NUM_REQUESTS;
long long limit_kbps = 0;
  
@@ -68,10 +68,10 @@ index b66037f..ca263ac 100644
sanitise_stdfd();
msetlocale();
 diff --git a/ssh-add.c b/ssh-add.c
-index ebfb8a3..b7d59bc 100644
+index 8057eb1..19f3da2 100644
 --- a/ssh-add.c
 +++ b/ssh-add.c
-@@ -577,6 +577,7 @@ main(int argc, char **argv)
+@@ -628,6 +628,7 @@ main(int argc, char **argv)
SyslogFacility log_facility = SYSLOG_FACILITY_AUTH;
LogLevel log_level = SYSLOG_LEVEL_INFO;
  
@@ -80,10 +80,10 @@ index ebfb8a3..b7d59bc 100644
sanitise_stdfd();
  
 diff --git a/ssh-agent.c b/ssh-agent.c
-index 9c6680a..d701479 100644
+index 7eb6f0d..1409044 100644
 --- a/ssh-agent.c
 +++ b/ssh-agent.c
-@@ -1104,6 +1104,7 @@ main(int ac, char **av)
+@@ -1196,6 +1196,7 @@ main(int ac, char **av)
size_t npfd = 0;
u_int maxfds;
  
@@ -92,10 +92,10 @@ index 9c6680a..d701479 100644
sanitise_stdfd();
  
 diff --git a/ssh-keygen.c b/ssh-keygen.c
-index cb4982d..84dd269 100644
+index feafe73..9b832f6 100644
 --- a/ssh-keygen.c
 +++ b/ssh-keygen.c
-@@ -2800,6 +2800,7 @@ main(int argc, char **argv)
+@@ -3140,6 +3140,7 @@ main(int argc, char **argv)
extern int optind;
extern char *optarg;
  
@@ -104,10 +104,10 @@ index cb4982d..84dd269 100644
sanitise_stdfd();
  
 diff --git a/ssh-keyscan.c b/ssh-keyscan.c
-index 5de0508..0644261 100644
+index a5e6440..e56a9d1 100644
 --- a/ssh-keyscan.c
 +++ b/ssh-keyscan.c
-@@ -663,6 +663,7 @@ main(int argc, char **argv)
+@@ -675,6 +675,7 @@ main(int argc, char **argv)
extern int optind;
extern char *optarg;
  
@@ -116,7 +116,7 @@ index 5de0508..0644261 100644
seed_rng();
TAILQ_INIT();
 diff --git a/ssh-keysign.c b/ssh-keysign.c
-index 6cfd5b4..23cf403 100644
+index 3e3ea3e..4804c42 100644
 --- a/ssh-keysign.c
 +++ b/ssh-keysign.c
 @@ -173,6 +173,7 @@ main(int argc, char **argv)
@@ -128,10 +128,10 @@ index 6cfd5b4..23cf403 100644
fatal("%s: pledge: %s", __progname, strerror(errno));
  
 diff --git a/ssh-pkcs11-helper.c b/ssh-pkcs11-helper.c
-index 3bcc244..6a78a1a 100644
+index 17220d6..1af0c2e 100644
 --- a/ssh-pkcs11-helper.c
 +++ b/ssh-pkcs11-helper.c
-@@ -325,6 +325,7 @@ main(int argc, char **argv)
+@@ -332,6 +332,7 @@ main(int argc, char **argv)
extern char *__progname;
struct pollfd pfd[2];
  
@@ -140,22 +140,22 @@ index 3bcc244..6a78a1a 100644
seed_rng();
TAILQ_INIT(_keylist);
 diff --git a/ssh.c b/ssh.c
-index 0724df4..9178673 100644
+index 49331fc..06836dd 100644
 --- a/ssh.c
 +++ b/ssh.c
-@@ -598,6 +598,7 @@ main(int ac, char **av)
-   struct ssh_digest_ctx *md;
+@@ -606,6 +606,7 @@ main(int ac, char **av)
u_char conn_hash[SSH_DIGEST_MAX_LENGTH];
+   size_t n, len;
  
 +  ssh_enable_fips_mode();
/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
sanitise_stdfd();
  
 diff --git a/sshd.c b/sshd.c
-index 2bf8939..c75e34a 100644
+index b86d682..304bf01 100644
 --- a/sshd.c
 +++ b/sshd.c
-@@ -1443,6 +1443,7 @@ main(int ac, char **av)
+@@ -1514,6 +1514,7 @@ main(int ac, char **av)
Authctxt *authctxt;
struct connection_info *connection_info = NULL;
  
@@ -164,7 +164,7 @@ index 2bf8939..c75e34a 100644

[yocto] [meta-openssl102-fips][PATCH] openssh: refresh patches to 8.2p1

[Yi Zhao]

Issue: LINCD-1151

Refresh patches to openssh-8.2p1.
Reference:
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/plain/openssh-7.7p1-fips.patch
(commit 51f5c1c99f1d20e48328edde666061d0ce0da83b)

(LOCAL REV: NOT UPSTREAM) -- send to meta-openssl102-fips on 20200220

Signed-off-by: Yi Zhao 
---
 .../0001-conditional-enable-fips-mode.patch   |  54 ++--
 ...ps.patch => 0001-openssh-8.2p1-fips.patch} | 300 --
 .../openssh/openssh-6.6p1-ctr-cavstest.patch  |  35 +-
 .../openssh/openssh-6.7p1-kdf-cavs.patch  |  35 +-
 recipes-connectivity/openssh/openssh_fips.inc |   2 +-
 5 files changed, 202 insertions(+), 224 deletions(-)
 rename recipes-connectivity/openssh/openssh/{0001-openssh-8.0p1-fips.patch => 
0001-openssh-8.2p1-fips.patch} (57%)

diff --git 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
index a0f496a..942fda6 100644
--- 
a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
+++ 
b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -1,4 +1,4 @@
-From 60204df9d1f54f581f9ddc5443228550cadd4b4b Mon Sep 17 00:00:00 2001
+From ef6490841a73b4f71ca35e09328c6a8b0ad9dba9 Mon Sep 17 00:00:00 2001
 From: Hongxu Jia 
 Date: Sat, 21 Dec 2019 13:03:23 +0800
 Subject: [PATCH] conditional enable fips mode
@@ -56,10 +56,10 @@ index 359204f..346255a 100644
log_init(__progname, log_level, log_facility, log_stderr);
  
 diff --git a/sftp.c b/sftp.c
-index b66037f..ca263ac 100644
+index ff14d3c..a633200 100644
 --- a/sftp.c
 +++ b/sftp.c
-@@ -2387,6 +2387,7 @@ main(int argc, char **argv)
+@@ -2390,6 +2390,7 @@ main(int argc, char **argv)
size_t num_requests = DEFAULT_NUM_REQUESTS;
long long limit_kbps = 0;
  
@@ -68,10 +68,10 @@ index b66037f..ca263ac 100644
sanitise_stdfd();
msetlocale();
 diff --git a/ssh-add.c b/ssh-add.c
-index ebfb8a3..b7d59bc 100644
+index 8057eb1..19f3da2 100644
 --- a/ssh-add.c
 +++ b/ssh-add.c
-@@ -577,6 +577,7 @@ main(int argc, char **argv)
+@@ -628,6 +628,7 @@ main(int argc, char **argv)
SyslogFacility log_facility = SYSLOG_FACILITY_AUTH;
LogLevel log_level = SYSLOG_LEVEL_INFO;
  
@@ -80,10 +80,10 @@ index ebfb8a3..b7d59bc 100644
sanitise_stdfd();
  
 diff --git a/ssh-agent.c b/ssh-agent.c
-index 9c6680a..d701479 100644
+index 7eb6f0d..1409044 100644
 --- a/ssh-agent.c
 +++ b/ssh-agent.c
-@@ -1104,6 +1104,7 @@ main(int ac, char **av)
+@@ -1196,6 +1196,7 @@ main(int ac, char **av)
size_t npfd = 0;
u_int maxfds;
  
@@ -92,10 +92,10 @@ index 9c6680a..d701479 100644
sanitise_stdfd();
  
 diff --git a/ssh-keygen.c b/ssh-keygen.c
-index cb4982d..84dd269 100644
+index feafe73..9b832f6 100644
 --- a/ssh-keygen.c
 +++ b/ssh-keygen.c
-@@ -2800,6 +2800,7 @@ main(int argc, char **argv)
+@@ -3140,6 +3140,7 @@ main(int argc, char **argv)
extern int optind;
extern char *optarg;
  
@@ -104,10 +104,10 @@ index cb4982d..84dd269 100644
sanitise_stdfd();
  
 diff --git a/ssh-keyscan.c b/ssh-keyscan.c
-index 5de0508..0644261 100644
+index a5e6440..e56a9d1 100644
 --- a/ssh-keyscan.c
 +++ b/ssh-keyscan.c
-@@ -663,6 +663,7 @@ main(int argc, char **argv)
+@@ -675,6 +675,7 @@ main(int argc, char **argv)
extern int optind;
extern char *optarg;
  
@@ -116,7 +116,7 @@ index 5de0508..0644261 100644
seed_rng();
TAILQ_INIT();
 diff --git a/ssh-keysign.c b/ssh-keysign.c
-index 6cfd5b4..23cf403 100644
+index 3e3ea3e..4804c42 100644
 --- a/ssh-keysign.c
 +++ b/ssh-keysign.c
 @@ -173,6 +173,7 @@ main(int argc, char **argv)
@@ -128,10 +128,10 @@ index 6cfd5b4..23cf403 100644
fatal("%s: pledge: %s", __progname, strerror(errno));
  
 diff --git a/ssh-pkcs11-helper.c b/ssh-pkcs11-helper.c
-index 3bcc244..6a78a1a 100644
+index 17220d6..1af0c2e 100644
 --- a/ssh-pkcs11-helper.c
 +++ b/ssh-pkcs11-helper.c
-@@ -325,6 +325,7 @@ main(int argc, char **argv)
+@@ -332,6 +332,7 @@ main(int argc, char **argv)
extern char *__progname;
struct pollfd pfd[2];
  
@@ -140,22 +140,22 @@ index 3bcc244..6a78a1a 100644
seed_rng();
TAILQ_INIT(_keylist);
 diff --git a/ssh.c b/ssh.c
-index 0724df4..9178673 100644
+index 49331fc..06836dd 100644
 --- a/ssh.c
 +++ b/ssh.c
-@@ -598,6 +598,7 @@ main(int ac, char **av)
-   struct ssh_digest_ctx *md;
+@@ -606,6 +606,7 @@ main(int ac, char **av)
u_char conn_hash[SSH_DIGEST_MAX_LENGTH];
+   size_t n, len;
  
 +  ssh_enable_fips_mode();
/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
sanitise_stdfd();
  
 diff --git a/sshd.c b/sshd.c
-index 2bf8939..c75e34a 100644
+index b86d682..304bf01 100644
 --- a/sshd.c
 +++ b/sshd.c
-@@ -1443,6 +1443,7 @@ main(int ac, char **av)
+@@ -1514,6 +1514,7 @@ main(int ac, char **av)
Authctxt *authctxt;
struct connection_info 

Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

[Mikko Rapeli]

On Wed, Feb 19, 2020 at 10:57:41PM +0100, Martin Jansa wrote:
> > DEPENDS_class-target += "systemd"
> 
> You surely meant
> DEPENDS_append_class-target = " systemd"
> here

Yes, quite likely. Tough reason why += doesn't work is a mystery to me :)

I hack things until "bitbake -e" shows the right things for the recipes.

-Mikko

> On Wed, Feb 19, 2020 at 10:48 PM Mikko Rapeli  wrote:
> 
> > Hi,
> >
> > On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> > > Hello,
> > >
> > > I have a recipe that builds a library. The recipe specifies an
> > additional package "${PN}-systemd" along with other systemd related
> > variables and finally it instructs that the package should be built with
> > "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended
> > this recipe to nativesdk because I need this library on it. When trying to
> > build the corresponding nativesdk package, the build fails at the
> > configuration step (i.e. "do_configure") claiming it cannot find the
> > package systemd.
> > >
> > > Is there a way I can install the -already-generated libraries into my
> > SDK (potentially via the corresponding nativesdk recipe) without having to
> > rebuild the package? Or do I need to somehow include such systemd package
> > in my sdk (which I don't think I need at all)?
> > >
> > > Any hints and pointers as to were to look at are very well appreciated.
> > > Thanks.
> >
> > Make the systemd dependency for target only, e.g. DEPENDS_class-target +=
> > "systemd"
> > etc.
> >
> > There may be relevant use cases to build some of systemd components or
> > tools
> > to native or nativesdk targets too. In that case add BBCLASSEXTEND +=
> > "nativesdk" etc
> > in a bbappend to systemd.
> >
> > Hope this helps,
> >
> > -Mikko
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48522): https://lists.yoctoproject.org/g/yocto/message/48522
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-