Directory traversal vulnerability

Describe the bug
K3s binary has directory traversal (or path traversal) vulnerability.
To Reproduce

Deploy the K3s environment.
Configure the kubeconfig on another host to access the K3s server.
Access url "https://k3s-server:6443/logs/" through brower from the host.
Step 3 above will prompt you to input the username password, then input these info from the kubeconfig.
Now you can see the directory traversal vulnerability.
In my environment, the path is the directory "/var/log" on the K3s server.

Expected behavior
No directory traversal vulnerability.
It seems not a upstream (k/k) vulnerability, but only exists in K3s.
Screenshots

Additional context
OS version: Fedora 29
K3S version: v0.4.0 (v1.14.1-k3s.4)

The second attack method:

Run kubectl proxy on another host.
curl http://<IP_ADDRESS>:8001/logs/.

This is a feature of upstream Kubernetes. We can disable it somehow I'm sure, but specifically what is the vulnerability? Kubernetes will serve /var/log on the path /log.  I don't like the functionality, but I'm not sure it's actually a security risk.

@warmchang You might not be seeing this issue in upstream because /logs is served by the kubelet, not the api-server (which happen to be the same process in for a single node setup).
https://github.com/kubernetes/kubernetes/blob/5d37d6b9bf75b21aff9cb724ceabc2023e106821/pkg/kubelet/server/server.go#L82

This is a feature of upstream Kubernetes. We can disable it somehow I'm sure, but specifically what is the vulnerability? Kubernetes will serve /var/log on the path /log. I don't like the functionality, but I'm not sure it's actually a security risk.

Kubernetes will serve /var/log on the path /log:
https://github.com/kubernetes/kubernetes/blob/517240750be0a9eaa39035ae81c92f81f7738b20/pkg/routes/logs.go#L34
But this feature does not mean that kubernetes users can view all the files & directories in the node /var/log path.
The administrator user is only for the kubernetes system instead of the node. That's way I think this's a directory traversal vulnerability.
The /var/log path contains not only the kubernetes logs, but also the logs of all sofeware on the node (It's the default log path). These sofeware do not belong to kubernetes and should not be seen by kubernetes user.
I compared Kubernetes, which handles /logs urls differently from k3s, and I will provide detailed information and screenshots later.

@ibuildthecloud In order to reproduce it conveniently, I used the katacoda public environment to show this.

User the same kubernetes version (v1.14.1).
All use single-node-cluster.

Reproducible operation steps (upstream k/k env):

Don't use the minikube version that already exists in katacoda environment
Download the lasted minikube, and deploy specific versions (v1.14.1).

Launch a v1.14.1 single nodecluster

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v1.0.0/minikube-linux-amd64 && chmod +x minikube && mv minikube /usr/local/bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 38.2M  100 38.2M    0     0  33.8M      0  0:00:01  0:00:01 --:--:-- 33.8M
$
$ minikube start --kubernetes-version v1.14.1
o   minikube v1.0.0 on linux (amd64)
$   Downloading Kubernetes v1.14.1 images in the background ...
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
>   Creating none VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
2019/04/25 10:55:32 Unable to read "/root/.docker/config.json": open /root/.docker/config.json: no such file or directory
2019/04/25 10:55:32 No matching credentials were found, falling back on anonymous
-   "minikube" IP address is <IP_ADDRESS>
-   Configuring Docker as the container runtime ...
-   Version of container runtime is 17.06.2-ce
:   Waiting for image downloads to complete ...
-   Preparing Kubernetes environment ...
@   Downloading kubeadm v1.14.1
@   Downloading kubelet v1.14.1
-   Pulling images required by Kubernetes v1.14.1 ...
-   Launching Kubernetes v1.14.1 using kubeadm ...
:   Waiting for pods: apiserver proxy etcd scheduler controller dns
-   Configuring cluster permissions ...
-   Verifying component health .....
>   Configuring local host environment ...
+   kubectl is now configured to use "minikube"
=   Done! Thank you for using minikube!
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:08:12Z", GoVersion:"go1.11.5",Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:02:58Z", GoVersion:"go1.12.1",Compiler:"gc", Platform:"linux/amd64"}
$

Get the auth info.

Run kubeclt cmd with "--v" para, get the auth info

$ kubectl cluster-info
Kubernetes master is running at https://<IP_ADDRESS>:8443
KubeDNS is running at https://<IP_ADDRESS>:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
$
$ kubectl get node --v=8
I0425 11:05:40.566574    6857 loader.go:359] Config loaded from file /root/.kube/config
I0425 11:05:40.567405    6857 loader.go:359] Config loaded from file /root/.kube/config
I0425 11:05:40.573930    6857 loader.go:359] Config loaded from file /root/.kube/config
I0425 11:05:40.583241    6857 loader.go:359] Config loaded from file /root/.kube/config
I0425 11:05:40.584221    6857 round_trippers.go:416] GET https://<IP_ADDRESS>:8443/api/v1/nodes?limit=500
I0425 11:05:40.584402    6857 round_trippers.go:423] Request Headers:
I0425 11:05:40.584583    6857 round_trippers.go:426]     User-Agent: kubectl/v1.13.3 (linux/amd64) kubernetes/721bfa7
I0425 11:05:40.584759    6857 round_trippers.go:426]     Accept: application/json;as=Table;v=v1beta1;g=meta.k8s.io, application/json
I0425 11:05:40.602257    6857 round_trippers.go:441] Response Status: 200 OK in 17 milliseconds
I0425 11:05:40.602318    6857 round_trippers.go:444] Response Headers:
I0425 11:05:40.602335    6857 round_trippers.go:447]     Content-Type: application/json
I0425 11:05:40.602351    6857 round_trippers.go:447]     Content-Length: 3122
I0425 11:05:40.602365    6857 round_trippers.go:447]     Date: Thu, 25 Apr 2019 11:05:40 GMT
I0425 11:05:40.602490    6857 request.go:942] Response Body: {"kind":"Table","apiVersion":"meta.k8s.io/v1beta1","metadata":{"selfLink":"/api/v1/nodes","resourceVersion":"1056"},"columnDefinitions":[{"name":"Name","type":"string","format":"name","description":"Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of anappropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names","priority":0},{"name":"Status","type":"string","format":"","description":"The status of the node","priority":0},{"name":"Roles","type":"string","format":"","description":"The roles of the node","priority":0},{"name":"Age","type":"string","format":"","description":"CreationTimestamp is a timestamp representing theserver time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. I [truncated 2098 chars]
I0425 11:05:40.603848    6857 get.go:563] no kind is registered for the type v1beta1.Table in scheme "k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:29"
NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   9m    v1.14.1
$
$ cat /root/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /root/.minikube/ca.crt
    server: https://<IP_ADDRESS>:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /root/.minikube/client.crt
    client-key: /root/.minikube/client.key
$

curl the url and check the response.

Let's try to curl these urls: /version, /, /logs, /logs/

$ curl -k --cert /root/.minikube/client.crt --key /root/.minikube/client.key https://<IP_ADDRESS>:8443/version{  "major": "1",  "minor": "14",
  "gitVersion": "v1.14.1",  "gitCommit": "b7394102d6ef778017f2ca4046abbaa23b88c290",
  "gitTreeState": "clean",
  "buildDate": "2019-04-08T17:02:58Z",
  "goVersion": "go1.12.1",
  "compiler": "gc",
  "platform": "linux/amd64"
}$
$ curl -k --cert /root/.minikube/client.crt --key /root/.minikube/client.key https://<IP_ADDRESS>:8443{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io",
    "/apis/admissionregistration.k8s.io/v1beta1",
    "/apis/apiextensions.k8s.io",
    "/apis/apiextensions.k8s.io/v1beta1",
    "/apis/apiregistration.k8s.io",
    "/apis/apiregistration.k8s.io/v1",
    "/apis/apiregistration.k8s.io/v1beta1",
    "/apis/apps",
    "/apis/apps/v1",
    "/apis/apps/v1beta1",
    "/apis/apps/v1beta2",
    "/apis/authentication.k8s.io",
    "/apis/authentication.k8s.io/v1",
    "/apis/authentication.k8s.io/v1beta1",
    "/apis/authorization.k8s.io",
    "/apis/authorization.k8s.io/v1",
    "/apis/authorization.k8s.io/v1beta1",
    "/apis/autoscaling",
    "/apis/autoscaling/v1",
    "/apis/autoscaling/v2beta1",
    "/apis/autoscaling/v2beta2",
    "/apis/batch",
    "/apis/batch/v1",
    "/apis/batch/v1beta1",
    "/apis/certificates.k8s.io",
    "/apis/certificates.k8s.io/v1beta1",
    "/apis/coordination.k8s.io",
    "/apis/coordination.k8s.io/v1",
    "/apis/coordination.k8s.io/v1beta1",
    "/apis/events.k8s.io",
    "/apis/events.k8s.io/v1beta1",
    "/apis/extensions",
    "/apis/extensions/v1beta1",
    "/apis/networking.k8s.io",
    "/apis/networking.k8s.io/v1",
    "/apis/networking.k8s.io/v1beta1",
    "/apis/node.k8s.io",
    "/apis/node.k8s.io/v1beta1",
    "/apis/policy",
    "/apis/policy/v1beta1",
    "/apis/rbac.authorization.k8s.io",
    "/apis/rbac.authorization.k8s.io/v1",
    "/apis/rbac.authorization.k8s.io/v1beta1",
    "/apis/scheduling.k8s.io",
    "/apis/scheduling.k8s.io/v1",
    "/apis/scheduling.k8s.io/v1beta1",
    "/apis/storage.k8s.io",
    "/apis/storage.k8s.io/v1",
    "/apis/storage.k8s.io/v1beta1",
    "/healthz",
    "/healthz/autoregister-completion",
    "/healthz/etcd",
    "/healthz/log",
    "/healthz/ping",
    "/healthz/poststarthook/apiservice-openapi-controller",
    "/healthz/poststarthook/apiservice-registration-controller",
    "/healthz/poststarthook/apiservice-status-available-controller",
    "/healthz/poststarthook/bootstrap-controller",
    "/healthz/poststarthook/ca-registration",
    "/healthz/poststarthook/crd-informer-synced",
    "/healthz/poststarthook/generic-apiserver-start-informers",
    "/healthz/poststarthook/kube-apiserver-autoregistration",
    "/healthz/poststarthook/rbac/bootstrap-roles",
    "/healthz/poststarthook/scheduling/bootstrap-system-priority-classes",
    "/healthz/poststarthook/start-apiextensions-controllers",
    "/healthz/poststarthook/start-apiextensions-informers",
    "/healthz/poststarthook/start-kube-aggregator-informers",
    "/healthz/poststarthook/start-kube-apiserver-admission-initializer",
    "/logs",
    "/metrics",
    "/openapi/v2",
    "/version"
  ]
}$
$ curl -k --cert /root/.minikube/client.crt --key /root/.minikube/client.key https://<IP_ADDRESS>:8443/logs
$
$ curl -k --cert /root/.minikube/client.crt --key /root/.minikube/client.key https://<IP_ADDRESS>:8443/logs/

