Re: [OE-core] openssl10 unusable for many components

[Khem Raj]

On Thu, Aug 17, 2017 at 4:54 AM, Alexander Kanavin
 wrote:
> On 08/17/2017 02:46 PM, Martin Jansa wrote:
>>
>> I meant "real-world" as builds for any products on the market (which are
>> likely using one of the failing recipes) - e.g. in LGE we have many more
>> failures over all internal components, so I'll just undo this openssl switch
>> (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as openssl_1.0
>> with PROVIDES openssl11). We won't be able to use openssl-1.1 for long time
>> anyway, because there are some 3rd party component which are difficult (or
>> expensive) to get rebuilt against new openssl ABI, but we might be
>> interested in some other improvements in oe-core/master.
>
>
> Yes, this will work for you as a quick fix, but it is merely postponing
> dealing with the issue properly to a later date. Make a plan for it and keep
> in mind that openssl 1.0 goes out of upstream support at the end of 2019.
> Given its history of major security vulnerabilities, it will be removed from
> oe-core well before that time, so that it won't linger in supported YP
> releases.
>

I was trying nodejs and it seems its also broken by this openssl
upgrade. Meta-oe alone has amost 50 recipes that are broken. there are
hundreds of other layers.
Many large packages in external layers are now broken, and the fact
that openssl10
is almost useless since some package will pull in openssl11 and cause
conflicts. This
is not a a good solution at least it seems to early for release. It
might take a bit for packages to get working with openssl11, We should
have carefully thought and considered postponing using it as default
until next release ( april 2018). Its fine to keep it in if needed but
keep openssl 1.0 as default preferred version, I don't think whole
ecosystem is ready for it and we don't have man power to fix
everything. This alone has a potential to make
October release quite weak as far as external layers are concerned

If we want to keep openssl 1.1 in Oe-Core as default its fine, then
lets provide a way to downgrade it instead of openssl10 recipe which
is sub-optimal since OE does build from
source and not binary packages where such a solution might work.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] insane: add qa check for uppercase recipe name

[Yeoh Ee Peng]

Since we disabled uppercase characters in overrides a few releases
ago, uppercase characters in recipe names (and for that matter, distro
and machine names) cannot be supported due to their reliance upon
overrides including the name.

QA check will produce an warning message when it verify that recipe
name is uppercase.

