SB-1232 application startup with database snapshot

@carlspring , @sbespalov please review this PR.
Note: This PR includes BIN +9.45 MB (strongbox-data-service/src/main/resources/db/snapshot/strongbox-db-snapshot.zip)

We should keep the binary in he artifact repository manager. I assume we should have it as either a separate module, or -- most-likely -- a separate project.
@steve-todorov , @sbespalov : What are your thoughts on this?

I think we shouldn't store binaries, it should be produced form liquibase migrations and deployed into nexus instead.
also it probably should be a separate project so not affect on strongbox build time.
I suggested it like this in task comments here

I agree. We should have a separate module. If we have it as a separate
project in our Github organization, there will be a cyclic dependency
most-likely and we should try to avoid that as we should always be able to
build our project from scratch.
On Fri, 28 Dec 2018, 05:40 Sergey Bespalov<EMAIL_ADDRESS>wrote:

I think we shouldn't store binaries, it should be produced form liquibase
migrations and deployed into nexus instead.
also it probably should be a separate project so not affect on strongbox
build time.
I suggested it like this in task comments here
https://youtrack.carlspring.org/issue/SB-1232#focus=streamItem-84-1548-0-0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/strongbox/strongbox/pull/963#issuecomment-450283040,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXqaRo4C56S68-7snoAsLyBAwJ_yDMBks5u9ZKcgaJpZM4Zinyx
.

I agree. We should have a separate module. If we have it as a separate project in our Github organization, there will be a cyclic dependency most-likely and we should try to avoid that as we should always be able to build our project from scratch.
…
On Fri, 28 Dec 2018, 05:40 Sergey Bespalov @.*** wrote: I think we shouldn't store binaries, it should be produced form liquibase migrations and deployed into nexus instead. also it probably should be a separate project so not affect on strongbox build time. I suggested it like this in task comments here https://youtrack.carlspring.org/issue/SB-1232#focus=streamItem-84-1548-0-0 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#963 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ABXqaRo4C56S68-7snoAsLyBAwJ_yDMBks5u9ZKcgaJpZM4Zinyx .

actually I mean that it should be a separate project, not module. If it will be a just module then it will affect strongbox build time a lot.

I suggested it like this in task comments here

I'll try to implement it this way.

I've created https://github.com/strongbox/strongbox-db
@steve-todorov, could you please prepare a Jenkins build for this project ?
This work is still in progress.

@fuss86 , @sbespalov ,
My only concern here is to avoid introducing a cyclic dependency. If this is a separate project, it shouldn't depend on strongbox itself, as this will certainly break our strongbox-against-strongbox builds.
So far, I can see that there is no such dependency, but I would like to make sure we don't end up in this situation. @fuss86, could you please clarify your approach?
Also, I saw there were some dependencies which had explicitly defined versions in the strongbox-db project, instead of the strongbox-parent.

My only concern here is to avoid introducing a cyclic dependency. If this is a separate project, it shouldn't depend on strongbox itself, as this will certainly break our strongbox-against-strongbox builds.

It will not depend on strongbox. It will inherit from parent.

Hm... The strongbox-parent is part of the strongbox project.

@sbespalov , @carlspring please review this PR. It follows SB-1232 requirements. See also https://github.com/strongbox/strongbox-db


feat(d.ts): type creating hook subscriber return value

Hi.
Based on what I found writen in docs ...

// If returning any value other than undefined, the returned value will be used as primary key

... I feel like return type of subscriber param of creating table hook can be significantly improved.

Thanks! That's correct.

Hi @hekystyle @dfahlander, this change seems to be introducing type mismatch with strictFunctionTypes enabled in Typescript. It is enabled by default in strict mode.
Example
import Dexie from "dexie";

class DB extends Dexie {
  public readonly someTable!: Dexie.Table<any, string>;
}

const db = new DB("name");

db.transaction("rw", db.someTable, () => {});

(property) DB.someTable: Dexie.Table<any, string>
No overload matches this call.
  Overload 1 of 6, '(mode: TransactionMode, tables: readonly (string | Table<any, IndexableType, any>)[], scope: (trans: Transaction & { someTable: Table<any, string>; }) => void | PromiseLike<...>): PromiseExtended<...>', gave the following error.
    Argument of type 'Table<any, string>' is not assignable to parameter of type 'readonly (string | Table<any, IndexableType, any>)[]'.
      Type 'Table<any, string>' is missing the following properties from type 'readonly (string | Table<any, IndexableType, any>)[]': length, concat, join, slice, and 15 more.
  Overload 2 of 6, '(mode: TransactionMode, table: string | Table<any, IndexableType, any>, scope: (trans: Transaction & { someTable: Table<any, string>; }) => void | PromiseLike<...>): PromiseExtended<...>', gave the following error.
    Argument of type 'Table<any, string>' is not assignable to parameter of type 'string | Table<any, IndexableType, any>'.
      Type 'Table<any, string>' is not assignable to type 'Table<any, IndexableType, any>'.
        Types of property 'hook' are incompatible.
          Types of parameters 'subscriber' and 'subscriber' are incompatible.
            Type 'void | IndexableType | undefined' is not assignable to type 'string | void | undefined'.
              Type 'number' is not assignable to type 'string | void | undefined'.ts(2769)


translate: setup/kubernetes/platfomr-setup

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fleeto
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content_zh/OWNERS [fleeto]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

CI failed.
- ./public/docs/setup/kubernetes/ansible-install/index.html
  *  internally linking to /docs/setup/kubernetes/platform-setup/, which does not exist (line 1)
     Kubernetes platform setup
htmlproofer 3.9.1 | Error:  HTML-Proofer found 1 failure!


Remove .clang-format to suppress VSCode autoformatting.

This is necessary to suppress formatting when people are working on workerd in a VSCode workspace with "format on save" enabled.

recheck

I have read the CLA Document and I hereby sign the CLA


how to use the api with bypass account?

Hi,
Thanks for your sample , i get it that how to use the gmail api .
But , this is still a question : how to use the api with bypass account ? I only work it on my primary account.
Thanks !

haha , i got it


Method invocation on multiple ports of the same service, is it possible?

In what area(s)?

/area runtime
/area operator
With the current service invocation api, one can only call methods on one port of the remote service, can we support multiple ports?
Hypothetical api:
http://localhost:3500/v1.0/invoke/calculator/method-<remote-port>/add
When the remote port is different, the following actual requests on remote service will be called:
http://calculator:3001/add
http://calculator:3002/add
http://calculator:3003/add

So, dapr today only supports talking to your app over a single port. There are a lot of assumptions in the code based on that pattern today, so a change like this would not be trivial. If you need this functionality today, one way you could get it would be to run multiple daprd instances, one for each port on your application.
I'd love to hear a little more detail on the use case here. Are you running a single service that listens to multiple ports, and exposes different APIs on each of them? Are you running the same APIs on different ports listening to the same service? If you can flush this out a bit, it might help us come up with a better solution, or justify doing the work of delivering the solution you've suggested.

Thank you for your detailed reply!
We are developing a sass system,  which is an activity/event site generator.
The system itself is accessible from example.com, and tenants can login into this system to create their own activity sites,  those created sites would be accessible by their customers from xxxx.example.com, yyy.example.com, etc, to provide some kinds of online activity experiences. This is like Github Pages, but more than that, each site will also have a corresponding admin site accessible from xxx-admin.example.com, yyy-admin.example.com, that will allow tenants to customize the activitie sites for their targeting customers.
The activity site and its corresponding admin site will be packed into one image, and run as a container/dapr app when the tenant requests to create it. We use dapr for its ability to abstract the infrastructures so we can build different activity site images in a way that not worring about them.
Different images provide different online activity experiences, they do not have much in common except they each contains an activity site and an admin site. Our thought is opening two ports for them in the container, and use dapr's reverse proxy to route traffic to that container, based on what domain the end user is using, if they are customers and viewing xxxx.example.com, we proxy them to the activity site ports; if they are tenants and viewing xxx-admin.example.com, we proxy them to the admin site ports.

I have a similar use case but rather our Admn API is on one port and our main API is on another

I have a similar use case but rather our Admn API is on one port and our main API is on another

If it's the same process, you can run multiple ports and have Dapr connect to either the Admin or Main APIs, or maybe even dedicate a port for Dapr entirely.

Could anyone help add a tag to this issue?


Support multiple versions

Prepare for the crazy Minecraft 1.16+.

:tada: This issue has been resolved in version 1.13.0 :tada:
The release is available on:

npm package (@latest dist-tag)
Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


Make bootstrap_mon optional

For considering upgrades where a Ceph cluster already exists, I think it makes sense to use ceph-salt apply for the subset of states that are not related to a fresh deployment.  These are
    - .sshkey
    - .software
    - .container
    - .apparmor
    - .time-prep
    - .time-sync
    - .cephtools

If the remaining steps are dependent on the presense of a bootstrap_mon, then
    - .cephbootstrap
    - .find-admin-host
    - .cephorch
    - .ceph-admin

would run for a fresh deployment.  All other scenarios would skip these parts.
Note that cephtools above does have a bootstrap_mon condition for setting the permissions on /var/log/ceph that would need to be addressed.

We still need the "configure ssh orchestrator" part of cephbootstrap for the upgrade case (see #267)

Checking for bootstrap_minion presence to control if those steps are executed or not will force us to always have a bootstrap_minion in our config, even after the initial deployment, otherwise new minions will not be automatically added to the orchestrator.
If we want to keep the behavior of allowing the user to remove the bootstrap minion after day 1, then we need a new setting on ceph-salt config to control if those steps should be executed or not.
Not sure what is the best approach here.


Jenayah: Watch wisdomisgift.blogspot.com

Jenayah requests the watch of the watch_keyword wisdomisgift\.blogspot\.com. See the MS search here and the Stack Exchange search here.

wisdomisgift\.blogspot\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Add 'on:resize' event to Chart and ChartContext

@regexident I'm ready to merge if you are.
I noticed the typings on on:resize showed CustomEvent<any> instead of  CustomEvent<ChartResizeDetail> but could be a local environment thing (or just Svelte/Typescript being a pain, which I'm looking forward to Svelte 5's much improved support) as you have the correct createEventDispatcher<...> type

Oh not at all. Merge away!


[BEAM-79] merge gearpump-runner into master

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.007%) to 70.602% when pulling daa7566939e212095ef745ff004580bfe4209b38 on manuzhang:gearpump-runner into 1d9160fa3337704b9fbdc423796925be78b0087e on apache:master.

