Re: [OE-core] [PATCH 1/1] util-linux: upgrade to 2.33.2

[ChenQi]

On 06/12/2019 01:43 PM, Adrian Bunk wrote:

On Wed, Jun 12, 2019 at 10:06:33AM +0800, Chen Qi wrote:

The license files' names are changed, but the contents remain the
same.

Signed-off-by: Chen Qi 
---
  meta/recipes-core/util-linux/util-linux.inc  | 16 
  .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb}   |  4 ++--
  2 files changed, 10 insertions(+), 10 deletions(-)
  rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
util-linux_2.33.2.bb} (72%)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 7b9b4d2..eaaf408 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -8,15 +8,15 @@ SECTION = "base"
  
  LICENSE = "GPLv2+ & LGPLv2.1+ & BSD"

...
-
file://Documentation/licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262 \
...
+
file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
 \
...

Doesn't this mean that LICENSE is (and already was before) wrong?

meta/files/common-licenses/BSD is the 3 clause BSD licence,
but this is the 4 clause licence (with the advertising clause).

cu
Adrian


Thanks. I've changed this in V2.

Best Regards,

Chen Qi

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

[OE-core] [PATCH V2 1/1] util-linux: upgrade to 2.33.2

[Chen Qi]

The license files' names are changed, but the contents remain the
same. However, the LICENSE section of the recipe was wrong. This
upgrade change the 'BSD' part to 'BSD-3-Clause & BSD-4-Clause'.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/util-linux/util-linux.inc| 18 +-
 .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb} |  4 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)
 rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
util-linux_2.33.2.bb} (72%)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 7b9b4d2..df1d122 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -6,17 +6,17 @@ disk partitioning, kernel message management, filesystem 
creation, and system lo
 
 SECTION = "base"
 
-LICENSE = "GPLv2+ & LGPLv2.1+ & BSD"
+LICENSE = "GPLv2+ & LGPLv2.1+ & BSD-3-Clause & BSD-4-Clause"
 
-LIC_FILES_CHKSUM = 
"file://README.licensing;md5=1715f5ee3e01203ca1e1e0b9ee65918c \
+LIC_FILES_CHKSUM = 
"file://README.licensing;md5=972a134f1e14b2b060e365df2fab0099 \
 file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-
file://Documentation/licenses/COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263
 \
-
file://Documentation/licenses/COPYING.LGPLv2.1;md5=4fbd65380cdd255951079008b364516c
 \
-
file://Documentation/licenses/COPYING.BSD-3;md5=58dcd8452651fc8b07d1f65ce07ca8af
 \
-
file://Documentation/licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262 \
-
file://libuuid/COPYING;md5=b442ffb762cf8d3e9df1b99e0bb4af70 \
-
file://libmount/COPYING;md5=fb93f01d4361069c5616327705373b16 \
-
file://libblkid/COPYING;md5=fb93f01d4361069c5616327705373b16"
+
file://Documentation/licenses/COPYING.GPL-2.0-or-later;md5=b234ee4d69f5fce4486a80fdaf4a4263
 \
+
file://Documentation/licenses/COPYING.LGPL-2.1-or-later;md5=4fbd65380cdd255951079008b364516c
 \
+
file://Documentation/licenses/COPYING.BSD-3-Clause;md5=58dcd8452651fc8b07d1f65ce07ca8af
 \
+
file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
 \
+
file://libuuid/COPYING;md5=6d2cafc999feb2c2de84d4d24b23290c \
+
file://libmount/COPYING;md5=7c7e39fb7d70ffe5d693a643e29987c2 \
+
file://libblkid/COPYING;md5=693bcbbe16d3a4a4b37bc906bc01cc04"
 
 #gtk-doc is not enabled as it requires xmlto which requires util-linux
 inherit autotools gettext manpages pkgconfig systemd update-alternatives 
python3-dir bash-completion ptest
diff --git a/meta/recipes-core/util-linux/util-linux_2.32.1.bb 
b/meta/recipes-core/util-linux/util-linux_2.33.2.bb
similarity index 72%
rename from meta/recipes-core/util-linux/util-linux_2.32.1.bb
rename to meta/recipes-core/util-linux/util-linux_2.33.2.bb
index e0bd383..538e276 100644
--- a/meta/recipes-core/util-linux/util-linux_2.32.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.33.2.bb
@@ -9,5 +9,5 @@ SRC_URI += "file://configure-sbindir.patch \
 file://avoid_parallel_tests.patch \
 file://check-for-_HAVE_STRUCT_TERMIOS_C_OSPEED.patch \
 "
-SRC_URI[md5sum] = "9e5b1b8c1dc99455bdb6b462cf9436d9"
-SRC_URI[sha256sum] = 
"86e6707a379c7ff5489c218cfaf1e3464b0b95acf7817db0bc5f179e356a67b2"
+SRC_URI[md5sum] = "91653b90fcbe9c161153e39b8cc69fb5"
+SRC_URI[sha256sum] = 
"631be8eac6cf6230ba478de211941d526808dba3cd436380793334496013ce97"
-- 
1.9.1

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

[OE-core] [PATCH V2 0/1] util-linux: upgrade to 2.33.2

[Chen Qi]

Changes in V2:
* LICENSE changed to 'BSD-3-Clause & BSD-4-Clause' from 'BSD'

The following changes since commit 9e5a3f40caa37141d292c6dd5914d4670ab57aff:

  bitbake: cooker: Ensure mcdeps are processed even if only one multiconfig 
(2019-06-11 13:27:19 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/util-linux-2.33.2
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/util-linux-2.33.2

Chen Qi (1):
  util-linux: upgrade to 2.33.2

 meta/recipes-core/util-linux/util-linux.inc| 18 +-
 .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb} |  4 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)
 rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
util-linux_2.33.2.bb} (72%)

-- 
1.9.1

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

Re: [OE-core] [PATCH 1/1] util-linux: upgrade to 2.33.2

[Adrian Bunk]

On Wed, Jun 12, 2019 at 10:06:33AM +0800, Chen Qi wrote:
> The license files' names are changed, but the contents remain the
> same.
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-core/util-linux/util-linux.inc  | 16 
> 
>  .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb}   |  4 ++--
>  2 files changed, 10 insertions(+), 10 deletions(-)
>  rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
> util-linux_2.33.2.bb} (72%)
> 
> diff --git a/meta/recipes-core/util-linux/util-linux.inc 
> b/meta/recipes-core/util-linux/util-linux.inc
> index 7b9b4d2..eaaf408 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -8,15 +8,15 @@ SECTION = "base"
>  
>  LICENSE = "GPLv2+ & LGPLv2.1+ & BSD"
>...
> -
> file://Documentation/licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262
>  \
>...
> +
> file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
>  \
>...

Doesn't this mean that LICENSE is (and already was before) wrong?

meta/files/common-licenses/BSD is the 3 clause BSD licence,
but this is the 4 clause licence (with the advertising clause).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] [PATCH] mtd-utils: upgrade 2.0.2 -> 2.1.0

[Adrian Bunk]

On Tue, Jun 11, 2019 at 05:41:52PM -0400, Denys Dmytriyenko wrote:
>...
> * Now requires openssl:
> | In file included from ../git/ubifs-utils/mkfs.ubifs/mkfs.ubifs.c:25:
> | ../git/ubifs-utils/mkfs.ubifs/mkfs.ubifs.h:49:10: fatal error: 
> openssl/rand.h: No such file or directory
> |  #include 
> |   ^~~~
> | compilation terminated.
> | Makefile:3457: recipe for target 
> 'ubifs-utils/mkfs.ubifs/mkfs_ubifs-mkfs.ubifs.o' failed
> | make: *** [ubifs-utils/mkfs.ubifs/mkfs_ubifs-mkfs.ubifs.o] Error 1
>...
> -DEPENDS = "zlib e2fsprogs util-linux"
> +DEPENDS = "zlib e2fsprogs util-linux openssl"

It doesn't (and should not) require it unconditionally.

Please backport "mkfs.ubifs: fix build without openssl" from
upstream git instead.

>...
> -PV = "2.0.2+${SRCPV}"
> +PV = "2.1.0+${SRCPV}"
>...

This was already wrong before but now is an opportunity to fix:
Since this is exactly the release, it should be
  PV = "2.1.0"

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[OE-core] [master][warrior][PATCH] at: Fix a spelling mistake.

[Lei Maohui]

Signed-off-by: Lei Maohui 
---
 meta/recipes-extended/at/at/pam.conf.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/at/at/pam.conf.patch 
b/meta/recipes-extended/at/at/pam.conf.patch
index c9f337e..38e7fc1 100644
--- a/meta/recipes-extended/at/at/pam.conf.patch
+++ b/meta/recipes-extended/at/at/pam.conf.patch
@@ -24,7 +24,7 @@ index 3674c0a..2f8d586 100644
 -@include common-auth
 -@include common-account
 +auth   includecommon-auth
-+acount includecommon-account
++account includecommon-account
  sessionrequired   pam_loginuid.so
 -@include common-session-noninteractive
 +sessionincludecommon-session-noninteractive
-- 
2.7.4



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

Re: [OE-core] bash ptests: use runuser? also remaining errors.

[Randy MacLeod]

On 6/11/19 8:05 PM, richard.pur...@linuxfoundation.org wrote:

On Tue, 2019-06-11 at 15:00 -0400, Randy MacLeod wrote:

Richard, et. al.

I have two patches (ptest-runner, bash) that enable all but two [*]
of the bash-ptests to pass. A potential problem is that when started
by
ptest-runner, 'su' (both busybox and util-linux versions), results in
a few of bash's tests failing whereas they work if started by
'runuser'.
The test failure is due to a warning:
  bash: cannot set terminal process group (16036): \
Inappropriate ioctl for device
that contaminates the test logs and makes a diff with the expected
results fail. I can easily redirect that warning to /dev/null but
that seems wrong and would be a patch that we'd have to carry in
oe-core.

To get 'runuser' from util-linux into an image, it seems that you
need:
   - the RDEPENDS for ptest,
   - REQUIRED_DISTRO_FEATURES = "pam" in bash.inc, and
   - to set the 'pam' DISTRO_FEATURE in your local.conf.


The requirement for pam is a problem as we can't require that for
ptests.


Ugh, I was expecting that you might say that. :-/




Is that something you are willing to do for all ptests or perhaps
just for bash's ptests?  If so, I'll clean-up my ptest-runner patch
and send this to the list.


I also considered using util-linux's 'setpriv' but enabling that
has turned into a mess of dependency loops and other build problems.
man runuser:
 If the PAM session is not required then recommended solution
 is to use setpriv(1) command.


What kind of dependency loops? Can we just enable it for target builds,
would that help?


The loops are due to adding libcap-ng to the DEPENDS for
util-linux so that 'setpriv' can be built. With that
change we have:
   util-linux -> libcap-ng -> python3 -> util-linux

libcap-ng provides both a low-level library and
a python wrapper. If I split that up quickly by just commenting
out the python parts and util-linux builds fine so that's
promising.


Other solutions to properly starting user tests from root are
welcome!


Not sure but I think we're going to need to find some. Enabling setpriv
sounds like the easiest first option but it depends on the errors.


Okay, I'll work on that next, err now... and it mostly works!
Now there are 4 ptest failures rather than 2 with runuser.
A newer version of util-linux/sys-utils/setpriv.c has a
  --reset-env
option that I suspect will help with that.

Chen,
Do you happen to have a util-linux update underway?
I need 2.33.2 or newer.


It's possible that there's also still a bug in ptest-runner that
should be fixed or some shell hackery that might work-around
the problems seen with 'su'.

Thanks for the quick reply,

../Randy


Cheers,

Richard




--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] util-linux: upgrade to 2.33.2

[Chen Qi]

*** BLURB HERE ***
The following changes since commit 9e5a3f40caa37141d292c6dd5914d4670ab57aff:

  bitbake: cooker: Ensure mcdeps are processed even if only one multiconfig 
(2019-06-11 13:27:19 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/util-linux-2.33.2
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/util-linux-2.33.2

Chen Qi (1):
  util-linux: upgrade to 2.33.2

 meta/recipes-core/util-linux/util-linux.inc  | 16 
 .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb}   |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)
 rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
util-linux_2.33.2.bb} (72%)

-- 
1.9.1

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

[OE-core] [PATCH 1/1] util-linux: upgrade to 2.33.2

[Chen Qi]

The license files' names are changed, but the contents remain the
same.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/util-linux/util-linux.inc  | 16 
 .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb}   |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)
 rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
util-linux_2.33.2.bb} (72%)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 7b9b4d2..eaaf408 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -8,15 +8,15 @@ SECTION = "base"
 
 LICENSE = "GPLv2+ & LGPLv2.1+ & BSD"
 
-LIC_FILES_CHKSUM = 
"file://README.licensing;md5=1715f5ee3e01203ca1e1e0b9ee65918c \
+LIC_FILES_CHKSUM = 
"file://README.licensing;md5=972a134f1e14b2b060e365df2fab0099 \
 file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-
file://Documentation/licenses/COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263
 \
-
file://Documentation/licenses/COPYING.LGPLv2.1;md5=4fbd65380cdd255951079008b364516c
 \
-
file://Documentation/licenses/COPYING.BSD-3;md5=58dcd8452651fc8b07d1f65ce07ca8af
 \
-
file://Documentation/licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262 \
-
file://libuuid/COPYING;md5=b442ffb762cf8d3e9df1b99e0bb4af70 \
-
file://libmount/COPYING;md5=fb93f01d4361069c5616327705373b16 \
-
file://libblkid/COPYING;md5=fb93f01d4361069c5616327705373b16"
+
file://Documentation/licenses/COPYING.GPL-2.0-or-later;md5=b234ee4d69f5fce4486a80fdaf4a4263
 \
+
file://Documentation/licenses/COPYING.LGPL-2.1-or-later;md5=4fbd65380cdd255951079008b364516c
 \
+
file://Documentation/licenses/COPYING.BSD-3-Clause;md5=58dcd8452651fc8b07d1f65ce07ca8af
 \
+
file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
 \
