Update linting rules to catch a range of Python issues

What is the context of this PR?
This PR adds extra linting rules to our CI setup to help us catch common errors or causes of bugs in the way in which we write python code.  It is influenced by some of the approaches taken by Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1237977
How to review

Check out the branch
Run pip install -r requirement.txt to install new flake8 plugins
Run ./scripts/run_tests.sh to execute the Flake8 code linting
Check that they all pass.

[ ] Do all commits have sensible commit messages?
[ ] Is all new code unit tested?
[ ] Are there integration tests if needed?
[ ] Is there sufficient logging?
[ ] Is there documentation or is the code self-describing?

Who worked on the PR
@dhilton

Looks good - can we just rebase and amend the commit messages and then this is ready to go?

After discussions, let's merge #362 and @LJBabbage 's work first then rebase and fix issues with those code changes.

That template preprocessor file shouldn't be in this commit, it was deleted earlier this week. Sounds like a git rebase issue.

Please can we squash and tidy up the commits?

LGTM 👍


the deck list should only be available to the creator of the tournaments and after it finished

probably i'll not do this at the use-cases at the DDD part of the project.
I think that i can do at the Adapter part... I think...


How to count symbolic links and windows shortcuts?

Example with symbolic link

Example with Windows shortcut

Should I pay attention to such files or count them on a par with others?
Originally posted by @NataliaBondarenko in https://github.com/victordomingos/Count-files/issues/84#issuecomment-421604292

yes, they are treated as files.

Let's keep it this way, so. Unless we have a good reason to change, I think it works as expected as we have it.


Vulnerabilities in calico

Expected Behavior

Current Behavior

During Trivy image scanner, calico node:v3.20.0 & pod2daemon-flexvol:v3.20.0 version has contains the High vulnerability severity also attached screen shot for same.

I have followed the Installation Calico  guide on Amazon EKS Linux nodes using manifests file also mentioned document below.
https://docs.aws.amazon.com/eks/latest/userguide/calico.html
Please suggest as which version suitable for production environment.
Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Calico version : NIL
Orchestrator version  AWS EKS
Operating System and version: 1.21
Link to your project (optional):

These are likely vulnerabilities in Golang not core Calico.
For us the official tigera image for v3.22.1 reported 0 vulnerabilities / CVE's and the Golang binary it came with was 1.17.8 which fixed a bunch of the CVE's.
FYI - i'm not a maintainer or contributor to Calico, just a user.

Was going to say the same - you should probably upgrade. The versions you're using aren't the latest patch release in that stream.

@caseydavenport Thanks for your prompt response.
please let me know once patch version has released.

@raj13aug v3.20.5 is out that has been built with the v1.17.8 golang version :+1:

Hi @caseydavenport,
Even latest version(v3.20.5) of node image contain the vulnerabilities also attached screen shot for same.

Regards,
Nataraj.R

@raj13aug that looks like an improvement over the original screen grab which had 58 fixable (now down to 16).
I'm afraid I can't do anything more without information about the exact CVEs that you're seeing - we already bumped the golang version and recompiled the binaries. Could you share the precise CVE numbers and descriptions that are being reported?

