154530 2016-02-22 02:20:52 -0800 New intl-numberformat.js test fails on many Linux platforms 2016-06-06 05:20:08 -0700 1 1 1 Unclassified WebKit JavaScriptCore Other Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=158066 P2 Normal --- 158417 147605 1 ossy webkit-unassigned andy bugs-noreply cgarcia clopez commit-queue darin gustavo gyuyoung.kim jh718.park keith_miller mark.lam mcatanzaro msaboff ossy saam sukolsak ysuzuki oldest_to_newest 1166973 0 ossy 2016-02-22 02:20:52 -0800 intl-numberformat.js introduced in http://trac.webkit.org/changeset/196850, but fails on EFL ARM and GTK x86_64 buildbots: - GTK bot: https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Tests%29/builds/13917 - EFL ARM bot: https://build.webkit.org/builders/EFL%20Linux%20ARMv7%20Thumb2%20Release/builds/17225 It's strange that it passes on the EFL x86_64 bot. I don't know anything about this code path. Is it possible that some 3rd party libraries with different version cause this failure? 1167031 1 sukolsak 2016-02-22 08:54:40 -0800 This is likely the same issue as Bug 152448. It is because Intl uses POSIX locale. $ LANG=en_US.UTF-8 ./jsc -e "print(Infinity.toLocaleString())" ∞ $ LANG=en_US_POSIX.UTF-8 ./jsc -e "print(Infinity.toLocaleString())" INF The proposed patch in Bug 152448 should fix it. 1168932 2 andy 2016-02-27 17:30:33 -0800 The patch for Bug 152448 likely hasn't resolved this issue, because it only provided a hook for defaultLanguage that is implemented in WebCore. 1168936 3 darin 2016-02-27 17:45:24 -0800 There are two separate questions here: One is how to make WebKit and JavaScriptCore properly choose a default locale for each platform. I don’t know what the right way to do that is for Linux in general. Fixing that for WebCore is what bug 152448 is all about. But it almost certainly needs to be fixed for direct JavaScriptCore use too. At least I know it does need to be done on the Apple platforms. So we may need a bug to track that. The other is how to make the test harness set a consistent language so that tests are reliable, rather than being sensitive to the language the user running the tests happens to prefer. That's something we need to address separately. There are lots of calls to setenv in various test tools, so it could be as simple as doing a setenv("LANG") in the right place for the appropriate platforms in some of the test tools. 1169143 4 clopez 2016-02-29 07:34:45 -0800 (In reply to comment #3) > There are two separate questions here: > > One is how to make WebKit and JavaScriptCore properly choose a default > locale for each platform. I don’t know what the right way to do that is for > Linux in general. Fixing that for WebCore is what bug 152448 is all about. > But it almost certainly needs to be fixed for direct JavaScriptCore use too. > At least I know it does need to be done on the Apple platforms. So we may > need a bug to track that. > With glibc (GNU/Linux) the default locale is defined on the environment variable LANG. If LANG is not defined, then the locale defaults to 'C' (also known as 'POSIX') which is the default portable locale. This default locale can be overridden with the environment variable LC_ALL. So perhaps we can just do setenv("LC_ALL", "C") before starting the tests. This will override any locale defined by the user, and it will be portable across operating systems Some quick tests: # Linux $ LANG=es_ES.UTF-8 WebKitBuild/Release/bin/jsc -e "print(Infinity.toLocaleString())" ∞ $ LC_ALL=POSIX LANG=es_ES.UTF-8 WebKitBuild/Release/bin/jsc -e "print(Infinity.toLocaleString())" INF $ LC_ALL=C LANG=es_ES.UTF-8 WebKitBuild/Release/bin/jsc -e "print(Infinity.toLocaleString())" INF # MacOS $ LANG=es_ES.UTF-8 WebKitBuild//Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Infinity.toLocaleString())" ∞ $ LC_ALL=POSIX LANG=es_ES.UTF-8 WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Infinity.toLocaleString())" INF $ LC_ALL=C LANG=es_ES.UTF-8 WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Infinity.toLocaleString())" INF > The other is how to make the test harness set a consistent language so that > tests are reliable, rather than being sensitive to the language the user > running the tests happens to prefer. That's something we need to address > separately. There are lots of calls to setenv in various test tools, so it > could be as simple as doing a setenv("LANG") in the right place for the > appropriate platforms in some of the test tools. As explained above, just doing setenv("LC_ALL", "C") before starting the tests should work for all use cases. More info: http://man7.org/linux/man-pages/man3/setlocale.3.html and https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/locale.1.html 1169179 5 clopez 2016-02-29 09:52:56 -0800 Seems that my previous suggestion of setting LC_ALL is not going to help. This test js/intl-numberformat.html is manually setting the locales and trying some numeric and monetary conversions and checking that it returns the right values. For example see the follow examples: linux # WebKitBuild/Release/bin/jsc -e "print(Intl.NumberFormat('es').format(1234.567))" 1 234,567 linux # $ WebKitBuild/Release/bin/jsc -e "print(Intl.NumberFormat('en').format(1234.567))" 1,234.567 macos # WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Intl.NumberFormat('es').format(1234.567))" 1.234,567 macos # WebKitBuild/Release/JavaScriptCore.framework/Versions/A/Resources/jsc -e "print(Intl.NumberFormat('en').format(1234.567))" 1,234.567 So it seems there is fundamental difference here. In MacOS we are getting a '.' in the thousands decimal mark for the spanish locale (right), meanwhile in Linux we are getting an space (wrong). The above checks are part of the test js/intl-numberformat.html therefore on Linux we are getting: -PASS Intl.NumberFormat('es').format(1234.567) is '1.234,567' +FAIL Intl.NumberFormat('es').format(1234.567) should be 1.234,567. Was 1 234,567. Not sure what is wrong, at least with printf on Linux I get the right values LC_NUMERIC=en_US.UTF8 /usr/bin/printf "%'.2f\n" '1234.567' 1,234.57 LC_NUMERIC=es_ES.UTF8 /usr/bin/printf "%'.2f\n" '1234.567' 1.234,57 So this don't seems a problem on the Linux glibc, but at first it looks that something on jsc is not picking/setting the right values for the locales when running on Linux This is the full text difference for the test js/intl-numberformat.html with WebKitGTK+ (Linux): --- /home/clopez/webkit/webkit/layout-test-results/js/intl-numberformat-expected.txt +++ /home/clopez/webkit/webkit/layout-test-results/js/intl-numberformat-actual.txt @@ -140,7 +140,7 @@ PASS Intl.NumberFormat('en').format(Number.MIN_VALUE) is '0' PASS Intl.NumberFormat('en').format(Number.MAX_VALUE) is '179,769,313,486,232,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000' PASS Intl.NumberFormat('en').format(1234.567) is '1,234.567' -PASS Intl.NumberFormat('es').format(1234.567) is '1.234,567' +FAIL Intl.NumberFormat('es').format(1234.567) should be 1.234,567. Was 1 234,567. PASS Intl.NumberFormat('fr').format(1234.567) is '1 234,567' PASS Intl.NumberFormat('en-u-nu-latn').format(1234.567) is '1,234.567' PASS Intl.NumberFormat('en-u-nu-fullwide').format(1234.567) is '１,２３４.５６７' @@ -156,14 +156,14 @@ PASS Intl.NumberFormat('en', {style: 'currency', currency: 'USD'}).format(Infinity) is '$∞' PASS Intl.NumberFormat('en', {style: 'currency', currency: 'JPY'}).format(4.2) is '¥4' PASS Intl.NumberFormat('en', {style: 'currency', currency: 'xXx'}).format(4.2) is 'XXX4.20' -PASS Intl.NumberFormat('en', {style: 'currency', currency: 'USD', currencyDisplay: 'code'}).format(4) is 'USD4.00' +FAIL Intl.NumberFormat('en', {style: 'currency', currency: 'USD', currencyDisplay: 'code'}).format(4) should be USD4.00. Threw exception Error: Failed to format a number. PASS Intl.NumberFormat('en', {style: 'currency', currency: 'USD', currencyDisplay: 'symbol'}).format(4) is '$4.00' -PASS Intl.NumberFormat('en', {style: 'currency', currency: 'USD', currencyDisplay: 'name'}).format(4) is '4.00 US dollars' -PASS Intl.NumberFormat('en', {style: 'currency', currency: 'JPY', currencyDisplay: 'code'}).format(-4.2) is '-JPY4' +FAIL Intl.NumberFormat('en', {style: 'currency', currency: 'USD', currencyDisplay: 'name'}).format(4) should be 4.00 US dollars. Threw exception Error: Failed to format a number. +FAIL Intl.NumberFormat('en', {style: 'currency', currency: 'JPY', currencyDisplay: 'code'}).format(-4.2) should be -JPY4. Threw exception Error: Failed to format a number. PASS Intl.NumberFormat('en', {style: 'currency', currency: 'JPY', currencyDisplay: 'symbol'}).format(-4.2) is '-¥4' -PASS Intl.NumberFormat('en', {style: 'currency', currency: 'JPY', currencyDisplay: 'name'}).format(-4.2) is '-4 Japanese yen' -PASS Intl.NumberFormat('fr', {style: 'currency', currency: 'USD', currencyDisplay: 'name'}).format(4) is '4,00 dollars des États-Unis' -PASS Intl.NumberFormat('fr', {style: 'currency', currency: 'JPY', currencyDisplay: 'name'}).format(4) is '4 yens japonais' +FAIL Intl.NumberFormat('en', {style: 'currency', currency: 'JPY', currencyDisplay: 'name'}).format(-4.2) should be -4 Japanese yen. Threw exception Error: Failed to format a number. +FAIL Intl.NumberFormat('fr', {style: 'currency', currency: 'USD', currencyDisplay: 'name'}).format(4) should be 4,00 dollars des États-Unis. Threw exception Error: Failed to format a number. +FAIL Intl.NumberFormat('fr', {style: 'currency', currency: 'JPY', currencyDisplay: 'name'}).format(4) should be 4 yens japonais. Threw exception Error: Failed to format a number. PASS Intl.NumberFormat('en', {minimumIntegerDigits: 4}).format(12) is '0,012' PASS Intl.NumberFormat('en', {minimumIntegerDigits: 4}).format(12345) is '12,345' PASS Intl.NumberFormat('en', {minimumFractionDigits: 3}).format(1) is '1.000' @@ -184,7 +184,7 @@ PASS Intl.NumberFormat('en', {maximumSignificantDigits: 4}).format(0.1234567) is '0.1235' PASS Intl.NumberFormat('en', {maximumSignificantDigits: 4}).format(1234567) is '1,235,000' PASS Intl.NumberFormat('en', {useGrouping: true}).format(1234567.123) is '1,234,567.123' -PASS Intl.NumberFormat('es', {useGrouping: true}).format(1234567.123) is '1.234.567,123' +FAIL Intl.NumberFormat('es', {useGrouping: true}).format(1234567.123) should be 1.234.567,123. Was 1 234 567,123. PASS Intl.NumberFormat('fr', {useGrouping: true}).format(1234567.123) is '1 234 567,123' PASS Intl.NumberFormat('en', {useGrouping: false}).format(1234567.123) is '1234567.123' PASS Intl.NumberFormat('es', {useGrouping: false}).format(1234567.123) is '1234567,123' 1196284 6 cgarcia 2016-05-25 04:13:13 -0700 Many other tests started to fail after r201066, but the problem seems to be the same. run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment variables at all when using jsc binary. We are using setlocale with a nullptr locale to get the current one, but the current one is always "C", because to set the locale according to the environment variables we need to call setlocale with an empty string as locale. That's done by gtk_init() which is called by all our binaries (web process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has always worked for EFL is because they call ecore_init() in jsc that calls setlocale. I'll submit a patch to fix this and the new tests failing. 1196291 7 279758 cgarcia 2016-05-25 04:22:34 -0700 Created attachment 279758 Patch I'm not sure this is also needed for jsc-only port. In that case it would be a matter of updating the ifdef 1196292 8 279758 darin 2016-05-25 04:26:20 -0700 Comment on attachment 279758 Patch OK. Not sure this is the right way to do things. Seems unfortunate to have significant platform dependencies in a command line tool. Unpleasant to have iOS, EFL, Windows, and GTK specifics. I suppose I should be grateful we don’t have anything like this for Mac yet? 1196294 9 cgarcia 2016-05-25 05:20:25 -0700 hmm, I was wrong, even with this patch intl-numberformat.js is filing, but all others that started to fail after r201066 are passing now, so I'll submit a separate bug. 1196295 10 ossy 2016-05-25 05:22:19 -0700 (In reply to comment #7) > Created attachment 279758 [details] > Patch > > I'm not sure this is also needed for jsc-only port. In that case it would be > a matter of updating the ifdef I'll check if it fixes failures on jsc-only ARM bots. ( without guard, of course :) ) Could you wait ~2-3 hours for my testing before landing? 1196298 11 279758 cgarcia 2016-05-25 05:27:14 -0700 Comment on attachment 279758 Patch Clearing flags, I moved the patch to bug #158066 1196299 12 cgarcia 2016-05-25 05:28:01 -0700 (In reply to comment #10) > (In reply to comment #7) > > Created attachment 279758 [details] > > Patch > > > > I'm not sure this is also needed for jsc-only port. In that case it would be > > a matter of updating the ifdef > > I'll check if it fixes failures on jsc-only ARM bots. > ( without guard, of course :) ) > > Could you wait ~2-3 hours for my testing before landing? Sure 1196300 13 cgarcia 2016-05-25 05:31:22 -0700 intl-numberformat.js works for me locally, but not in the bots 1196305 14 cgarcia 2016-05-25 05:57:05 -0700 In my laptop: $ LANG=en_US.UTF-8 bin/jsc -e "print(Intl.NumberFormat('es', {useGrouping: true}).format(1234567.123))" 1.234.567,123 In the bot: $ LANG=en_US.UTF-8 bin/jsc -e "print(Intl.NumberFormat('es', {useGrouping: true}).format(1234567.123))" 1 234 567,123 There must be something else, doesn't look like a WebKit problem. 1196306 15 cgarcia 2016-05-25 06:00:28 -0700 Are we using ICU for this? could it be the ICU version? it's the only (relevant) thing that looks different between my laptop and the bot 1196705 16 279882 cgarcia 2016-05-26 06:32:54 -0700 Created attachment 279882 Patch for GTK+ So it was indeed the ICU version installed in the bots. Confirmed that using a newer version in the bots fixes the tests. 1196710 17 cgarcia 2016-05-26 07:43:03 -0700 I tried the patch on a clean build in a tests bot we have and it worked, so I'm not sure about he EWS failure, maybe a clan build would fix it. 1196729 18 279882 darin 2016-05-26 08:47:29 -0700 Comment on attachment 279882 Patch for GTK+ Please look at the compile failure in GTK EWS. 1196730 19 cgarcia 2016-05-26 08:51:23 -0700 Darin, I think it's a clean build issue, because I've tried in a test bot and it worked. I'll trigger clean builds in the bots and watch them after landing. 1196993 20 cgarcia 2016-05-27 00:17:40 -0700 Committed r201449: <http://trac.webkit.org/changeset/201449> 1197304 21 ysuzuki 2016-05-27 20:14:23 -0700 While your change solves the JSC tests (Great!!), the layout-tests in GTK ports pose many new failing tests instead. Do you already know the reason? 1197307 22 ysuzuki 2016-05-27 20:43:29 -0700 Ah, no, these tests are previously failing. Sorry. 1197474 23 ossy 2016-05-29 03:52:11 -0700 It broke the GTK ARM bot. 1197550 24 cgarcia 2016-05-29 23:11:46 -0700 (In reply to comment #23) > It broke the GTK ARM bot. I already talked to Gustavo, who was going to look at it. For some reason wget is failing to download from sourceforge in the ARM bot. In any case, it's a problem of the bot itself, not the patch. 1197756 25 clopez 2016-05-31 03:33:20 -0700 Committed r201509: <http://trac.webkit.org/changeset/201509> 279758 2016-05-25 04:22:34 -0700 2016-05-25 05:27:38 -0700 Patch jsc-intl-setlocale.diff text/plain 2043 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IDg3MGU2MzkuLmUxMjFlMTEgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL0phdmFTY3JpcHRD b3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIxIEBACisyMDE2LTA1LTI1ICBDYXJsb3MgR2FyY2lh IENhbXBvcyAgPGNnYXJjaWFAaWdhbGlhLmNvbT4KKworICAgICAgICBOZXcgaW50bC1udW1iZXJm b3JtYXQuanMgdGVzdCBmYWlscyBvbiBtYW55IExpbnV4IHBsYXRmb3JtcworICAgICAgICBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTU0NTMwCisKKyAgICAgICAgUmV2 aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgcnVuLWphdmFzY3JpcHRjb3JlLXRl c3RzIGRvZXMgJEVOVntMQU5HfT0iZW5fVVMuVVRGLTgiOyBidXQgd2UgYXJlIG5vdCBhY3R1YWxs eSBob25vcmluZyB0aGUgZW52aXJvbm1lbnQKKyAgICAgICAgdmFyaWFibGVzIGF0IGFsbCB3aGVu IHVzaW5nIGpzYyBiaW5hcnkuIFdlIGFyZSB1c2luZyBzZXRsb2NhbGUoKSB3aXRoIGEgbnVsbHB0 ciBsb2NhbGUgdG8gZ2V0IHRoZSBjdXJyZW50IG9uZSwgYnV0CisgICAgICAgIHRoZSBjdXJyZW50 IG9uZSBpcyBhbHdheXMgIkMiLCBiZWNhdXNlIHRvIHNldCB0aGUgbG9jYWxlIGFjY29yZGluZyB0 byB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIHdlIG5lZWQgdG8gY2FsbAorICAgICAgICBzZXRs b2NhbGUgd2l0aCBhbiBlbXB0eSBzdHJpbmcgYXMgbG9jYWxlLiBUaGF0J3MgZG9uZSBieSBndGtf aW5pdCgpLCB3aGljaCBpcyBjYWxsZWQgYnkgYWxsIG91ciBiaW5hcmllcyAod2ViCisgICAgICAg IHByb2Nlc3MsIG5ldHdvcmsgcHJvY2VzcywgZXRjLiksIGJ1dCBub3QgYnkganNjIChiZWNhdXNl IGpzYyBkb2Vzbid0IGRlcGVuZCBvbiBHVEsrKS4gVGhlIHJlYXNvbiB3aHkgaXQgaGFzCisgICAg ICAgIGFsd2F5cyB3b3JrZWQgZm9yIEVGTCBpcyBiZWNhdXNlIHRoZXkgY2FsbCBlY29yZV9pbml0 KCkgaW4ganNjIHRoYXQgY2FsbHMgc2V0bG9jYWxlLiBUaGlzIGZpeGVzIG90aGVyIGludGwgdGVz dHMKKyAgICAgICAgdGhhdCBzdGFydGVkIHRvIGZhaWwgYWZ0ZXIgcjIwMTA2NiB0b28uCisKKyAg ICAgICAgKiBqc2MuY3BwOgorICAgICAgICAobWFpbik6IENhbGwgc2V0bG9jYWxlKExDX0FMTCwg IiIpIG9uIEdUSysuCisKIDIwMTYtMDUtMjQgIFNhYW0gYmFyYXRpICA8c2JhcmF0aUBhcHBsZS5j b20+IGFuZCBZdXN1a2UgU3V6dWtpIDx1dGF0YW5lLnRlYUBnbWFpbC5jb20+CiAKICAgICAgICAg VGhpc1REWk1vZGUgaXMgbm8gbG9uZ2VyIG5lZWRlZApkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFT Y3JpcHRDb3JlL2pzYy5jcHAgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvanNjLmNwcAppbmRleCA0 MDk3Mzg0Li5iMDIxZDEwIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvanNjLmNw cAorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvanNjLmNwcApAQCAtMTkzMSw2ICsxOTMxLDEx IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyKiogYXJndikKICAgICBlY29yZV9pbml0KCk7CiAj ZW5kaWYKIAorI2lmIFBMQVRGT1JNKEdUSykKKyAgICBpZiAoIXNldGxvY2FsZShMQ19BTEwsICIi KSkKKyAgICAgICAgV1RGTG9nQWx3YXlzKCJMb2NhbGUgbm90IHN1cHBvcnRlZCBieSBDIGxpYnJh cnkuXG5cdFVzaW5nIHRoZSBmYWxsYmFjayAnQycgbG9jYWxlLiIpOworI2VuZGlmCisKICAgICAv LyBOZWVkIHRvIGluaXRpYWxpemUgV1RGIHRocmVhZGluZyBiZWZvcmUgd2Ugc3RhcnQgYW55IHRo cmVhZHMuIENhbm5vdCBpbml0aWFsaXplIEpTQwogICAgIC8vIHRocmVhZGluZyB5ZXQsIHNpbmNl IHRoYXQgd291bGQgZG8gc29tZXRoaW5ncyB0aGF0IHdlJ2QgbGlrZSB0byBkZWZlciB1bnRpbCBh ZnRlciB3ZQogICAgIC8vIGhhdmUgYSBjaGFuY2UgdG8gcGFyc2Ugb3B0aW9ucy4K 279882 2016-05-26 06:32:54 -0700 2016-05-26 16:30:52 -0700 Patch for GTK+ icu.diff text/plain 2595 cgarcia ZGlmZiAtLWdpdCBhL1Rvb2xzL0NoYW5nZUxvZyBiL1Rvb2xzL0NoYW5nZUxvZwppbmRleCBiOWFi MzU5Li4wZmU4YWIzIDEwMDY0NAotLS0gYS9Ub29scy9DaGFuZ2VMb2cKKysrIGIvVG9vbHMvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTYtMDUtMjYgIENhcmxvcyBHYXJjaWEgQ2FtcG9z ICA8Y2dhcmNpYUBpZ2FsaWEuY29tPgorCisgICAgICAgIE5ldyBpbnRsLW51bWJlcmZvcm1hdC5q cyB0ZXN0IGZhaWxzIG9uIG1hbnkgTGludXggcGxhdGZvcm1zCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNTQ1MzAKKworICAgICAgICBSZXZpZXdlZCBi eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBUaGUgdGVzdCBpcyBhY3R1YWxseSBmYWlsaW5n IGJlY2F1c2Ugb2YgYSBidWcgaW4gdGhlIGljdSB2ZXJzaW9uIGluc3RhbGxlZCBpbiB0aGUgYm90 cywgdXNpbmcgYSBuZXdlciB2ZXJzaW9uIG9mCisgICAgICAgIGljdSBtYWtlcyB0aGUgdGVzdHMg cGFzcyBhbmQgZXhwbGFpbnMgd2h5IGl0IHdvcmtlZCBmb3Igc29tZSBwZW9wbGUuIFNvLCBsZXQn cyBhZGQgaWN1IDU1LjEgdG8gdGhlIGludGVybmFsCisgICAgICAgIGpoYnVpbGQgdG8gZW5zdXJl IEpTQyB0ZXN0cyBwYXNzIGluIHRoZSBib3RzIG5vIG1hdHRlciB3aGF0IHRoZSBpY3UgdmVyc2lv biBpbnN0YWxsZWQgaXMuCisKKyAgICAgICAgKiBndGsvamhidWlsZC5tb2R1bGVzOgorCiAyMDE2 LTA1LTI0ICBBYWthc2ggSmFpbiAgPGFha2FzaF9qYWluQGFwcGxlLmNvbT4KIAogICAgICAgICBS ZW9yZ2FuaXplIGRhc2hib2FyZCBjb2RlOiBtb3ZlIGNvZGUgZnJvbSBfdGltZUludGVydmFsU3Ry aW5nIHRvIGJhc2UgY2xhc3MKZGlmZiAtLWdpdCBhL1Rvb2xzL2d0ay9qaGJ1aWxkLm1vZHVsZXMg Yi9Ub29scy9ndGsvamhidWlsZC5tb2R1bGVzCmluZGV4IGQ2NGNlZjYuLjhkMjg5MGUgMTAwNjQ0 Ci0tLSBhL1Rvb2xzL2d0ay9qaGJ1aWxkLm1vZHVsZXMKKysrIGIvVG9vbHMvZ3RrL2poYnVpbGQu bW9kdWxlcwpAQCAtMjAsNiArMjAsNyBAQAogICAgICAgPGRlcCBwYWNrYWdlPSJnbm9tZS1pY29u LXRoZW1lLXN5bWJvbGljIi8+CiAgICAgICA8ZGVwIHBhY2thZ2U9Imdub21lLXRoZW1lcy1zdGFu ZGFyZCIvPgogICAgICAgPGRlcCBwYWNrYWdlPSJndGstZG9jIi8+CisgICAgICA8ZGVwIHBhY2th Z2U9ImljdSIvPgogICAgICAgPGRlcCBwYWNrYWdlPSJsaWJzb3VwIi8+CiAgICAgICA8ZGVwIHBh Y2thZ2U9ImF0ayIvPgogICAgICAgPGRlcCBwYWNrYWdlPSJnc3RyZWFtZXIiLz4KQEAgLTY5LDYg KzcwLDggQEAKICAgICAgIGhyZWY9Imh0dHA6Ly9wZW9wbGUuZnJlZWRlc2t0b3Aub3JnIi8+CiAg IDxyZXBvc2l0b3J5IHR5cGU9InRhcmJhbGwiIG5hbWU9Imxsdm0ub3JnIgogICAgICAgaHJlZj0i aHR0cDovL2xsdm0ub3JnIi8+CisgIDxyZXBvc2l0b3J5IHR5cGU9InRhcmJhbGwiIG5hbWU9Imlj dSIKKyAgICAgIGhyZWY9Imh0dHA6Ly9kb3dubG9hZC5pY3UtcHJvamVjdC5vcmcvZmlsZXMvaWN1 NGMvIi8+CiAKICAgPGF1dG90b29scyBpZD0iY2Fpcm8iPgogICAgIDxpZiBjb25kaXRpb24tc2V0 PSJsaW51eCI+CkBAIC0xMTksNiArMTIyLDkgQEAKICAgPC9hdXRvdG9vbHM+CiAKICAgPGF1dG90 b29scyBpZD0iaGFyZmJ1enoiIGF1dG9nZW4tc2g9ImNvbmZpZ3VyZSI+CisgICAgPGRlcGVuZGVu Y2llcz4KKyAgICAgIDxkZXAgcGFja2FnZT0iaWN1Ii8+CisgICAgPC9kZXBlbmRlbmNpZXM+CiAg ICAgPGJyYW5jaCBtb2R1bGU9InNvZnR3YXJlL2hhcmZidXp6L3JlbGVhc2UvaGFyZmJ1enotMC45 LjM1LnRhci5iejIiCiAgICAgICAgICAgICB2ZXJzaW9uPSIwLjkuMzUiCiAgICAgICAgICAgICBj aGVja291dGRpcj0iaGFyZmJ1enotMC45LjM1IgpAQCAtNDgzLDcgKzQ4OSwxNiBAQAogICAgICAg PHBhdGNoIGZpbGU9InNoYXJlZC1taW1lLWluZm8teGh0bWwtbWFnaWMucGF0Y2giIHN0cmlwPSIx Ii8+CiAgICAgPC9icmFuY2g+CiAgIDwvYXV0b3Rvb2xzPgotICAKKworICA8YXV0b3Rvb2xzIGlk PSJpY3UiCisgICAgICAgICAgICAgYXV0b2dlbi1zaD0iLi9zb3VyY2UvY29uZmlndXJlIgorICAg ICAgICAgICAgIGF1dG9nZW5hcmdzPSItLWRpc2FibGUtc2FtcGxlcyAtLWVuYWJsZS13ZWFrLXRo cmVhZHMiPgorICAgIDxicmFuY2ggbW9kdWxlPSI1NS4xL2ljdTRjLTU1XzEtc3JjLnRneiIgdmVy c2lvbj0iNTUuMSIgY2hlY2tvdXRkaXI9ImljdSIKKyAgICAgICAgICAgIHJlcG89ImljdSIKKyAg ICAgICAgICAgIGhhc2g9InNoYTI1NjplMTZiMjJjYmVmZGQzNTRiZWMxMTQ1NDFmNzg0OWExMmY4 ZmMyMDE1MzIwY2E1MjgyZWU0ZmQ3ODc1NzE0NTdiIj4KKyAgICA8L2JyYW5jaD4KKyAgPC9hdXRv dG9vbHM+CisKICAgPCEtLSBEZXBlbmRlbmNpZXMgbGlzdGVkIGJlbG93IHRoaXMgcG9pbnQgYXJl IG5vdCB0aG91Z2h0IHRvIGFmZmVjdCB0ZXN0IHJlc3VsdHMsIGFuZCBhcmUgb25seQogICAgICAg IGluY2x1ZGVkIGJlY2F1c2UgdGhleSB0aGVtc2VsdmVzIGRlcGVuZCBvbiBvdGhlciBkZXBlbmRl bmNpZXMgYnVpbHQgYnkgamhidWlsZC4gLS0+CiAK