[PATCH 0/1] Fix browser crash on PPC

[PATCH 0/1] Fix browser crash on PPC

[edwin.zhai]

From: Zhai Edwin <edwin.zhai@intel.com>

All,
    This patch use glib as unicode backend to avoid browser crash
            
webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
target system owns different endian. ICU's community is not responsive to make
a patch for this, so glib is used as work around here.

[YOCTO #1570] got fixed


The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa:

  cooker.py: terminate the Parser processes (2012-05-25 11:39:33 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib gzhai/fix3
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix3

Zhai Edwin (1):
  webkit-gtk: Use glib as unicode backend to avoid browser crash

 meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

[PATCH 1/1] webkit-gtk: Use glib as unicode backend to avoid browser crash

[edwin.zhai]

From: Zhai Edwin <edwin.zhai@intel.com>

webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
target system owns different endian. ICU's community is not responsive to make
a patch for this, so glib is used as work around here.

[YOCTO #1570] got fixed

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
---
 meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkit-gtk_svn.bb b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
index 7db573d..9381486 100644
--- a/meta/recipes-sato/webkit/webkit-gtk_svn.bb
+++ b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
@@ -10,12 +10,13 @@ LIC_FILES_CHKSUM = "file://Source/WebCore/rendering/RenderApplet.h;endline=22;md
 DEPENDS = "zlib enchant gnome-keyring libsoup-2.4 curl icu libxml2 cairo libxslt libxt libidn gnutls gtk+ gstreamer gst-plugins-base flex-native gperf-native perl-native-runtime sqlite3"
 DEPENDS += " ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', d)}"
 DEPENDS_darwin8 = "curl icu libxml2 cairo libxslt libidn gnutls gtk+ gstreamer flex-native gperf-native perl-native-runtime sqlite3"
+DEPENDS_append_qemuppc += "pango"
 
 SRCREV_FORMAT = "source"
 
 SRCREV = "101488"
 PV = "1.7.2+svnr${SRCPV}"
-PR = "r4"
+PR = "r5"
 
 SRC_URI = "\
   svn://svn.webkit.org/repository/webkit/trunk/;module=Source;proto=http;name=source \
@@ -47,6 +48,13 @@ EXTRA_OECONF = "\
                 UNICODE_CFLAGS=-D_REENTRANT \
                "
 
+#default unicode backend icu breaks in cross-compile when target and host owns different endian type
+EXTRA_OECONF_append_qemuppc += "--with-unicode-backend=glib"
+
+CPPFLAGS_append_qemuppc += "-I${STAGING_INCDIR}/pango-1.0 \
+                            -I${STAGING_LIBDIR}/glib-2.0/include \
+                            -I${STAGING_INCDIR}/glib-2.0"
+
 EXTRA_AUTORECONF = " -I Source/autotools "
 
 
-- 
1.7.1

Re: [PATCH 1/1] webkit-gtk: Use glib as unicode backend to avoid browser crash

[Richard Purdie]

On Wed, 2012-05-30 at 17:08 +0800, edwin.zhai@intel.com wrote:
> From: Zhai Edwin <edwin.zhai@intel.com>
> 
> webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
> target system owns different endian. ICU's community is not responsive to make
> a patch for this, so glib is used as work around here.
> 
> [YOCTO #1570] got fixed
> 
> Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
> ---
>  meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
>  1 files changed, 9 insertions(+), 1 deletions(-)

I've merged this however I'm not 100% happy with this as the final fix.
I'd ask that:

a) The bug remains open (re-prioritised appropriately) about the
remaining issues that still exist in ICU
b) We add something to the ICU recipe which stops it building when the
endianess isn't correct (host matches target) so nobody can built it and
have it not work.

Cheers,

Richard

Re: [PATCH 1/1] webkit-gtk: Use glib as unicode backend to avoid browser crash

[Gary Thomas]

On 2012-05-30 10:40, Richard Purdie wrote:
> On Wed, 2012-05-30 at 17:08 +0800, edwin.zhai@intel.com wrote:
>> From: Zhai Edwin<edwin.zhai@intel.com>
>>
>> webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
>> target system owns different endian. ICU's community is not responsive to make
>> a patch for this, so glib is used as work around here.
>>
>> [YOCTO #1570] got fixed
>>
>> Signed-off-by: Zhai Edwin<edwin.zhai@intel.com>
>> ---
>>   meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
>>   1 files changed, 9 insertions(+), 1 deletions(-)
>
> I've merged this however I'm not 100% happy with this as the final fix.
> I'd ask that:
>
> a) The bug remains open (re-prioritised appropriately) about the
> remaining issues that still exist in ICU
> b) We add something to the ICU recipe which stops it building when the
> endianess isn't correct (host matches target) so nobody can built it and
> have it not work.

Why not accept my patch that provides a working dataset?  I doubt
that you're ever going to get the ICU folks interested to the point
of fixing this correctly and this solves the problem without the
[IMO undesirable] side effect of using different libraries on
different architectures (for webkit-gtk).

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

Re: [PATCH 1/1] webkit-gtk: Use glib as unicode backend to avoid browser crash

[Zhai, Edwin]

On Wed, May 30, 2012 at 12:56:27PM -0600, Gary Thomas wrote:
> On 2012-05-30 10:40, Richard Purdie wrote:
> >
> >I've merged this however I'm not 100% happy with this as the final fix.
> >I'd ask that:
> >
> >a) The bug remains open (re-prioritised appropriately) about the
> >remaining issues that still exist in ICU
> >b) We add something to the ICU recipe which stops it building when the
> >endianess isn't correct (host matches target) so nobody can built it and
> >have it not work.
> 
> Why not accept my patch that provides a working dataset?  I doubt

