Can't install different version once installed

In a new directory enter pnpm install<EMAIL_ADDRESS>When it's finished, enter pnpm install<EMAIL_ADDRESS>Nothing happens - the previous version remains.

Yeah, it doesn't verify installed versions, haha. Not yet anyway. Something
to fix before declaring 1.0.0 for sure.
As a workaround, "rm" the symlink in node_modules/ember-cli first.
On Sunday, January 31, 2016, Adam Byrne<EMAIL_ADDRESS>wrote:

In a new directory enter pnpm install<EMAIL_ADDRESS>When it's finished, enter pnpm install<EMAIL_ADDRESS>Nothing happens - the previous version remains.
—
Reply to this email directly or view it on GitHub
https://github.com/rstacruz/pnpm/issues/51.

thanks for the reports, btw! feedback at this point really helps in prioritizing what's important to folks and finding edge cases i may not be finding myself.

No probs - I'm very excited about this project! 😄 Awesome work!

This one was fixed


HBASE-22012 Space Quota: DisableTableViolationPolicy will cause cycles of enable/disable table

Space Quota: Policy state is getting changed from disable to Observance after sometime automatically.
Steps:
1: Create a table with space quota policy as Disable
2: Put some data so that table state is in space quota violation
3: So observe that table state is in violation
4: Now wait for some time
5: Observe that after some time table state is changing to to Observance however table is still disabled
Solution:  it is better to not remove the entries from cache regionSizes if table is in violation and has DISABLE policy set on it to avoid this repeat cycle of enable/disable. If the entries are not removed from the cache for disable policy and violation tables the table will not go from disable to enable even though regions of the table are offline.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
118
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

+1
mvninstall
501
master passed

+1
compile
75
master passed

+1
checkstyle
103
master passed

+1
shadedjars
366
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
53
master passed

0
spotbugs
317
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
315
master passed

_ Patch Compile Tests _

+1
mvninstall
453
the patch passed

+1
compile
78
the patch passed

+1
javac
78
the patch passed

+1
checkstyle
108
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
368
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1415
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
javadoc
52
the patch passed

+1
findbugs
340
the patch passed

_ Other Tests _

-1
unit
13584
hbase-server in the patch failed.

+1
asflicense
26
The patch does not generate ASF License warnings.

18490

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/572

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 0447dc6a2f5a 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-572/out/precommit/personality/provided.sh

git revision
master / 345c21dbe7

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/1/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/1/testReport/

Max. process+thread count
4892 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/1/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

+1
mvninstall
323
master passed

+1
compile
55
master passed

+1
checkstyle
77
master passed

+1
shadedjars
275
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
37
master passed

0
spotbugs
262
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
260
master passed

_ Patch Compile Tests _

+1
mvninstall
291
the patch passed

+1
compile
58
the patch passed

+1
javac
58
the patch passed

+1
checkstyle
75
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
267
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
912
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
javadoc
39
the patch passed

+1
findbugs
272
the patch passed

_ Other Tests _

-1
unit
10431
hbase-server in the patch failed.

+1
asflicense
32
The patch does not generate ASF License warnings.

13820

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/572

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux a1bbdf86b2a2 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-572/out/precommit/personality/provided.sh

git revision
master / a5ef6b287c

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/2/testReport/

Max. process+thread count
4601 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/2/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
32
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

+1
mvninstall
351
master passed

+1
compile
57
master passed

+1
checkstyle
88
master passed

+1
shadedjars
297
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
36
master passed

0
spotbugs
266
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
264
master passed

_ Patch Compile Tests _

+1
mvninstall
334
the patch passed

+1
compile
57
the patch passed

+1
javac
57
the patch passed

+1
checkstyle
87
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
299
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1016
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
javadoc
34
the patch passed

+1
findbugs
267
the patch passed

_ Other Tests _

-1
unit
9424
hbase-server in the patch failed.

+1
asflicense
26
The patch does not generate ASF License warnings.

13077

Reason
Tests

Failed junit tests
hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/572

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux b7879d3eb4cc 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-572/out/precommit/personality/provided.sh

git revision
master / 9bed419cb0

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/3/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/3/testReport/

Max. process+thread count
4444 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/3/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Yep. It's on my list -- Shardul pinged me already :)
Thanks for asking, S.

@joshelser , thanks for the review..did all the changes and pushed.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
0m 36s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  0s
No case conflicting files found.

:green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

:green_heart:
test4tests
0m  0s
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

:green_heart:
mvninstall
5m 33s
master passed

:green_heart:
compile
0m 56s
master passed

:green_heart:
checkstyle
1m 18s
master passed

:green_heart:
shadedjars
4m 32s
branch has no errors when building our shaded downstream artifacts.

:green_heart:
javadoc
0m 38s
master passed

:blue_heart:
spotbugs
4m  1s
Used deprecated FindBugs config; considering switching to SpotBugs.

:green_heart:
findbugs
3m 58s
master passed

_ Patch Compile Tests _

:green_heart:
mvninstall
4m 52s
the patch passed

:green_heart:
compile
1m  5s
the patch passed

:green_heart:
javac
1m  5s
the patch passed

:green_heart:
checkstyle
1m 20s
the patch passed

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

:green_heart:
shadedjars
4m 29s
patch has no errors when building our shaded downstream artifacts.

:green_heart:
hadoopcheck
16m 20s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

:green_heart:
javadoc
0m 34s
the patch passed

:broken_heart:
findbugs
4m 10s
hbase-server generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0)

_ Other Tests _

:broken_heart:
unit
156m 59s
hbase-server in the patch failed.

:green_heart:
asflicense
0m 35s
The patch does not generate ASF License warnings.

214m 49s

Reason
Tests

FindBugs
module:hbase-server

Null pointer dereference of tableQuotaSnapshot in org.apache.hadoop.hbase.quotas.MasterQuotaManager.isInViolationAndPolicyDisable(TableName, QuotaObserverChore)  Dereferenced at MasterQuotaManager.java:in org.apache.hadoop.hbase.quotas.MasterQuotaManager.isInViolationAndPolicyDisable(TableName, QuotaObserverChore)  Dereferenced at MasterQuotaManager.java:[line 757]

Load of known null value in org.apache.hadoop.hbase.quotas.MasterQuotaManager.isInViolationAndPolicyDisable(TableName, QuotaObserverChore)  At MasterQuotaManager.java:in org.apache.hadoop.hbase.quotas.MasterQuotaManager.isInViolationAndPolicyDisable(TableName, QuotaObserverChore)  At MasterQuotaManager.java:[line 756]

Failed junit tests
hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/572

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 560cf133dc92 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-572/out/precommit/personality/provided.sh

git revision
master / 537c5f0660

Default Java
1.8.0_181

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/6/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/6/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/6/testReport/

Max. process+thread count
4540 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/6/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
2m 32s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  0s
No case conflicting files found.

:green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

:green_heart:
test4tests
0m  0s
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

:green_heart:
mvninstall
6m 34s
master passed

:green_heart:
compile
1m  9s
master passed

:green_heart:
checkstyle
1m 39s
master passed

:green_heart:
shadedjars
5m  9s
branch has no errors when building our shaded downstream artifacts.

:green_heart:
javadoc
0m 41s
master passed

:blue_heart:
spotbugs
4m 35s
Used deprecated FindBugs config; considering switching to SpotBugs.

:green_heart:
findbugs
4m 33s
master passed

_ Patch Compile Tests _

:green_heart:
mvninstall
5m 56s
the patch passed

:green_heart:
compile
1m  8s
the patch passed

:green_heart:
javac
1m  8s
the patch passed

:green_heart:
checkstyle
1m 30s
the patch passed

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

:green_heart:
shadedjars
5m 41s
patch has no errors when building our shaded downstream artifacts.

:green_heart:
hadoopcheck
18m 32s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

:green_heart:
javadoc
0m 35s
the patch passed

:green_heart:
findbugs
4m  8s
the patch passed

_ Other Tests _

:broken_heart:
unit
277m 52s
hbase-server in the patch failed.

:green_heart:
asflicense
0m 36s
The patch does not generate ASF License warnings.

344m 44s

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas

hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.2 Server=19.03.2 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/572

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 7032311cacc4 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-572/out/precommit/personality/provided.sh

git revision
master / 537c5f0660

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/7/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/7/testReport/

Max. process+thread count
4845 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-572/7/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

Looks ok now. Let me try to get this in.

Required some minor changes across branch-2.2/2 and more changes in branch-2.1.
Re-running the UTs on branch-2.1 now.


#713 include options in sortComplete

The sortComplete event would be a great place to pass back the sort options.
This could also potentially close issue #689.
This facilitates potential solutions for #650.
Thank you for your consideration on this PR.

I think the same thing should be done for the search & filter events. This would also fix point 14 on the wishlist.


stop relying on openssl/pyopenssl

Since we are already using: https://cryptography.io/en/latest/
we should use it for everything and replace everywhere we are using pyopenssl: https://github.com/komuW/sewer/blob/master/sewer/ACMEclient.py#L11 with it.

both pyopenssl and cryptography are maintained by same organisation: https://github.com/pyca.
one is specifically for cryptography and the other as a wrapper for openssl


Multiplayer intro swirl camera sometimes jitters.

How to reproduce: Start a multiplayer match, and sometimes the camera swirl animation will jitter.
https://github.com/fgsfdsfgs/perfect_dark/assets/130617241/b07077df-0aaf-470e-bfce-7267fe5bf102

This has probably been fixed in d7926f1.

