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

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>109969</bug_id>
          
          <creation_ts>2013-02-15 13:40:53 -0800</creation_ts>
          <short_desc>[GTK] Improve gyp build JavaScriptCore code generation</short_desc>
          <delta_ts>2013-02-19 13:55:46 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebKitGTK</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          <dependson>109960</dependson>
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Martin Robinson">mrobinson</reporter>
          <assigned_to name="Martin Robinson">mrobinson</assigned_to>
          <cc>dpranke</cc>
    
    <cc>gustavo</cc>
    
    <cc>pnormand</cc>
    
    <cc>thakis</cc>
    
    <cc>webkit.review.bot</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>834346</commentid>
    <comment_count>0</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-15 13:40:53 -0800</bug_when>
    <thetext>In bug https://bugs.webkit.org/show_bug.cgi?id=109003#c19 Nico suggested a way to improve the code generation for the JavaScriptCore part of the GTK+ gyp build.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>834417</commentid>
    <comment_count>1</comment_count>
      <attachid>188650</attachid>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-15 15:19:22 -0800</bug_when>
    <thetext>Created attachment 188650
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>834549</commentid>
    <comment_count>2</comment_count>
      <attachid>188650</attachid>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2013-02-15 17:42:46 -0800</bug_when>
    <thetext>Comment on attachment 188650
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=188650&amp;action=review

This looks basically okay but I&apos;m not knowledgeable enough about the JSC build process to be sure that this is the best way to do this ...

&gt; Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCoreGTK.gyp:93
&gt; +          &apos;../runtime/StringPrototype.cpp&apos;,

If you&apos;re concerned about this list being duplicated between here and JavaScriptCore.gypi, you can define this list as a variable in JavaScriptCore.gypi and include it from both places.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>834550</commentid>
    <comment_count>3</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2013-02-15 17:43:18 -0800</bug_when>
    <thetext>If no one else wants to take a look at this, I&apos;ll take another look in more detail to try and understand it better ...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>834569</commentid>
    <comment_count>4</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-15 18:03:39 -0800</bug_when>
    <thetext>(In reply to comment #2)
&gt; (From update of attachment 188650 [details])
&gt; View in context: https://bugs.webkit.org/attachment.cgi?id=188650&amp;action=review
&gt; 
&gt; This looks basically okay but I&apos;m not knowledgeable enough about the JSC build process to be sure that this is the best way to do this ...
&gt; 
&gt; &gt; Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCoreGTK.gyp:93
&gt; &gt; +          &apos;../runtime/StringPrototype.cpp&apos;,
&gt; 
&gt; If you&apos;re concerned about this list being duplicated between here and JavaScriptCore.gypi, you can define this list as a variable in JavaScriptCore.gypi and include it from both places.

The issue is that the rule seems to require paths realtive to this gyp file. Now that I look at this again, it seems that I can just prepend ../ to the &lt;(RULE_INPUT_PATH) part of the invocation. I&apos;ll fix this. :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>834883</commentid>
    <comment_count>5</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-16 16:30:45 -0800</bug_when>
    <thetext>So it seems that there is no way to avoid duplicating the list twice. The paths in JavaScriptCore.gypi are relative to the JavaScriptCore.gypi file, but the rule requires paths relative to JavaScriptCoreGTK.gyp. I&apos;m not sure how to remedy this. Prepending &quot;../&quot; doesn&apos;t fix it, because by the time the filename has transformed into &lt;(RULE_INPUT_PATH) it&apos;s already been resolve relative to the top-level of the project.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>835269</commentid>
    <comment_count>6</comment_count>
      <attachid>188650</attachid>
    <who name="Nico Weber">thakis</who>
    <bug_when>2013-02-18 02:40:35 -0800</bug_when>
    <thetext>Comment on attachment 188650
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=188650&amp;action=review

Looks pretty good!

&gt;&gt;&gt; Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCoreGTK.gyp:93
&gt;&gt;&gt; +          &apos;../runtime/StringPrototype.cpp&apos;,
&gt;&gt; 
&gt;&gt; If you&apos;re concerned about this list being duplicated between here and JavaScriptCore.gypi, you can define this list as a variable in JavaScriptCore.gypi and include it from both places.
&gt; 
&gt; The issue is that the rule seems to require paths realtive to this gyp file. Now that I look at this again, it seems that I can just prepend ../ to the &lt;(RULE_INPUT_PATH) part of the invocation. I&apos;ll fix this. :)

