Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Khem Raj]

On Tue, Sep 4, 2018 at 9:08 PM Andre McCurdy  wrote:
>
> On Tue, Sep 4, 2018 at 6:49 PM, Khem Raj  wrote:
> > On Tue, Sep 4, 2018 at 3:58 PM  wrote:
> >>
> >> On Tue, 2018-09-04 at 13:43 -0700, Khem Raj wrote:
> >> > I pointed this earlier before merge as well
> >> > meta-openembedded has 40 odd recipes failing due to openssl 1.1
> >> > upgrade
> >>
> >> Sorry, I think I missed something somewhere as I thought the
> >> indications were the bigger problems like qt5 were working now :/.
> >>
> >> > http://errors.yoctoproject.org/Errors/Build/67457/?page=2=50
> >> >
> >> > so obvious fix was to keep them pinned to openssl10 and i created
> >> > couple of fixes
> >> > to start
> >> >
> >> > https://patchwork.openembedded.org/patch/154517/
> >> > https://patchwork.openembedded.org/patch/154516/
> >> >
> >> > and the effects are showing up where sysroot task now starts to fail
> >> > for dependent
> >> > recipes here
> >> >
> >> > http://errors.yoctoproject.org/Errors/Details/190427/
> >> > http://errors.yoctoproject.org/Errors/Details/190433/
> >> >
> >> > in meta-oe certain recipes can be upgraded and we can get openssl 1.1
> >> > support
> >> > but others like the two examples I cited above do not have openSSL
> >> > 1.1 port.
> >> > so I think we can not live without openSSL 1.0 and OpenSSL 2.0 being
> >> > able to
> >> > co-exist.
> >>
> >> The latter link is php 7.2 which should have openssl 1.1 support
> >> (https://bugs.php.net/bug.php?id=72360).
> >>
> >> For the former, libgdata doesn't have an openssl depends so I guessed
> >> at liboauth pulling it in which does have an openssl 1.1 patch at:
> >> https://github.com/x42/liboauth/issues/9
> >>
> >
> > Thanks for pointers and they do help. However IMO the problem that
> > Martin decribed
> > is going to be a real blocker. Unless we can provide a solution to let
> > both openssl versions
> > coexist, this change is going to be problematic since we maintain
> > several old recipes which
> > would have to be fixed for openssl 1.1 and this can take time, right
> > now we are only seeing
> > meta-openembedded layers, we don't even know all other layers which
> > might get into similar
> > issues.
>
> To be clear, the issue is ( foo depends on openssl 1.1 and bar ) and (
> bar depends on openssl 1.0 ), right?

yes.

>
> Anyway, just for reference, it looks like Debian is packaging both
> openssl 1.0 and 1.1:
>
>   https://packages.debian.org/source/sid/openssl1.0
>   https://packages.debian.org/source/sid/openssl
>
> In the case of liboauth, they avoid to need to patch by configuring
> liboauth to build with nss instead of openssl.

this is already taken care see
http://git.openembedded.org/meta-openembedded-contrib/commit/?h=kraj/master=b1f87edc4202d6238c469dde358819c534b35751

but thats just one case.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Andre McCurdy]

On Tue, Sep 4, 2018 at 6:49 PM, Khem Raj  wrote:
> On Tue, Sep 4, 2018 at 3:58 PM  wrote:
>>
>> On Tue, 2018-09-04 at 13:43 -0700, Khem Raj wrote:
>> > I pointed this earlier before merge as well
>> > meta-openembedded has 40 odd recipes failing due to openssl 1.1
>> > upgrade
>>
>> Sorry, I think I missed something somewhere as I thought the
>> indications were the bigger problems like qt5 were working now :/.
>>
>> > http://errors.yoctoproject.org/Errors/Build/67457/?page=2=50
>> >
>> > so obvious fix was to keep them pinned to openssl10 and i created
>> > couple of fixes
>> > to start
>> >
>> > https://patchwork.openembedded.org/patch/154517/
>> > https://patchwork.openembedded.org/patch/154516/
>> >
>> > and the effects are showing up where sysroot task now starts to fail
>> > for dependent
>> > recipes here
>> >
>> > http://errors.yoctoproject.org/Errors/Details/190427/
>> > http://errors.yoctoproject.org/Errors/Details/190433/
>> >
>> > in meta-oe certain recipes can be upgraded and we can get openssl 1.1
>> > support
>> > but others like the two examples I cited above do not have openSSL
>> > 1.1 port.
>> > so I think we can not live without openSSL 1.0 and OpenSSL 2.0 being
>> > able to
>> > co-exist.
>>
>> The latter link is php 7.2 which should have openssl 1.1 support
>> (https://bugs.php.net/bug.php?id=72360).
>>
>> For the former, libgdata doesn't have an openssl depends so I guessed
>> at liboauth pulling it in which does have an openssl 1.1 patch at:
>> https://github.com/x42/liboauth/issues/9
>>
>
> Thanks for pointers and they do help. However IMO the problem that
> Martin decribed
> is going to be a real blocker. Unless we can provide a solution to let
> both openssl versions
> coexist, this change is going to be problematic since we maintain
> several old recipes which
> would have to be fixed for openssl 1.1 and this can take time, right
> now we are only seeing
> meta-openembedded layers, we don't even know all other layers which
> might get into similar
> issues.

To be clear, the issue is ( foo depends on openssl 1.1 and bar ) and (
bar depends on openssl 1.0 ), right?

Anyway, just for reference, it looks like Debian is packaging both
openssl 1.0 and 1.1:

  https://packages.debian.org/source/sid/openssl1.0
  https://packages.debian.org/source/sid/openssl

In the case of liboauth, they avoid to need to patch by configuring
liboauth to build with nss instead of openssl.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Andre McCurdy]

On Tue, Sep 4, 2018 at 8:18 PM, Hongxu Jia  wrote:
> On 2018年09月05日 10:41, Andre McCurdy wrote:
>>
>> On Tue, Sep 4, 2018 at 7:16 PM, Hongxu Jia 
>> wrote:
>>>
>>> On 2018年09月05日 09:59, Andre McCurdy wrote:

 On Tue, Sep 4, 2018 at 6:02 PM, Hongxu Jia 
 wrote:
>
> On 2018年09月05日 03:14, Andre McCurdy wrote:
>>
>> Maybe I'm missing something, but what's the advantage of using SHELL
>> to run this little wrapper script rather than hardcoding /bin/sh ?
>>
>> Task shell scripts created by bitbake use hardcoded /bin/sh (see
>> bitbake/lib/bb/build.py -> shell_trap_code())
>
> Keep align with the devshell as the comments mentioned above

 Yeah, I've read the comments. I still don't really understand why.

> The devshell.bbclass set var-SHELL to var-DEVSHELL, and
> terminal.bbclass
> initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
> than hardcoded `/bin/sh' as the shebang of wrapper script.
>
> On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
> we assign var-SHELL with `/bin/bash', the wrapper script is still
> dashism.

 What exactly is a dashism?
>>>
>>>
>>> In another word, it does not support bashism.
>>>
>>> Here is a case which `export -f' is bashism although
>>>
>>> devshell using bash, but /bin/sh -> dash
>>>
>>> [case]
>>>
>>> function foobar { echo foobar; };
>>>   export -f foobar
>>> bitbake -c devshell virtual/kernel
>>>
>>> [case]
>>>
>>>
>>> BTW, I've sent anther patch to fix it `[OE-core] [PATCH]
>>> devshell.bbclass/terminal.bbclass: add a shell check at devshell'
>>
>> OK, but run.do_terminal.xxx is a trivial wrapper which (apart from
>> exporting environment variables) just contains something like:
>>
>>do_terminal() {
>>exec pseudo /bin/bash
>>}
>>
>>do_terminal
>>
>> I'm not sure what the problem is running that with /bin/sh, regardless
>> of whether /bin/sh points to bash or dash?
>
>
> Isn't clear? In above case, even though `exec pseudo /bin/bash',
>
> since /bin/sh points to dash, the devshell started failed
>
> [snip]
>
> bitbake -c devshell virtual/kernel
> Trying to run: screen -r devshell_23640
> Cannot open your terminal '/dev/pts/39' - please check.
>
> [snip]
>
> Since `export -f' is bashism, use dash to load wrapper script failed

I understand that dash can not run bash specific syntax. What I don't
understand is where does the bash specific syntax in the terminal
wrapper script come from?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Hongxu Jia]

On 2018年09月05日 10:41, Andre McCurdy wrote:

On Tue, Sep 4, 2018 at 7:16 PM, Hongxu Jia  wrote:

On 2018年09月05日 09:59, Andre McCurdy wrote:

On Tue, Sep 4, 2018 at 6:02 PM, Hongxu Jia 
wrote:

On 2018年09月05日 03:14, Andre McCurdy wrote:

Maybe I'm missing something, but what's the advantage of using SHELL
to run this little wrapper script rather than hardcoding /bin/sh ?

Task shell scripts created by bitbake use hardcoded /bin/sh (see
bitbake/lib/bb/build.py -> shell_trap_code())

Keep align with the devshell as the comments mentioned above

Yeah, I've read the comments. I still don't really understand why.


The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
than hardcoded `/bin/sh' as the shebang of wrapper script.

On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
we assign var-SHELL with `/bin/bash', the wrapper script is still
dashism.

What exactly is a dashism?


In another word, it does not support bashism.

Here is a case which `export -f' is bashism although

devshell using bash, but /bin/sh -> dash

[case]

function foobar { echo foobar; };
  export -f foobar
bitbake -c devshell virtual/kernel

[case]


BTW, I've sent anther patch to fix it `[OE-core] [PATCH]
devshell.bbclass/terminal.bbclass: add a shell check at devshell'

OK, but run.do_terminal.xxx is a trivial wrapper which (apart from
exporting environment variables) just contains something like:

   do_terminal() {
   exec pseudo /bin/bash
   }

   do_terminal

I'm not sure what the problem is running that with /bin/sh, regardless
of whether /bin/sh points to bash or dash?


Isn't clear? In above case, even though `exec pseudo /bin/bash',

since /bin/sh points to dash, the devshell started failed

[snip]

bitbake -c devshell virtual/kernel
Trying to run: screen -r devshell_23640
Cannot open your terminal '/dev/pts/39' - please check.

[snip]