Appears to be fixed, this also fixed the Camspy rotation in https://github.com/fgsfdsfgs/perfect_dark/issues/20#issue-1853135268


Ambiguous error message at statup

Describe the issue
Once the liquid-qt is launched, if the bitcoin server is not correctly configured, the app displays an ambiguous error message. A user may not adequately understand the need to install a bitcoin node.
If so, please list the steps to reproduce below:
Start liquid-qt  app without other arguments (and without a configuration file).
Expected behaviour
Suggest to install bitcoin core (maybe with a link to bitcoincore.org) and to configure liquid appropriately.
Actual behaviour
Show an error message and halt the app.
Screenshots

Machine specs:
MacOSX 10.14.3

Does it make sense for normal users to verify pegins? Maybe it should be disabled by default unless mining?

@greenaddress pointed out that pegins are needed to verify unconfirmed transactions.

I would keep the error and add to it:
"If you haven't setup a bitcoind please get the latest stable version from https://bitcoincore.org/en/download/ or if you do not need to validate pegins
set in your liquid configuration validatepegin=0"

Fixed in 4532fb5feda3391494498fbeca801d8b89700042

I think we need the config file location for newbie users.
"If you haven't setup a bitcoind please get the latest stable version from https://bitcoincore.org/en/download/ or if you do not need to validate pegins,
set 'validatepegin=0' in your liquid configuration file (located at %s/liquid.conf)"


httpie refuses to trust a self-signed certificate

I don't entirely understand the discussion for issue #480 but I think the root cause may be the same for this issue. I need httpie to trust a self-signed certificate. Technically it is a self-signed intermediate certificate authority, but I can use one of the actual server certificates from that authority and get the same result. This certificate satisfies every other application on my Mac (OS 10.12), including curl. Httpie simply won't trust it. Sample output:
$ http --debug -j --verify=/usr/local/etc/openssl/certs/intermediate-authority.pem https://www.testdomain.com/robots.txt
HTTPie 0.9.9
Requests 2.12.3
Pygments 2.1.3
Python 3.6.1 (default, Mar 24 2017, 17:14:46)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-8<IP_ADDRESS>)]
/usr/local/Cellar/httpie/0.9.9/libexec/bin/python3.6
Darwin 16.5.0

<Environment {
    "colors": 256,
    "config": {
        "__meta__": {
            "about": "HTTPie configuration file",
            "help": "https://github.com/jkbrzt/httpie#config",
            "httpie": "0.9.4"
        },
        "default_options": "[]"
    },
    "config_dir": "/Users/username/.httpie",
    "is_windows": false,
    "stderr": "<_io.TextIOWrapper name='<stderr>' mode='w' encoding='UTF-8'>",
    "stderr_isatty": true,
    "stdin": "<_io.TextIOWrapper name='<stdin>' mode='r' encoding='UTF-8'>",
    "stdin_encoding": "UTF-8",
    "stdin_isatty": true,
    "stdout": "<_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>",
    "stdout_encoding": "UTF-8",
    "stdout_isatty": true
}>

>>> requests.request(**{
    "allow_redirects": false,
    "auth": "None",
    "cert": "None",
    "data": "",
    "files": {},
    "headers": {
        "Accept": "application/json, */*",
        "Content-Type": "application/json",
        "User-Agent": "HTTPie/0.9.9"
    },
    "method": "get",
    "params": {},
    "proxies": {},
    "stream": true,
    "timeout": 30,
    "url": "https://www.testdomain.com/robots.txt",
    "verify": "/usr/local/etc/openssl/certs/intermediate-authority.pem"
})

http: error: SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) while doing GET request to URL: https://www.testdomain.com/robots.txt
Traceback (most recent call last):
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/packages/urllib3/connectionpool.py", line 588, in urlopen
    self._prepare_proxy(conn)
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/packages/urllib3/connectionpool.py", line 801, in _prepare_proxy
    conn.connect()
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/packages/urllib3/connection.py", line 323, in connect
    ssl_context=context)
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/packages/urllib3/util/ssl_.py", line 324, in ssl_wrap_socket
    return context.wrap_socket(sock, server_hostname=server_hostname)
  File "/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 401, in wrap_socket
    _context=self, _session=session)
  File "/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 808, in __init__
    self.do_handshake()
  File "/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/adapters.py", line 423, in send
    timeout=timeout
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/packages/urllib3/connectionpool.py", line 624, in urlopen
    raise SSLError(e)
requests.packages.urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/http", line 11, in <module>
    load_entry_point('httpie==0.9.9', 'console_scripts', 'http')()
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/httpie/__main__.py", line 11, in main
    sys.exit(main())
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/httpie/core.py", line 227, in main
    log_error=log_error,
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/httpie/core.py", line 99, in program
    final_response = get_response(args, config_dir=env.config.directory)
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/httpie/client.py", line 70, in get_response
    response = requests_session.request(**kwargs)
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/Cellar/httpie/0.9.9/libexec/lib/python3.6/site-packages/requests/adapters.py", line 497, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749)

If I use --verify=no, the connection is accepted. I've tried converting the certificate file to DER format instead of PEM with no change.
Httpie was installed via Homebrew, which installed its own Python3 as a dependency.

Trusting a self-signed certificate is never encouraged. It is dangerous if a program accepts it by default. A hacker can simply inject a self-signed one to make the users feeling secure while it is not the case.
However, I would suggest httpie to response the issue of using a self-signed certificate with a clearer message rather than simply fail it. A suggestion to use --verify=no to disable the verification for testing purpose would be great.

@giskard22

I don't entirely understand the discussion for issue #480 but I think the root cause may be the same for this issue. I need httpie to trust a self-signed certificate. Technically it is a self-signed intermediate certificate authority, but I can use one of the actual server certificates from that authority and get the same result.

Looking at #480 this is not the same root cause. HTTPie is, in this case, using the bundle you provide it.
What I suspect is actually the cause is the following:
Your "test domain" is not returning the full certificate chain but only its leaf (which works fine for browsers which can dynamically retrieve the rest of the chain) but not for httpie and other non-browser clients. In this case, you're providing part of the chain via --verify but still not all of the intermediaries. If you place them all in one bundle and provide that instead, I suspect you'll find that this works.

Trusting a self-signed certificate is never encouraged. It is dangerous if a program accepts it by default. A hacker can simply inject a self-signed one to make the users feeling secure while it is not the case.

@alvis blanket advice is usually wrong and in this case it's quite alarmingly wrong. Self-signed certificates are a solution to a problem. I don't know @giskard22's use case for using a self-signed certificate here and neither do you. In that case your advice is not only most likely useless to @giskard22, it's also noise for the rest of the people receiving email notifications from issues on this repository.
Self-signed certificates can be dangerous to trust without verification but in this case it seems @giskard22 knows the trust chain and trusts it making this usage perfectly safe. Yes, if you happen upon a site using HTTPS that you might need to enter sensitive information into, it is not advisable to use a self-signed certificate but this is a wildly different situation as I understand it.

Yes, the use case here is using httpie through a corporate web proxy that does HTTPS man-in-the-middle so it can inspect traffic. It generates a domain-specific certificate on the fly. Blah.
I don't understand how the proxy's failure to provide a full certificate chain causes this issue. Perhaps OpenSSL's behavior (or is it Python's behavior?) is different than MacOS's built-in mechanism.
The trust chain for connections through the proxy looks like this:

On-the-fly certificate issued to www.testdomain.com
Intermediate CA certificate called proxy-name
Self-signed root CA certificate called domain.org

I have been unable to obtain certificate 3. However, certificate 2 is available from the proxy. I imported into my Keychain and marked it trusted for SSL use. That was enough to satisfy everything on my Mac except httpie, including other command-line tools like curl. The observed behavior is the validation mechanism follows the chain until it finds a trusted certificate, then stops. The root certificate's absence is irrelevant.
In the httpie debug output I posted in my initial report, I had stored certificate 2 in intermediate-authority.pem and specified that file with --verify. Are you saying that for httpie, that's not enough and I must also provide certificate 3?

Perhaps OpenSSL's behavior (or is it Python's behavior?) is different than MacOS's built-in mechanism.

