[QUESTION] longhorn-manager pods in CrashLoopBackOff state and longhorn-uninstall pods in Error state

Question

Environment

Longhorn version: 1.6.1.

Kubernetes version:
root@k8s-eu-1-control-plane-node-1:~# kubectl version
Client Version: v1.28.8
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.8

Node config

OS type and version : Ubuntu 22.04
Kernel version :
root@k8s-eu-1-control-plane-node-1:~# uname -r
5.15.0-102-generic
CPU per node:
Memory per node:
Disk type
Network bandwidth and latency between the nodes

root@k8s-eu-1-control-plane-node-1:~# kubectl get nodes
NAME                            STATUS   ROLES           AGE    VERSION
k8s-eu-1-control-plane-node-1   Ready    control-plane   2d1h   v1.28.8
k8s-eu-1-control-plane-node-2   Ready    control-plane   2d     v1.28.8
k8s-eu-1-control-plane-node-3   Ready    control-plane   2d     v1.28.8
k8s-eu-1-worker-1               Ready              2d     v1.28.8
k8s-eu-1-worker-2               Ready              47h    v1.28.8
k8s-eu-1-worker-3               Ready              47h    v1.28.8
k8s-eu-1-worker-4               Ready              47h    v1.28.8
k8s-eu-1-control-plane-node-1/2/3 +  k8s-eu-1-worker-4:  Cloud VPS-S each :
4 vCPU cores
8 GB RAM
400 GB SSD
32 TB Traffic (unlimited incoming)
k8s-eu-1-worker-1/2/3: Cloud VPS-XL each:
10 vCPU cores
60 GB RAM
1.6 TB SSD
32 TB Traffic (unlimited incoming)

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Baremetal Cloud VPS Provider: Contabo

I installed Longhorn through helm:
root@k8s-eu-1-control-plane-node-1:~# helm repo add longhorn https://charts.longhorn.io
"longhorn" has been added to your repositories
root@k8s-eu-1-control-plane-node-1:~# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "longhorn" chart repository
...Successfully got an update from the "cilium" chart repository
...Successfully got an update from the "prometheus-community" chart repository
Update Complete. ⎈Happy Helming!⎈
root@k8s-eu-1-control-plane-node-1:~# helm repo ls
NAME                	URL
cilium              	https://helm.cilium.io/
prometheus-community	https://prometheus-community.github.io/helm-charts
longhorn            	https://charts.longhorn.io

root@k8s-eu-1-control-plane-node-1:~# helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --version 1.6.1
NAME: longhorn
LAST DEPLOYED: Thu Apr 11 18:16:24 2024
NAMESPACE: longhorn-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Longhorn is now installed on the cluster!

Please wait a few minutes for other Longhorn components such as CSI deployments, Engine Images, and Instance Managers to be initialized.

Visit our documentation at https://longhorn.io/docs/

But the longhorn-manager pods remain in CrashLoopBackOff state , and the longhorn-uninstall pods in Error state:
root@k8s-eu-1-control-plane-node-1:~# kubectl get pods -n longhorn-system
NAME                                     READY   STATUS             RESTARTS        AGE
longhorn-driver-deployer-9f4fc86-mtnv8   0/1     Init:0/1           0               13m
longhorn-manager-88dsx                   0/1     CrashLoopBackOff   7 (2m24s ago)   13m
longhorn-manager-khxnr                   0/1     CrashLoopBackOff   7 (2m37s ago)   13m
longhorn-manager-q4xlz                   0/1     CrashLoopBackOff   7 (2m20s ago)   13m
longhorn-manager-wp559                   0/1     CrashLoopBackOff   7 (2m32s ago)   13m
longhorn-manager-z9r8m                   0/1     CrashLoopBackOff   7 (2m36s ago)   13m
longhorn-ui-5f4b7bbf69-gvsnc             1/1     Running            0               13m
longhorn-ui-5f4b7bbf69-v8w9x             1/1     Running            0               13m
longhorn-uninstall-hd4qz                 0/1     Error              0               9m55s
longhorn-uninstall-wx8tp                 0/1     Error              0               9m41s

