Re: [OE-core] EXT: Re: [PATCH 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Jose Alarcon]

On 02.09.2017 14:46, Richard Purdie wrote:
> On Sat, 2017-08-26 at 14:26 +0300, Jose Alarcon wrote:
>> The do_rootfs log contains a number of unsatisfied package
>> recommendations. At the moment those are only visible when
>> reviewing the rootfs log.
>>
>> This patch adds an extra check to surface any unsatisfied
>> recommendation  as WARNINGS to the build output when
>> "debug-tweaks" is enabled.
>>
>> Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
>> ---
>>  meta/classes/rootfs-postcommands.bbclass | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/meta/classes/rootfs-postcommands.bbclass
>> b/meta/classes/rootfs-postcommands.bbclass
>> index fb36bad..e7ef382 100644
>> --- a/meta/classes/rootfs-postcommands.bbclass
>> +++ b/meta/classes/rootfs-postcommands.bbclass
>> @@ -50,6 +50,9 @@ python () {
>>  d.appendVar('ROOTFS_POSTPROCESS_COMMAND',
>> '${SORT_PASSWD_POSTPROCESS_COMMAND}')
>>  }
>>  
>> +# Enable QA check for unsatisfied recommendations if debug-tweaks is
>> enabled
>> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATU
>> RES", "debug-tweaks", "rootfs_log_check_recommends; ", "",d)}'
>> +
>>  systemd_create_users () {
>>  for conffile in
>> ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf
>> ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
>>  [ -e $conffile ] || continue
> Can we just drop the above piece please? I think its fine for the user
> to enable this with:
>
> ROOTFS_POSTPROCESS_COMMAND += "rootfs_log_check_recommends"
>
> We're trying to kill off debug-tweaks as nobody can tell what it does
> from the name.

Thanks for your feedback! v2 sent.

Cheers,

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

[OE-core] [PATCH v2 1/2] rootfs-postcommands: remove empty line

[Jose Alarcon]

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 meta/classes/rootfs-postcommands.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index e7999d4..fb36bad 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -291,7 +291,6 @@ rootfs_sysroot_relativelinks () {
sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
 }
 
-
 # Generated test data json file
 python write_image_test_data() {
 from oe.data import export2json
-- 
2.10.1

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

[OE-core] [PATCH v2 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Jose Alarcon]

The do_rootfs log contains a number of unsatisfied package
recommendations. At the moment those are only visible when
reviewing the rootfs log.

This patch adds an extra check to surface any unsatisfied
recommendation  as WARNINGS to the build output.

Enable this check with:
ROOTFS_POSTPROCESS_COMMAND += "rootfs_log_check_recommends;"

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 meta/classes/rootfs-postcommands.bbclass | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index fb36bad..f6d31a0 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -307,3 +307,15 @@ python write_image_test_data() {
os.remove(testdata_link)
 os.symlink(os.path.basename(testdata), testdata_link)
 }
+
+# Check for unsatisfied recommendations (RRECOMMENDS)
+python rootfs_log_check_recommends() {
+log_path = d.expand("${T}/log.do_rootfs")
+with open(log_path, 'r') as log:
+for line in log:
+if 'log_check' in line:
+continue
+
+if 'unsatisfied recommendation for' in line:
+bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
+}
-- 
2.10.1

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

Re: [OE-core] EXT: Re: [PATCH 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Jose Alarcon]

On 02.09.2017 03:22, Burton, Ross wrote:
> On 26 August 2017 at 12:26, Jose Alarcon <jose.alar...@ge.com
> <mailto:jose.alar...@ge.com>> wrote:
>
> The do_rootfs log contains a number of unsatisfied package
> recommendations. At the moment those are only visible when
> reviewing the rootfs log.
>
> This patch adds an extra check to surface any unsatisfied
> recommendation  as WARNINGS to the build output when
> "debug-tweaks" is enabled.
>
>
> But isn't that the point of recommends?
>
> If the user uses BAD_RECOMMENDATIONS to explicitly stop specific
> recommendations being installed, or the package just isn't available,
> that's fine.

Yes. The purpose of this patch is to surface those unsatisfied
recommends. The user then can decide whether to use BAD_RECOMMENDATIONS,
satisfy the recommend if it is something he needs or just ignore them.

Thanks,

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

Re: [OE-core] [PATCH 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Jose Alarcon]

On 26.08.2017 14:26, Jose Alarcon wrote:
> The do_rootfs log contains a number of unsatisfied package
> recommendations. At the moment those are only visible when
> reviewing the rootfs log.
>
> This patch adds an extra check to surface any unsatisfied
> recommendation  as WARNINGS to the build output when
> "debug-tweaks" is enabled.
>
> Signed-off-by: Jose Alarcon <jose.alar...@ge.com>

Hello,

Gentle reminder, has anyone have a chance to review this patch?

Thanks,

--
Jose Alarcon

> ---
>  meta/classes/rootfs-postcommands.bbclass | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/meta/classes/rootfs-postcommands.bbclass 
> b/meta/classes/rootfs-postcommands.bbclass
> index fb36bad..e7ef382 100644
> --- a/meta/classes/rootfs-postcommands.bbclass
> +++ b/meta/classes/rootfs-postcommands.bbclass
> @@ -50,6 +50,9 @@ python () {
>  d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 
> '${SORT_PASSWD_POSTPROCESS_COMMAND}')
>  }
>  
> +# Enable QA check for unsatisfied recommendations if debug-tweaks is enabled
> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", 
> "debug-tweaks", "rootfs_log_check_recommends; ", "",d)}'
> +
>  systemd_create_users () {
>   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
> ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
>   [ -e $conffile ] || continue
> @@ -307,3 +310,15 @@ python write_image_test_data() {
> os.remove(testdata_link)
>  os.symlink(os.path.basename(testdata), testdata_link)
>  }
> +
> +# Check for unsatisfied recommendations (RRECOMMENDS)
> +python rootfs_log_check_recommends() {
> +log_path = d.expand("${T}/log.do_rootfs")
> +with open(log_path, 'r') as log:
> +for line in log:
> +if 'log_check' in line:
> +continue
> +
> +if 'unsatisfied recommendation for' in line:
> +bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
> +}

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

Re: [OE-core] EXT: Re: [PATCH resend] meta/classes: add class to test for unsatisfied RRECOMMENDS

[Jose Alarcon]

On 26.08.2017 14:27, Jose Alarcon wrote:
>
> On 25.08.2017 15:29, Richard Purdie wrote:
>> On Fri, 2017-08-25 at 09:43 +0300, Jose Alarcon wrote:
>>> The do_rootfs log contains a number of unsatisfied package
>>> recommendations. At the moment those are only visible when
>>> reviewing the rootfs log.
>>>
>>> This class adds an extra check to surface any unsatisfied
>>> recommendation  as WARNINGS to the build output.
>>>
>>> Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
>>> ---
>>>  meta/classes/rootfs-check-recommends.bbclass | 21
>>> +
>>>  1 file changed, 21 insertions(+)
>>>  create mode 100644 meta/classes/rootfs-check-recommends.bbclass
>> This looks like it would be a better fit for rootfs-
>> postcommands.bbclass?
> Thanks. I sent a new patch with this check done in rootfs-postcommands
> class.

New patch with the check done in rootfs-postcommands here:
https://patchwork.openembedded.org/series/8521/#

The reason why I implemented this as a class in the first place was that
we don't want to modify upstream layers and there is no way to append a
bbclass.
So I created a new class in our own layer instead. But for upstreaming
it is true that rootfs-postcommands is a better fit.

Thanks,

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

Re: [OE-core] EXT: Re: [PATCH resend] meta/classes: add class to test for unsatisfied RRECOMMENDS

[Jose Alarcon]

On 25.08.2017 15:29, Richard Purdie wrote:
> On Fri, 2017-08-25 at 09:43 +0300, Jose Alarcon wrote:
>> The do_rootfs log contains a number of unsatisfied package
>> recommendations. At the moment those are only visible when
>> reviewing the rootfs log.
>>
>> This class adds an extra check to surface any unsatisfied
>> recommendation  as WARNINGS to the build output.
>>
>> Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
>> ---
>>  meta/classes/rootfs-check-recommends.bbclass | 21
>> +
>>  1 file changed, 21 insertions(+)
>>  create mode 100644 meta/classes/rootfs-check-recommends.bbclass
> This looks like it would be a better fit for rootfs-
> postcommands.bbclass?

Thanks. I sent a new patch with this check done in rootfs-postcommands
class.

Cheers,

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

[OE-core] [PATCH 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Jose Alarcon]

The do_rootfs log contains a number of unsatisfied package
recommendations. At the moment those are only visible when
reviewing the rootfs log.

This patch adds an extra check to surface any unsatisfied
recommendation  as WARNINGS to the build output when
"debug-tweaks" is enabled.

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 meta/classes/rootfs-postcommands.bbclass | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index fb36bad..e7ef382 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -50,6 +50,9 @@ python () {
 d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 
'${SORT_PASSWD_POSTPROCESS_COMMAND}')
 }
 
