Network intents when applied using update API creates a new service instance

Description:
This issue is observed when using update API for updating network intent of an application
Steps to reproduce:

create logcal cloud with cluster1
specify cluster1 as the application placement intent.
specify network intents for application
Approve and instantiate the dig.
Edit the application network intent.
Call update API.
A new service instance is created for updated network intents, and the previous service instance still remains.

Please add examples of the intents used to reproduce - specifically step 3 and step 5.

Please add examples of the intents used to reproduce - specifically step 3 and step 5.

For step 3, we are using below json payload
wlIntent := WorkloadIntent{ 			Metadata: Metadata{ 				Name:        workloadIntentName, 				Description: "NA", 				UserData1:   customData, 				UserData2:   "data2"}, 			Spec: WorkloadIntentSpec{ 				AppName:          appName, 				WorkloadResource: intentData.DigVersion + "-" + appName, 				Type:             "Deployment", 			}, 		}
We use below URL to createworkload intent
url := "http://" + orch.MiddleendConf.OvnService + "/v2/projects/" + p + 		"/composite-apps/" + ca + "/" + v + 		"/deployment-intent-groups/" + digName + "/network-controller-intent/" + 		nwControllerIntentName + "/workload-intents" resp, err := orch.apiPost(jsonLoad, url, intentName)
For step 5, we are deleting the workload intent and then creating it
url := "http://" + orch.MiddleendConf.OvnService + "/v2/projects/" + p + 		"/composite-apps/" + ca + "/" + v + 		"/deployment-intent-groups/" + digName + "/network-controller-intent/" + 		nwControllerIntent + "/workload-intents/" + workloadIntentName + "/interfaces/" + ifaceName 	resp, err := orch.apiDel(url, ca+"_delIface")
and then creating workload intent using step mentioned as part of step3
Hope it helps

@amcopma - I don't know the details of your example test case, so I'll describe some observations I made using the vfw test case (which uses network intents).
Let me know if any of the following may be relevant to your test case.

