Add payments for ledgers to the CLI and edit a few things in the docs

Resolves #170
Adds payments for a ledger to the CLI and cleaned up a few things in the documentation.
Is there a GIF that reflects how this work made you feel?

@robertDurst @kbacha have give it another look at your convenience.


make test-integration & make docker-image fails because of wrong hash.

Hello, I want to setup the scion dev environment but I am running into an issue when making the test integration for it. Here's the error:

I checked the file and get this hash instead of the intended one:

How can I solve this issue and proceed to build the environment correctly?
I need to precise that make and make test are working but this error occurs for make test-integration and make docker-images.
I am on a virtualized Ubuntu 22.04.3 LTS.

Hi @Andraax
We have observed this issue in combination with a recent docker release. It appears that the rules_docker that we are using is incompatible with the latest docker version.
The long term fix is to adopt rules_oci.
As a temporary workaround, you can downgrade your docker version as described in this slack thread:
https://scionproto.slack.com/archives/C8ADA9CEP/p1708592627637149?thread_ts=1708537828.158799&cid=C8ADA9CEP
sudo apt-get autoremove docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
VERSION_STRING=5:24.0.7-1~ubuntu.22.04~jammy
sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin

Just to confirm, what is your currently installed docker version?
For me, the following works without any issues:
$ docker version
Client: Docker Engine - Community
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:07:41 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:07:41 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.28
  GitCommit:        ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Thanks, downgrading to docker 24.0.7 resolved my issue and now I am able to run SCION.


Unhandled exception: Invalid argument(s): Cannot find executable for sysctl.

After upgrading flutter on macbook here is the error I got.
Even Flutter doctor is giving me the same error.
Unhandled exception:
Invalid argument(s): Cannot find executable for sysctl.
#0      _getExecutable (package:process/src/interface/local_process_manager.dart:124:5)
#1      LocalProcessManager.runSync (package:process/src/interface/local_process_manager.dart:91:30)
#2      ErrorHandlingProcessManager.runSync.<anonymous closure> (package:flutter_tools/src/base/error_handling_io.dart:649:37)
#3      _runSync (package:flutter_tools/src/base/error_handling_io.dart:548:14)
#4      ErrorHandlingProcessManager.runSync (package:flutter_tools/src/base/error_handling_io.dart:649:12)
#5      _DefaultProcessUtils.runSync (package:flutter_tools/src/base/process.dart:420:51)
#6      _MacOSUtils.hostPlatform (package:flutter_tools/src/base/os.dart:305:25)
#7      _MacOSUtils.name (package:flutter_tools/src/base/os.dart:291:123)
#8      new _DefaultUsage (package:flutter_tools/src/reporting/usage.dart:247:18)
#9      new Usage (package:flutter_tools/src/reporting/usage.dart:81:9)
#10     runInContext.<anonymous closure> (package:flutter_tools/src/context_runner.dart:263:20)
#11     AppContext._generateIfNecessary.<anonymous closure> (package:flutter_tools/src/base/context.dart:104:41)
#12     _LinkedHashMapMixin.putIfAbsent (dart:collection-patch/compact_hash.dart:291:23)
#13     AppContext._generateIfNecessary (package:flutter_tools/src/base/context.dart:92:20)
#14     AppContext.get (package:flutter_tools/src/base/context.dart:121:32)
#15     flutterUsage (package:flutter_tools/src/globals.dart:55:35)
#16     _handleToolError (package:flutter_tools/runner.dart:133:13)
#17     run.<anonymous closure>.<anonymous closure> (package:flutter_tools/runner.dart:87:13)
#18     run.<anonymous closure>.<anonymous closure> (package:flutter_tools/runner.dart:81:17)
#19     _rootRunBinary (dart:async/zone.dart:1222:13)
#20     _CustomZone.runBinary (dart:async/zone.dart:1107:19)
#21     runZonedGuarded.<anonymous closure> (dart:async/zone.dart:1601:18)
#22     _CustomZone.handleUncaughtError (dart:async/zone.dart:1076:19)
#23     Future._propagateToListeners (dart:async/future_impl.dart:646:16)
#24     Future._completeError (dart:async/future_impl.dart:537:5)
#25     _completeOnAsyncError (dart:async-patch/async_patch.dart:264:13)
#26     run.<anonymous closure>.<anonymous closure> (package:flutter_tools/runner.dart)
<asynchronous suspension>

I'm given the same error

Didn't think sysctl could ever be missing.
What's the output of
$ which sysctl

I have the same error, after trying the which command it simply says sysctl not found.

Resolved the issue by replacing the installed folder by the previous stable version (1.22.3).

What's the output of:
$ ls /usr/sbin/sysctl
$ echo $PATH

https://stackoverflow.com/a/42352026 suggests it could be at /sbin/sysctl on some macs, updated the request for info.

Resolved this problem by adding /usr/sbin to PATH . In my case, the sysctl is in /usr/sbin

vim ~/.bash_profile
export PATH=/usr/sbin/sysctl:$PATH
this code resolve error,I check it

vim ~/.bash_profile
export PATH=/usr/sbin/sysctl:$PATH
this code resolve error,I check it

I have the same problem and I can't seem to find a solution. Can someone please help ? I don't know much about the PATH variable or sysctl files in general, so I have no idea what's actually happening here.
I also tried a fresh install, and that didn't work either.
Any help would be very nice, as I'm completely stuck on what to exactly do.

I have the SAME problem, it persists even after a fresh install and changing PATH info. I'm really stuck on it

