Take Scala standard in spark support

This pull request includes following fix:

Avoid procedure syntax method declaration

Because it brings potential of bug in the future code change. Procedure syntax is deprecated currently in the Scala standard and it will be removed in the future version of Scala.

Avoid unnecessary return statement

return is translated into throwing an exception (and catching it) by Scala compiler, so we shouldn't use it in the performance reason. Also compiler can't inference a return type of the method if return is being used in the method.

Avoid unnecessary while loop and mutable variable

Typically, we can write code safer by using immutable variables. while loop depends mutable flags in many cases, but it can be replaced with other way in Scala. It makes possible to eliminate mutable flags.

And I have questions about code in ScalaValueReader.scala, so I added inline comment to that code.

Thank you for submitting a pull request!
Please make sure you have signed our Contributor License Agreement (CLA).
We are not asking you to assign copyright to us, but to give us the right to distribute your code without restriction. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code.
You only need to sign the CLA once.

[x] I have signed the Contributor License Agreement (CLA)

@takezoe thanks for the PR! I've been looking through the changes the last few days whenever I've had time. I'd like to do some digging regarding those confusing null value returns before merging, but it might take a little while with my schedule. Just wanted to pop in and give you a heads up about the status of the review. The changes look great so far!

@jbaiera Thanks for your comment. I'm trying to eliminate remained return statements, but it will take a while, so I will send them as a new pull pull request after this request is merged.

@jbaiera I pushed more fix, and add a comment to the line that looks like a bug. Hope you will check them.

Given the nulls might be a potential bug, maybe it is worth investigating?

Hi @jbaiera, what's the status of this pull request?

Hi @takezoe, I'll be getting a proper review here very soon. My attention has been allocated toward other things at Elastic for the last month or so, but will be hopefully freeing up here in the next few days to return to here and clear out the backlog of things that need review. I seriously appreciate your patience on the matter!

@jbaiera Thanks, no problem if there are nothing blocking this pull request for now.

@takezoe How did you end up tracking down all of these problems? I'm wondering if there's a way to establish a build check to make sure these sorts of problems don't arise during regular development going forward, like a code analyzer or setting the compiler to error on syntax warnings.

@jbaiera In fact, I found out them by my eyes. There are some lint tools for Scala but almost of them are provided as sbt plugin, so they can't be used in Gradle.
However Scala compiler has some options to print warnings, it's might be helpful to find parts of these problems. Perhaps it's possible to enable these options in Gradle as well. I will raise an another pull request to update Gradle configuration to specify Scala compiler options.

I created a new request to add Scala compiler options as #964.

@jbaiera Thanks for your review. All fixed and changed the pull request target to 5.x branch.


Navbar

Looking good. However, needs to use and import the themePalete.css file. Then use the classes from it.

Great work @dinadeljanin !!!


multi-page layout error

I'm getting some weird results when trying to run this to create some multi-page layouts.
ive attached an example input/output.
SVGnest-output sample(1).zip

hm.. I can't seem to replicate the problem.
which browser are you using? does it do this every time or only sometimes?


Update for [DBSubnetGroup] Remove validation on DBSubnetGroupName #537

Hi Team,
Is there any update yet regarding this pull request?
https://github.com/aws-cloudformation/aws-cloudformation-resource-providers-rds/pull/537/files

@zrfr Thanks for following up. Is there anything the customer can do as a workaround for now?


Heroku app doesn't sleep

I don't need the heroku app to run 24/7... why doesn't it sleep whenever people don't visit the link after an hour? Really degrades the purpose of the login page because it shuts off for six hours while the heroku app recharges, and there's no way to warn people that the page will be down.

How do you know people haven't visited the link in half an hour? Do you know what it's doing to cause Heroku not to put it to sleep?

Maybe it's because it polls the channel? You could set that to be >30minutes with this command line option or environment variable:
-i, --interval        How frequently (ms) to poll Slack [$SLACK_INTERVAL or 5000]

As long as people leave the web page open, the browser will connect to update the current users online number. Disabling that to support new Heroku free dynos sounds like a good enhancement request.

Maybe bots are indexing this page.
Is it enabled by default?


GHA tests Python 2.7 on Windows

Hum, it doesn't work. I tried to automate tests for https://github.com/pythoncapi/pythoncapi_compat/issues/16


Server is currently unavailable. Please try again later

