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

[juan . m . cruz . alcaraz]

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 | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index dd506a39e6..a37072a02c 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -32,6 +32,10 @@ class BuildSystem(object):
 
 corebase = os.path.abspath(self.d.getVar('COREBASE'))
 layers.append(corebase)
+# The bitbake build system uses the meta-skeleton layer as a layout
+# for common recipies, e.g: the recipetool script to create kernel 
recipies
+# Add the meta-skeleton layer to be included as part of the eSDK 
installation
+layers.append(os.path.join(corebase, 'meta-skeleton'))
 
 # Exclude layers
 for layer_exclude in self.layers_exclude:
@@ -123,6 +127,14 @@ class BuildSystem(object):
 line = line.replace('workspacelayer', 
workspace_newname)
 f.write(line)
 
+# meta-skeleton layer is added as part of the build system
+# but not as a layer included in the build, therefore it is
+# not reported to the function caller.
+for layer in layers_copied:
+if layer.endswith('/meta-skeleton'):
+layers_copied.remove(layer)
+break
+
 return layers_copied
 
 def generate_locked_sigs(sigfile, d):
-- 
2.12.3

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

Re: [OE-core] [PATCH v3 00/11] Reproducible binaries

[Bystricky, Juro]

Yes, the warning is legit. because the kernel sources are not obtained the 
usual way via do_unpack (that's where SOURCE_DATE_EPOCH is being determined). 
This has been addressed in kernel.bbclass, kernel_do_compile() .


From: Martin Jansa [martin.ja...@gmail.com]
Sent: Friday, August 18, 2017 1:32 PM
To: Bystricky, Juro
Cc: Patches and discussions about the oe-core layer; Richard Purdie; Joshua G 
Lock; Burton, Ross; Juro Bystricky
Subject: Re: [PATCH v3 00/11] Reproducible binaries

Thanks!

FWIW: I've refreshed the patches from ML and still see:
WARNING: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0 do_unpack: 
Unable to determine src_date_epoch! 
path:/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source



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

Re: [OE-core] [PATCH v3 00/11] Reproducible binaries

[Martin Jansa]

Thanks!

FWIW: I've refreshed the patches from ML and still see:
WARNING: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0 do_unpack:
Unable to determine src_date_epoch!
path:/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source



On Fri, Aug 18, 2017 at 8:27 PM, Bystricky, Juro 
wrote:

> I will resend the remaining patches, today & tomorrow. Obviously there are
> also some other changes, but the error you mention should be fixed. I will
> rebase them on the current master as of today
> (0bd2dd08e3daf284a6bb7757651af8d40393aec2)
>
>
> --
> *From:* Martin Jansa [martin.ja...@gmail.com]
> *Sent:* Friday, August 18, 2017 11:11 AM
> *To:* Bystricky, Juro
> *Cc:* Patches and discussions about the oe-core layer; Richard Purdie;
> Joshua G Lock; Burton, Ross; Juro Bystricky
> *Subject:* Re: [PATCH v3 00/11] Reproducible binaries
>
> I've seen that some of these patches were already merged to master.
>
> Can you please resend remaining patches for oe-core? I'm testing some
> slightly older version of your patches and I see couple recipes failing
> e.g. like this one:
> http://errors.yoctoproject.org/Errors/Details/151939/
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] shadow: fix CVE-2017-12424

[Randy MacLeod]

On 2017-08-16 07:34 AM, Jussi Kukkonen wrote:
On 16 August 2017 at 13:28, Chen Qi > wrote:


Backport a patch to fix CVE-2017-12424.

In shadow before 4.5, the newusers tool could be made to manipulate
internal data structures in ways unintended by the authors.

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


CVE: CVE-2017-12424


I don't object to the patch but I'm wondering if there is a reason we 
are taking the shadow sources from debian instead of the upstream 
github*? shadow 4.5 seems to have been out for months already but Debian 
hasn't taken it yet...


*) https://github.com/shadow-maint/shadow

Jussi



Good point. It's late in the release but maybe
not too late to update shadow.

Qi,
If you could give it a try and let us know if there are any
'gotchas' that would prevent or make the upgrade risky,
that would be great.


There are quite a few functional changes:
   $ git diff 4.2.1..4.5 etc lib libmisc man src | diffstat| tail -1
83 files changed, 4011 insertions(+), 2020 deletions(-)

and a HUGE number of other changes:
   $ git diff 4.2.1..4.5 | diffstat| tail -1
9818 files changed, 390853 insertions(+), 7556 deletions(-)

mainly in tests:
   $ git diff 4.2.1..4.5 tests/| diffstat| tail -1
9690 files changed, 369156 insertions(+)
that could, say just post-M3, be added as ptests.

../Randy




Signed-off-by: Chen Qi >
---
  .../shadow/files/0001-shadow-CVE-2017-12424| 46
++
  meta/recipes-extended/shadow/shadow.inc|  1 +
  2 files changed, 47 insertions(+)
  create mode 100644
meta/recipes-extended/shadow/files/0001-shadow-CVE-2017-12424

diff --git
a/meta/recipes-extended/shadow/files/0001-shadow-CVE-2017-12424
b/meta/recipes-extended/shadow/files/0001-shadow-CVE-2017-12424
new file mode 100644
index 000..4d3e1e0
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/0001-shadow-CVE-2017-12424
@@ -0,0 +1,46 @@
+From 954e3d2e7113e9ac06632aee3c69b8d818cc8952 Mon Sep 17 00:00:00 2001
+From: Tomas Mraz >
+Date: Fri, 31 Mar 2017 16:25:06 +0200
+Subject: [PATCH] Fix buffer overflow if NULL line is present in db.
+
+If ptr->line == NULL for an entry, the first cycle will exit,
+but the second one will happily write past entries buffer.
+We actually do not want to exit the first cycle prematurely
+on ptr->line == NULL.
+Signed-off-by: Tomas Mraz >
+
+CVE: CVE-2017-12424
+Upstream-Status: Backport
+Signed-off-by: Chen Qi >
+---
+ lib/commonio.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/lib/commonio.c b/lib/commonio.c
+index b10da06..31edbaa 100644
+--- a/lib/commonio.c
 b/lib/commonio.c