Provideding a big binary in yocto website is not clean, but it should avoid 
potential side effect. 

> that you're ever going to get the ICU folks interested to the point
> of fixing this correctly and this solves the problem without the
> [IMO undesirable] side effect of using different libraries on

This is ultimate solution. I remember ICU community is not so active to do it.

> different architectures (for webkit-gtk).
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
best rgds,
edwin

Re: [PATCH 1/1] webkit-gtk: Use glib as unicode backend to avoid browser crash

[Richard Purdie]

On Wed, 2012-05-30 at 12:56 -0600, Gary Thomas wrote:
> On 2012-05-30 10:40, Richard Purdie wrote:
> > On Wed, 2012-05-30 at 17:08 +0800, edwin.zhai@intel.com wrote:
> >> From: Zhai Edwin<edwin.zhai@intel.com>
> >>
> >> webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
> >> target system owns different endian. ICU's community is not responsive to make
> >> a patch for this, so glib is used as work around here.
> >>
> >> [YOCTO #1570] got fixed
> >>
> >> Signed-off-by: Zhai Edwin<edwin.zhai@intel.com>
> >> ---
> >>   meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
> >>   1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > I've merged this however I'm not 100% happy with this as the final fix.
> > I'd ask that:
> >
> > a) The bug remains open (re-prioritised appropriately) about the
> > remaining issues that still exist in ICU
> > b) We add something to the ICU recipe which stops it building when the
> > endianess isn't correct (host matches target) so nobody can built it and
> > have it not work.
> 
> Why not accept my patch that provides a working dataset?  I doubt
> that you're ever going to get the ICU folks interested to the point
> of fixing this correctly and this solves the problem without the
> [IMO undesirable] side effect of using different libraries on
> different architectures (for webkit-gtk).

The issue here is that starting to distribute binary blobs gets us into
potentially troubled waters. It also means that for every new tune or
target (say mips BE), we'd need another blob. Add something like uclibc
and the problem gets worse.

