ESLint reports 1230 errors and 5 warnings

The readme suggests the use of npm run lint-test to "help you write quality JavaScript code by checking for common formatting errors, enforcing style rules, and suggesting changes that conform to best practices."
ESLint reports 1230 errors and 5 warnings.
This should be fixed.
lint-test-result.txt

Many of these errors can be fixed by th--fix parameter for ESLint, or by adding the Prettier package to the repo. The first option is a relatively quick-win, but temporary. The second will probably be better in the long run, but is likely to require a lot of work initially. What's everyone's though on these?

On the contrary I think the second one (prettier) should be easier to do since everything should be formatted in a single command. But we decided against using prettier long back https://github.com/exercism/javascript/issues/298
Eslint configuration is not complete (open issue https://github.com/exercism/javascript/issues/44) and is not added in CI. Hence all the errors. I am not sure if I have the time to look at each of those eslint rules and decide which ones to use. I would rather go with eslint:recommended or prettier.

Prettier or eslint --fix will take care of some of the formatting issues, which are the bulk of the errors, but not everything.  It might be worth doing another eslint --fix and pulling the lot in one go.

This can now be closed in favor of #480


Add Markdown support

Add possibility to write in markdown and render it in HTML in the list

Use this


karate - command: working dir: null

I am running tests to execute files .groovy with the karate commands, we are having an inconvenience with the 1.2.0.RC1 version of karate using JDK 17 that used to work with the karate version 0.9.6 and the JDK 8.
WARN  com.intuit.karate.shell.Command - exit code was non-zero: 127 - [cmd, /c, plink -ssh server@username -pw Ctrlmp@00 -t source ~/.bash_profile && sh dba1/scripts/groovyctm.sh BGCargaArchivoYappyBACC.groovy bancaabierta 03/08/2022] working dir: null

@Karkino0530 please follow this process to reopen: https://github.com/karatelabs/karate/wiki/How-to-Submit-an-Issue


Diagram in ./dag/README.md is Broken

https://github.com/iykyk-syn/unison/tree/main/dag#dag shows which looks like its missing the ending tag :

 Height99Height99Height99Height99Height 100Height101Height100Height100Height100Height101Height101Height101Regular BlockchainDAG chain of BlocksProposer 1 Proposer 1Proposer 2Proposer 3Proposer 2Proposer 3

Thanks for reporting. This is being fixed in https://github.com/iykyk-syn/unison/pull/55 now. Can you confirm it works for you now?


Test creation: schedule_job_kickurl #242

Codecov Report

Merging #314 into master will increase coverage by 0.52%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #314      +/-   ##
==========================================
+ Coverage   78.31%   78.84%   +0.52%
==========================================
  Files          22       22
  Lines        1259     1281      +22
  Branches       92       92
==========================================
+ Hits          986     1010      +24
+ Misses        251      249       -2
  Partials       22       22

Impacted Files
Coverage Δ

poseidon/poseidonMonitor/test_poseidonMonitor.py
86.85% <100%> (+1.88%)
:arrow_up:

poseidon/poseidonMonitor/poseidonMonitor.py
47.45% <0%> (+0.84%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 42b41ff...c66765a. Read the comment docs.


[Device Support Request] Smart button by Zemismart - TS0041 by _TZ3000_3oitjgaa

I purchase this button from AliExpress: https://www.aliexpress.com/item/1005003711313613.html?spm=a2g0o.order_list.order_list_main.30.83f91802xjGrTT and I am trying to make it work in HA. It works with Tuya as 3 functions.

Single click
Double click
Click and hold

My HA system has both ZHA and MQTT running in parallel and I tried both.
ZHA recognize it as switch, even after adding a custom quirk ts0041.py - https://github.com/zigpy/zha-device-handlers/pull/957/commits/cdf38b4e3c8b7796239b3848347e7eb77144a013

When clicked nothing registers in the logbook.
I then tried with Zigbee2MQTT and it works better there.

In the logbook it shows all (single click, double click and click hold), all 3 states.
Since it comes as this device - https://www.zigbee2mqtt.io/devices/TS0041.html I tried this Blueprint - https://community.home-assistant.io/t/zigbee2mqtt-1-button-scene-switch-ts0041/475324
I set up everything from the Blueprint as it should but when I clicked, nothing happens.

I also check this - https://zigbee.blakadder.com/Tuya_TS0041.html where is says it works with ZHA, but is a different photo, not the one I have. But the model shows as TS0041 by _TZ3000_3oitjgaa
Describe the solution you'd like
I need a quirk for ZHA or MQTT to make this button works in all 3 states. Maybe another blueprint since this does not seem to work.

Device signature
Paste the device signature here.
Don't remove the extra line breaks outside the ```
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0401",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0006",
        "0x000a"
      ],
      "out_clusters": [
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_3oitjgaa",
  "model": "TS0041",
  "class": "zigpy.device.Device"
}

[mqtt-940e4d82963367913f262015136efa0e-Smart button white round-aa41b106c091fd6554c096c3a4cc6d4e.json.txt](https://github.com/zigpy/zha-device-handlers/files/11120123/mqtt-940e4d82963367913f262015136efa0e-Smart.button.white.round-aa41b106c091fd6554c096c3a4cc6d4e.json.txt)

[zha-1be608adfd5dabaaecaf06df5a0aa201-_TZ3000_3oitjgaa TS0041-573e8ab03fa904085f1a51c5d7d72978.json.txt](https://github.com/zigpy/zha-device-handlers/files/11120178/zha-1be608adfd5dabaaecaf06df5a0aa201-_TZ3000_3oitjgaa.TS0041-573e8ab03fa904085f1a51c5d7d72978.json.txt)

Paste the diagnostic information here.
Don't remove the extra line breaks outside the ``` marks.

Additional logs
Paste any additional debug logs here.
Don't remove the extra line breaks outside the ``` marks.

Additional context
Add any other context or screenshots about the feature request here.

Your remote is not known of ZHA.
It need being added in this quirk https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0041.py in the right class that matching the signature and if its not one its need one new device lass is needed.
The switch is the GUI is because tuya have done the firmware wrongly as one light but its being fixed in the quirk then its being loaded.

Hello, I added this quirk https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0041.py but nothing changes. The quirk does not seem to work.

Try adding to your local file that class:
class TuyaSmartRemote0041TI_Var02(TuyaSmartRemote0041TI):
    """Tuya 1-button remote device with time on in."""

    signature = {
        # SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=0x0401, input_clusters=[0, 10, 1, 6], output_clusters=[25]))
        MODEL: "TS0041",
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.IAS_ANCILLARY_CONTROL,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    OnOff.cluster_id,
                    Time.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Ota.cluster_id],
            },
        },
    }