Hey, I actually managed to solve the problem yesterday.
Run `which sysctl' in the terminal, and it should output a directory now, which means it found it. Then proceed to do a fresh install of the flutter sdk through the official docs.
Everything should normally happen now. Also, skip the step where they tell you to set the path variable, since you've already done it.
I don't know about VS Code, but I'm using Android Studio for my development, and the first time I opened it after all of this, it couldn't locate the Dart SDK. There's a folder inside the flutter folder, at flutter/bin/cache/dart-sdk , that's the one where you should point it to.
I'm not sure about this, but what I think the problem was that the PATH variable got mixed up, and so the terminal could no longer find crucial files.
Hope this helps dude.
If you have other questions or problems, reply here so that I can try and help out, and for future reference by others.


Make it a Python package and pull completions on-the-fly

This pull request tries to streamline two issues with curent fish-django-completions:

make it pip-installable to avoid having to manually copy the generation script into each project
generate Fish completions on-the-fly on each initial completion attempt so all of a project's commands are taken into account.

I hope you like it. Please let me know if there's anything I can do to get this merged.
Thank you for this awesome package!

hi @jnns ! So sorry I missed this completely. Will take a look asap.


Showing ghosting in the SqlEditor screen

Ubuntu 16.04 -
DBeaver 5.1.4

Duplicate of #3916. See workaround in last #3916 comments.


Review request

link to the repository: https://github.com/Juanpa8830/Pokeapp
Note: In Our team, we are three people

Status: ✔ Project Approved ✔
Hi @Juanpa8830,
Everything is looking great! Please, start the project. :shipit:
Congratulations! 🎉
Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you take them into account as they can make your code better.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think the code review was unfair, you can request a second opinion using this form.


Fix link to cloud provider in relationship accordion

https://bugzilla.redhat.com/show_bug.cgi?id=1273436
before

after - link change to the restful route

@martinpovolny @h-kataria please review


Secret in clear text

Hi,
I would strongly recommend you to rotate that secret and change your implementation to not store the secret in clear text.
https://github.com/maikvandergaag/msft-extensions/blob/be3ef4438d6f2e50fee14659469c497715dfab6a/scripts/login-session.ps1#L1

thanks


Check if a reviewers ia already requested before re-assigning him

As discussed in https://github.com/zattoo/web/pull/3626 we don't want the automation to automatically ask reviewers to re-check pull-request, but rather we want this option to be in our hands.
So we shall check if a reviewer is already assigned to a pull-request before requesting his review by getting requested reviewers

@gotbahn OK, I was wrong again, requested-reviewers is giving back only reviewers who still didn't give a review, so we will be at the same place as before
Once a user who was requested to give a review gave a review, he is no longer on the list of requested reviewers :/
Another option would be to collect all users who gave a review on a pull request and omit them from the request. that can work

@nitzanashi interesting how GitHub build reviewer list, they use the same API, so definitely should be possible. Let's keep it like that for some time and see if someone except me complains.


jniLibs Folder

sorry for my english @codinguser
what's it for the jniLibs folder?
Thanks in advance :)

It's binaries for DropBox integration

@juandiego26 please do not use issues to ask questions.
You can send questions to<EMAIL_ADDRESS>


Does annotation "cni.projectcalico.org/ipAddrs" not support multiple IP addresses?

    cni.projectcalico.org/ipAddrs: A list of IPv4 and/or IPv6 addresses to assign to the Pod. The requested IP addresses will be assigned from Calico IPAM and must exist within a configured IP Pool.

As calico's doccument describing, annotation "cni.projectcalico.org/ipAddrs" suport a list of IPv4 and/or IPv6 addresses.   Does this mean I can config annotation "cni.projectcalico.org/ipAddrs" as this:
annotations:
    "cni.projectcalico.org/ipAddrs": "[\"<IP_ADDRESS>\", \"<IP_ADDRESS>\"]"

But I write this deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        "cni.projectcalico.org/ipAddrs": "[\"<IP_ADDRESS>\", \"<IP_ADDRESS>\"]"
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

[root@k8s-master3 ~]# kubectl create -f nginx.yaml
deployment.apps/nginx-deployment created

[root@k8s-master3 ~]# kubectl get pods -o wide
NAME                                READY   STATUS              RESTARTS   AGE   IP       NODE          NOMINATED NODE   READINESS GATES
nginx-deployment-78fffc4b8c-g6clh   0/1     ContainerCreating   0          8s    <none>   k8s-master4   <none>           <none>
nginx-deployment-78fffc4b8c-wlmcr   0/1     ContainerCreating   0          8s    <none>   k8s-master4   <none>           <none>

[root@k8s-master3 ~]# kubectl describe pod nginx-deployment-78fffc4b8c-g6clh
Name:           nginx-deployment-78fffc4b8c-g6clh
Namespace:      default
Priority:       0
Node:           k8s-master4/<IP_ADDRESS>
Start Time:     Mon, 17 Feb 2020 13:52:34 +0800
Labels:         app=nginx
                pod-template-hash=78fffc4b8c
Annotations:    cni.projectcalico.org/ipAddrs: ["<IP_ADDRESS>", "<IP_ADDRESS>"]
Status:         Pending
IP:
Controlled By:  ReplicaSet/nginx-deployment-78fffc4b8c
Containers:
  nginx:
    Container ID:
    Image:          nginx:1.7.9
    Image ID:
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-mx9jt (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-mx9jt:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-mx9jt
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age                             From                  Message
  ----     ------                  ----                            ----                  -------
  Normal   Scheduled               19s                             default-scheduler     Successfully assigned default/nginx-deployment-78fffc4b8c-g6clh to k8s-master4
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "cb0ec1f06afd6aba637f78139662c881dffac2cd4d1124efe8de85558301440b" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "739c81210ea30f63a655967afc4abd54acf8e0d9891e064111dc911e4520900a" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "b8fd76a2ee272233341dd57118e28c245752b069b5bceee83e4812872e929457" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "dcc28608cf3eb50585883ccaa6d9db4703efc779573330b866ca0aaf11fb1458" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e57289861563225b74b58672836aa00eed6dd5aeda7547be9b5eabe32ae14a2d" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "d48f9d91c703ddc7128b8e99a39fcab922ed0e2e909a1d93769a1763cfbbfc97" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "afbad81a814dfd85c1a88a391c5e45937768d5f69534675189223a78e80fd1bb" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "d4797f1097df21b923b772fa0918fe35d0d7ff4b8beb9c50fbf2afe4614fb5f1" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Warning  FailedCreatePodSandBox  <invalid>                       kubelet, k8s-master4  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "1ca3dc2736f70d747e35c9677240b0158bf4c50548737ddef02ced4f010ca1d7" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
  Normal   SandboxChanged          <invalid> (x12 over <invalid>)  kubelet, k8s-master4  Pod sandbox changed, it will be killed and re-created.
  Warning  FailedCreatePodSandBox  <invalid> (x4 over <invalid>)   kubelet, k8s-master4  (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0dc35609466ff7db1275c758abb2051d3db52ecafdca44e86900c22b72bbcc79" network for pod "nginx-deployment-78fffc4b8c-g6clh": NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation

Expected Behavior
Two pods will be created successfully. And the pod nginx-deployment-78fffc4b8c-g6clh is assigned ip <IP_ADDRESS> or <IP_ADDRESS>
Current Behavior
Fail to create the two pods. Error message: NetworkPlugin cni failed to set up pod "nginx-deployment-78fffc4b8c-g6clh_default" network: cannot have more than one IPv4 address for "cni.projectcalico.org/ipAddrs" annotation
Your Environment

Calico version is 3.11.1
kubernetes is v1.15.4
centos 7.6

After reading the source code of cni-plugin project, I just understanding that the annotation "cni.projectcalico.org/ipAddrs" is just one IPv4 and IPv6 address.

I have already solved this problem by using annotation "cni.projectcalico.org/ipv4pools" related the new ip pool（not the default pool）. My operation steps is as following:
[root@k8s-master3 ~]# cat ippool1.yaml
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: new-pool1
spec:
  blockSize: 31
  cidr: <IP_ADDRESS>/31
  ipipMode: Never
  natOutgoing: true
[root@k8s-master3 ~]# calicoctl create -f ippool1.yaml
Successfully created 1 'IPPool' resource(s)
[root@k8s-master3 ~]# cat ippool2.yaml
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: new-pool2
spec:
  blockSize: 31
  cidr: <IP_ADDRESS>/31
  ipipMode: Never
  natOutgoing: true
[root@k8s-master3 ~]# calicoctl create -f ippool2.yaml
Successfully created 1 'IPPool' resource(s)
[root@k8s-master3 ~]#
[root@k8s-master3 ~]#
[root@k8s-master3 ~]# calicoctl get ippool
NAME                  CIDR           SELECTOR
default-ipv4-ippool   <IP_ADDRESS>/16   all()
new-pool1             <IP_ADDRESS>/31   all()
new-pool2             <IP_ADDRESS>/31   all()

root@k8s-master3 ~]# cat nginx.yaml
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        "cni.projectcalico.org/ipv4pools": "[\"new-pool1\",\"new-pool2\"]"
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
[root@k8s-master3 ~]# kubectl create -f nginx.yaml
deployment.apps/nginx-deployment created
[root@k8s-master3 ~]# kubectl get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP          NODE          NOMINATED NODE   READINESS GATES
nginx-deployment-f49447c5d-4k4px   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>
nginx-deployment-f49447c5d-5sbrx   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>
nginx-deployment-f49447c5d-flfb8   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>
nginx-deployment-f49447c5d-q4945   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>

I have already solved this problem by using annotation "cni.projectcalico.org/ipv4pools" related the new ip pool（not the default pool）. My operation steps is as following:
[root@k8s-master3 ~]# cat ippool1.yaml
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: new-pool1
spec:
  blockSize: 31
  cidr: <IP_ADDRESS>/31
  ipipMode: Never
  natOutgoing: true
[root@k8s-master3 ~]# calicoctl create -f ippool1.yaml
Successfully created 1 'IPPool' resource(s)
[root@k8s-master3 ~]# cat ippool2.yaml
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: new-pool2
spec:
  blockSize: 31
  cidr: <IP_ADDRESS>/31
  ipipMode: Never
  natOutgoing: true
[root@k8s-master3 ~]# calicoctl create -f ippool2.yaml
Successfully created 1 'IPPool' resource(s)
[root@k8s-master3 ~]#
[root@k8s-master3 ~]#
[root@k8s-master3 ~]# calicoctl get ippool
NAME                  CIDR           SELECTOR
default-ipv4-ippool   <IP_ADDRESS>/16   all()
new-pool1             <IP_ADDRESS>/31   all()
new-pool2             <IP_ADDRESS>/31   all()

root@k8s-master3 ~]# cat nginx.yaml
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        "cni.projectcalico.org/ipv4pools": "[\"new-pool1\",\"new-pool2\"]"
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
[root@k8s-master3 ~]# kubectl create -f nginx.yaml
deployment.apps/nginx-deployment created
[root@k8s-master3 ~]# kubectl get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP          NODE          NOMINATED NODE   READINESS GATES
nginx-deployment-f49447c5d-4k4px   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>
nginx-deployment-f49447c5d-5sbrx   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>
nginx-deployment-f49447c5d-flfb8   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>
nginx-deployment-f49447c5d-q4945   1/1     Running   0          11s   <IP_ADDRESS>   k8s-master4   <none>           <none>

At least there's a problem in the documentation that's misleading about this here it mentions multiple times "A list of IPv4 and/or IPv6 addresses to assign to the Pod" with plural.


Fix issues with 1.2 blog, TODO was left on a title

…n is missing in some cases
Description

Related Issue(s)

Checklist

[ ] I have read the contribution guidelines
[ ] Suitable unit/system level tests have been added and they pass
[ ] Documentation has been updated

[ ] Upgrade instructions
[ ] Configuration details
[ ] Concepts

Labels

[ ] Backport needed? -> add the backport label
[ ] Includes a DB migration? -> add the area:migration label

Any reason why this had no reviewer assigned, and hasn't been merged?

I can't see any reason not to get this merged... so doing so.


test:  backports knuu optimizations from 3493

Closes #3480
This PR backports many optimizations introduced in the big block tests via https://github.com/celestiaorg/celestia-app/pull/3493 to the main branch.
Will be ready for review after merging https://github.com/celestiaorg/celestia-app/pull/3514

Since the optimization work was done by @smuu, assigning him to the PR for comments/questions.

When this is merged, we can close https://github.com/celestiaorg/celestia-app/issues/3480

Do you mind specifying what optimisations this makes to knuu?

When this is merged, we can close #3480

@smuu Thanks! Added to the PR description.

blocked by #3505

blocked by #3505

#3505 has been merged, and I have revised the content of this PR accordingly. cc:@smuu

Let me know if you have any other questions about these optimizations.

[To reviewers] I run all the e2e tests and benchmark tests and can confirm that they all work fine.


Invalid cookie when sign in

Hi, when I sign in to leetcode by Cookie, I get an error:
Error executing vim.schedule lua callback: ...packer\start\leetcode.nvim/lua/leetcode/cache/cookie.lua:25: Invalid cookie stack traceback:         [C]: in function 'error'         ...packer\start\leetcode.nvim/lua/leetcode/cache/cookie.lua:25: in function 'update'         ...pack\packer\start\leetcode.nvim/lua/leetcode/command.lua:45: in function 'on_submit'         ...a\site\pack\packer\start\nui.nvim/lua/nui/input/init.lua:160: in function <...a\site\pack\packer\start\nui.nvim/lua/nui/input/init.lua:147>

I'm using Windows 11 and packer.nvim.

Is your leetcode account verified via email?

Yes

Its an issue with your curl not supporting --compressed flag.
Does any of these fix your problem?
https://superuser.com/questions/1482661/where-to-get-libcurl-for-windows-with-compressed-option-enabled
https://imperioweb.net/en/fix-curl-option-compressed-doesnt-support-this-cygwin
https://stackoverflow.com/questions/59844774/not-able-to-run-curl-command-from-windows-command-prompt-but-can-run-it-from-cyg


Implement CachingStrategy in FlowListView [Question]

Is there any way to implement Caching Strategy in FlowListView? Thanks in advance! :)

It's already enabled by default.

How can i set the Caching strategy? I want to change it to "RetainElement" in order to fix the issue for Android 7 (crash when scrolling the listview), is it possible?

Just use its alternate constructor:
public FlowListView(ListViewCachingStrategy cachingStrategy) : base(cachingStrategy)

This is a great library, except it is crashing on android when scrolling backwards (up instead of down)
I'm assuming this helps, but what does using the alternate constructor look like in XAML?

@johntsil @99hats a little late, but here is how you can pass a diferent CachingStrategy over XAML:
 <flv:FlowListView>
     <x:Arguments>
         <ListViewCachingStrategy>RetainElement</ListViewCachingStrategy>
     </x:Arguments>
 </flv:FlowListView>

And here are the docs on Passing Arguments in XAML


XGM2 tempo off on PAL

Unlike the original XGM I'm having to set the XGM2_setMusicTempo to 60 to get things to play at the correct speed? Is this by design or is the detection not working properly?

To be honest I'm not sure why it doesn't work, default is 60 tick / second and it should work for both PAL or NTSC. Maybe the value was reset for some reason. Anyway I push a fix which was needed to properly adjust timing depending the PAL / NTSC track info.


readFile returns Error ERR_INVALID_ARG_VALUE

Using the multer package to parse the xlsx in express js:
Code:
const XLSX = require('xlsx');
const multer = require('multer');
const upload = multer();

module.exports = function(app){

    app.post('/upload', upload.any(), function(req, res) {
        let uploadedFile = req.files[0].buffer;
        console.log("uploadedFile: ", uploadedFile);
        var workbook = XLSX.readFile(uploadedFile, {inputType: "buffer"});

        res.sendStatus(200);
    });

}

Output:
uploadedFile:
Buffer(96769) [80, 75, 3, 4, 20, 0, 6, 0, …]
TypeError [ERR_INVALID_ARG_VALUE]: The argument 'path' must be a string or Uint8Array without null bytes. Received <Buffer 50 4b 03 04 14 00 06 00 08 00 00 00 21 00 c0 ea 9a 4d e0 01 00 00 7a 0e 00 00 13 00 08 02 5b 43 6f 6e 74 65 6e 74 5f 54 ...
    at Object.fs.openSync (fs.js:552:3)
    at Object.fs.readFileSync (fs.js:465:33)
    at read_binary (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/xlsx/xlsx.js:1891:44)
    at readSync (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/xlsx/xlsx.js:19481:69)
    at Object.readFileSync (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/xlsx/xlsx.js:19509:9)
    at /Users/jonas/Workspace/auto_calendar_js_backend/src/routes.js:10:29
    at Layer.handle [as handle_request] (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/express/lib/router/layer.js:95:5)
    at next (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/express/lib/router/route.js:137:13)
    at Array.<anonymous> (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/multer/lib/make-middleware.js:53:37)
    at listener (/Users/jonas/Workspace/auto_calendar_js_backend/node_modules/on-finished/index.js:169:15)

Using Postman to perform the POST request with the xlsx sheet inside the form data
It tries to read the file via a path, but i don't want to save the file first on the server to then serve it back to xlsx via path. I prefer to directly pass it so that it's stateless.
I tried to add the {inputType: "buffer"}, but it still tries to read it as a path..
Any idea's?

readFile always interprets the argument as a file name.  Use read with the option type:"buffer":
        let uploadedFile = req.files[0].buffer;
        console.log("uploadedFile: ", uploadedFile);
        var workbook = XLSX.read(uploadedFile, {type: "buffer"});


Cannot reproduce the result

Hi Mr.Zhao
We recently read this paper, which is very well written, well-structured. Therefore, we have carried out the reproducing work of the paper. In the process of reproducing, regarding the "Seen data", the experimental results have not reached the effect of the paper, so if it is convenient, can you provide the relevant results and data in the experiment? , Such as the final generated text. This will also better prove the validity of your work.  Thank you very much!
Yours Sincerely
Winston

Output sent by email.
For evaluation, please follow the official evaluation scripts. Different scripts may have dramatically different results.
https://webnlg-challenge.loria.fr/challenge_2017/


Feature Flag for Web Applications Hands on Lab - Basic Version (Intergen)

PR comments have been fixed :)


Chapter 2: does the algorithm performs better than humans?

Hello,
I'm reading the book at the moment and I think it's fantastic. I just finished chapter 2, and at this point, I have a question regarding the performance of the algorithm VS human performance.
Once the estimator is fully trained and optimized, its RMSE is about 49,000$. In section 2.2, it is said  that experts have an error rate of 15%. Does it mean that whatever the value of the house, experts will have an error rate of 15%? I imagine so. So for a house costing 450k, the error would be 67.5k. For cheaper houses, it would be ways less, and will actually go under the RMSE of our estimator.
So, which one is better in this case? Also, is the model sufficiently good enough so that a company would prefer it over humans?

Hi @JPFrancoia ,
Thanks for your kind words! :)
Great question, indeed, human performance is better than our best model, in this example.  The automated system might still be worthwhile if it allows the experts to concentrate on more interesting and/or profitable projects. ML does not always reach superhuman level, but even sub-human systems can be worthwhile.
Hope this helps!

human performance is better than our best model, in this example.

Is it all the time, or is it only for the cheaper houses?
Thank you for your answer anyway. It's always best to know the limitations of the model. Is there any way (for his example) that a model could beat the humans?

I'm not sure, I have not investigated much further.  I'd be interested if you manage to squeeze better performance from another model. :)

Thanks! Maybe I'll try one day, atm I was just curious if you knew about something better.


PoC: Release tuf with in-toto attestations and supply chain definition

Please fill in the fields below to submit a pull request.  The more information
that is provided, the better.
Fixes #529
POC for "long-term fix" for #1966
Description of the changes being introduced by the pull request:

Provides additional release instructions to locally generate in-toto links (attestations) for the 'git tag' step and each 'build' step (sdist and wheel).
Configures cd build job on GitHub to also generate attestations for sdist and wheel builds.
Adds script to generate generic in-toto layouts (supply chain definition) to verify the release:
This means for each build artifact that the release was tagged, and the tagged sources match the inputs to both local and cd builds, and the build outputs match the actual build artifacts available to the verifier. Moreover, the attestations must have been signed by the keys authorized in the layout.
The PR also includes instructions on how to verify the build artifacts against the corresponding layout using the created attestations.

See RELEASE_with_in-toto.md for details.
Please verify and check that the pull request fulfills the following
requirements:

[ ] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.354%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1201

Relevant Lines:
1217

💛  - Coveralls

Although this PR is fully functional, I labeled it as PoC because it has a couple of UX pain points:
Key distribution

Signing key for CD build job attestation is created locally and stored as GitHub secret (along with decryption password) in a one-time setup, and piped to a file during each CD build, in order for in-toto to use it, which feels cumbersome and risky (layout and maintainer attestation keys, otoh, use gpg and thus benefit from existing key server network).
While public keys and authorization mappings for attestation signatures are published through the layouts, the layout signing keys and thresholds need to be defined and distributed out-of-band. This PoC assumes that the layout is signed with one maintainer gpg key (see note about threshold below). How to establish root trust in layout signing keys is still unclear. Relying on fingerprints from maintainers.txt in the repo to protect the repo does not seem ideal.

Metadata distribution

CD build job attestations are published automatically on the GitHub release page, from where they must be downloaded by the verifier.
There is no mechanism to easily distribute layouts and maintainer attestations for verification. This PoC assumes that the verifier has created layouts and maintainer attestations and they are available locally during verification
There is also no mechanism to easily distribute layouts for threshold signing. In this PoC the layouts are signed only once.

in-toto quirks
In order for the verifier to link the paper trail of attestations to the actual final product, i.e. the build artifacts, a layout must define a so-called inspection, which in turn must define a shell command that is executed upon verification, even if no command is needed. Besides unnecessarily running a command, this can also fail the entire verification, if the command defined in the layout is not available to the verifier.
Ideally, the inspection command is relevant to the verification. In our case this could be an untar/unzip command to open up the build artifact and, by defining further artifact rules in the layout, match its contents to the tagged sources earlier in the supply chain. To not further bloat the PR, I only defined the dummy inspection as described above.
Another minor ux nuisance is that when the verifier runs the inspection command, it records all files from cwd as materials and products into an inspection attestation, which can then be used to link the final product to the products reported by the build attestation. For this to work, verification has to be run from a clean directory that contains only the build artifact to be verified.
See in-toto/docs#27 for a discussion about (dummy) inspections and linking the final product.

FYI: I also played around with a hatch plugin to generate in-toto attestations transparently by just calling python -m build ..., instead of wrapping the build command with in-toto-run [opts] -- [cmd]:  see https://github.com/lukpueh/tuf/commit/f89dcbdf84ac5ac81c218238360a089a78baa7cd
For this PoC it made sense to just use the verbose in-toto-run command, but a hatch plugin could benefit the broader community.
(cc @ofek, author of hatch and in-toto adoption veteran)

FYI: I also played around with a hatch plugin to generate in-toto attestations transparently by just calling python -m build ..., instead of wrapping the build command with in-toto-run [opts] -- [cmd]

I'm still ingesting the whole thing so this is just a comment on this specifically:
The build system plugin feels like a good idea but I do have a fundamental issue with injecting intoto into the python-tuf build system in general like the example does: we're adding a build dependency (an unversioned one even, although I'm sure that's because it's a PoC) for no benefit to the actual build.
I'm not saying the in-toto maintainers are not trustworthy :stuck_out_tongue:, but I'm not sure that an attestation mechanism should be in the actual build pipeline. I thought I could just use it to document inputs and outputs, without giving the tool the ability to compromise our build system. Is there a real advantage to letting in-toto run the whole build?

Example attestations seem to be here
https://github.com/lukpueh/tuf/releases/tag/v1.2.dev26

I thought I could just use it to document inputs and outputs, without giving the tool the ability to compromise our build system. Is there a real advantage to letting in-toto run the whole build?

No real advantage except for easier invocation maybe, and the ability to automatically record "byproducts" such as standard streams in the attestations, which I am not doing at the moment.
To record an attestation with in-toto, without having it run the command, you can do: in-toto-record start && python -m build && in-toto-record stop, which is what I also tried out at some point, while preparing this PR, because it gives better control over which materials/products should be included in the attestation: see lukpueh/tuf@release-attestations-with-record).

cc @SolidifiedRay

Heck, yes! Now I wonder if you could use TUF (e.g., PEP 480 and/or SigStore Trust Delegations) to somehow bootstrap the whole thing using TUF (pointing to in-toto metadata inside)...

We should combine efforts on this and https://github.com/in-toto/in-toto/pull/444 to get them both over the line, especially with bootstrapping in-toto metadata using TUF.

I've given this feedback verbally but maybe should do it in writing too: the core requirement for any build integrity improvement is a  verification process that can be and is used in the real world. If the verification is not easily usable and and understandable by humans, then the build integrity work may be cool but is in the end academic. This is the reason I've not made a proposal of e.g. sigstore signing yet: I could easily sign but what's the point if verification requires a crypto & certificate specialist?
The core idea of a formal way to require CD and maintainer attestations is really cool but still, I would like to see a way to easily verify at least some of this in a practically useful way before we merge... Otherwise it feels like adding a lot of new process (and code to maintain) right now for vague potential value some time in the future.

Can you say more about what you mean by "practically useful"?
When you in-toto verify something, you use a previously validated
root-of-trust to check a (potentially updated) layout file and validate
link metadata based upon the keys contained in this.  Assuming your
root-of-trust is valid, the verification process provides you cryptographic
validation that the parties with the specified keys signed link metadata
that attested to only permitted operations.
Also, FYI: this sort of validation is used in the real world now by some
organizations (e.g.,
https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/
).
On Thu, Jun 2, 2022 at 3:18 PM Jussi Kukkonen @.***>
wrote:

I've given this feedback verbally but maybe should do it in writing too:
the core requirement for any build integrity improvement is a verification
process that can be and is used in the real world. If the verification
is not easily usable and and understandable by humans, then the build
integrity work may be cool but is in the end academic. This is the reason
I've not made a proposal of e.g. sigstore signing yet: I could easily sign
but what's the point if verification requires a crypto & certificate
specialist?
The core idea of a formal way to require CD and maintainer attestations
is really cool but still, I would like to see a way to easily verify at
least some of this in a practically useful way before we merge... Otherwise
it feels like adding a lot of new process (and code to maintain) right now
for vague potential value some time in the future.
—
Reply to this email directly, view it on GitHub
https://github.com/theupdateframework/python-tuf/pull/2000#issuecomment-1144530916,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD7J7CKJ5BNN2PVAUVLVNBN25ANCNFSM5VN7XXTQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Can you say more about what you mean by "practically useful"?

What I mean is that

there is a plan for how this verification really happens -- so we don't just enable verification in theory, we ensure it happens or at least make it likely to happen. Do we have verification automation somewhere? clear instructions for contributors and users to verify?
the fairly long list of verification todo items in RELEASE_with_in-toto.md  is somehow handled -- I don't necessarily mean everything needs to be polished but I'd like to see at least a practical plan for these items

Hey just now seeing this. Yeah a build hook would work. For example, Project Jupyter & IPython are almost done switching their entire packaging ecosystem to be based on a Hatch build plugin. I tried to link to most of the changes here: https://hatch.pypa.io/latest/users/
One thing I added with all of you in mind was the extra-metadata wheel option. Basically a dedicated *.dist-info/extra_metadata/ directory to stuff whatever users might want, like signatures 😄

Converted this back to draft to be used as reference for other release signing solutions discussed in #1966, most notably wrt to UX and security properties.
python-tuf maintainers currently don't feel confident to merge because of the perceived potential for human error in the setup and the complexity of validating its correctness.


merge testing from feature/tests-refactor

Should Travis be updated in this same PR? we could still merge it in the plugin api branch and update travis there.

Maybe we should get this merged first, then enable Travis on feature/plugin-api.    Now is probably as good a time as any to do it.

I agree. Can I merge then?


Provide better experience when asserting the presence of multiple output lines in integration tests

This PR is the result of pain points encountered when writing assertions for: https://github.com/gradle/gradle/pull/19561.  Early investigations are here: https://github.com/gradle/gradle/issues/19608.
These changes cause the exception output to print only twice, and make the results of a failed test assertion much easier to interpret by suppressing Groovy's power assertions, which tend to be extremely difficult to interpret when searching for large blocks of text inside of nested structures composed of large blocks of text.
It also adds new formatting options for asserting comparisons on multiline blocks which can produce clearer output.
To see an example, in OutgoingVariantsReportTaskIntegrationTest change line 1074 to 'Elements of runtime for the main variant' and compare the current results in master, to the results in this branch after changing the assertOutputContains call to the new assertOutputContainsLines method:

The meaningful output is only duplicated once
The expected lines don't clutter the output when they match
The mismatched line(s), and their line number location(s) in the actual output is highly visible - in the the case the actual output being searched is many lines, this supports copying that output into a text editor and quickly jumping to the problem area
The differences in mismatches lines are highlighted with the JUnit comparison failure logic - within only the mismatched lines, NOT the entire output - this makes it MUCH easier to see where the problem lies
If there are multiple potential locations in a long output block that almost match (the same number of expected lines mismatch), then all the potential matches will be printed in this fashion
If an exact match exists, this should run quickly, to not slow down testing.  Upon failing to match, the performance of building this list of matches upon failure relies on some nested loops, which in practice shouldn't matter too much, unless the arguments are really tailored to make that happen, which I don't think is very likely in real-world usage.

This is accomplished by throwing exceptions which subclass SpockException, the root exception type thrown by the new ExhaustiveLinesSearcher class which powers the new search.  The new classes likely need some additional Javadoc and maybe some further cleanup, but I didn't want to do too much bikeshedding before demo-ing the approach I want to take and getting some feedback.
This change also:

Overrides toString() on intermediate types (GroupedOutputFixture and GroupedTaskFixture) to simplify output when these new methods are not used.
!Add a noPowerAssert method to AbstractIntegrationSpec for use in suppressing power assertion output in an ad-hoc manner.~ Removed, people can manually implement this method in a test if desired.
Adjusts existing test machinery in OutputScrapingTestResult to avoid duplicating gradle output upon failure more than once.
~Adds a dep on Google Truth to allow for optional git-like difference output.  This is not the default, because I think in the common case it is less readable, and it will only find a single place where the potential match might be, and it won't highlight the differences within the mismatched lines as well.~

Questions

~I needed to ignore keys in verification-metadata.xml to add the Google Truth dependency and get the build to work.  This doesn't seem right, can someone who understands this better explain what I need to do here.  Alternately, Sterling suggested just copying the entire DiffUtils class (which surprisingly doeesn't import anything else from the Truth project), so this is also an option.~ Class duplicated
~To what extent should I replace existing test code using result.groupedOutput.task(":myTask").assertOutputContains to search for big blocks of text (for example, in OutgoingVariantsReportTaskIntegrationTest) with this new method?  The expectation is that anything passing using the old method should also pass with the new method, and test run time should not be meaningfully affected.~ We don't want to change any existing expectations, or allow commits with "formatting options" for output assertions.
~Is it okay to deprecate assertOutputContains without replacing it?~ Won't do.

Additional Work

A likely common failure case is the additional or subtraction of a single missing line of text.  The alternate git unifiedDiff algorithm can provide output that is potentially more clear in this case.  I might experiment with changing PotentialMatch's output to check for this special case and display it differently, to spare the reader from having to mentally compute this.

@bot-gradle test QFL

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

I think the new output for failures is okay. I personally think it would be better to do a giant call-out so it's clear where the separation is, and add the expected lines

I originally had something like this, and after seeing it over and over when writing tests, I found myself ignoring the expected lines section and jumping right to the actual lines to find the mismatches.  I think it would be rare you would write a test that completely fails to match any of the expected lines, usually you would be looking for which lines failed.  So the expected lines are mostly visible in the actual lines, except for the mismatches, which are compressed to just the differing chars by the JUnit failure comparison highlighter.
I found this way clearer - and it has the additional benefit of less total output.  But this is exactly the sort of feedback I'm looking for here.  Let's see what the others think when they get a chance to weigh in.
I also tried an arrow at one point, and could go back to using that instead of the X I have now to indicate mismatches.  It just widened the prefix section.  If it looked like this would it be clearer?  Or was the arrow solely to divide the expected section from the actual section?
       1: a context line
[      2: a matching line
 ==>   3: a line that doesn't match
expected: <JUNIT COMPARISON>
 ==>]  4: another line that doesn't match
expected: <ANOTHER JUNIT COMPARISON```

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