Since `export -f' is bashism, use dash to load wrapper script failed


//Hongxu

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

Re: [OE-core] [PATCH 1/6] allarch: disable allarch when multilib is used

[Kang Kai]

On 2018年09月04日 16:36, richard.pur...@linuxfoundation.org wrote:

Hi,

I think this is close and it passes the tests on the autobuilder
however I did spot a couple of potential issues after thinking about
this for a bit.

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:

Some allarch packages rdepends non-allarch packages. When multilib is
used, it doesn't expand the dependency chain correctly, e.g.

core-image-sato -> ca-certificates(allarch) -> openssl

we expect dependency chain for lib32-core-image-sato:

lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl

it should install lib32-openssl for ca-certificates but openssl is
still wrongly required.

Copy allarch.bbclass to allarch-enabled.bbclass and only inherit
allarch-enabled.bbclass when multilib is not used.

Signed-off-by: Kai Kang 
---
  meta/classes/allarch-enabled.bbclass | 52 
  meta/classes/allarch.bbclass | 51 ++-
  meta/classes/icecc.bbclass   |  2 +-
  meta/classes/multilib.bbclass|  2 +-
  meta/classes/multilib_global.bbclass |  2 +-
  meta/classes/package.bbclass |  6 ++---
  6 files changed, 60 insertions(+), 55 deletions(-)
  create mode 100644 meta/classes/allarch-enabled.bbclass


diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 1eebe0bf2e7..0eca076df0b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -1,52 +1,5 @@
  #
-# This class is used for architecture independent recipes/data files (usually 
scripts)
+# This class enables allarch only when multilib is not used.
  #
  
-PACKAGE_ARCH = "all"

-
-python () {
-# Allow this class to be included but overridden - only set
-# the values if we're still "all" package arch.
-if d.getVar("PACKAGE_ARCH") == "all":
-# No need for virtual/libc or a cross compiler
-d.setVar("INHIBIT_DEFAULT_DEPS","1")
-
-# Set these to a common set of values, we shouldn't be using them 
other that for WORKDIR directory
-# naming anyway
-d.setVar("baselib", "lib")
-d.setVar("TARGET_ARCH", "allarch")
-d.setVar("TARGET_OS", "linux")
-d.setVar("TARGET_CC_ARCH", "none")
-d.setVar("TARGET_LD_ARCH", "none")
-d.setVar("TARGET_AS_ARCH", "none")
-d.setVar("TARGET_FPU", "")
-d.setVar("TARGET_PREFIX", "")
-# Expand PACKAGE_EXTRA_ARCHS since the staging code needs this
-# (this removes any dependencies from the hash perspective)
-d.setVar("PACKAGE_EXTRA_ARCHS", d.getVar("PACKAGE_EXTRA_ARCHS"))
-d.setVar("SDK_ARCH", "none")
-d.setVar("SDK_CC_ARCH", "none")
-d.setVar("TARGET_CPPFLAGS", "none")
-d.setVar("TARGET_CFLAGS", "none")
-d.setVar("TARGET_CXXFLAGS", "none")
-d.setVar("TARGET_LDFLAGS", "none")
-d.setVar("POPULATESYSROOTDEPS", "")
-
-# Avoid this being unnecessarily different due to nuances of
-# the target machine that aren't important for "all" arch
-# packages.
-d.setVar("LDFLAGS", "")
-
-# No need to do shared library processing or debug symbol handling
-d.setVar("EXCLUDE_FROM_SHLIBS", "1")
-d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
-d.setVar("INHIBIT_PACKAGE_STRIP", "1")
-
-# These multilib values shouldn't change allarch packages so exclude 
them
-d.appendVarFlag("emit_pkgdata", "vardepsexclude", " MULTILIB_VARIANTS")
-d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS")
-d.appendVarFlag("do_package", "vardepsexclude", " package_do_shlibs")
-elif bb.data.inherits_class('packagegroup', d) and not 
bb.data.inherits_class('nativesdk', d):
-bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" 
% d.getVar("FILE"))
-}
-
+inherit ${@oe.utils.ifelse(d.getVar('MULTILIB_VARIANTS'), '', 
'allarch-enabled')}

Firstly, whilst I do understand why you've made this change like this,
I don't really like one line classes which clutter up the classes
directory. Using inherit like this does force the expansion of the
variable early and is very prone to "race" conditions. The above is
safe but see below.

FWIW the original code tried to switch off the value of the
PACKAGE_ARCH variable. If we change the way we enable/disable the code,
we should consider whether we can consistently use one mechanism for
both.

Secondly, does this change affect the behaviour of nativesdk?

I think this will disable allarch for nativesdk in any multilib build
and we don't want to do that, we only have a problem with target
multilib allarch.


I searched oe-core for which inherits allarch and bbextend nativesdk by:

$ rgrep 'inherit.*allarch' -l meta | xargs grep -l 
'BBCLASSEXTEND.*nativesdk'

meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
meta/recipes-support/ca-certificates/ca-certificates_20180409.bb

[OE-core] [PATCH] elfutils: CVE-2018-16062

[Zhixiong Chi]

Backport the CVE patch from the upstream:
https://sourceware.org/git/?p=elfutils.git;a=commit;
h=29e31978ba51c1051743a503ee325b5ebc03d7e9

Signed-off-by: Zhixiong Chi 
---
 .../elfutils/elfutils_0.173.bb|  1 +
 .../elfutils/files/CVE-2018-16062.patch   | 79 +++
 2 files changed, 80 insertions(+)
 create mode 100644 meta/recipes-devtools/elfutils/files/CVE-2018-16062.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.173.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.173.bb
index 03144dc842..2fec73dbdb 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.173.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.173.bb
@@ -28,6 +28,7 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://debian/ignore_strmerge.diff \
file://debian/0001-fix-gcc7-ftbfs.patch \
file://debian/0001-disable_werror.patch \
+   file://CVE-2018-16062.patch \
"
 SRC_URI_append_libc-musl = " 
file://0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch"
 
diff --git a/meta/recipes-devtools/elfutils/files/CVE-2018-16062.patch 
b/meta/recipes-devtools/elfutils/files/CVE-2018-16062.patch
new file mode 100644
index 00..cfeb1ca13c
--- /dev/null
+++ b/meta/recipes-devtools/elfutils/files/CVE-2018-16062.patch
@@ -0,0 +1,79 @@
+From 29e31978ba51c1051743a503ee325b5ebc03d7e9 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard 
+Date: Sat, 18 Aug 2018 13:27:48 +0200
+Subject: [PATCH] libdw, readelf: Make sure there is enough data to read full
+ aranges header.
+
+dwarf_getaranges didn't check if there was enough data left to read both
+the address and segment size. readelf didn't check there was enough data
+left to read the segment size.
+
+https://sourceware.org/bugzilla/show_bug.cgi?id=23541
+
+CVE: CVE-2018-16062
+Upstream-Status: Backport
+
+Signed-off-by: Mark Wielaard 
+---
+ libdw/ChangeLog  | 5 +
+ libdw/dwarf_getaranges.c | 4 
+ src/ChangeLog| 5 +
+ src/readelf.c| 2 ++
+ 4 files changed, 16 insertions(+)
+
+diff --git a/libdw/ChangeLog b/libdw/ChangeLog
+index cb4f34e..472d922 100644
+--- a/libdw/ChangeLog
 b/libdw/ChangeLog
+@@ -1,3 +1,8 @@
++2018-08-18  Mark Wielaard  
++
++  * dwarf_getaranges.c (dwarf_getaranges.c): Make sure there is enough
++  data to read the address and segment size.
++
+ 2018-06-28  Mark Wielaard  
+ 
+   * dwarf_next_cfi.c (dwarf_next_cfi): Check whether length is zero.
+diff --git a/libdw/dwarf_getaranges.c b/libdw/dwarf_getaranges.c
+index bff9c86..de5b81b 100644
+--- a/libdw/dwarf_getaranges.c
 b/libdw/dwarf_getaranges.c
+@@ -148,6 +148,10 @@ dwarf_getaranges (Dwarf *dbg, Dwarf_Aranges **aranges, 
size_t *naranges)
+  length_bytes, , IDX_debug_info, 4))
+   goto fail;
+ 
++  /* Next up two bytes for address and segment size.  */
++  if (readp + 2 > readendp)
++  goto invalid;
++
+   unsigned int address_size = *readp++;
+   if (unlikely (address_size != 4 && address_size != 8))
+   goto invalid;
+diff --git a/src/ChangeLog b/src/ChangeLog
+index 8c89f83..2f9f774 100644
+--- a/src/ChangeLog
 b/src/ChangeLog
+@@ -1,3 +1,8 @@
++2018-08-18  Mark Wielaard  
++
++  * readelf.c (print_debug_aranges_section): Make sure there is enough
++  data to read the header segment size.
++
+ 2018-06-25  Mark Wielaard  
+ 
+   * readelf.c (print_decoded_line_section): Use dwarf_next_lines
+diff --git a/src/readelf.c b/src/readelf.c
+index 7b5707f..7b488ac 100644
+--- a/src/readelf.c
 b/src/readelf.c
+@@ -5447,6 +5447,8 @@ print_debug_aranges_section (Dwfl_Module *dwflmod 
__attribute__ ((unused)),
+ goto next_table;
+   }
+ 
++  if (readp + 1 > readendp)
++  goto invalid_data;
+   unsigned int segment_size = *readp++;
+   printf (gettext (" Segment size:  %6" PRIu64 "\n\n"),
+ (uint64_t) segment_size);
+-- 
+2.9.3
-- 
2.17.1

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

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Andre McCurdy]

On Tue, Sep 4, 2018 at 7:16 PM, Hongxu Jia  wrote:
> On 2018年09月05日 09:59, Andre McCurdy wrote:
>>
>> On Tue, Sep 4, 2018 at 6:02 PM, Hongxu Jia 
>> wrote:
>>>
>>> On 2018年09月05日 03:14, Andre McCurdy wrote:

 Maybe I'm missing something, but what's the advantage of using SHELL
 to run this little wrapper script rather than hardcoding /bin/sh ?

 Task shell scripts created by bitbake use hardcoded /bin/sh (see
 bitbake/lib/bb/build.py -> shell_trap_code())
>>>
>>> Keep align with the devshell as the comments mentioned above
>>
>> Yeah, I've read the comments. I still don't really understand why.
>>
>>> The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
>>> initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
>>> than hardcoded `/bin/sh' as the shebang of wrapper script.
>>>
>>> On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
>>> we assign var-SHELL with `/bin/bash', the wrapper script is still
>>> dashism.
>>
>> What exactly is a dashism?
>
>
> In another word, it does not support bashism.
>
> Here is a case which `export -f' is bashism although
>
> devshell using bash, but /bin/sh -> dash
>
> [case]
>
> function foobar { echo foobar; };
>  export -f foobar
> bitbake -c devshell virtual/kernel
>
> [case]
>
>
> BTW, I've sent anther patch to fix it `[OE-core] [PATCH]
> devshell.bbclass/terminal.bbclass: add a shell check at devshell'

OK, but run.do_terminal.xxx is a trivial wrapper which (apart from
exporting environment variables) just contains something like:

  do_terminal() {
  exec pseudo /bin/bash
  }

  do_terminal

I'm not sure what the problem is running that with /bin/sh, regardless
of whether /bin/sh points to bash or dash?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 6/7] wic:bootimg-efi:try other place for efi

[Lu.Jiang]

在 2018年09月05日 08:33, Tom Rini 写道:

On Tue, Sep 04, 2018 at 10:33:43AM +0800, Lu.Jiang wrote:

在 2018年09月04日 10:26, Tom Rini 写道:

On Tue, Sep 04, 2018 at 10:15:44AM +0800, Lu.Jiang wrote:

在 2018年09月03日 10:01, Lu.Jiang 写道:

在 2018年08月31日 21:52, Tom Rini 写道:

On Fri, Aug 31, 2018 at 10:15:09AM +0800, Jiang Lu wrote:


When there is no useful efi in $kerneldir, try copy
all efi from EFI/BOOT into boot image.

Signed-off-by: Jiang Lu 
---
   .../wic/files/wic/plugins/source/bootimg-efi.py | 12 
   1 file changed, 12 insertions(+)

diff --git
a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
index 0eb86a0..d435268 100644
--- a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
+++ b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
@@ -231,6 +231,18 @@ class BootimgEFIPlugin(SourcePlugin):
   else:
   raise WicError("unrecognized bootimg-efi loader: %s"
%
  source_params['loader'])
+    os.listdir("%s/EFI/BOOT/" % hdddir)
+    found_efi = False
+    for x in os.listdir("%s/EFI/BOOT/" % hdddir) :
+    if x.endswith(".efi"):
+    found_efi = True
+    break;
+    if not found_efi:
+    cp_cmd = "cp %s/EFI/BOOT/*.efi %s/EFI/BOOT/" %
(kernel_dir, hdddir)
+    try:
+    exec_cmd(cp_cmd, True)
+    except:
+    pass
   except KeyError:
   raise WicError("bootimg-efi requires a loader, none
specified")

I'm not sure this is the right approach.  If you don't have things set
up for automagic finding you should use bootimg-partition and
IMAGE_BOOT_FILES.  I'm doing this right now for some EFI projects
because it's also bad form to dump everything into EFI/BOOT and some
things should end up in EFI/vendorname or similar.


Hi Tom,

By indicating IMAGE_BOOT_FILES for bootimg-partition, can perform copy file
work. While we still need the code in bootimg-efi to re-generate grub.cfg.

I prefer use bootimg-efi for this case, but we can add a new parameter to
distinguish kernel dir & bootloader dir(for efi files)

I'm still not seeing why we need this, sorry.

If we need files in the ESP in EFI/BOOT/ then in our root filesystem
they're already in as /boot/efi/EFI/BOOT and we say that we populate
things from /boot/efi and this also gets us things like
/boot/efi/EFI/vendor and so forth populated and matches other Linux
distributions.

If we need something more complex, we have IMAGE_BOOT_FILES available
and can and should be populating the deploy directory like other
architectures and loaders do.


bootimg-efi performed following for grub boot partition:

1.copy grub-efi-* from $KERNEL_DIR into $/boot/EFI/BOOT/

2.copy bzImage from $KERNEL_DIR into $/boot/

3.generate grub.cfg based select booting device.

On target system, if we select booting device from running system as source
for booting-efi will meet issue. Because the *.efi & bzImage is not in the
same directory.

As you suggested, we may invoke booting-partition by feeding
$IMAGE_BOOT_FILES to indicating file need copy, this could done work 1 & 2.
While we still need generated grub.cfg.

One of the great strengths of wic is that it can cover a lot of
different fairly complex use cases automatically, and still provide an
expert "out" for when you're doing something fairly different but still
want to leverage wic.  While I don't understand the use case of turning
a live system into a wic image, it sounds like what you're looking for
is the case of "and we provide our own loader config file".  You should
be including grub.cfg into the IMAGE_BOOT_FILES list and generate this
however you need it.  Since you've already booted you should already
have a correct EFI/ directory to look at (we ought to stop having
top-level bzImage, that's not right, but that's orthogonal to this
thread).


The grub.cfg is generated in bootimg-efi.py. At least, it need include 
the new generated uuid info for rootfs partition.
So we still need a piece of code from bootimg-efi.py to generate 
grub.cfg at runtime.


The issue this patch try to fix is bootimg-efi assume bzImage & 
grub-*.efi located at top level of $KERNEL_DIR.
This is true for bitbake's deploy dir. However, it didn't apply to 
target. We need provide a way for adding search path for *.efi.


I believe wic is a powerful tool not only working under oe environment, 
it can be a simply implement tool on target. So try to add  a few patch 
to make it working on target.


Thanks
Jiang Lu



All that said, I'm also not sure why, roughly, this doesn't work for the
use case:
IMAGE_BOOT_FILE = "\
   /boot/efi/EFI/BOOT/bootx64.efi;EFI/BOOT/bootx64.efi \
   ...
   /boot/bzImage;EFI/yocto/bzImage \
   "

And you may want to address that we don't package our default grub
binary, or have the script that's 

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Hongxu Jia]

On 2018年09月05日 09:59, Andre McCurdy wrote:

On Tue, Sep 4, 2018 at 6:02 PM, Hongxu Jia  wrote:

On 2018年09月05日 03:14, Andre McCurdy wrote:

Maybe I'm missing something, but what's the advantage of using SHELL
to run this little wrapper script rather than hardcoding /bin/sh ?

Task shell scripts created by bitbake use hardcoded /bin/sh (see
bitbake/lib/bb/build.py -> shell_trap_code())

Keep align with the devshell as the comments mentioned above

Yeah, I've read the comments. I still don't really understand why.


The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
than hardcoded `/bin/sh' as the shebang of wrapper script.

On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
we assign var-SHELL with `/bin/bash', the wrapper script is still
dashism.

What exactly is a dashism?


In another word, it does not support bashism.

Here is a case which `export -f' is bashism although

devshell using bash, but /bin/sh -> dash

[case]

function foobar { echo foobar; };
 export -f foobar
bitbake -c devshell virtual/kernel

[case]


BTW, I've sent anther patch to fix it `[OE-core] [PATCH] 
devshell.bbclass/terminal.bbclass: add a shell check at devshell'


//Hongxu


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

Re: [OE-core] [PATCH] os-release: fix to install in the expected location

[Andre McCurdy]

On Tue, Sep 4, 2018 at 3:36 PM, Richard Purdie
 wrote:
> On Tue, 2018-09-04 at 13:19 -0700, Andre McCurdy wrote:
>> On Tue, Sep 4, 2018 at 8:50 AM, Ross Burton 
>> wrote:
>> > From: Joshua Lock 
>> >
>> > os-release (5) recommends that the os-release file be installed in
>> > /usr/lib/os-release and that /etc/os-release be a relative symlink
>> > to it.
>> >
>> > Signed-off-by: Joshua Lock 
>> > Signed-off-by: Ross Burton 
>> > ---
>> >  meta/recipes-core/os-release/os-release.bb | 7 ---
>> >  1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/meta/recipes-core/os-release/os-release.bb
>> > b/meta/recipes-core/os-release/os-release.bb
>> > index f9887047561..c6e36001dc5 100644
>> > --- a/meta/recipes-core/os-release/os-release.bb
>> > +++ b/meta/recipes-core/os-release/os-release.bb
>> > @@ -1,7 +1,7 @@
>> >  inherit allarch
>> >
>> >  SUMMARY = "Operating system identification"
>> > -DESCRIPTION = "The /etc/os-release file contains operating system
>> > identification data."
>> > +DESCRIPTION = "The /usr/lib/os-release file contains operating
>> > system identification data."
>> >  LICENSE = "MIT"
>> >  INHIBIT_DEFAULT_DEPS = "1"
>> >
>> > @@ -42,6 +42,7 @@ python do_compile () {
>> >  do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
>> >
>> >  do_install () {
>> > -install -d ${D}${sysconfdir}
>> > -install -m 0644 os-release ${D}${sysconfdir}/
>> > +install -d ${D}${libdir}
>> > +install -m 0644 os-release ${D}${libdir}/
>> > +lnr ${D}${libdir}/os-release ${D}${sysconfdir}
>>
>> This probably needs an "rm -f ${D}${sysconfdir}/os-release" too to
>> prevent problems if install is run twice as lnr doesn't handle the
>> case where the target already exists.
>
> Doesn't do_install clean out ${D} each time it reruns though?

Yes, it does. Sometimes it's useful to rerun the run.do_install script
manually though.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Andre McCurdy]

On Tue, Sep 4, 2018 at 6:02 PM, Hongxu Jia  wrote:
> On 2018年09月05日 03:14, Andre McCurdy wrote:
>>
>> Maybe I'm missing something, but what's the advantage of using SHELL
>> to run this little wrapper script rather than hardcoding /bin/sh ?
>>
>> Task shell scripts created by bitbake use hardcoded /bin/sh (see
>> bitbake/lib/bb/build.py -> shell_trap_code())
>
> Keep align with the devshell as the comments mentioned above

Yeah, I've read the comments. I still don't really understand why.

> The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
> initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
> than hardcoded `/bin/sh' as the shebang of wrapper script.
>
> On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
> we assign var-SHELL with `/bin/bash', the wrapper script is still
> dashism.

What exactly is a dashism?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Khem Raj]