+
file://libuuid/COPYING;md5=6d2cafc999feb2c2de84d4d24b23290c \
+
file://libmount/COPYING;md5=7c7e39fb7d70ffe5d693a643e29987c2 \
+
file://libblkid/COPYING;md5=693bcbbe16d3a4a4b37bc906bc01cc04"
 
 #gtk-doc is not enabled as it requires xmlto which requires util-linux
 inherit autotools gettext manpages pkgconfig systemd update-alternatives 
python3-dir bash-completion ptest
diff --git a/meta/recipes-core/util-linux/util-linux_2.32.1.bb 
b/meta/recipes-core/util-linux/util-linux_2.33.2.bb
similarity index 72%
rename from meta/recipes-core/util-linux/util-linux_2.32.1.bb
rename to meta/recipes-core/util-linux/util-linux_2.33.2.bb
index e0bd383..538e276 100644
--- a/meta/recipes-core/util-linux/util-linux_2.32.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.33.2.bb
@@ -9,5 +9,5 @@ SRC_URI += "file://configure-sbindir.patch \
 file://avoid_parallel_tests.patch \
 file://check-for-_HAVE_STRUCT_TERMIOS_C_OSPEED.patch \
 "
-SRC_URI[md5sum] = "9e5b1b8c1dc99455bdb6b462cf9436d9"
-SRC_URI[sha256sum] = 
"86e6707a379c7ff5489c218cfaf1e3464b0b95acf7817db0bc5f179e356a67b2"
+SRC_URI[md5sum] = "91653b90fcbe9c161153e39b8cc69fb5"
+SRC_URI[sha256sum] = 
"631be8eac6cf6230ba478de211941d526808dba3cd436380793334496013ce97"
-- 
1.9.1

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

Re: [OE-core] meta-openembedded git repo in some of the openembedded-core-contrib branches

[Hongxu Jia]

On 6/12/19 4:01 AM, Martin Jansa wrote:

Hi,

when accidentally checking for some old meta-oe commit in oe-core
repository I was surprised that it was found in some of the contrib
branches:


Sorry for the mistake


~/openembedded-core $ git branch -a --contains 30bbde3d09e
   remotes/contrib/hongxu/add-recipes-20190215
   remotes/contrib/hongxu/dbg-split
   remotes/contrib/hongxu/misc-fixes

These branches are actually from meta-oe repo, not oe-core.

Please remove old irrelevant branches from -contrib repositories:
https://git.openembedded.org/openembedded-core-contrib/
https://git.openembedded.org/meta-openembedded-contrib/

and make sure you're pushing to the right remote :), it unnecessary
almost doubles the repo size.


I 've already cleaned them up on openembedded-core

//Hongxu


Cheers,



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

Re: [OE-core] [PATCH] vim: Update to 8.1.1518 to fix CVE-2019-12735

[Tom Rini]

On Tue, Jun 11, 2019 at 08:10:58PM -0400, Tom Rini wrote:

> Signed-off-by: Tom Rini 
> ---
>  meta/recipes-support/vim/vim-tiny_8.1.1240.bb | 12 
>  meta/recipes-support/vim/vim-tiny_8.1.1518.bb | 12 
>  meta/recipes-support/vim/vim.inc  |  2 +-
>  meta/recipes-support/vim/vim_8.1.1240.bb  | 10 --
>  meta/recipes-support/vim/vim_8.1.1518.bb  | 10 ++
>  5 files changed, 23 insertions(+), 23 deletions(-)
>  delete mode 100644 meta/recipes-support/vim/vim-tiny_8.1.1240.bb
>  create mode 100644 meta/recipes-support/vim/vim-tiny_8.1.1518.bb
>  delete mode 100644 meta/recipes-support/vim/vim_8.1.1240.bb
>  create mode 100644 meta/recipes-support/vim/vim_8.1.1518.bb

Note that for warrior, if desired we can simply cherry-pick
https://github.com/vim/vim/commit/53575521406739cf20bbe4e384d88e7dca11f040
to resolve the CVE in question.

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

[OE-core] [PATCH] vim: Update to 8.1.1518 to fix CVE-2019-12735

[Tom Rini]

Signed-off-by: Tom Rini 
---
 meta/recipes-support/vim/vim-tiny_8.1.1240.bb | 12 
 meta/recipes-support/vim/vim-tiny_8.1.1518.bb | 12 
 meta/recipes-support/vim/vim.inc  |  2 +-
 meta/recipes-support/vim/vim_8.1.1240.bb  | 10 --
 meta/recipes-support/vim/vim_8.1.1518.bb  | 10 ++
 5 files changed, 23 insertions(+), 23 deletions(-)
 delete mode 100644 meta/recipes-support/vim/vim-tiny_8.1.1240.bb
 create mode 100644 meta/recipes-support/vim/vim-tiny_8.1.1518.bb
 delete mode 100644 meta/recipes-support/vim/vim_8.1.1240.bb
 create mode 100644 meta/recipes-support/vim/vim_8.1.1518.bb

diff --git a/meta/recipes-support/vim/vim-tiny_8.1.1240.bb 
b/meta/recipes-support/vim/vim-tiny_8.1.1240.bb
deleted file mode 100644
index e4c26d23f69d..
--- a/meta/recipes-support/vim/vim-tiny_8.1.1240.bb
+++ /dev/null
@@ -1,12 +0,0 @@
-require vim.inc
-
-SUMMARY += " (with tiny features)"
-
-PACKAGECONFIG += "tiny"
-
-do_install() {
-install -D -m 0755 ${S}/src/vim ${D}/${bindir}/vim.tiny
-}
-
-ALTERNATIVE_PRIORITY = "90"
-ALTERNATIVE_TARGET = "${bindir}/vim.tiny"
diff --git a/meta/recipes-support/vim/vim-tiny_8.1.1518.bb 
b/meta/recipes-support/vim/vim-tiny_8.1.1518.bb
new file mode 100644
index ..e4c26d23f69d
--- /dev/null
+++ b/meta/recipes-support/vim/vim-tiny_8.1.1518.bb
@@ -0,0 +1,12 @@
+require vim.inc
+
+SUMMARY += " (with tiny features)"
+
+PACKAGECONFIG += "tiny"
+
+do_install() {
+install -D -m 0755 ${S}/src/vim ${D}/${bindir}/vim.tiny
+}
+
+ALTERNATIVE_PRIORITY = "90"
+ALTERNATIVE_TARGET = "${bindir}/vim.tiny"
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 5f9f3d79de96..0a31e68cb7cc 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -12,7 +12,7 @@ SRC_URI = "git://github.com/vim/vim.git \
file://vim-add-knob-whether-elf.h-are-checked.patch \
file://0001-src-Makefile-improve-reproducibility.patch \
 "
-SRCREV = "d96dbd6f95ea22f609042cc9c6272f14a21ff1a5"
+SRCREV = "202d982b36d87cf91d992bd7e30d3223bdc72cd9"
 
 S = "${WORKDIR}/git"
 
diff --git a/meta/recipes-support/vim/vim_8.1.1240.bb 
b/meta/recipes-support/vim/vim_8.1.1240.bb
deleted file mode 100644
index 60946a181f42..
--- a/meta/recipes-support/vim/vim_8.1.1240.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require vim.inc
-
-PROVIDES = "xxd"
-
-PACKAGECONFIG_class-native = ""
-BBCLASSEXTEND = "native"
-
-ALTERNATIVE_${PN}_append = " xxd"
-ALTERNATIVE_TARGET[xxd] = "${bindir}/xxd"
-ALTERNATIVE_LINK_NAME[xxd] = "${bindir}/xxd"
diff --git a/meta/recipes-support/vim/vim_8.1.1518.bb 
b/meta/recipes-support/vim/vim_8.1.1518.bb
new file mode 100644
index ..60946a181f42
--- /dev/null
+++ b/meta/recipes-support/vim/vim_8.1.1518.bb
@@ -0,0 +1,10 @@
+require vim.inc
+
+PROVIDES = "xxd"
+
+PACKAGECONFIG_class-native = ""
+BBCLASSEXTEND = "native"
+
+ALTERNATIVE_${PN}_append = " xxd"
+ALTERNATIVE_TARGET[xxd] = "${bindir}/xxd"
+ALTERNATIVE_LINK_NAME[xxd] = "${bindir}/xxd"
-- 
2.7.4

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

Re: [OE-core] bash ptests: use runuser? also remaining errors.

[richard . purdie]

On Tue, 2019-06-11 at 15:00 -0400, Randy MacLeod wrote:
> Richard, et. al.
> 
> I have two patches (ptest-runner, bash) that enable all but two [*]
> of the bash-ptests to pass. A potential problem is that when started
> by
> ptest-runner, 'su' (both busybox and util-linux versions), results in
> a few of bash's tests failing whereas they work if started by
> 'runuser'.
> The test failure is due to a warning:
>  bash: cannot set terminal process group (16036): \
>Inappropriate ioctl for device
> that contaminates the test logs and makes a diff with the expected
> results fail. I can easily redirect that warning to /dev/null but
> that seems wrong and would be a patch that we'd have to carry in
> oe-core.
> 
> To get 'runuser' from util-linux into an image, it seems that you
> need:
>   - the RDEPENDS for ptest,
>   - REQUIRED_DISTRO_FEATURES = "pam" in bash.inc, and
>   - to set the 'pam' DISTRO_FEATURE in your local.conf.

The requirement for pam is a problem as we can't require that for
ptests.

> Is that something you are willing to do for all ptests or perhaps
> just for bash's ptests?  If so, I'll clean-up my ptest-runner patch
> and send this to the list.
> 
> 
> I also considered using util-linux's 'setpriv' but enabling that
> has turned into a mess of dependency loops and other build problems.
> man runuser:
> If the PAM session is not required then recommended solution
> is to use setpriv(1) command.

What kind of dependency loops? Can we just enable it for target builds,
would that help?

> Other solutions to properly starting user tests from root are
> welcome!

Not sure but I think we're going to need to find some. Enabling setpriv
sounds like the easiest first option but it depends on the errors.

Cheers,

Richard

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

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Bruce Ashfield]

On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
 wrote:
>
> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> > From: He Zhe 
> >
> > For the moment,
> > 0001~0004 are on master branch only.
> > 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
> > yet.
> >
> > Signed-off-by: He Zhe 
> > ---
> > v2: Correct a typo in SOB for 0001*.patch
>
> I just discussed this with lttng upstream maintainers a little. We're
> going to have continual tension between keeping lttng-modules up to
> date and new kernel versions.
>
> How about we also have a git version of this particular recipe which
> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
> PREFERRED_VERSION when using newer kernels?
>
> That should keep people using very recent kernels happy, let us use a
> stable release version and avoid us adding/removing large patchsets on
> a semi regular basis?
>
> Would you be willing to try/submit such a git recipe?

This makes sense to me as well, since I'm one of the folks that runs
into this issue the most. In fact, I've been carrying a local _git
version of the lttng recipe for over a year, since I didn't feel like
getting into the _git versus release tarballs debate. This solution
should avoid that debate and keep all the different versions of
kernels moving along.

Bruce

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



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] Revert "image_types: use pigz to create .gz files"

[Martin Jansa]

This is just FYI:

This probably won't happen with most of OE use-cases, but even with pigz
being the drop in replacement, there are some differences, e.g. when I'm
using pigz-2.4 on my Gentoo host as gzip, xmltex-1.9.tar.gz fails to unpack
gzip: warning:
/tmp/tmpfs/portage/dev-tex/xmltex-1.9-r2/distdir/xmltex-1.9.tar.gz:
trailing junk was ignored
ERROR: dev-tex/xmltex-1.9-r2::gentoo failed (unpack phase):
   unpack: failure unpacking xmltex-1.9.tar.gz

yes xmltex-1.9.tar.gz has something strange in the archive and emerge
should ignore the error from gzip (gzip itself shows it only as a warning),
but it doesn't and it's a bit confusing to find out that gzip is actually
pigz for someone who didn't see this commit :).

On Mon, May 27, 2019 at 3:44 PM Anuj Mittal  wrote:

> This reverts commit a559ffab30b7b45849ace023808c1fb20811d43d.
>
> This is not needed now that pigz has been marked as a drop-in
> replacement.
>
> Signed-off-by: Anuj Mittal 
> ---
>  meta/classes/image_types.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index 1c44ec4a80..fd98a7d1bd 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -284,7 +284,7 @@ COMPRESSIONTYPES ?= ""
>
>  CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum
> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
> ${COMPRESSIONTYPES}"
>  CONVERSION_CMD_lzma = "lzma -k -f -7
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> -CONVERSION_CMD_gz = "pigz -f -9 -n -c
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
> +CONVERSION_CMD_gz = "gzip -f -9 -n -c
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
>  CONVERSION_CMD_bz2 = "pbzip2 -f -k
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>  CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_DEFAULTS}
> --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.xz"
>  CONVERSION_CMD_lz4 = "lz4 -9 -z -l
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Richard Purdie]

On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> From: He Zhe 
> 
> For the moment,
> 0001~0004 are on master branch only.
> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
> yet.
> 
> Signed-off-by: He Zhe 
> ---
> v2: Correct a typo in SOB for 0001*.patch

I just discussed this with lttng upstream maintainers a little. We're
going to have continual tension between keeping lttng-modules up to
date and new kernel versions.

How about we also have a git version of this particular recipe which
has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
PREFERRED_VERSION when using newer kernels?

That should keep people using very recent kernels happy, let us use a
stable release version and avoid us adding/removing large patchsets on
a semi regular basis?

Would you be willing to try/submit such a git recipe?

Cheers,

Richard

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

[OE-core] [PATCH] mtd-utils: upgrade 2.0.2 -> 2.1.0

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

* 0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch is upstreamed
* Now requires openssl:
| In file included from ../git/ubifs-utils/mkfs.ubifs/mkfs.ubifs.c:25:
| ../git/ubifs-utils/mkfs.ubifs/mkfs.ubifs.h:49:10: fatal error: 
openssl/rand.h: No such file or directory
|  #include 
|   ^~~~
| compilation terminated.
| Makefile:3457: recipe for target 
'ubifs-utils/mkfs.ubifs/mkfs_ubifs-mkfs.ubifs.o' failed
| make: *** [ubifs-utils/mkfs.ubifs/mkfs_ubifs-mkfs.ubifs.o] Error 1