The existing assertOutputContains(String... text) method's argument represented some lines which could exist in any location within the actual output - they need not be in any particular order, or be continuous - each line was the target of a separate search.
I think this is too loose of an assertion (it should have at least been javadoc-ed), and most people would expect this method to look for sequential ordered lines.  I think there's probably not much benefit to using varargs vs. making multiple calls to a (doesn't yet exist) assertOutputContains(String text) method if this is really the case.
But - this doesn't matter, because when I altered the signature to remove the vargargs from the arg and ran sanityCheck it succeeded.  When CI ran all the tests without the vargargs arg nothing actually broke.  So we're not actually relying on this behavior.
So, to try to cover the 80% usage automatically like we talked about, this method will behave the same, and report missing lines as always if a single line is provided as an arg.  If multiple lines are provided, the new multiline format will be used.  I added overloads of the assertOutputContains method which allow supplying a List rather than varargs, and also allow specifying a particular output format.  Javadocs on these methods should point to the proper usage, but if even if these docs aren't ever read, the failure methods should just work better by being more readable for the multiline case.
We talked also about ensuring that the alternate methods weren't called by making them some sort of failure at build time (with a Checkstyle rule, perhaps), but I don't think this is necessary considering we'll always be calling the same method, just different overloads to tweak the formatting.
I'm going to add a few more unit tests to confirm the output format switching, but what do you think of this so far @big-guy?

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.


