GCP Cloud Provider: Source IP preservation for Virtual IPs

Description
Source IP Preservation - change Cloud load-balancer strategy to health-checks and respond to health check only on nodes that host pods for the service.
Progress Tracker

[x] Before Alpha

[x] Design Approval

[x] Design Proposal.  This goes under docs/proposals.  Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation.  Paste link to merged design proposal here: https://github.com/kubernetes/kubernetes/pull/30105
[x] Initial API review (if API).  Maybe same PR as design doc. PR-NUMBER

Any code that changes an API (/pkg/apis/...)
cc @kubernetes/api

[x] Write (code + tests + docs) then get them merged.  ALL-PR-NUMBERS

[x] Code needs to be disabled by default.   Verified by code OWNERS
[x] Minimal testing
[x] Minimal docs

cc @kubernetes/docs on docs PR
cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io

[x] Update release notes

[ ] Before Beta

[ ] Testing is sufficient for beta
[ ] User docs with tutorials

Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
cc @kubernetes/docs on docs PR https://github.com/kubernetes/kubernetes.github.io/pull/1062
cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

[ ] Thorough API review

cc @kubernetes/api

[ ] Before Stable

[ ] docs/proposals/foo.md moved to docs/design/foo.md

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

[ ] Soak, load testing
[ ] detailed user docs and examples

cc @kubernetes/docs
cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need.  Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs.  Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing.  They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

[ ] Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Notes:
Moving feature tracking issue https://github.com/kubernetes/kubernetes/issues/28647 from main repo to feature repo.

Does this involve preserving the visibility of the Source IP of the TCP connection that hits Pod which is behind a Service with an external IP address? Similar to what's discussed in https://github.com/kubernetes/kubernetes/issues/10921 ?

Yes, this is exactly that feature, sorry I haven't had time to convert the design proposal from Google doc into Markdown.

@girishkalele great to know. Can I ask a couple of questions for clarification?
We're operating Kubernetes for non-HTTP traffic (gRPC, and just plain TCP) on GCE using L3 Load Balancing (Network LB).  We rely on GCE network routes (programmed through Flannel) to direct the traffic to the Pod's IP address on a Worker Instance.
Ideally, what we'd like is the Frontend Instance kube-proxy would substitute the IP DST IP and port to point to the Pod's IP and port using DNAT. Then the GCE network/flannel stuff to do its magic and have the traffic end up on the Worker Instance and the Pod IP:port. Once our service running in the Pod responds, the kube-proxy on the Worker Instance would SNAT rewrite the SRC IP and port (which is the private Pod IP:port) to be the IP:port of the External service and drop it on the GCE network for egress. This would mean we get Direct Server Return (DSR) for free.
Is that roughly what you guys are thinking of doing?

@mwitkow
No...what we are planning is to eliminate the double hop by using GCE load balancer health checks. Instances/VMs that host endpoints in that service will respond healthy, and all other instances will respond unhealthy - thus, the GCE LB will split traffic only across nodes that host the service in local pods.

Does that mean that Source IP won't be preserved on non-GCE cloud providers?

Sorry, I should have said "Cloud Load Balancer" instead of GCE.
Source IP preservation will also be possible on other cloud providers, we just need to program the health checks using the provider's API - this will be an update in the pkg/cloudprovider/ package.
Note:
The new feature will be opt-in by adding an annotation in the service spec; the old LB behavior will still be the default. For cloud provider packages that are not updated, the annotation will be ignored. This will allow the contributors to catch up in subsequent releases without requiring a hard change-over for all providers in one release.

@girishkalele ok, that makes sense. But that means that the MASQUARADE step needs to go away (and be replaced with SNAT+DNAT I presume?), otherwise the service in the Pod won't see the SRC ip.

This is very close to what I am working on for [node-local services] (https://github.com/kubernetes/kubernetes/pull/28637), in that kube-proxy will have to go from a node-agnostic approach, where its iptables rules look the same on all nodes, to a node-aware one, where the rules and behaviour are tailored to each host.
@girishkalele, how do you plan on plumbing the node's IP through? It can be tricky on some cloud providers, namely AWS. And speaking of AWS, if you talk HTTP and X-Forwarded-For works for you, then you can already get the original source IP through the L7 annotations I implemented: https://github.com/kubernetes/kubernetes.github.io/blob/a135f0a717803b35ec80563768d5abb4b45ac4d1/docs/user-guide/services/index.md#ssl-support-on-aws
That said, removing extra hops is a great thing.

@mwitkow
Yes, we eliminate the SNAT (and Masquerade rules shouldn't be hit for traffic with external source ips).

@therc
I didn't need to pass the node IP to kube-proxy for this, atleast on GCE, none of the iptables rules need it for my purposes - did you have a need for it for the local-service implementation ?
I see the following note in that user-guide -
TCP and SSL will select layer 4 proxying: the ELB will forward traffic without modifying the headers.
The AWS LB looks like it will do L7 balancing with source ip transferred to the headers but for generic TCP services it wouldn't work. BTW, does it do websockets and HTTP ?

Please have these discussions on the design proposal. Let's try to keep the
feature repo meta.
On Mon, Jul 25, 2016 at 10:56 AM, Girish Kalele<EMAIL_ADDRESS>wrote:

@therc https://github.com/therc
I didn't need to pass the node IP to kube-proxy for this, atleast on GCE,
none of the iptables rules need it for my purposes - did you have a need
for it for the local-service implementation ?
I see the following note in that user-guide -
TCP and SSL will select layer 4 proxying: the ELB will forward traffic
without modifying the headers.
The AWS LB looks like it will do L7 balancing with source ip transferred
to the headers but for generic TCP services it wouldn't work. BTW, does it
do websockets and HTTP ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-235031200,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADIdQOMWMkobWz7VXMfT1V5oNl2a4Bfks5qZPjngaJpZM4JOTyt
.

Update: Code and docs merged - code activated only with alpha feature-gate flag.
E2Es cannot run till the E2E Jenkins job with the feature-gate ON is ready (WIP).

@girishkalele Please add docs PR numbers in the issue description

Ping.  Can you add the docs PR to the issue description?

@girishkalele docs PR question is still actual - please, add the links.

https://github.com/kubernetes/kubernetes.github.io/pull/1062

CCed kubernetes/docs in the Docs PR and also added to tracking spreadsheet.

@girishkalele FYI we've encountered an issue with the iptable rules used for external load balancing:
https://github.com/kubernetes/kubernetes/issues/33081

...this is so exciting. thank you all  for your hard work :-) making our lives easier

@kubernetes/sig-network @bprashanth  can you clarify the actual status of the feature?

hi everyone, reading the guide here http://kubernetes.io/docs/user-guide/load-balancer/#loss-of-client-source-ip-for-external-traffic it seems to me the feature is in alpha on GCE/GKE. I'm using a cluster 1.4 and trying to test the feature using the alpha annotation.
However, I still see a local ip address when I print it out in the log on my nginx pod using $remote_addr.
Anything am I doing wrong? Let me know if i should redirect this question to another group.
Thank you in advanced.
Best
David

@dgomezs may I ask you to create an issue in kubernetes/kubernetes repo? This repo is for managing and tracking the features, the actual coding and bug fixing work happens in that repo.

@idvoretskyi  Done.

Is this currently available on GCP in Alpha? If so, how is it enabled? We spun up an alpha cluster today and the x-forwarded-for header is still being replaced with a k8s IP. Used the "service.alpha.kubernetes.io/external-traffic": "OnlyLocal" annotation per http://kubernetes.io/docs/user-guide/load-balancer/#loss-of-client-source-ip-for-external-traffic with no luck.

@bprashanth can you update the actual status of the feature?

@bgabler As far as I understand, you cannot enable alpha features. You need an alpha cluster.

Ping. Is there a docs PR for this?

Not yet, we have till end of week right (isn't realease only Dec 7 ish)?
As of 1.4 it's alpha
As of 1.5 it's beta (same annotation, s/alpha/beta)

You had until yesterday to write a docs PR :)  Can you get me one today?

@girishkalele can you confirm that this item targets stable in 1.6?

Girish is no longer involved in this - @bprashanth has taken responsibility for it.

This is a huge issue for us. Any update on when we can expect this? In the meantime we're running NGINX on compute to add a custom header to the request as it passes through to a k8s service.

This is alpha in 1.4, and beta in 1.5.  Go nuts! :)
On Thu, Dec 15, 2016 at 12:15 PM, Ben Gabler<EMAIL_ADDRESS>wrote:

This is a huge issue for us. Any update on when we can expect this? In the
meantime we're running NGINX on compute to add a custom header to the
request as it passes through to a k8s service.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-267432245,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVEGnPjWr2XUU_qG3c8UQA0pfBqqWks5rIZ_-gaJpZM4JOTyt
.

Everything went so smooth the past few weeks for me when deploying stuff onto k8s but now this. Damn :(

@thockin does this only apply to k8s on GCE?

It should work on GCE and Azure for LB VIPs and it should work on any
platform for NodePorts (I think - @bprashanth to confirm)
On Mon, Dec 19, 2016 at 12:07 PM, Hans Kristian Flaatten <
<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin does this only apply to k8s on GCE?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-268064756,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVDi3xSX_JB7-lNMGArk3S4suTM_fks5rJuQXgaJpZM4JOTyt
.

I am on gke with updated cluster to 1.5.1 in euw1d and forward proto and and ip works but port is 5xxxx instead of 80/443(in my case).

@ivanjaros You'll have to be more explicit about what you're hoping to acheive, what you did, and what happened.  I don't know how to interpret your message.

I have nginx as proxy. Maybe I need to use different variable than $remote_port?

$server_port

That worked perfectly. Thanks aledbf.

Is it enough to add "service.beta.kubernetes.io/external-traffic": "OnlyLocal" annotation for services on a 1.5.1 cluster? It doesn't seem to work for me, still sees cluster ip.

That annotation currently works only in GKE.

What leads you to believe it only works on GKE?  There's nothing at all GKE specific in this code path.
@rxwen yes, settingWhat leads you to believe it only works on GKE?  There's nothing at all GKE specific in this code path. the annotation should be sufficient.  Can you tell me if, after that is set, whether you get another annotation set (automatically) with the "heathcheck nodeport" ?

http://kubernetes.io/docs/user-guide/load-balancer/#loss-of-client-source-ip-for-external-traffic
"However, starting in v1.5, an optional beta feature has been added that will preserve the client Source IP for GCE/GKE environments. This feature will be phased in for other cloud providers in subsequent releases."

I don't know. As a matter of fact, after I saw your previous comment, I believe it should work on a bare-metal cluster, nodeports type service (Though @bprashanth hasn't yet confirmed) .
If I understand correctly, after I set this annotation for a service, in addition to this annotation, a new annotation "heathcheck nodeport" should be applied to the service as well?
I'll check it and test again.

