87356 2012-05-24 02:02:57 -0700 [Chromium] File blob layout tests are failing since chromium r138702. 2012-06-13 21:01:58 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 vsevik ericu ericu jianli jsbell kinuko oldest_to_newest 632526 0 vsevik 2012-05-24 02:02:57 -0700 The following layout tests are failing on chromium fast/files/read-blob-async.html fast/files/workers/worker-read-blob-async.html fast/files/workers/worker-read-blob-sync.html This is caused by http://src.chromium.org/viewvc/chrome?view=rev&revision=138702 632528 1 vsevik 2012-05-24 02:03:41 -0700 --- /mnt/data/b/build/slave/Webkit_Linux/build/layout-test-results/fast/files/read-blob-async-expected.txt +++ /mnt/data/b/build/slave/Webkit_Linux/build/layout-test-results/fast/files/read-blob-async-actual.txt @@ -1,15 +1,21 @@ Test reading a blob containing non-existent file readyState: 0 -Received error event +Received loadstart event +readyState: 1 +Received load event readyState: 2 -error code: 1 +result size: 0 +result: Received loadend event Test reading a blob containing existent and non-existent file readyState: 0 -Received error event +Received loadstart event +readyState: 1 +Received load event readyState: 2 -error code: 1 +result size: 5 +result: Hello Received loadend event Test reading a blob containing empty file readyState: 0 --- /mnt/data/b/build/slave/Webkit_Linux/build/layout-test-results/fast/files/workers/worker-read-blob-async-expected.txt +++ /mnt/data/b/build/slave/Webkit_Linux/build/layout-test-results/fast/files/workers/worker-read-blob-async-actual.txt @@ -2,15 +2,21 @@ Received files in worker Test reading a blob containing non-existent file readyState: 0 -Received error event +Received loadstart event +readyState: 1 +Received load event readyState: 2 -error code: 1 +result size: 0 +result: Received loadend event Test reading a blob containing existent and non-existent file readyState: 0 -Received error event +Received loadstart event +readyState: 1 +Received load event readyState: 2 -error code: 1 +result size: 5 +result: Hello Received loadend event Test reading a blob containing empty file readyState: 0 --- /mnt/data/b/build/slave/Webkit_Linux/build/layout-test-results/fast/files/workers/worker-read-blob-sync-expected.txt +++ /mnt/data/b/build/slave/Webkit_Linux/build/layout-test-results/fast/files/workers/worker-read-blob-sync-actual.txt @@ -1,10 +1,12 @@ Received files in worker Test reading a blob containing non-existent file -Received exception 1: NOT_FOUND_ERR +result size: 0 +result: Received exception 8: NOT_FOUND_ERR Test reading a blob containing existent and non-existent file -Received exception 1: NOT_FOUND_ERR +result size: 5 +result: Hello Received exception 8: NOT_FOUND_ERR Test reading a blob containing empty file result size: 0 632567 2 vsevik 2012-05-24 02:51:39 -0700 Skipped in: https://trac.webkit.org/changeset/118337 637740 3 ericu 2012-05-30 15:05:50 -0700 Due to my Chromium change, the mechanism the test uses to set up blobs containing nonexistent files no longer works [for Chromium only]. We notice that the files don't exist, treat them as zero length, and don't bother to add them to the blob. Since this is only text fixture code, there's no real bug to fix, but we can't easily reproduce the test functionality without adding a bunch of code to DumpRenderTree. I think the right fix here is just to add Chromium-specific expectations for these three tests. Another alternative would be to break up the test into the pieces Chromium can handle and those it can't, and skip the latter, but that seems messier for non-Chromium ports. 637753 4 144937 ericu 2012-05-30 15:25:41 -0700 Created attachment 144937 Patch 644422 5 kinuko 2012-06-08 00:29:22 -0700 Is the chromium behavior (silently dropping a File reference for nonexisting file and not raising NotFoundError) right interms of the spec? Adding chrome-only exceptional behavior doesn't sound really right to me. http://www.w3.org/TR/FileAPI/#dfn-error-codes says: > If the File or Blob resource could not be found at the time the read was processed, then for asynchronous read methods the error attribute MUST return a "NotFoundError" DOMError and synchronous read methods MUST throw a NotFoundError exception. 646050 6 ericu 2012-06-11 10:04:13 -0700 (In reply to comment #5) > Is the chromium behavior (silently dropping a File reference for nonexisting file and not raising NotFoundError) right interms of the spec? Adding chrome-only exceptional behavior doesn't sound really right to me. > > http://www.w3.org/TR/FileAPI/#dfn-error-codes says: > > If the File or Blob resource could not be found at the time the read was processed, then for asynchronous read methods the error attribute MUST return a "NotFoundError" DOMError and synchronous read methods MUST throw a NotFoundError exception. Sorry--I should have added more information. There is still a problem here, that we're not raising NotFound, but this test isn't the right place for it. The reason for that is that this test creates the blobs via a private API that's not exposed to the web, and throwing an error out of that private API isn't helpful. You shouldn't be able to create a File that's not there--that what the private API lets you do. If you try to read a File that's not there [say you created a valid File, then deleted the underlying file], we'll still throw NotFound at the right place. However, if you have that File-with-no-file and add it to a Blob, we'll drop it silently, whereas the non-Chromium implementation will just add it. Perhaps we should be throwing NotFound when you do the addition? It's not really covered by the spec--the bit you quoted is about reads, but we're talking about Files that are invalid when used as constructor arguments. I think it would be reasonable to throw right then. We can't easily reenable this private API to create nonexistent files--the code gets pretty messy. Of course it's possible, but it would be a fair amount of churn and code that wouldn't benefit non-chromium ports at all, so I'm thinking that we should skip it. I'd been planning to log another bug suggesting that we throw in the Blob constructor, but perhaps we should just deal with it all here? 646706 7 kinuko 2012-06-12 00:47:02 -0700 (In reply to comment #6) > (In reply to comment #5) > > Is the chromium behavior (silently dropping a File reference for nonexisting file and not raising NotFoundError) right interms of the spec? Adding chrome-only exceptional behavior doesn't sound really right to me. > > > > http://www.w3.org/TR/FileAPI/#dfn-error-codes says: > > > If the File or Blob resource could not be found at the time the read was processed, then for asynchronous read methods the error attribute MUST return a "NotFoundError" DOMError and synchronous read methods MUST throw a NotFoundError exception. > > Sorry--I should have added more information. There is still a problem here, that we're not raising NotFound, but this test isn't the right place for it. The reason for that is that this test creates the blobs via a private API that's not exposed to the web, and throwing an error out of that private API isn't helpful. > > You shouldn't be able to create a File that's not there--that what the private API lets you do. If you try to read a File that's not there [say you created a valid File, then deleted the underlying file], we'll still throw NotFound at the right place. However, if you have that File-with-no-file and add it to a Blob, we'll drop it silently, whereas the non-Chromium implementation will just add it. Perhaps we should be throwing NotFound when you do the addition? It's not really covered by the spec--the bit you quoted is about reads, but we're talking about Files that are invalid when used as constructor arguments. I think it would be reasonable to throw right then. I think the same problem could happen on the real Web platform, since the error seems to be happening because we are creating a new Blob with non-existent files. We usually do not check the file's existence when we create a File object (in the current code) but do the check when we create a new Blob by combining a File or slicing a File. That's why we're getting length=0 file blob item in the backend. And in that case throwing an error when a read operation is initiated sounds valid to me. (Since otherwise creating a new Blob from an existing Blob/File needs synchronous file operation, though we happen to do so in the current WebKit/chromium code) Please correct me if I'm missing something. Thanks, > We can't easily reenable this private API to create nonexistent files--the code gets pretty messy. Of course it's possible, but it would be a fair amount of churn and code that wouldn't benefit non-chromium ports at all, so I'm thinking that we should skip it. I'd been planning to log another bug suggesting that we throw in the Blob constructor, but perhaps we should just deal with it all here? 647025 8 ericu 2012-06-12 09:59:55 -0700 (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Is the chromium behavior (silently dropping a File reference for nonexisting file and not raising NotFoundError) right interms of the spec? Adding chrome-only exceptional behavior doesn't sound really right to me. > > > > > > http://www.w3.org/TR/FileAPI/#dfn-error-codes says: > > > > If the File or Blob resource could not be found at the time the read was processed, then for asynchronous read methods the error attribute MUST return a "NotFoundError" DOMError and synchronous read methods MUST throw a NotFoundError exception. > > > > Sorry--I should have added more information. There is still a problem here, that we're not raising NotFound, but this test isn't the right place for it. The reason for that is that this test creates the blobs via a private API that's not exposed to the web, and throwing an error out of that private API isn't helpful. > > > > You shouldn't be able to create a File that's not there--that what the private API lets you do. If you try to read a File that's not there [say you created a valid File, then deleted the underlying file], we'll still throw NotFound at the right place. However, if you have that File-with-no-file and add it to a Blob, we'll drop it silently, whereas the non-Chromium implementation will just add it. Perhaps we should be throwing NotFound when you do the addition? It's not really covered by the spec--the bit you quoted is about reads, but we're talking about Files that are invalid when used as constructor arguments. I think it would be reasonable to throw right then. > > I think the same problem could happen on the real Web platform, since the error seems to be happening because we are creating a new Blob with non-existent files. We usually do not check the file's existence when we create a File object (in the current code) but do the check when we create a new Blob by combining a File or slicing a File. You're about to change that, though, right? Now we're going to snapshot the File when it's created? I thought that's where the discussion on WhatWG was going. > That's why we're getting length=0 file blob item in the backend. And in that case throwing an error when a read operation is initiated sounds valid to me. (Since otherwise creating a new Blob from an existing Blob/File needs synchronous file operation, though we happen to do so in the current WebKit/chromium code) Once we snapshot the File at creation time, there's no need for IO at slice time, so we wouldn't find out then. We'd either throw at creation, or get a read error, either of which seems correct to me. Then, since we won't be doing IO at slice time, this test either would work [if we rewrite it to somehow generate the same invalid File by other means] or not [if we don't so the exception would get thrown at File creation time, invalidating the test]. > Please correct me if I'm missing something. Thanks, > > > We can't easily reenable this private API to create nonexistent files--the code gets pretty messy. Of course it's possible, but it would be a fair amount of churn and code that wouldn't benefit non-chromium ports at all, so I'm thinking that we should skip it. I'd been planning to log another bug suggesting that we throw in the Blob constructor, but perhaps we should just deal with it all here? 647822 9 kinuko 2012-06-13 02:16:58 -0700 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > Is the chromium behavior (silently dropping a File reference for nonexisting file and not raising NotFoundError) right interms of the spec? Adding chrome-only exceptional behavior doesn't sound really right to me. > > > > > > > > http://www.w3.org/TR/FileAPI/#dfn-error-codes says: > > > > > If the File or Blob resource could not be found at the time the read was processed, then for asynchronous read methods the error attribute MUST return a "NotFoundError" DOMError and synchronous read methods MUST throw a NotFoundError exception. > > > > > > Sorry--I should have added more information. There is still a problem here, that we're not raising NotFound, but this test isn't the right place for it. The reason for that is that this test creates the blobs via a private API that's not exposed to the web, and throwing an error out of that private API isn't helpful. > > > > > > You shouldn't be able to create a File that's not there--that what the private API lets you do. If you try to read a File that's not there [say you created a valid File, then deleted the underlying file], we'll still throw NotFound at the right place. However, if you have that File-with-no-file and add it to a Blob, we'll drop it silently, whereas the non-Chromium implementation will just add it. Perhaps we should be throwing NotFound when you do the addition? It's not really covered by the spec--the bit you quoted is about reads, but we're talking about Files that are invalid when used as constructor arguments. I think it would be reasonable to throw right then. > > > > I think the same problem could happen on the real Web platform, since the error seems to be happening because we are creating a new Blob with non-existent files. We usually do not check the file's existence when we create a File object (in the current code) but do the check when we create a new Blob by combining a File or slicing a File. > > You're about to change that, though, right? Now we're going to snapshot the File when it's created? I thought that's where the discussion on WhatWG was going. We haven't made the change yet. I just want sure that the current chromium behavior is incompatible with the spec on the real environment too (partly due to the current WebKit code). If this sounds correct could you file a bug to track this chromium-specific behavior until we fix file snapshotting or the chromium behavior? Then I'll be happy to land this rebaseline. Thanks! > > That's why we're getting length=0 file blob item in the backend. And in that case throwing an error when a read operation is initiated sounds valid to me. (Since otherwise creating a new Blob from an existing Blob/File needs synchronous file operation, though we happen to do so in the current WebKit/chromium code) > > Once we snapshot the File at creation time, there's no need for IO at slice time, so we wouldn't find out then. We'd either throw at creation, or get a read error, either of which seems correct to me. > > Then, since we won't be doing IO at slice time, this test either would work [if we rewrite it to somehow generate the same invalid File by other means] or not [if we don't so the exception would get thrown at File creation time, invalidating the test]. > > > Please correct me if I'm missing something. Thanks, > > > > > We can't easily reenable this private API to create nonexistent files--the code gets pretty messy. Of course it's possible, but it would be a fair amount of churn and code that wouldn't benefit non-chromium ports at all, so I'm thinking that we should skip it. I'd been planning to log another bug suggesting that we throw in the Blob constructor, but perhaps we should just deal with it all here? 648428 10 ericu 2012-06-13 13:48:59 -0700 (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > (In reply to comment #5) > > > > > Is the chromium behavior (silently dropping a File reference for nonexisting file and not raising NotFoundError) right interms of the spec? Adding chrome-only exceptional behavior doesn't sound really right to me. > > > > > > > > > > http://www.w3.org/TR/FileAPI/#dfn-error-codes says: > > > > > > If the File or Blob resource could not be found at the time the read was processed, then for asynchronous read methods the error attribute MUST return a "NotFoundError" DOMError and synchronous read methods MUST throw a NotFoundError exception. > > > > > > > > Sorry--I should have added more information. There is still a problem here, that we're not raising NotFound, but this test isn't the right place for it. The reason for that is that this test creates the blobs via a private API that's not exposed to the web, and throwing an error out of that private API isn't helpful. > > > > > > > > You shouldn't be able to create a File that's not there--that what the private API lets you do. If you try to read a File that's not there [say you created a valid File, then deleted the underlying file], we'll still throw NotFound at the right place. However, if you have that File-with-no-file and add it to a Blob, we'll drop it silently, whereas the non-Chromium implementation will just add it. Perhaps we should be throwing NotFound when you do the addition? It's not really covered by the spec--the bit you quoted is about reads, but we're talking about Files that are invalid when used as constructor arguments. I think it would be reasonable to throw right then. > > > > > > I think the same problem could happen on the real Web platform, since the error seems to be happening because we are creating a new Blob with non-existent files. We usually do not check the file's existence when we create a File object (in the current code) but do the check when we create a new Blob by combining a File or slicing a File. > > > > You're about to change that, though, right? Now we're going to snapshot the File when it's created? I thought that's where the discussion on WhatWG was going. > > We haven't made the change yet. I just want sure that the current chromium behavior is incompatible with the spec on the real environment too (partly due to the current WebKit code). > > If this sounds correct could you file a bug to track this chromium-specific behavior until we fix file snapshotting or the chromium behavior? Then I'll be happy to land this rebaseline. Logged https://bugs.webkit.org/show_bug.cgi?id=89034; is that what you wanted? > Thanks! > > > > That's why we're getting length=0 file blob item in the backend. And in that case throwing an error when a read operation is initiated sounds valid to me. (Since otherwise creating a new Blob from an existing Blob/File needs synchronous file operation, though we happen to do so in the current WebKit/chromium code) > > > > Once we snapshot the File at creation time, there's no need for IO at slice time, so we wouldn't find out then. We'd either throw at creation, or get a read error, either of which seems correct to me. > > > > Then, since we won't be doing IO at slice time, this test either would work [if we rewrite it to somehow generate the same invalid File by other means] or not [if we don't so the exception would get thrown at File creation time, invalidating the test]. > > > > > Please correct me if I'm missing something. Thanks, > > > > > > > We can't easily reenable this private API to create nonexistent files--the code gets pretty messy. Of course it's possible, but it would be a fair amount of churn and code that wouldn't benefit non-chromium ports at all, so I'm thinking that we should skip it. I'd been planning to log another bug suggesting that we throw in the Blob constructor, but perhaps we should just deal with it all here? 648763 11 kinuko 2012-06-13 21:01:33 -0700 Committed r120273: <http://trac.webkit.org/changeset/120273> 144937 2012-05-30 15:25:41 -0700 2012-06-13 21:01:58 -0700 Patch bug-87356-20120530152540.patch text/plain 13941 ericu U3VidmVyc2lvbiBSZXZpc2lvbjogMTE4ODI3CmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9DaGFu Z2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKaW5kZXggNGNkMDJlNGQ1NDk2NmQ5N2RkZWJi ZDlmYWVlODFhNDlhMmEwNjk3NC4uODhkMjRiM2NhNmIzYjIxYzY4NGFjMzY3OTIyMGQ2ZTlmNTMz MjYxMiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCisrKyBiL0xheW91dFRlc3Rz L0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDEyLTA1LTMwICBFcmljIFVocmhhbmUgIDxl cmljdUBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgW0Nocm9taXVtXSBGaWxlIGJsb2IgbGF5b3V0 IHRlc3RzIGFyZSBmYWlsaW5nIHNpbmNlIGNocm9taXVtIHIxMzg3MDIuCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD04NzM1NgorCisgICAgICAgIFJlbW92 ZSBmYWlsaW5nIHRlc3Qgc2tpcDsgYWRkIENocm9taXVtLXNwZWNpZmljIGV4cGVjdGF0aW9ucy4K KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIHBsYXRm b3JtL2Nocm9taXVtL2Zhc3QvZmlsZXMvcmVhZC1ibG9iLWFzeW5jLWV4cGVjdGVkLnR4dDogQWRk ZWQuCisgICAgICAgICogcGxhdGZvcm0vY2hyb21pdW0vZmFzdC9maWxlcy93b3JrZXJzL3dvcmtl ci1yZWFkLWJsb2ItYXN5bmMtZXhwZWN0ZWQudHh0OiBBZGRlZC4KKyAgICAgICAgKiBwbGF0Zm9y bS9jaHJvbWl1bS9mYXN0L2ZpbGVzL3dvcmtlcnMvd29ya2VyLXJlYWQtYmxvYi1zeW5jLWV4cGVj dGVkLnR4dDogQWRkZWQuCisgICAgICAgICogcGxhdGZvcm0vY2hyb21pdW0vdGVzdF9leHBlY3Rh dGlvbnMudHh0OgorCiAyMDEyLTA1LTI5ICBKZXNzaWUgQmVybGluICA8amJlcmxpbkBhcHBsZS5j b20+CiAKICAgICAgICAgSlNDIGRvZXNuJ3Qgc3VwcG9ydCBoZWFwIHByb2ZpbGluZy4KZGlmZiAt LWdpdCBhL0xheW91dFRlc3RzL3BsYXRmb3JtL2Nocm9taXVtL2Zhc3QvZmlsZXMvcmVhZC1ibG9i LWFzeW5jLWV4cGVjdGVkLnR4dCBiL0xheW91dFRlc3RzL3BsYXRmb3JtL2Nocm9taXVtL2Zhc3Qv ZmlsZXMvcmVhZC1ibG9iLWFzeW5jLWV4cGVjdGVkLnR4dApuZXcgZmlsZSBtb2RlIDEwMDY0NApp bmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLi5kOTkwZWJlZWZk OGNmZjliNjdjNWI0MDhmZjg2YzVkZDFmNzNkNmU3Ci0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0 VGVzdHMvcGxhdGZvcm0vY2hyb21pdW0vZmFzdC9maWxlcy9yZWFkLWJsb2ItYXN5bmMtZXhwZWN0 ZWQudHh0CkBAIC0wLDAgKzEsMTc0IEBACisKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmlu ZyBub24tZXhpc3RlbnQgZmlsZQorcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQgbG9hZHN0YXJ0IGV2 ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFkeVN0YXRlOiAyCity ZXN1bHQgc2l6ZTogMAorcmVzdWx0OiAKK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVh ZGluZyBhIGJsb2IgY29udGFpbmluZyBleGlzdGVudCBhbmQgbm9uLWV4aXN0ZW50IGZpbGUKK3Jl YWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVj ZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTogMgorcmVzdWx0IHNpemU6IDUKK3Jlc3VsdDog SGVsbG8KK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFp bmluZyBlbXB0eSBmaWxlCityZWFkeVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQK K3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3Vs dCBzaXplOiAwCityZXN1bHQ6IAorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5n IGEgYmxvYiBjb250YWluaW5nIGVtcHR5IHRleHQKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxv YWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlT dGF0ZTogMgorcmVzdWx0IHNpemU6IDAKK3Jlc3VsdDogCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50 CitUZXN0IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgZW1wdHkgZmlsZXMgYW5kIGVtcHR5IHRl eHRzCityZWFkeVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6 IDEKK1JlY2VpdmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiAwCity ZXN1bHQ6IAorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250 YWluaW5nIHNpbmdsZSBmaWxlCityZWFkeVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZl bnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jl c3VsdCBzaXplOiA1CityZXN1bHQ6IEhlbGxvCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50CitUZXN0 IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgc2luZ2xlIHRleHQKK3JlYWR5U3RhdGU6IDAKK1Jl Y2VpdmVkIGxvYWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVu dAorcmVhZHlTdGF0ZTogMgorcmVzdWx0IHNpemU6IDUKK3Jlc3VsdDogRmlyc3QKK1JlY2VpdmVk IGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBzaW5nbGUgdGV4 dCBhcyBkYXRhIFVSTAorcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50City ZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQg c2l6ZTogMjAKK3Jlc3VsdDogZGF0YTpiYXNlNjQsUm1seWMzUT0KK1JlY2VpdmVkIGxvYWRlbmQg ZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBzaW5nbGUgdGV4dCBhcyBkYXRh IFVSTCAob3B0aW9uYWwgY29udGVudCB0eXBlIHByb3ZpZGVkKQorcmVhZHlTdGF0ZTogMAorUmVj ZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50 CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogMjkKK3Jlc3VsdDogZGF0YTp0eXBlL2Zvbzti YXNlNjQsUm1seWMzUT0KK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJs b2IgY29udGFpbmluZyBzaW5nbGUgQXJyYXlCdWZmZXIKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVk IGxvYWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVh ZHlTdGF0ZTogMgorcmVzdWx0IHNpemU6IDkKK3Jlc3VsdDogMHgwIDB4MSAweDIgMHg4MCAweDgx IDB4ODIgMHhmZCAweGZlIDB4ZmYKK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGlu ZyBhIGJsb2IgY29udGFpbmluZyBzbGljZWQgZmlsZQorcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQg bG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFk eVN0YXRlOiAyCityZXN1bHQgc2l6ZTogNQorcmVzdWx0OiBvbmRlcgorUmVjZWl2ZWQgbG9hZGVu ZCBldmVudAorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIHNsaWNlZCB0ZXh0CityZWFk eVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2Vp dmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiA0CityZXN1bHQ6IGly c3QKK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmlu ZyBzbGljZWQgQXJyYXlCdWZmZXIKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFydCBl dmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTogMgor cmVzdWx0IHNpemU6IDgKK3Jlc3VsdDogMHgxIDB4MiAweDgwIDB4ODEgMHg4MiAweGZkIDB4ZmUg MHhmZgorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWlu aW5nIG11bHRpcGxlIGZpbGVzCityZWFkeVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZl bnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jl c3VsdCBzaXplOiAxOQorcmVzdWx0OiBIZWxsb1dvbmRlcmZ1bFdvcmxkCitSZWNlaXZlZCBsb2Fk ZW5kIGV2ZW50CitUZXN0IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgbXVsdGlwbGUgdGV4dHMK K3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQor UmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTogMgorcmVzdWx0IHNpemU6IDE2CityZXN1 bHQ6IEZpcnN0U2Vjb25kVGhpcmQKK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGlu ZyBhIGJsb2IgY29udGFpbmluZyBtdWx0aXBsZSBBcnJheUJ1ZmZlcgorcmVhZHlTdGF0ZTogMAor UmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2 ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogOQorcmVzdWx0OiAweDAgMHgxIDB4MiAw eDgwIDB4ODEgMHg4MiAweGZkIDB4ZmUgMHhmZgorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVz dCByZWFkaW5nIGEgaHlicmlkIGJsb2IKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFy dCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTog MgorcmVzdWx0IHNpemU6IDM4CityZXN1bHQ6IEZpcnN0SGVsbG9TZWNvbmRXb25kZXJmdWxXb3Js ZFRoaXJkMDEyCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50CitUZXN0IHJlYWRpbmcgYSBzbGljZWQg aHlicmlkIGJsb2IKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFydCBldmVudAorcmVh ZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTogMgorcmVzdWx0IHNp emU6IDEyCityZXN1bHQ6IGxsb1NlY29uZFdvbgorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVz dCByZWFkaW5nIGEgdHJpcGxlLXNsaWNlZCBoeWJyaWQgYmxvYgorcmVhZHlTdGF0ZTogMAorUmVj ZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50 CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogMzAKK3Jlc3VsdDogb25kV29uZGVyZnVsV29y bGRUaGlyZDAxMkZvb2xvCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50CitET05FCisKZGlmZiAtLWdp dCBhL0xheW91dFRlc3RzL3BsYXRmb3JtL2Nocm9taXVtL2Zhc3QvZmlsZXMvd29ya2Vycy93b3Jr ZXItcmVhZC1ibG9iLWFzeW5jLWV4cGVjdGVkLnR4dCBiL0xheW91dFRlc3RzL3BsYXRmb3JtL2No cm9taXVtL2Zhc3QvZmlsZXMvd29ya2Vycy93b3JrZXItcmVhZC1ibG9iLWFzeW5jLWV4cGVjdGVk LnR4dApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwLi5hZTU3MzZhNjhhMDAxNzA5NmY0Njg2MjgwMzdmNDRiZjI1M2E0ODE3 Ci0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0VGVzdHMvcGxhdGZvcm0vY2hyb21pdW0vZmFzdC9m aWxlcy93b3JrZXJzL3dvcmtlci1yZWFkLWJsb2ItYXN5bmMtZXhwZWN0ZWQudHh0CkBAIC0wLDAg KzEsMTc1IEBACisKK1JlY2VpdmVkIGZpbGVzIGluIHdvcmtlcgorVGVzdCByZWFkaW5nIGEgYmxv YiBjb250YWluaW5nIG5vbi1leGlzdGVudCBmaWxlCityZWFkeVN0YXRlOiAwCitSZWNlaXZlZCBs b2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVkIGxvYWQgZXZlbnQKK3JlYWR5 U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiAwCityZXN1bHQ6IAorUmVjZWl2ZWQgbG9hZGVuZCBldmVu dAorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIGV4aXN0ZW50IGFuZCBub24tZXhpc3Rl bnQgZmlsZQorcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0 YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTog NQorcmVzdWx0OiBIZWxsbworUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5nIGEg YmxvYiBjb250YWluaW5nIGVtcHR5IGZpbGUKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRz dGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0 ZTogMgorcmVzdWx0IHNpemU6IDAKK3Jlc3VsdDogCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50CitU ZXN0IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgZW1wdHkgdGV4dAorcmVhZHlTdGF0ZTogMAor UmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2 ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogMAorcmVzdWx0OiAKK1JlY2VpdmVkIGxv YWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBlbXB0eSBmaWxlcyBh bmQgZW1wdHkgdGV4dHMKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFydCBldmVudAor cmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTogMgorcmVzdWx0 IHNpemU6IDAKK3Jlc3VsdDogCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50CitUZXN0IHJlYWRpbmcg YSBibG9iIGNvbnRhaW5pbmcgc2luZ2xlIGZpbGUKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxv YWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlT dGF0ZTogMgorcmVzdWx0IHNpemU6IDUKK3Jlc3VsdDogSGVsbG8KK1JlY2VpdmVkIGxvYWRlbmQg ZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBzaW5nbGUgdGV4dAorcmVhZHlT dGF0ZTogMAorUmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZl ZCBsb2FkIGV2ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogNQorcmVzdWx0OiBGaXJz dAorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5n IHNpbmdsZSB0ZXh0IGFzIGRhdGEgVVJMCityZWFkeVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3Rh cnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6 IDIKK3Jlc3VsdCBzaXplOiAyMAorcmVzdWx0OiBkYXRhOmJhc2U2NCxSbWx5YzNRPQorUmVjZWl2 ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIHNpbmdsZSB0 ZXh0IGFzIGRhdGEgVVJMIChvcHRpb25hbCBjb250ZW50IHR5cGUgcHJvdmlkZWQpCityZWFkeVN0 YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVk IGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiAyOQorcmVzdWx0OiBkYXRh OnR5cGUvZm9vO2Jhc2U2NCxSbWx5YzNRPQorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCBy ZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIHNpbmdsZSBBcnJheUJ1ZmZlcgorcmVhZHlTdGF0ZTog MAorUmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2Fk IGV2ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogOQorcmVzdWx0OiAweDAgMHgxIDB4 MiAweDgwIDB4ODEgMHg4MiAweGZkIDB4ZmUgMHhmZgorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAor VGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIHNsaWNlZCBmaWxlCityZWFkeVN0YXRlOiAw CitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVkIGxvYWQg ZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiA1CityZXN1bHQ6IG9uZGVyCitSZWNl aXZlZCBsb2FkZW5kIGV2ZW50CitUZXN0IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgc2xpY2Vk IHRleHQKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxvYWRzdGFydCBldmVudAorcmVhZHlTdGF0 ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlTdGF0ZTogMgorcmVzdWx0IHNpemU6IDQK K3Jlc3VsdDogaXJzdAorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAorVGVzdCByZWFkaW5nIGEgYmxv YiBjb250YWluaW5nIHNsaWNlZCBBcnJheUJ1ZmZlcgorcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQg bG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFk eVN0YXRlOiAyCityZXN1bHQgc2l6ZTogOAorcmVzdWx0OiAweDEgMHgyIDB4ODAgMHg4MSAweDgy IDB4ZmQgMHhmZSAweGZmCitSZWNlaXZlZCBsb2FkZW5kIGV2ZW50CitUZXN0IHJlYWRpbmcgYSBi bG9iIGNvbnRhaW5pbmcgbXVsdGlwbGUgZmlsZXMKK3JlYWR5U3RhdGU6IDAKK1JlY2VpdmVkIGxv YWRzdGFydCBldmVudAorcmVhZHlTdGF0ZTogMQorUmVjZWl2ZWQgbG9hZCBldmVudAorcmVhZHlT dGF0ZTogMgorcmVzdWx0IHNpemU6IDE5CityZXN1bHQ6IEhlbGxvV29uZGVyZnVsV29ybGQKK1Jl Y2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBtdWx0 aXBsZSB0ZXh0cworcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFk eVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6 ZTogMTYKK3Jlc3VsdDogRmlyc3RTZWNvbmRUaGlyZAorUmVjZWl2ZWQgbG9hZGVuZCBldmVudAor VGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIG11bHRpcGxlIEFycmF5QnVmZmVyCityZWFk eVN0YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2Vp dmVkIGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiA5CityZXN1bHQ6IDB4 MCAweDEgMHgyIDB4ODAgMHg4MSAweDgyIDB4ZmQgMHhmZSAweGZmCitSZWNlaXZlZCBsb2FkZW5k IGV2ZW50CitUZXN0IHJlYWRpbmcgYSBoeWJyaWQgYmxvYgorcmVhZHlTdGF0ZTogMAorUmVjZWl2 ZWQgbG9hZHN0YXJ0IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50City ZWFkeVN0YXRlOiAyCityZXN1bHQgc2l6ZTogMzgKK3Jlc3VsdDogRmlyc3RIZWxsb1NlY29uZFdv bmRlcmZ1bFdvcmxkVGhpcmQwMTIKK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK1Rlc3QgcmVhZGlu ZyBhIHNsaWNlZCBoeWJyaWQgYmxvYgorcmVhZHlTdGF0ZTogMAorUmVjZWl2ZWQgbG9hZHN0YXJ0 IGV2ZW50CityZWFkeVN0YXRlOiAxCitSZWNlaXZlZCBsb2FkIGV2ZW50CityZWFkeVN0YXRlOiAy CityZXN1bHQgc2l6ZTogMTIKK3Jlc3VsdDogbGxvU2Vjb25kV29uCitSZWNlaXZlZCBsb2FkZW5k IGV2ZW50CitUZXN0IHJlYWRpbmcgYSB0cmlwbGUtc2xpY2VkIGh5YnJpZCBibG9iCityZWFkeVN0 YXRlOiAwCitSZWNlaXZlZCBsb2Fkc3RhcnQgZXZlbnQKK3JlYWR5U3RhdGU6IDEKK1JlY2VpdmVk IGxvYWQgZXZlbnQKK3JlYWR5U3RhdGU6IDIKK3Jlc3VsdCBzaXplOiAzMAorcmVzdWx0OiBvbmRX b25kZXJmdWxXb3JsZFRoaXJkMDEyRm9vbG8KK1JlY2VpdmVkIGxvYWRlbmQgZXZlbnQKK0RPTkUK KwpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvcGxhdGZvcm0vY2hyb21pdW0vZmFzdC9maWxlcy93 b3JrZXJzL3dvcmtlci1yZWFkLWJsb2Itc3luYy1leHBlY3RlZC50eHQgYi9MYXlvdXRUZXN0cy9w bGF0Zm9ybS9jaHJvbWl1bS9mYXN0L2ZpbGVzL3dvcmtlcnMvd29ya2VyLXJlYWQtYmxvYi1zeW5j LWV4cGVjdGVkLnR4dApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLi5mNThhYmYwYTlhZDliZDRiNWEzMjFiZjkxZmFkOGFh OTE3MjgzZDVlCi0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0VGVzdHMvcGxhdGZvcm0vY2hyb21p dW0vZmFzdC9maWxlcy93b3JrZXJzL3dvcmtlci1yZWFkLWJsb2Itc3luYy1leHBlY3RlZC50eHQK QEAgLTAsMCArMSw4MCBAQAorCitSZWNlaXZlZCBmaWxlcyBpbiB3b3JrZXIKK1Rlc3QgcmVhZGlu ZyBhIGJsb2IgY29udGFpbmluZyBub24tZXhpc3RlbnQgZmlsZQorcmVzdWx0IHNpemU6IDAKK3Jl c3VsdDogCitSZWNlaXZlZCBleGNlcHRpb24gODogTk9UX0ZPVU5EX0VSUgorVGVzdCByZWFkaW5n IGEgYmxvYiBjb250YWluaW5nIGV4aXN0ZW50IGFuZCBub24tZXhpc3RlbnQgZmlsZQorcmVzdWx0 IHNpemU6IDUKK3Jlc3VsdDogSGVsbG8KK1JlY2VpdmVkIGV4Y2VwdGlvbiA4OiBOT1RfRk9VTkRf RVJSCitUZXN0IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgZW1wdHkgZmlsZQorcmVzdWx0IHNp emU6IDAKK3Jlc3VsdDogCitSZWNlaXZlZCBleGNlcHRpb24gODogTk9UX0ZPVU5EX0VSUgorVGVz dCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIGVtcHR5IHRleHQKK3Jlc3VsdCBzaXplOiAwCity ZXN1bHQ6IAorUmVjZWl2ZWQgZXhjZXB0aW9uIDg6IE5PVF9GT1VORF9FUlIKK1Rlc3QgcmVhZGlu ZyBhIGJsb2IgY29udGFpbmluZyBlbXB0eSBmaWxlcyBhbmQgZW1wdHkgdGV4dHMKK3Jlc3VsdCBz aXplOiAwCityZXN1bHQ6IAorUmVjZWl2ZWQgZXhjZXB0aW9uIDg6IE5PVF9GT1VORF9FUlIKK1Rl c3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBzaW5nbGUgZmlsZQorcmVzdWx0IHNpemU6IDUK K3Jlc3VsdDogSGVsbG8KK1JlY2VpdmVkIGV4Y2VwdGlvbiA4OiBOT1RfRk9VTkRfRVJSCitUZXN0 IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgc2luZ2xlIHRleHQKK3Jlc3VsdCBzaXplOiA1City ZXN1bHQ6IEZpcnN0CitSZWNlaXZlZCBleGNlcHRpb24gODogTk9UX0ZPVU5EX0VSUgorVGVzdCBy ZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIHNpbmdsZSB0ZXh0IGFzIGRhdGEgVVJMCityZXN1bHQg c2l6ZTogMjAKK3Jlc3VsdDogZGF0YTpiYXNlNjQsUm1seWMzUT0KK1JlY2VpdmVkIGV4Y2VwdGlv biA4OiBOT1RfRk9VTkRfRVJSCitUZXN0IHJlYWRpbmcgYSBibG9iIGNvbnRhaW5pbmcgc2luZ2xl IHRleHQgYXMgZGF0YSBVUkwgKG9wdGlvbmFsIGNvbnRlbnQgdHlwZSBwcm92aWRlZCkKK3Jlc3Vs dCBzaXplOiAyOQorcmVzdWx0OiBkYXRhOnR5cGUvZm9vO2Jhc2U2NCxSbWx5YzNRPQorUmVjZWl2 ZWQgZXhjZXB0aW9uIDg6IE5PVF9GT1VORF9FUlIKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFp bmluZyBzaW5nbGUgQXJyYXlCdWZmZXIKK3Jlc3VsdCBzaXplOiA5CityZXN1bHQ6IDB4MCAweDEg MHgyIDB4ODAgMHg4MSAweDgyIDB4ZmQgMHhmZSAweGZmCitSZWNlaXZlZCBleGNlcHRpb24gODog Tk9UX0ZPVU5EX0VSUgorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIHNsaWNlZCBmaWxl CityZXN1bHQgc2l6ZTogNQorcmVzdWx0OiBvbmRlcgorUmVjZWl2ZWQgZXhjZXB0aW9uIDg6IE5P VF9GT1VORF9FUlIKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBzbGljZWQgdGV4dAor cmVzdWx0IHNpemU6IDQKK3Jlc3VsdDogaXJzdAorUmVjZWl2ZWQgZXhjZXB0aW9uIDg6IE5PVF9G T1VORF9FUlIKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBzbGljZWQgQXJyYXlCdWZm ZXIKK3Jlc3VsdCBzaXplOiA4CityZXN1bHQ6IDB4MSAweDIgMHg4MCAweDgxIDB4ODIgMHhmZCAw eGZlIDB4ZmYKK1JlY2VpdmVkIGV4Y2VwdGlvbiA4OiBOT1RfRk9VTkRfRVJSCitUZXN0IHJlYWRp bmcgYSBibG9iIGNvbnRhaW5pbmcgbXVsdGlwbGUgZmlsZXMKK3Jlc3VsdCBzaXplOiAxOQorcmVz dWx0OiBIZWxsb1dvbmRlcmZ1bFdvcmxkCitSZWNlaXZlZCBleGNlcHRpb24gODogTk9UX0ZPVU5E X0VSUgorVGVzdCByZWFkaW5nIGEgYmxvYiBjb250YWluaW5nIG11bHRpcGxlIHRleHRzCityZXN1 bHQgc2l6ZTogMTYKK3Jlc3VsdDogRmlyc3RTZWNvbmRUaGlyZAorUmVjZWl2ZWQgZXhjZXB0aW9u IDg6IE5PVF9GT1VORF9FUlIKK1Rlc3QgcmVhZGluZyBhIGJsb2IgY29udGFpbmluZyBtdWx0aXBs ZSBBcnJheUJ1ZmZlcgorcmVzdWx0IHNpemU6IDkKK3Jlc3VsdDogMHgwIDB4MSAweDIgMHg4MCAw eDgxIDB4ODIgMHhmZCAweGZlIDB4ZmYKK1JlY2VpdmVkIGV4Y2VwdGlvbiA4OiBOT1RfRk9VTkRf RVJSCitUZXN0IHJlYWRpbmcgYSBoeWJyaWQgYmxvYgorcmVzdWx0IHNpemU6IDM4CityZXN1bHQ6 IEZpcnN0SGVsbG9TZWNvbmRXb25kZXJmdWxXb3JsZFRoaXJkMDEyCitSZWNlaXZlZCBleGNlcHRp b24gODogTk9UX0ZPVU5EX0VSUgorVGVzdCByZWFkaW5nIGEgc2xpY2VkIGh5YnJpZCBibG9iCity ZXN1bHQgc2l6ZTogMTIKK3Jlc3VsdDogbGxvU2Vjb25kV29uCitSZWNlaXZlZCBleGNlcHRpb24g ODogTk9UX0ZPVU5EX0VSUgorVGVzdCByZWFkaW5nIGEgdHJpcGxlLXNsaWNlZCBoeWJyaWQgYmxv YgorcmVzdWx0IHNpemU6IDMwCityZXN1bHQ6IG9uZFdvbmRlcmZ1bFdvcmxkVGhpcmQwMTJGb29s bworUmVjZWl2ZWQgZXhjZXB0aW9uIDg6IE5PVF9GT1VORF9FUlIKK0RPTkUKKwpkaWZmIC0tZ2l0 IGEvTGF5b3V0VGVzdHMvcGxhdGZvcm0vY2hyb21pdW0vdGVzdF9leHBlY3RhdGlvbnMudHh0IGIv TGF5b3V0VGVzdHMvcGxhdGZvcm0vY2hyb21pdW0vdGVzdF9leHBlY3RhdGlvbnMudHh0CmluZGV4 IDE2NjMxMzdmMTdlNGMyYmJjOWUwZGQxMjMxZmMzYWMwMTA2ZGQzZmUuLjM4MWM0ZGViM2ViZjM2 YTEzNDE1ZGQ2NDFmNjJmNTc3NmRkYWU3NzcgMTAwNjQ0Ci0tLSBhL0xheW91dFRlc3RzL3BsYXRm b3JtL2Nocm9taXVtL3Rlc3RfZXhwZWN0YXRpb25zLnR4dAorKysgYi9MYXlvdXRUZXN0cy9wbGF0 Zm9ybS9jaHJvbWl1bS90ZXN0X2V4cGVjdGF0aW9ucy50eHQKQEAgLTM3NjQsMTMgKzM3NjQsOCBA QCBCVUdXSzg3MjczIDogd2ViYXVkaW8vYXVkaW9wYXJhbS1jb25uZWN0LWF1ZGlvcmF0ZXNpZ25h bC5odG1sID0gVElNRU9VVCBQQVNTCiBCVUdXSzg3MzIxIFhQIDogZmFzdC9oaXN0b3J5L2hpc3Rv cnktc3ViZnJhbWUtd2l0aC1uYW1lLmh0bWwgPSBURVhUIFBBU1MKIEJVR1dLODczMjEgWFAgOiBm YXN0L2hpc3RvcnkvaGlzdG9yeS10cmF2ZXJzYWwtaXMtYXN5bmNocm9ub3VzLmh0bWwgPSBURVhU IFBBU1MKIAotLy8gRmlsZSBibG9iIHRlc3RzIGZhaWxpbmcgYWZ0ZXIgY2hyb21pdW0gcjEzODcw MgotQlVHV0s4NzM1NiA6IGZhc3QvZmlsZXMvcmVhZC1ibG9iLWFzeW5jLmh0bWwgPSBURVhUCi1C VUdXSzg3MzU2IDogZmFzdC9maWxlcy93b3JrZXJzL3dvcmtlci1yZWFkLWJsb2ItYXN5bmMuaHRt bCA9IFRFWFQKLUJVR1dLODczNTYgOiBmYXN0L2ZpbGVzL3dvcmtlcnMvd29ya2VyLXJlYWQtYmxv Yi1zeW5jLmh0bWwgPSBURVhUCi0vLyBUaGUgYWJvdmUgdGVzdHMgd2VyZSBwcmV2aW91c2x5IG1h cmtlZCBhcyBmb2xsb3dzOgotLy8gQlVHV0s3OTU0MCBERUJVRyA6IGZhc3QvZmlsZXMvd29ya2Vy cy93b3JrZXItcmVhZC1ibG9iLWFzeW5jLmh0bWwgPSBQQVNTIENSQVNICi0vLyBCVUdXSzc5NTQw IERFQlVHIDogZmFzdC9maWxlcy93b3JrZXJzL3dvcmtlci1yZWFkLWJsb2Itc3luYy5odG1sID0g UEFTUyBDUkFTSAorQlVHV0s3OTU0MCBERUJVRyA6IGZhc3QvZmlsZXMvd29ya2Vycy93b3JrZXIt cmVhZC1ibG9iLWFzeW5jLmh0bWwgPSBQQVNTIENSQVNICitCVUdXSzc5NTQwIERFQlVHIDogZmFz dC9maWxlcy93b3JrZXJzL3dvcmtlci1yZWFkLWJsb2Itc3luYy5odG1sID0gUEFTUyBDUkFTSAog CiAvLyBTaGFkb3cgRE9NIGRyb3AgZXZlbnQgdGVzdHMgYXJlIHZlcnkgZmxha3kgc2luY2UgY3Jl YXRpb24KIEJVR1dLODczNjQgREVCVUcgOiBmYXN0L2RvbS9zaGFkb3cvZHJvcC1ldmVudC1mb3It aW5wdXQtaW4tc2hhZG93Lmh0bWwgPSBURVhUIFBBU1MK