On Tue, Sep 4, 2018 at 3:58 PM  wrote:
>
> On Tue, 2018-09-04 at 13:43 -0700, Khem Raj wrote:
> > I pointed this earlier before merge as well
> > meta-openembedded has 40 odd recipes failing due to openssl 1.1
> > upgrade
>
> Sorry, I think I missed something somewhere as I thought the
> indications were the bigger problems like qt5 were working now :/.
>
> > http://errors.yoctoproject.org/Errors/Build/67457/?page=2=50
> >
> > so obvious fix was to keep them pinned to openssl10 and i created
> > couple of fixes
> > to start
> >
> > https://patchwork.openembedded.org/patch/154517/
> > https://patchwork.openembedded.org/patch/154516/
> >
> > and the effects are showing up where sysroot task now starts to fail
> > for dependent
> > recipes here
> >
> > http://errors.yoctoproject.org/Errors/Details/190427/
> > http://errors.yoctoproject.org/Errors/Details/190433/
> >
> > in meta-oe certain recipes can be upgraded and we can get openssl 1.1
> > support
> > but others like the two examples I cited above do not have openSSL
> > 1.1 port.
> > so I think we can not live without openSSL 1.0 and OpenSSL 2.0 being
> > able to
> > co-exist.
>
> The latter link is php 7.2 which should have openssl 1.1 support
> (https://bugs.php.net/bug.php?id=72360).
>
> For the former, libgdata doesn't have an openssl depends so I guessed
> at liboauth pulling it in which does have an openssl 1.1 patch at:
> https://github.com/x42/liboauth/issues/9
>

Thanks for pointers and they do help. However IMO the problem that
Martin decribed
is going to be a real blocker. Unless we can provide a solution to let
both openssl versions
coexist, this change is going to be problematic since we maintain
several old recipes which
would have to be fixed for openssl 1.1 and this can take time, right
now we are only seeing
meta-openembedded layers, we don't even know all other layers which
might get into similar
issues.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Hongxu Jia]

On 2018年09月05日 03:14, Andre McCurdy wrote:

Maybe I'm missing something, but what's the advantage of using SHELL
to run this little wrapper script rather than hardcoding /bin/sh ?

Task shell scripts created by bitbake use hardcoded /bin/sh (see
bitbake/lib/bb/build.py -> shell_trap_code())


Keep align with the devshell as the comments mentioned above

...

The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
than hardcoded `/bin/sh' as the shebang of wrapper script.

On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
we assign var-SHELL with `/bin/bash', the wrapper script is still
dashism.

...


//Hongxu

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

Re: [OE-core] [PATCH 6/7] wic:bootimg-efi:try other place for efi

[Tom Rini]

On Tue, Sep 04, 2018 at 10:33:43AM +0800, Lu.Jiang wrote:
> 在 2018年09月04日 10:26, Tom Rini 写道:
> >On Tue, Sep 04, 2018 at 10:15:44AM +0800, Lu.Jiang wrote:
> >>在 2018年09月03日 10:01, Lu.Jiang 写道:
> >>>在 2018年08月31日 21:52, Tom Rini 写道:
> On Fri, Aug 31, 2018 at 10:15:09AM +0800, Jiang Lu wrote:
> 
> >When there is no useful efi in $kerneldir, try copy
> >all efi from EFI/BOOT into boot image.
> >
> >Signed-off-by: Jiang Lu 
> >---
> >   .../wic/files/wic/plugins/source/bootimg-efi.py | 12 
> >   1 file changed, 12 insertions(+)
> >
> >diff --git
> >a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >index 0eb86a0..d435268 100644
> >--- a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >+++ b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >@@ -231,6 +231,18 @@ class BootimgEFIPlugin(SourcePlugin):
> >   else:
> >   raise WicError("unrecognized bootimg-efi loader: %s"
> >%
> >  source_params['loader'])
> >+    os.listdir("%s/EFI/BOOT/" % hdddir)
> >+    found_efi = False
> >+    for x in os.listdir("%s/EFI/BOOT/" % hdddir) :
> >+    if x.endswith(".efi"):
> >+    found_efi = True
> >+    break;
> >+    if not found_efi:
> >+    cp_cmd = "cp %s/EFI/BOOT/*.efi %s/EFI/BOOT/" %
> >(kernel_dir, hdddir)
> >+    try:
> >+    exec_cmd(cp_cmd, True)
> >+    except:
> >+    pass
> >   except KeyError:
> >   raise WicError("bootimg-efi requires a loader, none
> >specified")
> I'm not sure this is the right approach.  If you don't have things set
> up for automagic finding you should use bootimg-partition and
> IMAGE_BOOT_FILES.  I'm doing this right now for some EFI projects
> because it's also bad form to dump everything into EFI/BOOT and some
> things should end up in EFI/vendorname or similar.
> 
> >>Hi Tom,
> >>
> >>By indicating IMAGE_BOOT_FILES for bootimg-partition, can perform copy file
> >>work. While we still need the code in bootimg-efi to re-generate grub.cfg.
> >>
> >>I prefer use bootimg-efi for this case, but we can add a new parameter to
> >>distinguish kernel dir & bootloader dir(for efi files)
> >I'm still not seeing why we need this, sorry.
> >
> >If we need files in the ESP in EFI/BOOT/ then in our root filesystem
> >they're already in as /boot/efi/EFI/BOOT and we say that we populate
> >things from /boot/efi and this also gets us things like
> >/boot/efi/EFI/vendor and so forth populated and matches other Linux
> >distributions.
> >
> >If we need something more complex, we have IMAGE_BOOT_FILES available
> >and can and should be populating the deploy directory like other
> >architectures and loaders do.
> >
> bootimg-efi performed following for grub boot partition:
> 
> 1.copy grub-efi-* from $KERNEL_DIR into $/boot/EFI/BOOT/
> 
> 2.copy bzImage from $KERNEL_DIR into $/boot/
> 
> 3.generate grub.cfg based select booting device.
> 
> On target system, if we select booting device from running system as source
> for booting-efi will meet issue. Because the *.efi & bzImage is not in the
> same directory.
> 
> As you suggested, we may invoke booting-partition by feeding
> $IMAGE_BOOT_FILES to indicating file need copy, this could done work 1 & 2.
> While we still need generated grub.cfg.

One of the great strengths of wic is that it can cover a lot of
different fairly complex use cases automatically, and still provide an
expert "out" for when you're doing something fairly different but still
want to leverage wic.  While I don't understand the use case of turning
a live system into a wic image, it sounds like what you're looking for
is the case of "and we provide our own loader config file".  You should
be including grub.cfg into the IMAGE_BOOT_FILES list and generate this
however you need it.  Since you've already booted you should already
have a correct EFI/ directory to look at (we ought to stop having
top-level bzImage, that's not right, but that's orthogonal to this
thread).

All that said, I'm also not sure why, roughly, this doesn't work for the
use case:
IMAGE_BOOT_FILE = "\
  /boot/efi/EFI/BOOT/bootx64.efi;EFI/BOOT/bootx64.efi \
  ...
  /boot/bzImage;EFI/yocto/bzImage \
  "

And you may want to address that we don't package our default grub
binary, or have the script that's running wic make your grub.efi binary.
I kind of lean towards the former being something we should be doing and
aren't.  There's I think a lot of stuff that could be made more
consistent with other architectures and loaders but isn't currently.
That too is somewhat orthogonal to this series I'll admit.

Re: [OE-core] [PATCH] epiphany: upgrade 3.28.1.1 -> 3.28.3.1

[Yi Zhao]

Ping.  This release fixed CVE-2018-11396.


//Yi


在 2018年08月27日 13:55, Yi Zhao 写道:

Signed-off-by: Yi Zhao 
---
  .../epiphany/{epiphany_3.28.1.1.bb => epiphany_3.28.3.1.bb}   | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
  rename meta/recipes-gnome/epiphany/{epiphany_3.28.1.1.bb => 
epiphany_3.28.3.1.bb} (84%)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.28.1.1.bb 
b/meta/recipes-gnome/epiphany/epiphany_3.28.3.1.bb
similarity index 84%
rename from meta/recipes-gnome/epiphany/epiphany_3.28.1.1.bb
rename to meta/recipes-gnome/epiphany/epiphany_3.28.3.1.bb
index 65e7b45..8837b9c 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.28.1.1.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.28.3.1.bb
@@ -13,8 +13,8 @@ REQUIRED_DISTRO_FEATURES = "x11"
  SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive
 \
 file://0002-help-meson.build-disable-the-use-of-yelp.patch \
 "
-SRC_URI[archive.md5sum] = "9f4c0bf831789638818c23cd555b29d9"
-SRC_URI[archive.sha256sum] = 
"99426aa0e386742e924d84b59ec16bf394195fb9fce85d07f72d2cde486ea495"
+SRC_URI[archive.md5sum] = "31a4a443e8e22f085a10f80b7e41d5f3"
+SRC_URI[archive.sha256sum] = 
"690546a701f046c5c2b3a092659589ea6e17cb0f9a81ec3fdb3046b00cede6f7"
  
  EXTRA_OEMESON += " -Ddistributor_name=${DISTRO}"
  


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

Re: [OE-core] [PATCH] cmake: Update 3.11.4 -> 3.12.1

[Khem Raj]

Hi Otavio

Here is one failiure that is seen in meta-oe with updates cmake

http://errors.yoctoproject.org/Errors/Details/190510/


On Fri, Aug 31, 2018 at 1:54 PM Otavio Salvador
 wrote:
>
> On Fri, Aug 31, 2018 at 4:55 PM Khem Raj  wrote:
> > On Fri, Aug 31, 2018 at 11:14 AM Otavio Salvador
> >  wrote:
> > > On Fri, Aug 31, 2018 at 1:19 PM Khem Raj  wrote:
> > > > On Thu, Aug 30, 2018 at 4:26 PM Otavio Salvador 
> > > >  wrote:
> > > > > This updates CMake to the 3.12.1 stable release. All patches were
> > > > > rebase on top of the new source file and all them applied without
> > > > > changes.
> > > > >
> > > > > The number of patches has changed as all them were applied on the Git
> > > > > tree and re-exported, to avoid any fuzzy warnings.
> > > > >
> > > >
> > > > This is a major version update and cmake is quite deep in foundation of 
> > > > build
> > > > there are large packages outside OE-Core which depend on it. Can you 
> > > > give
> > > > some details on testing to make us feel comfortable ?
> > >
> > > I did basic testing but all patches applied fine. If desired, it can
> > > be postponed to next release as it is indeed not critical.
> >
> > build meta-qt5 with it there is lot of hairy stuff there
>
> bitbake qtscxml
>
> It went fine.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] os-release: fix to install in the expected location

[Khem Raj]

