Re: [OE-core] [PATCH] lttng-modules: work around GCC 7 changes

2017-04-25 Thread Khem Raj 


On 4/25/17 3:33 PM, Nathan Lynch wrote:
> Avoid using LTTng's BUILD_RUNTIME_BUG_ON macro, as it appears to run
> into a similar problem as Linux experienced with __builtin_constant_p
> and dead code elimination.
> 

Thanks for contributing. this patch looks ok to me.

> Signed-off-by: Nathan Lynch 
> ---
>  .../BUILD_RUNTIME_BUG_ON-vs-gcc7.patch | 43 
> ++
>  meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb   |  3 +-
>  2 files changed, 45 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch
> 
> diff --git 
> a/meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch 
> b/meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch
> new file mode 100644
> index ..76063607a831
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch
> @@ -0,0 +1,43 @@
> +From ab07574ef90fa510f293c37897d577066a88fe0d Mon Sep 17 00:00:00 2001
> +From: Nathan Lynch 
> +Date: Tue, 25 Apr 2017 16:26:57 -0500
> +Subject: [PATCH] BUILD_RUNTIME_BUG_ON vs gcc7
> +
> +Avoid using LTTng's BUILD_RUNTIME_BUG_ON macro, as it appears to run
> +into a similar problem as Linux experienced with ilog2.
> +
> +See:
> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=474c90156c8dcc2fa815e6716cc9394d7930cb9c
> +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
> +
> +Upstream-Status: Pending
> +Signed-off-by: Nathan Lynch 
> +---
> + lib/align.h | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/lib/align.h b/lib/align.h
> +index 5b91ae87410b..5e134cd485fe 100644
> +--- a/lib/align.h
>  b/lib/align.h
> +@@ -48,7 +48,7 @@
> +  */
> + #define offset_align(align_drift, alignment)
>\
> + ({ \
> +-BUILD_RUNTIME_BUG_ON((alignment) == 0  \
> ++BUG_ON((alignment) == 0\
> +|| ((alignment) & ((alignment) - 1)));  \
> + (((alignment) - (align_drift)) & ((alignment) - 1));   \
> + })
> +@@ -63,7 +63,7 @@
> +  */
> + #define offset_align_floor(align_drift, alignment) \
> + ({ \
> +-BUILD_RUNTIME_BUG_ON((alignment) == 0  \
> ++BUG_ON((alignment) == 0\
> +|| ((alignment) & ((alignment) - 1)));  \
> + (((align_drift) - (alignment)) & ((alignment) - 1));   \
> + })
> +-- 
> +2.9.3
> +
> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb 
> b/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb
> index abff79d06f26..b48f9cff9a78 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb
> @@ -11,7 +11,8 @@ inherit module
>  COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
>  
>  SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> -   file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch"
> +   file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch 
> \
> +   file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch"
>  
>  SRC_URI[md5sum] = "5a16bca52233cc2bdff572b1120a88f6"
>  SRC_URI[sha256sum] = 
> "62078fe3254ca65969db4b72e59042cd797dbf2740848f8f82384877ae460d54"
> 



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] [PATCH 0/4] Reproducible binaries

2017-04-25 Thread Trevor Woerner 
On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
 wrote:
> The variable defaults to "0" (do not
> build reproducible binaries) in order to minimize any potential
> regressions. (Once the reproducible binaries code is mature enough,
> it can be set to "1".)

My guess is that people would prefer security over reproducibility.
Maybe we need more consensus for the default value going forward?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] [RFT] gcc7 and glibc-2.26 recipes

2017-04-25 Thread Nathan Lynch 
"Burton, Ross"  writes:

> On 24 April 2017 at 23:00, Nathan Lynch  wrote:
>
>> Does adding this patch to lttng-modules work around it?
>>
>
> Yes, it fixes the build here.  I'll throw it at the autobuilder now, can
> you send a patch with a commit message that isn't "someone told me to try
> this"? :)

Done:
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/136086.html
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] lttng-modules: work around GCC 7 changes

2017-04-25 Thread Nathan Lynch 
Avoid using LTTng's BUILD_RUNTIME_BUG_ON macro, as it appears to run
into a similar problem as Linux experienced with __builtin_constant_p
and dead code elimination.

Signed-off-by: Nathan Lynch 
---
 .../BUILD_RUNTIME_BUG_ON-vs-gcc7.patch | 43 ++
 meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb   |  3 +-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch 
b/meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch
new file mode 100644
index ..76063607a831
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-modules/BUILD_RUNTIME_BUG_ON-vs-gcc7.patch
@@ -0,0 +1,43 @@
+From ab07574ef90fa510f293c37897d577066a88fe0d Mon Sep 17 00:00:00 2001
+From: Nathan Lynch 
+Date: Tue, 25 Apr 2017 16:26:57 -0500
+Subject: [PATCH] BUILD_RUNTIME_BUG_ON vs gcc7
+
+Avoid using LTTng's BUILD_RUNTIME_BUG_ON macro, as it appears to run
+into a similar problem as Linux experienced with ilog2.
+
+See:
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=474c90156c8dcc2fa815e6716cc9394d7930cb9c
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
+
+Upstream-Status: Pending
+Signed-off-by: Nathan Lynch 
+---
+ lib/align.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/align.h b/lib/align.h
+index 5b91ae87410b..5e134cd485fe 100644
+--- a/lib/align.h
 b/lib/align.h
+@@ -48,7 +48,7 @@
+  */
+ #define offset_align(align_drift, alignment) \
+   ({ \
+-  BUILD_RUNTIME_BUG_ON((alignment) == 0  \
++  BUG_ON((alignment) == 0\
+  || ((alignment) & ((alignment) - 1)));  \
+   (((alignment) - (align_drift)) & ((alignment) - 1));   \
+   })
+@@ -63,7 +63,7 @@
+  */
+ #define offset_align_floor(align_drift, alignment)   \
+   ({ \
+-  BUILD_RUNTIME_BUG_ON((alignment) == 0  \
++  BUG_ON((alignment) == 0\
+  || ((alignment) & ((alignment) - 1)));  \
+   (((align_drift) - (alignment)) & ((alignment) - 1));   \
+   })
+-- 
+2.9.3
+
diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb
index abff79d06f26..b48f9cff9a78 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.9.1.bb
@@ -11,7 +11,8 @@ inherit module
 COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
 
 SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
-   file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch"
+   file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
+   file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch"
 
 SRC_URI[md5sum] = "5a16bca52233cc2bdff572b1120a88f6"
 SRC_URI[sha256sum] = 
"62078fe3254ca65969db4b72e59042cd797dbf2740848f8f82384877ae460d54"
-- 
2.9.3

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

Re: [OE-core] [PATCH 1/2] grub: Fix build with gcc7

2017-04-25 Thread Andre McCurdy 
On Mon, Apr 24, 2017 at 6:38 PM, Khem Raj  wrote:
> On Mon, Apr 24, 2017 at 3:34 PM, Burton, Ross  wrote:
>> Clearly there's some build difference between our configurations. Are you
>> building grub-git instead of grub_2.00?  Should we delete grub_2.00 if its
>> that old?  I'd say that it looks good for a new upstream 2.02 release as
>> there is a 2.02-rc2 tagged just six weeks ago, but 2.02-beta1 was tagged
>> three years ago...
>
> yes saw that, fedora is already using 2.02-rc2, we will simplify
> things if we are ready to take the plunge and be ready to release with
> rc2 itself if final
> release takes another 3 years.

The 2.02 release seems to be almost ready:

  
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e54c99aaff5e5f6f5d3b06028506c57e66d8ef77

> --
> ___
> 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] ✗ patchtest: failure for busybox: fix typo in CVE-2016-2147_2.patch Upstream-Status tag

2017-04-25 Thread Andre McCurdy 
On Tue, Apr 25, 2017 at 9:06 AM, Leonardo Sandoval
 wrote:
> On Thu, 2017-04-20 at 01:01 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: busybox: fix typo in CVE-2016-2147_2.patch Upstream-Status tag
>> Revision: 1
>> URL   : https://patchwork.openembedded.org/series/6429/
>> State : failure
>>
>> == Summary ==
>>
>> Thank you for submitting this patch series to OpenEmbedded Core. This is
>> an automated response. Several tests have been executed on the proposed
>> series by patchtest resulting in the following failures:
>>
>> * Patchbusybox: fix typo in CVE-2016-2147_2.patch 
>> Upstream-Status tag
>>  Issue Missing or incorrectly formatted CVE tag in commit 
>> message [test_cve_presence_in_commit_message]
>>   Suggested fixInclude a "CVE--" tag in the commit message
>
> Andre,
>
> there is no need to send a second revision due to the above patchtest
> issue. The system detected the CVE on shortlog thus triggering the check
> on the commit message, but for this case there is no need. Will fix
> this.

Thanks Leo.

>>
>> If you believe any of these test results are incorrect, please reply to the
>> mailing list (openembedded-core@lists.openembedded.org) raising your 
>> concerns.
>> Otherwise we would appreciate you correcting the issues and submitting a new
>> version of the patchset if applicable. Please ensure you add/increment the
>> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
>> [PATCH v3] -> ...).
>>
>> ---
>> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
>> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] Reproducible binaries

