response.data is only working with some versions

I recently built my app for android from my office computer, though the code is synchronised through git. When I built the app, suddenly all the API calls are not working. When I looked into the issue, the response.data is no longer working.
`
void getHttp() async {
try {
var response = await Dio().get('http://www.google.com');
print(response.data);  ---> no longer can access .data
} catch (e) {
print(e);
}
}
`

ok I installed the latest version of the package and it seems to be working fine now.
My project was using
"dio: ^4.0.0"
I changed it to
"dio: ^4.0.6"
so my theory is that, the project was probably installing a random version in between "4.0.0" - "4.0.6", which probably didn't have support for "response.data" or wasn't returning a Map.
@ldsouza93 try setting it to the latest version and re-build the application


Add instructions on adding new Actions workflows

Once this is merged, I'll send an email to the dev list with similar instructions

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

R: @Abacn @andreydevyatkin @tvalentyn @liferoad


fix(jdbc-sink): relax the check for UPDATE_DELETE op

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
It should be safe to ignore the U- op in jdbc sink, since we use UPSERT to deliver events into downstream database which can resolve the inconsistent events.
related: https://github.com/risingwavelabs/risingwave/issues/14031
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Just curious that when will we miss the upsert delete?

Not sure why, more context here https://risingwave-labs.slack.com/archives/C06F37346CR/p1718669258478389

I forgot to add the cherry-pick action for v1.10, I will relabel to trigger the action after #17301


fix: display schema description if available

Resolves: https://github.com/graphql/graphiql/issues/656

I am a novice with javascript so I would appreciate some help linting and test this.


Broken release on v0.11.0-rc1

Expected Behavior
After upgrading to the official release v0.110-rc1, pods in namespace tekton-pipelines should run successfully
Actual Behavior
$ kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
$ kubectl get -n tekton-pipelines pods
NAME                                           READY   STATUS             RESTARTS   AGE
tekton-pipelines-controller-65c64786c8-kmfxh   0/1     CrashLoopBackOff   4          2m38s
tekton-pipelines-webhook-75c699fff9-7c6pt      0/1     CrashLoopBackOff   4          2m38s

Steps to Reproduce the Problem
Step 1: reset
$ kubectl delete namespace tekton-pipelines
namespace "tekton-pipelines" deleted

Step 2: install latest offical release as shown here
$ kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
$ kubectl get -n tekton-pipelines pods
NAME                                           READY   STATUS             RESTARTS   AGE
tekton-pipelines-controller-65c64786c8-kmfxh   0/1     CrashLoopBackOff   4          2m38s
tekton-pipelines-webhook-75c699fff9-7c6pt      0/1     CrashLoopBackOff   4          2m38s

Step 3: Rollback to previous version 0.9.0 and approve it works.
$ kubectl delete namespace tekton-pipelines
namespace "tekton-pipelines" deleted
$ kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.9.0/release.yaml
$ kubectl get -n tekton-pipelines pods
NAME                                           READY   STATUS    RESTARTS   AGE
tekton-pipelines-controller-754c496f57-xm9gp   1/1     Running   0          7s
tekton-pipelines-webhook-6664fb8c56-t2c4z      1/1     Running   0          7s

Additional Info
See here for the two pods (controller and webhook) output
kubectl get -n tekton-pipelines pods/tekton-pipelines-controller-65c64786c8-kmfxh -o json

{
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
        "annotations": {
            "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
        },
        "creationTimestamp": "2020-03-09T22:10:25Z",
        "generateName": "tekton-pipelines-controller-65c64786c8-",
        "labels": {
            "app": "tekton-pipelines-controller",
            "app.kubernetes.io/component": "controller",
            "app.kubernetes.io/name": "tekton-pipelines",
            "pipeline.tekton.dev/release": "v0.11.0-rc1",
            "pod-template-hash": "65c64786c8",
            "version": "v0.11.0-rc1"
        },
        "name": "tekton-pipelines-controller-65c64786c8-kmfxh",
        "namespace": "tekton-pipelines",
        "ownerReferences": [
            {
                "apiVersion": "apps/v1",
                "blockOwnerDeletion": true,
                "controller": true,
                "kind": "ReplicaSet",
                "name": "tekton-pipelines-controller-65c64786c8",
                "uid": "c717e023-6252-11ea-a334-42010a800156"
            }
        ],
        "resourceVersion": "14585",
        "selfLink": "/api/v1/namespaces/tekton-pipelines/pods/tekton-pipelines-controller-65c64786c8-kmfxh",
        "uid": "c71d1a95-6252-11ea-a334-42010a800156"
    },
    "spec": {
        "containers": [
            {
                "args": [
                    "-kubeconfig-writer-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/kubeconfigwriter:v0.11.0-rc1@sha256:66ff7dd82f77a9e7a5f5fbc6783baf5af732bb4428e0c7293ce7c285bd06f90e",
                    "-creds-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/creds-init:v0.11.0-rc1@sha256:d1251c017ad8db911f6b459f9cbe94328c962b619b5a6e4ef57524254c1dc30d",
                    "-git-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.11.0-rc1@sha256:90bab5bf608890d086942890681d84faf82c1cc766c97ad95e309c50bdac3121",
                    "-nop-image",
                    "tianon/true",
                    "-shell-image",
                    "busybox",
                    "-gsutil-image",
                    "google/cloud-sdk",
                    "-entrypoint-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/entrypoint:v0.11.0-rc1@sha256:4c6b3559819aa9e32b8b6b506140115a93e66fd513036c1d20f3426f5e405be1",
                    "-imagedigest-exporter-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/imagedigestexporter:v0.11.0-rc1@sha256:8b339a57f2080c6d017636317e368cca3c9124f0fe14af98e53d1dc446bb897e",
                    "-pr-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/pullrequest-init:v0.11.0-rc1@sha256:62388b0dd5fd3b12444e454cdb6ec967afb557dd2131a9f94bb7bb98761b5f35",
                    "-build-gcs-fetcher-image",
                    "gcr.io/tekton-releases/github.com/tektoncd/pipeline/vendor/github.com/googlecloudplatform/cloud-builders/gcs-fetcher/cmd/gcs-fetcher:v0.11.0-rc1@sha256:74fd88bb0c4810483bdbbfb779d9ad01324145d5e3e63c4c9271c61ae0d4e1c7"
                ],
                "env": [
                    {
                        "name": "SYSTEM_NAMESPACE",
                        "valueFrom": {
                            "fieldRef": {
                                "apiVersion": "v1",
                                "fieldPath": "metadata.namespace"
                            }
                        }
                    },
                    {
                        "name": "CONFIG_LOGGING_NAME",
                        "value": "config-logging"
                    },
                    {
                        "name": "CONFIG_OBSERVABILITY_NAME",
                        "value": "config-observability"
                    },
                    {
                        "name": "CONFIG_ARTIFACT_BUCKET_NAME",
                        "value": "config-artifact-bucket"
                    },
                    {
                        "name": "CONFIG_ARTIFACT_PVC_NAME",
                        "value": "config-artifact-pvc"
                    },
                    {
                        "name": "METRICS_DOMAIN",
                        "value": "tekton.dev/pipeline"
                    }
                ],
                "image": "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.11.0-rc1@sha256:786a306a2645186ad2c547db2cfc3e1987cd31962166dc320c908d10ebe903b9",
                "imagePullPolicy": "IfNotPresent",
                "name": "tekton-pipelines-controller",
                "resources": {},
                "terminationMessagePath": "/dev/termination-log",
                "terminationMessagePolicy": "File",
                "volumeMounts": [
                    {
                        "mountPath": "/etc/config-logging",
                        "name": "config-logging"
                    },
                    {
                        "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
                        "name": "tekton-pipelines-controller-token-xwl7c",
                        "readOnly": true
                    }
                ]
            }
        ],
        "dnsPolicy": "ClusterFirst",
        "enableServiceLinks": true,
        "nodeName": "gke-ci-test2-default-pool-eaeff9be-4djb",
        "priority": 0,
        "restartPolicy": "Always",
        "schedulerName": "default-scheduler",
        "securityContext": {},
        "serviceAccount": "tekton-pipelines-controller",
        "serviceAccountName": "tekton-pipelines-controller",
        "terminationGracePeriodSeconds": 30,
        "tolerations": [
            {
                "effect": "NoExecute",
                "key": "node.kubernetes.io/not-ready",
                "operator": "Exists",
                "tolerationSeconds": 300
            },
            {
                "effect": "NoExecute",
                "key": "node.kubernetes.io/unreachable",
                "operator": "Exists",
                "tolerationSeconds": 300
            }
        ],
        "volumes": [
            {
                "configMap": {
                    "defaultMode": 420,
                    "name": "config-logging"
                },
                "name": "config-logging"
            },
            {
                "name": "tekton-pipelines-controller-token-xwl7c",
                "secret": {
                    "defaultMode": 420,
                    "secretName": "tekton-pipelines-controller-token-xwl7c"
                }
            }
        ]
    },
    "status": {
        "conditions": [
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "status": "True",
                "type": "Initialized"
            },
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "message": "containers with unready status: [tekton-pipelines-controller]",
                "reason": "ContainersNotReady",
                "status": "False",
                "type": "Ready"
            },
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "message": "containers with unready status: [tekton-pipelines-controller]",
                "reason": "ContainersNotReady",
                "status": "False",
                "type": "ContainersReady"
            },
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "status": "True",
                "type": "PodScheduled"
            }
        ],
        "containerStatuses": [
            {
                "containerID": "docker://eccb17fe216980ec89c6f2b092609151d734f4872bc64319bc3671832bf954ee",
                "image": "sha256:31300f939d2c427b3caee8280ec2a7ddaa2d13832b97375f8f484cae6d36a716",
                "imageID": "docker-pullable://gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/controller@sha256:786a306a2645186ad2c547db2cfc3e1987cd31962166dc320c908d10ebe903b9",
                "lastState": {
                    "terminated": {
                        "containerID": "docker://eccb17fe216980ec89c6f2b092609151d734f4872bc64319bc3671832bf954ee",
                        "exitCode": 1,
                        "finishedAt": "2020-03-09T22:13:27Z",
                        "reason": "Error",
                        "startedAt": "2020-03-09T22:13:27Z"
                    }
                },
                "name": "tekton-pipelines-controller",
                "ready": false,
                "restartCount": 5,
                "state": {
                    "waiting": {
                        "message": "Back-off 2m40s restarting failed container=tekton-pipelines-controller pod=tekton-pipelines-controller-65c64786c8-kmfxh_tekton-pipelines(c71d1a95-6252-11ea-a334-42010a800156)",
                        "reason": "CrashLoopBackOff"
                    }
                }
            }
        ],
        "hostIP": "<IP_ADDRESS>",
        "phase": "Running",
        "podIP": "<IP_ADDRESS>",
        "qosClass": "BestEffort",
        "startTime": "2020-03-09T22:10:25Z"
    }
}