Get user trade exception

I am using this methods to get list of gdax UserTrade:
public static Exchange getAuthedGDAX(String key, String secret, String passphrase) {
        Exchange gdax = ExchangeFactory.INSTANCE.createExchange(GDAXExchange.class.getName());
        ExchangeSpecification spec = gdax.getDefaultExchangeSpecification();
        spec.setApiKey(key);
        spec.setSecretKey(secret);
        spec.setExchangeSpecificParametersItem("passphrase", passphrase);
        Exchange gdx = ExchangeFactory.INSTANCE.createExchange(spec);
        return gdx;
    }

    public static List<UserTrade> getGDAXTrades(String key, String secret, String passphrase) throws IOException {
        Exchange gdx = getAuthedGDAX(key, secret, passphrase);
        TradeService ts = gdx.getTradeService();
        return ts.getTradeHistory(ts.createTradeHistoryParams()).getUserTrades();
    }

and I am getting this exception:
org.knowm.xchange.exceptions.ExchangeException: org.knowm.xchange.gdax.dto.GDAXException: query must contained either product_id or order_id (HTTP status code: 400)
this code worked 2 weeks ago, and now I am getting exception.

Thank you for interesting to help, in the meantime I founded the solution.
First gdax is deprecated and migrated to xchange-coinbasepro.
The solution is, like you mentioned, to pass CurrencyPair as param or order_id as well:
`List pairs = fetchUserPairs(gdx);
CoinbaseProTradeServiceRaw.GdaxTradeHistoryParams params;
List trades = new ArrayList<>();
for (CurrencyPair pair : pairs) {
params = new CoinbaseProTradeServiceRaw.GdaxTradeHistoryParams();
params.setCurrencyPair(pair);
            List<UserTrade> helpTrades = ts.getTradeHistory(params).getUserTrades();
            if (helpTrades.size() > 0)
                trades.addAll(helpTrades);

}`