There&apos;s also the magic &lt;(DEPTH) variable that you can use for file lists in gypi files.

&gt; Source/JavaScriptCore/JavaScriptCore.gyp/redirect-stdout.sh:4
&gt; +$@ &gt; $OUTPUT_FILE

You can do `exec $1 &gt; $2` here, if you write &apos;python &lt;@(_inputs)&apos; as a single string in the gyp files. (or $2 &gt; $1 if you prefer putting the output file before the command, but having `command output` matches bash order and also happens to be consistent with a similar script in chromium land.) (the `exec` saves you one process.)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>835853</commentid>
    <comment_count>7</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-18 17:29:51 -0800</bug_when>
    <thetext>(In reply to comment #6)
 
Thanks for the comments!

&gt; &gt; The issue is that the rule seems to require paths realtive to this gyp file. Now that I look at this again, it seems that I can just prepend ../ to the &lt;(RULE_INPUT_PATH) part of the invocation. I&apos;ll fix this. :)
&gt; 
&gt; There&apos;s also the magic &lt;(DEPTH) variable that you can use for file lists in gypi files.

Hrm. I think I&apos;ll stick with the source list rather than &lt;(DEPTH). It&apos;s been very tricky getting out-of-tree builds working for the make generator [1].

&gt; 
&gt; &gt; Source/JavaScriptCore/JavaScriptCore.gyp/redirect-stdout.sh:4
&gt; &gt; +$@ &gt; $OUTPUT_FILE
&gt; 
&gt; You can do `exec $1 &gt; $2` here, if you write &apos;python &lt;@(_inputs)&apos; as a single string in the gyp files. (or $2 &gt; $1 if you prefer putting the output file before the command, but having `command output` matches bash order and also happens to be consistent with a similar script in chromium land.) (the `exec` saves you one process.)

It seems like this doesn&apos;t handle paths with spaces properly?

1. While I am very interested in the ninja generator, our downstream consumers will need to use the make generator.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>835854</commentid>
    <comment_count>8</comment_count>
      <attachid>188650</attachid>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-18 17:30:15 -0800</bug_when>
    <thetext>Comment on attachment 188650
Patch

