Re: [OE-core] [PATCH v2] mesa: updated to 20.0 release

[Ernst Sjöstrand]

Mesa usually says "This is a .0 release, and you may want to continue to to 
track 19.3.x until
20.0.1 comes out in two weeks. 19.3.5 is planned to be the final 19.3 release 
and is planned for next Wednesday."

Luckily, 20.0.1 came out now!

Regards
//Ernst

tor 2020-03-05 klockan 07:41 -0800 skrev Nathan Hartman:

Updated mesa and mesa-gl recipes to 20.0 release.


The license checksum difference is due to a small change in the license

formatting. The asterisk for footnotes was changed to a '[1]'

See:



https://urldefense.com/v3/__https://gitlab.freedesktop.org/mesa/mesa/-/commit/199572b65b7a03ffc887783e7f0f96f95bf1f99d__;!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdJptVVzSw$




glxgears runs successfully at 60 fps on a rpi4.


Signed-off-by: Nathan Hartman <



hnathan...@gmail.com

>

---

 .../mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} | 0

 meta/recipes-graphics/mesa/mesa.inc   | 2 +-

 meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} | 4 ++--

 3 files changed, 3 insertions(+), 3 deletions(-)

 rename meta/recipes-graphics/mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} 
(100%)

 rename meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} (88%)


diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb 
b/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb

similarity index 100%

rename from meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb

rename to meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc

index 54d7ea8961..b7ef496fdc 100644

--- a/meta/recipes-graphics/mesa/mesa.inc

+++ b/meta/recipes-graphics/mesa/mesa.inc

@@ -10,7 +10,7 @@ HOMEPAGE = "



https://urldefense.com/v3/__http://mesa3d.org__;!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdIQHGBJ_A$

 "

 BUGTRACKER = "



https://urldefense.com/v3/__https://bugs.freedesktop.org__;!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdIQ_4aXZw$

 "

 SECTION = "x11"

 LICENSE = "MIT"

-LIC_FILES_CHKSUM = "



file://docs/license.html;md5=3a4999caf82cc503ac8b9e37c235782e"


+LIC_FILES_CHKSUM = "



file://docs/license.html;md5=c1843d93c460bbf778d6037ce324f9f7"




 PE = "2"



diff --git a/meta/recipes-graphics/mesa/mesa_19.3.4.bb 
b/meta/recipes-graphics/mesa/mesa_20.0.0.bb

similarity index 88%

rename from meta/recipes-graphics/mesa/mesa_19.3.4.bb

rename to meta/recipes-graphics/mesa/mesa_20.0.0.bb

index 5f456c2429..2ed7ca2252 100644

--- a/meta/recipes-graphics/mesa/mesa_19.3.4.bb

+++ b/meta/recipes-graphics/mesa/mesa_20.0.0.bb

@@ -9,8 +9,8 @@ SRC_URI = "



https://urldefense.com/v3/__https://mesa.freedesktop.org/archive/mesa-$*7BPV*7D.tar.xz__;JSU!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdKys71eOA$

  \





file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch

 \

"



-SRC_URI[md5sum] = "09e7700d9af511384d131fb77b5802cb"

-SRC_URI[sha256sum] = 
"1da467e6ae2799a517e242462331eafd29ae77d9872f3a845df81f7c308e8fe4"

+SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795"

+SRC_URI[sha256sum] = 
"bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34"



 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"



--

2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3] alsa-utils: upgrade 1.2.1 -> 1.2.2

[Tanu Kaskinen]

On Sun, 2020-02-23 at 13:11 +, Richard Purdie wrote:
> On Sun, 2020-02-23 at 18:26 +0530, Praveen Muthusamy wrote:
> > From: Praveen Muthusamy 
> > 
> > Changelog: https://alsa-project.org/wiki/Changes_v1.2.1.2_v1.2.2
> > 
> > Signed-off-by: Praveen Muthusamy 
> > ---
> >  ...lsa-utils-scripts_1.2.1.bb => alsa-utils-scripts_1.2.2.bb} | 0
> >  .../alsa/{alsa-utils_1.2.1.bb => alsa-utils_1.2.2.bb} | 4 ++--
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.2.1.bb => 
> > alsa-utils-scripts_1.2.2.bb} (100%)
> >  rename meta/recipes-multimedia/alsa/{alsa-utils_1.2.1.bb => 
> > alsa-utils_1.2.2.bb} (97%)
> 
> Thanks, does this address the previous testing failure though?

alsa-utils 1.2.2 seems to depend on alsa-lib 1.2.2 (specifically,
alsatplg uses a new function in libatopology), so alsa-utils can't be
updated before alsa-lib.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cve-check: show whitelisted status

[chee . yang . lee]

From: Chee Yang Lee 

change whitelisted CVE status from "Patched" to "Whitelisted".