Hey, I'm in Australia and the code works for a friend of mine in Canada, but I get this error when I run it. Is it something on TikToks backend that's not working or am I doing something wrong. When I click the link on chrome I get sent to a white page with this text "Server is currently unavailable. Please try again later". But when I click it on firefox its a white background.
============Start uploading video===========
C:\Users\AppData\Roaming\Python\Python310\site-packages\urllib3\connectionpool.py:1045: InsecureRequestWarning: Unverified HTTPS request is being made to host 'tos-awsuseast19-up.tiktokcdn.com'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/1.26.x/advanced-usage.html#ssl-warnings
warnings.warn(
============Video uploaded successfully===========
============Publish failed===========
[-] An error occured while reaching https://www.tiktok.com/api/v1/web/project/post/
r = <Response [200]>
r.content = b'{"log_pb":{"impr_id":"202307100122452E3962ECA6B41833A22F"},"status_code":4,"status_msg":"Server is currently unavailable. Please try again later."}'
PS C:\Users\Desktop\Tiktok Software\Tiktok-AI-main>

I think it's because the script sent the post command too early when Tiktok was still converting the video.
Another possibility is that the CDN region of tiktok US is US-TTP (check the request header on chrome dev tool) and not just ap-singapore or ap-useast.

oh that makes sense I forgot cookies are brower specific thank you so much


integrate with GoDaddy

How can I integrate an SDK and API into my GoDaddy website?

Hi @Ahmedeissagom, I saw that you can add personalized JavaScript and HTML to you GoDaddy website, and with that you can use our SDK with CDN.
One of the options to use our SDK, besides using it as a package, is usage with a Content Delivery Network, or CDN. This means that you are importing our SDK with a script tag. You can do that with the following line added to your HTML (we recommend adding it inside the <head>):
<script type="module" src="https://unpkg.com/@superviz/sdk@latest"></script>

We have a dedicated page on our documentation with detailed instructions on how to use our SDK as a CDN, including the technical differences from using it as a package, and how to adapt the examples and explanations given in this documentation for a CDN context.
I invite you to use our Discord server, so I can better assist you if you'd need anything else.


Thread manager fixes/refactoring

Fix a case whereby we waited one full cq timeout before ending a thread
Pull down max_pollers to a more reasonable number
Increase CQ timeout to avoid thrashing (since we can now)
Avoid holding a lock whilst spawning threads (this was leading to large contention)
Be lazier about getting below max threads to avoid thrashing
Combine control logic into one function to make it easier to inspect at a glance

No significant performance differences

Failed: #10180

No significant performance differences


Hardcoded number of viewlets in CSS

https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/explorers/media/treeExplorer.contribution.css#L16
For one, this contribution shouldn't reach out to the activity bar like that at all. Second, why is that nth-child(n+6) in there? It hardcodes the number of non-contributed viewlets we currently have.

This should probably be revisited when we implement contributed viewlets to show up below a separator in the sidebar. Still needs UX discussion if we want to go with that approach but looks like  it.

I have removed this CSS hack and verified that the contributed icon looks good as long as it follows our spec.
@octref I suggest you update the custom explorer examples icons.

@bpasero Sure. Wondering where is the spec you are referring to?

I just copied one of the existing icons we had and tried. They seem to have a white background fill.


Validate provided checksum after successful import

Use the 'checksum' hash value in the yaml files to verify the image integrity after it has been successfully imported. Show a warning, if either the hash algorithm or the hash value does not match the expected fields.

[x] Deactivate broken image / deactivate cycle process
[x] unit test

Fixes #340

With the use of the web_download mechanism of Glance images are usually not downloaded by the image-manager but by Glance itself. I'd refrain from adding any code that would download images and requiring enough bandwidth or even disk space to hold them temporarily.
@gndrmnn  did you see my comment at https://github.com/osism/openstack-image-manager/issues/340#issuecomment-1471721379 ? in short: Glance does already produce hash values, it's just that this is done with a single fixed hash algo for all images and it cannot be chosen per image.
I suggest to try and extend the import call of the image API (https://docs.openstack.org/api-ref/image/v2/index.html?expanded=import-an-image-detail#import-an-image) to optionally give it a hash algo to use for the checksum. Then you get the image downloaded by Glance and the hash created by Glance and can simply compare it by fetching the image details.

@frittentheke Hi,

With the use of the web-download mechanism of Glance images are usually not downloaded by the image-manager but by Glance itself. I'd refrain from adding any code that would download images and requiring enough bandwidth or even disk space to hold them temporarily.

 The change in that file will result in all ymls containing a sha-512 going forward, but they will be "pre-computed" for the average user.

@gndrmnn did you see my comment at #340 (comment) ? in short: Glance does already produce hash values, it's just that this is done with a single fixed hash algo for all images and it cannot be chosen per image.

Yes, I read this. In fact, we compare the (in the future existing) SHA-512 contained in yaml files with the hash that glance computes when importing the image (i think that is how it works?). The imported_image in this call is already the representation of the Image object in openstack, which contains the hash that glance presumably calculated.

I suggest to try and extend the import call of the image API (https://docs.openstack.org/api-ref/image/v2/index.html?expanded=import-an-image-detail#import-an-image) to optionally give it a hash algo to use for the checksum. Then you get the image downloaded by Glance and the hash created by Glance and can simply compare it by fetching the image details.

Yes, that would also be possible. It was discussed with @berendt that we simply recompute the hash values for all image yml files at "image update time". But let's keep the PR on hold until @berendt is back from vacation and gives some input.

@frittentheke This was discussed with @berendt and it was decided that we implement this PR as is. The hash values in the yaml files will be pre-computed by the GitHub/Zuul Pipeline and not on the user side. The main advantage of this method is that we can implement it right now.
However, your suggestion to enhance the upstream API can still be applied later as a separate feature. That would allow Glance to throw away any corrupt image before it even "reaches" the backend. I will open a separate issue for that.

I'm wondering whether the file should be downloaded AFTER the filename is determined (after the whole HEREBE DRAGONS stuff). Or am I missing something? Also, I would actually keep track of the original hash as well, so that the file need not be downloaded every time the Github action runs. Naturally, I'm volunteering to make the changes I propose, and also to rebase to the outcome of https://github.com/osism/openstack-image-manager/pull/647 :)

I'm wondering whether the file should be downloaded AFTER the filename is determined (after the whole HEREBE DRAGONS stuff). Or am I missing something?

If I understand you correctly, it should make no meaningful difference at which of those two points in time the file is downloaded and hashed.

Also, I would actually keep track of the original hash as well, so that the file need not be downloaded every time the Github action runs

Right, that - or some other mechanism - would make sense to safe some bandwidth. We will consider how to best implement that.

Naturally, I'm volunteering to make the changes I propose, and also to rebase to the outcome of #647 :)

No, it's fine we got this. We might come back to ask some questions about #647 if need be later on though :)

@gndrmnn

If I understand you correctly, it should make no meaningful difference at which of those two points in time the file is downloaded and hashed.

Maybe I got it wrong myself, but in my understanding, the filename is not even known in advance for certain distros.
The latest_url for CentOS Stream 8, for instance, is given as https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-HEREBE\d+\.\dDRAGONS.x86_64.qcow2. When I try do download that, I get a HTTP response code 404. The actual filename has to be determined using the checksums file first to arrive at https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20230904.0.x86_64.qcow2, which can then be downloaded.

@gndrmnn

If I understand you correctly, it should make no meaningful difference at which of those two points in time the file is downloaded and hashed.

Maybe I got it wrong myself, but in my understanding, the filename is not even known in advance for certain distros.
The latest_url for CentOS Stream 8, for instance, is given as https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-HEREBE\d+.\dDRAGONS.x86_64.qcow2. When I try do download that, I get a HTTP response code 404. The actual filename has to be determined using the checksums file first to arrive at https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20230904.0.x86_64.qcow2, which can then be downloaded.

Ah right, yes. That indeed needs to be taken care of. Thanks for pointing that out.

@mbuechse I would kindly ask you to review this Merge Request as you are most familiar with the refactored update.py :)
The current iteration of this MR adds an additional field to the yaml schema which contains the sha512 of the actual image. Therefore, we can use the other existing hash to check if a new version was released. Also the filenames are resolved first now. I'd say it makes sense to review the commits individually.

@gndrmnn I've been ill. I will certainly have a look one of the next few days.

Why on earth did the PEP8 issues not trigger the Flake8 test?? :thinking:

Why on earth did the PEP8 issues not trigger the Flake8 test?? 🤔

Maybe your fork somehow didn't include the CI triggers?

Why on earth did the PEP8 issues not trigger the Flake8 test?? 🤔

Maybe your fork somehow didn't include the CI triggers?

Nope, the flake8 test in osism/zuul-jobs did not have the recurse flag enabled for the "Find .py files" job.  Which means that in all osism repos only py files located in the repo root are being tested with flake8 :D
Working on a fix fo osism/zuul-jobs now...

Thanks @mbuechse and thanks @gndrmnn for following up to find why this was not caught by CI. With that result this is a very useful finding.

recheck


Access Denied error due to race saving cache file on Windows

In pypa/setuptools#4467 and businho/pytest-ruff#28 and this Discord convo, I've captured an issue that's recently become apparent when pytest-ruff started failing on an exit code 2 (pytest-ruff 0.4).
In a test environment utilizing pytest-ruff and pytest-xdist, many tests will be run in parallel and since pytest-ruff passes each file to a separate ruff invocation, there may potentially be many instances of ruff launched for the same root directory and settings (and thus cache key).
As a result, Ruff will fail and exit with code 2 with the following output:
            Cause: Failed to rename temporary cache file to D:\a\setuptools\setuptools\.ruff_cache\0.5.1\13567325068112760734
            Cause: failed to persist temporary file: Access is denied. (os error 5)
            Cause: Access is denied. (os error 5)

Since it's a cache file, maybe the failure should be ignored, or maybe it could be retried.
At the very least, catching this error and exiting with a distinct exit code would allow tools like pytest-ruff to ignore the failure.

My guess is the same behavior is happening on Linux too, but the file system allows the race to be resolved by replacing the file. Maybe there's a Windows file operation that's comparable.

Yeah my guess is we're trying to replace the file while it's being read.

My vote would be to make these non-fatal, and warn. Cache errors should generally be non-fatal IMO.


fix(sql):backport the security patch of CVE-2024-43406

Here is a vulnerability which is fixed in the master branch (https://github.com/lf-edge/ekuiper/commit/1a9c745649438feaac357d282959687012b65503) but is not fixed in the branch of master-1.13, maybe it should be backported?

We only maintain the latest version (1.14.x now) as usual. Recommend to upgrade instead of stay in 1.13. Any reason to port to 1.13.x?

If you're still using 1.13.x and willing to maitain issues like this, we are more than happy to merge and publish new release. Thank you. Please check the DCO details link to sign off.

I see here is an error for build-for-android, what does it mean? I don't modify the code it mentioned, how can I fix it?

It fails due to dependency version updates. Just ignore it now.

@Crispy-fried-chicken  The build-for-android fail can be ignored now. However, the UT error should be fixed. Please kindly take a look.


Updating to latest typescript, ts-loader, and fork-ts-checker-webpack-plugin

Updating the razzle-plugin-typescript package
Updating versions of typescript, ts-loader, and fork-ts-checker-webpack-plugin for the razzle-plugin-typescript package.

tslint is deprecated in favor of eslint. tslint is not maintained anymore read more here
tsc compile watch: there's no changes
the new options for fork-ts-checker can be found here

(I'm not sure if there's any specific default ones you want to have besides the files that should be linted)
Test

run the npm test in the packages/razzle-plugin-typescript folder

I am considering dropping this plugin since razzle 4 will support ts natively.

I am considering dropping this plugin since razzle 4 will support ts natively.

That is great news. What's the timeline on it?! I've been eyeing the next and next-awesome branches.

Released a finch release now
https://github.com/jaredpalmer/razzle/releases/tag/v4.0.0-finch.2
Note: expect bugs ;)

Can you do this based on the finch branch?

@fivethreeo I found some additional changes I need to make. I will get these done right away.

@fivethreeo all done.

What changed in ts checker options wrt. tslint/eslint/watch?

@fivethreeo

tslint is deprecated in favor of eslint. tslint is not maintained anymore read more here
watch there's no changes
the new options for fork-ts-checker can be found here (I'm not sure if there's any specific default ones you want to have besides the files that should be linted)

But does this take jsconfig/tsconfig files into account? It should work with existing projects using this plugin preferably. But if we need to break it, now is the time ... So would a tsconfig/jsconfig with compileroptions.paths work? For example.

@fivethreeo yes tsconfig is supported. I can make it much clearer, and add test for it also.

Could you make files a glob with './src/**/*.{ts,tsx,js,jsx}'  ?

And set context and configFile in typescript options.

I am considering dropping this plugin since razzle 4 will support ts natively.

Babel preset typescript does not support advanced features of typescript, such as const enums and decorators, for decorators are some workaround plugins that work, but they are buggy. Personally I'm still use razzle-plugin-typescript in addition of new babel preset razzle. For projects that only write client code and simply have a express backend to send the ssr result, babel-plugin-typescript do the job, but, for people who use nestjs in backend or another type of dependency injection, this plugin still needed

Will not drop the plugin :)

Um, finch branch is now canary, can you do this against canary?

I am unable to reopen this pull since the branch is gone. Hrm @github

@fivethreeo I have PR locally I will recreate against canary.

@fivethreeo @ceopaludetto see: https://github.com/jaredpalmer/razzle/pull/1435


Revisit the explanation of parametricity & polymorphic argument as in Listing 2.1

https://forums.manning.com/posts/list/36349.page#p101487 .. Maybe explain the diff between subtyping and parametric polymorphism from Scala point of view.

Nothing to fix .. closing


Window position and sizing

This pull request adds the methods for positioning and sizing a Window as spec'd by the window_switching_spec. This fixes #54.
Note that the window_switching_spec required modifications to verify that these tests pass. The spec has windows being located using two parameters (how, what) as opposed to a single hash. The window method currently only supports a single parameter, which causes the test failures. An additional pull request will be created to address this other issue.

Closing this due to inactivity.


Merge tests and load Json from files

This merges the tests for the SaltStackParser class together into on class.
In addition to that i put the json in files with proper formatting so it is easier edit and verify those strings.

Very good, thanks again for this contribution.


Aria role listbox not suitable for Carousels

The argument has been made here:
https://github.com/twbs/bootstrap/issues/22061

There is a discussion going on in the PR.  Unlike bootstrap's carousel, our carousel captures keyboard events so you can use the left and right arrows to navigate.  When you assign event handlers like onkeydown and onclick to a non-interactive HTML element, like a div, then Aria requires that you assign the element a role.  At least that's my understanding of WCAG.
listbox seemed like an option because you can tab to each visible slide in the slider.  However, the audio that is read by a screen reader is a little misleading.  It speaks of "options" to select.  There's no options.
If anyone has an idea of which role we should use in this situation, please speak up.

How you guys looked at role: grid? Seems to be the catch all of ARIA widget roles. https://www.w3.org/TR/wai-aria-1.1/#grid

Into the rabbits hole we go... found this recent conversation:
https://github.com/w3c/aria-practices/issues/43

@bluSCALE4 it does look like they are including the spec. I am reviewing their carousel recommendation here https://www.w3.org/TR/wai-aria-practices-1.1/#carousel. I don't think it is final yet.

It is also important to note that many developers will over use a slider, not as a pure carousel but as a means of selection (ex: a product that has 10 different colors) in this case your list box maybe useful. Also if it is required that a selection be made then maybe even role="radiogroup" to help convey that this is part of a form selection.
There is also possibilities of expanding the useful meaning of the buttons for screen readers (ex: next button should read "Next 3 of 10" or however many slides as visible VS remaining) Same for previous first and last."First 1 of 10" /  "Last 10 of 10"
Also usage of tab seems to be throwing the slider off. In your demo of "Simple Carousel With React Redux" attempt to only use the tab key to move through the slides. The proper order should be Slide 1,2,3 then Next arrow. However as you can see the tab order continues to push the slider all the way through the slides before ever getting to the next button. Even then when the user reaches the next button they do not know they are at the end of the ordered list because the next button is still a valid button. Usage of aria-hidden=true/false and tabindex=0/-1 will keep the hidden slides  out the tab order.
Good luck!

As this doesn't currently have a clear solution, might it make sense for now to default torole="listbox" (remaining consistent with the current implementation, but to permit passing in props to override it (e.g. if their use case matches different guidance)? Currently it's not possible to override. Similarly, perhaps the aria-roledescription could be passed through to the element?

@hcientist would you be open to making a Pull Request for making it possible to override? @kylane mentions in Issue #315 the ability to override aria props, so it looks like it something that has support.

Where have we landed on this one? Removing role="listbox" seems to be a good start or giving us a way to overwrite it.

We found a very basic workaround to solve these issues for our purposes.
Without going into too much detail on how the roles work, for us, it was enough to make this work with role="listbox". This change did it for us.
            {/* Adding role={undefined} and trayProps={{role: 'listbox'}} fixes an issue
                with accessibility. Basically, the role attribute was on the wrong element.
                The role 'listbox' needs need wrap direct decedents with the role 'option'.
                We hope that this gets addressed by the library soon. */}
            <Slider
                aria-orientation={carouselState.orientation}
                aria-labelledby={carouselId}
                classNameTrayWrap="carousel-tray-wrapper"
                role={undefined}
                trayProps={{role: 'listbox'}}
            >
            ...
            </Slider>


Deployment of v5-rc0 namespaceScope: true crashes

I've deployed the operator like so:
helm upgrade --install grafana-operator --values=/opt/k3s/grafana-values.yml oci://ghcr.io/grafana-operator/helm-charts/grafana-operator --version v5.0.0-rc0 --namespace grafana
The grafana-values.yml file has all the defaults except namespaceScope: true and a node selector (which works, the operator pod is started on the right node).
The pod starts and keeps on running for a while, but has a lot of errors and then at some point it crashes and is restarted by K3s.
I am attaching the log output.

crashlog.txt

Hi @realulim , thanks for trying out the new version.
So the error is rather simple but it could probably be even clearer in the documentation.
Look at https://grafana-operator.github.io/grafana-operator/docs/installation/helm/#values and you will see
watchNamespaces
Sets the WATCH_NAMESPACES environment variable, it defines which namespaces the operator should be listening for. By default it’s all namespaces, if you only want to listen for the same namespace as the operator is deployed to look at namespaceScope.

So you need to define WATCH_NAMESPACE to the namespace that you want to use and I think it should work.

Thank you very much for your help and explanations. I have now configure namespaceScope: false and watchNamespace: "grafana" and installed the operator in the namespace grafana. It seems to start ok now, but there is a warning message in kubectl describe operator-pod that says:
Warning  Unhealthy  3m49s (x2 over 3m50s)  kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:8081/readyz": dial tcp <IP_ADDRESS>:8081: connect: connection refused

Strangely, that did not work:
anaFolder: grafanafolders.grafana.integreatly.org is forbidden: User "system:serviceaccount:grafana:grafana-operator" cannot list resource "grafanafolders" in API group "grafana.integreatly.org" at the cluster scope
It did work before with namespaceScope: false

If the readiness probe will only work once Grafana has migrated its database, then that would the reason for it failing. I haven't yet been able to install the tables due to db permission errors. The liveness probe appears to work and it goes to the same IP address.

So I have found the issue with the helm chart the env variable should be WATCH_NAMESPACE and not WATCH_NAMESPACES.
When I fixed this, the operator stopped complaining about rbac rules.
I have created a PR to fix this issue.

About the 3 replicas of grafana, I personally don't use postgress with my grafana instance so I can't say I have tried it out. But to my knowledge there have been other people that have used the operator with multiple replicas of grafana together with postgres with the old version of the operator. But since all we do with the operator is to start the grafana instance this sounds like a grafana issue and not operator issue.
I would recommend opening a grafana issue and ask them for input on your issue.
I will close this issue when the PR is merged.

Thank you very much. Of course there is an easy workaround: deploy 1 instance and then later upgrade to 3. So it is not a critical problem during initial installation.
That being said, the problem applies to all backend storages, not only PostgreSQL. Grafana creates its tables and data when it first starts and if you have multiple instances starting at the same time, they can overwrite each other. So in that sense the operator allows to do something that Grafana itself doesn't support. And if the operator progresses to the next capability levels ("seemless upgrades", "full lifecycle") it may well have to deal with this issue. I don't know what happens during Grafana upgrades, but I suppose they could have another database migration script. And then it will be critical, because a production database could be destroyed. Yes, they should have a lock table for their migration scripts like Liquibase or similar tools do it.

Hi @realulim , this should now be fixed and should be released soon.
I will close this issue.
If you want to give it a try you can do so by doing a local helm install.


File Write and Close or Unlink gives -22 error code

When I perform many file writes, like 300 or so(the amount seems to be random), it stops being able to write the files and once I close it, I get a return code -22, which means invalid arguments. I get the same error code when I call an fs_unlink function, so in essence I have the Flash bricked as long as this error occurs. All flash operations takes many seconds, when I was writing about 12 bytes it took 14s, now I'm writing 120 bytes and it takes 120s more or less. The weird part is that after good while, previously it was 1h, but now it seems like 3 hours(could be a number of writes and now it takes longer since the writes take longer) it just starts working again like it was nothing. An important info is that the flash is not filled, it has 2MB, and 300 120 bytes files only gives 36000 bytes. I have already posted about this issue on the nordic devzone forum about it on (https://devzone.nordicsemi.com/f/nordic-q-a/97005/file-delete-in-littlefs-results-in--22-error).
Expected behavior
I expected to write, close and unlink files without getting any error codes.
Impact
It completly ruins the device, as I'll lose a lot of data during the 3 hours it doesn't function, and pretty much stops our project
Logs and console output

Using a logic analyser I got some readings of the SPI, but they weren't very precise and muy analyser isn't very good so I can't get good readings as it times out frequently.
The prints that are "something:" -22 are my process to track down the function originating the -22 error code (I had to do it manually as VScode is not cooperating in navigating through the files), in the end I got down this track:
fs_unlink()
lfs_dir_commit()
lfs_orphaningcommit()
lfs_dir_relocatingcommit()
lfs_dir_splittingcompact()
lfs_dir_split()
lfs_dir_alloc()
lfs_bd_read()
lfs->cfg->read()
I couldn't find the function after that point, as it gets to the api struct and I don't know what it calls.
Enviroment
-OS: Windows 11
-NRF Connect SDK v2.3.0 and v2.2.0, happens on both
-nRF52832 as the processor
-mx25r1635f as the external flash
-littleFS on the the external flash
-The problem happened on the 6 boards tested up to now

Will take a look.

@BenjamimKrug there are quite some limitations in using littlefs. IIRC each file requires a complete eraseblock for storage, as your device only has 512 blocks (and maybe not everything is available for littlefs) you will be reaching this limit very easily. I think there are several of these problems reported on the littlefs github.

BTW, is #54779 still open ?

@Laczen, yes #54779 is still open, and if you are correct about reaching the max number of files due to the number of blocks available, that problem would be the one I'd have to fix.
@nordicjm I'll set the debug level and send it here.

@Laczen, yes #54779 is still open, and if you are correct about reaching the max number of files due to the number of blocks available, that problem would be the one I'd have to fix. @nordicjm I'll set the debug level and send it here.

You are probably having the same issue, but now reading on a out of range address. You will need to provide full setup details (dts, ...) as it was impossible to reproduce #54779.

@BenjamimKrug, while going over #54779 again I noticed that your device is a 16Mb device but you are declaring a partition of 16MB, you need to reduce the storage partition:
lfs1_part: partition@0 {
			label = "storage";
			reg = <0x00000000 0x1000000>;
		};

needs to be:
lfs1_part: partition@0 {
			label = "storage";
			reg = <0x00000000 0x200000>;
		};

The startup debugging for the littlelfs setup is crucial: always report the result of the mount:

shows that there is something wrong with the setup, your device does not have 4096 blocks of 4096 bytes.

I hope you understand why it is important to share details about your setup.


NPE IN 1.14.4-1.4.5

1.4.4 doesn't have this issue on the client.
client crash report: https://gist.github.com/73766ceefefd870c5814cd114600a1ca
client latest.log: https://gist.github.com/kreezxil/3f7bcf68400d332e7f0561b726fde546
client minecraft: 1.14.4
client forge: 28.2.0

Alright I couldn't replicate the crash but it seems its just giving an NPE for the team id nbt capability, I changed the default value from null to an empty string so hopefully that fixes it


Unsupported Model.Model Name: 'gpt-35-turbo' Model Version '0613'

Hi! The app is up and running. I however get the following error when sending a question:
Object { error: {…} }

error: Object { requestid: "5200e24d-e577-4328-9f8c-b4df9ed1f192", code: 400, message: "Unsupported Model. Model Name: 'gpt-35-turbo' Model Version '0613'. Please retry with supported model: gpt-4-32k (0314),gpt-35-turbo (0301),gpt-4 (0613),gpt-4 (0314),gpt-35-turbo-16k (0613),gpt-4-32k (0613)" }

code: 400

message: "Unsupported Model. Model Name: 'gpt-35-turbo' Model Version '0613'. Please retry with supported model: gpt-4-32k (0314),gpt-35-turbo (0301),gpt-4 (0613),gpt-4 (0314),gpt-35-turbo-16k (0613),gpt-4-32k (0613)"

requestid: "5200e24d-e577-4328-9f8c-b4df9ed1f192"

It looks like this when I inspect the webpage in the console:

Seems like a a matter of selecting the right OpenAI deployment for chat. I have a deployed gpt-4 0613. Can I set this variables:
https://github.com/microsoft/sample-app-aoai-chatGPT/blob/354b62b3485ce8270798dd625c4ce904bd311695/app.py#L50
https://github.com/microsoft/sample-app-aoai-chatGPT/blob/354b62b3485ce8270798dd625c4ce904bd311695/app.py#L60
through the azure cli? How do I do that if I don't have a project? I am kind of lost :sweat_smile:. Any hints?

I just updated the web app ("Update an existing web app") with the updated OpenAI model and searchindex. Everything works :smile:


Example available for AppCenter.Distribute with WPF?

Hi!
First of all I want to thank you for this great tool. The Crashes and Analytics module have already spared me lots of frustration and tedious debugging time :-)
Now I would like to take my WPF app a bit further. With Azure pipelines, I have set up a chain where a msi is created and deployed to AppCenter. Users in the distribution list get an email that a new version is available, which is great. However: Can the WPF app auto-detect updates via the AppCenter.Distribute package? I can't really seem to find a good example/walktrough for this on the documents page or anywhere else...
if I try this:
Distribute.SetEnabledAsync(true)
the Enabled property stays false..
Can someone guide me in the good direction?
Thanks for the help!