kubectl get -n tekton-pipelines pods/tekton-pipelines-webhook-75c699fff9-7c6pt -o json

{
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
        "annotations": {
            "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
        },
        "creationTimestamp": "2020-03-09T22:10:25Z",
        "generateName": "tekton-pipelines-webhook-75c699fff9-",
        "labels": {
            "app": "tekton-pipelines-webhook",
            "app.kubernetes.io/component": "webhook-controller",
            "app.kubernetes.io/name": "tekton-pipelines",
            "pipeline.tekton.dev/release": "v0.11.0-rc1",
            "pod-template-hash": "75c699fff9",
            "role": "webhook",
            "version": "v0.11.0-rc1"
        },
        "name": "tekton-pipelines-webhook-75c699fff9-7c6pt",
        "namespace": "tekton-pipelines",
        "ownerReferences": [
            {
                "apiVersion": "apps/v1",
                "blockOwnerDeletion": true,
                "controller": true,
                "kind": "ReplicaSet",
                "name": "tekton-pipelines-webhook-75c699fff9",
                "uid": "c7504daf-6252-11ea-a334-42010a800156"
            }
        ],
        "resourceVersion": "14629",
        "selfLink": "/api/v1/namespaces/tekton-pipelines/pods/tekton-pipelines-webhook-75c699fff9-7c6pt",
        "uid": "c753b9bf-6252-11ea-a334-42010a800156"
    },
    "spec": {
        "containers": [
            {
                "env": [
                    {
                        "name": "SYSTEM_NAMESPACE",
                        "valueFrom": {
                            "fieldRef": {
                                "apiVersion": "v1",
                                "fieldPath": "metadata.namespace"
                            }
                        }
                    },
                    {
                        "name": "CONFIG_LOGGING_NAME",
                        "value": "config-logging"
                    },
                    {
                        "name": "CONFIG_OBSERVABILITY_NAME",
                        "value": "config-observability"
                    },
                    {
                        "name": "WEBHOOK_SERVICE_NAME",
                        "value": "tekton-pipelines-webhook"
                    },
                    {
                        "name": "METRICS_DOMAIN",
                        "value": "tekton.dev/pipeline"
                    }
                ],
                "image": "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/webhook:v0.11.0-rc1@sha256:06d797f5456bfcd2c0bf50d701d899c6ad286dddf4d334c554c8e3e0c6949ca8",
                "imagePullPolicy": "IfNotPresent",
                "name": "webhook",
                "ports": [
                    {
                        "containerPort": 9090,
                        "name": "metrics",
                        "protocol": "TCP"
                    },
                    {
                        "containerPort": 8008,
                        "name": "profiling",
                        "protocol": "TCP"
                    },
                    {
                        "containerPort": 8443,
                        "name": "https-webhook",
                        "protocol": "TCP"
                    }
                ],
                "resources": {},
                "securityContext": {
                    "allowPrivilegeEscalation": false
                },
                "terminationMessagePath": "/dev/termination-log",
                "terminationMessagePolicy": "File",
                "volumeMounts": [
                    {
                        "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
                        "name": "tekton-pipelines-controller-token-xwl7c",
                        "readOnly": true
                    }
                ]
            }
        ],
        "dnsPolicy": "ClusterFirst",
        "enableServiceLinks": true,
        "nodeName": "gke-ci-test2-default-pool-eaeff9be-4djb",
        "priority": 0,
        "restartPolicy": "Always",
        "schedulerName": "default-scheduler",
        "securityContext": {},
        "serviceAccount": "tekton-pipelines-controller",
        "serviceAccountName": "tekton-pipelines-controller",
        "terminationGracePeriodSeconds": 30,
        "tolerations": [
            {
                "effect": "NoExecute",
                "key": "node.kubernetes.io/not-ready",
                "operator": "Exists",
                "tolerationSeconds": 300
            },
            {
                "effect": "NoExecute",
                "key": "node.kubernetes.io/unreachable",
                "operator": "Exists",
                "tolerationSeconds": 300
            }
        ],
        "volumes": [
            {
                "name": "tekton-pipelines-controller-token-xwl7c",
                "secret": {
                    "defaultMode": 420,
                    "secretName": "tekton-pipelines-controller-token-xwl7c"
                }
            }
        ]
    },
    "status": {
        "conditions": [
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "status": "True",
                "type": "Initialized"
            },
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "message": "containers with unready status: [webhook]",
                "reason": "ContainersNotReady",
                "status": "False",
                "type": "Ready"
            },
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "message": "containers with unready status: [webhook]",
                "reason": "ContainersNotReady",
                "status": "False",
                "type": "ContainersReady"
            },
            {
                "lastProbeTime": null,
                "lastTransitionTime": "2020-03-09T22:10:25Z",
                "status": "True",
                "type": "PodScheduled"
            }
        ],
        "containerStatuses": [
            {
                "containerID": "docker://8c13625907cecfd41f5c4ee278bf1931f96ac339e0d95938f85ff61ae602e18a",
                "image": "sha256:00b46864a1c443738089a729a7542af0034b973eb6a42112f264ab9da99a32b4",
                "imageID": "docker-pullable://gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/webhook@sha256:06d797f5456bfcd2c0bf50d701d899c6ad286dddf4d334c554c8e3e0c6949ca8",
                "lastState": {
                    "terminated": {
                        "containerID": "docker://8c13625907cecfd41f5c4ee278bf1931f96ac339e0d95938f85ff61ae602e18a",
                        "exitCode": 1,
                        "finishedAt": "2020-03-09T22:13:40Z",
                        "reason": "Error",
                        "startedAt": "2020-03-09T22:13:40Z"
                    }
                },
                "name": "webhook",
                "ready": false,
                "restartCount": 5,
                "state": {
                    "waiting": {
                        "message": "Back-off 2m40s restarting failed container=webhook pod=tekton-pipelines-webhook-75c699fff9-7c6pt_tekton-pipelines(c753b9bf-6252-11ea-a334-42010a800156)",
                        "reason": "CrashLoopBackOff"
                    }
                }
            }
        ],
        "hostIP": "<IP_ADDRESS>",
        "phase": "Running",
        "podIP": "<IP_ADDRESS>",
        "qosClass": "BestEffort",
        "startTime": "2020-03-09T22:10:25Z"
    }
}

/kind bug

@yuwenma
Could you paste the log for the pod?

@yuwenma
Could you paste the log for the pod?

It should be easily reproduced as described in "Steps to Reproduce the Problem". Do you suggest I'm the only one facing the problem? :open_mouth:

@yuwenma
yeah, I cannot reproduce it.

I see. Here's the log
$ kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
$ kubectl get -n tekton-pipelines pods
NAME                                           READY   STATUS             RESTARTS   AGE
tekton-pipelines-controller-65c64786c8-cd952   0/1     CrashLoopBackOff   1          14s
tekton-pipelines-webhook-75c699fff9-2qmt5      0/1     CrashLoopBackOff   1          14s

$ kubectl logs -n tekton-pipelines pods/tekton-pipelines-controller-65c64786c8-cd952
2020/03/10 01:52:26 Registering 4 clients
2020/03/10 01:52:26 Registering 3 informer factories
2020/03/10 01:52:26 Registering 8 informers
2020/03/10 01:52:26 Registering 2 controllers
{"level":"info","caller":"logging/config.go:108","msg":"Successfully created the logger."}
{"level":"info","caller":"logging/config.go:109","msg":"Logging level set to info"}
{"level":"fatal","logger":"tekton","caller":"sharedmain/main.go:149","msg":"Version check failed","commit":"60d76bd","error":"kubernetes version \"v1.14.10-gke.17\" is not compatible, need at least \"v1.15.0\" (this can be overridden with the env var \"KUBERNETES_MIN_VERSION\")","stacktrace":"github.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain.MainWithConfig\n\tgithub.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain/main.go:149\ngithub.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain.MainWithContext\n\tgithub.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain/main.go:114\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/controller/main.go:72\nruntime.main\n\truntime/proc.go:203"}

$ kubectl logs -n tekton-pipelines pods/tekton-pipelines-webhook-75c699fff9-2qmt5
2020/03/10 01:53:08 Registering 1 clients
2020/03/10 01:53:08 Registering 1 informer factories
2020/03/10 01:53:08 Registering 3 informers
2020/03/10 01:53:08 Registering 4 controllers
{"level":"info","caller":"logging/config.go:108","msg":"Successfully created the logger."}
{"level":"info","caller":"logging/config.go:109","msg":"Logging level set to info"}
{"level":"fatal","logger":"webhook","caller":"sharedmain/main.go:149","msg":"Version check failed","commit":"60d76bd","error":"kubernetes version \"v1.14.10-gke.17\" is not compatible, need at least \"v1.15.0\" (this can be overridden with the env var \"KUBERNETES_MIN_VERSION\")","stacktrace":"github.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain.MainWithConfig\n\tgithub.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain/main.go:149\ngithub.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain.MainWithContext\n\tgithub.com/tektoncd/pipeline/vendor/knative.dev/pkg/injection/sharedmain/main.go:114\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/webhook/main.go:136\nruntime.main\n\truntime/proc.go:203"}