So I can see the attraction of the solution and it works well for
particular cases but it isn't something I think can be made to work in
OE-Core in the general case :(.

I did wonder whether we could post process the binary to correct the
endianess of the data in the file?

Cheers,

Richard

RPM packaging issue?

[Laurentiu Palcu]

Hi list,

I was trying to build core-image-gtk-directfb and ended up with this error:

Log data follows:
| DEBUG: Executing shell function do_rootfs
| ERROR: Function failed: do_rootfs (see
/home/lau/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.4857
for further information)
| Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/qemux86...
| Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/i586...
| Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/all...
| Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/all...
| Processing task-core-boot...
| Processing module-init-tools...
| Unable to find package module-init-tools (module-init-tools)!
NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed

module-init-tools is provided by kmod package and is in the RDEPENDS of
task_base recipe.

Then I tried to add module_init_tools to CORE_IMAGE_EXTRA_INSTALL and
build core-image-minimal (just for testing), the same result.

The interesting thing is that this didn't happen if the packaging format
is ipk.

Anybody know anything about this issue?

Thanks,
Laurentiu

Re: RPM packaging issue?

[Mark Hatle]

On 5/31/12 8:33 PM, Laurentiu Palcu wrote:
> Hi list,
>
> I was trying to build core-image-gtk-directfb and ended up with this error:
>
> Log data follows:
> | DEBUG: Executing shell function do_rootfs
> | ERROR: Function failed: do_rootfs (see
> /home/lau/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.4857
> for further information)
> | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/qemux86...
> | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/i586...
> | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/all...
> | Generating solve db for /home/lau/yocto/build/tmp/deploy/rpm/all...
> | Processing task-core-boot...
> | Processing module-init-tools...
> | Unable to find package module-init-tools (module-init-tools)!
> NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
>
> module-init-tools is provided by kmod package and is in the RDEPENDS of
> task_base recipe.
>
> Then I tried to add module_init_tools to CORE_IMAGE_EXTRA_INSTALL and
> build core-image-minimal (just for testing), the same result.
>
> The interesting thing is that this didn't happen if the packaging format
> is ipk.
>
> Anybody know anything about this issue?

The IMAGE_INSTALL list has module-init-tools in it.  This list is based on 
package name and not "dependency" or "provide" name.  The package 
module-init-tools no longer exists in the system, there is only a runtime 
provide from the kmod package.

This ensures that any package that requires module-init-tools will work 
properly, but anyone adding module-init-tools to the IMAGE_INSTALL it will fail 
as you've seen above.

--Mark

> Thanks,
> Laurentiu
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 0/1] Fix browser crash on PPC

[Gary Thomas]

On 2012-05-30 03:08, edwin.zhai@intel.com wrote:
> From: Zhai Edwin<edwin.zhai@intel.com>
>
> All,
>      This patch use glib as unicode backend to avoid browser crash
>
> webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
> target system owns different endian. ICU's community is not responsive to make
> a patch for this, so glib is used as work around here.
>
> [YOCTO #1570] got fixed
>
>
> The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa:
>
>    cooker.py: terminate the Parser processes (2012-05-25 11:39:33 +0100)
>
> are available in the git repository at:
>    git://git.pokylinux.org/poky-contrib gzhai/fix3
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix3
>
> Zhai Edwin (1):
>    webkit-gtk: Use glib as unicode backend to avoid browser crash
>
>   meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
>   1 files changed, 9 insertions(+), 1 deletions(-)

Note: any big-endian target will probably suffer the same as PowerPC,
so should this not also be extended to those, e.g. big-endian MIPS, etc?

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

Re: [PATCH 0/1] Fix browser crash on PPC

[Koen Kooi]

Op 30 mei 2012, om 11:08 heeft edwin.zhai@intel.com het volgende geschreven:

> From: Zhai Edwin <edwin.zhai@intel.com>
> 
> All,
>    This patch use glib as unicode backend to avoid browser crash
> 
> webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
> target system owns different endian. ICU's community is not responsive to make
> a patch for this, so glib is used as work around here.

That is a really big change since the backends don't have equivalent functionality.

> [YOCTO #1570] got fixed
> 
> 
> The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa:
> 
>  cooker.py: terminate the Parser processes (2012-05-25 11:39:33 +0100)
> 
> are available in the git repository at:
>  git://git.pokylinux.org/poky-contrib gzhai/fix3
>  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix3

And that doesn't merge into oe-core, so I can't test it.