Key there is "GCE/GKE" not just GKE :)
On Mon, Jan 2, 2017 at 10:49 PM, Ivan Jaros<EMAIL_ADDRESS>wrote:

http://kubernetes.io/docs/user-guide/load-balancer/#
loss-of-client-source-ip-for-external-traffic
"However, starting in v1.5, an optional beta feature has been added that
will preserve the client Source IP for GCE/GKE environments. This feature
will be phased in for other cloud providers in subsequent releases."
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-270059288,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVH925L5IatAb4G_6eshAUdLjcQibks5rOe-MgaJpZM4JOTyt
.

On Mon, Jan 2, 2017 at 10:49 PM, rxwen<EMAIL_ADDRESS>wrote:

I don't know. As a matter of fact, after I saw your previous comment, I believe it should work on a bare-metal cluster, nodeports type service (Though @bprashanth hasn't yet confirmed) .

on BareMetal you have the pieces you need to make it work, mostly (I
think the nodeport healthchecking is wrong, @bprashanth we should fix
that ASAP for 1.6 tree), but you have to glue it together yourself
(since no cloud provider module)

If I understand correctly, after I set this annotation for a service, in addition to this annotation, a new annotation "heathcheck nodeport" should be applied to the service as well?
I'll check it and test again.

Correct.  That annotation is a signal that your annotation was
received and handled.

on BareMetal you have the pieces you need to make it work, mostly (I think the nodeport healthchecking is wrong, @bprashanth we should fix that ASAP for 1.6 tree), but you have to glue it together yourself (since no cloud provider module)

Does it mean on a 1.5.1 cluster, in addition to setting the annotation for a service, I need to make other configuration to make it work? If so, any guidance about what other configuration should I make?

On GCE it should just work.
On BareMetal, you need to configure the load-balancer to use the new
healthcheck-nodeport when routing traffic toward VMs, so it will not send
traffic to a VM with no backends.
On Mon, Jan 2, 2017 at 11:00 PM, rxwen<EMAIL_ADDRESS>wrote:

on BareMetal you have the pieces you need to make it work, mostly (I think
the nodeport healthchecking is wrong, @bprashanth
https://github.com/bprashanth we should fix that ASAP for 1.6 tree),
but you have to glue it together yourself (since no cloud provider module)
Does it mean on a 1.5.1 cluster, in addition to setting the annotation for
a service, I need to make other configuration to make it work? If so, any
guidance about what other configuration should I make?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-270060051,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVMkCQgIYdTgtWDFUI4GcdXoyxpc9ks5rOfIZgaJpZM4JOTyt
.

Does this feature have the nice side effect of fixing the lack of node health-checks in GCE L4 LBs created by "type: LoadBalancer" service definitions ? This is obviously causing service interruptions when upgrading nodes, because the L4 LB keeps sending traffic to down nodes, in the absence of any health check.
Is enabling implementing source IP preservation, even when you don't really care about the source IP, the recommended solution to this problem ? See my other comment here : https://github.com/kubernetes/kubernetes/issues/32827#issuecomment-271662756

Status update: I'm working on moving this feature to GA in 1.6.

We've tried enabling on GKE, no luck

@bgabler You should be able to use this feature with v1.5 on GKE, or v1.4 with Alpha Cluster. What issue did you encounter enabling this?

Just to confirm, we add the following annotation to a loadbalancer:
service.beta.kubernetes.io/external-traffic: "OnlyLocal"

Example:
`
apiVersion: v1
kind: Service
metadata:
labels:
name: foobar
app: foobar
release: "foobar"
heritage: "foobar"
name: "foobar"
annotations:
service.beta.kubernetes.io/external-traffic: "OnlyLocal"
namespace: "foobar"
spec:
clusterIP:
ports:

name: app
port: 443
selector:
name: "foobar"
sessionAffinity: None
type: LoadBalancer
`

@bgabler As this might not be the right place to discuss, could you please open an issue regarding this on kubernetes/kubernetes and provide more details and ping me? Thanks!

Not sure what changed but its actually working now.
We did notice some weird http2 issues so we had to tell our tyk gateway
to turn off http2

Ben Gabler
561.308.1171
Email<EMAIL_ADDRESS>Website: http://www.bengabler.com
LinkedIN: http://www.linkedin.com/in/bengabler
Twitter: http://www.twitter.com/ben_gabler
On 1/24/17 4:51 PM, Tim Hockin wrote:

Are you on kube v1.5 to use the "beta" annotation?
On Tue, Jan 24, 2017 at 1:32 PM, Zihong Zheng<EMAIL_ADDRESS>wrote:

@bgabler https://github.com/bgabler As this might not be the right
place to discuss, could you please open an issue regarding this on
kubernetes/kubernetes and provide more details and ping me? Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/kubernetes/features/issues/27#issuecomment-274945401,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AFVgVKI-RdlAr0jiXsIcRoAM_XgoWQfvks5rVm3jgaJpZM4JOTyt

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-274965256,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG7dYAntLxnXEcXU1dIekGjxTP7bBkSuks5rVoCBgaJpZM4JOTyt.

Is this feature supported in AWS ?
I tried adding the proposed annotation to the service but it didn't work! I have created a repo to create a minimalistic cluster to replicate my issue. (with same config its working in GKE just like that)

@Phanindra48 I'm afraid it is not fully supported on AWS yet. Please use kubernetes/kubernetes#35758 and kubernetes/kubernetes#35187 for tracking.

Oh! thanks for the info @MrHohn. Is there any work around for making it work in aws as our application depends on source ip?
I have created repo that contains config to create a cluster in aws (our cluster is almost similar to that).

AWS's ELB does not preserve the client IP at all.  Whether Kubernetes saves
it or not won't matter much.
On Mar 5, 2017 7:00 PM, "Phanindra Pydisetty"<EMAIL_ADDRESS>wrote:

Oh! thanks for the info @MrHohn https://github.com/MrHohn. Is there any
work around for making it work in aws as our application depends on source
ip?
I have created repo https://github.com/Phanindra48/k8s-source-ip-aws
that contains config to create a cluster in aws (our cluster is almost
similar to that).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/27#issuecomment-284291477,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVFVCvm9vzYnykCzA8Ho8VfP9Cun-ks5ri3blgaJpZM4JOTyt
.

The Classic LB's do, in the way that L7 LB's are expected to, using X-Forwarded-For, see: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html

@Phanindra48 what is your application?  Is it HTTP?  Because on AWS you have (at least) 3 choices for preserving the source IP:
a) Enable proxy protocol on the ELB using an annotation (any protocol, but requires you to parse the proxy protocol header)
b) Set the ELB into layer 7 mode using an annotation (HTTP/HTTPS only)
c) Use ingress with the nginx controller, enabling proxy protocol and telling nginx to process the proxy protocol for you
I like option c best.  Option b works well also, but you are dealing with the limitations of ELB HTTP support at that point.  Option a works with non-HTTP/HTTPS, but requires code changes.

Hi @justinsb, We got a micro-services architecture with around 10 services running on NodePort under nginx-ingress controller which is of type LoadBalancer (only external endpoint for us) and we have an ingress for all rules to divert the traffic to different services.
I tried adding annotation like shown here https://github.com/Phanindra48/k8s-source-ip-aws/blob/master/nginx-controller.yaml, but it didn't work. It actually removed the instances from LoadBalancer (couldn't register because of failing health checks).
So, as I'm using ingress with the nginx controller, option c seems like the best approach. Could you please tell which command should I add in nginx configmap to make it work?

@tomte76 There wouldn't be healthcheck nodeport assigned to OnlyLocal NodePort service. This is the expected behavior.
For the specific issue you encountered (seeing MASQ adress in logs), it would be great if you could provide more details --- which cloud provider, what commands you ran, iptables-save output on node, tcpdump result.
Could you please open a new issue on kubernetes/kubernetes and ping me so that we could follow up there. This feature issue is not the right place for bug report.

Acutally I have to admin, that  I don't know how to "ping" :) I opened an issue #44963 (Unexpected behaviour using "OnlyLocal" annotation on NodePort with 1.6.1 and Weave-Net 1.6) and provided some information. If you need any more please let me know

@MrHohn Should this be listed for GA in 1.7

@cmluciano Yes, kubernetes/kubernetes#41162 is out for this purpose.

/assign

Trying to get this feature working on v1.7.0-alpha.2 using flanneld with --ipmasq and kube-proxy with iptables mode. I want to receive traffic on a node directly and preserve the source IP as it is routed to the ingress-controller. I've tried using the NodePort service with the service.beta.kubernetes.io/external-traffic: OnlyLocal annotation, but echoheaders is still giving me <IP_ADDRESS> as the realip (where 10.100.35.x is the flannel/docker subnet for the node)