Looks like the error is because my cluster (GKE Cluster) is not using the latest kubernetes version. Does tekton have a more concrete plan about the backward compatible support for kubernetes?

hey @yuwenma
indeed, starting from 0.11-rc1, the minimum required version of k8s is 1.15. As commented on https://github.com/tektoncd/pipeline/issues/2187#issuecomment-596372663, the bump was to be able to bump knative.dev/pkg, to benefit enhancements on that, and prepare the use of conversion webhook (that are beta in 1.15). We need to make sure it is written on the main README.
(On triage, usually, we ask to specify the kubernetes version and the tekton version deployed — we need to update the github issue template to reflect that)
/kind documentation
/remove-kind bug

@vdemeester Besides readme, do you think we can add an extra check on the cluster side? For example, the  kubectl apply  returns error if the cluster is in a tekton incompatible version.
I feel like making the README up-to-date and forces users to check their clusters before upgrading tekton may still cause confusions, especially since users normally use the default  k8s version provided by the cloud-provider, and may always want to try out the latest tekton official release. WDYT?

@vdemeester Besides readme, do you think we can add an extra check on the cluster side? For example, the kubectl apply returns error if the cluster is in a tekton incompatible version.

I don't know if it's even possible :sweat_smile:. We could try but…

I feel like making the README up-to-date and forces users to check their clusters before upgrading tekton is not handy, especially considering that users normally use the default k8s version provided by the cloud-provider, and may always want to try out the latest tekton official release. WDYT?

Right, so there is a few things here:

Tekton might need some feature from a specific version of tekton (in this case, we need 1.15 for conversion webhook, and also because knative.dev/pkg has this requirement). At some point, Tekton maintainers needs to make a choice of bump the minimum required version of k8s. This is part of the lifecycle of the project.
Up until final 0.11 release, Tekton should still be considered alpha software — in my mind, this means that user should read the release notes before updating/trying tekton on their cluster (https://github.com/tektoncd/pipeline/releases/tag/v0.11.0-rc1).

It's not an easy problem, but we gotta make some choice at a given point of time, and users need too (and need to read releases notes of the software they deploy :angel:). My thought is, the more GA tekton is gonna be, the easier this is gonna be, but there will always be some cases like that, where a new version of Tekton bump the minimum required, and some cloud platform won't have it as default.


[Bug]: Application form authority limit change permission prompt needs to be modified

ODC version
odc431
OB version

What happened?

What did you expect to happen?

How can we reproduce it (as minimally and precisely as possible)?
Prompt for viewing and changing permissions on application forms
Anything else we need to know?
No response

pass


Fixing histogram loading state

CR: @viddo
Fixes #206

Changed code reviewer, free @javierarce :D.

LGTM


There are no code-39-vin tests

code-39 is tested, but code-39-vin is not.  There are fixtures for code-39-vin tests, but they are not used.

Sadly, the only fixture that works in there right now is image-006, but i'll add it.  I'm not sure if the configuration parameters are messed up or if that reader is messed up.

fwiw, image-006 only works with size = 800, sequence = false, halfSample = false.  The default config provided by integration.spec.js generateConfig() function has different settings and fails.
The default generateConfig() does not appear to work on any of the code_39_vin fixtures.  The decoder itself is at least functional, though i can't attest to it's quality.  We may be able to get a lot more of them working by adjusting the config.

001, 003 works with 1280 size
002 looks to be possibly too blurry to expect a decode
004 may also be too blurry, not sure
005, 8, 9, 10 i have no idea
006 works in 800 and 1200 size
007 locator finds the correct area at 1600 with patch-size large, but doesn't decode anything


Rethink interaction of all conda-related tooling in conda-store

Context
@jaimergp suggested I open this for discussing long-term plans for conda-store with regard to how conda tools are used.
Right now, we use conda as a library, via conda-lock, and via constructor.
All these know nothing about each other (only implicitly, e.g., via a shared global conda cache), which might lead to problems.
For example, https://github.com/conda-incubator/conda-store/pull/745#issuecomment-1916008070 was discovered because conda-store and conda-lock didn't communicate, so the shared cache was not used, which led to everything being downloaded on every build.
Value and/or benefit
Better performance and reliability.
Anything else?
No response

@peytondmurray  this is relevant per the recent discussions

Conda is not the only backend for environment specification and resolution. This is part of a larger discussion about pluggable backends. In light of recent discussions about that, I'm closing this for now and we can revisit in the future after the significant changes to come.


Get full coverage in our bench marks project.

We should get a lot more coverage of different performance tests in our Benchmark project. So most major classes covered.
Extensions

[ ] When Activated
[ ] When Any
[ ] When Any Value
[ ] When Any Observable
[ ] When Any Dynamic

Interactions

[ ] Interaction
[ ] Register Handlers
[ ] Handle
[ ] Interaction Context

Observable Properties

[ ] Reactive Object
[ ] Observable As Property Helper

Reactive Commands

[x] Create
[x] Create From Task
[x] Create From Observable
[ ] Create Combined
[ ] Invoke

Lately, I’ve been interested by everything performance so this could be a fun thing! are we talking of adding micro-benchmarks with a benchmark.NET? What’s the scope?

@kavignon if you want to help out this is probably a good starter task. Essentially we want a base line of most of our existing code base so we aren't going backwards in terms of performance. There is not a platform runner at the moment for benchmark dot net for Android iOS so I would focus on core functionality first that didn't exist in the platforms folder and work from there.

You mention full coverage. How do I determine case coverage to make sure when I submit my PR, it makes sense with what you’d expect in the benchmark project?

Yeah coverage is a bit tricky since as far as I know there isn't any automated tools. I was just going to go through each file in the src/ReactiveUI folder and produce a benchmark for it. I wouldn't do the Platform folder

How about this idea; I’m going to close ReactiveUI and do a few benchmarks on my own. Then submit a PR for those and we can discuss on said PR what you would have like to see if I miss anything. When that portion is stable, I’ll get over the items I haven’t done beforehand. Sounds good?

@Kavignon  I'd recommend starting with one of the items above, there are 4 categories of benchmarks.  I believe I have the ReactiveCommand started.  Let me dust that branch off this weekend and submit a PR for it.  Then you can just follow that PR for the remaining benchmarks.  That way you don't invest too much effort. I'd recommend open a PR per category to keep it easier to manage.  The bigger the PR the harder it is to review.

That sounds pretty good in fact! let me know here when your PR is ready!

Adding ToProperty extension methods to the list.

Hi may i can help , still open?

@GmausDev definitely one we could use help with


Backport 2.7: Fix memory leak in ssl_server2 when buffer allocator and backtracing enabled

Backport of #2070 to Mbed TLS 2.7, fixing #2069.

@RonEld No, the problem is that internally the buffer allocator uses the backtrace_symbols() call which does call the system malloc() under the hood. So there is an actual memory leak.

retest

retest


StackOverflowError when password is incorrect

Using version 3.4.1 of the hub gradle plugin I get StackOverflowErrors during execution one one project consistently. I'm not able at this point to determine what is special about this project.
The stack trace looks like this. Based on the stacktrace it looks like it's about to work because the connect socket call is being called but it's only after a very large loop within your RestConnection.java and CredentialsRestConnection.java
*Note that I cut off the stack trace because it's just repeating the last liens over and over again.
[07:55:37]	[Step 1/1] 07:55:35.634 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: java.lang.StackOverflowError
[07:55:37]	[Step 1/1] 07:55:35.635 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.platform.Platform.connectSocket(Platform.java:124)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:187)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.RealConnection.buildConnection(RealConnection.java:173)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:114)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:193)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:129)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:98)
[07:55:37]	[Step 1/1] 07:55:35.636 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
[07:55:37]	[Step 1/1] 07:55:35.637 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
[07:55:37]	[Step 1/1] 07:55:35.637 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
[07:55:37]	[Step 1/1] 07:55:35.638 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:109)
[07:55:37]	[Step 1/1] 07:55:35.638 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
[07:55:37]	[Step 1/1] 07:55:35.638 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
[07:55:37]	[Step 1/1] 07:55:35.638 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
[07:55:37]	[Step 1/1] 07:55:35.638 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
[07:55:37]	[Step 1/1] 07:55:35.638 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:124)
[07:55:37]	[Step 1/1] 07:55:35.653 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
[07:55:37]	[Step 1/1] 07:55:35.653 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
[07:55:37]	[Step 1/1] 07:55:35.653 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:170)
[07:55:37]	[Step 1/1] 07:55:35.653 [ERROR] [org.gradle.BuildExceptionReporter] 	at okhttp3.RealCall.execute(RealCall.java:60)
[07:55:37]	[Step 1/1] 07:55:35.653 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.handleExecuteClientCall(RestConnection.java:258)
[07:55:37]	[Step 1/1] 07:55:35.654 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.handleExecuteClientCall(RestConnection.java:252)
[07:55:37]	[Step 1/1] 07:55:35.654 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.CredentialsRestConnection.clientAuthenticate(CredentialsRestConnection.java:104)
[07:55:37]	[Step 1/1] 07:55:35.654 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.connect(RestConnection.java:130)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.handleExecuteClientCall(RestConnection.java:261)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.handleExecuteClientCall(RestConnection.java:252)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.CredentialsRestConnection.clientAuthenticate(CredentialsRestConnection.java:104)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.connect(RestConnection.java:130)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.handleExecuteClientCall(RestConnection.java:261)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.handleExecuteClientCall(RestConnection.java:252)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.CredentialsRestConnection.clientAuthenticate(CredentialsRestConnection.java:104)
[07:55:37]	[Step 1/1] 07:55:35.655 [ERROR] [org.gradle.BuildExceptionReporter] 	at com.blackducksoftware.integration.hub.rest.RestConnection.connect(RestConnection.java:130)