+# Enable QA check for unsatisfied recommendations if debug-tweaks is enabled
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", 
"debug-tweaks", "rootfs_log_check_recommends; ", "",d)}'
+
 systemd_create_users () {
for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
[ -e $conffile ] || continue
@@ -307,3 +310,15 @@ python write_image_test_data() {
os.remove(testdata_link)
 os.symlink(os.path.basename(testdata), testdata_link)
 }
+
+# Check for unsatisfied recommendations (RRECOMMENDS)
+python rootfs_log_check_recommends() {
+log_path = d.expand("${T}/log.do_rootfs")
+with open(log_path, 'r') as log:
+for line in log:
+if 'log_check' in line:
+continue
+
+if 'unsatisfied recommendation for' in line:
+bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
+}
-- 
2.10.1

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

[OE-core] [PATCH 1/2] rootfs-postcommands: remove empty line

[Jose Alarcon]

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 meta/classes/rootfs-postcommands.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index e7999d4..fb36bad 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -291,7 +291,6 @@ rootfs_sysroot_relativelinks () {
sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
 }
 
-
 # Generated test data json file
 python write_image_test_data() {
 from oe.data import export2json
-- 
2.10.1

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

[OE-core] [PATCH] Revert "libinput: remove obsolete touchpad patch"

[Jose Alarcon]

This reverts commit 9f32d9405ed5430e9e55de2f1562baac963e807c.

This patch is still needed since OLDEST_KERNEL is set to 3.2.0

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 ...ics-need-to-fake-new-touches-on-TRIPLETAP.patch | 72 ++
 meta/recipes-graphics/wayland/libinput_1.8.1.bb|  1 +
 2 files changed, 73 insertions(+)
 create mode 100644 
meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch

diff --git 
a/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
 
b/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
new file mode 100644
index 000..b52b496
--- /dev/null
+++ 
b/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
@@ -0,0 +1,72 @@
+This is a workaround upstream suggests for use with kernel 4.1.
+
+Upstream-Status: Inappropriate [temporary work-around]
+Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
+
+
+
+From: Peter Hutterer <peter.hutte...@who-t.net>
+Date: Mon Aug 3 18:23:12 PDT 2015
+Subject: [PATCH v3 libinput] touchpad: serial synaptics need to fake new 
touches on TRIPLETAP
+
+On the 4.1 kernels synaptics pretends to have 3 slots (the serial fw only does
+2). This was added to avoid cursor jumps but has since been reverted for 4.2
+(kernel commit dbf3c37086, 4.1.3 is still buggy). In some cases a TRIPLETAP
+may be triggered without slot 2 ever activating.
+
+While there are still those kernels out there, work around this bug by opening
+a new touch point where none exists if the fake finger count exceeds the slot
+count.
+
+Reported-by: Jan Alexander Steffens 
+Signed-off-by: Peter Hutterer 
+Tested-by: Jan Alexander Steffens 
+Reviewed-by: Hans de Goede 
+---
+Changes to v2:
+- split out the handling instead of having a tmp state variable, see Hans'
+  comments from v2
+
+Mainly sending this to the list again so I have a link to point people to.
+If you're on 4.1.x add this patch to your distribution package.
+
+ src/evdev-mt-touchpad.c | 22 --
+ 1 file changed, 16 insertions(+), 6 deletions(-)
+
+diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
+index a683d9a..5ef03d5 100644
+--- a/src/evdev-mt-touchpad.c
 b/src/evdev-mt-touchpad.c
+@@ -369,13 +369,23 @@ tp_restore_synaptics_touches(struct tp_dispatch *tp,
+   for (i = 0; i < tp->num_slots; i++) {
+   struct tp_touch *t = tp_get_touch(tp, i);
+ 
+-  if (t->state != TOUCH_END)
++  switch(t->state) {
++  case TOUCH_HOVERING:
++  case TOUCH_BEGIN:
++  case TOUCH_UPDATE:
+   continue;
+-
+-  /* new touch, move it through begin to update immediately */
+-  tp_new_touch(tp, t, time);
+-  tp_begin_touch(tp, t, time);
+-  t->state = TOUCH_UPDATE;
++  case TOUCH_NONE:
++  /* new touch, move it through to begin immediately */
++  tp_new_touch(tp, t, time);
++  tp_begin_touch(tp, t, time);
++  break;
++  case TOUCH_END:
++  /* touch just ended ,we need need to restore it to 
update */
++  tp_new_touch(tp, t, time);
++  tp_begin_touch(tp, t, time);
++  t->state = TOUCH_UPDATE;
++  break;
++  }
+   }
+ }
+ 
+-- 
+2.4.3
+
diff --git a/meta/recipes-graphics/wayland/libinput_1.8.1.bb 
b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
index a21babe..f75298b 100644
--- a/meta/recipes-graphics/wayland/libinput_1.8.1.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=2184aef38ff137ed33ce9a63b9d1eb8f"
 DEPENDS = "libevdev udev mtdev"
 
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
+   
file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
file://0001-tools-Fix-race-in-autotools-install.patch \
 "
 
-- 
2.10.1

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

Re: [OE-core] EXT: Re: [PATCH] libinput: remove obsolete touchpad patch

[Jose Alarcon]

On 25.08.2017 21:59, Martin Jansa wrote:
> Does the patch cause any harm when used on newer kernel?

Based on my limited testing on our devices running kernel 4.11.0, no.

>
> If so shouldn't the patch be fixed to work correctly even with newer
> kernel?
>
> Or what's the main reason to remove it?

I am going through each and every patch that we carry on our layers. If
upstreaming status is pending, we try to upstream it. If the patch is no
longer needed, we remove it.

When I came across this particular patch, I thought it was obsolete and
that it should be removed upstream too. I was not aware of OLDEST_KERNEL.

I will send a revert now.

Thanks,

--
Jose

>
> On Fri, Aug 25, 2017 at 8:55 PM, Mark Hatle <mark.ha...@windriver.com
> <mailto:mark.ha...@windriver.com>> wrote:
>
> On 8/25/17 1:48 PM, Andre McCurdy wrote:
> > On Fri, Aug 25, 2017 at 12:09 AM, Jose Alarcon
> <jose.alar...@ge.com <mailto:jose.alar...@ge.com>> wrote:
> >> On 24.08.2017 20 <tel:24.08.2017%2020>:45, Andre McCurdy wrote:
> >>> On Wed, Aug 23, 2017 at 10:37 PM, Jose Alarcon
> <jose.alar...@ge.com <mailto:jose.alar...@ge.com>> wrote:
> >>>> This patch was a temporal workaround needed with 4.1 kernels.
> >>>> Remove it.
> >>> OLDEST_KERNEL is still set to 3.2.0
> >>>
> >>> How can you be sure nobody is using 4.1 ?
> >>
> >> That's a good point!
> >>
> >> I didn't know about this variable. I believe we should not
> integrate
> >> this change.
> >> I will resend it once OLDEST_KERNEL is set to 4.2 or bigger.
> >
> > The original patch has been merged to master so a second patch
> will be
> > needed to revert it.
> >
>
> It may make sense to selectively apply the patch based on what
> OLDEST_KERNEL is
> set to.
>
> This way if a user or distribution sets a newer 'OLDEST_KERNEL',
> that item can
> be removed automatically.
>
> --Mark
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> <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] EXT: Re: [PATCH] libinput: remove obsolete touchpad patch

[Jose Alarcon]

On 24.08.2017 20:45, Andre McCurdy wrote:
> On Wed, Aug 23, 2017 at 10:37 PM, Jose Alarcon <jose.alar...@ge.com> wrote:
>> This patch was a temporal workaround needed with 4.1 kernels.
>> Remove it.
> OLDEST_KERNEL is still set to 3.2.0
>
> How can you be sure nobody is using 4.1 ?

That's a good point!

I didn't know about this variable. I believe we should not integrate
this change.
I will resend it once OLDEST_KERNEL is set to 4.2 or bigger.

Thanks,

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

[OE-core] [PATCH resend] meta/classes: add class to test for unsatisfied RRECOMMENDS

[Jose Alarcon]

The do_rootfs log contains a number of unsatisfied package
recommendations. At the moment those are only visible when
reviewing the rootfs log.

This class adds an extra check to surface any unsatisfied
recommendation  as WARNINGS to the build output.

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 meta/classes/rootfs-check-recommends.bbclass | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 meta/classes/rootfs-check-recommends.bbclass

diff --git a/meta/classes/rootfs-check-recommends.bbclass 
b/meta/classes/rootfs-check-recommends.bbclass
new file mode 100644
index 000..351e438
--- /dev/null
+++ b/meta/classes/rootfs-check-recommends.bbclass
@@ -0,0 +1,21 @@
+#
+# This bbclass adds an extra check to surface any unsatisfied
+# recommendation (RRECOMMENDS) as WARNINGS to the build output.
+#
+# To enable, use INHERIT in conf/distro/distro.conf:
+#
+#   INHERIT += "rootfs-check-recommends"
+#
+
+python log_check_recommends() {
+log_path = d.expand("${T}/log.do_rootfs")
+with open(log_path, 'r') as log:
+for line in log:
+if 'log_check' in line:
+continue
+
+if 'unsatisfied recommendation for' in line:
+bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
+}
+
+do_rootfs[postfuncs] += "log_check_recommends "
-- 
2.10.1

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

[OE-core] [PATCH] libinput: remove obsolete touchpad patch

[Jose Alarcon]

This patch was a temporal workaround needed with 4.1 kernels.
Remove it.

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 ...ics-need-to-fake-new-touches-on-TRIPLETAP.patch | 72 --
 meta/recipes-graphics/wayland/libinput_1.8.1.bb|  1 -
 2 files changed, 73 deletions(-)
 delete mode 100644 
meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch

diff --git 
a/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
 
b/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
deleted file mode 100644
index b52b496..000
--- 
a/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
+++ /dev/null
@@ -1,72 +0,0 @@
-This is a workaround upstream suggests for use with kernel 4.1.
-
-Upstream-Status: Inappropriate [temporary work-around]
-Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
-
-
-
-From: Peter Hutterer <peter.hutte...@who-t.net>
-Date: Mon Aug 3 18:23:12 PDT 2015
-Subject: [PATCH v3 libinput] touchpad: serial synaptics need to fake new 
touches on TRIPLETAP
-
-On the 4.1 kernels synaptics pretends to have 3 slots (the serial fw only does
-2). This was added to avoid cursor jumps but has since been reverted for 4.2
-(kernel commit dbf3c37086, 4.1.3 is still buggy). In some cases a TRIPLETAP
-may be triggered without slot 2 ever activating.
-
-While there are still those kernels out there, work around this bug by opening
-a new touch point where none exists if the fake finger count exceeds the slot
-count.
-
-Reported-by: Jan Alexander Steffens 
-Signed-off-by: Peter Hutterer 
-Tested-by: Jan Alexander Steffens 
-Reviewed-by: Hans de Goede 

-Changes to v2:
-- split out the handling instead of having a tmp state variable, see Hans'
-  comments from v2
-
-Mainly sending this to the list again so I have a link to point people to.
-If you're on 4.1.x add this patch to your distribution package.
-
- src/evdev-mt-touchpad.c | 22 --
- 1 file changed, 16 insertions(+), 6 deletions(-)
-
-diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
-index a683d9a..5ef03d5 100644
 a/src/evdev-mt-touchpad.c
-+++ b/src/evdev-mt-touchpad.c
-@@ -369,13 +369,23 @@ tp_restore_synaptics_touches(struct tp_dispatch *tp,
-   for (i = 0; i < tp->num_slots; i++) {
-   struct tp_touch *t = tp_get_touch(tp, i);
- 
--  if (t->state != TOUCH_END)
-+  switch(t->state) {
-+  case TOUCH_HOVERING:
-+  case TOUCH_BEGIN:
-+  case TOUCH_UPDATE:
-   continue;
--
--  /* new touch, move it through begin to update immediately */
--  tp_new_touch(tp, t, time);
--  tp_begin_touch(tp, t, time);
--  t->state = TOUCH_UPDATE;
-+  case TOUCH_NONE:
-+  /* new touch, move it through to begin immediately */
-+  tp_new_touch(tp, t, time);
-+  tp_begin_touch(tp, t, time);
-+  break;
-+  case TOUCH_END:
-+  /* touch just ended ,we need need to restore it to 
update */
-+  tp_new_touch(tp, t, time);
-+  tp_begin_touch(tp, t, time);
-+  t->state = TOUCH_UPDATE;
-+  break;
-+  }
-   }
- }
- 
--- 
-2.4.3
-
diff --git a/meta/recipes-graphics/wayland/libinput_1.8.1.bb 
b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
index f75298b..a21babe 100644
--- a/meta/recipes-graphics/wayland/libinput_1.8.1.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
@@ -8,7 +8,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=2184aef38ff137ed33ce9a63b9d1eb8f"
 DEPENDS = "libevdev udev mtdev"
 
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
-   
file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
file://0001-tools-Fix-race-in-autotools-install.patch \
 "
 
-- 
2.10.1

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

Re: [OE-core] EXT: Re: [meta-oe][PATCH] Dhrystone: add recipe 2.1

[Jose Alarcon]

Hello,

Thank you for your comments


On 21.08.2017 21:16, Khem Raj wrote:
> On Mon, Aug 21, 2017 at 5:35 AM, Jussi Kukkonen
> <jussi.kukko...@intel.com> wrote:
>> On 21 August 2017 at 13:23, Jose Alarcon <jose.alar...@ge.com> wrote:


>>
>> Hi,
>>
>> Please send meta-oe patches to openembedded-de...@lists.openembedded.org.

My bad. I will send the v2 to the correct list.

>>
>> Also this part is unlikely to be welcome on oe-devel either:
>>> LICENSE = "Proprietary"
>> I think I remember seeing a dhrystone recipe submission with an open source
>> license (NCSA maybe?) last year .
> https://patchwork.openembedded.org/patch/129975/
>
> a v2 was expected, which I cant find so it never got applied. if you
> are interested rework the v1 and test it out. Submit a v2 and we can
> take it further along the line.

About the license, I couldn't find any in the source of Dhrystone.

There is an Android package that mentions NCSA. I believe that Public
Domain would be more appropriate in this case.

I wasn't able to find a dhrystone package in Debian or Fedora to double
check about the license.

Thanks,

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

[OE-core] [meta-oe][PATCH] Dhrystone: add recipe 2.1

[Jose Alarcon]

Dhrystone is a synthetic computing benchmark program developed
in 1984 by Reinhold P. Weicker intended to be representative of
system (integer) programming.

https://en.wikipedia.org/wiki/Dhrystone

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 .../dhrystone/dhrystone-2.1/dhrystone.patch| 81 ++
 .../recipes-benchmark/dhrystone/dhrystone_2.1.bb   | 26 +++
 2 files changed, 107 insertions(+)
 create mode 100644 
meta-oe/recipes-benchmark/dhrystone/dhrystone-2.1/dhrystone.patch
 create mode 100644 meta-oe/recipes-benchmark/dhrystone/dhrystone_2.1.bb

diff --git a/meta-oe/recipes-benchmark/dhrystone/dhrystone-2.1/dhrystone.patch 
b/meta-oe/recipes-benchmark/dhrystone/dhrystone-2.1/dhrystone.patch
new file mode 100644
index 000..ae93aba
--- /dev/null
+++ b/meta-oe/recipes-benchmark/dhrystone/dhrystone-2.1/dhrystone.patch
@@ -0,0 +1,81 @@
+dhrystone: fix compilation problems
+
+This patch fixes two compilation errors with original
+dhrystone sources:
+* Redefinition of times() with wrong return type
+  - Fixed by commenting out the unnecessary redefinition
+* Undefined identifier HZ
+  - Originally HZ was supposed to be the clock frequency
+value for times()
+  - For Linux, the frequency should come from sysconf
+  - This patch defines global varible HZ and initializes
+it from sysconf
+
+Additionally, this patch adds a simple Makefile.
+
+upstream-status : Pending
+
+Sign-off-by: Kimmo Surakka <kimmo.sura...@ge.com>
+Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
+---
+
+diff -Naur dhry.orig/dhry_1.c dhry/dhry_1.c
+--- dhry.orig/dhry_1.c 2015-07-20 14:25:58.059945353 +0300
 dhry/dhry_1.c  2015-07-20 12:43:25.318945353 +0300
+@@ -45,11 +45,15 @@
+ 
+ #ifdef TIMES
+ struct tms  time_info;
+-extern  int times ();
++/* extern  int times (); */
+ /* see library function "times" */
+ #define Too_Small_Time 120
+ /* Measurements should last at least about 2 seconds */
+ #endif
++#ifndef HZ
++#include   /* sysconf */
++   long HZ;
++#endif
+ #ifdef TIME
+ extern long time();
+ /* see library function "time"  */
+@@ -84,6 +88,9 @@
+ 
+   /* Initializations */
+ 
++#ifndef HZ
++  HZ = sysconf(_SC_CLK_TCK);
++#endif
+   Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
+   Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
+ 
+diff -Naur dhry.orig/dhry.h dhry/dhry.h
+--- dhry.orig/dhry.h   2015-07-20 14:25:58.054945353 +0300
 dhry/dhry.h2015-07-20 12:42:59.903945353 +0300
+@@ -420,4 +420,6 @@
+   } variant;
+   } Rec_Type, *Rec_Pointer;
+ 
+-
++#ifndef HZ
++   extern long HZ;
++#endif
+diff -Naur dhry.orig/Makefile dhry/Makefile
+--- dhry.orig/Makefile 1970-01-01 02:00:00.0 +0200
 dhry/Makefile  2015-07-20 14:10:45.832945353 +0300