@Malet This source IP preservation feature has issues with some overlay network plugins (like flannel and weave), please see kubernetes/kubernetes#44963 for details.

@MrHohn @bprashanth @kubernetes/sig-network-feature-requests please, update the feature description to fit the new template.

Feature Description

One-line feature description (can be used as a release note): Source IP Preservation - change Cloud load-balancer strategy to health-checks and respond to health check only on nodes that host pods for the service.
Primary contact (assignee): @MrHohn
Responsible SIGs: sig-network
Design proposal link (community repo): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/external-lb-source-ip-preservation.md
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @thockin @freehan @bprashanth
Approver (likely from SIG/area to which feature belongs): @thockin
Feature target (which target equals to which milestone):

Alpha release target (1.4)
Beta release target (1.5)
Stable release target (1.7)

@idvoretskyi Could you please copy my previous post onto the top one? I don't yet have the privilege to edit post.

@MrHohn thanks!

Quick update on this feature:

Codes and tests  are merged: https://github.com/kubernetes/kubernetes/pull/41162

I'm now working on updating the existing docs to reference the new first class fields instead of beta annotations.

@MrHohn thanks

I've tried running with NodePort and the OnlyLocal annotation (bare-metal/flannel) but receive no traffic on local pod.  When the annotation is applied to the service, packets are not marked for masquerading in iptables but still always dropped by a rule that states "servicexyz has no local endpoints".  This is not the case, however - the service does indeed have load endpoints.  My guess is that, the health-check is failing.  Is this likely the case, and if so, what do I need to do in order that the health-check succeeds?

@liggetm Please open an issue for this on the main kubernetes repository.

@cmluciano will do.

@idvoretskyi This feature is complete for 1.8. Is there anymore to do with this issue or do we just close it?

This feature was promoted to GA in 1.7 and the release has been shipped. I believe we can close this.
/close

I've noticed that on GKE running a NodePort service + Ingress that this feature causes the backend to be marked as "UNHEALTHY" when I inspect the ingress with kubectl describe ing ingress (presumably because most nodes are failing the health check). Are there any negative side-effects to this or is it safe to ignore?

@unclewizard Is your GET / are available (HTTP code, 200 OK) for GCP healthy check?

@chy168 Yep - here is a simple way to reproduce:
Follow the instructions here: https://cloud.google.com/container-engine/docs/tutorials/http-balancer but when you get to Step 2, use the following yaml to create the nginx service:
apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    service.beta.kubernetes.io/external-traffic: "OnlyLocal"
spec:
  selector:
    run: nginx
  ports:
  - name: nginx
    port: 80
  type: NodePort

After you create the Ingress service in Step 3, wait about 10 minutes and then do a kubectl describe ing basic-ingress. The output will contain something like:
  ...
  backends:		{"k8s-be-30910--7b4223ab4c1af15d":"UNHEALTHY"}

If you visit the Ingress address you'll see that the page loads fine. I suspect the UNHEALTHY message doesn't actually matter but I wanted to make sure this is expected.

@unclewizard That is expected. When externalTrafficPolicy is set to Local, nodes that don't have backend pods run on it will intentionally fail LB health check.
Though backend service could contain multiple backends, the backends annotation only shows the healthiness of one of them, that seems incorrect. Opened https://github.com/kubernetes/ingress/issues/1395.

That is expected. When externalTrafficPolicy is set to Local, nodes that don't have backend pods run on it will intentionally fail LB health check.

Sorry, I said it wrong. We internally fail healthcheck for L4 LB but not L7. Backend service shouldn't show as "UNHEALTHY".
@unclewizard  Could you open a separate issue on https://github.com/kubernetes/ingress? Thanks.

Sorry for spamming, please ignore what I said on previous post. I need some sleep :(


Fix issue #81

This MR does the following:

Removes memset() for the sake of assignment + default constructor
Refactors sample notebook in order to add PATH to CUDA under Windows.

I confirm that #81 is fixed,
For adding CUDA PATH under Windows, we only need to add the CUDA\bin directory:
if os.name == "nt":
    # Add CUDA_PATH env variable
    cuda_path = os.environ["CUDA_PATH"]
    if cuda_path:
        os.add_dll_directory(os.path.join(cuda_path, "bin"))
    else:
        raise StopExecution

Hope you can update the sample notebook and the unit tests


Chore/bubble data hash error

Description
Propagate error to user if data being hashed has invalid square size (not a power of 2) while doing basic validation of block.
Returns nil block while making a new block with invalid data.
Returns nil hash for an incorrectly constructed block
Relevant files:

types/block.go
types/block_test.go

Checks:

[ ] Test case for returning nil block for invalid data
[ ] Test case for get nil hash for incorrectly constructed block

Ps: I'm not quite sure about this one, seems like returning a nil Block could be unexpected behaviour in a lot of places
Closes: #728

Ps: I'm not quite sure about this one, seems like returning a nil Block could be unexpected behaviour in a lot of places

same tbh, I think I created this issue due to some feedback somewhere, but I wish I had more context into why this should be switched from a panic. Its an unexpected state that means something is seriously wrong, so it feels like panicking is the appropriate thing to do.
I'll dig around and try to find the reason for this. We want to remove the ability to compute shares entirely from tendermint, and completely rely on the app for checking/generating it. In that case in particular, we want to panic if there isn't a hash already set in the block data.

I think changing this to return an error would be a mistake. Especially since in all use outside of tests that don't in the application, we should never reach the spot that is returning an error. In fact, it seems like a good thing to panic.
thanks for bring this to my attention @rahulghangas and sorry for not clearing out this issue sooner.
I think we should close this unmerged and close the issue as well.


Update list of CI users

Description
Adding @youngeunkwon0405 to list of authorized CI users.
Type of change

[ ] Documentation change (change only to the documentation, either a fix or a new content)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Infra/Build change
[ ] Code refractor
[x] Testing

Changes
Please list the changes introduced in this PR:

Update list of CI users

Checklist:

[x] I have read and followed the contributing guidelines
[x] The functionality is complete
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Also adding @KshitijLakhani to list of authorized users.


Zip operator

Hey,
A proposal of the zip operator.
It's called ZipFromObservable as we may also implement a zip from an iterable or something else tomorrow.
Furthermore, I also implemented a BiFunction type as described here: https://github.com/ReactiveX/RxGo/issues/85

See my comment https://github.com/ReactiveX/RxGo/pull/79#issuecomment-441798839 regarding the build failure.

Pull Request Test Coverage Report for Build 153

0 of 14 (0.0%)  changed or added relevant lines in 1 file are covered.
233 unchanged lines in 7 files lost coverage.
Overall coverage decreased (-26.7%) to 52.547%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

observable/observable.go
0
14
0.0%

Files with Coverage Reduction
New Missed Lines
%

observer/observer.go
1
72.5%

observable/create.go
2
80.77%

observable/flatmap.go
2
100.0%

subscription/subscription.go
3
100.0%

errors/errors.go
9
100.0%

handlers/handlers.go
15
100.0%

observable/observable.go
201
98.16%

Totals

Change from base Build 141:
-26.7%

Covered Lines:
361

Relevant Lines:
687

💛  - Coveralls

Pull Request Test Coverage Report for Build 153

0 of 14 (0.0%)  changed or added relevant lines in 1 file are covered.
233 unchanged lines in 7 files lost coverage.
Overall coverage decreased (-26.7%) to 52.547%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

observable/observable.go
0
14
0.0%

Files with Coverage Reduction
New Missed Lines
%

observer/observer.go
1
72.5%

observable/create.go
2
80.77%

observable/flatmap.go
2
100.0%

subscription/subscription.go
3
100.0%

errors/errors.go
9
100.0%

handlers/handlers.go
15
100.0%

observable/observable.go
201
98.16%

Totals

Change from base Build 141:
-26.7%

Covered Lines:
361

Relevant Lines:
687

💛  - Coveralls

See https://github.com/ReactiveX/RxGo/pull/95


data-aos="fade-right" not working in Safari

Hello, I have 4 images in a row and i want them to fade right. I've put a data-aos-delay="150" on the second, data-aos-delay="300" on the third and data-aos-delay="450" to the fourth. They work in Chrome, but not in Safari. In Safari the last image is not showing up in an animation, it just appears. Could you please take a look?

same issue here, AOS not working in safari.


[Bug]: Add the disclaimer back in each learning plans + in the about us page

Issue description
Can you please add the disclaimer we had on the old platform to each learning plan and in the about us page?
Where did this happen?
About us + each learning plan page.
What do you expect?
Add the following line for the learning plans:
Disclaimer:
Please be aware that the content herein has not been peer reviewed. It consists of personal reflections, insights, and learnings of the contributor(s). It may not to be exhaustive, nor does it aim to be authoritative knowledge.
Add the following line for the about us:
Disclaimer:
Please be aware that the content published here has not been peer reviewed. It consists of personal reflections, insights, and learnings of the contributor(s). It may not to be exhaustive, nor does it aim to be authoritative knowledge.
What browsers are you seeing the problem on?
No response
Add any other relevant details
No response

Noted with thanks. This will be available with the coming release in #77


Update cats-effect to 2.5.0

Updates org.typelevel:cats-effect from 2.4.1 to 2.5.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "cats-effect" } ]

labels: library-update, semver-minor

Superseded by #119.


CIP-0051? | Preserve submitter's ordering of transaction inputs

This CIP proposes a small change to the ledger specification allowing for optimisation in certain script validator executions.

There was some talk about switching inputs from a set to a list for Babbage because set is messy to work with for Plutus. I'm not sure if this ended up being included in the list of changes that will make it into the update though

There was some talk about switching inputs from a set to a list for Babbage because set is messy to work with for Plutus. I'm not sure if this ended up being included in the list of changes that will make it into the update though

No, this is not a part of the Babbage spec, for the reasons @WhatisRT mentioned above. At the very least, in needs more careful thought.