Save changes, restart HA and repair the device.

You mean to add this code to the bottom of my ts0041.py file?

Nothing has changed. I added the code, remove the device, restarted HA and added device again. No change.

Can you check if device gets the quirk? You can see it in the device info tab.
Also, you can enable the debug logs during the pairing proccess and attach here?

Sorry I am noob. Where to click to get device info tab and debug log? Please give me step by step?
home-assistant_2023-03-31T10-42-30.446Z.log

All we need is the "Zigbee Info" from your screenshoot. Sometime also will ask for the diagnostics from the "Download diagnostics" option.
Your device is saying us that no quirk is loaded (well, it is not saying that has a quirk loaded, that is the same).
You have a few errors in the HA startup.
Let's try with another approach.
Remove the current version of ts0041.py.
Copy the version from:

https://github.com/zigpy/zha-device-handlers/blob/0.0.94/zhaquirks/tuya/ts0041.py
Add the proposed class at the bottom.

Save changes, delete any __pycache__ folder from your local quirk folder, restart HA and re pair the device again.

I cleared the code form ts0041.ty and pasted from the link above. I added the code from https://github.com/zigpy/zha-device-handlers/issues/2314#issuecomment-1491653239 to the very bottom (I use Studio code sever) so no option to save. I belive it is saved automatically.
I checked in my quirk folder there is no pycache files. I restarted HA, removed the device and pair it again. No change

Still looks the same, nothing change. Am I doing something wrong?

Do I need to remove other .PY files? Seems like there is error with them? How do I fix it?

__pycache__ is a folder and I'm not sure if it 'shows' as a hidden folder.
Most of your quirks files have errors. You need to fix them or remove (or rename to .py_ ie).
Can you check if there are errors from the ts0041.py file?

Hello, sorry I was not available for a few days.

If the pycache folder is hidded, how do I find find/delete it? I have File editor and Studio Code Server installed, but dont see "hidden" option,

I removed all files from the "custom_zha_quirks" folder. I only left ts004.py file. But how do I tell if is loading it? And if NOT, why? Here is the log after starting HA and info of the button.