I instantiated the vfw test case.  Then, I deleted one of the interface intents (on the 'firewall' app) and recreated an interface intent, changing the IP address of the interface in the intent.  After running the 'update' command, I saw the the new 'firewall' pod trying to start up (never fully came up), but the existing pod continued to run.
I suspected the Deployment spec.strategy.type was a factor in my case, so I started over after changing the firewall deployment strategy type to be "Recreate".  In this case, (doing the same test as I did in #1), the 'firewall' pod got deleted first and then the new one started.
I suspected the issue I had in #1 was I only change 1 IP address, but the new pod was trying to use the same IP on other interfaces, so that was why new pod did not come up.  So, I reset the firewall to have the default strategy (as in #1) and this time, during the test, I changed all 3 firewall interface intents to have different IPs (so as not to conflict with initial pod).  In this case, on doing the 'update' command, the new pod came up and the old pod was deleted.

What I observed in case #1 sounds kind of similar to what you are reporting.
If none of what I saw in #1-#3 is relevant to your issue, please post the full details of your test case, so we can attempt to reproduce.

Hope this output helps
1. v1-firewall instantiated
ubuntu@nodeXXXX:~/allauddin/aarna-stream/awe/src/guimiddleend$ k get pod NAME                           READY   STATUS    RESTARTS   AGE mongo-7dd4599d65-9v2jj         1/1     Running   0          9m21s v1-firewall-5cc964bb47-kd77j   0/1     Pending   0          71s
ubuntu@nodeXXXX:~/allauddin/aarna-stream/awe/src/guimiddleend$ k get pod -o yaml | grep nfn-network       k8s.plugin.opnfv.org/nfn-network: '{"type":"ovn4nfv","Interface":[{"interface":"net0","name":"protected-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"},{"interface":"net1","name":"emco-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"},{"interface":"net2","name":"unprotected-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"}]}'             f:k8s.plugin.opnfv.org/nfn-network: {} ubuntu@nodeXXXX:~/allauddin/aarna-stream/awe/src/guimiddleend$ ^C
2. IP addresses updated by updating network intent using Update API
ubuntu@nodeXXXX:~/allauddin/aarna-stream/awe/src/guimiddleend$ k get pod NAME                           READY   STATUS    RESTARTS   AGE mongo-7dd4599d65-9v2jj         1/1     Running   0          11m v1-firewall-5cc964bb47-kd77j   0/1     Pending   0          3m v1-firewall-f5bfbbc6b-862zn    0/1     Pending   0          6s
ubuntu@nodezXXXX:~/allauddin/aarna-stream/awe/src/guimiddleend$ k get pod v1-firewall-f5bfbbc6b-862zn -o yaml | grep nfn-network     k8s.plugin.opnfv.org/nfn-network: '{"type":"ovn4nfv","Interface":[{"interface":"net0","name":"protected-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"},{"interface":"net1","name":"emco-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"},{"interface":"net2","name":"unprotected-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"}]}'           f:k8s.plugin.opnfv.org/nfn-network: {}
ubuntu@nodez00b03:~/allauddin/aarna-stream/awe/src/guimiddleend$ k get pod v1-firewall-5cc964bb47-kd77j -o yaml | grep nfn-network     k8s.plugin.opnfv.org/nfn-network: '{"type":"ovn4nfv","Interface":[{"interface":"net0","name":"protected-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"},{"interface":"net1","name":"emco-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"},{"interface":"net2","name":"unprotected-private-net","defaultGateway":"false","ipAddress":"<IP_ADDRESS>"}]}'           f:k8s.plugin.opnfv.org/nfn-network: {} ubuntu@nodez00b03:~/allauddin/aarna-stream/awe/src/guimiddleend$

@amcopma - on the first instantiation of your firewall (before doing an update), does it ever get out of Pending status (and get to a Running status)?

@amcopma - hi  - is there any update to this?  Have you determined why the initial Pod does not leave the Pending state?

@snackewm Yes, we did identified the reason for the firewall service not getting into running state, I will retry once the fix is done and update this ticket


Dedicated Load Balancer Basic Management Using CLI

Use CLI commands to create a basic load balanced web server farm

thx Mark.  this is great


(tests) Move away from ApproxDict

conftest.py defines an ApproxDict, which is a subclass of dict, whose equality method has been overridden such that, if a and b are dictionaries, then a == ApproxDict(b) will have the same truth value as a.items() >= b.items() (i.e. a is equal to ApproxDict(b) if a's key-value pairs are a superset of b's key-value pairs).
Since a.items() >= b.items() is a much clearer assertion than a == ApproxDict(b), let's replace usages of ApproxDict in our test suite with the more explicit assertion.

Hey @szokeasaurusrex , i started working on this if you dont mind. Still need to clean up some assertions which weren't picked up by the regex I used.

Huh, did not know this @antonpirker. Then let's close this


Doesn't build on Xcode 7 beta 4.

Need to covert to the new swift and even then there are errors.  Please update.

You can download swift 2 (Xcode 7 beta X) version manually, from swift_2 branch. When Xcode 7 will be released from beta, I'll allow update it from cocoapods.


Roll Engine from 9b2c8a140e4d to 12de11aff7db (2 revisions)

https://github.com/flutter/engine/compare/9b2c8a140e4d...12de11aff7db
2022-04-19<EMAIL_ADDRESS>Roll Skia from 05106ac1c327 to fce87a43e6df (3 revisions) (flutter/engine#32777)
2022-04-19<EMAIL_ADDRESS>Replace 'std::mutex' inside 'SyncSwitch' to 'fml::SharedMutex' (flutter/engine#32773)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Add pipeline summary GitHub comments

It's not possible to chain these pipeline tasks together with the github-add-comment task because Tekton runs everything in finally in parallel.
There is some code duplication so I filed a jira issue to reduce this later.
I'm also placing this on hold until #157 and https://github.com/redhat-openshift-ecosystem/operator-pipelines-images/pull/45 are merged in their new home. The pipeline_image param default will need to be updated as well.

Sample Comments


[wallets] Revert Safe SDK update

Revert https://github.com/thirdweb-dev/js/pull/2221

/release-pr

@SocketSecurity ignore<EMAIL_ADDRESS>

close in favor of #2364


Single-layered mesh generation.

Thank you for the great work and for sharing the code. How should we modify the code to generate "single-layered mesh" as shown in Figure 2 in Supplementary Material? Thank you very much.

@xincoder Did you find solution ? :)

The reason why the output mesh is in a double-layered fashion is that the gt tsdf_vol is generated as double-layered in this work. To convert it into single-layered, I guess either to change the gt tsdf_vol and re-train it, or using extracted depth to conduct TSDF fusion and dump the mesh.


EKS SSO with dex

User Story
Currently when creating EKS CAPA cluster, customer is required to use AWS authentication in order to connect with the clusters. What would be perfect, is that the GS dex application is easily deployable on the EKS clusters, such that customers can use the OIDC provider they would usually use for any other CAPA or Vintage clusters.
Acceptance Criteria

[ ] Dex application works on EKS clusters
[ ] Documentation for customers is provided for the dex configuration on EKS clusters

Dependencies (optional)

EKS instructions - https://intranet.giantswarm.io/docs/dev-and-releng/capi-eks-internal-doc/

Implementation details

Implementation info to be filled out by engineer

In standup, Spyros mentioned this post: https://aws.amazon.com/blogs/containers/using-dex-dex-k8s-authenticator-to-authenticate-to-amazon-eks/

@gawertm @anvddriesch this might be nice to show with Blacklane next week

From my perspective this should just be the same as any other cluster since the eks chart supports setting oidc flags in the same way as the other providers https://github.com/giantswarm/cluster-eks/tree/main/helm/cluster-eks#control-plane
However, I'll confirm by installing the auth-bundle on an eks cluster to double check. :smile:

not sure we need that for Blacklane already. as we don't even know if they run on EKS?

@gawertm yes they want EKS clusters - that was clear from the talk we had at least

auth-bundle deployed successfully on spy0 EKS on snail-MC
CAPEKS template:
---
apiVersion: v1
data:
  values: |
    global:
      metadata:
        name: spy0
        organization: bigmac
      controlPlane:
        oidcIdentityProviderConfig:
          clientId: dex-k8s-authenticator
          groupsClaim: groups
          usernameClaim: email
          issuerUrl: https://dex.spy0.gaws.gigantic.io
          identityProviderConfigName: dex-k8s-authenticator
      podSecurityStandards:
        enforced: true
kind: ConfigMap
metadata:
  creationTimestamp: null
  labels:
    giantswarm.io/cluster: spy0
  name: spy0-userconfig
  namespace: org-bigmac
---
apiVersion: application.giantswarm.io/v1alpha1
kind: App
metadata:
  labels:
    app-operator.giantswarm.io/version: 0.0.0
  name: spy0
  namespace: org-bigmac
spec:
  catalog: cluster
  config:
    configMap:
      name: ""
      namespace: ""
    secret:
      name: ""
      namespace: ""
  kubeConfig:
    context:
      name: ""
    inCluster: true
    secret:
      name: ""
      namespace: ""
  name: cluster-eks
  namespace: org-bigmac
  userConfig:
    configMap:
      name: spy0-userconfig
      namespace: org-bigmac
  version: 0.16.0
---
apiVersion: v1
data:
  values: |
    clusterName: spy0
    organization: bigmac
kind: ConfigMap
metadata:
  creationTimestamp: null
  labels:
    giantswarm.io/cluster: spy0
  name: spy0-default-apps-userconfig
  namespace: org-bigmac
---
apiVersion: application.giantswarm.io/v1alpha1
kind: App
metadata:
  labels:
    app-operator.giantswarm.io/version: 0.0.0
    giantswarm.io/cluster: spy0
    giantswarm.io/managed-by: cluster
  name: spy0-default-apps
  namespace: org-bigmac
spec:
  catalog: cluster
  config:
    configMap:
      name: spy0-cluster-values
      namespace: org-bigmac
    secret:
      name: ""
      namespace: ""
  kubeConfig:
    context:
      name: ""
    inCluster: true
    secret:
      name: ""
      namespace: ""
  name: default-apps-eks
  namespace: org-bigmac
  userConfig:
    configMap:
      name: spy0-default-apps-userconfig
      namespace: org-bigmac
  version: 0.7.0

auth-bundle values
---
apiVersion: application.giantswarm.io/v1alpha1
kind: App
metadata:
  finalizers:
  - operatorkit.giantswarm.io/app-operator-app
  generation: 1
  labels:
    app-operator.giantswarm.io/version: 0.0.0
    app.kubernetes.io/name: auth-bundle
    giantswarm.io/cluster: spy0
    policy.giantswarm.io/psp-status: disabled
  name: spy0-auth-bundle
  namespace: org-bigmac
spec:
  catalog: giantswarm
  config:
    configMap:
      name: spy0-cluster-values
      namespace: org-bigmac
  extraConfigs:
  - kind: configMap
    name: psp-removal-patch
    namespace: org-bigmac
    priority: 150
  kubeConfig:
    context:
      name: spy0
    inCluster: true
    secret:
      name: spy0-kubeconfig
      namespace: org-bigmac
  name: auth-bundle
  namespace: org-bigmac
  userConfig:
    configMap:
      name: spy0-auth-bundle-user-values
      namespace: org-bigmac
  version: 0.1.3
---
apiVersion: v1
data:
  values: |
    apps:
      athena:
        userConfig:
          configMap:
            values: |
              managementCluster:
                name: snail
      dex-app:
        userConfig:
          configMap:
            values: |
              isWorkloadCluster: true
      ingress-nginx:
        enabled: true
kind: ConfigMap
metadata:
  labels:
    app-operator.giantswarm.io/watching: "true"
  name: spy0-auth-bundle-user-values
  namespace: org-bigmac

Error: Token verification process failed: Get "[https://api.spy0.gaws.gigantic.io:443/version?timeout=32s](https://api.spy0.gaws.gigantic.io/version?timeout=32s)": tls: failed to verify certificate: x509: certificate is valid for 6eae2f2e28f9d92eff54dfa57c37081d.gr7.eu-central-1.eks.amazonaws.com, ip-172-16-121-133.eu-central-1.compute.internal, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, not api.spy0.gaws.gigantic.io

The issue still persist as there doesn't seem to be an option yet to define extraSANs or global.controlPlane.apiExtraCertSANs like on cluster-aws on clusterEKS yet. As of this certificates are not valid for the API-URL:api.spy0.gaws.gigantic.io

I tried using the eks api-endpoint as address in athena and that resulted in a valid token.
So in addition to the oidc settings seen above in the comment by @ssyno, this was needed:
apiVersion: v1
data:
  values: |
    apps:
      athena:
        userConfig:
          configMap:
            values: |
              managementCluster:
                name: snail
              kubernetes:
                api:
                  address: https://6EAE2F2E28F9D92EFF54DFA57C37081D.gr7.eu-central-1.eks.amazonaws.com
[...]

oidc flags are not applied when using the template command. I had to edit the controlplane values myself in order to propagate them

Phoenix confirmed that it's not implemented on CAPA/EKS. See more

Here's the PR for updating our OIDC Dex documentation with changes related to EKS.

✅ Dex application works on EKS clusters
✅ Documentation for customers is provided for the dex configuration on EKS clusters. Doc link
@T-Kukawka @alex-dabija

closing this, thanks a lot!


WASM Plugin on_log method not called with Matching API

Title: WASM Plugin on_log method not called with Matching API
Description:
The scenario is having two filters in the same filter chain for a http listener.

The first filter rejects the request and a response is returned by it.
If the second filter is an ExtensionWithMatcher with an ExecuteFilterAction delegating to a WASM filter, and the WASM filter is implementing the on_log method, the method is not invoked. As opposed to having the same scenario but without the ExtensionWithMatcher, then the on_log method is correctly invoked.

Repro steps:

Apply the attached configuration
curl -vvv http://localhost:10000/api/get
Expected a log entry containing wasm log examples.http_filter examples.http_filter vm.examples.http_filter: on_log, but it is not shown.

Config:
https://github.com/balbifm/envoy-config/blob/main/envoy.yaml

CC @mpwarres @snowp


[MTL+] add non-low power mode support for av1 10bit encode

1, add ffmpeg-vaapi/qsv support
2, add gst-va/msdk support
3, enable in caps

almost all sanity test cases passed except 1 case failed by bit rate check for gst-va

please fix conflicts


Grafana Dashboards have 'dips'

After setting up Unpoller via Docker, with a Unifi Express I am finding that the charts on Grafana are shown with 'dips'. I would expect these lines to be nice and smooth, but sadly they keep reporting zero
This is happening for the chart 'UAP Bandwidth / Wireless Devices' on Dashboard 'UniFi-Poller: Client Insights'

Increase the poll interval.

Maybe I'm just blind, but what is the Docker ENV tag to do that?

There appears to be UP_INFLUXDB_INTERVAL for InfluxDB, but nothing for Prometheus
I'm using prometheus and have this same problem.

Prometheus scrape interval?

Increasing the prometheus scrape interval (how often prometheus requests metrics from unpoller) does not appear to make the unpoller prometheus exporter fetch metrics from unifi more often.
I haven't dug into how UP_INFLUXDB_INTERVAL is implemented, but maybe increasing it will also increase the update frequency for the prometheus exporter?

unpoller appears to fetch metrics on its own internal interval and export the cached copy.

That's certainly not how I wrote the code and I doubt @platinummonkey changed that logic. It fetches metrics during the scrape request.

I rebuilt unpoller from 96a9259eb9e9ba138a39d6cf2691d4240c8b57e7 (today's master).
My prometheus scrape interval is 15s
The top panel in this screenshot is from telegraf scraping SNMP from my unifi switch directly.
The bottom panel in this screenshot is unpoller. It scrapes a UCK G2 Plus running Unifi OS v4.0.18 and Network 8.4.62.
I suspect both to look the same, but unpoller only has new metrics about once per minute, sometimes less.

You're reporting a completely different behavior than this original issue. This is normal. The API doesn't update as often as the SNMP values.

My understanding of prometheus, sampling, and grafana dashboard constructing lead me to believe the two behaviors are tied to one another. Zero values exist when rate() is used with a range vector that is shorter than the update interval, but there is no way to configure unpoller to fetch data more quickly.
Upthread you wrote:

Increase the poll interval.

Then:

It fetches metrics during the scrape request.

Both of which are at odds with:

The API doesn't update as often as the SNMP values.

So it appears that unpoller cannot sample often enough for prometheus rate() and friends to avoid returning 0 values with a range vector of less than about [3m]. As rate() and range vectors are the tools used to build dashboards that don't drop to 0.
I understand unpoller may not have control of how often the API updates.
Therefore I expect the configuration documentation scrape interval or update interval shorter than one minute is not going to result in improved resolution.
I also expect that the pre-built dashboards would have a minimum interval set to match.
I also expect that the slow API update rate is why the pre-computed metric unpoller_device_port_receive_rate_bytes also shows a 0 byte receive rate.
I understand we may have no way to win here, but I haven't seen any documentation about this limitation, and I believe that drove the initial reporter to create this issue.

Does documentation need to be written to address the issue with scrape intervals, or is there another way to resolve this issue?

Does documentation need to be written to address the issue with scrape intervals, or is there another way to resolve this issue?

Yes this would be the way to do this. Docs website is available here https://github.com/unpoller/unpoller.github.io/tree/master/documentation


Plot Sizing

There is excess white space on either side of the plot window. Could the plot window size to better fit the program window?
https://hydroserver.codeplex.com/workitem/10108

I think this has been resolved.


Please don't add SSL support

Someone recently asked for SSL support for C2 communications, but I think it is the wrong approach because some security products perform SSL interception and obtain clear-text visibility of all the data, as explained by this also great project: https://github.com/Mr-Un1k0d3r/ThunderShell
For this reason if I had to choose I would rather prefer to use weak XOR over HTTP than using HTTPS.
If you want to make this project even more awesome I would suggest AES over HTTP for encrypted communications, as used in this simple but elegant reverse shell: https://www.trustedsec.com/2012/03/building-a-native-http-shell-with-aes-in-python/
Also, AES over HTTP is a lot easier to implement than SSL in my opinion.
Keep it up, great project and thanks for sharing it.

Cool thanks

Just putting my two cents in
https://en.wikipedia.org/wiki/Forward_secrecy
In a perfect world:
AES/XOR over SSL using Ephemeral Diffie-Hellman key exchange with Perfect Forward Secrecy
From looking at the leaked sources of "Hive" You can say that's CIA grade stuff 😄


feat: allow showing notifications as snackbars in the UI

Hey, I just made a Pull Request!
Shows notifications in the bottom right corner as snack bars when they arrive

:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

@Rugvip @mareklibra maybe take a look when you have time?


stage1 not automatically fetch when used as dependency

I'm writing a stage1 that have coreos.com/rkt/stage1-coreos as a dependency.
Import of my stage1 failed since the process that fetch the stage1 from rkt bin directory is not triggered and discovery mechanism failed too since there is no discovery tags on coreos.com

I am curious what additional features you would like to have in stage1.
I think we should updated the rkt release guide to upload the stage1s on GitHub and change the coreos.com website to have something like:
<meta name="ac-discovery"
  content="coreos.com/rkt/stage1-coreos https://github.com/coreos/rkt/releases/download/{version}/stage1-coreos-{version}-{os}-{arch}.{ext}">

That could be useful, even without using a custom stage1.
@krnowak would it be difficult to use discovery mechanism for fetching the dependencies of stage1?

I'm rewriting dgr to build as a stage1 layer.
Working inside rkt will remove a big part of my discovery (except looking for latest image), and will allow me to have overlay management without writing it myself. I'm then exporting the upper of the build as the rootfs of my ACI.
In the process I need systemd-nspawn to isolate the users scripts, so I added stage1-coreos as a dependency of my build ACI to have it without adding it to my own stage1.

...(except looking for latest image)

is linked to #2276


I can't deploy and scale apps on flynn

When I deploy or scale apps on my flynn node I'm gettings the follow error.
flynn: getting image config with "docker inspect -f {{ json .Config }} brbid/wp"
flynn: tagging Docker image with "docker tag brbid/wp docker.flynn.tree.sh/alexandro:latest"
flynn: pushing Docker image with "docker push docker.flynn.tree.sh/alexandro:latest"
The push refers to a repository [docker.flynn.tree.sh/alexandro]
508c549726fb: Layer already exists
b1405bec6915: Layer already exists
eab431e9cb17: Layer already exists
a3f836de1386: Layer already exists
8050217d10d4: Layer already exists
9a999c18ebce: Layer already exists
54a54e27530f: Layer already exists
3cbb6cb8568b: Layer already exists
55410c2ce269: Layer already exists
78227ac00a42: Layer already exists
097a916f6a5a: Layer already exists
3e77de2f74ab: Layer already exists
4c36fb098bb8: Layer already exists
73ccb4760634: Layer already exists
daae20c55d80: Layer already exists
c54d1662afc3: Layer already exists
2478b27e35a5: Layer already exists
0dfa0375a8c9: Layer already exists
a4a6b530da26: Layer already exists
a03521c7187f: Layer already exists
3703e26e0d5e: Layer already exists
4591824cd00a: Layer already exists
c1870dfa056f: Layer already exists
26fdebcea995: Layer already exists
0fe2204ee16b: Layer already exists
6fd178795bc8: Layer already exists
5670c80821b4: Layer already exists
b383c4b9507c: Layer already exists
e40dce3d41d4: Layer already exists
7b7797fb4360: Layer already exists
c9a0778a74b0: Layer already exists
ca73e27525f7: Layer already exists
142a601d9793: Layer already exists
latest: digest: sha256:38011ab174516686f5bf33cc93c04c0fb7c0593edc16bbe2ecf891603855639c size: 32473
flynn: image pushed, waiting for artifact creation
flynn: deploying release using artifact URI http://flynn:0a41db91c5852c0ae7002385f3984730@docker-receive.discoverd?name=alexandro&id=sha256:38011ab174516686f5bf33cc93c04c0fb7c0593edc16bbe2ecf891603855639c
object_not_found: service not found
The "flynn-host" log https://transfer.sh/QgbBE/flynn-host-debug.tar.gz
The "flynn log" https://gist.github.com/hugoleodev/20e472f9e9e986869f57d79f847b5ca8
The "flynn ps" log https://gist.github.com/hugoleodev/282101ce833b9927840eac0223e871fa

@hugoleodev the issue here is that your instance is running out of memory, and because there is no swap to handle the pressure, certain jobs started throwing errors (for example discoverd was intermittently marking services as down).
You should take a cluster backup and restore to a cluster with more memory.

@lmars I will fix it now. Once again, thank you for your support.


Use inject in MsalRedirectComponent

Core Library
MSAL.js v2 (@azure/msal-browser)
Wrapper Library
MSAL Angular (@azure/msal-angular)
Public or Confidential Client?
Public
Description
In the alpha for v3, would you please modify MsalRedirectComponent so that instead of injecting the MsalService via the constructor, you instead use the inject(MsalService) option?  If you do that, we can stop providing a constructor in our component for the sole purpose of sending you a service.
Source
External (Customer)

@grosch-intl thanks for the feature request. We'll look into it but as a general rule we're not doing API breaking changes for v3. We're limiting updates to default behavior breaking changes and some tooling enhancements.
@EmLauber can we track this feature request for Angular v3? Thanks!

Tracking internally and keeping open as a feature request for breaking changes.


Odoo v10 compat

Coverage decreased (-42.2%) to 46.57% when pulling ee1935b5785034cb71faf46d9881fe6dc74ce5ff on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage decreased (-42.0%) to 46.768% when pulling c5d59d2024779adfcb7a79e297a1a1900e22079a on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage decreased (-41.6%) to 47.129% when pulling 9a378e3044149b504b5730a24bee836edd3e6af1 on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage decreased (-8.2%) to 80.512% when pulling ccfd7969ea904647ae0ac8162e8ad30a3074c403 on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage decreased (-39.3%) to 49.442% when pulling 15f52823db38c778cc7a29a363686754ff28c7ea on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage decreased (-39.3%) to 49.442% when pulling 15f52823db38c778cc7a29a363686754ff28c7ea on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage decreased (-39.3%) to 49.442% when pulling 15f52823db38c778cc7a29a363686754ff28c7ea on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage increased (+0.6%) to 89.364% when pulling 975139e3b568dfd5f99f8c7baa12f3e39a898d7e on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage increased (+0.4%) to 89.17% when pulling 4a122f9111487b603f514b8cdfcee66d0e953ecb on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage increased (+0.4%) to 89.17% when pulling 4a122f9111487b603f514b8cdfcee66d0e953ecb on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage increased (+0.4%) to 89.17% when pulling 4a122f9111487b603f514b8cdfcee66d0e953ecb on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

Coverage increased (+0.4%) to 89.17% when pulling 4a122f9111487b603f514b8cdfcee66d0e953ecb on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.

With this PR, we are using JSONRPC for the db and common services for Odoo version superior to 7.0. This was required for Odoo v10 as the XMLRPC server of these services has been dropped.

Coverage increased (+0.4%) to 89.105% when pulling 50bd336be3edd3b198c5f4a18b98ac0825ffde91 on odoo-10 into 2e54ba4dd2e77fc47924764b25a5ab2b24b5926b on master.


"Lists should be equal" keywords in the Collection library should have the option to ignore order

when comparing lists, we sometimes want to compare only the content irregardless of the order.
Currently, the Lists should be equal ensures each index in the list is the same.
So the following test case fails
*** Settings ***
Library     Collections

*** Test Cases ***
Compare lists
    ${l1}=  create list     a   b    c
    ${l2}=  create list     c   a    b
    lists should be equal   ${l1}   ${l2}

If I wanted to get this test to pass, I would need to use a combination of keywords found in Collections and BuiltIn.
*** Settings ***
Library     Collections

*** Test Cases ***
Compare lists
*** Settings ***
    ${l1}=  create list     a   b    c
    ${l2}=  create list     c   a    b
    list should contain sub list  ${l1}     ${l2}
    ${l1_length}=       get length  ${l1}
    length should be    ${l2}       ${l1_length}

I would be nice to be able to do something as follows:
*** Settings ***
Library     Collections

*** Test Cases ***
Compare lists
    ${l1}=  create list     a   b    c
    ${l2}=  create list     c   a    b
    lists should be equal   ${l1}   ${l2}      ignore_order=True

This ticket has been opened to improve the Lists should be equal keywords to include a way to ignore the orders of the list.

Sounds reasonable. What about duplicates?

I haven't given some thoughts about duplicates, but I guess we can have an "ignore_duplicates" argument as well.

This Lists should be equal keyword first compares  length of two list and if it is not same it fails.
if we ignore_order=True as argument, we can check first list's element in 2nd list  and if it is available at any position, test should pass.
Pseudo code
If  ignore_order=True
remove duplicates from lists
Fail if  not same length
if  element is not available in 2nd list, assert fail.
else  ##  order should be checked
compare item1 and item2
if ignore_order == True:
    assert_true(item1 in list2, msg='Index %d%s' % (index,  " Not in second list"))
else:
    assert_equal(item1, item2, msg='Index %d%s' % (index, name))

As length of both lists are, same we need to check first list's element in 2nd list in case of ignore_order.

Hi @pekkaklarck,
Can you please review following _yield_list_diffs function.
need to import from collections import Counter
def lists_should_be_equal(list1, list2, ignore_order=False,msg=None, values=True,
                              names=None):
    ....
    diffs = list(_yield_list_diffs(list1, list2, names,ignore_order))
   ....

def _yield_list_diffs(list1, list2, names,ignore_order=False):
    **if ignore_order == True:
        assert_true(Counter(list1) == Counter(list2 ), msg='Lists  are  different')
    else:**
        for index, (item1, item2) in enumerate(zip(list1, list2)):
            name = ' (%s)' % names[index] if index in names else ''
            try:
                assert_equal(item1, item2, msg='Index %d%s' % (index, name))
            except AssertionError as err:
                yield unic(err)
    ...

If we add these two lines before for loop in the existing given function will compare two UN-ordered  lists.
Case 1:
['A', 'B', 'C', 'B']
['A', 'D', 'B', 'B', 'E']
lists_should_be_equal(my_list1,my_list2,ignore_order=True)
AssertionError: Lengths are different: 4 != 5
Case 2:
['A', 'B', 'C', 'B']
['A', 'D', 'B', 'B']
lists_should_be_equal(my_list1,my_list2,ignore_order=True)
AssertionError: Lists  are  not matching
Case 3:
['A', 'B', 'C', 'B']
['C', 'A', 'B', 'B']
PASS
Adding more tests and verifying it

Duplicates not removed and compares correctly.
No original list modified.

Lists Should Be Equal With Different Values Ignore_order :: FAIL L... | PASS |
Lists Should Be Equal With Different Values And Own Error Message ... | PASS |
Lists Should Be Equal With Different Values And Own And Default Er... | PASS |
Lists Should Be Equal With Named Indices As List Ignore_order :: F... | FAIL |
Lists are different:
Index 0 (a): 11 != 13
Index 2 (c): 13 != 11
Lists Should Be Equal With Named Indices As List With Too Few Valu... | PASS |
Lists Should Be Equal With Duplicate Value Ignore_order :: PASS li... | PASS |
Lists Should Be Equal With Duplicate Value Second Small List :: FA... | FAIL |
Lists  are  different
Lists Should Be Equal With Two Duplicate Value Ignore_order :: FAI... | PASS |
Lists Should Be Equal With Duplicate And Different Value Ignore_or... | FAIL |
Lists are different:
Index 2: A != E
Index 3: D != A

https://github.com/robotframework/robotframework/pull/2720

#2720

@bbpatel2001, I don't understand the usage of collections.Counter at all. I would assume just sorting lists before comparison would be the easiest solution. Are you interested to look at this again?

As Pekka notes, sorting the list contents and comparing those sorted lists is the easiest way to do this, and the way that I've handled this situation in other projects when I only care about list contents rather than order.

why not to use the "should be equal" keyword in buildin?

What about introducing Set concept into framework itself and into Collections with related Sets Should Be Equal , Remove From Set, Convert To Set, etc?

May this one help?
In our company I just extend this library to custom RF library and then import it to compare.

Hi @pekkaklarck could you please review PR https://github.com/robotframework/robotframework/pull/3469

is this PR #3469 RF 3.2 candidate?

This was implemented by PR #3469. Thanks a lot @bbpatel2001!


Remove const

The const type qualifier is only used for two things:

removing pipelining registers for taps. (This can probably be better solved by using an ILP pipelining algorithm)
removing handshake signals for taps. (Can probably be better solved with plumbed values, i.e. letting modules have some side-channel inputs)

Given this, we should probably fix the underlying problem and get rid of the const qualifier.

Using an ILP pipelining algorithm won't solve the taps problem! If we multiply the tap by a real value deep in the pipeline, it will add pipeline registers (b/c right now, we can't have inputs be assigned to different pipeline stages). Additionally, if a tap is used at multiple pipe depths, it will generate pipelining registers.
Maybe a solution is to add the 'plumbed' variables to systolic itself? And add a special-case compiler pass for wiring these that happens after pipelining?

We could special case the globals, which would eliminate the pipelining problem with taps. But what if we compute (tap+2) and then use it multiple places? that'll still fail.

Handshake(const) definitely doesn't make sense though

What about PackTuple()?
Currently, PackTuple relies on const to eliminate some of the stream sync HW for taps. (e.g. when we are putting taps into a fully parallel convolve). If we got rid of const, this wouldn't happen.
This may not be a problem in practice. For fully parallel pipelines, we should really be doing this as a static pipeline anyway. for reduced parallelism, the Auto-FIFO-insertion should be smart enough to see that no FIFOs are required. The Verilog synthesis should see what we're anding two valid bits that are the same together, and eliminate the AND.

Actually, the packTuple case won't work... this will create a combinational loop unless we insert a FIFO, which we don't want to do...

The pipelining issue reappears if we have a const input to a module (in the old system).
eg, we may be mapping F over pixels+taps. Previously, F could take in a const for the taps and optimize away the pipeline registers. W/o const, we can't do this.

Fixed in #108


Embed DebugHelper into main executable

As per #407, this is a backported version of the integrated DebugHelper into the main Blish HUD executable from .NET 5. From now on, when debugging, there won't be a separate executable for the DebugHelper anymore, and just a copy of the Blish HUD process will be used instead that acts just like the previous DebugHelper.
This simplifies the source code and build output. I haven't tested this version specifically though.

Going to do some AV testing to make sure this doesn't freak any of them out too much.

Off to a good start in the AV department.  https://www.virustotal.com/gui/file/fd8231739bce1bdafe1d086118723ca2f81d9abd91f4c43053d0264cf1052fd0/detection
I'll do some testing tonight and then give it a code-review.  Thank you!

Seems to work great!


new chat does not open the hidden chat view

What were you trying to fix here @aeschli?

lastFocusedWidget was still set, even if the widget was hidden.

You were running "New Chat" from the command palette? That doesn't work now with the latest change


pull request for e2e test at 01/20/2017 02:15:09

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Polymer Catalog -- link-related usability issue

The demo buttons look like links but they don't behave like links. Clicking on a link while holding CTRL would normally opens up a new tab. It doesn't for the demo buttons (the ones with the eye icon).
Also back buttons after clicking on a link will normally get you back to the same place you departed from (same page, same spot on the page). It doesn't work with the demos.
Can't the demo buttons just be normal links?

Dupe of https://github.com/Polymer/polymer-element-catalog/issues/143


Error when auto upgrading: Unable to write file (Error: unexpected end of file)

code-server version:
v10.15.1
OS Version:
ubuntu 18.04

Description
I'm prompt to upgrade so I click ok and then failed Unable to write file (Error: unexpected end of file)

Steps to Reproduce
none. the code-server popup a window prompt

Ah, this is for v2 right? Currently auto-update won't work because
we have no real releases for v2. I should probably have a check
for that case, but since it will only happen until we publish a
real version I haven't put a high priority on it.

Yeah baby. Thanks.


UI: Loading bar covers prev and next button on some screens

wanted: more info @parkermccurley, screenshots would be best

outdated, This has been taken care of, closing issue.


SSD Head used in this work

Hi,
This work uses a SSD Head for predictions. However, SSD uses default bounding boxes for prediction. How do you generate these default bounding boxes in this work on Gen1/1mpx datasets?

It is done in GridSizeDefaultBoxGenerator in modèles/SSD_utils.py.


Name of this repo

Should we call this one:
sigsep-mus-2018-cutlist-generator
sigsep-mus-2018-trim should then probably be renamed to sigsep-mus-2018-preview-generator (which you might want to fork to the sigsep organisation).
If you're not fussed then let's leave it!

Thanks!
Yeah, I agree. I'm not a member of this organisation so I just made a start using my personal account.


JKBMS BLE unstable batteries link lost after few seconds

Describe the bug
Hi,
"With a USB connection, everything is OK. Thank you again for this excellent work.
However, the number of USB ports is not sufficient to my project, so I have to use the BLE connection for the batteries. As you can see below, the Raspberry Pi detects both batteries. I have added the two MAC addresses in config.ini and reinstalled the latest version.
The battery data is collected once, but then nothing happens. Did I forget something?"
How to reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
Same behavior as when USB connected
Driver version
last version on git
Venus OS device type
Raspberry Pi
Venus OS version
V3.0.1
BMS type
JKBMS / Heltec BMS
Cell count
4
Connection type
Bluetooth
Config file
[DEFAULT]

; If you want to add custom values/settings, then check the values/settings you want to change in "config.default.ini"
; and insert them below to persist future driver updates.

; Example (remove the semicolon ";" to uncomment and activate the value/setting):
MAX_BATTERY_CHARGE_CURRENT = 60.0
MAX_BATTERY_DISCHARGE_CURRENT = 200.0

MIN_CELL_VOLTAGE   = 2.900
MAX_CELL_VOLTAGE   = 3.550
FLOAT_CELL_VOLTAGE = 3.450

;Device C8:47:8C:ED:06:11 JKBMS-Heating
;Device C8:47:8C:EE:29:AF JKBMS-DISPLAY

;Discovered device  c8:47:8c:ed:06:11
;Discovered device  c8:47:8c:ee:29:af

BLUETOOTH_BMS = Jkbms_Ble C8:47:8C:ED:06:11, Jkbms_Ble C8:47:8C:EE:29:AF
BLOCK_ON_DISCONNECT = False
TIME_TO_GO_ENABLE = True
BMS_TYPE = Jkbms

Relevant log output
**cat /data/log/dbus-blebattery.1/current**

@4000000064c530241de6af9c btloop
@4000000064c530241de6b384 reconnect
@4000000064c530241de6bb54 Exiting bt-loop
@4000000064c530242e012344 Missing device address argument
@4000000064c530260678d27c INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c53026068bba54 INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c530261ba6cdd4 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c530261bae72dc INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5302f396156b4 INFO:SerialBattery:Jkbms_Ble found!
@4000000064c5302f396bde04 INFO:SerialBattery:BAT: JKBMS 11.XW 4 cells (20230708)
@4000000064c5302f397bfb04 INFO:SerialBattery:Connection established to Jkbms_Ble
@4000000064c5302f3982f42c INFO:SerialBattery:Battery Jkbms_Ble connected to dbus from c8478cee29af
@4000000064c5302f398e7194 INFO:SerialBattery:========== Settings ==========
@4000000064c5302f39960ae4 INFO:SerialBattery:> Connection voltage: 13.26V | Current: 0.0A | SoC: 99%
@4000000064c5302f399c92c4 INFO:SerialBattery:> Cell count: 4 | Cells populated: 4
@4000000064c5302f39a3459c INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
@4000000064c5302f39aa2b3c INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 60.0A | MAX BATTERY DISCHARGE CURRENT: 200.0A
@4000000064c5302f39b110dc INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 150.0A | MAX BATTERY DISCHARGE CURRENT: 200.0A (read from BMS)
@4000000064c5302f39b78d04 INFO:SerialBattery:> CVCM:     True
@4000000064c5302f39be91e4 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.9V | MAX CELL VOLTAGE: 3.55V
@4000000064c5302f39c540d4 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
@4000000064c5302f39cbe024 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
@4000000064c5302f39d27f74 INFO:SerialBattery:> CCCM SOC: True  | DCCM SOC: True
@4000000064c5302f39d90f24 INFO:SerialBattery:Serial Number/Unique Identifier:<PHONE_NUMBER>
@4000000064c530300f2fdeec INFO:SerialBattery:DeviceInstance = 7
@4000000064c530300f3f3c84 INFO:SerialBattery:com.victronenergy.battery.c8478cee29af
@4000000064c530300f4af86c INFO:SerialBattery:BAT: JKBMS 11.XW 4 cells (20230708)
@4000000064c53030107710a4 INFO:SerialBattery:publish config values = 1
@4000000064c5303014575044 INFO:SerialBattery:DeviceInstance = 7
@4000000064c530301463df1c INFO:SerialBattery:Changed DeviceInstance = 7
@4000000064c530540a59fc7c Missing device address argument
@4000000064c53055205dc634 INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c53055206d048c INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c5305538f2163c INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5305538fa43fc INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c531032256c38c Missing device address argument
@4000000064c531051f405bcc INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c531051f5c86bc INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c5310539decbe4 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5310539eaed5c INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5311b38eff744 ERROR:SerialBattery:ERROR >>> No battery connection at Jkbms_Ble
@4000000064c5311b38f01684
@4000000064c5311b38f02624 connect and scrape on address: C8:47:8C:EE:29:AF
@4000000064c5311b38f035c4 btloop
@4000000064c5311b38f039ac reconnect

@4000000064c530241de69ffc connect and scrape on address: C8:47:8C:EE:29:AF
@4000000064c530241de6af9c btloop
@4000000064c530241de6b384 reconnect
@4000000064c530241de6bb54 Exiting bt-loop
@4000000064c530242e012344 Missing device address argument
@4000000064c530260678d27c INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c53026068bba54 INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c530261ba6cdd4 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c530261bae72dc INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5302f396156b4 INFO:SerialBattery:Jkbms_Ble found!
@4000000064c5302f396bde04 INFO:SerialBattery:BAT: JKBMS 11.XW 4 cells (20230708)
@4000000064c5302f397bfb04 INFO:SerialBattery:Connection established to Jkbms_Ble
@4000000064c5302f3982f42c INFO:SerialBattery:Battery Jkbms_Ble connected to dbus from c8478cee29af
@4000000064c5302f398e7194 INFO:SerialBattery:========== Settings ==========
@4000000064c5302f39960ae4 INFO:SerialBattery:> Connection voltage: 13.26V | Current: 0.0A | SoC: 99%
@4000000064c5302f399c92c4 INFO:SerialBattery:> Cell count: 4 | Cells populated: 4
@4000000064c5302f39a3459c INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
@4000000064c5302f39aa2b3c INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 60.0A | MAX BATTERY DISCHARGE CURRENT: 200.0A
@4000000064c5302f39b110dc INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 150.0A | MAX BATTERY DISCHARGE CURRENT: 200.0A (read from BMS)
@4000000064c5302f39b78d04 INFO:SerialBattery:> CVCM:     True
@4000000064c5302f39be91e4 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.9V | MAX CELL VOLTAGE: 3.55V
@4000000064c5302f39c540d4 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
@4000000064c5302f39cbe024 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
@4000000064c5302f39d27f74 INFO:SerialBattery:> CCCM SOC: True  | DCCM SOC: True
@4000000064c5302f39d90f24 INFO:SerialBattery:Serial Number/Unique Identifier:<PHONE_NUMBER>
@4000000064c530300f2fdeec INFO:SerialBattery:DeviceInstance = 7
@4000000064c530300f3f3c84 INFO:SerialBattery:com.victronenergy.battery.c8478cee29af
@4000000064c530300f4af86c INFO:SerialBattery:BAT: JKBMS 11.XW 4 cells (20230708)
@4000000064c53030107710a4 INFO:SerialBattery:publish config values = 1
@4000000064c5303014575044 INFO:SerialBattery:DeviceInstance = 7
@4000000064c530301463df1c INFO:SerialBattery:Changed DeviceInstance = 7
@4000000064c530540a59fc7c Missing device address argument
@4000000064c53055205dc634 INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c53055206d048c INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c5305538f2163c INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5305538fa43fc INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c531032256c38c Missing device address argument
@4000000064c531051f405bcc INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c531051f5c86bc INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c5310539decbe4 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5310539eaed5c INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5311b38eff744 ERROR:SerialBattery:ERROR >>> No battery connection at Jkbms_Ble
@4000000064c5311b38f01684
@4000000064c5311b38f02624 connect and scrape on address: C8:47:8C:EE:29:AF
@4000000064c5311b38f035c4 btloop
@4000000064c5311b38f039ac reconnect
@4000000064c5311b38f0417c Exiting bt-loop
@4000000064c5311c0f344fa4 Missing device address argument
@4000000064c5311d206fac3c INFO:SerialBattery:Starting dbus-serialbattery
@4000000064c5311d2080b39c INFO:SerialBattery:dbus-serialbattery v1.0.20230531
@4000000064c5311d3464b264 INFO:SerialBattery:Init of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5311d346b8c4c INFO:SerialBattery:Test of Jkbms_Ble at C8:47:8C:EE:29:AF
@4000000064c5312317b10294 ERROR:SerialBattery:No Jkbms_Ble found at C8:47:8C:EE:29:AF
@4000000064c5312317b8808c ERROR:SerialBattery:ERROR >>> No battery connection at Jkbms_Ble
@4000000064c5312317bbe3bc

Any other information that may be helpful
Device **c8:47:8c:ed:06:11** (public), RSSI=-71 dB
  Flags = 06
  Incomplete 16b Services = 0000ffe0-0000-1000-8000-00805f9b34fb,0000fee7-0000-1000-8000-00805f9b34fb
  Manufacturer = 650b88a0c8478ced0611
  Complete Local Name = JKBMS-Heating
Device **c8:47:8c:ee:29:af** (public), RSSI=-66 dB
  Flags = 06
  Incomplete 16b Services = 0000ffe0-0000-1000-8000-00805f9b34fb,0000fee7-0000-1000-8000-00805f9b34fb
  Manufacturer = 650b88a0c8478cee29af
  Complete Local Name = JKBMS-Display

cat /data/etc/dbus-serialbattery/config.ini

root@raspberrypi2:~# bash /tmp/install.sh

1) latest release (recommended)	 4) local tar file
2) specific version		 5) quit
3) nightly build
Select which version you want to install and enter the corresponding number [1]: 1
Selected: latest release (recommended)

