Leverage user supplied secrets directly from cloudprovider

Currently, the only way to get tls certs into a cloudprovider ingress is by creating a Kubernetes secret.
Currently, Kubernetes secrets are not encrypted.
We should allow users to directly create a secret in the cloudprovider and pass it through an annotation on the Ingress. We already do this for kubernetes.io/ingress.global-static-ip-name
See https://github.com/kubernetes/contrib/issues/2095 for more context.
We also need a way to do this with nginx, where one might want to store the cert in eg: GCS and pass down a URL from where the controller downloads it. I think all cloudrpovider backends will also understand URL as long as it points to an existing ssl cert resource in the cloud.

I am happy to take this on and do the work for connecting Ingress's TLS requirement to GCP's compute ssl-certificate resource.
Can I get some confirmation that:

This would be a good place to check for the existence of an annotation
Source the cert via a new annotations.allowNamedTLS(tls) function here
Cert creation currently happens here.

Or is there a better place to fetch an existing GCP cert + use that for the Ingress' cert?

Also to confirm that I should do the work in this repo instead of https://github.com/kubernetes/contrib/tree/master/ingress?

Also to confirm that I should do the work in this repo instead of

Yes. Please work in this repository for any PR/issue related to Ingress.

The preliminary work is here: https://github.com/kubernetes/ingress/compare/master...tonglil:gce-tls
Please help me with suggestions/recommendations (or tell me I'm doing this completely wrong), this is my first change, a feature to ensure developers aren't handed wildcard certs.
I am having some trouble:

replacing the SSL cert of the HTTPS target proxy in GCP if the user also specifies a tls secret (spec.tls.secretName).
If the user does not specify a tls secret in the Ingress spec, but uses a GCP ssl cert, the only port that shows up in kubectl get ingress is 80.

Questions:

should the cert resource be referenced by "name" or the "selfLink" url (as suggested above)? Current implementation is the "name" in GCP because it is what the current interface understands.
should I rename the annotation to be GCP specific (like kubernetes.io/ingress.gcp-use-named-tls?

Are you asking about what wins, annotation vs api tls cert? We should validate against both being set, then the first one wins, and if they try to create with both set the create fails.

Name is friendlier, and certs are global so the self-link can easily be reconstructed

We should follow examples in the main repo. I suppose the named cert annotation applies for all cloudproviders, so including gcp in there will require an aws-use/digital-ocean-use etc. Why not just call it something generic like ssl-cert and allow the controller to interpret that as it sees fit (eg: the nginx controller could use that as a pointer into gce as well, if it wanted to, or into aws, or into some external vault store).

Gotcha, thanks. I understand that requirement now. The code currently thrashes between the cert specified in the annotation and the api. Should I change it so the user can only specify one?

(aka a.) Thank you for clarifying, I will continue to use the "name".

(aka b.). "kubernetes.io/ingress.ssl-cert" sounds like a good name, I'll update it to that. I agree, cloud provider specific annotation is bad, I was considering it based on this: https://kubernetes.io/docs/user-guide/services/#ssl-support-on-aws

I'll think a bit about the annotation. We should be consistent with main repo. I think there were guidelines somewhere about annotation naming convention, will try to find it.
Re: "fail if both are set", I was recommending validating that both aren't set, i.e here: https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/extensions/validation/validation.go#L337.
Also we probably don't want to call it "ssl-cert" but something like "external-ssl-cert". Make this a const and we can go back and forth on the name at the final round.

I read the guidelines, it is here: https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#label-selector-and-annotation-conventions
Const w/ external-ssl-cert sounds good to me, will do!

Thanks for the validation link, I wasn't sure where to do the validation (initially I thought either in controller.go or tls.go, but I think your link is the right place).

@tonglil meet @nicksardo, who also volunteered to help with implementation/code-review/e2e testing etc.
I took a quick look at your tree in https://github.com/kubernetes/ingress/issues/45#issuecomment-275785495 and the diff looks reasonable.
Regarding validation, I think you'll have to stick the const annotation in the main repo and reference it through the vendored dep, maybe put it in pkg/apis/extensions/annotations? (since we have both a pkg/api/annotations and a pkg/api/services/annotations, though neither seems appropriate). Then you can import it in the gce controller via "k8s.io/pkg/apis/extensions/annotations"
We will also have to add an e2e to validate this behavior. All ingress e2es are here: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/ingress.go
If you can make this a cross-platform annotation (i.e nginx controller also reads gce-ssl-cert annotation), then the right place to add a test is in the conformance suite: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/ingress_utils.go#L121
Otherwise, if we want to start with something GCE specific, add a test like the static-ip test: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/ingress.go#L128 and a TODO to implement it on all platforms

Also I'm still on the fence about naming (particularly, should we embed the name of the storage medium in the annotation, eg gce-ssl-cert, or let the controller decide where to look, eg first look at cloudprovider for ssl-cert with matching name, then look in /etc/ssl then...). Maybe @thockin has some thoughts.

How about ingress.kubernetes.io/pre-shared-cert=<something meaningful to the controller>.  On GCP that is the name of a certificate resource.  On the hypothetical Nginx with GCS it is a GCS URL, etc.

For GKE, it could be the "name".
For Nginx, it would either be specified as a URL (which can be parsed for that case), or a directory name (which can then be parsed differently).

Thanks @bprashanth for pointing me in the right direction and @nicksardo.
I will work on the validation and then see about the e2e tests.

One of the things I am still unable to achieve is that if the user leaves the tls secret in the Ingress spec empty, but completes the annotation, the only port that shows up in kubectl get ingress is 80.

I think everything in the loadbalancer pool just checks L7runtimeinfo.TLS.*, so if you populate that up front with the right values, things should fall into place (eg https://github.com/kubernetes/ingress/blob/master/controllers/gce/loadbalancers/loadbalancers.go#L357).
So I'm suggesting doing https://github.com/kubernetes/ingress/compare/master...tonglil:gce-tls#diff-247e0d4a5e00d30d32c0e454986614cdR369 earlier on, maybe here: https://github.com/kubernetes/ingress/blob/master/controllers/gce/controller/tls.go#L51.
Or make the tlsloaders a list and iterate through them, something like
var tls *loadbalancers.TLSCerts
for _, l := range lbc.tlsLoaders {
  tls, err = l.load(&ing)
  if err != nil {
    glog.Warningf()
  }
  if tls != nil {
    break
  }
}
lbs = append(lbs, *L7RuntimeInfo{TLS: tls})

here: https://github.com/kubernetes/ingress/blob/master/controllers/gce/controller/controller.go#L426
Then we'd just document that if somehow, an ingress crept past the validation and ended up in the controller with both spec.tls and the anotation set, one of them takes precedence (which we insert first into the list).

I don't know if we shold break on finding the first cert of keep piping the tls object down the stack of loaders (because the last loader might populate client certs, for example. We don't support client certs yet, but probably will soon: https://github.com/kubernetes/kubernetes/issues/32928), but for now I think breaking is fine, since we only care about one key/cert/chain and that's used for tls termination.

Oh, you're probably also looking for https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/resource_printer.go#L1285, which prints out kubectl output

Much appreciated, I think the last comment is what I was looking for.
I will also investigate the 3 different options (as is, early loading, and iteration) and report back with code.

I am trying to write unit tests for this package, but because I defined the annotation key in the main repo, how do I use my fork of it in this repo?

I am not sure how to run the modified k8s to ensure my changes to the validator are valid (other than the unit tests I wrote for the validator). Any suggestions?

I noticed this folder (https://github.com/kubernetes/ingress/tree/master/core/pkg/ingress/annotations). Should I be doing my work in there, or stay on the current path? I can't tell what the folder structure means wrt this change.

I am trying to write unit tests for this package, but because I defined the annotation key in the main repo, how do I use my fork of it in this repo?

You need to check the code into main repo, then update the godep to include your changes:https://github.com/kubernetes/ingress/blob/master/docs/dev/releases.md#dependencies
For local testing you can just modify the code in ingress/vendor/k8s.io/kubernetes/pkg... to include the new annotation.

I am not sure how to run the modified k8s to ensure my changes to the validator are valid (other than the unit tests I wrote for the validator). Any suggestions?

You can bring up a local cluster with the local-up-cluster script to test validation: https://github.com/kubernetes/ingress/blob/master/docs/dev/setup.md#single-node-local-cluster
You can test your changes to the ingress controller by pushing the image to a local image hub and modifying the static-pod manifest located on /etc/kubernetes/manifests on a Kubernetes master, or by deploying a new pod with your image: https://github.com/kubernetes/ingress/tree/master/examples/deployment/gce

I noticed this folder (https://github.com/kubernetes/ingress/tree/master/core/pkg/ingress/annotations). Should I be doing my work in there, or stay on the current path? I can't tell what the folder structure means wrt this change.

If you want to use the same annotation in main repo and ingress, you need to check it into the main repo and import it here or you'll end up with an import cycle. Duplicating the annotation in both repros is an option, but I'd prefer to maintain a single copy so it doesn't diverge.

Sweet, thanks. I would also prefer a single copy so leaving it in the main repo.
After fumbling with godep and git, I was able to build minikube with my validation edits to k8s:
HOST@Tony-Li-8834: ~/Temp/kube [1] (master)
cat ingress-invalid.yml
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo-app-tls-both
  annotations:
    kubernetes.io/ingress.pre-shared-cert: "double-cert"
spec:
  tls:
    - secretName: tls
  backend:
    serviceName: echo-app
    servicePort: 80

HOST@Tony-Li-8834: ~/Temp/kube (master)
kubectl apply -f ingress-invalid.yml
The Ingress "echo-app-tls-both" is invalid: metadata.annotations: Forbidden: may only specify 1 source for TLS (annotation or API)

Through that experience, I also suffered from really slow (and possibly broken) pre-commit hook in the main repo. Looking for time to submit a PR about that.
All that's left to do is e2e tests. I think for this PR I'll stick with a small GKE/GCE scope. After reading about the e2e, I will probably need some help because I am new to BDD.
Thanks.

Hey folks, before I can write any test cases, I am really having a difficult time trying to get e2e tests running on my system.

I tried hack/local-up-cluster.sh but I hit auth errors (https://github.com/kubernetes/kubernetes/issues/40459).

I tried minikube but it has problems returning an external IP address:

...
STEP: Starting loadbalancer controller haproxy in namespace e2e-tests-servicelb-gwznz
Feb  7 16:40:45.001: INFO: Parsing rc from test/e2e/testing-manifests/serviceloadbalancer/haproxyrc.yaml
Feb  7 16:40:45.001: INFO: Container args [--tcp-services=mysql:3306,nginxsvc:443 --namespace=e2e-tests-servicelb-gwznz]
Feb  7 16:45:41.063: INFO: No external address for pod service-loadbalancer-wxp7l on node minikube
Feb  7 16:45:42.064: INFO: No external address for pod service-loadbalancer-wxp7l on node minikube
...

I also tried to build in GCE/GKE, but run into provisioning issues:

...
Trying to find master named 'e2e-test-207383-master'
Looking for address 'e2e-test-207383-master-ip'
Using master: e2e-test-207383-master (external IP: <IP_ADDRESS>)
Waiting up to 300 seconds for cluster initialization.

  This will continually check to see if the API for kubernetes is reachable.
  This may time out if there was some uncaught error during start up.

...................................................................................................................................................Cluster failed to initialize within 300 seconds.
2017/02/07 13:24:14 util.go:98: Step './hack/e2e-internal/e2e-up.sh' finished in 9m30.403303949s
2017/02/07 13:24:14 util.go:96: Running: ./hack/e2e-internal/e2e-down.sh
...

Lastly I also tried go run hack/e2e.go -v --build --up --test --down but that gets stuck at building the container:

2017/02/07 11:41:23 e2e.go:946: Running: make quick-release
+++ [0207 11:41:23] Verifying Prerequisites....
+++ [0207 11:41:23] Using Docker for MacOS
+++ [0207 11:41:23] Building Docker image kube-build:build-0338fab74a-4-v1.7.4-1
+++ [0207 11:41:29] Syncing sources to container
+++ [0207 11:41:31] Running build command...

This process hasn't been easy, so now I'm wondering if I should just write tests by hand and open PRs to get the bots to run them for me? A little help in this direction would go along way :)

hmm, you need a test cluster to run e2es against, and you need to have a local build to create a test cluster, so the first step is running make successfully.
Try these instructions: https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#local-build-using-make
Maybe start with just running make, followed by something like
$ make release-skip-tests && go run hack/e2e.go -up -check_version_skew=false -v

That will give you an e2e cluster.

To run GCE ingress e2es you will also need to bump up your backend-services quota: https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md#quota, you can just increase it to 30 the default of 3 is too low. Once you have an e2e cluster, you can run
$ kubectl get no
NAME                               STATUS                     AGE       VERSION
e2e-test-beeps-master              Ready,SchedulingDisabled   12d       v1.6.0-alpha.0.2505+b1e0bd0fa415cc-dirty
e2e-test-beeps-minion-group-d185   Ready                      12d       v1.6.0-alpha.0.2505+b1e0bd0fa415cc-dirty
e2e-test-beeps-minion-group-zprd   Ready                      12d       v1.6.0-alpha.0.2505+b1e0bd0fa415cc-dirty
e2e-test-beeps-minion-group-zzwg   Ready                      12d       v1.6.0-alpha.0.2505+b1e0bd0fa415cc-dirty

$ ./hack/ginkgo-e2e.sh --ginkgo.focus=L7.*GCE --delete-namespace-on-failure=false

to run just the L7 GCE tests.

Thank you, make has always been successful, it was the part trying to get a test cluster that was problematic.
I ran go run hack/e2e.go -v --up -check_version_skew=false again and because the $USER on my laptop is numeric, I had to:

export KUBERNETES_PROVIDER=gce
export USER_ID=tony
export USER=tony

update build/common.sh:

-  chown -R ${USER_ID}.${GROUP_ID} "${LOCAL_OUTPUT_BUILD_CONTEXT}"
+  chown -R ${USER_ID}:${GROUP_ID} "${LOCAL_OUTPUT_BUILD_CONTEXT}"
...
-      chown -R ${USER_ID}.${GROUP_ID}
+      chown -R ${USER_ID}:${GROUP_ID}

Then when I run it again, it was able to create the cluster. I can't tell if that was the actual problem though.
However I noticed that after this succeeds, kubectl version doesn't seem to line up with local revision.
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.4086+7eb94258aeb8b5-dirty", GitCommit:"7eb94258aeb8b5531321c67e5c5f7c3c442674ca", GitTreeState:"dirty", BuildDate:"2017-02-07T22:47:34Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

whereas the local sha I built from is 923424afa0.

I should be good wrt the quota:
- limit: 75.0
  metric: BACKEND_SERVICES
  usage: 13.0

Oh fwiw I also tagged the k8s commit before I built it.
* 923424afa0 - (HEAD -> ingress-pre-shared-tls, tag: v1.7.0-923424afa0) (drop) update build script to correct chown (Wed Feb 8 13:04:16 2017 -0500) <Tony Li>
* 7eb94258ae - add minikube util.sh (Tue Feb 7 16:29:48 2017 -0500) <Tony Li>
* 5a024b6973 - (origin/ingress-pre-shared-tls) add unit test for ValidateIngressTLSAnnotation (Thu Feb 2 18:35:08 2017 -0500) <Tony Li>
* 879b08eda2 - include port 443 when tls annotation is set (Wed Feb 1 18:03:11 2017 -0500) <Tony Li>
*<PHONE_NUMBER> - add ingress tls source validation (Wed Feb 1 18:02:29 2017 -0500) <Tony Li>
* 4b1530c927 - use the annotation key from k8s (Wed Feb 1 16:28:13 2017 -0500) <Tony Li>
*   8fa38196a9 - (origin/master, origin/HEAD) Merge pull request #40608 from fabianofranz/owners_for_kubectl_translations (Fri Jan 27 15:51:04 2017 -0800) <Kubernetes Submit Queue>

After a lot frustration, I stopped trying to deploy to gce/locally and decided to dev on a GCE Ubuntu instance itself.
local-up-cluster.sh works, but now the tests won't run for some garbled reason:
tony@tony-gke:~/go/src/k8s.io/kubernetes$ go run hack/e2e.go -v --test
2017/02/10 01:12:27 e2e.go:946: Running: ./cluster/kubectl.sh version --match-server-version=false
Client Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
2017/02/10 01:12:27 e2e.go:948: Step './cluster/kubectl.sh version --match-server-version=false' finished in 133.144426ms
2017/02/10 01:12:27 e2e.go:946: Running: ./hack/e2e-internal/e2e-status.sh
Local doesn't need special preparations for e2e tests
Client Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
2017/02/10 01:12:27 e2e.go:948: Step './hack/e2e-internal/e2e-status.sh' finished in 106.123952ms
2017/02/10 01:12:27 e2e.go:946: Running: ./hack/ginkgo-e2e.sh
Setting up for KUBERNETES_PROVIDER="local".
Local doesn't need special preparations for e2e tests
./hack/ginkgo-e2e.sh: line 117: : command not found
!!! Error in ./hack/ginkgo-e2e.sh:117
  Error in ./hack/ginkgo-e2e.sh:117. '"${ginkgo}" "${ginkgo_args[@]:+${ginkgo_args[@]}}" "${e2e_test}" -- "${auth_config[@]:+${auth_config[@]}}" --ginkgo.flakeAttempts="${FLAKE_ATTEMPTS}" --host="${KUBE_MASTER_URL}" --provider="${KUBERNETES_PROVIDER}" --gce-project="${PROJECT:-}" --gce-zone="${ZONE:-}" --gke-cluster="${CLUSTER_NAME:-}" --kube-master="${KUBE_MASTER:-}" --cluster-tag="${CLUSTER_ID:-}" --repo-root="${KUBE_ROOT}" --node-instance-group="${NODE_INSTANCE_GROUP:-}" --prefix="${KUBE_GCE_INSTANCE_PREFIX:-e2e}" --network="${KUBE_GCE_NETWORK:-${KUBE_GKE_NETWORK:-e2e}}" --federated-kube-context="${FEDERATION_KUBE_CONTEXT:-e2e-federation}" ${KUBE_CONTAINER_RUNTIME:+"--container-runtime=${KUBE_CONTAINER_RUNTIME}"} ${MASTER_OS_DISTRIBUTION:+"--master-os-distro=${MASTER_OS_DISTRIBUTION}"} ${NODE_OS_DISTRIBUTION:+"--node-os-distro=${NODE_OS_DISTRIBUTION}"} ${NUM_NODES:+"--num-nodes=${NUM_NODES}"} ${E2E_CLEAN_START:+"--clean-start=true"} ${E2E_MIN_STARTUP_PODS:+"--minStartupPods=${E2E_MIN_STARTUP_PODS}"} ${E2E_REPORT_DIR:+"--report-dir=${E2E_REPORT_DIR}"} ${E2E_REPORT_PREFIX:+"--report-prefix=${E2E_REPORT_PREFIX}"} "${@:-}"' exited with status 127
Call stack:
  1: ./hack/ginkgo-e2e.sh:117 main(...)
Exiting with status 1
2017/02/10 01:12:27 e2e.go:948: Step './hack/ginkgo-e2e.sh' finished in 50.501613ms
2017/02/10 01:12:27 e2e.go:230: Something went wrong: encountered 1 errors: [exit status 1]
exit status 1
tony@tony-gke:~/go/src/k8s.io/kubernetes$ ginkgo
Found no test suites
For usage instructions:
	ginkgo help
tony@tony-gke:~/go/src/k8s.io/kubernetes$ ginkgo version
Ginkgo Version 1.2.0

And installed info:
tony@tony-gke:~/go/src/k8s.io/kubernetes$ uname -r
4.4.0-62-generic
tony@tony-gke:~/go/src/k8s.io/kubernetes$ uname -a
Linux tony-gke 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
tony@tony-gke:~/go/src/k8s.io/kubernetes$ docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   6b644ec
 Built:        Mon, 19 Dec 2016 09:20:48 +1300
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   6b644ec
 Built:        Mon, 19 Dec 2016 09:20:48 +1300
 OS/Arch:      linux/amd64
tony@tony-gke:~/go/src/k8s.io/kubernetes$ git version
git version 2.7.4
tony@tony-gke:~/go/src/k8s.io/kubernetes$ go version
go version go1.7.4 linux/amd64
tony@tony-gke:~/go/src/k8s.io/kubernetes$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/tony/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build211168760=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="0"
tony@tony-gke:~/go/src/k8s.io/kubernetes$ ./third_party/etcd/etcdctl --version
etcdctl version: 3.0.14
API version: 2
tony@tony-gke:~/go/src/k8s.io/kubernetes$ openssl version
OpenSSL 1.0.2g  1 Mar 2016
tony@tony-gke:~/go/src/k8s.io/kubernetes$ cfssl version
Version: 1.2.0
Revision: dev
Runtime: go1.7.4
tony@tony-gke:~/go/src/k8s.io/kubernetes$ gcloud version
Google Cloud SDK 143.0.0
alpha 2016.01.12
beta 2016.01.12
bq 2.0.24
bq-nix 2.0.24
core 2017.02.07
core-nix 2016.11.07
gcloud
gcloud-deps 2017.02.07
gcloud-deps-linux-x86_64
gsutil 4.22
gsutil-nix 4.19
kubectl
kubectl-linux-x86_64 1.5.2
tony@tony-gke:~/go/src/k8s.io/kubernetes$ kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
tony@tony-gke:~/go/src/k8s.io/kubernetes$ cluster/kubectl.sh version
Client Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.1-5a024b6973deaa-dirty", GitCommit:"5a024b6973deaa5149b6fb925f05539d6e263f3e", GitTreeState:"dirty", BuildDate:"2017-02-10T00:20:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Oh, haha our build and test tools can be a little frustrating at times, but I literally just setup a test cluster and ran tests.
You might have to run make clean to purge old builds. You can stick a log line somewhere and make sure it shows up, eg modify this line https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/controllermanager.go#L392, and tail /var/log/kube-controller-manager on the master (assuming it hasn't been rotated by the time you do, if it has, gunzip and tail).
Really to test your ingress controller you can ignore version skew, since it runs in a container and you can build/push that independent of the rest of the kubecluster. As long as e2es run you should be good to go.
If you ssh into the master you will find the controller manifest in /etc/kubernetes/manifests/glbc, you can modify that image to whatever you want. You can push a private image with your changes thus: https://github.com/kubernetes/ingress/blob/master/docs/dev/releases.md#testing

Regarding the test infra, I hope to summarize my experience and clean up the docs at the end of this.

In that comment (https://github.com/kubernetes/ingress/issues/45#issuecomment-278476971), I wasn't sure if I should proceed with the test if the server K8s version didn't have my "API spec validation" code changes (which could affect the e2e tests?).

since it runs in a container and you can build/push that independent of the rest of the kubecluster.

Are you suggesting that the e2e test only tests against the ingress controller (without testing the code changes in kubernetes/kubernetes)? I thought this comment is a request for tests to ensure this behavior is enforced, which I can't do without deploying both changes.

I haven't had a problem deploying the glbc into a real cluster (disabling the GKE glbc with --disable-addons HttpLoadBalancing, then modifying rc.yaml to my own image). That works dandy.

And I was able to run minikube with the kubernetes/kubernetes validation changes locally and ensure it rejects a bad spec.

I will attempt again maybe later tonight. This is the script I am running to setup the GCE instance (this time recorded down complete):
sudo apt-get update

# Go
echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.profile
echo 'export GOPATH=$HOME/go' >> ~/.profile
echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.profile
echo 'export CGO_ENABLED=0' >> ~/.profile
wget https://storage.googleapis.com/golang/go1.7.4.linux-amd64.tar.gz
sudo tar -xvf go1.7.4.linux-amd64.tar.gz
sudo mv go /usr/local
sudo chown ${USER}:root -R /usr/local/
go get -u github.com/tools/godep

# Docker
sudo apt-get install docker.io
sudo service docker start
sudo usermod -a -G docker ${USER}
sudo reboot

# etcd
ETCD_VER=v3.1.0
DOWNLOAD_URL=https://github.com/coreos/etcd/releases/download
curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
mkdir -p /tmp/test-etcd && tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /tmp/test-etcd --strip-components=1
mv /tmp/test-etcd/etcd /usr/local/bin/

# cfssl
go get -u github.com/cloudflare/cfssl/cmd/...

# K8s
mkdir -p $GOPATH/src/k8s.io
cd $GOPATH/src/k8s.io
git clone --depth=1 https://github.com/tonglil/kubernetes.git
cd kubernetes
git remote add upstream 'https://github.com/kubernetes/kubernetes.git'
git fetch upstream
git rebase upstream/master
git remote set-url --push upstream no_push

git checkout v1.7.0-5a024b6973

# Testing

export KUBERNETES_PROVIDER=gce
make release-skip-tests

I thought this comment is a request for tests to ensure this behavior is enforced, which I can't do without deploying both changes.

Yes to test the validation part you will need your changes in the real cluster, since validation is run by the kube-apiserver.
I'm guessing your hashes are mismatched somehow and you can confirm via logging statements that your code is actually getting pushed. I typically take down and rebuild my cluster to push new changes, i.e
$ go run ./hack/e2e.go -down -v
$ nohup go run ./hack/e2e.go -up -check_version_skew=false -v > /tmp/pushup 2>&1 &

Since pushing to a live cluster has been unreliable in the past

Also FYI main repo HEAD is usually stable enough that you can develope straight on it because we run quite a few pre and post submit e2es in http://submit-queue.k8s.io/#/queue, unless you're specifically looking for a particular commit to start from

I might have spoken too soon. After make release-skip-tests succeeds, go run hack/e2e.go -v -up -check_version_skew=false gives:
2017/02/10 02:26:46 e2e.go:946: Running: ./hack/e2e-internal/e2e-down.sh
Your active configuration is: [default]

Project: REDACTED
Zone: us-central1-b
Shutting down test cluster in background.
Bringing down cluster using provider: gce
Traceback (most recent call last):
  File "<string>", line 9, in <module>
  File "/usr/lib/python2.7/distutils/version.py", line 296, in __cmp__
    return cmp(self.version, other.version)
AttributeError: LooseVersion instance has no attribute 'version'
2017/02/10 02:26:48 e2e.go:948: Step './hack/e2e-internal/e2e-down.sh' finished in 2.21557735s
2017/02/10 02:26:48 e2e.go:230: Something went wrong: error tearing down previous cluster: exit status 1
exit status 1

Will try going back to local build + deploy, with make clean, thanks.

@kubernetes/test-infra-maintainers Tony seems to be having a pretty hard time running e2es against a GCE cluster, any suggestions? I can't repro and am not familiar enough with the scripts to provide insight without debugging

that's ... bizarre. @tonglil what version of python do you have installed? (python --version)

Sorry to have pulled you into this, unfortunately I already deleted that instance. The python version was 2.7.? though from a default install on the Ubuntu 16.04 LTS GCE image. I will attempt GCE again next week to try to reproduce the error.

I went back to building on my laptop + deploying to GCE since last time that seemed the most successful. After both make clean and docker prune, it worked! 😄
I want to apologize as I made a mistake when I checked the git sha that was deployed: I caught the red herring of the "tag" not lining up and didn't check for the sha7eb94258aeb8b5531321c67e5c5f7c3c442674ca in git's history. I am sorry to have spent your time responding to my oversight. I will inspect these things more closely in the future.

e2e tests written and tested (deployed GCE cluster from laptop and modified the manifest to pull my own image)!
https://github.com/kubernetes/kubernetes/compare/master...tonglil:ingress-pre-shared-tls


PR: Create a new Appearance plugin

Description of Changes

[x] Wrote at least one-line docstrings (for any new functions)
[x] Added unit test(s) covering the changes (if testable)

[ ] Included a screenshot or animation (if affecting the UI, see Licecap)

Issue(s) Resolved

Fixes #12798
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: @goanpeca

Hello @goanpeca! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/api/plugins.py:

Line 1513:1: W293 blank line contains whitespace

Hi @dalthviz, this one is ready for QA testing. Thanks!

Not sure why but seems like tests are failing on Windows @goanpeca (a message about Python aborting appears)

Yeah @dalthviz I am not sure where it is coming from, but please test the PR as the error seems unrelated to the work.

Checking this I found that changing the interface theme option (if no need of restart is detected) leads to the following traceback:
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\preferences\configdialog.py", line 227, in accept
    configpage.apply_changes()
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\preferences\configdialog.py", line 99, in apply_changes
    self.apply_callback()
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\preferences\configdialog.py", line 282, in <lambda>
    self.apply_settings(self.changed_options))
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\plugins\appearance\confpage.py", line 234, in apply_settings
    self.main.help.apply_plugin_settings(['color_scheme_name'])
AttributeError: 'Help' object has no attribute 'apply_plugin_settings'

Besides that seems like the rest of the options are working :+1: . Also, the error above is present in master too.
As a side note, restarting Spyder while running it from bootstrap is raising an error (this is also happening in master and 4.x):
Traceback (most recent call last):
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\app\restart.py", line 32, in <module>
    from spyder.utils.qthelpers import qapplication
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\utils\qthelpers.py", line 28, in <module>
    from spyder.config.manager import CONF
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\config\manager.py", line 17, in <module>
    from spyder.config.main import CONF_VERSION, DEFAULTS, NAME_MAP
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\config\main.py", line 19, in <module>
    from spyder.config.fonts import MEDIUM, SANS_SERIF
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\config\fonts.py", line 14, in <module>
    from spyder.config.utils import is_ubuntu
  File "C:\Users\Daniel\Documents\Spyder\Spyder otros\gonzalo\spyder\spyder\config\utils.py", line 17, in <module>
    from spyder_kernels.utils import iofuncs
ModuleNotFoundError: No module named 'spyder_kernels'

Thanks @dalthviz. Will fix!

As a side note, restarting Spyder while running it from bootstrap is raising an error (this is also happening in master and 4.x):

Please open a new issue for that with any details you can add. Thanks, @dalthviz !

Checking this I found that changing the interface theme option (if no need of restart is detected) leads to the following traceback:

I fixed (I think) the first issue @dalthviz mentioned. If you could check again that would be great.
Thanks!

This is ready for review @ccordoba12

@goanpeca checking again seems like now the help plugin doesn't raises an error :+1:
However, I checked the options regarding the fonts options and found the following:

Seems like the Plain text option, even after changing it, puts as selected font Consolas in the combobox.
Seems like the Size option of Rich text is connected to both number selectors (Plain text and Rich text)

Also, seems like the order of the sections in the preferences changed (now the Appearance entry is the seven one in the list instead of the second one)? (Maybe is not too important but I mention it just in case since I notice it while checking the GIF and running 4.x).

Seems like the Plain text option, even after changing it, puts as selected font Consolas in the combobox.
Seems like the Size option of Rich text is connected to both number selectors (Plain text and Rich text)

Thanks @dalthviz, will fix.

Also, seems like the order of the sections in the preferences changed (now the Appearance entry is the seven one in the list instead of the second one)? (Maybe is not too important but I mention it just in case since I notice it while checking the GIF and running 4.x).

Yes this will change in the meantime but will be restored once the other plugins are migrated. Thanks for checking!

Seems like the Plain text option, even after changing it, puts as selected font Consolas in the combobox.
Seems like the Size option of Rich text is connected to both number selectors (Plain text and Rich text)

Fixed @dalthviz

@dalthviz @ccordoba12 this one is ready for review.

@goanpeca, please rebase this one to see if our tests pass (they are failing in a Pylint test, which seems unrelated to this).
@dalthviz, please give this one another round of manual testing.

/binder

Fixed.

@goanpeca , now this one has merge conflicts.

Fixed.

I'll left this one to @dalthviz to test it and merge it.

While testing this I found the following:

Seems like the elements in the Preference dialog are duplicated (although maybe this is happening beside this PR?):

The actual functionality of the Appearance section LGTM :+1:

While testing this I found the following:

Hi @dalthviz thanks for checking.
I had already opened https://github.com/spyder-ide/spyder/pull/13414 to fix that. Feel free to merge that one too if you agree with the changes.

Done @goanpeca , please rebase this one and then it should be ready to merge :+1:

Done @goanpeca , please rebase this one and then this should be ready for merge 👍

Fixed! Thanks again.


Error: => shortened method not enabled

.dub/packages/sharded-map-2.1.0/sharded-map/source/rewind/map.d(5,19): Error: => shortened method not enabled, compile with compiler switch `-preview=shortenedMethods`
.dub/packages/sharded-map-2.1.0/sharded-map/source/rewind/map.d(7,20): Error: => shortened method not enabled, compile with compiler switch `-preview=shortenedMethods`
Error dmd failed with exit code 1.

If this package need special compiler flags to build, please put them in the dub.json, so no surprise to the user.

I totally missed this issue, need to reconfigure notifications on Github. I compiled using latest (at the time) DMD might be preview was over by then. Which version of compiler you are using?


Disable the batch API when in compatibility mode

Fixes the CI error in #224.
Additionally, we now use the mangled name of the CUfileOpError to determine if cuFile's batch API is available (v12.0.1+). Previously, we used the mangled name of cuFileBatchContextState, which corresponds to v12.0.0+.

Thanks all! 🙏


npm run installer is not working

I am using ubuntu server16.x.
git clone https://github.com/DivanteLtd/vue-storefront-api.git vue-storefront-api
cd vue-storefront-api
npm install
above 3 commands are worked properly, but last one "npm run installer" giving some error like below
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>installer: 'node ./core/scripts/installer'
npm ERR! Exit status 1
npm ERR! Failed at the<EMAIL_ADDRESS>installer script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!  Please attach the full log of the installer. It's not clear from your description but of course you're running the npm run installer inside vue-storefront directory right?
Which branch are you using (develop or master)?

I've just tested it on Debian server (https://demo-magento-checkout.vuestorefront.io/) and seems to work;
I've got the following versions of tools:
npm -v
5.3.0
yarn -v
1.5.1
node -v
v8.5.0

yes, i am running the npm run installer inside vue-storefront directory. I am using develop branch.

Please check if You have docker-compose installed - https://docs.docker.com/compose/install/

I have got the same issue and I have docker compose installed


installation fails on Linux (Ubuntu 22.10)

Hi,
I have Ubuntu 22.10
I'm trying to install ctc-segmentation, but I have this error :
Collecting ctc-segmentation
  Using cached ctc_segmentation-1.7.4.tar.gz (73 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy in ./venv/lib/python3.7/site-packages (from ctc-segmentation) (1.21.6)
Requirement already satisfied: Cython in ./venv/lib/python3.7/site-packages (from ctc-segmentation) (0.29.33)
Requirement already satisfied: setuptools in ./venv/lib/python3.7/site-packages (from ctc-segmentation) (67.3.3)
Building wheels for collected packages: ctc-segmentation
  Building wheel for ctc-segmentation (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for ctc-segmentation (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [38 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.linux-x86_64-cpython-37
      creating build/lib.linux-x86_64-cpython-37/ctc_segmentation
      copying ctc_segmentation/partitioning.py -> build/lib.linux-x86_64-cpython-37/ctc_segmentation
      copying ctc_segmentation/__init__.py -> build/lib.linux-x86_64-cpython-37/ctc_segmentation
      copying ctc_segmentation/ctc_segmentation.py -> build/lib.linux-x86_64-cpython-37/ctc_segmentation
      running build_ext
      building 'ctc_segmentation.ctc_segmentation_dyn' extension
      creating build/temp.linux-x86_64-cpython-37
      creating build/temp.linux-x86_64-cpython-37/ctc_segmentation
      gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/tmp/pip-build-env-b3izg_6t/overlay/lib/python3.7/site-packages/numpy/core/include -I/home/dewi/Labourva/sintezenn-ar-vouezh/venv/include -I/home/dewi/.pyenv/versions/3.7.12/include/python3.7m -c ctc_segmentation/ctc_segmentation_dyn.c -o build/temp.linux-x86_64-cpython-37/ctc_segmentation/ctc_segmentation_dyn.o
      In file included from /tmp/pip-build-env-b3izg_6t/overlay/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1816,
                       from /tmp/pip-build-env-b3izg_6t/overlay/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:18,
                       from /tmp/pip-build-env-b3izg_6t/overlay/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
                       from ctc_segmentation/ctc_segmentation_dyn.c:765:
      /tmp/pip-build-env-b3izg_6t/overlay/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
         15 | #warning "Using deprecated NumPy API, disable it by " \
            |  ^~~~~~~
      gcc -pthread -shared -L/home/dewi/.pyenv/versions/3.7.12/lib -L/home/dewi/.pyenv/versions/3.7.12/lib build/temp.linux-x86_64-cpython-37/ctc_segmentation/ctc_segmentation_dyn.o -o build/lib.linux-x86_64-cpython-37/ctc_segmentation/ctc_segmentation_dyn.cpython-37m-x86_64-linux-gnu.so
      /home/linuxbrew/.linuxbrew/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libc.so.6 when searching for /lib/x86_64-linux-gnu/libc.so.6
      /home/linuxbrew/.linuxbrew/bin/ld: cannot find /lib/x86_64-linux-gnu/libc.so.6
      /home/linuxbrew/.linuxbrew/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libc.so.6 when searching for /lib/x86_64-linux-gnu/libc.so.6
      /home/linuxbrew/.linuxbrew/bin/ld: /lib64/ld-linux-x86-64.so.2: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: /lib64/ld-linux-x86-64.so.2: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: skipping incompatible /lib64/ld-linux-x86-64.so.2 when searching for /lib64/ld-linux-x86-64.so.2
      /home/linuxbrew/.linuxbrew/bin/ld: cannot find /lib64/ld-linux-x86-64.so.2
      /home/linuxbrew/.linuxbrew/bin/ld: /lib64/ld-linux-x86-64.so.2: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: /lib64/ld-linux-x86-64.so.2: unknown type [0x13] section `.relr.dyn'
      /home/linuxbrew/.linuxbrew/bin/ld: skipping incompatible /lib64/ld-linux-x86-64.so.2 when searching for /lib64/ld-linux-x86-64.so.2
      collect2: error: ld returned 1 exit status
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for ctc-segmentation
Failed to build ctc-segmentation
ERROR: Could not build wheels for ctc-segmentation, which is required to install pyproject.toml-based projects

The build failed at the compilation step, which uses gcc.
My first guess: The ld that you use is in /home/linuxbrew/.linuxbrew/bin/ld, but it should be the ld in /usr/bin/ld, because you use /usr/bin/gcc. ld and gcc should have compatible versions, and this mismatch might cause the issue.

I think this can be closed, as it is a compiler-linker issue


Upgraded to v0.45.0 settings window no longer opens

Microsoft PowerToys version
0.45.0
Running as admin

[ ] Yes

Area(s) with issue?
General
Steps to reproduce
I was running (from memory) v0.43.0 successfully, using FancyZones in particular all the time.
I downloaded PT0.45.0 from GitHub and installed over the top of 0.43.0
I noticed that the installer insisted on stopiing (killing) explorer.exe before it would continue. Having let it stop Explorer it failed to restart it, so a reboot was required after the installation.
Symptoms-

Fancyzones configuration lost. All 3 monitors in my 3 monitor PLP setup have reverted to a default "roughly thirds" horizontal split
If I try to open the PT Settings by either double-clicking the icon, or right-clicking and choosing "Settings" nothing happens.
I don't think a window is running in some crazy position off-screen (a bit of a Windows thing) because if I run TaskManager, there is no foreground PowerTools window listed.

Note- When I went to uninstall PowerToys 0.45.0 to try a clean install, the installer again insists on killing Explorer.exe before it will continue. Is this expected behaviour?
✔ Expected Behavior

Settings retained between versions
Settings Window opens as normal

❌ Actual Behavior
No Settings interface opens
bug report attache
PowerToysReport_2021-09-21-20-48-51.zip
d
Other Software
Windows 10 Pro 64 bit

Update- An un-install and clean installation of 0.45.0 seems to have fixed the problem. My FancyZones definitions were still present so all I had to do was re=apply them to the correct monitors.
I did a checksum on the first download vs. the second and they are the same, so I do ont think this was caused by a corrupt download.
This appears to have been an installation problem, possibly to do with overwriting and older version, but that is a guess

Yes, that's possible, though I wonder why it happens only for a subset of users. I'll try to reproduce it locally.

Comparing the bug report's "installationFolderStructure.txt" with the one from my local 0.45 installed version reveals that the user's installation had different content in some files:

Microsoft.Toolkit.Win32.UI.XamlHost.xml
PowerToys.Settings.runtimeconfig.json
SvgPreviewHandler.runtimeconfig.json
SvgThumbnailProvider.runtimeconfig.json
Some plugin.json files in PowerToys Run plugins.

I just ran the update from 0.47.1 to 0.49.1, using the "upgrade now" function.
The good news is that this time the upgrade ran (asking for admin rights), and that afterwards the UI was still functional, so that's a step forwards.
The bad news is my FancyZones definitions have disappeared again. My two named custom zone layouts (called "centre" and "side" from memory) are gone, and all I have are the default layouts.
Question for the dev team, do you want to continue this discussion under this bugID, or close this issue and raise a new lesser one for just the "fancyzones disappear after upgrade" problem?

Yes, creating a new issue for fz settings would be great!

I have two machines running PowerToys, both on Windows 10 Pro 64 bit.
The first machine (laptop) has the setup described above, with  PowerToys installed in C:\Program Files\Microsoft\PowerToys. On this machine, as described above, the upgrader ran without error, but the FancyZones setting were lost.
I have just upgraded the second machine (desktop) to 0.49.1. It turns out on this machine PT is installed in the default location of C:\Program Files\PowerToys. The behaviour on this machine when installing the upgrade was different-

The upgrade process complained that files were in use and said it needed to halt and restart some applications
It turned out the main application it needed to restart was the window manager explorer.exe
After killing explorer, the upgrader still complained there were files open. It ran through to the end after hitting "continue", but did not restart explorer.
After logging out via the Task Manager (i.e. not a full reboot) PT seems to be running and the FancyZones settings are present and correct

So, strange stuff going on. Not sure how much of it is install location dependent.

cc @SeraphimaZ

@incansvl Which version are you using now and is this still an issue?

/needinfo


Convert simple block tags whose child is a link to gemini links

To simplify the rendering of a list of links, often seen using   or , e.g

link display
link display2

should become
=> target link display
=> target2 link display 2

fixed in https://github.com/LukeEmmet/html2gemini/commit/7a5e0baec07ac84fc4731f6e77529d7aad1d46bf


Cloud config file not updated on CLI install update

Hi there,
We had a customer encounter an error where the recently added 'batch_resource_id' was not set in their cached clouds.config file, yet the Batch command module requested it. In other words - the cached config was out-of-date with the rest of the CLI installation, and didn't contain the latest fields as required by the modules.
Is this expected behavior? Or should the CLI core update the cached config file between version updates?
The customer is running on Ubuntu 16.04 LTS, and their CLI install history is as follows:

Initially installed the apt-get package from a few months ago, however this didn't work with this tutorial
Installed the nightly build in order to image VMs.
Upgraded to the latest apt-get package, with the following version info:
az --version
azure-cli (2.0.3)
acr (2.0.1)
acs (2.0.3)
appservice (0.1.3)
batch (2.0.1)
cloud (2.0.1)
component (2.0.1)
configure (2.0.3)
container (0.1.3)
core (2.0.3)
documentdb (0.1.3)
feedback (2.0.1)
find (0.0.2)
iot (0.1.3)
keyvault (2.0.1)
lab (0.0.2)
monitor (0.0.2)
network (2.0.3)
nspkg (2.0.0)
profile (2.0.3)
redis (0.2.0)
resource (2.0.3)
role (2.0.2)
sql (2.0.1)
storage (2.0.3)
vm (2.0.3)
Python (Linux) 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

Is the above install process likely to have led to the confused config file? If so - is there a guaranteed method to wipe an installation along with any cached configs and profile data to insure a clean update?
Thanks,
Anna

I'm the customer.

As a workaround, you can delete the file ~/.azure/clouds.config.
It will get recreated once you run az and then batch_resource_id will exist. (if you added your own custom cloud, remember to save that though)
The issue was that the new batch_resource_id was added but since ~/.azure/clouds.config already existed, it wasn't updated.
Renaming the issue to reflect this.


pull request for e2e test at 01/09/2017 16:56:12

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Installation issue on fresh install: UnsatisfiableError

Dear Zipline Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment

Operating System: Windows 7 64bit
Python Version: 3.5.6
Python Bitness: 64
How did you install Zipline: conda
Python packages:
Name                    Version                   Build  Channel
certifi                   2018.8.24                py35_1
pip                       10.0.1                   py35_0
python                    3.5.6                he025d50_0
setuptools                40.2.0                   py35_0
vc                        14.1                 h0510ff6_4
vs2015_runtime            14.15.26706          h3a45250_4
wheel                     0.31.1                   py35_0
wincertstore              0.2              py35hfebbdb8_0

Now that you know a little about me, let me tell you about the issue I am
having:
Description of Issue
Zipline raises this error, when installed via conda:
Collecting package metadata (current_repodata.json): done
Solving environment: failed
Collecting package metadata (repodata.json): done
Solving environment: failed

UnsatisfiableError: The following specifications were found to be incompatible with each other:

  - certifi
  - pkgs/main/win-64::pip==10.0.1=py35_0
  - pkgs/main/win-64::python==3.5.6=he025d50_0
  - pkgs/main/win-64::setuptools==40.2.0=py35_0
  - pkgs/main/win-64::vc==14.1=h0510ff6_4
  - pkgs/main/win-64::vs2015_runtime==14.15.26706=h3a45250_4
  - pkgs/main/win-64::wheel==0.31.1=py35_0
  - pkgs/main/win-64::wincertstore==0.2=py35hfebbdb8_0
  - zipline

Please note that this incompatibility supposedly is on all the packages in the environment, which otherwise seems to work fine. In fact, the environment was just created, with the latest version of anaconda installed.
Here is how you can reproduce this issue on your machine:
Reproduction Steps

conda create -n env_zipline python=3.5
activate env_zipline
conda install -c Quantopian zipline

What steps have you taken to resolve this already?
Tried to update all packages:
conda update --all

And update conda in the base environment:
conda update conda
conda update anaconda-navigator
conda update navigator-updater

Anything else?
conda version : 4.7.5
conda-build version : 3.18.5

Sincerely,
Giulio

Same problem on linux-64 platform
UnsatisfiableError: The following specifications were found to be incompatible with each other:

ca-certificates
certifi
openssl
pkgs/main/linux-64::_libgcc_mutex==0.1=main
pkgs/main/linux-64::libedit==3.1.20181209=hc058e9b_0
pkgs/main/linux-64::libffi==3.2.1=hd88cf55_4
pkgs/main/linux-64::libgcc-ng==9.1.0=hdf63c60_0
pkgs/main/linux-64::libstdcxx-ng==9.1.0=hdf63c60_0
pkgs/main/linux-64::ncurses==6.1=he6710b0_1
pkgs/main/linux-64::pip==10.0.1=py35_0
pkgs/main/linux-64::python==3.5.6=hc3d631a_0
pkgs/main/linux-64::readline==7.0=h7b6447c_5
pkgs/main/linux-64::setuptools==40.2.0=py35_0
pkgs/main/linux-64::sqlite==3.28.0=h7b6447c_0
pkgs/main/linux-64::tk==8.6.8=hbc83047_0
pkgs/main/linux-64::wheel==0.31.1=py35_0
pkgs/main/linux-64::xz==5.2.4=h14c3975_4
pkgs/main/linux-64::zlib==1.2.11=h7b6447c_3
zipline

Same issue here on macOS 🙋♂.
UnsatisfiableError: The following specifications were found to be incompatible with each other:

  - ca-certificates
  - certifi
  - openssl
  - pkgs/main/osx-64::libcxx==4.0.1=hcfea43d_1
  - pkgs/main/osx-64::libcxxabi==4.0.1=hcfea43d_1
  - pkgs/main/osx-64::libedit==3.1.20181209=hb402a30_0
  - pkgs/main/osx-64::libffi==3.2.1=h475c297_4
  - pkgs/main/osx-64::ncurses==6.1=h0a44026_1
  - pkgs/main/osx-64::python==3.5.6=hc167b69_0
  - pkgs/main/osx-64::readline==7.0=h1de35cc_5
  - pkgs/main/osx-64::setuptools==40.2.0=py35_0
  - pkgs/main/osx-64::sqlite==3.28.0=ha441bb4_0
  - pkgs/main/osx-64::tk==8.6.8=ha441bb4_0
  - pkgs/main/osx-64::wheel==0.31.1=py35_0
  - pkgs/main/osx-64::xz==5.2.4=h1de35cc_4
  - pkgs/main/osx-64::zlib==1.2.11=h1de35cc_3
  - zipline

Same here, Windows 10, conda, Py 3.5.6
UnsatisfiableError: The following specifications were found to be incompatible with each other:

certifi
pkgs/main/win-64::pip==10.0.1=py35_0
pkgs/main/win-64::python==3.5.6=he025d50_0
pkgs/main/win-64::setuptools==40.2.0=py35_0
pkgs/main/win-64::vc==14.1=h0510ff6_4
pkgs/main/win-64::vs2015_runtime==14.15.26706=h3a45250_4
pkgs/main/win-64::wheel==0.31.1=py35_0
pkgs/main/win-64::wincertstore==0.2=py35hfebbdb8_0
zipline

Still no solution, I have still exactly the same "UnsatisfiableError: The following specifications were found to be incompatible with each other" error as above, and can't continue working with this great backtesting engine. Thanks for any response.

This is a problem with the latest version of Conda. Please see the following for a resolution: https://github.com/quantopian/zipline/issues/2514


Confusing UX with default values

I saw in several places this pattern:
class ContinuousFeature(BaseFeature):
    def __init__(self, key=None, preprocessor=None, imputer=None, scaler=None, log=False,
                 log_auto_scale=True):
        self.key = key
        self.preprocessor = preprocessor
        self.imputer = (imputer or SimpleImputer()) if imputer != False else None
        self.scaler = (scaler or StandardScaler()) if scaler != False else None
        self.log = log
        self.log_auto_scale = log_auto_scale

Lets focus on '''scaler''' for instance.
Reading the code, what I'm guessing is that what you want to offer to the developer using the lib, the following choices:

leave parameter with default value None, which internally will invoke a StandardScaler
provide her own scaler
use no scaler at all, by providing False value on that parameter

Those seems too many options,  not straightforward to think about, to use, or to code (onfire code is twisted for accomplishing this matter).
Not only that, but the code is also breaking the expectations. If the user writes ContinuousFeature(scaler=None) but instead get an instance with an StandardScaler, sounds like a bug to me (although you may say it's a feature).
Posible better UX:

default is None, and it's used as it is (which means, no scaler). And the usual python applies. False, 0, etc, are interpreted as None as well.

On the other hand, I think it is a nice feature to provide reasonable default values for each field type, for the following reasons:

When using the library, it is a common scenario to instantiate these classes many times (once for each feature), requiring to specifying these parameters several times (and probably with the same values). Providing default values avoids that need, making the code less verbose and more clear.
It makes the library very friendly to beginner users, who won't need to worry about many settings.

On the one hand, I fully agree with you that the UX is confusing and can be improved.
Probably, one of the reasons of such confusing behavior is the overuse of a single parameter to do many things. What if it uses two separate parameters instead? Following your example with "scaler"...

scaler: the scaler strategy to be used.

'standard_scaler' (default): uses StandardScaler with default arguments.
'custom': uses the scaler transform provided in custom_scaler parameter.
None (False, 0): uses no scaler.

custom_scaler: when scaler=='custom', this parameter specify the scaler transform to be used.

It is a similar to the pattern followed by sklearn, for instance in SimpleImputer (strategy/fill_value parameters)
Does it make sense to you?

I like your idea, enables the simplicity of use together with the flexibility for power users.
And I really like that matches the pattern of some pieces of sklearn.
It feels a bit of too-much-paperwork filling 2 params for single purpose.
Re-reading my initial comment I realize that what it hurts the most, is the issue with None interpreted as "standard_scaler".
Maybe an option in the middle is a good choice as well.
Signature:
class ContinuousFeature(BaseFeature):
    def __init__(self, key=None, preprocessor=None, imputer=None, scaler='standard_scaler', log=False,
                 log_auto_scale=True):
    ...

and then:

scaler:

'standard_scaler' (default): uses StandardScaler with default arguments.
None (False, 0): uses no scaler.
<custom-scaler-object>: user defined scaler transformer to be used.

I'm sorry for reviving this issue... but we have been using this and I thought that maybe it would make sense to do it like this, from a user perspective:

Thus, it would be something like:
class ContinuousFeature(BaseFeature):
def init(self, key=None, preprocessor=None, imputer=None, scaler=StandardScaler(), log=False,
log_auto_scale=True):
...
and then:

default is StandardScaler()
None would be no scaler
Pass other scaler object, uses the custom scaler.

and, therefore:

self.scaler = scaler

which is much more readable, in my opinion.


DEP status lost on new commit

I've discovered that DEP currently doesn't act on PRs receiving new commits, which leads to the status being not reported on the most current commit (the one used by github to compute the overall status). That's unfortunate as it prevents me from adding it to the list of required status.
It would be awesome to add DEP to the list of required PR status so that no one can accidentally merge a PR that is awaiting dependencies (eg. because it's based on an other PRs Branch).

Thanks @zetaron for reporting this 👍
I will check the logs and try to figure out what is going on. May you please provide some context? e.g. a PR link?

Oh, just letting you know that this would take a day or so since my laptop isn't working right now hehe

@ahmed-taj No preassure! Just wanted to bring it to your attention as it seemed odd to me at first :)
If you want I could try to come up with a PR.

Also I can try to setup a test repository to showcase the issue.

Great! Be my guest ;)
Also, we may need to consider that app might get rate limited since it's hosted on an OSS Zeit plan (https://now.sh) !

@ahmed-taj good to know, so maybe it's wise to host a small personal version... maybe add a hint to the readme and/or the github installation page?

You're right, I will add this to the installation page shortly!

Hey @zetaron. I've updated the installation page and will do the same on the README soon.

Also I can try to setup a test repository to showcase the issue.

Do you have more info you would like to share?

@ahmed-taj No I've nothing to add as soon as the repository is set up I can try to help reproduce this issue for further investigation.
As the repository I originally discovered it is a private one I can't share much more :s sorry.
Thanks for caring so much!

I think this just needs:
robot.on('pull_request.synchronize', update)

here: https://github.com/z0al/dep/blob/999cc9bf74059404321d8323403c7ffac38f9a05/index.js#L21-L25


upgrade jquery version

replace older version of jquery to patch xss vulnerability

A couple questions:

should the be pulled from the resource server, instead of being included directly here?
It looks like there is at least one spot in the code where it does already, maybe that should also be applied else where? https://github.com/uPortal-Project/WebproxyPortlet/blob/2caa339c282d3066416bd4f4d451a7cb504936ae/src/main/webapp/WEB-INF/jsp/gateway.jsp#L25
If we do keep it here, will we need to update the URLs like: https://github.com/uPortal-Project/WebproxyPortlet/blob/2caa339c282d3066416bd4f4d451a7cb504936ae/src/main/webapp/WEB-INF/jsp/gatewayNewPage.jsp#L31 to use the new script?

Yikes, yeah I'm not a fan of the hardcoding. I'll make some adjustments.. Thanks!

I changed to the latest resource-server version that uses jquery 1.12.4, and updated the references in the jsp files to use the resource path.


Add keyboard-selected tests

@rafeememon please review

Codecov Report

Merging #761 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #761   +/-   ##
=======================================
  Coverage   92.44%   92.44%
=======================================
  Files          13       13
  Lines         622      622
  Branches      116      116
=======================================
  Hits          575      575
  Misses          8        8
  Partials       39       39

Continue to review full report at Codecov.

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

This is great, thank you!


Feature request: Linear regression

Hello, a feature that currently seems to be missing from Iris is being able to do linear regressions e.g. to compute linear trends over time, which is important when studying climate change, for instance. I would have thought that even just having ordinary least squares (OLS) regression would be useful for many users.
The most obvious way to do this that I can think of (from a user rather than developer perspective) is to include it as an option under iris.analysis for use with cube.collapsed e.g. "cube.collapsed('time', iris.analysis.OLS)". I think it would make most sense for this to return a CubeList with cubes containing the intercept and slopes - this would make it a bit different from other iris.analysis functions, but I don't think this would matter a lot.

Related: #3331


Updating doesn't workl

Updating server doesn't work it stays at the same version.

Can you show some logs or anything ? Works fine here. If you're trying to update to v25.61 (server), that isn't out yet for private dedicated servers. It's WC's fault, not the plugin or windowsgsm. They release them late for us.


Update PyPi Package

Can we get an updated version of Redisco up on PyPi?

This should happen now since we have unit tests back on track.

That would be great because I use Redisco in a few projects and have concerns over its longevity such that I have an issue that says "migrate away from Redisco" :) I'd rather note though :)

Beware that it will have a new name as the the creator of the project lost his pypi account a looooong time ago.
In the mean time, I encourage you to migrate to v0.2 which fixes a BIG memory leaks. You can simply add the following line in your requirements.txt
-e<EMAIL_ADDRESS>
Should help the transition.

Although, remember  that 0.2 is not compatible with v0.1.4 that you may be using at the moment. I should maybe write a small migration tool for this.

I am afraid not. Since this is the same project all in all (we really share a lot of common code). But since pypi wont allow us to publish any project with the same name, better call it something like "redisco2" or something like that so people dont get confused when searching for it.

I think redisco2 is an 'okay" compromise; otherwise couldn't we contact the
PyPi admins to get "redisco" deleted so a new version can be republished?
(Seeing a the original author has forgotten/lost his/her password!)
James Mills / prologic
E<EMAIL_ADDRESS>W: prologic.shortcircuit.net.au
On Mon, Jun 6, 2016 at 10:39 PM, sebastien requiem<EMAIL_ADDRESS>
wrote:

I am afraid not. Since this is the same project all in all (we really
share a lot of common code). But since pypi wont allow us to publish any
project with the same name, better call it something like "redisco2" or
something like that so people dont get confused when searching for it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kiddouk/redisco/issues/61#issuecomment-224183281, or mute
the thread
https://github.com/notifications/unsubscribe/ABOv-vnQN7MDEoiH8UR6T1rnGdmxraZZks5qJQQXgaJpZM4IulkX
.

ping

👍  for redisco2


Store round constants of Keccak in the binary instead of memory

https://github.com/o1-labs/proof-systems/pull/1558#discussion_r1430162743

Close as https://github.com/o1-labs/proof-systems/issues/1605 is a duplicate


How to retrieve negotiation password?

How to retrieve negotiation password?
And is it editable?

Do:
# sqlitebrowser ./data/empire.db
Then browse to 'config' for the negotiation password or 'agents' for each agent's session key. ./setup/setup_database.py can set the staging key on db setup as well.

Thanks alot.


Mock Qn 1 Private Final?

Hi guys, for the qn 1 of the mock finals, why are we able to access newList.list at all, given that it is declared private final? Like I know its not really part of the question but isn't it actually fundamentally wrong?

This is how I thought add would be implemented (before using update())
ImList<T> add(T elem) {
	return new ImList(list.add(elem));
}

I have tested it out and for the original code, even within the same method signature ImList::add(T) its giving me (as expected):

Am I missing something here?

Hi, I am not sure if I am correct but if i recall correctly it's because lists are mutable structures in java? which is why ImList was introduced... (someone pls correct me if im wrong HAHA)

Hi, I am not sure if I am correct but if i recall correctly it's because lists are mutable structures in java? which is why ImList was introduced... (someone pls correct me if im wrong HAHA)

Yeah lists are mutable but I think I dont think you can call a List from a ImList that has it as private final, as the issue is not with mutability but with being able to access the thing in the first place?

Hi Im not too sure whether I understand your question correctly, but isn't the ImList in the question similar to our given ImList that we have been using all this while?
If I understand your question correctly, the abstraction barrier is not broken when an object of type ImList assesses the instance variables of another ImList object (referenced from Recitation 1 Guide)

omg ur right haha I should have just referred to one of my many ImList.java files. Must be an issue with my testing then, thanks!

Hi, I am not sure if I am correct but if i recall correctly it's because lists are mutable structures in java? which is why ImList was introduced... (someone pls correct me if im wrong HAHA)

Yeah lists are mutable but I think I dont think you can call a List from a ImList that has it as private final, as the issue is not with mutability but with being able to access the thing in the first place?

ahhh.. i misunderstood ur qns my bad hha


Adding copy-to-clipboard support for the long blockchain IDs.

...like the hashes. We display them abbreviated but make it easy to
copy the full version.

Here's a screenshot. Sadly it does not show the keen animation when you click the copy button.


ppx_repr doesn't work with types shadowing stdlib types

type result = int [@@deriving repr]

type t = result list [@@deriving repr]

causes
19 | type t = result list [@@deriving repr]
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: This expression has type
         'a Repr.ty -> 'b Repr.ty -> ('a, 'b) Stdlib.result Repr.ty
       but an expression was expected of type 'c Repr.ty

At some level, this is expected and is what the [@nobuiltin] attribute is for. (See ppx_deriving conventions and testing of the ppx_repr implementation.)
In this case, we could do better because result is used at a different arity from the one in the standard library, so attempting to use Repr.result isn't going to work. What do you think?

Thanks for the precisions.
The biggest problem here is that the error message is very misleading, it took me a while to understand this was caused by a name clash. Ideally, an error message would have suggested me to use [@nobuiltin].
When Repr sees a result, could we inject into the AST something that asserts that  result is Stdlib.result(and likewise for all the other types from stdlib)? This way I suppose that the error message would be clearer.

Yep, good point. This is part of a larger problem with PPXes having no way to hook into the error message mechanism. It's possible we could emit code like the following:
(* In a PPX runtime library *)
type ('a, 'b) expected_equality = Refl : ('a, 'a) expected_equality

(* In user code *)
type (_, _) result = unit
type foo = int * (bool, string) result

let foo_t =
  let _ : (('a, 'b) result, ('a, 'b) Stdlib.result) expected_equality = Ppx_repr_runtime.Refl in
  ...

which would produce an error of the following sort:
Line 1, characters 72-76:
Error: This expression has type (unit, unit) expected_equality
       but an expression was expected of type
         (unit, ('a, 'b) Stdlib.result) expected_equality
       Type unit is not compatible with type ('a, 'b) Stdlib.result

It's very possible that there are ways to coerce a better error message out of OCaml.


Only show a certain number of posts per page.

It seems like the index/home will continue to show all posts. What happens when a user hits 100? 1000? Even as static HTML, it is a lot to load, especially for mobile.
Can we limit each page to like 50 or 100? Could we make it configurable?

Hi @jaredsburrows
There's an open PR about this: https://github.com/jekyll/minima/pull/150
If you have a lot of posts, you should be able to add pagination and override the index.html file of the theme.
If you need pagination on categories or collections, I suggest you take a look on https://github.com/sverrirs/jekyll-paginate-v2 (but it's not supported by GitHub Pages)

@DirtyF Hey, do you have an example project that does work with Github pages? Thanks for the reply by the way.

@jaredsburrows Posts pagination is supported by default on GitHub Pages, you just have to specify some parameters in your _config.yml:
paginate: 1
paginate_path: "/page/:num/"

Then you loop over paginator.posts instead of site.posts as mentioned in the docs.
Make sure you pagination URLs are properly built, e.g. I had to add relative_url filter to next and previous links.
Here's a basic example with default GitHub Pages theme (primer), it works also for minima:
Pagination demo repository - Pagination basic demo

Without pagination, the default theme is useless when you have lot of posts.

Whats's the status here? Pagination would be nice for this default theme

Still the same

Thanks for all great work.. Looking forward for this feature

I was able to make it work following pull request of @DirtyF . Thanks for help.
https://github.com/prashanthmadi/prashanthmadi.github.io


Fix issue with res.render() in render util not being called with original view path

Fixes so that the render method calls res.render() with the original view path.
How to verify
(will be added soon)
Fixes #404

Coverage remained the same at 71.513% when pulling dd89f9a9aee656477a4ca2c1094f580b864e903c on fix-view-engine-res-render into 205f915ca5dcfe292253badf6cc0b9e503fa95f2 on master.

I fixed the test failure on master, we had to update an expected error string.  That change was unrelated to this issue.


Upgraded Doctrine ORM to 2.5.4.

The current Doctrine ORM version (2.5.1) doesn't work with PHP 7 type hints, it was fixed in the version 2.5.3.
DDC-4019: Proxy generator is not including PHP7 return type hints

Thank you for your pull request.
It looks like this may be your first contribution to an Oro, Inc. open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at http://www.orocrm.com/contributor-license-agreement/
If you've already signed the CLA, it's possible we don't have your GitHub username or you're using a different email address. GitHub uses the email address you set in your local Git configuration to associate commits with your GitHub account. Please sign the CLA again using the correct GitHub username and email address or see this help article on setting the email on your git commits.
Once you've signed the CLA, please allow for some time for the submission to be processed.

2.0 version of platform is already contains 2.5.5 version of doctrine/orm.
Thank you!

1.10 compatible with PHP 7.0 so issue above should not be a problem there.
As I know It is not planned yet to upgrade Doctrine ORM for 1.10. But even if it will be implemented you should know that for Community Edition we provides patch updates only for the latest LTS version, currently, this is 2.6 LTS. So even if an update will be scheduled it will be done only on Enterprise version.

1.10 is compatible with PHP 7.0, but doctrine/orm 2.5.1 is not.

yes, it doesn't support new features, but if you'll not use type-hint with php 7.0 this will work.


osquery logger fails to flush logs to file

If a user starts fleet with --osquery_enable_log_rotation, after a certain time, the log is not being written to disk.
Setting the flag to false, removes this problem. Because the lumberjack logger is used with osquery_enable_log_rotation it leads me to think that the bug is related to the lumberjack logger.
https://github.com/natefinch/lumberjack/issues/55 sounds suspicious.
Edit: looks like the logwriter can fail to write to disk even if it's not lumberjack. I will see if I can repro this under load.

In debugging this further I see that the logwriter can't deal with a deleted /tmp/osquery_result file.

ts=2017-11-15T14:23:33.745897Z component=service method=AuthenticateHost err=null took=3.462124ms
ts=2017-11-15T14:23:33.747546Z component=service method=SubmitResultLogs err=null took=502.252µs
ts=2017-11-15T14:23:34.728435Z component=service method=AuthenticateHost err=null took=3.448368ms
ts=2017-11-15T14:23:34.730132Z component=service method=SubmitResultLogs err=null took=540.144µs
ts=2017-11-15T14:23:35.699733Z component=service method=AuthenticateHost err=null took=3.989732ms
ts=2017-11-15T14:23:35.701558Z component=service method=SubmitResultLogs err=null took=512.859µs

cat /tmp/osquery_result
cat: /tmp/osquery_result: No such file or directory

you can try my writer(https://github.com/ilya1st/rotatewriter). It does not lock app on rotation. but there are no compression for rotated files. my first goal was handle SIGHUP correcty in one of my private projects.


💥 [DevOps] Enforce 60% coverage (backend)

💥 DevOps ticket

Enforce 60% coverage (backend)

This is not done yet or is it? @Mogge


fix: add nil checks for some functions

Add nil checks for functions oras.WithTargetPlatform, oras.FilterAnnotation and oras.FilterArtifactType.
Resolves #318
Signed-off-by: JasmineTang<EMAIL_ADDRESS>

Codecov Report

Merging #327 (76dcf07) into main (524c614) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #327      +/-   ##
==========================================
+ Coverage   71.79%   71.86%   +0.07%
==========================================
  Files          38       38
  Lines        3584     3593       +9
==========================================
+ Hits         2573     2582       +9
  Misses        754      754
  Partials      257      257

Impacted Files
Coverage Δ

copy.go
60.82% <100.00%> (+0.54%)
:arrow_up:

extendedcopy.go
69.49% <100.00%> (+1.07%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add detector classifier

Car should able to detect traffic light. Some files need to be reviews before merge.

Closing PR because the traffic light code was already merged in #7.


Issue with tests on urls that are valid and passed before or gave warning

https://inferno.healthit.gov/community/c8ezsf4EJ31/  This is the saved test for 2 tests Encounter and Allergy Intolerance.  These had passed on 08/18/2020, but then later in the week started getting does not resolve errors and does not pass.  Some of these are urls used in the Core examples, others are personal urls that were just getting warnings before.

This is a known issue with HL7 validator. We already have a solution.
https://github.com/onc-healthit/inferno/pull/502

Thank you!

https://inferno.healthit.gov/community/1fjo6jIl3ns/
This is an error we are seeing still on the extensions.  Please let us know what we need to do to pass.  Thanks!

Thanks for the update.  This is working now.

Thanks for the update.  This is working now.


[Bug] lazily adding extra libs did not trigger re-validation of semantic

Reproducible in vscode.dev or in VS Code Desktop?

[X] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[ ] Not reproducible in the monaco editor playground

Monaco Editor Playground Code
monaco.languages.typescript.typescriptDefaults.setDiagnosticsOptions({
    // I don't want to disable semantic validation.
	noSemanticValidation: false,
	noSyntaxValidation: false
});

function addLib() {
    console.log('adding lib...');
    // extra libraries
    var libSource = [
        'declare class Facts {',
        '    /**',
        '     * Returns the next fact',
        '     */',
        '    static next():string',
        '}'
    ].join('\n');
    var libUri = 'ts:filename/facts.d.ts';
    monaco.languages.typescript.typescriptDefaults.addExtraLib(libSource, libUri);
    monaco.editor.createModel(libSource, 'typescript', monaco.Uri.parse(libUri));
}

var jsCode = [
	'"use strict";',
	'',
	'class Chuck {',
	'    greet() {',
	'        return Facts.next();',
	'    }',
	'}'
].join('\n');

monaco.editor.create(document.getElementById('container'), {
	value: jsCode,
	language: 'typescript'
});

// `setEagerModelSync` would not help here.
// monaco.languages.typescript.typescriptDefaults.setEagerModelSync(true);

// Simulate adding libs lazily.
setTimeout(addLib, 2000);
// Changing timeout to `0` will make it work.

Actual Behavior
It shows Cannot find name 'Facts' while it shows class Facts above which indicates the lib has been loaded.
And when I make any edits, the error disappears.

I tried add monaco.languages.typescript.typescriptDefaults.setEagerModelSync(true) but it didn't help.
I think a re-validation of semantic should be done automatically after adding libs. Or Monaco should expose an API to do this.
Expected Behavior
Expect the error message disappears after libs loaded.
Additional Context
No response

Is this 0.31.1? If yes, this could have a similar cause as #2841. In that bug the _onDidChange event emitter somehow "lost" it's subscribers. In addExtraLib another event emitter _onDidExtraLibsChange is used. So my first gut instinct says they may be related, especially since the WorkerManager is also a subscriber here.

@spahnke Yes, it's 0.31.1.

Code below doesn't work either, and making any edits in editor after loaded libs will not make it working again:
function addLib() {
    monaco.languages.typescript.typescriptDefaults.addExtraLib(
        'export declare function add(a: number, b: number): number',
<EMAIL_ADDRESS>    );
}

const model = monaco.editor.createModel(
    `import {add} from 'math';\nconst x = add(3, 5);\n`,
    'typescript',
    monaco.Uri.parse('file:///main.ts')
);

monaco.editor.create(document.getElementById('container'), {model});

// Simulate adding libs lazily.
setTimeout(addLib, 2000);
// Changing timeout to `0` will make it work.

It seems that not only re-validation is missing, but also the lib has never been loaded.

Ran into the same issue. Here is a good way to reproduce it in playground. badVariable should always be marked as missing, but clicking the button should fix yourVariable. But it doesn't...
monaco.languages.typescript.typescriptDefaults.addExtraLib('var myVariable: string = "cheese"')
let editor = monaco.editor.create(document.getElementById('container'), {
value: "let ddd: string = 'tst';\nconsole.log(myVariable)\nconsole.log(badVariable)\nconsole.log(yourVariable)",
language: 'typescript'
});
let btn = document.createElement('button')
btn.innerText = 'Click to Fix'
document.getElementById('container').parentElement.prepend(btn);
btn.onclick = ()=>{
alert('Should fix yourVariable but doesnt')
monaco.languages.typescript.typescriptDefaults.addExtraLib('var yourVariable: string = "cheese"')
}

@alexdima Could you provide your estimates on this? Or maybe any workarounds? We're heavily relying on this and can't downgrade as several other bugs were resolved in the new version.

@hediet cc

@hediet Do you need any help with this? Or maybe you could share your estimation, please?

@alexdima Wow, thank you!
Could you please fix npm publish job so that we could test the change asap?
https://github.com/microsoft/monaco-editor/actions/runs/1788088945/workflow
Also, what users have you meant here?
https://github.com/microsoft/monaco-editor/blob/main/.github/workflows/publish.yml#L6
Repo owners?


Cannot access private folder on one iOS device

Hi,
I have three devices on my account - this computer (Linux), and two iOS devices (iPhone 8, iPhone 8 Plus), which I'll call the "old" one and the "new" one.
I am able to access my private folder on the Linux computer and the old iPhone, create files and see them show up on the other device, etc. Everything seems okay. However, on the new iPhone, I cannot open the private folder at all. A red bar pops up at the bottom of the content area which reads Failed to list folder: maeve.
I set up the new iPhone using the old iPhone, and it shows that when you click on it in the Devices listing. All my old devices are revoked. One revoked device was actually the old iPhone before I wiped and reinstalled it.
I have no idea how to fix this, and I am happy to have you delete the contents of the directory if that is necessary, as I've already moved the sensitive files to locally encrypted storage, so I'm copying the instructions found in https://github.com/keybase/client/issues/12285 and other issues:
BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkJcLRMo qLUoZVIoJJt1u7K 1iEtmLe4k5RRKDh 1VyvhCCD9Np7gNR 4IHaEDzUNfOu4v8 Snpn5vP6WIoz7An rCbKDO1FFeJWGyx 1UssyxCvD5dQx9c pSZzxOZSdQa4Hpb DktkeQMv8cPB28e C80KaeA6FymDmfQ aj6wWDtqDzZci5S gZQBq4RTteZz8OP eaPdVDnUMroughU m6WLVr23zTcpW3y 8asPlNIOLAodlq0 1YJNzdWa7Uy5bfj K1c3gDRAR4OBTtl oT0cGa70LKK1dkp sNo2Lvhn5JaNDLB wX7MWE0Po1DGxzH i6aSrK3SAItsrF9 t1GFjoZG7lhFRm. END KEYBASE SALTPACK SIGNED MESSAGE.

@maeveynot can you please send feedback with logs from your new iphone that's having the problem?  It's available from the in-app menu.  Mention me or this github issue in the feedback and I'll take a look.
On our side of things, everything seems fine -- all your current devices should have access to the folder.  It could be that the phone is still using an old version of the folder due to a caching bug, which will be fixed in the release that's coming out soon (today or tomorrow).

Sent!

Working now! Thank you.


Expand user's home in batch file path.

Address and close #9429.

Thanks.

That was fast! Thanks @dstftw ! :)


[serialization] safer serialization

In https://github.com/o1-labs/proof-systems/pull/160 I propose to use serde for serialization and deserialization.
There are a few problems with that:

we skip some fields, because in our current logic we do not deserialize them. This means that when you deserialize these structs, the Default implementation of these fields is used. You thus have to remember to fill them yourself. A better alternative would be to have an enum that prevents you to use the field if it hasn't been set. For example:#[serde(skip)]
pub fr_sponge_params: ArithmeticSpongeParams<F>,

or #[serde(skip)]
 pub srs: SRSValue<'a, G>,

we do not necessarily perform cryptographic validations on deserialization. For example, curve points might need to be checked to make sure they are on the curve. This is something that might not be relevant in the current use-case (caching structs to filesystem), but if we use this to serialize and deserialize types before sending them over the network this is something we need to be careful with.

I don't think the validation matters for now. We should have separate functions for that if we ever deserialize from untrusted source. But we should have these skipped fields be options.

In addition, we should remove serialization logic from the stubs in mina


How can i get the depth value before normalization?

Hi,
You should use the retrieveMeasure() function which give real world values.
Best,
/OB/


chore:update hessian 3.3.7 snapshot

Motivation:
Explain the context, and why you're making that change.
To make others understand what is the problem you're trying to solve.
Modification:
Describe the idea and modifications you've done.
Result:
Fixes #.
If there is no issue then describe the changes introduced by this PR.

Codecov Report

Merging #802 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #802      +/-   ##
============================================
+ Coverage     71.73%   71.74%   +0.01%
  Complexity     1081     1081
============================================
  Files           376      376
  Lines         15415    15415
  Branches       2465     2465
============================================
+ Hits          11058    11060       +2
+ Misses         3078     3077       -1
+ Partials       1279     1278       -1

Impacted Files
Coverage Δ
Complexity Δ

...alipay/sofa/rpc/registry/zk/ZookeeperRegistry.java
62.65% <0%> (-0.61%)
0% <0%> (ø)

...ofa/rpc/registry/zk/ZookeeperOverrideObserver.java
40.98% <0%> (+1.63%)
0% <0%> (ø)
:arrow_down:

...pay/sofa/rpc/transport/ClientTransportFactory.java
76.92% <0%> (+4.61%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


Renaming structs just creates new structs

Description
When renaming an already made struct in BinSync, this does not delete the old one.
Steps to reproduce the bug

Make a new struct
Rename it

Now you have two structs.
Environment
No response
Additional context
No response

Closed in #320


Kern County, CA - CSV Sender Onboarding

Sender Info:

Sender/Company Name: Kern County Public Health Services Department, CA
Type of Sender: Public Health
Location: CA
RS sender_id: kern-county-phsd-ca

Initial Interest & Follow Up

[x] Document the date & time the Sender expressed interest -- 1/26/2022

[x] Send Std Kickoff email.  This includes:
   - Links to TOS & TOS Registration
           - https://reportstream.cdc.gov/terms-of-service
           - https://reportstream.cdc.gov/sign-tos
   - Links to the CSV upload guide and CSV schema documentation
           - https://reportstream.cdc.gov/getting-started/testing-facilities/overview
   - Provide an option to have a Kickoff call to review these documents and answer any questions.

[ ] Schedule Kickoff / Q&A meetings at the Senders request.

[ ] Received TOS.

Sender Setup - Create OKTA group & OKTA account

[x] Define the RS sender_id  -- kern-county-phsd-ca
[x] Create an OKTA group for the sender_id
[x] Create an OKTA account using the RS Registration information.
[ ] Verify OKTA account registration by the Sender.

Sender Setup - Create Sender Settings for Staging & PROD

[x] Locally, create and test Settings in organizations.yaml
[x] Create the Staging & Production YAML settings files

Testing - Prod/Test Internal

[ ]  Move all RS development to Staging & PROD.
[ ] Make settings change to block results to the STLT, or send all results to the STLT's Test Feed.
[ ] Validate Production data and make all necessary RS changes.  Iterate through testing until validation is complete.

Testing - Prod/Test External (if required by the STLT

[ ] Contact the STLT to setup testing with Production data in their Production environment.
[ ] Verify which Feed the STLT wants to receive the results.  Make settings changes as-needed and deploy to PROD.
[ ] Work directly with the STLT to complete Integrated Testing and gain approval to move into Production.
- Prod/Test External (if required by the STLT)

Implementation - Plan & Schedule GO LIVE

[ ] Change setting "customerStatus:" to active from testing.
[ ] Contact RS Pipeline Team to turn on HHSProtect reporting.
[ ] Determine if there is a backlog of results.  If so, contact the STLT to determine what results are needed.  Example, in at one STLT, if a Sender has reported positives only to the STLT, then the STLT wants all COVID (positive & negative) since the Sender started testing.
[ ] Coordinate and schedule a start date for daily results and backlog results between the STLT and the Sender.

Implementation - GO LIVE and Post LIVE Review

[ ]  Monitor daily uploads for errors and contact Sender if results need to be corrected and resent.  Monitoring will typically be 1 week in duration unless issue are found.

1/27/22 - Kick off email sent by Adrian.

I missed the Slack message to set them up.  I'm doing it now.

Completed all Sender Setup.  Waiting on account activation.  Email'd Sender regarding account activation

2/8/22 Adrian received a response thru Shared Inbox that they awaiting supervisor approval to begin.
Reminder to ask why they want to use ReportStream?  The answer is probably because they use a different LIMS system than the State, so they are responsible for reporting to the State.

@Adrian-Brewster can we close this?


Allow passing --ignore-missing to sqlx::migrate! macro

The CLI's sqlx migrate run has a --ignore-missing flag which I'd love to be able to pass to the migrate macro.
Currently the migrate macro hardcodes ignore_missing: false
Currently it's used as such:
static MIGRATOR: Migrator = sqlx::migrate!();

It is possible to do it like this
static MIGRATOR: Migrator = {
    let mut m = sqlx::migrate!();
    m.ignore_missing = true;
    m
};

Would like something more ergonomic

in 0.7.0, you can write it as follows:
let mut migrator = Migrator::new(migration_folder)
    .await
    .expect("Migrator creation failed");

let migrator = migrator.set_ignore_missing(true);

// Then
migrator.run(my_pool).await;

@nipunn1313
Is this what you're looking for?
static MIGRATOR: Migrator = sqlx::migrate!("")
        .set_ignore_missing(true)

yep! That works!

Actually, it does not work.
expected Migrator found &Migrator because set_ignore_missing takes in &mut self and returns self. Would need to be more of a builder pattern.
Or alternately, an argument to migrate.


Larva obligated to Remain in the Hive and not perform Recon

About the PR

Added Rules from 13 Regarding larva, see attached image for details
Why / Balance

Parity
Technical details

Media

Requirements

[x] I have read and am following the Pull Request and Changelog Guidelines.
[x] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

:cl:

add: Ported Rules Restricting Larva's allowed zones

Test Fails are Unrelated to content included in the PR.

This is not enforceable without constantly checking replays of each round, which can only be done after the up to two or three hour round is over. This is a waste of resources.
It is the fault of the xenonid player and not the survivor if they seek out survivors and die because of it.
Additional solutions such as *roundstart larva taking damage off weeds is entirely possible and would be significantly more effective.
(*Either up to first drop which we have an event for, or after a time limit.)