[Yocto #13687]

Signed-off-by: Chee Yang Lee 
---
 meta/classes/cve-check.bbclass | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 7412436..7f98da6 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -56,10 +56,10 @@ python do_cve_check () {
 patched_cves = get_patches_cves(d)
 except FileNotFoundError:
 bb.fatal("Failure in searching patches")
-patched, unpatched = check_cves(d, patched_cves)
+whitelisted, patched, unpatched = check_cves(d, patched_cves)
 if patched or unpatched:
 cve_data = get_cve_info(d, patched + unpatched)
-cve_write_data(d, patched, unpatched, cve_data)
+cve_write_data(d, patched, unpatched, whitelisted, cve_data)
 else:
 bb.note("No CVE database found, skipping CVE check")
 
@@ -263,7 +263,7 @@ def check_cves(d, patched_cves):
 
 conn.close()
 
-return (list(patched_cves), cves_unpatched)
+return (list(cve_whitelist), list(patched_cves), cves_unpatched)
 
 def get_cve_info(d, cves):
 """
@@ -287,7 +287,7 @@ def get_cve_info(d, cves):
 conn.close()
 return cve_data
 
-def cve_write_data(d, patched, unpatched, cve_data):
+def cve_write_data(d, patched, unpatched, whitelisted, cve_data):
 """
 Write CVE information in WORKDIR; and to CVE_CHECK_DIR, and
 CVE manifest if enabled.
@@ -303,7 +303,9 @@ def cve_write_data(d, patched, unpatched, cve_data):
 write_string += "PACKAGE NAME: %s\n" % d.getVar("PN")
 write_string += "PACKAGE VERSION: %s\n" % d.getVar("PV")
 write_string += "CVE: %s\n" % cve
-if cve in patched:
+if cve in whitelisted:
+write_string += "CVE STATUS: Whitelisted\n"
+elif cve in patched:
 write_string += "CVE STATUS: Patched\n"
 else:
 unpatched_cves.append(cve)
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bitbake: gitsm: download submodules

[Freihofer, Adrian]

On Thu, 2020-03-05 at 09:42 +, Paul Barker wrote:
> On Wed, 4 Mar 2020 12:30:10 +
> "Freihofer, Adrian"  wrote:
> 
> > -Original Message-
> > From: Paul Barker 
> > To: "Freihofer, Adrian" 
> > Cc: openembedded-core@lists.openembedded.org <
> > openembedded-core@lists.openembedded.org>
> > Subject: Re: [OE-core] [PATCH] bitbake: gitsm: download submodules
> > Date: Wed, 04 Mar 2020 09:59:44 +
> > 
> > On Wed, 4 Mar 2020 08:12:27 +
> > "Freihofer, Adrian"  wrote:
> > 
> > > The unpack function failed because the submodules were not
> > > downloaded.
> > > Calling download before unpack for each submodule solves this
> > > issue.
> > > 
> > > Signed-off-by: Adrian Freihofer 
> > > ---
> > >  bitbake/lib/bb/fetch2/gitsm.py | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/bitbake/lib/bb/fetch2/gitsm.py
> > > b/bitbake/lib/bb/fetch2/gitsm.py
> > > index c622771d21..3715e9824f 100644
> > > --- a/bitbake/lib/bb/fetch2/gitsm.py
> > > +++ b/bitbake/lib/bb/fetch2/gitsm.py
> > > @@ -184,6 +184,7 @@ class GitSM(Git):
> > >  
> > >  try:
> > >  newfetch = Fetch([url], d, cache=False)
> > > +newfetch.download()
> > >  newfetch.unpack(root=os.path.dirname(os.path.joi
> > > n(re
> > > po
> > > _conf, 'modules', module)))
> > >  except Exception as e:
> > >  logger.error('gitsm: submodule unpack failed: %s
> > > %s'
> > > %
> > > (type(e).__name__, str(e)))  
> > 
> > You shouldn't be trying to download submodules in the do_unpack
> > step.
> > If
> > they're missing at this stage it probably indicates a fetch issue.
> > 
> > Basically true, but the information about which submodules need to
> > be
> > downloaded is not available before the top level repo has been
> > unpacked. I guess the solution must be something like:
> > 
> > fetch top-level
> > unpack top-level
> > foreach submodule:
> >   fetch submodule
> >   unpack submodule
> > 
> > What's the exact error that you're seeing?
> > 
> > Don't remeber exactly. But when I debugged the flow, it became
> > obvious,
> > that the submodules are not downloaded.
> > 
> > This could be related to the issue I saw when the fetcher uses git
> > shallow
> > tarballs from a mirror - if that's the case I'm planning to get
> > that
> > fixed
> > this weekend.
> > 
> > Yes, the problem occurs with git shallows. The patch solves it with
> > and
> > without shallows for us.
> > 
> > Also, your email client seems to have chewed the patch up. It's
> > best to
> > send
> > patches using `git send-email` only.
> > 
> > Sorry, we switched to a new e-mail solution. I have to adapt my
> > setup.
> 
> The problem with your patch is that it would require network access
> during
> do_unpack which then breaks our ability to do offline builds.
Fetching in the unpack task is probably really wrong, I agree.
However, it also works on our CI infrastructure which runs without
Internet connectivity.
> 
> Do you only see this issue when fetching from git shallow mirror
> tarballs?

On our CI which works with gitshallow archives, fetching did not work
at all. On machines with Internet access we also had problems, but I did not 
completely analyze what happened. The ovmf package from poky was causing the 
troubles in our case.

> If so, the mirror tarballs need to be extracted during do_fetch but
> not placed in the usual 'git2' directory (as future fetches can't
> cope with shallow clones in that directory).

Do you already have an idea how this could be implemented?

> 
> Fixing this also has some impact on archiver.bbclass as that also
> needs to be able to walk the tree of submodules correctly.
Yes.
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] libdnf: fix deprecation warning

[Joe Slater]

Backport from libdnf.  Fix is in version 0.35.2.

Signed-off-by: Joe Slater 
---
 .../libdnf/libdnf/fix-deprecation-warning.patch| 71 ++
 meta/recipes-devtools/libdnf/libdnf_0.28.1.bb  |  1 +
 2 files changed, 72 insertions(+)
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch

diff --git a/meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch 
b/meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch
new file mode 100644
index 000..3a3e02f
--- /dev/null
+++ b/meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch
@@ -0,0 +1,71 @@
+From 66d9b2ba3fbc7b04f2b5ad9d0e5371340c037b5f Mon Sep 17 00:00:00 2001
+From: Marek Blaha 
+Date: Wed, 10 Jul 2019 10:11:01 +0200
+Subject: [oe-core][PATCH 1/1] Fix Python 3.8 deprecation warning
+ (RhBug:1724244)
+
+This deprecation warning was introduced in Python 3.8 by
+https://bugs.python.org/issue36381:
+
+/usr/lib/python3.8/site-packages/dnf/package.py:57: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats
+  return super(Package, self).chksum
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1724244
+---
+ python/hawkey/package-py.cpp  | 3 ++-
+ python/hawkey/packagedelta-py.cpp | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+---
+
+Unchanged.  Appears in version 0.35.2.
+
+Upstream-Status: Backport [git://github.com/rpm-software-management/libdnf.git]
+
+Signed-off-by: Joe Slater 
+
+
+diff --git a/python/hawkey/package-py.cpp b/python/hawkey/package-py.cpp
+index 5102bba..68e03cb 100644
+--- a/python/hawkey/package-py.cpp
 b/python/hawkey/package-py.cpp
+@@ -18,6 +18,7 @@
+  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
USA
+  */
+ 
++#define PY_SSIZE_T_CLEAN
+ #include 
+ #include 
+ 
+@@ -251,7 +252,7 @@ get_chksum(_PackageObject *self, void *closure)
+ #if PY_MAJOR_VERSION < 3
+ res = Py_BuildValue("is#", type, cs, checksum_length);
+ #else
+-res = Py_BuildValue("iy#", type, cs, checksum_length);
++res = Py_BuildValue("iy#", type, cs, (Py_ssize_t)checksum_length);
+ #endif
+ 
+ return res;
+diff --git a/python/hawkey/packagedelta-py.cpp 
b/python/hawkey/packagedelta-py.cpp
+index ca1cb7d..1a64836 100644
+--- a/python/hawkey/packagedelta-py.cpp
 b/python/hawkey/packagedelta-py.cpp
+@@ -18,6 +18,7 @@
+  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
USA
+  */
+ 
++#define PY_SSIZE_T_CLEAN
+ #include 
+ 
+ // hawkey
+@@ -92,7 +93,7 @@ get_chksum(_PackageDeltaObject *self, void *closure)
+ #if PY_MAJOR_VERSION < 3
+ res = Py_BuildValue("is#", type, cs, checksum_length);
+ #else
+-res = Py_BuildValue("iy#", type, cs, checksum_length);
++res = Py_BuildValue("iy#", type, cs, (Py_ssize_t)checksum_length);
+ #endif
+ 
+ return res;
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb 
b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
index d498347..163a2ee 100644
--- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
+++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
@@ -8,6 +8,7 @@ SRC_URI = "git://github.com/rpm-software-management/libdnf \

file://0001-Get-parameters-for-both-libsolv-and-libsolvext-libdn.patch \
file://0001-Add-WITH_TESTS-option.patch \
file://0001-include-stdexcept-for-runtime_error.patch \
+   file://fix-deprecation-warning.patch \
"
 
 SRCREV = "751f89045b80d58c0d05800f74357cf78cdf7e77"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pulseaudio: Fix inline assembly syntax for arm

[Khem Raj]

Ensures that gcc can use right operand constraints

Signed-off-by: Khem Raj 
---
 ...ap-arm-Adjust-inline-asm-constraints.patch | 114 ++
 .../pulseaudio/pulseaudio_13.0.bb |   1 +
 2 files changed, 115 insertions(+)
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch

diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch
 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch
new file mode 100644
index 00..95133fd9d4
--- /dev/null
+++ 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch
@@ -0,0 +1,114 @@
+From 3450d1fcfe8a8f84553ab299cd96ae0705ddffbe Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Thu, 5 Mar 2020 11:48:28 -0800
+Subject: [PATCH] remap/arm: Adjust inline asm constraints
+
+gcc10 can effectively emit single precision registers if right
+operand modifier constraint is not in use
+
+This results in assembler rejecting the code
+
+/tmp/ccEG4QpI.s:646: Error: VFP/Neon double precision register expected -- 
`vtbl.8 d3,{d0,d1},s8'
+/tmp/ccEG4QpI.s:678: Error: invalid instruction shape -- `vmul.f32 d0,d0,s8'
+
+Therefore add %P qualifier to request double registers sinece 'w' could
+mean variable could be stored in s0..s14 and GCC defaults to printing out 
s0..s14.
+Note those registers map to d0..d7 also.
+
+Output generated is exactly same with gcc9, and it also now compiles
+with gcc10
+
+Its not documented well in gcc docs and there is a ticket for that
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84343
+
+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/261]
+Signed-off-by: Khem Raj 
+---
+ src/pulsecore/remap_neon.c | 22 +++---
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/src/pulsecore/remap_neon.c b/src/pulsecore/remap_neon.c
+index 41208986d..ca3b95b48 100644
+--- a/src/pulsecore/remap_neon.c
 b/src/pulsecore/remap_neon.c
+@@ -189,7 +189,7 @@ static void remap_ch4_to_mono_float32ne_neon(pa_remap_t 
*m, float *dst, const fl
+ "vadd.f32   d0, d0, d1  \n\t"
+ "vadd.f32   d2, d2, d3  \n\t"
+ "vadd.f32   d0, d0, d2  \n\t"
+-"vmul.f32   d0, d0, %[quart]\n\t"
++"vmul.f32   d0, d0, %P[quart]   \n\t"
+ "vst1.32{d0}, [%[dst]]! \n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : [quart] "w" (quart) /* input operands */
+@@ -276,7 +276,7 @@ static void remap_arrange_stereo_s16ne_neon(pa_remap_t *m, 
int16_t *dst, const i
+ for (; n >= 2; n -= 2) {
+ __asm__ __volatile__ (
+ "vld1.s16   d0, [%[src]]!   \n\t"
+-"vtbl.8 d0, {d0}, %[t]  \n\t"
++"vtbl.8 d0, {d0}, %P[t] \n\t"
+ "vst1.s16   d0, [%[dst]]!   \n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : [t] "w" (t) /* input operands */
+@@ -287,7 +287,7 @@ static void remap_arrange_stereo_s16ne_neon(pa_remap_t *m, 
int16_t *dst, const i
+ if (n > 0) {
+ __asm__ __volatile__ (
+ "vld1.32   d0[0], [%[src]]! \n\t"
+-"vtbl.8d0, {d0}, %[t]   \n\t"
++"vtbl.8d0, {d0}, %P[t]  \n\t"
+ "vst1.32   d0[0], [%[dst]]! \n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : [t] "w" (t) /* input operands */
+@@ -302,8 +302,8 @@ static void remap_arrange_ch2_ch4_s16ne_neon(pa_remap_t 
*m, int16_t *dst, const
+ for (; n > 0; n--) {
+ __asm__ __volatile__ (
+ "vld1.32d0[0], [%[src]]!   \n\t"
+-"vtbl.8 d0, {d0}, %[t]  \n\t"
+-"vst1.s16   d0, [%[dst]]!   \n\t"
++"vtbl.8 d0, {d0}, %P[t]\n\t"
++"vst1.s16   d0, [%[dst]]!  \n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : [t] "w" (t) /* input operands */
+ : "memory", "d0" /* clobber list */
+@@ -317,7 +317,7 @@ static void remap_arrange_ch4_s16ne_neon(pa_remap_t *m, 
int16_t *dst, const int1
+ for (; n > 0; n--) {
+ __asm__ __volatile__ (
+ "vld1.s16   d0, [%[src]]!   \n\t"
+-"vtbl.8 d0, {d0}, %[t]  \n\t"
++"vtbl.8 d0, {d0}, %P[t] \n\t"
+ "vst1.s16   d0, [%[dst]]!   \n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : [t] "w" (t) /* input operands */
+@@ -332,7 +332,7 @@ static void remap_arrange_stereo_float32ne_neon(pa_remap_t 
*m, float *dst, const
+ for (; n > 0; n--) {
+ __asm__ __volatile__ (
+  

[OE-core] [PATCH][master-next] linux-firmware: also install / package all license files

[André Draszik]

This doesn't happen with make install, hence all the -license packages
are missing, since they'd otherwise be empty.

Signed-off-by: André Draszik 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
index f7198cb56a..6039dc9d71 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
@@ -209,6 +209,7 @@ do_compile() {
 
 do_install() {
 oe_runmake 'DESTDIR=${D}' install
+cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
 }
 
 
-- 
2.23.0.rc1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [master-next] linux-firmware: install / package all license files again

[André Draszik]

This doesn't happen with make install, hence all the -license packages
are missing, since they'd otherwise be empty.

Signed-off-by: André Draszik 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
index f7198cb56a..6039dc9d71 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
@@ -209,6 +209,7 @@ do_compile() {
 
 do_install() {
 oe_runmake 'DESTDIR=${D}' install
+cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
 }
 
 
-- 
2.23.0.rc1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] oeqa-runtime: add missing import os to ptest case

[Stefan Kral]

Add missing import os statement to the oeqa runtime ptest.py

Signed-off-by: Stefan Kral 
---
 meta/lib/oeqa/runtime/cases/ptest.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/runtime/cases/ptest.py 
b/meta/lib/oeqa/runtime/cases/ptest.py
index 5626f707b9..99a44f0767 100644
--- a/meta/lib/oeqa/runtime/cases/ptest.py
+++ b/meta/lib/oeqa/runtime/cases/ptest.py
@@ -2,6 +2,7 @@
 # SPDX-License-Identifier: MIT
 #
 
+import os
 import unittest
 import pprint
 import datetime
-- 
2.17.2 (Apple Git-113)

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-firmware: use 'make install' for installation

[Alexander Kanavin]

Maybe you could send a follow up patch then? I won’t get to it until
tomorrow.

Alex

On Thu 5. Mar 2020 at 17.56, André Draszik  wrote:

> On Thu, 2020-03-05 at 17:44 +0100, Alexander Kanavin wrote:
> > Right I think this should be easy to fix, we need to copy LICENSE.*
> manually. I'll get to it soon.
> >
>
> Keep in mind there's different spelling, and two more files :-)
> This works for me:
>
> +cp -r GPL-2 LICENCE.* LICENSE.* WHENCE
> ${D}${nonarch_base_libdir}/firmware/
>
>
> Cheers,
> A.
>
> > Alex
> >
> > On Thu, 5 Mar 2020 at 17:20, André Draszik  wrote:
> > > On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote:
> > > > Copying the source tree over was missing important symlinks
> > > > that since recent updates can only be created with make install.
> > >
> > > Thanks for the quick fix Alex, but unfortunately now all the -license
> packages
> > > are non-existent and image creation fails, because their install:
> target
> > > doesn't copy the license files.
> > >
> > > Cheers,
> > > Andre'
> > >
> > > >
> > > > Signed-off-by: Alexander Kanavin 
> > > > ---
> > > >  .../linux-firmware/linux-firmware_20200122.bb | 22
> +--
> > > >  1 file changed, 1 insertion(+), 21 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-kernel/linux-firmware/
> linux-firmware_20200122.bb b/meta/recipes-kernel/linux-
> > > firmware/linux-
> > > > firmware_20200122.bb
> > > > index 0d1422cfca..f7198cb56a 100644
> > > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> > > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> > > > @@ -208,27 +208,7 @@ do_compile() {
> > > >  }
> > > >
> > > >  do_install() {
> > > > - install -d  ${D}${nonarch_base_libdir}/firmware/
> > > > - cp -r * ${D}${nonarch_base_libdir}/firmware/
> > > > -
> > > > - # Avoid Makefile to be deployed
> > > > - rm ${D}${nonarch_base_libdir}/firmware/Makefile
> > > > -
> > > > - # Remove unbuild firmware which needs cmake and bash
> > > > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf
> > > > -
> > > > - # Remove pointless bash script
> > > > - rm ${D}${nonarch_base_libdir}/firmware/configure
> > > > -
> > > > - # Remove python script used to check the WHENCE file
> > > > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py
> > > > -
> > > > - # Libertas sd8686
> > > > - ln -sf libertas/sd8686_v9.bin
> ${D}${nonarch_base_libdir}/firmware/sd8686.bin
> > > > - ln -sf libertas/sd8686_v9_helper.bin
> ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin
> > > > -
> > > > - # fixup wl12xx location, after 2.6.37 the kernel searches a
> different location for it
> > > > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
> ti-connectivity/* . )
> > > > +oe_runmake 'DESTDIR=${D}' install
> > > >  }
> > > >
> > > >
> > > > --
> > > > 2.25.1
> > > >
> > >
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-firmware: use 'make install' for installation

[André Draszik]

On Thu, 2020-03-05 at 17:44 +0100, Alexander Kanavin wrote:
> Right I think this should be easy to fix, we need to copy LICENSE.* manually. 
> I'll get to it soon.
> 

Keep in mind there's different spelling, and two more files :-)
This works for me:

+cp -r GPL-2 LICENCE.* LICENSE.* WHENCE 
${D}${nonarch_base_libdir}/firmware/


Cheers,
A.

> Alex
> 
> On Thu, 5 Mar 2020 at 17:20, André Draszik  wrote:
> > On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote:
> > > Copying the source tree over was missing important symlinks
> > > that since recent updates can only be created with make install.
> > 
> > Thanks for the quick fix Alex, but unfortunately now all the -license 
> > packages
> > are non-existent and image creation fails, because their install: target
> > doesn't copy the license files.
> > 
> > Cheers,
> > Andre'
> > 
> > > 
> > > Signed-off-by: Alexander Kanavin 
> > > ---
> > >  .../linux-firmware/linux-firmware_20200122.bb | 22 +--
> > >  1 file changed, 1 insertion(+), 21 deletions(-)
> > > 
> > > diff --git 
> > > a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb 
> > > b/meta/recipes-kernel/linux-
> > firmware/linux-
> > > firmware_20200122.bb
> > > index 0d1422cfca..f7198cb56a 100644
> > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> > > @@ -208,27 +208,7 @@ do_compile() {
> > >  }
> > >  
> > >  do_install() {
> > > - install -d  ${D}${nonarch_base_libdir}/firmware/
> > > - cp -r * ${D}${nonarch_base_libdir}/firmware/
> > > -
> > > - # Avoid Makefile to be deployed
> > > - rm ${D}${nonarch_base_libdir}/firmware/Makefile
> > > -
> > > - # Remove unbuild firmware which needs cmake and bash
> > > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf
> > > -
> > > - # Remove pointless bash script
> > > - rm ${D}${nonarch_base_libdir}/firmware/configure
> > > -
> > > - # Remove python script used to check the WHENCE file
> > > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py
> > > -
> > > - # Libertas sd8686
> > > - ln -sf libertas/sd8686_v9.bin 
> > > ${D}${nonarch_base_libdir}/firmware/sd8686.bin
> > > - ln -sf libertas/sd8686_v9_helper.bin 
> > > ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin
> > > -
> > > - # fixup wl12xx location, after 2.6.37 the kernel searches a 
> > > different location for it
> > > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* 
> > > . )
> > > +oe_runmake 'DESTDIR=${D}' install
> > >  }
> > >  
> > >  
> > > -- 
> > > 2.25.1
> > > 
> > 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-firmware: use 'make install' for installation

[Alexander Kanavin]

Right I think this should be easy to fix, we need to copy LICENSE.*
manually. I'll get to it soon.

Alex

On Thu, 5 Mar 2020 at 17:20, André Draszik  wrote:

> On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote:
> > Copying the source tree over was missing important symlinks
> > that since recent updates can only be created with make install.
>
> Thanks for the quick fix Alex, but unfortunately now all the -license
> packages
> are non-existent and image creation fails, because their install: target
> doesn't copy the license files.
>
> Cheers,
> Andre'
>
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  .../linux-firmware/linux-firmware_20200122.bb | 22 +--
> >  1 file changed, 1 insertion(+), 21 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/linux-firmware/
> linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-
> > firmware_20200122.bb
> > index 0d1422cfca..f7198cb56a 100644
> > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> > @@ -208,27 +208,7 @@ do_compile() {
> >  }
> >
> >  do_install() {
> > - install -d  ${D}${nonarch_base_libdir}/firmware/
> > - cp -r * ${D}${nonarch_base_libdir}/firmware/
> > -
> > - # Avoid Makefile to be deployed
> > - rm ${D}${nonarch_base_libdir}/firmware/Makefile
> > -
> > - # Remove unbuild firmware which needs cmake and bash
> > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf
> > -
> > - # Remove pointless bash script
> > - rm ${D}${nonarch_base_libdir}/firmware/configure
> > -
> > - # Remove python script used to check the WHENCE file
> > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py
> > -
> > - # Libertas sd8686
> > - ln -sf libertas/sd8686_v9.bin
> ${D}${nonarch_base_libdir}/firmware/sd8686.bin
> > - ln -sf libertas/sd8686_v9_helper.bin
> ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin
> > -
> > - # fixup wl12xx location, after 2.6.37 the kernel searches a
> different location for it
> > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf
> ti-connectivity/* . )
> > +oe_runmake 'DESTDIR=${D}' install
> >  }
> >
> >
> > --
> > 2.25.1
> >
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] curl: upgrade 7.68.0 -> 7.69.0

[Pierre-Jean Texier via Openembedded-core]

Bugfix release. For details, see full changelog

 - https://curl.haxx.se/changes.html#7_69_0

Signed-off-by: Pierre-Jean Texier 
---
 meta/recipes-support/curl/{curl_7.68.0.bb => curl_7.69.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/curl/{curl_7.68.0.bb => curl_7.69.0.bb} (95%)

diff --git a/meta/recipes-support/curl/curl_7.68.0.bb 
b/meta/recipes-support/curl/curl_7.69.0.bb
similarity index 95%
rename from meta/recipes-support/curl/curl_7.68.0.bb
rename to meta/recipes-support/curl/curl_7.69.0.bb
index 0a1547c..cf4f4bc 100644
--- a/meta/recipes-support/curl/curl_7.68.0.bb
+++ b/meta/recipes-support/curl/curl_7.69.0.bb
@@ -9,8 +9,8 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
 "
 
-SRC_URI[md5sum] = "40d6784bd1a86e079d63cc668ba9bd8f"
-SRC_URI[sha256sum] = 
"207f54917dd6a2dc733065ccf18d61bb5bebeaceb5df49cd9445483e8623eeb9"
+SRC_URI[md5sum] = "04eb86d1138c2ff3dbfd497f7de85daa"
+SRC_URI[sha256sum] = 
"668d451108a7316cff040b23c79bc766e7ed84122074e44f662b8982f2e76739"
 
 CVE_PRODUCT = "curl libcurl"
 inherit autotools pkgconfig binconfig multilib_header
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-firmware: use 'make install' for installation

[André Draszik]

On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote:
> Copying the source tree over was missing important symlinks
> that since recent updates can only be created with make install.

Thanks for the quick fix Alex, but unfortunately now all the -license packages
are non-existent and image creation fails, because their install: target
doesn't copy the license files.

Cheers,
Andre'

> 
> Signed-off-by: Alexander Kanavin 
> ---
>  .../linux-firmware/linux-firmware_20200122.bb | 22 +--
>  1 file changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb 
> b/meta/recipes-kernel/linux-firmware/linux-
> firmware_20200122.bb
> index 0d1422cfca..f7198cb56a 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb
> @@ -208,27 +208,7 @@ do_compile() {
>  }
>  
>  do_install() {
> - install -d  ${D}${nonarch_base_libdir}/firmware/
> - cp -r * ${D}${nonarch_base_libdir}/firmware/
> -
> - # Avoid Makefile to be deployed
> - rm ${D}${nonarch_base_libdir}/firmware/Makefile
> -
> - # Remove unbuild firmware which needs cmake and bash
> - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf
> -
> - # Remove pointless bash script
> - rm ${D}${nonarch_base_libdir}/firmware/configure
> -
> - # Remove python script used to check the WHENCE file
> - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py
> -
> - # Libertas sd8686
> - ln -sf libertas/sd8686_v9.bin 
> ${D}${nonarch_base_libdir}/firmware/sd8686.bin
> - ln -sf libertas/sd8686_v9_helper.bin 
> ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin
> -
> - # fixup wl12xx location, after 2.6.37 the kernel searches a different 
> location for it
> - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* . )
> +oe_runmake 'DESTDIR=${D}' install
>  }
>  
>  
> -- 
> 2.25.1
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] mesa: updated to 20.0 release

[Nathan Hartman]

Updated mesa and mesa-gl recipes to 20.0 release.

The license checksum difference is due to a small change in the license
formatting. The asterisk for footnotes was changed to a '[1]'
See: 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/199572b65b7a03ffc887783e7f0f96f95bf1f99d

glxgears runs successfully at 60 fps on a rpi4.

Signed-off-by: Nathan Hartman 
---
 .../mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} | 0
 meta/recipes-graphics/mesa/mesa.inc   | 2 +-
 meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} | 4 ++--
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} (88%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb 
b/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb
rename to meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 54d7ea8961..b7ef496fdc 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -10,7 +10,7 @@ HOMEPAGE = "http://mesa3d.org;
 BUGTRACKER = "https://bugs.freedesktop.org;
 SECTION = "x11"
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://docs/license.html;md5=3a4999caf82cc503ac8b9e37c235782e"
+LIC_FILES_CHKSUM = 
"file://docs/license.html;md5=c1843d93c460bbf778d6037ce324f9f7"
 
 PE = "2"
 
diff --git a/meta/recipes-graphics/mesa/mesa_19.3.4.bb 
b/meta/recipes-graphics/mesa/mesa_20.0.0.bb
similarity index 88%
rename from meta/recipes-graphics/mesa/mesa_19.3.4.bb
rename to meta/recipes-graphics/mesa/mesa_20.0.0.bb
index 5f456c2429..2ed7ca2252 100644
--- a/meta/recipes-graphics/mesa/mesa_19.3.4.bb
+++ b/meta/recipes-graphics/mesa/mesa_20.0.0.bb
@@ -9,8 +9,8 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
"
 
-SRC_URI[md5sum] = "09e7700d9af511384d131fb77b5802cb"
-SRC_URI[sha256sum] = 
"1da467e6ae2799a517e242462331eafd29ae77d9872f3a845df81f7c308e8fe4"
+SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795"
+SRC_URI[sha256sum] = 
"bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34"
 
 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
 
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument

[Ricardo Ribalda Delgado]

Hi Paul,

On Thu, Mar 5, 2020 at 10:37 AM Paul Barker  wrote:
>
> On Wed,  4 Mar 2020 15:49:36 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > This option adds the content of a rootfs on a specific location on the
> > rootfs.
> >
> > It is very useful for making a partition that contains the rootfs for a
> > host and a target Eg:
> >
> > / -> Roofs for the host
> > /export/ -> Rootfs for the target (which will netboot)
> >
> > Although today we support making a partition for "/export" this might
> > not be compatible with some upgrade systems, or we might be limited by
> > the number of partitions.
> >
> > With this patch we can use something like:
> >
> > part / --source rootfs --embed-rootfs target-image /export --embed-rootfs 
> > target-image2 /export2
>
> I like this but it still leaves confusion between `--include-path` and
> --embed-rootfs` as they're similar but slightly different. Can we just modify
> `--include-path` to have this syntax?

I think they are different enough.

- include-path ads a file/folder
- embed-rootfs adds a rootfs, which is either a folder or a image.bb file.


>
> >
> > on the .wks file.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  scripts/lib/wic/help.py  |  8 
> >  scripts/lib/wic/ksparser.py  |  1 +
> >  scripts/lib/wic/partition.py |  1 +
> >  scripts/lib/wic/plugins/source/rootfs.py | 22 +-
> >  4 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
> > index 4d342fcf05..140dc504cd 100644
> > --- a/scripts/lib/wic/help.py
> > +++ b/scripts/lib/wic/help.py
> > @@ -979,6 +979,14 @@ DESCRIPTION
> >   copies. This option only has an effect with the 
> > rootfs
> >   source plugin.
> >
> > + --embed-rootfs: This option is specific to wic. It embeds a 
> > rootfs into
> > + the given path to the resulting image. The option
> > + contains two fields, the roofs and the path, 
> > separated
> > + by a space. The rootfs follows the same logic as 
> > the
> > + rootfs-dir argument. Multiple options can be 
> > provided
> > + in order to embed multiple rootfs. This option 
> > only has
> > + an effect with the rootfs source plugin.
> > +
> >   --extra-space: This option is specific to wic. It adds extra
> >  space after the space filled by the content
> >  of the partition. The final size can go
> > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
> > index 650b976223..64c8c1175e 100644
> > --- a/scripts/lib/wic/ksparser.py
> > +++ b/scripts/lib/wic/ksparser.py
> > @@ -138,6 +138,7 @@ class KickStart():
> >  part.add_argument('--align', type=int)
> >  part.add_argument('--exclude-path', nargs='+')
> >  part.add_argument('--include-path', nargs='+')
> > +part.add_argument('--embed-rootfs', nargs=2, action='append')
> >  part.add_argument("--extra-space", type=sizetype)
> >  part.add_argument('--fsoptions', dest='fsopts')
> >  part.add_argument('--fstype', default='vfat',
> > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> > index 2d95f78439..13857df82f 100644
> > --- a/scripts/lib/wic/partition.py
> > +++ b/scripts/lib/wic/partition.py
> > @@ -31,6 +31,7 @@ class Partition():
> >  self.extra_space = args.extra_space
> >  self.exclude_path = args.exclude_path
> >  self.include_path = args.include_path
> > +self.embed_rootfs = args.embed_rootfs
> >  self.fsopts = args.fsopts
> >  self.fstype = args.fstype
> >  self.label = args.label
> > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > b/scripts/lib/wic/plugins/source/rootfs.py
> > index 40419a64b3..089aaea477 100644
> > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > +++ b/scripts/lib/wic/plugins/source/rootfs.py
> > @@ -17,6 +17,7 @@ import shutil
> >  import sys
> >
> >  from oe.path import copyhardlinktree, copytree
> > +from pathlib import Path
> >
> >  from wic import WicError
> >  from wic.pluginbase import SourcePlugin
> > @@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlugin):
> >
> >  new_rootfs = None
> >  # Handle excluded paths.
> > -if part.exclude_path or part.include_path:
> > +if part.exclude_path or part.include_path or part.embed_rootfs:
> >  # We need a new rootfs directory we can delete files from. 
> > Copy to
> >  # workdir.
> >  new_rootfs = os.path.realpath(os.path.join(cr_workdir, 
> > "rootfs%d" % part.lineno))
> > @@ -100,6 +101,25 @@ class RootfsPlugin(SourcePlugin):
> >  for path in part.include_path or []:
> >  copyhardlinktree(path, new_rootfs)
> 

[OE-core] [PATCH v2] babeltrace2: added first version, 2.0.1

[Anders Wallin]

Babeltrace 1 vs. Babeltrace 2

The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was released.
Babeltrace 2 is a complete rewrite of the library, Python bindings, and CLI. It
is plugin based and offers much more features and potential than Babeltrace 1.

Because Babeltrace 2 is still a young released project, some distributions still
provide packages for the Babeltrace 1 project. Both projects can coexist on the
same system as there are no common installed files.

Signed-off-by: Anders Wallin 
---
 meta/conf/distro/include/distro_alias.inc |  1 +
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../distro/include/ptest-packagelists.inc |  1 +
 .../packagegroup-core-tools-profile.bb|  2 +
 ...not-run-test-applications-from-.libs.patch | 28 ++
 .../lttng/babeltrace2/run-ptest   |  9 ++
 .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 92 +++
 7 files changed, 134 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch
 create mode 100755 meta/recipes-kernel/lttng/babeltrace2/run-ptest
 create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb

diff --git a/meta/conf/distro/include/distro_alias.inc 
b/meta/conf/distro/include/distro_alias.inc
index 79ebcaee29..0e4a9a9f8f 100644
--- a/meta/conf/distro/include/distro_alias.inc
+++ b/meta/conf/distro/include/distro_alias.inc
@@ -15,6 +15,7 @@ DISTRO_PN_ALIAS_pn-alsa-utils-scripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk"
 DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover"
 DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT"
+DISTRO_PN_ALIAS_pn-babeltrace2 = "OSPDT"
 DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debian=bjam"
 DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool"
 DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez  Opensuse=bluez"
diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 10095ffe76..adb18228e7 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -59,6 +59,7 @@ RECIPE_MAINTAINER_pn-automake = "Robert Yang 
"
 RECIPE_MAINTAINER_pn-avahi = "Yi Zhao "
 RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao "
 RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin "
+RECIPE_MAINTAINER_pn-babeltrace2 = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-base-files = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-base-passwd = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-bash = "Hongxu Jia "
diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index 4afac58e3a..d6f3aafc7f 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -64,6 +64,7 @@ PTESTS_FAST = "\
 
 PTESTS_SLOW = "\
 babeltrace-ptest \
+babeltrace2-ptest \
 busybox-ptest \
 dbus-test-ptest \
 e2fsprogs-ptest \
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 984c2fac92..ac180b542a 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -46,6 +46,7 @@ LTTNGMODULES = "lttng-modules"
 LTTNGMODULES_arc = ""
 
 BABELTRACE = "babeltrace"
+BABELTRACE2 = "babeltrace2"
 
 # valgrind does not work on the following configurations/architectures
 
@@ -69,6 +70,7 @@ RDEPENDS_${PN} = "\
 ${LTTNGTOOLS} \
 ${LTTNGMODULES} \
 ${BABELTRACE} \
+${BABELTRACE2} \
 ${SYSTEMTAP} \
 ${VALGRIND} \
 "
diff --git 
a/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch
 
b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch
new file mode 100644
index 00..805dde8064
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch
@@ -0,0 +1,28 @@
+From 582713cc9a013481eeef253195d644020f637ec4 Mon Sep 17 00:00:00 2001
+Message-Id: 
<582713cc9a013481eeef253195d644020f637ec4.1583403622.git.walli...@gmail.com>
+From: Anders Wallin 
+Date: Thu, 5 Mar 2020 11:20:04 +0100
+Subject: [PATCH] tests: do not run test applications from .libs
+
+Cross compile specific change
+
+Upstream-Status: Inappropriate [oe-core specific]
+
+Signed-off-by: Anders Wallin 
+---
+ tests/lib/test_plugin | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/lib/test_plugin b/tests/lib/test_plugin
+index 652c90cc..1f817c50 100755
+--- a/tests/lib/test_plugin
 b/tests/lib/test_plugin
+@@ -26,4 +26,4 @@ fi
+ # shellcheck source=../utils/utils.sh
+ source "$UTILSSH"
+ 
+-"${BT_TESTS_BUILDDIR}/lib/plugin" 
"${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins/.libs"
++"${BT_TESTS_BUILDDIR}/lib/plugin" 
"${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins"
+-- 
+2.25.1
+
diff --git 

[OE-core] [PATCH RESEND] openssl: pass PERL=perl environment variable to configurator

[Ruslan Bilovol via Openembedded-core]

In our build environment we use wrapper script
for perl in non-standard configuration with
extra variables set (provided by custom
buildtools-tarball).

In this case openssl fails to build because
by default it's Configure script detects and uses
perl executable directly (with absolute path)
obviously missing extra settings from wrapper
script.

Pass PERL=perl environment variable to Configure,
so it won't try to use perl executable directly
but will use what is provided from environment.

Signed-off-by: Ruslan Bilovol 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index c2ba005f47..d4871fe973 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -123,7 +123,7 @@ do_configure () {
fi
# WARNING: do not set compiler/linker flags (-I/-D etc.) in 
EXTRA_OECONF, as they will fully replace the
# environment variables set by bitbake. Adjust the environment 
variables instead.
-   PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
+   PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} 
--prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target
perl ${B}/configdata.pm --dump
 }
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: pass PERL=perl environment variable to configurator

[Ruslan Bilovol via Openembedded-core]

It seems this patch was forgotten and master moved forward.

Will resend it from latest master

Thanks,
Ruslan

On 12/21/18 11:33 PM, Ruslan Bilovol wrote:

In our build environment we use wrapper script
for perl in non-standard configuration with
extra variables set (provided by custom
buildtools-tarball).

In this case openssl fails to build because
by default it's Configure script detects and uses
perl executable directly (with absolute path)
obviously missing extra settings from wrapper
script.

Pass PERL=perl environment variable to Configure,
so it won't try to use perl executable directly
but will use what is provided from environment.

Signed-off-by: Ruslan Bilovol 
---
  meta/recipes-connectivity/openssl/openssl_1.1.1a.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
index 5c4e69c..6a72b5c 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
@@ -112,7 +112,7 @@ do_configure () {
fi
# WARNING: do not set compiler/linker flags (-I/-D etc.) in 
EXTRA_OECONF, as they will fully replace the
# environment variables set by bitbake. Adjust the environment 
variables instead.
-   PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
+   PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} 
--prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target
perl ${B}/configdata.pm --dump
  }


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] netbase: Upgrade to 6.1

[mingli.yu]

From: Mingli Yu 

Signed-off-by: Mingli Yu 
---
 meta/recipes-core/netbase/{netbase_6.0.bb => netbase_6.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-core/netbase/{netbase_6.0.bb => netbase_6.1.bb} (82%)

diff --git a/meta/recipes-core/netbase/netbase_6.0.bb 
b/meta/recipes-core/netbase/netbase_6.1.bb
similarity index 82%
rename from meta/recipes-core/netbase/netbase_6.0.bb
rename to meta/recipes-core/netbase/netbase_6.1.bb
index 2fb5762..bc0049c 100644
--- a/meta/recipes-core/netbase/netbase_6.0.bb
+++ b/meta/recipes-core/netbase/netbase_6.1.bb
@@ -8,8 +8,8 @@ PE = "1"
 
 SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz"
 
-SRC_URI[md5sum] = "3417b0487161f1a2b070a3308cd7f957"
-SRC_URI[sha256sum] = 
"692baeb7b76eba5580c7edbc97ce1784a06b5aa4b367c5ed0b39e0ce7a97d594"
+SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55"
+SRC_URI[sha256sum] = 
"084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8"
 
 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

Re: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path

[Ricardo Ribalda Delgado]

Hi Paul

On Thu, Mar 5, 2020 at 10:32 AM Paul Barker  wrote:
>
> On Wed, 4 Mar 2020 11:02:47 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > Hi Paul
> >
> > On Wed, Mar 4, 2020 at 10:53 AM Paul Barker  wrote:
> > >
> > > On Wed,  4 Mar 2020 09:34:37 +0100
> > > Ricardo Ribalda Delgado  wrote:
> > >
> > > > When parameters include_path or exclude_path are passed to the rootfs
> > > > plugin, it will copy the partition content into a folder and make all
> > > > the modifications there.
> > > >
> > > > This is done using copyhardlinktree(), which does not take into
> > > > consideration the content of the pseudo folder, which contains the
> > > > information about the right permissions and ownership of the folders.
> > >
> > > How are you running wic here? In the do_image_wic task it's executed under
> > > pseudo so all this is handled already. Executing wic outside of bitbake 
> > > may
> > > need some more testing here.
> >
> > I am running wic outside bitbake. But even if it is run under bitbake,
> > it should also fail. The pseudo directory needs to be present on the
> > target image
>
> If you're running wic outside of bitbake, is there any guarantee that pseudo
> is available?

Yes, the same guarantee that the ext3_tools are available. So I
believe we are safe here. Actually in my docker pseudo is not
installed and when I invoke with wic, everything is fine.

>
> >
> > >
> > > >
> > > > This results in a rootfs owned by the user that is running the wic
> > > > command (usually UID 1000), which makes some rootfs unbootable.
> > > >
> > > > To fix this we copy the content of the pseudo folders to the new folder
> > > > and modify the pseudo database using the "pseudo -B" command.
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > > ---
> > > >  scripts/lib/wic/plugins/source/rootfs.py | 22 +++---
> > > >  1 file changed, 19 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > > > b/scripts/lib/wic/plugins/source/rootfs.py
> > > > index 705aeb5563..40419a64b3 100644
> > > > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py
> > > > @@ -16,11 +16,11 @@ import os
> > > >  import shutil
> > > >  import sys
> > > >
> > > > -from oe.path import copyhardlinktree
> > > > +from oe.path import copyhardlinktree, copytree
> > > >
> > > >  from wic import WicError
> > > >  from wic.pluginbase import SourcePlugin
> > > > -from wic.misc import get_bitbake_var
> > > > +from wic.misc import get_bitbake_var, exec_native_cmd
> > > >
> > > >  logger = logging.getLogger('wic')
> > > >
> > > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin):
> > > >
> > > >  return os.path.realpath(image_rootfs_dir)
> > > >
> > > > +@staticmethod
> > > > +def __get_pseudo(native_sysroot, rootfs):
> > > > +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> > > > +pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % 
> > > > os.path.join(rootfs, "../pseudo")
> > > > +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs
> > > > +pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
> > > > +pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
> > > > +return pseudo
> > > > +
> > > >  @classmethod
> > > >  def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
> > > >   oe_builddir, bootimg_dir, kernel_dir,
> > > > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin):
> > > >
> > > >  if os.path.lexists(new_rootfs):
> > > >  shutil.rmtree(os.path.join(new_rootfs))
> > > > -
> > > >  copyhardlinktree(part.rootfs_dir, new_rootfs)
> > > >
> > > > +if os.path.lexists(os.path.join(new_rootfs, "../pseudo")):
> > > > +shutil.rmtree(os.path.join(new_rootfs, "../pseudo"))
> > > > +copytree(os.path.join(part.rootfs_dir, "../pseudo"),
> > > > + os.path.join(new_rootfs, "../pseudo"))
> > >
> > > I don't like stepping up the directory tree like this. We should be more
> > > explicit with the paths.
> >
> > You are thinking on:
> > os.path.dirname(directory)
>
> No, I'm wondering why we're taking a step up the directory tree from
> `part.rootfs_dir`. I can point that at any path using the `--rootfs-dir`
> argument and there's no guarantee that ../pseudo exists or is relevant to the
> path I gave to `--rootfs-dir`.

Because we are asuming that the rootfs is being generated with
OE/yocto, and there is where the pseudo folder lives.
It is the same asumption part.prepare_rootfs() is taking.

>
> >
> > >
> > > > +pseudo_cmd = "%s -B -m %s -M %s" % 
> > > > (cls.__get_pseudo(native_sysroot,new_rootfs),
> > > > +part.rootfs_dir, 
> > > > new_rootfs)
> > > > +exec_native_cmd(pseudo_cmd, native_sysroot)
> > > > +
> > > >  for path in part.include_path or []:
> > > >   

Re: [OE-core] [PATCH] bitbake: gitsm: download submodules

[Paul Barker]

On Wed, 4 Mar 2020 12:30:10 +
"Freihofer, Adrian"  wrote:

> -Original Message-
> From: Paul Barker 
> To: "Freihofer, Adrian" 
> Cc: openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] [PATCH] bitbake: gitsm: download submodules
> Date: Wed, 04 Mar 2020 09:59:44 +
> 
> On Wed, 4 Mar 2020 08:12:27 +
> "Freihofer, Adrian"  wrote:
> 
> > The unpack function failed because the submodules were not
> > downloaded.
> > Calling download before unpack for each submodule solves this issue.
> > 
> > Signed-off-by: Adrian Freihofer 
> > ---
> >  bitbake/lib/bb/fetch2/gitsm.py | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/bitbake/lib/bb/fetch2/gitsm.py
> > b/bitbake/lib/bb/fetch2/gitsm.py
> > index c622771d21..3715e9824f 100644
> > --- a/bitbake/lib/bb/fetch2/gitsm.py
> > +++ b/bitbake/lib/bb/fetch2/gitsm.py
> > @@ -184,6 +184,7 @@ class GitSM(Git):
> >  
> >  try:
> >  newfetch = Fetch([url], d, cache=False)
> > +newfetch.download()
> >  newfetch.unpack(root=os.path.dirname(os.path.join(re
> > po
> > _conf, 'modules', module)))
> >  except Exception as e:
> >  logger.error('gitsm: submodule unpack failed: %s %s'
> > %
> > (type(e).__name__, str(e)))  
> 
> You shouldn't be trying to download submodules in the do_unpack step.
> If
> they're missing at this stage it probably indicates a fetch issue.
> 
> Basically true, but the information about which submodules need to be
> downloaded is not available before the top level repo has been
> unpacked. I guess the solution must be something like:
> 
> fetch top-level
> unpack top-level
> foreach submodule:
>   fetch submodule
>   unpack submodule
> 
> What's the exact error that you're seeing?
> 
> Don't remeber exactly. But when I debugged the flow, it became obvious,
> that the submodules are not downloaded.
> 
> This could be related to the issue I saw when the fetcher uses git
> shallow
> tarballs from a mirror - if that's the case I'm planning to get that
> fixed
> this weekend.
> 
> Yes, the problem occurs with git shallows. The patch solves it with and
> without shallows for us.
> 
> Also, your email client seems to have chewed the patch up. It's best to
> send
> patches using `git send-email` only.
> 
> Sorry, we switched to a new e-mail solution. I have to adapt my setup.

The problem with your patch is that it would require network access during
do_unpack which then breaks our ability to do offline builds.

Do you only see this issue when fetching from git shallow mirror tarballs? If
so, the mirror tarballs need to be extracted during do_fetch but not placed
in the usual 'git2' directory (as future fetches can't cope with shallow
clones in that directory).

Fixing this also has some impact on archiver.bbclass as that also needs to be
able to walk the tree of submodules correctly.

-- 
Paul Barker
Konsulko Group
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument

[Paul Barker]

On Wed,  4 Mar 2020 15:49:36 +0100
Ricardo Ribalda Delgado  wrote:

> This option adds the content of a rootfs on a specific location on the
> rootfs.
> 
> It is very useful for making a partition that contains the rootfs for a
> host and a target Eg:
> 
> / -> Roofs for the host
> /export/ -> Rootfs for the target (which will netboot)
> 
> Although today we support making a partition for "/export" this might
> not be compatible with some upgrade systems, or we might be limited by
> the number of partitions.
> 
> With this patch we can use something like:
> 
> part / --source rootfs --embed-rootfs target-image /export --embed-rootfs 
> target-image2 /export2

I like this but it still leaves confusion between `--include-path` and
--embed-rootfs` as they're similar but slightly different. Can we just modify
`--include-path` to have this syntax?

> 
> on the .wks file.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  scripts/lib/wic/help.py  |  8 
>  scripts/lib/wic/ksparser.py  |  1 +
>  scripts/lib/wic/partition.py |  1 +
>  scripts/lib/wic/plugins/source/rootfs.py | 22 +-
>  4 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
> index 4d342fcf05..140dc504cd 100644
> --- a/scripts/lib/wic/help.py
> +++ b/scripts/lib/wic/help.py
> @@ -979,6 +979,14 @@ DESCRIPTION
>   copies. This option only has an effect with the 
> rootfs
>   source plugin.
>  
> + --embed-rootfs: This option is specific to wic. It embeds a rootfs 
> into
> + the given path to the resulting image. The option
> + contains two fields, the roofs and the path, 
> separated
> + by a space. The rootfs follows the same logic as the
> + rootfs-dir argument. Multiple options can be 
> provided
> + in order to embed multiple rootfs. This option only 
> has
> + an effect with the rootfs source plugin.
> +
>   --extra-space: This option is specific to wic. It adds extra
>  space after the space filled by the content
>  of the partition. The final size can go
> diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
> index 650b976223..64c8c1175e 100644
> --- a/scripts/lib/wic/ksparser.py
> +++ b/scripts/lib/wic/ksparser.py
> @@ -138,6 +138,7 @@ class KickStart():
>  part.add_argument('--align', type=int)
>  part.add_argument('--exclude-path', nargs='+')
>  part.add_argument('--include-path', nargs='+')
> +part.add_argument('--embed-rootfs', nargs=2, action='append')
>  part.add_argument("--extra-space", type=sizetype)
>  part.add_argument('--fsoptions', dest='fsopts')
>  part.add_argument('--fstype', default='vfat',
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 2d95f78439..13857df82f 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -31,6 +31,7 @@ class Partition():
>  self.extra_space = args.extra_space
>  self.exclude_path = args.exclude_path
>  self.include_path = args.include_path
> +self.embed_rootfs = args.embed_rootfs
>  self.fsopts = args.fsopts
>  self.fstype = args.fstype
>  self.label = args.label
> diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> b/scripts/lib/wic/plugins/source/rootfs.py
> index 40419a64b3..089aaea477 100644
> --- a/scripts/lib/wic/plugins/source/rootfs.py
> +++ b/scripts/lib/wic/plugins/source/rootfs.py
> @@ -17,6 +17,7 @@ import shutil
>  import sys
>  
>  from oe.path import copyhardlinktree, copytree
> +from pathlib import Path
>  
>  from wic import WicError
>  from wic.pluginbase import SourcePlugin
> @@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlugin):
>  
>  new_rootfs = None
>  # Handle excluded paths.
> -if part.exclude_path or part.include_path:
> +if part.exclude_path or part.include_path or part.embed_rootfs:
>  # We need a new rootfs directory we can delete files from. Copy 
> to
>  # workdir.
>  new_rootfs = os.path.realpath(os.path.join(cr_workdir, 
> "rootfs%d" % part.lineno))
> @@ -100,6 +101,25 @@ class RootfsPlugin(SourcePlugin):
>  for path in part.include_path or []:
>  copyhardlinktree(path, new_rootfs)
>  
> +for embed in part.embed_rootfs or []:
> +[embed_rootfs, path] = embed
> +#we need to remove the initial / for os.path.join to work
> +if os.path.isabs(path):
> +path = path[1:]
> +if embed_rootfs in krootfs_dir:
> +embed_rootfs = krootfs_dir[embed_rootfs]
> +embed_rootfs = 

Re: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path

[Paul Barker]

On Wed, 4 Mar 2020 11:02:47 +0100
Ricardo Ribalda Delgado  wrote:

> Hi Paul
> 
> On Wed, Mar 4, 2020 at 10:53 AM Paul Barker  wrote:
> >
> > On Wed,  4 Mar 2020 09:34:37 +0100
> > Ricardo Ribalda Delgado  wrote:
> >  
> > > When parameters include_path or exclude_path are passed to the rootfs
> > > plugin, it will copy the partition content into a folder and make all
> > > the modifications there.
> > >
> > > This is done using copyhardlinktree(), which does not take into
> > > consideration the content of the pseudo folder, which contains the
> > > information about the right permissions and ownership of the folders.  
> >
> > How are you running wic here? In the do_image_wic task it's executed under
> > pseudo so all this is handled already. Executing wic outside of bitbake may
> > need some more testing here.  
> 
> I am running wic outside bitbake. But even if it is run under bitbake,
> it should also fail. The pseudo directory needs to be present on the
> target image

If you're running wic outside of bitbake, is there any guarantee that pseudo
is available?

> 
> >  
> > >
> > > This results in a rootfs owned by the user that is running the wic
> > > command (usually UID 1000), which makes some rootfs unbootable.
> > >
> > > To fix this we copy the content of the pseudo folders to the new folder
> > > and modify the pseudo database using the "pseudo -B" command.
> > >
> > > Signed-off-by: Ricardo Ribalda Delgado 
> > > ---
> > >  scripts/lib/wic/plugins/source/rootfs.py | 22 +++---
> > >  1 file changed, 19 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > > b/scripts/lib/wic/plugins/source/rootfs.py
> > > index 705aeb5563..40419a64b3 100644
> > > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > > +++ b/scripts/lib/wic/plugins/source/rootfs.py
> > > @@ -16,11 +16,11 @@ import os
> > >  import shutil
> > >  import sys
> > >
> > > -from oe.path import copyhardlinktree
> > > +from oe.path import copyhardlinktree, copytree
> > >
> > >  from wic import WicError
> > >  from wic.pluginbase import SourcePlugin
> > > -from wic.misc import get_bitbake_var
> > > +from wic.misc import get_bitbake_var, exec_native_cmd
> > >
> > >  logger = logging.getLogger('wic')
> > >
> > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin):
> > >
> > >  return os.path.realpath(image_rootfs_dir)
> > >
> > > +@staticmethod
> > > +def __get_pseudo(native_sysroot, rootfs):
> > > +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> > > +pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % 
> > > os.path.join(rootfs, "../pseudo")
> > > +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs
> > > +pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
> > > +pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
> > > +return pseudo
> > > +
> > >  @classmethod
> > >  def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
> > >   oe_builddir, bootimg_dir, kernel_dir,
> > > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin):
> > >
> > >  if os.path.lexists(new_rootfs):
> > >  shutil.rmtree(os.path.join(new_rootfs))
> > > -
> > >  copyhardlinktree(part.rootfs_dir, new_rootfs)
> > >
> > > +if os.path.lexists(os.path.join(new_rootfs, "../pseudo")):
> > > +shutil.rmtree(os.path.join(new_rootfs, "../pseudo"))
> > > +copytree(os.path.join(part.rootfs_dir, "../pseudo"),
> > > + os.path.join(new_rootfs, "../pseudo"))  
> >
> > I don't like stepping up the directory tree like this. We should be more
> > explicit with the paths.  
> 
> You are thinking on:
> os.path.dirname(directory)

No, I'm wondering why we're taking a step up the directory tree from
`part.rootfs_dir`. I can point that at any path using the `--rootfs-dir`
argument and there's no guarantee that ../pseudo exists or is relevant to the
path I gave to `--rootfs-dir`.

> 
> >  
> > > +pseudo_cmd = "%s -B -m %s -M %s" % 
> > > (cls.__get_pseudo(native_sysroot,new_rootfs),
> > > +part.rootfs_dir, 
> > > new_rootfs)
> > > +exec_native_cmd(pseudo_cmd, native_sysroot)
> > > +
> > >  for path in part.include_path or []:
> > >  copyhardlinktree(path, new_rootfs)  
> >
> >
> >
> > If this is the right approach I imagine you would also need to fix things up
> > with pseudo after the copyhardlinktree call above.  
> 
> I do not think it is needed. include_path does not contain its own
> pseudo directory

That's not necessarily true. The include_path could have been built by Yocto
using pseudo.

I can see that there is an issue using these arguments to wic outside of
bitbake but I'm not sure this is the correct solution.

-- 
Paul Barker
Konsulko Group
-- 
___