I figured it out but this should still be fixed. This happens when the password is incorrect.

Yes - this was an issue in the underlying library the hub-gradle plugin uses. We addressed it there, so the next release of the hub-gradle plugin will have this taken care of. I'll close this when we release.


[RFE] Bump Harvester node driver to v0.6.5

Is your feature request related to a problem? Please describe.
Bump Harvester node driver to v0.6.5
Releated Harvester issues:

https://github.com/harvester/harvester/issues/3855

Close as the Harvester team has already validated this on https://github.com/harvester/harvester/issues/3855#issuecomment-1560650742, thanks.


The Settings page requires the email and password fields regardless of whether their changed

Currently the "Email" and "New Password" fields are required by the API when they should not be. The user is unable to update say their username without also providing their email and password. This means users are essentially overwriting both their email and password every time they go to change any field on their profile.

It's pretty common to ask for authentication information when you are about to change sensitive information about the account.
It provides a way to secure those information if an user leaves thier computer unattended without locking their session.
As such changes are rare, it doesn't introduce much inconvenience for users

Sure, that is pretty common, however, that is not what this is.
If you provide invalid credentials on that form your changes to the account aren't rejected. Instead, the credentials for the account change entirely. There is no confirmation of credentials built into the back end for that feature.

If that is supposed to be a way in which the user needs to provide their credentials to change their bio, image, or username, and only those, there will probably also need to be a way to change their email and passwords.

I agree. We can't affect all existing implementations with such changes but the goal is to work as soon as possible on new specs based on all suggestions provided to make them more 'real'


Write a "debug script"

Should do the following;

Read everything it can out of the CDC
Capture a screenshot of each HDMI input
Get MD5 sums of the firmware loaded onto the two devices? - Is that even possible?
Capture dmesg, loaded modules, etc
Capture system version

Basically it should collect a really nice debug report which makes it easy to figure out what the problem is.

Closing this as the HDMI2USB-jahanzeb-firmware is no longer under development.
All active development is now on the HDMI2USB-misoc-firmware which supports both the Atlys and Opsis boards and has loads of other new features!

Closing this as the HDMI2USB-jahanzeb-firmware is no longer under development.
All active development is now on the HDMI2USB-misoc-firmware which supports both the Atlys and Opsis boards and has loads of other new features!


Run ovn ovsdb-servers as anyuid

We may explore tightening it further to restricted-v2 later.
The change gets rid of kolla in startup path in line with:
https://github.com/openstack-k8s-operators/docs/pull/77

/lgtm

CI is temporarily down due to RDO Quay upgrade. I'll recheck later.

/test ovn-operator-build-deploy-kuttl

/test ovn-operator-build-deploy-kuttl


Live

Docs Build status updates of commit 54f6690:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Test


figure out ordering guarantees for messages and history

Suppose Alice and Bob are joined to the same channel. Our current implementation guarantees none of the following properties

If Alice receives msgid x before msgid y, then Bob will receive x before y as well
If msgid x is sent before msgid y, then x has a server-time <= y's server-time
If Alice received msgid x before msgid y, then replays history, x will appear before y in the history replay
(various other plausible-seeming properties related to these)

All of this can be corrected with locking as necessary, let's figure out what we want to do and do it.

