Re: [OE-core] Enabling uninative by default in oe-core?

[Koen Kooi]

> Op 17 nov. 2016, om 18:31 heeft Burton, Ross  het 
> volgende geschreven:
> 
> Hi,
> 
> Background: uninative is a class that downloads a precompiled host glibc 

Why can’t OE build it on-demand? What’s next, requiring prebuilt toolchains?

regards,

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

Re: [OE-core] Modifying SRC_URI from anonymous python

[Andre McCurdy]

On Thu, Nov 17, 2016 at 2:00 PM, Christopher Larson  wrote:
>
> On Thu, Nov 17, 2016 at 2:28 PM, Andre McCurdy  wrote:
>>
>> I have a supplier who provides recipes which set SRC_URI to their
>> private git servers. To make those same recipes usable by others (ie
>> me), some anonymous python is used to transform the default SRC_URI
>> (elements which contain private git URLs are replaced, patches and
>> other files are left as-is).
>>
>> This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
>> python which modifies SRC_URI races with the anonymous python in
>> base.bbclass which parses SRC_URI to determine additional
>> do_fetch/do_unpack dependencies and whether or not to call
>> fetch2.get_srcrev(). Specifically I get failures because
>> fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
>> AUTOREV from a repo to which I don't have access.
>
> You might want to try using a RecipePreFinalise event handler instead, they
> run before anonymous python functions do.

Thanks, that works.

(For the benefit of anyone else who may try copying and pasting the
example from the bitbake user manual, the correct eventmask is
"bb.event.RecipePreFinalise" rather than
"bb.build.RecipePreFinalise").

> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 00/13] Pull request jethro-next

[Armin Kuster]

Please consider these for jethro-next

The following changes since commit 820b835e3cbfefb1ed11faca95a67ef6f5475fb1:

  dev-manual: Fixed typo for "${INC_PR}.0" (2016-11-16 10:38:29 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib akuster/jethro-next
  http://git.yoctoproject.org/cgit.cgi//log/?h=akuster/jethro-next

Armin Kuster (13):
  gnutils: Security fix CVE-2016-7444
  bind: Security fix CVE-2016-2775
  bind: Security fix CVE-2016-2776
  openssl: Security fix CVE-2016-2179
  openssl: Security fix CVE-2016-8610
  python-2.7: Security fix CVE-2016-0772
  python-2.7: Security fix CVE-2016-5636
  python-2.7: Security fix CVE-2016-5699
  python-2.7: Security fix CVE-2016-1000110
  tzcode-native: update to 2016h
  tzdata: Update to 2016h
  tzcode: update to 2016i
  tzdata: update to 2016i

 .../bind/bind/CVE-2016-2775.patch  |  84 +++
 .../bind/bind/CVE-2016-2776.patch  | 112 +
 meta/recipes-connectivity/bind/bind_9.10.2-P4.bb   |   2 +
 .../openssl/openssl/CVE-2016-2179.patch| 255 +
 .../openssl/openssl/CVE-2016-8610.patch| 124 ++
 .../recipes-connectivity/openssl/openssl_1.0.2h.bb |   2 +
 .../python/python/CVE-2016-0772.patch  |  42 
 .../python/python/CVE-2016-1000110.patch   | 145 
 .../python/python/CVE-2016-5636.patch  |  42 
 .../python/python/CVE-2016-5699.patch  | 162 +
 meta/recipes-devtools/python/python_2.7.9.bb   |   4 +
 ...code-native_2016g.bb => tzcode-native_2016i.bb} |   8 +-
 .../tzdata/{tzdata_2016g.bb => tzdata_2016i.bb}|   4 +-
 .../gnutls/gnutls/CVE-2016-7444.patch  |  31 +++
 meta/recipes-support/gnutls/gnutls_3.3.17.1.bb |   1 +
 15 files changed, 1012 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-2775.patch
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-2776.patch
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2016-2179.patch
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2016-8610.patch
 create mode 100644 meta/recipes-devtools/python/python/CVE-2016-0772.patch
 create mode 100644 meta/recipes-devtools/python/python/CVE-2016-1000110.patch
 create mode 100644 meta/recipes-devtools/python/python/CVE-2016-5636.patch
 create mode 100644 meta/recipes-devtools/python/python/CVE-2016-5699.patch
 rename meta/recipes-extended/tzcode/{tzcode-native_2016g.bb => 
tzcode-native_2016i.bb} (68%)
 rename meta/recipes-extended/tzdata/{tzdata_2016g.bb => tzdata_2016i.bb} (98%)
 create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2016-7444.patch

-- 
2.3.5

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

Re: [OE-core] Modifying SRC_URI from anonymous python

[Christopher Larson]

On Thu, Nov 17, 2016 at 4:06 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Thu, 2016-11-17 at 13:28 -0800, Andre McCurdy wrote:
> > I have a supplier who provides recipes which set SRC_URI to their
> > private git servers. To make those same recipes usable by others (ie
> > me), some anonymous python is used to transform the default SRC_URI
> > (elements which contain private git URLs are replaced, patches and
> > other files are left as-is).
> >
> > This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
> > python which modifies SRC_URI races with the anonymous python in
> > base.bbclass which parses SRC_URI to determine additional
> > do_fetch/do_unpack dependencies and whether or not to call
> > fetch2.get_srcrev().
>
> I suspect we made some changes around that time to ensure determinism
> in the order certain things happened.
>
> >  Specifically I get failures because
> > fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
> > AUTOREV from a repo to which I don't have access.
> >
> > The proposed solution from the supplier is this patch to
> > base.bbclass:
> >
> > @@ -598,7 +598,7 @@ python () {
> >  d.appendVarFlag('do_unpack', 'depends', '
> > file-native:do_populate_sysroot')
> >
> >  if needsrcrev:
> > -d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> > +d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}",
> > parsing=True)
> >
> >  set_packagetriplet(d)
>
>
> parsing=True is a bitbake internal thing, its not documented and
> shouldn't be used outside the bitbake codebase. In hindsight, naming
> could have been better.
>
> > After reading the setVar source I'm not very clear how or why this
> > works, but it looks dubious. What is parsing=True intended to do?
>
> Its internal bitbake data store stuff, don't use or rely on it. It
> might happen to work here but its just luck.
>
> > Is it documented somewhere that modifying SRC_URI from anonymous
> > python isn't allowed? I've now seen two suppliers both independently
> > run into the same problem when updating to OE 2.1.
>
> We have an open bug related to anonymous python ordering. Its hard to
> fix easily as something can indicate it wants to run last, but then
> everything wants to run last. As Chris mentions, you can use an earlier
> event handler as one way to work around it.


I think our best bet there is to move toward more explicit event handler
naming and dependency handling amongst event handlers.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Enabling uninative by default in oe-core?

[Khem Raj]

On 11/17/16 10:56 AM, Nicolas Dechesne wrote:
> On Thu, Nov 17, 2016 at 7:06 PM, Khem Raj  wrote:
>>> Background: uninative is a class that downloads a precompiled host glibc for
>>> use in the sysroot, thus isolating the native sysroot from the host
>>> environment.  This means greater sstate reuse, as instead of native builds
>>> being dependent on the host system they're able to be shared between all
>>> hosts.  There is a reference tarball hosted on www.yoctoproject.org
>>> , and the URL can be overridden by distros if 
>>> you
>>> would prefer to build your own.
>>>
>>> We enable this in Poky so that we get greater reuse on the autobuilders, and
>>> due to some issues with the C++ ABI the eSDK generation in master now 
>>> requires
>>> uninative to be enabled.  The question is: do we now enable uninative by
>>> default in oe-core's nodistro (pointing at the yoctoproject tarball), or do 
>>> we
>>> keep it disabled by default and require the user to enable uninative if they
>>> wish to build an eSDK?
>>>
>>> Personally I'm torn: I don't like eSDK not working out of the box, but I 
>>> don't
>>> really like oe-core nodistro depending on uninative.  Though enabling
>>> uninative globally does mean everything works out of the box, so following 
>>> the
>>> principle of Least Surprise that's what we should do.
>>
>> If we are supporing e-SDK in OE-Core then we should enable uninative too
>> on the same lines.
>>
>> It does improve the user experience so I am in favor of adding it
>> unconditionally. May be tarball can be hosted on oe mirrors as well for
>> redundancy
> 
> 
> I am not sure how people would care about that (yet ;-) but uninative
> does not work for arm64 (host).
> 
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "aarch64-linux"
> NATIVELSBSTRING   = "Debian-8.6"
> TARGET_SYS= "arm-oe-linux-gnueabi"
> MACHINE   = "qemuarm"
> DISTRO= "nodistro"
> DISTRO_VERSION= "nodistro.0"
> TUNE_FEATURES = "arm armv5 thumb dsp"
> TARGET_FPU= "soft"
> meta  = "master:9303d8055c45a0f6af295d70a6f6a8b9d8d8a7c9"
> 
> ERROR: Uninative selected but not configured correctly, please set
> UNINATIVE_CHECKSUM[aarch64]
> 
> I don't know much about it, but it would be nice to fix that before we
> enable it by default. I will try to have a look at it more closely..
> 

Someone with aarch64 hardware in build boxes could take that up. I dont think
yocto project or many community members have access to hardware. I would be
happy if it informed me and continues without uninative.



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

Re: [OE-core] [Openembedded-architecture] Enabling uninative by default in oe-core?

[Khem Raj]

