ABI mismatch between transaction kernel API and compiled Wasm Canonical ABI

Problem
The transaction kernel and its user-facing API uses the ad-hoc ABI for function parameters and results. See its usage in the basic wallet contract at https://github.com/0xPolygonMiden/miden-base/blob/9f57fb2f088679a192e48f1f8ee83435e57bf24a/miden-lib/asm/miden/contracts/wallets/basic.masm#
The MASM code compiled from Rust (Wasm component model) uses the Canonical ABI for function parameters and results.
Since the user code in Rust needs to call the transaction kernel API, their ABIs must match.
Solution
Rewrite the transaction kernel API functions to use the Canonical ABI.
Since there are Pioneers that are intended to write MASM code directly against the existing transaction kernel API, we might want to make it sooner rather than later to avoid the Pioneer code breakage.

What would be a few examples of how we'd need to change kernel procedures to comply with the canonical ABI? For example, in the accounts module.

The most affecting changes will be due to the following Canonical ABI rules:

Anything larger than 8 bytes (i64) is returned via a pointer passed as an argument;
Parameters of complex types (think Asset) are encoded according to Canonical ABI lowering rules.

Let's look at the account::add_asset:
#! Add the specified asset to the vault.
#!
#! Panics:
#! - If the asset is not valid.
#! - If the total value of two fungible assets is greater than or equal to 2^63.
#! - If the vault already contains the same non-fungible asset.
#!
#! Stack: [ASSET]
#! Output: [ASSET']
#!
#! - ASSET' final asset in the account vault is defined as follows:
#!   - If ASSET is a non-fungible asset, then ASSET' is the same as ASSET.
#!   - If ASSET is a fungible asset, then ASSET' is the total fungible asset in the account vault
#!     after ASSET was added to it.
export.add_asset
    syscall.account_vault_add_asset
end

So far I designed the WIT type for Asset as follows(variant asset):
    type felt = u64;
    type word = tuple<felt, felt, felt, felt>;

    record fungible-asset {
        asset: account-id,
        amount: u64
    }

    type non-fungible-asset = word;

    variant asset {
        fungible(fungible-asset),
        non-fungible(non-fungible-asset),
    }

https://github.com/0xPolygonMiden/compiler/blob/9a0302a7bc54cdbd07de07355c11b939a50815ea/tests/rust-apps-wasm/sdk/sdk/wit/miden.wit#L88-L91
And a add_asset kernel transaction API as:
    add-asset: func(asset: asset) -> asset;

https://github.com/0xPolygonMiden/compiler/blob/9a0302a7bc54cdbd07de07355c11b939a50815ea/tests/rust-apps-wasm/sdk/sdk/wit/miden.wit#L105
I'm using it in the basic wallet code as follows:
#![no_std]

cargo_component_bindings::generate!();

use bindings::exports::miden::basic_wallet::basic_wallet::{Asset, Guest, Recipient, Tag};
use bindings::miden::base::tx_kernel::{add_asset, create_note, remove_asset};

struct Component;

impl Guest for Component {
    fn receive_asset(asset: Asset) {
        add_asset(asset);
    }

    fn send_asset(asset: Asset, tag: Tag, recipient: Recipient) {
        let asset = remove_asset(asset);
        create_note(asset, tag, recipient);
    }
}

https://github.com/0xPolygonMiden/compiler/blob/9a0302a7bc54cdbd07de07355c11b939a50815ea/tests/rust-apps-wasm/sdk/basic-wallet/src/lib.rs#L1-L19
And here is how the add_asset is expected according to the Canonical ABI to pass the parameter and receive the result. Let's look at the generated bindings (add_asset is wit_import):
      #[allow(unused_unsafe, clippy::all)]
      /// Add the specified asset to the vault
      pub fn add_asset(asset: Asset,) -> Asset{

        #[allow(unused_imports)]
        use ::cargo_component_bindings::rt::{alloc, vec::Vec, string::String};
        unsafe {

          #[repr(align(8))]
          struct RetArea([u8; 40]);
          let mut ret_area = ::core::mem::MaybeUninit::<RetArea>::uninit();
          use super::super::super::miden::base::types::Asset as V2;
          let (result3_0,result3_1,result3_2,result3_3,result3_4,) = match asset {
            V2::Fungible(e) => {
              let super::super::super::miden::base::types::FungibleAsset{ asset:asset0, amount:amount0, } = e;

              (0i32, ::cargo_component_bindings::rt::as_i64(asset0), ::cargo_component_bindings::rt::as_i64(amount0), 0i64, 0i64)
            },
            V2::NonFungible(e) => {
              let (t1_0, t1_1, t1_2, t1_3, ) = e;

              (1i32, ::cargo_component_bindings::rt::as_i64(t1_0), ::cargo_component_bindings::rt::as_i64(t1_1), ::cargo_component_bindings::rt::as_i64(t1_2), ::cargo_component_bindings::rt::as_i64(t1_3))
            },
          };
          let ptr4 = ret_area.as_mut_ptr() as i32;
          #[cfg(target_arch = "wasm32")]
          #[link(wasm_import_module = "miden:base/tx-kernel@1.0.0")]
          extern "C" {
            #[link_name = "add-asset"]
            fn wit_import(_: i32, _: i64, _: i64, _: i64, _: i64, _: i32, );
          }

          #[cfg(not(target_arch = "wasm32"))]
          fn wit_import(_: i32, _: i64, _: i64, _: i64, _: i64, _: i32, ){ unreachable!() }
          wit_import(result3_0, result3_1, result3_2, result3_3, result3_4, ptr4);
          let l5 = i32::from(*((ptr4 + 0) as *const u8));
          use super::super::super::miden::base::types::Asset as V12;
          let v12 = match l5 {
            0 => {
              let e12 = {
                let l6 = *((ptr4 + 8) as *const i64);
                let l7 = *((ptr4 + 16) as *const i64);

                super::super::super::miden::base::types::FungibleAsset{
                  asset: l6 as u64,
                  amount: l7 as u64,
                }
              };
              V12::Fungible(e12)
            }
            n => {
              debug_assert_eq!(n, 1, "invalid enum discriminant");
              let e12 = {
                let l8 = *((ptr4 + 8) as *const i64);
                let l9 = *((ptr4 + 16) as *const i64);
                let l10 = *((ptr4 + 24) as *const i64);
                let l11 = *((ptr4 + 32) as *const i64);

                (l8 as u64, l9 as u64, l10 as u64, l11 as u64)
              };
              V12::NonFungible(e12)
            }
          };
          v12
        }
      }

https://github.com/0xPolygonMiden/compiler/blob/9a0302a7bc54cdbd07de07355c11b939a50815ea/tests/integration/expected/sdk_basic_wallet/bindings/basic_wallet_bindings.rs#L152-L217
If you look at the kernel API add_asset call - wit_import(result3_0, result3_1, result3_2, result3_3, result3_4, ptr4);. It has the following parameters:

result3_0 - is a variant type 0 for Fungible and 1 for NonFungible;
result3_1 - result3_4 - are encoded variant values; in case of Fungible it's asset,amount, 0, 0), in case of NonFungible it's t1_0, t1_1, t1_2, t1_3 (the word type); See the Rust code above for lowering before the call;
ptr4 - is a pointer to the result area where the returned asset value must be written using the same encoding as above. See the Rust code above for lifting after the call.

Anything larger than 8 bytes (i64) is returned via a pointer passed as an argument;

Hmm - I'm not sure this is a good idea. I believe we discussed previously that words (i.e., 32 bytes) would be passed by value. This is very important as the alternative would be much less efficient. We may need to discuss how to bridge the gap here.

So far I designed the WIT type for Asset as follows(variant asset):
    type felt = u64;
    type word = tuple<felt, felt, felt, felt>;

    record fungible-asset {
        asset: account-id,
        amount: u64
    }

    type non-fungible-asset = word;

    variant asset {
        fungible(fungible-asset),
        non-fungible(non-fungible-asset),
    }

Let's discuss this as well as this is different from how we define assets in the kernel. Technically, the is really Asset(Word) - and I'm not quite sure what's the best way to express this in a higher-level language.


Health API not working with Triton Inference Server

/kind bug
What steps did you take and what happened:
[A clear and concise description of what the bug is.]
I'm using Triton Inference Server for model deployment and have built a frontend to access it. I make a health request to check if the model exists that I currently want to use. This health request returns
"*   Trying <IP_ADDRESS>:8000...