Example of longhorn-manager pod in CrashLoopBackOff state :
root@k8s-eu-1-control-plane-node-1:~# kubectl describe pod longhorn-manager-88dsx -n longhorn-system
Name:                 longhorn-manager-88dsx
Namespace:            longhorn-system
Priority:<PHONE_NUMBER>
Priority Class Name:  longhorn-critical
Service Account:      longhorn-service-account
Node:                 k8s-eu-1-control-plane-node-1/<IP_ADDRESS>
Start Time:           Thu, 11 Apr 2024 18:16:27 +0200
Labels:               app=longhorn-manager
                      app.kubernetes.io/instance=longhorn
                      app.kubernetes.io/managed-by=Helm
                      app.kubernetes.io/name=longhorn
                      app.kubernetes.io/version=v1.6.1
                      controller-revision-hash=758dbbd69b
                      helm.sh/chart=longhorn-1.6.1
                      pod-template-generation=1
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/longhorn-manager
Containers:
  longhorn-manager:
    Container ID:  cri-o://4eeb64b7c18fb6b566203d4a4112a8871332c783473b5ec751100b13764260e3
    Image:         longhornio/longhorn-manager:v1.6.1
    Image ID:      docker.io/longhornio/longhorn-manager@sha256:69a4dde599ab9fb2e506ea2eeed4f939b8c282fd7a073f8ba2ddccf3f844089e
    Ports:         9500/TCP, 9501/TCP, 9502/TCP, 9503/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP, 0/TCP
    Command:
      longhorn-manager
      -d
      daemon
      --engine-image
      longhornio/longhorn-engine:v1.6.1
      --instance-manager-image
      longhornio/longhorn-instance-manager:v1.6.1
      --share-manager-image
      longhornio/longhorn-share-manager:v1.6.1
      --backing-image-manager-image
      longhornio/backing-image-manager:v1.6.1
      --support-bundle-manager-image
      longhornio/support-bundle-kit:v0.0.36
      --manager-image
      longhornio/longhorn-manager:v1.6.1
      --service-account
      longhorn-service-account
      --upgrade-version-check
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Thu, 11 Apr 2024 18:27:39 +0200
      Finished:     Thu, 11 Apr 2024 18:27:40 +0200
    Ready:          False
    Restart Count:  7
    Readiness:      http-get https://:9501/v1/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      POD_NAMESPACE:  longhorn-system (v1:metadata.namespace)
      POD_IP:          (v1:status.podIP)
      NODE_NAME:       (v1:spec.nodeName)
    Mounts:
      /host/dev/ from dev (rw)
      /host/proc/ from proc (rw)
      /tls-files/ from longhorn-grpc-tls (rw)
      /var/lib/longhorn/ from longhorn (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-jzll2 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  dev:
    Type:          HostPath (bare host directory volume)
    Path:          /dev/
    HostPathType:
  proc:
    Type:          HostPath (bare host directory volume)
    Path:          /proc/
    HostPathType:
  longhorn:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/longhorn/
    HostPathType:
  longhorn-grpc-tls:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  longhorn-grpc-tls
    Optional:    true
  kube-api-access-jzll2:
    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/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists
                             node.kubernetes.io/pid-pressure:NoSchedule op=Exists
                             node.kubernetes.io/unreachable:NoExecute op=Exists
                             node.kubernetes.io/unschedulable:NoSchedule op=Exists
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  16m                 default-scheduler  Successfully assigned longhorn-system/longhorn-manager-88dsx to k8s-eu-1-control-plane-node-1
  Normal   Pulling    16m                 kubelet            Pulling image "longhornio/longhorn-manager:v1.6.1"
  Normal   Pulled     15m                 kubelet            Successfully pulled image "longhornio/longhorn-manager:v1.6.1" in 13.329s (13.329s including waiting)
  Normal   Created    14m (x5 over 15m)   kubelet            Created container longhorn-manager
  Normal   Started    14m (x5 over 15m)   kubelet            Started container longhorn-manager
  Normal   Pulled     14m (x4 over 15m)   kubelet            Container image "longhornio/longhorn-manager:v1.6.1" already present on machine
  Warning  BackOff    59s (x75 over 15m)  kubelet            Back-off restarting failed container longhorn-manager in pod longhorn-manager-88dsx_longhorn-system(cdc601a6-4b7f-41ff-8752-9551a7f80228)

And, example of longhorn-uninstall pod in Error state :
root@k8s-eu-1-control-plane-node-1:~# kubectl describe pod longhorn-uninstall-hd4qz -n longhorn-system
Name:                 longhorn-uninstall-hd4qz
Namespace:            longhorn-system
Priority:<PHONE_NUMBER>
Priority Class Name:  longhorn-critical
Service Account:      longhorn-service-account
Node:                 k8s-eu-1-worker-2/<IP_ADDRESS>
Start Time:           Thu, 11 Apr 2024 18:20:09 +0200
Labels:               app.kubernetes.io/instance=longhorn
                      app.kubernetes.io/managed-by=Helm
                      app.kubernetes.io/name=longhorn
                      app.kubernetes.io/version=v1.6.1
                      batch.kubernetes.io/controller-uid=5da939b0-4101-4926-83a1-6101cfe98965
                      batch.kubernetes.io/job-name=longhorn-uninstall
                      controller-uid=5da939b0-4101-4926-83a1-6101cfe98965
                      helm.sh/chart=longhorn-1.6.1
                      job-name=longhorn-uninstall
Annotations:          <none>
Status:               Failed
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  Job/longhorn-uninstall
Containers:
  longhorn-uninstall:
    Container ID:  cri-o://c3642973e07a155bcb6c69eeb3b46c0eb8cceb460583af8aadcd69d6996d5758
    Image:         longhornio/longhorn-manager:v1.6.1
    Image ID:      docker.io/longhornio/longhorn-manager@sha256:69a4dde599ab9fb2e506ea2eeed4f939b8c282fd7a073f8ba2ddccf3f844089e
    Port:          <none>
    Host Port:     <none>
    Command:
      longhorn-manager
      uninstall
      --force
    State:          Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Thu, 11 Apr 2024 18:20:09 +0200
      Finished:     Thu, 11 Apr 2024 18:20:13 +0200
    Ready:          False
    Restart Count:  0
    Environment:
      LONGHORN_NAMESPACE:  longhorn-system (v1:metadata.namespace)
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-pvtrr (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-pvtrr:
    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  Scheduled  14m   default-scheduler  Successfully assigned longhorn-system/longhorn-uninstall-hd4qz to k8s-eu-1-worker-2
  Normal  Pulled     14m   kubelet            Container image "longhornio/longhorn-manager:v1.6.1" already present on machine
  Normal  Created    14m   kubelet            Created container longhorn-uninstall
  Normal  Started    14m   kubelet            Started container longhorn-uninstall

What do I have to do to make all the longhorn-system pods become in Running state?

Do you see error log messages in the longhorn-uninstall pod?

Hi @derekbit
Yesterday I had issues also during the un-installation process, and I had to clean everything up through these steps:
https://longhorn.io/docs/1.6.1/deploy/uninstall/#uninstalling-longhorn-using-kubectl

Can you check the log messages of the longhorn-manager pods?
For example
kubectl -n longhorn-system logs longhorn-manager-9tnbl -f
kubectl -n longhorn-system logs longhorn-manager-9tnbl --previous

 logs longhorn-manager-9tnbl :
root@k8s-eu-1-control-plane-node-1:~# kubectl -n longhorn-system logs longhorn-manager-9tnbl -f
time="2024-04-12T08:38:20Z" level=fatal msg="Error starting manager: Failed environment check, please make sure you have iscsiadm/open-iscsi installed on the host: failed to execute: /usr/bin/nsenter [nsenter --mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net iscsiadm --version], output , stderr nsenter: failed to execute iscsiadm: No such file or directory\n: exit status 127" func=main.main.DaemonCmd.func3 file="daemon.go:92"

root@k8s-eu-1-control-plane-node-1:~# kubectl -n longhorn-system logs longhorn-manager-9tnbl --previous
time="2024-04-12T08:38:20Z" level=fatal msg="Error starting manager: Failed environment check, please make sure you have iscsiadm/open-iscsi installed on the host: failed to execute: /usr/bin/nsenter [nsenter --mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net iscsiadm --version], output , stderr nsenter: failed to execute iscsiadm: No such file or directory\n: exit status 127" func=main.main.DaemonCmd.func3 file="daemon.go:92"

OK. You need to install iSCSI utility and some dependencies. Please see https://longhorn.io/docs/1.6.1/deploy/install/.

I read that iscsid daemon has to be running on all the nodes.
Does it mean that I have to install in all nodes both the Ubuntu package open-iscsi and the longhorn-iscsi  : https://raw.githubusercontent.com/longhorn/longhorn/v1.6.1/deploy/prerequisite/longhorn-iscsi-installation.yaml  ?

I've installed iscsi tools in all the nodes apart from one, which I'm not able to connect to today, and for which I've contacted the Contabo Cloud Support Team
So, I guess, it will take a while for the whole process today

, which I'm not able to connect to today, and for which I've contacted the Contabo Cloud Support Team
So, I guess, it will take a while for the whole process today

OK! Take your time. Hope we can get good news soon! :)

It seems that now all the requirements are fulfilled for all kubernetes nodes:
root@k8s-eu-1-control-plane-node-1:~# curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.6.1/scripts/environment_check.sh | bash
[INFO]  Required dependencies 'kubectl jq mktemp sort printf' are installed.
[INFO]  All nodes have unique hostnames.
[INFO]  Waiting for longhorn-environment-check pods to become ready (0/5)...
[INFO]  All longhorn-environment-check pods are ready (5/5).
[INFO]  MountPropagation is enabled
[INFO]  Checking kernel release...
[INFO]  Checking iscsid...
[INFO]  Checking multipathd...
[INFO]  Checking packages...
[INFO]  Checking nfs client...
[INFO]  Cleaning up longhorn-environment-check pods...
[INFO]  Cleanup completed.

root@k8s-eu-1-control-plane-node-1:~# kubectl version
Client Version: v1.28.8
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.8

I re-installed longhorn
root@k8s-eu-1-control-plane-node-1:~# helm repo add longhorn https://charts.longhorn.io
"longhorn" already exists with the same configuration, skipping
root@k8s-eu-1-control-plane-node-1:~# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "longhorn" chart repository
...Successfully got an update from the "cilium" chart repository
...Successfully got an update from the "prometheus-community" chart repository
Update Complete. ⎈Happy Helming!⎈
root@k8s-eu-1-control-plane-node-1:~# helm repo ls
NAME                	URL
cilium              	https://helm.cilium.io/
prometheus-community	https://prometheus-community.github.io/helm-charts
longhorn            	https://charts.longhorn.io

root@k8s-eu-1-control-plane-node-1:~# helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --version 1.6.1
NAME: longhorn
LAST DEPLOYED: Mon Apr 15 09:39:06 2024
NAMESPACE: longhorn-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Longhorn is now installed on the cluster!

Please wait a few minutes for other Longhorn components such as CSI deployments, Engine Images, and Instance Managers to be initialized.

Visit our documentation at https://longhorn.io/docs/

And now the pods are all in Running state :
root@k8s-eu-1-control-plane-node-1:~# kubectl -n longhorn-system get pod
NAME                                                READY   STATUS    RESTARTS   AGE
csi-attacher-5c4bfdcf59-bdggn                       1/1     Running   0          4m3s
csi-attacher-5c4bfdcf59-glr9c                       1/1     Running   0          4m3s
csi-attacher-5c4bfdcf59-wbn9d                       1/1     Running   0          4m3s
csi-provisioner-667796df57-bkxgf                    1/1     Running   0          4m3s
csi-provisioner-667796df57-g2d57                    1/1     Running   0          4m3s
csi-provisioner-667796df57-p99tm                    1/1     Running   0          4m3s
csi-resizer-694f8f5f64-48h6q                        1/1     Running   0          4m3s
csi-resizer-694f8f5f64-4wtt2                        1/1     Running   0          4m3s
csi-resizer-694f8f5f64-n8m6w                        1/1     Running   0          4m3s
csi-snapshotter-959b69d4b-8v2nz                     1/1     Running   0          4m3s
csi-snapshotter-959b69d4b-dxvvz                     1/1     Running   0          4m3s
csi-snapshotter-959b69d4b-rmwxg                     1/1     Running   0          4m3s
engine-image-ei-5cefaf2b-2r7td                      1/1     Running   0          4m10s
engine-image-ei-5cefaf2b-7v899                      1/1     Running   0          4m10s
engine-image-ei-5cefaf2b-b5fnm                      1/1     Running   0          4m10s
engine-image-ei-5cefaf2b-jdwd6                      1/1     Running   0          4m10s
engine-image-ei-5cefaf2b-tbwm2                      1/1     Running   0          4m10s
instance-manager-350386a73f401a602f1783938be991c0   1/1     Running   0          4m10s
instance-manager-4f65765c001f2b941bc5d728b65d4a32   1/1     Running   0          4m10s
instance-manager-51492326327041ac5956619303cd25e7   1/1     Running   0          4m6s
instance-manager-58ba023cfd09576814ec35835c1d718f   1/1     Running   0          4m10s
instance-manager-df0e119506168285bcc61fb5bbe710ae   1/1     Running   0          4m10s
longhorn-csi-plugin-8gcz2                           3/3     Running   0          4m3s
longhorn-csi-plugin-8gpgr                           3/3     Running   0          4m3s
longhorn-csi-plugin-jkshn                           3/3     Running   0          4m3s
longhorn-csi-plugin-lnr9q                           3/3     Running   0          4m3s
longhorn-csi-plugin-wshnd                           3/3     Running   0          4m3s
longhorn-driver-deployer-9f4fc86-w2x6f              1/1     Running   0          4m18s
longhorn-manager-9rr2c                              1/1     Running   0          4m18s
longhorn-manager-b4wk6                              1/1     Running   0          4m18s
longhorn-manager-b9b4r                              1/1     Running   0          4m18s
longhorn-manager-r7zgs                              1/1     Running   0          4m18s
longhorn-manager-wbgv2                              1/1     Running   0          4m18s
longhorn-ui-5f4b7bbf69-f6zsz                        1/1     Running   0          4m18s
longhorn-ui-5f4b7bbf69-r7m5w                        1/1     Running   0          4m17s

Thank you @derekbit for your kind help


Broken in all browsers

The demo code editor is completely broken, the modal opens but there's nothing inside it.

Once you click inside the code editor, this triggers a re-layout and everything appears fine. I was able to get the same behavior by adding this at the bottom of the _initializeEditor method, but I'm not sure if it's the best workaround. @davidrleonard any thoughts?
setTimeout(function() {
  this.editor.execCommand('goDocEnd');
}.bind(this));

Fixes in 5c11a0458383d193160987b8e43e3e815797d196, released in v4.0.3.


Upload Aqua Operator Community Data

@SamiSousa  Yes, its allready tested on kubernetes and openshift
1.11+ k8s
3.11+ Openshift

/retest

/ok-to-test

@SamiSousa All Updated! and the build pass! Thanks!

@SamiSousa All Updated! Can you please have a look if its all ok and i can merge it.

@niso120b I believe the descriptions for your OpenShift and Kubernetes CSVs are still mixed up. Please switch the spec.descriptions for your two CSVs so that they match the directory they are in.

@SamiSousa Updated

@niso120b I don't see the updates, the spec.descriptions are still mixed up.

All is updated!
Kubernetes has its own description, and openshift has its own description.
and the commands to create some objects its en example after you install aqua operator.
and the operator also allready tested in openshift and kubnernetes and its pass your build, this PR opened 17 days ago.
Openshift

Kubernetes

@niso120b I appreciate your enthusiasm in getting this PR through.
When I look at the files in this PR, the descriptions are still mixed up.
The CSV in the community-operators directory should be for OpenShift.
The CSV in the upstream-community-operators directory should be for Kubernetes.
I see in your editor screenshots that the descriptions do match, but they do not match in the PR. If you are having issues with git, please let me know.

I don’t know where you see it,
You can take a look on the files
openshift
https://github.com/niso120b/community-operators/blob/master/upstream-community-operators/aqua/aqua-operator.v0.0.1.clusterserviceversion.yaml
Kubernetes
https://github.com/niso120b/community-operators/blob/master/community-operators/aqua/aqua-operator.v0.0.1.clusterserviceversion.yaml
You can see the file are updated
If you have issues with github, just let me know

@niso120b In your links, the "OpenShift" version is in the upstream-community-operators directory. That should be in the community-operators directory.

@SamiSousa Updated

@SamiSousa Thanks Updated

@SamiSousa Please Update me

@niso120b The operator successfully deploys to my cluster on OpenShift, but I'm unable to check if the application works since I do not have access to the aqua registry. The example CRs create deployments with pods that error with the ErrImagePull status (due to my lack of registry credentials). I'm satisfied with this result, since the operator is able to resolve the CRs. CI tests seems to be passing as well.
/lgtm

@niso120b Please rebase your commits

@SamiSousa Rebase Done!

/lgtm

@niso120b Thank you for your patience! I have pushed the aqua operator to quay.io, so now this operator will be available on OpenShift clusters running the marketplace operator. It will be listed on operatorhub.io in some time.


SQLite error with addTimestamps()

With current implementation of addTimestamps() method, it is impossible to add timestamp columns for already created table in SQLite environment. As there must be default value for column...
Migration 1:
$this->table('users')
    ->addColumn('name', 'string', ['limit' => 255])
    ->addColumn('email', 'string', ['limit' => 255])
    ->addColumn('password', 'char', ['limit' => 60])
    ->save();

Migration 2:
$this->table('users')->addTimestamps()->update();

Which generates:
PDOException: SQLSTATE[HY000]: General error: 1 Cannot add a column with non-constant default in /srv/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:168

@dereuromark I'm tried to fix this bug, but when I fix it, I have the next problem with rollback. And it hard for me, to understand how did rollback works. There is a solution what I found for addTimestamps()
        $this->addColumn($createdAt, 'timestamp', [
            'default' => 'NULL',
            'update' => '',
            'timezone' => $withTimezone,
        ])->changeColumn($createdAt, 'timestamp', [
            'default' => 'CURRENT_TIMESTAMP',
        ])->addColumn($updatedAt, 'timestamp', [
            'null' => true,
            'default' => null,
            'timezone' => $withTimezone,
        ]);

Default value can be set only, when table is already exists. So first we need to create created_at, and then update default value

I am not sure I see how your solution would work.

Default value can be set only, when table is already exists.
This is not true for sqlite. A default value using a non-constant value (e.g. the return of function CURRENT_TIMESTAMP) can only be applied at table creation time (this post explains technical details of why).

I think really only a note to the docs should be added just stating that addTimestamps() can only be used at table creation time for SQLite, given there's no way to make the $createdAt column work sensibly with alters.

This is now fixed for the upcoming 0.12 release.
Thanks @PetrenkoBohdan for your code there, got me to realize that the SQLite adapter was already doing something funny under the hood for change column commands, just had to adopt it to the add column commands. That funny bit being that instead of using SQLite's very weak ALTER TABLE command, it's better to create a temp table with the new desired functionality, and then copy everything over to it, and then rename the table, rather than trying to use ALTER TABLE.
@dereuromark close this?


feat: upgrade rn to 0.73.2 (INTER-48)

Most of the changes happened by running npx react-native upgrade
Upgrade requires upgrading node as well (set to latest LTS – 20)
All the other changes happened just by manually solving problem after problem.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-test.1 :tada:
The release is available on:

npm package (@test dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can there be several objective functions with DREAM?

DREAM uses this weird objective function, can Spotpy still be used to calculate other objective functions in the progress? For example Klingt Gupta, so in the End one can better compare stuff with ACME?

yes, thats possible, e.g. like this:
def objectivefunction(self,simulation,evaluation):
    like1 = spotpy.likelihoods.gaussianLikelihoodMeasErrorOut(evaluation,simulation)
    like2 = spotpy.objectivefunctions.kge(evaluation,simulation)
    return [like1,like2]

And just for the record, the DREAM objectivefunction is not weird, just different ;)

Thanks for the quick replay, did not really think that anyone but me would read this^^
I figured this could be done the way you laid out, but I knowing it for sure is quite helpful!
For me the DREAM objectivefunction will remain weird until I understand what it does ;)

