[OE-core] [PATCH 1/1] trace-cmd: fix QA warning

[Dengke Du]

Add PACKAGECONFIG for audit.

Signed-off-by: Dengke Du 
---
 meta/recipes-kernel/trace-cmd/trace-cmd_git.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/trace-cmd/trace-cmd_git.bb 
b/meta/recipes-kernel/trace-cmd/trace-cmd_git.bb
index dd9a8a0..05f5f9a 100644
--- a/meta/recipes-kernel/trace-cmd/trace-cmd_git.bb
+++ b/meta/recipes-kernel/trace-cmd/trace-cmd_git.bb
@@ -9,6 +9,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
 
file://trace-input.c;beginline=5;endline=8;md5=3ec82f43bbe0cfb5951ff414ef4d44d0 
\
 "
 
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[audit] = ",,audit"
+
 EXTRA_OEMAKE = "\
 'prefix=${prefix}' \
 'bindir=${bindir}' \
@@ -20,6 +23,7 @@ EXTRA_OEMAKE = "\
 'libdir=${@oe.path.relative(prefix, libdir)}' \
 \
 NO_PYTHON=1 \
+${@bb.utils.contains('PACKAGECONFIG', 'audit', '', 'NO_AUDIT=1', d)} \
 "
 
 do_compile_prepend() {
-- 
2.7.4

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

[OE-core] [PATCH 0/1] trace-cmd: fix QA warning

[Dengke Du]

The following changes since commit c3d2df883a9d6d5036277114339673656d89a728:

  oeqa/selftest/kernel.py: Add new file destined for kernel related tests 
(2016-11-01 10:05:46 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib 
dengke/fix-trace_cmd-QA-warning
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=dengke/fix-trace_cmd-QA-warning

Dengke Du (1):
  trace-cmd: fix QA warning

 meta/recipes-kernel/trace-cmd/trace-cmd_git.bb | 4 
 1 file changed, 4 insertions(+)

-- 
2.7.4

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

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

[Phil Blundell]

On Fri, 2016-11-04 at 23:24 +, Burton, Ross wrote:
> > No, I checked the files in /usr on the host, as this is a native
build it should be linking against the host libc.
> 
> $ grep -r getrandom
> x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
> x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
> x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
> 
> 
> Yes, looks like Debian headers are a bit broken.
> 
> 
> 

That would happen if your glibc was compiled against a newer version of
the kernel headers than you actually have installed (bits/syscall.h is
auto-generated from the kernel headers at build time). If this is a
clean Debian install then it does sound like they have messed up the
packaging somehow.

p.

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Phil Blundell]

On Fri, 2016-11-04 at 16:55 -0700, Khem Raj wrote:
> 
> yes I meant <= v5, it should work usually, I am just thinking its a
> untested
> option, it may not be as bad as I think but some testing might be
> useful

Well, I admit I haven't looked at the actual code, but from the
comments in the patch I get the impression that it just causes db to
use the same code (i.e. pthread_mutex_xx) on ARM as it already was
doing on every other architecture.  I think it's safe to say that
pthread_mutex_lock() on ARM probably does work, otherwise any number of
programs would be broken, and db probably does work with
pthread_mutex_lock generically otherwise it would be broken on x86 and
so on.

You're right of course that this specific combination could do with
some testing but all in all it seems like a fairly low-risk change.

p.

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

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

[Khem Raj]

On 10/20/16 4:05 AM, Burton, Ross wrote:
> 
> On 20 October 2016 at 09:30, Koen Kooi  > wrote:
> 
> +BBCLASSEXTEND = "native nativesdk"
> 
> 
> The native form fails on Debian stable hosts:
> 
> | make[2]: Entering directory
> '/data/poky-master/tmp-glibc/work/x86_64-linux/libbsd-native/0.8.3-r0/build/src'
> | ../x86_64-linux-libtool  --tag=CC   --mode=compile gcc  -DHAVE_CONFIG_H  
> -I.. -isystem ../../libbsd-0.8.3/include/bsd/ -include ../config.h
> -DLIBBSD_OVERLAY -DLIBBSD_DISABLE_DEPRECATED -D__REENTRANT
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include
>  -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
> -pipe -c -o getentropy.lo ../../libbsd-0.8.3/src/getentropy.c
> | x86_64-linux-libtool: compile:  gcc -DHAVE_CONFIG_H -I.. -isystem
> ../../libbsd-0.8.3/include/bsd/ -include ../config.h -DLIBBSD_OVERLAY
> -DLIBBSD_DISABLE_DEPRECATED -D__REENTRANT
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
> -pipe -c ../../libbsd-0.8.3/src/getentropy.c  -fPIC -DPIC -o 
> .libs/getentropy.o
> | In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0,
> |  from ../../libbsd-0.8.3/src/getentropy_linux.c:29,
> |  from ../../libbsd-0.8.3/src/getentropy.c:28:
> | ../../libbsd-0.8.3/src/getentropy_linux.c: In function 
> ‘getentropy_getrandom’:
> | ../../libbsd-0.8.3/src/getentropy_linux.c:203:17: error: ‘__NR_getrandom’
> undeclared (first use in this function)
> |ret = syscall(SYS_getrandom, buf, len, 0);
> |  ^
> | ../../libbsd-0.8.3/src/getentropy_linux.c:203:17: note: each undeclared
> identifier is reported only once for each function it appears in
> 
> It's not wrong - there's no actual definition of __NR_getrandom in
> /usr/include here.


Do you have libbsd pre-installed on your build system ?

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Khem Raj]

Phil

On 11/4/16 4:14 PM, Phil Blundell wrote:
> On Fri, 2016-11-04 at 11:22 -0700, Khem Raj wrote:
>>
>>
>> On 11/4/16 2:07 AM, Li Zhou wrote:
>>>
>>> The swpb in macro MUTEX_SET will cause "undefined instruction"
>>> error
>>> on the new arm arches which don't support this assembly instruction
>>> any more. If use ldrex/strex to replace swpb, the old arm arches
>>> don't
>>> support them. So to avoid this issue, just disable the ARM
>>> assembler
>>> mutex code, and use the default pthreads mutex.
>>>
> 
>> it would be good to keep this for older < armv5 arches
> 
> I guess you meant "<= ARMv5".  STREX etc were introduced in ARMv6, so
> ARMv5 (and ARMv5TE) don't have it.  But in any case, won't the default
> libpthread mutex work just fine on those older architectures?  There is
> no SMP on anything before ARMv6 anyway so lock contention will be
> relatively low, and it seems fairly unlikely that anybody has a real-
> world application which uses db so heavily that the mutex
> implementation will have any noticeable performance impact.

yes I meant <= v5, it should work usually, I am just thinking its a untested
option, it may not be as bad as I think but some testing might be useful

> 
> And, given that it's now something like 15 years since support for
> STREX was introduced in ARMv6, and more than 10 years since support for
> SWP was deleted in ARMv7, it doesn't seem entirely unreasonable for oe-
> core to pick the newer paradigm as the case to optimise for.  Distros
> that want to target ARMv5 or older are obviously free to do so and they
> can carry the SWP patch locally if they want to.  But as far as oe-core 
> itself is concerned, at this point it seems like it's just scar tissue.

yeah agree here.

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

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

[Nicolas Dechesne]

On Sat, Nov 5, 2016 at 12:24 AM, Burton, Ross  wrote:
> On 4 November 2016 at 21:25, Nicolas Dechesne 
> wrote:
>>
>> So in order to get the build error you are seeing, that means that
>> SYS_getrandom is define to NR_getrandom (in syscall.h), but that
>> NR_getrandom is not set to the right syscall ID. That makes it quite
>> inconsistent.. could we be mixing HOST and sysroot content here?
>
>
> No, I checked the files in /usr on the host, as this is a native build it
> should be linking against the host libc.
>
> $ grep -r getrandom
> x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
> x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
> x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
>
> Yes, looks like Debian headers are a bit broken.

hmm. not for me...

root@nikaia:/usr/include# grep getrandom
/usr/include/x86_64-linux-gnu/bits/syscall.h

root@nikaia:/usr/include# dpkg -S /usr/include/x86_64-linux-gnu/bits/syscall.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/syscall.h

root@nikaia:/usr/include# dpkg -l | grep libc6-dev
ii  libc6-dev:amd642.19-18+deb8u6   amd64
  GNU C Library: Development Libraries and Header Files

this is from a fresh jessie debootstrap
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Burton, Ross]

On 4 November 2016 at 21:25, Nicolas Dechesne 
wrote:

> So in order to get the build error you are seeing, that means that
> SYS_getrandom is define to NR_getrandom (in syscall.h), but that
> NR_getrandom is not set to the right syscall ID. That makes it quite
> inconsistent.. could we be mixing HOST and sysroot content here?
>

No, I checked the files in /usr on the host, as this is a native build it
should be linking against the host libc.

$ grep -r getrandom
x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom
x86_64-linux-gnu/bits/syscall.h:#define SYS_getrandom __NR_getrandom

Yes, looks like Debian headers are a bit broken.

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Phil Blundell]

On Fri, 2016-11-04 at 11:22 -0700, Khem Raj wrote:
> 
> 
> On 11/4/16 2:07 AM, Li Zhou wrote:
> > 
> > The swpb in macro MUTEX_SET will cause "undefined instruction"
> > error
> > on the new arm arches which don't support this assembly instruction
> > any more. If use ldrex/strex to replace swpb, the old arm arches
> > don't
> > support them. So to avoid this issue, just disable the ARM
> > assembler
> > mutex code, and use the default pthreads mutex.
> > 

> it would be good to keep this for older < armv5 arches

I guess you meant "<= ARMv5".  STREX etc were introduced in ARMv6, so
ARMv5 (and ARMv5TE) don't have it.  But in any case, won't the default
libpthread mutex work just fine on those older architectures?  There is
no SMP on anything before ARMv6 anyway so lock contention will be
relatively low, and it seems fairly unlikely that anybody has a real-
world application which uses db so heavily that the mutex
implementation will have any noticeable performance impact.

And, given that it's now something like 15 years since support for
STREX was introduced in ARMv6, and more than 10 years since support for
SWP was deleted in ARMv7, it doesn't seem entirely unreasonable for oe-
core to pick the newer paradigm as the case to optimise for.  Distros
that want to target ARMv5 or older are obviously free to do so and they
can carry the SWP patch locally if they want to.  But as far as oe-core 
itself is concerned, at this point it seems like it's just scar tissue.

p.

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Khem Raj]

Not sure the atomics in newer  compiler and libc has ever been tested in
this version of db

On Nov 4, 2016 1:29 PM, "Burton, Ross"  wrote:


On 4 November 2016 at 18:22, Khem Raj  wrote:

> it would be good to keep this for older < armv5 arches
>

Doesn't the C library support its own atomics for those?

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

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

[Nicolas Dechesne]

On Thu, Oct 20, 2016 at 1:05 PM, Burton, Ross  wrote:
> On 20 October 2016 at 09:30, Koen Kooi  wrote:
>>
>> +BBCLASSEXTEND = "native nativesdk"
>
>
> The native form fails on Debian stable hosts:
>
> | make[2]: Entering directory
> '/data/poky-master/tmp-glibc/work/x86_64-linux/libbsd-native/0.8.3-r0/build/src'
> | ../x86_64-linux-libtool  --tag=CC   --mode=compile gcc  -DHAVE_CONFIG_H
> -I.. -isystem ../../libbsd-0.8.3/include/bsd/ -include ../config.h
> -DLIBBSD_OVERLAY -DLIBBSD_DISABLE_DEPRECATED -D__REENTRANT
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
> -pipe -c -o getentropy.lo ../../libbsd-0.8.3/src/getentropy.c
> | x86_64-linux-libtool: compile:  gcc -DHAVE_CONFIG_H -I.. -isystem
> ../../libbsd-0.8.3/include/bsd/ -include ../config.h -DLIBBSD_OVERLAY
> -DLIBBSD_DISABLE_DEPRECATED -D__REENTRANT
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include
> -isystem/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/include -O2
> -pipe -c ../../libbsd-0.8.3/src/getentropy.c  -fPIC -DPIC -o
> .libs/getentropy.o
> | In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0,
> |  from ../../libbsd-0.8.3/src/getentropy_linux.c:29,
> |  from ../../libbsd-0.8.3/src/getentropy.c:28:
> | ../../libbsd-0.8.3/src/getentropy_linux.c: In function
> ‘getentropy_getrandom’:
> | ../../libbsd-0.8.3/src/getentropy_linux.c:203:17: error: ‘__NR_getrandom’
> undeclared (first use in this function)
> |ret = syscall(SYS_getrandom, buf, len, 0);
> |  ^
> | ../../libbsd-0.8.3/src/getentropy_linux.c:203:17: note: each undeclared
> identifier is reported only once for each function it appears in
>
> It's not wrong - there's no actual definition of __NR_getrandom in
> /usr/include here.

hmm. that's odd. libbsd is supposed to work with system that have this
syscall, and with system without it. in the upstream source code, they
properly do it like this:

#ifdef SYS_getrandom
static int
getentropy_getrandom(void *buf, size_t len)
{
int pre_errno = errno;
int ret;
if (len > 256)
return (-1);
do {
ret = syscall(SYS_getrandom, buf, len, 0);
<...>
#endif

So in order to get the build error you are seeing, that means that
SYS_getrandom is define to NR_getrandom (in syscall.h), but that
NR_getrandom is not set to the right syscall ID. That makes it quite
inconsistent.. could we be mixing HOST and sysroot content here?

I don't have a debian stable system handy right now, i will have to setup one.

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

Re: [OE-core] [PATCH 0/2] Time zone update to 2016i

[Burton, Ross]

On 4 November 2016 at 16:04, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> git pw mbox 3757 -r 1 | git apply --check
> error: meta/recipes-extended/tzcode/tzcode-native_2016h.bb: No such file
> or directory
> error: meta/recipes-extended/tzdata/tzdata_2016h.bb: No such file or
> directory
>

It depends on the update to 2016h that Armin sent earlier but isn't yet in
master.

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Burton, Ross]

On 4 November 2016 at 18:22, Khem Raj  wrote:

> it would be good to keep this for older < armv5 arches
>

Doesn't the C library support its own atomics for those?

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

[OE-core] [PATCH] distro_check: MeeGo is long dead, compare against Clear Linux instead

[Ross Burton]

Instead of checking against a file that represents a distribution that hasn't
existed for years, fetch package names for Clear Linux instead.

[ YOCTO #10601 ]

Signed-off-by: Ross Burton 
---
 meta/lib/oe/distro_check.py | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index 00c827e..c666ddc 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -43,15 +43,6 @@ def package_name_from_srpm(srpm):
 (name, version, release) = srpm.replace(".src.rpm", "").rsplit("-", 2)
 return name
 
-def get_latest_released_meego_source_package_list(d):
-"Returns list of all the name os packages in the latest meego distro"
-
-package_names = set()
-with open("/tmp/Meego-1.1", "r") as f:
-for line in f:
-package_names.add(line.strip() + ":" + "main")
-return "1.1", package_names
-
 def get_source_package_list_from_url(url, section, d):
 "Return a sectioned list of package names from a URL list"
 
@@ -99,6 +90,11 @@ def get_latest_released_mandriva_source_package_list(d):
 package_names |= 
get_source_package_list_from_url("http://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/official/%s/SRPMS/main/updates/";
 % latest, "updates", d)
 return latest, package_names
 
+def get_latest_released_clear_source_package_list(d):
+latest = 
find_latest_numeric_release("https://download.clearlinux.org/releases/";, d)
+package_names = 
get_source_package_list_from_url("https://download.clearlinux.org/releases/%s/clear/source/SRPMS/";
 % latest, "main", d)
+return latest, package_names
+
 def find_latest_debian_release(url, d):
 "Find the latest listed debian release on the given url"
 
@@ -167,7 +163,7 @@ def create_distro_packages_list(distro_check_dir, d):
 ("Fedora", 
get_latest_released_fedora_source_package_list),
 ("OpenSuSE", 
get_latest_released_opensuse_source_package_list),
 ("Mandriva", 
get_latest_released_mandriva_source_package_list),
-("Meego", 
get_latest_released_meego_source_package_list)
+("Clear", 
get_latest_released_clear_source_package_list),
)
 
 for name, fetcher_func in per_distro_functions:
-- 
2.8.1

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Khem Raj]