Flipping the review flag again, since I think this patch is good as-is.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836642</commentid>
    <comment_count>9</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2013-02-19 12:10:25 -0800</bug_when>
    <thetext>(In reply to comment #7)
&gt; (In reply to comment #6)
&gt; 
&gt; Thanks for the comments!
&gt; 
&gt; &gt; &gt; The issue is that the rule seems to require paths realtive to this gyp file. Now that I look at this again, it seems that I can just prepend ../ to the &lt;(RULE_INPUT_PATH) part of the invocation. I&apos;ll fix this. :)
&gt; &gt; 
&gt; &gt; There&apos;s also the magic &lt;(DEPTH) variable that you can use for file lists in gypi files.
&gt; 
&gt; Hrm. I think I&apos;ll stick with the source list rather than &lt;(DEPTH). It&apos;s been very tricky getting out-of-tree builds working for the make generator [1].
&gt; 
&gt; &gt; 
&gt; &gt; &gt; Source/JavaScriptCore/JavaScriptCore.gyp/redirect-stdout.sh:4
&gt; &gt; &gt; +$@ &gt; $OUTPUT_FILE
&gt; &gt; 
&gt; &gt; You can do `exec $1 &gt; $2` here, if you write &apos;python &lt;@(_inputs)&apos; as a single string in the gyp files. (or $2 &gt; $1 if you prefer putting the output file before the command, but having `command output` matches bash order and also happens to be consistent with a similar script in chromium land.) (the `exec` saves you one process.)
&gt; 
&gt; It seems like this doesn&apos;t handle paths with spaces properly?
&gt; 

Do we have paths with spaces in them somewhere?

&gt; 1. While I am very interested in the ninja generator, our downstream consumers will need to use the make generator.

I didn&apos;t see a mention of ninja anywhere, so I&apos;m not sure what this is referring to?

You should be aware that the make generator doesn&apos;t get a lot of attention from chromium-land these days (I think all or at least nearly all of our builds have switched to ninja), so you might be a bit more on the hook for making sure make works for you. You might also want to make sure the make output is what you want it to be (last I looked at it, it had a lot of stuff that seemed like unnecessary boilerplate, but it might be useful or needed to blend in w/ various linux distros, I&apos;m not sure).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836655</commentid>
    <comment_count>10</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-19 12:17:58 -0800</bug_when>
    <thetext>(In reply to comment #9)

&gt; &gt; &gt; You can do `exec $1 &gt; $2` here, if you write &apos;python &lt;@(_inputs)&apos; as a single string in the gyp files. (or $2 &gt; $1 if you prefer putting the output file before the command, but having `command output` matches bash order and also happens to be consistent with a similar script in chromium land.) (the `exec` saves you one process.)
&gt; &gt; 
&gt; &gt; It seems like this doesn&apos;t handle paths with spaces properly?
&gt; &gt; 
&gt; 
&gt; Do we have paths with spaces in them somewhere?

Not within WebKit to my knowledge, but theoretically someone could kick off an out-of-tree build into a directory with a space in the name. Since we distribute a source tarball, we have less control over the build environment.

&gt; You should be aware that the make generator doesn&apos;t get a lot of attention from chromium-land these days (I think all or at least nearly all of our builds have switched to ninja), so you might be a bit more on the hook for making sure make works for you. You might also want to make sure the make output is what you want it to be (last I looked at it, it had a lot of stuff that seemed like unnecessary boilerplate, but it might be useful or needed to blend in w/ various linux distros, I&apos;m not sure).

That&apos;s the impression that I have as well. Since the make generator is so flaky at the moment, I&apos;m worried about making my job bigger by relying too much on DEPTH in the gyp build. To some extent we&apos;ll need to fix bugs in the make generator and do some maintenance. This will have to be the state of affairs until I can ensure that it&apos;s okay to force the ninja dependency downstream. The great thing about gyp is that it&apos;s very hackable and we can easily bundle it with WebKit to include fixes. The only thing that would really worry me is if there are plans to remove the make generator entirely.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836660</commentid>
    <comment_count>11</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2013-02-19 12:28:39 -0800</bug_when>
    <thetext>(In reply to comment #10)
&gt; The only thing that would really worry me is if there are plans to remove the make generator entirely.

I don&apos;t believe there are, and I don&apos;t really see that happening.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836673</commentid>
    <comment_count>12</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2013-02-19 12:37:32 -0800</bug_when>
    <thetext>(In reply to comment #7)
&gt; (In reply to comment #6)
&gt; 
&gt; Thanks for the comments!
&gt; 
&gt; &gt; &gt; The issue is that the rule seems to require paths realtive to this gyp file. Now that I look at this again, it seems that I can just prepend ../ to the &lt;(RULE_INPUT_PATH) part of the invocation. I&apos;ll fix this. :)
&gt; &gt; 
&gt; &gt; There&apos;s also the magic &lt;(DEPTH) variable that you can use for file lists in gypi files.
&gt; 
&gt; Hrm. I think I&apos;ll stick with the source list rather than &lt;(DEPTH). It&apos;s been very tricky getting out-of-tree builds working for the make generator [1].
&gt; 

Often (but not always) in chromium we use .gypi files that live in the same directory as the .gyp files, to get around issues like this when they crop up. It&apos;s not clear to me why we didn&apos;t do that in WebKit, but I suspect it was to get around putting too many gyp-related files in the top directories. This reason might be less relevant if we can get people to standardize on gyp.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836679</commentid>
    <comment_count>13</comment_count>
      <attachid>188650</attachid>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2013-02-19 12:38:51 -0800</bug_when>
    <thetext>Comment on attachment 188650
Patch

r+; hopefully nico won&apos;t shoot me for this :).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836744</commentid>
    <comment_count>14</comment_count>
      <attachid>188650</attachid>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2013-02-19 13:49:05 -0800</bug_when>
    <thetext>Comment on attachment 188650
Patch

Rejecting attachment 188650 from commit-queue.

Failed to run &quot;[&apos;/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch&apos;, &apos;--status-host=queues.webkit.org&apos;, &apos;--bot-id=gce-cq-03&apos;, &apos;apply-attachment&apos;, &apos;--no-update&apos;, &apos;--non-interactive&apos;, 188650, &apos;--port=chromium-xvfb&apos;]&quot; exit_code: 2 cwd: /mnt/git/webkit-commit-queue

Last 500 characters of output:
 hunks FAILED -- saving rejects to file Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCoreGTK.gyp.rej
patching file Source/JavaScriptCore/JavaScriptCore.gyp/generate-derived-sources.sh
rm &apos;Source/JavaScriptCore/JavaScriptCore.gyp/generate-derived-sources.sh&apos;
patching file Source/JavaScriptCore/JavaScriptCore.gyp/redirect-stdout.sh

Failed to run &quot;[u&apos;/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply&apos;, &apos;--force&apos;, &apos;--reviewer&apos;, &apos;Dirk Pranke&apos;]&quot; exit_code: 1 cwd: /mnt/git/webkit-commit-queue

Full output: http://queues.webkit.org/results/16626872</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836746</commentid>
    <comment_count>15</comment_count>
    <who name="Nico Weber">thakis</who>
    <bug_when>2013-02-19 13:49:41 -0800</bug_when>
    <thetext>(In reply to comment #11)
&gt; (In reply to comment #10)
&gt; &gt; The only thing that would really worry me is if there are plans to remove the make generator entirely.
&gt; 
&gt; I don&apos;t believe there are, and I don&apos;t really see that happening.

I don&apos;t know of any plans to get rid of the make generator either. The old scons generator is still around too, even though it isn&apos;t used anywhere in chromium land.

(We might move from make to ninja as the default build system on linux eventually, but we wouldn&apos;t delete the generator from gyp if we did that.)

Patch lgtm too.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>836751</commentid>
    <comment_count>16</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-02-19 13:55:46 -0800</bug_when>
    <thetext>Committed r143381: &lt;http://trac.webkit.org/changeset/143381&gt;</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>188650</attachid>
            <date>2013-02-15 15:19:22 -0800</date>
            <delta_ts>2013-02-19 13:49:05 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-109969-20130215151550.patch</filename>
            <type>text/plain</type>
            <size>6696</size>
            <attacher name="Martin Robinson">mrobinson</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTQzMDM5CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw
dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCA0
YWQ5NWRkMWQ5MmM2ZTdjZjhiNGEyYTk3ZjYxMGRkMTRmOGJjOWQzLi5lNTUwYzE2YmUzY2FlNjNm
NzJjYzVjYmE0NGJmYzg1Nzg1YmVhMmQwIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv
cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs
NSArMSwyMCBAQAogMjAxMy0wMi0xNSAgTWFydGluIFJvYmluc29uICA8bXJvYmluc29uQGlnYWxp
YS5jb20+CiAKKyAgICAgICAgW0dUS10gSW1wcm92ZSBneXAgYnVpbGQgSmF2YVNjcmlwdENvcmUg
Y29kZSBnZW5lcmF0aW9uCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn
LmNnaT9pZD0xMDk5NjkKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKwor
ICAgICAgICBTd2l0Y2ggYXdheSBmcm9tIHVzaW5nIERlcml2ZWRTb3VyY2VzLm1ha2Ugd2hlbiBi
dWlsZGluZyBKYXZhU2NyaXB0Q29yZSBnZW5lcmF0ZWQKKyAgICAgICAgc291cmNlcy4gVGhpcyBi
cmluZyBhIGNvdXBsZSBhZHZhbnRhZ2VzLCBzdWNoIGFzIGJ1aWxkaW5nIHRoZSBzb3VyY2VzIGlu
IHBhcmFsbGVsLAorICAgICAgICBidXQgcmVxdWlyZXMgdXMgdG8gbGlzdCB0aGUgZ2VuZXJhdGVk
IHNvdXJjZXMgbW9yZSB0aGFuIG9uY2UuCisKKyAgICAgICAgKiBKYXZhU2NyaXB0Q29yZS5neXAv
SmF2YVNjcmlwdENvcmVHVEsuZ3lwOiBBZGQgcnVsZXMgZm9yIGdlbmVyYXRpbmcgSmF2YVNjcmlw
dENvcmUgc291cmNlcy4KKyAgICAgICAgKiBKYXZhU2NyaXB0Q29yZS5neXAvZ2VuZXJhdGUtZGVy
aXZlZC1zb3VyY2VzLnNoOiBBZGRlZC4KKyAgICAgICAgKiBKYXZhU2NyaXB0Q29yZS5neXAvcmVk
aXJlY3Qtc3Rkb3V0LnNoOiBBZGRlZC4KKworMjAxMy0wMi0xNSAgTWFydGluIFJvYmluc29uICA8
bXJvYmluc29uQGlnYWxpYS5jb20+CisKICAgICAgICAgW0dUS10gU3ByZWFkIHRoZSBneXAgYnVp
bGQgZmlsZXMgdGhyb3VnaG91dCB0aGUgdHJlZQogICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0
Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTA5OTYwCiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2Ny
aXB0Q29yZS9KYXZhU2NyaXB0Q29yZS5neXAvSmF2YVNjcmlwdENvcmVHVEsuZ3lwIGIvU291cmNl
L0phdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLmd5cC9KYXZhU2NyaXB0Q29yZUdUSy5neXAK
aW5kZXggNTNhMDgxN2UyMTEwZjQ3ZjQyNmE0NmQxMDc4OGViYWRhZDQzZTk4Mi4uM2Q4MmNhN2U2
ZjNmNDNlYzRhNTk5NTY4MmM0OTIxODAxNDBkNmViYyAxMDA2NDQKLS0tIGEvU291cmNlL0phdmFT
Y3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLmd5cC9KYXZhU2NyaXB0Q29yZUdUSy5neXAKKysrIGIv
U291cmNlL0phdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLmd5cC9KYXZhU2NyaXB0Q29yZUdU
Sy5neXAKQEAgLTY5LDExICs2OSw2NyBAQAogICAgICAgXSwKICAgICB9LAogICAgIHsKKyAgICAg
ICd0YXJnZXRfbmFtZSc6ICdHZW5lcmF0ZUxVVHMnLAorICAgICAgJ3R5cGUnOiAnbm9uZScsCisg
ICAgICAnc291cmNlcyc6IFsKKyAgICAgICAgICAnLi4vcnVudGltZS9BcnJheUNvbnN0cnVjdG9y
LmNwcCcsCisgICAgICAgICAgJy4uL3J1bnRpbWUvQXJyYXlQcm90b3R5cGUuY3BwJywKKyAgICAg
ICAgICAnLi4vcnVudGltZS9Cb29sZWFuUHJvdG90eXBlLmNwcCcsCisgICAgICAgICAgJy4uL3J1
bnRpbWUvRGF0ZUNvbnN0cnVjdG9yLmNwcCcsCisgICAgICAgICAgJy4uL3J1bnRpbWUvRGF0ZVBy
b3RvdHlwZS5jcHAnLAorICAgICAgICAgICcuLi9ydW50aW1lL0Vycm9yUHJvdG90eXBlLmNwcCcs
CisgICAgICAgICAgJy4uL3J1bnRpbWUvSlNPTk9iamVjdC5jcHAnLAorICAgICAgICAgICcuLi9y
dW50aW1lL0pTR2xvYmFsT2JqZWN0LmNwcCcsCisgICAgICAgICAgJy4uL3J1bnRpbWUvTWF0aE9i
amVjdC5jcHAnLAorICAgICAgICAgICcuLi9ydW50aW1lL05hbWVQcm90b3R5cGUuY3BwJywKKyAg
ICAgICAgICAnLi4vcnVudGltZS9OdW1iZXJDb25zdHJ1Y3Rvci5jcHAnLAorICAgICAgICAgICcu
Li9ydW50aW1lL051bWJlclByb3RvdHlwZS5jcHAnLAorICAgICAgICAgICcuLi9ydW50aW1lL09i
amVjdENvbnN0cnVjdG9yLmNwcCcsCisgICAgICAgICAgJy4uL3J1bnRpbWUvT2JqZWN0UHJvdG90
eXBlLmNwcCcsCisgICAgICAgICAgJy4uL3J1bnRpbWUvUmVnRXhwQ29uc3RydWN0b3IuY3BwJywK
KyAgICAgICAgICAnLi4vcnVudGltZS9SZWdFeHBQcm90b3R5cGUuY3BwJywKKyAgICAgICAgICAn
Li4vcnVudGltZS9SZWdFeHBPYmplY3QuY3BwJywKKyAgICAgICAgICAnLi4vcnVudGltZS9TdHJp
bmdDb25zdHJ1Y3Rvci5jcHAnLAorICAgICAgICAgICcuLi9ydW50aW1lL1N0cmluZ1Byb3RvdHlw
ZS5jcHAnLAorICAgICAgXSwKKyAgICAgICdydWxlcycgOiBbCisgICAgICAgIHsKKyAgICAgICAg
ICAncnVsZV9uYW1lJzogJ0dlbmVyYXRlTFVUJywKKyAgICAgICAgICAnZXh0ZW5zaW9uJzogJ2Nw
cCcsCisgICAgICAgICAgJ2lucHV0cyc6IFsgJzwoSmF2YVNjcmlwdENvcmUpL2NyZWF0ZV9oYXNo
X3RhYmxlJywgXSwKKyAgICAgICAgICAnb3V0cHV0cyc6IFsKKyAgICAgICAgICAgICc8KFBST0RV
Q1RfRElSKS9EZXJpdmVkU291cmNlcy9KYXZhU2NyaXB0Q29yZS88KFJVTEVfSU5QVVRfUk9PVCku
bHV0LmgnLAorICAgICAgICAgIF0sCisgICAgICAgICAgJ2FjdGlvbic6IFsKKyAgICAgICAgICAg
ICcuL3JlZGlyZWN0LXN0ZG91dC5zaCcsCisgICAgICAgICAgICAnPChQUk9EVUNUX0RJUikvRGVy
aXZlZFNvdXJjZXMvSmF2YVNjcmlwdENvcmUvPChSVUxFX0lOUFVUX1JPT1QpLmx1dC5oJywKKyAg
ICAgICAgICAgICdwZXJsJywgJzxAKF9pbnB1dHMpJywgJzwoUlVMRV9JTlBVVF9QQVRIKScsICct
aScsCisgICAgICAgICAgXSwKKyAgICAgICAgfQorICAgICAgXSwKKyAgICAgICdhY3Rpb25zJzog
WworICAgICAgICB7CisgICAgICAgICAgJ2FjdGlvbl9uYW1lJzogJ0dlbmVyYXRlTGV4ZXJMVVQn
LAorICAgICAgICAgICdpbnB1dHMnOiBbCisgICAgICAgICAgICAgICc8KEphdmFTY3JpcHRDb3Jl
KS9jcmVhdGVfaGFzaF90YWJsZScsCisgICAgICAgICAgICAgICc8KEphdmFTY3JpcHRDb3JlKS9w
YXJzZXIvS2V5d29yZHMudGFibGUnLAorICAgICAgICAgICBdLAorICAgICAgICAgICdvdXRwdXRz
JzogWyAnPChQUk9EVUNUX0RJUikvRGVyaXZlZFNvdXJjZXMvSmF2YVNjcmlwdENvcmUvTGV4ZXIu
bHV0LmgnLCBdLAorICAgICAgICAgICdhY3Rpb24nOiBbCisgICAgICAgICAgICAnLi9yZWRpcmVj
dC1zdGRvdXQuc2gnLAorICAgICAgICAgICAgJzwoUFJPRFVDVF9ESVIpL0Rlcml2ZWRTb3VyY2Vz
L0phdmFTY3JpcHRDb3JlL0xleGVyLmx1dC5oJywKKyAgICAgICAgICAgICdwZXJsJywgJzxAKF9p
bnB1dHMpJywKKyAgICAgICAgICBdLAorICAgICAgICB9LAorICAgICAgXSwKKyAgICB9LAorICAg
IHsKICAgICAgICd0YXJnZXRfbmFtZSc6ICdsaWJqYXZhc2NyaXB0Y29yZWd0aycsCiAgICAgICAg
ICd0eXBlJzogJ3NoYXJlZF9saWJyYXJ5JywKICAgICAgICAgJ2RlcGVuZGVuY2llcyc6IFsKLSAg
ICAgICAgICAnLi4vLi4vV1RGL1dURi5neXAvV1RGR1RLLmd5cDp3dGYnLAogICAgICAgICAgICdM
TEludE9mZnNldEV4dHJhY3RvcicsCisgICAgICAgICAgJ0dlbmVyYXRlTFVUcycsCisgICAgICAg
ICAgJy4uLy4uL1dURi9XVEYuZ3lwL1dURkdUSy5neXA6d3RmJywKICAgICAgICAgICAnPChEZXBl
bmRlbmNpZXMpOmdsaWInLAogICAgICAgICAgICc8KERlcGVuZGVuY2llcyk6aWN1JywKICAgICAg
ICAgXSwKQEAgLTkzLDE3ICsxNDksNiBAQAogICAgICAgICBdLAogICAgICAgJ2FjdGlvbnMnOiBb
CiAgICAgICAgIHsKLSAgICAgICAgICAnYWN0aW9uX25hbWUnOiAnR2VuZXJhdGUgRGVyaXZlZCBT
b3VyY2VzJywKLSAgICAgICAgICAnaW5wdXRzJzogWwotICAgICAgICAgICAgJzwoSmF2YVNjcmlw
dENvcmUpL0Rlcml2ZWRTb3VyY2VzLm1ha2UnLAotICAgICAgICAgICAgJ2dlbmVyYXRlLWRlcml2
ZWQtc291cmNlcy5zaCcsCi0gICAgICAgICAgXSwKLSAgICAgICAgICAnb3V0cHV0cyc6IFsKLSAg
ICAgICAgICAgICc8QChqYXZhc2NyaXB0Y29yZV9kZXJpdmVkX3NvdXJjZV9maWxlcyknLAotICAg
ICAgICAgIF0sCi0gICAgICAgICAgJ2FjdGlvbic6IFsnc2gnLCAnZ2VuZXJhdGUtZGVyaXZlZC1z
b3VyY2VzLnNoJywgJzxAKHByb2plY3RfZGlyKScsICc8KFBST0RVQ1RfRElSKS9EZXJpdmVkU291
cmNlcy9KYXZhU2NyaXB0Q29yZSddLAotICAgICAgICB9LAotICAgICAgICB7CiAgICAgICAgICAg
J2FjdGlvbl9uYW1lJzogJ2xsaW50YXNzZW1ibHlfaGVhZGVyX2dlbmVyYXRpb24nLAogICAgICAg
ICAgICdpbnB1dHMnOiBbCiAgICAgICAgICAgICAnPChKYXZhU2NyaXB0Q29yZSkvb2ZmbGluZWFz
bS9hc20ucmInLApAQCAtMTE1LDYgKzE2MCwyOSBAQAogICAgICAgICAgIF0sCiAgICAgICAgICAg
J2FjdGlvbic6IFsncnVieScsICc8QChfaW5wdXRzKScsICc8QChfb3V0cHV0cyknXSwKICAgICAg
ICAgfSwKKyAgICAgICAgeworICAgICAgICAgICdhY3Rpb25fbmFtZSc6ICdHZW5lcmF0ZVJlZ0V4
cEppdFRhYmxlcycsCisgICAgICAgICAgJ2lucHV0cyc6IFsgJzwoSmF2YVNjcmlwdENvcmUpL2Ny
ZWF0ZV9yZWdleF90YWJsZXMnLCBdLAorICAgICAgICAgICdvdXRwdXRzJzogWyAnPChQUk9EVUNU
X0RJUikvRGVyaXZlZFNvdXJjZXMvSmF2YVNjcmlwdENvcmUvUmVnRXhwSml0VGFibGVzLmgnLCBd
LAorICAgICAgICAgICdhY3Rpb24nOiBbCisgICAgICAgICAgICAnLi9yZWRpcmVjdC1zdGRvdXQu
c2gnLAorICAgICAgICAgICAgJzwoUFJPRFVDVF9ESVIpL0Rlcml2ZWRTb3VyY2VzL0phdmFTY3Jp
cHRDb3JlL1JlZ0V4cEppdFRhYmxlcy5oJywKKyAgICAgICAgICAgICdweXRob24nLCAnPEAoX2lu
cHV0cyknCisgICAgICAgICAgXSwKKyAgICAgICAgfSwKKyAgICAgICAgeworICAgICAgICAgICdh
Y3Rpb25fbmFtZSc6ICdHZW5lcmF0ZUtleXdvcmRMb29rdXAnLAorICAgICAgICAgICdpbnB1dHMn
OiBbCisgICAgICAgICAgICAnPChKYXZhU2NyaXB0Q29yZSkvS2V5d29yZExvb2t1cEdlbmVyYXRv
ci5weScsCisgICAgICAgICAgICAnPChKYXZhU2NyaXB0Q29yZSkvcGFyc2VyL0tleXdvcmRzLnRh
YmxlJywKKyAgICAgICAgICBdLAorICAgICAgICAgICdvdXRwdXRzJzogWyAnPChQUk9EVUNUX0RJ
UikvRGVyaXZlZFNvdXJjZXMvSmF2YVNjcmlwdENvcmUvS2V5d29yZExvb2t1cC5oJywgXSwKKyAg
ICAgICAgICAnYWN0aW9uJzogWworICAgICAgICAgICAgJy4vcmVkaXJlY3Qtc3Rkb3V0LnNoJywK
KyAgICAgICAgICAgICc8KFBST0RVQ1RfRElSKS9EZXJpdmVkU291cmNlcy9KYXZhU2NyaXB0Q29y
ZS9LZXl3b3JkTG9va3VwLmgnLAorICAgICAgICAgICAgJ3B5dGhvbicsICc8QChfaW5wdXRzKScK
KyAgICAgICAgICBdLAorICAgICAgICB9LAogICAgICAgXSwKICAgICB9LAogICAgIHsKZGlmZiAt
LWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9KYXZhU2NyaXB0Q29yZS5neXAvZ2VuZXJhdGUt
ZGVyaXZlZC1zb3VyY2VzLnNoIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3Jl
Lmd5cC9nZW5lcmF0ZS1kZXJpdmVkLXNvdXJjZXMuc2gKZGVsZXRlZCBmaWxlIG1vZGUgMTAwNjQ0
CmluZGV4IGRhNDQ1MjNjNGRiZjIzMDExMzk4MTM1NDA0MzdlNjg4OGRmOGZkNjAuLjAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKLS0tIGEvU291cmNlL0phdmFTY3JpcHRD
b3JlL0phdmFTY3JpcHRDb3JlLmd5cC9nZW5lcmF0ZS1kZXJpdmVkLXNvdXJjZXMuc2gKKysrIC9k
ZXYvbnVsbApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLQotYWJzcGF0aCAoKSB7Ci0gICAg
Y2FzZSAiJDEiIGluIC8qKQotICAgICAgICBwcmludGYgIiVzXG4iICIkMSI7OwotICAgICopCi0g
ICAgICAgIHByaW50ZiAiJXNcbiIgIiRQV0QvJDEiOzsKLSAgICBlc2FjOwotfQotCi1KYXZhU2Ny
aXB0Q29yZT1gYWJzcGF0aCAkMWAKLWNkICQyCi1lY2hvIGBhYnNwYXRoICQyYAotbWFrZSAtLW5v
LWJ1aWx0aW4tcnVsZXMgLWYgIiRKYXZhU2NyaXB0Q29yZS9EZXJpdmVkU291cmNlcy5tYWtlIiBK
YXZhU2NyaXB0Q29yZT0kSmF2YVNjcmlwdENvcmUKLQpkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFT
Y3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLmd5cC9yZWRpcmVjdC1zdGRvdXQuc2ggYi9Tb3VyY2Uv
SmF2YVNjcmlwdENvcmUvSmF2YVNjcmlwdENvcmUuZ3lwL3JlZGlyZWN0LXN0ZG91dC5zaApuZXcg
ZmlsZSBtb2RlIDEwMDc1NQppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwLi5kYjhlZTk5ZDI3NjQxNTRmNDlmNDNjZTFhNWE3NTViZjcwYzQyZThlCi0tLSAvZGV2
L251bGwKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLmd5cC9yZWRp
cmVjdC1zdGRvdXQuc2gKQEAgLTAsMCArMSw0IEBACisjIS9iaW4vc2gKK09VVFBVVF9GSUxFPSQx
CitzaGlmdAorJEAgPiAkT1VUUFVUX0ZJTEUK
</data>
<flag name="review"
          id="209229"
          type_id="1"
          status="+"
          setter="dpranke"
    />
    <flag name="commit-queue"
          id="209475"
          type_id="3"
          status="-"
          setter="webkit.review.bot"
    />
          </attachment>
      

    </bug>

</bugzilla>