The gaussian likelihood function is not too complex. From the mathematically compexety similar to KGE:
p = -n/2\\log(\\sum_{t=1}^n e_t(x)^2)

with e_t = observation - simulation, and n = len(simulation). So more ore less, just the negative log of the sum of the squared residuals. The value is allways negative. The closer to zero the better is the fit.

Ah nice. Thanks.
You mean spotpy.likelihoods.gaussianLikelihoodMeasErrorOut?

exactly

For now acme will use Latin Hypercube Sampling. Therefore, this is closed. Might need reevaluation in future.


Intelligent Dispatching not triggering for second part of a scheduled charge

Describe the bug
I have a two segment charging window between 23:30-00:00 and 00:00-06:00.. However the Intelligent Dispatching is off during the second window.
Reproduction steps
this data taken at 01:23 31/5/24 BST.. the sensor is OFF when it should be ON: (is location=null expected?)
My OCPP charging is charging at this point.
planned_dispatches:

start: '2024-05-31T00:00:00+01:00'
end: '2024-05-31T06:00:00+01:00'
charge_in_kwh: -42.94
source: smart-charge
location: null

completed_dispatches:

start: '2024-05-30T23:30:00+01:00'
end: '2024-05-31T00:00:00+01:00'
charge_in_kwh: -3.5
source: null
location: AT_HOME

data_last_retrieved: 2024-05-31T01:12:39.841940+01:00
last_evaluated: 2024-05-31T01:12:40.007945+01:00
provider: OCPP_WALLBOX
vehicle_battery_size_in_kwh: 39
charge_point_power_in_kw: 6.8
current_start: null
current_end: null
next_start: null
next_end: null
icon: mdi:power-plug-battery
friendly_name: Octopus Energy Intelligent Dispatching
Expected behaviour
The sensor value should be ON during all scheduled windows
Tariff Code
E-1R-INTELLI-VAR-22-10-14-L
Integration Version
11.02
Home Assistant Version
2024.5.2
Fresh Install?
Not specified
Home Assistant Logs
no logs as yet
Confirmation

[X] I confirm that I cannot find my solution within the documentation
[X] I confirm that I cannot find my solution within the FAQ

Is this related to https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues/884 ? Saw this issue today and also with issue #884

Hello. It looks like the OE APIs are failing to return any rate information after 2024-05-31 05:30:00 (similar to 884 as pointed out). This is not something I'm in control of, so unfortunately there's nothing I can do. I've posted in the OE forums which will hopefully get someone's attention.

For me, I see Intelligent dispatching goes "on" at 23:30 (start of off peak) and then "off" at 00:00 instead of 05:30. Same thing on 24/25th May - i.e. exactly a week ago so perhap timing is factor. Based upon last week, we might see it return correct status later in the morning.


System log under Hass.io tab always show log entries in UTC time zone

The system log under the Hass.io tab always show log entries in with UTC timestamp even if another time zone is set in the configuration.yaml. The log under dev-info shows always the right timezone.
This is not version specific, this is since I use Home Assistant before 0.50 Version. I'm on Raspberry Pi 3B+ with Hassos 1.9,
My time zone is Europe/Berlin (CEST +2 hours). The system og is 2 hours behind (UTC).

/move to home-assistant/hassio


[Issue-137] Upgrade Pravega version and Spark version

Signed-off-by: Fan, Yang<EMAIL_ADDRESS>Change log description

Upgrade Pravega version to the commit https://github.com/pravega/pravega/commit/fc1f5c371cf5e499c045897596d6ade0be5866c4
Upgrade Spark version to 3.2

Purpose of the change
Fix #137
What the code does

Change Pravega version in gradle.properties
Change Spark version in gradle.properties

How to verify it
./gradlew clean build passed

Closed as not needed now.


Mccalluc/example tracktypes

Description
What was changed in this pull request?

Generate the html with one script rather than one-liners
List the track types used in every viewconf example

Why is it necessary?

