[OE-core] [PATCH] glibc: Update to 2.24 after hard-freeze

[Khem Raj]

Drop upstreamed patch

Signed-off-by: Khem Raj 
---
 .../glibc/cross-localedef-native_2.24.bb   |  2 +-
 meta/recipes-core/glibc/glibc/elf-meta.patch   | 32 --
 meta/recipes-core/glibc/glibc_2.24.bb  |  3 +-
 3 files changed, 2 insertions(+), 35 deletions(-)
 delete mode 100644 meta/recipes-core/glibc/glibc/elf-meta.patch

diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.24.bb 
b/meta/recipes-core/glibc/cross-localedef-native_2.24.bb
index 104e38b..650c6c3 100644
--- a/meta/recipes-core/glibc/cross-localedef-native_2.24.bb
+++ b/meta/recipes-core/glibc/cross-localedef-native_2.24.bb
@@ -22,7 +22,7 @@ GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
 SRCBRANCH ?= "master"
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+(\.\d+)*)"
 
-SRCREV_glibc ?= "d461c9682d4954076f9ee9e07be903c2eef8e73b"
+SRCREV_glibc ?= "d957c4d3fa48d685ff2726c605c988127ef99395"
 SRCREV_localedef ?= "29869b6dc11427c5bab839bdb155c85a7c644c71"
 
 SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
diff --git a/meta/recipes-core/glibc/glibc/elf-meta.patch 
b/meta/recipes-core/glibc/glibc/elf-meta.patch
deleted file mode 100644
index fab66d7..000
--- a/meta/recipes-core/glibc/glibc/elf-meta.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-Upstream-Status: Pending
-Signed-off-by: Ross Burton 
-
-From a495656665cd4a4f97744741a4741eafa621d65b Mon Sep 17 00:00:00 2001
-From: Ross Burton 
-Date: Mon, 11 Jul 2016 16:57:38 +0100
-Subject: [PATCH] elf.h: add relocations for Imagination META
-
-Adding EM_METAG but not the relocations means the kernel doesn't compile as it
-guards its own declarations on the presence of EM_METAG.

- elf/elf.h | 4 
- 1 file changed, 4 insertions(+)
-
-diff --git a/elf/elf.h b/elf/elf.h
-index b6112d9..69e85a7 100644
 a/elf/elf.h
-+++ b/elf/elf.h
-@@ -3677,6 +3677,10 @@ enum
- 
- #define R_TILEGX_NUM  130
- 
-+/* Imagination META relocs */
-+#define R_METAG_ADDR322
-+#define R_METAG_NONE  3
-+
- /* BPF specific declarations.  */
- 
- #define R_BPF_NONE0   /* No reloc */
--- 
-2.8.1
-
diff --git a/meta/recipes-core/glibc/glibc_2.24.bb 
b/meta/recipes-core/glibc/glibc_2.24.bb
index 456f206..03773c7 100644
--- a/meta/recipes-core/glibc/glibc_2.24.bb
+++ b/meta/recipes-core/glibc/glibc_2.24.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
 
 DEPENDS += "gperf-native"
 
-SRCREV ?= "d461c9682d4954076f9ee9e07be903c2eef8e73b"
+SRCREV ?= "d957c4d3fa48d685ff2726c605c988127ef99395"
 
 #SRCBRANCH ?= "release/${PV}/master"
 SRCBRANCH ?= "master"
@@ -37,7 +37,6 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0023-eglibc-Install-PIC-archives.patch \

file://0024-eglibc-Forward-port-cross-locale-generation-support.patch \
file://0025-Define-DUMMY_LOCALE_T-if-not-defined.patch \
-   file://elf-meta.patch \
 "
 
 SRC_URI += "\
-- 
2.9.0

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

[OE-core] [PATCH 1/1] net-tools: lib/inet6.c:INET6_rresolve() - various fixes [ LIN9-1102 ]

[jianchuan.wang]

From: Shan Hai 

Integrate net-tools upstream commit a70c568b907d to fix a bug which
causes the 'netstat -a' to print "[UNKNOWN]" in case of DNS problem
instead of IPv6 address.

Signed-off-by: Jianchuan Wang 
---
 ...-lib-inet6.c-INET6_rresolve-various-fixes.patch | 87 ++
 .../net-tools/net-tools_1.60-26.bb |  1 +
 2 files changed, 88 insertions(+)
 create mode 100644 
meta/recipes-extended/net-tools/net-tools/0001-lib-inet6.c-INET6_rresolve-various-fixes.patch

diff --git 
a/meta/recipes-extended/net-tools/net-tools/0001-lib-inet6.c-INET6_rresolve-various-fixes.patch
 
b/meta/recipes-extended/net-tools/net-tools/0001-lib-inet6.c-INET6_rresolve-various-fixes.patch
new file mode 100644
index 000..8be45cc
--- /dev/null
+++ 
b/meta/recipes-extended/net-tools/net-tools/0001-lib-inet6.c-INET6_rresolve-various-fixes.patch
@@ -0,0 +1,87 @@
+From 08abfcd923e9f37d1902db26771b1dc6731eb265 Mon Sep 17 00:00:00 2001
+From: Jiri Popelka 
+Date: Fri, 27 Sep 2013 18:40:06 +0200
+Subject: [PATCH 1/1] lib/inet6.c:INET6_rresolve() - various fixes
+
+1) Fall-back to numeric address if getnameinfo fails.
+   Reverse lookup is not mandatory, therefore its fail
+   is not an error. Just return numeric address in that case.
+   This makes netstat/route show IPv6 address instead of
+   [UNKNOWN] in case of DNS problems.
+
+2) Pass length of 'name' buffer into function.
+   'name' is a pointer and therefore sizeof(name)
+   returns size of pointer and not size of the buffer.
+   see 
http://stackoverflow.com/questions/14298710/c-pointers-and-arrays-sizeof-operator
+   The sizeof() usage was added with commit 604785adc,
+   so I checked all the other changes in that commit
+   and they seem to be OK.
+
+3) remove unused 's' variable
+
+Upstream-Status: Pending
+
+Signed-off-by: Shan Hai 
+Signed-off-by: Jianchuan Wang 
+---
+ lib/inet6.c | 21 ++---
+ 1 file changed, 10 insertions(+), 11 deletions(-)
+
+diff --git a/lib/inet6.c b/lib/inet6.c
+index 9a484a0..2a9c459 100644
+--- a/lib/inet6.c
 b/lib/inet6.c
+@@ -84,10 +84,9 @@ static int INET6_resolve(char *name, struct sockaddr_in6 
*sin6)
+ #endif
+ 
+ 
+-static int INET6_rresolve(char *name, struct sockaddr_in6 *sin6, int numeric)
++static int INET6_rresolve(char *name, size_t namelen,
++struct sockaddr_in6 *sin6, int numeric)
+ {
+-int s;
+-
+ /* Grmpf. -FvK */
+ if (sin6->sin6_family != AF_INET6) {
+ #ifdef DEBUG
+@@ -98,21 +97,20 @@ static int INET6_rresolve(char *name, struct sockaddr_in6 
*sin6, int numeric)
+   return (-1);
+ }
+ if (numeric & 0x7FFF) {
+-  inet_ntop( AF_INET6, >sin6_addr, name, 80);
++  inet_ntop( AF_INET6, >sin6_addr, name, namelen);
+   return (0);
+ }
+ if (IN6_IS_ADDR_UNSPECIFIED(>sin6_addr)) {
+ if (numeric & 0x8000)
+-  strcpy(name, "default");
++  safe_strncpy(name, "default", namelen);
+   else
+-  strcpy(name, "[::]");
++  safe_strncpy(name, "[::]", namelen);
+   return (0);
+ }
+ 
+-if ((s = getnameinfo((struct sockaddr *) sin6, sizeof(struct 
sockaddr_in6),
+-   name, 255 /* !! */ , NULL, 0, 0))) {
+-  fputs("getnameinfo failed\n", stderr);
+-  return -1;
++if (getnameinfo((struct sockaddr *) sin6, sizeof(struct sockaddr_in6),
++  name, namelen , NULL, 0, 0)) {
++  inet_ntop( AF_INET6, >sin6_addr, name, namelen);
+ }
+ return (0);
+ }
+@@ -143,7 +141,8 @@ static char *INET6_sprint(struct sockaddr *sap, int 
numeric)
+ 
+ if (sap->sa_family == 0x || sap->sa_family == 0)
+   return safe_strncpy(buff, _("[NONE SET]"), sizeof(buff));
+-if (INET6_rresolve(buff, (struct sockaddr_in6 *) sap, numeric) != 0)
++if (INET6_rresolve(buff, sizeof(buff),
++ (struct sockaddr_in6 *) sap, numeric) != 0)
+   return safe_strncpy(buff, _("[UNKNOWN]"), sizeof(buff));
+ return (fix_v4_address(buff, &((struct sockaddr_in6 *)sap)->sin6_addr));
+ }
+-- 
+1.8.5.2.233.g932f7e4
+
diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index 759de0a..9c2adfa 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -15,6 +15,7 @@ SRC_URI = 
"http://snapshot.debian.org/archive/debian/20050312T00Z/pool/main/
file://net-tools-1.60-sctp1.patch \
file://net-tools-1.60-sctp2-quiet.patch \
file://net-tools-1.60-sctp3-addrs.patch \
+   file://0001-lib-inet6.c-INET6_rresolve-various-fixes.patch \
   "
 
 # for this package we're mostly interested in tracking debian patches,
-- 
2.8.1

-- 
___
Openembedded-core mailing list

Re: [OE-core] [PATCH V3] rootfs.py: allow removal of support packages

[Stephano Cetola]

On 07/18, Burton, Ross wrote:
> On 11 July 2016 at 18:55, Stephano Cetola 
> wrote:
> 
> > +unneeded_pkgs.extend(self.d.getVar("ROOTFS_BOOTSTRAP_INSTALL",
> > +True).split(","))
> >
> 
> Sorry for not getting around to reviewing this...
> 
> That variable is whitespace separated, not comma.
> 
> Ross

There should be a V4 out there already that splits off space. Not sure what I
was thinking here, but I realized pretty quickly my mistake :)

https://patchwork.openembedded.org/patch/126893/

Cheers,
Stephano

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

Re: [OE-core] [Openembedded-architecture] Removal of uclibc from oe-core?

[Mark Hatle]

On 7/18/16 6:27 PM, Khem Raj wrote:
> 
>> On Jul 18, 2016, at 3:48 PM, Bruce Ashfield > > wrote:
>>
>>
>>
>> On Mon, Jul 18, 2016 at 6:18 PM, Phil Blundell > > wrote:
>>
>> On Mon, 2016-07-18 at 23:01 +0100, Burton, Ross wrote:
>>
>> > Now that musl is fairly mature I think it's time to take uclibc out to
>> > pasture, where the pasture is possibly called meta-uclibc.
>>
>> I think this is a splendid idea.
>>
>>
>> Agreed.
>>
>> But do we need a sharpened stake to make sure it doesn't come back ?
> 
> I think its just about time. Given the health of uclibc project and 
> maintenance
> burden we impose on OE-Core, if someone
> needs to have it beyond 2.1, please step up and we can create a new layer
> mnta-uclibc and it can be hosted there. but it
> certainly should go out of OE-Core. 

Agreed.

--Mark

>>
>> Bruce
>>  
>>
>>
>> p.
>>
>>
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> 
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>>
>> -- 
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at
>> its end"
>> -- 
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> 
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 

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