On 11/17/16 10:50 AM, Denys Dmytriyenko wrote:
> On Thu, Nov 17, 2016 at 10:06:46AM -0800, Khem Raj wrote:
>>
>>
>> On 11/17/16 9:31 AM, Burton, Ross wrote:
>>> Hi,
>>>
>>> Background: uninative is a class that downloads a precompiled host glibc for
>>> use in the sysroot, thus isolating the native sysroot from the host
>>> environment.  This means greater sstate reuse, as instead of native builds
>>> being dependent on the host system they're able to be shared between all
>>> hosts.  There is a reference tarball hosted on www.yoctoproject.org
>>> , and the URL can be overridden by distros if 
>>> you
>>> would prefer to build your own.
>>>
>>> We enable this in Poky so that we get greater reuse on the autobuilders, and
>>> due to some issues with the C++ ABI the eSDK generation in master now 
>>> requires
>>> uninative to be enabled.  The question is: do we now enable uninative by
>>> default in oe-core's nodistro (pointing at the yoctoproject tarball), or do 
>>> we
>>> keep it disabled by default and require the user to enable uninative if they
>>> wish to build an eSDK?
>>>
>>> Personally I'm torn: I don't like eSDK not working out of the box, but I 
>>> don't
>>> really like oe-core nodistro depending on uninative.  Though enabling
>>> uninative globally does mean everything works out of the box, so following 
>>> the
>>> principle of Least Surprise that's what we should do.
>>
>> If we are supporing e-SDK in OE-Core then we should enable uninative too
>> on the same lines.
>>
>> It does improve the user experience so I am in favor of adding it
>> unconditionally. May be tarball can be hosted on oe mirrors as well for
>> redundancy
> 
> I still believe this new feature is moving to become mandatory a bit too 
> soon...

perhaps keeping it optional for 1 release would be acceptable ? it also means
that we may not be able to develop core features using this and it would also
mean more testing matrix, which I believe is fine. Since we know non uninative
version wont get as much coverage.

> 



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

Re: [OE-core] Modifying SRC_URI from anonymous python

[Richard Purdie]

On Thu, 2016-11-17 at 13:28 -0800, Andre McCurdy wrote:
> I have a supplier who provides recipes which set SRC_URI to their
> private git servers. To make those same recipes usable by others (ie
> me), some anonymous python is used to transform the default SRC_URI
> (elements which contain private git URLs are replaced, patches and
> other files are left as-is).
> 
> This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
> python which modifies SRC_URI races with the anonymous python in
> base.bbclass which parses SRC_URI to determine additional
> do_fetch/do_unpack dependencies and whether or not to call
> fetch2.get_srcrev().

I suspect we made some changes around that time to ensure determinism
in the order certain things happened.

>  Specifically I get failures because
> fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
> AUTOREV from a repo to which I don't have access.
> 
> The proposed solution from the supplier is this patch to
> base.bbclass:
> 
> @@ -598,7 +598,7 @@ python () {
>  d.appendVarFlag('do_unpack', 'depends', '
> file-native:do_populate_sysroot')
> 
>  if needsrcrev:
> -d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> +d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}",
> parsing=True)
> 
>  set_packagetriplet(d)


parsing=True is a bitbake internal thing, its not documented and
shouldn't be used outside the bitbake codebase. In hindsight, naming
could have been better.

> After reading the setVar source I'm not very clear how or why this
> works, but it looks dubious. What is parsing=True intended to do?

Its internal bitbake data store stuff, don't use or rely on it. It
might happen to work here but its just luck.

> Is it documented somewhere that modifying SRC_URI from anonymous
> python isn't allowed? I've now seen two suppliers both independently
> run into the same problem when updating to OE 2.1.

We have an open bug related to anonymous python ordering. Its hard to
fix easily as something can indicate it wants to run last, but then
everything wants to run last. As Chris mentions, you can use an earlier
event handler as one way to work around it.

I'd also note that anonymous python runs in parsed order. Since
base.bbclass is "up front", its hard to run things before it though :/.

Cheers,

Richard


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

Re: [OE-core] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Martin Jansa]

On Thu, Nov 17, 2016 at 01:26:34PM -0200, Fabio Berton wrote:
> Add patches to fix error:
> /
> | ERROR: oe_runmake failed
> | config.status: creating pcap-config.tmp
> | mv pcap-config.tmp pcap-config
> | chmod a+x pcap-config
> | ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
> | ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
> | {aka struct _compiler_state}' has no member named 'ai'
> |   cstate.ai = NULL;
> | ^
> | ../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
> | ../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
> | (first use in this function)
> |bpf_error(cstate, "direction applied to 'gateway'");
> |  ^~
> | ../libpcap-1.8.1/gencode.c:4914:13: note: each undeclared identifier is
> | reported only once for each function it appears in
> \

Thanks!

> 
> Patches were submitted to upstream [1]
> 
> [1] https://github.com/the-tcpdump-group/libpcap/pull/541
> 
> Signed-off-by: Fabio Berton 
> ---
>  ...r_state_t.ai-usage-when-INET6-is-not-defi.patch | 41 +
>  ...02-Add-missing-compiler_state_t-parameter.patch | 67 
> ++
>  meta/recipes-connectivity/libpcap/libpcap_1.8.1.bb |  2 +
>  3 files changed, 110 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
>  create mode 100644 
> meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
> 
> diff --git 
> a/meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
>  
> b/meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
> new file mode 100644
> index 000..edb6ae5
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
> @@ -0,0 +1,41 @@
> +From 64aa033a061c43fc15c711f2490ae41d23b868c3 Mon Sep 17 00:00:00 2001
> +From: Fabio Berton 
> +Date: Thu, 17 Nov 2016 09:44:42 -0200
> +Subject: [PATCH 1/2] Fix compiler_state_t.ai usage when INET6 is not defined
> +Organization: O.S. Systems Software LTDA.
> +
> +Fix error:
> +
> +/
> +| ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
> +| ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
> +| {aka struct _compiler_state}' has no member named 'ai'
> +|   cstate.ai = NULL;
> +\
> +
> +Upstream-Status: Submitted [1]
> +
> +[1] https://github.com/the-tcpdump-group/libpcap/pull/541
> +
> +Signed-off-by: Fabio Berton 
> +---
> + gencode.c | 2 ++
> + 1 file changed, 2 insertions(+)
> +
> +diff --git a/gencode.c b/gencode.c
> +index a887f27..e103c70 100644
> +--- a/gencode.c
>  b/gencode.c
> +@@ -690,7 +690,9 @@ pcap_compile(pcap_t *p, struct bpf_program *program,
> + }
> + initchunks();
> + cstate.no_optimize = 0;
> ++#ifdef INET6
> + cstate.ai = NULL;
> ++#endif
> + cstate.ic.root = NULL;
> + cstate.ic.cur_mark = 0;
> + cstate.bpf_pcap = p;
> +-- 
> +2.1.4
> +
> diff --git 
> a/meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
>  
> b/meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
> new file mode 100644
> index 000..032b265
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
> @@ -0,0 +1,67 @@
> +From 50ec0a088d5924a8305b2d70dcba71b0942dee1a Mon Sep 17 00:00:00 2001
> +From: Fabio Berton 
> +Date: Thu, 17 Nov 2016 09:47:29 -0200
> +Subject: [PATCH 2/2] Add missing compiler_state_t parameter
> +Organization: O.S. Systems Software LTDA.
> +
> +Fix error:
> +
> +/
> +|../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
> +|../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
> +| (first use in this function)
> +|bpf_error(cstate, "direction applied to 'gateway'");
> +\
> +
> +Upstream-Status: Submitted [1]
> +
> +[1] https://github.com/the-tcpdump-group/libpcap/pull/541
> +
> +Signed-off-by: Fabio Berton 
> +---
> + gencode.c | 15 ---
> + 1 file changed, 8 insertions(+), 7 deletions(-)
> +
> +diff --git a/gencode.c b/gencode.c
> +index e103c70..f07c0be 100644
> +--- a/gencode.c
>  b/gencode.c
> +@@ -523,7 +523,7 @@ static struct block *gen_host6(compiler_state_t *, 
> struct in6_addr *,
> + struct in6_addr *, int, int, int);
> + #endif
> + #ifndef INET6
> +-static struct block *gen_gateway(const u_char *, bpf_u_int32 **, int, int);
> ++static struct block *gen_gateway(compiler_state_t *, const u_char *, 
> bpf_u_int32 **, int, int);
> + #endif
> + static struct block *gen_ipfrag(compiler_state_t *);
> + static struct block *gen_portatom(compiler_state_t *, int, bpf_int32);
> +@@ -4904,11 +4904,12 @@ 

[OE-core] [PATCH V2] python3-setuptools: upgrade to 28.8.0

[Edwin Plauchu]

It is a simultaneous upgrade for python 2 and 3 over setuptools.

Signed-off-by: Edwin Plauchu 
---
 meta/recipes-devtools/python/python-setuptools.inc  | 6 +++---
 .../{python-setuptools_22.0.5.bb => python-setuptools_28.8.0.bb}| 0
 .../{python3-setuptools_22.0.5.bb => python3-setuptools_28.8.0.bb}  | 0
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/python/{python-setuptools_22.0.5.bb => 
python-setuptools_28.8.0.bb} (100%)
 rename meta/recipes-devtools/python/{python3-setuptools_22.0.5.bb => 
python3-setuptools_28.8.0.bb} (100%)

diff --git a/meta/recipes-devtools/python/python-setuptools.inc 
b/meta/recipes-devtools/python/python-setuptools.inc
index 92ca9a0..d3eef13 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -3,14 +3,14 @@ HOMEPAGE = "https://pypi.python.org/pypi/setuptools;
 SECTION = "devel/python"
 LICENSE = "MIT"
 
-LIC_FILES_CHKSUM = 
"file://setup.py;beginline=134;endline=134;md5=3e8df024d6c1442d18e84acf8fbbc475"
+LIC_FILES_CHKSUM = 
"file://setup.py;beginline=146;endline=146;md5=3e8df024d6c1442d18e84acf8fbbc475"
 
 SRCNAME = "setuptools"
 
 SRC_URI = 
"https://files.pythonhosted.org/packages/source/s/${SRCNAME}/${SRCNAME}-${PV}.tar.gz;
 
-SRC_URI[md5sum] = "869f3029dcc66a64ba39875e2a2f044a"
-SRC_URI[sha256sum] = 
"19aad19471052d5daefe96f2c1fa2e88dcdb17488bf8708d7e6356881ea833cb"
+SRC_URI[md5sum] = "43d6eb25f60e8a2682a8f826ce9e3f42"
+SRC_URI[sha256sum] = 
"432a1ad4044338c34c2d09b0ff75d509b9849df8cf329f4c1c7706d9c2ba3c61"
 
 UPSTREAM_CHECK_URI = "https://pypi.python.org/pypi/setuptools;
 