+@@ -751,16 +751,16 @@ commonio_sort (struct commonio_db *db, int
(*cmp) (const void *, const void *))
+   for (ptr = db->head;
+   (NULL != ptr)
+ #if KEEP_NIS_AT_END
+-   && (NULL != ptr->line)
+-   && (   ('+' != ptr->line[0])
+-   && ('-' != ptr->line[0]))
++   && ((NULL == ptr->line)
++   || (('+' != ptr->line[0])
++   && ('-' != ptr->line[0])))
+ #endif
+;
+ptr = ptr->next) {
+   n++;
+   }
+ #if KEEP_NIS_AT_END
+-  if ((NULL != ptr) && (NULL != ptr->line)) {
++  if (NULL != ptr) {
+   nis = ptr;
+   }
+ #endif
+--
+2.1.0
+
diff --git a/meta/recipes-extended/shadow/shadow.inc
b/meta/recipes-extended/shadow/shadow.inc
index 5e6b0bd..cc18964 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -16,6 +16,7 @@ SRC_URI =
"http://pkg-shadow.alioth.debian.org/releases/${BPN}-${PV}.tar.xz
 \

file://0001-Do-not-read-login.defs-before-doing-chroot.patch \

file://check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patch \

file://0001-useradd-copy-extended-attributes-of-home.patch \

+   file://0001-shadow-CVE-2017-12424 \
 ${@bb.utils.contains('PACKAGECONFIG', 'pam',
'${PAM_SRC_URI}', '', d)} \
 "

--
1.9.1

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

[OE-core] [PATCHv3] openssl10: rename back to openssl and make it the default via PREFERRED_VERSION

[Alexander Kanavin]

openssl 1.1 broke 3rd party layers a lot more than was expected; let's flip
the switch at the start of next development cycle.

Add a PROVIDES = "openssl10" to openssl 1.0 recipe; any dependency that is
not compatible with 1.1 should use that in its DEPENDS, as the 1.0
recipe will later be renamed back to openssl10. This does not always work:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140957.html
but for many recipes it does.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/default-versions.inc   |  3 +++
 ...0001-Fix-build-with-clang-using-external-assembler.patch |  0
 .../{openssl10 => openssl-1.0.2l}/Makefiles-ptest.patch |  0
 .../Use-SHA256-not-MD5-as-default-digest.patch  |  0
 .../configure-musl-target.patch |  0
 .../{openssl10 => openssl-1.0.2l}/configure-targets.patch   |  0
 .../debian/c_rehash-compat.patch|  0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/ca.patch   |  0
 .../debian/debian-targets.patch |  0
 .../{openssl10 => openssl-1.0.2l}/debian/man-dir.patch  |  0
 .../{openssl10 => openssl-1.0.2l}/debian/man-section.patch  |  0
 .../{openssl10 => openssl-1.0.2l}/debian/no-rpath.patch |  0
 .../{openssl10 => openssl-1.0.2l}/debian/no-symbolic.patch  |  0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/pic.patch  |  0
 .../debian/version-script.patch |  0
 .../debian1.0.2/block_digicert_malaysia.patch   |  0
 .../debian1.0.2/block_diginotar.patch   |  0
 .../{openssl10 => openssl-1.0.2l}/debian1.0.2/soname.patch  |  0
 .../debian1.0.2/version-script.patch|  0
 .../engines-install-in-libdir-ssl.patch |  0
 .../openssl/{openssl10 => openssl-1.0.2l}/find.pl   |  0
 .../openssl/{openssl10 => openssl-1.0.2l}/oe-ldflags.patch  |  0
 .../openssl-1.0.2a-x32-asm.patch|  0
 .../{openssl10 => openssl-1.0.2l}/openssl-c_rehash.sh   |  0
 .../openssl-fix-des.pod-error.patch |  0
 .../openssl-util-perlpath.pl-cwd.patch  |  0
 .../{openssl10 => openssl-1.0.2l}/openssl_fix_for_x32.patch |  0
 .../openssl/{openssl10 => openssl-1.0.2l}/parallel.patch|  0
 .../openssl/{openssl10 => openssl-1.0.2l}/ptest-deps.patch  |  0
 .../{openssl10 => openssl-1.0.2l}/ptest_makefile_deps.patch |  0
 .../openssl/{openssl10 => openssl-1.0.2l}/run-ptest |  0
 .../openssl/{openssl10 => openssl-1.0.2l}/shared-libs.patch |  0
 meta/recipes-connectivity/openssl/openssl10.inc | 13 ++---
 .../openssl/{openssl10_1.0.2l.bb => openssl_1.0.2l.bb}  |  0
 34 files changed, 5 insertions(+), 11 deletions(-)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/0001-Fix-build-with-clang-using-external-assembler.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/Makefiles-ptest.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/configure-musl-target.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/configure-targets.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/c_rehash-compat.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/ca.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/debian-targets.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/man-dir.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/man-section.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/no-rpath.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/no-symbolic.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/pic.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/version-script.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/block_digicert_malaysia.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/block_diginotar.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/soname.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/version-script.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/engines-install-in-libdir-ssl.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 

[OE-core] [PATCHv2] openssl10: rename back to openssl and make it the default via PREFERRED_VERSION

[Alexander Kanavin]

openssl 1.1 broke 3rd party layers a lot more than was expected; let's flip
the switch at the start of next development cycle.

Add a PROVIDES = "openssl10" to openssl 1.0 recipe; any dependency that is
not compatible with 1.1 should use that in its DEPENDS, as the 1.0
recipe will later be renamed back to openssl10. This does not always work:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140957.html
but for many recipes it does.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/default-versions.inc  | 3 +++
 .../0001-Fix-build-with-clang-using-external-assembler.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/Makefiles-ptest.patch| 0
 .../Use-SHA256-not-MD5-as-default-digest.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/configure-musl-target.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/configure-targets.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/c_rehash-compat.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/ca.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/debian-targets.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/man-dir.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/man-section.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/no-rpath.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/no-symbolic.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/pic.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/version-script.patch  | 0
 .../debian1.0.2/block_digicert_malaysia.patch  | 0
 .../{openssl10 => openssl-1.0.2l}/debian1.0.2/block_diginotar.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian1.0.2/soname.patch | 0
 .../{openssl10 => openssl-1.0.2l}/debian1.0.2/version-script.patch | 0
 .../{openssl10 => openssl-1.0.2l}/engines-install-in-libdir-ssl.patch  | 0
 .../recipes-connectivity/openssl/{openssl10 => openssl-1.0.2l}/find.pl | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/oe-ldflags.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/openssl-1.0.2a-x32-asm.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/openssl-c_rehash.sh  | 0
 .../{openssl10 => openssl-1.0.2l}/openssl-fix-des.pod-error.patch  | 0
 .../{openssl10 => openssl-1.0.2l}/openssl-util-perlpath.pl-cwd.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/openssl_fix_for_x32.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/parallel.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/ptest-deps.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/ptest_makefile_deps.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/run-ptest| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/shared-libs.patch| 0
 meta/recipes-connectivity/openssl/openssl10.inc| 2 ++
 .../openssl/{openssl10_1.0.2l.bb => openssl_1.0.2l.bb} | 0
 34 files changed, 5 insertions(+)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/0001-Fix-build-with-clang-using-external-assembler.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/Makefiles-ptest.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/configure-musl-target.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/configure-targets.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/c_rehash-compat.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/ca.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/debian-targets.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/man-dir.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/man-section.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/no-rpath.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/no-symbolic.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/pic.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/version-script.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/block_digicert_malaysia.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/block_diginotar.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/soname.patch 

[OE-core] [PATCH] prelink: Change the behavior to avoid checking USER_CLASSES

[Mark Hatle]

The behavior before this change was to check USER_CLASSES and adjust
the install script to return either exit 0 (don't do anything) or
exit 1 (run on first boot).  This enabled a user to include the prelink
package without enablign the image-prelink bbclass and get a first boot
prelink.

Checking USER_CLASSES is not desired, as an image should be able to simply
inherit the image-prelink and get the same type of behavior.  Modifying
the recipe based on the inclusion of a class is a bad idea as it makes
this style work more difficult.  So we move to a more defined strategy
based on exist uses.  (That we know of...)

If we ae doing a cross install, we want to avoid prelinking.
Prelinking during a cross install should be handled by the image-prelink
bbclass.  If the user desires this to run on the target at first boot
they will need to create a custom boot script.

[YOCTO #11169]

Signed-off-by: Mark Hatle 
---
 meta/recipes-devtools/prelink/prelink_git.bb | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/prelink/prelink_git.bb 
b/meta/recipes-devtools/prelink/prelink_git.bb
index 4529dbf..b739af0 100644
--- a/meta/recipes-devtools/prelink/prelink_git.bb
+++ b/meta/recipes-devtools/prelink/prelink_git.bb
@@ -150,13 +150,15 @@ do_install_append () {
install -m 0644 ${WORKDIR}/macros.prelink 
${D}${sysconfdir}/rpm/macros.prelink
 }
 
-# If we're using image-prelink, we want to skip this on the host side
-# but still do it if the package is installed on the target...
+# If we ae doing a cross install, we want to avoid prelinking.
+# Prelinking during a cross install should be handled by the image-prelink
+# bbclass.  If the user desires this to run on the target at first boot
+# they will need to create a custom boot script.
 pkg_postinst_prelink() {
 #!/bin/sh
 
 if [ "x$D" != "x" ]; then
-  ${@bb.utils.contains('USER_CLASSES', 'image-prelink', 'exit 0', 'exit 1', d)}
+  exit 0
 fi
 
 prelink -a
-- 
1.8.3.1

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

[OE-core] State of bitbake world, Failed tasks 2017-08-17

[Martin Jansa]

Another build with openssl-1.1.

Next build will use openssl-1.0 again.

http://www.openembedded.org/wiki/Bitbake_World_Status

== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!|Signatures !!colspan='14'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64||all   
||already-stripped  ||libdir||textrel   ||build-deps
||file-rdeps||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||ldflags   ||compile-host-path 
||  
|-
||2017-08-17||42||43||43||0 ||0 ||0 
||5 ||0 ||0 ||0 ||1 
||0 ||0 ||0 ||0 ||0 
||0 ||0 ||  
|}

== Failed tasks 2017-08-17 ==

INFO: jenkins-job.sh-1.8.25 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20170818_090627.log

=== common (40) ===
* meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
* 
meta-openembedded/meta-multimedia/recipes-dvb/oscam/oscam_svn.bb:do_compile
* 
meta-openembedded/meta-multimedia/recipes-multimedia/rtmpdump/rtmpdump_2.4.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-connectivity/lftp/lftp_4.7.7.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb:do_compile
* meta-openembedded/meta-networking/recipes-irc/znc/znc_git.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.3.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-protocols/nopoll/nopoll_0.4.2.b297.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-support/fetchmail/fetchmail_6.3.26.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-support/ipsec-tools/ipsec-tools_0.8.2.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-support/openvpn/openvpn_2.4.2.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-support/uftp/uftp_4.9.3.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/libtorrent/libtorrent_git.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/thrift/thrift_0.9.3.bb:do_compile
* meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvstreams_4.6.1.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-devtools/librcf/librcf_2.2.0.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-devtools/uw-imap/uw-imap_2007f.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-extended/boinc/boinc-client_7.6.33.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-extended/cfengine/cfengine_3.9.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-extended/openwsman/openwsman_2.6.2.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-extended/pam/pam-ssh-agent-auth_0.10.3.bb:do_compile
* meta-openembedded/meta-oe/recipes-support/asio/asio_1.10.6.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/freerdp/freerdp_git.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/ipmitool/ipmitool_1.8.18.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/libgit2/libgit2_0.24.3.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/liboauth/liboauth_1.0.3.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/libp11/libp11_0.4.0.bb:do_compile
* meta-openembedded/meta-oe/recipes-support/links/links_2.7.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/links/links-x11_2.7.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/opensc/opensc_0.16.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/pkcs11-helper/pkcs11-helper_1.11.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb:do_configure
* 
meta-openembedded/meta-oe/recipes-support/synergy/synergy_git.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-support/syslog-ng/syslog-ng_3.8.1.bb:do_compile
* 
meta-openembedded/meta-perl/recipes-perl/libcrypt/libcrypt-openssl-rsa-perl_0.28.bb:do_compile
* 
meta-openembedded/meta-python/recipes-devtools/python/python-m2crypto_0.26.0.bb:do_compile
* 
meta-openembedded/meta-python/recipes-devtools/python/python-matplotlib_1.1.0.bb:do_compile
* 
virtual:native:meta-openembedded/meta-python/recipes-devtools/python/python-m2crypto_0.26.0.bb:do_compile

=== common-x86 (2) ===
* 
meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_4.8.3.bb:do_compile
* 

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

[Mark Hatle]

On 8/18/17 1:41 PM, Alexander Kanavin wrote:
> On 08/18/2017 08:56 PM, Mark Hatle wrote:
>>> Even with that patch to rename openssl10 back to openssl we still need to 
>>> solve
>>> the openssl-native which wasn't reverted back to 1.0.
>>>
>>> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
>>> https://github.com/nodejs/node/pull/14761
>>
>> I wanted to pull out a specific comment from the above link that shows one of
>> the reasons why OpenSSL 1.1 support is delayed by many:
>>
>> 7 days ago: shigeki commented:
>>> We're also waiting for FIPS support of 1.1.x. They are now working on it as 
>>> https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...
>>
>> Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects (and 
>> major
>> distributions) are going to wait to deploy it.
> 
> What I don't understand is why node even cares about FIPS? FIPS 
> compliance is needed to win software supplier contracts with one certain 
> government; I haven't seen any other reasons.

Many governments and private company require this certification.  FIPS-140-2 is
the US NIST name for this work, but the same work resolves ISO requirements in
Europe and other countries.

Medical devices often requires FIPS certification in order to conform the
privacy requirements (or to be sold into US Government funded hospitals.)  FIPS
is really a big deal for many industries.

> Another point is that getting FIPS done will take a very long time, 
> possibly two years or more, and this work is just starting now with no 
> clear funding or completion date (see the openssl blog link). Meanwhile, 
> all major desktop linux distros have 1.1 by default already; seems to me 
> that they don't care.

Yes it will.  It will likely take 6 months to a year of development and likely
another 6 months to a year of certification lab work.

This is part of the reason the 1.0.2 EOL was set to end of 2019, to help force
the move to 1.1.  However, if you look at the 1.0.2 FIPS module, it has January
2022 EOL.  (Note, that EOL has a slightly different meaning then the 2019 1.0.2
one but the reality is that there will be organizations that will continue
to publish security fixes for OpenSSL 1.0.2 through the FIPS module EOL...
simply our of necessity.)

One of the key thing with this is that work can accelerate (likely not less then
a year) if additional people step up and assist in the funding.  I'm aware of a
few commercial companies that are discussing doing this, but unfortunately
nothing more concrete then the blog referenced above.)

> Alex
> 

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

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

[Carlos Alberto Lopez Perez]

On 18/08/17 08:38, Jussi Kukkonen wrote:
> There's also https://bugzilla.yoctoproject.org/show_bug.cgi?id=11792 about
> whether glib should bring in shared-mime-info so GIO file sniffing wouldn't
> be broken (the database is 3.6MB which is not a big number in a webkit
> context but can be for others).

This looks to me the best option.






signature.asc
Description: OpenPGP digital signature
-- 
___
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]

I don't know why they care about it, but yes it will take long time:
https://www.openssl.org/blog/blog/2017/08/17/fips/

On Fri, Aug 18, 2017 at 8:41 PM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 08/18/2017 08:56 PM, Mark Hatle wrote:
>
>> Even with that patch to rename openssl10 back to openssl we still need to
>>> solve
>>> the openssl-native which wasn't reverted back to 1.0.
>>>
>>> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as
>>> explained:
>>> https://github.com/nodejs/node/pull/14761
>>>
>>
>> I wanted to pull out a specific comment from the above link that shows
>> one of
>> the reasons why OpenSSL 1.1 support is delayed by many:
>>
>> 7 days ago: shigeki commented:
>>
>>> We're also waiting for FIPS support of 1.1.x. They are now working on it
>>> as https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...
>>>
>>
>> Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects
>> (and major
>> distributions) are going to wait to deploy it.
>>
>
> What I don't understand is why node even cares about FIPS? FIPS compliance
> is needed to win software supplier contracts with one certain government; I
> haven't seen any other reasons.
>
> Another point is that getting FIPS done will take a very long time,
> possibly two years or more, and this work is just starting now with no
> clear funding or completion date (see the openssl blog link). Meanwhile,
> all major desktop linux distros have 1.1 by default already; seems to me
> that they don't care.
>
> 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

[Alexander Kanavin]

On 08/18/2017 08:56 PM, Mark Hatle wrote:

Even with that patch to rename openssl10 back to openssl we still need to solve
the openssl-native which wasn't reverted back to 1.0.

Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
https://github.com/nodejs/node/pull/14761


I wanted to pull out a specific comment from the above link that shows one of
the reasons why OpenSSL 1.1 support is delayed by many:

7 days ago: shigeki commented:

We're also waiting for FIPS support of 1.1.x. They are now working on it as 
https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...


Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects (and major
distributions) are going to wait to deploy it.


What I don't understand is why node even cares about FIPS? FIPS 
compliance is needed to win software supplier contracts with one certain 
government; I haven't seen any other reasons.


Another point is that getting FIPS done will take a very long time, 
possibly two years or more, and this work is just starting now with no 
clear funding or completion date (see the openssl blog link). Meanwhile, 
all major desktop linux distros have 1.1 by default already; seems to me 
that they don't care.


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

[Alexander Kanavin]

On 08/18/2017 08:41 PM, Martin Jansa wrote:

openssl 1.1 goes out of upstream support on 2018-08-31 _more than a year
before_ 1.0.2 support, see:

https://www.openssl.org/policies/releasestrat.html
Version 1.1.0 will be supported until 2018-08-31.
Version 1.0.2 will be supported until 2019-12-31 (LTS).

Given its history of major security vulnerabilities, I hope you'll
remove openssl-1.1.0 even sooner than openssl-1.0.2.


openssl 1.1.1 should be released as soon as final TLS 1.3 spec is 
published. I expect it will go out of support much later than 1.1.0. I 
do not expect a situation where 1.0 is supported but 1.1.something is not.



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

Re: [OE-core] [RFC] recipe_links.bbclass: introduction

[Mark Asselstine]

On Friday, August 18, 2017 10:58:30 AM EDT Andre McCurdy wrote:
> On Fri, Aug 18, 2017 at 8:44 AM, Mark Asselstine
> 
>  wrote:
> > This is a new class which can be used (for example via USER_CLASSES in
> > local.conf) to make your build more development friendly. When
> > included this class will create symlinks to the various bb and
> > bbappend files in WORKDIR.
> > 
> > Normally when you are debugging or extending a package's recipe files
> > a developer will employ one of a few indirect techniques to determine
> > where bb and bbappends files associated with a recipe exist. For
> > example they might use bitbake-layers show-recipes or similar, or
> > simply rely on their experience to guide them. Even after working with
> > openembedded for serveral years now I find these techniques tedious
> > and time consuming, and sometimes even hit and miss.
> > 
> > Since the whereabouts of these files are already stored in various
> > files at parse time we can create symlinks to simplify the task of
> > finding these files, making them available in WORKDIR for easy
> > inpsection and in a convenient location if using devshel for instance.
> > 
> > For now this work is completely optional but we could conceivable make
> > this the default behavior if folks find it is convenient and the cost
> > of performing these operations across all builds is minimal enough.
> > 
> > recipe_links can safely be added to USER_CLASSES for existing builds,
> > care has been taken to avoid this action causing anything to be
> > rebuilt. After this has been added you can either 'bitbake  -C
> > unpack' or 'bitbake  -c create_recipe_links' to cause the
> > links to be created in the WORKDIR for the specified recipe.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> >  meta/classes/recipe_links.bbclass | 79
> >  +++ meta/conf/documentation.conf
> >   |  1 +
> >  2 files changed, 80 insertions(+)
> >  create mode 100644 meta/classes/recipe_links.bbclass
> > 
> > diff --git a/meta/classes/recipe_links.bbclass
> > b/meta/classes/recipe_links.bbclass new file mode 100644
> > index 000..ea97605
> > --- /dev/null
> > +++ b/meta/classes/recipe_links.bbclass
> > @@ -0,0 +1,79 @@
> > +# Create symlink in WORKDIR to the various bb and
> > +# bbappend files used to define the package ops
> > +
> > +# Create a symlink given src and dst paths
> > +def create_link(d, src, dst):
> > +if os.path.islink(dst):
> > +try:
> > +os.unlink(dst)
> > +except OSError as err:
> > +bb.error("  Failed to cleanup old link %s: %s"
> > + % (os.path.basename(dst),
> > os.strerror(err.errno))) +return False
> > +
> > +
> > +try:
> > +os.symlink(src, dst)
> > +except OSError as err:
> > +bb.error("  Failed to create file link for %s: %s"
> > + % (src, os.strerror(err.errno)))
> > +return False
> > +
> > +return True
> > +
> > +# Ensure the work is scheduled. We do this as a func
> > +# to avoid sig changes causing things to be rebuilt
> > +# when the class is added/removed after the fact.
> > +do_unpack[postfuncs] += "create_recipe_links "
> > +do_unpack[vardepsexclude] += "create_recipe_links "
> > +python create_recipe_links() {
> > +import re
> > +import glob
> > +
> > +workdir = d.getVar('WORKDIR')
> > +
> > +# Main recipe file
> > +bb.note("Add main recipe file link:")
> > +bb_path = d.getVar('FILE')
> > +bb_filename = os.path.basename(bb_path)
> > +bb_destname = "%s/%s" % (workdir, bb_filename)
> > +bb.note("  Linking %s" % bb_path)
> > +if not create_link(d, bb_path, bb_destname):
> > +return False
> > +
> > +# Cleanup old bbappends links
> > +bb.note("Removing old bbappend links:")
> > +pn = d.getVar('PN')
> > +files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
> > +files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
> > +for filename in files:
> > +bb.note("  Removing: %s" % filename)
> > +try:
> > +os.unlink(filename)
> > +except OSError as err:
> > +bb.error("  Failed to cleanup old link %s: %s" %
> > + (os.path.basename(filename),
> > os.strerror(err.errno))) +return False
> > +
> > +# Add bbappends links
> > +bb.note("Adding bbappend links:")
> > +included_files = d.getVar('BBINCLUDED').split()
> > +bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" %
> > re.escape(pn)) +for filename in included_files:
> > +if bbappend_re.match(filename):
> > +bb.note("  Linking %s" % filename)
> > +destname = "00_%s" % (os.path.basename(filename))
> > +while os.path.exists("%s/%s" % (workdir, destname)):
> > + destname = str(int(destname[:2]) + 1).zfill(2) +
> > 

Re: [OE-core] [PATCH v3 00/11] Reproducible binaries

[Bystricky, Juro]

I will resend the remaining patches, today & tomorrow. Obviously there are also 
some other changes, but the error you mention should be fixed. I will rebase 
them on the current master as of today
(0bd2dd08e3daf284a6bb7757651af8d40393aec2)



From: Martin Jansa [martin.ja...@gmail.com]
Sent: Friday, August 18, 2017 11:11 AM
To: Bystricky, Juro
Cc: Patches and discussions about the oe-core layer; Richard Purdie; Joshua G 
Lock; Burton, Ross; Juro Bystricky
Subject: Re: [PATCH v3 00/11] Reproducible binaries

I've seen that some of these patches were already merged to master.

Can you please resend remaining patches for oe-core? I'm testing some slightly 
older version of your patches and I see couple recipes failing e.g. like this 
one:
http://errors.yoctoproject.org/Errors/Details/151939/


-- 
___
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/18/2017 08:29 PM, Martin Jansa wrote:
Even with that patch to rename openssl10 back to openssl we still need 
to solve the openssl-native which wasn't reverted back to 1.0.


That was a simple oversight, I forgot to set PREFERRED_VERSION for 
native and nativesdk variants.



Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
https://github.com/nodejs/node/pull/14761
https://github.com/nodejs/node/pull/11828
so it would make sense to revert native and nativesdk versions as well - 
if it isn't done in oe-core, I'll do it in our own layers to keep the 
builds going.


I don't understand why nodejs fails for you with openssl10 dependency. 
Works totally fine for me here.


qtbase however does fail, but this will be solved in 5.10.

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

[Alexander Kanavin]

On 08/18/2017 05:41 PM, Khem Raj wrote:

FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.


no it doesnt try building nodejs-native.



Just tried. nodejs-native compiled and installed perfectly against 
openssl10-native.



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

Re: [OE-core] [PATCH v3 00/11] Reproducible binaries

[Martin Jansa]

I've seen that some of these patches were already merged to master.

Can you please resend remaining patches for oe-core? I'm testing some
slightly older version of your patches and I see couple recipes failing
e.g. like this one:
http://errors.yoctoproject.org/Errors/Details/151939/

On Wed, Aug 9, 2017 at 7:48 PM, Juro Bystricky 
wrote:

> This patch-set contains basic changes needed in order to support building
> of
> reproducible bianries. The set containes the following patches:
>
> 0001-reproducible_build.bbclass-initial-support-for-binar.patch
> 0002-image-prelink.bbclass-support-binary-reproducibility.patch
> 0003-rootfs-postcommands.bbclass-support-binary-reproduci.patch
> 0004-busybox.inc-improve-reproducibility.patch
> 0005-image.bbclass-support-binary-reproducibility.patch
> 0006-cpio-provide-cpio-replacement-native.patch
> 0007-image_types.bbclass-improve-cpio-image-reproducibili.patch
> 0008-python2.7-improve-reproducibility.patch
> 0009-python3-improve-reproducibility.patch
> 0010-kernel.bbclass-improve-reproducibility.patch
> 0011-poky-reproducible.conf-Initial-version.patch
>
> Using this patch set while building core-image minimal (two clean builds,
> same
> machine/OS, same date, two different folders, at two different times) I
> got the
> following results:
>
> Same:
>
> core-image-minimal-initramfs-qemux86
> bzImage-qemux86.bin
> vmlinux.gz-qemux86.bin
> (Some binaries i.e. ext4 differ, but the differnce is due to conversion to
> .ext4)
>
> Comparing Debian packages in tmp/deploy/deb:
>
> Same:  4005
> Different:  38
> Total: 4043
>
> (The remaining packages that still differ can be dealt with on an
> individual basis)
>
>
> Although the patches contain commit messages explaining the purpose and
> implementation,
> a somewhat more detailed description of selected patches seems prudent:
>
> 0001-reproducible_build.bbclass-initial-support-for-binar.patch
> ===
>
> This patch creates a new class "reproducible_build.bbclass",
> introducing two new variables:
>
> BUILD_REPRODUCIBLE_BINARIES: "0" (default) business as usual, "1" turn on
> various pieces of
> codes to improve reproducible builds
>
> REPRODUCIBLE_TIMESTAMP_ROOTFS: only used if BUILD_REPRODUCIBLE_BINARIES="
> 1".
> Catch-all timestamp for various rootfs files, pre-linker, etc. If needed,
> timestamps can
> be better granulated later on, right now we use a single value.
>
> Having a new variable BUILD_REPRODUCIBLE_BINARIES serves two purposes:
> 1. Lets user decide (there are minor trade-offs)
> 2. Setting to "0" will guarantee to cause zero regressions.
> 3. Setting to "1" will force the the environment to contain
> SOURCE_DATE_EPOCH
>
> BUILD_REPRODUCIBLE_BINARIES is globally exported, as this will initially
> force all kinds
> of rebuilds. I know no simple way around this, though. This variable is
> needed in numerous
> places: configuration, compilation, rootfs creation, packaging etc.
> REPRODUCIBLE_TIMESTAMP_ROOTFS does not need to be globally exported, it is
> exported locally
> based on the need.
> Once these variables are "official", various classes and recipes can be
> modified to conditionally
> support binary reproducibility.
>
> Setting SOURCE_DATE_EPOCH is essential for binary reproducibility.
> We need to set a recipe specific SOURCE_DATE_EPOCH in each recipe
> environment for various tasks.
> One way would be to modify all recipes one-by-one, but that is not
> realistic. So determining
> SOURCE_DATE_EPOCH is done in this class automatically: After sources are
> unpacked (but
> before they are patched), we try to determine the value for
> SOURCE_DATE_EPOCH.
>
> There are 4 ways to determine SOURCE_DATE_EPOCH:
> 1. Use value from src-data-epoch.txt file if this file exists. This file
> was most likely created
>   in the previous build by one of the following methods 2,3,4.
>   (But it could be actually provided by a recipe via SRC_URI)
>
> If the file does not exist:
> 2. Use .git last commit date timestamp (git does not allow checking out
> files and preserving their
>timestamps)
> 3. Use "known" files such as NEWS, CHANGLELOG, ...
> 4. Use the youngest file of the source tree.
>
> Once the value of SOURCE_DATE_EPOCH is determined, it is stored in the
> recipe source tree in
> a text file "src-date-epoch.txt'.
>
> If this file is found by other recipe task, the value is placed in the
> SOURCE_DATE_EPOCH var in
> the task environment. This is done in an anonymous python function, so
> SOURCE_DATE_EPOCH is
> guaranteed to exist for all tasks. (If the file is not found
> SOURCE_DATE_EPOCH is set to 0)
> This can optimized in the future, as some tasks (all tasks before fetch,
> tasks such as package QA,
> rm_work, ...) do not need SOURCE_DATE_EPOCH in the environment.
>
>
> 0008-python2.7-improve-reproducibility.patch
> 0009-python3-improve-reproducibility.patch
> 
> These are back 

Re: [OE-core] [RFC] recipe_links.bbclass: introduction

[Mark Hatle]

On 8/18/17 12:58 PM, Andre McCurdy wrote:
> On Fri, Aug 18, 2017 at 8:44 AM, Mark Asselstine
>  wrote:
>> This is a new class which can be used (for example via USER_CLASSES in
>> local.conf) to make your build more development friendly. When
>> included this class will create symlinks to the various bb and
>> bbappend files in WORKDIR.
>>
>> Normally when you are debugging or extending a package's recipe files
>> a developer will employ one of a few indirect techniques to determine
>> where bb and bbappends files associated with a recipe exist. For
>> example they might use bitbake-layers show-recipes or similar, or
>> simply rely on their experience to guide them. Even after working with
>> openembedded for serveral years now I find these techniques tedious
>> and time consuming, and sometimes even hit and miss.
>>
>> Since the whereabouts of these files are already stored in various
>> files at parse time we can create symlinks to simplify the task of
>> finding these files, making them available in WORKDIR for easy
>> inpsection and in a convenient location if using devshel for instance.
>>
>> For now this work is completely optional but we could conceivable make
>> this the default behavior if folks find it is convenient and the cost
>> of performing these operations across all builds is minimal enough.
>>
>> recipe_links can safely be added to USER_CLASSES for existing builds,
>> care has been taken to avoid this action causing anything to be
>> rebuilt. After this has been added you can either 'bitbake  -C
>> unpack' or 'bitbake  -c create_recipe_links' to cause the
>> links to be created in the WORKDIR for the specified recipe.
>>
>> Signed-off-by: Mark Asselstine 
>> ---
>>  meta/classes/recipe_links.bbclass | 79 
>> +++
>>  meta/conf/documentation.conf  |  1 +
>>  2 files changed, 80 insertions(+)
>>  create mode 100644 meta/classes/recipe_links.bbclass
>>
>> diff --git a/meta/classes/recipe_links.bbclass 
>> b/meta/classes/recipe_links.bbclass
>> new file mode 100644
>> index 000..ea97605
>> --- /dev/null
>> +++ b/meta/classes/recipe_links.bbclass
>> @@ -0,0 +1,79 @@
>> +# Create symlink in WORKDIR to the various bb and
>> +# bbappend files used to define the package ops
>> +
>> +# Create a symlink given src and dst paths
>> +def create_link(d, src, dst):
>> +if os.path.islink(dst):
>> +try:
>> +os.unlink(dst)
>> +except OSError as err:
>> +bb.error("  Failed to cleanup old link %s: %s"
>> + % (os.path.basename(dst), os.strerror(err.errno)))
>> +return False
>> +
>> +
>> +try:
>> +os.symlink(src, dst)
>> +except OSError as err:
>> +bb.error("  Failed to create file link for %s: %s"
>> + % (src, os.strerror(err.errno)))
>> +return False
>> +
>> +return True
>> +
>> +# Ensure the work is scheduled. We do this as a func
>> +# to avoid sig changes causing things to be rebuilt
>> +# when the class is added/removed after the fact.
>> +do_unpack[postfuncs] += "create_recipe_links "
>> +do_unpack[vardepsexclude] += "create_recipe_links "
>> +python create_recipe_links() {
>> +import re
>> +import glob
>> +
>> +workdir = d.getVar('WORKDIR')
>> +
>> +# Main recipe file
>> +bb.note("Add main recipe file link:")
>> +bb_path = d.getVar('FILE')
>> +bb_filename = os.path.basename(bb_path)
>> +bb_destname = "%s/%s" % (workdir, bb_filename)
>> +bb.note("  Linking %s" % bb_path)
>> +if not create_link(d, bb_path, bb_destname):
>> +return False
>> +
>> +# Cleanup old bbappends links
>> +bb.note("Removing old bbappend links:")
>> +pn = d.getVar('PN')
>> +files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
>> +files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
>> +for filename in files:
>> +bb.note("  Removing: %s" % filename)
>> +try:
>> +os.unlink(filename)
>> +except OSError as err:
>> +bb.error("  Failed to cleanup old link %s: %s" %
>> + (os.path.basename(filename), 
>> os.strerror(err.errno)))
>> +return False
>> +
>> +# Add bbappends links
>> +bb.note("Adding bbappend links:")
>> +included_files = d.getVar('BBINCLUDED').split()
>> +bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" % re.escape(pn))
>> +for filename in included_files:
>> +if bbappend_re.match(filename):
>> +bb.note("  Linking %s" % filename)
>> +destname = "00_%s" % (os.path.basename(filename))
>> +while os.path.exists("%s/%s" % (workdir, destname)):
>> + destname = str(int(destname[:2]) + 1).zfill(2) + 
>> destname[2:]
>> +if not create_link(d, filename, "%s/%s" % (workdir, destname)):
>> +return False
>> +
>> +

Re: [OE-core] [RFC] recipe_links.bbclass: introduction

[Andre McCurdy]

On Fri, Aug 18, 2017 at 8:44 AM, Mark Asselstine
 wrote:
> This is a new class which can be used (for example via USER_CLASSES in
> local.conf) to make your build more development friendly. When
> included this class will create symlinks to the various bb and
> bbappend files in WORKDIR.
>
> Normally when you are debugging or extending a package's recipe files
> a developer will employ one of a few indirect techniques to determine
> where bb and bbappends files associated with a recipe exist. For
> example they might use bitbake-layers show-recipes or similar, or
> simply rely on their experience to guide them. Even after working with
> openembedded for serveral years now I find these techniques tedious
> and time consuming, and sometimes even hit and miss.
>
> Since the whereabouts of these files are already stored in various
> files at parse time we can create symlinks to simplify the task of
> finding these files, making them available in WORKDIR for easy
> inpsection and in a convenient location if using devshel for instance.
>
> For now this work is completely optional but we could conceivable make
> this the default behavior if folks find it is convenient and the cost
> of performing these operations across all builds is minimal enough.
>
> recipe_links can safely be added to USER_CLASSES for existing builds,
> care has been taken to avoid this action causing anything to be
> rebuilt. After this has been added you can either 'bitbake  -C
> unpack' or 'bitbake  -c create_recipe_links' to cause the
> links to be created in the WORKDIR for the specified recipe.
>
> Signed-off-by: Mark Asselstine 
> ---
>  meta/classes/recipe_links.bbclass | 79 
> +++
>  meta/conf/documentation.conf  |  1 +
>  2 files changed, 80 insertions(+)
>  create mode 100644 meta/classes/recipe_links.bbclass
>
> diff --git a/meta/classes/recipe_links.bbclass 
> b/meta/classes/recipe_links.bbclass
> new file mode 100644
> index 000..ea97605
> --- /dev/null
> +++ b/meta/classes/recipe_links.bbclass
> @@ -0,0 +1,79 @@
> +# Create symlink in WORKDIR to the various bb and
> +# bbappend files used to define the package ops
> +
> +# Create a symlink given src and dst paths
> +def create_link(d, src, dst):
> +if os.path.islink(dst):
> +try:
> +os.unlink(dst)
> +except OSError as err:
> +bb.error("  Failed to cleanup old link %s: %s"
> + % (os.path.basename(dst), os.strerror(err.errno)))
> +return False
> +
> +
> +try:
> +os.symlink(src, dst)
> +except OSError as err:
> +bb.error("  Failed to create file link for %s: %s"
> + % (src, os.strerror(err.errno)))
> +return False
> +
> +return True
> +
> +# Ensure the work is scheduled. We do this as a func
> +# to avoid sig changes causing things to be rebuilt
> +# when the class is added/removed after the fact.
> +do_unpack[postfuncs] += "create_recipe_links "
> +do_unpack[vardepsexclude] += "create_recipe_links "
> +python create_recipe_links() {
> +import re
> +import glob
> +
> +workdir = d.getVar('WORKDIR')
> +
> +# Main recipe file
> +bb.note("Add main recipe file link:")
> +bb_path = d.getVar('FILE')
> +bb_filename = os.path.basename(bb_path)
> +bb_destname = "%s/%s" % (workdir, bb_filename)
> +bb.note("  Linking %s" % bb_path)
> +if not create_link(d, bb_path, bb_destname):
> +return False
> +
> +# Cleanup old bbappends links
> +bb.note("Removing old bbappend links:")
> +pn = d.getVar('PN')
> +files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
> +files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
> +for filename in files:
> +bb.note("  Removing: %s" % filename)
> +try:
> +os.unlink(filename)
> +except OSError as err:
> +bb.error("  Failed to cleanup old link %s: %s" %
> + (os.path.basename(filename), 
> os.strerror(err.errno)))
> +return False
> +
> +# Add bbappends links
> +bb.note("Adding bbappend links:")
> +included_files = d.getVar('BBINCLUDED').split()
> +bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" % re.escape(pn))
> +for filename in included_files:
> +if bbappend_re.match(filename):
> +bb.note("  Linking %s" % filename)
> +destname = "00_%s" % (os.path.basename(filename))
> +while os.path.exists("%s/%s" % (workdir, destname)):
> + destname = str(int(destname[:2]) + 1).zfill(2) + 
> destname[2:]
> +if not create_link(d, filename, "%s/%s" % (workdir, destname)):
> +return False
> +
> +return True
> +}
> +
> +# In addition to the func we want to make things able to be (re)run
> +# easily by the user so ensure it is available as a task.
> +addtask 

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

[Mark Hatle]

On 8/18/17 12:29 PM, Martin Jansa wrote:
> Even with that patch to rename openssl10 back to openssl we still need to 
> solve
> the openssl-native which wasn't reverted back to 1.0.
> 
> Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
> https://github.com/nodejs/node/pull/14761

I wanted to pull out a specific comment from the above link that shows one of
the reasons why OpenSSL 1.1 support is delayed by many:

7 days ago: shigeki commented:
> We're also waiting for FIPS support of 1.1.x. They are now working on it as 
> https://www.openssl.org/blog/blog/2017/07/25/fips/.> ...

Until the OpenSSL 1.1.x FIPS work is further along, a lot of projects (and major
distributions) are going to wait to deploy it.

--Mark

> https://github.com/nodejs/node/pull/11828
> so it would make sense to revert native and nativesdk versions as well - if it
> isn't done in oe-core, I'll do it in our own layers to keep the builds going.
> 
> On Fri, Aug 18, 2017 at 4:41 PM, Khem Raj  > wrote:
> 
> On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin
>  > wrote:
> > On 08/18/2017 08:56 AM, Khem Raj wrote:
> >
> >> 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
> >
> >
> > FWIW, nodejs from meta-oe does build just fine with openssl10 
> dependency.
> 
> no it doesnt try building nodejs-native.
> 
>  So
> > it's not exactly useless. And no one has established how many of the 
> other
> > 50 packages can be fixed by either doing that, or updating them to 
> latest
> > upstream releases.
> 
> Thats not going to solve everything. Neither does pointing to fedora 
> patches.
> 
> >
> > I'll send a patch that renames openssl10 recipe back to openssl and sets
> > that as a preferred version, so anyone can experiment with 1.1 without
> > widespread breakage.
> >
> > But at the start of next development cycle this will be reverted back; 
> no
> > more complaining then please, we have to do this at some point, and just
> > after a new cycle has started is as good time as it gets.
> 
> Just putting random deadlines is not going to solve this, there has to
> be some look
> at upstream packages and other distros switching to openssl11 and
> dropping openssl10
> completely. People have fielded products to support and they need some
> assurance of
> forward path, their ecosystem might involve a lot larger package set
> then just oe-core.
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> 
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 
> 
> 

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

[OE-core] [oe-core][PATCH 1/1] ruby: fix CVE-2017-922{6-9}

[Joe Slater]

CVE-2017-9226 : check too big code point value for single byte
CVE-2017-9227 : access to invalid address by reg->dmin value
CVE-2017-9228 : invalid state(CCS_VALUE) in parse_char_class()
CVE-2017-9229 : access to invalid address by reg->dmax value

Signed-off-by: Joe Slater 
---
 .../ruby/ruby/ruby-CVE-2017-9226.patch | 41 +++
 .../ruby/ruby/ruby-CVE-2017-9227.patch | 32 
 .../ruby/ruby/ruby-CVE-2017-9228.patch | 34 +
 .../ruby/ruby/ruby-CVE-2017-9229.patch | 59 ++
 meta/recipes-devtools/ruby/ruby_2.4.1.bb   |  4 ++
 5 files changed, 170 insertions(+)
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9226.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9227.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9228.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9229.patch

diff --git a/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9226.patch 
b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9226.patch
new file mode 100644
index 000..0f2a430
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9226.patch
@@ -0,0 +1,41 @@
+From b4bf968ad52afe14e60a2dc8a95d3555c543353a Mon Sep 17 00:00:00 2001
+From: "K.Kosako" 
+Date: Thu, 18 May 2017 17:05:27 +0900
+Subject: [PATCH] fix #55 : check too big code point value for single byte
+ value in next_state_val()
+
+---
+ regparse.c |3 +++
+ 1 file changed, 3 insertions(+)
+
+--- end of original header
+
+CVE: CVE-2017-9226
+
+Add check for octal number bigger than 255.
+
+Upstream-Status: Pending
+Signed-off-by: Joe Slater 
+
+
+--- ruby-2.4.1.orig/regparse.c
 ruby-2.4.1/regparse.c
+@@ -3644,7 +3644,7 @@ fetch_token(OnigToken* tok, UChar** src,
+   if (IS_SYNTAX_OP(syn, ONIG_SYN_OP_ESC_OCTAL3)) {
+   prev = p;
+   num = scan_unsigned_octal_number(, end, (c == '0' ? 2:3), enc);
+-  if (num < 0) return ONIGERR_TOO_BIG_NUMBER;
++  if (num < 0 || 0xff < num) return ONIGERR_TOO_BIG_NUMBER;
+   if (p == prev) {  /* can't read nothing. */
+ num = 0; /* but, it's not error */
+   }
+@@ -4450,6 +4450,9 @@ next_state_val(CClassNode* cc, CClassNod
+   switch (*state) {
+   case CCS_VALUE:
+ if (*type == CCV_SB) {
++  if (*vs > 0xff)
++  return ONIGERR_INVALID_CODE_POINT_VALUE;
++
+   BITSET_SET_BIT_CHKDUP(cc->bs, (int )(*vs));
+   if (IS_NOT_NULL(asc_cc))
+   BITSET_SET_BIT(asc_cc->bs, (int )(*vs));
diff --git a/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9227.patch 
b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9227.patch
new file mode 100644
index 000..85e7ccb
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9227.patch
@@ -0,0 +1,32 @@
+From 9690d3ab1f9bcd2db8cbe1fe3ee4a5da606b8814 Mon Sep 17 00:00:00 2001
+From: "K.Kosako" 
+Date: Tue, 23 May 2017 16:15:35 +0900
+Subject: [PATCH] fix #58 : access to invalid address by reg->dmin value
+
+---
+ regexec.c |2 ++
+ 1 file changed, 2 insertions(+)
+
+--- end of original header
+
+CVE: CVE-2017-9227
+
+Upstream-Status: Inappropriate [not author]
+Signed-off-by: Joe Slater 
+
+diff --git a/regexec.c b/regexec.c
+index d4e577d..2fa0f3d 100644
+--- a/regexec.c
 b/regexec.c
+@@ -3154,6 +3154,8 @@ forward_search_range(regex_t* reg, const UChar* str, 
const UChar* end, UChar* s,
+ }
+ else {
+   UChar *q = p + reg->dmin;
++
++  if (q >= end) return 0; /* fail */
+   while (p < q) p += enclen(reg->enc, p, end);
+ }
+   }
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9228.patch 
b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9228.patch
new file mode 100644
index 000..d8bfba4
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9228.patch
@@ -0,0 +1,34 @@
+From 3b63d12038c8d8fc278e81c942fa9bec7c704c8b Mon Sep 17 00:00:00 2001
+From: "K.Kosako" 
+Date: Wed, 24 May 2017 13:43:25 +0900
+Subject: [PATCH] fix #60 : invalid state(CCS_VALUE) in parse_char_class()
+
+---
+ regparse.c |4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- end of original header
+
+CVE: CVE-2017-9228
+
+Upstream-Status: Inappropriate [not author]
+Signed-off-by: Joe Slater 
+
+diff --git a/regparse.c b/regparse.c
+index 69875fa..1988747 100644
+--- a/regparse.c
 b/regparse.c
+@@ -4081,7 +4081,9 @@ next_state_class(CClassNode* cc, OnigCodePoint* vs, enum 
CCVALTYPE* type,
+ }
+   }
+ 
+-  *state = CCS_VALUE;
++  if (*state != CCS_START)
++*state = CCS_VALUE;
++
+   *type  = CCV_CLASS;
+   return 0;
+ }
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9229.patch 
b/meta/recipes-devtools/ruby/ruby/ruby-CVE-2017-9229.patch
new file mode 100644
index 000..6e765bf
--- /dev/null

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

[Martin Jansa]

On Thu, Aug 17, 2017 at 02:54:37PM +0300, 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.

openssl 1.1 goes out of upstream support on 2018-08-31 _more than a year
before_ 1.0.2 support, see:

https://www.openssl.org/policies/releasestrat.html
Version 1.1.0 will be supported until 2018-08-31.
Version 1.0.2 will be supported until 2019-12-31 (LTS).

Given its history of major security vulnerabilities, I hope you'll
remove openssl-1.1.0 even sooner than openssl-1.0.2.

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


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

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

[Martin Jansa]

Even with that patch to rename openssl10 back to openssl we still need to
solve the openssl-native which wasn't reverted back to 1.0.

Upstream nodejs isn't going to be openssl-1.1 for a bit longer as explained:
https://github.com/nodejs/node/pull/14761
https://github.com/nodejs/node/pull/11828
so it would make sense to revert native and nativesdk versions as well - if
it isn't done in oe-core, I'll do it in our own layers to keep the builds
going.

On Fri, Aug 18, 2017 at 4:41 PM, Khem Raj  wrote:

> On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin
>  wrote:
> > On 08/18/2017 08:56 AM, Khem Raj wrote:
> >
> >> 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
> >
> >
> > FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.
>
> no it doesnt try building nodejs-native.
>
>  So
> > it's not exactly useless. And no one has established how many of the
> other
> > 50 packages can be fixed by either doing that, or updating them to latest
> > upstream releases.
>
> Thats not going to solve everything. Neither does pointing to fedora
> patches.
>
> >
> > I'll send a patch that renames openssl10 recipe back to openssl and sets
> > that as a preferred version, so anyone can experiment with 1.1 without
> > widespread breakage.
> >
> > But at the start of next development cycle this will be reverted back; no
> > more complaining then please, we have to do this at some point, and just
> > after a new cycle has started is as good time as it gets.
>
> Just putting random deadlines is not going to solve this, there has to
> be some look
> at upstream packages and other distros switching to openssl11 and
> dropping openssl10
> completely. People have fielded products to support and they need some
> assurance of
> forward path, their ecosystem might involve a lot larger package set
> then just oe-core.
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] packagegroup-python3: add packagegroup

[Jose Lamego]

Please disregard this patch. The python3 recipe provides python-modules,
which includes all of the listed packages, making a new packagegroup
unnecessary.


On 08/15/2017 04:05 PM, Jose Lamego wrote:
> Many of the most usual python3 modules are missing when
> trying to import them to python3 in images built with
> python3-core installed.
>
> This change creates the python3 packagegroup, containing
> the most usual python3 packages to be installed for images
> featuring complete python functionality by using the
> FEATURES_PACKAGES variable to define python3 as a new feature
> and then adding it to the image to build.
>
> [YOCTO #10667]
>
> Signed-off-by: Jose Lamego 
> ---
>  .../packagegroups/packagegroup-python3.bb  | 85 
> ++
>  1 file changed, 85 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/packagegroups/packagegroup-python3.bb
>
> diff --git a/meta/recipes-devtools/packagegroups/packagegroup-python3.bb 
> b/meta/recipes-devtools/packagegroups/packagegroup-python3.bb
> new file mode 100644
> index 000..ab83460
> --- /dev/null
> +++ b/meta/recipes-devtools/packagegroups/packagegroup-python3.bb
> @@ -0,0 +1,85 @@
> +SUMMARY = "Provides a basic set of python3 packages"
> +
> +DEPENDS = "python3-native"
> +
> +PR = "1"
> +
> +inherit packagegroup
> +
> +RPROVIDES_${PN} = "python3"
> +
> +RDEPENDS_${PN} = "\
> +libpython3 \
> +libpython3-staticdev \
> +python3-pyvenv \
> +python3-dbg \
> +python3-2to3 \
> +python3-argparse \
> +python3-asyncio \
> +python3-audio \
> +python3-codecs \
> +python3-compile \
> +python3-compression \
> +python3-core \
> +python3-crypt \
> +python3-ctypes \
> +python3-curses \
> +python3-datetime \
> +python3-db \
> +python3-debugger \
> +python3-dev \
> +python3-difflib \
> +python3-distutils \
> +python3-doctest \
> +python3-email \
> +python3-enum \
> +python3-fcntl \
> +python3-gdbm \
> +python3-html \
> +python3-idle \
> +python3-image \
> +python3-importlib \
> +python3-io \
> +python3-json \
> +python3-lang \
> +python3-logging \
> +python3-mailbox \
> +python3-math \
> +python3-mime \
> +python3-mmap \
> +python3-multiprocessing \
> +python3-netclient \
> +python3-netserver \
> +python3-numbers \
> +python3-pickle \
> +python3-pkgutil \
> +python3-pprint \
> +python3-profile \
> +python3-pydoc \
> +python3-re \
> +python3-readline \
> +python3-reprlib \
> +python3-resource \
> +python3-selectors \
> +python3-shell \
> +python3-signal \
> +python3-smtpd \
> +python3-sqlite3 \
> +python3-sqlite3-tests \
> +python3-stringold \
> +python3-subprocess \
> +python3-syslog \
> +python3-terminal \
> +python3-tests \
> +python3-textutils \
> +python3-threading \
> +python3-tkinter \
> +python3-typing \
> +python3-unittest \
> +python3-unixadmin \
> +python3-xml \
> +python3-xmlrpc \
> +python3-modules \
> +python3-misc \
> +python3-man \
> +"

-- 
Jose Lamego | OTC Embedded Platform & Tools | GDC

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

Re: [OE-core] bussybox: updating to new version

[Leonardo Sandoval]

On Fri, 2017-08-18 at 12:16 +0200, Andrej Valek wrote:
> Hello everyone,
> 
> I would like to ask you a question about busybox upgrading.
> 
> Is there any reason, why we are still using the version 1.24.1?
> I think that, the latest version 1.27.2 has a lot of fixes and it less
> vulnerable then the current.
> 

feel free to send a patch with the upgrade. BTW, this is the upgrade
history of the recipe

http://recipes.yoctoproject.org/rrs/recipedetail/12601/

> I have checked a license and it has not been changed.
> 
> Thank you for the explanation.
> 
> Andrej


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

Re: [OE-core] bussybox: updating to new version

[Khem Raj]

On Fri, Aug 18, 2017 at 3:16 AM, Andrej Valek  wrote:
> Hello everyone,
>
> I would like to ask you a question about busybox upgrading.
>
> Is there any reason, why we are still using the version 1.24.1?
> I think that, the latest version 1.27.2 has a lot of fixes and it less
> vulnerable then the current.
>

I dont think its intentional. Feel free to send a patch if you can.

> I have checked a license and it has not been changed.
>
> Thank you for the explanation.
>
> Andrej
> --
> ___
> 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 V2] db: Add --tag parameter to libtool invocation

[Khem Raj]

Fix do_configure to be able to regenerate configure files

Use cross libtool as installed by OE, as done in normal autotooled recipes

These changes help in invoking the libtool with proper tags for C
and C++ compiler and linker invocation and not use same tag across all
different invocations

Fixes errors like
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'

Signed-off-by: Khem Raj 
---

v1 -> v2:
- Fix commit message

 ...dd-explicit-tag-options-to-libtool-invoca.patch | 42 ++
 meta/recipes-support/db/db_5.3.28.bb   | 23 
 2 files changed, 59 insertions(+), 6 deletions(-)
 create mode 100644 
meta/recipes-support/db/db/0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch

diff --git 
a/meta/recipes-support/db/db/0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch
 
b/meta/recipes-support/db/db/0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch
new file mode 100644
index 00..cb28db1343
--- /dev/null
+++ 
b/meta/recipes-support/db/db/0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch
@@ -0,0 +1,42 @@
+From 32e5943a3c4637d39e4d65b544dcb99e280210e3 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sun, 23 Jul 2017 10:54:26 -0700
+Subject: [PATCH] configure: Add explicit tag options to libtool invocation
+
+This helps cross compile when tag inference via heuristics
+fail because CC variable is having -fPIE -pie and libtool
+smartly removes it when building libraries
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj 
+---
+ dist/configure.ac | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/dist/configure.ac b/dist/configure.ac
+index 689f3b8..9c14bdb 100644
+--- a/dist/configure.ac
 b/dist/configure.ac
+@@ -366,12 +366,12 @@ LIBTOOL="./libtool"
+ 
+ INSTALLER="\$(LIBTOOL) --mode=install cp -p"
+ 
+-MAKEFILE_CC="\$(LIBTOOL) --mode=compile ${MAKEFILE_CC}"
+-MAKEFILE_SOLINK="\$(LIBTOOL) --mode=link ${MAKEFILE_CCLINK} -avoid-version"
+-MAKEFILE_CCLINK="\$(LIBTOOL) --mode=link ${MAKEFILE_CCLINK}"
+-MAKEFILE_CXX="\$(LIBTOOL) --mode=compile ${MAKEFILE_CXX}"
+-MAKEFILE_XSOLINK="\$(LIBTOOL) --mode=link ${MAKEFILE_CXXLINK} -avoid-version"
+-MAKEFILE_CXXLINK="\$(LIBTOOL) --mode=link ${MAKEFILE_CXXLINK}"
++MAKEFILE_CC="\$(LIBTOOL) --tag=CC --mode=compile ${MAKEFILE_CC}"
++MAKEFILE_SOLINK="\$(LIBTOOL) --tag=CC --mode=link ${MAKEFILE_CCLINK} 
-avoid-version"
++MAKEFILE_CCLINK="\$(LIBTOOL) --tag=CC --mode=link ${MAKEFILE_CCLINK}"
++MAKEFILE_CXX="\$(LIBTOOL) --tag=CXX --mode=compile ${MAKEFILE_CXX}"
++MAKEFILE_XSOLINK="\$(LIBTOOL) --tag=CXX --mode=link ${MAKEFILE_CXXLINK} 
-avoid-version"
++MAKEFILE_CXXLINK="\$(LIBTOOL) --tag=CXX --mode=link ${MAKEFILE_CXXLINK}"
+ 
+ 
+ case "$host_os" in
+-- 
+2.13.3
+
diff --git a/meta/recipes-support/db/db_5.3.28.bb 
b/meta/recipes-support/db/db_5.3.28.bb
index 7b158e9e2c..ab0d68fce5 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -22,6 +22,7 @@ SRC_URI = 
"http://download.oracle.com/berkeley-db/db-${PV}.tar.gz;
 SRC_URI += "file://arm-thumb-mutex_db5.patch \
 file://fix-parallel-build.patch \
 
file://0001-atomic-Rename-local-__atomic_compare_exchange-to-avo.patch \
+
file://0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch \
"
 # We are not interested in official latest 6.x versions;
 # let's track what debian is using.
@@ -76,22 +77,32 @@ MUTEX = ""
 MUTEX_arm = "${ARM_MUTEX}"
 MUTEX_armeb = "${ARM_MUTEX}"
 EXTRA_OECONF += "${MUTEX} STRIP=true"
-EXTRA_OEMAKE_append_class-target = " 
LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
+EXTRA_OEMAKE_append = " LIBTOOL=${HOST_SYS}-libtool"
 
+EXTRA_AUTORECONF += "--exclude=autoheader  -I ${S}/dist/aclocal 
-I${S}/dist/aclocal_java"
 AUTOTOOLS_SCRIPT_PATH = "${S}/dist"
 
 # Cancel the site stuff - it's set for db3 and destroys the
 # configure.
 CONFIG_SITE = ""
-do_configure() {
-cd ${B}
-   gnu-configize --force ${AUTOTOOLS_SCRIPT_PATH}
-   oe_runconf
+
+oe_runconf_prepend() {
+   . ${S}/dist/RELEASE
+   # Edit version information we couldn't pre-compute.
+   sed -i -e "s/__EDIT_DB_VERSION_FAMILY__/$DB_VERSION_FAMILY/g" \
+   -e "s/__EDIT_DB_VERSION_RELEASE__/$DB_VERSION_RELEASE/g" \
+   -e "s/__EDIT_DB_VERSION_MAJOR__/$DB_VERSION_MAJOR/g" \
+   -e "s/__EDIT_DB_VERSION_MINOR__/$DB_VERSION_MINOR/g" \
+   -e "s/__EDIT_DB_VERSION_PATCH__/$DB_VERSION_PATCH/g" \
+   -e "s/__EDIT_DB_VERSION_STRING__/$DB_VERSION_STRING/g" \
+   -e "s/__EDIT_DB_VERSION_FULL_STRING__/$DB_VERSION_FULL_STRING/g" \
+   -e "s/__EDIT_DB_VERSION_UNIQUE_NAME__/$DB_VERSION_UNIQUE_NAME/g" \
+   -e "s/__EDIT_DB_VERSION__/$DB_VERSION/g" ${S}/dist/configure
 }
 
 do_compile_prepend() {
 # Stop libtool adding RPATHs
-sed 

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

[Randy MacLeod]

On 2017-08-18 06:05 AM, Andrej Valek wrote:

OK thank You, so please merge it into these branches.


Add Armin, who maintains those branches:
   https://wiki.yoctoproject.org/wiki/Releases
Is Krogoth still maintained? It's listed at Stable in the link above.

../Randy





Regards,
Andrej

On 08/18/2017 11:35 AM, Richard Purdie wrote:

On Fri, 2017-08-18 at 08:26 +0200, Andrej Valek wrote:

Yes, for actual branch is not required. But for branches like krogoth
and morty, where HOSTTOOLS is not implemented, is this necessary.


Lets just apply this to krogoth/morty then...

Cheers,

Richard




--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

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

[OE-core] [RFC] recipe_links.bbclass: introduction

[Mark Asselstine]

This is a new class which can be used (for example via USER_CLASSES in
local.conf) to make your build more development friendly. When
included this class will create symlinks to the various bb and
bbappend files in WORKDIR.

Normally when you are debugging or extending a package's recipe files
a developer will employ one of a few indirect techniques to determine
where bb and bbappends files associated with a recipe exist. For
example they might use bitbake-layers show-recipes or similar, or
simply rely on their experience to guide them. Even after working with
openembedded for serveral years now I find these techniques tedious
and time consuming, and sometimes even hit and miss.

Since the whereabouts of these files are already stored in various
files at parse time we can create symlinks to simplify the task of
finding these files, making them available in WORKDIR for easy
inpsection and in a convenient location if using devshel for instance.

For now this work is completely optional but we could conceivable make
this the default behavior if folks find it is convenient and the cost
of performing these operations across all builds is minimal enough.

recipe_links can safely be added to USER_CLASSES for existing builds,
care has been taken to avoid this action causing anything to be
rebuilt. After this has been added you can either 'bitbake  -C
unpack' or 'bitbake  -c create_recipe_links' to cause the
links to be created in the WORKDIR for the specified recipe.

Signed-off-by: Mark Asselstine 
---
 meta/classes/recipe_links.bbclass | 79 +++
 meta/conf/documentation.conf  |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 meta/classes/recipe_links.bbclass

diff --git a/meta/classes/recipe_links.bbclass 
b/meta/classes/recipe_links.bbclass
new file mode 100644
index 000..ea97605
--- /dev/null
+++ b/meta/classes/recipe_links.bbclass
@@ -0,0 +1,79 @@
+# Create symlink in WORKDIR to the various bb and
+# bbappend files used to define the package ops
+
+# Create a symlink given src and dst paths
+def create_link(d, src, dst):
+if os.path.islink(dst):
+try:
+os.unlink(dst)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s"
+ % (os.path.basename(dst), os.strerror(err.errno)))
+return False
+
+
+try:
+os.symlink(src, dst)
+except OSError as err:
+bb.error("  Failed to create file link for %s: %s"
+ % (src, os.strerror(err.errno)))
+return False
+
+return True
+
+# Ensure the work is scheduled. We do this as a func
+# to avoid sig changes causing things to be rebuilt
+# when the class is added/removed after the fact.
+do_unpack[postfuncs] += "create_recipe_links "
+do_unpack[vardepsexclude] += "create_recipe_links "
+python create_recipe_links() {
+import re
+import glob
+
+workdir = d.getVar('WORKDIR')
+
+# Main recipe file
+bb.note("Add main recipe file link:")
+bb_path = d.getVar('FILE')
+bb_filename = os.path.basename(bb_path)
+bb_destname = "%s/%s" % (workdir, bb_filename)
+bb.note("  Linking %s" % bb_path)
+if not create_link(d, bb_path, bb_destname):
+return False
+
+# Cleanup old bbappends links
+bb.note("Removing old bbappend links:")
+pn = d.getVar('PN')
+files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
+files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
+for filename in files:
+bb.note("  Removing: %s" % filename)
+try:
+os.unlink(filename)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s" %
+ (os.path.basename(filename), os.strerror(err.errno)))
+return False
+
+# Add bbappends links
+bb.note("Adding bbappend links:")
+included_files = d.getVar('BBINCLUDED').split()
+bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" % re.escape(pn))
+for filename in included_files:
+if bbappend_re.match(filename):
+bb.note("  Linking %s" % filename)
+destname = "00_%s" % (os.path.basename(filename))
+while os.path.exists("%s/%s" % (workdir, destname)):
+ destname = str(int(destname[:2]) + 1).zfill(2) + destname[2:]
+if not create_link(d, filename, "%s/%s" % (workdir, destname)):
+return False
+
+return True
+}
+
+# In addition to the func we want to make things able to be (re)run
+# easily by the user so ensure it is available as a task.
+addtask do_create_recipe_links
+python do_create_recipe_links() {
+bb.build.exec_func("create_recipe_links", d)
+}
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index a55e283..5a8a07e 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -23,6 +23,7 @@ do_devshell[doc] = 

Re: [OE-core] [PATCH] db: Add --tag parameter to libtool invocation

[Richard Purdie]

On Fri, 2017-08-18 at 07:29 -0700, Khem Raj wrote:
> On Fri, Aug 18, 2017 at 2:52 AM, Richard Purdie
>  wrote:
> > 
> > On Tue, 2017-08-15 at 20:33 -0700, Khem Raj wrote:
> > > 
> > > Fixes errors like
> > > libtool: compile: unable to infer tagged configuration
> > > libtool: compile: specify a tag with `--tag'
> > The patch seems to do a bit more than this?
> > 
> Yes, now it can regenerate configure files like OE does normally.
> This
> change is needed
> for --tag param to work properly with libtool since it uses the cross
> libtool that is copies over from OE by do_configure in normal cases.

Can you update the commit message to mention that please?

I tend to get worried when patches do things in the commit which aren't
mentioned at all in the commit message!

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

[Khem Raj]

On Fri, Aug 18, 2017 at 3:53 AM, Alexander Kanavin
 wrote:
> On 08/18/2017 08:56 AM, Khem Raj wrote:
>
>> 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
>
>
> FWIW, nodejs from meta-oe does build just fine with openssl10 dependency.

no it doesnt try building nodejs-native.

 So
> it's not exactly useless. And no one has established how many of the other
> 50 packages can be fixed by either doing that, or updating them to latest
> upstream releases.

Thats not going to solve everything. Neither does pointing to fedora patches.

>
> I'll send a patch that renames openssl10 recipe back to openssl and sets
> that as a preferred version, so anyone can experiment with 1.1 without
> widespread breakage.
>
> But at the start of next development cycle this will be reverted back; no
> more complaining then please, we have to do this at some point, and just
> after a new cycle has started is as good time as it gets.

Just putting random deadlines is not going to solve this, there has to
be some look
at upstream packages and other distros switching to openssl11 and
dropping openssl10
completely. People have fielded products to support and they need some
assurance of
forward path, their ecosystem might involve a lot larger package set
then just oe-core.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] db: Add --tag parameter to libtool invocation

[Khem Raj]

On Fri, Aug 18, 2017 at 2:52 AM, Richard Purdie
 wrote:
> On Tue, 2017-08-15 at 20:33 -0700, Khem Raj wrote:
>> Fixes errors like
>> libtool: compile: unable to infer tagged configuration
>> libtool: compile: specify a tag with `--tag'
>
> The patch seems to do a bit more than this?
>

Yes, now it can regenerate configure files like OE does normally. This
change is needed
for --tag param to work properly with libtool since it uses the cross
libtool that is copies over from OE by do_configure in normal cases.

> Cheers,
>
> Richard
-- 
___
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 Fri, 2017-08-18 at 11:04 +0300, Markus Lehtonen wrote:
> Hi,
> 

Ok so basically I wasted my time on this profiling exercise. Thanks for
the clarification.



> Using selftest to measure the signing performance is fruitless. The effect of 
> using "chunks" really depends on the number of subpackages the recipe 
> produces. Selftest uses one of the smallest recipes , i.e. "ed", so you won't 
> see any difference. But with  hundreds of subpackages you get different 
> figures.
>- Markus
> 
> On 17/08/2017, 17.52, "Leonardo Sandoval" 
>  wrote:
> 
> 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
> 

[OE-core] [PATCH] dnf: fix "Unable to detect release version" warning

[Alexander Kanavin]

The release version was actually working correctly; it only makes
the warning work properly.

Signed-off-by: Alexander Kanavin 
---
 ...eck-conf.releasever-instead-of-releasever.patch | 31 ++
 meta/recipes-devtools/dnf/dnf_2.6.3.bb |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 
meta/recipes-devtools/dnf/dnf/0001-Check-conf.releasever-instead-of-releasever.patch

diff --git 
a/meta/recipes-devtools/dnf/dnf/0001-Check-conf.releasever-instead-of-releasever.patch
 
b/meta/recipes-devtools/dnf/dnf/0001-Check-conf.releasever-instead-of-releasever.patch
new file mode 100644
index 000..05f31415174
--- /dev/null
+++ 
b/meta/recipes-devtools/dnf/dnf/0001-Check-conf.releasever-instead-of-releasever.patch
@@ -0,0 +1,31 @@
+From 166833a88a928a574bf9143b9b65f544be482c77 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Fri, 18 Aug 2017 15:55:15 +0300
+Subject: [PATCH] Check conf.releasever instead of releasever
+
+The substitutions may actually set the conf.releasever correctly,
+and so the check should use that instead of the passed-in function
+parameter.
+
+Upstream-Status: Submitted 
[https://github.com/rpm-software-management/dnf/pull/901]
+Signed-off-by: Alexander Kanavin 
+---
+ dnf/cli/cli.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/dnf/cli/cli.py b/dnf/cli/cli.py
+index 2d63420c..167943b8 100644
+--- a/dnf/cli/cli.py
 b/dnf/cli/cli.py
+@@ -914,7 +914,7 @@ class Cli(object):
+ conf.releasever = releasever
+ subst = conf.substitutions
+ subst.update_from_etc(conf.installroot)
+-if releasever is None:
++if conf.releasever is None:
+ logger.warning(_("Unable to detect release version (use 
'--releasever' to specify "
+  "release version)"))
+ 
+-- 
+2.14.1
+
diff --git a/meta/recipes-devtools/dnf/dnf_2.6.3.bb 
b/meta/recipes-devtools/dnf/dnf_2.6.3.bb
index 51072901e4d..3ed6a74570f 100644
--- a/meta/recipes-devtools/dnf/dnf_2.6.3.bb
+++ b/meta/recipes-devtools/dnf/dnf_2.6.3.bb
@@ -10,6 +10,7 @@ SRC_URI = "git://github.com/rpm-software-management/dnf.git \
file://0001-Do-not-prepend-installroot-to-logdir.patch \
file://0001-Do-not-hardcode-etc-and-systemd-unit-directories.patch \
file://0001-Corretly-install-tmpfiles.d-configuration.patch \
+   file://0001-Check-conf.releasever-instead-of-releasever.patch \
"
 
 SRCREV = "be2585183ec4485ee4d5e121f242d8669296f065"
-- 
2.14.1

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

Re: [OE-core] [PATCH] Revert "kernel: Fix symlinks"

[Otavio Salvador]

On Wed, Aug 16, 2017 at 3:15 PM, Otavio Salvador
 wrote:
> This reverts commit c7bc46b9bc29dd0953ab8d63b50fa105bb66892e.
>
> The commit has broken the alternatives concept as it is managed by
> links controlled by the alternatives system. That said the failing
> case identified (which some bootloaders fail to load the file) seems
> to be due a misuse of the alternative system.
>
> Cc: Christopher Larson 
> Cc: Ross Burton 
> Signed-off-by: Otavio Salvador 

I ended forgetting to add the commit author on Cc. Adding now :-)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] openssl10: rename back to openssl and make it the default via PREFERRED_VERSION

[Alexander Kanavin]

openssl 1.1 broke 3rd party layers a lot more than was expected; let's flip
the switch at the start of next development cycle.

Add a PROVIDES = "openssl10" to openssl 1.0 recipe; any dependency that is
not compatible with 1.1 should use that in its DEPENDS, as the 1.0
recipe will later be renamed back to openssl10. This does not always work:
http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140957.html
but for many recipes it does.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/default-versions.inc   | 1 +
 .../0001-Fix-build-with-clang-using-external-assembler.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/Makefiles-ptest.patch | 0
 .../Use-SHA256-not-MD5-as-default-digest.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/configure-musl-target.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/configure-targets.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/c_rehash-compat.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/ca.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/debian-targets.patch   | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/man-dir.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/man-section.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/no-rpath.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/no-symbolic.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/pic.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian/version-script.patch   | 0
 .../debian1.0.2/block_digicert_malaysia.patch   | 0
 .../{openssl10 => openssl-1.0.2l}/debian1.0.2/block_diginotar.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/debian1.0.2/soname.patch  | 0
 .../{openssl10 => openssl-1.0.2l}/debian1.0.2/version-script.patch  | 0
 .../{openssl10 => openssl-1.0.2l}/engines-install-in-libdir-ssl.patch   | 0
 meta/recipes-connectivity/openssl/{openssl10 => openssl-1.0.2l}/find.pl | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/oe-ldflags.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/openssl-1.0.2a-x32-asm.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/openssl-c_rehash.sh   | 0
 .../{openssl10 => openssl-1.0.2l}/openssl-fix-des.pod-error.patch   | 0
 .../{openssl10 => openssl-1.0.2l}/openssl-util-perlpath.pl-cwd.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/openssl_fix_for_x32.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/parallel.patch| 0
 .../openssl/{openssl10 => openssl-1.0.2l}/ptest-deps.patch  | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/ptest_makefile_deps.patch | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/run-ptest | 0
 .../openssl/{openssl10 => openssl-1.0.2l}/shared-libs.patch | 0
 meta/recipes-connectivity/openssl/openssl10.inc | 2 ++
 .../openssl/{openssl10_1.0.2l.bb => openssl_1.0.2l.bb}  | 0
 34 files changed, 3 insertions(+)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/0001-Fix-build-with-clang-using-external-assembler.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/Makefiles-ptest.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/configure-musl-target.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/configure-targets.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/c_rehash-compat.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/ca.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/debian-targets.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/man-dir.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/man-section.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/no-rpath.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/no-symbolic.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/pic.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian/version-script.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/block_digicert_malaysia.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 
openssl-1.0.2l}/debian1.0.2/block_diginotar.patch (100%)
 rename meta/recipes-connectivity/openssl/{openssl10 => 

[OE-core] [PATCH] cve-check-tool: Fix progress bar patch for curl 7.55

[Jussi Kukkonen]

CURL_FORMAT_OFF_T does not seem to exist anymore, use
CURL_FORMAT_CURL_OFF_T instead. This works with old and new curl.

Signed-off-by: Jussi Kukkonen 
---
 .../files/0001-print-progress-in-percent-when-downloading-CVE-db.patch  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-devtools/cve-check-tool/files/0001-print-progress-in-percent-when-downloading-CVE-db.patch
 
b/meta/recipes-devtools/cve-check-tool/files/0001-print-progress-in-percent-when-downloading-CVE-db.patch
index 0510e3a..8ea6f68 100644
--- 
a/meta/recipes-devtools/cve-check-tool/files/0001-print-progress-in-percent-when-downloading-CVE-db.patch
+++ 
b/meta/recipes-devtools/cve-check-tool/files/0001-print-progress-in-percent-when-downloading-CVE-db.patch
@@ -38,7 +38,7 @@ index 06d4b30..0fe6d76 100644
 +if (dltotal && percent && percent->end >= percent->start) {
 +unsigned int diff = percent->end - percent->start;
 +if (diff) {
-+fprintf(stderr,"completed: "CURL_FORMAT_OFF_T"%%\r", 
percent->start + (diff * dlnow / dltotal));
++fprintf(stderr,"completed: 
%"CURL_FORMAT_CURL_OFF_T"%%\r", percent->start + (diff * dlnow / dltotal));
 +}
 +}
 +
-- 
2.1.4

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

Re: [OE-core] [PATCH] curl: upgrade to 7.55.1

[Jussi Kukkonen]

On 15 August 2017 at 00:09, Oleksandr Kravchuk  wrote:

> Signed-off-by: Oleksandr Kravchuk 
> ---
>  meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.55.1.bb} | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>  rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.55.1.bb} (92%)
>
> diff --git a/meta/recipes-support/curl/curl_7.54.1.bb
> b/meta/recipes-support/curl/curl_7.55.1.bb
> similarity index 92%
> rename from meta/recipes-support/curl/curl_7.54.1.bb
> rename to meta/recipes-support/curl/curl_7.55.1.bb
> index f42582a..0074a74 100644
> --- a/meta/recipes-support/curl/curl_7.54.1.bb
> +++ b/meta/recipes-support/curl/curl_7.55.1.bb
> @@ -14,8 +14,8 @@ SRC_URI = "http://curl.haxx.se/download/
> curl-${PV}.tar.bz2 \
>  #
>  SRC_URI += " file://configure_ac.patch"
>
> -SRC_URI[md5sum] = "6b6eb722f512e7a24855ff084f54fe55"
> -SRC_URI[sha256sum] = "fdfc4df2d001ee0c44ec071186e77
> 0046249263c491fcae48df0e1a3ca8f25a0"
> +SRC_URI[md5sum] = "8c153f282bbe482495214654cdcd4182"
> +SRC_URI[sha256sum] = "e5b1a92ed3b0c11f149886458fa06
> 3419500819f1610c020d62f25b8e4b16cfb"
>
>  CVE_PRODUCT = "libcurl"
>  inherit autotools pkgconfig binconfig multilib_header
> @@ -53,10 +53,6 @@ EXTRA_OECONF = " \
>  --without-nghttp2 \
>  "
>
> -do_install_append() {
> -   oe_multilib_header curl/curlbuild.h
> -}
> -
>

The lack of curlbuild.h leads to cve-check-tool build failure (this is with
7.55.0 but same should apply to 7.55.1):
https://autobuilder.yocto.io/builders/nightly-no-x11/
builds/416/steps/BuildImages/logs/stdio

The upstream cve-check-tool would probably not fail but we have a patched
in progress bar(?) that breaks. I'll send a a fix for cve-check-tool.

Jussi




>  do_install_append_class-target() {
> # cleanup buildpaths from curl-config
> sed -i -e 's,${STAGING_DIR_HOST},,g' ${D}${bindir}/curl-config
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] curl: upgrade to 7.55.1

[Maxin B. John]

Hi RP,

On Fri, Aug 18, 2017 at 12:34:52PM +0100, Richard Purdie wrote:
> On Mon, 2017-08-14 at 23:09 +0200, Oleksandr Kravchuk wrote:
> > Signed-off-by: Oleksandr Kravchuk 
> > ---
> >  meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.55.1.bb} | 8 ++--
> >  1 file changed, 2 insertions(+), 6 deletions(-)
> >  rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.55.1.bb} (92%)
> 
> https://autobuilder.yocto.io/builders/nightly-x32/builds/409/steps/BuildImages/logs/stdio
>