I want to get examples of every track type (#422) and a prerequisite to that is understanding what tracktype examples we already have.
and in the other direction, we would like to be able to point the users to examples of each track type.

Maybe down the road some sort of grid would be more clear visually.
Also might consider confirming in travis that this is up-to-date.
Checklist

[ ] Unit tests added or updated
[ ] Documentation added or updated
[ ] Example added or updated
[x] Screenshot for visual changes (e.g. new tracks)
[ ] Updated CHANGELOG.md

(Sorry about all the commits: I'll try to rebase this and see if that helps.)

You can also just squash and merge your commits. Just click on the drop down next to "Merge pull request" and select "Squash and merge".

You can also just squash and merge your commits. Just click on the drop down next to "Merge pull request" and select "Squash and merge".

Sure: That's what I usually do with my PRs. I guess I meant to apologize for making this PR harder to review by including the earlier commits, but the end result when it is merged is the same.

Would you mind making this a proper python string with a main function and a usage tag?

Will do.

@pkerpedjiev : ok now?

(Sent follow up questions on slack... will go ahead and merge.)


Support textColor, not resource id

TextView tv_title = findViewById(R.id.tv_title);
String breadCrumb = year + " >";
SimpleText simpleTextBC = SimpleText.from(breadCrumb)
.all(">")
.bold()
.textColor(R.color.colorWhite);
tv_title.setText(simpleTextBC);
I am getting the error on .textColor Line
Attempt to invoke virtual method 'int android.content.Context.getColor(int)' on a null object reference

@Sarosh-Madara Can you really access R.color.colorWhite?, Have you tried to rebuild your project?

hi @Sarosh-Madara in which device you faced this issue. i also had this issue but can't figure out on which device it's happening. so it will be great if you provide some more info about device. thanks


Please add changelog

As the title says, was hoping you could add a simple changelog, or at least provide a bit of description with your releases. Just trying to get an idea of what additions / bugfixes happen with each update.

Yup that'd be nice. I'm not going to backlog all of the changes but I'll try to keep one up to date from now on.


Use EXIF or XMP for screenshot metadata

Currently metadata is stored as raw text inside a PNG chunk. This means external programs either ignore it or can't read the text. Even exiftool refuses to export the data because it's not a recognised type.
This is especially annoying when trying to convert screenshots into a newer format. I've managed to halve the size of my screenshots losslessly, but the text chunk is always ignored making it useless...
Storing the metadata inside an EXIF chunk instead would mean more programs can read it, and the metadata would be preserved when converting to newer file formats too.
Alternatively, turning the text chunk into an XMP chunk is also an option. Then you can store the metadata in custom fields rather than filling up EXIF's description tag.
Ideally there'd be a button in the screenshot manager section to convert older files to the new format too

the current implementation was done on purpose as to make sure it doesn't get stripped by sharing platforms like discord.

Discord only removes metadata from jpegs, and the XMP is still a text chunk with some extra formatting

Here's an example with both EXIF and XMP, it kept both when uploaded to Discord

Here's an example with both EXIF and XMP, it kept both when uploaded to Discord

back then discord stripped all exif data this was during time of implementation of vrcxs feature, this is no longer the case and discord now only stripes exif data for GPS tags. back then it was a requirement, now its a stuck in feature and changing it would require migrating thousands of user pictures with wouldn't at all go off perfectly and could risk corruption, don't fix what isn't broken.

in your own example EXIF is stripped from that image we just tested it through vanilla discord clients ORG image

after being ran through discord through the vanilla client

Well that's odd, I even got an SHA256 match on mine after re-saving from Discord

Huh, so it does actually parse the EXIF chunk. Guess XMP would be the option then, although you already said no

Huh, so it does actually parse the EXIF chunk. Guess XMP would be the option then, although you already said no

well even if this wasn't the case it would still require migrating possibly thousands of user images to a new format and if we don't do that maintain the old format as well, we don't want to find ourselves in the middle of some funky migrator stage.

IIRC I looked into storing exif data at first but went with iTxT bc the PNG format < 1.2 doesn't really support exif data (at least in many decoders/editing software) and would be pointless to force in bc a lot of programs didn't even process it/detect it correctly, even if png 1.2 technically supports it on paper. Even now, imagemagick is about the only thing that detects the metadata we store.
It was part of the problem of going from the original implementation of the mod that did the same thing, but converted images to JPG and then stored metadata, which would be likely more involved and costly to do working on files after they've already been captured/saved.


Fix AnimationNodeTransition initialization and AnimationNode remapping method

Fixes #72637. Follow up #72513.
AnimationNodeTransition now validates inputs in _process() with the pending_update flag.[^1]
Also, I removed the parameter remap method in #72513, but it was actually necessary. However, the remap was not working correctly previously. For example, remapping was not done correctly due to node deletion. This was also one of the causes of the AnimationNodeTransition initialization bug.
So, this PR added signals for remapping and the remapping is now done correctly.
[^1]: Multiple AnimationTrees may reference the same AnimationBlendTree (Resource), so this must be done in _process(). See also https://github.com/godotengine/godot/issues/23629#issuecomment-1001020829.

Thanks!


fix: set link default value to random

The link input has now a default value, which is a random string.
I've kept the Generate link to make another one, if the user wants, or if he make a bad manipulation and have to generate another link.

This Pull request resolve #180

Nice, thanks again for all your PRs :)

No problems, I'm working on the reverse shares options.

@stonith404
I'll just need help because I had to modify a bit the database, to add a string, which contains a JSON object :
export type ReverseShareOptions = {
  easyMode: boolean;

  customLinkEnabled: boolean;
  passwordEnabled: boolean;
  descriptionEnabled: boolean;
  maximalViewsEnabled: boolean;
}

And I also changed the backend service and DTOs, but I would like to add this modification, without breaking the current db, how can I do that ? I would like to put default values for all the current reverse shares but I don't know how to do ...

For the frontend there is no problem, because I can do smth like this :
const getMyReverseShares = async (): Promise<MyReverseShare[]> => {
  const shares = (await api.get("reverseShares")).data;
  for (const share of shares)
  {
    share.sharesOptions = JSON.parse(share.sharesOptions);
    if(Object.keys(share.sharesOptions).length === 0)
      share.sharesOptions = structuredClone(defaultReverseShareOptions);
  }

  return shares;
};

But the backend db resets if the schema has changed. Personally, I have regenerated the db :
npx prisma db push
npx prisma db seed

But for all the other users, how could I make the new release without having to reset their db ?

@pierrbt I probably would add a new table and add a 1:1 connection between the ReverseShare and ReverseShareOptions table as a a relational database shouldn't have a JSON object inside a cell.
For the migration part, it is quite easy with prisma. You just have to run npx prisma dev. Then a sql file will get created in ./prisma/migrations/{your_migration}. Now you can update the sql file that the existing reverse shares will get the correct data.
Btw. you can write me on Discord (stonith404) then we don't have to discuss things in random PRs or issues.


[radio-spinel] fix RCP if aSkipRcpCompatibilityCheck is set

If aSkipRcpCompatibilityCheck is true, the member mRadioCaps is never retrieved from the RCP controller, which breaks tx security checks.
Fix the issue by retrieving both the RCP API version and radio capabilities in any case.

If aSkipRcpCompatibilityCheck is true, the member mRadioCaps is never retrieved from the RCP controller, which breaks tx security checks.
Fix the issue by retrieving both the RCP API version and radio capabilities in any case.

Thanks @pdgendt for submitting this.
What is the use-case for this change?
I think in general we should only safely use the RCP as a radio (i.e., send and receive frame, ect) when we do the RCP compatibility checks (i.e., aSkipRcpCompatibilityCheck should not be used if we intend to use RCP to communicate).
From what I recall, the aSkipRcpCompatibilityCheck feature was intended for very special use-cases (like transitions between firmwares, or from an NCP build or an RCP one, etc.).

In such cases, the NCP build (or even the RCP build) may not actually provide certain properties.
e.g.,  SPINEL_PROP_RCP_API_VERSION and SPINEL_PROP_RADIO_CAPS are only available on an RCP build and not on an NCP firmware.
So if we try to retrieve them in RadioSpinel (even under aSkipRcpCompatibilityCheck),  it can cause failures/timeouts and the host-side driver/posix app may not even start properly.

Hi @abtink, thanks for the response. The use case I intended to target was the transition of firmwares, where the application logic verifies this.
Currently if we want to support this, we need to add logic to the both our application and the init.d script to make sure we can verify the RCP package version.
Effectively this change permits the host from setting aSkipRcpCompatibilityCheck=true and keep running the openthread stack without the need to restart if the host and RCP are already compatible.

Thanks @pdgendt.
I think if we want to start Thread operation (start the network, enable radio, and issue commands to RCP to send/receive frame) then we should do so with full version check and with aSkipRcpCompatibilityCheck = false.

The main reason for the performing the RCP_API_VERSION is to make sure the RCP API command/response format is compatible between RCP and host.
The model is that RCP_API_VERSION is incremented when there is any change in any of the RCP API (any spinel format that is used between RCP and host).
On the host we track a range of RCP_API_VERSIONs that are supported (the MIN_HOST_SUPPORTED_RCP_API_VERSION specifies this) and it is updated when there is a backward incompatible change (meaning we definitely need to update RCP image to work with a new change on the host side).

I think starting to operate Thread Network with  aSkipRcpCompatibilityCheck = true may be unsafe (it may address some immediate need but in general I would advise against using it).
The challenge I see with the change you proposed in this PR, is that it assumes/requires that the SPINEL_PROP_RADIO_CAPS to be available on the RCP/NCP firmware image (from which we are transitioning) which may not be the case (for example it is the case for an NCP firmware build). So it limits the use of aSkipRcpCompatibilityCheck.

@pdgendt , any further thoughts on this PR?

@pdgendt , any further thoughts on this PR?

In our case it is still useful, but I understand that this impacts backwards compatibility. Is adding a new option to the initialisation overkill?
It could be refactored a bit to a descriptive struct with bit flags instead of listing all options separately. Any suggestions or objections?

@pdgendt would you be able to share a bit more details about your use-case? We may be to able to then provide some help/suggestions (based on the models/solutions we have used in some of our internal projects/products that use posix/RCP architecture).
Do you intend to allow OpenThread stack to run (host controlling the RCP and send and receive frames, etc) when RCP API check can potentially fail? If that's the case, I would again highly advice against doing so. If the RCP API check fails it indicates that there are some incompatible changes between host and RCP (and how the APIs are defined between the two). Basically the host will issue commands to RCP but its behavior will be undefined. When there is an API version check failure even if things kind of work initially, some functionality is definitely changed/broken between the host and RCP.
If you want to have the application logic perform the RCP API version,  what is the next step (what will it do) if it detects a RCP API version mismatch? Thanks.

Hi @abtink, our posix device has a very simple init script for the border agent (in which we always set aSkipRcpCompatibilityCheck=true), and we don't want to add extra logic here.
It is another application that queries the package version and verifies if it is as expected. If so, it simply continues, otherwise it will perform an update of the RCP controller.
This can only work if the border agent doesn't exit prior to the version request, and it is beneficial if the border agent doesn't need to restart if the check is validated.

Thanks @pdgendt .
One question: in your use-case if the version check fails and the application starts the RCP firmware update, does it work ok if border agent and ot-ftd (OT posix app) process continue to run. In our use-case integrations, from what I recall, we made sure that ot posix process is stopped to avoid it interacting and potentially disrupting the RCP during the firmware update (e.g. issue hw reset, etc).

Thanks @pdgendt .
One question: in your use-case if the version check fails and the application starts the RCP firmware update, does it work ok if border agent and ot-ftd (OT posix app) process continue to run. In our use-case integrations, from what I recall, we made sure that ot posix process is stopped to avoid it interacting and potentially disrupting the RCP during the firmware update (e.g. issue hw reset, etc).

If the version check fails, the border agent is stopped during the upgrade. Not sure what you mean with the ot-ftd app though?

If the version check fails, the border agent is stopped during the upgrade. Not sure what you mean with the ot-ftd app though?

Thanks. By ot-ftd I mean the OT posix executable (I guess it would be basically same as border agent executable in your case).
Seems like your application can then check and stop the border agent process (I guess it stops the process fully?) which is good to do. So if you enable RCP API check it would automatically kill the process for you on RCP API failure. Would it then work in your use-case to have applicable use the fact that process is not running as indicator of a RCP version mismatch and trigger the RCP firmware update?


UI5-combobox

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/retest

/retest


related to feature 315

Hello,
in feature#315 which allows to use CacheManager with no UI, createProgressDialog() must be called in onPreExecute() in CacheManagerTask and not in the constructor.

done


Add parameter to disable mongodb/rabbitmq in-cluster deployment

Closes #24 - not sure if the fix is this simple.  Feedback appreciated!

I'll release updated Helm chart version early next week.


real-world: remove expected failure from ssl.tabelog.com test

Reviewer: @shakyShane
Asana: https://app.asana.com/0/0/1207309735478037/f
Description
We're able to consistently detect the login field, so there's no need to expect a failure for it any more.
Steps to test
node_modules/.bin/jest src/Form/input-classifiers.test.js -t tabelog

Closing in favor of a separate discussion on supported languages. See https://github.com/duckduckgo/duckduckgo-autofill/pull/564#discussion_r1601177256


Playing on multiple servers with same name picks only first server

Expected Behavior
Returning an error if more then on server with the same name is returned by https://lobby.ogame.gameforge.com/api/users/me/accounts
AND/OR
possibility to choose which server should be used. Imo it would be enough to pass a language flag.
Actual Behavior
OGame object initialises with the first server in the list.
Steps to Reproduce the Problem

Play on two servers with the same name with different languages
Init OGame lib with universe, username and password
print e.g the planet names or check the uni speed (have to be set differently)

Possible solution
Instead of only checking the server name(which alone is not unique) here, also check for the provided language(extend constructor with language flag). If language is set to None pick the first server in the list, like it is done already.

Fixed it with
https://github.com/alaingilbert/pyogame/commit/dad0ac932823311f02359ab50808ad6575fde62a

Hello,
this fix is not working.
It is correct that this fix is filtering the complete server list for the given server(to check if the provided server exists), but the problem isn't that the server number is wrongly filtered at this section. It will return the server number of the provided server with the same number but this number is not unique itself. E.g this is returned by calling the complete server list https://lobby.ogame.gameforge.com/api/servers i filtered for the Pasiphae server. Both have the same number

The language will be overwritten after being logged in by retrieving the server list of the account here. And this will override the given language key here
The server numbers are equal over all language instances. Example json after login and calling https://lobby.ogame.gameforge.com/api/users/me/accounts (tampered with some values but shouldn't matter)
[
    {
        "server": {
            "language": "en",
            "number": 168
        },
        "id": 1,
        "gameAccountId": 1,
        "name": "asdf",
        "lastPlayed": "2020-06-02T22:11:23+0000",
        "lastLogin": "2020-06-02T22:11:23+0000",
        "blocked": false,
        "bannedUntil": null,
        "bannedReason": null,
        "details": [
            {
                "type": "literal",
                "title": "myAccounts.rank",
                "value": "1"
            },
            {
                "type": "localized",
                "title": "myAccounts.status",
                "value": "playerStatus.active"
            }
        ],
        "sitting": {
            "shared": false,
            "endTime": null,
            "cooldownTime": null
        },
        "trading": {
            "trading": false,
            "cooldownTime": null
        }
    },
    {
        "server": {
            "language": "de",
            "number": 168
        },
        "id": 1,
        "gameAccountId": 1,
        "name": "asdf",
        "lastPlayed": "2020-06-02T21:06:22+0000",
        "lastLogin": "2020-06-02T21:06:22+0000",
        "blocked": false,
        "bannedUntil": null,
        "bannedReason": null,
        "details": [
            {
                "type": "literal",
                "title": "myAccounts.rank",
                "value": "1"
            },
            {
                "type": "localized",
                "title": "myAccounts.status",
                "value": "playerStatus.active"
            }
        ],
        "sitting": {
            "shared": false,
            "endTime": null,
            "cooldownTime": null
        },
        "trading": {
            "trading": false,
            "cooldownTime": null
        }
    }
]

Imo it doens't make sense to search for the existence of the server in the complete server list if the user isn't logged in already. It should be enough to check the server list of the account, if this list doesn't contain the server it can return an error. If a valid server is passed, but it is not in the account server list we won't retrieve any data.

i cant test for this myself.
I looked at your pull request and i like what i see. i will accept it. But can you push it to develop?

sure will do it this evening thank you :) there will be no permission problem pushing to develop?

