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 1fTLOH-00056L-UU for pgadmin-hackers@arkaria.postgresql.org; Thu, 14 Jun 2018 06:05:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fTLOG-0000ey-Av for pgadmin-hackers@arkaria.postgresql.org; Thu, 14 Jun 2018 06:05:48 +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 1fTLOG-0000em-2Z for pgadmin-hackers@lists.postgresql.org; Thu, 14 Jun 2018 06:05:48 +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 1fTLO6-0004Sb-Kf for pgadmin-hackers@postgresql.org; Thu, 14 Jun 2018 06:05:47 +0000 Received: by mail-lf0-x241.google.com with SMTP id v135-v6so7476373lfa.9 for ; Wed, 13 Jun 2018 23:05:37 -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=otJgqbx2CGefVyLoladUbJPGLulqFHF4DmPMeHiurd0=; b=TYJZrqDQpdQRzHtRLh1DquYAwS071NJxshHknx9znwz9QSiy89FVa/XaCQm8ZZ74g+ KQmbyxgaFR7LGdnOp+AfTRFjprnOdGtzIK8bB4lA3LlECdtjDu6Ob3iZYsUjTZyt7EgD mAU2DPppaaTCUEIdAT6HMRNQ8wDloxDYb8gUdDwy/aR78s0vqKMG2U8Oz7BvwYhwyjjG 8ocDcPSJdPMFj8oZoq5jQ8D9Lnenf6voxOkTFfhb97RukdTpXuIHjkSxumdI0Wn1cpeG EbC9Zju7/0CFMcNhHEtbJPn+zR+SzIgGURPmHs8wmOUJ8s0YWmo8Xsxy0T35GDpIkrFj o35Q== 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=otJgqbx2CGefVyLoladUbJPGLulqFHF4DmPMeHiurd0=; b=KWbfZYQ8o5VXP83b9t7UgKEa58Djl30YBDm2tlQgiULTl0ee95BrE9bwgJ5VrCEe/t 7ehYGLpqx7qjXKYMMUi8h0YoGQsyIYsjGiQpQPxvitU3skJrAKMuLv42IcDskfvFPWiC VTiiM9WGHi5GmpbeoXkOjCa2YsCd9iOpz9kSduTgFVXtKjkFf/dX61rp6QpATMcqdGwJ lH8645R/18e9JBcbGRAb03tMn4PQbG4dM6lr7n0LOestIEelG0VBSYvZ2H6qvCUMKWOo qQeNZ8SFb+P6cZr1rvPoWrh2i6dspKyPQdel1w8u7hEfO5MIxg1nidp7/ozs9lXIA7+a sIOw== X-Gm-Message-State: APt69E0BAKl8eST+HSnKYXNHeb6pQuX7NxfVyEqgabXbgetTJJk7+/S+ CDlbustX2TB3Kx4H57Ap0x+JRbigjyrcQRp/4meFwg== X-Google-Smtp-Source: ADUXVKKEJ9rOhvgqneX+B21hO6FdbGBvh8Uf7SLzUBCu7OUMO8qCc0qFM8fIiqKzlPeV1pzoXqJyLCFUObdFExfCPn4= X-Received: by 2002:a2e:750d:: with SMTP id q13-v6mr691232ljc.56.1528956336157; Wed, 13 Jun 2018 23:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:7a02:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 23:05:35 -0700 (PDT) In-Reply-To: References: From: Aditya Toshniwal Date: Thu, 14 Jun 2018 11:35:35 +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="0000000000004b6f27056e93e3ec" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000004b6f27056e93e3ec Content-Type: multipart/alternative; boundary="0000000000004b6f23056e93e3ea" --0000000000004b6f23056e93e3ea Content-Type: text/plain; charset="UTF-8" I am sorry I missed the attachment. :( PFA. On Thu, Jun 14, 2018 at 11:34 AM, Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > Hi Hackers, > > PFA updated patch. > > On Thu, Jun 7, 2018 at 4:41 PM, Dave Page wrote: > >> Hi >> >> On Thu, Jun 7, 2018 at 12:05 PM, Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> >>> On Thu, Jun 7, 2018 at 4:07 PM, Dave Page wrote: >>> >>>> Hi >>>> >>>> On Wed, Jun 6, 2018 at 2:02 PM, Aditya Toshniwal < >>>> aditya.toshniwal@enterprisedb.com> wrote: >>>> >>>>> Hi Hackers, >>>>> >>>>> PFA updated patch as the previous one was not working as expected. I >>>>> have tried to make it similar to that of pgAdmin3 and you do not need to >>>>> change client_encoding as it is set now based on server encoding. It works >>>>> fine with "view data" also. >>>>> >>>> >>>> - In connection.py, at ~409, shouldn't we set the client_encoding to >>>> SQL_ASCII? Otherwise it could be overridden with something unexpected if >>>> the client has PGCLIENTENCODING set for example. >>>> >>> Yeah I agree, it would be better to add. Will add the change. >>> >>>> >>>> - With or without that change, I get the following test failure on >>>> macOS with Python 2.7.10: >>>> >>> It works fine on my machine with Python 2.7 and macOS. Could you please >>> let me know the Postgres DB version also. >>> >> >> PostgreSQL 9.4.10 on x86_64-apple-darwin, compiled by >> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build >> 5658) (LLVM build 2336.11.00), 64-bit >> >> >>> Will test on few more machines. >>> >>>> >>>> ====================================================================== >>>> ERROR: runTest (pgadmin.tools.sqleditor.tests >>>> .test_encoding_charset.TestEncodingCharset) >>>> With Encoding SQL_ASCII >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/tests/test_encoding_charset.py", >>>> line 86, in runTest >>>> response = self.tester.get(url) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/test.py", >>>> line 830, in get >>>> return self.open(*args, **kw) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/testing.py", >>>> line 127, in open >>>> follow_redirects=follow_redirects) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/test.py", >>>> line 803, in open >>>> response = self.run_wsgi_app(environ, buffered=buffered) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/test.py", >>>> line 716, in run_wsgi_app >>>> rv = run_wsgi_app(self.application, environ, buffered=buffered) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/test.py", >>>> line 923, in run_wsgi_app >>>> app_rv = app(environ, start_response) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1997, in __call__ >>>> return self.wsgi_app(environ, start_response) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1985, in wsgi_app >>>> response = self.handle_exception(e) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1540, in handle_exception >>>> reraise(exc_type, exc_value, tb) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1982, in wsgi_app >>>> response = self.full_dispatch_request() >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1614, in full_dispatch_request >>>> rv = self.handle_user_exception(e) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1517, in handle_user_exception >>>> reraise(exc_type, exc_value, tb) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1612, in full_dispatch_request >>>> rv = self.dispatch_request() >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", >>>> line 1598, in dispatch_request >>>> return self.view_functions[rule.endpoint](**req.view_args) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask_login.py", >>>> line 792, in decorated_view >>>> return func(*args, **kwargs) >>>> File "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/__init__.py", >>>> line 576, in poll >>>> 'oids': oids >>>> File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/ajax.py", line 61, >>>> in make_json_response >>>> separators=(',', ':')), >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/simplejson/__init__.py", >>>> line 399, in dumps >>>> **kw).encode(obj) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/simplejson/encoder.py", >>>> line 291, in encode >>>> chunks = self.iterencode(o, _one_shot=True) >>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/simplejson/encoder.py", >>>> line 373, in iterencode >>>> return _iterencode(o, 0) >>>> UnicodeDecodeError: 'utf8' codec can't decode byte 0xad in position 0: >>>> invalid start byte >>>> >>>> ---------------------------------------------------------------------- >>>> Ran 317 tests in 30.692s >>>> >>>> FAILED (errors=1, skipped=21) >>>> >>> > This is fixed. There was a problem with json dumps. Now, json dumps will > be done based on connection encoding. > >> >>>> >>>> >>>>> The only problem is, I cannot find equivalent codec for wxConvLibc in >>>>> python. The closest one I could find is raw_unicode_escape. So, in a >>>>> SQL_ASCII database, non ASCII characters may differ in pgAdmin4 and >>>>> pgAdmin3, but it will display results. >>>>> >>>> >>>> Yeah, I think that's fine. For the small number of people with >>>> SQL_ASCII databases, seeing escaped characters is better than nothing. >>>> >>>> >>>>> >>>>> >>>>> Dave, >>>>> You need to add "E" before the string to be inserted, otherwise \x >>>>> will be considered as a plain string. >>>>> INSERT INTO sql_ascii (data) VALUES (E'[Invalid UTF-8] Blob: >>>>> \xf4\xa5\xa3\xa5'); >>>>> >>>> >>>> Yeah, sorry - I copied the wrong version of the query :-( >>>> >>>> >>>>> >>>>> >>>>> Kindly review. >>>>> >>>>> Thanks and Regards, >>>>> Aditya Toshniwal >>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>> "Don't Complain about Heat, Plant a tree" >>>>> >>>>> On Tue, Jun 5, 2018 at 6:42 PM, Dave Page wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Tue, Jun 5, 2018 at 2:03 PM, Aditya Toshniwal < >>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Tue, Jun 5, 2018 at 6:25 PM, Dave Page wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 5, 2018 at 1:49 PM, Aditya Toshniwal < >>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> Hi Dave, >>>>>>>>> >>>>>>>>> The problem of SQL ASCII is solved with the patch, and not related >>>>>>>>> to setting the client encoding of the sql window. >>>>>>>>> >>>>>>>> >>>>>>>> No it's not. It doesn't work for me as I said (and showed the >>>>>>>> example of). >>>>>>>> >>>>>>> >>>>>>> After setting the client_encoding to SQL_ASCII you got the output. >>>>>>> Previously, it used to fail in the back end itself because python encoding >>>>>>> failure. That is fixed. >>>>>>> The error ERROR: invalid byte sequence for encoding "UTF8": 0x80 is >>>>>>> thrown by postgres and not python or pgAdmin4. You will get the same error >>>>>>> even if you >>>>>>> connect from psql. >>>>>>> >>>>>> >>>>>> Sure - but that is not a fix. You have no way of running the SET >>>>>> command if you're using "view data" - and in the query tool, users just >>>>>> expect it to work (as it did in pgAdmin 3). >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> I can see there is no SET call in pgAdmin3 for client_encoding. I >>>>>>>>> can remove the SET client_encoding='UNICODE'; that will solve the >>>>>>>>> problem. But, can you please let me know why that was added. >>>>>>>>> >>>>>>>> >>>>>>>> There is, but it's inside an API call (PQsetClientEncoding): >>>>>>>> >>>>>>>> 300 >>>>>>>> >>>>>>>> wxLogInfo(wxT("Setting client_encoding to '%s'") >>>>>>>> , encoding.c_str()); >>>>>>>> 301 >>>>>>>> >>>>>>>> if (PQsetClientEncoding(conn, encoding.ToAscii())) >>>>>>>> 302 >>>>>>>> >>>>>>>> { >>>>>>>> 303 >>>>>>>> >>>>>>>> wxLogError(wxT("%s"), GetLastError().c_str()); >>>>>>>> 304 >>>>>>>> >>>>>>>> } >>>>>>>> 305 >>>>>>>> >>>>>>>> >>>>>>>> Oops ! Missed that. Apologies. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Will remove the set call and will send you the updated patch if >>>>>>>>> everything works fine. >>>>>>>>> >>>>>>>> >>>>>>>> No, we need to ensure the client encoding is set correctly. It just >>>>>>>> needs to be set to SQL_ASCII if it's a SQL_ASCII database (I believe). >>>>>>>> >>>>>>>> >>>>>>> Need to rework on the initialise method. Will come with an updated. >>>>>>> patch. Sorry for trouble. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 5, 2018 at 6:05 PM, Dave Page >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> On Tue, Jun 5, 2018 at 1:21 PM, Aditya Toshniwal < >>>>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Dave, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 5, 2018 at 4:56 PM, Dave Page >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal < >>>>>>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Hackers, >>>>>>>>>>>>> >>>>>>>>>>>>> PFA updated patch. The sqleditor change is sent separately and >>>>>>>>>>>>> removed from current patch as suggested. >>>>>>>>>>>>> The test cases were running fine when the module was specified >>>>>>>>>>>>> using --pkg but were failing in complete run. Fixed that. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I did a quick test by creating a SQL_ASCII database containing >>>>>>>>>>>> a simple table: >>>>>>>>>>>> >>>>>>>>>>>> CREATE TABLE sql_ascii (id serial primary key, data text); >>>>>>>>>>>> >>>>>>>>>>>> And then populated it with data: >>>>>>>>>>>> >>>>>>>>>>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c >>>>>>>>>>>> "INSERT INTO sql_acsii (data) VALUES ('[Windows-1252] Euro: \x80 Double >>>>>>>>>>>> dagger: \x87');" >>>>>>>>>>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c >>>>>>>>>>>> "INSERT INTO sql_ascii (data) VALUES ('[Latin-1] Yen: \xa5 Half: >>>>>>>>>>>> \xbd');" >>>>>>>>>>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c >>>>>>>>>>>> "INSERT INTO sql_ascii (data) VALUES ('[Japanese] Ship: \xe8\x88\xb9');" >>>>>>>>>>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c >>>>>>>>>>>> "INSERT INTO sql_ascii (data) VALUES ('[Invalid UTF-8] Blob: >>>>>>>>>>>> \xf4\xa5\xa3\xa5');" >>>>>>>>>>>> >>>>>>>>>>>> I then right-clicked the table in the treeview, and selected >>>>>>>>>>>> the option to view all rows, and immediately saw an error: >>>>>>>>>>>> >>>>>>>>>>>> 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for >>>>>>>>>>>> server #1 - CONN:1187535 (Query-id: 8522474): >>>>>>>>>>>> SELECT * FROM public.sql_ascii >>>>>>>>>>>> ORDER BY id ASC >>>>>>>>>>>> 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute >>>>>>>>>>>> query (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474): >>>>>>>>>>>> Error Message:ERROR: invalid byte sequence for encoding >>>>>>>>>>>> "UTF8": 0x80 >>>>>>>>>>>> SQL state: 22021 >>>>>>>>>>>> >>>>>>>>>>>> Running "SELECT * FROM sql_ascii" in the query tool resulted in >>>>>>>>>>>> the same error, however, if I ran "SET client_encoding = 'SQL_ASCII';" >>>>>>>>>>>> first, I do see results. >>>>>>>>>>>> >>>>>>>>>>>> I have confirmed that I've restarted the server after applying >>>>>>>>>>>> the patch. >>>>>>>>>>>> >>>>>>>>>>>> What am I missing? Why don't we just set the client_encoding to >>>>>>>>>>>> SQL_ASCII if it's a SQL_ASCII database? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It is by default same as the server encoding. But, the following >>>>>>>>>>> existing code in web/pgadmin/utils/driver/psycopg2/connection.py >>>>>>>>>>> makes the client_encoding as UNICODE for every connection. I am >>>>>>>>>>> not sure it should be removed. >>>>>>>>>>> >>>>>>>>>>> status = _execute(cur, "SET DateStyle=ISO;" >>>>>>>>>>> >>>>>>>>>>> "SET client_min_messages=notice;" >>>>>>>>>>> >>>>>>>>>>> "SET bytea_output=escape;" >>>>>>>>>>> >>>>>>>>>>> "SET client_encoding='UNICODE';") >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It was probably before you joined, but I have said a number of >>>>>>>>>> times that pgAdmin 3 handled this differently and that maybe we should do >>>>>>>>>> it the same way here. See https://git.postgresql.org >>>>>>>>>> /gitweb/?p=pgadmin3.git;a=blob;f=pgadmin/db/pgConn.cpp, in the >>>>>>>>>> pgConn::Initialize() function. >>>>>>>>>> >>>>>>>>>> Either way, your patch isn't working for me. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this testing was on Python 2.7.10 on MacOS. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Kindly review. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks and Regards, >>>>>>>>>>>>> Aditya Toshniwal >>>>>>>>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>>>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal < >>>>>>>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira < >>>>>>>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Aditya, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is no change related to notifications in this patch. >>>>>>>>>>>>>>>> The below code is minor fix related to connection status of >>>>>>>>>>>>>>>> sql editor. Can you please share the code snippet if it is not the below. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - # Check for the asynchronous notifies statements. >>>>>>>>>>>>>>>> - conn.check_notifies(True) >>>>>>>>>>>>>>>> - notifies = conn.get_notifies() >>>>>>>>>>>>>>>> + if status is not None: >>>>>>>>>>>>>>>> + # Check for the asynchronous notifies >>>>>>>>>>>>>>>> statements. >>>>>>>>>>>>>>>> + conn.check_notifies(True) >>>>>>>>>>>>>>>> + notifies = conn.get_notifies() >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a minor fix, but is it related to querying SQL_ASCII >>>>>>>>>>>>>>> database? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> No its not. It is something I found when I was working on >>>>>>>>>>>>>> SQL_ASCII related changes. >>>>>>>>>>>>>> Well then, will send a separate patch for it. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Victoria && Joao >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >> > > --0000000000004b6f23056e93e3ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am sorry I missed the attachment. :(
PFA.

On Thu, Jun 14, 2018 at 11:34 AM, Aditya Tos= hniwal <aditya.toshniwal@enterprisedb.com> w= rote:
H= i Hackers,

PFA updated patch.

On Thu, Jun 7, 2018 a= t 4:41 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi
On Thu, Jun 7, 2018 at 12:05 PM, Aditya T= oshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Dave,


On Thu, Jun 7, 2018 at 4:07 PM, Dave Page <dpag= e@pgadmin.org> wrote:
Hi

=
On Wed, Jun 6, 2018 at 2:02 PM, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:=
Hi Hackers,

PFA updated patch as the previous o= ne was not working as expected. I have tried to make it similar to that of = pgAdmin3 and you do not need to change client_encoding as it is set now bas= ed on server encoding. It works fine with "view data" also.
=

- In connection.py, at ~409, = shouldn't we set the client_encoding to SQL_ASCII? Otherwise it could b= e overridden with something unexpected if the client has PGCLIENTENCODING s= et for example.
Yeah I agre= e, it would be better to add. Will add the change.=C2=A0

- With or without that change,= I get the following test failure on macOS with Python 2.7.10:
<= /div>
It works fine on my machine with Python= 2.7 and macOS. Could you please let me know the Postgres DB version also.<= /div>

PostgreSQL 9= .4.10 on x86_64-apple-darwin, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00), = 64-bit
=C2=A0
Will test on few more = machines.=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
ERROR: runTest (pgadmin.tools.sqleditor.tests.t= est_encoding_charset.TestEncodingCharset)
With Encoding SQL_= ASCII
------------------------------------------------------= ----------------
Traceback (most recent call last):
=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin= /tools/sqleditor/tests/test_encoding_charset.py", line 86, in run= Test
=C2=A0 =C2=A0 response =3D self.tester.get(url)
= =C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/sit= e-packages/werkzeug/test.py", line 830, in get
=C2=A0 = =C2=A0 return self.open(*args, **kw)
=C2=A0 File "/Users/dpa= ge/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/testin= g.py", line 127, in open
=C2=A0 =C2=A0 follow_redirects=3Dfo= llow_redirects)
=C2=A0 File "/Users/dpage/.virtualenvs/= pgadmin4/lib/python2.7/site-packages/werkzeug/test.py", line= 803, in open
=C2=A0 =C2=A0 response =3D self.run_wsgi_app(enviro= n, buffered=3Dbuffered)
=C2=A0 File "/Users/dpage/.virtualen= vs/pgadmin4/lib/python2.7/site-packages/werkzeug/test.py", l= ine 716, in run_wsgi_app
=C2=A0 =C2=A0 rv =3D run_wsgi_app(self.a= pplication, environ, buffered=3Dbuffered)
=C2=A0 File "/User= s/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeu= g/test.py", line 923, in run_wsgi_app
=C2=A0 =C2=A0 app_rv = =3D app(environ, start_response)
=C2=A0 File "/Users/dpage/.= virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py&quo= t;, line 1997, in __call__
=C2=A0 =C2=A0 return self.wsgi_app(env= iron, start_response)
=C2=A0 File "/Users/dpage/.virtualenvs= /pgadmin4/lib/python2.7/site-packages/flask/app.py", line 19= 85, in wsgi_app
=C2=A0 =C2=A0 response =3D self.handle_exception(= e)
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/= python2.7/site-packages/flask/app.py", line 1540, in handle_excep= tion
=C2=A0 =C2=A0 reraise(exc_type, exc_value, tb)
=C2= =A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-p= ackages/flask/app.py", line 1982, in wsgi_app
=C2=A0 = =C2=A0 response =3D self.full_dispatch_request()
=C2=A0 File &quo= t;/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", line 1614, in full_dispatch_request
=C2=A0 = =C2=A0 rv =3D self.handle_user_exception(e)
=C2=A0 File "/Us= ers/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask= /app.py", line 1517, in handle_user_exception
=C2=A0 =C2=A0 = reraise(exc_type, exc_value, tb)
=C2=A0 File "/Users/dpage/.= virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py&quo= t;, line 1612, in full_dispatch_request
=C2=A0 =C2=A0 rv =3D self= .dispatch_request()
=C2=A0 File "/Users/dpage/.virtualenvs/p= gadmin4/lib/python2.7/site-packages/flask/app.py", line 1598= , in dispatch_request
=C2=A0 =C2=A0 return self.view_functions[ru= le.endpoint](**req.view_args)
=C2=A0 File "/Users/dpage= /.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask_login.py= ", line 792, in decorated_view
=C2=A0 =C2=A0 return func(*ar= gs, **kwargs)
=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/__init__.py", line 576, in poll
=C2=A0 =C2=A0 'oids': oids
=C2=A0 File "/Users/dp= age/git/pgadmin4/web/pgadmin/utils/ajax.py", line 61, in make_jso= n_response
=C2=A0 =C2=A0 separators=3D(',', ':'))= ,
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/p= ython2.7/site-packages/simplejson/__init__.py", line 399, in dump= s
=C2=A0 =C2=A0 **kw).encode(obj)
=C2=A0 File "/Us= ers/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/simpl= ejson/encoder.py", line 291, in encode
=C2=A0 =C2=A0 chunks = =3D self.iterencode(o, _one_shot=3DTrue)
=C2=A0 File "/Users= /dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/simplejs= on/encoder.py", line 373, in iterencode
=C2=A0 =C2=A0 return= _iterencode(o, 0)
UnicodeDecodeError: 'utf8' codec can&#= 39;t decode byte 0xad in position 0: invalid start byte

