<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>1570</bug_id>
          
          <creation_ts>2011-10-03 07:58:31 +0000</creation_ts>
          <short_desc>ICU fails if target endian != build host endian</short_desc>
          <delta_ts>2018-01-25 16:05:23 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>OE-Core</product>
          <component>graphics</component>
          <version>unspecified</version>
          <rep_platform>Other</rep_platform>
          <op_sys>ppc</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard>Tested on qemuppc, ask for Gary to have a try. May24, 2012</status_whiteboard>
          <keywords></keywords>
          <priority>Low</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>Future</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Gary Thomas">gary</reporter>
          <assigned_to name="Ross Burton">ross.burton</assigned_to>
          <cc>jessica.zhang</cc>
    
    <cc>meta.mr.watcher</cc>
    
    <cc>meta.watcher</cc>
    
    <cc>nitin.a.kamble</cc>
    
    <cc>randy.macleod</cc>
    
    <cc>richard.purdie</cc>
    
    <cc>scott.a.garman</cc>
    
    <cc>sgw</cc>
    
    <cc>shane.wang</cc>
    
    <cc>song.liu</cc>
    
    <cc>yi.zhao</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>---</cf_regression_type>
          
          <cf_docchange>Don&apos;t know</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>16618</commentid>
    <comment_count>0</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2011-10-03 07:58:31 +0000</bug_when>
    <thetext>I&apos;m trying to run the web-webkit browser on my PowerPC system (built using Poky).
I&apos;ve built this on ARM and it runs great, but on PowerPC it fails almost immediately.
Following into the failure with GDB, it looks like it&apos;s trying to build up a string
using a [possibly] wide character iterator.  It fails on line 76 of the code below,
going through it by hand shows that &apos;iterator&apos; is NULL.