This log shows curl version 7.55.0 instead of 7.55.1 

> Cheers,
> 
> Richard
>

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

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

[Richard Purdie]

On Fri, 2017-08-18 at 12:33 +0100, Richard Purdie wrote:
> On Fri, 2017-08-18 at 11:23 +0100, Richard Purdie wrote:
> > 
> > On Thu, 2017-08-17 at 10:11 -0700, Alejandro Hernandez wrote:
> > > 
> > > 
> > > 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.
> > https://autobuilder.yocto.io/builders/build-appliance/builds/416/steps/BuildImages_1/logs/stdio
> https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/68/steps/Running%20Sanity%20Tests/logs/stdio
> 
> (no fcntl module)

https://autobuilder.yocto.io/builders/buildtools/builds/409/steps/BuildImages/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] curl: upgrade to 7.55.1

[Richard Purdie]

On Mon, 2017-08-14 at 23:09 +0200, Oleksandr Kravchuk wrote:
> Signed-off-by: Oleksandr Kravchuk 
> ---
>  meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.55.1.bb} | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>  rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.55.1.bb} (92%)

https://autobuilder.yocto.io/builders/nightly-x32/builds/409/steps/BuildImages/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 0/3] Restructure python2 and python3 packaging system

[Richard Purdie]

On Fri, 2017-08-18 at 11:23 +0100, Richard Purdie wrote:
> On Thu, 2017-08-17 at 10:11 -0700, Alejandro Hernandez wrote:
> > 
> > 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.
> https://autobuilder.yocto.io/builders/build-appliance/builds/416/steps/BuildImages_1/logs/stdio