Found 2 Bluetooth BMS in the config file!

Installing required packages...
Downloading https://updates.victronenergy.com/feeds/venus/release/packages/dunfell/all/Packages.gz.
Updated source 'all'.
Downloading https://updates.victronenergy.com/feeds/venus/release/packages/dunfell/cortexa7hf-neon-vfpv4/Packages.gz.
Updated source 'cortexa7hf-neon-vfpv4'.
Downloading https://updates.victronenergy.com/feeds/venus/release/packages/dunfell/raspberrypi2/Packages.gz.
Updated source 'raspberrypi2'.
No packages installed or removed.
Requirement already satisfied: bleak in /usr/lib/python3.8/site-packages (0.20.2)
Requirement already satisfied: async-timeout<5,>=3.0.0; python_version < "3.11" in /usr/lib/python3.8/site-packages (from bleak) (4.0.2)
Requirement already satisfied: dbus-fast<2.0.0,>=1.83.0; platform_system == "Linux" in /usr/lib/python3.8/site-packages (from bleak) (1.87.5)
Packages installed.

Installing Jkbms_Ble C8:47:8C:ED:06:11 as dbus-blebattery.0
Installing Jkbms_Ble C8:47:8C:EE:29:AF as dbus-blebattery.1
Stopping bluetooth: bluetoothd.
Starting bluetooth: bluetoothd.