Oh, also it's wrong to describe this as "deterministic" transaction input ordering. The ordering is definitely deterministic, it's just not the same as the one in the transaction format. "Fixed" transaction ordering might be a better way to describe it.

The script has to properly validate the information it uses anyway, which should always require traversing the full input set. Relying on the ordering of the inputs seems very dangerous, since an attacker could use this to hide information from a script that isn't carefully validating its inputs. And checking that no such hidden information is present is pretty much exactly what is required to find the relevant inputs.

As @michaelpj mentioned (https://github.com/cardano-foundation/CIPs/pull/231#discussion_r823779435), script inputs are already ordered and scripts can already rely on that ordering if they so choose. This CIP does not change that fact.
The CIP merely seeks to preserve the order of inputs that the transaction submitter sets when constructing the transaction, instead of the current approach of ordering transactions lexicographically by (1) their originating transaction's ID and (2) by their output index within that transaction. This would allow the transaction submitter to order the inputs in a way that better aligns to script logic, in the same way that this can currently be done with transaction outputs.
For example, consider a protocol with a transaction class that zips a variable-length (i.e. batchable) list of "pairs" [(A id,B id)] of inputs into a list of outputs [C id]. If input ordering is preserved, then the submitter can submit a transaction with the following inputs and outputs:
inputs = [A 1, B 1, A 3, B 3, A 5, B 5]
outputs = [C 1, C 3, C 5]

The script could iterate in parallel through the outputs (one element at a time) and inputs (two elements at a time), and verify that:

They are relevant to the protocol – i.e. they contain a token, datum, and/or script address that indicates that they belong to the protocol.
That they match each other – e.g. (A 1, B 1, C 1) should match, but (A 1, B 2, C 1) shouldn't match.

This is quite straightforward and efficient to achieve if the script and transaction submitter can coordinate via the input/output ordering. It is much harder if the inputs are ordered according to their original (TxId, OutputIndex), which is irrelevant in most contexts.

Oh, also it's wrong to describe this as "deterministic" transaction input ordering. The ordering is definitely deterministic, it's just not the same as the one in the transaction format. "Fixed" transaction ordering might be a better way to describe it.

I suggest "Preserve submitted transaction input ordering"

Relying on the ordering of the inputs seems very dangerous, since an attacker could use this to hide information from a script that isn't carefully validating its inputs.

I also don't think this is too much of a concern: many applications don't care about what's going on with the other inputs, and can safely ignore them.

I have another concern about this, which is interoperability. If this CIP would be implemented, I'd expect that most scripts (at some point in the future) would require the inputs that script cares about to be at the beginning of the list of inputs, simply because of convenience. This means that people would only be able to execute multiple scripts in the same transaction if those scripts were explicitly designed with that in mind. This is a significant change from how things work today: scripts that don't know and care about each other can be run in the same transaction, even if they were never intended to be executed simultaneously with other scripts.

That same issue is present today with, say, outputs. If scripts A and B both care about outputs O_A and O_B, it's easy for A to be lazily written to require O_A to be the first output, and likewise for B. So I'm not sure this makes things worse.

I happened to be thinking about this again, and I think what @michaelpj's comment suggests is that the order of the outputs should not have been preserved either. We could have just sorted them as well, which would have gives us better interoperability defaults. We can't change that anymore since people might rely on it somewhere, but we could strongly discourage using that information in our APIs. So while I'm not sure this CIP would make things worse, I'm also not sure that it doesn't make it worse.

I happened to be thinking about this again, and I think what @michaelpj's comment suggests is that the order of the outputs should not have been preserved either.

I think this is true if what we primarily cared about was encouraging scripts not to make bad assumptions. But in fact the aim was mostly just to accurately represent the structure of the transaction, and I still think that's a good default.

I might have said what I meant in a way that's a bit confusing: I wouldn't want to throw away ledger information, I think that the ledger should reorder them and that should be accurately represented. In an alternate universe we could've had a version of Shelley that does sort outputs, and in hindsight I'd have preferred that.

(last label application was my operator error)

So this is fait accompli because it's already being implemented

This is not being implemented AFAIK.

Yes, no plans on the ledger side. I also still believe that this is a step in the wrong direction, since it doesn't actually simplify much as scripts still have to check that the inputs are what they expect, see above. Instead it adds another pitfall (forgetting to properly check that the order is correct) and it may worsen interoperability.

@gege251 closing because of lack of support from Plutus team(s) indicated above.

Please reopen this. If you guys saw the codebases of any of the DEXs you would understand why this is such a big deal. The crazy non-sense they all do (that introduces a ton of complexity and room for vulnerabilities) to reconstruct the necessary of inputs within the transaction is actually revolting, and the DEXs that don't do this ugly reconstruction can only fit roughly half as many requests in a batch. In addition to the absolutely massive efficiency benefits, it actually solves the double satisfaction issue, because you can match the corresponding outputs based on their indices (ie input at index 1 must correspond to output at index 1).

@colll78 (@euonymos) I hear your statement (and support) but this is not an issue for implementation: it's a technical document which particularly the Plutus team decided not to support in their implementation.  It would make no difference if we reopened or even merged this pull request as a CIP if it's not something they're going to do.
@michaelpj @WhatisRT please, on the off-chance that the last 7 months have led to the IOG Plutus or Ledger team doing anything as requested, or anything else that would mitigate the problem reported especially by DEXes, then can you post here?  If so we can add it to the CIP meeting agenda in 3 days' time when Plutus reps are expected to be present.
@colll78 the general problem of DEXes sounds like a good subject for a CPS (Cardano Problem Statement) if it remains unaddressed by any other CIP or development plan.  Can you check first to see if any of these are applicable? https://github.com/cardano-foundation/CIPs#cardano-problem-statements-cps-1
... especially this one, which I think covered the "double satisfaction" problem? https://github.com/cardano-foundation/CIPs/tree/master/CPS-0005

Historical note: this effort is continuing through candidate CIP-0128: https://github.com/cardano-foundation/CIPs/pull/758


String type in Field.Create return compile error string cannot be nullable

Hi,
I got a compiler error when trying to create a string field
Field.Create("test","firsttest")
return TDATA canot be nullable
Thanks in advance

+1 it seems like this restriction can and should be lifted since the field type can be created as string when defining the collection schema at collection creation.

@luisquintanilla This was also what we were looking at with SDK possibilities. Based upon last response here let's discuss what we should or shouldn't do on next week.

I work on ASP.NET and C# would like to discuss this further. Is there a slack channel our team can join so, we can have discussion

@luisquintanilla @LadyNaggaga This is also something that what we were looking/discussed at with SDK possibilities. Based upon last response here let's discuss what we should or shouldn't do on next week.

I work on ASP.NET and C# would like to discuss this further. Is there a slack channel our team can join so, we can have discussion

@LadyNaggaga I created a channel already for us  in Milvus for follow-up & invited you to the follow-up with Luis

can someone give me the slack link? the link from the main project is broken. I want to contribute to this .net sdk

I make a PR to fix this issue here https://github.com/milvus-io/milvus-sdk-csharp/pull/9

can someone give me the slack link? the link from the main project is broken. I want to contribute to this .net sdk

I believe Slack channel info is provided here: https://milvus.io/community


Add support for WebSocket transport

This PR aims to add a WebSocket transport implementation provided by tungstenite-rs and tokio-tungstenite-rs. Currently the implementation of this transport is based entirely on the existing WebTransport implementation as I've found it to be most fitting, given they are both web transport apis. Some structures from WebTransport were reused for this implementation, such as WebServerDestination
This addresses issue #16
Here is the current state of things (Some of which can be done in one or more PR's):

[x] Server impl (to be revised: tls, if needs encryption or not depends on ws or wss and clean up copy paste leftovers)
[ ] Client impl (todo)
[ ] Documentation (todo)
[ ] Feature conditional compilation (todo)
[ ] Add WebSocket transport to echo_server_cross example (todo)

Building off this PR here (WIP): https://github.com/UkoeHB/renet2/tree/websockets

Implemented in https://github.com/UkoeHB/renet2/commit/4acb9bc9971e815bcdaff529928899842b61a852


Rename permission docs path to plural

A minor annoyance and inaccuracy that the docs section titled "Permissions" can't be navigated to by accessing backstage.io/docs/permissions/overview ... now it can!
Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

Aight, although this will break links to the existing pages. For example the todo-list plugin READMEs need an update as well right? Would also need to check blogposts and so on

Good catch on this, updated the todo list plugin READMEs. We're in luck, because the blog posts seem to have no references to the permission docs yet.
I did a bit of digging to see if docusaurus will let us create secondary paths for redirects (for exactly cases like these) but it doesn't seem like that's supported. 😞


OS Monitor

OS Monitor
Application: EmergencyManagerService
Package name: com.sec.android.emergencymode.service
Version: <IP_ADDRESS>
Process: com.sec.android.emergencymode.service
UID: 1000
First used: 14:22:30
Last used: 16:22:06
Total used: 19:00:00
Time in foreground: 19:00:00

What is this. I got a back door person


haskellPackages.nvfetcher: add to top-level

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build nvfetcher

This looks good, thanks for adding yourself as maintainer!

Thanks for noting that, the upcoming version requires generateOptparseApplicativeCompletion, and I'll add this new one and move them to configuration-common.nix at once.


Unable to receive requests using HTTP DELETE/PUT/PATCH handlers

Seems to work fine with the any method and I can see the appropriate method being listed under the req.getHeader('access-control-request-method') header but for some reason I can get these handlers work using their respective methods.

Can you post the full code you are using? probably doing something wrong?

Server (not working):
  .del('/', (res, req) => {
    let origin =  req.getHeader('origin')
    res.writeHeader('Access-Control-Allow-Origin', origin);
    res.writeHeader('Access-Control-Allow-Credentials', 'true');
    res.end();
  })

Server (working):
  .any('/', (res, req) => {
    let origin =  req.getHeader('origin')
    res.writeHeader('Access-Control-Allow-Origin', origin);
    res.writeHeader('Access-Control-Allow-Credentials', 'true');
    res.end();
  })

Client:
    fetch('http://localhost:9001/', {
        method: 'DELETE',
    })
    .then(result=>{
        result.text().then(data=>console.log(data))
    })
    .catch(err=>console.log(err))

I just tried those examples you posted and they are working, what do you mean by not working? possibly more code you are leaving out for full example?

Okay - Not sure what I was doing wrong but seems to be working fine now :| Thanks for the help! I will close this now.

I will leave this comment here in case someone runs into a similar issue.
I was testing my API through an application served on a different port (both localhost), this made it a cross site request.
Cross site requests get processed into two calls an options call to ensure the server accepts the type of request you're trying to make and then the actual call you intended to make.
In order to to use non get/post routes I had to setup an .options route to with the appropriate Access-Control-Allow-Origin and Access-Control-Allow-Methods.
Hope that helps!

I will leave this comment here in case someone runs into a similar issue.
I was testing my API through an application served on a different port (both localhost), this made it a cross site request.
Cross site requests get processed into two calls an options call to ensure the server accepts the type of request you're trying to make and then the actual call you intended to make.
In order to to use non get/post routes I had to setup an .options route to with the appropriate Access-Control-Allow-Origin and Access-Control-Allow-Methods.
Hope that helps!

Man, how the .options worked? Could you please post that here.


Typo in "aws secret key" config variable referece in AmazonS3ModuleImpl

ReadMe of this module asks the dev to declare the aws secret key in the "conf" file with the key "aws.secret.key"
But, in the code (AmazonS3ModuleImpl) this is being read with the key "aws.access.secret". Hence, it isnt being resolved and the error "S3Module is not properly configured" is being thrown.
To align with the aws naming conventions, change the reference in the code to "aws.secret.key" and leave the doc as it is.

@0xbaadf00d created a PR for this. Thanks!

Thank your @prakashvadrevu. PR has been merged with success.


HttpXHRPlugin broken in 3.0.0

Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
3.0.0
Can you reproduce the issue with our latest release version?
3.0.0 is the latest at the point of opening of the issue so yes.
Can you reproduce the issue with the latest code from master?
Not tried yet.
Are you using the demo app or your own custom app?
No, but it happens on a minimalist page with some "necessary interactions" to use HttpXHRPlugin instead of the deafult fetch-based one.
If custom app, can you reproduce the issue using our demo app?
Can I set the default scheme handler to XHR on the demo app?
What browser and OS are you using?
Chrome 83.0.4103.97 on Windows 10
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
I am on a PC.
What are the manifest and license server URIs?
Happens before playback start so does not matter I think.
What did you do?
Add this snippet to a minimalist player page.
// Make the XHR-based HTTP plugin the default (shaka 2.4+)
if (shaka.net.HttpXHRPlugin) {
    shaka.net.NetworkingEngine.registerScheme('http', shaka.net.HttpXHRPlugin,
    shaka.net.NetworkingEngine.PluginPriority.PREFERRED);
    shaka.net.NetworkingEngine.registerScheme('https', shaka.net.HttpXHRPlugin,
    shaka.net.NetworkingEngine.PluginPriority.PREFERRED);
}

What did you expect to happen?
Playback should work normally.
What actually happened?
Playback failed with:
Error code undefined object TypeError: Cannot read property 'timeMs' of undefined
    at destroyer.js:63
    at Ob (networking_engine.js:188)
    at multi_map.js:39

Thanks for the report.  I'll start working on repro and a fix, but in the mean time, can you explain why XHR should be preferred over the more modern Fetch API if both are available?

We used XHRPlugin as the basis for our "hybrid delivery" as it is tricky to "emulate" fetch in full.

I'm trying to reproduce this on ChromeOS 83.  I commented out the registration of the Fetch-based scheme plugin to force the use of XHR, then recompiled the library and demo.  I tried running this in uncompiled, debug, and compiled mode.  In all three, I can confirm in the debugger that the XHR plugin is being used, but I can't reproduce the error you mentioned:

Error code undefined object TypeError: Cannot read property 'timeMs' of undefined

Finally I realized the root of the issue.  The signature of the plugin has changed in v3.0.0.  Instead of registering the plugin class's constructor, you register its static .parse method: shaka.net.HttpXHRPlugin.parse.
This is mentioned in the upgrade guide, under the heading "Built-in network scheme plugin changes": https://shaka-player-demo.appspot.com/docs/api/tutorial-upgrade-v2-5.html

Built-in network scheme plugin changes
Some of the built-in network scheme plugins have changed their API.  Instead of
registering the class itself, they now register a static parse() method on
the class.  Any applications with scheme plugins that delegate to these
built-in plugins MUST update to call the new methods.
This affects the following classes:

shaka.net.DataUriPlugin
shaka.net.HttpFetchPlugin
shaka.net.HttpXHRPlugin

// v2.5:
function MySchemePlugin(uri, request, requestType, progressUpdated) {
  return shaka.net.DataUriPlugin(
      uri, request, requestType, progressUpdated);
}
shaka.net.NetworkingEngine.registerScheme('data', MySchemePlugin);

// v3.0:
function MySchemePlugin(uri, request, requestType, progressUpdated) {
  return shaka.net.DataUriPlugin.parse(
      uri, request, requestType, progressUpdated);
}

Does this help?

Yes thank you a lot 👍  (my bad as I missed this change when reading the long list of API changes).


'package:flutter/src/rendering/object.dart': Failed assertion: line 1645 pos 12: '!_debugDoingThisLayout': is not true.

Hi
Thanks for a great plugin, but I just installed an I get this exception when using it
'package:flutter/src/rendering/object.dart': Failed assertion: line 1645 pos 12: '!_debugDoingThisLayout': is not true.
I followed the example on my project.
Here doctor output
$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel master, v1.10.3-pre.46, on Microsoft Windows [Version 10.0.18362.418], locale en-ZA)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[!] Android Studio (version 3.4)
    X Flutter plugin not installed; this adds Flutter specific functionality.
    X Dart plugin not installed; this adds Dart specific functionality.
[√] VS Code (version 1.39.1)
[√] Connected device (1 available)

! Doctor found issues in 1 category.

This looks like an issue unrelated to modal_progress_hud. Were you able to fix it?


Perform case-insensitive comparison

Hi! 👋 Labels are case-insensitive, so the checks done by this action must take that into account. I encountered this issue when I configured this action to detect ios label in my repository, but since the actual label name is iOS, it got ignored.
This PR fixes this issue by transforming labels to lowercase before comparing them. The added test fails before the change and passes after the change.

@akashivskyy thanks for the fix here! looks good - happy to merge and cut a version for this.  Would you mind running npm run build then checking in the dist files that get written?

@mattcosta7 Done!

shipped in 0.0.5


env variables config

Hi!
I'm using symfony 4 and when I try to set the config parameters fom env variables, a throw execption is launched because try to check if the queue name finish with ".fifo"
//qpush.yaml
uecode_qpush:
logging_enabled: true
providers:
opta:
driver: aws
region: '%env(AWS_SQS_REGION)%'
queues:
opta_messaging:
provider: opta
options:
message_timeout: 30
queue_name: '%env(resolve:AWS_SQS_QUEUE_NAME)%'
push_notifications:     false
notification_retries:   3
message_delay:          0
message_expiration:     0
fifo:                        true
content_based_deduplication: false
messages_to_receive:    1
receive_wait_time:      3
//.env
###> aws/aws-sdk-php-symfony ###
AWS_SQS_REGION=us-east-2
AWS_SQS_QUEUE_NAME=testing.fifo
###< aws/aws-sdk-php-symfony ###
The env variables are encripted, then the real name is not set. As you see I trie to use the resolve in the env variable, but not function.
Thank you.

I'm also struggling with this
This block checks the name of the queue at compile time and hence any attempt to use '%env(...)%' in the bundle's config fails as the following regex executes on the actual string '%env(...)%'
// Check queue name ends with ".fifo"
$isQueueNameFIFOReady = preg_match("/$(?<=(\.fifo))/", $values['options']['queue_name']) === 1;
if ($values['options']['fifo'] === true && !$isQueueNameFIFOReady) {
     throw new InvalidArgumentException('Queue name must end with ".fifo" on AWS FIFO queues');
}

Would it be possible to remove this check, or would you think of an alternative?

At the moment I think that the best way is remove this check, because in other part of the code this is checked (isQueueFIFO()), but only the option, it's posible to add there the regex expression also to check the name?
Thanks


Python2 and Python3 compatible README.md read

Collecting le-utils==0.1.24 (from -r requirements/base.txt (line 18))
  Downloading https://files.pythonhosted.org/packages/f7/5e/e499293c64010ca8e22d126c29b26c3255c41ecc74b7e903e5f1f2a34a54/le-utils-0.1.24.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-wjbv6qqa/le-utils/setup.py", line 3, in <module>
        long_description = open('README.md').read()
      File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2845: ordinal not in range(128)

This should make a new release if possible please. This is interfering with Kolibri make docker-whl Makefile target (among other things)
PR will be inbound for that too

le-utils==0.1.25 up on PyPI https://pypi.org/project/le-utils/
thx for the fix!
On Fri, Jul 24, 2020 at 7:46 AM Lewis Cowles<EMAIL_ADDRESS>wrote:

This should make a new release if possible please. This is interfering
with Kolibri make docker-whl Makefile target (among other things)
PR will be inbound for that too
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/learningequality/le-utils/pull/74#issuecomment-663500107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABIA7XWPFO6PIDQKBWDENDR5FYA5ANCNFSM4PGUK6SQ
.

I had anticipated more discussion around this. As long as your python2 is 2.7, this should not be an issue.
AFAIK io was backported to ship with 2.7.x.
I used this same fix many years ago when I was into trying to support two major runtimes and this worked for me. I sort of wanted some others to confirm it works for them, although I suppose they can pin to 0.1.24 so it's not the end of the world, it might be a violation of semver.


Footnotes on table at bottom of page

Need a way to get footnotes attached to a table at the bottom of the page.  There is a difference between the item of attachment and the layout.  Should have flexible layout, but still allow the footnotes to change from one table to another.  This is when multiple pieces of content are in the same report.

valign parameter already added.  This is a redundant issue.


Castle.MicroKernel.Lifestyle.WebRequestScopeAccessor

Hello.
I have just updated a solution with a few projects.
And i get the following error.

at Nancy.Bootstrappers.Windsor.NancyPerWebRequestScopeAccessor..ctor()
at lambda_method(Closure , Object[] )
at Castle.Core.Internal.ReflectionUtil.Instantiate(ConstructorInfo ctor, Object[] ctorArgs)
at Castle.Core.Internal.ReflectionUtil.Instantiate[TBase](Type subtypeofTBase, Object[] ctorArgs)
at Castle.Core.Internal.ReflectionUtil.CreateInstance[TBase](Type subtypeofTBase, Object[] ctorArgs)
at Castle.MicroKernel.DefaultKernel.CreateScopeAccessor(ComponentModel model)
at Castle.MicroKernel.DefaultKernel.CreateLifestyleManager(ComponentModel model, IComponentActivator activator)
at Castle.MicroKernel.Handlers.DefaultHandler.InitDependencies()
at Castle.MicroKernel.Handlers.AbstractHandler.Init(IKernelInternal kernel)
at Castle.MicroKernel.Handlers.DefaultHandlerFactory.Create(ComponentModel model)
at Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.CreateHandler(ComponentModel model)
at Castle.MicroKernel.DefaultKernel.AddCustomComponent(ComponentModel model)
at Castle.MicroKernel.Registration.ComponentRegistration1.Castle.MicroKernel.Registration.IRegistration.Register(IKernelInternal kernel)    at Castle.MicroKernel.DefaultKernel.Register(IRegistration[] registrations)    at Castle.Windsor.WindsorContainer.Register(IRegistration[] registrations)    at Nancy.Bootstrappers.Windsor.WindsorNancyBootstrapper.RegisterModules(IWindsorContainer container, IEnumerable1 moduleRegistrationTypes)
at Nancy.Bootstrapper.NancyBootstrapperBase`1.Initialise()
at Nancy.Owin.NancyMiddleware.UseNancy(NancyOptions options)
at Owin.AppBuilderExtensions.UseNancy(IAppBuilder builder, NancyOptions options)
at DatabaseRest.Startup.Configuration(IAppBuilder app) in C:\foobar\Startup.cs:line 83

Could not load type 'Castle.MicroKernel.Lifestyle.WebRequestScopeAccessor' from assembly 'Castle.Windsor, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.

I'm using castle.windsor v5 and Nancy.Bootstrappers.Windsor 1.4.1 (i have tried v2 too)
Am i doing something wrong?
Thanks!

We see the same issue, we had to move back to Castle.Windsor 4.1.1

I had the same issue. Turned out it was a third party library that I was using that caused this (in my case it was the deprecated Castle.Windsor.Lifestyles because I wanted to use the Hybrid lifestyles). If that's also your case, you can fork the library, correct the dependencies and use the forked one in your code.

Added Pull #58 to address this. May need some assistance to get it working with Cake. But would really like to get a new v2.0.0 of this package out there if possible please.
https://github.com/NancyFx/Nancy.Bootstrappers.Windsor/pull/58

Hello again.
I have tried to use the 2.0.0 version of nancy(during the process of updating nuget packages) and i get the same error.
Is it supposed to have been fixed?
Sorry i'm just confused.

Finally i have used your repo and everything is fine.
But why isn't it yet merged ?
Thanks!

I gave up trying to get help to merge it. In the end I pulled the few classes into our repo with a plan to migrate away from NancyFx

I agree!
Thanks again!


Several connections

It would be great to have several sickrage connections within the same app

This request already exists in https://github.com/MGaetan89/ShowsRage/issues/12.


XcodeProj Writable conformance does not include WorkspaceSettings

Context 🕵♀
I need to prevent Xcode from automatically creating schemes by setting IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to false in WorkspaceSettings.xcsettings.
What 🌱
WorkspaceSettings already supports this via autoCreateSchemes, so I initialized XcodeProj with custom WorkspaceSettings in order to disable this feature; however, the WorkspaceSettings.xcsettings file that WorkspaceSettings represents is never created when the project is written:
let sharedData = XCSharedData(workspaceSettings: WorkspaceSettings(autoCreateSchemes: false))
let project = XcodeProj(workspace: xcworkspace, pbxproj: pbxproj, sharedData: sharedData)

try project.write(path: path) // WorkspaceSettings's write method is never invoked, so WorkspaceSettings.xcsettings is not written

Proposal 🎉
XcodeProj's Writable conformance includes methods for writing other aspects of XCSharedData, including schemes (XcodeProj.swift:159) and breakpoints (XcodeProj.swift:196).
My proposal is to create a new method called writeWorkspaceSettings with the following signature:
public func writeWorkspaceSettings(path: Path, override: Bool = true) throws {
    // Unwrap `sharedData`
    // Invoke `sharedData.workspaceSettings.write(path: workspaceSettingsPath, override: override)`
}

This method will be called within XcodeProj's write method (XcodeProj.swift:85), resulting in WorkspaceSettings.xcsettings being written:
public func write(path: Path, override: Bool = true, outputSettings: PBXOutputSettings) throws {
    try path.mkpath()
    try writeWorkspace(path: path, override: override)
    try writePBXProj(path: path, override: override, outputSettings: outputSettings)
    try writeSchemes(path: path, override: override)
    try writeBreakPoints(path: path, override: override)
    try writeWorkspaceSettings(path: path, override: override) // Invoke new method here
}

P.S. XCSharedData does not conform to Writable, meaning that XcodeProj.swift contains the implementation for writing schemes and breakpoints to file, accounting for 77 of the files 207 lines. The addition of a new method for writing WorkspaceSettings will only add further bloat.
Would it make sense to add Writable conformance to XCSharedData so that methods like writeSchemes, writeBreakpoints, and the proposed writeWorkspaceSettings can be moved within XCSharedData? This would greatly simplify the XcodeProj.swift file and would result in a write method that looks like the following:
public func write(path: Path, override: Bool = true, outputSettings: PBXOutputSettings) throws {
    try path.mkpath()
    try writeWorkspace(path: path, override: override)
    try writePBXProj(path: path, override: override, outputSettings: outputSettings)
    try writeSharedData(path: path, override: override) // Unwrap `sharedData` and invoke `sharedData.write` method
}

I'm happy to contribute a PR to resolve the issue described above assuming the proposal makes sense!

Hey @dayton-bobbitt I'm working on a PR to integrate the xcuserdata folder and because a *.xcuserdatad folder can also contains schemes I had to rewrite this logic a bit.. also conforming XCSharedData to Writable.
I just stumbled on the WorkspaceSettings not being written and when looking of existing issues I found your issue! Shall I call WorkspaceSettings.write(path:override:) inside of XCSharedData in my PR, or shall I leave it as is so you can fix it and maybe write some tests for it?

Hey @teameh! I wouldn’t mind making the change and adding some additional tests.
Do you want me to make the change in your branch or is your PR almost ready to merge, in which case I can just wait to branch off main until then?

Cool. See https://github.com/tuist/XcodeProj/compare/main...teameh:XcodeProj:xcuserdata-support for my branch. PR will follow tonight or tomorrow.

Finished updating so that WorkspaceSettings are written when calling XCSharedData's write method. See https://github.com/teameh/XcodeProj/compare/xcuserdata-support...dayton-bobbitt:XcodeProj:write-workspace-settings?expand=1
Planning to open PR against main once https://github.com/tuist/XcodeProj/pull/739 is merged.


[SPARK-37423][PYTHON] Inline type hints for fpm.py in python/pyspark/mllib

What changes were proposed in this pull request?
Inline type hints for fpm.py, test.py in python/pyspark/mllib/
Why are the changes needed?
We can take advantage of static type checking within the functions by inlining the type hints.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests

CC @zero323 @HyukjinKwon @ueshin, please take a look if you have time. Thanks!

Ping @zero323 , Very glad if you help me resolve this PR! TIA :smiley:

Merged into master and branch-3.3.


Various editorial changes

...strewn across several commits at this point. The last commit is bigger questions that I didn't feel I could resolve on my own.

There are still (four?) questions suggestions inline in 4.0. Behaviour.md that should be addressed/removed before merging.


ContextRoot path does not account for multiple domains using same path - feature suggestion

Problem
https://github.com/ehazlett/interlock/blob/master/docs/interlock_data.md#context-root
Based on my experimentation, using ContextRoot doesn't support multiple hosts nor domains for same
path as stated. It would be nice to have context and domain/host.
The current code (v1.1.1) replaces Domain with the ContextRoot:  https://github.com/ehazlett/interlock/blob/b2b86fb042520535ba5e72a09f959c97cb57e733/ext/lb/haproxy/generate.go#L48 . Which means using the Domain or HostName in templates is not possible.
Example
(Note my current deployment is using the host to differentiate environments, but we could use part of domain)
curl http://myapp-qa.company.co/api/v1/resource
curl http://myapp-acceptance.company.co/api/v1/resource

Solution ideas

Not mutating Domain
Adding fields interlock.context_domain and/or interlock.context_host(this would leave current code path intact)

Example template use:
 {{ range $host := .Hosts }}
 ...
# use both rules even on ContextRoot
acl ctx_{{ $host.Name}} path_beg -i / {{ $host.ContextRoot.Path }}
acl is_{{ $host.Name }} hdr_beg(host) {{ $host.Domain }}

backend ctx_{{ $host.Name}} if is_{{ $host.Name }} ctx_{{ $host.Name}}
...

TL;DR

Am I approaching this problem correctly with Interlock + HAProxy?
Should I have one HAProxy per environment (less ideal)?
Which solution is ideal? (I might take a stab at a PR)

Thanks,
Hank

When I first did the feature the requirements given were extremely vague. I think not mutating the domain is the best thing. Thanks for the feedback!

This should be fixed in #216.  Can you try ehazlett/interlock:dev to see if that fixes?  Thanks!

We are tracking most of this discussion in #206.  Closing this one.  Thanks!


Only use testing EventGroups for CMMS correctness test.

Testing EventGroups are identified by a reference ID prefix. The EventGroups created by EdpSimulator use this prefix. This helps prevent other EventGroups from interfering with the correctness test.

This change is

Fixes #779


Support multi value cookies?

CGI, Dancer, Plack, and I'm sure many other languages and libraries have the concept of a multi value cookie where the individual values are escaped and then concatenated with ampersand to form the raw header. For more details see the corresponding Dancer bug - https://github.com/PerlDancer/Dancer2/pull/1325
Would you be opposed to someone extending bake_cookie at least to take an array ref for the value? Changing crush_cookie might hurt expectations, but extending bake_cookie would be using what is currently an error.

Hey, sorry for the long time to respond, had to deal with some family issues.
I am not opposed at all. Not sure how useful it would be to just modify bake_cookie without also modifying crush_cookie.
Can you provide some code? At least some tests (which would break today) showing how you expect this to work, for both bake_cookie and crush_cookie?
Cheers!

Hey, I haven't had a chance to work on the implementation yet, but I was thinking of a design something like this:
bake_cookie foo => [ 'bar&baz', 'qux' ];

# or

bake_cookie foo => { value => [ 'bar&baz', 'qux' ] };

# should produce a value of "foo=bar%26baz&qux"

So each of the array values are URI escaped and then concatenated with ampersand.
The crush side should work like this:
my $values = crush_cookie $cookie;

# $values could have array ref values like "{ foo => [ 'bar&baz', 'qux' ] }"

Obviously all of this would be in addition to the scalar interface, so some kind of SvTYPE(...) == PVAV if check at the top of back_cookie would dispatch to the escaping logic in a loop, or something. I doubt we need to worry about array ref overloading.

Hi @JRaspass, I was wondering if this is still needed?

@gonzus it would definitely be a nice to have, ATM Dancer 2 works around it by using the pure perl implementation with multi value cookies.

Hi again @JRaspass,
I just wanted to let you know that I have a first implementation of multi-valued cookies. I need to clean it up a bit, I expect to do that tomorrow.
Pinging @xsawyerx as well, I know he will be happy to hear this. :-)

This is pushed now, will soon release a new version.

Awesome! Thanks @gonzus

Just uploaded HTTP-XSCookies-0.000017.tar.gz to CPAN.

Great stuff! :)


Version v2.2.2

Summary
This PR contains fixes to be included in v2.2.2, cherry-picked from master; let me know if I missed any.
Commits related to release itself:

https://github.com/DisnakeDev/disnake/pull/135/commits/2dc95d2cf35b74c5b46272424190be03a0bc1530
https://github.com/DisnakeDev/disnake/pull/135/commits/8896bc4c0f0ec75d74f246111e73116852ea79f4

Checklist

[x] If code changes were made then they have been tested

[x] I have updated the documentation to reflect the changes
[x] I have formatted the code properly by running black .

[x] This PR fixes an issue
[ ] This PR adds something new (e.g. new method or parameters)
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

3a68767d9671db452cfb4d87f93d4ca04f17789e is also fairly important, since the examples are already updated for it but they don't actually work that way in the latest release yet.

Isn't it included?

Isn't it included?

Ye, it is, I just mentioned it since it's one of the two main fixes in this list. The others are primarily docs or other minor fixes.


feat: add documentation tests to CI

The --all-features test already covers this. It seems like adding a lib crate type enabled running these.
See #38.


FAQs need a revamp

Many of the items listed at https://zeek.org/faq/ are outdated.

Piggy-backing. It's not possible to deep-link at specific entries of the FAQ. Would be nice if that worked.

There's a draft of the next iteration of the FAQs here — people are welcome to comment.
I am planning to turn this into a wiki page next week.


WX version compatibility for Gooey, Pip, Conda, and OS platforms

Placeholder for working out how best to structure Gooey's WX dep such that installs across different package managers, platforms, and OSs can all work (mostly) seamlessly, or at least have a useful escape hatch.
Problems:

WX's minor versions are not stable, as such, Gooey is very conservative with its deps and locks WX to a known stable version
The WX version Gooey uses isn't available in package managers like Conda.
There doesn't appear to be a single blessed WX version which can satisfy all installation requirements (for instance, the previous 4.0.7 caused issues on Linux)

Planned Solution:
Gooey will loosen its grip on developing against a single known stable WX version, and work with a sliding window starting from 4.1.0 up to current 4.1.1 (and onward as relevant).

The WX version Gooey uses isn't available in package managers like Conda.

I assume this is in reference to https://github.com/conda-forge/gooey-feedstock/issues/6 which is no longer true. All WX versions are on conda atm.
Also, as of now Gooey insists on installing wxpython==4.1.0 (hardcoded in setup.py) which prohibits using any different version even if compatible. I'd suggest reverting it back to wxpython>=4.0.7 or even earlier if known to work.

Going back through the issue history a bit, it looks like I misspoke. People had trouble getting 4.0.7 installed on Linux, which the 4.1.0 bump resolved. So, there was a driver there beyond just getting things up to date.

I think there's a fundamental difference in thinking here. No package (Gooey, etc) need concern itself about whether its dependencies are easy to install. It simply should state the minimum version required, leaving it up to the end user to decide what to install.
pip install gooey["wx>=4.1.0"] sounds as crazy as pip install "gooey-psutil-5.4.2[wx>=4.1,pillow>=4.3,colored>=1.3.93,pygtrie>=2.3.3]"
It sounds like Gooey's deps should definitely be changed from wxpython==4.1.0 to wxpython>=4.0.7.
If a particualr user is having difficulty installing wxpython==4.0.7 then they can simply pip install gooey "wxpython>=4.1"

P.S. I'm on linux and have installed wxpython==4.1.0 via conda

The difference in thinking probably comes from me wearing the maintainer hat. Incentives shift based on perspective. Supporting a range of potentially non-backwards compatible WX versions is much harder to do on my end versus having a single canonical "good" version. FWIW, writing code to patch around version incompatibilities is what led to WxPython taking its current 'break everything' approach. Keeping things backwards compatible across dependency versions when that dependency keeps breaking its API introduces a lot of cruft into everything.

It simply should state the minimum version required (and incompatible versions), leaving it up to the end user's package manager to decide what to install.

This ignores the messy reality in favor of the ideal. I'd love to just set a minimum and be done with it. However, by design, WX does not follow semvar nor guarantee backwards compatible releases. This fact is what led to using a locked down 'stable' version in the first place. Having Gooey stop working for everyone because wx broke an API during a minor point release is an obnoxious way to spend a weekend.
All that said, I can just bite the bullet and make sure Gooey works well with 4.0.7 - 4.1.1 and then slowly extend the upper supported versions as they come available.

I don't follow. My last suggestion (wxpython>=4.0.7,<=4.1) is about not artificially making old versions incompatible. As you say, "then slowly extend the upper supported versions as they come available."
When you say "make sure Gooey works well with 4.0.7 - 4.1.1" - I was under the impression that it does, and there's no effort required there... If you know the current state of gooey is incompatible with 4.0.7 then please drop it (rather than bother fixing it). I'm finding fault with dropping it without reason.

My last suggestion (wxpython>=4.0.7,<=4.1) is about not artificially making old versions incompatible. As you say, "then slowly extend the upper supported versions as they come available."

OK. After rereading your comments several more times, I realize I've been misunderstanding what you're suggesting as well as talking about something slightly different.

4.0.7 is not compatible with current Gooey versions. I injected a lot of confusion into the topic by suggesting that as a 'free' option
Given the above, I was coming at this from a perspective of supporting it in spite of its incompatibility (+ issues from future WX versions). So, this was all from the vantage point that, given that the world is not ideal, and WX releases are what they are, and people have issues installing certain WX versions, what could Gooey do to make installing everywhere easy -- even if that meant carrying along some cruft in its code base to enable other WX versions to be used.

No package (Gooey, etc) need concern itself about whether its dependencies are easy to install. It simply should state the minimum version required (and incompatible versions)

FWIW, I somehow missed the "and incompatible versions" bit which I why I was talking about the ticking time bomb which would come from WX under a balnket >= setup. In short, I was mistaken. Whoops!
So, TL;DR here, I'll update setup.py/requirements to use wxpython>=4.1.0,<=4.1.1 and run with that model going forward.

Ah ok great, I hadn't realised either that 4.0.7 actually isn't compatible. Sure, no problem - I don't expect anyone to "fix" that :)

Hi,
Getting an error with widgets example. simple and subparser run fine.
Thanks,
Mickey
GooeyExamples$ python ./examples/widget_demo.py
Writing Build Config to: ./examples/gooey_config.json
Gtk-Message: 22:35:43.923: Failed to load module "canberra-gtk-module"
Traceback (most recent call last):
  File "./examples/widget_demo.py", line 83, in <module>
    main()
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/python_bindings/gooey_decorator.py", line 87, in inner2
    return payload(*args, **kwargs)
  File "./examples/widget_demo.py", line 74, in main
    my_cool_parser.parse_args()
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/python_bindings/gooey_parser.py", line 114, in parse_args
    return self.parser.parse_args(args, namespace)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/python_bindings/gooey_decorator.py", line 82, in run_gooey
    application.run(build_spec)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/application.py", line 21, in run
    app = build_app(build_spec)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/application.py", line 30, in build_app
    gapp = GooeyApplication(merge(build_spec, imagesPaths))
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/containers/application.py", line 43, in __init__
    self.configs = self.buildConfigPanels(self)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/containers/application.py", line 221, in buildConfigPanels
    for widgets in self.buildSpec['widgets'].values()]
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/containers/application.py", line 221, in <listcomp>
    for widgets in self.buildSpec['widgets'].values()]
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/components/config.py", line 16, in __init__
    self.layoutComponent()
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/components/config.py", line 92, in layoutComponent
    self.makeGroup(self, sizer, item, 0, wx.EXPAND | wx.ALL, 10)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/components/config.py", line 136, in makeGroup
    widget = self.reifyWidget(parent, item)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/components/config.py", line 187, in reifyWidget
    widgetClass = getattr(widgets, item['type'])
AttributeError: module 'gooey.gui.components.widgets' has no attribute 'TimeChooser'

Hi again,
I forced conda install -c conda-forge wspython=4.1.0
GooeyExamples$ python ./examples/widget_demo.py
Writing Build Config to: ./examples/gooey_config.json
Gtk-Message: 22:45:23.054: Failed to load module "atk-bridge"
Gtk-Message: 22:45:23.056: Failed to load module "canberra-gtk-module"
Traceback (most recent call last):
  File "./examples/widget_demo.py", line 83, in <module>
    main()
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/python_bindings/gooey_decorator.py", line 87, in inner2
    return payload(*args, **kwargs)
  File "./examples/widget_demo.py", line 74, in main
    my_cool_parser.parse_args()
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/python_bindings/gooey_parser.py", line 114, in parse_args
    return self.parser.parse_args(args, namespace)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/python_bindings/gooey_decorator.py", line 82, in run_gooey
    application.run(build_spec)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/application.py", line 21, in run
    app = build_app(build_spec)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/application.py", line 30, in build_app
    gapp = GooeyApplication(merge(build_spec, imagesPaths))
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/containers/application.py", line 42, in __init__
    self.header = FrameHeader(self, buildSpec)
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/components/header.py", line 33, in __init__
    self.layoutComponent()
  File "/home/mickey/miniconda3/envs/blurmvp2.2/lib/python3.7/site-packages/gooey/gui/components/header.py", line 77, in layoutComponent
    PAD_SIZE)
wx._core.wxAssertionError: C++ assertion "!(flags & wxALIGN_CENTRE_HORIZONTAL)" failed at /home/conda/feedstock_root/build_artifacts/wxpython_1603889841103/work/ext/wxWidgets/src/common/sizer.cpp(2106) in DoInsert(): Horizontal alignment flags are ignored in horizontal sizers

I don't know whether this will be helpful, but in debugging some issues I found that I had multiple versions of Python installed on my system:  3.6 (64-bit) and 3.8 (32-bit).    Revisiting the issues produced some problems with wxPython, but the difficulties were resolved by removing and reinstalling the base installations of Python on our system (a W10 box).

FYI the conda installation was fixed for gooey>=1.0.8 https://github.com/conda-forge/gooey-feedstock/issues/6

Dependency version has been changed to >=4.x


Pull/MergeReqstraight.h

Does this work? If not, could you kind of (give some hints) on what I did wrong, as I am new to Github and am kinda lost on this? Thanks! :)
Describes your contribution
Referenced Issues
closes #issue_number

@DanielZhang111 Our project has different fonts that print characters in a specific style style. You can find these fonts in the Fonts directory. Each font has two files - a header file and a markdown file. A preview for each character is present in the associated markdown file. You refer to that when defining the function for the character you want to add.
You define the function in the associated Header file. For Straight font, that would be the straight.h file. We have already provided the body for all functions in the comments. You need to uncomment and make the required changes.
Now, each character is a 2D grid. The rows and columns for the grid depend upon the specific character. All you need to do is fill this grid as per the preview.
https://github.com/codewithnick/ascii-art/blob/8afb0692287f19a2af59fd5e6821dec48e54e6f6/Fonts/Straight/straight.h#L188-L197
For testing, you use the example.cpp file. Set the font to the font you're working on and print the character.
https://github.com/codewithnick/ascii-art/blob/8afb0692287f19a2af59fd5e6821dec48e54e6f6/example.cpp#L8-L10
I hope this helps answer your question. If there is anything else, feel free to ask.

As I can see you haven't uncommented the function but have added some lines. You know C++, right?

I'm still kind of confused...

@DanielZhang111 what programming language do you know?

None :/ I'm new to this lol

Oh, I see. it's a tricky situation. Well in that case I would suggest you better learn first. Once you become a bit more proficient, feel free to contribute here. I might not be hacktoberfest, but open source stays open all year. I hope you understand @DanielZhang111

Ok, I will come back to this hopefully sometime in the future!

@DanielZhang111 will look forward to that 🫡

Ok ! :)


Compile errors after applying patches

I'm using waf to apply a collection of patches to backstage prior to compiling it. The patches are all successfully applied but the build process has two compile errors.
Expected Behavior
backstage should compile (and run) after the patches are applied.
Current Behavior
I get the following two errors during the build process:
plugins/auth-backend/src/lib/oauth/helpers.ts:39:5 - error TS2345: Argument of type 'Dictionary<string | undefined>' is not assignable to parameter of type 'string | Record<string, string> | string[][] | URLSearchParams | undefined'.
  Type 'Dictionary<string | undefined>' is not assignable to type 'string'.

39     pickBy(state, value => value !== undefined),
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

plugins/catalog-import/src/components/StepPrepareSelectLocations/StepPrepareSelectLocations.tsx:55:34 - error TS7006: Parameter 'l' implicitly has an 'any' type.

55     prepareResult?.locations.map(l => l.target) || [],
                                    ~

Found 2 errors.

error Command failed with exit code 1.

Note that neither of these files are patched!
Context
I'm currently unable to build my backstage application.
Your Environment

NodeJS Version (v14): 14.17.5
Operating System and Version (e.g. Ubuntu 14.04): MacOS Catalina

Few questions:

What is waf?
What patches are you trying to apply? Is it coming from the CHANGELOGS of Backstage packages?
What version of auth-backend are you on? Try bumping it and see if the errors disappear?

@OrkoHunter  I hope this helps a bit:

waf is a meta-build system
I created the patch files by creating a private branch from master, applying a series of edits/commits to that branch and running git format-patch master. The waf build then clones a specific commit on master and automatically applies the patch files before backstage is compiled. The patches do things like changing the OAuth app to AzureAD, add our corporate theme, etc. This is done so I don't have to fork the backstage repo and constantly deal with new commits on master that break my customizations.
I'm using whatever is in the package.json files in 'backstage

This is the rather lengthy build command waf issues:

bsdev is the cloned backstage/master repo.

What version of @types/lodash do you end up with (yarn why @types/lodash)? Could be that newer or older versions have changed how pickBy works. Could also be worth checking your version of typescript as well.
I tried creating #7299 in case it would fix it, although even if it does it would be interesting to know why :grin:

What version of @types/lodash do you end up with (yarn why @types/lodash)? Could be that newer or older versions have changed how pickBy works. Could also be worth checking your version of typescript as well.
I tried creating #7299 in case it would fix it, although even if it does it would be interesting to know why 😁

❯ yarn why @types/lodash
yarn why v1.22.1
[1/4] 🤔  Why do we have the module<EMAIL_ADDRESS>[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "<EMAIL_ADDRESS>info Reasons this module exists

"project#@backstage#catalog-model" depends on it
Hoisted from "project#@backstage#catalog-model#@types#lodash"
Hoisted from "project#@backstage#plugin-catalog-backend-module-ldap#@types#lodash"
Hoisted from "project#@backstage#plugin-catalog-backend-module-msgraph#@types#lodash"
Hoisted from "project#@backstage#plugin-catalog-backend#@types#lodash"
Hoisted from "project#@backstage#plugin-kafka-backend#@types#lodash"
info Disk size without dependencies: "3.52MB"
info Disk size with unique dependencies: "3.52MB"
info Disk size with transitive dependencies: "3.52MB"
info Number of shared dependencies: 0
✨  Done in 2.25s.

What about this error:
plugins/catalog-import/src/components/StepPrepareSelectLocations/StepPrepareSelectLocations.tsx:55:34 - error TS7006: Parameter 'l' implicitly has an 'any' type.

55     prepareResult?.locations.map(l => l.target) || [],

???

Here's the fix - make it explicit!
    prepareResult?.locations.map((l: any) => l.target) || [],


opneHASP support for Pyportal

Hi there, wanting to know if there is an easy way (or might be a way in the future) to have openHASP available for pyportal/pyportal Titano systems (they run on an ATSAMD51J20 and don't seem to be compatible at the moment)

openHASP does not support the ATSAMD51J20 microcontroller. There are a few dozens of ESP32 devices that can run openHASP to choose from. If your really wanted to port the source code to a new MCU, I guess it could eventually work... the question is if it's worth the time and effort, since most devices only cost a coupla bucks nowadays.

thanks for the quick reply @fvanroie

Is this something you'll be pursuing and actively working towards? Or can this issue be closed?


Add api route for main files

This PR adds an api route for the main files of modules, making it more predictable.
The need for this came up while trying to make a reproducible piece of output, and noticing the uploadcare URL was incomprehensible.
Specifically, the route is now as easy as:
/api/modules/main/[suffix]

✌

Merging this with admin privileges because I sort of need this for something 😅