diff --git a/meta/recipes-devtools/python/python-setuptools_22.0.5.bb 
b/meta/recipes-devtools/python/python-setuptools_28.8.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python-setuptools_22.0.5.bb
rename to meta/recipes-devtools/python/python-setuptools_28.8.0.bb
diff --git a/meta/recipes-devtools/python/python3-setuptools_22.0.5.bb 
b/meta/recipes-devtools/python/python3-setuptools_28.8.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-setuptools_22.0.5.bb
rename to meta/recipes-devtools/python/python3-setuptools_28.8.0.bb
-- 
2.9.3

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

Re: [OE-core] [PATCH] apt-package: Include maintenance scripts

[Aníbal Limón]

Hi Linus,

Your patch looks good, only missing one thing you need to conditional
those lines to only work when systemd is enabled in DISTRO_FEATURES, see
example:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/consolekit/consolekit_0.4.6.bb#n26

Thanks in advance,
alimon


On 11/16/2016 10:33 AM, Linus Wallgren wrote:
> Apt can run multiple tasks daily, such as for example clean, update,
> autoclean, unattended-upgrades etc.
> 
> [YOCTO #10669]
> 
> Signed-off-by: Linus Wallgren 
> ---
>  meta/recipes-devtools/apt/apt-package.inc | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/apt/apt-package.inc 
> b/meta/recipes-devtools/apt/apt-package.inc
> index a553aa2..38cd558 100644
> --- a/meta/recipes-devtools/apt/apt-package.inc
> +++ b/meta/recipes-devtools/apt/apt-package.inc
> @@ -32,13 +32,19 @@ FILES_${PN} = "${bindir}/apt-cdrom ${bindir}/apt-get \
>  ${bindir}/apt-config ${bindir}/apt-cache \
>  ${libdir}/apt ${libdir}/libapt*.so.* \
>  ${localstatedir} ${sysconfdir} \
> -${libdir}/dpkg"
> +${libdir}/dpkg \
> +${systemd_unitdir}/system \
> +   "
>  FILES_${PN}-utils = "${bindir}/apt-sortpkgs ${bindir}/apt-extracttemplates"
>  FILES_${PN}-doc = "${@get_files_apt_doc(d, bb, d.getVar('apt-manpages', 
> True))} \
>  ${docdir}/apt"
>  FILES_${PN}-utils-doc = "${@get_files_apt_doc(d, bb, 
> d.getVar('apt-utils-manpages', True))}"
>  FILES_${PN}-dev = "${libdir}/libapt*.so ${includedir}"
>  
> +inherit systemd
> +
> +SYSTEMD_SERVICE_${PN} = "apt-daily.timer"
> +
>  do_install () {
>   set -x
>   install -d ${D}${bindir}
> @@ -75,4 +81,11 @@ do_install () {
>  
>   install -d ${D}${includedir}/apt-pkg/
>   install -m 0644 include/apt-pkg/*.h ${D}${includedir}/apt-pkg/
> +
> +install -d ${D}${systemd_unitdir}/system/
> +install -m 0644 ${S}/debian/apt.systemd.daily ${D}/usr/lib/apt/
> +install -m 0644 ${S}/debian/apt-daily.service 
> ${D}${systemd_unitdir}/system/
> +install -m 0644 ${S}/debian/apt-daily.timer 
> ${D}${systemd_unitdir}/system/
> +install -d ${D}${sysconfdir}/cron.daily/
> +install -m 0755 ${S}/debian/apt.apt-compat.cron.daily 
> ${D}${sysconfdir}/cron.daily/
>  }
> 



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

Re: [OE-core] Modifying SRC_URI from anonymous python

[Christopher Larson]

On Thu, Nov 17, 2016 at 2:28 PM, Andre McCurdy  wrote:

> I have a supplier who provides recipes which set SRC_URI to their
> private git servers. To make those same recipes usable by others (ie
> me), some anonymous python is used to transform the default SRC_URI
> (elements which contain private git URLs are replaced, patches and
> other files are left as-is).
>
> This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
> python which modifies SRC_URI races with the anonymous python in
> base.bbclass which parses SRC_URI to determine additional
> do_fetch/do_unpack dependencies and whether or not to call
> fetch2.get_srcrev(). Specifically I get failures because
> fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
> AUTOREV from a repo to which I don't have access.
>

You might want to try using a RecipePreFinalise event handler instead, they
run before anonymous python functions do.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Enabling uninative by default in oe-core?

[Mark Hatle]

On 11/17/16 12:31 PM, Burton, Ross wrote:
> Hi,
> 
> Background: uninative is a class that downloads a precompiled host glibc for 
> use
> in the sysroot, thus isolating the native sysroot from the host environment. 
> This means greater sstate reuse, as instead of native builds being dependent 
> on
> the host system they're able to be shared between all hosts.  There is a
> reference tarball hosted on www.yoctoproject.org 
> ,
> and the URL can be overridden by distros if you would prefer to build your 
> own.
> 
> We enable this in Poky so that we get greater reuse on the autobuilders, and 
> due
> to some issues with the C++ ABI the eSDK generation in master now requires
> uninative to be enabled.  The question is: do we now enable uninative by 
> default
> in oe-core's nodistro (pointing at the yoctoproject tarball), or do we keep it
> disabled by default and require the user to enable uninative if they wish to
> build an eSDK?
> 
> Personally I'm torn: I don't like eSDK not working out of the box, but I don't
> really like oe-core nodistro depending on uninative.  Though enabling 
> uninative
> globally does mean everything works out of the box, so following the principle
> of Least Surprise that's what we should do.

I agree, I see both sides.

I'm tempted though to say, at a minimum it would be nice if oe-core had a
working (prebuilt) uninative -- or at least instructions for someone to build it
themselves.  Also corresponding instructions for the eSDK that says, BTW you
need this and this is how to do it.

That would let people use the uninative with oe-core... and maybe? let us vet
this so we can determine if it's the right thing to do by default in the future
or not.

(With that said, the stuff I'm working on is using the uninative -- and it's
solved a number of minor issues..)

--Mark

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

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

[OE-core] Modifying SRC_URI from anonymous python

[Andre McCurdy]

I have a supplier who provides recipes which set SRC_URI to their
private git servers. To make those same recipes usable by others (ie
me), some anonymous python is used to transform the default SRC_URI
(elements which contain private git URLs are replaced, patches and
other files are left as-is).

This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
python which modifies SRC_URI races with the anonymous python in
base.bbclass which parses SRC_URI to determine additional
do_fetch/do_unpack dependencies and whether or not to call
fetch2.get_srcrev(). Specifically I get failures because
fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
AUTOREV from a repo to which I don't have access.

The proposed solution from the supplier is this patch to base.bbclass:

@@ -598,7 +598,7 @@ python () {
 d.appendVarFlag('do_unpack', 'depends', '
file-native:do_populate_sysroot')

 if needsrcrev:
-d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
+d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}", parsing=True)

 set_packagetriplet(d)

After reading the setVar source I'm not very clear how or why this
works, but it looks dubious. What is parsing=True intended to do?

Is it documented somewhere that modifying SRC_URI from anonymous
python isn't allowed? I've now seen two suppliers both independently
run into the same problem when updating to OE 2.1.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] busybox: enable fractional sleep arguments

[Nathan Lynch]

Fractional durations (e.g. 0.5s) for the sleep command are useful and
not terribly uncommon in practice, especially in scripts associated
with test cases (e.g. mdadm, lttng-tools).  Enable FEATURE_FLOAT_SLEEP
by default in order to avoid having to patch every instance of a
script using a fractional sleep.

The busybox binary gains a few hundred bytes in text (armv5e shown):

$ size -x busybox.nosuid.{before,after}
   textdata bss dec hex filename
0x89382   0x71d  0x2250  572655   8bcef busybox.nosuid.before
0x8954e   0x721  0x2250  573119   8bebf busybox.nosuid.after

Signed-off-by: Nathan Lynch 
---
 meta/recipes-core/busybox/busybox/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox/defconfig 
b/meta/recipes-core/busybox/busybox/defconfig
index c0459d59612b..cbdb1391fd33 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -279,7 +279,7 @@ CONFIG_SEQ=y
 # CONFIG_SHA3SUM is not set
 CONFIG_SLEEP=y
 CONFIG_FEATURE_FANCY_SLEEP=y
-# CONFIG_FEATURE_FLOAT_SLEEP is not set
+CONFIG_FEATURE_FLOAT_SLEEP=y
 CONFIG_SORT=y
 CONFIG_FEATURE_SORT_BIG=y
 # CONFIG_SPLIT is not set
-- 
2.7.4

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

Re: [OE-core] Enabling uninative by default in oe-core?

[Nicolas Dechesne]

On Thu, Nov 17, 2016 at 7:06 PM, Khem Raj  wrote:
>> Background: uninative is a class that downloads a precompiled host glibc for
>> use in the sysroot, thus isolating the native sysroot from the host
>> environment.  This means greater sstate reuse, as instead of native builds
>> being dependent on the host system they're able to be shared between all
>> hosts.  There is a reference tarball hosted on www.yoctoproject.org
>> , and the URL can be overridden by distros if 
>> you
>> would prefer to build your own.
>>
>> We enable this in Poky so that we get greater reuse on the autobuilders, and
>> due to some issues with the C++ ABI the eSDK generation in master now 
>> requires
>> uninative to be enabled.  The question is: do we now enable uninative by
>> default in oe-core's nodistro (pointing at the yoctoproject tarball), or do 
>> we
>> keep it disabled by default and require the user to enable uninative if they
>> wish to build an eSDK?
>>
>> Personally I'm torn: I don't like eSDK not working out of the box, but I 
>> don't
>> really like oe-core nodistro depending on uninative.  Though enabling
>> uninative globally does mean everything works out of the box, so following 
>> the
>> principle of Least Surprise that's what we should do.
>
> If we are supporing e-SDK in OE-Core then we should enable uninative too
> on the same lines.
>
> It does improve the user experience so I am in favor of adding it
> unconditionally. May be tarball can be hosted on oe mirrors as well for
> redundancy


I am not sure how people would care about that (yet ;-) but uninative
does not work for arm64 (host).

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "aarch64-linux"
NATIVELSBSTRING   = "Debian-8.6"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE   = "qemuarm"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "arm armv5 thumb dsp"
TARGET_FPU= "soft"
meta  = "master:9303d8055c45a0f6af295d70a6f6a8b9d8d8a7c9"

ERROR: Uninative selected but not configured correctly, please set
UNINATIVE_CHECKSUM[aarch64]

I don't know much about it, but it would be nice to fix that before we
enable it by default. I will try to have a look at it more closely..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/3] module.bbclass: use Module.symvers for dependants

[Denys Dmytriyenko]

On Thu, Nov 17, 2016 at 10:22:18AM +, André Draszik wrote:
> Hi,
> 
> On Wed, 2016-11-16 at 15:18 -0500, Denys Dmytriyenko wrote:
> > On Thu, Aug 18, 2016 at 08:56:24AM +0100, André Draszik wrote:
> > >  
> > > @@ -24,6 +34,11 @@ module_do_install() {
> > >      CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> > >      O=${STAGING_KERNEL_BUILDDIR} \
> > >      ${MODULES_INSTALL_TARGET}
> > > +
> > > + install -d -m0755 ${D}${includedir}/${BPN}
> > > + cp -a --no-preserve=ownership ${B}/Module.symvers
> > > ${D}${includedir}/${BPN}
> > 
> > Hmm, why is Module.symvers expected to be in the root of ${B}? This seems
> > like 
> > a very artificial assumption/requirement!
> 
> [...]
> 
> > I wonder if this should have been rolled into ${MODULES_INSTALL_TARGET} 
> > step...
> 
> What about adding a (lazy ?=) variable to be able to override the location
> of Module.symvers within ${B}, or alternatively using find to automatically
> detect it? I guess there could also be more than one in theory? Do you have
> something different in mind?

Yes, find will probably be too ambiguous, but I like the variable idea to 
point to Module.symvers within ${B}!

For now I have a workaround to do an extra copy in do_install_prepend(), which 
is not very elegant...

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

Re: [OE-core] [Openembedded-architecture] Enabling uninative by default in oe-core?

[Denys Dmytriyenko]

On Thu, Nov 17, 2016 at 10:06:46AM -0800, Khem Raj wrote:
> 
> 
> On 11/17/16 9:31 AM, Burton, Ross wrote:
> > Hi,
> > 
> > Background: uninative is a class that downloads a precompiled host glibc for
> > use in the sysroot, thus isolating the native sysroot from the host
> > environment.  This means greater sstate reuse, as instead of native builds
> > being dependent on the host system they're able to be shared between all
> > hosts.  There is a reference tarball hosted on www.yoctoproject.org
> > , and the URL can be overridden by distros if 
> > you
> > would prefer to build your own.
> > 
> > We enable this in Poky so that we get greater reuse on the autobuilders, and
> > due to some issues with the C++ ABI the eSDK generation in master now 
> > requires
> > uninative to be enabled.  The question is: do we now enable uninative by
> > default in oe-core's nodistro (pointing at the yoctoproject tarball), or do 
> > we
> > keep it disabled by default and require the user to enable uninative if they
> > wish to build an eSDK?
> > 
> > Personally I'm torn: I don't like eSDK not working out of the box, but I 
> > don't
> > really like oe-core nodistro depending on uninative.  Though enabling
> > uninative globally does mean everything works out of the box, so following 
> > the
> > principle of Least Surprise that's what we should do.
> 
> If we are supporing e-SDK in OE-Core then we should enable uninative too
> on the same lines.
> 
> It does improve the user experience so I am in favor of adding it
> unconditionally. May be tarball can be hosted on oe mirrors as well for
> redundancy

I still believe this new feature is moving to become mandatory a bit too 
soon...

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

Re: [OE-core] [PATCH] Test needed to verify postinst script order.

[Pedraza Gonzalez, Francisco J]

Hi,
Sure I can send a patch with the updates.
Ross: Could you please give more details about PACKAGE_CLASSES?, I am not very 
familiar with.
Regards,
Paco

From: Jose Perez Carranza [jose.perez.carra...@linux.intel.com]
Sent: Thursday, November 17, 2016 7:33 AM
To: Burton, Ross; Pedraza Gonzalez, Francisco J
Cc: OE-core
Subject: Re: [OE-core] [PATCH] Test needed to verify postinst script order.

On 11/17/2016 06:14 AM, Burton, Ross wrote:

On 16 November 2016 at 00:50, Francisco Pedraza 
>
 wrote:
Will verify the following:
1. Compile a minimal image.
2. The compiled image will add the created layer with the
recipes postinstz postinsta postinstb postinstd postinstp postinstt
created previously at "meta-selftest/recipes-test"
2. Run qemu
3. Validate the task execution order.
V4

This is missing the test that some postinsts should be happening at rootfs time.
I have assigned the bug 8433 and I will send a different patch to add those 
test cases, I'm just waiting to the final implementation of this  patch to be 
accepted to avoid execution and merge conflicts.

Also, can it permute PACKAGE_CLASSES (rotate through all three options) so it 
exercises all backends.

Signed-off-by: Francisco Pedraza 
>
---
 .../recipes-test/postinsta/postinsta_1.0.bb| 
20 +++
 .../recipes-test/postinstb/postinstb_1.0.bb| 
22 
 .../recipes-test/postinstd/postinstd_1.0.bb| 
22 
 .../recipes-test/postinstp/postinstp_1.0.bb| 
22 
 .../recipes-test/postinstt/postinstt_1.0.bb| 
22 
 .../recipes-test/postinstz/postinstz_1.0.bb| 
12 +++

For clarity can all of these be squashed into a single recipe with clearer 
names?

Ross



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

Re: [OE-core] Enabling uninative by default in oe-core?

[Khem Raj]

On 11/17/16 9:31 AM, Burton, Ross wrote:
> Hi,
> 
> Background: uninative is a class that downloads a precompiled host glibc for
> use in the sysroot, thus isolating the native sysroot from the host
> environment.  This means greater sstate reuse, as instead of native builds
> being dependent on the host system they're able to be shared between all
> hosts.  There is a reference tarball hosted on www.yoctoproject.org
> , and the URL can be overridden by distros if you
> would prefer to build your own.
> 
> We enable this in Poky so that we get greater reuse on the autobuilders, and
> due to some issues with the C++ ABI the eSDK generation in master now requires
> uninative to be enabled.  The question is: do we now enable uninative by
> default in oe-core's nodistro (pointing at the yoctoproject tarball), or do we
> keep it disabled by default and require the user to enable uninative if they
> wish to build an eSDK?
> 
> Personally I'm torn: I don't like eSDK not working out of the box, but I don't
> really like oe-core nodistro depending on uninative.  Though enabling
> uninative globally does mean everything works out of the box, so following the
> principle of Least Surprise that's what we should do.

If we are supporing e-SDK in OE-Core then we should enable uninative too
on the same lines.

It does improve the user experience so I am in favor of adding it
unconditionally. May be tarball can be hosted on oe mirrors as well for
redundancy

> 
> Ross
> 
> 



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

[OE-core] Enabling uninative by default in oe-core?

[Burton, Ross]

Hi,

Background: uninative is a class that downloads a precompiled host glibc
for use in the sysroot, thus isolating the native sysroot from the host
environment.  This means greater sstate reuse, as instead of native builds
being dependent on the host system they're able to be shared between all
hosts.  There is a reference tarball hosted on www.yoctoproject.org, and
the URL can be overridden by distros if you would prefer to build your own.

We enable this in Poky so that we get greater reuse on the autobuilders,
and due to some issues with the C++ ABI the eSDK generation in master now
requires uninative to be enabled.  The question is: do we now enable
uninative by default in oe-core's nodistro (pointing at the yoctoproject
tarball), or do we keep it disabled by default and require the user to
enable uninative if they wish to build an eSDK?

Personally I'm torn: I don't like eSDK not working out of the box, but I
don't really like oe-core nodistro depending on uninative.  Though enabling
uninative globally does mean everything works out of the box, so following
the principle of Least Surprise that's what we should do.

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

Re: [OE-core] ✗ patchtest: failure for Fixes for eSDK and testsdkext

[Paul Eggleton]

On Thu, 17 Nov 2016 09:02:21 Burton, Ross wrote:
> On 17 November 2016 at 06:55, Patchwork <
> 
> patchw...@patchwork.openembedded.org> wrote:
> > * Patch[7/8] oeqa/sdkext/devtool.py: skip
> > test_extend_autotools_recipe_creation when no libxml2
> > 
> >   IssueCommit shortlog is too long [test_shortlog_length]
> >   Suggested fixEdit shortlog so that it is 80 characters or less
> > 
> > (currently 82 characters)
> 
> I'm not sure we've ever been super-strict on this, so I'm wondering if
> warning over 90 is sensible so that we allow an extra two characters when
> function names are long but still detect when someone has put an essay in
> the first line (which does happen if the submitter isn't aware of the git
> convention).

Yep I'd support that.

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] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Christopher Larson]

On Thu, Nov 17, 2016 at 9:11 AM, Fabio Berton  wrote:

> Patches in this commit have Upstream-Status: Submitted tag.
>

I know, the point was the tag was within the commit message in the patch,
not just the patch file — wrong location within the patch file. Is the
Upstream-Status tag in the commits you submitted upstream? Unlikely, it’s
oe-specific metadata.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Christopher Larson]

On Thu, Nov 17, 2016 at 9:21 AM, Fabio Berton  wrote:

> No, I created a patch, git format-patch and then edit generated files with
> Upstream-Status tag and added to recipe. Is this wrong?


As I indicated in my first reply, it’s best to put the tag outside the
generated patch (above it, or below the —-), as it isn’t part of the
commit, only part of the patch file. It’s minor, and you don’t need to
re-submit, but in general the tag is not part of the commit message. For
example, if your patch was applied to a git repository with git-am, it’d be
in the commit message, which should not be the case.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Fabio Berton]

Hi Chistopher,

Patches in this commit have Upstream-Status: Submitted tag.

Thanks.

On Thu, Nov 17, 2016 at 2:00 PM, Christopher Larson 
wrote:

>
> On Thu, Nov 17, 2016 at 8:26 AM, Fabio Berton <
> fabio.ber...@ossystems.com.br> wrote:
>
>> Add patches to fix error:
>> /
>> | ERROR: oe_runmake failed
>> | config.status: creating pcap-config.tmp
>> | mv pcap-config.tmp pcap-config
>> | chmod a+x pcap-config
>> | ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
>> | ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
>> | {aka struct _compiler_state}' has no member named 'ai'
>> |   cstate.ai = NULL;
>> | ^
>> | ../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
>> | ../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
>> | (first use in this function)
>> |bpf_error(cstate, "direction applied to 'gateway'");
>> |  ^~
>> | ../libpcap-1.8.1/gencode.c:4914:13: note: each undeclared identifier is
>> | reported only once for each function it appears in
>> \
>>
>> Patches were submitted to upstream [1]
>>
>> [1] https://github.com/the-tcpdump-group/libpcap/pull/541
>>
>> Signed-off-by: Fabio Berton 
>>
>
> This is fairly common, but afaik the Upstream-Status is an artifact of the
> patch, not the commit that generated the patch, so belongs outside (above)
> the commit message in the patch file.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Fabio Berton]

No, I created a patch, git format-patch and then edit generated files with
Upstream-Status tag and added to recipe. Is this wrong?

On Thu, Nov 17, 2016 at 2:15 PM, Christopher Larson 
wrote:

>
> On Thu, Nov 17, 2016 at 9:11 AM, Fabio Berton <
> fabio.ber...@ossystems.com.br> wrote:
>
>> Patches in this commit have Upstream-Status: Submitted tag.
>>
>
> I know, the point was the tag was within the commit message in the patch,
> not just the patch file — wrong location within the patch file. Is the
> Upstream-Status tag in the commits you submitted upstream? Unlikely, it’s
> oe-specific metadata.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] classes: add gitupstream class

[Burton, Ross]

On 17 November 2016 at 15:50, Ross Burton  wrote:

>  BBCLASSEXTEND = "gitupstream"
>  SRC_URI_class-gitupstream = "git://git.example.com/example"
>  SRCREV_class-gitupstream = "abcd1234"
>

This isn't quite right, if you don't want to patch bitbake then use
BBCLASSEXTEND="gitupstream:foo".

I have patches to extend this to native recipes but they're rather ugly so
are not ready yet.

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

Re: [OE-core] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Christopher Larson]

On Thu, Nov 17, 2016 at 8:26 AM, Fabio Berton  wrote:

> Add patches to fix error:
> /
> | ERROR: oe_runmake failed
> | config.status: creating pcap-config.tmp
> | mv pcap-config.tmp pcap-config
> | chmod a+x pcap-config
> | ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
> | ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
> | {aka struct _compiler_state}' has no member named 'ai'
> |   cstate.ai = NULL;
> | ^
> | ../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
> | ../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
> | (first use in this function)
> |bpf_error(cstate, "direction applied to 'gateway'");
> |  ^~
> | ../libpcap-1.8.1/gencode.c:4914:13: note: each undeclared identifier is
> | reported only once for each function it appears in
> \
>
> Patches were submitted to upstream [1]
>
> [1] https://github.com/the-tcpdump-group/libpcap/pull/541
>
> Signed-off-by: Fabio Berton 
>

This is fairly common, but afaik the Upstream-Status is an artifact of the
patch, not the commit that generated the patch, so belongs outside (above)
the commit message in the patch file.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][RFC] classes: add gitupstream class

[Ross Burton]

This class lets you use BBCLASSEXTEND to add a variant of the recipe that
fetches from git instead of a tarball.

For example:

 BBCLASSEXTEND = "gitupstream"
 SRC_URI_class-gitupstream = "git://git.example.com/example"
 SRCREV_class-gitupstream = "abcd1234"

This variant will have DEFAULT_PREFERENCE set to -1 so it needs to be selected
to be used, and any git-specific tweaks can be done with the class-gitupstream
override, for example:

 DEPENDS_append_class-gitupstream = " gperf-native"

 do_configure_prepend_class-gitupstream() {
touch ${S}/README
 }

It currently only supports creating a git variant of the target recipe, not
native or nativesdk.

Signed-off-by: Ross Burton 
---
 meta/classes/gitupstream.bbclass | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 meta/classes/gitupstream.bbclass

diff --git a/meta/classes/gitupstream.bbclass b/meta/classes/gitupstream.bbclass
new file mode 100644
index 000..64aab61
--- /dev/null
+++ b/meta/classes/gitupstream.bbclass
@@ -0,0 +1,23 @@
+CLASSOVERRIDE = "class-gitupstream"
+
+# TODO doesn't let you gitupstream a native recipe yet
+
+python gitupstream_virtclass_handler () {
+# Do nothing if this is inherited, as it's for BBCLASSEXTEND
+if "gitupstream" not in (e.data.getVar('BBCLASSEXTEND', True) or ""):
+bb.warn("Don't inherit gitupstream, use BBCLASSEXTEND")
+return
+
+# TODO sanity check somehow?
+
+d.setVar("DEFAULT_PREFERENCE", "-1")
+d.setVar("S", "${WORKDIR}/git")
+
+# Modify the SRCREV, if the recipe hasn't used PV_class-gitupstream to
+# assign a +gitX PV already.
+pv = d.getVar("PV", True)
+if "+git" not in pv:
+d.setVar("PV", pv + "+git${SRCPV}")
+}
+addhandler gitupstream_virtclass_handler
+gitupstream_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
-- 
2.8.1

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

Re: [OE-core] [PATCH] Test needed to verify postinst script order.

[Jose Perez Carranza]

On 11/17/2016 06:14 AM, Burton, Ross wrote:


On 16 November 2016 at 00:50, Francisco Pedraza 
> wrote:


Will verify the following:
1. Compile a minimal image.
2. The compiled image will add the created layer with the
recipes postinstz postinsta postinstb postinstd postinstp postinstt
created previously at "meta-selftest/recipes-test"
2. Run qemu
3. Validate the task execution order.
V4


This is missing the test that some postinsts should be happening at 
rootfs time.
I have assigned the bug 8433 and I will send a different patch to add 
those test cases, I'm just waiting to the final implementation of this  
patch to be accepted to avoid execution and merge conflicts.


Also, can it permute PACKAGE_CLASSES (rotate through all three 
options) so it exercises all backends.


Signed-off-by: Francisco Pedraza
>
---
 .../recipes-test/postinsta/postinsta_1.0.bb
| 20 +++
 .../recipes-test/postinstb/postinstb_1.0.bb
| 22 
 .../recipes-test/postinstd/postinstd_1.0.bb
| 22 
 .../recipes-test/postinstp/postinstp_1.0.bb
| 22 
 .../recipes-test/postinstt/postinstt_1.0.bb
| 22 
 .../recipes-test/postinstz/postinstz_1.0.bb
| 12 +++


For clarity can all of these be squashed into a single recipe with 
clearer names?


Ross




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

[OE-core] [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable

[Fabio Berton]

Add patches to fix error:
/
| ERROR: oe_runmake failed
| config.status: creating pcap-config.tmp
| mv pcap-config.tmp pcap-config
| chmod a+x pcap-config
| ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
| ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
| {aka struct _compiler_state}' has no member named 'ai'
|   cstate.ai = NULL;
| ^
| ../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
| ../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
| (first use in this function)
|bpf_error(cstate, "direction applied to 'gateway'");
|  ^~
| ../libpcap-1.8.1/gencode.c:4914:13: note: each undeclared identifier is
| reported only once for each function it appears in
\

Patches were submitted to upstream [1]

[1] https://github.com/the-tcpdump-group/libpcap/pull/541

Signed-off-by: Fabio Berton 
---
 ...r_state_t.ai-usage-when-INET6-is-not-defi.patch | 41 +
 ...02-Add-missing-compiler_state_t-parameter.patch | 67 ++
 meta/recipes-connectivity/libpcap/libpcap_1.8.1.bb |  2 +
 3 files changed, 110 insertions(+)
 create mode 100644 
meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
 create mode 100644 
meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch

diff --git 
a/meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
 
b/meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
new file mode 100644
index 000..edb6ae5
--- /dev/null
+++ 
b/meta/recipes-connectivity/libpcap/libpcap/0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch
@@ -0,0 +1,41 @@
+From 64aa033a061c43fc15c711f2490ae41d23b868c3 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Thu, 17 Nov 2016 09:44:42 -0200
+Subject: [PATCH 1/2] Fix compiler_state_t.ai usage when INET6 is not defined
+Organization: O.S. Systems Software LTDA.
+
+Fix error:
+
+/
+| ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
+| ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
+| {aka struct _compiler_state}' has no member named 'ai'
+|   cstate.ai = NULL;
+\
+
+Upstream-Status: Submitted [1]
+
+[1] https://github.com/the-tcpdump-group/libpcap/pull/541
+
+Signed-off-by: Fabio Berton 
+---
+ gencode.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/gencode.c b/gencode.c
+index a887f27..e103c70 100644
+--- a/gencode.c
 b/gencode.c
+@@ -690,7 +690,9 @@ pcap_compile(pcap_t *p, struct bpf_program *program,
+   }
+   initchunks();
+   cstate.no_optimize = 0;
++#ifdef INET6
+   cstate.ai = NULL;
++#endif
+   cstate.ic.root = NULL;
+   cstate.ic.cur_mark = 0;
+   cstate.bpf_pcap = p;
+-- 
+2.1.4
+
diff --git 
a/meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
 
b/meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
new file mode 100644
index 000..032b265
--- /dev/null
+++ 
b/meta/recipes-connectivity/libpcap/libpcap/0002-Add-missing-compiler_state_t-parameter.patch
@@ -0,0 +1,67 @@
+From 50ec0a088d5924a8305b2d70dcba71b0942dee1a Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Thu, 17 Nov 2016 09:47:29 -0200
+Subject: [PATCH 2/2] Add missing compiler_state_t parameter
+Organization: O.S. Systems Software LTDA.
+
+Fix error:
+
+/
+|../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
+|../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
+| (first use in this function)
+|bpf_error(cstate, "direction applied to 'gateway'");
+\
+
+Upstream-Status: Submitted [1]
+
+[1] https://github.com/the-tcpdump-group/libpcap/pull/541
+
+Signed-off-by: Fabio Berton 
+---
+ gencode.c | 15 ---
+ 1 file changed, 8 insertions(+), 7 deletions(-)
+
+diff --git a/gencode.c b/gencode.c
+index e103c70..f07c0be 100644
+--- a/gencode.c
 b/gencode.c
+@@ -523,7 +523,7 @@ static struct block *gen_host6(compiler_state_t *, struct 
in6_addr *,
+ struct in6_addr *, int, int, int);
+ #endif
+ #ifndef INET6
+-static struct block *gen_gateway(const u_char *, bpf_u_int32 **, int, int);
++static struct block *gen_gateway(compiler_state_t *, const u_char *, 
bpf_u_int32 **, int, int);
+ #endif
+ static struct block *gen_ipfrag(compiler_state_t *);
+ static struct block *gen_portatom(compiler_state_t *, int, bpf_int32);
+@@ -4904,11 +4904,12 @@ gen_host6(compiler_state_t *cstate, struct in6_addr 
*addr,
+ 
+ #ifndef INET6
+ static struct block *
+-gen_gateway(eaddr, alist, proto, dir)
+-  const u_char *eaddr;
+-  bpf_u_int32 **alist;
+-  int proto;
+-  int dir;
++gen_gateway(cstate, eaddr, alist, proto, dir)
++compiler_state_t *cstate;
++const u_char *eaddr;
++

[OE-core] [PATCHv2 4/4] mesa: Upgrade 12.0.3 -> 13.0.1

[Jussi Kukkonen]

New major release with OpenGL 4.4 support. Dependency on libudev has
been removed.

* Rebase replace_glibc_check_with_linux.patch
* Add patch to find native wayland-scanner
* Add PACKAGECONFIG[osmesa], disabled by default
* package osmesa header correctly

Signed-off-by: Jussi Kukkonen 
---

Changes since v1:
* Add PACKAGECONFIG[osmesa], disabled by default
* package osmesa header correctly

I've force pushed the branch:

  git://git.yoctoproject.org/poky-contrib jku/mesa-piglit
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/mesa-piglit

Thanks,
  Jussi


 .../0001-Use-wayland-scanner-in-the-path.patch | 37 ++
 .../files/replace_glibc_check_with_linux.patch | 25 ++-
 .../mesa/{mesa-gl_12.0.3.bb => mesa-gl_13.0.1.bb}  |  0
 meta/recipes-graphics/mesa/mesa.inc|  7 ++--
 .../mesa/{mesa_12.0.3.bb => mesa_13.0.1.bb}|  5 +--
 5 files changed, 62 insertions(+), 12 deletions(-)
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-Use-wayland-scanner-in-the-path.patch
 rename meta/recipes-graphics/mesa/{mesa-gl_12.0.3.bb => mesa-gl_13.0.1.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_12.0.3.bb => mesa_13.0.1.bb} (75%)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Use-wayland-scanner-in-the-path.patch 
b/meta/recipes-graphics/mesa/files/0001-Use-wayland-scanner-in-the-path.patch
new file mode 100644
index 000..e49695b
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-Use-wayland-scanner-in-the-path.patch
@@ -0,0 +1,37 @@
+From 2f68fcaaf4964e7feeb383f5c26851965cda037c Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Tue, 15 Nov 2016 15:20:49 +0200
+Subject: [PATCH] Simplify wayland-scanner lookup
+
+Don't use pkg-config to lookup the path of a binary that's in the path.
+
+Alternatively we'd have to prefix the path returned by pkg-config with
+PKG_CONFIG_SYSROOT_DIR.
+
+Upstream-Status: Pending
+Signed-off-by: Jussi Kukkonen 
+---
+ configure.ac | 7 +--
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index e56e35a..a92005a 100644
+--- a/configure.ac
 b/configure.ac
+@@ -2020,12 +2020,7 @@ if test "x$with_egl_platforms" != "x" -a "x$enable_egl" 
!= xyes; then
+ AC_MSG_ERROR([cannot build egl state tracker without EGL library])
+ fi
+ 
+-PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
+-WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`,
+-WAYLAND_SCANNER='')
+-if test "x$WAYLAND_SCANNER" = x; then
+-AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+-fi
++AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+ 
+ # Do per-EGL platform setups and checks
+ egl_platforms=`IFS=', '; echo $with_egl_platforms`
+-- 
+2.1.4
+
diff --git 
a/meta/recipes-graphics/mesa/files/replace_glibc_check_with_linux.patch 
b/meta/recipes-graphics/mesa/files/replace_glibc_check_with_linux.patch
index e4461ef..0280ee8 100644
--- a/meta/recipes-graphics/mesa/files/replace_glibc_check_with_linux.patch
+++ b/meta/recipes-graphics/mesa/files/replace_glibc_check_with_linux.patch
@@ -2,16 +2,25 @@ endianness check is OS wide and not specific to libc
 
 Signed-off-by: Khem Raj 
 Upstream-Status: Pending
-Index: mesa-11.1.1/src/gallium/include/pipe/p_config.h
-===
 mesa-11.1.1.orig/src/gallium/include/pipe/p_config.h
-+++ mesa-11.1.1/src/gallium/include/pipe/p_config.h
-@@ -130,7 +130,7 @@
-  * Endian detection.
-  */
+
+Signed-off-by: Jussi Kukkonen 
+---
+ src/util/u_endian.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/util/u_endian.h b/src/util/u_endian.h
+index b9d563d..2d5eab9 100644
+--- a/src/util/u_endian.h
 b/src/util/u_endian.h
+@@ -27,7 +27,7 @@
+ #ifndef U_ENDIAN_H
+ #define U_ENDIAN_H
  
--#ifdef __GLIBC__
+-#if defined(__GLIBC__) || defined(ANDROID)
 +#if defined(__linux__)
  #include 
  
  #if __BYTE_ORDER == __LITTLE_ENDIAN
+-- 
+2.1.4
+
diff --git a/meta/recipes-graphics/mesa/mesa-gl_12.0.3.bb 
b/meta/recipes-graphics/mesa/mesa-gl_13.0.1.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_12.0.3.bb
rename to meta/recipes-graphics/mesa/mesa-gl_13.0.1.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index e4880ff..4ec4961 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = 
"file://docs/license.html;md5=899fbe7e42d494c7c8c159c7001693d
 
 PE = "2"
 
-DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native 
udev"
+DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native"
 
 PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl 
virtual/mesa"
 
@@ -64,6 +64,9 @@ PACKAGECONFIG[gallium-llvm] = 

Re: [OE-core] FW: [PATCH v2] oe-tests: Migrate tests from /oe/test to /oeqa/selftest/oe-tests

[Jose Perez Carranza]

On 11/15/2016 03:11 PM, Burton, Ross wrote:


On 15 November 2016 at 19:10, Benjamin Esquivel 
> wrote:


The reason for the migration of the tests is for them to be
included in the selftest execution. And for that execution, it
needs to base off of the oeSelfTest class.


Sounds like a problem with the discovery if it mandates oeselftest.  
Is there a reason why it can't also execute bare unittests?


  You are right this is a problem on the suite right now AFAIK there 
will pbe a fix for this on oeqa2 framework adding Marian and Anibal to 
the loop to give an in put on this.

Ross


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

[OE-core] [PATCH 00/32] Pull request for Krogoth-next

[Armin Kuster]

Please consider these changes for Krogoth-next

The following changes since commit 3bf928a3b6354bc09c87fcbf9e3972c8d368aaa3:

  dev-manual: Fixed typo for "${INC_PR}.0" (2016-11-16 10:38:24 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib akuster/krogoth-next
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/krogoth-next

Adrian Dudau (2):
  qemu: Security fix CVE-2016-4439
  qemu: Security fix CVE-2016-4952

Armin Kuster (2):
  tzcode-native: update to 2016h
  tzdata: Update to 2016h

Daniel Díaz (1):
  weston: Add no-input-device patch to 1.9.0.

Otavio Salvador (1):
  gstreamer1.0-libav: Add 'valgrind' config option

Richard Purdie (5):
  sstate: Ensure we don't remove sigbasedata files
  rm_work: Ensure we don't remove sigbasedata files
  bitbake: build: Ensure we preserve sigbasedata files as well as
sigdata ones
  bitbake: siggen: Pass basehash to worker processes and sanity check
reparsing result
  bitbake: siggen: Ensure taskhash mismatches don't override existing
data

Ross Burton (4):
  classes/cross: set lt_cv_sys_lib_dlsearch_path_spec
  classes/native: set lt_cv_sys_lib_dlsearch_path_spec
  binutils: fix typo in libtool patch
  binutils: apply RPATH fixes from our libtool patches

Sona Sarmadi (11):
  curl: CVE-2016-8615
  curl: CVE-2016-8616
  curl: CVE-2016-8617
  curl: CVE-2016-8618
  curl: CVE-2016-8619
  curl: CVE-2016-8620
  curl: CVE-2016-8621
  curl: CVE-2016-8622
  curl: CVE-2016-8623
  curl: CVE-2016-8624
  curl: CVE-2016-8625

Yi Zhao (5):
  tiff: Security fix CVE-2016-3945
  tiff: Security fix CVE-2016-3990
  tiff: Security fix CVE-2016-3991
  tiff: Security fix CVE-2016-3623
  tiff: Security fix CVE-2016-3622

Zeeshan Ali (1):
  nss: Disable warning on deprecated API usage

 bitbake/lib/bb/build.py|   2 +-
 bitbake/lib/bb/siggen.py   |  31 +-
 meta/classes/cross.bbclass |   2 +
 meta/classes/native.bbclass|   3 +-
 meta/classes/rm_work.bbclass   |   2 +-
 meta/classes/sstate.bbclass|   2 +-
 meta/recipes-devtools/binutils/binutils-2.26.inc   |   1 +
 .../binutils/binutils/0006-Use-libtool-2.4.patch   |   5 +-
 .../binutils/0014-libtool-remove-rpath.patch   | 100 
 .../recipes-devtools/qemu/qemu/CVE-2016-4441.patch |  78 +++
 .../recipes-devtools/qemu/qemu/CVE-2016-4952.patch | 105 
 meta/recipes-devtools/qemu/qemu_2.5.0.bb   |   2 +
 ...code-native_2016g.bb => tzcode-native_2016h.bb} |   8 +-
 .../tzdata/{tzdata_2016g.bb => tzdata_2016h.bb}|   4 +-
 .../add-config-option-for-no-input-device.patch| 125 +
 meta/recipes-graphics/wayland/weston_1.9.0.bb  |   1 +
 .../gstreamer/gstreamer1.0-libav.inc   |   1 +
 .../libtiff/files/CVE-2016-3622.patch  | 129 +
 .../libtiff/files/CVE-2016-3623.patch  |  52 ++
 .../libtiff/files/CVE-2016-3945.patch  | 118 
 .../libtiff/files/CVE-2016-3990.patch  |  66 +++
 .../libtiff/files/CVE-2016-3991.patch  | 147 +
 meta/recipes-multimedia/libtiff/tiff_4.0.6.bb  |   5 +
 meta/recipes-support/curl/curl/CVE-2016-8615.patch |  77 +++
 meta/recipes-support/curl/curl/CVE-2016-8616.patch |  49 ++
 meta/recipes-support/curl/curl/CVE-2016-8617.patch |  28 +
 meta/recipes-support/curl/curl/CVE-2016-8618.patch |  52 ++
 meta/recipes-support/curl/curl/CVE-2016-8619.patch |  52 ++
 meta/recipes-support/curl/curl/CVE-2016-8620.patch |  44 ++
 meta/recipes-support/curl/curl/CVE-2016-8621.patch | 120 
 meta/recipes-support/curl/curl/CVE-2016-8622.patch |  94 
 meta/recipes-support/curl/curl/CVE-2016-8623.patch | 209 +++
 meta/recipes-support/curl/curl/CVE-2016-8624.patch |  51 ++
 meta/recipes-support/curl/curl/CVE-2016-8625.patch | 615 +
 .../url-remove-unconditional-idn2.h-include.patch  |  29 +
 meta/recipes-support/curl/curl_7.47.1.bb   |  12 +
 .../nss/nss-disable-werror-on-deprecated-api.patch |  22 +
 meta/recipes-support/nss/nss_3.21.bb   |   1 +
 38 files changed, 2417 insertions(+), 27 deletions(-)
 create mode 100644 
meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4952.patch
 rename meta/recipes-extended/tzcode/{tzcode-native_2016g.bb => 
tzcode-native_2016h.bb} (68%)
 rename meta/recipes-extended/tzdata/{tzdata_2016g.bb => tzdata_2016h.bb} (98%)
 create mode 100644 
meta/recipes-graphics/wayland/weston/add-config-option-for-no-input-device.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3622.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3623.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3945.patch
 create mode 100644 

Re: [OE-core] [PATCH] Test needed to verify postinst script order.

[Burton, Ross]

On 16 November 2016 at 00:50, Francisco Pedraza <
francisco.j.pedraza.gonza...@intel.com> wrote:

> Will verify the following:
> 1. Compile a minimal image.
> 2. The compiled image will add the created layer with the
> recipes postinstz postinsta postinstb postinstd postinstp postinstt
> created previously at "meta-selftest/recipes-test"
> 2. Run qemu
> 3. Validate the task execution order.
> V4
>

This is missing the test that some postinsts should be happening at rootfs
time.

Also, can it permute PACKAGE_CLASSES (rotate through all three options) so
it exercises all backends.

Signed-off-by: Francisco Pedraza 
> ---
>  .../recipes-test/postinsta/postinsta_1.0.bb| 20 +++
>  .../recipes-test/postinstb/postinstb_1.0.bb| 22 
>  .../recipes-test/postinstd/postinstd_1.0.bb| 22 
>  .../recipes-test/postinstp/postinstp_1.0.bb| 22 
>  .../recipes-test/postinstt/postinstt_1.0.bb| 22 
>  .../recipes-test/postinstz/postinstz_1.0.bb| 12 +++
>

For clarity can all of these be squashed into a single recipe with clearer
names?

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

Re: [OE-core] [PATCH 4/4] mesa: Upgrade 12.0.3 -> 13.0.1

[Burton, Ross]

On 16 November 2016 at 13:15, Jussi Kukkonen 
wrote:

> New major release with OpenGL 4.4 support. Dependency on libudev has
> been removed.
>
> Rebase replace_glibc_check_with_linux.patch.
> Add patch to find native wayland-scanner.
>
> Signed-off-by: Jussi Kukkonen 
>

This has removed some files:

packages/corei7-64-poky-linux/mesa/libgl-mesa-dev: FILELIST: removed
"/usr/include/GL/osmesa.h /usr/include/GL/wglext.h
/usr/include/GL/mesa_glinterop.h"

osmesa is now behind a disabled configure option, so I guess we should make
that an option at least, even if we do disable it by default.

wglext is Windows specific, and mesa-glinterop.h appears to be internal
only, so they're good.

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

[OE-core] [morty][PATCH] libbsd 0.8.3: BBCLASSEXTEND to native and nativesdk

[Nicolas Dechesne]

From: Koen Kooi 

Android-tools depends on it and to build the native versions of fastboot, adb, 
mkbootimg and others libbsd needs to support native builds.

Signed-off-by: Koen Kooi 
Signed-off-by: Ross Burton 
(cherry picked from commit b02cef58ee35dd277fff48538ce2803df1cbc4d5)
Signed-off-by: Nicolas Dechesne 
---
 meta/recipes-support/libbsd/libbsd_0.8.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libbsd/libbsd_0.8.3.bb 
b/meta/recipes-support/libbsd/libbsd_0.8.3.bb
index 92121ef..6f734ab 100644
--- a/meta/recipes-support/libbsd/libbsd_0.8.3.bb
+++ b/meta/recipes-support/libbsd/libbsd_0.8.3.bb
@@ -41,3 +41,5 @@ SRC_URI[md5sum] = "e935c1bb6cc98a4a43cb1da22795493a"
 SRC_URI[sha256sum] = 
"934b634f4dfd865b6482650b8f522c70ae65c463529de8be907b53c89c3a34a8"
 
 inherit autotools pkgconfig
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.7.0

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

Re: [OE-core] [PATCH v2 1/3] module.bbclass: use Module.symvers for dependants

[André Draszik]

Hi,

On Wed, 2016-11-16 at 15:18 -0500, Denys Dmytriyenko wrote:
> On Thu, Aug 18, 2016 at 08:56:24AM +0100, André Draszik wrote:
> >  
> > @@ -24,6 +34,11 @@ module_do_install() {
> >        CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> >        O=${STAGING_KERNEL_BUILDDIR} \
> >        ${MODULES_INSTALL_TARGET}
> > +
> > +   install -d -m0755 ${D}${includedir}/${BPN}
> > +   cp -a --no-preserve=ownership ${B}/Module.symvers
> > ${D}${includedir}/${BPN}
> 
> Hmm, why is Module.symvers expected to be in the root of ${B}? This seems
> like 
> a very artificial assumption/requirement!

[...]

> I wonder if this should have been rolled into ${MODULES_INSTALL_TARGET} 
> step...

What about adding a (lazy ?=) variable to be able to override the location
of Module.symvers within ${B}, or alternatively using find to automatically
detect it? I guess there could also be more than one in theory? Do you have
something different in mind?

A.

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

Re: [OE-core] [PATCH] libdrm: Upgrade 2.4.71 -> 2.4.73

[Andreas Müller]

On Thu, Nov 17, 2016 at 9:56 AM, Jussi Kukkonen
 wrote:
> Signed-off-by: Jussi Kukkonen 
> ---
>
> I've pushed this into the mesa-piglit update branch:
>
>   git://git.yoctoproject.org/poky-contrib jku/mesa-piglit
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/mesa-piglit
>
> Thanks,
>  Jussi
>
>
>  meta/recipes-graphics/drm/{libdrm_2.4.71.bb => libdrm_2.4.73.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-graphics/drm/{libdrm_2.4.71.bb => libdrm_2.4.73.bb} (93%)
>
> diff --git a/meta/recipes-graphics/drm/libdrm_2.4.71.bb 
> b/meta/recipes-graphics/drm/libdrm_2.4.73.bb
> similarity index 93%
> rename from meta/recipes-graphics/drm/libdrm_2.4.71.bb
> rename to meta/recipes-graphics/drm/libdrm_2.4.73.bb
> index 152cf55..3315014 100644
> --- a/meta/recipes-graphics/drm/libdrm_2.4.71.bb
> +++ b/meta/recipes-graphics/drm/libdrm_2.4.73.bb
> @@ -16,8 +16,8 @@ SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
> 
> file://0001-configure.ac-Allow-explicit-enabling-of-cunit-tests.patch \
>"
>
> -SRC_URI[md5sum] = "776bccc84618b616fc57a7143836ae7a"
> -SRC_URI[sha256sum] = 
> "c66287ddeee5f46ea8f8880b94b80acb3bbc33ba6321d17767eef145046df9b8"
> +SRC_URI[md5sum] = "bc1cee09cde72ffe3b952e8f50ccdaa8"
> +SRC_URI[sha256sum] = 
> "96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d"
>
>  inherit autotools pkgconfig manpages
>
> --
> 2.1.4
>
Thanks!

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

Re: [OE-core] ✗ patchtest: failure for Fixes for eSDK and testsdkext

[Burton, Ross]

On 17 November 2016 at 06:55, Patchwork <
patchw...@patchwork.openembedded.org> wrote:

> * Patch[7/8] oeqa/sdkext/devtool.py: skip
> test_extend_autotools_recipe_creation when no libxml2
>   IssueCommit shortlog is too long [test_shortlog_length]
>   Suggested fixEdit shortlog so that it is 80 characters or less
> (currently 82 characters)
>

I'm not sure we've ever been super-strict on this, so I'm wondering if
warning over 90 is sensible so that we allow an extra two characters when
function names are long but still detect when someone has put an essay in
the first line (which does happen if the submitter isn't aware of the git
convention).

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

[OE-core] [PATCH] libdrm: Upgrade 2.4.71 -> 2.4.73

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen 
---

I've pushed this into the mesa-piglit update branch:

  git://git.yoctoproject.org/poky-contrib jku/mesa-piglit
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/mesa-piglit

Thanks,
 Jussi


 meta/recipes-graphics/drm/{libdrm_2.4.71.bb => libdrm_2.4.73.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/drm/{libdrm_2.4.71.bb => libdrm_2.4.73.bb} (93%)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.71.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.73.bb
similarity index 93%
rename from meta/recipes-graphics/drm/libdrm_2.4.71.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.73.bb
index 152cf55..3315014 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.71.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.73.bb
@@ -16,8 +16,8 @@ SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \

file://0001-configure.ac-Allow-explicit-enabling-of-cunit-tests.patch \
   "
 
-SRC_URI[md5sum] = "776bccc84618b616fc57a7143836ae7a"
-SRC_URI[sha256sum] = 
"c66287ddeee5f46ea8f8880b94b80acb3bbc33ba6321d17767eef145046df9b8"
+SRC_URI[md5sum] = "bc1cee09cde72ffe3b952e8f50ccdaa8"
+SRC_URI[sha256sum] = 
"96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d"
 
 inherit autotools pkgconfig manpages
 
-- 
2.1.4

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

[OE-core] [PATCH 1/2] tiff: Security fix CVE-2016-3658

[Yi Zhao]

CVE-2016-3658 libtiff: The TIFFWriteDirectoryTagLongLong8Array function
in tif_dirwrite.c in the tiffset tool in LibTIFF 4.0.6 and earlier
allows remote attackers to cause a denial of service (out-of-bounds
read) via vectors involving the ma variable.

External References:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3658
http://www.openwall.com/lists/oss-security/2016/04/08/12
http://bugzilla.maptools.org/show_bug.cgi?id=2546

Patch from:
https://github.com/vadz/libtiff/commit/45c68450bef8ad876f310b495165c513cad8b67d

This git repository is a mirror of libtiff cvs repository at cvs.maptools.org
created and updated using "git cvsimport".

Signed-off-by: Yi Zhao 
---
 .../libtiff/files/CVE-2016-3658.patch  | 120 +
 meta/recipes-multimedia/libtiff/tiff_4.0.6.bb  |   1 +
 2 files changed, 121 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3658.patch

diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2016-3658.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2016-3658.patch
new file mode 100644
index 000..950c634
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2016-3658.patch
@@ -0,0 +1,120 @@
+From 45c68450bef8ad876f310b495165c513cad8b67d Mon Sep 17 00:00:00 2001
+From: erouault 
+Date: Tue, 25 Oct 2016 21:35:15 +
+Subject: [PATCH] * libtiff/tif_dir.c: discard values of SMinSampleValue and
+ SMaxSampleValue when they have been read and the value of SamplesPerPixel is
+ changed afterwards (like when reading a OJPEG compressed image with a missing
+ SamplesPerPixel tag, and whose photometric is RGB or YCbCr, forcing
+ SamplesPerPixel being 3). Otherwise when rewriting the directory (for example
+ with tiffset, we will expect 3 values whereas the array had been allocated
+ with just one), thus causing a out of bound read access. Fixes
+ http://bugzilla.maptools.org/show_bug.cgi?id=2500 (CVE-2014-8127, duplicate:
+ CVE-2016-3658)
+
+* libtiff/tif_write.c: avoid null pointer dereference on td_stripoffset
+when writing directory, if FIELD_STRIPOFFSETS was artificially set
+for a hack casein OJPEG case.
+Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2500
+(CVE-2014-8127, duplicate: CVE-2016-3658)
+
+CVE: CVE-2016-3658
+Upstream-Status: Backport
+https://github.com/vadz/libtiff/commit/45c68450bef8ad876f310b495165c513cad8b67d
+
+Signed-off-by: Yi Zhao 
+---
+ ChangeLog  | 19 +++
+ libtiff/tif_dir.c  | 22 ++
+ libtiff/tif_dirwrite.c | 16 ++--
+ 3 files changed, 55 insertions(+), 2 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 375fe02..8027964 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,22 @@
++2016-10-25 Even Rouault 
++
++  * libtiff/tif_dir.c: discard values of SMinSampleValue and
++  SMaxSampleValue when they have been read and the value of
++  SamplesPerPixel is changed afterwards (like when reading a
++  OJPEG compressed image with a missing SamplesPerPixel tag,
++  and whose photometric is RGB or YCbCr, forcing SamplesPerPixel
++  being 3). Otherwise when rewriting the directory (for example
++  with tiffset, we will expect 3 values whereas the array had been
++  allocated with just one), thus causing a out of bound read access.
++  Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2500
++  (CVE-2014-8127, duplicate: CVE-2016-3658)
++  
++  * libtiff/tif_write.c: avoid null pointer dereference on td_stripoffset
++  when writing directory, if FIELD_STRIPOFFSETS was artificially set
++  for a hack case in OJPEG case.
++  Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2500
++  (CVE-2014-8127, duplicate: CVE-2016-3658)
++
+ 2016-09-24  Bob Friesenhahn  
+ 
+   * libtiff/tif_getimage.c (TIFFRGBAImageOK): Reject attempts to
+diff --git a/libtiff/tif_dir.c b/libtiff/tif_dir.c
+index 8073480..160c5d4 100644
+--- a/libtiff/tif_dir.c
 b/libtiff/tif_dir.c
+@@ -256,6 +256,28 @@ _TIFFVSetField(TIFF* tif, uint32 tag, va_list ap)
+   v = (uint16) va_arg(ap, uint16_vap);
+   if (v == 0)
+   goto badvalue;
++if( v != td->td_samplesperpixel )
++{
++/* See http://bugzilla.maptools.org/show_bug.cgi?id=2500 */
++if( td->td_sminsamplevalue != NULL )
++{
++TIFFWarningExt(tif->tif_clientdata,module,
++"SamplesPerPixel tag value is changing, "
++"but SMinSampleValue tag was read with a different value. 
Cancelling it");
++TIFFClrFieldBit(tif,FIELD_SMINSAMPLEVALUE);
++_TIFFfree(td->td_sminsamplevalue);
++td->td_sminsamplevalue = NULL;
++}
++if( td->td_smaxsamplevalue != NULL )
++{
++TIFFWarningExt(tif->tif_clientdata,module,
++

[OE-core] [PATCH 2/2] tiff: Security fix CVE-2016-3632

[Yi Zhao]

CVE-2016-3632 libtiff: The _TIFFVGetField function in tif_dirinfo.c in
LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of
service (out-of-bounds write) or execute arbitrary code via a crafted
TIFF image.

External References:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3632
http://bugzilla.maptools.org/show_bug.cgi?id=2549
https://bugzilla.redhat.com/show_bug.cgi?id=1325095

The patch is from RHEL7.

Signed-off-by: Yi Zhao 
---
 .../libtiff/files/CVE-2016-3632.patch  | 34 ++
 meta/recipes-multimedia/libtiff/tiff_4.0.6.bb  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3632.patch

diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2016-3632.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2016-3632.patch
new file mode 100644
index 000..a839250
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2016-3632.patch
@@ -0,0 +1,34 @@
+From d3f9829a37661749b200760ad6525f77cf77d77a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Nikola=20Forr=C3=B3?= 
+Date: Mon, 11 Jul 2016 16:04:34 +0200
+Subject: [PATCH 4/8] Fix CVE-2016-3632
+
+CVE-2016-3632 libtiff: The _TIFFVGetField function in tif_dirinfo.c in
+LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service
+(out-of-bounds write) or execute arbitrary code via a crafted TIFF image.
+
+CVE: CVE-2016-3632
+Upstream-Status: Backport [RedHat RHEL7]
+
+Signed-off-by: Yi Zhao 
+---
+ tools/thumbnail.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tools/thumbnail.c b/tools/thumbnail.c
+index fd1cba5..75e7009 100644
+--- a/tools/thumbnail.c
 b/tools/thumbnail.c
+@@ -253,7 +253,8 @@ static struct cpTag {
+ { TIFFTAG_WHITEPOINT, 2, TIFF_RATIONAL },
+ { TIFFTAG_PRIMARYCHROMATICITIES,  (uint16) -1,TIFF_RATIONAL },
+ { TIFFTAG_HALFTONEHINTS,  2, TIFF_SHORT },
+-{ TIFFTAG_BADFAXLINES,1, TIFF_LONG },
++// disable BADFAXLINES, CVE-2016-3632
++//{ TIFFTAG_BADFAXLINES,  1, TIFF_LONG },
+ { TIFFTAG_CLEANFAXDATA,   1, TIFF_SHORT },
+ { TIFFTAG_CONSECUTIVEBADFAXLINES, 1, TIFF_LONG },
+ { TIFFTAG_INKSET, 1, TIFF_SHORT },
+-- 
+2.7.4
+
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb 
b/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
index edd560f..9b4aff3 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
@@ -16,6 +16,7 @@ SRC_URI = 
"http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
file://CVE-2016-3623.patch \
file://CVE-2016-3622.patch \
file://CVE-2016-3658.patch \
+   file://CVE-2016-3632.patch \
   "
 
 SRC_URI[md5sum] = "d1d2e940dea0b5ad435f21f03d96dd72"
-- 
2.7.4

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

[OE-core] [PATCH 0/2] tiff: 2 CVE fixes

[Yi Zhao]

Yi Zhao (2):
  tiff: Security fix CVE-2016-3658
  tiff: Security fix CVE-2016-3632

 .../libtiff/files/CVE-2016-3632.patch  |  34 ++
 .../libtiff/files/CVE-2016-3658.patch  | 120 +
 meta/recipes-multimedia/libtiff/tiff_4.0.6.bb  |   2 +
 3 files changed, 156 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3632.patch
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2016-3658.patch

-- 
2.7.4

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