So OpenSSL will look in the bundle you provide it for whatever it's missing. If it cannot find it there it fails the verification. This is transitively also Python's behaviour. SecureTransport (MacOS's built-in mechanism) works slightly differently but only if the certificates are in MacOS's Keychain. Also, on MacOS the default Python has a hacked-up (for lack of a better term) version of OpenSSL that uses Keychain and thus can resolve these even if you provide it your own certificate bundle (i.e., if you tell it only to trust what's in a bundle file, it'll say "LOL, but I got Keychain access and that trusts it so YOLO" ... or YOVO? (You Only Verify Once... Idk)).
If the entire trust chain for these on-the-fly certificates is what you described, I think you should be able to get away with having a bundle that only includes links 2 and 3 in the chain.
Also, if you installed httpie from homebrew on MacOS then it was installed with the homebrew versions of OpenSSL, Python, and virtualenv which is why it cannot take advantage of a Mac's hacked-up OpenSSL.

I was finally able to identify and obtain the self-signed root certificate. Upon putting both that cert and the intermediate cert in a .pem file and using that file with --verify, I no longer got the SSL error. This is good! As suggested, OpenSSL requires the entire certificate chain. Unlike SecureTransport, it won't accept a partial chain even if manually supplied.
Any thoughts on the following additional complication? The proxy lets traffic go to certain domains without inserting its custom certificate. It looks like you cannot use multiple --verify arguments. The last one wins. Is there any way to use multiple certificate bundles?
I have a workaround that involves concatenating OpenSSL's provided root CA bundle and the custom bundle upon demand, but hoping to avoid that.

So OpenSSL supports providing a directory full of .pem files for verification. That said, support for that in Python is spotty. I don't honestly think anything older than Python 3.5 or 3.6 supports directories in the standard library and I don't recall if pyOpenSSL will support it. The short of it is that I don't think you can accomplish your ends without having one all-serving .pem file. The other catch here is that the HTTP transport library that HTTPie uses doesn't quite support directories either given the limited support across versions and TLS library implementations.

ol' Postman to the rescue. You can turn off detection of self signed cert.

SSL is good, probably devs know that.  Disabling SSL because of corner cases and language limitations or whatever stinks.  I know people just want to get work done.  I just wonder when we'll say SSL is good and have the same gut reaction at saying "disable SSL verification".    But SSL is good.  We all know that right?  Is it confusing or common knowledge that SSL verification is really what the whole SSL thing is?  If postman has an option to disable SSL verification is that just a fancy way of saying something that is potentially insecure? curl has that same option as a flag called --insecure.  Is it just a fancy way that hides exactly what the problem is (it turns off SSL)?
I hope https dev machines, self signed certs and corporate CAs are supplanted by scriptable automatic letsencrypt certs one day.  It's a shame that python makes http less organic at trusting the system keychain / ssl store.  It's a curl replacement except in this area.  I guess golang has operating system detection for all this stuff.  So a modern curl replacement (like bat) that's written in go would have pretty output, a nice CLI experience and handle custom CAs or ssl termination (load balancers).

SSL is good, probably devs know that. Disabling SSL because of corner cases and language limitations or whatever stinks. I know people just want to get work done. I just wonder when we'll say SSL is good and have the same gut reaction at saying "disable SSL verification".  But SSL is good. We all know that right? Is it confusing or common knowledge that SSL verification is really what the whole SSL thing is? If postman has an option to disable SSL verification is that just a fancy way of saying something that is potentially insecure? curl has that same option as a flag called --insecure. Is it just a fancy way that hides exactly what the problem is (it turns off SSL)? I think it's fine to test in Postman. TIL that Postman has that option. Am I going to turn it back on? Or did I just disable SSL for every current and future project? Am I sending API keys from a coffee shop? :|
I hope https dev machines, self signed certs and corporate CAs are supplanted by scriptable automatic letsencrypt certs one day. It's a shame that python makes http less organic at trusting the system keychain / ssl store. It's a curl replacement except in this area. I guess golang has operating system detection for all this stuff. So a modern curl replacement (like bat) that's written in go would have pretty output, a nice CLI experience and handle custom CAs or ssl termination (load balancers).

Nope, not good. Need to be able to curl even if adhoc developer certificate.

I think we all know that we should not be using self signed SSL certs, but sometimes, in a dev environment, you just want to get on with it.
It should be possible to use these certificates, if they are sgned by a CA, that is entered into your OS trust store? (even if the CA is yourself). Most browsers are ok with this.
Not trusting a Self signed certs is a pain, esp if you are running on your own network.
Back to curl, postman or insomnia.

I believe it's an anti-pattern to train users to turn off certificate verification for self-signed certs.
httpie is used widely in my current (very large) org, we have a internal trusted CA cert that isn't public and isn't used for public internet trusts.
httpie - unlike curl (when compiled with SecureTransport) - can't use this internal CA trust (in the keychain for our MacOS developer systems), which is a great shame and only enforces user/developer behaviour to turn off verification, when there is absolutely a good reason not to.

Hi,
What is exposed in the discussion is weird: most of the intervenants seem to think that a self-signed certificate is a "bad thing".
In my case, I'm using Vault as a PKI cert issuer and I don't understand why I could not trust my own certs as I know these are secure, on my side.
I use httpie mainly to check if my URLs and entrypoints are OK, before configuring my monitoring to do some health checks. In the monitoring I WON'T turn off SSL check, so why should I disable it on my manual test ? This won't make it as close as possible to the monitoring point of view.
So, I agree with @tomtastic : this is not cool not to be able to use internal keychain for validation.
My 50 cents...


Update master with es6 tutorial and better notes.

We would like to encourage users to use ES6 while building Material Start, but would also like to clarify the other branches and their purpose.
To do this, we will:

[ ] Ensure es5 and es5-tutorial branches are in-sync and up-to-date
[ ] Update the master branch to use the ES6 final code
[ ] Update the master README to include more information and links to the other branches

Will use these branches at Angular Connect 2016.

Done; just need to make master the default branch.


[Bug]: New version(v0.8.1) not support Chinese system

Is there an existing issue for this?

[X] I have searched the existing issues and checked the recent builds/commits

What happened?
Throw exception while asking Bing by Chinese
Exception: InvalidRequest: Culture is not supported. (Parameter 'name')
Chinese (Simplified)-People's Republic of China is an invalid culture identifier
Steps to reproduce the problem
Run it in Chinese system, and ask Bing by Chinese
What should have happened?
Answer the question
Version where the problem happens
0.8.1
What Python version are you running this with?
3.8,10
What is your operating system ?
Windows
Command Line Arguments
No

Console logs
Traceback (most recent call last):
  File "api.py", line 132, in bing_main
    response = await bot.ask(prompt, conversation_style=conversation_style)
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python38\lib\site-p
ackages\EdgeGPT.py", line 753, in ask
    async for final, response in self.chat_hub.ask_stream(
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python38\lib\site-p
ackages\EdgeGPT.py", line 658, in ask_stream
    raise Exception(
Exception: InvalidRequest: Culture is not supported. (Parameter 'name')
Chinese (Simplified)-People's Republic of China is an invalid culture identifier
.
Traceback (most recent call last):
  File "api.py", line 211, in bing_request
    quotes = message["adaptiveCards"][0]["body"]
TypeError: 'NoneType' object is not subscriptable

Additional information
No response

ans = await bot.ask(prompt=txt, conversation_style=ConversationStyle.creative, locale="zh-cn")自己指定地区就可以了

好像是Windows平台的问题，getlocale获取的格式不是en_US这样
指定locale在连续第二次请求之后传递不过去，PR #489 可以修复这个


Downsampling with caggs example broken

The documentation for downsampling with caggs is broken: https://docs.timescale.com/promscale/latest/downsample-data/caggs/#continuous-aggregates-in-promscale.

It doesn't correctly handle the fact that the metric name is mixed-case
The cagg definition fails to load with ERROR:  only immutable functions supported in continuous aggregate view.

closing this issue, as it's duplicate of #1080


Error during MacOS installation via brew

Describe the bug
Attempting to install azure-cli via brew on MacOS is resulting in the following error:

==> Pouring python-3.7.4.mojave.bottle.tar.gz
Error: An unexpected error occurred during the brew link step
The formula built, but is not symlinked into /usr/local
Permission denied @ dir_s_mkdir - /usr/local/Frameworks
Error: Permission denied @ dir_s_mkdir - /usr/local/Frameworks

To Reproduce
Run the following in a terminal:
brew install azure-cli
Expected behavior
The installation should proceed error-free.
Environment summary
Install Method: brew
CLI version: stable 2.0.72 (bottled), HEAD
OS version: MacOS mojave 10.14.6
Shell Type: bash via iTerm2

This is potentially not an issue with azure-cli specifically. A little searching turned up this solution:
sudo install -d -o $(whoami) -g admin /usr/local/Frameworks
After running the above, I was able to successfully install it.

I am glad it is solved. If any issue comes up, please don't hesitate to let us know.


Escape variables in Less_Parser::serializeVars() using tilda and quotes

Escape variables in Less_Parser::serializeVars() using tilda and quotes.
In my case this was breaking the compilation:
$parser->ModifyVars(array('__CSS_URL__' => 'http://www.example.com/css/'));

translates into:
@__CSS_URL__: http://www.example.com/css/;

Unfortunately, less.js doesn't do anything like this

Still a valid issue.
I've posted a PR to less.js.


Improving the services section

@tushargupta1504
i would like to improve the styling of service section .
i believe i can do this task efficiently as i have a strong hold over css styling and have completed many projects.
please assign me this task under GSSoC24 extd and hactoberfest , also assign the level label.

I would like to improve the styling of the service section.
I believe I can do this task efficiently as I have a strong hold over CSS styling and have completed many projects.
please assign me this task


Knex cant recycle the connection pool

We use Knex with generic pool as our Query Builder and Pool Manager for our Oracle 11.2 Database.
The problem we are facing is that some time Knex / generic-pool starts to accumulate connections and cant recycle them.
I tried to pass some parameters to Knex / Generic Pool to make them kill connections after some point, but looks like it did not worked out.
Packges version:

Knex: v0.13.0
Oracledb: v1.13.1
Generic Pool: v2.5.4
Knex configuration:

{
    client: 'oracledb',
    connection: {
        user: DB_USER,
        password: DB_PASSWORD,
        host: `${DB_HOST}:${DB_PORT}`,
        database: DB_NAME
    },
    debug: true,
    fetchAsString: ['number', 'clob'],
    acquireConnectionTimeout: 843600000,
    pool: {
        min: 2,
        max: 150,
        acquireTimeoutMillis: 100000,
        evictionRunIntervalMillis: 120000,
        maxWaitingClients: 100,
        idleTimeoutMillis: 100000
    }
}

Edit:
Adding a Openshift print with environment variable DEBUG="knex:*" to show the current pool state:
https://i.stack.imgur.com/DepZs.png

What kind of code is it that accumulates connections. Please add complete example code to reproduce. Just a config is not enough. Does this happen with latest knex too?

@elhigu
Some sample code here. I will try with the latest version.
return rxifyPromiseFn(() => this.knexInstance.client.acquireRawConnection())             .switchMap((connection: oracledb.IConnection) => {                 return fromPromise(connection.execute(sqlCommand, bindings)) 		}).then(doSomething) 		  .catch(error)

Sorry for take so much time to reply.
I'm testing with Knex 0.14.2 in our homologation environment starting today.

@rsfernandes 0.14.3 uses brand new connection pool, could you check if it's still an issue there?

@igor-savin-ht I haven't yet stress tested oracle so it might still not be stable in 0.14.4 either at least mssql driver is still pretty unstable.

Hi folks, I have some update to this thread.
The sessions lost by Knex were kept in Oracle as inactive, as Knex could not recycle them.
Now we're using version 0.14.6 with min pool size set to 0 and it seems to be working better, but we're changing to use node-oracledb only.
My problem is related to this issue: https://github.com/tgriesser/knex/issues/2514 so you can close this issue and we continue the conversation there.
Thks


TIMEOUT: build_docker_python in interop tests

https://source.cloud.google.com/results/invocations/298b09ce-1d89-42af-8a7c-0b4fbf977604/log
This has been behind many of the failed interop test that failed recently. We can increase the timeout, but 30mins already seems to be pretty high.
2018-05-24 21:31:16,021 WAITING: ETA 1654.3 sec; 0 queued, 1 jobs running, 1 complete, 0 failed (load 1.00)
2018-05-24 21:31:26,022 WAITING: ETA 1664.3 sec; 0 queued, 1 jobs running, 1 complete, 0 failed (load 1.00)
2018-05-24 14:31:29,283 TIMEOUT: build_docker_python [pid=9395, time=1807.7sec]

CC @mehrdada  @nathanielmanistaatgoogle

This still seems to be happening.  30mins just to build python seems like a lot.

Idea:
It seems that python interop tests are only running under python27,
https://github.com/grpc/grpc/blob/70ce9e21df4f6a18fbcfbb2103d1e89987125f4a/tools/run_tests/run_interop_tests.py#L548
but the build script seems to be building python for both 2.x and 3.x  (that's what the build script does by default).
https://github.com/grpc/grpc/blob/70ce9e21df4f6a18fbcfbb2103d1e89987125f4a/tools/dockerfile/interoptest/grpc_interop_python/build_interop.sh#L31
@mehrdada , as python27 is going away, let's switch python interop tests to 3.x  and make sure interop tests docker image only builds python3.x?

This is still happening in one of CI run yesterday

Oh 11 hours ago... sorry I think the CI was run before that.


[stable/cluster-autoscaler] Add me as owner

What this PR does / why we need it:
Add me as owner.
Which issue this PR fixes

https://github.com/helm/charts/issues/13869

Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

I've asked in Slack how to get added to the GitHub org.

Hello and thanks for stepping up!
Any past contributions to this chart or others?

Yeah, I've made a few contributions to a few different charts: https://github.com/helm/charts/pulls?q=is%3Apr+author%3Ayurrriq

And a few open PRs for this chart: https://github.com/helm/charts/pulls?q=is%3Apr+author%3Ayurrriq+[stable%2Fcluster-autoscaler]

works for me :)
/assign
/ok-to-test

/lgtm

/approve

/approve no-issue

Thanks, @maorfr! I've joined the org. What's the next step?

/auto-cc

/retest

You need to resolve the conflict that will arrive soon :)

heh on it!

I think all my :duck:s are in a row now.

/lgtm

/lgtm
welcome to the party :)

Thanks!


Database contains sensitive information

When searching for the definition of 'sposida' in Elefen-to-English mode, the result is very sensitive information.
https://conlang-corpora.vercel.app/?l1=Elefen&l2=English&selectedCorpusIds=%5B0%5D&search=

Remarkably, what you found there appears to be an excerpt from Cory Doctorow’s 2008 Little Brother.

Grasias, me vide la sinia de sita aora.
(Thank you, I see the quote now.)


doc(readme): remove ES7 bind

It's a bad practice to bind functions into render() which can lead into performances issues.
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-bind.md

I'm aware, but meh, premature optimization


chore(deprecated stuff): replace viewproperties to viewprops, textproperties to textprops, textinputproperties to textinputprops

The type of this PR is: Enhancement

This PR resolves [CX-]
Description
I noticed that ViewProperties, TextProperties and TextInputProperties have been deprecated, so I thought I'll quickly replace them with the new thing, *Props.
Pretty easy change.
(My first PR that I think deserves a chore 😅.)

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have added tests for my changes, or my changes don't require testing, or I have included a link to a separate Jira ticket covering the tests.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a CHANGELOG.yml entry or my changes do not require one.

🚢🚢🚢


ui-br-phone-number shows an error when the model starts with a value

Hi,
I am using the ui-br-phone-number for validating phone numbers in my app and realized that if I previously have a value in the ng-model (set on controller), the ui-br-phone-number reports an error and invalidate my form. If I delete the last number and re-type it, the form turns to valid.

"angular-input-masks": "^2.6.0"
"ionic": "3.6.0"
"type": "ionic1"

Tested on Google Chrome 61.0.3163.100

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

What is the angular version you are using?

Angular Version: 1.5.3
I noticed that, if the ng-model value is set before the view is rendered (in a modal, for instance), the mask works fine. But, if the view is already displayed, and the ng-model is set after some action (like pressing a button), the error is shown and the form is invalid.

Can you write a test case that reproduce this scenario? Check the src/br/phone/br-phone.test.js

I tried to write a test case, but, unfortunately, I am not that good on writing tests for angular (yet), so I was not able to pull request.
However, I discovered the problem in my code: the api that I am using returns a masked phone number, and I was writing vm.form.phone = data.phone (in fact, the $modelValue was invalid). I solved that writing vm.form.phone = data.phone.replace(/\D/g, '') instead.
I don't know if this is the expected behaviour for angular-input-masks, but this is how it is working today.
Thanks for your attention!

No problem.
Yes the intended behavior is to not store the mask in the model, only the pure value.


[AMBARI-24453] Ambari stack hook changes to create HDFS users and groups in workload cluster that has only HDFS client

What changes were proposed in this pull request?
Current logic is to create hdfs users and group on all hosts only when NameNode is installed on a cluster
Patch changes this to create hdfs users and group even when only HDFS client is being managed by ambari .
In a cluster that has hdfs clients but no namenode, hdfs user is expected to be present by other service scripts while copying tarballs to hdfs, service check, setting ownership to hdfs user for some configuration files
How was this patch tested?
Deploying a cluster with only HDFS client component in HDFS service and other services

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3528/
Test FAILed.
Test FAILured.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3573/
Test PASSed.


Error "Namespace required" on new PV claim (cloned deployment)

**Rancher versions:**
rancher/rancher: v2.0.2
Docker version: (docker version,docker info preferred) 17.03.2-ce
Operating system and kernel: (cat /etc/os-release, uname -r preferred)
RancherOS v1.4.0
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO) AWS EC2
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node rancher
Steps to Reproduce:

Configure a default storage class and validate creating volume work nicely.
Create a new deployment with a new volume claim -> this works well.
Clone the deployment.
Change to new namespace (non-existing)
Delete the volume config and add a new one.

Results:
Error: "Namespace is required" pops up on clicking Define.
Workarounds:
This is probably a corner case, since we got at least these three workarounds.

Clone deployment without volume, then edit and add.
Create volume before and select it instead of add on the fly.
Create namespace before.

Version - 2.0 master 7/3
Verified fixed


[BUG] Gradle check retry not working as expected

Describe the bug

As a part of https://github.com/opensearch-project/OpenSearch/issues/2547 and https://github.com/opensearch-project/OpenSearch/pull/2638/, a retry mechanism was introduced to rerun failed tests during gradle check
With the increased flakiness in tests, one issue that was noticed is the retries do not always run for tests on the build server

Sample runs -

https://build.ci.opensearch.org/job/gradle-check/6825/consoleFull
https://build.ci.opensearch.org/job/gradle-check/6782/

To Reproduce

Run gradle check for a PR with a test failure

Expected behavior

Retries to be present within the console output with x tests completed, y failed with y > 1 in case of failed tests with a retry

Plugins

N/A

Screenshots

https://build.ci.opensearch.org/job/gradle-check/6825/consoleFull
https://build.ci.opensearch.org/job/gradle-check/6782/

Host/Environment (please complete the following information):

Jenkins build server for OpenSearch

Additional context

https://github.com/opensearch-project/OpenSearch/issues/2878

Just as an example, from this test run back in April, if we drill into the report we can see 3 failures of the same test:

But it succeeded on the 4 attempt so the overall test run is marked as successful. Not conclusive, but I have never seen an example of a test failing but succeeding on retry since we moved to the public Jenkins runner.

Ok, now I do have an example of a test succeeding after retry from just a few minutes ago: https://build.ci.opensearch.org/job/gradle-check/6876/testReport/org.opensearch.index/ShardIndexingPressureConcurrentExecutionTests/ You can see that the test testCoordinatingPrimaryThreadedUpdateToShardLimitsAndRejections failed twice but succeeded on the third attempt. You can also observe the retries in the console output. (The overall test failed for a different reason causing a test to fail 4 times).

I think this is working as expected. I'm closing this, unless someone can show an example where all retries failed and we still reported success.

reopen if you can show an example where all retries failed and we still reported success