On Tue, Sep 4, 2018 at 8:50 AM Ross Burton  wrote:
>
> From: Joshua Lock 
>
> os-release (5) recommends that the os-release file be installed in
> /usr/lib/os-release and that /etc/os-release be a relative symlink to it.
>
> Signed-off-by: Joshua Lock 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/os-release/os-release.bb | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-core/os-release/os-release.bb 
> b/meta/recipes-core/os-release/os-release.bb
> index f9887047561..c6e36001dc5 100644
> --- a/meta/recipes-core/os-release/os-release.bb
> +++ b/meta/recipes-core/os-release/os-release.bb
> @@ -1,7 +1,7 @@
>  inherit allarch
>
>  SUMMARY = "Operating system identification"
> -DESCRIPTION = "The /etc/os-release file contains operating system 
> identification data."
> +DESCRIPTION = "The /usr/lib/os-release file contains operating system 
> identification data."
>  LICENSE = "MIT"
>  INHIBIT_DEFAULT_DEPS = "1"
>
> @@ -42,6 +42,7 @@ python do_compile () {
>  do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
>
>  do_install () {
> -install -d ${D}${sysconfdir}
> -install -m 0644 os-release ${D}${sysconfdir}/
> +install -d ${D}${libdir}
> +install -m 0644 os-release ${D}${libdir}/
> +lnr ${D}${libdir}/os-release ${D}${sysconfdir}
>  }

I am also seeing packaging failures

ERROR: os-release-1.0-r0 do_package: QA Issue: os-release:
Files/directories were installed but not shipped in any package:
  /usr
  /usr/lib
  /usr/lib/os-release
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[richard . purdie]

On Tue, 2018-09-04 at 13:43 -0700, Khem Raj wrote:
> I pointed this earlier before merge as well
> meta-openembedded has 40 odd recipes failing due to openssl 1.1
> upgrade

Sorry, I think I missed something somewhere as I thought the
indications were the bigger problems like qt5 were working now :/.

> http://errors.yoctoproject.org/Errors/Build/67457/?page=2=50
> 
> so obvious fix was to keep them pinned to openssl10 and i created
> couple of fixes
> to start
> 
> https://patchwork.openembedded.org/patch/154517/
> https://patchwork.openembedded.org/patch/154516/
> 
> and the effects are showing up where sysroot task now starts to fail
> for dependent
> recipes here
> 
> http://errors.yoctoproject.org/Errors/Details/190427/
> http://errors.yoctoproject.org/Errors/Details/190433/
> 
> in meta-oe certain recipes can be upgraded and we can get openssl 1.1
> support
> but others like the two examples I cited above do not have openSSL
> 1.1 port.
> so I think we can not live without openSSL 1.0 and OpenSSL 2.0 being
> able to
> co-exist.

The latter link is php 7.2 which should have openssl 1.1 support
(https://bugs.php.net/bug.php?id=72360).

For the former, libgdata doesn't have an openssl depends so I guessed
at liboauth pulling it in which does have an openssl 1.1 patch at: 
https://github.com/x42/liboauth/issues/9

Cheers,

Richard

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

Re: [OE-core] [PATCH] os-release: fix to install in the expected location

[Richard Purdie]

On Tue, 2018-09-04 at 13:19 -0700, Andre McCurdy wrote:
> On Tue, Sep 4, 2018 at 8:50 AM, Ross Burton 
> wrote:
> > From: Joshua Lock 
> > 
> > os-release (5) recommends that the os-release file be installed in
> > /usr/lib/os-release and that /etc/os-release be a relative symlink
> > to it.
> > 
> > Signed-off-by: Joshua Lock 
> > Signed-off-by: Ross Burton 
> > ---
> >  meta/recipes-core/os-release/os-release.bb | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/recipes-core/os-release/os-release.bb
> > b/meta/recipes-core/os-release/os-release.bb
> > index f9887047561..c6e36001dc5 100644
> > --- a/meta/recipes-core/os-release/os-release.bb
> > +++ b/meta/recipes-core/os-release/os-release.bb
> > @@ -1,7 +1,7 @@
> >  inherit allarch
> > 
> >  SUMMARY = "Operating system identification"
> > -DESCRIPTION = "The /etc/os-release file contains operating system
> > identification data."
> > +DESCRIPTION = "The /usr/lib/os-release file contains operating
> > system identification data."
> >  LICENSE = "MIT"
> >  INHIBIT_DEFAULT_DEPS = "1"
> > 
> > @@ -42,6 +42,7 @@ python do_compile () {
> >  do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
> > 
> >  do_install () {
> > -install -d ${D}${sysconfdir}
> > -install -m 0644 os-release ${D}${sysconfdir}/
> > +install -d ${D}${libdir}
> > +install -m 0644 os-release ${D}${libdir}/
> > +lnr ${D}${libdir}/os-release ${D}${sysconfdir}
> 
> This probably needs an "rm -f ${D}${sysconfdir}/os-release" too to
> prevent problems if install is run twice as lnr doesn't handle the
> case where the target already exists.

Doesn't do_install clean out ${D} each time it reruns though?

Cheers,

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

[OE-core] [PATCH V2 2/2] musl: Upgrade to 1.1.20

[Khem Raj]

All 1.1.20 Release Notes

https://git.musl-libc.org/cgit/musl/commit/?id=0fa1e638e87cf257e9f96b4019b2076afd674a19

ChangeLog for this change in OE

https://git.musl-libc.org/cgit/musl/log/?qt=range=767f7a1091af3a3dcee2f7a49d0713359a81961c..0fa1e638e87cf257e9f96b4019b2076afd674a19

Signed-off-by: Khem Raj 
---
Changes in v2: Upgrade to 1.1.20 tag

 meta/recipes-core/musl/musl_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index f4f156042a..de1cfd0058 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,9 +3,9 @@
 
 require musl.inc
 
-SRCREV = "767f7a1091af3a3dcee2f7a49d0713359a81961c"
+SRCREV = "0fa1e638e87cf257e9f96b4019b2076afd674a19"
 
-PV = "1.1.19+git${SRCPV}"
+PV = "1.1.20+git${SRCPV}"
 
 # mirror is at git://github.com/kraj/musl.git
 
-- 
2.18.0

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

Re: [OE-core] [PATCH] os-release: fix to install in the expected location

[Khem Raj]

On Tue, Sep 4, 2018 at 1:19 PM Andre McCurdy  wrote:
>
> On Tue, Sep 4, 2018 at 8:50 AM, Ross Burton  wrote:
> > From: Joshua Lock 
> >
> > os-release (5) recommends that the os-release file be installed in
> > /usr/lib/os-release and that /etc/os-release be a relative symlink to it.
> >
> > Signed-off-by: Joshua Lock 
> > Signed-off-by: Ross Burton 
> > ---
> >  meta/recipes-core/os-release/os-release.bb | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-core/os-release/os-release.bb 
> > b/meta/recipes-core/os-release/os-release.bb
> > index f9887047561..c6e36001dc5 100644
> > --- a/meta/recipes-core/os-release/os-release.bb
> > +++ b/meta/recipes-core/os-release/os-release.bb
> > @@ -1,7 +1,7 @@
> >  inherit allarch
> >
> >  SUMMARY = "Operating system identification"
> > -DESCRIPTION = "The /etc/os-release file contains operating system 
> > identification data."
> > +DESCRIPTION = "The /usr/lib/os-release file contains operating system 
> > identification data."
> >  LICENSE = "MIT"
> >  INHIBIT_DEFAULT_DEPS = "1"
> >
> > @@ -42,6 +42,7 @@ python do_compile () {
> >  do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
> >
> >  do_install () {
> > -install -d ${D}${sysconfdir}
> > -install -m 0644 os-release ${D}${sysconfdir}/
> > +install -d ${D}${libdir}
> > +install -m 0644 os-release ${D}${libdir}/

both install calls above could be squashed into install -D -m 0644 ...

> > +lnr ${D}${libdir}/os-release ${D}${sysconfdir}
>
> This probably needs an "rm -f ${D}${sysconfdir}/os-release" too to
> prevent problems if install is run twice as lnr doesn't handle the
> case where the target already exists.
>
> >  }
> > --
> > 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Khem Raj]

On Tue, Sep 4, 2018 at 1:35 PM Richard Purdie
 wrote:
>
> On Tue, 2018-09-04 at 21:12 +0200, Martin Jansa wrote:
> > On Tue, Aug 28, 2018 at 12:23 PM Alexander Kanavin  > l.com> wrote:
> > > From: Alexander Kanavin 
> > >
> > > I believe the time has come to do this: openssl 1.0 upstream
> > > support stops at the end
> > > of 2019, and we do not want a situation where a supported YP
> > > release contains an
> > > unsupported version of a critical security component.
> > >
> > > Openssl 1.0 can still be utilized by depending on 'openssl10'
> > > recipe.
> >
> > This still isn't true for most recipes, as long as there is something
> > depending on openssl in the dependency tree, it will
> > cause do_prepare_recipe_sysroot failures like last time
> >
> > ERROR: The file /usr/lib/libssl.so is installed by both openssl10 and
> > openssl, aborting
> > DEBUG: Python function extend_recipe_sysroot finished
> > DEBUG: Python function do_prepare_recipe_sysroot finished
> > ERROR: Function failed: extend_recipe_sysroot
> >
> > From 15 failures caused by openssl-1.1 detected in my builds, just
> > changing DEPENDS from openssl to openssl10 didn't help in any case.
>
> That isn't good news. Do you have an idea of which components are in
> the dependency chains and if any of them are common? It'd also be
> useful to understand which ones are breaking...
>

I pointed this earlier before merge as well
meta-openembedded has 40 odd recipes failing due to openssl 1.1 upgrade

http://errors.yoctoproject.org/Errors/Build/67457/?page=2=50

so obvious fix was to keep them pinned to openssl10 and i created
couple of fixes
to start

https://patchwork.openembedded.org/patch/154517/
https://patchwork.openembedded.org/patch/154516/

and the effects are showing up where sysroot task now starts to fail
for dependent
recipes here

http://errors.yoctoproject.org/Errors/Details/190427/
http://errors.yoctoproject.org/Errors/Details/190433/

in meta-oe certain recipes can be upgraded and we can get openssl 1.1 support
but others like the two examples I cited above do not have openSSL 1.1 port.
so I think we can not live without openSSL 1.0 and OpenSSL 2.0 being able to
co-exist.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 2/6] cryptodev-tests: port to openssl 1.1

[Andre McCurdy]

On Tue, Aug 28, 2018 at 3:23 AM, Alexander Kanavin
 wrote:
> From: Alexander Kanavin 
>
> This leaves openssh as the only recipe that requires openssl 1.0 (or 
> libressl).
>
> Signed-off-by: Alexander Kanavin 
> ---
>  .../cryptodev/cryptodev-tests_1.9.bb   |   3 +-
>  .../files/0001-Port-tests-to-openssl-1.1.patch | 103 
> +
>  2 files changed, 105 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
>
> diff --git a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb 
> b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
> index 9afb3de..617db6c 100644
> --- a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
> +++ b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
> @@ -2,10 +2,11 @@ require cryptodev.inc
>
>  SUMMARY = "A test suite for /dev/crypto device driver"
>
> -DEPENDS += "openssl10"
> +DEPENDS += "openssl"
>
>  SRC_URI += " \
>  file://0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch \
> +file://0001-Port-tests-to-openssl-1.1.patch \
>  "
>
>  EXTRA_OEMAKE='KERNEL_DIR="${STAGING_EXECPREFIXDIR}" PREFIX="${D}"'
> diff --git 
> a/meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch 
> b/meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
> new file mode 100644
> index 000..c969126
> --- /dev/null
> +++ b/meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
> @@ -0,0 +1,103 @@
> +From 2fe4bdeb8cdd0b0f46d9caed807812855d51ea56 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin 
> +Date: Wed, 28 Mar 2018 20:11:05 +0300
> +Subject: [PATCH] Port tests to openssl 1.1
> +
> +Upstream-Status: Accepted 
> [https://github.com/cryptodev-linux/cryptodev-linux/pull/36]
> +Signed-off-by: Alexander Kanavin 
> +
> +---
> + tests/openssl_wrapper.c | 33 +
> + 1 file changed, 33 insertions(+)
> +
> +diff --git a/tests/openssl_wrapper.c b/tests/openssl_wrapper.c
> +index 038c58f..dea2496 100644
> +--- a/tests/openssl_wrapper.c
>  b/tests/openssl_wrapper.c
> +@@ -4,6 +4,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> +
> + //#define DEBUG
> +
> +@@ -23,10 +24,17 @@ enum ctx_type {
> +   ctx_type_md,
> + };
> +
> ++#if OPENSSL_VERSION_NUMBER >= 0x1010L
> ++union openssl_ctx {
> ++  HMAC_CTX *hmac;
> ++  EVP_MD_CTX *md;
> ++};
> ++#else
> + union openssl_ctx {
> +   HMAC_CTX hmac;
> +   EVP_MD_CTX md;
> + };
> ++#endif
> +
> + struct ctx_mapping {
> +   __u32 ses;
> +@@ -63,6 +71,16 @@ static void remove_mapping(__u32 ses)
> +   switch (mapping->type) {
> +   case ctx_type_none:
> +   break;
> ++#if OPENSSL_VERSION_NUMBER >= 0x1010L
> ++  case ctx_type_hmac:
> ++  dbgp("%s: calling HMAC_CTX_free\n", __func__);
> ++  HMAC_CTX_free(mapping->ctx.hmac);
> ++  break;
> ++  case ctx_type_md:
> ++  dbgp("%s: calling EVP_MD_CTX_free\n", __func__);
> ++  EVP_MD_CTX_free(mapping->ctx.md);
> ++  break;
> ++#else
> +   case ctx_type_hmac:
> +   dbgp("%s: calling HMAC_CTX_cleanup\n", __func__);
> +   HMAC_CTX_cleanup(>ctx.hmac);
> +@@ -71,6 +89,7 @@ static void remove_mapping(__u32 ses)
> +   dbgp("%s: calling EVP_MD_CTX_cleanup\n", __func__);
> +   EVP_MD_CTX_cleanup(>ctx.md);
> +   break;
> ++#endif
> +   }
> +   memset(mapping, 0, sizeof(*mapping));
> + }
> +@@ -127,10 +146,17 @@ static int openssl_hmac(struct session_op *sess, 
> struct crypt_op *cop)
> +
> +   mapping->ses = sess->ses;
> +   mapping->type = ctx_type_hmac;
> ++#if OPENSSL_VERSION_NUMBER >= 0x1010L
> ++  ctx = mapping->ctx.hmac;

Assigning the (uninitialised?) value of mapping->ctx.hmac to ctx here
looks redundant?

> ++
> ++  dbgp("calling HMAC_CTX_new");
> ++  ctx = HMAC_CTX_new();
> ++#else
> +   ctx = >ctx.hmac;
> +
> +   dbgp("calling HMAC_CTX_init");
> +   HMAC_CTX_init(ctx);
> ++#endif
> +   dbgp("calling HMAC_Init_ex");
> +   if (!HMAC_Init_ex(ctx, sess->mackey, sess->mackeylen,
> +   sess_to_evp_md(sess), NULL)) {
> +@@ -172,10 +198,17 @@ static int openssl_md(struct session_op *sess, struct 
> crypt_op *cop)
> +
> +   mapping->ses = sess->ses;
> +   mapping->type = ctx_type_md;
> ++#if OPENSSL_VERSION_NUMBER >= 0x1010L
> ++  ctx = mapping->ctx.md;

And same comment here.

> ++
> ++  dbgp("calling EVP_MD_CTX_new");
> ++  ctx = EVP_MD_CTX_new();
> ++#else
> +   ctx = >ctx.md;
> +
> +   dbgp("calling EVP_MD_CTX_init");
> +   EVP_MD_CTX_init(ctx);
> ++#endif
> +   dbgp("calling EVP_DigestInit");
> +   EVP_DigestInit(ctx, 

Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Richard Purdie]

On Tue, 2018-09-04 at 21:12 +0200, Martin Jansa wrote:
> On Tue, Aug 28, 2018 at 12:23 PM Alexander Kanavin  l.com> wrote:
> > From: Alexander Kanavin 
> > 
> > I believe the time has come to do this: openssl 1.0 upstream
> > support stops at the end
> > of 2019, and we do not want a situation where a supported YP
> > release contains an
> > unsupported version of a critical security component.
> > 
> > Openssl 1.0 can still be utilized by depending on 'openssl10'
> > recipe.
> 
> This still isn't true for most recipes, as long as there is something
> depending on openssl in the dependency tree, it will
> cause do_prepare_recipe_sysroot failures like last time
> 
> ERROR: The file /usr/lib/libssl.so is installed by both openssl10 and
> openssl, aborting
> DEBUG: Python function extend_recipe_sysroot finished
> DEBUG: Python function do_prepare_recipe_sysroot finished
> ERROR: Function failed: extend_recipe_sysroot
> 
> From 15 failures caused by openssl-1.1 detected in my builds, just
> changing DEPENDS from openssl to openssl10 didn't help in any case.

That isn't good news. Do you have an idea of which components are in
the dependency chains and if any of them are common? It'd also be
useful to understand which ones are breaking...

Cheers,

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

Re: [OE-core] [PATCH] os-release: fix to install in the expected location

[Andre McCurdy]

On Tue, Sep 4, 2018 at 8:50 AM, Ross Burton  wrote:
> From: Joshua Lock 
>
> os-release (5) recommends that the os-release file be installed in
> /usr/lib/os-release and that /etc/os-release be a relative symlink to it.
>
> Signed-off-by: Joshua Lock 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/os-release/os-release.bb | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-core/os-release/os-release.bb 
> b/meta/recipes-core/os-release/os-release.bb
> index f9887047561..c6e36001dc5 100644
> --- a/meta/recipes-core/os-release/os-release.bb
> +++ b/meta/recipes-core/os-release/os-release.bb
> @@ -1,7 +1,7 @@
>  inherit allarch
>
>  SUMMARY = "Operating system identification"
> -DESCRIPTION = "The /etc/os-release file contains operating system 
> identification data."
> +DESCRIPTION = "The /usr/lib/os-release file contains operating system 
> identification data."
>  LICENSE = "MIT"
>  INHIBIT_DEFAULT_DEPS = "1"
>
> @@ -42,6 +42,7 @@ python do_compile () {
>  do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
>
>  do_install () {
> -install -d ${D}${sysconfdir}
> -install -m 0644 os-release ${D}${sysconfdir}/
> +install -d ${D}${libdir}
> +install -m 0644 os-release ${D}${libdir}/
> +lnr ${D}${libdir}/os-release ${D}${sysconfdir}

This probably needs an "rm -f ${D}${sysconfdir}/os-release" too to
prevent problems if install is run twice as lnr doesn't handle the
case where the target already exists.

>  }
> --
> 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

Re: [OE-core] [PATCH 2/2] musl: Update latest on master

[Khem Raj]

On Tue, Sep 4, 2018 at 12:44 PM Andre McCurdy  wrote:
>
> On Tue, Sep 4, 2018 at 12:00 PM, Khem Raj  wrote:
> > hopefully last bump before 1.1.20 is released
>
> 1.1.20 has been released.
>

indeed right in time, I will update the commit message. its actually
same commit with a release commit on top.

> > ChangeLog
> >
> > https://git.musl-libc.org/cgit/musl/log/?qt=range=767f7a1091af3a3dcee2f7a49d0713359a81961c..64466094ede4162ddd4049cea5da09feb9abfaa6
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-core/musl/musl_git.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/musl/musl_git.bb 
> > b/meta/recipes-core/musl/musl_git.bb
> > index f4f156042a..997eb14959 100644
> > --- a/meta/recipes-core/musl/musl_git.bb
> > +++ b/meta/recipes-core/musl/musl_git.bb
> > @@ -3,7 +3,7 @@
> >
> >  require musl.inc
> >
> > -SRCREV = "767f7a1091af3a3dcee2f7a49d0713359a81961c"
> > +SRCREV = "64466094ede4162ddd4049cea5da09feb9abfaa6"
> >
> >  PV = "1.1.19+git${SRCPV}"
> >
> > --
> > 2.18.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 2/2] musl: Update latest on master

[Andre McCurdy]

On Tue, Sep 4, 2018 at 12:00 PM, Khem Raj  wrote:
> hopefully last bump before 1.1.20 is released

1.1.20 has been released.

> ChangeLog
>
> https://git.musl-libc.org/cgit/musl/log/?qt=range=767f7a1091af3a3dcee2f7a49d0713359a81961c..64466094ede4162ddd4049cea5da09feb9abfaa6
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/musl/musl_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/musl/musl_git.bb 
> b/meta/recipes-core/musl/musl_git.bb
> index f4f156042a..997eb14959 100644
> --- a/meta/recipes-core/musl/musl_git.bb
> +++ b/meta/recipes-core/musl/musl_git.bb
> @@ -3,7 +3,7 @@
>
>  require musl.inc
>
> -SRCREV = "767f7a1091af3a3dcee2f7a49d0713359a81961c"
> +SRCREV = "64466094ede4162ddd4049cea5da09feb9abfaa6"
>
>  PV = "1.1.19+git${SRCPV}"
>
> --
> 2.18.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] busybox: update to 1.29.2

[Randy MacLeod]

We really want to get this change merged this week so
that it's part of the 2.6-M3 content that will be well tested.

On 08/31/2018 03:42 AM, Andrej Valek wrote:

I had some network problems.

This patch could be ignored, because, it's same as
http://lists.openembedded.org/pipermail/openembedded-core/2018-August/155059.html



That patch dropped the:

   Openpgp: preference=signencrypt
   Autocrypt: addr=andrej.va...@siemens.com; prefer-encrypt=mutual;
   keydata=
xsBNBFkSzTcBCADSJTRk7Y...bIFUmc7ck3KeuUGKy
ifrpWD6/7YPXbixv4sAlFl...zmMdr0BPLMsL96nBO
...

but it's still base64 encoded:
   Content-Type: text/plain; charset="utf-8"
   Content-Transfer-Encoding: base64

whereas other patches to the list use:
   Content-Type: text/plain; charset="us-ascii"
   Content-Transfer-Encoding: 7bit


Can you fix that and/or send a pull request:

http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Committing_your_patch


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

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Andre McCurdy]

On Tue, Sep 4, 2018 at 9:36 AM, Alejandro Enedino Hernandez Samaniego
 wrote:
> Hey Hongxu,
>
>
>
> On 09/02/2018 10:52 PM, Hongxu Jia wrote:
>>
>> On 2018年09月01日 08:14, Alejandro Enedino Hernandez Samaniego wrote:
>>>
>>> Hey Hongxu,
>>>
>>>
>>> On 08/24/2018 01:54 AM, Hongxu Jia wrote:

 The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
 initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
 than hardcoded `/bin/sh' as the shebang of wrapper script.

 On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
 we assign var-SHELL with `/bin/bash', the wrapper script is still
 dashism.

 Signed-off-by: Hongxu Jia 
 ---
   meta/classes/terminal.bbclass | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/meta/classes/terminal.bbclass
 b/meta/classes/terminal.bbclass
 index a27e10c..73e765d 100644
 --- a/meta/classes/terminal.bbclass
 +++ b/meta/classes/terminal.bbclass
 @@ -25,7 +25,8 @@ def emit_terminal_func(command, envdata, d):
   bb.utils.mkdirhier(os.path.dirname(runfile))
 with open(runfile, 'w') as script:
 -script.write('#!/bin/sh -e\n')
 +script.write('#!/usr/bin/env %s\n' % d.getVar('SHELL'))
 +script.write('set -e\n')
>>>
>>> This is causing a bug on several systems, I believe that it is because
>>> the way our systems are set up,
>>> basically, our running shell isn't necessarily $SHELL, so it is causing
>>> the process to exit immediately,
>>> anything thats using this class is affected, devshell, menuconfig, etc.
>>>
>>>
>>> $ echo $SHELL
>>> /bin/csh
>>>
>>> $ echo $0
>>> /bin/bash
>>>
>>
>> The csh does not support `export', in you case, you should correct
>> var-SHELL to align with $0,
>>
>> Such as:
>> $ usermod  -s $0
>
>
> I absolutely agree, but as I was saying, because the way the system is set
> up, it does not allow me to do so.

Maybe I'm missing something, but what's the advantage of using SHELL
to run this little wrapper script rather than hardcoding /bin/sh ?

Task shell scripts created by bitbake use hardcoded /bin/sh (see
bitbake/lib/bb/build.py -> shell_trap_code())
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Martin Jansa]

On Tue, Aug 28, 2018 at 12:23 PM Alexander Kanavin 
wrote:

> From: Alexander Kanavin 
>
> I believe the time has come to do this: openssl 1.0 upstream support stops
> at the end
> of 2019, and we do not want a situation where a supported YP release
> contains an
> unsupported version of a critical security component.
>
> Openssl 1.0 can still be utilized by depending on 'openssl10' recipe.
>

This still isn't true for most recipes, as long as there is something
depending on openssl in the dependency tree, it will
cause do_prepare_recipe_sysroot failures like last time

ERROR: The file /usr/lib/libssl.so is installed by both openssl10 and
openssl, aborting
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Python function do_prepare_recipe_sysroot finished
ERROR: Function failed: extend_recipe_sysroot

>From 15 failures caused by openssl-1.1 detected in my builds, just changing
DEPENDS from openssl to openssl10 didn't help in any case.

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

[OE-core] [PATCH 2/2] musl: Update latest on master

[Khem Raj]

hopefully last bump before 1.1.20 is released

ChangeLog

https://git.musl-libc.org/cgit/musl/log/?qt=range=767f7a1091af3a3dcee2f7a49d0713359a81961c..64466094ede4162ddd4049cea5da09feb9abfaa6

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index f4f156042a..997eb14959 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,7 +3,7 @@
 
 require musl.inc
 
-SRCREV = "767f7a1091af3a3dcee2f7a49d0713359a81961c"
+SRCREV = "64466094ede4162ddd4049cea5da09feb9abfaa6"
 
 PV = "1.1.19+git${SRCPV}"
 
-- 
2.18.0

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

[OE-core] [PATCH 1/2] openssl_1.1.1: Fix Musl build by disabling async during configure

[Khem Raj]

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

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb
index 7122cfcf02..c13731feac 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb
@@ -31,7 +31,7 @@ inherit lib_package multilib_header ptest
 #| ./libcrypto.so: undefined reference to `getcontext'
 #| ./libcrypto.so: undefined reference to `setcontext'
 #| ./libcrypto.so: undefined reference to `makecontext'
-CPPFLAGS_append_libc-musl = " -DOPENSSL_NO_ASYNC"
+EXTRA_OECONF_append_libc-musl = " no-async"
 
 # This prevents openssl from using getrandom() which is not available on older 
glibc versions
 # (native versions can be built with newer glibc, but then relocated onto a 
system with older glibc)
-- 
2.18.0

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

Re: [OE-core] [PATCH] terminal.bbclass: use var-SHELL as the shebang of wrapper script

[Alejandro Enedino Hernandez Samaniego]

Hey Hongxu,


On 09/02/2018 10:52 PM, Hongxu Jia wrote:

On 2018年09月01日 08:14, Alejandro Enedino Hernandez Samaniego wrote:

Hey Hongxu,


On 08/24/2018 01:54 AM, Hongxu Jia wrote:
The devshell.bbclass set var-SHELL to var-DEVSHELL, and 
terminal.bbclass

initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
than hardcoded `/bin/sh' as the shebang of wrapper script.

On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
we assign var-SHELL with `/bin/bash', the wrapper script is still 
dashism.


Signed-off-by: Hongxu Jia 
---
  meta/classes/terminal.bbclass | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/terminal.bbclass 
b/meta/classes/terminal.bbclass

index a27e10c..73e765d 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -25,7 +25,8 @@ def emit_terminal_func(command, envdata, d):
  bb.utils.mkdirhier(os.path.dirname(runfile))
with open(runfile, 'w') as script:
-script.write('#!/bin/sh -e\n')
+script.write('#!/usr/bin/env %s\n' % d.getVar('SHELL'))
+script.write('set -e\n')
This is causing a bug on several systems, I believe that it is 
because the way our systems are set up,
basically, our running shell isn't necessarily $SHELL, so it is 
causing the process to exit immediately,

anything thats using this class is affected, devshell, menuconfig, etc.


$ echo $SHELL
/bin/csh

$ echo $0
/bin/bash



The csh does not support `export', in you case, you should correct 
var-SHELL to align with $0,


Such as:
$ usermod  -s $0


I absolutely agree, but as I was saying, because the way the system is 
set up, it does not allow me to do so.


Thanks!

Alejandro




But the script should be more robust, it should
work well in this situation. I will try to fix it.

//Hongxu




Sadly we are unable to set $SHELL correctly.

I wonder if there is another way of doing this that wouldn't cause 
this behavior.


Cheers,

Alejandro



  bb.data.emit_func(cmd_func, script, envdata)
  script.write(cmd_func)
  script.write("\n")






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

[OE-core] [PATCH] os-release: fix to install in the expected location

[Ross Burton]

From: Joshua Lock 

os-release (5) recommends that the os-release file be installed in
/usr/lib/os-release and that /etc/os-release be a relative symlink to it.

Signed-off-by: Joshua Lock 
Signed-off-by: Ross Burton 
---
 meta/recipes-core/os-release/os-release.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/os-release/os-release.bb 
b/meta/recipes-core/os-release/os-release.bb
index f9887047561..c6e36001dc5 100644
--- a/meta/recipes-core/os-release/os-release.bb
+++ b/meta/recipes-core/os-release/os-release.bb
@@ -1,7 +1,7 @@
 inherit allarch
 
 SUMMARY = "Operating system identification"
-DESCRIPTION = "The /etc/os-release file contains operating system 
identification data."
+DESCRIPTION = "The /usr/lib/os-release file contains operating system 
identification data."
 LICENSE = "MIT"
 INHIBIT_DEFAULT_DEPS = "1"
 
@@ -42,6 +42,7 @@ python do_compile () {
 do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
 
 do_install () {
-install -d ${D}${sysconfdir}
-install -m 0644 os-release ${D}${sysconfdir}/
+install -d ${D}${libdir}
+install -m 0644 os-release ${D}${libdir}/
+lnr ${D}${libdir}/os-release ${D}${sysconfdir}
 }
-- 
2.11.0

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

[OE-core] [PATCH] wpa-supplicant: fix CVE-2018-14526

[Andrej Valek]

Ignore unauthenticated encrypted EAPOL-Key data in supplicant
processing. When using WPA2, these are frames that have the Encrypted
flag set, but not the MIC flag.

Signed-off-by: Andrej Valek 
---
 .../wpa_supplicant-CVE-2018-14526.patch| 44 ++
 .../wpa-supplicant/wpa-supplicant_2.6.bb   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant-CVE-2018-14526.patch

diff --git 
a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant-CVE-2018-14526.patch
 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant-CVE-2018-14526.patch
new file mode 100644
index 00..e800a410ea
--- /dev/null
+++ 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/wpa_supplicant-CVE-2018-14526.patch
@@ -0,0 +1,44 @@
+wpa_supplicant-2.6: Fix CVE-2018-14526
+
+[No upstream tracking] -- 
https://w1.fi/security/2018-1/unauthenticated-eapol-key-decryption.txt
+
+wpa: Ignore unauthenticated encrypted EAPOL-Key data
+
+Ignore unauthenticated encrypted EAPOL-Key data in supplicant
+processing. When using WPA2, these are frames that have the Encrypted
+flag set, but not the MIC flag.
+
+When using WPA2, EAPOL-Key frames that had the Encrypted flag set but
+not the MIC flag, had their data field decrypted without first verifying
+the MIC. In case the data field was encrypted using RC4 (i.e., when
+negotiating TKIP as the pairwise cipher), this meant that
+unauthenticated but decrypted data would then be processed. An adversary
+could abuse this as a decryption oracle to recover sensitive information
+in the data field of EAPOL-Key messages (e.g., the group key).
+
+Upstream-Status: Backport 
[https://w1.fi/cgit/hostap/commit/src/rsn_supp/wpa.c?id=3e34cfdff6b192fe337c6fb3f487f73e96582961]
+CVE: CVE-2018-14526
+Signed-off-by: Andrej Valek 
+
+diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c
+index 3c47879..6bdf923 100644
+--- a/src/rsn_supp/wpa.c
 b/src/rsn_supp/wpa.c
+@@ -2016,6 +2016,17 @@ int wpa_sm_rx_eapol(struct wpa_sm *sm, const u8 
*src_addr,
+
+   if ((sm->proto == WPA_PROTO_RSN || sm->proto == WPA_PROTO_OSEN) &&
+   (key_info & WPA_KEY_INFO_ENCR_KEY_DATA)) {
++  /*
++   * Only decrypt the Key Data field if the frame's authenticity
++   * was verified. When using AES-SIV (FILS), the MIC flag is not
++   * set, so this check should only be performed if mic_len != 0
++   * which is the case in this code branch.
++   */
++  if (!(key_info & WPA_KEY_INFO_MIC)) {
++  wpa_msg(sm->ctx->msg_ctx, MSG_WARNING,
++  "WPA: Ignore EAPOL-Key with encrypted but 
unauthenticated data");
++  goto out;
++  }
+   if (wpa_supplicant_decrypt_key_data(sm, key, ver, key_data,
+   _data_len))
+   goto out;
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
index e684537486..aa4c4c2da0 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
@@ -32,6 +32,7 @@ SRC_URI = "http://w1.fi/releases/wpa_supplicant-${PV}.tar.gz  
\
file://key-replay-cve-multiple6.patch \
file://key-replay-cve-multiple7.patch \
file://key-replay-cve-multiple8.patch \
+   file://wpa_supplicant-CVE-2018-14526.patch \
   "
 SRC_URI[md5sum] = "091569eb4440b7d7f2b4276dbfc03c3c"
 SRC_URI[sha256sum] = 
"b4936d34c4e6cdd44954beba74296d964bc2c9668ecaa5255e499636fe2b1450"
-- 
2.11.0

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

[OE-core] Yocto Project Status WW36’18

[Jolley, Stephen K]

Current Dev Position: YP 2.6 M3. - This is feature freeze for YP 2.6!

Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018


SWAT Team Rotation:

· SWAT lead is currently: Ross

· SWAT team rotation: Ross -> Amanda on Sept. 7, 2018

· SWAT team rotation: Amanda -> Tracy on Sept. 14, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· We’re now into M3 feature freeze so new feature patches, particularly 
for unplanned changes will be much less likely to be merged until 2.7 now.

· M3 has not been built yet. There are some significant changes which 
did merge:

oRemaining 4.18 kernel pieces

oOpenssl 1.1.1 for everything except openssh

· There are some patches which should really get merged before we build 
M3:

oMultilib allarch changes need another respin after review feedback

oBusybox recipe upgrade (current one is a comparatively old version)

· There are some issues of concern which may also need addressing for 
M3:

oBitbake error output is looking fragile around server startup and the 
recent fixes that merged have only highlighted more issues todo with output 
being lost in unflushed buffers.

oWe’ve now found multiple issues where autotools tests are falling back to 
incorrect defaults due to cross compilation and being unable to execute code. 
We now have patches to warn when this happens (thanks Ross) but the number of 
warnings is concerning.

oThe new autobuilder code is now able to track and flag builds which issue 
warnings as well as errors. This has uncovered a number of issues which also 
may need investigation.

oThe python3 pgo optimisations are proving extremely slow to build. There 
are some tweaks we can make to speed this up and this is being actively worked 
on.

· Given the number of issues above we will hold off building M3 until 
at least the majority of these are resolved, some warning fixing may also 
happen in M4.

· The sstate hash equivalency code is still pending review and 
resolution of the filehandle upon fork issues.

· We plan to build M3 on the new autobuilder codebase and 
infrastructure (based upon buildbot ‘nine’) and decommission the older buildbot 
‘eight’ codebase ASAP.


Planned Releases for YP 2.6:

· YP 2.6 M3 Build Target is Aug. 27, 2018

· YP 2.6 M3 Release Target is Sept. 7, 2018

· YP 2.6 M4 Build Target is Oct. 1, 2018

· YP 2.6 M4 Release Target is Oct. 26, 2018


Planned upcoming dot releases:

· YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.

· YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.


Tracking Metrics:

· WDD 2582 (last week 2610) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1643 (last week 1636)

oPercentage of patches in the Pending State: 736 (45%) [last week 737 (45%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


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

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

[OE-core] [PATCH] openssl: rename PV to 1.1.1~pre9 to avoid future versions from going backwards

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb
index 7fcb9c2..7122cfc 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1-pre9.bb
@@ -10,7 +10,11 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
 
 DEPENDS = "hostperl-runtime-native"
 
-SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
+# This short sort lower than 1.1.1 final, to avoid package version going 
downwards issue
+PV = "1.1.1~pre9"
+S = "${WORKDIR}/openssl-1.1.1-pre9"
+
+SRC_URI = "http://www.openssl.org/source/openssl-1.1.1-pre9.tar.gz \
file://run-ptest \
file://openssl-c_rehash.sh \
"
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/2] webkitgtk: add opengl to REQUIRED_DISTRO_FEATURES

[Alexander Kanavin]

2018-09-04 15:29 GMT+02:00 Hongxu Jia :
>>> They can't be built without opengl in DISTRO_FEATURES.
>>> [snip]

> I am afraid whether opengl or not, it always requires virtual/libql
> just like Ubuntu/Fedora does.
>
> [Fedora webkitgtk.spec]
> BuildRequires:  mesa-libGL-devel
> [Fedora webkitgtk.spec]
>
> [Ubuntu debian/control]
> Build-Depends: libgl1-mesa-dev [!armel !armhf !arm64]
> [Ubuntu debian/control]

Fedora and Ubuntu have elected to enable opengl in their distros, that
does not in itself mean it cannot be disabled. So please disable it,
and inspect the source code for reasons it breaks the build. That
header file you cited  in particular is guarded by ENABLE_OPENGL
conditional, which should be false when opengl is switched off.


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

Re: [OE-core] [PATCH 1/2] webkitgtk: add opengl to REQUIRED_DISTRO_FEATURES

[Hongxu Jia]

On 2018年09月03日 17:54, Alexander Kanavin wrote:

2018-09-03 11:35 GMT+02:00 Hongxu Jia :

They can't be built without opengl in DISTRO_FEATURES.
[snip]
|webkitgtk-2.20.3/Source/WebCore/platform/graphics/OpenGLShims.h:23:10:
fatal error: GL/gl.h: No such file or directory
[snip]

Apologies, but NAK.

Webkit recipe already has the necessary configuration to handle this:

PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'x11', 'wayland' ,d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'webgl opengl', '' ,d)} \

PACKAGECONFIG[webgl] = "-DENABLE_WEBGL=ON,-DENABLE_WEBGL=OFF,virtual/libgl"
PACKAGECONFIG[opengl] = "-DENABLE_OPENGL=ON,-DENABLE_OPENGL=OFF,virtual/libgl"


If disabling opengl does not work, then you should look closer into
why, instead of just requiring opengl to be present always.

I am afraid whether opengl or not, it always requires virtual/libql
just like Ubuntu/Fedora does.

[Fedora webkitgtk.spec]
BuildRequires:  mesa-libGL-devel
[Fedora webkitgtk.spec]

[Ubuntu debian/control]
Build-Depends: libgl1-mesa-dev [!armel !armhf !arm64]
[Ubuntu debian/control]

I tried to move `virtual/libgl' from PACKAGECONFIG to DEPENDS,
but unfortunately, the provider of `virtual/libgl' -- mesa/mesa-ql,
they require `opengl 'or `vulkan' in distro features check.

//Hongxu


Alex



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

Re: [OE-core] [PATCH 1/1] bitbake.conf: Make BUILD_OPTIMIZATION respect to DEBUG_BUILD

[Richard Purdie]

On Tue, 2018-09-04 at 08:15 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> >  > core-boun...@lists.openembedded.org> On Behalf Of Robert Yang
> > Sent: den 4 september 2018 08:37
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 1/1] bitbake.conf: Make
> > BUILD_OPTIMIZATION
> > respect to DEBUG_BUILD
> > 
> > We may also need debug native tools, so make BUILD_OPTIMIZATION
> > respect to
> > DEBUG_BUILD, otherwise, we need set CFLAGS in the recipe which
> > isn't
> > convenient.
> > 
> > Signed-off-by: Robert Yang 
> > ---
> >  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 1941633..df62445 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -612,7 +612,7 @@ FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
> >  DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS}
> > -pipe"
> >  SELECTED_OPTIMIZATION = "${@d.getVar(['FULL_OPTIMIZATION',
> > 'DEBUG_OPTIMIZATION'][d.getVar('DEBUG_BUILD') == '1'])}"
> >  SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION
> > DEBUG_OPTIMIZATION"
> > -BUILD_OPTIMIZATION = "-O2 -pipe"
> > +BUILD_OPTIMIZATION = "${@['-O2', '-O -g -feliminate-unused-debug-
> > types -fno-omit-frame-pointer'][d.getVar('DEBUG_BUILD') == '1']}
> > -pipe"
> 
> Can we make that more readable:
> 
> BUILD_OPTIMIZATION = "${@'-O -g -feliminate-unused-debug-types -fno-
> omit-frame-pointer' if d.getVar('DEBUG_BUILD') == '1' else '-O2'}
> -pipe"
> 
> Should probably do the same for SELECTED_OPTIMIZATION while at it:
> 
> SELECTED_OPTIMIZATION = "${@d.getVar('DEBUG_OPTIMIZATION' if
> d.getVar('DEBUG_BUILD') == '1' else 'FULL_OPTIMIZATION')}"

