OTA OVER BLE MESH (IDFGH-12080)

Is your feature request related to a problem?
Hello there Espressif team!
We currently working with the ESP32-S3 in a BLE MESH app. I'm mostly using the Vendor model to transmit the values that I need, and it works as expected.
I would like to add an OTA feature. I would like to know which model can be used to for this?
Thanks a lot in advance.
Describe the solution you'd like.
No response
Describe alternatives you've considered.
No response
Additional context.
No response

You can refer to here:
https://github.com/espressif/esp-iot-solution/tree/master/examples/bluetooth/ble_ota

Thanks you @XionHsieh

@xiewenxiang  will this OTA example work on BLE_mesh?


close triggers page reload

Hi,
clicking on the close button trigger page reload (perhaps because I have a form in my template).
Would be nice to prevent submit on the click (I do it in the action). IIRC, it should be possible by replacing @click by @click.prevent

Hey,
Are you able to post an example here (possibly the full component file)? I am not able to reproduce this.
Here is a component I tried:
<template>
  <div>
    <modal :showModal="visible" :closeAction="toggle">
      <form slot="body" action="http://example.com">
        <input type="text">
        <input type="submit">
      </form>
    </modal>
    <button type="btn btn-default" @click="toggle">Show</button>
  </div>
</template>

<script>
import Modal from 'modal-vue';

export default {
  components: {
    Modal,
  },
  data() {
    return {
      visible: false,
    };
  },
  methods: {
    toggle() {
      this.visible = !this.visible;
    },
  },
};
</script>

My results:
Clicking the "submit" button sends the browser to the action url, as expected. Clicking the close button performs the closeAction and does not invoke submit, as expected.
Above behaviour also remains the same when no closeAction is specified.


Error: unable to load seccomp BPF program: Invalid argument

I get following error while trying to build a docker image using the README instructions.
 => ERROR [build 3/3] RUN   nix-env -f default.nix -iA myEnv --show-trace   && export-profile /dist                          13.1s
------
 > [build 3/3] RUN   nix-env -f default.nix -iA myEnv --show-trace   && export-profile /dist:
#7 0.804 installing 'env'
#7 4.654 these 2 derivations will be built:
#7 4.656   /nix/store/imf2qzrzs0qggbabsn3f5mr3wa5jxhkh-builder.pl.drv
#7 4.656   /nix/store/k1rhrji3ha5zfhb15q21ki5fds9gr58h-env.drv
#7 4.660 these 12 paths will be fetched (10.44 MiB download, 68.78 MiB unpacked):
#7 4.660   /nix/store/526xlkd8f2q5vbdy68rnv4x5d0wzml8w-diffutils-3.8
#7 4.660   /nix/store/576iqyz893c8zg0qy92is04cgcjanqky-file-5.43
#7 4.660   /nix/store/6s9h7vcjxhh76kaa6plickgik9c7rpqj-curl-7.86.0-man
#7 4.660   /nix/store/8dj94g330sk2q5kvji3jy0fpcj5m0kii-stdenv-linux
#7 4.660   /nix/store/8p49h8m12hx1qjxgw98vrx17a6hxcn2z-findutils-4.9.0
#7 4.660   /nix/store/gjyskq701gwzpin34r3rqlcaqif7v3l6-patch-2.7.6
#7 4.660   /nix/store/hnwgz78qripqnnnprar3lzmp7ymkv90x-gnumake-4.3
#7 4.660   /nix/store/hybxi0dm46sd8cf2xw6nhsdy858qlvyf-ed-1.18
#7 4.660   /nix/store/qbbh33w8jwr1pb6vxp2aplcsdlj6hvvk-patchelf-0.15.0
#7 4.661   /nix/store/qs14qs0x86ibndw0j5mwf1v46jxn56ld-gawk-5.1.1
#7 4.661   /nix/store/xdd67g9ps5aripg044v6y4j1qsli76fh-curl-7.86.0-bin
#7 4.661   /nix/store/yxd2rlvzh1n01j1f86zcxlj8xr20kwh5-perl-5.36.0
#7 4.728 copying path '/nix/store/6s9h7vcjxhh76kaa6plickgik9c7rpqj-curl-7.86.0-man' from 'https://cache.nixos.org'...
#7 4.899 copying path '/nix/store/xdd67g9ps5aripg044v6y4j1qsli76fh-curl-7.86.0-bin' from 'https://cache.nixos.org'...
#7 5.017 copying path '/nix/store/526xlkd8f2q5vbdy68rnv4x5d0wzml8w-diffutils-3.8' from 'https://cache.nixos.org'...
#7 5.283 copying path '/nix/store/hybxi0dm46sd8cf2xw6nhsdy858qlvyf-ed-1.18' from 'https://cache.nixos.org'...
#7 5.660 copying path '/nix/store/576iqyz893c8zg0qy92is04cgcjanqky-file-5.43' from 'https://cache.nixos.org'...
#7 6.300 copying path '/nix/store/8p49h8m12hx1qjxgw98vrx17a6hxcn2z-findutils-4.9.0' from 'https://cache.nixos.org'...
#7 6.567 copying path '/nix/store/qs14qs0x86ibndw0j5mwf1v46jxn56ld-gawk-5.1.1' from 'https://cache.nixos.org'...
#7 6.983 copying path '/nix/store/hnwgz78qripqnnnprar3lzmp7ymkv90x-gnumake-4.3' from 'https://cache.nixos.org'...
#7 7.213 copying path '/nix/store/gjyskq701gwzpin34r3rqlcaqif7v3l6-patch-2.7.6' from 'https://cache.nixos.org'...
#7 7.335 copying path '/nix/store/qbbh33w8jwr1pb6vxp2aplcsdlj6hvvk-patchelf-0.15.0' from 'https://cache.nixos.org'...
#7 7.487 copying path '/nix/store/yxd2rlvzh1n01j1f86zcxlj8xr20kwh5-perl-5.36.0' from 'https://cache.nixos.org'...
#7 12.83 copying path '/nix/store/8dj94g330sk2q5kvji3jy0fpcj5m0kii-stdenv-linux' from 'https://cache.nixos.org'...
#7 12.99 error: unable to load seccomp BPF program: Invalid argument
#7 12.99
#7 12.99        … while setting up the build environment

Below is my Dockerfile
FROM niteo/nixpkgs-nixos-22.11:ea96b4af6148114421fda90df33cf236ff5ecf1d AS build

# Import the project source
COPY default.nix default.nix

RUN \
  # Install the program to propagate to the final image
  nix-env -f default.nix -iA myEnv --show-trace \
  # Exports a root directory structure containing all dependencies
  # installed with nix-env under /run/profile
  && export-profile /dist

# Second Docker stage, we start with a completely empty image
FROM scratch

# Copy the /dist root folder from the previous stage into this one
COPY --from=build /dist /

# Set PATH so Nix binaries can be found
ENV PATH=/run/profile/bin
ENV NIX_SSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt

Below is the nix file
let
  pkgs = import <nixpkgs> {};
in {
  myEnv = pkgs.buildEnv {
    name = "env";
    paths = with pkgs; [
      curl
      cacert
    ];
  };
}

This error was fixed by setting nix-env -f default.nix -iA myEnv --option filter-syscalls false


setting imagePullSecrets for workers

Setting the imagepullsecrets. Not sure this is the best location to do this in.

Added the changes requested. There does seem to be an intermittent build error with mqtt.

Updates pushed up. Resolved all the changes.


consider using default authN scheme

instead of having our own scheme property on the auth options. might be easier for consuming devs to not have 3 places to change the default.

done
https://github.com/IdentityServer/IdentityServer4/pull/1446
plz review @brockallen

Yep, reviewed it all. I made some tweaks here & there, but all in all looks good. There are more TODOs in the comments for us to go over together before release.


[added]Provide a hook to enable infinite scroll in modal

I was trying to implement a infinite scroll feature within the modal using this library. I soon discovered that I had to fork the repo and make changes to let me provide a callback on scroll event. I was successful in implementing the feature after making the changes and thought it would be useful to have the same hook in the original library.
It would be useful when you are trying to implement a modal to display a list of users (followers, people liked a post, etc..) and need to fetch more resource as you scroll down inside the modal.
Changes proposed:

Add two props onEndReached and onEndReachedThreshold to let user provide a callback function when bottom of the modal is reached.
This provides a hook to enable infinite scroll feature inside the modal

@kenny-hibino, this feature looks really good, but maybe it can be a separate module that can be used within the modal.
<Modal { modal props }>
  <InfinityScroll { props for the infinity scroll } />
</Modal>

@diasbruno Thank you for replying! I will try to see if I can extract this out into a separate module as you suggested 👍

@kenny-hibino awesome! It'll be an awesome component because people could use it anywhere.

@claydiffrient This issue can be closed.
@kenny-hibino Remember that you still can publish your own version with this feature...and/or if you implement a infinity scroll component, remember to share it! :)


[RFR] Get volume attachment from instance

[x] Method to find attached volumes of Openstack Instance/Server

@mshriver  : I am done with this thing and you can proceed through PR. I will raise another PR if I find something need to be added later.


th trainMNIST.lua error: SpatialSoftMax.lua:38: bad argument #1 to 'resizeAs' (torch.DoubleTensor expected, got torch.CudaTensor)

Hi Ritchie,
Thank you for the code.
There is a error, SpatialSoftMax.lua:38: bad argument #1 to 'resizeAs' (torch.DoubleTensor expected, got torch.CudaTensor), when I run the command, th trainMNIST.lua, After I  convert the data type,  torch.CudaTensor, to  torch.DoubleTensor. There is a new error, assertion failed!.  How to deal with it? Thank you for you answering.

Thanks for pointing this out! I must have introduced this bug when I copied this code over from the project it originally came from.


Support yield from connect/serve on Python 3.7.

Fix #435.

I rebased the PR after updating to Circle CI 2.0 in order to be able to run tests on Python 3.7.


Wrong version

### Version
3.0.0
Node and OS info
node 8.11, npm 5.6, Mac OS 10.13
Steps to reproduce
Install beta version of cli. Uninstall beta. Then install stable 3.0.0. Print version.
What is expected?
version 3.0.0
What is actually happening?
version 3.0.0-beta.6