@dblock I think we have the opposite problem. The retries are working, but even when a test succeeds on retry we still fail the overall test run. See here for an example. AwarenessAttributeDecommissionIT.testInvariantsAndLogsOnDecommissionedNodes both failed and succeeded in the same run. Don't we expect the overall test result to be success in such a case?

Again looking at 6825, we see the "BUILD SUCCESSFUL" result in the output (tests succeeded on retry):
BUILD SUCCESSFUL in 25m 35s
2626 actionable tasks: 2612 executed, 2 from cache, 12 up-to-date
...
Finished: UNSTABLE

The gradle check jenkins run completes with the result "UNSTABLE" and results in a failure of the GitHub action. Is this the right behavior? I think the point of the retries is to pass the gradle check when tests pass on retry so this seems wrong to me.

I'll look at other UNSTABLE gradle checks to check if it's the same cause.

I think that if a retry succeeded, the build should be a SUCCESS.

Fix: https://github.com/opensearch-project/opensearch-build/pull/2902


SFML x64-windows-static fails on Windows 10

I have the latest version of vcpkg installed on my Windows 10 PC. I tried installing sfml:x64-windows-static and I get the following error message:
Error: Building package openal-soft:x64-windows-static failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: openal-soft:x64-windows-static
  Vcpkg version: 2019.06.21-nohash

Can't reproduce. Do you have any additional logs?

I tried installing sfml:x64-windows-static but stumbled upon a different error:
C:\Users\n42k\vcpkg>vcpkg install sfml:x64-windows-static
The following packages will be built and installed:
  * bzip2[core]:x64-windows-static
  * freetype[core]:x64-windows-static
  * libflac[core]:x64-windows-static
  * libogg[core]:x64-windows-static
  * libpng[core]:x64-windows-static
  * libvorbis[core]:x64-windows-static
  * openal-soft[core]:x64-windows-static
    sfml[core]:x64-windows-static
  * stb[core]:x64-windows-static
  * zlib[core]:x64-windows-static
Additional packages (*) will be modified to complete this operation.
Starting package 1/10: zlib:x64-windows-static
Building package zlib[core]:x64-windows-static...
CMake Error at scripts/ports.cmake:37 (message):
  Unsupported target triplet.  Triplet file does not exist:

Error: Building package zlib:x64-windows-static failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: zlib:x64-windows-static
  Vcpkg version: 2019.06.21-nohash

I get the same error as you if I install openal-soft:x64-windows-static directly. It seems like dependencies are being installed in a different order.

Hi @n42k, thanks for your feedback! Because VCPKG has been updated, you can run this command .\bootstrap-vcpkg.bat to update VCPKG.

I was able to successfully compile sfml:x64-windows-static after running .\bootstrap-vcpkg.bat. Thank you, I'll take that in mind next time.

That fixed worked for me as well. Thank you @wangli28

Thanks for posting this issue. This issue has been fixed. So I am closing this issue for now.


Support Caddy as a server type

I can help with the implementation or any questions, but I'm not sure where to start

Can't say I'm familiar with Caddy. First thing would be an overview of what we'd be dealing with/looking at.

https://caddyserver.com/
Works similarly to nginx, but has a ton of unique features not available (without extensions) in nginx like automatic SSL (gets an SSL cert from Let's Encrypt on the fly on server startup), etc.
A simple Caddyfile for a PHP site is (usually) as simple as:
https://{{hostname}} {
    root /var/www/web
    fastcgi / <IP_ADDRESS>:9000 php
    rewrite {
        to {path} {path}/ /index.php?{query}
    }
}

Uses php-fpm with the fastcgi Caddyfile directive, so you can reuse all the stuff you have to run PHP with apache/nginx.

The automatic HTTPS bit will probably cause issues with Nanobox, actually, but we can explicitly disable that pretty simply in the config template we would create for this. In production, SSL is terminated at the load balancer, not the web server, so Caddy wouldn't ever actually see a request to 443.
What else sets it apart if we disable the auto SSL? I think we can definitely add it to our list of things to support, but it would be nice to be able to give users some guidance on when to use which server, and what restrictions the Nanobox design will place on the actual features they'll be able to take advantage of.

Check https://caddyserver.com/features for a pretty comprehensive list.
Caddy can be used as a load balancer itself, which can terminate SSL and automatically renew, if that would work in the stack.
Disclaimer: I don't actually use nanobox, just saw it via Hacktoberfest and thought I'd bring this up as a potential addition because Caddy is feeling like the #3 webserver these days. I use it in most of my projects because of its ease of use and features that simplify lots of the usually complicated server tasks (e.g. SSL).

It certainly looks nice. We use Go in a lot of our own stack, in fact, including for the CLI client. Our load balancer/SSL terminator/router is kernel-level, IIRC, and configured on the fly via API, so it's very fast and handles changes in app infrastructure very cleanly on the fly. So I don't think we'd want to switch to it for our purposes.
That said, it certainly looks like something to support for app-level use! Thanks for bringing it up!


Change to Jenkins file to add hipclang testing

Closing all existing pull requests that do not target the develop branch. In case this pull request is still valid, please rebase your changes against develop branch and resubmit.


SearchShowAsync bugfix

Hi,
I found a bug with the SearchShowAsync method where the referred class was ShowDetails instead of SearchResult.
I should have fixed it, so I was hoping to be helpful and ask for a pull request :)
Thank you and have a nice day,
Mordas.

hey!
thank you for the fix!


%(RelativeDir) Clarification

%(RelativeDir) includes %(RootDir) if Include is full path.
For example:
<ItemGroup>
    <MyItem Include="C:\MyProject\Source\Program.cs" />
</ItemGroup>

%(RelativeDir) is "C:\MyProject\Source"

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 62db4b12-8d5d-6a33-b5f6-b3f7320dd3f8
Version Independent ID: 19ee6154-2eb2-b6a0-ab2e-96de2cfc05b2
Content: MSBuild Well-known Item Metadata - Visual Studio
Content Source: docs/msbuild/msbuild-well-known-item-metadata.md
Product: visual-studio-windows
Technology: msbuild
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@Mikejo5000 -- Mike, please review the above-mentioned PR 5943.


⚠ Bofrost.fr has degraded performance

In 42726af, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1642 ms

Resolved: Bofrost.fr performance has improved in 84967b0.


Use defaultdict instead of manual dict manpulation

Drops lines, also slightly faster.

Thanks for using OSMnx, and thanks for offering this contribution. Note the tests are not passing
Looking through it, I'm not sure yet if we'll merge it in. In my testing it looks like the speed-up is negligible and I feel like the code is less readable. defaultdict may be a useful language feature here for terse code and a small performance increase but I want to make sure the simplification algorithm remains as readable as can be (without meaningfully impacting performance).


Problem with FindProtobuf

Hi,
CMake gives me an error when I try to compile MXNet using ps-lite, as the Protobuf libraries are not exported to PARENT. I think I tracked the problem and it should be in these lines.
Basically, FindProtobuf exports PROTOBUF_LIBRARY (see here), whereas the lines look for Protobuf_LIBRARY. Is anyone else having a similar problem?

So, it seems a problem with the FindProtobuf module, which changed the name of the variable after CMake version 3.6.