TCP_NODELAY set
Connected to localhost (<IP_ADDRESS>) port 8000 (#0)

GET /v2/models/inception_graphdef/versions/1/ready HTTP/1.1
Host: localhost:8000
User-Agent: curl/7.68.0
Accept: /

Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 0
< Content-Type: text/plain
<
Connection #0 to host localhost left intact
"

when used through command line  as "curl -v localhost:8000/v2/models/inception_graphdef/versions/1/ready"
What did you expect to happen:
The problem is that on my frontend it gets stuck at this get request, so I tested it on postman. It didn't return anything on postman either. I am on Linux and this request gives appropriate output on Windows in postman and in my application.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:

Istio Version:
Knative Version:
KFServing Version:
Kubeflow version:
Kfdef:[k8s_istio/istio_dex/gcp_basic_auth/gcp_iap/aws/aws_cognito/ibm]
Minikube version:
Kubernetes version: (use kubectl version):
OS (e.g. from /etc/os-release):

@bansal01yash this is unlikely triton issue, I see the output gives 200 response I am not clear what the problem is.


Bug 2066615: run openshift plugin to get downstream images

Description of the change:
Update hybrid bundle to use openshift plugin and switch to downstream images.
Motivation for the change:
Downstream plugins should use downstream images.
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

/label qe-approved

/label docs-approved


fix 1207 for kubernetes native client

@ryanjbaxter this is ready to be looked at. thank you.

Ready after review comments


Prey does not take Vulnerable into account

I used Vuln Potion and then Prey on a enemy. The first hit did not do extra 50% damage like it should. Only the second hit took Vulnerable into account.

Solved in 0.0.4. Added a calculateCardDamage step before applying single target damage. Note: multiDamage on card description now uses static magicNumber value, so that it doesn't show misleading values when hovering over a vulnerable enemy.


Longhorn manager try to describe non existing node label

Hi
I have deployed a HA K8s test-cluster on AWS for testing Longhorn, the underlying OS is CoreOS. The cluster has 3 etcd instances, two masters, 3 spotfleet worker nodes and two storage nodes (with a 500GB gp2 ebs volume each). My plan is to run longhorn on the storage nodes only, Any pods on nodes should be able to consume longhorn PVCs.
NAME                                        STATUS   ROLES          AGE    VERSION
ip-10-1-43-117.eu-west-1.compute.internal   Ready    master         2d1h   v1.13.5
ip-10-1-43-126.eu-west-1.compute.internal   Ready    node,spot      42h    v1.13.5
ip-10-1-43-24.eu-west-1.compute.internal    Ready    node,storage   105m   v1.13.5
ip-10-1-44-231.eu-west-1.compute.internal   Ready    master         2d1h   v1.13.5
ip-10-1-44-97.eu-west-1.compute.internal    Ready    node,spot      42h    v1.13.5
ip-10-1-45-198.eu-west-1.compute.internal   Ready    node,storage   105m   v1.13.5
ip-10-1-45-87.eu-west-1.compute.internal    Ready    node,spot      42h    v1.13.5

This is the state of pods after deploying longhorn. The driver installer waits for the init to finish (basically waiting for the backend service).
NAME                                        READY   STATUS     RESTARTS   AGE
engine-image-ei-9bea8a9c-564qj              1/1     Running    0          3h46m
engine-image-ei-9bea8a9c-f98wp              1/1     Running    0          3h46m
engine-image-ei-9bea8a9c-tlg59              1/1     Running    0          3h46m
longhorn-driver-deployer-6b4bfcbd99-92gv5   0/1     Init:0/1   0          3h46m
longhorn-manager-xb85z                      1/1     Running    35         3h46m
longhorn-manager-xdjl9                      1/1     Running    35         3h46m
longhorn-ui-6475bfbbd8-lxtjz                1/1     Running    0          3h46m

The managers DaemonSet pods are isolated to the storage nodes (using node selectors and affinity). So this seems to work.
    spec:
      nodeSelector:
        kube-aws.coreos.com/role: storage
      tolerations:
      - key: kube-aws.coreos.com/role
        operator: Equal
        value: storage
        effect: NoSchedule

But is it the manager pods or the engine pods that a re responsible for adding the ebs volumes and managing the storage pool? The system architecture and which pod is responsible for what is a little unclear to me, after reading the documentation.
The managers pods are constantly crashlooping, this is the output from the logs
...
time="2019-05-25T20:14:14Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-05-25T20:14:20Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-05-25T20:14:20Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:23Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:23Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:26Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-05-25T20:14:30Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:30Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=fatal msg="Error starting manager: failed to wait for engine image rancher/longhorn-engine:v0.5.0: Wait for engine image rancher/longhorn-engine:v0.5.0 timed out"

The manager is trying to parse a node label that deos not exists, describe node where the pod runs reveals that it does not have the node-role.kubernetes.io/worker, so it's pretty obvious why it fails. But why does the manager try to describe a node label that does not exist on the node?
Name:               ip-10-1-43-24.eu-west-1.compute.internal
Roles:              node,storage
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=m5a.large
                    beta.kubernetes.io/os=linux
                    cputype=normal
                    failure-domain.beta.kubernetes.io/region=eu-west-1
                    failure-domain.beta.kubernetes.io/zone=eu-west-1a
                    kube-aws.coreos.com/autoscalinggroup=k8s6-Storage-1PWKNJJPPE5BU-Workers-C7BU4PXGMV6R
                    kube-aws.coreos.com/cluster=k8s6
                    kube-aws.coreos.com/launchconfiguration=
                    kube-aws.coreos.com/role=storage
                    kubernetes.io/hostname=ip-10-1-43-24.eu-west-1.compute.internal
                    kubernetes.io/role=node
                    node-role.kubernetes.io/node=
                    node-role.kubernetes.io/storage=
                    node.kubernetes.io/role=storage
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"5a:be:3d:18:cc:89"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: <IP_ADDRESS>
                    kube-aws.coreos.com/securitygroups: k8s6-Network-1AJ9I9AGCOR35-SecurityGroupWorker-5M4RWB63CGHZ
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Sat, 25 May 2019 16:42:42 +0200

Any help would be appreciated. It's also a little unclear to me how to configure this part of the driver-deployer deployment to use CSI. What do I have to uncomment or change? Do i have to manually choose flexvolume or csi, or is manual selection just an option to override automatic selection?
          # manually choose "flexvolume" or "csi"
          #- --driver
          #- flexvolume
          # manually set root directory for flexvolume
          #- --flexvolume-dir
          #- /usr/libexec/kubernetes/kubelet-plugins/volume/exec/
          # manually set root directory for csi
          #- --kubelet-root-dir
          #- /var/lib/rancher/k3s/agent/kubelet
          # manually specify number of CSI attacher replicas
          #- --csi-attacher-replica-count
          #- "3"
          # manually specify number of CSI provisioner replicas
          #- --csi-provisioner-replica-count
          #- "3"
          env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: SERVICE_ACCOUNT
            valueFrom:
              fieldRef:
                fieldPath: spec.serviceAccountName
          # For auto detection, leave this parameter unset
          #- name: FLEXVOLUME_DIR
            # FOR RKE
            #value: "/var/lib/kubelet/volumeplugins"
            # FOR GKE
            #value: "/home/kubernetes/flexvolume/"

@paalkr
In fact the manager pods cannot be isolated to the storage node in this case. The manager is needed to provide the volume to the worker node as well (if you want volumes to be usable by the worker node other than the storage worker node). You can simply use the yaml file or chart to deploy longhorn and if you don't want the disk space on non-storage node to be used, you can disable the scheduling on those node in Longhorn.
The failing of starting longhorn manager is due to we're waiting for a engine image daemonset to be deployed on all the nodes. Engine image pods and manager pods should be deployed on every worker node. Engine image pods are used by manager on the same node. It's not recommended to change the deployment method.
One thing is interesting is the nodes here doesn't have node-role.kubernetes.io/worker. We need to check how it happened. (CC @shreesha21 )
You shouldn't worry about CSI or Flexvolume options now. As we said in the document, Longhorn will detect the environment and config itself when installing. Those options are there just in case something went wrong, and we would need a way to manually override the automatic detection mechanism before we deliver the fix in the next release.

One important question is, what's your Kubernetes distribution? EKS? The node labels should be related to the distribution so we can investigate.

@yasker ,
Thanks for the feedback. The distribution is not EKS, the cluster is deployed using kube-aws, https://github.com/kubernetes-incubator/kube-aws. We have been using kube-aws in production for several years.
I probably did a mistake to isolate the manger to the storage nodes. but as I said it's still unclear to me what role the different compensates in longhorn play ;)
How do I configure Longhorn so only volumes from the storage nodes will be used to power the storage pool?

I removed the NodeSelector from the manager DaemonSet, so the manager now runs on all nodes. But still the describe node label fails, probably as expected, and the manager pods are crashlooping with the same error as I described previously.
Probably that's also why I get
curl: (7) Failed to connect to longhorn-backend port 9500: Connection refused
when exec into the init container and executing
curl http://longhorn-backend:9500/v1
The init container obviously are stuck in the waiting state.

One more thing, what value do you expect the node-role.kubernetes.io/worker label to have, just true or empty, or something different? I can easily add that label to all my worked nodes, if it's a requirement for Longhorn. As you can see kube-aws adds formats the label in question like
node-role.kubernetes.io/<worker_pool_name>
This is my current set of label for master, normal workers and storage "workers"
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=t3.medium
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=eu-west-1
                    failure-domain.beta.kubernetes.io/zone=eu-west-1a
                    kube-aws.coreos.com/cluster=k8s6
                    kube-aws.coreos.com/role=controller
                    kubernetes.io/hostname=ip-10-1-43-117.eu-west-1.compute.internal
                    kubernetes.io/role=master
                    node-role.kubernetes.io/master=
                    node.kubernetes.io/role=master

Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=r4.xlarge
                    beta.kubernetes.io/os=linux
                    cputype=spot
                    failure-domain.beta.kubernetes.io/region=eu-west-1
                    failure-domain.beta.kubernetes.io/zone=eu-west-1a
                    kube-aws.coreos.com/autoscalinggroup=k8s6-Spot-FOZD5MPY626V-Workers-13UH03LVMZBAF
                    kube-aws.coreos.com/cluster=k8s6
                    kube-aws.coreos.com/launchconfiguration=
                    kube-aws.coreos.com/role=worker
                    kubernetes.io/hostname=ip-10-1-43-126.eu-west-1.compute.internal
                    kubernetes.io/role=node
                    node-role.kubernetes.io/node=
                    node-role.kubernetes.io/spot=
                    node.kubernetes.io/role=spot

Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=m5a.large
                    beta.kubernetes.io/os=linux
                    cputype=normal
                    failure-domain.beta.kubernetes.io/region=eu-west-1
                    failure-domain.beta.kubernetes.io/zone=eu-west-1a
                    kube-aws.coreos.com/autoscalinggroup=k8s6-Storage-1PWKNJJPPE5BU-Workers-C7BU4PXGMV6R
                    kube-aws.coreos.com/cluster=k8s6
                    kube-aws.coreos.com/launchconfiguration=
                    kube-aws.coreos.com/role=storage
                    kubernetes.io/hostname=ip-10-1-43-24.eu-west-1.compute.internal
                    kubernetes.io/role=node
                    node-role.kubernetes.io/node=
                    node-role.kubernetes.io/storage=
                    node.kubernetes.io/role=storage

Btw, I think looking for the kubernetes.io/role=node would be closer to the Kubernetes intention, the node-role.kubernetes.io/ is meant to describe what type the node is.
https://github.com/kubernetes/kubernetes/pull/35975/files#diff-c8063ac1e636c387ca8169633ddee1bdR54

@paalkr We need to take a closer look at the role issue (I just found out GKE set no role for the nodes), but it shouldn't stop the manager from starting.
How many managers pods and engine image pods you've seen? There should be 5 pods for each (as the same number as your worker nodes) since both are just a daemon set.  Managers need to wait for engine image pods to complete deployment before continuing. And other pods (driver-deployer etc) are waiting for the manager before continuing.
And yes, you can disable the scheduling from UI for the non-storage pods after it's installed.

This is what I observe in the longhorn-system namespace
NAME                                        READY   STATUS             RESTARTS   AGE    IP             NODE                                        NOMINATED NODE   READINESS GATES
engine-image-ei-9bea8a9c-65tfj              1/1     Running            0          8h     <IP_ADDRESS>    ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
engine-image-ei-9bea8a9c-6pc5l              1/1     Running            0          8h     <IP_ADDRESS>    ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
engine-image-ei-9bea8a9c-tlg59              1/1     Running            0          22h    <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
longhorn-driver-deployer-6b4bfcbd99-lmbkl   0/1     Init:0/1           0          8h     <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-j4m8f                      0/1     CrashLoopBackOff   21         130m   <IP_ADDRESS>    ip-10-1-43-24.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-ksj6f                      0/1     CrashLoopBackOff   21         130m   <IP_ADDRESS>    ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-mrcwb                      0/1     CrashLoopBackOff   21         130m   <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-qwdw7                      0/1     CrashLoopBackOff   21         130m   <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
longhorn-manager-rd68p                      0/1     CrashLoopBackOff   21         130m   <IP_ADDRESS>    ip-10-1-45-198.eu-west-1.compute.internal   <none>           <none>
longhorn-ui-6475bfbbd8-bpqs8                1/1     Running            0          8h     <IP_ADDRESS>    ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>

Nodes
NAME                                        STATUS   ROLES          AGE     VERSION
ip-10-1-43-117.eu-west-1.compute.internal   Ready    master         3d      v1.13.5
ip-10-1-43-126.eu-west-1.compute.internal   Ready    node,spot      2d17h   v1.13.5
ip-10-1-43-24.eu-west-1.compute.internal    Ready    node,storage   24h     v1.13.5
ip-10-1-44-231.eu-west-1.compute.internal   Ready    master         3d      v1.13.5
ip-10-1-44-32.eu-west-1.compute.internal    Ready    node,spot      8h      v1.13.5
ip-10-1-45-198.eu-west-1.compute.internal   Ready    node,storage   24h     v1.13.5
ip-10-1-45-62.eu-west-1.compute.internal    Ready    node,spot      8h      v1.13.5

PS, I have still taints on the storage nodes, so that no normal workloads should be able to run there.
Name:               ip-10-1-43-24.eu-west-1.compute.internal
Roles:              node,storage
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=m5a.large
                    beta.kubernetes.io/os=linux
                    cputype=normal
                    failure-domain.beta.kubernetes.io/region=eu-west-1
                    failure-domain.beta.kubernetes.io/zone=eu-west-1a
                    kube-aws.coreos.com/autoscalinggroup=k8s6-Storage-1PWKNJJPPE5BU-Workers-C7BU4PXGMV6R
                    kube-aws.coreos.com/cluster=k8s6
                    kube-aws.coreos.com/launchconfiguration=
                    kube-aws.coreos.com/role=storage
                    kubernetes.io/hostname=ip-10-1-43-24.eu-west-1.compute.internal
                    kubernetes.io/role=node
                    node-role.kubernetes.io/node=
                    node-role.kubernetes.io/storage=
                    node.kubernetes.io/role=storage
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"5a:be:3d:18:cc:89"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: <IP_ADDRESS>
                    kube-aws.coreos.com/securitygroups: k8s6-Network-1AJ9I9AGCOR35-SecurityGroupWorker-5M4RWB63CGHZ
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Sat, 25 May 2019 16:42:42 +0200
Taints:             kube-aws.coreos.com/role=storage:NoSchedule
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Sun, 26 May 2019 17:14:49 +0200   Sat, 25 May 2019 16:42:42 +0200   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Sun, 26 May 2019 17:14:49 +0200   Sat, 25 May 2019 16:42:42 +0200   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Sun, 26 May 2019 17:14:49 +0200   Sat, 25 May 2019 16:42:42 +0200   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Sun, 26 May 2019 17:14:49 +0200   Sat, 25 May 2019 16:43:22 +0200   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:   <IP_ADDRESS>
  InternalDNS:  ip-10-1-43-24.eu-west-1.compute.internal
  Hostname:     ip-10-1-43-24.eu-west-1.compute.internal
Capacity:
 attachable-volumes-aws-ebs:  25
 cpu:                         2
 ephemeral-storage:           73773584Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7910252Ki
 pods:                        110
Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         2
 ephemeral-storage:           73773584Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7705452Ki
 pods:                        110
System Info:
 Machine ID:                 ec2d03d75f37c30231c68c58b9f796fb
 System UUID:                ec2d03d7-5f37-c302-31c6-8c58b9f796fb
 Boot ID:                    a8b9157f-292c-4c90-a34d-335bb0073c0b
 Kernel Version:             4.19.43-coreos
 OS Image:                   Container Linux by CoreOS 2079.4.0 (Rhyolite)
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://18.6.3
 Kubelet Version:            v1.13.5
 Kube-Proxy Version:         v1.13.5
PodCIDR:                     <IP_ADDRESS>/24
ProviderID:                  aws:///eu-west-1a/i-0ab552010a4043c83
Non-terminated Pods:         (6 in total)
  Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                         ------------  ----------  ---------------  -------------  ---
  kube-system                flannel-5xw28                                100m (5%)     100m (5%)   50Mi (0%)        50Mi (0%)      24h
  kube-system                kiam-agent-29mv2                             250m (12%)    500m (25%)  100Mi (1%)       800Mi (10%)    24h
  kube-system                kube-node-drainer-ds-h69lx                   0 (0%)        0 (0%)      0 (0%)           0 (0%)         24h
  kube-system                kube-proxy-tm96l                             0 (0%)        0 (0%)      0 (0%)           0 (0%)         24h
  longhorn-system            longhorn-manager-j4m8f                       0 (0%)        0 (0%)      0 (0%)           0 (0%)         134m
  monitoring                 monitoring-prometheus-node-exporter-dfnt4    0 (0%)        0 (0%)      0 (0%)           0 (0%)         24h

After manually editing the engine-image DaemonSet to include the toleration for my storage node taints, the longhorn system seems to start up.
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  creationTimestamp: "2019-05-25T16:27:55Z"
  generation: 2
  labels:
    longhorn: engine-image
  name: engine-image-ei-9bea8a9c
  namespace: longhorn-system
  resourceVersion: "984146"
  selfLink: /apis/extensions/v1beta1/namespaces/longhorn-system/daemonsets/engine-image-ei-9bea8a9c
  uid: 0ceea091-7f0a-11e9-965b-028e8725643a
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      longhorn: engine-image
  template:
    metadata:
      creationTimestamp: null
      labels:
        longhorn: engine-image
      name: engine-image-ei-9bea8a9c
    spec:
      containers:
      - args:
        - -c
        - cp /usr/local/bin/longhorn* /data/ && echo installed && trap 'rm /data/longhorn*
          && echo cleaned up' EXIT && sleep infinity
        command:
        - /bin/bash
        image: rancher/longhorn-engine:v0.5.0
        imagePullPolicy: Always
        name: engine-image-ei-9bea8a9c
        readinessProbe:
          exec:
            command:
            - ls
            - /data/longhorn
          failureThreshold: 3
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /data/
          name: data
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoSchedule
        key: kube-aws.coreos.com/role
        operator: Equal
        value: storage
      volumes:
      - hostPath:
          path: /var/lib/rancher/longhorn/engine-binaries/rancher-longhorn-engine-v0.5.0
          type: ""
        name: data
  templateGeneration: 2
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate

NAME                                        READY   STATUS    RESTARTS   AGE     IP             NODE                                        NOMINATED NODE   READINESS GATES
csi-attacher-799cdf866b-cmtv4               1/1     Running   0          46s     <IP_ADDRESS>   ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
csi-attacher-799cdf866b-fq2jr               1/1     Running   0          46s     <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
csi-attacher-799cdf866b-j5slx               1/1     Running   0          46s     <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
csi-provisioner-7f4bccb59-5gd95             1/1     Running   0          45s     <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
csi-provisioner-7f4bccb59-hf7rk             1/1     Running   0          45s     <IP_ADDRESS>   ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
csi-provisioner-7f4bccb59-qccnr             1/1     Running   0          45s     <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
engine-image-ei-9bea8a9c-m99dj              1/1     Running   0          3m48s   <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
engine-image-ei-9bea8a9c-pjj7s              1/1     Running   0          4m30s   <IP_ADDRESS>   ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
engine-image-ei-9bea8a9c-qkbqz              1/1     Running   0          5m29s   <IP_ADDRESS>    ip-10-1-43-24.eu-west-1.compute.internal    <none>           <none>
engine-image-ei-9bea8a9c-qq55c              1/1     Running   0          2m59s   <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
engine-image-ei-9bea8a9c-wkvcl              1/1     Running   0          5m29s   <IP_ADDRESS>    ip-10-1-45-198.eu-west-1.compute.internal   <none>           <none>
longhorn-csi-plugin-cgjgf                   2/2     Running   0          45s     <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
longhorn-csi-plugin-j7nxs                   2/2     Running   0          45s     <IP_ADDRESS>   ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
longhorn-csi-plugin-kcqtw                   2/2     Running   0          45s     <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
longhorn-driver-deployer-6b4bfcbd99-lmbkl   1/1     Running   0          8h      <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-j4m8f                      1/1     Running   24         147m    <IP_ADDRESS>    ip-10-1-43-24.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-ksj6f                      1/1     Running   24         148m    <IP_ADDRESS>    ip-10-1-45-62.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-mrcwb                      1/1     Running   24         148m    <IP_ADDRESS>   ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>
longhorn-manager-qwdw7                      1/1     Running   24         148m    <IP_ADDRESS>   ip-10-1-43-126.eu-west-1.compute.internal   <none>           <none>
longhorn-manager-rd68p                      1/1     Running   24         147m    <IP_ADDRESS>    ip-10-1-45-198.eu-west-1.compute.internal   <none>           <none>
longhorn-ui-6475bfbbd8-bpqs8                1/1     Running   0          8h      <IP_ADDRESS>    ip-10-1-44-32.eu-west-1.compute.internal    <none>           <none>

Thanks for the help so far!
After some manual intervention I did get Longhorn up running, see attached screen shot from the manager :)