Re: [OE-core] [Openembedded-architecture] Removal of uclibc from oe-core?

[Khem Raj]

> On Jul 18, 2016, at 3:48 PM, Bruce Ashfield  wrote:
> 
> 
> 
> On Mon, Jul 18, 2016 at 6:18 PM, Phil Blundell  > wrote:
> On Mon, 2016-07-18 at 23:01 +0100, Burton, Ross wrote:
> 
> > Now that musl is fairly mature I think it's time to take uclibc out to
> > pasture, where the pasture is possibly called meta-uclibc.
> 
> I think this is a splendid idea.
> 
> Agreed.
> 
> But do we need a sharpened stake to make sure it doesn't come back ?

I think its just about time. Given the health of uclibc project and maintenance 
burden we impose on OE-Core, if someone
needs to have it beyond 2.1, please step up and we can create a new layer 
mnta-uclibc and it can be hosted there. but it
certainly should go out of OE-Core.

> 
> Bruce
> 
> 
> p.
> 
> 
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org 
> 
> http://lists.openembedded.org/mailman/listinfo/openembedded-core 
> 
> 
> 
> 
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
> its end"
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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] [Openembedded-architecture] Removal of uclibc from oe-core?

[Bruce Ashfield]

On Mon, Jul 18, 2016 at 6:18 PM, Phil Blundell  wrote:

> On Mon, 2016-07-18 at 23:01 +0100, Burton, Ross wrote:
>
> > Now that musl is fairly mature I think it's time to take uclibc out to
> > pasture, where the pasture is possibly called meta-uclibc.
>
> I think this is a splendid idea.
>

Agreed.

But do we need a sharpened stake to make sure it doesn't come back ?

Bruce


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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Removal of uclibc from oe-core?

[Phil Blundell]

On Mon, 2016-07-18 at 23:01 +0100, Burton, Ross wrote:

> Now that musl is fairly mature I think it's time to take uclibc out to
> pasture, where the pasture is possibly called meta-uclibc.

I think this is a splendid idea.

p.



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

Re: [OE-core] [PATCHv3 1/2] cve-check-tool: Add recipe

[Mariano Lopez]

On 07/12/2016 05:19 PM, akuster808 wrote:

Mariano,


On 07/11/2016 05:52 AM, mariano.lo...@linux.intel.com wrote:

From: Mariano Lopez 

cve-check-tool is a program for public CVEs checking.
This tool also seek to determine if a vulnerability has
been addressed by a patch.

By tool do you mean the "cve-check-tool"? All the Nvd DB can tell you if
an CVE has been assigned, anything more than that is not guaranteed.

Look at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-5320


Sorry for the confusion, here I was referring to patches in OE that 
address the CVE, the class will look for the CVE tag for this.





The recipe also includes the do_populate_cve_db task
that will populate the database used by the tool.

This DB is big. May want to add a note to that affect. Maybe a note
about how to share the DB across builds like with the AB.


You are right, the DB is big and it will take some time to download. By 
default the tool will download the DB to DL_DIR, so if you have this dir 
shared, it will be downloaded just one time, and incremental updates later.




time for me to play with this.

Thanks for driving this.


Glad to be helping with this.


regards,
Armin


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

[OE-core] Removal of uclibc from oe-core?

[Burton, Ross]

Hi,

Now that musl is fairly mature I think it's time to take uclibc out to
pasture, where the pasture is possibly called meta-uclibc.

Carrying excessive numbers of C libraries in OE Core isn't really ideal,
and musl approximates the size of uclibc whilst being far more feature
complete.  I have a patch to remove the uclibc recipes from OE Core whilst
keeping the infrastructure so a meta-uclibc would be possible if someone is
interested in keeping in alive going forward.  Is anyone interested in
creating and maintaining a meta-uclibc?  Is anyone horrified at the
prospect of uclibc being removed from oe-core?

Feedback welcome!

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

[OE-core] [PATCH] webkitgtk: Switch the ARMv7 build to Thumb2 and enable back the JSC JIT.

[Carlos Alberto Lopez Perez]

* The JSC JIT is broken on ARMv7 without Thumb2.

[YOCTO #9474]

Signed-off-by: Carlos Alberto Lopez Perez 
---
 meta/recipes-sato/webkit/webkitgtk_2.12.3.bb | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb
index c5e5432..536fa23 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb
@@ -71,10 +71,6 @@ EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
 EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
 EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
 
-# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
-# displaying problems or ephiphany hang.
-EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "
-
 # binutils 2.25.1 has a bug on aarch64:
 # https://sourceware.org/bugzilla/show_bug.cgi?id=18430
 EXTRA_OECMAKE_append_aarch64 = " -DUSE_LD_GOLD=OFF "
@@ -89,7 +85,18 @@ SECURITY_CFLAGS_append_aarch64 = " -fPIE"
 FILES_${PN} += 
"${libdir}/webkit2gtk-4.0/injected-bundle/libwebkit2gtkinjectedbundle.so"
 
 # http://errors.yoctoproject.org/Errors/Details/20370/
-ARM_INSTRUCTION_SET = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+ARM_INSTRUCTION_SET_armv6 = "arm"
+
+# https://bugzilla.yoctoproject.org/show_bug.cgi?id=9474
+# https://bugs.webkit.org/show_bug.cgi?id=159880
+# JSC JIT can build on ARMv7 with -marm, but doesn't work on runtime.
+# Upstream only tests regularly the JSC JIT on ARMv7 with Thumb2 (-mthumb).
+ARM_INSTRUCTION_SET_armv7a = "thumb"
+ARM_INSTRUCTION_SET_armv7r = "thumb"
+ARM_INSTRUCTION_SET_armv7m = "thumb"
+ARM_INSTRUCTION_SET_armv7ve = "thumb"
 
 # Invalid data memory access: 0x
 # ...
-- 
2.1.4

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

Re: [OE-core] [PATCH V3] rootfs.py: allow removal of support packages

[Burton, Ross]

On 11 July 2016 at 18:55, Stephano Cetola 
wrote:

> +unneeded_pkgs.extend(self.d.getVar("ROOTFS_BOOTSTRAP_INSTALL",
> +True).split(","))
>

Sorry for not getting around to reviewing this...

That variable is whitespace separated, not comma.

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

Re: [OE-core] [oe][Patch] package.bbclass: fix host contamination warnings for source files

[Max Krummenacher]

Hi

Am Sonntag, den 03.04.2016, 22:45 +0100 schrieb Richard Purdie:
> On Sun, 2016-04-03 at 22:57 +0200, Max Krummenacher wrote:
> > Addresses https://bugzilla.yoctoproject.org/show_bug.cgi?id=8939
> > 
> > Source files deployed with the *-dbg packages are owned by the user
> > running bitbake leading to warnings as the one below.
> > 
> > WARNING: glibc-2.23-r0 do_package_qa: QA Issue: glibc: /glibc
> > -dbg/usr/src/debug/glibc/2.23-r0/git/include/resolv.h is owned by
> > uid
> > 1000, which is the same as the user running bitbake. This may be
> > due
> > to host contamination
> > glibc: /glibc-dbg/usr/src/debug/glibc/2.23
> > -r0/git/include/monetary.h
> > is owned by uid 1000, which is the same as the user running
> > bitbake.
> > This may be due to host contamination
> > glibc: /glibc-dbg/usr/src/debug/glibc/2.23-r0/git/include/locale.h
> > is
> > owned by uid 1000, which is the same as the user running bitbake.
> > This may be due to host contamination
> > ...
> > 
> > The files are copied as part of the do_package task.
> > The patch chowns all file in packages/usr/src after cpio copied
> > them
> > into the
> > package directory.
> > 
> > Signed-off-by: Max Krummenacher 
> > ---
> > 
> > 
> >  meta/classes/package.bbclass | 23 +++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/meta/classes/package.bbclass
> > b/meta/classes/package.bbclass
> > index bdbe96d..d9ef62c 100644
> > --- a/meta/classes/package.bbclass
> > +++ b/meta/classes/package.bbclass
> > @@ -362,6 +362,7 @@ def copydebugsources(debugsrcdir, d):
> >  # and copied to the destination here.
> >  
> >  import stat
> > +import subprocess
> >  
> >  sourcefile = d.expand("${WORKDIR}/debugsources.list")
> >  if debugsrcdir and os.path.isfile(sourcefile):
> > @@ -410,6 +411,28 @@ def copydebugsources(debugsrcdir, d):
> >  if retval:
> >  bb.fatal("debugsrc symlink fixup failed with exit code
> > %s (cmd was %s)" % (retval, cmd))
> >  
> > +# cpio --no-preserve-owner does not create the destination
> > files with
> > +# owner root even when run under pseudo, chown them
> > explicitely.
> 
> How about passing --owner=0:0 to cpio? 
> 
> I'm a little worried about why I don't see this failure on my own
> local
> builds.
> 
> We have a few cases where things sometimes seem to work out and
> sometimes don't and I'd love to get to the bottom of how to reproduce
> it and to understand why its different for different people.

I finally got enough time to investigate further.

I found cpio -l (i.e. createing hardlinks) under pseudo does not set
the owner to root, neither width --no-preserve-owner nor width -
-owner=0:0.

The file ownership in yocto is corrected later with fs-perms.txt.
Angstrom does provide its own fs perms configuration which disables the
oe-core fs-perms.txt. But due to a bug the angstrom file is not active.
Patch sent to the angstrom ML.
http://article.gmane.org/gmane.linux.distributions.angstrom.devel/7856

Max

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

Re: [OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args

[Tom Hochstein]

Re-sent.

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, July 18, 2016 11:29 AM
To: Otavio Salvador 
Cc: Tom Hochstein ; Otavio Salvador 
; Patches and discussions about the oe-core layer 

Subject: Re: [OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow 
weston args without openvt args

I can only see 1/3 and 3/3, but no 2/3.

On 18 July 2016 at 16:13, Otavio Salvador 
> 
wrote:
On Mon, Jul 18, 2016 at 11:43 AM, Tom Hochstein 
> wrote:
> The parser didn't properly handle commands of the form
> weston-start -- .
>
> Signed-off-by: Tom Hochstein 
> >



Acked-by: Otavio Salvador 
>

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: 
+1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[OE-core] [PATCH v3 2/3] weston-init: Fix weston-start to handle 0 or 1 args

[Tom Hochstein]

The parser incorrectly treated anything less than 2 args as an error.

Signed-off-by: Tom Hochstein 
---
 meta/recipes-graphics/wayland/weston-init/weston-start | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index d7358ba..cd64216 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -6,7 +6,7 @@ export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
 
 usage() {
 cat < -- 
+$0 [] [-- ]
 EOF
 }
 
@@ -23,11 +23,6 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
 }
 
-if test $# -lt 2; then
-   usage
-   exit 1
-fi
-
 if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston 
instance is not supported yet."
exit 1
-- 
1.9.1

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

Re: [OE-core] [PATCH 2/2] juce: Added support for JUCE framework

[Burton, Ross]

On 18 July 2016 at 19:04, Felipe Ferreri Tonello 
wrote:

> Ok. Nevertheless the first patch is valid for oe-core.
>

Agreed, already queued it for testing. :)

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

Re: [OE-core] [PATCH 2/2] juce: Added support for JUCE framework

[Felipe Ferreri Tonello]

Hi Ross,

On 18/07/16 11:13, Burton, Ross wrote:
> 
> On 18 July 2016 at 11:07, Felipe Ferreri Tonello  > wrote:
> 
> I can send this as part of meta-multimedia, no problem. What is the
> process to promote a recipe to oe-core?
> 
> 
> To be part of oe-core you basically need to be able to demonstrate that
> a large proportion of users will need it.  As this is an audio
> framework, meta-multimedia is the obvious home for it.
> 

Ok. Nevertheless the first patch is valid for oe-core.

Thanks.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] kernel-fitimage: Add x86 support

[George McCollister]

For x86, bzImage must be built instead of zImage.

Include setup.bin (which is required to boot the kernel) in the fitimage
and always use a load/boot address of 0x0009.

For details see:
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/x86-fit-boot.txt

Signed-off-by: George McCollister 
---
 meta/classes/kernel-fitimage.bbclass | 112 +--
 1 file changed, 82 insertions(+), 30 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index ede69e7..d4e3ed8 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -7,12 +7,17 @@ python __anonymous () {
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
 
+if d.getVar("UBOOT_ARCH", True) == "x86":
+replacementtype = "bzImage"
+else:
+replacementtype = "zImage"
+
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
 typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
 if 'fitImage' in typeformake.split():
-d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
typeformake.replace('fitImage', 'zImage'))
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
typeformake.replace('fitImage', replacementtype))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -138,6 +143,33 @@ EOF
 }
 
 #
