git-remote-http defunct processes from cluster-register_cattle-cluster-agent

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

Set up a downstream RKE cluster with controlplane/worker/etcd roles
May need to let environment run for a few hours or days (or longer)
Run ps -aef| grep git-remote-http | grep defunct

Result:
root@ip-10-0-10-10:~# ps -aef| grep git-remote-http | grep defunct
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root<PHONE_NUMBER>477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1002027 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1003623 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1007068 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1008661 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1013683 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1047331 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1063943 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1072376 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1114015 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1164008 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1192443 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1207442 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1212456 1938477  0 Nov14 ?        00:00:00 [git-remote-http] <defunct>
root     1939739 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940142 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940285 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940319 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940684 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940750 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940763 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940793 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940822 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940828 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1940914 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1941101 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1941272 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     1941642 1938477  0 Oct22 ?        00:00:00 [git-remote-http] <defunct>
root     2019753 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2023155 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2024758 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2029990 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2033161 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2034739 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2039756 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2043166 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2044772 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2048280 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2049884 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2053285 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2054868 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2058284 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2059877 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2063267 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2064879 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2068271 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2069877 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2073259 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2074850 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2078256 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2079849 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2083236 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2084824 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>
root     2088252 1938477  0 Nov15 ?        00:00:00 [git-remote-http] <defunct>

Other details that may be helpful:
This PID matches this container:
# docker inspect 079 | grep -i "pid\|Name"
            "Pid": 1938477,
        "HostnamePath": "/var/lib/docker/containers/2b3fab56a2bd8d4b3be4a26d0eec54ab8f589e8cd4ab7fce7e031ea7a3fa09f2/hostname",
        "Name": "/k8s_cluster-register_cattle-cluster-agent-5c97dd84f-h9ctr_cattle-system_c1b8ec65-40c3-4195-aa11-63d7e341c38d_0",
                "Name": "no",
            "PidMode": "",
            "PidsLimit": null,
            "Name": "overlay2"
            "Hostname": "cattle-cluster-agent-5c97dd84f-h9ctr",
            "Domainname": "",
                "io.kubernetes.container.name": "cluster-register",
                "io.kubernetes.pod.name": "cattle-cluster-agent-5c97dd84f-h9ctr",
                "io.kubernetes.pod.namespace": "cattle-system",

Looks like there was a similar problem in v2.0 with another rancher workload - https://github.com/rancher/rancher/issues/13858
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
v2.5.2
Installation option (single install/HA):
HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory):
t3a.medium on AWS EC2 - 2vCPU, 8GB RAM
Kubernetes version (use kubectl version):

> kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

root@ip-10-0-10-10:~# docker version
Client:
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.13.8
 Git commit:        afacb8b7f0
 Built:             Wed Oct 14 19:43:43 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.8
  Git commit:       afacb8b7f0
  Built:            Wed Oct 14 16:41:21 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.3-0ubuntu2
  GitCommit:
 runc:
  Version:          spec: 1.0.1-dev
  GitCommit:
 docker-init:
  Version:          0.18.0
  GitCommit:

gz#13535

I am too experiencing this issue on selfhosted centos 8 with docker 19.03.12

I am also experiencing this issue on self-hosted air-gapped installation on ubuntu with two master and one worker node.
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3+k3s2", GitCommit:"f8a4547bec36b4d1597c19c86b5063756d4c150e", GitTreeState:"clean", BuildDate:"2020-10-30T19:30:45Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3+k3s2", GitCommit:"f8a4547bec36b4d1597c19c86b5063756d4c150e", GitTreeState:"clean", BuildDate:"2020-10-30T19:30:45Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

Client: Docker Engine - Community
 Version:           19.03.12
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        48a66213fe
 Built:             Mon Jun 22 15:45:44 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.12
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       48a66213fe
  Built:            Mon Jun 22 15:44:15 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

I am also experiencing this issue on centos 7.x with docker 19.03.12、19.03.13

I've had a k3s cluster working for the better part of this year without any issue, until recently. The defunct processes show up within minutes after the cluster starts. These started after installing the nfs-client-provisioner chart from the archived Helm stable repository.

This can be solved the same way as we solved it in Rancher previously, see https://github.com/rancher/rancher/issues/13858. This needs to be applied and tested if we see any side effects when using this.

This can be solved the same way as we solved it in Rancher previously, see #13858. This needs to be applied and tested if we see any side effects when using this.

I am on
Rancher | v2.5.1
User Interface | v2.5.0
Helm | v2.16.8-rancher1
Machine | v0.15.0-rancher45

and still I have the issue. The ticket mentioned said this would be fixed in v2.0.7

Temporary workaround: on the k3s server, scale the cattle-cluster-agent deployment down and then back up.
sudo k3s kubectl scale deployment -n cattle-system cattle-cluster-agent --replicas=0
sudo k3s kubectl scale deployment -n cattle-system cattle-cluster-agent --replicas=1

I can also confirm this issue. For me it also affects custom (Rancher-launched) RKE clusters, not just imported ones. I'm running VMware Ubuntu 18.04 nodes on-premise.

First Environment: Rancher 2.5.1 (Clusters: RKE-launched 1.19.4) || affected, uses proxy for internet access
Second Environment: Rancher 2.5.1 (Clusters: RKE-launched and imported RKE 1.19.3 & 1.19.4) || affected, uses proxy for internet access
Third Environment: Rancher 2.43 (Clusters: RKE-launched and imported RKE 1.17.5) || Seemingly unaffected, does not use proxy for internet access

The issue doesn't seem to affect any nodes that are part of the Rancher HA cluster in any environment, only other RKE clusters.

I think it is fixed in 2.5.4, when I upgrade to 2.5.4,  the problem disappeared

I think it is fixed in 2.5.4, when I upgrade to 2.5.4,  the problem disappeared

This is still a problem with my Rancher 2.5.5 HA environment, which is managing the following clusters:

The Rancher HA cluster itself, RKE-launched v1.19.4; unaffected
A Rancher-launched v1.18.4 cluster; there are only a handful of defunct git-remote-http processes
An imported k3s v1.20.2+k3s1 cluster; a pair of new defunct processes every 5 minutes

This is still a problem with my Rancher 2.5.5 HA environment, which is managing the following clusters:

The Rancher HA cluster itself, RKE-launched v1.19.4; unaffected
A Rancher-launched v1.18.4 cluster; there are only a handful of defunct git-remote-http processes
An imported k3s v1.20.2+k3s1 cluster; a pair of new defunct processes every 5 minutes

My problem turns out to be another case of wildcard DNS causing lookups to fail because of the default options ndots:5 DNS configuration; see rancher/k3s#1954. Having said that, my workaround in that issue is probably evil.
By turning on query logging I was able to find that something was attempting to resolve git.rancher.io, which caused a lookup for git.rancher.io.mydomain.tld, and in turn resolved to the external address of my cluster's ingress controller. This of course returns a 404. I imagine that the error status isn't being handled gracefully.
I've removed the wildcard DNS record. It simply doesn't provide enough value, especially when compared to chasing my tail each time it causes a strange problem like this. I haven't seen a single defunct git-remote-http since making this change.

My problem turns out to be another case of wildcard DNS causing lookups to fail because of the default options ndots:5 DNS configuration; see rancher/k3s#1954. Having said that, my workaround in that issue is probably evil.
By turning on query logging I was able to find that something was attempting to resolve git.rancher.io, which caused a lookup for git.rancher.io.mydomain.tld, and in turn resolved to the external address of my cluster's ingress controller. This of course returns a 404. I imagine that the error status isn't being handled gracefully.
I've removed the wildcard DNS record. It simply doesn't provide enough value, especially when compared to chasing my tail each time it causes a strange problem like this. I haven't seen a single defunct git-remote-http since making this change.

I think @StoneCut is correct about it being proxy related.  We upgraded our dev Rancher HA to 2.5.6. and we are seeing 2 new zombie procs every 5 minutes on the host that is running the cattle cluster agent in each of our clusters managed by that Rancher.
I took a packet capture (for our proxy server, as well as the IPs that git.rancher.io resolve to) on the host running the agent.
At the same time, I was tailing the logs for the coredns workload.  Every time I see the coredns spit out a bunch of DNS queries related to git.rancher.io, I see the K8s node trying to communicate directly to the AWS IP, and not to our proxy server.

To test the theory about the proxy, we manually modified the cattle-cluster-agent workload in our clusters and added in the HTTPS_PROXY, HTTP_PROXY and NO_PROXY values that it should be using.  After the pod restarts, we have not seen any zombie procs on any of our clusters.

Proxy isn't really an Option in my Air gapped environment. Any suggestions for this case?
No Idea from where is the cause. Cluster-Agent is clear. Which process is trying to bring up this connection to git.rancher.io?