Probably right. Thanks.

I removed npm, node, yarn and every node related file/folder recursively. But vue command was still working with the beta version.
Then i reinstalled everything and vue-cli. Still got the beta version.
Then i had to install yarn garbage and removed cli-beta by yarn. That worked.
Then i removed yarn.
Never install yarn again. Happy ending.


Update controller-runtime to v0.15.0

Problem Statement
controller-runtime was recently released with support for k8s 1.27.x
https://github.com/kubernetes-sigs/controller-runtime/releases/tag/v0.15.0
Proposed Solution
Update the go.mod and update code for the backward breaking changes
Alternatives Considered
None
Additional Context
None

fixed in https://github.com/cisco-open/operator-tools/pull/158


[ru] Localize auto-scaling.md

Description
This PR adds RU localization of Auto-scaling
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

@tym83 this one is ready, please approve


Can not modify Value when it's an array.

The copy constructor in json11.h is like this : "const Value & operator[](size_t i) const"
So user can not update an array by "[]", for example : obj["array"][0] = a_json_value;
Why is it designed like this?

The Json type is intended to be an immutable value type, which has a number of advantages including thread safety and the ability to share data across copies.  If you want a mutable array you can use a Json::array (which is just a typedef for a vector) and mutate it freely before putting it into a Json object.


Start publishing a list of public homeservers

matrix.org (duh)
we.ho.st
disroot.org

If you want to advertise public HS hosting, please add a comment here and we'll get you added to an official list somewhere on matrix.org!

matrix.allmende.io

important thing to remember with public homeservers: where is HS hosted and what promises "owner" gives. or how do you even measure quality of public HS? if someone just got cheap VPS from somewhere and HS gets lots of accounts and one day owner can't pay for it anymore... well, you get the idea.

A table that indicates information about each server's reliability, updates, security, etc., could be modelled after: https://xmpp.net/directory.php or http://www.jabberes.org/servers/ or https://list.jabber.at/