On 11/4/16 2:07 AM, Li Zhou wrote:
> The swpb in macro MUTEX_SET will cause "undefined instruction" error
> on the new arm arches which don't support this assembly instruction
> any more. If use ldrex/strex to replace swpb, the old arm arches don't
> support them. So to avoid this issue, just disable the ARM assembler
> mutex code, and use the default pthreads mutex.
> 
> Signed-off-by: Li Zhou 
> ---
>  meta/recipes-support/db/db_6.0.30.bb | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/meta/recipes-support/db/db_6.0.30.bb 
> b/meta/recipes-support/db/db_6.0.30.bb
> index 50a469b..2d08b5e 100644
> --- a/meta/recipes-support/db/db_6.0.30.bb
> +++ b/meta/recipes-support/db/db_6.0.30.bb
> @@ -74,15 +74,6 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
> --disable-queue --disabl
>  
>  EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
>  
> -# Override the MUTEX setting here, the POSIX library is
> -# the default - "POSIX/pthreads/library".
> -# Don't ignore the nice SWP instruction on the ARM:
> -# These enable the ARM assembler mutex code
> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
> -MUTEX = ""
> -MUTEX_arm = "${ARM_MUTEX}"
> -MUTEX_armeb = "${ARM_MUTEX}"
> -EXTRA_OECONF += "${MUTEX}"

it would be good to keep this for older < armv5 arches

>  EXTRA_OEMAKE_class-target = 
> "LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
>  
>  # Cancel the site stuff - it's set for db3 and destroys the
> 



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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Mark Hatle]

On 11/4/16 11:12 AM, Leonardo Sandoval wrote:
> This patch cannot be applied because the modified file is not track by 
> oe-core.
> 

The original submitted should have mentioned this patch is against Jethro.
However the patch is directly applicable to master, morty and korgoth as well.

Li, please rebase this against master and then ask for it to be backported to
the others.

--Mark

> On 11/04/2016 03:07 AM, Li Zhou wrote:
>> The swpb in macro MUTEX_SET will cause "undefined instruction" error
>> on the new arm arches which don't support this assembly instruction
>> any more. If use ldrex/strex to replace swpb, the old arm arches don't
>> support them. So to avoid this issue, just disable the ARM assembler
>> mutex code, and use the default pthreads mutex.
>>
>> Signed-off-by: Li Zhou 
>> ---
>>   meta/recipes-support/db/db_6.0.30.bb | 9 -
>>   1 file changed, 9 deletions(-)
>>
>> diff --git a/meta/recipes-support/db/db_6.0.30.bb 
>> b/meta/recipes-support/db/db_6.0.30.bb
>> index 50a469b..2d08b5e 100644
>> --- a/meta/recipes-support/db/db_6.0.30.bb
>> +++ b/meta/recipes-support/db/db_6.0.30.bb
>> @@ -74,15 +74,6 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
>> --disable-queue --disabl
>>   
>>   EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
>>   
>> -# Override the MUTEX setting here, the POSIX library is
>> -# the default - "POSIX/pthreads/library".
>> -# Don't ignore the nice SWP instruction on the ARM:
>> -# These enable the ARM assembler mutex code
>> -ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
>> -MUTEX = ""
>> -MUTEX_arm = "${ARM_MUTEX}"
>> -MUTEX_armeb = "${ARM_MUTEX}"
>> -EXTRA_OECONF += "${MUTEX}"
>>   EXTRA_OEMAKE_class-target = 
>> "LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
>>   
>>   # Cancel the site stuff - it's set for db3 and destroys the
> 

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

[OE-core] Yocto Project Status WW45 - UPDATED

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M1

Next Deadline: YP 2.3 M1 by Dec. 12, 2016


SWAT team rotation: Ross -> Randy

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*2.2 was released!

*Patches are starting to be merged into master

*We are intending to have point releases for 2.0 and 2.1, this is 
dependent on good build test results.

*We are having various issues with the new autobuilder so it is still 
not in production use yet.

*There was a challenging taskhash mismatch test case this week which 
has resulted in some significant debugging improvements for taskhashes and 
basehashes which are now in master.

*2.3 planning is underway and RP will send more thoughts on the plans 
for that in the next couple of weeks.

*We are going to make a strong effort to load balance things up front 
this time so work is spread over M1-3 rather than the usual 'front loaded' 
everything in M1 approach which is currently how bugzilla looks.


Proposed upcoming dot releases:

YP 2.0.3 Release by Nov. 18, 2016

YP 2.1.2 Release by Dec. 9, 2016

YP 2.2.1 Release by Jan. 20, 2017


Key YP 2.3 Dates:

YP 2.3 M1 Cutoff is Dec. 12, 2016

YP 2.3 M1 Release is Dec. 23, 2016

YP 2.3 M2 Cutoff is Jan. 23, 2017

YP 2.3 M2 Release is Feb. 3, 2017

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 3, 2017

YP 2.3 M4 Release is April 28, 2017


Tracking Metrics:

WDD 2422 (last week 2394)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

Re: [OE-core] ✗ patchtest: failure for u-boot: mkimage: fix build

[Leonardo Sandoval]

This is another false positive that has been fixed. Submitted is a valid 
status.



On 11/04/2016 05:25 AM, Patchwork wrote:

== Series Details ==

Series: u-boot: mkimage: fix build
URL   : https://patchwork.openembedded.org/series/3768/
State : failure

== Summary ==

Thank you for your patch submission of the following patch series to 
OpenEmbedded Core-.
this is an automated response. Several tests have been executed on the proposed
series (series 3768, revision 1) by patchtest and the following have failed:


Test Nametest_upstream_status_format
Proposed Fix Fix Upstream-Status format
Required format  Upstream-Status: 
Possible Status  Pending, Accepted, Backport, Denied, Inappropriate
Line Upstream-Status: Submitted
Column   18


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

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



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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Leonardo Sandoval]

This patch cannot be applied because the modified file is not track by 
oe-core.



On 11/04/2016 03:07 AM, Li Zhou wrote:

The swpb in macro MUTEX_SET will cause "undefined instruction" error
on the new arm arches which don't support this assembly instruction
any more. If use ldrex/strex to replace swpb, the old arm arches don't
support them. So to avoid this issue, just disable the ARM assembler
mutex code, and use the default pthreads mutex.

Signed-off-by: Li Zhou 
---
  meta/recipes-support/db/db_6.0.30.bb | 9 -
  1 file changed, 9 deletions(-)

diff --git a/meta/recipes-support/db/db_6.0.30.bb 
b/meta/recipes-support/db/db_6.0.30.bb
index 50a469b..2d08b5e 100644
--- a/meta/recipes-support/db/db_6.0.30.bb
+++ b/meta/recipes-support/db/db_6.0.30.bb
@@ -74,15 +74,6 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
--disable-queue --disabl
  
  EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
  
-# Override the MUTEX setting here, the POSIX library is

-# the default - "POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX}"
  EXTRA_OEMAKE_class-target = 
"LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
  
  # Cancel the site stuff - it's set for db3 and destroys the


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

Re: [OE-core] [PATCH 0/2] Time zone update to 2016i

[Leonardo Sandoval]

Armin, I am trying to patch your series but I get this error:

git pw mbox 3757 -r 1 | git apply --check
error: meta/recipes-extended/tzcode/tzcode-native_2016h.bb: No such file 
or directory
error: meta/recipes-extended/tzdata/tzdata_2016h.bb: No such file or 
directory



BTW, 3757 is the series ID located at patchwork instance.

On 11/03/2016 11:53 PM, Armin Kuster wrote:

These applied on top of 2016h I sent on 10-23

Armin Kuster (2):
   tzcode: update to 2016i
   tzdata: update to 2016i

  .../tzcode/{tzcode-native_2016h.bb => tzcode-native_2016i.bb} | 8 
  meta/recipes-extended/tzdata/{tzdata_2016h.bb => tzdata_2016i.bb} | 4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)
  rename meta/recipes-extended/tzcode/{tzcode-native_2016h.bb => 
tzcode-native_2016i.bb} (69%)
  rename meta/recipes-extended/tzdata/{tzdata_2016h.bb => tzdata_2016i.bb} (98%)



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

[OE-core] Yocto Project Status WW45

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M1

Next Deadline: YP 2.3 M1 by Dec. 12, 2016


SWAT team rotation: Ross -> Randy

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*2.2 was released!

*Patches are starting to be merged into master

*We are intending to have point releases for 2.0 and 2.1, this is 
dependent on good build test results.

*We are having various issues with the new autobuilder so it is still 
not in production use yet.

*There was a challenging taskhash mismatch test case this week which 
has resulted in some significant debugging improvements for taskhashes and 
basehashes which are now in master.

*2.3 planning is underway and RP will send more thoughts on the plans 
for that in the next couple of weeks.

*We are going to make a strong effort to load balance things up front 
this time so work is spread over M1-3 rather than the usual 'front loaded' 
everything in M1 approach which is currently how bugzilla looks.


Proposed upcoming dot releases:

YP 2.0.3 Release by Nov. 18, 2016

YP 2.1.2 Release by Dec. 9, 2016