Signed-off-by: Denys Dmytriyenko 
---
 ...rn-correct-error-number-in-ubi_get_vol_in.patch | 92 --
 meta/recipes-devtools/mtd/mtd-utils_git.bb |  7 +-
 2 files changed, 3 insertions(+), 96 deletions(-)
 delete mode 100644 
meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch

diff --git 
a/meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
 
b/meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
deleted file mode 100644
index 4ece56b..000
--- 
a/meta/recipes-devtools/mtd/mtd-utils/0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch
+++ /dev/null
@@ -1,92 +0,0 @@
-From 0f833ac73ad631248826386e2918d8571ecf0347 Mon Sep 17 00:00:00 2001
-From: David Oberhollenzer 
-Date: Sat, 9 Jun 2018 16:45:22 +0200
-Subject: [PATCH] Revert "Return correct error number in ubi_get_vol_info1"
-
-This reverts commit dede98ffb706676309488d7cc660f569548d5930.
-
-The original commit tried to fix a descrepancy between the implementation
-and the documentation by making the implementation comply.
-
-When making the change, it was overlooked, that ubinfo and ubirename were
-written against the implementation instead of the behaviour specified by
-the documentation. So were further internal functions like
-ubi_get_vol_info1_nm which further breaks ubirmvol.
-
-A report with an outline of a resulting problem can be read on
-the mailing list:
-
-http://lists.infradead.org/pipermail/linux-mtd/2018-June/081562.html
-
-From the report:
-
-steps to reproduce: have mtd-utils 2.0.1 or 2.0.2
-
-0. make a bunch of ubi volumes in sequential order
-
-ubimkvol /dev/ubi0 -s 64KiB -N test1
-ubimkvol /dev/ubi0 -s 64KiB -N test2
-ubimkvol /dev/ubi0 -s 64KiB -N test3
-ubimkvol /dev/ubi0 -s 64KiB -N test4
-..
-
-1. delete the test1 volume, making a hole in the volume table
-
-ubirmvol /dev/ubi0 -N test1
-
-2. try an affected tool (i.e. "ubirmvol /dev/ubi0 -N test4" )
-
- |root at mr24:/# ubirmvol /dev/ubi0 -N test4
- |ubirmvol: error!: cannot find UBI volume "test4"
- | error 19 (No such device)
-
-or "ubinfo -a"
-
- | root at mr24:/# ubinfo -a
- | UBI version:1
- | Count of UBI devices:   1
- | UBI control device major/minor: 10:59
- | Present UBI devices:ubi0
- |
- | ubi0
- | Volumes count:   11
- | Logical eraseblock size: 15872 bytes, 15.5 KiB
- | Total amount of logical eraseblocks: 1952 (30982144 bytes, 29.5 MiB)
- | Amount of available logical eraseblocks: 75 (1190400 bytes, 1.1 MiB)
- | Maximum count of volumes 92
- | Count of bad physical eraseblocks:   0
- | Count of reserved physical eraseblocks:  40
- | Current maximum erase counter value: 984
- | Minimum input/output unit size:  512 bytes
- | Character device major/minor:251:0
- | ubinfo: error!: libubi failed to probe volume 5 on ubi0
- |error 19 (No such device)
- | Present volumes: 0, 1, 2, 3, 4root at mr24:/#
-
-Reported-by: Christian Lamparter 
-Signed-off-by: David Oberhollenzer 
-Upstream-Status: Accepted 
[http://git.infradead.org/mtd-utils.git/commit/0f833ac73ad631248826386e2918d8571ecf0347]

- lib/libubi.c | 5 +
- 1 file changed, 1 insertion(+), 4 deletions(-)
-
-diff --git a/lib/libubi.c b/lib/libubi.c
-index b50e68a..978b433 100644
 a/lib/libubi.c
-+++ b/lib/libubi.c
-@@ -1240,11 +1240,8 @@ int ubi_get_vol_info1(libubi_t desc, int dev_num, int 
vol_id,
-   info->dev_num = dev_num;
-   info->vol_id = vol_id;
- 
--  if (vol_get_major(lib, dev_num, vol_id, >major, >minor)) {
--  if (errno == ENOENT)
--  errno = ENODEV;
-+  if (vol_get_major(lib, dev_num, vol_id, >major, >minor))
-   return -1;
--  }
- 
-   ret = vol_read_data(lib->vol_type, dev_num, vol_id, buf, 50);
-   if (ret < 0)
--- 
-2.14.4
-
diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb 
b/meta/recipes-devtools/mtd/mtd-utils_git.bb
index 9ffac2e..1dba224 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
@@ -7,15 +7,14 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
 
 inherit autotools pkgconfig update-alternatives
 
-DEPENDS = "zlib e2fsprogs util-linux"
+DEPENDS = "zlib 

Re: [OE-core] Fwd: [yocto] Yocto Project DevDay NA 2019 - Extend your Embedded Linux Conference Experience

[Joshua Watt]

On 6/11/19 3:57 PM, Joshua Watt wrote:
Both of the registration links take me to the ELC registration 
page is there a way to register outside of the ELC registration? 
We lost our confirmation numbers due to a mix up in the ordering 
process and can't change our registration anymore :(


Of course, as soon as I send that, we find the confirmation numbers in 
our Junk mail. Sorry for the noise





On 6/10/19 7:21 AM, Philip Balister wrote:

FYI

 Forwarded Message 
Subject: [yocto] Yocto Project DevDay NA 2019 - Extend your Embedded
Linux Conference Experience
Date: Tue, 4 Jun 2019 19:39:08 +
From: Volosincu, Andreea S 
To: Yocto list discussion 

Hello Everybody,

The registration for the Yocto Project DevDay NA 2019 is now open. Join
our knowledgeable and engaging instructors to learn about creating
custom-build Linux distributions using the Yocto Project infrastructure
and tools, across multiple architectures.

Date: Tuesday, August 20, 2019
Time: 9:00 am - 5:00 pm
Location: Hilton San Diego Bayfront

There are two ways to register - by adding it your ELC registration or
on the separate registration page.

Register now.


Best regards,
Yocto Project Advocacy Team




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

Re: [OE-core] Fwd: [yocto] Yocto Project DevDay NA 2019 - Extend your Embedded Linux Conference Experience

[Joshua Watt]

Both of the registration links take me to the ELC registration page 
is there a way to register outside of the ELC registration? We lost our 
confirmation numbers due to a mix up in the ordering process and can't 
change our registration anymore :(


On 6/10/19 7:21 AM, Philip Balister wrote:

FYI

 Forwarded Message 
Subject: [yocto] Yocto Project DevDay NA 2019 - Extend your Embedded
Linux Conference Experience
Date: Tue, 4 Jun 2019 19:39:08 +
From: Volosincu, Andreea S 
To: Yocto list discussion 

Hello Everybody,

The registration for the Yocto Project DevDay NA 2019 is now open. Join
our knowledgeable and engaging instructors to learn about creating
custom-build Linux distributions using the Yocto Project infrastructure
and tools, across multiple architectures.

Date: Tuesday, August 20, 2019
Time: 9:00 am - 5:00 pm
Location: Hilton San Diego Bayfront

There are two ways to register - by adding it your ELC registration or
on the separate registration page.

Register now.


Best regards,
Yocto Project Advocacy Team




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

[OE-core] meta-openembedded git repo in some of the openembedded-core-contrib branches

[Martin Jansa]

Hi,

when accidentally checking for some old meta-oe commit in oe-core
repository I was surprised that it was found in some of the contrib
branches:

~/openembedded-core $ git branch -a --contains 30bbde3d09e
  remotes/contrib/hongxu/add-recipes-20190215
  remotes/contrib/hongxu/dbg-split
  remotes/contrib/hongxu/misc-fixes

These branches are actually from meta-oe repo, not oe-core.

Please remove old irrelevant branches from -contrib repositories:
https://git.openembedded.org/openembedded-core-contrib/
https://git.openembedded.org/meta-openembedded-contrib/

and make sure you're pushing to the right remote :), it unnecessary
almost doubles the repo size.

Cheers,


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

[OE-core] bash ptests: use runuser? also remaining errors.

[Randy MacLeod]

Richard, et. al.

I have two patches (ptest-runner, bash) that enable all but two [*]
of the bash-ptests to pass. A potential problem is that when started by
ptest-runner, 'su' (both busybox and util-linux versions), results in
a few of bash's tests failing whereas they work if started by 'runuser'.
The test failure is due to a warning:
bash: cannot set terminal process group (16036): \
  Inappropriate ioctl for device
that contaminates the test logs and makes a diff with the expected
results fail. I can easily redirect that warning to /dev/null but
that seems wrong and would be a patch that we'd have to carry in
oe-core.

To get 'runuser' from util-linux into an image, it seems that you need:
 - the RDEPENDS for ptest,
 - REQUIRED_DISTRO_FEATURES = "pam" in bash.inc, and
 - to set the 'pam' DISTRO_FEATURE in your local.conf.

Is that something you are willing to do for all ptests or perhaps just
for bash's ptests?  If so, I'll clean-up my ptest-runner patch and
send this to the list.


I also considered using util-linux's 'setpriv' but enabling that
has turned into a mess of dependency loops and other build problems.
man runuser:
   If the PAM session is not required then recommended solution
   is to use setpriv(1) command.

Other solutions to properly starting user tests from root are welcome!

Thanks in advance,
--
# Randy MacLeod
# Wind River Linux


[*] FYI, the two remaining failures are:

1.
run-read:
  # cat tests/read6.sub
  # test read with a timeout of 0 -- input polling
  # sleep with fractional seconds argument is not universal
  echo abcde | { sleep 0.25 2>/dev/null ; read -t 0; }
  echo $?

  read -t 0 < $0
  echo $?

  read -t 0
  echo $? <-- returns 1, when 0 is expected.

I can reproduce this on my workstation but only when using ptest-runner
and initially logging into the console as root. That's a little odd and
seems like I need to continue to improve ptest-runner.


2.

run-trap:
  # cat tests/trap3.sub
  PS4='+[$LINENO] '
  trap 'echo trap: $LINENO' ERR

  set -x

  echo 1
  echo 2
  echo 3 | cat | false <--- error
  echo 4

This is a scheduler behaviour difference between the common case
on a workstation and the common case in qemu. The test case does
warn about the completion order not being deterministic so I plan
to ignore it.

From tests/run-trap:
  UNIX versions number signals and schedule processes differently.
  If output differing only in line numbers is produced, please
  do not consider this a test failure.

Still, it's notable and slightly odd that the common case output
is different.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic/plugins: kernel image refer to KERNEL_IMAGETYPE

[Andre McCurdy]

On Mon, Jun 10, 2019 at 11:31 PM  wrote:
> From: Chee Yang Lee 
>
> replaced hardcoded kernel image with KERNEL_IMAGETYPE.
> set kernel image to "bzImage" incase KERNEL_IMAGETYPE not set.

A default value for KERNEL_IMAGETYPE is set by default-distrovars.inc,
so if it's not set here then something is mis-configured. Better to
exit with an error in that case rather than try to carry on.

> Signed-off-by: Chee Yang Lee 
> ---
>  scripts/lib/wic/plugins/source/bootimg-efi.py   | 21 
> +++--
>  scripts/lib/wic/plugins/source/bootimg-pcbios.py|  8 ++--
>  .../lib/wic/plugins/source/isoimage-isohybrid.py| 21 
> ++---
>  3 files changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
> b/scripts/lib/wic/plugins/source/bootimg-efi.py
> index 70cc1b0..d87db1f 100644
> --- a/scripts/lib/wic/plugins/source/bootimg-efi.py
> +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
> @@ -71,14 +71,16 @@ class BootimgEFIPlugin(SourcePlugin):
>  grubefi_conf += "timeout=%s\n" % bootloader.timeout
>  grubefi_conf += "menuentry '%s'{\n" % (title if title else 
> "boot")
>
> -kernel = "/bzImage"
> +kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> +if not kernel:
> +kernel = "bzImage"
>
>  label = source_params.get('label')
>  label_conf = "root=%s" % creator.rootdev
>  if label:
>  label_conf = "LABEL=%s" % label
>
> -grubefi_conf += "linux %s %s rootwait %s\n" \
> +grubefi_conf += "linux /%s %s rootwait %s\n" \
>  % (kernel, label_conf, bootloader.append)
>
>  if initrd:
> @@ -143,12 +145,15 @@ class BootimgEFIPlugin(SourcePlugin):
>
>  if not custom_cfg:
>  # Create systemd-boot configuration using parameters from wks 
> file
> -kernel = "/bzImage"
> +kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> +if not kernel:
> +kernel = "bzImage"
> +
>  title = source_params.get('title')
>
>  boot_conf = ""
>  boot_conf += "title %s\n" % (title if title else "boot")
> -boot_conf += "linux %s\n" % kernel
> +boot_conf += "linux /%s\n" % kernel
>
>  label = source_params.get('label')
>  label_conf = "LABEL=Boot root=%s" % creator.rootdev
> @@ -209,8 +214,12 @@ class BootimgEFIPlugin(SourcePlugin):
>
>  hdddir = "%s/hdd/boot" % cr_workdir
>
> -install_cmd = "install -m 0644 %s/bzImage %s/bzImage" % \
> -(staging_kernel_dir, hdddir)
> +kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> +if not kernel:
> +kernel = "bzImage"
> +
> +install_cmd = "install -m 0644 %s/%s %s/%s" % \
> +(staging_kernel_dir, kernel, hdddir, kernel)
>  exec_cmd(install_cmd)
>
>
> diff --git a/scripts/lib/wic/plugins/source/bootimg-pcbios.py 
> b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
> index 6c9f54a..670d347 100644
> --- a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
> +++ b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
> @@ -149,8 +149,12 @@ class BootimgPcbiosPlugin(SourcePlugin):
>
>  hdddir = "%s/hdd/boot" % cr_workdir
>
> -cmds = ("install -m 0644 %s/bzImage %s/vmlinuz" %
> -(staging_kernel_dir, hdddir),
> +kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> +if not kernel:
> +kernel = "bzImage"
> +
> +cmds = ("install -m 0644 %s/%s %s/vmlinuz" %
> +(staging_kernel_dir, kernel, hdddir),
>  "install -m 444 %s/syslinux/ldlinux.sys %s/ldlinux.sys" %
>  (bootimg_dir, hdddir),
>  "install -m 0644 %s/syslinux/vesamenu.c32 %s/vesamenu.c32" %
> diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
> b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> index 96d07ff..74d6f14 100644
> --- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> @@ -70,8 +70,10 @@ class IsoImagePlugin(SourcePlugin):
>  syslinux_conf += "DEFAULT boot\n"
>  syslinux_conf += "LABEL boot\n"
>
> -kernel = "/bzImage"
> -syslinux_conf += "KERNEL " + kernel + "\n"
> +kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> +if not kernel:
> +kernel = "bzImage"
> +syslinux_conf += "KERNEL /" + kernel + "\n"
>  syslinux_conf += "APPEND initrd=/initrd LABEL=boot %s\n" \
>   % bootloader.append
>
> @@ -114,9 +116,11 @@ class IsoImagePlugin(SourcePlugin):
>  grubefi_conf += "\n"
>  grubefi_conf += "menuentry 'boot'{\n"
>
> -kernel = "/bzImage"
> +kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> +if not kernel:
> +

[OE-core] ✗ patchtest: failure for selftests: add tests for INCOMPATIBLE_LICENSE

[Patchwork]

== Series Details ==

Series: selftests: add tests for INCOMPATIBLE_LICENSE
Revision: 1
URL   : https://patchwork.openembedded.org/series/18089/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Errors in your Python code were encountered [test_pylint] 
  Suggested fixCorrect the lines introduced by your patch
  Output   Please, fix the listed issues:
   meta/lib/oeqa/selftest/cases/incompatible_lic.py does not 
exist



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH v5] selftests: add tests for INCOMPATIBLE_LICENSE

[Quentin Schulz]

One bug went unnoticed without these selftests: an INCOMPATIBLE_LICENSE
with a non-SPDX license for a package with that non-SPDX license wasn't
enforcing the denial of build for said package. See
4b6ce4604cc15e289a48f8586d58a101b7a70b52 ("meta: license: fix non-SPDX
license being removed from INCOMPATIBLE_LICENSE")

While adding a test for that particular case, let's add a few more so
that we cover a handful more use cases of INCOMPATIBLE_LICENSE.

Signed-off-by: Quentin Schulz 
---

v5:
  - removed useless OETestID import,
  - renamed test_lic into lic_test so that the function isn't called by Python
unittest framework,
  - added --dry-run to the bitbake command so that it does not do a full build
  to tell us the behaviour is not the one we expect (INCOMPATIBLE_LICENSE not
  working),

added in v4

 .../license/incompatible-license-alias.bb |  3 ++
 .../license/incompatible-license.bb   |  3 ++
 .../license/incompatible-nonspdx-license.bb   |  3 ++
 .../oeqa/selftest/cases/incompatible_lic.py   | 41 +++
 4 files changed, 50 insertions(+)
 create mode 100644 
meta-selftest/recipes-test/license/incompatible-license-alias.bb
 create mode 100644 meta-selftest/recipes-test/license/incompatible-license.bb
 create mode 100644 
meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb
 create mode 100644 meta/lib/oeqa/selftest/cases/incompatible_lic.py

diff --git a/meta-selftest/recipes-test/license/incompatible-license-alias.bb 
b/meta-selftest/recipes-test/license/incompatible-license-alias.bb
new file mode 100644
index 00..e0b4e13c26
--- /dev/null
+++ b/meta-selftest/recipes-test/license/incompatible-license-alias.bb
@@ -0,0 +1,3 @@
+SUMMARY = "Recipe with an alias of an SPDX license"
+DESCRIPTION = "Is licensed with an alias of an SPDX license to be used for 
testing"
+LICENSE = "GPLv3"
diff --git a/meta-selftest/recipes-test/license/incompatible-license.bb 
b/meta-selftest/recipes-test/license/incompatible-license.bb
new file mode 100644
index 00..1728ad76b7
--- /dev/null
+++ b/meta-selftest/recipes-test/license/incompatible-license.bb
@@ -0,0 +1,3 @@
+SUMMARY = "Recipe with an SPDX license"
+DESCRIPTION = "Is licensed with an SPDX license to be used for testing"
+LICENSE = "GPL-3.0"
diff --git a/meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb 
b/meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb
new file mode 100644
index 00..35af0966ef
--- /dev/null
+++ b/meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb
@@ -0,0 +1,3 @@
+SUMMARY = "Recipe with a non-SPDX license"
+DESCRIPTION = "Is licensed with a non-SPDX license to be used for testing"
+LICENSE = "FooLicense"
diff --git a/meta/lib/oeqa/selftest/cases/incompatible_lic.py 
b/meta/lib/oeqa/selftest/cases/incompatible_lic.py
new file mode 100644
index 00..8fb93af8a8
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/incompatible_lic.py
@@ -0,0 +1,41 @@
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake
+
+class IncompatibleLicenseTests(OESelftestTestCase):
+
+def lic_test(self, pn, pn_lic, lic):
+error_msg = 'ERROR: Nothing PROVIDES \'%s\'\n%s was skipped: it has an 
incompatible license: %s' % (pn, pn, pn_lic)
+
+self.write_config("INCOMPATIBLE_LICENSE += \"%s\"" % (lic))
+
+result = bitbake('%s --dry-run' % (pn), ignore_status=True)
+if error_msg not in result.output:
+raise AssertionError(result.output)
+
+# Verify that a package with an SPDX license (from SRC_DISTRIBUTE_LICENSES)
+# cannot be built when INCOMPATIBLE_LICENSE contains this SPDX license
+def test_incompatible_spdx_license(self):
+self.lic_test('incompatible-license', 'GPL-3.0', 'GPL-3.0')
+
+# Verify that a package with an SPDX license (from SRC_DISTRIBUTE_LICENSES)
+# cannot be built when INCOMPATIBLE_LICENSE contains an alias (in
+# SPDXLICENSEMAP) of this SPDX license
+def test_incompatible_alias_spdx_license(self):
+self.lic_test('incompatible-license', 'GPL-3.0', 'GPLv3')
+
+# Verify that a package with an alias (from SPDXLICENSEMAP) to an SPDX
+# license cannot be built when INCOMPATIBLE_LICENSE contains this SPDX
+# license
+def test_incompatible_spdx_license_alias(self):
+self.lic_test('incompatible-license-alias', 'GPLv3', 'GPL-3.0')
+
+# Verify that a package with an alias (from SPDXLICENSEMAP) to an SPDX
+# license cannot be built when INCOMPATIBLE_LICENSE contains this alias
+def test_incompatible_alias_spdx_license_alias(self):
+self.lic_test('incompatible-license-alias', 'GPLv3', 'GPLv3')
+
+# Verify that a package with a non-SPDX license (neither in
+# SRC_DISTRIBUTE_LICENSES nor in SPDXLICENSEMAP) cannot be built when
+# INCOMPATIBLE_LICENSE contains this license
+def test_incompatible_nonspdx_license(self):
+self.lic_test('incompatible-nonspdx-license', 

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Quentin Schulz]

On Tue, Jun 11, 2019 at 03:57:23PM +0100, Burton, Ross wrote:
> On Tue, 11 Jun 2019 at 15:56, Quentin Schulz
>  wrote:
> > Also, I factored out everything into a function that shouldn't be run as
> > a test but when doing:
> > oe-selftest --run-tests incompatible_lic.IncompatibleLicenseTests
> > it tries to run the function and thus fails the test. Is that okay? if
> > not, how do you usually proceed?
> 
> So Python unittest's behaviour is that any function called test_*() is
> a test case and is executed, so just don't name any helper functions
> like this test_*.
> 

Ah, that's what I was missing. Thanks.

Quentin
-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Burton, Ross]

On Tue, 11 Jun 2019 at 15:55, Burton, Ross  wrote:
> Either is fine.  Note that in the broken case - where the recipe isn't
> skipped - the test goes ahead and compiles stuff.  Can you also try
> using --dry-run to see if that results in the same test behaviour, but
> without attempting compilation.

FWIW:

-result = bitbake(pn, ignore_status=True)
+result = bitbake("%s --dry-run" % pn, ignore_status=True)

Still results in the nonspdx case failing as expected without the fix,
but without any compilation attempted.

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

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Burton, Ross]

On Tue, 11 Jun 2019 at 15:56, Quentin Schulz
 wrote:
> Also, I factored out everything into a function that shouldn't be run as
> a test but when doing:
> oe-selftest --run-tests incompatible_lic.IncompatibleLicenseTests
> it tries to run the function and thus fails the test. Is that okay? if
> not, how do you usually proceed?

So Python unittest's behaviour is that any function called test_*() is
a test case and is executed, so just don't name any helper functions
like this test_*.

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

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Burton, Ross]

On Tue, 11 Jun 2019 at 15:52, Quentin Schulz
 wrote:
> Sorry for the noise, apparently forgot to pull master and didn't even
> see my patch was already there *sigh*.
>
> I'll remove the import and test on master with and without the patch you
> already merged.
>
> Do you want me to send a v5 or a separate patch series is better for
> you?

Either is fine.  Note that in the broken case - where the recipe isn't
skipped - the test goes ahead and compiles stuff.  Can you also try
using --dry-run to see if that results in the same test behaviour, but
without attempting compilation.

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

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Quentin Schulz]

On Tue, Jun 11, 2019 at 04:52:16PM +0200, Quentin Schulz wrote:
> Hi Ross,
> 
> On Tue, Jun 11, 2019 at 03:49:31PM +0100, Burton, Ross wrote:
> > On Tue, 11 Jun 2019 at 15:27, Quentin Schulz
> >  wrote:
> > > +from oeqa.core.decorator.oeid import OETestID
> > 
> > This was removed a while ago, can you rebase the patches on top of
> > master please?
> > 
> > In this case you can just remove the import, but please verify the
> > behaviour with master.
> > 
> 
> Sorry for the noise, apparently forgot to pull master and didn't even
> see my patch was already there *sigh*.
> 
> I'll remove the import and test on master with and without the patch you
> already merged.
> 
> Do you want me to send a v5 or a separate patch series is better for
> you?
> 

Also, I factored out everything into a function that shouldn't be run as
a test but when doing:
oe-selftest --run-tests incompatible_lic.IncompatibleLicenseTests
it tries to run the function and thus fails the test. Is that okay? if
not, how do you usually proceed?

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

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Quentin Schulz]