While I wait for this to be put on the road map...
I will:
copy my msix and appinstaller files to a web site and allow users to install the app from there.
[https://github.com/Squirrel/Squirrel.Windows/blob/develop/docs/getting-started/0-overview.md](Auto-Update using wither Squirrel.Windows (https://github.com/Squirrel/Squirrel.Windows))
or
https://winsparkle.org/

@TheElectricCo Does this example from the appcenter-sdk-dotenet project work as the requested example?

Hi @OzBob ,
not sure where to look. In the WPF demos I don't immediately see an implementation of the in-app updates (or I am looking over it, it is still morning). Can you point me where to look in the example?
Thanks,
Lens

Hi Lens/ @TheElectricCo
my bad, the example doesn't have auto-update.
I am investigating win.sparkle and windows.squirrel  as packages to make my own.
I am searching for an example using the AppCenter 'sparkle' URL or the CI build files pushed to my own webserver.


[TC-MOD-2.1] ChangeToMode Verification Step 3 expects 0x85 as error response code but is getting 0xc6

In the Mode Select cluster test case TC-MOD-2.1 ChangeToMode Verification, in the last step (Step 3), the expectations is an error response with code 0x85. Even though I am seeing the error response, the error code is showing up to be 0xc6 and not the one expected.
Below is the log,
"[1637613691414] [25246:2371575] CHIP: [CTL] Generating NOC
[1637613691415] [25246:2371575] CHIP: [CTL] Generating ICAC
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: ===== RANDOM NUMBER GENERATOR AUDIT START ====
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: * Validate buf1 and buf2 are <<<different every run/boot!>>>
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: * Validate r1 and r2 are <<<different every run/boot!>>>
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: * buf1: 414B7AE819FDD429C3AA7ADBDA0AD446
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: * buf2: 065EA3162930BD63935F5929A39F597F
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: * r1: 0x30A12716 r2: 0x0382BBC1
[1637613691415] [25246:2371575] CHIP: [DL] AUDIT: ===== RANDOM NUMBER GENERATOR AUDIT END ====
[1637613691415] [25246:2371575] CHIP: [DL] _Init
[1637613691415] [25246:2371575] CHIP: [IN] UDP::Init bind&listen port=5541
[1637613691415] [25246:2371575] CHIP: [IN] UDP::Init bound to port=5541
[1637613691415] [25246:2371575] CHIP: [IN] UDP::Init bind&listen port=5541
[1637613691415] [25246:2371575] CHIP: [IN] UDP::Init bound to port=5541
[1637613691415] [25246:2371575] CHIP: [IN] TransportMgr initialized
[1637613691416] [25246:2371575] CHIP: [DIS] Init fabric pairing table with server storage
[1637613691416] [25246:2371575] CHIP: [CTL] System State Initialized...
[1637613691416] [25246:2371575] CHIP: [ZCL] Using ZAP configuration...
[1637613691416] [25246:2371575] CHIP: [DIS] Verifying the received credentials
[1637613691417] [25246:2371575] CHIP: [DIS] Added new fabric at index: 1, Initialized: 1
[1637613691417] [25246:2371575] CHIP: [DIS] Assigned compressed fabric ID: 0x56791D9DD63C9A95, node ID: 0x000000000001B669
[1637613691417] [25246:2371575] CHIP: [CTL] Joined the fabric at index 1. Compressed fabric ID is: 0x56791D9DD63C9A95
[1637613691417] [25246:2371579] CHIP: [DL] _OnPlatformEvent
[1637613691417] [25246:2371579] CHIP: [TOO] Sending command to node 0x1
[1637613691418] [25246:2371579] CHIP: [IN] Prepared plaintext message 0x7f8dce013280 to 0x0000000000000000 of type 0x30 and protocolId (0, 0) on exchange 42877i with MessageCounter:2136539305.
[1637613691418] [25246:2371579] CHIP: [IN] Sending plaintext msg 0x7f8dce013280 with MessageCounter:2136539305 to 0x0000000000000000 at monotonic time: 428590555 msec
[1637613691418] [25246:2371579] CHIP: [SC] Sent Sigma1 msg
[1637613691569] [25246:2371579] CHIP: [EM] Received message of type 0x31 with protocolId (0, 0) and MessageCounter:1619126971 on exchange 42877i
[1637613691569] [25246:2371579] CHIP: [EM] Rxd Ack; Removing MessageCounter:2136539305 from Retrans Table on exchange 42877i
[1637613691569] [25246:2371579] CHIP: [EM] Removed CHIP MessageCounter:2136539305 from RetransTable on exchange 42877i
[1637613691569] [25246:2371579] CHIP: [SC] Received Sigma2 msg
[1637613691569] [25246:2371579] CHIP: [SC] Peer assigned session session ID 73
[1637613691570] [25246:2371579] CHIP: [SC] Sending Sigma3
[1637613691571] [25246:2371579] CHIP: [EM] Piggybacking Ack for MessageCounter:1619126971 on exchange: 42877i
[1637613691571] [25246:2371579] CHIP: [IN] Prepared plaintext message 0x7f8dce013280 to 0x0000000000000000 of type 0x32 and protocolId (0, 0) on exchange 42877i with MessageCounter:2136539306.
[1637613691571] [25246:2371579] CHIP: [IN] Sending plaintext msg 0x7f8dce013280 with MessageCounter:2136539306 to 0x0000000000000000 at monotonic time: 428590708 msec
[1637613691571] [25246:2371579] CHIP: [SC] Sent Sigma3 msg
[1637613691579] [25246:2371581] CHIP: [EM] Received message of type 0x40 with protocolId (0, 0) and MessageCounter:1619126972 on exchange 42877i
[1637613691579] [25246:2371581] CHIP: [EM] Rxd Ack; Removing MessageCounter:2136539306 from Retrans Table on exchange 42877i
[1637613691579] [25246:2371581] CHIP: [EM] Removed CHIP MessageCounter:2136539306 from RetransTable on exchange 42877i
[1637613691579] [25246:2371581] CHIP: [SC] Success status report received. Session was established
[1637613691579] [25246:2371581] CHIP: [IN] New secure session created for device 0x0000000000000001, key 73!!
[1637613691579] [25246:2371581] CHIP: [TOO] Sending cluster (0x00000050) command (0x00000000) on endpoint 1
[1637613691579] [25246:2371581] CHIP: [DMG] ICR moving to [AddingComm]
[1637613691579] [25246:2371581] CHIP: [DMG] ICR moving to [AddedComma]
[1637613691579] [25246:2371581] CHIP: [IN] Prepared encrypted message 0x7f8dce013280 to 0x0000000000000001 of type 0x8 and protocolId (0, 1) on exchange 42878i with MessageCounter:0.
[1637613691579] [25246:2371581] CHIP: [IN] Sending encrypted msg 0x7f8dce013280 with MessageCounter:0 to 0x0000000000000001 at monotonic time: 428590717 msec
[1637613691579] [25246:2371581] CHIP: [DMG] ICR moving to [CommandSen]
[1637613691579] [25246:2371581] CHIP: [EM] Sending Standalone Ack for MessageCounter:1619126972 on exchange 42877i
[1637613691579] [25246:2371581] CHIP: [IN] Prepared plaintext message 0x700001a40450 to 0x0000000000000000 of type 0x10 and protocolId (0, 0) on exchange 42877i with MessageCounter:2136539307.
[1637613691579] [25246:2371581] CHIP: [IN] Sending plaintext msg 0x700001a40450 with MessageCounter:2136539307 to 0x0000000000000000 at monotonic time: 428590717 msec
[1637613691579] [25246:2371581] CHIP: [EM] Flushed pending ack for MessageCounter:1619126972 on exchange 42877i
[1637613691582] [25246:2371581] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:1 on exchange 42878i
[1637613691582] [25246:2371581] CHIP: [EM] Rxd Ack; Removing MessageCounter:0 from Retrans Table on exchange 42878i
[1637613691582] [25246:2371581] CHIP: [EM] Removed CHIP MessageCounter:0 from RetransTable on exchange 42878i
[1637613691582] [25246:2371581] CHIP: [DMG] InvokeCommand =
[1637613691582] [25246:2371581] CHIP: [DMG] {
[1637613691582] [25246:2371581] CHIP: [DMG] 	CommandList =
[1637613691582] [25246:2371581] CHIP: [DMG] 	[
[1637613691582] [25246:2371581] CHIP: [DMG] 		CommandDataIB =
[1637613691582] [25246:2371581] CHIP: [DMG] 		{
[1637613691582] [25246:2371581] CHIP: [DMG] 			CommandPathIB =
[1637613691582] [25246:2371581] CHIP: [DMG] 			{
[1637613691582] [25246:2371581] CHIP: [DMG] 				EndpointId = 0x1,
[1637613691582] [25246:2371581] CHIP: [DMG] 				ClusterId = 0x50,
[1637613691582] [25246:2371581] CHIP: [DMG] 				CommandId = 0x0,
[1637613691582] [25246:2371581] CHIP: [DMG] 			},
[1637613691582] [25246:2371581] CHIP: [DMG]
[1637613691582] [25246:2371581] CHIP: [DMG] 			StatusIB =
[1637613691582] [25246:2371581] CHIP: [DMG] 			{
[1637613691582] [25246:2371581] CHIP: [DMG] 				status = 0xc6,
[1637613691582] [25246:2371581] CHIP: [DMG] 			},
[1637613691582] [25246:2371581] CHIP: [DMG]
[1637613691582] [25246:2371581] CHIP: [DMG] 		},
[1637613691582] [25246:2371581] CHIP: [DMG]
[1637613691582] [25246:2371581] CHIP: [DMG] 	],
[1637613691582] [25246:2371581] CHIP: [DMG]
[1637613691582] [25246:2371581] CHIP: [DMG] }
[1637613691582] [25246:2371581] CHIP: [DMG] Received Command Response Status for Endpoint=1 Cluster=0x0000_0050 Command=0x0000_0000 Status=0xc6
[1637613691583] [25246:2371581] CHIP: [TOO] Default Failure Response: 0xc6
[1637613691583] [25246:2371581] CHIP: [DMG] ICR moving to [AwaitingDe]
[1637613691583] [25246:2371581] CHIP: [EM] Sending Standalone Ack for MessageCounter:1 on exchange 42878i
[1637613691583] [25246:2371581] CHIP: [IN] Prepared encrypted message 0x700001a40310 to 0x0000000000000001 of type 0x10 and protocolId (0, 0) on exchange 42878i with MessageCounter:1.
[1637613691583] [25246:2371581] CHIP: [IN] Sending encrypted msg 0x700001a40310 with MessageCounter:1 to 0x0000000000000001 at monotonic time: 428590721 msec
[1637613691583] [25246:2371581] CHIP: [EM] Flushed pending ack for MessageCounter:1 on exchange 42878i
[1637613691584] [25246:2371575] CHIP: [-] ../../zzz_generated/chip-tool/zap-generated/cluster/Commands.h:45: CHIP Error 0x000000AC: Internal error at ../../examples/chip-tool/commands/common/CHIPCommand.cpp:84
[1637613691584] [25246:2371575] CHIP: [TOO] Run command failure: ../../zzz_generated/chip-tool/zap-generated/cluster/Commands.h:45: CHIP Error 0x000000AC: Internal error
[1637613691618] [25246:2371575] CHIP: [CTL] Shutting down the System State, this will teardown the CHIP Stack
[1637613691618] [25246:2371575] CHIP: [DL] Inet Layer shutdown
[1637613691618] [25246:2371575] CHIP: [DL] BLE layer shutdown
[1637613691618] [25246:2371575] CHIP: [DL] System Layer shutdown
"

In the recent TE7.5 testing, we are seeing error code 0x87 instead of 0x85

For referance still facing the isssue :

ubuntu@matter-7:~/cntrl/connectedhomeip/examples/chip-tool/out/debug$ ./chip-tool modeselect change-to-mode 2 1 1
[1648556998.071675][19550:19550] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
[1648556998.072229][19550:19550] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_factory.ini
[1648556998.072387][19550:19550] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_config.ini
[1648556998.072501][19550:19550] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_counters.ini
[1648556998.072881][19550:19550] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-t3LZ9q)
[1648556998.073532][19550:19550] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1648556998.073587][19550:19550] CHIP:DL: NVS set: chip-counters/reboot-count = 27 (0x1B)
[1648556998.074507][19550:19550] CHIP:DL: Got Ethernet interface: eth0
[1648556998.075201][19550:19550] CHIP:DL: Found the primary Ethernet interface:eth0
[1648556998.075876][19550:19550] CHIP:DL: Got WiFi interface: wlan0
[1648556998.075954][19550:19550] CHIP:DL: Failed to reset WiFi statistic counts
[1648556998.076046][19550:19550] CHIP:IN: UDP::Init bind&listen port=0
[1648556998.076180][19550:19550] CHIP:IN: UDP::Init bound to port=36387
[1648556998.076207][19550:19550] CHIP:IN: BLEBase::Init - setting/overriding transport
[1648556998.076228][19550:19550] CHIP:IN: TransportMgr initialized
[1648556998.076262][19550:19550] CHIP:DIS: Init fabric pairing table with server storage
[1648556998.076398][19550:19550] CHIP:IN: Loading from storage for fabric index 1
[1648556998.076927][19550:19550] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000001 and root pubkey
[1648556998.076974][19550:19550] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.077007][19550:19550] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.077039][19550:19550] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.077070][19550:19550] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.077101][19550:19550] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.077132][19550:19550] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.077162][19550:19550] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.077193][19550:19550] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.077219][19550:19550] CHIP:IN: 0xa1,
[1648556998.077341][19550:19550] CHIP:IN: Generated compressed fabric ID
[1648556998.077379][19550:19550] CHIP:IN: 0x14, 0x76, 0xe3, 0x40, 0xdf, 0xf9, 0x07, 0xd9,
[1648556998.080197][19550:19550] CHIP:IN: Loading from storage for fabric index 2
[1648556998.080591][19550:19550] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000002 and root pubkey
[1648556998.080634][19550:19550] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.080666][19550:19550] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.080722][19550:19550] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.080753][19550:19550] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.080783][19550:19550] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.080813][19550:19550] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.080843][19550:19550] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.080873][19550:19550] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.080900][19550:19550] CHIP:IN: 0xa1,
[1648556998.080967][19550:19550] CHIP:IN: Generated compressed fabric ID
[1648556998.081003][19550:19550] CHIP:IN: 0x2c, 0x56, 0x73, 0xec, 0x92, 0x91, 0x75, 0x94,
[1648556998.081359][19550:19550] CHIP:IN: Loading from storage for fabric index 3
[1648556998.081709][19550:19550] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000003 and root pubkey
[1648556998.081752][19550:19550] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.081783][19550:19550] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.081814][19550:19550] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.081845][19550:19550] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.081875][19550:19550] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.081905][19550:19550] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.081936][19550:19550] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.081966][19550:19550] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.081993][19550:19550] CHIP:IN: 0xa1,
[1648556998.082047][19550:19550] CHIP:IN: Generated compressed fabric ID
[1648556998.082082][19550:19550] CHIP:IN: 0x5b, 0xf4, 0xa2, 0x9a, 0x0b, 0x0b, 0xfe, 0xea,
[1648556998.082441][19550:19550] CHIP:DIS: Add fabric pairing table delegate
[1648556998.082730][19550:19550] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-On9lPE)
[1648556998.083501][19550:19550] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1648556998.083566][19550:19550] CHIP:DL: NVS set: chip-counters/GlobalMCTR = 27000 (0x6978)
[1648556998.086924][19550:19550] CHIP:ZCL: Using ZAP configuration...
[1648556998.090956][19550:19550] CHIP:DL: Avahi client registered
[1648556998.092104][19550:19550] CHIP:CTL: System State Initialized...
[1648556998.092186][19550:19550] CHIP:CTL: Setting attestation nonce to random value
[1648556998.092236][19550:19550] CHIP:CTL: Setting CSR nonce to random value
[1648556998.092322][19550:19550] CHIP:IN: UDP::Init bind&listen port=5550
[1648556998.092465][19550:19550] CHIP:IN: UDP::Init bound to port=5550
[1648556998.092492][19550:19550] CHIP:IN: TransportMgr initialized
[1648556998.092562][19550:19550] CHIP:CTL: Setting attestation nonce to random value
[1648556998.092613][19550:19550] CHIP:CTL: Setting CSR nonce to random value
[1648556998.093506][19550:19550] CHIP:CTL: Generating NOC
[1648556998.094472][19550:19550] CHIP:DIS: Verifying the received credentials
[1648556998.096186][19550:19550] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000001 and root pubkey
[1648556998.096310][19550:19550] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.096335][19550:19550] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.096358][19550:19550] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.096381][19550:19550] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.096402][19550:19550] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.096424][19550:19550] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.096446][19550:19550] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.096468][19550:19550] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.096488][19550:19550] CHIP:IN: 0xa1,
[1648556998.096545][19550:19550] CHIP:IN: Generated compressed fabric ID
[1648556998.096570][19550:19550] CHIP:IN: 0x14, 0x76, 0xe3, 0x40, 0xdf, 0xf9, 0x07, 0xd9,
[1648556998.096599][19550:19550] CHIP:DIS: Added new fabric at index: 1, Initialized: 1
[1648556998.096620][19550:19550] CHIP:DIS: Assigned compressed fabric ID: 0x1476E340DFF907D9, node ID: 0x000000000001B669
[1648556998.096642][19550:19550] CHIP:CTL: Joined the fabric at index 1. Compressed fabric ID is: 0x1476E340DFF907D9
[1648556998.096698][19550:19550] CHIP:IN: UDP::Init bind&listen port=5550
[1648556998.096828][19550:19550] CHIP:IN: UDP::Init bound to port=5550
[1648556998.096852][19550:19550] CHIP:IN: TransportMgr initialized
[1648556998.096951][19550:19550] CHIP:CTL: Setting attestation nonce to random value
[1648556998.097009][19550:19550] CHIP:CTL: Setting CSR nonce to random value
[1648556998.097787][19550:19550] CHIP:CTL: Generating NOC
[1648556998.098950][19550:19550] CHIP:DIS: Verifying the received credentials
[1648556998.101365][19550:19550] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000002 and root pubkey
[1648556998.101421][19550:19550] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.101454][19550:19550] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.101485][19550:19550] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.101515][19550:19550] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.101544][19550:19550] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.101575][19550:19550] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.101622][19550:19550] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.101652][19550:19550] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.101679][19550:19550] CHIP:IN: 0xa1,
[1648556998.101763][19550:19550] CHIP:IN: Generated compressed fabric ID
[1648556998.101810][19550:19550] CHIP:IN: 0x2c, 0x56, 0x73, 0xec, 0x92, 0x91, 0x75, 0x94,
[1648556998.101848][19550:19550] CHIP:DIS: Added new fabric at index: 2, Initialized: 1
[1648556998.101889][19550:19550] CHIP:DIS: Assigned compressed fabric ID: 0x2C5673EC92917594, node ID: 0x000000000001B669
[1648556998.101919][19550:19550] CHIP:CTL: Joined the fabric at index 2. Compressed fabric ID is: 0x2C5673EC92917594
[1648556998.101985][19550:19550] CHIP:IN: UDP::Init bind&listen port=5550
[1648556998.102171][19550:19550] CHIP:IN: UDP::Init bound to port=5550
[1648556998.102220][19550:19550] CHIP:IN: TransportMgr initialized
[1648556998.102347][19550:19550] CHIP:CTL: Setting attestation nonce to random value
[1648556998.102427][19550:19550] CHIP:CTL: Setting CSR nonce to random value
[1648556998.103399][19550:19550] CHIP:CTL: Generating NOC
[1648556998.104734][19550:19550] CHIP:DIS: Verifying the received credentials
[1648556998.107027][19550:19550] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000003 and root pubkey
[1648556998.107170][19550:19550] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.107204][19550:19550] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.107235][19550:19550] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.107265][19550:19550] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.107295][19550:19550] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.107325][19550:19550] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.107355][19550:19550] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.107385][19550:19550] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.107412][19550:19550] CHIP:IN: 0xa1,
[1648556998.107480][19550:19550] CHIP:IN: Generated compressed fabric ID
[1648556998.107515][19550:19550] CHIP:IN: 0x5b, 0xf4, 0xa2, 0x9a, 0x0b, 0x0b, 0xfe, 0xea,
[1648556998.107550][19550:19550] CHIP:DIS: Added new fabric at index: 3, Initialized: 1
[1648556998.107578][19550:19550] CHIP:DIS: Assigned compressed fabric ID: 0x5BF4A29A0B0BFEEA, node ID: 0x000000000001B669
[1648556998.107608][19550:19550] CHIP:CTL: Joined the fabric at index 3. Compressed fabric ID is: 0x5BF4A29A0B0BFEEA
[1648556998.107660][19550:19550] CHIP:IN: UDP::Init bind&listen port=5550
[1648556998.107818][19550:19550] CHIP:IN: UDP::Init bound to port=5550
[1648556998.107851][19550:19550] CHIP:IN: TransportMgr initialized
[1648556998.137616][19550:19555] CHIP:DL: CHIP task running
[1648556998.137881][19550:19555] CHIP:DL: HandlePlatformSpecificBLEEvent 32787
[1648556998.137919][19550:19555] CHIP:TOO: Sending command to node 0x1
[1648556998.137958][19550:19555] CHIP:CSM: FindOrEstablishSession: PeerId = 1476E340DFF907D9:0000000000000001, NodeIdWasResolved = 0
[1648556998.137990][19550:19555] CHIP:CSM: FindOrEstablishSession: No existing session found
[1648556998.138035][19550:19555] CHIP:DIS: Resolving 1476E340DFF907D9:0000000000000001 ...
[1648556998.139974][19550:19555] CHIP:DL: Avahi resolve found
[1648556998.140057][19550:19555] CHIP:DIS: Node ID resolved for 1476E340DFF907D9:0000000000000001
[1648556998.140087][19550:19555] CHIP:DIS:     Addr 0: [fe80::e65f:1ff:fe30:e67f]:5540
[1648556998.140337][19550:19555] CHIP:DIS: UDP:[fe80::e65f:1ff:fe30:e67f%eth0]:5540: new best score: 3
[1648556998.140366][19550:19555] CHIP:DIS: Checking node lookup status after 2 ms
[1648556998.140388][19550:19555] CHIP:DIS: Keeping DNSSD lookup active
[1648556998.338703][19550:19555] CHIP:DIS: Checking node lookup status after 201 ms
[1648556998.339013][19550:19555] CHIP:CTL: Updating device address to UDP:[fe80::e65f:1ff:fe30:e67f%eth0]:5540 while in state 1
[1648556998.339075][19550:19555] CHIP:CTL: OperationalDeviceProxy[1476E340DFF907D9:0000000000000001]: State change 1 --> 2
[1648556998.339527][19550:19555] CHIP:SC: Establishing CASE session to UDP:[fe80::e65f:1ff:fe30:e67f%eth0]:5540
[1648556998.340530][19550:19555] CHIP:IN: Generating DestinationID. Fabric ID 0x0000000000000001, Dest node ID 0x0000000000000001, Random data
[1648556998.340621][19550:19555] CHIP:IN: 0xb6, 0xa6, 0x4f, 0x8c, 0x0e, 0x9a, 0x52, 0xd5,
[1648556998.340755][19550:19555] CHIP:IN: 0x5f, 0x69, 0x8b, 0xab, 0xe2, 0x2d, 0xf1, 0x17,
[1648556998.340817][19550:19555] CHIP:IN: 0x68, 0xd3, 0x63, 0x3b, 0xa9, 0x97, 0xbc, 0xb4,
[1648556998.340874][19550:19555] CHIP:IN: 0x0e, 0xee, 0xc4, 0x4f, 0xc6, 0xa6, 0x21, 0x51,
[1648556998.340923][19550:19555] CHIP:IN: Root pubkey
[1648556998.340978][19550:19555] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.341029][19550:19555] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.341084][19550:19555] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.341140][19550:19555] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.341209][19550:19555] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.341264][19550:19555] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.341319][19550:19555] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.341374][19550:19555] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.341422][19550:19555] CHIP:IN: 0xa1,
[1648556998.341472][19550:19555] CHIP:IN: IPK
[1648556998.341527][19550:19555] CHIP:IN: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
[1648556998.341585][19550:19555] CHIP:IN: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
[1648556998.341671][19550:19555] CHIP:IN: Generated DestinationID output
[1648556998.341731][19550:19555] CHIP:IN: 0x30, 0x24, 0x9a, 0xbb, 0x56, 0x8f, 0x39, 0x46,
[1648556998.341787][19550:19555] CHIP:IN: 0xa3, 0x59, 0x72, 0x49, 0xef, 0x24, 0xbb, 0x1c,
[1648556998.341841][19550:19555] CHIP:IN: 0x9b, 0x5a, 0xdd, 0x24, 0x5d, 0xe4, 0x8f, 0x24,
[1648556998.341896][19550:19555] CHIP:IN: 0x5b, 0x3e, 0xc8, 0xae, 0x36, 0x1a, 0x85, 0xe5,
[1648556998.341948][19550:19555] CHIP:SC: Including MRP parameters
[1648556998.342247][19550:19555] CHIP:IN: Prepared unauthenticated message 0xaaaafe6fadd8 to 0x0000000000000000 (0)  of type 0x30 and protocolId (0, 0) on exchange 65456i with MessageCounter:3540166398.
[1648556998.342348][19550:19555] CHIP:IN: Sending unauthenticated msg 0xaaaafe6fadd8 with MessageCounter:3540166398 to 0x0000000000000000 at monotonic time:<PHONE_NUMBER>DC3529 msec
[1648556998.342852][19550:19555] CHIP:SC: Sent Sigma1 msg
[1648556998.342926][19550:19555] CHIP:CTL: OperationalDeviceProxy[1476E340DFF907D9:0000000000000001]: State change 2 --> 3
[1648556998.342992][19550:19555] CHIP:DIS: Discovery does not require any more timeouts
[1648556998.349894][19550:19555] CHIP:EM: Received message of type 0x31 with protocolId (0, 0) and MessageCounter:3611010131 on exchange 65456i
[1648556998.349975][19550:19555] CHIP:EM: Found matching exchange: 65456i, Delegate: 0xffff7c0011f8
[1648556998.350060][19550:19555] CHIP:EM: Rxd Ack; Removing MessageCounter:3540166398 from Retrans Table on exchange 65456i
[1648556998.350119][19550:19555] CHIP:EM: Removed CHIP MessageCounter:3540166398 from RetransTable on exchange 65456i
[1648556998.350194][19550:19555] CHIP:SC: Received Sigma2 msg
[1648556998.350269][19550:19555] CHIP:SC: Peer assigned session session ID 28
[1648556998.351272][19550:19555] CHIP:SC: The device does not support GetClock_RealTimeMS() API. This will eventually result in CASE session setup failures.
[1648556998.354173][19550:19555] CHIP:IN: Generating compressed fabric ID using uncompressed fabric ID 0x0000000000000001 and root pubkey
[1648556998.354235][19550:19555] CHIP:IN: 0x04, 0x9a, 0x8e, 0xfa, 0xe6, 0x8a, 0x73, 0x21,
[1648556998.354275][19550:19555] CHIP:IN: 0x5d, 0x29, 0xc7, 0x1b, 0x97, 0xb7, 0x39, 0x8b,
[1648556998.354313][19550:19555] CHIP:IN: 0x02, 0x03, 0x69, 0xba, 0x1d, 0x67, 0x3d, 0x92,
[1648556998.354350][19550:19555] CHIP:IN: 0x3e, 0x36, 0xc2, 0xd3, 0x16, 0xd2, 0xb2, 0x0c,
[1648556998.354388][19550:19555] CHIP:IN: 0x82, 0xf8, 0x96, 0xf7, 0xa0, 0x61, 0x26, 0x4a,
[1648556998.354424][19550:19555] CHIP:IN: 0x81, 0x4e, 0x85, 0xba, 0xb8, 0x8b, 0xf9, 0xe1,
[1648556998.354460][19550:19555] CHIP:IN: 0x13, 0x23, 0xfb, 0x59, 0xf1, 0x6f, 0x9a, 0x9d,
[1648556998.354496][19550:19555] CHIP:IN: 0xe4, 0x68, 0x0c, 0xb4, 0x2c, 0x4f, 0x31, 0x63,
[1648556998.354529][19550:19555] CHIP:IN: 0xa1,
[1648556998.354601][19550:19555] CHIP:IN: Generated compressed fabric ID
[1648556998.354643][19550:19555] CHIP:IN: 0x14, 0x76, 0xe3, 0x40, 0xdf, 0xf9, 0x07, 0xd9,
[1648556998.355987][19550:19555] CHIP:SC: Found MRP parameters in the message
[1648556998.356042][19550:19555] CHIP:SC: Sending Sigma3
[1648556998.356564][19550:19555] CHIP:EM: Piggybacking Ack for MessageCounter:3611010131 on exchange: 65456i
[1648556998.356810][19550:19555] CHIP:IN: Prepared unauthenticated message 0xaaaafe6fadd8 to 0x0000000000000000 (0)  of type 0x32 and protocolId (0, 0) on exchange 65456i with MessageCounter:3540166399.
[1648556998.356878][19550:19555] CHIP:IN: Sending unauthenticated msg 0xaaaafe6fadd8 with MessageCounter:3540166399 to 0x0000000000000000 at monotonic time:<PHONE_NUMBER>DC3538 msec
[1648556998.357252][19550:19555] CHIP:SC: Sent Sigma3 msg
[1648556998.363564][19550:19555] CHIP:EM: Received message of type 0x40 with protocolId (0, 0) and MessageCounter:3611010132 on exchange 65456i
[1648556998.363607][19550:19555] CHIP:EM: Found matching exchange: 65456i, Delegate: 0xffff7c0011f8
[1648556998.363651][19550:19555] CHIP:EM: Rxd Ack; Removing MessageCounter:3540166399 from Retrans Table on exchange 65456i
[1648556998.363681][19550:19555] CHIP:EM: Removed CHIP MessageCounter:3540166399 from RetransTable on exchange 65456i
[1648556998.363722][19550:19555] CHIP:SC: Success status report received. Session was established
[1648556998.363757][19550:19555] CHIP:IN: New secure session created for device 0x0000000000000001, LSID:1 PSID:28!
[1648556998.363886][19550:19555] CHIP:CTL: OperationalDeviceProxy[1476E340DFF907D9:0000000000000001]: State change 3 --> 4
[1648556998.363950][19550:19555] CHIP:TOO: Sending cluster (0x00000050) command (0x00000000) on endpoint 1
[1648556998.364038][19550:19555] CHIP:DMG: ICR moving to [AddingComm]
[1648556998.364090][19550:19555] CHIP:DMG: ICR moving to [AddedComma]
[1648556998.364222][19550:19555] CHIP:IN: Prepared secure message 0xaaaafe6fadd8 to 0x0000000000000001 (1)  of type 0x8 and protocolId (0, 1) on exchange 65457i with MessageCounter:16220148.
[1648556998.364271][19550:19555] CHIP:IN: Sending encrypted msg 0xaaaafe6fadd8 with MessageCounter:16220148 to 0x0000000000000001 (1) at monotonic time:<PHONE_NUMBER>DC353F msec
[1648556998.364500][19550:19555] CHIP:DMG: ICR moving to [CommandSen]
[1648556998.364543][19550:19555] CHIP:EM: Sending Standalone Ack for MessageCounter:3611010132 on exchange 65456i
[1648556998.364612][19550:19555] CHIP:IN: Prepared unauthenticated message 0xffff9174d908 to 0x0000000000000000 (0)  of type 0x10 and protocolId (0, 0) on exchange 65456i with MessageCounter:3540166400.
[1648556998.364656][19550:19555] CHIP:IN: Sending unauthenticated msg 0xffff9174d908 with MessageCounter:3540166400 to 0x0000000000000000 at monotonic time:<PHONE_NUMBER>DC353F msec
[1648556998.364855][19550:19555] CHIP:EM: Flushed pending ack for MessageCounter:3611010132 on exchange 65456i
[1648556998.367903][19550:19555] CHIP:EM: Received message of type 0x9 with protocolId (0, 1) and MessageCounter:6651613 on exchange 65457i
[1648556998.367943][19550:19555] CHIP:EM: Found matching exchange: 65457i, Delegate: 0xffff7c004060
[1648556998.367984][19550:19555] CHIP:EM: Rxd Ack; Removing MessageCounter:16220148 from Retrans Table on exchange 65457i
[1648556998.368013][19550:19555] CHIP:EM: Removed CHIP MessageCounter:16220148 from RetransTable on exchange 65457i
[1648556998.368049][19550:19555] CHIP:DMG: ICR moving to [ResponseRe]
[1648556998.368107][19550:19555] CHIP:DMG: InvokeResponseMessage =
[1648556998.368136][19550:19555] CHIP:DMG: {
[1648556998.368165][19550:19555] CHIP:DMG:      suppressResponse = false,
[1648556998.368195][19550:19555] CHIP:DMG:      InvokeResponseIBs =
[1648556998.368233][19550:19555] CHIP:DMG:      [
[1648556998.368262][19550:19555] CHIP:DMG:              InvokeResponseIB =
[1648556998.368304][19550:19555] CHIP:DMG:              {
[1648556998.368335][19550:19555] CHIP:DMG:                      CommandStatusIB =
[1648556998.368374][19550:19555] CHIP:DMG:                      {
[1648556998.368411][19550:19555] CHIP:DMG:                              CommandPathIB =
[1648556998.368452][19550:19555] CHIP:DMG:                              {
[1648556998.368494][19550:19555] CHIP:DMG:                                      EndpointId = 0x1,
[1648556998.368537][19550:19555] CHIP:DMG:                                      ClusterId = 0x50,
[1648556998.368578][19550:19555] CHIP:DMG:                                      CommandId = 0x0,
[1648556998.368618][19550:19555] CHIP:DMG:                              },
[1648556998.368662][19550:19555] CHIP:DMG:
[1648556998.368738][19550:19555] CHIP:DMG:                              StatusIB =
[1648556998.368779][19550:19555] CHIP:DMG:                              {
[1648556998.368824][19550:19555] CHIP:DMG:                                      status = 0x87,
[1648556998.368867][19550:19555] CHIP:DMG:                              },
[1648556998.368908][19550:19555] CHIP:DMG:
[1648556998.368943][19550:19555] CHIP:DMG:                      },
[1648556998.368988][19550:19555] CHIP:DMG:
[1648556998.369021][19550:19555] CHIP:DMG:              },
[1648556998.369060][19550:19555] CHIP:DMG:
[1648556998.369092][19550:19555] CHIP:DMG:      ],
[1648556998.369128][19550:19555] CHIP:DMG:
[1648556998.369158][19550:19555] CHIP:DMG:      InteractionModelRevision = 1
[1648556998.369189][19550:19555] CHIP:DMG: },
[1648556998.369263][19550:19555] CHIP:DMG: Received Command Response Status for Endpoint=1 Cluster=0x0000_0050 Command=0x0000_0000 Status=0x87
[1648556998.369304][19550:19555] CHIP:TOO: Error: IM Error 0x00000587: General error: 0x87
[1648556998.369347][19550:19555] CHIP:DMG: ICR moving to [AwaitingDe]
[1648556998.369410][19550:19555] CHIP:EM: Sending Standalone Ack for MessageCounter:6651613 on exchange 65457i
[1648556998.369513][19550:19555] CHIP:IN: Prepared secure message 0xffff9174d918 to 0x0000000000000001 (1)  of type 0x10 and protocolId (0, 0) on exchange 65457i with MessageCounter:16220149.
[1648556998.369559][19550:19555] CHIP:IN: Sending encrypted msg 0xffff9174d918 with MessageCounter:16220149 to 0x0000000000000001 (1) at monotonic time:<PHONE_NUMBER>DC3544 msec
[1648556998.369766][19550:19555] CHIP:EM: Flushed pending ack for MessageCounter:6651613 on exchange 65457i
[1648556998.369988][19550:19550] CHIP:CTL: Shutting down the commissioner
[1648556998.370087][19550:19550] CHIP:CTL: Shutting down the controller
[1648556998.370126][19550:19550] CHIP:CTL: Shutting down the commissioner
[1648556998.370208][19550:19550] CHIP:CTL: Shutting down the controller
[1648556998.370246][19550:19550] CHIP:IN: Expiring all connections for fabric 1!!
[1648556998.370316][19550:19550] CHIP:CTL: Shutting down the commissioner
[1648556998.370394][19550:19550] CHIP:CTL: Shutting down the controller
[1648556998.370423][19550:19550] CHIP:IN: Expiring all connections for fabric 2!!
[1648556998.370466][19550:19550] CHIP:CTL: Shutting down the commissioner
[1648556998.370544][19550:19550] CHIP:CTL: Shutting down the controller
[1648556998.370583][19550:19550] CHIP:IN: Expiring all connections for fabric 3!!
[1648556998.370622][19550:19550] CHIP:CTL: Shutting down the System State, this will teardown the CHIP Stack
[1648556998.371735][19550:19550] CHIP:DMG: IM WH moving to [Uninitialized]
[1648556998.371782][19550:19550] CHIP:DMG: IM WH moving to [Uninitialized]
[1648556998.371805][19550:19550] CHIP:DMG: IM WH moving to [Uninitialized]
[1648556998.371829][19550:19550] CHIP:DMG: IM WH moving to [Uninitialized]
[1648556998.371910][19550:19550] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.
[1648556998.372279][19550:19550] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-NctEh0)
[1648556998.373274][19550:19550] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1648556998.373363][19550:19550] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1648556998.373401][19550:19550] CHIP:DL: Inet Layer shutdown
[1648556998.373434][19550:19550] CHIP:DL: BLE shutdown
[1648556998.373468][19550:19550] CHIP:DL: System Layer shutdown
[1648556998.373628][19550:19550] CHIP:TOO: Run command failure: IM Error 0x00000587: General error: 0x87