If we're going to deal with readability and usability we could add
something like:

def vartrue(var, iftrue, iffalse, d):
if oe.types.boolean(d.getVar(var)):
return iftrue
else:
return iffalse

to lib/oe/utils and then:

BUILD_OPTIMIZATION = "${@oe.utils.vartrue('DEBUG_BUILD', '-O -g 
-feliminate-unused-debug-types -fno-omit-frame-pointer', '-O2', d)}"

Cheers,

Richard

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

Re: [OE-core] [meta-oe][PATCH v2 4/4] testimage: Moved write_image_test_data to testimage bbclass.

[Richard Purdie]

On Thu, 2018-08-30 at 19:49 +0200, Paulo Neves wrote:
> Previously the write_image_test_data was a rootfs post
> process command. This function ran only when the rootfs
> task was ran. Due to this if a variable was changed
> or added to the datastore that would not trigger the do_rootfs
> task, the variable would never be written into the json
> file. Consequently the do_testimage task was potentially
> unreproduceable and could fail if for some reason this
> variable was then used.
> 
> In this commit we move the recording of the datastore to the
> start of the do_testimage task. The do_testimage
> task then reads this freshly generated json and passes it into
> the normal test machinery. This approach allows for the test
> machinery to still be loosely coupled to bitbake, and thus
> still allows for the tests to be exported and used independently
> from bitbake. The caveat is, if there are datastore changes
> then the bitbake testimage task should be run before the tests
> can be ran independently again.