+@@ -0,0 +1,15 @@
++CC=gcc
++
++all: dhry
++
++dhry: dhry_1.o dhry_2.o
++  $(CC) $(LDFLAGS) -o $@ $^ $(LOADLIBES) $(LDLIBS)
++
++dhry_1.o: dhry_1.c dhry.h
++
++dhry_2.o: dhry_2.c dhry.h
++
++clean:
++  rm -f *.o *~
++
++.PHONY: all clean
diff --git a/meta-oe/recipes-benchmark/dhrystone/dhrystone_2.1.bb 
b/meta-oe/recipes-benchmark/dhrystone/dhrystone_2.1.bb
new file mode 100644
index 000..a11e8cf
--- /dev/null
+++ b/meta-oe/recipes-benchmark/dhrystone/dhrystone_2.1.bb
@@ -0,0 +1,26 @@
+SUMMARY = "Dhrystone CPU benchmark"
+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/files/common-licenses/Proprietary;md5=0557f9d92cf58f2ccdd50f62f8ac0b28"
+
+SRC_URI = "http://www.netlib.org/benchmark/dhry-c;downloadfilename=dhry-c.shar 
\
+   file://dhrystone.patch"
+SRC_URI[md5sum] = "75aa5909c174eed98c134be2f56307da"
+SRC_URI[sha256sum] = 
"038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e"
+
+# Need to override Makefile variables
+EXTRA_OEMAKE = "-e MAKEFLAGS="
+
+do_unpack() {
+[ -d ${S} ] || mkdir -p ${S}
+cd ${S}
+sh ${DL_DIR}/dhry-c.shar
+}
+do_install() {
+install -d ${D}${bindir}
+install -m 0755 ${S}/dhry ${D}${bindir}
+}
+
+# Prevent procedure merging as required by dhrystone.c:
+CFLAGS += "-fno-lto"
+
+LDFLAGS += "-fno-lto"
-- 
2.10.1

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

Re: [OE-core] EXT: Re: [PATCH v2] libx11: Add patch to fix hanging issue in _XReply

[Jose Alarcon]

On 14.08.2017 18:51, Leonardo Sandoval wrote:
> On Mon, 2017-08-14 at 11:00 +0300, Jose Alarcon wrote:
>> Assume event queue is empty if another thread is blocking waiting for event.
>>
>> If one thread was blocking waiting for an event and another thread sent a
>> reply to the X server, both threads got blocked until an event was
>> received.
>>
>> Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
>> ---
>>  .../libx11/Fix-hanging-issue-in-_XReply.patch  | 60 
>> ++
>>  meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb |  1 +
>>  2 files changed, 61 insertions(+)
>>  create mode 100644 
>> meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
>>
>> diff --git 
>> a/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch 
>> b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
>> new file mode 100644
>> index 000..e04acef
>> --- /dev/null
>> +++ 
>> b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
>> @@ -0,0 +1,60 @@
>> +From 5235a7f3692a4c3c90dd4ac1be3c670388904bbe Mon Sep 17 00:00:00 2001
>> +From: Tatu Frisk <tatu.fr...@ge.com>
>> +Date: Tue, 14 Mar 2017 14:41:27 +0200
>> +Subject: [PATCH] Fix hanging issue in _XReply
>> +
>> +Assume event queue is empty if another thread is blocking waiting for event.
>> +
>> +If one thread was blocking waiting for an event and another thread sent a
>> +reply to the X server, both threads got blocked until an event was
>> +received.
>> +
>> +Upstream-Status: Submitted.
> Jose, can you please included where it was submitted:
>
> Upstream-Status: Submitted [where]
>
> More info @
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Thanks Leonardo,

I sent a v3 with the upstream status corrected.

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

[OE-core] [PATCH v3] libx11: Add patch to fix hanging issue in _XReply

[Jose Alarcon]

Assume event queue is empty if another thread is blocking waiting for event.

If one thread was blocking waiting for an event and another thread sent a
reply to the X server, both threads got blocked until an event was
received.

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 .../libx11/Fix-hanging-issue-in-_XReply.patch  | 60 ++
 meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb |  1 +
 2 files changed, 61 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch

diff --git 
a/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch 
b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
new file mode 100644
index 000..897882b
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
@@ -0,0 +1,60 @@
+From 5235a7f3692a4c3c90dd4ac1be3c670388904bbe Mon Sep 17 00:00:00 2001
+From: Tatu Frisk <tatu.fr...@ge.com>
+Date: Tue, 14 Mar 2017 14:41:27 +0200
+Subject: [PATCH] Fix hanging issue in _XReply
+
+Assume event queue is empty if another thread is blocking waiting for event.
+
+If one thread was blocking waiting for an event and another thread sent a
+reply to the X server, both threads got blocked until an event was
+received.
+
+Upstream-Status: Submitted [https://patchwork.freedesktop.org/patch/171458/]
+
+This patch needs to be removed once the corresponding patch has been merged 
upstream.
+
+https://patchwork.freedesktop.org/patch/171458/
+
+Signed-off-by: Tatu Frisk <tatu.fr...@ge.com>
+Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
+---
+ src/xcb_io.c | 19 +++
+ 1 file changed, 7 insertions(+), 12 deletions(-)
+
+diff --git a/src/xcb_io.c b/src/xcb_io.c
+index 5987329..c64eb04 100644
+--- a/src/xcb_io.c
 b/src/xcb_io.c
+@@ -609,22 +609,17 @@ Status _XReply(Display *dpy, xReply *rep, int extra, 
Bool discard)
+* letting anyone else process this sequence number, we
+* need to process any events that should have come
+* earlier. */
+-
+   if(dpy->xcb->event_owner == XlibOwnsEventQueue)
+   {
+   xcb_generic_reply_t *event;
+-  /* If some thread is already waiting for events,
+-   * it will get the first one. That thread must
+-   * process that event before we can continue. */
+-  /* FIXME: That event might be after this reply,
+-   * and might never even come--or there might be
+-   * multiple threads trying to get events. */
+-  while(dpy->xcb->event_waiter)
+-  { /* need braces around ConditionWait */
+-  ConditionWait(dpy, dpy->xcb->event_notify);
++
++  /* Assume event queue is empty if another thread is 
blocking
++   * waiting for event. */
++  if(!dpy->xcb->event_waiter)
++  {
++  while((event = poll_for_response(dpy)))
++  handle_response(dpy, event, True);
+   }
+-  while((event = poll_for_event(dpy)))
+-  handle_response(dpy, event, True);
+   }
+ 
+   req->reply_waiter = 0;
+-- 
+2.10.1
+
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb 
b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
index 50e8837..427bf28 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
@@ -4,6 +4,7 @@ inherit gettext
 BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI += "file://disable_tests.patch \
+file://Fix-hanging-issue-in-_XReply.patch \
"
 do_configure_append () {
 sed -i -e "/X11_CFLAGS/d" ${B}/src/util/Makefile
-- 
2.10.1

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

[OE-core] [PATCH v2] libx11: Add patch to fix hanging issue in _XReply

[Jose Alarcon]

Assume event queue is empty if another thread is blocking waiting for event.

If one thread was blocking waiting for an event and another thread sent a
reply to the X server, both threads got blocked until an event was
received.

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 .../libx11/Fix-hanging-issue-in-_XReply.patch  | 60 ++
 meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb |  1 +
 2 files changed, 61 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch

diff --git 
a/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch 
b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
new file mode 100644
index 000..e04acef
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
@@ -0,0 +1,60 @@
+From 5235a7f3692a4c3c90dd4ac1be3c670388904bbe Mon Sep 17 00:00:00 2001
+From: Tatu Frisk <tatu.fr...@ge.com>
+Date: Tue, 14 Mar 2017 14:41:27 +0200
+Subject: [PATCH] Fix hanging issue in _XReply
+
+Assume event queue is empty if another thread is blocking waiting for event.
+
+If one thread was blocking waiting for an event and another thread sent a
+reply to the X server, both threads got blocked until an event was
+received.
+
+Upstream-Status: Submitted.
+
+This patch needs to be removed once the corresponding patch has been merged 
upstream.
+
+https://patchwork.freedesktop.org/patch/171458/
+
+Signed-off-by: Tatu Frisk <tatu.fr...@ge.com>
+Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
+---
+ src/xcb_io.c | 19 +++
+ 1 file changed, 7 insertions(+), 12 deletions(-)
+
+diff --git a/src/xcb_io.c b/src/xcb_io.c
+index 5987329..c64eb04 100644
+--- a/src/xcb_io.c
 b/src/xcb_io.c
+@@ -609,22 +609,17 @@ Status _XReply(Display *dpy, xReply *rep, int extra, 
Bool discard)
+* letting anyone else process this sequence number, we
+* need to process any events that should have come
+* earlier. */
+-
+   if(dpy->xcb->event_owner == XlibOwnsEventQueue)
+   {
+   xcb_generic_reply_t *event;
+-  /* If some thread is already waiting for events,
+-   * it will get the first one. That thread must
+-   * process that event before we can continue. */
+-  /* FIXME: That event might be after this reply,
+-   * and might never even come--or there might be
+-   * multiple threads trying to get events. */
+-  while(dpy->xcb->event_waiter)
+-  { /* need braces around ConditionWait */
+-  ConditionWait(dpy, dpy->xcb->event_notify);
++
++  /* Assume event queue is empty if another thread is 
blocking
++   * waiting for event. */
++  if(!dpy->xcb->event_waiter)
++  {
++  while((event = poll_for_response(dpy)))
++  handle_response(dpy, event, True);
+   }
+-  while((event = poll_for_event(dpy)))
+-  handle_response(dpy, event, True);
+   }
+ 
+   req->reply_waiter = 0;
+-- 
+2.10.1
+
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb 
b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
index 50e8837..427bf28 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
@@ -4,6 +4,7 @@ inherit gettext
 BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI += "file://disable_tests.patch \
+file://Fix-hanging-issue-in-_XReply.patch \
"
 do_configure_append () {
 sed -i -e "/X11_CFLAGS/d" ${B}/src/util/Makefile
-- 
2.10.1

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

[OE-core] [meta-oe][PATCH] libx11: Add patch to fix hanging issue in _XReply

[Jose Alarcon]

Assume event queue is empty if another thread is blocking waiting for event.

If one thread was blocking waiting for an event and another thread sent a
reply to the X server, both threads got blocked until an event was
received.
---
 .../libx11/Fix-hanging-issue-in-_XReply.patch  | 59 ++
 meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch

diff --git 
a/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch 
b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
new file mode 100644
index 000..c3d9ba3
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/Fix-hanging-issue-in-_XReply.patch
@@ -0,0 +1,59 @@
+From 5235a7f3692a4c3c90dd4ac1be3c670388904bbe Mon Sep 17 00:00:00 2001
+From: Tatu Frisk 
+Date: Tue, 14 Mar 2017 14:41:27 +0200
+Subject: [PATCH] Fix hanging issue in _XReply
+
+Assume event queue is empty if another thread is blocking waiting for event.
+
+If one thread was blocking waiting for an event and another thread sent a
+reply to the X server, both threads got blocked until an event was
+received.
+
+Upstream-Status: Submitted.
+
+This patch needs to be removed once the corresponding patch has been merged 
upstream.
+
+https://patchwork.freedesktop.org/patch/171458/
+
+Signed-off-by: Tatu Frisk 
+---
+ src/xcb_io.c | 19 +++
+ 1 file changed, 7 insertions(+), 12 deletions(-)
+
+diff --git a/src/xcb_io.c b/src/xcb_io.c
+index 5987329..c64eb04 100644
+--- a/src/xcb_io.c
 b/src/xcb_io.c
+@@ -609,22 +609,17 @@ Status _XReply(Display *dpy, xReply *rep, int extra, 
Bool discard)
+* letting anyone else process this sequence number, we
+* need to process any events that should have come
+* earlier. */
+-
+   if(dpy->xcb->event_owner == XlibOwnsEventQueue)
+   {
+   xcb_generic_reply_t *event;
+-  /* If some thread is already waiting for events,
+-   * it will get the first one. That thread must
+-   * process that event before we can continue. */
+-  /* FIXME: That event might be after this reply,
+-   * and might never even come--or there might be
+-   * multiple threads trying to get events. */
+-  while(dpy->xcb->event_waiter)
+-  { /* need braces around ConditionWait */
+-  ConditionWait(dpy, dpy->xcb->event_notify);
++
++  /* Assume event queue is empty if another thread is 
blocking
++   * waiting for event. */
++  if(!dpy->xcb->event_waiter)
++  {
++  while((event = poll_for_response(dpy)))
++  handle_response(dpy, event, True);
+   }
+-  while((event = poll_for_event(dpy)))
+-  handle_response(dpy, event, True);
+   }
+ 
+   req->reply_waiter = 0;
+-- 
+2.10.1
+
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb 
b/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb
index caa95fb..7ee51ad 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb
@@ -4,6 +4,7 @@ inherit gettext
 BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI += "file://disable_tests.patch \
+file://Fix-hanging-issue-in-_XReply.patch \
"
 
 SRC_URI[md5sum] = "6d54227082f3aa2c596f0b3a3fbb9175"
-- 
2.10.1

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

[OE-core] [PATCH] Create class to test for unsatisfied RRECOMMENDS

[Jose Alarcon]

The do_rootfs log contains a number of unsatisfied package
recommendations. At the moment those are only visible when
reviewing the rootfs log.

This class adds an extra check to surface any unsatisfied
recommendation  as WARNINGS to the build output.

Signed-off-by: Jose Alarcon <jose.alar...@ge.com>
---
 meta/classes/rootfs-check-recommends.bbclass | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 meta/classes/rootfs-check-recommends.bbclass

diff --git a/meta/classes/rootfs-check-recommends.bbclass 
b/meta/classes/rootfs-check-recommends.bbclass
new file mode 100644
index 000..351e438
--- /dev/null
+++ b/meta/classes/rootfs-check-recommends.bbclass
@@ -0,0 +1,21 @@
+#
+# This bbclass adds an extra check to surface any unsatisfied
+# recommendation (RRECOMMENDS) as WARNINGS to the build output.
+#
+# To enable, use INHERIT in conf/distro/distro.conf:
+#
+#   INHERIT += "rootfs-check-recommends"
+#
+
+python log_check_recommends() {
+log_path = d.expand("${T}/log.do_rootfs")
+with open(log_path, 'r') as log:
+for line in log:
+if 'log_check' in line:
+continue
+
+if 'unsatisfied recommendation for' in line:
+bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
+}
+
+do_rootfs[postfuncs] += "log_check_recommends "
-- 
2.4.5

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