https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/68/steps/Running%20Sanity%20Tests/logs/stdio

(no fcntl module)

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/18/2017 08:56 AM, Khem Raj wrote:


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


FWIW, nodejs from meta-oe does build just fine with openssl10 
dependency. So it's not exactly useless. And no one has established how 
many of the other 50 packages can be fixed by either doing that, or 
updating them to latest upstream releases.


I'll send a patch that renames openssl10 recipe back to openssl and sets 
that as a preferred version, so anyone can experiment with 1.1 without 
widespread breakage.


But at the start of next development cycle this will be reverted back; 
no more complaining then please, we have to do this at some point, and 
just after a new cycle has started is as good time as it gets.



Alex
--
___
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

[Andrej Valek]

OK thank You, so please merge it into these branches.

Regards,
Andrej

On 08/18/2017 11:35 AM, Richard Purdie wrote:
> On Fri, 2017-08-18 at 08:26 +0200, Andrej Valek wrote:
>> Yes, for actual branch is not required. But for branches like krogoth
>> and morty, where HOSTTOOLS is not implemented, is this necessary.
> 
> Lets just apply this to krogoth/morty then...
> 
> Cheers,
> 
> Richard
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Richard Purdie]

On Thu, 2017-08-17 at 10:11 -0700, Alejandro Hernandez wrote:
> 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.

