Re: [OE-core] [PATCH 2/4] scons.bbclass: use python3-scons

2019-06-20 Thread Khem Raj
On Thu, Jun 20, 2019 at 6:18 PM Tim Orling  wrote:

>
>
> On Thu, Jun 20, 2019 at 6:37 AM Khem Raj  wrote:
>
>> On Fri, Jun 7, 2019 at 5:50 PM Tim Orling
>>  wrote:
>> >
>> > SCons has supported python3 since 3.0.0 release, use it.
>> >
>> > [YOCTO #13381]
>> >
>> > Signed-off-by: Tim Orling 
>> > ---
>> >  meta/classes/scons.bbclass | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/meta/classes/scons.bbclass b/meta/classes/scons.bbclass
>> > index 9ee7d1587d..a8ddae35f7 100644
>> > --- a/meta/classes/scons.bbclass
>> > +++ b/meta/classes/scons.bbclass
>> > @@ -1,4 +1,4 @@
>> > -DEPENDS += "python-scons-native"
>> > +DEPENDS += "python3-scons-native"
>> >
>>
>> some packages haven't upgraded to py3 but use scons see
>> https://errors.yoctoproject.org/Errors/Details/249271/
>>
>
>
> Thank you for reporting this. I was of course expecting some breakage and
> am committed to fixes. Please do report any other issues.
>
> Latest mongo release appears to be 4.3.0 and appears to support python3:
>
>
> https://github.com/mongodb/mongo/blob/89e7419a897b2270931c9c029abf6de555d83e0f/SConstruct
>
> Is this an aceptable upgrade? I am not savvy on which versions are
> desirable.
>

Yes for master this upgrade is fine

>
>
>> >  EXTRA_OESCONS ?= ""
>> >
>> > --
>> > 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
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/2] update-rc.d: support enable/disable options

2019-06-20 Thread changqing.li
From: Changqing Li 

* update-rc.d has added support of enable/disable options, which are
  expected to keep the previous configuration even after upgrade the packages.
  With support for these options, it will only create start/stop link
  when there are none, or it will keep the previous configuration.

  Our preinst uses "-f remove" to remove any links under the /etc/rcrunlevel.d
  which is conflicting behavior with disable/enable options, so remove it.

  For example, if a user disabled one service before upgrade,
  then after upgrade the service could be started. This happens because during 
preinst,
  all links have been deleted, then postinst may create the link to start 
service.

  With this change, we remove preinst and therefore keep the previous links
  so that after upgrade, if a link existed for the package, then the postinst
  will not create new start/stop links.

* remove '-f' for postinst. Previously, the keepalived recipe used 'remove'
  during postinst, so we needed the -f, but now the keepalived recipe has fixed
  this problem, so it's safe to remove '-f'.