SERIAL battery connection: The installation is complete. You don't have to do anything more.

BLUETOOTH battery connection: There are a few more steps to complete installation.

    1. Please add the Bluetooth BMS to the config file "/data/etc/dbus-serialbattery/config.ini" by adding "BLUETOOTH_BMS":
       Example with 1 BMS: BLUETOOTH_BMS = Jkbms_Ble C8:47:8C:00:00:00
       Example with 3 BMS: BLUETOOTH_BMS = Jkbms_Ble C8:47:8C:00:00:00, Jkbms_Ble C8:47:8C:00:00:11, Jkbms_Ble C8:47:8C:00:00:22
       If your Bluetooth BMS are nearby you can show the MAC address with "bluetoothctl devices".

    2. Make sure to disable Settings -> Bluetooth in the remote console/GUI to prevent reconnects every minute.

    3. Re-run "/data/etc/dbus-serialbattery/reinstall-local.sh", if the Bluetooth BMS were not added to the "config.ini" before.

    ATTENTION!
    If you changed the default connection PIN of your BMS, then you have to pair the BMS first using OS tools like the "bluetoothctl".
    See https://wiki.debian.org/BluetoothUser#Using_bluetoothctl for more details.

CUSTOM SETTINGS: If you want to add custom settings, then check the settings you want to change in "/data/etc/dbus-serialbattery/config.default.ini"
                 and add them to "/data/etc/dbus-serialbattery/config.ini" to persist future driver updates.