Hello @caseydavenport
Thanks for your support and cooperation as always.
I pasted the CVE number for your reference.
CVE-2019-9893Criticalgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: libseccomp before 2.4.0 did not correctly generate 64-bit syscall argument comparisons using the arithmetic operators (LT, GT, LE, GE), which might able to lead to bypassing seccomp filters and potential privilege escalations.
End of Expandable row content
CVE-2021-3711Criticalgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to EVP_PKEY_decrypt() can be smaller than the actual size required by the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k).
End of Expandable row content
CVE-2021-35942Criticalgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: The wordexp function in the GNU C Library (aka glibc) through 2.33 may crash or read arbitrary memory in parse_param (in posix/wordexp.c) when called with an untrusted, crafted pattern, potentially resulting in a denial of service or disclosure of information. This occurs because atoi was used but strtoul should have been used to ensure correct calculations.
End of Expandable row content
CVE-2018-25032 Highzlib1.2.11-17.el8
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: zlib 1.2.11 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.
End of Expandable row content
CVE-2022-1271Highgzip1.9-12.el8
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An arbitrary file write vulnerability was found in GNU gzip's zgrep utility. When zgrep is applied on the attacker's chosen file name (for example, a crafted file name), this can overwrite an attacker's content to an arbitrary attacker-selected file. This flaw occurs due to insufficient validation when processing filenames with two or more newlines where selected content and the target file names are embedded in crafted multi-line file names. This flaw allows a remote, low privileged attacker to force zgrep to write arbitrary files on the system.
End of Expandable row content
CVE-2022-21698Highgithub.com/prometheus/client_golang1.7.1
1.11.1
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: client_golang is the instrumentation library for Go applications in Prometheus, and the promhttp package in client_golang provides tooling around HTTP servers and clients. In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods. In order to be affected, an instrumented software must use any of promhttp.InstrumentHandler* middleware except RequestsInFlight; not filter any specific methods (e.g GET) before middleware; pass metric with method label name to our middleware; and not have any firewall/LB/proxy that filters away requests with unknown method. client_golang version 1.11.1 contains a patch for this issue. Several workarounds are available, including removing the method label name from counter/gauge used in the InstrumentHandler; turning off affected promhttp handlers; adding custom middleware before promhttp handler that will sanitize the request method given by Go http.Request; and using a reverse proxy or web application firewall, configured to only allow a limited set of methods.
End of Expandable row content
CVE-2018-1098Highgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
3.3.2
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: A cross-site request forgery flaw was found in etcd 3.3.1 and earlier. An attacker can set up a website that tries to send a POST request to the etcd server and modify a key. Adding a key is done with PUT so it is theoretically safe (can't PUT from an HTML form or such) but POST allows creating in-order keys that an attacker can send.
End of Expandable row content
CVE-2021-3121Highgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
2.305.0b2
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An issue was discovered in GoGo Protobuf before 1.3.2. plugin/unmarshal/unmarshal.go lacks certain index validation, aka the "skippy peanut butter" issue.
End of Expandable row content
CVE-2020-29361Highgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
2.305.0a0
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An issue was discovered in p11-kit 0.21.1 through 0.23.21. Multiple integer overflows have been discovered in the array allocations in the p11-kit library and the p11-kit list command, where overflow checks are missing before calling realloc or calloc.
End of Expandable row content
CVE-2020-29363Highgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
2.305.0a0
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An issue was discovered in p11-kit 0.23.6 through 0.23.21. A heap-based buffer overflow has been discovered in the RPC protocol used by p11-kit server/remote commands and the client library. When the remote entity supplies a serialized byte array in a CK_ATTRIBUTE, the receiving entity may not allocate sufficient length for the buffer to store the deserialized value.
End of Expandable row content
CVE-2020-14040Highgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
2.305.0a0
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: The x/text package before 0.3.3 for Go has a vulnerability in encoding/unicode that could lead to the UTF-16 decoder entering an infinite loop, causing the program to crash or run out of memory. An attacker could provide a single byte to a UTF16 decoder instantiated with UseBOM or ExpectBOM to trigger an infinite loop if the String function on the Decoder is called, or the Decoder is passed to golang.org/x/text/transform.String.
End of Expandable row content
CVE-2020-15113Highgo.etcd.io/etcd0.5.0-alpha.5.0.20201125193152-8a03d2e9614b
3.3.23
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: In etcd before versions 3.3.23 and 3.4.10, certain directory paths are created (etcd data directory and the directory path when provided to automatically generate self-signed certificates for TLS connections with clients) with restricted access permissions (700) by using the os.MkdirAll. This function does not perform any permission checks when a given directory path exists already. A possible workaround is to ensure the directories have the desired permission (700).
End of Expandable row content
CVE-2021-30465Highk8s.io/apimachinery0.21.0-rc.0
0.22.0a3
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: runc before 1.0.0-rc95 allows a Container Filesystem Breakout via Directory Traversal. To exploit the vulnerability, an attacker must be able to create multiple containers with a fairly specific mount configuration. The problem occurs via a symlink-exchange attack that relies on a race condition.
End of Expandable row content
CVE-2021-30465Highk8s.io/apiserver0.21.0-rc.0
0.22.0a3
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: runc before 1.0.0-rc95 allows a Container Filesystem Breakout via Directory Traversal. To exploit the vulnerability, an attacker must be able to create multiple containers with a fairly specific mount configuration. The problem occurs via a symlink-exchange attack that relies on a race condition.
End of Expandable row content
CVE-2021-30465Highk8s.io/client-go0.21.0-rc.0
0.22.0a3
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: runc before 1.0.0-rc95 allows a Container Filesystem Breakout via Directory Traversal. To exploit the vulnerability, an attacker must be able to create multiple containers with a fairly specific mount configuration. The problem occurs via a symlink-exchange attack that relies on a race condition.
End of Expandable row content
CVE-2021-42694 Mediumlibgcc8.5.0-4.el8_5
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An issue was discovered in the character definitions of the Unicode Specification through 14.0. The specification allows an adversary to produce source code identifiers such as function names using homoglyphs that render visually identical to a target identifier. Adversaries can leverage this to inject code via adversarial identifier definitions in upstream software dependencies invoked deceptively in downstream software.A flaw was found in the way Unicode standards are implemented in the context of development environments, which have specialized requirements for rendering text. Homoglyphs are different Unicode characters that, to the naked eye, look the same. An attacker could use homoglyphs to deceive a human reviewer by creating a malicious patch containing functions that look similar to standard library functions, such as print, but replace one character with a homoglyph. This function can then be defined in an upstream dependency to launch source code-related attacks.
End of Expandable row content
CVE-2021-39537 Mediumncurses-base6.1-9.20180224.el8
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An issue was discovered in ncurses through v6.2-1. _nc_captoinfo in captoinfo.c has a heap-based buffer overflow.The ncurses package (tic) is susceptible to a heap overflow on crafted input. When the terminfo entry-description compiler processes input, proper bounds checking was not enforced leading to this software flaw. The highest threat from this vulnerability is system availability.
End of Expandable row content
CVE-2021-39537 Mediumncurses-libs6.1-9.20180224.el8
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An issue was discovered in ncurses through v6.2-1. _nc_captoinfo in captoinfo.c has a heap-based buffer overflow.The ncurses package (tic) is susceptible to a heap overflow on crafted input. When the terminfo entry-description compiler processes input, proper bounds checking was not enforced leading to this software flaw. The highest threat from this vulnerability is system availability.
End of Expandable row content
CVE-2018-20839 Mediumsystemd-libs239-45.el8_4.3
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: systemd 242 changes the VT1 mode upon a logout, which allows attackers to read cleartext passwords in certain circumstances, such as watching a shutdown, or using Ctrl-Alt-F1 and Ctrl-Alt-F2. This occurs because the KDGKBMODE (aka current keyboard mode) check is mishandled.
End of Expandable row content
CVE-2018-20839 Mediumsystemd-pam239-45.el8_4.3
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: systemd 242 changes the VT1 mode upon a logout, which allows attackers to read cleartext passwords in certain circumstances, such as watching a shutdown, or using Ctrl-Alt-F1 and Ctrl-Alt-F2. This occurs because the KDGKBMODE (aka current keyboard mode) check is mishandled.
End of Expandable row content
CVE-2021-4122Mediumcryptsetup-libs2.3.3-4.el8
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: It was found that a specially crafted LUKS header could trick cryptsetup into disabling encryption during the recovery of the device. An attacker with physical access to the medium, such as a flash disk, could use this flaw to force a user into permanently disabling the encryption layer of that medium.
End of Expandable row content
RHSA-2022:0370Mediumcryptsetup-libs2.3.3-4.el8
0:2.3.3-4.el8_5.1
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: An update for cryptsetup is now available for Red Hat Enterprise Linux 8. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section. The cryptsetup packages provide a utility for setting up disk encryption using the dm-crypt kernel module. Security Fix(es): * cryptsetup: disable encryption via header rewrite (CVE-2021-4122) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. cryptsetup: disable encryption via header rewrite
End of Expandable row content
CVE-2021-35938Mediumrpm4.14.3-19.el8_5.2
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: A symbolic link issue was found in rpm. It occurs when rpm sets the desired permissions and credentials after installing a file. A local unprivileged user could use this flaw to exchange the original file with a symbolic link to a security-critical file and escalate their privileges on the system. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
End of Expandable row content
CVE-2021-35939Mediumrpm4.14.3-19.el8_5.2
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: It was found that the fix for CVE-2017-7500 and CVE-2017-7501 was incomplete: the check was only implemented for the parent directory of the file to be created. A local unprivileged user who owns another ancestor directory could potentially use this flaw to gain root privileges. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
End of Expandable row content
CVE-2021-35937Mediumrpm4.14.3-19.el8_5.2
Beginning of Expandable row content Screen reader table commands may not work for viewing expanded content, please use your screen reader's browse mode to read the content exposed by this button
Description: A race condition vulnerability was found in rpm. A local unprivileged user could use this flaw to bypass the checks that were introduced in response to CVE-2017-7500 and CVE-2017-7501, potentially gaining root privileges. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability
Regards,
Nataraj.R

Reopening this while we evaluate the above CVEs ^

Hi,
Below are our analysis regarding the CVEs reported:
CVE-2019-9893  - False positive. Libseccomp not in image and not used by node.
CVE-2021-3711  - False positive. Openssl is on backported version 1:1.1.1k-6.el8_5.
CVE-2021-35942 - False Positive. Backported by RH for 2.28-164.el8_5.3.
CVE-2018-25032 - Not Affected. Node does not use zlib. Zlib will be updated in a further version of node.
CVE-2022-1271  - Not Affected. Node does not use Gzip. Gzip will be updated in a further version of node.
CVE-2022-21698 - Not Affected. We do not believe node is affected by this vulnerability. Etcd dependency will be updated in a future version of node.
CVE-2018-1098  - Not Affected. We do not believe node is affected by this vulnerability. Etcd dependency will be updated in a future version of node.
CVE-2021-3121  - False positive. We are using v1.3.2.
CVE-2020-29361 -  False positive. p11-kit vuln detect as etcd vuln. p11-kit is on non vulnerable version.
CVE-2020-29363 - False positive. p11-kit vuln detect as etcd vuln. p11-kit is on non vulnerable version.
CVE-2020-14040 - Not affected. We do not believe node is affected by this vulnerability. x/text dependency will be updated in a future version of node.
CVE-2020-15113  - Not Affected. We do not believe node is affected by this vulnerability. Etcd dependency will be updated in a future version of node.
CVE-2021-30465  - Not affected. We do not believe node is affected by this vulnerability. runc dependency will be updated in a future version of node.
CVE-2021-42694  - Not affected. We do not believe node is affected by this vulnerability.
CVE-2021-39537  - False positive. ncurses-lib not in image and not used by node.
CVE-2018-20839  - False positive. systemd not in image and not used by node.
CVE-2021-4122   - False positive. cryptosetup-libs not in image and not used by node.
RHSA-2022:0370  - False positive. cryptosetup-libs not in image and not used by node.
CVE-2021-35938  - False positive. rpm not in image and not used by node.
CVE-2021-35939  - False positive. rpm not in image and not used by node.
CVE-2021-35937  - False positive. rpm not in image and not used by node.
Please let us know if you have any questions.

@gpang-tigera please let me know which tool are using to scan the image Vulnerabilities part

@gpang-tigera
We were using the Trivy tool to scan the image Vulnerabilities.  In our case, it shows a critical vulnerability. please help me to sort out the problem.
Regards,
Nataraj.R

I'm not sure how exactly Trivy works, but we do strip our images of anything that is not essential to Calico. However, due to how docker image layers work, the scanner might be falsely detecting a vulnerable component that is not present in the final calico-node image. In addition, there seems to be other classes of false positives according to @gpang-tigera (such as p11-kit vuln being detected as an etcd vuln), but I cannot tell why/how Trivy is picking those up as well, maybe try to raise an issue with their team?

It looks like all of these are either "False positive" or "Not affected".
We continue to remove CVEs even if they are False positive or not affected, but I don't think we need to keep this issue open for now.


Invigorating Gemstone

Currently The Invigorating Gemstone shows 80% reduc at lvl 50. It should be 50% reduc, in fact it is 0.4% reduc per lvl + lvl 50 as max (same for patch 2.4.1)

Ah, just to confirm, what other gems are currently capped?
I don't have level caps implemented atm since I figured people wouldn't put in higher levels anyway, but I might add them eventually.


Missing unification event

"Seems like some events that are supposed to handle culture unification and (I think) annex minors simply don't exist in the game files. Events 11106 and 111011928 (used in decision files nationalunification.txt/converterunions.txt and arabian formation.txt do not exist in any file within the events folder. Trying to use these events in game does nothing."
11101 is in vanilla files, 11106 is missing and I have no idea what's that junk of numbers after it:

Solved by #669; the remaining summoned but not defined events are there for HPM compatibility


DOCU-2474: Updates workspaces and teams for get-started guide

Summary
Updates the workspaces and teams getting started guide to match the other work in this guide for 3.0
Testing
Built docs locally

Draft PR, still WIP


Adding Dockerfile

Dockerfile created using:

Debian Jessie
GDAL 2.0.1

Possible issues:

Mongoose emits errors with node-mongodb-native driver for mongodb upon startup
Creating users yields an error, possibly due to above

This fixes #4

Awesome would love to run this from Docker Container

Can we have it use a new nodejs version?

Any other version of Node other than 0.12 fails to build GDAL and install the other necessary npm modules.
6.9.x could potentially work, but it required heavy modification of node package configurations which resulted in a very brittle server environment.  :(

Awesome, I will check this out and merge it soon.


data_bag_item raw_data should be converted to a mash before accessed

Description
https://github.com/chef/chef/blob/85c9830b3396451af209625ef2263013855ff776/lib/chef/data_bag_item.rb#L81
If a hash is given as the new data, and it contains a key with an :id symbol, validate_id raises an error, as it is passed a nil value.
Since raw_data should be a mash anyways, the setter should convert the value to a mash before retrieving values from it, and setting it as the internal value.
Chef Version
12.16.42
Platform Version
n/a
Replication Case
See above
Client Output
==> default: Chef::Exceptions::InvalidDataBagItemID
==> default: --------------------------------------
==> default: Data Bag items must have an id matching /^[\.\-[:alnum:]_]+$/, you gave: nil
==

👍  data bag items should be a mash in chef 13


Use attribute group api instead of entity api when making a call to ermrest

Issue: #171
This PR adds a logic to Reference.read() function to change the uri in order to get the foreign key data as well as current reference data. This doesn't affect the actual Reference._location object and just changes the uri internally for the http request.
The Page._data works exactly as it used to and Page._linkedData stores the data for foreign keys. I didn't add any new test cases for Page._linkedData because I wasn't sure about the data structure that I used for holding the foreign key data. However, the fact that other test cases are not failing shows that Page._data has been set correctly.
The data structure that I used for Page._linkedData is as follows:
 // for the i-th returned data
 this._linkedData[i] = {
  'schemaName:constraintName': foreignKeyData,
  ...
}

// for retrieving the foreign key data in Page using this._linkedData
var i, j, fkData, foreignKeys = this._ref._table.foreignKeys.all();
for (i = 0; i < this._data.length; i++) {
  for (j = 0; j < foreignKeys.length; j++) {
    fkData = this._linkedData[foreignKeys[j].constraint_names[0].join(":")];
  }
}

Is this good enough? Do I need to change it?

I will close this PR, as a new PR will replace it with the complete set of changes related to foreign keys.


integration of Powerwall possible?

Like the data for the cars there are maybe also data for the powerwall available?

Are the Powerwall API's documented somewhere? If so please share a reference. They may be easy to add.
Note that I do not have a Powerwall so am unable to test or validate.

Tesla has once again broken 3rd party auth so I am not able to investigate this request further at this time.

Tesla has removed the Captcha requirement so the library is working. However, I still have no access to a Powerwall for testing. Nor a reference for any of the Powerwall API's. I'm going to close this now. If you can point me to some resources please feel free to comment and I can try to take a look.


Add failure check function to a circuit breaker

Add circuit.failureCheck(func)
Exposes a way to separate which errors should be considered a failure that counts toward tripping the breaker. If the function returns true, then it should count as a failure. I find that I need this feature since I'd like to wrap some http functions with circuit breaker, but only want to trip on certain http status codes.
Usage
const circuit = opossum(myHttpFunction)

circuit.failureCheck(e => {
  // Only consider error with status code >= 500 as failures
  return e.statusCode >= 500;
})

circuit.fire();

To-Do

[ ] Update README

Things to Consider

Currently if the function returns false, I simply emit success with the error as an argument. Anything else that should be done?

Thanks beforehand 🙇

Coverage increased (+0.01%) to 99.408% when pulling a3e27dbe8ec9ffdcce0fd13f20acd390d3047c01 on Permagate:develop-check-failure into b76caf667c93c578925501bde60c54c802c027f3 on bucharest-gold:master.

I think I can see why you might want the action to fail with a rejected promise - doing it this way means you don't need to mess around with modifying code flow/control. What I'm concerned about is having this behavior affect the statistics and the behavior of the circuit in a non-intuitive way. Specifically, the behavior of the code is just as though there were an error, but a 'success' event is emitted, even though the returned promise from Circuit.fire() is rejected. In addition, it modifies the true statistics of the behavior which can lead to non-intuitive reporting.
Maybe there's a better way to go about it.
What about something like Circuit#shouldOpen( func ) which takes a function that accepts a stats object, and the Error as a parameter? It returns a resolved Promise if the circuit should open, or a rejected one if not. The few places where this.open() is called in the circuit would be changed to call _open(this, err).  This could also be a more flexible solution for user-controlled circuit behavior.
Maybe something like this?

class CircuitBreaker {
  shouldOpen ( func ) {
    this[SHOULD_OPEN] = func;
  }
  // etc.
}

// outside of class scope
function _open (circuit, err) {
  if (circuit[SHOULD_OPEN])
    circuit[SHOULD_OPEN].call(circuit[SHOULD_OPEN], circuit.stats, err)
      .then(circuit.open)
      .catch(err => {
        // log error or shutdown or handle in some appropriate way
      });
  }
}

```

Maybe returning a promise in the shouldOpen function is overkill. A simple predicate function that returns true or false is clearer and simpler, and really the shouldOpen function shouldn't need to do anything asynchronous.
// outside of class scope
function _open (circuit, err) {
  if (circuit[SHOULD_OPEN)) {
    return circuit[SHOULD_OPEN].call(circuit[SHOULD_OPEN], circuit.stats, err) && circuit.open();
  }
  return circuit.open();
}

@Permagate Do you think this would handle your use case?

@Permagate - just checking in to see if you have thoughts or feedback on my suggestions.

Thanks for the reminder! it was a bit hectic last week for me, so it slipped my mind to reply 😅
Anyway, your suggestion of shouldOpen is quite different with what I have in mind. If I understand correctly, you'd like to keep the premise of where rejected promise should always be counted as failure and resolved promise as success, but having a shouldOpen function that will check if the failure should trip the circuit breaker or not.
However, the goal of this PR is to achieve what you mentioned:

Specifically, the behavior of the code is just as though there were an error, but a 'success' event is emitted, even though the returned promise from Circuit.fire() is rejected.

While it might seem unintuitive, I think there is scenario where this is desirable. It is when the rejected error is expected, thus should not trip circuit breaker. For example, axios is a http library that rejects http requests when status code is not 2xx. Consider a function that tries to authenticate user:
const breaker = require('opossum');
const axios = require('axios');

const wrappedPost = breaker(axios.post);

module.exports = () => {
  return wrappedPost.post('/login', {
    email<EMAIL_ADDRESS>    password: 'awdawdawd'
  });
};

Suppose if the user fails to authenticate (e.g. incorrect password) and status code is 401, the function will reject an error, and thus it will be counted as failure by circuit breaker. Given enough 401 error response, the circuit breaker will potentially trip, even though this error is expected. Ideally, circuit breaker should only trip in unexpected scenario which usually have 5xx error code. This is possible by adding checkFailure function like so:
const breaker = require('opossum');
const axios = require('axios');

const wrappedPost = breaker(axios.post);
wrappedPost.checkFailure(err => {
  return err.respose.status >= 500;
});

module.exports = () => {
  return wrappedPost.post('/login', {
    email<EMAIL_ADDRESS>    password: 'awdawdawd'
  });
};

Now, even though the user fails to authenticate bazillion of times, it will never trip circuit breaker. With shouldOpen, if there are a lot of failed authentications, it will also not trip circuit breaker. However, because they are still counted as failures, just one 5xx error response is enough to trip circuit breaker. With checkFailure, multiple 5xx error responses are still required to trip.
Hope it makes sense! I'll fix the other feedbacks you mentioned above.

What I'd like to achieve is quite similar with isFailure in levee.

@Permagate your example is helpful and illustrative. I think maybe you are misunderstanding my concern. I am ok with a success event being emitted if the failure check function returns false. My real concern is that the Promise returned from fire() is rejected even though the event is a success.
I took a look at the levee implementation, and this is the key difference between what you have here and what is happening in levee. In levee, if the failure check function returns false (e.g. there was no failure), then the user-provided callback is invoked as though there were no error. https://github.com/krakenjs/levee/blob/master/lib/breaker.js#L113-L119
I can see how this might be problematic in your example. You don't want a failed authentication to trip the circuit breaker, but at the same time, a failed authentication probably demands a different code path than a successful auth. However, it seems counter-intuitive to me that an invocation that results in a success event returns a rejected Promise. In our case, to have parity with levee, the Promisereturned fromfire()` should be resolved, not rejected.
As I said when you first submitted this PR, I am ok with the idea in general and am grateful for the contribution. But the behavior of the code should be consistent, e.g. a success event always results in a resolved Promise.

@Permagate I'm going to close this for now. If you decide to pick it up again, it can be reopened.


Idea: recognise default values

Hey @stevie-mayhew, what's up 😀
Just trying this module, it looks handy. I was thinking though, that in real world use (for me at least) all my pages have a meta title whether I provide a custom one or not, because I'll generate one if not provided. I'll sometimes do the same for Meta Descriptions too. So I would like error messages to reflect the actual tags that are output, and I would like to see the default content when a field is blank, to know whether it's worth overriding it with a custom value.
What do you think about providing a method like this to determine a default value:
// Provide a default meta title if no custom one is set
public function defaultMetaTitle() {
    return $this->Title . ' → ' . SiteConfig::current_site_config()->Title;
}

This could be overridden in the Page class to let developers define their own default. Then you could set a placeholder on form fields so that any blank fields display their default values, and show error messages based on the final resolved value rather than the custom value only.
To explain my approach further - to bring this all together I would then put something like this in my Page class:
// Resolve the actual meta title content that will be output
public function resolvedMetaTitle() {
    return $this->MetaTitle ?: $this->defaultMetaTitle();
}

And I'd put this in my PageController. (Putting it on the model would cause the resolved value to be populated on MetaTitle form fields)
// Resolve a meta title for this page
public function getMetaTitle() {
    return $this->resolvedMetaTitle();
}

Seems like a good idea as long as its configurable to turn on and off - we like to show clients where they haven't done anything beyond the default. Or we could somehow mark it as a "default value"?

Yeah the way I'm using it locally is I set a placeholder value on the field with the default value. So the user can see whether or not they've provided a custom value, and what the default value is if they haven't provided a custom one. That's the idea at least, seems for now that placeholder values and field values look identical in SS4 😅 so I might have to open an issue about that.

Relevant: https://github.com/silverstripe/silverstripe-cms/pull/2215

Little update, that PR has been merged into 4.4.x-dev, so should open up some new possibilities for reading and writing meta tags


Healthcheck URL for api server

Ideally it should be configurable, but due to https://github.com/kubernetes/ingress/issues/720 (we will use k8s GCE ingress) I'm basically interested in api server answering 200 to GET / requests

@rporres what do you need exactly and from whom to unblock src-d/backlog#961?

I need landing-api server to return an 200 http response code to a GET / request. It currently returns a 404 response code
[GIN] 2017/08/23 - 10:04:34 | 404 |       3.603µs |        <IP_ADDRESS> | GET      /

Ok, Sergio said he'll look into this.


Fix missing package update

This PR fixes #

This update got missing in previous PR due to merge conflict.  Pushing to fix hygiene break.


[Bug Report] Select Component popup animation exception in Chrome 74

Element UI version
2.8.2
OS/Browsers version
win7/chrome74
Vue version
2.6.10
Reproduction Link
https://codepen.io/pen/?&editable=true
Steps to reproduce
click the select
What is Expected?
正常的弹出动画
What is actually happening?
这个是我在开发时发现的，包括官网也能复现；
表现：下拉框弹出时会反复跳动两次

I know hao to deal it

i have the same question

I have the same question

How to solve it?

it's maybe chrome bug?

Duplicate of #15501


Handle alternate names for UTF-8 encoding

The issue
Currently, pipenv does this:

In __init__.py, sys.stdout and sys.stderr are replaced by io.TextIOWrappers with encoding set to 'utf8' (no dash): https://github.com/pypa/pipenv/blob/d9ebad335dc4cfff9cb223f7cc3141066044b65b/pipenv/init.py#L31-L36
In _compat.py, the encoding is forced to UTF-8 by checking if sys.stdout/err.encoding.lower() is equal to 'utf-8' (with a dash): https://github.com/pypa/pipenv/blob/d9ebad335dc4cfff9cb223f7cc3141066044b65b/pipenv/_compat.py#L331

Fixes #3313.
The fix

Canonicalizes the encoding name using codecs.lookup(). This will always return 'utf-8' for UTF-8 encodings, no matter what alias is used ('utf8', 'UTF-8', 'u8', etc.)
Catch ImportError when importing ctypes, so that this code path doesn't crash with PyPy (which doesn't support ctypes). @frostming mentioned in #3313 that pipenv doesn't officially support PyPy so I can remove this if you'd prefer, but it seems like a net improvement to me.