YP 2.2.1 Release by Jan. 20, 2017


Key YP 2.3 Dates:

YP 2.3 M1 Cutoff is Dec. 12, 2016

YP 2.3 M1 Release is Dec. 23, 2016

YP 2.3 M2 Cutoff is Jan. 23, 2017

YP 2.3 M2 Release is Feb. 3, 2017

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.4 M4 Cutoff is April 3, 2017

YP 2.4 M4 Release is April 28, 2017


Tracking Metrics:

WDD 2422 (last week 2394)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

Re: [OE-core] using devtool for rebasing patches

[Alexander Kanavin]

On 11/03/2016 09:29 PM, Paul Eggleton wrote:


"devtool upgrade" is designed specifically to handle the upgrade case and
tries to rebase the old patches onto the new version, putting you into
resolution mode with "git am" if it fails to apply a patch. I appreciate that
you may now be working through sorting out all of the patches to reduce the
fuzziness when applying, and that won't help in that scenario, but it would
definitely be worth considering for upgrades.


Fair enough, although I was not aware of this feature of devtool until 
now, despite being a major contributor of package upgrades to oe-core :) 
We have had a miscommunication issue, it seems.



I'm open to implementing better support for handling patch application failure
for devtool modify - in fact there is a bug open for just that:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325


THanks, I just wrote a comment there, and made the patch fuzz bug depend 
on this one :)


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

Re: [OE-core] [PATCH]] libpcap: Update to version 1.8.1

[Burton, Ross]

On 4 November 2016 at 12:12, Fabio Berton 
wrote:

>   - Update patches libpcap.inc and aclocal.patch to work with version
> 1.8.1.
>

This is legacy and aclocal.patch can be removed, we're improved the
autotools class and you can now stop aclocal from running at all.

Add EXTRA_AUTORECONF += "--exclude=aclocal" to the libpcap.inc and then you
can remove both aclocal.patch and the copying of aclocal.m4 to acinclude.m4.

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

[OE-core] [PATCH 1/1] run-postinsts: Use opkg/dpkg to configure when possible

[Jussi Kukkonen]

Currently run-postinsts script has code to run postinst scripts
via opkg/dpkg configure but that code is never used. The advantage
of using package managers instead of just executing the scripts is
to keep the package manager DB updated.

Fix the script so that the package managers are used when appropriate.
Also use $localstatedir for the opkg runtime file location.

Fixes [YOCTO #10478].

Signed-off-by: Jussi Kukkonen 
---
 .../recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts 
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index 04ba394..10f2118 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -16,23 +16,25 @@ pm_installed=false
 for pm in $backend_list; do
pi_dir="#SYSCONFDIR#/$pm-postinsts"
 
-   [ -d $pi_dir ] && break
+   if [ ! -d $pi_dir ]; then
+   continue
+   fi
 
+   # found the package manager, it has postinsts
case $pm in
"deb")
if [ -s "#LOCALSTATEDIR#/lib/dpkg/status" ]; then
pm_installed=true
-   break
fi
;;
 