I need to push develop to master asap because since today all pyogame bots dont work anymore.


mbedtls: 2.8.0 -> 2.9.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/mbedtls/versions.
These checks were done:

built on NixOS
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_aescrypt2 -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_aescrypt2 --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_aescrypt2 help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_hello -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_hello --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_hello help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ecdh_curve25519 -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ecdh_curve25519 --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ecdh_curve25519 help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_key_app -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_key_app --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_key_app help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_mpi_demo -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_mpi_demo --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_mpi_demo help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_pk_decrypt -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_pk_decrypt --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_pk_decrypt help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_rsa_genkey -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_rsa_genkey --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_rsa_genkey help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_rsa_sign -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_rsa_sign --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_rsa_sign help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_entropy -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_entropy --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_entropy help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_random_ctr_drbg -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_random_ctr_drbg --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_random_ctr_drbg help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_random_havege -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_random_havege --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_gen_random_havege help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ssl_mail_client -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ssl_mail_client --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ssl_mail_client help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_benchmark -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_benchmark --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_benchmark help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ssl_cert_test -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ssl_cert_test --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_ssl_cert_test help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_pem2der -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_pem2der --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_pem2der help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_strerror -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_strerror --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_strerror help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_crl_app -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_crl_app --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_crl_app help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_req_app -h’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_req_app --help’ got 0 exit code
ran ‘/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_req_app help’ got 0 exit code
found 2.9.0 with grep in /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0
directory tree listing: https://gist.github.com/fc0f8e7848649388caae66bddc561fb8

cc @wkennington @fpletz for review

Failure on x86_64-darwin (full log)
Attempted: mbedtls
Partial log (click to expand)
source root is source
patching sources
applying patch /nix/store/pbip32vbqclwbcnmr71w22md0wlhj264-darwin_dylib.patch
patching file library/Makefile
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file library/Makefile.rej
builder for '/nix/store/12gar1z0sli0rdkpxdpy9d32i4x6kfp6-mbedtls-2.9.0.drv' failed with exit code 1
error: build of '/nix/store/12gar1z0sli0rdkpxdpy9d32i4x6kfp6-mbedtls-2.9.0.drv' failed

Success on x86_64-linux (full log)
Attempted: mbedtls
Partial log (click to expand)
shrinking /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_cert_app
shrinking /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_cert_req
shrinking /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_cert_write
shrinking /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_crl_app
shrinking /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin/mbedtls_req_app
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/lib  /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0/bin
patching script interpreter paths in /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0
checking for references to /build in /nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0...
/nix/store/3k23m5xwfjjwmyj7q311blpk4wl204ks-mbedtls-2.9.0

Success on aarch64-linux (full log)
Attempted: mbedtls
Partial log (click to expand)
shrinking /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/bin/mbedtls_crypt_and_hash
shrinking /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/bin/mbedtls_aescrypt2
shrinking /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/lib/libmbedcrypto.so.2
shrinking /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/lib/libmbedx509.so.0
shrinking /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/lib/libmbedtls.so.10
strip is /nix/store/gp7fylxwn18b7pl2c18ks89hsiaxyfvf-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/lib  /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0/bin
patching script interpreter paths in /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0
checking for references to /build in /nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0...
/nix/store/0gy9ryqggljnj55b9gk8h49y4yx39bw6-mbedtls-2.9.0

This update has security fixes.

It looks like this invalidates the Darwin patch:
https://hydra.nixos.org/build/73716288
Does it look safe to remove?

seems so. I give it a shot: https://github.com/NixOS/nixpkgs/pull/40137

fixed.


API Version error on openeocloud.vito.be

import openeo

con = openeo.connect("openeocloud.vito.be")
con.list_processes()