But there are some areas that I think should be handled a little different, to get at fault tolerant self healing storage system in place.

Taints should be possible to specify, ref my previous comment
It should be possible to specify that nodes with/without a certain label should automatically be marked as disabled by longhorn
The mount path on the nodes should be possible to specify, but that might already be possible if I have a closer look at the manifest of the longhorn-manager DaemonSet

I'm looking forward to start playing with Longhorn. Previously I have been using Rook/Ceph and we are currently using NetApp/trident for K8s persistent volumes.

@paalkr You're welcome!
First two items in your list, we definitely can do. I can see the use case now. Feel free to file separate issues for them (which makes it easier for us to track them)
Though, what's the mount path you're talking about?

@yasker , thanks!
Great that you are happy about my suggested improvements to Longhorn.
What I mean by bulletpoint 3 is that I would like to specify what mount path on the host that should be automatically included in Longhorn. In my case during node startup attached EBS volumes are striped together and mounted at /ebs/, which is where I would like Longhorn to store data. Currently Longhorn adds /var/lib/rancher/longhorn/ to the storage pool by default, which would be on the node root volume. Using the root volume for storage is not ideal.

@paalkr Yeah, that makes sense. I will file separate issues for those improvements.

I have created separate tickets for the various issues I have reported during testing. So I guess this current issue then can be focused on the fact that the Longhorn manager tries to describe a non existing node label. This error does not prevent Longhorn from starting though, but it fills up the logs with clutter.
...
time="2019-05-25T20:14:14Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-05-25T20:14:20Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-05-25T20:14:20Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:23Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:23Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:26Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-05-25T20:14:30Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:30Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-45-198.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=error msg="Error while parsing the value of the label node-role.kubernetes.io/worker in node ip-10-1-43-24.eu-west-1.compute.internal:strconv.ParseBool: parsing \"\": invalid syntax"
time="2019-05-25T20:14:32Z" level=fatal msg="Error starting manager: failed to wait for engine image rancher/longhorn-engine:v0.5.0: Wait for engine image rancher/longhorn-engine:v0.5.0 timed out"