The maximalist solution here is something like: rename joinPartMutex to something like channelEventMutex, and acquire it across the entirety of every replayable operation (join, part, and privmsg/notice/tagmsg at least), including the nonblocking sends to channel members. (Just have to make sure we don't hold it during any synchronous sends to the initiating client, in particular, any call to rb.Flush(true).)

Hmm. If this is a fix for the history that we send to users (i.e. something that should be required/expected by spec), it should be noted that this is going to be a problem with any network that has multiple clients connected to it, especially ones that just use traditional spanning-tree architecture. Send message, get echo-message back with your specific timestamp, receive next msg sent by a user on the far side of the network with a slightly-earlier message ID, this won't fix users from needing to deal with that sort of ordering issue.

Excellent point, we shouldn't be worried about providing any guarantees that can't be provided under true federation.

Following up on some discussion in #oragono: we might think about deprecating or removing the use of msgids in after/before/between CHATHISTORY queries, for this reason. Basically, if the client uses timestamps, they can apply a fudge factor (e.g., subtracting 15 seconds from the server-time on the last-delivered message) and query on that basis, whereas it's harder to fudge message IDs (except in ways that are essentially derivative of time-fudging, e.g., fudging the time and then looking for a message ID that was sent around that time).
If there's no safe way to use message IDs in these queries, then we should think about disallowing it.

e seems to think that servers should respect the "causal order" of messages, also that a JOIN has a definite position in the ordering of PRIVMSGs, such that you can safely request messages BEFORE the msgid of your JOIN without missing anything (because anything after your JOIN would have been relayed to you normally).
Our implementation does not provide this guarantee and moreover it seems difficult / bad to require it, particularly in the case of a persistent datastore (we'd have to hold a lock over all JOIN/PART/PRIVMSG and do the datastore write while holding the lock).


Using some backpack-based mods, items can be acquired indefinitely.

I am using Mod Ver 1.0 Mc Ver 1.18.2 Forge. I don't know if it is triggered by stacked items being recovered in the player's inventory, but when I use [Sophisticated Backpacks] or other items that put items directly into the backpack instead of the inventory, the count is not reduced and I can acquire stacked items indefinitely.

Thank you for your report! Should be fixed in the latest version
https://modrinth.com/mod/staaaaaaaaaaaack/version/1.18.2-1.0.1-27


Internationalization and French translations

Hey,
I worked on some things to make the wiki available for certain people and newcomers who don't understand English very well. Also this may help local communities to provide support to members in need, and bring more people to know this main wiki, which should be the reference for anyone playing Beat Saber.
Internationalization
The use of vuepress allows to have some kind of internationalization. So following this doc I propose in this pull request the following way for translated pages in the wiki:

/ location is for English original pages.
/fr/ location is for French translated pages.
/[...]/ location might be for any new translation party, if a local community goes for it.

In the repo, files look like:
wiki
├─ README.md
├─ health-and-safety.md
├─ mapping
│  └─ README.md
├─ fr
│  ├─ README.md
│  ├─ health-and-safety.md
│  └─ mapping
│     └─ README.md
└─ [...]
   ├─ README.md
   ├─ health-and-safety.md
   └─ mapping
      └─ README.md

This means an original file must have an equivalent translated file in every languages. Otherwise the page would lead to 404.
Using locales adds a "Languages" in the banner on which the user can pick any of the implemented languages, condition be the translated page exists.
Ref: commits f35bfd1 & 8e36758
French translations
So I did some translations in French, but some pages are not done yet (whole mapping part, whole modding part and some support part). I will translate the rest when the tool to track updates is ready. The BSFR community might help with that too.
Ref: all other commits
Wiki Update Tracker tool
It doesn't appear in this PR, but I have also been working on a tracker to watch updates on original pages. This is totally required when you see how the wiki grows and evolves every day. As a quick inventory right now, based on my French translations, I have (keep in mind I started more than 3 months ago):

2 files to create
21 files to update
15 files up-to-date (nothing to do yay)

The idea is to get the original file from the last commit which modified the translated file, and compare it to the most recent original file. If anything changed, the translated file must be updated and the translator can use a tool like Diffchecker to know what changed in the original English files.
Here's some schema

why, this does not explain anything heloo, when it's released will be better
Yet, I'm not sure if it should report directly in issues as a Github bot, or through our own BSFR Discord community, or a dedicated web app.
Translation guidelines
Finally, here's some guidance for future translators, to add to CONTRIBUTING maybe.
A translation must follow some principles we should agree to:

Just translate. No content must be added to the translation than the original page itself. This means that, at any time, the translated page has less or the same amount of information as the original page, never more (see something to add, contribute to the original page first).
When you contribute to a translation, you must base it on the original English file which is in your repository / your branch. For example, when I'm updating /fr/README.md in my own fork I'm using /README.md present in my own fork, not the official bsmg.wiki page which may have any discrepancy from what I'm translating. This is mandatory for the Wiki Update Tracker tool to work, as it is its only constraint.
No Google translate please (neither DeepL).

Do you OK?

Hey, this looks great so far!
Your internationalization looks good to me. I was unaware that Vuepress's had the builtin ability to do this, it seems to work pretty well.
I think that the Wiki Update Tracker Tool is a good idea as well.
That seems fit for GitHub Projects. Maybe a different card for each top level folder (such as 'mapping') with the child pages listed on the card as tasks to complete.
Given the amount of commits in this PR, I'd prefer if you please squash your commits before we merge them. I believe this post is shows what you need to do https://stackoverflow.com/a/5201642/12816894
You will likely have to force push your new commit to override the existing ones.
In the future we may add that to the CONTRIBUTING guidelines for all translation PRs.
Thanks for doing all of these translations so far, I imagine it was a lot of work!

There, everything in 1 beautiful commit (+ added most recent files in fr to avoid having a 404 not found when browsing the wiki).
Oh right Github Projects is a good idea I'll keep that in mind. I'll try to integrate the tool to something on my end and maintain the translations up to date, maybe with the help of my French comrades.

Ok, sounds good to me!
I'm open to adding additional GitHub Actions to track the differences between the separate locales.
I'm not sure how it would work exactly, but it may be enough to simply detect when an English page is updated, then create a card in a GitHub project to indicate that the French page should be updated as well. I think you could also use commit history to show all changes to an English page since the last time the French page was updated, in the case that an English page is updated multiple times before the translation is updated.


Fix task stealing after continuation with block allocator

Proposed fix for #18

Codecov Report

Merging #19 (1ce741c) into master (a9d9992) will decrease coverage by 0.27%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##           master      #19      +/-   ##
==========================================
- Coverage   97.18%   96.91%   -0.28%
==========================================
  Files          48       48
  Lines        3237     3242       +5
==========================================
- Hits         3146     3142       -4
- Misses         91      100       +9

Impacted Files
Coverage Δ

include/parlay/internal/block_allocator.h
96.47% <85.71%> (-1.03%)
:arrow_down:

include/parlay/hash_table.h
88.05% <0.00%> (-11.95%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us.


custom_header text with newline doesn't display

Describe the bug
With one of the recent updates custom headers  that were previously working no longer works. I think the issue is when there is a new line character in the text.
To Reproduce
minimal config used to run nvim -u config
return require('packer').startup(function(use)
	use {'glepnir/dashboard-nvim', -- dashboard on vim startup
		config = function()
			local home = os.getenv('HOME')
			local db = require('dashboard')
			db.custom_header = 	{[[
			TEST
			]]}
		end
	}

  if packer_bootstrap then
    require('packer').sync()
  end
end)

Expected behavior
Previously it would display TEST in header.
db.custom_header = 	{[[TEST]]} still works
Screenshots
No Header being displayed

Another weird behavior i noticed was setting db.custom_header =  {'TEST','TEST','TEST','TEST'} causes an extra newline before the last element

you can try that adding a blank line to last line like:
db.custom_header = {
'test',
'test',
'test',
'test',
'',
}

you should check the [[ ]] usage in lua . if you want add some pad . check the doc for pad option
db.custom = { 'test' }
``

This no longer works
local home = os.getenv('HOME')
return require('packer').startup(function(use)
	use {'glepnir/dashboard-nvim', -- dashboard on vim startup
		config = function()
			local home = os.getenv('HOME')
			local db = require('dashboard')
			db.preview_command = 'cat '
			db.preview_file_path = home .. '/temp/test.txt'
			db.preview_file_height = 50
			db.preview_file_width = 50
		end
	}

  if packer_bootstrap then
    require('packer').sync()
  end
end)

with test.txt as
test
test

does not work while it used to work previously.
db.preview_command = 'cat | lolcat' works.
I was previously using a binary file that already had color in it and printing it with just cat.That is now broken.  I cant figure out what i need to change to get it to work again. i thought it was the newline that was causing the issue, looks like i was mistaken.

cat | cat worked lol.

so it works now?

yes. changing the preview_command from cat  to cat | cat fixed it.

Okay but I think cat also should work. I will check it when i have time :)


Update index.md

update kubectl option

This change is

@stewart-yu This page is auto generated from source in another repo. Stand by for more details.

I have changed content of this PR, need you review, thanks @steveperry-53


Use lastchar to set keyboard labels instead of figuring them out post-hoc

This also implies storing the binding label in the struct/class instead of figuring it out later

only if lastchar is alpha (lower != upper)

Implemented for v3.4.0


inapp fix for image going over text in certain devices

Looks good to me. @ryanseams

Tested on simulator with 5 devices of different screen sizes and the results look good to me.


Missing zoom 12 terrarium tiles

Developer support request reports 193 missing tiles, see the "full list" attachment below.
Endpoint used:

https://s3.amazonaws.com/elevation-tiles-prod/terrarium/

Example:

https://s3.amazonaws.com/terrarium/12/331/921.png

Full list:

missing-tiles.txt

I've cleaned up the list of missing tiles from S3, which included all those in the attached list :relieved:
A first pass through those rendered a few, but the majority had errors. I think I've fixed the problems, and the rest are now rendering.

I can confirm it has been partially fixed. Now only 62 remains:
https://s3.amazonaws.com/terrarium/12/[341..342]/[882..912].png

@jan-tosovsky-cz Thanks for the update! We'll keep this issue open until the remaining 62 are also resolved.

Here's an example tile that's still missing:

http://a.tile.openstreetmap.org/12/341/882.png

Which is water up in the Arctic ocean in high latitudes:

http://tangrams.github.io/bubble-wrap/#12/71.0027/-149.9854

Likely sourced from ETOPO1.
@jan-tosovsky-cz Those are over-zoomed bathymetry tiles with poor resolution. Are they critical for your workflow?

@nvkelso thanks for analysis. They are not critical. My aim is to get elevation range for every particular tile. I can average missing values from adjacent ones. I am just trying avoid this tweaking (= additional work). Especially when final processing is planned not before few next weeks.

My latest calculations show that there should be no missing tiles now. I almost can't believe it! Please, please let me know if you do find any, because I'm sure there must be a few hiding away somewhere :wink:

I can confirm there are no missing tiles for zoom 12 (terrarium) any more. Thanks guys!

Great to hear, thanks for checking @jan-tosovsky-cz!


Add support for securityContext

This commit adds an optional value to template out securityContext for
the deployment.

@dmizelle can you bump the chart to a new minor version? Also please document this in the README.md. Thanks!

Any update on this? PodSecurityPolicy has been deprecated and set to be removed in v1.25

Closing in favor of #35 which includes the changes.


Refactor CMake and Make file

Describe your PR, what does it fix/add?

modernize CMake a bit
"unscreamify" CMake commands
add CONFIGURE_DEPENDS to file(GLOB_RECURSE ...), such the CMake configure phase is invoked when new files are added (important for incremental builds)
replace undocumented CMake option -H by -S in Makefile
remove unnecessary "cd" in Makefile
call meson setup <build-dir>, because meson <build-dir> is deprecated

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Let me know if that went too far for the first round of refactoring.
Is it ready for merging, or does it need work?
Ready to merge.

CI failed. Check the logs and adjust to that please :)


Split PlayFab class

To make things more usable and clear, split the PlayFab class, into:

A base class
A class for each top-level API. eg:

Client
Event

Was implemented with #20


Disable copying url after push

Hello! Is any options to disable this feature?

Not currently but would be an easy patch, would be happy to accept a PR. If
you'd need help with that just let us know!
On Fri, Jul 12, 2019 at 6:54 AM Philipp Trubchenko<EMAIL_ADDRESS>wrote:

Hello! Is any options to disable this feature?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jamiew/git-friendly/issues/72?email_source=notifications&email_token=AAAAO3YGUE2VKSGWSCLTR4DP7BPHDA5CNFSM4ICHGJBKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G63HCWA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAAO36D5RIP73ZBMVGF5KDP7BPHDANCNFSM4ICHGJBA
.

--
@jamiew https://twitter.com/jamiew | https://jamiedubs.com
https://www.jamiedubs.com/

Oh, nice! I gonna try

I’ll go ahead and re-open this since it is a valid feature request
If you submit a pull request just mention “closes #72”
Thanks!

How can i push branch to the repo?


Automated Package Upgrade

:tada: This PR is included in version 7.7.333 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Implement initial framework for wamp transports

This commit removes the templatization of the wamp session. This
will allow us to:

Treat transports and sessions as separate entities which allows for:

Reuse of transports across multiple sessions.
Pausing and resuming of sessions.

Implement different types of transports (i.e. websocket).
Implement flow control for transports.
Support native communication with the application router.

Regarding copyright: I'd be fine with replacing the line
// Copyright (c) Tavendo GmbH

with
// Copyright (c) Tavendo GmbH, Topology LP and contributors.

in all existing files, and add the line to all new files.

We haven't added explicit other contributor names to any of the other Autobahn libraries, but I think the amount of code contributed by Topology, and the specific situation here definitely justifies that. (I am cautious, because I want to avoid being asked to do similar for X and Y and Z on all Autobahn's - I wouldn't!).

I agree with @davidchappelle regarding dates (no dates pls), exactly because of the arguments Dave raises. In any case, everything can be traced back to the first commit anyway - and those commits have timestamps.

@jpetso

This is making the entirely reasonable & unquestionable assumption that in 70 or 95 years or however long copyright will be then, autobahn-cpp will be in wide use as a foundational piece of all software.

=)
I totally agree.

Btw: why are messages shuffled around .. got_message(wamp_message&& message)  with double &&?
I can see these types coming from code
wamp_message message(std::move(fields), std::move(*(result.zone())));
got_message(std::move(message));

I still don't get it. And reading this makes my brain hurt;)

A minor thing .. but. I recently took time making sure all the examples run, work with the Crossbar.io config supplied in the examples dir out of the box, and that the READMEs are in sync.
I've skimmed over the patch (that also updates the examples) .. and I think there are some minor issues. I will test the branch using Crossbar.io from that directory. Yes, I understand you (obviously) care more about Bonefish (and that is perfectly fine!), but people come and file issues and ask questions on our mailing lists if AutobahnCpp does not work with Crossbar.io and/or the examples here.

I'll also wait for the copyright changes before merging - if Topology is fine with the proposal above.

The double && allows for ownership of objects to be passed efficiently without having to deal with smart pointers, heap allocations, etc. It took a bit once I moved to c++11 to really see the advantages to r-value references. In the code you posted above, the message is constructed from a set of fields and a zone. The fields and zone only exist for the purposes of constructing the message. To avoid the overhead of copying, heap allocations, etc. we use r-value references. The calls to std::move(...) are effectively zero-cost cast operations. It allows for the r-value versions of the copy and assignment constructors to be invoked where appropriate. This also allows the transports themselves to deal with messages efficiently. For example, when back pressure occurs or when native communication is being used (i.e. autobahn-cpp calling directly into the application router and vice versa).
Hopefully things still just work with crossbar. I think the only sticking point would be the uds example but  I added a new test parameter for specifying the uds path. Maybe I should default to the crossbar default?
I am in agreement with how to do the copyright. I can put together a commit for that once @jpetso confirms.