cmake was improved in (#170)

@al-rigazzi I didn't check if #170 addressed this particular issue. Please report if you still face this issue and we can reopen.


Ligatures?

I do not expect this anytime soon, but I want to put it out there : ligatures.  Italics & Bold will be great, but I’d rather have fresh ligatures to use in my agave code in the future!
Also, thank you for creating this font.  It Oozes unusual monospace beauty & helps your eyes over lengths of time.  ✨🌵

Hi, thank you very much for using agave and for your feedback.
I will definitely consider ligatures as they sound interesting for agave, but I have yet to come up with a roadmap for future development. Most likely, I will take a path-of-least-resistance approach to adding more features, and ligatures do seem like good candidates. I will do some more research.
And just wondering, what kind of ligatures do you use most often? I'm guessing arrows, conjunctives, that sort of thing?

Yes, for all of the math operators, arrows & conjunctives relative to coding.
I became obsessed with finding the right "daily driver" coding font.
Agave has become that font for me, and adding ligatures would basically add superglue to my font selection in RubyMine!!! lol
I also love the illusory effect between large and small sizes, how the movement of the font comes alive at smaller sizes! its so cool!

It excites me immensely to hear that agave is being used as a fellow programmer's daily driver. That is, quite honestly, more than I had hoped for when first making the font. Thanks. I will look into ligatures and hopefully come up with designs that preserve agave's quirkiness.

Agave brings my code to life.  It's quirkiness is its power in parsing syntax line by line. Can't wait to see the future progress in regard.

I took a brief look at "ligatures for coding" and I must say my opinions on adding them are negative.
Sure, the actual implementation does not seem all that difficult, but I have trouble weighing the advantages against the potential disadvantages. So unless I am persuaded otherwise, I will have to decline adding coding-ligatures to agave. (Please note, however, that I have little experience using ligatures in a programming context.)
These are my reasons (in no particular order):

There is no coding-ligature standard.

Example: What would be the reason for providing a ligature for === as opposed to some other combination? Because JavaScript is popular? Where do I draw the line, and how would I "rank" particular combinations of symbols?

I realise this line of reasoning can extend to arbitrary, even metaphysical, considerations. But what adding ligatures does is add yet one more level of uncertainty and doubt.

Adds semantic complexity.

Example: tonsky / FiraCode / issues 751 and 92.
Example: You want to use a bunch of =s to decorate a block of comments, but without ligatures. Simultaneously, you want to use == ligatures in normal conditional statements. What do?

Granted, this stems more from a lack of experience with ligatures than from a reason against adding them to agave. But still, similar considerations will have to figure into the design.

Adds logistical complexity (possibly following from previous point).

Would have to supply numerous variants. For example, a variant with <= for C and another with =< for Prolog (bad example, I know). Or at least some convenient way of building user-specific variants.

Against the original design idea of agave.

I am hopelessly conservative when it comes to agave's "retro-inspired" design. And I must admit that coding-ligatures just do not evoke that regularity and simplicity we love so much in classic terminal fonts. For instance, I doubt ligatures would get supported in pure virtual console environments (not that outline fonts would either). But when they do, I will definitely reconsider this issue :-)
Ease of programming was part of the intention behind agave's design. At the risk of sounding like an ignorant fool, I think fonts without ligatures still have very high "programmability".

A blog post makes some more complaints against the use of coding-ligatures: https://news.ycombinator.com/item?id=19805053 . Not sure if I agree with everything there, but a few points do make a lot of sense.
In conclusion, I thought I would like the idea of adding ligatures, but further investigation has proven otherwise, and I hope the above reasoning has been clear. I also don't mean to come across as attacking the use of ligatures. I simply don't think they are a warranted feature for agave, especially given the font's design idea and extent of manpower. However, I am still open to persuasion.
Thanks for understanding.

Putting aside that Agave is already a super cool looking font, part of my attraction to your design is your implementation parameters of the glyphs ie Power of 2, the golden ratio.  Applying these design parameters seems to add the mysterious, flowing effect Agave seems to produce.
In many ways, your considerations & then rejection of ligatures further reinforces why I dig Agave so much.  To me, the main draw of enabling ligatures with a font is to make the Math & Block expressions flow a bit easier on the page.  They also tend to decrease, say, ES6 linter issues when dropped into a large codebase. But your considerations are very clear on what could quickly spoil what makes Agave so great.
I am of the same mind that the adherence to the spiritual design of Agave is the correct path forward, whether that includes ligatures in the future or not. Ligatures do tend to be divisive, as do Italics, and could add semantic complexity to an already great design.
There are certain languages that rely on the implementation of ligatures much more than others ie Haskell, Clojure etc (primarily functional programming languages).  But obviously these are niche cases & hard to justify in a larger scope of a coding font lifecycle.

Despite not having used ligatures for coding, I can sense the appeal, and the general demand for them is obvious (FiraCode has almost 10x as many github stars as FiraMono -- holy moly).
To me, the best method of adding ligatures to agave would be as an optional feature or a fork. But I hesitate to lead in such a development unless I find more time and/or see demand from more users. And as for the "core" agave, I must stand by my last comment.
In the meantime, I would like to further investigate the "flow of math & block expressions" that you mention. I did make an effort to adhere to metric uniformity with regards to math symbols and brackets, etc. in the ASCII plane, but if there is room for improvement there, even without the use of ligatures, I would be more than willing to implement it.
In any case, your feedback and remarks are very helpful, so thanks again.

I found your font in the following link, a test drive site for a majority of the programming fonts used :
http://app.programmingfonts.org
Agave stands out right away, with perhaps a bit of spiritual genealogy to Fantasque Mono & DaddyTime Mono(the latter having Exceptionally oversized operators & brackets!).
You will notice very few of them possess ligatures, and the ones that do usually pair them equally with italics / cursive italics.  So there is a sound argument that ligatures are at best Optional parameters to tack on depending on project use.
If I can aid in any kind of problem solving for your project in any way (also for the Ino typeface), let me know - I'm a major major typeface nerd (with major affection for Susan Kare's work in the 80s)

Also, something I was thinking about - a what if...
What happens to Agave when using the Silver Ratio for traits?
Would the results be different enough to yield a sister font?
Would it yield a "softer" agave?
Food for thought indeed!

That's pretty interesting. Actually, part of the reason I want to make ino is to parameterise metrics such as these, using metapost (thank you Knuth!). But research/development on that front has so far been embarrassingly slow.
Applying the silver ratio to agave, as it is now, my guess is that things will look just a bit stubbier/boxier (0.618 vs. 0.707 = 1/sqrt(2)). I also get the feeling that agave looks satisfactory right now only because of the peculiarity (read: divinity) of the golden ratio. I think any other ratio will make things slightly wonkier. Well, actually, who knows.
Thank you for sharing that page. It's awesome.
As for help with development, I can't think of anything specific right now, but of course you're free to fork agave and try adding ligatures to it or modify it as you wish. I could maybe give a few pointers in terms of design if you're interested. But to be honest, I am a complete amateur in type design and the scheme I followed is incredibly naive, as you may have gathered from the website. Oh, if you are familiar with using metapost, I would appreciate any info.

There are a million monospace fonts we could use to program.  Hell, Susan Kare's original Monaco for the mac is still great to use.
Agave is truly different, I believe that.  I TRIED going back to my other daily drivers.
I can't, Agave is too cool and useful! lol
Doing a silver ratio edition of Agave may be interesting as a side project, I will consider what I could do to make that achievable.  I'm looking over Metapost now and I will give insight if I can on what you may or may not know.

I noticed this project that combines agave with fira code ligatures: https://github.com/pavel/agave-code

As I most likely won't be implementing ligatures for this font, I'll close this thread.


Review crypto future01

submit PR trial

submit PR trial

what is this???
created PR on GitHub!!
I don't think anything happen.


Implemented tags

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 3 committers have signed the CLA.:x: renemadsen:x: Gid733:x: Roomey12You have signed the CLA already but the status is still pending? Let us recheck it.


Remove future library from project.

Description

Remove future library and references from the code base.
GitHub Issues

https://github.com/Miserlou/Zappa/issues/1966

Coverage decreased (-0.02%) to 72.951% when pulling<PHONE_NUMBER>1c19abf6e2259de2d0fd619c08aba1 on RyanDale:remove-future into 80a6881f0ec0be525a8fd7835b5a1157f9e66100 on Miserlou:master.


Convert codebase to TypeScript

[ ] figure out the canonical way to publish packages written in TypeScript to npm so people can use them without caring
[ ] integrate whatever that process is with release-it