What is the problem? Please help :(

I see this in the log:
Unexpected exception importing custom quirk 'ts0041'
6:29:28 PM – (ERROR) /usr/local/lib/python3.10/site-packages/zhaquirks/init.py
But not sure what it is and how to fix it?

You will have an error in the HA startup. Look for the error in the homeassistant.log file. Probably some indent or format error in the file.

Error/formating in which file ? The ts0041 ?
Here is the log: home-assistant.log
/config/home-assistant.log
home-assistant.log

Yes in the file that is trying to load and the only that is in the folder.
Any error in the log?

Yes, here are the errors:

Yes, here are the errors:

And?
Have you read what is saying the error?
File "/config/custom_zha_quirks/ts0041.py", line 185
And:
IndentationError: expected an indented block after class definition on line 184
You can check your /config/custom_zha_quirks/ts0041.py at line 185 and will see that the comment is not indented as the proposed from the previous comment:
https://github.com/zigpy/zha-device-handlers/issues/2314#issuecomment-1491653239

Yes I read is line 185. It is a comment "- """Tuya 1-button remote device with time on in."""
I removed it and now shows 186. The indentation seems good.
Here is a screenshot

    """Tuya 1-button remote device with time on in."""
    signature = {
        # SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=0x0401, input_clusters=[0, 10, 1, 6], output_clusters=[25]))
        MODEL: "TS0041",
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.IAS_ANCILLARY_CONTROL,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    OnOff.cluster_id,
                    Time.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Ota.cluster_id],
            },
        },
    }

I was able to load the quirk finally. Here it is:

However, there is nothing showing. I clicked the button and there is no Logbook. Maybe the  quirk is no good? What do I do from now on? Thanks

Enable the debug logs (you can do it from the 3 dots next to the "RECONFIGURE" button).
Once enabled, press the physicals buttons (click, double,...) . When you hit the stop debug logs a file will be downloaded. Attach it here.

I dont see "Debug log" When I click the 3 dots I get this:

Here is Download diagnostics
zha-1be608adfd5dabaaecaf06df5a0aa201-_TZ3000_3oitjgaa TS0041-573e8ab03fa904085f1a51c5d7d72978.json.txt

Hi,
I have the same device, were you able to make it to work?
I have followed @javicalle  instructions, downloaded the quirk, added section on the end, restarted - I have it discovered using quirk.
adding part of the log - button press and double press are recorded.
home-assistant_zha_2023-09-03T16-29-07.105Z_1.log
ps. I was able to pair it under zigbee2mqtt and it was discovered correctly, but I need it working on ZHA - this is the only waterproof remote I was able to find.

@Drmatterpl Wish IP-class is you needing ?
If PI44 is enough use IKEA RODRET (OnOff is released and OpenClose and Shortcut is on the way) and is Zigbee certificated = dont need any quirks for working OK and is very likely getting firmware updates to new Zigbee standard ZCL R9,

I deleted the post before I saw your response, in fact all was good - I followed the instructions above and the button works as expected.
I need this remote to open a gate-door (release electric lock) - it will be mounted on the fance - totally outside, IP44 is not enough. My wife also wants to be able to turn on the lights in backyard with it.
Now we have it all working - thanks to you !!!


request {resource}_id even if the resource is not declarative-friendly.

Generally, having user-settable IDs is a better user experience, and it would be best to require them and exempt yourself in edge cases rather than not enforce it.
See https://github.com/aip-dev/google.aip.dev/pull/1019 which also recommends upgrading the guidance.

Generally, having user-settable IDs is a better user experience, and it would be best to require them and exempt yourself in edge cases rather than not enforce it.
See https://github.com/aip-dev/google.aip.dev/pull/1019 which also recommends upgrading the guidance.

Generally, having user-settable IDs is a better user experience, and it would be best to require them and exempt yourself in edge cases rather than not enforce it.
See https://github.com/aip-dev/google.aip.dev/pull/1019 which also recommends upgrading the guidance.

Generally, having user-settable IDs is a better user experience, and it would be best to require them and exempt yourself in edge cases rather than not enforce it.
See https://github.com/aip-dev/google.aip.dev/pull/1019 which also recommends upgrading the guidance.


[A2-809] back up ListProjectRules API with real data

:nut_and_bolt: Description
The ListProjectRules API is one of our POC APIs we built with the superteam during our initial spike to tag ingested resources with projects. This API returns a map of rules keyed by the project they belong to, which is then used by the ingest/compliance service to tag ingested resources with the appropriate project based on whatever rules apply to that project.
Now, this API is backed by a simple cache in OPA. Before, the intention was to store the rules in a proper OPA store and fetch them with a special rule_mappings rego function. However, since we weren't using any of rego's capabilities to manipulate the returned rules and the cost of re-converting the stored rules and their nested conditions into their correct storage types was high, I decided to switch to storing them in a basic go cache (still a part of OPA's state, so we still get all opa refresh logic needed for multi-node)).
We will need to rerun benchmarks to ensure this change doesn't impact performance.
:+1: Definition of Done

[x] rules are loaded into a cache on authz server init
[x] the rule cache gets updated anytime a rule gets created, deleted, or updated
[x] load rules into test setup, get tests passing
[x] delete GetProjectRules POC APIs, project mappings rego, old engine rule structs
[x] rename API so it's not so similar to ListRulesForProject

:athletic_shoe: Demo Script / Repro Steps
1. create projects
curl -kH "api-token: $TOK" https://localhost/apis/iam/v2beta/projects -d "$(jq -n '{ id: "foo-project", name: "my foo project" }')"
curl -kH "api-token: $TOK" https://localhost/apis/iam/v2beta/projects -d "$(jq -n '{ id: "foo-project-2", name: "my foo project" }')"

2. create rules
curl -kH "api-token: $TOK" https://localhost/apis/iam/v2beta/rules -d "$(jq -n '{ id: "foo-rule", name: "my foo rule", type: "NODE", project_id: "foo-project", conditions: [{ type: "CHEF_SERVERS", operator: "MEMBER_OF", values: ["prod", "staging"]}]}')" | jq .

curl -kH "api-token: $TOK" https://localhost/apis/iam/v2beta/rules -d "$(jq -n '{ id: "foo-rule-b", name: "my foo rule", type: "EVENT", project_id: "foo-project-2", conditions: [{ type: "CHEF_ORGS", operator: "EQUALS", values: ["staging"]}]}')" | jq .

curl -kH "api-token: $TOK" https://localhost/apis/iam/v2beta/rules -d "$(jq -n '{ id: "foo-rule-z", name: "my foo rule", type: "EVENT", project_id: "foo-project-2", conditions: [{ type: "CHEF_ORGS", operator: "EQUALS", values: ["staging"]}]}')" | jq .

chef-automate dev grpcurl authz-service chef.automate.domain.authz.v2.Projects.ListRulesForAllProjects
{
  "projectRules": {
    "foo-project": {
      "rules": [
        {
          "id": "foo-rule",
          "projectId": "foo-project",
          "name": "my foo rule",
          "conditions": [
            {
              "values": [
                "prod",
                "staging"
              ]
            }
          ]
        }
      ]
    },
    "foo-project-2": {
      "rules": [
        {
          "id": "foo-rule-z",
          "projectId": "foo-project-2",
          "name": "my foo rule",
          "type": "EVENT",
          "conditions": [
            {
              "type": "CHEF_ORGS",
              "values": [
                "staging"
              ],
              "operator": "EQUALS"
            }
          ]
        },
        {
          "id": "foo-rule-b",
          "projectId": "foo-project-2",
          "name": "my foo rule",
          "type": "EVENT",
          "conditions": [
            {
              "type": "CHEF_ORGS",
              "values": [
                "staging"
              ],
              "operator": "EQUALS"
            }
          ]
        }
      ]
    }
  }
}

Note: in the grpcurl response, some of the rule types, condition attributes, or condition operators are suppressed because they're the 0 value of those types. We could fix this, but I've confirmed the values are correct in logging, and since this API is for internal use only, it should be fine leaving it as is.
:chains: Related Resources
:white_check_mark: Checklist

[ ] Necessary tests added/updated?
[ ] Necessary docs added/updated?
[ ] Code actually executed?
[ ] Vetting performed (unit tests, lint, etc.)?

ℹ This still leaves ingest-service querying an empty rule cache when the system is not using v2.1 -- but it's better than before (and #561), where these queries would fail ("empty eval" OPA error), in that now, they'll just return nothing. Merging.


git push deis master ssh error

e2e is hitting ssh_exchange_identification: read: Connection reset by peer intermittently.  (Can open in deis/workflow-e2e if this id determined to be a spec issue).
An example:
16:27:14 ------------------------------
16:27:14 $ deis auth:register http://deis.k8s.local --username=test-21355 --password=asdf1234<EMAIL_ADDRESS>16:27:14 Registered test-21355
16:27:14 Logged in as test-21355
16:27:14 $ deis keys:add /tmp/deis-workflow-home895683507/.ssh/deiskey-328.pub
16:27:14 Uploading deiskey-328.pub to deis... done
16:27:14 $ deis apps:create test-51626122
16:27:14 Creating Application... ...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...o...done, created test-51626122
16:27:14 Git remote deis added
16:27:14 remote available at ssh://git@deis-builder.k8s.local:2222/test-51626122.git
16:27:14 $ GIT_SSH=/tmp/deis-workflow-home895683507/.ssh/git-ssh GIT_KEY=/tmp/deis-workflow-home895683507/.ssh/deiskey-328 git push deis master
16:27:14 ssh_exchange_identification: read: Connection reset by peer
16:27:14 fatal: Could not read from remote repository.
16:27:14
16:27:14 Please make sure you have the correct access rights
16:27:14 and the repository exists.
16:27:14 $ deis apps:destroy --app=test-51626122 --confirm=test-51626122
16:27:14 Destroying test-51626122...
16:27:14 done in 0s
16:27:14 $ deis auth:cancel --username=test-21355 --password=asdf1234 --yes
16:27:14 Please log in again in order to cancel this account
16:27:14 Logged in as test-21355
16:27:14 Account cancelled
16:27:14
16:27:14
16:27:14 • Failure [48.502 seconds]
16:27:14 git push deis master
16:27:14 /go/src/github.com/deis/workflow-e2e/tests/git_push_test.go:284
16:27:14   with an existing user
16:27:14   /go/src/github.com/deis/workflow-e2e/tests/git_push_test.go:282
16:27:14     who has added their public key
16:27:14     /go/src/github.com/deis/workflow-e2e/tests/git_push_test.go:280
16:27:14       and who has a local git repo containing buildpack source code
16:27:14       /go/src/github.com/deis/workflow-e2e/tests/git_push_test.go:166
16:27:14         and has run `deis apps:create` from within that repo
16:27:14         /go/src/github.com/deis/workflow-e2e/tests/git_push_test.go:164
16:27:14           that user can deploy that app using a git push [It]
16:27:14           /go/src/github.com/deis/workflow-e2e/vendor/github.com/onsi/ginkgo/ginkgo_dsl.go:354
16:27:14
16:27:14           No future change is possible.  Bailing out early after 10.018s.
16:27:14           Expected
16:27:14               <int>: 128
16:27:14           to match exit code:
16:27:14               <int>: 0
16:27:14
16:27:14           /go/src/github.com/deis/workflow-e2e/tests/cmd/git/commands.go:32
16:27:14 ------------------------------

More can be found in https://ci.deis.io/job/workflow-test-pr/4137/consoleFull
Logs: https://ci.deis.io/job/workflow-test-pr/4137/artifact/4137/logs/

Closing for now as this seems to have resolved itself in the last few months. Let's re-open if it occurs again in e2e.

Same problem here
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Add NavigationMesh debug when navmesh is added later through scripts

Add NavigationMesh debug when navmesh is added later through scripts.
Previously the meshinstance for the navigationmesh debug visuals would only be added when entering the SceneTree but not if the navigationmesh was empty. When the mesh is added later through scripts the child node meshinstance was missing so the debug visuals were not added.
Fixes #32545

Cherry-picked for 3.5.


Add code comments about field keys

At one point, app users were called "field keys". We've since updated the UI to talk about app users instead, and we've also updated the API (e.g., the …/field-keys endpoint is now the …/app-users endpoint). However, it didn't seem as useful to change the code. That means that app users are still called field keys in the code (in both Backend and Frontend). Mostly I think that's OK, but it also has the potential to lead to confusion (as @alxndrsn has pointed out). This issue is to add code comments to Backend and Frontend to clarify that "field keys" refer to app users. For example, a comment could be added to the FieldKey frame in Backend.

It looks like there are two things currently being referred to as "field keys" in the code:

the FieldKey frame - which might be renamed as AppUser, and
the request.fieldKey property, which seems to be a session bearer token

Is this correct?  Would 2 be accurately described as e.g. an "app user token"?

Would 2 be accurately described as e.g. an "app user token"?

That sounds pretty close. You can see request.fieldKey being added in fieldKeyParser() in lib/http/middleware.js. The only thing I'd add to your description is that we use the same mechanism for public links. Public links specify the session token using the st query parameter, which fieldKeyParser() also puts in request.fieldKey. For public links, fieldKeyParser() also rewrites request.originalUrl to a /v1/key URL, which is what we use for app users. So in total, I would say that request.fieldKey is "any session token specified in the URL" or "any session token that uses the same auth mechanism as app users."

the FieldKey frame - which might be renamed as AppUser

Unless it's overly confusing, I think we should just add code comments, not rename "field keys" to "app users" in the code. There are just too many references to "field keys". We're also getting close to starting on a redesign of how users work, including app users. I don't think we should try to rename things until after we complete that redesign, since a lot is about to change anyway.


⚠ Bofrost.at has degraded performance

In 3fde2bc, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1229 ms

Resolved: Bofrost.at performance has improved in f212c23 after 6 minutes.


feat(electron): [DO NOT MERGE BEFORE RELEASE] ✨ switch from badvpn-tun2socks to golang based tun2socks

In this PR, I switched the VpnTunnel used by electron apps from ShadowsocksLibevBadvpnTunnel to GoVpnTunnel.
The feature was implemented in #1134 before, but reverted in #1150 due to releasing priorities. Here I not only turn on the flag, but also remove all unused build flags and 3rd party binaries/code from the repository:

cleaned up dead code in Android referencing legacy libev libraries, these files have already been excluded from the Android plugin project
cleaned up dead code in Apple referencing legacy libev libraries, these files have already been excluded from the iOS XCode Project and the macOS XCode Project
removed third_party/badvpn/**/*.*
removed third_party/shadowsocks-libev/**/*.*
removed bower license generator because we already got rid of bower
re-generate the licenses disclaimer
I also added version: 1.7.3 to package.json because it is required by npx generate-license-file
Finally, I removed other dependencies used by shadowsocks-libev including libev, libev-mingw, mbedtls, c-ares, pcre and sodium

It seems we are deleting too many files, and GitHub cannot handle it perfectly 😂. The hidden files include the sodium library source code in third_party, and one README change in tools/outline_proxy_controller.


Special Number

💥 Proposal
Special number in JAVA
Have you read the Contributing Guidelines on Pull Requests?
Yes

/assign


Keypoints format

Thanks for your Awesome work!
While generating keypoints using openpose, output format is json file and in your code is npy file.
2_1_gen_kpts.py is not completed yet, Are there instructions to reshape keypoints as required in your script?

Hi @Ibrahimatef, we have updated 2_1_gen_kpts.py for your reference:
https://github.com/ShenhanQian/SpeechDrivesTemplates/blob/c1e1b6ddd65456c3d31fb71f788c30ffd09a2e92/data_preprocess/2_1_gen_kpts.py#L49-L54


function Sync() not existed

*db.DB has no methods Sync().
maybe the github.com/HouzuoGuo/tiedot/db has modified already

Thanks @cilen! Indeed, the method Sync has been removed in tiedot. Fixed! :+1:


Memory leaks

Severe problem, need to investigate

It seems like process rapidly grows to some size and stops growing (~200M on my testbed).
Tried to find the leak with strict mode and changing vars to let/const, that did no effect.
As for now, I don't assume, there is a leak
Will try to investigate that with running the process for a long time and will re-open this if we face that again.

It leaks. Or, at least, 200MB RSS is huge for 4 checks.
Will push a new version in several days.

Fixed in 0.9.3+


Log screen freezes on Downloading Launcher....

@ChampionLeake do you get any console output during that step? Does NUS Downloader work for you?

On the latest Windows release I enabled the command line window to be shown all the time, I would like to know if it shows any errors when you reach that step.

@ChampionLeake changed the get_launcher procedure, please test the latest release and let me know if it works for you.

Alrighty, I'll test it when I have my laptop. Sorry if I was slow on the feedback

Alright, I was able to get things finally working. Thank you


[Notebook] Connecting Locally.ipynd file depracated

Running the notebook in order shows the following error:
----> 1 worker = gr.GridClient(addr='http://localhost:5000')

AttributeError: module 'grid' has no attribute 'GridClient'

Notebook should be updated or removed, in order not to confuse first timers like I just did.

try this way:
hook = sy.TorchHook(torch)
node ="http://localhost:5000"
worker = gr.WebsocketGridClient(hook, node)


Address 5.3.0 api review

Description
Address the Spring Cloud Azure 5.3.0 release api review, to port https://github.com/Azure/azure-sdk-for-java/pull/34267 and https://github.com/Azure/azure-sdk-for-java/pull/34318 to this branch.
This PR also did some refactor to reduce code duplication.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
spring-cloud-azure-core

/azp run java - spring - tests


Polyfills::Window destroyed while evaluating script

When running Win32 ValidationTests App, polyfills::Window is destroyed when loading babylon.material.js
I (kinda) fixed it by adding a reference Window::Initialize
        napi_ref result;
        napi_create_reference(env, jsWindow, 1, &result);

This doesn't happen with the Linux Validation App.

#235 probably fixes this, but I haven't tested. The issue is in https://github.com/nodejs/node-addon-api/pull/714.

I did another try today. I still get the crash win x86 but not x64. Windows + Chakra.
To experience it, compile and run ValidationTests in 32bits mode on Windows.


Generic Name Changes

Change image_info to sample_info to maintain a generic name for all the use-cases

Resolve the review comments raised. Other than that, changes look fine. Run the vscode formatter in the changed files as discussed.


Feat/convert placeholder

Created the convertToPlaceholder function, which converts a file to a placeholder with the 'pinned' status. This function takes the file path and the ID as parameters for the conversion.
Additionally, exposed the function using Node-API.

Switch base branch to 'get/placeholder-state' and resolve conflicts
cc: @miguelsw


Make InfExtendedReal a bitstype

closes #4
So here's an attempt at making InfExtendedReal a bitstype. Since a lot of the arithmetic and whatnot assumes it's working with a Real value, I added a x.val property accessor that will return the finite value or -+infinity. This seemed to be the easiest way to get InfExtendedReal into a bitstype without completely rewriting all the code for it.
That being said, I'm a little unsure how to fix the test changes where the @inferred tests were failing. I added the types that they should expect, but I'm not sure if thats the correct solution or if there is a better one.
Aside from that there were a couple of other minor changes to get the x.val accessor working properly. I might want to add more tests as well as I'm not sure everything is covered with the current set.

Ok, I think this should be about ready to merge if anybody wants to give it a final check.

Thanks again! I'll release this as v0.2 soon.

Oh and thanks for the extensive tests.

@cjdoris I'd like to do one more PR to clean everything up and consolidate things. Let me get that going, and when thats done we can release the v0.2 if thats ok with you

I already released v0.2, but I'm happy to make v0.2.1. I was also planning to do a spring clean (and attend to some of the other issues I've been mulling over #6 #11 #14), but don't have time to do it for a little while so go ahead. Maybe make an issue to outline what you're planning?

ah ok no problemo. :) I'll throw an issue up and get it going


etpro_telemetry: fix unimplemented "insecure" sensor_info argument

nice catch, I don't mind merging it or removing the parameter for being unused.

Whoops, deleting the fork removed the RP. Will re-submit in a few minutes. :-)


telemetry api datadog configuration missing service name

Bug Description
According to https://buf.build/envoyproxy/envoy/file/main:envoy/config/trace/v3/datadog.proto#L29 the service_name field of the datadog tracing provider must be configured. Otherwise the configuration will fail and new pods using the proxy will refuse to start with this error:
ADS:LDS: ACK ERROR istio-gateway-qkhm8.istio-system-2422 Internal:Error adding/updating listener(s) <IP_ADDRESS>_32010: Proto constraint validation failed (DatadogConfigValidationError.ServiceName: value length must be at least 1 characters): collector_cluster: "outbound|8126||dd-agent.kube-system.svc.cluster.local"

It seems this is where we are currently creating the configuration for the datadog config:
https://github.com/istio/istio/blob/aeb0876637bfb819344d0ced3b822aa35cc7f5e8/pilot/pkg/networking/core/v1alpha3/tracing.go#L257-L262
And the ServiceName is not being set.
It is quite strange that the datadog provider requires the service name to be set here as it seems the other providers do not actually seem to require this?
I assume we should use the same logic from here to set the ServiceName?
https://github.com/istio/istio/blob/aeb0876637bfb819344d0ced3b822aa35cc7f5e8/pkg/bootstrap/config.go#L307-L337
I guess the other solution would simply be allow the user to set this value when configuring the telemetry api? But it doesn't seem great to have to do that from a user experience as you would have to create a new resource for every deployment to set the service name correctly in the traces.
Im open to working on this issue and fixing it but would require some direction on what we would like to do and how.
Version
➜  istioctl version
kubectl version --shortclient version: 1.13.2
control plane version: 1.13.2
data plane version: 1.13.2 (28 proxies)
➜ kubectl version --short
Client Version: v1.23.6
Server Version: v1.21.5-eks-bc4871b

Additional Information
I cant include the output of the bug report but here you can find the relevant config and error log
values:
  meshConfig:
    defaultProviders:
      tracing:
      - datadog
      extensionProviders:
      - datadog:
          port: 8126
          service: dd-agent.kube-system.svc.cluster.local # from reading the code i cant specify $(HOSTIP) here? :cry:

The logs from pilot show:
ADS:LDS: ACK ERROR istio-gateway-qkhm8.istio-system-2422 Internal:Error adding/updating listener(s) <IP_ADDRESS>_32010: Proto constraint validation failed (DatadogConfigValidationError.ServiceName: value length must be at least 1 characters): collector_cluster: "outbound|8126||dd-agent.kube-system.svc.cluster.local"

It seems like the skywalking envoy plugin is much smarter in the scenario where this value isn't specified?
https://github.com/envoyproxy/envoy/blob/03f23769d19e1baaf37fe52dcfe3f840429f9d06/api/envoy/config/trace/v3/skywalking.proto#L39-L44
Maybe its the datadog plugin in envoy which we should look at instead of this?

Is it possible to configure Datadog using extensionProviders, but using $(HOSTIP) instead of a service?
It seems best suited when running the agents as a Daemonset.


No way to update the non-dist version of manifest.json

Issue

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

semantic-release-chrome version: 1.1.3

What you did and problem description

I've added semantic-release-chrome to a standard chrome extension package which has various source files that get compiled to a /dist folder via an npm build script.
My goal was to have semantic-release-chrome modify the manifest.json with the new version and then have that commited along with package.json and CHANGELOG.md as part of the final release commit.
What happened

Only the dist folder manifest.json is updated which means CWS will get the new version but not GitHub
Suggested solution
Maybe take an array of paths to update the manifest?
This is a bit tricky since updating and zipping both happen during the prepare step which means there's no chance for another plugin to do anything in beween.
Right now, my work around will be to copy the manifest from dest back to src folder in an exec plugin that comes later.

hey @gabeduartem, can I ask if you're accepting contributions for this?


After installation the recent items shows (No Name)

see screenshot:
http://screencast.com/t/csLodenJPB
this is immediately after install

it's an install over a previous version of 5.5, which has old page IDs still in session.

ah, my bad


Can't send JMS messages, getting 'uber-trace-id' is not a valid java identifier.

Using spring-integration and after added the opentracing starter:
        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-spring-jaeger-cloud-starter</artifactId>
            <version>1.0.3</version>
        </dependency>
        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-spring-cloud-starter</artifactId>
            <version>0.2.4</version>
        </dependency>

started to get errors:
javax.jms.JMSRuntimeException: AMQ139012: The property name 'uber-trace-id' is not a valid java identifier.
	at org.apache.activemq.artemis.jms.client.ActiveMQMessage.checkProperty(ActiveMQMessage.java:992) ~[artemis-jms-client-2.6.4.jar:2.6.4]
	at org.apache.activemq.artemis.jms.client.ActiveMQMessage.setObjectProperty(ActiveMQMessage.java:763) ~[artemis-jms-client-2.6.4.jar:2.6.4]
...

Accordingly to this (see at the bottom) all dashes should be replaced with $dash$ but this is not happening. When I try to use raw opentracing java-jms it works as expected
I created repo that can be used to reproduce this issue

Could you please try 0.2.6 version?
If the java-jms works we are probably using a wrong version? Are you interested in submitting a fix for this?

I tried 0.2.6 and also the latest version, but still getting the same error
        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-spring-jaeger-cloud-starter</artifactId>
            <version>2.0.0</version>
        </dependency>
        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-spring-cloud-starter</artifactId>
            <version>0.3.2</version>
        </dependency>

Yep, I will submit a fix once I know what's wrong with it


How to build the containers on arm32v7 or arm64?

When I try to compose the containers on an armhf machine, I get these errors (as they are amd64 builds):
postgrest_1  | exec /bin/bash: exec format error
ui_1         | exec /bin/bash: exec format error
remote_1     | exec /bin/bash: exec format error

Can I build armhf or arm64 images of containers on armhf or arm64?
It looks like this would be a start:
for container in postgrest ui remote; do
  c=open-balena-$container
  git clone<EMAIL_ADDRESS>  docker build -t $c $c/
done

Then collect the new image ids and use them of the docker-compose suing sed 's|dcaputo-harmoni/||' compolse/services.yml

@bernhardkaindl thank you for the PR’s! With your commit to the open-balena-postgrest I am assuming the containers will now build on arm32v7/arm64?  If so I would be happy to post arm builds as well.  We should probably have an option in the quickstart script to specify the target architecture as well?  Curious how the base open-balena packages handle different architectures as we could always mirror that, I’ve always run them on amd64.


Remove ErrTruncated

	if off != len(msg) {
		// TODO(miek) make this an error?
		// use PackOpt to let people tell how detailed the error reporting should be?
		// println("dns: extra bytes in dns packet", off, "<", len(msg))
	} else if dns.Truncated {
		// Whether we ran into a an error or not, we want to return that it
		// was truncated
		err = ErrTruncated
	}
	return err
}

In msg.go L840 we should probably remove err = ErrTruncated. This is #423 as well, but it makes sense. Assume a message is fully formed even with TC. You can check msg.Truncated for truncated message.
Willing to remove ErrTruncated to signal a breaking change for people relying on this behavior.

it makes very sense

I missed this while I was out. We originally added ErrTruncated because its not obvious that you need to check truncated and so someone that's blindly using this might end up processing a truncated message and not realizing it. With ErrTruncated a user can explicitly can ignore truncation if they want and know what truncation is, but in the default case it'll error and they'll need to read up on what truncation is and if they want to ignore it.

That behaviour is still there, but you have to check msg.Truncate to see.
Originaly I think I added this because of assuming a truncated message
might actually be not complete, i.e incomplete RRs.
On Tue, 27 Nov 2018, 15:24 James Hartig<EMAIL_ADDRESS>wrote:

I missed this while I was out. We originally added ErrTruncated because
its not obvious that you need to check truncated and so someone that's
blindly using this might end up processing a truncated message and not
realizing it. With ErrTruncated a user can explicitly can ignore
truncation if they want and know what truncation is, but in the default
case it'll error and they'll need to read up on what truncation is and if
they want to ignore it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/miekg/dns/issues/814#issuecomment-442098472, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVkW4bSVTd6_bvGLbrX76PhBhpQrKu2ks5uzVkxgaJpZM4YndHl
.


Fixing linter errors by excluding http://site.icu-project.org/ (404)

Signed-off-by: Andriy Redko<EMAIL_ADDRESS>Description
The linter is failing the builds because http://site.icu-project.org/ is not available anymore.
 📝 Summary
---------------------
🔍 Total.........1071
✅ Successful.....775
⏳ Timeouts.........0
🔀 Redirected.......0
👻 Excluded.......294
🚫 Errors...........2

Errors in plugins/ingest-attachment/licenses/tika-parsers-LICENSE.txt
✗ http://site.icu-project.org/ (HTTP status client error (404 Not Found) for url (http://site.icu-project.org/))

Errors in plugins/ingest-attachment/licenses/tika-core-LICENSE.txt
+ echo
+ echo ::set-output name=exit_code::2
✗ http://site.icu-project.org/ (HTTP status client error (404 Not Found) for url (http://site.icu-project.org/))

Issues Resolved
None
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Already fixed in #1189

My bad @dblock, thank you


HTTP mock server as an independent process

It is also programmable from the outside via cli arguments

@jlevison since I don't know when I'll have a few hours for independent packaging for the mock , here's my work so far for merging purposes, so that you're not blocked

Does it mean we will have two mock servers for some time?

@jlevison are you going to incorporate this in your next p-r?


Grabbing grabbables still possible when TwoHandGrabbables script is disabled.

When deactivating the TwoHandGrabbable script the object can still be interacted with as it is still subscribed to the interaction events (as long as it still has a collider that can be targeted). There should be a check in BeginInteraction that checks if the script is enabled, and returns if it is not. Deactivating the script should be a clear indication that the user does not want the object to be interacted with.
This should be fixed for both Grabbable and TwoHandGrabbable.
https://github.com/bouvet/BouvetDevelopmentKit/blob/6b6e2f092d739de6fe200447c29e216d99b26962/Scripts/Runtime/Foundations/Functionallity/Hands/Grabbable.cs#L66
https://github.com/bouvet/BouvetDevelopmentKit/blob/6b6e2f092d739de6fe200447c29e216d99b26962/Scripts/Runtime/Foundations/Functionallity/Hands/TwoHandGrabbable.cs#L50

I think in general we should move a lot of our event handling to onEnable and onDisable instead of start and OnDestroy. In my opinion, this would make interactions like this much more resillient and it would behave more as expected.

Just be aware that starting event handling onEnable might break the interaction as InputManager might not have completed it setup yet.
https://docs.unity3d.com/Manual/ExecutionOrder.html

Thank you for the heads up, although I still feel that's the right way to go 😉
We can have a go at changing it, and potentially not do the initial subscribe in staer, andhave it unsubscribe and resubscribe with onEnable and OnDisable after that.

Fixed in version 1.1.1.


Update chuyu/es.xml

I change it due to questions from several people interpreting a bit badly in wsusscn2.
CompactOS=>Change this part for confusions in the users of Dism ++, who asked me when searching Google.
there will be no further changes on the page. "Last correction".
I'm sorry for any inconvenience.

Thank you


Feature: auto value for max queued seeds

it will probably be very similar to how PR#62 implements auto value for SeedQueueConfig#backgroundPreviews

I don't think this is necessary, AUTO should only really be used for options that users don't need to understand, but to increase their RAM allocation in the first place users should in my opinion understand that this is going to correlate with Max Queued Seeds.
I also don't want SeedQueue to be on (Max Queued Seeds != 0) by default.
Something I would be interested in is implementing reasonable defaults for Max Generating Seeds and Max Generating Seeds (Wall) once we get the results from the poll in discord.
Unless you come up with a very convincing argument I think I'll close this pr

I don't think this is necessary
Many users have been seen to have Max Queued Seeds much below what it should be with the ram they've allocated thinking that it would cause issues because their cpu isn't "good enough" (this feature would had prevented that and also the text walls helpers had to send to those users to pin-point the best settings would had reduced in length)
AUTO should only really be used for options that users don't need to understand
Why? imo we should have AUTO value for every option we can. Why you may ask, because it would make helping new users much much easier in general (reducing the amount of support we have to do can increase our productivity towards more features, fixes and improvements --> right now if someone asks for the best settings for their specs we have to explain so many things for Max Queued Seeds option)
I also don't want SeedQueue to be on (Max Queued Seeds != 0) by default
We can set it to 0 (as i said above just telling the user to set it to Auto would be much easier than explaining everything to them when we know that they will most likely put it on what Auto does)

another thing is that why do you think Max Generating Seeds and Max Generating Seeds (Wall) are options people don't need to understand? imo they should be explained even prior to Max Queued Seeds and most people will want to understand them if they knew what they are but the same doesn't really go for Max Queued Seeds.

I think defaults are fine for Max Generating Seeds (+Wall) to give users a starting point to try out more themselves. I absolutely think they are settings people need to understand, thats why I'm against making them AUTO.
I only really want to use AUTO values where users shouldn't mess with stuff unless they know something already (see Threading Settings) or where a default value wouldn't work because it changes depending on more factors (Background Previews, changes based on other options/layouts).
I'm opposed to AUTO values anywhere in Queue Settings to be honest, because I think those are the options users should kind of understand.
What I'm not opposed to however would be to implement some kind of warning for users based on their allocation, however there would also have to be a good bit of tolerance, for example AA runners usually use 3GB as base

I think defaults are fine for Max Generating Seeds (+Wall) to give users a starting point to try out more themselves. I absolutely think they are settings people need to understand, thats why I'm against making them AUTO

😕 you just said "I would be interested in is implementing reasonable defaults for Max Generating Seeds and Max Generating Seeds (Wall)"

I'm opposed to AUTO values anywhere in Queue Settings to be honest, because I think those are the options users should kind of understand.

Making the user understand what it is just a sentence long, making them put it to what it shoud be? Not really, helpers have to calculate that everytime because of all the different hardware

maybe we should just make it default to the answer the formula gives instead of having an AUTO value for it because it would stil be as helpful and would definitely avoid putting auto values for queue settings

maybe we should just make it default to the answer the formula gives instead of having an AUTO value for it because it would stil be as helpful and would definitely avoid putting auto values for queue settings

This is what I meant by "I would be interested in is implementing reasonable defaults for Max Generating Seeds and Max Generating Seeds (Wall)".

Making the user understand what it is just a sentence long, making them put it to what it shoud be? Not really, helpers have to calculate that everytime because of all the different hardware

This is only an issue because there is no very concise setup video yet (which is normal because features are still evolving and we don't have all the data yet), once that is done people will be able to calculate it themselves.
Also, having an AUTO option wouldn't solve people not knowing how much RAM to allocate, they wouldn't even be able to tell how big the queue is without checking making their wall 10x10 or checking F3. It also wouldn't help with users overshooting on RAM, which is arguably a bigger issue than undershooting.
I'm going to close this PR, I think a warning telling the user they have too little/too much RAM allocated with some tolerance makes more sense and is better for users knowing what's going on than an AUTO option


NodeToIndex returned values don't cover the whole codomain

ortools for python version: 7.1.6720
python version: 3.6.7
Platforms: linux, darwin
In the following example even though the number of nodes is 3, the NodeToIndex returns correct values only for nodes 1 and 2, but not for 0.
from ortools.constraint_solver import pywrapcp

def main():
    number_of_locations = 3
    number_of_vehicles = 1
    start_nodes = [1]
    end_nodes = [0]

    index_manager = pywrapcp.RoutingIndexManager(number_of_locations, number_of_vehicles, start_nodes, end_nodes)
    i = index_manager.NodeToIndex(0)

    print("Number of nodes: ", index_manager.GetNumberOfNodes())    # Prints 3
    print("NodeToIndex: ", i)   # Prints -1
    print("IndexToNode: ", index_manager.IndexToNode(i))    # Should not give correct result (sometimes it does)

if __name__ == "__main__":
    main()

The mapping is not specified for start and end nodes.
Here is how to scan a route:
index = routing.Start(0)
while not routing.IsEnd(index):
    plan_output += ' {} ->'.format(manager.IndexToNode(index))
   ...


Error when tearing down istio test framework

Bug description
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[x] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
I was writing a test framework for istio.io. Normally there'd be no errors when setting up and tearing down the istio test framework. However, an error appeared after istio 1.6.1 was released so I suspect there might be a connection.
Steps to reproduce the bug

Set environment variables. More details in this makefile.

export HUB=gcr.io/istio-testing
export TAG=1.7-alpha.b5d6aeed94550848279425513a1d0b9e229c5720

Create a file bug_test.go with the following content:

package bug

import (
	"testing"

	"istio.io/istio/pkg/test/framework"
	"istio.io/istio/pkg/test/framework/components/istio"
	"istio.io/istio/pkg/test/framework/resource/environment"
)

var inst istio.Instance

func TestMain(m *testing.M) {
	framework.
		NewSuite("bug_test", m).
		SetupOnEnv(environment.Kube, istio.Setup(&inst, nil)).
		Run()
}

Create some kind of k8s cluster (I launched a GKE and connected to the master) and run go test bug_test.go -v --istio.test.env=kube, which gives

2020-06-08T22:01:36.802855Z     info    tf      Test run dir: /tmp/bug-test-892101d8c7f4421980edf6

- Processing resources for Istio core.
✔ Istio core installed
- Processing resources for Istiod.
- Processing resources for Istiod. Waiting for Deployment/istio-system/istiod
✔ Istiod installed
- Processing resources for Ingress gateways.
- Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
✔ Ingress gateways installed
- Pruning removed resources
✔ Installation completetesting: warning: no tests to run
PASS
2020-06-08T22:03:06.072053Z     error   tf      Error during close: 1 error occurred:
        * configmaps "istio-status-leader" not found

ok      command-line-arguments  91.806s

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
Output from istioctl version --remote:
client version: 1.6.0
control plane version: 1.7-alpha.b5d6aeed94550848279425513a1d0b9e229c5720
data plane version: 1.7-alpha.b5d6aeed94550848279425513a1d0b9e229c5720 (1 proxies)

Output from kubectl version:
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:52:00Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.9-gke.2", GitCommit:"4751ff766b3f6dbf6c6a63394a909e8108e89744", GitTreeState:"clean", BuildDate:"2020-05-08T16:44:50Z", GoVersion:"go1.13.9b4", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
It is installed by istio test framework itself.
Environment where bug was observed (cloud vendor, OS, etc)
The GKE cluster I tested against was created using
gcloud container clusters create $CLUSTER_NAME \
  --cluster-version latest \
  --machine-type=$M_TYPE \
  --num-nodes 4 \
  --zone $ZONE \
  --project $PROJECT_ID

We should either ignore the error or not clean it up. Basically it's only created in some cases but we always try to clean it up and then log an error when it's not there