[PATCH 01/16] irda-utils: Weak Define the build TARGETS

[PATCH 01/16] irda-utils: Weak Define the build TARGETS

[Khem Raj]

This will help one to disable the targets via bbappends if needed
e.g. musl can not compile irdaping since it uses includes
net/if_packet.h, which (on GLIBC) only defines struct sockaddr_pkt but
not in other libc e.g. musl that makes irdaping specific to glibc

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb b/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
index bd60b9f..8ac3b18 100644
--- a/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
+++ b/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
@@ -32,15 +32,18 @@ EXTRA_OEMAKE = "\
 INITSCRIPT_NAME = "irattach"
 INITSCRIPT_PARAMS = "defaults 20"
 
+TARGETS ??= "irattach irdaping"
 do_compile () {
-	oe_runmake -C irattach
-	oe_runmake -C irdaping
+	for t in ${TARGETS}; do
+		oe_runmake -C $t
+	done
 }
 
 do_install () {
 	install -d ${D}${sbindir}
-	oe_runmake -C irattach ROOT="${D}" install
-	oe_runmake -C irdaping ROOT="${D}" install
+	for t in ${TARGETS}; do
+		oe_runmake -C $t ROOT="${D}" install
+	done
 
 	install -d ${D}${sysconfdir}/init.d
 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
-- 
2.5.1

[PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Khem Raj]

Fixes errors like

|
/home/ubuntu/work/oe/openembedded-core/build/tmp-musl/work/core2-64-oe-linux-musl/slang/2.2.4-r12/slang-2.2.4/src/slpo
sio.c:366:12: error: conflicting types for 'posix_close'
|  static int posix_close (SLFile_FD_Type *f)
|             ^
| In file included from
/home/ubuntu/work/oe/openembedded-core/build/tmp-musl/work/core2-64-oe-linux-musl/slang/2.2.4-r1
2/slang-2.2.4/src/slinclud.h:20:0,
|                  from
/home/ubuntu/work/oe/openembedded-core/build/tmp-musl/work/core2-64-oe-linux-musl/slang/2.2.4-r1
2/slang-2.2.4/src/slposio.c:24:
|
/home/ubuntu/work/oe/openembedded-core/build/tmp-musl/sysroots/qemux86-64/usr/include/unistd.h:38:5:
note: previous de
claration of 'posix_close' was here
|  int posix_close(int, int);
|      ^
| make[1]: ***
[/home/ubuntu/work/oe/openembedded-core/build/tmp-musl/work/core2-64-oe-linux-musl/slang/2.2.4-r12/slang-
2.2.4/src/elfobjs/slposio.o] Error 1

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...x-error-conflicting-types-for-posix_close.patch | 39 ++++++++++++++++++++++
 meta/recipes-extended/slang/slang_2.2.4.bb         |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 meta/recipes-extended/slang/slang/0001-Fix-error-conflicting-types-for-posix_close.patch

diff --git a/meta/recipes-extended/slang/slang/0001-Fix-error-conflicting-types-for-posix_close.patch b/meta/recipes-extended/slang/slang/0001-Fix-error-conflicting-types-for-posix_close.patch
new file mode 100644
index 0000000..57ebfe4
--- /dev/null
+++ b/meta/recipes-extended/slang/slang/0001-Fix-error-conflicting-types-for-posix_close.patch
@@ -0,0 +1,39 @@
+From 96eb7e29822151823a66a1eb59f1fa4aead5ae08 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 31 Aug 2015 06:33:21 +0000
+Subject: [PATCH] Fix  error: conflicting types for 'posix_close'
+
+Exposed while compiling on musl
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ src/slposio.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/slposio.c b/src/slposio.c
+index 9ce9697..9ff9bfe 100644
+--- a/src/slposio.c
++++ b/src/slposio.c
+@@ -363,7 +363,7 @@ static int posix_close_fd (int *fd)
+    return 0;
+ }
+ 
+-static int posix_close (SLFile_FD_Type *f)
++static int posix_closex (SLFile_FD_Type *f)
+ {
+    int status = do_close (f);
+ 
+@@ -1001,7 +1001,7 @@ static SLang_Intrin_Fun_Type Fd_Name_Table [] =
+    MAKE_INTRINSIC_2("write", posix_write, V, F, B),
+    MAKE_INTRINSIC_1("dup_fd", posix_dup, V, F),
+    MAKE_INTRINSIC_2("dup2_fd", posix_dup2, I, F, I),
+-   MAKE_INTRINSIC_1("close", posix_close, I, F),
++   MAKE_INTRINSIC_1("close", posix_closex, I, F),
+    MAKE_INTRINSIC_1("_close", posix_close_fd, I, I),
+ #if defined(TTYNAME_R)
+    MAKE_INTRINSIC_0("ttyname", posix_ttyname, V),
+-- 
+2.5.1
+
diff --git a/meta/recipes-extended/slang/slang_2.2.4.bb b/meta/recipes-extended/slang/slang_2.2.4.bb
index 25f1b0c..5122f53 100644
--- a/meta/recipes-extended/slang/slang_2.2.4.bb
+++ b/meta/recipes-extended/slang/slang_2.2.4.bb
@@ -22,6 +22,7 @@ SRC_URI = "ftp://space.mit.edu/pub/davis/slang/v2.2/slang-${PV}.tar.bz2 \
            file://change-char-type-to-signed-char-in-macros.patch \
            file://sprintf-bug-concerning-8-bit-characters.patch \
            file://slang-fix-the-iconv-existence-checking.patch \
+           file://0001-Fix-error-conflicting-types-for-posix_close.patch \
           "
 
 inherit autotools-brokensep
-- 
2.5.1

[PATCH 03/16] sudo: Include sys/types.h for id_t definition

[Khem Raj]

This is exposed by musl, on glibc sys/types.h comes as indirect include
from other include myriad.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...1-Include-sys-types.h-for-id_t-definition.patch | 34 ++++++++++++++++++++++
 meta/recipes-extended/sudo/sudo_1.8.14p3.bb        |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-extended/sudo/sudo/0001-Include-sys-types.h-for-id_t-definition.patch

diff --git a/meta/recipes-extended/sudo/sudo/0001-Include-sys-types.h-for-id_t-definition.patch b/meta/recipes-extended/sudo/sudo/0001-Include-sys-types.h-for-id_t-definition.patch
new file mode 100644
index 0000000..eb36cd4
--- /dev/null
+++ b/meta/recipes-extended/sudo/sudo/0001-Include-sys-types.h-for-id_t-definition.patch
@@ -0,0 +1,34 @@
+From 386e2c2fa2ab2e02ef71c268a57205139be329ab Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 31 Aug 2015 07:07:49 +0000
+Subject: [PATCH] Include sys/types.h for id_t definition
+
+/sudo_util.h:219:14: error: unknown type name 'id_t'
+ __dso_public id_t sudo_strtoid_v1(const char *str, const char *sep,
+ char **endp, const char **errstr);
+               ^
+	       make[1]: *** [preserve_fds.o] Error 1
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ include/sudo_util.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/include/sudo_util.h b/include/sudo_util.h
+index 89c9f89..ac0855a 100644
+--- a/include/sudo_util.h
++++ b/include/sudo_util.h
+@@ -17,6 +17,8 @@
+ #ifndef SUDO_UTIL_H
+ #define SUDO_UTIL_H
+ 
++#include <sys/types.h>
++
+ #ifdef HAVE_STDBOOL_H
+ # include <stdbool.h>
+ #else
+-- 
+2.5.1
+
diff --git a/meta/recipes-extended/sudo/sudo_1.8.14p3.bb b/meta/recipes-extended/sudo/sudo_1.8.14p3.bb
index ea37aaf..93b9bb4 100644
--- a/meta/recipes-extended/sudo/sudo_1.8.14p3.bb
+++ b/meta/recipes-extended/sudo/sudo_1.8.14p3.bb
@@ -3,6 +3,7 @@ require sudo.inc
 SRC_URI = "http://ftp.sudo.ws/sudo/dist/sudo-${PV}.tar.gz \
            ${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)} \
            file://0001-Use-correct-path-to-init.d-and-tmpfiles.d-files.patch \
+           file://0001-Include-sys-types.h-for-id_t-definition.patch \
            "
 
 PAM_SRC_URI = "file://sudo.pam"
-- 
2.5.1

[PATCH 04/16] man: Use -DSYSV when builing for linux

[Khem Raj]

We needed this define but were getting away since glibc indirectly
included fcntl.h but man sources clearly guard inclusion of fcntl.h with
SYSV, this is uncovered with musl

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-extended/man/man_1.6g.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/man/man_1.6g.bb b/meta/recipes-extended/man/man_1.6g.bb
index 6a4c734..fa4736b 100644
--- a/meta/recipes-extended/man/man_1.6g.bb
+++ b/meta/recipes-extended/man/man_1.6g.bb
@@ -58,6 +58,8 @@ SRC_URI = "http://pkgs.fedoraproject.org/lookaside/pkgs/man2html/${BP}.tar.gz/ba
 SRC_URI[md5sum] = "ba154d5796928b841c9c69f0ae376660"
 SRC_URI[sha256sum] = "ccdcb8c3f4e0080923d7e818f0e4a202db26c46415eaef361387c20995b8959f"
 
+CFLAGS += "-DSYSV"
+
 do_configure () {
         ${S}/configure -default -confdir /etc +sgid +fhs +lang all
 }
-- 
2.5.1

[PATCH 05/16] minicom: Fix build with musl

[Khem Raj]

musl exposes the inherent assumption about certain header files from
glibc

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...0001-Fix-build-issus-surfaced-due-to-musl.patch | 47 ++++++++++++++++++++++
 meta/recipes-extended/minicom/minicom_2.7.bb       |  1 +
 2 files changed, 48 insertions(+)
 create mode 100644 meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch

diff --git a/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch b/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
new file mode 100644
index 0000000..fec67fd
--- /dev/null
+++ b/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
@@ -0,0 +1,47 @@
+From d62a5862e26ed3fc58d789efe9c40ca6c911d36b Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 31 Aug 2015 22:35:31 +0000
+Subject: [PATCH] Fix build issus surfaced due to musl
+
+src/getsdir.h:28:14: error: 'MAXNAMLEN' undeclared here (not in a function)
+   char fname[MAXNAMLEN + 1];  /* filename + terminating null */
+
+src/dial.c:352:22: error: 'KIOCSOUND' undeclared (first use in this function)
+|      ioctl(consolefd, KIOCSOUND, k);
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ src/dial.c    | 2 +-
+ src/getsdir.c | 1 +
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/dial.c b/src/dial.c
+index a90c1d2..bf02574 100644
+--- a/src/dial.c
++++ b/src/dial.c
+@@ -39,7 +39,7 @@
+ #include "intl.h"
+ 
+ #ifdef VC_MUSIC
+-#  if defined(__GLIBC__)
++#  if defined(__GLIBC__) || defined(__linux__)
+ #    include <sys/ioctl.h>
+ #    include <sys/kd.h>
+ #    include <sys/time.h>
+diff --git a/src/getsdir.c b/src/getsdir.c
+index 2195b27..b61a361 100644
+--- a/src/getsdir.c
++++ b/src/getsdir.c
+@@ -30,6 +30,7 @@
+ #include <string.h>
+ #include <sys/types.h>
+ #include <sys/stat.h>
++#include <sys/param.h>
+ #include <errno.h>
+ 
+ #include "getsdir.h"
+-- 
+2.5.1
+
diff --git a/meta/recipes-extended/minicom/minicom_2.7.bb b/meta/recipes-extended/minicom/minicom_2.7.bb
index c002bc8..1575cfb 100644
--- a/meta/recipes-extended/minicom/minicom_2.7.bb
+++ b/meta/recipes-extended/minicom/minicom_2.7.bb
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=420477abc567404debca0a2a1cb6b645 \
 SRC_URI = "https://alioth.debian.org/frs/download.php/latestfile/3/${BP}.tar.gz \
            file://allow.to.disable.lockdev.patch \
            file://0001-fix-minicom-h-v-return-value-is-not-0.patch \
+           file://0001-Fix-build-issus-surfaced-due-to-musl.patch \
           "
 
 SRC_URI[md5sum] = "7044ca3e291268c33294f171d426dc2d"
-- 
2.5.1

[PATCH 00/16] Recipes fixes for clang

[Khem Raj]

This patch series is about common fixes that came to fore due to clang compilation
some of the fixes are real bugs which were latent and has been submitted upstream,
some were backports and some are yet to be submitted

The following changes since commit 8402958cd2cb87b8283c8ee4e2d08e1a6717d67a:

  pseudo_1.7.3.bb: New version of pseudo (2015-09-06 15:24:28 +0100)

are available in the git repository at:

  git://github.com/kraj/openembedded-core clang
  https://github.com/kraj/openembedded-core/tree/clang

Khem Raj (16):
  irda-utils: Weak Define the build TARGETS
  slang: Fix namespace conflict vis-a-vis posix_close
  sudo: Include sys/types.h for id_t definition
  man: Use -DSYSV when builing for linux
  minicom: Fix build with musl
  bdwgc: Include signal.h instead of hard asm/sigcontext.h
  ccache: Dont add LDFLAGS to compiler flags
  latencytop: Fix build with clang
  alsa-tools: Fix compiling with clang
  kexec-tools: Pass -r directly to linker
  xorg-driver: Fix logical && with bitwise and operation
  puzzles: Fix build with clang
  sudo: Disable rsize_t deliberately
  webkit-gtk: Backport fix to remove FrameDestructionObserver
  mdadm: Fix bugs exposed by clang
  directfb: Avoid using VLAs and printf formats

 .../irda-utils/irda-utils_0.9.18.bb                |  11 ++-
 meta/recipes-devtools/ccache/ccache.inc            |   2 -
 meta/recipes-extended/man/man_1.6g.bb              |   2 +
 .../mdadm/files/0001-Fix-typo-in-comparision.patch |  86 +++++++++++++++++
 meta/recipes-extended/mdadm/mdadm_3.3.4.bb         |   1 +
 ...0001-Fix-build-issus-surfaced-due-to-musl.patch |  47 +++++++++
 meta/recipes-extended/minicom/minicom_2.7.bb       |   1 +
 ...x-error-conflicting-types-for-posix_close.patch |  39 ++++++++
 meta/recipes-extended/slang/slang_2.2.4.bb         |   1 +
 ...1-Include-sys-types.h-for-id_t-definition.patch |  34 +++++++
 meta/recipes-extended/sudo/sudo_1.8.14p3.bb        |   2 +
 meta/recipes-graphics/directfb/directfb.inc        |   4 +-
 ...direct-Aboid-usng-VLAs-and-printf-formats.patch |  61 ++++++++++++
 ...put_dpms-Replace-logical-with-bitwise-ope.patch |  31 ++++++
 .../xorg-driver/xf86-video-omap_0.4.3.bb           |   2 +
 .../0001-purgatory-Pass-r-directly-to-linker.patch |  32 +++++++
 meta/recipes-kernel/kexec/kexec-tools_2.0.10.bb    |   1 +
 ...-function-signatures-to-fix-prototype-mis.patch |  64 +++++++++++++
 meta/recipes-kernel/latencytop/latencytop_0.5.bb   |   6 +-
 ...s10k1-Make-output_tram_line-static-inline.patch |  31 ++++++
 meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb  |   1 +
 .../files/0001-Use-labs-instead-of-abs.patch       |  46 +++++++++
 meta/recipes-sato/puzzles/puzzles_git.bb           |   1 +
 ...ride-of-FrameDestructionObserver-willDeta.patch | 105 +++++++++++++++++++++
 meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb       |   1 +
 .../bdwgc/bdwgc/0001-fix-build-with-musl.patch     |  35 +++++++
 meta/recipes-support/bdwgc/bdwgc_7.4.2.bb          |   4 +-
 27 files changed, 641 insertions(+), 10 deletions(-)
 create mode 100644 meta/recipes-extended/mdadm/files/0001-Fix-typo-in-comparision.patch
 create mode 100644 meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
 create mode 100644 meta/recipes-extended/slang/slang/0001-Fix-error-conflicting-types-for-posix_close.patch
 create mode 100644 meta/recipes-extended/sudo/sudo/0001-Include-sys-types.h-for-id_t-definition.patch
 create mode 100644 meta/recipes-graphics/directfb/directfb/0001-gfx-direct-Aboid-usng-VLAs-and-printf-formats.patch
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch
 create mode 100644 meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch
 create mode 100644 meta/recipes-kernel/latencytop/latencytop-0.5/0001-Rectify-the-function-signatures-to-fix-prototype-mis.patch
 create mode 100644 meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
 create mode 100644 meta/recipes-sato/puzzles/files/0001-Use-labs-instead-of-abs.patch
 create mode 100644 meta/recipes-sato/webkit/webkit-gtk-1.8.3/0001-Remove-override-of-FrameDestructionObserver-willDeta.patch
 create mode 100644 meta/recipes-support/bdwgc/bdwgc/0001-fix-build-with-musl.patch

-- 
2.5.1

[PATCH 06/16] bdwgc: Include signal.h instead of hard asm/sigcontext.h

[Khem Raj]

All cases are about glibc and for non-glibc systems it falls back to
last else choice which still is glibc's older version, ideally it
should have a case where libc != glibc

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../bdwgc/bdwgc/0001-fix-build-with-musl.patch     | 35 ++++++++++++++++++++++
 meta/recipes-support/bdwgc/bdwgc_7.4.2.bb          |  4 ++-
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/bdwgc/bdwgc/0001-fix-build-with-musl.patch

diff --git a/meta/recipes-support/bdwgc/bdwgc/0001-fix-build-with-musl.patch b/meta/recipes-support/bdwgc/bdwgc/0001-fix-build-with-musl.patch
new file mode 100644
index 0000000..ab907fc
--- /dev/null
+++ b/meta/recipes-support/bdwgc/bdwgc/0001-fix-build-with-musl.patch
@@ -0,0 +1,35 @@
+From 829a89e7f5785239a9384e3afd46c900f9d76ada Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 31 Aug 2015 19:55:32 +0000
+Subject: [PATCH] fix build with musl
+
+signal.h already includes bits/sigcontext.h
+Documentation seems to indicate that if you need the definitions in
+sigcontext.h, you are supposed to include signal.h and not sigcontext.h.
+
+a good fix should be to remove glibc
+specific understanding, in those ifdef's
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ os_dep.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/os_dep.c b/os_dep.c
+index 08c501d..5cb7873 100644
+--- a/os_dep.c
++++ b/os_dep.c
+@@ -41,7 +41,7 @@
+ #   else /* __GLIBC__ < 2 */
+       /* libc5 doesn't have <sigcontext.h>: go directly with the kernel   */
+       /* one.  Check LINUX_VERSION_CODE to see which we should reference. */
+-#     include <asm/sigcontext.h>
++#     include <signal.h>
+ #   endif /* __GLIBC__ < 2 */
+ # endif
+ #endif /* LINUX && !POWERPC */
+-- 
+2.5.1
+
diff --git a/meta/recipes-support/bdwgc/bdwgc_7.4.2.bb b/meta/recipes-support/bdwgc/bdwgc_7.4.2.bb
index 1ca8cf7..95e358f 100644
--- a/meta/recipes-support/bdwgc/bdwgc_7.4.2.bb
+++ b/meta/recipes-support/bdwgc/bdwgc_7.4.2.bb
@@ -21,7 +21,9 @@ SECTION = "devel"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://README.QUICK;md5=55f5088f90a982fed7af9a4897047ef7"
 
-SRC_URI = "http://www.hboehm.info/gc/gc_source/gc-${PV}.tar.gz"
+SRC_URI = "http://www.hboehm.info/gc/gc_source/gc-${PV}.tar.gz \
+           file://0001-fix-build-with-musl.patch \
+          "
 
 SRC_URI[md5sum] = "12c05fd2811d989341d8c6d81f66af87"
 SRC_URI[sha256sum] = "63320ad7c45460e4a40e03f5aa4c6893783f21a16416c3282b994f933312afa2"
-- 
2.5.1

[PATCH 07/16] ccache: Dont add LDFLAGS to compiler flags

[Khem Raj]

This is no longer required, its been carried over for a long time. As a
side effect it helps compiling ccache with clang

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/ccache/ccache.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-devtools/ccache/ccache.inc b/meta/recipes-devtools/ccache/ccache.inc
index 4790021..69aa64e 100644
--- a/meta/recipes-devtools/ccache/ccache.inc
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -16,5 +16,3 @@ S = "${WORKDIR}/git"
 inherit autotools
 
 BBCLASSEXTEND = "native"
-
-TARGET_CC_ARCH += "${LDFLAGS}"
-- 
2.5.1

[PATCH 08/16] latencytop: Fix build with clang

[Khem Raj]

Clang is stricter with syntax checking and flags the functions return
values if they dont match with function signatures, Fixed thusly

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...-function-signatures-to-fix-prototype-mis.patch | 64 ++++++++++++++++++++++
 meta/recipes-kernel/latencytop/latencytop_0.5.bb   |  6 +-
 2 files changed, 68 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-kernel/latencytop/latencytop-0.5/0001-Rectify-the-function-signatures-to-fix-prototype-mis.patch

diff --git a/meta/recipes-kernel/latencytop/latencytop-0.5/0001-Rectify-the-function-signatures-to-fix-prototype-mis.patch b/meta/recipes-kernel/latencytop/latencytop-0.5/0001-Rectify-the-function-signatures-to-fix-prototype-mis.patch
new file mode 100644
index 0000000..b248133
--- /dev/null
+++ b/meta/recipes-kernel/latencytop/latencytop-0.5/0001-Rectify-the-function-signatures-to-fix-prototype-mis.patch
@@ -0,0 +1,64 @@
+From db112739dc4f608a968b8104b382955dc3d96ca3 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 7 Sep 2015 07:40:10 +0000
+Subject: [PATCH] Rectify the function signatures to fix prototype mismatches
+
+clang is less forgiving when it comes to coding standards, correct the
+function signatures to reflect the function logic
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ fsync.c      | 7 ++++---
+ latencytop.h | 2 +-
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/fsync.c b/fsync.c
+index 82dff0e..5cefba9 100644
+--- a/fsync.c
++++ b/fsync.c
+@@ -51,7 +51,7 @@ struct fsync_files {
+ static GList *fsync_data;
+ 
+ 
+-static chain_file(struct fsync_process *proc, char *filename)
++static void chain_file(struct fsync_process *proc, char *filename)
+ {
+ 	struct fsync_files *file;
+ 	GList *item;
+@@ -75,7 +75,7 @@ static chain_file(struct fsync_process *proc, char *filename)
+ 	proc->files = g_list_append(proc->files, file);
+ }
+ 
+-static report_file(char *process, char *file)
++static void report_file(char *process, char *file)
+ {
+ 	struct fsync_process *proc;
+ 	GList *item;
+@@ -157,9 +157,10 @@ int enable_fsync_tracer(void)
+ 	write_to_file("/sys/kernel/debug/tracing/current_tracer", "fsync");	
+ 	write_to_file("/sys/kernel/debug/tracing/iter_ctrl", "ftrace_printk");	
+ 	write_to_file("/sys/kernel/debug/tracing/tracing_on", "1");
++	return ret;
+ }
+ 
+-int disable_fsync_tracer(void)
++void disable_fsync_tracer(void)
+ {
+ 	write_to_file("/sys/kernel/debug/tracing/tracing_on", "0");
+ }
+diff --git a/latencytop.h b/latencytop.h
+index 5394d73..9d107a8 100644
+--- a/latencytop.h
++++ b/latencytop.h
+@@ -54,5 +54,5 @@ extern char *translate(char *line);
+ extern void init_translations(char *filename);
+ extern int fsync_display(int duration);
+ extern int enable_fsync_tracer(void);
+-extern int disable_fsync_tracer(void);
++extern void disable_fsync_tracer(void);
+ extern void update_list(void);
+-- 
+2.5.1
+
diff --git a/meta/recipes-kernel/latencytop/latencytop_0.5.bb b/meta/recipes-kernel/latencytop/latencytop_0.5.bb
index cb0a3c5..f31f1bb 100644
--- a/meta/recipes-kernel/latencytop/latencytop_0.5.bb
+++ b/meta/recipes-kernel/latencytop/latencytop_0.5.bb
@@ -10,7 +10,9 @@ PR = "r3"
 
 SRC_URI = "http://pkgs.fedoraproject.org/repo/pkgs/${BPN}/${BP}.tar.gz/73bb3371c6ee0b0e68e25289027e865c/${BP}.tar.gz \
             file://latencytop-makefile.patch \
-            file://latencytop-fsync.patch"
+            file://latencytop-fsync.patch \
+            file://0001-Rectify-the-function-signatures-to-fix-prototype-mis.patch \
+"
 
 SRC_URI[md5sum] = "73bb3371c6ee0b0e68e25289027e865c"
 SRC_URI[sha256sum] = "9e7f72fbea7bd918e71212a1eabaad8488d2c602205d2e3c95d62cd57e9203ef"
@@ -21,7 +23,7 @@ PACKAGECONFIG[x11] = ",,gtk+"
 
 EXTRA_OEMAKE_X = "${@bb.utils.contains('PACKAGECONFIG', 'x11', 'HAS_GTK_GUI=1', '', d)}"
 
-CFLAGS += "${LDFLAGS}"
+#CFLAGS += "${LDFLAGS}"
 
 do_install() {
     oe_runmake install DESTDIR=${D} ${EXTRA_OEMAKE_X}
-- 
2.5.1

[PATCH 09/16] alsa-tools: Fix compiling with clang

[Khem Raj]

Fixed a linking error occurring when building with clang, where a
function reference is emitted but function is not since its marked as
inline, making it static inline gives better opportunity to compiler to
compile it

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...s10k1-Make-output_tram_line-static-inline.patch | 31 ++++++++++++++++++++++
 meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb  |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch

diff --git a/meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch b/meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
new file mode 100644
index 0000000..d049a30
--- /dev/null
+++ b/meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
@@ -0,0 +1,31 @@
+From 1e5926df74a35fe2cd90bc59f5264a8715c94048 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 7 Sep 2015 08:16:59 +0000
+Subject: [PATCH] as10k1: Make output_tram_line() static inline
+
+The function is not used in any other file, its better to make it static
+inline so compiler has a better chance of optimizing here
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ as10k1/as10k1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/as10k1/as10k1.c b/as10k1/as10k1.c
+index 96af0c3..d0766fd 100644
+--- a/as10k1/as10k1.c
++++ b/as10k1/as10k1.c
+@@ -366,7 +366,7 @@ void as_exit(const char *message)
+ 	exit(1);
+ }
+ 
+-inline void output_tram_line( struct list_head *line_head, int type){
++static inline void output_tram_line( struct list_head *line_head, int type){
+         
+         struct tram *tram_sym;
+         struct list_head *entry;
+-- 
+2.5.1
+
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb b/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
index b5b9cc4..fdf396e 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
@@ -13,6 +13,7 @@ SRC_URI = "ftp://ftp.alsa-project.org/pub/tools/${BP}.tar.bz2 \
            ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', \
                                 'file://makefile_no_gtk.patch', d)} \
            file://gitcompile_hdajacksensetest \
+           file://0001-as10k1-Make-output_tram_line-static-inline.patch \
           "
 
 SRC_URI[md5sum] = "f339a3cd24f748c9d007bdff0e98775b"
-- 
2.5.1

[PATCH 10/16] kexec-tools: Pass -r directly to linker

[Khem Raj]

-r is understood by gcc but not by clang, anyway its a linker option so
pass it straight to linker by using -Wl explicitly

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../0001-purgatory-Pass-r-directly-to-linker.patch | 32 ++++++++++++++++++++++
 meta/recipes-kernel/kexec/kexec-tools_2.0.10.bb    |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch

diff --git a/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch b/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch
new file mode 100644
index 0000000..bfd077d
--- /dev/null
+++ b/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch
@@ -0,0 +1,32 @@
+From a1135b3170963ba956f2364c1283864c35541295 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 7 Sep 2015 07:59:45 +0000
+Subject: [PATCH] purgatory: Pass -r directly to linker
+
+This helps compiling with clang since -r is not a known option for clang
+where as gcc knows how to deal with it and passes it down to linker
+unfiltered
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ purgatory/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/purgatory/Makefile b/purgatory/Makefile
+index 2b5c061..b251353 100644
+--- a/purgatory/Makefile
++++ b/purgatory/Makefile
+@@ -61,7 +61,7 @@ $(PURGATORY): CPPFLAGS=$($(ARCH)_PURGATORY_EXTRA_CFLAGS) \
+ 			-I$(shell $(CC) -print-file-name=include)
+ $(PURGATORY): LDFLAGS=$($(ARCH)_PURGATORY_EXTRA_CFLAGS)\
+ 			-Wl,--no-undefined -nostartfiles -nostdlib \
+-			-nodefaultlibs -e purgatory_start -r \
++			-nodefaultlibs -e purgatory_start -Wl,-r \
+ 			-Wl,-Map=$(PURGATORY_MAP)
+ 
+ $(PURGATORY): $(PURGATORY_OBJS)
+-- 
+2.5.1
+
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.10.bb b/meta/recipes-kernel/kexec/kexec-tools_2.0.10.bb
index dd7bba7..ffdb983 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.10.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.10.bb
@@ -6,6 +6,7 @@ SRC_URI += "file://kexec-tools-Refine-kdump-device_tree-sort.patch \
             file://kexec-aarch64.patch \
             file://kexec-x32.patch \
             file://0002-powerpc-change-the-memory-size-limit.patch \
+            file://0001-purgatory-Pass-r-directly-to-linker.patch \
          "
 
 SRC_URI[md5sum] = "6cb4d22bcec71b6e070aa8e9d990a5e6"
-- 
2.5.1

[PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Khem Raj]

This must have been a typo which is a bug infact we should have used
bitwise & in first place.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...put_dpms-Replace-logical-with-bitwise-ope.patch | 31 ++++++++++++++++++++++
 .../xorg-driver/xf86-video-omap_0.4.3.bb           |  2 ++
 2 files changed, 33 insertions(+)
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch

diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch b/meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch
new file mode 100644
index 0000000..41e77d3
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch
@@ -0,0 +1,31 @@
+From fc653ca3b36435aea281ae409fb90f85e1bc0d81 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 7 Sep 2015 08:44:13 +0000
+Subject: [freedreno][PATCH] drmmode_output_dpms: Replace logical && with bitwise &
+ operation
+
+This is a mask calculation so bitbwise & should have been used
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Submitted
+
+ src/drmmode_display.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/drmmode_display.c b/src/drmmode_display.c
+index c3cf4f8..eb54b59 100644
+--- a/src/drmmode_display.c
++++ b/src/drmmode_display.c
+@@ -777,7 +777,7 @@ drmmode_output_dpms(xf86OutputPtr output, int mode)
+ 
+ 	for (i = 0; i < koutput->count_props; i++) {
+ 		props = drmModeGetProperty(drmmode->fd, koutput->props[i]);
+-		if (props && (props->flags && DRM_MODE_PROP_ENUM)) {
++		if (props && (props->flags & DRM_MODE_PROP_ENUM)) {
+ 			if (!strcmp(props->name, "DPMS")) {
+ 				mode_id = koutput->props[i];
+ 				drmModeFreeProperty(props);
+-- 
+2.5.1
+
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omap_0.4.3.bb b/meta/recipes-graphics/xorg-driver/xf86-video-omap_0.4.3.bb
index 5f3a532..76682ed 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-omap_0.4.3.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-omap_0.4.3.bb
@@ -24,6 +24,8 @@ LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=10ce5de3b111315ea652a5f74ec0c602"
 DEPENDS += "virtual/libx11 libdrm xf86driproto"
 
+SRC_URI += "file://0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch"
+
 SRC_URI[md5sum] = "be35daf6fa4b75092cc4a8978c437bc5"
 SRC_URI[sha256sum] = "db1e0e69fd4c4c8fdca5ef2cb0447bccd7518a718495876a6904bef57b39986d"
 
-- 
2.5.1

[PATCH 12/16] puzzles: Fix build with clang

[Khem Raj]

Clang uncovered an error where abs() is used on long types, we shoud be
using labs()

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../files/0001-Use-labs-instead-of-abs.patch       | 46 ++++++++++++++++++++++
 meta/recipes-sato/puzzles/puzzles_git.bb           |  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 meta/recipes-sato/puzzles/files/0001-Use-labs-instead-of-abs.patch

diff --git a/meta/recipes-sato/puzzles/files/0001-Use-labs-instead-of-abs.patch b/meta/recipes-sato/puzzles/files/0001-Use-labs-instead-of-abs.patch
new file mode 100644
index 0000000..f43d1df
--- /dev/null
+++ b/meta/recipes-sato/puzzles/files/0001-Use-labs-instead-of-abs.patch
@@ -0,0 +1,46 @@
+From 9808dc09e08937c9bffd858d3ded428225a4312a Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 7 Sep 2015 09:02:38 +0000
+Subject: [PATCH] Use labs instead of abs
+
+cluevals is array of longs so we have to use labs() instead of abs()
+since abs() returns int
+
+Fixes
+
+keen.c:1458:17: error: absolute value function 'abs' given an argument
+of type 'long' but has parameter of type 'int' which may cause
+truncation of value
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ keen.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/keen.c b/keen.c
+index a6a7238..1631992 100644
+--- a/keen.c
++++ b/keen.c
+@@ -1043,7 +1043,7 @@ done
+ 		    cluevals[j] *= grid[i];
+ 		    break;
+ 		  case C_SUB:
+-		    cluevals[j] = abs(cluevals[j] - grid[i]);
++		    cluevals[j] = labs(cluevals[j] - grid[i]);
+ 		    break;
+ 		  case C_DIV:
+ 		    {
+@@ -1455,7 +1455,7 @@ static int check_errors(const game_state *state, long *errors)
+ 		cluevals[j] *= state->grid[i];
+ 		break;
+ 	      case C_SUB:
+-		cluevals[j] = abs(cluevals[j] - state->grid[i]);
++		cluevals[j] = labs(cluevals[j] - state->grid[i]);
+ 		break;
+ 	      case C_DIV:
+ 		{
+-- 
+2.5.1
+
diff --git a/meta/recipes-sato/puzzles/puzzles_git.bb b/meta/recipes-sato/puzzles/puzzles_git.bb
index 11e9225..95826c1 100644
--- a/meta/recipes-sato/puzzles/puzzles_git.bb
+++ b/meta/recipes-sato/puzzles/puzzles_git.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = "file://LICENCE;md5=33bcd4bce8f3c197f2aefbdbd2d299bc"
 
 SRC_URI = "git://git.tartarus.org/simon/puzzles.git \
            file://fix-compiling-failure-with-option-g-O.patch \
+           file://0001-Use-labs-instead-of-abs.patch \
 "
 SRCREV = "c296301a06ce49b87c954c9d15452521dfeddf1a"
 PE = "1"
-- 
2.5.1

[PATCH 13/16] sudo: Disable rsize_t deliberately

[Khem Raj]

gcc does not have it but clang does, problem happens when host compiler
is gcc and cross compiler is clang, because autoconf detects it with
clang and slaps it to host compiler as well

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-extended/sudo/sudo_1.8.14p3.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-extended/sudo/sudo_1.8.14p3.bb b/meta/recipes-extended/sudo/sudo_1.8.14p3.bb
index 93b9bb4..6b3cd6d 100644
--- a/meta/recipes-extended/sudo/sudo_1.8.14p3.bb
+++ b/meta/recipes-extended/sudo/sudo_1.8.14p3.bb
@@ -15,6 +15,7 @@ DEPENDS += " ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 RDEPENDS_${PN} += " ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-limits pam-plugin-keyinit', '', d)}"
 
 EXTRA_OECONF += " \
+             ac_cv_type_rsize_t=no \
              ${@bb.utils.contains('DISTRO_FEATURES', 'pam', '--with-pam', '--without-pam', d)} \
              ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--enable-tmpfiles.d=${libdir}/tmpfiles.d', '--disable-tmpfiles.d', d)} \
              "
-- 
2.5.1

[PATCH 14/16] webkit-gtk: Backport fix to remove FrameDestructionObserver

[Khem Raj]

This helps clang compile webkit without problems. This is a backport
from upstream

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...ride-of-FrameDestructionObserver-willDeta.patch | 105 +++++++++++++++++++++
 meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb       |   1 +
 2 files changed, 106 insertions(+)
 create mode 100644 meta/recipes-sato/webkit/webkit-gtk-1.8.3/0001-Remove-override-of-FrameDestructionObserver-willDeta.patch

diff --git a/meta/recipes-sato/webkit/webkit-gtk-1.8.3/0001-Remove-override-of-FrameDestructionObserver-willDeta.patch b/meta/recipes-sato/webkit/webkit-gtk-1.8.3/0001-Remove-override-of-FrameDestructionObserver-willDeta.patch
new file mode 100644
index 0000000..c8761d8
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkit-gtk-1.8.3/0001-Remove-override-of-FrameDestructionObserver-willDeta.patch
@@ -0,0 +1,105 @@
+From 540a792c05f0c7800f694eb39a04d8c31b685789 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 7 Sep 2015 16:36:02 +0000
+Subject: [PATCH] Remove override of FrameDestructionObserver::willDetachPage()
+
+Reviewed by Antti Koivisto.
+This callback was only used by the Chromium port.
+editing/Editor.h:
+editing/Editor.cpp:
+Remove override of FrameDestructionObserver::willDetachPage().
+page/EditorClient.h:
+Remove frameWillDetachPage(). This is repeated in every EditorClient subclass.
+
+Backported from https://bugs.webkit.org/show_bug.cgi?id=119950
+
+Upstream-Status: Backport
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ Source/WebCore/editing/Editor.cpp                          | 6 ------
+ Source/WebCore/editing/Editor.h                            | 1 -
+ Source/WebCore/loader/EmptyClients.h                       | 1 -
+ Source/WebCore/page/EditorClient.h                         | 1 -
+ Source/WebKit/gtk/WebCoreSupport/EditorClientGtk.h         | 1 -
+ Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h | 1 -
+ 6 files changed, 11 deletions(-)
+
+diff --git a/Source/WebCore/editing/Editor.cpp b/Source/WebCore/editing/Editor.cpp
+index 45c5612..2af4057 100644
+--- a/Source/WebCore/editing/Editor.cpp
++++ b/Source/WebCore/editing/Editor.cpp
+@@ -3020,10 +3020,4 @@ bool Editor::unifiedTextCheckerEnabled() const
+     return WebCore::unifiedTextCheckerEnabled(m_frame);
+ }
+ 
+-void Editor::willDetachPage()
+-{
+-    if (EditorClient* editorClient = client())
+-        editorClient->frameWillDetachPage(frame());
+-}
+-
+ } // namespace WebCore
+diff --git a/Source/WebCore/editing/Editor.h b/Source/WebCore/editing/Editor.h
+index 32fc3dc..0c8cc40 100644
+--- a/Source/WebCore/editing/Editor.h
++++ b/Source/WebCore/editing/Editor.h
+@@ -385,7 +385,6 @@ public:
+     void deviceScaleFactorChanged();
+ 
+ private:
+-    virtual void willDetachPage() OVERRIDE;
+ 
+     OwnPtr<DeleteButtonController> m_deleteButtonController;
+     RefPtr<CompositeEditCommand> m_lastEditCommand;
+diff --git a/Source/WebCore/loader/EmptyClients.h b/Source/WebCore/loader/EmptyClients.h
+index 76e6642..7525a42 100644
+--- a/Source/WebCore/loader/EmptyClients.h
++++ b/Source/WebCore/loader/EmptyClients.h
+@@ -439,7 +439,6 @@ public:
+     EmptyEditorClient() { }
+     virtual ~EmptyEditorClient() { }
+     virtual void pageDestroyed() { }
+-    virtual void frameWillDetachPage(Frame*) { }
+ 
+     virtual bool shouldDeleteRange(Range*) { return false; }
+     virtual bool shouldShowDeleteInterface(HTMLElement*) { return false; }
+diff --git a/Source/WebCore/page/EditorClient.h b/Source/WebCore/page/EditorClient.h
+index f8a2106..451bbd4 100644
+--- a/Source/WebCore/page/EditorClient.h
++++ b/Source/WebCore/page/EditorClient.h
+@@ -65,7 +65,6 @@ class EditorClient {
+ public:
+     virtual ~EditorClient() {  }
+     virtual void pageDestroyed() = 0;
+-    virtual void frameWillDetachPage(Frame*) = 0;
+ 
+     virtual bool shouldDeleteRange(Range*) = 0;
+     virtual bool shouldShowDeleteInterface(HTMLElement*) = 0;
+diff --git a/Source/WebKit/gtk/WebCoreSupport/EditorClientGtk.h b/Source/WebKit/gtk/WebCoreSupport/EditorClientGtk.h
+index 0ff9278..2533c16 100644
+--- a/Source/WebKit/gtk/WebCoreSupport/EditorClientGtk.h
++++ b/Source/WebKit/gtk/WebCoreSupport/EditorClientGtk.h
+@@ -76,7 +76,6 @@ class EditorClient : public WebCore::EditorClient {
+ 
+         // from EditorClient
+         virtual void pageDestroyed();
+-        virtual void frameWillDetachPage(WebCore::Frame*) { }
+ 
+         virtual bool shouldDeleteRange(WebCore::Range*);
+         virtual bool shouldShowDeleteInterface(WebCore::HTMLElement*);
+diff --git a/Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h b/Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h
+index 20818ff..b82d1ef 100644
+--- a/Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h
++++ b/Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h
+@@ -42,7 +42,6 @@ public:
+ 
+ private:
+     virtual void pageDestroyed() OVERRIDE;
+-    virtual void frameWillDetachPage(WebCore::Frame*) OVERRIDE { }
+ 
+     virtual bool shouldDeleteRange(WebCore::Range*) OVERRIDE;
+     virtual bool shouldShowDeleteInterface(WebCore::HTMLElement*) OVERRIDE;
+-- 
+2.5.1
+
diff --git a/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb b/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
index b9a9d7a..7142dd3 100644
--- a/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
+++ b/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
@@ -30,6 +30,7 @@ SRC_URI = "\
   file://0001-Enable-mips64-build.patch \
   file://aarch64.patch \
   file://webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch \
+  file://0001-Remove-override-of-FrameDestructionObserver-willDeta.patch \
  "
 
 SRC_URI[md5sum] = "dcbf9d5e2e6391f857c29a57528b32a6"
-- 
2.5.1

[PATCH 15/16] mdadm: Fix bugs exposed by clang

[Khem Raj]

clang points to coding errors which otherwise go unnoticed

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../mdadm/files/0001-Fix-typo-in-comparision.patch | 86 ++++++++++++++++++++++
 meta/recipes-extended/mdadm/mdadm_3.3.4.bb         |  1 +
 2 files changed, 87 insertions(+)
 create mode 100644 meta/recipes-extended/mdadm/files/0001-Fix-typo-in-comparision.patch

diff --git a/meta/recipes-extended/mdadm/files/0001-Fix-typo-in-comparision.patch b/meta/recipes-extended/mdadm/files/0001-Fix-typo-in-comparision.patch
new file mode 100644
index 0000000..df70b1c
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/0001-Fix-typo-in-comparision.patch
@@ -0,0 +1,86 @@
+From 18d360d74271a066a849bc1fba4f10dbb23ed251 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Tue, 8 Sep 2015 08:17:42 +0000
+Subject: [PATCH] Fix typo in comparision
+
+error: comparison of array 'devnm' equal to a null pointer is always false
+
+User bitwise '&' operator as it is a mask
+
+Fixes
+error: use of logical '&&' with constant operand
+
+Remove extraneous parens
+
+error: equality comparison with extraneous parentheses
+
+Remove dead code
+
+restripe.c:465:21: error: explicitly assigning value of variable of type 'int' to itself
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ mdmon.h       | 2 +-
+ mdopen.c      | 2 +-
+ restripe.c    | 3 ---
+ super-intel.c | 2 +-
+ 4 files changed, 3 insertions(+), 6 deletions(-)
+
+diff --git a/mdmon.h b/mdmon.h
+index aa750c6..0b08c3d 100644
+--- a/mdmon.h
++++ b/mdmon.h
+@@ -101,7 +101,7 @@ static inline int is_resync_complete(struct mdinfo *array)
+ 		break;
+ 	case 10:
+ 		l = array->array.layout;
+-		ncopies = (l & 0xff) * ((l >> 8) && 0xff);
++		ncopies = (l & 0xff) * ((l >> 8) & 0xff);
+ 		sync_size = array->component_size * array->array.raid_disks;
+ 		sync_size /= ncopies;
+ 		break;
+diff --git a/mdopen.c b/mdopen.c
+index 28410f4..c5ee2a6 100644
+--- a/mdopen.c
++++ b/mdopen.c
+@@ -318,7 +318,7 @@ int create_mddev(char *dev, char *name, int autof, int trustworthy,
+ 	else if (num < 0) {
+ 		/* need to choose a free number. */
+ 		char *_devnm = find_free_devnm(use_mdp);
+-		if (devnm == NULL) {
++		if (_devnm == NULL) {
+ 			pr_err("No avail md devices - aborting\n");
+ 			return -1;
+ 		}
+diff --git a/restripe.c b/restripe.c
+index 4d92190..cfe9666 100644
+--- a/restripe.c
++++ b/restripe.c
+@@ -461,9 +461,6 @@ int raid6_check_disks(int data_disks, int start, int chunk_size,
+ 			curr_broken_disk = diskD;
+ 		}
+ 
+-		if((Px == 0) && (Qx == 0))
+-			curr_broken_disk = curr_broken_disk;
+-
+ 		if(curr_broken_disk >= data_disks + 2)
+ 			broken_status = 2;
+ 
+diff --git a/super-intel.c b/super-intel.c
+index 3f812d6..1838012 100644
+--- a/super-intel.c
++++ b/super-intel.c
+@@ -10027,7 +10027,7 @@ enum imsm_reshape_type imsm_analyze_change(struct supertype *st,
+ 				geo->size = max_size;
+ 		}
+ 
+-		if ((direction == ROLLBACK_METADATA_CHANGES)) {
++		if (direction == ROLLBACK_METADATA_CHANGES) {
+ 			/* accept size for rollback only
+ 			*/
+ 		} else {
+-- 
+2.5.1
+
diff --git a/meta/recipes-extended/mdadm/mdadm_3.3.4.bb b/meta/recipes-extended/mdadm/mdadm_3.3.4.bb
index 460a430..1198167 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.3.4.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.3.4.bb
@@ -12,6 +12,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
            file://mdadm-3.2.2_fix_for_x32.patch \
            file://gcc-4.9.patch \
            file://mdadm-3.3.2_x32_abi_time_t.patch \
+           file://0001-Fix-typo-in-comparision.patch \
            file://run-ptest \
 	  "
 SRC_URI[md5sum] = "7ca8b114710f98f53f20c5787b674a09"
-- 
2.5.1

[PATCH 16/16] directfb: Avoid using VLAs and printf formats

[Khem Raj]

These are not portable features and are flagged by clang

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-graphics/directfb/directfb.inc        |  4 +-
 ...direct-Aboid-usng-VLAs-and-printf-formats.patch | 61 ++++++++++++++++++++++
 2 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-graphics/directfb/directfb/0001-gfx-direct-Aboid-usng-VLAs-and-printf-formats.patch

diff --git a/meta/recipes-graphics/directfb/directfb.inc b/meta/recipes-graphics/directfb/directfb.inc
index 4fbca87..446aaea 100644
--- a/meta/recipes-graphics/directfb/directfb.inc
+++ b/meta/recipes-graphics/directfb/directfb.inc
@@ -14,7 +14,9 @@ DEPENDS = "jpeg libpng freetype zlib tslib sysfsutils"
 SRC_URI = "http://www.directfb.org/downloads/Core/DirectFB-1.7/DirectFB-${PV}.tar.gz \
            file://configurefix.patch \
            file://fusion.patch \
-           file://bashism.patch"
+           file://bashism.patch \
+           file://0001-gfx-direct-Aboid-usng-VLAs-and-printf-formats.patch \
+          "
 
 S = "${WORKDIR}/DirectFB-${PV}"
 
diff --git a/meta/recipes-graphics/directfb/directfb/0001-gfx-direct-Aboid-usng-VLAs-and-printf-formats.patch b/meta/recipes-graphics/directfb/directfb/0001-gfx-direct-Aboid-usng-VLAs-and-printf-formats.patch
new file mode 100644
index 0000000..76e0f75
--- /dev/null
+++ b/meta/recipes-graphics/directfb/directfb/0001-gfx-direct-Aboid-usng-VLAs-and-printf-formats.patch
@@ -0,0 +1,61 @@
+From f43ef44806ffb8e3b35d99070dde9b6cc1714d3d Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Tue, 8 Sep 2015 21:32:20 +0000
+Subject: [PATCH] gfx,direct: Aboid usng VLAs and printf formats
+
+VLAs are flagged by clang when using non-POD types, therefore replace
+the usage with alloca which is exact same allocation on stack
+
+ __attribute__((__format__ (__printf__))) is not portable as used here
+ therefore disable the check for clang here, we lose no functionality
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+Upstream-Status: Pending
+
+ lib/direct/util.h | 2 +-
+ src/gfx/util.cpp  | 8 ++++----
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/lib/direct/util.h b/lib/direct/util.h
+index 72941e9..8e7fa4a 100644
+--- a/lib/direct/util.h
++++ b/lib/direct/util.h
+@@ -98,7 +98,7 @@
+ #define D_CONST_FUNC
+ #endif
+ 
+-#if __GNUC__ >= 3
++#if __GNUC__ >= 3 && !defined __clang__
+ #define D_FORMAT_PRINTF(n)         __attribute__((__format__ (__printf__, n, n+1)))
+ #define D_FORMAT_VPRINTF(n)        __attribute__((__format__ (__printf__, n, 0)))
+ #else
+diff --git a/src/gfx/util.cpp b/src/gfx/util.cpp
+index 40032bc..d1015d4 100644
+--- a/src/gfx/util.cpp
++++ b/src/gfx/util.cpp
+@@ -294,8 +294,8 @@ dfb_gfx_copy_regions_stereo( CoreSurface           *source,
+ {
+      unsigned int i, n = 0;
+      DFBRectangle rect = { 0, 0, source->config.size.w, source->config.size.h };
+-     DFBRectangle rects[num];
+-     DFBPoint     points[num];
++     DFBRectangle *rects =  (DFBRectangle*)alloca( sizeof(struct DFBRectangle) * num);
++     DFBPoint *points =  (DFBPoint*)alloca( sizeof(struct DFBPoint) * num);
+ 
+      for (i=0; i<num; i++) {
+           DFB_REGION_ASSERT( &regions[i] );
+@@ -351,8 +351,8 @@ dfb_gfx_copy_regions_client( CoreSurface             *source,
+ {
+      unsigned int             i, n = 0;
+      DFBRectangle             rect = { 0, 0, source->config.size.w, source->config.size.h };
+-     DFBRectangle             rects[num];
+-     DFBPoint                 points[num];
++     DFBRectangle            *rects =  (DFBRectangle*)alloca( sizeof(struct DFBRectangle) * num);
++     DFBPoint                *points =  (DFBPoint*)alloca( sizeof(struct DFBPoint) * num);
+      CoreGraphicsStateClient *client = _client ? _client : &StateClient::Get()->client;
+      CardState               *state  = client->state;
+      CardState                backup;
+-- 
+2.5.1
+
-- 
2.5.1

Re: [PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Nicolas Dechesne]

On Wed, Sep 9, 2015 at 1:07 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>  ...put_dpms-Replace-logical-with-bitwise-ope.patch | 31 ++++++++++++++++++++++
>  .../xorg-driver/xf86-video-omap_0.4.3.bb           |  2 ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch
>
> diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch b/meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch
> new file mode 100644
> index 0000000..41e77d3
> --- /dev/null
> +++ b/meta/recipes-graphics/xorg-driver/xf86-video-omap/0001-drmmode_output_dpms-Replace-logical-with-bitwise-ope.patch
> @@ -0,0 +1,31 @@
> +From fc653ca3b36435aea281ae409fb90f85e1bc0d81 Mon Sep 17 00:00:00 2001
> +From: Khem Raj <raj.khem@gmail.com>
> +Date: Mon, 7 Sep 2015 08:44:13 +0000
> +Subject: [freedreno][PATCH] drmmode_output_dpms: Replace logical && with bitwise &
> + operation

why are you adding a patch sent to freedreno mailing list (so I would
assume against xf86-video-freedreno), in the xf86-video-omap recipe,
is that a typo?

Re: [PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]


> On Sep 9, 2015, at 12:44 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> 
> 
> why are you adding a patch sent to freedreno mailing list (so I would
> assume against xf86-video-freedreno), in the xf86-video-omap recipe,
> is that a typo?

thats where it was sent to. since thats the same list omap driver is using as well.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Nicolas Dechesne]

On Wed, Sep 9, 2015 at 9:52 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> why are you adding a patch sent to freedreno mailing list (so I would
>> assume against xf86-video-freedreno), in the xf86-video-omap recipe,
>> is that a typo?
>
> thats where it was sent to. since thats the same list omap driver is using as well.
>
>

hmm. really? I can't find any info about that. how did you figure this out?

Note: I saw your patch on the freedreno ML, and actually the patch
also exists on the -freedreno driver as well... probably that file was
just copy/pasted.. in any case, from your email sent to freedreno it's
not obvious at all that you are targeting -omap driver. so if you can
confirm that -omap patches need to be sent on the freedreno list, then
at least you might want to resend with [omap] in subject to avoid
confusion..  I will test/submit the same patch for -freedreno on my
side.

Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[alexander.kanavin]

> +Exposed while compiling on musl
> +
> +Signed-off-by: Khem Raj <raj.khem@gmail.com>
> +---
> +Upstream-Status: Pending

If this has been submitted upstream (as you say in the cover letter for
this patchset), please provide a link for the submission in the
upstream-status. We can't afford to let the amount of 'Pending' patches in
oe-core grow indefinitely.

Same goes for other patches in this set.

Regards,
Alex

Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[alexander.kanavin]

>> +Exposed while compiling on musl
>> +
>> +Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> +---
>> +Upstream-Status: Pending
>
> If this has been submitted upstream (as you say in the cover letter for
> this patchset), please provide a link for the submission in the
> upstream-status. We can't afford to let the amount of 'Pending' patches in
> oe-core grow indefinitely.
>
> Same goes for other patches in this set.


Actually scratch the above, it was too hasty. What I really wanted to say
is that, ideally, you should first submit the patches upstream, have a
prooflink of that, and only then send them here with that proof in the
upstream-status. There are already too many eternal 'Pending' patches in
oe-core that never made it to upsream. We can't afford more of them.

Regards,
Alex

Re: [PATCH 14/16] webkit-gtk: Backport fix to remove FrameDestructionObserver

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On 9 September 2015 at 00:07, Khem Raj <raj.khem@gmail.com> wrote:

> This helps clang compile webkit without problems. This is a backport
> from upstream
>

MUT has an upgrade to webkitgtk 2.8.5, would this version have this fix
integrated?

Ross

[-- Attachment #2: Type: text/html, Size: 664 bytes --]

Re: [PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Nicolas Dechesne]

On Wed, Sep 9, 2015 at 10:07 AM, Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:
> On Wed, Sep 9, 2015 at 9:52 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> why are you adding a patch sent to freedreno mailing list (so I would
>>> assume against xf86-video-freedreno), in the xf86-video-omap recipe,
>>> is that a typo?
>>
>> thats where it was sent to. since thats the same list omap driver is using as well.
>>
>>
>
> hmm. really? I can't find any info about that. how did you figure this out?
>
> Note: I saw your patch on the freedreno ML, and actually the patch
> also exists on the -freedreno driver as well... probably that file was
> just copy/pasted.. in any case, from your email sent to freedreno it's
> not obvious at all that you are targeting -omap driver. so if you can
> confirm that -omap patches need to be sent on the freedreno list, then
> at least you might want to resend with [omap] in subject to avoid
> confusion..  I will test/submit the same patch for -freedreno on my
> side.

i talked to Rob, he merged the patch in both -omap and -freedreno. 2
for the price of 1..

nico

Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]


> On Sep 9, 2015, at 3:23 AM, alexander.kanavin@linux.intel.com wrote:
> 
>>> +Exposed while compiling on musl
>>> +
>>> +Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>> +---
>>> +Upstream-Status: Pending
>> 
>> If this has been submitted upstream (as you say in the cover letter for
>> this patchset), please provide a link for the submission in the
>> upstream-status. We can't afford to let the amount of 'Pending' patches in
>> oe-core grow indefinitely.
>> 
>> Same goes for other patches in this set.
> 
> 
> Actually scratch the above, it was too hasty. What I really wanted to say
> is that, ideally, you should first submit the patches upstream, have a
> prooflink of that, and only then send them here with that proof in the
> upstream-status. There are already too many eternal 'Pending' patches in
> oe-core that never made it to upsream. We can't afford more of them.

There is process for that. The upstreaming of a patch is an independent thing thats why pending status
is agreed upon probably it predates you in OE contributor's community.
since it deals with different community, and usually we carry a patch for a release or two
and then it gets merged or redone and we drop it. Many a times with recipe upgrades you will
see patches get dropped for these reasons. As integrators, the engagement of rule is a bit different for us. since every component community has its own interworking and nature, this way we make progress while upstreaming takes its own course. This process is followed by all major distro’s as well including OE.
Now if we want to step ahead and change a policy to first submit patch upstream then it will be accepted in OE
thats a fine idea, however that requires a wider discussion community wide and also needs tools to reject
patches with out upstream submission. It also has downside where a distro developer may not participate upstream
and hence with not enough momentum things will stall and people may prefer to carry own forks, so we have
to make it less burdensome. We can not go by grey area where we say this patch should be first submitted upstream and this we can accept without submission since that will put extra burden on maintainers of OE for deciding on code thats they may not be experts in.

So I encourage you to formulate a policy and make a proposal to community and get everyone on board in changing
the policy OE wide.

Cheers
-Khem


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]


> On Sep 9, 2015, at 1:07 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> 
> On Wed, Sep 9, 2015 at 9:52 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> why are you adding a patch sent to freedreno mailing list (so I would
>>> assume against xf86-video-freedreno), in the xf86-video-omap recipe,
>>> is that a typo?
>> 
>> thats where it was sent to. since thats the same list omap driver is using as well.
>> 
>> 
> 
> hmm. really? I can't find any info about that. how did you figure this out?

well I wanted to get Rob’s attention doesnt matter which mailing list goes :)

> 
> Note: I saw your patch on the freedreno ML, and actually the patch
> also exists on the -freedreno driver as well... probably that file was
> just copy/pasted.. in any case, from your email sent to freedreno it's
> not obvious at all that you are targeting -omap driver. so if you can
> confirm that -omap patches need to be sent on the freedreno list, then
> at least you might want to resend with [omap] in subject to avoid
> confusion..  I will test/submit the same patch for -freedreno on my
> side.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 11/16] xorg-driver: Fix logical && with bitwise and operation

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]


> On Sep 9, 2015, at 9:00 AM, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> 
> On Wed, Sep 9, 2015 at 10:07 AM, Nicolas Dechesne
> <nicolas.dechesne@linaro.org> wrote:
>> On Wed, Sep 9, 2015 at 9:52 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> why are you adding a patch sent to freedreno mailing list (so I would
>>>> assume against xf86-video-freedreno), in the xf86-video-omap recipe,
>>>> is that a typo?
>>> 
>>> thats where it was sent to. since thats the same list omap driver is using as well.
>>> 
>>> 
>> 
>> hmm. really? I can't find any info about that. how did you figure this out?
>> 
>> Note: I saw your patch on the freedreno ML, and actually the patch
>> also exists on the -freedreno driver as well... probably that file was
>> just copy/pasted.. in any case, from your email sent to freedreno it's
>> not obvious at all that you are targeting -omap driver. so if you can
>> confirm that -omap patches need to be sent on the freedreno list, then
>> at least you might want to resend with [omap] in subject to avoid
>> confusion..  I will test/submit the same patch for -freedreno on my
>> side.
> 
> i talked to Rob, he merged the patch in both -omap and -freedreno. 2
> for the price of 1..

ah there we go as hoped :)

> 
> nico


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 14/16] webkit-gtk: Backport fix to remove FrameDestructionObserver

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 506 bytes --]

Hi Ross

> On Sep 9, 2015, at 6:04 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 9 September 2015 at 00:07, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> This helps clang compile webkit without problems. This is a backport
> from upstream
> 
> MUT has an upgrade to webkitgtk 2.8.5, would this version have this fix integrated?
> 

yes its been fixed in 2.8.x. point me to MUT commit I can cherry-pick locally here and try it out to make it sure.

> Ross


[-- Attachment #1.2: Type: text/html, Size: 1535 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 14/16] webkit-gtk: Backport fix to remove FrameDestructionObserver

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On 9 September 2015 at 20:28, Khem Raj <raj.khem@gmail.com> wrote:

> yes its been fixed in 2.8.x. point me to MUT commit I can cherry-pick
> locally here and try it out to make it sure.
>

The webkitgtk upgrade is poky-contrib:ross/mut (a01c056).

Ross

[-- Attachment #2: Type: text/html, Size: 676 bytes --]

Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Alexander Kanavin]

On 09/09/2015 07:02 PM, Khem Raj wrote:

> So I encourage you to formulate a policy and make a proposal to community and get everyone on board in changing
> the policy OE wide.


Actually, first we need some kind of tool that keeps track of custom 
patches and their upstream-statuses and minimizes the amount of manual 
work.

Then we can formulate a policy on top of that: for example, if a patch 
has been 'Pending' for 3 months, the person who added it gets a reminder 
to update the status; if the patch has been 'Pending' for 6 months and 
the patch person has been unresponsive, no more patches are accepted 
from that person until he does the upstreaming of the ones he already 
got into oe-core. Something like that.

Regards,
Alex

Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Trevor Woerner]

On 09/10/15 07:21, Alexander Kanavin wrote:
> On 09/09/2015 07:02 PM, Khem Raj wrote:
>
>> So I encourage you to formulate a policy and make a proposal to
>> community and get everyone on board in changing
>> the policy OE wide.
>
>
> Actually, first we need some kind of tool that keeps track of custom
> patches and their upstream-statuses and minimizes the amount of manual
> work.
>
> Then we can formulate a policy on top of that: for example, if a patch
> has been 'Pending' for 3 months, the person who added it gets a
> reminder to update the status; if the patch has been 'Pending' for 6
> months and the patch person has been unresponsive, no more patches are
> accepted from that person until he does the upstreaming of the ones he
> already got into oe-core. Something like that.

With so many maintainers on so many different layers/etc we would need
some sort of billboard somewhere listing the names of people currently
on the "naughty" list ;-)

Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On 10 September 2015 at 12:50, Trevor Woerner <twoerner@gmail.com> wrote:

> With so many maintainers on so many different layers/etc we would need
> some sort of billboard somewhere listing the names of people currently
> on the "naughty" list ;-)
>

I prefer the concept of a naughty list to blanket rejecting...  and I have
a script for internal tracking this sort of metric so when I have a spare
hour I'll see if I can extend to do this.   "pending" lines added per
person or something.

Ross

[-- Attachment #2: Type: text/html, Size: 939 bytes --]

Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[Alexander Kanavin]

On 09/10/2015 02:50 PM, Trevor Woerner wrote:

>> Then we can formulate a policy on top of that: for example, if a patch
>> has been 'Pending' for 3 months, the person who added it gets a
>> reminder to update the status; if the patch has been 'Pending' for 6
>> months and the patch person has been unresponsive, no more patches are
>> accepted from that person until he does the upstreaming of the ones he
>> already got into oe-core. Something like that.
>
> With so many maintainers on so many different layers/etc we would need
> some sort of billboard somewhere listing the names of people currently
> on the "naughty" list ;-)

Yes, something similar to http://recipes.yoctoproject.org

And the autobuilder could automatically reject or flag a patch that adds 
custom 'Pending' patches, if the patch author is determined to be on the 
'naughty' list :-)


Alex

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[Gary Thomas]

On 2015-09-10 06:08, Alexander Kanavin wrote:
> On 09/10/2015 02:50 PM, Trevor Woerner wrote:
>
>>> Then we can formulate a policy on top of that: for example, if a patch
>>> has been 'Pending' for 3 months, the person who added it gets a
>>> reminder to update the status; if the patch has been 'Pending' for 6
>>> months and the patch person has been unresponsive, no more patches are
>>> accepted from that person until he does the upstreaming of the ones he
>>> already got into oe-core. Something like that.
>>
>> With so many maintainers on so many different layers/etc we would need
>> some sort of billboard somewhere listing the names of people currently
>> on the "naughty" list ;-)
>
> Yes, something similar to http://recipes.yoctoproject.org
>
> And the autobuilder could automatically reject or flag a patch that adds custom 'Pending' patches, if the patch author is determined to be on the 'naughty' list :-)

What would you do to the poor sod that sends a patch upstream
(i.e. Pending) that is not being moved on by the upstream holders?
Punish him by making his patch (and potentially all others he
has created) invalid?  Seems a bit harsh...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

On 10 September 2015 at 13:12, Gary Thomas <gary@mlbassoc.com> wrote:

> What would you do to the poor sod that sends a patch upstream
> (i.e. Pending) that is not being moved on by the upstream holders?
> Punish him by making his patch (and potentially all others he
> has created) invalid?  Seems a bit harsh...
>

Send upstream is Upstream-Status: Submitted.

Pending means "I wrote a patch but cannot be bothered to send it upstream".

Ross

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[Gary Thomas]

On 2015-09-10 06:12, Burton, Ross wrote:
>
> On 10 September 2015 at 13:12, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     What would you do to the poor sod that sends a patch upstream
>     (i.e. Pending) that is not being moved on by the upstream holders?
>     Punish him by making his patch (and potentially all others he
>     has created) invalid?  Seems a bit harsh...
>
>
> Send upstream is Upstream-Status: Submitted.
>
> Pending means "I wrote a patch but cannot be bothered to send it upstream".

Fair enough, that's a different case which does seem to warrant this treatment.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]


> On Sep 10, 2015, at 5:12 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 10 September 2015 at 13:12, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
> What would you do to the poor sod that sends a patch upstream
> (i.e. Pending) that is not being moved on by the upstream holders?
> Punish him by making his patch (and potentially all others he
> has created) invalid?  Seems a bit harsh...
> 
> Send upstream is Upstream-Status: Submitted.
> 
> Pending means "I wrote a patch but cannot be bothered to send it upstream”.

Or more politely, I am working on upstreaming it on my own schedule.

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


[-- Attachment #2: Type: text/html, Size: 2128 bytes --]

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[akuster808]

On 09/10/2015 05:08 AM, Alexander Kanavin wrote:
> On 09/10/2015 02:50 PM, Trevor Woerner wrote:
> 
>>> Then we can formulate a policy on top of that: for example, if a patch
>>> has been 'Pending' for 3 months, the person who added it gets a
>>> reminder to update the status; if the patch has been 'Pending' for 6
>>> months and the patch person has been unresponsive, no more patches are
>>> accepted from that person until he does the upstreaming of the ones he
>>> already got into oe-core. Something like that.
>>
>> With so many maintainers on so many different layers/etc we would need
>> some sort of billboard somewhere listing the names of people currently
>> on the "naughty" list ;-)
> 
> Yes, something similar to http://recipes.yoctoproject.org
> 
> And the autobuilder could automatically reject or flag a patch that adds
> custom 'Pending' patches, if the patch author is determined to be on the
> 'naughty' list :-)

That might just alter peoples behavior and change them to use
"Submitted" and still not do anything. It does not address the issue.

Having the ability to report a patch's status does have some merit. What
is done with it is a different story.

- armin

> 
> 
> Alex

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[alexander.kanavin]

>> Pending means "I wrote a patch but cannot be bothered to send it
>> upstream”.
>
> Or more politely, I am working on upstreaming it on my own schedule.

Allowing "own schedule" doesn't work out in reality. Here's how many
'Pending' patches the yocto releases have:

master: 712
fido: 681
dizzy: 683
daisy: 598
dora: 611
dylan: 555
danny: 548
denzil: 518
edison: 426

There should be measures to keep this number from growing indefinitely.

Regards,
Alex

Re: Policy for 'Pending' patches (was Re: [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close)

[alexander.kanavin]

>> And the autobuilder could automatically reject or flag a patch that adds
>> custom 'Pending' patches, if the patch author is determined to be on the
>> 'naughty' list :-)
>
> That might just alter peoples behavior and change them to use
> "Submitted" and still not do anything. It does not address the issue.

Of course 'Submitted' must include a proof link of the submission, or a
notice that the only way to submit upstream is by private email (which is
very rare). Such link is necessary anyway to follow up later what happened
with the submission.

Regards,
Alex