# ->  OpenEoApiError: [500] Internal: Requested API version 1.1.0 != expected 1.0.0 (ref: r-64c75ab3fbb64a7c92bbe399763343f9)

reason: openeocloud.vito.be resolves throught (well-known/openeo) to https://openeocloud.vito.be/openeo/1.1/ (so version 1.1.0),
but aggregator still uses 1.0.0 version backend connections
and that gives this conflict:
https://github.com/Open-EO/openeo-aggregator/blob/b62b6f2295df05efc701a3cff4d1c7c3b3fdcf8b/src/openeo_aggregator/backend.py#L410-L414


PIMCOPY - The company doesn't exist on Scrapper.UI

ENVIRONMENT: production
URL: https://scrapers.peviitor.ro/
Browser: Chrome
Device: Laptop
OS: Windows 10
STEPS TO REPRODUCE:

Open the url
Type "pimcopy" in search field

EXPECTED RESULTS:
Should have a result with Pimcopy company
ACTUAL RESULTS:
Pimcopy company doesn't exist  on Scraper.UI
Attachments:

fixed

Retested


Remove planned refactoring needed for the NANODBC_HANDLE_NODATA_BUG

There isn't an easy way to automatically handle buggy drivers.
See #33 for detailed discussion.

:+1:


Correction for raw affiliation Schulich Interfaculty Program in Public Health, Western University, London, ON

Correction needed for raw affiliation Schulich Interfaculty Program in Public Health, Western University, London, ON
raw_affiliation_name: Schulich Interfaculty Program in Public Health, Western University, London, ON
new_rors: 02grkyz14
previous_rors: 02agqkc58
works_examples: W4378172479;W4366463608
contact: 2930e9d1621f9801d3c8b0ee2b3ad662:9c7543dddc096a20 @ uwo.ca

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


Per the kernel oops above, it appears that a syscall from kubelet led to the panic, but beyond that I don't have much more insight.
After digging into the stack a little bit more, one possibility is that dname (returned by blkg_dev_name()) was a bad pointer: link.  When later deferenced as part of the %s formatting in seq_printf, it could have generated the memory protection fault.
Interestingly, it would not have been a null pointer, as that is explicitly checked here.
I looked through the Kernel bugtracker, and was not able to find any bugs that seemed related.
What you expected to happen:
No kernel panic.
How to reproduce it (as minimally and precisely as possible):
I unfortunately do not have a repro—this has only occurred once in our clusters.
Anything else we need to know?:
Environment:

AWS Region: us-west-2
Instance Type(s): r5.12xlarge
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion): eks.6
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): 1.19
AMI Version: ami-01a9605bd94e3d03d
Kernel (e.g. uname -a): Linux ip-100-122-23-239.us-west-2.compute.internal 5.4.110-54.189.amzn2.x86_64 #1 SMP Mon Apr 26 21:25:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Release information (run cat /etc/eks/release on a node):

BASE_AMI_ID="ami-004a571bc4ab7023a"
BUILD_TIME="Tue May  4 05:17:05 UTC 2021"
BUILD_KERNEL="5.4.110-54.189.amzn2.x86_64"
ARCH="x86_64"

@aweeks have you observed this on any newer kernel version, or more than once on 5.4.110-54.189.amzn2.x86_64?

Without steps to reproduce, there's probably not much we can do here. There have been many revisions to the kernel and several to the kubelet since this occurred; so please update to the latest AMI and create a new issue (referencing this one) if you observe this again.


One texture in two different slots

axmol version:
devices test on:
developing environments

NDK version: r23c
Xcode version: 14.2+
Visual Studio:

VS version: 2022 (17.9+)
MSVC version: 19.39+
Windows SDK version: 10.0.22621.0+

cmake version:
Steps to Reproduce:

Direct me please if it is bad designe from my side. Really I can avoid this case (and will do), but it happend in my application.
One shader use's some texture with slot 7. The second shader use's the same texture with slot 8. The second shader is drawn right after the first according to the accident.
Then the texture will not be bind to the slot 8 for the second shader

go to the config and turn off gl state cache and see if that helps

With disabled ...GUARD... macros texture works as expected, since bind will pass, but this feature reduce gl calls

The cache should process active slot and texture binding

@solan-solan please check latest commit: https://github.com/axmolengine/axmol/commit/2701bd10881df9ae7e8fb0b6d4417c39b93bd9ce

@halx99 I checked and it looks very good optimization, since there are no more extra texture bindings for objects which use multiple textures (ex. diffuse, then normal map) and drawn one by one. Thanks for this


bulk update method

Initial patch, still need to create the unittest and workqueue part change.

Updated unittests and WorkQueue changes. @amaltaro, Alan please review

Yes I will test performance between bulk and individual update. Still unittest failure seems to be real. Although I am sure what cause that. I am investigating

I ran some performance test which is not very accurate since it on connect local couch, document site is small, there could be other facts affecting this.
5000 document update.

update individually - 42 sec
2 update bulk with 1000 chuck (5 calls) - 2 sec

Wow! 2 secs for the 5k docs or for each slice? Not bad at all! :)

There are other factors involved though. The difference in between two other than bulk and one aspect.
The formal needs to retrieve all the content in the doc and the latter is in place change.
So it will be less call for bulk but it will be much more data transfer. However it WQE is pretty small per doc and we can control size of the bulk. I think it will be overall helpful but might have some side effect.
Also the test skips authentication so it will be beneficial in that aspect in real situation.
Anyway, I have to fix the unittest in WQ which is really odd.

test this please

@amaltaro, Alan I updated the patch as you suggested. Could you review again? Thanks

test this please

@amaltaro, Alan finally fix all the unittest. There are 6 unittests failing in WQ but not because of this patch. I will try to look at them in separate patch. Please review.

Ahh, I forgot mentioning. Since you created a unittest, how about creating a second one (and maybe a third one) that would hit a doc conflict with maxRetries>0 (and another with maxRetries=0)?

test this please


If Ctrl+W already bound to Window.CloseDocumentWindow, pressing it closes two documents

I've installed this (great!) extension, and got a strange behavior: pressing Ctrl+W closes two documents (if open).
One clue was that they wasn't being closed in parallel, but one after one, like someone pressed Ctrl+W twice instead of one.
In the start, I suspected my keyboard is the reason. But Ctrl+F4 worked great.
I wanted to report it to Developer Community, so I opened VS in Presentation Mode, but suddenly the problem disappeared.
I changed the relevant settings of Presentation Mode, still problem refuse to reproduce.
I opened VS in Safe Mode, and problem still not there. Here I understood that one of my extensions was the factor.
So I started exploring my extensions, and found this one. I forgot that I installed it, so I took a look at its documentation. And I saw it changes the behavior of Ctrl+W to close the current document. Great, I thought, I already had that in my VS. VS Code and Chrome, you know... All use Ctrl+W.
Just a moment - did I have it before? Maybe this is the cause? So I removed my custom keyboard shortcut, and problem disappeared!
TL;DR: This extension still executed Ctrl+W shortcut, which causes bugs if it closes document.
The simple fix will be to define Ctrl+W as a VS shortcut and not custom code; However, this will force us to save the previous shortcut in order to restore it in case of uninstallation. Another, somewhat more complicated fix, will be to not execute the code if Ctrl+W already bound to Close Document.

I hit this problem too so ended up removing the CTRL+W keyboard mapping and just relying on Tweaks.

@danielgreen-nes This is what I did too, but this is still a bug 😃


Syntax highlighting example

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Problem
Not working with remark-prism.
Solution
Any lightweight syntax highlighter support.
Alternatives
Can't find any alternatives.

There is not enough information to help. "Not working with remark-prism" is not an helpful issue. Please refer to asking quality questions.
In the meantime, I recommend taking a look at this example with react-markdown: https://github.com/remarkjs/react-markdown#use-custom-components-syntax-highlight. The components prop from that package is similar to rehypeReactOptions.components from this package so it could serve as inspiration. Alternatively, switch to react-markdown and use that example.

https://stackblitz.com/edit/nextjs-sfulsg?file=pages/index.js


Error message when trying to use Esri Maps for Office

When I try to add a map in excel, I get an error message.

I can not reproduce this issue with Office 2013 and Esri Maps for Office 3.0. Please ensure you have the latest software installed.


Manually installed distro - Unregister distro leaves traces on filesystem

Windows Build Number
Microsoft Windows [Version 10.0.18363.1500]
WSL Version

[ ] WSL 2
[X] WSL 1

Kernel Version
No response
Distro Version
No response
Other Software
No response
Repro Steps

Download any distro from Docs page - in my case Kali-linux
Install it by executing .appx file
List installed distros

PS T:\> wslconfig.exe /l
Windows Subsystem for Linux Distributions:
Debian (Default)
kali-linux

Unregister distro

PS T:\> wslconfig.exe /u kali-linux
Unregistering...
PS T:\> wslconfig.exe /l
Windows Subsystem for Linux Distributions:
Debian (Default)
PS T:\>

Expected Behavior
According documentation wsl --unregister <distro> or wslconfig /u <distro> will delete whole distro. I'm expecting that there will be no traces for kali-linux after unregistering.
Actual Behavior
After unregistering distro, I can see empty files and folders of unregistered distro - in my case kali-linux

I can still se kali-linux in Start menu, which will start installing distro again. There is no uninstall button on right click menu, under Settings -> Apps & features Uninstall button is grayed.
I don't see any way how to properly delete that manually installed distro, only by manually searching for files on filesystem, and hoping that there are no more places where some files could be (%APPDATA%, Program Files, etc).
Diagnostic Logs
No response

Unregistering a distro does not uninstall the associated app, it only deletes the Linux filesystem.


make one for all offsets, walkspeed etc

yes im already planning on doing that but that will be a seperate project


Add connect API

