Re: [OE-core] [PATCH] selftest/imagefeatures: Enable sanity test for IMAGE_GEN_DEBUGFS

[Yeoh Ee Peng]

Hi Ross,

This is a following up patch for enable sanity test for IMAGE_GEN_DEBUGFS. You 
provided the review for this patch in the past. Could you take a look and give 
us your inputs? Thank you very much for your attention and help!
https://lists.openembedded.org/g/openembedded-core/message/106075?p=,,,20,0,0,0::Created,,IMAGE_GEN_DEBUGFS,20,2,20,72347194

Thanks,
Ee Peng 

-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Yeoh Ee Peng
Sent: Wednesday, April 1, 2020 1:38 PM
To: openembedded-core@lists.openembedded.org
Cc: Yeoh, Ee Peng ; Humberto Ibarra 

Subject: [OE-core] [PATCH] selftest/imagefeatures: Enable sanity test for 
IMAGE_GEN_DEBUGFS

Add new testcase to check IMAGE_GEN_DEBUGFS. Test makes sure that debug 
filesystem is created accordingly. Test also check for debug symbols for some 
packages as suggested by Ross Burton.

[YOCTO #10906]

Signed-off-by: Humberto Ibarra 
Signed-off-by: Yeoh Ee Peng 
---
 meta/lib/oeqa/selftest/cases/imagefeatures.py | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index 5c519ac..9ad5c17 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -262,3 +262,36 @@ PNBLACKLIST[busybox] = "Don't build this"
 self.write_config(config)
 
 bitbake("--graphviz core-image-sato")
+
+def test_image_gen_debugfs(self):
+"""
+Summary: Check debugfs generation
+Expected:1. core-image-minimal can be build with IMAGE_GEN_DEBUGFS 
variable set
+ 2. debug filesystem is created when variable set
+ 3. debug symbols available
+Product: oe-core
+Author:  Humberto Ibarra 
+ Yeoh Ee Peng 
+"""
+import glob
+image_name = 'core-image-minimal'
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+
+features = 'IMAGE_GEN_DEBUGFS = "1"\n'
+features += 'IMAGE_FSTYPES_DEBUGFS = "tar.bz2"\n'
+features += 'MACHINE = "genericx86-64"\n'
+self.write_config(features)
+
+bitbake(image_name)
+dbg_tar_file = os.path.join(deploy_dir_image, "*-dbg.rootfs.tar.bz2")
+debug_files = glob.glob(dbg_tar_file)
+self.assertNotEqual(len(debug_files), 0, 'debug filesystem not 
generated')
+result = runCmd('cd %s; tar xvf %s' % (deploy_dir_image, dbg_tar_file))
+self.assertEqual(result.status, 0, msg='Failed to extract %s: %s' % 
(dbg_tar_file, result.output))
+result = runCmd('find %s -name %s' % (deploy_dir_image, "udevadm"))
+self.assertTrue("udevadm" in result.output, msg='Failed to find 
udevadm: %s' % result.output)
+dbg_symbols_targets = result.output.splitlines()
+self.assertTrue(dbg_symbols_targets, msg='Failed to split udevadm: %s' 
% dbg_symbols_targets)
+for t in dbg_symbols_targets:
+result = runCmd('objdump --syms %s | grep debug' % t)
+self.assertTrue("debug" in result.output, msg='Failed to 
+ find debug symbol: %s' % result.output)
--
2.7.4

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

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

[OE-core] [PATCH] selftest/imagefeatures: Enable sanity test for IMAGE_GEN_DEBUGFS

[Yeoh Ee Peng]

Add new testcase to check IMAGE_GEN_DEBUGFS. Test makes
sure that debug filesystem is created accordingly. Test also check
for debug symbols for some packages as suggested by Ross Burton.

[YOCTO #10906]

Signed-off-by: Humberto Ibarra 
Signed-off-by: Yeoh Ee Peng 
---
 meta/lib/oeqa/selftest/cases/imagefeatures.py | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index 5c519ac..9ad5c17 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -262,3 +262,36 @@ PNBLACKLIST[busybox] = "Don't build this"
 self.write_config(config)
 
 bitbake("--graphviz core-image-sato")
+
+def test_image_gen_debugfs(self):
+"""
+Summary: Check debugfs generation
+Expected:1. core-image-minimal can be build with IMAGE_GEN_DEBUGFS 
variable set
+ 2. debug filesystem is created when variable set
+ 3. debug symbols available
+Product: oe-core
+Author:  Humberto Ibarra 
+ Yeoh Ee Peng 
+"""
+import glob
+image_name = 'core-image-minimal'
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+
+features = 'IMAGE_GEN_DEBUGFS = "1"\n'
+features += 'IMAGE_FSTYPES_DEBUGFS = "tar.bz2"\n'
+features += 'MACHINE = "genericx86-64"\n'
+self.write_config(features)
+
+bitbake(image_name)
+dbg_tar_file = os.path.join(deploy_dir_image, "*-dbg.rootfs.tar.bz2")
+debug_files = glob.glob(dbg_tar_file)
+self.assertNotEqual(len(debug_files), 0, 'debug filesystem not 
generated')
+result = runCmd('cd %s; tar xvf %s' % (deploy_dir_image, dbg_tar_file))
+self.assertEqual(result.status, 0, msg='Failed to extract %s: %s' % 
(dbg_tar_file, result.output))
+result = runCmd('find %s -name %s' % (deploy_dir_image, "udevadm"))
+self.assertTrue("udevadm" in result.output, msg='Failed to find 
udevadm: %s' % result.output)
+dbg_symbols_targets = result.output.splitlines()
+self.assertTrue(dbg_symbols_targets, msg='Failed to split udevadm: %s' 
% dbg_symbols_targets)
+for t in dbg_symbols_targets:
+result = runCmd('objdump --syms %s | grep debug' % t)
+self.assertTrue("debug" in result.output, msg='Failed to find 
debug symbol: %s' % result.output)
-- 
2.7.4

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

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

Re: [OE-core] [PATCHv2] recipes-kernel/linux-firmware: Add qcom-sdm845-{audio,compute,modem} firmware packages

[Nicolas Dechesne]

On Tue, Mar 31, 2020 at 10:25 PM Aníbal Limón 
wrote:

> Contains the firmware for the audio, compute and modem/wireless in SDM845
> platforms.
>

thanks. it's better this way.

in case it helps:
Reviewed-by: Nicolas Dechesne 


>
> Signed-off-by: Aníbal Limón 
> ---
>  .../linux-firmware/linux-firmware_20200122.bb| 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> index a7406e48de..7173409e05 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> @@ -289,6 +289,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>   ${PN}-qcom-license \
>   ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 \
>   ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a530 \
> + ${PN}-qcom-sdm845-audio ${PN}-qcom-sdm845-compute
> ${PN}-qcom-sdm845-modem \
>   ${PN}-whence-license \
>   ${PN}-license \
>   "
> @@ -841,17 +842,23 @@ FILES_${PN}-qat-license   =
> "${nonarch_base_libdir}/firmware/LICENCE.qat_firmwar
>  FILES_${PN}-qat   = "${nonarch_base_libdir}/firmware/qat*.bin"
>  RDEPENDS_${PN}-qat= "${PN}-qat-license"
>
> -# For QCOM VPU/GPU
> +# For QCOM VPU/GPU and SDM845
>  LICENSE_${PN}-qcom-license = "Firmware-qcom"
>  FILES_${PN}-qcom-license   =
> "${nonarch_base_libdir}/firmware/LICENSE.qcom
> ${nonarch_base_libdir}/firmware/qcom/NOTICE.txt"
>  FILES_${PN}-qcom-venus-1.8 =
> "${nonarch_base_libdir}/firmware/qcom/venus-1.8/*"
>  FILES_${PN}-qcom-venus-4.2 =
> "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*"
>  FILES_${PN}-qcom-adreno-a3xx =
> "${nonarch_base_libdir}/firmware/qcom/a300_*.fw
> ${nonarch_base_libdir}/firmware/a300_*.fw"
>  FILES_${PN}-qcom-adreno-a530 =
> "${nonarch_base_libdir}/firmware/qcom/a530*.*"
> +FILES_${PN}-qcom-sdm845-audio =
> "${nonarch_base_libdir}/firmware/qcom/sdm845/adsp*.*"
> +FILES_${PN}-qcom-sdm845-compute =
> "${nonarch_base_libdir}/firmware/qcom/sdm845/cdsp*.*"
> +FILES_${PN}-qcom-sdm845-modem =
> "${nonarch_base_libdir}/firmware/qcom/sdm845/mba.mbn
> ${nonarch_base_libdir}/firmware/qcom/sdm845/modem*.*"
>  RDEPENDS_${PN}-qcom-venus-1.8 = "${PN}-qcom-license"
>  RDEPENDS_${PN}-qcom-venus-4.2 = "${PN}-qcom-license"
>  RDEPENDS_${PN}-qcom-adreno-a3xx = "${PN}-qcom-license"
>  RDEPENDS_${PN}-qcom-adreno-a530 = "${PN}-qcom-license"
> +RDEPENDS_${PN}-qcom-sdm845-audio = "${PN}-qcom-license"
> +RDEPENDS_${PN}-qcom-sdm845-compute = "${PN}-qcom-license"
> +RDEPENDS_${PN}-qcom-sdm845-modem = "${PN}-qcom-license"
>
>  FILES_${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
>
> --
> 2.26.0
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[OE-core] [PATCH] gstreamer1.0-plugins-good: Fix build when egl is enabled but no x11/wayland

[Khem Raj]

This fixes build errors seen in no-x11/no-wayland configuration ( eglfs
) and when QT5 support is enabled

Signed-off-by: Khem Raj 
---
 ...defines-GLsync-to-fix-compile-on-som.patch | 70 +++
 ...t-gstqtgl.h-instead-of-gst-gl-gstglf.patch | 56 +++
 .../gstreamer1.0-plugins-good_1.16.2.bb   |  2 +
 3 files changed, 128 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qmlgl-ensure-Qt-defines-GLsync-to-fix-compile-on-som.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qt-include-ext-qt-gstqtgl.h-instead-of-gst-gl-gstglf.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qmlgl-ensure-Qt-defines-GLsync-to-fix-compile-on-som.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qmlgl-ensure-Qt-defines-GLsync-to-fix-compile-on-som.patch
new file mode 100644
index 00..136848763b
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qmlgl-ensure-Qt-defines-GLsync-to-fix-compile-on-som.patch
@@ -0,0 +1,70 @@
+From 3e0d5577444b32579bdf5b69d720a322322ff7bc Mon Sep 17 00:00:00 2001
+From: Milian Wolff 
+Date: Tue, 26 Nov 2019 15:08:20 +0100
+Subject: [PATCH] qmlgl: ensure Qt defines GLsync to fix compile on some 
platforms
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+By explictly including QtGui/qopengl.h we force the code path that
+defines GLsync in the Qt-specific way. Without that, some platforms
+failed to compile the qmlgl plugin, since neither Qt nor gstreamer
+defined GLsync then, leading to e.g.:
+
+```
+make[4]: Entering directory '/.../gst-plugins-good-1.16.1/ext/qt'
+  CXX  libgstqmlgl_la-qtitem.lo
+In file included from gstqtgl.h:32,
+ from qtitem.h:27,
+ from qtitem.cc:28:
+/.../usr/include/gstreamer-1.0/
+gst/gl/gstglfuncs.h:93:17: error: expected identifier before ‘*’ token
+   ret (GSTGLAPI *name) args;
+ ^
+/.../usr/include/gstreamer-1.0/
+gst/gl/glprototypes/sync.h:27:1: note: in expansion of macro
+‘GST_GL_EXT_FUNCTION’
+ GST_GL_EXT_FUNCTION (GLsync, FenceSync,
+ ^~~
+```
+Signed-off-by: Khem Raj 
+Upstream-Status: Backport 
[https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/commit/3e0d5577444b32579bdf5b69d720a322322ff7bc]
+---
+ ext/qt/gstqtgl.h | 18 +++---
+ 1 file changed, 11 insertions(+), 7 deletions(-)
+
+--- a/ext/qt/gstqtgl.h
 b/ext/qt/gstqtgl.h
+@@ -22,14 +22,7 @@
+ #include 
+ #endif
+ 
+-/* qt uses the same trick as us to typedef GLsync on GLES2 but to a different
+- * type which confuses the preprocessor. Instead of trying to reconcile the
+- * two, we instead use the GLsync definition from Qt from above, and ensure
+- * that we don't typedef GLsync in gstglfuncs.h */
+ #include 
+-#undef GST_GL_HAVE_GLSYNC
+-#define GST_GL_HAVE_GLSYNC 1
+-#include 
+ 
+ /* The glext.h guard was renamed in 2018, but some software which
+  * includes their own copy of the GL headers (such as qt) might have
+@@ -46,6 +39,17 @@
+ #endif
+ #endif
+ 
++/* pulls in GLsync, see below */
++#include 
++
++/* qt uses the same trick as us to typedef GLsync on GLES2 but to a different
++ * type which confuses the preprocessor. Instead of trying to reconcile the
++ * two, we instead use the GLsync definition from Qt from above, and ensure
++ * that we don't typedef GLsync in gstglfuncs.h */
++#undef GST_GL_HAVE_GLSYNC
++#define GST_GL_HAVE_GLSYNC 1
++#include 
++
+ #if defined(QT_OPENGL_ES_2)
+ #include 
+ #include 
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qt-include-ext-qt-gstqtgl.h-instead-of-gst-gl-gstglf.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qt-include-ext-qt-gstqtgl.h-instead-of-gst-gl-gstglf.patch
new file mode 100644
index 00..3d423154e0
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-qt-include-ext-qt-gstqtgl.h-instead-of-gst-gl-gstglf.patch
@@ -0,0 +1,56 @@
+From d08234a659bec1fd5c984fedefbeb8192af07839 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 31 Mar 2020 21:23:28 -0700
+Subject: [PATCH] qt: include ext/qt/gstqtgl.h instead of gst/gl/gstglfuncs.h
+
+gst/gl/gstglfuncs.h is included via ext/qt/gstqtgl.h which has logic to
+prefer qt headers definitions for GLsync
+
+This helps in fixing build errors like below
+
+/mnt/b/yoe/build/tmp/work/cortexa7t2hf-neon-vfpv4-yoe-linux-gnueabi/gstreamer1.0-plugins-good/1.16.2-r0/recipe-sysroot/usr/include/QtGui/qopengles2ext.h:24:26:
 error: conflicting declaration 'typedef struct __GLsync* GLsync'
+   24 | typedef struct __GLsync *GLsync;
+  |  ^~
+In file included from 
/mnt/b/yoe/build/tmp/work/cortexa7t2hf-neon-vfpv4-yoe-linux-gnueabi/gstreamer1.0-plugins-good/1.16.2-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:84,
+ 

Re: [OE-core][RFC PATCH 2/2] image.bbclass: deploy image artifacts in stages

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Bartosz Golaszewski
> Sent: den 31 mars 2020 11:43
> To: Richard Purdie 
> Cc: Khem Raj ; Armin Kuster ;
> Jerome Neanne ; Quentin Schulz
> ; Patches and discussions about the
> oe-core layer ; Bartosz
> Golaszewski 
> Subject: Re: [OE-core][RFC PATCH 2/2] image.bbclass: deploy image
> artifacts in stages
> 
> pon., 30 mar 2020 o 18:31 Richard Purdie
>  napisał(a):

[cut]

> > Also, you used {}.format which I'm torn on since most of the codebase
> > uses the other approach.
> 
> I couldn't find any official guidelines for that. {} is the preferred
> way in Python. Maybe it's time to start slowly converting the bitbake
> codebase?

If we have waited so long to change string formatting, why not wait 
till we require  Python 3.6 and go for f-strings directly? With Tim's 
proposed patch we will soon require Python 3.5 as a minimum, so 3.6 
as a minimum requirement is probably not too long in the future...

Anyway, since I had fun generating it, I have included a graph 
depicting the use of % vs .format() for all Poky releases (and the 
script used to generate it; run it in a pristine clone of Poky for 
an interactive experience). Enjoy. :)

(For the curious, the first use of .format() was introduced to 
bitbake almost exactly 10 years ago in the Laverne release.)

//Peter



formattingwar-plot.sh
Description: formattingwar-plot.sh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[OE-core] [PATCH] perf: fix compile error when rebuilding

[Changqing Li]

From: Changqing Li 

Fix error like:
Makefile.perf:597: recipe for target
'intel_x86_64-wrs-linux/perf/1.0-r9/perf-1.0/perf-in.o] Error 2
Makefile.perf:220: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:69: recipe for target 'all' failed
make: *** [all] Error 2

during rebuilding, when kernel version changed, some
source files also maybe changed. It could happened
that the source under ${S} messed up with some already
dropped files and also new files. Fix by clean the ${S}
before copy source files.

Signed-off-by: Changqing Li 
---
 meta/recipes-kernel/perf/perf.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index e005eb0..c4b7b77 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -147,6 +147,7 @@ python copy_perf_source_from_kernel() {
 src_dir = d.getVar("STAGING_KERNEL_DIR")
 dest_dir = d.getVar("S")
 bb.utils.mkdirhier(dest_dir)
+bb.utils.prunedir(dest_dir)
 for s in sources:
 src = oe.path.join(src_dir, s)
 dest = oe.path.join(dest_dir, s)
-- 
2.7.4

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

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

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Martin Jansa]

Another piece of this puzzle might also be that in 2012 I was still using
minimalistic gentoo chroot, which was shared across all builders as git
repository, so even when you were building some kernel from tarball it
might have incorrectly assume that the kernel repo is dirty (even when it
was the git repo in top level rootfs directory which was dirty).

But I agree that my commit message in:
https://git.openembedded.org/meta-openembedded/commit/?id=ef29620a796fc3004afaf998c875ad76c533652c

sucks considering that the ML archives were changed at least 2 times since
this commit.

On Wed, Apr 1, 2020 at 2:32 AM Bruce Ashfield 
wrote:

> On Tue, Mar 31, 2020 at 9:29 PM Bruce Ashfield 
> wrote:
> >
> > On Tue, Mar 31, 2020 at 7:56 PM Paul Burton via Lists.Openembedded.Org
> >  wrote:
> > >
> > > The kernel_do_configure() function creates empty .scmversion files
> > > within both the source & build directories. The presence of these files
> > > causes the scm_version function within the kernel's
> > > scripts/setlocalversion to always output the empty string, breaking the
> > > kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
> > > string to the kernel version. Rather than appending the git commit hash
> > > or another SCM revision to the kernel version, the empty string is
> > > appended causing CONFIG_LOCALVERSION_AUTO to do nothing.
> > >
> > > This behavior was introduced for the build directory by commit
> > > c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
> > > extended to the source directory by commit cafb94f57123
> > > ("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
> > > entirely clear since these commits contain no meaningful descriptions
> > > and the former links to a mailing list archive that is no longer
> online,
> > > but the '+' character referenced would be appended if the kernel were
> > > built from a dirty working tree. This in itself is useful information;
> > > hiding that fact can only serve to muddy a user's understanding of what
> > > kernel they're actually running. I have verified that building a kernel
> > > from a clean working tree does not result in a spurious '+' character.
> >
> > I have all the original email from 2011 on the topic, Martin probably
> does
> > as well.
>
> Also note that in 2017 Trevor Woerner tried exactly the same fix that
> you are doing, but ended up retracting it when he found a test case
> that was still adding a + to the version.
>
> see: [OE-core] [PATCH] meta/classes/kernel.bbclass: revert 56fe5300ab5
>
> It might be worth checking with Trevor to see if he recalls what case
> it was where the + snuck back in.
>
> Cheers,
>
> Bruce
>
> Bruce
>
> >
> > A snippet from the conversation is this, and it is about moving some
> kernel
> > build steps into oe-core from meta-oe:
> >
> > --
> > "If you're working on shared linux.inc in meta-oe, could you please
> > integrate this:
> >
> > do_configure_prepend() {
> > #otherwise it gets extra '+' "2.6.37+"
> > #because:
> > #$ scripts/setlocalversion . => +
> > #$ make kernelversion => 2.6.37
> > #$ make kernelrelease => 2.6.37+
> >   rm -rf ${S}/.git
> > }
> >
> > I have to do this in every git recipe as I don't like dirs like
> > /lib/modules/2.6.37+
> >
> > Maybe it should be fixed on kernel.bbclass level, because linux-yocto
> > suffers the same ie /lib/modules/3.0.12-yocto-standard+
> >
> > Ccing oe-core for that.."
> > --
> >
> > I didn't make any of the changes, but looking at the thread, if you
> aren't
> > getting a + added to the localversion or directories, then I can't see
> how
> > it would break anything.
> >
> > Cheers,
> >
> > Bruce
> >
> > >
> > > Remove the creation of the empty .scmversion files in order to restore
> > > the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> > > of kernels built from non-tagged source & configured with
> > > CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> > > actually running.
> > >
> > > Signed-off-by: Paul Burton 
> > > ---
> > >  meta/classes/kernel.bbclass | 6 --
> > >  1 file changed, 6 deletions(-)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index a724645466..46e24a19e2 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] +=
> "OLDEST_KERNEL KERNEL_VERSION"
> > >  do_configure[prefuncs] += "check_oldest_kernel"
> > >
> > >  kernel_do_configure() {
> > > -   # fixes extra + in /lib/modules/2.6.37+
> > > -   # $ scripts/setlocalversion . => +
> > > -   # $ make kernelversion => 2.6.37
> > > -   # $ make kernelrelease => 2.6.37+
> > > -   touch ${B}/.scmversion ${S}/.scmversion
> > > -
> > > if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
> "${B}/.config" ]; then
> > > mv "${S}/.config" "${B}/.config"
> > > fi
> > > --
> > > 

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Bruce Ashfield]

On Tue, Mar 31, 2020 at 9:29 PM Bruce Ashfield  wrote:
>
> On Tue, Mar 31, 2020 at 7:56 PM Paul Burton via Lists.Openembedded.Org
>  wrote:
> >
> > The kernel_do_configure() function creates empty .scmversion files
> > within both the source & build directories. The presence of these files
> > causes the scm_version function within the kernel's
> > scripts/setlocalversion to always output the empty string, breaking the
> > kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
> > string to the kernel version. Rather than appending the git commit hash
> > or another SCM revision to the kernel version, the empty string is
> > appended causing CONFIG_LOCALVERSION_AUTO to do nothing.
> >
> > This behavior was introduced for the build directory by commit
> > c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
> > extended to the source directory by commit cafb94f57123
> > ("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
> > entirely clear since these commits contain no meaningful descriptions
> > and the former links to a mailing list archive that is no longer online,
> > but the '+' character referenced would be appended if the kernel were
> > built from a dirty working tree. This in itself is useful information;
> > hiding that fact can only serve to muddy a user's understanding of what
> > kernel they're actually running. I have verified that building a kernel
> > from a clean working tree does not result in a spurious '+' character.
>
> I have all the original email from 2011 on the topic, Martin probably does
> as well.

Also note that in 2017 Trevor Woerner tried exactly the same fix that
you are doing, but ended up retracting it when he found a test case
that was still adding a + to the version.

see: [OE-core] [PATCH] meta/classes/kernel.bbclass: revert 56fe5300ab5

It might be worth checking with Trevor to see if he recalls what case
it was where the + snuck back in.

Cheers,

Bruce

Bruce

>
> A snippet from the conversation is this, and it is about moving some kernel
> build steps into oe-core from meta-oe:
>
> --
> "If you're working on shared linux.inc in meta-oe, could you please
> integrate this:
>
> do_configure_prepend() {
> #otherwise it gets extra '+' "2.6.37+"
> #because:
> #$ scripts/setlocalversion . => +
> #$ make kernelversion => 2.6.37
> #$ make kernelrelease => 2.6.37+
>   rm -rf ${S}/.git
> }
>
> I have to do this in every git recipe as I don't like dirs like
> /lib/modules/2.6.37+
>
> Maybe it should be fixed on kernel.bbclass level, because linux-yocto
> suffers the same ie /lib/modules/3.0.12-yocto-standard+
>
> Ccing oe-core for that.."
> --
>
> I didn't make any of the changes, but looking at the thread, if you aren't
> getting a + added to the localversion or directories, then I can't see how
> it would break anything.
>
> Cheers,
>
> Bruce
>
> >
> > Remove the creation of the empty .scmversion files in order to restore
> > the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> > of kernels built from non-tagged source & configured with
> > CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> > actually running.
> >
> > Signed-off-by: Paul Burton 
> > ---
> >  meta/classes/kernel.bbclass | 6 --
> >  1 file changed, 6 deletions(-)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index a724645466..46e24a19e2 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL 
> > KERNEL_VERSION"
> >  do_configure[prefuncs] += "check_oldest_kernel"
> >
> >  kernel_do_configure() {
> > -   # fixes extra + in /lib/modules/2.6.37+
> > -   # $ scripts/setlocalversion . => +
> > -   # $ make kernelversion => 2.6.37
> > -   # $ make kernelrelease => 2.6.37+
> > -   touch ${B}/.scmversion ${S}/.scmversion
> > -
> > if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f 
> > "${B}/.config" ]; then
> > mv "${S}/.config" "${B}/.config"
> > fi
> > --
> > 2.26.0.rc2.310.g2932bb562d-goog
> >
> > 
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



--
- 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 (#136908): 
https://lists.openembedded.org/g/openembedded-core/message/136908
Mute This Topic: https://lists.openembedded.org/mt/72690129/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Bruce Ashfield]

On Tue, Mar 31, 2020 at 7:56 PM Paul Burton via Lists.Openembedded.Org
 wrote:
>
> The kernel_do_configure() function creates empty .scmversion files
> within both the source & build directories. The presence of these files
> causes the scm_version function within the kernel's
> scripts/setlocalversion to always output the empty string, breaking the
> kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
> string to the kernel version. Rather than appending the git commit hash
> or another SCM revision to the kernel version, the empty string is
> appended causing CONFIG_LOCALVERSION_AUTO to do nothing.
>
> This behavior was introduced for the build directory by commit
> c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
> extended to the source directory by commit cafb94f57123
> ("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
> entirely clear since these commits contain no meaningful descriptions
> and the former links to a mailing list archive that is no longer online,
> but the '+' character referenced would be appended if the kernel were
> built from a dirty working tree. This in itself is useful information;
> hiding that fact can only serve to muddy a user's understanding of what
> kernel they're actually running. I have verified that building a kernel
> from a clean working tree does not result in a spurious '+' character.

I have all the original email from 2011 on the topic, Martin probably does
as well.

A snippet from the conversation is this, and it is about moving some kernel
build steps into oe-core from meta-oe:

--
"If you're working on shared linux.inc in meta-oe, could you please
integrate this:

do_configure_prepend() {
#otherwise it gets extra '+' "2.6.37+"
#because:
#$ scripts/setlocalversion . => +
#$ make kernelversion => 2.6.37
#$ make kernelrelease => 2.6.37+
  rm -rf ${S}/.git
}

I have to do this in every git recipe as I don't like dirs like
/lib/modules/2.6.37+

Maybe it should be fixed on kernel.bbclass level, because linux-yocto
suffers the same ie /lib/modules/3.0.12-yocto-standard+

Ccing oe-core for that.."
--

I didn't make any of the changes, but looking at the thread, if you aren't
getting a + added to the localversion or directories, then I can't see how
it would break anything.

Cheers,

Bruce

>
> Remove the creation of the empty .scmversion files in order to restore
> the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> of kernels built from non-tagged source & configured with
> CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> actually running.
>
> Signed-off-by: Paul Burton 
> ---
>  meta/classes/kernel.bbclass | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index a724645466..46e24a19e2 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL 
> KERNEL_VERSION"
>  do_configure[prefuncs] += "check_oldest_kernel"
>
>  kernel_do_configure() {
> -   # fixes extra + in /lib/modules/2.6.37+
> -   # $ scripts/setlocalversion . => +
> -   # $ make kernelversion => 2.6.37
> -   # $ make kernelrelease => 2.6.37+
> -   touch ${B}/.scmversion ${S}/.scmversion
> -
> if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f 
> "${B}/.config" ]; then
> mv "${S}/.config" "${B}/.config"
> fi
> --
> 2.26.0.rc2.310.g2932bb562d-goog
>
> 



-- 
- 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 (#136907): 
https://lists.openembedded.org/g/openembedded-core/message/136907
Mute This Topic: https://lists.openembedded.org/mt/72690129/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Paul Burton via Lists.Openembedded.Org]

The kernel_do_configure() function creates empty .scmversion files
within both the source & build directories. The presence of these files
causes the scm_version function within the kernel's
scripts/setlocalversion to always output the empty string, breaking the
kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
string to the kernel version. Rather than appending the git commit hash
or another SCM revision to the kernel version, the empty string is
appended causing CONFIG_LOCALVERSION_AUTO to do nothing.

This behavior was introduced for the build directory by commit
c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
extended to the source directory by commit cafb94f57123
("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
entirely clear since these commits contain no meaningful descriptions
and the former links to a mailing list archive that is no longer online,
but the '+' character referenced would be appended if the kernel were
built from a dirty working tree. This in itself is useful information;
hiding that fact can only serve to muddy a user's understanding of what
kernel they're actually running. I have verified that building a kernel
from a clean working tree does not result in a spurious '+' character.

Remove the creation of the empty .scmversion files in order to restore
the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
of kernels built from non-tagged source & configured with
CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
actually running.

Signed-off-by: Paul Burton 
---
 meta/classes/kernel.bbclass | 6 --
 1 file changed, 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a724645466..46e24a19e2 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL 
KERNEL_VERSION"
 do_configure[prefuncs] += "check_oldest_kernel"
 
 kernel_do_configure() {
-   # fixes extra + in /lib/modules/2.6.37+
-   # $ scripts/setlocalversion . => +
-   # $ make kernelversion => 2.6.37
-   # $ make kernelrelease => 2.6.37+
-   touch ${B}/.scmversion ${S}/.scmversion
-
if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f 
"${B}/.config" ]; then
mv "${S}/.config" "${B}/.config"
fi
-- 
2.26.0.rc2.310.g2932bb562d-goog

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

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

[OE-core] [PATCH] default-providers.inc: Set U-Boot related default providers

[Otavio Salvador]

We should set the default providers for the U-Boot related packages and
recipes. Multiple providers are common to be found in the field due to
custom hardware BSP implementations.

Following providers are set:

 - PREFERRED_PROVIDER_u-boot-fw-utils ?= "libubootenv"
 - PREFERRED_RPROVIDER_u-boot-fw-utils ?= "libubootenv-bin"
 - PREFERRED_RPROVIDER_nativesdk-u-boot-mkimage ?= "nativesdk-u-boot-tools"

Signed-off-by: Otavio Salvador 
---

 meta/conf/distro/include/default-providers.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/distro/include/default-providers.inc 
b/meta/conf/distro/include/default-providers.inc
index ea88bd4876a..7cde1b5c17b 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -58,3 +58,7 @@ PREFERRED_PROVIDER_pkgconfig-native ?= "pkgconfig-native"
 PREFERRED_RPROVIDER_initd-functions ?= "initscripts"
 
 PREFERRED_PROVIDER_nativesdk-mesa ?= "nativesdk-mesa"
+
+PREFERRED_PROVIDER_u-boot-fw-utils ?= "libubootenv"
+PREFERRED_RPROVIDER_u-boot-fw-utils ?= "libubootenv-bin"
+PREFERRED_RPROVIDER_nativesdk-u-boot-mkimage ?= "nativesdk-u-boot-tools"
-- 
2.26.0

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

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

Re: [OE-Core][RFC PATCH v3 06/13] systemd: Add PACKAGECONFIG for sysvinit

[Otavio Salvador]

On Tue, Mar 31, 2020 at 4:45 PM Alex Kiernan  wrote:
> On Tue, Mar 31, 2020 at 1:28 PM Alex Kiernan via
> Lists.Openembedded.Org 
> wrote:
>
> I'm looking at the wrong build... if you remove sysvinit, systemd
> drops legacy.conf. What are you seeing that expects /run/lock?

fw_printenv and fw_setenv

https://github.com/sbabic/libubootenv/blob/master/src/uboot_env.c#L56-L71

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[OE-core] [PATCH] openssl: update to 1.1.1f

[Alexander Kanavin]

This also un-breaks python3 ptest which got broken
with 1.1.1e update.

Signed-off-by: Alexander Kanavin 
---
 .../openssl/{openssl_1.1.1e.bb => openssl_1.1.1f.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1e.bb => 
openssl_1.1.1f.bb} (98%)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1e.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1e.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
index 8f0702b535..3fa2b41fb9 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1e.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
@@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[sha256sum] = 
"694f61ac11cb51c9bf73f54e771ff6022b0327a43bbdfa1b2f19de1662a6dcbe"
+SRC_URI[sha256sum] = 
"186c6bfe6ecfba7a5b48c47f8a1673d0f3b0e5ba2e25602dd23b629975da3f35"
 
 inherit lib_package multilib_header multilib_script ptest
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
-- 
2.25.1

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

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

[OE-core] [PATCHv2] recipes-kernel/linux-firmware: Add qcom-sdm845-{audio,compute,modem} firmware packages

[Anibal Limon]

Contains the firmware for the audio, compute and modem/wireless in SDM845 
platforms.

Signed-off-by: Aníbal Limón 
---
 .../linux-firmware/linux-firmware_20200122.bb| 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
index a7406e48de..7173409e05 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
@@ -289,6 +289,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-qcom-license \
  ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 \
  ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a530 \
+ ${PN}-qcom-sdm845-audio ${PN}-qcom-sdm845-compute 
${PN}-qcom-sdm845-modem \
  ${PN}-whence-license \
  ${PN}-license \
  "
@@ -841,17 +842,23 @@ FILES_${PN}-qat-license   = 
"${nonarch_base_libdir}/firmware/LICENCE.qat_firmwar
 FILES_${PN}-qat   = "${nonarch_base_libdir}/firmware/qat*.bin"
 RDEPENDS_${PN}-qat= "${PN}-qat-license"
 
-# For QCOM VPU/GPU
+# For QCOM VPU/GPU and SDM845
 LICENSE_${PN}-qcom-license = "Firmware-qcom"
 FILES_${PN}-qcom-license   = "${nonarch_base_libdir}/firmware/LICENSE.qcom 
${nonarch_base_libdir}/firmware/qcom/NOTICE.txt"
 FILES_${PN}-qcom-venus-1.8 = "${nonarch_base_libdir}/firmware/qcom/venus-1.8/*"
 FILES_${PN}-qcom-venus-4.2 = "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*"
 FILES_${PN}-qcom-adreno-a3xx = "${nonarch_base_libdir}/firmware/qcom/a300_*.fw 
${nonarch_base_libdir}/firmware/a300_*.fw"
 FILES_${PN}-qcom-adreno-a530 = "${nonarch_base_libdir}/firmware/qcom/a530*.*"
+FILES_${PN}-qcom-sdm845-audio = 
"${nonarch_base_libdir}/firmware/qcom/sdm845/adsp*.*"
+FILES_${PN}-qcom-sdm845-compute = 
"${nonarch_base_libdir}/firmware/qcom/sdm845/cdsp*.*"
+FILES_${PN}-qcom-sdm845-modem = 
"${nonarch_base_libdir}/firmware/qcom/sdm845/mba.mbn 
${nonarch_base_libdir}/firmware/qcom/sdm845/modem*.*"
 RDEPENDS_${PN}-qcom-venus-1.8 = "${PN}-qcom-license"
 RDEPENDS_${PN}-qcom-venus-4.2 = "${PN}-qcom-license"
 RDEPENDS_${PN}-qcom-adreno-a3xx = "${PN}-qcom-license"
 RDEPENDS_${PN}-qcom-adreno-a530 = "${PN}-qcom-license"
+RDEPENDS_${PN}-qcom-sdm845-audio = "${PN}-qcom-license"
+RDEPENDS_${PN}-qcom-sdm845-compute = "${PN}-qcom-license"
+RDEPENDS_${PN}-qcom-sdm845-modem = "${PN}-qcom-license"
 
 FILES_${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
 
-- 
2.26.0

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

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

[OE-core] [PATCH v2 4/6] lib/oe/utils.py: add get_host_compiler_version()

[Tim Orling]

Add helper function to get the host compiler and version.
Do not assume compiler is gcc.

NOTE: cannot set env to d.getVar("PATH") as that does not contain
the session PATH which was set by environment-setup-... which
breaks the install-buildtools use-case

Signed-off-by: Tim Orling 
---
 meta/lib/oe/utils.py | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 9042b370f7..13f4271da0 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -373,6 +373,37 @@ def format_pkg_list(pkg_dict, ret_format=None):
 
 return output_str
 
+
+# Helper function to get the host compiler version
+# Do not assume the compiler is gcc
+def get_host_compiler_version(d, taskcontextonly=False):
+import re, subprocess
+
+if taskcontextonly and d.getVar('BB_WORKERCONTEXT') != '1':
+return
+
+compiler = d.getVar("BUILD_CC")
+# Get rid of ccache since it is not present when parsing.
+if compiler.startswith('ccache '):
+compiler = compiler[7:]
+try:
+env = os.environ.copy()
+# datastore PATH does not contain session PATH as set by 
environment-setup-...
+# this breaks the install-buildtools use-case
+# env["PATH"] = d.getVar("PATH")
+output = subprocess.check_output("%s --version" % compiler, \
+shell=True, env=env, 
stderr=subprocess.STDOUT).decode("utf-8")
+except subprocess.CalledProcessError as e:
+bb.fatal("Error running %s --version: %s" % (compiler, 
e.output.decode("utf-8")))
+
+match = re.match(r".* (\d+\.\d+)\.\d+.*", output.split('\n')[0])
+if not match:
+bb.fatal("Can't get compiler version from %s --version output" % 
compiler)
+
+version = match.group(1)
+return compiler, version
+
+
 def host_gcc_version(d, taskcontextonly=False):
 import re, subprocess
 
-- 
2.24.0

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

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

[OE-core] [PATCH v2 3/6] sanity.bbclass: recommend using install-buildtools

[Tim Orling]

For old tar version (< 1.28), recommend using
scripts/install-buildtools

Drop check for tar version 1.24. Dubious extra value.

Signed-off-by: Tim Orling 
---
 meta/classes/sanity.bbclass | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index cca5cdad17..fef05fb012 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -532,10 +532,8 @@ def check_tar_version(sanity_data):
 except subprocess.CalledProcessError as e:
 return "Unable to execute tar --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[3]
-if LooseVersion(version) < LooseVersion("1.24"):
-return "Your version of tar is older than 1.24 and has bugs which will 
break builds. Please install a newer version of tar (1.28+).\n"
 if LooseVersion(version) < LooseVersion("1.28"):
-return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar (you could use the projects buildtools-tarball from our last release).\n"
+return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar (you could use the projects buildtools-tarball from our last release or use 
scripts/install-buildtools).\n"
 return None
 
 # We use git parameters and functionality only found in 1.7.8 or later
-- 
2.24.0

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

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

[OE-core] [PATCH v2 6/6] install-buildtools: bump default to yocto-3.1_M3, fixes

[Tim Orling]

Add ability to check md5sum (yocto-3.1_M2 and before) or sha256
(yocto-3.1_M3 and beyond).

Make regex for path in checksum file optional, since
for yocto-3.1_M3 the format is   ,
but prior releases was   

Signed-off-by: Tim Orling 
---
 scripts/install-buildtools | 51 ++
 1 file changed, 30 insertions(+), 21 deletions(-)

diff --git a/scripts/install-buildtools b/scripts/install-buildtools
index 49cab1345a..92fb1eb7d2 100755
--- a/scripts/install-buildtools
+++ b/scripts/install-buildtools
@@ -11,14 +11,14 @@
 #  Example usage (extended buildtools from milestone):
 #(1) using --url and --filename
 #$ install-buildtools \
-#  --url 
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M2/buildtools
 \
-#  --filename 
x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200122.sh
+#  --url 
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M3/buildtools
 \
+#  --filename 
x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200315.sh
 #(2) using --base-url, --release, --installer-version and --build-date
 #$ install-buildtools \
 #  --base-url http://downloads.yoctoproject.org/releases/yocto \
-#  --release yocto-3.1_M2 \
+#  --release yocto-3.1_M3 \
 #  --installer-version 3.0+snapshot
-#  --build-date 202000122
+#  --build-date 202000315
 #
 #  Example usage (standard buildtools from release):
 #(3) using --url and --filename
@@ -61,9 +61,9 @@ logger = scriptutils.logger_create(PROGNAME, 
stream=sys.stdout)
 
 DEFAULT_INSTALL_DIR: str = 
os.path.join(os.path.split(scripts_path)[0],'buildtools')
 DEFAULT_BASE_URL: str = 'http://downloads.yoctoproject.org/releases/yocto'
-DEFAULT_RELEASE: str = 'yocto-3.1_M2'
+DEFAULT_RELEASE: str = 'yocto-3.1_M3'
 DEFAULT_INSTALLER_VERSION: str = '3.0+snapshot'
-DEFAULT_BUILDDATE: str = "20200122"
+DEFAULT_BUILDDATE: str = "20200315"
 
 
 def main():
@@ -189,31 +189,40 @@ def main():
 if args.check:
 import bb
 logger.info("Fetching buildtools installer checksum")
-check_url = "{}.md5sum".format(buildtools_url)
-checksum_filename = "%s.md5sum" % filename
-tmpbuildtools_checksum = os.path.join(tmpsdk_dir, 
checksum_filename)
-ret = subprocess.call("wget -q -O %s %s" %
-  (tmpbuildtools_checksum, check_url), 
shell=True)
-if ret != 0:
-logger.error("Could not download file from %s" % check_url)
-return ret
-regex = 
re.compile(r"^(?P[0-9a-f]+)\s\s(?P.*/)(?P.*)$")
+checksum_type = ""
+for checksum_type in ["md5sum", "sha256"]: 
+check_url = "{}.{}".format(buildtools_url, checksum_type)
+checksum_filename = "{}.{}".format(filename, checksum_type)
+tmpbuildtools_checksum = os.path.join(tmpsdk_dir, 
checksum_filename)
+ret = subprocess.call("wget -q -O %s %s" %
+  (tmpbuildtools_checksum, check_url), 
shell=True)
+if ret == 0:
+break
+else:
+if ret != 0:
+logger.error("Could not download file from %s" % check_url)
+return ret
+regex = 
re.compile(r"^(?P[0-9a-f]+)\s\s(?P.*/)?(?P.*)$")
 with open(tmpbuildtools_checksum, 'rb') as f:
 original = f.read()
 m = re.search(regex, original.decode("utf-8"))
-logger.debug("md5sum: %s" % m.group('md5sum'))
+logger.debug("checksum regex match: %s" % m)
+logger.debug("checksum: %s" % m.group('checksum'))
 logger.debug("path: %s" % m.group('path'))
 logger.debug("filename: %s" % m.group('filename'))
 if filename != m.group('filename'):
 logger.error("Filename does not match name in checksum")
 return 1
-md5sum = m.group('md5sum')
-md5value = bb.utils.md5_file(tmpbuildtools)
-if md5sum == md5value:
-logger.info("Checksum success")
+checksum = m.group('checksum')
+if checksum_type == "md5sum":
+checksum_value = bb.utils.md5_file(tmpbuildtools)
+else:
+checksum_value = bb.utils.sha256_file(tmpbuildtools)
+if checksum == checksum_value:
+logger.info("Checksum success")
 else:
 logger.error("Checksum %s expected. Actual checksum is %s." %
- (md5sum, md5value))
+ (checksum, checksum_value))
 
 # Make installer executable
 logger.info("Making installer executable")
-- 
2.24.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive 

[OE-core] [PATCH v2 2/6] oe-buildenv-internal: python 3.5 as min version

[Tim Orling]

Python 3.4 is EOL:
https://www.python.org/downloads/release/python-3410/

The last supported distro was probably CentOS-7, which has python36 available
from epel-7 or scl (as rh-python36) [1]

[1] https://www.softwarecollections.org/en/scls/rhscl/rh-python36/

Signed-off-by: Tim Orling 
---
 scripts/oe-buildenv-internal | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index 8cbe34669d..c62688fbd2 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -32,12 +32,12 @@ fi
 # We potentially have code that doesn't parse correctly with older versions 
 # of Python, and rather than fixing that and being eternally vigilant for 
 # any other new feature use, just check the version here.
-py_v34_check=$(python3 -c 'import sys; print(sys.version_info >= (3,4,0))')
-if [ "$py_v34_check" != "True" ]; then
-echo >&2 "BitBake requires Python 3.4.0 or later as 'python3'"
+py_v35_check=$(python3 -c 'import sys; print(sys.version_info >= (3,5,0))')
+if [ "$py_v35_check" != "True" ]; then
+echo >&2 "BitBake requires Python 3.5.0 or later as 'python3'"
 return 1
 fi
-unset py_v34_check
+unset py_v35_check
 
 if [ -z "$BDIR" ]; then
 if [ -z "$1" ]; then
-- 
2.24.0

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

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

[OE-core] [PATCH v2 1/6] scripts/install-buildtools: improvements

[Tim Orling]

* Install directory defaults to scripts/../buildtools
  e.g. --directory is set by default
  This avoids the user having to type in their sudo password
  to install in /opt/poky/

* Use "." rather than "source" for sourcing the environment script
  as not all distros (e.g. Debian) have "source" by default.

* Add buildtools/ to .gitignore

* Fix typos in example usage (--install-version -> --installer-version)

[YOCTO #13832]

Signed-off-by: Tim Orling 
---
 .gitignore |  1 +
 scripts/install-buildtools | 13 +
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index d0e6b2fb89..b66d371aac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,6 +9,7 @@ pstage/
 scripts/oe-git-proxy-socks
 sources/
 meta-*/
+buildtools/
 !meta-skeleton
 !meta-selftest
 hob-image-*.bb
diff --git a/scripts/install-buildtools b/scripts/install-buildtools
index 0947e9c4d6..49cab1345a 100755
--- a/scripts/install-buildtools
+++ b/scripts/install-buildtools
@@ -17,7 +17,7 @@
 #$ install-buildtools \
 #  --base-url http://downloads.yoctoproject.org/releases/yocto \
 #  --release yocto-3.1_M2 \
-#  --install-version 3.0+snapshot
+#  --installer-version 3.0+snapshot
 #  --build-date 202000122
 #
 #  Example usage (standard buildtools from release):
@@ -29,7 +29,7 @@
 #$ install-buildtools --without-extended-buildtools \
 #  --base-url http://downloads.yoctoproject.org/releases/yocto \
 #  --release yocto-3.0.2 \
-#  --install-version 3.0.2
+#  --installer-version 3.0.2
 #
 
 import argparse
@@ -59,6 +59,7 @@ if not bitbakepath:
 PROGNAME = 'install-buildtools'
 logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout)
 
+DEFAULT_INSTALL_DIR: str = 
os.path.join(os.path.split(scripts_path)[0],'buildtools')
 DEFAULT_BASE_URL: str = 'http://downloads.yoctoproject.org/releases/yocto'
 DEFAULT_RELEASE: str = 'yocto-3.1_M2'
 DEFAULT_INSTALLER_VERSION: str = '3.0+snapshot'
@@ -66,6 +67,7 @@ DEFAULT_BUILDDATE: str = "20200122"
 
 
 def main():
+global DEFAULT_INSTALL_DIR
 global DEFAULT_BASE_URL
 global DEFAULT_RELEASE
 global DEFAULT_INSTALLER_VERSION
@@ -73,6 +75,7 @@ def main():
 filename: str = ""
 release: str = ""
 buildtools_url: str = ""
+install_dir: str = ""
 
 parser = argparse.ArgumentParser(
 description="Buildtools installation helper",
@@ -87,6 +90,7 @@ def main():
  '(optional)\nRequires --url',
 action='store')
 parser.add_argument('-d', '--directory',
+default=DEFAULT_INSTALL_DIR,
 help='directory where buildtools SDK will be installed 
(optional)',
 action='store')
 parser.add_argument('-r', '--release',
@@ -216,12 +220,12 @@ def main():
 st = os.stat(tmpbuildtools)
 os.chmod(tmpbuildtools, st.st_mode | stat.S_IEXEC)
 logger.debug(os.stat(tmpbuildtools))
-install_dir = "/opt/poky/%s" % args.installer_version
 if args.directory:
 install_dir = args.directory
 ret = subprocess.call("%s -d %s -y" %
   (tmpbuildtools, install_dir), shell=True)
 else:
+install_dir = "/opt/poky/%s" % args.installer_version
 ret = subprocess.call("%s -y" % tmpbuildtools, shell=True)
 if ret != 0:
 logger.error("Could not run buildtools installer")
@@ -238,7 +242,8 @@ def main():
 tool = 'gcc'
 else:
 tool = 'tar'
-proc = subprocess.run("source 
%s/environment-setup-x86_64-pokysdk-linux && which %s" %
+logger.debug("install_dir: %s" % install_dir)
+proc = subprocess.run(". %s/environment-setup-x86_64-pokysdk-linux && 
which %s" %
   (install_dir, tool),
   shell=True, stdout=subprocess.PIPE)
 which_tool = proc.stdout.decode("utf-8")
-- 
2.24.0

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

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

[OE-core] [PATCH v2 5/6] sanity.bbclass: add test for gcc < 5.0

[Tim Orling]

It is known that the version of gcc in CentOS-7 (4.8.5) causes builds to fail.

Add a test for BUILD_CC == 'gcc' and gcc < 5.0 and recommend using
scripts/install-buildtools or user built buildtools-extended-tarball.

Use the new get_host_compiler_version function from lib/oe/utils.py

NOTE: another solution is to install devtoolset-6+ from scl [1], but
this is a rather large install (> 1 Gb) and fairly invasive.

[1] https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/

Signed-off-by: Tim Orling 
---
 meta/classes/sanity.bbclass | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index fef05fb012..f0186a9475 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -521,6 +521,25 @@ def check_wsl(d):
 return "OpenEmbedded doesn't work under WSL at this time, sorry"
 return None
 
+# The gcc version in CentOS-7 (4.8.5) is known to be a problem.
+# Require at least gcc version 5.0.
+#
+# This can be fixed on CentOS-7 with devtoolset-6+
+# https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/
+#
+# A less invasive fix is with scripts/install-buildtools (or with user
+# built buildtools-extended-tarball)
+#
+def check_gcc_version(sanity_data):
+from distutils.version import LooseVersion
+import subprocess
+
+build_cc, version = oe.utils.get_host_compiler_version(sanity_data)
+if build_cc.strip() == "gcc":
+if LooseVersion(version) < LooseVersion("5.0"):
+return "Your version of gcc is older than 5.0 and will break 
builds. Please install a newer version of gcc (you could use the project's 
buildtools-extended-tarball or use scripts/install-buildtools).\n"
+return None
+
 # Tar version 1.24 and onwards handle overwriting symlinks correctly
 # but earlier versions do not; this needs to work properly for sstate
 # Version 1.28 is needed so opkg-build works correctly when reproducibile 
builds are enabled
@@ -533,7 +552,7 @@ def check_tar_version(sanity_data):
 return "Unable to execute tar --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[3]
 if LooseVersion(version) < LooseVersion("1.28"):
-return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar (you could use the projects buildtools-tarball from our last release or use 
scripts/install-buildtools).\n"
+return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar (you could use the project's buildtools-tarball from our last release or 
use scripts/install-buildtools).\n"
 return None
 
 # We use git parameters and functionality only found in 1.7.8 or later
@@ -632,6 +651,7 @@ def check_sanity_version_change(status, d):
 except ImportError as e:
 status.addresult('Your Python 3 is not a full install. Please install 
the module %s (see the Getting Started guide for further information).\n' % 
e.name)
 
+status.addresult(check_gcc_version(d))
 status.addresult(check_make_version(d))
 status.addresult(check_patch_version(d))
 status.addresult(check_tar_version(d))
-- 
2.24.0

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

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

Re: [OE-Core][RFC PATCH v3 06/13] systemd: Add PACKAGECONFIG for sysvinit

[Alex Kiernan]

On Tue, Mar 31, 2020 at 1:28 PM Alex Kiernan via
Lists.Openembedded.Org 
wrote:
>
> Hi Otavio
>
> On Sat, Mar 28, 2020 at 5:17 PM Otavio Salvador
>  wrote:
> >
> > Hello Alex,
> >
> > On Fri, Mar 27, 2020 at 2:25 PM Alex Kiernan  wrote:
> > >
> > > Add sysvinit PACKAGECONFIG which disables all sysvinit handling in
> > > systemd if it isn't present.
> > >
> > > Consolidate sysvinit handling so that when it's disabled we exclude all
> > > sysvinit features.
> > >
> > > Signed-off-by: Alex Kiernan 
> >
> > This address the comments from Adrian and I'd like to mention that
> > /run/lock is not being created if sysvinit is removed from
> > PACKAGECONFIG.
> >
> > This patch is good to go as is, if possible Alex, take a look at the
> > /run/lock creation issue without sysvinit support.
> >
>
> Just got around to looking at this and I'm confused... you should have
> /usr/lib/tmpfiles.d/legacy.conf (which systemd delivers) which
> supplies that at runtime?
>

I'm looking at the wrong build... if you remove sysvinit, systemd
drops legacy.conf. What are you seeing that expects /run/lock?


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

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

Re: [OE-core] [PATCH] u-boot: Add UBOOT_LOCALVERSION_AUTO support

[Otavio Salvador]

On Tue, Mar 31, 2020 at 3:47 PM Denys Dmytriyenko  wrote:
> On Tue, Mar 31, 2020 at 03:18:41PM -0300, Otavio Salvador wrote:
> > On Tue, Mar 31, 2020 at 3:07 PM Denys Dmytriyenko  wrote:
> > > On Tue, Mar 31, 2020 at 02:46:41PM -0300, Otavio Salvador wrote:
> > > > Add the Git revision used for the build. It is very useful especially 
> > > > when
> > > > using custom or vendor U-Boot forks so we can map a binary to a specific
> > > > source revision. Valid values are "0" or "1".
> > >
> > > Well, UBOOT_LOCALVERSION was originally added specifically for this 
> > > purpose -
> > > to be able to append git hash.
> >
> > Not really; it kinda of maps to what Linux kernel provides and it is a
> > "suffix" for the version. For example "-ti" to imply it came from a
> > Texas Instruments fork.
>
> There are multiple uses and you can append anything you want. Here's the
> original patch that specifically mentions adding git hash, as an example:
> https://lists.openembedded.org/g/openembedded-core/topic/72204283
>
> > > > This is based on a class which has been in use in `meta-freescale` BSP
> > > > for years and has been very useful especially for custom U-Boot releases
> > > > as it allow we to know the exact Git revision used for the binary.
> > >
> > > And in meta-ti BSP we've used for many years:
> > > UBOOT_LOCALVERSION = "-g${@get_git_revision('${S}')}"
> > >
> > > And get_git_revision() just calls "git rev-parse HEAD"
> > >
> > > So, it seems a bit redundant to add another variable for this...
> >
> > How I use this is:
> >
> > UBOOT_LOCALVERSION = "-updatehub"
> > UBOOT_LOCALVERSION_AUTO = "1"
> >
> > I think it is way easier for users to do that. Using inline Python
> > code is possible but it is not something I qualify as user friendly.
>
> UBOOT_LOCALVERSION = "-updatehub-g${SRCPV}"

U-Boot 2020.01-updatehub-AUTOINC+d228123da8 (Mar 20 2020 - 17:05:55 +)

This is kinda ugly. Also the old behaviour is still supported.

Let's see what others from community think about it.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core] [PATCH] recipes-kernel/linux-firmware: Add qcom-sdm845 firmware package

[Anibal Limon]

On Tue, 31 Mar 2020 at 07:31, Nicolas Dechesne 
wrote:

>
>
> On Tue, Mar 31, 2020 at 4:01 AM Aníbal Limón 
> wrote:
>
>> Contains the firmware for the modem and wireless in SDM845 platforms.
>>
>
> it is more than that, since that folder contains also the audio and
> compute DSP firmware, so we should either say that , or not include them.
>
>
>> Signed-off-by: Aníbal Limón 
>> ---
>>  meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/recipes-kernel/linux-firmware/
>> linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/
>> linux-firmware_20200122.bb
>> index a7406e48de..3e03aafb6b 100644
>> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
>> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
>> @@ -289,6 +289,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>>   ${PN}-qcom-license \
>>   ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 \
>>   ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a530 \
>> + ${PN}-qcom-sdm845 \
>>   ${PN}-whence-license \
>>   ${PN}-license \
>>   "
>> @@ -848,10 +849,12 @@ FILES_${PN}-qcom-venus-1.8 =
>> "${nonarch_base_libdir}/firmware/qcom/venus-1.8/*"
>>  FILES_${PN}-qcom-venus-4.2 =
>> "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*"
>>  FILES_${PN}-qcom-adreno-a3xx =
>> "${nonarch_base_libdir}/firmware/qcom/a300_*.fw
>> ${nonarch_base_libdir}/firmware/a300_*.fw"
>>  FILES_${PN}-qcom-adreno-a530 =
>> "${nonarch_base_libdir}/firmware/qcom/a530*.*"
>> +FILES_${PN}-qcom-sdm845 = "${nonarch_base_libdir}/firmware/qcom/sdm845/*"
>>
>
> I think we should be specific for the files we include, using the wildcard
> means we don't control/know what we are packaging. We could do several
> packages for qcom-sdm845-modem, qcom-sdm845-audio, qcom-sdm845-compute, ...
> which would be ideal.. but i am not sure how appropriate this is for
> oe-core. but for the other qcom firmware, we package them by 'feature' (see
> above).
>

Right, better to have a split of firmware by feature, I will send a v2.

Anibal

>
>  RDEPENDS_${PN}-qcom-venus-1.8 = "${PN}-qcom-license"
>>  RDEPENDS_${PN}-qcom-venus-4.2 = "${PN}-qcom-license"
>>  RDEPENDS_${PN}-qcom-adreno-a3xx = "${PN}-qcom-license"
>>  RDEPENDS_${PN}-qcom-adreno-a530 = "${PN}-qcom-license"
>> +RDEPENDS_${PN}-qcom-sdm845 = "${PN}-qcom-license"
>>
>>  FILES_${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
>>
>> --
>> 2.26.0
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core] [PATCH] u-boot: Add UBOOT_LOCALVERSION_AUTO support

[Denys Dmytriyenko]

On Tue, Mar 31, 2020 at 03:18:41PM -0300, Otavio Salvador wrote:
> Hello Denys,
> 
> On Tue, Mar 31, 2020 at 3:07 PM Denys Dmytriyenko  wrote:
> > On Tue, Mar 31, 2020 at 02:46:41PM -0300, Otavio Salvador wrote:
> > > Add the Git revision used for the build. It is very useful especially when
> > > using custom or vendor U-Boot forks so we can map a binary to a specific
> > > source revision. Valid values are "0" or "1".
> >
> > Well, UBOOT_LOCALVERSION was originally added specifically for this purpose 
> > -
> > to be able to append git hash.
> 
> Not really; it kinda of maps to what Linux kernel provides and it is a
> "suffix" for the version. For example "-ti" to imply it came from a
> Texas Instruments fork.

There are multiple uses and you can append anything you want. Here's the 
original patch that specifically mentions adding git hash, as an example:
https://lists.openembedded.org/g/openembedded-core/topic/72204283


> > > This is based on a class which has been in use in `meta-freescale` BSP
> > > for years and has been very useful especially for custom U-Boot releases
> > > as it allow we to know the exact Git revision used for the binary.
> >
> > And in meta-ti BSP we've used for many years:
> > UBOOT_LOCALVERSION = "-g${@get_git_revision('${S}')}"
> >
> > And get_git_revision() just calls "git rev-parse HEAD"
> >
> > So, it seems a bit redundant to add another variable for this...
> 
> How I use this is:
> 
> UBOOT_LOCALVERSION = "-updatehub"
> UBOOT_LOCALVERSION_AUTO = "1"
> 
> I think it is way easier for users to do that. Using inline Python
> code is possible but it is not something I qualify as user friendly.

UBOOT_LOCALVERSION = "-updatehub-g${SRCPV}"

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

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

Re: [OE-core] [PATCH] u-boot: Add UBOOT_LOCALVERSION_AUTO support

[Otavio Salvador]

Hello Denys,

On Tue, Mar 31, 2020 at 3:07 PM Denys Dmytriyenko  wrote:
> On Tue, Mar 31, 2020 at 02:46:41PM -0300, Otavio Salvador wrote:
> > Add the Git revision used for the build. It is very useful especially when
> > using custom or vendor U-Boot forks so we can map a binary to a specific
> > source revision. Valid values are "0" or "1".
>
> Well, UBOOT_LOCALVERSION was originally added specifically for this purpose -
> to be able to append git hash.

Not really; it kinda of maps to what Linux kernel provides and it is a
"suffix" for the version. For example "-ti" to imply it came from a
Texas Instruments fork.

> > This is based on a class which has been in use in `meta-freescale` BSP
> > for years and has been very useful especially for custom U-Boot releases
> > as it allow we to know the exact Git revision used for the binary.
>
> And in meta-ti BSP we've used for many years:
> UBOOT_LOCALVERSION = "-g${@get_git_revision('${S}')}"
>
> And get_git_revision() just calls "git rev-parse HEAD"
>
> So, it seems a bit redundant to add another variable for this...

How I use this is:

UBOOT_LOCALVERSION = "-updatehub"
UBOOT_LOCALVERSION_AUTO = "1"

I think it is way easier for users to do that. Using inline Python
code is possible but it is not something I qualify as user friendly.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core] [PATCH] u-boot: Add UBOOT_LOCALVERSION_AUTO support

[Denys Dmytriyenko]

On Tue, Mar 31, 2020 at 02:46:41PM -0300, Otavio Salvador wrote:
> Add the Git revision used for the build. It is very useful especially when
> using custom or vendor U-Boot forks so we can map a binary to a specific
> source revision. Valid values are "0" or "1".

Well, UBOOT_LOCALVERSION was originally added specifically for this purpose - 
to be able to append git hash.


> This is based on a class which has been in use in `meta-freescale` BSP
> for years and has been very useful especially for custom U-Boot releases
> as it allow we to know the exact Git revision used for the binary.

And in meta-ti BSP we've used for many years:
UBOOT_LOCALVERSION = "-g${@get_git_revision('${S}')}"

And get_git_revision() just calls "git rev-parse HEAD"

So, it seems a bit redundant to add another variable for this...

-- 
Denys


> Signed-off-by: Otavio Salvador 
> ---
> 
>  meta/recipes-bsp/u-boot/u-boot.inc | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index b13db224732..39d35500e11 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -24,6 +24,11 @@ PACKAGECONFIG[openssl] = ",,openssl-native"
>  # file already exists it will not be overwritten.
>  UBOOT_LOCALVERSION ?= ""
>  
> +# Add the Git revision used for the build. It is very useful especially when
> +# using custom or vendor U-Boot forks so we can map a binary to a specific
> +# source revision. Valid values are "0" or "1".
> +UBOOT_LOCALVERSION_AUTO ?= "0"
> +
>  # Some versions of u-boot use .bin and others use .img.  By default use .bin
>  # but enable individual recipes to change this value.
>  UBOOT_SUFFIX ??= "bin"
> @@ -84,6 +89,19 @@ do_configure () {
>  oe_runmake -C ${S} O=${B} oldconfig
>  fi
>  merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
> +
> +if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]; then
> +if [ "${UBOOT_LOCALVERSION_AUTO}" = "1" ]; then
> +# Add GIT revision to the local version
> +head=`cd ${S} ; git rev-parse --verify --short HEAD 2> 
> /dev/null`
> +printf "%s%s%s" "${UBOOT_LOCALVERSION}" +g $head > 
> ${S}/.scmversion
> +printf "%s%s%s" "${UBOOT_LOCALVERSION}" +g $head > 
> ${B}/.scmversion
> +else
> +printf "%s" "${UBOOT_LOCALVERSION}" > ${S}/.scmversion
> +printf "%s" "${UBOOT_LOCALVERSION}" > ${B}/.scmversion
> +fi
> +fi
> +
>  cml1_do_configure
>  else
>  DEVTOOL_DISABLE_MENUCONFIG=true
> @@ -99,12 +117,6 @@ do_compile () {
>   unset CFLAGS
>   unset CPPFLAGS
>  
> - if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]
> - then
> - echo ${UBOOT_LOCALVERSION} > ${B}/.scmversion
> - echo ${UBOOT_LOCALVERSION} > ${S}/.scmversion
> - fi
> -
>  if [ -n "${UBOOT_CONFIG}" ]
>  then
>  unset i j k
> -- 
> 2.26.0
> 

> 

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

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

Re: [OE-core] [PATCH v2] u-boot: Restore valid default environment for running system

[Otavio Salvador]

On Tue, Mar 31, 2020 at 2:03 PM Stefano Babic  wrote:
> On 31.03.20 18:44, Otavio Salvador wrote:
> > Hello Stefano,
> >
> > On Tue, Mar 31, 2020 at 12:32 PM Stefano Babic  wrote:
> >> On 31.03.20 17:16, Otavio Salvador wrote:
> > ...
> >>> - u-boot-initial-env on deploy
> >>> - fw_env.config on deploy
> >>
> >> Why do we need both of them in deploy ? For making system functional, we
> >> just need that both files are in /etc, that is ${PN}-env must be
> >> installed (and then you set RRECOMMENDS). But why in deploy ? Am I
> >> missing something ?
> >
> > This is used externally, as well as the u-boot binary. In our case, we
> > use this to add them to the UpdateHub package so we can upgrade the
> > U-Boot environment during the update process. Something similar can be
> > done using swupdate.
> >
>
> Ah, ok - got it.
>
> In your commit message, you stated that as side-effect after switching
> to libubootenv is to put the initial environment in deploy. Fine with me

What I meant was a side effect of the change itself.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[OE-core] [PATCH] u-boot: Add UBOOT_LOCALVERSION_AUTO support

[Otavio Salvador]

Add the Git revision used for the build. It is very useful especially when
using custom or vendor U-Boot forks so we can map a binary to a specific
source revision. Valid values are "0" or "1".

This is based on a class which has been in use in `meta-freescale` BSP
for years and has been very useful especially for custom U-Boot releases
as it allow we to know the exact Git revision used for the binary.

Signed-off-by: Otavio Salvador 
---

 meta/recipes-bsp/u-boot/u-boot.inc | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index b13db224732..39d35500e11 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -24,6 +24,11 @@ PACKAGECONFIG[openssl] = ",,openssl-native"
 # file already exists it will not be overwritten.
 UBOOT_LOCALVERSION ?= ""
 
+# Add the Git revision used for the build. It is very useful especially when
+# using custom or vendor U-Boot forks so we can map a binary to a specific
+# source revision. Valid values are "0" or "1".
+UBOOT_LOCALVERSION_AUTO ?= "0"
+
 # Some versions of u-boot use .bin and others use .img.  By default use .bin
 # but enable individual recipes to change this value.
 UBOOT_SUFFIX ??= "bin"
@@ -84,6 +89,19 @@ do_configure () {
 oe_runmake -C ${S} O=${B} oldconfig
 fi
 merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
+
+if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]; then
+if [ "${UBOOT_LOCALVERSION_AUTO}" = "1" ]; then
+# Add GIT revision to the local version
+head=`cd ${S} ; git rev-parse --verify --short HEAD 2> 
/dev/null`
+printf "%s%s%s" "${UBOOT_LOCALVERSION}" +g $head > 
${S}/.scmversion
+printf "%s%s%s" "${UBOOT_LOCALVERSION}" +g $head > 
${B}/.scmversion
+else
+printf "%s" "${UBOOT_LOCALVERSION}" > ${S}/.scmversion
+printf "%s" "${UBOOT_LOCALVERSION}" > ${B}/.scmversion
+fi
+fi
+
 cml1_do_configure
 else
 DEVTOOL_DISABLE_MENUCONFIG=true
@@ -99,12 +117,6 @@ do_compile () {
unset CFLAGS
unset CPPFLAGS
 
-   if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]
-   then
-   echo ${UBOOT_LOCALVERSION} > ${B}/.scmversion
-   echo ${UBOOT_LOCALVERSION} > ${S}/.scmversion
-   fi
-
 if [ -n "${UBOOT_CONFIG}" ]
 then
 unset i j k
-- 
2.26.0

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

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

Re: [OE-core] [PATCH v2] u-boot: Restore valid default environment for running system

[Stefano Babic]

Hi Otavio,

On 31.03.20 18:44, Otavio Salvador wrote:
> Hello Stefano,
> 
> On Tue, Mar 31, 2020 at 12:32 PM Stefano Babic  wrote:
>> On 31.03.20 17:16, Otavio Salvador wrote:
> ...
>>> - u-boot-initial-env on deploy
>>> - fw_env.config on deploy
>>
>> Why do we need both of them in deploy ? For making system functional, we
>> just need that both files are in /etc, that is ${PN}-env must be
>> installed (and then you set RRECOMMENDS). But why in deploy ? Am I
>> missing something ?
> 
> This is used externally, as well as the u-boot binary. In our case, we
> use this to add them to the UpdateHub package so we can upgrade the
> U-Boot environment during the update process. Something similar can be
> done using swupdate.
> 

Ah, ok - got it.

In your commit message, you stated that as side-effect after switching
to libubootenv is to put the initial environment in deploy. Fine with me
if this helps to add further fetaures or you need it in UpdateHub.


Best regards,
Stefano

> 
> 
> 


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core] [PATCH v2] u-boot: Restore valid default environment for running system

[Otavio Salvador]

Hello Stefano,

On Tue, Mar 31, 2020 at 12:32 PM Stefano Babic  wrote:
> On 31.03.20 17:16, Otavio Salvador wrote:
...
> > - u-boot-initial-env on deploy
> > - fw_env.config on deploy
>
> Why do we need both of them in deploy ? For making system functional, we
> just need that both files are in /etc, that is ${PN}-env must be
> installed (and then you set RRECOMMENDS). But why in deploy ? Am I
> missing something ?

This is used externally, as well as the u-boot binary. In our case, we
use this to add them to the UpdateHub package so we can upgrade the
U-Boot environment during the update process. Something similar can be
done using swupdate.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-core] [PATCH v2] u-boot: Restore valid default environment for running system

[Stefano Babic]

Hi Otavio,

On 31.03.20 17:16, Otavio Salvador wrote:
> One significant change from previous OE-Core releases was the move from
> u-boot-fw-utils to libubootenv which offers a generic and not machine
> specific alternative. However, it is not fully functional as currently
> we don't provide the default environment nor the required configuration
> file to be used by it.

Fully agree - it was on my TODO list, then forgotten. Thanks for fixing
this !

> 
> This change address this and include on the default u-boot.inc the
> needed code to generate, install and deploy the default environment.
> 
> The side effect of this change are:
> 
> - new ${PN}-env

Agree.

> - u-boot-initial-env on deploy
> - fw_env.config on deploy

Why do we need both of them in deploy ? For making system functional, we
just need that both files are in /etc, that is ${PN}-env must be
installed (and then you set RRECOMMENDS). But why in deploy ? Am I
missing something ?

> 
> Signed-off-by: Otavio Salvador 
> ---
> This change is late in the cycle but it is critical in my opinion.
> 
> The lack of default environment as well as the configuration for the
> tool is a regression from the previous release and this mitigates it.
> 
> Changes in v2:
> - Fix wrong path on do_install
> - Change virtual/bootloader-env to u-boot-default-env (RP)
> - Add Tom Rini and Stefano Babic to Cc
> 
>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb |  1 +
>  meta/recipes-bsp/u-boot/u-boot.inc | 54 ++
>  2 files changed, 46 insertions(+), 9 deletions(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> index 7a7ec4c8856..144c5c941df 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> @@ -23,5 +23,6 @@ EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
>  
>  PROVIDES += "u-boot-fw-utils"
>  RPROVIDES_${PN}-bin += "u-boot-fw-utils"
> +RRECOMMENDS_${PN}-bin += "u-boot-default-env"
>  
>  BBCLASSEXTEND = "native"
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 648298da0bf..b13db224732 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -122,6 +122,11 @@ do_compile () {
>  cp ${B}/${config}/${binary} 
> ${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX}
>  fi
>  done
> +
> +# Generate the uboot-initial-env
> +oe_runmake -C ${S} O=${B}/${config} u-boot-initial-env
> +cp ${B}/${config}/u-boot-initial-env 
> ${B}/${config}/u-boot-initial-env-${type}
> +
>  unset k
>  fi
>  done
> @@ -130,6 +135,9 @@ do_compile () {
>  unset  i
>  else
>  oe_runmake -C ${S} O=${B} ${UBOOT_MAKE_TARGET}
> +
> +# Generate the uboot-initial-env
> +oe_runmake -C ${S} O=${B} u-boot-initial-env
>  fi
>  
>  }
> @@ -143,19 +151,26 @@ do_install () {
>  j=$(expr $j + 1);
>  if [ $j -eq $i ]
>  then
> -install -d ${D}/boot
> -install -m 644 
> ${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
> ${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
> +install -D -m 644 
> ${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
> ${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
>  ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX} 
> ${D}/boot/${UBOOT_BINARY}-${type}
>  ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX} 
> ${D}/boot/${UBOOT_BINARY}
> +
> +# Install the uboot-initial-env
> +install -D -m 644 
> ${B}/${config}/u-boot-initial-env-${type} 
> ${D}/${sysconfdir}/u-boot-initial-env-${type}-${PV}-${PR}
> +ln -sf u-boot-initial-env-${type}-${PV}-${PR} 
> ${D}/${sysconfdir}/u-boot-initial-env-${type}
> +ln -sf u-boot-initial-env-${type}-${PV}-${PR} 
> ${D}/${sysconfdir}/u-boot-initial-env
>  fi
>  done
>  unset  j
>  done
>  unset  i
>  else
> -install -d ${D}/boot
> -install -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
> +install -D -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
>  ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
> +
> +# Install the uboot-initial-env
> +install -D -m 644 ${B}/u-boot-initial-env 
> ${D}/${sysconfdir}/u-boot-initial-env-${PV}-${PR}
> +ln -sf u-boot-initial-env-${PV}-${PR} 
> ${D}/${sysconfdir}/u-boot-initial-env
>  fi
>  
>  if [ -n "${UBOOT_ELF}" ]
> @@ -224,7 +239,16 @@ do_install () {
>  
>  }
>  
> -FILES_${PN} = "/boot ${sysconfdir} ${datadir}"
> +PACKAGE_BEFORE_PN += "${PN}-env"
> +
> +RPROVIDES_${PN}-env += "u-boot-default-env"
> +FILES_${PN}-env = " \
> +

[OE-core] [PATCH v2] u-boot: Restore valid default environment for running system

[Otavio Salvador]

One significant change from previous OE-Core releases was the move from
u-boot-fw-utils to libubootenv which offers a generic and not machine
specific alternative. However, it is not fully functional as currently
we don't provide the default environment nor the required configuration
file to be used by it.

This change address this and include on the default u-boot.inc the
needed code to generate, install and deploy the default environment.

The side effect of this change are:

- new ${PN}-env
- u-boot-initial-env on deploy
- fw_env.config on deploy

Signed-off-by: Otavio Salvador 
---
This change is late in the cycle but it is critical in my opinion.

The lack of default environment as well as the configuration for the
tool is a regression from the previous release and this mitigates it.

Changes in v2:
- Fix wrong path on do_install
- Change virtual/bootloader-env to u-boot-default-env (RP)
- Add Tom Rini and Stefano Babic to Cc

 meta/recipes-bsp/u-boot/libubootenv_0.2.bb |  1 +
 meta/recipes-bsp/u-boot/u-boot.inc | 54 ++
 2 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
index 7a7ec4c8856..144c5c941df 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -23,5 +23,6 @@ EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
 
 PROVIDES += "u-boot-fw-utils"
 RPROVIDES_${PN}-bin += "u-boot-fw-utils"
+RRECOMMENDS_${PN}-bin += "u-boot-default-env"
 
 BBCLASSEXTEND = "native"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 648298da0bf..b13db224732 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -122,6 +122,11 @@ do_compile () {
 cp ${B}/${config}/${binary} 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX}
 fi
 done
+
+# Generate the uboot-initial-env
+oe_runmake -C ${S} O=${B}/${config} u-boot-initial-env
+cp ${B}/${config}/u-boot-initial-env 
${B}/${config}/u-boot-initial-env-${type}
+
 unset k
 fi
 done
@@ -130,6 +135,9 @@ do_compile () {
 unset  i
 else
 oe_runmake -C ${S} O=${B} ${UBOOT_MAKE_TARGET}
+
+# Generate the uboot-initial-env
+oe_runmake -C ${S} O=${B} u-boot-initial-env
 fi
 
 }
@@ -143,19 +151,26 @@ do_install () {
 j=$(expr $j + 1);
 if [ $j -eq $i ]
 then
-install -d ${D}/boot
-install -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+install -D -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
 ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX} 
${D}/boot/${UBOOT_BINARY}-${type}
 ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX} 
${D}/boot/${UBOOT_BINARY}
+
+# Install the uboot-initial-env
+install -D -m 644 
${B}/${config}/u-boot-initial-env-${type} 
${D}/${sysconfdir}/u-boot-initial-env-${type}-${PV}-${PR}
+ln -sf u-boot-initial-env-${type}-${PV}-${PR} 
${D}/${sysconfdir}/u-boot-initial-env-${type}
+ln -sf u-boot-initial-env-${type}-${PV}-${PR} 
${D}/${sysconfdir}/u-boot-initial-env
 fi
 done
 unset  j
 done
 unset  i
 else
-install -d ${D}/boot
-install -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
+install -D -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
 ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
+
+# Install the uboot-initial-env
+install -D -m 644 ${B}/u-boot-initial-env 
${D}/${sysconfdir}/u-boot-initial-env-${PV}-${PR}
+ln -sf u-boot-initial-env-${PV}-${PR} 
${D}/${sysconfdir}/u-boot-initial-env
 fi
 
 if [ -n "${UBOOT_ELF}" ]
@@ -224,7 +239,16 @@ do_install () {
 
 }
 
-FILES_${PN} = "/boot ${sysconfdir} ${datadir}"
+PACKAGE_BEFORE_PN += "${PN}-env"
+
+RPROVIDES_${PN}-env += "u-boot-default-env"
+FILES_${PN}-env = " \
+${sysconfdir}/u-boot-initial-env* \
+${sysconfdir}/fw_env.config \
+"
+
+FILES_${PN} = "/boot ${datadir}"
+RDEPENDS_${PN} += "${PN}-env"
 
 do_deploy () {
 if [ -n "${UBOOT_CONFIG}" ]
@@ -235,25 +259,37 @@ do_deploy () {
 j=$(expr $j + 1);
 if [ $j -eq $i ]
 then
-install -d ${DEPLOYDIR}
-install -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${DEPLOYDIR}/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+install -D -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 

[OE-core] Yocto Project Status WW13'20

[Stephen Jolley]

Current Dev Position: YP 3.1 M4 - Stabilization - Final RC builds

Next Deadline: YP 3.1 M4 build date  3/30/2020

 

Next Team Meetings:

*   Bug Triage meeting Thursday Apr. 2nd at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Apr. 7th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Mar. 31st  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See http://www.twitch.tv/letoatreidesthe2nd

 

Key Status/Updates:

*   3.1 M3 was released
*   The 3.1 rc1 build has not happened yet, the final remaining patches
are being worked upon and will be built when the remaining high issues are
resolved.
*   YP 3.1 has been announced as an LTS release:

https://www.yoctoproject.org/yocto-project-long-term-support-announced/
*   The focus is now on stabilizing and bug fixing for the final release
*   We continue to have concerns about the number of autobuilder
intermittent failures, particularly with this being an LTS release however
the remaining issues are proving hard to reproduce and track down.

 

YP 3.1 Milestone Dates:

*   YP 3.1 M4 build date  3/30/2020
*   YP 3.1 M4 release date  4/24/2020

 

Planned upcoming dot releases:

*   YP 3.0.3 build date  5/4/2020
*   YP 3.0.3 release date 5/15/2020
*   YP 2.7.4 build date  5/18/2020
*   YP 2.7.4 release date 5/29/2020

 

Tracking Metrics:

*   WDD 2663 (last week 2681) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1354 (last week 1350)
*   Patches in the Pending State: 536 (40%) [last week 535 (40%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

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

[OE-core] [PATCH] u-boot: Restore valid default environment for running system

[Otavio Salvador]

One significant change from previous OE-Core releases was the move from
u-boot-fw-utils to libubootenv which offers a generic and not machine
specific alternative. However, it is not fully functional as currently
we don't provide the default environment nor the required configuration
file to be used by it.

This change address this and include on the default u-boot.inc the
needed code to generate, install and deploy the default environment.

The side effect of this change are:

- new ${PN}-env
- u-boot-initial-env on deploy
- fw_env.config on deploy

Signed-off-by: Otavio Salvador 
---
This change is late in the cycle but it is critical in my opinion.

The lack of default environment as well as the configuration for the
tool is a regression from the previous release and this mitigates it.

 meta/recipes-bsp/u-boot/libubootenv_0.2.bb |  1 +
 meta/recipes-bsp/u-boot/u-boot.inc | 54 ++
 2 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
index 7a7ec4c8856..89e0c4f8df7 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -23,5 +23,6 @@ EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
 
 PROVIDES += "u-boot-fw-utils"
 RPROVIDES_${PN}-bin += "u-boot-fw-utils"
+RRECOMMENDS_${PN}-bin += "virtual/bootloader-env"
 
 BBCLASSEXTEND = "native"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 648298da0bf..e7e1ce10c62 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -122,6 +122,11 @@ do_compile () {
 cp ${B}/${config}/${binary} 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX}
 fi
 done
+
+# Generate the uboot-initial-env
+oe_runmake -C ${S} O=${B}/${config} u-boot-initial-env
+cp ${B}/${config}/u-boot-initial-env 
${B}/${config}/u-boot-initial-env-${type}
+
 unset k
 fi
 done
@@ -130,6 +135,9 @@ do_compile () {
 unset  i
 else
 oe_runmake -C ${S} O=${B} ${UBOOT_MAKE_TARGET}
+
+# Generate the uboot-initial-env
+oe_runmake -C ${S} O=${B} u-boot-initial-env
 fi
 
 }
@@ -143,19 +151,26 @@ do_install () {
 j=$(expr $j + 1);
 if [ $j -eq $i ]
 then
-install -d ${D}/boot
-install -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+install -D -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
 ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX} 
${D}/boot/${UBOOT_BINARY}-${type}
 ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX} 
${D}/boot/${UBOOT_BINARY}
+
+# Install the uboot-initial-env
+install -D -m 644 
${B}/${config}/u-boot-initial-env-${type} 
${D}/${sysconfdir}/u-boot-initial-env-${type}-${PV}-${PR}
+ln -sf u-boot-initial-env-${type}-${PV}-${PR} 
${D}/${sysconfdir}/u-boot-initial-env-${type}
+ln -sf u-boot-initial-env-${type}-${PV}-${PR} 
${D}/${sysconfdir}/u-boot-initial-env
 fi
 done
 unset  j
 done
 unset  i
 else
-install -d ${D}/boot
-install -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
+install -D -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
 ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
+
+# Install the uboot-initial-env
+install -D -m 644 ${B}/${config}/u-boot-initial-env 
${D}/${sysconfdir}/u-boot-initial-env-${PV}-${PR}
+ln -sf u-boot-initial-env-${PV}-${PR} 
${D}/${sysconfdir}/u-boot-initial-env
 fi
 
 if [ -n "${UBOOT_ELF}" ]
@@ -224,7 +239,16 @@ do_install () {
 
 }
 
-FILES_${PN} = "/boot ${sysconfdir} ${datadir}"
+PACKAGE_BEFORE_PN += "${PN}-env"
+
+RPROVIDES_${PN}-env += "virtual/bootloader-env"
+FILES_${PN}-env = " \
+${sysconfdir}/u-boot-initial-env* \
+${sysconfdir}/fw_env.config \
+"
+
+FILES_${PN} = "/boot ${datadir}"
+RDEPENDS_${PN} += "${PN}-env"
 
 do_deploy () {
 if [ -n "${UBOOT_CONFIG}" ]
@@ -235,25 +259,37 @@ do_deploy () {
 j=$(expr $j + 1);
 if [ $j -eq $i ]
 then
-install -d ${DEPLOYDIR}
-install -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${DEPLOYDIR}/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+install -D -m 644 
${B}/${config}/u-boot-${type}.${UBOOT_SUFFIX} 
${DEPLOYDIR}/u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+install -D -m 644 
${B}/${config}/u-boot-initial-env-${type} 

Re: [OE-core] [PATCH] recipes-kernel/linux-firmware: Add qcom-sdm845 firmware package

[Nicolas Dechesne]

On Tue, Mar 31, 2020 at 4:01 AM Aníbal Limón 
wrote:

> Contains the firmware for the modem and wireless in SDM845 platforms.
>

it is more than that, since that folder contains also the audio and compute
DSP firmware, so we should either say that , or not include them.


> Signed-off-by: Aníbal Limón 
> ---
>  meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> index a7406e48de..3e03aafb6b 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> @@ -289,6 +289,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>   ${PN}-qcom-license \
>   ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 \
>   ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a530 \
> + ${PN}-qcom-sdm845 \
>   ${PN}-whence-license \
>   ${PN}-license \
>   "
> @@ -848,10 +849,12 @@ FILES_${PN}-qcom-venus-1.8 =
> "${nonarch_base_libdir}/firmware/qcom/venus-1.8/*"
>  FILES_${PN}-qcom-venus-4.2 =
> "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*"
>  FILES_${PN}-qcom-adreno-a3xx =
> "${nonarch_base_libdir}/firmware/qcom/a300_*.fw
> ${nonarch_base_libdir}/firmware/a300_*.fw"
>  FILES_${PN}-qcom-adreno-a530 =
> "${nonarch_base_libdir}/firmware/qcom/a530*.*"
> +FILES_${PN}-qcom-sdm845 = "${nonarch_base_libdir}/firmware/qcom/sdm845/*"
>

I think we should be specific for the files we include, using the wildcard
means we don't control/know what we are packaging. We could do several
packages for qcom-sdm845-modem, qcom-sdm845-audio, qcom-sdm845-compute, ...
which would be ideal.. but i am not sure how appropriate this is for
oe-core. but for the other qcom firmware, we package them by 'feature' (see
above).

 RDEPENDS_${PN}-qcom-venus-1.8 = "${PN}-qcom-license"
>  RDEPENDS_${PN}-qcom-venus-4.2 = "${PN}-qcom-license"
>  RDEPENDS_${PN}-qcom-adreno-a3xx = "${PN}-qcom-license"
>  RDEPENDS_${PN}-qcom-adreno-a530 = "${PN}-qcom-license"
> +RDEPENDS_${PN}-qcom-sdm845 = "${PN}-qcom-license"
>
>  FILES_${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
>
> --
> 2.26.0
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [OE-Core][RFC PATCH v3 06/13] systemd: Add PACKAGECONFIG for sysvinit

[Alex Kiernan]

Hi Otavio

On Sat, Mar 28, 2020 at 5:17 PM Otavio Salvador
 wrote:
>
> Hello Alex,
>
> On Fri, Mar 27, 2020 at 2:25 PM Alex Kiernan  wrote:
> >
> > Add sysvinit PACKAGECONFIG which disables all sysvinit handling in
> > systemd if it isn't present.
> >
> > Consolidate sysvinit handling so that when it's disabled we exclude all
> > sysvinit features.
> >
> > Signed-off-by: Alex Kiernan 
>
> This address the comments from Adrian and I'd like to mention that
> /run/lock is not being created if sysvinit is removed from
> PACKAGECONFIG.
>
> This patch is good to go as is, if possible Alex, take a look at the
> /run/lock creation issue without sysvinit support.
>

Just got around to looking at this and I'm confused... you should have
/usr/lib/tmpfiles.d/legacy.conf (which systemd delivers) which
supplies that at runtime?

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

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

Re: [OE-core] [PATCH] file: explicitly disable seccomp

[Richard Purdie]

On Tue, 2020-03-31 at 12:57 +0200, Jan Luebbe wrote:
> Hi,
> 
> On Mon, 2020-01-20 at 17:10 +, Ross Burton wrote:
> > On 20/01/2020 15:45, Khem Raj wrote:
> > > pseudo needs some love since it alters syscalls which go out of
> > > bounds
> > > what is allowed by libseccomp until then pin your file version to
> > > 5.37
> > > in arch till a supported distro is affected by same problem. It
> > > wont
> > > be long better option is to fix pseudo
> > 
> > That's not quite right.  pseudo LD_PRELOADs itself into file, and
> > makes 
> > syscalls which are not whitelisted in file's seccomp configuration.
> > 
> > There's nothing pseudo can do to solve this.
> 
> I stumbled across this thread when checking why libseccomp is not in
> oe-core or meta-oe. It seems to me that pseudo could intercept the
> seccomp(2) or libseccomps seccomp_* function calls and report them as
> unsupported to simulate running on a kernel without seccomp support.
> 
> What am I missing? :)

I don't think we'd thought of that, I like the idea in principle...

Cheers,

Richard

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

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

Re: [OE-core] [PATCH] file: explicitly disable seccomp

[Jan Luebbe]

Hi,

On Mon, 2020-01-20 at 17:10 +, Ross Burton wrote:
> On 20/01/2020 15:45, Khem Raj wrote:
> > pseudo needs some love since it alters syscalls which go out of bounds
> > what is allowed by libseccomp until then pin your file version to 5.37
> > in arch till a supported distro is affected by same problem. It wont
> > be long better option is to fix pseudo
> 
> That's not quite right.  pseudo LD_PRELOADs itself into file, and makes 
> syscalls which are not whitelisted in file's seccomp configuration.
> 
> There's nothing pseudo can do to solve this.

I stumbled across this thread when checking why libseccomp is not in
oe-core or meta-oe. It seems to me that pseudo could intercept the
seccomp(2) or libseccomps seccomp_* function calls and report them as
unsupported to simulate running on a kernel without seccomp support.

What am I missing? :)

Regards,
Jan

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

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

Re: [OE-core][RFC PATCH 2/2] image.bbclass: deploy image artifacts in stages

[Bartosz Golaszewski]

pon., 30 mar 2020 o 18:31 Richard Purdie
 napisał(a):
>
> On Mon, 2020-03-30 at 18:26 +0200, Bartosz Golaszewski wrote:
> > pon., 23 mar 2020 o 18:28 Bartosz Golaszewski 
> > napisał(a):
> > > From: Bartosz Golaszewski 
> > >
> > > Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
> > > override. This way each generated set of artifacts is deployed as
> > > soon
> > > as it's ready instead of the do_image_complete task handling the
> > > entire
> > > deployement. This allows us to better fine-tune dependencies e.g.
> > > we
> > > can make do_image_wic depend on fitImage task which can in turn
> > > depend
> > > on do_image_ext4.
> > >
> > > We need to completely delete the do_package task in order to avoid
> > > problems with task hash changes as well as delete the IMGDEPLOYDIR
> > > variable from the data object passed to each image task so that
> > > it's
> > > expanded with the correct override.
> > >
> > > Signed-off-by: Bartosz Golaszewski 
> >
> > It's been a week. Can I get some feedback on this? Is the idea at
> > least remotely acceptable/can we build upon it?
>
> FWIW at a quick glance I didn't think it was too bad.
>
> I think there will be corner cases to resolve which I was hoping to
> look into and give some pointers to but I haven't had the time.
>
> I'm hoping somehow we can improve the FIXME you mention too.
>

Yeah, after thinking about it more, I figured that if a task signature
changes, then something is wrong. I guess it's because we end up
assigning pre- and postfuncs to tasks twice: once in anonymous python
code from image.bbclass and then from sstate.bbclass. Maybe we should
provide a python helper for explicitly making a task an sstate task
and - when using it - not add said task to SSTATETASKS, so that
sstate.bbclass code ignores it? Or maybe this anonymous function
should become an event handler invoked at event.RecipeParsed?

> The do_package change should probably be separated out - I'm guessing
> we did noexec there for a reason though?
>

I couldn't find a reason. Maybe it's a leftover from some previous,
now cleaned up change.

> Also, you used {}.format which I'm torn on since most of the codebase
> uses the other approach.
>

I couldn't find any official guidelines for that. {} is the preferred
way in Python. Maybe it's time to start slowly converting the bitbake
codebase?

> Its too late to get this into 3.1 and that is where I'm focusing my
> effort right now but I think this is probably going the right way.
>

Sure, I didn't expect it to go into the next release. If you're happy
with this direction I'll try to improve it and send a v2.

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

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

Re: [OE-core] [PATCH] netbase: use git fetcher

[Yu, Mingli]

Ping.

Thanks,
Mingli

From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of 
mingli...@windriver.com 
Sent: Monday, March 16, 2020 17:24
To: openembedded-core@lists.openembedded.org 

Subject: [OE-core] [PATCH] netbase: use git fetcher

From: Mingli Yu 

Use git repo as the the previous URL only stores
the latest source file and fails to locate the
source tar file if we don't upgrade timely.

Signed-off-by: Mingli Yu 
---
 meta/recipes-core/netbase/netbase_6.1.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/netbase/netbase_6.1.bb 
b/meta/recipes-core/netbase/netbase_6.1.bb
index bc0049c..c13685e 100644
--- a/meta/recipes-core/netbase/netbase_6.1.bb
+++ b/meta/recipes-core/netbase/netbase_6.1.bb
@@ -6,10 +6,10 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = 
"file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
 PE = "1"

-SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz"
+SRC_URI = "git://salsa.debian.org/md/netbase.git;protocol=https"
+SRCREV = "0fc1e4ce39328f7388badace0aaf7b7294d5ed61"

-SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55"
-SRC_URI[sha256sum] = 
"084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8"
+S = "${WORKDIR}/git"

 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/"
 do_install () {
--
2.7.4

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[OE-core] [PATCH] cve-check: CPE version '-' as all version

[Lee Chee Yang]

From: Lee Chee Yang 

CPE version could be '-' to mean no version info.
Current cve_check treat it as not valid and does not report these
CVE but some of these could be a valid vulnerabilities.

Since non-valid CVE can be whitelisted, so treat '-' as all version
and report all these CVE to capture possible vulnerabilities.

Non-valid CVE to be whitelisted separately.

[YOCTO #13617]

Signed-off-by: Lee Chee Yang 
---
 meta/classes/cve-check.bbclass | 2 +-
 meta/recipes-core/meta/cve-update-db-native.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 5d84b93..2a530a0 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -221,7 +221,7 @@ def check_cves(d, patched_cves):
 (_, _, _, version_start, operator_start, version_end, 
operator_end) = row
 #bb.debug(2, "Evaluating row " + str(row))
 
-if (operator_start == '=' and pv == version_start):
+if (operator_start == '=' and pv == version_start) or 
version_start == '-':
 vulnerable = True
 else:
 if operator_start:
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb 
b/meta/recipes-core/meta/cve-update-db-native.bb
index 6afe091..497d957 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -135,7 +135,7 @@ def parse_node_and_insert(c, node, cveId):
 product = cpe23[4]
 version = cpe23[5]
 
-if version != '*':
+if version != '*' and version != '-':
 # Version is defined, this is a '=' match
 yield [cveId, vendor, product, version, '=', '', '']
 else:
-- 
2.7.4

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

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