----------------------------------------------------------------------
Ran 317 tests in 30.692s

FAI= LED (errors=3D1, skipped=3D21)

This is fixed. There was a problem= with json dumps. Now, json dumps will be done based on connection encoding= .=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=C2=A0
The only problem is, I cannot find equivalent codec for wxC= onvLibc in python. The closest one I could find is raw_unicode_escape. So, = in a SQL_ASCII database, non ASCII characters may differ in pgAdmin4 and pg= Admin3, but it will display results.

Yeah, I think that's fine. For the small number of people = with SQL_ASCII databases, seeing escaped characters is better than nothing.=
=C2=A0


Dave,=C2=A0
You need to add "E" before the string to be i= nserted, otherwise \x will be considered as a plain string.
INSERT INTO sql_ascii (data) VALUES (E'[Inv= alid UTF-8]=C2=A0 Blob: \xf4\xa5\xa3\xa5');

Yeah, sorry - I copied the wrong version of = the query :-(
=C2=A0


Kindly review.

Thanks and Regards,
Aditya Toshniwal=
Software Engi= neer |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don&= #39;t Complain about Heat, Plant a tree"

On Tue, Jun 5, 2018 at 6:42 PM, Dave Pa= ge <dpage@pgadmin.org> wrote:
Hi
On Tue, Jun 5, 2018 at 2:03 = PM, Aditya Toshniwal <aditya.toshniwal@enterprisedb.c= om> wrote:
Hi

On Tue, Jun 5, 2018 at 6:25 PM, Dave Page = <dpage@pgadmin.or= g> wrote:


On Tue, Jun 5, 2018 at 1:49 PM, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
=
Hi Dave,=

The problem of SQL ASCII is solved with the patch, and= not related to setting the client encoding of the sql window.

No it's not. It doesn't work for = me as I said (and showed the example of).

After setting the client_encoding to SQL_ASCI= I you got the output. Previously, it used to fail in the back end itself be= cause python encoding failure. That is fixed.
The error=C2=A0ERROR:=C2=A0 invalid byte sequence for encoding = "UTF8": 0x80=C2=A0is thrown by postgres and not pyt= hon or pgAdmin4. You will get the same error even if you=C2=A0
co= nnect from psql.

=
Sure - but that is not a fix. You have no way of running the SET comma= nd if you're using "view data" - and in the query tool, users= just expect it to work (as it did in pgAdmin 3).
=C2=A0
=C2=A0
I can see there = is no SET call in pgAdmin3 for client_encoding.=C2=A0 I can remove the=C2= =A0SET client_encoding=3D'UNICODE'; that will solve the problem. But, can you plea= se let me know why that was added.=C2=A0

=
There is, but it's inside an API call (PQsetClie= ntEncoding):

300 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0wxLogInfo(wxT("Setting= =C2=A0client_encoding=C2=A0to=C2=A0'%s'"),=C2=A0encoding.= c_str());
301 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= if=C2=A0(PQsetClientEncoding(conn,=C2=A0encoding.ToAscii()))
302 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{
303 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0wxLogError(wxT("%s"),=C2=A0GetLastError().c_str()= );
304 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
305

<= /div>
Oops ! Missed that. Apologi= es.=C2=A0
=C2=A0

Will remove the set call and will send you the updated patch if everything= works fine.

No, w= e need to ensure the client encoding is set correctly. It just needs to be = set to SQL_ASCII if it's a SQL_ASCII database (I believe).
=C2=A0
Need to rework on= the initialise method. Will come with an updated. patch. Sorry for trouble= .=C2=A0

<= /div>

On Tue, Jun 5, 2018 at 6:05 PM, Dave Page = <dpage@pgadmin.org> wrote:
Hi

<= div class=3D"gmail_quote">
On Tue,= Jun 5, 2018 at 1:21 PM, Aditya Toshniwal <aditya.toshniwa= l@enterprisedb.com> wrote:
Hi Dave,


On Tue, Jun 5, 2018 at 4:56 PM, Dave Page <dpage@pgadmi= n.org> wrote:
Hi

On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Hackers,
PFA updated patch. The sqleditor change is sent separately= and removed from current patch as suggested.
The test cases were= running fine when the module was specified using --pkg but were failing in= complete run. Fixed that.

I did a quick test by creating a SQL_ASCII database containing a simple = table:

CREATE TABLE sql_ascii (id serial primary k= ey, data text);

And then populated it with data:

/Library/PostgreSQL/9.4/bin/psql -d sql_a= scii -U postgres -c "INSERT INTO sql_acsii (data) VALUES ('[Window= s-1252]=C2=A0 =C2=A0Euro: \x80=C2=A0 =C2=A0Double dagger: \x87');"=
/Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -= c "INSERT INTO sql_ascii (data) VALUES ('[Latin-1]=C2=A0 =C2=A0Yen= : \xa5=C2=A0 =C2=A0Half: \xbd');"
/Library/PostgreSQL/9.= 4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO sql_ascii (da= ta) VALUES ('[Japanese]=C2=A0 =C2=A0Ship: \xe8\x88\xb9');"
/Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c &q= uot;INSERT INTO sql_ascii (data) VALUES ('[Invalid UTF-8]=C2=A0 Blob: \= xf4\xa5\xa3\xa5');"

I then right-cl= icked the table in the treeview, and selected the option to view all rows, = and immediately saw an error:

2018-06-05 12:2= 3:27,319: SQL pgadmin: Execute (async) for server #1 - CONN:11= 87535 (Query-id: 8522474):
SELECT * FROM public.sql_ascii
ORDER BY id ASC=C2=A0
2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query (execute_async) for the server #1 - CO= NN:1187535(Query-id: 8522474):
Error Message:ERROR:=C2=A0 invalid= byte sequence for encoding "UTF8": 0x80
SQL state: 220= 21

Running "SELECT * FROM sql_ascii&quo= t; in the query tool resulted in the same error, however, if I ran "SE= T client_encoding =3D 'SQL_ASCII';" first, I do see results.

I have confirmed that I've restarted the server= after applying the patch.

What am I missing? Why = don't we just set the client_encoding to SQL_ASCII if it's a SQL_AS= CII database?
=C2=A0
<= div>It is by default same as the server encoding. But, the following existi= ng code in=C2=A0=C2=A0web/pgadmin/utils/driver/psycop= g2/connection.py makes the client_encoding as UNICODE for every conn= ection. I am not sure it should be removed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0= status =3D _execute(cur, "SET DateStyle=3DISO;"

=C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "SET client_min_messages=3Dnotice;"

=C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "SET bytea_output=3Descape;"

=C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "SET client_encoding=3D'UNICODE';")


It was probably before you joined, but I have said a number of time= s that pgAdmin 3 handled this differently and that maybe we should do it th= e same way here. See=C2=A0https= ://git.postgresql.org/gitweb/?p=3Dpgadmin3.git;a=3Dblob;f=3Dpgadm= in/db/pgConn.cpp, in the pgConn::Initialize() function.

<= /div>
Either way, your patch isn't working for me.
=C2=A0


Note that this testing was on Python 2.7.10 on Ma= cOS.
=C2=A0

Kindly review.

Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0= EnterpriseDB Software Solutions |=C2=A0= Pune
"Don't Compla= in about Heat, Plant a tree"

On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal = <= aditya.toshniwal@enterprisedb.com> wrote:
Hi

On Tue, Jun 5, 2018 at 1:08 = AM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io&g= t; wrote:
Hello Aditya,


There is no change related to notifications in this patch.=C2=A0
The below code is minor fix related to connection status of sql editor. = Can you please share the code snippet if it is not the below.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Check for the asynchronous = notifies statements.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 conn.check_noti= fies(True)
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 notifies =3D conn.get_not= ifies()
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if status is not None:
=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Check for the asynchronou= s notifies statements.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= conn.check_notifies(True)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 notifies =3D conn.get_notifies()


This is a minor fix, but is it related= to querying SQL_ASCII database?
= No its not. It is something I found when I was working on SQL_ASCII related= changes.
Well then, will send a separate patch for it.

Thanks
Victoria && J= oao





--
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




--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
<= br>EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
=




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

Enterprise= DB 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

=


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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterpr= ise PostgreSQL Company


--0000000000004b6f23056e93e3ea-- --0000000000004b6f27056e93e3ec Content-Type: application/octet-stream; name="RM3289.patch" Content-Disposition: attachment; filename="RM3289.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jie54fax0 ZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL3Rvb2xzL3NxbGVkaXRvci9fX2luaXRfXy5weSBiL3dl Yi9wZ2FkbWluL3Rvb2xzL3NxbGVkaXRvci9fX2luaXRfXy5weQppbmRleCBhOTQ2MGRkNy4uZDhm MmNlNjcgMTAwNjQ0Ci0tLSBhL3dlYi9wZ2FkbWluL3Rvb2xzL3NxbGVkaXRvci9fX2luaXRfXy5w eQorKysgYi93ZWIvcGdhZG1pbi90b29scy9zcWxlZGl0b3IvX19pbml0X18ucHkKQEAgLTU3NCw3 ICs1NzQsOCBAQCBkZWYgcG9sbCh0cmFuc19pZCk6CiAgICAgICAgICAgICAnY2xpZW50X3ByaW1h cnlfa2V5JzogY2xpZW50X3ByaW1hcnlfa2V5LAogICAgICAgICAgICAgJ2hhc19vaWRzJzogaGFz X29pZHMsCiAgICAgICAgICAgICAnb2lkcyc6IG9pZHMKLSAgICAgICAgfQorICAgICAgICB9LAor ICAgICAgICBlbmNvZGluZz1jb25uLnB5dGhvbl9lbmNvZGluZwogICAgICkKIAogCkBAIC02NDYs NyArNjQ3LDggQEAgZGVmIGZldGNoKHRyYW5zX2lkLCBmZXRjaF9hbGw9Tm9uZSk6CiAgICAgICAg ICAgICAnaGFzX21vcmVfcm93cyc6IGhhc19tb3JlX3Jvd3MsCiAgICAgICAgICAgICAncm93c19m ZXRjaGVkX2Zyb20nOiByb3dzX2ZldGNoZWRfZnJvbSwKICAgICAgICAgICAgICdyb3dzX2ZldGNo ZWRfdG8nOiByb3dzX2ZldGNoZWRfdG8KLSAgICAgICAgfQorICAgICAgICB9LAorICAgICAgICBl bmNvZGluZz1jb25uLnB5dGhvbl9lbmNvZGluZwogICAgICkKIAogCmRpZmYgLS1naXQgYS93ZWIv cGdhZG1pbi90b29scy9zcWxlZGl0b3IvdGVzdHMvdGVzdF9lbmNvZGluZ19jaGFyc2V0LnB5IGIv d2ViL3BnYWRtaW4vdG9vbHMvc3FsZWRpdG9yL3Rlc3RzL3Rlc3RfZW5jb2RpbmdfY2hhcnNldC5w eQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMC4uMDgyNmRlY2IKLS0tIC9kZXYv bnVsbAorKysgYi93ZWIvcGdhZG1pbi90b29scy9zcWxlZGl0b3IvdGVzdHMvdGVzdF9lbmNvZGlu Z19jaGFyc2V0LnB5CkBAIC0wLDAgKzEsMTAzIEBACisjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIworIworIyBw Z0FkbWluIDQgLSBQb3N0Z3JlU1FMIFRvb2xzCisjCisjIENvcHlyaWdodCAoQykgMjAxMyAtIDIw MTgsIFRoZSBwZ0FkbWluIERldmVsb3BtZW50IFRlYW0KKyMgVGhpcyBzb2Z0d2FyZSBpcyByZWxl YXNlZCB1bmRlciB0aGUgUG9zdGdyZVNRTCBMaWNlbmNlCisjCisjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwor Citmcm9tIHBnYWRtaW4udXRpbHMucm91dGUgaW1wb3J0IEJhc2VUZXN0R2VuZXJhdG9yCitmcm9t IHBnYWRtaW4uYnJvd3Nlci5zZXJ2ZXJfZ3JvdXBzLnNlcnZlcnMuZGF0YWJhc2VzLnRlc3RzIGlt cG9ydCB1dGlscyBhcyBcCisgICAgZGF0YWJhc2VfdXRpbHMKK2Zyb20gcmVncmVzc2lvbiBpbXBv cnQgcGFyZW50X25vZGVfZGljdAorZnJvbSByZWdyZXNzaW9uLnB5dGhvbl90ZXN0X3V0aWxzIGlt cG9ydCB0ZXN0X3V0aWxzCitpbXBvcnQganNvbgorCisKK2NsYXNzIFRlc3RFbmNvZGluZ0NoYXJz ZXQoQmFzZVRlc3RHZW5lcmF0b3IpOgorICAgICIiIgorICAgIFRoaXMgY2xhc3MgdmFsaWRhdGVz IGNoYXJhY3RlciBzdXBwb3J0IGluIHBnQWRtaW40IGZvcgorICAgIGRpZmZlcmVudCBQb3N0Z3Jl c0RCIGVuY29kaW5ncworICAgICIiIgorICAgIHNjZW5hcmlvcyA9IFsKKyAgICAgICAgKAorICAg ICAgICAgICAgJ1dpdGggRW5jb2RpbmcgVVRGOCcsCisgICAgICAgICAgICBkaWN0KAorICAgICAg ICAgICAgICAgIGRiX2VuY29kaW5nPSdVVEY4JywKKyAgICAgICAgICAgICAgICBsY19jb2xsYXRl PSdDJywKKyAgICAgICAgICAgICAgICB0ZXN0X3N0cj0nQScKKyAgICAgICAgICAgICkpLAorICAg ICAgICAoCisgICAgICAgICAgICAnV2l0aCBFbmNvZGluZyBXSU4xMjUyJywKKyAgICAgICAgICAg IGRpY3QoCisgICAgICAgICAgICAgICAgZGJfZW5jb2Rpbmc9J1dJTjEyNTInLAorICAgICAgICAg ICAgICAgIGxjX2NvbGxhdGU9J0MnLAorICAgICAgICAgICAgICAgIHRlc3Rfc3RyPSdBJworICAg ICAgICAgICAgKSksCisgICAgICAgICgKKyAgICAgICAgICAgICdXaXRoIEVuY29kaW5nIEVVQ19D TicsCisgICAgICAgICAgICBkaWN0KAorICAgICAgICAgICAgICAgIGRiX2VuY29kaW5nPSdFVUNf Q04nLAorICAgICAgICAgICAgICAgIGxjX2NvbGxhdGU9J0MnLAorICAgICAgICAgICAgICAgIHRl c3Rfc3RyPSdBJworICAgICAgICAgICAgKSksCisgICAgICAgICgKKyAgICAgICAgICAgICdXaXRo IEVuY29kaW5nIFNRTF9BU0NJSScsCisgICAgICAgICAgICBkaWN0KAorICAgICAgICAgICAgICAg IGRiX2VuY29kaW5nPSdTUUxfQVNDSUknLAorICAgICAgICAgICAgICAgIGxjX2NvbGxhdGU9J0Mn LAorICAgICAgICAgICAgICAgIHRlc3Rfc3RyPSdcXDI1NScKKyAgICAgICAgICAgICkpLAorICAg IF0KKworICAgIGRlZiBzZXRVcChzZWxmKToKKyAgICAgICAgc2VsZi5lbmNvZGVfZGJfbmFtZSA9 ICdlbmNvZGluZ18nICsgc2VsZi5kYl9lbmNvZGluZworICAgICAgICBzZWxmLmVuY29kZV9zaWQg PSBzZWxmLnNlcnZlcl9pbmZvcm1hdGlvblsnc2VydmVyX2lkJ10KKyAgICAgICAgc2VsZi5lbmNv ZGVfZGlkID0gdGVzdF91dGlscy5jcmVhdGVfZGF0YWJhc2UoCisgICAgICAgICAgICBzZWxmLnNl cnZlciwgc2VsZi5lbmNvZGVfZGJfbmFtZSwKKyAgICAgICAgICAgIChzZWxmLmRiX2VuY29kaW5n LCBzZWxmLmxjX2NvbGxhdGUpKQorCisgICAgZGVmIHJ1blRlc3Qoc2VsZik6CisKKyAgICAgICAg ZGJfY29uID0gZGF0YWJhc2VfdXRpbHMuY29ubmVjdF9kYXRhYmFzZShzZWxmLAorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRlc3RfdXRpbHMuU0VSVkVS X0dST1VQLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHNlbGYuZW5jb2RlX3NpZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzZWxmLmVuY29kZV9kaWQpCisgICAgICAgIGlmIG5vdCBkYl9jb25bImluZm8i XSA9PSAiRGF0YWJhc2UgY29ubmVjdGVkLiI6CisgICAgICAgICAgICByYWlzZSBFeGNlcHRpb24o IkNvdWxkIG5vdCBjb25uZWN0IHRvIHRoZSBkYXRhYmFzZS4iKQorCisgICAgICAgICMgSW5pdGlh bGl6ZSBxdWVyeSB0b29sCisgICAgICAgIHVybCA9ICcvZGF0YWdyaWQvaW5pdGlhbGl6ZS9xdWVy eV90b29sL3swfS97MX0vezJ9Jy5mb3JtYXQoCisgICAgICAgICAgICB0ZXN0X3V0aWxzLlNFUlZF Ul9HUk9VUCwgc2VsZi5lbmNvZGVfc2lkLCBzZWxmLmVuY29kZV9kaWQpCisgICAgICAgIHJlc3Bv bnNlID0gc2VsZi50ZXN0ZXIucG9zdCh1cmwpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWxzKHJl c3BvbnNlLnN0YXR1c19jb2RlLCAyMDApCisKKyAgICAgICAgcmVzcG9uc2VfZGF0YSA9IGpzb24u bG9hZHMocmVzcG9uc2UuZGF0YS5kZWNvZGUoJ3V0Zi04JykpCisgICAgICAgIHNlbGYudHJhbnNf aWQgPSByZXNwb25zZV9kYXRhWydkYXRhJ11bJ2dyaWRUcmFuc0lkJ10KKworICAgICAgICAjIENo ZWNrIGNoYXJhY3RlcgorICAgICAgICB1cmwgPSAiL3NxbGVkaXRvci9xdWVyeV90b29sL3N0YXJ0 L3swfSIuZm9ybWF0KHNlbGYudHJhbnNfaWQpCisgICAgICAgIHNxbCA9ICJzZWxlY3QgRSd7MH0n OyIuZm9ybWF0KHNlbGYudGVzdF9zdHIpCisgICAgICAgIHJlc3BvbnNlID0gc2VsZi50ZXN0ZXIu cG9zdCh1cmwsIGRhdGE9anNvbi5kdW1wcyh7InNxbCI6IHNxbH0pLAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgY29udGVudF90eXBlPSdodG1sL2pzb24nKQorICAgICAgICBz ZWxmLmFzc2VydEVxdWFscyhyZXNwb25zZS5zdGF0dXNfY29kZSwgMjAwKQorICAgICAgICB1cmwg PSAnL3NxbGVkaXRvci9wb2xsL3swfScuZm9ybWF0KHNlbGYudHJhbnNfaWQpCisgICAgICAgIHJl c3BvbnNlID0gc2VsZi50ZXN0ZXIuZ2V0KHVybCkKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbHMo cmVzcG9uc2Uuc3RhdHVzX2NvZGUsIDIwMCkKKyAgICAgICAgcmVzcG9uc2VfZGF0YSA9IGpzb24u bG9hZHMocmVzcG9uc2UuZGF0YS5kZWNvZGUoJ3V0Zi04JykpCisgICAgICAgIHNlbGYuYXNzZXJ0 RXF1YWxzKHJlc3BvbnNlX2RhdGFbJ2RhdGEnXVsncm93c19mZXRjaGVkX3RvJ10sIDEpCisKKyAg ICAgICAgZGF0YWJhc2VfdXRpbHMuZGlzY29ubmVjdF9kYXRhYmFzZShzZWxmLCBzZWxmLmVuY29k ZV9zaWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VsZi5l bmNvZGVfZGlkKQorCisgICAgZGVmIHRlYXJEb3duKHNlbGYpOgorICAgICAgICBtYWluX2Nvbm4g PSB0ZXN0X3V0aWxzLmdldF9kYl9jb25uZWN0aW9uKAorICAgICAgICAgICAgc2VsZi5zZXJ2ZXJb J2RiJ10sCisgICAgICAgICAgICBzZWxmLnNlcnZlclsndXNlcm5hbWUnXSwKKyAgICAgICAgICAg IHNlbGYuc2VydmVyWydkYl9wYXNzd29yZCddLAorICAgICAgICAgICAgc2VsZi5zZXJ2ZXJbJ2hv c3QnXSwKKyAgICAgICAgICAgIHNlbGYuc2VydmVyWydwb3J0J10sCisgICAgICAgICAgICBzZWxm LnNlcnZlclsnc3NsbW9kZSddCisgICAgICAgICkKKyAgICAgICAgdGVzdF91dGlscy5kcm9wX2Rh dGFiYXNlKG1haW5fY29ubiwgc2VsZi5lbmNvZGVfZGJfbmFtZSkKZGlmZiAtLWdpdCBhL3dlYi9w Z2FkbWluL3V0aWxzL2FqYXgucHkgYi93ZWIvcGdhZG1pbi91dGlscy9hamF4LnB5CmluZGV4IDli NDRhYTNlLi5jMTlmNzc4YSAxMDA2NDQKLS0tIGEvd2ViL3BnYWRtaW4vdXRpbHMvYWpheC5weQor KysgYi93ZWIvcGdhZG1pbi91dGlscy9hamF4LnB5CkBAIC00NSw3ICs0NSw4IEBAIGRlZiBnZXRf bm9fY2FjaGVfaGVhZGVyKCk6CiAKIAogZGVmIG1ha2VfanNvbl9yZXNwb25zZSgKLSAgICAgICAg c3VjY2Vzcz0xLCBlcnJvcm1zZz0nJywgaW5mbz0nJywgcmVzdWx0PU5vbmUsIGRhdGE9Tm9uZSwg c3RhdHVzPTIwMAorICAgICAgICBzdWNjZXNzPTEsIGVycm9ybXNnPScnLCBpbmZvPScnLCByZXN1 bHQ9Tm9uZSwgZGF0YT1Ob25lLCBzdGF0dXM9MjAwLAorICAgICAgICBlbmNvZGluZz0ndXRmLTgn CiApOgogICAgICIiIkNyZWF0ZSBhIEhUTUwgcmVzcG9uc2UgZG9jdW1lbnQgZGVzY3JpYmluZyB0 aGUgcmVzdWx0cyBvZiBhIHJlcXVlc3QgYW5kCiAgICAgY29udGFpbmluZyB0aGUgZGF0YS4iIiIK QEAgLTU4LDcgKzU5LDcgQEAgZGVmIG1ha2VfanNvbl9yZXNwb25zZSgKIAogICAgIHJldHVybiBS ZXNwb25zZSgKICAgICAgICAgcmVzcG9uc2U9anNvbi5kdW1wcyhkb2MsIGNscz1EYXRhVHlwZUpT T05FbmNvZGVyLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcGFyYXRvcnM9KCcsJywg JzonKSksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VwYXJhdG9ycz0oJywnLCAnOicp LCBlbmNvZGluZz1lbmNvZGluZyksCiAgICAgICAgIHN0YXR1cz1zdGF0dXMsCiAgICAgICAgIG1p bWV0eXBlPSJhcHBsaWNhdGlvbi9qc29uIiwKICAgICAgICAgaGVhZGVycz1nZXRfbm9fY2FjaGVf aGVhZGVyKCkKZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL3V0aWxzL2RyaXZlci9wc3ljb3BnMi9j b25uZWN0aW9uLnB5IGIvd2ViL3BnYWRtaW4vdXRpbHMvZHJpdmVyL3BzeWNvcGcyL2Nvbm5lY3Rp b24ucHkKaW5kZXggY2ZkMTYxYTAuLjMzNzYyNTU4IDEwMDY0NAotLS0gYS93ZWIvcGdhZG1pbi91 dGlscy9kcml2ZXIvcHN5Y29wZzIvY29ubmVjdGlvbi5weQorKysgYi93ZWIvcGdhZG1pbi91dGls cy9kcml2ZXIvcHN5Y29wZzIvY29ubmVjdGlvbi5weQpAQCAtMzMsNyArMzMsNyBAQCBmcm9tIHBn YWRtaW4udXRpbHMgaW1wb3J0IGdldF9jb21wbGV0ZV9maWxlX3BhdGgKIGZyb20gLi5hYnN0cmFj dCBpbXBvcnQgQmFzZURyaXZlciwgQmFzZUNvbm5lY3Rpb24KIGZyb20gLmN1cnNvciBpbXBvcnQg RGljdEN1cnNvcgogZnJvbSAudHlwZWNhc3QgaW1wb3J0IHJlZ2lzdGVyX2dsb2JhbF90eXBlY2Fz dGVycywgXAotICAgIHJlZ2lzdGVyX3N0cmluZ190eXBlY2FzdGVycywgcmVnaXN0ZXJfYmluYXJ5 X3R5cGVjYXN0ZXJzLCBcCisgICAgcmVnaXN0ZXJfYmluYXJ5X3R5cGVjYXN0ZXJzLCBcCiAgICAg cmVnaXN0ZXJfYXJyYXlfdG9fc3RyaW5nX3R5cGVjYXN0ZXJzLCBBTExfSlNPTl9UWVBFUwogCiAK QEAgLTM4Nyw4ICszODcsNiBAQCBjbGFzcyBDb25uZWN0aW9uKEJhc2VDb25uZWN0aW9uKToKICAg ICAgICAgICAgIGVsc2U6CiAgICAgICAgICAgICAgICAgc2VsZi5jb25uLmF1dG9jb21taXQgPSBU cnVlCiAKLSAgICAgICAgcmVnaXN0ZXJfc3RyaW5nX3R5cGVjYXN0ZXJzKHNlbGYuY29ubikKLQog ICAgICAgICBpZiBzZWxmLmFycmF5X3RvX3N0cmluZzoKICAgICAgICAgICAgIHJlZ2lzdGVyX2Fy cmF5X3RvX3N0cmluZ190eXBlY2FzdGVycyhzZWxmLmNvbm4pCiAKQEAgLTM5NywxMSArMzk1LDIy IEBAIGNsYXNzIENvbm5lY3Rpb24oQmFzZUNvbm5lY3Rpb24pOgogICAgICAgICBpZiBzZWxmLnVz ZV9iaW5hcnlfcGxhY2Vob2xkZXI6CiAgICAgICAgICAgICByZWdpc3Rlcl9iaW5hcnlfdHlwZWNh c3RlcnMoc2VsZi5jb25uKQogCi0gICAgICAgIHN0YXR1cyA9IF9leGVjdXRlKGN1ciwgIlNFVCBE YXRlU3R5bGU9SVNPOyIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiU0VUIGNsaWVu dF9taW5fbWVzc2FnZXM9bm90aWNlOyIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi U0VUIGJ5dGVhX291dHB1dD1lc2NhcGU7IgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICJTRVQgY2xpZW50X2VuY29kaW5nPSdVTklDT0RFJzsiKQotCisgICAgICAgIGlmIHNlbGYuY29u bi5lbmNvZGluZyBub3QgaW4gKCdTUUxfQVNDSUknLCAnU1FMQVNDSUknLAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAnTVVMRV9JTlRFUk5BTCcsICdNVUxFSU5URVJOQUwn KToKKyAgICAgICAgICAgIHN0YXR1cyA9IF9leGVjdXRlKGN1ciwgIlNFVCBEYXRlU3R5bGU9SVNP OyIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIlNFVCBjbGllbnRfbWluX21l c3NhZ2VzPW5vdGljZTsiCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJTRVQg Ynl0ZWFfb3V0cHV0PWVzY2FwZTsiCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICJTRVQgY2xpZW50X2VuY29kaW5nPSdVTklDT0RFJzsiKQorICAgICAgICAgICAgc2VsZi5weXRo b25fZW5jb2RpbmcgPSAndXRmLTgnCisgICAgICAgICAgICBlbmNvZGluZ3Nbc2VsZi5jb25uLmVu Y29kaW5nXSA9IHNlbGYucHl0aG9uX2VuY29kaW5nCisgICAgICAgIGVsc2U6CisgICAgICAgICAg ICBzdGF0dXMgPSBfZXhlY3V0ZShjdXIsICJTRVQgRGF0ZVN0eWxlPUlTTzsiCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICJTRVQgY2xpZW50X21pbl9tZXNzYWdlcz1ub3RpY2U7 IgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiU0VUIGJ5dGVhX291dHB1dD1l c2NhcGU7IgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiU0VUIGNsaWVudF9l bmNvZGluZz0nezB9JzsiCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuZm9ybWF0KHNl bGYuY29ubi5lbmNvZGluZykpCisgICAgICAgICAgICBzZWxmLnB5dGhvbl9lbmNvZGluZyA9ICdy YXdfdW5pY29kZV9lc2NhcGUnCisgICAgICAgICAgICBlbmNvZGluZ3Nbc2VsZi5jb25uLmVuY29k aW5nXSA9IHNlbGYucHl0aG9uX2VuY29kaW5nCiAgICAgICAgIGlmIHN0YXR1cyBpcyBub3QgTm9u ZToKICAgICAgICAgICAgIHNlbGYuY29ubi5jbG9zZSgpCiAgICAgICAgICAgICBzZWxmLmNvbm4g PSBOb25lCmRpZmYgLS1naXQgYS93ZWIvcGdhZG1pbi91dGlscy9kcml2ZXIvcHN5Y29wZzIvdHlw ZWNhc3QucHkgYi93ZWIvcGdhZG1pbi91dGlscy9kcml2ZXIvcHN5Y29wZzIvdHlwZWNhc3QucHkK aW5kZXggZjEzNjYwNDkuLmE4ZjZjMzg1IDEwMDY0NAotLS0gYS93ZWIvcGdhZG1pbi91dGlscy9k cml2ZXIvcHN5Y29wZzIvdHlwZWNhc3QucHkKKysrIGIvd2ViL3BnYWRtaW4vdXRpbHMvZHJpdmVy L3BzeWNvcGcyL3R5cGVjYXN0LnB5CkBAIC0xNjMsNDkgKzE2Myw2IEBAIGRlZiByZWdpc3Rlcl9n bG9iYWxfdHlwZWNhc3RlcnMoKToKICAgICBwc3ljb3BnMi5leHRlbnNpb25zLnJlZ2lzdGVyX3R5 cGUocGdfYXJyYXlfdHlwZXNfdG9fYXJyYXlfb2Zfc3RyaW5nX3R5cGUpCiAKIAotZGVmIHJlZ2lz dGVyX3N0cmluZ190eXBlY2FzdGVycyhjb25uZWN0aW9uKToKLSAgICBpZiBjb25uZWN0aW9uLmVu Y29kaW5nICE9ICdVVEY4JzoKLSAgICAgICAgIyBJbiBweXRob24zIHdoZW4gZGF0YWJhc2UgZW5j b2RpbmcgaXMgb3RoZXIgdGhhbiB1dGYtOCBhbmQgY2xpZW50Ci0gICAgICAgICMgZW5jb2Rpbmcg aXMgc2V0IHRvIFVOSUNPREUgdGhlbiB3ZSBuZWVkIHRvIG1hcCBkYXRhIGZyb20gZGF0YWJhc2UK LSAgICAgICAgIyBlbmNvZGluZyB0byB1dGYtOC4KLSAgICAgICAgIyBUaGlzIGlzIHJlcXVpcmVk IGJlY2F1c2Ugd2hlbiBjbGllbnQgZW5jb2RpbmcgaXMgc2V0IHRvIFVOSUNPREUgdGhlbgotICAg ICAgICAjIHBzeWNvcGcgYXNzdW1lcyBkYXRhYmFzZSBlbmNvZGluZyB1dGYtOCBhbmQgbm90IHRo ZSBhY3R1YWwgZW5jb2RpbmcuCi0gICAgICAgICMgTm90IHN1cmUgd2hldGhlciBpdCdzIGJ1ZyBv ciBmZWF0dXJlIGluIHBzeWNvcGcgZm9yIHB5dGhvbjMuCi0gICAgICAgIGlmIHN5cy52ZXJzaW9u X2luZm8gPj0gKDMsKToKLSAgICAgICAgICAgIGRlZiByZXR1cm5fYXNfdW5pY29kZSh2YWx1ZSwg Y3Vyc29yKToKLSAgICAgICAgICAgICAgICBpZiB2YWx1ZSBpcyBOb25lOgotICAgICAgICAgICAg ICAgICAgICByZXR1cm4gTm9uZQotICAgICAgICAgICAgICAgICMgVHJlYXQgdmFsdWUgYXMgYnl0 ZSBzZXF1ZW5jZSBvZiBkYXRhYmFzZSBlbmNvZGluZyBhbmQgdGhlbgotICAgICAgICAgICAgICAg ICMgZGVjb2RlIGl0IGFzIHV0Zi04IHRvIGdldCBjb3JyZWN0IHVuaWNvZGUgdmFsdWUuCi0gICAg ICAgICAgICAgICAgcmV0dXJuIGJ5dGVzKAotICAgICAgICAgICAgICAgICAgICB2YWx1ZSwgZW5j b2RpbmdzW2N1cnNvci5jb25uZWN0aW9uLmVuY29kaW5nXQotICAgICAgICAgICAgICAgICkuZGVj b2RlKCd1dGYtOCcpCi0KLSAgICAgICAgICAgIHVuaWNvZGVfdHlwZSA9IHBzeWNvcGcyLmV4dGVu c2lvbnMubmV3X3R5cGUoCi0gICAgICAgICAgICAgICAgIyAiY2hhciIsIG5hbWUsIHRleHQsIGNo YXJhY3RlciwgY2hhcmFjdGVyIHZhcnlpbmcKLSAgICAgICAgICAgICAgICAoMTksIDE4LCAyNSwg MTA0MiwgMTA0MywgMCksCi0gICAgICAgICAgICAgICAgJ1VOSUNPREUnLCByZXR1cm5fYXNfdW5p Y29kZSkKLSAgICAgICAgZWxzZToKLSAgICAgICAgICAgIGRlZiByZXR1cm5fYXNfdW5pY29kZSh2 YWx1ZSwgY3Vyc29yKToKLSAgICAgICAgICAgICAgICBpZiB2YWx1ZSBpcyBOb25lOgotICAgICAg ICAgICAgICAgICAgICByZXR1cm4gTm9uZQotICAgICAgICAgICAgICAgICMgRGVjb2RlIGl0IGFz IHV0Zi04IHRvIGdldCBjb3JyZWN0IHVuaWNvZGUgdmFsdWUuCi0gICAgICAgICAgICAgICAgcmV0 dXJuIHZhbHVlLmRlY29kZSgndXRmLTgnKQotCi0gICAgICAgICAgICB1bmljb2RlX3R5cGUgPSBw c3ljb3BnMi5leHRlbnNpb25zLm5ld190eXBlKAotICAgICAgICAgICAgICAgICMgImNoYXIiLCBu YW1lLCB0ZXh0LCBjaGFyYWN0ZXIsIGNoYXJhY3RlciB2YXJ5aW5nCi0gICAgICAgICAgICAgICAg KDE5LCAxOCwgMjUsIDEwNDIsIDEwNDMsIDApLAotICAgICAgICAgICAgICAgICdVTklDT0RFJywg cmV0dXJuX2FzX3VuaWNvZGUpCi0KLSAgICAgICAgdW5pY29kZV9hcnJheV90eXBlID0gcHN5Y29w ZzIuZXh0ZW5zaW9ucy5uZXdfYXJyYXlfdHlwZSgKLSAgICAgICAgICAgICMgImNoYXIiW10sIG5h bWVbXSwgdGV4dFtdLCBjaGFyYWN0ZXJbXSwgY2hhcmFjdGVyIHZhcnlpbmdbXQotICAgICAgICAg ICAgKDEwMDIsIDEwMDMsIDEwMDksIDEwMTQsIDEwMTUsIDAKLSAgICAgICAgICAgICApLCAnVU5J Q09ERUFSUkFZJywgdW5pY29kZV90eXBlKQotCi0gICAgICAgIHBzeWNvcGcyLmV4dGVuc2lvbnMu cmVnaXN0ZXJfdHlwZSh1bmljb2RlX3R5cGUpCi0gICAgICAgIHBzeWNvcGcyLmV4dGVuc2lvbnMu cmVnaXN0ZXJfdHlwZSh1bmljb2RlX2FycmF5X3R5cGUpCi0KLQogZGVmIHJlZ2lzdGVyX2JpbmFy eV90eXBlY2FzdGVycyhjb25uZWN0aW9uKToKICAgICBwc3ljb3BnMi5leHRlbnNpb25zLnJlZ2lz dGVyX3R5cGUoCiAgICAgICAgIHBzeWNvcGcyLmV4dGVuc2lvbnMubmV3X3R5cGUoCmRpZmYgLS1n aXQgYS93ZWIvcmVncmVzc2lvbi9weXRob25fdGVzdF91dGlscy90ZXN0X3V0aWxzLnB5IGIvd2Vi L3JlZ3Jlc3Npb24vcHl0aG9uX3Rlc3RfdXRpbHMvdGVzdF91dGlscy5weQppbmRleCAzZTUxN2I2 MS4uNDY0YTA5ZTEgMTAwNjQ0Ci0tLSBhL3dlYi9yZWdyZXNzaW9uL3B5dGhvbl90ZXN0X3V0aWxz L3Rlc3RfdXRpbHMucHkKKysrIGIvd2ViL3JlZ3Jlc3Npb24vcHl0aG9uX3Rlc3RfdXRpbHMvdGVz dF91dGlscy5weQpAQCAtMTE2LDcgKzExNiw3IEBAIGRlZiBjbGVhcl9ub2RlX2luZm9fZGljdCgp OgogICAgICAgICBkZWwgbm9kZV9pbmZvX2RpY3Rbbm9kZV1bOl0KIAogCi1kZWYgY3JlYXRlX2Rh dGFiYXNlKHNlcnZlciwgZGJfbmFtZSk6CitkZWYgY3JlYXRlX2RhdGFiYXNlKHNlcnZlciwgZGJf bmFtZSwgZW5jb2Rpbmc9Tm9uZSk6CiAgICAgIiIiVGhpcyBmdW5jdGlvbiB1c2VkIHRvIGNyZWF0 ZSBkYXRhYmFzZSBhbmQgcmV0dXJucyB0aGUgZGF0YWJhc2UgaWQiIiIKICAgICB0cnk6CiAgICAg ICAgIGNvbm5lY3Rpb24gPSBnZXRfZGJfY29ubmVjdGlvbigKQEAgLTEzMCw4ICsxMzAsMTQgQEAg ZGVmIGNyZWF0ZV9kYXRhYmFzZShzZXJ2ZXIsIGRiX25hbWUpOgogICAgICAgICBvbGRfaXNvbGF0 aW9uX2xldmVsID0gY29ubmVjdGlvbi5pc29sYXRpb25fbGV2ZWwKICAgICAgICAgY29ubmVjdGlv bi5zZXRfaXNvbGF0aW9uX2xldmVsKDApCiAgICAgICAgIHBnX2N1cnNvciA9IGNvbm5lY3Rpb24u Y3Vyc29yKCkKLSAgICAgICAgcGdfY3Vyc29yLmV4ZWN1dGUoCi0gICAgICAgICAgICAnJydDUkVB VEUgREFUQUJBU0UgIiVzIiBURU1QTEFURSB0ZW1wbGF0ZTAnJycgJSBkYl9uYW1lKQorICAgICAg ICBpZiBlbmNvZGluZyBpcyBOb25lOgorICAgICAgICAgICAgcGdfY3Vyc29yLmV4ZWN1dGUoCisg ICAgICAgICAgICAgICAgJycnQ1JFQVRFIERBVEFCQVNFICIlcyIgVEVNUExBVEUgdGVtcGxhdGUw JycnICUgZGJfbmFtZSkKKyAgICAgICAgZWxzZToKKyAgICAgICAgICAgIHBnX2N1cnNvci5leGVj dXRlKAorICAgICAgICAgICAgICAgICcnJ0NSRUFURSBEQVRBQkFTRSAiJXMiIFRFTVBMQVRFIHRl bXBsYXRlMAorICAgICAgICAgICAgICAgIEVOQ09ESU5HPSclcycgTENfQ09MTEFURT0nJXMnIExD X0NUWVBFPSclcycgJycnICUKKyAgICAgICAgICAgICAgICAoZGJfbmFtZSwgZW5jb2RpbmdbMF0s IGVuY29kaW5nWzFdLCBlbmNvZGluZ1sxXSkpCiAgICAgICAgIGNvbm5lY3Rpb24uc2V0X2lzb2xh dGlvbl9sZXZlbChvbGRfaXNvbGF0aW9uX2xldmVsKQogICAgICAgICBjb25uZWN0aW9uLmNvbW1p dCgpCiAK --0000000000004b6f27056e93e3ec--