@paalkr Thanks for filing the issues. Yeah, we're going to fix this error message in the next release.

The issue with the error message was fixed by reverting the change in https://github.com/longhorn/longhorn-manager/pull/366/commits/b9633528a37a885ed6eb3c66086deca553a1b618


[T4A4][F09-B2] Xu Chen

Ready for review

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.


Support for expansion files

Also fixed all error situations where a lot of "varname of undefined" errors were thrown.
Support for OBB files also added to the CLI, and documented in the Readme.
Output:
$ DEBUG=google-play-publisher ~/Projects/google-play-publisher/cli.js -t alpha -a ./android.json Build/Android/Unity-Android.apk Build/Android/Unity-Android.main.obb
  google-play-publisher Detected package name REDACTED +0ms
  google-play-publisher Detected version code 5 +3ms
  google-play-publisher > Authenticating +4ms
  google-play-publisher > Authenticated succesfully +710ms
  google-play-publisher > Creating edit +0ms
  google-play-publisher > Created edit with id<PHONE_NUMBER>854013500 +899ms
  google-play-publisher > Uploading release +1ms
  google-play-publisher > Uploaded Build/Android/Unity-Android.apk with version code 5 and SHA1 09fda6834edeac19be8b2d3aeae1b13283692cca +7s
  google-play-publisher > Uploading 1 expansion file(s) +1ms
  google-play-publisher > Uploaded Build/Android/Unity-Android.main.obb +7s
  google-play-publisher > Assigning APK to alpha track +0ms
  google-play-publisher > Assigned APK to alpha track +876ms
  google-play-publisher > Commiting changes +1ms
  google-play-publisher > Commited changes +6s
  google-play-publisher > Finished uploading APK +0ms

Closes #7
Fixes #8

Thank you!

No problem! :)


State of OSL

hello,
I've been looking over OSL and it looks very promising, however I've run into a few issues.  I built OSL on Centos 7 off of branch RB-1.8 and about half of the tests fail, and only about half of the "testsuite/render-" tests produce a non black image using testrender.  To compile, I needed to remove a line for adding the  MCJIT llvm library in case that affected anything.  I'm using llvm 3.4.2.
Is this indicative of the state of OSL (or at least the testrender/testshader apps) or specific to my build/dependencies?
Would blender be a better starting point for assessing the stability and functionality of OSL?
Is there a place that maintains a set of supported shaders comparable to something like the vMaterial Library, or would the best place for prebuilt shaders be an external package like blender if they can export to OSL?

In what way do the tests fail, exactly? Crash? Incorrect result?
Which part of RB-1.8? The current head? A release tag?
 Or do you have the option to use a modern LLVM (beyond 3.4 does require C++11)?

adding partial output below.  I'm assuming incorrect output, but haven't delved deeper.
I checked out RB-1.8 branch, latest commit was:
I'm using llvm 3.4 simply because that's what Centos' package manager has and it was listed as supported.
Test project /home/carson/git/OpenShadingLanguage/build/linux64
Start   1: and-or-not-synonyms
1/306 Test   #1: and-or-not-synonyms ................   Passed    0.20 sec
Start   2: and-or-not-synonyms.opt
2/306 Test   #2: and-or-not-synonyms.opt ............   Passed    0.19 sec
Start   3: aastep
3/306 Test   #3: aastep .............................***Failed    0.17 sec
sh: bin/idiff: No such file or directory
sh: bin/idiff: No such file or directory
test source dir = ../../../../testsuite/aastep
command = ../../src/oslc/oslc test.osl >> out.txt 2>&1 ;
../../src/testshade/testshade -g 64 64 -od uint8 -o Cout out.tif test >> out.txt 2>&1 ;
PASS: out.txt matches ref/out.txt
NO MATCH for out.tif
FAIL out.tif
    Start   4: aastep.opt

4/306 Test   #4: aastep.opt .........................***Failed    0.22 sec
sh: bin/idiff: No such file or directory
sh: bin/idiff: No such file or directory
test source dir = ../../../../testsuite/aastep
command = ../../src/oslc/oslc test.osl >> out.txt 2>&1 ;
../../src/testshade/testshade -g 64 64 -od uint8 -o Cout out.tif test >> out.txt 2>&1 ;
PASS: out.txt matches ref/out.txt
NO MATCH for out.tif
FAIL out.tif
    Start   5: arithmetic

5/306 Test   #5: arithmetic .........................   Passed    0.19 sec
Start   6: arithmetic.opt
6/306 Test   #6: arithmetic.opt .....................   Passed    0.21 sec
Start   7: array
7/306 Test   #7: array ..............................   Passed    0.22 sec
Start   8: array.opt
8/306 Test   #8: array.opt ..........................   Passed    0.20 sec
Start   9: array-derivs
9/306 Test   #9: array-derivs .......................   Passed    0.20 sec
Start  10: array-derivs.opt
10/306 Test  #10: array-derivs.opt ...................   Passed    0.17 sec
Start  11: array-range
11/306 Test  #11: array-range ........................   Passed    0.13 sec
Start  12: array-range.opt
12/306 Test  #12: array-range.opt ....................   Passed    0.16 sec
Start  13: blackbody
13/306 Test  #13: blackbody ..........................***Failed    0.22 sec
sh: bin/idiff: No such file or directory
sh: bin/idiff: No such file or directory
test source dir = ../../../../testsuite/blackbody
command = ../../src/oslc/oslc test.osl >> out.txt 2>&1 ;
../../src/testshade/testshade -g 1000 64 -od half -o Cout out.exr test >> out.txt 2>&1 ;
PASS: out.txt matches ref/out.txt
NO MATCH for out.exr
FAIL out.exr
    Start  14: blackbody.opt

14/306 Test  #14: blackbody.opt ......................***Failed    0.21 sec
sh: bin/idiff: No such file or directory
sh: bin/idiff: No such file or directory
test source dir = ../../../../testsuite/blackbody
command = ../../src/oslc/oslc test.osl >> out.txt 2>&1 ;
../../src/testshade/testshade -g 1000 64 -od half -o Cout out.exr test >> out.txt 2>&1 ;
PASS: out.txt matches ref/out.txt
NO MATCH for out.exr
FAIL out.exr
...
300/306 Test #300: wavelength_color ...................***Failed    0.24 sec
sh: bin/idiff: No such file or directory
sh: bin/idiff: No such file or directory
test source dir = ../../../../testsuite/wavelength_color
command = ../../src/oslc/oslc test.osl >> out.txt 2>&1 ;
../../src/testshade/testshade -g 1000 64 -od float -o Cout out.exr test >> out.txt 2>&1 ;
PASS: out.txt matches ref/out.txt
NO MATCH for out.exr
FAIL out.exr
    Start 301: wavelength_color.opt

301/306 Test #301: wavelength_color.opt ...............***Failed    0.24 sec
sh: bin/idiff: No such file or directory
sh: bin/idiff: No such file or directory
test source dir = ../../../../testsuite/wavelength_color
command = ../../src/oslc/oslc test.osl >> out.txt 2>&1 ;
../../src/testshade/testshade -g 1000 64 -od float -o Cout out.exr test >> out.txt 2>&1 ;
PASS: out.txt matches ref/out.txt
NO MATCH for out.exr
FAIL out.exr
    Start 302: xml

302/306 Test #302: xml ................................   Passed    0.20 sec
Start 303: xml.opt
303/306 Test #303: xml.opt ............................   Passed    0.19 sec
Start 304: unit_accum
304/306 Test #304: unit_accum .........................   Passed    0.05 sec
Start 305: unit_llvmutil
305/306 Test #305: unit_llvmutil ......................   Passed    0.03 sec
Start 306: unit_oslnoise
306/306 Test #306: unit_oslnoise ......................   Passed    5.52 sec
67% tests passed, 102 tests failed out of 306
Total Test time (real) =  78.61 sec
The following tests FAILED:
3 - aastep (Failed)
4 - aastep.opt (Failed)
13 - blackbody (Failed)
14 - blackbody.opt (Failed)
19 - bug-array-heapoffsets (Failed)
20 - bug-array-heapoffsets.opt (Failed)
23 - bug-outputinit (Failed)
24 - bug-outputinit.opt (Failed)
29 - cellnoise (Failed)
30 - cellnoise.opt (Failed)
39 - compile-buffer (Failed)
40 - compile-buffer.opt (Failed)
55 - draw_string (Failed)
56 - draw_string.opt (Failed)
74 - getsymbol-nonheap (Failed)
75 - getsymbol-nonheap.opt (Failed)
76 - gettextureinfo (Failed)
77 - gettextureinfo.opt (Failed)
78 - group-outputs (Failed)
79 - group-outputs.opt (Failed)
108 - layers-repeatedoutputs (Failed)
109 - layers-repeatedoutputs.opt (Failed)
110 - linearstep (Failed)
111 - linearstep.opt (Failed)
130 - noise (Failed)
131 - noise.opt (Failed)
132 - noise-cell (Failed)
133 - noise-cell.opt (Failed)
134 - noise-gabor (Failed)
135 - noise-gabor.opt (Failed)
136 - noise-gabor2d-filter (Failed)
137 - noise-gabor2d-filter.opt (Failed)
138 - noise-gabor3d-filter (Failed)
139 - noise-gabor3d-filter.opt (Failed)
140 - noise-perlin (Failed)
141 - noise-perlin.opt (Failed)
142 - noise-uperlin (Failed)
143 - noise-uperlin.opt (Failed)
144 - noise-simplex (Failed)
145 - noise-simplex.opt (Failed)
146 - noise-usimplex (Failed)
147 - noise-usimplex.opt (Failed)
148 - pnoise (Failed)
149 - pnoise.opt (Failed)
150 - pnoise-cell (Failed)
151 - pnoise-cell.opt (Failed)
152 - pnoise-gabor (Failed)
153 - pnoise-gabor.opt (Failed)
154 - pnoise-perlin (Failed)
155 - pnoise-perlin.opt (Failed)
156 - pnoise-uperlin (Failed)
157 - pnoise-uperlin.opt (Failed)
190 - osl-imageio (Failed)
191 - osl-imageio.opt (Failed)
198 - reparam (Failed)
199 - reparam.opt (Failed)
200 - render-background.opt (Failed)
201 - render-bumptest.opt (Failed)
202 - render-cornell.opt (Failed)
203 - render-furnace-diffuse.opt (Failed)
204 - render-microfacet.opt (Failed)
205 - render-oren-nayar.opt (Failed)
206 - render-veachmis.opt (Failed)
207 - render-ward.opt (Failed)
212 - spline (Failed)
213 - spline.opt (Failed)
216 - spline-derivbug (Failed)
217 - spline-derivbug.opt (Failed)
244 - testshade-expr (Failed)
245 - testshade-expr.opt (Failed)
246 - texture-alpha (Failed)
247 - texture-alpha.opt (Failed)
248 - texture-blur (Failed)
249 - texture-blur.opt (Failed)
250 - texture-connected-options (Failed)
251 - texture-connected-options.opt (Failed)
252 - texture-derivs (Failed)
253 - texture-derivs.opt (Failed)
254 - texture-errormsg (Failed)
255 - texture-errormsg.opt (Failed)
256 - texture-firstchannel (Failed)
257 - texture-firstchannel.opt (Failed)
258 - texture-interp (Failed)
259 - texture-interp.opt (Failed)
260 - texture-missingcolor (Failed)
261 - texture-missingcolor.opt (Failed)
262 - texture-simple (Failed)
263 - texture-simple.opt (Failed)
264 - texture-smallderivs (Failed)
265 - texture-smallderivs.opt (Failed)
266 - texture-swirl (Failed)
267 - texture-swirl.opt (Failed)
268 - texture-udim (Failed)
269 - texture-udim.opt (Failed)
270 - texture-width (Failed)
271 - texture-width.opt (Failed)
272 - texture-withderivs (Failed)
273 - texture-withderivs.opt (Failed)
274 - texture-wrap (Failed)
275 - texture-wrap.opt (Failed)
300 - wavelength_color (Failed)
301 - wavelength_color.opt (Failed)
Errors while running CTest
make: *** [test] Error 8
`

sh: bin/idiff: No such file or directory

It's trying to use the OpenImageIO idiff utility to compare test images to reference images, and not finding it. The way the error message is worded, it looks like you have an $OPENIMAGEIOHOME env variable present, but it is empty, so you're getting "bin/idiff". If the variable doesn't exist at all, it will just look for "idiff" and hope it's in your path.
If idiff is not in your $PATH, then please set environment variable $OPENIMAGEIOHOME to the prefix where your OIIO installation is.

odd, env | grep OPENIMAGE returns nothing, and setting it to /user/local appeared to have no affect.  Perhaps python is grabbing another set of env vars?  At any rate, I modified the code to not append bin to the path and it got rid of that error.  A few tests still fail, listed below.  Any idea why some of the render- tests are showing up black?
`
test source dir = ../../../../testsuite/compile-buffer
command = ../../src/testshade/testshade --inbuffer test >> out.txt 2>&1 ;
Error: this command failed:  ../../src/testshade/testshade --inbuffer test >> out.txt 2>&1
FAIL
    Start  40: compile-buffer.opt