Hi Ross,

On Tue, Jun 11, 2019 at 03:49:31PM +0100, Burton, Ross wrote:
> On Tue, 11 Jun 2019 at 15:27, Quentin Schulz
>  wrote:
> > +from oeqa.core.decorator.oeid import OETestID
> 
> This was removed a while ago, can you rebase the patches on top of
> master please?
> 
> In this case you can just remove the import, but please verify the
> behaviour with master.
> 

Sorry for the noise, apparently forgot to pull master and didn't even
see my patch was already there *sigh*.

I'll remove the import and test on master with and without the patch you
already merged.

Do you want me to send a v5 or a separate patch series is better for
you?

Quentin
-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] gtk+3: update 3.24.5 -> 3.24.8

[Alexander Kanavin]

Rebase 0003-Add-disable-opengl-configure-option.patch
and add another fix to it (g-introspection input file list assumes
opengl is always available).

Signed-off-by: Alexander Kanavin 
---
 ...-Add-disable-opengl-configure-option.patch | 77 ++-
 .../gtk+/{gtk+3_3.24.5.bb => gtk+3_3.24.8.bb} |  4 +-
 2 files changed, 58 insertions(+), 23 deletions(-)
 rename meta/recipes-gnome/gtk+/{gtk+3_3.24.5.bb => gtk+3_3.24.8.bb} (84%)

diff --git 
a/meta/recipes-gnome/gtk+/gtk+3/0003-Add-disable-opengl-configure-option.patch 
b/meta/recipes-gnome/gtk+/gtk+3/0003-Add-disable-opengl-configure-option.patch
index e5a67d098e7..852dc9dfcd3 100644
--- 
a/meta/recipes-gnome/gtk+/gtk+3/0003-Add-disable-opengl-configure-option.patch
+++ 
b/meta/recipes-gnome/gtk+/gtk+3/0003-Add-disable-opengl-configure-option.patch
@@ -1,4 +1,4 @@
-From 9e243474eea4330b593e0f6dd418b61b79699d8b Mon Sep 17 00:00:00 2001
+From d11b41a7ff0234f3832d6aabdf498807d1463c18 Mon Sep 17 00:00:00 2001
 From: Jussi Kukkonen 
 Date: Tue, 21 Jun 2016 15:11:39 +0300
 Subject: [PATCH] Add --disable-opengl configure option
@@ -25,6 +25,7 @@ Signed-off-by: Jussi Kukkonen 
  demos/gtk-demo/glarea.c| 14 ++
  docs/tools/Makefile.am |  9 +++-
  docs/tools/widgets.c   |  4 +-
+ gdk/Makefile.am|  8 ++-
  gdk/gdkdisplay.c   |  4 +-
  gdk/gdkgl.c| 10 
  gdk/gdkglcontext.c |  6 +++
@@ -41,15 +42,15 @@ Signed-off-by: Jussi Kukkonen 
  gtk/inspector/general.c|  6 +++
  tests/Makefile.am  | 10 ++--
  testsuite/gtk/objects-finalize.c   |  2 +
- 20 files changed, 202 insertions(+), 18 deletions(-)
+ 21 files changed, 208 insertions(+), 20 deletions(-)
  rename gdk/x11/{gdkx.h => gdkx-with-gl-context.h} (98%)
  create mode 100644 gdk/x11/gdkx-without-gl-context.h
 
 diff --git a/configure.ac b/configure.ac
-index a91b29c..561d3b5 100644
+index 2c4733b..18ae66c 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -351,6 +351,15 @@ AC_ARG_ENABLE(cloudproviders,
+@@ -352,6 +352,15 @@ AC_ARG_ENABLE(cloudproviders,
[AS_HELP_STRING([--enable-cloudproviders],
[enable libcloudproviders integration])],
[cloudproviders_set=yes])
@@ -65,21 +66,21 @@ index a91b29c..561d3b5 100644
  AC_ARG_ENABLE(glx,
[AS_HELP_STRING([--enable-glx],
[When enabled Gdk will try to initialize GLX])])
-@@ -1381,7 +1390,7 @@ CFLAGS="$saved_cflags"
+@@ -1370,7 +1379,7 @@ CFLAGS="$saved_cflags"
  LDFLAGS="$saved_ldflags"
  
  GDK_PACKAGES="$PANGO_PACKAGES gdk-pixbuf-2.0 >= gdk_pixbuf_required_version 
cairo >= cairo_required_version cairo-gobject >= cairo_required_version"
--GDK_PRIVATE_PACKAGES="$GDK_GIO_PACKAGE $X_PACKAGES $WAYLAND_PACKAGES 
$MIR_PACKAGES $cairo_backends epoxy >= epoxy_required_version 
$CLOUDPROVIDER_PACKAGES"
-+GDK_PRIVATE_PACKAGES="$GDK_GIO_PACKAGE $X_PACKAGES $WAYLAND_PACKAGES 
$MIR_PACKAGES $cairo_backends $EPOXY_PACKAGES $CLOUDPROVIDER_PACKAGES"
+-GDK_PRIVATE_PACKAGES="$GDK_GIO_PACKAGE $X_PACKAGES $WAYLAND_PACKAGES 
$MIR_PACKAGES $cairo_backends epoxy >= epoxy_required_version 
$CLOUDPROVIDER_PACKAGES fribidi >= fribidi_required_version"
++GDK_PRIVATE_PACKAGES="$GDK_GIO_PACKAGE $X_PACKAGES $WAYLAND_PACKAGES 
$MIR_PACKAGES $cairo_backends $EPOXY_PACKAGES $CLOUDPROVIDER_PACKAGES fribidi 
>= fribidi_required_version"
  
  PKG_CHECK_MODULES(GDK_DEP, $GDK_PACKAGES $GDK_PRIVATE_PACKAGES)
  GDK_DEP_LIBS="$GDK_EXTRA_LIBS $GDK_DEP_LIBS $MATH_LIB"
-@@ -1415,7 +1424,7 @@ fi
+@@ -1404,7 +1413,7 @@ fi
  PKG_CHECK_MODULES(ATK, $ATK_PACKAGES)
  
  GTK_PACKAGES="atk >= atk_required_version cairo >= cairo_required_version 
cairo-gobject >= cairo_required_version gdk-pixbuf-2.0 >= 
gdk_pixbuf_required_version gio-2.0 >= glib_required_version"
--GTK_PRIVATE_PACKAGES="$ATK_PACKAGES $WAYLAND_PACKAGES $MIR_PACKAGES epoxy >= 
epoxy_required_version"
-+GTK_PRIVATE_PACKAGES="$ATK_PACKAGES $WAYLAND_PACKAGES $MIR_PACKAGES 
$EPOXY_PACKAGES"
+-GTK_PRIVATE_PACKAGES="$ATK_PACKAGES $WAYLAND_PACKAGES $MIR_PACKAGES epoxy >= 
epoxy_required_version fribidi >= fribidi_required_version"
++GTK_PRIVATE_PACKAGES="$ATK_PACKAGES $WAYLAND_PACKAGES $MIR_PACKAGES 
$EPOXY_PACKAGES fribidi >= fribidi_required_version"
  if test "x$enable_x11_backend" = xyes -o "x$enable_wayland_backend" = xyes; 
then
GTK_PRIVATE_PACKAGES="$GTK_PRIVATE_PACKAGES pangoft2"
  fi
@@ -208,11 +209,44 @@ index 932daf1..54239d6 100644
info = new_widget_info ("glarea", widget, MEDIUM);
  
return info;
+diff --git a/gdk/Makefile.am b/gdk/Makefile.am
+index 689ee52..d6b4e70 100644
+--- a/gdk/Makefile.am
 b/gdk/Makefile.am
+@@ -274,7 +274,6 @@ x11_introspection_files =  \
+   x11/gdkeventsource.c\
+   x11/gdkeventtranslator.c\
+   

[OE-core] [PATCH 1/2] gdk-pixbuf: update 2.38.0 -> 2.38.1

[Alexander Kanavin]

Remove 0001-loaders.cache-depend-on-loaders-being-fully-build.patch
as upstream has fixed the issue.

Add a patch to revert upstream's decision to not cross-compile
thumbnailer or tests.

Signed-off-by: Alexander Kanavin 
---
 ...f-decisions-around-cross-compilation.patch | 50 --
 ...-depend-on-loaders-being-fully-build.patch | 51 ---
 ...-around-thumbnailer-cross-compile-fa.patch |  8 ++-
 ...ailer-and-tests-also-in-cross-builds.patch | 28 ++
 ...-pixbuf_2.38.0.bb => gdk-pixbuf_2.38.1.bb} |  6 +--
 5 files changed, 55 insertions(+), 88 deletions(-)
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-loaders.cache-depend-on-loaders-being-fully-build.patch
 create mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0006-Build-thumbnailer-and-tests-also-in-cross-builds.patch
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf_2.38.0.bb => 
gdk-pixbuf_2.38.1.bb} (95%)

diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Fix-a-couple-of-decisions-around-cross-compilation.patch
 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Fix-a-couple-of-decisions-around-cross-compilation.patch
index e638fd3b6f3..e4614049183 100644
--- 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Fix-a-couple-of-decisions-around-cross-compilation.patch
+++ 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Fix-a-couple-of-decisions-around-cross-compilation.patch
@@ -1,4 +1,4 @@
-From bf71999b6e64d1f1919b0351b27c1c417e2b8856 Mon Sep 17 00:00:00 2001
+From be8a47e0c21e5577d4f5669d339dfec6299b25be Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Thu, 14 Feb 2019 18:06:25 +0100
 Subject: [PATCH] Generate loaders.cache using a native tool when
@@ -10,37 +10,29 @@ Upstream-Status: Pending
 Signed-off-by: Alexander Kanavin 
 
 ---
- gdk-pixbuf/meson.build | 13 +
- 1 file changed, 13 insertions(+)
+ gdk-pixbuf/meson.build | 12 ++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
 
 diff --git a/gdk-pixbuf/meson.build b/gdk-pixbuf/meson.build
-index 1995ffd..d692cb7 100644
+index 5cddbec..78c8bd3 100644
 --- a/gdk-pixbuf/meson.build
 +++ b/gdk-pixbuf/meson.build
-@@ -291,6 +291,7 @@ foreach bin: gdkpixbuf_bin
-   set_variable(bin_name.underscorify(), bin)
- endforeach
- 
-+if not meson.is_cross_build()
- # The 'loaders.cache' used for testing, so we don't accidentally
- # load the installed cache; we always build it by default
- loaders_cache = custom_target('loaders.cache',
-@@ -302,6 +303,18 @@ loaders_cache = custom_target('loaders.cache',
-   ],
-   build_by_default: true)
- loaders_dep = declare_dependency(sources: [ loaders_cache ])
-+else
-+loaders_cache = custom_target('loaders.cache',
-+  output: 'loaders.cache',
-+  capture: true,
-+  depends: [ dynamic_loaders_dep ],
-+  command: [
-+'gdk-pixbuf-query-loaders',
-+dynamic_loaders,
-+  ],
-+  build_by_default: true)
-+loaders_dep = declare_dependency(sources: [ loaders_cache ])
-+endif
+@@ -324,8 +324,16 @@ if not meson.is_cross_build()
+ build_by_default: true)
+   loaders_dep = declare_dependency(sources: [ loaders_cache ])
+ else
+-  loaders_cache = []
+-  loaders_dep = declare_dependency()
++  loaders_cache = custom_target('loaders.cache',
++output: 'loaders.cache',
++capture: true,
++command: [
++  'gdk-pixbuf-query-loaders',
++  dynamic_loaders,
++],
++depends: dynamic_loaders_dep,
++build_by_default: true)
++  loaders_dep = declare_dependency(sources: [ loaders_cache ])
+ endif
  
  pkgconfig = import('pkgconfig')