@Garik098 - please describe spec requirement (unclear to me if ChangeToMode is M(andatory) or O(ptional) in the spec from just reading the bug description) and the test case in a condensed format.
Logs in this bug are too long to parse easily. I need:

what spec are we testing
what is being done to test
what environment was this tested on (what app like all-clusters/lock/light etc. and what platform(s) like esp32/nrf/efr/...) for a developer to reproduce the issue

Beyond that logs either as attachments or if reviewed by a human, condensed to minimal data (e.g. saying Error 0xAC or Error 0x87 rather than a full log dump)

Problem:
while executing testcase [TC-MOD-2.1] expected outcome is not matched with the result.
command used:
./chip-tool modeselect change-to-mode 2 1 1
Expected outcome:
INVALID_COMMAND (hex value 0x85/decimal 133)
Actual outcome:
Error: IM Error 0x00000587: General error: 0x87
Reason:
Because we execute the support mode  attribute ,It should display the supporting modes values as 0,4 and 7.We are changing the mode which is not displayed in the supported modes, it should get a value as (0x85-invalid command) but actually we are getting (0x87-General error).
Modes which are supports are displayed below:
./chip-tool modeselect read supported-modes 1 1
SupportedModes: 3 entries
[1]: {
Label: Black
Mode: 0
SemanticTag: 0
}
:     [2]: {
Label: Cappuccino
Mode: 4
SemanticTag: 0
}
[3]: {
Label: Espresso
Mode: 7
SemanticTag: 0
}