https://autobuilder.yocto.io/builders/build-appliance/builds/416/steps/BuildImages_1/logs/stdio

Cheers,

Richard


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

[OE-core] bussybox: updating to new version

[Andrej Valek]

Hello everyone,

I would like to ask you a question about busybox upgrading.

Is there any reason, why we are still using the version 1.24.1?
I think that, the latest version 1.27.2 has a lot of fixes and it less
vulnerable then the current.

I have checked a license and it has not been changed.

Thank you for the explanation.

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

[OE-core] [PATCH 2/2] qemu conf: replace deprecated option with new option

[Chen Qi]

Replace the deprecated '-usbdevice' option with '-device usb-xx' option.
This would fix runqemu boot error like below.

  '-usbdevice' is deprecated, please use '-device usb-...' instead

Signed-off-by: Chen Qi 
---
 meta/conf/machine/include/qemuboot-mips.inc | 2 +-
 meta/conf/machine/include/qemuboot-x86.inc  | 2 +-
 meta/conf/machine/qemuarm.conf  | 2 +-
 meta/conf/machine/qemuppc.conf  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index 0c60cf2..7d9fa52 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -4,5 +4,5 @@ QB_MEM = "-m 256"
 QB_MACHINE = "-machine malta"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
-QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -usbdevice tablet -device 
virtio-rng-pci"
+QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet -device 
virtio-rng-pci"
 QB_SYSTEM_NAME = "qemu-system-${TUNE_ARCH}"