"ipk")
-   if [ -s "/var/lib/opkg/status" ]; then
+   if [ -s "#LOCALSTATEDIR#/lib/opkg/status" ]; then
pm_installed=true
-   break
fi
;;
esac
+   break
 done
 
 remove_rcsd_link () {
-- 
2.1.4

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

[OE-core] [PATCH 0/1] run-postinsts: Use opkg/dpkg to configure when possible

[Jussi Kukkonen]

run-postinst has not been using package managers to configure the
packages: the code was there all along but a bug prevented it from
being used.

I was hesitating sending this a bit as it felt quite difficult to test
comprehensively and the change is not completely trivial: as an example
the order of postinsts will likely change as it's now handled by the
package manager instead of OE. I can still run more tests if anyone
has good ideas...



Cheers, 
  Jussi


The following changes since commit c3d2df883a9d6d5036277114339673656d89a728:

  oeqa/selftest/kernel.py: Add new file destined for kernel related tests 
(2016-11-01 10:05:46 +)

are available in the git repository at:

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

Jussi Kukkonen (1):
  run-postinsts: Use opkg/dpkg to configure when possible

 .../recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
2.1.4

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

[OE-core] trying to build rpm with perl bindings

[Robert P. J. Day]

  for my qemuppc target, i wanted to add perl bindings to the target
"rpm" command, so i checked the "rpm_5.4.16.bb" recipe file to find:

  # Perl modules are not built, but they could be enabled fairly easily
  # the perl module creation and installation would need to be patched.
  # (currently has host perl contamination issues)
  WITH_PERL = "--with-perl --without-perlembed --without-perl-urpm"
  WITHOUT_PERL = "--without-perl --without-perl-urpm"
  PACKAGECONFIG[perl] = "${WITH_PERL},${WITHOUT_PERL},perl,"

um ... ok, no idea what the issue is here but what the heck, let's
just try it and see what happens, so added:

  PACKAGECONFIG_append_pn-rpm = " perl"

to "local.conf", ran "bitbake rpm" and eventually got:

| Making all in perl
| make[2]: Entering directory
'/home/rpjday/oe/builds/msm_qemuppc/tmp/work/ppc7400-poky-linux/rpm/5.4.16-r0/build/perl'
| /usr/bin/perl Makefile.PL CC="powerpc-poky-linux-gcc  -m32
-mhard-float -mcpu=7400 -mno-spe
--sysroot=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc"
MAKEFILE=Makefile.perl
| Bareword found where operator expected at Makefile.PL line 71, near
"--sysroot"
|   (Missing operator before sysroot?)
| Can't modify constant item in postdecrement (--) at Makefile.PL line
71, near "spe --"
| syntax error at Makefile.PL line 71, near "--sysroot"
... snip ...

 . so i open build/perl/Makefile.PL and, sure enough, down at line
71:

  WriteMakefile(
'NAME'  => 'RPM',
'OBJECT'=> join(' ', @objects),
'VERSION' => '5.4.16',
'MAKEFILE'=> 'Makefile.perl',
'CC'  => powerpc-poky-linux-gcc  -m32 -mhard-float -mcpu=7400 
-mno-spe
  --sysroot=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc,
... snip ...

doesn't that 'CC' line also need quotes around the value being
assigned? that seems to be a fairly blatant error, no? or am i
misreading something?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday




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

[OE-core] [PATCH]] libpcap: Update to version 1.8.1

[Fabio Berton]

  - Update patches libpcap.inc and aclocal.patch to work with version 1.8.1.
  - Option --enable-canusb was removed on commit:

https://github.com/the-tcpdump-group/libpcap/commit/93ca5ff7030aaf1219e1de05ec89a68384bfc50b

Signed-off-by: Fabio Berton 
---
 meta/recipes-connectivity/libpcap/libpcap.inc  |   1 -
 .../libpcap/libpcap/aclocal.patch  | 119 +++--
 .../libpcap/libpcap-pkgconfig-support.patch|  32 +++---
 .../libpcap/{libpcap_1.7.4.bb => libpcap_1.8.1.bb} |   6 +-
 4 files changed, 105 insertions(+), 53 deletions(-)
 rename meta/recipes-connectivity/libpcap/{libpcap_1.7.4.bb => 
libpcap_1.8.1.bb} (80%)

diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc 
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 7b29a52..56a2a6a 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -26,7 +26,6 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 
'bluetooth', '${BLUEZ
 PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
 # Add a dummy PACKAGECONFIG for bluez5 since it is not supported by libpcap.
 PACKAGECONFIG[bluez5] = ",,"
-PACKAGECONFIG[canusb] = "--enable-canusb,--enable-canusb=no,libusb"
 PACKAGECONFIG[dbus] = "--enable-dbus,--disable-dbus,dbus"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
 PACKAGECONFIG[libnl] = "--with-libnl,--without-libnl,libnl"
diff --git a/meta/recipes-connectivity/libpcap/libpcap/aclocal.patch 
b/meta/recipes-connectivity/libpcap/libpcap/aclocal.patch
index 2151982..a2421c4 100644
--- a/meta/recipes-connectivity/libpcap/libpcap/aclocal.patch
+++ b/meta/recipes-connectivity/libpcap/libpcap/aclocal.patch
@@ -1,9 +1,21 @@
+From 731aa41f2139d5217941685441d49a809a04de02 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Thu, 3 Nov 2016 17:41:17 -0200
+Subject: [PATCH] aclocal
+Organization: O.S. Systems Software LTDA.
+
 Upstream-Status: Inappropriate [configuration]
 
-diff -ruN libpcap-1.1.1-orig/aclocal.m4 libpcap-1.1.1/aclocal.m4
 libpcap-1.1.1-orig/aclocal.m4  2010-06-29 10:46:32.815117569 +0800
-+++ libpcap-1.1.1/aclocal.m4   2010-06-29 10:49:17.150149949 +0800
-@@ -37,7 +37,7 @@
+Signed-off-by: Fabio Berton 
+---
+ aclocal.m4 | 44 ++--
+ 1 file changed, 22 insertions(+), 22 deletions(-)
+
+diff --git a/aclocal.m4 b/aclocal.m4
+index 83f5761..3de3bf8 100644
+--- a/aclocal.m4
 b/aclocal.m4
+@@ -35,7 +35,7 @@ dnl calling AC_PROG_CC, and then doing the tests we now do in
  dnl AC_LBL_C_INIT.  Now, we run AC_LBL_C_INIT_BEFORE_CC, AC_PROG_CC,
  dnl and AC_LBL_C_INIT at the top level.
  dnl
@@ -12,16 +24,43 @@ diff -ruN libpcap-1.1.1-orig/aclocal.m4 
libpcap-1.1.1/aclocal.m4
  [
  AC_BEFORE([$0], [AC_LBL_C_INIT])
  AC_BEFORE([$0], [AC_PROG_CC])
-@@ -90,7 +90,7 @@
- dnl LDFLAGS
- dnl LBL_CFLAGS
+@@ -92,7 +92,7 @@ dnl  CC
+ dnl   LDFLAGS
+ dnl   LBL_CFLAGS
  dnl
 -AC_DEFUN(AC_LBL_C_INIT,
 +AC_DEFUN([AC_LBL_C_INIT],
  [
  AC_BEFORE([$0], [AC_LBL_FIXINCLUDES])
  AC_BEFORE([$0], [AC_LBL_DEVEL])
-@@ -217,7 +217,7 @@
+@@ -238,7 +238,7 @@ dnl Set ac_lbl_unknown_warning_option_error to the 
appropriate flag
+ dnl to force an error if it would otherwise just print a warning message
+ dnl and succeed.
+ dnl
+-AC_DEFUN(AC_LBL_CHECK_UNKNOWN_WARNING_OPTION_ERROR,
++AC_DEFUN([AC_LBL_CHECK_UNKNOWN_WARNING_OPTION_ERROR],
+ [
+   AC_MSG_CHECKING([whether the compiler fails when given an unknown 
warning option])
+   save_CFLAGS="$CFLAGS"
+@@ -266,7 +266,7 @@ dnl Check whether the compiler option specified as the 
second argument
+ dnl is supported by the compiler and, if so, add it to the macro
+ dnl specified as the first argument
+ dnl
+-AC_DEFUN(AC_LBL_CHECK_COMPILER_OPT,
++AC_DEFUN([AC_LBL_CHECK_COMPILER_OPT],
+ [
+   AC_MSG_CHECKING([whether the compiler supports the $2 option])
+   save_CFLAGS="$CFLAGS"
+@@ -315,7 +315,7 @@ dnl output by default.  IBM's XLC, however, supports -M 
but sends
+ dnl the output to {sourcefile-basename}.u, and AIX has no /dev/stdout
+ dnl to work around that, so we don't bother with XLC.
+ dnl
+-AC_DEFUN(AC_LBL_CHECK_DEPENDENCY_GENERATION_OPT,
++AC_DEFUN([AC_LBL_CHECK_DEPENDENCY_GENERATION_OPT],
+ [
+   AC_MSG_CHECKING([whether the compiler supports generating dependencies])
+   if test "$GCC" = yes ; then
+@@ -425,7 +425,7 @@ dnlV_SHLIB_OPT
  dnl   V_SONAME_OPT
  dnl   V_RPATH_OPT
  dnl
@@ -30,7 +69,7 @@ diff -ruN libpcap-1.1.1-orig/aclocal.m4 
libpcap-1.1.1/aclocal.m4
  [AC_PREREQ(2.50)
  if test "$GCC" = yes ; then
#
-@@ -361,7 +361,7 @@
+@@ -586,7 +586,7 @@ AC_DEFUN(AC_LBL_SHLIBS_INIT,
  # Make sure we use the V_CCOPT flags, because some of those might
  # disable inlining.
  #
@@ -39,7 +78,7 @@ diff -ruN libpcap-1.1.1-orig/aclocal.m4 
libpcap-1.1.1/aclocal.m4
  [AC_MSG_CHECKING(for inline)
  save_CFLAGS="$CFLAGS"
  CFLAGS="$V_CCOPT"
-@@ -407,7 +407,7 @@
+

[OE-core] [PATCH] cve-check.bbclass: CVE-2014-2524 / readline v5.2

[André Draszik]

From: André Draszik 

Contrary to the CVE report, the vulnerable trace functions
don't exist in readline v5.2 (which we keep for GPLv2+
purposes), they were added in readline v6.0 only - let's
whitelist that CVE in order to avoid false positives.

See also the discussion in
 https://patchwork.openembedded.org/patch/81765/

Signed-off-by: André Draszik 
Reviewed-by: Lukasz Nowak 
---
 meta/classes/cve-check.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 1425a40..b0febfb 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -39,7 +39,7 @@ CVE_CHECK_PN_WHITELIST = "\
 
 # Whitelist for CVE and version of package
 CVE_CHECK_CVE_WHITELIST = "{\
-'CVE-2014-2524': ('6.3',), \
+'CVE-2014-2524': ('6.3','5.2',), \
 }"
 
 python do_cve_check () {
-- 
2.10.2

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

[OE-core] [PATCH] u-boot: mkimage: fix build

[Stefan Müller-Klieser]

This fixes the mkimage build for situations where HOSTCC and friends
need to be overridden and the u-boot makefile defaults don't work.

Signed-off-by: Stefan Müller-Klieser 
---
 ...file-improve-cross_tools-target-usability.patch | 35 ++
 ...ile-add-override-statements-for-cross_too.patch | 41 ++
 meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb  |  8 -
 3 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-bsp/u-boot/u-boot-mkimage/0001-tools-Makefile-improve-cross_tools-target-usability.patch
 create mode 100644 
meta/recipes-bsp/u-boot/u-boot-mkimage/0002-tools-Makefile-add-override-statements-for-cross_too.patch

diff --git 
a/meta/recipes-bsp/u-boot/u-boot-mkimage/0001-tools-Makefile-improve-cross_tools-target-usability.patch
 
b/meta/recipes-bsp/u-boot/u-boot-mkimage/0001-tools-Makefile-improve-cross_tools-target-usability.patch
new file mode 100644
index 000..4b0d0e8
--- /dev/null
+++ 
b/meta/recipes-bsp/u-boot/u-boot-mkimage/0001-tools-Makefile-improve-cross_tools-target-usability.patch
@@ -0,0 +1,35 @@
+From ad129135402b38deeb37383c86781341cf239b6a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= 
+Date: Mon, 31 Oct 2016 10:30:18 +0100
+Subject: [PATCH 1/2] tools: Makefile: improve cross_tools target usability
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When building the cross_tools target, HOSTCFLAGS and HOSTLDFLAGS will
+propagate to the target build. This should not happen and is easy to
+prevent.
+
+Upstream-Status: Submitted
+
+Signed-off-by: Stefan Müller-Klieser 
+---
+ tools/Makefile | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/tools/Makefile b/tools/Makefile
+index 400588c..305336c 100644
+--- a/tools/Makefile
 b/tools/Makefile
+@@ -263,6 +263,8 @@ subdir- += env
+ 
+ ifneq ($(CROSS_BUILD_TOOLS),)
+ HOSTCC = $(CC)
++HOSTCFLAGS = $(CFLAGS)
++HOSTLDFLAGS = $(LDFLAGS)
+ 
+ quiet_cmd_crosstools_strip = STRIP   $^
+   cmd_crosstools_strip = $(STRIP) $^; touch $@
+-- 
+1.9.1
+
diff --git 
a/meta/recipes-bsp/u-boot/u-boot-mkimage/0002-tools-Makefile-add-override-statements-for-cross_too.patch
 
b/meta/recipes-bsp/u-boot/u-boot-mkimage/0002-tools-Makefile-add-override-statements-for-cross_too.patch
new file mode 100644
index 000..4c7b6d0
--- /dev/null
+++ 
b/meta/recipes-bsp/u-boot/u-boot-mkimage/0002-tools-Makefile-add-override-statements-for-cross_too.patch
@@ -0,0 +1,41 @@
+From 2772e2ad0e097590e77fa338295d839d6ae6037c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= 
+Date: Thu, 3 Nov 2016 08:48:02 +0100
+Subject: [PATCH 2/2] tools: Makefile: add override statements for cross_tools
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This fixes the use case where one needs to override the host compiler
+flags for building the target tools. Usually the Makefile will build the
+basic tools first using the hostcc. After that cc will be assigned to
+hostcc to build the target tools. So in this scenario overriding HOSTCC
+fails to build. Using the override statement is one possible fix.
+
+Upstream-Status: Pending
+
+Signed-off-by: Stefan Müller-Klieser 
+---
+ tools/Makefile | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/tools/Makefile b/tools/Makefile
+index 305336c..9cb1607 100644
+--- a/tools/Makefile
 b/tools/Makefile
+@@ -262,9 +262,9 @@ $(LICENSE_H): $(obj)/bin2header 
$(srctree)/Licenses/gpl-2.0.txt
+ subdir- += env
+ 
+ ifneq ($(CROSS_BUILD_TOOLS),)
+-HOSTCC = $(CC)
+-HOSTCFLAGS = $(CFLAGS)
+-HOSTLDFLAGS = $(LDFLAGS)
++override HOSTCC = $(CC)
++override HOSTCFLAGS = $(CFLAGS)
++override HOSTLDFLAGS = $(LDFLAGS)
+ 
+ quiet_cmd_crosstools_strip = STRIP   $^
+   cmd_crosstools_strip = $(STRIP) $^; touch $@
+-- 
+1.9.1
+
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb 
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
index 5025961..0749408 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
@@ -3,7 +3,13 @@ require u-boot-common_${PV}.inc
 SUMMARY = "U-Boot bootloader image creation tool"
 DEPENDS = "openssl"
 
-EXTRA_OEMAKE = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} ${CFLAGS} 
${LDFLAGS}" STRIP=true V=1'
+SRC_URI += " \
+file://0001-tools-Makefile-improve-cross_tools-target-usability.patch \
+file://0002-tools-Makefile-add-override-statements-for-cross_too.patch \
+"
+
+EXTRA_OEMAKE = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC}" CFLAGS="${CFLAGS}" 
LDFLAGS="${LDFLAGS}" STRIP=true V=1'
+EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC}" HOSTCFLAGS="${BUILD_CFLAGS}" 
HOSTLDFLAGS="${BUILD_LDFLAGS}"'
 
 do_compile () {
oe_runmake sandbox_defconfig
-- 
1.9.1

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

[OE-core] [PATCH v2]] gawk: Update to version 4.1.4

[Fabio Berton]

Add patch to remove hashbang line in file test/arrayind1.awk. This
patch fixes:
/
|WARNING: gawk-4.1.4-r0 do_package_qa: QA Issue:
|/usr/lib/gawk/ptest/test/arrayind1.awk contained in package gawk-ptest
|requires /usr/local/bin/awk, but no providers found in RDEPENDS_gawk-ptest?
|[file-rdeps]
\

Patch was submitted to upstream [1]

[1] https://lists.gnu.org/archive/html/bug-gawk/2016-11/msg3.html

Signed-off-by: Fabio Berton 
---
 .../gawk/{gawk-4.1.3 => gawk-4.1.4}/run-ptest  |  0
 .../test-arrayind1-Remove-hashbang-line.patch  | 30 ++
 .../gawk/{gawk_4.1.3.bb => gawk_4.1.4.bb}  |  5 ++--
 3 files changed, 33 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/gawk/{gawk-4.1.3 => gawk-4.1.4}/run-ptest (100%)
 create mode 100644 
meta/recipes-extended/gawk/gawk-4.1.4/test-arrayind1-Remove-hashbang-line.patch
 rename meta/recipes-extended/gawk/{gawk_4.1.3.bb => gawk_4.1.4.bb} (85%)

diff --git a/meta/recipes-extended/gawk/gawk-4.1.3/run-ptest 
b/meta/recipes-extended/gawk/gawk-4.1.4/run-ptest
similarity index 100%
rename from meta/recipes-extended/gawk/gawk-4.1.3/run-ptest
rename to meta/recipes-extended/gawk/gawk-4.1.4/run-ptest
diff --git 
a/meta/recipes-extended/gawk/gawk-4.1.4/test-arrayind1-Remove-hashbang-line.patch
 
b/meta/recipes-extended/gawk/gawk-4.1.4/test-arrayind1-Remove-hashbang-line.patch
new file mode 100644
index 000..d4262ed
--- /dev/null
+++ 
b/meta/recipes-extended/gawk/gawk-4.1.4/test-arrayind1-Remove-hashbang-line.patch
@@ -0,0 +1,30 @@
+From a3a3f26078223c47871c7b53e5c015ad163ae045 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Thu, 3 Nov 2016 14:50:52 -0200
+Subject: [PATCH] test/arrayind1: Remove hashbang line
+Organization: O.S. Systems Software LTDA.
+
+Remove "#!/usr/local/bin/awk -f" as none of the other awk scripts in the
+test suite have a hashbang.
+
+Upstream-Status: Submitted [1]
+
+[1] https://lists.gnu.org/archive/html/bug-gawk/2016-11/msg3.html
+
+Signed-off-by: Fabio Berton 
+---
+ test/arrayind1.awk | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/test/arrayind1.awk b/test/arrayind1.awk
+index 5d4a6f3..59e8b4e 100755
+--- a/test/arrayind1.awk
 b/test/arrayind1.awk
+@@ -1,4 +1,3 @@
+-#!/usr/local/bin/awk -f
+ # this script renums pedigrees with metafounders
+ # so that they are added *before*regular animals
+ # mf are ascertained because they are not in the 1st column
+-- 
+2.1.4
+
diff --git a/meta/recipes-extended/gawk/gawk_4.1.3.bb 
b/meta/recipes-extended/gawk/gawk_4.1.4.bb
similarity index 85%
rename from meta/recipes-extended/gawk/gawk_4.1.3.bb
rename to meta/recipes-extended/gawk/gawk_4.1.4.bb
index 6ca7f3e..b888df1 100644
--- a/meta/recipes-extended/gawk/gawk_4.1.3.bb
+++ b/meta/recipes-extended/gawk/gawk_4.1.4.bb
@@ -17,10 +17,11 @@ PACKAGECONFIG[mpfr] = "--with-mpfr,--without-mpfr, mpfr"
 
 SRC_URI = "${GNU_MIRROR}/gawk/gawk-${PV}.tar.gz \
file://run-ptest \
+   file://test-arrayind1-Remove-hashbang-line.patch \
 "
 
-SRC_URI[md5sum] = "55d37f4069502677f25d1340df8eec97"
-SRC_URI[sha256sum] = 
"524effa5b9ecd4ed940f2581c5d3c1df4e4bd7e6f768aa033c1916f47dfc6e29"
+SRC_URI[md5sum] = "f20c94ca51b6ebfc9bffb90f95c8ffbb"
+SRC_URI[sha256sum] = 
"8c03080e2b5a56263e8783f6f1f306398d4591be18254041f3f547efef944d35"
 
 inherit autotools gettext texinfo update-alternatives
 
-- 
2.1.4

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

Re: [OE-core] [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage

[Stefan Müller-Klieser]

On 03.11.2016 00:06, Burton, Ross wrote:
> On 2 November 2016 at 19:40, Marek Vasut  wrote:
> 
>>> But u-boot-common doesn't set EXTRA_OEMAKE...
>>
>> Should be u-boot.inc , sorry.
>>
> 
> Yes, but u-book-mkimage doesn't include that file. :)
> 
> Ross

I am seeing a different problem, but I guess my solution would fix this case
here, too. So I am sending it as a new thread. I hope it helps the case and
I get some discussion about the solution.

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

[OE-core] [PATCH] image-buildinfo: treat staged changes as modified branch, too

[André Draszik]

From: André Draszik 

When staging changes in a layer using git add, image-buildinfo
doesn't detect this as a modification, because of the way it
uses git diff.

Surely, merely staging, but not committing changes to git
should not result in image-buildhistory assuming that the
git repository hasn't been modified compared to the branch
HEAD, this state should be treated similarly to modifications
being unstaged.

We have to use both, git diff and git diff --cached to get the
desired result.

Signed-off-by: André Draszik 
Reported-by: Lukasz Nowak 
Reviewed-by: Lukasz Nowak 
---
 meta/classes/image-buildinfo.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image-buildinfo.bbclass 
b/meta/classes/image-buildinfo.bbclass
index 3003f5d..da1edf7 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -28,7 +28,9 @@ def image_buildinfo_outputvars(vars, listvars, d):
 def get_layer_git_status(path):
 import subprocess
 try:
-subprocess.check_output("cd %s; PSEUDO_UNLOAD=1 git diff --quiet 
--no-ext-diff" % path,
+subprocess.check_output("""cd %s; export PSEUDO_UNLOAD=1; set -e;
+git diff --quiet --no-ext-diff
+git diff --quiet --no-ext-diff --cached""" % 
path,
 shell=True,
 stderr=subprocess.STDOUT)
 return ""
-- 
2.10.2

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

[OE-core] [PATCH] distro_check: partial rewrite to make it work again

[Ross Burton]

This library suffered as part of the Python 2 to Python 3 migration and stopped
working entirely.

Fix all the migration problems such as files being treated as strings but opened
in binary mode, insufficient use of with on files, and so on.

Rewrite large amounts to be Pythonic instead of C-in-Python.

Update OpenSuse and Fedora URLs.

Fedora now splits the archive alphabetically so handle that.

[ YOCTO #10562 ]

Signed-off-by: Ross Burton 
---
 meta/lib/oe/distro_check.py | 281 +---
 1 file changed, 110 insertions(+), 171 deletions(-)

diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index 87c52fa..00c827e 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -1,32 +1,17 @@
-from contextlib import contextmanager
-
-from bb.utils import export_proxies
-
 def create_socket(url, d):
 import urllib
+from bb.utils import export_proxies
 
-socket = None
-try:
-export_proxies(d)
-socket = urllib.request.urlopen(url)
-except:
-bb.warn("distro_check: create_socket url %s can't access" % url)
-
-return socket
+export_proxies(d)
+return urllib.request.urlopen(url)
 
 def get_links_from_url(url, d):
 "Return all the href links found on the web location"
 
 from bs4 import BeautifulSoup, SoupStrainer
 
+soup = BeautifulSoup(create_socket(url,d), "html.parser", 
parse_only=SoupStrainer("a"))
 hyperlinks = []
-
-webpage = ''
-sock = create_socket(url,d)
-if sock:
-webpage = sock.read()
-
-soup = BeautifulSoup(webpage, "html.parser", parse_only=SoupStrainer("a"))
 for line in soup.find_all('a', href=True):
 hyperlinks.append(line['href'].strip('/'))
 return hyperlinks
@@ -37,6 +22,7 @@ def find_latest_numeric_release(url, d):
 maxstr=""
 for link in get_links_from_url(url, d):
 try:
+# TODO use LooseVersion
 release = float(link)
 except:
 release = 0
@@ -47,144 +33,116 @@ def find_latest_numeric_release(url, d):
 
 def is_src_rpm(name):
 "Check if the link is pointing to a src.rpm file"
-if name[-8:] == ".src.rpm":
-return True
-else:
-return False
+return name.endswith(".src.rpm")
 
 def package_name_from_srpm(srpm):
 "Strip out the package name from the src.rpm filename"
-strings = srpm.split('-')
-package_name = strings[0]
-for i in range(1, len (strings) - 1):
-str = strings[i]
-if not str[0].isdigit():
-package_name += '-' + str
-return package_name
-
-def clean_package_list(package_list):
-"Removes multiple entries of packages and sorts the list"
-set = {}
-map(set.__setitem__, package_list, [])
-return set.keys()
 
+# ca-certificates-2016.2.7-1.0.fc24.src.rpm
+# ^name   ^ver ^release^removed
+(name, version, release) = srpm.replace(".src.rpm", "").rsplit("-", 2)
+return name
 
 def get_latest_released_meego_source_package_list(d):
 "Returns list of all the name os packages in the latest meego distro"
 
-package_names = []
-try:
-f = open("/tmp/Meego-1.1", "r")
+package_names = set()
+with open("/tmp/Meego-1.1", "r") as f:
 for line in f:
-package_names.append(line[:-1] + ":" + "main") # Also strip the 
'\n' at the end
-except IOError: pass
-package_list=clean_package_list(package_names)
-return "1.0", package_list
+package_names.add(line.strip() + ":" + "main")
+return "1.1", package_names
 
 def get_source_package_list_from_url(url, section, d):
 "Return a sectioned list of package names from a URL list"
 
 bb.note("Reading %s: %s" % (url, section))
 links = get_links_from_url(url, d)
-srpms = list(filter(is_src_rpm, links))
-names_list = list(map(package_name_from_srpm, srpms))
+srpms = filter(is_src_rpm, links)
+names_list = map(package_name_from_srpm, srpms)
 
-new_pkgs = []
+new_pkgs = set()
 for pkgs in names_list:
-   new_pkgs.append(pkgs + ":" + section)
-
+   new_pkgs.add(pkgs + ":" + section)
 return new_pkgs
 
+def get_source_package_list_from_url_by_letter(url, section, d):
+import string
+from urllib.error import HTTPError
+packages = set()
+for letter in (string.ascii_lowercase + string.digits):
+# Not all subfolders may exist, so silently handle 404
+try:
+packages |= get_source_package_list_from_url(url + "/" + letter, 
section, d)
+except HTTPError as e:
+if e.code != 404: raise
+return packages
+
 def get_latest_released_fedora_source_package_list(d):
 "Returns list of all the name os packages in the latest fedora distro"
 latest = 
find_latest_numeric_release("http://archive.fedoraproject.org/pub/fedora/linux/releases/";,
 d)
-
-package_names = 
get_source_package_list_from_url("http://archive.fedoraproject.org/pu

Re: [OE-core] uninative binary?

[Richard Purdie]

On Fri, 2016-11-04 at 08:16 +0100, Gary Thomas wrote:
> Some of my customers need to be able to build without any
> network connectivity, so I normally use BB_NO_NETWORK="1"
> 
> Is there a way to add the uninative "binary shim" to my
> download mirror?  Given that the path includes a hash as
> a directory, it's not clear to me how to put it into my
> mirror.
> 
> Thanks for any ideas

Set UNINATIVE_URL to point at your mirror?

If the file already exists in DL_DIR, it will be used without touching
the network.

Cheers,

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

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

[Zhou, Li]

Some more explanations:

Berkeley DB's assembly mutex code for arm is related with arm arch version.

The old version DB code uses old arm instruction (such as swpb), which 
isn't supported by new arm arch (such as armv7).


The new version DB (maybe from 6.1.29 or 6.1.26) uses new arm 
instruction (such as ldrex/strex), which isn't supported by old arm arch 
(such as armv5).


To support all the arm arches, and consider that the Berkeley DB code 
will upgrade in the future, I suggest disable the ARM assembler mutex 
code, and use the default pthreads mutex.


Thanks.
Zhou Li

On 11/04/2016 05:07 PM, Li Zhou wrote:

The swpb in macro MUTEX_SET will cause "undefined instruction" error
on the new arm arches which don't support this assembly instruction
any more. If use ldrex/strex to replace swpb, the old arm arches don't
support them. So to avoid this issue, just disable the ARM assembler
mutex code, and use the default pthreads mutex.

Signed-off-by: Li Zhou 
---
  meta/recipes-support/db/db_6.0.30.bb | 9 -
  1 file changed, 9 deletions(-)

diff --git a/meta/recipes-support/db/db_6.0.30.bb 
b/meta/recipes-support/db/db_6.0.30.bb
index 50a469b..2d08b5e 100644
--- a/meta/recipes-support/db/db_6.0.30.bb
+++ b/meta/recipes-support/db/db_6.0.30.bb
@@ -74,15 +74,6 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
--disable-queue --disabl
  
  EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
  
-# Override the MUTEX setting here, the POSIX library is

-# the default - "POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX}"
  EXTRA_OEMAKE_class-target = 
"LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
  
  # Cancel the site stuff - it's set for db3 and destroys the


--
Best Regards!
Zhou Li
Phone number: 86-10-84778511

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

[OE-core] [PATCH] db: disable the ARM assembler mutex code

[Li Zhou]

The swpb in macro MUTEX_SET will cause "undefined instruction" error
on the new arm arches which don't support this assembly instruction
any more. If use ldrex/strex to replace swpb, the old arm arches don't
support them. So to avoid this issue, just disable the ARM assembler
mutex code, and use the default pthreads mutex.

Signed-off-by: Li Zhou 
---
 meta/recipes-support/db/db_6.0.30.bb | 9 -
 1 file changed, 9 deletions(-)

diff --git a/meta/recipes-support/db/db_6.0.30.bb 
b/meta/recipes-support/db/db_6.0.30.bb
index 50a469b..2d08b5e 100644
--- a/meta/recipes-support/db/db_6.0.30.bb
+++ b/meta/recipes-support/db/db_6.0.30.bb
@@ -74,15 +74,6 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
--disable-queue --disabl
 
 EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
 
-# Override the MUTEX setting here, the POSIX library is
-# the default - "POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX}"
 EXTRA_OEMAKE_class-target = 
"LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
 
 # Cancel the site stuff - it's set for db3 and destroys the
-- 
2.9.3

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

[OE-core] [PATCH] db: disable the ARM assembler mutex code

[Li Zhou]

The swpb in macro MUTEX_SET will cause "undefined instruction" error
on the new arm arches which don't support this assembly instruction
any more. If use ldrex/strex to replace swpb, the old arm arches don't
support them. So to avoid this issue, just disable the ARM assembler
mutex code, and use the default pthreads mutex.

Signed-off-by: Li Zhou 
---
 meta/recipes-support/db/db_6.0.30.bb | 9 -
 1 file changed, 9 deletions(-)

diff --git a/meta/recipes-support/db/db_6.0.30.bb 
b/meta/recipes-support/db/db_6.0.30.bb
index 50a469b..2d08b5e 100644
--- a/meta/recipes-support/db/db_6.0.30.bb
+++ b/meta/recipes-support/db/db_6.0.30.bb
@@ -74,15 +74,6 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
--disable-queue --disabl
 
 EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
 
-# Override the MUTEX setting here, the POSIX library is
-# the default - "POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX}"
 EXTRA_OEMAKE_class-target = 
"LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
 
 # Cancel the site stuff - it's set for db3 and destroys the
-- 
2.9.3

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

Re: [OE-core] uninative binary?

[Robert P. J. Day]

On Fri, 4 Nov 2016, Gary Thomas wrote:

> Some of my customers need to be able to build without any
> network connectivity, so I normally use BB_NO_NETWORK="1"
>
> Is there a way to add the uninative "binary shim" to my
> download mirror?  Given that the path includes a hash as
> a directory, it's not clear to me how to put it into my
> mirror.

  weirdly, i was about to ask the very same question ... you should
have waited. :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support spdx2.0 SPEC

[Lei, Maohui]

Hi Simon

> Where do we stand:
> - v1 of patch submitted
> - comment to create/use dosocs-native tp avoid the separate install (well, +1)
> - comment that "the following direct dependencies that not belong to oe-core"


Sorry, I mean it's difficult to add them all into oe-core, because as you know, 
oe-core only contains base layer of recipes. But I don't think these recipes 
are base enough.
So, I think it's easier to let user install dosocs themselves.


> @Lei: can you find where those dependencies are ?
>   (https://layers.openembedded.org/layerindex/branch/morty/recipes/)

The situation of these dependences is the following:

PostgreSQL - meta-oe
python-psycopg2 - meta-openstack
jinja2  - meta-python/meta-openstack 
docopt  - not found
SQLAlchemy - meta-python


Best regards
Lei



> -Original Message-
> From: Jan-Simon Möller [mailto:dl...@gmx.de]
> Sent: Thursday, November 03, 2016 5:06 PM
> To: Lei, Maohui
> Cc: Maxin B. John; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support spdx2.0 SPEC
> 
> Hi Lei, Maxin!
> 
> Where do we stand:
> - v1 of patch submitted
> - comment to create/use dosocs-native tp avoid the separate install (well, +1)
> - comment that "the following direct dependencies that not belong to oe-core"
> 
> Did I summarize that correctly ?
> 
> @Maxin: what would you propose, work on the dependencies or let the user
> install ?
> @Lei: can you find where those dependencies are ?
>   (https://layers.openembedded.org/layerindex/branch/morty/recipes/)
> 
> Best,
> Jan-Simon
> 
> Am Donnerstag, 3. November 2016, 04:02:42 schrieb Lei, Maohui:
> > Ping.
> >
> >
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-
>  core-boun...@lists.openembedded.org] On Behalf Of
> > > Lei, Maohui
> > > Sent: Monday, October 17, 2016 9:04 AM
> > > To: Maxin B. John; Jan-Simon Möller
> > > Cc: jsmoel...@linuxfoundation.org;
> > > openembedded-core@lists.openembedded.org
>  Subject: Re: [OE-core] [PATCH
> > > v2 1/1] Make yocto-spdx support spdx2.0 SPEC Hi Maxin, Simon
> > >
> > >
> > > > > Instead of requesting the user to install the DoSOCSv2 from github
> > > > > or other repos, can we make the spdx.bbclass depend on
> > > > > "dosocs-native"
> > > >
> > > > or
> > > >
> > > > > similar and make that "DoSOCSv2" recipe available in oe-core ?
> > > >
> > > >
> > > >
> > > > That's a good idea. I will try.
> > >
> > >
> > > I tried to make DoSOCSv2 recipe to oe-core, and find that there are at
> > > least
>  the following direct dependencies that not belong to oe-core.
> > >
> > > PostgreSQL
> > > python-psycopg2
> > > jinja2
> > > python-magic
> > > docopt
> > > SQLAlchemy
> > > psycopg2
> > >
> > > I think it difficult to add them all into oe-core and it's the reason that
> > > why
>  the original spdx module didn't add fossology into oe-core.
> > >
> > >
> > >
> > > Best regards
> > > Lei
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: openembedded-core-boun...@lists.openembedded.org
> > > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > > > Lei, Maohui
> > > > Sent: Thursday, September 22, 2016 10:19 AM
> > > > To: Maxin B. John; Jan-Simon Möller
> > > > Cc: jsmoel...@linuxfoundation.org; openembedded-
> > > > c...@lists.openembedded.org
> > > > Subject: Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support spdx2.0
> > > > SPEC
> > > >
> > > >
> > > >
> > > > Hi Maxin, Simon
> > > >
> > > >
> > > >
> > > > > It would be nice to include the reason for change from fossology to
> > > > > dosocs2 in the commit message too (from cover letter)
> > > >
> > > >
> > > >
> > > > OK, I will add the reasons into the commit message in v3.
> > > >
> > > >
> > > >
> > > > > Instead of requesting the user to install the DoSOCSv2 from github
> > > > > or other repos, can we make the spdx.bbclass depend on
> > > > > "dosocs-native"
> > > >
> > > > or
> > > >
> > > > > similar and make that "DoSOCSv2" recipe available in oe-core ?
> > > >
> > > >
> > > >
> > > > That's a good idea. I will try.
> > > >
> > > >
> > > >
> > > >
> > > > Best Regards
> > > > Lei
> > > >
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Maxin B. John [mailto:maxin.j...@intel.com]
> > > > > Sent: Monday, September 19, 2016 6:58 PM
> > > > > To: Lei, Maohui
> > > > > Cc: openembedded-core@lists.openembedded.org;
> > > > > jsmoel...@linuxfoundation.org
> > > > > Subject: Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support
> > > > > spdx2.0 SPEC
> > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > >
> > > > > Please find my comments below:
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Sep 19, 2016 at 04:39:50PM +0800, Lei Maohui wrote:
> > > > >
> > > > > > More:
> > > > > > - change spdx tool from fossology to dosocs2
> > > > >
> > > > >
> > > > >
> > > > > It would be nice to include t

[OE-core] uninative binary?

[Gary Thomas]

Some of my customers need to be able to build without any
network connectivity, so I normally use BB_NO_NETWORK="1"

Is there a way to add the uninative "binary shim" to my
download mirror?  Given that the path includes a hash as
a directory, it's not clear to me how to put it into my
mirror.

Thanks for any ideas

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] [PATCH 0/1] tcf-agent: fix systemd service file

[Chen Qi]

The following changes since commit 98c6ebf1e05158c689e01b785d32757847cdb10c:

  oeqa/selftest/kernel.py: Add new file destined for kernel related tests 
(2016-11-01 10:05:40 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/tcf-agent
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/tcf-agent

Chen Qi (1):
  tcf-agent: fix systemd service file

 meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
1.9.1

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

[OE-core] [PATCH 1/1] tcf-agent: fix systemd service file

[Chen Qi]

Fix tcf-agent service file so that `systemctl stop tcf-agent' doesn't
fail.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service 
b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service
index fd9a6c4..dd3a79b 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service
@@ -3,8 +3,7 @@ Description=Target Communication Framework agent
 After=network.target
 
 [Service]
-Type=forking
-ExecStart=@SBINDIR@/tcf-agent -d -L- -l0
+ExecStart=@SBINDIR@/tcf-agent -L- -l0
 
 [Install]
 WantedBy=multi-user.target
-- 
1.9.1

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