Fixed in #17685


Cause filter of finder should be in two columns on thor

Testing on Firefox 41.0.2 from Brazil via TorGuard.

Hmm, not seeing this in Firefox 41.0.2 on OS X 10.11.1, on either production or Thor:

I'll look into setting up TorGuard to see if somehow it's only appearing for BR users, but I can't think of a reason that'd be occurring. :confused:

@DFurnes Keep in mind thor now has headers that make "BR" act like Global English, not Brazil

Hmm. We're serving identical stylesheets and markup for that section to all country codes though. But we'll see... strange things have been happening with CSS column bugs lately, so who knows!

@mikefantini I'm unable to reproduce this across environments or country codes. Going to close, but please re-open if you continue seeing this.


Add licence headers

Can you add licence headers to all your files?
Like we have in jhipster/jhipster, for example at:
https://github.com/jhipster/jhipster/blob/master/src/main/java/io/github/jhipster/web/filter/CachingHttpHeadersFilter.java
Now those files are not generated anymore, we should add the licence everywhere.

Sure will do
Thanks & Regards,
Deepu
On Thu, Dec 29, 2016 at 9:25 AM, Julien Dubois<EMAIL_ADDRESS>wrote:

Can you add licence headers to all your files?
Like we have in jhipster/jhipster, for example at:
https://github.com/jhipster/jhipster/blob/master/src/main/
java/io/github/jhipster/web/filter/CachingHttpHeadersFilter.java
Now those files are not generated anymore, we should add the licence
everywhere.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/ng-jhipster/issues/2, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF-szJA_80lX4hdvvP4RQfG5bOyV0ks5rM25-gaJpZM4LXbN6
.