(gdb) dir /local/logopak8347tbga_new/tmp/work/ppc603e-amltd-linux/webkit-gtk-1.5.1+svnr90727-r0
(gdb) l
71      TextBreakIterator* acquireLineBreakIterator(const UChar* string, int length, const AtomicString&amp; locale)
72      {
73          UBreakIterator* iterator = LineBreakIteratorPool::sharedPool().take(locale);
74
75          UErrorCode setTextStatus = U_ZERO_ERROR;
76          ubrk_setText(iterator, string, length, &amp;setTextStatus);
77          if (U_FAILURE(setTextStatus)) {
78              LOG_ERROR(&quot;ubrk_setText failed with status %d&quot;, setTextStatus);
79              return 0;
80          }
(gdb) b 75
Breakpoint 1 at 0xf8a7440: file Source/WebCore/platform/text/TextBreakIteratorICU.cpp, line 75.

Any ideas what might be wrong here?  Maybe some confusion about wide vs not-wide
character representation (I&apos;ve seen this one a lot, especially on PowerPC systems)?
Any clues where to look next?
I did note that &apos;locale&apos; into this function is also NULL.

Note: I tried this with the stock Poky master 9d1db6cc928199f8ac4960e8d4648563ef141427
building for qemuppc and running web2 via ssh -X (since qemu doesn&apos;t support graphics?)
The failure is the same, so this is not something special in my setup.

Note 2: it&apos;s difficult to get this to fail when running in qemu since it only fails
when it&apos;s loading and rendering the www.google.co.uk default page.  I couldn&apos;t figure
out how to get my qemu system to be able to access that page over the net, but I ran
the same Yocto filesystem on my hardware (this is not a hardware bug) with the same
failure.  Maybe someone smarter than me can show me how to get qemu to actually access
the internet (when the machine that&apos;s running qemu is inside a NAT&apos;d zone)?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>16637</commentid>
    <comment_count>1</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2011-10-04 06:06:59 +0000</bug_when>
    <thetext>Further investigation shows that this is a failure in the ICU library.  Webkit is using
ICU to help it render strings and the calls to &apos;ubrk_open()&apos; always return NULL.

This is because of how the ICU library is built.  It contains some prebuilt tables which
are target specific.  If the host and target have different endianness (or indeed other
layout issues), this fails.

I built the ICU library (version 3.6) by hand on a PowerPC host and installed this
to my Poky system.  Now &apos;web2&apos; runs fine.

Newer versions of ICU supposedly handle this case where the host and target are
not the same endianness.  However, my experience with version 4.4 in the past showed
that the situation was not any better.  I&apos;ll try the latest 4.8.1 to see if it helps.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>16657</commentid>
    <comment_count>2</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2011-10-04 08:18:17 +0000</bug_when>
    <thetext>ICU 4.8.1 still fails under these conditions :-(</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>16721</commentid>
    <comment_count>3</comment_count>
      <attachid>270</attachid>
    <who name="Gary Thomas">gary</who>
    <bug_when>2011-10-05 08:10:37 +0000</bug_when>
    <thetext>Created attachment 270
Updated recipe for ICU library

Includes PowerPC work around.  Actual data file can be found at:
  http://www.mlbassoc.com/poky/libicudata.so.48.1.gz</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>17763</commentid>
    <comment_count>4</comment_count>
    <who name="Jessica">jessica.zhang</who>
    <bug_when>2011-12-20 11:42:53 +0000</bug_when>
    <thetext>Please take some action on the bug, at least accept the bug</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20248</commentid>
    <comment_count>5</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2012-04-12 16:26:45 +0000</bug_when>
    <thetext>Gary,
  There is nothing special about getting to internet from qemu. if you are behind proxies then you will need to setup the proxies inside qemu.

Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20249</commentid>
    <comment_count>6</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2012-04-12 16:37:16 +0000</bug_when>
    <thetext>Gary,
  I see you have a binary file with powerpc work around. Why don&apos;t you apply patches for the work around to the recipe in poky?

Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20254</commentid>
    <comment_count>7</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2012-04-12 17:02:15 +0000</bug_when>
    <thetext>(In reply to comment #6)
&gt; Gary,
&gt;   I see you have a binary file with powerpc work around. Why don&apos;t you apply
&gt; patches for the work around to the recipe in poky?
&gt; 
&gt; Nitin

It&apos;s not that simple - the work around is to provide a database library which is in the correct endian format.  If you are building this recipe on a little endian machine (most everyone is), the library created is incorrect when used on big endian targets.  The ICU build process attempts to get this right, but it&apos;s not even close and upstream doesn&apos;t seem too interested in making it work :-(</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20268</commentid>
    <comment_count>8</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2012-04-12 21:34:37 +0000</bug_when>
    <thetext>Gary,
  Can you scope out how much work is needed to support correct endian-ness in a cross build?
  1. If it is not too much work then support can be added to ICU to swap the bytes for correct endian-ness. 
  2. If it is too much work, then it can be build with mips qemu emulation, which will be built much slowly but correctly. 
  3. And also another option is what you have, provide prebuilt library from some url.

Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20271</commentid>
    <comment_count>9</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2012-04-12 23:39:13 +0000</bug_when>
    <thetext>(In reply to comment #8)
&gt; Gary,
&gt;   Can you scope out how much work is needed to support correct endian-ness in a
&gt; cross build?
&gt;   1. If it is not too much work then support can be added to ICU to swap the
&gt; bytes for correct endian-ness. 
&gt;   2. If it is too much work, then it can be build with mips qemu emulation,
&gt; which will be built much slowly but correctly. 
&gt;   3. And also another option is what you have, provide prebuilt library from
&gt; some url.
&gt; 
&gt; Nitin

There is already code for option (1) but it&apos;s severely broken and would take a significant amount of time to redo (probably start from scratch)

Option (2) would be OK - not sure why you&apos;d choose MIPS instead of PowerPC?
I&apos;d hate to have to build a complete MIPS setup when I build for PowerPC, just
to solve this issue :-(

I prefer option (3) as I already have it working and tested.  It only requires updating the library manually when the recipe changes.  Given that the OE-core
recipe is still at 3.6 (I&apos;ve tested 4.8.1 here) and that this project changes
very rarely, I think this would be the way to go.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20276</commentid>
    <comment_count>10</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2012-04-13 01:41:34 +0000</bug_when>
    <thetext>I meant powerpc in place of mips. (for me mips and ppc are equally foreign, hence the confusion)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20280</commentid>
    <comment_count>11</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2012-04-13 04:51:48 +0000</bug_when>
    <thetext>Gary,
   the 3rd options is the hardest to get included in the tree though.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20521</commentid>
    <comment_count>12</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-17 11:39:31 +0000</bug_when>
    <thetext>Its too late to get this into 1.2, targeting to point release.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20722</commentid>
    <comment_count>13</comment_count>
    <who name="Edwin Zhai">edwin.zhai</who>
    <bug_when>2012-04-19 15:20:33 +0000</bug_when>
    <thetext>Gary,
I investigated ICU, and found it&apos;s not easy to add this feature. But we can configure webkit-gtk to use glib as unicode backend rather than icu as attached patch. Some comments says glib&apos;s unicode is incomplete, so can you have a test on your real machine(need change my patch a little bit) when you have time?

If it works, we can use it as temporary solution before this feature is added in ICU upstream.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20723</commentid>
    <comment_count>14</comment_count>
      <attachid>491</attachid>
    <who name="Edwin Zhai">edwin.zhai</who>
    <bug_when>2012-04-19 15:22:06 +0000</bug_when>
    <thetext>Created attachment 491
Fix web2 segfault on ppc

configure webkit-gtk to use glib rather than icu as unicode backend to avoid segfault</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21541</commentid>
    <comment_count>15</comment_count>
    <who name="Yi Zhao">yi.zhao</who>
    <bug_when>2012-05-23 10:09:58 +0000</bug_when>
    <thetext>Currently our ppc board mpc8315e-rdb doesn&apos;t support X because it does&apos;t have any graphics adaptor, so we can not verifiy it on real hardware. But I can reproduce this bug on qemuppc because it supports X now.

We need to re-configure the qemu network to make it can access internet:
######
1. On linux host, enable the ip forwarding: 
   $ echo 1 &gt; /proc/sys/net/ipv4/ip_forward
   If there is a firewall on the host, we also need to run the following command:
   $ iptables -t nat -A POSTROUTING -j MASQUERADE

2. Launch the qemuppc image.

3. We need to re-configure the network manually.
   First, kill the connmand:
   $ killall connmand
   $ ifconfig eth0 192.168.7.2
   $ ifconfig eth0 up
   Then add a default gw:
   $ route add default gw 192.168.7.1 dev eth0

4. Add a nameserver in /etc/resolv.conf

5. Launch the web2 in terminal. Then the brower could access the internet.
########

I built a qemuppc sato-image with the latest master branch(b4c8c74a45e386f99344cf9799eb5294ad6c9e3e). When I access some complicated website, like www.intel.com or www.nvidia.com. There would be a segfault with it.

After applying Edwin&apos;s patch, the web2 works fine. But there is still some issues, someone has opened a bug 2318 to report it.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21650</commentid>
    <comment_count>16</comment_count>
    <who name="Edwin Zhai">edwin.zhai</who>
    <bug_when>2012-05-28 02:11:32 +0000</bug_when>
    <thetext>(In reply to comment #9)
Gary,
I have sent you a mail, could you pls. test the attached patch to see if it works?

Thanks,
Edwin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21677</commentid>
    <comment_count>17</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2012-05-28 17:30:47 +0000</bug_when>
    <thetext>Yes, this change does work (tested with the attached patch).

Perhaps the changes in the patch should just be used for all architectures?  No need to mess with the ICU package (broken) when pango can work just as well.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21682</commentid>
    <comment_count>18</comment_count>
    <who name="Edwin Zhai">edwin.zhai</who>
    <bug_when>2012-05-29 00:28:02 +0000</bug_when>
    <thetext>(In reply to comment #17)
&gt; Yes, this change does work (tested with the attached patch).
&gt; 
&gt; Perhaps the changes in the patch should just be used for all architectures? 
&gt; No need to mess with the ICU package (broken) when pango can work just as
&gt; well.

I&apos;m not sure if glib unicode works for all architectures. Furthermore, readme in glib said its unicode implementation is incomplete at this point. So I&apos;d like to use this work around only for ppc and turn to ICU if they fix this issue, or glib if it become more popular. Do you agree?

Is your machine config in oe-core? Or you need something like bbappend in your layer.

Thanks,
Edwin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21688</commentid>
    <comment_count>19</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2012-05-29 10:56:39 +0000</bug_when>
    <thetext>(In reply to comment #18)
&gt; (In reply to comment #17)
&gt; &gt; Yes, this change does work (tested with the attached patch).
&gt; &gt; 
&gt; &gt; Perhaps the changes in the patch should just be used for all architectures? 
&gt; &gt; No need to mess with the ICU package (broken) when pango can work just as
&gt; &gt; well.
&gt; 
&gt; I&apos;m not sure if glib unicode works for all architectures. Furthermore,
&gt; readme in glib said its unicode implementation is incomplete at this point.
&gt; So I&apos;d like to use this work around only for ppc and turn to ICU if they fix
&gt; this issue, or glib if it become more popular. Do you agree?

Fair enough - for machines that share the same endian-ness as the build host (typically little endian machines) this is acceptable.  What I don&apos;t like about it is that the program will be built differently, hence behave differently, on different target architectures (seldom a correct choice)

&gt; 
&gt; Is your machine config in oe-core? Or you need something like bbappend in
&gt; your layer.

No, my machine is not public.  

At this point, I just have edited the main recipe directly (matching your request).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21779</commentid>
    <comment_count>20</comment_count>
    <who name="Edwin Zhai">edwin.zhai</who>
    <bug_when>2012-06-01 01:15:30 +0000</bug_when>
    <thetext>Patch to use glib as unicode backend is already in master, so there is no crash from web browser on ppc.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=348da93e283b2b8454fd9cde80d4b17378e2a168

For the ICU bug, we need keep tracking the upstream status for a fix. I&apos;d suggest postpone it to a later milestone.

Thanks,
Edwin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>22013</commentid>
    <comment_count>21</comment_count>
    <who name="Edwin Zhai">edwin.zhai</who>
    <bug_when>2012-06-11 23:38:44 +0000</bug_when>
    <thetext>We have a work around to fix the browser crash on ppc system, and wait for ICU&apos;s community to fix this cross-compile issue.

Postpone it to 1.4.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>22039</commentid>
    <comment_count>22</comment_count>
      <attachid>569</attachid>
    <who name="Gary Thomas">gary</who>
    <bug_when>2012-06-12 11:43:19 +0000</bug_when>
    <thetext>Created attachment 569
Extend fix for all PowerPC targets</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>26619</commentid>
    <comment_count>23</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2012-10-15 21:48:56 +0000</bug_when>
    <thetext>Gary&apos;s patch was applied a while ago, and Webkit is working on qemuppc. We are still waiting for the upstream to provide a proper patch, there are various cross-compilation and endianness bugs at http://bugs.icu-project.org/trac, I am not exactly sure if gary or edwin actually filed bugs.

I also agree with Gary, we might make full build use pango for all arches and see what happens, I will test this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>56367</commentid>
    <comment_count>24</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2015-11-10 17:27:09 +0000</bug_when>
    <thetext>A relevant upstream bug is http://bugs.icu-project.org/trac/ticket/11758. Open for 57 months.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>79221</commentid>
    <comment_count>25</comment_count>
    <who name="Randy MacLeod">randy.macleod</who>
    <bug_when>2018-01-25 16:05:23 +0000</bug_when>
    <thetext>commit 77d1b9cda69d09cd7d3c8174ef14b4ee10e5efb6
Author: Yi Zhao &lt;yi.zhao@windriver.com&gt;
Date:   Tue Dec 5 09:17:04 2017 +0800

    icu: fix libicudata corruption on big endian system</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>270</attachid>
            <date>2011-10-05 08:10:37 +0000</date>
            <delta_ts>2011-10-05 08:10:37 +0000</delta_ts>
            <desc>Updated recipe for ICU library</desc>
            <filename>icu_4.8.1.bb</filename>
            <type>application/octet-stream</type>
            <size>2211</size>
            <attacher name="Gary Thomas">gary</attacher>
            
              <data encoding="base64">REVTQ1JJUFRJT04gPSAiVGhlIEludGVybmF0aW9uYWwgQ29tcG9uZW50IGZvciBVbmljb2RlIChJ
Q1UpIGlzIGEgbWF0dXJlLCBwb3J0YWJsZSBzZXQgb2YgQy9DKysgYW5kIEphdmEgbGlicmFyaWVz
IGZvciBVbmljb2RlIHN1cHBvcnQsIHNvZnR3YXJlIGludGVybmF0aW9uYWxpemF0aW9uIChJMThO
KSBhbmQgZ2xvYmFsaXphdGlvbiAoRzExTiksIGdpdmluZyBhcHBsaWNhdGlvbnMgdGhlIHNhbWUg
cmVzdWx0cyBvbiBhbGwgcGxhdGZvcm1zLiIKSE9NRVBBR0UgPSAiaHR0cDovL3dodHRwOi8vc2l0
ZS5pY3UtcHJvamVjdC5vcmcvIgoKU1JDX1VSSSA9ICJodHRwOi8vZG93bmxvYWQuaWN1LXByb2pl
Y3Qub3JnL2ZpbGVzL2ljdTRjLzQuOC4xL2ljdTRjLTRfOF8xLXNyYy50Z3o7bmFtZT1pY3VzcmMg
XAogICAgICAgICAgIgpTUkNfVVJJW2ljdXNyYy5tZDVzdW1dID0gImFmMzZmNjM1MjcxYTIzOWQ3
NmQwMzhkNmNmOGRhOGRmIgpTUkNfVVJJW2ljdXNyYy5zaGEyNTZzdW1dID0gIjE5YTRjZDZlOTQx
ODdhMDNiY2E3NTE0ZDY5NGM1YTVhNjY2NTY3ZTI4ODRjZTAwOGNhOWYxNGZhNDAwYWY4OGYiCgpQ
UiA9ICJyMCIKTElDRU5TRSA9ICJJQ1UiCkxJQ19GSUxFU19DSEtTVU0gPSAiZmlsZTovLyR7V09S
S0RJUn0vaWN1L2xpY2Vuc2UuaHRtbDttZDU9YzdjMmZiNWYzYjgxMWExMmU5NjIxMDIwNzkzY2Y5
OTkgXAoJCSAgICBmaWxlOi8vJHtXT1JLRElSfS9pY3UvdW5pY29kZS1saWNlbnNlLnR4dDttZDU9
ODFhZmNhMjFjZGZjOTAzYWJjY2Q1MGVlZDM5MmY4NWMgIgoKREVQRU5EUyA9ICJpY3UtbmF0aXZl
IgpERVBFTkRTX3ZpcnRjbGFzcy1uYXRpdmUgPSAiIgoKUyA9ICIke1dPUktESVJ9L2ljdS9zb3Vy
Y2UiCgpQQVJBTExFTF9NQUtFID0gIiIKRlVMTF9PUFRJTUlaQVRJT05fYXJtID0gIi1PcyIKCmlu
aGVyaXQgYXV0b3Rvb2xzX3N0YWdlIHBrZ2NvbmZpZyBiaW5jb25maWcKCl9PRUNPTkYgPSAiIC0t
d2l0aC1jcm9zcy1idWlsZD0ke1dPUktESVJ9Ly4uLy4uLyR7QlVJTERfU1lTfS9pY3UtbmF0aXZl
LSR7UFZ9LSR7UFJ9L2ljdS9zb3VyY2UgIgpfT0VDT05GX3ZpcnRjbGFzcy1uYXRpdmUgPSAiIgpF
WFRSQV9PRUNPTkYgKz0gJHtfT0VDT05GfQoKIyBNYWluIHBhY2thZ2UgbGlua3MgYmFjayBpbnRv
IG5hdGl2ZSB2ZXJzaW9uICh1Z2x5Li4uKSwgc28gcm1fd29yayBpcyBiYWQKZG9fcm1fd29yaygp
IHsKfQoKZG9fY29uZmlndXJlKCkgewoJbGlidG9vbGl6ZSAtLWZvcmNlCglnbnUtY29uZmlnaXpl
IC0tZm9yY2UKCW9lX3J1bmNvbmYKfQoKZG9fY29tcGlsZSgpIHsKCW9lX3J1bm1ha2UgJ0NYWD0k
e0NYWH0nCn0KCmRvX2luc3RhbGxfYXBwZW5kKCkgewogICAgICAgIGNobW9kICt4ICR7RH0ke2xp
YmRpcn0vbGliKgp9CgpQQUNLQUdFUyA9KyAibGliaWN1ZGF0YSBsaWJpY3V1YyBsaWJpY3VpMThu
IGxpYmljdWxlIGxpYmljdWx4IGxpYmljdXR1IGxpYmljdWlvIgoKRklMRVNfbGliaWN1ZGF0YSA9
ICIke2xpYmRpcn0vbGliaWN1ZGF0YS5zby4qIgpGSUxFU19saWJpY3V1YyA9ICIke2xpYmRpcn0v
bGliaWN1dWMuc28uKiIKRklMRVNfbGliaWN1aTE4biA9ICIke2xpYmRpcn0vbGliaWN1aTE4bi5z
by4qIgpGSUxFU19saWJpY3VsZSA9ICIke2xpYmRpcn0vbGliaWN1bGUuc28uKiIKRklMRVNfbGli
aWN1bHggPSAiJHtsaWJkaXJ9L2xpYmljdWx4LnNvLioiCkZJTEVTX2xpYmljdXR1ID0gIiR7bGli
ZGlyfS9saWJpY3V0dS5zby4qIgpGSUxFU19saWJpY3VpbyA9ICIke2xpYmRpcn0vbGliaWN1aW8u
c28uKiIKCkJCQ0xBU1NFWFRFTkQgPSAibmF0aXZlIgoKIwojIFdvcmsgYXJvdW5kIGJ1aWxkIHBy
b2JsZW1zIGZvciBCaWdFbmRpYW4gbWFjaGluZXMgKG9ubHkgUG93ZXJQQyB0ZXN0ZWQpCiMKU1JD
X1VSSV9hcHBlbmRfcG93ZXJwYyA9ICJodHRwOi8vbm90LXB1YmxpYy5jb20vbGliaWN1ZGF0YS5z
by40OC4xLmd6O25hbWU9aWN1bGliIgpTUkNfVVJJW2ljdWxpYi5tZDVzdW1dID0gImNlODNhMWVk
NWQwY2FlMGQ3NjhkYzkxNTNmMDJkODhhIgpTUkNfVVJJW2ljdWxpYi5zaGEyNTZzdW1dID0gIjMy
YzgwM2Y3MTZjZWYxY2MyNjdiMTczZjdkNTIyY2JjYzE1MGQ0NTY1YTU2ZDkzNTE1MzlmNjhlMWQ4
N2NiODUiCgpkb19pbnN0YWxsX2FwcGVuZF9wb3dlcnBjKCkgewoJaW5zdGFsbCAtbSAwNzU1ICR7
V09SS0RJUn0vbGliaWN1ZGF0YS5zby40OC4xICR7RH0vJHtsaWJkaXJ9Cn0K
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>491</attachid>
            <date>2012-04-19 15:22:06 +0000</date>
            <delta_ts>2012-04-19 15:22:06 +0000</delta_ts>
            <desc>Fix web2 segfault on ppc</desc>
            <filename>webkit-gtk-fix.patch</filename>
            <type>text/plain</type>
            <size>1532</size>
            <attacher name="Edwin Zhai">edwin.zhai</attacher>
            
              <data encoding="base64">Y29tbWl0IDJhODkwOTY3ZDg1MzZiN2Y5MDE0NTU4ZDFlMzdhNzViMDI0MDY2ZjAKQXV0aG9yOiBa
aGFpIEVkd2luIDxlZHdpbi56aGFpQGludGVsLmNvbT4KRGF0ZTogICBXZWQgQXByIDE4IDA3OjU1
OjE3IDIwMTIgKzA4MDAKCiAgICB3ZWJraXQtZ3RrOiBGaXggcnVubmluZyBlcnJvcgogICAgCiAg
ICBTaWduZWQtb2ZmLWJ5OiBaaGFpIEVkd2luIDxlZHdpbi56aGFpQGludGVsLmNvbT4KCmRpZmYg
LS1naXQgYS9tZXRhL3JlY2lwZXMtc2F0by93ZWJraXQvd2Via2l0LWd0a19zdm4uYmIgYi9tZXRh
L3JlY2lwZXMtc2F0by93ZWJraXQvd2Via2l0LWd0a19zdm4uYmIKaW5kZXggN2RiNTczZC4uMjlm
ZDE1YSAxMDA2NDQKLS0tIGEvbWV0YS9yZWNpcGVzLXNhdG8vd2Via2l0L3dlYmtpdC1ndGtfc3Zu
LmJiCisrKyBiL21ldGEvcmVjaXBlcy1zYXRvL3dlYmtpdC93ZWJraXQtZ3RrX3N2bi5iYgpAQCAt
MTAsNiArMTAsNyBAQCBMSUNfRklMRVNfQ0hLU1VNID0gImZpbGU6Ly9Tb3VyY2UvV2ViQ29yZS9y
ZW5kZXJpbmcvUmVuZGVyQXBwbGV0Lmg7ZW5kbGluZT0yMjttZAogREVQRU5EUyA9ICJ6bGliIGVu
Y2hhbnQgZ25vbWUta2V5cmluZyBsaWJzb3VwLTIuNCBjdXJsIGljdSBsaWJ4bWwyIGNhaXJvIGxp
YnhzbHQgbGlieHQgbGliaWRuIGdudXRscyBndGsrIGdzdHJlYW1lciBnc3QtcGx1Z2lucy1iYXNl
IGZsZXgtbmF0aXZlIGdwZXJmLW5hdGl2ZSBwZXJsLW5hdGl2ZS1ydW50aW1lIHNxbGl0ZTMiCiBE
RVBFTkRTICs9ICIgJHtAYmFzZV9jb250YWlucygnRElTVFJPX0ZFQVRVUkVTJywgJ29wZW5nbCcs
ICd2aXJ0dWFsL2xpYmdsJywgJycsIGQpfSIKIERFUEVORFNfZGFyd2luOCA9ICJjdXJsIGljdSBs
aWJ4bWwyIGNhaXJvIGxpYnhzbHQgbGliaWRuIGdudXRscyBndGsrIGdzdHJlYW1lciBmbGV4LW5h
dGl2ZSBncGVyZi1uYXRpdmUgcGVybC1uYXRpdmUtcnVudGltZSBzcWxpdGUzIgorREVQRU5EU19h
cHBlbmRfcWVtdXBwYyArPSAicGFuZ28iCiAKIFNSQ1JFVl9GT1JNQVQgPSAic291cmNlIgogCkBA
IC00Nyw2ICs0OCwxMyBAQCBFWFRSQV9PRUNPTkYgPSAiXAogICAgICAgICAgICAgICAgIFVOSUNP
REVfQ0ZMQUdTPS1EX1JFRU5UUkFOVCBcCiAgICAgICAgICAgICAgICAiCiAKKyNkZWZhdWx0IHVu
aWNvZGUgYmFja2VuZCBpY3UgYnJlYWtzIGluIGNyb3NzLWNvbXBpbGUgd2hlbiB0YXJnZXQgYW5k
IGhvc3Qgb3ducyBkaWZmZXJlbnQgZW5kaWFuIHR5cGUKK0VYVFJBX09FQ09ORl9hcHBlbmRfcWVt
dXBwYyArPSAiLS13aXRoLXVuaWNvZGUtYmFja2VuZD1nbGliIgorCitDUFBGTEFHU19hcHBlbmRf
cWVtdXBwYyArPSAiLUkke1NUQUdJTkdfSU5DRElSfS9wYW5nby0xLjAgXAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC1JJHtTVEFHSU5HX0xJQkRJUn0vZ2xpYi0yLjAvaW5jbHVkZSBcCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLUkke1NUQUdJTkdfSU5DRElSfS9nbGliLTIuMCIK
KwogRVhUUkFfQVVUT1JFQ09ORiA9ICIgLUkgU291cmNlL2F1dG90b29scyAiCiAKIAo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>569</attachid>
            <date>2012-06-12 11:43:19 +0000</date>
            <delta_ts>2012-06-12 11:43:19 +0000</delta_ts>
            <desc>Extend fix for all PowerPC targets</desc>
            <filename>0001-PATCH-webkit-gtk-Apply-work-around-for-all-PowerPC-t.patch</filename>
            <type>text/plain</type>
            <size>2781</size>
            <attacher name="Gary Thomas">gary</attacher>
            
              <data encoding="base64">RnJvbSA2MTQxYWM4OWY0YzU1Zjg5NjhhZWRkMTEyY2E4MjVjMzcyZjU2MTE1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBHYXJ5IFRob21hcyA8Z2FyeUBtbGJhc3NvYy5jb20+CkRhdGU6
IFR1ZSwgMTIgSnVuIDIwMTIgMDU6MzU6MjkgLTA2MDAKU3ViamVjdDogW1BBVENIXSB3ZWJraXQt
Z3RrOiBBcHBseSB3b3JrIGFyb3VuZCBmb3IgYWxsIFBvd2VyUEMKIHRhcmdldHMKClRoZSBjdXJy
ZW50IHBhdGNoIGZvciBidWcgIzE1NzAgb25seSBhcHBsaWVzIHRvIHFlbXVwcGMgYnV0IHNob3Vs
ZCBiZQphcHBsaWNhYmxlIGZvciBhbGwgUG93ZXJQQyB0YXJnZXRzLiAgQWxzbyB1cGRhdGUgdGhl
IHBhdGNoIHNvIHRoYXQKb25seSBvbmUgbGFuZ3VhZ2UgYmFja2VuZCwgZWl0aGVyIElDVSBvciBQ
QU5HTywgaXMgYnVpbHQuCgpBbHNvIHJlbW92ZSBzb21lIG9sZCBjdXN0b21pemF0aW9ucyAoZGVw
ZW5kZW5jaWVzIG9uIGRhcndpbikgYXMgdGhlc2UKc2hvdWxkIG5vdyBiZSBoYW5kbGVkIGluIGEg
bGF5ZXIgc3BlY2lmaWMgLmJiYXBwZW5kIGZpbGUuCgpTaWduZWQtb2ZmLWJ5OiBHYXJ5IFRob21h
cyA8Z2FyeUBtbGJhc3NvYy5jb20+Ci0tLQogbWV0YS9yZWNpcGVzLXNhdG8vd2Via2l0L3dlYmtp
dC1ndGtfc3ZuLmJiIHwgICAxNSArKysrKysrKystLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgOSBp
bnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL21ldGEvcmVjaXBlcy1z
YXRvL3dlYmtpdC93ZWJraXQtZ3RrX3N2bi5iYiBiL21ldGEvcmVjaXBlcy1zYXRvL3dlYmtpdC93
ZWJraXQtZ3RrX3N2bi5iYgppbmRleCA5MzgxNDg2Li43MTZhZmNlIDEwMDY0NAotLS0gYS9tZXRh
L3JlY2lwZXMtc2F0by93ZWJraXQvd2Via2l0LWd0a19zdm4uYmIKKysrIGIvbWV0YS9yZWNpcGVz
LXNhdG8vd2Via2l0L3dlYmtpdC1ndGtfc3ZuLmJiCkBAIC03LDEwICs3LDEzIEBAIExJQ19GSUxF
U19DSEtTVU0gPSAiZmlsZTovL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9SZW5kZXJBcHBsZXQu
aDtlbmRsaW5lPTIyO21kCiAgICAgICAgICAgICAgICAgICAgIGZpbGU6Ly9Tb3VyY2UvV2ViS2l0
L2d0ay93ZWJraXQvd2Via2l0Lmg7ZW5kbGluZT0yMTttZDU9YjRmYmU5ZjRhOTQ0ZjFkMDcxZGJh
MWQyYzc2YjMzNTEgXAogICAgICAgICAgICAgICAgICAgICBmaWxlOi8vU291cmNlL0phdmFTY3Jp
cHRDb3JlL3BhcnNlci9QYXJzZXIuaDtlbmRsaW5lPTIzO21kNT0yZjNjZmYwYWQwYTljNDg2ZGE1
YTM3NjkyODk3M2E5MCIKIAotREVQRU5EUyA9ICJ6bGliIGVuY2hhbnQgZ25vbWUta2V5cmluZyBs
aWJzb3VwLTIuNCBjdXJsIGljdSBsaWJ4bWwyIGNhaXJvIGxpYnhzbHQgbGlieHQgbGliaWRuIGdu
dXRscyBndGsrIGdzdHJlYW1lciBnc3QtcGx1Z2lucy1iYXNlIGZsZXgtbmF0aXZlIGdwZXJmLW5h
dGl2ZSBwZXJsLW5hdGl2ZS1ydW50aW1lIHNxbGl0ZTMiCisjIENob2ljZSBvZiBsYW5ndWFnZSBi
YWNrZW5kcyAtIGljdSBoYXMgaXNzdWVzIG9uIEJpZyBFbmRpYW4gbWFjaGluZXMgc28gdXNlIHBh
bmdvCitJQ1VfTElCID0gImljdSIKK0lDVV9MSUJfcG93ZXJwYyA9ICJwYW5nbyIKKworREVQRU5E
UyA9ICJ6bGliIGVuY2hhbnQgZ25vbWUta2V5cmluZyBsaWJzb3VwLTIuNCBjdXJsIGxpYnhtbDIg
Y2Fpcm8gbGlieHNsdCBsaWJ4dCBsaWJpZG4gZ251dGxzIFwKKyAgICAgICAgICAgZ3RrKyBnc3Ry
ZWFtZXIgZ3N0LXBsdWdpbnMtYmFzZSBmbGV4LW5hdGl2ZSBncGVyZi1uYXRpdmUgcGVybC1uYXRp
dmUtcnVudGltZSBzcWxpdGUzICR7SUNVX0xJQn0iCiBERVBFTkRTICs9ICIgJHtAYmFzZV9jb250
YWlucygnRElTVFJPX0ZFQVRVUkVTJywgJ29wZW5nbCcsICd2aXJ0dWFsL2xpYmdsJywgJycsIGQp
fSIKLURFUEVORFNfZGFyd2luOCA9ICJjdXJsIGljdSBsaWJ4bWwyIGNhaXJvIGxpYnhzbHQgbGli
aWRuIGdudXRscyBndGsrIGdzdHJlYW1lciBmbGV4LW5hdGl2ZSBncGVyZi1uYXRpdmUgcGVybC1u
YXRpdmUtcnVudGltZSBzcWxpdGUzIgotREVQRU5EU19hcHBlbmRfcWVtdXBwYyArPSAicGFuZ28i
CiAKIFNSQ1JFVl9GT1JNQVQgPSAic291cmNlIgogCkBAIC00OCwxMCArNTEsMTAgQEAgRVhUUkFf
T0VDT05GID0gIlwKICAgICAgICAgICAgICAgICBVTklDT0RFX0NGTEFHUz0tRF9SRUVOVFJBTlQg
XAogICAgICAgICAgICAgICAgIgogCi0jZGVmYXVsdCB1bmljb2RlIGJhY2tlbmQgaWN1IGJyZWFr
cyBpbiBjcm9zcy1jb21waWxlIHdoZW4gdGFyZ2V0IGFuZCBob3N0IG93bnMgZGlmZmVyZW50IGVu
ZGlhbiB0eXBlCi1FWFRSQV9PRUNPTkZfYXBwZW5kX3FlbXVwcGMgKz0gIi0td2l0aC11bmljb2Rl
LWJhY2tlbmQ9Z2xpYiIKKyNkZWZhdWx0IHVuaWNvZGUgYmFja2VuZCBpY3UgYnJlYWtzIGluIGNy
b3NzLWNvbXBpbGUgd2hlbiB0YXJnZXQgYW5kIGhvc3QgYXJlIGRpZmZlcmVudCBlbmRpYW4gdHlw
ZQorRVhUUkFfT0VDT05GX2FwcGVuZF9wb3dlcnBjICs9ICItLXdpdGgtdW5pY29kZS1iYWNrZW5k
PWdsaWIiCiAKLUNQUEZMQUdTX2FwcGVuZF9xZW11cHBjICs9ICItSSR7U1RBR0lOR19JTkNESVJ9
L3BhbmdvLTEuMCBcCitDUFBGTEFHU19hcHBlbmRfcG93ZXJwYyArPSAiLUkke1NUQUdJTkdfSU5D
RElSfS9wYW5nby0xLjAgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIC1JJHtTVEFHSU5H
X0xJQkRJUn0vZ2xpYi0yLjAvaW5jbHVkZSBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LUkke1NUQUdJTkdfSU5DRElSfS9nbGliLTIuMCIKIAotLSAKMS43LjcuNgoK
</data>

          </attachment>
      

    </bug>

</bugzilla>