@davidchappelle thanks for explaining the double & thing. I have filed https://github.com/crossbario/autobahn-cpp/issues/94 as I think this is worth discussing in docs.
Rgd examples:

the examples include https://github.com/crossbario/autobahn-cpp/blob/master/examples/web/index.html, and there URIs there should match the one's used in C++.
As of the UDS path: whatever the default from command line arg parsing should match https://github.com/crossbario/autobahn-cpp/blob/master/examples/.crossbar/config.json#L79 - we can make that more generic though, eg router.sock or whatever.

@davidchappelle pls let me know if you still want this merged, given the different views on "copyright notice" in the headers ..

Yes I am ok with still merging. I am just touching up the example items
that you mentioned above.
On Wed, Feb 17, 2016 at 4:35 PM, Tobias Oberstein<EMAIL_ADDRESS>wrote:

@davidchappelle https://github.com/davidchappelle pls let me know if
you still want this merged, given the different views on "copyright notice"
in the headers ..
—
Reply to this email directly or view it on GitHub
https://github.com/crossbario/autobahn-cpp/pull/93#issuecomment-185416831
.

Ok, cool!! Thanks! Gimme a ping when ready and I'll merge.

Thanks a lot, Dave!

Not a problem. Thanks for all of the collaboration. I think that
autobahn-cpp is now at a stage where many of the newer serialization and
transport features can be easily added.
On Wed, Feb 17, 2016 at 4:58 PM, Tobias Oberstein<EMAIL_ADDRESS>wrote:

Thanks a lot, Dave!
—
Reply to this email directly or view it on GitHub
https://github.com/crossbario/autobahn-cpp/pull/93#issuecomment-185425547
.

Great job @davidchappelle!  Been tracking your wamp_transports branch for a while.


Format code using 'cargo fmt'

Hey @Atul9 thanks for the PR. I'm in the midst of reorganizing the repository in the https://github.com/nickray/littlefs2/tree/closures-instead-of-ub branch, so it doesn't make much sense to merge this into main as of now. The changes there are needed as current main branch is flawed and has undefined behaviour.


fix: Move drupal11 to its own project type, make "drupal" an alias for latest drupal, fixes #6635

The Issue

#6635

In progress.
TODO:

[x] Implement drupal type as alias for drupal11
[x] Make sure ddev config --project-type=drupal works.
[x] Update quickstarts to stop using ddev config --update
[x] Change docs on ddev config --update - should it go away? Just be ddev config --auto ?
[x] Improve docs about the drupal project type and what it means now (alias) and it's previous usage.
[x] Several changes were made to use drupal11 in tests, they may be able to use drupal and be more resilient for future versions.
[x] ddev list and ddev describe should show the configured project type, not the detected project type
[x] ddev config --project-type=drupal should create drupal11 right now
[x] Tests for complex "drupal" handling
[x] With drupal11 codebase, restart ddev config manual. Gets php? then drupal10? may be detection is not working right. May be intermittent.

How This PR Solves The Issue
Manual Testing Instructions

[ ] Test with ddev config --project-type=drupal --docroot=web (should come out drupal, but ddev list and ddev describe will report it as drupal11)
[ ] Test with interactive ddev config
[ ] Test with various project types in config.yaml

Automated Testing Overview

Release/Deployment Notes

One more thing, when I have drupal, and then run ddev config --auto or ddev config --update, it's replaced with drupal11.

This is intentional.

ddev config --update definitely wants to discover the "preferred" type, so it always alters project type when it discovers another project type
ddev config --auto perhaps ought to respect the existing one, but it's a tossup.


Tasks 882-885: Atharva_Barwe

@Rubicon1887 Can you update your tasks based on the comments? Thanks!


Cannot use socket extensions inside async namespace middleware

Describe the bug
Cannot use socket extensions inside async namespace middleware
To Reproduce
Code that reproduce error:
main.rs
use socketioxide::extensions::{Extensions, Ref};
use socketioxide::extract::SocketRef;
use socketioxide::handler::ConnectHandler;
use socketioxide::SocketIo;
use tokio::net::TcpListener;

fn handler(s: SocketRef) {
    println!("socket connected on / namespace with id: {}", s.id);
}

async fn test_async() -> Result<(), reqwest::Error> {
    reqwest::get("https://google.com").await?;
    Ok(())
}

async fn middleware(socket: SocketRef) -> Result<(), socketioxide::SocketError<()>> {
    let ext: &Extensions = &socket.extensions;
    let number: Option<Ref<i32>> = ext.get::<i32>(); // if comment this line
    let _ = test_async().await;                      // or this one, then there will be no compilation error
    Ok(())
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (layer, io) = SocketIo::new_layer();
    io.ns("/", handler.with(middleware));
    let app = axum::Router::new().layer(layer);

    let listener = TcpListener::bind("<IP_ADDRESS>:5002").await.unwrap();

    axum::serve(listener, app).await?;

    Ok(())
}

Cargo.toml
[package]
name = "test"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = { version = "0.7.5" }
socketioxide = { version = "0.12.0", features = ["extensions"] }
reqwest = "0.12.2"

Error:
error[E0277]: the trait bound `fn(SocketRef) -> impl Future<Output = Result<(), SocketError<()>>> {middleware}: ConnectMiddleware<LocalAdapter, _>` is not satisfied
   --> src/bin/test_socket.rs:25:24
    |
25  |     io.ns("/", handler.with(middleware));
    |                        ^^^^ the trait `ConnectMiddleware<LocalAdapter, _>` is not implemented for fn item `fn(SocketRef) -> impl Future<Output = Result<(), SocketError<()>>> {middleware}`
    |
note: required by a bound in `ConnectHandler::{opaque#0}`
   --> /Users/xorbit/.cargo/registry/src/index.crates.io-6f17d22bba15001f/socketioxide-0.12.0/src/handler/connect.rs:239:12
    |
239 |         M: ConnectMiddleware<A, T1> + Send + Sync + 'static,
    |            ^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `ConnectHandler::{opaque#0}`

Expected behavior
The code is being compiled, extensions are working properly
Versions (please complete the following information):

Socketioxide version: 0.12.0
Http lib: axum/0.7.5

Additional context
-

It is because the Ref is not Send. Therefore if you use it across .await points, the returned future will not be Send. It is a requirement for the returned future to be Send so it can be later boxed.
One possible way to solve this might be to completely the Dashmap by a tokio::RwLock<HashMap> so that LockGuard are Send.
Currently the only solution to solve your issue is either to constraint your ref to a limited scope before your .await point:

async fn middleware(socket: SocketRef) -> Result<(), socketioxide::SocketError<()>> {
    {
         let ext: &Extensions = &socket.extensions;
         let number: Option<Ref<i32>> = ext.get::<i32>();
    }
    let _ = test_async().await;
    Ok(())
}

or to clone the content and discard the Ref.

Thanks for the answer, I just tried to use cloning for now, as the objects where not too complicated. But the solution with the limitation of the scope is good one, did not figure out it myself
Are there any plans to add rwlock/mutex to extensions?

Actually, it is global to every handlers (not only middlewares).
The only thing I could do is to provide a Extension extractor that directly get and clone the object like with the Extension extractor from axum. I might also add an HttpExtension extractor that would correspond to the http request extension also.


feat(TwinMakerTools): add tools-iottwinmaker to npm publish workflow

Overview
Add tools-iottwinmaker (tmdt) to app-kit npm publishing workflow.
Legal
This project is available under the Apache 2.0 License.

Just wanted to confirm my understanding of the customer experience:

after this change, there will be an page on https://www.npmjs.com/ for TMDT?
what will the content on that page be?
and I should be able to npm install -g the package and then I have the tmdt executable in my environment?
is there a version number associated with the package? looks like it's 3.0 now? Should it be 1.0? also want to see if we can align the user-agent value before releasing to npm [1] ?
to confirm: after this there's no way to "undo" the release right?

Just wanted to confirm my understanding of the customer experience:
* after this change, there will be an page on https://www.npmjs.com/ for TMDT?

* what will the content on that page be?

* and I should be able to `npm install -g` the package and then I have the `tmdt` executable in my environment?

* is there a version number associated with the package? looks like it's [3.0](https://github.com/awslabs/iot-app-kit/blob/main/packages/tools-iottwinmaker/package.json#L4) now? Should it be 1.0? also want to see if we can align the user-agent value before releasing to npm [[1]](https://github.com/awslabs/iot-app-kit/blob/main/packages/tools-iottwinmaker/src/lib/aws-clients.ts#L20) ?

* to confirm: after this there's no way to "undo" the release right?

I believe there will be a page for tmdt under @iot-app-kit/tools-iottwinmaker. I assume the readme at tmdt's root will be used for the npm package.
Yes, npm install -g from the tools-iottwinmaker root will currently install the tmdt executable globally
The version number in the package.json is left over from our set up, should I change it to 1?
For the user-agent value, I believe we can probably remove the versioning from tmdt definition but I will discuss offline with Johnny.
I do not believe there is a way to "undo" this release.

Thanks Matt

I believe there will be a page for tmdt under @iot-app-kit/tools-iottwinmaker. I assume the readme at tmdt's root will be used for the npm package.

Can we change it to a generic or empty page for now? Looking over it again, the README for the project needs to be cleaned up, am wondering if we can decouple that from first npm release (or if needs to be cleaned up first?)
e.g. it currently refers to the private repo and the sample commands should remove references to our development to avoid confusing customers ("CookieFactory0601" and "SyncB") Also am wondering if the tmdt_local instructions should be part of a developer-only page instead of the landing README.