diff --git a/meta/conf/machine/include/qemuboot-x86.inc 
b/meta/conf/machine/include/qemuboot-x86.inc
index acf9d55..0596e2e 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -12,7 +12,7 @@ QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE} 
oprofile.timer=1 uvesafb.task_timeout=-1"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
-QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device 
virtio-rng-pci"
+QB_OPT_APPEND = "-vga vmware -show-cursor -usb -device usb-tablet -device 
virtio-rng-pci"
 
 KERNEL_MODULE_AUTOLOAD += "uvesafb"
 KERNEL_MODULE_PROBECONF += "uvesafb"
diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
index 6b875e4..1f0a65f 100644
--- a/meta/conf/machine/qemuarm.conf
+++ b/meta/conf/machine/qemuarm.conf
@@ -15,6 +15,6 @@ QB_SYSTEM_NAME = "qemu-system-arm"
 QB_MACHINE = "-machine versatilepb"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,115200 console=tty"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
-QB_OPT_APPEND = "-show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
+QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet -device virtio-rng-pci"
 PREFERRED_VERSION_linux-yocto ??= "4.10%"
 QB_DTB = "${@base_version_less_or_equal('PREFERRED_VERSION_linux-yocto', 
'4.7', '', 'zImage-versatile-pb.dtb', d)}"
diff --git a/meta/conf/machine/qemuppc.conf b/meta/conf/machine/qemuppc.conf
index a9ef64b..537b2f6 100644
--- a/meta/conf/machine/qemuppc.conf
+++ b/meta/conf/machine/qemuppc.conf
@@ -17,5 +17,5 @@ QB_MACHINE = "-machine mac99"
 QB_CPU = "-cpu G4"
 QB_KERNEL_CMDLINE_APPEND = "console=tty console=ttyS0"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