[YOCTO# 11592]

Signed-off-by: Yeoh Ee Peng 
---
 meta/classes/insane.bbclass | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index b7177c9..86237a8 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -16,7 +16,7 @@
 #   into exec_prefix
 #  -Check that scripts in base_[bindir|sbindir|libdir] do not reference
 #   files under exec_prefix
-
+#  -Check if the package name is upper case
 
 QA_SANE = "True"
 
@@ -27,7 +27,7 @@ WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir 
xorg-driver-abi \
 installed-vs-shipped compile-host-path install-host-path \
 pn-overrides infodir build-deps \
 unknown-configure-option symlink-to-sysroot multilib \
-invalid-packageconfig host-user-contaminated \
+invalid-packageconfig host-user-contaminated uppercase-pn \
 "
 ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
 perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
@@ -1248,6 +1248,8 @@ do_configure[postfuncs] += "do_qa_configure "
 do_unpack[postfuncs] += "do_qa_unpack"
 
 python () {
+import re
+
 tests = d.getVar('ALL_QA').split()
 if "desktop" in tests:
 d.appendVar("PACKAGE_DEPENDS", " desktop-file-utils-native")
@@ -1274,6 +1276,8 @@ python () {
 if pn in overrides:
 msg = 'Recipe %s has PN of "%s" which is in OVERRIDES, this can result 
in unexpected behaviour.' % (d.getVar("FILE"), pn)
 package_qa_handle_error("pn-overrides", msg, d)
+if re.search('[A-Z]', pn):
+package_qa_handle_error("uppercase-pn", 'PN: %s is upper case, this 
can result in unexpected behavior.' % pn, d)
 
 issues = []
 if (d.getVar('PACKAGES') or "").split():
-- 
2.7.4

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

Re: [OE-core] [PATCH v3] (morty) rpm: Fix the Bug of SRPM String error

[Zheng, Ruoqin]

ping

-Original Message-
From: Zheng, Ruoqin/郑 若钦 
Sent: Friday, June 23, 2017 9:56 AM
To: openembedded-core@lists.openembedded.org
Cc: Zheng, Ruoqin/郑 若钦 
Subject: [OE-core] [PATCH v3] (morty) rpm: Fix the Bug of SRPM String error

Add a patch 0001-Fix-the-Bug-of-SRPM-String-error.patch to fix SRPM bug

When use bitbake to build a SRPM package, some sections of SRPM can't be 
displayed normally.
For example:
$ rpm -qpi bash-4.3.30-r0.src.rpm
warning: bash-4.3.30-r0.src.rpm: Header V4 DSA/SHA1 Signature, key ID 0a868e8e: 
NOKEY
Name: bash
Version : 4.3.30
Release : r0
Architecture: i586
Install Date: (not installed)
Group   : Ô¯
Size: 8413797
License : GPLv3+
Signature   : DSA/SHA1, Wed 21 Jun 2017 07:37:52 PM PDT, Key ID 609104e40a868e8e
Source RPM  : (none)
Build Date  : Wed 21 Jun 2017 07:37:52 PM PDT Build Host  : ubuntu Relocations 
: (not relocatable)
Packager: Poky 
URL : http://tiswww.case.edu/php/chet/bash/bashtop.html
Summary : 8
Description :
8 

Signed-off-by: zhengrq 
---
 .../0001-Fix-the-Bug-of-SRPM-String-error.patch| 48 ++
 meta/recipes-devtools/rpm/rpm_5.4.16.bb|  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 
meta/recipes-devtools/rpm/rpm/0001-Fix-the-Bug-of-SRPM-String-error.patch

diff --git 
a/meta/recipes-devtools/rpm/rpm/0001-Fix-the-Bug-of-SRPM-String-error.patch 
b/meta/recipes-devtools/rpm/rpm/0001-Fix-the-Bug-of-SRPM-String-error.patch
new file mode 100644
index 000..b962617
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/0001-Fix-the-Bug-of-SRPM-String-erro
+++ r.patch
@@ -0,0 +1,48 @@
+Subject: [PATCH] Fix the Bug of SRPM String error
+
+Upstream-Status: Pending
+$ rpm -qpi bash-4.3.30-r0.src.rpm
+warning: bash-4.3.30-r0.src.rpm: Header V4 DSA/SHA1 Signature, key ID 
0a868e8e: NOKEY
+Name: bash
+Version : 4.3.30
+Release : r0
+Architecture: i586
+Install Date: (not installed)
+Group   : Ô¯
+Size: 8413797
+License : GPLv3+
+Signature   : DSA/SHA1, Wed 21 Jun 2017 07:37:52 PM PDT, Key ID 
609104e40a868e8e
+Source RPM  : (none)
+Build Date  : Wed 21 Jun 2017 07:37:52 PM PDT Build Host  : ubuntu 
+Relocations : (not relocatable)
+Packager: Poky 
+URL : http://tiswww.case.edu/php/chet/bash/bashtop.html
+Summary : 8
+Description :
+8
+
+Signed-off-by: zhengrq 
+---
+ rpmdb/tagname.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/rpmdb/tagname.c b/rpmdb/tagname.c index cfd1459..dbcafd1 
+100644
+--- a/rpmdb/tagname.c
 b/rpmdb/tagname.c
+@@ -518,9 +518,9 @@ tagStore_t tagStoreFree(tagStore_t dbiTags, size_t 
+dbiNTags)  void tagTypeValidate(HE_t he);  void tagTypeValidate(HE_t 
+he)  {
+-/* XXX Re-map RPM_I18NSTRING_TYPE -> RPM_STRING_TYPE */
++/* XXX RPM_I18NSTRING_TYPE is treated as strings. */
+ if (he->t == RPM_I18NSTRING_TYPE)
+-  he->t = RPM_STRING_TYPE;
++  return;
+ 
+ /* XXX Arbitrary tags are always strings. */
+ if ((he->tag & 0x4000)
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.16.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
index 497af8e..ae5e0c4 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.16.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
@@ -120,6 +120,7 @@ SRC_URI += " \
   file://0001-system.h-query.c-support-nosignature.patch \
   file://rpm-ensure-rpm2cpio-call-rpm-relocation-code.patch \
   file://0001-macros-add-_gpg_sign_cmd_extra_args.patch \
+  file://0001-Fix-the-Bug-of-SRPM-String-error.patch \
 "
 
 # OE specific changes
--
2.7.4



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

Re: [OE-core] [PATCH] recipetool: create: allow handers to set license

[Paul Eggleton]

On Thursday, 10 August 2017 10:00:39 PM NZST Richard Purdie wrote:
> On Wed, 2017-08-02 at 16:09 -0700, Mark D Horn wrote:
> > Recipetool plugins set through register_recipe_handlers were not able
> > to impact the license type via setting extravalues['LICENSE']. This
> > is
> > due to caching the license variables in create_recipe before the
> > handlers
> > have been executed.
> > 
> > This change moves the call to handle_license_vars well after the
> > registered plugins (and extravalue functions) have been called.
> > 
> > Signed-off-by: Mark D Horn 
> > ---
> >  scripts/lib/recipetool/create.py | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> I'm afraid this leads to oe-selftest regressions and issues in devtool:
>...

FYI Mark and I have discussed this offline and I have a reworked change for 
which the tests pass - I just need to sort out where some of the other devtool 
patches are and I will send it out.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] initramfs-framework/setup-live: also boot live image if root=/dev/ram0

[California Sullivan]

Our grub and syslinux bootloaders both define root=/dev/ram0 for live
images by default. Kernel docs show that root=/dev/ram0 is just a
sentinel value for the kernel to mount the initrd as root, which then
mounts and switches to the real root. This is exactly what our scripts
do, so just check for root=/dev/ram0 as well.

See: https://www.kernel.org/doc/html/v4.11/admin-guide/initrd.html#operation

This fixes the issue where the new initramfs-framework scripts would not
boot live images that use grub or syslinux bootloaders.

Signed-off-by: California Sullivan 
---
I think the first one was missed because it was sent as a reply rather
than a top-level subject. This one has the same change but with a better
commit message.

 meta/recipes-core/initrdscripts/initramfs-framework/setup-live | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/setup-live 
b/meta/recipes-core/initrdscripts/initramfs-framework/setup-live
index 591c93a..b98a321 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework/setup-live
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/setup-live
@@ -12,7 +12,7 @@ ISOLINUX=""
 ROOT_DISK=""
 shelltimeout=30
 
-   if [ -z $bootparam_root ]; then
+   if [ -z $bootparam_root -o $bootparam_root = "/dev/ram0" ]; then
echo "Waiting for removable media..."
C=0
while true
-- 
2.9.5

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

[OE-core] [PATCH v7] kernel: Add support for multiple kernel packages

[Haris Okanovic]

Some distros may want to provide alternate kernel "flavors" via feeds or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers to
more quickly resolve issues by avoiding lengthy kernel builds.

This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.

To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build
in the old location and may be preferred provider -- while recipes using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't
provide "virtual/kernel".

Testing:
 1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
linux-yocto-tiny_4.9.bb so that it may build alongside
the main kernel.
 2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors.
 3. Verified image and modules IPKs exist for both:
tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
 4. Verified linux-yocto is the "preferred provider", and was built in
shared directory: tmp-glibc/work-shared/qemux86/kernel-*
 5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
core-image-base.bb to include both kernel flavors.
 6. `bitbake core-image-base` to build an image.
 7. Verified image contains two bzImage's under /boot/, with
"yocto-standard" selected to boot via symlink.

Discussion threads:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122
http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Gratian Crisan 
Signed-off-by: Haris Okanovic 
Coauthored-by: Gratian Crisan 
Coauthored-by: Haris Okanovic 
Coauthored-by: Josh Hernstrom 
---
[PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to the
"work" directory in alternate kernel builds, instead of "work-shared",
so
that the two builds don't clobber each other.

[PATCH v3] An updated version of this change rebased onto the current
OE-core master. Changes:
 - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
   kernel builds, since alternate kernels aren't the
   PREFERRED_PROVIDER for virtual/kernel by definition.
 - Remove "virtual/kernel" from PROVIDES in alternate kernel builds.

[PATCH v4] Another rebase onto master; no functional change.
Improved description and testing steps.

[PATCH v5]
 - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
 - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions

[PATCH v6] Add KERNEL_PACKAGE_NAME to kernel-module-split.bbclass for
module recipes; fixes lttng-modules build.

[PATCH v7] Remove second definition of KERNEL_PACKAGE_NAME from
kernel-module-split.bbclass; apply a default in two places where
KERNEL_PACKAGE_NAME is referenced.

https://github.com/harisokanovic/openembedded-core/tree/dev/hokanovi/multi-kernel-packages-v7
---
 meta/classes/kernel-module-split.bbclass  |   9 ++-
 meta/classes/kernel.bbclass   | 114 +++---
 meta/conf/documentation.conf  |   1 +
 meta/recipes-kernel/linux/linux-dtb.inc   |   2 +-
 meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
 5 files changed, 81 insertions(+), 47 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 1035525dac..73c7f18c78 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -30,7 +30,7 @@ do_install_append() {
 
 PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
 
-KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
+KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME", True) or 
"kernel" }-modules"
 
 KERNEL_MODULE_PACKAGE_PREFIX ?= ""
 KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
@@ -129,16 +129,19 @@ python split_kernel_module_packages () {
postfix = format.split('%s')[1]
d.setVar('RPROVIDES_' + pkg, pkg.replace(postfix, ''))
 
+kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME", True) or "kernel"
+kernel_version = d.getVar("KERNEL_VERSION", True)
+
 module_regex = '^(.*)\.k?o$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 

Re: [OE-core] [PATCH v6] kernel: Add support for multiple kernel packages

[Haris Okanovic]

On 08/16/2017 11:00 AM, Wold, Saul wrote:

On Mon, 2017-08-14 at 16:29 -0500, Haris Okanovic wrote:

Some distros may want to provide alternate kernel "flavors" via feeds
or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers
to
more quickly resolve issues by avoiding lengthy kernel builds.

This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.

To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is
because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
build
in the old location and may be preferred provider -- while recipes
using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
don't
provide "virtual/kernel".

Testing:
  1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
 linux-yocto-tiny_4.9.bb so that it may build alongside
 the main kernel.
  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
flavors.
  3. Verified image and modules IPKs exist for both:
 tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
 tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
  4. Verified linux-yocto is the "preferred provider", and was built
in
 shared directory: tmp-glibc/work-shared/qemux86/kernel-*
  5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
 core-image-base.bb to include both kernel flavors.
  6. `bitbake core-image-base` to build an image.
  7. Verified image contains two bzImage's under /boot/, with
 "yocto-standard" selected to boot via symlink.

Discussion threads:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_pipermail_openembedded-2Dcore_2015-2DDecemb=DwIGaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=8Bziuw3IaCGjyrSAphuGwHmVdHcVwza-srUYwL9U_Ms=0QcXD-YEVpGbAgVAWiuCmMnvCng6N5j5KrqqwqXHW2E=88YT5OEfyAkDMCqrZzRoGH6Z8DsSjP8nfCmrq4fronk=
er/thread.html#114122
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_pipermail_openembedded-2Dcore_2017-2DJuly_t=DwIGaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=8Bziuw3IaCGjyrSAphuGwHmVdHcVwza-srUYwL9U_Ms=0QcXD-YEVpGbAgVAWiuCmMnvCng6N5j5KrqqwqXHW2E=2NjYYuy80NctfYU9vcnLPueVm9rALs-0nFjVd5cnY8w=
hread.html#139130

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Gratian Crisan 
Signed-off-by: Haris Okanovic 
Coauthored-by: Gratian Crisan 
Coauthored-by: Haris Okanovic 
Coauthored-by: Josh Hernstrom 
---
[PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to
the
"work" directory in alternate kernel builds, instead of "work-
shared",
so
that the two builds don't clobber each other.

[PATCH v3] An updated version of this change rebased onto the current
OE-core master. Changes:
  - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
kernel builds, since alternate kernels aren't the
PREFERRED_PROVIDER for virtual/kernel by definition.
  - Remove "virtual/kernel" from PROVIDES in alternate kernel builds.

[PATCH v4] Another rebase onto master; no functional change.
Improved description and testing steps.

[PATCH v5]
  - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
  - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions

[PATCH v6] Add KERNEL_PACKAGE_NAME to kernel-module-split.bbclass for
module recipes; fixes lttng-modules build.

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_harisokanovic_openembedded-2Dcore_tree_dev_hokanovi_=DwIGaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=8Bziuw3IaCGjyrSAphuGwHmVdHcVwza-srUYwL9U_Ms=0QcXD-YEVpGbAgVAWiuCmMnvCng6N5j5KrqqwqXHW2E=HlNgsQzUBE7Qo-WEzXqkx8xf814iqTLQbr-EqAENFKs=
multi-kernel-packages-v6
---
  meta/classes/kernel-module-split.bbclass  |  14 +++-
  meta/classes/kernel.bbclass   | 114 +++-
--
  meta/conf/documentation.conf  |   1 +
  meta/recipes-kernel/linux/linux-dtb.inc   |   2 +-
  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
  5 files changed, 86 insertions(+), 47 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 1035525dac..59f19f3de2 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -30,7 +30,12 @@ do_install_append() {
  
  PACKAGESPLITFUNCS_prepend = 

[OE-core] [PATCH] insane.bbclass: Warn if ${COREBASE}/LICENSE is used

[Saul Wold]

The top level LICENSE file is not actually a license, it refers
other licenses that are used by Bitbake and Meta-data. Relying
on this file could cause problems for recipes when this file
changes, which it is about to.

Signed-off-by: Saul Wold 
---
 meta/classes/insane.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 479d39c..6d20eb6 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -659,7 +659,7 @@ python populate_lic_qa_checksum() {
 sane = package_qa_handle_error("license-checksum", pn + ": Recipe file 
fetches files and does not have license file information (LIC_FILES_CHKSUM)", d)
 
 srcdir = d.getVar('S')
-
+corebase_licensefile = d.getVar('COREBASE') + "/LICENSE"
 for url in lic_files.split():
 try:
 (type, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
@@ -670,6 +670,10 @@ python populate_lic_qa_checksum() {
 if not os.path.isfile(srclicfile):
 package_qa_handle_error("license-checksum", pn + ": 
LIC_FILES_CHKSUM points to an invalid file: " + srclicfile, d)
 continue
+
+if (srclicfile == corebase_licensefile):
+bb.warn("${COREBASE}/LICENSE is not a valid license file, please 
use '${COMMON_LICENSE_DIR}/MIT' for a MIT License file in LIC_FILES_CHKSUM")
+bb.warn("This will become an error in the next release")
 
 recipemd5 = parm.get('md5', '')
 beginline, endline = 0, 0
-- 
2.7.5

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

Re: [OE-core] [PATCH v3 02/11] image-prelink.bbclass: support binary reproducibility

[Leonardo Sandoval]

On Wed, 2017-08-09 at 10:48 -0700, Juro Bystricky wrote:
> Conditionally support binary reproducibility in built images.
> If BUILD_REPRODUCIBLE_BINARIES = 1 then:
> 
> 1. Do not randomize library addresses
> 2. Set/export PRELINK_TIMESTAMP to a reproducible value.
>If REPRODUCIBLE_TIMESTAMP_ROOTFS is specified, then the value will
>be used. Otherwise the timestamp will be derived from the top git commit.
> 
> Signed-off-by: Juro Bystricky 
> ---
>  meta/classes/image-prelink.bbclass | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image-prelink.bbclass 
> b/meta/classes/image-prelink.bbclass
> index 4157df0..e833d47 100644
> --- a/meta/classes/image-prelink.bbclass
> +++ b/meta/classes/image-prelink.bbclass
> @@ -36,7 +36,17 @@ prelink_image () {
>   dynamic_loader=$(linuxloader)
>  
>   # prelink!
> - ${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -amR -N -c 
> ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
> + if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
> + bbnote " prelink: BUILD_REPRODUCIBLE_BINARIES..."
> + if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
> + export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `


as Chris suggested in other email, better to used $() instead of ``



> + else
> + export PRELINK_TIMESTAMP=$REPRODUCIBLE_TIMESTAMP_ROOTFS
> + fi
> + ${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -am -N 
> -c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
> + else
> + ${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -amR 
> -N -c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
> + fi
>  
>   # Remove the prelink.conf if we had to add it.
>   if [ "$dummy_prelink_conf" = "true" ]; then
> -- 
> 2.7.4
> 


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

Re: [OE-core] [PATCH v3 08/11] python2.7: improve reproducibility

[Leonardo Sandoval]

On Wed, 2017-08-09 at 10:48 -0700, Juro Bystricky wrote:
> The compiled .pyc files contain time stamp corresponding to the compile time.
> This prevents binary reproducibility. This patch allows to achieve binary
> reproducibility by overriding the build time stamp by the value
> exported via SOURCE_DATE_EPOCH.
> 
> Patch by Bernhard M. Wiedemann, backported from 
> https://github.com/python/cpython/pull/296
> 
> [YOCTO#11241]
> 
> Signed-off-by: Juro Bystricky 
> ---
>  .../python/python-native_2.7.13.bb |  1 +
>  .../python/python/reproducible.patch   | 34 
> ++
>  meta/recipes-devtools/python/python_2.7.13.bb  |  1 +
>  3 files changed, 36 insertions(+)
>  create mode 100644 meta/recipes-devtools/python/python/reproducible.patch
> 
> diff --git a/meta/recipes-devtools/python/python-native_2.7.13.bb 
> b/meta/recipes-devtools/python/python-native_2.7.13.bb
> index 7edf153..a82b7bb 100644
> --- a/meta/recipes-devtools/python/python-native_2.7.13.bb
> +++ b/meta/recipes-devtools/python/python-native_2.7.13.bb
> @@ -17,6 +17,7 @@ SRC_URI += "\
>  file://builddir.patch \
>  file://parallel-makeinst-create-bindir.patch \
>  file://revert_use_of_sysconfigdata.patch \
> +file://reproducible.patch \


Not really important but it would be better to rename the patch to
something more specific
('repoducible-build-time-override-by-source-date-epoch.path'), allowing
future patches in this area. Besides a better name, it helps to quickly
identify the patch purpose without looking at the code itself.



> "
>  
>  S = "${WORKDIR}/Python-${PV}"
> diff --git a/meta/recipes-devtools/python/python/reproducible.patch 
> b/meta/recipes-devtools/python/python/reproducible.patch
> new file mode 100644
> index 000..1265179
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python/reproducible.patch
> @@ -0,0 +1,34 @@
> +The compiled .pyc files contain time stamp corresponding to the compile time.
> +This prevents binary reproducibility. This patch allows to achieve binary
> +reproducibility by overriding the build time stamp by the value 
> +exported via SOURCE_DATE_EPOCH. 
> +
> +Patch by Bernhard M. Wiedemann
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Juro Bystricky 
> +
> +Fri Feb 24 17:08:25 UTC 2017 - bwiedem...@suse.com
> +
> +- Add reproducible.patch to allow reproducible builds of various
> +  python packages like python-amqp
> +  Upstream: https://github.com/python/cpython/pull/296
> +
> +
> +@@ -0,0 +1,15 @@
> +Index: Python-2.7.13/Lib/py_compile.py
> +===
> +--- Python-2.7.13.orig/Lib/py_compile.py
>  Python-2.7.13/Lib/py_compile.py
> +@@ -108,6 +108,10 @@ def compile(file, cfile=None, dfile=None
> + timestamp = long(os.fstat(f.fileno()).st_mtime)
> + except AttributeError:
> + timestamp = long(os.stat(file).st_mtime)
> ++sde = os.environ.get('SOURCE_DATE_EPOCH')
> ++if sde and timestamp > int(sde):
> ++timestamp = int(sde)
> ++os.utime(file, (timestamp, timestamp))
> + codestring = f.read()
> + try:
> + codeobject = __builtin__.compile(codestring, dfile or file,'exec')
> diff --git a/meta/recipes-devtools/python/python_2.7.13.bb 
> b/meta/recipes-devtools/python/python_2.7.13.bb
> index 4ef9952..96c3ab2 100644
> --- a/meta/recipes-devtools/python/python_2.7.13.bb
> +++ b/meta/recipes-devtools/python/python_2.7.13.bb
> @@ -27,6 +27,7 @@ SRC_URI += "\
>file://use_sysroot_ncurses_instead_of_host.patch \
>file://add-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch \
>file://Don-t-use-getentropy-on-Linux.patch \
> +  file://reproducible.patch \
>  "
>  
>  S = "${WORKDIR}/Python-${PV}"
> -- 
> 2.7.4
> 


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

Re: [OE-core] ✗ patchtest: failure for Restructure python2 and python3 packaging system

[Alejandro Hernandez]

The failure is expected, since this patch modifies(removes) the python 
manifest,


and one of the things that I wanted to fix was exactly this, that 
submitting a patch to


the manifest shouldnt cause an issue, after this patch is applied this 
will no longer happen.



As for the series not applying, the patch does apply, the contrib branch 
hsalejandro/python_autopack_final


is baes on the latest master.


Regards,


Alejandro



On 08/17/2017 12:35 PM, Patchwork wrote:

== Series Details ==

Series: Restructure python2 and python3 packaging system
Revision: 1
URL   : https://patchwork.openembedded.org/series/8314/
State : failure

== Summary ==


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



* Issue Series cannot be parsed correctly due to malformed diff 
lines [test_mbox_format]
   Suggested fixCreate the series again using git-format-patch and ensure 
it can be applied using git am
   Diff line diff --git 
a/meta/recipes-devtools/python/python-native_2.7.13.bb 
b/meta/recipes-devtools/python/python-native_2.7.13.bb


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



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

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe



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

[OE-core] [PATCH] webkitgtk: Add a recommends on shared-mime-info.

[Carlos Alberto Lopez Perez]

 * without this package installed any WebKitGTK+ based browser
   will fail to correctly open html files (and other files)
   from disk (file:// URIs). It will open them as plain txt files.

Signed-off-by: Carlos Alberto Lopez Perez 
---
 meta/recipes-sato/webkit/webkitgtk_2.16.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
index 387965970e..df355d29ba 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
@@ -98,7 +98,7 @@ SECURITY_CFLAGS_append_aarch64 = " -fPIE"
 
 FILES_${PN} += 
"${libdir}/webkit2gtk-4.0/injected-bundle/libwebkit2gtkinjectedbundle.so"
 
-RRECOMMENDS_${PN} += "ca-certificates"
+RRECOMMENDS_${PN} += "ca-certificates shared-mime-info"
 
 # http://errors.yoctoproject.org/Errors/Details/20370/
 ARM_INSTRUCTION_SET_armv4 = "arm"
-- 
2.11.0

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

Re: [OE-core] [PATCH v3 10/11] kernel.bbclass: improve reproducibility

[Bystricky, Juro]

thanks for pointing this out, will fix it the way you suggested



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

[OE-core] [PATCH] report-error: provide distro identifier string in case of uninative build

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

Besides providing the NATIVELSBSTRING, include distro info when creating
the (json) error report. This information provides better info than the
standard 'universal*' string for uninative builds.

[YOCTO #11824]

Signed-off-by: Leonardo Sandoval 
---
 meta/classes/report-error.bbclass | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/classes/report-error.bbclass 
b/meta/classes/report-error.bbclass
index d6fdd364ad..1c55abfbf3 100644
--- a/meta/classes/report-error.bbclass
+++ b/meta/classes/report-error.bbclass
@@ -29,6 +29,13 @@ python errorreport_handler () {
 import json
 import codecs
 
+def nativelsb():
+nativelsbstr = e.data.getVar("NATIVELSBSTRING")
+# provide a bit more host info in case of uninative build
+if e.data.getVar('UNINATIVE_URL') != 'unset':
+return '/'.join([nativelsbstr, lsb_distro_identifier(e.data)])
+return nativelsbstr
+
 logpath = e.data.getVar('ERR_REPORT_DIR')
 datafile = os.path.join(logpath, "error-report.txt")
 
@@ -38,7 +45,7 @@ python errorreport_handler () {
 machine = e.data.getVar("MACHINE")
 data['machine'] = machine
 data['build_sys'] = e.data.getVar("BUILD_SYS")
-data['nativelsb'] = e.data.getVar("NATIVELSBSTRING")
+data['nativelsb'] = nativelsb()
 data['distro'] = e.data.getVar("DISTRO")
 data['target_sys'] = e.data.getVar("TARGET_SYS")
 data['failures'] = []
-- 
2.12.3

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

Re: [OE-core] [PATCH v2] image.bbclass: delete DATE variable too

[Stefan Agner]

On 2017-08-29 02:54, Stefan Agner wrote:
> From: Stefan Agner 
> 
> When creating a custom image which uses the DATE variable the basehash
> seems to change every day and lead to errors such as:
> ERROR: console-tdx-image-2.7.6-r0 do_image_customimg: Error executing
> a python function in exec_python_func() autogenerated:
> 
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:set_image_size(d)
> ...
> 
> Add DATE to the variables which should not get expanded early and to the
> vardepsexclude list for the image task.

Armin, this has been applied to master in between.

Is there a chance to get that also into pyro and morty?

--
Stefan


> 
> Signed-off-by: Stefan Agner 
> ---
> I am not that deep in OE usually and I am not sure if I miss something
> completely here... It seems to solve the issue for us though. Does that
> change sounds reasonable? Could it be done in the custom image class file?
> 
>  meta/classes/image.bbclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 2c1dc81..7949b46 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -437,6 +437,7 @@ python () {
>  # date/time values. It will get expanded at execution time.
>  # Similarly TMPDIR since otherwise we see QA stamp comparision 
> problems
>  localdata.delVar('DATETIME')
> +localdata.delVar('DATE')
>  localdata.delVar('TMPDIR')
>  
>  image_cmd = localdata.getVar("IMAGE_CMD")
> @@ -501,7 +502,7 @@ python () {
>  d.prependVarFlag(task, 'postfuncs', ' create_symlinks')
>  d.appendVarFlag(task, 'subimages', ' ' + ' '.join(subimages))
>  d.appendVarFlag(task, 'vardeps', ' ' + ' '.join(vardeps))
> -d.appendVarFlag(task, 'vardepsexclude', 'DATETIME')
> +d.appendVarFlag(task, 'vardepsexclude', 'DATETIME DATE')
>  
>  bb.debug(2, "Adding task %s before %s, after %s" % (task,
> 'do_image_complete', after))
>  bb.build.addtask(task, 'do_image_complete', after, d)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for Restructure python2 and python3 packaging system

[Patchwork]

== Series Details ==

Series: Restructure python2 and python3 packaging system
Revision: 1
URL   : https://patchwork.openembedded.org/series/8314/
State : failure

== Summary ==


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



* Issue Series cannot be parsed correctly due to malformed diff 
lines [test_mbox_format] 
  Suggested fixCreate the series again using git-format-patch and ensure it 
can be applied using git am
  Diff line diff --git 
a/meta/recipes-devtools/python/python-native_2.7.13.bb 
b/meta/recipes-devtools/python/python-native_2.7.13.bb


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



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

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] sign_rpm: Allow pkg signing by chunks through RPM_GPG_SIGN_CHUNK

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

Commit d58b1d196 moved from chunk to serial signing, but neither of both 
approaches
allowed the user to select the chunks size. This patch allows the user to select
a chunk size through RPM_GPG_SIGN_CHUNK defaulting to BB_NUMBER_THREADS, 
considered
a good default. Indirectly, this change reduces the number of processes spawn
to number-of-packages/RPM_GPG_SIGN_CHUNK.

Signed-off-by: Leonardo Sandoval 
---
 meta/classes/sign_rpm.bbclass | 7 ++-
 meta/lib/oe/gpg_sign.py   | 8 
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/meta/classes/sign_rpm.bbclass b/meta/classes/sign_rpm.bbclass
index c49406c74d..6796780ee4 100644
--- a/meta/classes/sign_rpm.bbclass
+++ b/meta/classes/sign_rpm.bbclass
@@ -19,9 +19,12 @@
 # GPG_BIN
 #   Optional variable for specifying the gpg binary/wrapper to use for
 #   signing.
+# RPM_GPG_SIGN_CHUNK
+#   Optional variable indicating the number of packages used per gpg
+#   invocation
 # GPG_PATH
 #   Optional variable for specifying the gnupg "home" directory:
-#
+
 inherit sanity
 
 RPM_SIGN_PACKAGES='1'
@@ -29,6 +32,7 @@ RPM_SIGN_FILES ?= '0'
 RPM_GPG_BACKEND ?= 'local'
 # SHA-256 is used by default
 RPM_FILE_CHECKSUM_DIGEST ?= '8'
+RPM_GPG_SIGN_CHUNK ?= "${BB_NUMBER_THREADS}"
 
 
 python () {
@@ -56,6 +60,7 @@ python sign_rpm () {
  d.getVar('RPM_GPG_NAME'),
  d.getVar('RPM_GPG_PASSPHRASE'),
  d.getVar('RPM_FILE_CHECKSUM_DIGEST'),
+ int(d.getVar('RPM_GPG_SIGN_CHUNK')),
  d.getVar('RPM_FSK_PATH'),
  d.getVar('RPM_FSK_PASSWORD'))
 }
diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 5c7985a856..008478dfeb 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -27,7 +27,7 @@ class LocalSigner(object):
 raise bb.build.FuncFailed('Failed to export gpg public key (%s): 
%s' %
   (keyid, output))
 
-def sign_rpms(self, files, keyid, passphrase, digest, fsk=None, 
fsk_password=None):
+def sign_rpms(self, files, keyid, passphrase, digest, sign_chunk, 
fsk=None, fsk_password=None):
 """Sign RPM files"""
 
 cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
@@ -45,9 +45,9 @@ class LocalSigner(object):
 if fsk_password:
 cmd += "--define '_file_signing_key_password %s' " % 
fsk_password
 
-# Sign packages
-for f in files:
-status, output = oe.utils.getstatusoutput(cmd + ' ' + f)
+# Sign in chunks
+for i in range(0, len(files), sign_chunk):
+status, output = oe.utils.getstatusoutput(cmd + ' 
'.join(files[i:i+sign_chunk]))
 if status:
 raise bb.build.FuncFailed("Failed to sign RPM packages: %s" % 
output)
 
-- 
2.12.3

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

[OE-core] [PATCH 2/3] python3: fix RDEPENDS on several recipes, due to non-existent python3 packages

[Alejandro Hernandez]

Signed-off-by: Alejandro Hernandez 
---
 meta/recipes-core/libxml/libxml2_2.9.4.bb  | 2 +-
 meta/recipes-devtools/bootchart2/bootchart2_0.14.8.bb  | 2 +-
 meta/recipes-devtools/dnf/dnf_2.6.3.bb | 4 ++--
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc   | 4 ++--
 meta/recipes-devtools/opkg-utils/opkg-utils_0.3.5.bb   | 2 +-
 meta/recipes-devtools/python-numpy/python3-numpy_1.13.1.bb | 2 --
 meta/recipes-devtools/python/python3-async_0.6.2.bb| 2 +-
 meta/recipes-devtools/python/python3-git_2.1.5.bb  | 2 +-
 meta/recipes-devtools/python/python3-gitdb_0.6.4.bb| 2 +-
 meta/recipes-devtools/python/python3-pygobject_3.24.1.bb   | 2 +-
 meta/recipes-devtools/python/python3-setuptools_36.2.7.bb  | 3 ---
 meta/recipes-devtools/python/python3-smmap_0.9.0.bb| 2 +-
 meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb| 2 +-
 meta/recipes-graphics/piglit/piglit_git.bb | 4 ++--
 meta/recipes-rt/rt-tests/hwlatdetect_1.1.bb| 2 +-
 meta/recipes-rt/rt-tests/rt-tests_1.1.bb   | 2 +-
 16 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/meta/recipes-core/libxml/libxml2_2.9.4.bb 
b/meta/recipes-core/libxml/libxml2_2.9.4.bb
index f67c47d29c1..5a81fa1403a 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.4.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.4.bb
@@ -48,7 +48,7 @@ inherit autotools pkgconfig binconfig-disabled ptest
 
 inherit ${@bb.utils.contains('PACKAGECONFIG', 'python', 'python3native', '', 
d)}
 
-RDEPENDS_${PN}-ptest += "make ${@bb.utils.contains('PACKAGECONFIG', 'python', 
'libgcc python3-core python3-argparse python3-logging python3-shell 
python3-signal python3-stringold python3-threading python3-unittest 
${PN}-python', '', d)}"
+RDEPENDS_${PN}-ptest += "make ${@bb.utils.contains('PACKAGECONFIG', 'python', 
'libgcc python3-core python3-logging python3-shell  python3-stringold 
python3-threading python3-unittest ${PN}-python', '', d)}"
 
 RDEPENDS_${PN}-python += "${@bb.utils.contains('PACKAGECONFIG', 'python', 
'python3-core', '', d)}"
 
diff --git a/meta/recipes-devtools/bootchart2/bootchart2_0.14.8.bb 
b/meta/recipes-devtools/bootchart2/bootchart2_0.14.8.bb
index 4f01734bb0b..fa1ce29bdc9 100644
--- a/meta/recipes-devtools/bootchart2/bootchart2_0.14.8.bb
+++ b/meta/recipes-devtools/bootchart2/bootchart2_0.14.8.bb
@@ -139,7 +139,7 @@ do_install () {
 
 PACKAGES =+ "pybootchartgui"
 FILES_pybootchartgui += "${PYTHON_SITEPACKAGES_DIR}/pybootchartgui 
${bindir}/pybootchartgui"
-RDEPENDS_pybootchartgui = "python3-pycairo python3-compression python3-image 
python3-textutils python3-shell python3-compression python3-codecs"
+RDEPENDS_pybootchartgui = "python3-pycairo python3-compression python3-image 
python3-shell python3-compression python3-codecs"
 RDEPENDS_${PN}_class-target += "${@bb.utils.contains('DISTRO_FEATURES', 
'sysvinit', 'sysvinit-pidof', 'procps', d)}"
 RDEPENDS_${PN}_class-target += "lsb"
 DEPENDS_append_class-native = " python3-pycairo-native"
diff --git a/meta/recipes-devtools/dnf/dnf_2.6.3.bb 
b/meta/recipes-devtools/dnf/dnf_2.6.3.bb
index 51072901e4d..74cb25feb90 100644
--- a/meta/recipes-devtools/dnf/dnf_2.6.3.bb
+++ b/meta/recipes-devtools/dnf/dnf_2.6.3.bb
@@ -25,8 +25,8 @@ DEPENDS += "libdnf librepo libcomps python3-iniparse"
 EXTRA_OECMAKE = " -DWITH_MAN=0 -DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} 
-DPYTHON_DESIRED=3"
 
 BBCLASSEXTEND = "native nativesdk"
-RDEPENDS_${PN}_class-target += "python3-core python3-codecs python3-netclient 
python3-email python3-threading python3-distutils librepo python3-shell 
python3-subprocess libcomps libdnf python3-sqlite3 python3-compression 
python3-rpm python3-iniparse python3-json python3-importlib python3-curses 
python3-argparse python3-misc python3-gpg"
-# Recommend gnupg so that GPG signature check on repository metadata is 
possible
+
+RDEPENDS_${PN}_class-target += "python3-core python3-codecs python3-netclient 
python3-email python3-threading python3-distutils librepo python3-shell 
libcomps libdnf python3-sqlite3 python3-compression python3-rpm 
python3-iniparse python3-json python3-curses python3-misc python3-gpg"
 RRECOMMENDS_${PN}_class-target += "gnupg"
 
 # Create a symlink called 'dnf' as 'make install' does not do it, but
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc 
b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
index 3ff19895388..4fc6747d9da 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
@@ -13,9 +13,9 @@ GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'"
 # Overrides PACKAGECONFIG variables in gdb-common.inc
 PACKAGECONFIG ??= "python readline"
 PACKAGECONFIG[python] = 
"--with-python=${WORKDIR}/python,--without-python,nativesdk-python3, \
- nativesdk-python3-core nativesdk-python3-lang 
nativesdk-python3-re \
+   

[OE-core] [PATCH 3/3] python3: Restructure python3 packaging and replace it with autopackaging

[Alejandro Hernandez]

See previous commit (python2 version) for more info.

Old manifest file had several issues:
 - Its unorganized and hard to read and understand it for an average
   human being.
 - Git complains every single time a patch is submitted to the manifest,
   since it violates some of its guidelines for patches.
 - It changes or may change with every release of python, its impossible
   to know if the required files for a certain package have changed (it
   could have more or less dependencies), the only way of doing so would be
   to install and test them all one by one, and even then we wouldnt know
   if they require less dependencies, we would just know if an extra
   dependency is required since it would complain, lets face it, this isnt
   feasible.
 - The same thing happens for new packages, if someone wants to add a new
   package, its dependencies need to be checked manually one by one.

Features/Fixes:
 - A new manifest format is used (JSON), easy to read and understand.
   This file is parsed by the python recipe and python packages
   read from here are passed directly to bitbake during parsing time.
 - It provides an automatic manifest creation task (explained on previous
   commit), which automagically checks for every package dependencies and
   adds them to the new manifest, hence we will have on each package
   exactly what that package needs to be run, providing finer granularity.
  - Dependencies are also checked automagically for new packages
   (explained on previous commit).

This patch differs has the same features as the python2's version
but it differs in the following ways:
 - Python3 handles precompiled bytecode files  (*.pyc) differently.
   for this reason and since we are cross compiling, wildcards couldnt be
   avoided on python3 (See PEP #3147 [1]).
   Both the manifest and the manifest creation script handle this
   differently, the manifest for python3 has an extra field for cached
   files, which is how it lets the user install the cached files or not
   via : INCLUDE_PYCS = "1" on their local.conf.
 - Shared libs nomenclature also changed on python3, so again, we use
   wildcards to deal with this issue ( See PEP #3149 [2]):
 - Fixes python3 manifest, python3-core should be base and everything
   should depend on it, hence several packages were deleted:
   python3-enum, re, gdbm, subprocess, signal, readline.
 - Sitecustomize was fixed since encoding was deprecated.
 - Fixes [YOCTO #11513] while were at it.

Signed-off-by: Alejandro Hernandez 
---
 .../python/python-3.5-manifest.inc |  283 -
 .../python/python-native-3.5-manifest.inc  |   10 -
 .../python/python3-native_3.5.3.bb |   10 +-
 .../python/python3/create_manifest3.py |  318 ++
 .../python/python3/get_module_deps3.py |  145 +++
 .../python/python3/python3-manifest.json   | 1107 
 meta/recipes-devtools/python/python3_3.5.3.bb  |   90 +-
 scripts/contrib/python/generate-manifest-3.5.py|  433 
 8 files changed, 1664 insertions(+), 732 deletions(-)
 delete mode 100644 meta/recipes-devtools/python/python-3.5-manifest.inc
 delete mode 100644 meta/recipes-devtools/python/python-native-3.5-manifest.inc
 create mode 100644 meta/recipes-devtools/python/python3/create_manifest3.py
 create mode 100644 meta/recipes-devtools/python/python3/get_module_deps3.py
 create mode 100644 meta/recipes-devtools/python/python3/python3-manifest.json
 delete mode 100755 scripts/contrib/python/generate-manifest-3.5.py

diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
deleted file mode 100644
index 0260e87e75f..000
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ /dev/null
@@ -1,283 +0,0 @@
-
-# WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
-# Generator: 'scripts/contrib/python/generate-manifest-3.5.py' Version 
20140131 (C) 2002-2010 Michael 'Mickey' Lauer 
-
- 
-
-PROVIDES+="${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio ${PN}-codecs 
${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes 
${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib 
${PN}-distutils ${PN}-distutils-staticdev ${PN}-doctest ${PN}-email ${PN}-enum 
${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib 
${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math 
${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient ${PN}-netserver 
${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc 
${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource ${PN}-selectors 
${PN}-shell ${PN}-signal ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests 
${PN}-textutils ${PN}-threading ${PN}-tkinter 

[OE-core] [PATCH 1/3] python: Restructure python packaging and replace it with autopackaging

[Alejandro Hernandez]

The reason we have a manifest file for python is that our goal is to
keep python-core as small as posible and add other python packages only
when the user needs them, hence why we split upstream python into several
packages.

Although our manifest file has several issues:
 - Its unorganized and hard to read and understand it for an average
   human being.
 - Git complains every single time a patch is submitted to the manifest,
   since it violates some of its guidelines for patches.
 - It changes or may change with every release of python, its impossible
   to know if the required files for a certain package have changed
   (it could have more or less dependencies), the only way of doing so
   would be to install and test them all one by one, and even then we
   wouldnt know if they require less dependencies, we would just know if
   an extra dependency is required since it would complain, lets face it,
   this isnt feasible.
 - The same thing happens for new packages, if someone wants to add a
   new package, its dependencies need to be checked manually one by one.

This patch fixes those issues, while adding some additional features.

Features/Fixes:

 - A new manifest format is used (JSON), easy to read and understand.
   This file is parsed by the python recipe and python packages read
   from here are passed directly to bitbake during parsing time.
 - It provides an automatic manifest creation task (explained below),
   which automagically checks for every package dependencies and adds
   them to the new manifest, hence we will have on each package exactly
   what that package needs to be run, providing finer granularity.
 - Dependencies are also checked automagically for new packages (explained 
below).
 - Fixes the manifest in the following ways:
   * python-core should be base and all packages should depend on it ,
 fixes lang, string, codecs, etc.
   * Fixes packages with repeated files (e.g. bssdb and db, or
 netclient and mime, and many others).
 - Removes the manifest from the python-native recipe (Why was it there
   in the first place?, native recipes do not get split).
 - It creates a solution for users that want precompiled bytecode files
   (*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to
   include such files, some argument they get faster boot time, even when the
   files would be created on their first run?, but they also sometimes give a
   magic number error and take up space, so we leave it to the user to
   decide if they want them or not.
 - Fixes python-core for dependencies, e.g.
   When python is run on an image, it TRIES to import everything it needs,
   but it doesnt necessarily fails when it doesnt find something, so even if
   we didnt know, we had errors like (trimmed on purpose):
   # trying /usr/lib/python2.7/_locale.so
   # trying /usr/lib/python2.7/lib-dynload/_locale.so
   # trying /usr/lib/python2.7/_sysconfigdata.so

   while it didnt complain about _locale it should have imported it,
   after creating a new manifest with the automated script we get:

   # trying /usr/lib/python2.7/lib-dynload/_locale.so
   dlopen("/usr/lib/python2.7/lib-dynload/_locale.so", 2);
   import _locale # dynamically loaded from 
/usr/lib/python2.7/lib-dynload/_locale.so

How to use (after a new release of python, or maybe before every OE
release):
 - A new task called create_manifest was added to the python package,
   which may be invoked via:

 $ bitbake python -c create_manifest

 This task runs a script on native python on our HOST system, this
 script is called create_manifest.py and it in a very simplistic way
 it does the following:

 1. Reads the JSON manifest file and creates a dictionary data structure
with all of our python packages, their FILES, RDEPENDS and SUMMARY.
 2. Loops through all of them and runs them asynchronously, determining
every dependency that they have.
 3. These module dependencies are then handled, to be able to know which
packages contain those files and which should RDEPEND on one another.
 4. The data structure that comes out of this, is then used to create a new
manifest file which is automatically copied onto the user's python
directory replacing the old one.

 Create_manifest script features:
 - Handles modules which dont exist anymore (new release for example).
 - Handles modules that are builtin.
 - Deals with modules which were not compiled (e.g. bsddb or ossaudiodev)
 - This method works for both python modules and shared libraries used
   by python.
 - Deals with packages which include folders.
 - Deals with packages which include FILES with a wildcard.
 - The manifest can be constructed on a multilib environment as well.

How to add a new package:
 - If a user wants to add a new package all that has to be done is
   modify the python2-manifest.json file, and add the required file(s)
   to the FILES list, the script should handle all the rest.
   Real example:
   "webbrowser": {
   "files": 

[OE-core] [PATCH 0/3] Restructure python2 and python3 packaging system

[Alejandro Hernandez]

The reason we have a manifest file for python is that our goal is to
keep python-core as small as posible and add other python packages only
when the user needs them, hence why we split upstream python into several
packages.

There are many problems with our current implementation of the manifest file,
this patch tries to deal with all of them along with adding several other
features.

This patch adds a new task to python recipes, which is meant to create a new
manifest file every release.

$ bitbake python -c create_manifest  

In a very simplistic way what this does is: 
 
Launch python and see specifically what is required for it to run at a minimum  
 

 
Go through the python-manifest file and launch a separate task for every single 
 
one of the files on each package, this task will check what was required for 
that
specific module to run, these modules will be called dependencies.  
 
The output of such task will be a list of the modules or dependencies that were 
 
found for that file.
 

 
Such output will be parsed by this script, we will look for each dependency on 
the   
manifest and if we find that another package already includes it, then we will 
add   
that package as an RDEPENDS to the package we are currently checking; in case 
we dont
find the current dependency on any other package we will add it to the current 
package   
as part of FILES.   
 

 
This way we will create a new manifest from the data structure that was built 
during 
this process, ont this new manifest each package will contain specifically only 
 
what it needs to run, providing us with finer granularity.

There are some caveats which we try to deal with, such as repeated files on 
different
packages, packages that include folders, wildcards, and special packages.   
 
Its also important to note that this method only works for python files, and 
shared  
libraries. Static libraries, header files and binaries need to be dealt with 
manually.


Using this script a new package can easily be added like this:
 - If a user wants to add a new package all that has to be done is
   modify the python2-manifest.json file, and add the required file(s)
   to the FILES list, the script should handle all the rest.
   Real example:
   "webbrowser": {
   "files": ["${libdir}/python2.7/lib-dynload/webbrowser.py"],
   "rdepends": [],
   "summary": "Python Web browser support"}

 Run bitbake python -c create_manifest and the resulting manifest
 should  be completed after a few seconds, showing something like:
   "webbrowser": {
  "files": ["${libdir}/python2.7/webbrowser.py"],
  "rdepends": ["core","fcntl","io","pickle","shell","subprocess"],
  "summary": "Python Web browser support"}

It also fixes several errors we didnt even know we had:
 - Fixes python-core for dependencies, e.g.
   When python is run on an image, it TRIES to import everything it needs,
   but it doesnt necessarily fails when it doesnt find something, so even if
   we didnt know, we had errors like (trimmed on purpose):
   # trying /usr/lib/python2.7/_locale.so
   # trying /usr/lib/python2.7/lib-dynload/_locale.so
   # trying /usr/lib/python2.7/_sysconfigdata.so

   while it didnt complain about _locale it should have imported it,
   after creating a new manifest with the automated script we get:

   # trying 

[OE-core] [PATCH] systemd-boot: Move adjacent to systemd

[Khem Raj]

We always forget to upgrade it when systemd is upgraded, keeping it
next to systemd will be an easy reminder to upgrade this recipe along
with systemd

Define EFI_CC, so far it has been using detection mechanism which
worked with gcc but falls back to native gcc when using non-gcc compiler
as default system compiler e.g. clang

Signed-off-by: Khem Raj 
---
 ...pper-instead-of-looking-for-relative-opti.patch | 40 --
 .../systemd/systemd-boot_234.bb}   |  6 ++--
 2 files changed, 4 insertions(+), 42 deletions(-)
 delete mode 100644 
meta/recipes-bsp/systemd-boot/files/0001-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
 rename meta/{recipes-bsp/systemd-boot/systemd-boot_232.bb => 
recipes-core/systemd/systemd-boot_234.bb} (85%)

diff --git 
a/meta/recipes-bsp/systemd-boot/files/0001-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
 
b/meta/recipes-bsp/systemd-boot/files/0001-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
deleted file mode 100644
index bc92db7468..00
--- 
a/meta/recipes-bsp/systemd-boot/files/0001-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From a3482c91642cf568b3ac27fa6c0cb3c6b30669b7 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 9 Nov 2016 19:32:14 -0800
-Subject: [PATCH 07/19] use lnr wrapper instead of looking for --relative
- option for ln
-
-Upstream-Status: Inappropriate [OE-Specific]
-
-Signed-off-by: Khem Raj 

- Makefile.am  | 2 +-
- configure.ac | 2 --
- 2 files changed, 1 insertion(+), 3 deletions(-)
-
-Index: git/Makefile.am
-===
 git.orig/Makefile.am
-+++ git/Makefile.am
-@@ -320,7 +320,7 @@ define install-relative-aliases
-   while [ -n "$$1" ]; do \
-   $(MKDIR_P) `dirname $(DESTDIR)$$dir/$$2` && \
-   rm -f $(DESTDIR)$$dir/$$2 && \
--  $(LN_S) --relative $(DESTDIR)$$1 $(DESTDIR)$$dir/$$2 && \
-+  lnr $(DESTDIR)$$1 $(DESTDIR)$$dir/$$2 && \
-   shift 2 || exit $$?; \
-   done
- endef
-Index: git/configure.ac
-===
 git.orig/configure.ac
-+++ git/configure.ac
-@@ -110,8 +110,6 @@ AC_PATH_PROG([SULOGIN], [sulogin], [/usr
- AC_PATH_PROG([MOUNT_PATH], [mount], [/usr/bin/mount], [$PATH:/usr/sbin:/sbin])
- AC_PATH_PROG([UMOUNT_PATH], [umount], [/usr/bin/umount], 
[$PATH:/usr/sbin:/sbin])
- 
--AS_IF([! ln --relative --help > /dev/null 2>&1], [AC_MSG_ERROR([*** ln 
doesn't support --relative ***])])
--
- M4_DEFINES=
- 
- AC_CHECK_TOOL(OBJCOPY, objcopy)
diff --git a/meta/recipes-bsp/systemd-boot/systemd-boot_232.bb 
b/meta/recipes-core/systemd/systemd-boot_234.bb
similarity index 85%
rename from meta/recipes-bsp/systemd-boot/systemd-boot_232.bb
rename to meta/recipes-core/systemd/systemd-boot_234.bb
index 0471ce246b..ed55e537eb 100644
--- a/meta/recipes-bsp/systemd-boot/systemd-boot_232.bb
+++ b/meta/recipes-core/systemd/systemd-boot_234.bb
@@ -1,12 +1,14 @@
-require recipes-core/systemd/systemd.inc
+require systemd.inc
+FILESEXTRAPATHS =. "${FILE_DIRNAME}/systemd:"
 
 DEPENDS = "intltool-native libcap util-linux gnu-efi gperf-native"
 
-SRC_URI += 
"file://0001-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch"
+SRC_URI += 
"file://0007-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch"
 
 inherit autotools pkgconfig gettext
 inherit deploy
 
+export EFI_CC="${CC}"
 # Man pages are packaged through the main systemd recipe
 EXTRA_OECONF = " --enable-gnuefi \
  --with-efi-includedir=${STAGING_INCDIR} \
-- 
2.14.1

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

Re: [OE-core] [PATCH] ca-certificates: prevent executing update-ca-certificates from host system

[Richard Purdie]

On Thu, 2017-08-17 at 16:44 +0200, Andrej Valek wrote:
> Signed-off-by: Andrej Valek 
> ---
>  meta/recipes-support/ca-certificates/ca-certificates_20161130.bb | 2
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-support/ca-certificates/ca-
> certificates_20161130.bb b/meta/recipes-support/ca-certificates/ca-
> certificates_20161130.bb
> index 9a80f43..771714d 100644
> --- a/meta/recipes-support/ca-certificates/ca-
> certificates_20161130.bb
> +++ b/meta/recipes-support/ca-certificates/ca-
> certificates_20161130.bb
> @@ -72,7 +72,7 @@ CONFFILES_${PN} += "${sysconfdir}/ca-
> certificates.conf"
>  # Postinsts don't seem to be run for nativesdk packages when
> populating SDKs.
>  CONFFILES_${PN}_append_class-nativesdk = "
> ${sysconfdir}/ssl/certs/ca-certificates.crt"
>  do_install_append_class-nativesdk () {
> -SYSROOT="${D}${SDKPATHNATIVE}" update-ca-certificates
> +SYSROOT="${D}${SDKPATHNATIVE}" ${D}${sbindir}/update-ca-
> certificates
>  }
>  
>  do_install_append_class-native () {

Since the HOSTTOOLS changes, this should no longer be needed?

Cheers,

Richard

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

Re: [OE-core] [PATCH v3 10/11] kernel.bbclass: improve reproducibility

[Christopher Larson]

On Wed, Aug 9, 2017 at 10:48 AM, Juro Bystricky 
wrote:

> Several tweaks to improve reproducibility:
>
> 1. If BUILD_REPRODUCIBLE_BINARIES == 1, set KBUILD_BUILD_TIMESTAMP
> to a reproducible value. This is either a non-zero SOURCE_DATE_EPOCH, or
> the
> value obtained from top entry of GIT repo, or (if there is no GIT repo)
> fallback to REPRODUCIBLE_TIMESTAMP_ROOTFS as the last resort.
> Also export KCONFIG_NOTIMESTAMP=1.
>
> 2. When compressing vmlinux.gz, use gzip "-n" option
>
> 3. Kernel and kernel modules contain hard coded paths referencing the host
> build system. This is usually because the source code contains __FILE__
> at some place. This prevents binary reproducibility. However, some
> compilers
> allow remapping of the __FILE__ value. If we detect the compiler is capable
> of doing this, we replace the source path $(S) part of __FILE__ by a
> string "/kernel-source".
> For example:
>
> ​/data/master/build/tmp/work-shared/qemux86/kernel-source/
> drivers/media/v4l2-core/videobuf2-core.​c
>
> will be replaced by a reproducible value:
>
> /kernel-source/drivers/media/v4l2-core/videobuf2-core.c.
>
> Signed-off-by: Juro Bystricky 
> ---
>  meta/classes/kernel.bbclass | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index ce2cab6..2a76554 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -255,8 +255,39 @@ python do_devshell_prepend () {
>
>  addtask bundle_initramfs after do_install before do_deploy
>
> +get_cc_option () {
> +   # Check if KERNEL_CC supports the option "file-prefix-map".
> +   # This option allows us to build images with __FILE__
> values that do not
> +   # contain the host build path.
> +   cc_option_supported=`${KERNEL_CC} -Q --help=joined | grep
> ffile-prefix-map`
>

This fails the do_compile task if ffile-prefix-map isn’t found in the help
output, resulting in build failures with an external toolchain, for
example. This function doesn’t work the way you intended at all. It also
fails to quote things properly, uses the old `` syntax rather than $(), and
relies on grep output rather than grep exit codes.

At a minimum we need a “|| true” or “|| :” on the end of the
cc_option_supported= line. I don’t see why this doesn’t just do this,
instead, though:

if ${KERNEL_CC} -Q —help=joined | grep -q

Re: [OE-core] Chaining compression support fixes for morty / pyro

[akuster808]

On 07/31/2017 06:59 AM, Tom Rini wrote:

Hi Armin,

The following changes in master are relevant to both morty and pyro:


In stagging for morty. will do pyro shortly.


commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703
Author: Tom Rini 
Date:   Fri Jul 21 18:06:33 2017 -0400

 image.bbclass: Correct chaining compression support


Needed a little fixup

thanks,
Armin


commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d
Author: Tom Rini 
Date:   Tue Jul 25 15:58:09 2017 -0400

 image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

And fix the problem where you cannot make arbitrary combinations of say
"ext4", "u-boot" and "xz" images.  In the interest of full disclosure,
it is entirely possible that there are image types introduces in other
layers that have the same problem that the "u-boot" type had which lead
to 46bc438374de being done in the first place, which is to say a new
IMAGE_CMD that also cleaned up the intermediate files on its own.  This
may make this too risky to pull into stable branches and that's fine.
Thanks for your consideration!



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

Re: [OE-core] [PATCH v2] devtool/copy_buildsystem: adds meta-skeleton layer in the eSDK installation.

[Juan Manuel]

On 17/08/17 03:59, Paul Eggleton wrote:

On Thursday, 17 August 2017 7:36:14 PM NZST Richard Purdie wrote:

On Wed, 2017-08-16 at 18:36 -0700, juan.m.cruz.alca...@linux.intel.com
wrote:

From: Juan M Cruz Alcaraz 

The eSDK installation requires the meta-skeleton layer.
The build system might use the meta-skeleton recipes as layout
to create custom recipes. An example is the recipetool script
that uses the meta-skeleton kernel recipe when creating a custom
kernel recipe.

[YOCTO #11102]

Signed-off-by: Juan M Cruz Alcaraz 
---
  meta/lib/oe/copy_buildsystem.py | 8 
  1 file changed, 8 insertions(+)

Failed to build on the autobuilder I'm afraid:

https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/1216/

steps/BuildImages_2/logs/stdio

Right, the assumption that the first part will be "poky/" is probably the
issue here. I suspect you will have to step through the list and remove
anything that ends with '/meta-skeleton'.

Certainly that is the problem. I'll fix and send back.


Cheers,
Paul




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

Re: [OE-core] [PATCH 1/3] python: Restructure python packaging and replace it with autopackaging

[Alejandro Hernandez]

Hey Andreas,


On 08/17/2017 09:14 AM, Andreas Oberritter wrote:

On Thu, 17 Aug 2017 03:24:23 -0700
Alejandro Hernandez  wrote:


  - It creates a solution for users that want precompiled bytecode files
(*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to
include such files, some argument they get faster boot time, even when the
files would be created on their first run?, but they also sometimes give a
magic number error and take up space, so we leave it to the user to
decide if they want them or not.

A serious problem with not shipping precompiled pyc and/or pyo files is that,
once generated on first run, package managers won't uninstall them.

This can cause many undesired effects, because python programs will still be
able to import these files, but dependencies like graphics or shared libraries
may have been deleted by the package manager.

Also, not being able to uninstall something is bad on its own.

So, if anything, I believe INCLUDE_PYCS = "1" would be the only sane default,
unless no package management was involved at all.

And no read-only filesystem, for what it's worth.

Interesting, I didn't know that happened, sounds like a fair argument,
I will make sure to set INCLUDE_PYCS = "1" by default to avoid problems
like this, and let the user set it to 0 if thats what they want.


Best regards,
Andreas

P.S.: I didn't see patches 2 and 3. Is it just an incorrect subject?

Yes, there's 2 other patches, which are used for python3, but somehow
I forgot to send them, it was 4 am my apologies, will send them in a bit.

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

[OE-core] [PATCH] ca-certificates: prevent executing update-ca-certificates from host system

[Andrej Valek]

Signed-off-by: Andrej Valek 
---
 meta/recipes-support/ca-certificates/ca-certificates_20161130.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb 
b/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
index 9a80f43..771714d 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
@@ -72,7 +72,7 @@ CONFFILES_${PN} += "${sysconfdir}/ca-certificates.conf"
 # Postinsts don't seem to be run for nativesdk packages when populating SDKs.
 CONFFILES_${PN}_append_class-nativesdk = " 
${sysconfdir}/ssl/certs/ca-certificates.crt"
 do_install_append_class-nativesdk () {
-SYSROOT="${D}${SDKPATHNATIVE}" update-ca-certificates
+SYSROOT="${D}${SDKPATHNATIVE}" ${D}${sbindir}/update-ca-certificates
 }
 
 do_install_append_class-native () {
-- 
2.1.4

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

Re: [OE-core] [PATCH] gpg_sign: perform rpm signing serially

[Leonardo Sandoval]

On Thu, 2017-08-17 at 10:50 +0300, Markus Lehtonen wrote:
> Hi,
> 
> I quickly run some tests on a Xeon server, using glibc-locale as the recipe 
> to build.
> 100: 154s 
> 10: 162s (+5%)
> 1: 234s (+51%)

What I did to measure parallel versus serial is to run the corresponding
selftest (signing.Signing.test_signing_packages) several times for
chucks of 100, 20, 10 and 1. 

Here are the results (Xeon machine also)

100:
- Ran 1 test in 51.857s
- Ran 1 test in 52.148s
- Ran 1 test in 52.048s
- Ran 1 test in 52.397s

20:

- Ran 1 test in 54.068s
- Ran 1 test in 67.295s
- Ran 1 test in 52.608s
- Ran 1 test in 51.948s
- Ran 1 test in 53.283s

10

- Ran 1 test in 55.178s
- Ran 1 test in 56.468s
- Ran 1 test in 52.735s
- Ran 1 test in 53.530s
- Ran 1 test in 53.064s

1:
- Ran 1 test in 52.604s
- Ran 1 test in 53.211s
- Ran 1 test in 53.020s
- Ran 1 test in 53.017s
- Ran 1 test in 53.029s


so at least at selftest level, there is not such an perf penalty as you
observed. This is the test involved:


@OETestID(1362)
def test_signing_packages(self):

""" 

   
Summary: Test that packages can be signed in the package
feed

  
Expected:Package should be signed with the correct
key 


Expected:Images can be created from signed packages  





> 
> Even if signing is not parallel, the difference may be explained by the 
> number of rpm processes that get spawned. I would drop the factor to 10 or 
> use BB_NUMBER_THREADS as Andre suggested in another email.
>   - Markus
> 
> 
> 
> On 16/08/2017, 19.00, "Leonardo Sandoval" 
>  wrote:
> 
> On Wed, 2017-08-16 at 15:28 +0300, Markus Lehtonen wrote:
> > I agree. I don't see reason for dropping parallelism completely. There 
> is a real gain when running on beefier machines. Making it configurable would 
> probably be best. Or just drop it to a saner value, like 20 or 10.
> >- Markus
> > 
> 
> I ran some tests with 100, 20 and 1 and I saw (I can rerun and provide
> times) no difference on times. gpg may be intrinsically serial so
> passing 1 or N files wont make much difference in type. The only gain
> when using file chunks is that one one process is launched.
> 
> I the other hand, I tried using multiprocessing.Pool, but failed
> miserably due to file looking reasons.
> 
> 
> 
> > On 16/08/2017, 2.53, "Mark Hatle" 
>  mark.ha...@windriver.com> wrote:
> > 
> > It would probably be better if this was configurable with a 'safe' 
> default.
> > 
> > Moving from parallel to single will greatly affect the overall 
> performance on
> > larger build machines (lots of memory and cores) that can handle 
> the load vs a
> > typical development machine.
> > 
> > --Mark
> > 
> > On 8/15/17 4:40 PM, leonardo.sandoval.gonza...@linux.intel.com 
> wrote:
> > > From: Leonardo Sandoval 
> 
> > > 
> > > gpg signing in file batches (which was default to 100) is a 
> memory expensive
> > > computation, causing trouble in some host machines (even on 
> production AB
> > > as seen on the bugzilla ID). Also, in terms of performance, there 
> is no real
> > > gain when rpm signing is done in batches. Considering the latter 
> issues, perform the
> > > rpm signing serially.
> > > 
> > > Log showing errors observed recently at AB workers:
> > > 
> > > | gpg: signing failed: Cannot allocate memory
> > > | gpg: signing failed: Cannot allocate memory
> > > | error: gpg exec failed (2)
> > > | 
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/core2-64-poky-linux/base-passwd/3.5.29-r0/deploy-rpms/core2_64/base-passwd-dev-3.5.29-r0.core2_64.rpm:
> > > 
> > > [YOCTO #11914]
> > > 
> > > Signed-off-by: Leonardo Sandoval 
> 
> > > ---
> > >  meta/lib/oe/gpg_sign.py | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
> > > index 

Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on Pyro

[Mark Hatle]

On 8/17/17 8:01 AM, Peter Kjellerstedt wrote:
>> -Original Message-
>> From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com]
>> Sent: den 17 augusti 2017 12:53
>> To: Mark Hatle ; Richard Purdie
>> ; openembedded-
>> c...@lists.openembedded.org
>> Cc: Peter Kjellerstedt 
>> Subject: Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on
>> Pyro
>>
>> On 08/16/2017 06:37 PM, Mark Hatle wrote:
>>> Are there any examples?  I was looking there and simply didn't see
>>> any.  I saw the packaging for instance exercised python interfaces, 
>>> version comparison tools, etc.. but nothing that built a 
>>> recipe/package and then verified the contents were 'correct'.
>>>
>>> Ideally the test would be to fabricate something with a known set 
>>> of file dependencies, produce a package from it and then verify 
>>> that the package properly included those dependencies.
>>>
>>> I had looked at just picking some random library out of the deploy
>>> directory, and doing a pattern search on it's provides.. but I'm 
>>> not sure that type of test would be very robust.
>>
>> How was this regression discovered in the first place? I guess that
>> some recipe used to build without error with rpm5, and stopped 
>> building with rpm4. This is what you could test for: isolate the 
>> problematic bit, remove everything else, and write a simple recipe(s) 
>> that can be placed into meta-selftest. Then simply build those from 
>> the selftest; if they build without error, you don't need to do more 
>> sophisticated checks.
>>
>> Alex
> 
> The problem we have, which caused me to look into this, is:
> 
> We unfortunately have a lot of unversioned libraries, e.g., 
> "libfoo.so" instead of "libfoo.so.1.2.3". There is no problem 

You shouldn't have to version, but you do need to declare an soname.  (This can
be done after link as well if I remember correctly.)  Once an soname is declared
in your library, OE will know that it's runtime and not -dev.)

> building these (except we need to work around OE's default of 
> putting *.so in ${PN}-dev rather than ${PN}). However, when rpm 
> creates the packages for the applications linked with these 
> libraries, it fails to automatically determine these runtime
> dependencies. However, since there are no errors, what then 
> happens is that the image is created, lacking most of our 
> libraries, which of course leads to the image failing to boot 
> when applications cannot find the libraries they need...
> 
> The reason this is not a problem with versioned libraries is 
> that the code in OE has support for determining these and will 
> feed that information to rpm. In hindsight, it would probably 
> have been better if I looked at fixing that code to support 
> unversioned libraries, but since rpm's automatic discovery of 
> runtime dependencies worked in Morty, I thought it would be 
> easiest to get the needed functionality back that was lost in 
> the transition to dnf by fixing rpm...

It might be a good idea to have an optional QA warning for unversioned
libraries.  Last time I looked (a few years ago) we didn't have any by default.
This made it easy to define the rules that we use the declared soname(s) to
define what goes into the runtime library package and what goes into the -dev
package.

--Mark

> //Peter
> 

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

Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on Pyro

[Mark Hatle]

On 8/17/17 5:53 AM, Alexander Kanavin wrote:
> On 08/16/2017 06:37 PM, Mark Hatle wrote:
>> Are there any examples?  I was looking there and simply didn't see any.  I 
>> saw
>> the packaging for instance exercised python interfaces, version comparison
>> tools, etc.. but nothing that built a recipe/package and then verified the
>> contents were 'correct'.
>>
>> Ideally the test would be to fabricate something with a known set of file
>> dependencies, produce a package from it and then verify that the package
>> properly included those dependencies.
>>
>> I had looked at just picking some random library out of the deploy directory,
>> and doing a pattern search on it's provides.. but I'm not sure that type of 
>> test
>> would be very robust.
> 
> How was this regression discovered in the first place? I guess that some 
> recipe used to build without error with rpm5, and stopped building with 
> rpm4. This is what you could test for: isolate the problematic bit, 
> remove everything else, and write a simple recipe(s) that can be placed 
> into meta-selftest. Then simply build those from the selftest; if they 
> build without error, you don't need to do more sophisticated checks.
> 

In -my- case (I can't speak for Peter), I found the issue trying to build SRPMs
on the target.  I either ran into dep problems or could not install what I 
built.

Further I went in and simply looked at the output (deploy dir):  rpm -qp
 --provides

I was able to quickly determine that only OE style dependencies were present.

So from a test perspective, we probably need to build something with a known
content and run rpmdeps against it, and then build a package (recipe) and verify
the dependencies are there as well.  I just don't know how to implement that in
the existing unit-test framework.

--Mark

> Alex
> 

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

Re: [OE-core] [PATCH 1/3] python: Restructure python packaging and replace it with autopackaging

[Andreas Oberritter]

On Thu, 17 Aug 2017 03:24:23 -0700
Alejandro Hernandez  wrote:

>  - It creates a solution for users that want precompiled bytecode files
>(*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to
>include such files, some argument they get faster boot time, even when the
>files would be created on their first run?, but they also sometimes give a
>magic number error and take up space, so we leave it to the user to
>decide if they want them or not.

A serious problem with not shipping precompiled pyc and/or pyo files is that,
once generated on first run, package managers won't uninstall them.

This can cause many undesired effects, because python programs will still be
able to import these files, but dependencies like graphics or shared libraries
may have been deleted by the package manager.

Also, not being able to uninstall something is bad on its own.

So, if anything, I believe INCLUDE_PYCS = "1" would be the only sane default,
unless no package management was involved at all.

And no read-only filesystem, for what it's worth.

Best regards,
Andreas

P.S.: I didn't see patches 2 and 3. Is it just an incorrect subject?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qemuboot.bbclass: Prevent creating a link loop

[Mike Looijmans]

When IMAGE_NAME and IMAGE_LINK_NAME are equal, do_write_qemuboot_conf will
create a symlink that links to itself.

Check if this is the case before creating the link.

Signed-off-by: Mike Looijmans 
---
 meta/classes/qemuboot.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 86b3060..0e21fc9 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -114,7 +114,8 @@ python do_write_qemuboot_conf() {
 with open(qemuboot, 'w') as f:
 cf.write(f)
 
-if os.path.lexists(qemuboot_link):
-   os.remove(qemuboot_link)
-os.symlink(os.path.basename(qemuboot), qemuboot_link)
+if qemuboot_link != qemuboot:
+if os.path.lexists(qemuboot_link):
+   os.remove(qemuboot_link)
+os.symlink(os.path.basename(qemuboot), qemuboot_link)
 }
-- 
1.9.1

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

Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on Pyro

[Alexander Kanavin]

On 08/17/2017 04:01 PM, Peter Kjellerstedt wrote:


The problem we have, which caused me to look into this, is:

We unfortunately have a lot of unversioned libraries, e.g.,
"libfoo.so" instead of "libfoo.so.1.2.3". There is no problem
building these (except we need to work around OE's default of
putting *.so in ${PN}-dev rather than ${PN}). However, when rpm
creates the packages for the applications linked with these
libraries, it fails to automatically determine these runtime
dependencies. However, since there are no errors, what then
happens is that the image is created, lacking most of our
libraries, which of course leads to the image failing to boot
when applications cannot find the libraries they need...


Thanks. The problem with relying on rpm for this discovery is that this 
mechanism is not used anywhere in oe-core. I may update rpm to 4.14 and 
again break this stuff without noticing. I'd say it's better if you fix 
oe-core's code to discover those in the same way versioned libraries are 
discovered.



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

[OE-core] [PATCH] copy_buildsystem: include layer tree during build structure creation

[Andrej Valek]

When buildsystem with layer structure is going to be copied, only the last
meta-XXX layer is taken.
For example, during ext_sdk bblayers creating:
layers/oe/meta \
layers/oe/meta-oe \
layers/oe/meta-networking \
layers/oe/meta-webserver \
...
It restructured meta-oe, meta-networking,... contents into meta-oe.
Recipes from meta-oe will be on the same level like meta-networking,
meta-webserver, ... .

It should take the whole meta path instead of the last one.
layers/oe/meta \
layers/oe/meta-oe/meta-oe \
layers/oe/meta-oe/meta-networking \
layers/oe/meta-oe/meta-webserver \
...
Now the directory structure is the same like during build creation.

Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 meta/lib/oe/copy_buildsystem.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index dd506a3..e24488d 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -71,6 +71,11 @@ class BuildSystem(object):
 layerdestpath = destdir
 if corebase == os.path.dirname(layer):
 layerdestpath += '/' + os.path.basename(corebase)
+else:
+layer_relative = os.path.basename(corebase) + '/' + 
os.path.relpath(layer, corebase)
+if os.path.dirname(layer_relative) != layernewname:
+layerdestpath += '/' + os.path.dirname(layer_relative)
+
 layerdestpath += '/' + layernewname
 
 layer_relative = os.path.relpath(layerdestpath,
-- 
2.1.4

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

Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on Pyro

[Peter Kjellerstedt]

> -Original Message-
> From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com]
> Sent: den 17 augusti 2017 12:53
> To: Mark Hatle ; Richard Purdie
> ; openembedded-
> c...@lists.openembedded.org
> Cc: Peter Kjellerstedt 
> Subject: Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on
> Pyro
> 
> On 08/16/2017 06:37 PM, Mark Hatle wrote:
> > Are there any examples?  I was looking there and simply didn't see
> > any.  I saw the packaging for instance exercised python interfaces, 
> > version comparison tools, etc.. but nothing that built a 
> > recipe/package and then verified the contents were 'correct'.
> >
> > Ideally the test would be to fabricate something with a known set 
> > of file dependencies, produce a package from it and then verify 
> > that the package properly included those dependencies.
> >
> > I had looked at just picking some random library out of the deploy
> > directory, and doing a pattern search on it's provides.. but I'm 
> > not sure that type of test would be very robust.
> 
> How was this regression discovered in the first place? I guess that
> some recipe used to build without error with rpm5, and stopped 
> building with rpm4. This is what you could test for: isolate the 
> problematic bit, remove everything else, and write a simple recipe(s) 
> that can be placed into meta-selftest. Then simply build those from 
> the selftest; if they build without error, you don't need to do more 
> sophisticated checks.
> 
> Alex

The problem we have, which caused me to look into this, is:

We unfortunately have a lot of unversioned libraries, e.g., 
"libfoo.so" instead of "libfoo.so.1.2.3". There is no problem 
building these (except we need to work around OE's default of 
putting *.so in ${PN}-dev rather than ${PN}). However, when rpm 
creates the packages for the applications linked with these 
libraries, it fails to automatically determine these runtime
dependencies. However, since there are no errors, what then 
happens is that the image is created, lacking most of our 
libraries, which of course leads to the image failing to boot 
when applications cannot find the libraries they need...

The reason this is not a problem with versioned libraries is 
that the code in OE has support for determining these and will 
feed that information to rpm. In hindsight, it would probably 
have been better if I looked at fixing that code to support 
unversioned libraries, but since rpm's automatic discovery of 
runtime dependencies worked in Morty, I thought it would be 
easiest to get the needed functionality back that was lost in 
the transition to dnf by fixing rpm...

//Peter

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

Re: [OE-core] [PATCH] mc: unify curses initialization

[Richard Purdie]

On Thu, 2017-08-17 at 03:15 -0400, Hongxu Jia wrote:
> Since ncurses upgraded to 6.0+20170715, it compile failed
> ...
> > 
> > ../../../mc-4.8.19/lib/tty/tty-ncurses.c:199:13: error:
> > dereferencing
> pointer to incomplete type 'TERMINAL {aka struct term}'
> > 
> >  cur_term->Nttyb.c_cc[VINTR] = CTRL ('g');   /* ^g */
> >  ^~
> ...
> 
> Backport a patch from upstream fixed the issue.
> 
> Signed-off-by: Hongxu Jia 

Unfortunately there is a version in meta-gplv2 that fails to build:

https://autobuilder.yocto.io/builders/nightly-non-gpl3/builds/406

I'm tempted just to delete that recipe at this point as porting the
patch to it would have to be done cleanroom style.

Cheers,

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

Re: [OE-core] [PATCH 2/8] bash: 4.3.30 -> 4.4

[Richard Purdie]

On Wed, 2017-08-16 at 04:31 -0400, Hongxu Jia wrote:
> Rebase patches:
> - fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
> - test-output.patch
> 
> Drop backported patches:
> - CVE-2016-9401.patch
> - fix-run-intl.patch
> 
> Add ${PN}-loadable for loadable builtins which is new features in
> Bash 4.4
> 
> The 4.4 fixed CVE-2017-5932 and CVE-2016-0634
> - https://security-tracker.debian.org/tracker/CVE-2017-5932
> - https://security-tracker.debian.org/tracker/CVE-2016-0634
> 
> Signed-off-by: Hongxu Jia 

There is a multilib issue with one of the headers:

https://autobuilder.yocto.io/builders/nightly-multilib/builds/430

Cheers,

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

Re: [OE-core] openssl10 unusable for many components

[Alexander Kanavin]

On 08/17/2017 02:46 PM, Martin Jansa wrote:
I meant "real-world" as builds for any products on the market (which are 
likely using one of the failing recipes) - e.g. in LGE we have many more 
failures over all internal components, so I'll just undo this openssl 
switch (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as 
openssl_1.0 with PROVIDES openssl11). We won't be able to use 
openssl-1.1 for long time anyway, because there are some 3rd party 
component which are difficult (or expensive) to get rebuilt against new 
openssl ABI, but we might be interested in some other improvements in 
oe-core/master.


Yes, this will work for you as a quick fix, but it is merely postponing 
dealing with the issue properly to a later date. Make a plan for it and 
keep in mind that openssl 1.0 goes out of upstream support at the end of 
2019. Given its history of major security vulnerabilities, it will be 
removed from oe-core well before that time, so that it won't linger in 
supported YP releases.



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

Re: [OE-core] openssl10 unusable for many components

[Martin Jansa]

The qtbase was just an example, the link with the last report:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140829.html

shows that instead of 5 failures reported in previous one:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-August/114108.html

we have around 40 failures (numbers differs for different MACHINEs) and
that's probably far from complete list of failing recipes, because many
recipes weren't built at all, because one of their dependencies failed
already.

I meant "real-world" as builds for any products on the market (which are
likely using one of the failing recipes) - e.g. in LGE we have many more
failures over all internal components, so I'll just undo this openssl
switch (renaming openssl_1.1 as openssl11 and openssl11_1.0 back as
openssl_1.0 with PROVIDES openssl11). We won't be able to use openssl-1.1
for long time anyway, because there are some 3rd party component which are
difficult (or expensive) to get rebuilt against new openssl ABI, but we
might be interested in some other improvements in oe-core/master.

I'm not saying that oe-core should be blocked until the oldest and slowly
moving project is updated to be compatible with it, just keep in mind that
"real-world" products are far more complicated than keeping oe-core
autobuilder green and that some companies might see it as blocker for
upgrading to newer oe-core.

Regards,

On Thu, Aug 17, 2017 at 1:33 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Thu, 2017-08-17 at 12:31 +0200, Martin Jansa wrote:
> > Does openssl10 work for anyone in real-world scenarios?
>
> Depends what "real-world" means really.
>
> I've strongly pushed for OE-Core to have at least some spectrum of
> coverage of various elements of the software stacks people use so we
> can use it as an indicator of changes readiness to be merged. This goes
> against those who want it stripped to the bare bones.
>
> There was a strong desire to keep qt5 out of OE-Core and I've gone
> along with that, this is one of the downsides, it doesn't get testing
> when changes like this get integrated. We did test openssl 1.1 as far
> as we reasonably could before it merged and it was posted on the list
> for quite a while and discussed.
>
> There is a problem here and I don't know how we solve it to be honest
> (other than the obvious upgrading of problematic recipes).
>
> I can imagine some fancy sstate code in the openssl recipes where they
> could prune their populate_sysroot data depending on the dependency
> chains being installed. Equally, that code would be hard to right and
> would only stop another subset of issues, not solve the problem. For
> example, if python3 references the openssl headers, there could be
> ABI/API issues if QT uses python3 openssl functions, depending on how
> the headers are structured.
>
> So I'm not sure how we move forward here, one plus point is that there
> are 1.1 patches for qt5 which is something at least.
>
> People could suggest more testing. The reason patches merge slowly in
> OE-Core is the infrastructure struggles with the current range of
> testing. I've actually "destroyed" one of the autobuilder clusters this
> week and we're running on degraded infrastructure right now until we
> fix the overloading problem I caused there :(.
>
> Cheers,
>
> Richard
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] openssl10 unusable for many components

[Richard Purdie]

On Thu, 2017-08-17 at 12:31 +0200, Martin Jansa wrote:
> Does openssl10 work for anyone in real-world scenarios?

Depends what "real-world" means really.

I've strongly pushed for OE-Core to have at least some spectrum of
coverage of various elements of the software stacks people use so we
can use it as an indicator of changes readiness to be merged. This goes
against those who want it stripped to the bare bones.

There was a strong desire to keep qt5 out of OE-Core and I've gone
along with that, this is one of the downsides, it doesn't get testing
when changes like this get integrated. We did test openssl 1.1 as far
as we reasonably could before it merged and it was posted on the list
for quite a while and discussed.

There is a problem here and I don't know how we solve it to be honest
(other than the obvious upgrading of problematic recipes).

I can imagine some fancy sstate code in the openssl recipes where they
could prune their populate_sysroot data depending on the dependency
chains being installed. Equally, that code would be hard to right and
would only stop another subset of issues, not solve the problem. For
example, if python3 references the openssl headers, there could be
ABI/API issues if QT uses python3 openssl functions, depending on how
the headers are structured.

So I'm not sure how we move forward here, one plus point is that there
are 1.1 patches for qt5 which is something at least.

People could suggest more testing. The reason patches merge slowly in
OE-Core is the infrastructure struggles with the current range of
testing. I've actually "destroyed" one of the autobuilder clusters this
week and we're running on degraded infrastructure right now until we
fix the overloading problem I caused there :(. 

Cheers,

Richard


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

Re: [OE-core] openssl10 unusable for many components

[Alexander Kanavin]

On 08/17/2017 01:31 PM, Martin Jansa wrote:
So you cannot just select which openssl implementation you want for 
given component, unless it's very simple component with small dependency 
tree.


Unfortunately yes. The header names clash, and there's no way to have 
them both in the sysroot at the same time.


The only solution I see is the hard one: first update the component to 
latest upstream version, and see if that version compiles with 1.1.
If not, then Fedora probably has a vendor patch for the API fixing, as 
they've already moved to 1.1 as default.


FWIW, qt5 has merged openssl 1.1 support 
https://codereview.qt-project.org/#/c/189399/, but I don't know if 
there's a release with it included.


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

[OE-core] [PATCH] rootfs-postcommands.bbclass: Prevent linking testdata to itself

[Mike Looijmans]

testdata and testdata_link may point to the same file, in particular
when IMAGE_LINK_NAME and IMAGE_NAME are equal.

Check if this is the case before creating a symlink that points to
itself and makes the next build fail.

Signed-off-by: Mike Looijmans 
---
 meta/classes/rootfs-postcommands.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 78f7c55..c92df7b 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -300,7 +300,8 @@ python write_image_test_data() {
 searchString = "%s/"%(d.getVar("TOPDIR")).replace("//","/")
 export2json(d, testdata,searchString=searchString,replaceString="")
 
-if os.path.lexists(testdata_link):
-   os.remove(testdata_link)
-os.symlink(os.path.basename(testdata), testdata_link)
+if testdata_link != testdata:
+if os.path.lexists(testdata_link):
+   os.remove(testdata_link)
+os.symlink(os.path.basename(testdata), testdata_link)
 }
-- 
1.9.1

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

Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on Pyro

[Alexander Kanavin]

On 08/16/2017 06:37 PM, Mark Hatle wrote:

Are there any examples?  I was looking there and simply didn't see any.  I saw
the packaging for instance exercised python interfaces, version comparison
tools, etc.. but nothing that built a recipe/package and then verified the
contents were 'correct'.

Ideally the test would be to fabricate something with a known set of file
dependencies, produce a package from it and then verify that the package
properly included those dependencies.

I had looked at just picking some random library out of the deploy directory,
and doing a pattern search on it's provides.. but I'm not sure that type of test
would be very robust.


How was this regression discovered in the first place? I guess that some 
recipe used to build without error with rpm5, and stopped building with 
rpm4. This is what you could test for: isolate the problematic bit, 
remove everything else, and write a simple recipe(s) that can be placed 
into meta-selftest. Then simply build those from the selftest; if they 
build without error, you don't need to do more sophisticated checks.



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

[OE-core] openssl10 unusable for many components

[Martin Jansa]

Does openssl10 work for anyone in real-world scenarios?

I was trying to fix at least some of the failures reported in last bitbake
world status:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140829.html

But in most recipes if you update DEPENDS to use openssl10, it will get
openssl (1.1) somewhere in dependency tree as well, e.g. like qtbase
through python3:

OE qemux86@ ~/build/oe-core $ grep " -> \"openssl.*do_populate_sysroot"
task-depends.dot
"qtbase.do_prepare_recipe_sysroot" -> "openssl10.do_populate_sysroot"
"openssl10.do_prepare_recipe_sysroot" ->
"openssl-native.do_populate_sysroot"
"python3-native.do_prepare_recipe_sysroot" ->
"openssl-native.do_populate_sysroot"
"python3.do_prepare_recipe_sysroot" -> "openssl.do_populate_sysroot"

and then do_prepare_recipe_sysroot fails, because both dependencies provid
libssl.a:

ERROR: qtbase-5.9.0+gitAUTOINC+f6b36eaafe-r0 do_prepare_recipe_sysroot:
Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '/OE/build/oe-core/openembedded-core/meta/classes/staging.bbclass',
lineno: 510, function: extend_recipe_sysroot
 0506:dest = newmanifest[l]
 0507:if l.endswith("/"):
 0508:staging_copydir(l, targetdir, dest,
seendirs)
 0509:continue
 *** 0510:staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
 0511:
 0512:for f in fixme:
 0513:if f == '':
 0514:staging_processfixme(fixme[f], recipesysroot,
recipesysroot, recipesysrootnative, d)
File: '/OE/build/oe-core/openembedded-core/meta/classes/staging.bbclass',
lineno: 151, function: staging_copyfile
 0147:os.symlink(linkto, dest)
 0148:#bb.warn(c)
 0149:else:
 0150:try:
 *** 0151:os.link(c, dest)
 0152:except OSError as err:
 0153:if err.errno == errno.EXDEV:
 0154:bb.utils.copyfile(c, dest)
 0155:else:
Exception: FileExistsError: [Errno 17] File exists:
'/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/libssl.a'
->
'/OE/build/oe-core/tmp-glibc/work/i586-oe-linux/qtbase/5.9.0+gitAUTOINC+f6b36eaafe-r0/recipe-sysroot/usr/lib/libssl.a'

ERROR: qtbase-5.9.0+gitAUTOINC+f6b36eaafe-r0 do_prepare_recipe_sysroot:
Function failed: extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/OE/build/oe-core/tmp-glibc/work/i586-oe-linux/qtbase/5.9.0+gitAUTOINC+f6b36eaafe-r0/temp/log.do_prepare_recipe_sysroot.6496
ERROR: Task 
(/OE/build/oe-core/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_prepare_recipe_sysroot)
failed with exit code '1'

And not just libssl.a, they both provide also identically named pkg-config
files:
openssl.pc, libcrypto.pc, libssl.pc
OE qemux86@ ~/build/oe-core $ find
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/ | grep pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/usr/lib/pkgconfig/openssl.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/usr/lib/pkgconfig/libcrypto.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl10/usr/lib/pkgconfig/libssl.pc
OE qemux86@ ~/build/oe-core $ find
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl | grep pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/pkgconfig/openssl.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/pkgconfig/libcrypto.pc
/OE/build/oe-core/tmp-glibc/sysroots-components/i586/openssl/usr/lib/pkgconfig/libssl.pc

So you cannot just select which openssl implementation you want for given
component, unless it's very simple component with small dependency tree.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] python: Restructure python packaging and replace it with autopackaging

[Alejandro Hernandez]

The reason we have a manifest file for python is that our goal is to
keep python-core as small as posible and add other python packages only
when the user needs them, hence why we split upstream python into several
packages.

Although our manifest file has several issues:
 - Its unorganized and hard to read and understand it for an average
   human being.
 - Git throws an error every single time  a patch to the manifest 
   is submitted.
 - It changes or may change with every release of python, its impossible
   to know if the required files for a certain package have changed
   (it could have more or less dependencies), the only way of doing so
   would be to install and test them all one by one, and even then we
   wouldnt know if they require less dependencies, we would just know if
   an extra dependency is required since it would complain, lets face it,
   this isnt feasible.
 - The same thing happens for new packages, if someone wants to add a
   new package, its dependencies need to be checked manually one by one.

This patch fixes those issues, while adding some additional features.

Features/Fixes:

 - A new manifest format is used (JSON), easy to read and understand.
   This file is parsed by the python recipe and python packages read
   from here are passed directly to bitbake during parsing time.
 - It provides an automatic manifest creation task (explained below),
   which automagically checks for every package dependencies and adds
   them to the new manifest, hence we will have on each package exactly
   what that package needs to be run, providing finer granularity.
 - Dependencies are also checked automagically for new packages (explained 
below).
 - Fixes the manifest in the following ways:
   * python-core should be base and all packages should depend on it ,
 fixes lang, string, codecs, etc.
   * Fixes packages with repeated files (e.g. bssdb and db, or
 netclient and mime, and many others).
 - Removes the manifest from the python-native recipe (Why was it there
   in the first place?, native recipes do not get split).
 - It creates a solution for users that want precompiled bytecode files
   (*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to
   include such files, some argument they get faster boot time, even when the
   files would be created on their first run?, but they also sometimes give a
   magic number error and take up space, so we leave it to the user to
   decide if they want them or not.
 - Fixes python-core for dependencies, e.g.
   When python is run on an image, it TRIES to import everything it needs,
   but it doesnt necessarily fails when it doesnt find something, so even if
   we didnt know, we had errors like (trimmed on purpose):
   # trying /usr/lib/python2.7/_locale.so
   # trying /usr/lib/python2.7/lib-dynload/_locale.so
   # trying /usr/lib/python2.7/_sysconfigdata.so

   while it didnt complain about _locale it should have imported it,
   after creating a new manifest with the automated script we get:

   # trying /usr/lib/python2.7/lib-dynload/_locale.so
   dlopen("/usr/lib/python2.7/lib-dynload/_locale.so", 2);
   import _locale # dynamically loaded from 
/usr/lib/python2.7/lib-dynload/_locale.so

How to use (after a new release of python, or maybe before every OE
release):
 - A new task called create_manifest was added to the python package,
   which may be invoked via:

 $ bitbake python -c create_manifest

 This task runs a script on native python on our HOST system, this
 script is called create_manifest.py and it in a very simplistic way
 it does the following:

 1. Reads the JSON manifest file and creates a dictionary data structure
with all of our python packages, their FILES, RDEPENDS and SUMMARY.
 2. Loops through all of them and runs them asynchronously, determining
every dependency that they have.
 3. These module dependencies are then handled, to be able to know which
packages contain those files and which should RDEPEND on one another.
 4. The data structure that comes out of this, is then used to create a new
manifest file which is automatically copied onto the user's python
directory replacing the old one.

 Create_manifest script features:
 - Handles modules which dont exist anymore (new release for example).
 - Handles modules that are builtin.
 - Deals with modules which were not compiled (e.g. bsddb or ossaudiodev)
 - This method works for both python modules and shared libraries used
   by python.
 - Deals with packages which include folders.
 - Deals with packages which include FILES with a wildcard.
 - The manifest can be constructed on a multilib environment as well.

How to add a new package:
 - If a user wants to add a new package all that has to be done is
   modify the python2-manifest.json file, and add the required file(s)
   to the FILES list, the script should handle all the rest.
   Real example:
   "webbrowser": {
   "files": 

Re: [OE-core] [PATCH] gpgme: remove local m4/python.m4

[Richard Purdie]

On Thu, 2017-08-17 at 04:35 -0400, Hongxu Jia wrote:
> While multilib, the local m4/python.m4 incorrectly assigned
> am_cv_python_pyexecdir and am_cv_python_pythondir which caused
> the following error enabled:
> ...
> ERROR: gpgme-1.9.0-r0 do_package: QA Issue: gpgme: Files/directories
> were installed but not shipped in any package:
>   /usr/lib/python3.5/site-packages/gpg-1.9.0-py3.5.egg-info
> ...
> 
> Signed-off-by: Hongxu Jia 
> ---
>  meta/recipes-support/gpgme/gpgme_1.9.0.bb | 1 +
>  1 file changed, 1 insertion(+)

Thanks for the quick turnaround on this and the other fix, its much
appreciated. I'll include them in the next build and see where we are.

Cheers,

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

[OE-core] [PATCH] valgrind: disable build for muslx32

[swee . aun . khor]

From: sweeaun 

Disable build for muslx32.X32 isn't supported by valgrind at this
moment.

Signed-off-by: sweeaun 
---
 meta/recipes-devtools/valgrind/valgrind_3.13.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.13.0.bb 
b/meta/recipes-devtools/valgrind/valgrind_3.13.0.bb
index a5c4943..25b4126 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.13.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.13.0.bb
@@ -51,6 +51,7 @@ COMPATIBLE_HOST_armv6 = 'null'
 
 # X32 isn't supported by valgrind at this time
 COMPATIBLE_HOST_linux-gnux32 = 'null'
+COMPATIBLE_HOST_linux-muslx32 = 'null'
 
 # Disable for some MIPS variants
 COMPATIBLE_HOST_mipsarchn32 = 'null'
-- 
2.7.4

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

[OE-core] [PATCH] goarch: Disable build for muslx32

[swee . aun . khor]

From: sweeaun 

Disable build for muslx32.

Signed-off-by: sweeaun 
---
 meta/classes/goarch.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 57537fb..9cd38b8 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -14,6 +14,7 @@ GO_BUILD_BINDIR = 
"${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE',Tru
 # define here because everybody inherits this class
 #
 COMPATIBLE_HOST_linux-gnux32 = "null"
+COMPATIBLE_HOST_linux-muslx32 = "null"
 COMPATIBLE_HOST_powerpc = "null"
 COMPATIBLE_HOST_powerpc64 = "null"
 
-- 
2.7.4

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

Re: [OE-core] [PATCH v2] devtool/copy_buildsystem: adds meta-skeleton layer in the eSDK installation.

[Paul Eggleton]

On Thursday, 17 August 2017 7:36:14 PM NZST Richard Purdie wrote:
> On Wed, 2017-08-16 at 18:36 -0700, juan.m.cruz.alca...@linux.intel.com
> wrote:
> > From: Juan M Cruz Alcaraz 
> > 
> > The eSDK installation requires the meta-skeleton layer.
> > The build system might use the meta-skeleton recipes as layout
> > to create custom recipes. An example is the recipetool script
> > that uses the meta-skeleton kernel recipe when creating a custom
> > kernel recipe.
> > 
> > [YOCTO #11102]
> > 
> > Signed-off-by: Juan M Cruz Alcaraz  > om>
> > ---
> >  meta/lib/oe/copy_buildsystem.py | 8 
> >  1 file changed, 8 insertions(+)
> 
> Failed to build on the autobuilder I'm afraid:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/1216/
steps/BuildImages_2/logs/stdio

Right, the assumption that the first part will be "poky/" is probably the 
issue here. I suspect you will have to step through the list and remove 
anything that ends with '/meta-skeleton'.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] dpkg: 1.18.10 -> 1.18.24

[Hongxu Jia]

The 1.18.24 fixed CVE-2016-7948

Rebase patches:
- noman.patch -> 0001
- remove-tar-no-timestamp.patch -> 0002
- arch_pm.patch -> 0003
- add_armeb_triplet_entry.patch -> 0004
- 0002-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch -> 0005
- 0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch -> 0006
- 0004-The-lutimes-function-doesn-t-work-properly-for-all-s.patch -> 0007
- 0005-dpkg-compiler.m4-remove-Wvla.patch -> 0008
- 0006-add-musleabi-to-known-target-tripets.patch -> 0009
- 0007-dpkg-deb-build.c-Remove-usage-of-clamp-mtime-in-tar.patch -> 0010
- glibc2.5-sync_file_range.patch -> 0011

Signed-off-by: Hongxu Jia 
---
 .../dpkg/dpkg/{noman.patch => 0001-no-man.patch}   | 28 +++--
 ...mp.patch => 0002-remove-tar-no-timestamp.patch} | 27 +++--
 .../dpkg/{arch_pm.patch => 0003-arch-pm.patch} | 27 +++--
 ...04-add-armeb-tuple-entry-into-tupletable.patch} | 39 +++--
 ...ux-wrs-kernel-version-which-has-characte.patch} | 29 ++
 ...insts-expect-D-to-be-set-when-running-in.patch} | 11 ++--
 ...function-doesn-t-work-properly-for-all-s.patch} | 14 +++--
 ...tch => 0008-dpkg-compiler.m4-remove-Wvla.patch} | 13 +++--
 ...-add-musleabi-to-known-target-tupletable.patch} | 66 +++---
 ...ild.c-Remove-usage-of-clamp-mtime-in-tar.patch} | 33 ++-
 ...e.patch => 0011-glibc2.5-sync-file-range.patch} | 31 +++---
 .../dpkg/{dpkg_1.18.10.bb => dpkg_1.18.24.bb}  | 28 -
 12 files changed, 214 insertions(+), 132 deletions(-)
 rename meta/recipes-devtools/dpkg/dpkg/{noman.patch => 0001-no-man.patch} (19%)
 rename meta/recipes-devtools/dpkg/dpkg/{remove-tar-no-timestamp.patch => 
0002-remove-tar-no-timestamp.patch} (38%)
 rename meta/recipes-devtools/dpkg/dpkg/{arch_pm.patch => 0003-arch-pm.patch} 
(36%)
 rename meta/recipes-devtools/dpkg/dpkg/{add_armeb_triplet_entry.patch => 
0004-add-armeb-tuple-entry-into-tupletable.patch} (51%)
 rename 
meta/recipes-devtools/dpkg/dpkg/{0002-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch
 => 0005-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch} (61%)
 rename 
meta/recipes-devtools/dpkg/dpkg/{0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch
 => 0006-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch} (88%)
 rename 
meta/recipes-devtools/dpkg/dpkg/{0004-The-lutimes-function-doesn-t-work-properly-for-all-s.patch
 => 0007-The-lutimes-function-doesn-t-work-properly-for-all-s.patch} (68%)
 rename 
meta/recipes-devtools/dpkg/dpkg/{0005-dpkg-compiler.m4-remove-Wvla.patch => 
0008-dpkg-compiler.m4-remove-Wvla.patch} (78%)
 rename 
meta/recipes-devtools/dpkg/dpkg/{0006-add-musleabi-to-known-target-tripets.patch
 => 0009-add-musleabi-to-known-target-tupletable.patch} (14%)
 rename 
meta/recipes-devtools/dpkg/dpkg/{0007-dpkg-deb-build.c-Remove-usage-of-clamp-mtime-in-tar.patch
 => 0010-dpkg-deb-build.c-Remove-usage-of-clamp-mtime-in-tar.patch} (52%)
 rename meta/recipes-devtools/dpkg/dpkg/{glibc2.5-sync_file_range.patch => 
0011-glibc2.5-sync-file-range.patch} (81%)
 rename meta/recipes-devtools/dpkg/{dpkg_1.18.10.bb => dpkg_1.18.24.bb} (19%)

diff --git a/meta/recipes-devtools/dpkg/dpkg/noman.patch 
b/meta/recipes-devtools/dpkg/dpkg/0001-no-man.patch
similarity index 19%
rename from meta/recipes-devtools/dpkg/dpkg/noman.patch
rename to meta/recipes-devtools/dpkg/dpkg/0001-no-man.patch
index d30c150..7eb3dae 100644
--- a/meta/recipes-devtools/dpkg/dpkg/noman.patch
+++ b/meta/recipes-devtools/dpkg/dpkg/0001-no-man.patch
@@ -1,14 +1,32 @@
+From 3be0b1983c943c31534f0f3e199a702a0033f3be Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Thu, 17 Aug 2017 10:29:21 +0800
+Subject: [PATCH 01/11] no man
+
 Upstream-Status: Inappropriate [disable feature]
 
-diff -ruN dpkg-1.15.8.5-orig/Makefile.am dpkg-1.15.8.5/Makefile.am
 dpkg-1.15.8.5-orig/Makefile.am 2010-10-08 12:27:15.042083703 +0800
-+++ dpkg-1.15.8.5/Makefile.am  2010-10-08 12:27:27.755148228 +0800
-@@ -12,8 +12,7 @@
-   utils \
+Signed-off-by: anonymous
+
+Rebase to 1.18.24
+Signed-off-by: Hongxu Jia 
+---
+ Makefile.am | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 0da52cb..a1f79e0 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -13,8 +13,7 @@ SUBDIRS = \
$(MAYBE_DSELECT) \
scripts \
+   t-func \
 -  po \
 -  man
 +  po
  
  ACLOCAL_AMFLAGS = -I m4
+ 
+-- 
+1.8.3.1
+
diff --git a/meta/recipes-devtools/dpkg/dpkg/remove-tar-no-timestamp.patch 
b/meta/recipes-devtools/dpkg/dpkg/0002-remove-tar-no-timestamp.patch
similarity index 38%
rename from meta/recipes-devtools/dpkg/dpkg/remove-tar-no-timestamp.patch
rename to meta/recipes-devtools/dpkg/dpkg/0002-remove-tar-no-timestamp.patch
index 4f408ff..b003ce8 100644
--- a/meta/recipes-devtools/dpkg/dpkg/remove-tar-no-timestamp.patch
+++ 

[OE-core] [PATCH] gpgme: remove local m4/python.m4

[Hongxu Jia]

While multilib, the local m4/python.m4 incorrectly assigned
am_cv_python_pyexecdir and am_cv_python_pythondir which caused
the following error enabled:
...
ERROR: gpgme-1.9.0-r0 do_package: QA Issue: gpgme: Files/directories
were installed but not shipped in any package:
  /usr/lib/python3.5/site-packages/gpg-1.9.0-py3.5.egg-info
...

Signed-off-by: Hongxu Jia 
---
 meta/recipes-support/gpgme/gpgme_1.9.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/gpgme/gpgme_1.9.0.bb 
b/meta/recipes-support/gpgme/gpgme_1.9.0.bb
index 2518147..065c346 100644
--- a/meta/recipes-support/gpgme/gpgme_1.9.0.bb
+++ b/meta/recipes-support/gpgme/gpgme_1.9.0.bb
@@ -73,4 +73,5 @@ do_configure_prepend () {
# Else these could be used in preference to those in aclocal-copy
rm -f ${S}/m4/gpg-error.m4
rm -f ${S}/m4/libassuan.m4
+   rm -f ${S}/m4/python.m4
 }
-- 
2.8.1

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

Re: [OE-core] [PATCH] gpg_sign: perform rpm signing serially

[Markus Lehtonen]

Hi,

I quickly run some tests on a Xeon server, using glibc-locale as the recipe to 
build.
100: 154s 
10: 162s (+5%)
1: 234s (+51%)

Even if signing is not parallel, the difference may be explained by the number 
of rpm processes that get spawned. I would drop the factor to 10 or use 
BB_NUMBER_THREADS as Andre suggested in another email.
  - Markus



On 16/08/2017, 19.00, "Leonardo Sandoval" 
 wrote:

On Wed, 2017-08-16 at 15:28 +0300, Markus Lehtonen wrote:
> I agree. I don't see reason for dropping parallelism completely. There is 
a real gain when running on beefier machines. Making it configurable would 
probably be best. Or just drop it to a saner value, like 20 or 10.
>- Markus
> 

I ran some tests with 100, 20 and 1 and I saw (I can rerun and provide
times) no difference on times. gpg may be intrinsically serial so
passing 1 or N files wont make much difference in type. The only gain
when using file chunks is that one one process is launched.

I the other hand, I tried using multiprocessing.Pool, but failed
miserably due to file looking reasons.



> On 16/08/2017, 2.53, "Mark Hatle" 
 wrote:
> 
> It would probably be better if this was configurable with a 'safe' 
default.
> 
> Moving from parallel to single will greatly affect the overall 
performance on
> larger build machines (lots of memory and cores) that can handle the 
load vs a
> typical development machine.
> 
> --Mark
> 
> On 8/15/17 4:40 PM, leonardo.sandoval.gonza...@linux.intel.com wrote:
> > From: Leonardo Sandoval 
> > 
> > gpg signing in file batches (which was default to 100) is a memory 
expensive
> > computation, causing trouble in some host machines (even on 
production AB
> > as seen on the bugzilla ID). Also, in terms of performance, there 
is no real
> > gain when rpm signing is done in batches. Considering the latter 
issues, perform the
> > rpm signing serially.
> > 
> > Log showing errors observed recently at AB workers:
> > 
> > | gpg: signing failed: Cannot allocate memory
> > | gpg: signing failed: Cannot allocate memory
> > | error: gpg exec failed (2)
> > | 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/core2-64-poky-linux/base-passwd/3.5.29-r0/deploy-rpms/core2_64/base-passwd-dev-3.5.29-r0.core2_64.rpm:
> > 
> > [YOCTO #11914]
> > 
> > Signed-off-by: Leonardo Sandoval 

> > ---
> >  meta/lib/oe/gpg_sign.py | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
> > index f4d8b10e4b..5c7985a856 100644
> > --- a/meta/lib/oe/gpg_sign.py
> > +++ b/meta/lib/oe/gpg_sign.py
> > @@ -45,9 +45,9 @@ class LocalSigner(object):
> >  if fsk_password:
> >  cmd += "--define '_file_signing_key_password %s' " 
% fsk_password
> >  
> > -# Sign in chunks of 100 packages
> > -for i in range(0, len(files), 100):
> > -status, output = oe.utils.getstatusoutput(cmd + ' 
'.join(files[i:i+100]))
> > +# Sign packages
> > +for f in files:
> > +status, output = oe.utils.getstatusoutput(cmd + ' ' + 
f)
> >  if status:
> >  raise bb.build.FuncFailed("Failed to sign RPM 
packages: %s" % output)
> >  
> > 
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 





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

[OE-core] [PATCH] xserver-xorg: Fix CVE-2017-10971

[jackie.huang]

From: Jackie Huang 

Backport 3 patches to fix CVE-2017-10971:

In the X.Org X server before 2017-06-19, a user authenticated to an X
Session could crash or execute code in the context of the X Server by
exploiting a stack overflow in the endianness conversion of X Events.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-10971

Signed-off-by: Jackie Huang 
---
 .../xserver-xorg/CVE-2017-10971-1.patch| 76 ++
 .../xserver-xorg/CVE-2017-10971-2.patch| 55 
 .../xserver-xorg/CVE-2017-10971-3.patch| 50 ++
 .../xorg-xserver/xserver-xorg_1.19.3.bb|  3 +
 4 files changed, 184 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-1.patch
 create mode 100644 
meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-2.patch
 create mode 100644 
meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-3.patch

diff --git 
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-1.patch 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-1.patch
new file mode 100644
index 00..23c8049896
--- /dev/null
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-1.patch
@@ -0,0 +1,76 @@
+From 215f894965df5fb0bb45b107d84524e700d2073c Mon Sep 17 00:00:00 2001
+From: Michal Srb 
+Date: Wed, 24 May 2017 15:54:40 +0300
+Subject: [PATCH] dix: Disallow GenericEvent in SendEvent request.
+
+The SendEvent request holds xEvent which is exactly 32 bytes long, no more,
+no less. Both ProcSendEvent and SProcSendEvent verify that the received data
+exactly match the request size. However nothing stops the client from passing
+in event with xEvent::type = GenericEvent and any value of
+xGenericEvent::length.
+
+In the case of ProcSendEvent, the event will be eventually passed to
+WriteEventsToClient which will see that it is Generic event and copy the
+arbitrary length from the receive buffer (and possibly past it) and send it to
+the other client. This allows clients to copy unitialized heap memory out of X
+server or to crash it.
+
+In case of SProcSendEvent, it will attempt to swap the incoming event by
+calling a swapping function from the EventSwapVector array. The swapped event
+is written to target buffer, which in this case is local xEvent variable. The
+xEvent variable is 32 bytes long, but the swapping functions for GenericEvents
+expect that the target buffer has size matching the size of the source
+GenericEvent. This allows clients to cause stack buffer overflows.
+
+Signed-off-by: Michal Srb 
+Reviewed-by: Peter Hutterer 
+Signed-off-by: Peter Hutterer 
+
+CVE: CVE-2017-10971
+
+Upstream-Status: Backport 
[https://cgit.freedesktop.org/xorg/xserver/commit/?id=215f894965df5fb0bb45b107d84524e700d2073c]
+
+Signed-off-by: Jackie Huang 
+---
+ dix/events.c  |6 ++
+ dix/swapreq.c |7 +++
+ 2 files changed, 13 insertions(+)
+
+diff --git a/dix/events.c b/dix/events.c
+index 3e3a01e..d3a33ea 100644
+--- a/dix/events.c
 b/dix/events.c
+@@ -5366,6 +5366,12 @@ ProcSendEvent(ClientPtr client)
+ client->errorValue = stuff->event.u.u.type;
+ return BadValue;
+ }
++/* Generic events can have variable size, but SendEvent request holds
++   exactly 32B of event data. */
++if (stuff->event.u.u.type == GenericEvent) {
++client->errorValue = stuff->event.u.u.type;
++return BadValue;
++}
+ if (stuff->event.u.u.type == ClientMessage &&
+ stuff->event.u.u.detail != 8 &&
+ stuff->event.u.u.detail != 16 && stuff->event.u.u.detail != 32) {
+diff --git a/dix/swapreq.c b/dix/swapreq.c
+index 719e9b8..6785059 100644
+--- a/dix/swapreq.c
 b/dix/swapreq.c
+@@ -292,6 +292,13 @@ SProcSendEvent(ClientPtr client)
+ swapl(>destination);
+ swapl(>eventMask);
+ 
++/* Generic events can have variable size, but SendEvent request holds
++   exactly 32B of event data. */
++if (stuff->event.u.u.type == GenericEvent) {
++client->errorValue = stuff->event.u.u.type;
++return BadValue;
++}
++
+ /* Swap event */
+ proc = EventSwapVector[stuff->event.u.u.type & 0177];
+ if (!proc || proc == NotImplemented)/* no swapping proc; invalid 
event type? */
+-- 
+1.7.9.5
+
diff --git 
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-2.patch 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-2.patch
new file mode 100644
index 00..5c9887afa1
--- /dev/null
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2017-10971-2.patch
@@ -0,0 +1,55 @@
+From 8caed4df36b1f802b4992edcfd282cbeeec35d9d Mon Sep 17 00:00:00 2001
+From: Michal Srb 
+Date: Wed, 24 May 2017 15:54:41 +0300
+Subject: [PATCH] Xi: Verify all events in 

[OE-core] [PATCH] wget: Security fix CVE-2017-6508

[Yi Zhao]

CVE-2017-6508: CRLF injection vulnerability in the url_parse function in
url.c in Wget through 1.19.1 allows remote attackers to inject arbitrary
HTTP headers via CRLF sequences in the host subcomponent of a URL.

External References:
https://nvd.nist.gov/vuln/detail/CVE-2017-6508

Patch from:
http://git.savannah.gnu.org/cgit/wget.git/commit/?id=4d729e322fae359a1aefaafec1144764a54e8ad4

Signed-off-by: Yi Zhao 
---
 .../recipes-extended/wget/wget/CVE-2017-6508.patch | 44 ++
 meta/recipes-extended/wget/wget_1.19.1.bb  |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 meta/recipes-extended/wget/wget/CVE-2017-6508.patch

diff --git a/meta/recipes-extended/wget/wget/CVE-2017-6508.patch 
b/meta/recipes-extended/wget/wget/CVE-2017-6508.patch
new file mode 100644
index 000..b9c290f
--- /dev/null
+++ b/meta/recipes-extended/wget/wget/CVE-2017-6508.patch
@@ -0,0 +1,44 @@
+From 4d729e322fae359a1aefaafec1144764a54e8ad4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?= 
+Date: Mon, 6 Mar 2017 10:04:22 +0100
+Subject: [PATCH] Fix CRLF injection in Wget host part
+
+* src/url.c (url_parse): Reject control characters in host part of URL
+
+Reported-by: Orange Tsai
+
+Upstream-Status: Backport
+[http://git.savannah.gnu.org/cgit/wget.git/commit/?id=4d729e322fae359a1aefaafec1144764a54e8ad4]
+
+CVE: CVE-2017-6508
+
+Signed-off-by: Yi Zhao 
+---
+ src/url.c | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/src/url.c b/src/url.c
+index 8f8ff0b..7d36b27 100644
+--- a/src/url.c
 b/src/url.c
+@@ -925,6 +925,17 @@ url_parse (const char *url, int *error, struct iri *iri, 
bool percent_encode)
+   url_unescape (u->host);
+   host_modified = true;
+ 
++  /* check for invalid control characters in host name */
++  for (p = u->host; *p; p++)
++{
++  if (c_iscntrl(*p))
++{
++  url_free(u);
++  error_code = PE_INVALID_HOST_NAME;
++  goto error;
++}
++}
++
+   /* Apply IDNA regardless of iri->utf8_encode status */
+   if (opt.enable_iri && iri)
+ {
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/wget/wget_1.19.1.bb 
b/meta/recipes-extended/wget/wget_1.19.1.bb
index 62313b2..78bde95 100644
--- a/meta/recipes-extended/wget/wget_1.19.1.bb
+++ b/meta/recipes-extended/wget/wget_1.19.1.bb
@@ -1,5 +1,6 @@
 SRC_URI = "${GNU_MIRROR}/wget/wget-${PV}.tar.gz \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
+   file://CVE-2017-6508.patch \
   "
 
 SRC_URI[md5sum] = "87cea36b7161fd43e3fd51a4e8b89689"
-- 
2.7.4

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

Re: [OE-core] [PATCH v2] devtool/copy_buildsystem: adds meta-skeleton layer in the eSDK installation.

[Richard Purdie]

On Wed, 2017-08-16 at 18:36 -0700, juan.m.cruz.alca...@linux.intel.com
wrote:
> From: Juan M Cruz Alcaraz 
> 
> The eSDK installation requires the meta-skeleton layer.
> The build system might use the meta-skeleton recipes as layout
> to create custom recipes. An example is the recipetool script
> that uses the meta-skeleton kernel recipe when creating a custom
> kernel recipe.
> 
> [YOCTO #11102]
> 
> Signed-off-by: Juan M Cruz Alcaraz  om>
> ---
>  meta/lib/oe/copy_buildsystem.py | 8 
>  1 file changed, 8 insertions(+)

Failed to build on the autobuilder I'm afraid:

https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/1216/steps/BuildImages_2/logs/stdio

Cheers,

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

Re: [OE-core] [PATCH 7/8] gpgme: 1.8.0 -> 1.9.0

[Richard Purdie]

On Wed, 2017-08-16 at 04:31 -0400, Hongxu Jia wrote:
> Rebase patches:
> - pkgconfig.patch -> 0001
> - python-lang-config.patch -> 0002
> - 0001-Correctly-install-python-modules.patch -> 0003
> - python-import.patch -> 0004
> - 0001-gpgme-config-skip-all-lib-or-usr-lib-directories-in-.patch ->
> 0005

Looks like there is some kind of python packaging issue:

https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/1185/steps/BuildImages/logs/stdio

Cheers,

Richard

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

[OE-core] [PATCH] mc: unify curses initialization

[Hongxu Jia]

Since ncurses upgraded to 6.0+20170715, it compile failed
...
| ../../../mc-4.8.19/lib/tty/tty-ncurses.c:199:13: error: dereferencing
pointer to incomplete type 'TERMINAL {aka struct term}'
|  cur_term->Nttyb.c_cc[VINTR] = CTRL ('g');   /* ^g */
|  ^~
...

Backport a patch from upstream fixed the issue.

Signed-off-by: Hongxu Jia 
---
 ...3697-tty_init-unify-curses-initialization.patch | 66 ++
 meta/recipes-extended/mc/mc_4.8.19.bb  |  1 +
 2 files changed, 67 insertions(+)
 create mode 100644 
meta/recipes-extended/mc/files/0002-Ticket-3697-tty_init-unify-curses-initialization.patch

diff --git 
a/meta/recipes-extended/mc/files/0002-Ticket-3697-tty_init-unify-curses-initialization.patch
 
b/meta/recipes-extended/mc/files/0002-Ticket-3697-tty_init-unify-curses-initialization.patch
new file mode 100644
index 000..c54d4d0
--- /dev/null
+++ 
b/meta/recipes-extended/mc/files/0002-Ticket-3697-tty_init-unify-curses-initialization.patch
@@ -0,0 +1,66 @@
+From 4d46a108629beb66a293672db7b44f863b6598ba Mon Sep 17 00:00:00 2001
+From: Thomas Dickey 
+Date: Fri, 14 Apr 2017 14:06:13 +0300
+Subject: [PATCH] Ticket #3697: (tty_init): unify curses initialization
+
+...for various curses implementations.
+
+Signed-off-by: Andrew Borodin 
+
+Upstream-Status: Backport [https://github.com/MidnightCommander/mc.git]
+
+Signed-off-by: Hongxu Jia 
+
+---
+ lib/tty/tty-ncurses.c | 26 +-
+ 1 file changed, 9 insertions(+), 17 deletions(-)
+
+diff --git a/lib/tty/tty-ncurses.c b/lib/tty/tty-ncurses.c
+index a7a11f3..8e69b39 100644
+--- a/lib/tty/tty-ncurses.c
 b/lib/tty/tty-ncurses.c
+@@ -179,6 +179,8 @@ mc_tty_normalize_lines_char (const char *ch)
+ void
+ tty_init (gboolean mouse_enable, gboolean is_xterm)
+ {
++struct termios mode;
++
+ initscr ();
+ 
+ #ifdef HAVE_ESCDELAY
+@@ -194,25 +196,15 @@ tty_init (gboolean mouse_enable, gboolean is_xterm)
+ ESCDELAY = 200;
+ #endif /* HAVE_ESCDELAY */
+ 
+-#ifdef NCURSES_VERSION
++tcgetattr (STDIN_FILENO, );
+ /* use Ctrl-g to generate SIGINT */
+-cur_term->Nttyb.c_cc[VINTR] = CTRL ('g');   /* ^g */
++mode.c_cc[VINTR] = CTRL ('g');  /* ^g */
+ /* disable SIGQUIT to allow use Ctrl-\ key */
+-cur_term->Nttyb.c_cc[VQUIT] = NULL_VALUE;
+-tcsetattr (cur_term->Filedes, TCSANOW, _term->Nttyb);
+-#else
+-/* other curses implementation (bsd curses, ...) */
+-{
+-struct termios mode;
+-
+-tcgetattr (STDIN_FILENO, );
+-/* use Ctrl-g to generate SIGINT */
+-mode.c_cc[VINTR] = CTRL ('g');  /* ^g */
+-/* disable SIGQUIT to allow use Ctrl-\ key */
+-mode.c_cc[VQUIT] = NULL_VALUE;
+-tcsetattr (STDIN_FILENO, TCSANOW, );
+-}
+-#endif /* NCURSES_VERSION */
++mode.c_cc[VQUIT] = NULL_VALUE;
++tcsetattr (STDIN_FILENO, TCSANOW, );
++
++/* curses remembers the "in-program" modes after this call */
++def_prog_mode ();
+ 
+ tty_start_interrupt_key ();
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/mc/mc_4.8.19.bb 
b/meta/recipes-extended/mc/mc_4.8.19.bb
index 20ef9dd..b3a156c 100644
--- a/meta/recipes-extended/mc/mc_4.8.19.bb
+++ b/meta/recipes-extended/mc/mc_4.8.19.bb
@@ -8,6 +8,7 @@ RDEPENDS_${PN} = "ncurses-terminfo"
 
 SRC_URI = "http://www.midnight-commander.org/downloads/${BPN}-${PV}.tar.bz2 \
file://0001-mc-replace-perl-w-with-use-warnings.patch \
+   file://0002-Ticket-3697-tty_init-unify-curses-initialization.patch \
"
 SRC_URI[md5sum] = "ef423f5b6f80a1a5a5fc53b8324cab70"
 SRC_URI[sha256sum] = 
"d0dddfae7149fac903f74ef55cfcb2a198e0f7004346c7bded43669d61ba436f"
-- 
2.8.1

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

Re: [OE-core] [PATCH] mesa: update to 17.1.6

[Andreas Müller]

On Fri, Aug 11, 2017 at 3:08 PM, Andrea Galbusera  wrote:
> On Thu, Aug 10, 2017 at 11:37 AM, Andreas Müller
>  wrote:
>>
>> Optional installation of khrplatform.h was implemented upstream by a
>> slightly
>> different approach ->
>> 0001-mapi-Only-install-khrplatform.h-with-EGL-or-GLES.patch
>> can be removed.
>>
>>
>> Signed-off-by: Andreas Müller 
>
>
> LGTM. Being reporting the issue that originated the here removed patch by
> Jussi, I build tested this commit on the original setup with
> meta-raspberrypi and everything still looks good.
>
ping
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] libsndfile1: Fix CVE-2017-8362

[jackie.huang]

From: Jackie Huang 

Backport the patch to fix CVE-2017-8362:

The flac_buffer_copy function in flac.c in libsndfile 1.0.28 allows
remote attackers to cause a denial of service (invalid read and
application crash) via a crafted audio file.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-8362

Signed-off-by: Jackie Huang 
---
 .../libsndfile/libsndfile1/CVE-2017-8362.patch | 59 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8362.patch

diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8362.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8362.patch
new file mode 100644
index 00..9ee7e46a6d
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8362.patch
@@ -0,0 +1,59 @@
+From ef1dbb2df1c0e741486646de40bd638a9c4cd808 Mon Sep 17 00:00:00 2001
+From: Erik de Castro Lopo 
+Date: Fri, 14 Apr 2017 15:19:16 +1000
+Subject: [PATCH] src/flac.c: Fix a buffer read overflow
+
+A file (generated by a fuzzer) which increased the number of channels
+from one frame to the next could cause a read beyond the end of the
+buffer provided by libFLAC. Only option is to abort the read.
+
+Closes: https://github.com/erikd/libsndfile/issues/231
+
+CVE: CVE-2017-8362
+
+Upstream-Status: Backport 
[https://github.com/erikd/libsndfile/commit/ef1dbb2df1c0e741486646de40bd638a9c4cd808]
+
+Signed-off-by: Jackie Huang 
+---
+ src/flac.c | 11 +--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/src/flac.c b/src/flac.c
+index 5a4f8c2..e4f9aaa 100644
+--- a/src/flac.c
 b/src/flac.c
+@@ -169,6 +169,14 @@ flac_buffer_copy (SF_PRIVATE *psf)
+   const int32_t* const *buffer = pflac->wbuffer ;
+   unsigned i = 0, j, offset, channels, len ;
+ 
++  if (psf->sf.channels != (int) frame->header.channels)
++  {   psf_log_printf (psf, "Error: FLAC frame changed from %d to %d 
channels\n"
++  
"Nothing to do but to error out.\n" ,
++  
psf->sf.channels, frame->header.channels) ;
++  psf->error = SFE_FLAC_CHANNEL_COUNT_CHANGED ;
++  return 0 ;
++  } ;
++
+   /*
+   **  frame->header.blocksize is variable and we're using a constant 
blocksize
+   **  of FLAC__MAX_BLOCK_SIZE.
+@@ -202,7 +210,6 @@ flac_buffer_copy (SF_PRIVATE *psf)
+   return 0 ;
+   } ;
+ 
+-
+   len = SF_MIN (pflac->len, frame->header.blocksize) ;
+ 
+   if (pflac->remain % channels != 0)
+@@ -436,7 +443,7 @@ sf_flac_meta_callback (const FLAC__StreamDecoder * UNUSED 
(decoder), const FLAC_
+   {   case FLAC__METADATA_TYPE_STREAMINFO :
+   if (psf->sf.channels > 0 && psf->sf.channels != (int) 
metadata->data.stream_info.channels)
+   {   psf_log_printf (psf, "Error: FLAC stream 
changed from %d to %d channels\n"
+-  
"Nothing to be but to error out.\n" ,
++  
"Nothing to do but to error out.\n" ,
+   
psf->sf.channels, metadata->data.stream_info.channels) ;
+   psf->error = SFE_FLAC_CHANNEL_COUNT_CHANGED ;
+   return ;
+-- 
+2.7.4
+
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index f80ce2fc99..2bd51b1cd9 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -8,6 +8,7 @@ LICENSE = "LGPLv2.1"
 SRC_URI = "http://www.mega-nerd.com/libsndfile/files/libsndfile-${PV}.tar.gz \
file://CVE-2017-6892.patch \
file://CVE-2017-8361-8365.patch \
+   file://CVE-2017-8362.patch \
   "
 
 SRC_URI[md5sum] = "646b5f98ce89ac60cdb060fcd398247c"
-- 
2.11.0

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

[OE-core] [PATCH 3/3] libsndfile1: Fix CVE-2017-8363

[jackie.huang]

From: Jackie Huang 

Backport the patch to fix CVE-2017-8363:

The flac_buffer_copy function in flac.c in libsndfile 1.0.28 allows
remote attackers to cause a denial of service (heap-based buffer
over-read and application crash) via a crafted audio file.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-8363

Signed-off-by: Jackie Huang 
---
 .../libsndfile/libsndfile1/CVE-2017-8363.patch | 37 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8363.patch

diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8363.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8363.patch
new file mode 100644
index 00..e526e5a346
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8363.patch
@@ -0,0 +1,37 @@
+From cd7da8dbf6ee4310d21d9e44b385d6797160d9e8 Mon Sep 17 00:00:00 2001
+From: Erik de Castro Lopo 
+Date: Wed, 12 Apr 2017 20:19:34 +1000
+Subject: [PATCH] src/flac.c: Fix another memory leak
+
+When the FLAC decoder was passed a malformed file, the associated
+`FLAC__StreamDecoder` object was not getting released.
+
+Closes: https://github.com/erikd/libsndfile/issues/233
+
+CVE: CVE-2017-8363
+
+Upstream-Status: Backport 
[https://github.com/erikd/libsndfile/commit/cd7da8dbf6ee4310d21d9e44b385d6797160d9e8]
+
+Signed-off-by: Jackie Huang 
+---
+ src/flac.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/flac.c b/src/flac.c
+index 986a7b8..5a4f8c2 100644
+--- a/src/flac.c
 b/src/flac.c
+@@ -841,7 +841,9 @@ flac_read_header (SF_PRIVATE *psf)
+ 
+   psf_log_printf (psf, "End\n") ;
+ 
+-  if (psf->error == 0)
++  if (psf->error != 0)
++  FLAC__stream_decoder_delete (pflac->fsd) ;
++  else
+   {   FLAC__uint64 position ;
+ 
+   FLAC__stream_decoder_get_decode_position (pflac->fsd, 
) ;
+-- 
+2.7.4
+
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index 2bd51b1cd9..281ac82e39 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -9,6 +9,7 @@ SRC_URI = 
"http://www.mega-nerd.com/libsndfile/files/libsndfile-${PV}.tar.gz \
file://CVE-2017-6892.patch \
file://CVE-2017-8361-8365.patch \
file://CVE-2017-8362.patch \
+   file://CVE-2017-8363.patch \
   "
 
 SRC_URI[md5sum] = "646b5f98ce89ac60cdb060fcd398247c"
-- 
2.11.0

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

[OE-core] [PATCH 1/3] libsndfile1: Fix CVE-2017-8361 and CVE-2017-8365

[jackie.huang]

From: Jackie Huang 

Backport the patch to fix two CVEs:

CVE-2017-8361:
The flac_buffer_copy function in flac.c in libsndfile 1.0.28 allows
remote attackers to cause a denial of service (buffer overflow and
application crash) or possibly have unspecified other impact via a
crafted audio file.

CVE-2017-8365:
The i2les_array function in pcm.c in libsndfile 1.0.28 allows remote
attackers to cause a denial of service (buffer over-read and application
crash) via a crafted audio file.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-8361
https://nvd.nist.gov/vuln/detail/CVE-2017-8365

Signed-off-by: Jackie Huang 
---
 .../libsndfile1/CVE-2017-8361-8365.patch   | 73 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 74 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8361-8365.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8361-8365.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8361-8365.patch
new file mode 100644
index 00..ac99516bb3
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8361-8365.patch
@@ -0,0 +1,73 @@
+From fd0484aba8e51d16af1e3a880f9b8b857b385eb3 Mon Sep 17 00:00:00 2001
+From: Erik de Castro Lopo 
+Date: Wed, 12 Apr 2017 19:45:30 +1000
+Subject: [PATCH] FLAC: Fix a buffer read overrun
+
+Buffer read overrun occurs when reading a FLAC file that switches
+from 2 channels to one channel mid-stream. Only option is to
+abort the read.
+
+Closes: https://github.com/erikd/libsndfile/issues/230
+
+CVE: CVE-2017-8361 CVE-2017-8365
+
+Upstream-Status: Backport 
[https://github.com/erikd/libsndfile/commit/fd0484aba8e51d16af1e3a880f9b8b857b385eb3]
+
+Signed-off-by: Jackie Huang 
+---
+ src/common.h  |  1 +
+ src/flac.c| 13 +
+ src/sndfile.c |  1 +
+ 3 files changed, 15 insertions(+)
+
+diff --git a/src/common.h b/src/common.h
+index 0bd810c..e2669b6 100644
+--- a/src/common.h
 b/src/common.h
+@@ -725,6 +725,7 @@ enum
+   SFE_FLAC_INIT_DECODER,
+   SFE_FLAC_LOST_SYNC,
+   SFE_FLAC_BAD_SAMPLE_RATE,
++  SFE_FLAC_CHANNEL_COUNT_CHANGED,
+   SFE_FLAC_UNKOWN_ERROR,
+ 
+   SFE_WVE_NOT_WVE,
+diff --git a/src/flac.c b/src/flac.c
+index 84de0e2..986a7b8 100644
+--- a/src/flac.c
 b/src/flac.c
+@@ -434,6 +434,19 @@ sf_flac_meta_callback (const FLAC__StreamDecoder * UNUSED 
(decoder), const FLAC_
+ 
+   switch (metadata->type)
+   {   case FLAC__METADATA_TYPE_STREAMINFO :
++  if (psf->sf.channels > 0 && psf->sf.channels != (int) 
metadata->data.stream_info.channels)
++  {   psf_log_printf (psf, "Error: FLAC stream 
changed from %d to %d channels\n"
++  
"Nothing to be but to error out.\n" ,
++  
psf->sf.channels, metadata->data.stream_info.channels) ;
++  psf->error = SFE_FLAC_CHANNEL_COUNT_CHANGED ;
++  return ;
++  } ;
++
++  if (psf->sf.channels > 0 && psf->sf.samplerate != (int) 
metadata->data.stream_info.sample_rate)
++  {   psf_log_printf (psf, "Warning: FLAC stream 
changed sample rates from %d to %d.\n"
++  
"Carrying on as if nothing happened.",
++  
psf->sf.samplerate, metadata->data.stream_info.sample_rate) ;
++  } ;
+   psf->sf.channels = metadata->data.stream_info.channels ;
+   psf->sf.samplerate = 
metadata->data.stream_info.sample_rate ;
+   psf->sf.frames = 
metadata->data.stream_info.total_samples ;
+diff --git a/src/sndfile.c b/src/sndfile.c
+index 4187561..e2a87be 100644
+--- a/src/sndfile.c
 b/src/sndfile.c
+@@ -245,6 +245,7 @@ ErrorStruct SndfileErrors [] =
+   {   SFE_FLAC_INIT_DECODER   , "Error : problem with initialization 
of the flac decoder." },
+   {   SFE_FLAC_LOST_SYNC  , "Error : flac decoder lost 
sync." },
+   {   SFE_FLAC_BAD_SAMPLE_RATE, "Error : flac does not support this 
sample rate." },
++  {   SFE_FLAC_CHANNEL_COUNT_CHANGED, "Error : flac channel changed 
mid stream." },
+   {   SFE_FLAC_UNKOWN_ERROR   , "Error : unknown error in flac 
decoder." },
+ 
+   {   SFE_WVE_NOT_WVE , "Error : not a WVE file." },
+-- 
+2.7.4
+
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index e6a92a2a41..f80ce2fc99 100644
--- 

[OE-core] [PATCH 0/3] libsndfile1: Fix several CVE issues

[jackie.huang]

From: Jackie Huang 

--
The following changes since commit 55bf88603927469de9aa9f6fd4d449230d2e61e3:

  poky: Add nios2 to list of qemu targets (2017-08-17 00:21:35 +0100)

are available in the git repository at:

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

Jackie Huang (3):
  libsndfile1: Fix CVE-2017-8361 and CVE-2017-8365
  libsndfile1: Fix CVE-2017-8362
  libsndfile1: Fix CVE-2017-8363

 .../libsndfile1/CVE-2017-8361-8365.patch   | 73 ++
 .../libsndfile/libsndfile1/CVE-2017-8362.patch | 59 +
 .../libsndfile/libsndfile1/CVE-2017-8363.patch | 37 +++
 .../libsndfile/libsndfile1_1.0.28.bb   |  3 +
 4 files changed, 172 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8361-8365.patch
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8362.patch
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-8363.patch

-- 
2.11.0

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

Re: [OE-core] [PATCH] pango: 1.40.6 -> 1.40.10

[Jussi Kukkonen]

On 17 August 2017 at 08:50, Huang Qiyu  wrote:

> 1) Upgrade pango from 1.40.6 to 1.40.10.
> 2) Modify 0001-Enforce-recreation-of-docs-pango.types-it-is-build-c.patch
> for pango 1.40.10.
>

I admit I didn't understand the patch even before this but especially now
that pango.types is apparently no longer shipped, how does the patch do
what it claims to do?

Jussi



>
> Signed-off-by: Huang Qiyu 
> ---
>  ...reation-of-docs-pango.types-it-is-build-c.patch | 104
> ++---
>  .../pango/{pango_1.40.6.bb => pango_1.40.10.bb}|   4 +-
>  2 files changed, 10 insertions(+), 98 deletions(-)
>  rename meta/recipes-graphics/pango/{pango_1.40.6.bb => pango_1.40.10.bb}
> (92%)
>
> diff --git a/meta/recipes-graphics/pango/pango/0001-Enforce-recreation-
> of-docs-pango.types-it-is-build-c.patch b/meta/recipes-graphics/pango/
> pango/0001-Enforce-recreation-of-docs-pango.types-it-is-build-c.patch
> index 6784a10..481f267 100644
> --- a/meta/recipes-graphics/pango/pango/0001-Enforce-recreation-
> of-docs-pango.types-it-is-build-c.patch
> +++ b/meta/recipes-graphics/pango/pango/0001-Enforce-recreation-
> of-docs-pango.types-it-is-build-c.patch
> @@ -1,6 +1,3 @@
> -From 526a6a9fc9a1cfe75c521c8bb39b61754fe42fe8 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Fri, 2 Sep 2016 14:00:24 +0300
>  Subject: [PATCH] Enforce recreation of docs/pango.types; it is build
>   configuration-specific.
>
> @@ -8,14 +5,15 @@ In particular, it needs to exclude references to
> PangoXft if Xft is not availabl
>
>  Upstream-Status: Pending
>  Signed-off-by: Alexander Kanavin 
> +
> +Update for pango 1.40.10.
> +Signed-off-by: Huang Qiyu 
>  ---
> - docs/Makefile.am | 17 
> - docs/pango.types | 80 --
> --
> - 2 files changed, 5 insertions(+), 92 deletions(-)
> - delete mode 100644 docs/pango.types
> + docs/Makefile.am | 17 +
> + 1 file changed, 5 insertions(+), 12 deletions(-)
>
>  diff --git a/docs/Makefile.am b/docs/Makefile.am
> -index f5f1317..8947a99 100644
> +index f5f1317..76b8661 100644
>  --- a/docs/Makefile.am
>  +++ b/docs/Makefile.am
>  @@ -49,6 +49,10 @@ IGNORE_HFILES=  \
> @@ -52,96 +50,10 @@ index f5f1317..8947a99 100644
> version.xml.in  \
>  -  check.docs  \
>  -  pango.types
> -+  check.docs
> ++check.docs
>
>   # force doc rebulid after configure
>   dist-hook-local: dist-local-check-no-cross-references all-local
> -diff --git a/docs/pango.types b/docs/pango.types
> -deleted file mode 100644
> -index 7d93cda..000
>  a/docs/pango.types
> -+++ /dev/null
> -@@ -1,80 +0,0 @@
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --#include 
> --
> --pango_alignment_get_type
> --pango_attr_list_get_type
> --pango_attr_type_get_type
> --pango_bidi_type_get_type
> --pango_cairo_fc_font_map_get_type
> --pango_cairo_font_get_type
> --pango_cairo_font_map_get_type
> --pango_color_get_type
> --pango_context_get_type
> --pango_coverage_level_get_type
> --pango_direction_get_type
> --pango_ellipsize_mode_get_type
> --pango_engine_get_type
> --pango_engine_lang_get_type
> --pango_engine_shape_get_type
> --pango_fc_decoder_get_type
> --pango_fc_font_get_type
> --pango_fc_font_map_get_type
> --pango_font_description_get_type
> --pango_font_face_get_type
> --pango_font_family_get_type
> --pango_font_get_type
> --pango_font_map_get_type
> --pango_font_mask_get_type
> --pango_font_metrics_get_type
> --pango_fontset_get_type
> --pango_fontset_simple_get_type
> --pango_ft2_font_map_get_type
> --pango_glyph_item_get_type
> --pango_glyph_item_iter_get_type
> --pango_glyph_string_get_type
> --pango_gravity_get_type
> --pango_gravity_hint_get_type
> --pango_item_get_type
> --pango_language_get_type
> --pango_layout_get_type
> --pango_layout_iter_get_type
> --pango_layout_line_get_type
> --pango_matrix_get_type
> --pango_ot_info_get_type
> --pango_ot_ruleset_get_type
> --pango_render_part_get_type
> --pango_renderer_get_type
> --pango_script_get_type
> --pango_stretch_get_type
> --pango_style_get_type
> --pango_tab_align_get_type
> --pango_tab_array_get_type
> --pango_underline_get_type
> --pango_variant_get_type
> --pango_weight_get_type
> --pango_wrap_mode_get_type
> --pango_xft_font_get_type
> --pango_xft_font_map_get_type
> --pango_xft_renderer_get_type
>  --
> -2.9.3
> +2.7.4
>
> diff --git a/meta/recipes-graphics/pango/pango_1.40.6.bb
> b/meta/recipes-graphics/pango/pango_1.40.10.bb
> similarity index 92%
> rename from 

[OE-core] [PATCH 1/1] cairo: Fix CVE-2017-9814

[Dengke Du]

Backport patch from the following link to fix CVE-2017-9814:

https://bugs.freedesktop.org/show_bug.cgi?id=101547

Signed-off-by: Dengke Du 
---
 .../cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch | 45 ++
 meta/recipes-graphics/cairo/cairo_1.14.10.bb   |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-graphics/cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch

diff --git 
a/meta/recipes-graphics/cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch 
b/meta/recipes-graphics/cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch
new file mode 100644
index 000..7d02ab9
--- /dev/null
+++ b/meta/recipes-graphics/cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch
@@ -0,0 +1,45 @@
+From 042421e9e3d266ad0bb7805132041ef51ad3234d Mon Sep 17 00:00:00 2001
+From: Adrian Johnson 
+Date: Wed, 16 Aug 2017 22:52:35 -0400
+Subject: [PATCH] cairo: Fix CVE-2017-9814
+
+The bug happens because in some scenarios the variable size can
+have a value of 0 at line 1288. And malloc(0) is not returning
+NULL as some people could expect:
+
+https://stackoverflow.com/questions/1073157/zero-size-malloc
+
+malloc(0) returns the smallest chunk possible. So the line 1290
+with the return is not execute. And the execution continues with
+an invalid map.
+
+Since the size is 0 the variable map is not initialized correctly
+at load_trutype_table. So, later when the variable map is accessed
+previous values from a freed chunk are used. This could allows an
+attacker to control the variable map.
+
+This patch have not merge in upstream now.
+
+Upstream-Status: Backport [https://bugs.freedesktop.org/show_bug.cgi?id=101547]
+CVE: CVE-2017-9814
+Signed-off-by: Dengke Du 
+---
+ src/cairo-truetype-subset.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/cairo-truetype-subset.c b/src/cairo-truetype-subset.c
+index e3449a0..f77d11c 100644
+--- a/src/cairo-truetype-subset.c
 b/src/cairo-truetype-subset.c
+@@ -1285,7 +1285,7 @@ _cairo_truetype_reverse_cmap (cairo_scaled_font_t 
*scaled_font,
+   return CAIRO_INT_STATUS_UNSUPPORTED;
+ 
+ size = be16_to_cpu (map->length);
+-map = malloc (size);
++map = _cairo_malloc (size);
+ if (unlikely (map == NULL))
+   return _cairo_error (CAIRO_STATUS_NO_MEMORY);
+ 
+-- 
+2.8.1
+
diff --git a/meta/recipes-graphics/cairo/cairo_1.14.10.bb 
b/meta/recipes-graphics/cairo/cairo_1.14.10.bb
index ba38c34..fcdddc6 100644
--- a/meta/recipes-graphics/cairo/cairo_1.14.10.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.14.10.bb
@@ -4,6 +4,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77"
 
 SRC_URI = "http://cairographics.org/releases/cairo-${PV}.tar.xz \
file://cairo-get_bitmap_surface-bsc1036789-CVE-2017-7475.diff \ 
+   file://0001-cairo-Fix-CVE-2017-9814.patch \
   "
 
 SRC_URI[md5sum] = "146f5f4d0b4439fc3792fd3452b7b12a"
-- 
2.8.1

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

[OE-core] [PATCH 0/1] cairo: Fix CVE-2017-9814

[Dengke Du]

The following changes since commit 55bf88603927469de9aa9f6fd4d449230d2e61e3:

  poky: Add nios2 to list of qemu targets (2017-08-17 00:21:35 +0100)

are available in the git repository at:

  https://github.com/DengkeDu/openembedded-core.git dengke/fix-CVE-2017-9814
  https://github.com//tree/dengke/fix-CVE-2017-9814

Dengke Du (1):
  cairo: Fix CVE-2017-9814

 .../cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch | 45 ++
 meta/recipes-graphics/cairo/cairo_1.14.10.bb   |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-graphics/cairo/cairo/0001-cairo-Fix-CVE-2017-9814.patch

-- 
2.8.1

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

Re: [OE-core] [PATCH 2/3] mesa: Enable gallium-llvm on x86 and x86_64

[Khem Raj]

On Wed, Aug 16, 2017 at 1:09 AM, Richard Purdie
 wrote:
> On Sun, 2017-08-13 at 20:24 -0700, Khem Raj wrote:
>> Signed-off-by: Khem Raj 
>> ---
>>  meta/recipes-graphics/cairo/cairo.inc | 3 ++-
>>  meta/recipes-graphics/mesa/mesa.inc   | 3 +++
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> I think this breaks on x32:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/1183/steps/BuildImages/logs/stdio
>

i cant reproduce this here i changed

-DEFAULTTUNE ?= "core2-64"
+DEFAULTTUNE ?= "core2-64-x32"


and built mesa and core-image-sato from scratch. all seems to build and boot ok

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