The version number in the package.json is left over from our set up, should I change it to 1?

Since it's alpha, is it appropriate to use a v0 version number? e.g. 0.1.0?

For the user-agent value, I believe we can probably remove the versioning from tmdt definition but I will discuss offline with Johnny.

Sorry, which versioning definition are you referring to?

we're using the user-agent one for usage tracking
we should keep the version in the tmdt.json file (have we renamed it from tmdk.json?)  for compatibility-tracking
I thought the one in the package.json gets reflected in npm?


Have fixed some errors

these will help others more
NOTE: Please read the CONTRIBUTING.md guidelines before submitting your patch,
and ensure you followed them all:
https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#contributing
Summary
SUMMARY_GOES_HERE
Full changelog

[Implement ...]
[Add related tests]
...

Issues resolved
Fix #XXX

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I double checked, and none of the TOC links are missing. When ommitted, it is intentional. The other changes aren't helping in clarifying the content, sorry. I just pushed https://github.com/Kong/kong/commit/88a530c68e09e0bde74a1904ee908054718f6195 which will help avoiding future contributors getting confused with the exotic styling in this file.
Closing this PR now, thank you for your time on this and trying to improve the project!


Issue with non-privileged OSDs and SElinux

Can not mount the OSD fs, ceph-disk logs:
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: 2017-02-28 13:43:27  /entrypoint.sh: static: does not generate config
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: main_activate: path = /dev/sdb1
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: get_dm_uuid: get_dm_uuid /dev/sdb1 uuid path is /sys/dev/block/8:17/dm/uuid
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: command: Running command: /sbin/blkid -o udev -p /dev/sdb1
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: command: Running command: /sbin/blkid -p -s TYPE -o value -- /dev/sdb1
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: command: Running command: /usr/bin/ceph-conf --cluster=ceph --name=osd. --lookup osd_mount_options_xfs
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: mount: Mounting /dev/sdb1 on /var/lib/ceph/tmp/mnt.rguqya with options noatime,largeio,inode64,swalloc
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: command_check_call: Running command: /bin/mount -t xfs -o noatime,largeio,inode64,swalloc -- /dev/sdb1 /var/lib/ceph/tmp/mnt.rguqya
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: mount: /dev/sdb1 is write-protected, mounting read-only
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: mount: cannot mount /dev/sdb1 read-only
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: Traceback (most recent call last):
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: File "/usr/sbin/ceph-disk", line 9, in <module>
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: load_entry_point('ceph-disk==1.0.0', 'console_scripts', 'ceph-disk')()
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: File "/usr/lib/python2.7/dist-packages/ceph_disk/main.py", line 5230, in run
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: main(sys.argv[1:])
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: File "/usr/lib/python2.7/dist-packages/ceph_disk/main.py", line 5181, in main
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: args.func(args)
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: File "/usr/lib/python2.7/dist-packages/ceph_disk/main.py", line 3532, in main_activate
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: reactivate=args.reactivate,
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: File "/usr/lib/python2.7/dist-packages/ceph_disk/main.py", line 3266, in mount_activate
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: path = mount(dev=dev, fstype=fstype, options=mount_options)
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: File "/usr/lib/python2.7/dist-packages/ceph_disk/main.py", line 1337, in mount
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: raise MountError(e)
Feb 28 13:43:27 docker-centos-osd ceph-osd-run.sh[23738]: ceph_disk.main.MountError: <exception str() failed>

Selinux logs:
time->Tue Feb 28 13:41:45 2017
type=SYSCALL msg=audit(1488289305.045:162836): arch=c000003e syscall=165 success=no exit=-13 a0=ea0240 a1=ea02f0 a2=ea0260 a3=c0ed0400 items=0 ppid=18748 pid=18755 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/bin/mount" subj=system_u:system_r:svirt_lxc_net_t:s0:c590,c721 key=(null)
type=AVC msg=audit(1488289305.045:162836): avc:  denied  { mount } for  pid=18755 comm="mount" name="/" dev="sdd1" ino=32 scontext=system_u:system_r:svirt_lxc_net_t:s0:c590,c721 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem

SElinux:
[root@docker-centos-osd ~]# getenforce
Enforcing

Setting to permissive solves the issue.

Seems to be related to the removal of --pid=host...

@b-ranto any ideas on this selinux issue?

It says that mount was called with svirt_lxc_net_t context which suggests containers did not do/define the appropriate context transition when calling mount.

any updates about how to fix this?

@sjkyspa you can run your container with --pid=host. If you run on k8s you're fine.


Emphasise a current popularity metric instead of total downloads

"Total downloads" seems to be the currently emphasised metric. For example, when I browse to my profile page, the packages are listed in descending order by number of total downloads. The preview tile for each package also shows the number of total downloads.
I propose that number of total downloads is not the most interesting metric, and certainly not the metric which indicates which packages are "hot". The more interesting metric is average downloads per day. I'll explain why. The number of total downloads is heavily influenced by the length of time a package has been on the gallery.
For example, https://www.nuget.org/packages/LiteGuard.Source/ only gets 9 downloads a day, but it's been on the gallery since early 2013, so it currently has around 21K total downloads. On the other hand, https://www.nuget.org/packages/MinVer/1.0.0 currently gets 77 downloads day (more than 8 times as many as LiteGuard.Source) but because it's only been on the gallery since late 2018 (6 months) it only has 15K downloads.
Currently, LiteGuard.Source is sorted above MinVer on my profile page, but it's clearly the less popular package. MinVer is more than 8 times as popular, as proven by its downloads per day.
I propose the following (for all relevant pages in the gallery, not necessarily just profile pages):

Add downloads per day to the package tile and emphasise it. E.g.
Change the descending sort order to be based on avg downloads per day instead of total downloads.

Great idea! Thanks for the suggestion. As far as I can remember right now, the profile page is the only one that is sorted just by simple total download count. Search (which is being improved right now) takes your search term into account as well as downloads and other factors we are considering.
Another way of getting hot packages to stand out is total download count over the past N days.
One question I have is this: as a package CONSUMER do you use the profile page for discovering new packages that you don't know about yet? Or for finding a package ID you forgot? Or something else?
Above you mentioned your own profile page. As a package AUTHOR how do you use your own profile page? I feel like in this scenario (package author on his own page) we may have to guess the sort order.
Perhaps on profile page we just need a drop-down so you can pick the sort order... Needs more input from users perhaps.
In short, it's not clear to me yet how people use the profile page and the right sort order may vary from use case to use case.

One question I have is this: as a package CONSUMER do you use the profile page for discovering new packages that you don't know about yet? Or for finding a package ID you forgot? Or something else?

I use it to see what are the most interesting packages produced by that author/organisation. If package net-hotness has 1,000 downloads a day but has only been on the gallery for one month, I want to see that before package old-dinosaur that's been on the gallery for 5 years but only has 20 downloads a day (currently the old-dinosaur would show before new-hotness).

Above you mentioned your own profile page. As a package AUTHOR how do you use your own profile page? I feel like in this scenario (package author on his own page) we may have to guess the sort order.

I want to use it to see which of packages is most interesting to the community, but currently, it's highly skewed to which packages have been on the gallery the longest. It's effectively the same use case, and the same problem, as when I'm browsing as a CONSUMER of someone else's profile page.

Perhaps on profile page we just need a drop-down so you can pick the sort order... Needs more input from users perhaps.

Yes, that could work.

Another way of getting hot packages to stand out is total download count over the past N days.

I think I prefer avg downloads per day. The number of downloads over the last N days can be erratic, and it an even shorter term metric. The avg downloads per day still take into account the historic value of a package, even if it's popularity is tailing off. Just by taking into account length of time on the gallery, it's already a more interesting metric than an absolute number of downloads.

Perhaps this issue should be split into two?

Add avg downloads per day to package tiles (in all views)\
Sort profile pages by avg downloads per day

Perhaps this issue should be split into two?

Add avg downloads per day to package tiles (in all views)\
Sort profile pages by avg downloads per day

Maybe keep them as one for now.
@anangaur @karann-msft, thoughts?

IMO total downloads doesn’t even make sense. It’s a vanity metric for authors 🙂. From consumers, a recent download metric makes sense like weekly or monthly download count. We can do away with other metrics on the details page and put them into stats, if required

For profile page too we could have monthly/weekly  downloads along with total downloads for the packages. And sort them by monthly downloads descending

To clarify, does "monthly/weekly downloads" mean downloads in the last month/week, or average number of downloads per month/week?

Last one month/week as it reflects the current popularity

OK, but in that case I would propose using month as the primary metric. One week could be too erratic.

OK, but in that case I would propose using month as the primary metric. One week could be too erratic.

Agree 👍

What is the current status of this?

@adamralph , we have added this to our backlog. We will prioritize the work based on the other items we got.

Any movement?

Hi @adamralph, we haven't been able to prioritize this work yet, but we still believe that it's important and will likely improve our search relevancy. I will update this issue we get started on this feature 😊

Is there anything I (or anyone else) can do to help get this prioritised?

Hey @adamralph, apologies on the day in responding here. Generally speaking, this is something we're interested in the potential of. However we haven't had the time to formalize any particular ideas or a proposal. Today our stats pipeline has some scalability issues but we're in the process of modernizing how we ingest download logs and process them into reports. In other words, potential blockers we had in the implementation will soon be going away so I think it's a good time to at least start a conversation about what this change would mean for NuGet.org.

Is there anything I (or anyone else) can do to help get this prioritised?

