Refactor NSExpression Unit Tests

There are just two types of expressions that aren't refactored yet:
functionExpression = [NSExpression expressionWithFormat:@"mgl_interpolate:withCurveType:parameters:stops:(keyName, 'linear', nil, %@)", @{@18: constantExpression}];
It contains the `keyName, and it's not clear from our documentation how to translate it
The other form is:
constantExpression = [NSExpression expressionWithFormat:@"MGL_FUNCTION('image', 'Icon Image')"];
where MGL_FUNCTION isn't recognized.
Any advice on this is greatly appreciated.

@birkskyum —
I found the expression for keyName another one of the curious expressions.  I found that Swift code was easier to understand and see where the original authors were intending.
The Unit Test testMigratingToExpressions$Linear() defined here has Swift source that is compiled and tested in the scheme CI.   This Unit Test uses Earthquake magnitude as a keyName.  But this was the only example that I found.
https://github.com/maplibre/maplibre-gl-native/blob/901ab18689d96a1804b429c7f505d32d94f417dd/platform/ios/platform/darwin/test/MGLDocumentationGuideTests.swift#L91

Then see the section in DEVELOPING.md titled "Generating Documentation" to run make idocument which auto generates the markdown file:
https://github.com/maplibre/maplibre-gl-native/blob/main/platform/ios/platform/ios/docs/guides/Migrating to Expressions.md#linear.

Another comment on how the Unit Tests for Expressions are structured.  I found a single Unit Test to have many tests within it.  Ideally, a unit test should have a small bit of code over a few lines.  You'll see that I used XCTExpectFailure, which  marks a test as an expected failure from that point in the code on.
My longer term recommendation for the Expressions unit tests is:

Add more Swift Unit Test for Expressions
Refactor the Objective-C Unit Tests for Expressions to have one expression for test (whereas, now we have many per one single Unit Test, and it makes it harder to understand exactly what is failing).
Leave the expected failures in place until either 1. or 2. is achieved.

@roblabs thanks! So a solution could be to port these test files to Swift, right?

From https://github.com/maplibre/maplibre-gl-native/pull/425#issuecomment-1237533943

My longer term recommendation for the Expressions unit tests is:

Add more Swift Unit Test for Expressions
Refactor the Objective-C Unit Tests for Expressions to have one expression for test (whereas, now we have many per one single Unit Test, and it makes it harder to understand exactly what is failing).
Leave the expected failures in place until either 1. or 2. is achieved.

@birkskyum  thanks! So is it a solution here to port the test files to Swift?


Update jQuery to 1.11.0 -> 1.11.3

Latest point release in the 1.11.x series. Compatible with Bootstrap 3.3.4.

Works fine. Trivial point release anyways.


Pull requests with more than 1 commit break the tests

Sending a suggested change on #911 break the test because there is more than 1 commit on the pull request. This made me open another pull request #932, cherry pick only the last change. This made the test pass.
Is this really how it should work? Here is the test result for que PR with 2 commits:
http://test.drone.io/github.com/drone/drone/check_presence_socat_anywhere_in_path/0d36b85e65b51f9820825de360f21b56c0ab7599

pull requests with > 1 commit works fine. There is a single postgres unit test that (for some reason) is non-deterministic and occasionally fails

@bradrydzewski thanks! I thought it was related to some test setup of postgres and not actually on the code and/or Drone itself. As I was unable to re-run the build, I sent only the other commit to a new PR.
How can we re-run the tests for a PR that shows the same behavior? Should we just point it out?

yep, until I have a permanent fix you can just ask :)
I think going forward we should allow the committer to re-run a failed pull request, even if he / she is not granted access to the repository. We don't track the necessary data (yet) in the database, but I'll look at adding


Can´t connect 2 Stacks

I have 2 stacks where one container from the first stack has the same overlay as 3 container in the second stack. The three in the second can ping each other just fine, but can´t reach the one in the other stack. This is a haproxy container which can´t start because it doesn´t reach the other 3:
[ALERT] 124/135641 (7) : parsing [/usr/local/etc/haproxy/haproxy.cfg:33] : 'server slave1' : could not resolve address 'slave1'.
.
.
.
I created the network in composer-stack and tried it in cmd with docker network create, same results.
All containers are on different hosts, newest version of docker and docker-compose, any idea?

@Goram this is a Swarm mode issue. Please open it on https://github.com/moby/moby.


<EMAIL_ADDRESS>decompress error

The past few week I've been receiving this error when trying to install Gimp.
Installing 'gimp' (2.10.38-1) [64bit] from 'extras' bucket
Loading gimp-2.10.38-setup-1.exe from cache
Checking hash of gimp-2.10.38-setup-1.exe ... ok.
Extracting gimp-2.10.38-setup-1.exe ... ERROR Exit code was 1!
Failed to extract files from C:\Users\micha\scoop\apps\gimp\2.10.38-1\gimp-2.10.38-setup-1.exe.
Log file:
~\scoop\apps\gimp\2.10.38-1\innounp.log
Log Content:
innounp.log
Signature detected: Inno Setup Setup Data (6.3.0)
This is not directly supported, but i'll try to unpack it as version 5602
; Version detected: 6300
Unpacking failed. This version is not supported.

Duplicates #14126.


minecells 1.8.0 crash

Mod Name
Minecells
Mod Homepage
https://modrinth.com/mod/minecells/version/1.8.0
Minecraft version
1.20.1
Describe the bug
crash on startup
Steps to reproduce
doesn't crash with version 1.7.3, but with 1.8.0 it does.
Logs
https://gist.github.com/oof100200/a0bc60b478b1f0d6a6c3971154f3e2c3
Additional context
No response

Found the culprit - MixinExtras' @ModifyExpressionValue mixins seem to crash Connector, while they work just fine on Fabric.
Got two of those in Mine Cells: here and here. Disabling these Mixins and recompiling the mod allows the game to launch.

找到罪魁祸首 - MixinExtras 的@ModifyExpressionValuemixins 似乎使 Connector 崩溃，而它们在 Fabric 上工作得很好。 在 Mine Cells 中找到了其中的两个：这里和这里。取消这些 Mixins 并重新编译 mod 即可启动游戏。

thanks.

How do disable the mixing and recompile mod?

How do disable the mixing and recompile mod?

You shouldn't try to do that, it'll break a few things in the mod. I was just saying that I definitely know these mixins are the problematic thing here.


Make all struct CamelCase

Pull Request Template
Checklist

[x] Confirmed that run-checks all script has been executed.
[x] Made sure the book is up to date with changes in this PR.

Related Issues/PRs
https://github.com/tracel-ai/burn/pull/1311
Changes
Convert all struct names do not follow proper Rust convention for struct names. I have used ripgrep find all bad names using this shell command:
rg --type rust "struct\s+[A-Z_]{2,}"

Testing
./run-checks.sh all is passing.

I usually say LGTM, but this time I think I'll say Lgtm 😆

Wow I missed such a great opportunity in my comment 🤣


Cilium Envoy fails to propagate FIN packets to downstream when upstream connection closes

Is there an existing issue for this?

[X] I have searched the existing issues

Version
higher than v1.14.13 and lower than v1.15.0
What happened?
We've encountered an issue with Cilium Envoy in our Kubernetes environment. Our setup consists of a request chain involving three services:

Ingress controller
Envoy proxy for API management
Workload pod

We're using Cilium proxy annotations for the workload container port, configured as ingress HTTP, primarily for observability purposes.
The problem occurs when the workload pod restarts. Immediately after the restart, the next request receives an error: upstream connect error or disconnect/reset before headers. reset reason: connection termination (HTTP 503).
Upon investigation, we discovered the following:

Cilium Envoy acts as an intermediary, creating two connections: one to the downstream API management Envoy and another to the upstream workload pod.

When the workload pod terminates, it emits a FIN packet. Cilium Envoy consumes this packet but doesn't terminate the downstream connection it created in relation to the upstream pod. This connection remains open until it hits the idle timeout.

If a new request is sent immediately after the workload pod restart, our Envoy attempts to reuse the existing connection, resulting in a 503 error.

The initial failed request causes the connection to terminate, allowing subsequent requests to succeed.

However, we noticed that with kubeproxy replacement enabled, even the subsequent requests continue to fail until we restart our Envoy to break the connection.

Hubble outputs
With kube proxy

Without kube proxy

How can we reproduce the issue?

Run cilium install --version 1.14.13 on AKS cluster with BYOCNI.
Deploy following two yaml files.

envoy.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: apim
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-config
  namespace: apim
data:
  envoy.yaml: |
    static_resources:
      listeners:
      - address:
          socket_address:
            address: <IP_ADDRESS>
            port_value: 8080
        filter_chains:
        - filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stat_prefix: ingress_http
              route_config:
                name: local_route
                virtual_hosts:
                - name: backend
                  domains:
                  - "*"
                  routes:
                  - match:
                      prefix: "/"
                    route:
                      cluster: foo_service
              http_filters:
              - name: envoy.filters.http.router
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      clusters:
      - name: foo_service
        connect_timeout: 0.25s
        type: STRICT_DNS
        lb_policy: ROUND_ROBIN
        load_assignment:
          cluster_name: foo_service
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: foo.bar.svc.cluster.local
                    port_value: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: envoy-proxy
  namespace: apim
spec:
  replicas: 1
  selector:
    matchLabels:
      app: envoy-proxy
  template:
    metadata:
      labels:
        app: envoy-proxy
    spec:
      containers:
      - name: envoy
        image: envoyproxy/envoy:v1.24.7
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: envoy-config
          mountPath: /etc/envoy
      volumes:
      - name: envoy-config
        configMap:
          name: envoy-config
---
apiVersion: v1
kind: Service
metadata:
  name: envoy-proxy
  namespace: apim
spec:
  selector:
    app: envoy-proxy
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: envoy-ingress
  namespace: apim
spec:
  ingressClassName: nginx
  rules:
  - host: envoy.cilium.internal
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: envoy-proxy
            port:
              number: 8080

workload.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: bar
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: bar
spec:
  replicas: 1
  selector:
    matchLabels:
      app: foo
  template:
    metadata:
      labels:
        app: foo
      annotations:
        policy.cilium.io/proxy-visibility: "<Egress/53/UDP/DNS>,<Ingress/8080/TCP/HTTP>"
    spec:
      containers:
      - name: debug-service
        image: ghcr.io/isala404/toolbox/debug-service:latest
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: bar
spec:
  selector:
    app: foo
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

Deploy a ingress controller.
Run curl LB-IP/healthz -H "Host: envoy.cilium.internal".
Run kubectl delete pods --all -n bar.
Wait for ~20 seconds and rerun the curl.

Cilium Version
1.14.13
Kernel Version
5.15.0-1067-azure
Kubernetes Version
v1.28.10
Regression
1.13.0
Sysdump
With Kube Proxy
cilium-sysdump-20240717-182934.zip
Without Kube Proxy
cilium-sysdump-20240717-185333.zip
Relevant log output
No response
Anything else?
Issue was happening regardless of wireguard encryption being enabled or not.
Cilium Users Document

[X] Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I ran some additional tests to fully understand the behavior we're observing. One of these tests involved chaining two Envoy instances to see how they interact. From this test, I discovered that Envoy is not designed to send a FIN packet to the downstream service. Instead, when a new request arrives over an already established connection from downstream, but the connection to the upstream service has been terminated, Envoy should initiate a new request to the upstream backend.
Please review the following Hubble log from the two chained Envoy servers:

hubble log
~> hubble observe -n default -f --denylist '{"destination_label":["k8s:k8s-app=kube-dns"]}' --denylist '{"source_label":["k8s:k8s-app=kube-dns"]}' --since 1s
Jul 22 12:23:26.904: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: SYN)
Jul 22 12:23:26.904: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) <- default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Jul 22 12:23:26.904: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 22 12:23:26.904: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:26.904: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) -> default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: SYN)
Jul 22 12:23:26.904: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) <- default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Jul 22 12:23:26.905: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) -> default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 22 12:23:26.905: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) -> default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:26.906: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: SYN)
Jul 22 12:23:26.906: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) <- default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Jul 22 12:23:26.906: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 22 12:23:26.906: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:26.926: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) <- default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:26.926: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) <- default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:26.932: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) <- default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:31.926: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) <- default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Jul 22 12:23:31.927: default/envoy-proxy-2-86d6b5f47c-fv5g6:56366 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, FIN)

Jul 22 12:23:49.260: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: SYN)
Jul 22 12:23:49.260: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) <- default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Jul 22 12:23:49.260: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 22 12:23:49.260: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:49.261: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) -> default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:49.261: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: SYN)
Jul 22 12:23:49.261: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) <- default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Jul 22 12:23:49.262: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 22 12:23:49.262: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:49.266: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) <- default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:49.266: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) <- default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:49.266: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) <- default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:23:54.268: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) <- default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Jul 22 12:23:54.268: default/envoy-proxy-2-86d6b5f47c-fv5g6:45852 (ID:8738) -> default/echo-service-6d6ddfb466-96h7c:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, FIN)

# After running kubectl delete pod

Jul 22 12:24:26.904: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Jul 22 12:24:26.905: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) <- default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Jul 22 12:24:26.905: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:32810 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK)

Jul 22 12:24:46.752: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) -> default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:24:46.752: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) -> default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:24:46.753: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) -> default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: SYN)
Jul 22 12:24:46.753: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) <- default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Jul 22 12:24:46.753: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) -> default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 22 12:24:46.753: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) -> default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:24:46.773: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) <- default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:24:46.773: default/envoy-proxy-1-685ccc6b67-c5pdq:52522 (ID:346) <- default/envoy-proxy-2-86d6b5f47c-fv5g6:8000 (ID:8738) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:24:46.779: ingress-nginx/ingress-nginx-controller-597dc6d68-lbc74:57326 (ID:12699) <- default/envoy-proxy-1-685ccc6b67-c5pdq:8001 (ID:346) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 22 12:24:51.772: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) <- default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Jul 22 12:24:51.772: default/envoy-proxy-2-86d6b5f47c-fv5g6:51646 (ID:8738) -> default/echo-service-6d6ddfb466-8t67w:8080 (ID:55500) to-endpoint FORWARDED (TCP Flags: ACK, FIN)

As illustrated in the logs, Envoy-1 establishes a connection with Envoy-2 using port 52522. When the pod is deleted, the same port gets reused.

deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo-service
  template:
    metadata:
      labels:
        app: echo-service
    spec:
      containers:
      - name: echo-service
        image: ghcr.io/isala404/toolbox/debug-service:latest
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: echo-service
spec:
  selector:
    app: echo-service
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-config-2
data:
  envoy.yaml: |
    static_resources:
      listeners:
      - address:
          socket_address:
            address: <IP_ADDRESS>
            port_value: 8000
        filter_chains:
        - filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stat_prefix: ingress_http
              route_config:
                name: local_route
                virtual_hosts:
                - name: backend
                  domains:
                  - "*"
                  routes:
                  - match:
                      prefix: "/"
                    route:
                      cluster: echo_service
              http_filters:
              - name: envoy.filters.http.router
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      clusters:
      - name: echo_service
        connect_timeout: 0.25s
        type: STRICT_DNS
        lb_policy: ROUND_ROBIN
        load_assignment:
          cluster_name: echo_service
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: echo-service
                    port_value: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: envoy-proxy-2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: envoy-proxy-2
  template:
    metadata:
      labels:
        app: envoy-proxy-2
    spec:
      containers:
      - name: envoy-proxy
        image: envoyproxy/envoy:v1.28.4  # Cilium envoy version
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: envoy-config
          mountPath: /etc/envoy
      volumes:
      - name: envoy-config
        configMap:
          name: envoy-config-2
---
apiVersion: v1
kind: Service
metadata:
  name: envoy-proxy-2
spec:
  selector:
    app: envoy-proxy-2
  ports:
  - port: 8000
    targetPort: 8000
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-config-1
data:
  envoy.yaml: |
    static_resources:
      listeners:
      - address:
          socket_address:
            address: <IP_ADDRESS>
            port_value: 8001
        filter_chains:
        - filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stat_prefix: ingress_http
              route_config:
                name: local_route
                virtual_hosts:
                - name: backend
                  domains:
                  - "*"
                  routes:
                  - match:
                      prefix: "/"
                    route:
                      cluster: envoy_proxy_2
              http_filters:
              - name: envoy.filters.http.router
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      clusters:
      - name: envoy_proxy_2
        connect_timeout: 0.25s
        type: STRICT_DNS
        lb_policy: ROUND_ROBIN
        load_assignment:
          cluster_name: envoy_proxy_2
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: envoy-proxy-2
                    port_value: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: envoy-proxy-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: envoy-proxy-1
  template:
    metadata:
      labels:
        app: envoy-proxy-1
    spec:
      containers:
      - name: envoy-proxy
        image: envoyproxy/envoy:v1.24.7 # APIM envoy version
        ports:
        - containerPort: 8001
        volumeMounts:
        - name: envoy-config
          mountPath: /etc/envoy
      volumes:
      - name: envoy-config
        configMap:
          name: envoy-config-1
---
apiVersion: v1
kind: Service
metadata:
  name: envoy-proxy-1
spec:
  selector:
    app: envoy-proxy-1
  ports:
  - port: 8001
    targetPort: 8001
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: envoy-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: your-domain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: envoy-proxy-1
            port:
              number: 8001


Single Switches appear as two devices: Light + Switch

Switches, which used to be one single device, now show up in Homebridge and Home App as two devices.
The switch was shown wrongly as light in v1.2.20. This home device is not connected to the Fibaro device any more.
Now it has beed added additionally as a switch. The new switch is switching the actual Fibaro device.
First realized in version v 1.4.0
Might be a side effect of the fix of a previous issue.
Konfiguration
Homebridge v1.7.0
homebridge-fibaro-home-center v1.4.0
Node.js v18.16.0
Raspbian GNU/Linux Bullseye (11)
Fresh Install on Raspberry Pi 3+
Home Center 2 v4.630
Screenshot from my Home App. Left device is original device. Second device is new.

@Krillle you must remove unused device from cache (Homebridge settings)

Removing device from cache in Homebridge Settings fixed the issue. Device was added correctly automatically.


Raspbian 10 fresh install has broken routing (iptables/nf_tables detection)

Version:
k3s version v1.17.4+k3s1 (3eee8ac3) on a raspberry pi 4 running Raspbian 10.
K3s arguments:
curl -sfL https://get.k3s.io | sh -
Describe the bug
On a fresh install, no traffic is routed inside the cluster, even for core services. Resolution is to uninstall the default iptables v1.8.2 (nf_tables), and install nftables.
On a fresh install, no traffic is routed inside the cluster. nodes cannot reach each other or coredns. Core services can't reach each other or the api. Ports are not opened on the physical host.
The host is not listening on port 80. Traefik LB reports that it is listening on port 80, but sudo netstat -tlp |grep 80 disagrees. External hosts cannot access created ingresses.
To Reproduce

Install k3s on Raspbian 10.
Run shell in a dnsutils container:  kubectl run -it --rm --restart=Never dnsutils --image=gcr.io/kubernetes-e2e-test-images/dnsutils:1.3 sh
Inside that container, run wget -O- github.com, or wget -O- kubernetes.default and observe "invalid name" errors. Try pinging any IP you please - the DNS server, external IPs - and observe failures.

Expected behavior
Traffic inside the cluster should be routed.
Actual behavior
No traffic is routed inside the cluster. Services (even kube-system) can't reach each other, nothing can reach the API server, etc.
First symptom I noticed was that ingresses failed to open port 80, and services couldn't reach their pods.
Additional context / logs
Fresh uninstall/reinstall on a raspbian host with IP <IP_ADDRESS>:
$ sudo kubectl get all -n kube-system
NAME                                          READY   STATUS      RESTARTS   AGE
pod/metrics-server-6d684c7b5-w7swt            1/1     Running     0          25m
pod/coredns-6c6bb68b64-tqs4d                  1/1     Running     0          25m
pod/helm-install-traefik-pvsvx                0/1     Completed   0          25m
pod/svclb-traefik-pr5cn                       2/2     Running     0          22m
pod/traefik-7b8b884c8-826lt                   1/1     Running     0          22m
pod/local-path-provisioner-58fb86bdfd-cdjwd   1/1     Running     2          25m

NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
service/kube-dns             ClusterIP      <IP_ADDRESS>      <none>         53/UDP,53/TCP,9153/TCP       25m
service/metrics-server       ClusterIP      <IP_ADDRESS>   <none>         443/TCP                      25m
service/traefik-prometheus   ClusterIP      <IP_ADDRESS>   <none>         9100/TCP                     22m
service/traefik              LoadBalancer   <IP_ADDRESS>   <IP_ADDRESS>   80:30192/TCP,443:31737/TCP   22m

NAME                           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/svclb-traefik   1         1         1       1            1           <none>          22m

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/metrics-server           1/1     1            1           25m
deployment.apps/coredns                  1/1     1            1           25m
deployment.apps/traefik                  1/1     1            1           22m
deployment.apps/local-path-provisioner   1/1     1            1           25m

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/metrics-server-6d684c7b5            1         1         1       25m
replicaset.apps/coredns-6c6bb68b64                  1         1         1       25m
replicaset.apps/traefik-7b8b884c8                   1         1         1       22m
replicaset.apps/local-path-provisioner-58fb86bdfd   1         1         1       25m

NAME                             COMPLETIONS   DURATION   AGE
job.batch/helm-install-traefik   1/1           2m24s      25m

$ sudo kubectl describe service traefik -n kube-system
Name:                     traefik
Namespace:                kube-system
Labels:                   app=traefik
                          chart=traefik-1.81.0
                          heritage=Helm
                          release=traefik
Annotations:              <none>
Selector:                 app=traefik,release=traefik
Type:                     LoadBalancer
IP:                       <IP_ADDRESS>
LoadBalancer Ingress:     <IP_ADDRESS>
Port:                     http  80/TCP
TargetPort:               http/TCP
NodePort:                 http  30192/TCP
Endpoints:                <IP_ADDRESS>:80
Port:                     https  443/TCP
TargetPort:               https/TCP
NodePort:                 https  31737/TCP
Endpoints:                <IP_ADDRESS>:443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

$ sudo kubectl describe ingress nginx
Name:             nginx
Namespace:        default
Address:          <IP_ADDRESS>
Default backend:  default-http-backend:80 (<none>)
Rules:
  Host                Path  Backends
  ----                ----  --------
  nginx.cluster.vert
                      /   nginx:80 (<none>)
Annotations:
Events:  <none>

$ sudo netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 <IP_ADDRESS>:8125          <IP_ADDRESS>:*               LISTEN      461/netdata
tcp        0      0 <IP_ADDRESS>:19999           <IP_ADDRESS>:*               LISTEN      461/netdata
tcp        0      0 <IP_ADDRESS>:10248         <IP_ADDRESS>:*               LISTEN      2754/k3s
tcp        0      0 <IP_ADDRESS>:10249         <IP_ADDRESS>:*               LISTEN      2754/k3s
tcp        0      0 <IP_ADDRESS>:6444          <IP_ADDRESS>:*               LISTEN      2754/k3s
tcp        0      0 <IP_ADDRESS>:10256         <IP_ADDRESS>:*               LISTEN      2754/k3s
tcp        0      0 <IP_ADDRESS>:22              <IP_ADDRESS>:*               LISTEN      523/sshd
tcp        0      0 <IP_ADDRESS>:10010         <IP_ADDRESS>:*               LISTEN      2821/containerd
tcp6       0      0 ::1:8125                :::*                    LISTEN      461/netdata
tcp6       0      0 :::19999                :::*                    LISTEN      461/netdata
tcp6       0      0 :::10250                :::*                    LISTEN      2754/k3s
tcp6       0      0 :::10251                :::*                    LISTEN      2754/k3s
tcp6       0      0 :::6443                 :::*                    LISTEN      2754/k3s
tcp6       0      0 :::10252                :::*                    LISTEN      2754/k3s
tcp6       0      0 :::30192                :::*                    LISTEN      2754/k3s
tcp6       0      0 :::22                   :::*                    LISTEN      523/sshd
tcp6       0      0 :::31737                :::*                    LISTEN      2754/k3s

This all started with a power loss/reboot of my working pi cluster, after an apt update.
See my eventual resolution. Seems to me that it was applying rules to both nftables and iptables-legacy, and there was some conflict.
UPDATE: changed focus now that I know routing is completely borked.
UPDATE 2: rewrite title/description after I discovered/resolved the problem. Left open because I believe it will affect other Raspbian 10 users and could probably use a PR to improve iptables vs nftables behavior.

More debugging information:
I tried launching a dnsutils pod inside the cluster. It can't resolve anything. Even kubernetes.default times out trying to reach internal DNS.
Coredns logs are filled with entries like this:
E0328 22:36:15.894784       1 reflector.go:125] pkg/mod/k8s.io/client-go@v0.0.0-20190620085101-78d2af792bab/tools/cache/reflector.go:98: Failed to list *v1.Endpoints: Get https://<IP_ADDRESS>:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
[INFO] plugin/ready: Still waiting on: "kubernetes"

Same for v1.Namespace and v1.Service. The logs start with several lines of:
[ERROR] plugin/errors: 2<PHONE_NUMBER>.156930755. HINFO: read udp <IP_ADDRESS>:58686-><IP_ADDRESS>:53: i/o timeout
where <IP_ADDRESS>:53 is my local DNS server, accessible from the host machine.
And I guess because kube-dns isn't ready, it doesn't have any endpoints, even after 8 hours. :|
Logs for metrics-server are filled with:
E0328 22:56:23.510224       1 manager.go:111] unable to fully collect metrics: unable to fully scrape metrics from source kubelet_summary:cluster1: unable to fetch metrics from Kubelet cluster1 (cluster1): Get https://cluster1:10250/stats/summary?only_cpu_and_memory=true: dial tcp: i/o timeout
That URL is perfectly accessible from outside the cluster (though unauthorized of course).
So I'm left with some kind of problem with routing. Traffic originating inside the cluster seems to be getting nowhere. Services can't talk to each other, or to the outside world. The only IP my dnsutils pod can ping is that of the host machine, <IP_ADDRESS>.
I uninstalled, rebooted, and reinstalled once again, and the problem persists. So clearly there is some possible system state that causes this on a fresh install. I just don't know what. :(

@ohthehugemanatee Have you checked if u have a firewall running?
I have another issue where the install isn't working, and I've found the local linux firewall (firewalld or UFW) is the issue.

@jfmatth can you give some more detail? I would expect the k3s installer to validate that...
Anyway no, there's no firewall running. Just a default raspbian install. In fact if I was only trying to solve my own problem I would wipe/reinstall raspbian... but now I'm walking my way through routing in k3s in case this problem hits someone else...

Sorry @ohthehugemanatee I'm affraid I don't.  There is issue #1543 that some of us are seeing, and I noticed that the same install at home didn't behave the same on Linode.  The main difference was the firewall.
You can see my notes there, but basically, any firewall running before install seems to keep both .13 and .14 from working inside the cluster.
Maybe on Raspbian check the iptables --list just to be sure?

it's true! After uninstall, iptables -L and iptables-legacy -L both showed residual rules hanging around. BUT remember, I had rebooted in between uninstall and reinstall... in any case I did an uninstall, iptables -F; iptables-legacy -F, then reinstall. Same problem.
Metrics server logs are flooded with entries like this:
E0330 19:53:51.599412       1 manager.go:111] unable to fully collect metrics: unable to fully scrape metrics from source kubelet_summary:cluster1: unable to fetch metrics from Kubelet cluster1 (cluster1): Get https://cluster1:10250/stats/summary?only_cpu_and_memory=true: dial tcp: i/o timeout

On the host machine I can wget that address and get an immediate response (and certificate failure since I don't have the cluster's CA in my chain)
I notice that I have iptables 1.8.2 nf_tables... and that used to be a problem.. but that's solved, right? I'm looking at kubernetes/kubernetes#82966 . The fix got into kubernetes 1.17, and I'm running k3s v1.17.4+k3s1 (3eee8ac3).

Got it! W00tarz!
So here's the problem, for future frustrated folk:
Raspbian 10 comes with an iptables wrapper around nf_tables in the kernel. So the command iptables exists, but only as a simlink to iptables_nft. It returns version string iptables v1.8.2 (nf_tables) which seems like it should be correctly handled in check-config.sh. Still, I found firewall entries both in iptables -L (ie nf_tables) and iptables-legacy -L.
The fix was to remove the iptables wrapper and explicitly install nftables:
sudo apt remove iptables -y && sudo apt install nftables
I then reinstalled with a reboot for good measure. And hey presto, everything works!
I'm leaving this issue open and re-titling/describing, because I believe this should be common to all recently updated Raspbian 10 installs, and it probably indicates something to be improved in the installer.

I encountered similar issues. seems like the kubernetes.default /  <IP_ADDRESS> route is broken after reboot / further deployment. My temp workaround:
pi@raspberrypi:~$ sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
pi@raspberrypi:~$ sudo iptables -t nat -I PREROUTING -d <IP_ADDRESS>/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination $eth0_IP:6443
pi@raspberrypi:~$ sudo iptables -t nat -I OUTPUT -d <IP_ADDRESS>/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination $eth0_IP:6443

some ppl report similar issue after install docker
https://github.com/rancher/k3s/issues/703
for my own case, it turns out some related IPv6. (unrelated to iptables, seems)
After I disable IPv6 via sysctl. everything works properly. Possibly I will create another separated issue.

ohthehugemanatee you are amazing - I burned up a couple days trying to figure out why this wasn't working on my Pi Bramble.  Your solution worked a charm.

Just did a clean install of raspbian on two Rpi4s. update-alternatives method didn't work for me, and I'm reluctant to disable IPv6. @dictcp temp fix on the master node (where the failing containers were) worked for now. Not sure if it'll flush after a reboot and I'll need to add it to a script and cron on reboot for now or not.
Details:

# OS distrib:
nate-mbp17:~ ls ~/Downloads/2020-05-27-raspios-buster-lite-armhf.zip
/Users/xnutsive/Downloads/2020-05-27-raspios-buster-lite-armhf.zip

# Steps I did:
sudo apt-get update && apt-get upgrade
sudo apt-get install vim fish tmux git

# Installation
# Used k3s-ansible to setup.

# Problem

nate-mbp17:~ kubectl get pods -A -o wide
NAMESPACE     NAME                                     READY   STATUS             RESTARTS   AGE     IP           NODE   NOMINATED NODE   READINESS GATES
kube-system   helm-install-traefik-nspr7               0/1     Completed          0          8m57s   <IP_ADDRESS>    rpi2   <none>           <none>
kube-system   svclb-traefik-vh9mz                      2/2     Running            2          7m41s   <IP_ADDRESS>    rpi3   <none>           <none>
kube-system   coredns-8655855d6-q79dn                  0/1     Running            1          8m56s   <IP_ADDRESS>    rpi2   <none>           <none>
kube-system   traefik-758cd5fc85-9jx77                 1/1     Running            1          7m41s   <IP_ADDRESS>    rpi3   <none>           <none>
kube-system   svclb-traefik-wrflb                      2/2     Running            2          7m41s   <IP_ADDRESS>   rpi2   <none>           <none>
kube-system   metrics-server-7566d596c8-fb9t5          0/1     CrashLoopBackOff   4          8m56s   <IP_ADDRESS>    rpi2   <none>           <none>
kube-system   local-path-provisioner-6d59f47c7-5stjg   0/1     CrashLoopBackOff   5          8m56s   <IP_ADDRESS>    rpi2   <none>           <none>

# After applying the iptables tunnel preroute / ouput hack
nate-mbp17:~ kubectl get pods -A -o wide
NAMESPACE     NAME                                     READY   STATUS      RESTARTS   AGE   IP           NODE   NOMINATED NODE   READINESS GATES
kube-system   helm-install-traefik-nspr7               0/1     Completed   0          22m   <IP_ADDRESS>    rpi2   <none>           <none>
kube-system   svclb-traefik-wrflb                      2/2     Running     4          20m   <IP_ADDRESS>   rpi2   <none>           <none>
kube-system   svclb-traefik-vh9mz                      2/2     Running     4          20m   <IP_ADDRESS>    rpi3   <none>           <none>
kube-system   traefik-758cd5fc85-9jx77                 1/1     Running     2          20m   <IP_ADDRESS>    rpi3   <none>           <none>
kube-system   coredns-8655855d6-q79dn                  1/1     Running     2          22m   <IP_ADDRESS>   rpi2   <none>           <none>
kube-system   local-path-provisioner-6d59f47c7-5stjg   1/1     Running     11         22m   <IP_ADDRESS>   rpi2   <none>           <none>
kube-system   metrics-server-7566d596c8-fb9t5          1/1     Running     11         22m   <IP_ADDRESS>   rpi2   <none>           <none>

@ohthehugemanatee I followed your guidance and ran sudo apt remove iptables -y && sudo apt install nftables, followed by a reboot than an install of k3s, all on a fresh install of raspbian. Now, k3s won't start.
:~ k3s config-check returns
...
- links: aux/ip6tables should link to iptables-detect.sh (fail)
- links: aux/ip6tables-restore should link to iptables-detect.sh (fail)
- links: aux/ip6tables-save should link to iptables-detect.sh (fail)
- links: aux/iptables should link to iptables-detect.sh (fail)
- links: aux/iptables-restore should link to iptables-detect.sh (fail)
- links: aux/iptables-save should link to iptables-detect.sh (fail)
...

Did you also setup alternatives as well? It seems like k3s needs to be able to locate an alternative to iptables, but just installing nftables isn't enough.

I had a similar experience, although in my case I rebooted a long running k3s agent and then noticed the network issue.
Running the following commands fixed the issue:
sudo iptables -F
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
sudo reboot

I found this solution in the k3s documentation under the Advanced Options and Configuration topic.

@virtualstaticvoid possibly related to https://github.com/k3s-io/k3s/issues/3117#issuecomment-810617920

@coopstools I didn't have to update-alternatives to my memory... but the time between my solution and your problem is long enough to have multiple releases in between. I doubt if my diagnosis still applies on modern raspberry pi os installs.  Did you find another solution?


How to loop through the properties of a schema?

I want to use kcl as single source of truth to generate some configuration files that can be consumed by other processes. When consuming these json files with python it would be good to have type information of the structure of the data available in python. For that I want to generate a python file that has the same structure as a kcl schema. This way the python linter knows which data to expect and runtime errors can be prevented.
For example this .k-file:
schema MySchema:
    mykey: str

should be converted to this python code:
from typing import TypedDict

class MySchema(TypedDict):
    mykey: str

My question: Is there a kcl-native way to loop through the properties of a schema in order to generate code of the python class?

@Peefy Thank you! :)


Update typedoc from 0.22.18 to 0.23.1

Change-type: patch
Signed-off-by: Josh Bowling<EMAIL_ADDRESS>

@balena-ci I self certify!


fix fix regression test

regression test broken because of pr influence each other:
#37951 and #38081

run buildall

run buildall


Correction for raw affiliation Micalis Institute, INRAE, AgroParisTech, University Paris-Saclay, Jouy-en-Josas, France

Correction needed for raw affiliation Micalis Institute, INRAE, AgroParisTech, University Paris-Saclay, Jouy-en-Josas, France
raw_affiliation_name: Micalis Institute, INRAE, AgroParisTech, University Paris-Saclay, Jouy-en-Josas, France
new_rors: 0471cyx86;02kbmgc12;003vg9w96;03xjwb503
previous_rors: 0471cyx86;02kbmgc12;003vg9w96
works_examples: W4353034940
contact: 99003072d70a1a9265c571366d615e57:7898f2e2d0f2492b6457e512f4c47bfc8a08 @ agroparistech.fr

This issue was accepted and ingested by the OpenAlex team on 2024-12-19. The new affiliations should be visible within the next 7 days.


Json file

@dbolya  Thanks for the source code , i just wanted to write all the predicted boxes and mask area into a json file similar to the input json file which we are giving while training . I see in your code u have made this accomodation for the validation set , how can i use this for the test set

Simply specify the dataset parameter: --dataset=x. For the COCO test set, I already have that set up as coco2017_testdev_dataset , so the command you would want is
python (...) --dataset=coco2017_testdev_dataset --output_coco_json
Then if you have a test set for your own custom dataset, look at how I made coco2017_testdev_dataset in data/config.py. Just make sure you set 'has_gt' to false.

thanks for response but when i perform this , i get encode values in json for the segmented mask

You mean you want a polygon segmentation out? Converting a 2d tensor to a polygon is a pretty hard task so you'll have to implement that yourself if you want that.
The output format of the segmentation is COCO's RLE format. I'll quote an explanation of the format I made in another thread:

All it is is an array with alternating numbers of 0's and 1's. So [10, 20, 30] would be 10 0's followed by 20 1's then followed again by 30 0's finally reshaped into the saved size, though coco does some extra compression on top of this.

Is it possible for you to just use this format? You can use pycocotools to convert RLE's back into a 2d tensor. I was also able to pretty easily implement this decoding function in Javascript you can find here if you want that.

@dbolya yes i wanted the polygon output of the segmentation . I shall try to use the pycocotools to convert the format , since i require the functionality output to be in polygon form

Ah, I meant use pycocotools to convert it back into a 2d tensor (it won't convert it into a polygon). What you're asking for is probably impossible to do losslessly (esp. for very concave / separated shapes) and it would slow down the network, which is why I haven't implemented that.
If you really need polygon masks, you can try something like this, though it might break in some difficult cases.

sure i shall try the link suggested , i need to perform this offline so i am wokay with slowing of the network

can you share the code, how to set the json path? I have my dataset, but when I set the json path, it cannot create it automatically.
thanks a lot


[W5.7][W14-4] Zulqarnain

Where are the unit test and IO test of your sort function?

Thanks for pointing that out @fzdy1914 , i have added in the test cases in the new commits


Fixed crash with fancy warp menu

What menu?

I still crash using this build and fancy warp 2.0113
crash-2024-02-20_19.32.44-client.txt

wait actually
thats not a pss crash

What menu?

I opened /warp

so is it good?

so is it good?

i mean im not getting the pss crash

alright I sent to tireless


domain pakkauksen luokkien toistuva koodi vähennetty

Codecov Report

Merging #2 into master will not change coverage.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master       #2   +/-   ##
=========================================
  Coverage     72.87%   72.87%
  Complexity      175      175
=========================================
  Files            16       16
  Lines           778      778
  Branches         84       84
=========================================
  Hits            567      567
  Misses          167      167
  Partials         44       44

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/ReadMe/domain/Article.java
50% <100%> (ø)
10 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Kiitos!


Item Show Page

On the item edit page the diaper banks enter in information on distribution quantity, package size and value of the items. We should display this information on the item show page.

Hey Sean,
When referring to value of items, are you expecting value per items or total value of items per storage location?  value per items is present within the item header already. This is what I have

Hey @johnfelixespinosa you're on the right track! I was thinking that the distribution quantity, package size, and value per item would be between the header and the storage location information.


Eval function does not pass field value to functions with multiple arguments

The following occurs with a document database, on 2.1-rc5.
create class test
insert into test(counter) values (1)

-- Correct results
select counter from test
-- result = 1
select min(counter, 2) from test
-- result = 1
select max(counter, 0) from test
-- result = 1
select eval('counter') from test
-- result = 1

-- Incorrect results when using the eval function with multiple argument functions
select eval('min(counter, 2)') from test
-- result = 2
select eval('max(counter, 0)') from test
-- result = 0

wrong usage... don't quote the expression, use this and it works..
select eval(max(counter, 0)) from test
select eval(min(counter, 2)) from test

That is the correct usage according to the documentation. Note that the following throws a NullPointerException.
select eval(1 * 10) from test

But it works when quoted with single quotes.
Also this is broken..
select eval(max(counter, 0) * 10) from test
-- result = 1. Should be 10

indeed, this seems to be an inconsistency that leads to incorrect results in certain cases.
you may be able to use the below as a workaround:
select eval('10 * max') from (select max from (select max(counter,0) from test))
@lvca i still think this is a bug

Unfortunately that workaround won't work in an UPDATE statement, which is where I need to do the evaluation.

This is a problem of visibility of variables. Try using $current.max instead of max

I would love to see this fixed soon -- it's possibly related to some of the issues I reported recently, like #6604 or #6606.


isona在maven编译时依赖无法找到。

C:\Users\Administrator\Desktop\isona>mvn clean package
[INFO] Scanning for projects...
Downloading from nexus-snapshots: http://nexus-snapshots/com/spring4all/isona-pa
rent/0.0.1-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata com.spring4all:isona-parent:0.0.1-SNAPSHOT
/maven-metadata.xml from/to nexus-snapshots (http://nexus-snapshots): nexus-snap
shots
Downloading from nexus-releases: http://nexus-releases/com/spring4all/isona-pare
nt/0.0.1-SNAPSHOT/isona-parent-0.0.1-SNAPSHOT.pom
Downloading from nexus-snapshots: http://nexus-snapshots/com/spring4all/isona-pa
rent/0.0.1-SNAPSHOT/isona-parent-0.0.1-SNAPSHOT.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'parent.relativePath' of POM com.spring4all:isona-storage:0.0.1-SNAPSH
OT (C:\Users\Administrator\Desktop\isona\isona-storage\pom.xml) points at com.sp
ring4all:isona instead of com.spring4all:isona-parent, please verify your projec
t structure @ line 14, column 10
[FATAL] Non-resolvable parent POM for com.spring4all:isona-storage:0.0.1-SNAPSHO
T: Could not transfer artifact com.spring4all:isona-parent:pom:0.0.1-SNAPSHOT fr
om/to nexus-releases (http://nexus-releases): nexus-releases and 'parent.relativ
ePath' points at wrong local POM @ line 14, column 10
[WARNING] 'parent.relativePath' of POM com.spring4all:isona-core:0.0.1-SNAPSHOT
(C:\Users\Administrator\Desktop\isona\isona-core\pom.xml) points at com.spring4a
ll:isona instead of com.spring4all:isona-parent, please verify your project stru
cture @ line 14, column 10
[FATAL] Non-resolvable parent POM for com.spring4all:isona-core:0.0.1-SNAPSHOT:
Failure to transfer com.spring4all:isona-parent:pom:0.0.1-SNAPSHOT from http://n
exus-releases was cached in the local repository, resolution will not be reattem
pted until the update interval of nexus-releases has elapsed or updates are forc
ed. Original error: Could not transfer artifact com.spring4all:isona-parent:pom:
0.0.1-SNAPSHOT from/to nexus-releases (http://nexus-releases): nexus-releases an
d 'parent.relativePath' points at wrong local POM @ line 14, column 10
[WARNING] 'parent.relativePath' of POM com.spring4all:isona-web:0.0.1-SNAPSHOT (
C:\Users\Administrator\Desktop\isona\isona-web\pom.xml) points at com.spring4all
:isona instead of com.spring4all:isona-parent, please verify your project struct
ure @ line 14, column 10
[FATAL] Non-resolvable parent POM for com.spring4all:isona-web:0.0.1-SNAPSHOT: F
ailure to transfer com.spring4all:isona-parent:pom:0.0.1-SNAPSHOT from http://ne
xus-releases was cached in the local repository, resolution will not be reattemp
ted until the update interval of nexus-releases has elapsed or updates are force
d. Original error: Could not transfer artifact com.spring4all:isona-parent:pom:0
.0.1-SNAPSHOT from/to nexus-releases (http://nexus-releases): nexus-releases and
'parent.relativePath' points at wrong local POM @ line 14, column 10
[ERROR] Child module C:\Users\Administrator\Desktop\isona\isona-example-consul o
f C:\Users\Administrator\Desktop\isona\pom.xml does not exist @
@
[ERROR] The build could not read 4 projects -> [Help 1]
[ERROR]
[ERROR]   The project com.spring4all:isona-storage:0.0.1-SNAPSHOT (C:\Users\Admi
nistrator\Desktop\isona\isona-storage\pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for com.spring4all:isona-storage:0.0.1-SNA
PSHOT: Could not transfer artifact com.spring4all:isona-parent:pom:0.0.1-SNAPSHO
T from/to nexus-releases (http://nexus-releases): nexus-releases and 'parent.rel
ativePath' points at wrong local POM @ line 14, column 10: Unknown host nexus-re
leases -> [Help 2]
[ERROR]
[ERROR]   The project com.spring4all:isona-core:0.0.1-SNAPSHOT (C:\Users\Adminis
trator\Desktop\isona\isona-core\pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for com.spring4all:isona-core:0.0.1-SNAPSH
OT: Failure to transfer com.spring4all:isona-parent:pom:0.0.1-SNAPSHOT from http
://nexus-releases was cached in the local repository, resolution will not be rea
ttempted until the update interval of nexus-releases has elapsed or updates are
forced. Original error: Could not transfer artifact com.spring4all:isona-parent:
pom:0.0.1-SNAPSHOT from/to nexus-releases (http://nexus-releases): nexus-release
s and 'parent.relativePath' points at wrong local POM @ line 14, column 10 -> [H
elp 2]
[ERROR]
[ERROR]   The project com.spring4all:isona-web:0.0.1-SNAPSHOT (C:\Users\Administ
rator\Desktop\isona\isona-web\pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for com.spring4all:isona-web:0.0.1-SNAPSHO
T: Failure to transfer com.spring4all:isona-parent:pom:0.0.1-SNAPSHOT from http:
//nexus-releases was cached in the local repository, resolution will not be reat
tempted until the update interval of nexus-releases has elapsed or updates are f
orced. Original error: Could not transfer artifact com.spring4all:isona-parent:p
om:0.0.1-SNAPSHOT from/to nexus-releases (http://nexus-releases): nexus-releases
and 'parent.relativePath' points at wrong local POM @ line 14, column 10 -> [He
lp 2]
[ERROR]
[ERROR]   The project com.spring4all:isona:0.0.1-SNAPSHOT (C:\Users\Administrato
r\Desktop\isona\pom.xml) has 1 error
[ERROR]     Child module C:\Users\Administrator\Desktop\isona\isona-example-cons
ul of C:\Users\Administrator\Desktop\isona\pom.xml does not exist
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException

没有上传到nexus，先编译一下parent模块，再编译其他的


Discussion: implement a new git handler

This may help with integration with watches and hooks:
https://rovaughn.github.io/2015-2-9.html
It's about how to create a new protocol handler (e.g. git push irmin://github.com) in the git CLI.

Interesting! Actually, I was going to ask: Irmin has a git backend, but what about a git front-end ? e.g. speaking the git-over-http protocol (either the dumb or the dynamic one) ? Does that exist already ? Would it be difficult ?
Could be quite useful for, I don't know, serving an opam repository for a completely random example :p


Optimize all reduce v2

the original dense all reduce is not efficient, update to a more efficient one.

@googlebot I consent.

We never patch the nightly branch. Please open/rebase against master

@chengmengli06  Can you please check @mihaimaruseac's comments and keep us posted ? Thanks!

Closing since this is against nightly branch which we don't update


Update User Guide

Updated the user guide to improve UX
Updated commands in the user guide
Changed reset command to list

Closes #114

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Files with missing lines
Patch %
Lines

...java/seedu/address/logic/commands/ListCommand.java
0.00%
1 Missing :warning:

.../seedu/address/logic/parser/AddressBookParser.java
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Files with missing lines
Coverage Δ
Complexity Δ

...java/seedu/address/logic/commands/ListCommand.java
0.00% <0.00%> (ø)
0.00 <0.00> (?)

.../seedu/address/logic/parser/AddressBookParser.java
65.00% <0.00%> (-3.43%)
6.00 <0.00> (ø)

... and 24 files with indirect coverage changes


postgresql entered FATAL state, too many start retries too quickly

Docker version 25.0.3, build 4debf41
I found that I cannot login through Kitsu's default username and password, so I checked the console and got those error:
root@MyServer:~# docker run --init -ti --rm -p 80:80 -p 1080:1080 --name cgwire cgwire/cgwire
[WARN  tini (7)] Tini is not running as PID 1 and isn't registered as a child subreaper.
Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
Running Zou...
2024-04-05 03:42:19,035 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2024-04-05 03:42:19,039 INFO RPC interface 'supervisor' initialized
2024-04-05 03:42:19,039 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-04-05 03:42:19,039 INFO supervisord started with pid 12
2024-04-05 03:42:20,041 INFO spawned: 'gunicorn' with pid 15
2024-04-05 03:42:20,042 INFO spawned: 'gunicorn-events' with pid 16
2024-04-05 03:42:20,059 INFO spawned: 'redis' with pid 17
2024-04-05 03:42:20,060 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:20,063 INFO spawned: 'nginx' with pid 18
2024-04-05 03:42:21,082 INFO success: gunicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:21,082 INFO success: gunicorn-events entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:21,082 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:21,083 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:21,084 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:23,086 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:26,087 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:26,087 INFO gave up: postgresql entered FATAL state, too many start retries too quickly

Thank you for reporting, we will check the image again.

Thank you for reporting, we will check the image again.

Today I tried to build the docker image from this repo instead of pull image from docker hub, and I got it running well.
For comparison, I tried the image cgwire/cgwire from Docker Hub, and the error appeared again.
It seems that something went wrong in the Docker Hub image, and the error still exist in Docker Hub image today.

I was able to set up the image on my computer. It may be related to your installation.

I have the same issue with the image on Docker Image: PostgreSQL encounters a problem at startup until the message:
gave up: postgresql entered FATAL state, too many start retries too quickly.
I am going to test by building the image from the repository.

Hi @RyougiShiki-214 can you tell me if you still have this error?
Thanks.

Hi @RyougiShiki-214 can you tell me if you still have this error? Thanks.

I tried just now, and it seems that this problem had been solved


All tests timing out on vm-fuchsia-release-x64

There are new test failures on [tfa] Fix crash when building field guard summary with captured receiver...[vm/compiler] Avoid load forwarding for weak fields.

This is likely due to a sudden shutdown or disconnect of the target.
If you have encountered what you think is a bug, Please report it at https://fxbug.dev/new/ffx+User+Bug

To diagnose the issue, use `ffx doctor`.

stderr:
WARNING:root:Process exited with status code 1.

--- Re-run this test:
python3 tools/test.py -n vm-fuchsia-release-x64 ffi/data_test

Looks like we don't see any error logs in here. My hunch is we're hitting an ASSERT. @alexmarkov could you PTAL?

When running locally, I see the same test failures (timeouts) before (ced6074176f112796f7e71bc1b21395efcf411ca) and after (778a413fa67c17de1ba05e32adc008b849f92f5f) my changes.
Most likely Fuchsia bot is not hermetic, and those failures are caused by a recent Fuchsia change and not Dart SDK changes.
@liamappelbe @rmacnak-google Do you know how to diagnose these failures? Is there any way to get more logs out of the fuchsia bot?

I think this was caused by the machine type change. The new machines don't have KVM. I have infra changes to get one old machine with KVM for this builder.

Thanks @rmacnak-google!

Green again, it picked up the old approvals.


(IAC-983) Removal of inappropriate terminology

Closing as this module is no longer on our priority list.

Closing as this module is no longer on our priority list.


Add nmap plugin and update Vundle plugin

Just some aliases that could be useful for people frequently scanning with nmap.
Most of these are easy to type while autocompleting with .
I'm not sure if this is the proper way to contribute this to the repo.
If you have any suggestions do let me know.
Also I updated the vundle plugin with the latest vundle repo name and commands.

@uberspot Can you re-submit these as two unique pull requests?

Done :)


Task import change import directory type from text input to dropdown select

Using react-select library to achieve
TODO: the height of the select element is not the same as other parameter fields

Yan, this might be colliding with a different implementation (commit 841941e) that hasn't yet reached the main branch.

I see, we can close this PR

Yan, this might be colliding with a different implementation (commit 841941e) that hasn't yet reached the main branch.

I see, we can close this PR


support chatGPT model

When trying to set gptcommit config set openai.model gpt-3.5-turbo
after that, when using gptcommit, It shows the error
OpenAI error: This is a chat model and not supported in the v1/completions endpoint. Did you mean to use v1/chat/completions?
reference: https://openai.com/blog/introducing-chatgpt-and-whisper-apis

Stay posted for a minor version release here!


Remove watchdog file

What this PR does / why we need it:
As part of https://github.com/kubevirt/kubevirt/pull/3212, release v0.29, watchdog files were made obsolete.
As of release 1.2, this is safe to drop as new launchers are not using watchdog files long enough.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note:

NONE

/cc @davidvossel @vladikr

Sorry, I didn't get to it earlier.
This definitely makes sense, thanks!
/approve

/hold
I found a few more relics

/hold cancel

/cc

@fossedihelm PTAL

+55 −863

Sooo good! Thank you @xpivarc
/lgtm
/hold
@xpivarc I lost the timing between the hold and the approval. Feel free to unhold in case
this is unnecessary.

/hold cancel
The changes since the approval were only cosmetic


Algo Kruskal's Algorithm Java

Here is the description of the algorithm of the Kruskal algorithm .
https://www.geeksforgeeks.org/kruskals-algorithm-simple-implementation-for-adjacency-matrix/

Want to work on this issue
yes

i wan't to do using c++

Then plss open another issue for C++


Preserve symlink contents in sdists

Wheels do not support symlinks (as they are ZIP files), but tarballs do. For consistent results however, expand those symlinks to the files they reference.
This is consistent with 0.16.0, and fixes this regression in 0.17.0.

This broke part of our latest release because we make it from an sdist: matplotlib/matplotlib#29229
In 0.16.0, the test was whether the source directory path was a file:
https://github.com/mesonbuild/meson-python/blob/0.16.0/mesonpy/__init__.py#L893
Then this file would be opened and inserted into the tarball:
https://github.com/mesonbuild/meson-python/blob/0.16.0/mesonpy/__init__.py#L909-L910
This path check returns True for symlinks, and the file opening would insert the target contents into the tarball.
As of 0.17.0 (specifically #587), the check is whether the TarInfo is a file:
https://github.com/mesonbuild/meson-python/blob/0.17.0/mesonpy/__init__.py#L882
This does not return True for a symlink, and then they get skipped.
If we just check member.issym(), then what ends up in the tarball is a symlink, so we need to copy information from the original in order to produce the contents as used to occur in 0.16.0.

This is consistent with 0.16.0, and fixes this regression in 0.17.0.

This is not a regression. We decided to do not support symbolic links and other special files. Supporting them is not exactly trivial and I didn't see an use case for them. Why does matplotlib need symbolic links in its source repository?

This is not a regression.  We decided to do not support symbolic links and other special files.

Is this documented someplace?  We looked at the release notes for 0.17 and did not see any mention of this change.  As this appeared to be an undocumented behavior change that broke us, from our point of view it looked like a regression.

Why does matplotlib need symbolic links in its source repository?

We have files that we want to keep in-sync that we want to have different names (the second name is imposed on us via GTK) and while there are a bunch of ways we could solve this (just have two copies and be careful to keep them the same or add a build step that makes the second copy) using a symlink is the simplest way (trust the file system to do its job and git sorts it out on windows).  I suspect reasonable people will disagree about if this is a "good enough" reason or not.
However, I am not sure that it is worth debating the merits of our use of symlinks.  It is a fact that we do and I can not believe mpl is the only project that will trip on this so what can we do to save the next project?  My preference would be to restore the behavior from 0.16, but if that is not on the table I think the second best option is to hard-fail the build when symlinks are encountered. The behavior in 0.17 of just dropping the files is the worst of all options and I would still argue is a bug even if not supporting symlinks is the intended behavior.

I was just typing a reply that kinda overlaps with @tacaswell's. Whether this is a regression or not is imho a semantic difference that isn't super important. This looks like a case of Hyrum's Law: we didn't explicitly promise or test that symlinks work for an sdist, but Matplotlib did rely on it and now it broke. Since https://github.com/matplotlib/matplotlib/issues/29229 looks like it has a pretty high impact, let's see what we can do here to mitigate it - either temporarily or permanently.
Re symlinks in general: I still have hope for support for symlinks in wheels materializing (it's been giving a thumbs up in principle, however wheel 2.0 is a heavy lift). So if the change in this PR isn't too onerous, supporting symlinks in sdist creation doesn't seem unreasonable to me. If that sdist creation turns symlinks into copies, that means wheel builds work too, so there is a use case (and IIRC we've had questions about this before, like with nanoarrow). In most cases symlinks aren't the most healthy of the available options, but in some corner cases they may be.

I was not trying to argue that we should not support symlinks. I was just curious to see what is the motivation to have them in the repository of a cross-platform project, given that AFAIK git turns them into regular files on Windows.
The main problem with supporting symlinks is with sanitizing their destination. Including a file in the sdist outside the repository is obviously bad for reproducibility, but it is also a data exfiltration vector that I don't think we should support. Other than that, supporting symlinks to regular files within the repository by turning them into regular files is most likely a desirable feature.
I'm much less convinced that hard links should be supported. I don't think git has support for hard links anyway. Does it? Someone could be creating hard links in a dist-script, but I cannot think about any reason why someone would do that.

IIRC we've had questions about this before, like with nanoarrow

IIRC nanoarrow wanted to symlink directories. I don't think we should support that.

I think the second best option is to hard-fail the build when symlinks are encountered

Unfortunately that would be a compatibility break as bad as silently dropping support for symlinks: someone may be relying on the fact that special files are silently dropped and their build would be broken by this change. However, it is a good idea to add a warning for special files that do not make into the sdist.

Anecdotally, meson itself has a bunch of symlinks in the testsuite, some of which are because we are in fact testing the functionality of meson functions that are documented to interact with symlinks in specific ways.
We had to delete them from git and start creating them in run_project_tests.py, because setuptools silently drops them from sdists. It is both awkwardly annoying to manage this as part of the test runner, and a deeply frustrating debug experience because they were silently dropped -- everything worked in CI, but tests failed for people building from sdist. On systems without symlink support, we skip those tests anyway so we don't care whether git/tar unpack them by extracting full file copies.


[IOTDB-2308]Library string

Description
Add String Processing of UDF functions through Library-string.

Coverage decreased (-0.02%) to 68.072% when pulling e0f50e8542f1a697ad62e65df2ecc90b9f9fcd48 on trin1t:library-string into 001490bbd734eab37ee4dcc5530b0dac33603870 on apache:master.

The test cases are LGTM.


fix: update cards dependencies

fixes security vulnerability with one of the dependencies of the cards plugin. See https://osv.dev/vulnerability/GHSA-f8q6-p94x-37v3 for details.
simply ran yarn upgrade and yarn buildon the package. Still needs verifying that the plugin functions as expected.

I vaguely remember @seethroughdev telling me about the tests for the JS framework. @seethroughdev do you know where the tests are present so we can just run them once to verify if the PR doesn't break anything?

thanks for looking into this @saikonen . I'm not seeing a change to the yarn file, only yarn.lock, I think we should update both, that way we know we can regenerate a lockfile, and it will work.
also, I'm a bit surprised by changes in the css and js outputs. do you know change is causing them?

I'm not seeing a change to the yarn file, only yarn.lock

I only ran yarn upgrade which updates dependencies to the latest versions allowed by the pinned versions found in package.json, didn't want to start off with minor/major version upgrades in fear of breaking changes :)

also, I'm a bit surprised by changes in the css and js outputs. do you know change is causing them?

My best guess is that between versions the parser has had some changes and might just be ordering the output differently, hence the massive diff. the files are generated with yarn build so its all up to the build process

Yeah, npm ci is nice for that as your guaranteed packages won't shift.  Both things make sense. As long as you're not concerned with the diff change, then works for me!
Thanks.


CDN access

Since there's no dist preinstall we can't just use rawgithub is there a way we can get a cdn version of incremental-dom up so I can use it jsbin / jsfiddle?

Let me ask around to see if there is somewhere inside Google to host it.

You can grab 0.2.0 from here:
https://ajax.googleapis.com/ajax/libs/incrementaldom/0.2.0/incremental-dom.js

Nice +1.


Electron App: Is there a way to include credentials for secured graphql endpoints?

Any way to include credentials (preferably for BASIC auth) using the Electron App?

You can indeed set headers!

You can read more about how to put basic auth into the headers here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication


fix(ci): Update CI triggers so they react to changes to common build files

Description
Recently we updated some packages so they refer to common build config files directly in the repo (by path), instead of through a package dependency. This means that changes to those files should trigger the CI build, but we missed adding them to the pipeline triggers.
Some examples of the file references (non-exhaustive):

https://github.com/microsoft/FluidFramework/blob/4eb59e40657f12cc20bb2975f7360bffd84d46cd/common/lib/common-definitions/package.json#L30
https://github.com/microsoft/FluidFramework/blob/4eb59e40657f12cc20bb2975f7360bffd84d46cd/common/lib/protocol-definitions/package.json#L35
https://github.com/microsoft/FluidFramework/blob/4eb59e40657f12cc20bb2975f7360bffd84d46cd/packages/dds/matrix/package.json#L79

Reviewer Guidance
The review process is outlined on this wiki page.
I explicitly did not try to target the exact files that we depend on today (opting instead for triggering on changes anywhere in the directory) since it is safer. It might lead to some unnecessary CI builds, but I think the risk of that is low and that this side of the trade-off is a better starting point.

/azp run Build - protocol-definitions


anlayzer: move InlineTableScan into Analyzer.

Which issue does this PR close?
Closes #5682
Rationale for this change

What changes are included in this PR?
move InlineTableScan into Analyzer.
Are these changes tested?
Add Unit test for Analyzer
Are there any user-facing changes?

cc @alamb @mingmwang @liukun4515

However, the other rule, https://github.com/apache/arrow-datafusion/blob/main/datafusion/optimizer/src/analyzer/count_wildcard_rule.rs does not fot this criteria either 🤔

Spark has a similar rule ExtractWindowExpressions like it.

Taking a step back, I thought the purpose of the Analyzer was to do semantic analysis (things like doing type checks) or maybe coercing the types so the the plan became valid.

I think any action to make plan valid should be put into analyzer like resolvePlan, typeCoercion, .....
I think inlineTableScan also belong this category.

I think any action to make plan valid should be put into analyzer like resolvePlan, typeCoercion, .....
I think inlineTableScan/count_wildcard_rule also belong this category.

That makes sense to me. I tried to capture this in doc comments for future readers here:  https://github.com/apache/arrow-datafusion/pull/5705


testing, ignore.

Add echo commands. Testing, ignore.

Coverage remained the same at 93.858% when pulling fb6e2e2fc7467094544b61140a5c35eb9be8b76e on bladee-x:patch-1 into 1da38c8836e81560a3edfa177920b781f75d7300 on Netflix:master.


Running the generate-k8s-api Target Results in Unexpected Deepcopy Funcs

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
pkg/maps/tunnel/zz_generated.deepcopy.go was created from $ make generate-k8s-api. This is due to the TunnelIP struct containing a controller-runtime marker to generate the deepcopy funcs.
Cilium Version
main branch
Kernel Version
N/A
Kubernetes Version
N/A
Sysdump
N/A
Relevant log output
N/A

Anything else?
N/A
Code of Conduct

[X] I agree to follow this project's Code of Conduct

/assign

@danehans Why is this an issue?  And why now, looks like the commit which added deep copy was done 6 months ago?

Hi @danehans,
The automatic generation of the deepcopy methods for that type has been overlooked for some time, as it was not checked by the CI. It should have been fixed by this PR, though, and now running make generate-k8s-api should not lead to unexpected changes anymore. Could you please verify on a newly rebased branch if you still experience issues?

@giorio94 thanks for the review. Let me wrap-up the PR I'm working on and I'll retest.


OIDC Share Call back function is not loading the screen

OIDC share call back, vp_token has huge image data and it seems to be not loading anymore

it was the system glitch, nothing to be done to fix it


BackupEntries remain in the Source Seed after Control Plane Migration

How to categorize this issue?

/area control-plane-migration
/kind bug
/priority 2
What happened:
Sometimes after executing Control Plane Migration, the migrated Shoot's extensions.gardener.cloud/v1alpha1.BackupEntry is still present in the Source Seed.
What you expected to happen:
There should be no BackupEntry for the migrated Shoot in the Source Seed
How to reproduce it (as minimally and precisely as possible):
Create a Shoot cluster and migrate it. The issue dues not occur with every migration.
Anything else we need to know?:
After closer investigation of the issue here is what happens:
During the Migrate operation where we remove the Shoot's control plane from the Source Seed, the BackupEntry in the Seed is annotated with gardener.cloud/operation=migrate which removes its finalizers. Afterwards the resource is deleted. At the end of the Migrate operation the Spec.SeedName of the BackupEntry in the garden cluster is switched to the Destination Seed. However, it seems that the BackupEntry controller in the gardenlet reconciles the resource either after the BackupEntry has been removed from the Source Seed but before the Spec.SeedName has been changed or reconciles it with outdated data. This basically redeploys the BackupEntry on the Source Seed
Environment:

Gardener version: 1.20.0
Kubernetes version (use kubectl version):
Cloud provider or hardware configuration: all
Others:

/assign
/invite @kris94 @timebertt @rfranzke

One option would be to add a Status.SeedName field to the BackupEntry in the garden cluster and it will do any steps to migrate the BackupEntry from the Source Seed to the Destination Seed if Status.SeedName != Spec.SeedName - similar to what happens with the Shoot resource. The BackupEntry in the Seed will not be directly annotated with gardener.cloud/operation=migrate as this will be taken care of by the BackupEntry controller in the gardenlet.
Another would be to annotate the BackupEntry with gardener.cloud/operation=migrate and once it is done with with migrating the BackupEntry in the seed cluster, it removes this annotation and sets its Spec.SeedName = nil. Then it waits for the shoot reconciliation in the gardenlet to set its new Spec.SeedName.
@amshuman-kr @rfranzke wdyt?

I like the first proposal for similarity reasons to the Shoot resource and to let the BackupEntry controller in gardenlet coordinate this/encapsulate the required knowledge, so that the Shoot controller in gardenlet doesn't need to know about these details and just change the .spec.seedName.

One question: Will we have a similar handling for spec.bucketName? According to https://github.com/gardener/gardener/issues/3491#issuecomment-790656701, the bucket will also change after migration.

One question: Will we have a similar handling for spec.bucketName? According to #3491 (comment), the bucket will also change after migration.

I guess we would have a better idea of how to handle this once we have agreed on how to migrate data between the buckets of the source and destination seeds. We could add the source bucket to the BackupEntry.Status.BucketName and have the destination bucket in the BackupEntry.Spec.BucketName - but we will have to keep those until the etcd data is migrated.


Instructions are not up-to-date - mailbox usage page

[Enter feedback here]
Instructions on this page are not up to date, there is no drop-down menu to access exchange/usage
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e612a4e4-d051-27a7-e54a-bb1ac3fe0849
Version Independent ID: 653be32f-e4e8-8a72-98b3-a629238ecbd5
Content: Microsoft 365 Reports in the admin center - Mailbox usage - Microsoft 365 admin
Content Source: microsoft-365/admin/activity-reports/mailbox-usage.md
Service: o365-administration
GitHub Login: @KwekuA
Microsoft Alias: kwekua

@loveall27 Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/3573
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @loveall27 Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


WIP: Replace patches

Hi @tambien, I hope you're doing good.
this is not meant to be a mergeable pull request. It is more like a proof of concept which could be extended to other parts of Tone.js if you like it.
I recently noticed that Tone.js doesn't work well with my standardized-audio-context package. After some debugging I figured that Tone.js is modifiying built-in objects like the AudioContext prototype. My library on the other hand uses these objects to determine the API support in the currently used browser.
Therefore I began to replace every modification of built-in objects with internal helper functions. For now I only replaced the chain() and connect() functions of AudioNodes.
I would argue that every modification of a built-in object should ideally be replaced with a helper function as it is not considered a good practice to modify objects owned by the browser. Tone.js is so popular that it might one day cause a similar problem as MooTools did by modifying the Array.prototype. (https://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible)
Do you although think that using internal helpers is a viable approach? I'm curious on your thoughts.

Sorry for not following up on this pull request. I would of course be happy if standardized-audio-context proofs to be useful for Tone.js. Let me know if there is anything I need to do to make it work.

@chrisguttandin thanks! i will let you know how it goes


PrimeFaces-served icons CSS fails to load after changing design

If the NSF is left alone, this generally works (as in the riekpil.de example), but opening the NSF or making a change that initializes a full app reload (e.g. re-saving faces-config.xml or a Java file) makes the resource fail until a server restart or, presumably, the app expires.

There's no error message in the response or on the console, though there's a logged message (without a trace) about trying to get a writer after already getting an output stream for the request - that implies that it could be squelching some other problem.
The fact that it only happens on a "full" app refresh makes me wonder if there's some aspect of it sticking around that causes trouble, like caches resources or the like. It'll be worth investigating whether the ServletContext and related elements really come in clean after a refresh.

It looks like this specifically happens when you have jakarta.faces.PROJECT_STAGE=Development, though I'm not even sure why that'd matter - from what I can tell, the Servlet and the special ClassLoader it uses should be discarded entirely on design change anyway.

In some initial investigation, it seems like the problem may be down to the way classes are loaded from the NSF. Currently, it's done via module.getModuleClassLoader().loadClass(className), but switching it to Class.forName(className, true, module.getClassLoader()) appears to avoid the trouble.

Turns out that wasn't the problem, but it's good to fix anyway.
The actual exception is currently being squelched by the exception handler in NsfJsfServlet, which doesn't log the exception anywhere when it can't get a Writer (which is where the only log line is coming from). Changing the exception handler to log the full trace reveals:
java.lang.ClassCastException: org.primefaces.context.PrimeRequestContext incompatible with org.primefaces.context.PrimeRequestContext
	at org.primefaces.context.PrimeRequestContext.getCurrentInstance(PrimeRequestContext.java:83)
	at org.primefaces.application.resource.PrimeResource.<init>(PrimeResource.java:46)
	at org.primefaces.application.resource.PrimeResourceHandler.wrapResource(PrimeResourceHandler.java:106)
	at org.primefaces.application.resource.PrimeResourceHandler.createResource(PrimeResourceHandler.java:72)
	at org.apache.myfaces.el.unified.resolver.ResourceResolver.getValue(ResourceResolver.java:141)
	at jakarta.el.CompositeELResolver.getValue(CompositeELResolver.java:136)
	at com.sun.el.parser.AstValue.getValue(AstValue.java:114)
	at com.sun.el.parser.AstValue.getValue(AstValue.java:177)
	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:183)
	at org.apache.myfaces.shared.resource.ValueExpressionFilterInputStream.read(ValueExpressionFilterInputStream.java:128)
	at java.base/java.io.InputStream.read(InputStream.java:293)
	at java.base/java.io.InputStream.read(InputStream.java:218)
	at org.apache.myfaces.application.ResourceHandlerImpl.pipeBytes(ResourceHandlerImpl.java:701)
	at org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:638)
	at jakarta.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:72)
	at org.primefaces.application.resource.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:87)
	at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:196)
	at org.openntf.xsp.jsf.nsf.NSFJsfServlet.lambda$0(NSFJsfServlet.java:178)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:748)
	at org.openntf.xsp.jsf.nsf.NSFJsfServlet.service(NSFJsfServlet.java:155)
	(snip)

My general theories have revolved around needing to close out older ClassLoaders at the right time, though that hasn't borne fruit. Still, it seems plausible: the Servlet#destroy method in NSFJsfServlet isn't called when modifying a force-reload resource and going to the page again, and so lingering bits remain. On the other hand, keeping a cache of CLs based on DB path and then closing an old one out didn't fix the trouble.
In general, the problem could come from the fact that PrimeFaces uses its own FacesContextFactory, and this lingers around after the refresh. However, my initial test in that direction wasn't fruitful either: in the same check where I look for an orphaned ClassLoader, I also tried calling FactoryFinder.releaseFactories(), but the problem remained.

Similarly, calling FactoryFinder.releaseFactories() after each request (so it's in the same ClassLoader) doesn't change the problem either.

This is weirdly fiddly. I've had no luck so far tracking down what might remain between discarded ClassLoaders. Looking at the FacesServlet and the objects it gets from the factory, they're all new instances, including the Prime ones.
I also don't see anything stashed in the ServletContext (which is presumably reset) or in the HttpSession.


Key gen command

Generate a private pem key using key command.
Use a private pem key in start command with --key flag.

@integraloleg It would be a good idea to split up obviously separate, decoupled, and useful-to-other-projects functionality to different repositories, like I've done with batch-ethkey

This functionality is not yet useful-to-other-projects because unstable. I think we should return to this later.

@integraloleg I'm worried that we're doing that everytime. Soon I'll be advocating—once again—splitting this repository up into bite sized repos. Each with their own tests and publicly defined interfaces, so that they can evolve independently (as long as the maintain their interface).
Something ridiculously independent exposable in a subcommand like this PR is the perfect case study. What is created could then be a tested dependency of batch-ethkey, which could then join the ecosystem of subcommands.

😓

Though I would disagree on splitting ontol smaller repos just because of splitting, - such split should carefully thought out beforehand. But there is no point to include auxiliary functionality into a single executable as that executable would reside in memory for a long run and we will just waste memory for the code implementing the functionality not used in the current run.


Introduce cost center creation showcase app

I suspect the file integration-tests/dev_jco_rfc.trc should not have been committed, right?

Trace file integration-tests/dev_jco_rfc.trc removed

Thanks, can you add this app as one line to the root README.md file where the applications of this repo are listed?
Are there any non-obvious prerequisites that the S/4 system to connect to has to fulfill?

@sacnl :
(1) README.md adjusted
(2) None.


export Config type

I'd like to be able to separate my config as export const variantConfig: Config = { ... } and then pull those into storybook stories argTypes, but I don't see how I can import that type.
Alternatively, add .config to the returned function from cva() and we can access it through variants.config
argTypes: {
  color: {
    values: Object.keys(variants.config.variants.color),
    control: { type: 'radio' },
  }
}

Duplicate of https://github.com/joe-bell/cva/discussions/146


Fix CI parent branch check

Previously, the list of commits found by the parent check script was
incorrect, causing failures on pull requests submitted to the prod
branch. This change reaches out to github via the v3 api with an
authenticated request to gather the definitive list of commits for a
pull request and compare them against the commits in the stg branch
before merging to prod.

@twiest @kwoodson can you please give this a look when you have a chance?
This, plus https://github.com/openshift/openshift-tools/pull/1997 should resolve the issues with testing on the prod branch.

Tests are failing here because the change made to run_tests.py to set the new environment variable containing the list of commits that the parent check consumes is not present in stg yet.
All other tests are passing, this is ready to merge upon approval.


Problem with running Pysplit

Hello Melissa,
I hope that you are doing well. I am trying to use Pysplit. I am using Jupyter with Python 2.7 and I have the following problem. I tried very hard to follow your steps in the Github repository examples but when I am not able to make it work.

I am running the following command:
import pysplit
pysplit.generate_bulktraj("Example", hysplit_working="C:/hysplit4/working", output_dir="C:/Users/dell/Dropbox/Pysplit/trajectories/facilityexample", meteo_dir="C:/Users/dell/Dropbox/Pysplit/gdas", years=[2005], months=[6], hours= [6,12,18], altitudes=[500,1500], coordinates=(34.4326157, -119.9028486), run=48, monthslice=slice(0, 32, 1), meteo_bookends=([0]), get_reverse=False, get_clipped=False, hysplit="C:/hysplit4/exec/hyts_std")

I get the following error:

AttributeError                            Traceback (most recent call last)
 in ()
1 import pysplit
----> 2 pysplit.generate_bulktraj("Example", hysplit_working="C:/hysplit4/working", output_dir="C:/Users/dell/Dropbox/Pysplit/trajectories/facilityexample", meteo_dir="C:/Users/dell/Dropbox/Pysplit/gdas", years=[2005], months=[6], hours= [6,12,18], altitudes=[500,1500], coordinates=(34.4326157, -119.9028486), run=48, monthslice=slice(0, 32, 1), meteo_bookends=([0]), get_reverse=False, get_clipped=False, hysplit="C:/hysplit4/exec/hyts_std")
AttributeError: 'module' object has no attribute 'generate_bulktraj'
I was wondering if you think this is due to an installation problem or something. I hope that you can help me and sorry if the question is too basic.
Best,
Danae

Hi Danae,
Only one thing immediately comes to mind- are you using PySPLIT 0.3.4, the most current version (to check, run pysplit.__version__)?  This function had a different name in early versions.
Mellissa

Just as a clarification comment. The problem (I think) was that I had installed pysplit in python 3.7... I specified the environment as python 3.5, installed pysplit again and I was able to import pysplit and run bulk trajectories perfectly (with Pysplit 0.3.4).


Rework add-version.sh into update.sh a la other repos

To conform with other similar setups, add-version.sh likely needs to become update.sh and be taught how to derive the latest version (e.g. 1.2.0) from a given release (e.g. 1.2) and assemble a .travis.yml file dynamically. Two examples are httpd and cassandra.

@iemejia do you think you could take this on?

Sure, I will take a look, maybe we shall use the Asignees github mechanism to show when we are working on any of the ongoing issues.


Correctly set up package_dir for src/ prefix

This adds something like
package_dir = \
{'': 'src'}

setup(...
      package_dir=package_dir,
)

to setup.py if the module is found inside a src/ prefix.
Fix #302.
Syntax reference: https://docs.python.org/3.9/distutils/setupscript.html#listing-whole-packages

Looks reasonable, but can we have a test? The test_sdist module already has a handy function to get global variables from a generated setup.py, so it should be easy to add.

My work PC just broke down :( I’m sending it for replacement tomorrow and will come back to this when I can (hopefully not for too long).

No problem, thanks for letting me know.