@mdmower almost done; need to figure out how to do mixins (or give up on mixing in those functions, that's probably easier) https://github.com/beaugunderson/ip-address/pull/113


fix footnote reference

Tweak to api docs to make the ltv footnote reference work with a fragment identifier.

Coverage remained the same at 99.794% when pulling 678c30b1b0d6c008e3d319326f8d55358a1b458b on fix-docs into ce0e95599b435bad326684feea90b631483c17eb on master.


Fix typing file

Two changes in the typings file:

Fixed the type of log method in PoolConfig interface
Removed create, destroy and validate methods from PoolConfig interface, because Knex is overriding these methods, and any user provided implementations of these methods are being ignored. Having these methods in the typings file will only confuse users.

Can someone please review this? CC: @elhigu

I think that at least validate should be able to be overridden by the user. But I believe that the best way to implement pool config typings would be to somehow inherit/extend it from tarn's config type and add javascript level errors, when trying to override create/destroy. I'm not completely sure if even overriding those must be denied if the one providing new implementations knows what they are doing 🤔

@elhigu Knex seems to ignore any user provided implementation of validate/create/destroy, and pass its own implementation of these methods to tarn. I was just trying to update the typings file to express this intent accurately. Do you want me to change Knex's behavior and allow users to override those methods?

Do you want me to change Knex's behavior and allow users to override those methods?

No need to change the current implementation. If some one starts requesting it it will be easy to improve afterwards.

@elhigu In that case, this PR should be ready to be approved and merged?

Retriggered tests... for some reason there was no button visible in travis to retry those.

Released in 0.20.2


SIGTERM is not stopping program during node startup

During runNode if we have long running operation, such as replaying from storage, node cannot be stopped with SIGTERM.
When a node lost state.db, it starts replaying blocks from storage. During this, Ctrl + C is not handled properly and node cannot be stopped. Main cause is, replaying starts during ctor of the node, thus listeners.node cannot be assigned and is null. Following check fails to stop the node.
https://github.com/bosagora/agora/blob/dd2491c711296fcb561ec5b90900a7a3c7c194d1/source/agora/node/main.d#L245

Updated issue details, since its not just related with block replaying but during runNode in general.

Related with #3158


"broken invariant in parsetree: Explicit universal type quantification cannot be empty" with OCaml 5.3

While compiling the following interface file with OCaml 5.3 and only ppx_deriving_yojson:
https://framagit.org/zoggy/ojs-base/-/blob/3067edd2bf7f67f52b09dfb5a7b8914ada8d28f2/lib/types.mli
the following error message appears:
$ (cd _build/default && /home/kit_ty_kate/.opam/5.3/bin/ocamlc.opt -g -w @1..3@5..28@30..39@43@46..47<EMAIL_ADDRESS>-strict-sequence -strict-formats -short-paths -keep-locs -bin-annot -w -6-7-9-10-27-32-33-34-35-36-39-50-52 -no-strict-sequence -g -bin-annot -bin-annot-occurrences -I lib/.ojs_base.objs/byte -I /home/kit_ty_kate/.opam/5.3/lib/lwt -I /home/kit_ty_kate/.opam/5.3/lib/ppx_deriving/runtime -I /home/kit_ty_kate/.opam/5.3/lib/ppx_deriving_yojson/runtime -I /home/kit_ty_kate/.opam/5.3/lib/seq -I /home/kit_ty_kate/.opam/5.3/lib/yojson -no-alias-deps -opaque -open Ojs_base -o lib/.ojs_base.objs/byte/ojs_base__Types.cmi -c -intf lib/types.pp.mli)
File "_none_", line 1:
Error: broken invariant in parsetree: Explicit universal type quantification cannot be empty.

This issue doesn't appear with OCaml 5.2

Thanks for reporting this! I'll try to reproduce it and prepare a fix.

Yes, the compiler started to enforce this invariant in 5.3 because using empty Ptyp_poly could lead to undecipherable error in random part of the typechecker.


[SPARK-17167] [2.0] [SQL] Issue Exceptions when Analyze Table on In-Memory Cataloged Tables

What changes were proposed in this pull request?
Currently, Analyze Table is only used for Hive-serde tables. We should issue exceptions in all the other cases. When the tables are data source tables, we issued an exception. However, when tables are In-Memory Cataloged tables, we do not issue any exception.
This PR is to issue an exception when the tables are in-memory cataloged. For example,
CREATE TABLE tbl(a INT, b INT) USING parquet

tbl is a SimpleCatalogRelation when the hive support is not enabled.
How was this patch tested?
Added two test cases. One of them is just to improve the test coverage when the analyzed table is data source tables.

cc @hvanhovell

Test build #64333 has started for PR 14781 at commit 77666fd.

Test build #64333 has finished for PR 14781 at commit 77666fd.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/64333/
Test PASSed.

LGTM - merging to branch-2.0. Thanks.

@gatorsmile I have merged this PR. The merge script can only close PRs that are targeted at master. Can you close it?


Feature/minor updates

In this branch

Updated readme file
Updated itemCount function to an arrow function

Great job on these implementations!

no linter errors ✔
Nice Readme ✔
Good use of Git flow ✔

Ready to merge!!!


Sync with ECMWF develop

Merge ecmwf::atlas/develop into jcsda::atlas/develop
jcsda::atlas/develop is 8 month's stale.

Looks like the Travis CI builds are failing because doxygen and dot are not found.
Any idea how to fix these?
The branch builds on my macOS with GNU compiler set.

Thanks @aerorahul  - I tested this on AWS and it seems to be fine with fv3-bundle.

we can wait another day for @danholdaway and @benjaminmenetrier to comment before merging.

I agree that we need to discuss how we manage our forks.  Maybe we could keep our local feature branches but we should make PRs from those branches to upstream and only change our develop through synching with upstream.
Our containers have both doxygen and dot but these are not our containers.  It looks like ENABLE_DOCS is now on by default

Looks like @wdeconinck just pushed a doxygen fix

The issue with doing a straight develop to develop merge is that if it breaks some model we wont know until it's merged and develop starts failing and you have no way of triggering code build. But so long as you've tested with fv3-jedi somehow/somewhere I'm happy to merge. But would stress that Travis CI passing here is insufficient for assessing the impact of merging from upstream. At the beginning of the code sprint last month none of our models worked with ECMWF develop due to a bug not picked up by Travis.

The issue with doing a straight develop to develop merge is that if it breaks some model we wont know until it's merged and develop starts failing and you have no way of triggering code build. But so long as you've tested with fv3-jedi somehow/somewhere I'm happy to merge. But would stress that Travis CI passing here is insufficient for assessing the impact of merging from upstream. At the beginning of the code sprint last month none of our models worked with ECMWF develop due to a bug not picked up by Travis.

The JCSDA fork is 8 months stale.  If anyone has been using the JCSDA develop, there is no guarantee things won't break.  As @ytremolet suggested, we need a way of syncing our forks timely (and possibly automatically) with upstream develop; whilst maintaining a jcsda-develop that is closely maintained with upstream.  Aren't there bots for this kind of stuff?

I also definitely agree that you should not rely on the upstream develop branch for any model. Especially for upstream packages you would ideally rely on tagged versions. I understand that if you have features you want to develop, you can do so, but then most reliably do so from a known working tagged version. Then merge (or preferably rebase) with latest upstream develop for submitting PR upstream.
ECMWF's IFS is e.g. never using a "develop" branch. Not saying you should, but we do "synchronised (tagged) releases" of all libraries with (hopefully) thorough (unit) testing on various platforms, and use these tagged versions for IFS. Probably more tricky for you as you have multiple sites and models to deal with.

Our containers have both doxygen and dot but these are not our containers. It looks like ENABLE_DOCS is now on by default

Even though for Atlas the ENABLE_DOCS should be OFF by default, for eckit it is not, and in a bundle that would then change the default for ENABLE_DOCS (but not a hard requirement).
I also had some failing CI on our end, but due to a "REQUIRED" keyword in the find_package( LATEX ) that was merged in latest PR. It is now fixed. (so please reintegrate).

Our containers have both doxygen and dot but these are not our containers. It looks like ENABLE_DOCS is now on by default

Even though for Atlas the ENABLE_DOCS should be OFF by default, for eckit it is not, and in a bundle that would then change the default for ENABLE_DOCS (but not a hard requirement).
I also had some failing CI on our end, but due to a "REQUIRED" keyword in the find_package( LATEX ) that was merged in latest PR. It is now fixed. (so please reintegrate).

@wdeconinck If ENABLE_DOCS is turned ON, then isn't LATEX required to build the pdf documentation?   If not, then CONDITION LATEX_FOUND is irrelevant to build the (partial) documentation.
I suppose one can just build doxygen documentation.  One can wrap all different kinds of these documentation builders in their respective <PACKAGE_FOUND> if statements.
A job for another time, perhaps!

last call!
merging develop-ecmwf -> develop at Noon EDT.

Ok - it can be part of the mini virtual code sprint today - fixing all potential merge problems at once!

Our containers have both doxygen and dot but these are not our containers. It looks like ENABLE_DOCS is now on by default

Even though for Atlas the ENABLE_DOCS should be OFF by default, for eckit it is not, and in a bundle that would then change the default for ENABLE_DOCS (but not a hard requirement).
I also had some failing CI on our end, but due to a "REQUIRED" keyword in the find_package( LATEX ) that was merged in latest PR. It is now fixed. (so please reintegrate).

@wdeconinck If ENABLE_DOCS is turned ON, then isn't LATEX required to build the pdf documentation? If not, then CONDITION LATEX_FOUND is irrelevant to build the (partial) documentation.
I suppose one can just build doxygen documentation. One can wrap all different kinds of these documentation builders in their respective <PACKAGE_FOUND> if statements.
A job for another time, perhaps!

I am working on another repository "atlas-docs" (not yet in Github, very much a work in progress) where I generate the documentation to be hosted here:
https://sites.ecmwf.int/docs/atlas/
In the end both the LATEX and Doxygen will then be removed from the atlas repo.
Regardless, I was also surprised, but it seems that  "ENABLE_DOCS=ON" can also be the case without it being turned on explicitly from the command-line. This is when another previous package in the bundle entered a ecbuild_add_option( DOCS ... ) with the default "ON".
There's a ENABLE_DOCS CMake option being set to ON, for GUI purposes, which can be overridden by command-line.
In my tests ( and in the general case ) we were not explicitly setting "ENABLE_DOCS=OFF" so it was hence going into this case where "REQUIRED" was used, even if we did not explicitly turned it ON.


Custom Sprite For iii Missile

Haha time to break the Geneva Convention

Haha time to break the Geneva Convention


Consolebot - Convo not working

Hi guys,
I'm trying to make run a simple convo from your examples with the lib/consolebot but it fails to reply to me on the convo.say
The convo.ask after the startConversation runs well, the callback is well fired, but nothing happens on the say triggering the next reply.
Any idea ?
Alex

Actually, i've found the issue.
You forgot to call the callback on the worker.send method :
bot.send = function(message, cb) {
     cb() // was missing to complete the sending in core.js
     console.log('BOT:', message.text);
};

Would you mind submitting a PR to fix the example?


Fix pile dataset download config

What does this PR do?
Fixes # (issue)
Before submitting

[x] Did you read the contributor guideline?

Refer to the Pile dataset discussion.
The Pile dataset originally hosted on Hugging Face is no longer downloadable.
To address this issue, the original dataset configuration has been switched to an alternative dataset.
Now, the Pile dataset can be downloaded normally.

LGTM!


Fix my listing as maintainer

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@douglowe Something went wrong when you added me as a maintainer, probably because you used origin/master directly instead of a fork and pull-request, resulting in me not being listed in the README.md and codeowners file. This PR addresses this.

Thanks for the correction - I'll merge it now.

Thanks!


Move T-12 QA tasks to T-8

@lindalumitchell mentioned that the T-12 tasks aren't really done until T-8, so have moved them in the checklist

Thanks, @jasonblais! Was just now thinking I should put in a PR for this. Appreciate you remembering and taking care of it.


[WIP] Alert on uploads that take more than 3 hours

Description
This will help us react to user uploads that stall because their connection fails or other unknown causes. The resque job will be enqueued in 3 hours plus one minute after creation of a sample.
Notes
Please check the logic of the check. I'm not 100% sure that it is what we want. For example, are there valid cases where a user will create a sample, then wait to begin uploading?
Also, I'm not sure how reliable client_updated_at because I only saw around 300 of them in samples in prod database.
Tests
TBD

Seems like this overlaps with this issue: https://jira.czi.team/secure/RapidBoard.jspa?rapidView=12&view=planning&selectedIssue=IDSEQ-1191&quickFilter=41&issueLimit=100
client_updated_at is updated whenever the user's browser calls a "upload heartbeat" endpoint for local sample uploads. This was lost during the new sample upload, and we need to add it back. Maybe it makes sense to look at client_updated_at instead of created_at, once we add it back?
Also, should we set the sample to "Failed" after a certain point? Down the line, we can even give the user an option to re-upload their files.

^ Actually the client_updated_at was added in April but it seems to have been broken between then and now :|

@cdebourcy:

We mustn’t overload the resque tier by adding 1 job for every single sample even though most of them are going to be no-ops.

Instead, you should make it a demon that just lists Sample.where(status: Sample::STATUS_CREATED).where("created_at < ?", Time.now - 3.hours) periodically. That will be much more efficient.

You can piggyback on the pipeline_monitor code (https://github.com/chanzuckerberg/idseq-web/blob/master/lib/tasks/pipeline_monitor.rake),

Will do. I'll add a comment following @tfcarvalho's point.

Time.current will not be consistent with the created_at column here. You should use Time.now.

Good catch! But what about all the other instances of Time.current, as in PipelineRun:
def run_time
  Time.current - created_at
end

@markzhang @jsheu

Maybe it makes sense to look at client_updated_at instead of created_at, once we add it back?

Thanks for the extra context. However, I don't think we should use client_updated_at for the alert because 1) the client may not update at all, 2) the CLI does not set client_updated_at
Also, should we set the sample to "Failed" after a certain point? Down the line, we can even give the user an option to re-upload their files.

Actually the client_updated_at was added in April but it seems to have been broken between then and now :|

Is this tracked anywhere? It seems like it would be worth fixing.

run_time

Thanks for catching that! Looks like runtime is only used in admin-facing pages, not user-facing ones (phew), but we should fix it! Thanks!

@cdebourcy I piggybacked on the result monitor code instead of pipeline monitor because the code was simpler and it has a min sleep_quantum of 5 seconds, which seems appropriate.

See new PR https://github.com/chanzuckerberg/idseq-web/pull/2450

@cdebourcy I piggybacked on the result monitor code instead of pipeline monitor because the code was simpler and it has a min sleep_quantum of 5 seconds, which seems appropriate.

Thanks for making the change! One more question:
Is it going to keep sending alerts for the same sample every 5 seconds? Should we bundle this change with the "upload failed" status update, so that we can stop sending more alerts after the status is changed to "upload failed"? Of course, in that case the time-out needs to be longer than 3 hours (some users do report letting uploads run overnight)...
If you did want to do this alert in the pipeline_monitor -- which seems conceptually more logical to me, but opinions can differ -- I believe this would be the place to put it: https://github.com/chanzuckerberg/idseq-web/blob/220ac23c8863b09af1a2985646df1e6a88e97c5e/lib/tasks/pipeline_monitor.rake#L306

Oh I see this PR is superseded by a new one.

Rubocop says:

lib/tasks/result_monitor.rake:56:8: C: Avoid using update_all because it skips validations.

😂


Particles pushed on top of each other at moving boundaries

In the current setup with two walls and a floor, at both corners when the walls move towards one another, particles that used to inhabit that space are naturally pushed with them. However, this may happen to land them directly on top of another particle. The two will now stay glued together for the rest of time, acting as particularly dense, with other particles staying far away and being violently repelled otherwise.
To address this, we just need to make the particles strongly repel each other at these close distances. One potential thing we can do is add a near-pressure term (as described in this paper). Which may also help other aspects of the simulation.
Another thing we might have to do is notice that this stacking is only happening because the particles are stuck on the plane of the floor, without any conception of the y-axis. If so, we might want to artificially introduce a bit of random movement, that's visually imperceptable but introduces some numeric instability to bump things back into the y-axis.

1.6.0 Addresses this somewhat by adding a small random change to W in GPUC3 if the distance between two particles is sufficiently small, which should give them different updates and seperate them. This does partly work, however particles can still remain stacked for periods of time before actually seperating.


Centralized Logging

Whether LogStash/Elk or something RHQ/Hawkular-based.

I guess this boils down to a custom log adapter within the WF logging subsystem? That's probably something @jamezp can comment on.

WildFly can send logs anywhere really. FWIW I did just do a blog post about sending WildFly logs to logstash. http://wildfly.org/news/2015/07/25/Wildfly-And-ELK/

Yep, was planning on using the information in your blog to create a logstash fraction! ;-)

To have your application log to logstash:

Add dependency to wildfly-swarm-logstash
Configure the LogstashFraction inside your Main class, by specifying the hostname and port of the logstash server:

Container container = new Container();
container.fraction(new LogstashFraction().hostname("localhost").port("8000"));

By default, the LogstashFraction will create a piece of metadata in the message to logstash with a key of wildflySwarmNode and value of ${jboss.node.name}. The value will default to the hostname of the machine, but can be overridden by specifying -Djboss.node.name=[name] on the command line when starting the self executable.
You can also override the key name and value being passed to logstash in the LogstashFraction constructor:
container.fraction(new LogstashFraction("metadataKey", "metadataValue").hostname("localhost").port("8000"));

You can also set as many metadata elements on the message as you desire:
new LogstasFraction()
  .metadata("key1", "value1")
  .metadata("key2", "value2");

That's awesome Ken! Well done.

+1

Addendum:
You can configure it manually, by addding new Fraction().hostname("...").port(...)
or you can avoid explicit compile-time configuration by running your app with:
-Dswarm.logstash.hostname=...
-Dswarm.logstash.port=...

If both are not set, there is no default Logstash configuration.  If both properties are set, logstash will be configured and added to your container (assuming you have the wildfly-swarm-logstash dependency).

It would be fantastic if it was possible to do the same with Splunk. A SplunkFraction  :)