I'm glad you asked 😃. In the past 6 months or so, we have formalized the proposal process so that changes to NuGet.org or to NuGet client software can be spec'd in the open and we can gather feedback from the community more easily. Would you be interested in creating a proposal spec, per this guide?
https://github.com/NuGet/Home/blob/dev/meta/README.md
Here are some open PRs on NuGet/Home, many of which are other public NuGet proposal (some by the team, some by external contributors like yourself):
https://github.com/NuGet/Home/pulls?q=is%3Aopen+is%3Apr
In short, a great thing you could do to help get this prioritized is to create a proposal of the change in experience that you'd like and we can discuss on the proposal PR.
Some questions to consider for your proposal:

What time window do you think makes sense to calculate the average over?
Should this change only affect the NuGet.org UI? Or should it also affect search ranking? (We have to be careful with search ranking)
What are all of the specific places that need to show this new average? Some places have more visual space than others.
How would this change get plumbed down into the Visual Studio client, if at all? Roughly 90% of the NuGet searches performed against NuGet.org are actually done in the Package Manager UI in VS, but VS changes are hard to land and nearly impossible to revert 😃 (so higher risk).

@joelverhagen thanks very much for the detailed response.
Initially, I was thinking of only a baby step — changing the profile page to default to sorting packages by the number of downloads in the last 6 weeks, with an option to switch back to sorting by total downloads. For example (hacked in with no explicit consideration for styling):

BTW I'm using 6 weeks as an example because the package stats pages are already for 6 weeks, so users are already primed to think of 6 weeks as being current/recent.

@joelverhagen apologies, please disregard that last comment in favour of this one. I got my wires crossed with a different idea. I believe the following is better:
Initially, I was thinking of only a baby step — changing the profile page to default to sorting packages by the average downloads per day, with an option to switch back to sorting by total downloads. For example (hacked in with no explicit consideration for styling):

I like it! One thought is that the (somewhat similar) package search page has a filter expander with more options which feel a bit like your suggested dropdown.

Perhaps we should just extend that experience and add it to the profile page? Just a thought, feel free to take your proposal document any direction you want.
Could you open a proposal PR? It can be relatively small, if you want to scope it to something minimal right now.
Once there's a proposal PR, we can boost the visibility on Twitter and gather broader input from the community. We've found a PR is a better place for these sort of discussions since we can comment on specific parts of your idea more clearly. Also, it's a lot easier for newer people in the community to understand if there's a document that can be read instead of a mega issue comment thread 😅.

/cc: @jcjiang
@adamralph, any reason why you switched the popularity metric?
I think avg. downloads per day may still be skewed to show high number for really old packages that initially had very high downloads but not any more. In that way, I somehow liked the "downloads in last 6 weeks" as it's a better indicator of recent popularity. Thoughts?

@anangaur fair enough, maybe "downloads in last 6 weeks" is indeed better. Or perhaps we can provide both. I'll open the proposal PR ASAP.

FTR this hasn't been important enough for me to dedicate the time to raise the proposal PR and I currently have no intention to do so.


MRS100 wrong open setting after reboot

MRS100 device are set to 50% opening after HomeAssistant restart even if the shutter was completely open or completely closed.
Version
System
Version | core-2022.2.8
Installation type | Home Assistant OS
Home Assistant Supervisor
SO | Home Assistant OS 7.4
Supervisor version | supervisor-2022.01.1
Meross device
MRS100
firmaware version 2.1.4
hardware version 2.0.0
Describe the bug
MRS100 device are set to 50% opening after HomeAssistant restart even if the shutter was completely open or completely closed.
At each restart the shutter opening status is lost and set to 50% again.
In these days when automatic updates bring HomeAssistant to one restart a day, every day the shutters close in half or open in half because they think they are starting from the wrong point.
After each restart the device forgets the status of the rolling shutter and sets it to 50%.
The automations to bring the shutter to 0% then move it to half height, leaving the house open instead of closed.
Same thing by asking to open at 100% with an automation, the shutter will go up by 50% because it thinks it starts from mid-opening.

If I use the up or down arrow buttons manually (in the home assistant device interface) the component respects the total up / down time. If I insert the closing of the shutter in an automation by setting 0% opening, it only moves by 50% of the set time (because it thinks it starts from 50% when in reality it is completely open).
Error log
I don't know if it is useful but looking in the error log I found this (a few hours after the restart which causes the reset of the original position of the shutter).
Questo errore ha avuto origine da un'integrazione personalizzata.
Logger: custom_components.meross_lan
Source: custom_components/meross_lan/helpers.py:23
Integration: Meross LAN (documentation, issues)
First occurred: 17:41:49 (6 occurrences)
Last logged: 17:41:51
MerossDevice(2006096481753790815448e1e91e7501) error in async_http_request: Server disconnected
MerossDevice(2006093320459790815448e1e91e7cb3) error in async_http_request: Server disconnected
MerossDevice(2006090988485790815448e1e91e7c21) error in async_http_request: Server disconnected
MerossDevice(2007165824177090819948e1e92579b4) error in async_http_request: Server disconnected
MerossDevice(2006094896864290815448e1e91e7cb6) error in async_http_request: Server disconnected

Resolution expectation
After the restart, the shutter remembers the status it was in and is set again with that opening percentage.
Marco

Hello @galamarco ,
Yes that is an issue hardly solvable because the mrs100 itself doesn't know it's own position and reports only 0 or 100 (this is at least the 'state of my knowledge' up to a few months ago when I did implement it.
So, in order to provide a nicer HA experience meross_lan overrides the internal device positioning information by calculating its own trajectories based on time of run.
Of course when you restart, the meross_lan doesn't know any reliable starting position and so the 50%. There's no alternative to this since after you restart you cannot be sure someone else didn't move the shutter in between (even if it's a few seconds...). I mean, you could be sure you didn't but meross_lan cannot ;)
I suggest you to use the more dedicated service calls like 'close_cover' and 'open_cover' which should (I cannot try myself) instruct the mrs100 to do a full run whatever the actual position: this way, the calculated state will 'relax' to the correct position 0 or 100 since the run lasts the full timing configured on the shutter.
I could tweak a bit meross_lan in order to do a full run if it knows the state is unknown at the start but that would be anyway a trick with the consequence that the first set_position would behave as a full run independently of the destination position..and that could be confusing even more....(It would work if you set 0 or 100 but what if you set 30 as the first target? We cannot really know where that 30% position lies).
That's why, if it fits you, I suggest to use the open/close cover which could be more appropriate for the intended action in your automations: i.e. do you want to open/close it full?
Nevertheless, I'll see if I can save the meross_lan HA state between restarts, not an ideal solution but maybe better than nothing (and would work if noone moves the shutter in between!)

Thanks for the explanation.
The use of close_cover is a work around but not a solution of forgetting the position problem at each restart, even automatic, that occurs.
It is true that it is not possible to be sure that the button was pressed during the restart, but on the contrary we are sure that the shutters at 50% in a house are a 99% incorrect setting.
Currently it happens that I leave the house and the shutters are brought to 0% but they go down in the middle and do not close the house. I noticed it from the video surveillance otherwise I would have gone on like this for months. Who knows how many people this is happening to and they haven't noticed.
I come home and they are open normally, so you don't notice anything abnormal.
"close_cover" is certainly better, but it is the least userfriendly when creating automation from the interface. It is natural, not knowing this problem, to set the closing to 0% in the automations.
It could be a solution when setting 0% "close_cover" is executed and when setting 100% "open_cover" is executed. This implicitly resets the dubious status and makes sure that the shutter is fully opened or closed completely.
But I don't know if it's feasible.
Of course the 50% position after each reboot is always wrong.
Best regards
Marco Galassi


HW 1 Errors

Hello, the following are errors I have found in your first homework assignment:

The link you have included to the course webpage does not work.
The formatted Thomas Edison quote is missing at the bottom of the page.

Since this is the first assignment, you have the opportunity to earn some points back on these mistakes if you resolve these issues by the start of class on Monday.

Hello, so there is an issue that happened with my website link when I was trying to fix it and now I can't add my webpage course link back, I fixed the Thomas Edison quote, my website link got deleted.

okay I think I have resolved it!! so will I get points added back to my hw if everything is correct??

Yes, I am adding some points back to your grade!


MessageBroker tests are flaky

The multi threading one(s) regularly hang and the build times out. The whole task/thread based implementation of the broker should probably be reviewed.

[x] fix on master https://github.com/RadicalFx/Radical/pull/479
[ ] backport to 1.6.x
[ ] re-enable disabled tests on master: MessageBroker_broadcast_from_multiple_thread_should_not_fail

from the test I made, to solve this issue, you need to add TaskCreationOptions.LongRunning to the following lines:
https://github.com/RadicalFx/Radical/blob/038a9d0ec38c8efb0a96b6ee092209e687944e78/src/Radical/Messaging/MessageBroker.cs#L513-L516
https://github.com/RadicalFx/Radical/blob/038a9d0ec38c8efb0a96b6ee092209e687944e78/src/Radical/Messaging/MessageBroker.cs#L553-L556

Thanks @workgroupengineering, I raised https://github.com/RadicalFx/Radical/pull/479.

Thanks to you, I learned a lot by studying your code.


PVWatts-Battery cannot run grid outages

Describe the bug
All PVWatts Battery configurations produce the error "exec fail(battery): If grid_outage is specified in any time step, crit_load must have length > 0 and values > 0
Simulation battwatts failed :exec fail(battery): If grid_outage is specified in any time step, crit_load must have length > 0 and values > 0" when attempting to specify a grid outage and a critical load. The same specification works with cmod_battery
To Reproduce
Steps to reproduce the behavior:

Open a PVWatts-Battery configuration
Specify a critical load
Specify a grid outage
Run the simulation and see the error

Expected behavior
Either we should remove the UI widgets from PVWatts-Battery, or the grid outage behavior should match the mainline battery configurations.
Operating System and Version

Version 2021.12.02

Decision in SAM meeting 1/11 was to remove the inputs from PVWatts-Battery and steer the users towards the detailed battery model.

Closed in #844