make sure you're using the coinbasePro module from here on out.


Create portuguese translation

This is a PR to translate the NEAR Wallet to Portuguese.

@murilooon Could I help you on that?
How can we coordinate a async translate process?

You can clone this repository by the guild fork, them checkout to this branch and push the translation commits here. I think it's possible this way, not sure...

Hi there!
On past weeks we (@murilooon @kammradt and me) coordinate a "test drive" translate process using Crowdin
Was a very positive experience, we've translated around 80% and those string were commited on this branch.

Any suggestion or question, please contact me
:)

Just finished the translations. Also, updated with master and english current json file. :wink:

Just finished the translations. Also, updated with master and english current json file. 😉

Major props to everyone that has contributed to this!
@murilooon it seems that tests are failing after the last commit. Can you please take a look?

Just finished the translations. Also, updated with master and english current json file. wink

Major props to everyone that has contributed to this!
@murilooon it seems that tests are failing after the last commit. Can you please take a look?

All the commits broke the CI. Something about sentry and an ENV.

Maybe because this is a branch created from the forked repo?

Maybe because this is a branch created from the forked repo?

It's just because forked repo, ignore error


Add Croc

Project URL
github.com/jkalash/croc
Category
Text
Description
Added Croc Emoji parsing library to the set of Text emojis
Why it should be included to awesome-ios (optional)
List lacks Swift 4.0 recent support for Unicode 11.0 Emoji parsing. Croc does the job
Checklist

[x ] Only one project/change is in this pull request
[ x] Addition in chronological order (bottom of category)
[ x] Supports iOS 9 / tvOS 10 or later
[ x] Supports Swift 4 or later
[ x] Has a commit from less than 2 years ago
[ x] Has a clear README in English

          2 Warnings

:warning:
Too many changes (when adding, please keep it to one project per Pull Request)

:warning:
Found 2 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

254
301
https://github.com/alfa-laboratory/YARCH-Examples redirects tohttps://github.com/alfa-laboratory/YARCH

2724
301
https://github.com/JetpackSwift/FrameworkTemplate redirects tohttps://github.com/RahulKatariya/FrameworkTemplate

  Generated by :no_entry_sign: Danger

Thanks for contributing, @JKalash 👍


Release Google.Cloud.Compute.V1 version 2.15.0

Changes in this release:
New features

Change netstandard2.1 target to netstandard2.0 (commit 82bea85)

Created release for Google.Cloud.Compute.V1-2.15.0


"Application error: a client-side exception has occurred" when searching for templates

Describe the Problem
When searching for templates on the submit a combo page, an unhandled Application error is thrown.
The crash does not seem to occur on any search that would not yield a result.
Browser and Operating System Information
Firefox 119.01 (64-bit)
Windows 10 Pro N, Version 22H2, Build 19045.3693
Steps to Reproduce
Add a template by clicking the "Add a template" button
In the "Template Name:" box, type in three characters that would yield a valid search result

Web console log of the error
console-export-2023-11-21_11-53-8.txt


The error is not clear when failed to run the lsp server as a child process

Version: 4200ed
Minimum reproducible steps

# gopls should not be in $PATH
cargo run -- gopls

If something bad happens during running the lsp server, e.g. the lsp server is not in $PATH, the backtrace looks like this:
[2024-11-27T12:18:36Z INFO  emacs_lsp_booster::app] Running server "gopls"
[2024-11-27T12:18:36Z INFO  emacs_lsp_booster::app] Will convert server json to bytecode! bytecode options: BytecodeOptions { object_type: Plist, null_value: Nil, false_value: Nil }
Error: No such file or directory (os error 2)

Stack backtrace:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/backtrace.rs:331:13
   3: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
   4: emacs_lsp_booster::app::run_app_forever
   5: emacs_lsp_booster::main
   6: std::sys_common::backtrace::__rust_begin_short_backtrace
   7: std::rt::lang_start::{{closure}}
   8: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:284:13
   9: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  10: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  11: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  12: std::rt::lang_start_internal::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:48
  13: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  14: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  15: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  16: std::rt::lang_start_internal
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:20
  17: _main

It isn't obvious what went wrong, and we don't even know which line in emacs_lsp_booster::app::run_app_forever specifically is the culprit.
The fix is easy. Simply attach a context with <anyhow::Result as anyhow::Context>::with_context method.
Afterwards, the error looks like this:
[2024-11-27T12:29:25Z INFO  emacs_lsp_booster::app] About to run the lsp server with command "gopls"
[2024-11-27T12:29:25Z INFO  emacs_lsp_booster::app] Will convert server json to bytecode! bytecode options: BytecodeOptions { object_type: Plist, null_value: Nil, false_value: Nil }
Error: Failed to run the lsp server with command: "gopls"

Caused by:
    No such file or directory (os error 2)

Stack backtrace:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/backtrace.rs:331:13
   3: <E as anyhow::context::ext::StdError>::ext_context
             at /Users/zino/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.78/src/context.rs:27:29
   4: anyhow::context::<impl anyhow::Context<T,E> for core::result::Result<T,E>>::with_context
             at /Users/zino/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.78/src/context.rs:65:31
   5: emacs_lsp_booster::app::run_app_forever
             at ./src/app.rs:110:20
   6: emacs_lsp_booster::main
             at ./src/main.rs:76:23
   7: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
   8: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:155:18
   9: std::rt::lang_start::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:166:18
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:284:13
  11: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  12: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  13: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  14: std::rt::lang_start_internal::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:48
  15: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  16: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  17: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  18: std::rt::lang_start_internal
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:20
  19: std::rt::lang_start
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:165:17
  20: _main

By the way, do you use a .rustfmt.toml locally? The code is not formatted by rustfmt, so when I save the file and the auto-formatting tool is run, the changes are all over the place. Just my opinion that if the code is correctly formatted, it will be easier for others to contribute to this project :). Do you mind formatting the code or accepting a PR that does the formatting? I am ok to create such a PR :).
Thx for your great project!

Thanks for your reply. As someone often annoyed by Go's dogmatic code formatting, I totally understand your choice :).


Adds command pa app permission ensure, Closes #4651

Closes #4651

Thank you, will review ASAP!

Merged manually, great work adding this command!


Initialize containers step consistently takes around ~14 minutes to complete (no image pull issues)

