Re: [OE-core] [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

2019-03-14 Thread Khem Raj
On Wed, Mar 13, 2019 at 1:04 PM Mark Asselstine wrote: > > On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote: > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine > > > > wrote: > > > The cortexa7 tunings use 'cortexa7' in their tunings and do not > > > include 'arm7' so we need to

Re: [OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error

2019-03-14 Thread Khem Raj
On Thu, Mar 14, 2019 at 12:20 PM Joe Slater wrote: > > In tree234.c, change a while() loop to a for() loop so > that the compiler will realize we loop at least once. > > Signed-off-by: Joe Slater > --- > .../puzzles/files/fix-ki-uninitialized.patch | 25 > ++ >

Re: [OE-core] [PATCHv4 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-14 Thread Khem Raj
I have sent an alternative, please see if that works for you. I think that could be simpler On Thu, Mar 14, 2019 at 8:04 AM Peter Kjellerstedt wrote: > > This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c. > > This solution had unforeseen side effects, which, e.g., lead to the >

Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"

2019-03-14 Thread Khem Raj
On Mon, Mar 11, 2019 at 6:49 AM Peter Kjellerstedt wrote: > > > -Original Message- > > From: Khem Raj > > Sent: den 11 mars 2019 05:24 > > To: Peter Kjellerstedt > > Cc: OE Core (openembedded-core@lists.openembedded.org) > c...@lists.openembedded.org> > > Subject: Re: Can't build

[OE-core] [PATCH] arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches

2019-03-14 Thread Khem Raj
armv5 is not a specific tune feature anymore, there is no need to check it, since having dsp will define if 'e' should be added or not Signed-off-by: Khem Raj Cc: Peter Kjellerstedt --- meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [OE-core] [v2][PATCH 1/2] go.bbclass: Export GOARM

2019-03-14 Thread Khem Raj
On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine wrote: > > When building GO packages for ARM (v5, v6, v7) it is expected that the > GOARM env variable is set during the build. Not having GOARM exported > will result in GO binaries which can't be executed on the target > (terminate with segfault).

Re: [OE-core] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets

2019-03-14 Thread Andre McCurdy
On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine wrote: > > Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when > building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm() > does not account for the Cortex* TUNINGs and as such misses several > Cortex variants which

Re: [OE-core] [OE-Core][Thud][PATCH 1/3] lttng-ust: update to 2.10.3

2019-03-14 Thread akuster808
On 3/14/19 9:29 AM, Jonathan Rajotte-Julien wrote: >>> Disregard this series. It does not follow the project guideline regarding >>> recipe >>> update for stable release. >> There are exceptions when a package update is a bugfix only change. I >> know the kernel, openssl, bind, curl and a few

Re: [OE-core] [PATCH] libnss-nisplus: Add recipe

2019-03-14 Thread Khem Raj
On Thu, Mar 14, 2019 at 12:43 PM Ruslan Bilovol wrote: > Same as with libnss-nis - this will substitute > the glibc nisplus module which has been removed > > SRCREV points to 1.3 release plus patch on top which > allows to build with recent glibc versions This looks okay but not An Oe core

[OE-core] [PATCH] openssl: fix CVE-2019-1543

2019-03-14 Thread Ross Burton
Signed-off-by: Ross Burton --- .../openssl/openssl/CVE-2019-1543.patch| 69 ++ .../recipes-connectivity/openssl/openssl_1.1.1a.bb | 1 + 2 files changed, 70 insertions(+) create mode 100644 meta/recipes-connectivity/openssl/openssl/CVE-2019-1543.patch diff

[OE-core] [v2][PATCH 1/2] go.bbclass: Export GOARM

2019-03-14 Thread Mark Asselstine
When building GO packages for ARM (v5, v6, v7) it is expected that the GOARM env variable is set during the build. Not having GOARM exported will result in GO binaries which can't be executed on the target (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm We already have the

[OE-core] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets

2019-03-14 Thread Mark Asselstine
Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm() does not account for the Cortex* TUNINGs and as such misses several Cortex variants which implement ARMv7. Here we add an additional check that will include

[OE-core] [PATCH] libnss-nisplus: Add recipe

2019-03-14 Thread Ruslan Bilovol via Openembedded-core
Same as with libnss-nis - this will substitute the glibc nisplus module which has been removed SRCREV points to 1.3 release plus patch on top which allows to build with recent glibc versions Signed-off-by: Ruslan Bilovol --- .../libnss-nisplus/libnss-nisplus.bb | 31

Re: [OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error

2019-03-14 Thread Burton, Ross
Can we *please* start sending these upstream. It's not like the maintainer isn't responsive. Ross On Thu, 14 Mar 2019 at 19:20, Joe Slater wrote: > > In tree234.c, change a while() loop to a for() loop so > that the compiler will realize we loop at least once. > > Signed-off-by: Joe Slater >

[OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error

2019-03-14 Thread Joe Slater
In tree234.c, change a while() loop to a for() loop so that the compiler will realize we loop at least once. Signed-off-by: Joe Slater --- .../puzzles/files/fix-ki-uninitialized.patch | 25 ++ meta/recipes-sato/puzzles/puzzles_git.bb | 1 + 2 files changed,

Re: [OE-core] [PATCH 1/2] go.bbclass: Export GOARM

2019-03-14 Thread Mark Asselstine
On Thursday, March 14, 2019 2:44:35 PM EDT Christopher Larson wrote: > Good to know, thanks. Possibly something to improve in bitbake at some > point in the future. This is what I am preparing to send out --- GOARM[export] = "0" GOARM_arm_class-target = "${TARGET_GOARM}"

Re: [OE-core] [PATCH 1/2] go.bbclass: Export GOARM

2019-03-14 Thread Christopher Larson
Good to know, thanks. Possibly something to improve in bitbake at some point in the future. On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine < mark.asselst...@windriver.com> wrote: > On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote: > > How would bitbake respond to an

Re: [OE-core] [PATCH 1/2] go.bbclass: Export GOARM

2019-03-14 Thread Mark Asselstine
On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote: > How would bitbake respond to an ‘export’ line with the empty string? I.e. > can you do an actual conditional export the way we do conditional inherits, > so it still is only exported for arm, even if the value is set to the

Re: [OE-core] [OE-Core][Thud][PATCH 1/3] lttng-ust: update to 2.10.3

2019-03-14 Thread Jonathan Rajotte-Julien
> > Disregard this series. It does not follow the project guideline regarding > > recipe > > update for stable release. > There are exceptions when a package update is a bugfix only change. I > know the kernel, openssl, bind, curl and a few others fall into that > category. Many minor version

[OE-core] [sumo][PATCH] coreutils: 8.29: fix native build

2019-03-14 Thread Stefan Müller-Klieser
This fixes the native build on glibc 2.28 hosts, by backporting two gnulib patches from master. Signed-off-by: Stefan Müller-Klieser --- ...adjust-to-glibc-2.28-libio.h-removal.patch | 193 ++ ...e-more-paranoid-about-libio.h-change.patch | 187 +

Re: [OE-core] [OE-Core][Thud][PATCH 1/3] lttng-ust: update to 2.10.3

2019-03-14 Thread akuster808
Jonathan, On 3/13/19 3:47 PM, Jonathan Rajotte-Julien wrote: > Hi, > > Disregard this series. It does not follow the project guideline regarding > recipe > update for stable release. There are exceptions when a package update is a bugfix only change. I know the kernel, openssl, bind, curl and a

[OE-core] [PATCH] networkmanager: Use ALTERNATIVES for resolv-conf handling.

2019-03-14 Thread drew . moseley
From: Drew Moseley This brings the networkmanager in sync with how systemd-resolved and connman work. Additionally this allows it to function with a read-only rootFS. Signed-off-by: Drew Moseley --- .../networkmanager/networkmanager_1.14.4.bb | 12 +++- 1 file

[OE-core] [PATCHv4 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-14 Thread Peter Kjellerstedt
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c. This solution had unforeseen side effects, which, e.g., lead to the following sanity error if trying to build with the arm926ejs default tune: Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5 armv5t

[OE-core] [PATCHv4 2/2] arm-tunes: Prefer the -mcpu option over -march

2019-03-14 Thread Peter Kjellerstedt
Tune files that inherit the arch definitions already define appropriate -mcpu options, which are equivalent of the correct -march and -mtune combinations. This is preferred since gcc is getting stricter and stricter with option check semantics and can now find incompatible -march and -mcpu options

[OE-core] [PATCH] zlib: cleanup

2019-03-14 Thread Ross Burton
Drop remove.ldconfig.call.patch, as it's easier to just set LDCONFIG=true. Pass uname=GNU via the documented configure option instead of undocumented environment variable. Rename zlib-1.2.11/ to just zlib/ as we don't ship multiple versions. Send ldflags-tests.patch upstream and update

[OE-core] [PATCH] devtool sdk-update: unconditionally append updateserver to sstate mirrors

2019-03-14 Thread Jaewon Lee
The code in sdk.py which checks if SSTATE_MIRRORS is set before appending the updateserver to SSTATE_MIRRORS was written before it was being set in the eSDK's local.conf (OE-Core commit 6b9e8b780dcd8d5ffba3df35cfe41674413ee26d). Unconditionally appending updateserver to SSTATE_MIRRORS as this is