- pkgconfig.generate(
diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-loaders.cache-depend-on-loaders-being-fully-build.patch
 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-loaders.cache-depend-on-loaders-being-fully-build.patch
deleted file mode 100644
index 2a7751511bb..000
--- 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-loaders.cache-depend-on-loaders-being-fully-build.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 116bc8f7a6034ce43053876a72a132fcd4e1e472 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Wed, 20 Feb 2019 19:53:07 +0100
-Subject: [PATCH] loaders.cache: depend on loaders being fully build
-
-Otherwise, races have been observed:
-https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/310/steps/7/logs/step1b
-
-Upstream-Status: Pending
-Signed-off-by: Alexander Kanavin 
-

- gdk-pixbuf/meson.build | 4 
- 1 file changed, 4 insertions(+)
-
-diff 

Re: [OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Burton, Ross]

On Tue, 11 Jun 2019 at 15:27, Quentin Schulz
 wrote:
> +from oeqa.core.decorator.oeid import OETestID

This was removed a while ago, can you rebase the patches on top of
master please?

In this case you can just remove the import, but please verify the
behaviour with master.

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

[OE-core] Yocto Project Status WW24'19

[Richard Purdie]

Current Dev Position: YP 2.8 M2Next Deadline: YP 2.8 Milestone 2 Cutoff
July 14th, 2019
SWAT Team Rotation: * SWAT lead is currently: Anuj
 * SWAT team rotation: Anuj -> Paul on June 14, 2019
 * SWAT team rotation: Paul -> Ross on June 21, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday June 13th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday July 2nd at 8am PDT (
https://zoom.us/j/990892712) 
 * Twitch - Next event is Tuesday 11th June at 8am PDT (
https://www.twitch.tv/yocto_project)

Key Status/Updates: * 2.8 M1 has been built and rc2 is now undergoing
QA (rc1 ran into an issue with a broken autobuilder worker).
 * Stephen continues to be unavailable, please refer any queries to
Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. This shouldn’t impact users directly, more details will be sent
to the mailing lists before the transfer. THe Yocto Project lists will
move first, followed by OE, likely a week later.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * We’re seeing an increasing number of intermittent failures which
affect the autobuilder builds, causing problems for merging patches and
for release builds. One cause, a long standing problem with gpg signing
testing has finally been root caused and fixed. Several others keep
appearing. There is a backlog of them in the bugzilla and we’re opening
bugs for the new ones.
 * M1 isn’t of ideal quality, there are three ptest timeouts (2.7 had
none). The ptest failure rate is however much improved. There is nobody
actively working on some of the ptest timeout issues so holding the
milestone build wouldn’t have made much difference but its a worrying
sign for the project quality.
 * M1 also has a couple of MIPS issues with the gcc9 upgrade. There
doesn’t appear to be much interest in investigating and fixing these
which raises questions about supporting the architecture within the
project.
 * There was a Yocto Project related article in LWN: 
https://lwn.net/Articles/788626/

Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2478 (last week 2507) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1507 (last week 1513)
* Patches in the Pending State: 641 (43%) [last week 646 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
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!]





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

[OE-core] ✗ patchtest: failure for "[v4] meta: license: fix non-SP..." and 1 more

[Patchwork]

== Series Details ==

Series: "[v4] meta: license: fix non-SP..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/18087/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at f79c95f6a8)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH v4 2/2] selftests: add tests for INCOMPATIBLE_LICENSE

[Quentin Schulz]

One bug went unnoticed without these selftests: an INCOMPATIBLE_LICENSE
with a non-SPDX license for a package with that non-SPDX license wasn't
enforcing the denial of build for said package.

While adding a test for that particular case, let's add a few more so
that we cover a handful more use cases of INCOMPATIBLE_LICENSE.

Signed-off-by: Quentin Schulz 
---

added in v4

 .../license/incompatible-license-alias.bb |  3 ++
 .../license/incompatible-license.bb   |  3 ++
 .../license/incompatible-nonspdx-license.bb   |  3 ++
 .../oeqa/selftest/cases/incompatible_lic.py   | 42 +++
 4 files changed, 51 insertions(+)
 create mode 100644 
meta-selftest/recipes-test/license/incompatible-license-alias.bb
 create mode 100644 meta-selftest/recipes-test/license/incompatible-license.bb
 create mode 100644 
meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb
 create mode 100644 meta/lib/oeqa/selftest/cases/incompatible_lic.py

diff --git a/meta-selftest/recipes-test/license/incompatible-license-alias.bb 
b/meta-selftest/recipes-test/license/incompatible-license-alias.bb
new file mode 100644
index 00..e0b4e13c26
--- /dev/null
+++ b/meta-selftest/recipes-test/license/incompatible-license-alias.bb
@@ -0,0 +1,3 @@
+SUMMARY = "Recipe with an alias of an SPDX license"
+DESCRIPTION = "Is licensed with an alias of an SPDX license to be used for 
testing"
+LICENSE = "GPLv3"
diff --git a/meta-selftest/recipes-test/license/incompatible-license.bb 
b/meta-selftest/recipes-test/license/incompatible-license.bb
new file mode 100644
index 00..1728ad76b7
--- /dev/null
+++ b/meta-selftest/recipes-test/license/incompatible-license.bb
@@ -0,0 +1,3 @@
+SUMMARY = "Recipe with an SPDX license"
+DESCRIPTION = "Is licensed with an SPDX license to be used for testing"
+LICENSE = "GPL-3.0"
diff --git a/meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb 
b/meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb
new file mode 100644
index 00..35af0966ef
--- /dev/null
+++ b/meta-selftest/recipes-test/license/incompatible-nonspdx-license.bb
@@ -0,0 +1,3 @@
+SUMMARY = "Recipe with a non-SPDX license"
+DESCRIPTION = "Is licensed with a non-SPDX license to be used for testing"
+LICENSE = "FooLicense"
diff --git a/meta/lib/oeqa/selftest/cases/incompatible_lic.py 
b/meta/lib/oeqa/selftest/cases/incompatible_lic.py
new file mode 100644
index 00..4e0d1f53d3
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/incompatible_lic.py
@@ -0,0 +1,42 @@
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake
+from oeqa.core.decorator.oeid import OETestID
+
+class IncompatibleLicenseTests(OESelftestTestCase):
+
+def test_lic(self, pn, pn_lic, lic):
+error_msg = 'ERROR: Nothing PROVIDES \'%s\'\n%s was skipped: it has an 
incompatible license: %s' % (pn, pn, pn_lic)
+
+self.write_config("INCOMPATIBLE_LICENSE += \"%s\"" % (lic))
+
+result = bitbake(pn, ignore_status=True)
+if error_msg not in result.output:
+raise AssertionError(result.output)
+
+# Verify that a package with an SPDX license (from SRC_DISTRIBUTE_LICENSES)
+# cannot be built when INCOMPATIBLE_LICENSE contains this SPDX license
+def test_incompatible_spdx_license(self):
+self.test_lic('incompatible-license', 'GPL-3.0', 'GPL-3.0')
+
+# Verify that a package with an SPDX license (from SRC_DISTRIBUTE_LICENSES)
+# cannot be built when INCOMPATIBLE_LICENSE contains an alias (in
+# SPDXLICENSEMAP) of this SPDX license
+def test_incompatible_alias_spdx_license(self):
+self.test_lic('incompatible-license', 'GPL-3.0', 'GPLv3')
+
+# Verify that a package with an alias (from SPDXLICENSEMAP) to an SPDX
+# license cannot be built when INCOMPATIBLE_LICENSE contains this SPDX
+# license
+def test_incompatible_spdx_license_alias(self):
+self.test_lic('incompatible-license-alias', 'GPLv3', 'GPL-3.0')
+
+# Verify that a package with an alias (from SPDXLICENSEMAP) to an SPDX
+# license cannot be built when INCOMPATIBLE_LICENSE contains this alias
+def test_incompatible_alias_spdx_license_alias(self):
+self.test_lic('incompatible-license-alias', 'GPLv3', 'GPLv3')
+
+# Verify that a package with a non-SPDX license (neither in
+# SRC_DISTRIBUTE_LICENSES nor in SPDXLICENSEMAP) cannot be built when
+# INCOMPATIBLE_LICENSE contains this license
+def test_incompatible_nonspdx_license(self):
+self.test_lic('incompatible-nonspdx-license', 'FooLicense', 
'FooLicense')
-- 
2.17.1

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

[OE-core] [PATCH v4 1/2] meta: license: fix non-SPDX license being removed from INCOMPATIBLE_LICENSE

[Quentin Schulz]

A non-SPDX license (which is not an alias to an SPDX license) cannot
currently be marked as incompatible in INCOMPATIBLE_LICENSE.
In the current state, we take all INCOMPATIBLE_LICENSE and pass them
through expand_wildcard_licenses which is only adding SPDX licenses that
match the glob regexp of what is in INCOMPATIBLE_LICENSE (be it a direct
match to an SPDX license or via an alias).

This does not work well with custom licenses.

E.g.:

foo.bb:
LICENSE = "FooLicense"

conf/local.conf:
INCOMPATIBLE_LICENSE = "FooLicense"

`bitbake foo`

Gives no warning, no error, builds and packages successfully, because
INCOMPATIBLE_LICENSE is basically empty since FooLicense is neither in
SPDXLICENSEMAP nor in SRC_DISTRIBUTE_LICENSES.

Let's add the original licenses to the list returned by
expand_wildcard_licenses to be able to handle the aforementioned case.

INCOMPATIBLE_LICENSE = "FooLicense GPLv2 GPLv3+" used to "resolve" to
"GPLv2 GPLv3". It now resolves to "FooLicense GPLv2 GPLv3 GPLv3+" which
fixes the issue with custom licenses not being in SPDXLICENSEMAP or
SRC_DISTRIBUTE_LICENSES and thus being left out of the blacklisted
licenses.

I needed to pass a list to expand_wildcard_licenses from the
license_image class instead of the current output of map() because the
operator [:] does not work on this kind of type, and list(map()) or
anything that iterates over map() actually moves the iterator and breaks
the forloop right after in expand_wildcard_licenses.

Signed-off-by: Quentin Schulz 
---

v3:
  - fix git context from v2, patch cleanly applies on master branch now,

v2:
  - fixed image building by replacing map(lambda) by a comprehensive list so
that we have a consistent input type for expand_wildcard_licenses,

 meta/classes/license.bbclass   | 2 +-
 meta/classes/license_image.bbclass | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index ed91a4b4db..adca881c85 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -268,7 +268,7 @@ def expand_wildcard_licenses(d, wildcard_licenses):
 wildcards from SPDXLICENSEMAP flags and SRC_DISTRIBUTE_LICENSES values.
 """
 import fnmatch
-licenses = []
+licenses = wildcard_licenses[:]
 spdxmapkeys = d.getVarFlags('SPDXLICENSEMAP').keys()
 for wld_lic in wildcard_licenses:
 spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 6fb76be48e..2cfda81c99 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -40,7 +40,7 @@ def write_license_files(d, license_manifest, pkg_dic, 
rootfs=True):
 import stat
 
 bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()
-bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
+bad_licenses = [canonical_license(d, l) for l in bad_licenses]
 bad_licenses = expand_wildcard_licenses(d, bad_licenses)
 
 with open(license_manifest, "w") as license_file:
-- 
2.17.1

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

Re: [OE-core] [PATCHv2] cmake: Avoid passing empty prefix to os.path.relpath

[Mike Crowe]

On Saturday 06 January 2018 at 20:16:18 +, Mike Crowe wrote:
> https://patchwork.openembedded.org/patch/145709/
> 
> On Wednesday 20 December 2017 at 10:28:22 +, Mike Crowe wrote:
> > On Monday 11 December 2017 at 13:45:26 +, Burton, Ross wrote:
> > > It was implicated in some build failures.  I'll re-add it and try again.
> > 
> > Thanks. Are the new results in? I had a poke about on autobuilder.yocto.io
> > but couldn't work out how to tell which builds this commit was included in.
> > Build 719 did not appear to include it.
> 
> Any more news?
> 
> Thanks.

Hi Ross,

It looks like this patch never made it in. It still applies. Please can you
try adding it again?

Thanks.

Mike.

>From c5b7a0584b6d37ecb28cd2aa3d9a9a80b0178e96 Mon Sep 17 00:00:00 2001
From: Mike Crowe 
Date: Sun, 12 Nov 2017 14:16:20 +
Subject: [PATCHv2] cmake: Avoid passing empty prefix to os.path.relpath

With meta-micro, ${prefix} is the empty string. This means that
CMAKE_INSTALL_BINDIR:PATH and friends end up containing paths starting with
many instances of "../", presumably due to os.path.relpath attempting to
find its way to the current directory.

Let's avoid this by ensuring that the root path always ends in a slash. If
it already ends in a slash then adding another one shouldn't cause any
problems.

Signed-off-by: Mike Crowe 
Signed-off-by: Otavio Salvador 
---
 meta/classes/cmake.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index a5cffedbc6..f80a7e2f1d 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -161,15 +161,15 @@ cmake_do_configure() {
  $oecmake_sitefile \
  ${OECMAKE_SOURCEPATH} \
  -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'), 
d.getVar('prefix'))} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'), 
d.getVar('prefix'))} \
- 
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'), 
d.getVar('prefix'))} \
+ -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'), 
d.getVar('prefix') + '/')} \
+ -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'), 
d.getVar('prefix') + '/')} \
+ 
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'), 
d.getVar('prefix') + '/')} \
  -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- 
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
 d.  getVar('prefix'))} \
+ 
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
 d.  getVar('prefix') + '/')} \
  -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix'))} \
- 
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix'))} \
- 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix'))} \
+ -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix') + '/')} \
+ 
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix') + '/')} \
+ 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix') + '/')} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
--
2.20.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic/plugins: kernel image refer to KERNEL_IMAGETYPE

[Tom Rini]

On Tue, Jun 11, 2019 at 02:31:37PM +0800, chee.yang@intel.com wrote:

> From: Chee Yang Lee 
> 
> replaced hardcoded kernel image with KERNEL_IMAGETYPE.
> set kernel image to "bzImage" incase KERNEL_IMAGETYPE not set.
> 
> Signed-off-by: Chee Yang Lee 

I could see this being useful down the line (if not now..) for UEFI
images, but aarch64, so a good idea.

Reviewed-by: Tom Rini 

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

Re: [OE-core] [PATCH v3] meta: license: fix non-SPDX license being removed from INCOMPATIBLE_LICENSE

[Burton, Ross]

What would be really useful is a small selftest
(meta/lib/oeqa/selftest/cases) to exercise this codepath.  Have a test
that should work but doesn't before the fix, so the bug is
demonstrated and verified.

Ross

On Tue, 11 Jun 2019 at 09:13, Quentin Schulz
 wrote:
>
> A non-SPDX license (which is not an alias to an SPDX license) cannot
> currently be marked as incompatible in INCOMPATIBLE_LICENSE.
> In the current state, we take all INCOMPATIBLE_LICENSE and pass them
> through expand_wildcard_licenses which is only adding SPDX licenses that
> match the glob regexp of what is in INCOMPATIBLE_LICENSE (be it a direct
> match to an SPDX license or via an alias).
>
> This does not work well with custom licenses.
>
> E.g.:
>
> foo.bb:
> LICENSE = "FooLicense"
>
> conf/local.conf:
> INCOMPATIBLE_LICENSE = "FooLicense"
>
> `bitbake foo`
>
> Gives no warning, no error, builds and packages successfully, because
> INCOMPATIBLE_LICENSE is basically empty since FooLicense is neither in
> SPDXLICENSEMAP nor in SRC_DISTRIBUTE_LICENSES.
>
> Let's add the original licenses to the list returned by
> expand_wildcard_licenses to be able to handle the aforementioned case.
>
> INCOMPATIBLE_LICENSE = "FooLicense GPLv2 GPLv3+" used to "resolve" to
> "GPLv2 GPLv3". It now resolves to "FooLicense GPLv2 GPLv3 GPLv3+" which
> fixes the issue with custom licenses not being in SPDXLICENSEMAP or
> SRC_DISTRIBUTE_LICENSES and thus being left out of the blacklisted
> licenses.
>
> I needed to pass a list to expand_wildcard_licenses from the
> license_image class instead of the current output of map() because the
> operator [:] does not work on this kind of type, and list(map()) or
> anything that iterates over map() actually moves the iterator and breaks
> the forloop right after in expand_wildcard_licenses.
>
> Signed-off-by: Quentin Schulz 
> ---
>
> v3:
>   - fix git context from v2, patch cleanly applies on master branch now,
>
> v2:
>   - fixed image building by replacing map(lambda) by a comprehensive list so
> that we have a consistent input type for expand_wildcard_licenses,
>
>  meta/classes/license.bbclass   | 2 +-
>  meta/classes/license_image.bbclass | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index ed91a4b4db..adca881c85 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -268,7 +268,7 @@ def expand_wildcard_licenses(d, wildcard_licenses):
>  wildcards from SPDXLICENSEMAP flags and SRC_DISTRIBUTE_LICENSES values.
>  """
>  import fnmatch
> -licenses = []
> +licenses = wildcard_licenses[:]
>  spdxmapkeys = d.getVarFlags('SPDXLICENSEMAP').keys()
>  for wld_lic in wildcard_licenses:
>  spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
> diff --git a/meta/classes/license_image.bbclass 
> b/meta/classes/license_image.bbclass
> index 6fb76be48e..2cfda81c99 100644
> --- a/meta/classes/license_image.bbclass
> +++ b/meta/classes/license_image.bbclass
> @@ -40,7 +40,7 @@ def write_license_files(d, license_manifest, pkg_dic, 
> rootfs=True):
>  import stat
>
>  bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()
> -bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
> +bad_licenses = [canonical_license(d, l) for l in bad_licenses]
>  bad_licenses = expand_wildcard_licenses(d, bad_licenses)
>
>  with open(license_manifest, "w") as license_file:
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] multiconfig: Adapt to bitbake switch 'multiconfig' -> 'mc'

[Alejandro Hernandez]

On 6/7/2019 9:30 AM, Joshua Watt wrote:

On 6/7/19 11:23 AM, richard.pur...@linuxfoundation.org wrote:

On Fri, 2019-06-07 at 10:51 -0500, Joshua Watt wrote:

Is there a reason for this change other than aesthetics?

I have had a lot of complaints and in real world use I can understand
why...


FWIW, we maintain some recipes across several versions of poky, so
this rename is going to cause me some headaches

The mcdepends code is tollerant of either naming. We could teach cooker
to translate any commandline references so both worked there. Would
that be good enough to work for you?


Ya, that would be sufficient. I'll work up a patch for that.


I believe that I originally named it 'multiconfig' to try to make it 
more explicit for users,


but if people think its more intuitive to use 'mc' I'm not against it, 
using either also


works for me.


Cheers,

Alejandro






Cheers,

Richard


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

[OE-core] [PATCH] python-nose: python3-nose should be default

[Ross Burton]

We have nose recipes for both Py2 and Py3, but they both want to ship the
unversioned nosetest binary.  As Py2 is approaching EOL, remove the unversioned
binary from python-nose (leaving nosetest-2.7) instead of renaming the binary to
nosetest3 in python3-nose.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/python/python-nose_1.3.7.bb  | 4 
 meta/recipes-devtools/python/python3-nose_1.3.7.bb | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/python/python-nose_1.3.7.bb 
b/meta/recipes-devtools/python/python-nose_1.3.7.bb
index 6d69d2d62e2..fab609df901 100644
--- a/meta/recipes-devtools/python/python-nose_1.3.7.bb
+++ b/meta/recipes-devtools/python/python-nose_1.3.7.bb
@@ -1,2 +1,6 @@
 inherit setuptools
 require python-nose.inc
+
+do_install_append() {
+rm ${D}${bindir}/nosetests
+}
diff --git a/meta/recipes-devtools/python/python3-nose_1.3.7.bb 
b/meta/recipes-devtools/python/python3-nose_1.3.7.bb
index 8bc1f49835e..13dbf96179a 100644
--- a/meta/recipes-devtools/python/python3-nose_1.3.7.bb
+++ b/meta/recipes-devtools/python/python3-nose_1.3.7.bb
@@ -1,6 +1,2 @@
 inherit setuptools3
 require python-nose.inc
-
-do_install_append() {
-mv ${D}${bindir}/nosetests ${D}${bindir}/nosetests3
-}
-- 
2.11.0

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

Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Alexander Kanavin]

On Tue, 11 Jun 2019 at 03:58, Douglas Royds via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> Upstream json-c haven't made a release since March 2018.
> Adopt the current HEAD revision, pulling it directly from git.
>

You should ask the upstream to make a new version then. Pulling a random
git commit is the wrong thing to do.

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

Re: [OE-core] [PATCH] gnome.bbclass: inherit upstream-version-is-even

[Kang Kai]

On 2019/6/11 下午4:41, Richard Purdie wrote:

On Tue, 2019-06-11 at 04:37 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

According to gnome versioning policy, "Even/odd minor package
versions
can be used respectively for stable/unstable releases.". Make
gnome.bbclass inherit upstream-version-is-even to comply with the
policy.

Ref:
https://developer.gnome.org/programming-guidelines/stable/versioning.html.en#stable-unstable-versions

Signed-off-by: Kai Kang 
---
  meta/classes/gnome.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

The question is whether all recipes using the gnome class use the gnome
version policy? I'm not sure that is true?


My thought was gnome.bbclass inherits gnonebase.bbclass which means the 
sources from gnome and should comply the version policy of gnome.
But I check it again and find that some packages override the SRC_URI 
such as pavucontrol which doesn't obey the policy. Please ignore it.



Thanks,
Kai




Cheers,

Richard






--
Kai Kang

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

[OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[zhe.he]

From: He Zhe 

For the moment,
0001~0004 are on master branch only.
0005~0007 are on stable-2.11 branch, but v2.11 has not been released yet.

Signed-off-by: He Zhe 
---
v2: Correct a typo in SOB for 0001*.patch

 ...ove-wrapper-definitions-for-obsolete-RCU..patch |  47 
 ...ix-timer-trace-Improve-timer-tracing-v5.2.patch |  80 +++
 .../0003-Fix-pipe-stop-using-can_merge-v5.1.patch  |  42 
 ...ix-mm-create-the-new-vm_fault_t-type-v5.1.patch |  65 ++
 ...an-drop-may_writepage-and-classzone_idx-f.patch |  92 
 ...only-read-from-dev-random-after-its-pool-.patch |  76 ++
 ...start-and-number-from-syscall_get_argumen.patch | 259 +
 meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb  |   7 +
 8 files changed, 668 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-Fix-pipe-stop-using-can_merge-v5.1.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-Fix-mm-create-the-new-vm_fault_t-type-v5.1.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0005-fix-mm-vmscan-drop-may_writepage-and-classzone_idx-f.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0006-fix-random-only-read-from-dev-random-after-its-pool-.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0007-Fix-Remove-start-and-number-from-syscall_get_argumen.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
new file mode 100644
index 000..de572a9
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
@@ -0,0 +1,47 @@
+From 92da05ce1f73488a57e7fd79e9c03113cefdb76f Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Mon, 18 Mar 2019 16:20:33 -0400
+Subject: [PATCH] Fix: rcu: Remove wrapper definitions for obsolete RCU...
+ (v5.1)
+
+See upstream commit :
+
+commit 6ba7d681aca22e53385bdb35b1d7662e61905760
+Author: Paul E. McKenney 
+Date:   Wed Jan 9 15:22:03 2019 -0800
+
+rcu: Remove wrapper definitions for obsolete RCU update functions
+
+None of synchronize_rcu_bh, synchronize_rcu_bh_expedited, call_rcu_bh,
+rcu_barrier_bh, synchronize_sched, synchronize_sched_expedited,
+call_rcu_sched, rcu_barrier_sched, get_state_synchronize_sched, and
+cond_synchronize_sched are actually used.  This commit therefore removes
+their trivial wrapper-function definitions.
+
+Signed-off-by: Mathieu Desnoyers 
+Upstream-Status: Backport
+Signed-off-by: He Zhe 
+---
+ lttng-events.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/lttng-events.c b/lttng-events.c
+index 566080a..f4206c5 100644
+--- a/lttng-events.c
 b/lttng-events.c
+@@ -75,7 +75,12 @@ int _lttng_field_statedump(struct lttng_session *session,
+ 
+ void synchronize_trace(void)
+ {
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,1,0))
++  synchronize_rcu();
++#else
+   synchronize_sched();
++#endif
++
+ #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,4,0))
+ #ifdef CONFIG_PREEMPT_RT_FULL
+   synchronize_rcu();
+-- 
+2.7.4
+
diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
new file mode 100644
index 000..e782ee0
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
@@ -0,0 +1,80 @@
+From d88e2fe5c3ea0d2c3055fba824be17223c418854 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Tue, 21 May 2019 16:33:10 -0400
+Subject: [PATCH] fix: timer/trace: Improve timer tracing (v5.2)
+
+See upstream commit:
+
+  commit f28d3d5346e97e60c81f933ac89ccf015430e5cf
+  Author: Anna-Maria Gleixner 
+  Date:   Thu Mar 21 13:09:21 2019 +0100
+
+timer/trace: Improve timer tracing
+
+Timers are added to the timer wheel off by one. This is required in
+case a timer is queued directly before incrementing jiffies to prevent
+early timer expiry.
+
+When reading a timer trace and relying only on the expiry time of the timer
+in the timer_start trace point and on the now in the timer_expiry_entry
+trace point, it seems that the timer fires late. With the current
+timer_expiry_entry trace point information only now=jiffies is printed but
+not the value of base->clk. This makes it impossible to draw a conclusion
+to the index of base->clk and makes it impossible to examine timer problems
+without additional trace points.
+
+Therefore add the base->clk value to the timer_expire_entry trace
+

Re: [OE-core] [PATCH] multiconfig: Adapt to bitbake switch 'multiconfig' -> 'mc'

[richard . purdie]

On Mon, 2019-06-10 at 10:53 -0700, Alejandro Hernandez wrote:
> On 6/7/2019 9:30 AM, Joshua Watt wrote:
> > On 6/7/19 11:23 AM, richard.pur...@linuxfoundation.org wrote:
> > > On Fri, 2019-06-07 at 10:51 -0500, Joshua Watt wrote:
> > > > Is there a reason for this change other than aesthetics?
> > > I have had a lot of complaints and in real world use I can
> > > understand
> > > why...
> > > 
> > > > FWIW, we maintain some recipes across several versions of poky,
> > > > so
> > > > this rename is going to cause me some headaches
> > > The mcdepends code is tollerant of either naming. We could teach
> > > cooker
> > > to translate any commandline references so both worked there.
> > > Would
> > > that be good enough to work for you?
> > 
> > Ya, that would be sufficient. I'll work up a patch for that.
> 
> I believe that I originally named it 'multiconfig' to try to make it 
> more explicit for users,

I remember the discussions and I was fairly strongly in favour of
"multiconfig" as well...

> but if people think its more intuitive to use 'mc' I'm not against
> it, using either also works for me.

On balance its proving annoying to people and the feedback I'm getting
is people strongly prefer "mc:", even if it makes me think midnight
commander! :)

Cheers,

Richard

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

[OE-core] [PATCH] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[zhe.he]

From: He Zhe 

For the moment,
0001~0004 are on master branch only.
0005~0007 are on stable-2.11 branch, but v2.11 has not been released yet.

Signed-off-by: He Zhe 
---
 ...ove-wrapper-definitions-for-obsolete-RCU..patch |  47 
 ...ix-timer-trace-Improve-timer-tracing-v5.2.patch |  80 +++
 .../0003-Fix-pipe-stop-using-can_merge-v5.1.patch  |  42 
 ...ix-mm-create-the-new-vm_fault_t-type-v5.1.patch |  65 ++
 ...an-drop-may_writepage-and-classzone_idx-f.patch |  92 
 ...only-read-from-dev-random-after-its-pool-.patch |  76 ++
 ...start-and-number-from-syscall_get_argumen.patch | 259 +
 meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb  |   7 +
 8 files changed, 668 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-Fix-pipe-stop-using-can_merge-v5.1.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-Fix-mm-create-the-new-vm_fault_t-type-v5.1.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0005-fix-mm-vmscan-drop-may_writepage-and-classzone_idx-f.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0006-fix-random-only-read-from-dev-random-after-its-pool-.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0007-Fix-Remove-start-and-number-from-syscall_get_argumen.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
new file mode 100644
index 000..385af52
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
@@ -0,0 +1,47 @@
+From 92da05ce1f73488a57e7fd79e9c03113cefdb76f Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Mon, 18 Mar 2019 16:20:33 -0400
+Subject: [PATCH] Fix: rcu: Remove wrapper definitions for obsolete RCU...
+ (v5.1)
+
+See upstream commit :
+
+commit 6ba7d681aca22e53385bdb35b1d7662e61905760
+Author: Paul E. McKenney 
+Date:   Wed Jan 9 15:22:03 2019 -0800
+
+rcu: Remove wrapper definitions for obsolete RCU update functions
+
+None of synchronize_rcu_bh, synchronize_rcu_bh_expedited, call_rcu_bh,
+rcu_barrier_bh, synchronize_sched, synchronize_sched_expedited,
+call_rcu_sched, rcu_barrier_sched, get_state_synchronize_sched, and
+cond_synchronize_sched are actually used.  This commit therefore removes
+their trivial wrapper-function definitions.
+
+Signed-off-by: Mathieu Desnoyers 
+Upstream-Status: Backport
+igned-off-by: He Zhe 
+---
+ lttng-events.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/lttng-events.c b/lttng-events.c
+index 566080a..f4206c5 100644
+--- a/lttng-events.c
 b/lttng-events.c
+@@ -75,7 +75,12 @@ int _lttng_field_statedump(struct lttng_session *session,
+ 
+ void synchronize_trace(void)
+ {
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,1,0))
++  synchronize_rcu();
++#else
+   synchronize_sched();
++#endif
++
+ #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,4,0))
+ #ifdef CONFIG_PREEMPT_RT_FULL
+   synchronize_rcu();
+-- 
+2.7.4
+
diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
new file mode 100644
index 000..e782ee0
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
@@ -0,0 +1,80 @@
+From d88e2fe5c3ea0d2c3055fba824be17223c418854 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Tue, 21 May 2019 16:33:10 -0400
+Subject: [PATCH] fix: timer/trace: Improve timer tracing (v5.2)
+
+See upstream commit:
+
+  commit f28d3d5346e97e60c81f933ac89ccf015430e5cf
+  Author: Anna-Maria Gleixner 
+  Date:   Thu Mar 21 13:09:21 2019 +0100
+
+timer/trace: Improve timer tracing
+
+Timers are added to the timer wheel off by one. This is required in
+case a timer is queued directly before incrementing jiffies to prevent
+early timer expiry.
+
+When reading a timer trace and relying only on the expiry time of the timer
+in the timer_start trace point and on the now in the timer_expiry_entry
+trace point, it seems that the timer fires late. With the current
+timer_expiry_entry trace point information only now=jiffies is printed but
+not the value of base->clk. This makes it impossible to draw a conclusion
+to the index of base->clk and makes it impossible to examine timer problems
+without additional trace points.
+
+Therefore add the base->clk value to the timer_expire_entry trace
+point, to be able to calculate the index the 

[OE-core] [PATCH] tune-thunderx: Set the correct PACKAGE_EXTRA_ARCHS_tune-thunderx

[Kevin Hao]

The value of PACKAGE_EXTRA_ARCHS_tune-thunderx should be based on
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto instead of armv8a-crc-crypto.
Otherwise we would get some sanity check error like this:
OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker 
(see sanity.conf).
Following is the list of potential problems / advisories:

Error, the PACKAGE_ARCHS variable (all any noarch armv8a-crc-crypto 
thunderx qemuarm64) for DEFAULTTUNE (thunderx) does not contain TUNE_PKGARCH 
(aarch64)

Signed-off-by: Kevin Hao 
---
 meta/conf/machine/include/tune-thunderx.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/tune-thunderx.inc 
b/meta/conf/machine/include/tune-thunderx.inc
index 92adf2df1fce..aa4d0501d400 100644
--- a/meta/conf/machine/include/tune-thunderx.inc
+++ b/meta/conf/machine/include/tune-thunderx.inc
@@ -15,5 +15,5 @@ TUNE_FEATURES_tune-thunderx_be = 
"${TUNE_FEATURES_tune-thunderx} bigendian"
 BASE_LIB_tune-thunderx = "lib64"
 BASE_LIB_tune-thunderx_be = "lib64"
 
-PACKAGE_EXTRA_ARCHS_tune-thunderx = "armv8a-crc-crypto thunderx"
+PACKAGE_EXTRA_ARCHS_tune-thunderx = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} thunderx"
 PACKAGE_EXTRA_ARCHS_tune-thunderx_be = "aarch64_be thunderx_be"