I'm not sure I agree with this. The test data really should be written
at either rootfs or image generation, not just before the tests are
run.

If you wanted to run the tests independently, after this change you
have no way to generate the data to do that without first running the
tests at least once. That doesn't make sense.

The correct thing to do here is to ensure the write_image_test_data()
function indicates which variables it depends upon and hence reruns
correctly.

Cheers,

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

Re: [OE-core] recipes-kernel/linux-libc-headers/linux-libc-headers.inc question

[Richard Purdie]

On Fri, 2018-08-31 at 18:41 +0300, Niko Mauno wrote:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eb24d4aeac
> aad9d41ddcbefd8d2ac96e95548183
> apparently is needed for 4.15, but it breaks with 4.14 as we get
> 
>   ERROR: linux-libc-headers-4.14-r0 do_install: oe_multilib_header:
>   Unable to find header asm/bpf_perf_event.h.
> 
> I used following to work this around in our own linux-libc-
> headers_4.14.bb:
> 
>   do_install_armmultilib_prepend() {
>   touch ${D}${includedir}/asm/bpf_perf_event.h
>   }
> 
> but curious if somebody could suggest a better mitigation

The options are really what you've done, copy the .inc and edit or use
the never libc-headers. It doesn't need to match your kernel version
and newer libc-headers should be very backwards compatible.

Cheers,

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

[OE-core] [openembedded][qt5] : Text is hidden in Qt5 apps

[Mohamed Dawod]

Hi,
I built custom image based on wayland instead of x11
it support Qt5 apps.
I built simple Qt5 app and tried to build it for the custom image to run it
there.
the application is work but the text is hidden !
The same for the test app "Qt5_Cinematicexperience"
No text at all for all films.

Thanks,


-- 

Mohamed Dawod
Computer Engineering Department
Faculty of Engineering
Cairo University
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/5] update_font_cache: update script for multilib

[Kang Kai]

On 2018年09月04日 17:44, Martin Jansa wrote:

Hi Kai,

do you have similar fix for update_gio_module_cache intercept? It 
seems to fail similarly with multilib enabled.


The fix is from script update_gio_module_cache, so I thought it works 
and didn't meet the failure. I'll check it.


Thanks,
Kai



Regards,

On Sat, Aug 25, 2018 at 7:14 PM Kai Kang > wrote:


Packages which inherit fontcache.bbclass call postinstall script
update_font_cache. And in update_font_cache, it calls
${bindir}/fc-cache
by qemuwrapper. When multilib is enabled, both packages foo and
lib32-foo
will call ${bindir}/fc-cache and one of them will fail to run
obviously.

Duplicate install file fc-cache to ${libexecdir} with ${MLPREFIX} and
call proper fc-cache in update_font_cache.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
 | 8 +++-
 scripts/postinst-intercepts/update_font_cache         | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

index d4cbce80b45..db36c867741 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

@@ -35,9 +35,15 @@ do_configure_prepend() {
     rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
 }

+do_install_append_class-target() {
+    # duplicate fc-cache for postinstall script
+    mkdir -p ${D}${libexecdir}
+    cp ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache
+}
+
 PACKAGES =+ "fontconfig-utils"
 FILES_${PN} =+ "${datadir}/xml/*"
-FILES_fontconfig-utils = "${bindir}/*"
+FILES_fontconfig-utils = "${bindir}/* ${libexecdir}/*"

 # Work around past breakage in debian.bbclass
 RPROVIDES_fontconfig-utils = "libfontconfig-utils"
diff --git a/scripts/postinst-intercepts/update_font_cache
b/scripts/postinst-intercepts/update_font_cache
index 20e9048adfc..e0ec471964c 100644
--- a/scripts/postinst-intercepts/update_font_cache
+++ b/scripts/postinst-intercepts/update_font_cache
@@ -2,5 +2,5 @@

 set -e

-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E
${fontconfigcacheenv} $D${bindir}/fc-cache --sysroot=$D
--system-only ${fontconfigcacheparams}
+PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E
${fontconfigcacheenv} $D${libexecdir}/${binprefix}fc-cache
--sysroot=$D --system-only ${fontconfigcacheparams}
 chown -R root:root $D${fontconfigcachedir}
-- 
2.11.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 6/6] multilib: fix install file conflicts

[Kang Kai]

On 2018年09月04日 17:16, richard.pur...@linuxfoundation.org wrote:

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:

Fix install files conflicts between multlib packages:


Error: Transaction check error:
   file /usr/bin/g-ir-annotation-tool conflicts between attempted installs of 
lib32-gobject-introspection-1.56.1-r0.x86 and 
gobject-introspection-1.56.1-r0.core2_64
   file /usr/bin/g-ir-scanner conflicts between attempted installs of 
lib32-gobject-introspection-1.56.1-r0.x86 and 
gobject-introspection-1.56.1-r0.core2_64
   file /usr/bin/cairo-trace conflicts between attempted installs of 
lib32-libcairo-perf-utils-1.14.12-r0.x86 and 
libcairo-perf-utils-1.14.12-r0.core2_64
   file /usr/bin/icu-config conflicts between attempted installs of 
lib32-icu-dev-62.1-r0.x86 and icu-dev-62.1-r0.core2_64
   file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted installs of 
gobject-introspection-dev-1.56.1-r0.core2_64 and 
lib32-gobject-introspection-dev-1.56.1-r0.x86
   file /usr/bin/gpgrt-config conflicts between attempted installs of 
lib32-libgpg-error-dev-1.32-r0.x86 and libgpg-error-dev-1.32-r0.core2_64
   file /usr/share/pkgconfig/udev.pc conflicts between attempted installs of 
eudev-dev-3.2.5-r0.core2_64 and lib32-eudev-dev-3.2.5-r0.x86

.pc files installed into /usr/share are architecture
independent. Either it is arch dependent in which case its in the wrong
place, or it needs to be fixed.


For .pc file of eudev, it sets udevdir with prefix ${libdir}

$ diff -u image/usr/share/pkgconfig/udev.pc 
../../../x86-pokymllib32-linux/lib32-eudev/3.2.5-r0/image/usr/share/pkgconfig/udev.pc

--- image/usr/share/pkgconfig/udev.pc   2018-08-31 16:03:35.721580345 +0800
+++ 
../../../x86-pokymllib32-linux/lib32-eudev/3.2.5-r0/image/usr/share/pkgconfig/udev.pc 
2018-09-03 14:20:05.320474868 +0800

@@ -3,4 +3,4 @@
 Version: 220
 prefix=/usr
 exec_prefix=/usr
-udevdir=/lib64/udev
+udevdir=/lib/udev




We are not putting these under control of update-alternatives!

It would be helpful to understand the kinds of differences in some of
these files. gir files in /usr/share/gir-1.0/ should also really be
arch independent...


For the .gir file, it contains some length of types, such as long and 
pointer.


@@ -21251,16 +21251,16 @@
 This is ":" on UNIX machines and ";" under Windows.
   
 
-    
+    
   
 
-    
+    
   
 
-    
+    
   
 
-    
+    
   
 
 


Regards,
Kai



Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 3/5] update_font_cache: update script for multilib

[Martin Jansa]

Hi Kai,

do you have similar fix for update_gio_module_cache intercept? It seems to
fail similarly with multilib enabled.

Regards,

On Sat, Aug 25, 2018 at 7:14 PM Kai Kang  wrote:

> Packages which inherit fontcache.bbclass call postinstall script
> update_font_cache. And in update_font_cache, it calls ${bindir}/fc-cache
> by qemuwrapper. When multilib is enabled, both packages foo and lib32-foo
> will call ${bindir}/fc-cache and one of them will fail to run obviously.
>
> Duplicate install file fc-cache to ${libexecdir} with ${MLPREFIX} and
> call proper fc-cache in update_font_cache.
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb | 8 +++-
>  scripts/postinst-intercepts/update_font_cache | 2 +-
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> index d4cbce80b45..db36c867741 100644
> --- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> +++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> @@ -35,9 +35,15 @@ do_configure_prepend() {
>  rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
>  }
>
> +do_install_append_class-target() {
> +# duplicate fc-cache for postinstall script
> +mkdir -p ${D}${libexecdir}
> +cp ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache
> +}
> +
>  PACKAGES =+ "fontconfig-utils"
>  FILES_${PN} =+ "${datadir}/xml/*"
> -FILES_fontconfig-utils = "${bindir}/*"
> +FILES_fontconfig-utils = "${bindir}/* ${libexecdir}/*"
>
>  # Work around past breakage in debian.bbclass
>  RPROVIDES_fontconfig-utils = "libfontconfig-utils"
> diff --git a/scripts/postinst-intercepts/update_font_cache
> b/scripts/postinst-intercepts/update_font_cache
> index 20e9048adfc..e0ec471964c 100644
> --- a/scripts/postinst-intercepts/update_font_cache
> +++ b/scripts/postinst-intercepts/update_font_cache
> @@ -2,5 +2,5 @@
>
>  set -e
>
> -PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E ${fontconfigcacheenv}
> $D${bindir}/fc-cache --sysroot=$D --system-only ${fontconfigcacheparams}
> +PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E ${fontconfigcacheenv}
> $D${libexecdir}/${binprefix}fc-cache --sysroot=$D --system-only
> ${fontconfigcacheparams}
>  chown -R root:root $D${fontconfigcachedir}
> --
> 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

