Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fPhxp-0001oE-DD for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jun 2018 05:23:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fPhxn-0004Yz-Qi for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jun 2018 05:23:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fPhxn-0004Yp-FY for pgadmin-hackers@lists.postgresql.org; Mon, 04 Jun 2018 05:23:27 +0000 Received: from mail-lf0-x241.google.com ([2a00:1450:4010:c07::241]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fPhxi-0002VE-G8 for pgadmin-hackers@postgresql.org; Mon, 04 Jun 2018 05:23:26 +0000 Received: by mail-lf0-x241.google.com with SMTP id d24-v6so23156949lfa.8 for ; Sun, 03 Jun 2018 22:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+vUbQ7YbA6EMI/wdCSGqfDBQhaAkm8vV7XMHRBusvI0=; b=IYOAaygPpvyGlxJqw/ALv9hjCU03/+yAbnnsa7ag4J0ir6SmHM85IpBoy/QV6aU/ws RJ2LkKljGUAL0DJhy4mUms/MDgmlR4H+pr9WuGnD5eivxAM6KOgQTtJSxBgZmgt3Dxl1 6OaadmYuG1+I0qSt/kk5QafRbGVyD5rF0Q9ggyBXTGz5v8CHn9orEFBwuyLRr0UzvRA/ hRgBO5ZTevf4yLfr/1D00+ojMLAXgzt1NBfzUDdCuyU2YpGwE9cF5FkdAcNrXU4DKium bBi9UBGWdVb4LYZnjnGhTfaVI6g2fGCMeby2os/oisP5JLvzD3sJ3BmOTGu0Q2LcSnQU O8IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+vUbQ7YbA6EMI/wdCSGqfDBQhaAkm8vV7XMHRBusvI0=; b=cb893BejAP5AZNvG/VJGnzLV864RosxFL4P4kV03ux2LeUWwwbBj2iaiPLRmoTcEvO cvQy5AkoMy99BUmDMcGKhM4X+pi9K3erigoSnNb3JlWagWaBsfhwAIFrs4qJQ3SU/TSz 3XnrMOH0Uslj49601H0iQ6jnsugd5mtp2nU91vJCb8Hu6JzSLCW82yacz6uhltfFbCP/ Z24ckKqFK9RTqA7UXsWe8nkn1Wl4UUpJkKkpQeub6rZuwnn45rzjXM+6iwD9BGg2jXuB Di+ATMrgKxwKEsAtP0SJt3/33sjOT5zZvZCpiFX8/Jrw53YzMnDwbkEcXK1VwHvM+Jwl 5WRw== X-Gm-Message-State: ALKqPweJQRcFCtrqD/NdCs4I4g9sxUejXxKMmCh998L2PJD+sGF6tMfF 69tXpbs2jTsd4Ow0lx0UeCvY7RJTejRenYy8ZGg8SQ== X-Google-Smtp-Source: ADUXVKK5UJZdRgcJuASb5mSZFcbNIiCElH3Qsv76MawGnMJhcAwoL4dg9aRXWSnsgYC1+2AEnsTj/HVjmQfQmvRpLnM= X-Received: by 2002:a19:1156:: with SMTP id g83-v6mr11276935lfi.142.1528089800998; Sun, 03 Jun 2018 22:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:9e8a:0:0:0:0:0 with HTTP; Sun, 3 Jun 2018 22:23:20 -0700 (PDT) In-Reply-To: References: From: Aditya Toshniwal Date: Mon, 4 Jun 2018 10:53:20 +0530 Message-ID: Subject: Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database. To: Dave Page Cc: Joao De Almeida Pereira , pgadmin-hackers Content-Type: multipart/mixed; boundary="000000000000c630ee056dca2104" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000c630ee056dca2104 Content-Type: multipart/alternative; boundary="000000000000c630ea056dca2102" --000000000000c630ea056dca2102 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hackers, PFA the updated patch on this. I have tried to add test cases to check for different encoding database. In the test run, it will create a database, fire a query for a string, check if we get the output and drops the database. Kindly review. Thanks and Regards, Aditya Toshniwal Software Engineer | EnterpriseDB Software Solutions | Pune "Don't Complain about Heat, Plant a tree" On Thu, May 31, 2018 at 6:42 PM, Dave Page wrote: > Hi > > On Thu, May 31, 2018 at 1:20 AM, Aditya Toshniwal enterprisedb.com> wrote: > >> Hi Victoria/Joao, >> >> On Thu, May 31, 2018 at 2:06 AM, Joao De Almeida Pereira < >> jdealmeidapereira@pivotal.io> wrote: >> >>> Hello Aditya, >>> >>> It looks ok and it passes CI. >>> >>> We have some recommendations: >>> - These look like 2 different changes so they should be in separated >>> commits >>> >> >> If you are talking of set client_encoding, then its not a bug. Its a >> choice given to Postgres DB user to change the encoding of the character= s. >> Postgres will translate characters from Server Encoding to Client Encodi= ng, >> and will throw error like mentioned previously. This link will help bett= er >> - https://www.postgresql.org/docs/10/static/multibyte.html >> The actual bug was, even after changing the client encoding to SQL_ASCII= , >> pgAdmin4 was not able to show the output as it was failing in encoding b= y >> psycopg2. The patch is for resolving that. >> >> >>> - Do we have test coverage for the bug that you are talking about? If >>> not we should, to ensure this problem does not happen again in a future >>> change. >>> >> >> It is not possible adding test cases for encoding related stuff, as >> Postgres support a lot many different types of encoding and conversions >> (refer above link) >> > > I was going to ask the same thing. Per https://www.postgresql. > org/docs/10/static/multibyte.html#id-1.6.10.5.7, every characterset > except SQL_ASCII can be converted to UTF-8, so we only need to test that > UTF-8 and some other charactersets besides SQL_ASCII work, and then > separately that SQL_ASCII with characters known not to be in UTF-8 work. > > >> >>> Thanks >>> Victoria && Joao >>> >>> On Wed, May 30, 2018 at 3:06 AM Aditya Toshniwal < >>> aditya.toshniwal@enterprisedb.com> wrote: >>> >>>> Hi Hackers, >>>> >>>> PFA updated patch after all the permutations, combinations for encodin= g >>>> for SQL_ASCII database. Also fixed a small glitch for sql editor >>>> connection status check. >>>> >>>> Please note, ERROR: invalid byte sequence for encoding "UTF8": 0xe9 >>>> 0x73 is a Postgres DB error and not pgAdmin4 error. >>>> >>>> >>>> >>>> You need to change client_encoding to the appropriate. After changing >>>> client_encoding using command - set client_encoding=3D'XYZ', it will g= ive not >>>> give error. >>>> >>>> >>>> >>>> Thanks and Regards, >>>> Aditya Toshniwal >>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>> "Don't Complain about Heat, Plant a tree" >>>> >>>> On Wed, May 23, 2018 at 10:13 AM, Aditya Toshniwal < >>>> aditya.toshniwal@enterprisedb.com> wrote: >>>> >>>>> Thank you Victoria, Anthony. >>>>> >>>>> Thanks and Regards, >>>>> Aditya Toshniwal >>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>> "Don't Complain about Heat, Plant a tree" >>>>> >>>>> On Tue, May 22, 2018 at 7:15 PM, Victoria Henry >>>>> wrote: >>>>> >>>>>> Hi Aditya, >>>>>> >>>>>> We made a minor change to make the patch so the python linter can >>>>>> pass. Attached is the change we made. >>>>>> Everything else looks good. >>>>>> >>>>>> Sincerely, >>>>>> >>>>>> Victoria & Anthony >>>>>> >>>>>> On Tue, May 22, 2018 at 4:46 AM Aditya Toshniwal < >>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> PFA updated patch. Linter issues are fixed ( we dont have any linte= r >>>>>>> setup for python :-( ) >>>>>>> Regarding test cases, they run successfully on my system and the >>>>>>> reason it failed for pivotal is timeout exception. I am sorry I can= 't help >>>>>>> with that. >>>>>>> >>>>>>> Traceback (most recent call last): >>>>>>> File "/tmp/build/a453582b/pgadmin-repo/web/pgadmin/feature_tests/= keyboard_shortcut_test.py", >>>>>>> line 52, in runTest >>>>>>> self._check_shortcuts() >>>>>>> File "/tmp/build/a453582b/pgadmin-repo/web/pgadmin/feature_tests/= keyboard_shortcut_test.py", >>>>>>> line 77, in _check_shortcuts >>>>>>> ") and contains(@class, 'open')]") >>>>>>> File "/root/.pyenv/versions/pgadmin36/lib/python3.6/site-packages >>>>>>> /selenium/webdriver/support/wait.py", line 80, in until >>>>>>> raise TimeoutException(message, screen, stacktrace) >>>>>>> selenium.common.exceptions.TimeoutException: Message: >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> Aditya Toshniwal >>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>> >>>>>>> On Tue, May 22, 2018 at 1:37 PM, Dave Page >>>>>>> wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> Pivotal's buildbot is showing problems with this patch: >>>>>>>> >>>>>>>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines >>>>>>>> /pgadmin-patch/jobs/run-linter/builds/66 (linter failed) >>>>>>>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines >>>>>>>> /pgadmin-patch/jobs/run-tests/builds/84 (tests failed) >>>>>>>> >>>>>>>> >>>>>>>> On Tue, May 22, 2018 at 7:05 AM, Aditya Toshniwal < >>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> Hi Hackers, >>>>>>>>> >>>>>>>>> PFA patch for RM#3289 where decode error was thrown on querying a >>>>>>>>> SQL_ASCII database table. Please note, this problem occurs only o= n windows. >>>>>>>>> Sample insert - insert into test_tab values ('=C3=A9'); >>>>>>>>> >>>>>>>>> psycopg2 has a encodings dictionary where Postgres Database >>>>>>>>> Encodings are mapped to python equivalent. It uses 'ascii' decode= r of >>>>>>>>> python to decode for SQL_ASCII encoding. If data has characters b= eyond the >>>>>>>>> limit of ascii then it failed. The solution would be to use utf_8= decoder >>>>>>>>> instead of ascii. I tried setting the client_encoding using >>>>>>>>> set_client_encoding('UTF8') method of a psycopg2 connection but n= o luck >>>>>>>>> (also its not allowed for async connection). I also tried executi= ng "SET >>>>>>>>> CLIENT_ENCODING=3D'UTF8'" but it didn't work too. >>>>>>>>> So, as in the patch, I had to set encodings dict value directly t= o >>>>>>>>> 'utf_8' and it seems to be working. Please note, the same is adde= d to >>>>>>>>> psycopg3 milestones >>>>>>>>> https://github.com/psycopg/psycopg2/milestone/4 >>>>>>>>> >>>>>>>>> Also fixed a small glitch for sql editor connection status check. >>>>>>>>> >>>>>>>>> Kindly review. >>>>>>>>> >>>>>>>>> Thanks and Regards, >>>>>>>>> Aditya Toshniwal >>>>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dave Page >>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>> Twitter: @pgsnake >>>>>>>> >>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>> The Enterprise PostgreSQL Company >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >> > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --000000000000c630ea056dca2102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hackers,

PFA the updated patch on th= is. I have tried to add test cases to check for different encoding database= . In the test run, it will create a database, fire a query for a string, ch= eck if we get the output and drops the database.
Kindly review.

Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0EnterpriseDB Software Solutions= |=C2=A0Pune
"Don't Complain about Heat, Plant a tree&quo= t;

On Thu, May 31, 2018 at 6:42 PM, Dave Page <= span dir=3D"ltr"><dpage@pgadmin.org> wrote:
=
Hi

On Thu, May 31, 2018 at 1:20 AM, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote= :
Hi = Victoria/Joao,

On Thu, May 31, 2018 at= 2:06 AM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io= > wrote:
Hello Aditya,

It looks ok and it passe= s CI.

We have some recommendations:
- Th= ese look like 2 different changes so they should be in separated commits
=C2=A0
https://www.postgresql.org/docs/10/= static/multibyte.html
The actual bu= g was, even after changing the client encoding to SQL_ASCII, pgAdmin4 was n= ot able to show the output as it was failing in encoding by psycopg2. The p= atch is for resolving that.
=C2=A0
- Do we have test coverage for the bug that you = are talking about? If not we should, to ensure this problem does not happen= again in a future change.

It is not possible adding test cases for encoding related stuff, as Post= gres support a lot many different types of encoding and conversions (refer = above link)=C2=A0

I was going to ask the same thing. Per=C2=A0https://www.postgresql.org/docs/10/static/multibyte.html#id-1.6.= 10.5.7, every characterset except SQL_ASCII can be converted to UTF-8, = so we only need to test that UTF-8 and some other charactersets besides SQL= _ASCII work, and then separately that SQL_ASCII with characters known not t= o be in UTF-8 work.
=C2=A0

Thanks
Victoria &= amp;& Joao

On Wed, May 30, 2018 at 3:06 AM Aditya Toshn= iwal <aditya.toshniwal@enterprisedb.com> wrote:
=
Hi Hackers,

PFA upda= ted patch after all the permutations, combinations for encoding for SQL_ASC= II database.=C2=A0 Also fixed a small glitch for sql editor connect= ion status check.

Please note,=C2=A0ERROR: invalid byte sequence fo= r encoding "UTF8": 0xe9 0x73 is a Postgres DB error and not pgAdm= in4 error.

<Image Deleted>
=

You need to= change client_encoding to the appropriate. After changing client_encoding = using command - set client_encoding=3D'XYZ', it will give not give = error.

&= lt;Image Deleted>

Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0EnterpriseDB Software Sol= utions |=C2=A0Pune
"Don't Complain about Heat, Plant a tr= ee"

On Wed, May 23, 2018 at 10:13 AM, Aditya Tos= hniwal <aditya.toshniwal@enterprisedb.com> wrote:
Thank you Victoria, Anthony.
Thanks and Regards,
Aditya Toshniwal
Software Engine= er |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don&#= 39;t Complain about Heat, Plant a tree"

On Tue, May 22, 2018 at 7:15 PM, Victoria Henry <<= a href=3D"mailto:vhenry@pivotal.io" target=3D"_blank">vhenry@pivotal.io= > wrote:
Hi Aditya,

We made a minor change to make = the patch so the python linter can pass.=C2=A0 Attached is the change we ma= de.
Everything else looks good.

Sincerel= y,

Victoria & Anthony

On Tue, May 22, 2018 at 4:46 AM Aditya Toshniwal <aditya.toshniwal@ente= rprisedb.com> wrote:
Hi,

PFA updated patch.= Linter issues are fixed ( we dont have any linter setup for python :-( )
Regarding test cases, they run successfully on my system and the r= eason it failed for pivotal is timeout exception. I am sorry I can't he= lp with that.

Traceback (most recent call last):
=C2= =A0 File "/tmp/build/a453582b/pgadmin-repo/web/pgadmin/feature_te= sts/keyboard_shortcut_test.py", line 52, in runTest
=C2=A0 =C2= =A0 self._check_shortcuts()
=C2=A0 File "/tmp/build/a453582b/pgadmi= n-repo/web/pgadmin/feature_tests/keyboard_shortcut_test.py",= line 77, in _check_shortcuts
=C2=A0 =C2=A0 ") and contains(@class,= 'open')]")
=C2=A0 File "/root/.pyenv/versions/pgadmin= 36/lib/python3.6/site-packages/selenium/webdriver/support/wa= it.py", line 80, in until
=C2=A0 =C2=A0 raise TimeoutException(mess= age, screen, stacktrace)
selenium.common.exceptions.TimeoutExceptio= n: Message:

Thanks and= Regards,
Aditya Tos= hniwal
= Software Engineer |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don't Complain about Heat, Plant a tree"

On Tue, May 22, 2018 at 1:37 PM, Dave Page <= span dir=3D"ltr"><dpage@pgadmin.org> wrote:
=

On Tue, May 22, 20= 18 at 7:05 AM, Aditya Toshniwal <aditya.toshniwal@enterpri= sedb.com> wrote:
Hi Hackers,

PF= A patch for RM#3289 where decode error was thrown on querying a SQL_ASCII d= atabase table. Please note, this problem occurs only on windows.
= Sample insert -=C2=A0insert into test_tab values ('=C3=A9');
<= div>
psycopg2 has a encodings dictionary where Postgres Datab= ase Encodings are mapped to python equivalent. It uses 'ascii' deco= der of python to decode for SQL_ASCII encoding. If data has characters beyo= nd the limit of ascii then it failed. The solution would be to use utf_8 de= coder instead of ascii. I tried setting the client_encoding using set_clien= t_encoding('UTF8') method of a psycopg2 connection but no luck (als= o its not allowed for async connection). I also tried executing "SET C= LIENT_ENCODING=3D'UTF8'" but it didn't work too.
So, as in the patch, I had to set encodings dict value directly to 'ut= f_8' and it seems to be working. Please note, the same is added to psyc= opg3 milestones

Also fixed a small glitch for sql edito= r connection status check.

Kindly review.
Thanks and Reg= ards,
Aditya Toshniw= al
Soft= ware Engineer |=C2=A0EnterpriseDB Software Solutions |=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:"trebuchet ms",sans-se= rif;font-size:small">Pune
&= quot;Don't Complain about Heat, Plant a tree"
<= /div>



--
Dave Page
Blog: http://pgsnake.blogspot.com<= br>Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterpri= se PostgreSQL Company







--
= Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB = UK: http://www.en= terprisedb.com
The Enterprise PostgreSQL Company

--000000000000c630ea056dca2102-- --000000000000c630ee056dca2104 Content-Type: text/x-patch; charset="US-ASCII"; name="RM3289.patch" Content-Disposition: attachment; filename="RM3289.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jhzt7h3i0 ZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL3Rvb2xzL3NxbGVkaXRvci9fX2luaXRfXy5weSBiL3dl Yi9wZ2FkbWluL3Rvb2xzL3NxbGVkaXRvci9fX2luaXRfXy5weQppbmRleCAwMTNlNGRjLi5hOTQ2 MGRkIDEwMDY0NAotLS0gYS93ZWIvcGdhZG1pbi90b29scy9zcWxlZGl0b3IvX19pbml0X18ucHkK KysrIGIvd2ViL3BnYWRtaW4vdG9vbHMvc3FsZWRpdG9yL19faW5pdF9fLnB5CkBAIC0xNDgwLDE5 ICsxNDgwLDI0IEBAIGRlZiBxdWVyeV90b29sX3N0YXR1cyh0cmFuc19pZCk6CiAgICAgaWYgY29u biBhbmQgdHJhbnNfb2JqIGFuZCBzZXNzaW9uX29iajoKICAgICAgICAgc3RhdHVzID0gY29ubi50 cmFuc2FjdGlvbl9zdGF0dXMoKQogCi0gICAgICAgICMgQ2hlY2sgZm9yIHRoZSBhc3luY2hyb25v dXMgbm90aWZpZXMgc3RhdGVtZW50cy4KLSAgICAgICAgY29ubi5jaGVja19ub3RpZmllcyhUcnVl KQotICAgICAgICBub3RpZmllcyA9IGNvbm4uZ2V0X25vdGlmaWVzKCkKKyAgICAgICAgaWYgc3Rh dHVzIGlzIG5vdCBOb25lOgorICAgICAgICAgICAgIyBDaGVjayBmb3IgdGhlIGFzeW5jaHJvbm91 cyBub3RpZmllcyBzdGF0ZW1lbnRzLgorICAgICAgICAgICAgY29ubi5jaGVja19ub3RpZmllcyhU cnVlKQorICAgICAgICAgICAgbm90aWZpZXMgPSBjb25uLmdldF9ub3RpZmllcygpCiAKLSAgICAg ICAgcmV0dXJuIG1ha2VfanNvbl9yZXNwb25zZSgKLSAgICAgICAgICAgIGRhdGE9ewotICAgICAg ICAgICAgICAgICdzdGF0dXMnOiBzdGF0dXMsCi0gICAgICAgICAgICAgICAgJ21lc3NhZ2UnOiBn ZXR0ZXh0KAotICAgICAgICAgICAgICAgICAgICBDT05ORUNUSU9OX1NUQVRVU19NRVNTQUdFX01B UFBJTkcuZ2V0KHN0YXR1cyksCi0gICAgICAgICAgICAgICAgKSwKLSAgICAgICAgICAgICAgICAn bm90aWZpZXMnOiBub3RpZmllcwotICAgICAgICAgICAgfQotICAgICAgICApCisgICAgICAgICAg ICByZXR1cm4gbWFrZV9qc29uX3Jlc3BvbnNlKAorICAgICAgICAgICAgICAgIGRhdGE9eworICAg ICAgICAgICAgICAgICAgICAnc3RhdHVzJzogc3RhdHVzLAorICAgICAgICAgICAgICAgICAgICAn bWVzc2FnZSc6IGdldHRleHQoCisgICAgICAgICAgICAgICAgICAgICAgICBDT05ORUNUSU9OX1NU QVRVU19NRVNTQUdFX01BUFBJTkcuZ2V0KHN0YXR1cyksCisgICAgICAgICAgICAgICAgICAgICks CisgICAgICAgICAgICAgICAgICAgICdub3RpZmllcyc6IG5vdGlmaWVzCisgICAgICAgICAgICAg ICAgfQorICAgICAgICAgICAgKQorICAgICAgICBlbHNlOgorICAgICAgICAgICAgcmV0dXJuIGlu dGVybmFsX3NlcnZlcl9lcnJvcigKKyAgICAgICAgICAgICAgICBlcnJvcm1zZz1nZXR0ZXh0KCJU cmFuc2FjdGlvbiBzdGF0dXMgY2hlY2sgZmFpbGVkLiIpCisgICAgICAgICAgICApCiAgICAgZWxz ZToKICAgICAgICAgcmV0dXJuIGludGVybmFsX3NlcnZlcl9lcnJvcigKICAgICAgICAgICAgIGVy cm9ybXNnPWdldHRleHQoIlRyYW5zYWN0aW9uIHN0YXR1cyBjaGVjayBmYWlsZWQuIikKZGlmZiAt LWdpdCBhL3dlYi9wZ2FkbWluL3V0aWxzL2RyaXZlci9wc3ljb3BnMi9jb25uZWN0aW9uLnB5IGIv d2ViL3BnYWRtaW4vdXRpbHMvZHJpdmVyL3BzeWNvcGcyL2Nvbm5lY3Rpb24ucHkKaW5kZXggY2Zk MTYxYS4uZThjYTg4NiAxMDA2NDQKLS0tIGEvd2ViL3BnYWRtaW4vdXRpbHMvZHJpdmVyL3BzeWNv cGcyL2Nvbm5lY3Rpb24ucHkKKysrIGIvd2ViL3BnYWRtaW4vdXRpbHMvZHJpdmVyL3BzeWNvcGcy L2Nvbm5lY3Rpb24ucHkKQEAgLTUxLDYgKzUxLDEyIEBAIGVsc2U6CiBfID0gZ2V0dGV4dAogCiAK KyMgUmVwbGFjZSBkZWZhdWx0IGFzY2lpIGVuY29kZXIgd2l0aCB1bmljb2RlLWVzY2FwZQorIyB3 aGljaCB0cmFuc2xhdGVzIGNoYXJhY3RlcnMgdG8gdW5pY29kZSBmb3JtYXQuCisjIEVzY2FwZSBz cGVjaWFsIGNoYXJhY3RlcnMgdG8gQVNDSUkgYmFzZWQgb24gdW5pY29kZQorZW5jb2RpbmdzWydT UUxfQVNDSUknXSA9ICd1bmljb2RlLWVzY2FwZScKK2VuY29kaW5nc1snU1FMQVNDSUknXSA9ICd1 bmljb2RlLWVzY2FwZScKKwogIyBSZWdpc3RlciBnbG9iYWwgdHlwZSBjYXN0ZXIgd2hpY2ggd2ls bCBiZSBhcHBsaWNhYmxlIHRvIGFsbCBjb25uZWN0aW9ucy4KIHJlZ2lzdGVyX2dsb2JhbF90eXBl Y2FzdGVycygpCiAKZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL3V0aWxzL2RyaXZlci9wc3ljb3Bn Mi90eXBlY2FzdC5weSBiL3dlYi9wZ2FkbWluL3V0aWxzL2RyaXZlci9wc3ljb3BnMi90eXBlY2Fz dC5weQppbmRleCBmMTM2NjA0Li5jY2ViYjJmIDEwMDY0NAotLS0gYS93ZWIvcGdhZG1pbi91dGls cy9kcml2ZXIvcHN5Y29wZzIvdHlwZWNhc3QucHkKKysrIGIvd2ViL3BnYWRtaW4vdXRpbHMvZHJp dmVyL3BzeWNvcGcyL3R5cGVjYXN0LnB5CkBAIC0xNjQsNyArMTY0LDcgQEAgZGVmIHJlZ2lzdGVy X2dsb2JhbF90eXBlY2FzdGVycygpOgogCiAKIGRlZiByZWdpc3Rlcl9zdHJpbmdfdHlwZWNhc3Rl cnMoY29ubmVjdGlvbik6Ci0gICAgaWYgY29ubmVjdGlvbi5lbmNvZGluZyAhPSAnVVRGOCc6Cisg ICAgaWYgY29ubmVjdGlvbi5lbmNvZGluZyBub3QgaW4gKCdVVEY4JywgJ1NRTEFTQ0lJJywgJ1NR TF9BU0NJSScpOgogICAgICAgICAjIEluIHB5dGhvbjMgd2hlbiBkYXRhYmFzZSBlbmNvZGluZyBp cyBvdGhlciB0aGFuIHV0Zi04IGFuZCBjbGllbnQKICAgICAgICAgIyBlbmNvZGluZyBpcyBzZXQg dG8gVU5JQ09ERSB0aGVuIHdlIG5lZWQgdG8gbWFwIGRhdGEgZnJvbSBkYXRhYmFzZQogICAgICAg ICAjIGVuY29kaW5nIHRvIHV0Zi04LgpkaWZmIC0tZ2l0IGEvd2ViL3JlZ3Jlc3Npb24vcHl0aG9u X3Rlc3RfdXRpbHMvdGVzdF91dGlscy5weSBiL3dlYi9yZWdyZXNzaW9uL3B5dGhvbl90ZXN0X3V0 aWxzL3Rlc3RfdXRpbHMucHkKaW5kZXggM2U1MTdiNi4uMTYzYWYxMCAxMDA2NDQKLS0tIGEvd2Vi L3JlZ3Jlc3Npb24vcHl0aG9uX3Rlc3RfdXRpbHMvdGVzdF91dGlscy5weQorKysgYi93ZWIvcmVn cmVzc2lvbi9weXRob25fdGVzdF91dGlscy90ZXN0X3V0aWxzLnB5CkBAIC0xMTYsNyArMTE2LDcg QEAgZGVmIGNsZWFyX25vZGVfaW5mb19kaWN0KCk6CiAgICAgICAgIGRlbCBub2RlX2luZm9fZGlj dFtub2RlXVs6XQogCiAKLWRlZiBjcmVhdGVfZGF0YWJhc2Uoc2VydmVyLCBkYl9uYW1lKToKK2Rl ZiBjcmVhdGVfZGF0YWJhc2Uoc2VydmVyLCBkYl9uYW1lLCBlbmNvZGluZz1Ob25lKToKICAgICAi IiJUaGlzIGZ1bmN0aW9uIHVzZWQgdG8gY3JlYXRlIGRhdGFiYXNlIGFuZCByZXR1cm5zIHRoZSBk YXRhYmFzZSBpZCIiIgogICAgIHRyeToKICAgICAgICAgY29ubmVjdGlvbiA9IGdldF9kYl9jb25u ZWN0aW9uKApAQCAtMTMwLDggKzEzMCwxNCBAQCBkZWYgY3JlYXRlX2RhdGFiYXNlKHNlcnZlciwg ZGJfbmFtZSk6CiAgICAgICAgIG9sZF9pc29sYXRpb25fbGV2ZWwgPSBjb25uZWN0aW9uLmlzb2xh dGlvbl9sZXZlbAogICAgICAgICBjb25uZWN0aW9uLnNldF9pc29sYXRpb25fbGV2ZWwoMCkKICAg ICAgICAgcGdfY3Vyc29yID0gY29ubmVjdGlvbi5jdXJzb3IoKQotICAgICAgICBwZ19jdXJzb3Iu ZXhlY3V0ZSgKLSAgICAgICAgICAgICcnJ0NSRUFURSBEQVRBQkFTRSAiJXMiIFRFTVBMQVRFIHRl bXBsYXRlMCcnJyAlIGRiX25hbWUpCisgICAgICAgIGlmIGVuY29kaW5nIGlzIE5vbmU6CisgICAg ICAgICAgICBwZ19jdXJzb3IuZXhlY3V0ZSgKKyAgICAgICAgICAgICAgICAnJydDUkVBVEUgREFU QUJBU0UgIiVzIiBURU1QTEFURSB0ZW1wbGF0ZTAnJycgJSBkYl9uYW1lKQorICAgICAgICBlbHNl OgorICAgICAgICAgICAgcGdfY3Vyc29yLmV4ZWN1dGUoCisgICAgICAgICAgICAgICAgJycnQ1JF QVRFIERBVEFCQVNFICIlcyIgVEVNUExBVEUgdGVtcGxhdGUwIAorICAgICAgICAgICAgICAgIEVO Q09ESU5HPSclcycgTENfQ09MTEFURT0nJXMnIExDX0NUWVBFPSclcycgJycnICUKKyAgICAgICAg ICAgICAgICAoZGJfbmFtZSwgZW5jb2RpbmdbMF0sIGVuY29kaW5nWzFdLCBlbmNvZGluZ1sxXSkp CiAgICAgICAgIGNvbm5lY3Rpb24uc2V0X2lzb2xhdGlvbl9sZXZlbChvbGRfaXNvbGF0aW9uX2xl dmVsKQogICAgICAgICBjb25uZWN0aW9uLmNvbW1pdCgpCiAK --000000000000c630ee056dca2104--