Sorry but the data you provided is a mess. Please specify the exact version number which is installed and provide the logs in the correct form. Everything is exactly described when you open an issue. Otherwise it's very hard to help you.
Have you tried the latest nightly from the dev branch?


[standalone rcs request]

hey, can anyone link me a standalone rcs , or give me code to paste?

I would code it myself if I wasn't just learning arrays, I'm new to c++ but I intend on improving

https://github.com/danielkrupinski/Osiris/pull/1277
https://github.com/danielkrupinski/Osiris/pull/769

#1277
#769

doesn't work sadly, how can i get it to work

# 1277
# 769

infelizmente não funciona, como posso fazê-lo funcionar?

I can add, discord: MunhoZ # 4150


[vcpkg baseline][openvino] Fix conflict with onednn

Fix baseline Pipelines - Run 20230704.1 (azure.com) ports build error.
D:\buildtrees\openvino\src\d109628fc6-f227b95ee7.clean\src\plugins\intel_cpu\thirdparty\onednn\src\common\c_types_map.hpp(88): error C2065: 'dnnl_eltwise_hsigmoid': undeclared identifier
D:\buildtrees\openvino\src\d109628fc6-f227b95ee7.clean\src\plugins\intel_cpu\thirdparty\onednn\src\common\c_types_map.hpp(89): error C2065: 'dnnl_eltwise_round_half_to_even': undeclared identifier
D:\buildtrees\openvino\src\d109628fc6-f227b95ee7.clean\src\plugins\intel_cpu\thirdparty\onednn\src\common\c_types_map.hpp(90): error C2065: 'dnnl_eltwise_round_half_away_from_zero': undeclared identifier