-- 
2.14.4

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

Re: [OE-core] [PATCH] gnome.bbclass: inherit upstream-version-is-even

[Richard Purdie]

On Tue, 2019-06-11 at 04:37 -0400, kai.k...@windriver.com wrote:
> From: Kai Kang 
> 
> According to gnome versioning policy, "Even/odd minor package
> versions
> can be used respectively for stable/unstable releases.". Make
> gnome.bbclass inherit upstream-version-is-even to comply with the
> policy.
> 
> Ref:
> https://developer.gnome.org/programming-guidelines/stable/versioning.html.en#stable-unstable-versions
> 
> Signed-off-by: Kai Kang 
> ---
>  meta/classes/gnome.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

The question is whether all recipes using the gnome class use the gnome
version policy? I'm not sure that is true?

Cheers,

Richard



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

[OE-core] [PATCH] gnome.bbclass: inherit upstream-version-is-even

[kai.kang]

From: Kai Kang 

According to gnome versioning policy, "Even/odd minor package versions
can be used respectively for stable/unstable releases.". Make
gnome.bbclass inherit upstream-version-is-even to comply with the
policy.

Ref:
https://developer.gnome.org/programming-guidelines/stable/versioning.html.en#stable-unstable-versions

Signed-off-by: Kai Kang 
---
 meta/classes/gnome.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/gnome.bbclass b/meta/classes/gnome.bbclass
index c6202bbb75..d3841e24ef 100644
--- a/meta/classes/gnome.bbclass
+++ b/meta/classes/gnome.bbclass
@@ -1 +1 @@
-inherit gnomebase gtk-icon-cache gconf mime
+inherit gnomebase gtk-icon-cache gconf mime upstream-version-is-even
-- 
2.20.0

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