we can use the same right ?

yes we can use the same
Thanks & Regards,
Deepu
On Thu, Dec 29, 2016 at 10:26 AM, Sendil Kumar N<EMAIL_ADDRESS>wrote:

we can use the same right ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/ng-jhipster/issues/2#issuecomment-269603147,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF3XgFfrJP8BPwnfVtGJpzqNOIIEFks5rM3y5gaJpZM4LXbN6
.

Indeed, they are very generic. It's just to protect our licence.

Okayes 👍 currently I have started the test cases, I will progressively add this .

this is done


Move away from setup.py

python setup.py install is outdated. We should be using pip install -e .. I think this should mostly just involve refactoring setup.py and moving a bunch of information into setup.cfg.

Optionally, just retemplate the whole thing with the sunpy/OA cookiecutter template


Find the speaker with the most name variations and paste a list of each variation

I need to know the name of the name of the speaker with the most variations, and I need a list of each of these variations.  Variations can include permutations and/or office titles and/or peerage titles, etc.

Maybe that really long name.
For sure William Gladstone.


fix: articles/virtual-machines/workloads/sap/hana-supported-scenario.md

Escape element

@nschonni : Thanks for your contribution! The author, @saghorpa, has been notified to review your proposed change.


How to install this on hacs?

Hi, I read the documentation and it says to install this via HACS. I am running the latest home-assistant 2021.4.6 and on HACS I just can't find this integration. Sorry for the newbie question. Any help please?