Coverage increased (+0.02%) to 70.599% when pulling 49d4ed59567852e978d14729c89b9ea91bb96c32 on manuzhang:gearpump-runner into 81c2e90f3a9d109121b686c25b642cc9f16ced43 on apache:master.

R: @kennknowles

@kennknowles split this into #3636 and #3637. I will leave it open for a while since it is referenced on mailing list

Great. Those PRs look just right. Fine to leave this open - but links will keep working even when close.

Coverage decreased (-0.08%) to 70.502% when pulling d56606dec3afab3f6bf6dbe7b77f4a23e21ee3c5 on manuzhang:gearpump-runner into 81c2e90f3a9d109121b686c25b642cc9f16ced43 on apache:master.

Coverage decreased (-0.007%) to 70.509% when pulling a56c5994574f17f076c02aabe49a3f9bdb1564b3 on manuzhang:gearpump-runner into 71196ec9cab9f393a73d068dd3ecbc255352dd0e on apache:master.

Changes Unknown when pulling b0ed584d1ba9aa0d7c7ff325d2ea25e6dfc13806 on manuzhang:gearpump-runner into ** on apache:master**.


Bump tracy

Tracy has been updated and contains a change I'd like to use without having to manually patch this crate.
Could the tracy dependency be updated an a new release made?

There's two issues I hit when running this:

This doesn't build, fix is easy, a couple lines in tracy_impl.rs need to change from

.span_alloc($name, function_name, file!(), line!(), 0);

to
.span_alloc(Some($name), function_name, file!(), line!(), 0);

A secondary issue that is kind of annoying is that the upstream crate is set up with a loose version range of crates that are allowed for tracy-client-sys.

If you already have a project locally with a Cargo.lock file, bumping the version number for profiling to take this code change may leave users with older versions of tracy-client-sys, which require version 0.8.2 of tracy.
But if someone runs cargo update, or they clone the project locally and didn't have a Cargo.lock file before, they will get the latest compatible version of tracy-client-sys and require tracy 0.9.

It's annoying that the "correct" version of tracy to use will not be well-defined. But I don't think we can do anything about it from this crate.

Hmm okay the change I want is in tracy-client-sys, so I should be able to just run cargo update and get 0.19.0 since tracy-client requires version = ">=0.17.0, <0.20.0". I remember trying but it not having any effect, but I'll check again

Closed in #56


Stacks: Hide walls of assets/arguments/etc in wallet

99% of users aren't interested in this kind of stuff, or rather scared by it
A default view with this stuff hidden and an advanced view where this information shows would be great

I think you already filed this one? https://github.com/leather-wallet/extension/issues/2764
We've already redesigned this screen in general, with these contract details going into an advanced view. The redesign should be live this quarter.


refactor: name duplication detection types

Additional thoughts: from the TS perspective, working with an array of configs is difficult because of generics around Value type. An easier approach in terms of TS would be API like this:
withSlices(countSlice).and(textSlice);

Which also means that you can get rid of "createSlice"
  withSlices({
    name: 'count',
    value: 0,
    actions: {
      inc: () => (prev) => prev + 1,
      reset: () => () => 0,
    },
  }).and({
    name: 'text',
    value: 'Hello',
    actions: {
      updateText: (newText: string) => () => newText,
      reset: () => () => 'Hello',
    },
  });

Any pipe-type API like this would be way more robust and easy to write in TS.
But as always, the question is do I want to think typescript-first, or api-first? Or is it possible to prioritize both at the same time?

Additional thoughts: from the TS perspective, working with an array of configs is difficult because of generics around Value type. An easier approach in terms of TS would be API like this:
withSlices(countSlice).and(textSlice);

Hmm, I'm not sure if people like it. I'm neutral or a bit negative.

But as always, the question is do I want to think typescript-first, or api-first? Or is it possible to prioritize both at the same time?

Yeah, well, my proposition is Zustand API is API-first (and then we have mutator hacks), and Jotai API is TS-first.
So, for now,
withSlices(countSlice, textSlice);

seems good. But, I can change my mind with user feedback in the future.


Correct threading model used by wmi calls

WbemScripting is apartment threaded according to its registry entries so switch multi-threaded OLE to apartment threaded enabling the global lock to be removed.
Correct missing CoUninitialize call when CoInitializeEx returns S_FALSE as documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms695279(v=vs.85).aspx
Also:

Cleanup OleError checking in Query.
Handle nil return from CreateObject by returning ErrNilCreateObject before it causes a panic. This has been seen in rare cases in production when built under go v1.6.

I am using this in production now along with the Enum changes. Who can we get to merge these pull requests? Pretty messy having to apply them manually. Is @mjibson no longer maintaining this? :).

I'm not maintaining this anymore. @gbrayut may be, or may know who should look at these PRs.

I staged these at https://github.com/StackExchange/wmi/tree/next and will do some testing before merging to master

Holding off on merging... appears to be a memory leak. See https://github.com/multiplay/wmi/pull/8#issuecomment-235421732

Merged in https://github.com/StackExchange/wmi/pull/16 but we kept the lock and ole.CoInitializeEx(0, ole.COINIT_MULTITHREADED) as ole.CoInitializeEx(0, ole.COINIT_APARTMENTTHREADED) caused a memory leak

Hmm... still seeing a memory leak, although much slower than the apartment threaded one:

I am going to try reverting the ole.CoUninitialize() logic back into an else block. We may not be initializing things correctly (this says it is only needed once per thread and SHOULD have matching calls to CoUninitialize) but I'm not sure how to do that when the method is called by many go routines.
We didn't see any issues with the old logic, and the nil check would remain to fix the potential panic reported on the multiplay repo.

Hmm that does sound very broken upstream as the MS docs do explicitly state, as you know:
To close the COM library gracefully on a thread, each successful call to CoInitialize or CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize.

With regards to balancing the calls that's not something you need to worry about as its uninitialized before the method returns by the defer so the calls are explicitly balanced and as the thread is locked for the duration that thread cant be used by any other executing goroutine for the duration.
Do you have a small production case you could share?

The code base is https://github.com/bosun-monitor/bosun/tree/master/cmd/scollector and https://github.com/bosun-monitor/bosun/blob/master/cmd/scollector/collectors/cpu_windows.go#L16 is an example of a collector that gets run every 15s. There are other collectors also creating WMI queries using 90-100 total go routines.
I suspect https://github.com/StackExchange/wmi/blob/master/wmi.go#L12 would have the same issue if it is run in a go benchmark, but I'm on day two of what I though would be a quick merge so I don't have time to test that.
So far testing with the old CoUninitialize code looks better, but I'll need to let it run for a few more hours to confirm:

I think I found it. It wasn't this PR, it was the Use _NewEnum one which was missing a call to Release(). https://github.com/StackExchange/wmi/pull/14#issuecomment-236031901
We will leave the new ole.CoUninitialize() code in, as testing that by itself did not cause any issues.

Cool thanks for the update @gbrayut that would explain why we never saw an issue in our production environment either.
If adding that missing Release() does indeed fix it adding back in the switch to apartment threading would also be good to see :)

I let it run overnight with apartment threading and it looks slightly higher but no leak. I'll merge that in to master shortly

Thanks!


cleanup mentions of experimental var for 2.0

Summary

Release Note

Documentation

Codecov Report

:exclamation: No coverage uploaded for pull request base (2.0-docs@781309d). Click here to learn what that means.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             2.0-docs    #2680   +/-   ##
===========================================
  Coverage            ?   30.02%
===========================================
  Files               ?      146
  Lines               ?     9293
  Branches            ?        0
===========================================
  Hits                ?     2790
  Misses              ?     6071
  Partials            ?      432

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Security 3.16a: Manage Locations - New Records linked to research team

The Manage Locations form should associate newly created records with the team_ID cached in the user's session cookie.
Tasks:

Start at app_server.py route associated with the create action, follow down to dao method.
Retrieve team_ID from self.session['team_ID'].
Add team_ID to parameters passed to Q_CREATE_LOCATION
Update Q_CREATE_LOCATION to utilize passed team_ID to set this attribute
Verify Q_CREATE_LOCATION is not used elsewhere

Test Plan:

Verify that new records are created with the appropriate value set for the team_ID attribute
Verify that record editing and deleting is unaffected by this change
Test for multiple users
Test when logged in to different teams

Test plan OK


python setup.py install vs. pip install

Running python setup.py install only produces one file in the virtualenv: lib/python3.4/site-packages/django_twitter_bootstrap-3.2.0_1-py3.4.egg.
However, running, pip install django-twitter-bootstrap produces django_twitter_bootstrap-3.2.0_1-py3.4.egg-info (so, +info) and lib/python3.4/site-packages/twitter_bootstrap. What's the difference? How can I properly install django-twitter-bootstrap with a local git clone?
Thank you.