40/306 Test  #40: compile-buffer.opt .................***Failed    0.11 sec
test source dir = ../../../../testsuite/compile-buffer
command = ../../src/testshade/testshade --inbuffer test >> out.txt 2>&1 ;
Error: this command failed:  ../../src/testshade/testshade --inbuffer test >> out.txt 2>&1
FAIL
    Start  41: component-range

...
190/306 Test #190: osl-imageio ........................**Failed    0.17 sec
test source dir = ../../../../testsuite/osl-imageio
command = ../../src/oslc/oslc ramp.osl >> out.txt 2>&1 ;
oiiotool "ramp.oso?RES=64" -d uint8 -o ramp-oso-default.tif >> out.txt 2>&1 ;
oiiotool "ramp.oso?RES=64&color topright=0,0,1" -d uint8 -o ramp-oso-blue.tif >> out.txt 2>&1 ;
oiiotool "ramp.oso?RES=64&color bottomright=0,1,1&TILE=32x32" -d uint8 -o ramp-oso-tiles.tif >> out.txt 2>&1 ;
oiiotool "result=sin(40s)/2+0.5.oslbody?RES=256x256&MIP=1" -selectmip 2 -d uint8 -o wave-mip.tif >> out.txt 2>&1 ;
Error: this command failed:
oiiotool "ramp.oso?RES=64" -d uint8 -o ramp-oso-default.tif >> out.txt 2>&1
FAIL
    Start 191: osl-imageio.opt

191/306 Test #191: osl-imageio.opt ....................**Failed    0.19 sec
test source dir = ../../../../testsuite/osl-imageio
command = ../../src/oslc/oslc ramp.osl >> out.txt 2>&1 ;
oiiotool "ramp.oso?RES=64" -d uint8 -o ramp-oso-default.tif >> out.txt 2>&1 ;
oiiotool "ramp.oso?RES=64&color topright=0,0,1" -d uint8 -o ramp-oso-blue.tif >> out.txt 2>&1 ;
oiiotool "ramp.oso?RES=64&color bottomright=0,1,1&TILE=32x32" -d uint8 -o ramp-oso-tiles.tif >> out.txt 2>&1 ;
oiiotool "result=sin(40s)/2+0.5.oslbody?RES=256x256&MIP=1" -selectmip 2 -d uint8 -o wave-mip.tif >> out.txt 2>&1 ;
Error: this command failed:
oiiotool "ramp.oso?RES=64" -d uint8 -o ramp-oso-default.tif >> out.txt 2>&1
FAIL
...
202/306 Test #202: render-cornell.opt .................***Failed    0.69 sec
Comparing "out.exr" and "ref/out.exr"
256 x 256, 3 channel
Mean error = 0.0463048
RMS error = 0.0609431
Peak SNR = 50.6157
Max error  = 0.306152 @ (215, 87, B)
61346 pixels (93.6%) over 0.01
64746 pixels (98.8%) over 0.005
FAILURE
Comparing "out.exr" and "ref/out.exr"
256 x 256, 3 channel
Mean error = 0.0463048
RMS error = 0.0609431
Peak SNR = 50.6157
Max error  = 0.306152 @ (215, 87, B)
61346 pixels (93.6%) over 0.01
64746 pixels (98.8%) over 0.005
FAILURE
test source dir = ../../../../testsuite/render-cornell
command = ../../src/oslc/oslc emitter.osl >> out.txt 2>&1 ;
../../src/oslc/oslc matte.osl >> out.txt 2>&1 ;
../../src/oslc/oslc metal.osl >> out.txt 2>&1 ;
../../src/testrender/testrender  -v --stats -r 256 256 -aa 4 cornell.xml out.exr >> out.txt 2>&1 ;
NO MATCH for out.exr
FAIL out.exr
    Start 203: render-furnace-diffuse.opt

...
205/306 Test #205: render-oren-nayar.opt ..............***Failed    0.54 sec
Comparing "out.exr" and "ref/out.exr"
320 x 240, 3 channel
Mean error = 0.0757942
RMS error = 0.110048
Peak SNR = 19.1683
Max error  = 0.59668 @ (10, 123, R)
42732 pixels (55.6%) over 0.06
53154 pixels (69.2%) over 0.03
FAILURE
Comparing "out.exr" and "ref/out.exr"
320 x 240, 3 channel
Mean error = 0.0757942
RMS error = 0.110048
Peak SNR = 19.1683
Max error  = 0.59668 @ (10, 123, R)
42732 pixels (55.6%) over 0.06
53154 pixels (69.2%) over 0.03
FAILURE
test source dir = ../../../../testsuite/render-oren-nayar
command = ../../src/oslc/oslc checkerboard.osl >> out.txt 2>&1 ;
../../src/oslc/oslc emitter.osl >> out.txt 2>&1 ;
../../src/oslc/oslc matte.osl >> out.txt 2>&1 ;
../../src/oslc/oslc rough_matte.osl >> out.txt 2>&1 ;
../../src/testrender/testrender  -v --stats -r 320 240 -aa 4 scene.xml out.exr >> out.txt 2>&1 ;
NO MATCH for out.exr
FAIL out.exr
    Start 206: render-veachmis.opt

206/306 Test #206: render-veachmis.opt ................***Failed    0.70 sec
Comparing "out.exr" and "ref/out.exr"
320 x 240, 3 channel
Mean error = 0.0183451
RMS error = 0.202123
Peak SNR = 47.7633
Max error  = 39.2734 @ (69, 69, B)
34302 pixels (44.7%) over 0.008
44774 pixels (58.3%) over 0.004
FAILURE
Comparing "out.exr" and "ref/out.exr"
320 x 240, 3 channel
Mean error = 0.0183451
RMS error = 0.202123
Peak SNR = 47.7633
Max error  = 39.2734 @ (69, 69, B)
34302 pixels (44.7%) over 0.008
44774 pixels (58.3%) over 0.004
FAILURE
test source dir = ../../../../testsuite/render-veachmis
command = ../../src/oslc/oslc checkerboard.osl >> out.txt 2>&1 ;
../../src/oslc/oslc emitter.osl >> out.txt 2>&1 ;
../../src/oslc/oslc matte.osl >> out.txt 2>&1 ;
../../src/oslc/oslc phong.osl >> out.txt 2>&1 ;
../../src/testrender/testrender  -v --stats -r 320 240 -aa 4 veach.xml out.exr >> out.txt 2>&1 ;
NO MATCH for out.exr
FAIL out.exr
    Start 207: render-ward.opt

...
244/306 Test #244: testshade-expr .....................***Failed    0.19 sec
Comparing "out.tif" and "ref/out.tif"
PASS
test source dir = ../../../../testsuite/testshade-expr
command = ../../src/testshade/testshade -v -g 64 64 -od uint8 -o result out.tif -expr 'result=color(u,v,0)' >> out.txt 2>&1 ;
NO MATCH for out.txt
FAIL out.txt
-----out.txt----->
ERROR: :0: warning: Unable to find "stdosl.h"
Expression-based shader text is:
shader expr_0 (
float s = u [[ int lockgeom=0 ]],
float t = v [[ int lockgeom=0 ]],
output color result = 0,
output float alpha = 1,
)
{
result=color(u,v,0)
;
}
Shader group:
shader expr_0  ;