I have made a first attempt at a public server list for Matrix: https://www.hello-matrix.net/public_servers.php
I have added the servers above to which I could actually connect. Let me know if you want to use this or get added to it (or want to add details to your server's listing).

this isn't really a spec issue. Closing in favour of https://github.com/matrix-org/matrix.org/issues/95


Envoy caching routes

I was trying out contour by installing the simple kuard example, I was able to get it up and working very quickly and easily. I then tried making it TLS; I run on prem 1.9 HA cluster. When I added TLS the https connection would ask to accept self-signed cert then give a 404 but the http would work, while trying to debug I found that the envoy admin interface routes showed the old routes that I deleted when I re-created the ingress resource for TLS, I believe this is why the http connection was still working. I deleted the pod and waited for the new one to be created and brought the envoy admin page back up, this time it had the correct routes.
I believe envoy is somehow caching routes. I believe this is an undesired feature.
Thanks for the support.

Hi, sorry you're having issues. I'm going to need a few pieces of information to help you.

Can you grab the output of the envoy container

% kubectl logs -n heptio-contour -c envoy -l app=contour

and the output of the contour container
% kubectl logs -n heptio-contour -c contour -l app=contour

and the ingress object you applied.

So first I installed the example rbac deployment example except I removed the service definition and added hostNetwork: true to the pod definition. Then I applied this ingress resource:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kuard-ing
  labels:
    app: kuard
  annotations:
    kubernetes.io/ingress.class: contour
spec:
  backend:
    serviceName: kuard
    servicePort: 80

This works and I see this in the routes endpoint in envoy:
[
{
"version_info": "1",
"route_config_name": "ingress_http",
"config_source": {
 "api_config_source": {
  "api_type": "GRPC",
  "cluster_names": [
   "contour"
  ],
  "grpc_services": [
   {
    "envoy_grpc": {
     "cluster_name": "contour"
    }
   }
  ]
 }
}
,
"route_table_dump": {
 "name": "ingress_http",
 "virtual_hosts": [
  {
   "name": "*",
   "domains": [
    "*"
   ],
   "routes": [
    {
     "match": {
      "prefix": "/"
     },
     "route": {
      "cluster": "default/kuard/80"
     }
    }
   ]
  }
 ]
}

}
]

It's when I edit the ingress resource to:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kuard-ing
  labels:
    app: kuard
  annotations:
    kubernetes.io/ingress.class: contour
spec:
  rules:
  - host: kuard.db.gd-ms.com
    http:
      paths:
      - backend:
         serviceName: kuard
         servicePort: 80
        path: /

That I see the old wildcard route still in envoy:
[
{
"version_info": "3",
"route_config_name": "ingress_http",
"config_source": {
 "api_config_source": {
  "api_type": "GRPC",
  "cluster_names": [
   "contour"
  ],
  "grpc_services": [
   {
    "envoy_grpc": {
     "cluster_name": "contour"
    }
   }
  ]
 }
}
,
"route_table_dump": {
 "name": "ingress_http",
 "virtual_hosts": [
  {
   "name": "*",
   "domains": [
    "*"
   ],
   "routes": [
    {
     "match": {
      "prefix": "/"
     },
     "route": {
      "cluster": "default/kuard/80"
     }
    }
   ]
  },
  {
   "name": "kuard.db.gd-ms.com",
   "domains": [
    "kuard.db.gd-ms.com"
   ],
   "routes": [
    {
     "match": {
      "prefix": "/"
     },
     "route": {
      "cluster": "default/kuard/80"
     }
    }
   ]
  }
 ]
}

}
]

I simplified this, originally I was trying to get TLS to work and it had other routes for https and other backends I tried to deploy.
Logs from envoy:
[2018-03-05 17:36:50.738][1][info][main] source/server/server.cc:178] initializing epoch 0 (hot restart version=9.200.16384.127.options=capacity=16384, num_slots=8209 hash=228984379728933363)
[2018-03-05 17:36:50.751][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:128] cm init: initializing cds
[2018-03-05 17:36:50.752][1][info][config] source/server/configuration_impl.cc:52] loading 0 listener(s)
[2018-03-05 17:36:50.752][1][info][config] source/server/configuration_impl.cc:92] loading tracing configuration
[2018-03-05 17:36:50.752][1][info][config] source/server/configuration_impl.cc:119] loading stats sink configuration
[2018-03-05 17:36:50.753][1][info][main] source/server/server.cc:353] starting main dispatch loop
[2018-03-05 17:36:50.755][1][warning][upstream] source/common/config/grpc_mux_impl.cc:205] gRPC config stream closed: 1,
[2018-03-05 17:36:50.755][1][warning][config] bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:66] gRPC update for type.googleapis.com/envoy.api.v2.Cluster failed
[2018-03-05 17:36:50.755][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:132] cm init: all clusters initialized
[2018-03-05 17:36:50.755][1][info][main] source/server/server.cc:337] all clusters initialized. initializing init manager
[2018-03-05 17:36:50.755][1][warning][upstream] source/common/config/grpc_mux_impl.cc:205] gRPC config stream closed: 1,
[2018-03-05 17:36:50.755][1][warning][config] bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:66] gRPC update for type.googleapis.com/envoy.api.v2.Listener failed
[2018-03-05 17:36:50.755][1][info][config] source/server/listener_manager_impl.cc:579] all dependencies initialized. starting workers
[2018-03-05 17:36:55.760][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster default/kuard/80
[2018-03-05 17:36:55.765][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster default/kubernetes/443
[2018-03-05 17:36:55.769][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster default/kubernetes/https
[2018-03-05 17:36:55.773][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/kube-dns/53
[2018-03-05 17:36:55.778][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/kube-dns/dns-tcp
[2018-03-05 17:36:55.783][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/tiller-deploy/44134
[2018-03-05 17:36:55.788][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/tiller-deploy/tiller
[2018-03-05 17:41:25.696][1][info][upstream] source/server/lds_api.cc:60] lds: add/update listener 'ingress_http'
[2018-03-05 17:51:50.753][1][info][main] source/server/drain_manager_impl.cc:63] shutting down parent after drain
[2018-03-05 17:36:56.104][1][info][main] source/server/server.cc:178] initializing epoch 0 (hot restart version=9.200.16384.127.options=capacity=16384, num_slots=8209 hash=228984379728933363)
[2018-03-05 17:36:56.120][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:128] cm init: initializing cds
[2018-03-05 17:36:56.123][1][info][config] source/server/configuration_impl.cc:52] loading 0 listener(s)
[2018-03-05 17:36:56.123][1][info][config] source/server/configuration_impl.cc:92] loading tracing configuration
[2018-03-05 17:36:56.123][1][info][config] source/server/configuration_impl.cc:119] loading stats sink configuration
[2018-03-05 17:36:56.123][1][info][main] source/server/server.cc:353] starting main dispatch loop
[2018-03-05 17:36:56.125][1][warning][upstream] source/common/config/grpc_mux_impl.cc:205] gRPC config stream closed: 1,
[2018-03-05 17:36:56.125][1][warning][config] bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:66] gRPC update for type.googleapis.com/envoy.api.v2.Cluster failed
[2018-03-05 17:36:56.125][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:132] cm init: all clusters initialized
[2018-03-05 17:36:56.125][1][info][main] source/server/server.cc:337] all clusters initialized. initializing init manager
[2018-03-05 17:36:56.125][1][warning][upstream] source/common/config/grpc_mux_impl.cc:205] gRPC config stream closed: 1,
[2018-03-05 17:36:56.125][1][warning][config] bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:66] gRPC update for type.googleapis.com/envoy.api.v2.Listener failed
[2018-03-05 17:36:56.125][1][info][config] source/server/listener_manager_impl.cc:579] all dependencies initialized. starting workers
[2018-03-05 17:37:01.132][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster default/kuard/80
[2018-03-05 17:37:01.136][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster default/kubernetes/443
[2018-03-05 17:37:01.141][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster default/kubernetes/https
[2018-03-05 17:37:01.145][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/kube-dns/53
[2018-03-05 17:37:01.149][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/kube-dns/dns-tcp
[2018-03-05 17:37:01.154][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/tiller-deploy/44134
[2018-03-05 17:37:01.159][1][info][upstream] source/common/upstream/cluster_manager_impl.cc:356] add/update cluster kube-system/tiller-deploy/tiller
[2018-03-05 17:41:25.651][1][info][upstream] source/server/lds_api.cc:60] lds: add/update listener 'ingress_http'
[2018-03-05T17:41:59.073Z] "GET / HTTP/1.1" 200 - 0 1985 7 6 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" "b9b90842-9caa-45ac-b2c8-6edc73bdefd7" "kuard.db.gd-ms.com:8080" "<IP_ADDRESS>:8080"
[2018-03-05T17:41:59.109Z] "GET /static/css/styles.css HTTP/1.1" 200 - 0 1585 5 4 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" "49ca4433-fa0b-4053-97d9-f8f7929d7788" "kuard.db.gd-ms.com:8080" "<IP_ADDRESS>:8080"
[2018-03-05T17:41:59.107Z] "GET /static/css/bootstrap.min.css HTTP/1.1" 200 - 0 144292 10 9 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" "88c5c12c-f545-4a20-98ca-3c9732e90161" "kuard.db.gd-ms.com:8080" "<IP_ADDRESS>:8080"
[2018-03-05T17:41:59.110Z] "GET /built/bundle.js HTTP/1.1" 200 - 0 331323 33 26 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" "d805ce9f-b105-4a68-aec6-7d7563696b21" "kuard.db.gd-ms.com:8080" "<IP_ADDRESS>:8080"
[2018-03-05T17:41:59.908Z] "GET /favicon.ico HTTP/1.1" 404 - 0 19 1 0 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" "9be1f917-c3cd-459e-a6c2-09e85f92230e" "kuard.db.gd-ms.com:8080" "<IP_ADDRESS>:8080"
[2018-03-05 17:51:56.123][1][info][main] source/server/drain_manager_impl.cc:63] shutting down parent after drain

Logs for contour:
time="2018-03-05T18:06:53Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=60
time="2018-03-05T18:06:53Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=66
time="2018-03-05T18:06:53Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=66
time="2018-03-05T18:06:53Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=70
time="2018-03-05T18:06:53Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=70
time="2018-03-05T18:20:53Z" level=info msg="notification received" api=RDS connection=1 context=grpc version=3
time="2018-03-05T18:20:53Z" level=info msg="waiting for notification" api=RDS connection=1 context=grpc version=3
time="2018-03-05T18:20:53Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=71
time="2018-03-05T18:20:53Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=71
time="2018-03-05T17:36:57Z" level=info msg="args: [serve --incluster]"
time="2018-03-05T17:36:57Z" level=info msg=started context=watch resource=endpoints
time="2018-03-05T17:36:57Z" level=info msg=started context=watch resource=ingresses
time="2018-03-05T17:36:57Z" level=info msg=started context=buffer
time="2018-03-05T17:36:57Z" level=info msg=started context=watch resource=secrets
time="2018-03-05T17:36:57Z" level=info msg=started context=watch resource=services
time="2018-03-05T17:36:57Z" level=info msg=started context=grpc
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=CDS connection=1 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=CDS connection=1 context=grpc version=4
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=CDS connection=1 context=grpc version=4
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=34
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=34
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=1 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=1 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=3 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=2 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=1 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=2 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=4 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=4 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=2 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=5 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=5 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=6 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=4 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=6 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=3 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=6 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=3 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=5 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=7 context=grpc version=0
time="2018-03-05T17:37:01Z" level=info msg="notification received" api=EDS connection=7 context=grpc version=6
time="2018-03-05T17:37:01Z" level=info msg="waiting for notification" api=EDS connection=7 context=grpc version=6
time="2018-03-05T17:41:25Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=35
time="2018-03-05T17:41:25Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=35
time="2018-03-05T17:41:25Z" level=info msg="waiting for notification" api=RDS connection=1 context=grpc version=0
time="2018-03-05T17:41:25Z" level=info msg="notification received" api=RDS connection=1 context=grpc version=1
time="2018-03-05T17:41:25Z" level=info msg="waiting for notification" api=RDS connection=1 context=grpc version=1
time="2018-03-05T18:06:57Z" level=info msg="notification received" api=RDS connection=1 context=grpc version=2
time="2018-03-05T18:06:57Z" level=info msg="waiting for notification" api=RDS connection=1 context=grpc version=2
time="2018-03-05T18:06:57Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=36
time="2018-03-05T18:06:57Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=36
time="2018-03-05T18:06:57Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=37
time="2018-03-05T18:06:57Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=37
time="2018-03-05T18:06:57Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=62
time="2018-03-05T18:06:57Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=62
time="2018-03-05T18:06:57Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=70
time="2018-03-05T18:06:57Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=70
time="2018-03-05T18:20:53Z" level=info msg="notification received" api=RDS connection=1 context=grpc version=3
time="2018-03-05T18:20:53Z" level=info msg="waiting for notification" api=RDS connection=1 context=grpc version=3
time="2018-03-05T18:20:53Z" level=info msg="notification received" api=LDS connection=1 context=grpc version=71
time="2018-03-05T18:20:53Z" level=info msg="waiting for notification" api=LDS connection=1 context=grpc version=71

Thanks @davecheney for the help. If you need any other info I will get it to you ASAP.

@cten thanks for the detailed reproduction, I've verified the issue and added some regression tests. Fix coming up RSN.

Looks like #271 caused contour to generate an invalid RDS record
[2018-03-13 04:35:42.167][1][warning][config] bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:69] gRPC config for type.googleapis.com/envoy.api.v2.RouteConfiguration rejected: Proto constraint validation failed (RouteConfigurationValidationError.VirtualHosts[i]: ["embedded message failed validation"] | caused by VirtualHostValidationError.Name: ["value length must be at least " '\x01' " bytes"]): name: "ingress_http"


[Design] Dialog system

Will address #135

I wonder if a dialog system is overkill. With the exception of the text input field, everything else could be implemented better as a node library. Is there a different way we could integrate text input?

This initially started because we wanted a text input field, so we could argue that.
There are at least 3 additional benefits to have a dialog system

no latency on input selection.
allows custom dialog UI per host app, or per engine integration
enables per engine optimizations that generic actors wouldn't

In reply to: 527662800 [](ancestors = 527662800)

Looks good to me


[Bug]: CVE issue with cucumber module

Module
Core
Testcontainers version
tip
Using the latest Testcontainers version?
Yes
Host OS
windows
Host Arch
x86
Docker version
windows

What happened?

Relevant log output
Provides transitive vulnerable dependency maven:com.google.guava:guava:25.0-jre
CVE-2020-8908 3.3 Incorrect Permission Assignment for Critical Resource vulnerability pending CVSS allocation

https://devhub.checkmarx.com/cve-details/CVE-2020-8908/?utm_source=jetbrains&utm_medium=referral&utm_campaign=idea

   implementation 'org.seleniumhq.selenium:selenium-remote-driver:3.141.59'
in testcontainers-java\examples\cucumber\build.gradle
Additional Information
No response

dependencies for selenium were upgraded https://github.com/testcontainers/testcontainers-java/commit/01bd9a0e1b9f0a493d1e8a38f336fe63d3b6f862


Clone Gdrive

This one not exporting native google docs files.
If you are looking for alternative https://talusoft.com/products/clonegdrive

Nice spam campaign: GitHub, Stack Overflow...
You could have at least verified that gdrive was indeed not exporting Google Docs!
Spoiler alert: it does!

Nice spam campaign: GitHub, Stack Overflow...
You could have at least verified that drive was indeed not exporting Google Docs!
Spoiler alert: it does!

If you have 100000 google docs or have greater than 15mb google docs or you want to clone more than 2 TB data you have to something smilar. it is not spam. Thanks.

This one not exporting native google docs files.

This is simply not true.
If you're looking to advertise a product, at least get your facts right.

How can I export 200mb of Google Slide or How can I export Draw?

How can I export more than 200mb Google Slide

I don't have any Google Slide this big to confirm if it works or not.
What issue do you encounter when you try to export such a slide using drive?

How can I export Drawings?

drive pull -force -export svg your-google-drawing
To be clear, I'm not saying your product is bad or that it is not better than drive, I just hate spam!
If you're looking to advertise a product, just don't post a 2-lines issue on GitHub.

Thank you for pinging the project @mehmetkut and for the self marketing :) I have no problem directing people to other alternatives if need be but really drive supports the above features and way even more.
Thank you @chevillet for standing up and spending time to answer this spam post.


filterPEM enhancements

Signed-off-by: smcavallo<EMAIL_ADDRESS>Problem Statement
There was some really nice support for managing PEMs in secrets added as part of these:

https://github.com/external-secrets/external-secrets/issues/358
https://github.com/external-secrets/external-secrets/pull/701
There's a very similar use case to the above, where instead of combining certificates into the full chain, that, given the full certificate chain, users may want to break out the server certificate from the intermediate certificates.
It would make sense to support handling pem files both ways - combining them (existing functionality) and splitting them (new functionality)

Related Issue
Fixes #...
Proposed Changes
This is really simple - code - given a PEM file with a certificate and the full chain, certificate chain order states that the server certificate must be first and the intermediates after.  This feature extracts the first certificate from the bundled PEM in the case of filterPEMChain to return only the server certificate, or returns only the intermediate/root certificates in the case of filterPEMServer
Note that I extended the filterPEM terminology but it was not the most intuitive to be named this way.
It might make sense for the methods to be called getCertificate or getIntermediateCertificate
Alternatively, the feature could instead be written in such a way that it simply returns the full list of certificates as an array and the end user can do what they please with the results inside the template.
Checklist

[X ] I have read the contribution guidelines
[X ] All commits are signed with git commit --signoff
[X ] My changes have reasonable test coverage
[X ] All tests pass with make test
[X ] I ensured my PR is ready for review with make reviewable

/ok-to-test sha=0b743d04de6b90c66a507053b7136d99de4c8784


Determine how much user has scrolled

Hi,
Determine how much user has scrolled the page in pixel i mean scrolled amount because i want to show "Scroll to Top" button in page and also if i click that button it should goes to top.
i written bellow code
var offset = 300;
$(window).scroll(function () {
if($(this).scrollTop() > offset) {
$('#scrollTop').show();
}
else {
$('#scrollTop').hide();
}
            });

but problem is im not getting $(this).scrollTop() value.
if i use default browser then i will get value but i use this scrollbar then above code is not working.
for reference find the screenshot

i  want to implement above button with your scrollbar. can u tell me how to do it.

Read docs again and you'll find the answer.


fix ci

Signed-off-by: hang.jiang<EMAIL_ADDRESS>
What type of PR is this?

/kind bug
What this PR does / why we need it:

fix ci bug when release new tag

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/lgtm


Improved "Preparing environment" step in main script flow.

The section was lacking console output, so end-user did not know what was going on during this step. Furthermore, if something failed, there was no visibility on what was exactly the failure.
The changes include:

Add a new prepare_environment() function to become more modular and extend it over time
Improve console output by informing about the tasks that are being performed during the preparation of the environment
Refactor and parallelize the copy of team's public ssh keys (extra), hopefully saving more time when deploying ~180 images simultaneously
Move hardcoded tmp file paths to default configuration, so they can be customized and referenced from other parts of the code
Add a new method to the CIVConfig class, to export CIV config items to env variables, so they can be easily referenced from other parts of the code

You can see an example of the console output here:

https://gitlab.com/redhat/services/products/image-builder/ci/cloud-image-val-ci/-/jobs/6578277145#L1925


Update spek license

Thank you for the contribution. It was merged directly as 3416ec41cdad983bfe90ff5c9be5cbad6149a112 to keep commit history cleaner. Your contribution is still credited to you.


Dashboard card stuck on "Loading"

Hi,
I'm on the latest HA version and the latest Fomuleone-card version (Thanks for updating).
My card is not loading all the time.

I have this problem in the browser Firefox and Edge. Both browsers are setup clearing cache on shutdown so it is not an old cache file that can cause the issue. Pressing F5 is sometimes helpfull, sometimes not.
Also in de HA app I have this problem.
Is there some way to debug this? Or is it an simple time-out from the source because I am all day playing in Home Assistant Dashboard?

Try ctrl+f5?

That doesn't work

That doesn't work

I needed to clear localstorage. But I thought that was because of I had the development version running. Do you know how to do that?

Browser inspections shows:

Oh wait. The country API is down again :(

Ah oké. But why the card does not load?
I thought the API pulled once from the source, then store the info locally and refresh (New pull from sourcce) that local info when chanced?

Oké, to technical for me I think Marco ;)
Thanks for the quick reaction and your work! Have a nice evening.


Passing vars/templates/data between git-included deployments

Command

[ ] check-image-updates
[ ] delete
[ ] deploy
[ ] diff
[ ] helm-pull
[ ] helm-update
[ ] list-images
[ ] list-targets
[ ] poke-images
[ ] prune
[ ] render
[ ] seal
[ ] validate
[ ] version

Who are you?
No response
What do you want to do?
I could not find any way to pass any data between git included deployments.
I tried multiple approaches:

Using variables from sub-deployments included via git -> Does not work. Maybe we could add smth like expose: true to expose vars to the parent deployment?
Using templates with onlyRender: true from sub-deployments included via git f.e. with load_template() -> I could not find a path to load any templates from sub-deployments. However this does work fine with include: instead of git:. The docs only mention that you cannot use templates from the parent deployment. Maybe https://github.com/kluctl/kluctl/pull/372 could help getting the path of git-included deployments?
Using ConfigMaps or Secrets with clusterConfigMap / clusterSecret variable sources -> does not work as noted in the docs.

I included barrier: true between all deployment items and added waitReadiness: true to all kustomize deployments.
Am i missing something or is there currently no way to pass any data?
Why do you need that?
There are many use cases where passing data between deployments is necessary.

@senbax-admin Sorry for the late response, I somehow missed this issue. Is this still relevant?
Generally, all git included sub-deployment inherit the templating context from the parent, meaning that all variables should be available. Files can currently not be shared between projects, as I implement some strict protections to avoid leaving a git project.


Adds Advanced SMES, an SMES with higher capacity for mapping

About the PR
Adds an Advanced SMES, an SMES with a capacity of 15 MJ (15,000,000 J) intended for mapping. For comparison, the basic SMES has a base capacity of 8 MJ.
This is intended to be used in station battery storage banks and provides more agency for mappers to adjust how their station performs power-wise and for easier future balancing.
If this PR gets merged, I will create a megaissue addressing the current engineering roundflow power issues and how it should be addressed according to the (legacy, but still included, and very much still relevant in my opinion) engineering design document.
I didn't buff base SMESes as I wanted mappers to have more agency.
Why / Balance
Right now, engineering has a horrible power roundflow problem. Engineering power is intended to follow this pattern:

The station is running on battery power at the start of the shift. This will deplete rapidly until engineers setup an AME to help supplement the batteries. Station batteries should reach around 30% capacity at the 5 minute mark, where the AME is started.
Solars can be setup to further reduce this drain, with them expected to be setup at the 10 minute mark. At this time, batteries should be drained to around 20%. Solars should further offset and supplement the batteries, but there is still a little bit of power drain that warrants a greater power source.
Now that the batteries are not running out in 2 minutes, engineering can dedicate enough time to setting up a proper power source, like the Tesla, Singulo, or TEG. This power source should be setup at the 20 minute mark. Once this is done, engineering will finally be power positive, and can turn off the AME.

Below is a graph from the design document showing the intended flow:

The RED line is Meta station. It doesn't even last 3 minutes, 30 seconds before the station starts to brown out. Other large stations are worse than this. This is not good at all, and promotes a lot of problems:

Engineers don't have enough time to teach new TAs engines, they are pushed to rush setup of these engines. I have had to turn away TAs that want to learn because taking the moment to explain engines may lead to the station running out of power.
Engineers get yelled at constantly by people with their departments in brownout because batteries with AME assistance last literally 7 minutes. This often leads to them cryoing and never wanting to play engineering.
This little buffer time is horrible for lowpop engineering and engineering with only TAs.

This change is intended to give mappers a higher capacity SMES to help bridge that gap to the AME turning on, without having to spam 12 SMESes.
Technical details
Added and adjusted relevant things in YAML.
Media

Requirements

[x] I have read and am following the Pull Request and Changelog Guidelines.
[x] I have added media to this PR or it does not require an ingame showcase.

Changelog
:cl:

add: New Advanced SMES, an SMES with a 15 MJ capacity. Board is available roundstart to print at an autolathe.

I would add some red or orange stripes to the top and bottom rims.

I think this would be good to distinguish it, but I am horrible at spriting.

Does the capacity of the power cell used in substation/SMES construction affect its capacity?

Nope. Component-based upgrades are not desired, explicit machine upgrades should be used instead.

How is the graph affected when you turn on the roundstart plasma and uranium PACMANs?

I've discussed the usage of generators to help bridge power, and I'll mirror my thoughts about it below:

The fact that I should have to pry up a floor tile and connect a generator to a grid manually instead of using a station's purpose-built support generator because it sucks is not good game design.
If mappers want players to use generators to help bridge power and extend the lifetime of the SMES banks, it should be a clearly, intuitively obvious, mapped feature. See Fland for an excellent example and see Cog for a horrible example.

Should we buff substation capacities instead so departments get a longer blackout warning? (Essentially when light flickers and the APCs turn red to show they're losing power.)

I'm partially against giving powernet transformers a larger internal battery for the sake of a band-aid solution to a larger core problem. I think it's good to have this PR's changes reflected in the SMES percentages because it's an easier thing to balance around. However, it could be a good change when things like substation/APC having breakers and APC equipment networks (toggling breakers to equipment, doors, lighting separately) are a thing in the future.

I agree with the point they should already be anchored or positioned on them roundstart like on Cog or Fland. Thus I'm asking what the graph will look like when every map does it.

The underlying issue is that the batteries don't last long enough to support the station's SMES array until the 5 minute mark, where engineers have presumed to have setup the AME and other low-tier sources like PACMANs and the AME.
The solution is mappers taking advantage of dual-core AMEs, something that should be mapped for large stations, as some stations need more power to help assist the batteries than others.
To answer your question, I turned on the AME, PACMAN and SUPERPACMAN at the 5 minute mark (when the SMESes had already ran out for about 2 minutes, but the station was still running off of substation and APC battery power), which brought the load down to 80 kW. Assuming that engineers setup solars by the 10 minute mark, engineering would actually be basically power-neutral, giving them plenty of time to setup an engine (assuming they do it in the timeframe the generators will last).
With my PR, I did testing on Cog, the notorious map where engineers notoriously run into problems. The batteries got to around 38% at the five minute mark, and with a 2-core AME assisting the batteries (compared to the current 1-core), it got to the 10 minute mark at 13%, where solars "kicked in". Once the solars had balanced the load, battery usage was down to around 50-60 kW. The SMESes then fully depleted at the 16 minute mark. A PACMAN generator (which is mapped intuitively) setup alongside the AME would help greatly.

In reality, the AME is setup a bit sooner, and solars are set up piecewise, helping to offset the grid much sooner.

Does the capacity of the power cell used in substation/SMES construction affect its capacity?

Cell substation/SMES upgrades got axed while ago in substation resprite PR. Which was halfish year ago or so.

Does the capacity of the power cell used in substation/SMES construction affect its capacity?

Cell substation/SMES upgrades got axed while ago in substation resprite PR. Which was halfish year ago or so.

I still have issues with the removal of some part upgrades, like those, to this day. They weren’t all perfect, but especially for substations and SMES it just makes sense

I still have issues with the removal of some part upgrades, like those, to this day. They weren’t all perfect, but especially for substations and SMES it just makes sense

I agree, yeah. For stuff like substations, cell upgrades do indeed make sense, however, they aren't explicit.

For any maintainer that reviews this, I would also like #32825 looked at as well, as this ties into my larger goals of mappers being able to use multi-core AMEs to help achieve the roundflow SMES power levels as outlined in the current engineering design document.

I intend to make some changes soon:

Add a sprite to the advanced SMES to fully distinguish it between the regular variant.
Make the power capacity actually double because it uses double the materials. One MJ doesn't reflect to a huge change in time anyways, believe it or not.
Move the advanced SMES under the advanced cells T2 research because it makes much more sense there. Undesirable to have it available roundstart.

I'm finished with my changes. This PR now requires #33808 or else the sprites will look weird. Thanks AugustSun for the sprites.

You can just overcharge SMES'es, so they will be charged for 400% roundstart, so no power outage for 30 minutes for crew

That would require me to code. I could ask a fork if it's okay to implement their solution.
Besides that, I think it's good to give engineering an explicit upgradeable SMES for those that want to bother. Maybe engineering might go around the station and start upgrading them? It's just nice to have something mechanical, "overcharging" feels weird.

Lmfao yeah thanks

new sprites once again, thanksies AugustSun
everything seems to work on the sprites side with the lights
I can also confirm that PR #33808 works and they have proper open sprites.

I think the idea is sound (always love a good graph) and  evening out the roundstart power is something we're interested in. I've made a discussion thread to check with maintainers who are better at mapping/Engineering than me, and the sprite will need Art Lead approval.

I think the idea is sound (always love a good graph) and  evening out the roundstart power is something we're interested in. I've made a discussion thread to check with maintainers who are better at mapping/Engineering than me, and the sprite will need Art Lead approval.

Excellent, let me know how it goes. If it's possible, I'd like PR #32825 included in that discussion as it ties into my larger goal with standardizing station power runtimes.

Thank you for your work and your detailed analysis. It seems that you concluded that the core issue is mapping -- mappers aren't putting in enough round-start energy storage to make the red curve align with the blue one.
So while the proposed solution (adding a bigger mappable SMES) gives mappers more flexibility, ultimately it doesn't solve the problem of testing power draw on map start. Ultimately, even without this change, mappers can still map a larger round-start SMES bank, no?

Thank you for your work and your detailed analysis. It seems that you concluded that the core issue is mapping -- mappers aren't putting in enough round-start energy storage to make the red curve align with the blue one.
So while the proposed solution (adding a bigger mappable SMES) gives mappers more flexibility, ultimately it doesn't solve the problem of testing power draw on map start. Ultimately, even without this change, mappers can still map a larger round-start SMES bank, no?

Questioning this PR, I can see your concerns with why it exists in the first place. You are correct that mappers can simply map more roundstart SMES banks in order to compensate for draw, and that this PR isn't really needed. The issue I saw (and what this PR is for) is that using regular 8MJ SMESes leads to a very large battery room for the station. With the Advanced SMESes, the density would be doubled, allowing for a simple drop-in replacement with little requirement for re-mapping SMES rooms on most maps.
For solving the problem of testing power draw on round start, I believe there is a test for station power over time, #29698. However, it needs to be adapted to follow the intended graph. Right now it simply checks for a 10-minute time on batteries alone, which doesn't match with engineering's intended gameplay.
There is a second component to the power issue, which is that the post-AME power graph's slope can't really be modified right now for maps that need it. The AME's current power curve causes core counts over 2 to produce less power, which means that for some large maps, the 20% at 20 minutes target can't be made.
If this PR and the AME PR (#32825) are merged, I'll go ahead and re-tune all maps to conform to the graph.

Intuitive simulation is one of our core design pillars, and I think it makes a lot of intuitive sense that a large station should also be served by a large SMES bank.
That said, I also think that it is useful to give mappers more flexibility, and this advanced SMES is justified as being more "advanced" and also only represents a modest 2× increase in capacity. So I think it's fine.
I do want to emphasize that it is important for mappers to check their round start power draw, because I can see this problem either not getting solved, or small stations getting over-corrected.
Thanks again for your work.

To any maintainer who merges this, after the internal discussions with the engineering workgroup about this PR:
This PR's greater goal is to standardize the power roundflow. A huge component that enables this is PR #32825, which rebalances the AME curve to allow core counts higher than 2, with a logarithmic loss. This allows the power curve to be easily fitted for larger stations.
PR #32825 should be merged alongside this PR.

Emisse has given approval on Discord during the Maintainer Discussion, and seeing as they're the head mapper that means this is Good To Merge+.


[Feature]: There should be metric like m, cm for 2d and 3d shapes

Description
There should be a feature in which we can calculate the area or the perimeter by adding unit like metre , centrimetre etc so that the user can get the value according to their need
Screenshots

Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Proceed @upsaurav12

Hi @Rakesh9100 Thank you for assigning me this issue. I want to know that the level tag will added after raising PR??

Pls provide your PR @upsaurav12
Label will be added once the PR is successfully merged!

Provide your PR else you will be unassigned today @upsaurav12

i am sorry i was busy somewhere else i will surely give you PR ASAP


SqlServiceAccount: Added integration tests (plus other changes)

Pull Request (PR) description

Changes to SqlServerDsc

Added a README.md under Tests\Integration to help contributors to write
integration tests.

Changes to SqlServiceAccount

Added a read-only parameter ServiceAccountName so correctly returns the
service account name as a string (issue #982)
Added integration tests (issue #980).

Changes to SqlSetup

Cleaned up integration tests.
Added integration tests for installing a default instance of Database Engine.

This Pull Request (PR) fixes the following issues:
Fixes #980
Fixes #982
Task list:

[x] Change details added to Unreleased section of CHANGELOG.md?
[x] Added/updated documentation, comment-based help and descriptions in .schema.mof files where appropriate?
[ ] Examples appropriately updated?
[x] New/changed code adheres to Style Guidelines?
[x] Unit and (optional) Integration tests created/updated where possible?

This change is

Codecov Report

Merging #987 into dev will increase coverage by <1%.
The diff coverage is n/a.

@@         Coverage Diff          @@
##            dev   #987    +/-   ##
====================================
+ Coverage    96%    96%   +<1%
====================================
  Files        32     32
  Lines      3537   3833   +296
====================================
+ Hits       3417   3713   +296
  Misses      120    120


2 mesh networks (GS and Edge) support added

2 mesh networks (GS and Edge) support added.
Default mesh enabled.
Settings are based on manifest-defined environment variables.
### Google IoT 2-mesh config example
initial-wifi:
    edge:
        api_version: 2
        ssid: default-edge
        key: "foobar"
        enc: wep
        ap_mac: "00:11:22:33:44:55"
        country: cn
        frequency: "5180"
        ip: <IP_ADDRESS>
        subnet: <IP_ADDRESS>
        tx_power: "30"
        mode: mesh
    gs:
        api_version: 2
        ssid: default-gs
        key: "foobar"
        enc: wep
        ap_mac: "00:11:22:33:44:55"
        country: cn
        frequency: "5745"
        ip: <IP_ADDRESS>
        subnet: <IP_ADDRESS>
        tx_power: "30"
        mode: mesh

Any specific reason to have default CN country code and major concern is WEP and it should not be used as Mika commented previously.
All modes/features should be based on top of WPA3 security at bare minimum unless those features are experimental and DO_NOT_MERGE category,

@govindsi  @sergei-petroff

Any specific reason to have default CN country code and major concern is WEP and it should not be used as Mika commented previously. All modes/features should be based on top of WPA3 security at bare minimum unless those features are experimental and DO_NOT_MERGE category,

enc: WEP is not used for anything.  WPA3 SAE is used with all supported Wi-Fi cards.  CN as for the country code is selected for testing purposes (txpower, available channels).

@govindsi @joenpera
Google IoT 2-mesh config is just an example based on default settings provided to newly installed drone.
Real Default Mesh settings are defined in the manifest.json file along with other drone role and config properties.
Thank you.

@govindsi @joenpera
I should make an additional review of this PR by myself.
Please don't merge for now.

Config updated after the workshop with Solita team
Google IoT mesh config, GS example
initial-wifi:
api_version: 2
ssid: gold
key: "1234567890"
ap_mac: "00:11:22:33:44:55"
country: cn
frequency: "5805"
ip: <IP_ADDRESS>
subnet: <IP_ADDRESS>
tx_power: "30"
mode: mesh
edge:
api_version: 2
ssid: default_edge_mesh
key: "1234567890"
ap_mac: "00:11:22:33:44:66"
country: cn
frequency: "5180"
ip: <IP_ADDRESS>
subnet: <IP_ADDRESS>
tx_power: "30"
mode: mesh
gs:
api_version: 2
ssid: default_gs_mesh
key: "1234567890"
ap_mac: "00:11:22:33:44:55"
country: cn
frequency: "5745"
ip: <IP_ADDRESS>
subnet: <IP_ADDRESS>
tx_power: "30"
mode: mesh


[BUG] Is Dashboard Querying the Correct Database?

Describe the bug
Hello, just installed Varken and your excellent dashboard. Varken starts without error and your Varken.py is happily writing to Influx DB. The only widget showing data on the dashboard is CPU though. When I log in to influx, I see these databases:

show databases
name: databases
name

_internal
telegraf
varken
The Movies dashboard widget is querying:
"executedQueryString": "SELECT last(\"total\") FROM \"Tautulli\" WHERE (\"type\" = 'library_stats' AND \"section_name\" =~ /^Movies$/) AND time >= now() - 1d"

2021-01-04 11:14:52 : DEBUG : dbmanager : Writing Data to InfluxDB [{'measurement': 'Tautulli', 'tags': {'type': 'Session', 'session_id': 'jz8m72r0rwd274ew4k1lp7cx', 'friendly_name': 'dennis_faucher', 'username': 'dennis_faucher', 'title': 'Mad Max 2 the Road Warrior', 'product': 'Plex Web', 'platform': 'Chrome', 'product_version': '4.49.2', 'quality': '720p', 'video_decision': 'Direct Play', 'transcode_decision': 'Direct Play', 'transcode_hw_decoding': 0, 'transcode_hw_encoding': 0, 'media_type': 'Movie', 'audio_codec': 'AAC', 'audio_profile': 'LC', 'stream_audio_codec': 'AAC', 'quality_profile': 'Original', 'progress_percent': '3', 'region_code': 'MA', 'location': 'Sudbury', 'full_location': 'Massachusetts - Sudbury', 'latitude': 42.3822, 'longitude': -71.4275, 'player_state': 1, 'device_type': 'Chrome', 'relayed': 0, 'secure': 1, 'server': 1}, 'time': '2021-01-04T11:14:52.655856-05:00', 'fields': {'hash': 'db41fd8047cf234198623904578bf940'}}, {'measurement': 'Tautulli', 'tags': {'type': 'current_stream_stats', 'server': 1}, 'time': '2021-01-04T11:14:52.655856-05:00', 'fields': {'stream_count': 1, 'total_bandwidth': 1118, 'wan_bandwidth': 0, 'lan_bandwidth': 1118, 'transcode_streams': 0, 'direct_play_streams': 1, 'direct_streams': 0}}]
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Install Dashboard
Dashboard Empty
...
...

Expected behavior
Install dashboard
Dashboard populates
Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

OS: [e.g. Ubuntu 18.04.1 or Docker:Tag] Raspberry Pi OS
Version [e.g. v1.1]

Additional context
Add any other context about the problem here.
Thank you

Update: if I change my Grafana datasource from "telegraf" to "varken" the dashboard works, but that breaks my other dashboards.

Update: if I change my Grafana datasource from "telegraf" to "varken" the dashboard works, but that breaks my other dashboards.

:wave: @DennisFaucher, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please use our support channels to get help with Varken!

Discord
Discord Quick Access

:wave: @DennisFaucher, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please use our support channels to get help with Varken!

Discord
Discord Quick Access

Thanks. Found the support channel and received the support I needed to create a new Grafana data source with database varken. Closing.

Thanks. Found the support channel and received the support I needed to create a new Grafana data source with database varken. Closing.


Display Headings - add variable and breakpoints

Add breakpoint mappings for display-x
Use $display-headings map to allow for extending like $theme-colors

Thanks, but I don't see much value in having a nested Sass map for these right now. I agree they should be responsive, but not in the sense that we have modifiers for each grid breakpoint—more so that they each adapt to the relative viewport size.


Upgrade to latest version of arkworks

Superseded by https://github.com/MinaProtocol/mina/issues/14970.


Resolving External Screen Overlapping Issue

Introduction
Many users have encountered an overlapping issue when using an external screen with the simple-bar. This tutorial aims to guide you through the steps to resolve this issue by modifying the .yabairc  configuration file.
Step-by-Step Guide

Open the .yabairc Configuration File
Navigate to your .yabairc file, which is usually located in your home directory.

Add the Configuration Line
Add the following line to your .yabairc file to create a void space at the top of all spaces, which can accommodate a bar (or other elements, but in this case, it's for the bar):

yabai -m config external_bar all:28:0

Note: The value 28 in 28:0 represents the number of pixels dedicated to the space. You can modify this value according to your preference.

Save Your File

After adding the line, save your .yabairc file to apply the changes.

Restart the Configuration

Restart the configuration to apply the new settings and check if the issue has been resolved. You can do this by using the following command in your terminal:
yabai --restart-service

Yabai Documentation Excerpt
Here is an excerpt from the yabai documentation that further explains the external_bar configuration:
external_bar [<main|all|off>:<top_padding>:<bottom_padding>]

Specify top and bottom padding for a potential custom bar that you may be running.
- main: Apply the given padding only to spaces located on the main display.
- all: Apply the given padding to all spaces regardless of their display.
- off: Do not apply any special padding.

I'd like to move this piece of information in the documentation (where I moved everything else). Is that okay for you?

I moved this here: https://www.jeantinland.com/en/toolbox/simple-bar/documentation/resolving-external-screen-overlapping-issue/.
I'm closing this, feel free to update this guide and notify me if necessary, thank you again :)

Not sure right place to ask. But does this requires SIP to be disabled? I have follow the docs but the app on External Screen got Overlapped.


Pets Images Classification

ML-Crate Repository (Proposing new issue)
:red_circle: Project Title : Pets Images Classification
:red_circle: Aim : Create a machine learning model with highest accuracy which can predict the images of the pets.
:red_circle: Dataset : https://public.roboflow.com/object-detection/oxford-pets
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.
Hello, ML-Crate contributors, this issue is only for the contribution purposes and allocated only to the participants of SWOC 2.0 Open Source Program and JWOC '22 Open Source Program.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.
This issue is only for 'SWOC' and 'JWOC' contributors of 'ML-Crate' project.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
GitHub Profile Link :
Participant ID :
Approach for this Project :
What is your participant role?

[ ] SWOC 2.0 Participant.
[ ] JWOC 2022 Participant.
[ ] Contributor

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Issue assigned to you @yagyesh-bobde


Add Send Operation

This aims to add support of Send Operation to Leshan.
See LWM2M specification for more details :

core§6.4.6-Send-Operation
transport§6.4.5-Infomation-Reporting-Interface

The API look like this :
Client Side:
// send data
SendResponse r = client.sendData (server,
                                  ContentFormat.SENML_JSON,
                                  Arrays.asList("/3/0/1", "/3/0/2"),
                                  timeoutInMs);

Server Side:
// listen for new data
server.getSendService().addListener(new SendListener() {
  @Override
  public void dataReceived(Registration registration, Map<LwM2mPath, LwM2mNode> data, SendRequest request) {
      System.out.println(data);
  }
});

List of concerns or potential improvements :

at client side, add more low level function allowing to send SendRequest directly.
at server side, current Map<LwM2mPath, LwM2mNode> data is not so good. LwM2mPath is largely used internally but generally not so exposed. (we have same problem with WriteComposite)
at server side, if an error occurred when handling SendRequest, this is not reported to application layer, it should maybe be reported in SendListener.
at server side, in addition of listener maybe we should add a kind of DataCollector which could be able to report the data handling state. This could be useful to let device know when data was not collected/handled correctly.

I changed the Send API at server side like this :
// listen for new data
server.getSendService().addListener(new SendListener() {
  @Override
  public void dataReceived(Registration registration, Map<String, LwM2mNode> data, SendRequest request) {
      System.out.println(data);
  }
});

(data attribute changed from Map<LwM2mPath, LwM2mNode> to  Map<String, LwM2mNode> data)

Hi @sbernard31 ,
I have a question for you, our team need to build coap server , can we theoretically reuse Leshan server for it , so our dmserver will serve both Lwm2m and Coap clients?

Hi I can not see how this is related to this PR ?
Please create a new issue for this kind of question.
(after you created the issue I will delete your comment above :point_up:  and this one)

Hi
Sorry for posting it here
https://github.com/eclipse/leshan/issues/990 I created issue for this
Please delete above comment


Invite a user to conversation like programmable Chat

Hello is there any way to invite a user in conversation before creating one to one conversation between two users, as we had in programmable Chat I am unable to find anything in dos so I am creating an issue here?

Hi, no, invites are currently not supported by the Conversations product.
If you could state your intended use case I might suggest a workaround and will also raise awareness to the team about why this feature is needed.

My intended case is that the user first invites another user when he accepts then he can send the message. This is the case let me know how can we deal with this case without having invite resources in user.

Conversations are more backend-heavy than the Chat product before it. It is mostly related to the fact that you operate with more different access channels (SMS, WhatsApp, etc).
The invites are quite hard to implement for SMS for example - how would you see the invite without joining the conversation first?
If you are building your product for chat users only, you could use conversations as additional signalling tools: for example, create the "userXXX_invites" conversation and send messages there whenever user is invited to a channel.
This is how it could look:
Conversation: "userXXX_invites"
Participants: userXXX (only that user)
Your backend would send a message (in pseudo-json) "invite: { from: userYYY, toConversation: CHzzzzzz }"
when user recieves this the app will:

parse the message
advance the read horizon on this conversation to mark the invite as processed
show the invite UI in the app
if the user accepts or rejects the invite, the app will write a response in this conversation like "inviteResponse: { from: userYYY, toConversation: CHzzzzz, resolution: accepted }"

The backend per-message webhook will handle this message and ADD userXXX to conversation with userYYY

Additional bonus here is that you could for example add an invitation message: "invite: { to: CHzzz, message: "Hi Please join my conversation" } and it's a lot more flexible.

Could you please send me doc url
On Fri, 4 Mar 2022, 2:08 pm Berkus Decker, @.***> wrote:

Additional bonus here is that you could for example add an invitation
message: "invite: { to: CHzzz, message: "Hi Please join my conversation" }
and it's a lot more flexible.
—
Reply to this email directly, view it on GitHub
https://github.com/twilio/twilio-conversations-demo-kotlin/issues/34#issuecomment-1058975367,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6J5M7VMEZ3SDHNULK44R3U6HHKDANCNFSM5P42FPSA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Which doc?

No response, closing.


Release as a default type?

In my company we use this package in a few projects. We always end up hardcoding the types because we use release for commits that upgrade the package version or commits that produce a new shrinkwrap etc..
How do you feel about adding release as a default type?

Hi @naxhh, this project defaults to conventional-commit-types. You might file an issue there, but I'm pretty sure that they'll probably want to stick to the standard. You could fork it and use your fork instead. See the docs on types :)
Good luck, and thanks :)

Or you can specify the name of a module that exports types according to the conventional-commit-types spec, e.g. "types": "conventional-commit-types".

I didn't saw this when reviewing the readme. that solves my issue.
Thanks a lot for your time

Sure thing!


PLT-8028: remove initial rollback

From my discussion with @berewt:
https://github.com/input-output-hk/marconi/pull/180 introduces the following indexing event when processing a rollback. This ends up triggering https://github.com/input-output-hk/marconi/blob/3f5750d9ac0451618fa4893731a5be3196fed0ed/marconi-core/src/Marconi/Core/Preprocessor/Resume.hs#L86. The solution is to remove the "artificial" rollback event that marconi emits, which is no longer necessary for synchronizing indexers.
Note: the ResumeStarts state, which was introduced to handle rollbacks at the start of the resuming procedure, could not be removed because there is an additional initial rollback which comes from somewhere external to marconi.

Pre-submit checklist:

Branch

[ ] Tests are provided (if possible)
[ ] Commit sequence broadly makes sense and have useful messages
[ ] Important changes are reflected in changelog.d of the affected packages
[ ] Relevant tickets are mentioned in commit messages

PR

[ ] (For external contributions) Corresponding issue exists and is linked in the description
[ ] Targeting main unless this is a cherry-pick backport
[ ] Self-reviewed the diff
[ ] Useful pull request description
[ ] If relevant, reference the ADR in the PR and reference the PR in the ADR
[ ] Reviewer requested

Should we open a spike to investigate the why and decide whether we remove or keep it?

Looking at the code... I think that If we get 2 rollbacks, that means there is an initial one we emit when the intersection is found, and the second is an actual rollback from the node that tells the client to go back some previous state.


Can't change font size

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: Windows 10 64bit
Hyper.app version: 2.0.0
Link of a Gist with the contents of your .hyper.js: https://gist.github.com/ParkSB/2b9625da574818f24322a62452342156
Relevant information from devtools (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere): N/A
The issue is reproducible in vanilla Hyper.app: Is Vanilla.

Issue

I tried to change a font size by modifying a value of font-size in hyper.js file, but the font size doesn't change. Is it a bug or there is another way to change font size?

It was an issue of theme plugin 'verminal'. The font size works well after delete verminal.

You can apply the font size to overide for verminal.
See the link below:
https://github.com/zeit/hyper/issues/3343#issuecomment-451235240

Thank you for this information, you helped me.


when use @vue/compat in vue3 project,  use emit('update:modelValue', val), v-model not effect

Vue version
3.3.4
Link to minimal reproduction
https://localhost:8089/
Steps to reproduce
floow the npm markdown,
when use @vue/compat in vue3 project,
child use emit('update:modelValue', val),
parent  v-model not effect.
when commented  @vue/compat code,
it works
What is expected?
can you give me some suggestions .both use @vue/compat and let it works
What is actually happening?
In parent ,
v-model not effect
System Info
No response
Any additional comments?
No response

Please provide a minimal runnable reproduction.

If you are running the compat build in Vue 2 mode, then the parent that is using v-model on your component will listen for ìnput, not update:modelValue`.
You would have to deactivate the COMPONENT_V_MODEL compat flag in your app, or in that parent component's compat config.
https://v3-migration.vuejs.org/migration-build.html#compat-configuration


feat(typography): initail typography components

Heading
Link
Image
Para

Props like anythingClass isn't needed, class attrubute on component and :class attribute in components will be merged
Also for class merging need to use https://github.com/dcastil/tailwind-merge

<Link class="text-bg-500 underline">This is a link</Link>

Do you mean using class attribute directly like this instead of  something like link-class

<Link class="text-bg-500 underline">This is a link</Link>

Do you mean using class attribute directly like this instead of something like link-class

Yes

Props like anythingClass isn't needed, class attrubute on component and :class attribute in components will be merged Also for class merging need to use https://github.com/dcastil/tailwind-merge

It works for all typography other than image, if we use class on Img component it applies styles on the outer container, so we have to receive the prop inside Img component to use it on the image tag like this,

You're right for Img component we need to have a prop imgClass

Closed this one due to conflicts issues


Return err if we got err on parseForm

Signed-off-by: Qiang Huang<EMAIL_ADDRESS>

were there any specific reasons why these parseForm calls were just returning nil instead of err? or were these just bugs? (stalkering you today @hqhq :smile: )

I don't see any, it doesn't make any sense, does it? Seems we both active at a quiet time :)

I seem to recall that we had a discussion about this during the "remove engine" work, and while people thought returning errors due to bad input (parsing errors) was correct, it would break backwards compatibility, so the old behavior was left.
Changing behavior for valid input would be bad, but becoming more correct by flagging bad input (while might break some people) is probably overall a good thing.
But @LK4D4 do you remember those discussions?  I might be misremembering....

Have no idea :/
+1 to change though

LGTM

LGTM


Bump min SDK to Dart 2.18.0 / Flutter 3.3.0 & fix CI

Bump min SDK to Dart 2.18.0 / Flutter 3.3.0 where we can use a newer melos version (3.4.0) that allows simplified usage and supports pubspec_overrides.yaml files
revert workflow event back to pull_request & disable coverage comment for now - this needs to be handled differently
remove unnecessary exclusive parameter
adapt download test to use httpbun

New Pull Request Checklist

[ ] I have read the Documentation
[ ] I have searched for a similar pull request in the project and found none
[ ] I have updated this branch with the latest main branch to avoid conflicts (via merge from master or rebase)
[ ] I have added the required tests to prove the fix/feature I'm adding
[ ] I have updated the documentation (if necessary)
[ ] I have run the tests without failures
[x] I have updated the CHANGELOG.md in the corresponding package

Additional context and info (if any)

Well this doesn't work

Looks like something is cached

Ok, so since we switched to pull_request_target a lot of the repository content is actually used from main. Probably when we use path or git dependencies.

Ok, so since we switched to pull_request_target a lot of the repository content is actually used from main. Probably when we use path or git dependencies.

Ah that sounds fair. Maybe GITHUB.ref would help?

So after reverting to pull_request we still have 2 issues.

The download test is taking too long (longer than 2 minutes)
The melos version on min SDK (or the Dart version itself) doesn't seem to support the pubspec overrides

Dart 2.18.0 was released on Aug 30, 2022 - so I think this is fine, we should probably publish this as a minor version.

The build still shows as failure but this is due to the old pull_request_target usage.

@AlexV525 I think this is good to go, the coverage comment should start to work again once the new workflow is on the main branch. Hopefully it also has correct coverage values after this. This was likely caused by the same problem.

I'm on a holiday and will be AFK for 3 days. I'm considering a couple things:

I'd like to fix #2173 first so we can get as much fixes as we could before we bump SDK requirements.
I'd also like if we split the exclusive fix as a single request so we can easily manage the SDK upgrade request.
We might also stated somewhere that we can at least support SDKs that are released within 1 year in order to provide a solid service.

Have a nice holiday!
I understand your concerns but as it stands now, the min Dart SDK 2.15.0 does not support pubspec_overrides.yaml.
So all the testing setup we did recently does not actually work for the min SDK since we removed the path dependencies to the test project.
All changes in this PR are interwoven and atomically won't solve the problems.
If we change the exclusive problem, there would still be wrong tests pointing to the main branch in the next PR. It might show a success while the actual code does not work, just how the exclusive problem happened in the first place.
Dart 2.15 ist almost 2.5 years old, we need to get rid of it so we can move forward with the limited time we all have to spare for OS projects. If someone is still using such an old version and having actual problems due to specific bugs, then they can afford to pay someone else to solve the problem in a fork or donate to dio and request a custom handmade release.

Yes I agree with all changes, those concerns are something I think we might do when applying changes. As our regular principle about the maintaining, we can provide a great guide or message to allow users to have a good chance to stand along with our opinions.

I've added the compatibility policy doc to indicate our general support and exceptions.

Nice, I would go with ~1.5 years instead of 2 years.
We have Dart 3.0.0 on the 6.0.0 branch which is less than 1 year ago. We might be able to go back down to 2.19.0 and then we could release this around mid 2024.

Nice, I would go with ~1.5 years instead of 2 years.

Yeah it's a general idea, so it depends, which means you could always do so if you have a proper reason.

We have Dart 3.0.0 on the 6.0.0 branch which is less than 1 year ago. We might be able to go back down to 2.19.0 and then we could release this around mid 2024.

Sounds good

@ueman Do you have any input about this request and relevant policies?


The configuration-window has no CANCEL-SAVE-buttons anymore

Hey,
please take a look:

Regards,
Vlad

Hi Vlad,
thanks a lot for reporting this. Unfortunately, life is too short to understand Java layout managers. In this case, this was caused by the long rule description. Will be fixed with the next release!
Kind regards,
Jörg-Michael

:-D
Thanks JM!

Hi Vlad,
thanks again for reporting this issue – this should now be fixed with version 1.11.1, which was just released!
Kind regards,
Jörg-Michael


Add getting-started-java repo to releasing docs

I also updated the doc to mention the Bookshelf app needs to be updated.

Coverage remained the same at 85.29% when pulling a51c19f00e58b3d19e2451e128d90d0bec04818a on ajkannan:update-releasing-docs into 29b1ea56a18978e5fb93b28ea71955d4f356047c on GoogleCloudPlatform:master.

LGTM

Coverage remained the same at 85.29% when pulling c6eb5e794ab4478800cbd9fc4c49e2babd651313 on ajkannan:update-releasing-docs into 29b1ea56a18978e5fb93b28ea71955d4f356047c on GoogleCloudPlatform:master.


[Proposal]: Modular core APIs

This idea is in a very early stage, please contribute by leaving questions and ideas!

Is your feature request related to a problem? Please describe.
The backend currently has two different ways of exposing ApIs to the frontend: Commands (and Plugins) as well as the core APIs. Commands are very modular while the core APIs are not.
Describe the solution you'd like
Modularizing the core api using a similar system to #2959, inspired by deno's extensions.
So a tauri app could look like this:
let plugins = vec![
   tauri::api::fs::init(),
   tauri::api::path::init()
];

tauri::Builder::default()
   .plugins(plugins)
   .build(tauri::generate_context!())
   .expect("error while building tauri application");

Why?:

In-code configuration.
When reading the code it's immediately obvious what APIs are available to the frontend.
The current allowlist system split's feature configuration between the app, the Cargo.toml file and the tauri.conf.json file.
There is also no opportunity to add comments in the tauri.conf.json file, where dev could explain why an API is enabled.
No feature flags.
Tauri apps would be as slim as possible without the copious amounts of feature flags we employ right now. (Of course more involved features like systray would still use them on top)
This makes the cli waay simpler and less error prone.
Capabilities.
The init function is a very natural way to pass capabilities to APIs enabling capability oriented design.
A clear path for new APIs.
@amrbashir pioneered this with the vibrancy plugin. Similar to rust itself, we could develop new APIs in separately versioned plugins, that can be iterated upon more easily. Once they reached sufficient stability can be merged into the core. This is maybe the most compelling reason IMO.
A clear path for old APIs.
Core APIs can be deprecated and still be accessible to users who didn't upgrade yet, while not taking up space for users who did.  (I could see withGlobalTauri going this route for example. It would still be there for users who need it, but would never end up in the binary for users who don't)

Open Questions

Would the name plugin still be applicable to this new system?
How do users tell the tauri::Builder about plugins?
Does tauri::Builder::default() come with default plugins?
Are there core plugins that will not be modular (i.e. enabled by default)?

There's one downside going with this approach and removing the allowlist entirely: people need to touch the Rust code to enable APIs, and a lot of users are scared of it.

But turning the APIs into plugins is something I have in mind for quite some time, specially since it's the only way to have an allowlist when we have bindings (each core plugin could have its own binding, then e.g. a Deno user can install each plugin individually).

There's one downside going with this approach and removing the allowlist entirely: people need to touch the Rust code to enable APIs, and a lot of users are scared of it.

can't the allowlist call these functions ? like have a top-level tauri::include_apis!() macro ? kinda like how windows-rs used to a similar macro to generate the apis

There's one downside going with this approach and removing the allowlist entirely: people need to touch the Rust code to enable APIs, and a lot of users are scared of it.

Do you think it is that bad? Adding plugins to a vec doesn't touch lifetimes or any other part of rust that people find scary 🤔
But I get the concern, maybe a macro could help here, yes!

If there are no feature flags, will Rust skip the unused dependencies when compiling?
Definitely would like to specify the allowlist in code, and avoid tauri writing feature flags to Cargo.toml

If there are no feature flags, will Rust skip the unused dependencies when compiling?
Yes, of course 😉. Rust binaries are large, but without dead code elimination and other optimizations the size would be measured in gigabytes.
I will do a mvp of this next week and we can go from there!

Definitely would like to specify the allowlist in code, and avoid tauri writing feature flags to Cargo.toml

I think this is actually an antipattern to be honest. Having your configuration in exactly one place makes it auditable. If you can set this kind of thing anywhere in code, then where do you look to know what you have set?

I think this is actually an antipattern to be honest. Having your configuration in exactly one place makes it auditable. If you can set this kind of thing anywhere in code, then where do you look to know what you have set?

Totally agree, having the config in one place is good and the closer we can get to that the better.
That said, configuration of a tauri app is already split between main.rs and tauri.conf.json right now and as a user I'd rather have all configuration in rust code where I can add comments and the like at the expense of simplicity 🤔

I think this is actually an antipattern to be honest. Having your configuration in exactly one place makes it auditable. If you can set this kind of thing anywhere in code, then where do you look to know what you have set?

Actually it can be in one place in rust, with the proposed API, all plugins (user defined) and core plugins (our plugins proposed in this issue) can only be passed through tauri::Builder::plugins() in main.rs.

I think the point brought up about users having to touch Rust code is very daunting, even if it a very simple operation. I think the option for users to choose one system over another is preferable. So for example, have the project when initialized, include the allowList in the config file. In the main code, we could have a macro for the plugins portion, something link include_from_config!(),
This way, if a user would rather use the init pattern, they can just remove the macro call and go from there.
Another important note, if we wanted to go with the above route, of allowing users to choose, it would be a very good idea to emit an info message to the console so the user knows which of the two methods are being used, and thus avoid confusion. This or just emit a warning, if for example, the user opts out of using the config file, but still has the allowList key in their config file.
But I 100% love the idea of modularizing the core API's.

As a notice to anyone coming along, work on this will continue after the release of v1.

configuration of a tauri app is already split between main.rs and tauri.conf.json right now and as a user I'd rather have all configuration in rust code where I can add comments and the like

I like the idea of a macro that pulls in the tauri.conf.json and compiles down to calls to the modular APIs under the hood

@JonasKruckenberg If comments are a desirable feature, is JSONC an option for the config file?

rc.0 introduced JSON5 support for the conf file in February :)


upload: Use content_disposition_header from Django 4.2.

The code for this was merged in Django 4.2:
https://code.djangoproject.com/ticket/34194

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

The test failure is a mypy issue -- looks like the Django stubs don't know about the new function. Probably worth reporting upstream and marking with a type: ignore.

Nice, merged, thanks @alexmv!


chore: specify telemetry version

Motivation

If we start a new elixir application with the following deps:
  defp deps do
    [
      {:telemetry, "~> 1.1.0"},
      {:httpoison, "~> 1.8.2"}
    ]
  end

We won't be able to add :hackney_telemetry, since it only accept :telemetry at version 1.0.0.

Overview

I find myself needing this change so we can use it with later versions of :telemetry too. Would it be possible to get this merged?

I've also run into this issue and am hoping to see this merged 😄


Remove usage of deprecated to_graphql

What
Closes #19. As far as I can tell GraphQL::Schema.types now exposes the equivalent.

Could anyone merge this PR?

@benrbrook do you still have write access to this repo?
Otherwise, @Kjentleman @jacobmoretti @crempp - hi! Could one of you help get this merged?

@dwillett Hey Dave, I'll get this merged and a minor version release out for this fix today.

@dwillett Looks like the 30 day window for the github action to run CI expired. Are you able to push a new commit or re-open the PR? I believe that should re-trigger it. I'd like to make sure that passes before merging.

Awesome, thanks Jacob!

Thanks for taking care of this. Sorry I missed the original issue!


(Temporary) Managed voice channels

Feature request
Is this feature request related to a problem?
Some people want to create temporary voice channels to Just listen to music alone / with friends.
Admins/DJs could manage (add, edit, view, change perms, etc.) added voice channels marked as music
Is this feature related to a command? Is it a command?
Sure

/voicemanager view-music-channels - View added music channels
/voicemanager create-temp - create Temporary channels (DJ/custom)
/voicemanager close-temp - close Temporary channel
/voicemanager roles - view/edit permissions for Voice Manager
/voicemanager manage - manage channels at a glance

Wanted feature behaviour
The so-called "CloudyVC" system lets you easily create, edit and manage voice channels and Temporary voice channels
Add custom emoji

DJ Cloudy cannot clone itself two times in the same server so this feature does not make sense to put a lot of effort in it. Won't be implemented


fix(fleet): Use the right permissions for system-probe/security-agent fleet policies

What does this PR do?
security-agent.yaml & system-probe.yaml must be readable by the main agent, so they need root:dd-agent ownership & 0440 permissions
Motivation
Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes

/merge


Support for wlr_tablet_tool

I still have support for tablets in the pipeline. wlr_tablet_tool is already implemented and required some changes especially to the Cursor class and ffi_build.
See https://github.com/flacjacket/pywlroots/compare/main...heuer:pywlroots:tablet_feature
Considering the fact that WLR 0.17 is just around the corner: Should I open a PR for it now or wait for a WLR 0.17 release? I don't want to unnecessarily complicate the transition to 0.17.
@flacjacket, @jwijenbergh?

If you can, wait, as rebasing wlroots 0.16 changes on top of 0.17 is pretty difficult

Sorry for being annoying, but is there any movement on this?


test-branch/execute-job/quoted-authorization/f8aca44d-0017-4e3d-9e81-4a6978f9dd87

PR for testing 174f9256c75a4460bdd6f0aad707cc0bb66fec39

/canonical/self-hosted-runners/run-workflows 174f9256c75a4460bdd6f0aad707cc0bb66fec39


Meteor.users no longer an instance of Meteor.Collection

Without collection-hooks:
Meteor.users instanceof Meteor.Collection  => true
With collection-hooks:
Meteor.users instanceof Meteor.Collection => false
The problem with this now is that any Meteor.Collection.prototype.fn we wish to attach does not attach to the Meteor.users collection. This affects the collection-helpers package and potentially others.
https://github.com/dburles/meteor-collection-helpers/issues/2

@matb33  I meet same issue on IE10, on Chorme, IE11, the website work fine. How to fix it?


BrowserThanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.
Originally posted by @welcome[bot] in https://github.com/github/docs/issues/771#issuecomment-715641203

This issue appears have been opened accidentally. I'm going to close it now, but feel free to open a new issue or ask any questions in discussions!


Addons do not wait for namespace generation

Hi,
For installing Argo on my new cluster I have put two files in an addon directory and I have enabled addons via the configuration flag in the kubeone manifest. However, it seems like kubeone does not wait for the argocd namespace creation. The namespace got created, but I had to run the argo.yaml manually.
In which order are the files applied? I named my namespace yaml: 00-argocd-namespace.yaml and the argo deployment has the name argo.yaml.
Also: Does the addons feature support multiple sub folders? Right now I have one addons directory with many YAML files. I would like to create a few directories and put YAMLs in each.

For installing Argo on my new cluster I have put two files in an addon directory and I have enabled addons via the configuration flag in the kubeone manifest. However, it seems like kubeone does not wait for the argocd namespace creation.

Yes, that's true, kubeone doesn't wait for anything since it doesn't know what's inside. Contents of the addons are being kubectl apply-ed after render.

In which order are the files applied? I named my namespace yaml: 00-argocd-namespace.yaml and the argo deployment has the name argo.yaml.

Kubeone render whole addon into the single manifest that's kubectl apply-ed.

Also: Does the addons feature support multiple sub folders? Right now I have one addons directory with many YAML files. I would like to create a few directories and put YAMLs in each.

No, only 1 level of subdir is supported.

Kubeone render whole addon into the single manifest that's kubectl apply-ed.
is there a specific order for this single manifest that gets created? because normally kubectl apply -f single.yaml should work if I create the namespace in this yaml first and then the rest of the resources. I would really like to know why applying the argo.yaml failed.

The order is whatever fs.ReadDir has. See https://github.com/kubermatic/kubeone/blob/06c8f8c5fefc2bd39516e97b3d140adb1199472b/pkg/addons/manifest.go#L68

@kron4eg thanks


[discuss] docker compose make quick start hangs

This is a problem I keep hitting.
After a while, I would have an old version of openwhisk/controller:latest locally.
When running make quick-start with all defaults it will try to use the local old image, and the controller controller will not start or not start correctly.
How can we make this bullet proof for the default case quick start.
Add a download step to download the images by default every time?
cc @ddragosd

wrong repo, correct place https://github.com/apache/incubator-openwhisk-devtools/issues/116


Changing the Default Chunk Size from Storage Policy Settings

Hi CommvaultEngg Team,
I need some information regarding changing the Default Chunk Size from Commvault-Python SDK.
Is there any way we can modify the default Chunk Size from 4096 Mb to any larger size like 8192 or 12288 MB from CV-Python SDK?
It is required for Backup Performance optimization (increasing Throughput).
Manually we can do this change by below option :
Storage Policy --> Primary Copy --> Properties --> Data Paths --> Properties
I am using  Commvault Python SDK version :  CV11SP11

Please open Commvault support ticket.