Hey there,
Just looking for a bit of a pointer here, and to ask whether you've seen this behaviour before.
One of my customers is an early adopter of EKS-Anywhere (v1.23.15-eks-69f0cbf with CRI-O + containerd), currently on vSphere 7.x, and they have containerMode: kubernetes somewhat working using a RunnerDeployment on the current releast of ARC (v0.27.4), the runner is v2.304.0 runner image. Hooks is 0.3.2. The job container image is ubi8/ubi-minimal:8.8 The "somewhat" part is that every job, no matter the size of the job container, takes almost exactly 14 minutes to get past the Initialize containers step within the workflow, but then does go on to succeed very swiftly (just a "hello world" step next). It's perhaps prudent to note that this is their first attempt at using ARC on this cluster at all; it's still a PoC for them.
The RunnerDeployment's  imagePullPolicy is IfNotPresent, and in the case where it's not, I've debugged this on the nodes themselves, and I see in tcpdump that a connection to their Artifact store isn't actually attempted until ~14 minutes elapses. In the case where the image is already present, of course no pull is attempted, but the same duration elapses before the job ultimately succeeds.
The (two) k8s worker nodes have previously been 2 vCPU and 8 GB, so I bumped resources to 8 vCPU and 32GB, and there has been no change in outcome.. I still see no evidence on the nodes or otherwise that a resource shortfall is in play here.
The CSI I am using is NetApp Trident, and PVCs get an PV and go bound within a few seconds - no issues there.
Here is a redacted shot of a typical workflow. I can confirm that the image - pulled manually on the worker nodes - does indeed pull down within a few seconds (time crictl pull ...), so I am not convinced this is a network issue.
The screenshot doesn't show it, but line 10 (##[debug]/home/runner/externals/node16/bin/node /runner/k8s/index.js) is where the 14 mins is spent - see further for the raw log counterpart which does show it.
f
Here is the raw log excerpt which shows the ~14m delay between the stages:
2023-06-04T12:41:59.4349638Z Complete job name: initial-test-job
2023-06-04T12:41:59.4371584Z ##[debug]Collect running processes for tracking orphan processes.
2023-06-04T12:41:59.4577813Z ##[debug]Finishing: Set up job
2023-06-04T12:41:59.4866818Z ##[debug]Evaluating condition for step: 'Initialize containers'
2023-06-04T12:41:59.4915702Z ##[debug]Evaluating: success()
2023-06-04T12:41:59.4918032Z ##[debug]Evaluating success:
2023-06-04T12:41:59.4934400Z ##[debug]=> true
2023-06-04T12:41:59.4938501Z ##[debug]Result: true
2023-06-04T12:41:59.4964191Z ##[debug]Starting: Initialize containers
2023-06-04T12:41:59.5069467Z ##[debug]Register post job cleanup for stopping/deleting containers.
2023-06-04T12:41:59.6496794Z ##[group]Run '/runner/k8s/index.js'
2023-06-04T12:41:59.6500884Z shell: /home/runner/externals/node16/bin/node {0}
2023-06-04T12:41:59.6501243Z ##[endgroup]
2023-06-04T12:41:59.8054336Z ##[debug]/home/runner/externals/node16/bin/node /runner/k8s/index.js

< --- note timestamps - all the time spent here --- >

2023-06-04T12:55:23.4137069Z ##[debug]Using image '[XXXXXXXX.jfrog.io/docker/ubi8/ubi:8.8](http://xxxxxxxx.jfrog.io/docker/ubi8/ubi:8.8)' for job image
2023-06-04T12:55:23.4546632Z ##[debug]Job pod created, waiting for it to come online actions-runner-XXXXXX-actions-runner-deployment-fs-workflow
2023-06-04T12:55:54.5558565Z ##[debug]Job pod is ready for traffic
...

