<?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>2299</bug_id>
          
          <creation_ts>2012-04-14 12:25:59 +0000</creation_ts>
          <short_desc>pseudo-nativesdk: libpseudo.so can not find GLIBC_2.14</short_desc>
          <delta_ts>2012-04-25 08:26:04 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>6</classification_id>
          <classification>Yocto Project Subprojects</classification>
          <product>ADT</product>
          <component>kernel analysis</component>
          <version>1.2</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Multiple</op_sys>
          <bug_status>VERIFIED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard>Working 70% (1.2)</status_whiteboard>
          <keywords></keywords>
          <priority>High</priority>
          <bug_severity>major</bug_severity>
          <target_milestone>1.2 M4</target_milestone>
          
          <blocked>2351</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Robert Yang">liezhi.yang</reporter>
          <assigned_to name="Seebs">seebs</assigned_to>
          <cc>hongnax.xu</cc>
    
    <cc>jessica.zhang</cc>
    
    <cc>lianhao.lu</cc>
    
    <cc>mark.hatle</cc>
    
    <cc>meta.mr.watcher</cc>
    
    <cc>meta.watcher</cc>
    
    <cc>richard.purdie</cc>
    
    <cc>seebs</cc>
    
    <cc>sgw</cc>
    
    <cc>yp.sdk.watcher</cc>
    
    <cc>yp.watcher</cc>
    
    <cc>zhenfeng.zhao</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>---</cf_regression_type>
          
          <cf_docchange>---</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>20369</commentid>
    <comment_count>0</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2012-04-14 12:25:59 +0000</bug_when>
    <thetext>The libpseudo.so lacks rpath so it can&apos;t work correctly:

$ ldd /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so 
/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so: /lib64/libc.so.6: version `GLIBC_2.14&apos; not found (required by /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so)
        linux-vdso.so.1 =&gt;  (0x00007fff6a9e6000)
        libdl.so.2 =&gt; /lib64/libdl.so.2 (0x00007f070dd69000)
        libpthread.so.0 =&gt; /lib64/libpthread.so.0 (0x00007f070db4d000)
        libc.so.6 =&gt; /lib64/libc.so.6 (0x00007f070d7ce000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003908a00000)

It uses the libs in the host, and can&apos;t find GLIBC_2.14 when the host&apos;s libc.so.6 doesn&apos;t provide it.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20379</commentid>
    <comment_count>1</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2012-04-14 15:11:13 +0000</bug_when>
    <thetext>More information:

This is because the /lib64/libc.so.6 loaded before /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 when the pseudo runs,
export LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 would fix the problem, a solution maybe use a wrapper for pseudo, for example:

mv pseudo pseudo.real
echo LD_PREPLOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 pseudo $@ &gt; pseudo</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20380</commentid>
    <comment_count>2</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2012-04-14 15:39:13 +0000</bug_when>
    <thetext>(In reply to comment #1)
&gt; More information:
&gt; 
&gt; This is because the /lib64/libc.so.6 loaded before
&gt; /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 when the
&gt; pseudo runs,
&gt; export
&gt; LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
&gt; would fix the problem, a solution maybe use a wrapper for pseudo, for example:
&gt; 
&gt; mv pseudo pseudo.real
&gt; echo
&gt; LD_PREPLOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
&gt; pseudo $@ &gt; pseudo

Put the following two lines in the wrapper doesn&apos;t work:
export LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
pseudo.real $@

But manually:
export LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
works.

I guess that this is because the shell has loaded the host&apos;s libc.so.6, so
put the LD_PRELOAD in the wrapper doesn&apos;t work. Need help, anyone who is interested on
it please feel free to take it.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20399</commentid>
    <comment_count>3</comment_count>
      <attachid>474</attachid>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2012-04-15 10:47:05 +0000</bug_when>
    <thetext>Created attachment 474
can not find GLIBC_2.14

This patch is still in testing.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20400</commentid>
    <comment_count>4</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2012-04-15 10:48:19 +0000</bug_when>
    <thetext>Update information:

It is caused by the --libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS}, this makes pseudo search every library that it needs in ${prefix}/lib/pseudo/lib{SITEINFO_BITS} firstly, and if not found, it would seasch in the system libdir, our libc.so.6 is in ${prefix}/lib/, not in ${prefix}/lib/pseudo/lib${SITEINFO_BITS}, so it can&apos;t found our libc.so.6, and will use the one on the host, so the error comes, there is a draft patch, I&apos;m still testing it before send the patch review, any suggestions is appreciated:

I don&apos;t know why we installed the libpseudo.so to ${prefix}/lib/pseudo/lib, so I fixed
the pseudo-native, pseudo-nativesdk and the target pseudo, this seems dangerous at the current stage, I&apos;d like to only fix pseudo-nativesdk, in fact.

The patch is in the attachment(still in testing):

https://bugzilla.yoctoproject.org/attachment.cgi?id=474</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20402</commentid>
    <comment_count>5</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-15 14:29:47 +0000</bug_when>
    <thetext>I had a look into this problem. Even if we change pseudo so the correct rpath is in both the pseduo binary and in libpseudo itself, the problem still occurs since tar loads the libc from the system path.

I think your change happens to work since pseudo persists the LD_LIBRARY_PATH which happens to make things work.

I&apos;m wondering if we set LD_LIBRARY_PATH in a wrapper for pseudo, whether that will fix things...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20403</commentid>
    <comment_count>6</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-15 15:01:06 +0000</bug_when>
    <thetext>I&apos;ve posted a patch for review on the oe-core mailing list.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20404</commentid>
    <comment_count>7</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2012-04-15 15:27:16 +0000</bug_when>
    <thetext>(In reply to comment #6)
&gt; I&apos;ve posted a patch for review on the oe-core mailing list.
Thank you very much, I&apos;ve tried to edit: 
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/oe-find-native-sysroot
with your suggestion:

Change:
PSEUDO=&quot;$OECORE_NATIVE_SYSROOT/usr/bin/pseudo&quot;
to:
PSEUDO=&quot;env LD_LIBRARY_PATH=$OECORE_NATIVE_SYSROOT/lib $OECORE_NATIVE_SYSROOT/usr/bin/pseudo&quot;

Then it works.

I will build a new sdk with your patch which seems better tonight, and will reply the
testing result tomorrow.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20409</commentid>
    <comment_count>8</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-15 17:15:15 +0000</bug_when>
    <thetext>Fix merged into master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f562e2a393d69312281ceda1d2b2b0af03a8c8b5</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20448</commentid>
    <comment_count>9</comment_count>
    <who name="Mark Hatle">mark.hatle</who>
    <bug_when>2012-04-16 15:05:16 +0000</bug_when>
    <thetext>FYI the proposed patch in comment #4 is incorrect.

pseudo wrapper belongs in a sub directory location.  This is because we do not know if the host sysroot &quot;/lib&quot; is 32-bit or 64-bit.  We have to have a way to distinguish between the two.  Also we do not want to impact the system&apos;s LD_LIBRARY_PATH, unless the users really want that (by specifying as the patch from Richard does.)

In short, the pseudo wrapper library must be somewhere that is not normally searched by the system library routines.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20466</commentid>
    <comment_count>10</comment_count>
    <who name="Seebs">seebs</who>
    <bug_when>2012-04-16 17:47:09 +0000</bug_when>
    <thetext>I&apos;m really confused by this, simply because I thought pseudo was nearly-always using host libc.  Are we building a local native libc that&apos;s newer than host libc?  If so, that&apos;s outside my original plan, and yes, we&apos;d need to do something fancy.  We don&apos;t want libpseudo.so to be in the directory providing the new libc, I don&apos;t think.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20476</commentid>
    <comment_count>11</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-16 21:24:24 +0000</bug_when>
    <thetext>(In reply to comment #10)
&gt; I&apos;m really confused by this, simply because I thought pseudo was nearly-always
&gt; using host libc.  Are we building a local native libc that&apos;s newer than host
&gt; libc?  If so, that&apos;s outside my original plan, and yes, we&apos;d need to do
&gt; something fancy.

Yes, we build a libc that is equal or newer than the host libc.

&gt;  We don&apos;t want libpseudo.so to be in the directory providing
&gt; the new libc, I don&apos;t think.

We install it into a separate subdir as in the native and target cases.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20779</commentid>
    <comment_count>12</comment_count>
    <who name="Lianhao Lu">lianhao.lu</who>
    <bug_when>2012-04-20 07:25:10 +0000</bug_when>
    <thetext>On FC16 32bit, the fixing in comment #8 will result a segmentation fault in tar.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20787</commentid>
    <comment_count>13</comment_count>
    <who name="Seebs">seebs</who>
    <bug_when>2012-04-20 15:41:59 +0000</bug_when>
    <thetext>Not sure, but is the segfault there maybe fixed by the since-proposed change to create_wrapper which removes the attempt to &quot;test&quot; the variable assignments?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20788</commentid>
    <comment_count>14</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-20 16:16:50 +0000</bug_when>
    <thetext>No, the change to create_wrapper will have zero effect on this issue :(</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20799</commentid>
    <comment_count>15</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-22 11:14:25 +0000</bug_when>
    <thetext>Taking a step back here a second, the issue is that we need to be able to use libpseudo on systems with an older host libc even if the native libc is newer. The problem, is that when compiled against a newer libc, there are &quot;GLIBC_2.14&quot; symbols which cause it to fail on an older libc.

We&apos;ve demonstrated in the other open pseudo bug that we can&apos;t mix one dynamic loader with another libc, this is bad and hence we need to remove the workaround added in the pseudo wrapper. Looking at the libc code, its clear they&apos;re incestuous and can&apos;t be independent. 

Would one solution be to force libpseudo to use older symbol versions? We could do this by adding:

__asm__(&quot;.symver memcpy,memcpy@GLIBC_2.2.5&quot;);

into the pseudo code. I mention memcpy specifically as its the only 2.14 symbol used, the next oldest is GLIBC_2.7 for which there are two references, then we&apos;re back to 2.3.4 (output from objdump -T libpseudo.so).

So the proposal is to:
a) Drop the LD_LIBRBARY_PATH
b) Have libpseudo.so use older symbol versioning for memcpy</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20835</commentid>
    <comment_count>16</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2012-04-24 09:24:41 +0000</bug_when>
    <thetext>Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=604fc2adce743294cbad631993ce17e7bfcf17ab and also applied to the denzil branch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>20862</commentid>
    <comment_count>17</comment_count>
    <who name="Hongna Xu">hongnax.xu</who>
    <bug_when>2012-04-25 08:26:04 +0000</bug_when>
    <thetext>Got fixed and verify on poky/denzil:35196ff703726addf7f4051ee09d70bf9ee0c5d0</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>474</attachid>
            <date>2012-04-15 10:47:05 +0000</date>
            <delta_ts>2012-04-15 10:47:05 +0000</delta_ts>
            <desc>can not find GLIBC_2.14</desc>
            <filename>0001-pseudo-nativesdk-libpseudo.so-can-t-find-GLIBC_2.14.patch</filename>
            <type>text/plain</type>
            <size>6742</size>
            <attacher name="Robert Yang">liezhi.yang</attacher>
            
              <data encoding="base64">RnJvbSBlYzk1YmQ0OGNlYjMwMzYxOGRjOGFiMGVlMDg3YWVhNTJlMDdlMWNmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBSb2JlcnQgWWFuZyA8bGllemhpLnlhbmdAd2luZHJpdmVyLmNv
bT4KRGF0ZTogU3VuLCAxNSBBcHIgMjAxMiAxNzo0MjoxOCArMDgwMApTdWJqZWN0OiBbUEFUQ0hd
IHBzZXVkby1uYXRpdmVzZGs6IGxpYnBzZXVkby5zbyBjYW4ndCBmaW5kIEdMSUJDXzIuMTQKClRo
ZSBsaWJwc2V1ZG8uc28gaW4gdGhlIFNESyBjYW4ndCBmaW5kIEdMSUJDXzIuMTQgaWYgdGhlIGhv
c3QgZG9lc24ndApwcm92aWRlIGl0LCBJdCBpcyBjYXVzZWQgYnkgdGhlCi0tbGliZGlyPSR7cHJl
Zml4fS9saWIvcHNldWRvL2xpYiR7U0lURUlORk9fQklUU30sIHRoaXMgbWFrZXMgcHNldWRvCnNl
YXJjaCBldmVyeSBsaWJyYXJ5IHRoYXQgaXQgbmVlZHMgaW4KJHtwcmVmaXh9L2xpYi9wc2V1ZG8v
bGlie1NJVEVJTkZPX0JJVFN9IGZpcnN0bHksIGFuZCBpZiBub3QgZm91bmQsIGl0CndvdWxkIHNl
YXNjaCBpbiB0aGUgc3lzdGVtIGxpYmRpciwgb3VyIGxpYmMuc28uNiBpcyBpbiAke3ByZWZpeH0v
bGliLywKbm90IGluICR7cHJlZml4fS9saWIvcHNldWRvL2xpYiR7U0lURUlORk9fQklUU30sIHNv
IGl0IGNhbid0IGZvdW5kIG91cgpsaWJjLnNvLjYsIGFuZCB3aWxsIHVzZSB0aGUgb25lIG9uIHRo
ZSBob3N0LCBzbyB0aGUgZXJyb3IgY29tZXMuCgpVc2UgcmlnaHQgLS1saWJkaXIgd291bGQgZml4
IHRoZSBwcm9ibGVtLgoKW1lPQ1RPICMyMjk5XQoKU2lnbmVkLW9mZi1ieTogUm9iZXJ0IFlhbmcg
PGxpZXpoaS55YW5nQHdpbmRyaXZlci5jb20+Ci0tLQogbWV0YS9yZWNpcGVzLWRldnRvb2xzL3Bz
ZXVkby9wc2V1ZG8uaW5jICAgIHwgICAzMCArKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0KIG1l
dGEvcmVjaXBlcy1kZXZ0b29scy9wc2V1ZG8vcHNldWRvXzEuMy5iYiB8ICAgIDIgKy0KIG1ldGEv
cmVjaXBlcy1kZXZ0b29scy9wc2V1ZG8vcHNldWRvX2dpdC5iYiB8ICAgIDIgKy0KIHNjcmlwdHMv
Yml0YmFrZSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIDQgZmlsZXMgY2hh
bmdlZCwgMjEgaW5zZXJ0aW9ucygrKSwgMTUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbWV0
YS9yZWNpcGVzLWRldnRvb2xzL3BzZXVkby9wc2V1ZG8uaW5jIGIvbWV0YS9yZWNpcGVzLWRldnRv
b2xzL3BzZXVkby9wc2V1ZG8uaW5jCmluZGV4IGQ3MTAwNTguLmEzYzZkMzMgMTAwNjQ0Ci0tLSBh
L21ldGEvcmVjaXBlcy1kZXZ0b29scy9wc2V1ZG8vcHNldWRvLmluYworKysgYi9tZXRhL3JlY2lw
ZXMtZGV2dG9vbHMvcHNldWRvL3BzZXVkby5pbmMKQEAgLTI5LDkgKzI5LDkgQEAgTk8zMkxJQlMg
Pz89ICIxIgogIyBDb21waWxlIGZvciB0aGUgbG9jYWwgbWFjaGluZSBhcmNoLi4uCiBkb19jb21w
aWxlICgpIHsKIAlpZiBbICIke1NJVEVJTkZPX0JJVFN9IiA9PSAiNjQiIF07IHRoZW4KLQkgICR7
U30vY29uZmlndXJlIC0tcHJlZml4PSR7cHJlZml4fSAtLWxpYmRpcj0ke3ByZWZpeH0vbGliL3Bz
ZXVkby9saWIke1NJVEVJTkZPX0JJVFN9IC0td2l0aC1zcWxpdGU9JHtTVEFHSU5HX0RJUl9UQVJH
RVR9JHtleGVjX3ByZWZpeH0gLS1iaXRzPSR7U0lURUlORk9fQklUU30gLS1lbmFibGUtc3RhdGlj
LXNxbGl0ZSAtLXdpdGhvdXQtcnBhdGgKKwkgICR7U30vY29uZmlndXJlIC0tcHJlZml4PSR7cHJl
Zml4fSAtLWxpYmRpcj0ke3ByZWZpeH0vbGlie1NJVEVJTkZPX0JJVFN9IC0td2l0aC1zcWxpdGU9
JHtTVEFHSU5HX0RJUl9UQVJHRVR9JHtleGVjX3ByZWZpeH0gLS1iaXRzPSR7U0lURUlORk9fQklU
U30gLS1lbmFibGUtc3RhdGljLXNxbGl0ZSAtLXdpdGhvdXQtcnBhdGgKIAllbHNlCi0JICAke1N9
L2NvbmZpZ3VyZSAtLXByZWZpeD0ke3ByZWZpeH0gLS1saWJkaXI9JHtwcmVmaXh9L2xpYi9wc2V1
ZG8vbGliIC0td2l0aC1zcWxpdGU9JHtTVEFHSU5HX0RJUl9UQVJHRVR9JHtleGVjX3ByZWZpeH0g
LS1iaXRzPSR7U0lURUlORk9fQklUU30gLS1lbmFibGUtc3RhdGljLXNxbGl0ZSAtLXdpdGhvdXQt
cnBhdGgKKwkgICR7U30vY29uZmlndXJlIC0tcHJlZml4PSR7cHJlZml4fSAtLWxpYmRpcj0ke3By
ZWZpeH0vbGliIC0td2l0aC1zcWxpdGU9JHtTVEFHSU5HX0RJUl9UQVJHRVR9JHtleGVjX3ByZWZp
eH0gLS1iaXRzPSR7U0lURUlORk9fQklUU30gLS1lbmFibGUtc3RhdGljLXNxbGl0ZSAtLXdpdGhv
dXQtcnBhdGgKIAlmaQogCW9lX3J1bm1ha2UgJHtNQUtFT1BUU30KIH0KQEAgLTM5LDI4ICszOSwz
NCBAQCBkb19jb21waWxlICgpIHsKICMgVHdvIGJlbG93IGFyZSB0aGUgc2FtZQogIyBJZiBuZWNl
c3NhcnkgY29tcGlsZSBmb3IgdGhlIGFsdGVybmF0aXZlIG1hY2hpbmUgYXJjaC4gIFRoaXMgaXMg
b25seSAKICMgbmVjZXNzYXJ5IGluIGEgbmF0aXZlIGJ1aWxkLgotZG9fY29tcGlsZV9wcmVwZW5k
X3ZpcnRjbGFzcy1uYXRpdmUgKCkgeworZG9fY29tcGlsZV92aXJ0Y2xhc3MtbmF0aXZlICgpIHsK
IAlpZiBbICIke1NJVEVJTkZPX0JJVFN9IiA9PSAiNjQiIC1hIC1lICIvdXNyL2luY2x1ZGUvZ251
L3N0dWJzLTMyLmgiIC1hICIke1BOfSIgPT0gInBzZXVkby1uYXRpdmUiIC1hICIke05PMzJMSUJT
fSIgIT0gIjEiIF07IHRoZW4KIAkJIyBXZSBuZWVkIHRoZSAzMi1iaXQgbGlicHNldWRvIG9uIGEg
NjQtYml0IG1hY2hpbmUuLi4KLQkJLi9jb25maWd1cmUgLS1wcmVmaXg9JHtwcmVmaXh9IC0tbGli
ZGlyPSR7cHJlZml4fS9saWIvcHNldWRvL2xpYiAtLXdpdGgtc3FsaXRlPSR7U1RBR0lOR19ESVJf
VEFSR0VUfSR7ZXhlY19wcmVmaXh9IC0tYml0cz0zMiAtLXdpdGhvdXQtcnBhdGgKKwkJLi9jb25m
aWd1cmUgLS1wcmVmaXg9JHtwcmVmaXh9IC0tbGliZGlyPSR7cHJlZml4fS9saWIgLS13aXRoLXNx
bGl0ZT0ke1NUQUdJTkdfRElSX1RBUkdFVH0ke2V4ZWNfcHJlZml4fSAtLWJpdHM9MzIgLS13aXRo
b3V0LXJwYXRoCiAJCW9lX3J1bm1ha2UgJHtNQUtFT1BUU30gbGlicHNldWRvCiAJCSMgcHJldmVu
dCBpdCBmcm9tIHJlbW92aW5nIHRoZSBsaWIsIGJ1dCByZW1vdmUgZXZlcnl0aGluZyBlbHNlCiAJ
CW1ha2UgJ0xJQj1mb28nICR7TUFLRU9QVFN9IGRpc3RjbGVhbiAKKwllbHNlCisJICAke1N9L2Nv
bmZpZ3VyZSAtLXByZWZpeD0ke3ByZWZpeH0gLS1saWJkaXI9JHtwcmVmaXh9L2xpYiAtLXdpdGgt
c3FsaXRlPSR7U1RBR0lOR19ESVJfVEFSR0VUfSR7ZXhlY19wcmVmaXh9IC0tYml0cz0ke1NJVEVJ
TkZPX0JJVFN9IC0tZW5hYmxlLXN0YXRpYy1zcWxpdGUgLS13aXRob3V0LXJwYXRoCiAJZmkKKwlv
ZV9ydW5tYWtlICR7TUFLRU9QVFN9CiB9CiAKLWRvX2NvbXBpbGVfcHJlcGVuZF92aXJ0Y2xhc3Mt
bmF0aXZlc2RrICgpIHsKLQlpZiBbICIke1NJVEVJTkZPX0JJVFN9IiA9PSAiNjQiIC1hIC1lICIv
dXNyL2luY2x1ZGUvZ251L3N0dWJzLTMyLmgiIC1hICIke1BOfSIgPT0gInBzZXVkby1uYXRpdmUi
IC1hICIke05PMzJMSUJTfSIgIT0gIjEiIF07IHRoZW4KK2RvX2NvbXBpbGVfdmlydGNsYXNzLW5h
dGl2ZXNkayAoKSB7CisJaWYgWyAiJHtTSVRFSU5GT19CSVRTfSIgPT0gIjY0IiAtYSAtZSAiL3Vz
ci9pbmNsdWRlL2dudS9zdHVicy0zMi5oIiAtYSAiJHtQTn0iID09ICJwc2V1ZG8tbmF0aXZlc2Rr
IiAtYSAiJHtOTzMyTElCU30iICE9ICIxIiBdOyB0aGVuCiAJCSMgV2UgbmVlZCB0aGUgMzItYml0
IGxpYnBzZXVkbyBvbiBhIDY0LWJpdCBtYWNoaW5lLi4uCi0JCS4vY29uZmlndXJlIC0tcHJlZml4
PSR7cHJlZml4fSAtLWxpYmRpcj0ke3ByZWZpeH0vbGliL3BzZXVkby9saWIgLS13aXRoLXNxbGl0
ZT0ke1NUQUdJTkdfRElSX1RBUkdFVH0ke2V4ZWNfcHJlZml4fSAtLWJpdHM9MzIgLS13aXRob3V0
LXJwYXRoCisJCS4vY29uZmlndXJlIC0tcHJlZml4PSR7cHJlZml4fSAtLWxpYmRpcj0ke3ByZWZp
eH0vbGliIC0td2l0aC1zcWxpdGU9JHtTVEFHSU5HX0RJUl9UQVJHRVR9JHtleGVjX3ByZWZpeH0g
LS1iaXRzPTMyIC0td2l0aG91dC1ycGF0aAogCQlvZV9ydW5tYWtlICR7TUFLRU9QVFN9IGxpYnBz
ZXVkbwogCQkjIHByZXZlbnQgaXQgZnJvbSByZW1vdmluZyB0aGUgbGliLCBidXQgcmVtb3ZlIGV2
ZXJ5dGhpbmcgZWxzZQogCQltYWtlICdMSUI9Zm9vJyAke01BS0VPUFRTfSBkaXN0Y2xlYW4gCisJ
ZWxzZQorCSAgJHtTfS9jb25maWd1cmUgLS1wcmVmaXg9JHtwcmVmaXh9IC0tbGliZGlyPSR7cHJl
Zml4fS9saWIgLS13aXRoLXNxbGl0ZT0ke1NUQUdJTkdfRElSX1RBUkdFVH0ke2V4ZWNfcHJlZml4
fSAtLWJpdHM9JHtTSVRFSU5GT19CSVRTfSAtLWVuYWJsZS1zdGF0aWMtc3FsaXRlIC0td2l0aG91
dC1ycGF0aAogCWZpCisJb2VfcnVubWFrZSAke01BS0VPUFRTfQogfQogCiBkb19pbnN0YWxsICgp
IHsKLQlvZV9ydW5tYWtlICdERVNURElSPSR7RH0nICR7TUFLRU9QVFN9ICdMSUI9bGliL3BzZXVk
by9saWIkKE1BUks2NCknIGluc3RhbGwKKwlvZV9ydW5tYWtlICdERVNURElSPSR7RH0nICR7TUFL
RU9QVFN9IGluc3RhbGwKIH0KIAogIyBUd28gYmVsb3cgYXJlIHRoZSBzYW1lCkBAIC02OCwxNSAr
NzQsMTUgQEAgZG9faW5zdGFsbCAoKSB7CiAjIG5lY2Vzc2FyeSBpbiBhIG5hdGl2ZSBidWlsZC4K
IGRvX2luc3RhbGxfYXBwZW5kX3ZpcnRjbGFzcy1uYXRpdmUgKCkgewogCWlmIFsgIiR7U0lURUlO
Rk9fQklUU30iID09ICI2NCIgLWEgLWUgIi91c3IvaW5jbHVkZS9nbnUvc3R1YnMtMzIuaCIgLWEg
IiR7UE59IiA9PSAicHNldWRvLW5hdGl2ZSIgLWEgIiR7Tk8zMkxJQlN9IiAhPSAiMSIgXTsgdGhl
bgotCQlta2RpciAtcCAke0R9JHtwcmVmaXh9L2xpYi9wc2V1ZG8vbGliCi0JCWNwIGxpYi9wc2V1
ZG8vbGliL2xpYnBzZXVkby5zbyAke0R9JHtwcmVmaXh9L2xpYi9wc2V1ZG8vbGliLy4KKwkJbWtk
aXIgLXAgJHtEfSR7cHJlZml4fS9saWIKKwkJY3AgbGliL2xpYnBzZXVkby5zbyAke0R9JHtwcmVm
aXh9L2xpYi8uCiAJZmkKIH0KIAogZG9faW5zdGFsbF9hcHBlbmRfdmlydGNsYXNzLW5hdGl2ZXNk
ayAoKSB7CiAJaWYgWyAiJHtTSVRFSU5GT19CSVRTfSIgPT0gIjY0IiAtYSAtZSAiL3Vzci9pbmNs
dWRlL2dudS9zdHVicy0zMi5oIiAtYSAiJHtQTn0iID09ICJwc2V1ZG8tbmF0aXZlIiAtYSAiJHtO
TzMyTElCU30iICE9ICIxIiBdOyB0aGVuCi0JCW1rZGlyIC1wICR7RH0ke3ByZWZpeH0vbGliL3Bz
ZXVkby9saWIKLQkJY3AgbGliL3BzZXVkby9saWIvbGlicHNldWRvLnNvICR7RH0ke3ByZWZpeH0v
bGliL3BzZXVkby9saWIvLgorCQlta2RpciAtcCAke0R9JHtwcmVmaXh9L2xpYgorCQljcCBsaWIv
bGlicHNldWRvLnNvICR7RH0ke3ByZWZpeH0vbGliLy4KIAlmaQogfQogCmRpZmYgLS1naXQgYS9t
ZXRhL3JlY2lwZXMtZGV2dG9vbHMvcHNldWRvL3BzZXVkb18xLjMuYmIgYi9tZXRhL3JlY2lwZXMt
ZGV2dG9vbHMvcHNldWRvL3BzZXVkb18xLjMuYmIKaW5kZXggMDgwYjczOS4uYjE2YjJkOSAxMDA2
NDQKLS0tIGEvbWV0YS9yZWNpcGVzLWRldnRvb2xzL3BzZXVkby9wc2V1ZG9fMS4zLmJiCisrKyBi
L21ldGEvcmVjaXBlcy1kZXZ0b29scy9wc2V1ZG8vcHNldWRvXzEuMy5iYgpAQCAtMSw2ICsxLDYg
QEAKIHJlcXVpcmUgcHNldWRvLmluYwogCi1QUiA9ICJyOCIKK1BSID0gInI5IgogCiBTUkNfVVJJ
ID0gImh0dHA6Ly93d3cueW9jdG9wcm9qZWN0Lm9yZy9kb3dubG9hZHMvJHtCUE59LyR7QlBOfS0k
e1BWfS50YXIuYnoyIgogCmRpZmYgLS1naXQgYS9tZXRhL3JlY2lwZXMtZGV2dG9vbHMvcHNldWRv
L3BzZXVkb19naXQuYmIgYi9tZXRhL3JlY2lwZXMtZGV2dG9vbHMvcHNldWRvL3BzZXVkb19naXQu
YmIKaW5kZXggNzg1NzI3NS4uNTc3MTI5NSAxMDA2NDQKLS0tIGEvbWV0YS9yZWNpcGVzLWRldnRv
b2xzL3BzZXVkby9wc2V1ZG9fZ2l0LmJiCisrKyBiL21ldGEvcmVjaXBlcy1kZXZ0b29scy9wc2V1
ZG8vcHNldWRvX2dpdC5iYgpAQCAtMiw3ICsyLDcgQEAgcmVxdWlyZSBwc2V1ZG8uaW5jCiAKIFNS
Q1JFViA9ICJmMDM3NWM5YWFlZmJjY2ZkNDFhZWJiZjZkMzMyYmI0ZDllOGY5ODBjIgogUFYgPSAi
MS4zK2dpdCR7U1JDUFZ9IgotUFIgPSAicjIzIgorUFIgPSAicjI0IgogCiBERUZBVUxUX1BSRUZF
UkVOQ0UgPSAiLTEiCiAKZGlmZiAtLWdpdCBhL3NjcmlwdHMvYml0YmFrZSBiL3NjcmlwdHMvYml0
YmFrZQppbmRleCAzNzcyZDgyLi43Nzc3ZTQ4IDEwMDc1NQotLS0gYS9zY3JpcHRzL2JpdGJha2UK
KysrIGIvc2NyaXB0cy9iaXRiYWtlCkBAIC0xNTIsNyArMTUyLDcgQEAgQklUQkFLRT1gd2hpY2gg
Yml0YmFrZWAKIGV4cG9ydCBQQVRIPSRPTERQQVRICiBpZiBbICRuZWVkcHNldWRvID0gIjEiIF07
IHRoZW4KICAgICBleHBvcnQgUFNFVURPX0JVSUxEPTIKLSAgICBQU0VVRE9fQklORElSPSRQU0VV
RE9CSU5ESVIgUFNFVURPX0xJQkRJUj0kUFNFVURPQklORElSLy4uL2xpYi9wc2V1ZG8vbGliIFBT
RVVET19QUkVGSVg9JFBTRVVET0JJTkRJUi8uLi8uLi8gUFNFVURPX0RJU0FCTEVEPTEgJFBTRVVE
T0JJTkRJUi9wc2V1ZG8gJEJJVEJBS0UgJEAKKyAgICBQU0VVRE9fQklORElSPSRQU0VVRE9CSU5E
SVIgUFNFVURPX0xJQkRJUj0kUFNFVURPQklORElSLy4uL2xpYiBQU0VVRE9fUFJFRklYPSRQU0VV
RE9CSU5ESVIvLi4vLi4vIFBTRVVET19ESVNBQkxFRD0xICRQU0VVRE9CSU5ESVIvcHNldWRvICRC
SVRCQUtFICRACiBlbHNlCiAgICAgZXhwb3J0IFBTRVVET19CVUlMRD0wCiAgICAgJEJJVEJBS0Ug
JEAKLS0gCjEuNy4zLjQKCg==
</data>

          </attachment>
      

    </bug>

</bugzilla>