[OE-core] [PATCH 2/2] mkelfimage: Fix build on x86_64 with hardening

2017-07-18 Thread Khem Raj
We get linking errors on some hosts like
| ld -static --warn-multiple-gp --warn-common -T linux-i386/convert.lds -o 
objdir/linux-i386/convert ob
jdir/linux-i386/head.o objdir/linux-i386/convert_params.o
| objdir/linux-i386/convert_params.o: In function `printf':
| convert_params.c:(.text+0x1fd): undefined reference to 
`__stack_chk_fail_local'

This is because the build system is defaulting to host linker when building
32bit binaries and it may not have same defaults as OE toolchain and issue
gets highlighted.

fix it by using cross linker for 32bit links when building on x86_64

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb 
b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
index 2bcc8d7bd9..2ad4b49ab1 100644
--- a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
+++ b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
@@ -29,6 +29,7 @@ CACHED_CONFIGUREVARS += "\
 HOST_CFLAGS='${BUILD_CFLAGS}' \
 HOST_CPPFLAGS='${BUILD_CPPFLAGS}' \
 "
+EXTRA_OECONF_append_x86-64 = " --with-i386=${HOST_SYS}"
 
 inherit autotools-brokensep
 
-- 
2.13.3

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


[OE-core] [PATCH 1/2] glibc: Update to latest on 2.26 pre-release

2017-07-18 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/recipes-core/glibc/cross-localedef-native_2.25.90.bb | 2 +-
 meta/recipes-core/glibc/glibc_2.25.90.bb  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.25.90.bb 
b/meta/recipes-core/glibc/cross-localedef-native_2.25.90.bb
index 5dd0c70400..429076ea98 100644
--- a/meta/recipes-core/glibc/cross-localedef-native_2.25.90.bb
+++ b/meta/recipes-core/glibc/cross-localedef-native_2.25.90.bb
@@ -22,7 +22,7 @@ SRCBRANCH ?= "master"
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+(\.\d+)*)"
 
-SRCREV_glibc ?= "43a9f537fc121a867981ca31ea9d79f33ce0fd24"
+SRCREV_glibc ?= "91ac3a7d8474480685632cd25f844d3154c69fdf"
 SRCREV_localedef ?= "dfb4afe551c6c6e94f9cc85417bd1f582168c843"
 
 SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
diff --git a/meta/recipes-core/glibc/glibc_2.25.90.bb 
b/meta/recipes-core/glibc/glibc_2.25.90.bb
index caf1ff4138..477b04d867 100644
--- a/meta/recipes-core/glibc/glibc_2.25.90.bb
+++ b/meta/recipes-core/glibc/glibc_2.25.90.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
 
 DEPENDS += "gperf-native"
 
-SRCREV ?= "43a9f537fc121a867981ca31ea9d79f33ce0fd24"
+SRCREV ?= "91ac3a7d8474480685632cd25f844d3154c69fdf"
 
 #SRCBRANCH ?= "release/${PV}/master"
 SRCBRANCH ?= "master"
-- 
2.13.3

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


Re: [OE-core] [PATCH] gcc-7.inc: add new warning "Wnot-cross-compiler"

2017-07-18 Thread Khem Raj
On Tue, Jul 18, 2017 at 8:33 PM, Andre McCurdy  wrote:
> On Tue, Jul 18, 2017 at 5:12 PM, Khem Raj  wrote:
>>
>> On Tue, Jul 18, 2017 at 6:45 PM Juro Bystricky 
>> wrote:
>>>
>>> Suppose we have an autotools project that looks like it is using the cross
>>> compiler but is actually reaching out to the host compiler instead.
>>> On an x86-64 build, you may not even notice.
>>> To be able to prevent this, this patch implements a new gcc warning
>>> "Wnot-cross-compiler". The intention here is to intentionally break a
>>> build
>>> if we are not using a cross-compiler when one is expected to be used.
>>>
>>> Expected usage: " -Wnot-cross-compiler -Werror=not-cross-compiler "will
>>
>> Shouldn't this patch get applied to native gcc on build hosts ?
>
> Isn't the intention that native gcc won't recognise the new options
> and will therefore fail if they're accidentally passed to it?

precisely, the problem is that some host compiler may silently ignore
unknown warnings and some host may not be using gcc as default system
compiler at all e.g. mageia distro and may be more in future.

>
>> And I would suggest to sent it to gcc mailing lists before we apply it to oe
>>>
>>> [YOCTO #11587]
>>>
>>> Signed-off-by: Juro Bystricky 
>>> ---
>>>  meta/recipes-devtools/gcc/gcc-7.1.inc  |  1 +
>>>  .../gcc/gcc-7.1/0051-warn-not-cross-compiler.patch | 39
>>> ++
>>>  2 files changed, 40 insertions(+)
>>>  create mode 100644
>>> meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>>>
>>> diff --git a/meta/recipes-devtools/gcc/gcc-7.1.inc
>>> b/meta/recipes-devtools/gcc/gcc-7.1.inc
>>> index 3f1c06d..e9b1f21 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-7.1.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-7.1.inc
>>> @@ -75,6 +75,7 @@ SRC_URI = "\
>>> file://0048-gcc-Enable-static-PIE.patch \
>>>
>>> file://0049-libsanitizer-Use-stack_t-instead-of-struct-sigaltsta.patch \
>>> file://0050-replace-struct-ucontext-with-ucontext_t.patch \
>>> +   file://0051-warn-not-cross-compiler.patch \
>>> ${BACKPORTS} \
>>>  "
>>>  BACKPORTS = "\
>>> diff --git
>>> a/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>>> b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>>> new file mode 100644
>>> index 000..78671ed
>>> --- /dev/null
>>> +++ b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>>> @@ -0,0 +1,39 @@
>>> +
>>> +This patch implements an additional gcc command line option warning
>>> +"Wnot-cross-compiler". The option (if specified) will simply generate
>>> +a warning if gcc being used is not a cross-compiler.
>>> +
>>> +Upstream-Status: Pending
>>> +Signed-off-by: Juro Bystricky 
>>> +
>>> +
>>> +diff --git a/gcc/common.opt b/gcc/common.opt
>>> +--- a/gcc/common.opt
>>>  b/gcc/common.opt
>>> +@@ -801,6 +801,10 @@
>>> + Common Var(warn_vector_operation_performance) Warning
>>> + Warn when a vector operation is compiled outside the SIMD.
>>> +
>>> ++Wnot-cross-compiler
>>> ++Common Warning
>>> ++Warn when not-cross-compiling.
>>> ++
>>> + Xassembler
>>> + Driver Separate
>>> +
>>> +diff --git a/gcc/opts.c b/gcc/opts.c
>>> +--- a/gcc/opts.c
>>>  b/gcc/opts.c
>>> +@@ -2334,6 +2334,12 @@
>>> +   opts->x_flag_ipa_icf_variables = value;
>>> +   break;
>>> +
>>> ++case OPT_Wnot_cross_compiler:
>>> ++#ifndef CROSS_DIRECTORY_STRUCTURE
>>> ++  warning (OPT_Wnot_cross_compiler, "Not using cross-compiler!");
>>> ++#endif
>>> ++  break;
>>> ++
>>> + default:
>>> +   /* If the flag was handled in a standard way, assume the lack of
>>> +processing here is intentional.  */
>>> --
>>> 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] gcc-7.inc: add new warning "Wnot-cross-compiler"

2017-07-18 Thread Andre McCurdy
On Tue, Jul 18, 2017 at 5:12 PM, Khem Raj  wrote:
>
> On Tue, Jul 18, 2017 at 6:45 PM Juro Bystricky 
> wrote:
>>
>> Suppose we have an autotools project that looks like it is using the cross
>> compiler but is actually reaching out to the host compiler instead.
>> On an x86-64 build, you may not even notice.
>> To be able to prevent this, this patch implements a new gcc warning
>> "Wnot-cross-compiler". The intention here is to intentionally break a
>> build
>> if we are not using a cross-compiler when one is expected to be used.
>>
>> Expected usage: " -Wnot-cross-compiler -Werror=not-cross-compiler "will
>
> Shouldn't this patch get applied to native gcc on build hosts ?

Isn't the intention that native gcc won't recognise the new options
and will therefore fail if they're accidentally passed to it?

> And I would suggest to sent it to gcc mailing lists before we apply it to oe
>>
>> [YOCTO #11587]
>>
>> Signed-off-by: Juro Bystricky 
>> ---
>>  meta/recipes-devtools/gcc/gcc-7.1.inc  |  1 +
>>  .../gcc/gcc-7.1/0051-warn-not-cross-compiler.patch | 39
>> ++
>>  2 files changed, 40 insertions(+)
>>  create mode 100644
>> meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-7.1.inc
>> b/meta/recipes-devtools/gcc/gcc-7.1.inc
>> index 3f1c06d..e9b1f21 100644
>> --- a/meta/recipes-devtools/gcc/gcc-7.1.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-7.1.inc
>> @@ -75,6 +75,7 @@ SRC_URI = "\
>> file://0048-gcc-Enable-static-PIE.patch \
>>
>> file://0049-libsanitizer-Use-stack_t-instead-of-struct-sigaltsta.patch \
>> file://0050-replace-struct-ucontext-with-ucontext_t.patch \
>> +   file://0051-warn-not-cross-compiler.patch \
>> ${BACKPORTS} \
>>  "
>>  BACKPORTS = "\
>> diff --git
>> a/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>> b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>> new file mode 100644
>> index 000..78671ed
>> --- /dev/null
>> +++ b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>> @@ -0,0 +1,39 @@
>> +
>> +This patch implements an additional gcc command line option warning
>> +"Wnot-cross-compiler". The option (if specified) will simply generate
>> +a warning if gcc being used is not a cross-compiler.
>> +
>> +Upstream-Status: Pending
>> +Signed-off-by: Juro Bystricky 
>> +
>> +
>> +diff --git a/gcc/common.opt b/gcc/common.opt
>> +--- a/gcc/common.opt
>>  b/gcc/common.opt
>> +@@ -801,6 +801,10 @@
>> + Common Var(warn_vector_operation_performance) Warning
>> + Warn when a vector operation is compiled outside the SIMD.
>> +
>> ++Wnot-cross-compiler
>> ++Common Warning
>> ++Warn when not-cross-compiling.
>> ++
>> + Xassembler
>> + Driver Separate
>> +
>> +diff --git a/gcc/opts.c b/gcc/opts.c
>> +--- a/gcc/opts.c
>>  b/gcc/opts.c
>> +@@ -2334,6 +2334,12 @@
>> +   opts->x_flag_ipa_icf_variables = value;
>> +   break;
>> +
>> ++case OPT_Wnot_cross_compiler:
>> ++#ifndef CROSS_DIRECTORY_STRUCTURE
>> ++  warning (OPT_Wnot_cross_compiler, "Not using cross-compiler!");
>> ++#endif
>> ++  break;
>> ++
>> + default:
>> +   /* If the flag was handled in a standard way, assume the lack of
>> +processing here is intentional.  */
>> --
>> 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] gcc-7.inc: add new warning "Wnot-cross-compiler"

2017-07-18 Thread Khem Raj
On Tue, Jul 18, 2017 at 6:45 PM Juro Bystricky 
wrote:

> Suppose we have an autotools project that looks like it is using the cross
> compiler but is actually reaching out to the host compiler instead.
> On an x86-64 build, you may not even notice.
> To be able to prevent this, this patch implements a new gcc warning
> "Wnot-cross-compiler". The intention here is to intentionally break a build
> if we are not using a cross-compiler when one is expected to be used.
>
> Expected usage: " -Wnot-cross-compiler -Werror=not-cross-compiler "will


Shouldn't this patch get applied to native gcc on build hosts ?

And I would suggest to sent it to gcc mailing lists before we apply it to
oe