[Yocto #12955]

Signed-off-by: Changqing Li 
---
 meta/classes/update-rc.d.bbclass | 28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 265c4be..1366fee 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -20,28 +20,14 @@ def use_updatercd(d):
 return '[ -n "$D" -o ! -d /run/systemd/system ]'
 return 'true'
 
-updatercd_preinst() {
-if ${@use_updatercd(d)} && [ -z "$D" -a -f "${INIT_D_DIR}/${INITSCRIPT_NAME}" 
]; then
-   ${INIT_D_DIR}/${INITSCRIPT_NAME} stop || :
-fi
-if ${@use_updatercd(d)} && type update-rc.d >/dev/null 2>/dev/null; then
-   if [ -n "$D" ]; then
-   OPT="-f -r $D"
-   else
-   OPT="-f"
-   fi
-   update-rc.d $OPT ${INITSCRIPT_NAME} remove
-fi
-}
-
 PACKAGE_WRITE_DEPS += "update-rc.d-native"
 
 updatercd_postinst() {
 if ${@use_updatercd(d)} && type update-rc.d >/dev/null 2>/dev/null; then
if [ -n "$D" ]; then
-   OPT="-f -r $D"
+   OPT="-r $D"
else
-   OPT="-f -s"
+   OPT="-s"
fi
update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
 fi
@@ -79,7 +65,7 @@ python __anonymous() {
 PACKAGESPLITFUNCS_prepend = "${@bb.utils.contains('DISTRO_FEATURES', 
'sysvinit', 'populate_packages_updatercd ', '', d)}"
 PACKAGESPLITFUNCS_remove_class-nativesdk = "populate_packages_updatercd "
 
-populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm 
updatercd_preinst updatercd_postinst"
+populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm 
updatercd_postinst"
 populate_packages_updatercd[vardepsexclude] += "OVERRIDES"
 
 python populate_packages_updatercd () {
@@ -95,7 +81,7 @@ python populate_packages_updatercd () {
 d.appendVar('RDEPENDS_' + pkg, ' %sinitd-functions' % (mlprefix))
 
 def update_rcd_package(pkg):
-bb.debug(1, 'adding update-rc.d calls to preinst/postinst/prerm/postrm 
for %s' % pkg)
+bb.debug(1, 'adding update-rc.d calls to postinst/prerm/postrm for %s' 
% pkg)
 
 localdata = bb.data.createCopy(d)
 overrides = localdata.getVar("OVERRIDES")
@@ -103,12 +89,6 @@ python populate_packages_updatercd () {
 
 update_rcd_auto_depend(pkg)
 
-preinst = d.getVar('pkg_preinst_%s' % pkg)
-if not preinst:
-preinst = '#!/bin/sh\n'
-preinst += localdata.getVar('updatercd_preinst')
-d.setVar('pkg_preinst_%s' % pkg, preinst)
-
 postinst = d.getVar('pkg_postinst_%s' % pkg)
 if not postinst:
 postinst = '#!/bin/sh\n'
-- 
2.7.4

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


[OE-core] [PATCH 2/2] update-rc.d: update SRCREV and license checksum

2019-06-20 Thread changqing.li
From: Changqing Li 

Signed-off-by: Changqing Li 
---
 meta/recipes-core/update-rc.d/update-rc.d_0.8.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb 
b/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb
index baa21ae..75632d9 100644
--- a/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb
+++ b/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb
@@ -4,10 +4,10 @@ DESCRIPTION = "update-rc.d is a utility that allows the 
management of symlinks t
 SECTION = "base"
 
 LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = 
"file://update-rc.d;beginline=5;endline=15;md5=148a48321b10eb37c1fa3ee02b940a75"
+LIC_FILES_CHKSUM = 
"file://update-rc.d;beginline=5;endline=15;md5=d40a07c27f535425934bb5001f2037d9"
 
 SRC_URI = "git://git.yoctoproject.org/update-rc.d"
-SRCREV = "22e0692898c3e7ceedc8eb5ff4ec8e0b9c340b2d"
+SRCREV = "4b150b25b38de688d25cde2b2d22c268ed65a748"
 
 UPSTREAM_CHECK_COMMITS = "1"
 
-- 
2.7.4

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


[OE-core] [PATCH 0/2] update-rc.d changes

2019-06-20 Thread changqing.li
From: Changqing Li 

1. update-rc.d.bbclass: change to work align with new update-rc.d behavior
2. update-rc.d_0.8.bb: update SRCREV and license checksum

Changqing Li (2):
  update-rc.d: support enable/disable options
  update-rc.d: update SRCREV and license checksum

 meta/classes/update-rc.d.bbclass | 28 
 meta/recipes-core/update-rc.d/update-rc.d_0.8.bb |  4 ++--
 2 files changed, 6 insertions(+), 26 deletions(-)

-- 
2.7.4

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


[OE-core] [PATCH 1/2] context.py: avoid skipping tests by meaningless command argument

2019-06-20 Thread Chen Qi
Currently `oe-selftest -R a' will skip 'archiver' tests. This is
not expected. Fix it so that the '-R' should be followed by actual
module/class/test names.

Signed-off-by: Chen Qi 
---
 meta/lib/oeqa/core/context.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/core/context.py b/meta/lib/oeqa/core/context.py
index 5824489..7882697 100644
--- a/meta/lib/oeqa/core/context.py
+++ b/meta/lib/oeqa/core/context.py
@@ -52,7 +52,7 @@ class OETestContext(object):
 return func
 for test in self.suites:
 for skip in skips:
-if test.id().startswith(skip):
+if (test.id()+'.').startswith(skip+'.'):
 setattr(test, 'setUp', skipfuncgen('Skip by the command 
line argument "%s"' % skip))
 
 def loadTests(self, module_paths, modules=[], tests=[],
-- 
1.9.1

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


[OE-core] [PATCH 0/2] oeqa: two fixes regarding skipping tests

2019-06-20 Thread Chen Qi
*** BLURB HERE ***
The following changes since commit 1d60af733cc28018ce95789191986e3ce6c3b86d:

  python3: python3: Fix build error x86->x86 (2019-06-19 22:13:42 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/oeqa-skip-class
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/oeqa-skip-class

Chen Qi (2):
  context.py: avoid skipping tests by meaningless command argument
  oeqa: avoid class setup method to run when skipping the whole class

 meta/lib/oeqa/core/case.py|  2 ++
 meta/lib/oeqa/core/context.py | 10 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

-- 
1.9.1

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


[OE-core] [PATCH 2/2] oeqa: avoid class setup method to run when skipping the whole class

2019-06-20 Thread Chen Qi
For now, even if we have specified to skip the whole module/class via
command line, e.g., `oe-selftest -R gotoolchain', the class setup method
is still run. This at least results in unnecessary builds, and at worst
results in ERROR, if the setup method fails.

So improve the skipping mechanism to avoid class setup method to run
when specified to skip.

Signed-off-by: Chen Qi 
---
 meta/lib/oeqa/core/case.py| 2 ++
 meta/lib/oeqa/core/context.py | 8 
 2 files changed, 10 insertions(+)

diff --git a/meta/lib/oeqa/core/case.py b/meta/lib/oeqa/core/case.py
index 54977c8..aca144e 100644
--- a/meta/lib/oeqa/core/case.py
+++ b/meta/lib/oeqa/core/case.py
@@ -32,6 +32,8 @@ class OETestCase(unittest.TestCase):
 @classmethod
 def _oeSetUpClass(clss):
 _validate_td_vars(clss.td, clss.td_vars, "class")
+if hasattr(clss, 'setUpHooker') and callable(getattr(clss, 
'setUpHooker')):
+clss.setUpHooker()
 clss.setUpClassMethod()
 
 @classmethod
diff --git a/meta/lib/oeqa/core/context.py b/meta/lib/oeqa/core/context.py
index 7882697..68819cc 100644
--- a/meta/lib/oeqa/core/context.py
+++ b/meta/lib/oeqa/core/context.py
@@ -50,10 +50,18 @@ class OETestContext(object):
 def func():
 raise unittest.SkipTest(skipmsg)
 return func
+class_ids = {}
 for test in self.suites:
+if test.__class__ not in class_ids:
+class_ids[test.__class__] = '.'.join(test.id().split('.')[:-1])
 for skip in skips:
 if (test.id()+'.').startswith(skip+'.'):
 setattr(test, 'setUp', skipfuncgen('Skip by the command 
line argument "%s"' % skip))
+for tclass in class_ids:
+cid = class_ids[tclass]
+for skip in skips:
+if (cid + '.').startswith(skip + '.'):
+setattr(tclass, 'setUpHooker', skipfuncgen('Skip by the 
command line argument "%s"' % skip))
 
 def loadTests(self, module_paths, modules=[], tests=[],
 modules_manifest="", modules_required=[], filters={}):
-- 
1.9.1

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


Re: [OE-core] [PATCH 2/4] scons.bbclass: use python3-scons

2019-06-20 Thread Tim Orling
On Thu, Jun 20, 2019 at 6:37 AM Khem Raj  wrote:

> On Fri, Jun 7, 2019 at 5:50 PM Tim Orling
>  wrote:
> >
> > SCons has supported python3 since 3.0.0 release, use it.
> >
> > [YOCTO #13381]
> >
> > Signed-off-by: Tim Orling 
> > ---
> >  meta/classes/scons.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/scons.bbclass b/meta/classes/scons.bbclass
> > index 9ee7d1587d..a8ddae35f7 100644
> > --- a/meta/classes/scons.bbclass
> > +++ b/meta/classes/scons.bbclass
> > @@ -1,4 +1,4 @@
> > -DEPENDS += "python-scons-native"
> > +DEPENDS += "python3-scons-native"
> >
>
> some packages haven't upgraded to py3 but use scons see
> https://errors.yoctoproject.org/Errors/Details/249271/
>


Thank you for reporting this. I was of course expecting some breakage and
am committed to fixes. Please do report any other issues.

Latest mongo release appears to be 4.3.0 and appears to support python3:

https://github.com/mongodb/mongo/blob/89e7419a897b2270931c9c029abf6de555d83e0f/SConstruct

Is this an aceptable upgrade? I am not savvy on which versions are
desirable.


> >  EXTRA_OESCONS ?= ""
> >
> > --
> > 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] ✗ patchtest: failure for dropbear: new feature: disable-weak-ciphers

2019-06-20 Thread Patchwork
== Series Details ==

Series: dropbear: new feature: disable-weak-ciphers
Revision: 1
URL   : https://patchwork.openembedded.org/series/18278/
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 cannot be parsed correctly due to malformed diff 
lines [test_mbox_format] 
  Suggested fixCreate the series again using git-format-patch and ensure it 
can be applied using git am
  Diff line@@ -46,8 +47,9 @@ SBINCOMMANDS = "dropbear dropbearkey 
dropbearconvert"


* 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 0fdf76305a)



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] dropbear: new feature: disable-weak-ciphers

2019-06-20 Thread Joseph Reynolds

dropbear: new feature: disable-weak-ciphers

Enhances dropbear with a new feature "disable-weak-ciphers", on by 
default.
This feature disables all CBC, SHA1, and diffie-hellman group1 ciphers 
in

the dropbear ssh server and client.

Disable this feature if you need to connect to the ssh server from older
clients.  Additional customization can be done with local_options.h as 
usual.


Tested: On dropbear_2019.78.

Upstream-Status: Inappropriate [configuration]

Signed-off-by: Joseph Reynolds 
---
 meta/recipes-core/dropbear/dropbear.inc|  6 ++--
 .../dropbear/dropbear-disable-weak-ciphers.patch   | 37 
++

 2 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-core/dropbear/dropbear/dropbear-disable-weak-ciphers.patch


diff --git a/meta/recipes-core/dropbear/dropbear.inc 
b/meta/recipes-core/dropbear/dropbear.inc

index b74d186..dcbda74 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -20,7 +20,8 @@ SRC_URI = 
"http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \

file://dropbear@.service \
file://dropbear.socket \
file://dropbear.default \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'${PAM_SRC_URI}', '', d)} "
+   ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'${PAM_SRC_URI}', '', d)} \
+   ${@bb.utils.contains('PACKAGECONFIG', 
'disable-weak-ciphers', 'file://dropbear-disable-weak-ciphers.patch', 
'', d)} "


 PAM_SRC_URI = "file://0005-dropbear-enable-pam.patch \
file://0006-dropbear-configuration-file.patch \
@@ -46,8 +47,9 @@ SBINCOMMANDS = "dropbear dropbearkey dropbearconvert"
 BINCOMMANDS = "dbclient ssh scp"
 EXTRA_OEMAKE = 'MULTI=1 SCPPROGRESS=1 PROGRAMS="${SBINCOMMANDS} 
${BINCOMMANDS}"'


-PACKAGECONFIG ?= ""
+PACKAGECONFIG ?= "disable-weak-ciphers"
 PACKAGECONFIG[system-libtom] = 
"--disable-bundled-libtom,--enable-bundled-libtom,libtommath 
libtomcrypt"

+PACKAGECONFIG[disable-weak-ciphers] = ""

 EXTRA_OECONF += "\
  ${@bb.utils.contains('DISTRO_FEATURES', 'pam', '--enable-pam', 
'--disable-pam', d)}"
diff --git 
a/meta/recipes-core/dropbear/dropbear/dropbear-disable-weak-ciphers.patch 
b/meta/recipes-core/dropbear/dropbear/dropbear-disable-weak-ciphers.patch

new file mode 100644
index 000..764aebd
--- /dev/null
+++ 
b/meta/recipes-core/dropbear/dropbear/dropbear-disable-weak-ciphers.patch

@@ -0,0 +1,37 @@
+diff --git a/default_options.h b/default_options.h
+index 9000fcc..bfb8a8f 100644
+--- a/default_options.h
 b/default_options.h
+@@ -91,7 +91,7 @@ IMPORTANT: Some options will require "make clean" 
after changes */

+
+ /* Enable CBC mode for ciphers. This has security issues though
+  * is the most compatible with older SSH implementations */
+-#define DROPBEAR_ENABLE_CBC_MODE 1
++#define DROPBEAR_ENABLE_CBC_MODE 0
+
+ /* Enable "Counter Mode" for ciphers. This is more secure than
+  * CBC mode against certain attacks. It is recommended for security
+@@ -101,7 +101,7 @@ IMPORTANT: Some options will require "make clean" 
after changes */

+ /* Message integrity. sha2-256 is recommended as a default,
+sha1 for compatibility */
+ #define DROPBEAR_SHA1_HMAC 1
+-#define DROPBEAR_SHA1_96_HMAC 1
++#define DROPBEAR_SHA1_96_HMAC 0
+ #define DROPBEAR_SHA2_256_HMAC 1
+
+ /* Hostkey/public key algorithms - at least one required, these are 
used
+@@ -149,12 +149,12 @@ IMPORTANT: Some options will require "make clean" 
after changes */
+  * Small systems should generally include either curve25519 or ecdh 
for performance.

+  * curve25519 is less widely supported but is faster
+  */
+-#define DROPBEAR_DH_GROUP14_SHA1 1
++#define DROPBEAR_DH_GROUP14_SHA1 0
+ #define DROPBEAR_DH_GROUP14_SHA256 1
+ #define DROPBEAR_DH_GROUP16 0
+ #define DROPBEAR_CURVE25519 1
+ #define DROPBEAR_ECDH 1
+-#define DROPBEAR_DH_GROUP1 1
++#define DROPBEAR_DH_GROUP1 0
+
+ /* When group1 is enabled it will only be allowed by Dropbear client
+ not as a server, due to concerns over its strength. Set to 0 to allow
--
1.8.3.1

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


[OE-core] [oe-core][PATCH 1/1][v3] parted: change device manager check in ptest

2019-06-20 Thread Joe Slater
t6001-psep should check for device manager the same way as
other ptests for parted -- look for an environment variable.

Signed-off-by: Joe Slater 
---
 meta/recipes-extended/parted/files/dm_check.patch | 22 ++
 meta/recipes-extended/parted/parted_3.2.bb|  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 meta/recipes-extended/parted/files/dm_check.patch

diff --git a/meta/recipes-extended/parted/files/dm_check.patch 
b/meta/recipes-extended/parted/files/dm_check.patch
new file mode 100644
index 000..5f3c4dd
--- /dev/null
+++ b/meta/recipes-extended/parted/files/dm_check.patch
@@ -0,0 +1,22 @@
+parted: change check for device-manager
+
+Other ptests use this method.
+
+Upstream-Status: Submitted [bug-par...@gnu.org]
+
+Signed-off-by: Joe Slater 
+
+
+--- a/tests/t6001-psep.sh
 b/tests/t6001-psep.sh
+@@ -19,7 +19,9 @@
+ . "${srcdir=.}/init.sh"; path_prepend_ ../parted
+ 
+ require_root_
+-(dmsetup --help) > /dev/null 2>&1 || skip_test_ "No dmsetup installed"
++
++test "x$ENABLE_DEVICE_MAPPER" = xyes \
++  || skip_ "no device-mapper support"
+ 
+ # Device maps names - should be random to not conflict with existing ones on
+ # the system
diff --git a/meta/recipes-extended/parted/parted_3.2.bb 
b/meta/recipes-extended/parted/parted_3.2.bb
index 13d7d66..21a8153 100644
--- a/meta/recipes-extended/parted/parted_3.2.bb
+++ b/meta/recipes-extended/parted/parted_3.2.bb
@@ -18,6 +18,7 @@ SRC_URI = "${GNU_MIRROR}/parted/parted-${PV}.tar.xz \
file://run-ptest \
file://Makefile \

file://0001-libparted-Use-read-only-when-probing-devices-on-linu.patch \
+   file://dm_check.patch \
 "
 
 SRC_URI[md5sum] = "0247b6a7b314f8edeb618159fa95f9cb"
-- 
2.7.4

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


Re: [OE-core] [oe-commits] [openembedded-core] 09/30: linux-yocto/5.0: update to v5.0.19

2019-06-20 Thread Bruce Ashfield
On Thu, Jun 20, 2019 at 4:17 PM Bruce Ashfield  wrote:
>
> On Thu, Jun 20, 2019 at 3:19 PM Martin Jansa  wrote:
> >
> > Hi,
> >
> >
> > One of these recent updates is causing following WARNING:
>
> It is this one:

or I should have said, I *should* be that change ... But either way,
I'm pulling together a new patch.

Bruce

>
> --
> commit 70a30872bd93cc058b05d9cf2b4f9334658629ee
> Author: Mariano López 
> Date:   Thu Jun 13 22:32:41 2019 -0500
>
> linux-yocto: Add scsi_debug module when ptest is in DISTRO_FEATURES
>
> util-linux ptest requires the scsi_debug module to perform eject/mount
> tests. This will conditionally add scsi_debug module when ptest is in
> DISTRO_FEATURES.
>
> This doesn't include linux-yocto-tiny because the resulting image will
> be too big and do_image would complain about this.
>
> [YOCTO #13301]
>
> Signed-off-by: Mariano López 
> Signed-off-by: Richard Purdie 
> -
>
> Khem pointed it out the other day, and I have a WIP patch that should
> address it shortly.
>
> Bruce
>
> >
> > -- CONFIG_SCSI_DEBUG -
>
-- 
- 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] [oe-commits] [openembedded-core] 09/30: linux-yocto/5.0: update to v5.0.19

2019-06-20 Thread Bruce Ashfield
On Thu, Jun 20, 2019 at 3:19 PM Martin Jansa  wrote:
>
> Hi,
>
>
> One of these recent updates is causing following WARNING:

It is this one:

--
commit 70a30872bd93cc058b05d9cf2b4f9334658629ee
Author: Mariano López 
Date:   Thu Jun 13 22:32:41 2019 -0500

linux-yocto: Add scsi_debug module when ptest is in DISTRO_FEATURES

util-linux ptest requires the scsi_debug module to perform eject/mount
tests. This will conditionally add scsi_debug module when ptest is in
DISTRO_FEATURES.

This doesn't include linux-yocto-tiny because the resulting image will
be too big and do_image would complain about this.

[YOCTO #13301]

Signed-off-by: Mariano López 
Signed-off-by: Richard Purdie 
-

Khem pointed it out the other day, and I have a WIP patch that should
address it shortly.

Bruce

>
> -- CONFIG_SCSI_DEBUG -
> Config: CONFIG_SCSI_DEBUG
> From: 
> work-shared/qemuarm/kernel-source/.kernel-meta/configs/v5.0/standard/features/scsi/scsi-debug.cfg
> Requested value:  CONFIG_SCSI_DEBUG=m
> Actual value:
>
> No reference to SCSI_DEBUG found
>
>
> On Tue, Jun 18, 2019 at 12:31 PM  wrote:
>>
>> This is an automated email from the git hooks/post-receive script.
>>
>> rpurdie pushed a commit to branch warrior
>> in repository openembedded-core.
>>
>> commit 02ee58ba18a0393ce372f4fe9d4860cc9486
>> Author: Bruce Ashfield 
>> AuthorDate: Thu May 30 08:44:42 2019 -0400
>>
>> linux-yocto/5.0: update to v5.0.19
>>
>> Integrating the korg -stable updates that comprise the following
>> commits:
>>
>>3f7c1cab1a61 Linux 5.0.19
>>64d314bd8cc8 fbdev: sm712fb: fix memory frequency by avoiding a 
>> switch/case fallthrough
>>e5c6d75b0f03 bpf, lru: avoid messing with eviction heuristics upon 
>> syscall lookup
>>b5f95aa7a88b bpf: add map_lookup_elem_sys_only for lookups from 
>> syscall side
>>d811930f74ac bpf: relax inode permission check for retrieving bpf 
>> program
>>ca7ef7e3ddfa driver core: Postpone DMA tear-down until after devres 
>> release for probe failure
>>bad4fbe76cfb md/raid: raid5 preserve the writeback action after the 
>> parity check
>>3770eb3721be Revert "Don't jump to compute_result state from 
>> check_result state"
>>07116a6548c8 perf/x86/intel: Fix race in intel_pmu_disable_event()
>>58d1e074c742 perf cs-etm: Always allocate memory for 
>> cs_etm_queue::prev_packet
>>cd448c27b08e perf bench numa: Add define for RUSAGE_THREAD if not 
>> present
>>7325696ce261 i2c: designware: ratelimit 'transfer when suspended' 
>> errors
>>8258661858d5 ufs: fix braino in ufs_get_inode_gid() for solaris UFS 
>> flavour
>>5b73764a5d2c KVM: selftests: make hyperv_cpuid test pass on AMD
>>fb654d0763c8 KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of 
>> unaligned size
>>497ce5c7f538 x86/mm/mem_encrypt: Disable all instrumentation for 
>> early SME setup
>>96f0be982c8a sched/cpufreq: Fix kobject memleak
>>2a9605f177f8 iwlwifi: mvm: check for length correctness in 
>> iwl_mvm_create_skb()
>>df5eba5f41be qmi_wwan: new Wistron, ZTE and D-Link devices
>>bd61ddd3e9fc bpf: Fix preempt_enable_no_resched() abuse
>>bd3713424a01 tools: bpftool: fix infinite loop in map create
>>1e61a219090f power: supply: sysfs: prevent endless uevent loop with 
>> CONFIG_POWER_SUPPLY_DEBUG
>>e6ae43922897 KVM: arm/arm64: Ensure vcpu target is unset on reset 
>> failure
>>5450811a02f5 net: ieee802154: fix missing checks for 
>> regmap_update_bits
>>15f64f420bae mac80211: Fix kernel panic due to use of txq after free
>>eff6d5429bd2 x86: kvm: hyper-v: deal with buggy TLB flush requests 
>> from WS2012
>>48be4d7ced2c PCI: Fix issue with "pci=disable_acs_redir" parameter 
>> being ignored
>>fa42fde1f8e6 apparmorfs: fix use-after-free on symlink traversal
>>cf0259f7662a securityfs: fix use-after-free on symlink traversal
>>04aa8a51e723 power: supply: cpcap-battery: Fix division by zero
>>38a725dd0be7 KVM: PPC: Book3S: Protect memslots while validating user 
>> address
>>eec0c746757b KVM: PPC: Book3S HV: Perserve PSSCR FAKE_SUSPEND bit on 
>> guest exit
>>f3adb80bb243 clk: sunxi-ng: nkmp: Avoid GENMASK(-1, 0)
>>791746a758e7 ARC: PAE40: don't panic and instead turn off hw ioc
>>30bd4585bf14 xfrm4: Fix uninitialized memory read in _decode_session4
>>79fad8fd2b76 xfrm: Honor original L3 slave device in xfrmi policy 
>> lookup
>>ff7fa2c801bc esp4: add length check for UDP encapsulation
>>4e8ce2680442 xfrm: clean up xfrm protocol checks
>>6c0db1cbf772 vti4: ipip tunnel deregistration fixes.
>>f8a427ca50d6 xfrm6_tunnel: Fix potential panic when unloading 
>> xfrm6_tunnel module
>>70a87327025a xfrm: Reset secpath in xfrm failure
>>9531aac1ee3e xfrm: policy: Fix 

Re: [OE-core] [oe-commits] [openembedded-core] 09/30: linux-yocto/5.0: update to v5.0.19

2019-06-20 Thread Martin Jansa
Hi,


One of these recent updates is causing following WARNING:


-- CONFIG_SCSI_DEBUG -
Config: CONFIG_SCSI_DEBUG
From: 
work-shared/qemuarm/kernel-source/.kernel-meta/configs/v5.0/standard/features/scsi/scsi-debug.cfg
Requested value:  CONFIG_SCSI_DEBUG=m
Actual value:

No reference to SCSI_DEBUG found


On Tue, Jun 18, 2019 at 12:31 PM  wrote:

> This is an automated email from the git hooks/post-receive script.
>
> rpurdie pushed a commit to branch warrior
> in repository openembedded-core.
>
> commit 02ee58ba18a0393ce372f4fe9d4860cc9486
> Author: Bruce Ashfield 
> AuthorDate: Thu May 30 08:44:42 2019 -0400
>
> linux-yocto/5.0: update to v5.0.19
>
> Integrating the korg -stable updates that comprise the following
> commits:
>
>3f7c1cab1a61 Linux 5.0.19
>64d314bd8cc8 fbdev: sm712fb: fix memory frequency by avoiding a
> switch/case fallthrough
>e5c6d75b0f03 bpf, lru: avoid messing with eviction heuristics upon
> syscall lookup
>b5f95aa7a88b bpf: add map_lookup_elem_sys_only for lookups from
> syscall side
>d811930f74ac bpf: relax inode permission check for retrieving bpf
> program
>ca7ef7e3ddfa driver core: Postpone DMA tear-down until after devres
> release for probe failure
>bad4fbe76cfb md/raid: raid5 preserve the writeback action after the
> parity check
>3770eb3721be Revert "Don't jump to compute_result state from
> check_result state"
>07116a6548c8 perf/x86/intel: Fix race in intel_pmu_disable_event()
>58d1e074c742 perf cs-etm: Always allocate memory for
> cs_etm_queue::prev_packet
>cd448c27b08e perf bench numa: Add define for RUSAGE_THREAD if not
> present
>7325696ce261 i2c: designware: ratelimit 'transfer when suspended'
> errors
>8258661858d5 ufs: fix braino in ufs_get_inode_gid() for solaris UFS
> flavour
>5b73764a5d2c KVM: selftests: make hyperv_cpuid test pass on AMD
>fb654d0763c8 KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of
> unaligned size
>497ce5c7f538 x86/mm/mem_encrypt: Disable all instrumentation for
> early SME setup
>96f0be982c8a sched/cpufreq: Fix kobject memleak
>2a9605f177f8 iwlwifi: mvm: check for length correctness in
> iwl_mvm_create_skb()
>df5eba5f41be qmi_wwan: new Wistron, ZTE and D-Link devices
>bd61ddd3e9fc bpf: Fix preempt_enable_no_resched() abuse
>bd3713424a01 tools: bpftool: fix infinite loop in map create
>1e61a219090f power: supply: sysfs: prevent endless uevent loop with
> CONFIG_POWER_SUPPLY_DEBUG
>e6ae43922897 KVM: arm/arm64: Ensure vcpu target is unset on reset
> failure
>5450811a02f5 net: ieee802154: fix missing checks for
> regmap_update_bits
>15f64f420bae mac80211: Fix kernel panic due to use of txq after free
>eff6d5429bd2 x86: kvm: hyper-v: deal with buggy TLB flush requests
> from WS2012
>48be4d7ced2c PCI: Fix issue with "pci=disable_acs_redir" parameter
> being ignored
>fa42fde1f8e6 apparmorfs: fix use-after-free on symlink traversal
>cf0259f7662a securityfs: fix use-after-free on symlink traversal
>04aa8a51e723 power: supply: cpcap-battery: Fix division by zero
>38a725dd0be7 KVM: PPC: Book3S: Protect memslots while validating
> user address
>eec0c746757b KVM: PPC: Book3S HV: Perserve PSSCR FAKE_SUSPEND bit
> on guest exit
>f3adb80bb243 clk: sunxi-ng: nkmp: Avoid GENMASK(-1, 0)
>791746a758e7 ARC: PAE40: don't panic and instead turn off hw ioc
>30bd4585bf14 xfrm4: Fix uninitialized memory read in
> _decode_session4
>79fad8fd2b76 xfrm: Honor original L3 slave device in xfrmi policy
> lookup
>ff7fa2c801bc esp4: add length check for UDP encapsulation
>4e8ce2680442 xfrm: clean up xfrm protocol checks
>6c0db1cbf772 vti4: ipip tunnel deregistration fixes.
>f8a427ca50d6 xfrm6_tunnel: Fix potential panic when unloading
> xfrm6_tunnel module
>70a87327025a xfrm: Reset secpath in xfrm failure
>9531aac1ee3e xfrm: policy: Fix out-of-bound array accesses in
> __xfrm_policy_unlink
>07a573c046c0 fuse: Add FOPEN_STREAM to use stream_open()
>560c6fd312c9 dm mpath: always free attached_handler_name in
> parse_path()
>96ecf4c59f08 dm integrity: correctly calculate the size of metadata
> area
>ecff1441aa15 dm crypt: move detailed message into debug level
>862a78341ade dm delay: fix a crash when invalid device is specified
>fab2e96c6be0 dm zoned: Fix zone report handling
>ef3f84246954 dm cache metadata: Fix loading discard bitset
>6c412dc3b757 PCI: Work around Pericom PCIe-to-PCI bridge Retrain
> Link erratum
>d06a30b1a957 PCI: Factor out pcie_retrain_link() function
>4f22ec9f0c28 PCI: rcar: Add the initialization of PCIe link in
> resume_noirq()
>fbd9c6ef0dfc PCI/AER: Change pci_aer_init() stub to return void
>

[OE-core] [PATCH] lttng-tools: update to 2.10.7

2019-06-20 Thread Jonathan Rajotte
Remove upstreamed patches.

Signed-off-by: Jonathan Rajotte 
---
 ...nk-libpause_consumer-on-liblttng-ctl.patch |  35 --
 ...01-Skip-when-testapp-is-not-present.patch} |   0
 ...tng-modules-presence-before-testing.patch} |   0
 ...st_getcpu_override-on-single-thread-.patch |  52 ---
 ...e-tree-origin-can-be-a-symlink-itsel.patch |  80 
 ...be-to-test-for-the-presence-of-lttng.patch | 176 -
 ...sts-check-for-lttng-modules-presence.patch |  28 --
 ...tgrnam-is-not-MT-Safe-use-getgrnam_r.patch | 347 --
 ...-tools_2.10.6.bb => lttng-tools_2.10.7.bb} |  14 +-
 9 files changed, 4 insertions(+), 728 deletions(-)
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-Fix-tests-link-libpause_consumer-on-liblttng-ctl.patch
 rename 
meta/recipes-kernel/lttng/lttng-tools/{0004-Skip-when-testapp-is-not-present.patch
 => 0001-Skip-when-testapp-is-not-present.patch} (100%)
 rename 
meta/recipes-kernel/lttng/lttng-tools/{0008-Fix-check-for-lttng-modules-presence-before-testing.patch
 => 0002-Fix-check-for-lttng-modules-presence-before-testing.patch} (100%)
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0002-Fix-test-skip-test_getcpu_override-on-single-thread-.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0003-Fix-test-unit-the-tree-origin-can-be-a-symlink-itsel.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0005-Tests-use-modprobe-to-test-for-the-presence-of-lttng.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0006-Tests-check-for-lttng-modules-presence.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0007-Fix-getgrnam-is-not-MT-Safe-use-getgrnam_r.patch
 rename meta/recipes-kernel/lttng/{lttng-tools_2.10.6.bb => 
lttng-tools_2.10.7.bb} (89%)

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-Fix-tests-link-libpause_consumer-on-liblttng-ctl.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-Fix-tests-link-libpause_consumer-on-liblttng-ctl.patch
deleted file mode 100644
index df18dc842b..00
--- 
a/meta/recipes-kernel/lttng/lttng-tools/0001-Fix-tests-link-libpause_consumer-on-liblttng-ctl.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From 7244eac44be929fabd6ed1333f96929ef8da564f Mon Sep 17 00:00:00 2001
-From: Jonathan Rajotte 
-Date: Tue, 19 Mar 2019 17:56:49 +
-Subject: [PATCH] fix: tests: link libpause_consumer on liblttng-ctl
-
-This preload test library uses symbols from liblttng-ctl which are
-resolved when preloaded by GLIBC but not by MUSL.
-
-Upstream-Status: Accepted [f667fbd7f8b9512f9943edb2597c226fcc424ee9]
-Backported to 2.11 and 2.10.
-
-Signed-off-by: Michael Jeanson 

- tests/regression/tools/notification/Makefile.am | 5 -
- 1 file changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/tests/regression/tools/notification/Makefile.am 
b/tests/regression/tools/notification/Makefile.am
-index 41adc69..a352bb8 100644
 a/tests/regression/tools/notification/Makefile.am
-+++ b/tests/regression/tools/notification/Makefile.am
-@@ -20,7 +20,10 @@ FORCE_SHARED_LIB_OPTIONS = -module -shared -avoid-version \
-  -rpath $(abs_builddir)
- 
- libpause_consumer_la_SOURCES = consumer_testpoints.c
--libpause_consumer_la_LIBADD = $(top_builddir)/src/common/libcommon.la 
$(DL_LIBS)
-+libpause_consumer_la_LIBADD = \
-+ $(top_builddir)/src/common/libcommon.la \
-+ $(top_builddir)/src/lib/lttng-ctl/liblttng-ctl.la \
-+ $(DL_LIBS)
- libpause_consumer_la_LDFLAGS = $(FORCE_SHARED_LIB_OPTIONS)
- noinst_LTLIBRARIES = libpause_consumer.la
- 
--- 
-2.17.1
-
diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0004-Skip-when-testapp-is-not-present.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-Skip-when-testapp-is-not-present.patch
similarity index 100%
rename from 
meta/recipes-kernel/lttng/lttng-tools/0004-Skip-when-testapp-is-not-present.patch
rename to 
meta/recipes-kernel/lttng/lttng-tools/0001-Skip-when-testapp-is-not-present.patch
diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0008-Fix-check-for-lttng-modules-presence-before-testing.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0002-Fix-check-for-lttng-modules-presence-before-testing.patch
similarity index 100%
rename from 
meta/recipes-kernel/lttng/lttng-tools/0008-Fix-check-for-lttng-modules-presence-before-testing.patch
rename to 
meta/recipes-kernel/lttng/lttng-tools/0002-Fix-check-for-lttng-modules-presence-before-testing.patch
diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0002-Fix-test-skip-test_getcpu_override-on-single-thread-.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0002-Fix-test-skip-test_getcpu_override-on-single-thread-.patch
deleted file mode 100644
index 5bb88d21e5..00
--- 
a/meta/recipes-kernel/lttng/lttng-tools/0002-Fix-test-skip-test_getcpu_override-on-single-thread-.patch
+++ /dev/null
@@ -1,52 +0,0 @@
-From e7db27668a9d7fd279d45bc43f3a2d5847374e7b Mon Sep 17 00:00:00 2001
-From: Jonathan Rajotte 
-Date: Tue, 12 Mar 2019 12:04:58 -0400
-Subject: [PATCH 

[OE-core] [v2][oe-core][PATCH 1/1] glib-2.0: Fix CVE-2019-12450

2019-06-20 Thread Joe Slater
Unchanged patch from glib.git which was added after current release.

Signed-off-by: Joe Slater 
---
 .../glib-2.0/glib-2.0/CVE-2019-12450.patch | 62 ++
 meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb  |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch
new file mode 100644
index 000..59e4919
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch
@@ -0,0 +1,62 @@
+glib-2.0: fix CVE-2019-12450
+
+Not in release 2.61.1.
+
+CVE: CVE-2019-12450
+
+Upstream-Status: Backport [github.com/GNOME/glib.git]
+Signed-off-by: Joe Slater 
+---
+From d8f8f4d637ce43f8699ba94c9b7648beda0ca174 Mon Sep 17 00:00:00 2001
+From: Ondrej Holy 
+Date: Thu, 23 May 2019 10:41:53 +0200
+Subject: [PATCH] gfile: Limit access to files when copying
+
+file_copy_fallback creates new files with default permissions and
+set the correct permissions after the operation is finished. This
+might cause that the files can be accessible by more users during
+the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
+files to limit access to those files.
+---
+ gio/gfile.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/gio/gfile.c b/gio/gfile.c
+index 24b136d80..74b58047c 100644
+--- a/gio/gfile.c
 b/gio/gfile.c
+@@ -3284,12 +3284,12 @@ file_copy_fallback (GFile  *source,
+ out = (GOutputStream*)_g_local_file_output_stream_replace 
(_g_local_file_get_filename (G_LOCAL_FILE (destination)),
+FALSE, 
NULL,
+flags & 
G_FILE_COPY_BACKUP,
+-   
G_FILE_CREATE_REPLACE_DESTINATION,
+-   info,
++   
G_FILE_CREATE_REPLACE_DESTINATION |
++   
G_FILE_CREATE_PRIVATE, info,
+
cancellable, error);
+   else
+ out = (GOutputStream*)_g_local_file_output_stream_create 
(_g_local_file_get_filename (G_LOCAL_FILE (destination)),
+-  FALSE, 0, 
info,
++  FALSE, 
G_FILE_CREATE_PRIVATE, info,
+   
cancellable, error);
+ }
+   else if (flags & G_FILE_COPY_OVERWRITE)
+@@ -3297,12 +3297,13 @@ file_copy_fallback (GFile  *source,
+   out = (GOutputStream *)g_file_replace (destination,
+  NULL,
+  flags & G_FILE_COPY_BACKUP,
+- 
G_FILE_CREATE_REPLACE_DESTINATION,
++ 
G_FILE_CREATE_REPLACE_DESTINATION |
++ G_FILE_CREATE_PRIVATE,
+  cancellable, error);
+ }
+   else
+ {
+-  out = (GOutputStream *)g_file_create (destination, 0, cancellable, 
error);
++  out = (GOutputStream *)g_file_create (destination, 
G_FILE_CREATE_PRIVATE, cancellable, error);
+ }
+ 
+   if (!out)
+-- 
+2.17.1
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb
index bb77294..5942241 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb
@@ -16,6 +16,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz 
\
file://0001-Do-not-write-bindir-into-pkg-config-files.patch \

file://0001-meson.build-do-not-hardcode-linux-as-the-host-system.patch \

file://0001-meson-do-a-build-time-check-for-strlcpy-before-attem.patch \
+   file://CVE-2019-12450.patch \
"
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
-- 
2.7.4

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


Re: [OE-core] [RFC][PATCH] systemd: Remove clearly incorrect musl patches

2019-06-20 Thread Martin Jansa
On Thu, Jun 20, 2019 at 11:09:39AM -0600, Khem Raj wrote:
> On Thu, Jun 20, 2019 at 1:15 AM Adrian Bunk  wrote:
> >
> > On Wed, Jun 19, 2019 at 12:59:05PM -0700, Khem Raj wrote:
> > > On Fri, Jun 14, 2019 at 4:44 AM Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > >
> > > > On Fri, 2019-06-14 at 10:29 +0300, Adrian Bunk wrote:
> > > > > This removes clearly incorrect musl patches and marks
> > > > > systemd as incompatible with musl until these issues
> > > > > are fixed.
> > > > >
> > > > > The previous status quo where systemd was made compiling
> > > > > with patches that are known to introduce bugs and security
> > > > > vulnerabilities silently delivered a sub-standard package
> > > > > to users, this change makes it clear where work is needed
> > > > > to be done by people interested in systemd on musl.
> > > > >
> > > > > Patches that are merely questionable or not upstreamable
> > > > > are not touched.
> > > >
> > > > I'll be interested to see what others think of this, I can't imagine
> > > > this move being very popular...
> > >
> > > There are real products using this combination
> >
> > An OE-only combination neither upstream supports.
> >
> > > And this is not a good message, eventually we want to either fix or stop
> > > supporting this but I think now is not the time
> >
> > When is the time?
> >
> > In a month?
> > Before the Yocto 2.8 branching?
> > After the Yocto 2.8 branching?
> >
> 
> When users that I know stop using it, and that might be a release or
> two. Meanwhile
> I think it will be good to address the issues with patches, if they
> introduce bugs or secvulns
> that I think will help the user community instead of removing the support.
> 
> meanwhile, I would think that we can still work slowly towards making
> things better
> musl has provided a lot of good cleanup patches for systemd so this is
> not a wasted
> effort even if upstream systemd does not officially support anything
> besides glibc.

I don't use systemd/musl combination myself, but I agree with Khem.

As long as these bad musl related patches are applied to systemd only
when musl is used, then it's no harm to people not using systemd/musl
combo.

We can even PNBLACKLIST systemd when musl is being used with warning
that these patches are wrong and create security issues (more details
would be useful for the user to make educated decisions).

If we just remove them, then people who use this combo (for whatever
reason) will just import them to their layers and either fix them
locally (and never share it back) or use this bad version forever.

Keeping them with blacklist in oe-core will prevent people accidentally
assuming that systemd/musl is well supported combination while allowing
interested people to collaborate on fixing the patches in oe-core.

Regards,

> > The best solution would be if someone would step up to properly maintain
> > the systemd/musl combination, but usually such "either fix or stop" only
> > work with a clear deadline.
> >
> 
> 
> 
> > 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

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [RFC][PATCH] systemd: Remove clearly incorrect musl patches

2019-06-20 Thread Khem Raj
On Thu, Jun 20, 2019 at 1:15 AM Adrian Bunk  wrote:
>
> On Wed, Jun 19, 2019 at 12:59:05PM -0700, Khem Raj wrote:
> > On Fri, Jun 14, 2019 at 4:44 AM Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> >
> > > On Fri, 2019-06-14 at 10:29 +0300, Adrian Bunk wrote:
> > > > This removes clearly incorrect musl patches and marks
> > > > systemd as incompatible with musl until these issues
> > > > are fixed.
> > > >
> > > > The previous status quo where systemd was made compiling
> > > > with patches that are known to introduce bugs and security
> > > > vulnerabilities silently delivered a sub-standard package
> > > > to users, this change makes it clear where work is needed
> > > > to be done by people interested in systemd on musl.
> > > >
> > > > Patches that are merely questionable or not upstreamable
> > > > are not touched.
> > >
> > > I'll be interested to see what others think of this, I can't imagine
> > > this move being very popular...
> >
> > There are real products using this combination
>
> An OE-only combination neither upstream supports.
>
> > And this is not a good message, eventually we want to either fix or stop
> > supporting this but I think now is not the time
>
> When is the time?
>
> In a month?
> Before the Yocto 2.8 branching?
> After the Yocto 2.8 branching?
>

When users that I know stop using it, and that might be a release or
two. Meanwhile
I think it will be good to address the issues with patches, if they
introduce bugs or secvulns
that I think will help the user community instead of removing the support.

meanwhile, I would think that we can still work slowly towards making
things better
musl has provided a lot of good cleanup patches for systemd so this is
not a wasted
effort even if upstream systemd does not officially support anything
besides glibc.

> The best solution would be if someone would step up to properly maintain
> the systemd/musl combination, but usually such "either fix or stop" only
> work with a clear deadline.
>



> 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 1/2] python3: Reformat sysconfig

2019-06-20 Thread Richard Purdie
On Thu, 2019-06-20 at 10:43 -0500, Joshua Watt wrote:
> Reformats the sysconfig file when packaging. This file is output by
> using the python pprint function. This function will wrap long lines
> at
> 80 characters by default, and will even split strings at whitespace
> boundaries to do so, e.g.:
> 
>  'A': 'B is really'
> ' long'
> 
> This causes a problem for reproducibility however because there might
> be
> lines of differing lengths depending on the build path. These
> non-reproducible paths are removed, but their effect on string
> wrapping
> from pprint remains.
> 
> To correct this, reformat the entire sysconfig file by re-printing
> using
> pprint with an (effectively) unlimited line length.
> 
> Signed-off-by: Joshua Watt 

Fails on nativesdk:

https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/969

Have aborted that build.

Cheers,

Richard

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


Re: [OE-core] [PATCH] bash: Remove .build files for reproducible builds

2019-06-20 Thread Joshua Watt
On Thu, Jun 20, 2019, 11:20 AM Burton, Ross  wrote:

> Is it easier to just always delete those files?  Do they serve any
> useful purpose?
>

Probably not for our uses. I'll post a V2 unless someone complains


> Ross
>
> On Thu, 20 Jun 2019 at 16:47, Joshua Watt  wrote:
> >
> > Bash has an internal "build number" that it tracks and automatically
> > increments ever time a given builds is made from the same sandbox.
> > However, this can make builds non-reproducible in the event that a build
> > directory is reused multiple times.
> >
> > Remove the .build files after every build if reproducible builds have
> > been requested which will reset the build build number for the next
> > build.
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >  meta/recipes-extended/bash/bash.inc | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/meta/recipes-extended/bash/bash.inc
> b/meta/recipes-extended/bash/bash.inc
> > index c91cc8ada8d..e2844dffbad 100644
> > --- a/meta/recipes-extended/bash/bash.inc
> > +++ b/meta/recipes-extended/bash/bash.inc
> > @@ -39,6 +39,14 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = " \
> >
> >  CACHED_CONFIGUREVARS += "headersdir=${includedir}/${PN}"
> >
> > +do_compile_prepend() {
> > +# If reproducible builds are requested, remove any leftover .build
> files.
> > +# This ensures that bash always has the same version number
> > +if [ "${BUILD_REPRODUCIBLE_BINARIES}" == "1" ]; then
> > +rm -f ${B}/.build
> > +fi
> > +}
> > +
> >  do_compile_ptest () {
> > oe_runmake buildtest
> >  }
> > --
> > 2.21.0
> >
> > --
> > ___
> > 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] bash: Remove .build files for reproducible builds

2019-06-20 Thread Burton, Ross
Is it easier to just always delete those files?  Do they serve any
useful purpose?

Ross

On Thu, 20 Jun 2019 at 16:47, Joshua Watt  wrote:
>
> Bash has an internal "build number" that it tracks and automatically
> increments ever time a given builds is made from the same sandbox.
> However, this can make builds non-reproducible in the event that a build
> directory is reused multiple times.
>
> Remove the .build files after every build if reproducible builds have
> been requested which will reset the build build number for the next
> build.
>
> Signed-off-by: Joshua Watt 
> ---
>  meta/recipes-extended/bash/bash.inc | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/meta/recipes-extended/bash/bash.inc 
> b/meta/recipes-extended/bash/bash.inc
> index c91cc8ada8d..e2844dffbad 100644
> --- a/meta/recipes-extended/bash/bash.inc
> +++ b/meta/recipes-extended/bash/bash.inc
> @@ -39,6 +39,14 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = " \
>
>  CACHED_CONFIGUREVARS += "headersdir=${includedir}/${PN}"
>
> +do_compile_prepend() {
> +# If reproducible builds are requested, remove any leftover .build files.
> +# This ensures that bash always has the same version number
> +if [ "${BUILD_REPRODUCIBLE_BINARIES}" == "1" ]; then
> +rm -f ${B}/.build
> +fi
> +}
> +
>  do_compile_ptest () {
> oe_runmake buildtest
>  }
> --
> 2.21.0
>
> --
> ___
> 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


[OE-core] ✗ patchtest: failure for python3: Reproducible build fixes

2019-06-20 Thread Patchwork
== Series Details ==

Series: python3: Reproducible build fixes
Revision: 1
URL   : https://patchwork.openembedded.org/series/18272/
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/recipes-devtools/python/python3/reformat_sysconfig.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] perl: Improve ptest package reproducibility

2019-06-20 Thread Joshua Watt
Fixes a few reproducibility issues in the perl ptest package:
 1) config.log has a lot of paths encoded in it. This file is
unnecessary for ptest, so it is omitted from the package
 2) Makefile.config has a lot of paths encoded in it. This file should
be fixed up using the same rules as several other files that are in
the package
 3) Paths in DEBUG_PREFIX_MAP are not being correctly removed from files
because DEBUG_PREFIX_MAP is now several command line arguments.
Instead of requiring an exact match for all arguments, remove any
matching argument.

Signed-off-by: Joshua Watt 
---
 meta/recipes-devtools/perl/perl-ptest.inc | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl-ptest.inc 
b/meta/recipes-devtools/perl/perl-ptest.inc
index 9dd9b7da57f..7152057762f 100644
--- a/meta/recipes-devtools/perl/perl-ptest.inc
+++ b/meta/recipes-devtools/perl/perl-ptest.inc
@@ -2,6 +2,9 @@ inherit ptest
 
 SRC_URI += "file://run-ptest \
"
+
+DEBUG_PREFIX_MAP_REGEX = "${@'\\|'.join(d.getVar('DEBUG_PREFIX_MAP').split())}"
+
 do_install_ptest () {
mkdir -p ${D}${PTEST_PATH}
sed -e "s:\/usr\/local:${bindir}:g" -i cpan/version/t/*
@@ -13,7 +16,7 @@ do_install_ptest () {
--exclude='win32/config.*' --exclude=plan9 --exclude=README.plan9 
--exclude=perlplan9.pod --exclude=Configure \
--exclude=veryclean.sh --exclude=realclean.sh  
--exclude=getioctlsizes \
--exclude=dl_aix.xs --exclude=sdbm.3 --exclude='cflags.SH' 
--exclude=makefile.old \
-   --exclude=miniperl --exclude=generate_uudmap --exclude=patches 
* | ( cd ${D}${PTEST_PATH} && tar -x )
+   --exclude=miniperl --exclude=generate_uudmap --exclude=patches 
--exclude='config.log' * | ( cd ${D}${PTEST_PATH} && tar -x )
 
ln -sf ${bindir}/perl ${D}${PTEST_PATH}/t/perl
 
@@ -21,12 +24,12 @@ do_install_ptest () {
find "${D}${PTEST_PATH}" \
 \( -name '*.PL' -o -name 'myconfig' -o -name 'cflags' -o -name 
'*.pl' -o -name '*.sh' -o -name '*.pm' \
 -o -name 'h2xs' -o -name 'h2ph' \
--o -name '*.h' -o -name 'config.sh-*' -o -name 'pod2man'  -o -name 
'pod2text' \) \
+-o -name '*.h' -o -name 'config.sh-*' -o -name 'pod2man'  -o -name 
'pod2text' -o -name 'Makefile.config' \) \
-type f -exec sed -i \
   -e "s,${D},,g" \
   -e "s,--sysroot=${STAGING_DIR_HOST},,g" \
   -e "s,-isystem${STAGING_INCDIR} ,,g" \
-  -e 's|${DEBUG_PREFIX_MAP}||g' \
+  -e 's^${DEBUG_PREFIX_MAP_REGEX}^^g' \
   -e "s,${STAGING_BINDIR_NATIVE}/perl-native/,${bindir}/,g" \
   -e "s,${STAGING_LIBDIR},${libdir},g" \
   -e "s,${STAGING_BINDIR},${bindir},g" \
-- 
2.21.0

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


[OE-core] [PATCH] bash: Remove .build files for reproducible builds

2019-06-20 Thread Joshua Watt
Bash has an internal "build number" that it tracks and automatically
increments ever time a given builds is made from the same sandbox.
However, this can make builds non-reproducible in the event that a build
directory is reused multiple times.

Remove the .build files after every build if reproducible builds have
been requested which will reset the build build number for the next
build.

Signed-off-by: Joshua Watt 
---
 meta/recipes-extended/bash/bash.inc | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-extended/bash/bash.inc 
b/meta/recipes-extended/bash/bash.inc
index c91cc8ada8d..e2844dffbad 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -39,6 +39,14 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = " \
 
 CACHED_CONFIGUREVARS += "headersdir=${includedir}/${PN}"
 
+do_compile_prepend() {
+# If reproducible builds are requested, remove any leftover .build files.
+# This ensures that bash always has the same version number
+if [ "${BUILD_REPRODUCIBLE_BINARIES}" == "1" ]; then
+rm -f ${B}/.build
+fi
+}
+
 do_compile_ptest () {
oe_runmake buildtest
 }
-- 
2.21.0

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


[OE-core] [PATCH 0/2] python3: Reproducible build fixes

2019-06-20 Thread Joshua Watt
Two fixes to make the Python3 build reproducible

Joshua Watt (2):
  python3: Reformat sysconfig
  python3: Disable PGO for reproducible builds

 .../python/python3/reformat_sysconfig.py  | 21 +++
 meta/recipes-devtools/python/python3_3.7.3.bb | 20 +-
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/python/python3/reformat_sysconfig.py

-- 
2.21.0

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


[OE-core] [PATCH 2/2] python3: Disable PGO for reproducible builds

2019-06-20 Thread Joshua Watt
Enabling PGO for python current causes it to not be reproducible when
building, so disable it for now.

Signed-off-by: Joshua Watt 
---
 meta/recipes-devtools/python/python3_3.7.3.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb 
b/meta/recipes-devtools/python/python3_3.7.3.bb
index d14c93880fb..40e2229a165 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -79,8 +79,16 @@ CACHED_CONFIGUREVARS = " \
 ac_cv_file__dev_ptc=no \
 ac_cv_working_tzset=yes \
 "
+python() {
+# PGO currently causes builds to not be reproducible, so disable it for
+# now. See YOCTO #13407
+if bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', True, False, d) 
and d.getVar('BUILD_REPRODUCIBLE_BINARIES') != '1':
+d.setVar('PACKAGECONFIG_PGO', 'pgo')
+else:
+d.setVar('PACKAGECONFIG_PGO', '')
+}
 
-PACKAGECONFIG_class-target ??= "readline 
${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 'pgo', '', d)}"
+PACKAGECONFIG_class-target ??= "readline ${PACKAGECONFIG_PGO}"
 PACKAGECONFIG_class-native ??= "readline"
 PACKAGECONFIG_class-nativesdk ??= "readline"
 PACKAGECONFIG[readline] = ",,readline"
-- 
2.21.0

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


[OE-core] [PATCH 1/2] python3: Reformat sysconfig

2019-06-20 Thread Joshua Watt
Reformats the sysconfig file when packaging. This file is output by
using the python pprint function. This function will wrap long lines at
80 characters by default, and will even split strings at whitespace
boundaries to do so, e.g.:

 'A': 'B is really'
' long'

This causes a problem for reproducibility however because there might be
lines of differing lengths depending on the build path. These
non-reproducible paths are removed, but their effect on string wrapping
from pprint remains.

To correct this, reformat the entire sysconfig file by re-printing using
pprint with an (effectively) unlimited line length.

Signed-off-by: Joshua Watt 
---
 .../python/python3/reformat_sysconfig.py  | 21 +++
 meta/recipes-devtools/python/python3_3.7.3.bb | 10 +
 2 files changed, 31 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3/reformat_sysconfig.py

diff --git a/meta/recipes-devtools/python/python3/reformat_sysconfig.py 
b/meta/recipes-devtools/python/python3/reformat_sysconfig.py
new file mode 100644
index 000..c4164313e8b
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/reformat_sysconfig.py
@@ -0,0 +1,21 @@
+#! /usr/bin/env python3
+#
+# SPDX-License-Identifier: MIT
+#
+# Copyright 2019 by Garmin Ltd. or its subsidiaries
+#
+# A script to reformat python sysconfig
+
+import sys
+import pprint
+l = {}
+g = {}
+with open(sys.argv[1], 'r') as f:
+exec(f.read(), g, l)
+
+with open(sys.argv[1], 'w') as f:
+for k in sorted(l.keys()):
+f.write('%s = ' % k)
+pprint.pprint(l[k], stream=f, width=sys.maxsize)
+f.write('\n')
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb 
b/meta/recipes-devtools/python/python3_3.7.3.bb
index 24442961421..d14c93880fb 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -27,6 +27,10 @@ SRC_URI = 
"http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
   file://crosspythonpath.patch \
"
 
+SRC_URI_append_class-target = " \
+   file://reformat_sysconfig.py \
+   "
+
 SRC_URI_append_class-native = " \

file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
@@ -157,6 +161,12 @@ py_package_preprocess () {
 ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata*.py \
 ${PKGD}/${bindir}/python${PYTHON_BINABI}-config
 
+# Reformat _sysconfigdata after modifying it so that it remains
+# reproducible
+for c in ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata*.py; 
do
+python3 ${WORKDIR}/reformat_sysconfig.py $c
+done
+
 # Recompile _sysconfigdata after modifying it
 cd ${PKGD}
 sysconfigfile=`find . -name _sysconfigdata_*.py`
-- 
2.21.0

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


Re: [OE-core] [PATCH 3/4] update-alternatives.bbclass: run update-alternatives firstly in postinst script

2019-06-20 Thread Richard Purdie
On Thu, 2019-06-20 at 16:15 +0800, Robert Yang wrote:
> Recipes like postfix run command newaliases in postinst, but
> newaliases is
> installed newaliases.postfix, and need run update-alternatives to
> update it to
> newaliases, so we would get the error when install postinst on
> target.
> 
> Fixed:
> $ opkg install postfix
> Configuring postfix.
> ///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command
> not found
> 
> Run update-alternatives firstly will fix the problem.
> 
> Signed-off-by: Robert Yang 
> ---
>  meta/classes/update-alternatives.bbclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

This seemed to result in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/724

Cheers,

Richard

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


[OE-core] [PATCH] python: make 'python' install everything instead of just the interpretter

2019-06-20 Thread Ross Burton
Follow the python3 behaviour, and common sense, by making 'python' install
python-modules instead of python-core.  This means a user installing python gets
all of Python, instead of just a fraction of the library.

[ YOCTO #13402 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/python/python_2.7.16.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python_2.7.16.bb 
b/meta/recipes-devtools/python/python_2.7.16.bb
index d70342fe3a6..5f387b8af11 100644
--- a/meta/recipes-devtools/python/python_2.7.16.bb
+++ b/meta/recipes-devtools/python/python_2.7.16.bb
@@ -162,7 +162,7 @@ py_package_preprocess () {
 PACKAGES_remove = "${PN}"
 
 # manual dependency additions
-RPROVIDES_${PN}-core = "${PN}"
+RPROVIDES_${PN}-modules = "${PN}"
 RRECOMMENDS_${PN}-core_append_class-nativesdk = " nativesdk-python-modules"
 RRECOMMENDS_${PN}-crypt = "openssl"
 
-- 
2.11.0

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


[OE-core] [PATCH] qemu: disable capstone for 32-bit mips with multilib

2019-06-20 Thread kai.kang
From: Kai Kang 

When build lib32-qemu for qemumips with multilib:

  require conf/multilib.conf
  MACHINE = "qemumips64"
  MULTILIBS = "multilib:lib32"
  DEFAULTTUNE_virtclass-multilib-lib32 = "mips"

it fails to compile capstone:

|  CC  arch/AArch64/AArch64InstPrinter.o
|  {standard input}: Assembler messages:
|  {standard input}:36033: Error: branch out of range
|  {standard input}:36257: Error: branch out of range

Disable capstone for mips o32 in this situation as a workround.

Signed-off-by: Kai Kang 
---
 meta/recipes-devtools/qemu/qemu_4.0.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/qemu/qemu_4.0.0.bb 
b/meta/recipes-devtools/qemu/qemu_4.0.0.bb
index f119215b21..76776098d0 100644
--- a/meta/recipes-devtools/qemu/qemu_4.0.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_4.0.0.bb
@@ -7,6 +7,7 @@ DEPENDS = "glib-2.0 zlib pixman bison-native"
 RDEPENDS_${PN}_class-target += "bash"
 
 EXTRA_OECONF_append_class-target = " --target-list=${@get_qemu_target_list(d)}"
+EXTRA_OECONF_append_class-target_mipsarcho32 = 
"${@bb.utils.contains('BBEXTENDCURR', 'multilib', ' --disable-capstone', '', 
d)}"
 EXTRA_OECONF_append_class-nativesdk = " 
--target-list=${@get_qemu_target_list(d)}"
 
 do_install_append_class-nativesdk() {
-- 
2.20.0

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


[OE-core] ✗ patchtest: failure for cmake.bbclass: pass mandatory compiler flags through CMAKE__COMPILER_ARG1 (rev2)

2019-06-20 Thread Patchwork
== Series Details ==

Series: cmake.bbclass: pass mandatory compiler flags through 
CMAKE__COMPILER_ARG1 (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/17610/
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:



* Patch[v2] cmake.bbclass: pass mandatory compiler flags through 
CMAKE__COMPILER_ARG1
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



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] [PATCHv2] cmake.bbclass: pass mandatory compiler flags through CMAKE__COMPILER_ARG1

2019-06-20 Thread Nikolai Merinov via Openembedded-core
Hi,

Updated patch for the current "master" branch is attached.

> have you also tried building SDK and see if these changes are reflected in 
> SDK as well ?

I checked that the changes reflected in the Extensible SDK for the 
"core-image-sato" image of the poky.

Regards,
Nikolai

- Original Message -
From: "Khem Raj" 
To: "n merinov" , "openembedded-core" 

Sent: Tuesday, May 21, 2019 1:41:46 AM
Subject: Re: [OE-core] [PATCH] cmake.bbclass: pass mandatory compiler flags 
through CMAKE__COMPILER_ARG1

On 5/14/19 8:04 AM, Nikolai Merinov wrote:
> The CMake takes mandatory compiler arguments from the following variables:
> - CMAKE_SYSROOT -- path to sysroot that should be passed to compiler.
> - CMAKE__COMPILER_TARGET -- target architecture, used for compilers
>that supports several targets through command line options.
>e.g. "clang --target ${CMAKE_C_COMPILER_TARGET}".
> - CMAKE__COMPILER_EXTERNAL_TOOLCHAIN -- path to external toolchain,
>used for compilers that support build with external toolchain.
>e.g. "clang --gcc-toolchain ${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}".
> - CMAKE__COMPILER_ARG1 -- other mandatory arguments to a compiler
>command.
> 
> CMAKE__COMPILER_ARG1 is the most suitable variable to pass mandatory
> arguments, that belongs to CC variable with other build systems, to a
> compiler.
> 
> Additionally usage of CMAKE__COMPILER_ARG1 instead of
> CMAKE__FLAGS reduce the risk that a variable can be overrided by
> CMakeLists.txt files.
> ---
>   meta/classes/cmake.bbclass | 21 +++--
>   1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index d3f0d70847..4da4c00a09 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -27,27 +27,33 @@ python() {
>   cc_list = d.getVar('CC').split()
>   if cc_list[0] == 'ccache':
>   d.setVar('OECMAKE_C_COMPILER', '%s %s' % (cc_list[0], 
> cc_list[1]))
> +cc_arg1 = ' '.join(cc_list[2:])
>   else:
>   d.setVar('OECMAKE_C_COMPILER', cc_list[0])
> +cc_arg1 = ' '.join(cc_list[1:])
> +if not d.getVar('OECMAKE_C_COMPILER_ARG1'):
> +d.setVar('OECMAKE_C_COMPILER_ARG1', cc_arg1)
>   
>   if not d.getVar('OECMAKE_CXX_COMPILER'):
>   cxx_list = d.getVar('CXX').split()
>   if cxx_list[0] == 'ccache':
>   d.setVar('OECMAKE_CXX_COMPILER', '%s %s' % (cxx_list[0], 
> cxx_list[1]))
> +cxx_arg1 = ' '.join(cxx_list[2:])
>   else:
>   d.setVar('OECMAKE_CXX_COMPILER', cxx_list[0])
> +cxx_arg1 = ' '.join(cxx_list[1:])
> +if not d.getVar('OECMAKE_CXX_COMPILER_ARG1'):
> +d.setVar('OECMAKE_CXX_COMPILER_ARG1', cxx_arg1)
>   }
>   OECMAKE_AR ?= "${AR}"
>   
>   # Compiler flags
> -OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}"
> -OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS}"
> +OECMAKE_C_FLAGS ?= "${CFLAGS}"
> +OECMAKE_CXX_FLAGS ?= "${CXXFLAGS}"
>   OECMAKE_C_FLAGS_RELEASE ?= "-DNDEBUG"
>   OECMAKE_CXX_FLAGS_RELEASE ?= "-DNDEBUG"
> -OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS} 
> ${LDFLAGS}"
> -OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} 
> ${LDFLAGS}"
> -CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> -CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> +OECMAKE_C_LINK_FLAGS ?= "${CPPFLAGS} ${LDFLAGS}"
> +OECMAKE_CXX_LINK_FLAGS ?= "${CXXFLAGS} ${LDFLAGS}"
>   
>   OECMAKE_RPATH ?= ""
>   OECMAKE_PERLNATIVE_DIR ??= ""
> @@ -85,8 +91,11 @@ $cmake_crosscompiling
>   set( CMAKE_SYSTEM_NAME `echo ${TARGET_OS} | sed -e 's/^./\u&/' -e 
> 's/^\(Linux\).*/\1/'` )
>   set( CMAKE_SYSTEM_PROCESSOR 
> ${@map_target_arch_to_uname_arch(d.getVar('TARGET_ARCH'))} )
>   set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
> +set( CMAKE_C_COMPILER_ARG1 "${OECMAKE_C_COMPILER_ARG1}" )
>   set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
> +set( CMAKE_CXX_COMPILER_ARG1 "${OECMAKE_CXX_COMPILER_ARG1}" )
>   set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
> +set( CMAKE_ASM_COMPILER_ARG1 "${OECMAKE_C_COMPILER_ARG1}" )
>   set( CMAKE_AR ${OECMAKE_AR} CACHE FILEPATH "Archiver" )
>   set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
>   set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
> 

these changes look ok, have you also tried building SDK and see if these 
changes are reflected in SDK as well ?From 07dcf522cb4cadf211e76cd66f1897f6e22ca6e1 Mon Sep 17 00:00:00 2001
From: Nikolai Merinov 
Date: Thu, 20 Jun 2019 14:15:14 +0500
Subject: [PATCH] cmake.bbclass: pass mandatory compiler flags through
 CMAKE__COMPILER_ARG1

The CMake takes mandatory compiler arguments from the following variables:
- CMAKE_SYSROOT -- path to sysroot that should be passed to compiler.
- CMAKE__COMPILER_TARGET -- target architecture, used for compilers
  that supports 

Re: [OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Burton, Ross
Why DEPENDS on gtk?  The recipes will typically already do this, but
all this class needs is the rdepends.  Also, there's no explanation
for the hicolor addition.

Ross

On Thu, 20 Jun 2019 at 14:54, Richard Purdie
 wrote:
>
> On Thu, 2019-06-20 at 17:58 +0800, Robert Yang wrote:
> >
> > On 6/20/19 5:19 PM, Adrian Bunk wrote:
> > > On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
> > > > ...
> > > > Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think
> > > > that we
> > > > need something like virtual/gtk to fix these problems totally?
> > >
> > > GTK+2 is mostly obsolete.
> > >
> > > I just checked the GTK4 sources, and there it is renamed to
> > > gtk4-update-icon-cache. Based on that I would say that your
> > > patch is actually fine at least for now.
> >
> > Thanks, I updated the commit message in the PULL:
>
> Please resend patches rather than updating the branch as they get lost
> really easily and also don't get reviewed properly this way.
>
> Cheers,
>
> Richard
>
> --
> ___
> 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 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Richard Purdie
On Thu, 2019-06-20 at 17:58 +0800, Robert Yang wrote:
> 
> On 6/20/19 5:19 PM, Adrian Bunk wrote:
> > On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
> > > ...
> > > Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think
> > > that we
> > > need something like virtual/gtk to fix these problems totally?
> > 
> > GTK+2 is mostly obsolete.
> > 
> > I just checked the GTK4 sources, and there it is renamed to
> > gtk4-update-icon-cache. Based on that I would say that your
> > patch is actually fine at least for now.
> 
> Thanks, I updated the commit message in the PULL:

Please resend patches rather than updating the branch as they get lost
really easily and also don't get reviewed properly this way.

Cheers,

Richard

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


Re: [OE-core] [PATCH 2/4] scons.bbclass: use python3-scons

2019-06-20 Thread Khem Raj
On Fri, Jun 7, 2019 at 5:50 PM Tim Orling
 wrote:
>
> SCons has supported python3 since 3.0.0 release, use it.
>
> [YOCTO #13381]
>
> Signed-off-by: Tim Orling 
> ---
>  meta/classes/scons.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/scons.bbclass b/meta/classes/scons.bbclass
> index 9ee7d1587d..a8ddae35f7 100644
> --- a/meta/classes/scons.bbclass
> +++ b/meta/classes/scons.bbclass
> @@ -1,4 +1,4 @@
> -DEPENDS += "python-scons-native"
> +DEPENDS += "python3-scons-native"
>

some packages haven't upgraded to py3 but use scons see
https://errors.yoctoproject.org/Errors/Details/249271/

>  EXTRA_OESCONS ?= ""
>
> --
> 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 2/2] efibootmgr: add

2019-06-20 Thread Khem Raj
On Wed, Jun 12, 2019 at 2:36 PM Ross Burton  wrote:
>
> This was in meta-oe but EFI is sufficiently widespread now that we need it in
> core.
>
> The recipe is based on the one in meta-oe but with several updates.
>

now there is a patch to meta-oe to remove it and I see built failure
with clang/musl on x86_64

make[1]: *** No rule to make target 'efivar.h', needed by 'efibootmgr.o'.  Stop.

see
https://errors.yoctoproject.org/Errors/Details/249267/

meta-oe one did not have this error.

> Signed-off-by: Ross Burton 
> ---
>  .../efibootmgr/0001-remove-extra-decl.patch| 31 
>  meta/recipes-bsp/efibootmgr/efibootmgr_17.bb   | 34 
> ++
>  2 files changed, 65 insertions(+)
>  create mode 100644 
> meta/recipes-bsp/efibootmgr/efibootmgr/0001-remove-extra-decl.patch
>  create mode 100644 meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
>
> diff --git 
> a/meta/recipes-bsp/efibootmgr/efibootmgr/0001-remove-extra-decl.patch 
> b/meta/recipes-bsp/efibootmgr/efibootmgr/0001-remove-extra-decl.patch
> new file mode 100644
> index 000..42f3a8182df
> --- /dev/null
> +++ b/meta/recipes-bsp/efibootmgr/efibootmgr/0001-remove-extra-decl.patch
> @@ -0,0 +1,31 @@
> +From 99b578501643377e0b1994b2a068b790d189d5ad Mon Sep 17 00:00:00 2001
> +From: Peter Jones 
> +Date: Wed, 13 Jun 2018 09:41:01 -0400
> +Subject: [PATCH] remove extra decl
> +
> +Signed-off-by: Peter Jones 
> +
> +Upstream-Status: Backport [git://github.com/rhinstaller/efibootmgr.git]
> +Signed-off-by: Hongxu Jia 
> +
> +---
> + src/efibootmgr.c | 3 ---
> + 1 file changed, 3 deletions(-)
> +
> +diff --git a/src/efibootmgr.c b/src/efibootmgr.c
> +index de38f01..4e1a680 100644
> +--- a/src/efibootmgr.c
>  b/src/efibootmgr.c
> +@@ -1536,9 +1536,6 @@ parse_opts(int argc, char **argv)
> +  "invalid numeric value %s\n",
> +  optarg);
> +   }
> +-/* XXX efivar-36 accidentally doesn't have a public
> +- * header for this */
> +-  extern int efi_set_verbose(int verbosity, FILE 
> *errlog);
> +   efi_set_verbose(opts.verbose - 2, stderr);
> +   break;
> +   case 'V':
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb 
> b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
> new file mode 100644
> index 000..0e5a81e3166
> --- /dev/null
> +++ b/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb
> @@ -0,0 +1,34 @@
> +DESCRIPTION = "Linux user-space application to modify the EFI Boot Manager."
> +SUMMARY = "EFI Boot Manager"
> +HOMEPAGE = "https://github.com/rhboot/efibootmgr;
> +SECTION = "base"
> +
> +LICENSE = "GPLv2+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3"
> +
> +DEPENDS = "efivar popt"
> +
> +COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
> +
> +SRC_URI = "git://github.com/rhinstaller/efibootmgr.git;protocol=https \
> +   file://0001-remove-extra-decl.patch \
> +  "
> +SRCREV = "e067160ecef8208e1944002e5d50b275733211fb"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit pkgconfig
> +
> +# The directory under the ESP that the default bootloader is found in.  When
> +# wic uses a subdirectory, this should use the same one too.
> +EFIDIR ?= "/"
> +
> +EXTRA_OEMAKE += "'EFIDIR=${EFIDIR}'"
> +
> +CFLAGS += " -Wno-error"
> +
> +do_install () {
> +   oe_runmake install DESTDIR="${D}"
> +}
> +
> +CLEANBROKEN = "1"
> --
> 2.11.0
>
> --
> ___
> 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


[OE-core] [PATCH] cmake: Clarify comment in cmake toolchain file

2019-06-20 Thread Richard Purdie
The comment is misleading and there was confusion in a bug report. In the native
case STAGING_DATADIR would be equal to the native value so there isn't any issue
but tweak the comment.

[YOCTO #12761]

Signed-off-by: Richard Purdie 
---
 meta/classes/cmake.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index f80a7e2f1d6..2b317c832fe 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -119,7 +119,7 @@ set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
 # directory as rpath by default
 set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
 
-# Use native cmake modules
+# Use our cmake modules
 list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
 
 # add for non /usr/lib libdir, e.g. /usr/lib64
-- 
2.20.1

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


Re: [OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Robert Yang




On 6/20/19 5:19 PM, Adrian Bunk wrote:

On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:

...
Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
need something like virtual/gtk to fix these problems totally?


GTK+2 is mostly obsolete.

I just checked the GTK4 sources, and there it is renamed to
gtk4-update-icon-cache. Based on that I would say that your
patch is actually fine at least for now.


Thanks, I updated the commit message in the PULL:

The gtk-update-icon-cache is provided by gtk+3, gdk-pixbuf-query-loaders is
provided by gdk-pixbuf, and gtk+3 depends on gdk-pixbuf, so depends on gtk+3
can fix the problems.


// Robert




// Robert


cu
Adrian


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


Re: [OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Alexander Kanavin
I’d say virtual/gtk wouldn’t be helpful much as 2/3/4 versions have major api 
differences.

Alex

> On 20 Jun 2019, at 11.19, Adrian Bunk  wrote:
> 
>> On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
>> ...
>> Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
>> need something like virtual/gtk to fix these problems totally?
> 
> GTK+2 is mostly obsolete.
> 
> I just checked the GTK4 sources, and there it is renamed to 
> gtk4-update-icon-cache. Based on that I would say that your
> patch is actually fine at least for now.
> 
>> // Robert
> 
> 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/4] cve-update-db: New recipe to update CVE database

2019-06-20 Thread Pierre Le Magourou
> Not sure which of the changes is responsible, but this is new:
> WARNING: flex-native-2.6.0-r0 do_cve_check: Found unpatched CVE
> (CVE-2015-1773)
>
> https://nvd.nist.gov/vuln/detail/CVE-2015-1773
>
> Note that the flex tool is completely unrelated to Apache Flex.
>
>
I see, the 4/4 patch is responsible for that (Consider CVE that affects
versions with less than operator). It takes into account the comparison
operator in the json NVD file (new 'version_affected' field that was not in
the XML data feed). So this CVE matches because 2.6.0 <= 4.14.0. But it
should not match because it concerns another product (flex_project/flex vs
Apache/flex).

There is indeed a problem I didn't manage. The CVE_PRODUCT variable we use
in cve-check only takes the product name (here 'flex') into account, we
should also consider the vendor name (here 'flex_project').

Without this patch (4/4), the behaviour should be the same as before.

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


[OE-core] [PATCH] bitbake: add iconv to HOSTTOOLS

2019-06-20 Thread mingli.yu
From: Mingli Yu 

Some package such as vim depends on iconv.
Without iconv, vim-common which is the
sub-pakcage of vim may include different files
as failed to use iconv to generate the *.po file.

Signed-off-by: Mingli Yu 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index c5313ccd19..4b907d6820 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -492,7 +492,7 @@ HOSTTOOLS += " \
 [ ar as awk basename bash bzip2 cat chgrp chmod chown chrpath cmp comm cp 
cpio \
 cpp cut date dd diff diffstat dirname du echo egrep env expand expr false \
 fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \
-head hostname id install ld ldd ln ls make makeinfo md5sum mkdir mknod \
+head hostname iconv id install ld ldd ln ls make makeinfo md5sum mkdir 
mknod \
 mktemp mv nm objcopy objdump od patch perl pod2man pr printf pwd python2 \
 python2.7 python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq 
sh sha256sum \
 sleep sort split stat strings strip tail tar tee test touch tr true uname \
-- 
2.21.0

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


Re: [OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Adrian Bunk
On Thu, Jun 20, 2019 at 04:46:16PM +0800, Robert Yang wrote:
>...
> Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
> need something like virtual/gtk to fix these problems totally?

GTK+2 is mostly obsolete.

I just checked the GTK4 sources, and there it is renamed to 
gtk4-update-icon-cache. Based on that I would say that your
patch is actually fine at least for now.

> // Robert

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] mdadm: fix systemd service start up failure

2019-06-20 Thread Changqing Li



On 6/20/19 3:35 PM, Adrian Bunk wrote:

On Thu, Jun 20, 2019 at 11:14:03AM +0800, changqing...@windriver.com wrote:

From: Changqing Li 

1. mdadm: No mail address or alert command - not monitoring

with --monitor mode, mdadm needs a mail address and/or a program.
This can be given with "mailaddr" and "program" lines to that
monitoring can be started using.

fix by given a mail address, user can replace with a valid one
when use.
...
+sed -i -e 's/#MAILADDR r...@mydomain.tld/MAILADDR r...@mydomain.tld/g' 
${D}${sysconfdir}/mdadm.conf
...

Defaulting to try to send emails to an invalid address is worse than not
having an email address configured.

Looking at the manpages I would have expected syslog-only monitoring to
work if neither mailaddr nor program are configured.
If this isn't working, is this something upstream considers a bug?

Thanks, I will check this, and try find another solution.


cu
Adrian


--
BRs

Sandy(Li Changqing)

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


Re: [OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Robert Yang




On 6/20/19 4:28 PM, Adrian Bunk wrote:

On Thu, Jun 20, 2019 at 04:15:26PM +0800, Robert Yang wrote:

The gtk-update-icon-cache and gdk-pixbuf-query-loaders are provided by gtk+3.


gdk-pixbuf-query-loaders is provided by gdk-pixbuf,
which is not tied to a specific GTK version.

gtk-update-icon-cache is provided by both GTK 2 and GTK 3,
I haven't checked whether it will also be in GTK 4.


Thanks, I will update it.




...
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -4,6 +4,11 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 
'hicolor-icon-theme']} gtk
  
  PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
  
+inherit distro_features_check

+ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
+
+DEPENDS += "gtk+3"
...


This looks OK.


@@ -45,10 +50,11 @@ python populate_packages_append () {
  if not os.path.exists(icon_dir):
  continue
  
-bb.note("adding hicolor-icon-theme dependency to %s" % pkg)

-rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
-d.appendVar('RDEPENDS_%s' % pkg, rdepends)
-
+for dep in ('hicolor-icon-theme', 'gtk+3'):
+bb.note("Adding %s dependency to %s" % (dep, pkg))
+rdepends = ' ' + d.getVar('MLPREFIX', False) + dep
+d.appendVar('RDEPENDS_%s' % pkg, rdepends)
...


Why is this necessary?


Otherwise, gtk+3 won't be installed.



I would expect there to always be a generated RDEPENDS on either
gtk+ or gtk+3 (or soon gtk4) that already covers this.
Anything I miss here?


gtk2/3/4 is a problem, I checked DEPENDS in oe-core's recipes, most
of them depend on gtk+3, only one depends on gtk+:

meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb

Maybe gtk+2 is out of date? Since gtk+4 is on the way, so I think that we
need something like virtual/gtk to fix these problems totally?

// Robert



cu
Adrian


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


[OE-core] [PATCH] go: Upgrade 1.12.5 -> 1.12.6

2019-06-20 Thread Adrian Bunk
Signed-off-by: Adrian Bunk 
---
 meta/recipes-devtools/go/go-1.12.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/go/go-1.12.inc 
b/meta/recipes-devtools/go/go-1.12.inc
index 7c4cac1fc2..3f23f06f09 100644
--- a/meta/recipes-devtools/go/go-1.12.inc
+++ b/meta/recipes-devtools/go/go-1.12.inc
@@ -1,7 +1,7 @@
 require go-common.inc
 
 GO_BASEVERSION = "1.12"
-GO_MINOR = ".5"
+GO_MINOR = ".6"
 PV .= "${GO_MINOR}"
 FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
 
@@ -19,5 +19,5 @@ SRC_URI += "\
 "
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
 
-SRC_URI[main.md5sum] = "cb6f594d22dd79af4fff9779607b1b47"
-SRC_URI[main.sha256sum] = 
"2aa5f088cbb332e73fc3def546800616b38d3bfe6b8713b8a6404060f22503e8"
+SRC_URI[main.md5sum] = "48a4141fc718dd742d106431294f08bf"
+SRC_URI[main.sha256sum] = 
"c96c5ccc7455638ae1a8b7498a030fe653731c8391c5f8e79590bce72f92b4ca"
-- 
2.17.1

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


Re: [OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Adrian Bunk
On Thu, Jun 20, 2019 at 04:15:26PM +0800, Robert Yang wrote:
> The gtk-update-icon-cache and gdk-pixbuf-query-loaders are provided by gtk+3.

gdk-pixbuf-query-loaders is provided by gdk-pixbuf,
which is not tied to a specific GTK version.

gtk-update-icon-cache is provided by both GTK 2 and GTK 3,
I haven't checked whether it will also be in GTK 4.

>...
> --- a/meta/classes/gtk-icon-cache.bbclass
> +++ b/meta/classes/gtk-icon-cache.bbclass
> @@ -4,6 +4,11 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 
> 'hicolor-icon-theme']} gtk
>  
>  PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
>  
> +inherit distro_features_check
> +ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
> +
> +DEPENDS += "gtk+3"
>...

This looks OK.

> @@ -45,10 +50,11 @@ python populate_packages_append () {
>  if not os.path.exists(icon_dir):
>  continue
>  
> -bb.note("adding hicolor-icon-theme dependency to %s" % pkg)
> -rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
> -d.appendVar('RDEPENDS_%s' % pkg, rdepends)
> -
> +for dep in ('hicolor-icon-theme', 'gtk+3'):
> +bb.note("Adding %s dependency to %s" % (dep, pkg))
> +rdepends = ' ' + d.getVar('MLPREFIX', False) + dep
> +d.appendVar('RDEPENDS_%s' % pkg, rdepends)
>...

Why is this necessary?

I would expect there to always be a generated RDEPENDS on either
gtk+ or gtk+3 (or soon gtk4) that already covers this.
Anything I miss here?

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] [PATCH 2/4] make-mod-scripts: Depends on bison-native

2019-06-20 Thread Robert Yang
Fixed do_configure error when use linux-dummy:
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"

/bin/sh: bison: command not found

Build make-mod-scripts doesn't make sense when use linux-dummy, but it breaks
"bitbake world", so add bison-native to DEPENDS to fix the problem.

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb 
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 97c58c5..460e05a 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -12,7 +12,7 @@ S = "${WORKDIR}"
 do_configure[depends] += "virtual/kernel:do_shared_workdir 
openssl-native:do_populate_sysroot"
 do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
 
-DEPENDS += "bc-native"
+DEPENDS += "bc-native bison-native"
 
 EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
HOSTCPP="${BUILD_CPP}""
 
-- 
2.7.4

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


[OE-core] [PATCH 3/4] update-alternatives.bbclass: run update-alternatives firstly in postinst script

2019-06-20 Thread Robert Yang
Recipes like postfix run command newaliases in postinst, but newaliases is
installed newaliases.postfix, and need run update-alternatives to update it to
newaliases, so we would get the error when install postinst on target.

Fixed:
$ opkg install postfix
Configuring postfix.
///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command not found

Run update-alternatives firstly will fix the problem.

Signed-off-by: Robert Yang 
---
 meta/classes/update-alternatives.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/update-alternatives.bbclass 
b/meta/classes/update-alternatives.bbclass
index b702e77..8c2b66e 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -284,8 +284,11 @@ python populate_packages_updatealternatives () {
 
 bb.note('adding update-alternatives calls to postinst/prerm for 
%s' % pkg)
 bb.note('%s' % alt_setup_links)
-postinst = d.getVar('pkg_postinst_%s' % pkg) or '#!/bin/sh\n'
-postinst += alt_setup_links
+postinst = d.getVar('pkg_postinst_%s' % pkg)
+if postinst:
+postinst = alt_setup_links + postinst
+else:
+postinst = '#!/bin/sh\n' + alt_setup_links
 d.setVar('pkg_postinst_%s' % pkg, postinst)
 
 bb.note('%s' % alt_remove_links)
-- 
2.7.4

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


[OE-core] [PATCH 4/4] gtk-icon-cache.bbclass: Depends on gtk+3

2019-06-20 Thread Robert Yang
The gtk-update-icon-cache and gdk-pixbuf-query-loaders are provided by gtk+3.

Signed-off-by: Robert Yang 
---
 meta/classes/gtk-icon-cache.bbclass | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass 
b/meta/classes/gtk-icon-cache.bbclass
index 66fe781..4e60fe6 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -4,6 +4,11 @@ DEPENDS +=" ${@['hicolor-icon-theme', '']['${BPN}' == 
'hicolor-icon-theme']} gtk
 
 PACKAGE_WRITE_DEPS += "gtk+3-native gdk-pixbuf-native"
 
+inherit distro_features_check
+ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
+
+DEPENDS += "gtk+3"
+
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} \
@@ -45,10 +50,11 @@ python populate_packages_append () {
 if not os.path.exists(icon_dir):
 continue
 
-bb.note("adding hicolor-icon-theme dependency to %s" % pkg)
-rdepends = ' ' + d.getVar('MLPREFIX', False) + "hicolor-icon-theme"
-d.appendVar('RDEPENDS_%s' % pkg, rdepends)
-
+for dep in ('hicolor-icon-theme', 'gtk+3'):
+bb.note("Adding %s dependency to %s" % (dep, pkg))
+rdepends = ' ' + d.getVar('MLPREFIX', False) + dep
+d.appendVar('RDEPENDS_%s' % pkg, rdepends)
+
 bb.note("adding gtk-icon-cache postinst and postrm scripts to %s" % 
pkg)
 
 postinst = d.getVar('pkg_postinst_%s' % pkg)
-- 
2.7.4

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


[OE-core] [PATCH 0/4] meta: 4 fixes

2019-06-20 Thread Robert Yang
The following changes since commit 2106a567820bad438ff78d54a49e3d87da428dcf:

  python3: python3: Fix build error x86->x86 (2019-06-19 13:15:55 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/4fixes
  http://cgit.openembedded.org//log/?h=rbt/4fixes

Robert Yang (4):
  linux-dummy: Add do_compile_kernelmodules
  make-mod-scripts: Depends on bison-native
  update-alternatives.bbclass: run update-alternatives firstly in
postinst script
  gtk-icon-cache.bbclass: Depends on gtk+3

 meta/classes/gtk-icon-cache.bbclass| 14 ++
 meta/classes/update-alternatives.bbclass   |  7 +--
 meta/recipes-kernel/linux/linux-dummy.bb   |  5 +
 .../make-mod-scripts/make-mod-scripts_1.0.bb   |  2 +-
 4 files changed, 21 insertions(+), 7 deletions(-)

-- 
2.7.4

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


[OE-core] [PATCH 1/4] linux-dummy: Add do_compile_kernelmodules

2019-06-20 Thread Robert Yang
Fixed:
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"

$ bitbake world
ERROR: Task do_compile in make-mod-scripts_1.0.bb depends upon non-existent 
task do_compile_kernelmodules in linux-dummy.bb
ERROR: Command execution failed: Exited with 1

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/linux/linux-dummy.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-dummy.bb 
b/meta/recipes-kernel/linux/linux-dummy.bb
index e1c7f76..62cf6f5 100644
--- a/meta/recipes-kernel/linux/linux-dummy.bb
+++ b/meta/recipes-kernel/linux/linux-dummy.bb
@@ -39,6 +39,10 @@ do_compile () {
:
 }
 
+do_compile_kernelmodules() {
+:
+}
+
 do_shared_workdir () {
:
 }
@@ -58,3 +62,4 @@ do_deploy() {
 addtask bundle_initramfs after do_install before do_deploy
 addtask deploy after do_install
 addtask shared_workdir after do_compile before do_install
+addtask compile_kernelmodules
-- 
2.7.4

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


Re: [OE-core] [PATCH] mdadm: fix systemd service start up failure

2019-06-20 Thread Adrian Bunk
On Thu, Jun 20, 2019 at 11:14:03AM +0800, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> 1. mdadm: No mail address or alert command - not monitoring
> 
> with --monitor mode, mdadm needs a mail address and/or a program.
> This can be given with "mailaddr" and "program" lines to that
> monitoring can be started using.
> 
> fix by given a mail address, user can replace with a valid one
> when use.
>...
> +sed -i -e 's/#MAILADDR r...@mydomain.tld/MAILADDR 
> r...@mydomain.tld/g' ${D}${sysconfdir}/mdadm.conf
>...

Defaulting to try to send emails to an invalid address is worse than not 
having an email address configured.

Looking at the manpages I would have expected syslog-only monitoring to 
work if neither mailaddr nor program are configured.
If this isn't working, is this something upstream considers a bug?

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] [RFC][PATCH] systemd: Remove clearly incorrect musl patches

2019-06-20 Thread Adrian Bunk
On Wed, Jun 19, 2019 at 12:59:05PM -0700, Khem Raj wrote:
> On Fri, Jun 14, 2019 at 4:44 AM Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> 
> > On Fri, 2019-06-14 at 10:29 +0300, Adrian Bunk wrote:
> > > This removes clearly incorrect musl patches and marks
> > > systemd as incompatible with musl until these issues
> > > are fixed.
> > >
> > > The previous status quo where systemd was made compiling
> > > with patches that are known to introduce bugs and security
> > > vulnerabilities silently delivered a sub-standard package
> > > to users, this change makes it clear where work is needed
> > > to be done by people interested in systemd on musl.
> > >
> > > Patches that are merely questionable or not upstreamable
> > > are not touched.
> >
> > I'll be interested to see what others think of this, I can't imagine
> > this move being very popular...
> 
> There are real products using this combination

An OE-only combination neither upstream supports.

> And this is not a good message, eventually we want to either fix or stop
> supporting this but I think now is not the time

When is the time?

In a month?
Before the Yocto 2.8 branching?
After the Yocto 2.8 branching?

The best solution would be if someone would step up to properly maintain 
the systemd/musl combination, but usually such "either fix or stop" only
work with a clear deadline.

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