Edit Dashboard - 3 dots - Manage resources -  Add resource -  paste the link to JS

then add card - manual - use docs for configuration

I did exactly as stated above and create a new card with the following code:
type: custom:ha-card-weather-conditions name: cc_test language: de animation: true weather:   icons_model: climacell   current:     temperature: sensors.pws_temperature
I get the following error:
JSON.parse: unexpected character at line 1 column 1 of the JSON data
Can someone point me to the error??

I did exactly as stated above and create a new card with the following code:
type: custom:ha-card-weather-conditions name: cc_test language: de animation: true weather: icons_model: climacell current: temperature: sensors.pws_temperature
I get the following error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Can someone point me to the error??

I had same issue, after i copied code to external editor i noticed there is missing space

I hope this help someone

this took me a long time so maybe I help someone:
-install from HACS
-no need to add ANYTHING to the resources. But if you want, double check that in Settings/Dashboards/.../Resources you already have ha-card-weather-conditions
-go to a dashboard, click Add Card, and scroll down to the bottom. Click Manual, and paste one of the examples. I found that  i got an error for type unless I put them in ' '
-you got an empty dashboard. You have to populate the card with your sensors, they are NOT added. So instead of temperature: sensor.cc_test_temperature
you need to enter a sensor that is your actual temperature.


ECS task roles error

summon s3 won't pull from a container with ECS roles because the version of aws-sdk-go is to old to support it.       A rebuild with updated deps should resolve the issue.
I tried to update all the deps but I am getting these errors below while building.   I don't know go well enough to resolve this issue.
-->     linux/amd64: github.com/conjurinc/summon-s3
-->   windows/amd64: github.com/conjurinc/summon-s3

3 errors occurred:
--> darwin/amd64 error: exit status 2
Stderr: # github.com/aws/aws-sdk-go/aws/request
Godeps/_workspace/src/github.com/aws/aws-sdk-go/aws/request/request_context_1_6.go:13: r.HTTPRequest.Cancel undefined (type *http.Request has no field or method Cancel)

--> linux/amd64 error: exit status 2
Stderr: # github.com/aws/aws-sdk-go/aws/request
Godeps/_workspace/src/github.com/aws/aws-sdk-go/aws/request/request_context_1_6.go:13: r.HTTPRequest.Cancel undefined (type *http.Request has no field or method Cancel)

--> windows/amd64 error: exit status 2
Stderr: # github.com/aws/aws-sdk-go/aws/request
Godeps/_workspace/src/github.com/aws/aws-sdk-go/aws/request/request_context_1_6.go:13: r.HTTPRequest.Cancel undefined (type *http.Request has no field or method Cancel)

I thought I had it solved but even updating to go1.7, it is still throwing the error.

I was able to get it to compile with 1.7 but it throws this error now
error fetching variable AWS: exit status 2: panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x46e4da]
goroutine 1 [running]:
panic(0x6b3b20, 0xc420012080)
/usr/lib/go-1.7/src/runtime/panic.go:500 +0x1a1
github.com/aws/aws-sdk-go/service/s3.New(0x0, 0x0, 0x0, 0x0, 0x0, 0xc4200cf460)
/go/src/github.com/conjurinc/summon-aws/Godeps/_workspace/src/github.com/aws/aws-sdk-go/service/s3/service.go:47 +0x3a
main.main()
/go/src/github.com/conjurinc/summon-aws/main.go:38 +0x189

Thanks for bringing this up! Will get a new build out later today.

i doubt this is correct but   I added this
"github.com/aws/aws-sdk-go/aws/session"
and
	// Create S3 service client
	svc := s3.New(sess)

and it makes it work with ECS task roles but it no longer works with the ~/.aws/credentials files
so I sure there is more to be changed to work with both.
I can test both use cases easily if needed.
Thanks!

I also had to build it with the golang docker image because the gox image was giving problems.   (used the image that summon is using)

This commit should fix the build errors: https://github.com/conjurinc/summon-s3/commit/109346ec378a9808973ac46988364b0b37780b25.
Can you try latest master and let us know if you're still seeing issues?

will do

this is the error that I am getting
Error fetching variable VAR: exit status 2: panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x6a776a]

    goroutine 1 [running]:
 summon-s3/vendor/github.com/aws/aws-sdk-go/service/s3.New(0x0, 0x0, 0x0, 0x0, 0x0, 0xc420016240)
 	/go/src/summon-s3/vendor/github.com/aws/aws-sdk-go/service/s3/service.go:47 +0x3a
 main.main()
 	/go/src/summon-s3/main.go:38 +0x181

I'm not sure how to do it in go but something similar to this is what i was thinking
       // if config file exists
	sess := session.Must(session.NewSessionWithOptions(session.Options{
		SharedConfigState: session.SharedConfigEnable,
	}))

	if sess == nil {
                // if session token exists
		sess := session.Must(session.NewSession())
	}

        svc := s3.New(sess)

I just put up an MR that resolves it

PR #3 has been merged to address this. v0.2.0 should work fine with ECS tasks. Please reopen if this is not the case. Thanks for your contribution @slimm609!


ArrayList updating values

Hey,
I have question if I'm doing something wrong..
I have class like this:
 @Entity
  public abstract class AbstractMyObject implements Persistable {
     @Key
     int id;

     @Nullable
     String title;

     @Nullable
     String description;

     @Convert(IntegerListConverter.class)
     ArrayList<Integer> someIDs= new ArrayList<>();
}

and now I'm trying to insert value to ArrayList and with simple update it's not working, method convertToPersisted is not called, and as I debugged there is no modifier for ArrayList like MODIFIED state.
When I do update(MyObject.class, Myobject.SOME_IDS) it's working.
What's problem with simple update on whole MyObject.class that this ArrayList is not updated?

Hi update only updates the modified fields in an entity for efficiency. When you have a collection that is converted the framework will not know it is modified from what it is stored currently hence why no change was made. update(MyObject.class, Myobject.SOME_IDS) is a good way to handle that like you mentioned.

Thank for fast reply! I understand, than it should described somewhere in docs as I couldn't find solution for this easily.

This is mentioned in the update javadoc, but will look into making this more clear (possibly returning the row count so you know how the rows affected)


Use cfu blackbox to help integration with external IP

Could this be useful to help integrating implementations of cfu. I've seen @tcal-x wrap*.v verilogs and I was wondering if this could make things a bit easier.
With this change an user must provide the implementation of CfuBb module.

Thank you @dlobato !   I agree the wrapper is quite a hack.   In fact I am currently investigating another way of getting rid of the wrapper -- explicitly connecting the CFU to the VexRiscv using LiteX:  https://github.com/enjoy-digital/litex/issues/883.    But let me take a look at your approach.


1 Power Suggestion

Can You Make A Power That Put Particles In RPG??
For Example /rpgitem test power particle flame??
Because There Are No Permission To Give To Members To Access Them For Command Powe
(Sorry For My Bad English) Your Plugin Is Amazing ^^ Keep Your Amazing Work

+1 on this.
Options should include: practicles type, enable mode (hold, rightclick or leftclick), and duration and cooldown if set to click.

@phoenixlzx
You can have an effect played multiple times with an interval, but you can not make an effect "durable". So what do you mean here?
Also, the "hold" trigger looks confusing for the same reason. Playing the effect every tick may significantly lag the server.