Availabl to test on both master and 2.5-head.

@kravciak To reproduce this issue, you can try to:

Go to downstream cluster and add a helm chart repo in app & marketplace
Edit the helm repo URL so that it can't be reached or failed to reach.
Go to the node where cattle-cluster-agent is deployed, run ps -ef | grep defunct

I was able to reproduce the issue on v2.5.5.

This works fine on 2.5-head (41f173a), I tried on k3s and rke clusters and they are without defunct processes.

@kravciak Please log a forwardport for this issue to validate it on master-head


feat: Implemented Voice Search

Fixes #1357
Changes: Voice Search is used.
proper permission is taken.
It is a necessary feature.
Screenshots for the change:

@nikit19 @iamareebjamal please help

There is a wildcard import in one of you files which is causing the Travis build fail

@aggarwalpulkit596 Can you suggest a way to fix it?

Just remove any generic import ending with .*

Build is failing due to format violations

@ShridharGoel I had carefully refactored the code in android studio before pushing to github... Can you suggest a way to fix the error?

@ShridharGoel I had carefully refactored the code in android studio before pushing to github... Can you suggest a way to fix the error?

Run this command 'gradlew spotlessApply' to fix the error

Also, the UI needs to be better. No need to write 'Use Voice Search' just the icon is sufficient and that icon should be at the right end of the 'Enter a location' field, this is what I would suggest.

@iamareebjamal @nikit19 please review

UI is looking really bad. Take a look at existing apps which use voice search

Improved looks:

Still, do you seriously think it looks good?

How about this?

Just check voice search in play store and other applications.

@liveHarshit please see this:-

@iamareebjamal Used vector icon. PR is updated

@iamareebjamal Any other changes required?

@iamareebjamal I think this PR is ready.

As told before, ask peer review first

@liveHarshit What's your opinion?

@liveHarshit I'll make necessary changes and update accordingly.

@liveHarshit PR is updated

@liveHarshit please see the code now

@iamareebjamal please review


Reference runtime-only ObjC classes with bare strings

As part of this, rename TypeMetadataRecordKind to TypeReferenceKind and consistently give it three bits of storage.
The better modelling of these type references appears to have been sufficient to make dynamic conformance checks succeed, which is good but unexpected.

@swift-ci Please test.

Build failed
Swift Test OS X Platform
Git Sha - ca46a4cd466b595b5642944f8acba5fe0cff56db

@swift-ci Please test.

Build failed
Swift Test OS X Platform
Git Sha - ca46a4cd466b595b5642944f8acba5fe0cff56db

Build failed
Swift Test Linux Platform
Git Sha - ca46a4cd466b595b5642944f8acba5fe0cff56db

@swift-ci Please test OS X.

The OS X bot flaked out when it got to running the iphonesimulator tests, but that means it didn't run them, so force-merging is probably not a good idea.

Build failed
Swift Test OS X Platform
Git Sha - d10239313fbf2ee92cb24cc5ad346838bae61fec

Simulator test harness is apparently broken; should be resolved by https://github.com/apple/swift/pull/18322.

@swift-ci Please test OS X.


doesnt remember selection for multiple choice

doesnt remember selection for multiple choice when scrolling out of view

Fixed in v0.3.4 28bb950afa495ffb2e956a75e2eb0a324bc2eedf


[BUG] Choke on badly named docker compose services

Describe the bug
Service named with an underscore fails as invalid component name.
This is the same problem as https://github.com/deref/exo/issues/72
Expected behavior
We should apply the same solution as we did for procfiles. See this PR and the highlighted line in particular:
https://github.com/deref/exo/pull/73/files#diff-d25b12dec6f33085b7526cc93449e046c919e5705e416eb816d79292961f0f91R41
Note that I'd argue that underscores should be rejected by docker compose itself, especially given what the spec says about aliases and hostnames for links.

Containers for the linked service MUST be reachable at a hostname identical to the alias, or the service name if no alias was specified.

Assigning to @BenElgar to resolve as part of his work to support more docker compose examples.


Publish new version with syntex fix

Is it possible to publish a new version to crates.io with the fix made recently for syntex? I'm currently unable to package a crate using this as a dependency; I tried out using the latest version from Github and it works fine, so I think pushing a new release as-is should fix the issue I'm having.
Thanks so much!

published.

Thanks!


Human friendly ABI input parameter error