The checklist

[x] Associated issue: #3313
[x] A news fragment in the news/ directory: 3313.bugfix.rst

Thanks! if you run into anything else definitely let us know, I may experiment with adding PyPy to CI if we can

Cool, thanks!


Fix output when benchmark reporting is set to console

Results should be formatted with equal offset.
rates contains 'á' characters.

Fixed.


Need Help understanding apk signing keystore file path

Hi Team,
I am currently working in Azure DevOps, and xamarin android application development.
I am able to create build pipeline and build android source successfully. but when I try to sign my android apk I am facing challenges to give android keystore file.
Note: I have placed my keystore file in my project android source code and main source code path as well.  now i really don't know how to specify this keystore file path in my pipeline.yml file.  Below is my yml content.
_# Xamarin.Android
Build a Xamarin.Android project.
Add steps that test, sign, and distribute an app, save build artifacts, and more:
https://docs.microsoft.com/azure/devops/pipelines/languages/xamarin
pool:
vmImage: 'macOS 10.13'
variables:
buildConfiguration: 'Release'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
steps:

task: NuGetToolInstaller@0

task: NuGetCommand@2
inputs:
restoreSolution: '**/*.sln'

task: XamarinAndroid@1
inputs:
projectFile: '**/droid.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'

task: AndroidSigning@3
inputs:
apkFiles: '$(outputDirectory)/*.apk'
apksign: true
apksignerKeystoreFile: '$(build.sourcesDirectory)/pockeystore.keystore'
apksignerKeystorePassword: 'pockeystore'
apksignerKeyPassword: 'pockeystore'
zipalign: false

