* Re: Modifying SRC_URI from anonymous python
From: Andre McCurdy @ 2016-11-18 3:31 UTC (permalink / raw)
To: Christopher Larson; +Cc: OE Core mailing list
In-Reply-To: <CABcZANmfZSGZsFFcXvSAhTgPBPvoQm=wx=p9Q7sPgSSn3D4mAg@mail.gmail.com>
On Thu, Nov 17, 2016 at 2:00 PM, Christopher Larson <clarson@kergoth.com> wrote:
>
> On Thu, Nov 17, 2016 at 2:28 PM, Andre McCurdy <armccurdy@gmail.com> 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
^ permalink raw reply
* [PATCH 00/13] Pull request jethro-next
From: Armin Kuster @ 2016-11-18 3:24 UTC (permalink / raw)
To: akuster, openembedded-core
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 +0000)
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
^ permalink raw reply
* Re: Modifying SRC_URI from anonymous python
From: Christopher Larson @ 2016-11-18 0:59 UTC (permalink / raw)
To: Richard Purdie; +Cc: OE Core mailing list
In-Reply-To: <1479423992.28508.99.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]
On Thu, Nov 17, 2016 at 4:06 PM, Richard Purdie <
richard.purdie@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
[-- Attachment #2: Type: text/html, Size: 3531 bytes --]
^ permalink raw reply
* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Khem Raj @ 2016-11-17 23:22 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: openembedded-architecture, OE-core
In-Reply-To: <20161117185001.GE26131@denix.org>
[-- Attachment #1.1: Type: text/plain, Size: 2082 bytes --]
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
>>> <http://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.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: Enabling uninative by default in oe-core?
From: Khem Raj @ 2016-11-17 23:19 UTC (permalink / raw)
To: Nicolas Dechesne; +Cc: openembedded-architecture, OE-core
In-Reply-To: <CAP71WjwJDTVsAcU9YrVh0uBcQ87Xt6HB9fCuj_t-jHcaGsjEWw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2675 bytes --]
On 11/17/16 10:56 AM, Nicolas Dechesne wrote:
> On Thu, Nov 17, 2016 at 7:06 PM, Khem Raj <raj.khem@gmail.com> 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
>>> <http://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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: Modifying SRC_URI from anonymous python
From: Richard Purdie @ 2016-11-17 23:06 UTC (permalink / raw)
To: Andre McCurdy, OE Core mailing list
In-Reply-To: <CAJ86T=U8RB13J_we2bte22bFQKwnahCe3v5L6na9SDPKm6O8bA@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Martin Jansa @ 2016-11-17 22:50 UTC (permalink / raw)
To: Fabio Berton; +Cc: openembedded-core
In-Reply-To: <1479396394-26134-1-git-send-email-fabio.berton@ossystems.com.br>
[-- Attachment #1: Type: text/plain, Size: 6818 bytes --]
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 <fabio.berton@ossystems.com.br>
> ---
> ...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 0000000..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 <fabio.berton@ossystems.com.br>
> +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 <fabio.berton@ossystems.com.br>
> +---
> + 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);
> + 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 0000000..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 <fabio.berton@ossystems.com.br>
> +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 <fabio.berton@ossystems.com.br>
> +---
> + 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;
> ++ bpf_u_int32 **alist;
> ++ int proto;
> ++ int dir;
> + {
> + struct block *b0, *b1, *tmp;
> +
> +@@ -6472,7 +6473,7 @@ gen_scode(compiler_state_t *cstate, const char *name, struct qual q)
> + alist = pcap_nametoaddr(name);
> + if (alist == NULL || *alist == NULL)
> + bpf_error(cstate, "unknown host '%s'", name);
> +- b = gen_gateway(eaddr, alist, proto, dir);
> ++ b = gen_gateway(cstate, eaddr, alist, proto, dir);
> + free(eaddr);
> + return b;
> + #else
> +--
> +2.1.4
> +
> diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.8.1.bb b/meta/recipes-connectivity/libpcap/libpcap_1.8.1.bb
> index 9072fe0..e9db28a 100644
> --- a/meta/recipes-connectivity/libpcap/libpcap_1.8.1.bb
> +++ b/meta/recipes-connectivity/libpcap/libpcap_1.8.1.bb
> @@ -2,6 +2,8 @@ require libpcap.inc
>
> SRC_URI += " \
> file://libpcap-pkgconfig-support.patch \
> + file://0001-Fix-compiler_state_t.ai-usage-when-INET6-is-not-defi.patch \
> + file://0002-Add-missing-compiler_state_t-parameter.patch \
> "
>
> SRC_URI[md5sum] = "3d48f9cd171ff12b0efd9134b52f1447"
> --
> 2.1.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* [PATCH V2] python3-setuptools: upgrade to 28.8.0
From: Edwin Plauchu @ 2016-11-17 22:32 UTC (permalink / raw)
To: openembedded-core
It is a simultaneous upgrade for python 2 and 3 over setuptools.
Signed-off-by: Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>
---
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
^ permalink raw reply related
* Re: [PATCH] apt-package: Include maintenance scripts
From: Aníbal Limón @ 2016-11-17 22:16 UTC (permalink / raw)
To: Linus Wallgren, openembedded-core
In-Reply-To: <20161116163315.18662-1-linus.wallgren@scypho.com>
[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]
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 <linus.wallgren@scypho.com>
> ---
> 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/
> }
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Modifying SRC_URI from anonymous python
From: Christopher Larson @ 2016-11-17 22:00 UTC (permalink / raw)
To: Andre McCurdy; +Cc: OE Core mailing list
In-Reply-To: <CAJ86T=U8RB13J_we2bte22bFQKwnahCe3v5L6na9SDPKm6O8bA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
On Thu, Nov 17, 2016 at 2:28 PM, Andre McCurdy <armccurdy@gmail.com> 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
[-- Attachment #2: Type: text/html, Size: 1576 bytes --]
^ permalink raw reply
* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Mark Hatle @ 2016-11-17 21:47 UTC (permalink / raw)
To: Burton, Ross, OE-core, openembedded-architecture
In-Reply-To: <CAJTo0LbvGwRpzxfOL0505w+Vz=Jhf6O3QOr5Z8SX9XaFqaZ7eg@mail.gmail.com>
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 <http://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-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
^ permalink raw reply
* Modifying SRC_URI from anonymous python
From: Andre McCurdy @ 2016-11-17 21:28 UTC (permalink / raw)
To: OE Core mailing list
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.
^ permalink raw reply
* [PATCH] busybox: enable fractional sleep arguments
From: Nathan Lynch @ 2016-11-17 20:49 UTC (permalink / raw)
To: openembedded-core
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}
text data 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 <nathan_lynch@mentor.com>
---
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
^ permalink raw reply related
* Re: Enabling uninative by default in oe-core?
From: Nicolas Dechesne @ 2016-11-17 18:56 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-architecture, OE-core
In-Reply-To: <4181f25d-a2bc-bb94-2b94-4d18ad654ab8@gmail.com>
On Thu, Nov 17, 2016 at 7:06 PM, Khem Raj <raj.khem@gmail.com> 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
>> <http://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..
^ permalink raw reply
* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Denys Dmytriyenko @ 2016-11-17 18:50 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-architecture, OE-core
In-Reply-To: <4181f25d-a2bc-bb94-2b94-4d18ad654ab8@gmail.com>
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
> > <http://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
^ permalink raw reply
* Re: [PATCH v2 1/3] module.bbclass: use Module.symvers for dependants
From: Denys Dmytriyenko @ 2016-11-17 18:47 UTC (permalink / raw)
To: André Draszik; +Cc: openembedded-core
In-Reply-To: <1479378138.27546.1.camel@andred.net>
On Thu, Nov 17, 2016 at 10:22:18AM +0000, 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
^ permalink raw reply
* Re: [PATCH] Test needed to verify postinst script order.
From: Pedraza Gonzalez, Francisco J @ 2016-11-17 18:20 UTC (permalink / raw)
To: Jose Perez Carranza, Burton, Ross; +Cc: OE-core
In-Reply-To: <358803d5-7678-9c6e-2017-9007263d02d5@linux.intel.com>
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.carranza@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 <francisco.j.pedraza.gonzalez@intel.com<mailto:francisco.j.pedraza.gonzalez@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.
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 <francisco.j.pedraza.gonzalez@intel.com<mailto:francisco.j.pedraza.gonzalez@intel.com>>
---
.../recipes-test/postinsta/postinsta_1.0.bb<http://postinsta_1.0.bb> | 20 +++++++++++
.../recipes-test/postinstb/postinstb_1.0.bb<http://postinstb_1.0.bb> | 22 ++++++++++++
.../recipes-test/postinstd/postinstd_1.0.bb<http://postinstd_1.0.bb> | 22 ++++++++++++
.../recipes-test/postinstp/postinstp_1.0.bb<http://postinstp_1.0.bb> | 22 ++++++++++++
.../recipes-test/postinstt/postinstt_1.0.bb<http://postinstt_1.0.bb> | 22 ++++++++++++
.../recipes-test/postinstz/postinstz_1.0.bb<http://postinstz_1.0.bb> | 12 +++++++
For clarity can all of these be squashed into a single recipe with clearer names?
Ross
^ permalink raw reply
* Re: Enabling uninative by default in oe-core?
From: Khem Raj @ 2016-11-17 18:06 UTC (permalink / raw)
To: Burton, Ross, OE-core, openembedded-architecture
In-Reply-To: <CAJTo0LbvGwRpzxfOL0505w+Vz=Jhf6O3QOr5Z8SX9XaFqaZ7eg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]
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
> <http://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
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Enabling uninative by default in oe-core?
From: Burton, Ross @ 2016-11-17 17:31 UTC (permalink / raw)
To: OE-core, openembedded-architecture
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1333 bytes --]
^ permalink raw reply
* Re: ✗ patchtest: failure for Fixes for eSDK and testsdkext
From: Paul Eggleton @ 2016-11-17 17:12 UTC (permalink / raw)
To: Burton, Ross; +Cc: Lock, Joshua G, OE-core
In-Reply-To: <CAJTo0LYTbP3h5T+YEMiESUCwq0YM6QXtj5+_nr0ZWMH1Z3mhNQ@mail.gmail.com>
On Thu, 17 Nov 2016 09:02:21 Burton, Ross wrote:
> On 17 November 2016 at 06:55, Patchwork <
>
> patchwork@patchwork.openembedded.org> wrote:
> > * Patch [7/8] oeqa/sdkext/devtool.py: skip
> > test_extend_autotools_recipe_creation when no libxml2
> >
> > Issue Commit shortlog is too long [test_shortlog_length]
> > Suggested fix Edit 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
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Christopher Larson @ 2016-11-17 16:24 UTC (permalink / raw)
To: Fabio Berton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAAPZna2dHKqh-rDSo6UGu0uP=CBLRHaGbhC-c=OisccQ4HUUsQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Thu, Nov 17, 2016 at 9:21 AM, Fabio Berton <fabio.berton@ossystems.com.br
> 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
[-- Attachment #2: Type: text/html, Size: 1189 bytes --]
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Fabio Berton @ 2016-11-17 16:21 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZAN=55DOHHy0fMJi6pPaR+TuwgwfErOd7YBAN=s_e9D0rwA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
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 <clarson@kergoth.com>
wrote:
>
> On Thu, Nov 17, 2016 at 9:11 AM, Fabio Berton <
> fabio.berton@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
>
[-- Attachment #2: Type: text/html, Size: 1703 bytes --]
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Christopher Larson @ 2016-11-17 16:15 UTC (permalink / raw)
To: Fabio Berton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAAPZna2pDLyq6PH6sb8c0J_Bxa2Pi+FNNZw_tVJ38o90mGsEJw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
On Thu, Nov 17, 2016 at 9:11 AM, Fabio Berton <fabio.berton@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
[-- Attachment #2: Type: text/html, Size: 1031 bytes --]
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Fabio Berton @ 2016-11-17 16:11 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANmh+pV4Xxwi2UY7fA+BctpVXRvM6gLcgMJEx-rwODMi4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
Hi Chistopher,
Patches in this commit have Upstream-Status: Submitted tag.
Thanks.
On Thu, Nov 17, 2016 at 2:00 PM, Christopher Larson <clarson@kergoth.com>
wrote:
>
> On Thu, Nov 17, 2016 at 8:26 AM, Fabio Berton <
> fabio.berton@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 <fabio.berton@ossystems.com.br>
>>
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 3155 bytes --]
^ permalink raw reply
* Re: [PATCH][RFC] classes: add gitupstream class
From: Burton, Ross @ 2016-11-17 16:07 UTC (permalink / raw)
To: OE-core
In-Reply-To: <1479397835-26630-1-git-send-email-ross.burton@intel.com>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On 17 November 2016 at 15:50, Ross Burton <ross.burton@intel.com> 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
[-- Attachment #2: Type: text/html, Size: 1036 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox