Re: [OE-core] EXT: Re: [PATCH 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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