The processes on the runner themselves are sleeping during this time, and strace (outpt not included for brevity's sake) shows a typical non-blocking I/O cycle of sleep, wake, check futex, yield and go back to sleep. See runner processes sleeping - a state they remain for almost the entire 14m period:
runner@actions-runner-XXXXXX-actions-runner-deployment-lhbgp-2xxrg:/$ ps auxww
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
runner         1  0.0  0.0   4492  3260 ?        Ss   13:51   0:00 /bin/bash /usr/bin/entrypoint.sh
runner         7  0.0  0.0    224     4 ?        S    13:51   0:00 dumb-init bash
runner        10  0.0  0.0   4360  3288 ?        Ss   13:51   0:00 bash
runner        11  0.0  0.0   4360  3316 ?        S    13:51   0:00 /bin/bash ./run.sh
runner        99  0.0  0.0   4360  3372 ?        S    13:51   0:00 /bin/bash /runner/run-helper.sh
runner       103  0.4  0.3 13753912 101952 ?     Sl   13:51   0:02 /runner/bin/Runner.Listener run
runner       120  0.7  0.3 13750300 107344 ?     Sl   13:51   0:04 /runner/bin/Runner.Worker spawnclient 106 109
runner       158  1.0  0.2<PHONE_NUMBER>0 ?        Sl   13:52   0:06 /runner/externals/node16/bin/node /runner/k8s/index.js
runner       235  0.3  0.0   4624  3776 pts/0    Ss   14:03   0:00 bash
runner       242  0.0  0.0   7064  1612 pts/0    R+   14:03   0:00 ps auxww
runner@actions-runner-XXXXXX-actions-runner-deployment-lhbgp-2xxrg:/$

As mentioned, as soon as the 14 min has elapsed, the workflow pod comes up within seconds, and the job moves on to successful completion.
Thanks for any pointers or ideas!

Extra context in case it''s helpful.
During the "wait" period, the runner logs are effectively spinning on the following:
[WORKER 2023-06-04 15:11:59Z INFO HostContext] Well known directory 'Bin': '/home/runner/bin'
[WORKER 2023-06-04 15:11:59Z INFO HostContext] Well known directory 'Root': '/home/runner'
[WORKER 2023-06-04 15:11:59Z INFO HostContext] Well known directory 'Work': '/runner/_work'
[RUNNER 2023-06-04 15:12:02Z INFO JobDispatcher] Successfully renew job request 59, job is valid till 06/04/2023 15:22:02
[WORKER 2023-06-04 15:12:09Z INFO HostContext] Well known directory 'Bin': '/home/runner/bin'
[WORKER 2023-06-04 15:12:09Z INFO HostContext] Well known directory 'Root': '/home/runner'
[WORKER 2023-06-04 15:12:09Z INFO HostContext] Well known directory 'Work': '/runner/_work'
[WORKER 2023-06-04 15:12:19Z INFO HostContext] Well known directory 'Bin': '/home/runner/bin'
[WORKER 2023-06-04 15:12:19Z INFO HostContext] Well known directory 'Root': '/home/runner'
[WORKER 2023-06-04 15:12:19Z INFO HostContext] Well known directory 'Work': '/runner/_work'
[WORKER 2023-06-04 15:12:29Z INFO HostContext] Well known directory 'Bin': '/home/runner/bin'
[WORKER 2023-06-04 15:12:29Z INFO HostContext] Well known directory 'Root': '/home/runner'
[WORKER 2023-06-04 15:12:29Z INFO HostContext] Well known directory 'Work': '/runner/_work'
[WORKER 2023-06-04 15:12:39Z INFO HostContext] Well known directory 'Bin': '/home/runner/bin'
...

.. before the time is up and the rest of the process continues:
...
[WORKER 2023-06-04 15:15:29Z INFO HostContext] Well known directory 'Root': '/home/runner'
[WORKER 2023-06-04 15:15:29Z INFO HostContext] Well known directory 'Work': '/runner/_work'
[WORKER 2023-06-04 15:15:31Z INFO JobServerQueue] Try to append 1 batches web console lines for record '1ab5e0cd-4ace-4d35-b32b-2935204705d0', success rate: 1/1.
[WORKER 2023-06-04 15:15:34Z INFO ProcessInvokerWrapper] STDOUT/STDERR stream read finished.
[WORKER 2023-06-04 15:15:34Z INFO ProcessInvokerWrapper] STDOUT/STDERR stream read finished.
[WORKER 2023-06-04 15:15:34Z INFO ProcessInvokerWrapper] Finished process 130 with exit code 0, and elapsed time 00:13:45.5155178.
[WORKER 2023-06-04 15:15:34Z INFO JobServerQueue] Try to append 1 batches web console lines for record '1ab5e0cd-4ace-4d35-b32b-2935204705d0', success rate: 1/1.
[WORKER 2023-06-04 15:15:34Z INFO ContainerHookManager] Response file for the hook script at '/runner/k8s/index.js' running command 'PrepareJob' was processed successfully
[WORKER 2023-06-04 15:15:34Z INFO ContainerHookManager] Response file for the hook script at '/runner/k8s/index.js' running command 'PrepareJob' was deleted successfully
[WORKER 2023-06-04 15:15:34Z INFO ContainerHookManager] Global variable 'ContainerHookState' updated successfully for 'PrepareJob' with data found in 'state' property of the response file.
[WORKER 2023-06-04 15:15:34Z INFO StepsRunner] Step result:
[WORKER 2023-06-04 15:15:34Z INFO ExecutionContext] Publish step telemetry for current step {
[WORKER 2023-06-04 15:15:34Z INFO ExecutionContext]   "action": "Pre Job Hook",
...

Hey @cloudbustinguk
Can you please post the output of kubectl describe on the job pod? I would imagine image pull not causing issues since it is done by the kubelet. From the debug log, what I have noticed is that the alpine check has exit code 1. We need that check to know if we need to mount node for alpine. That is something causing this issue. I'll try reproducing it using this image, but in the meantime, maybe kubectl describe can be helpful to see what stages did the job pod go through

Hey @cloudbustinguk
Can you please post the output of kubectl describe on the job pod? I would imagine image pull not causing issues since it is done by the kubelet. From the debug log, what I have noticed is that the alpine check has exit code 1. We need that check to know if we need to mount node for alpine. That is something causing this issue. I'll try reproducing it using this image, but in the meantime, maybe kubectl describe can be helpful to see what stages did the job pod go through

Hi @nikola-jokic ,
Many thanks for getting back to me. I include below both the runner pod and the eventual (after ~14m) workload/job pod.
Please let me know if you need anything else.
Cheers

Runner Pod
Name:         actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9
Namespace:    github-actions-runners-eksa-XXXXXX
Priority:     0
Node:         eks-a-node-1-workload1-md-0-85884886c9-q9j6q.dev.YYYYYYYY.com/<IP_ADDRESS>
Start Time:   Tue, 13 Jun 2023 16:59:39 +0000
Labels:       actions-runner=
      actions-runner-controller/inject-registration-token=true
      app.kubernetes.io/instance=actions-runner-XXXXXX
      app.kubernetes.io/name=actions-runner-deployment
      pod-template-hash=9fd7b8dc
      runner-deployment-name=actions-runner-XXXXXX-actions-runner-deployment
      runner-template-hash=5c57dd9bfc
Annotations:  actions-runner/github-api-creds-secret: actions-runner-XXXXXX
      actions-runner/id: 106
      sync-time: 2023-06-13T16:59:35Z
Status:       Running
IP:           <IP_ADDRESS>
IPs:
IP:           <IP_ADDRESS>
Controlled By:  Runner/actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9
Containers:
runner:
Container ID:   containerd://59cc7f8b66dc52ac02416a99a5409afe091da922276a1abea209db0943ed7f61
Image:          YYYYYYYY.jfrog.io/docker/custom-k8s-actions-runner:1.0.12
Image ID:       YYYYYYYY.jfrog.io/docker/custom-k8s-actions-runner@sha256:cd92d3c03ee945b845a48c049791fcb7a01a06157fa67a1df2fcf0336baa6bec
Port:           <none>
Host Port:      <none>
State:          Running
Started:      Tue, 13 Jun 2023 16:59:48 +0000
Ready:          True
Restart Count:  0
Limits:
cpu:     2
memory:  4Gi
Requests:
cpu:     2
memory:  4Gi
Environment:
RUNNER_ORG:
RUNNER_REPO:                             XXXXXX/somerepo
RUNNER_ENTERPRISE:
RUNNER_LABELS:                           self-hosted,XXXXXX
RUNNER_GROUP:                            Default
DOCKER_ENABLED:                          false
DOCKERD_IN_RUNNER:                       false
GITHUB_URL:                              https://github.YYYYYYYY.com/
RUNNER_WORKDIR:                          /runner/_work
RUNNER_EPHEMERAL:                        true
RUNNER_STATUS_UPDATE_HOOK:               true
GITHUB_ACTIONS_RUNNER_EXTRA_USER_AGENT:  actions-runner-controller/v0.27.4
ACTIONS_RUNNER_CONTAINER_HOOKS:          /runner/k8s/index.js
ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER:    true
ACTIONS_RUNNER_POD_NAME:                 actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9 (v1:metadata.name)
ACTIONS_RUNNER_JOB_NAMESPACE:            github-actions-runners-eksa-XXXXXX (v1:metadata.namespace)
ACTIONS_RUNNER_REQUIRE_SAME_NODE:        true
RUNNER_NAME:                             actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9
RUNNER_TOKEN:                            REDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTED
Mounts:
/gpfs/CCCC-eksa-dev from CCCC-eksa-dev (ro)
/runner from runner (rw)
/runner/_work from work (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-6m2nf (ro)
Conditions:
Type              Status
Initialized       True
Ready             True
ContainersReady   True
PodScheduled      True
Volumes:
work:
Type:          EphemeralVolume (an inline specification for a volume that gets created and deleted with the pod)
StorageClass:  netapp-CCCC-ontap-nas-economy
Volume:
Labels:            <none>
Annotations:       <none>
Capacity:
Access Modes:
VolumeMode:    Filesystem
runner:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:  <unset>
CCCC-eksa-dev:
Type:          HostPath (bare host directory volume)
Path:          /gpfs/CCCC-eksa-dev
HostPathType:
kube-api-access-6m2nf:
Type:                    Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds:  3607
ConfigMapName:           kube-root-ca.crt
ConfigMapOptional:       <nil>
DownwardAPI:             true
QoS Class:                   Guaranteed
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                     node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type     Reason                  Age   From                     Message
----     ------                  ----  ----                     -------
Warning  FailedScheduling        13m   default-scheduler        0/4 nodes are available: 4 waiting for ephemeral volume controller to create the persistentvolumeclaim "actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9-work".
Warning  FailedScheduling        13m   default-scheduler        0/4 nodes are available: 4 pod has unbound immediate PersistentVolumeClaims.
Normal   Scheduled               13m   default-scheduler        Successfully assigned github-actions-runners-eksa-XXXXXX/actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9 to eks-a-node-1-workload1-md-0-85884886c9-q9j6q.dev.YYYYYYYY.com
  Normal   SuccessfulAttachVolume  13m   attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-bcca1b33-9b52-472e-b893-989b52c9068e"
  Normal   Pulled                  13m   kubelet                  Container image "YYYYYYYY.jfrog.io/docker/custom-k8s-actions-runner:1.0.12" already present on machine
  Normal   Created                 13m   kubelet                  Created container runner
  Normal   Started                 13m   kubelet                  Started container runner

Workload Pod
Name:         actions-runner-XXXXXX-actions-runner-deployment-7h-workflow
Namespace:    github-actions-runners-eksa-XXXXXX
Priority:     0
Node:         eks-a-node-1-workload1-md-0-85884886c9-q9j6q.dev.YYYYYYYY.com/<IP_ADDRESS>
Start Time:   Tue, 13 Jun 2023 17:24:47 +0000
Labels:       runner-pod=actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9
Annotations:  <none>
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:  <IP_ADDRESS>
Containers:
  job:
    Container ID:  containerd://18687bc551a95d9619adb720703ed2d5d9c8b5032700c6d32e86c7c5bca81159
    Image:         YYYYYYYY.jfrog.io/docker/ubi8/ubi:8.8
    Image ID:      YYYYYYYY.jfrog.io/docker/ubi8/ubi@sha256:a7143118671dfc61aca46e8ab9e488500495a3c4c73a69577ca9386564614c13
    Port:          <none>
    Host Port:     <none>
    Command:
      tail
    Args:
      -f
      /dev/null
    State:          Running
      Started:      Tue, 13 Jun 2023 17:24:49 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /__e from work (rw,path="externals")
      /__w from work (rw)
      /github/home from work (rw,path="_temp/_github_home")
      /github/workflow from work (rw,path="_temp/_github_workflow")
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-8xfbc (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  work:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  actions-runner-XXXXXX-actions-runner-deployment-7hjrn-dwhk9-work
    ReadOnly:   false
  kube-api-access-8xfbc:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason   Age   From     Message
  ----    ------   ----  ----     -------
  Normal  Pulled   26s   kubelet  Container image "YYYYYYYY.jfrog.io/docker/ubi8/ubi:8.8" already present on machine
  Normal  Created  25s   kubelet  Created container job
  Normal  Started  25s   kubelet  Started container job

I think you have a huge delay in the k8be scheduler.
Based on your output, it is really a cluster issue. The persistent volume could not be created on that node for 13 minutes, and after 13 minutes, the volume is attached. Only then the action executes within a minute.
It seems to me that the scheduler could not find the node where this volume mount can be attached and once it does, the action executes quickly

I think you have a huge delay in the k8be scheduler. Based on your output, it is really a cluster issue. The persistent volume could not be created on that node for 13 minutes, and after 13 minutes, the volume is attached. Only then the action executes within a minute. It seems to me that the scheduler could not find the node where this volume mount can be attached and once it does, the action executes quickly

From what I can see, this isn't the case. The 13m is a very unfortunate coincidence here, but all of those events mentioned occurred at the same time (which was about 13 minutes between deploying the runner itself, and me actually manually starting the Actions workflow... my apologies for the confusion!). The relative timestamp here is to be interpreted as "13 mins ago".
The sequence as far as I understand it, and have just tested again to confirm:

Scheduler waits for CSI to bind PVC / make PV (recent attempt takes a few seconds)
PV is bound and Pod can now be assigned to node (few seconds)
Volume gets attached (effectively instantaenous after step 2)
Container gets created (effectively instant ...)
Container starts (effectively instant ...)

If I've somehow missed the point, do let me know, but I still maintain that the issue is as before.

Oh, I see... my bad...
I'll let you know as soon as I'm able to reproduce it.

@nikola-jokic Thanks for your patience. I've switched the storageClass away from NetApp (which I found out has spinning disk, and despite having flashcache and tuning NFS to avoid too much metadata / file I/O overhead) to GPFS, and this problem completely disappeared.
As you and I discussed directly over mail, the main issue here is that the externals step sets up different versions of node, and this results in a storm of small file I/O (which is anathema to NFS performance). As NetApp Trident CSI is more and more prevalent these days (especially for on-prem k8s solutions), this is going to be a sensitivity unless the NetApp is SSD-based or so (even then, small file I/O will present a challenge depending on the use case).
Hope this helps future users, and I thank you for your time and support!

@cloudbustinguk
Quick question, if I may - how did you get the runner to output the debug logging? I am facing an identical 14 min problem on AKS with PVC set to blob. I would like to debug my runners but so far has failed to get the same output as you have shown in the screenshot

@cloudbustinguk Quick question, if I may - how did you get the runner to output the debug logging? I am facing an identical 14 min problem on AKS with PVC set to blob. I would like to debug my runners but so far has failed to get the same output as you have shown in the screenshot

Hey there @nixlim! If you mean the first screenshot of the actions job, then when you click Re-run all jobs in an already-run-job summary page, you have the checkbox for Enable debug logging. The next set of screenshots are effectively those logs, but either downloaded from the cog wheel inside the job/steps view, or from the self-hosted runner directory (in our case).
In your case with the blob storage, it's likely the IOPS are too low, given the amount off node modules which get unpacked. Is it in scope for you to add a disk/SSD-based StorageClass and try it out?

Awesome! Thank you - this entire post and your work has solved 5 days of OCD "Why does it take so long" for me - 🙇🏻♂
Yeah, we switched from Azure NFS to Fuse that brought the time down to 3-4 minutes. We could switch to Disk as well, although I am not 100% sure whether it would bring down the time any more.

For anyone looking into this and working with AKS - we have solved the time delay issue by customising the hook (with, among other things, removing the copying of externals at the hook initialisation level) and then baking in externals both into the image for the workflow pod and the runner pod. This has allowed us to arrive at a scalable solution - pods now take seconds to get the job up and running.

We are experiencing exactly the same issue, but with EKS EFS.
The pod initialization is taking about 3-4 minutes, with no hints in the logs available on the runner on what is exactly happening during that time.
Once workflow pod is created, the execution takes seconds to complete.
@nixlim can you share your modified hook templates and what are the externals you moved to the runner, please?

@anlesk
Hey!
So, basically what is happening is that it is copying /externals directory to the workflow pod - that is Node16 and Node20. There are huge-ish and obviously you are copying over the network since it is actually copying to the PVC (mounted as a volume on both runner and job/workflow pod).
So, what we did:

From the hook implementation we removed the copyExternals command - we simplified the Typescript code for the hook, removed the bunch of stuff we didn't need and then build our own Typescript compilation of the hook. That is part of the modified runner image we use.
We copied the /externals directory from the runner image to the image we use to build workflow pod and provided the volumeMounts and volumes pointing to that location. The path is kept the same as in the original runner but now it comes with the content already baked in.
So now the /externals directory is baked into the image  and does not need to be copied - it takes seconds to initialise.

Unfortunately, I cannot provide the actual code - I will get fired :)


Errors do not always show sufficient context

There are cases where rustfmt's call to fs::metadata() will fail
(due to permissions) and panic. For example, an ancestor directory or the home directory may exist but
the user may not have permissions to list the contents of the directory.
Example on a Linux system where the user cannot read the home directory:
$ ls -ld /opt/root-only
drwx------ - root 2022-01-19 15:26 /opt/root-only/

$ HOME=/opt/root-only rustfmt --check /dev/null
Permission denied (os error 13)

Ideally, the error above should show more context about what file could not be opened, why the file was opened (to find config), etc.
(Issue originally noted in PR #5178)

Thank you for opening this. I have two questions/asks:

You've mentioned panics in a couple places, but from the output you've shared, I'm only seeing errors; not panics. Is there some scenario where you're actually seeing a true panic, and if so, could you please open a separate issue with a minimal repro? If not, let's update the description as exiting with an error (regardless of how good/bad the message is) is quite different than panicking
Could you please make the scope more specific and concrete? As originally reported, the issue is rather vague and high level. Yes, it includes on example, but implies others, and that ambiguity makes tracking the issue more challenging than it needs to be (i.e. how does one know when it is resolved?)

@calebcartwright I reworded the title/description of the issue. Hopefully it's more clear. There was never a panic--only an exit on error.
At least in the error path described, the error message is just confusing--it does not indicate what attempted action lead to "permission denied".

Going to close this as #5207 addressed this issue


Couldn’t find a stream for this anime

Every anime I play, it shows the message that "couldn’t find a stream for this anime" though all the anime is playing well.
please add pip mode in player.
Great app.

Aight will have a look into that.


fix for https://github.com/adafruit/circuitpython/issues/4956

now does differnet htings for pre-7!

.. can the lib constructor take in rotation (default: rotation=0) and in the 7.0+ case use (rotation + 90) % 360?

.. can the lib constructor take in rotation (default: rotation=0) and in the 7.0+ case use (rotation + 90) % 360?

i could if you prefer that?

ok FYI @makermelissa i dont know we support this oled but we may have to tweak this if we do

If it's the same OLED as the one in https://www.adafruit.com/product/4650, then I think we do support it.


LVT Cannot compile: Symbol has no implicit type

Hi Devs,
I am trying to compile LVT (I have LDT and LIS compile just fine) and am using the mpicc and mpif90 compilers for this. I got past the huge module compilation for LDT by using a beefier machine and setting optimization level to 0. However, I am stuck at the following error, as I am not very familiar with fortran.
`Compiling LVT
[INFO] Compiling LVT source code
/usr/bin/mpif90 -c -pass-exit-codes -ffree-line-length-0 -O0  -fbacktrace  -fconvert=big-endian -DHIDE_SHR_MSG -DNO_SHR_VMATH -DGFORTRAN -DHIDE_MPI -I/sandbox/esmf/install/mod  -I/usr/local/include/ -I/sandbox/netcdf-c/4.7.3/install/include/  -I/usr/local/include/  -I/usr/local/include/  -I./ -I../core/ ../datastreams/SMAPTB/readSMAPTBobs.F90
../datastreams/SMAPTB/readSMAPTBobs.F90:351:9:
351 |      do c=1,LVT_rc%lnc
|         1
Error: Symbol 'c' at (1) has no IMPLICIT type
../datastreams/SMAPTB/readSMAPTBobs.F90:350:6:
350 |   do r=1,LVT_rc%lnr
|      1
Error: Symbol 'r' at (1) has no IMPLICIT type
make: *** [Makefile:108: readSMAPTBobs.o] Error 1
[ERR] Compile failed
`
I've attached my configure.lvt file as well. As far as my understanding goes, this is an issue with the fortran code and maybe some of the right header files are missing, but it could also be an issue with my environment.
Any help is appreciated.
configure.lvt.txt

Hi @rfun 👋 ,
Thanks opening this issue! It looks like this error is due to the variables r and c being defined within an if block that begins at line 134 (#if (defined USE_HDF5)) and ends just before the code that causes the error you reported. The code within the if statement is only run if HDF5 is installed and enabled, which it does not appear to be based on the configure.lvt file you provided. These variables therefore surprise the compiler when it skips that if statement.
I recommend installing HDF5 (if you have not done so already) and selecting the HDF5 option when configuring LVT prior to compiling.
@sujayvkumar: Should the code beginning at line 350 be placed inside the #if (defined USE_HDF5) block?

Makes sense. I had purposely left hdf5 out for now, as I wanted everything to work with hdf4 first. But this makes sense. I will try it with hdf5 and update this issue. Thanks so much

@bmcandr
Yes, including HDF5 solves this. The only suggestion here would be to ensure that the specific code is run only for hdf5 included installations since the build docs don't list hdf5 as a required dependency but more of an optional thing. I am okay if you would like to close this issue as well.

@bmcandr -I am good with the suggested code change.


Unit tests and some bug fixes

Implements #99
Improves #19
And possibly fixes #33

I'm writing missing test for normalize and this came out:
>>> a
Profile([[ 1,  1],
       [ 2, 20],
       [ 3, 40]])
>>> a.normalize(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ant6/.virtualenvs/in_beprof3/lib/python3.4/site-packages/beprof/profile.py", line 150, in normalize
    self.y /= ave
TypeError: ufunc 'true_divide' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''
>>> ave = np.average(a.y[np.fabs(a.x) <= 0])
>>> ave
nan
>>> a /= ave
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ufunc 'true_divide' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''

Our method looks like this:
    def normalize(self, dt):
        """
        Normalize to 1 over [-dt, +dt] area
        :param dt:
        :return:
        """
        logger.info('Running {0}.normalize(dt={1})'.format(self.__class__, dt))
        try:
            ave = np.average(self.y[np.fabs(self.x) <= dt])
        except RuntimeWarning as e:
            logger.error('in normalize(). self class is {0}, dt={1}'.format(self.__class__, dt))
            raise Exception("Scaling factor error:\n" + str(e))
        self.y /= ave  # <-- extra try-except?

So it's not idiot-proof enough.

It's something with division...
>>> a
Profile([[ 1,  1],
       [ 2, 20],
       [ 3, 40]])
>>> ave = np.average(a.y[np.fabs(a.x) <= 10])
>>> ave
20.333333333333332
>>> a.y /= ave
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ufunc 'true_divide' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''

@grzanka that's sad:
>>> import numpy as np
>>> a = np.array([1,2,3])
>>> b = 2.0
>>> a /= b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ufunc 'true_divide' output (typecode 'd') could not be coerced to provided output parameter (typecode 'l') according to the casting rule ''same_kind''

More here: https://github.com/nipy/dipy/issues/730/

In other words - Profile.y data has to be floats or it errors...

Current coverage is 49.80% (diff: 75.00%)

Merging #110 into master will increase coverage by 7.76%

@@             master       #110   diff @@
==========================================
  Files             5          5
  Lines           502        502
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            211        250    +39
+ Misses          291        252    -39
  Partials          0          0

Powered by Codecov. Last update 298c6d6...1ec3023

@grzanka I think, we can now change required version of numpy in setup.py to 1.8.0?

Yes, change it please

@grzanka ready for re-review


Always navigate up on createTeam from teams tab

This fixes the bug where nothing happens.

r? @keybase/react-hackers


How to advertise library's regular community meetings?

Hi, I'd like to advertise xarray's recurring public dev calls on the scientific python website, but it's not clear to me where they should go. Is there a collective calendar somewhere?

https://scientific-python.org/calendars/

Here is an example PR: https://github.com/scientific-python/scientific-python.org/pull/266


Speedup interceptor by using cached rules

As the title says, will speed up access through the geoserver.action / interceptor by caching the rules that get requested most often.
Speedup is roughly ~300ms decrease per single request.
@devs please review

Thanks for review!


fixFix the old version of the materialized view error 'Current database is not set'`

cause by: https://github.com/apache/doris/pull/36543
after 36543,not need set db&catalog in ConnectContext, because query sql Because the query statement was rewritten to the full path (ctl.db. table. col) during creation,
but query sql of old materialized view not was rewritten, so need set db&catalog in ConnectContext

run buildall

run buildall


Add dependabot for actions

Closes #36

The dependabot.yml file is as per this example, with a couple of optional properties chosen from here.
@KasiaKoz I've added you as a Dependabot PR reviewer - shout if that's not okay 😄 .
@brynpickering Should we add anybody else as a reviewer?

Looks good, except there is a warning in the build, do we want to fix that before merging?

The following actions use a deprecated Node.js version and will be forced to run on node20: asdf-vm/actions/install@v2. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

I saw that warning, and I don't want to address it, @KasiaKoz. I want to use it as a test. Dependabot should detect it the first time it runs on schedule and create a PR to upgrade that action, with the three of us as reviewers 🤞.

I want to use it as a test. Dependabot should detect it the first time it runs on schedule and create a PR to upgrade that action, with the three of us as reviewers 🤞.

Smort ✨