@pquentin Sorry for not noticing this (yikes, this must've gotten buried in a mark-as-read with a lot of other noise).
So, while this method of installation from source doesn't leave the folder behind, the .egg is pretty much a zip of the package, on the path and it should be importable (though, the static files may not be found this way).
However, why install this way as opposed to a typical pip install (where you get pretty much everything you need).
Now, if you're dev'ing on this package, then I would suggest a dev-install of the package. So instead of python setup.py install, do pip install -e ..
Tell me if I'm missing something else though.

Also, given how long I missed this issue, perhaps I should relinquish primary maintenance of this package :/
Are you still using it much?

Yeah, I was trying to fix an issue, and at the time I used python setup.py install. I now usually do python setup.py develop - thanks for mentioning dev-isntall and pip install -e!
No worries at all for the delay, it wasn't a blocking issue, and I used django-twitter-bootstrap for some time without issues. I did stop using django-twitter-bootstrap and I'm now including bootstrap as a git submodule - this has its own issues; I still don't know what's the best way to work with bootstrap for a project that is supposed to continue to evolve year after year.
Thank you for thinking about me!


WriterSize parameter is incorrectly set

The WriterSize parameter is incorrectly set in the newClient method.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.627%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5243

Relevant Lines:
5316

💛  - Coveralls


HTTP Error 429

Here is the exact error I got today:
RROR: Unable to download webpage: HTTP Error 429: Too Many Requests (caused by HTTPError()); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
I was trying to get this video 5 minutes ago:
https://www.youtube.com/watch?v=OyLWjDl7Thw&index=3&list=WL
I am running a Mac on the most up to date OS and Safari web Browser
I hope this helps

Duplicate of #5138. See also this FAQ entry.


Doesn't work on AS 4.1

Plugin Error: Plugin "Flutter App Template Generator" is incompatible (supported only in IntelliJ IDEA).

@hayoi will you fix this plugin on AS 4.1.1?

Still not fixed.


Encryption Options for Unmanaged Disks(Page Blobs-Standard/Premium)

Hello,
I could not find documentation which compares encryption options for UNMANAGED Disks.
Perhaps adding a section for Unmanaged Disks here would help compare directly(current article only talks about Managed Disks).
Regards,
Aditya Garg

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b964cc95-9074-55f1-c150-f74933aa9222
Version Independent ID: 90d48cea-1b05-d320-f939-179cd5e6b195
Content: Overview of managed disk encryption options - Azure Virtual Machines
Content Source: articles/virtual-machines/disk-encryption-overview.md
Service: virtual-machines
Sub-service: disks
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

Alternatively, Perhaps this link
https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json
should call out Unmanaged disks(Page Blobs) explicitly. (including standard page blobs in gpv2 as well as premium page blobs)

@msmbaldwin
Can you please check and add your comments on this doc update request as applicable.

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. If you are still experiencing a problem, you might want to move this question to Microsoft Q&A: https://learn.microsoft.com/en-us/answers/tags/94/azure-virtual-machines. Because this issue does not relate to documentation, we are closing this issue. #please-close

Hi,the issue does relate to documentation-I do not understand why we are closing this.

@adi-garg Sorry, I'm closing out old issues that haven't been addressed and I had draft text that I didn't edit before pasting it here.
I closed the issue because it wasn't getting addressed here. I think you will get a quicker answer on Q&A. Unmanaged disks are being retired on September 30, 2025 so the main focus is moving folks off of unmanaged disks onto managed disks or other storage offerings before the retirement.


similarity measure 2 needs to get started

TO DOs for similarity measure 2:

I'm GONNA START

Finished embedding architecture


ios push freezes

Hi,
i have a problem when sending push notifications via the ios adapter.
The notification i'm sending is received but the request never get's finished so that it freezes all other outgoing notifications in the same process.
I cant find any thing in the logs. I'm just wondering if any other is having a similar issue?
I'm using both gcm and ios adapter.

What version of PHP is the server you are issuing the commands from running? I had a similar issue and updating to PHP 5.6.10 resolved the issue. See issue below:
https://bugs.php.net/bug.php?id=69393

Thank you so much for responding, i will check that out! I think this is a valid statement!

It seems that updating php version does the trick!


[Android] Set up tests for Android CHIPTool

Problem
Android CHIPTool has no testing infrastructure.
Proposed Solution
Set up emulator or Robolectric tests.

This is an older issue.
Android tests are required for v1.
They likely exist now in a form sufficient to close this, but I haven't validated.
Removing tag v1_triage_split_4

I still need to work on this. Closing #7286 as duplicate.

For Android tests, we can use Robolectric as local test infra to run many Android related tests on JVM without Emulator and real devices, and we can use android-test with Espresso API to test behaviors on Emulator. All of them can be run GitHub Actions for CI purpose. We can run Robolectric on JVM with a normal JVM and Android building environment, and run Emulator tests with android-emulator-runner. Hi @austinh0 , what is the current progress of this feature?

Currently, Matter Java APIs is tested with java-matter-controller in GitHub CI, I think we are talking about testing Matter Java API, not Android ChipTool example app, right?

We have Matter Java APIs tested with java-matter-controller in GitHub CI. Android CHIPTool need to run either in emulator or real device, so it is not good candidate to test Java API in GitHub CI.


Add Description to Groups Table

Groups have a description which would be useful to see in the table to provide some context on what a group means. Can we add a column to this table to show description.

cc/ @brendan-shea-pm


RSSI_PEER error messages in Home Assistant log

Home Assistant version (if applicable):
0.77.2
Describe the bug
I get error messages regarding the RSSI_PEER parameter being unknown for HomeMatic IP devices. Looks like this in the Home Assistant log:
Sep 02 22:07:55 hassbian hass[779]: 2018-09-02 22:07:55 ERROR (Thread-17) [pyhomematic.devicetypes.generic] HMGeneric.getValue: RSSI_PEER on<PHONE_NUMBER>5566:0 Exception: <Fault -5: 'Unknown Parameter value for value key: RSSI_PEER'>

Expected behavior
Use the correct parameter for IP devices, or don't check RSSI at all.
Additional context
Probably has been introduced with this PR: https://github.com/danielperna84/pyhomematic/pull/157

Yikes, it looks like I've messed this up when playing around with RSSI_PEER and RSSI_DEVICE. I do not have any HM-IP devices yet, so I did not notice this.
If all of the HMIP devices actually need RSSI_DEVICE then we could solve this through a helper class, just like HelperWired. I am about to pull the trigger on a set of HmIP-SWSD smoke detectors so I could start testing.

I found this explanation about the RSSI values. The values which are displayed in the hidden CCU interface represent RSSI_DEVICE/RSSI_PEER. Most of my devices only use RSSI_PEER, that's why I always got -65535 in RSSI_DEVICE. If the explaination mentioned above is correct it looks like sensors most likely only have RSSI_PEER and actuators may also (or only) have RSSI_DEVICE. That's a theory, though.
At least it looks like the "correct" RSSI value is device-specific (that's also what the document says), so I am thinking that this might not be a HM-IP-only thing. We could let the actual device implemenetation decide which attribute should be used for RSSI lookups.
The referenced commit is just a suggestion, we would obviously need to plug in the appropriate helper in all of the device classes.
Pros:

Devices can decide which value they expose for RSSI reporting.

Cons:

We need to be very careful when it comes to multiple inheritance. For example if we plug in the HelperRssiPeer into the GenericSwitch class we cannot really use HelperRssiDevice for IPSwitch any more.

@danielperna84 What do you think? Oh, and which device is causing that error? Is it a sensor or an actuator?

In my case it's a HmIP-PSM. So an actuator.
For most of my RF devices RSSI_PEER is the correct one as well. But for the HmIP-PSM it is RSSI_DEVICE. And for the HM-Sec-SC-2 (shutter contact) RSSI_DEVICE is the correct parameter as well.
The way you have done it in your commit is looking good. You can create a PR for that.

I think actively plugging in the required rssi-helper is the cleanest way. We had it broken for a bunch of devices for ages, now got them fixed, but broke others by doing that. Adding the helper where it's really needed would get rid of errors (like now with the IP-devices). And we can always patch in the helper for devices where it's missing.
So yes, to me this seems like the best approach. If it works with HASS as well I'm fine with your changes.

OK, I have cleaned up the branch (lint fixes) and I have also tested it with Home Assistant. RSSI reports for my devices are now OK (including my new HmIP-SWSD, which needs RSSI_DEVICE). In HASS we still need to add RSSI_DEVICE to HM_ATTRIBUTE_SUPPORT.
As I said before we'll remove RSSI reporting from untested devices entirely with this PR - although adding the appropriate helper should be fairly easy now. But this is probably not too bad, because when testing my RSSI changes with HASS I found out that the RSSI_DEVICE/RSSI_PEER events are not broadcasted regularly. Maybe I haven't tested this long enough, but for me it looks like these events are only broadcasted during device discovery and then the RSSI values are never updated again :cry:
That would mean that this whole RSSI thing is still a mess, unfortunately (at least for CCU users, I don't know how Homegear handles this) . At least the PR should fix this bug, the missing events for the RSSI attributes are a different story I think. I won't have access to my Dev machine in the next few weeks, so I cannot look into this any further at this time - I just wanted to get the PR ready.


Change default outDir of @typechain/hardhat to '.typechain'

(This is a draft, it seems something went wrong.)

Hey @krzkaczor, I think we don't wanna commit lockfiles in examples dir. It seem that running yarn install with --frozen-lockfile can get us an old version of local libraries (despite of file:../ installation path).

For posterity: see related discussion in https://github.com/dethcrypto/TypeChain/issues/423.


Fix contributor count

This means the pull request template doesn't work?
I did something wrong? 😢

I made the change through the UI, not sure if that was the reason maybe?


Pause until tomorrow

This is a feature suggestion.
I like using Stretchly all when I'm working, but I use the same laptop for work and leisure and I often find myself in a position where I'm watching videos or doing other things with my laptop in the evening. In those situations, I don't always like having the breaks.
What would be nice for that is a menu option to pause Stretchly until the next morning (e.g. 6am local time), similar to the "Disable until sunrise" feature in f.lux (https://justgetflux.com/).
What do you think about this?

I like it ;]
The only question is what would "tomorrow" mean.  I guess 6am could be ok

I'll work on it. I think I'll implement 2 versions

manual hour specification
specification of coordinates so we will be able to calculate the actual sunrise
@hovancik what do you think?

Oh, that's good, but imo it's easier to just push until morning than to manually specify time (if I understand correctly how custom pause will work) because that's much more common use case, for example when I'm finished with work for today and want to watch films etc.
Location thing is completely optional and available only through manual edit of 'config.json' so this shouldn't be that big of a deal, even more so this only needs approximate location so city or even country will work just fine.


Monitoring does not work for Windows Server Core worker nodes

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

Create new Windows Server Core VM
Add the windows server core VM to Rancher as a worker node
enable cluster monitoring (or have it already enabled in the cluster prior to joining)

Result:
exporter-node-binary-copy container fails to deploy with encountered an error during Start: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106). This prevents the exporter-node-windows-cluster-monitoring workload to finish deploying on the node.
Other details that may be helpful:
The same containers deploy and work without an issue on Windows Server (with Desktop experience, aka normal Windows Server) and appears isolated to Windows Server Core.

W0713 15:16:42.243971    7340 docker_container.go:238] Cannot create symbolic link because container log file doesn't exist!

E0713 15:16:42.243971    7340 remote_runtime.go:222] StartContainer "118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693" from runtime service failed: rpc error: code = Unknown desc = failed to start container "118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693": Error response from daemon: container 118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693 encountered an error during Start: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106)
E0713 15:16:42.245009    7340 kuberuntime_manager.go:801] init container start failed: RunContainerError: failed to start container "118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693": Error response from daemon: container 118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693 encountered an error during Start: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106)

