Re: [OE-core] Loss of a wayland socket by a systemd user session

2016-11-18 Thread Daniel Díaz 
Hello!


On 11/18/2016 12:12 PM, Tomas Novotny wrote:
> I'm using weston and its 'weston-start' script shipped with oe-core (morty).
> It works perfectly until root is logged in. The problematic path is:
[...]

We've seen that [1]. If you have PAM, you can modify weston-start to
pass `-u root' to weston-launch [2].

You can also try this systemd service unit and launch Weston directly:
  https://github.com/mrchapp/meta-96boards/commit/ac3e11e

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[1] https://bugs.linaro.org/show_bug.cgi?id=2576
[2] https://github.com/mrchapp/meta-96boards/commit/ee71b7e

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

[OE-core] [PATCH] ltp: fix an incorrect macro checking

2016-11-18 Thread jackie.huang 
From: Jackie Huang 

The previous patch added a check but incorrectly
change the elif to if, then it always return 0
for cpuid if the machine is not __i386__

getcpu011  TFAIL  :  getcpu01.c:140: getcpu() returned wrong value expected 
cpuid:7, returned value cpuid: 0

After this fix:
getcpu011  TPASS  :  getcpu() returned proper cpuid:7, node id:0

Signed-off-by: Jackie Huang 
---
 .../0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch  | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git 
a/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
 
b/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
index d123074..41f2623 100644
--- 
a/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
+++ 
b/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
@@ -88,22 +88,19 @@ index c927512..921b107 100644
  
  void cleanup(void);
  void setup(void);
-@@ -164,9 +172,14 @@ static inline int getcpu(unsigned *cpu_id, unsigned 
*node_id,
+@@ -164,7 +172,11 @@ static inline int getcpu(unsigned *cpu_id, unsigned 
*node_id,
  {
  #if defined(__i386__)
return syscall(318, cpu_id, node_id, cache_struct);
 -#elif __GLIBC_PREREQ(2,6)
-+#if defined(__GLIBC__)
++#elif defined(__GLIBC__)
 +#if __GLIBC_PREREQ(2,6)
 +  *cpu_id = sched_getcpu();
 +#endif
 +#else
*cpu_id = sched_getcpu();
  #endif
-+#endif
return 0;
- }
- 
 @@ -191,15 +204,20 @@ unsigned int set_cpu_affinity(void)
cpu_set_t *set;
size_t size;
-- 
2.8.3

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

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

2016-11-18 Thread Denys Dmytriyenko 
On Fri, Nov 18, 2016 at 09:50:08PM +0100, Koen Kooi wrote:
> 
> > Op 18 nov. 2016, om 19:06 heeft Richard Purdie 
> >  het volgende geschreven:
> > 
> > On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
> >> On 11/17/2016 09:31 AM, Burton, Ross wrote:
> >>> Background: uninative is a class that downloads a precompiled host
> >>> glibc for use in the sysroot, thus isolating the native sysroot
> >>> from the host environment.  This means greater sstate reuse, as
> >>> instead of native builds being dependent on the host system they're
> >>> able to be shared between all hosts.  There is a reference tarball
> >>> hosted on www.yoctoproject.org, and the URL can be overridden by
> >>> distros if you would prefer to build your own.
> >>> 
> >>> We enable this in Poky so that we get greater reuse on the
> >>> autobuilders, and due to some issues with the C++ ABI the eSDK
> >>> generation in master now requires uninative to be enabled.  The
> >>> question is: do we now enable uninative by default in oe-core's
> >>> nodistro (pointing at the yoctoproject tarball), or do we keep it
> >>> disabled by default and require the user to enable uninative if
> >>> they wish to build an eSDK?
> >>  
> >> If Poky wants the default to use a prebuilt uninative that is fine,
> >> but it should be not be the default in OE.  In the spirit of Bitbake,
> >> uninative should be a build dependency for eSDK with the option of
> >> using a prebuilt one.
> > 
> > Its not that simple. Using uninative requires certain options passed in
> > when compiling native recipes for example, e.g. to pick particular C++
> > abis. If you start the build without those set (since uninative is
> > disabled), you can't get native sstate built in the right way for it to
> > work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
> > which is native specially for use in the eSDK but that seems silly.
> > 
> > I guess we could move the configuration uninative requires into global
> > bitbake.conf but not require the actual binary shim to be enabled. That
> > would let eSDK work in OE-Core just not make OE-Core require uninative.
> > It would mean the compiler options for native would be a little
> > different. That might be an acceptable compromise?
> 
> It would be for me.

Agree, sounds like a good compromise.

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

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

2016-11-18 Thread Koen Kooi 

> Op 18 nov. 2016, om 19:06 heeft Richard Purdie 
>  het volgende geschreven:
> 
> On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
>> On 11/17/2016 09:31 AM, Burton, Ross wrote:
>>> Background: uninative is a class that downloads a precompiled host
>>> glibc for use in the sysroot, thus isolating the native sysroot
>>> from the host environment.  This means greater sstate reuse, as
>>> instead of native builds being dependent on the host system they're
>>> able to be shared between all hosts.  There is a reference tarball
>>> hosted on www.yoctoproject.org, and the URL can be overridden by
>>> distros if you would prefer to build your own.
>>> 
>>> We enable this in Poky so that we get greater reuse on the
>>> autobuilders, and due to some issues with the C++ ABI the eSDK
>>> generation in master now requires uninative to be enabled.  The
>>> question is: do we now enable uninative by default in oe-core's
>>> nodistro (pointing at the yoctoproject tarball), or do we keep it
>>> disabled by default and require the user to enable uninative if
>>> they wish to build an eSDK?
>>  
>> If Poky wants the default to use a prebuilt uninative that is fine,
>> but it should be not be the default in OE.  In the spirit of Bitbake,
>> uninative should be a build dependency for eSDK with the option of
>> using a prebuilt one.
> 
> Its not that simple. Using uninative requires certain options passed in
> when compiling native recipes for example, e.g. to pick particular C++
> abis. If you start the build without those set (since uninative is
> disabled), you can't get native sstate built in the right way for it to
> work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
> which is native specially for use in the eSDK but that seems silly.
> 
> I guess we could move the configuration uninative requires into global
> bitbake.conf but not require the actual binary shim to be enabled. That
> would let eSDK work in OE-Core just not make OE-Core require uninative.
> It would mean the compiler options for native would be a little
> different. That might be an acceptable compromise?

It would be for me.

regards,

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

Re: [OE-core] [PATCH] u-boot: Update to v2016.11 release

2016-11-18 Thread Marek Vasut 
On 11/18/2016 08:44 PM, Denys Dmytriyenko wrote:
> On Fri, Nov 18, 2016 at 08:29:55PM +0100, Marek Vasut wrote:
>> Upgrade U-Boot to the latest version.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Richard Purdie 
>> Cc: Denys Dmytriyenko 
> 
> Acked-by: Denys Dmytriyenko 
> 
> 
>> Cc: Ross Burton 
>> ---
>>
>> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc 
>> b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
>> similarity index 71%
>> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
>> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
>> index f706a6b..84adc1c 100644
>> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
>> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
>> @@ -7,8 +7,8 @@ PE = "1"
>>  
>>  # We use the revision in order to avoid having to fetch it from the
>>  # repo during parse
>> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
>> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
>>  
>> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
>> +SRC_URI = "git://git.denx.de/u-boot.git"
> 
> Will it branch off into own branch eventually?Does master ever get 
> re-written? I guess as long as this commit always stays in master, it should 
> be fine.

Master never gets rewritten and the commit is always in master, unless
we screw something up bad and need to make a fixup release (which
happens almost never :-)), in which case that goes into separate branch.

-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Update to v2016.11 release

2016-11-18 Thread Tom Rini 
On Fri, Nov 18, 2016 at 08:29:55PM +0100, Marek Vasut wrote:

> Upgrade U-Boot to the latest version.
> 
> Signed-off-by: Marek Vasut 
> Cc: Richard Purdie 
> Cc: Denys Dmytriyenko 
> Cc: Ross Burton 

Reviewed-by: Tom Rini 

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

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

2016-11-18 Thread Tom Rini 
On Thu, Nov 17, 2016 at 02:49:51PM -0600, Nathan Lynch wrote:
> 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 

It's also something I've seen customer use as well in their scripts so
this would remove the need to add it to the local layer.

Reviewed-by: Tom Rini 

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

Re: [OE-core] [PATCH] cantarell-fonts: add inherit pkgconfig to get pkgconfig dependency

2016-11-18 Thread Burton, Ross 
On 18 November 2016 at 19:37, Cody P Schafer  wrote:

> Without this, do_configure can fail with:
>
> | ../git/configure: line 2381: syntax error near unexpected token
> `0.19'
> | ../git/configure: line 2381: `PKG_PROG_PKG_CONFIG(0.19)'
>
> If pkgconfig-native happens to be added to the sysroot too late.
>

Looking at upstream's configure there's no reason why it calls that macro,
so you could submit a patch to remove that line upstream and then just bump
the SRCREV.

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

Re: [OE-core] [PATCH] u-boot: Update to v2016.11 release

2016-11-18 Thread Denys Dmytriyenko 
On Fri, Nov 18, 2016 at 08:29:55PM +0100, Marek Vasut wrote:
> Upgrade U-Boot to the latest version.
> 
> Signed-off-by: Marek Vasut 
> Cc: Richard Purdie 
> Cc: Denys Dmytriyenko 

Acked-by: Denys Dmytriyenko 


> Cc: Ross Burton 
> ---
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc 
> b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> similarity index 71%
> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> index f706a6b..84adc1c 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> @@ -7,8 +7,8 @@ PE = "1"
>  
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
>  
> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
> +SRC_URI = "git://git.denx.de/u-boot.git"

Will it branch off into own branch eventually? Does master ever get 
re-written? I guess as long as this commit always stays in master, it should 
be fine.


>  S = "${WORKDIR}/git"
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> -- 
> 2.10.2
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cantarell-fonts: add inherit pkgconfig to get pkgconfig dependency

2016-11-18 Thread Cody P Schafer 
Without this, do_configure can fail with:

| ../git/configure: line 2381: syntax error near unexpected token `0.19'
| ../git/configure: line 2381: `PKG_PROG_PKG_CONFIG(0.19)'

If pkgconfig-native happens to be added to the sysroot too late.

Signed-off-by: Cody P Schafer 
---
 meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb 
b/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
index e3e4cde..c71ab11 100644
--- a/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
+++ b/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
@@ -18,7 +18,7 @@ UPSTREAM_CHECK_GITTAGREGEX = 
"(?P(?!0\.13)(?!0\.10\.1)\d+\.\d+(\.\d+)+)"
 
 S = "${WORKDIR}/git"
 
-inherit autotools allarch fontcache
+inherit autotools allarch fontcache pkgconfig
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[fontforge] = 
"--enable-source-rebuild=yes,--enable-source-rebuild=no,fontforge-native"
-- 
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: Update to v2016.11 release

2016-11-18 Thread Marek Vasut 
Upgrade U-Boot to the latest version.

Signed-off-by: Marek Vasut 
Cc: Richard Purdie 
Cc: Denys Dmytriyenko 
Cc: Ross Burton 
---
 .../{u-boot-common_2016.09.01.inc => u-boot-common_2016.11.inc}   | 4 ++--
 .../{u-boot-fw-utils_2016.09.01.bb => u-boot-fw-utils_2016.11.bb} | 0
 .../{u-boot-mkimage_2016.09.01.bb => u-boot-mkimage_2016.11.bb}   | 0
 meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb}   | 0
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-bsp/u-boot/{u-boot-common_2016.09.01.inc => 
u-boot-common_2016.11.inc} (71%)
 rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2016.09.01.bb => 
u-boot-fw-utils_2016.11.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2016.09.01.bb => 
u-boot-mkimage_2016.11.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb} 
(100%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc 
b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
similarity index 71%
rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
index f706a6b..84adc1c 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
@@ -7,8 +7,8 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
+SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
 
-SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
+SRC_URI = "git://git.denx.de/u-boot.git"
 
 S = "${WORKDIR}/git"
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
-- 
2.10.2

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

[OE-core] Loss of a wayland socket by a systemd user session

2016-11-18 Thread Tomas Novotny 
Hi all,

I'm using weston and its 'weston-start' script shipped with oe-core (morty).
It works perfectly until root is logged in. The problematic path is:

1) 'weston-start' is started during boot. XDG_RUNTIME_DIR for root doesn't
exist so it is created and 'wayland-0' socket is created in that directory.
So far so good.

2) When root is logged in, systemd user session is started via 'systemd
--user'. This replaces original XDG_RUNTIME_DIR (new tmpfs is mounted over
it) and the 'wayland-0' socket is lost. Logout doesn't help, the original
XDG_RUNTIME_DIR is deleted. You can imagine that weston doesn't work properly
without that socket.

Is there any proper way to fix it?

Thanks,

Tomas

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

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

2016-11-18 Thread Richard Purdie 
On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
> On 11/17/2016 09:31 AM, Burton, Ross wrote:
> > Background: uninative is a class that downloads a precompiled host
> > glibc for use in the sysroot, thus isolating the native sysroot
> > from the host environment.  This means greater sstate reuse, as
> > instead of native builds being dependent on the host system they're
> > able to be shared between all hosts.  There is a reference tarball
> > hosted on www.yoctoproject.org, and the URL can be overridden by
> > distros if you would prefer to build your own.
> > 
> > We enable this in Poky so that we get greater reuse on the
> > autobuilders, and due to some issues with the C++ ABI the eSDK
> > generation in master now requires uninative to be enabled.  The
> > question is: do we now enable uninative by default in oe-core's
> > nodistro (pointing at the yoctoproject tarball), or do we keep it
> > disabled by default and require the user to enable uninative if
> > they wish to build an eSDK?
>  
> If Poky wants the default to use a prebuilt uninative that is fine,
> but it should be not be the default in OE.  In the spirit of Bitbake,
> uninative should be a build dependency for eSDK with the option of
> using a prebuilt one.

Its not that simple. Using uninative requires certain options passed in
when compiling native recipes for example, e.g. to pick particular C++
abis. If you start the build without those set (since uninative is
disabled), you can't get native sstate built in the right way for it to
work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
which is native specially for use in the eSDK but that seems silly.

I guess we could move the configuration uninative requires into global
bitbake.conf but not require the actual binary shim to be enabled. That
would let eSDK work in OE-Core just not make OE-Core require uninative.
It would mean the compiler options for native would be a little
different. That might be an acceptable compromise?

> > 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 see there are multiple versions, which one works with which
> release?

The one configured in meta/conf/distro/include/yocto-uninative.inc.
By putting a standard include there its easy for anyone to opt into
this should they wish to.

Cheers,

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

Re: [OE-core] [PATCH 1/5] systemd: Upgrade to 232

2016-11-18 Thread Khem Raj 


On 11/18/16 4:38 AM, Burton, Ross wrote:
> 
> On 16 November 2016 at 17:47, Khem Raj  > wrote:
> 
> * Drop support for rcS.d SysV init scripts.
>   These are prone to cause dependency loops, and almost all packages with
>   rcS scripts now ship a native systemd service.
> 
> * Drop mount propagation patch, it only happens with libseccomp, OE doesnt
>   enable it
> 
> * kdbus option has disappeared from configure
> 
> * Ignore dev-so for PN now since systemd introduced private .so see
>   https://github.com/systemd/systemd/issues/3810
> 
> 
> Signed-off-by: Khem Raj >
> 
> 
> Because systemd-boot basically include the systemd recipe, this breaks
> systemd-boot.
> 
> Can we think up a way to handle systemd/systemd-boot without breaking every
> upgrade?

I have been booting systemd 232 on multiple devices how did it got missed to
compile this ?

> 
> Ross



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

[OE-core] State of bitbake world 2016-11-17

2016-11-18 Thread Martin Jansa 
== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!colspan='6'|Failed depencencies!!|Signatures
!!colspan='12'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64
||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped  
||libdir||textrel   ||build-deps||file-rdeps
||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||  
|-
||2016-11-17||9 ||7 ||6 ||17||9 ||7 ||12||6 
||5 ||0 ||0 ||0 ||2 ||1 
||3 ||24||2 ||0 ||0 
||0 ||0 ||0 ||  
|}

http://www.openembedded.org/wiki/Bitbake_World_Status

== Failed tasks 2016-11-17 ==

INFO: jenkins-job.sh-1.8.12 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20161118_063609.log

=== common (6) ===
* 
meta-openembedded/meta-networking/recipes-support/wireshark/wireshark_2.2.1.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/obexftp/obexftp_0.23.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/obex/obex-data-server_0.4.6.bb:do_compile
* 
meta-openembedded/meta-python/recipes-devtools/python/python3-scales_1.0.9.bb:do_populate_lic
* 
meta-openembedded/meta-xfce/recipes-bindings/vala/xfce4-vala_4.10.3.bb:do_configure
* 
openembedded-core/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb:do_compile

=== common-x86 (0) ===

=== qemuarm (3) ===
* 
meta-openembedded/meta-multimedia/recipes-mediacenter/kodi/kodi_16.bb:do_configure
* 
meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_2.2.2.bb:do_package_qa
* openembedded-core/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb:do_compile

=== qemux86 (1) ===
* meta-browser/recipes-browser/chromium/chromium_52.0.2743.76.bb:do_compile

=== qemux86_64 (0) ===

=== Number of failed tasks (22) ===
{| class=wikitable
|-
|| qemuarm  || 9 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20161116_034630.log/
 || http://errors.yoctoproject.org/Errors/Build/24510/
|-
|| qemux86  || 7 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemux86.20161116_034634.log/
 || http://errors.yoctoproject.org/Errors/Build/24517/
|-
|| qemux86_64   || 6 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemux86-64.20161117_042142.log/
 || http://errors.yoctoproject.org/Errors/Build/24596/
|}
=== PNBLACKLISTs (116) ===
=== QA issues (32) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||symlink-to-sysroot
|-
||0 ||unknown-configure-option
|-
||1 ||build-deps
|-
||24||version-going-backwards
|-
||2 ||host-user-contaminated
|-
||2 ||textrel
|-
||3 ||file-rdeps
|}



=== Failed dependencies for qemuarm (17) ===

Complete log: 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log/
Found differences: 
Found errors: 
* ERROR: 17 issues were found in these recipes: kodi libsdl2 
obex-data-server obexftp python3-scales vlc webkitgtk wireshark xfce4-vala

=== Recipes failing with maximal dependencies for qemuarm (9) ===
* kodi -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/kodi.log
* libsdl2 -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/libsdl2.log
* obex-data-server -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/obex-data-server.log
* obexftp -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/obexftp.log
* python3-scales -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/python3-scales.log
* vlc -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/vlc.log
* webkitgtk -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/webkitgtk.log
* wireshark -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/wireshark.log
* xfce4-vala -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/xfce4-vala.log

=== Recipes failing with minimal dependencies for qemuarm (7) ===

[OE-core] Yocto Project Status WW47

2016-11-18 Thread Jolley, Stephen K 
Current Dev Position: YP 2.3 M1

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


SWAT team rotation: Leo -> Juro

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


Key Status/Updates:

*2.1.2 QA report is out and likely to be released imminently.

*The QA report for 2.1.2 is at: 
https://wiki.yoctoproject.org/wiki/WW46_-_2016-11-10_-_Test_Cycle_2.1.2_rc1

*At this point most 2.3 targeted features should have been identified 
in bugzilla. M1 is comparatively loaded compared to M2/M3 and some individuals 
have particularly heavy workloads so loading balancing is being done.

*We'll run a 2.0.3 test build over the weekend to find out our status 
there.

*Backports of fixes to the morty release branch are now occurring, 
thanks Armin. Armin is looking like the principle morty maintainer for that 
stable release series.

*There are some changes planned to the getVar/getVarFlag expansion 
defaults and the old data store APIs are likely to be removed imminently. There 
is an email on the openembedded-architecture list about this.

*WDD is now climbing again unfortunately, we've wiped out half of the 
improvements we made in the 2.2 cycle.


Proposed upcoming dot releases:

YP 2.0.3 Release by Dec. 9, 2016

YP 2.2.1 Release by Jan. 20, 2017

YP 2.1.3 Release by May. 19, 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 2516 (last week 2497)

(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] Enabling uninative by default in oe-core?

2016-11-18 Thread akuster808 



On 11/17/2016 09:31 AM, Burton, Ross wrote:

Hi,

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


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


If Poky wants the default to use a prebuilt uninative that is fine, but 
it should be not be the default in OE.  In the spirit of Bitbake, 
uninative should be a build dependency for eSDK with the option of using 
a prebuilt one.




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.


Well Bitbake does not work out of the box on every host either. There 
are packages needing to exist on the host as a prerequisite. I see this 
in the same light.

Do we make "Buildtools" a  requirement to use Bitbake?


||
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 see there are multiple versions, which one works with which release?


- Armin


Ross




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

[OE-core] [PATCH] ofono: update 1.18 -> 1.19

2016-11-18 Thread André Draszik 
From: André Draszik 

In particular, this fixes a crash on shutdown.

From upstream's ChangeLog:
ver 1.19:
Fix issue with DHCP parsing and Huawei modems.
Fix issue with detecting Huawei E3372 modem.
Fix issue with handling serving cell info.
Fix issue with handling SIM SC facility lock.
Fix issue with Android RIL PIN retry logic.
Fix issue with Android RIL and RAT handling.
Add support for Android RIL cell broadcast.
Add support for SoFIA 3GR thermal management.

Signed-off-by: André Draszik 
---
 meta/recipes-connectivity/ofono/{ofono_1.18.bb => ofono_1.19.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-connectivity/ofono/{ofono_1.18.bb => ofono_1.19.bb} (52%)

diff --git a/meta/recipes-connectivity/ofono/ofono_1.18.bb 
b/meta/recipes-connectivity/ofono/ofono_1.19.bb
similarity index 52%
rename from meta/recipes-connectivity/ofono/ofono_1.18.bb
rename to meta/recipes-connectivity/ofono/ofono_1.19.bb
index b070731..adebd71 100644
--- a/meta/recipes-connectivity/ofono/ofono_1.18.bb
+++ b/meta/recipes-connectivity/ofono/ofono_1.19.bb
@@ -4,7 +4,7 @@ SRC_URI  = "\
   ${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
   file://ofono \
 "
-SRC_URI[md5sum] = "0a6b37c8ace891cb2a7ca5d121043a0a"
-SRC_URI[sha256sum] = 
"53cdbf342913f46bce4827241c60e24255a3d43a94945edf77482ae5b312d51f"
+SRC_URI[md5sum] = "a5f8803ace110511b6ff5a2b39782e8b"
+SRC_URI[sha256sum] = 
"a0e09bdd8b53b8d2e4b54f1863ecd9aebe4786477a6cbf8f655496e8edb31c81"
 
 CFLAGS_append_libc-uclibc = " -D_GNU_SOURCE"
-- 
2.10.2

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

Re: [OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread Robert P. J. Day 
On Fri, 18 Nov 2016, André Draszik wrote:

> On Fri, 2016-11-18 at 09:09 -0500, Robert P. J. Day wrote:
> > On Fri, 18 Nov 2016, André Draszik wrote:
> >
> > > On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> > > > On Fri, 18 Nov 2016, André Draszik wrote:
> > > >
> > > > > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > > > >   after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > > > > less than a dozen that are going to take more work, and a small
> > > > > > number
> > > > > > of those seem to be simply badly written in that they don't
> > > > > > support
> > > > > > cross-compilation for my target choice of "qemuppc". example
> > > > > > boilerplate recipe i put together produces this:
> > > > > >
> > > > > > $ make libauthen-pam-perl
> > > > > > ... snip ...
> > > > > > Checking if your kit is complete...
> > > > > > Looks good
> > > > > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float
> > > > > > -mcpu=7400
> > > > > > --
> > > > > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroo
> > > > > > ts/q
> > > > > > emup
> > > > > > pc
> > > > > > checking for C compiler default output file name... a.out
> > > > > > checking whether the C compiler works... configure: error: cannot
> > > > > > run
> > > > > > C compiled programs.
> > > > > > If you meant to cross compile, use `--host'.
> > > > > > See `config.log' for more details.
> > > > >
> > > > > It'd be useful to see config.log, ...
> > > >
> > > >   see bottom.
> > >
> > > That message is referring to config.log from autotools, not the
> > > bitbake do_configure.log. Should be somewhere below ${B}
> >
> >   sorry, my mistake ... see below:
> >
> > This file contains any messages produced by compilers while
> > running configure, to aid debugging if configure makes a mistake.
> >
> > It was created by Authen::PAM configure 0.16, which was
> > generated by GNU Autoconf 2.59.  Invocation command line was
> >
> >   $ ./configure
>
> I think the issues are in your recipe. You should see *many* arguments to
> configure. In particular --build= --host= --target=, but many more.
>
> Also, this explains that message:
>
> configure:1697: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.

  i realize that now, so that will be today's project. thanks.

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] small number of perl modules that can't be cross-compiled

2016-11-18 Thread André Draszik 
On Fri, 2016-11-18 at 09:09 -0500, Robert P. J. Day wrote:
> On Fri, 18 Nov 2016, André Draszik wrote:
> 
> > On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> > > On Fri, 18 Nov 2016, André Draszik wrote:
> > > 
> > > > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > > >   after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > > > less than a dozen that are going to take more work, and a small
> > > > > number
> > > > > of those seem to be simply badly written in that they don't
> > > > > support
> > > > > cross-compilation for my target choice of "qemuppc". example
> > > > > boilerplate recipe i put together produces this:
> > > > > 
> > > > > $ make libauthen-pam-perl
> > > > > ... snip ...
> > > > > Checking if your kit is complete...
> > > > > Looks good
> > > > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float
> > > > > -mcpu=7400
> > > > > --
> > > > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroo
> > > > > ts/q
> > > > > emup
> > > > > pc
> > > > > checking for C compiler default output file name... a.out
> > > > > checking whether the C compiler works... configure: error: cannot
> > > > > run
> > > > > C compiled programs.
> > > > > If you meant to cross compile, use `--host'.
> > > > > See `config.log' for more details.
> > > > 
> > > > It'd be useful to see config.log, ...
> > > 
> > >   see bottom.
> > 
> > That message is referring to config.log from autotools, not the
> > bitbake do_configure.log. Should be somewhere below ${B}
> 
>   sorry, my mistake ... see below:
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> It was created by Authen::PAM configure 0.16, which was
> generated by GNU Autoconf 2.59.  Invocation command line was
> 
>   $ ./configure

I think the issues are in your recipe. You should see *many* arguments to
configure. In particular --build= --host= --target=, but many more.

Also, this explains that message:

configure:1697: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.



Cheers,
Andre'

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

Re: [OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread Robert P. J. Day 
On Fri, 18 Nov 2016, André Draszik wrote:

> On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> > On Fri, 18 Nov 2016, André Draszik wrote:
> >
> > > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > >   after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > > less than a dozen that are going to take more work, and a small number
> > > > of those seem to be simply badly written in that they don't support
> > > > cross-compilation for my target choice of "qemuppc". example
> > > > boilerplate recipe i put together produces this:
> > > >
> > > > $ make libauthen-pam-perl
> > > > ... snip ...
> > > > Checking if your kit is complete...
> > > > Looks good
> > > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> > > > --
> > > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/q
> > > > emup
> > > > pc
> > > > checking for C compiler default output file name... a.out
> > > > checking whether the C compiler works... configure: error: cannot run
> > > > C compiled programs.
> > > > If you meant to cross compile, use `--host'.
> > > > See `config.log' for more details.
> > >
> > > It'd be useful to see config.log, ...
> >
> >   see bottom.
>
> That message is referring to config.log from autotools, not the
> bitbake do_configure.log. Should be somewhere below ${B}

  sorry, my mistake ... see below:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Authen::PAM configure 0.16, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ ./configure

## - ##
## Platform. ##
## - ##

hostname = localhost.localdomain
uname -m = x86_64
uname -r = 4.7.7-100.fc23.x86_64
uname -s = Linux
uname -v = #1 SMP Fri Oct 7 22:16:13 UTC 2016

/usr/bin/uname -p = x86_64
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/perl-native
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/oe-core/scripts
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/powerpc-wrs-linux
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/bin/crossscripts
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/sbin
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/sbin
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/oe-core/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake/bin
PATH: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/buildtools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/wrlinux/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/scripts
PATH: /scripts
PATH: /home/rpjday/oe/dist/bin/bb/bin
PATH: /home/rpjday/oe/dist/bin/bb/bin
PATH: /usr/local/bin
PATH: /usr/local/sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /home/rpjday/.local/bin
PATH: /home/rpjday/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/wrlinux/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/wrlcompat/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/local/scripts


## --- ##
## Core tests. ##
## --- ##

configure:1313: checking for gcc
configure:1339: result: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 
--sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc
configure:1583: checking for C compiler version
configure:1586: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 
--sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc 
--version &5
powerpc-wrs-linux-gcc (Wind River Linux 5.2.0-8.0-qemuppc) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:1589: $? = 0
configure:1591: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 
--sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc 
-v &5
Using built-in specs.
COLLECT_GCC=powerpc-wrs-linux-gcc
COLLECT_LTO_WRAPPER=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/libexec/powerpc-wrs-linux/gcc/powerpc-wrs-linux/5.2.0/lto-wrapper
Target: powerpc-wrs-linux
Configured with: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/work-shared/gcc-5.2.0-r0/gcc-5.2.0/configure
 --build=x86_64-linux --host=x86_64-linux --target=powerpc-wrs-linux

Re: [OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread André Draszik 
On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> On Fri, 18 Nov 2016, André Draszik wrote:
> 
> > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > >   after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > less than a dozen that are going to take more work, and a small number
> > > of those seem to be simply badly written in that they don't support
> > > cross-compilation for my target choice of "qemuppc". example
> > > boilerplate recipe i put together produces this:
> > > 
> > > $ make libauthen-pam-perl
> > > ... snip ...
> > > Checking if your kit is complete...
> > > Looks good
> > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> > > --
> > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/q
> > > emup
> > > pc
> > > checking for C compiler default output file name... a.out
> > > checking whether the C compiler works... configure: error: cannot run
> > > C compiled programs.
> > > If you meant to cross compile, use `--host'.
> > > See `config.log' for more details.
> > 
> > It'd be useful to see config.log, ...
> 
>   see bottom.

That message is referring to config.log from autotools, not the bitbake
do_configure.log. Should be somewhere below ${B}

Cheers,
a.

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

Re: [OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread Jens Rehsack 

> Am 18.11.2016 um 13:27 schrieb André Draszik :
> 
> On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
>>   after OE recipfying over 100 perl modules from CPAN, i'm down to
>> less than a dozen that are going to take more work, and a small number
>> of those seem to be simply badly written in that they don't support
>> cross-compilation for my target choice of "qemuppc". example
>> boilerplate recipe i put together produces this:
>> 
>> $ make libauthen-pam-perl
>> ... snip ...
>> Checking if your kit is complete...
>> Looks good
>> checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
>> --
>> sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemup
>> pc
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... configure: error: cannot run
>> C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details.
> 
> It'd be useful to see config.log, ...
> 
>> Error in configuring the Authen::PAM module.
>> ... snip ...
>> 
>>   so i'm assuming the source itself for Authen::PAM:
>> 
>> https://metacpan.org/pod/Authen::PAM
>> 
>> is somehow flawed in that it doesn't properly recognize
>> cross-compilation, would that be it?
> 
> ... there is at least one issue in Authen-PAM-0.16/configure.ac, I would
> say, in that it tries to detect RTLD_GLOBAL support based on the host's
> perl. So it's likely there are more flaws.

Looks as if Makefile.PL doesn't pass all reasonable flags to ./configure call.
Maybe you should send the Author to http://act.yapc.eu/lpw2016/talk/6966 or
at least send him 
http://www.netbsd.org/~sno/talks/nrpm/Cross-Compiling-For-Perl-Hackers.pdf :)

Cheers
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2016-11-18 Thread Burton, Ross 
On 17 November 2016 at 18:20, Pedraza Gonzalez, Francisco J <
francisco.j.pedraza.gonza...@intel.com> wrote:

> Ross: Could you please give more details about PACKAGE_CLASSES?, I am not
> very familiar with.
>

See
http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PACKAGE_CLASSES

By setting it to "package_rpm package_ipk package_deb" you'll be build
packages for all formats, and then rotating the value so each format is
first when you build an image it will be built with each type of package.

For example:

for classes in ("package_rpm package_deb package_ipk",
  "package_deb package_rpm package_ipk",
   "package_ipk package_deb package_rpm"):
  PACKAGE_CLASSES=classes
  bitbake()
  qemu()

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

Re: [OE-core] perl packaging, Makefile.PL versus Build.PL?

2016-11-18 Thread Jens Rehsack 

> Am 18.11.2016 um 11:24 schrieb Robert P. J. Day :
> 
> 
>  still going to have a few more questions on the standards for
> packaging perl source into OE recipes, here's the first one.
> 
>  as i read it, there are two build standards for perl source in OE:
> 
>  cpan.bbclass:Makefile.PL build-based
>  cpan_build.bbclass:  (newer) Build.PL build-based

Err: Wrong - Module::Build has been written after ExtUtil::MakeMaker exists,
but it has been removed from Perl core, because ExtUtils::MakeMaker is
much better maintained and has better compatibilities (even if it still
can improved ^^)

> so if one peruses the source at CPAN, it should be obvious which build
> system is relevant, no? so what about source that has *both* those
> files?
> 
>  https://metacpan.org/pod/Parse::DMIDecode

Look into it: 
https://metacpan.org/source/NICOLAW/Parse-DMIDecode-0.03/Makefile.PL
shows clearly, that the Makefile.PL is a wrapper for cpan shells which don't
support Build.PL (very old, but when Nicola uploaded it in 2007, 5.8 was 
bleeding
edge and 5.004 or 5.005 were widely spread.

You can also refer to 
https://github.com/rehsack/Packager-Utils/blob/master/lib/Packager/Utils/Role/Packages/Bitbake.pm#L507-L517
 for some inspiration.

> which has both of those install scripts in the top-level directory,
> although the INSTALL file clearly refers to the newer build system:
> 
>  perl Build.PL
>  perl Build
>  perl Build test
>  perl Build install
> 
> does it make any logical sense for both of those files to be there?
> backward compatibility? any other reason? or am i just wildly
> misunderstanding something?

For some people: yes. For others: No.

Cheers
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread Robert P. J. Day 
On Fri, 18 Nov 2016, André Draszik wrote:

> On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> >   after OE recipfying over 100 perl modules from CPAN, i'm down to
> > less than a dozen that are going to take more work, and a small number
> > of those seem to be simply badly written in that they don't support
> > cross-compilation for my target choice of "qemuppc". example
> > boilerplate recipe i put together produces this:
> >
> > $ make libauthen-pam-perl
> > ... snip ...
> > Checking if your kit is complete...
> > Looks good
> > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> > --
> > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemup
> > pc
> > checking for C compiler default output file name... a.out
> > checking whether the C compiler works... configure: error: cannot run
> > C compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details.
>
> It'd be useful to see config.log, ...

  see bottom.

> > Error in configuring the Authen::PAM module.
> > ... snip ...
> >
> >   so i'm assuming the source itself for Authen::PAM:
> >
> > https://metacpan.org/pod/Authen::PAM
> >
> > is somehow flawed in that it doesn't properly recognize
> > cross-compilation, would that be it?
>
> ... there is at least one issue in Authen-PAM-0.16/configure.ac, I would
> say, in that it tries to detect RTLD_GLOBAL support based on the host's
> perl. So it's likely there are more flaws.

  that's pretty much all i wanted to confirm at this point -- that it
wasn't something stupid i was doing; rather, the source itself is
flawed, and that's not the only example.

rday

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: Executing shell function do_configure
*** Module name IN: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/Cwd.pm
*** p1: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/  
p3: perl/5.22.0/  p5: Cwd.pm
*** Module name OUT: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/Cwd.pm
*** Module name IN: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/Encode.pm
*** p1: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/  
p3: perl/5.22.0/  p5: Encode.pm
*** Module name OUT: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/Encode.pm
*** Module name IN: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/I18N/Langinfo.pm
*** p1: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/  
p3: perl/5.22.0/  p5: I18N/Langinfo.pm
*** Module name OUT: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/I18N/Langinfo.pm
*** Module name IN: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/B.pm
*** p1: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/  
p3: perl/5.22.0/  p5: B.pm
*** Module name OUT: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/B.pm
*** Module name IN: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/List/Util.pm
*** p1: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/  
p3: perl/5.22.0/  p5: List/Util.pm
*** Module name OUT: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/List/Util.pm
Checking if your kit is complete...
Looks good
checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 
--sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C 
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Error in configuring the Authen::PAM module.
WARNING: 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/work/ppc7400-wrs-linux/libauthen-pam-perl/0.16-r0/temp/do_configure/run.do_configure.16119:1
 exit 25 from
  perl Makefile.PL INSTALLDIRS=vendor
ERROR: Function failed: do_configure (log file is located at 
/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/work/ppc7400-wrs-linux/libauthen-pam-perl/0.16-r0/temp/do_configure/log.do_configure.16119)-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread André Draszik 
On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
>   after OE recipfying over 100 perl modules from CPAN, i'm down to
> less than a dozen that are going to take more work, and a small number
> of those seem to be simply badly written in that they don't support
> cross-compilation for my target choice of "qemuppc". example
> boilerplate recipe i put together produces this:
> 
> $ make libauthen-pam-perl
> ... snip ...
> Checking if your kit is complete...
> Looks good
> checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> --
> sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemup
> pc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... configure: error: cannot run
> C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.

It'd be useful to see config.log, ...

> Error in configuring the Authen::PAM module.
> ... snip ...
> 
>   so i'm assuming the source itself for Authen::PAM:
> 
> https://metacpan.org/pod/Authen::PAM
> 
> is somehow flawed in that it doesn't properly recognize
> cross-compilation, would that be it?

... there is at least one issue in Authen-PAM-0.16/configure.ac, I would
say, in that it tries to detect RTLD_GLOBAL support based on the host's
perl. So it's likely there are more flaws.

A.

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

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

2016-11-18 Thread Patrick Ohly 
On Thu, 2016-11-17 at 09:24 -0700, Christopher Larson wrote:
> 
> On Thu, Nov 17, 2016 at 9:21 AM, Fabio Berton
>  wrote:
> No, I created a patch, git format-patch and then edit
> generated files with Upstream-Status tag and added to recipe.
> Is this wrong?
> 
> As I indicated in my first reply, it’s best to put the tag outside the
> generated patch (above it, or below the —-), as it isn’t part of the
> commit, only part of the patch file.

Now I'm confused. My understanding was that
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations
 explicitly asks for Upstream-Status in the patch header.

Taking an existing example, is
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
 doing it wrong?

>  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.

Yes, that's indeed the effect. That has pros (the Upstream-Status tag is
preserved when working with devtool) and cons (patch as attached to a
recipe is not the same as the patch upstream).

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] [PATCH 1/5] systemd: Upgrade to 232

2016-11-18 Thread Burton, Ross 
On 16 November 2016 at 17:47, Khem Raj  wrote:

> * Drop support for rcS.d SysV init scripts.
>   These are prone to cause dependency loops, and almost all packages with
>   rcS scripts now ship a native systemd service.
>
> * Drop mount propagation patch, it only happens with libseccomp, OE doesnt
>   enable it
>
> * kdbus option has disappeared from configure
>
> * Ignore dev-so for PN now since systemd introduced private .so see
>   https://github.com/systemd/systemd/issues/3810
>
> Signed-off-by: Khem Raj 
>

Because systemd-boot basically include the systemd recipe, this breaks
systemd-boot.

Can we think up a way to handle systemd/systemd-boot without breaking every
upgrade?

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

[OE-core] small number of perl modules that can't be cross-compiled

2016-11-18 Thread Robert P. J. Day 

  after OE recipfying over 100 perl modules from CPAN, i'm down to
less than a dozen that are going to take more work, and a small number
of those seem to be simply badly written in that they don't support
cross-compilation for my target choice of "qemuppc". example
boilerplate recipe i put together produces this:

$ make libauthen-pam-perl
... snip ...
Checking if your kit is complete...
Looks good
checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
--sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run
C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Error in configuring the Authen::PAM module.
... snip ...

  so i'm assuming the source itself for Authen::PAM:

https://metacpan.org/pod/Authen::PAM

is somehow flawed in that it doesn't properly recognize
cross-compilation, would that be it?

  i'm about to peruse the build process, but if someone has a quick
answer as to what the issue is here, there are 2 or 3 other modules
that have exactly the same issue. much thanks.

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] perl packaging, Makefile.PL versus Build.PL?

2016-11-18 Thread Robert P. J. Day 

  still going to have a few more questions on the standards for
packaging perl source into OE recipes, here's the first one.

  as i read it, there are two build standards for perl source in OE:

  cpan.bbclass: Makefile.PL build-based
  cpan_build.bbclass:   (newer) Build.PL build-based

so if one peruses the source at CPAN, it should be obvious which build
system is relevant, no? so what about source that has *both* those
files?

  https://metacpan.org/pod/Parse::DMIDecode

which has both of those install scripts in the top-level directory,
although the INSTALL file clearly refers to the newer build system:

  perl Build.PL
  perl Build
  perl Build test
  perl Build install

does it make any logical sense for both of those files to be there?
backward compatibility? any other reason? or am i just wildly
misunderstanding 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

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

2016-11-18 Thread Richard Purdie 
On Fri, 2016-11-18 at 08:15 +0100, Koen Kooi wrote:
> > 
> > Op 17 nov. 2016, om 18:31 heeft Burton, Ross  > > het volgende geschreven:
> > 
> > Hi,
> > 
> > Background: uninative is a class that downloads a precompiled host
> > glibc 
> Why can’t OE build it on-demand? What’s next, requiring prebuilt
> toolchains?

Its a chicken and egg problem.

We could add a special "uninativesdk" BBCLASSEXTEND range of targets,
then require that it built before we build anything native (or anything
that needs a native tool). This would push build times up 'a little'
and I suspect might not be popular. So the reason we "can't" is that
its impractical, not an absolute technical constraint.

Cheers,

Richard


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

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

2016-11-18 Thread Patrick Ohly 
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 have a patch which I intend to submit to bitbake which adds priorities
for anonymous python methods:
https://github.com/pohly/poky/commit/9d959e50e5f27d149654f5db0aff2fe51365ad68

With that in place, the anonymous python method which transforms the
SRC_URI could request to run sooner than the base.bbclass anonymous
python.

However, I am not sure whether that should be backported to 2.1 and 2.2.

>  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.

Sorry, I don't know about that.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[OE-core] [PATCH][krogoth] Qemu: net: CVE-2016-4001

2016-11-18 Thread Sona Sarmadi 
buffer overflow in stellaris_enet emulator

Reference to upstream patch:
http://git.qemu.org/?p=qemu.git;a=patch;h=3a15cc0e1ee7168db0782133d2607a6bfa422d66

Reference:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4001

Signed-off-by: Sona Sarmadi 
---
 .../recipes-devtools/qemu/qemu/CVE-2016-4001.patch | 51 ++
 meta/recipes-devtools/qemu/qemu_2.5.0.bb   |  1 +
 2 files changed, 52 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch
new file mode 100644
index 000..cfec8b8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch
@@ -0,0 +1,51 @@
+From 3a15cc0e1ee7168db0782133d2607a6bfa422d66 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Fri, 8 Apr 2016 11:33:48 +0530
+Subject: [PATCH] net: stellaris_enet: check packet length against receive
+ buffer
+
+When receiving packets over Stellaris ethernet controller, it
+uses receive buffer of size 2048 bytes. In case the controller
+accepts large(MTU) packets, it could lead to memory corruption.
+Add check to avoid it.
+
+CVE: CVE-2016-4001
+Upstream-Status: Backport
+
+Reported-by: Oleksandr Bazhaniuk 
+Signed-off-by: Prasad J Pandit 
+Message-id: 1460095428-22698-1-git-send-email-ppan...@redhat.com
+Reviewed-by: Peter Maydell 
+Signed-off-by: Peter Maydell 
+Signed-off-by: Sona Sarmadi 
+---
+ hw/net/stellaris_enet.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
+index 84cf60b..6880894 100644
+--- a/hw/net/stellaris_enet.c
 b/hw/net/stellaris_enet.c
+@@ -236,8 +236,18 @@ static ssize_t stellaris_enet_receive(NetClientState *nc, 
const uint8_t *buf, si
+ n = s->next_packet + s->np;
+ if (n >= 31)
+ n -= 31;
+-s->np++;
+ 
++if (size >= sizeof(s->rx[n].data) - 6) {
++/* If the packet won't fit into the
++ * emulated 2K RAM, this is reported
++ * as a FIFO overrun error.
++ */
++s->ris |= SE_INT_FOV;
++stellaris_enet_update(s);
++return -1;
++}
++
++s->np++;
+ s->rx[n].len = size + 6;
+ p = s->rx[n].data;
+ *(p++) = (size + 6);
+-- 
+1.9.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
index b965f69..6823b62 100644
--- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
@@ -28,6 +28,7 @@ SRC_URI += 
"file://configure-fix-Darwin-target-detection.patch \
 file://CVE-2016-5403.patch \
 file://CVE-2016-4441.patch \
 file://CVE-2016-4952.patch \
+file://CVE-2016-4001.patch \
"
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2;
 SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
-- 
1.9.1

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