task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(outputDirectory)'_

Please help me to setup keystore file path.
Joy
Innovation Lead

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

ID: 4b1fbcd8-d799-879e-d672-9dee164401ef
Version Independent ID: 7208d03d-9042-7753-ab4d-d1ad8e99ef1d
Content: Android signing build and release task
Content Source: docs/pipelines/tasks/build/android-signing.md
Product: devops
GitHub Login: @andyjlewis
Microsoft Alias: alewis

I have upload my android keystore file in Library-> SecureFiles Section. Then i try to use it in Build Task but its showing error message Job Job1: Step input secureFile references secure file pockeystore.keystore which could not be found. The secure file does not exist or has not been authorized for use. For authorization details, refer to https://aka.ms/yamlauthz.
My Yaml script is:
Xamarin.Android
Build a Xamarin.Android project.
Add steps that test, sign, and distribute an app, save build artifacts, and more:
https://docs.microsoft.com/azure/devops/pipelines/languages/xamarin
pool:
vmImage: 'macOS 10.13'
variables:
buildConfiguration: 'Release'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
steps:

task: NuGetToolInstaller@0

task: NuGetCommand@2
inputs:
restoreSolution: '**/*.sln'

task: XamarinAndroid@1
inputs:
projectFile: '**/droid.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'

task: DownloadSecureFile@1
inputs:
secureFile: 'pockeystore.keystore'

task: AndroidSigning@3
inputs:
apkFiles: '$(outputDirectory)/*.apk'
apksign: false
zipalign: false
#apksignerKeystoreFile: 'pockeystore.keystore'
#apksignerKeystorePassword: 'pockeystore'
#apksignerKeyPassword: 'pockeystore'

task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(outputDirectory)'

Keep-alive

@joychandru thank you for reporting this and apologies for the confusion.  The Android Signing docs have been updated to address this and will be live within a couple of days.  If you still face the problem that the secure file "has not be authorized for use", please visit https://aka.ms/yamlauthz or click on the secure file and set it to be authorized for use by all pipelines:

Hi @davidstaheli !
I have a similar issue, where the builds are (I think) not being signed. I checked "Pipeline permissions" on the "Secure files" tab, and tried turning it on. But it is always turned back to off.
Strangely, when I change the setting, the "Save"-button (can be seen in your screenshot) does not turn on. This is even though I am the administrator of my project (since I created it).
Do you experience the same issue?

Hi @davidstaheli !
I have a similar issue, where the builds are (I think) not being signed. I checked "Pipeline permissions" on the "Secure files" tab, and tried turning it on. But it is always turned back to off.
Strangely, when I change the setting, the "Save"-button (can be seen in your screenshot) does not turn on. This is even though I am the administrator of my project (since I created it).
Do you experience the same issue?

I'm also experiencing the same issue, even though I have turned on the pipeline permission.
Although this works when I use the classical mode for signing the apk.


Different ocs status-text and status-code in oCIS and oC10 using ocs api v1

Describe the bug
OCIS returns different status and statuscode for some requests:

add/remove user to non-existing group
add/remove non-existing user to a group
get/edit/delete non-existing user
edit not allowed user attribute
get non-existing user's groups

In oCIS
curl -X POST -u admin:admin https://localhost:9200/ocs/v1.php/cloud/users/demo/groups -d groupid="non-existing"

<ocs>
  <meta>
    <status>error</status>
    <statuscode>998</statuscode>
    <message>The requested group could not be found</message>
  </meta>
</ocs>

In oC10
curl -X POST -u admin:admin http://localhost/core/ocs/v1.php/cloud/users/demo/groups -d groupid="non-existing"

<?xml version="1.0"?>
<ocs>
  <meta>
    <status>failure</status>
    <statuscode>102</statuscode>
    <message/>
  </meta>
  <data/>
</ocs>

Expected behavior
oC10 and oCIS ocs response to be identical

@saw-jan is this still an issue?
I don't see it mentioned in any OCIS expected-failures files.

@saw-jan is this still an issue?

Yeah, I can confirm it.
This issue is mentioned in owncloud-sdk's tests

re-tested oCIS latest master (55269c23d) and oC 10.9.2 prealpha (git) still relevant

We will not invest more effort into OCS, because that API is deprecated.


Add support for files with variable content that is comma-separated

Support for content like
Schulz;Petra;24
Blubber;Roger;2344
would be nice.

FLDA now supports List as Record Type. Current supported Types are String, Integer, Long and Enums


Dependency nyholm/psr7 missing in 1.4.0

Q
A

Bug?
no

New Feature?
no

Version
1.4.0

Actual Behavior
Due to the missing dependency, the sourcecode of nyholm/psr7 is never retrieved from packagist.org, resulting in the following bug:
[2018-03-07 15:33:57] main.ERROR: Source class "\Nyholm\Psr7\Factory\Stream" for "Nyholm\Psr7\Factory\StreamFactory" generation does not exist. [] []
Expected Behavior
No errors...
Steps to Reproduce

git clone
composer install
run it?

Possible Solutions
specify nyholm/psr7 in the require section of composer.json

Thank you for this issue.
This library does NOT have a dependency on Nyholm/psr7, guzzlehttp/psr7 or any other client or PSR7 implementation.
The only purpose of this library is to find the classes you have installed. So this library does:
"Is Nyolm/psr7 installed? - If so, use it"
"Is Guzzle PSR7 installed? - If so, use it".
Could you give me some more details. What version of PHP are you running?  Is Nyholm/psr7 installed in your application?

@Nyholm No, Nyholm/psr7 is not installed in our application. The problem is for us 4 levels deep in dependencies.

To clarify, we use a Magento2 Application and use the MyCademy/Mailgun-Magento2 package for using Mailgun in Magento2.
As you can see in the composer.json, it has a dependency to mailgun/mailgun-php.
The mailgun/mailgun-php package has on his turn a dependency to php-http/discovery

The problems lie in the fact that, in our dependency tree, Nyholm/psr7 is never installed. This results in the following error in Magento2:
[2018-03-07 15:33:57] main.ERROR: Source class "\Nyholm\Psr7\Factory\Stream" for "Nyholm\Psr7\Factory\StreamFactory" generation does not exist. [] []

This error is in that sense 'correct', due to the fact that we don't have these source classes since it's nowhere required in the dependency tree.
However, it is quite strange that this package is trying to use your classes, even though they don't exist. Like mentioned in https://github.com/mailgun/mailgun-php/issues/452#issuecomment-371197710, if I revert php-http/discovery back to version 1.3.0, the problem is solved since your package is not yet included in this version and everything works as expected.
PS: we use PHP 7.0.26 ;-)

Can you see where you are trying to use that class? Ie, what line generates the error? The error message is nothing that is printed here.

@Nyholm well that's the problem right there, we do not use it anywhere. Furthermore, the only error shown is the one posted above, and the only place where it could have been thrown is in an underlying package (and my assumption is php-http/discovery, since its the only package using your code).

Furthermore, the only error shown is the one posted above,

Yes. But who is printing the error message or throwing an exception

and my assumption is php-http/discovery, since its the only package using your code

It is only used if it is installed. That is why I cant figure out your errors with the details you describe.

well that's the problem right there, we do not use it anywhere.

I understand that you do not use it in production. But try research this problem locally.

auto discovery does class_exists checks to see what implementation is available. could it be that your autoloader logs these errors? class_exists on non-existing classes is something that can happen and should not be an error.

Took me a while, but here is the trace:

1
0.0012
410344
{main}( )
.../index.php:0

2
0.5278
13885744
Magento\Framework\App\Bootstrap->run( )
.../index.php:40

3
0.5318
13937664
Magento\Framework\App\Http->launch( )
.../Bootstrap.php:258

4
0.8095
25306408
Magento\Framework\App\FrontController\Interceptor->dispatch( )
.../Http.php:135

5
0.8162
25318160
Magento\Framework\App\FrontController\Interceptor->___callPlugins( )
.../Interceptor.php:26

6
0.8470
26202768
Magento\Framework\Module\Plugin\DbStatusValidator->aroundDispatch( )
.../Interceptor.php:142

7
0.8472
26202752
Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception{closure}( )
.../DbStatusValidator.php:69

8
0.8472
26203128
Magento\Framework\Interception\Chain\Chain->invokeNext( )
.../Interceptor.php:138

9
0.8473
26204112
Magento\Framework\App\FrontController\Interceptor->___callParent( )
.../Chain.php:70

10
0.8473
26204112
Magento\Framework\App\FrontController\Interceptor->dispatch( )
.../Interceptor.php:74

11
1.5913
36184320
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->dispatch( )
.../FrontController.php:55

12
1.5978
36274432
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->___callPlugins( )
.../Interceptor.php:26

13
1.8571
39995416
Magento\Backend\App\Action\Plugin\MassactionKey->aroundDispatch( )
.../Interceptor.php:142

14
1.8571
39995416
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->Magento\Framework\Interception{closure}( )
.../MassactionKey.php:33

15
1.8571
39995792
Magento\Framework\Interception\Chain\Chain->invokeNext( )
.../Interceptor.php:138