That should be fairly straight-forward if you wanted to adapt the Logstash fraction and contribute it.
--
Sent from my iPhone

On Jul 30, 2015, at 12:52 PM, thomas andersen<EMAIL_ADDRESS>wrote:
It would be fantastic if it was possible to do the same with Splunk. A SplunkFraction :)
—
Reply to this email directly or view it on GitHub.

On holiday, but will give it a shot :)


fix: added logging if available check fails

What

to help debug situations where the available check is failing, we want to log the error produced by the status check instead of just emitting "failure" status

lol first prize for the strangest commit ever :-)

It's not so strange @wincus ... it's just indented a lot... did you scroll horizontally all the way over? lol
Github insists on showing tabs as 8 spaces 😖

ahhhh I see it now 👊

Looks Good! 👍


OAuth2: Sample verification_uri is wrong

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps
What part(s) of the article would you like to see updated?
Under Step 1: App requests the device and user verification codes from GitHub there is a sample response:

device_code=3584d83530557fdd1f46af8289938c8ef79f9dc5&expires_in=900&interval=5&user_code=WDJB-MJHT&verification_uri=https%3A%2F%github.com%2Flogin%2Fdevice

The verification_uri value here is https%3A%2F%github.com%2Flogin%2Fdevice, which unescapes to https:/%github.com/login/device. This is not a valid URL.
Additional information
No response

@yaakov-h Thanks so much for opening a PR! I'll get this triaged for review ✨

@yaakov-h Thank you for opening an issue and linking it to your PR! ✨


ceskatelevize.cz: No video formats found

Checklist

[x] I'm reporting a broken site support
[x] I've verified that I'm running youtube-dl version 2020.01.01
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar issues including closed ones

Verbose log
$ youtube-dl -v 'https://www.ceskatelevize.cz/porady/11473805409-buster-keaton-genius-ktereho-znicil-hollywood/'
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://www.ceskatelevize.cz/porady/11473805409-buster-keaton-genius-ktereho-znicil-hollywood/']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2020.01.01
[debug] Python version 3.6.9 (CPython) - Linux-4.15.0-74-generic-x86_64-with-Ubuntu-18.04-bionic
[debug] exe versions: ffmpeg 3.4.6, ffprobe 3.4.6
[debug] Proxy map: {}
[CeskaTelevizePorady]<PHONE_NUMBER>9-buster-keaton-genius-ktereho-znicil-hollywood: Downloading webpage
[CeskaTelevize] iFramePlayer.php: Downloading webpage
[CeskaTelevize] iFramePlayer.php: Downloading JSON metadata
[CeskaTelevize] iFramePlayer.php: Downloading JSON metadata
[CeskaTelevize] iFramePlayer.php: Downloading JSON metadata
[CeskaTelevize] iFramePlayer.php: Downloading JSON metadata
ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/home/ikar/.local/lib/python3.6/site-packages/youtube_dl/YoutubeDL.py", line 796, in extract_info
    ie_result = ie.extract(url)
  File "/home/ikar/.local/lib/python3.6/site-packages/youtube_dl/extractor/common.py", line 530, in extract
    ie_result = self._real_extract(url)
  File "/home/ikar/.local/lib/python3.6/site-packages/youtube_dl/extractor/ceskatelevize.py", line 201, in _real_extract
    self._sort_formats(e['formats'])
  File "/home/ikar/.local/lib/python3.6/site-packages/youtube_dl/extractor/common.py", line 1327, in _sort_formats
    raise ExtractorError('No video formats found')
youtube_dl.utils.ExtractorError: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Description
The download of video from ceskatelevize.cz does not work anymore. The URL:
https://www.ceskatelevize.cz/porady/11473805409-buster-keaton-genius-ktereho-znicil-hollywood/
...is playable in browser but not downloadable.

Hey @remitamine, I see you added DRM label -> does this mean it won't be implemented? Or is there any workaround? Any related issue?

There is no plan to support DRM protected videos.


android: added logs to callback functions

Implements all the callback functions and adds logs to it.

@francesca64 I have implemented the callback functions in Kotlin and added logs to it, you can use this for Android connlib updates.

Just needs approval from @conectado and @francesca64