>
>
> [YOCTO #11587]
>
> Signed-off-by: Juro Bystricky 
> ---
>  meta/recipes-devtools/gcc/gcc-7.1.inc  |  1 +
>  .../gcc/gcc-7.1/0051-warn-not-cross-compiler.patch | 39
> ++
>  2 files changed, 40 insertions(+)
>  create mode 100644
> meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-7.1.inc
> b/meta/recipes-devtools/gcc/gcc-7.1.inc
> index 3f1c06d..e9b1f21 100644
> --- a/meta/recipes-devtools/gcc/gcc-7.1.inc
> +++ b/meta/recipes-devtools/gcc/gcc-7.1.inc
> @@ -75,6 +75,7 @@ SRC_URI = "\
> file://0048-gcc-Enable-static-PIE.patch \
>
> file://0049-libsanitizer-Use-stack_t-instead-of-struct-sigaltsta.patch \
> file://0050-replace-struct-ucontext-with-ucontext_t.patch \
> +   file://0051-warn-not-cross-compiler.patch \
> ${BACKPORTS} \
>  "
>  BACKPORTS = "\
> diff --git
> a/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
> b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
> new file mode 100644
> index 000..78671ed
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
> @@ -0,0 +1,39 @@
> +
> +This patch implements an additional gcc command line option warning
> +"Wnot-cross-compiler". The option (if specified) will simply generate
> +a warning if gcc being used is not a cross-compiler.
> +
> +Upstream-Status: Pending
> +Signed-off-by: Juro Bystricky 
> +
> +
> +diff --git a/gcc/common.opt b/gcc/common.opt
> +--- a/gcc/common.opt
>  b/gcc/common.opt
> +@@ -801,6 +801,10 @@
> + Common Var(warn_vector_operation_performance) Warning
> + Warn when a vector operation is compiled outside the SIMD.
> +
> ++Wnot-cross-compiler
> ++Common Warning
> ++Warn when not-cross-compiling.
> ++
> + Xassembler
> + Driver Separate
> +
> +diff --git a/gcc/opts.c b/gcc/opts.c
> +--- a/gcc/opts.c
>  b/gcc/opts.c
> +@@ -2334,6 +2334,12 @@
> +   opts->x_flag_ipa_icf_variables = value;
> +   break;
> +
> ++case OPT_Wnot_cross_compiler:
> ++#ifndef CROSS_DIRECTORY_STRUCTURE
> ++  warning (OPT_Wnot_cross_compiler, "Not using cross-compiler!");
> ++#endif
> ++  break;
> ++
> + default:
> +   /* If the flag was handled in a standard way, assume the lack of
> +processing here is intentional.  */
> --
> 2.7.4
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] gcc-7.inc: add new warning "Wnot-cross-compiler"

2017-07-18 Thread Juro Bystricky
Suppose we have an autotools project that looks like it is using the cross
compiler but is actually reaching out to the host compiler instead.
On an x86-64 build, you may not even notice.
To be able to prevent this, this patch implements a new gcc warning
"Wnot-cross-compiler". The intention here is to intentionally break a build
if we are not using a cross-compiler when one is expected to be used.

Expected usage: " -Wnot-cross-compiler -Werror=not-cross-compiler "

[YOCTO #11587]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-devtools/gcc/gcc-7.1.inc  |  1 +
 .../gcc/gcc-7.1/0051-warn-not-cross-compiler.patch | 39 ++
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.1.inc 
b/meta/recipes-devtools/gcc/gcc-7.1.inc
index 3f1c06d..e9b1f21 100644
--- a/meta/recipes-devtools/gcc/gcc-7.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.1.inc
@@ -75,6 +75,7 @@ SRC_URI = "\
file://0048-gcc-Enable-static-PIE.patch \

file://0049-libsanitizer-Use-stack_t-instead-of-struct-sigaltsta.patch \
file://0050-replace-struct-ucontext-with-ucontext_t.patch \
+   file://0051-warn-not-cross-compiler.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git 
a/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch 
b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
new file mode 100644
index 000..78671ed
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-7.1/0051-warn-not-cross-compiler.patch
@@ -0,0 +1,39 @@
+ 
+This patch implements an additional gcc command line option warning 
+"Wnot-cross-compiler". The option (if specified) will simply generate 
+a warning if gcc being used is not a cross-compiler. 
+
+Upstream-Status: Pending
+Signed-off-by: Juro Bystricky 
+
+
+diff --git a/gcc/common.opt b/gcc/common.opt
+--- a/gcc/common.opt
 b/gcc/common.opt
+@@ -801,6 +801,10 @@
+ Common Var(warn_vector_operation_performance) Warning
+ Warn when a vector operation is compiled outside the SIMD.
+ 
++Wnot-cross-compiler
++Common Warning
++Warn when not-cross-compiling.
++
+ Xassembler
+ Driver Separate
+ 
+diff --git a/gcc/opts.c b/gcc/opts.c
+--- a/gcc/opts.c
 b/gcc/opts.c
+@@ -2334,6 +2334,12 @@
+   opts->x_flag_ipa_icf_variables = value;
+   break;
+ 
++case OPT_Wnot_cross_compiler:
++#ifndef CROSS_DIRECTORY_STRUCTURE
++  warning (OPT_Wnot_cross_compiler, "Not using cross-compiler!");
++#endif
++  break;
++
+ default:
+   /* If the flag was handled in a standard way, assume the lack of
+processing here is intentional.  */
-- 
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 "[morty] libgcrypt: fix CVE-201..." and 1 more

2017-07-18 Thread akuster808



On 07/18/2017 03:31 PM, Patchwork wrote:

== Series Details ==

Series: "[morty] libgcrypt: fix CVE-201..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/7801/


looks like patch test got confused. your patches look fine to me.

- armin

State : failure

== Summary ==


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



* Patch[morty,1/2] libgcrypt: fix CVE-2017-9526
  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



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] ✗ patchtest: failure for "[morty] libgcrypt: fix CVE-201..." and 1 more

2017-07-18 Thread Patchwork
== Series Details ==

Series: "[morty] libgcrypt: fix CVE-201..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/7801/
State : failure

== Summary ==


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



* Patch[morty,1/2] libgcrypt: fix CVE-2017-9526
 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



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] ✗ patchtest: failure for "[pyro] libgcrypt: fix CVE-2017..." and 1 more

2017-07-18 Thread Patchwork
== Series Details ==

Series: "[pyro] libgcrypt: fix CVE-2017..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/7800/
State : failure

== Summary ==


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



* Patch[pyro,1/2] libgcrypt: fix CVE-2017-9526
 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



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][morty 1/2] libgcrypt: fix CVE-2017-9526

2017-07-18 Thread Burton, Ross
On 18 July 2017 at 23:09, akuster808  wrote:

> is this version 2 or resend?
>

See I thought I had already sent it but didn't see it in my outbox, so I
sent it again.  It's just a resend.

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


Re: [OE-core] [PATCH][morty 1/2] libgcrypt: fix CVE-2017-9526

2017-07-18 Thread akuster808



On 07/18/2017 03:07 PM, Ross Burton wrote:

In libgcrypt before 1.7.7, an attacker who learns the EdDSA session key (from
side-channel observation during the signing process) can easily recover the
long-term secret key. 1.7.7 makes a cipher/ecc-eddsa.c change to store this
session key in secure memory, to ensure that constant-time point operations are
used in the MPI library.


is this version 2 or resend?

- armin

Signed-off-by: Ross Burton 
---
  ...-Store-EdDSA-session-key-in-secure-memory.patch | 39 ++
  meta/recipes-support/libgcrypt/libgcrypt.inc   |  1 +
  2 files changed, 40 insertions(+)
  create mode 100644 
meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch

diff --git 
a/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
 
b/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
new file mode 100644
index 000..f6c4ca76f33
--- /dev/null
+++ 
b/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
@@ -0,0 +1,39 @@
+CVE: CVE-2017-9526
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From b3cab278eb9c2ceda79f980bc26460d97f260041 Mon Sep 17 00:00:00 2001
+From: Jo Van Bulck 
+Date: Thu, 19 Jan 2017 17:00:15 +0100
+Subject: [PATCH] ecc: Store EdDSA session key in secure memory.
+
+* cipher/ecc-eddsa.c (_gcry_ecc_eddsa_sign): use mpi_snew to allocate
+session key.
+--
+
+An attacker who learns the EdDSA session key from side-channel
+observation during the signing process, can easily revover the long-
+term secret key. Storing the session key in secure memory ensures that
+constant time point operations are used in the MPI library.
+
+Signed-off-by: Jo Van Bulck 
+---
+ cipher/ecc-eddsa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cipher/ecc-eddsa.c b/cipher/ecc-eddsa.c
+index f91f8489..813e030d 100644
+--- a/cipher/ecc-eddsa.c
 b/cipher/ecc-eddsa.c
+@@ -603,7 +603,7 @@ _gcry_ecc_eddsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+   a = mpi_snew (0);
+   x = mpi_new (0);
+   y = mpi_new (0);
+-  r = mpi_new (0);
++  r = mpi_snew (0);
+   ctx = _gcry_mpi_ec_p_internal_new (skey->E.model, skey->E.dialect, 0,
+  skey->E.p, skey->E.a, skey->E.b);
+   b = (ctx->nbits+7)/8;
+--
+2.11.0
+
diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc 
b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 15805cd4365..7c4c0e83b53 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -20,6 +20,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \
 file://libgcrypt-fix-building-error-with-O2-in-sysroot-path.patch \
 file://fix-ICE-failure-on-mips-with-option-O-and-g.patch \
 file://fix-undefined-reference-to-pthread.patch \
+   file://0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch \
  "
  
  BINCONFIG = "${bindir}/libgcrypt-config"


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


[OE-core] [PATCH][morty 1/2] libgcrypt: fix CVE-2017-9526

2017-07-18 Thread Ross Burton
In libgcrypt before 1.7.7, an attacker who learns the EdDSA session key (from
side-channel observation during the signing process) can easily recover the
long-term secret key. 1.7.7 makes a cipher/ecc-eddsa.c change to store this
session key in secure memory, to ensure that constant-time point operations are
used in the MPI library.

Signed-off-by: Ross Burton 
---
 ...-Store-EdDSA-session-key-in-secure-memory.patch | 39 ++
 meta/recipes-support/libgcrypt/libgcrypt.inc   |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch

diff --git 
a/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
 
b/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
new file mode 100644
index 000..f6c4ca76f33
--- /dev/null
+++ 
b/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
@@ -0,0 +1,39 @@
+CVE: CVE-2017-9526
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From b3cab278eb9c2ceda79f980bc26460d97f260041 Mon Sep 17 00:00:00 2001
+From: Jo Van Bulck 
+Date: Thu, 19 Jan 2017 17:00:15 +0100
+Subject: [PATCH] ecc: Store EdDSA session key in secure memory.
+
+* cipher/ecc-eddsa.c (_gcry_ecc_eddsa_sign): use mpi_snew to allocate
+session key.
+--
+
+An attacker who learns the EdDSA session key from side-channel
+observation during the signing process, can easily revover the long-
+term secret key. Storing the session key in secure memory ensures that
+constant time point operations are used in the MPI library.
+
+Signed-off-by: Jo Van Bulck 
+---
+ cipher/ecc-eddsa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cipher/ecc-eddsa.c b/cipher/ecc-eddsa.c
+index f91f8489..813e030d 100644
+--- a/cipher/ecc-eddsa.c
 b/cipher/ecc-eddsa.c
+@@ -603,7 +603,7 @@ _gcry_ecc_eddsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+   a = mpi_snew (0);
+   x = mpi_new (0);
+   y = mpi_new (0);
+-  r = mpi_new (0);
++  r = mpi_snew (0);
+   ctx = _gcry_mpi_ec_p_internal_new (skey->E.model, skey->E.dialect, 0,
+  skey->E.p, skey->E.a, skey->E.b);
+   b = (ctx->nbits+7)/8;
+-- 
+2.11.0
+
diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc 
b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 15805cd4365..7c4c0e83b53 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -20,6 +20,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \
file://libgcrypt-fix-building-error-with-O2-in-sysroot-path.patch \
file://fix-ICE-failure-on-mips-with-option-O-and-g.patch \
file://fix-undefined-reference-to-pthread.patch \
+   file://0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch \
 "
 
 BINCONFIG = "${bindir}/libgcrypt-config"
-- 
2.11.0

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


[OE-core] [PATCH][morty 2/2] libgcrypt: fix CVE-2017-7526

2017-07-18 Thread Ross Burton
Fixes CVE-2017-7526, 'flush+reload side-channel attack on RSA secret keys dubbed
"Sliding right into disaster"'.

Signed-off-by: Ross Burton 
---
 .../libgcrypt/files/CVE-2017-7526.patch| 455 +
 meta/recipes-support/libgcrypt/libgcrypt.inc   |   1 +
 2 files changed, 456 insertions(+)
 create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch

diff --git a/meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch 
b/meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch
new file mode 100644
index 000..7180e7af2c3
--- /dev/null
+++ b/meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch
@@ -0,0 +1,455 @@
+Flush+reload side-channel attack on RSA secret keys dubbed "Sliding right
+into disaster".
+
+CVE: CVE-2017-7526
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 56bd068335500207dea2cece9cc662bcd9658951 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka 
+Date: Tue, 4 Apr 2017 17:38:05 +0900
+Subject: [PATCH 1/5] mpi: Simplify mpi_powm.
+
+* mpi/mpi-pow.c (_gcry_mpi_powm): Simplify the loop.
+
+--
+
+This fix is not a solution for the problem reported (yet).  The
+problem is that the current algorithm of _gcry_mpi_powm depends on
+exponent and some information leaks is possible.
+
+Reported-by: Andreas Zankl 
+Signed-off-by: NIIBE Yutaka 
+
+(backport from master commit:
+719468e53133d3bdf12156c5bfdea2bf15f9f6f1)
+
+Signed-off-by: Ross Burton 
+---
+ mpi/mpi-pow.c | 105 +-
+ 1 file changed, 30 insertions(+), 75 deletions(-)
+
+diff --git a/mpi/mpi-pow.c b/mpi/mpi-pow.c
+index a780ebd1..7b3dc318 100644
+--- a/mpi/mpi-pow.c
 b/mpi/mpi-pow.c