[OE-core] [PATCH v3] meta: license: fix non-SPDX license being removed from INCOMPATIBLE_LICENSE

[Quentin Schulz]

A non-SPDX license (which is not an alias to an SPDX license) cannot
currently be marked as incompatible in INCOMPATIBLE_LICENSE.
In the current state, we take all INCOMPATIBLE_LICENSE and pass them
through expand_wildcard_licenses which is only adding SPDX licenses that
match the glob regexp of what is in INCOMPATIBLE_LICENSE (be it a direct
match to an SPDX license or via an alias).

This does not work well with custom licenses.

E.g.:

foo.bb:
LICENSE = "FooLicense"

conf/local.conf:
INCOMPATIBLE_LICENSE = "FooLicense"

`bitbake foo`

Gives no warning, no error, builds and packages successfully, because
INCOMPATIBLE_LICENSE is basically empty since FooLicense is neither in
SPDXLICENSEMAP nor in SRC_DISTRIBUTE_LICENSES.

Let's add the original licenses to the list returned by
expand_wildcard_licenses to be able to handle the aforementioned case.

INCOMPATIBLE_LICENSE = "FooLicense GPLv2 GPLv3+" used to "resolve" to
"GPLv2 GPLv3". It now resolves to "FooLicense GPLv2 GPLv3 GPLv3+" which
fixes the issue with custom licenses not being in SPDXLICENSEMAP or
SRC_DISTRIBUTE_LICENSES and thus being left out of the blacklisted
licenses.

I needed to pass a list to expand_wildcard_licenses from the
license_image class instead of the current output of map() because the
operator [:] does not work on this kind of type, and list(map()) or
anything that iterates over map() actually moves the iterator and breaks
the forloop right after in expand_wildcard_licenses.

Signed-off-by: Quentin Schulz 
---

v3:
  - fix git context from v2, patch cleanly applies on master branch now,

v2:
  - fixed image building by replacing map(lambda) by a comprehensive list so
that we have a consistent input type for expand_wildcard_licenses,

 meta/classes/license.bbclass   | 2 +-
 meta/classes/license_image.bbclass | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index ed91a4b4db..adca881c85 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -268,7 +268,7 @@ def expand_wildcard_licenses(d, wildcard_licenses):
 wildcards from SPDXLICENSEMAP flags and SRC_DISTRIBUTE_LICENSES values.
 """
 import fnmatch
-licenses = []
+licenses = wildcard_licenses[:]
 spdxmapkeys = d.getVarFlags('SPDXLICENSEMAP').keys()
 for wld_lic in wildcard_licenses:
 spdxflags = fnmatch.filter(spdxmapkeys, wld_lic)
diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 6fb76be48e..2cfda81c99 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -40,7 +40,7 @@ def write_license_files(d, license_manifest, pkg_dic, 
rootfs=True):
 import stat
 
 bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()
-bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
+bad_licenses = [canonical_license(d, l) for l in bad_licenses]
 bad_licenses = expand_wildcard_licenses(d, bad_licenses)
 
 with open(license_manifest, "w") as license_file:
-- 
2.17.1

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

[OE-core] [PATCH] wic/plugins: kernel image refer to KERNEL_IMAGETYPE

[chee . yang . lee]

From: Chee Yang Lee 

replaced hardcoded kernel image with KERNEL_IMAGETYPE.
set kernel image to "bzImage" incase KERNEL_IMAGETYPE not set.

Signed-off-by: Chee Yang Lee 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py   | 21 +++--
 scripts/lib/wic/plugins/source/bootimg-pcbios.py|  8 ++--
 .../lib/wic/plugins/source/isoimage-isohybrid.py| 21 ++---
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 70cc1b0..d87db1f 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -71,14 +71,16 @@ class BootimgEFIPlugin(SourcePlugin):
 grubefi_conf += "timeout=%s\n" % bootloader.timeout
 grubefi_conf += "menuentry '%s'{\n" % (title if title else "boot")
 
-kernel = "/bzImage"
+kernel = get_bitbake_var("KERNEL_IMAGETYPE")
+if not kernel:
+kernel = "bzImage"
 
 label = source_params.get('label')
 label_conf = "root=%s" % creator.rootdev
 if label:
 label_conf = "LABEL=%s" % label
 
-grubefi_conf += "linux %s %s rootwait %s\n" \
+grubefi_conf += "linux /%s %s rootwait %s\n" \
 % (kernel, label_conf, bootloader.append)
 
 if initrd:
@@ -143,12 +145,15 @@ class BootimgEFIPlugin(SourcePlugin):
 
 if not custom_cfg:
 # Create systemd-boot configuration using parameters from wks file
-kernel = "/bzImage"
+kernel = get_bitbake_var("KERNEL_IMAGETYPE")
+if not kernel:
+kernel = "bzImage"
+
 title = source_params.get('title')
 
 boot_conf = ""
 boot_conf += "title %s\n" % (title if title else "boot")
-boot_conf += "linux %s\n" % kernel
+boot_conf += "linux /%s\n" % kernel
 
 label = source_params.get('label')
 label_conf = "LABEL=Boot root=%s" % creator.rootdev
@@ -209,8 +214,12 @@ class BootimgEFIPlugin(SourcePlugin):
 
 hdddir = "%s/hdd/boot" % cr_workdir
 
-install_cmd = "install -m 0644 %s/bzImage %s/bzImage" % \
-(staging_kernel_dir, hdddir)
+kernel = get_bitbake_var("KERNEL_IMAGETYPE")
+if not kernel:
+kernel = "bzImage"
+
+install_cmd = "install -m 0644 %s/%s %s/%s" % \
+(staging_kernel_dir, kernel, hdddir, kernel)
 exec_cmd(install_cmd)
 
 
diff --git a/scripts/lib/wic/plugins/source/bootimg-pcbios.py 
b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
index 6c9f54a..670d347 100644
--- a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
+++ b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
@@ -149,8 +149,12 @@ class BootimgPcbiosPlugin(SourcePlugin):
 
 hdddir = "%s/hdd/boot" % cr_workdir
 
-cmds = ("install -m 0644 %s/bzImage %s/vmlinuz" %
-(staging_kernel_dir, hdddir),
+kernel = get_bitbake_var("KERNEL_IMAGETYPE")
+if not kernel:
+kernel = "bzImage"
+
+cmds = ("install -m 0644 %s/%s %s/vmlinuz" %
+(staging_kernel_dir, kernel, hdddir),
 "install -m 444 %s/syslinux/ldlinux.sys %s/ldlinux.sys" %
 (bootimg_dir, hdddir),
 "install -m 0644 %s/syslinux/vesamenu.c32 %s/vesamenu.c32" %
diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 96d07ff..74d6f14 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -70,8 +70,10 @@ class IsoImagePlugin(SourcePlugin):
 syslinux_conf += "DEFAULT boot\n"
 syslinux_conf += "LABEL boot\n"
 
-kernel = "/bzImage"
-syslinux_conf += "KERNEL " + kernel + "\n"
+kernel = get_bitbake_var("KERNEL_IMAGETYPE")
+if not kernel:
+kernel = "bzImage"
+syslinux_conf += "KERNEL /" + kernel + "\n"
 syslinux_conf += "APPEND initrd=/initrd LABEL=boot %s\n" \
  % bootloader.append
 
@@ -114,9 +116,11 @@ class IsoImagePlugin(SourcePlugin):
 grubefi_conf += "\n"
 grubefi_conf += "menuentry 'boot'{\n"
 
-kernel = "/bzImage"
+kernel = get_bitbake_var("KERNEL_IMAGETYPE")
+if not kernel:
+kernel = "bzImage"
 
-grubefi_conf += "linux %s rootwait %s\n" \
+grubefi_conf += "linux /%s rootwait %s\n" \
 % (kernel, bootloader.append)
 grubefi_conf += "initrd /initrd \n"
 grubefi_conf += "}\n"
@@ -268,9 +272,12 @@ class IsoImagePlugin(SourcePlugin):
 if os.path.isfile("%s/initrd.cpio.gz" % cr_workdir):
 os.remove("%s/initrd.cpio.gz" % cr_workdir)
 

[OE-core] [PATCH] gstreamer1.0-python_1.16.0.bb: Override libpython dir

[Jaewon Lee]

As mentioned in upstream commit a2cf84a8a78fdaa8fabcfa9b40be1936678e,
"gstpythonplugin hardcodes the location of the libpython from the build
workspace and then fails at runtime."

In other words, PYTHON_LIB_LOC was set to the recipe-sysroot-native dir
in the gstreamer1.0-python workspace on the host. Overriding
PYTHON_LIB_LOC with /usr/lib by adding --with-libpython-dir=${libdir} to
EXTRA_OECONF to fix this issue.

The error that was seen is:
** (gst-plugin-scanner:2343): CRITICAL **: 23:08:18.327: Couldn't
g_module_open libpython. Reason: ${project}/build/tmp/work/${arch}/
gstreamer1.0-python/1.14.4-r0/recipe-sysroot-native/usr/lib/libpython3.5m.so:
cannot open shared object file: No such file or directory

The comment continues and says "it still fails because it looks for
a symlinked library ending in .so instead of the actually library with
LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
we want, it will break again if the library version ever changes."
This isn't the case anymore as the package is deploying
/usr/lib/gstreamer-1.0/libgstpython.cpython-37m-i386-linux-gnu.so, a
versionless so.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 .../gstreamer/gstreamer1.0-python_1.16.0.bb  | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb
index af9f3f2..0f3aac1 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb
@@ -22,16 +22,10 @@ UNKNOWN_CONFIGURE_WHITELIST_append = " 
--enable-introspection --disable-introspe
 
 inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection distro_features_check
 
+EXTRA_OECONF += "--with-libpython-dir=${libdir}"
+
 do_install_append() {
-# gstpythonplugin hardcodes the location of the libpython from the build
-# workspace and then fails at runtime. We can override it using
-# --with-libpython-dir=${libdir}, but it still fails because it looks for a
-# symlinked library ending in .so instead of the actually library with
-# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
-# we want, it will break again if the library version ever changes. We need
-# to think about the best way of handling this and possibly consult
-# upstream.
-#
+
 # Note that this particular find line is taken from the Debian packaging 
for
 # gst-python1.0.
 find "${D}" \
-- 
2.7.4

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

[OE-core] [PATCH] json-c: Backport --disable-werror patch to allow compilation under icecc

[Douglas Royds via Openembedded-core]

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthough */
comments in switch statements that normally prevent an implicit-fallthrough
warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror, the upstream project has implemented a
configure option, --disable-werror, in response to Ross's
https://github.com/json-c/json-c/issues/489

This patch from
https://github.com/json-c/json-c/commit/21c886534f8927fdc0fb5f8647394f3e0e0874b8

Upstream-Status: Backport [Not yet released]
Signed-off-by: Douglas Royds 
---
 ...d-disable-werror-option-to-configure.patch | 45 +++
 meta/recipes-devtools/json-c/json-c_0.13.1.bb |  8 +++-
 2 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch

diff --git 
a/meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch
 
b/meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch
new file mode 100644
index 00..0c20c8458a
--- /dev/null
+++ 
b/meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch
@@ -0,0 +1,45 @@
+json-c: Backport --disable-werror patch to allow compilation under icecc
+
+icecc preprocesses source files locally before shipping them off to be compiled
+on remote hosts. This preprocessing removes comments, including /* fallthough 
*/
+comments in switch statements that normally prevent an implicit-fallthrough
+warning, see https://github.com/icecc/icecream/issues/419
+
+Rather than turning off -Werror, the upstream project has implemented a
+configure option, --disable-werror, in response to Ross's
+https://github.com/json-c/json-c/issues/489
+
+This patch from
+https://github.com/json-c/json-c/commit/21c886534f8927fdc0fb5f8647394f3e0e0874b8
+
+Upstream-Status: Backport [Not yet released]
+Signed-off-by: Douglas Royds 
+
+From 21c886534f8927fdc0fb5f8647394f3e0e0874b8 Mon Sep 17 00:00:00 2001
+From: Pierce Lopez 
+Date: Sun, 9 Jun 2019 10:52:08 -0400
+Subject: [PATCH] build: add --disable-werror option to configure
+
+to omit -Werror compiler option
+---
+ configure.ac | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 272ea6af9c..798fd5b747 100644
+--- a/configure.ac
 b/configure.ac
+@@ -165,7 +165,12 @@ AS_IF([test "x$enable_Bsymbolic" = "xcheck"],
+ AS_IF([test "x$enable_Bsymbolic" = "xyes"], 
[JSON_BSYMBOLIC_LDFLAGS=-Wl[,]-Bsymbolic-functions])
+ AC_SUBST(JSON_BSYMBOLIC_LDFLAGS)
+ 
+-AX_APPEND_COMPILE_FLAGS([-Wall -Werror -Wcast-qual 
-Wno-error=deprecated-declarations])
++AC_ARG_ENABLE([werror],
++AS_HELP_STRING([--disable-werror], [avoid treating compiler warnings as 
fatal errors]))
++
++AS_IF([test "x$enable_werror" != "xno"], [AX_APPEND_COMPILE_FLAGS([-Werror])])
++
++AX_APPEND_COMPILE_FLAGS([-Wall -Wcast-qual 
-Wno-error=deprecated-declarations])
+ AX_APPEND_COMPILE_FLAGS([-Wextra -Wwrite-string -Wno-unused-parameter])
+ AX_APPEND_COMPILE_FLAGS([-D_GNU_SOURCE])
+ 
diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..9d8f2e7870 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -4,7 +4,9 @@ HOMEPAGE = "https://github.com/json-c/json-c/wiki;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
 
-SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz \
+   file://add-disable-werror-option-to-configure.patch \
+   "
 SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
 SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"
 
@@ -20,7 +22,9 @@ RPROVIDES_${PN} = "libjson"
 
 inherit autotools
 
-EXTRA_OECONF = "--enable-rdrand"
+EXTRA_OECONF = "--disable-werror \
+--enable-rdrand \
+"
 
 do_configure_prepend() {
 # Clean up autoconf cruft that should not be in the tarball
-- 
2.17.1

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