2017-04-25 Thread Bystricky, Juro 
The idea is that both builds have reproducible timestamps. So there may be 
different ways to determine the best way to get the stamp. My rationale was 
that if the builds are from two different commits, the difference should be 
reflected in the timestamp.  But I agree that two different commits
may in principle result in the same binary image. But without the last commit 
you would end up with different binaries anyway, as the timestamp is usually 
taken from the time of the build.

From: Martin Jansa [martin.ja...@gmail.com]
Sent: Tuesday, April 25, 2017 11:36 AM
To: Bystricky, Juro
Cc: Patches and discussions about the oe-core layer; jurobystri...@hotmail.com
Subject: Re: [OE-core] [PATCH 0/4] Reproducible binaries

Is using the last commit really that useful?

I would like to be able to compare 2 subsequent builds (ideally performed on 2 
different hosts with some small modification in metadata layers) and the 
binaries not affected by those small metadata modifications should be the same 
- which is not the case if we feed them with the top commit date.

The real world use-case is that we're doing daily official builds (which don't 
use sstate for some bad reasons) and just comparing files-in-image.txt file 
from buildhistory shows that almost all binaries are different every day (just 
their size fluctuating +- 2 bytes from the linker mangling) and when something 
goes wrong, it's hard to find "the significant diff" when it's always all 
different even when the 2nd build only had very small change in image recipe.

On Tue, Apr 25, 2017 at 8:14 PM, Juro Bystricky 
> wrote:
This patch set contains several patches aimed to achieve reproducible binaries.
Building reproducible binaries may remove certain intentional
randomness intended for increased security. Hence, it is reasonable
to expect there will be cases where this is not desirable.
The user can select his/her preferences via the variable
BUILD_REPRODUCIBLE_BINARIES. The variable defaults to "0" (do not
build reproducible binaries) in order to minimize any potential
regressions. (Once the reproducible binaries code is mature enough,
it can be set to "1".)

The patch set is rather simple, targeting the "low hanging fruit".
For debian packages we get a lot of binary identical packages simply by
exporting SOURCE_DATE_EPOCH.
For rootfs we get much fewer differences by modified prelinking and by
ensuring various timestamps are reproducible.


Juro Bystricky (4):
  bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES
  base.bbclass: initial support for binary reproducibility
  image-preling.bbclass: support binary reproducibility
  rootfs-postcommands.bbclass: support binary reproducibility

 meta/classes/base.bbclass| 82 
 meta/classes/image-prelink.bbclass   |  9 +++-
 meta/classes/rootfs-postcommands.bbclass | 18 ++-
 meta/conf/bitbake.conf   |  3 ++
 4 files changed, 109 insertions(+), 3 deletions(-)

--
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 0/4] Reproducible binaries

2017-04-25 Thread Martin Jansa 
Is using the last commit really that useful?

I would like to be able to compare 2 subsequent builds (ideally performed
on 2 different hosts with some small modification in metadata layers) and
the binaries not affected by those small metadata modifications should be
the same - which is not the case if we feed them with the top commit date.

The real world use-case is that we're doing daily official builds (which
don't use sstate for some bad reasons) and just comparing
files-in-image.txt file from buildhistory shows that almost all binaries
are different every day (just their size fluctuating +- 2 bytes from the
linker mangling) and when something goes wrong, it's hard to find "the
significant diff" when it's always all different even when the 2nd build
only had very small change in image recipe.

On Tue, Apr 25, 2017 at 8:14 PM, Juro Bystricky 
wrote:

> This patch set contains several patches aimed to achieve reproducible
> binaries.
> Building reproducible binaries may remove certain intentional
> randomness intended for increased security. Hence, it is reasonable
> to expect there will be cases where this is not desirable.
> The user can select his/her preferences via the variable
> BUILD_REPRODUCIBLE_BINARIES. The variable defaults to "0" (do not
> build reproducible binaries) in order to minimize any potential
> regressions. (Once the reproducible binaries code is mature enough,
> it can be set to "1".)
>
> The patch set is rather simple, targeting the "low hanging fruit".
> For debian packages we get a lot of binary identical packages simply by
> exporting SOURCE_DATE_EPOCH.
> For rootfs we get much fewer differences by modified prelinking and by
> ensuring various timestamps are reproducible.
>
>
> Juro Bystricky (4):
>   bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES
>   base.bbclass: initial support for binary reproducibility
>   image-preling.bbclass: support binary reproducibility
>   rootfs-postcommands.bbclass: support binary reproducibility
>
>  meta/classes/base.bbclass| 82
> 
>  meta/classes/image-prelink.bbclass   |  9 +++-
>  meta/classes/rootfs-postcommands.bbclass | 18 ++-
>  meta/conf/bitbake.conf   |  3 ++
>  4 files changed, 109 insertions(+), 3 deletions(-)
>
> --
> 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

[OE-core] [PATCH 1/4] bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES

2017-04-25 Thread Juro Bystricky 
Building reproducible binaries may remove certain intentional
randomness intended for increased security. Hence, it is reasonable
to expect there will be cases where this is not desirable.
The user can select his/her preferences via the variable
BUILD_REPRODUCIBLE_BINARIES. The variable defaults to "0" (do not
build reproducible binaries) in order to minimize any potential
regressions. (Once the reproducible binaries code is mature enough,
it can be set to "1".)

Signed-off-by: Juro Bystricky 
---
 meta/conf/bitbake.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 227babd..0c1091e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -859,3 +859,6 @@ BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends \
 
 MLPREFIX ??= ""
 MULTILIB_VARIANTS ??= ""
+
+BUILD_REPRODUCIBLE_BINARIES ??= "0"
+BUILD_REPRODUCIBLE_BINARIES[export] = "1"
-- 
2.7.4

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

[OE-core] [PATCH 3/4] image-preling.bbclass: support binary reproducibility

2017-04-25 Thread Juro Bystricky 
Conditionally support binary reproducibility in built images.
If BUILD_REPRODUCIBLE_BINARIES = 1 then:

1. Do not randomize library addresses
2. Set/export PRELINK_TIMESTAMP to a reproducible value.
   The value is derived from the top git commit.

Signed-off-by: Juro Bystricky 
---
 meta/classes/image-prelink.bbclass | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image-prelink.bbclass 