This change adds support for the new /catalog/connect/:service API (https://www.consul.io/api/catalog.html#serviceconnect).
Tests are included with full coverage, although I could not get the acceptance tests to run with the instructions given in the Readme.

Awesome, great work! I'll get it deployed to npm shortly.

Published to npm<EMAIL_ADDRESS>


Through using script how could I return the used_gas of a transaction call?

I was wondering is it possible to return and print the transaction's used gas through script.
When I print returned value of the transaction call it returns me the transaction object I guess along with its transaction_receipt. But in addition to that how could I obtain its consumed gas and maybe additional information related to that transaction?
tx = my_contract().function({'from': accounts[0]})
print(tx)

The output I get:
<Transaction object '0xc1feb1714b6f7ffb5b0b232484c6a1c5d937bf55a9d36b3c0b42052566d956bc'>

When I do tx. and tab in console it doesn't return me its functions that I can use.

Following approach solved my problem:
print(' => GasUsed:' + str(tx.__dict__['gas_used']))

The documentation for TransferReceipt will probably help.
https://eth-brownie.readthedocs.io/en/latest/api.html#transactions
You can print tx.gas_used or if you want more detailed information, use tx.info()


CMake project config which suports non-ROS build

Back again this year with a PR to my issue #16 from last year.
It installs and works as expected with a plain non-ROS build (pure C++ lib).
I also tested with ROS Melodic; the launch file, tests and using it in another ROS package.
(However, I'm not that experienced with ROS so you should check it ourselves that it installs and everything as expected.)
The pure C++ lib part of the CMake is mostly according to modern CMake best practices, the ROS part is just adopted from the original configuration.
The if statement with BUILD_WITH_ROS was needed twice since the catkin_package() was needed before add_library().
I guess a version bump is needed if this is merged. What version do you want?
It would be nice if @Timple also could take a look at it.

Thank you for asking my input. I took a quick swing at it before diving into the changes:
/usr/bin/ld: /home/timple/ros/devel/.private/steering_functions/lib/libsteering_functions.a(cc00_dubins_state_space.cpp.o): relocation R_X86_64_PC32 against symbol `_ZTVN8steering23CC00_Dubins_State_SpaceE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/utils.dir/build.make:285: /home/tim/ros/devel/.private/harvey/lib/harvey_utils.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:7915: CMakeFiles/utils.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:141: all] Error 2

Does this look familiar or do you have some easy things to check for me?

Thank you for asking my input. I took a quick swing at it before diving into the changes:
/usr/bin/ld: /home/timple/ros/devel/.private/steering_functions/lib/libsteering_functions.a(cc00_dubins_state_space.cpp.o): relocation R_X86_64_PC32 against symbol `_ZTVN8steering23CC00_Dubins_State_SpaceE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/utils.dir/build.make:285: /home/tim/ros/devel/.private/harvey/lib/harvey_utils.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:7915: CMakeFiles/utils.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:141: all] Error 2

Does this look familiar or do you have some easy things to check for me?
Adding this fixes the issue:
target_compile_options(${PROJECT_NAME}
    PRIVATE
        -fPIC
)

But I'm not sure if this is desired or common practice.

Hmm. I think the idiomatic CMake way to set the flag is:
option(CMAKE_POSITION_INDEPENDENT_CODE "Build position independent code." ON)

or
set_property(TARGET ${PROJECT_NAME} PROPERTY POSITION_INDEPENDENT_CODE ON)

However, this flag is always enabled by default in CMake when building a shared library (creating an libsteering_functions.so file), e.g. by setting BUILD_SHARED_LIBS to ON.
It seems you are building this library as static (libsteering_functions.a file), but your library harvey_utils.so is built as shared library. Just out of curiosity, can you try to build and link to the steering_functions lib on master branch without altering your harvey_utils toolchain setup?

Just out of curiosity, can you try to build and link to the steering_functions lib on master branch without altering your harvey_utils toolchain setup?

It does.
Comparing compilation with the master branch, I notice that the ros node is also binary different. Perhaps this gives an indication?

Could you take a look now?
I noticed that catkin builds the shared library of the master branch so by introducing the explicit CMake option (and defaulting it to OFF), I had changed the behaviour compared to maste branch. I removed the explicit option and now this branch also defaults to shared library with catkin.
I also changed back to the original behavior of the ROS node executable. It builds with all the source files instead of linking to the (shared) library steering_functions. Which is a rather strange choice, but to avoid breaking things I reverted back. (Doesn't matter to me since I don't use ROS).

It works now. Only the removal of option(BUILD_SHARED_LIBS "Build as shared library" OFF) seemed to be enough.
Personally I would keep the restructure you had. That the node actually uses the library. You are right that this makes most sense.

Still works :slightly_smiling_face:. So no objections for me.
I'm a user however, not a maintainer, so this is up to @hbanzhaf

@vebjornjr Could you please also update the README with how to build this package with and without ROS?

Done. I guess a version bump is needed too. What version do you want?

@Timple To which version number should we increment?

As far as I'm concerned it's a backwards compatible change.
So 0.2.0?

@vebjornjr Happy to merge this PR once the other minor comments are also resolved.

Which comments to you refer to, @hbanzhaf? I was under the impression that I had resolved all.

Friendly ping @hbanzhaf


Make DAP pins customizable from application sketches.

Hi.
I'm currently working on my DAPLink adapter which makes XIAO to DAPLink.
This library works well except that the pin definitions of DAP is not configurable from its application sketches.
Due to this limitation, I have to modify DAP_config.h file to change DAP pin definitions to adapt to my adapter board.
This PR removes the limitation by making DAP pins runtime configurable via newly added setPin API to change DAP pins.
There are no performance degradation. Actually, the throughput is improved slightly by caching PortGroup address.
(In my environment, loading ELF file throughput is increased from 14[kiB/s] to 20[kiB/s].)
In order to use the new API, all we have to do is just add pin configuration codes in the  setup() function before calling DAP_Setup()
If the application developer does not call the setPin API, the default pin mappings are used.
void setup() {
    USBDevice.setProductDescriptor("CMSIS-DAP");
    USBDevice.addInterface(cmsisdap_v2);

// Change DAP pins for my DAP adapter.
    SWDIOPin.setPin(A9);
    SWCLKPin.setPin(A8);
    TDIPin.setPin(A5);
    TDOPin.setPin(A4);
    nRESETPin.setPin(A0);

    pinMode(LED_BUILTIN, OUTPUT);

    baud = old_baud = 115200;
    Serial.begin(baud);
    SerialTTL.begin(baud);

    // wait until device mounted
    while( !USBDevice.mounted() ) delay(1);

    DAP_Setup();
}

@ciniml  Can you provide examples to show how this function is used?

@Pillar1989 I've added custom_pins.ino as an example of the new pin configuration API.

Thanks


phpmyadmin in merecat?

I open a new thread, phpmyadmin in mercat ?, not really, but if someone has been able to make "phpminiadmin" work in merecat I would appreciate it http://phpminiadmin.sourceforge.net/ , it's a simple script in php

Not a PHP user myself.  But I did some work to get php-cgi to work earlier, just like other CGIs.  Dunno if you need env. variables or sth for phpminiadmin, but it's possible it works as is using the the latest GIT master.  Some info on PHP and CGI is in the man pages.

Tested setting up Maria DB with phpMyAdmin today.  With the latest bug fixes I pushed today, it works ... :open_mouth:
I used Debian 10, installed everything from scratch.  Used the default Apache first, just to bootstrap everything.  Then started Merecat on port 8080 instead of the default.   The only real adaptations I had to do, except for enabling PHP (with the correct CGI pattern), was to make sure to run merecat with sudo and set username = www-data in my merecat.conf ... otherwise the /var/lib/php/sessions cannot be read.


time_local and launch_date do not give timezone.

https://api.spacexdata.com/launches
The time_local does not specify the time zone.
Also, there will be (rare) cases where time_utc and time_local occur on different days, it will, therefore, be ambiguous as to which the launch_date agrees with.
Possible solutions to the latter would be:

changing the launch_date key to launch_date_utc
a new key launch_date_utc or launch_date_local, whichever launch_date isn't
instead replacing them with new variables launch_date_utc and (launch_date_local or local_timezone) in the ISO 8601 fomat. Stack Overflow discussion here, linked article here

I'll go ahead and convert them to date/time stamps for UTC and Local
For example:
Flight 1
"launch_date_utc" : "2006-03-24T22:30:00Z"
"launch_date_local" : "2006-03-24T22:30:00+12:00"

Would the local time even be necessary at that point?

You could just give a local_timezone, but I think it would be easier to
keep it as you have put it above!
On 13 Jul 2017 23:09, "Jake Meyer"<EMAIL_ADDRESS>wrote:

Would the local time even be necessary at that point?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/r-spacex/SpaceX-API/issues/23#issuecomment-315215986,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK6RagYgIyglnaAoWQr1A_iYg-fuwO7kks5sNpWvgaJpZM4OXgvT
.

Sounds good 👍  I'll get started on that

One issue that is food for thought is that it is hard to get a 'readable' time zone from this syntax i.e 'EST' or 'PDT'. Why is time always so complicated!?

That's the only real downside to using timestamps like this, since it doesn't allow for it

All previous and upcoming dates have been converted
https://api.spacexdata.com/launches


feat: support creating partition tables with different window widths (PROOF-893)

Rationale for this change
In order to experiment with different window widths for partition tables and perhaps find values that lead to better performance, this PR makes the window width an option when creating partition tables instead of fixing it to 16.
What changes are included in this PR?

rework functions to creating partition tables to accept a window width argument

Are these changes tested?
Yes

:tada: This PR is included in version 1.71.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[FEATURE] Support SkCanvas::drawImageRect

Is your feature request related to a problem? Please describe.
This Skia API function is not supported.
Describe the solution you'd like
Add support for this.
Describe alternatives you've considered
It seems SKCanvas::drawImage does not perform subpixel sampling, so e.g. fractional source cropping is not possible with it. It seems drawImageRect can do this, at least that's what I understand from the comments.

https://api.skia.org/classSkCanvas.html#a769bf7da37709068444a0d05243aa22a
void drawImageRect (const sk_sp< SkImage > &image, const SkRect &src, const SkRect &dst, const SkPaint *paint, SrcRectConstraint constraint=kStrict_SrcRectConstraint)
Draws SkRect src of SkImage image, scaled and translated to fill SkRect dst. More...
I think SKCanvas::drawImage does not supports subpixel sampling too.
You can call ClipRect first to draw a part of an image.

https://api.skia.org/classSkCanvas.html#a769bf7da37709068444a0d05243aa22a
void drawImageRect (const sk_sp< SkImage > &image, const SkRect &src, const SkRect &dst, const SkPaint *paint, SrcRectConstraint constraint=kStrict_SrcRectConstraint)
Draws SkRect src of SkImage image, scaled and translated to fill SkRect dst. More...
I think SKCanvas::drawImage does not supports subpixel sampling too.
You can call ClipRect first to draw a part of an image.


Eye Tracking Roaming

When testing eye tracking, from what can be deciphered, rotation on both x and y axes takes on a "drift" that causes a kind of false momentum which causes the eyes to continue moving for several values in the previous direction when the direction is reversed.
Resolution appears to come from changing the viewport type (in most cases, from "solid" to "material preview"), but sometimes does not help. Restarting Blender seems to help in resolution. Opening certain software (in this case, OBS) causes the issue to compound irrationally, in one case causing the eyes to pop forward out of the head and down as if falling out. This also ceased when restarting Blender.
Example video:
https://youtu.be/sw_MokdkpjU

Thanks for the report, this is now fixed in the development version of cats and will be released soon. For now you can just install the development version in cats via the build-in updater.


detail.op isn't given on X86

Take the homepage's example code and add d.option(cs.OPT_DETAIL, cs.OPT_ON);
Now try to print instr.detail.op, it should be an array, but it's not given. op_count from here is also 0, but shouldn't it be a real value if detail mode is on?

Hey @darkf! Not sure what's causing this, it's very likely that I messed writing the parser for those structures. I'm a bit busy these days, but I'll try to fix this issue (and update to Capstone 4.0.1!) in early May.

I've just updated to Capstone 4.0.1 and fixed a bug in cs_close that corrupted the memory (no idea how that didn't cause issues earlier). Regarding your issue, it turns out the way I computed offsets in for the cs_detail members was wrong. This is now fixed and should work fine CS_ARCH_X86, as of 8f488ca.
The cs_detail members for the remaining architectures still need to be fixed (and the architectures added in Capstone 4.x need to be added to the wrapper as well). Other than that, regular decoding should work fine.