E0713 15:16:42.245009    7340 pod_workers.go:191] Error syncing pod 52aacfee-2aab-4321-aad6-96ca0feaffc9 ("exporter-node-windows-cluster-monitoring-7lc6l_cattle-prometheus(52aacfee-2aab-4321-aad6-96ca0feaffc9)"), skipping: failed to "StartContainer" for "exporter-node-binary-copy" with RunContainerError: "failed to start container "118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693": Error response from daemon: container 118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693 encountered an error during Start: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106)"

 StartTime:2020-07-10 15:23:27 +0000 GMT,ContainerStatuses:[]ContainerStatus{ContainerStatus{Name:exporter-node,State:ContainerState{Waiting:&ContainerStateWaiting{Reason:PodInitializing,Message:,},Running:nil,Terminated:nil,},LastTerminationState:ContainerState{Waiting:nil,Running:nil,Terminated:nil,},Ready:false,RestartCount:0,Image:rancher/wmi_exporter-package:v0.0.3,ImageID:,ContainerID:,Started:*false,},},QOSClass:BestEffort,InitContainerStatuses:[]ContainerStatus{ContainerStatus{Name:exporter-node-binary-copy,State:ContainerState{Waiting:&ContainerStateWaiting{Reason:CrashLoopBackOff,Message:back-off 5m0s restarting failed container=exporter-node-binary-copy pod=exporter-node-windows-cluster-monitoring-7lc6l_cattle-prometheus(52aacfee-2aab-4321-aad6-96ca0feaffc9),},Running:nil,Terminated:nil,},LastTerminationState:ContainerState{Waiting:nil,Running:nil,Terminated:&ContainerStateTerminated{ExitCode:128,Signal:0,Reason:ContainerCannotRun,Message:container 784f0fb958deae0ac7cff7e905d356c8663298c83c6843145b8d5e50c0194751 encountered an error during Start: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106),StartedAt:2020-07-13 15:11:32 +0000 GMT,FinishedAt:2020-07-13 15:11:32 +0000 GMT,ContainerID:docker://784f0fb958deae0ac7cff7e905d356c8663298c83c6843145b8d5e50c0194751,},},Ready:false,RestartCount:846,Image:rancher/wmi_exporter-package:v0.0.3,ImageID:docker-pullable://rancher/wmi_exporter-package@sha256:556b1cf82783af8c0ec298315d48bf82cf6fb1864ffdf8736477a72d67af2be4,ContainerID:docker://784f0fb958deae0ac7cff7e905d356c8663298c83c6843145b8d5e50c0194751,Started:nil,},},NominatedNodeName:,PodIPs:[]PodIP{PodIP{IP:<IP_ADDRESS>,},},EphemeralContainerStatuses:[]ContainerStatus{},},} container id:  118f9659f56343cba90557e25f19a5ee47c15ab524b5156f143505d6107b8693
One other item to note: service-sidekick does a goroutine panic on a Windows Server Core VM while running but it reports that it recovers. This behavior is not seen on a normal windows server node.
I0710 15:23:40.415037    5272 device_windows.go:124] Created HostComputeNetwork vxlan0
panic: reflect: Field index out of range [recovered]
        panic: reflect: Field index out of range

goroutine 1 [running]:
encoding/json.(*encodeState).marshal.func1(0xc0001db540)
        /usr/local/go/src/encoding/json/encode.go:301 +0xa1
panic(0x121d7c0, 0x157a2b0)
        /usr/local/go/src/runtime/panic.go:513 +0x1c7
reflect.Value.Field(0x130ff60, 0xc00032b3e0, 0x99, 0x2d383632342d3032, 0xc0002e9e30, 0xc0000c82c0, 0x12ee720)
        /usr/local/go/src/reflect/value.go:816 +0x148
encoding/json.fieldByIndex(0x130ff60, 0xc00032b3e0, 0x99, 0xc00034a6d0, 0x1, 0x1, 0x12ee720, 0xc00032b3e0, 0x99)
        /usr/local/go/src/encoding/json/encode.go:842 +0x65
encoding/json.(*structEncoder).encode(0xc0002e9e00, 0xc0000c82c0, 0x130ff60, 0xc00032b3e0, 0x99, 0x1300100)
        /usr/local/go/src/encoding/json/encode.go:635 +0x149
encoding/json.(*structEncoder).encode-fm(0xc0000c82c0, 0x130ff60, 0xc00032b3e0, 0x99, 0xc0001d0100)
        /usr/local/go/src/encoding/json/encode.go:661 +0x6b
encoding/json.(*encodeState).reflectValue(0xc0000c82c0, 0x130ff60, 0xc00032b3e0, 0x99, 0x1fd0100)
        /usr/local/go/src/encoding/json/encode.go:333 +0x89
encoding/json.(*encodeState).marshal(0xc0000c82c0, 0x130ff60, 0xc00032b3e0, 0x100, 0x0, 0x0)
        /usr/local/go/src/encoding/json/encode.go:305 +0xfb
encoding/json.Marshal(0x130ff60, 0xc00032b3e0, 0x130ff60, 0xc00032b3e0, 0x0, 0x0, 0x0)
        /usr/local/go/src/encoding/json/encode.go:160 +0x59
github.com/coreos/flannel/vendor/github.com/Microsoft/hcsshim/hcn.modifyNetwork(0xc0004c6de0, 0x24, 0xc000514460, 0x6a, 0xc000514460, 0x6a, 0x0)
        /go/src/github.com/coreos/flannel/vendor/github.com/Microsoft/hcsshim/hcn/hcnnetwork.go:224 +0x1d1
github.com/coreos/flannel/vendor/github.com/Microsoft/hcsshim/hcn.(*HostComputeNetwork).ModifyNetworkSettings(0xc0003de1e0, 0xc000069d00, 0xc00002e540, 0x31)
        /go/src/github.com/coreos/flannel/vendor/github.com/Microsoft/hcsshim/hcn/hcnnetwork.go:356 +0x13c
github.com/coreos/flannel/vendor/github.com/Microsoft/hcsshim/hcn.(*HostComputeNetwork).AddPolicy(0xc0003de1e0, 0xc00032b1d0, 0x1, 0x1, 0x2, 0x8)
        /go/src/github.com/coreos/flannel/vendor/github.com/Microsoft/hcsshim/hcn/hcnnetwork.go:377 +0x1b9
github.com/coreos/flannel/backend/vxlan.ensureLink(0xc000125480, 0xc000125480, 0x130fc60, 0x1)
        /go/src/github.com/coreos/flannel/backend/vxlan/device_windows.go:147 +0x348
github.com/coreos/flannel/backend/vxlan.newVXLANDevice(0xc0002e9b30, 0xc0002e9b30, 0xc00023a4c0, 0xc0001baf60)
        /go/src/github.com/coreos/flannel/backend/vxlan/device_windows.go:47 +0x7a
github.com/coreos/flannel/backend/vxlan.(*VXLANBackend).RegisterNetwork(0xc0006310a0, 0x2330138, 0xc00023a4c0, 0x100000000, 0xc000000000, 0xc0000ae640, 0x0, 0xc00009c082, 0xf, 0xc000663698)
        /go/src/github.com/coreos/flannel/backend/vxlan/vxlan_windows.go:149 +0x514
main.main()
        /go/src/github.com/coreos/flannel/main.go:289 +0x735

More logs available on request.
Cluster information
Cluster type: Hosted Rancher
Machine type: AWS t3a.xlarge
AMI: Windows_Server-1909-English-Core-Base-2020.06.10 (ami-0e9662f7dc78f5a18)
OS: Windows Server Datacenter 10.0.18363.900
Rancher v2.4.5
K8s v1.18.3
Docker version 19.03.5, build 2ee0c57608
gz#11061
gz#13205

Check the crash log, we have a project to package window node export windows_exporter, logs show that container crash when modifyNetwork github.com/Microsoft/hcsshim/hcn/hcnnetwork.go:224, seems like this node HCS query result isn't expected one. But I'm not familiar debug with window HCS, may windows colleague help?

Also need to make sure monitoring v1 works on 1909

@rosskirkpat I suspect the root cause here is because your Windows node doesn't have c:\etc\wmi-exporter\wmi-exporter.exe, which is the file that the exporter-node-binary-copy container tries to transfer to a new location (as shown in the ConfigMap it mounts as the Powershell script to be run on start). You also similarly may not have flannel installed as a service.
Did the cluster that you were working with have Windows support already enabled via Rancher (on cluster create)?
If you added the windows server core VM to Rancher as a worker node to a cluster that did not have Windows support enabled on creation, some of the bootstrapping we do in order to get services like flannel or wmi_exporter running on your machine may not have been run. This would explain both the errors you noted in the issue and, as noted in the docs, can only be resolved by creating a new cluster with that node.

@aiyengar2

Did the cluster that you were working with have Windows support already enabled via Rancher (on cluster create)?

Yes, it did. Seeing as the cluster is long gone at this point, I'm spinning up a new 2.4.11 mixed cluster with k8s v1.18.12 to validate the level of functionality of Windows 1909 Server Core. I'll update here with my results.

@rosskirkpat I was able to spin up a GKE cluster with version Windows Server version 1909 Datacenter Core for Containers and deploy Monitoring V1 on it successfully, so this may be an environment-specific issue.
More details
I spun up a k8s cluster using the following configurations for GCE nodes:

[ubuntu] 1 Ubuntu worker/etcd/controlplane
[default-access-1809] 1 Windows 2019 Server, where Identity and API access -> Access Scopes -> Allow default access
[default-access-1909] 1 Windows 1909 Datacenter Core for Containers, where Identity and API access -> Access Scopes -> Allow default access
[allow-all-access-1909] 1 Windows 1909 Datacenter Core for Containers, where Identity and API access -> Access Scopes -> Allow full access to all Cloud APIs

What I noticed, however, was that the deployment of cattle-node-agent-windows on node default-access-1909 was stuck on ContainerCreating.
kubectl describe revealed that this was caused by a failure to create the pod sandbox.

Upon checking the kubelet logs on the default-access-1909 Windows host to see why that might be the case, I found the following logs showed up:

This issue did not affect default-access-1809 or allow-all-access-1909 and these specific error logs are also missing from those nodes.
Once I removed default-access-1909 from the cluster, Monitoring V1 was successfully deployed, so this might just be a GCE-specific issue.

On 2.5.4-rc7

Deployed 1909 windows server core version
monitoring v1 fails to deploy
Error on exporter-node-windows-cluster-monitoring pod: Error: failed to start container "exporter-node-binary-copy": Error response from daemon: container exporter-node-binary-copy encountered an error during hcsshim::System::Start: failure in a Windows system call: The virtual machine or container exited unexpectedly. (0xc0370106)

On 2.5.5, using AMI from GCP - windows-server-1909-dc-core-for-containers-v20210112

Deploy Windows 1909 - 1 etcd/control/worker linux node, 2 linux worker nodes and 3 windows worker nodes.
Enable monitoring v1 - 0.2.0. Monitoring is seen enabled successfully.
exporter-node-windows-cluster-monitoring workload deployed successfully on Windows nodes.
Metrics from windows nodes are available.

On 2.5.5, using AMI from GCP - windows-server-1909-dc-core-for-containers-v20210112

Deploy Windows 1909 - 1 etcd/control/worker linux node, 2 linux worker nodes and 3 windows worker nodes.
Enable monitoring v1 - 0.2.0. Monitoring is seen enabled successfully.
exporter-node-windows-cluster-monitoring workload deployed successfully on Windows nodes.
Metrics from windows nodes are available.

@sowmyav27 can we check if the issue still appears in AWS (tested in https://github.com/rancher/rancher/issues/27911#issuecomment-750579236)?
Given that Monitoring V1 works in GKE, this could be an AMI specific issue.

@sowmyav27 can we check if the issue still appears in AWS (tested in https://github.com/rancher/rancher/issues/27911#issuecomment-750579236)?
Given that Monitoring V1 works in GKE, this could be an AMI specific issue.

Also, instead of using Windows_Server-1909-English-Core-Base-2020.06.10 (ami-0e9662f7dc78f5a18), I think we should try to reproduce using the Containers equivalent of the AMI, i.e.
Windows_Server-1909-English-Core-ContainersLatest-2021.01.13 (ami-08c8719f1e743ff72)
This more closely aligns with what we tested in GCP, which was Datacenter Core for Containers, not Datacenter Core Base.
Based on discussion offline during the initial error in AWS reproduced in https://github.com/rancher/rancher/issues/27911#issuecomment-750579236, one of the things I discovered was that the AMI itself did not have Docker EE installed at all so we ran the following as part of the provisioning step manually in order to get Docker EE installed:
iwr -outf docker-install.ps1 -uri https://gist.githubusercontent.com/thxCode/cd8ec26795a56eb120b57675f0c067cf/raw/4129222b07d17fb591182ca839ce6d83e6a203e9/docker-install.ps1; ./docker-install.ps1 -Version 19.03

However, it's possible that more changes were required on the host in order to actually get containers on the Server Core Base.

Also, instead of using Windows_Server-1909-English-Core-Base-2020.06.10 (ami-0e9662f7dc78f5a18), I think we should try to reproduce using the Containers equivalent of the AMI, i.e.
Windows_Server-1909-English-Core-ContainersLatest-2021.01.13 (ami-08c8719f1e743ff72)
This more closely aligns with what we tested in GCP, which was Datacenter Core for Containers, not Datacenter Core Base.
Based on discussion offline during the initial error in AWS reproduced in https://github.com/rancher/rancher/issues/27911#issuecomment-750579236, one of the things I discovered was that the AMI itself did not have Docker EE installed at all so we ran the following as part of the provisioning step manually in order to get Docker EE installed:
iwr -outf docker-install.ps1 -uri https://gist.githubusercontent.com/thxCode/cd8ec26795a56eb120b57675f0c067cf/raw/4129222b07d17fb591182ca839ce6d83e6a203e9/docker-install.ps1; ./docker-install.ps1 -Version 19.03

However, it's possible that more changes were required on the host in order to actually get containers on the Server Core Base.

Tested on 2.5-head (2ae4cf117ac988ce409ca0617d246008f74c7aaa) using Windows_Server-1909-English-Core-ContainersLatest-2021.01.13 as the base AMI

Deployed 1909 windows server ContainersLatest version
monitoring v1 fails to deploy
Error on exporter-node-windows-cluster-monitoring Error from server (BadRequest): container "exporter-node" in pod "exporter-node-windows-cluster-monitoring-rfm88" is waiting to start: PodInitializing

Tested on 2.5-head (2ae4cf117ac988ce409ca0617d246008f74c7aaa) using Windows_Server-1909-English-Core-ContainersLatest-2021.01.13 as the base AMI

Deployed 1909 windows server ContainersLatest version
monitoring v1 fails to deploy
Error on exporter-node-windows-cluster-monitoring Error from server (BadRequest): container "exporter-node" in pod "exporter-node-windows-cluster-monitoring-rfm88" is waiting to start: PodInitializing

@slickwarren - can you please test on a different version of Windows_Server?  A version prior to 1909.  Thanks.

@SheilaghM We have validated monitoring on windows as said here using Windows_Server-1909-English-Core-ContainersLatest-2021.01.13. Monitoring v1 works on 1903/1809. It also works on 1909 using GCE nodes. This issue seems specific to AWS AMIs.

Upgrading the version of wmi_exporter seems to do the trick!
As noted in the PR linked above, I suspect that the issue that we see was caused by the following announcement: https://support.microsoft.com/en-us/topic/you-might-encounter-issues-when-using-windows-server-containers-with-the-february-11-2020-security-update-release-b9a8fcae-950d-7a0b-ac7c-cb6b294cb809.
wmi_exporter-package v0.0.3 was built in September 17, 2019 while v0.0.4 (which works) was built on October 26th, 2020.
AWS docs seem to indicate that they keep up to date with Windows security updates (see https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-ami-version-history.html#amis-2020), but I'm not sure about GCE. On looking at the actual VM, I noticed that Get-Hotfix didn't result in nearly as many Windows patches applied, so it's possible / likely they could have not absorbed that security fix yet.

@sowmyav27 @slickwarren we need to test two new chart versions for this release: v0.1.5 (for k8s 1.15 support) and v0.2.1 (for k8s 1.16+). The only changes introduced to both are to bump the wmi_exporter-package version, so only Windows clusters need to be tested.
Both versions exist in dev-v2.5, but have not been backported into dev-v2.4.
@Jono-SUSE-Rancher @SheilaghM we also need to create a separate issue to backport these two charts into the 2.4 release line once this has been tested. Which release do we want to target that for?

I deployed windows cluster on AWS (us-east-1) by using rancher v2.5.4-rc4 with kubernetes v1.18.15-rancher2-1. Also successfully deployed v1 monitoring v0.2.1 and all the metrics from the windows worker machine are visible in Rancher Amber UI as well as in Grafana.

The same as above stands for monitoring v0.1.5 and kubernetes v1.15.12-rancher2-8 on rancher v2.5.6-rc4 (the unsupported version kubernetes_version: v1.15.12-rancher2-8 specified in 'Edit as yaml' when creating the cluster).
Also here all metrics are visible in Amber UI & Grafana and all the related resources are Ready and healthy.


Camera can get locked with old fw version

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D455 and D435

Firmware Version
<IP_ADDRESS>

OS
Ubuntu 18.04

Platform
PC

SDK Version
2.41.0

Language
shell scripts

Segment
Robot

Issue Description (feature request)
The D435 is downgraded to <IP_ADDRESS> for older release of our robot.  It is upgraded to <IP_ADDRESS> for latest release.
After several cycles of up and down versioning the camera will report "device is locked for update" and will not accept an update.  This is expected.   The issue is that the camera is stuck at the older version of <IP_ADDRESS>.   the FW-update tool reports "Use firmware version higher than: <IP_ADDRESS>"    It will not accept version <IP_ADDRESS>.
The correct thing I believe is for the camera to accept any version that is equal to or greater than the highest_fw_version that has been applied to the camera.   This would allow me to get the camera from <IP_ADDRESS> to <IP_ADDRESS> which is the version of our current release.   As it is the camera has to be removed and replaced with a new unit get the correct version on the robot.

Hi @kenmccormackagility   There was a similar case in November 2020.
https://github.com/IntelRealSense/librealsense/issues/7783
The eventual successful solution in that particular case was to wait for the release of a newer firmware version than the one that the camera believed was currently installed and then install it.
https://github.com/IntelRealSense/librealsense/issues/7783#issuecomment-737898217

Hi @kenmccormackagility   There was a similar case in November 2020.
https://github.com/IntelRealSense/librealsense/issues/7783
The eventual successful solution in that particular case was to wait for the release of a newer firmware version than the one that the camera believed was currently installed and then install it.
https://github.com/IntelRealSense/librealsense/issues/7783#issuecomment-737898217

Hi @kenmccormackagility   There was a similar case in November 2020.
https://github.com/IntelRealSense/librealsense/issues/7783
The eventual successful solution was to wait for the release of a newer firmware version than the one that the camera believed was currently installed and then install it.
https://github.com/IntelRealSense/librealsense/issues/7783#issuecomment-737898217

Hi @kenmccormackagility   There was a similar case in November 2020.
https://github.com/IntelRealSense/librealsense/issues/7783
The eventual successful solution was to wait for the release of a newer firmware version than the one that the camera believed was currently installed and then install it.
https://github.com/IntelRealSense/librealsense/issues/7783#issuecomment-737898217

Thanks for the link to the similar issue (#7783)   Our issue is  similar
but perhaps is a feature request rather than a bug.  The realsense is
deployed in a commercial robot and waiting for an upgrade is not an
option.    It seems that a camera that is locked at an older version should
always be upgradable to the newest version that has been previously
installed on the camera.  It should not be limited to newest+1.   As it is
now the camera cannot be upgraded in the field until a new release that is
newer than 05.12.10.   Being locked at an older version the camera will not
work in the robot.
A second question that is related.   Does anyone know the reason a camera
would get locked in the first place?   I've tested two other cameras
bouncing between two versions (05.12.03/05.12.08) and they seem to
indefinitely update.   Yet I have two other cameras that stopped updates
and are now locked out.
On Tue, Jan 19, 2021 at 4:22 AM MartyG-RealSense<EMAIL_ADDRESS>wrote:

Hi @kenmccormackagility https://github.com/kenmccormackagility There
was a similar case in November 2020.
#7783 https://github.com/IntelRealSense/librealsense/issues/7783
The eventual successful solution was to wait for the release of a newer
firmware version than the one that the camera believed was currently
installed and then install it.
#7783 (comment)
https://github.com/IntelRealSense/librealsense/issues/7783#issuecomment-737898217
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/8186#issuecomment-762807389,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5LM34NIAT2BJNRYNJ5O3TS2V2PVANCNFSM4WIEUAKQ
.

Thanks for the link to the similar issue (#7783)   Our issue is  similar
but perhaps is a feature request rather than a bug.  The realsense is
deployed in a commercial robot and waiting for an upgrade is not an
option.    It seems that a camera that is locked at an older version should
always be upgradable to the newest version that has been previously
installed on the camera.  It should not be limited to newest+1.   As it is
now the camera cannot be upgraded in the field until a new release that is
newer than 05.12.10.   Being locked at an older version the camera will not
work in the robot.
A second question that is related.   Does anyone know the reason a camera
would get locked in the first place?   I've tested two other cameras
bouncing between two versions (05.12.03/05.12.08) and they seem to
indefinitely update.   Yet I have two other cameras that stopped updates
and are now locked out.
On Tue, Jan 19, 2021 at 4:22 AM MartyG-RealSense<EMAIL_ADDRESS>wrote:

Hi @kenmccormackagility https://github.com/kenmccormackagility There
was a similar case in November 2020.
#7783 https://github.com/IntelRealSense/librealsense/issues/7783
The eventual successful solution was to wait for the release of a newer
firmware version than the one that the camera believed was currently
installed and then install it.
#7783 (comment)
https://github.com/IntelRealSense/librealsense/issues/7783#issuecomment-737898217
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/8186#issuecomment-762807389,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5LM34NIAT2BJNRYNJ5O3TS2V2PVANCNFSM4WIEUAKQ
.

Could you confirm please whether updating the camera in the RealSense Viewer instead of rs-fw-update, as suggested above, enabled the camera to be successfully updated to <IP_ADDRESS> please?
Is using the Viewer as a means of updating the firmware in future instead of the rs-fw-update tool an option for your commercial operation?
Regarding your second question, the official information about the 20-downgrade limit in the data sheet document for the 400 Series cameras is quoted below.

The firmware update engine does not allow infinite update cycles between older and current versions of firmware.  The engine will establish a baseline version of firmware based on the latest firmware version installed.  The engine will allow a return to a previous version or baseline version of firmware up to 20 times.  After the 20th update, the engine will only allow an update to a firmware revision higher than the baseline version.

As far as I know, only a downgrade to an older firmware version than the currently installed version - or to the version considered as the camera's 'baseline' firmware - counts as one of the 20 permitted attempts, not an upgrade (e.g from 5.12.3 to the newer 5.12.8).  The origin of the 20 downgrade limit dates back to the SR300 RealSense camera model launched in early 2016.  I do not know of a circumstance that would cause the counter to reset and allow unlimited downgrades though, as the data sheet document statement represents the extent of the publicly available information about the 20-limit.

Could you confirm please whether updating the camera in the RealSense Viewer instead of rs-fw-update, as suggested above, enabled the camera to be successfully updated to <IP_ADDRESS> please?
Is using the Viewer as a means of updating the firmware in future instead of the rs-fw-update tool an option for your commercial operation?
Regarding your second question, the official information about the 20-downgrade limit in the data sheet document for the 400 Series cameras is quoted below.

The firmware update engine does not allow infinite update cycles between older and current versions of firmware.  The engine will establish a baseline version of firmware based on the latest firmware version installed.  The engine will allow a return to a previous version or baseline version of firmware up to 20 times.  After the 20th update, the engine will only allow an update to a firmware revision higher than the baseline version.

As far as I know, only a downgrade to an older firmware version than the currently installed version - or to the version considered as the camera's 'baseline' firmware - counts as one of the 20 permitted attempts, not an upgrade (e.g from 5.12.3 to the newer 5.12.8).  The origin of the 20 downgrade limit dates back to the SR300 RealSense camera model launched in early 2016.  I do not know of a circumstance that would cause the counter to reset and allow unlimited downgrades though, as the data sheet document statement represents the extent of the publicly available information about the 20-limit.

I have verified that the camera *does not *upgrade from <IP_ADDRESS> using
the realsense viewer.      It reports the following

Requesting to switch to recovery mode.
Recovery device connected, starting update.
ERROR:UNKNOWN in rs2_update_firmware_cpp()  Device:<PHONE_NUMBER>43 is
locked for update.
Use firmware version higher than <IP_ADDRESS>"

Upgrading with the realsense-viewer is an option.  However, since both the
rs-fw-update and the viewer use the same updating libraries it seems like a
command line tool can be devised that would work as good as the viewer.
Thanks for the information on the 20 cycle limitation.
On Sat, Jan 23, 2021 at 9:34 AM MartyG-RealSense<EMAIL_ADDRESS>wrote:

Could you confirm please whether updating the camera in the RealSense
Viewer instead of rs-fw-update, as suggested above, enabled the camera to
be successfully updated to <IP_ADDRESS> please?
Is using the Viewer as a means of updating the firmware in future instead
of the rs-fw-update tool an option for your commercial operation?
Regarding your second question, the official information about the
20-downgrade limit in the data sheet document for the 400 Series cameras is
quoted below.
The firmware update engine does not allow infinite update cycles between
older and current versions of firmware. The engine will establish a
baseline version of firmware based on the latest firmware version
installed. The engine will allow a return to a previous version or baseline
version of firmware up to 20 times. After the 20th update, the engine will
only allow an update to a firmware revision higher than the baseline
version.
As far as I know, only a downgrade to an older firmware version than the
currently installed version - or to the version considered as the camera's
'baseline' firmware - counts as one of the 20 permitted attempts, not an
upgrade (e.g from 5.12.3 to the newer 5.12.8). The origin of the 20
downgrade limit dates back to the SR300 RealSense camera model launched in
early 2016. I do not know of a circumstance that would cause the counter to
reset and allow unlimited downgrades though, as the data sheet document
statement represents the extent of the publicly available information about
the 20-limit.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/8186#issuecomment-766146261,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5LM3YSJULGZZSRNSIFXITS3MCBBANCNFSM4WIEUAKQ
.

I have verified that the camera *does not *upgrade from <IP_ADDRESS> using
the realsense viewer.      It reports the following

Requesting to switch to recovery mode.
Recovery device connected, starting update.
ERROR:UNKNOWN in rs2_update_firmware_cpp()  Device:<PHONE_NUMBER>43 is
locked for update.
Use firmware version higher than <IP_ADDRESS>"

Upgrading with the realsense-viewer is an option.  However, since both the
rs-fw-update and the viewer use the same updating libraries it seems like a
command line tool can be devised that would work as good as the viewer.
Thanks for the information on the 20 cycle limitation.
On Sat, Jan 23, 2021 at 9:34 AM MartyG-RealSense<EMAIL_ADDRESS>wrote:

Could you confirm please whether updating the camera in the RealSense
Viewer instead of rs-fw-update, as suggested above, enabled the camera to
be successfully updated to <IP_ADDRESS> please?
Is using the Viewer as a means of updating the firmware in future instead
of the rs-fw-update tool an option for your commercial operation?
Regarding your second question, the official information about the
20-downgrade limit in the data sheet document for the 400 Series cameras is
quoted below.
The firmware update engine does not allow infinite update cycles between
older and current versions of firmware. The engine will establish a
baseline version of firmware based on the latest firmware version
installed. The engine will allow a return to a previous version or baseline
version of firmware up to 20 times. After the 20th update, the engine will
only allow an update to a firmware revision higher than the baseline
version.
As far as I know, only a downgrade to an older firmware version than the
currently installed version - or to the version considered as the camera's
'baseline' firmware - counts as one of the 20 permitted attempts, not an
upgrade (e.g from 5.12.3 to the newer 5.12.8). The origin of the 20
downgrade limit dates back to the SR300 RealSense camera model launched in
early 2016. I do not know of a circumstance that would cause the counter to
reset and allow unlimited downgrades though, as the data sheet document
statement represents the extent of the publicly available information about
the 20-limit.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/8186#issuecomment-766146261,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5LM3YSJULGZZSRNSIFXITS3MCBBANCNFSM4WIEUAKQ
.

Thanks very much for the information @kenmccormackagility
Though updating through rs-fw-update or the Viewer are the recommended update methods, it is also possible to check firmware information and update the firmware with scripting instructions:
https://github.com/IntelRealSense/librealsense/issues/4416

Thanks very much for the information @kenmccormackagility
Though updating through rs-fw-update or the Viewer are the recommended update methods, it is also possible to check firmware information and update the firmware with scripting instructions:
https://github.com/IntelRealSense/librealsense/issues/4416

I have manually verified that 20 or so cycles of changing versions on a
camera will cause it to lockup and fail to accept new updates that are not
one version greater than the newest version seen on the device.   I have
also verified that if the version+1 is applied to the device that it resets
the up/down upgrade count back to zero and thus allows updates as desired
freely.
This provided a work around for the issue seen.   We use the production
versions of FW release and if a customer upgrades/down grades enough to
trigger the issue we will service the device by writing one of the "minor"
releases to the camera.  After this any version that is compatible
including the current baseline can be put back on.
The feature requested here is that the device should always be able to
return to the baseline version irregardless of the number of up/down
cycles.
This issue can be closed.
On Tue, Jan 26, 2021 at 10:02 AM MartyG-RealSense<EMAIL_ADDRESS>wrote:

Thanks very much for the information @kenmccormackagility
https://github.com/kenmccormackagility
Though updating through rs-fw-update or the Viewer are the recommended
update methods, it is also possible to check firmware information and
update the firmware with scripting instructions:
#4416 https://github.com/IntelRealSense/librealsense/issues/4416
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/8186#issuecomment-767723207,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5LM324YYQKUK2Z2KV2YZLS337UPANCNFSM4WIEUAKQ
.

I have manually verified that 20 or so cycles of changing versions on a
camera will cause it to lockup and fail to accept new updates that are not
one version greater than the newest version seen on the device.   I have
also verified that if the version+1 is applied to the device that it resets
the up/down upgrade count back to zero and thus allows updates as desired
freely.
This provided a work around for the issue seen.   We use the production
versions of FW release and if a customer upgrades/down grades enough to
trigger the issue we will service the device by writing one of the "minor"
releases to the camera.  After this any version that is compatible
including the current baseline can be put back on.
The feature requested here is that the device should always be able to
return to the baseline version irregardless of the number of up/down
cycles.
This issue can be closed.
On Tue, Jan 26, 2021 at 10:02 AM MartyG-RealSense<EMAIL_ADDRESS>wrote:

Thanks very much for the information @kenmccormackagility
https://github.com/kenmccormackagility
Though updating through rs-fw-update or the Viewer are the recommended
update methods, it is also possible to check firmware information and
update the firmware with scripting instructions:
#4416 https://github.com/IntelRealSense/librealsense/issues/4416
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/8186#issuecomment-767723207,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5LM324YYQKUK2Z2KV2YZLS337UPANCNFSM4WIEUAKQ
.

Thanks so much @kenmccormackagility for the detailed update for the benefit of RealSense cmmunity members reading this case in future!  I am very pleased that you reached a satisfactory solution.

Thanks so much @kenmccormackagility for the detailed update for the benefit of RealSense cmmunity members reading this case in future!  I am very pleased that you reached a satisfactory solution.

Hello, what is the purpose of the 20 times  limit to downgrading？

Hi @liuxiaodong528  There is not an official explanation, but unofficially my understanding is that it is a protective measure to stop multiple changes to the camera firmware being made by an unauthorized source such as harmful 'malware' software.  Once the downgrade limit of 20 is reached then from that point onward, the camera can only be upgraded to a newer firmware version than the currently installed version.


Linear fitter weights

This should fix the line you asked about (weights = weights.flatten() at L471), as well as adding some missing checks. Sorry, didn't get to work on this much on Friday and haven't tried refactoring the loops.

Thanks James.


Update Provider name - Pediatric Preclinical Testing Consortium

Description
Observed: Preclinical Pediatric Testing Consortium
Expected:  Pediatric Preclinical Testing Consortium
http://www.ncipptc.org/
Acceptance criteria

[ ] Provider name changed in the db
[ ] changes are propagated to prod

I made this change on the Dev branch of the DB

@Afollet could you please also check that it is American English, the original ticket I wrote corrected for British spelling.

It is "Pediatric Preclinical  Tumor Consortium" in the database.
I only know American English @zperova

WIll go in with the next Release

@CsabaHalmagyi to update in the database on beat and live

This is now done.

closing. Thanks @CsabaHalmagyi


fix: Support arbitrary escapes until 0.4.25

See https://github.com/NomicFoundation/slang/pull/896#discussion_r1551845740
Arbitrary here means anything that's not \u (Unicode escape sequence) nor \x (hex escape sequence). Before 0.4.25, the arbitrary escapes likes \a are allowed in the string but evaluate to a, after 0.4.25 it is a parse error in solc. Known/valid escapes like \n should still work correctly across all of the versions.

Small update: I have verified with the EVM asm output that it was possible to "verbatim escape" unicode as well, so I've dropped the "ASCII" bit.


Replace OpenSSL's ERR_PACK with ERR_GET_REASON

ERR_PACK is internal of OpenSSL and there's no need to filter out by the function name in this case. The comment in the code already suggests to replace it with ERR_GET_REASON.
It also fixes this error when compiling Unbound with BoringSSL:
C/C++: .../boringssl/include/openssl/err.h:468:9: note: macro 'ERR_PACK' defined here
C/C++: #define ERR_PACK(lib, reason)                                              \
C/C++:         ^
C/C++: util/netevent.c:1215:55: error: too many arguments provided to function-like macro invocation
C/C++:                 err == ERR_PACK(ERR_LIB_SSL, SSL_F_SSL3_GET_RECORD, SSL_R_HTTP_REQUEST) ||

Thanks for the patch! Merged it to increase openssl library compatibility.


PFUser Subclass currentUser() not returning subclass

Say we have a custom user subclass:
class TUser: PFUser {
	override class func initialize() {
		struct Static {
			static var onceToken : dispatch_once_t = 0;
		}
		dispatch_once(&Static.onceToken) {
			self.registerSubclass()
		}
	}

	// MARK: Parse Properties
	@NSManaged var mySpecialObject: PFObject?
}

The expectation is that TUser.currentUser() will return the currently authenticated user as a TUser object. Unfortunately, we often get a PFUser object back instead, and the method ignores our subclass altogether.
When trying to access a property like TUser.currentUser()?.mySpecialObject this causes a bad access crash, because PFObject does not have a mySpecialObject property.
I tried to do a little digging and got all the way to the PFObjectFilePersistenceController and the PFObjectFileCoder where it appears to write the current user info to Core Data, and it stores the Parse class name (_User in our case) but doesn't seem to do anything for subclassing. Following the call tree up, I don't see anywhere that a subclass would get instantiated instead and returned.
How is this supposed to work? Is the issue stemming from creating these subclasses using Swift? Is the Parse SDK expecting something dynamic that Swift isn't providing?

Some more info. It seems like the Parse initialize method pre-loads "current" objects from disk. This seems to happen before the custom TUser subclass is registered. The current user controller then caches the current user, which is a PFUser object, and that's what gets vended from there on out.
Running the TUser.registerSubclass() before calling Parse.init should solve this problem. Going to keep looking to see if there is another solution that doesn't require moving the register subclass method.

Created a PR which will fix the issue without any code changes. This should result in safer code (doesn't matter if some developers are unaware of this bug or that they may need to move their subclass reg methods, if they update their code will just work as expected.

@Vortec4800, good job on identifying the root cause of this.
Since currently it's required to register subclasses before Parse is initialized - I am not sure if the temporary workaround is required at all and I would rather pursue #5 (as you said) instead of adding a temporary patch around something that will go away.
Let me know your thoughts on this, so we can discuss and make the best decision together.

I had a few thoughts about that.
When trying to figure out what was happening (started as just a bad access crash on the currentUser line, which didn't give me a lot to work with at first) I found a few other people with similar issues. I did find someone who said to register the subclass before running the Parse init, but I wanted to better understand what was happening.
I've been working on this project for a while and never even noticed this issue happening until recently, because of the weird race condition I described it only happens in certain circumstances. This leads me to believe that there are more than likely other devs running into this issue and not even realizing it. Putting together a fix like this would just automatically fix all those projects once they update.
I do think #5 is a much more elegant solution and would much prefer it to my change. I wasn't sure why that had been sitting for so long, and why it hasn't been merged yet. I figured a patch like this is so small and won't affect projects that don't need it, and when #5 is actually ready to go this would probably get refactored away anyway, given it references the singleton user controller.

This sounds great!
Let me ping @richardjrossiii today to see if we can update and ship #5 with the next upcoming release.
If not - I am all in for the change. If yes - it'll just get better for everyone at once. 😁
Thank you for clarification, it's awesome to have you!

👍 👍 👍


Remove associated crawl files when deleting crawls.

Right now the files for the crawls are left behind when you delete a crawl. They should be deleted, because there are cases where new crawls will take on the PK of previously deleted crawls.

The files are located in source/resources/crawls (after you have started a crawl). The edit crawl view just needs to delete all the files associated with the crawl.

Setting this to backlog. Still not sure if this should be done.

Done in #433


v1.1.1 release notes half duplicate of  v1.0.1149

The first half of the release notes on https://github.com/mozilla/pdf.js/releases/tag/v1.1.1 seem to be copied from https://github.com/mozilla/pdf.js/releases/tag/v1.0.1149
The duplicates stops with #5763 Update to version 1.0.1149

Version 1.1.1 is based on the previous release version (1.0.1040), and not on version 1.0.1149, hence this is expected. For an explanation of why this was done, please see https://github.com/mozilla/pdf.js/pull/5851#issuecomment-83102602.
Closing as answered.


the per site/domain "show popup with error details" incorrectly displaying current option state

The option toggle below is incorrectly indicating that it is not selected on the current site.

go to site with error. For that site, on the options, choose "show popup with errors details".
Close the tab
Leave the site and go to another site with errors
revisit the site from step 1. The errors popup will display with details, but the status incorrectly indicates "show popup" is not selected.

To get 'unstuck', select the option twice, to toggle it back 'on' then off again.  This also might be related to the last issue re display layout bug

Seems to be 'fixed' by forcing a larger default initial popup size 57a1e9c83c16c4da3325dfcbf603cf9d5301fca0


Added force-dynamic to page that fetches patterns from db

Category

PR Type

✔
Bug Fix

New Feature

Refactor

Update Deps

Documentation

Description

Added force-dynamic to page that fetches allPatterns from the db. Test whether this will hit the db and render a full Pattern List on prod.

Merging for now but need to look into combining force-dynamic with revalidate/fetch latest data logic


Help Wanted: Document workaround for white Desktop App screen on login

Context
The Mattermost Product Documentation doesn't provide guidance for users who encounter a white desktop app screen after logging in.
Documentation Request
Document the following workaround for the white screen desktop app issue via https://docs.mattermost.com/collaborate/install-desktop-app.html#log-in-using-the-desktop-app
Delete the local Mattermost desktop app configuration file, and then reinstall the desktop app.
The location of the Mattermost desktop app configuration file depends on the platform where you’re running Mattermost (and, in the case of macOS, how you’ve chosen to install the app):

Windows: Users\<username>\AppData\Roaming\Mattermost
macOS installer: /Users/<username>/Library/Application Support/Mattermost
macOS App Store: /Users/<username>/Library/Containers/Mattermost/Data/Library/Application Support/Mattermost
Linux: ~/.config/Mattermost

Hi @cwarnermm
Could you assign this issue to me? I can document the mentioned workaround.

Thanks, @1510janu! Really appreciate your help with this issue!

Issue resolved. Closing.


Could not load package ezsystems/ezplatform

I use symfony/framework-bundle v5.0.5 in docker-compose. And when I try executed composer require league/flysystem-aws-s3-v3:2.0.0-beta.3 I faced wth that:
  [RuntimeException]
  Could not load package ezsystems/ezplatform in http://repo.packagist.org: [
  UnexpectedValueException] Could not parse version constraint dev-load-varni
  sh-only-when-used as ^2.0@dev: Invalid version string "^2.0@dev"

  [UnexpectedValueException]
  Could not parse version constraint dev-load-varnish-only-when-used as ^2.0@
  dev: Invalid version string "^2.0@dev"

what I'm doing wrong ?

problem was with new composer version 1.10.11. I reduced to 1.10.10 and lib installed


user agent throws "ValueError: could not convert string to float" error - on both cached /uncached calls

from fake_useragent import UserAgent
on calling ua = UserAgent() or ua = UserAgent(cache=False)
Traceback (most recent call last):
File "<pyshell#17>", line 1, in
ua = UserAgent()
File "/usr/local/lib/python2.7/dist-packages/fake_useragent-0.0.6-py2.7.egg/fake_useragent/fake.py", line 12, in init
self.data = load_cached()
File "/usr/local/lib/python2.7/dist-packages/fake_useragent-0.0.6-py2.7.egg/fake_useragent/utils.py", line 134, in load_cached
update()
File "/usr/local/lib/python2.7/dist-packages/fake_useragent-0.0.6-py2.7.egg/fake_useragent/utils.py", line 129, in update
write(load())
File "/usr/local/lib/python2.7/dist-packages/fake_useragent-0.0.6-py2.7.egg/fake_useragent/utils.py", line 88, in load
for counter in range(int(float(percent))):
ValueError: could not convert string to float: <a

Hey, new version was pushed to pypy a couple of days ago, have You tried latest build?

Just upgraded . Works now.

I upgraded to the last version, but returns the same error message!

@ImanYZ, just checked and seems to be working fine. Can You give me full traceback?

Hi @hellysmile,
Thank you for your concern.
I thought this thread was closed. That's why I asked my complete question in a new thread called:
ValueError: could not convert string to float: <a
Best regards,
ImanYZ

@ImanYZ , ok, https://github.com/hellysmile/fake-useragent/issues/9


Update workflows to use Github environment secrets and add release pipeline

This PR updates the actions to utilize Environment secrets and adds a new release Github Action workflow. This will be triggered upon a manually pushed git tag

Utilizing Github Environments to ensure that prod release can only happen with a manual gate from verified reviewers:

Our environment settings: https://github.com/liatrio/gratibot-rewrite/settings/environments

prod will need PROD_BOT_TOKEN & PROD_SIGNING_SECRET once we're ready to take over Gratibot

More reading: https://docs.github.com/en/actions/reference/environments


Collaboration for asynchronous file access?

Hi there
Don't Panic ... this is not really an issue as such!
positionhigh aka Mark PMed me on the PJRC forum with regard to my buffered SD playback code (https://github.com/h4yn0nnym0u5e/Audio/tree/feature/buffered-SD). He's keen to get a library which combines my multi-file playback with your variable-rate capability, for the MicroDexed project he's involved with. I gather you've worked with them to some extent in the past.
I must confess to having looked at your code previously and being utterly daunted! As an old-school C programmer (tends to be the language of choice for the day job in embedded medical products), I'm not well-versed in The Way of C++... but I had another look, and can just barely follow the outlines of what's going on.
I think my effort has been reasonably successful (though I've not had a huge amount of feedback or bug reports), so I'm fairly confident my approach of firing an Event inside the audio update, and re-loading buffers by servicing the event during "foreground" code (loop() exit, delay() or yield()) is OK.
If this sounds as if it might be of interest, do let me know and we can discuss the best approach. No offence if not, I'm sure you've got plenty of projects on hand!
best regards
Jonathan

this is the crux of the resampling (casting _remainder from float to int is equivalent to truncating the fraction part):
_remainder = accumulator A1, _playbackRate = R1, _bufferPosition = P1. Effectively it does the process above...
https://github.com/newdigate/teensy-variable-playback/blob/master/src/ResamplingReader.h#L343
 _remainder += _playbackRate;
auto delta = static_cast<signed int>(_remainder);
_remainder -= static_cast<double>(delta);
_bufferPosition +=  (delta * _numChannels);

I'm not so concerned about the resampling, I'm just assuming you've got that right!
The main thing for making the source data available to the resampler in a timely manner is shifting from on-demand file reads to pre-loading data before it's going to be required, in chunks large enough to be efficient. With multiple tracks and variable filesystem latency, at 1x playback I've found pre-loading about 8k samples gives enough leeway for a reasonably large track count. Obviously that can take a fair bit of RAM, but PSRAM is very usable for the pre-load buffers. The evidence from others' testing seems to be that around 4kbytes is a fairly sweet spot for SD read sizes: my 4x bigger pre-loads are primarily to allow for extra latency when multiple files are in use. For faster playback rates even bigger buffers might be needed, but they're under programmer control so it's not a decision that the library writer needs to make.
As far as I can tell, you've implemented file random access by emulating a big array and indexing into it, which causes filesystem reads if necessary. The trick would therefore be to change just that element, so that array accesses (within the update() function) can always be satisfied from existing buffered data, but will also trigger a buffer load as soon as there's enough space available to make it worthwhile. At this point I get a bit stuck reading your code and figuring out how to nail my async buffer refill into it...
Do you think this is a sufficiently worthwhile improvement that you'd be happy to give a bit of guidance along the way so it fits with your aims/needs, and pull it in to your repo once complete (assuming it's functional)? I'm quite interested to see if I can make it work, but not enough to spend ages generating and maintaining a fork which might have a pretty limited user base.

I'd be happy to put reference to your repo in the readme file, but I think it'd probably be better to separate this async loading strategy into a repo/branch of its own as I don't think it suits all use-cases, but certainly worth while trying this technique if it improves performance/stability.
I recently introduced the indexable file class to abstract/unify the interpolation code with lots of random access to nearby samples (Much easier and more portable to use indexers [ ] - so the interpolation code file access and array access would be using the same code - sacrificing efficiency for less repeated code). I think one could effectively do the same by storing variables for the last x number of samples. Earlier versions have different code per class to do interpolation. It might be interesting to see how I did it before the indexable file strategy...
There is a good argument for not reading from the SD card during the audio interrupt process() call, and I think its a great idea to try and get this loading to happen before the interrupt has been called, but I would treat it as experimental. During the audio callback interrupt, (i.e. process() method), if the buffer has less than a threshold of data remaining, it would mark a flag, and then during the next loop() method call, a new buffer would be recycled/allocated and read from the sd card.
Unfortunately I don't have much appetite/incentive to write teensy code at the moment, mostly just focusing on paying bills lately. But I'm more than willing to discuss solution, ideas, etc... so please feel free to ask any questions...

the issue as i’m understanding it is that at the moment the read cycle occurs during the process method inside the interrupt. i am trying to get by head around how to get the buffer populated in the loop cycle instead. the minor complication is that the buffer will be either be forward or backward. if we assume the playback rate is constant during the processing of an audio buffer it simplifies it a bit. when the threshold remaining buffer level is reached, it would signal the loop method to load the next or previous buffer depending on if rate is positive or negative.
i think this is doable. but would need tweaking. also the issue is that sd cards are very different. the performance of reading only ever decreases with write cycles. but certainly there are sweet spots as you say.
If this would solve the issue of reading and writing to the same file on sd card I would be interested. but sadly i don’t think this solves that issue.

just thinking aloud here: my slight hesitance is that there is no guarantee the loop() method will reach the code to load the next buffer before the audio interrupt  processes the next buffer, depending on the load inside loop(). possibly creating  a latency and/or need for prioritised task scheduling in your loop(),  it may not happen if the sweet spot is sweet enough. but this might change drastically between sd cards.
there is a good discussion on sd card performance variation here: https://github.com/greiman/SdFat/issues/324

OK, thanks for that. I always develop on branches anyway, never understood why people don't use them as a matter of routine...
I'll consider tinkering with this, and come back to you if I get stuck or have something that I think may be worthy of consideration. Possibly not soon, plenty of other stuff to do.
Good luck with paying the bills!
The way I've made this work is to use Paul's EventResponder class; it can be set up to trigger an event inside the update(), and the responder is configured to execute the file read code within yield(). As yield() is called whenever loop() exits, or delay() is called, or explicitly, it "just" requires discipline on the programmer's part to ensure this happens "often enough". Effectively it builds polling into the fabric of the application; one could do it with an explicit call, like AudioPlayResmp::fillBuffers(), but EventResponder does that for you.
... trying to keep up here! ...
Yes, it has to be often enough, which is why my buffers are 8ksamples long, so loop() can take 64 updates before stuff fails.

As it stands my code only ever reads files forwards, but it's a trivial change to do a seek() if playing in reverse.
The programmer will have to allocate enough buffer for the maximum expected playback rate - as noted above, PSRAM is useful for huge buffers / multiple tracks.

:) If the teensy were paying the bills I'd be working 60 hours a week :) Unfortunately the things that pay the bills are exceedingly boring :(

if you’re using linux or mac and not scared to use command-line-interface i have some tools that make developing/debugging/ testing much easier.  let me know if you’re interested. ( i developed, debugged and tested all this code on x86 with libsoundio audio integration and folders as mock sd cards, using visual studio code. and building my own teensy build process using cmake - to switch between build x86 and arm-eabi-none binaries)

I'm using Win10 x64 and very basic tools - Arduino 1.x IDE and NotePad++. I really should spin up a Linux box or at least a VM, but I seem to be managing so far

i wanted to port the build system to windows recently, because the people who need it use windows. but my
latest version of windows was 7. turns out to be useless. no visual studio code for windows 7 or node js. the hardware was more than necessary. unfortunately a loss for everyone. one day it’ll happen. in the meantime i make the build system into a package manager for teensy.

Windows 10 free upgrade still works, apparently ... I probably shouldn't post a link, but Google Is Your Friend (sort of ... I expect everyone's got a friend who rootles through their drawers and makes off with stuff they'll never miss). Disclaimer: I bought a copy when I built my PC

Ah - didn't know about that!... And google was happy to give all the details! Brilliant. Thanks 👍

I'd LOVE to see a combination of both your libraries. I'm currently using teensy-variable-playback for a project, but would also like the ability of the buffered library to play / record multiple files simultaneously. The teensy-variable-playback library also has looping modes, along with the ability to set the loop start/finish, which I think the buffered library lacks.
I would be more than happy to test out any progress on this, in whatever shape it takes.

The teensy-variable-playback library also has looping modes, along with the ability to set the loop start/finish, which I think the buffered library lacks.

I think the buffered library doesn't need to deal with this, except it would need to know the play direction of the sample. However that i see more as a bonus function, the hard part is how to feed the sample data from buffered library into variable-playback, reading from SD Card, so it does not crash due to running out of data.
Unfortunatly i am unable to help in this complicated topic, except for testing, since this is far above my coding skill.

Please note I've started work, and posted on the relevant thread on the Teensy forum - see https://forum.pjrc.com/threads/67613-changing-pitch-of-audio-samples-TeensyVariablePlayback-library?p=323961#post323961 I'd prefer discussion on there simply because it'll reach a wider audience and result in more people having a crack at testing, making suggestions etc.
I did ask if Nic would prefer an completely separate thread for that discussion, but no response - guess the day job is getting priority!


OpenCL: cleanup and rev support for add_diag, unary +-, mean, sub_col, sub_row, segment

Summary
This PR does dome minor cleanup of /opencl and adds support for a few simple functions. In detail:

removes copy_triangular, diagonal_multiply, identity and sub_block. The first was not used, other were replaced by k.g.
added rev support for add_diag, unary operator+ (and plus()), unary operator- (and minus()), mean, sub_col, sub_row, segment

Tests
All new functions are tested
Side Effects
/
Release notes
OpenCL: added rev support for add_diag, unary operator+ (and plus()), unary operator- (and minus()), mean, sub_col, sub_row and segment.
Checklist

[x] Math issue #1854

[x] Copyright holder: Rok Češnovar

Ready for review.