b/meta/classes/image-prelink.bbclass
index 4157df0..78ef65a 100644
--- a/meta/classes/image-prelink.bbclass
+++ b/meta/classes/image-prelink.bbclass
@@ -36,7 +36,14 @@ prelink_image () {
dynamic_loader=$(linuxloader)
 
# prelink!
-   ${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -amR -N -c 
${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
+   if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
+   bbnote " prelink: BUILD_REPRODUCIBLE_BINARIES..."
+   # SOURCE_DATE_EPOCH is 0 (no soure files), so get the timestamp 
from GIT repo...
+   export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `
+   ${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -am -N 
-c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
+   else
+   ${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -amR 
-N -c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
+   fi
 
# Remove the prelink.conf if we had to add it.
if [ "$dummy_prelink_conf" = "true" ]; then
-- 
2.7.4

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

[OE-core] [PATCH 2/4] base.bbclass: initial support for binary reproducibility

2017-04-25 Thread Juro Bystricky 
Conditionally set some environment variables in order to achieve
improved binary reproducibility. Providing BUILD_REPRODUCIBLE_BINARIES is
set to "1", we set the following environment variables:

export PYTHONHASHSEED=0
export PERL_HASH_SEED=0
export TZ="UTC"

We also export and set SOURCE_DATE_EPOCH. The value for this variable
is obtained after source code for a recipe has been unpacked, but before it is
patched. If the code comes from a GIT repo, we get the timestamp from the top
commit. (This usually corresponds to the mktime of "changelog".)
Otherwise we go through all files and get the timestamp from the youngest
one. We create a timestamp for each recipe. The timestamp is stored in the file
'src_date_epoch.txt'. Later on, each task reads this file and sets 
SOURCE_DATE_EPOCH
based on the value found in the file.

[YOCTO#11178]
[YOCTO#11179]

Signed-off-by: Juro Bystricky 
---
 meta/classes/base.bbclass | 82 +++
 1 file changed, 82 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index e29821f..f2b2d97 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -10,6 +10,52 @@ inherit utility-tasks
 inherit metadata_scm
 inherit logging
 
+def get_git_src_date_epoch(d, path):
+import subprocess
+saved_cwd = os.getcwd()
+os.chdir(path)
+src_date_epoch = 
int(subprocess.check_output(['git','log','-1','--pretty=%ct']))
+os.chdir(saved_cwd)
+return src_date_epoch
+
+def create_src_date_epoch_stamp(d):
+if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
+path = d.getVar('S')
+src_date_epoch = 0
+filename_dbg = None
+
+if path.endswith('/git'):
+src_date_epoch = get_git_src_date_epoch(d, path)
+else:
+exclude = set(["temp", "licenses", "patches", 
"recipe-sysroot-native", "recipe-sysroot" ])
+for root, dirs, files in os.walk(path, topdown=True):
+dirs[:] = [d for d in dirs if d not in exclude]
+if root.endswith('/git'):
+src_date_epoch = get_git_src_date_epoch(d, root)
+break
+
+for fname in files:
+filename = os.path.join(root, fname)
+try:
+mtime = int(os.path.getmtime(filename))
+except:
+mtime = 0
+if mtime > src_date_epoch:
+src_date_epoch = mtime
+filename_dbg = filename
+
+# Most likely an empty folder
+if src_date_epoch == 0:
+bb.warn("Unable to determine src_date_epoch! path:%s" % path)
+
+f = open(os.path.join(path,'src_date_epoch.txt'), 'w')
+f.write(str(src_date_epoch))
+f.close()
+
+if filename_dbg != None:
+bb.debug(1," src_date_epoch %d derived from: %s" % 
(src_date_epoch, filename_dbg))
+
+
 OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package 
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license"
 OE_IMPORTS[type] = "list"
 
@@ -173,6 +219,7 @@ python base_do_unpack() {
 try:
 fetcher = bb.fetch2.Fetch(src_uri, d)
 fetcher.unpack(d.getVar('WORKDIR'))
+create_src_date_epoch_stamp(d)
 except bb.fetch2.BBFetchException as e:
 bb.fatal(str(e))
 }
@@ -383,9 +430,43 @@ def set_packagetriplet(d):
 
 settriplet(d, "PKGMLTRIPLETS", archs, tos, tvs)
 
+
+export PYTHONHASHSEED
+export PERL_HASH_SEED
+export SOURCE_DATE_EPOCH
+
+BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH PYTHONHASHSEED PERL_HASH_SEED "
+
 python () {
 import string, re
 
+# Create reproducible_environment
+
+if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
+import subprocess
+d.setVar('PYTHONHASHSEED', '0')
+d.setVar('PERL_HASH_SEED', '0')
+d.setVar('TZ', 'UTC')
+
+path = d.getVar('S')
+epochfile = os.path.join(path,'src_date_epoch.txt')
+if os.path.isfile(epochfile):
+f = open(epochfile, 'r')
+src_date_epoch = f.read()
+f.close()
+bb.debug(1, "src_date_epoch stamp found ---> stamp %s" % 
src_date_epoch)
+d.setVar('SOURCE_DATE_EPOCH', src_date_epoch)
+else:
+bb.debug(1, "src_date_epoch stamp not found.")
+d.setVar('SOURCE_DATE_EPOCH', '0')
+else:
+if 'PYTHONHASHSEED' in os.environ:
+del os.environ['PYTHONHASHSEED']
+if 'PERL_HASH_SEED' in os.environ:
+del os.environ['PERL_HASH_SEED']
+if 'SOURCE_DATE_EPOCH' in os.environ:
+del os.environ['SOURCE_DATE_EPOCH']
+
 # Handle PACKAGECONFIG
 #
 # These take the form:
@@ -678,6 +759,7 @@ python () {
 bb.warn("Recipe %s is marked as only being architecture specific 
but seems to have machine specific packages?! The recipe may as well

[OE-core] [PATCH 4/4] rootfs-postcommands.bbclass: support binary reproducibility

2017-04-25 Thread Juro Bystricky 
Conditionally support binary reproducibility of rootfs images.
If BUILD_REPRODUCIBLE_BINARIES = 1 then:

1. set /etc/timestamp to a reproducible value
2. set /etc/version to a reproducible value

The value for /etc/version is modified in a designated catch-all
post-rootfs function "rootfs_reproducible". This function is expected
to provide additional functionality to improve the determinism based
on future needs

[YOCTO#11176]

Signed-off-by: Juro Bystricky 
---
 meta/classes/rootfs-postcommands.bbclass | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 498174a..be1e8dd 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -28,6 +28,8 @@ ROOTFS_POSTPROCESS_COMMAND += 
'${@bb.utils.contains("DISTRO_FEATURES", "systemd"
 
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
+ROOTFS_POSTPROCESS_COMMAND += 'rootfs_reproducible;'
+
 # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
 # distros to choose not to take this change
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
@@ -246,7 +248,12 @@ python write_image_manifest () {
 # Can be use to create /etc/timestamp during image construction to give a 
reasonably
 # sane default time setting
 rootfs_update_timestamp () {
-   date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
+   if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
+   bbnote " rootfs_update_timestamp: 
BUILD_REPRODUCIBLE_BINARIES..."
+   git log -1 --pretty=%cd --date=format:%4Y%2m%2d%2H%2M%2S 
>${IMAGE_ROOTFS}/etc/timestamp
+   else
+   date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
+   fi
 }
 
 # Prevent X from being started
@@ -286,7 +293,6 @@ rootfs_sysroot_relativelinks () {
sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
 }
 
-
 # Generated test data json file
 python write_image_test_data() {
 from oe.data import export2json
@@ -302,3 +308,11 @@ python write_image_test_data() {
os.remove(testdata_link)
 os.symlink(os.path.basename(testdata), testdata_link)
 }
+
+# Perform any additional adjustments needed to make rootf binary reproducible
+rootfs_reproducible () {
+   if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
+   bbnote " rootfs_reproducible: set /etc/version..."
+   git log -1 --pretty=%cd --date=format:%4Y%2m%2d%2H%2M%2S 
>${IMAGE_ROOTFS}/etc/version
+   fi
+}
-- 
2.7.4

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

[OE-core] [PATCH 0/4] Reproducible binaries

2017-04-25 Thread Juro Bystricky 
This patch set contains several patches aimed to achieve reproducible binaries.
Building reproducible binaries may remove certain intentional
randomness intended for increased security. Hence, it is reasonable
to expect there will be cases where this is not desirable.
The user can select his/her preferences via the variable
BUILD_REPRODUCIBLE_BINARIES. The variable defaults to "0" (do not
build reproducible binaries) in order to minimize any potential
regressions. (Once the reproducible binaries code is mature enough,
it can be set to "1".)

The patch set is rather simple, targeting the "low hanging fruit".
For debian packages we get a lot of binary identical packages simply by
exporting SOURCE_DATE_EPOCH.
For rootfs we get much fewer differences by modified prelinking and by
ensuring various timestamps are reproducible.


Juro Bystricky (4):
  bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES
  base.bbclass: initial support for binary reproducibility
  image-preling.bbclass: support binary reproducibility
  rootfs-postcommands.bbclass: support binary reproducibility

 meta/classes/base.bbclass| 82 
 meta/classes/image-prelink.bbclass   |  9 +++-
 meta/classes/rootfs-postcommands.bbclass | 18 ++-
 meta/conf/bitbake.conf   |  3 ++
 4 files changed, 109 insertions(+), 3 deletions(-)

-- 
2.7.4

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

Re: [OE-core] ✗ patchtest: failure for bash: CVE-2016-0634

2017-04-25 Thread Leonardo Sandoval 
On Thu, 2017-04-20 at 07:01 +, Patchwork wrote:
> == Series Details ==
> 
> Series: bash: CVE-2016-0634
> Revision: 1
> URL   : https://patchwork.openembedded.org/series/6434/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Patchbash: CVE-2016-0634
>  Issue Missing or incorrectly formatted CVE tag in included patch 
> file [test_cve_tag_format] 
>   Suggested fixCorrect or include the CVE tag on cve patch with format: 
> "CVE: CVE--"
> 
This is another false-positive issue raised by patchtest. No need to
send a second revision. This has been fixed at the patchtest-oe repo
(a3c87df58f76eafcb80b07260f1bcea966eca5ea)

Leo

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


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

Re: [OE-core] [PATCHv4 4/7] bluez5: add PACKAGECONFIG option for systemd

2017-04-25 Thread Marc Ferland 
On Tue, Apr 25, 2017 at 11:13 AM, Martin Jansa 
wrote:
>
> On Tue, Apr 25, 2017 at 10:48:37AM -0400, Marc Ferland wrote:
> > Signed-off-by: Marc Ferland 
> > ---
> >  meta/recipes-connectivity/bluez5/bluez5.inc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
> > index 687656e..71a5016 100644
> > --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> > +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> > @@ -12,11 +12,12 @@ RPROVIDES_${PN} += "bluez-hcidump"
> >
> >  RCONFLICTS_${PN} = "bluez4"
> >
> > -PACKAGECONFIG ??= "obex-profiles readline"
> > +PACKAGECONFIG ??= "obex-profiles readline
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
> >  PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
> >  PACKAGECONFIG[readline] = "--enable-client,--disable-client,readline,"
> >  PACKAGECONFIG[testing] = "--enable-testing,--disable-testing"
> >  PACKAGECONFIG[midi] = "--enable-midi,--disable-midi,alsa-lib"
> > +PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd"
> >
> >  SRC_URI = "\
> >  ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> > @@ -36,7 +37,6 @@ EXTRA_OECONF = "\
> >--disable-cups \
> >--enable-test \
> >--enable-datafiles \
> > -  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'--enable-systemd', '--disable-systemd', d)} \
>
> Why not use just the options from PACKAGECONFIG?
>
> >--enable-library \
> >  "

enable-library builds and installs the libbluetooth library along with
the header files. I guess it's something pretty much everyone
wants/expects, a sane default, probably also why it was "hard-coded"
in EXTRA_OECONF.

There are many other build options in bluez5 which aren't exposed as
PACKAGECONFIG options. The majority of them being for more finer
grained stuff (the current options are mostly for obvious external
dependencies).

I'll take a look at it and come up with a separate patch if that's okay.

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

[OE-core] [PATCH] Partially revert "volatile-binds: correct some errors reported by systemd"

2017-04-25 Thread Andrea Galbusera 
Suppressing default version of etc.conf for systemd-tmpfiles-setup prevents at
least the name resolver from working as expected when using systemd-resolved.
The missing /etc/resolv.conf symlink breaks application relying on this for
name resolution (tested with ping from busybox).

This patch brings default etc.conf from systemd recipe back, solving the
broken name resolution issue.

[YOCTO #11331]

Signed-off-by: Andrea Galbusera 
---
 meta/recipes-core/volatile-binds/volatile-binds.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
b/meta/recipes-core/volatile-binds/volatile-binds.bb
index a6e3254..943e6ba 100644
--- a/meta/recipes-core/volatile-binds/volatile-binds.bb
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -74,7 +74,6 @@ do_install () {
 # Suppress attempts to process some tmpfiles that are not temporary.
 #
 install -d ${D}${sysconfdir}/tmpfiles.d ${D}/var/cache
-ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/etc.conf
 ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/home.conf
 }
 do_install[dirs] = "${WORKDIR}"
-- 
2.7.4

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

[OE-core] ✗ patchtest: failure for libcap: clean up gperf enabling logic

2017-04-25 Thread Patchwork 
== Series Details ==

Series: libcap: clean up gperf enabling logic
Revision: 1
URL   : https://patchwork.openembedded.org/series/6502/
State : failure

== Summary ==


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



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



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

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

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

[OE-core] [PATCH] libcap: clean up gperf enabling logic

2017-04-25 Thread Ross Burton 
There's no need to sed the Makefile (especially the wrong Makefile) when there's
a variable we can pass.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/libcap/libcap_2.25.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb 
b/meta/recipes-support/libcap/libcap_2.25.bb
index 0587e77..5c2765f 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -22,9 +22,6 @@ do_configure() {
# on what should be replaced with ?=
sed -e 's,:=,?=,g' -i Make.Rules
sed -e 's,^BUILD_CFLAGS ?= $(.*CFLAGS),BUILD_CFLAGS := 
$(BUILD_CFLAGS),' -i Make.Rules
-
-   # disable gperf detection
-   sed -e '/shell gperf/cifeq (,yes)' -i libcap/Makefile
 }
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}"
@@ -37,6 +34,7 @@ EXTRA_OEMAKE = " \
   lib=${@os.path.basename('${libdir}')} \
   RAISE_SETFCAP=no \
   DYNAMIC=yes \
+  BUILD_GPERF=yes \
 "
 
 EXTRA_OEMAKE_append_class-target = " SYSTEM_HEADERS=${STAGING_INCDIR}"
-- 
2.8.1

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

Re: [OE-core] ✗ patchtest: failure for busybox: fix typo in CVE-2016-2147_2.patch Upstream-Status tag

2017-04-25 Thread Leonardo Sandoval 
On Thu, 2017-04-20 at 01:01 +, Patchwork wrote:
> == Series Details ==
> 
> Series: busybox: fix typo in CVE-2016-2147_2.patch Upstream-Status tag
> Revision: 1
> URL   : https://patchwork.openembedded.org/series/6429/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Patchbusybox: fix typo in CVE-2016-2147_2.patch Upstream-Status 
> tag
>  Issue Missing or incorrectly formatted CVE tag in commit message 
> [test_cve_presence_in_commit_message] 
>   Suggested fixInclude a "CVE--" tag in the commit message

Andre,

there is no need to send a second revision due to the above patchtest
issue. The system detected the CVE on shortlog thus triggering the check
on the commit message, but for this case there is no need. Will fix
this.

Leo

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


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

Re: [OE-core] [PATCHv4 4/7] bluez5: add PACKAGECONFIG option for systemd

2017-04-25 Thread Martin Jansa 
On Tue, Apr 25, 2017 at 10:48:37AM -0400, Marc Ferland wrote:
> Signed-off-by: Marc Ferland 
> ---
>  meta/recipes-connectivity/bluez5/bluez5.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index 687656e..71a5016 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -12,11 +12,12 @@ RPROVIDES_${PN} += "bluez-hcidump"
>  
>  RCONFLICTS_${PN} = "bluez4"
>  
> -PACKAGECONFIG ??= "obex-profiles readline"
> +PACKAGECONFIG ??= "obex-profiles readline 
> ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
>  PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
>  PACKAGECONFIG[readline] = "--enable-client,--disable-client,readline,"
>  PACKAGECONFIG[testing] = "--enable-testing,--disable-testing"
>  PACKAGECONFIG[midi] = "--enable-midi,--disable-midi,alsa-lib"
> +PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd"
>  
>  SRC_URI = "\
>  ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> @@ -36,7 +37,6 @@ EXTRA_OECONF = "\
>--disable-cups \
>--enable-test \
>--enable-datafiles \
> -  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--enable-systemd', 
> '--disable-systemd', d)} \

Why not use just the options from PACKAGECONFIG?

>--enable-library \
>  "
>  
> -- 
> 2.7.4
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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


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

[OE-core] [PATCHv4 7/7] bluez5: cleanup tabs and spaces

2017-04-25 Thread Marc Ferland 
Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 30 ++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 47d8f22..01ade7d 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -57,24 +57,24 @@ do_install_append() {
 
install -d ${D}${sysconfdir}/bluetooth/
if [ -f ${S}/profiles/network/network.conf ]; then
-   install -m 0644 ${S}/profiles/network/network.conf 
${D}/${sysconfdir}/bluetooth/
+   install -m 0644 ${S}/profiles/network/network.conf 
${D}/${sysconfdir}/bluetooth/
fi
if [ -f ${S}/profiles/input/input.conf ]; then
-   install -m 0644 ${S}/profiles/input/input.conf 
${D}/${sysconfdir}/bluetooth/
+   install -m 0644 ${S}/profiles/input/input.conf 
${D}/${sysconfdir}/bluetooth/
fi
 
-  if [ -f ${D}/${sysconfdir}/init.d/bluetooth ]; then
-sed -i -e 's#@LIBEXECDIR@#${libexecdir}#g' 
${D}/${sysconfdir}/init.d/bluetooth
-  fi
+   if [ -f ${D}/${sysconfdir}/init.d/bluetooth ]; then
+   sed -i -e 's#@LIBEXECDIR@#${libexecdir}#g' 
${D}/${sysconfdir}/init.d/bluetooth
+   fi
 
# Install desired tools that upstream leaves in build area
-for f in ${NOINST_TOOLS} ; do
-   install -m 755 ${B}/$f ${D}/${bindir}
+   for f in ${NOINST_TOOLS} ; do
+   install -m 755 ${B}/$f ${D}/${bindir}
done
 
-# Patch python tools to use Python 3; they should be source 
compatible, but
-# still refer to Python 2 in the shebang
-sed -i -e '1s,#!.*python.*,#!${bindir}/python3,' 
${D}${libdir}/bluez/test/*
+   # Patch python tools to use Python 3; they should be source compatible, 
but
+   # still refer to Python 2 in the shebang
+   sed -i -e '1s,#!.*python.*,#!${bindir}/python3,' 
${D}${libdir}/bluez/test/*
 }
 
 PACKAGES =+ "${PN}-testtools ${PN}-obex ${PN}-noinst-tools"
@@ -84,8 +84,8 @@ FILES_${PN} += " \
 ${systemd_unitdir}/ ${datadir}/dbus-1 \
 ${libdir}/cups \
 "
-FILES_${PN}-dev += "\
-  ${libdir}/bluetooth/plugins/*.la \
+FILES_${PN}-dev += " \
+${libdir}/bluetooth/plugins/*.la \
 "
 
 FILES_${PN}-obex = "${libexecdir}/bluetooth/obexd \
@@ -115,10 +115,10 @@ INITSCRIPT_NAME_${PN} = "bluetooth"
 EXCLUDE_FROM_WORLD = "1"
 
 do_compile_ptest() {
-oe_runmake buildtests
+   oe_runmake buildtests
 }
 
 do_install_ptest() {
-cp -r ${B}/unit/ ${D}${PTEST_PATH}
-rm -f ${D}${PTEST_PATH}/unit/*.o
+   cp -r ${B}/unit/ ${D}${PTEST_PATH}
+   rm -f ${D}${PTEST_PATH}/unit/*.o
 }
-- 
2.7.4

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

[OE-core] [PATCHv4 5/7] bluez5: add PACKAGECONFIG option for cups

2017-04-25 Thread Marc Ferland 
Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 71a5016..c8a240f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -18,6 +18,7 @@ PACKAGECONFIG[readline] = 
"--enable-client,--disable-client,readline,"
 PACKAGECONFIG[testing] = "--enable-testing,--disable-testing"
 PACKAGECONFIG[midi] = "--enable-midi,--disable-midi,alsa-lib"
 PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd"
+PACKAGECONFIG[cups] = "--enable-cups,--disable-cups,,cups"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
@@ -34,7 +35,6 @@ inherit autotools pkgconfig systemd update-rc.d 
distro_features_check ptest
 EXTRA_OECONF = "\
   --enable-tools \
   --enable-deprecated \
-  --disable-cups \
   --enable-test \
   --enable-datafiles \
   --enable-library \
@@ -82,7 +82,11 @@ do_install_append() {
 
 PACKAGES =+ "${PN}-testtools ${PN}-obex ${PN}-noinst-tools"
 
-FILES_${PN} += "${libdir}/bluetooth/plugins/*.so ${systemd_unitdir}/ 
${datadir}/dbus-1"
+FILES_${PN} += " \
+${libdir}/bluetooth/plugins/*.so \
+${systemd_unitdir}/ ${datadir}/dbus-1 \
+${libdir}/cups \
+"
 FILES_${PN}-dev += "\
   ${libdir}/bluetooth/plugins/*.la \
 "
-- 
2.7.4

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

[OE-core] [PATCHv4 6/7] bluez5: do not install audio.conf

2017-04-25 Thread Marc Ferland 
The audio.conf file has been removed, stop installing it.

Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index c8a240f..47d8f22 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -56,9 +56,6 @@ do_install_append() {
install -m 0755 ${WORKDIR}/init ${D}${INIT_D_DIR}/bluetooth
 
install -d ${D}${sysconfdir}/bluetooth/
-   if [ -f ${S}/profiles/audio/audio.conf ]; then
-   install -m 0644 ${S}/profiles/audio/audio.conf 
${D}/${sysconfdir}/bluetooth/
-   fi
if [ -f ${S}/profiles/network/network.conf ]; then
install -m 0644 ${S}/profiles/network/network.conf 
${D}/${sysconfdir}/bluetooth/
fi
-- 
2.7.4

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

[OE-core] [PATCHv4 0/7] bluez: upgrade and refactoring

2017-04-25 Thread Marc Ferland 
V4:
* dropped the "rename readline 'config' option to 'client'" changes (reported 
by Ross Burton)
* make references to libasound-module-bluez depend on bluez4 only (reported by 
Ross burton)

V3:
* shell functions use tabs not spaces (reported by Khem Raj)

V2:
* upgrades to version 5.44
* renames variables and configure options to better reflect bluez options
* adds midi, cups and systemd as PACKAGECONFIG options
* removes references from files that are no longer part of bluez
* cleanups tabs/spaces usage

V1:
* https://patchwork.openembedded.org/patch/138995/

Regards,

Marc Ferland (7):
  bluez5: Upgrade 5.43 -> 5.44
  bluez5: remove libasound-module references
  bluez5: add PACKAGECONFIG option for midi
  bluez5: add PACKAGECONFIG option for systemd
  bluez5: add PACKAGECONFIG option for cups
  bluez5: do not install audio.conf
  bluez5: cleanup tabs and spaces

 meta/conf/distro/include/default-providers.inc |  1 -
 meta/recipes-connectivity/bluez5/bluez5.inc| 60 ++-
 meta/recipes-connectivity/bluez5/bluez5_5.43.bb| 55 -
 meta/recipes-connectivity/bluez5/bluez5_5.44.bb| 68 ++
 .../packagegroups/packagegroup-base.bb |  2 +-
 5 files changed, 100 insertions(+), 86 deletions(-)
 delete mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.43.bb
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.44.bb

-- 
2.7.4

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

[OE-core] [PATCHv4 3/7] bluez5: add PACKAGECONFIG option for midi

2017-04-25 Thread Marc Ferland 
Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 4244fc8..687656e 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -16,6 +16,7 @@ PACKAGECONFIG ??= "obex-profiles readline"
 PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
 PACKAGECONFIG[readline] = "--enable-client,--disable-client,readline,"
 PACKAGECONFIG[testing] = "--enable-testing,--disable-testing"
+PACKAGECONFIG[midi] = "--enable-midi,--disable-midi,alsa-lib"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
-- 
2.7.4

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

[OE-core] [PATCHv4 4/7] bluez5: add PACKAGECONFIG option for systemd

2017-04-25 Thread Marc Ferland 
Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 687656e..71a5016 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -12,11 +12,12 @@ RPROVIDES_${PN} += "bluez-hcidump"
 
 RCONFLICTS_${PN} = "bluez4"
 
-PACKAGECONFIG ??= "obex-profiles readline"
+PACKAGECONFIG ??= "obex-profiles readline 
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
 PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
 PACKAGECONFIG[readline] = "--enable-client,--disable-client,readline,"
 PACKAGECONFIG[testing] = "--enable-testing,--disable-testing"
 PACKAGECONFIG[midi] = "--enable-midi,--disable-midi,alsa-lib"
+PACKAGECONFIG[systemd] = "--enable-systemd,--disable-systemd"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
@@ -36,7 +37,6 @@ EXTRA_OECONF = "\
   --disable-cups \
   --enable-test \
   --enable-datafiles \
-  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--enable-systemd', 
'--disable-systemd', d)} \
   --enable-library \
 "
 
-- 
2.7.4

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

[OE-core] [PATCHv4 2/7] bluez5: remove libasound-module references

2017-04-25 Thread Marc Ferland 
Cleanup references to libasound-module since this code has been
completly removed from Bluez.

Signed-off-by: Marc Ferland 
---
 meta/conf/distro/include/default-providers.inc   | 1 -
 meta/recipes-connectivity/bluez5/bluez5.inc  | 5 +
 meta/recipes-core/packagegroups/packagegroup-base.bb | 2 +-
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/conf/distro/include/default-providers.inc 
b/meta/conf/distro/include/default-providers.inc
index ece4d8b..e1cb2f9 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -46,7 +46,6 @@ PREFERRED_PROVIDER_nativesdk-opkg ?= "nativesdk-opkg"
 PREFERRED_PROVIDER_console-tools ?= "kbd"
 PREFERRED_PROVIDER_gzip-native ?= "pigz-native"
 PREFERRED_PROVIDER_udev ?= 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd','eudev',d)}"
-PREFERRED_RPROVIDER_libasound-module-bluez ?= 
"${@bb.utils.contains('DISTRO_FEATURES','bluetooth 
bluez5','bluez5','bluez4',d)}"
 PREFERRED_RPROVIDER_bluez-hcidump ?= 
"${@bb.utils.contains('DISTRO_FEATURES','bluetooth 
bluez5','bluez5','bluez-hcidump',d)}"
 # Alternative is ltp-ddt in meta-oe: 
meta-oe/recipes-devtools/ltp-ddt/ltp-ddt_0.0.4.bb
 PREFERRED_PROVIDER_ltp ?= "ltp"
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 11cf8fb..4244fc8 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -79,14 +79,11 @@ do_install_append() {
 sed -i -e '1s,#!.*python.*,#!${bindir}/python3,' 
${D}${libdir}/bluez/test/*
 }
 
-ALLOW_EMPTY_libasound-module-bluez = "1"
-PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex 
${PN}-noinst-tools"
+PACKAGES =+ "${PN}-testtools ${PN}-obex ${PN}-noinst-tools"
 
-FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so ${datadir}/alsa"
 FILES_${PN} += "${libdir}/bluetooth/plugins/*.so ${systemd_unitdir}/ 
${datadir}/dbus-1"
 FILES_${PN}-dev += "\
   ${libdir}/bluetooth/plugins/*.la \
-  ${libdir}/alsa-lib/*.la \
 "
 
 FILES_${PN}-obex = "${libexecdir}/bluetooth/obexd \
diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb 
b/meta/recipes-core/packagegroups/packagegroup-base.bb
index 0069e3e..f9e6e2e 100644
--- a/meta/recipes-core/packagegroups/packagegroup-base.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
@@ -204,7 +204,7 @@ RRECOMMENDS_packagegroup-base-pcmcia = "\
 SUMMARY_packagegroup-base-bluetooth = "Bluetooth support"
 RDEPENDS_packagegroup-base-bluetooth = "\
 ${BLUEZ} \
-${@bb.utils.contains('COMBINED_FEATURES', 'alsa', 
'libasound-module-bluez', '',d)} \
+${@bb.utils.contains('COMBINED_FEATURES', 'alsa', 
bb.utils.contains('BLUEZ', 'bluez4', 'libasound-module-bluez', '', d), '',d)} \
 "
 
 RRECOMMENDS_packagegroup-base-bluetooth = "\
-- 
2.7.4

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

[OE-core] [PATCHv4 1/7] bluez5: Upgrade 5.43 -> 5.44

2017-04-25 Thread Marc Ferland 
New feautures/fixes in this version:

* fixes to BLE
* a new midi plugin
* support for single-mode controllers w/o public address
* most of the experimental tools have been promoted and are now part of
  the official tools
* 'experimental' has been renamed to 'testing' (hence the addition of
  the 'testing' package config option)
* classic command line tools like hciattach and hciconfig are now enabled
  by the "--enable-deprecated" configure option (enabled by default for
  backward compatibility).

Signed-off-by: Marc Ferland 
---
 meta/recipes-connectivity/bluez5/bluez5.inc |  9 ++--
 meta/recipes-connectivity/bluez5/bluez5_5.43.bb | 55 
 meta/recipes-connectivity/bluez5/bluez5_5.44.bb | 68 +
 3 files changed, 74 insertions(+), 58 deletions(-)
 delete mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.43.bb
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.44.bb

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index ed75db2..11cf8fb 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -14,8 +14,8 @@ RCONFLICTS_${PN} = "bluez4"
 
 PACKAGECONFIG ??= "obex-profiles readline"
 PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
-PACKAGECONFIG[experimental] = "--enable-experimental,--disable-experimental,"
 PACKAGECONFIG[readline] = "--enable-client,--disable-client,readline,"
+PACKAGECONFIG[testing] = "--enable-testing,--disable-testing"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
@@ -31,6 +31,7 @@ inherit autotools pkgconfig systemd update-rc.d 
distro_features_check ptest
 
 EXTRA_OECONF = "\
   --enable-tools \
+  --enable-deprecated \
   --disable-cups \
   --enable-test \
   --enable-datafiles \
@@ -41,10 +42,12 @@ EXTRA_OECONF = "\
 # bluez5 builds a large number of useful utilities but does not
 # install them.  Specify which ones we want put into ${PN}-noinst-tools.
 NOINST_TOOLS_READLINE ??= ""
-NOINST_TOOLS_EXPERIMENTAL ??= ""
+NOINST_TOOLS_TESTING ??= ""
+NOINST_TOOLS_BT ??= ""
 NOINST_TOOLS = " \
 ${@bb.utils.contains('PACKAGECONFIG', 'readline', 
'${NOINST_TOOLS_READLINE}', '', d)} \
-${@bb.utils.contains('PACKAGECONFIG', 'experimental', 
'${NOINST_TOOLS_EXPERIMENTAL}', '', d)} \
+${@bb.utils.contains('PACKAGECONFIG', 'testing', 
'${NOINST_TOOLS_TESTING}', '', d)} \
+${NOINST_TOOLS_BT} \
 "
 
 do_install_append() {
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.43.bb 
b/meta/recipes-connectivity/bluez5/bluez5_5.43.bb
deleted file mode 100644
index e10b82d..000
--- a/meta/recipes-connectivity/bluez5/bluez5_5.43.bb
+++ /dev/null
@@ -1,55 +0,0 @@
-require bluez5.inc
-
-REQUIRED_DISTRO_FEATURES = "bluez5"
-
-SRC_URI[md5sum] = "698def88df96840dfbb0858bb6d73350"
-SRC_URI[sha256sum] = 
"16c9c05d2a1da644ce3570d975ada3643d2e60c007a955bac09c0a0efeb58d15"
-
-# noinst programs in Makefile.tools that are conditional on READLINE
-# support
-NOINST_TOOLS_READLINE ?= " \
-attrib/gatttool \
-tools/obex-client-tool \
-tools/obex-server-tool \
-tools/bluetooth-player \
-tools/obexctl \
-tools/btmgmt \
-"
-
-# noinst programs in Makefile.tools that are conditional on EXPERIMENTAL
-# support
-NOINST_TOOLS_EXPERIMENTAL ?= " \
-emulator/btvirt \
-emulator/b1ee \
-emulator/hfp \
-tools/3dsp \
-tools/mgmt-tester \
-tools/gap-tester \
-tools/l2cap-tester \
-tools/sco-tester \
-tools/smp-tester \
-tools/hci-tester \
-tools/rfcomm-tester \
-tools/bdaddr \
-tools/avinfo \
-tools/avtest \
-tools/scotest \
-tools/amptest \
-tools/hwdb \
-tools/hcieventmask \
-tools/hcisecfilter \
-tools/btinfo \
-tools/btattach \
-tools/btsnoop \
-tools/btproxy \
-tools/btiotest \
-tools/mcaptest \
-tools/cltest \
-tools/oobtest \
-tools/seq2bseq \
-tools/ibeacon \
-tools/btgatt-client \
-tools/btgatt-server \
-tools/gatt-service \
-profiles/iap/iapd \
-"
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.44.bb 
b/meta/recipes-connectivity/bluez5/bluez5_5.44.bb
new file mode 100644
index 000..1095f88
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.44.bb
@@ -0,0 +1,68 @@
+require bluez5.inc
+
+REQUIRED_DISTRO_FEATURES = "bluez5"
+
+SRC_URI[md5sum] = "94273617129ced06612fcb9f5273d14c"
+SRC_URI[sha256sum] = 
"0c321e291f8b45e6a78e379dfe80592b65955a0f0ab191f1cca0edd8ec356c85"
+
+# noinst programs in Makefile.tools that are conditional on READLINE
+# support
+NOINST_TOOLS_READLINE ?= " \
+attrib/gatttool \
+tools/obex-client-tool \
+tools/obex-server-tool \
+tools/bluetooth-player \
+tools/obexctl \
+tools/btmgmt \
+"
+
+# noinst programs in Makefile.tools that are conditional on TESTING
+# support
+NOINST_TOOLS_TESTING ?= " \
+emulator/btvirt \
+emulator/b1ee \
+

Re: [OE-core] [PATCH] gperf: 3.0.4 -> 3.1

2017-04-25 Thread Burton, Ross 
On 24 April 2017 at 03:12, Huang Qiyu  wrote:

> Upgrade gperf from 3.0.4 to 3.1.
>

This breaks the libcap build:

| In file included from :0:0:
| ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
|  gperf_case_strncmp (register const char *s1, register const char *s2,
register size_t n)
|
  ^~
| ./_caps_output.gperf:96:53: error: unknown type name 'size_t'
|  __cap_hash_name (register const char *str, register size_t len)
|  ^~
| ./_caps_output.gperf:200:55: error: unknown type name 'size_t'
|  __cap_lookup_name (register const char *str, register size_t len)
|^~
| ./_caps_output.gperf:200:1: error: conflicting types for
'__cap_lookup_name'
|  __cap_lookup_name (register const char *str, register size_t len)
|  ^
| ./_caps_output.gperf:33:29: note: previous declaration of
'__cap_lookup_name' was here
|  const struct __cap_token_s *__cap_lookup_name(const char *, unsigned
int);
|  ^

gperf 3.1 changed a type from int to size_t, so there's a missing header
include.  Can you also fix libcap?

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

Re: [OE-core] linux-yocto.do_validate_branches failing since last oe-core update

2017-04-25 Thread Bruce Ashfield 
On Tue, Apr 25, 2017 at 9:09 AM, Richard Purdie  wrote:

> On Mon, 2017-04-24 at 21:06 -0400, Bruce Ashfield wrote:
> > On Mon, Apr 24, 2017 at 5:27 PM, Richard Purdie
> >  wrote:
> > > On Mon, 2017-04-24 at 15:56 -0400, Bruce Ashfield wrote:
> > > >
> > > >
> > > > On Mon, Apr 24, 2017 at 9:54 AM, Bruce Ashfield  > > mail
> > > > .com> wrote:
> > > > >
> > > > >
> > > > > On Mon, Apr 24, 2017 at 9:39 AM, Martin Jansa  > > il.c
> > > > > om> wrote:
> > >
> > > >
> > > > Richard/Ross: are you seeing this same thing on the autobuilder ?
> > > >
> > > > There's some incantation or config that I'm missing, I assume
> > > this is
> > > > a straight qemux86 config
> > > > with a bitbake of something like core-image-minimal ?
> > >
> > > We're not seeing this on the autobuilders. I do suspect something
> > > in
> > > the handling of extra patches or cfg fragments from SRC_URI if I
> > > had to
> > > guess. That certainly was the trigger last time I saw this.
> > Yah, that's the kicker, I'm still carrying your patch for binfmt_elf,
> > and I added two of my own
> > + config fragments, and I can't trigger anything.
>
> I managed to reproduce breakage. With master and my separate patch in
> SRC_URI:
>
>
This particular issue should be fixed with with patch I sent, late Friday
night:

[OE-core] [PATCH] kernel-yocto/kern-tools: fix do_validate_branches clean
stage

Martin applied it to his builds and is still seeing an issue in the actual
patching phase.
I'm currently not able to reproduce it.

If you do have that patch applied, I'm definitely interested. If you don't,
and have two
minutes to re-run with that applied .. I'd be interested to hear if the
build works after
that.

Cheers,

Bruce

$ bitbake linux-yocto
> $ bitbake linux-yocto -c kernel_checkout -f
> $ bitbake linux-yocto
>
> ERROR: linux-yocto-4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0
> do_validate_branches: Function failed: do_validate_branches (log file is
> located at /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/linu
> x-yocto/4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0/temp/log.
> do_validate_branches.116726)
> ERROR: Logfile of failure stored in: /media/build1/poky/build/tmp/w
> ork/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e
> 885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726
> Log data follows:
> | DEBUG: Executing shell function do_validate_branches
> | HEAD is now at fe0fb8d Merge tag 'v4.10.9' into standard/base
> | 1493125671.284715: mkdir: cannot create directory ‘.’: File exists
> | 1493125671.370592:
> | 1493125671.3742917: [ERROR] Can't find patch dir at
> ./patches/standard/base
> | 1493125671.3742917: usage: kgit s2q
> | 1493125671.3743172: WARNING: exit code 1 from a shell command.
> | 1493125671.3745801: ERROR: Function failed: do_validate_branches (log
> file is located at /media/build1/poky/build/tmp/w
> ork/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e
> 885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726)
>
> Cheers,
>
> Richard
>
>
>
>


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

Re: [OE-core] linux-yocto.do_validate_branches failing since last oe-core update

2017-04-25 Thread Richard Purdie 
On Mon, 2017-04-24 at 21:06 -0400, Bruce Ashfield wrote:
> On Mon, Apr 24, 2017 at 5:27 PM, Richard Purdie
>  wrote:
> > On Mon, 2017-04-24 at 15:56 -0400, Bruce Ashfield wrote:
> > >
> > >
> > > On Mon, Apr 24, 2017 at 9:54 AM, Bruce Ashfield  > mail
> > > .com> wrote:
> > > >
> > > >
> > > > On Mon, Apr 24, 2017 at 9:39 AM, Martin Jansa  > il.c
> > > > om> wrote:
> > 
> > >
> > > Richard/Ross: are you seeing this same thing on the autobuilder ?
> > >
> > > There's some incantation or config that I'm missing, I assume
> > this is
> > > a straight qemux86 config
> > > with a bitbake of something like core-image-minimal ?
> > 
> > We're not seeing this on the autobuilders. I do suspect something
> > in
> > the handling of extra patches or cfg fragments from SRC_URI if I
> > had to
> > guess. That certainly was the trigger last time I saw this.
> Yah, that's the kicker, I'm still carrying your patch for binfmt_elf,
> and I added two of my own
> + config fragments, and I can't trigger anything.

I managed to reproduce breakage. With master and my separate patch in
SRC_URI:

$ bitbake linux-yocto
$ bitbake linux-yocto -c kernel_checkout -f
$ bitbake linux-yocto

ERROR: linux-yocto-4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0 
do_validate_branches: Function failed: do_validate_branches (log file is 
located at 
/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726)
ERROR: Logfile of failure stored in: 
/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| HEAD is now at fe0fb8d Merge tag 'v4.10.9' into standard/base
| 1493125671.284715: mkdir: cannot create directory ‘.’: File exists
| 1493125671.370592:
| 1493125671.3742917: [ERROR] Can't find patch dir at ./patches/standard/base
| 1493125671.3742917: usage: kgit s2q
| 1493125671.3743172: WARNING: exit code 1 from a shell command.
| 1493125671.3745801: ERROR: Function failed: do_validate_branches (log file is 
located at 
/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/linux-yocto/4.10.9+gitAUTOINC+ad2e885015_fe0fb8da3d-r0/temp/log.do_validate_branches.116726)

Cheers,

Richard



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

Re: [OE-core] [yocto] [RFT] gcc7 and glibc-2.26 recipes

2017-04-25 Thread Burton, Ross 
On 24 April 2017 at 23:00, Nathan Lynch  wrote:

> Does adding this patch to lttng-modules work around it?
>

Yes, it fixes the build here.  I'll throw it at the autobuilder now, can
you send a patch with a commit message that isn't "someone told me to try
this"? :)

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

[OE-core] [PATCH v2] connman: fix race condition with systemd-udev

2017-04-25 Thread Dmitry Rozhkov 
When a new USB network interface is plugged in systemd
fails to rename the new interface (ethX) to a predictable
name [1] because connman locks it first.

Add a fix to connman that makes it to re-evaluate
a known but blacklisted ethernet interface for enabling
after it has got renamed.

Still a user has to blacklist the unpredictable names in
connman herself in order to avoid the race condition.
We cannot blacklist the names by default because there
are cases when one might want to use systemd, but to
disable systemd's predictable names feature.

Fixes [YOCTO #11341]

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Signed-off-by: Dmitry Rozhkov 
---

Changes in v2:
 - do not blacklist unpredictable network interface names by default
   if systemd is in use.

 ...try-to-add-ether-interface-after-renaming.patch | 42 ++
 meta/recipes-connectivity/connman/connman_1.33.bb  |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-connectivity/connman/connman/0001-rtnl-retry-to-add-ether-interface-after-renaming.patch

diff --git 
a/meta/recipes-connectivity/connman/connman/0001-rtnl-retry-to-add-ether-interface-after-renaming.patch
 
b/meta/recipes-connectivity/connman/connman/0001-rtnl-retry-to-add-ether-interface-after-renaming.patch
new file mode 100644
index 000..1806b70
--- /dev/null
+++ 
b/meta/recipes-connectivity/connman/connman/0001-rtnl-retry-to-add-ether-interface-after-renaming.patch
@@ -0,0 +1,42 @@
+From d92e713e112e48cb4434f1c67b97e6507a7cf9e8 Mon Sep 17 00:00:00 2001
+From: Dmitry Rozhkov 
+Date: Thu, 20 Apr 2017 15:54:29 +0300
+Subject: [PATCH] rtnl: retry to add ether interface after renaming
+
+If eth* interfaces are blacklisted to avoid a race condition
+where connman may access an interface before systemd/udev can
+change it to use a predictable interface name then it's impossible
+to re-activate it under a new predictable name because an existing
+interface is considered to be already added to the technology.
+
+Once blacklisted an interface is not re-evaluated under a new name.
+
+This patch allows to re-evaluate an interface known to connman for
+adding it to the ethernet technology in case it's name has changed.
+E.g. after unplugging a cable and plugging it back.
+
+Upstream-Status: Accepted 
[https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=d81f21e32562c83e2a0bdf77e91158c9b3c5945a]
+
+Signed-off-by: Dmitry Rozhkov 
+---
+ src/rtnl.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/rtnl.c b/src/rtnl.c
+index d1b851f..19a999c 100644
+--- a/src/rtnl.c
 b/src/rtnl.c
+@@ -469,7 +469,9 @@ static void process_newlink(unsigned short type, int 
index, unsigned flags,
+ 
+   if (type == ARPHRD_ETHER)
+   read_uevent(interface);
+-  } else
++  } else if (type == ARPHRD_ETHER && interface->device_type == 
CONNMAN_DEVICE_TYPE_UNKNOWN)
++  read_uevent(interface);
++  else
+   interface = NULL;
+ 
+   for (list = rtnl_list; list; list = list->next) {
+-- 
+2.9.3
+
diff --git a/meta/recipes-connectivity/connman/connman_1.33.bb 
b/meta/recipes-connectivity/connman/connman_1.33.bb
index 4129b05..56a4711 100644
--- a/meta/recipes-connectivity/connman/connman_1.33.bb
+++ b/meta/recipes-connectivity/connman/connman_1.33.bb
@@ -6,6 +6,7 @@ SRC_URI  = 
"${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
 file://no-version-scripts.patch \
 file://includes.patch \
 file://0003-stats-Fix-bad-file-descriptor-initialisation.patch \
+file://0001-rtnl-retry-to-add-ether-interface-after-renaming.patch 
\
 "
 SRC_URI_append_libc-musl = " 
file://0002-resolve-musl-does-not-implement-res_ninit.patch \
  
file://0001-Fix-compile-on-musl-with-kernel-4.9-headers.patch"
-- 
2.9.3

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

Re: [OE-core] [PATCH v3 2/2] tcf-agent: enable default target debugging features

2017-04-25 Thread Gernot Hillier 
On 21.04.2017 18:39, Burton, Ross wrote:
> 
> On 20 April 2017 at 20:08, Gernot Hillier  > wrote:
> 
> A number of features were disabled in OE due to historic problems
> on ARM. In tcf-agent 1.4, they compile cleanly on all architectures
> besides mips. These features are required for target debugging with
> Eclipse Neon, CDT and TCF plugins - for example used by Xilinx Vivado
> SDK 2016.4.
> 
> 
> Would this be responsible for this failure under musl on the autobuilder:
> 
> system/GNU/Linux/tcf/context-linux.c:490:10: error: variable 'cmd' has
> initializer but incomplete type
>  enum __ptrace_request cmd = PTRACE_SINGLESTEP;
>   ^~~~

Thanks to pointing me to this!

Looks like we need to disable the advanced tcf-agent features for musl
again as it seems to lack the necessary ptrace header.

I'll double-check other builders and post an updated patch series soon.

-- 
Gernot
Siemens AG, Corporate Competence Center Embedded Linux

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

[OE-core] [PATCH v2] libevent: 2.0.22 -> 2.1.8

2017-04-25 Thread Andrej Valek 
Update libevent to version 2.1.8 and fix test directory creation

License file has been changed due to new MIT license in source code.

Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 .../libevent/Makefile-missing-test-dir.patch   | 27 ++
 .../{libevent_2.0.22.bb => libevent_2.1.8.bb}  | 15 ++--
 2 files changed, 35 insertions(+), 7 deletions(-)
 create mode 100644 
meta/recipes-support/libevent/libevent/Makefile-missing-test-dir.patch
 rename meta/recipes-support/libevent/{libevent_2.0.22.bb => libevent_2.1.8.bb} 
(56%)

diff --git 
a/meta/recipes-support/libevent/libevent/Makefile-missing-test-dir.patch 
b/meta/recipes-support/libevent/libevent/Makefile-missing-test-dir.patch
new file mode 100644
index 000..8880bd0
--- /dev/null
+++ b/meta/recipes-support/libevent/libevent/Makefile-missing-test-dir.patch
@@ -0,0 +1,27 @@
+Fix missing test directory creation.
+
+GCC used in OE-core has "dependency tracking" disabled and
+libevent has problem with this.
+Due to removed makefile.am/in files in test/sample/include
+directories, output directories are not created in
+configuration step. Compilation step will fails, when
+trying to write to non-existing directory.
+
+Upstream-Status: Inappropriate [Other]
+Workaround specific to our build system.
+
+Signed-off-by: Andrej Valek 
+Signed-off-by: Pascal Bach 
+
+diff --git a/libevent-2.1.8-stable/test/include.am 
b/libevent-2.1.8-stable/test/include.am
+index eea249f..d323dff 100644
+--- a/test/include.am
 b/test/include.am
+@@ -161,6 +161,7 @@ test_bench_httpclient_LDADD = $(LIBEVENT_GC_SECTIONS) 
libevent_core.la
+ test/regress.gen.c test/regress.gen.h: test/rpcgen-attempted
+ 
+ test/rpcgen-attempted: test/regress.rpc event_rpcgen.py test/rpcgen_wrapper.sh
++  @$(MKDIR_P) test
+   $(AM_V_GEN)date -u > $@
+   $(AM_V_at)if $(srcdir)/test/rpcgen_wrapper.sh $(srcdir)/test; then \
+  true; \
diff --git a/meta/recipes-support/libevent/libevent_2.0.22.bb 
b/meta/recipes-support/libevent/libevent_2.1.8.bb
similarity index 56%
rename from meta/recipes-support/libevent/libevent_2.0.22.bb
rename to meta/recipes-support/libevent/libevent_2.1.8.bb
index df8a31c..1270d62 100644
--- a/meta/recipes-support/libevent/libevent_2.0.22.bb
+++ b/meta/recipes-support/libevent/libevent_2.1.8.bb
@@ -1,18 +1,19 @@
 SUMMARY = "An asynchronous event notification library"
 HOMEPAGE = "http://libevent.org/;
-BUGTRACKER = "http://sourceforge.net/tracker/?group_id=50884=461322;
+BUGTRACKER = "https://github.com/libevent/libevent/issues;
 SECTION = "libs"
 
-LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=45c5316ff684bcfe2f9f86d8b1279559"
+LICENSE = "BSD & MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=17f20574c0b154d12236d5fbe964f549"
 
 SRC_URI = " \
-${SOURCEFORGE_MIRROR}/levent/${BP}-stable.tar.gz \
+
https://github.com/libevent/libevent/releases/download/release-${PV}-stable/${BP}-stable.tar.gz
 \
+file://Makefile-missing-test-dir.patch \
 file://run-ptest \
 "
 
-SRC_URI[md5sum] = "c4c56f986aa985677ca1db89630a2e11"
-SRC_URI[sha256sum] = 
"71c2c49f0adadacfdbe6332a372c38cf9c8b7895bb73dabeaa53cdcc1d4e1fa3"
+SRC_URI[md5sum] = "f3eeaed018542963b7d2416ef1135ecc"
+SRC_URI[sha256sum] = 
"965cc5a8bb46ce4199a47e9b2c9e1cae3b137e8356ffdad6d94d3b9069b71dc2"
 
 UPSTREAM_CHECK_URI = "http://libevent.org/;
 
@@ -24,7 +25,7 @@ PACKAGECONFIG[openssl] = 
"--enable-openssl,--disable-openssl,openssl"
 inherit autotools
 
 # Needed for Debian packaging
-LEAD_SONAME = "libevent-2.0.so"
+LEAD_SONAME = "libevent-2.1.so"
 
 inherit ptest
 
-- 
2.1.4

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