+# Emit the fitImage ITS setup section
+#
+# $1 ... .its filename
+# $2 ... Image counter
+# $3 ... Path to setup image
+fitimage_emit_section_setup() {
+
+   setup_csum="sha1"
+
+   cat << EOF >> ${1}
+setup@${2} {
+description = "Linux setup.bin";
+data = /incbin/("${3}");
+type = "x86_setup";
+arch = "${UBOOT_ARCH}";
+os = "linux";
+compression = "none";
+load = <0x0009>;
+entry = <0x0009>;
+hash@1 {
+algo = "${setup_csum}";
+};
+};
+EOF
+}
+
+#
 # Emit the fitImage ITS ramdisk section
 #
 # $1 ... .its filename
@@ -171,6 +203,7 @@ EOF
 # $2 ... Linux kernel ID
 # $3 ... DTB image ID
 # $4 ... ramdisk ID
+# $5 ... config ID
 fitimage_emit_section_config() {
 
conf_csum="sha1"
@@ -179,24 +212,25 @@ fitimage_emit_section_config() {
fi
 
# Test if we have any DTBs at all
-   if [ -z "${3}" -a -z "${4}" ] ; then
-   conf_desc="Boot Linux kernel"
-   fdt_line=""
-   ramdisk_line=""
-   elif [ -z "${4}" ]; then
-   conf_desc="Boot Linux kernel with FDT blob"
-   fdt_line="fdt = \"fdt@${3}\";"
-   ramdisk_line=""
-   elif [ -z "${3}" ]; then
-   conf_desc="Boot Linux kernel with ramdisk"
-   fdt_line=""
-   ramdisk_line="ramdisk = \"ramdisk@${4}\";"
-   else
-   conf_desc="Boot Linux kernel with FDT blob, ramdisk"
+   conf_desc="Linux kernel"
+   kernel_line="kernel = \"kernel@${2}\";"
+   fdt_line=""
+   ramdisk_line=""
+
+   if [ -n "${3}" ]; then
+   conf_desc="${conf_desc}, FDT blob"
fdt_line="fdt = \"fdt@${3}\";"
+   fi
+
+   if [ -n "${4}" ]; then
+   conf_desc="${conf_desc}, ramdisk"
ramdisk_line="ramdisk = \"ramdisk@${4}\";"
fi
-   kernel_line="kernel = \"kernel@${2}\";"
+
+   if [ -n "${5}" ]; then
+   conf_desc="${conf_desc}, setup"
+   setup_line="setup = \"setup@${5}\";"
+   fi
 
cat << EOF >> ${1}
 default = "conf@1";
@@ -205,6 +239,7 @@ fitimage_emit_section_config() {
${kernel_line}
${fdt_line}
${ramdisk_line}
+   ${setup_line}
 hash@1 {
 algo = "${conf_csum}";
 };
@@ -212,16 +247,22 @@ EOF
 
if [ ! -z "${conf_sign_keyname}" ] ; then
 
-   if [ -z "${3}" -a -z "${4}" ] ; then
-   sign_line="sign-images = \"kernel\";"
-   elif [ -z "${4}" ]; then
-   sign_line="sign-images = \"fdt\", \"kernel\";"
-   elif [ -z "${3}" ]; then
-   sign_line="sign-images = \"ramdisk\", \"kernel\";"
-   else
-   sign_line="sign-images = \"ramdisk\", \"fdt\", 
\"kernel\";"
+   sign_line="sign-images = \"kernel\""
+
+   if [ -n "${3}" ]; then
+   sign_line="${sign_line}, \"fdt\""
+ 

[OE-core] [PATCH v2 1/3] kernel-fitimage: add initramfs support

[George McCollister]

If INITRAMFS_IMAGE is set, build an additional fitImage containing the
initramfs. Copy the additional fitImage and the source (*.its) file, used
to create it to DEPLOYDIR. The fitImage containing the initramfs must be
built before do_deploy and after do_install to avoid circular dependencies.

UBOOT_RD_LOADADDRESS - Specifies the load address used by u-boot for the
   initramfs.
UBOOT_RD_ENTRYPOINT  - Specifies the entry point used by u-boot for the
   initramfs.

Signed-off-by: George McCollister 
---
 meta/classes/kernel-fitimage.bbclass | 282 +++
 1 file changed, 187 insertions(+), 95 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 9a3caf5..ede69e7 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -16,7 +16,7 @@ python __anonymous () {
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
-d.appendVarFlag('do_assemble_fitimage', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
+d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
 
 # Verified boot will sign the fitImage and append the public key to
 # U-boot dtb. We ensure the U-Boot dtb is deployed before assembling
@@ -32,8 +32,9 @@ UBOOT_MKIMAGE_DTCOPTS ??= ""
 #
 # Emit the fitImage ITS header
 #
+# $1 ... .its filename
 fitimage_emit_fit_header() {
-   cat << EOF >> fit-image.its
+   cat << EOF >> ${1}
 /dts-v1/;
 
 / {
@@ -45,32 +46,33 @@ EOF
 #
 # Emit the fitImage section bits
 #
-# $1 ... Section bit type: imagestart - image section start
+# $1 ... .its filename
+# $2 ... Section bit type: imagestart - image section start
 #  confstart  - configuration section start
 #  sectend- section end
 #  fitend - fitimage end
 #
 fitimage_emit_section_maint() {
-   case $1 in
+   case $2 in
imagestart)
-   cat << EOF >> fit-image.its
+   cat << EOF >> ${1}
 
 images {
 EOF
;;
confstart)
-   cat << EOF >> fit-image.its
+   cat << EOF >> ${1}
 
 configurations {
 EOF
;;
sectend)
-   cat << EOF >> fit-image.its
+   cat << EOF >> ${1}
};
 EOF
;;
fitend)
-   cat << EOF >> fit-image.its
+   cat << EOF >> ${1}
 };
 EOF
;;
@@ -80,9 +82,10 @@ EOF
 #
 # Emit the fitImage ITS kernel section
 #
-# $1 ... Image counter
-# $2 ... Path to kernel image
-# $3 ... Compression type
+# $1 ... .its filename
+# $2 ... Image counter
+# $3 ... Path to kernel image
+# $4 ... Compression type
 fitimage_emit_section_kernel() {
 
kernel_csum="sha1"
@@ -90,17 +93,17 @@ fitimage_emit_section_kernel() {
ENTRYPOINT=${UBOOT_ENTRYPOINT}
if test -n "${UBOOT_ENTRYSYMBOL}"; then
ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
-   awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
+   awk '$4=="${UBOOT_ENTRYSYMBOL}" {print $2}'`
fi
 
-   cat << EOF >> fit-image.its
-kernel@${1} {
+   cat << EOF >> ${1}
+kernel@${2} {
 description = "Linux kernel";
-data = /incbin/("${2}");
+data = /incbin/("${3}");
 type = "kernel";
 arch = "${UBOOT_ARCH}";
 os = "linux";
-compression = "${3}";
+compression = "${4}";
 load = <${UBOOT_LOADADDRESS}>;
 entry = <${ENTRYPOINT}>;
 hash@1 {
@@ -113,16 +116,17 @@ EOF
 #
 # Emit the fitImage ITS DTB section
 #
-# $1 ... Image counter
-# $2 ... Path to DTB image
+# $1 ... .its filename
+# $2 ... Image counter
+# $3 ... Path to DTB image
 fitimage_emit_section_dtb() {
 
dtb_csum="sha1"
 
-   cat << EOF >> fit-image.its
-fdt@${1} {
+   cat << EOF >> ${1}
+fdt@${2} {
 description = "Flattened Device Tree blob";
-data = /incbin/("${2}");
+data = /incbin/("${3}");
 type = "flat_dt";
 arch = "${UBOOT_ARCH}";
 compression = "none";
@@ -134,10 +138,39 @@ EOF
 }
 
 #
+# Emit the fitImage ITS ramdisk section
+#
+# $1 ... .its filename
+# $2 ... Image counter
+# $3 ... Path to ramdisk image
+fitimage_emit_section_ramdisk() {
+
+   ramdisk_csum="sha1"
+
+   cat << EOF >> ${1}
+ramdisk@${2} {
+description = "ramdisk image";
+data = /incbin/("${3}");
+   

[OE-core] [PATCH 3/3] uboot-sign: Handle .rom signing the same as .img

[George McCollister]

Handle u-boot.rom signing (U-Boot as x86 BIOS replacement) the same way
that u-boot.img signing is handled.

Signed-off-by: George McCollister 
---
 meta/classes/uboot-sign.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 57d4903..d56ad8e 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -64,7 +64,8 @@ do_concat_dtb () {
# Concatenate U-Boot w/o DTB & DTB with public key
# (cf. kernel-fitimage.bbclass for more details)
if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ]; then
-   if [ "x${UBOOT_SUFFIX}" = "ximg" -a -e 
"${DEPLOYDIR}/${UBOOT_DTB_IMAGE}" ]; then
+   if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom" 
] && \
+   [ -e "${DEPLOYDIR}/${UBOOT_DTB_IMAGE}" ]; then
oe_runmake EXT_DTB=${DEPLOYDIR}/${UBOOT_DTB_IMAGE}
install ${S}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
install ${S}/${UBOOT_BINARY} 
${DEPLOY_DIR_IMAGE}/${UBOOT_IMAGE}
-- 
2.8.0

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

[OE-core] [PATCH 0/3] kernel-fitimage: Add initramfs, x86 support

[George McCollister]

Add support for building fitImages that include an initramfs and booting
on x86.

The following changes since commit da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6:

  useradd-staticids: use map() instead of imap() (2016-07-12 23:11:57 +0100)

are available in the git repository at:

  git://github.com/gmccollister/openembedded-core master-fit
  https://github.com/gmccollister/openembedded-core/tree/master-fit

George McCollister (3):
  kernel-fitimage: add initramfs support
  kernel-fitimage: Add x86 support
  uboot-sign: Handle .rom signing the same as .img

 meta/classes/kernel-fitimage.bbclass | 344 +--
 meta/classes/uboot-sign.bbclass  |   3 +-
 2 files changed, 246 insertions(+), 101 deletions(-)

-- 
2.8.0

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

[OE-core] [PATCH v3 2/3] weston-init: Fix weston-start to handle 0 or 1 args

[Tom Hochstein]

The parser incorrectly treated anything less than 2 args as an error.

Signed-off-by: Tom Hochstein 
---
 meta/recipes-graphics/wayland/weston-init/weston-start | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index d7358ba..cd64216 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -6,7 +6,7 @@ export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
 
 usage() {
 cat < -- 
+$0 [] [-- ]
 EOF
 }
 
@@ -23,11 +23,6 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
 }
 
-if test $# -lt 2; then
-   usage
-   exit 1
-fi
-
 if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston 
instance is not supported yet."
exit 1
-- 
1.9.1

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

Re: [OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args

[Burton, Ross]

I can only see 1/3 and 3/3, but no 2/3.

On 18 July 2016 at 16:13, Otavio Salvador 
wrote:

> On Mon, Jul 18, 2016 at 11:43 AM, Tom Hochstein 
> wrote:
> > The parser didn't properly handle commands of the form
> > weston-start -- .
> >
> > Signed-off-by: Tom Hochstein 
>
>
>
> Acked-by: Otavio Salvador 
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 1/3] weston-init: De-couple framebuffer console from Weston for systemd startup

[Tom Hochstein]

The framebuffer console was using the same I/O as Weston. We fix this
by having openvt switch to the new VT when starting weston-launch, same
as is already done for the sysvinit case.

Signed-off-by: Tom Hochstein 
---
 meta/recipes-graphics/wayland/weston-init/init | 2 +-
 meta/recipes-graphics/wayland/weston-init/weston-start | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston-init/init 
b/meta/recipes-graphics/wayland/weston-init/init
index 5c925f4..d3e87c6 100644
--- a/meta/recipes-graphics/wayland/weston-init/init
+++ b/meta/recipes-graphics/wayland/weston-init/init
@@ -31,7 +31,7 @@ case "$1" in
   start)
 . /etc/profile
 
-weston-start -s -- $OPTARGS
+weston-start -- $OPTARGS
   ;;
 
   stop)
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index 5b7604f..d7358ba 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -1,5 +1,6 @@
 #!/bin/sh
 # Copyright (C) 2016 O.S. Systems Software LTDA.
+# Copyright (C) 2016 Freescale Semiconductor
 
 export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
 
@@ -37,7 +38,7 @@ else
launcher="weston-launch --"
 fi
 
-openvt_args=""
+openvt_args="-s"
 while [ -n "$1" ]; do
openvt_args="$openvt_args $1"
shift
-- 
1.9.1

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

Re: [OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args

[Otavio Salvador]

On Mon, Jul 18, 2016 at 11:43 AM, Tom Hochstein  wrote:
> The parser didn't properly handle commands of the form
> weston-start -- .
>
> Signed-off-by: Tom Hochstein 



Acked-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 1/3] weston-init: De-couple framebuffer console from Weston for systemd startup

[Otavio Salvador]

On Mon, Jul 18, 2016 at 11:43 AM, Tom Hochstein  wrote:
> The framebuffer console was using the same I/O as Weston. We fix this
> by having openvt switch to the new VT when starting weston-launch, same
> as is already done for the sysvinit case.
>
> Signed-off-by: Tom Hochstein 

Acked-by: Otavio Salvador 


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 2/3] weston-init: Fix weston-start to handle 0 or 1 args

[Otavio Salvador]

On Mon, Jul 18, 2016 at 11:43 AM, Tom Hochstein  wrote:
> The parser incorrectly treated anything less than 2 args as an error.
>
> Signed-off-by: Tom Hochstein 



Acked-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args

[Tom Hochstein]

The parser didn't properly handle commands of the form
weston-start -- .

Signed-off-by: Tom Hochstein 
---
 meta/recipes-graphics/wayland/weston-init/weston-start | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index cd64216..e72fbaa 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -35,13 +35,12 @@ fi
 
 openvt_args="-s"
 while [ -n "$1" ]; do
-   openvt_args="$openvt_args $1"
-   shift
-
if [ "$1" = "--" ]; then
shift
break
fi
+   openvt_args="$openvt_args $1"
+   shift
 done
 
 weston_args=$*
-- 
1.9.1

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

Re: [OE-core] [PATCH 3/8] wayland: Upgrade 1.10.0 -> 1.11.0

[Khem Raj]

On Mon, Jul 18, 2016 at 6:30 AM, Jussi Kukkonen
 wrote:
> On 16 July 2016 at 02:25, Khem Raj  wrote:
>>
>> On Jul 15, 2016, at 3:15 PM, Burton, Ross  wrote:
>>
>>
>> On 15 July 2016 at 11:41, Jussi Kukkonen  wrote:
>>>
>>> Signed-off-by: Jussi Kukkonen 
>>
>>
>> This breaks with musl:
>>
>> | ../wayland-1.11.0/src/scanner.c: In function 'find_enumeration':
>> | ../wayland-1.11.0/src/scanner.c:811:2: error: unknown type name 'uint'
>> |   uint idx = 0, j;
>>
>>
>> Fixed with
>> https://patchwork.freedesktop.org/patch/98992/
>>
>> Please back port and test
>>
>
> Thanks Khem,
>
> I've added one more small fix to weston, and things build on musl now.
> Unfortunately at boot time I get the same versioned symbol relocation
> problem that vte has:
>   gbm: failed to open any driver (search paths /usr/lib/dri)
>   gbm: last dlopen error: Error relocating /lib/libgcc_s.so.1:
> __cpu_indicator_init: symbol not found
>   failed to load driver: i965

this was reported earlier too. I havent had a chance to look and root
causing it. Can you trying adding ASNEEDED=""
to recipe and see if that helps

>
> This is with mesa 12.0.1 from this same patchset. I'll resend the set in a
> minute.
>
> Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] glibc: Upgrade to latest tip of master

[Khem Raj]

I also enable security flags

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc

INHERIT += "uninative"

On Mon, Jul 18, 2016 at 5:16 AM, Trevor Woerner  wrote:
> On Fri 2016-07-08 @ 01:55:18 PM, Khem Raj wrote:
>> Trevor
>>
>> On Thu, Jul 7, 2016 at 1:25 PM, Khem Raj  wrote:
>> > Ok thanks. Let me know if you get to see the same issue on say qemuarm or
>> > qemuarm64
>>
>> I built core-image-sato/qemux86-64 vmdk with chromium added
>>
>> CORE_IMAGE_EXTRA_INSTALL_append = " chromium "
>>
>> launched this image in VM and chromium starts normally.
>
> Someday I hope that we'll have a mechanism in place that will be able to
> better record the full information about a build to help make it easier for
> multiple people to fully recreate the exact same builds, independently (iow,
> in situations like this).
>
> I've done my best to recreate your build, and I'm still seeing the failure.
> I was able, however, to convince someone else to try building and running
> chromium (from master), they tried it, and are seeing the run-time failure
> too.
>
>>
>> I am using github.com/kraj/openembedded-core kraj/master branch and
>> github.com/kraj/meta-raspberrypi kraj/master
>> everything else is upstream master and gcc is 5.x
>>
>> here is my build info
>>
>> Build Configuration:
>> BB_VERSION= "1.31.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING   = "universal"
>> TARGET_SYS= "x86_64-oe-linux"
>> MACHINE   = "qemux86-64"
>> DISTRO= "nodistro"
>> DISTRO_VERSION= "nodistro.0"
>> TUNE_FEATURES = "m64 core2"
>> TARGET_FPU= ""
>> meta-raspberrypi  = "kraj/master:b9ba221e520f39bc3e273f709b5ceea02897d525"
>> meta-qcom = "master:0eaea003cac6c3175b0a3682efd6e1f20ecc9dab"
>> meta-96boards = "master:6b2744bf3e82154a9329ab89cf03eec9d1f80837"
>> oe-meta-go= "master:dc19a245ae5224d1c9859119a9c53b6331812400"
>> meta-browser  = "master:77736988073a5d90fcff9d0005c8477332ede387"
>> meta-metrological = "kraj/master:356f0c33298eb63af415f333fe06121d056261e1"
>> meta-multimedia
>> meta-gnome
>> meta-oe   = "master:f11f8664de82e4f8c23b075542f4c98c16ce1f5e"
>> meta  = "kraj/master:96ed9e94082589a62a6c602e5f774c11de3328c6"
>
> At first I looked at your list and thought to myself: why all the extras? For
> qemux86-64, all that's needed are:
> - something to provide the meta (poky or openembedded-core)
> - meta-browser
> - meta-openembedded
>
> As such my first build was:
>
> BB_VERSION= "1.31.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "SUSELINUX-42.1"
> TARGET_SYS= "x86_64-oe-linux"
> MACHINE   = "qemux86-64"
> DISTRO= "nodistro"
> DISTRO_VERSION= "nodistro.0"
> TUNE_FEATURES = "m64 core2"
> TARGET_FPU= ""
> meta  = 
> "kraj/master:f30e9793b8f247f691e5ffd023e1b83301508409"
> meta-browser  = "master:77736988073a5d90fcff9d0005c8477332ede387"
> meta-oe
> meta-gnome
> meta-multimedia   = "master:303d9ea960e2d88281079a4e71abe2cf8c815184"
>
> Running chromium showed the failure, as usual.
>
> So then I thought I'd try to recreate your build exactly -- except that's not 
> possible:
>
> oe-meta-go from https://github.com/errordeveloper/oe-meta-go doesn't 
> contain a dc19a245ae5224d1c9859119a9c53b6331812400
> meta-openembedded doesn't contain a 
> f11f8664de82e4f8c23b075542f4c98c16ce1f5e
> openembedded-core from https://github.com/kraj/openembedded-core 
> doesn't contain a 96ed9e94082589a62a6c602e5f774c11de3328c6
>
>
> But even at that, I ended up removing meta-metrological because:
> ERROR: ParseError at 
> /z/chromium-qemux86-64/meta-metrological/recipes-qt/qtbrowser/qtbrowser_2.0.11.bb:14:
>  Could not inherit file classes/qmake5.bbclass
>
>
> So I performed my build with:
> BB_VERSION= "1.31.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "SUSELINUX-42.1"
> TARGET_SYS= "x86_64-oe-linux"
> MACHINE   = "qemux86-64"
> DISTRO= "nodistro"
> DISTRO_VERSION= "nodistro.0"
> TUNE_FEATURES = "m64 core2"
> TARGET_FPU= ""
> meta-raspberrypi__kraj = 
> "HEAD:b9ba221e520f39bc3e273f709b5ceea02897d525"
> meta-qcom = "HEAD:0eaea003cac6c3175b0a3682efd6e1f20ecc9dab"
> meta-96boards = "HEAD:6b2744bf3e82154a9329ab89cf03eec9d1f80837"
> oe-meta-go= "master:0712320950adf810fb324d49fba5d49ae19981b0"
> meta-browser  = "HEAD:77736988073a5d90fcff9d0005c8477332ede387"
> meta-oe
> meta-gnome
> meta-multimedia   = "master:303d9ea960e2d88281079a4e71abe2cf8c815184"
> 

[OE-core] [PATCHv2 9/9] xf86-input-libinput: Upgrade 0.16.0 -> 0.19.0

[Jussi Kukkonen]

Note that the xorg configuration file for input-libinput now sorts
lower than it used to (90 -> 60).

Signed-off-by: Jussi Kukkonen 
---
 .../{xf86-input-libinput_0.16.0.bb => xf86-input-libinput_0.19.0.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-driver/{xf86-input-libinput_0.16.0.bb => 
xf86-input-libinput_0.19.0.bb} (63%)

diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.16.0.bb 
b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.19.0.bb
similarity index 63%
rename from meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.16.0.bb
rename to meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.19.0.bb
index 0252baf..5e5c471 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.16.0.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.19.0.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=5e6b20ea2ef94a998145f0ea3f788ee0"
 
 DEPENDS += "libinput"
 
-SRC_URI[md5sum] = "2c8cb520f88da7bafaceebc0b34ea1d4"
-SRC_URI[sha256sum] = 
"fdade531e91e79acf6dce8ac55fa4f65abe3f1358c5d3d777ae48dbc74b76f49"
+SRC_URI[md5sum] = "52c38b1369764243bfcf6ead1e4c6d32"
+SRC_URI[sha256sum] = 
"6c5d30dc7c8b8ae34261340e1dc9cbb8ef435078e084b8ef507527a8a21af477"
 
 FILES_${PN} += "${datadir}/X11/xorg.conf.d"
-- 
2.1.4

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

[OE-core] [PATCHv2 3/9] wayland-protocols: Upgrade 1.3 -> 1.4

[Jussi Kukkonen]

Remove backported patch.

Signed-off-by: Jussi Kukkonen 
---
 .../wayland-protocols/dont-use-AC_CANONICAL.patch  | 29 --
 ...d-protocols_1.3.bb => wayland-protocols_1.4.bb} |  6 ++---
 2 files changed, 3 insertions(+), 32 deletions(-)
 delete mode 100644 
meta/recipes-graphics/wayland/wayland-protocols/dont-use-AC_CANONICAL.patch
 rename meta/recipes-graphics/wayland/{wayland-protocols_1.3.bb => 
wayland-protocols_1.4.bb} (80%)

diff --git 
a/meta/recipes-graphics/wayland/wayland-protocols/dont-use-AC_CANONICAL.patch 
b/meta/recipes-graphics/wayland/wayland-protocols/dont-use-AC_CANONICAL.patch
deleted file mode 100644
index 6cc0f3b..000
--- 
a/meta/recipes-graphics/wayland/wayland-protocols/dont-use-AC_CANONICAL.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-Check autoconfs $cross_compiling instead as AC_CANONICAL_HOST call
-will fail if the host cpu is not recognised (which can happen when
-e.g. Yocto builds for "allarch").
-
-Signed-off-by: Jussi Kukkonen 
-Upstream-Status: Backport [cc276dfa41]
-
-diff --git a/configure.ac b/configure.ac
-index 5b48b1a..3d45a4b 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -15,13 +15,10 @@ AC_CONFIG_MACRO_DIR([m4])
- 
- AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
- 
--AC_CANONICAL_HOST
--AC_CANONICAL_BUILD
--
- AC_ARG_VAR([wayland_scanner], [The wayland-scanner executable])
- AC_PATH_PROG([wayland_scanner], [wayland-scanner])
- if test x$wayland_scanner = x; then
--if test x$host = x$build; then
-+if test "x$cross_compiling" != "xyes"; then
- PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
- wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`
- else
--- 
-cgit v0.10.2
-
diff --git a/meta/recipes-graphics/wayland/wayland-protocols_1.3.bb 
b/meta/recipes-graphics/wayland/wayland-protocols_1.4.bb
similarity index 80%
rename from meta/recipes-graphics/wayland/wayland-protocols_1.3.bb
rename to meta/recipes-graphics/wayland/wayland-protocols_1.4.bb
index 86e89b5..fcc156f 100644
--- a/meta/recipes-graphics/wayland/wayland-protocols_1.3.bb
+++ b/meta/recipes-graphics/wayland/wayland-protocols_1.4.bb
@@ -10,9 +10,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=c7b12b6702da38ca028ace54aae3d484 \
 
file://stable/presentation-time/presentation-time.xml;endline=26;md5=4646cd7d9edc9fa55db941f2d3a7dc53"
 
 SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
-   file://dont-use-AC_CANONICAL.patch"
-SRC_URI[md5sum] = "88b5e3dce52908c7e74fad3e2cf8abb0"
-SRC_URI[sha256sum] = 
"6bcd0633fdf9225ef1c7d2831f542e947f7d79811c79fc37f57b2e5375ded82f"
+   "
+SRC_URI[md5sum] = "fd8089abf13a1d04e4baa6509ee72baf"
+SRC_URI[sha256sum] = 
"014a9a23c21ed14f49b1005b3e8efa66d6337d4ceafc97f7b0d6707e7e3df572"
 
 inherit allarch autotools pkgconfig
 
-- 
2.1.4

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

[OE-core] [PATCHv2 8/9] xf86-input-evdev: Upgrade 2.10.2 -> 2.10.3

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen 
---
 .../{xf86-input-evdev_2.10.2.bb => xf86-input-evdev_2.10.3.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-driver/{xf86-input-evdev_2.10.2.bb => 
xf86-input-evdev_2.10.3.bb} (83%)

diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.2.bb 
b/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.3.bb
similarity index 83%
rename from meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.2.bb
rename to meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.3.bb
index 2ea4574..f81c3ec 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.2.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.3.bb
@@ -16,5 +16,5 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=fefe33b1cf0cacba0e72e3b0fa0f0e16"
 
 DEPENDS += "mtdev libevdev"
 
-SRC_URI[md5sum] = "452bcc3bcce712b59af363eea94e3392"
-SRC_URI[sha256sum] = 
"a73a630d41ab90708d929f357e922bfbdb63d553491c5a30ab3e8fb1e35dfe1d"
+SRC_URI[md5sum] = "aa3363ce5061d0c4d1e7f7019b99716d"
+SRC_URI[sha256sum] = 
"5aa21ba4be8df927e5676a99c7f4f0343abc089f5451b7e73e39536f29b332a2"
-- 
2.1.4

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

[OE-core] [PATCHv2 6/9] libxfixes: Upgrade 5.0.1 -> 5.0.2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen 
---
 .../xorg-lib/{libxfixes_5.0.1.bb => libxfixes_5.0.2.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{libxfixes_5.0.1.bb => 
libxfixes_5.0.2.bb} (79%)

diff --git a/meta/recipes-graphics/xorg-lib/libxfixes_5.0.1.bb 
b/meta/recipes-graphics/xorg-lib/libxfixes_5.0.2.bb
similarity index 79%
rename from meta/recipes-graphics/xorg-lib/libxfixes_5.0.1.bb
rename to meta/recipes-graphics/xorg-lib/libxfixes_5.0.2.bb
index 6e2740c..f078aed 100644
--- a/meta/recipes-graphics/xorg-lib/libxfixes_5.0.1.bb
+++ b/meta/recipes-graphics/xorg-lib/libxfixes_5.0.2.bb
@@ -18,5 +18,5 @@ XORG_PN = "libXfixes"
 
 BBCLASSEXTEND = "native nativesdk"
 
-SRC_URI[md5sum] = "b985b85f8b9386c85ddcfe1073906b4d"
-SRC_URI[sha256sum] = 
"63bec085084fa3caaee5180490dd871f1eb2020ba9e9b39a30f93693ffc34767"
+SRC_URI[md5sum] = "544d73df94e638ba7b64147be416e576"
+SRC_URI[sha256sum] = 
"9bd20edfec084a1bed481d48dd4815dee88139fffad091418cdda081129a9aea"
-- 
2.1.4

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

[OE-core] [PATCHv2 5/9] weston: Upgrade 1.10.0 -> 1.11.0

[Jussi Kukkonen]

Remove now unnecessary patch, rebase others.
Add musl build fix patch.

Signed-off-by: Jussi Kukkonen 
---
 ...1-configure.ac-Fix-wayland-protocols-path.patch |  4 +-
 .../0001-shared-include-stdint.h-for-int32_t.patch | 28 +
 ...ch-Provide-a-default-version-that-doesn-t.patch | 68 +++---
 .../make-libwebp-explicitly-configurable.patch | 37 
 .../wayland/{weston_1.10.0.bb => weston_1.11.0.bb} |  8 +--
 5 files changed, 69 insertions(+), 76 deletions(-)
 create mode 100644 
meta/recipes-graphics/wayland/weston/0001-shared-include-stdint.h-for-int32_t.patch
 delete mode 100644 
meta/recipes-graphics/wayland/weston/make-libwebp-explicitly-configurable.patch
 rename meta/recipes-graphics/wayland/{weston_1.10.0.bb => weston_1.11.0.bb} 
(95%)

diff --git 
a/meta/recipes-graphics/wayland/weston/0001-configure.ac-Fix-wayland-protocols-path.patch
 
b/meta/recipes-graphics/wayland/weston/0001-configure.ac-Fix-wayland-protocols-path.patch
index 7e00038..00118d7 100644
--- 
a/meta/recipes-graphics/wayland/weston/0001-configure.ac-Fix-wayland-protocols-path.patch
+++ 
b/meta/recipes-graphics/wayland/weston/0001-configure.ac-Fix-wayland-protocols-path.patch
@@ -20,10 +20,10 @@ diff --git a/configure.ac b/configure.ac
 index bc7c329..15a05d3 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -184,7 +184,7 @@ PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
+@@ -187,7 +187,7 @@ PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
  PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
  
- PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.0],
+ PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.2],
 -[ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG 
--variable=pkgdatadir wayland-protocols`])
 +
[ac_wayland_protocols_pkgdatadir=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG 
--variable=pkgdatadir wayland-protocols`])
  AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, $ac_wayland_protocols_pkgdatadir)
diff --git 
a/meta/recipes-graphics/wayland/weston/0001-shared-include-stdint.h-for-int32_t.patch
 
b/meta/recipes-graphics/wayland/weston/0001-shared-include-stdint.h-for-int32_t.patch
new file mode 100644
index 000..91ef727
--- /dev/null
+++ 
b/meta/recipes-graphics/wayland/weston/0001-shared-include-stdint.h-for-int32_t.patch
@@ -0,0 +1,28 @@
+From ba02b8abe4e2afac2bfbf2559972d5059d75a041 Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Sat, 16 Jul 2016 22:50:19 +0300
+Subject: [PATCH weston] shared: include stdint.h for int32_t
+
+This fixes build on musl.
+
+Signed-off-by: Jussi Kukkonen 
+Upstream-Status: Submitted
+---
+ shared/xalloc.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/shared/xalloc.h b/shared/xalloc.h
+index 85fccb4..484de2d 100644
+--- a/shared/xalloc.h
 b/shared/xalloc.h
+@@ -30,6 +30,7 @@
+ extern "C" {
+ #endif
+ 
++#include 
+ #include 
+ #include 
+ 
+-- 
+2.1.4
+
diff --git 
a/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
 
b/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
index 9a401ee..5542036 100644
--- 
a/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
+++ 
b/meta/recipes-graphics/wayland/weston/0001-weston-launch-Provide-a-default-version-that-doesn-t.patch
@@ -1,8 +1,8 @@
-From 228349e796e9baa86f2ba8232c730c18ac41283d Mon Sep 17 00:00:00 2001
+From d02226b3d5872b184c1d50c7f4706ac9467ffb81 Mon Sep 17 00:00:00 2001
 From: Tom Hochstein 
-Date: Fri, 13 May 2016 09:31:55 -0500
-Subject: [PATCH weston] weston-launch: Provide a default version that doesn't
- require PAM
+Date: Fri, 15 Jul 2016 11:00:15 +0300
+Subject: [PATCH] weston-launch: Provide a default version that doesn't require
+ PAM
 
 weston-launch requires PAM for starting weston as a non-root user.
 
@@ -14,18 +14,17 @@ Upstream-Status: Pending
 
 Signed-off-by: Tom Hochstein 
 ---
- Makefile.am |  3 ---
- configure.ac| 12 +++-
+ configure.ac|  9 +++--
  src/weston-launch.c | 20 
- 3 files changed, 27 insertions(+), 8 deletions(-)
+ 2 files changed, 27 insertions(+), 2 deletions(-)
 
-Index: weston-1.10.0/configure.ac
-===
 weston-1.10.0.orig/configure.ac2016-05-13 11:02:05.711817559 -0500
-+++ weston-1.10.0/configure.ac 2016-05-13 13:30:28.0 -0500
-@@ -445,13 +445,17 @@
- AS_IF([test "x$have_systemd_login_209" = "xyes"],
-   [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
+diff --git a/configure.ac b/configure.ac
+index 32fdde7..240966f 100644
+--- a/configure.ac
 b/configure.ac
+@@ -416,13 +416,17 @@ AC_ARG_ENABLE(resize-optimization,
+ AS_IF([test "x$enable_resize_optimization" = 

[OE-core] [PATCHv2 1/9] mesa-demos: Require X11 distro feature

[Jussi Kukkonen]

Mesa-demos theoretically does not require X11 (apart from xdemos/)
but reality is that every other binary requires glut. So:
 * 'non-glut' part of mesa-demos requires X11
 * current freeglut recipe also depends on X11

There is apparently wayland support in freeglut now: This recipe
should be modified when meta-oe freeglut recipe has that feature.

The change became necessary now because mesa no longer mistakenly
installs GL files when X11 is disabled (and mesa-demos configure
currently requires GL).

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb 
b/meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb
index ee0bb02..fab0bdb 100644
--- a/meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb
@@ -24,10 +24,10 @@ SRC_URI[sha256sum] = 
"c173154bbd0d5fb53d732471984def42fb1b14ac85fcb834138fb9518b
 
 inherit autotools pkgconfig distro_features_check
 # depends on virtual/egl, virtual/libgl ...
-REQUIRED_DISTRO_FEATURES = "opengl"
+REQUIRED_DISTRO_FEATURES = "opengl x11"
 
 PACKAGECONFIG ?= "drm osmesa freetype2 gbm egl gles1 gles2 \
-  ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 glew glu 
glx', '', d)}"
+  x11 glew glu glx"
 
 # The Wayland code doesn't work with Wayland 1.0, so disable it for now
 #${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)}"
-- 
2.1.4

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

[OE-core] [PATCHv2 2/9] mesa: Upgrade 11.2.2 -> 12.0.1

[Jussi Kukkonen]

Massive mesa upgrade (OpenGL 4.3, GLVND support, vulkan driver
for intel etc), although many new things are disabled by default.

License file change does not change the actual licenses.

piglit results (with piglit update on ML) on an old NUC with Intel
HD5000 for reference:
   pass:   33972
   fail: 306
  crash:   2
   skip:   30857
   warn:   7
  total:   65144

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-graphics/mesa/{mesa-gl_11.2.2.bb => mesa-gl_12.0.1.bb} | 0
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 meta/recipes-graphics/mesa/{mesa_11.2.2.bb => mesa_12.0.1.bb}   | 4 ++--
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_11.2.2.bb => mesa-gl_12.0.1.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_11.2.2.bb => mesa_12.0.1.bb} (80%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_11.2.2.bb 
b/meta/recipes-graphics/mesa/mesa-gl_12.0.1.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_11.2.2.bb
rename to meta/recipes-graphics/mesa/mesa-gl_12.0.1.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 1d084c0..e4880ff 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -10,7 +10,7 @@ HOMEPAGE = "http://mesa3d.org;
 BUGTRACKER = "https://bugs.freedesktop.org;
 SECTION = "x11"
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://docs/license.html;md5=6a23445982a7a972ac198e93cc1cb3de"
+LIC_FILES_CHKSUM = 
"file://docs/license.html;md5=899fbe7e42d494c7c8c159c7001693d5"
 
 PE = "2"
 
diff --git a/meta/recipes-graphics/mesa/mesa_11.2.2.bb 
b/meta/recipes-graphics/mesa/mesa_12.0.1.bb
similarity index 80%
rename from meta/recipes-graphics/mesa/mesa_11.2.2.bb
rename to meta/recipes-graphics/mesa/mesa_12.0.1.bb
index a864b54..ad872b3 100644
--- a/meta/recipes-graphics/mesa/mesa_11.2.2.bb
+++ b/meta/recipes-graphics/mesa/mesa_12.0.1.bb
@@ -4,8 +4,8 @@ SRC_URI = 
"ftp://ftp.freedesktop.org/pub/mesa/${PV}/mesa-${PV}.tar.xz \
file://replace_glibc_check_with_linux.patch \
 "
 
-SRC_URI[md5sum] = "e0ec73f7273662a74366f0d76dd19ac3"
-SRC_URI[sha256sum] = 
"40e148812388ec7c6d7b6657d5a16e2e8dabba8b97ddfceea5197947647bdfb4"
+SRC_URI[md5sum] = "972fd5ad5a63aeabf173fb9adefc6522"
+SRC_URI[sha256sum] = 
"bab24fb79f78c876073527f515ed871fc9c81d816f66c8a0b051d8d653896389"
 
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
-- 
2.1.4

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

[OE-core] [PATCHv2 4/9] wayland: Upgrade 1.10.0 -> 1.11.0

[Jussi Kukkonen]

Add a musl build fix patch.

Signed-off-by: Jussi Kukkonen 
---
 ...0001-scanner-Use-unit32_t-instead-of-uint.patch | 30 ++
 .../{wayland_1.10.0.bb => wayland_1.11.0.bb}   |  8 +++---
 2 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
 rename meta/recipes-graphics/wayland/{wayland_1.10.0.bb => wayland_1.11.0.bb} 
(87%)

diff --git 
a/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
 
b/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
new file mode 100644
index 000..dece95c
--- /dev/null
+++ 
b/meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
@@ -0,0 +1,30 @@
+From 5516d32e694badca35b6c71b02a3f08f650308bf Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 15 Jul 2016 16:23:48 -0700
+Subject: [PATCH] scanner: Use unit32_t instead of uint
+
+uint32_t is C99 defined stdint type
+
+Signed-off-by: Khem Raj 
+Signed-off-by: Jussi Kukkonen 
+Upstream-Status: Submitted
+---
+ src/scanner.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/scanner.c b/src/scanner.c
+index 5f06e8e..10a4023 100644
+--- a/src/scanner.c
 b/src/scanner.c
+@@ -808,7 +808,7 @@ find_enumeration(struct protocol *protocol,
+   struct interface *i;
+   struct enumeration *e;
+   char *enum_name;
+-  uint idx = 0, j;
++  uint32_t idx = 0, j;
+ 
+   for (j = 0; j + 1 < strlen(enum_attribute); j++) {
+   if (enum_attribute[j] == '.') {
+-- 
+2.1.4
+
diff --git a/meta/recipes-graphics/wayland/wayland_1.10.0.bb 
b/meta/recipes-graphics/wayland/wayland_1.11.0.bb
similarity index 87%
rename from meta/recipes-graphics/wayland/wayland_1.10.0.bb
rename to meta/recipes-graphics/wayland/wayland_1.11.0.bb
index 41d08b7..3413406 100644
--- a/meta/recipes-graphics/wayland/wayland_1.10.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.11.0.bb
@@ -10,9 +10,11 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b31d8f53b6aaf2b4985d7dd7810a70d1 \
 
file://src/wayland-server.c;endline=24;md5=b8e046164a766bb1ede8ba38e9dcd7ce"
 
-SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz;
-SRC_URI[md5sum] = "e7751c38807c231afaba9d6b68f2a2b7"
-SRC_URI[sha256sum] = 
"4bf6e790aa6f50ab3825676282ecd75850ec9c4767af96ecb7127b1f3c3d60dc"
+SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
+   file://0001-scanner-Use-unit32_t-instead-of-uint.patch \
+   "
+SRC_URI[md5sum] = "fccf680be066e234729d5b69e0bd0fa9"
+SRC_URI[sha256sum] = 
"9540925f7928becfdf5e3b84c70757f6589bf1ceef09bea78784d8e4772c0db0"
 
 EXTRA_OECONF_class-native = "--disable-documentation --disable-libraries"
 
-- 
2.1.4

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

[OE-core] [PATCHv2 7/9] xkeyboard-config: Upgrade 2.17 -> 2.18

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen 
---
 .../xorg-lib/{xkeyboard-config_2.17.bb => xkeyboard-config_2.18.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{xkeyboard-config_2.17.bb => 
xkeyboard-config_2.18.bb} (88%)

diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.17.bb 
b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.18.bb
similarity index 88%
rename from meta/recipes-graphics/xorg-lib/xkeyboard-config_2.17.bb
rename to meta/recipes-graphics/xorg-lib/xkeyboard-config_2.18.bb
index ff9aa1d..79fcbd8 100644
--- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.17.bb
+++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.18.bb
@@ -13,8 +13,8 @@ LICENSE = "MIT & MIT-style"
 LIC_FILES_CHKSUM = "file://COPYING;md5=0e7f21ca7db975c63467d2e7624a12f9"
 
 SRC_URI = 
"${XORG_MIRROR}/individual/data/xkeyboard-config/${BPN}-${PV}.tar.bz2"
-SRC_URI[md5sum] = "15034bb74deebde54161dface62abbce"
-SRC_URI[sha256sum] = 
"dec6be44bd31775cdc1ab95bfd75d5f2c0055613eeca8b4e9c6480b183430701"
+SRC_URI[md5sum] = "c28cf45616bfec276879360bc36c6b27"
+SRC_URI[sha256sum] = 
"c41d917d6c8a59feb7ccbda51c40a6ada824fdd1e9684b52dd48c9530617ddd0"
 
 SECTION = "x11/libs"
 DEPENDS = "intltool-native virtual/gettext util-macros libxslt-native"
-- 
2.1.4

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

[OE-core] [PATCHv2 0/9] Upgrade mesa, wayland

[Jussi Kukkonen]

Changes since V1:
* wayland: Added Khems musl build fix patch
* weston: Added a musl build fix patch
* mesa-demos (new patch): require X11 distro feature

Issues:
* gbm fails to load drivers with musl: "Error relocating
  /lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found"


Original cover letter follows:

Major releases of wayland components and especially mesa. The X
upgrades are all fairly small ones.

Mesa has been tested with piglit (looks pretty good). I did not have
a modern test device at hand so have not verified the OpenGL 4.3
support. Wayland was just smoke tested: seems to work fine.

Jussi

The following changes since commit 627d01997fcf6a0581d88047735769ffb2592b82:

  useradd-staticids: use map() instead of imap() (2016-07-12 23:12:00 +0100)

are available in the git repository at:

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

Jussi Kukkonen (9):
  mesa-demos: Require X11 distro feature
  mesa: Upgrade 11.2.2 -> 12.0.1
  wayland-protocols: Upgrade 1.3 -> 1.4
  wayland: Upgrade 1.10.0 -> 1.11.0
  weston: Upgrade 1.10.0 -> 1.11.0
  libxfixes: Upgrade 5.0.1 -> 5.0.2
  xkeyboard-config: Upgrade 2.17 -> 2.18
  xf86-input-evdev: Upgrade 2.10.2 -> 2.10.3
  xf86-input-libinput: Upgrade 0.16.0 -> 0.19.0

 meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb |  4 +-
 .../mesa/{mesa-gl_11.2.2.bb => mesa-gl_12.0.1.bb}  |  0
 meta/recipes-graphics/mesa/mesa.inc|  2 +-
 .../mesa/{mesa_11.2.2.bb => mesa_12.0.1.bb}|  4 +-
 .../wayland-protocols/dont-use-AC_CANONICAL.patch  | 29 -
 ...d-protocols_1.3.bb => wayland-protocols_1.4.bb} |  6 +-
 ...0001-scanner-Use-unit32_t-instead-of-uint.patch | 30 ++
 .../{wayland_1.10.0.bb => wayland_1.11.0.bb}   |  8 ++-
 ...1-configure.ac-Fix-wayland-protocols-path.patch |  4 +-
 .../0001-shared-include-stdint.h-for-int32_t.patch | 28 +
 ...ch-Provide-a-default-version-that-doesn-t.patch | 68 +++---
 .../make-libwebp-explicitly-configurable.patch | 37 
 .../wayland/{weston_1.10.0.bb => weston_1.11.0.bb} |  8 +--
 ...-evdev_2.10.2.bb => xf86-input-evdev_2.10.3.bb} |  4 +-
 ...put_0.16.0.bb => xf86-input-libinput_0.19.0.bb} |  4 +-
 .../{libxfixes_5.0.1.bb => libxfixes_5.0.2.bb} |  4 +-
 ...ard-config_2.17.bb => xkeyboard-config_2.18.bb} |  4 +-
 17 files changed, 120 insertions(+), 124 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_11.2.2.bb => mesa-gl_12.0.1.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_11.2.2.bb => mesa_12.0.1.bb} (80%)
 delete mode 100644 
meta/recipes-graphics/wayland/wayland-protocols/dont-use-AC_CANONICAL.patch
 rename meta/recipes-graphics/wayland/{wayland-protocols_1.3.bb => 
wayland-protocols_1.4.bb} (80%)
 create mode 100644 
meta/recipes-graphics/wayland/wayland/0001-scanner-Use-unit32_t-instead-of-uint.patch
 rename meta/recipes-graphics/wayland/{wayland_1.10.0.bb => wayland_1.11.0.bb} 
(87%)
 create mode 100644 
meta/recipes-graphics/wayland/weston/0001-shared-include-stdint.h-for-int32_t.patch
 delete mode 100644 
meta/recipes-graphics/wayland/weston/make-libwebp-explicitly-configurable.patch
 rename meta/recipes-graphics/wayland/{weston_1.10.0.bb => weston_1.11.0.bb} 
(95%)
 rename meta/recipes-graphics/xorg-driver/{xf86-input-evdev_2.10.2.bb => 
xf86-input-evdev_2.10.3.bb} (83%)
 rename meta/recipes-graphics/xorg-driver/{xf86-input-libinput_0.16.0.bb => 
xf86-input-libinput_0.19.0.bb} (63%)
 rename meta/recipes-graphics/xorg-lib/{libxfixes_5.0.1.bb => 
libxfixes_5.0.2.bb} (79%)
 rename meta/recipes-graphics/xorg-lib/{xkeyboard-config_2.17.bb => 
xkeyboard-config_2.18.bb} (88%)

-- 
2.1.4

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

Re: [OE-core] [PATCH 3/8] wayland: Upgrade 1.10.0 -> 1.11.0

[Jussi Kukkonen]

On 16 July 2016 at 02:25, Khem Raj  wrote:

> On Jul 15, 2016, at 3:15 PM, Burton, Ross  wrote:
>
>
> On 15 July 2016 at 11:41, Jussi Kukkonen  wrote:
>
>> Signed-off-by: Jussi Kukkonen 
>>
>
> This breaks with musl:
>
> | ../wayland-1.11.0/src/scanner.c: In function 'find_enumeration':
> | ../wayland-1.11.0/src/scanner.c:811:2: error: unknown type name 'uint'
> |   uint idx = 0, j;
>
>
> Fixed with
> https://patchwork.freedesktop.org/patch/98992/
>
> Please back port and test
>
>
Thanks Khem,

I've added one more small fix to weston, and things build on musl now.
Unfortunately at boot time I get the same versioned symbol relocation
problem that vte has:
  gbm: failed to open any driver (search paths /usr/lib/dri)
  gbm: last dlopen error: Error relocating /lib/libgcc_s.so.1:
__cpu_indicator_init: symbol not found
  failed to load driver: i965

This is with mesa 12.0.1 from this same patchset. I'll resend the set in a
minute.

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

Re: [OE-core] [PATCH V2] glibc: Upgrade to latest tip of master

[Trevor Woerner]

On Fri 2016-07-08 @ 01:55:18 PM, Khem Raj wrote:
> Trevor
> 
> On Thu, Jul 7, 2016 at 1:25 PM, Khem Raj  wrote:
> > Ok thanks. Let me know if you get to see the same issue on say qemuarm or
> > qemuarm64
> 
> I built core-image-sato/qemux86-64 vmdk with chromium added
> 
> CORE_IMAGE_EXTRA_INSTALL_append = " chromium "
> 
> launched this image in VM and chromium starts normally.

Someday I hope that we'll have a mechanism in place that will be able to
better record the full information about a build to help make it easier for
multiple people to fully recreate the exact same builds, independently (iow,
in situations like this).

I've done my best to recreate your build, and I'm still seeing the failure.
I was able, however, to convince someone else to try building and running
chromium (from master), they tried it, and are seeing the run-time failure
too.

> 
> I am using github.com/kraj/openembedded-core kraj/master branch and
> github.com/kraj/meta-raspberrypi kraj/master
> everything else is upstream master and gcc is 5.x
> 
> here is my build info
> 
> Build Configuration:
> BB_VERSION= "1.31.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "x86_64-oe-linux"
> MACHINE   = "qemux86-64"
> DISTRO= "nodistro"
> DISTRO_VERSION= "nodistro.0"
> TUNE_FEATURES = "m64 core2"
> TARGET_FPU= ""
> meta-raspberrypi  = "kraj/master:b9ba221e520f39bc3e273f709b5ceea02897d525"
> meta-qcom = "master:0eaea003cac6c3175b0a3682efd6e1f20ecc9dab"
> meta-96boards = "master:6b2744bf3e82154a9329ab89cf03eec9d1f80837"
> oe-meta-go= "master:dc19a245ae5224d1c9859119a9c53b6331812400"
> meta-browser  = "master:77736988073a5d90fcff9d0005c8477332ede387"
> meta-metrological = "kraj/master:356f0c33298eb63af415f333fe06121d056261e1"
> meta-multimedia
> meta-gnome
> meta-oe   = "master:f11f8664de82e4f8c23b075542f4c98c16ce1f5e"
> meta  = "kraj/master:96ed9e94082589a62a6c602e5f774c11de3328c6"

At first I looked at your list and thought to myself: why all the extras? For
qemux86-64, all that's needed are:
- something to provide the meta (poky or openembedded-core)
- meta-browser
- meta-openembedded

As such my first build was:

BB_VERSION= "1.31.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "SUSELINUX-42.1"
TARGET_SYS= "x86_64-oe-linux"
MACHINE   = "qemux86-64"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""
meta  = 
"kraj/master:f30e9793b8f247f691e5ffd023e1b83301508409"
meta-browser  = "master:77736988073a5d90fcff9d0005c8477332ede387"
meta-oe
meta-gnome
meta-multimedia   = "master:303d9ea960e2d88281079a4e71abe2cf8c815184"

Running chromium showed the failure, as usual.

So then I thought I'd try to recreate your build exactly -- except that's not 
possible:

oe-meta-go from https://github.com/errordeveloper/oe-meta-go doesn't 
contain a dc19a245ae5224d1c9859119a9c53b6331812400
meta-openembedded doesn't contain a 
f11f8664de82e4f8c23b075542f4c98c16ce1f5e
openembedded-core from https://github.com/kraj/openembedded-core 
doesn't contain a 96ed9e94082589a62a6c602e5f774c11de3328c6


But even at that, I ended up removing meta-metrological because:
ERROR: ParseError at 
/z/chromium-qemux86-64/meta-metrological/recipes-qt/qtbrowser/qtbrowser_2.0.11.bb:14:
 Could not inherit file classes/qmake5.bbclass


So I performed my build with:
BB_VERSION= "1.31.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "SUSELINUX-42.1"
TARGET_SYS= "x86_64-oe-linux"
MACHINE   = "qemux86-64"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""
meta-raspberrypi__kraj = "HEAD:b9ba221e520f39bc3e273f709b5ceea02897d525"
meta-qcom = "HEAD:0eaea003cac6c3175b0a3682efd6e1f20ecc9dab"
meta-96boards = "HEAD:6b2744bf3e82154a9329ab89cf03eec9d1f80837"
oe-meta-go= "master:0712320950adf810fb324d49fba5d49ae19981b0"
meta-browser  = "HEAD:77736988073a5d90fcff9d0005c8477332ede387"
meta-oe
meta-gnome
meta-multimedia   = "master:303d9ea960e2d88281079a4e71abe2cf8c815184"
meta  = 
"kraj/master:f30e9793b8f247f691e5ffd023e1b83301508409"

This build succeeded (with gcc-5%), but running chromium caused the failure to
occur, as usual.

In the last couple weeks I've built chromium for x86-64 52 times and haven't
once seen it run successfully unless glibc was at 2.23. Plus I've had someone
else independently build and run chromium once, and it failed. I'm baffled how
it could be failing for me but 

Re: [OE-core] [PATCH] systemd: use OE core paths under /var/volatile for /var/tmp and /var/log

[Burton, Ross]

On 15 April 2016 at 23:22, Bill Randle  wrote:

> +-d /var/log 0755 - - -
> ++# OE Core uses /var/volatile/log rather than /var/log
> ++#d /var/log 0755 - - -
> ++L /var/log - - - - /var/volatile/log


I'm not sure this is right - in the default configuration /var/log and
/var/tmp are symlinks into /var/volatile which is a tmpfs, but that's
basically an implementation detail which a distro is free to change (if
they'd like persistent logs, for example).

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

[OE-core] [PATCH 1/1] classes/populate_sdk_ext: show progress when preparing build system

[Paul Eggleton]

During the extensible SDK installation process the final step is to
prepare the internal copy of the build system. This can take some time,
especially if you have SDK_EXT_TYPE set to "minimal" (downloading
sstate artifacts) and SDK_INCLUDE_PKGDATA set to "1" (restoring
pkgdata for world). To make this a bit less painful, use BitBake's new
quiet mode to display status during this operation so you have some idea
of how it's progressing; instead of redirecting the output to
preparing_build_system.log we grab the last console log and append it
instead.

One result of this change is that you get the errors printed on the
console during normal output rather than this going to the
preparing_build_system.log file first. In OE-Core revision
227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the
contents of preparing_build_system.log on failure, but now at least the
error contents of that log is duplicated. Besides, I intentionally
didn't print out the contents of that log during normal usage because
it's quite verbose - the bug that we were attempting to fix was about
not getting this information when seeing failures in the automated
tests, thus I've moved printing the log to the test handling code
instead.

Part of the implementation for [YOCTO #9613].

Signed-off-by: Paul Eggleton 
---
 meta/classes/populate_sdk_ext.bbclass |  2 +-
 meta/files/ext-sdk-prepare.py | 67 ++-
 2 files changed, 44 insertions(+), 25 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 245adc1..62f2c3e 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -428,7 +428,7 @@ sdk_ext_postinst() {
# current working directory when first ran, nor will it set $1 
when
# sourcing a script. That is why this has to look so ugly.
LOGFILE="$target_sdk_dir/preparing_build_system.log"
-   sh -c ". buildtools/environment-setup* > $LOGFILE && cd 
$target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . 
$target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && python 
$target_sdk_dir/ext-sdk-prepare.py '${SDK_INSTALL_TARGETS}' >> $LOGFILE 2>&1" 
|| { echo "ERROR: SDK preparation failed: see $LOGFILE for a slightly more 
detailed log"; echo "printf 'ERROR: this SDK was not fully installed and needs 
reinstalling\n'" >> $env_setup_script ; exit 1 ; }
+   sh -c ". buildtools/environment-setup* > $LOGFILE && cd 
$target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . 
$target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && python 
$target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'" || { echo 
"ERROR: SDK preparation failed: see $LOGFILE for a slightly more detailed log"; 
echo "printf 'ERROR: this SDK was not fully installed and needs 
reinstalling\n'" >> $env_setup_script ; exit 1 ; }
rm $target_sdk_dir/ext-sdk-prepare.py
fi
echo done
diff --git a/meta/files/ext-sdk-prepare.py b/meta/files/ext-sdk-prepare.py
index 3b33c0f..8b15982 100644
--- a/meta/files/ext-sdk-prepare.py
+++ b/meta/files/ext-sdk-prepare.py
@@ -5,43 +5,62 @@
 import sys
 import os
 import subprocess
+import signal
 
-def exec_watch(cmd, **options):
-"""Run program with stdout shown on sys.stdout"""
-if isinstance(cmd, str) and not "shell" in options:
-options["shell"] = True
+def reenable_sigint():
+signal.signal(signal.SIGINT, signal.SIG_DFL)
 
-process = subprocess.Popen(
-cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, **options
-)
-
-buf = ''
-while True:
-out = process.stdout.read(1)
-if out:
-sys.stdout.write(out)
-sys.stdout.flush()
-buf += out
-elif out == '' and process.poll() != None:
-break
+def run_command_interruptible(cmd):
+"""
+Run a command with output displayed on the console, but ensure any Ctrl+C 
is
+processed only by the child process.
+"""
+signal.signal(signal.SIGINT, signal.SIG_IGN)
+try:
+ret = subprocess.call(cmd, shell=True, preexec_fn=reenable_sigint)
+finally:
+signal.signal(signal.SIGINT, signal.SIG_DFL)
+return ret
 
-return process.returncode, buf
+def get_last_consolelog():
+'''Return the most recent console log file'''
+logdir = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'tmp', 
'log', 'cooker')
+if os.path.exists(logdir):
+mcdir = os.listdir(logdir)
+if mcdir:
+logdir = os.path.join(logdir, mcdir[0])
+logfiles = [os.path.join(logdir, fn) for fn in os.listdir(logdir)]
+logfiles.sort(key=os.path.getmtime)
+if logfiles:
+return os.path.join(logdir, logfiles[-1])
+return None
 
 def main():
 

[OE-core] [PATCH 0/1] Show progress when preparing eSDK (rebased)

[Paul Eggleton]

This patch from the earlier series wasn't merged, possibly since it
conflicted - I've rebased it onto master and resolved that.


The following changes since commit da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6:

  useradd-staticids: use map() instead of imap() (2016-07-12 23:11:57 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/startup-oe2
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/startup-oe2

Paul Eggleton (1):
  classes/populate_sdk_ext: show progress when preparing build system

 meta/classes/populate_sdk_ext.bbclass |  2 +-
 meta/files/ext-sdk-prepare.py | 67 ++-
 2 files changed, 44 insertions(+), 25 deletions(-)

-- 
2.5.5

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

Re: [OE-core] [PATCH 2/2] juce: Added support for JUCE framework

[Burton, Ross]

On 18 July 2016 at 11:07, Felipe Ferreri Tonello 
wrote:

> I can send this as part of meta-multimedia, no problem. What is the
> process to promote a recipe to oe-core?
>

To be part of oe-core you basically need to be able to demonstrate that a
large proportion of users will need it.  As this is an audio framework,
meta-multimedia is the obvious home for it.

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

Re: [OE-core] [PATCH 2/2] juce: Added support for JUCE framework

[Felipe Ferreri Tonello]

Hi Ross,

On 15/07/16 18:49, Burton, Ross wrote:
> 
> On 15 July 2016 at 17:36, Felipe F. Tonello  > wrote:
> 
> For TL;DRs: JUCE is a well known and widely used C++ Framework for audio
> applications. It has good support for Linux and ARM.
> 
> 
> Getting new recipes into oe-core has a high bar.  Why would this be in
> oe-core and not it's own layer, or part of meta-multimedia?
> 

Yes. I sent this patch to oe-core because I believe it is a great
addition to OE since this will enable many applications to be ported to
Embedded Linux that before was not possible. JUCE has no support for
Embedded Linux so far because most people doing Audio programming have
no experience with this side of things.

I can send this as part of meta-multimedia, no problem. What is the
process to promote a recipe to oe-core?

Anyhow, I have to resend a v2 of this recipe anyway because there are
some typos to be fixed.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH v2 1/1] image: add do_image_qa task to run QA checks on the constructed image

[Burton, Ross]

On 14 July 2016 at 14:36, Joshua Lock  wrote:

> +qamsg = qamsg + '\Image QA function %s failed' % e.name
>

I fixed this typo when merging to mut.

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

[OE-core] [PATCH] boost: fix CVE-2012-2677

[kai.kang]

From: Kai Kang 

Backport patch to fix CVE-2012-2677 for boost from:

https://svn.boost.org/trac/boost/changeset/78326

Signed-off-by: Kai Kang 
---
 .../boost/boost/boost-CVE-2012-2677.patch  | 112 +
 meta/recipes-support/boost/boost_1.61.0.bb |   1 +
 2 files changed, 113 insertions(+)
 create mode 100644 meta/recipes-support/boost/boost/boost-CVE-2012-2677.patch

diff --git a/meta/recipes-support/boost/boost/boost-CVE-2012-2677.patch 
b/meta/recipes-support/boost/boost/boost-CVE-2012-2677.patch
new file mode 100644
index 000..859f4aa
--- /dev/null
+++ b/meta/recipes-support/boost/boost/boost-CVE-2012-2677.patch
@@ -0,0 +1,112 @@
+Reference
+
+https://svn.boost.org/trac/boost/changeset/78326
+
+Upstream-Status: Backport
+
+Signed-off-by: Yue Tao 
+
+diff --git a/boost/pool/pool.hpp.old b/boost/pool/pool.hpp
+index c47b11f..417a1e0 100644
+--- a/boost/pool/pool.hpp.old
 b/boost/pool/pool.hpp
+@@ -26,6 +26,8 @@
+ 
+ #include 
+ 
++// std::numeric_limits
++#include 
+ // boost::integer::static_lcm
+ #include 
+ // boost::simple_segregated_storage
+@@ -355,6 +357,15 @@ class pool: protected simple_segregated_storage < 
typename UserAllocator::size_t
+   return s;
+ }
+ 
++size_type max_chunks() const
++{ //! Calculated maximum number of memory chunks that can be allocated in 
a single call by this Pool.
++  size_type partition_size = alloc_size();
++  size_type POD_size = math::static_lcm::value + sizeof(size_type);
++  size_type max_chunks = (std::numeric_limits::max() - 
POD_size) / alloc_size();
++
++  return max_chunks;
++}
++
+ static void * & nextof(void * const ptr)
+ { //! \returns Pointer dereferenced.
+   //! (Provided and used for the sake of code readability :)
+@@ -375,6 +386,8 @@ class pool: protected simple_segregated_storage < typename 
UserAllocator::size_t
+   //!   the first time that object needs to allocate system memory.
+   //!   The default is 32. This parameter may not be 0.
+   //! \param nmax_size is the maximum number of chunks to allocate in one 
block.
++  set_next_size(nnext_size);
++  set_max_size(nmax_size);
+ }
+ 
+ ~pool()
+@@ -398,8 +411,8 @@ class pool: protected simple_segregated_storage < typename 
UserAllocator::size_t
+ }
+ void set_next_size(const size_type nnext_size)
+ { //! Set number of chunks to request from the system the next time that 
object needs to allocate system memory. This value should never be set to 0.
+-  //! \returns nnext_size.
+-  next_size = start_size = nnext_size;
++  BOOST_USING_STD_MIN();
++  next_size = start_size = min 
BOOST_PREVENT_MACRO_SUBSTITUTION(nnext_size, max_chunks());
+ }
+ size_type get_max_size() const
+ { //! \returns max_size.
+@@ -407,7 +420,8 @@ class pool: protected simple_segregated_storage < typename 
UserAllocator::size_t
+ }
+ void set_max_size(const size_type nmax_size)
+ { //! Set max_size.
+-  max_size = nmax_size;
++  BOOST_USING_STD_MIN();
++  max_size = min BOOST_PREVENT_MACRO_SUBSTITUTION(nmax_size, 
max_chunks());
+ }
+ size_type get_requested_size() const
+ { //!   \returns the requested size passed into the constructor.
+@@ -708,9 +722,9 @@ void * pool::malloc_need_resize()
+ 
+   BOOST_USING_STD_MIN();
+   if(!max_size)
+-next_size <<= 1;
++set_next_size(next_size << 1);
+   else if( next_size*partition_size/requested_size < max_size)
+-next_size = min BOOST_PREVENT_MACRO_SUBSTITUTION(next_size << 1, 
max_size*requested_size/ partition_size);
++set_next_size(min BOOST_PREVENT_MACRO_SUBSTITUTION(next_size << 1, 
max_size * requested_size / partition_size));
+ 
+   //  initialize it,
+   store().add_block(node.begin(), node.element_size(), partition_size);
+@@ -748,9 +762,9 @@ void * pool::ordered_malloc_need_resize()
+ 
+   BOOST_USING_STD_MIN();
+   if(!max_size)
+-next_size <<= 1;
++set_next_size(next_size << 1);
+   else if( next_size*partition_size/requested_size < max_size)
+-next_size = min BOOST_PREVENT_MACRO_SUBSTITUTION(next_size << 1, 
max_size*requested_size/ partition_size);
++set_next_size(min BOOST_PREVENT_MACRO_SUBSTITUTION(next_size << 1, 
max_size * requested_size / partition_size));
+ 
+   //  initialize it,
+   //  (we can use "add_block" here because we know that
+@@ -792,6 +806,8 @@ void * pool::ordered_malloc(const size_type 
n)
+ { //! Gets address of a chunk n, allocating new memory if not already 
available.
+   //! \returns Address of chunk n if allocated ok.
+   //! \returns 0 if not enough memory for n chunks.
++  if (n > max_chunks())
++return 0;
+ 
+   const size_type partition_size = alloc_size();
+   const size_type total_req_size = n * requested_size;
+@@ -840,9 +856,9 @@ void * pool::ordered_malloc(const size_type 
n)
+ 
+