The onednn code downloaded from the upstream of openvino uses the header file generated by onednn in vcpkg. The two header files are different, so the code in openvino cannot find the required header file:
#include "oneapi/dnnl/dnnl_types.h"

I modified the openvino upstream code to use the include storage path of the onednn generated header file, which is distinguished from the onednn in vcpkg, so that it will no longer find the header file generated by onednn in vcpkg.

Why do you modify onednn, not openvino? Doesn't onednn own include/oneapi/dnnl?

I'm not sure what the correct fix is here, so I submitted https://github.com/openvinotoolkit/openvino/issues/18465 . I think the changes here in effect cause OpenVINO's oneDNN fork to not be used, because their sources say #include <onednn/dnnl.h> rather than #include <openvino/oneapi/dnnl.h>.
We'll see what upstream says. If they must use their forked copy and there's no practical way to do the devendoring we may be forced to remove OpenVINO from the curated registry; oneDNN has been in the registry much longer and has dependents. /cc @ilya-lavrenov

Hi,
There is no way to use official oneDNN for OpenVINO CPU plugin.
Historically (> 5 years ago), oneDNN team were quite slow to accept external contributions, so the fork was created and now it has > 20k lines of difference with official oneDNN.
Maybe the proper solution is to reorganize oneDNN header includes so the "own" headers are taken first? In this case even if we have 2 versions of oneDNN, second one (OpenVINO's) will take its headers and ignore "system" ones.

Maybe the proper solution is to reorganize oneDNN header includes so the "own" headers are taken first? In this case even if we have 2 versions of oneDNN, second one (OpenVINO's) will take its headers and ignore "system" ones.

C++ doesn't work this way; you're breaking the one definition rule here. The result at link time will be some mix of the 'real' oneDNN COMDATs and some mix of your fork's, usually resulting in 'impossible' ABI mismatch crashes at runtime.

Also, maybe you need to think building projects with isolation from others? E.g. Conan creates environment which is required only for this specific package, while Vcpkg exposes everything to everyone.

That we do not do this is an intentional choice, as it makes our results compatible with more build systems without proprietary lock-in.
Moreover, it wouldn't actually fix this problem. OpenVINO and oneDNN are still link-incompatible as described, and no attempt to isolate things while building them fixes the downstream thing exposed to them both.
I'm pretty sure this means our only response is to remove OpenVINO from our curated registry.

Could we disable all components that depend on OneDNN? It seems like OpenVINO is a larger "framework" with multiple plugins.
Users that want those specific incompatible plugins can use an overlay to reenable them.

C++ doesn't work this way; you're breaking the one definition rule here. The result at link time will be some mix of the 'real' oneDNN COMDATs and some mix of your fork's, usually resulting in 'impossible' ABI mismatch crashes at runtime.

Your assumption is that people are using static libraries and link everything together. But what's about dynamic linkage? In this case if we will refactor our oneDNN fork to use its headers first, we can overcome the issue.
Will it work as a some kind of solution?
I fully agree that forks are not great approach to develop software, etc, but the history is more complex than it can look from the first glance. And taking this into account we still want to be a part of vcpkg and ready to perform oneDNN's fork refactoring to mitigate this issue.
Lastly, people who use OpenVINO most likely don't need standalone oneDNN and never face this issue. So, this conflict is synthetic and hard to see in real customer scenarios. Why is it not OK to accept that onednn and openvino ports are incompatible?

Your assumption is that people are using static libraries and link everything together. But what's about dynamic linkage? In this case if we will refactor our oneDNN fork to use its headers first, we can overcome the issue.
Will it work as a some kind of solution?

Yes, it is possible to vendor and completely "hide" a dependency behind a dynamic linking boundary. That is pretty easy on Windows (where all symbols are namespaced to the DLL they come from) and annoying but doable (by changing the default visibility or by marking all symbols in the vendored thing as visibility hidden) on the POSIX platforms.
In my experience though most folks who see what that entails to do successfully decide that getting some form of agreement with upstream on the vendored thing is easier than arranging that situation.

I fully agree that forks are not great approach to develop software, etc, but the history is more complex than it can look from the first glance. And taking this into account we still want to be a part of vcpkg and ready to perform oneDNN's fork refactoring to mitigate this issue.
[...]
Lastly, people who use OpenVINO 99.9% don't need standalone oneDNN and never face this issue. So, this conflict is synthetic and hard to see in real customer scenarios. Why is it not OK to accept that onednn and openvino ports are incompatible?

Sure, if you have erected barriers to ensure things are still link compatible, that's fine with us. Our values are to the integrity of the overall registry over the integrity of any individual component that may wish to be listed there, which is why in general we don't accept "if you install X you can't install Y" relationships. That quickly devolves into schisms where you may as well be operating two registries anyway because half your universe can't be used with the other half.
What do you think of @ras0219-msft 's question?

Yes, it is possible to vendor and completely "hide" a dependency behind a dynamic linking boundary. That is pretty easy on Windows (where all symbols are namespaced to the DLL they come from) and annoying but doable (by changing the default visibility or by marking all symbols in the vendored thing as visibility hidden) on the POSIX platforms.

Sure, we completely hide the static dependencies and their symbols are invisible.

Sure, if you have erected barriers to ensure things are still link compatible, that's fine with us

I will try to fix oneDNN fork compilation with installed standalone oneDNN.

What do you think of @ras0219-msft 's question?

CPU is our main inference device and it depends on oneDNN fork. It's better to fix our fork and enable CPU conditionally only for dynamic libraries case.
I will work on it soon.

Thanks!

I will try to fix oneDNN fork compilation with installed standalone oneDNN.

Thank you! OK, here's what we're going to do:

Add skips for OpenVINO to ci.baseline.txt which will cause it to stop blocking other people's PRs as a result of this conflict.
Check back with you on a regular basis to see how it's going and hopefully do a fix.
If we can't remove the skip in ~a month we'll move to deindexing / suggesting using an alternate registry.

I can probably look at fixing the header only thing (getting the includes to be in the right order so your fork is found rather than the public one...)

@ilya-lavrenov FYI you also might some kind of build race :(
Passes in the build lab with 16c/32t machines but my local 3970X (32c/64t) fails:
[2426/2948] cmd.exe /C "cd . && C:\Dev\vcpkg-downloads\tools\cmake-3.25.1-windows\cmake-3.25.1-windows-i386\bin\cmake.exe -E vs_link_dll --intdir=src\CMakeFiles\openvino.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MIB055~1\2022\ENTERP~1\VC\Tools\MSVC\1436~1.325\bin\Hostx64\x64\link.exe  @CMakeFiles\openvino.rsp  /out:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.dll /implib:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.lib /pdb:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.pdb /dll /version:0.0 /machine:x64 /ignore:4098 /ignore:4286 /nologo    /debug /INCREMENTAL  && cd ."
FAILED: C:/Dev/vcpkg/buildtrees/openvino/src/d109628fc6-ab6debca8f.clean/bin/intel64/Debug/openvinod.dll C:/Dev/vcpkg/buildtrees/openvino/src/d109628fc6-ab6debca8f.clean/bin/intel64/Debug/openvinod.lib
cmd.exe /C "cd . && C:\Dev\vcpkg-downloads\tools\cmake-3.25.1-windows\cmake-3.25.1-windows-i386\bin\cmake.exe -E vs_link_dll --intdir=src\CMakeFiles\openvino.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MIB055~1\2022\ENTERP~1\VC\Tools\MSVC\1436~1.325\bin\Hostx64\x64\link.exe  @CMakeFiles\openvino.rsp  /out:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.dll /implib:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.lib /pdb:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.pdb /dll /version:0.0 /machine:x64 /ignore:4098 /ignore:4286 /nologo    /debug /INCREMENTAL  && cd ."
FINAL LINK: command "C:\PROGRA~1\MIB055~1\2022\ENTERP~1\VC\Tools\MSVC\1436~1.325\bin\Hostx64\x64\link.exe @CMakeFiles\openvino.rsp /out:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.dll /implib:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.lib /pdb:C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.pdb /dll /version:0.0 /machine:x64 /ignore:4098 /ignore:4286 /nologo /debug /INCREMENTAL /MANIFEST /MANIFESTFILE:src\CMakeFiles\openvino.dir/intermediate.manifest src\CMakeFiles\openvino.dir/manifest.res" failed (exit code 1168) with the following output:
LINK : fatal error LNK1168: cannot open C:\Dev\vcpkg\buildtrees\openvino\src\d109628fc6-ab6debca8f.clean\bin\intel64\Debug\openvinod.dll for writing

Don't need to fix that promptly but since I encountered it I thought I'd mention

As this was resolved in another way, I'm closing the PR. Thanks for the help and investigation @JonLiu1993 !


Set up Continuous Integration

We want automated tests because it is the bread and butter of FOSS development :-).

Done! :-)


Cannot see/select data passed the beggining of the new year.

Hello & Happy new year!
How to better start the new year than with a bug ? :)
It seems that data is not being show/selected past the beginning of the new year... So in this case 1/1/2017.
Any ideas why?
I have data in my cluster since (Thu 22 Dec 2016). I can see the timestamp in ES so I'm guessing it could be something with the grafana/grafana plugin ?
BTW: that plugin could maybe get more love...seems. And also what do you guys use for graphing data from heroic api?
Thanks!