-QB_OPT_APPEND = "-show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
+QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet -device virtio-rng-pci"
 QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
-- 
1.9.1

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

[OE-core] [PATCH 1/2] qemu: backport patches to fix boot failure

[Chen Qi]

Backport two patches to fix the following error when booting qemu.

  Failed to unlock byte 100

Signed-off-by: Chen Qi 
---
 ...0001-osdep-Add-runtime-OFD-lock-detection.patch | 141 +
 ...e-posix-Do-runtime-check-for-ofd-lock-API.patch |  71 +++
 meta/recipes-devtools/qemu/qemu_2.10.0-rc2.bb  |   2 +
 3 files changed, 214 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0002-file-posix-Do-runtime-check-for-ofd-lock-API.patch

diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
new file mode 100644
index 000..f83f0d2
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
@@ -0,0 +1,141 @@
+From ca749954b09b89e22cd69c4949fb7e689b057963 Mon Sep 17 00:00:00 2001
+From: Fam Zheng 
+Date: Fri, 11 Aug 2017 19:44:46 +0800
+Subject: [PATCH 1/2] osdep: Add runtime OFD lock detection
+
+Build time check of OFD lock is not sufficient and can cause image open
+errors when the runtime environment doesn't support it.
+
+Add a helper function to probe it at runtime, additionally. Also provide
+a qemu_has_ofd_lock() for callers to check the status.
+
+Signed-off-by: Fam Zheng 
+Signed-off-by: Kevin Wolf 
+
+Upstream-Status: Backport
+Signed-off-by: Chen Qi 
+---
+ include/qemu/osdep.h |  1 +
+ util/osdep.c | 66 
+ 2 files changed, 57 insertions(+), 10 deletions(-)
+
+diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
+index 3b74f6fcb2..6855b94bbf 100644
+--- a/include/qemu/osdep.h
 b/include/qemu/osdep.h
+@@ -357,6 +357,7 @@ int qemu_dup(int fd);
+ int qemu_lock_fd(int fd, int64_t start, int64_t len, bool exclusive);
+ int qemu_unlock_fd(int fd, int64_t start, int64_t len);
+ int qemu_lock_fd_test(int fd, int64_t start, int64_t len, bool exclusive);
++bool qemu_has_ofd_lock(void);
+ 
+ #if defined(__HAIKU__) && defined(__i386__)
+ #define FMT_pid "%ld"
+diff --git a/util/osdep.c b/util/osdep.c
+index a2863c8e53..a479fedc4a 100644
+--- a/util/osdep.c
 b/util/osdep.c
+@@ -38,14 +38,6 @@ extern int madvise(caddr_t, size_t, int);
+ #include "qemu/error-report.h"
+ #include "monitor/monitor.h"
+ 
+-#ifdef F_OFD_SETLK
+-#define QEMU_SETLK F_OFD_SETLK
+-#define QEMU_GETLK F_OFD_GETLK
+-#else
+-#define QEMU_SETLK F_SETLK
+-#define QEMU_GETLK F_GETLK
+-#endif
+-
+ static bool fips_enabled = false;
+ 
+ static const char *hw_version = QEMU_HW_VERSION;
+@@ -82,6 +74,10 @@ int qemu_madvise(void *addr, size_t len, int advice)
+ }
+ 
+ #ifndef _WIN32
++
++static int fcntl_op_setlk = -1;
++static int fcntl_op_getlk = -1;
++
+ /*
+  * Dups an fd and sets the flags
+  */
+@@ -149,6 +145,54 @@ static int qemu_parse_fdset(const char *param)
+ return qemu_parse_fd(param);
+ }
+ 
++static void qemu_probe_lock_ops(void)
++{
++if (fcntl_op_setlk == -1) {
++#ifdef F_OFD_SETLK
++int fd;
++int ret;
++struct flock fl = {
++.l_whence = SEEK_SET,
++.l_start  = 0,
++.l_len= 0,
++.l_type   = F_WRLCK,
++};
++
++fd = open("/dev/null", O_RDWR);
++if (fd < 0) {
++fprintf(stderr,
++"Failed to open /dev/null for OFD lock probing: %s\n",
++strerror(errno));
++fcntl_op_setlk = F_SETLK;
++fcntl_op_getlk = F_GETLK;
++return;
++}
++ret = fcntl(fd, F_OFD_GETLK, );
++close(fd);
++if (!ret) {
++fcntl_op_setlk = F_OFD_SETLK;
++fcntl_op_getlk = F_OFD_GETLK;
++} else {
++fcntl_op_setlk = F_SETLK;
++fcntl_op_getlk = F_GETLK;
++}
++#else
++fcntl_op_setlk = F_SETLK;
++fcntl_op_getlk = F_GETLK;
++#endif
++}
++}
++
++bool qemu_has_ofd_lock(void)
++{
++qemu_probe_lock_ops();
++#ifdef F_OFD_SETLK
++return fcntl_op_setlk == F_OFD_SETLK;
++#else
++return false;
++#endif
++}
++
+ static int qemu_lock_fcntl(int fd, int64_t start, int64_t len, int fl_type)
+ {
+ int ret;
+@@ -158,7 +202,8 @@ static int qemu_lock_fcntl(int fd, int64_t start, int64_t 
len, int fl_type)
+ .l_len= len,
+ .l_type   = fl_type,
+ };
+-ret = fcntl(fd, QEMU_SETLK, );
++qemu_probe_lock_ops();
++ret = fcntl(fd, fcntl_op_setlk, );
+ return ret == -1 ? -errno : 0;
+ }
+ 
+@@ -181,7 +226,8 @@ int qemu_lock_fd_test(int fd, int64_t start, int64_t len, 
bool exclusive)
+ .l_len= len,
+ .l_type   = exclusive ? F_WRLCK : F_RDLCK,
+ };
+-ret = fcntl(fd, QEMU_GETLK, );
++qemu_probe_lock_ops();
++ret = fcntl(fd, fcntl_op_getlk, );
+ 

[OE-core] [PATCH 0/2] Fix runqemu startup failure

[Chen Qi]

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 ChenQi/runqemu_boot_error
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/runqemu_boot_error

Chen Qi (2):
  qemu: backport patches to fix boot failure
  qemu conf: replace deprecated option with new option

 meta/conf/machine/include/qemuboot-mips.inc|   2 +-
 meta/conf/machine/include/qemuboot-x86.inc |   2 +-
 meta/conf/machine/qemuarm.conf |   2 +-
 meta/conf/machine/qemuppc.conf |   2 +-
 ...0001-osdep-Add-runtime-OFD-lock-detection.patch | 141 +
 ...e-posix-Do-runtime-check-for-ofd-lock-API.patch |  71 +++
 meta/recipes-devtools/qemu/qemu_2.10.0-rc2.bb  |   2 +
 7 files changed, 218 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0002-file-posix-Do-runtime-check-for-ofd-lock-API.patch

-- 
1.9.1

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

Re: [OE-core] [PATCH] oe/path.py: copyhardlinktree: don't overwrite existing symlinks

[Richard Purdie]

On Wed, 2017-08-16 at 14:13 +0300, Ioan-Adrian Ratiu wrote:
> Starting with tar>=1.26 the default behaviour when extracting is to
> overwrite symlinks and a '-h' flag was added for tar to follow them.
> 
> The primary use case for this is to allow ${DEPLOY_DIR_IPK/RPM/DEB}
> to
> be symlinks and avoid copyhardlinktree replacing those symlinks with
> a
> normal directory.
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> ---
>  meta/lib/oe/path.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Does the -h option exist for tar < 1.26?

Cheers,

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

Re: [OE-core] [PATCH] db: Add --tag parameter to libtool invocation

[Richard Purdie]