@RecursiveG Duration only applies when it set to click to use, means the effect lasts for some time after left or right click.
For hold, just give the player unlimited time of effect once, and when player switch to another item, remove the effect.


Update bower.json

Update Angular version to 1.3

@marcoscheuble used your PR on supported fork
Hope you don't mind.
And thanks for contributing :+1:

in fact I hoped you would do this :-)
Thanks for the module!


Examples Not Working

When running the examples most of them seem to throw an error. It seems like the Chat Input is not being parsed correctly. Looking at the example Ingest Url chain it looks to have an issue passing the Chat Input to the Web Loader. I was able to fix it by using a JSON Transform but in the example videos that it seems to work without them. I built with the latest code on the master branch.

With the JSON Transform it works

Is there something else that needs to be set so that the web loader properly reads the chat input?

I think the fix you made is the right one.
The chat input always sends user_input. The expected values for the chain can be edited but the chat doesn't map to it automatically. Manually mapping the input within the chain is required for now.
A good improvement would be to make the transform automatic, configured from the Chat Input node's input config.


Refactor validateType

Fixes: #68

[x] Unify error messages (don't emit multiple errors for one wrong call):

Example:

What I want to see here is simply: Entity#constructor> customValidation failed: x is NaN

Coming a bit closer to the goal with the commit before this comment:

(now I just need to repeat this pattern, I'm very happy so far with it)

This PR became a bit bigger and bumps Major semver version, but it feels so much cleaner and easier to understand now :rainbow: :+1: :1st_place_medal:


Error building

Hi,
When trying to build an docker image I get the following error:
2021-09-14 07:18:22,650 (BuildImageResultCallback.java:34) DEBUG : ResponseItem(stream=-- Found LibSSH: /usr/include (found suitable version "0.9.5", minimum required is "0.7.1")
, status=null, progressDetail=null, progress=null, id=null, from=null, time=null, errorDetail=null, error=null, aux=null)
2021-09-14 07:18:22,650 (ImageFromDockerfile.java:99) DEBUG : -- Found LibSSH: /usr/include (found suitable version "0.9.5", minimum required is "0.7.1")
2021-09-14 07:18:22,650 (BuildImageResultCallback.java:34) DEBUG : ResponseItem(stream=&amp#27;[91mCMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find LibYANG: Found unsuitable version "1.10.32", but required is
  at least "2" (found /usr/lib/x86_64-linux-gnu/libyang.so)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:376 (_FPHSA_FAILURE_MESSAGE)
  CMakeModules/FindLibYANG.cmake:86 (find_package_handle_standard_args)
  CMakeLists.txt:256 (find_package)

&amp#27;[0m, status=null, progressDetail=null, progress=null, id=null, from=null, time=null, errorDetail=null, error=null, aux=null)
2021-09-14 07:18:22,650 (ImageFromDockerfile.java:99) DEBUG : &amp#27;[91mCMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find LibYANG: Found unsuitable version "1.10.32", but required is
  at least "2" (found /usr/lib/x86_64-linux-gnu/libyang.so)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:376 (_FPHSA_FAILURE_MESSAGE)
  CMakeModules/FindLibYANG.cmake:86 (find_package_handle_standard_args)
  CMakeLists.txt:256 (find_package)

&amp#27;[0m
2021-09-14 07:18:22,650 (BuildImageResultCallback.java:34) DEBUG : ResponseItem(stream=-- Configuring incomplete, errors occurred!
See also "/opt/dev/libnetconf2/build/CMakeFiles/CMakeOutput.log".
See also "/opt/dev/libnetconf2/build/CMakeFiles/CMakeError.log".
, status=null, progressDetail=null, progress=null, id=null, from=null, time=null, errorDetail=null, error=null, aux=null)
2021-09-14 07:18:22,651 (ImageFromDockerfile.java:99) DEBUG : -- Configuring incomplete, errors occurred!
See also "/opt/dev/libnetconf2/build/CMakeFiles/CMakeOutput.log".
See also "/opt/dev/libnetconf2/build/CMakeFiles/CMakeError.log".
2021-09-14 07:18:22,786 (BuildImageResultCallback.java:34) DEBUG : ResponseItem(stream=null, status=null, progressDetail=null, progress=null, id=null, from=null, time=null, errorDetail=ResponseItem.ErrorDetail(code=1, message=The command '/bin/sh -c cd /opt/dev &&       git clone https://github.com/CESNET/libnetconf2.git && cd libnetconf2 &&       git checkout master &&       mkdir build && cd build &&       cmake  -DCMAKE_BUILD_TYPE:String="Release" -DCMAKE_INSTALL_PREFIX:PATH=/usr -DENABLE_BUILD_TESTS=OFF .. &&       make -j2 &&       make install' returned a non-zero code: 1), error=The command '/bin/sh -c cd /opt/dev &&       git clone https://github.com/CESNET/libnetconf2.git && cd libnetconf2 &&       git checkout master &&       mkdir build && cd build &&       cmake  -DCMAKE_BUILD_TYPE:String="Release" -DCMAKE_INSTALL_PREFIX:PATH=/usr -DENABLE_BUILD_TESTS=OFF .. &&       make -j2 &&       make install' returned a non-zero code: 1, aux=null)
2021-09-14 07:18:22,786 (ImageFromDockerfile.java:97) ERROR : The command '/bin/sh -c cd /opt/dev &&       git clone https://github.com/CESNET/libnetconf2.git && cd libnetconf2 &&       git checkout master &&       mkdir build && cd build &&       cmake  -DCMAKE_BUILD_TYPE:String="Release" -DCMAKE_INSTALL_PREFIX:PATH=/usr -DENABLE_BUILD_TESTS=OFF .. &&       make -j2 &&       make install' returned a non-zero code: 1

We use Ubuntu 18.4 and we get this:
apt-get install libyang1 libyang-dev sysrepo sysrepo-dev
Is there something wrong with this?

Well, it seems you are installing sysrepo v2 with having libyang v1 installed, I do not know where you get the packages from because they should not really be available on Ubuntu 18.04.

Dockerfile (2).txt
I am using this dockerfile.
Is there anything strange with it.

Ok so I my case I need to add build from source and using libyang1branch for all repos. Besides that I need to  add make
for libyang and sysrepo git repos and not use "ready apt packages" specified by ubuntu 18.4 link.
I will try that and see how it goes.
Thanks for help!

Thanks that worked! I get some warnings when building but no errors. Is it possible to tag with a version for all these libraries so I don't get latest?

You can tag the latest v1 releases but the libyang1 includes some more fixes, it is up to you which you want to use.

So which branch and tag should I checkout when retrieving source?

If you want to stay on versions 1 of all the projects (for now), I suggest you always simply checkout the libyang1 branch, no need to use any specific tag.

Do you know when you will have a tagged version of v2? And which repos will have a v2?

There is already a tag for v2 for all the projects (libyang, sysrepo, libnetconf2, and netopeer2), but it is the initial release that includes major problems that are fixed already in devel branches of the respective projects. There should be a new release (tag) soon.

Thanks that worked! I get some warnings when building but no errors. Is it possible to tag with a version for all these libraries so I don't get latest?


Save personalized window properties

I am working on another application that saves personalized window/monitor properties and reloads these properties when the window is re-opened at a later time.
The new application is to be used either stand-alone or as a complement to cortile. The reason for this is that I do not want to bloat the cortile source code and the associated configuration file too much.

I am working on another application that saves personalized window/monitor properties and reloads these properties when the window is re-opened at a later time.

Actually it was less work than expected, so I added some of the features directly into cortile.
At the moment the new features only work well on XFCE, other environments will be evaluated in upcoming releases.

The new application is to be used either stand-alone or as a complement to cortile. The reason for this is that I do not want to bloat the cortile source code and the associated configuration file too much.

Starting with version v2.3.0 the window positions and sticky states are saved and restored by cortile, based on the window class name.
For more advanced customization of window properties based on window title, time of the day, workspace configuration,  etc. please check out the alternative suggested in #21.
Any window that is marked as sticky on a given monitor will be again sticky when reopened. This function is not exactly the same as the one discussed in #17, but it may already cover some of the use cases.

Tested on Xfce and Openbox environments, closing it for now!


Change nginx base to alpine

Changed Nginx to use Alpine instead of Debian
Image size is 93 MB smaller and build times are shorter is 36-49s now is 23-36s.
Have been running the latest version built on nginx:alpine on my raspi for the day and nothing seems to be broken. Only add services with no API, so that's the only thing I haven't tested as I don't have one
Will be making alpine builds in my fork till this has been tested more and merged.
ghcr.io/c00ldude1oo/mhp           test             ec30655a4d49   35 minutes ago      19.7MB
ghcr.io/ajnart/mhp                latest           afa7d0ba6d4d   10 hours ago        113MB

Thank you for the PR @c00ldude1oo ! Approving 👍🏼


[Gardening] Cleanup TokenKinds.def

This shepherds #6618.

@swift-ci please test

@xwu I can't seem to request you for review, but I've made a lot of the changes that you specified on the original patch

This looks really great to me. Thanks @micahhainline!

@CodaFi Thanks, LGTM!

⛵


[5.10] Tests: Make some IRGen tests less deployment target dependent

Also, use %target-cpu lit substitution in IRGen/lto_autolink.swift.
Resolves rdar://121344608

@swift-ci please test


universe_structures_structure request error

I receive this kind of error when trying to take structure data automatically with google script code
Error: {"error":"Forbidden"}
doRequest
execute
invoke
universe_structures_structure
What does it mean and can I skip this kind of errors?

Oops, sorry for the delay @multru!
For your use case I would suggest to keep a static list and just vlookup the names of each location. This way you avoid making extra requests which will make things more performant. It also allows you to give custom names to each structure if you actually know the name but it's unresolveable via ESI.
Another option would be to move your logic into a custom function which would allow using JS exception handling features.
Feel free to stop by the Discord server if you want to chat about it more.

thx for your reply @Blacksmoke16
the exception is a great idea! I just forgot about this )
About performance, this script is built my static table. Because in a first way I'm checking if these names (stations, characters, ships) are already present in my table, and if no I request this data by GESI.
Issue is closed.


Creating a stand-alone example

CC @sethladd

I don't like having an example which isn't putting forward best practices - but we can improve it once we have dart-lang/build#718.

Let's make best practices easier first! 😄


Bugfix/crash when docker timesout

What do these changes do?

fixed #10 by retrying before actually crashing to keep an error if this happens again.
Bonus:
adds a message as to why the stack is updated.
Related issue number

Checklist

[x] I think the code is well written
[ ] Unit tests for the changes exist
[ ] Documentation reflects the changes
[x] Runs in the swarm
[x] If you design a new module, add your user to .github/CODEOWNERS

Codecov Report

Merging #11 into master will increase coverage by <.01%.
The diff coverage is 69.69%.

@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
+ Coverage   74.62%   74.63%   +<.01%
==========================================
  Files          20       20
  Lines         666      682      +16
==========================================
+ Hits          497      509      +12
- Misses        169      173       +4

Impacted Files
Coverage Δ

...vice_deployment_agent/docker_registries_watcher.py
91.66% <100%> (+0.59%)
:arrow_up:

...imcore_service_deployment_agent/git_url_watcher.py
92.47% <100%> (+0.51%)
:arrow_up:

...nt/src/simcore_service_deployment_agent/subtask.py
76.92% <100%> (+4.19%)
:arrow_up:

...mcore_service_deployment_agent/auto_deploy_task.py
46.48% <23.07%> (-1.03%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8057c38...c4391d2. Read the comment docs.