+@@ -609,12 +609,8 @@ _gcry_mpi_powm (gcry_mpi_t res,
+   if (e == 0)
+ {
+   j += c;
+-  i--;
+-  if ( i < 0 )
+-{
+-  c = 0;
+-  break;
+-}
++  if ( --i < 0 )
++break;
+ 
+   e = ep[i];
+   c = BITS_PER_MPI_LIMB;
+@@ -629,38 +625,33 @@ _gcry_mpi_powm (gcry_mpi_t res,
+   c -= c0;
+   j += c0;
+ 
++  e0 = (e >> (BITS_PER_MPI_LIMB - W));
+   if (c >= W)
+-{
+-  e0 = (e >> (BITS_PER_MPI_LIMB - W));
+-  e = (e << W);
+-  c -= W;
+-}
++c0 = 0;
+   else
+ {
+-  i--;
+-  if ( i < 0 )
++  if ( --i < 0 )
+ {
+-  e = (e >> (BITS_PER_MPI_LIMB - c));
+-  break;
++  e0 = (e >> (BITS_PER_MPI_LIMB - c));
++  j += c - W;
++  goto last_step;
++}
++  else
++{
++  c0 = c;
++  e = ep[i];
++  c = BITS_PER_MPI_LIMB;
++  e0 |= (e >> (BITS_PER_MPI_LIMB - (W - c0)));
+ }
+-
+-  c0 = c;
+-  e0 = (e >> (BITS_PER_MPI_LIMB - W))
+-| (ep[i] >> (BITS_PER_MPI_LIMB - W + c0));
+-  e = (ep[i] << (W - c0));
+-  c = BITS_PER_MPI_LIMB - W + c0;
+ }
+ 
++  e = e << (W - c0);
++  c -= (W - c0);
++
++last_step:
+   count_trailing_zeros (c0, e0);
+   e0 = (e0 >> c0) >> 1;
+ 
+-  for (j += W - c0; j; j--)
+-{
+-  mul_mod (xp, , rp, rsize, rp, rsize, mp, msize, );
+-  tp = rp; rp = xp; xp = tp;
+-  rsize = xsize;
+-}
+-
+   /*
+*  base_u <= precomp[e0]
+*  base_u_size <= precomp_size[e0]
+@@ -677,25 +668,23 @@ _gcry_mpi_powm (gcry_mpi_t res,
+   u.d = precomp[k];
+ 
+   mpi_set_cond (, , k == e0);
+-  base_u_size |= (precomp_size[k] & ((mpi_size_t)0 - (k == e0)) );
++  base_u_size |= ( precomp_size[k] & ((mpi_size_t)0 - (k == e0)) 
);
+ }
+ 
+-  mul_mod (xp, , rp, rsize, base_u, base_u_size,
+-   mp, msize, );
+-  tp = rp; rp = xp; xp = tp;
+-  rsize = xsize;
++  for (j += W - c0; j >= 0; j--)
++{
++  mul_mod (xp, , rp, rsize,
++   j == 0 ? base_u : rp, j == 0 ? base_u_size : rsize,
++   mp, msize, );
++  tp = rp; rp = xp; xp = tp;
++  rsize = xsize;
++}
+ 
+   j = c0;
++  if ( i < 0 )
++break;
+ }
+ 
+-if (c != 0)
+-  {
+-j += c;
+-count_trailing_zeros (c, e);
+-e = (e >> c);
+-j -= c;
+-  }
+-
+ while (j--)
+   {
+ mul_mod (xp, , rp, rsize, rp, rsize, mp, msize, );
+@@ -703,40 +692,6 @@ _gcry_mpi_powm (gcry_mpi_t res,
+ rsize = 

[OE-core] [PATCH][pyro 1/2] libgcrypt: fix CVE-2017-9526

2017-07-18 Thread Ross Burton
In libgcrypt before 1.7.7, an attacker who learns the EdDSA session key (from
side-channel observation during the signing process) can easily recover the
long-term secret key. 1.7.7 makes a cipher/ecc-eddsa.c change to store this
session key in secure memory, to ensure that constant-time point operations are
used in the MPI library.

Signed-off-by: Ross Burton 
---
 ...-Store-EdDSA-session-key-in-secure-memory.patch | 39 ++
 meta/recipes-support/libgcrypt/libgcrypt.inc   |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch

diff --git 
a/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
 
b/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
new file mode 100644
index 000..0a4dfe67737
--- /dev/null
+++ 
b/meta/recipes-support/libgcrypt/files/0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch
@@ -0,0 +1,39 @@
+CVE: CVE-2017-9526
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 4a1768d683f6572ad86d833508c70e6b3dc1efdc Mon Sep 17 00:00:00 2001
+From: Jo Van Bulck 
+Date: Thu, 19 Jan 2017 17:00:15 +0100
+Subject: [PATCH] ecc: Store EdDSA session key in secure memory.
+
+* cipher/ecc-eddsa.c (_gcry_ecc_eddsa_sign): use mpi_snew to allocate
+session key.
+--
+
+An attacker who learns the EdDSA session key from side-channel
+observation during the signing process, can easily revover the long-
+term secret key. Storing the session key in secure memory ensures that
+constant time point operations are used in the MPI library.
+
+Signed-off-by: Jo Van Bulck 
+---
+ cipher/ecc-eddsa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cipher/ecc-eddsa.c b/cipher/ecc-eddsa.c
+index f91f8489..813e030d 100644
+--- a/cipher/ecc-eddsa.c
 b/cipher/ecc-eddsa.c
+@@ -603,7 +603,7 @@ _gcry_ecc_eddsa_sign (gcry_mpi_t input, ECC_secret_key 
*skey,
+   a = mpi_snew (0);
+   x = mpi_new (0);
+   y = mpi_new (0);
+-  r = mpi_new (0);
++  r = mpi_snew (0);
+   ctx = _gcry_mpi_ec_p_internal_new (skey->E.model, skey->E.dialect, 0,
+  skey->E.p, skey->E.a, skey->E.b);
+   b = (ctx->nbits+7)/8;
+-- 
+2.11.0
+
diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc 
b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 84c1cc018b3..e95c059c875 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -20,6 +20,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \
file://libgcrypt-fix-building-error-with-O2-in-sysroot-path.patch \
file://fix-ICE-failure-on-mips-with-option-O-and-g.patch \
file://fix-undefined-reference-to-pthread.patch \
+   file://0001-ecc-Store-EdDSA-session-key-in-secure-memory.patch \
 "
 
 BINCONFIG = "${bindir}/libgcrypt-config"
-- 
2.11.0

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


[OE-core] [PATCH][pyro 2/2] libgcrypt: fix CVE-2017-7526

2017-07-18 Thread Ross Burton
Fixes CVE-2017-7526, 'flush+reload side-channel attack on RSA secret keys dubbed
"Sliding right into disaster"'.

Signed-off-by: Ross Burton 
---
 .../libgcrypt/files/CVE-2017-7526.patch| 455 +
 meta/recipes-support/libgcrypt/libgcrypt.inc   |   1 +
 2 files changed, 456 insertions(+)
 create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch

diff --git a/meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch 
b/meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch
new file mode 100644
index 000..384fa964ae5
--- /dev/null
+++ b/meta/recipes-support/libgcrypt/files/CVE-2017-7526.patch
@@ -0,0 +1,455 @@
+Flush+reload side-channel attack on RSA secret keys dubbed "Sliding right
+into disaster".
+
+CVE: CVE-2017-7526
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 12ee400c39e0ebb5fb819c3926d459c278fc99fd Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka 
+Date: Tue, 4 Apr 2017 17:38:05 +0900
+Subject: [PATCH 1/5] mpi: Simplify mpi_powm.
+
+* mpi/mpi-pow.c (_gcry_mpi_powm): Simplify the loop.
+
+--
+
+This fix is not a solution for the problem reported (yet).  The
+problem is that the current algorithm of _gcry_mpi_powm depends on
+exponent and some information leaks is possible.
+
+Reported-by: Andreas Zankl 
+Signed-off-by: NIIBE Yutaka 
+
+(backport from master commit:
+719468e53133d3bdf12156c5bfdea2bf15f9f6f1)
+
+Signed-off-by: Ross Burton 
+---
+ mpi/mpi-pow.c | 105 +-
+ 1 file changed, 30 insertions(+), 75 deletions(-)
+
+diff --git a/mpi/mpi-pow.c b/mpi/mpi-pow.c
+index a780ebd1..7b3dc318 100644
+--- a/mpi/mpi-pow.c
 b/mpi/mpi-pow.c
+@@ -609,12 +609,8 @@ _gcry_mpi_powm (gcry_mpi_t res,
+   if (e == 0)
+ {
+   j += c;
+-  i--;
+-  if ( i < 0 )
+-{
+-  c = 0;
+-  break;
+-}
++  if ( --i < 0 )
++break;
+ 
+   e = ep[i];
+   c = BITS_PER_MPI_LIMB;
+@@ -629,38 +625,33 @@ _gcry_mpi_powm (gcry_mpi_t res,
+   c -= c0;
+   j += c0;
+ 
++  e0 = (e >> (BITS_PER_MPI_LIMB - W));
+   if (c >= W)
+-{
+-  e0 = (e >> (BITS_PER_MPI_LIMB - W));
+-  e = (e << W);
+-  c -= W;
+-}
++c0 = 0;
+   else
+ {
+-  i--;
+-  if ( i < 0 )
++  if ( --i < 0 )
+ {
+-  e = (e >> (BITS_PER_MPI_LIMB - c));
+-  break;
++  e0 = (e >> (BITS_PER_MPI_LIMB - c));
++  j += c - W;
++  goto last_step;
++}
++  else
++{
++  c0 = c;
++  e = ep[i];
++  c = BITS_PER_MPI_LIMB;
++  e0 |= (e >> (BITS_PER_MPI_LIMB - (W - c0)));
+ }
+-
+-  c0 = c;
+-  e0 = (e >> (BITS_PER_MPI_LIMB - W))
+-| (ep[i] >> (BITS_PER_MPI_LIMB - W + c0));
+-  e = (ep[i] << (W - c0));
+-  c = BITS_PER_MPI_LIMB - W + c0;
+ }
+ 
++  e = e << (W - c0);
++  c -= (W - c0);
++
++last_step:
+   count_trailing_zeros (c0, e0);
+   e0 = (e0 >> c0) >> 1;
+ 
+-  for (j += W - c0; j; j--)
+-{
+-  mul_mod (xp, , rp, rsize, rp, rsize, mp, msize, );
+-  tp = rp; rp = xp; xp = tp;
+-  rsize = xsize;
+-}
+-
+   /*
+*  base_u <= precomp[e0]
+*  base_u_size <= precomp_size[e0]
+@@ -677,25 +668,23 @@ _gcry_mpi_powm (gcry_mpi_t res,
+   u.d = precomp[k];
+ 
+   mpi_set_cond (, , k == e0);
+-  base_u_size |= (precomp_size[k] & ((mpi_size_t)0 - (k == e0)) );
++  base_u_size |= ( precomp_size[k] & ((mpi_size_t)0 - (k == e0)) 
);
+ }
+ 
+-  mul_mod (xp, , rp, rsize, base_u, base_u_size,
+-   mp, msize, );
+-  tp = rp; rp = xp; xp = tp;
+-  rsize = xsize;
++  for (j += W - c0; j >= 0; j--)
++{
++  mul_mod (xp, , rp, rsize,
++   j == 0 ? base_u : rp, j == 0 ? base_u_size : rsize,
++   mp, msize, );
++  tp = rp; rp = xp; xp = tp;
++  rsize = xsize;
++}
+ 
+   j = c0;
++  if ( i < 0 )
++break;
+ }
+ 
+-if (c != 0)
+-  {
+-j += c;
+-count_trailing_zeros (c, e);
+-e = (e >> c);
+-j -= c;
+-  }
+-
+ while (j--)
+   {
+ mul_mod (xp, , rp, rsize, rp, rsize, mp, msize, );
+@@ -703,40 +692,6 @@ _gcry_mpi_powm (gcry_mpi_t res,
+ rsize = 

Re: [OE-core] [morty][PATCH] glibc: Fix CVE-2015-5180

2017-07-18 Thread akuster808


Yualie,

On 07/17/2017 11:14 PM, Yuanjie Huang wrote:

Backport upstream patch to fix NULL pointer dereference and process
crash in libresolv. (CVE-2015-5180)
I will have to hand merge the bb file as I have several other glibc 
changes sitting in my contrib branch.

Thanks for the patch.


Signed-off-by: Yuanjie Huang 
---
  meta/recipes-core/glibc/glibc/CVE-2015-5180.patch | 136 ++
  meta/recipes-core/glibc/glibc_2.24.bb |   1 +
  2 files changed, 137 insertions(+)
  create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-5180.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-5180.patch 
b/meta/recipes-core/glibc/glibc/CVE-2015-5180.patch
new file mode 100644
index 00..638f652c4d
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2015-5180.patch
@@ -0,0 +1,136 @@
+From a8476611d5bca2032a2d18c503996762ac26a489 Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Sat, 31 Dec 2016 20:22:09 +0100
+Subject: CVE-2015-5180: resolv: Fix crash with internal QTYPE [BZ #18784]
+
+Also rename T_UNSPEC because an upcoming public header file
+update will use that name.
+
+(cherry picked from commit fc82b0a2dfe7dbd35671c10510a8da1043d746a5)
+
+Upstream-Status: Backport[master]
+CVE: CVE-2015-5180
+Signed-off-by: Yuanjie Huang 
+---
+ ChangeLog | 11 +++
+ NEWS  |  6 ++
+ include/arpa/nameser_compat.h |  6 +++---
+ resolv/nss_dns/dns-host.c |  2 +-
+ resolv/res_mkquery.c  |  4 
+ resolv/res_query.c|  6 +++---
+ 6 files changed, 28 insertions(+), 7 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 0fbda9020e..180634e658 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,14 @@
++2017-03-07  Siddhesh Poyarekar  
++
++  [BZ #18784]
++  CVE-2015-5180
++  * include/arpa/nameser_compat.h (T_QUERY_A_AND_): Rename from
++  T_UNSPEC.  Adjust value.
++  * resolv/nss_dns/dns-host.c (_nss_dns_gethostbyname4_r): Use it.
++  * resolv/res_query.c (__libc_res_nquery): Likewise.
++  * resolv/res_mkquery.c (res_nmkquery): Check for out-of-range
++  QTYPEs.
++
+ 2016-01-28  Carlos O'Donell  
+   Alexey Makhalov 
+   Florian Weimer 
+diff --git a/NEWS b/NEWS
+index b0447e7169..366f602aac 100644
+--- a/NEWS
 b/NEWS
+@@ -71,6 +71,12 @@ Security related changes:
+   and exits.  Over time, this could result in a denial of service due to
+   memory exhaustion.  Reported by Matthias Schiffer.  (CVE-2016-5417)
+
++* The DNS stub resolver functions would crash due to a NULL pointer
++  dereference when processing a query with a valid DNS question type which
++  was used internally in the implementation.  The stub resolver now uses a
++  question type which is outside the range of valid question type values.
++  (CVE-2015-5180)
++
+ The following bugs are resolved with this release:
+
+   [1170] localedata: ne_NP: update Nepali locale definition file
+diff --git a/include/arpa/nameser_compat.h b/include/arpa/nameser_compat.h
+index 2e735ede4c..7c0deed9ae 100644
+--- a/include/arpa/nameser_compat.h
 b/include/arpa/nameser_compat.h
+@@ -1,8 +1,8 @@
+ #ifndef _ARPA_NAMESER_COMPAT_
+ #include 
+
+-/* Picksome unused number to represent lookups of IPv4 and IPv6 (i.e.,
+-   T_A and T_).  */
+-#define T_UNSPEC 62321
++/* The number is outside the 16-bit RR type range and is used
++   internally by the implementation.  */
++#define T_QUERY_A_AND_ 439963904
+
+ #endif
+diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
+index 5f9e35701b..d16fa4b8ed 100644
+--- a/resolv/nss_dns/dns-host.c
 b/resolv/nss_dns/dns-host.c
+@@ -323,7 +323,7 @@ _nss_dns_gethostbyname4_r (const char *name, struct 
gaih_addrtuple **pat,
+
+   int olderr = errno;
+   enum nss_status status;
+-  int n = __libc_res_nsearch (&_res, name, C_IN, T_UNSPEC,
++  int n = __libc_res_nsearch (&_res, name, C_IN, T_QUERY_A_AND_,
+ host_buffer.buf->buf, 2048, _buffer.ptr,
+ , , , _malloced);
+   if (n >= 0)
+diff --git a/resolv/res_mkquery.c b/resolv/res_mkquery.c
+index 12f9730199..d80b5318e5 100644
+--- a/resolv/res_mkquery.c
 b/resolv/res_mkquery.c
+@@ -103,6 +103,10 @@ res_nmkquery(res_state statp,
+   int n;
+   u_char *dnptrs[20], **dpp, **lastdnptr;
+
++  if (class < 0 || class > 65535
++  || type < 0 || type > 65535)
++return -1;
++
+ #ifdef DEBUG
+   if (statp->options & RES_DEBUG)
+   printf(";; res_nmkquery(%s, %s, %s, %s)\n",
+diff --git a/resolv/res_query.c b/resolv/res_query.c
+index 944d1a90f5..07dc6f6583 100644
+--- a/resolv/res_query.c
 b/resolv/res_query.c
+@@ -122,7 +122,7 @@ __libc_res_nquery(res_state statp,
+   int n, use_malloc = 0;
+   u_int oflags = 

Re: [OE-core] [PATCH 0/1] bind: 9.10..3-P3 -> 9.10.5-P3

2017-07-18 Thread Khem Raj
On Tue, Jul 18, 2017 at 3:14 PM, Alexander Kanavin
 wrote:
> On 07/18/2017 05:04 AM, Kang Kai wrote:
>
>bind: 9.10..3-P3 -> 9.10.5-P3
>>>
>>>
>>> Why not 9.11.1?
>>
>>
>> If bind 9.11.x is needed, we could add its recipe. But I think the 9.10.x
>> version should be kept for compatibility.
>
>
> The policy in oe-core master is to update to latest stable upstream
> releases, so please provide an update to 9.11.x. If you want to keep 9.10.x,
> you can do that, but please provide a more specific reason.

if there are ABI incompatible changes then we have to scope the impact
and plan the upgrade accordingly, if its backward compatible then yes its
the norm.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/1] bind: 9.10..3-P3 -> 9.10.5-P3

2017-07-18 Thread Alexander Kanavin

On 07/18/2017 05:04 AM, Kang Kai wrote:

   bind: 9.10..3-P3 -> 9.10.5-P3


Why not 9.11.1?


If bind 9.11.x is needed, we could add its recipe. But I think the 
9.10.x version should be kept for compatibility.


The policy in oe-core master is to update to latest stable upstream 
releases, so please provide an update to 9.11.x. If you want to keep 
9.10.x, you can do that, but please provide a more specific reason.


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


Re: [OE-core] [PATCH 2/6] cryptodev: 1.8 -> 1.9

2017-07-18 Thread Denys Dmytriyenko
On Sat, Jul 15, 2017 at 06:13:55AM -0700, Khem Raj wrote:
> On Thu, Jul 13, 2017 at 3:03 AM, Robert Yang  
> wrote:
> >
> >
> > On 07/13/2017 05:50 PM, Burton, Ross wrote:
> >>
> >>
> >> On 13 July 2017 at 03:51, Robert Yang  >> > wrote:
> >>
> >> BTW, I sent a meta-gplv2 patch to p...@yoctoproject.org
> >>  two days ago, but
> >> I didn't find it in p...@yoctoproject.org
> >> ,
> >> Ross, did you see it, please ?
> >> Maybe I should send it again.
> >>
> >>
> >> The list is yo...@yoctoproject.org .
> >> Please
> >> resend to the list.
> >
> >
> > Sorry, I had sent it to yo...@lists.yoctoproject.org which is from README,
> > but
> > I didn't get it in my mailing list, and I resent it to
> > yo...@yoctoproject.org
> > just now, I got it, should we update README, please ?
> 
> now meta-intel stepped ahead by applying the patch where as OE-Core
> does not (yet)
> have this patch applied. meta-intel should have waited for this patch
> to land in master.

Should this kind of behavior be addressed by BSP Guidelines and the Yocto 
Project Compatible 2.0 requirements?

Also, which BSPs are enabled on the OE-Core autobuilder by default?

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


Re: [OE-core] [PATCH] gstreamer1.0-python: add new recipe

2017-07-18 Thread Martin Kelly

On 07/18/2017 11:37 AM, Khem Raj wrote:

On Tue, Jul 18, 2017 at 12:21 PM, Martin Kelly  wrote:

On 07/17/2017 07:47 PM, Khem Raj wrote:


On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly  wrote:


Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35
++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb



I think everything in single file would be better



I'm fine with that, but I was just following the convention that the rest of
the gstreamer packaging uses; all the recipes in
meta/recipes-multimedia/gstreamer use the same convention. I figured it's
cleaner to keep all of it consistent. Would you prefer I diverge anyway?



I dont have strong preference here.



OK, I sent a new version with just the license change.



diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..3299b89daa
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/;
+SECTION = "multimedia"
+LICENSE = "LGPLv2"
+



this should be 2.1 most probably



Yes you're right, I'll change it.



+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI =
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the
build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it
looks for a
+# symlinked library ending in .so instead of the actually library
with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use
the path
+# we want, it will break again if the library version ever changes.
We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian
packaging for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI =
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] =
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
--
2.11.0

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

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


[OE-core] [PATCH v2] gstreamer1.0-python: add new recipe

2017-07-18 Thread Martin Kelly
Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35 ++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..961b93017e
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/;
+SECTION = "multimedia"
+LICENSE = "LGPLv2.1"
+
+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it looks for a
+# symlinked library ending in .so instead of the actually library with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
+# we want, it will break again if the library version ever changes. We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian packaging 
for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] = 
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
-- 
2.11.0

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


Re: [OE-core] [PATCH] systemd-bootchart: Fix build with glibc 2.26

2017-07-18 Thread Khem Raj
On Tue, Jul 18, 2017 at 6:52 AM, Jussi Kukkonen
 wrote:
> xlocale.h is no more, don't include it.
>

looks good

> Signed-off-by: Jussi Kukkonen 
> ---
>  .../0001-parse-util-Don-t-use-xlocale.h.patch  | 32 
> ++
>  .../systemd-bootchart/systemd-bootchart_231.bb |  4 ++-
>  2 files changed, 35 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
>
> diff --git 
> a/meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
>  
> b/meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
> new file mode 100644
> index 000..5aa0463
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
> @@ -0,0 +1,32 @@
> +From d379126d56d0b6e935b2d97ca71579e6cc54d1bb Mon Sep 17 00:00:00 2001
> +From: Jussi Kukkonen 
> +Date: Tue, 18 Jul 2017 13:37:27 +0300
> +Subject: [PATCH] parse-util: Don't use xlocale.h
> +
> +glibc 2.26 no longer contains the non-standard xlocale.h
> +(http://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.h.27)
> +
> +This change shouldn't break anything as xlocale.h was a subset of
> +locale.h.
> +
> +Signed-off-by: Jussi Kukkonen 
> +Upstream-Status: Submitted 
> [https://github.com/systemd/systemd-bootchart/pull/35]
> +---
> + src/parse-util.c | 1 -
> + 1 file changed, 1 deletion(-)
> +
> +diff --git a/src/parse-util.c b/src/parse-util.c
> +index 5635a68..1b2169c 100644
> +--- a/src/parse-util.c
>  b/src/parse-util.c
> +@@ -21,7 +21,6 @@
> + #include 
> + #include 
> + #include 
> +-#include 
> +
> + #include "macro.h"
> + #include "parse-util.h"
> +--
> +2.13.2
> +
> diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb 
> b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
> index 1d88036..4da000e 100644
> --- a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
> +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
> @@ -2,7 +2,9 @@ LICENSE = "LGPLv2.1 & GPLv2"
>  LIC_FILES_CHKSUM = 
> "file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c \
>  file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe"
>
> -SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https"
> +SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https \
> +   file://0001-parse-util-Don-t-use-xlocale.h.patch \
> +"
>
>  # Modify these as desired
>  PV = "231+git${SRCPV}"
> --
> 2.1.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] gstreamer1.0-python: add new recipe

2017-07-18 Thread Khem Raj
On Tue, Jul 18, 2017 at 12:21 PM, Martin Kelly  wrote:
> On 07/17/2017 07:47 PM, Khem Raj wrote:
>>
>> On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly  wrote:
>>>
>>> Previously, we had a gst-python recipe, but it supported only GStreamer
>>> 0.1. After GStreamer switched the Python bindings to use GObject
>>> introspection, we were no longer able to build the bindings, and they
>>> were dropped in this patch:
>>>
>>> https://patchwork.openembedded.org/patch/93793/
>>>
>>> However, at this point, we have a gobject-introspection class, so we can
>>> use the bindings again, this time with GStreamer 1.0.
>>>
>>> Signed-off-by: Martin Kelly 
>>> ---
>>>  .../gstreamer/gstreamer1.0-python.inc  | 35
>>> ++
>>>  .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
>>>  2 files changed, 42 insertions(+)
>>>  create mode 100644
>>> meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
>>>  create mode 100644
>>> meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
>>
>>
>> I think everything in single file would be better
>>
>
> I'm fine with that, but I was just following the convention that the rest of
> the gstreamer packaging uses; all the recipes in
> meta/recipes-multimedia/gstreamer use the same convention. I figured it's
> cleaner to keep all of it consistent. Would you prefer I diverge anyway?
>

I dont have strong preference here.

>>>
>>> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
>>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
>>> new file mode 100644
>>> index 00..3299b89daa
>>> --- /dev/null
>>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
>>> @@ -0,0 +1,35 @@
>>> +SUMMARY = "Python bindings for GStreamer 1.0"
>>> +HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/;
>>> +SECTION = "multimedia"
>>> +LICENSE = "LGPLv2"
>>> +
>>
>>
>> this should be 2.1 most probably
>>
>
> Yes you're right, I'll change it.
>
>
>>> +DEPENDS = "gstreamer1.0 python3-pygobject"
>>> +RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
>>> +
>>> +PNREAL = "gst-python"
>>> +
>>> +SRC_URI =
>>> "http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
>>> +
>>> +S = "${WORKDIR}/${PNREAL}-${PV}"
>>> +
>>> +inherit autotools pkgconfig distutils3-base upstream-version-is-even
>>> gobject-introspection
>>> +
>>> +do_install_append() {
>>> +# gstpythonplugin hardcodes the location of the libpython from the
>>> build
>>> +# workspace and then fails at runtime. We can override it using
>>> +# --with-libpython-dir=${libdir}, but it still fails because it
>>> looks for a
>>> +# symlinked library ending in .so instead of the actually library
>>> with
>>> +# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use
>>> the path
>>> +# we want, it will break again if the library version ever changes.
>>> We need
>>> +# to think about the best way of handling this and possibly consult
>>> +# upstream.
>>> +#
>>> +# Note that this particular find line is taken from the Debian
>>> packaging for
>>> +# gst-python1.0.
>>> +find "${D}" \
>>> +-name '*.pyc' -o \
>>> +-name '*.pyo' -o \
>>> +-name '*.la' -o \
>>> +-name 'libgstpythonplugin*' \
>>> +-delete
>>> +}
>>> diff --git
>>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
>>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
>>> new file mode 100644
>>> index 00..1365f7c6dd
>>> --- /dev/null
>>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
>>> @@ -0,0 +1,7 @@
>>> +require gstreamer1.0-python.inc
>>> +
>>> +SRC_URI =
>>> "http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
>>> +SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
>>> +SRC_URI[sha256sum] =
>>> "59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
>>> +
>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
>>> --
>>> 2.11.0
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] bluez5: cosmetic fixes to bluetooth bootscript

2017-07-18 Thread Javier Viguera
Fix booting messages wrapped over two different lines:

Starting bluetooth
bluetoothd

Stopping bluetooth
/usr/libexec/bluetooth/bluetoothd

Also reworked whitespace (removed some empty lines).

Signed-off-by: Javier Viguera 
---
 meta/recipes-connectivity/bluez5/bluez5/init | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5/init 
b/meta/recipes-connectivity/bluez5/bluez5/init
index 489e9b9eba33..d7972f2d950b 100644
--- a/meta/recipes-connectivity/bluez5/bluez5/init
+++ b/meta/recipes-connectivity/bluez5/bluez5/init
@@ -21,25 +21,22 @@ set -e
 
 case $1 in
   start)
-   echo "Starting $DESC"
-
+   echo -n "Starting $DESC: "
if test "$BLUETOOTH_ENABLED" = 0; then
-   echo "disabled. see /etc/default/bluetooth"
+   echo "disabled (see /etc/default/bluetooth)."
exit 0
fi
-
start-stop-daemon --start --background $SSD_OPTIONS
-   echo "${DAEMON##*/}"
-
+   echo "${DAEMON##*/}."
   ;;
   stop)
-   echo "Stopping $DESC"
+   echo -n "Stopping $DESC: "
if test "$BLUETOOTH_ENABLED" = 0; then
-   echo "disabled."
+   echo "disabled (see /etc/default/bluetooth)."
exit 0
fi
start-stop-daemon --stop $SSD_OPTIONS
-   echo "${DAEMON}"
+   echo "${DAEMON##*/}."
   ;;
   restart|force-reload)
$0 stop
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] gstreamer1.0-python: add new recipe

2017-07-18 Thread Martin Kelly

On 07/17/2017 07:47 PM, Khem Raj wrote:

On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly  wrote:

Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35 ++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb


I think everything in single file would be better



I'm fine with that, but I was just following the convention that the 
rest of the gstreamer packaging uses; all the recipes in 
meta/recipes-multimedia/gstreamer use the same convention. I figured 
it's cleaner to keep all of it consistent. Would you prefer I diverge 
anyway?




diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..3299b89daa
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/;
+SECTION = "multimedia"
+LICENSE = "LGPLv2"
+


this should be 2.1 most probably



Yes you're right, I'll change it.


+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it looks for a
+# symlinked library ending in .so instead of the actually library with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
+# we want, it will break again if the library version ever changes. We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian packaging 
for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz;
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] = 
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
--
2.11.0

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

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