On Tue, 2017-08-15 at 20:33 -0700, Khem Raj wrote:
> Fixes errors like
> libtool: compile: unable to infer tagged configuration
> libtool: compile: specify a tag with `--tag'

The patch seems to do a bit more than this?

Cheers,

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

Re: [OE-core] [PATCH] Perl: No reference conversion for Porting/Glossary

[Richard Purdie]

On Wed, 2017-08-16 at 09:18 +0800, cinly@intel.com wrote:
> From: Ooi Cinly 
> 
> do_configure() will no longer convert references to
> /usr/include into /path/to/recipes-sysroot/usr/include
> for the file "Porting/Glossary".
> 
> [YOCTO #11243]
> 
> Signed-off-by: Ooi Cinly 
> ---
>  meta/recipes-devtools/perl/perl_5.24.1.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I've queued this, I just wanted to note that I had to tweak the
shortlog. Its not clear from reading the version above what the change
is doing. The recipe is perl, not Perl too. I changed it to:

"perl: Don't change /usr/include references in docs to sysroot paths"

Cheers,

Richard

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

Re: [OE-core] [PATCH 6/8] gnupg: 2.1.20 -> 2.1.23

[Richard Purdie]

On Wed, 2017-08-16 at 04:31 -0400, Hongxu Jia wrote:
> COPYING.LIB: Rename to COPYING.LGPL3.
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=3419a
> 339d9c4e800bf30e9021e05982d8c1021c1
> 
> Rebase patches:
> - pkgconfig.patch -> 0001
> - use-pkgconfig-instead-of-npth-config.patch -> 0002
> - dirmngr-uses-libgpg-error.patch -> 0003
> - autogen.sh-fix-find-version-for-beta-checking.patch -> 0004
> 
> Signed-off-by: Hongxu Jia 

Its taken a bit of tracking down but this causes "oe-selftest -r
runtime_test.TestImage.test_testimage_dnf" to fail:

NOTE: Executing RunQueue Tasks
NOTE: Running task 547 of 547 
(/media/build1/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_testimage)
NOTE: recipe core-image-full-cmdline-1.0-r0: task do_testimage: Started
RESULTS:
RESULTS - dnf.DnfBasicTest.test_dnf_help - Testcase 1735: PASSED
RESULTS - ping.PingTest.test_ping - Testcase 964: PASSED
RESULTS - ssh.SSHTest.test_ssh - Testcase 224: PASSED
RESULTS - dnf_runtime.DnfSelftest.test_verify_package_feeds - Testcase -1: 
FAILED
SUMMARY:
core-image-full-cmdline () - Ran 4 tests in 23.612s
core-image-full-cmdline - FAIL - Required tests failed
ERROR: core-image-full-cmdline-1.0-r0 do_testimage: core-image-full-cmdline - 
FAILED - check the task log and the ssh log
ERROR: core-image-full-cmdline-1.0-r0 do_testimage: Function failed: 
do_testimage
ERROR: Logfile of failure stored in: 
/media/build1/poky/build/tmp/work/qemux86-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_testimage.11134
NOTE: recipe core-image-full-cmdline-1.0-r0: task do_testimage: Failed
ERROR: Task 
(/media/build1/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_testimage)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 547 tasks of which 546 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
  
/media/build1/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_testimage
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
--
2017-08-18 09:39:52,189 - oe-selftest - INFO - Ran 1 test in 343.737s
2017-08-18 09:39:52,189 - oe-selftest - INFO - FAILED
2017-08-18 09:39:52,189 - oe-selftest - INFO -  (failures=1)
2017-08-18 09:39:52,193 - oe-selftest - INFO - RESULTS:
2017-08-18 09:39:52,193 - oe-selftest - INFO - RESULTS - 
runtime_test.TestImage.test_testimage_dnf - Testcase 1883: FAILED
2017-08-18 09:39:52,193 - oe-selftest - INFO - SUMMARY:
2017-08-18 09:39:52,193 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 
343.742s
2017-08-18 09:39:52,193 - oe-selftest - INFO - oe-selftest - FAIL - Required 
tests failed

With:

diff --git a/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py 
b/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py
index 6742e8c..f813c43 100644
--- a/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py
+++ b/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py
@@ -37,7 +37,7 @@ class DnfSelftest(DnfTest):
 
 import re
 # Use '-y' for non-interactive mode: automatically import the feed 
signing key
-output_makecache = self.dnf('-y makecache')
+output_makecache = self.dnf('-vy makecache')
 self.assertTrue(re.match(r".*Failed to synchronize cache", 
output_makecache, re.DOTALL) is None, msg = "dnf makecache failed to 
synchronize repo: %s" %(output_makecache))
 self.assertTrue(re.match(r".*Metadata cache created", 
output_makecache, re.DOTALL) is not None, msg = "dnf makecache failed: %s" 
%(output_makecache))

applied the log shows:

NOTE: Traceback (most recent call last):
  File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, 
in wrapped_f
return func(*args, **kwargs)
  File 
"/media/build1/poky/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py", line 
41, in test_verify_package_feeds
self.assertTrue(re.match(r".*Failed to synchronize cache", 
output_makecache, re.DOTALL) is None, msg = "dnf makecache failed to 
synchronize repo: %s" %(output_makecache))
AssertionError: False is not true : dnf makecache failed to synchronize repo: 
Unable to detect release version (use '--releasever' to specify release version)
DNF version: 2.6.3
cachedir: /var/cache/dnf
Making cache files for all metadata files.
oe-remote-repo: has expired and will be refreshed.
Cannot download 'http://192.168.7.1:33541': repomd.xml GPG signature 
verification error: gpgme_engine_check_version() error: Invalid crypto engine.
Failed to synchronize cache for repo 'oe-remote-repo', disabling.
Metadata cache created.

If I revert this upgrade it works again. Seems to be some kind of
gpgme/gnupg version compatibility issue?

Cheers,

Richard


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

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

[Alexander Kanavin]

On 08/17/2017 08:11 PM, Alejandro Hernandez wrote:

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.


Thanks for doing this; does it mean that python 3.6 update is coming 
soon? :)


Alex
--
___
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 Fri, 2017-08-18 at 08:26 +0200, Andrej Valek wrote:
> Yes, for actual branch is not required. But for branches like krogoth
> and morty, where HOSTTOOLS is not implemented, is this necessary.

Lets just apply this to krogoth/morty then...

Cheers,

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

[OE-core] [PATCH] oeqa: increase verbosity of dnf commands in dnf packagefeed test

[Markus Lehtonen]

Makes diagnosing failures easier.

[YOCTO #11209]

Signed-off-by: Markus Lehtonen 
---
 meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py 
b/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py
index 6742e8c080..81c50ed97b 100644
--- a/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py
+++ b/meta-selftest/lib/oeqa/runtime/cases/dnf_runtime.py
@@ -37,11 +37,11 @@ class DnfSelftest(DnfTest):
 
 import re
 # Use '-y' for non-interactive mode: automatically import the feed 
signing key
-output_makecache = self.dnf('-y makecache')
+output_makecache = self.dnf('-vy makecache')
 self.assertTrue(re.match(r".*Failed to synchronize cache", 
output_makecache, re.DOTALL) is None, msg = "dnf makecache failed to 
synchronize repo: %s" %(output_makecache))
 self.assertTrue(re.match(r".*Metadata cache created", 
output_makecache, re.DOTALL) is not None, msg = "dnf makecache failed: %s" 
%(output_makecache))
 
-output_repoinfo = self.dnf('repoinfo')
+output_repoinfo = self.dnf('-v repoinfo')
 matchobj = re.match(r".*Repo-pkgs\s*:\s*(?P[0-9]+)", 
output_repoinfo, re.DOTALL)
 self.assertTrue(matchobj is not None, msg = "Could not find the amount 
of packages in dnf repoinfo output: %s" %(output_repoinfo))
 self.assertTrue(int(matchobj.group('n_pkgs')) > 0, msg = "Amount of 
remote packages is not more than zero: %s\n" %(output_repoinfo))
-- 
2.12.3

-- 
___
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,

Using selftest to measure the signing performance is fruitless. The effect of 
using "chunks" really depends on the number of subpackages the recipe produces. 
Selftest uses one of the smallest recipes , i.e. "ed", so you won't see any 
difference. But with  hundreds of subpackages you get different figures.
   - Markus

On 17/08/2017, 17.52, "Leonardo Sandoval" 
 wrote:

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" 
 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:
> 

[OE-core] [V2 PATCH 1/2] bash: 4.3.30 -> 4.4

[Hongxu Jia]

1. Rebase patches:
- fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
- test-output.patch

2. Drop backported patches:
- CVE-2016-9401.patch
- fix-run-intl.patch

3. Add ${PN}-loadable for loadable builtins which is new features in Bash 4.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

5. The 4.4 installed include header files, fix bash-dev confilicts
   with lib32-bash-dev
.
$ bitbake lib32-core-image-sato-sdk
...
|Error: Transaction check error: file /usr/include/bash/config.h
conflicts between attempted installs
|of lib32-bash-dev-4.4-r0.x86 and bash-dev-4.4-r0.core2_64
..

Signed-off-by: Hongxu Jia 
---
 meta/recipes-extended/bash/bash.inc|   6 +
 .../recipes-extended/bash/bash/CVE-2016-9401.patch |  50 ---
 ...roc-run-heredoc-run-execscript-run-test-f.patch | 158 +++--
 meta/recipes-extended/bash/bash/fix-run-intl.patch | 110 --
 meta/recipes-extended/bash/bash/test-output.patch  |  47 --
 meta/recipes-extended/bash/bash_4.3.30.bb  |  75 --
 meta/recipes-extended/bash/bash_4.4.bb |  58 
 7 files changed, 113 insertions(+), 391 deletions(-)
 delete mode 100644 meta/recipes-extended/bash/bash/CVE-2016-9401.patch
 delete mode 100644 meta/recipes-extended/bash/bash/fix-run-intl.patch
 delete mode 100644 meta/recipes-extended/bash/bash_4.3.30.bb
 create mode 100644 meta/recipes-extended/bash/bash_4.4.bb

diff --git a/meta/recipes-extended/bash/bash.inc 
b/meta/recipes-extended/bash/bash.inc
index 6c94a24..92916d9 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -28,6 +28,8 @@ RDEPENDS_${PN}-ptest += "make"
 USERADD_PACKAGES = "${PN}-ptest"
 USERADD_PARAM_${PN}-ptest = "--create-home --user-group test"
 
+CACHED_CONFIGUREVARS += "headersdir=${includedir}/${PN}"
+
 do_configure_prepend () {
if [ ! -e ${S}/acinclude.m4 ]; then
cat ${S}/aclocal.m4 > ${S}/acinclude.m4
@@ -70,4 +72,8 @@ PACKAGES += "${PN}-bashbug"
 FILES_${PN} = "${bindir}/bash ${base_bindir}/bash.bash"
 FILES_${PN}-bashbug = "${bindir}/bashbug"
 
+PACKAGE_BEFORE_PN += "${PN}-loadable"
+RDEPENDS_${PN}-loadable += "${PN}"
+FILES_${PN}-loadable += "${libdir}/bash/*"
+
 RPROVIDES_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', 
'/bin/sh /bin/bash', '', d)}"
diff --git a/meta/recipes-extended/bash/bash/CVE-2016-9401.patch 
b/meta/recipes-extended/bash/bash/CVE-2016-9401.patch
deleted file mode 100644
index 28c9277..000
--- a/meta/recipes-extended/bash/bash/CVE-2016-9401.patch
+++ /dev/null
@@ -1,50 +0,0 @@
-From fa741771ed47b30547be63b5b5dbfb51977aca12 Mon Sep 17 00:00:00 2001
-From: Chet Ramey 
-Date: Fri, 20 Jan 2017 11:47:31 -0500
-Subject: [PATCH] Bash-4.4 patch 6
-
-Bug-Reference-URL:
-https://lists.gnu.org/archive/html/bug-bash/2016-11/msg00116.html
-
-Reference to upstream patch:
-https://ftp.gnu.org/pub/gnu/bash/bash-4.4-patches/bash44-006
-
-Bug-Description:
-Out-of-range negative offsets to popd can cause the shell to crash attempting
-to free an invalid memory block.
-
-Upstream-Status: Backport
-CVE: CVE-2016-9401
-Signed-off-by: Li Zhou 

- builtins/pushd.def | 7 ++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
-
-diff --git a/builtins/pushd.def b/builtins/pushd.def
-index 9c6548f..8a13bae 100644
 a/builtins/pushd.def
-+++ b/builtins/pushd.def
-@@ -359,7 +359,7 @@ popd_builtin (list)
-   break;
- }
- 
--  if (which > directory_list_offset || (directory_list_offset == 0 && which 
== 0))
-+  if (which > directory_list_offset || (which < -directory_list_offset) || 
(directory_list_offset == 0 && which == 0))
- {
-   pushd_error (directory_list_offset, which_word ? which_word : "");
-   return (EXECUTION_FAILURE);
-@@ -381,6 +381,11 @@ popd_builtin (list)
-remove that directory from the list and shift the remainder
-of the list into place. */
-   i = (direction == '+') ? directory_list_offset - which : which;
-+  if (i < 0 || i > directory_list_offset)
-+  {
-+pushd_error (directory_list_offset, which_word ? which_word : "");
-+return (EXECUTION_FAILURE);
-+  }
-   free (pushd_directory_list[i]);
-   directory_list_offset--;
- 
--- 
-1.9.1
-
diff --git 
a/meta/recipes-extended/bash/bash/fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
 
b/meta/recipes-extended/bash/bash/fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
index 7f099ae..9ac2461 100644
--- 
a/meta/recipes-extended/bash/bash/fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
+++ 
b/meta/recipes-extended/bash/bash/fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
@@ -1,15 +1,7 @@
-From 2c30dff8ea8b17ad5ba9881e35ad1eba9c515f13 Mon Sep 17 00:00:00 2001
+From 

[OE-core] [PATCH 2/2] logrotate: fix systemd service not found while multilib

[Hongxu Jia]

...
|ERROR: lib32-logrotate-3.12.3-r0 do_package: SYSTEMD_SERVICE_lib32-logrotate
value lib32-logrotate.service does not exist
|ERROR: lib32-logrotate-3.12.3-r0 do_package: Function failed:
systemd_populate_packages
...

The systemd sercie file should not be multilib expend.

Signed-off-by: Hongxu Jia 
---
 meta/recipes-extended/logrotate/logrotate_3.12.3.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/logrotate/logrotate_3.12.3.bb 
b/meta/recipes-extended/logrotate/logrotate_3.12.3.bb
index 05705be..05c2ef1 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.12.3.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.12.3.bb
@@ -56,8 +56,8 @@ OS_NAME = "Linux"
 inherit autotools systemd
 
 SYSTEMD_SERVICE_${PN} = "\
-${PN}.service \
-${PN}.timer \
+${BPN}.service \
+${BPN}.timer \
 "
 
 LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
-- 
2.8.1

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

[OE-core] [PATCH 0/2] upgrade bash v2 && fix multilib issues

[Hongxu Jia]

Test steps:

vim local.conf:
...
MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_INSTALL_append = " bash"

VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
KERNEL_FEATURES_append = " cfg/systemd.scc"
...

bitbake lib32-core-image-sato-sdk

//Hongxu

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.openembedded.org/openembedded-core-contrib hongxu/upgrade-20170816
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=hongxu/upgrade-20170816

Hongxu Jia (2):
  bash: 4.3.30 -> 4.4
  logrotate: fix systemd service not found while multilib

 meta/recipes-extended/bash/bash.inc|   6 +
 .../recipes-extended/bash/bash/CVE-2016-9401.patch |  50 ---
 ...roc-run-heredoc-run-execscript-run-test-f.patch | 158 +++--
 meta/recipes-extended/bash/bash/fix-run-intl.patch | 110 --
 meta/recipes-extended/bash/bash/test-output.patch  |  47 --
 meta/recipes-extended/bash/bash_4.3.30.bb  |  75 --
 meta/recipes-extended/bash/bash_4.4.bb |  58 
 .../recipes-extended/logrotate/logrotate_3.12.3.bb |   4 +-
 8 files changed, 115 insertions(+), 393 deletions(-)
 delete mode 100644 meta/recipes-extended/bash/bash/CVE-2016-9401.patch
 delete mode 100644 meta/recipes-extended/bash/bash/fix-run-intl.patch
 delete mode 100644 meta/recipes-extended/bash/bash_4.3.30.bb
 create mode 100644 meta/recipes-extended/bash/bash_4.4.bb

-- 
2.8.1

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

[OE-core] [PATCH 1/1] mpg123: upgrade to 1.25.6

[Dengke Du]

Signed-off-by: Dengke Du 
---
 meta/recipes-multimedia/mpg123/{mpg123_1.25.4.bb => mpg123_1.25.6.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/mpg123/{mpg123_1.25.4.bb => mpg123_1.25.6.bb} 
(94%)

diff --git a/meta/recipes-multimedia/mpg123/mpg123_1.25.4.bb 
b/meta/recipes-multimedia/mpg123/mpg123_1.25.6.bb
similarity index 94%
rename from meta/recipes-multimedia/mpg123/mpg123_1.25.4.bb
rename to meta/recipes-multimedia/mpg123/mpg123_1.25.6.bb
index 96e8f21..cb86199 100644
--- a/meta/recipes-multimedia/mpg123/mpg123_1.25.4.bb
+++ b/meta/recipes-multimedia/mpg123/mpg123_1.25.6.bb
@@ -11,8 +11,8 @@ LICENSE_FLAGS = "commercial"
 LIC_FILES_CHKSUM = "file://COPYING;md5=1e86753638d3cf2512528b99079bc4f3"
 
 SRC_URI = "https://www.mpg123.de/download/${BP}.tar.bz2;
-SRC_URI[md5sum] = "810e9d00fd75c92c4afafa20245317b5"
-SRC_URI[sha256sum] = 
"cdb5620e8aab83f75a27dab3394a44b9cc4017fc77b2954b8425ca416db6b3e7"
+SRC_URI[md5sum] = "43336bef78f67c2e66c4f6c288ca1eb3"
+SRC_URI[sha256sum] = 
"0f0458c9b87799bc2c9bf9455279cc4d305e245db43b51a39ef27afe025c5a8e"
 
 inherit autotools pkgconfig
 
-- 
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] mpg123: upgrade to 1.25.6

[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/mpg123-1.25.6
  https://github.com//tree/dengke/mpg123-1.25.6

Dengke Du (1):
  mpg123: upgrade to 1.25.6

 meta/recipes-multimedia/mpg123/{mpg123_1.25.4.bb => mpg123_1.25.6.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/mpg123/{mpg123_1.25.4.bb => mpg123_1.25.6.bb} 
(94%)

-- 
2.8.1

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

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

[Jussi Kukkonen]

On 17 August 2017 at 21:26, Carlos Alberto Lopez Perez 
wrote:

>  * 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"


This isn't wrong , I'll just add some context.

If/when my gdk-pixbuf patch from three days ago lands gdk-pixbuf will
always rdepend on shared-mime-info (and webkitgtk probably can't be
installed without gdk-pixbuf) so the problem would disappear anyway. This
just a happy accident so this patch still seems valid.

There's also https://bugzilla.yoctoproject.org/show_bug.cgi?id=11792 about
whether glib should bring in shared-mime-info so GIO file sniffing wouldn't
be broken (the database is 3.6MB which is not a big number in a webkit
context but can be for others).

Jussi
-- 
___
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

[Andrej Valek]

Yes, for actual branch is not required. But for branches like krogoth
and morty, where HOSTTOOLS is not implemented, is this necessary.

Andrej

On 08/17/2017 06:31 PM, Richard Purdie wrote:
> 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] two recipes, one replaces files of another

[Dvorkin Dmitry]

Thanks!

The problem is that this two machines are the same, except only one 
configuration file.
Bootloader files are build for two machines with the same image. Linux 
kernel is the same the small  difference is in two separate DTS files only.

Everything else is the same.
I don't like dirty hacks. If somebody knows the good way to set 
preference in non-root configuration files - please, advice me.


On 15.08.2017 17:38, Alexander Kanavin wrote:

On 08/15/2017 05:21 PM, Dvorkin Dmitry wrote:

Thank you, Alexander!

But according to this

https://lists.yoctoproject.org/pipermail/yocto/2013-January/011855.html

PREFERRED_PROVIDER_... can't be used in image recipes, only at 
top-level configuration files.


I can't make it work...



I think you can solve this by defining two machines: brdRevA and 
brdRevB. Then set PREFERRED_PROVIDER in the machine definitions.

And have just one recipe for the image.

You should not make image recipes hardware-specific anyway; any image 
recipe should work on any hardware, and details specific to the 
hardware are abstracted to the machine definition.


Alex


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