$

The response of /logs & /logs/ from k/k env.

The verbose info.

The /logs/ does not list the host volume info

$ curl -k --cert /root/.minikube/client.crt --key /root/.minikube/client.key https://<IP_ADDRESS>:8443/logs -v
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: minikube (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: O=system:masters,CN=minikube
*        start date: Wed, 24 Apr 2019 10:56:15 GMT
*        expire date: Fri, 24 Apr 2020 10:56:15 GMT
*        issuer: CN=minikubeCA
*        compression: NULL
* ALPN, server accepted to use http/1.1
> GET /logs HTTP/1.1
> Host: <IP_ADDRESS>:8443
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: logs/
< Date: Thu, 25 Apr 2019 11:14:08 GMT
< Content-Length: 0
<
* Connection #0 to host <IP_ADDRESS> left intact
$ curl -k --cert /root/.minikube/client.crt --key /root/.minikube/client.key https://<IP_ADDRESS>:8443/logs/ -v
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: minikube (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: O=system:masters,CN=minikube
*        start date: Wed, 24 Apr 2019 10:56:15 GMT
*        expire date: Fri, 24 Apr 2020 10:56:15 GMT
*        issuer: CN=minikubeCA
*        compression: NULL
* ALPN, server accepted to use http/1.1
> GET /logs/ HTTP/1.1
> Host: <IP_ADDRESS>:8443
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Last-Modified: Tue, 29 Jan 2019 19:36:53 GMT
< Date: Thu, 25 Apr 2019 11:14:12 GMT
< Content-Length: 13
<

* Connection #0 to host <IP_ADDRESS> left intact
$

Check the default log path of the host.

List /var/log/

$ ls /var/log/
alternatives.log  btmp          dpkg.log        installer  pods
apt               containers    faillog         kern.log   syslog
auth.log          dist-upgrade  fontconfig.log  lastlog    unattended-upgrades
bootstrap.log     dmesg         fsck            ntpstats   wtmp
$

Now we can see that upstream kubernetes does not list file and subdirectory details in the /var directory.
Instead, k3s lists them and has further access to them (eg. access the cloud-init-output.log https://github.com/rancher/k3s/issues/387#issuecomment-486075390).

@warmchang Is this because minikube runs the api-server in a docker container that is not on the host and doesn't have access to /var/log?  I still believe the k3s behavior is consistent with upstream kubernetes but haven't tried myself yet.
To be clear, I think we should just drop the /logs path but I want to understand what is actually different from k3s and upstream k8s.  We shouldn't have change anything in this area.

@warmchang Is this because minikube runs the api-server in a docker container that is not on the host and doesn't have access to /var/log? I still believe the k3s behavior is consistent with upstream kubernetes but haven't tried myself yet.

@ibuildthecloud Thank you for reply.
To be precise, the host refers to the carrier where the binary of k3s or kubernetes is located, whether it is a physical machine, VM or a container.
As you said, it is possible that upstream kubernetes has similar behavior, I will continue to verify this.

Log access is enabled by default, but can be disabled completely with --enable-logs=false, and is protected (on the https port) by whatever authorization mode is enabled for the API server. See https://github.com/kubernetes/kubernetes/issues/77182#issuecomment-487393911 for details

Continute discussion in https://github.com/kubernetes/kubernetes/issues/77182#issuecomment-487437725
/close


MPI updates and fixes

This PR fixes some GTest issues, and adds more comprehensive tests for bindings.

Move gtest compilation to the core/test/mpi unit.
Add non-blocking equivalents for the frequently used MPI calls.
Some doc fixes.
Update tests and add tests for all bindings.

TODO:

[ ] Update CI to be more comprehensive.

format!

Sorry, I ended adding a few more wrapper functions I needed, namely MPI_'Get'Accumulate and MPI_Fetch_and_op operations. Maybe @Slaedr and @MarcelKoch can have another look if everything is right with the CI.


mysql: 8.0.29 -> 8.0.30

Description of changes
Update mysql to 8.0.30: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 185535 run on x86_64-linux 1

2 packages built:

libmysqlconnectorcpp
mysql80


New guides

Opening this PR for detailed review of the updated guides.
For general feedback please go to the forum thread.

Thanks for the review @frangio! I'll update the guides to address the remaining suggestions.

I've updated the guides with all of your comments, please take a look!

I can't approve the PR because I opened it myself, but LGTM!

I've created a branch docs-v2.x and set up Netlify to publish that branch. We should cherry-pick these changes, along with anything we want to see published now, into that branch.


[terra-form-select] Prevent special characters from being added

Feature Request
Description
Prevent special characters from being entered into the form-select control.
Additional Context / Screenshots

@ Mentions

This is likely a duplicate of https://github.com/cerner/terra-core/issues/2208


Too much information or not?

Hi,
I just noticed that when you search people from sidebar, meteor.js responding with too much data.
I can't use this information because the data that leaks is encrypted. But I guess 'probably' there is no active filter for this search and ( hypothetically ) if someone add 3rd party logins ( like Twitter,Github etc.) it'll include the user's tokens too.
Can you guys check this out, is it the expected behavior ?

It seems to be a bug with the easy-search feature (https://github.com/matteodem/meteor-easy-search/issues/126), I have disabled this functionality while this get resolved. Thank you for the bug report.
cc @yasaricli who implemented this feature.

Thanks, I hope you guys figure it out easily :)

I fixed the bug and re-enabled the search feature in http://git.libreboard.com/libreboard/libreboard/commit/b7daaafec6a81b7e512991e757b6438b32ed6187
Thank you very much for this security report.


Test feedback

This is feedback on the get help topic.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4e853a70-3794-7f23-2dba-da09abf822e0
Version Independent ID: d3dc0161-e075-df4d-d82c-a8f87c58da89
Content: Get help in Microsoft Teams
Content Source: Teams/get-help-in-microsoft-teams.md
Service: msteams
GitHub Login: @LolaJacobsen
Microsoft Alias: lolaj

response


BUG: behind the current version

Sealos Version
4.2.0
How to reproduce the bug?
sealos run labring/kubernetes:v1.25.10-4.2.0 -f
What is the expected behavior?
install success
What do you see instead?
2023-06-09T11:30:06 info new cluster version v1.25.10 behind the current version v1.25.8
Operating environment
- Sealos version:
- Docker version:
- Kubernetes version: 1.25.8
- Operating system:
- Runtime environment:
- Cluster size:
- Additional information:

Additional information
No response

https://github.com/labring/sealos/blob/502bee1437d919cbf64b974556cac2fc17990a76/pkg/utils/versionutil/version.go#L51

I wanted to fix this


Add support for using cookies

Add support for setting cookies in Request object and retrieve cookie to a string in Response object.

@nategood Apologies for reopening a two years old thread, I was wondering if you would have an example of how to use an keep cookies for a connection. I have the misfortune of having to connect to a service that doesn't implement REST properly, and the only way to make it work is to authenticate like a user would do (POST request), keep the cookies that the authentication generates and send them again with each subsequent request. It seems simple, but for some reason I can't make it work.
Thanks in advance for your help.

Sorry to keep this open, but this is really easy to do with HTTPful. I don't think it should be in the library because it's against RESTFULL principles (should be stateless).
We do it like this (by using the addOnCurlOption method):
    return Request::{$method}($this->url.$url)
        // it's not a restful api, really..
        // it violates the stateless constraint
        ->addOnCurlOption(CURLOPT_COOKIEJAR, $cookieFile)
        ->addOnCurlOption(CURLOPT_COOKIEFILE, $cookieFile)
        ->sendsJson()
        ->authenticateWith($this->username, $this->password);


[bug] PyTorch Benchmark running but not Datago

Hello,
I greatly appreciate the awesome work you are doing on Datago.
When testing the python/benchmark_filesystem.py script, the PyTorch benchmark runs fine but not the Datago one.
AssertionError: No image - benchmark did not run

│    59 │   # Save the last image as a test                                                                                │
│ ❱  60 │   assert img is not None, "No image - benchmark did not run"                                                                                │
│    61 │   img.save("benchmark_last_image.png")

Benchmarking torch dataloader

Example printed batch:
[(<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D88C10>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F26984F5E90>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D2F790>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D8FA50>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D8FE50>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D98250>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D98610>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D98A10>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D98E10>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D592D0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D59650>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D99950>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D51DD0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D52150>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D5A4D0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D8A890>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D9AB90>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D9AED0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D53350>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D9B650>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D9BA10>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D53E90>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695CEC1D0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695CEC5D0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F26984ECA90>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D64E50>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695CED150>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695CED510>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F26984F59D0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D2DD90>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D2E1D0>, 0), (<PIL.Image.Image image mode=RGB size=512x512 at 0x7F2695D8E5D0>, 0)]

Torch FPS 14.06

Folder structure is nvme_data/test_folder/images.
Datago is installed through pypi: https://pypi.org/project/datago/
Python version is 3.11.10.
OS is Ubuntu 22.04.
Thank you,
Enrico

Hey, thanks for the feedback, having a look !

ok, it's because of this PR @conceptofmind, I forgot to update the example and didn't catch it in the code, rank and world size and not initialized in that case and all samples are skipped. Fixing this

pushing a new package which catches undefined rank and world_size, but previous package would work still with the updated benchmark code

@blefaudeux,
Thank you for the immediate response and fix.
I will open a new issue regarding the benchmark.


Update Eslint configuration to enforce error for unused vars rule

Signed-off-by: Shubham Sharma<EMAIL_ADDRESS>Description
Per #195, we were looking to enforce eslint, but it already configures each rule as "error" by default. The only rule we were throwing warning for was "@typescript-eslint/no-unused-vars" and this PR changes that. Now, it errors out like this:

Issue reference
Please reference the issue this PR will close: #195
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[X] Code compiles correctly
(NA) Created/updated tests
(NA) Extended the documentation

Merged


app_encryption_key length errors with valid length strings

Bug Description
When setting the app_encryption_key with FjeislajjeiOJFjfeajsejieajfIFjew I get the error APP_ENCRYPTION_KEY value must be exactly 32 characters long (type=value_error).
I am thinking the problem is probably here. I think the encoded length different for the original length.
Steps to Reproduce

Add - FIDESOPS__SECURITY__APP_ENCRYPTION_KEY="FjeislajjeiOJFjfeajsejieajfIFjew" as an environment variable in the docker-compose file.
Run docker-compose up

Expected behavior
No error
Screenshots
If applicable, add screenshots to help explain your problem.
Environment

Version: 3.1.4
OS:
Python Version: 3.9
Docker Version: 20.10.17, build 100c701

Additional context
Add any other context about the problem here.

I have written a test for this and the test passes so it seems like the error is happening somewhere else. Leaving this open for now until we can verify where the issue is coming from.
def test_config_app_encryption_key() -> None:
    app_encryption_key = "FjeislajjeiOJFjfeajsejieajfIFjew"
    with patch.dict(
        os.environ,
        {
            "FIDES__SECURITY__APP_ENCRYPTION_KEY": app_encryption_key,
        },
        clear=True,
    ):
        config = get_config()
        assert config.security.app_encryption_key == app_encryption_key

The problem was the quotes, the are included with the string bring the count to 34. Change it to - FIDESOPS__SECURITY__APP_ENCRYPTION_KEY=FjeislajjeiOJFjfeajsejieajfIFjew and it works.


multiple improvements related to prefix logic

pass strip_after_prefix to constructor to avoid it being overriden
simplier case insensitive regex check for prefix
replace logic with ambigous order of await/or
small import changes because yes

self.cached_users = {} is removed because it's unused in both main bot and discord.py bot base

thx


Little questions and answers

If there are less than  5 questions, the 'more answered questions' button will not be present.
If there are less than 3 answers for a question, the 'more Answers' button will not be present.

@finchzebra @saraschaeffer This one too :)

I'll take this one too

@saraschaeffer Thanks for the suggestion!


fix(package.json): pin enhanced-resolve

What kind of change does this PR introduce?
Angular 2 apps don't compile in AoT.
See angular-cli#7113 and webpack/enhanced-resolve#98 for context.
Did you add tests for your changes?
Not required
Summary
Angular 2 app doesn't build in AoT mode.
Module not found: Error: Can't resolve './$$_gendir/app/app.module.ngfactory'
 @ ./src/main.ts 5:0-74
 @ multi ./src/main.ts

Does this PR introduce a breaking change?
Previous versions of Webpack 2.x.x will fail compilation using AoT
Other information
See angular-cli#7113 and webpack/enhanced-resolve#98 for context.

I just signed your CLA. Thank you for the quick action

I don't think those Travis failing tests are related to my commit.
Can you please let me know if you can manage to trigger a patch release containing this fix anytime soon.
Thank you.

This is not a problem this webpack/enhanced-resolve. The AOT Compiler accesses private properties of the Resolver's filesystem, which is not allowed.
See this code: https://github.com/angular/angular-cli/blob/master/packages/%40ngtools/webpack/src/compiler_host.ts#L156-L178

A: The code assumes this is a CachedInputFileSystem, but technically any plugin is allowed to plug-in another filesystem, or decorate this. But this is not yet a problem for this current issue.
B: The code accesses private implementation details of the CachedInputFileSystem (as noted with an _). The CachedInputFileSystem is free to change this anytime, by renaming properties etc.
This happend in 3.4.0 where the data property of the Storage class changed from object to Map. This is a change not visible on API surface so it was released as minor change. This was ok for enhanced-resolve. The hacky access to internal objects from angular-cli is not ok.
For the stuff angular-cli want to do there is a good way to implement it, which don't need hacks. But in general when hacks are needed the implementor of these hacks should pin the dependency to be sure assumptions about implementation details doesn't change.
Anyway I'm not going to merge this.

thanks for the explanation


Add neuroSMT feature in calculation of reward

SAT-1641
We need to add new feature for executionState that estimate time of SMT request, then do experiment: train models and compare coverage on test project (guava-26.0).

This is an unfinished part of the Maxim Petukhov and other research, unfortunately there is no open addition information to add here


Update all dependencies, and fix lint issues

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (682021e) 100.00% compared to head (4157682) 100.00%.

:exclamation: Current head 4157682 differs from pull request most recent head 8daa8f4. Consider uploading reports for the commit 8daa8f4 to get more accurate results

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #24   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           16        16
  Lines         3116      3136   +20
  Branches       539       539
=========================================
+ Hits          3116      3136   +20

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Remove Nth node from end of the linked list

Description
Head of the linked list will be given, our program will remove nth node from end of the linked list and display the list.
I am a contributor in gssoc'22. Please assign this to me
I will provide optimal code with description, time and space complexity and comments plus test cases.
Domain
Data Structure
Type of Contribution
Addition
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

please have look at this @iamgunjan

Please, Can you assign this to me @Lakhankumawat


Guardian render issue again on 1.10.2 running spigot 1.8

Guardian render issue again on 1.10.2 running spigot 1.8

It would be nice if you filled in the issue template perhaps providing screenshots, unfortunately, I am not psychic so I don't really know what happens and what should happen.

@MylesIsCool maybe is related to my ticket #660

If you have this issue consider asking for reopen with info so we actually know what's wrong.


cant send push notifications to web via SDK

Operating System version: macOS monterey 12.6
Firebase SDK version: 4.8.0
Library version: v4
Firebase Product: messaging

When using the firebase SDK, push notifications that target devices on my web app are not received. Using the same information, I can successfully trigger push notifications to my web app from the google console.
Steps to reproduce:
FIrst you would need to setup a client to receive messages: https://firebase.google.com/docs/cloud-messaging/js/client
Add firebase to your server following these steps: https://firebase.google.com/docs/admin/setup
Make sure you are properly authenticated: https://firebase.google.com/docs/cloud-messaging/auth-server
Finally, follow these steps to send a message: https://firebase.google.com/docs/cloud-messaging/send-message
Relevant Code:
func NewServer(db *sqlx.DB) *Service {
    var app *firebase.App
    ctx := context.Background()
    cfg := map[string]string{
	"type": "service_account",
	"project_id": "kalos-services-push",
	"private_key_id": "<A PRIVATE KEY ID>",
	"private_key": "<A PRIVATE KEY>",
	"client_email"<EMAIL_ADDRESS>	"client_id": "<CLIENT_ID>",
	"auth_uri": "https://accounts.google.com/o/oauth2/auth",
	"token_uri": "https://oauth2.googleapis.com/token",
	"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
	"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/kalos-services-push-new%40kalos-services-push.iam.gserviceaccount.com",
    }
    jsonBytes, err := json.Marshal(cfg)
    checkError(err)

    app, err = firebase.NewApp(
        ctx,
	&firebase.Config{
	    ProjectID: "kalos-services-push",
	    DatabaseURL: "https://kalos-services-push.firebaseio.com",
	},
	option.WithCredentialsJSON(jsonBytes),
    )
    msg, err := app.Messaging(ctx)
    checkError(err)
    res, err := msg.Send(ctx, &messaging.Message{
	Notification: &messaging.Notification{Title: "a test title", Body: "a test body"},
	Token: "fkvEZ9vvDfWevtv2yAUw8F:APA91bHa_K_t99_OVn4u4J0uchwxjEtxRhBKtB6enBdrlSPZuHUTRC6gPYrsWKv9hUiXJQBblyhhKCAnOBwiAR3eOH_t7XjewRco8mUW0e4HJSwes0vGGm-h1URHbb-hAsUgkdKO6HZK",
    }
    log.Println("res: ", res) // "projects/kalos-services-push/messages/be6f7922-32ec-42e0-8ecd-9640adeef062"
    log.Println("err: ", err) // always nil
}

The result of the call is always projects/kalos-services-push/messages/be6f7922-32ec-42e0-8ecd-9640adeef062. When I use the exact same FCM registration token via the firebase console, the notification is delivered successfully. What did I miss?

here is my service worker:
importScripts(
  'https://www.gstatic.com/firebasejs/9.0.0/firebase-app-compat.js',
);
importScripts(
  'https://www.gstatic.com/firebasejs/9.0.0/firebase-messaging-compat.js',
);

// Initialize the Firebase app in the service worker by passing the generated config
var firebaseConfig = {
  apiKey: 'AIzaSyD8WgmLl0p3B-GWmLkQpyYw_Xpg4B54Fyc',
  authDomain: 'kalos-services-push.firebaseapp.com',
  databaseURL: 'https://kalos-services-push.firebaseio.com',
  projectId: 'kalos-services-push',
  storageBucket: 'kalos-services-push.appspot.com',
  messagingSenderId: '493739388494',
  appId: '1:493739388494:web:a89c4a4ab2d05131381d1f',
};

var app = firebase.initializeApp(firebaseConfig);
var messaging = firebase.messaging(app);

messaging.onBackgroundMessage(function (payload) {
  console.log('Received background message ', payload);

  const notificationTitle = payload.notification.title;
  const notificationOptions = {
    body: payload.notification.body,
  };
  self.registration
    .showNotification(notificationTitle, notificationOptions)
    .then(res => {
      console.log(res);
    })
    .catch(err => {
      console.error(err);
    });
});

and here is the initialization of firebase in my webapp:
const firebaseConfig = {
  apiKey: 'AIzaSyD8WgmLl0p3B-GWmLkQpyYw_Xpg4B54Fyc',
  authDomain: 'kalos-services-push.firebaseapp.com',
  databaseURL: 'https://kalos-services-push.firebaseio.com',
  projectId: 'kalos-services-push',
  storageBucket: 'kalos-services-push.appspot.com',
  messagingSenderId: '493739388494',
  appId: '1:493739388494:web:a89c4a4ab2d05131381d1f',
};

const registration = await registerServiceWorker(
  'app/assets/js/firebase-messaging-sw.js',
);

const app = initializeApp(firebaseConfig);
const messaging = getMessaging(app);

onMessage(messaging, payload => {
  console.log('recieved message: ', payload);
});

Hi @rmilejcz do you get any errors from the messaging API?
Hey @chong-shao any thoughts on what could be wrong here? Thanks!

Hi thanks for your response, I do not receive any error, the return for the error is always nil. Also unfortunately I have tested with chrome, firefox, and safari, and I am unable to receive web push on any of them.

Hi I was able to solve the issue by using specifying some Webpush properties, specifically TTL and Urgency:
&messaging.Message{
    Notification: &messaging.Notification{Title: "title", Body: "body"},
    Token: "FCM TOKEN",
    Webpush: &messaging.WebpushConfig{
        Headers: map[string]string{"Urgency":"high", "TTL": "4500"},
},

Thank you so much for your time, I hope this helps someone in the future.


Nvidia graphic card does not start everytime, nvidia-smi errors out.

Describe the bug
I expect nvidia-smi to give graphic card started everytime, but it gives error.
nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

This is likely happening because adding nvidia-drm.fbdev=0 to grub configuration. It was done because of https://forums.developer.nvidia.com/t/545-29-02-fbdev-1-cause-nvidia-drm-flip-event-timeout-on-boot-errors/272829/4.
If I had not added the grub change, the linux freezes right after login and all you can do is to move back to lockscreen after it timesout, or force restart it.
So basically, it's happening because of a issue in nvidia driver, there's a patch related to it on the thread itself.
What did you expect to happen?
Work as expected.
Output of rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest
                   Digest: sha256:cf844b210be42ddfcbea8ae3cbaddde93e515640bb6e3dcbf2dd31f84abb18e3
                  Version: 39.20240303.0 (2024-03-04T00:06:13Z)
          LayeredPackages: 'gcc-c++'

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest
                   Digest: sha256:4326db86d1f02c7da36c4f8e85aa5f9ff072cfce4e12d1da373e0f129d4a276c
                  Version: 39.20240302.0 (2024-03-02T16:52:56Z)
          LayeredPackages: 'gcc-c++'
            LocalPackages: warp-terminal-v0.2<IP_ADDRESS>.01.stable_03-1.x86_64

Extra information or context
More links -
https://forums.developer.nvidia.com/t/545-29-06-18-1-flip-event-timeout-error-on-startup-shutdown-and-sometimes-suspend-wayland-unusable/274788
https://www.google.com/search?q=nvidia+drm+flip+event+timeout

OS: Fedora Linux 39.20240303.0 (Bluefin) x86_64
Host: TGL QX60_TLS
Kernel: 6.7.6-200.fc39.x86_64
Uptime: 19 mins
Packages: 2026 (rpm), 10 (brew), 219 (nix-user), 52 (nix-default), 70 (flatpak)
Shell: zsh 5.9
Resolution: 1920x1080, 2560x1440, 2560x1440, 2560x1440
DE: GNOME 45.4 (Wayland)
Theme: Yaru-blue [GTK2/3]
Icons: Yaru-blue [GTK2/3]
Terminal: ptyxis-agent
CPU: 11th Gen Intel i7-11800H (16) @ 4.600GHz
GPU: Intel TigerLake-H GT1 [UHD Graphics]
GPU: NVIDIA GeForce RTX 3060 Mobile / Max-Q
Memory: 5482MiB / 39884MiB

Fixed a bug that caused “Flip event timeout” messages to be printed to the system log when displays are hotplugged when nvidia-drm is loaded with the fbdev=1 kernel module parameter.

https://www.gamingonlinux.com/2024/02/nvidia-550-54-14-driver-released-as-stable/
Apparently it might be fixed in latest version, will try to reboot and check the nvidia driver version etc.

Update -> removed fbdev.0 from the grub, the nvidia-smi is still causing problems and giving same error.

nvidia-smi
Tue Mar  5 10:42:10 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3060 ...    Off |   00000000:01:00.0  On |                  N/A |
| N/A   40C    P8             13W /   80W |      69MiB /   6144MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A     10255      G   /usr/bin/gnome-shell                            2MiB |
+-----------------------------------------------------------------------------------------+

Now the card is back, but will be gone again next reboot/shutdown randomly.


compress hmmer output

Hi! Thanks for the amazing tool! I was wondering, is it possible for you to add an option --tar such as BUSCO has for compressing the hmmer output into a tarball? It would be easier to handle the output directory this way.

Thank you for the suggestion! Too many output files may cause IO problem. I will add the feature.


Clarified how to run container from make quick-release

Added clarification on how to run build output to README.md

/ok-to-test

@xtophs I would suggest rebasing on latest code and then trigger the test again.

/retest

@irfanurrehman  : rebased

/lgtm


Post release automated changes for notificationhubs releases

Post release automated changes for azure-notification-hubs

API change check
API changes are not detected in this pull request.


Response for list api calls does not include the meta field

Paystack now returns a meta field with every list call.  Can that be included in the returned response?

Hi @Josiah-J ! it should still work the same. The Response object returned from calling any of the client methods is a named tuple. Here's a link to the documentation https://gray-adeyi.github.io/pypaystack2 you can also try out CLI https://pypi.org/project/paystack-cli/
Please let me know if you encounter any bugs

Oh I see now! @Josiah-J the current implementation won't capture that because it's not included as part data property. It would be included in the next release of this project. Does it really affect what you're working on or you have a workaround you can use in the meantime?

Hi @Josiah-J this feature has been added to v2.1.0. Happy coding 😎


tree of local resolvers in client and server mixed queries

In the pupstagram demo, isLiked resolver in Images is executed. But it parents resolvers i.e images and dog are not executed
I made a fork of pupstagram to demostrate this
https://codesandbox.io/s/q4kz4v985q
Should we support resolver execution of entire tree starting from query similar to server ?
One drawback of executing only leaf resolvers is that it won't have access to variables of parent fields
const GET_DOG = gql`
  query getDogByBreed($breed: String!) {
    dog(breed: $breed) {
      images {
        url
        id
        isLiked @client
      }
    }
  }
`;

In this case, variables passed to isLiked resolver is null and it didn't have access to breed variable

As I understand i, if you want to access the variables, you should specifically pass them in:
const GET_DOG = gql`
  query getDogByBreed($breed: String!) {
    dog(breed: $breed) {
      images {
        url
        id
        isLiked(breed: $breed) @client
      }
    }
  }
`;

It's perhaps suboptimal, but that's how I understand how it should work today.

This behavior is consistent with what happens on the server. If you look at this launchpad, click on Logs, and run the query, you'll notice that the images resolver doesn't get the arguments passed to the dog resolver. If you want to access those arguments, you'll have to pass them yourself like in @fbartho's example.


Upgrade from 0.0.3 to 2.0.3

Describe the bug
When I try to upgrade the Usercentric package, I am getting following error. Any idea?
`> Task :usercentrics_react-native-sdk:compileDebugKotlin FAILED
ReactNativeFirebase WARNING: NPM package '@react-native-firebase/crashlytics' depends on '@react-native-firebase/app' v9.0.0 but found v8.4.7, this might cause build issues or runtime crashes.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.2/userguide/command_line_interface.html#sec:command_line_warnings
783 actionable tasks: 724 executed, 59 up-to-date
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note:/node_modules/expo-constants/android/src/main/java/expo/modules/constants/ConstantsService.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/expo-file-system/android/src/main/java/expo/modules/filesystem/FileSystemModule.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/expo-file-system/android/src/main/java/expo/modules/filesystem/FileSystemModule.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: /node_modules/lottie-react-native/src/android/src/main/java/com/airbnb/android/react/lottie/LottieAnimationViewManager.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/lottie-react-native/src/android/src/main/java/com/airbnb/android/react/lottie/LottieAnimationViewManager.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note<EMAIL_ADDRESS>uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note<EMAIL_ADDRESS>uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note<EMAIL_ADDRESS>uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note<EMAIL_ADDRESS>uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note<EMAIL_ADDRESS>uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note<EMAIL_ADDRESS>uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: /node_modules/react-native-keychain/android/src/main/java/com/oblador/keychain/cipherStorage/CipherStorageKeystoreRsaEcb.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/react-native-localize/android/src/main/java/com/reactcommunity/rnlocalize/RNLocalizeModule.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/react-native-otp-verify/android/src/main/java/com/faizal/OtpVerify/AppSignatureHelper.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/react-native-reanimated/android/src/main/java/com/swmansion/reanimated/NodesManager.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/react-native-reanimated/android/src/main/java/com/swmansion/reanimated/NodesManager.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: /node_modules/react-native-safe-area-context/android/src/main/java/com/th3rdwave/safeareacontext/SafeAreaUtils.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: /node_modules/react-native-share/android/src/main/java/cl/json/RNSharePathUtil.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /node_modules/react-native-webview/android/src/main/java/com/reactnativecommunity/webview/RNCWebViewManager.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note<EMAIL_ADDRESS>uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: /node_modules/unimodules-app-loader/android/src/main/java/org/unimodules/apploader/AppLoaderProvider.java uses unchecked or unsafe operations.

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':usercentrics_react-native-sdk:compileDebugKotlin'.

Compilation error. See log for more details
`

Maybe this is from your firebase version? See first lines in your log. I am using @react-native-firebase/* in v14.1.0.

I also already use 2.0.4-rc1 of the uc package, as there where problems with the ios Pods. Maybe you can try to upgrade too. See #20

Problem is installing app on android. iOS works fine. And yes it has to do something with firebase but I don’t understand.

So maybe try to use the newest stable from firebase in package.json? Or do you already tried that?

We upgraded to 14.2.1 and still face the same issue
    "@react-native-firebase/analytics": "^14.2.1",     "@react-native-firebase/app": "^14.2.1",     "@react-native-firebase/crashlytics": "^14.2.1",
and still see the issue

What went wrong:
Execution failed for task ':usercentrics_react-native-sdk:compileDebugKotlin'.
Compilation error. See log for more details

complete log
Task :usercentrics_react-native-sdk:compileDebugKotlin FAILED

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.2/userguide/command_line_interface.html#sec:command_line_warnings
783 actionable tasks: 724 executed, 59 up-to-date
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Note: node_modules/unimodules-app-loader/android/src/main/java/org/unimodules/apploader/AppLoaderProvider.java uses unchecked or unsafe operations.

FAILURE: Build failed with an exception.

Hello @adeem, can you confirm the react and react-native version that you are using in your project?

"react": "16.13.1",
"react-native": "0.63.4",
@uc-pedro above I list down the react and react-native version used inside the app.

Can you try to update to
"react": "^17.0.2",
"react-native": "^0.65.1" and check if the issue persists?

worked by upgrading react native version. Can you please mentioned this in "readme" file?

@adeem yeah, I'll do that as soon as possible, thank you!


Code Issue

Hi，Layne-Huang
Thank you very much for your work, but while reading the code, at line 155 of the utils/protein_ligand.py file, the code reads as follows,
def to_dict_atom_cutoff(self, ligand_pos, cutoff):
and I would like to know why your code sets cutoff to 8 here, is this a priori knowledge?

It is set to get a smaller protein pocket which make it calculate more efficiently. You can also try other threshold like 10A or 20A.


Namespace in module header

closes #365
📑 Description
Namespace: is added in the Module Header before the  module.namespace for users to understand what the module.namespace actually is
✅ Checks

[x] I have performed a self-review of my code

ℹ Additional context
Here is a screenshot of the changes

Sorry my bad I did switch to a new branch but I do not know why are the commits to the other branch also got committed here


WinRM Basic auth is Required but it's not listed.

This page is misleading.
Basic Authentication - which I'll remind you, is a security risk as per Microsoft's own blogs - via WinRM is usually disabled in an enterprise environment.
Microsoft has also recommended disabling Basic Authentication at the Exchange Level.
The EXOv2 module listed on this page should represent that with WinRM Basic Authentication disabled, only 9 commands are available.
The assumption, reading this page, is that keeping up with modern security practices will still grant you full access to all Exchange Commands however, this is definitely not the case.
At the very least, the section "How do you know this worked" should include that WinRM with Basic Authentication is required.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 39fbe5a2-c138-b566-c094-82ffc3d1b734
Version Independent ID: 4d69ee5d-5a6d-a203-69fe-bf5441a8b5eb
Content: Connect to Exchange Online PowerShell
Content Source: exchange/docs-conceptual/connect-to-exchange-online-powershell.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

+100 what are the options here, i can see that AccessTokens doesnt work and the older SkypeForBusiness module is no longer available. 😮

@jdelforno, @pkbullock, the first bullet in the "What do you need to know before you begin?" section says:

The requirements for installing and using the EXO V2 module are described in Install and maintain the EXO V2 module.

That topic goes into detail about why Basic auth in WinRM is required in the Prerequisites section:

WinRM needs to allow Basic authentication (it's enabled by default). We don't send the username and password combination, but the Basic authentication header is required to send the session's OAuth token, since the client-side WinRM implementation has no support for OAuth.

The connection topic is a balance between those trying to connect for the first time and those who connect often. Prior to the existence of the EXO V2 Module, all of the prerequisite information was in the Connection topic, but it seemed cleaner and less cluttered to have it in main EXO V2 Module topic.
If you want to attempt to eliminate the Basic auth in WinRM requirement, I would suggest opening a support case.
From what I understand, the fundamental problem of client-side WinRM not supporting OAuth is a problem in both PowerShell 5.x and 7.x.

@jdelforno Hope this comment is helpful for you. Considering the nature of the issue, as advised, please open a service ticket in your tenant and follow with them for the resolution. We proceed to close it as here we are limited to documentation fixes and improvements only.
We will be very happy if you can share the outcome or resolution with us if you see documentation update is required. We will certainly update this documentation with that valuable information. Thanks again, for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Permission issue after starting VS

VSCode Version: 1.41.1
OS Version: macOS Catalina 10.15.2

Steps to Reproduce:

Installed VSCode
"Open anyway"
Permission error

Does this issue occur when all extensions are disabled?: Yes/No

/duplicate https://github.com/microsoft/vscode/issues/74782


Delete new theme after install

Installed a new custom theme based on N1-theme-starter and now N1 won't launch. Tried to dig around in the package contents but can't find the custom theme to delete. Also tried deleting N1 and reinstalling, no success.
Any help on how to remove a custom theme after installing much appreciated

It's in ~/.nylas/packages!


[Frontend] Don't ask to report bugs for scripts failures

A script crash.swift failing on an assert such as:
assert(false)

Leads to a full stacktrace starting with a request to file a bug to swift.org:
% swift crash.swift
crash/crash.swift:1: Assertion failed
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
...

Let's remove the "Please submit a bug report..." line in immediate mode and keep the stacktrace as it has useful information, even if likely too much for the need of the script developer. Note that this will apply to failures in both client code and in the compiler.
rdar://81233463

cc @lhames This is casting a wide net, differentiating compiler and script-side failures could be an interesting improvement in future JIT work.


Add Test pass for build artifacts

Feature Request
With github actions producing wheels to deliver to pypi, it would be helpful to have a separate part of our build process to validate those exact artifacts before they can become candidates for pypi delivery.
Description
At a minimum, smoke tests could be run that did something simple like:

Import otio
create an example timeline
write it to disk
read the timeline back into disk

The testing should be run on target platforms called out as supported.
In a perfect world, the full unittest suite would be run against the wheels that are being delivered.
The main objective of this testing should be to catch packaging issues like:

Not building statically linked to libopentimelineio or libopentime or missing .so files for those in the package (whatever the chosen method of including those functions is)
Incorrect architecture mismatch in the binary parts of the distribution
Missing _otio module from the package distribution

Context
Over the course of improving our build system setup, the above listed issues have been hallmark things that pop up when iterating on our somewhat brittle combo of cmake configs and setup.py. A sanity check that this class of issues hasn't made it into our artifacts will help catch issues close to where they are introduced and increase our confidence when iterating on the build setup.
Some things to consider:

In testing, it is important to fail as fast as possible. I think we'd favor relying on the build time unittests a bit more in exchange for faster iteration time on build failures.
At the time of writing, there are 17 wheels being built. Running tests to cover every one of these may not be worth the effort. It may be best to choose a representative set of platform/python version combos to maximize coverage while minimizing the variant combos of test machines.

I like where you are going with this. Here is some more thoughts I have:
General testing good practices:

A wheel should be first created and then used for running the tests. This tests the whole process of building the wheel, testing its installation and running the tests against the installed wheel.
If we go wild we could even say we need to first build an sdist, then build a wheel from the sdist to test the entire process and make sure our sdists are valid and working as expected. (Side note: When tox is used in a project, it's tox that makes sure that an sdist is built and then used to build a wheel and then install the wheel to be tested. But I know tox was removed from OTIO a couple of months ago). One might argue that we already run check-manifest in CI and that it already covers verification of files included in the sdists. That is true indeed, but it doesn't test the create of a wheel from the sdist + test from this.
Care must be taken to make sure tests don't use any code from the source files (which means we need to run the tests from another folder, like a tmp folder).

General improvements to be made for CI:

The test dependencies are specified and installed in two different ways right now (https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/master/.github/workflows/python-package.yml#L42-L47 and https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/master/.github/workflows/python-package.yml#L53). The dev extra installs all the dependencies manaully installed in actions plus one additional dependency. Though technically it's not exactly the same, but there is overlap that is confusing and unnecessary.

I have other things in my head but I think it would diverge a little bit from this issue.


Change basemap style without reloading the page. Closes #300

This adapts the work @stuartlynn recently added to svelte-maplibre to let us change MapLibre basemap without reloading the entire page. This is a much better UX to not lose current page state, and made even nicer with the new basemaps added or coming soon.
Demos: https://acteng.github.io/atip/swap_basemap/browse.html
https://github.com/acteng/atip/assets/1664407/14dafc4a-d9f0-4968-b157-831d7ee52470
https://github.com/acteng/atip/assets/1664407/5b401dca-b46b-4ba6-9140-bb2783a84245
CC @mem48 in case this helps with NPT

Looks good to me, but other layers still 'flicker', right?

Looks good to me, but other layers still 'flicker', right?

Yeah not sure if there is a good way around this. The only way I think to prevent that is to not use maplibres setStyle method and instead fetch the style ourselves, remove the previous style layers and sources and then add the new styles while leaving the user defined ones intact. Though I am not even 100% that would fix the flicker.
Might be woth investigating though


[releases] Added support for level 0 dispatching

layer for level 0 support

fixed wrong formatting

added error handling routines for level zero errors processing

fixed formatting

added define to remove level0 support during build, and addressed some feedbacks

fixed formatiing

introduced DAAL_DESABLE_LEVEL_ZERO and added support for skipping Level0 on windows

last fixes for comments from review

removed comments and full path to lze_loader

adress clang-format

adress copyrights check

adress copyrights check

Co-authored-by: amaklaev<EMAIL_ADDRESS>Co-authored-by: Petrov, Nikolay A<EMAIL_ADDRESS>

/intelci: run
set infra_branch=cherry-pick-7c9786bc-2


Fixed various recipes by removing faulty or non-available datasets

Description
This PR removes problematic dataset for some recipes (see #2408).

esmvaltool/recipes/mpqb/recipe_mpqb_xch4.yml: This only uses atmospheric variables, so I explicitly specified areacella in the preprocessor (see https://github.com/ESMValGroup/ESMValCore/issues/1265).
esmvaltool/recipes/recipe_impact.yml: Removed dataset that has an issue in the time coordinate on ESGF (see comments below).
esmvaltool/recipes/recipe_landcover.yml: Removed dataset that is not available on ESGF.
esmvaltool/recipes/recipe_perfmetrics_CMIP5.yml: Removed dataset that is not available on ESGF.
esmvaltool/recipes/recipe_perfmetrics_CMIP5_4cds.yml: Removed dataset that is not available on ESGF.

Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

[x] 🛠 This pull request has a descriptive title
[x] 🛠 Code is written according to the code quality guidelines
[x] 🛠 Documentation is available
[x] 🛠 Tests run successfully
[x] 🛠 The list of authors is up to date
[x] 🛠 Any changed dependencies have been added or removed correctly
[x] 🛠 All checks below this pull request were successful

New or updated recipe/diagnostic

[x] 🧪 Recipe runs successfully
[x] 🧪 Recipe is well documented
[x] 🧪 Figure(s) and data look as expected from literature
[x] 🛠 Provenance information has been added

To help with the number of pull requests:

🙏 We kindly ask you to review two other open pull requests in this repository

I don't think it makes sense to trigger the bot here because we have not turned on the automatic data download there and it seems to me that a lot of data are missing to run that recipe at DKRZ. The main_log_debug.txt obtained during the last round of recipe testing shows the problem that is fixed here:
esmvalcore.cmor.check.CMORCheckError: There were errors in variable tas:
 Time coordinate for var time is not monotonic
 time: Frequency mon does not match input data
in cube:
air_temperature / (K)               (-- : 48; latitude: 160; longitude: 320)
    Dimension coordinates:
        latitude                        -             x               -
        longitude                       -             -               x
    Auxiliary coordinates:
        time                            x             -               -
    Scalar coordinates:
        height                      2.0 m
    Cell methods:
        mean                        time (3 hours)
    Attributes:
        Conventions                 'CF-1.4'
        associated_files            'baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_atmos_fx_EC-EARTH_rcp85_r0i0p0.nc...
        branch_time                 2006.0
        cmor_version                '2.8.0'
        contact                     'Alastair McKinstry<EMAIL_ADDRESS>        experiment                  'RCP8.5'
        experiment_id               'rcp85'
        forcing                     'Nat,Ant'
        frequency                   'mon'
        initialization_method       1
        institute_id                'ICHEC'
        institution                 'EC-Earth (European Earth System Model)'
        model_id                    'EC-EARTH'
        modeling_realm              'atmos'
        nco_openmp_thread_number    1
        original_name               '2T'
        parent_experiment           'pre-industrial control'
        parent_experiment_id        'piControl'
        parent_experiment_rip       'r1i1p1'
        physics_version             1
        product                     'output'
        project_id                  'CMIP5'
        realization                 6
        references                  'Model described by Hazeleger et al. (Bull. Amer. Meteor. Soc., 2010, 91,...
        source                      'EC-EARTH 2.3 (2011); atmosphere: IFS (cy31R1+modifications, T159L62);...
        source_file                 '/mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output1/ICHEC/EC-EARTH/rcp...
        table_id                    'Table Amon (26 July 2011) b26379e76858ab98b927917878a63d01'
        title                       'EC-EARTH model output prepared for CMIP5 RCP8.5'
loaded from file /mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas/tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-200912.nc```

The recipe worked fine last time i ran it, the output is here: https://esmvaltool.dkrz.de/shared/esmvaltool/climate4impact/recipe_output.html. I do remember that i had to run it on my laptop and download all data, because on mistral there were some outdated models and the automatic download is not yet smart enough to check if a newer version is available even if the data is found locally.

I just checked the data, and indeed it looks weird:
 > ll `dirname /mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas/tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-205012.nc`                                                                                30ms
total 456340
-rwxrwxr-x 1 k204210 esgf   9851620 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-200912.nc
-rw-rw-r-- 1 k204210 esgf 110624960 Jun 21  2012 tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-205012.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_201001-201912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_202001-202912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_203001-203912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_204001-204912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_205001-205912.nc
-rw-rw-r-- 1 k204210 esgf 122914400 Jun 21  2012 tas_Amon_EC-EARTH_rcp85_r6i1p1_205101-210012.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_206001-206912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_207001-207912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_208001-208912.nc
-rwxrwxr-x 1 k204210 esgf  24599348 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_209001-209912.nc
-rwxrwxr-x 1 k204210 esgf   2477960 Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_210001-210012.nc

The problem does not appear in the tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-205012.nc file. Maybe we should ask DKRZ to delete the duplicated data?

It looks like this is a data issue on Mistral, not a problem with this recipe. Shall we close this pull request?

We just ran this recipe with data freshly downloaded from ESGF. Unfortunately, the error persists, so it's probably not an error on mistral. I suggest removing the erroneous dataset.

The problem is reported with the CMIP5 model, while this pull request removes a similar looking CMIP6 model

Right, sorry about that!! Will fix that locally and test the recipe.

Maybe we should consider making the code for selecting the most recent version of the data more advanced. But the fact that data can be stored over multiple versions as reported in https://github.com/ESMValGroup/ESMValCore/issues/286 makes this non-trivial.

Agreed! Can you open an issue about that? Would be nice to tackle this in v2.6.

I added other very similar changes to this PR. Here is a list of successful runs for the corresponding recipes:
https://esmvaltool.dkrz.de/shared/esmvaltool/v2.5.0-test-rc4/recipe_perfmetrics_CMIP5_20220304_111729/
https://esmvaltool.dkrz.de/shared/esmvaltool/v2.5.0-test-rc4/recipe_perfmetrics_CMIP5_4cds_20220304_114547/
https://esmvaltool.dkrz.de/shared/esmvaltool/v2.5.0-test-rc4/recipe_impact_20220304_112324/
https://esmvaltool.dkrz.de/shared/esmvaltool/v2.5.0-test-rc4/recipe_mpqb_xch4_20220304_092520/

The recipe_landcover runs fine with if the missing data listed in #2408 are removed. Note that with the updated version of esgf-pyclient, we are very confident that the data are not available on ESGF nodes for the recipes of this PR.

Could you update the top post so it clear describes what is changed in which recipes and why? Are there issues in which the problems are reported? The problem with recipe_impact.yml appears to be a combination of faulty data organization at DKRZ and a limitation of ESMValCore https://github.com/ESMValGroup/ESMValCore/issues/1523. What about the other recipes?

Could you update the top post so it clear describes what is changed in which recipes and why? Are there issues in which the problems are reported? The problem with recipe_impact.yml appears to be a combination of faulty data organization at DKRZ and a limitation of ESMValCore ESMValGroup/ESMValCore#1523. What about the other recipes?

Done.

Thanks! The problem with the CMIP5 EC-EARTH r6i1p1 dataset is not a wrong time coordinate, but that we are trying to use two versions of the dataset at the same time and these apparently have a different time coordinate. This happens because ESMValCore is not able to select the right files (https://github.com/ESMValGroup/ESMValCore/issues/1523). Using just the latest version would probably solve the issue.

Thanks! The problem with the CMIP5 EC-EARTH r6i1p1 dataset is not a wrong time coordinate, but that we are trying to use two versions of the dataset at the same time and these apparently have a different time coordinate. This happens because ESMValCore is not able to select the right files (ESMValGroup/ESMValCore#1523). Using just the latest version would probably solve the issue.

There is definitely an issue in the time coordinate in the old version of this:
> ncdump -v time tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-200912.nc                                                                                2268ms
netcdf tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-200912 {
dimensions:
        time = UNLIMITED ; // (48 currently)
        lat = 160 ;
        lon = 320 ;
        bnds = 2 ;
variables:
        double time(time) ;
                time:bounds = "time_bnds" ;
                time:units = "days since 2006-1-1" ;
                time:calendar = "gregorian" ;
                time:axis = "T" ;
                time:long_name = "time" ;
                time:standard_name = "time" ;
        double time_bnds(time, bnds) ;
        double lat(lat) ;
                lat:bounds = "lat_bnds" ;
                lat:units = "degrees_north" ;
                lat:axis = "Y" ;
                lat:long_name = "latitude" ;
                lat:standard_name = "latitude" ;
        double lat_bnds(lat, bnds) ;
        double lon(lon) ;
                lon:bounds = "lon_bnds" ;
                lon:units = "degrees_east" ;
                lon:axis = "X" ;
                lon:long_name = "longitude" ;
                lon:standard_name = "longitude" ;
        double lon_bnds(lon, bnds) ;
        double height ;
                height:units = "m" ;
                height:axis = "Z" ;
                height:positive = "up" ;
                height:long_name = "height" ;
                height:standard_name = "height" ;
        float tas(time, lat, lon) ;
                tas:standard_name = "air_temperature" ;
                tas:long_name = "Near-Surface Air Temperature" ;
                tas:units = "K" ;
                tas:original_name = "2T" ;
                tas:cell_methods = "time: mean (interval: 3 hours)" ;
                tas:cell_measures = "area: areacella" ;
                tas:history = "2013-01-13T11:10:30Z altered by CMOR: Treated scalar dimension: \'height\'. 2013-01-13T11:10:30Z altered by CMOR: replaced missing value flag (1e+28) with standard missing value (1e+20). 2013-01-13T11:10:30Z altered by CMOR: Converted type
 from \'d\' to \'f\'. 2013-01-13T11:10:30Z altered by CMOR: Inverted axis: lat." ;
                tas:coordinates = "height" ;
                tas:missing_value = 1.e+20f ;
                tas:_FillValue = 1.e+20f ;
                tas:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_atmos_fx_EC-EARTH_rcp85_r0i0p0.nc areacella: areacella_fx_EC-EARTH_rcp85_r0i0p0.nc" ;

// global attributes:
                ...
data:

 time = 15.5, 45, 74.5, 105, 135.5, 166, 196.5, 227.5, 258, 288.5, 319,
    349.5, 15.5, 45, 74.5, 105, 135.5, 166, 196.5, 227.5, 258, 288.5, 319,
    349.5, 15.5, 45.5, 75.5, 106, 136.5, 167, 197.5, 228.5, 259, 289.5, 320,
    350.5, 15.5, 45, 74.5, 105, 135.5, 166, 196.5, 227.5, 258, 288.5, 319,
    349.5 ;

But you are right, using only the latest version would most likely fix this.

Thanks for clarifying!

Thanks! The problem with the CMIP5 EC-EARTH r6i1p1 dataset is not a wrong time coordinate, but that we are trying to use two versions of the dataset at the same time and these apparently have a different time coordinate. This happens because ESMValCore is not able to select the right files (ESMValGroup/ESMValCore#1523). Using just the latest version would probably solve the issue.

Taking a closer look at the data available on Mistral, it looks to me that the newest of the two data versions available show a problem with the time coordinate:
ll /mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas
total 446M
-rw-rw-r--  1 k204210 esgf 106M Jun 21  2012 tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-205012.nc
-rw-rw-r--  1 k204210 esgf 118M Jun 21  2012 tas_Amon_EC-EARTH_rcp85_r6i1p1_205101-210012.nc
-rwxrwxr-x  1 k204210 esgf 9.4M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-200912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_209001-209912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_207001-207912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_204001-204912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_202001-202912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_201001-201912.nc
-rwxrwxr-x  1 k204210 esgf 2.4M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_210001-210012.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_208001-208912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_206001-206912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_205001-205912.nc
-rwxrwxr-x  1 k204210 esgf  24M Dec  1  2017 tas_Amon_EC-EARTH_rcp85_r6i1p1_203001-203912.nc

and the weird time coordinate is only in the model from Dec 1 2017. Nevertheless the data looks fine if downloaded from ESGF nodes.
From a testing perspective, the recipe_impact is challenging to run. Using Mistral data or downloaded data only is not sufficient to get a successful run. Given that DKRZ does not really support CMIP5 data any more, I am not sure they would clean that directory and download the latest data. Not sure that is a good enough reason for commenting out the faulty dataset from the recipe. But if we keep problems like this in our recipes, testing them automatically will remain challenging, I have seen that...

That's weird. From the screenshot of @bouweandela it looks like the problematic file is the old version (v20130315).

>>> from esmvalcore.esgf import find_files
>>> files = find_files(project="CMIP5", mip="Amon", short_name="tas", dataset='EC-EARTH', exp=['historical', 'rcp85'], ensemble='r6i1p1')
>>> for file in files:
...     print(file)
...
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/historical/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_historical_r6i1p1_190001-194912.nc on hosts ['aims3.llnl.gov', 'esgf-data1.ceda.ac.uk', 'esgf.nci.org.au', 'esgf2.dkrz.de']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/historical/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_historical_r6i1p1_195001-200512.nc on hosts ['aims3.llnl.gov', 'esgf-data1.ceda.ac.uk', 'esgf.nci.org.au', 'esgf2.dkrz.de']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-200912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20171115/tas_Amon_EC-EARTH_rcp85_r6i1p1_200601-205012.nc on hosts ['esgf.ichec.ie', 'esgf.nci.org.au']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_201001-201912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_202001-202912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_203001-203912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_204001-204912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_205001-205912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20171115/tas_Amon_EC-EARTH_rcp85_r6i1p1_205101-210012.nc on hosts ['esgf.ichec.ie', 'esgf.nci.org.au']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_206001-206912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_207001-207912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_208001-208912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_209001-209912.nc on hosts ['aims3.llnl.gov']
ESGFFile:cmip5/output1/ICHEC/EC-EARTH/rcp85/mon/atmos/Amon/r6i1p1/v20130315/tas_Amon_EC-EARTH_rcp85_r6i1p1_210001-210012.nc on hosts ['aims3.llnl.gov']
>>>

I'm really in favor for dropping this dataset. The recipe does not really depend on it and it caused already so much trouble during the tests.

I have run successfully the 5 recipes of this PR. The overview of the results can be found in this temporary table. Once this is merged, I will update the v2.5.0_rc4 table accordingly. Note that I used a dev installation of the Core to apply the latest fix for the perfmetrics recipes (https://github.com/ESMValGroup/ESMValCore/pull/1524)

@bouweandela can you remove your "requested changes" review if you are happy with this?
@axel-lauer What is your opinion on how to deal with missing datasets? Commenting them or removing them?

@axel-lauer What is your opinion on how to deal with missing datasets? Commenting them or removing them?

If in doubt, I would prefer to simply comment out things. This way, we still have some kind of "tracking" as the recipe does no longer reproduce the original figure. At least, then we do not forget as easily.

This should be ready now


support new sampling UI fields during resampling (numColumns, rowSamplingMethod, columnSamplingMethod)

done in https://github.com/noteable-io/dx/pull/156


Authentication Library

Refer to #29 for an overview of all design related tasks

@Abayolpeter
https://www.figma.com/file/UzdIIpsX43I1ZgMETPwLgQ/Authentication-Library?node-id=155%3A34


Update pre-commit hooks to latest versions

@jbusecke, when you get a chance, can you add me as a admin/maintainer to this repository?

Done.


feat/plugins-rate-limiting limit by path

Summary
plugins-rate-limiting limit by path

Hi @taotao2014, thanks for your submission!
I believe those changes to the PDK are not needed by this feature, right? Could you split these features in two different PRs, please?
We are still discussing if it is interesting to expose the balancer details to the PDK, but rate-limiting by path sounds like a nice feature.

Hi @taotao2014, thanks for your submission!
I believe those changes to the PDK are not needed by this feature, right? Could you split these features in two different PRs, please?
We are still discussing if it is interesting to expose the balancer details to the PDK, but rate-limiting by path sounds like a nice feature.

Thank you @locao , the feature has been split.
feat/plugins-rate-limiting by path #6216
https://github.com/Kong/kong/pull/6216

update #6234

I am closing this one since the change mentioned on the title was merged in #6286 . If you want to add that extra function to the PDK, please send a different PR. Thanks!


Improve disk size communication

Current rest api properties and their UI namings
actual_size -> Used
provisioned_size -> Total
This may be suitable for "thin provisioned" (cow) disks (I'm not sure if size of snapshots is included in actual size). However for "preallocated" (raw) disks it feels pretty misleading since a newly created disk seems to be fully used right from the beginning (see screenshot).
version: commit 852ab59

how do you suggest to improve it?

Based on IRC conversation with Tal: actual_size is allocated size, i.e. how much space does the disk occupy on the underlying storage.
Since the disk may use for example MBR table for partitioning and have not partitions created, there is not notion how much space is actually used by meaningful data. So my suggestions are pairs (actual_size /  provisioned_size)

allocated size / provisioned size
allocated size / (without any adjective) size
leave only the provisioned_size part named as Size, since VM Portal users are rarely expected to care about actual allocated size.

Comments? @michalskrivanek, @jelkosz, @mareklibra

allocated size / provisioned size
allocated size / (without any adjective) size
leave only the provisioned_size part named as Size, since VM Portal users are rarely expected to care about actual allocated size.

^^^ this sounds like the best option to me ^^^

Rendering just the provisioned_size does not help in identification that particaulr VM is running out of disk space.

Since the disk may use for example MBR table for partitioning and have not partitions created,
This is less common case in my POV

Rendering just the provisioned_size does not help in identification that particaulr VM is running out of disk space.

Yes, it doesn't. Sadly AFAIK there is no property of Disk entity that could help in identifying log disk space. As mentioned in the first comment, actual_size = provisioned_size for all raw disks. And that doesn't mean they are full.
Here is how engine identifies low disk space.

actual size is useful, and that's enough.
guest-agent reported values make sense, but only once we have it.

@lizsurette @sjd78 let's discuss this in the next redesign meeting

guest-agent reported values make sense, but only once we have it

sounds similar to what @michalskrivanek brought up last meeting, where the Disks card was showing Domain-level but needs to show VM-level

This issue is relevant to the disk charts on the Utilization card on #652
@gregsheremeta - Yeah, the discussion was around showing the VM users disk information that is relevant to them.  That means showing them info from the guest (partitions, file system sizes, things that a df -h may show), instead of info from infrastructure (provisioned disk size vs allocated disk size in a spare/thin disk/vol).
How exactly that translated to a donut + spark line chart I'm not quite sure.

See PR #700

no longer relevant


Documentation Site

I've added a proper documentation to the project. You can preview the site under https://awesome-notification-docs.vercel.app
To preview it, you need to run

cd docs
yarn install
yarn dev

When you want to deploy, you could do that with vercel.com like this:

cd docs
vercel

For the Search to work, @rafaelsetragni you need to apply with the deployed site here: https://docsearch.algolia.com/ and add the credentials to a copy of .env.example as .env or use build vars
In addition to the documentation, I also added .DS_Store to .gitignore and removed it with git rm --cached as I was not able to clone the project due to a conflict with that (automatically created) file on my system.
Todos:

[ ] Apply for Algolia search
[ ] Add credentials for search
[ ] Remove unneeded/duplicated stuff from main readme
[ ] Check for missing stuff in new docs

Hey @rafaelsetragni any reason why you did not take a look until now? I put some work into that after you've mentioned to lack of contributions 🤷♂

I need to finish the version 0.7.5 first and then i will study all your modifications before merge it.

@rafaelsetragni forgot about?


AUTHENTICATION IN SIGN IN PAGE

Description
as i observed your login page doesn't working on the basis of authentication .

Steps to Reproduce

go to login page
try login
problem is everyone have feature to login no matter he/she is old user or not

Expected Behavior
EX:- as we login in game , game software only allow us to login if we have old account in it unless it will show us a error.
Actual Behavior
No response
Screenshots
No response
Additional Information
i am able to this backed work with the help of firebase(google library) please assign me this work so that i will look forward to contribute and I WOULD LOVE TO CONTRIBUTE .

What browser are you seeing the problem on?

[X] Firefox
[X] Chrome
[X] Safari
[X] Microsoft Edge

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue. (optional)

I would to solve this issue please assign me


Any sort of rebase option?

I'm no expert with all programs, and I took the time to look at the manual. Either I'm missing something, or this program does not contain any set of tools to make this happen. My program I want to debug relies on a  certain memory address contained within the program itself, iBoot. I need to make my memory output as 0x5FF00000 and right now, its increment is from 0x0. Basically, all I need is to have the memory layout as such rather than starting from 0x0. Anyone who has solved this, please let me know!

there is the options button (Base Address) in the import file dialog, (it works for raw binary) not sure what you file format is but can that do what you need?

This was exactly what I needed! Sorry about the noob question as I just realized I totally didn't see the button. I was a little too excited and completely looked over the button to find what I needed! Thanks!

For a rebase after the binary has been loaded, open the Memory Map window and press the house at the top right.

!(image)[https://files.watercod.es/c09514b90.png]


Add FP5 E2M2 support from upstream

https://github.com/usyd-fsalab/fp6_llm/commit/5df6737cca32f604e957e3f63f03ccc2e4d1df0d
Also close #402
New API
from torchao.quantization.quant_api import quantize
from torchao.prototype.quant_llm import fp6_llm_weight_only, quant_llm_fpx_weight_only

model = ...
model.half()  # not necessary, but recommeneded to maintain accuracy
quantize(model, fp6_llm_weight_only())  # convert nn.Lineaer.weight to FP6 E3M2 in-place

# for generic FPx EyMz where x = 1 + y + z
# quantize(model, quant_llm_fpx_weight_only(2, 2))  # use FP5 E2M2 instead

# fully compatible with torch.compile()
model.compile(mode="max-autotune", fullgraph=True)

Benchmark results
Benchmarks are run on a machine with a single 4070Ti SUPER GPU using the scripts in _models/llama. tokens/s is measured using generate.py which generates text in a latency optimized way (batchsize=1). wikitext perplexity is measured using eval.py which uses lm_eval. The model used is meta-llama/Llama-2-7b-chat-hf.
FPx quantization is run with --precision float16. The rest uses the default precision of bfloat16.

Quantization
wikitext perplexity
tokens/s

INT8
12.21
87.45

INT4-256 (tinygemm)
(bug)
157.10

FP6 E3M2
12.34
106.76

FP6 E2M3
12.23
106.77

FP5 E3M1
12.55
122.69

FP5 E2M2
12.47
122.66

FP4 E3M0
14.58
145.55

FP4 E2M1
15.01
146.05

FP3 E2M0
74625.18
164.49

For the nightly failure in CI make sure to rebase to main in ao. There's some upstream issue with triton we haven't debugged yet #429

tensor subclass changes LGTM, I'll leave the rest to @msaroufim

another nit comment I have is the quant_llm name, should we rename this to something more specific like fp6/fp5? also what is the difference between this as mx?

another nit comment I have is the quant_llm name, should we rename this to something more specific like fp6/fp5?

I also don't really like the Quant-LLM name since it's quite ambiguous. But the upstream repo renames it to that (https://github.com/usyd-fsalab/fp6_llm) so I follow it. The original name (first release) was FP6-LLM.
The kernel supports arbitrary FP2 -> FP7, so naming it as only FP6/FP5 is quite limited. My benchmarks show that FP4 is not competitive with INT4 tinygemm (might be improved by block-wise quantization). For now I only enable FP6 E3M2, FP6 E2M3, FP5 E2M2, and FP5 E3M1 (each dtype support is a template instantiation. upstream repo only tested for FP6E3M2 and F5 E2M2). Something better might be like quant_llm_fpx. In the future upstream repo might even support INTx.
I'm open to changing the name.

also what is the difference between this as mx?

The FPx dtype itself is quite similar to MX, thus I refactored dtype casting code from @vkuzo (#363) and re-use it here. However, there are key differences

MX specs only specify FP6 E3M2, FP6 E2M3 and FP4 E2M1, while Quant-LLM kernel supports arbitrary FPx as mentioned above
MX dtype use block-wise quantization scale, and scale is in E8M0 format. In contrast, Quant-LLM kernel only supports per-row quantization scale.
Quant-LLM uses a special layout optimized for tensor cores (see pack_tc_fpx()). The idea is similar to tinygemm I think.

I think those differences are significant enough to make separate subclasses for them. It also helps with maintenance.

Thanks for the detailed context @gau-nernst, OK makes sense to keep the name for now I guess, but maybe we can talk to the author to make the name a bit more descriptive like you said (e.g. quant_llm_fpx), in torchao I feel we should probably use fpx (as a name for dtype) in the end to indicate that it supports different floating point dtypes.