16
1.8692
40247008
Magento\Backend\App\Action\Plugin\Authentication->aroundDispatch( )
.../Chain.php:67

17
1.8898
40419576
Magento\Framework\Interception\Chain\Chain->Magento\Framework\Interception\Chain{closure}( )
.../Authentication.php:143

18
1.8898
40419952
Magento\Framework\Interception\Chain\Chain->invokeNext( )
.../Chain.php:63

19
1.8898
40419992
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->___callParent( )
.../Chain.php:70

20
1.8898
40419992
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->dispatch( )
.../Interceptor.php:74

21
1.9104
41331904
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->dispatch( )
.../AbstractAction.php:226

22
1.9354
41525888
Magento\Sales\Controller\Adminhtml\Order\Email\Interceptor->execute( )
.../Action.php:102

23
2.4657
46701376
Magento\Sales\Model\Service\OrderService\Interceptor->notify( )
.../Email.php:27

24
2.4680
46703856
Magento\Sales\Model\OrderNotifier->notify( )
.../OrderService.php:140

25
2.4680
46703856
Fooman\EmailAttachments\Model\Email\Sender\OrderSender->send( )
.../AbstractNotifier.php:59

26
2.5936
54148424
Fooman\EmailAttachments\Model\Email\Sender\OrderSender->send( )
.../OrderSender.php:56

27
2.5936
54148504
Fooman\EmailAttachments\Model\Email\Sender\OrderSender->checkAndSend( )
.../OrderSender.php:102

28
2.8620
57155872
Fooman\EmailAttachments\Model\SenderBuilder->send( )
.../Sender.php:77

29
2.8620
57155872
Fooman\EmailAttachments\Model\SenderBuilder->send( )
.../SenderBuilder.php:56

30
7.1825
64710352
Bogardo\Mailgun\Mail\Transport\Interceptor->sendMessage( )
.../SenderBuilder.php:67

31
7.1885
64726104
Bogardo\Mailgun\Mail\Transport\Interceptor->___callPlugins( )
.../Interceptor.php:26

32
7.1910
64732808
Magento\Email\Model\Plugin\TransportInterfacePlugin->aroundSendMessage( )
.../Interceptor.php:142

33
7.1910
64732808
Bogardo\Mailgun\Mail\Transport\Interceptor->Magento\Framework\Interception{closure}( )
.../TransportInterfacePlugin.php:54

34
7.1910
64732864
Magento\Framework\Interception\Chain\Chain->invokeNext( )
.../Interceptor.php:138

35
7.1910
64732904
Bogardo\Mailgun\Mail\Transport\Interceptor->___callParent( )
.../Chain.php:70

36
7.1910
64732904
Bogardo\Mailgun\Mail\Transport\Interceptor->sendMessage( )
.../Interceptor.php:74

37
7.2593
65405584
Mailgun\Mailgun->sendMessage( )
.../Transport.php:65

38
7.2593
65405640
Mailgun\Mailgun->post( )
.../Mailgun.php:135

39
7.2593
65405640
Mailgun\Connection\RestClient->post( )
.../Mailgun.php:204

40
7.2594
65408760
Mailgun\Connection\RestClient->send( )
.../RestClient.php:179

41
7.2633
65435688
Http\Message\MultipartStream\MultipartStreamBuilder->__construct( )
.../RestClient.php:96

42
7.2693
65459280
Http\Discovery\StreamFactoryDiscovery::find( )
.../MultipartStreamBuilder.php:43

43
7.2693
65459280
Http\Discovery\ClassDiscovery::findOneByType( )
.../StreamFactoryDiscovery.php:25

44
7.2853
65562272
Http\Discovery\ClassDiscovery::evaluateCondition( )
.../ClassDiscovery.php:63

45
7.2882
65562648
Http\Discovery\ClassDiscovery::evaluateCondition( )
.../ClassDiscovery.php:174

46
7.2882
65562648
class_exists ( )
.../ClassDiscovery.php:164

47
7.2882
65562712
spl_autoload_call ( )
.../ClassDiscovery.php:164

48
7.2883
65562856
Magento\Framework\Code\Generator\Autoloader->load( )
.../ClassDiscovery.php:164

49
7.2883
65562856
Magento\Framework\Code\Generator->generateClass( )
.../Autoloader.php:35

50
7.3155
65920760
Magento\Framework\Code\Generator->tryToLoadSourceClass( )
.../Generator.php:112

51
7.3158
66017728
__construct ( )
.../Generator.php:181

Looking at row 45 and forward. It seams like @dbu is correct.
We run class_exsits() here. Then the Magento autoloader tries to load and generate(?) this class. And this is where you fail.
I suggest opening an issue on https://github.com/magento/magento2/issues with this stack trace.

@Nyholm & @dbu see https://github.com/magento/magento2/issues/14074
Apparently, Magento thinks this is normal behavior cause you apparently can't have 3rd party classes with the name Factory in it. Due to the ignorance of the Magento developers, the issue there has been closed and marked as a non-issue, so I'd suggest to close this issue since this is appearently not getting fixed (LMAO...).
Thanks for looking anyways and I wish you guys the best of luck in the future ;-)

I just cloned magento2 and ran:
composer req php-http/discovery guzzlehttp/psr7  php-http/message

Then I added the PHP file:
<?php

include_once __DIR__.'/vendor/autoload.php';

echo "Starting\n\n";
$messageFactory = \Http\Discovery\MessageFactoryDiscovery::find();
if (null !== $messageFactory) {
    echo "Class exists!";
} else {
    echo "Fail";
}

Running that PHP file will output "Class exists!".
I could not reproduce the error you got.

Im closing this since an issue has been opened on Magento's repo. I also created a PR: https://github.com/magento/magento2/pull/14085

This was a really strange attempt to circumvent a bug affecting end user in Magento :)
Of course there is no need to add optional dependency as mandatory and there is nothing to fix in Magento core. From the stack trace the problem comes from Bogardo_Mailgun module (or maybe Fooman_EmailAttachments? cannot say exactly without looking into the code) and it's the right place for the bugfix.

It is clear to me that you do not understand the purpose of php-http/discovery. Have a look in the documentation and you will see why requiring nyholm/psr7 does not make any sense.

It is clear to me that you do not understand the purpose of php-http/discovery

Lolwhat? :) How is that different from

Of course there is no need to add optional dependency as mandatory

? Of course I DO understand when particular library needs to be specified in composer.json.

@orlangur "? Of course I DO understand when particular library needs to be specified in composer.json."

Well clearly you dont, since nyholm/psr7 may or may not be declared, it doesn't matter. It CHECKS if the class exists, and by doing this (using official PHP methods), it breaks Magento in the process because of the bad implementation of MAGENTO'S Autoloader

lets not shout at each other - the analysis is done and @Nyholm provided a pull request to magento proving the bug is in the magento autoloader. there is nothing wrong with the discovery, it uses PHP as intended when it does a class_exists call with a possibly not existing class.


Export and Import metrics

 Issue by BrianHicks
Friday Feb 10, 2017 at 16:18 GMT
Originally opened as https://github.com/BrianHicks/elm-benchmark/issues/5