Re: [OE-core] [PATCH 3/6] update_font_cache: update script for multilib

[Kang Kai]

On 2018年09月04日 17:12, richard.pur...@linuxfoundation.org wrote:

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:

Packages which inherit fontcache.bbclass call postinstall script
update_font_cache. And in update_font_cache, it calls ${bindir}/fc-
cache
by qemuwrapper. When multilib is enabled, both packages foo and
lib32-foo
will call ${bindir}/fc-cache and one of them will fail to run
obviously.

Duplicate install file fc-cache to ${libexecdir} with ${MLPREFIX} and
call proper fc-cache in update_font_cache.

Signed-off-by: Kai Kang 
---
  meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb | 8 +++-
  scripts/postinst-intercepts/update_font_cache | 2 +-
  2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
index d4cbce80b45..db36c867741 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
@@ -35,9 +35,15 @@ do_configure_prepend() {
  rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
  }
  
+do_install_append_class-target() {

+# duplicate fc-cache for postinstall script
+mkdir -p ${D}${libexecdir}
+cp ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache

We may as well hardlink this, same for the following patch too.


OK. Got it.

--Kai



Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

[OE-core] [PATCH] [PATCH] libdrm:2.4.93 -> 2.4.94

[Hong Liu]

Upgrade libdrm from 2.4.93 to 2.4.94.

Signed-off-by: Hong Liu 
---
 meta/recipes-graphics/drm/{libdrm_2.4.93.bb => libdrm_2.4.94.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/drm/{libdrm_2.4.93.bb => libdrm_2.4.94.bb} (95%)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.93.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.94.bb
similarity index 95%
rename from meta/recipes-graphics/drm/libdrm_2.4.93.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.94.bb
index 9219d87..d654292 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.93.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.94.bb
@@ -12,8 +12,8 @@ DEPENDS = "libpthread-stubs"
 
 SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
file://musl-ioctl.patch"
-SRC_URI[md5sum] = "0ba45ad1551b2c1b6df0797a3e65f827"
-SRC_URI[sha256sum] = 
"6e84d1dc9548a76f20b59a85cf80a0b230cd8196084f5243469d9e65354fcd3c"
+SRC_URI[md5sum] = "e9803233838007047f39eb385c70d9e0"
+SRC_URI[sha256sum] = 
"b73c59b0a3760502c428ba81de49cd4807657d26be5e697eba3a87dd021d16be"
 
 inherit meson pkgconfig manpages
 
-- 
2.7.4



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

Re: [OE-core] [PATCH 6/6] multilib: fix install file conflicts

[richard . purdie]

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:
> Fix install files conflicts between multlib packages:
> 
> > Error: Transaction check error:
> >   file /usr/bin/g-ir-annotation-tool conflicts between attempted installs 
> > of lib32-gobject-introspection-1.56.1-r0.x86 and 
> > gobject-introspection-1.56.1-r0.core2_64
> >   file /usr/bin/g-ir-scanner conflicts between attempted installs of 
> > lib32-gobject-introspection-1.56.1-r0.x86 and 
> > gobject-introspection-1.56.1-r0.core2_64
> >   file /usr/bin/cairo-trace conflicts between attempted installs of 
> > lib32-libcairo-perf-utils-1.14.12-r0.x86 and 
> > libcairo-perf-utils-1.14.12-r0.core2_64
> >   file /usr/bin/icu-config conflicts between attempted installs of 
> > lib32-icu-dev-62.1-r0.x86 and icu-dev-62.1-r0.core2_64
> >   file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted installs 
> > of gobject-introspection-dev-1.56.1-r0.core2_64 and 
> > lib32-gobject-introspection-dev-1.56.1-r0.x86
> >   file /usr/bin/gpgrt-config conflicts between attempted installs of 
> > lib32-libgpg-error-dev-1.32-r0.x86 and libgpg-error-dev-1.32-r0.core2_64
> >   file /usr/share/pkgconfig/udev.pc conflicts between attempted installs of 
> > eudev-dev-3.2.5-r0.core2_64 and lib32-eudev-dev-3.2.5-r0.x86

.pc files installed into /usr/share are architecture
independent. Either it is arch dependent in which case its in the wrong
place, or it needs to be fixed.

We are not putting these under control of update-alternatives!

It would be helpful to understand the kinds of differences in some of
these files. gir files in /usr/share/gir-1.0/ should also really be
arch independent...

Cheers,

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

Re: [OE-core] [PATCH 3/6] update_font_cache: update script for multilib

[richard . purdie]

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:
> Packages which inherit fontcache.bbclass call postinstall script
> update_font_cache. And in update_font_cache, it calls ${bindir}/fc-
> cache
> by qemuwrapper. When multilib is enabled, both packages foo and
> lib32-foo
> will call ${bindir}/fc-cache and one of them will fail to run
> obviously.
> 
> Duplicate install file fc-cache to ${libexecdir} with ${MLPREFIX} and
> call proper fc-cache in update_font_cache.
> 
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb | 8 +++-
>  scripts/postinst-intercepts/update_font_cache | 2 +-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> index d4cbce80b45..db36c867741 100644
> --- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> +++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
> @@ -35,9 +35,15 @@ do_configure_prepend() {
>  rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
>  }
>  
> +do_install_append_class-target() {
> +# duplicate fc-cache for postinstall script
> +mkdir -p ${D}${libexecdir}
> +cp ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache

We may as well hardlink this, same for the following patch too.

Cheers,

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

Re: [OE-core] [PATCH 1/6] allarch: disable allarch when multilib is used

[Kang Kai]

On 2018年09月04日 16:36, richard.pur...@linuxfoundation.org wrote:

Hi,

I think this is close and it passes the tests on the autobuilder
however I did spot a couple of potential issues after thinking about
this for a bit.

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:

Some allarch packages rdepends non-allarch packages. When multilib is
used, it doesn't expand the dependency chain correctly, e.g.

core-image-sato -> ca-certificates(allarch) -> openssl

we expect dependency chain for lib32-core-image-sato:

lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl

it should install lib32-openssl for ca-certificates but openssl is
still wrongly required.

Copy allarch.bbclass to allarch-enabled.bbclass and only inherit
allarch-enabled.bbclass when multilib is not used.

Signed-off-by: Kai Kang 
---
  meta/classes/allarch-enabled.bbclass | 52 
  meta/classes/allarch.bbclass | 51 ++-
  meta/classes/icecc.bbclass   |  2 +-
  meta/classes/multilib.bbclass|  2 +-
  meta/classes/multilib_global.bbclass |  2 +-
  meta/classes/package.bbclass |  6 ++---
  6 files changed, 60 insertions(+), 55 deletions(-)
  create mode 100644 meta/classes/allarch-enabled.bbclass


diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 1eebe0bf2e7..0eca076df0b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -1,52 +1,5 @@
  #
-# This class is used for architecture independent recipes/data files (usually 
scripts)
+# This class enables allarch only when multilib is not used.
  #
  
-PACKAGE_ARCH = "all"

-
-python () {
-# Allow this class to be included but overridden - only set
-# the values if we're still "all" package arch.
-if d.getVar("PACKAGE_ARCH") == "all":
-# No need for virtual/libc or a cross compiler
-d.setVar("INHIBIT_DEFAULT_DEPS","1")
-
-# Set these to a common set of values, we shouldn't be using them 
other that for WORKDIR directory
-# naming anyway
-d.setVar("baselib", "lib")
-d.setVar("TARGET_ARCH", "allarch")
-d.setVar("TARGET_OS", "linux")
-d.setVar("TARGET_CC_ARCH", "none")
-d.setVar("TARGET_LD_ARCH", "none")
-d.setVar("TARGET_AS_ARCH", "none")
-d.setVar("TARGET_FPU", "")
-d.setVar("TARGET_PREFIX", "")
-# Expand PACKAGE_EXTRA_ARCHS since the staging code needs this
-# (this removes any dependencies from the hash perspective)
-d.setVar("PACKAGE_EXTRA_ARCHS", d.getVar("PACKAGE_EXTRA_ARCHS"))
-d.setVar("SDK_ARCH", "none")
-d.setVar("SDK_CC_ARCH", "none")
-d.setVar("TARGET_CPPFLAGS", "none")
-d.setVar("TARGET_CFLAGS", "none")
-d.setVar("TARGET_CXXFLAGS", "none")
-d.setVar("TARGET_LDFLAGS", "none")
-d.setVar("POPULATESYSROOTDEPS", "")
-
-# Avoid this being unnecessarily different due to nuances of
-# the target machine that aren't important for "all" arch
-# packages.
-d.setVar("LDFLAGS", "")
-
-# No need to do shared library processing or debug symbol handling
-d.setVar("EXCLUDE_FROM_SHLIBS", "1")
-d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
-d.setVar("INHIBIT_PACKAGE_STRIP", "1")
-
-# These multilib values shouldn't change allarch packages so exclude 
them
-d.appendVarFlag("emit_pkgdata", "vardepsexclude", " MULTILIB_VARIANTS")
-d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS")
-d.appendVarFlag("do_package", "vardepsexclude", " package_do_shlibs")
-elif bb.data.inherits_class('packagegroup', d) and not 
bb.data.inherits_class('nativesdk', d):
-bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" 
% d.getVar("FILE"))
-}
-
+inherit ${@oe.utils.ifelse(d.getVar('MULTILIB_VARIANTS'), '', 
'allarch-enabled')}

Firstly, whilst I do understand why you've made this change like this,
I don't really like one line classes which clutter up the classes
directory. Using inherit like this does force the expansion of the
variable early and is very prone to "race" conditions. The above is
safe but see below.

FWIW the original code tried to switch off the value of the
PACKAGE_ARCH variable. If we change the way we enable/disable the code,
we should consider whether we can consistently use one mechanism for
both.


It has bugs in original code that the PACKAGE_ARCH is set in a python 
anonymous function and too later to set PACKAGE_ARCH.

I'll check how to do it with a better way.



Secondly, does this change affect the behaviour of nativesdk?

I think this will disable allarch for nativesdk in any multilib build
and we don't want to do that, we only have a problem with target
multilib allarch.

At a guess you probably need to check class-target is in overrides and
multilib_variants is set? The problem could be that class-target 

Re: [OE-core] [PATCH 1/6] allarch: disable allarch when multilib is used

[richard . purdie]

Hi,

I think this is close and it passes the tests on the autobuilder
however I did spot a couple of potential issues after thinking about
this for a bit.

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:
> Some allarch packages rdepends non-allarch packages. When multilib is
> used, it doesn't expand the dependency chain correctly, e.g.
> 
> core-image-sato -> ca-certificates(allarch) -> openssl
> 
> we expect dependency chain for lib32-core-image-sato:
> 
> lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl
> 
> it should install lib32-openssl for ca-certificates but openssl is
> still wrongly required.
> 
> Copy allarch.bbclass to allarch-enabled.bbclass and only inherit
> allarch-enabled.bbclass when multilib is not used.
> 
> Signed-off-by: Kai Kang 
> ---
>  meta/classes/allarch-enabled.bbclass | 52 
> 
>  meta/classes/allarch.bbclass | 51 ++-
>  meta/classes/icecc.bbclass   |  2 +-
>  meta/classes/multilib.bbclass|  2 +-
>  meta/classes/multilib_global.bbclass |  2 +-
>  meta/classes/package.bbclass |  6 ++---
>  6 files changed, 60 insertions(+), 55 deletions(-)
>  create mode 100644 meta/classes/allarch-enabled.bbclass
> 
> 
> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> index 1eebe0bf2e7..0eca076df0b 100644
> --- a/meta/classes/allarch.bbclass
> +++ b/meta/classes/allarch.bbclass
> @@ -1,52 +1,5 @@
>  #
> -# This class is used for architecture independent recipes/data files 
> (usually scripts)
> +# This class enables allarch only when multilib is not used.
>  #
>  
> -PACKAGE_ARCH = "all"
> -
> -python () {
> -# Allow this class to be included but overridden - only set
> -# the values if we're still "all" package arch.
> -if d.getVar("PACKAGE_ARCH") == "all":
> -# No need for virtual/libc or a cross compiler
> -d.setVar("INHIBIT_DEFAULT_DEPS","1")
> -
> -# Set these to a common set of values, we shouldn't be using them 
> other that for WORKDIR directory
> -# naming anyway
> -d.setVar("baselib", "lib")
> -d.setVar("TARGET_ARCH", "allarch")
> -d.setVar("TARGET_OS", "linux")
> -d.setVar("TARGET_CC_ARCH", "none")
> -d.setVar("TARGET_LD_ARCH", "none")
> -d.setVar("TARGET_AS_ARCH", "none")
> -d.setVar("TARGET_FPU", "")
> -d.setVar("TARGET_PREFIX", "")
> -# Expand PACKAGE_EXTRA_ARCHS since the staging code needs this
> -# (this removes any dependencies from the hash perspective)
> -d.setVar("PACKAGE_EXTRA_ARCHS", d.getVar("PACKAGE_EXTRA_ARCHS"))
> -d.setVar("SDK_ARCH", "none")
> -d.setVar("SDK_CC_ARCH", "none")
> -d.setVar("TARGET_CPPFLAGS", "none")
> -d.setVar("TARGET_CFLAGS", "none")
> -d.setVar("TARGET_CXXFLAGS", "none")
> -d.setVar("TARGET_LDFLAGS", "none")
> -d.setVar("POPULATESYSROOTDEPS", "")
> -
> -# Avoid this being unnecessarily different due to nuances of
> -# the target machine that aren't important for "all" arch
> -# packages.
> -d.setVar("LDFLAGS", "")
> -
> -# No need to do shared library processing or debug symbol handling
> -d.setVar("EXCLUDE_FROM_SHLIBS", "1")
> -d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
> -d.setVar("INHIBIT_PACKAGE_STRIP", "1")
> -
> -# These multilib values shouldn't change allarch packages so exclude 
> them
> -d.appendVarFlag("emit_pkgdata", "vardepsexclude", " 
> MULTILIB_VARIANTS")
> -d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS")
> -d.appendVarFlag("do_package", "vardepsexclude", " package_do_shlibs")
> -elif bb.data.inherits_class('packagegroup', d) and not 
> bb.data.inherits_class('nativesdk', d):
> -bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit 
> packagegroup" % d.getVar("FILE"))
> -}
> -
> +inherit ${@oe.utils.ifelse(d.getVar('MULTILIB_VARIANTS'), '', 
> 'allarch-enabled')}

Firstly, whilst I do understand why you've made this change like this,
I don't really like one line classes which clutter up the classes
directory. Using inherit like this does force the expansion of the
variable early and is very prone to "race" conditions. The above is
safe but see below. 

FWIW the original code tried to switch off the value of the
PACKAGE_ARCH variable. If we change the way we enable/disable the code,
we should consider whether we can consistently use one mechanism for
both.

Secondly, does this change affect the behaviour of nativesdk?

I think this will disable allarch for nativesdk in any multilib build
and we don't want to do that, we only have a problem with target
multilib allarch.

At a guess you probably need to check class-target is in overrides and
multilib_variants is set? The problem could be that class-target is set
comparatively late and then we're into ordering issues.

[OE-core] [PATCH] dhcp: make dhclient to get configuration for other programs

[Yi Zhao]

From: Li Wang 

Make dhclient to run /etc/dhcp/dhclient.d/*.sh, and get the configuration
for ntp, nis or other programes

These codes are from redhat rpm package.

Signed-off-by: Li Wang 
Signed-off-by: Roy Li 
Signed-off-by: Robert Yang 
Signed-off-by: Yi Zhao 
---
 .../dhcp/dhcp/dhcp-add-exec-script-function.patch  | 90 ++
 meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb   |  1 +
 meta/recipes-connectivity/dhcp/files/dhclient.conf |  1 +
 3 files changed, 92 insertions(+)
 create mode 100644 
meta/recipes-connectivity/dhcp/dhcp/dhcp-add-exec-script-function.patch

diff --git 
a/meta/recipes-connectivity/dhcp/dhcp/dhcp-add-exec-script-function.patch 
b/meta/recipes-connectivity/dhcp/dhcp/dhcp-add-exec-script-function.patch
new file mode 100644
index 000..1809b78
--- /dev/null
+++ b/meta/recipes-connectivity/dhcp/dhcp/dhcp-add-exec-script-function.patch
@@ -0,0 +1,90 @@
+From 36a4423d82291f6e01ee26a6f5bf0b5d0d75d07e Mon Sep 17 00:00:00 2001
+From: Li Wang 
+Date: Fri, 17 Jul 2015 14:31:49 +0800
+Subject: [PATCH] [PATCH] dhcp: add exec script function
+
+Make dhclient to run /etc/dhcp/dhclient.d/*.sh, and get the configuration
+for ntp, nis or other programes
+
+These codes are from redhat rpm packages.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Li Wang 
+Signed-off-by: Roy Li 
+Signed-off-by: Yi Zhao 
+---
+ client/scripts/linux | 21 +
+ 1 file changed, 21 insertions(+)
+
+diff --git a/client/scripts/linux b/client/scripts/linux
+index e9ea379..716d7e8 100755
+--- a/client/scripts/linux
 b/client/scripts/linux
+@@ -31,6 +31,8 @@
+ # overwirte this line to use a fake ip-echo tool. It's also convenient
+ # if your system holds ip tool in a non-standard location.
+ ip=/sbin/ip
++ETCDIR="/etc/dhcp"
++export SAVEDIR=/var/lib/dhcp
+ 
+ # update /etc/resolv.conf based on received values
+ # This updated version mostly follows Debian script by Andrew Pollock et al.
+@@ -182,6 +184,20 @@ exit_with_hooks() {
+ exit $exit_status
+ }
+ 
++execute_client_side_configuration_scripts() {
++# execute any additional client side configuration scripts we have
++if [ "${1}" == "config" ] || [ "${1}" == "restore" ]; then
++for f in ${ETCDIR}/dhclient.d/*.sh ; do
++if [ -x "${f}" ]; then
++subsystem="${f%.sh}"
++subsystem="${subsystem##*/}"
++. "${f}"
++"${subsystem}_${1}"
++fi
++done
++fi
++}
++
+ # This function was largely borrowed from dhclient-script that
+ # ships with Centos, authored by Jiri Popelka and David Cantrell
+ # of Redhat. Thanks guys.
+@@ -325,10 +341,12 @@ case "$reason" in
+ 
+ # update /etc/resolv.conf
+ make_resolv_conf
++execute_client_side_configuration_scripts "config"
+ 
+ ;;
+ 
+ EXPIRE|FAIL|RELEASE|STOP)
++execute_client_side_configuration_scripts "restore"
+ if [ -n "$alias_ip_address" ]; then
+ # flush alias IP
+ ${ip} -4 addr flush dev ${interface} label ${interface}:0
+@@ -464,6 +482,7 @@ case "$reason" in
+[ "${new_dhcp6_domain_search}" != "${old_dhcp6_domain_search}" ]; 
then
+ make_resolv_conf
+ fi
++execute_client_side_configuration_scripts "config"
+ 
+ ;;
+ 
+@@ -476,6 +495,7 @@ case "$reason" in
+ ${ip} -6 addr change ${cur_ip6_address}/${cur_ip6_prefixlen} \
+ dev ${interface} scope global preferred_lft 0
+ 
++execute_client_side_configuration_scripts "config"
+ ;;
+ 
+ EXPIRE6|RELEASE6|STOP6)
+@@ -487,6 +507,7 @@ case "$reason" in
+ ${ip} -6 addr del ${old_ip6_address}/${old_ip6_prefixlen} \
+ dev ${interface}
+ 
++execute_client_side_configuration_scripts "restore"
+ ;;
+ esac
+ 
diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb 
b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
index 159abbc..85ceaba 100644
--- a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
+++ b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
@@ -10,6 +10,7 @@ SRC_URI += 
"file://0001-define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.pat
 file://0009-remove-dhclient-script-bash-dependency.patch \
 file://0012-dhcp-correct-the-intention-for-xml2-lib-search.patch \
 file://0013-fixup_use_libbind.patch \