What was wrong?
It was hard to figure out why the contract call input parameter encoding failed, esp. with all type coercion going on.
Now you get:
web3.exceptions.ArgumentEncodeError: Cannot encode 1. argument of the function, expected type: b'string', inbound value None, full signature is {'inputs': [{'name': b'_value', 'type': b'string'}], 'type': b'constructor'

How was it fixed?
Added a new TypeError exception subclass that comes with a human friendly error message.
For backwards compatibility, I kept old check_if_arguments_can_be_encoded function around, as there might be subtle differences in the behavior. However this function can be marked to be deprecated in the future release.
Cute Animal Picture
   /\     /\
  {  `---'  }
  {  O   O  }
  ~~>  V  <~~
   \  \|/  /
    `-----'__
    /     \  `^\_
   {       }\ |\_\_   W
   |  \_/  |/ /  \_\_( )
    \__/  /(_E     \__/
      (  /
       MM

This looks like a really nice usability improvement.  Can you explain your choice to write this as a new function rather than modifying the existing function?

It is subtly different regarding exceptions as the old one. So I was thinking maybe have a deprecation path and avoid breaking the library users was nice. But I can make it this one function if you think we can do compromises here with the backwards compatibility.

Actually it doesn't make sense as this is called from Contract internals. Let me change this to the one function?

It isn't always the case, but generally I consider anything in utils/... to be non-public API an subject to change without notice.

@miohtama Are you still interested in doing this improvement? It looks like the next step was merging to a single function. Some things have changed in the last eight months :) so you would need to rebase against master.

Some other merged PRs have improved this situation. Closing, but feel free to reopen or comment if the current state is still unsatisfactory.


[ALLUXIO-2595]To avoid accidental subclass extension

https://alluxio.atlassian.net/browse/ALLUXIO-2595
To avoid accidental subclass extension

alluxio-bot, check this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/14024/
Test PASSed.


Reenable MSAA for Metal

I am not sure why this code was commented, but it took me a while to understand why MSAA is not working for Metal (sample count is set to 1 for all MSAA settings). I reenabled it and it works.

cc @attilaz

git blame
https://github.com/bkaradzic/bgfx/blame/17db2f79e0aa57e0af78142223c993882a64382d/src/renderer_mtl.mm#L643

I think it was crashing for me...

@bkaradzic Ok. I will test it and see if there is any issue for me.

Before the code was commented out by https://github.com/bkaradzic/bgfx/commit/aeb8a003270b223716017e356f51fc850d9b76d6 , the original line was:
const int32_t sampleCount = 1<<(ii-1);

But now the line has been updated to:
const int32_t sampleCount = 1<<ii;

I don't know what the correct one should be, but I thought it was worth pointing this out.

1<<i looks correct. So I guess it started as a bugfix, but as there were other problems msaa got disabled.
Here is my fix for msaa capture.
https://github.com/bkaradzic/bgfx/pull/2033


[JENKINS-34534] support for gitlab-plugin 1.2.0

allowAllBraches paramater was replaced by branchFilterType
new parameter targetBranchRegex
new property gitlabConnection which sets the gitlab connection a job
should use

This breaks compatibility for users who are still using version 1.1.x of the GitLab plugin. Keep the existing options for compatibility and only generate new option when a newer version of the plugin is installed. See https://github.com/jenkinsci/job-dsl-plugin/blob/job-dsl-1.46/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/publisher/PublisherContext.groovy#L203 for an example.

For anyone having problems with DSL and the Gitlab Plugin 1.2.x, reverting to Gitlab plugin 1.1.32 is a temporary fix.

@daspilker I have update the changeset per your request. I stumbled around for a bit, but I think I got on the right track. I would appreciate if you could review the change again.

OK, cool. See my inline comments. And mark allowAllBranches as deprecated.

@daspilker updated. Let me know if there is anything else that needs to be updated/changed.

@daspilker I'm a bit confused on behavior I'm seeing. I can swear this worked yesterday.
I updated a jenkins and bunch of plugins. Additionally, I built the job-dsl-plugin from master.
DSL snippet
job.with {
  triggers {
    gitlabPush {
      buildOnMergeRequestEvents(false)
      buildOnPushEvents(true)
      enableCiSkip(true)
      setBuildDescription(true)
      addNoteOnMergeRequest(false)
      rebuildOpenMergeRequest('never')
      addVoteOnMergeRequest(false)
      useCiFeatures(true)
      branchFilterType('nameBasedFilter')
}

When I run my job-dsl job, I get the following error:
ERROR: (Trigger.groovy, line 19) No signature of method: javaposse.jobdsl.dsl.helpers.triggers.GitLabTriggerContext.branchFilterType() is applicable for argument types: (java.lang.String) values: [nameBasedFilter]
Possible solutions: setBranchFilterType(java.lang.String), getBranchFilterType()

If I change branchFilterType('nameBasedFilter') to setBranchFilterType('nameBasedFilter') per the recommendation, everything works.
The API Viewer shows branchFilterType. As a sanity check I grepped the code for setBranchFilterType and didn't get any matches.
Do you have any ideas on what might be going on?

I did some refactoring while merging, branchFilterType will be set implicitly, see
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/triggers/GitLabTriggerContext.groovy#L36
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/triggers/GitLabTriggerContext.groovy#L44
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/triggers/GitLabTriggerContext.groovy#L57

I see, makes sense. I was afraid I submitted busted code!
I didn't notice before, but there are two triggers in the api viewer:gitlabPush and gitLabPushTrigger.
gitLabPushTrigger is automatically generated. Some of the parameter names differ. Should there be any efforts to fix/update the names in the job-dsl code or will the auto generated functions be preferred?

For compatibility I'm not going to adjust the built-in DSL names.
The plan is to focus on improving the plugins (e.g. the GitLab plugin) so that the automatically generated DSL improves. And other DSLs which are use the Structs plugin, e.g. the Pipeline DSL.
One thing that needs to be improved is that most plugins use @DataBoundConstructor to declare all options. But @DataBoundConstructor defines mandatory options and in post cases the options are not mandatory and should use @DataBoundSetter instead. So currently you need to specify all options when using gitLabPushTrigger.


add missing description for solana-lattice-hash

Problem
need the description for publishing crate
Summary of Changes
add a basic one

we don't assign publish = false in https://github.com/anza-xyz/agave/pull/2204 so I assume we wanna publish it 🤔
even if we don’t publish the crate, we will face another issue because we publish solana-accounts-db, and this crate is one of its dependencies. iirc, we usually publish deps as well


Owncloud-Onlyoffice Docker behind NGINX reverse proxy connection issues

I have Owncloud 10 and OnlyOffice Documentserver running in containers with a NGINX reverse proxy. I'm getting errors when I configure the connector in Owncloud. I did wget from the Owncloud server to the Document server with no issues but when I wget from the Document server to Owncloud it tests the connection via https which succeeds and then tries to download via http which obviously isn't going to work. I think the issue is with my proxy.config but I've hit a wall. I've tried a slew of different config lines from more forums than I can count to no avail. I have connection to both servers by their FQDN from an external machine. I stripped the config file down to bare minimum that still works from an external machine and posted it below. Any guidance would be appreciated.
  upstream owncloud-server {
    server <IP_ADDRESS>:8080;
  }
  upstream document-server {
    server <IP_ADDRESS>:81;
  }
server {
  listen 443 ssl http2;
  ssl_certificate /etc/nginx/conf.d/cert.pem;
  ssl_certificate_key /etc/nginx/conf.d/key.pem;
  client_max_body_size 512M;
  location / {
     proxy_pass http://owncloud-server;
  }
}

server {
  listen 8443 ssl http2;
  server_tokens off;
  ssl_certificate /etc/nginx/conf.d/cert.pem;
  ssl_certificate_key /etc/nginx/conf.d/key.pem;
  location / {
     proxy_pass http://document-server;
  }
}

The problem can be solved by adding x_forwarded_host and x_forwarded_proto headers.
Here you can find additional information about using Document Server behind a proxy.
Examples for different web servers
Example of the config that we use in NGINX+OC+DS (docker compose)

Help me !!! I tried many ways but failed :((
https://github.com/BeShin/ownCloud-ONLYOFFICE-integration/issues/1

Hello @BeShin
Please make sure both servers can reach each other via https:

Run wget https://documentserver_address on Owncloud machine.
Run wget https://owncloud_address on Document Server machine.

Also please note that neither Document Server nor Owncloud is able to verify self-signed certificates. We strongly recommend to use CA-signed certificates. For instance, you can obtain trusted certs from Let's Encrypt for free.

Thank you to help me. I know my problem and have been fixed it. It is not problem of self-signed certificates.

Thank you to help me. I know my problem and have fixed it. It is not problem of self-signed certificates. There are a few problems when installing the onlyoffice server. I have reinstalled and run fine :)
Can you post step-by-step or config files?


Removed unnecessary if/else clause.

@ijuma Thanks :)

@ijuma Can you please have a look ? :)

Looks like this was already fixed in #2013.

@hachikuji You're right. I must not have seen it, Thanks for pointing it out.


Allow changing SMS texts via theme

I tried to configure the SMS text in the login theme. I added a line to the themes/mytheme/login/messages/messages_de.properties with smsAuthText=My new message %1$s. This new text was not used. Maybe it works with another trick, for example in the account theme. If that is the case, we should document it.

The problem was caused by a duplicated entry for ' smsAuthText`. See https://git.verdigado.com/verdigado/keycloak-themes/pulls/20


add optional policy allowing push access

what

adds the ability to give push-only access to the repository

why

full access was more than we wanted in our situation (CI pushing images to the repo) so we added a principals_push_access to give push-only access.

references

policy is based on this AWS doc

https://github.com/cloudposse/terraform-aws-ecr/issues/96

Thanks for the contribution. I'm just trying to get a second set of eyes on this to make sure it's what we want in this module.

Use distinct function for override policy document

Either we should move lambda condition to independent or add in push policy as welll
I prefer it should be independent

Use distinct function for override policy document

I'm not sure I follow. Where do you think there should be a distinct function?

Use distinct function for override policy document

I'm not sure I follow. Where do you think there should be a distinct function?

Main.tf line no 250

Use distinct function for override policy document

I'm not sure I follow. Where do you think there should be a distinct function?

Main.tf line no 250

Maybe I'm missing something but I think that would require restructuring the module so that the all (push, readonly, full)actions are combined/distinct before they get used in a policy document. That would also mean losing the sid on the different policy blocks. That would make it harder to understand the policy when looking at it from the AWS side.
Or I'm looking at the wrong thing...

i see the bridgecrew code analysis is failing but i'm not able to see the output of the job

/test all

@kpankonen  currently lambda access is granted using dynamic statements in each group and it may be problematic if someone want to create and ECR with just lambda access as resource policy. then policy might be missing because we are checking if the system has push or pull or full variables then only create not based on lambda too.

@aknysh @nitrocode is there anything else i can do to help get this merged?

@tovbinm there is an small change needs to be done

The PR has been updated to add the Lambda access policy

are any additional changes needed?

@kpankonen Apologies, but can you fix the out of date README? Do the following:
make init
make github/init
make readme

and commit the changes (if any)

@kpankonen Apologies, but can you fix the out of date README? Do the following:
make init
make github/init
make readme

and commit the changes (if any)

done!

/test all

anything else needed?

Argh @kpankonen -- we're doing you wrong here with multiple of us trying to move it forward, but then dropping the ball (we get drowned in a sea of GH notification emails as part of being on the maintainer team, so that is our excuse 😅 ).
Can you please address the conflicts or try rebasing again? Once this is ready to go, ping me here or better yet in the SweetOps slack and I will be sure to get this over the line for you. Thanks for the work and patience!

/terratest

@Gowiem updated

/terratest

@aknysh I believe we need your approval to move this forward.
FYI, I am going to do a fast follow on this PR today or tomorrow to break out the principals_lambda policies into their own policy doc so they don't need to be included with each of these full vs read vs write docs.


Issue on fargate when using ECS plugin

I think that ECS plugin is not working for fargate at least:
2018-05-23 09:13:18.951 ERROR 7 --- [ main] com.amazonaws.xray.plugins.ECSPlugin : Could not get docker container ID from hostname.
This is due to the fact that fargate container hostname is not really something that can be resolved to IP, when I had similar problem I had to fetch the IP from the task metadata endpoint

Ok, although the task meta data endpoint is accessible from within a Fargate task.  That's how solutions like Datadog can get Docker stats for Fargate containers.  You can remove from the config too.  Are the traces working, i.e. can you see segments in X-Ray?

Yea I could see traces


Exclude prefixes or folders from versioning

Object versioning can now be configured with certain exclusions (no longer strictly on a per-bucket basis). Add documentation about how to use the new options:

--excluded-prefixes to exclude objects with certain prefixes
--exclude-folders to exclude anything with name ending in / (folders)

[] Exclude prefixes
[] Exclude folders
[] Wildcards/globbing
[] Limitations
[] View versioning exclusion configuration

Fixes https://github.com/minio/docs/issues/760

@ravindk89 @djwfyi First draft for the versioning exclusion docs, very WIP. If you have a moment, comments on usual style and formatting conventions much appreciated.

Note for reviewers:
Now this PR is at a reasonable state to do a proper review. Added comments about a few things I had questions about. Not yet staged, need to try that on Monday.

Staged:
Bucket Versioning
mc version


fix: force a specific version as peerDependencies

:tada: This issue has been resolved in version 1.1.88 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Implemented Intl.Collator for ICU

This change includes a significant refactoring of Intl.js in order to simplify how we handle locale differences across ICU, Windows Globalization, and Windows National Language Support.

The locale strings used in Intl.js now all get normalized to language + script + region + collation, which is supported across all backing layers.
resolveLocaleHelper now no longer has to be passed a different default locale in different circumstances, and Collator correctly passes down the correct extension filters.
NLS locale differences are now encapsulated by the toNLS/fromNLS functions, which should be used whenever we are about to pass a string to a platform function that is backed by NLS rather than WinGlob or ICU (currently, this is only platform.getDefaultLocale and platform.compareString)

@jackhorton are we sure we want to put this in master right now? Can you check if the changes affect negatively affect chakra perf via webcrawler or perflab?

No, I am very-much-so not sure it should. @digitalinfinity thoughts on putting this into the intl-icu branch and do a big merge of intl-icu into master after DateTimeFormat finishes?

Update on this: We are back to passing 326/470 of the test262/intl402 tests in Windows Globalization (same exact tests passing both before and after this change), and I am investigating some issues that test262 exposed in the ICU implementation

Also, this PR:

fixes #4044, #4031, #4015, #3683, #3665
will soon fix #3673, #3674, #3666
adds an IntlCache class to help address #4007 and #2352
makes significant headway towards #3771

@jackhorton Add that list of issues fixed (update once finalized) to the main description so that it appears in the merge commit message and use "Fixes" before each issue number so they are all automatically closed when it is merged to master. (Although, since you're merging to a feature branch you might want to manually close them all in advance of that point in time.)

Ping to update the PR description to add the list of resolved issues.

In reply to: 341213529 [](ancestors = 341213529)

Description is updated, the first commit has the correct Fixes: list

        return r;                                                         \

For example, here a failfast is not needed because we "recover" by returning r.

Refers to: lib/Runtime/PlatformAgnostic/Platform/Common/Intl.cpp:117 in fdd8321. [](commit_id = fdd8321931e77bce8be168c877960c7d900f8d6b, deletion_comment = False)

        AssertMsg(false, u_errorName(e));                                 \

Here a failfast doesn't hurt performance because the key performance element is the check above which leads us here. This is an excellent candidate for a failfast. No reason not to, and it's a defensive coding pattern.

Refers to: lib/Runtime/PlatformAgnostic/Platform/Common/Intl.cpp:101 in fdd8321. [](commit_id = fdd8321931e77bce8be168c877960c7d900f8d6b, deletion_comment = False)


locale id of moment is different from cldr

Bug, feature request, or proposal:
Bug
What is the expected behavior?
What is the current behavior?
MomentDateAdapter use LOCAL_ID by default
  constructor(@Optional() @Inject(MAT_DATE_LOCALE) dateLocale: string) {
    super();
    this.setLocale(dateLocale || moment.locale());
  }

but, angular use cldr  spec from v5. they are different.
for example:

locale
CLDR
Moment

chinese
zh-Hans
zh-cn

cause moment.localeData can't find the locale data with that locale id.
What are the steps to reproduce?
Providing a StackBlitz/Plunker (or similar) is the best way to get the team to see your issue.
Plunker starter (using on @master): https://goo.gl/uDmqyY
StackBlitz starter (using latest npm release): https://goo.gl/wwnhMV
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Is there anything else we should know?

@vicb is there any way for us to get the old style locale ID? It seems Moment.js is not compatible with the BCP47 ones.

@mmalerba Angular should use whatever you ask him to use, no ?
I guess I'm missing context here. How is the app built ?

FYI this issue might be linked to angular/angular#20340 ?
Seems like a webpack plugin is trying to be too smart. @ocombe is working on it and will update this issue.
In the meantime @Maroon1 could you please confirm what your build process is. Thanks.

demo, run npm run serve:aot @vicb.

So @ocombe I guess what's relevant here is

"serve:aot": "ng serve --aot --local zh-hans --open",

ie CLI app. Thanks for the details @Maroon1

Hello, we've reviewed the issue and we think that we can do to things to fix this:

update the i18n docs with the list of equivalent locales (like zh-Hans / zh-cn), you can already find this list in our extraction scripts if you're curious: https://github.com/angular/angular/blob/master/tools/gulp-tasks/cldr/closure.js#L35
let user register locale data along with the locale id of their choice (if you still want to use the old locale id but need to import the locale data from angular)

@vicb @ocombe so am I correct in saying that there's nothing for material to do here other than wait for the fix in core?

The fix has been merged in the core and will be available in the 5.1 release branch.

excellent, closing this issue then


Support RTL text

My mother tongue is Persian so the feeds i have are Persian
The problem is that Twine only support text alignment for left to right languages
So the arabic typescript will show up distorted when they contain English words in their sentences

Can you include a screenshot? If the device system language is set to RTL, that should work.

Article titles appear rtl when the system language is Arabic, but the content of the articles is ltr.
while the headings and content are ltr when the system language is

Can you post the links to the feeds you are having this issue with? I can test it out and roll out a fix.

https://discourse.aosus.org/latest.rss
https://fariszr.com/index.xml

See RTL support Implementation in Read you Maybe it will help you
https://github.com/Ashinch/ReadYou/pull/378

Can you share an image that contains the right language direction for the above content so that I can verify the changes when I get to this?

Thank you for your response, I tried the latest version of github action and the result is good for both rtl and ltr, but there is a problem in displaying Code snippets, it shows rtl instead of ltr


heimdall stuff is not stripped correctly.

[x] strange thing where the entire heimdall thing came with unexpectedly (not sure how this happened)

Uncaught TypeError: Cannot read property 'registerMonitor' of undefined

[ ]   var heimdall = global.heimdall; still remains

^ was a quick fix, investigating now why it was giving me issues.

im not sure how the first example happened, I can't reproduce it myself

I think @runspired is working on some heimdal ember-cli add-on stuff.  I'll keep this disable for abit, and we can revisit soon.

Confirm, once i have a v2 to v3 compat shim for heimdall I'm going to create ember-heimdall for enabling global config of what gets stripped etc.

the plan is to create ember-heimdall for enabling global config of what gets stripped etc.

Lets have a quick chat about this?  I just want to make sure that I'm on the same page, as I am actively working on refactors to ember-cli's JS preprocessing system (e.g. to land babel@6 and utilize the new project.targets system)...

@rwjblue sounds good, I'll ping you on Slack RE this.

I'm using your<EMAIL_ADDRESS>but am seeing this heimdall error in<EMAIL_ADDRESS>The error is, "Cannot read property 'heimdall' of undefined", thrown from ember-data.js, line 17:
var loader, define, requireModule, require, requirejs;

(function (global) {
  'use strict';

  var heimdall = global.heimdall;

I will say that when I installed ember-data via ember install ember-data, I got this error when I tried to run ember s:
The Broccoli Plugin: [SourceMapConcat: Concat: Vendor /assets/vendor.js] failed with:
Error: ENOENT: no such file or directory, open '/Users/myaccount/Documents/git/myproject/ember/tmp/source_map_concat-input_base_path-f186pNbr.tmp/bower_components/ember-data/ember-data.js'

and I got past that by installing ember-data on bower too, so that in my package.json file I have
"devDependencies": {
  ...
  "ember-cli": "^2.11.1",
  ...
  "ember-data": "2.12.0",
  ...

If you have an issue with ember data please report it there. So we can track/debug/diagnose it quickly :)


ci: add image-push-master for arm64

Fixes: https://github.com/k8snetworkplumbingwg/whereabouts/issues/226
[root@master ~]# docker pull ghcr.io/k8snetworkplumbingwg/whereabouts:latest-arm64
Error response from daemon: manifest unknown

add image-push-master for arm64

Hi @dougbtv  Can you take a look? Thanks.


Update structure-controllers.md

Q
A

Is bugfix?
yes/no

New feature?
yes/no

Breaks BC?
yes/no

Tests pass?
yes/no

Fixed issues
comma-separated list of tickets # fixed by the PR, if any

您好，邮件已经收到，我会很快回复的，谢啦

错别字


module 'osmnx' has no attribute 'get_colors'

Hi,
Running into an issue with the isochrone module for osmnx. I receive the following error when setting the colors. I am using osmnx '0.13.0'

See https://osmnx.readthedocs.io/en/stable/osmnx.html#osmnx.plot.get_colors
The correct syntax as of v0.13.0 is ox.plot.get_colors()

see also https://github.com/gboeing/osmnx/issues/511#issuecomment-649669215


Match Windows Behavior Exactly?

Hello, I have an old Razer mouse that I've been using with Windows to play games for ~10 years. However, no matter how I adjust things (even using the Razer software to set it to 1000 DPI, same as Windows) it still feels completely wrong. The closest I can get it is setting acceleration to zero and DPI to ~2300.
Is there a guide to get pixel-perfect matching between Windows and MacOS for pointer and direct input (e.g., CSGO/other FPSes)? Thanks!

You may take a look at #121.
If you disable "Enhance pointer precision" (mouse acceleration) on Windows, you should be able to find a sensitivity in LinearMouse (or DPI in your Razer software) that results in pixel-perfect matching between the two operating systems. However, if "Enhance pointer precision" is enabled, pixel-perfect matching is difficult to achieve because the acceleration curves on Windows and macOS appear to be different.

("Enhance pointer precision" is disabled and Mouse speed is at the middle between slow and fast)
How can I replicate this settings in MacOS via linearmouse? There are acceleration and sensitivity options but no speed option.

There are acceleration and sensitivity options but no speed option.

The speed in Windows corresponds to the sensitivity in LinearMouse.

I set acceleration to 0 and sensitivity to 0.5, so am I correctly replicating the settings in Windows?

No, the pointer speed range in Windows and LinearMouse can differ. So the middle speed can be different as well. If you really want to replicate the settings in Windows precisely, you'll have to manually find the sensitivity as I commented here. Otherwise, keep the acceleration at 0 and tweak the sensitivity until you have a comfortable pointer speed.


Re-introduce chained sig syntax

This PR re-introduces the previously reverted chained signature syntax PR. Explanation of the chained syntax feature can be found in the original PR.
The new change in this PR that reviewers can focus on is this commit. @jez was kind enough to give us a reproduction of the error here which helped us in identifying the problem. Currently in sorbet-runtime we instantiate a new DeclBuilder every time we execute the block and finalize that builder. However, the reverted PR modified this to reuse a builder since chained syntax uses the state stored in a DeclarationBuilder.
Motivation

Chained sig syntax enables abstract to be chained into the sig parameter and makes this information available sooner, since sig blocks are evaluated lazily.
With this information at an earlier stage, it's possible to completely turn off method wrapping and unwrapping for non-abstract methods, when using default_checked_level = :never.
Test plan

I have simplified the reproduction script and added it as a test:
When we call DefineMethodWithSig.duplex() we encounter the method signature and execute it. Upon this execution we encounter the type CallsMethodUponLoading and proceed to load that class. As the name suggests this class triggers the duplex method a second time upon loading. This second trigger initiates a second signature processing for duplex method which succeeds and returns. Afterwards, we continue processing the signature due to the original method call. At this point if we reuse the previous DeclBuilder instance we'd encounter the You can't modify a signature declaration after it has been used error since the previous builder was finalized.
Here's a diagram to better conceptualize the test case:
flowchart LR
A(DuplicateSigEvalTest) -->|calls| B("DefineMethodWithSig.duplex()")
B --> |execute sig| C(CallsMethodUponLoading)
C --> |calls| D("DefineMethodWithSig.duplex()")
D --> E(finalize!)
E --> |done| F[return]
F --> G(finalize!)
B --> |waiting| G
G --> |done| H[return]

cc @vinistock

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_LL1sZsa9n8AR0C
→ https://go/builds/bui_LL1s1nYMk9zWGd

(FWIW, the suggested reproducer on stripe's infrastructure is to require a specific file, then force running all sig blocks via T::Utils.run_all_sig_blocks, which might also be enlightening on something like Shopify's codebase--but maybe you already tested on that...)

PR #5641 should have a failing testcase similar to at least one of the failures in Stripe's codebase.  On that branch:
st-froydnj1:sorbet froydnj$ cd gems/sorbet-runtime/
st-froydnj1:sorbet-runtime froydnj$ bundle exec ruby main.rb
st-froydnj1:sorbet-runtime froydnj$

with this PR:
st-froydnj1:sorbet-runtime froydnj$ bundle exec ruby main.rb
Traceback (most recent call last):
	57: from main.rb:17:in `<main>'
	56: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:258:in `block in _on_method_added'
	55: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:447:in `maybe_run_sig_block_for_key'
	54: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:467:in `run_sig_block_for_key'
	53: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:248:in `block in _on_method_added'
	52: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:338:in `run_sig'
	51: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:361:in `run_builder'
	50: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:71:in `run!'
	49: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:71:in `instance_exec'
	48: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/ms.rb:10:in `block in <class:M>'
	47: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/ms.rb:10:in `require'
	46: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:1:in `<top (required)>'
	45: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:2:in `<module:Repro>'
	44: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:3:in `<class:D1>'
	43: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:3:in `require'
	42: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:1:in `<top (required)>'
	41: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:2:in `<module:Repro>'
	40: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:3:in `<module:D2>'
	39: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:3:in `new'
	38: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
	37: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation.rb:161:in `validate_call'
	36: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation.rb:161:in `bind_call'
	35: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:25:in `initialize'
	34: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:258:in `block in _on_method_added'
	33: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:447:in `maybe_run_sig_block_for_key'
	32: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:467:in `run_sig_block_for_key'
	31: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:248:in `block in _on_method_added'
	30: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:346:in `run_sig'
	29: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:397:in `build_sig'
	28: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:397:in `new'
	27: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/signature.rb:47:in `initialize'
	26: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/utils.rb:8:in `coerce'
	25: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/types/type_alias.rb:13:in `aliased_type'
	24: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:13:in `block in <class:HC>'
	23: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/_types.rb:36:in `nilable'
	22: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/utils.rb:8:in `coerce'
	21: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/types/type_alias.rb:13:in `aliased_type'
	20: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:6:in `block in <class:HC>'
	19: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:6:in `require'
	18: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:1:in `<top (required)>'
	17: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:2:in `<module:Repro>'
	16: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:12:in `<class:I>'
	15: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:6:in `make'
	14: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:6:in `new'
	13: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation_2_7.rb:389:in `block in create_validator_procedure_fast0'
	12: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation_2_7.rb:389:in `bind_call'
	11: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:25:in `initialize'
	10: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:258:in `block in _on_method_added'
	 9: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:447:in `maybe_run_sig_block_for_key'
	 8: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:467:in `run_sig_block_for_key'
	 7: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:248:in `block in _on_method_added'
	 6: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:338:in `run_sig'
	 5: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:361:in `run_builder'
	 4: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:71:in `run!'
	 3: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:71:in `instance_exec'
	 2: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:17:in `block in <class:HC>'
	 1: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:93:in `returns'
/Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:28:in `check_live!': You can't modify a signature declaration after it has been used. (T::Private::Methods::DeclBuilder::BuilderError)
	54: from main.rb:17:in `<main>'
	53: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:258:in `block in _on_method_added'
	52: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:447:in `maybe_run_sig_block_for_key'
	51: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:467:in `run_sig_block_for_key'
	50: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:248:in `block in _on_method_added'
	49: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:338:in `run_sig'
	48: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:361:in `run_builder'
	47: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:71:in `run!'
	46: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/decl_builder.rb:71:in `instance_exec'
	45: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/ms.rb:10:in `block in <class:M>'
	44: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/ms.rb:10:in `require'
	43: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:1:in `<top (required)>'
	42: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:2:in `<module:Repro>'
	41: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:3:in `<class:D1>'
	40: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d1.rb:3:in `require'
	39: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:1:in `<top (required)>'
	38: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:2:in `<module:Repro>'
	37: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:3:in `<module:D2>'
	36: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/d2.rb:3:in `new'
	35: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
	34: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation.rb:161:in `validate_call'
	33: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation.rb:161:in `bind_call'
	32: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:25:in `initialize'
	31: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:258:in `block in _on_method_added'
	30: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:447:in `maybe_run_sig_block_for_key'
	29: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:467:in `run_sig_block_for_key'
	28: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:248:in `block in _on_method_added'
	27: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:346:in `run_sig'
	26: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:397:in `build_sig'
	25: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:397:in `new'
	24: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/signature.rb:47:in `initialize'
	23: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/utils.rb:8:in `coerce'
	22: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/types/type_alias.rb:13:in `aliased_type'
	21: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:13:in `block in <class:HC>'
	20: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/_types.rb:36:in `nilable'
	19: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/utils.rb:8:in `coerce'
	18: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/types/type_alias.rb:13:in `aliased_type'
	17: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:6:in `block in <class:HC>'
	16: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:6:in `require'
	15: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:1:in `<top (required)>'
	14: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:2:in `<module:Repro>'
	13: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:12:in `<class:I>'
	12: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:6:in `make'
	11: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/i.rb:6:in `new'
	10: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation_2_7.rb:389:in `block in create_validator_procedure_fast0'
	 9: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/call_validation_2_7.rb:389:in `bind_call'
	 8: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:25:in `initialize'
	 7: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:258:in `block in _on_method_added'
	 6: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:447:in `maybe_run_sig_block_for_key'
	 5: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:467:in `run_sig_block_for_key'
	 4: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:248:in `block in _on_method_added'
	 3: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:337:in `run_sig'
	 2: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/private/methods/_methods.rb:340:in `rescue in run_sig'
	 1: from /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/configuration.rb:202:in `sig_builder_error_handler'
/Users/froydnj/stripe/sorbet/gems/sorbet-runtime/lib/types/configuration.rb:195:in `sig_builder_error_handler_default': /Users/froydnj/stripe/sorbet/gems/sorbet-runtime/hc.rb:17: Error interpreting `sig`: (ArgumentError)
  You can't modify a signature declaration after it has been used.

@froydnj Given the lazy evaluation of type_alias your last repro was hard to get around with our existing solutions in mind. As a result we ended up going back to how it's currently processed in Sorbet. Only difference being the duplication of the internal decl state to keep it persistent between the multiple instances of DeclBuilder: https://github.com/sorbet/sorbet/pull/5329/commits/f8c8386cef3c59714ef1ee591e0a2d28d406f145
I also have a CI linter failure but couldn't replicate it locally.

Green test on Stripe's CI: http://go/builds/bui_NmnpNMSzpFHw0r
It doesn't look like this PR noticeably affects test performance (one datapoint is a not a great way to measure this, but at least the performance of the above run was not noticeably different from historical data over the last week or so).

@froydnj I addressed your latest rewriter comments, there are still some discussions points from earlier. Also this PR is growing quite large with conflicting commits. Let me know if you'd like me to clean up the git history (undo the revert revert and make atomic commits) before reviewing. Thank you!

Our test script failed to post a comment, here's the link for Stripe employees:
https://cibot.corp.stripe.com/builds/pay-server--bui_PkA6P0eGxlm9Tc


Allow custom script execution when provisioning nodes

For my use case I would like to create a single ARM template which deploys an ACS cluster (DC/OS orchestrator) and some additional services directly provisioned on top of Marathon.
I've tried to add an Custom Script Extension to the Mesos master. This works although there is no way to resolve the VM's resource name due to generated 8 HEX string to make the resources unique.
Issue #53 would solve this particular problem, but I think it would be cleaner if it's somehow possible  to provide an reference to a script.

Will it solve your case, if you writing your code in parts/dcosprovision.sh?  This runs on both Master and Agent.

That will work for sure. Any guidance of how to determine if it's currently running on a master or agent? In my case I would like to only run it once on the first master node (curl a Marathon app in json format)

For DCOS, there is a custom script extension that runs on the last master.  If this doesn't complete, it will fail the deployment.  You can wire in your changes to that master custom script extension to confirm it has successfully run.

Closing since this was a question.  Please re-open if this is not fully answered.  I've tagged with wontfix, since I'll leave this as a customer enhancement.


Fixed possession typos

Nice repo! Thought I'd contribute ;)
Related issue: #128

Thanks!
Did you pull the project from the develop or the main branch? The primary branch is the main branch (for users) but some changes have already be made to the develop branch, so please pull that and also open a pull request to merge into that branch.

Ah yeah I branched from main. Will fix it

@Alek050 This should be correct, can you check again


cursor blinks on ios

https://youtu.be/4mwK8Wyun6Q
Cursor blinks when I typing on Input or Textarea
How to fix this issue?
When I uninstalled cordova-plugin-ionic-webview, everything is fine,
but I have to use cordova-plugin-ionic-webview because of some other ios issues.
I use cordova-plugin-ionic-webview 4.0.0. and platform version is<EMAIL_ADDRESS>How to fix this issue?
cli packages: (/Users/----/.nvm/versions/node/v8.11.1/lib/node_modules)
@ionic/cli-utils  : 1.19.2
ionic (Ionic CLI) : 3.20.0
global packages:
cordova (Cordova CLI) : 8.1.2<EMAIL_ADDRESS>local packages:
@ionic/app-scripts : 3.2.2
Cordova Platforms  : android 6.3.0 ios 4.4.0
Ionic Framework    : ionic-angular 3.9.2
System:
Android SDK Tools : 26.1.1
ios-deploy        : 1.9.4
Node              : v8.11.1
npm               : 5.6.0
OS                : macOS
Xcode             : Xcode 10.1 Build version 10B61
Environment Variables:
ANDROID_HOME : /Users/mingyu/Library/Android/sdk
Misc:
backend : pro

What's the problem with this?
I've checked some native apps and the cursor always blinks, why do you want/need to prevent it?

@jcesarmobile
when I input text first letter, text blinks and shows placeholder even if text exists.
see video

Ah, I understand it now, you mean the placeholder appearing and disappearing even when there are some characters.
Anyway, this is a problem on Safari itself, you should report it to Apple/Webkit, there is nothing we can do about it. If you report it to them, mention that you are using Korean keyboard, as it doesn't happen with other languages where a keystroke is a character, while in Korean keyboard the first character can be replaced by a second one depending on the next char you tap, and that's what causes the placeholder to appear while current character is being replaced.


Upgrade to .NET 8.0

Describe the feature you're suggesting.
.NET 6.0 and 7.0 are being deprecated. .NET 8.0 is the latest LTS version that the app needs to be updated to

Completed in https://github.com/CriticalFlaw/TF2HUD.Editor/commit/c2852ea879398de56f8f0b553f6f5952ebc74cde


[BUG] Restore of Snapshot taken from a 3 node cluster fails.

Describe the bug
We have a 3 node opensearch cluster. When I take a snapshot of the opensearch and opendistro indices and check the snapshot, the snapshot does not have any failed shards:
{"snapshots":[{"snapshot":"2","uuid":"vCkI0dAMTxqmOPE3yF_Rfw","version_id":136357827,"version":"2.14.0","remote_store_index_shallow_copy":false,"indices":[".opendistro-alerting-alert-history-2024.06.11-1",".opensearch-notifications-config",".opendistro-alerting-alerts",".kibana_1",".opendistro-reports-instances",".opendistro-alerting-config",".opendistro-reports-definitions"],"data_streams":[],"include_global_state":false,"state":"SUCCESS","start_time":"2024-06-11T07:33:00.126Z","start_time_in_millis":1718091180126,"end_time":"2024-06-11T07:33:00.326Z","end_time_in_millis":1718091180326,"duration_in_millis":200,"failures":[],"shards":{"total":7,"failed":0,"successful":7}}]}
However, when I try to restore the same snapshot on the same 3 node cluster,  I see that some shards have failed.
{"snapshot":{"snapshot":"2","indices":[".opendistro-alerting-alert-history-2024.06.11-1",".opendistro-alerting-alerts",".opendistro-reports-definitions",".kibana_1",".opendistro-reports-instances",".opensearch-notifications-config",".opendistro-alerting-config"],"shards":{"total":7,"failed":3,"successful":4}}}
The opensearch logs say that the snapshot is missing:
[2024-06-12T09:20:00,612][WARN ][o.o.s.InternalSnapshotsInfoService] [opensearch-cluster-master-0] failed to retrieve shard size for [snapshot=nsp-opensearch-repository:2/vCkI0dAMTxqmOPE3yF_Rfw, index=[.opendistro-alerting-alerts/FLxs5PqsSTOF7NqmUF-0NA], shard=[.opendistro-alerting-alerts][0]]
org.opensearch.snapshots.SnapshotMissingException: [nsp-opensearch-repository:2] is missing
at org.opensearch.repositories.blobstore.BlobStoreRepository.loadShardSnapshot(BlobStoreRepository.java:3556) ~[opensearch-2.14.0.jar:2.14.0]
at org.opensearch.repositories.blobstore.BlobStoreRepository.getShardSnapshotStatus(BlobStoreRepository.java:3356) ~[opensearch-2.14.0.jar:2.14.0]
at org.opensearch.snapshots.InternalSnapshotsInfoService$FetchingSnapshotShardSizeRunnable.doRun(InternalSnapshotsInfoService.java:241) [opensearch-2.14.0.jar:2.14.0]
at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:913) [opensearch-2.14.0.jar:2.14.0]
at org.opensearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:52) [opensearch-2.14.0.jar:2.14.0]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) [?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) [?:?]
at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
However, I have manually copied the backup files to the pod at the path registered in the repository.
We don't have a shared file system but we make sure to manually copy the snapshot files to all the nodes.
I wanted to clarify two things.

Is it advisable to backup and restore these indices?
How does opensearch restore process handle index that have multiple primary and replica shards.

We have the same issue with another set of application specific indices that have multiple primary and replica shards.
Related component
Storage:Snapshots
To Reproduce

Take a snapshot of an opensearch cluster consisting of multiple nodes
Restore the snapshot on the same node.

Expected behavior
The snapshot should get restored successfully without any shard failures.
Additional Details
No response

[Storage Triage - attendees 1 2 3 4 5 6 7 8 9 10 ]
@@manoj0598

Is it advisable to backup and restore these indices?

Repository has to be shared across all the nodes in the cluster . If you copy the data manually , the behavior is undefined .

How does opensearch restore process handle index that have multiple primary and replica shards.

Snapshot stores and restores the data on per shard basis . Replica shards starts hydrating post the primary shards via peer recovery mechanism .


Pg pool

In This PR

Using pg-pool

All models follow the form:
return Promise((resolve, reject) => {
  db.query(sql, [params...], functionToInstantiateObjectFromDBRow)
  .then(resolve)
  .catch(reject);
});

Updates to controllers were made as necessary.
TODO:

[ ] Check thoroughly on staging

Checks out on staging!

Thanks @btmills


create new core tool for serving up a RESTful endpoint for managing multiple instances of vent

closing as no new activity in over 2 years.


Update PyQUBO version to 1.3.1

PyQUBO version 1.3.0 is released. This version is compatible with dimod 0.11.x.
https://github.com/recruit-communications/pyqubo/releases/tag/1.3.0

@arcondello We recently released PyQUBO 1.3.0 which supports dimod 0.11.x. I would appreciate it if you could review it.

Hi @kotarotanahashi we actually just released dimod 0.12.0 today. I believe support should be straightforward.

@arcondello I see it! I'll update PyQUBO to support the latest version of dimod. Thank you.

@arcondello I updated PyQUBO to support dimod 0.12.x. in the latest PyQUBO v1.3.1 (https://github.com/recruit-communications/pyqubo/releases/tag/1.3.1) Thank you!


Update README

What :computer:

Added cargo installation command to README.md file.

Why :hand:

To install Rust easily

We rather point to the official rust docs. Thanks tho!


NVDA does not read message from showInformationMessage()

Issue Type: Bug
Extension uses vscode.window.showInformationMessage to show a notification. User tries to use NVDA to read it.
Expected: NVDA can read the notification.
Actual: NVDA cannot read the notification.
VS Code version: Code 1.25.1 (1dfc5e557209371715f655691b1235b6b26a06be, 2018-07-11T15:43:53.668Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 x 3408)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
31.92GB (23.39GB free)

Process Argv
C:\Program Files\Microsoft VS Code\Code.exe

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

cpptools
ms-
0.17.7

vsliveshare
ms-
0.3.472

@IlyaBiryukov steps to reproduce please, every notification in VSCode is alerted to NVDA, extensions make no difference.

The bug originally came in the accessibility test pass of Live Share.
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/646335

@IlyaBiryukov I cannot reproduce when I try with a simple "Hello World" notification:

At this point, please try to produce a minimal reproducible sample for me to test.

@bpasero Can we please reopen this?  Here are the steps to reproduce:

Download Live Share extension for VSCode
Go to the "share" icon in the status bar, click it, and sign in to start a collaboration session
Click the name icon in the status bar

Select "share server" in the quick pick menu that appears
Type any number in "Enter port to expose..."
A notification will appear saying "Exposed local TCP port 3000...".  This notification is not announced by the screen reader.

Note that this doesn't happen for all notifications, just this one that appears following the input box.

@cait1inhennessy I cannot reproduce with the steps provided. Using NVDA speech viewer I get this:

So there must be some configuration issue on where this was tested.

@bpasero Thanks!


Porting old 1.6 prs

This PR is cherry-picking the following PRs that were previously merged into feat-1.6 branch

#3967
#3978, but it turns out it was noop as it was likely ported in #4732
#4082 and #4305

Just using as a test for CI working

bors try

bors r+

bors r+

bors r+


Update of belarusian interface translations by Zmitr

Belarusian translation is corrected

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 5.046%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
129

Relevant Lines:
2944

💛  - Coveralls


How does this method perform if training without Reliability Map?

Hello. Thank you for your nice work and contribution of field.
I have some questions.

How does this method perform if training without Reliability Map?
Since the method detected keypoints with simple network(only 4 1*1 conv), did you validate some metric about keypoint detection, e.g. Repeatability?

I look forward to your reply and thank you for your excellent work!

Hi @weich37, thank you for your interest in our work!
Q1: For semi-dense matching, you can match the full (dense) descriptor map without filtering based on reliability (no need to train with a reliability map). This should provide the densest matching, but the inlier ratio (#correct/#total) may decrease, and the matching cost will increase.
Q2: We did not check keypoint repeatability because it does not always correlate well with downstream task performance. Instead, we directly evaluated the keypoints/descriptors on downstream tasks such as camera pose, homography estimation, and visual localization.

Thank you


perf(vite): cache repeated manifest access

🔗 Linked issue

❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[x] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR caches each key in the client manifest to improve performance and decrease the manifest handling time. Tested with core-js package.json file, the results speak for themselves:

📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

(The failing test has nothing to do with the PR whatsoever, and might be worth fixing in the test case itself)

This is run once after the vite build, and iterates over every file emitted from the vite client build.
I would not imagine there is a significant difference in time between 6x accesses of a deep property and 1x access of deep property and 5x one level less. But I'm happy to be proved wrong.
How did you run the test in the issue?

@danielroe
clientManifest is the core-js package-lock.json file (won't paste it here because it's too large), BASE_RE is new RegExp('abcde')
Rest of the code is:
repeatedIndex: the same as the current file
cachedAccess: this PR
Same goes with all my perf PR's


Generation for k8s 1.19 to k8s-alpha repo

Just wondering if this will be done soon, or should we just use 1.18 meanwhile?

I added Kubernetes 1.19 in https://github.com/jsonnet-libs/k8s-alpha/commit/46e45906958567cdbc1b3bde181ef8bc4afb877d

Thanks!


Text "Bingo Item" disappears from all items and blocks

Currently, there are max 25 items and blocks on the bingo card. Each of them has the text "Bingo Item" in its tooltip. When you obtain any of the required items or blocks in any way, the text "Bingo Item" disappears but not only from the item or block you've just obtained but from all of them. It shouldn't behave like this, I think.
For more context, look at these pictures and their descriptions:

At first:

As you can see in this picture, both stone and granite have the text "Bingo Item" in their tooltips (as they are on my bingo card, among others of course).

Afterwards:

After picking up only one of them (e.g. stone), the text "Bingo Item" disappeared from both tooltips, but should've disappeared from only one of them (i.e. from stone, since I picked up only it). I don't think it should behave like this, hence my issue report.

This issue occurs on the following configuration (I didn't test other configs):

Minecraft version: 1.16.4
Bongo version: 1.0.4
LibX version: 1.0.6
Forge version: 35.1.4

Could you post some screenshots?

At first:

As you can see in this picture, both stone and granite have the text "Bingo Item" in their tooltips (as they are on my bingo card, among others of course).
Afterwards:

After picking up only one of them (e.g. stone), the text "Bingo Item" disappeared from both tooltips, but should've disappeared from only one of them (i.e. from stone, since I picked up only it). I don't think it should behave like this, hence my issue report.

Pictures added.

Now the text "Bingo Item" remains forever on all tooltips of the items and blocks that are on the Bingo card. Was it supposed to work like this from the beginning?

Now the text "Bingo Item" is displayed all the time in all tooltips of the items and blocks that are on the Bingo card. Was it supposed to work like this from the beginning?

Yeah the tooltip was initially added to easily filter bingo items in JEI. But when you always see what you're missing in JEI this is a bit too easy I think. That's why it's always shown on all 25 items so you still need to find your specific item from a list of 25.

Fair enough. Thank you for the explanation.


Non-error slicing

In Python and JavaScript, there's a function vec.slice that never throws an error:
vec.slice(x, -y)

means "remove the first x elements from the start and the first y elements from the end". Rust currently throws an error if x is greater than vec.len() - 1. It returns an empty vec when the span includes no elements: that's what you want for many use cases.
It's convenient to do Python/JavaScript like accesses as an idiomatic version of takeing and droping (in the Haskell sense) in Rust.
For clarity, here is an example implementation:
fn slice_vec<T>(vec: &[T], start: isize, end: isize) -> &[T] {
    let len = vec.len() as isize;
    let start = if start >= 0 { start } else { len + start };
    let end = if end >= 0 { end } else { len + end };
    let start = start.max(0) as usize;
    let end = end.min(len).max(start) as usize;
    &vec[start..end]
}

The use of isize looks really unergonomic to me, since both arguments in that example are unsigned (more precisely, start and -end  are always nonnegative in the interesting case). Using an unsigned input simplifies some of those branches, and you can use saturating_sub if you are doing a subtraction to produce the result and want to stop at 0.

Python's signed slicing can cause some real gotchas, like what do you think this returns for b=""?
def endwith(a: str, b: str) -> bool {
     return a[-len(b):] == b

A better approach would be a special const END value that allows you to do slicing like vec[0..END-1]
pub struct FromEnd(usize);
pub const END: FromEnd = FromEnd(0);
impl SliceIndex for FromEnd { .. };
impl Sub<usize> for FromEnd { .. };
// etc

@FHTMitchell ops::Range requires both fields to have the same index. Implementing this would probably require a new conversion trait:

Declare trait IntoRangeBound<T>, implement the blanket T: IntoRangeBound<T>
Implement usize: IntoRangeBound<FromStartOrEnd>
Desugar a..b as ops::Range { start: IntoRangeBound::into(a), end: IntoRangeBound::into(b) }

Type inference seems to work: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=c067c8bf3600fc6c2e5f1c4411b7a4aa

@SOF3  Ah good point. Such a conversion trait would probably break inference though :(
How would the compiler know you want 0usize..5usize to be IntoRangBound<usize> or IntoRangeBound<FromStartOrEnd>?

what about just using an enum with Start and End variants? there's no strict need to make it work with two different types together.

In my experience, most of the time when .slice() is used in JS, you only want to remove items from the start OR the end, but not both. So two functions – slice.remove_first(n) and slice.remove_last(n) would suffice for most use cases.
These names are pretty much self-explaining, while the syntax proposed in the RFC could be very confusing. That something.slice(0, -5) removes the last 5 elements is far from obvious to anyone not familiar with JS or Python.
If you want to remove items both from the start and the end of the slice, you could write something.remove_first(m).remove_last(n) – which is less concise than something.slice(m, -n), but I think it is easier to understand.

Should this issue be named signed slicing instead of non-error slicing?

Python's string slicing is so fabled for its error-prone, surprising behavior that university professors, in my experience, use it as prime example of a poorly-designed API.
A feature like this one is best experimented with by publishing a public crate. @FHTMitchell posted an example of how this might work without changes to the standard library.


Remove npm cache clean from Makefile

As of npm@5, the npm cache self-heals from corruption issues and data extracted from the cache is guaranteed to be valid.

Coverage remained the same at 96.396% when pulling 7197886d4cc9264bea9e7f2114134ab27bd4f232 on remove-npm-cache-clean into 4b6e621365da5c95101324cdef16855df68739d9 on master.

Does this mean we all have to use npm 5 to publish docs though?

@matthewp No, you don’t have to use npm 5. Obviously if you’re still on <5, you can run npm cache clean before running make. I’m the one who added it to Makefile, and I’m not 100% sure why given that none of our other Makefiles include it, so I think it’s safe to remove.

👍


Revisit conversation on exposing stack outputs client

https://github.com/aws-amplify/samsara-cli/pull/261#discussion_r1333457152
This conversation was intentionally left unresolved to be revisited.
The PR for the comment thread introduces a utility that allows access to stack outputs.
At the time the PR was introduced, the only way to access output data conveniently was through the client-config package.
This effectively required all data used at runtime to be persisted in the client config file as well. Because the client config file has specific use cases for the amplify libraries, this was suboptimal.
Before release, we should revisit the exposed client in this PR and reevaluate the level of abstraction that the client operates at.

We're leaving the deployed backend client api in current shape.


Added ability to select cells by blinking

https://github.com/willowtreeapps/vocable-ios/issues/452
Description of Work
Description

Added the ability for users to select cells or buttons by blinking.

Since the blink conforms to UIGestureRecognizer, the user has the ability to start, end, and cancel the gesture.
Temporarily, I added a variable inside AppConfig.swift to toggle between hovering and blinking.
Provisioning needs to be fixed since I am an external user.

Notes to Test (Optional)
Notes

@Clstroud I filled out the Join our Slack form, but I haven't received an invitation and it seems my old account was deactivated. Would you be able to ask IT if I can be added as a guest to that external channel? I'm interested in contributing in my spare time 🙏

@Clstroud I filled out the Join our Slack form, but I haven't received an invitation and it seems my old account was deactivated. Would you be able to ask IT if I can be added as a guest to that external channel? I'm interested in contributing in my spare time 🙏

Hey Patrick, trying to get you added.


Support for incremental output

I want to parse a huge, but regular document. Tabula correctly parses the 1st page, but using --pages all causes it to consume a huge amount of memory as, I guess, it tries to do processing considering every page before starting to parse, which would be the right thing to do on arbitrary file.
It seems that running tabula once on every page and appending the output to a csv would run a lot faster and on much less resources.
Considering that it easily goes beyond 8GB of ram (~5500 pages), and causes the jvm's gc to go crazy, there should be an option to just parse the pages individually and incrementally (printing to stdout asap).

Hi @Dietr1ch,
That's something that we'd also like to implement. However, AFAICT, there's no way to avoid reading all the pages in a PDF with PDFBox 1.8. Until we finish the migration to PDFBox 2.0 (#52), I suggest that you split the PDF in smaller chunks with (with pdftk, for example) and process them separately.

Thanks for the quick response.
I was trying this, but it also seems much slower than it should.
for p in (seq (pdf-pageCount doc.pdf))
    java -jar target/tabula-0.9.1-jar-with-dependencies.jar  --pages=$p doc.pdf >> doc.csv
end

(pdf-pageCount just filters the output of pdfinfo)
It seems that #52 blocks this.

Leaving a comment to bump this issue. Now that #52 is closed, we should be able to implement this.


Fix issue select[multiple] overflowing container

Added overflow: scroll to select[multiple].form-control class to fix options overflowing container.
Before

After

Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED
Commit: 437f7974c25c185c289470d5d3c763781f4ea3f4
Build details: https://travis-ci.org/twbs-savage/bootstrap/builds/156715265
Docs preview: http://preview.twbsapps.com/c/${commitSha.sha}
(Please note that this is a fully automated comment.)

Refs #20384.

That issue concerns Bootstrap 4, but this patch is against Bootstrap 3.
Did you accidentally choose the wrong branch?

Yes, I did! So should we close this PR out and I'll create a new one on v4-dev?

Closing out then.
#20428 will fix this in v4.


Active node updates when individual module added to my_modules list

When an individual module is added or removed from the my_modules list using the buttons on the module_details panel, the active_node is updated to be Bash: Combining Commands

This still seems to be happening sporadically. More investigation is needed!

New data: This occurs on @rosemm's computer when running the main branch in a docker container, but not on my computer when running the main branch in a docker container. That fact makes it even weirder since running the same thing in docker containers should be identical.

More data: didn't occur on @pm0kjp 's docker container, but later did occur on mine making me think this is something about how long the app is running for or how many times things have been added or removed from various lists.

This may have been resolve in the network_analysis branch that is live on learn.arcus.chop.edu. Some changes were made to how the active node updates which may have fixed this problem.

This problem has not been fully fixed, removing a module from the pathway resets the active node to bash_combining_commands.


Bern Features: Category annotations do not show up in the list auf annotations

They show up in the track, but not the list. When I try to reload the page, the tool does not oben at all (see screenshot).

Have you seen this issue? It does still appear.

This was indeed an issue with the SWITCHcast fork. I can't point to any commit in this repo, but it should be fixed on their side now.

Looks fine and can be closed.

Fixed.

Fixed.


Get Rita serving on HTTPS

Using https on the frontend over https
In order for the browser to be allowed to make api calls, Rita needs to be using the same cert
Or maybe proxy everything thru nginx

To get the frontend running on https I installed px5g and rebooted uhttpd. It then generated a cert at /etc/uhttpd.crt
I was looking into getting actix to read the crt and use it to serve the client dashboard API over https but the example I was looking at was using PEM format whereas the cert that uhttpd generated was DER. It also complained about a missing bind_ssl method. I wonder if installing the openssl crate might fix that.
I also considered installing nginx instead of uhttpd to setup a reverse proxy but the nginx opkg doesn't come with ssl support out of the box. There is a nginx-ssl custom feed or you can use make menuconfig to tick off the Enable SSL box for nginx.

This is the actix ssl example I was looking at: https://github.com/actix/actix-website/blob/master/examples/server/src/ssl.rs

Research how to do it and evaluate the options on Monday 2018-10-22

Obstacles

Making this a smooth experience for the user. If we create a cert and self-sign it it'll probably keep telling people that their connection is not safe and that they need a security exception.
Actualy doing it in actix-web : there's an example that appears to do what we want so we're probably okay in that department https://github.com/actix/examples/blob/master/tls/src/main.rs

completion of pull request 2018-10-23

as for 2018-10-25 the pull request still does not pass tests.