Shader group "" layers are:
Output result to out.tif
<----------
Diff was:
--- out.txt	Thu Apr  6 17:18:01 2017
+++ ref/out.txt	Wed Apr  5 13:27:15 2017
@@ -1,4 +1,3 @@
-ERROR: :0: warning: Unable to find "stdosl.h"
Expression-based shader text is:
shader expr_0 (
PASS: out.tif matches ref/out.tif
    Start 245: testshade-expr.opt

245/306 Test #245: testshade-expr.opt .................***Failed    0.14 sec
Comparing "out.tif" and "ref/out.tif"
PASS
test source dir = ../../../../testsuite/testshade-expr
command = ../../src/testshade/testshade -v -g 64 64 -od uint8 -o result out.tif -expr 'result=color(u,v,0)' >> out.txt 2>&1 ;
NO MATCH for out.txt
FAIL out.txt
-----out.txt----->
ERROR: :0: warning: Unable to find "stdosl.h"
Expression-based shader text is:
shader expr_0 (
float s = u [[ int lockgeom=0 ]],
float t = v [[ int lockgeom=0 ]],
output color result = 0,
output float alpha = 1,
)
{
result=color(u,v,0)
;
}
Shader group:
shader expr_0  ;

Shader group "" layers are:
Output result to out.tif
<----------
Diff was:
--- out.txt	Thu Apr  6 17:18:01 2017
+++ ref/out.txt	Wed Apr  5 13:27:15 2017
@@ -1,4 +1,3 @@
-ERROR: :0: warning: Unable to find "stdosl.h"
Expression-based shader text is:
shader expr_0 (
PASS: out.tif matches ref/out.tif
    Start 246: texture-alpha

...
97% tests passed, 10 tests failed out of 306
Total Test time (real) =  91.63 sec
The following tests FAILED:
39 - compile-buffer (Failed)
40 - compile-buffer.opt (Failed)
190 - osl-imageio (Failed)
191 - osl-imageio.opt (Failed)
202 - render-cornell.opt (Failed)
205 - render-oren-nayar.opt (Failed)
206 - render-veachmis.opt (Failed)
207 - render-ward.opt (Failed)
244 - testshade-expr (Failed)
245 - testshade-expr.opt (Failed)
Errors while running CTest
make: *** [test] Error 8
`

set OSLHOME to the dist area
The tests are just for me and for CI, we don't expect users to run them.
I should probably take a pass at it and make sure it's more robust if you don't have all the magic environment variables set up, be sure it looks in obvious default places.
In any case, this is nothing to worry about.

#737 will make the build and test work fine without OSLHOME being set.
Closing.


0.18.1 links agains glibc 2.18 not availble on CentOS 7

This issue tracker is only for technical issues related to Qtum.
Describe the issue
Official build of qtum 0.18.1 is built agains glibc 2.18 that is not availble on CentOS 7
What behavior did you expect?
I'd like to run qtum on latest stable centos if it is supported by application
What was the actual behavior (provide screenshots if the issue is GUI-related)?
# ldd bin/qtumd
bin/qtumd: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by bin/qtumd)
	linux-vdso.so.1 =>  (0x00007ffee14cd000)
	librt.so.1 => /lib64/librt.so.1 (0x00007ff31f62a000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff31f40e000)
	libm.so.6 => /lib64/libm.so.6 (0x00007ff31f10c000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff31eef6000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ff31eb29000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff320c6a000)

How reliably can you reproduce the issue, what are the steps to do so?
What version of Qtum are you using, where did you get it (website, self-compiled, etc)?
0.18.1
What type of machine are you observing the error on (OS/CPU and disk type)?
CentOS 7.7.1908

The public release now requires GLIBC >=2.18, we will make a build for centos7 and add it to our repo soon.


Get what half of what edge polygon collids to.

Here's the polygon:
new SAT.Box(new SAT.Vector(0, 0), 69, 40).toPolygon().translate(-34.5, -20)

Is it possible to detect what half of what edge (1 or 3) another polygon collids to?

The polygons may be rotated.

I don't think there's a simple way to get this - This lib only tells you if two items collide and what the shortest vector to move either of them to not make them collide anymore.
This is somewhat similar to #37
You might be able to use the overlap vector returned in the collision response to determine which edge the colliding polygon was closest to, but I'm not sure you're going to be able to get anything more than that. The colliding polygon could be on both halves of the edges.

what about taking the mid-point of an edge?


Implement actual code to send email notifications

Describe your changes and why you are making these changes
This PR implements email sending code based on standard go smtp library reference.
Related issue number (if any)
ENG-2268
Loom demo (if any)
First part of https://www.loom.com/share/b7929818b83743d881db8d712675fdc3
Checklist before requesting a review

[ ] I have created a descriptive PR title. The PR title should complete the sentence "This PR...".
[ ] I have performed a self-review of my code.
[ ] I have included a small demo of the changes. For the UI, this would be a screenshot or a Loom video.
[ ] If this is a new feature, I have added unit tests and integration tests.
[ ] I have run the integration tests locally and they are passing.
[ ] I have run the linter script locally (See python3 scripts/run_linters.py -h for usage).
[ ] All features on the UI continue to work correctly.
[ ] Added one of the following CI labels:

run_integration_test: Runs integration tests
skip_integration_test: Skips integration tests (Should be used when changes are ONLY documentation/UI)

@cw75 @hsubbaraj-spiral I'm going to merge this PR now to unblock the whole stack. But feel free to drop additional comments and I can address separately.


update copyright prop to be an array of copyrights (fixes #2)

Issue #, if available:
#2
Description of changes:
changes copyright (string) to copyrights (string[])
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@dabutvin Agh! Sorry! I realized I didn't have notifications turned on for this repo. :(
Fixed that, and merged. Thanks for your contribution!

:+1: no worries!


I send it in the Demo.ipynb code first, the ID of the text tags and the PARSED_CONTENT_LIST is inconsistent.

I found that the digital labels on the picture and the index of the PARED_CONTENT_LIST can be corresponding. It's just that the two are different. For example, the text of the digital label 12 is DOG, and the index in the PARSED_CONATENT_LIST is the confnt of 12. But Bbox's coordinates are consistent.

73 {'type': 'icon', 'bbox': [0.30748462677001953, 0.7972637414932251, 0.5034134984016418, 0.8806127905845642], 'interactivity': True, 'content': 'A link to an email or message.'}

such as 73.PARSED_CONATENT_LIST’content is 'A link to an email or message.', 73 of picture is others


h11._util.RemoteProtocolError: illegal header line: bytearray(b'Cookie: \

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the FastAPI documentation, with the integrated search.
[X] I already searched in Google "How to X in FastAPI" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to FastAPI but to Pydantic.
[X] I already checked if it is not related to FastAPI but to Swagger UI.
[X] I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
sys.argv = [
			"gunicorn",
			"--preload",
			"-b", f"<IP_ADDRESS>:{port}",
			"--threads", str(multiprocessing.cpu_count()),
			"-w", str((multiprocessing.cpu_count()*2)+1),
			"--max-requests", "1000",
			"--max-requests-jitter", "50",
			"-k", " uvicorn.workers.UvicornH11Worker",
			"--keep-alive", "0",
			"main:app",
		]

### Description

i am using gunicorn with ``uvicorn.workers.UvicornH11Worker`` and keep getting the error
i found a lot solutions and non worked for me
i am using digital ocean

### Operating System

Linux

### Operating System Details

OS: Ubuntu 20.04LTS
Python 3.8.10
Fastapi 0.70.0
Uvicorn 0.14.0
Gunicorn 20.1.0

### FastAPI Version

0.70.0

### Python Version

3.8.10

### Additional Context

![image](https://user-images.githubusercontent.com/43340190/144101577-5ca7c89e-23bc-445b-97f4-3b7b1edb9d32.png)

Hello @MayankFawkes , I got this error while deploying a fastapi server on digital ocean droplet.
It occurs when I try to send https requests to the server. I suspect it is because of not having SSL sertificate.
How about you, did you solve this issue?

@FarukOzderim  same i am also using digital ocean and it still didn't solve for me but i am just ignoring the error. I guess it is because of some bots sending https request on port 80 not sure other than that error everything is working perfectly fine, i tried to solve that but it didn't work so i just ignored the error.


Minimize to tray should not remove tray icon

Tested on windows.
Minimize driveshare-gui to tray. I am getting a nice tray icon. If I restore driveshare-gui the tray icon should still be in the tray like every other icon. Don't remove it.

@littleskunk, I think this a subjective behavior expectation. Personally, I feel that if the app has focus, the user is engaged with it and there is no need to keep the icon in tray (hence "minimize to tray").
This should not hold up the v0.5.0 release, so I'm labeling it as a discussion and keeping it in the backlog for now.

I agree with @littleskunk. When I click on other apps on Windows, they come in focus but stay in tray. I think we should follow what the expected behavior is.
Oh the flip side @gordonwritescode is right. "Minimize to tray" is not really descriptive of the expected behavior. Think we should rename that slightly and do the expected behavior.
Not sure if this is the expected behavior on Mac of Linux.

Got a ACK from @littleskunk on Slack. #77 was another issue where on Mac we fixed it to fit the expected behavior. My open ended question is that is this the expected behavior for OSX and Linux. If this is not the case then this should only be a fix for Windows similar to #77.

Addressed in #159


Knowledge has an incompatible new v3 file format

See instructlab/sdg#160
A new v3 knowledge format has been added to InstructLab, with no backwards compatibility for v1 or v2 contributions - this till be released in InstructLab v0.18.0.
Existing knowledge contributions need to be updated, along with any documentation on creating knowledge contributions.
https://github.com/instructlab/instructlab/blob/main/scripts/test-data/e2e-qna-knowledge.yaml is an example of the new format

We have existing v1 knowledge in the main branch which needs to be fixed or removed.

xref #1260

v3 example: #1255

From @juliadenham :+1:

The yaml file must include a minimum of 5 context fields, each with a minimum of 3 Q&A pairs relating to the context.
Context should be a chunk from the knowledge document(s) being submitted and should be in markdown format.
Length constraints:
500 words for context
250 words for Q&A pairs
750 total
Document_outline is a new field that replaces task_description. It should describe the information noting specifics from each context hunk.

We now support V3 knowledge, yay!


addId for queryTransformer | feature

It would be nice to have something like addTypename (queryTransformer) but for object ids.
All my models has attribute id but sometimes I will forget to add id property into the query and then apollo-client is not working properly because it has data like User:undefined. I think that it will help some developers too.

Currently I am using addTypename and it is great.

I think that's a great proposal and we'll make Apollo Client add that to queries automatically as soon as the __id proposal is implemented in most GraphQL servers. Right now it would cause queries to fail if you add id to a type that doesn't have that field (presumably your query type doesn't have an id, or does it?).

I did not know about __id proposal. I added id field to all my queries because I was able to completely remove refetchQueries after my mutations. For models I am using ID from database but for other responses I am using "virtual id" Very often it is combination of the query arguments.
  query getLike($userId: ID!, $modelId: ID!, $modelName: String!) {
    like(userId: $userId, modelId: $modelId, modelName: $modelName) {
      id,
      type,
      isLiked,
    }
  }

id will be computed as ${userId}-${modelId}-${modelName}

We're considering adding a default dataIdFromObject function, and we might expose an option to add the necessary fields for that (id and __typename), but for generic modifications I think it makes more sense to do those outside of apollo-client. Maybe graphql-tag could provide such functionality. In Apollo Client core we prefer not to modify the query that's passed in (even though we currently do).


[yurtctl] Refactor yurtctl: Separate the image used by the conversion job from yurtctl

Background:
During yurtctl conversion, the Job will be issued to the cloud and edge nodes. The edge node will start yurthub, modify the kubelet configuration, etc. And the cloud node will modify the kube-controller-manager configuration. The image used by these jobs (pkg/yurtctl/constants/constants.go) is yurtctl binary file.
What would you like to be added:
Decouple the image used by the conversion job from yurtctl. You can consider separating the content of the job executed by the cloud and edge node from yurtctl and making it a new module in yurtctl, which serves as the job image. Yurtctl only performs job delivery.
Why is this needed:
The user runs yurtctl, and yurtctl is executed again in the Job issued by yurtctl, which is equivalent to yurtctl calling itself. The logic of using yurtctl is too complicated, which is not conducive to other developers to understand and use.
others
/kind design

/assign @adamzhoul


⚠ Bofrost.de has degraded performance

In 01580e6, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1839 ms

Resolved: Bofrost.de performance has improved in 253fc27 after 27 minutes.


CI for Node

to new branch

Contains the compiled JavaScript

Contains the compiled JavaScript
On Tue, Aug 17, 2021 at 9:08 AM github-learning-lab[bot] <
@.***> wrote:

Waiting on tests
Great! Now that the testing framework is properly configured, we should
get a response from it soon. This time, you'll practice reading the logs on
your own. Just like before, you can follow along as GitHub Actions runs
your job by going to the Actions tab
https://github.com/DFinn-Takeoff/github-actions-for-ci/actions or by
clicking on "Details" in the merge box below.
When the tests finish, you'll see a red X ❌ or a green check mark ✔ in
the merge box. At that point, you'll have access to logs for the build job
and its associated steps.
Step 4: Read an Actions log
By looking at the logs, can you identify which tests failed? To find
it, go to one of the failed builds and scrolling through the log. Look for
a section that lists all the unit tests. We're looking for the name of the
test with an "x".
[image: screenshot of a sample build log with the names of the tests
blurred out]
https://user-images.githubusercontent.com/16547949/65922013-e740a200-e3b1-11e9-8151-faf52c30201e.png
⌨ Activity: Tell the bot which test is failing so we can fix it

Navigate to the log output
Identify a name of a failing test
Comment the name of the failing test here

I'll respond when you enter the name of at least one failing test. You can
either copy and paste that portion of the log directly, or type the name of
the test as a comment.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/DFinn-Takeoff/github-actions-for-ci/pull/2#issuecomment-900283034,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOZJM3PBDV3SBLYGF4DKGFLT5JNMVANCNFSM5CJ2LNQA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

--
Disclaimer: This message contains confidential information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this email. Please notify the sender immediately by email if you have
received this email by mistake and delete this email from your system. If
you are not the intended recipient, you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of
this information is strictly prohibited.


Can't install on Windows

Can't install, i try to remove, clean cache etc
C:\WINDOWS\system32>yarn create eth-app my-eth-app
yarn create v1.22.17
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...

success Installed<EMAIL_ADDRESS>with binaries:
      - create-eth-app
[##] 2/2'C:\Users\Gonçalo' is not recognized as an internal or external command,
operable program or batch file.
error Command failed.
Exit code: 1
Command: C:\Users\Gonçalo Oliveira\AppData\Local\Yarn\bin\create-eth-app
Arguments: my-eth-app
Directory: C:\WINDOWS\system32
Output:

info Visit https://yarnpkg.com/en/docs/cli/create for documentation about this command.

This looks like a Windows user permission issue. Does it work if you run the command as an administrator?

i test with command as an administrator, and didn't work

I resolve the problem, i need to change the name, without spaces


fix show statement's rewriting bug

Related Issue https://github.com/influxdata/influxdb/issues/6480
when rewriting ShowXStatement, the result statement should inherit the previous statment's  database and retention policy
Required for all non-trivial PRs

[x] Rebased/mergable
[x] Tests pass
[x] CHANGELOG.md updated
[x] Sign CLA (if not already signed)

@jsternberg @benbjohnson

@jsternberg @benbjohnson
Hello, Is there anything else I need to fix?


Rexie appears to hang on add()

I was following the example on the README, and while it seems to get through the await in initialization, it appears to get stuck in the await from the add(). Noob question: Do I need to have an async runtime already running for this to work? I had assumed no, since I called into the rust async function from javascript in the browser. But I'm not sure as I'm new to WASM.

I'm not sure the exact reason you're facing this issue. Can you post some code so that I can debug the issue?


Custom Windows SSH-Agent Deadlock issue

Hi Nathan,
I'm so glad I came across this repo, it does exactly what I need.
I've come across an issue when running winssh-pageant with my own custom SSH-Agent (this is running using the crypto/ssh/agent library)
I run my custom SSH-Agent, which allows connections using named pipes, and when I run winssh-pageant, this allows connections using PuTTY just fine.
But if I'm doing other things on my computer, after a little while, winssh-pageant always seems to crash with a deadlock.
From what I can find out about the error, it appears to be related to a nil pointer in the message loop, in the main() function.
...
for win.GetMessage(&msg, 0, 0, 0) > 0 {
...

A really good explanation of I what I think the problem is, is detailed here
The full error stack for my issue is show below.
$ go run ./
Exception 0xc0000005 0x0 0xc0001d3f30 0x7ff945ce1b4e
PC=0x7ff945ce1b4e

syscall.Syscall6(0x7ff945ce1b10, 0x4, 0xc0001d3f28, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        C:/Program Files/Go/src/runtime/syscall_windows.go:343 +0xf2
github.com/lxn/win.GetMessage(0xc0001d3f28, 0x0, 0x0, 0x1)
        C:/Users/user/go/pkg/mod/github.com/lxn/win@v0.0.0-20210218163916-a377121e959e/user32.go:2642 +0xab
main.main()
        C:/Users/user/Repos/winssh-pageant/main.go:31 +0xf4

goroutine 6 [chan receive, 7 minutes]:
github.com/Microsoft/go-winio.(*win32PipeListener).Accept(0xc00009e0a0, 0x5c, 0xc000043ee8, 0x2c4088, 0xc00009e0a0)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:483 +0x14c
main.pipeProxy()
        C:/Users/user/Repos/winssh-pageant/pageant.go:188 +0x282
created by main.main
        C:/Users/user/Repos/winssh-pageant/main.go:20 +0x1ff

goroutine 18 [select, 7 minutes]:
github.com/Microsoft/go-winio.(*win32PipeListener).makeConnectedServerPipe(0xc00009e0a0, 0xc00003df68, 0x0, 0x0)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:365 +0x139
github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine(0xc00009e0a0)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:395 +0x132
created by github.com/Microsoft/go-winio.ListenPipe
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:460 +0x1e9

goroutine 7 [syscall, locked to thread]:
syscall.Syscall6(0x7ff947b45dd0, 0x5, 0x324, 0xc000123f9c, 0xc000123fa0, 0xc000123fa8, 0xffffffff, 0x0, 0x0, 0x0, ...)
        C:/Program Files/Go/src/runtime/syscall_windows.go:343 +0xf2
github.com/Microsoft/go-winio.getQueuedCompletionStatus(0x324, 0xc000123f9c, 0xc000123fa0, 0xc000123fa8, 0xffffffff, 0x0, 0x0)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/zsyscall_windows.go:107 +0xd5
github.com/Microsoft/go-winio.ioCompletionProcessor(0x324)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/file.go:167 +0xb6
created by github.com/Microsoft/go-winio.initIo
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/file.go:73 +0x85

goroutine 8 [select, 7 minutes]:
github.com/Microsoft/go-winio.(*win32File).asyncIo(0xc00011c000, 0xc000112c00, 0x0, 0x0, 0x2c33e0, 0x34e218, 0x0, 0x0, 0x0)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/file.go:194 +0x14b
github.com/Microsoft/go-winio.connectPipe(0xc00011c000, 0x0, 0x0)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:472 +0xe5
github.com/Microsoft/go-winio.(*win32PipeListener).makeConnectedServerPipe.func1(0xc00004a2a0, 0xc00011c000)
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:362 +0x32
created by github.com/Microsoft/go-winio.(*win32PipeListener).makeConnectedServerPipe
        C:/Users/user/go/pkg/mod/github.com/!microsoft/go-winio@v0.4.14/pipe.go:361 +0xc5
rax     0x0
rbx     0xc0001d3f28
rcx     0x7ff945c91104
rdi     0x0
rsi     0xc0001d3e80
rbp     0xc0001d3e20
rsp     0xfab77ffda0
r8      0xfab77ffd98
r9      0xc0001d3e20
r10     0x0
r11     0x246
r12     0x27cac0
r13     0x0
r14     0x0
r15     0x2030000
rip     0x7ff945ce1b4e
rflags  0x10293
cs      0x33
fs      0x53
gs      0x2b
exit status 2

A few possible solutions I've found are listed below (I'm not sure if they would be a permanent fix, but they at least worked for me)

One Possible solution I found was from here
Suggesting to define msg as this

	 msg := (*win.MSG)(unsafe.Pointer(win.GlobalAlloc(0, unsafe.Sizeof(win.MSG{}))))
	 defer win.GlobalFree(win.HGLOBAL(unsafe.Pointer(msg)))
	 for win.GetMessage(msg, 0, 0, 0) > 0 {
	 	win.TranslateMessage(msg)
	 	win.DispatchMessage(msg)
	 }

Another solution was to place an runtime.LockOSThread() in the main() function, I found this discussed here

func main()
    runtime.LockOSThread()
...

Thanks so much for putting together this repo, it's been really really helpful.
And many thanks for any help.
-Gary

Ohh joy this is going to be a fun one to fix 😅, interfacing with win32 api in go is always a nightmare.
I'll look into it, can I get the code/binary for the custom SSH agent you're using, so that I may replicate this error and then test fixes.

Poking through the forks, you've forked this and seemingly implemented a fix already: https://github.com/gazzenger/winssh-pageant
Did you have plans to open a pull request?

Awesome, I've gone and created a pull request, https://github.com/ndbeals/winssh-pageant/pull/11
There is some other stuff in this, relating more to reading from the SSH list function with bufio - so feel free to have a look.
Unrelated, but if you're interested, I've made some other commits, and moved the pageant.go file into it's own folder. This allows the package to be imported into other peoples code.
https://github.com/gazzenger/winssh-pageant/commit/b3cebc44b3852e5cbba807df6b83cde5c608897e

Thanks for opening the pull request, I plan to merge it today.
As for making pageant.go it's own pacakge, I'm cool with that, though I personally lack the imagination to see why others may want to use it, but that's on me. I'll end up pulling that one in a little later, feel free to open a PR for it too.
Further discussion relating to PR #11 should be had in that PR, as I've got a few questions for you in it already.

PR #11 merged, closing this.


nixos-rebuild: capture the switch output to the journal

Currently nixos-rebuild switch runs switch-to-configuration attached to the user's terminal, but under systemd-run. This is great and helps take the switch to completion if the terminal vanishes, but it does not log the switch output itself to the journal because it is passed straight through to the terminal. We cannot stop using --pty mode, because some users do use stdin in their configuration switch scripts.
 There was no log of what it did, besides guessing at which service changes were its fault while looking at the journal afterwards.
Fortunately, there is an ancient Unix utility called script(1) (today, in the util-linux package) which makes digital logs of your teletypewriter printouts as files, so you can grep them without having to pore over a large stack of folded paper by hand! What a labour saving!
This is exactly what we want, if the file in question is a pipe to systemd-cat, and it just takes some clever wrapping with a little bash script to shell-quote the command losslessly, so we can stick it in front of the configuration switch.
Arguably logging systemd-run pty mode could be a reasonable feature to include in systemd, but we already depend on util-linux for switch-to-configuration and can compose together something that works today.
Sample log:
Feb 11 08:18:16 nixos nixos-rebuild[1199]: Script started on 2024-02-11 08:18:16+00:00 [COMMAND="'/nix/store/q54lbnnnxic7pp2gg1lrs12ym5mgwrfz-nixos-system-nixos-24.05.20240204.>
Feb 11 08:18:16 nixos nixos-rebuild[1199]: Warning: do not know how to make this configuration bootable; please enable a boot loader.
Feb 11 08:18:16 nixos nixos[1200]: switching to system configuration /nix/store/q54lbnnnxic7pp2gg1lrs12ym5mgwrfz-nixos-system-nixos-24.05.20240204.dirty
Feb 11 08:18:16 nixos systemd[1]: Stopped target Local File Systems.
Feb 11 08:18:16 nixos systemd[1]: Stopped target Remote File Systems.
Feb 11 08:18:16 nixos nixos-rebuild[1199]: activating the configuration...
Feb 11 08:18:17 nixos nixos-rebuild[1199]: setting up /etc...
Feb 11 08:18:17 nixos systemd[1]: Reloading requested from client PID 1252 ('systemctl') (unit nixos-rebuild-switch-to-configuration.service)...
Feb 11 08:18:17 nixos systemd[1]: Reloading...
Feb 11 08:18:17 nixos systemd[1]: Reloading finished in 403 ms.
Feb 11 08:18:17 nixos nixos-rebuild[1199]: reloading user units for root...
Feb 11 08:18:17 nixos su[1278]: Successful su for root by root
Feb 11 08:18:17 nixos su[1278]: pam_unix(su:session): session opened for user root(uid=0) by (uid=0)
Feb 11 08:18:17 nixos systemd[1174]: Reexecuting requested from client PID 1280 ('systemctl')...
Feb 11 08:18:17 nixos systemd[1174]: Reexecuting.
Feb 11 08:18:17 nixos systemd[1174]: Run user-specific NixOS activation was skipped because of an unmet condition check (ConditionUser=!@system).
Feb 11 08:18:17 nixos su[1278]: pam_unix(su:session): session closed for user root
Feb 11 08:18:17 nixos nixos-rebuild[1199]: restarting sysinit-reactivation.target
Feb 11 08:18:17 nixos systemd[1]: Stopped target Reactivate sysinit units.
Feb 11 08:18:17 nixos systemd[1]: Stopping Reactivate sysinit units...
Feb 11 08:18:17 nixos systemd[1]: Reached target Reactivate sysinit units.
Feb 11 08:18:17 nixos systemd[1]: Reached target Local File Systems.
Feb 11 08:18:17 nixos systemd[1]: Reached target Remote File Systems.
Feb 11 08:18:18 nixos systemd[1]: Starting Load Kernel Module efi_pstore...
Feb 11 08:18:18 nixos systemd[1]: Starting Create SUID/SGID Wrappers...
Feb 11 08:18:18 nixos systemd[1]<EMAIL_ADDRESS>Deactivated successfully.
Feb 11 08:18:18 nixos systemd[1]: Finished Load Kernel Module efi_pstore.
Feb 11 08:18:18 nixos systemd[1]: Platform Persistent Storage Archival was skipped because of an unmet condition check (ConditionDirectoryNotEmpty=/sys/fs/pstore).
Feb 11 08:18:18 nixos systemd[1]: suid-sgid-wrappers.service: Deactivated successfully.
Feb 11 08:18:18 nixos systemd[1]: Finished Create SUID/SGID Wrappers.
Feb 11 08:18:18 nixos nixos[1200]: finished switching to system configuration /nix/store/q54lbnnnxic7pp2gg1lrs12ym5mgwrfz-nixos-system-nixos-24.05.20240204.dirty
Feb 11 08:18:18 nixos nixos-rebuild[1199]: Script done on 2024-02-11 08:18:18+00:00 [COMMAND_EXIT_CODE="0"]

Description of changes

Things done
I have manually checked this works by putting it in a docker container where systemd-cat would be broken, and cat'ing big files. I found out that way about the load bearing alternative cat >/dev/null, which fixes the lockup that happened then. I then stuck it into NixOS and ran a switch on a remote machine. The worst case failure mode of this, in any case, is that nixos-rebuild gives up and runs without systemd-run, which is ultimately harmless.

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I like the idea in general, but I feel like there should be an opt-out. Maybe an option given to nixos-rebuild?
Also, does this mean that I cannot use my nixos-rebuild to switch to a system that was built prior to this change? It doesn't look like there are checks in place for whether that script exists. nixos-rebuild --rollback switch would just fail.

I like the idea in general, but I feel like there should be an opt-out. Maybe an option given to nixos-rebuild? Also, does this mean that I cannot use my nixos-rebuild to switch to a system that was built prior to this change? It doesn't look like there are checks in place for whether that script exists. nixos-rebuild --rollback switch would just fail.

Nope this is totally safe against that. It's not the cleanest but if you look at the code for the systemd-run stuff directly adjacent to my change in nixos-rebuild, it will automatically opt out if a self-test fails. This isn't perfectly clean because it conflates this stuff not working and systemd-run not working but either way, it will just work(tm), albeit without the systemd-run protection for such cross version executions.


Custom Themes?

I found this offering a replacement of the built-in material theme.  However, I'm unsure how one is supposed to create new themes.
I tried just adding another section in app.css but there was no change in the list found at YakYak -> View -> Color Scheme.

I would also be more than happy to create some more themes but not sure where to add them.
If anyone can provide more information that would be great!

I would also be more than happy to create some more themes but not sure where to add them.
If anyone can provide more information that would be great!

go to Contents/Resources/app/ui/app.css scroll down and you will find osmething liek this
and you will find something like this.
html.material {
  --white: #202B31;
  --ghostwhite: #2d3d46;
  --lightgrey: #28353B;
  --altgrey: #2B3E41;
  --grey: #303F47;
  --darkgrey: #617E8A;
  --lightblack: #455a64;
  --black: #99B1B7;
  --green: #900F3C;
  --darkgreen: #790d32;
  --red: #900F3C;
  --darkred: #790d32;
  --link: #14a3be;
}

those numbers are hex color codes. Pick a theme color you never gonna use (here its material i.e. html.material )  and start changing those hex numbers to the colors you want. Restart yakyak and see the difference.

That's right @Rone777 you can change one of this tags and use it on your machine.
They can also be any allowed color in css (such as rgb( , , ) )
If you guys want to contribute the new theme to the community, the files to change are:

the actual colors src/ui/css/yakyak/colors.less
a new menu item src/ui/views/menu.coffee
and the english translation template src/locales/en.json.template

Then create a pull request with these 3 changes.
Check out an example for the latest theme PoP in https://github.com/yakyak/yakyak/pull/951/files


prevent OOM errors when streaming attachments out of db for zip export

right now we have to recommend that people go up a size when choosing a DO droplet because the smallest size tends to OOM-death when streaming binary attachment data back out of the database for .csv.zip export.
this is because node receives the chunk of data and unquestioningly allocates a buffer to fit it, even if it is unwise to do so.
last time i looked it didn't seem like there was a good way to throttle this data coming back from postgres, but it makes me uncomfortable that this is a possibility so i want to look again.

maybe this: https://github.com/Joris-van-der-Wel/node-pg-large-object

it turns out, that is not probably the problem. the primary current issue is that the way we receive data from the database and queue it to the archiver does not appropriately apply backpressure. this in turn wouldn't be so bad if it weren't for the fact that the archiver actually cannot process data in parallel, so each attachment gets individually stalled and its entire buffer sits on memory waiting for the csv content to complete and flush.


Support Yarn V2 PnP

Preflight Checklist

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Proposed Solution

Support Yarn v2 PnP
Alternatives Considered

There are no alternatives, just maybe check is .pnp.js exists, if it does run X Y Z for building instead of copying node_modules
Additional Information

N/A

The last time I looked at this, it would need to export your dependencies to node_modules because Electron itself has no concept of Yarn's PnP feature.
That being said, this isn't a high priority for me to implement (without being sponsored). I'll gladly review a proposal to add this feature, although as far as I'm aware, there's nothing particular about this that requires it to be in Electron Packager itself, it could be a plugin that utilizes an afterCopy hook.

I get that, just might be cool as a lot of projects are switching to yarn v2


Add Dwolla support for bank funding sources

Currently, if someone tries to sign up for an event with dwolla, they have to have an actual balance in their account. Better would be if we supported paying directly from their bank account (if their balance isn't enough.)
This would almost certainly require dwolla webhooks - it looks like the payments don't get processed for 3-4 days. This is kinda weird; I would've expected them to just automatically use banks as a funding source if the balance was too low.

This was resolved by 2160637.


integrate with google assistant

See https://www.home-assistant.io/components/google_assistant/

Re-opening because the integration is enabled, but not sure what needs to be done to use it well.
e.g. Hey Google, close Jeff's garage door

integrated


Add sample rate support to distributions

What does this PR do?
Add support for sampling to distributions by inserting 1 / sample rate values
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?

@olivielpeau @ogaca-dd is this OK to merge?

@ogaca-dd do we need to kick the build somehow?

merged master into the branch, CI should pass now


Updates documentation

Checklist

[ ] Updated CHANGELOG.md describing pertinent changes.
[x] Updated README.md with pertinent info (may not always apply).
[ ] Squash down commits (optional).

Fixes #18

99513e5 closes #29 with instructions included