we should be able to export benchmarks for safekeeping and comparison against new data. This should be independent from running benchmarks (and possibly related to #4.) My ideal workflow:

Run benchmarks
Save data (CSV, JSON, whatever… as long as it's consistent)
Improve code
Import prior data for analysis

Also:

Run benchmarks and save data ("a")
Run improved benchmarks and saved data ("b")
…
~profit~ import benchmark data sets a and b for analysis.

This may mean that the analysis may be separate from the benchmarks. That wouldn't be the end of the world, and could pretty easily be hosted somewhere static and public.

 Comment by chadbrewbaker
Saturday Feb 11, 2017 at 14:10 GMT

Yes, this is pretty much it. BOS's Criterion split into two pieces. One for benchmarking Elm code, a common benchmark CSV format, and a separate chunk of code that takes benchmark data from some source and produces Criterion style graphs.
BenchmarkGenerator :: [config] -> InternalBenchmark
BenchmarkExport :: InternalBenchmark -> CSV
BenchmarkImport :: CSV -> InternalBenchmark
ReportKDE :: InternalBenchMark -> KDEReport -- The default
ReportHisto :: InternalBenchmark -> HistoReport

See http://www.serpentine.com/criterion/tutorial.html
For this to really take off I think there has to be out of the box support for benchmarking WASM FFI.  Elm -> JS -> LLVM IR -> WASM.  That way you can also use Elm to benchmark any language that compiles to LLVM IR. C/C++, Haskell, ...
As for WebAssembly I'm not sure what the plans are for Elm. IMHO Elm should support a second type of JS Port called PurePort. If you have WebAssembly or JS that you can prove to be pure then Elm should have a simplified port structure for calling that code and assume no side effects.

 Comment by zwilias
Friday Mar 10, 2017 at 10:46 GMT

I think this is definitely the way to go; especially in terms of separation of concerns.
Let the runner give you only very basic info, and dump a json blob when benchmarking is done. Allow/encourage projects to then take such blobs and give pretty/well formatted information based on those.
I imagine such reporters could exist as SPA's online, too, no installation required ;)

 Comment by zwilias
Thursday Mar 23, 2017 at 18:05 GMT

Let's go all hypothetical for a moment and take it a bit further.
Imagine if elm-benchmark was actually 2 things:

an elm-benchmark-primitives library with the core benchmark and benchmark1 through benchmark8 functions, with one difference - rather than taking a string, make them take an arbitrary piece of data for identification. Edit: upon further inspection, I'm completely wrong and this is basically just Benchmark.LowLevel
elm-benchmark, providing a nice higher level API to work with these primitives (i.e. Benchmark.describe, Benchmark.compare, etc.), a minimalistic but sane minimal browser runner, and a JSON encoder. Edit: so yeah, that's basically already what it is -_-

Splitting the primitives into their own library and keeping them as primitive and limited as possible allows for a richer ecosystem of tools leveraging those. Edit: Then again, there's nothing stopping anyone from doing so right now.
Say you need an 8-way comparison with one of them marked as a baseline; you can just do that. The current structure requires nested describes to get relevant grouping, and doesn't support saying "this benchmark tests input of type X and size Y". There's no particular reason that it must be this way, other than the convenience of having a sane default. And that brings us full circle - the default runner could provide sane defaults. Edit: same goes here, that is totally feasible right now.
Edit: I kind had a major brainfart. See edits.


Use Slack notification name field instead of channel.

Sysdig REST API returns Slack channel name as response['name'] instead of response['options']['channel'] (which is empty):
Example of curl GET (/api/notificationChannels)
{"notificationChannels":[{"id":865,"version":1,"createdOn":1602011148000,"modifiedOn":1602011148000,"teamId":1111,"type":"SLACK","enabled":true,"sendTestNotification":false,"name":"#channel","options":{"notifyOnOk":true,"url":"https://this-is-a-test.ok/123","channel":"","notifyOnResolve":true}}

Integrating this pull request, it would be possible to filter Slack notification channels by using the name field, currently it is not possible to filter by channel name.

Hi @iris-garcia, thanks for your contribution. As I mentioned in #149, secrets are not mounted into PRs from forked repositories. That's a known limitation in GitHub Actions.
We will review and test this PR.

Hey Iris, I am merging this, thanks for your contribution! :100:


Remove default

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=dev:d33aa961828628e3dce7aa3183246c1b0040b25c

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=dev:42e157d528e24c4870e27ebd262a4db2a41a6d30

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=dev:b65d04fd00ddd0d7258a3dd6e42a004e9bd0042c

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=dev:96373c93fe4834dc5f89616a6b20408648645b26

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=dev:f3e183a89a6f1c23fff1b58b84a72b3a8bfb250a

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=dev:f3e183a89a6f1c23fff1b58b84a72b3a8bfb250a

Your orb has been published to the CircleCI Orb Registry.
You can view your published orb on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/nnsnodnb/firebase-app-distribution?version=0.0.8


moves css rules for activityaction.css

Ref: https://github.com/microsoft/vscode/issues/165169
Moves css rules for  src/vs/workbench/browser/parts/activitybar/activitybarActions.ts

We discussed this in the team today: changes to other properties that are not colors or borders will still require some JS code, for example:

listen to theme changes manually
toggle a CSS class based on the presence of a color
in CSS set the non-CSS-variable based properties based on that

This is not a straight forward porting from JS to CSS using variables. This needs some logic to be retained in JS and shall be tested with all possible cases. Sounds not trivial.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Migrate to Swift-3

Also remove unnecessary test dependency CatchingFire

Changes Unknown when pulling f688f1155c6d456c8d1e6ee877e6570c9b3a5346 on Swift-3 into ** on master**.

Changes Unknown when pulling f688f1155c6d456c8d1e6ee877e6570c9b3a5346 on Swift-3 into ** on master**.

Changes Unknown when pulling 019fe6be0be95384e4e6add18012b936dcafbc3e on Swift-3 into ** on master**.

Changes Unknown when pulling 6f77b0e56dd7cca9528ea01affa6efc0af1e713a on Swift-3 into ** on master**.

Changes Unknown when pulling dc22131acdaf6a1bc5ee52d079886df2e0929bd3 on Swift-3 into ** on master**.


Add net47 target

Keeping the oidc client library in sync with the targets for the common identity model library.

Tests are failing - I am still not convinced this is the right thing to do.

I'm thinking the failures are due to the fact that the base IdentityModel library that the Oidc project uses (via nuget) is still using net461. I am running local builds with both 47 variants and it seems to work fine.
Do you have any other ideas on how to address the underlying issue? Maybe remove reliance on System.Net.Http entirely?

Should be fixed with latest


d3.scaleTime() and deep zooming

See following code:
http://jsbin.com/tuwikekuya/1/edit?js,output
When you zoom in too deep inside the view. Moving of the view on x-axis does not work properly any more.
The ticks are jumping instead of moving smooth like they do for y-axis.
The problem occurs when using d3.scaleTime(). For d3.scaleLinear() eveything is good.

This is the expected behavior. The problem is that Date objects in JavaScript only have millisecond resolution, so you will need to limit the ability to zoom in or switch to a linear scale if you want sub-millisecond precision.


Remove aggressive inlining in core/ headers

The following patterns should be refactored out for simplicity & flexibility, save code size:

core/include/xxx_private.h internal headers - roll into either normal functions or standard inlines at point of declaration.
Remove INLINED macro, replace with 'inline static'
Move larger inlined functions (or inlined functions that need constant data arrays) to become normal functions, either in IRAM or flash (candidates include gpio_to_imux, gpio_enable, probably others.)

I think this is more or less done, there might be a couple of oversized inlines still but the bulk of it is cleaned out.


[BUG] IndicesStatsResponse bug when specifying the Shard Level in the IndicesStatsRequest

What is the Bug
When sending a IndicesStatsRequest via a OpenSearchIndicesClient request, the following error is raised
org.opensearch.client.util.MissingRequiredPropertyException: Missing required property 'ShardStats.shards'

The error is primarily related only to when the Shard level is specified. For other levels, the error does not occur.
I believe the error is centered around how the ShardStats class creates objects for the statistics for each of the primary shards. The error is called around the function call of requireNonNull in the ApiTypeHelper class.
There is method to bypass this, in which before calling the response, one call call ApiTypeHelper.DANGEROUS_disableRequiredPropertiesCheck(true); to ensure that a given response is returned
How to Run
OpenSearch version info
{
"name": -----,
"cluster_name": -----,
"cluster_uuid": "eRQAiiiiVRJ67bdt_J2IBXQ",
"version": {
"distribution": "opensearch",
"number": "2.15.0",
"build_type": "tar",
"build_hash": "61dbcd079goe5gn4o5be5762175414bc38bbcadf",
"build_date": "2024-06-20T03:26:49.193630411Z",
"build_snapshot": false,
"lucene_version": "9.10.0",
"minimum_wire_compatibility_version": "7.10.0",
"minimum_index_compatibility_version": "7.0.0"
},
"tagline": "The OpenSearch Project: https://opensearch.org/"
}
For failure
IndicesStatsRequest indicesStatsRequest=newIndicesStatsRequest.Builder().index(indices).level(Level.Shards).build();
// (openSearchClient is a OpenSearchClient class)
openSearchClient.indices().stats(indicesStatsRequest);

For 'dangerous' success
ApiTypeHelper.DANGEROUS_disableRequiredPropertiesCheck(true);
IndicesStatsRequest indicesStatsRequest=newIndicesStatsRequest.Builder().index(indices).level(Level.Shards).build();
// (openSearchClient is a OpenSearchClient class)
openSearchClient.indices().stats(indicesStatsRequest);

What is the expected behaviour
Either the ShardStats are returned or are not required.
Further details
The API Documentation on the README contains no information for the field, nor of the ShardStats class.
Furthermore, for the relevant documentation page, https://opensearch.org/docs/latest/api-reference/index-apis/stats, there is no information on the shards field

@JmacCl could you please check whether this is correctly specified in https://github.com/opensearch-project/opensearch-api-specification (and if not maybe fix it)? @Xtansia is working on replacing all this hand-rolled code by a generator.

Hi @dblock, I'd be happy to contribute the resolution to this issue since I've seen it too, and had to utilise the workaround James outlined.
From the api-spec https://github.com/opensearch-project/opensearch-api-specification/blob/main/spec/schemas/indices.stats.yaml#L95, ShardStats.shards is not an expected property and the docs here https://opensearch.org/docs/latest/api-reference/index-apis/stats do not have a "shards" as a property in the exemplar response.

Hi @dblock, I'd be happy to contribute the resolution to this issue since I've seen it too, and had to utilise the workaround James outlined.
From the api-spec https://github.com/opensearch-project/opensearch-api-specification/blob/main/spec/schemas/indices.stats.yaml#L95, ShardStats.shards is not an expected property and the docs here https://opensearch.org/docs/latest/api-reference/index-apis/stats do not have a "shards" as a property in the exemplar response.

Please and thank you. You'll need to dig up when it was added, etc. We plan to generate docs from the api spec, so up to you if you want to manually add that too now.


SVG files that include image elements are not rendered correctly

The version of prawn-svg library that is currently used by asciidoctor-pdf does not allow to refer to bitmap images located on disk: https://github.com/mogest/prawn-svg/issues/71.
For example, a "title page background" image can be in SVG format and include raster elements ( elements that refer to png or jpg files on local computer) . These elements will not be rendered.
As a workaround, it's possible to embed png/jpg files by converting them into base64 (~ 0.5 - 1 MB string)  and embedding into a SVG file. All these embeddings "inflate" the SVG file to enormous size and make it problematic to edit in IDE or SVG/Text editors.
However the latest version of prawn-svg library includes a fix for the issue and only needs to be integrated into asciidoctor-pdf.

the latest version of prawn-svg library includes a fix for the issue and only needs to be integrated into asciidoctor-pdf.

I agree! I've been tracking that issue and I also notice it just got fixed.
I have two questions. Do we need to enable the new option? Also, how does the path resolution work?

Do we need to enable the new option? Also, how does the path resolution work?

Unfortunatly, just upgrading to the latest version of prawn-svg is not enoght. Asciidoctor-pdf needs to be modified as well by enabling a newly added option in prawn-svg lib:
:enable_file_requests_with_root | string | If not nil, prawn-svg will serve file: URLs from your local disk if the file is located under the specified directory. It is very dangerous to specify your root path ("/") if you're ot fully in control of your input SVG.  Defaults to nil (off).
I've played a bit with the latest prawn-svg library and asciidoctor-pdf and it's resulted into the following changes - relative paths are resolved against the path where a svg file is located.
diff --git a/lib/asciidoctor-pdf/converter.rb b/lib/asciidoctor-pdf/converter.rb
index f913eff..d4322e4 100644
--- a/lib/asciidoctor-pdf/converter.rb
+++ b/lib/asciidoctor-pdf/converter.rb
@@ -816,14 +816,14 @@ class Converter < ::Prawn::Document
     when 'svg'
       begin
         svg_data = ::IO.read image_path
-        svg_obj = ::Prawn::Svg::Interface.new svg_data, self, position: position, width: width, fallback_font_name: default_svg_font
+        svg_obj = ::Prawn::Svg::Interface.new svg_data, self, position: position, width: width, fallback_font_name: default_svg_font, enable_file_requests_with_root: File.dirname(image_path)
         svg_size = svg_obj.document.sizing
         rendered_w = svg_size.output_width
         if !width && (svg_obj.document.root.attributes.key? 'width')
           # NOTE scale native width & height by 75% to convert px to pt; restrict width to bounds.width
           if (adjusted_w = [bounds.width, rendered_w * 0.75].min) != rendered_w
             # FIXME would be nice to have a resize/recalculate method; instead, just reconstruct
-            svg_obj = ::Prawn::Svg::Interface.new svg_data, self, position: position, width: (rendered_w = adjusted_w), fallback_font_name: default_svg_font
+            svg_obj = ::Prawn::Svg::Interface.new svg_data, self, position: position, width: (rendered_w = adjusted_w), fallback_font_name: default_svg_font, enable_file_requests_with_root: File.dirname(image_path)
             svg_size = svg_obj.document.sizing
           end
         end

Thanks! That's exactly what I needed to know.
Do you think the root should be the resolved value of imagesdir or the directory containing the SVG?

I think, the root directory should be the resolved value of the directory containing the SVG.
SVG files are usually prepared in SVG editors like Inkscape or generated programmatically by some tool. Mentioned tools are not aware of imagedir or asciidoctor specifics.

A very sound point! We'll stick to your proposal then.

Would you like to send a PR with these changes?

Sure, I'll send the PR.

Here is the PR: https://github.com/asciidoctor/asciidoctor-pdf/pull/417

Dan, Did you have a chance to review the PR?

Not yet, but it's on my list for this weekend. :hourglass_flowing_sand:

Merged as 4b7a667b409a03d92303882f8520ba4540caea8c. Thanks @AlexanderZobkov!

One thing I noticed is that when I run Ghostscript (gs) on the generated PDF, I get the following warning:
**** Warning: stream Length incorrect.

This only happens when an SVG containing a linked image is included in the document. This makes me think that it is a bug somewhere in Prawn SVG.
You can verify by running the optimize-pdf shell script on the generated PDF.

I'm not sure that this is caused by Prawn SVG. I've run the optimize-pdf script with some PDF files (12) that we generate with asciidoctor-maven-plugin and for one file ghostscript (9.15 cygwin) reported
   **** File did not complete the page properly and may be damaged.

   **** This file had errors that were repaired or ignored.
   **** The file was produced by:
   **** >>>> Asciidoctor PDF 1.5.0.alpha.11, based on Prawn 2.0.2 <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.

All the PDF files include the same SVG elements in title pages.
For me, this is something in Prawn itself. As far as I know, Prawn SVG uses only high-level Prawn API to produce vector geometry and embed images.

For me, this is something in Prawn itself.

I think we're saying the same thing. Somewhere, Prawn is messing up the content length when this combination of APIs are used. The next step is probably to try to duplicate this without Asciidoctor involved and see if we can get a test case. I think the test case still belongs in Prawn SVG since that is where this combination of Prawn APIs is used.

Apologies for commenting on this old thread, but I can't seem to get my images to show up. I wonder if that works in the context of the page title image, but not with embedded SVGs in the content?
In my AsciiDoc file I have:
image::images/test.svg[]

My SVG looks like:
<svg version="1.1"
     baseProfile="full"
     xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink">

    <image xlink:href="file:tab-facet-1.png" />

    <circle cx="150" cy="100" r="12" fill="#f26835" />
    <text x="150" y="106" text-anchor="middle" fill="white">1</text>

</svg>

But when I render the PDF, only the circle + text is shown, the underlying background image is not. I've tried various ways to indicate the path, either relative or absolute, with or without file:, etc. I also tried with a remote URI, and by setting :allow-uri-read:, but to no avail.
Am I missing something?

Replying to myself in case that helps someone else: The <image> tag needs to have a width and height attributes, otherwise prawn-svg will skip it.

@nguillaumin Perhaps consider reporting that upstream in prawn-svg.
However, if I try to view the SVG using a desktop image viewer, I face the same restriction. So perhaps this is to spec.

Facing the same issue with height and width specified in the svg. This image does span multiple pages, maybe that has something to do with anything?
<image x="-0.5" y="-0.5" width="839" height="2598" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA0cAAAomCAIAAAAk6Cj4AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsIAAA7CARUoSoAAAP+lSURBVHhe7N0HWBTHAgfw3SvA0..../>


[curl] Fix mingw to default to winssl (matching windows builds)

Describe the pull request
Fixes the default ssl backend when using mingw to match the backend used for windows builds (winssl).

Which triplets are supported/not supported? Have you updated the CI baseline?
only impacts community mingw triplets

@past-due ，Have you tested these features，

@past-due ，Have you tested these features，

@JonLiu1993 Yep - tested building with mingw and running on Windows. All works as expected. 👍

LGTM, thanks for the PR!


IGNITE-11987: Metrics configuration.

@agura Thanks, for the review!
I will resolve your comments after we came to the consensus in dev-list discussion.

@agura Seems, I resolve all your comments.
Please, review.

@agura
I've done following changes according to your comments:

Metrics management methods moved to new MetricMXBean
configuration remove on metric registry remove
tests to check configuration remove added.

Please, review.

@ibessonov Thanks, for the review. I resolved all your comments.
Please, take a look.


Support for Webhooks

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Support for WebHook configuration
New or Affected Resource(s)

pingone_webhook

Potential Terraform Configuration

# Copy-paste your PingOne related Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

# Remember to replace any account/customer sensitive information in the configuration before submitting the issue

References

depends on https://github.com/patrickcping/pingone-openapi-specs/issues/159


Default value to FFh for unused I/O ports

On a real PCXT, when reading from an I/O port that has no hardware behind it to respond, FFh is always returned.

I have reopened the same pull request, as I deleted the previous fork before you could review and accept this change, and apparently if I delete the fork before this happens, the associated pull requests are automatically closed, which is something I didn't know.


Default annotations for workflow pods

Summary
It would be useful to have the ability to set default annotations for all pods in a workflow via the default workflow spec. Perhaps pods in a workflow could inherit the annotations on the workflow itself? Or another configuration option could be added for this purpose.
Use Cases
We use kube2iam for AWS access which includes our s3 artifact repository. Unless I'm missing something, it seems like every template needs to have an annotation individually applied to it so that it can archive logs. I'd like to be able to apply a default annotation to all workflow pods via the default workflow spec, which would save every workflow definitions from needing to know about that role.

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

would you like to submit a PR to add this feature?

I can look into it when I have time; it's really more of a nice to have than a necessity.

PR up: https://github.com/argoproj/argo/pull/5031


Running  docker bench with  Docker daemon  listen on a specific IP and port

I have changed the default socket "unix:///var/run/docker.sock" ,which will docker listen to a tcp port and ip address .Here is my daemon.json
{

 "tls": true,
 "tlsverify": true,
 "tlscacert": "/tmp/cer/ca.pem",
 "tlscert": "/tmp/cer/server-cert.pem",
 "tlskey": "/tmp/cer/server-key.pem",
 "hosts": ["tcp://<IP_ADDRESS>:2376"]

}

But after this  i am not able to run the docker bench . I am using the following method
docker run -it --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /etc:/etc:ro \
    -v /lib/systemd/system:/lib/systemd/system:ro \
    -v /usr/bin/containerd:/usr/bin/containerd:ro \
    -v /usr/bin/runc:/usr/bin/runc:ro \
    -v /usr/lib/systemd:/usr/lib/systemd:ro \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker/docker-bench-security

i am guessing docker bench require the /var/run/docker.sock to be mounted to the container .Since my docker daemon listen on tcp port and ip address how can i run docker bench for this

Hi @ppratheesh, currently you can't. docker-bench-security requires access to the docker socket in order do get all required information.
You can however use both tcp and socket to get your situation to work.

But using socket would override tlsverify which points  Docker’s tlscacert flag to a trusted CA certificate.After running docker bench i am getting warning [WARN] 2.11  - Ensure that authorization for Docker client commands is enabled
my current daemon.json
{
  "no-new-privileges": true,
  "userland-proxy": false,
  "live-restore": true,
  "log-level" : "info",
  "icc" : false,
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/tmp/cer/ca.pem",
  "tlscert": "/tmp/cer/server-cert.pem",
  "tlskey": "/tmp/cer/server-key.pem",
  "hosts": ["unix:///var/run/docker.sock","tcp://<IP_ADDRESS>:2376"],
  "userns-remap": "appz"
}

so the only way to fix the warning 2.11 is to use a  Docker authorization plugins

What do you mean it overrides the tlsverify flag? It should just allow connections on both port :2376 and the socket (which should only be available locally). After running docker-bench, you can remove the socket setting.
Yes, 2.11 requires authorization plugins.
Also note that if you're running the official Docker image, it is out-of-date (https://github.com/docker/docker-bench-security/issues/405) and you should try running the script or build your own image.

Closing due to inactivity.


It's better prettier/lint only on change/staged files and could be committed after scripts

Per-commit running format-lint on all files before committing right now, but should focus on the files developer want to commit/staged.
Another issue is when files are after formatting and linting before commit which changed would not be marked as changed in staged file so you need to stage and commit again.

completed with PR #695


How to get inputted data

Hi, Thanks to share your active-table.
I going to use your component.
But I don't know how to get data from table when input the data.
If possible, please answer about it or attach it to the active table docs
Best regards.

Hi @luckystar0506.
You can get data from the table using the getData method.

Everything is documented in the official docs. Please use the search function on the top right to assist you with the particular queries. There are also more examples on various designs in the example designs section.
If the documentation doesn't contain something you need, then please comment below. Thankyou!

Thanks.
I want to set type specific cell.
Here is the example.

How to set type for this?
Best regards.

And does this component have merged cell feature?

Unfortunately cell based types and merged cells are not supported by Active Table. Sincere apologies.


For pricing info, see Pricing for Phone System.

The link is broken and send us to a 404 (was a video about SQL, but it's no longuer here)

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

ID: abae7324-861d-7ca7-7239-a5df8fd927d5
Version Independent ID: 8a30bd2f-9bc3-a0a8-8b31-d53836ead4d0
Content: Microsoft Teams add-on licenses - Microsoft Teams
Content Source: Teams/teams-add-on-licensing/microsoft-teams-add-on-licensing.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@adrienmaugard  Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

Hi @adrienmaugard, thank you for your feedback.
It´s working for me now, could you please double-check it?

It work now, thanks.


feat: move --report-unused-disable-directives cli option to .eslintrc.cjs

PR Checklist

[x] Steps in CONTRIBUTING.md were taken

Overview
I don't know this is intended, but generally forks include me preferred set in config file rather than cli options.
thanks take a look the PR!

OH and createESLintRC.ts needs to include these changes. I'll send that up too.

@all-contributors please add @ryota-murakami for code.

🤖 Beep boop! This comment was added automatically by all-contributors-auto-action.
Not all contributions can be detected from Git & GitHub alone. Please comment any missing contribution types this bot missed.
...and of course, thank you for contributing! 💙

@JoshuaKGoldberg Thank you for confirm the PR!
I'm using this template with own customize(swap to https://github.com/laststance/eslint-config-ts-prefixer etc) although there are a lot of points which should I learn.
Especially create new app and migrate existing projects CLI script are great resource for me!
👋


[BUG] - Primary key update logic seems faulty

Describe the bug
In the sample project clickbait data, I wanted to upload new dummy data with the following logic:
import pandas as pd

data = pd.DataFrame([{
    "running_id": idx,
    "headline": "I uploaded this"
} for idx in range(1_000)])

Now, when I have the running_id as the primary key, what I would expect is that my existing records are overwritten. What I get, however, is that 500 records are written new to the database, and 500 seem to be overwritten.
To Reproduce
Steps to reproduce the behavior:

Jump into the clickbait sample project
Either upload a .json file containing the above generated data, or use the SDK (client.post_df(data))

Expected behavior
See above.
Screenshots

Desktop (please complete the following information):

OS: MacOs
Browser: Chrome
Version: 1.2.0

Additional context
-

Steps to solve:

analyze and understand error (1-2 hours)
If easy to fix, continue / if hard to fix, reevaluate time estimations (15 min)
Create Branch and PR, setup implementation (15 min)
Implement fix (1 hour)
Test fixes (1 hour)
Review PR (1 hour)
Merge changes and close issue (15 min)

1 hour of buffer
-> 7-8 hour estimation, so roughly a day in total

Dataset to reproduce:  clickbait-dummy-1000.json.zip

For some reason the bug occurs on the 500th record and following ones. Since we use a chunk size of 500 in the record upload, this is a very interesting information and will be the first field to investigate


[Addition]: If you don't take any action spoofers like this, this will destroy all the network!

Hotspot b58 Addresses
112drPtnkjLsgt2upV2skNv8Fq6mGSjQxupqSDK8XHgHLf5tJMZW
112j8LGyBqNHMcb3ViRYu18BUnPqzp5AuABTM9vmkxThVEVEKRLj
112Z2FZ8185aC3gSaqaazcsr81CCJr1G1tsg2j25w7XChJtkF1xP
11286NK3WfBMXGe4SBe5w3AYhtL34GJpuSzeHLH1E3Pw9AX7zdE3
11ETVCHUYqbdsYHSspqKPSTj4TSdAsFektXN3wnpge55YL6dPf8
11zTQREnubLUDAfT73S8Da5xEvJq4yHDcUjeYwva77CdKwezzCb
112Ezyg7GvFeoFmXg5CLHjf3SGVD5X7kaU4jCvgzcY6B63UpJKzk
112vSbvRjW24VeggpUoRARtcRu5U4d5uTZX4iWPDzBEhr1M3EVus
11wM5owKWLRX5uBQvcg8XYBFb4vScXpAidDHN1nx4TdcLtrytpi
112t3uAMFwF8zTihEcsui7v4f3HUkayiAS6tbxpdWx9sHsc1smbo
11DaiQFZovZnWnjEKpJNCahRQwTvo9E8AV7K9tHTuFjQRht6ZNG
11w5JpEo1eBs9eQ7jqtK8LFLYZQnCGeziDAUy8jktEVBPx9kATR
1125PME7ZdtMnju7wdToHxHcn9hhKViRKbtF7q6uqwEdc7zdUCAQ
112Qj8jY47LGbJnX9U8WYUU7yCNFbzDV9uT8vAc5Ao9WDnGhSC4B
11Nt6ThnJGUYTufCc2C78d9rb18hVRGGa64pvaCNLEHqry2fiQG
113Fx7WJVPXybzLuH1f3n4YXjkby5YNn1Pwtbd8ZpCZRopkCRZZ
1122cJZBQGDqq6cMW88wqmkgYChE9TnQJSk9sX6kjtgxGCqkMvXS
112k716aiXG7KMGpfDrcC1ioW4F1dL56Lb6uwVPvZN57ZBYkaPVN
11inqnWCtR2Wnb5szbFUXR5R8ngNgM7wR4R2Hrg4yp2r9Mb8tJS
117htCnsRMchqNtvayDhZoZpTLNuhjnRVsqg2hisVQPyYgPonwd
11PtLJgganpVFZhfuNvR8nqWVSa1N9zL6XqkdVQQkZjnBwpHDDJ
11iQ8NTteLvWtfCa3nbMbnmAsTvS3JAG33t4eZ4UUeHJSiX7mxC
11DESVUpFEzLTQRiAmL1db6XzbKF7FQjpLQVaJKFSofqRb2d2yD
112BihpiwrJBSHDDEvkKKgWj2UYfZkg8bR7DXHxP32R93x4jvqZY
11hpzSvK3BHaUaXy5yRPqJVdw3rUPev7zZodeju54LdzTguQ42q
112aj5Zp8PhPiwrumTR84kaexGhoHKzZr1sGKX6EtFvmmnHZufQb
12TDQJyJLKHYDQMCmkKbGQBsaKoorqmyi3Vw3fyvcUiJLqAzbWv
111Fuz6J5k266wGUbefD8A8z7gqvFGMWfmjyDxeh4or27REj1dc
112cvuGJh6EeLsNRQvKKipE35haq2wcEmP3dtEBBKwSa8CYu4mq1
117GaNpgczJAYRpGwecjgApo3hFT4JLT3ccYhNd3FAr7QDtvF4v
Discord Handle
No response
Reason(s)
These are hotspots of well known spoofer/cheater in Turkey. He has also banned in Official Discord Server who called 5ky . His most of decives located at Istanbul then moved to Duzce.
His this account has 31 hotspots currently. Some of them in the middile of the sea. He works with an electrician and playing with the network.
Probably he asserted hotspots into 1 or 2 house.
This video is taken from his Telegram group which teaches people how to spoof.
He's currently managing RisingHF discord server.
https://user-images.githubusercontent.com/100527579/159022727-3bf9532d-970c-4ba8-bbac-412f740bbdbf.mov

Quoi ca vous prend de plus,faites votre job!


Set content type if empty for gzipped responses

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

Open rancher using firefox browser
Enable monitoring for a cluster
Navigate to that cluster

Result:
Error messages caused by failure to parse JSON.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.2.2-rc8

https://github.com/rancher/rancher/pull/19497 issue first acknowledged

The bug is reproduced in v2.2.2-rc8.
Following the same steps as the issue describe, notice that

two error messages show in the UI
the GET https://your-url/c/c-xxxx/monitoring response header does not set the content types.

The bug fix is validated with Rancher: master 4fd2548
Following the same steps as the issue describe, notice that

no error message
the GET https://your-url/c/c-xxxx/monitoring response header contains the content types: Content-Type: text/html; charset=utf-8


questions about DDP and multi-GPU usage

Hi Mohit,
I am using your code recently and trying to do the multi-GPU training. But I find that the multi-gpu and DDP usage in your code seems a bit strange for me to understand.
Specifically, in train.py, you use the following code to call multi-process and also use the multi GPU:
mp.spawn(run_seed_fn.run_seed,
                 args=(cfg,
                       obs_config,
                       cfg.rlbench.cameras,
                       multi_task,
                       seed,
                       world_size),
                 nprocs=world_size,
                 join=True)

while then, in run_seed function, you actually create agents for each process respectively, and thus it seems that the agents between different gpus are not sharing params, weights, or gradients, if I do not understand wrongly. And this seems to make multi-gpu training nonsense.
Do I understand correctly? Could you possibly give some explanations?
Great thanks!

@YanjieZe, the DDP code is based on this example from PyTorch.
Do you mean why the train script hard-coded for 1 node? This is bad engineering on my part. Ideally, you should be able to spawn any number of nodes across machines, where each node makes use of multiple GPUs. But my code just handles 1 node at a time.
Hope this helps!

Thank you Mohit! The blog solves my confusion perfectly.
Great thanks again for your response in time and nice open source code :)


Can you resolve the plaid pattern in images?

Hello and thank you for sharing your good repository.
With attention, I can see a plaid pattern in reconstructed images which I believe is the result of patching the image (The border of reconstructed patches has a little less quality). Do you know any way to resolve that (maybe overlapping patches (which may increase the compression size))?

Hello,
Thank you for your interest!
You are correct, the reconstructed image will have these artifacts consisting of noisy edges where patches touch each other. To circumvent this, in a sort-of hacky manner, I have devised smoothing.py which performs linear interpolation at the borders, making the image look clearer.
This is an open problem. A possible cause, in my opinion, is that, given an image patch, the network does not have any explicit information of the surrounding patches, therefore not knowing how to treat that particular pixels.
I have started to brush-up the project, so far ensuring that training works with the latest PyTorch. I plan to devise some experiments in order to fix the patching issues. Feel free to contribute if you have an idea!
Keep an eye on #17 for further updates!
All the best,
Alex

Thanks for explanation. I think the cause you described is correct, in other words, latent variables mainly affect their responsive pixels in the output but they have a wide receptive field, so neighbor patches latent variables affect the border pixels in current patch. Let me know if I'm wrong.
One possible way is to not dividing the image to patches and sweep the image with the conv network. I'm doing something similar to what you've done using 32x32 patches and tried the method. The result showed a different kind of artifact which I believe is because the padding was a significant part of training data but in action there is not a lot of padding in a high resolution image. Because you trained your network on 128x128 patches you should not see this artifact a lot. How do you think about it?
Best regards,
Amin


New Crowdin updates

@oliviertassinari can we drop this?

can we drop this?

Sure, only runs on master though.