+file://dhcp-add-exec-script-function.patch \
 "
 
 SRC_URI[md5sum] = "18c7f4dcbb0a63df25098216d47b1ede"
diff --git a/meta/recipes-connectivity/dhcp/files/dhclient.conf 
b/meta/recipes-connectivity/dhcp/files/dhclient.conf
index 0e6dcf9..0f7d42f 100644
--- a/meta/recipes-connectivity/dhcp/files/dhclient.conf
+++ b/meta/recipes-connectivity/dhcp/files/dhclient.conf
@@ -17,6 +17,7 @@
 #supersede domain-name "fugue.com home.vix.com";
 #prepend domain-name-servers 127.0.0.1;
 request subnet-mask, broadcast-address, time-offset, routers,
+   nis-domain, nis-servers, domain-search, 

Re: [OE-core] [PATCH 1/1] bitbake.conf: Make BUILD_OPTIMIZATION respect to DEBUG_BUILD

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Robert Yang
> Sent: den 4 september 2018 08:37
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 1/1] bitbake.conf: Make BUILD_OPTIMIZATION
> respect to DEBUG_BUILD
> 
> We may also need debug native tools, so make BUILD_OPTIMIZATION respect to
> DEBUG_BUILD, otherwise, we need set CFLAGS in the recipe which isn't
> convenient.
> 
> Signed-off-by: Robert Yang 
> ---
>  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 1941633..df62445 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -612,7 +612,7 @@ FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
>  DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
>  SELECTED_OPTIMIZATION = "${@d.getVar(['FULL_OPTIMIZATION', 
> 'DEBUG_OPTIMIZATION'][d.getVar('DEBUG_BUILD') == '1'])}"
>  SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION DEBUG_OPTIMIZATION"
> -BUILD_OPTIMIZATION = "-O2 -pipe"
> +BUILD_OPTIMIZATION = "${@['-O2', '-O -g -feliminate-unused-debug-types 
> -fno-omit-frame-pointer'][d.getVar('DEBUG_BUILD') == '1']} -pipe"

Can we make that more readable:

BUILD_OPTIMIZATION = "${@'-O -g -feliminate-unused-debug-types 
-fno-omit-frame-pointer' if d.getVar('DEBUG_BUILD') == '1' else '-O2'} -pipe"

Should probably do the same for SELECTED_OPTIMIZATION while at it:

SELECTED_OPTIMIZATION = "${@d.getVar('DEBUG_OPTIMIZATION' if 
d.getVar('DEBUG_BUILD') == '1' else 'FULL_OPTIMIZATION')}"

> 
>  ##
>  # Settings used by bitbake-layers.
> --
> 2.7.4

//Peter

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

[OE-core] [PATCH 1/1] package_manager.py: add noarch to buildarch_compat

[kai.kang]

From: Kai Kang 

It fails to run rpmbuild to build a noarch package on target when it
contains 'BuildArch: noarch' in the spec file:

| error: No compatible architectures found for build

Add 'noarch' to buildarch_compat in configure file rpmrc to fix it.

Signed-off-by: Kai Kang 
---
 meta/lib/oe/package_manager.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 398838835e..da53e06c33 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -766,7 +766,9 @@ class RpmPM(PackageManager):
 rpmrcconfdir = "%s/%s" %(self.target_rootfs, "etc/")
 bb.utils.mkdirhier(platformconfdir)
 open(platformconfdir + "platform", 'w').write("%s-pc-linux" % 
self.primary_arch)
-open(rpmrcconfdir + "rpmrc", 'w').write("arch_compat: %s: %s\n" % 
(self.primary_arch, self.archs if len(self.archs) > 0 else self.primary_arch))
+with open(rpmrcconfdir + "rpmrc", 'w') as f:
+f.write("arch_compat: %s: %s\n" % (self.primary_arch, self.archs 
if len(self.archs) > 0 else self.primary_arch))
+f.write("buildarch_compat: %s: noarch\n" % self.primary_arch)
 
 open(platformconfdir + "macros", 'w').write("%_transaction_color 7\n")
 if self.d.getVar('RPM_PREFER_ELF_ARCH'):
-- 
2.18.0

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

[OE-core] [PATCH 0/1] package_manager.py: add noarch to buildarch_compat

[kai.kang]

From: Kai Kang 

The following changes since commit 443405cf49300a7d2c9ca8fa3080d551d795:

  bitbake: tests/fetch: Update gnome.org urls after upstream changes 
(2018-08-29 10:43:23 +0100)

are available in the Git repository at:

  git://git.pokylinux.org/poky-contrib kangkai/rpm
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/rpm

Kai Kang (1):
  package_manager.py: add noarch to buildarch_compat

 meta/lib/oe/package_manager.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.18.0

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

[OE-core] [PATCH 1/1] bitbake.conf: Make BUILD_OPTIMIZATION respect to DEBUG_BUILD

[Robert Yang]

We may also need debug native tools, so make BUILD_OPTIMIZATION respect to
DEBUG_BUILD, otherwise, we need set CFLAGS in the recipe which isn't
convenient.

Signed-off-by: Robert Yang 
---
 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 1941633..df62445 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -612,7 +612,7 @@ FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
 DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
 SELECTED_OPTIMIZATION = "${@d.getVar(['FULL_OPTIMIZATION', 
'DEBUG_OPTIMIZATION'][d.getVar('DEBUG_BUILD') == '1'])}"
 SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION DEBUG_OPTIMIZATION"
-BUILD_OPTIMIZATION = "-O2 -pipe"
+BUILD_OPTIMIZATION = "${@['-O2', '-O -g -feliminate-unused-debug-types 
-fno-omit-frame-pointer'][d.getVar('DEBUG_BUILD') == '1']} -pipe"
 
 ##
 # Settings used by bitbake-layers.
-- 
2.7.4

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

[OE-core] [PATCH 0/1] bitbake.conf: Make BUILD_OPTIMIZATION respect to DEBUG_BUILD

[Robert Yang]

The following changes since commit 853e0499be449c71378c087e08b1926be8e2ac87:

  ruby: improve reproducibility (2018-08-29 10:40:08 +0100)

are available in the git repository at:

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

Robert Yang (1):
  bitbake.conf: Make BUILD_OPTIMIZATION respect to DEBUG_BUILD

 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4

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

Re: [OE-core] [PATCH 3/7] sysklogd: Use update-alternatives

[Markus Lehtonen]

Hmm,

There should be rconflicts in place, in both way – i.e. busybox-syslog 
rconflicts with sysklogd and the other way around. Isn't there(?)
  - Markus

On 03/09/2018, 19.34, "Khem Raj"  wrote:

On Sun, Sep 2, 2018 at 11:49 PM Markus Lehtonen
 wrote:
>
> Hi,
>
> IIRC, the problem was that all the syslog packages were providing 
${sysconfdir}/init.d/syslog which caused problems. And I don't think that has 
changed.
>
> Why would you want to install two syslog daemons on the system? You 
should be able to install busybox after syslog as busybox-syslog is packaged in 
separate binary rpm.
>

thats fine, we need to have a RCONFLICTS statement to catch these
issues explicitly during packaging.

> Cheers,
>   Markus
>
> On 30/08/2018, 12.41, "ChenQi"  wrote:
>
> On 08/30/2018 03:44 PM, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org 
 >> core-boun...@lists.openembedded.org> On Behalf Of Khem Raj
> >> Sent: den 30 augusti 2018 05:56
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: [OE-core] [PATCH 3/7] sysklogd: Use update-alternatives
> >>
> >> busybox also provides klogd and syslogd, this change makes it 
coexist
> >> peacefully. Currently rootfs fails in situations where both of 
them are
> >> providing these binaries and busybox postinsts fail
> >>
> >> update-alternatives: Error: not linking
> >> /mnt/a/oe/build/tmp/work/qemuriscv64-bec-linux/core-image-full-
> >> cmdline/1.0-r0/rootfs/sbin/klogd
> >> to /bin/busybox.nosuid since
> >> /mnt/a/oe/build/tmp/work/qemuriscv64-bec-linux/core-image-full-
> >> cmdline/1.0-r0/rootfs/sbin/klogd
> >> exists and is not a link
> >>
> >> Signed-off-by: Khem Raj 
> >> ---
> >>   meta/recipes-extended/sysklogd/sysklogd.inc | 8 +++-
> >>   1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc
> >> b/meta/recipes-extended/sysklogd/sysklogd.inc
> >> index fc4e67c18e..2a8bed00f3 100644
> >> --- a/meta/recipes-extended/sysklogd/sysklogd.inc
> >> +++ b/meta/recipes-extended/sysklogd/sysklogd.inc
> >> @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
> >>   
file://klogd.c;beginline=2;endline=19;md5=7e87ed0ae6142de079bce738c10c899d \
> >>  "
> >>
> >> -inherit update-rc.d systemd
> >> +inherit update-rc.d systemd update-alternatives
> >>
> >>   SRC_URI = 
"http://www.infodrom.org/projects/sysklogd/download/sysklogd-${PV}.tar.gz \
> >>  file://no-strip-install.patch \
> >> @@ -70,3 +70,9 @@ python () {
> >>   if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 
True, False, d):
> >>   d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
> >>   }
> >> +
> >> +ALTERNATIVE_PRIORITY = "100"
> >> +ALTERNATIVE_${PN} = "klogd syslogd"
> >> +ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
> >> +ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"
> >> +
> >> --
> >> 2.18.0
> > This is a (partial) revert of commit 988aad01b2 (sysklogd: don't use
> > update-alternatives). Can you come to an agreement regarding which 
is
> > the correct solution?
> >
> > //Peter
> >
>
>
> I think the previous commit (syslogd: don't use update-alternatives) 
is
> made because syslog daemon conflict with each other. I guess the 
author
> assumed that the 'syslogd' and 'klogd' alternatives entries are 
handled
> by busybox-syslog package.
>
> On the other hand, I think the patch is trying to solve the problem of
> busybox being installed after sysklogd.
> We are currently not seeing errors because busybox is likely to be
> installed before sysklogd. Even in this situation, the result is not 
all
> correct, because the links busybox's postinstall creates are covered 
by
> the real binaries from sysklogd.
>
> I think the problem is about busybox's handling of alternatives.
>
> Khem, I've sent out a patch to fix busybox's alternatives logic. Could
> you please help review it?
>
> Best Regards,
> Chen Qi
>
>
>



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