[OE-core] ✗ patchtest: failure for systemd: refuse to load units with errors (CVE-2017-1000082)

2017-07-18 Thread Patchwork
== Series Details ==

Series: systemd: refuse to load units with errors (CVE-2017-182)
Revision: 1
URL   : https://patchwork.openembedded.org/series/7796/
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:



* Patchsystemd: refuse to load units with errors (CVE-2017-182)
 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



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] systemd: refuse to load units with errors (CVE-2017-1000082)

2017-07-18 Thread Ross Burton
If a unit has a statement such as User=0day where the username exists but is
strictly speaking invalid, the unit will be started as the root user instead.

Backport a patch from upstream to mitigate this by refusing to start units such
as this.

Signed-off-by: Ross Burton 
---
 ...ragment-refuse-units-with-errors-in-certa.patch | 329 +
 meta/recipes-core/systemd/systemd_232.bb   |   1 +
 2 files changed, 330 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-core-load-fragment-refuse-units-with-errors-in-certa.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-core-load-fragment-refuse-units-with-errors-in-certa.patch
 
b/meta/recipes-core/systemd/systemd/0001-core-load-fragment-refuse-units-with-errors-in-certa.patch
new file mode 100644
index 000..80948b2ceea
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-core-load-fragment-refuse-units-with-errors-in-certa.patch
@@ -0,0 +1,329 @@
+If a user is created with a strictly-speaking invalid name such as '0day' and a
+unit created to run as that user, systemd rejects the username and runs the 
unit
+as root.
+
+CVE: CVE-2017-182
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From d8e1310e1ed7b6f122bc7eb8ba061fbd088783c0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= 
+Date: Thu, 6 Jul 2017 13:28:19 -0400
+Subject: [PATCH] core/load-fragment: refuse units with errors in certain
+ directives
+
+If an error is encountered in any of the Exec* lines, WorkingDirectory,
+SELinuxContext, ApparmorProfile, SmackProcessLabel, Service (in .socket
+units), User, or Group, refuse to load the unit. If the config stanza
+has support, ignore the failure if '-' is present.
+
+For those configuration directives, even if we started the unit, it's
+pretty likely that it'll do something unexpected (like write files
+in a wrong place, or with a wrong context, or run with wrong permissions,
+etc). It seems better to refuse to start the unit and have the admin
+clean up the configuration without giving the service a chance to mess
+up stuff.
+
+Note that all "security" options that restrict what the unit can do
+(Capabilities, AmbientCapabilities, Restrict*, SystemCallFilter, Limit*,
+PrivateDevices, Protect*, etc) are _not_ treated like this. Such options are
+only supplementary, and are not always available depending on the architecture
+and compilation options, so unit authors have to make sure that the service
+runs correctly without them anyway.
+
+Fixes #6237, #6277.
+
+Signed-off-by: Ross Burton 
+---
+ src/core/load-fragment.c  | 104 --
+ src/test/test-unit-file.c |  14 +++
+ 2 files changed, 70 insertions(+), 48 deletions(-)
+
+diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
+index cbc826809..2047974f4 100644
+--- a/src/core/load-fragment.c
 b/src/core/load-fragment.c