Hi,
I was to fast to pull the trigger...seems to be my mistake. I was using points(1d) and data was selected only for 1 day.

ok, thanks!


Extended render buffer to use all GL internal formats

I've applied several changes that aim to bring this pull in line with our coding style and conventions (in particular: whitespace and not using switch expressions), and also improve maintainability (by reordering the enum to match GL ES spec, and also linking said spec in the comment).
@Flutterish if you should want to continue submitting code to this project, I'd ask that you keep in mind our styling conventions instead of using your own.

I've applied several changes that aim to bring this pull in line with our coding style and conventions (in particular: whitespace and not using switch expressions), and also improve maintainability (by reordering the enum to match GL ES spec, and also linking said spec in the comment).
@Flutterish if you should want to continue submitting code to this project, I'd ask that you keep in mind our styling conventions instead of using your own.


Deprecated async_forward_entry_setup

Home Assistant Adaptive Lighting Issue Template
Bug Reports
Logger: homeassistant.helpers.frame
Quelle: helpers/frame.py:189
Erstmals aufgetreten: 17:46:22 (1 Vorkommnisse)
Zuletzt protokolliert: 17:46:22
Detected that custom integration 'adaptive_lighting' calls async_forward_entry_setup for integration, adaptive_lighting with title: Wohnzimmer and entry_id: 48a7cf86e86966c728032c6b8ed0b190, which is deprecated and will stop working in Home Assistant 2025.6, await async_forward_entry_setups instead at custom_components/adaptive_lighting/init.py, line 69: hass.async_create_task(, please create a bug report at https://github.com/basnijholt/adaptive-lighting/issues

Steps to reproduce the behavior:
Install 2024.11.0b1 and you this message in logs

I can confirm this warning started appearing in 2024.10.

Duplicate of #1020 ?


Update notes on what Firefox does, at least as of version 43 (decembe…

…r 2015)
It looks like Firefox does the same thing that Chrome does in almost all cases. The only difference (according to your notes, I didn't verify) is that window.innerHeight is updated continuously in Chrome but not in Firefox.

Thanks for the update!


Build against newer GGML version

[x]  Update llama.cpp and include ggml-alloc during binding generation
[ ] Switch to new graph-alllocator
[ ]  Ensure CPU inference works
[ ] Ensure Cuda inference works
[ ] Ensure OpenCL inference works
[ ] Ensure Metal inference works

CPU inference seams to work, at least for llama. Cuda/OpenCL are currently broken.

As requested:
llm # git log --pretty=oneline
78b0e25c7164cfa9e56cf6ac648e803432d5a0aa (HEAD -> feat/ggml-update, llukas22/feat/ggml-update) Scope `input_length` and `session_len` to `BuildContext`

llm # cargo run -r infer -a llama -m models/llama2/dolphin-llama2-7b.ggmlv3.q4_K_M.bin -p "Testing 123: "
   Compiling ggml-sys v0.2.0-dev (llm/crates/ggml/sys)
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
...
    Finished release [optimized] target(s) in 10.26s
     Running `target/release/llm infer -a llama -m models/llama2/dolphin-llama2-7b.ggmlv3.q4_K_M.bin -p 'Testing 123: '`
✓ Loaded 291 tensors (4.1 GB) after 131ms
zsh: segmentation fault  cargo run -r infer -a llama -m  -p "Testing 123: "

llm # cargo run -F metal -r infer -a llama -m models/llama2/dolphin-llama2-7b.ggmlv3.q4_K_M.bin -p "Testing 123: " --use-gpu
   Compiling ggml-sys v0.2.0-dev (llm/crates/ggml/sys)
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
warning: clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
   Compiling ggml v0.2.0-dev (llm/crates/ggml)
   Compiling llm-base v0.2.0-dev (llm/crates/llm-base)
error[E0425]: cannot find value `scratch` in this scope
   --> crates/llm-base/src/inference_session.rs:172:28
    |
172 |                 for buf in scratch.iter() {
    |                            ^^^^^^^ not found in this scope

error[E0308]: mismatched types
   --> crates/llm-base/src/inference_session.rs:298:34
    |
298 |                     plan.execute(ctx0);
    |                          ------- ^^^^ expected `&mut Vec<u8>`, found `&mut Context`
    |                          |
    |                          arguments to this method are incorrect
    |
    = note: expected mutable reference `&mut Vec<u8>`
               found mutable reference `&mut ggml::Context`
note: method defined here
   --> llm/crates/ggml/src/lib.rs:355:12
    |
355 |     pub fn execute(&mut self, buffer: &mut Vec<u8>) {
    |            ^^^^^^^

error[E0308]: mismatched types
   --> crates/llm-base/src/inference_session.rs:302:30
    |
302 |                 plan.execute(ctx0);
    |                      ------- ^^^^ expected `&mut Vec<u8>`, found `&mut Context`
    |                      |
    |                      arguments to this method are incorrect
    |
    = note: expected mutable reference `&mut Vec<u8>`
               found mutable reference `&mut ggml::Context`
note: method defined here
   --> llm/crates/ggml/src/lib.rs:355:12
    |
355 |     pub fn execute(&mut self, buffer: &mut Vec<u8>) {
    |            ^^^^^^^

Some errors have detailed explanations: E0308, E0425.
For more information about an error, try `rustc --explain E0308`.
error: could not compile `llm-base` (lib) due to 3 previous errors

Thanks for the quick test, i don't think i can debug that as i can't reproduce it. The failure with metal enabled is expected as i don't have touched any of the accelerators yet. I think i will focus on getting Cuda and OpenCL functional again.

Sounds good to me - I'll see if I can make some time to push the macOS effort forward, but I suspect I'm going to be really busy for the next week or two 😓
Awesome work so far, though! Let me know if you need me to look at/consult on anything, but everything looks great so far.

The test I did earlier on macOS now works after pulling in your latest changes. I'll fix Metal soon - I'm hoping that it shouldn't be too bad. After that, I'll check each architecture with {CPU, CUDA, Metal}. Maybe OpenCL, but that's honestly kind of a pain to test - might just bounce it against the CI and hope for the best.
I may also try to use this PR to update to the latest version once more, but it'll depend on how large that change is. I want to keep the diff small so that I can get this in before #412 and not have to resolve too many merge conflicts - we'll see how we go!

I think i stopped implementing this as i got a lot of "memory access errors" while i tried to get cuda working. I guess CPU inference should work, but i kind of gave up on getting CUDA o work as its just very difficult to debug into GGML from the rust side. Especially the CUDA bits.

Yeah, understandable - it’s very difficult to debug. I’m out of town for the next few days, but I’ll get back to it after that.

Take your time. I will probably focus on getting the quanitzed cuda kernels working in candle over the weekend.