Add redis and mysql volumes to docker compose

@RustyBower The volumes are actually 'named' volumes, so they won't be stored locally in the git repo, they will be stored in '/var/lib/docker' I believe, so we shouldn't need to add it to .gitignore


platinum-sw-fetch event handler for POST requests

I'm using platinum-sw-fetch component to map fetch requests to handlers inside service workers. It works well for "GET" requests but not for "POST" requests. One of my use case is returning fixture data for my requests.
After digging polymer code, I found that are defined routes (by sw-toolbox library) only for "GET" requests:

sw-toolbox-setup.js
...
 if (typeof handler === 'function') {
        global.toolbox.router.get(routeParams[0], handler, originParam);
      } else {
        console.error('Unable to register sw-toolbox route: ', routeParams);
      }
...

Is there an option for registering handlers for "POST" request?

Hi @ioantomulesei,
This is just a suggestion because I'm not part of the Google team, but I think this issue should be reported in https://github.com/PolymerElements/platinum-sw/issues (which is the repo of platinum elements).

This issue was moved to PolymerElements/platinum-sw#82


Tabris 2.x to 3.x migration

This page describes changes, but does it exist a tool which analyze my source and lists difference?
How can I "backport" a 3.x script to 2.x to run it on windows?

There isn't a tool for either of your questions.  You'll need to perform the migrations manually.

I am trying, with no success: is "tabris-decorators" implemented or not in 2.x? According to documentation it is, but none of these lines  works in developer app for 2.x:
const {ItemPicker, List} = require('tabris-decorators');
import {ItemPicker, List} from 'tabris-decorators';

You'll want to switch to the older version which is compatible with the (deprecated) 2.x

how do I enable it in palyground of developer app 2.x?

You can access the legacy playground

Yes, that's what I'm doing...
I copied my script from new playgorund  to legacy playground, and tabris 2.x raises this errors:
import {ItemPicker, List} from 'tabris-decorators';  --> syntax error, unexpected token import
const {ItemPicker, List} = require('tabris-decorators');  -->  Could not load main module: Error: Cannot find module 'tabris-decorators'

We are discussing at same time in slackand here... anyway syntax "import from"  works fine in Tabris 3.8.0, but only for "tabris", not for "tabris-decorators"

import {ItemPicker, List} from 'tabris-decorators'; --> syntax error, unexpected token import

This isn't es5 syntax.  Only es5 is supported.

const {ItemPicker, List} = require('tabris-decorators'); --> Could not load main module: Error: Cannot find module 'tabris-decorators'

only the tabris package is available on the playground.  You'll need to download tabris-cli to use the developer app with any other packages or plugins

It's a pity, in new playground it's available.
So is there any way to debug tabris2/windows apps online, without installing node.js on PC?

You could install node.js on someone else's computer

Then I assume the answer is "no, because a bug in playground of 2.x prevents from testing app  in developer app for 2.x"

Where can I find the source code of the examples of the android developer app for 2.x and for windows developer app?

Then I assume the answer is "no, because a bug in playground of 2.x prevents from testing app in developer app for 2.x"

What bug?

Where can I find the source code of the examples of the android developer app for 2.x and for windows developer app?

https://github.com/eclipsesource/tabris-js/tree/1f410683f1d52f5fc5557947ffe272c4e5c45eb8/snippets

Where can I find the source code of the examples of the android developer app for 2.x and for windows developer app?

https://github.com/eclipsesource/tabris-js/tree/1f410683f1d52f5fc5557947ffe272c4e5c45eb8/snippets

These are for 3.x. I'd need the ones for 2.x:

Specifically, the "input elements" one:

Found in archive:
https://github.com/eclipsesource/tabris-js/blob/f594fbaca6101d792f5e2ca1144dd729d25fd4a6/snippets/input.jsx

Where can I find the source code of the examples of the android developer app for 2.x and for windows developer app?

https://github.com/eclipsesource/tabris-js/tree/1f410683f1d52f5fc5557947ffe272c4e5c45eb8/snippets

These are for 3.x. I'd need the ones for 2.x:

Actually, these are for 2.x.  On GitHub we can view the list of tagged releases and we can see that the 2.9 release was tagged at 1f410683f1d52f5fc5557947ffe272c4e5c45eb8.  Clicking on that commit hash will allow us to browse the source code at that version number.

Found in archive:
https://github.com/eclipsesource/tabris-js/blob/f594fbaca6101d792f5e2ca1144dd729d25fd4a6/snippets/input.jsx

Using the same methodology as above we can browse the source at that revision and determine that this commit you found is not for 2.x, it is much newer: it is from the 3.8 release

I have no idea of how to select a  specific version of a repo, I just looked for "flyer" in the whole repo (a keyword I've seen in the screenshot)  and I found that file...
Anyway, back to the topic,  to back-migrate from 3.x to 2.x, should I convert all the interface declarations from .JS style to .JSX style?

You can use JS, JSX, TS, or TSX, whichever you prefer


TypeError: Object # has no method 'toArray'

aggregation query returns a cursor in Mongo 2.6. According to native-mongodb-driver documentation, to read the cursor, we do something like this:
var MongoClient = require('mongodb').MongoClient;
MongoClient.connect("mongodb://localhost:27017/test", function(err, db) {
  var collection = db.collection("ag");

  var cursor = collection.aggregate([{ $group : {_id: '$a'}}], {cursor:{batchSize:100}});
 var docs = cursor.toArray();
});

when I try the same with Mongoskin 1.4.4, I get the error:
TypeError: Object #<SkinClass> has no method 'toArray'

Hi. Any update on this?
I am using hapi-app-mongo-model which is built over monk, which is built over mongo-skin... that fix would be really appreciated


⚠ Bofrost.nl has degraded performance

In 4d6c324, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1682 ms

Resolved: Bofrost.nl performance has improved in 54fc093.


Add maaz's name to contributors list

@MuaazBin, I'm quite elated about your PR. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a PR and learned that I merged it?

I loved the tutorial. It was easy to follow and quite well written. Would love to see more such tutorials related to git.

@MuaazBin, I’d urge you to continue contributing to other open source projects.
We also have a slack team to help/mentor people trying to contribute to open source projects.
You can join the team by going to https://firstcontributions.herokuapp.com


Feature output file

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue#6)
Type of change

[ ] New feature (non-breaking change which adds functionality)
[ ] This change requires a documentation update

Thanks for the PR!
Some feedback:

The actual output to CSV should go into generic.Outputs. Then you call this from cli.py.
There are too many redundant commits in your branch :sweat_smile:. Consider squashing them.
Some more feedback in the review


Admin Dashboard

Yes, The admin should be able to read, edit, and destroy all the data in the system.

Yes, The admin should be able to read, edit, and destroy all the data in the system.

What kind of info will be displayed, like from which table columns?

roles, users, f.aid groups, f.aids, applications, reports, messages, still loading others

maybe applicants, donors and donations as well.