+@@ -630,20 +630,28 @@ int config_parse_exec(
+ 
+ if (isempty(f)) {
+ /* First word is either "-" or "@" with no command. */
+-log_syntax(unit, LOG_ERR, filename, line, 0, "Empty 
path in command line, ignoring: \"%s\"", rvalue);
+-return 0;
++log_syntax(unit, LOG_ERR, filename, line, 0,
++   "Empty path in command line%s: \"%s\"",
++   ignore ? ", ignoring" : "", rvalue);
++return ignore ? 0 : -ENOEXEC;
+ }
+ if (!string_is_safe(f)) {
+-log_syntax(unit, LOG_ERR, filename, line, 0, 
"Executable path contains special characters, ignoring: %s", rvalue);
+-return 0;
++log_syntax(unit, LOG_ERR, filename, line, 0,
++   "Executable path contains special 
characters%s: %s",
++   ignore ? ", ignoring" : "", rvalue);
++return ignore ? 0 : -ENOEXEC;
+ }
+ if (!path_is_absolute(f)) {
+-log_syntax(unit, LOG_ERR, filename, line, 0, 
"Executable path is not absolute, ignoring: %s", rvalue);
+-return 0;
++log_syntax(unit, LOG_ERR, filename, line, 0,
++   "Executable path is not absolute%s: %s",
++   ignore ? ", ignoring" : "", rvalue);
++return ignore ? 0 : -ENOEXEC;
+ }
+ if (endswith(f, "/")) {
+-log_syntax(unit, LOG_ERR, filename, line, 0, 
"Executable path specifies a directory, ignoring: %s", rvalue);
+-return 0;
++log_syntax(unit, LOG_ERR, filename, line, 0,
++ 

Re: [OE-core] [PATCHv3 11/30] oeqa/selftest/{case, context}: Add builddir by test class and context

2017-07-18 Thread Aníbal Limón


On 07/17/2017 04:45 PM, Aníbal Limón wrote:
> The build directory by Test class will enable to use several instances
> of bitbake in parallel to enable oe-selftest threaded runs.
> 
> [YOCTO #11429]
> 
> Signed-off-by: Aníbal Limón 
> ---
>  meta/lib/oeqa/selftest/case.py| 97 
> ---
>  meta/lib/oeqa/selftest/context.py |  4 ++
>  2 files changed, 74 insertions(+), 27 deletions(-)
> 
> diff --git a/meta/lib/oeqa/selftest/case.py b/meta/lib/oeqa/selftest/case.py
> index 871009c568b..dd24e366abd 100644
> --- a/meta/lib/oeqa/selftest/case.py
> +++ b/meta/lib/oeqa/selftest/case.py
> @@ -13,28 +13,73 @@ from oeqa.utils.commands import runCmd, bitbake, 
> get_bb_var
>  from oeqa.core.case import OETestCase
>  
>  class OESelftestTestCase(OETestCase):
> +_use_own_builddir = False
> +_main_thread = True
> +_end_thread = False
> +
>  def __init__(self, methodName="runTest"):
>  self._extra_tear_down_commands = []
>  super(OESelftestTestCase, self).__init__(methodName)
>  
>  @classmethod
> +def _setUpBuildDir(cls):
> +if cls._use_own_builddir:
> +cls.builddir = os.path.join(cls.tc.config_paths['base_builddir'],
> +cls.__module__, cls.__name__)
> +
> +cls.localconf_path = os.path.join(cls.builddir, 
> "conf/local.conf")
> +cls.localconf_backup = os.path.join(cls.builddir,
> +"conf/local.conf.bk")
> +cls.local_bblayers_path = os.path.join(cls.builddir,
> +"conf/bblayers.conf")
> +cls.local_bblayers_backup = os.path.join(cls.builddir,
> +"conf/bblayers.conf.bk")
> +else:
> +cls.builddir = cls.tc.config_paths['builddir']
> +cls.localconf_path = cls.tc.config_paths['localconf']
> +cls.localconf_backup = 
> cls.tc.config_paths['localconf_class_backup']
> +cls.local_bblayers_path = cls.tc.config_paths['bblayers']
> +cls.local_bblayers_backup = \
> +cls.tc.config_paths['bblayers_class_backup']
> +
> +cls.testinc_path = os.path.join(cls.builddir, "conf/selftest.inc")
> +cls.testinc_bblayers_path = os.path.join(cls.builddir,
> +"conf/bblayers.inc")
> +cls.machineinc_path = os.path.join(cls.builddir, "conf/machine.inc")
> +
> +# creates a custom build directory for every test class
> +if not os.path.exists(cls.builddir):
> +os.makedirs(cls.builddir)
> +
> +builddir_conf = os.path.join(cls.builddir, 'conf')
> +origdir_conf = os.path.join(cls.tc.config_paths['builddir'], 
> 'conf')
> +shutil.copytree(origdir_conf, builddir_conf)
> +
> +ftools.append_file(cls.localconf_path, "# added by oe-selftest 
> base class")
> +
> +# shares original sstate_dir across build directories to speed up
> +sstate_line = "SSTATE_DIR=\"%s\"" % cls.td['SSTATE_DIR']
> +ftools.append_file(cls.localconf_path, sstate_line)
> +
> +# shares original dl_dir across build directories to avoid 
> additional
> +# network usage
> +dldir_line = "DL_DIR=\"%s\"" % cls.td['DL_DIR']
> +ftools.append_file(cls.localconf_path, dldir_line)

I sent a bad version of this patch, the DL_DIR and SSTATE_DIR needs to
be set as ?= to don't interfere with certain tests that set the same
variables.

The integration branch has the good one,

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=alimon/oe_selftest_threaded

Cheers,
Anibal

> +
> +# use the same value of threads for 
> BB_NUMBER_THREADS/PARALLEL_MAKE
> +# to avoid ran out resources (cpu/memory)
> +if hasattr(cls.tc.loader, 'process_num'):
> +ftools.append_file(cls.localconf_path, 
> "BB_NUMBER_THREADS?=\"%d\"" %
> +cls.tc.loader.process_num)
> +ftools.append_file(cls.localconf_path, "PARALLEL_MAKE?=\"-j 
> %d\"" %
> +cls.tc.loader.process_num)
> +
> +@classmethod
>  def setUpClass(cls):
>  super(OESelftestTestCase, cls).setUpClass()
>  
>  cls.testlayer_path = cls.tc.config_paths['testlayer_path']
> -cls.builddir = cls.tc.config_paths['builddir']
> -
> -cls.localconf_path = cls.tc.config_paths['localconf']
> -cls.localconf_backup = cls.tc.config_paths['localconf_class_backup']
> -cls.local_bblayers_path = cls.tc.config_paths['bblayers']
> -cls.local_bblayers_backup = 
> cls.tc.config_paths['bblayers_class_backup']
> -
> -cls.testinc_path = os.path.join(cls.tc.config_paths['builddir'],
> -"conf/selftest.inc")
> -cls.testinc_bblayers_path = 
> os.path.join(cls.tc.config_paths['builddir'],
> -"conf/bblayers.inc")
> -cls.machineinc_path = 

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

2017-07-18 Thread Haris Okanovic



On 07/17/2017 03:31 PM, Wold, Saul wrote:

On Wed, 2017-07-05 at 12:33 -0500, Haris Okanovic wrote:

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

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

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

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

Discussion thread:
http://lists.openembedded.org/pipermail/openembedded-core/2015-Decemb
er/thread.html#114122

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

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

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


So I finally had a chance to get back to this and test build with it, I
saw the following WARNING, which lead to the ERROR:

WARNING: Variable key FILES_${PN}-dev (${includedir} ${FILES_SOLIBSDEV}
${libdir}/*.la ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig
${datadir}/aclocal ${base_libdir}/*.o ${libdir}/${BPN}/*.la
${base_libdir}/*.la) replaces original key FILES_linux-yocto-dev
(/boot/System.map* /boot/Module.symvers* /boot/config*
${KERNEL_SRC_PATH}
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build).
ERROR: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0
do_package: QA Issue: linux-yocto: Files/directories were installed but
not shipped in any package:
   /boot/System.map-4.10.17-yocto-standard
   /boot/Module.symvers-4.10.17-yocto-standard
   /boot/config-4.10.17-yocto-standard
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install.
linux-yocto: 3 installed and not shipped files. [installed-vs-shipped]
ERROR: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0
do_package: Fatal QA errors found, failing task.
ERROR: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0
do_package: Function failed: do_package

Something seems to be causing the FILES_linux-yocto-dev info to be
overridden, I have not tracked down the culprit yet.



`FILES_linux-yocto-dev` is set to the default value from OE's 
bitbake.conf. `FILES_kernel-dev` on the other hand is set by 
kernel.bbclass; when `KERNEL_PACKAGE_NAME` expands to `kernel`.


I think the real issue here is that QA checks care about 
`FILES_${PN}-dev` at all even though that particular package name isn't 
listed in `PACKAGES` variable. I.e. `FILES_${PN}-dev` should be 
disregarded since the `linux-yocto` 

Re: [OE-core] State of bitbake world, Failed tasks 2017-07-16

2017-07-18 Thread Khem Raj
On Tue, Jul 18, 2017 at 4:22 AM, Martin Jansa  wrote:
> I don't know what setup you're using, but my is described here:
> http://www.openembedded.org/wiki/Bitbake_World_Status_Setup
>

interesting parts are
https://github.com/shr-project/jenkins-jobs/blob/master/jenkins-job.sh#L329-L350

I see that firefox, mariadb are because the setup uses gold linker

pmloglib really needs to fix the snprintf call properly.

systemd-bootchart needs the systemd fix done for xlocale.h removal

ippool problem is that some portions are ignoring CFLAGS which mean -On
param is not passed but security flags are passed one of secflags is
FORTIFY_SOURCES which does require some Olevel enabled. A fix is
to append SELECTED_OPTIMIZATION to SECURITY_CFLAGS but
surprisingly. I cant reproduce it on my end. you can try such a fix and see if
that helps.

> and the current version published with the results:
> http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170717_011149.log/world_fixes.inc
>
> now I see that e.g. security-flags.inc addition i not shown in
> world_fixes.inc above, because I've added it to local.conf in:
> https://github.com/shr-project/jenkins-jobs/commit/94a25010b439e9144e4b564102c4ee7a7c1e5277
>
> I'll move them and few other lines to world_fixes.inc.
>
>
> On Tue, Jul 18, 2017 at 5:03 AM, Khem Raj  wrote:
>>
>> firefox and ipppool seems to not fail for me here.
>> so I wonder what might be different.
>>
>> On Mon, Jul 17, 2017 at 11:49 AM, Martin Jansa 
>> wrote:
>> > The v2s of those patches really helped:
>> >
>> > 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-07-17 ||5 ||4 ||4 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0
>> > ||0 ||0 ||0 ||
>> > |}
>> >
>> > == Failed tasks 2017-07-17 ==
>> >
>> > INFO: jenkins-job.sh-1.8.25 Complete log available at
>> >
>> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20170717_054804.log
>> >
>> > === common (4) ===
>> > *
>> > meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
>> > *
>> >
>> > meta-openembedded/meta-networking/recipes-daemons/ippool/ippool_1.3.bb:do_compile
>> > *
>> >
>> > meta-webos-ports/meta-luneui/recipes-webos/pmloglib/pmloglib.bb:do_compile
>> > *
>> >
>> > openembedded-core/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb:do_compile
>> >
>> > === common-x86 (0) ===
>> >
>> > === qemuarm (1) ===
>> > *
>> >
>> > meta-openembedded/meta-oe/recipes-support/mysql/mariadb_5.5.55.bb:do_compile
>> >
>> > === qemux86 (0) ===
>> >
>> > === qemux86_64 (0) ===
>> >
>> > === Number of failed tasks (13) ===
>> > {| class=wikitable
>> > |-
>> > || qemuarm || 5 ||
>> >
>> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170717_011149.log/
>> > || http://errors.yoctoproject.org/Errors/Build/41271/
>> > |-
>> > || qemux86 || 4 ||
>> >
>> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemux86.20170717_011149.log/
>> > || http://errors.yoctoproject.org/Errors/Build/41272/
>> > |-
>> > || qemux86_64 || 4 ||
>> >
>> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemux86-64.20170717_031905.log/
>> > || http://errors.yoctoproject.org/Errors/Build/41273/
>> > |}
>> >
>> > === PNBLACKLISTs (14) ===
>> >
>> > === QA issues (0) ===
>> > {| class=wikitable
>> > !| Count ||Issue
>> > |-
>> > ||0 ||already-stripped
>> > |-
>> > ||0 ||build-deps
>> > |-
>> > ||0 ||compile-host-path
>> > |-
>> > ||0 ||file-rdeps
>> > |-
>> > ||0 ||host-user-contaminated
>> > |-
>> > ||0 ||installed-vs-shipped
>> > |-
>> > ||0 ||invalid-pkgconfig
>> > |-
>> > ||0 ||ldflags
>> > |-
>> > ||0 ||libdir
>> > |-
>> > ||0 ||pkgname
>> > |-
>> > ||0 ||symlink-to-sysroot
>> > |-
>> > ||0 ||textrel
>> > |-
>> > ||0 ||unknown-configure-option
>> > |-
>> > ||0 ||version-going-backwards
>> > |}
>> >
>> >
>> >
>> > === Incorrect PACKAGE_ARCH or sstate signatures (0) ===
>> >
>> > Complete log:
>> >
>> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.signatures.20170717_031354.log/
>> >
>> > No issues detected
>> >
>> >
>> > PNBLACKLISTs:
>> > openembedded-core/:
>> > meta-browser:
>> > meta-openembedded:
>> >
>> > meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.17.bb:PNBLACKLIST[lksctp-tools]
>> > ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', "BROKEN: fails
>> > to
>> > link against sctp_connectx symbol", '', d)}"
>> >
>> > 

Re: [OE-core] [PATCH] bitbake.conf: Add unzip hosttool

2017-07-18 Thread Ricardo Ribalda Delgado
Hi Ross

That did the trick. I have just posted a new patch!

Thanks!

On Tue, Jul 18, 2017 at 12:47 PM, Burton, Ross  wrote:
>
> On 18 July 2017 at 11:03, Ricardo Ribalda Delgado
>  wrote:
>>
>> Unzip is required for jar files. Without this patch:
>> ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
>> 'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
>> command
>>
>> PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
>> ..."
>> unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
>> return value 127
>
>
> Proper fix is to fix the automatic dependency generation.
>
> The bitbake fetcher handles jar files:
>
> elif file.endswith('.zip') or file.endswith('.jar'):
> ...
> cmd = 'unzip -q -o'
>
> But the dependency generation in base.bbclass just handles .zip:
>
> # .zip should DEPEND on unzip-native for unpacking
> elif path.endswith('.zip'):
> d.appendVarFlag('do_unpack', 'depends', '
> unzip-native:do_populate_sysroot')
>
> So the fix is to extend that test in base.bbclass to handle .zip and .jar.
>
> Ross



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


[OE-core] [PATCH] base.bbclass: Make .jar file depend on unzip-native

2017-07-18 Thread Ricardo Ribalda Delgado
Unzip is required for jar files. Without this patch:
ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
command
PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
 ..."
unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
return value 127

Suggested-by: Ross Burton 
Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/classes/base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 27a28b8b8c47..4b05d5d4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -628,7 +628,7 @@ python () {
 d.appendVarFlag('do_unpack', 'depends', ' 
xz-native:do_populate_sysroot')
 
 # .zip should DEPEND on unzip-native for unpacking
-elif path.endswith('.zip'):
+elif path.endswith('.zip') or path.endswith('.jar'):
 d.appendVarFlag('do_unpack', 'depends', ' 
unzip-native:do_populate_sysroot')
 
 # file is needed by rpm2cpio.sh
-- 
2.13.2

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


[OE-core] [PATCH] systemd-bootchart: Fix build with glibc 2.26

2017-07-18 Thread Jussi Kukkonen
xlocale.h is no more, don't include it.

Signed-off-by: Jussi Kukkonen 
---
 .../0001-parse-util-Don-t-use-xlocale.h.patch  | 32 ++
 .../systemd-bootchart/systemd-bootchart_231.bb |  4 ++-
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch

diff --git 
a/meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
 
b/meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
new file mode 100644
index 000..5aa0463
--- /dev/null
+++ 
b/meta/recipes-devtools/systemd-bootchart/files/0001-parse-util-Don-t-use-xlocale.h.patch
@@ -0,0 +1,32 @@
+From d379126d56d0b6e935b2d97ca71579e6cc54d1bb Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Tue, 18 Jul 2017 13:37:27 +0300
+Subject: [PATCH] parse-util: Don't use xlocale.h
+
+glibc 2.26 no longer contains the non-standard xlocale.h
+(http://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.h.27)
+
+This change shouldn't break anything as xlocale.h was a subset of
+locale.h.
+
+Signed-off-by: Jussi Kukkonen 
+Upstream-Status: Submitted 
[https://github.com/systemd/systemd-bootchart/pull/35]
+---
+ src/parse-util.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/parse-util.c b/src/parse-util.c
+index 5635a68..1b2169c 100644
+--- a/src/parse-util.c
 b/src/parse-util.c
+@@ -21,7 +21,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ 
+ #include "macro.h"
+ #include "parse-util.h"
+-- 
+2.13.2
+
diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb 
b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
index 1d88036..4da000e 100644
--- a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
+++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
@@ -2,7 +2,9 @@ LICENSE = "LGPLv2.1 & GPLv2"
 LIC_FILES_CHKSUM = 
"file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c \
 file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe"
 
-SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https"
+SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https \
+   file://0001-parse-util-Don-t-use-xlocale.h.patch \
+"
 
 # Modify these as desired
 PV = "231+git${SRCPV}"
-- 
2.1.4

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


Re: [OE-core] [PATCH] bitbake.conf: Add unzip hosttool

2017-07-18 Thread Burton, Ross
On 18 July 2017 at 11:03, Ricardo Ribalda Delgado  wrote:

> Unzip is required for jar files. Without this patch:
> ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
> 'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
> command
> PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/
> tmp/sysroots-uninative/x86_64-linux/usr/bin ..."
> unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
> return value 127
>

Proper fix is to fix the automatic dependency generation.

The bitbake fetcher handles jar files:

elif file.endswith('.zip') or file.endswith('.jar'):
...
cmd = 'unzip -q -o'

But the dependency generation in base.bbclass just handles .zip:

# .zip should DEPEND on unzip-native for unpacking
elif path.endswith('.zip'):
d.appendVarFlag('do_unpack', 'depends', '
unzip-native:do_populate_sysroot')

So the fix is to extend that test in base.bbclass to handle .zip and .jar.

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


Re: [OE-core] [PATCH] bitbake.conf: Add unzip hosttool

2017-07-18 Thread Martin Jansa
There is unzip-native available, so you should add it to DEPENDS only where
needed.e.g. like in:
https://github.com/OSSystems/meta-browser/commit/bd2c39ddba00a3e0171e30ee4a4585b56122990a


On Tue, Jul 18, 2017 at 11:03 AM, Ricardo Ribalda Delgado <
ricardo.riba...@gmail.com> wrote:

> Unzip is required for jar files. Without this patch:
> ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
> 'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
> command
> PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/
> tmp/sysroots-uninative/x86_64-linux/usr/bin ..."
> unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
> return value 127
>
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  meta/conf/bitbake.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 9a3aa8bbf29e..35608d0fa787 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -477,7 +477,7 @@ HOSTTOOLS += "ip ping ps scp ssh stty"
>  HOSTTOOLS_NONFATAL += "aws ccache gcc-ar gpg ld.bfd ld.gold nc sftp socat
> sudo"
>
>  # Temporary add few more detected in bitbake world
> -HOSTTOOLS_NONFATAL += "join nl size yes zcat"
> +HOSTTOOLS_NONFATAL += "join nl size unzip yes zcat"
>
>  CCACHE ??= ""
>  # ccache < 3.1.10 will create CCACHE_DIR on startup even if disabled, and
> --
> 2.13.2
>
> --
> ___
> 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] bitbake.conf: Add unzip hosttool

2017-07-18 Thread Ricardo Ribalda Delgado
Unzip is required for jar files. Without this patch:
ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
command
PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
 ..."
unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
return value 127

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

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9a3aa8bbf29e..35608d0fa787 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -477,7 +477,7 @@ HOSTTOOLS += "ip ping ps scp ssh stty"
 HOSTTOOLS_NONFATAL += "aws ccache gcc-ar gpg ld.bfd ld.gold nc sftp socat sudo"
 
 # Temporary add few more detected in bitbake world
-HOSTTOOLS_NONFATAL += "join nl size yes zcat"
+HOSTTOOLS_NONFATAL += "join nl size unzip yes zcat"
 
 CCACHE ??= ""
 # ccache < 3.1.10 will create CCACHE_DIR on startup even if disabled, and
-- 
2.13.2

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


Re: [OE-core] [PATCH 2/6] cryptodev: 1.8 -> 1.9

2017-07-18 Thread Robert Yang



On 07/18/2017 04:45 PM, Paul Eggleton wrote:

On Thursday, 13 July 2017 12:03:19 PM CEST Robert Yang wrote:

On 07/13/2017 05:50 PM, Burton, Ross wrote:

The list is yo...@yoctoproject.org .
Please resend to the list.


Sorry, I had sent it to yo...@lists.yoctoproject.org which is from README,
but I didn't get it in my mailing list, and I resent it to
yo...@yoctoproject.org just now, I got it, should we update README, please ?


As far as I am aware both of these addresses go to the same list, so there
shouldn't be any need to change it.


Unfortunately, yo...@lists.yoctoproject.org seemed not work, I can't receive
the email that I had sent to it.

// Robert



Cheers,
Paul


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


Re: [OE-core] [PATCH 2/6] cryptodev: 1.8 -> 1.9

2017-07-18 Thread Paul Eggleton
On Thursday, 13 July 2017 12:03:19 PM CEST Robert Yang wrote:
> On 07/13/2017 05:50 PM, Burton, Ross wrote:
> > The list is yo...@yoctoproject.org .
> > Please resend to the list.
> 
> Sorry, I had sent it to yo...@lists.yoctoproject.org which is from README,
> but I didn't get it in my mailing list, and I resent it to
> yo...@yoctoproject.org just now, I got it, should we update README, please ?

As far as I am aware both of these addresses go to the same list, so there 
shouldn't be any need to change it.

Cheers,
Paul

-- 

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


Re: [OE-core] State of bitbake world, Failed tasks 2017-07-16

2017-07-18 Thread Martin Jansa
I don't know what setup you're using, but my is described here:
http://www.openembedded.org/wiki/Bitbake_World_Status_Setup

and the current version published with the results:
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170717_011149.log/world_fixes.inc

now I see that e.g. security-flags.inc addition i not shown in
world_fixes.inc above, because I've added it to local.conf in:
https://github.com/shr-project/jenkins-jobs/commit/94a25010b439e9144e4b564102c4ee7a7c1e5277

I'll move them and few other lines to world_fixes.inc.


On Tue, Jul 18, 2017 at 5:03 AM, Khem Raj  wrote:

> firefox and ipppool seems to not fail for me here.
> so I wonder what might be different.
>
> On Mon, Jul 17, 2017 at 11:49 AM, Martin Jansa 
> wrote:
> > The v2s of those patches really helped:
> >
> > 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-07-17 ||5 ||4 ||4 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0 ||0
> ||0 ||0 ||0 ||
> > |}
> >
> > == Failed tasks 2017-07-17 ==
> >
> > INFO: jenkins-job.sh-1.8.25 Complete log available at
> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
> report.20170717_054804.log
> >
> > === common (4) ===
> > * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:d
> o_compile
> > *
> > meta-openembedded/meta-networking/recipes-daemons/ippool/ippool_1.3.bb:
> do_compile
> > *
> > meta-webos-ports/meta-luneui/recipes-webos/pmloglib/pmloglib.bb:
> do_compile
> > *
> > openembedded-core/meta/recipes-devtools/systemd-
> bootchart/systemd-bootchart_231.bb:do_compile
> >
> > === common-x86 (0) ===
> >
> > === qemuarm (1) ===
> > *
> > meta-openembedded/meta-oe/recipes-support/mysql/mariadb_5.5.55.bb:
> do_compile
> >
> > === qemux86 (0) ===
> >
> > === qemux86_64 (0) ===
> >
> > === Number of failed tasks (13) ===
> > {| class=wikitable
> > |-
> > || qemuarm || 5 ||
> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
> world.qemuarm.20170717_011149.log/
> > || http://errors.yoctoproject.org/Errors/Build/41271/
> > |-
> > || qemux86 || 4 ||
> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
> world.qemux86.20170717_011149.log/
> > || http://errors.yoctoproject.org/Errors/Build/41272/
> > |-
> > || qemux86_64 || 4 ||
> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
> world.qemux86-64.20170717_031905.log/
> > || http://errors.yoctoproject.org/Errors/Build/41273/
> > |}
> >
> > === PNBLACKLISTs (14) ===
> >
> > === QA issues (0) ===
> > {| class=wikitable
> > !| Count ||Issue
> > |-
> > ||0 ||already-stripped
> > |-
> > ||0 ||build-deps
> > |-
> > ||0 ||compile-host-path
> > |-
> > ||0 ||file-rdeps
> > |-
> > ||0 ||host-user-contaminated
> > |-
> > ||0 ||installed-vs-shipped
> > |-
> > ||0 ||invalid-pkgconfig
> > |-
> > ||0 ||ldflags
> > |-
> > ||0 ||libdir
> > |-
> > ||0 ||pkgname
> > |-
> > ||0 ||symlink-to-sysroot
> > |-
> > ||0 ||textrel
> > |-
> > ||0 ||unknown-configure-option
> > |-
> > ||0 ||version-going-backwards
> > |}
> >
> >
> >
> > === Incorrect PACKAGE_ARCH or sstate signatures (0) ===
> >
> > Complete log:
> > http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.
> signatures.20170717_031354.log/
> >
> > No issues detected
> >
> >
> > PNBLACKLISTs:
> > openembedded-core/:
> > meta-browser:
> > meta-openembedded:
> > meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.17.bb:
> PNBLACKLIST[lksctp-tools]
> > ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', "BROKEN:
> fails to
> > link against sctp_connectx symbol", '', d)}"
> > meta-oe/recipes-connectivity/bluez/bluez-hcidump_2.5.bb:PNB
> LACKLIST[bluez-hcidump]
> > ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts
> with
> > bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
> > meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb:PNBLACKLIST[bluez4]
> ?=
> > "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts
> with
> > bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
> > meta-oe/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb:
> PNBLACKLIST[gst-plugin-bluetooth]
> > ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts
> with
> > bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
> > meta-oe/recipes-graphics/libsexy/libsexy_0.1.11.bb:PNBLACKLIST[libsexy]
> ?=
> > "Fails to build with RSS
> > http://errors.yoctoproject.org/Errors/Details/130607/ - the recipe will
> be
> > removed on 2017-09-01 unless the 

[OE-core] [PATCH 0/2] acl,at: reduce local pending patches

2017-07-18 Thread Dengke Du
The following changes since commit 81498aac9560fbeaeb58eaada32ce80e0ea51628:

  yocto-project-qs: Updated Next Steps list (2017-07-12 00:28:16 +0100)

are available in the git repository at:

  https://github.com/DengkeDu/openembedded-core.git 
dengke/acl-at-reduce-local-pending-patches
  https://github.com//tree/dengke/acl-at-reduce-local-pending-patches

Dengke Du (2):
  at: reduce local pending patches
  acl: reduce local pending patches

 .../at/at/0001-remove-glibc-assumption.patch| 12 +++-
 .../attr/acl/test-fix-directory-permissions.patch   | 17 ++---
 2 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.8.1

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


[OE-core] [PATCH 2/2] acl: reduce local pending patches

2017-07-18 Thread Dengke Du
Signed-off-by: Dengke Du 
---
 .../attr/acl/test-fix-directory-permissions.patch   | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch 
b/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch
index a76cbbe..e64990a 100644
--- a/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch
+++ b/meta/recipes-support/attr/acl/test-fix-directory-permissions.patch
@@ -1,6 +1,9 @@
+From 311589fedf196168382d8f0db303ab328bcf9d83 Mon Sep 17 00:00:00 2001
+From: Peter Seebach 
+Date: Wed, 11 May 2016 15:16:06 -0500
+Subject: [PATCH] acl.inc, run-ptest: improve ptest functionality on limited
+
 commit c45bae84817a70fef6c2b661a07a492a0d23ae85
-Author: Peter Seebach 
-Date:   Wed May 11 15:16:06 2016 -0500
 
 Fix permissions on temporary directory
 
@@ -10,7 +13,12 @@ Date:   Wed May 11 15:16:06 2016 -0500
 
 Signed-off-by: Peter Seebach 
 
-Upstream-Status: Pending
+Upstream-Status: Backport [ 
http://git.savannah.gnu.org/cgit/acl.git/commit/?id=c6772a958800de064482634f77c20a0faafc5af6
 ]
+
+Signed-off-by: Dengke Du 
+---
+ test/root/permissions.test | 1 +
+ 1 file changed, 1 insertion(+)
 
 diff --git a/test/root/permissions.test b/test/root/permissions.test
 index 42615f5..098b52a 100644
@@ -24,3 +32,6 @@ index 42615f5..098b52a 100644
$ mkdir d
$ cd d
$ umask 027
+-- 
+2.8.1
+
-- 
2.8.1

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


[OE-core] [PATCH 1/2] at: reduce local pending patches

2017-07-18 Thread Dengke Du
Signed-off-by: Dengke Du 
---
 .../at/at/0001-remove-glibc-assumption.patch | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch 
b/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch
index 53ae28b..7fdecc7 100644
--- a/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch
+++ b/meta/recipes-extended/at/at/0001-remove-glibc-assumption.patch
@@ -1,6 +1,6 @@
-From 7f811d9c4ebc9444e613e251c31d6bf537a24dc1 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Mon, 13 Apr 2015 16:35:30 -0700
+From f446686916e503dfb9fb928252d1b72a07573b29 Mon Sep 17 00:00:00 2001
+From: Dengke Du 
+Date: Tue, 18 Jul 2017 03:42:56 -0400
 Subject: [PATCH] remove glibc assumption
 
 glibc time.h header has an undocumented __isleap macro
@@ -9,9 +9,11 @@ Since it is undocumented & does not appear
 on any other libc, stop using it and just define the macro in
 locally  instead.
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [ 
https://lists.debian.org/debian-accessibility/2017/07/msg00044.html ]
 
 Signed-off-by: Khem Raj 
+
+Signed-off-by: Dengke Du 
 ---
  parsetime.y | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)
@@ -53,5 +55,5 @@ index 7005e88..324e6d3 100644
{
yyerror("Error in day of month");
 -- 
-2.1.4
+2.8.1
 
-- 
2.8.1

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


[OE-core] [PATCH] vulkan-demos: Rename ${bindir}/screenshot

2017-07-18 Thread Jussi Kukkonen
This conflicts with sato-screenshot.

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-graphics/vulkan/vulkan-demos_git.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/vulkan/vulkan-demos_git.bb 
b/meta/recipes-graphics/vulkan/vulkan-demos_git.bb
index fcd9e7b..e088277 100644
--- a/meta/recipes-graphics/vulkan/vulkan-demos_git.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-demos_git.bb
@@ -24,6 +24,8 @@ do_install_append () {
${D}${datadir}/vulkan-demos/models/vulkanscene* \
${D}${datadir}/vulkan-demos/models/plants.dae \
${D}${datadir}/vulkan-demos/textures/texturearray_plants*
+
+mv ${D}${bindir}/screenshot ${D}${bindir}/vulkan-screenshot
 }
 
 EXTRA_OECMAKE = "-DRESOURCE_INSTALL_DIR=${datadir}/vulkan-demos"
-- 
2.1.4

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


[OE-core] [PATCH v2] screen: 4.5.1 -> 4.6.0

2017-07-18 Thread Bian Yaqin
Update screen from 4.5.1 to 4.6.0

Signed-off-by: Bian Yaqin 
---
 meta/recipes-extended/screen/{screen_4.5.1.bb => screen_4.6.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/screen/{screen_4.5.1.bb => screen_4.6.0.bb} (93%)

diff --git a/meta/recipes-extended/screen/screen_4.5.1.bb 
b/meta/recipes-extended/screen/screen_4.6.0.bb
similarity index 93%
rename from meta/recipes-extended/screen/screen_4.5.1.bb
rename to meta/recipes-extended/screen/screen_4.6.0.bb
index 32c1a5a..a41efe9 100644
--- a/meta/recipes-extended/screen/screen_4.5.1.bb
+++ b/meta/recipes-extended/screen/screen_4.6.0.bb
@@ -26,8 +26,8 @@ SRC_URI = "${GNU_MIRROR}/screen/screen-${PV}.tar.gz \
file://0001-fix-for-multijob-build.patch \
   "
 
-SRC_URI[md5sum] = "a8c5da2f42f8a18fa4dada2419d1549b"
-SRC_URI[sha256sum] = 
"97db2114dd963b016cd4ded34831955dcbe3251e5eee45ac2606e67e9f097b2d"
+SRC_URI[md5sum] = "af60f716c4ec134712b923ef6cd93848"
+SRC_URI[sha256sum] = 
"9433706b653e941cc4c745f28e252e57be2a141eded923e61cc2c4a09768fed4"
 
 inherit autotools texinfo
 
-- 
2.7.4



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


Re: [OE-core] [PATCH 1/1] expat: upgrade to 2.2.2

2017-07-18 Thread Dengke Du

Hi Ross

Do we need to add a patch to glibc to support the ubuntu 14.04 (or 
kernel version older than 3.17)?



On 2017年07月18日 14:01, Dengke Du wrote:

The expat 2.2.2:

 using getrandom syscall on linux 3.17+, so when we compiling expat-native
 on the kernel older than 3.17, that would be failed.

Signed-off-by: Dengke Du 
---
  meta/recipes-core/expat/expat_2.2.1.bb | 5 -
  meta/recipes-core/expat/expat_2.2.2.bb | 5 +
  2 files changed, 5 insertions(+), 5 deletions(-)
  delete mode 100644 meta/recipes-core/expat/expat_2.2.1.bb
  create mode 100644 meta/recipes-core/expat/expat_2.2.2.bb

diff --git a/meta/recipes-core/expat/expat_2.2.1.bb 
b/meta/recipes-core/expat/expat_2.2.1.bb
deleted file mode 100644
index 47827c5..000
--- a/meta/recipes-core/expat/expat_2.2.1.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require expat.inc
-LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79"
-
-SRC_URI[md5sum] = "d9c3baeab58774cefc2f04faf29f2cf8"
-SRC_URI[sha256sum] = 
"1868cadae4c82a018e361e2b2091de103cd820aaacb0d6cfa49bd2cd83978885"
diff --git a/meta/recipes-core/expat/expat_2.2.2.bb 
b/meta/recipes-core/expat/expat_2.2.2.bb
new file mode 100644
index 000..dfa014b
--- /dev/null
+++ b/meta/recipes-core/expat/expat_2.2.2.bb
@@ -0,0 +1,5 @@
+require expat.inc
+LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79"
+
+SRC_URI[md5sum] = "1ede9a41223c78528b8c5d23e69a2667"
+SRC_URI[sha256sum] = 
"4376911fcf81a23ebd821bbabc26fd933f3ac74833f74924342c29aad2c86046"


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


[OE-core] [morty][PATCH] glibc: Fix CVE-2015-5180

2017-07-18 Thread Yuanjie Huang
Backport upstream patch to fix NULL pointer dereference and process
crash in libresolv. (CVE-2015-5180)

Signed-off-by: Yuanjie Huang 
---
 meta/recipes-core/glibc/glibc/CVE-2015-5180.patch | 136 ++
 meta/recipes-core/glibc/glibc_2.24.bb |   1 +
 2 files changed, 137 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-5180.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-5180.patch 
b/meta/recipes-core/glibc/glibc/CVE-2015-5180.patch
new file mode 100644
index 00..638f652c4d
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2015-5180.patch
@@ -0,0 +1,136 @@
+From a8476611d5bca2032a2d18c503996762ac26a489 Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Sat, 31 Dec 2016 20:22:09 +0100
+Subject: CVE-2015-5180: resolv: Fix crash with internal QTYPE [BZ #18784]
+
+Also rename T_UNSPEC because an upcoming public header file
+update will use that name.
+
+(cherry picked from commit fc82b0a2dfe7dbd35671c10510a8da1043d746a5)
+
+Upstream-Status: Backport[master]
+CVE: CVE-2015-5180
+Signed-off-by: Yuanjie Huang 
+---
+ ChangeLog | 11 +++
+ NEWS  |  6 ++
+ include/arpa/nameser_compat.h |  6 +++---
+ resolv/nss_dns/dns-host.c |  2 +-
+ resolv/res_mkquery.c  |  4 
+ resolv/res_query.c|  6 +++---
+ 6 files changed, 28 insertions(+), 7 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 0fbda9020e..180634e658 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,14 @@
++2017-03-07  Siddhesh Poyarekar  
++
++  [BZ #18784]
++  CVE-2015-5180
++  * include/arpa/nameser_compat.h (T_QUERY_A_AND_): Rename from
++  T_UNSPEC.  Adjust value.
++  * resolv/nss_dns/dns-host.c (_nss_dns_gethostbyname4_r): Use it.
++  * resolv/res_query.c (__libc_res_nquery): Likewise.
++  * resolv/res_mkquery.c (res_nmkquery): Check for out-of-range
++  QTYPEs.
++
+ 2016-01-28  Carlos O'Donell  
+   Alexey Makhalov 
+   Florian Weimer 
+diff --git a/NEWS b/NEWS
+index b0447e7169..366f602aac 100644
+--- a/NEWS
 b/NEWS
+@@ -71,6 +71,12 @@ Security related changes:
+   and exits.  Over time, this could result in a denial of service due to
+   memory exhaustion.  Reported by Matthias Schiffer.  (CVE-2016-5417)
+ 
++* The DNS stub resolver functions would crash due to a NULL pointer
++  dereference when processing a query with a valid DNS question type which
++  was used internally in the implementation.  The stub resolver now uses a
++  question type which is outside the range of valid question type values.
++  (CVE-2015-5180)
++
+ The following bugs are resolved with this release:
+ 
+   [1170] localedata: ne_NP: update Nepali locale definition file
+diff --git a/include/arpa/nameser_compat.h b/include/arpa/nameser_compat.h
+index 2e735ede4c..7c0deed9ae 100644
+--- a/include/arpa/nameser_compat.h
 b/include/arpa/nameser_compat.h
+@@ -1,8 +1,8 @@
+ #ifndef _ARPA_NAMESER_COMPAT_
+ #include 
+ 
+-/* Picksome unused number to represent lookups of IPv4 and IPv6 (i.e.,
+-   T_A and T_).  */
+-#define T_UNSPEC 62321
++/* The number is outside the 16-bit RR type range and is used
++   internally by the implementation.  */
++#define T_QUERY_A_AND_ 439963904
+ 
+ #endif
+diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
+index 5f9e35701b..d16fa4b8ed 100644
+--- a/resolv/nss_dns/dns-host.c
 b/resolv/nss_dns/dns-host.c
+@@ -323,7 +323,7 @@ _nss_dns_gethostbyname4_r (const char *name, struct 
gaih_addrtuple **pat,
+ 
+   int olderr = errno;
+   enum nss_status status;
+-  int n = __libc_res_nsearch (&_res, name, C_IN, T_UNSPEC,
++  int n = __libc_res_nsearch (&_res, name, C_IN, T_QUERY_A_AND_,
+ host_buffer.buf->buf, 2048, _buffer.ptr,
+ , , , _malloced);
+   if (n >= 0)
+diff --git a/resolv/res_mkquery.c b/resolv/res_mkquery.c
+index 12f9730199..d80b5318e5 100644
+--- a/resolv/res_mkquery.c
 b/resolv/res_mkquery.c
+@@ -103,6 +103,10 @@ res_nmkquery(res_state statp,
+   int n;
+   u_char *dnptrs[20], **dpp, **lastdnptr;
+ 
++  if (class < 0 || class > 65535
++  || type < 0 || type > 65535)
++return -1;
++
+ #ifdef DEBUG
+   if (statp->options & RES_DEBUG)
+   printf(";; res_nmkquery(%s, %s, %s, %s)\n",
+diff --git a/resolv/res_query.c b/resolv/res_query.c
+index 944d1a90f5..07dc6f6583 100644
+--- a/resolv/res_query.c
 b/resolv/res_query.c
+@@ -122,7 +122,7 @@ __libc_res_nquery(res_state statp,
+   int n, use_malloc = 0;
+   u_int oflags = statp->_flags;
+ 
+-  size_t bufsize = (type == T_UNSPEC ? 2 : 1) * QUERYSIZE;
++  size_t bufsize = (type == T_QUERY_A_AND_ ? 2 : 1) * QUERYSIZE;
+   u_char *buf = alloca (bufsize);

[OE-core] [PATCH 0/1] expat: upgrade to 2.2.2

2017-07-18 Thread Dengke Du
The following changes since commit 81498aac9560fbeaeb58eaada32ce80e0ea51628:

  yocto-project-qs: Updated Next Steps list (2017-07-12 00:28:16 +0100)

are available in the git repository at:

  https://github.com/DengkeDu/openembedded-core.git dengke/expat-upgrade-2.2.2
  https://github.com//tree/dengke/expat-upgrade-2.2.2

Dengke Du (1):
  expat: upgrade to 2.2.2

 meta/recipes-core/expat/expat_2.2.1.bb | 5 -
 meta/recipes-core/expat/expat_2.2.2.bb | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)
 delete mode 100644 meta/recipes-core/expat/expat_2.2.1.bb
 create mode 100644 meta/recipes-core/expat/expat_2.2.2.bb

-- 
2.7.4

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


[OE-core] [PATCH 1/1] expat: upgrade to 2.2.2

2017-07-18 Thread Dengke Du
The expat 2.2.2:

using getrandom syscall on linux 3.17+, so when we compiling expat-native
on the kernel older than 3.17, that would be failed.

Signed-off-by: Dengke Du 
---
 meta/recipes-core/expat/expat_2.2.1.bb | 5 -
 meta/recipes-core/expat/expat_2.2.2.bb | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)
 delete mode 100644 meta/recipes-core/expat/expat_2.2.1.bb
 create mode 100644 meta/recipes-core/expat/expat_2.2.2.bb

diff --git a/meta/recipes-core/expat/expat_2.2.1.bb 
b/meta/recipes-core/expat/expat_2.2.1.bb
deleted file mode 100644
index 47827c5..000
--- a/meta/recipes-core/expat/expat_2.2.1.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require expat.inc
-LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79"
-
-SRC_URI[md5sum] = "d9c3baeab58774cefc2f04faf29f2cf8"
-SRC_URI[sha256sum] = 
"1868cadae4c82a018e361e2b2091de103cd820aaacb0d6cfa49bd2cd83978885"
diff --git a/meta/recipes-core/expat/expat_2.2.2.bb 
b/meta/recipes-core/expat/expat_2.2.2.bb
new file mode 100644
index 000..dfa014b
--- /dev/null
+++ b/meta/recipes-core/expat/expat_2.2.2.bb
@@ -0,0 +1,5 @@
+require expat.inc
+LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79"
+
+SRC_URI[md5sum] = "1ede9a41223c78528b8c5d23e69a2667"
+SRC_URI[sha256sum] = 
"4376911fcf81a23ebd821bbabc26fd933f3ac74833f74924342c29aad2c86046"
-- 
2.7.4

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