Google's log says "0 keys" after risk update

Avoid duplicates

[X] Bug is not mentioned in the FAQ
[X] Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
[X] Bug is not already reported in another issue

Describe the bug
Today at 00:01 the first check of keys via the API has been performed. The app indicates a successful risk update and says 'low risk'. What puzzles me is that the log in the Google settings says 'Anzahl der Schlüssel: 0'.
Expected behaviour
The log should say 'Anzahl der Schlüssel: n' with n being the number of keys pulled from the CDN. I expect the app to download keys and initiate a check via the API. If the log is correct, something went wrong. If the log is incorrect, this is another issue. But I can't know what is the case.
Steps to reproduce the issue
Open App, see that risk update has been made, check Google's log, see new (first) entry, check entry, see: 0 keys, 0 matches
Technical details

Mobile device: Samsung Galaxy A50
Android version: 10
App version: 1.0.4

I'm trying to check this but I can't even find the "Details prüfen" screen you included. I can't find it in Settings->Google->COVID-19 Exposure Notifications. I'm using a Pixel 2 (fully updated) but would expect this to look the same for everybody as this is provided by Play Services.
@nilsalex - Can you let me know where in the menu you found this screen?

Moto One
Android 10

Juni 2020 Patch
Mai 2020 Google Play

Same issue here
Xiaomi Mi 8
MIUI <IP_ADDRESS>
Android 10
1. April 2020 Patch
Play Services 20.21.17

Is there anyone that has the menu on the phone, and where there the "number of keys" is more than 1 for any check?

I cannot check any other devices in my family, because none even have the menu to access the information.

The menu is coming from a GMS Update which is still not fully deployed to all devices yet. Also, the assumption is that the 0 keys are only a display bug and the key retrieval and matching are in fact working properly. I will update once this can be finally confirmed from our side.

There were screenshots on twitter showing one person who has received  warning after husband was tested positive. But it was on iPhone...Android still doesn't allow screenshots.

Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.

So doesn't my Android 6.0.1 - phone restart did not help.
Version of up-to-date Google Play Dienste is 20.12.17(040308-316502805)

Other Android 6.0.1 and here the menu point is at least available
Version of Google Play Dienst is
20.21.17(040400-316502805)
So on this device it has at least been deployed, as @jakobmoellersap said (thx for mentioning)

On my Android 6.0.1 device the button is also there, see my first comment, but the keys are at 0.
Does your device show the number of keys checked @gizmo21 ?

Does your device show the number of keys checked @gizmo21 ?

On that button showing device there is no and won't be a CWA app, so just wanted to report the GPS version.
For that 0 key issue, the devs are on it so we'll just have to wait and perhaps Google has to fix that with an even newer service version :)

BlackBerry KeyOne, Android 8.1.0
The past three days there have been several transfers per day (3 just today), and all of them show "Number of Keys = 0"
It seems unlikely to be 'just' a display issue:  why would the system attempt a transfer so many times each day?
Our iPhone got just one update two days ago, and shows 503 keys.

This is not a display of a "transfer". This is about the calls for "provideDiagnosisKeys" of the Google API, as can also be deduced from the UI description. The number of keys is likely just a display bug as if no key packages were there, we would not even call the specified function "provideDiagnosisKeys". Since we do call this function (which would correlate to one UI entry), and we do not tamper with the packages, we can be sure it is the same key file package that is also used by iOS.

Is there any open issue on Googles end so far?
My experience with issue tracking on that far end are not… good.
Do you have a link to an issue on Googles Issue tracker or is this still speculation.
So far it could also be a handling issue and nothing is ever checked, not really reassuring.
Also: was this never tested?

@DooMMasteR I will recheck with Google to see if there is anything I can link to from here.
This was tested on our side and we were able to see the correct key packages being downloaded. Also on our Devices, we were able to see the correct key count with the productive setup while trying to replicate the behaviour. This could be related to some devices being whitelisted and showing up correct key counts while others do not, but we cannot fully guarantee this yet.

The fact that you can see the correct count, but many (I know no case that can) makes me wonder if the number 0 might be correct and there is nothing being checked on our devices.
Getting anything productive from Google alone is a privilege on your end, I guess, usually it feels like a dead end for many bugs and issues, that will eventually get fixed, but they offer about zero feedback down the road. Let us hope this gets sorted quickly because people might get the impression (might even be true) that the app is not working for them.

Regarding your comment of resetting the device: As stated previously in this issue, the rollout is probably not yet completed, and the device reset means that you also reset GMS to a version prior to the rollout of the functionality. I would thus not call the observed behaviour random but in fact expected, wouldn't you agree?

It got the COVID functionality back, but not the insights into the API calls, the Corona-Warn works just fine, but I cannot see the checks anymore (I could see them before) the stock GMS has no COVID functionality at all, since it is an Android 9 device. (I guess any phone to date would not have the APIs without any update).
Basically: the way Google handles their rollouts is random... the phone previously got the version with insights, now got one without :-)
My other phones have always had the insight, I never even knew there was one without this feature until I asked a friend about it.

Seeing the same behaviour on a OnePlus 7T, Android 10, Google Play services 20.21.17<PHONE_NUMBER>02805).
6 exposure checks so far, all of them showing 'Number of keys: 0'.

Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.

So doesn't my Android 6.0.1 - phone restart did not help.
Version of up-to-date Google Play Dienste is 20.12.17(040308-316502805)

Other Android 6.0.1 and here the menu point is at least available
Version of Google Play Dienst is
20.21.17(040400-316502805)
So on this device it has at least been deployed, as @jakobmoellersap said (thx for mentioning)

No button for details on checks available on my Android 6.0.1; restarted phone to be sure
Device

Android Version: 6.0.1 (stock Android of device, not rooted)
Google Play Services version: 20.21.17<PHONE_NUMBER>02805)
Device Model and Manufacturer: Samsung S5 (SM-G900F)
Latest OS Update: settings say all available updates installed, security patch level 1st Aug 2017 :(

Kernel: 3.4.0-14131106 from 06 Aug 2018, Build number: MMB29M.G900FXXU1CRH1

Google Mobile Services (GMS) version:

com.google.android.gms [202117018] [20.21.17<PHONE_NUMBER>02805)] [Container]
com.google.android.gms.nearby_en [v202304013]

Android settings

Android settings > Google > (loads web view of my Google account on Android)
click on Benachrichtigungen zu möglicher Begegnung mit COVID-19-Infizierten
no button to check stats, see below (ignore the red and green comments in the image, screenshot was made for another issue)

the assumption is that the 0 keys are only a display bug and the key retrieval and matching are in fact working properly.

I also believe that this is only a display bug, because during matching Android's log clearly shows
06-20 19:18:19.170  1275 16568 I ExposureNotificationJni: matchingNative get 720 keys
06-20 19:18:19.170  1275 16568 I ExposureNotificationJni: Matching with 720 diagnosis key
06-20 19:18:19.260  1275 16568 I ExposureNotificationJni: Matching done, no key matches
06-20 19:18:19.260  1275 16568 I ExposureNotification: ExposureMatchingTracer.traceWithNative() 0 keys matched, total 720 keys [CONTEXT service_id=236 ]

but the details in Exposure checks also show 0 / 0 on my device.

Ahh ok, so adb holds more information after all.
Good to know.
On Fri, Jun 26, 2020, 19:28 mh-<EMAIL_ADDRESS>wrote:

the assumption is that the 0 keys are only a display bug and the key
retrieval and matching are in fact working properly.
I also believe that this is only a display bug, because during matching
Android's log clearly shows
06-20 19:18:19.170  1275 16568 I ExposureNotificationJni: matchingNative get 720 keys
06-20 19:18:19.170  1275 16568 I ExposureNotificationJni: Matching with 720 diagnosis key
06-20 19:18:19.260  1275 16568 I ExposureNotificationJni: Matching done, no key matches
06-20 19:18:19.260  1275 16568 I ExposureNotification: ExposureMatchingTracer.traceWithNative() 0 keys matched, total 720 keys [CONTEXT service_id=236 ]
but the details in Exposure checks also show 0 / 0 on my device.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-650302530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABR7PK56H6QKOPS57GREO3RYTLDLANCNFSM4OHNUP3Q
.

Ok, I think I can confirm that the V1.0.4 Corona Warn Android app
does warn when RPI/TEK matching was positive.
Tested on Android 7.0, Google Play service version 20.21.17<PHONE_NUMBER>02805).
I inserted 1 matching RPI into the GMS database, and "Check details" shows this:

So apparently, instead of showing all keys that were used for matching, the screen shows the "Number of matches" twice.
Excerpt from logcat:
06-21 11:02:25.301  1270  9567 I ExposureNotificationJni: matchingNative get 1160 keys
06-21 11:02:25.301  1270  9567 I ExposureNotificationJni: Matching with 1160 diagnosis key
06-21 11:02:25.442  1270  9567 I ExposureNotificationJni: Matching done, find 1 keys match
06-21 11:02:25.442  1270  9567 I ExposureNotification: ExposureMatchingTracer.traceWithNative() 1 keys matched, total 1160 keys [CONTEXT service_id=236 ]
06-21 11:02:25.443  1270  9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Native pre-filter found 1 keys with sightings out of 74 scan records. Spent time: 0.180s [CONTEXT service_id=236 ]
06-21 11:02:25.443  1270  9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Java tracing started. [CONTEXT service_id=236 ]
06-21 11:02:25.446  1270  9567 I ExposureNotification: ThreadSafeLevelDbWrapper:contact-tracing-contact-record-db instance btz@bbfab4c created [CONTEXT service_id=236 ]
(...)
06-21 11:02:25.459  1270  9567 I ExposureNotification: ThreadSafeLevelDbWrapper: do open LevelDb en-exposure-result-storage-db [CONTEXT service_id=236 ]
06-21 11:02:25.460  1270  9567 I ExposureNotification: ThreadSafeLevelDbWrapper:en-exposure-result-storage-db instance btz@f954795 created [CONTEXT service_id=236 ]
(...)
06-21 11:02:25.498  1270  9567 I ExposureNotification: previous was null setting to -19 [CONTEXT service_id=236 ]
06-21 11:02:25.500  1270  9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Valid sighting found with TX Power=-14 [CONTEXT service_id=236 ]
06-21 11:02:25.504  1270  9567 I ExposureNotification: previous was null setting to -19 [CONTEXT service_id=236 ]
06-21 11:02:25.505  1270  9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Valid sighting found with TX Power=-14 [CONTEXT service_id=236 ]
06-21 11:02:25.507  1270  9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Valid sighting found with TX Power=-14 [CONTEXT service_id=236 ]
(...)

The app shows this:
(note that I fiddled with the device's clock while doing this, so the "0 days since last encounter" is not necessarily a bug)

Ok, so Google will have to fix this... Can only be a matter of days.
Thx for all the testing on your end @mh-

I will keep updating the discussion once I have more information on the issue solution on Google side. Thanks for your patience, everyone.

Seems to be fixed in Google Play services 20.26.12<PHONE_NUMBER>12943). I updated to this version yesterday and today's exposure checks show the number of keys correctly. (Exposure checks performed before the update still show '0').

Thanks for updating. When some more people have confirmed the Update, we will close the issue.

I also got the new play services, which seem to be marked as beta, but for me the issue still persists, which is 'weird'.
The dialog now shows the version in the bottom of the screen though, 202612000 is the displayed version as of now on my phones, which seems to reflect the play services version of 20.26.12.

@DooMMasteR If the actual matching had been done with the "old" Play Services, the "new" Play Services would still show 0 (because they simply read the values from a database), so maybe wait for the next matching tomorrow.

Seems to be fixed... Yay
You where correct, the checks are stored wrong, so the update just fixed newer entries...
This play service update ist marked as Beta for me, so rollout will probably still need some time, but this issue can or could be closed pretty soon now.

Seems to be fixed... Yay
You where correct, the checks are stored wrong, so the update just fixed newer entries...
This play service update ist marked as Beta for me, so rollout will probably still need some time, but this issue can or could be closed pretty soon now.

It's fixed for me as well, and I'm also using beta play services.

Nothing on my Android 6.0.1 Sony Z3 device. Google Play Services still at ver. 20.21.17.
But the button "Überprüfung auf mögliche Begegnungen" has now disappeared.
Hoping for a speedy Google-update.

Does this mean the key-exchange did not work for the last two weeks?
Is it possible for the user to verify this without logcat?

Does this mean the key-exchange did not work for the last two weeks?
Is it possible for the user to verify this without logcat?

This issue is not about key-exchanges, they can be easily be confirmed with any other bluetooth device (yes, even a PC).

At least you cannot be sure it worked :-( the situation is kind of sad in
itself and should have been covered by the simplest of test, but apparently
it was not.
This is the real worrying part here, Google released this API without any
suitable (at least apparent) kind of testing. The fact that it is not just
a view but also a controller/model issue, makes this really, "not good".
On Wed, Jul 1, 2020 at 9:55 AM dee8een0<EMAIL_ADDRESS>wrote:

Does this mean the key-exchange did not work for the last two weeks?
Is it possible for the user to verify this without logcat?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-652257411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABR7PJXOTXSAOA5JKCO6H3RZLTXFANCNFSM4OHNUP3Q
.

the situation is kind of sad in itself and should have been covered by the simplest of test, but apparently it was not. This is the real worrying part here, Google released this API without any suitable (at least apparent) kind of testing. The fact that it is not just a view but also a controller/model issue, makes this really, "not good".

On my device, the list of verifications is unsorted (all meanwhile seven days are shown in random order), and when you scrolled down and opened a verification there and then go back, you are again on top of the list.
This observation strengthens the feeling that this UI has been developed under high pressure and with little testing.

This observation strengthens the feeling that this UI has been developed under high pressure and with little testing.

Also doesn't work well with dark mode/themes. I can't read anything inside the 'bars'. They're just white with white text.

but the fact, that the checks done before, are not affected by the fix also shows, that even model and controller are or at least where somewhat flawed :-(
I guess Google failed on their part here, which does not enhance the trust in the APi as a whole.
Also: Does Google have any plans to open source the implementation on their end or is it to messy to publicize?

"Überprüfung auf mögliche Begegnungen" is now available, after installation of google-play-service beta 20.26.13<PHONE_NUMBER>35724).
The history of exposure checks was not available to me before the update to beta version.
Also me history only goes back till 28. june. In contrast to that CWA says "14 von 14 Tagen aktiv".

"Überprüfung auf mögliche Begegnungen" is now available, after installation of google-play-service beta 20.26.13<PHONE_NUMBER>35724).

For me, the appearance of this menu item was not related to a play services update.
Did not have it last week with 20.21.17, but have it since Monday with the same 20.21.17.
I assume this is controlled by a feature flag gradually rolled out to the accounts.

The history of exposure checks was not available to me before the update to beta version.
Also me history only goes back till 28. june. In contrast to that CWA says "14 von 14 Tagen aktiv".

Did you scroll through the entire list? As written, the list is not sorted by day but appears random (but stable), and as I just found out, the order even changes when switching the device language from DE to EN.

For me, the appearance of this menu item was not related to a play services update.
Did not have it last week with 20.21.17, but have it since Monday with the same 20.21.17.

Screenshot before update with  20.21.17 google-play-service:

Screenshot after update to beta 20.26.13 google-play-service:

Did you scroll through the entire list? As written, the list is not sorted by day but appears random (but stable), and as I just found out, the order even changes when switching the device language from DE to EN.

For me the list appears to be ordered by date:

Disclaimer:
This is not my daily driver. I have two phones. I use the one with the beta update for trying stuff.

As I have stated before, this feature seems to be distributed on others paths or at least not exclusively with the Play Service updates.
For me just resetting the phone (Play Services stayed the same) made the menu disappear.

The Update is delivered via GMS which is automatically updated on your device independent from the Play Store Version.

which makes the Version displayed at the bottom useless :-1:
I have 2 phones, both have the same version, as displayed at the bottom of the COVID-API screen, but one has the menu, the other does not have it (but had it before, on an older version).

The Update is delivered via GMS which is automatically updated on your device independent from the Play Store Version.

Yes, but the appearance of the menu doesn't seem to be related to the PlayServices version, neither.

I assume this is controlled by a feature flag gradually rolled out to the accounts.

This.

in that case, it is buggy as hell because I use the same account on my devices...
but let's see where this goes, at least we now seem to have a paved road to useful information in the future.
P.S: some of my friends report that they just got the menu and the chaos ordering of the list is the there for everyone so far, so there is at least some consistency in it after all.

Just a quick update. Sony Z3 Android 6.0.1 received an update to Google Play Services yesterday, now GPS is 20.24.14.
CWA threw a Google API (10) error, after restarting the mobile CWA threw a Google API (39508) error.
Still no keys visible.

On my mother's phone, ist seems to have stopped working, since the last update of Google Play Services the phone does not send any beacons.
Rebooting the phone and such do not fix it.

Same issue on Google Pixel 2 XL (0 keys) with the Android 11 Beta and latest Play Services
Here is the exported beautified log file: data.json.zip
1.) 0 Keys for every submission
2.) multiple calls to the API in the same minute every day...

I may have found the issue:
There is a shared preference which stores the last time the app fetched keys from the server.. When fetching keys it tries to fetch the keys since the day stored in that variable up to now..
It is only set once via: LocalData.lastTimeDiagnosisKeysFromServerFetch(...);
here: https://github.com/corona-warn-app/cwa-app-android/blob/51f2c691794e6aa73a4cbc72be20b49068f56919/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/transaction/RetrieveDiagnosisKeysTransaction.kt#L188
it´s set to the value stored in "lastFetchDateForRollback"
however lastFetchDateForRollback is only initialized from LocalData.lastTimeDiagnosisKeysFromServerFetch(); here: https://github.com/corona-warn-app/cwa-app-android/blob/51f2c691794e6aa73a4cbc72be20b49068f56919/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/transaction/RetrieveDiagnosisKeysTransaction.kt#L206
so if LocalData.lastTimeDiagnosisKeysFromServerFetch() becomes 0 (which it is on default install or if one fetch fails).. The app always tries to fetch all keys for the past 14 days and submit them to the API, which fails due to rate limiting.. Thereby breaking the whole app..
This was probably introduced by the change that made the fetching more "failure tolerant"...
Maybe I missed something here, but this how it looks to me and it would explain the logs we see (0 keys, due to old packed being submitted which don´t contain keys and then aborting due to rate limit)...

@Spacefish To confirm that this is caused by rate limiting, do you have access to logs?
This is how rate limiting shows up in the log on my device: https://github.com/kbobrowski/en-i13n/issues/1#issuecomment-653920278

I doubt this is rate limiting. The same 0 keys occurs with SwissCovid so they would have made the same mistake?

I also had "0" in "Anzahl der Schlüssel" every day since I installed the app.
Yesterday I switched to the beta version of "Google Play Services".
As of today a have the first time that "Anzahl der Schlüssel" is above "0".
So it seems a new version of "Google Play Services" might be a solution to this problem.
I attached a screenshot of "before" and "after" I installed the beta version of "Google Play Services".
I use Android 10 on a Pixel 3 device.

I also had "0" in "Anzahl der Schlüssel" every day since I installed the app.
Yesterday I switched to the beta version of "Google Play Services".
As of today a have the first time that "Anzahl der Schlüssel" is above "0".
So it seems a new version of "Google Play Services" might be a solution to this problem.

Which version do you have? I am also subscribed to Google Play Services Beta but still get the 0 keys every day.
Device: BQ Aquaris X2 Pro
Android Version: 10
Google Play Services Version: 20.24.13
App Version: 1.0.4

I also had "0" in "Anzahl der Schlüssel" every day since I installed the app.
Yesterday I switched to the beta version of "Google Play Services".
As of today a have the first time that "Anzahl der Schlüssel" is above "0".
So it seems a new version of "Google Play Services" might be a solution to this problem.

@MartinKolbAtWork
Which version do you have? I am also subscribed to Google Play Services Beta but still get the 0 keys every day.
Device: BQ Aquaris X2 Pro
Android Version: 10
Google Play Services Version: 20.24.13
App Version: 1.0.4

I have:
Device: Pixel 3
Android Version: 10
Google Play Services Version: 20.26.13
App Version: 1.0.4

Seems to be fixed for me with version<PHONE_NUMBER>2. Sorting is still not correct. I've cleared the history, maybe sorting will work from now on.

Thanks for the update. As rollout of Play Service updates takes a couple of days (up to 14), the issue should be resolved over time for all users. And since it is now resolved for the issue creator, we'll close the issue. If it persists with the version mentioned in https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-657220680 , please open a separate issue.

Seems to be fixed for me with version<PHONE_NUMBER>2.

I couldn't find this version number for Google Play services and I also have a Samsung Galaxy A50.
I did however pull the 20.26.14 beta apk from https://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-20-26-14-release/ and installed it manually. For my device it is listed under 202614037 on apkmirror.
The version shown is 20.26.14<PHONE_NUMBER>08519).
I'm now seeing Number of keys 1960 for each entry of the server sync performed today (and Number of matches 0). I'm happy to see a non-zero value for the key count and a zero value for the count of matches!
For any previous days, the Number of keys is still showing 0. Hopefully this is just a display issue, but I am left wondering whether previous days actually did execute properly.

@MikeMcC399 yes it did work correctly, see https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-650532041

At the bottom of Exposure Notifications
(Settings -> Google -> COVID-19 exposure notifications)
I can see Version<PHONE_NUMBER>2 when Google Play services is at Version 20.24.14<PHONE_NUMBER>35315). On the same device, Samsung Galaxy A5, when Google Play services was still at Version 20.21.17<PHONE_NUMBER>02805) the exposure notifications screen was not displaying any version number.
Unfortunately the Google Play services release notes on https://developers.google.com/android/guides/releases don't mention COVID-19 exposure notifications at all so it's difficult to know exactly what the prerequisites are to get the Number of keys to display correctly. I re-read the whole of this thread and still couldn't work it out. Is a certain minimum version of Google Play services 20.nn.nn necessary for correct display of Number of keys? Is the version shown in COVID-19 exposure notifications e.g. Version<PHONE_NUMBER>2 directly tied to the version of Google Play services or can it change independently of the Google Play services version?

As you can see in my log-file below the keycount is 0 for all days. The CWA was installed on the rollout day, As you can also see is that the logs do not cover all the past 14 days (please note: my phone was carried around a lot during all the 14 days and no logs for several days are very unlikely).
Question: The keycount should be the same number for everyone each day as the keycount number should be equal to the number of  postive-reports each day. Can someone confirm?
all-exposure-checks_t.txt

@jeschket

As you can see in my log-file below the keycount is 0 for all days (exept 25/26.07.2020).
As you noted in your edited comment, the newest risk updates have non-zero values, and this closed thread is about the problem of zero values, so the thread is not really relevant to your question.

I'm sorry that I don't know the explanation about varying "Number of keys" for the same day. If you don't get an answer here, you might try starting a new issue.

As you can see in my log-file below the keycount is 0 for all days (except 25/26.07.2020).

@jeschket
I think this means that you had old Google Play Services that would incorrectly record "0" until 24 July.
And now you have new Google Play Services, and everything is fine.
As explained here, searching for matches worked properly before as well. Only the recording of the number of keys was incorrect.

@jeschket

Question: The keycount should be the same number for everyone each day as the keycount number should be equal to the number of postive-reports each day. Can someone confirm?

I went back and read some of the documentation
https://developers.google.com/android/exposure-notifications/exposure-notifications-api and
https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md
and my understanding is that the risks are calculated using historical data split up by days. So the number of keys depends on what keys were relevant for a risk calculation on a particular day. (If I got this wrong, please feel free to correct me!)
https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md explains it nicely with an example.
The Google Exposure Notifications UI shows only the timestamp that the keys were received from the server, but it doesn't display the historical time period that the keys apply to. That would perhaps be a good enhancement suggestion for Google to add the missing information.

The Problem "Anzahl der Schlüssel 0" is back.
App Version 1.2.1
COVID-19-Benachrichtigungen Version<PHONE_NUMBER>3
Google Play-Dienste Version 20.26.14
I checked the numbers every day since July 23. Until yesterday there were 14 different numbers but today (timestamp August 17, 2020 09:39) all 14 numbers are 0.

All systems green here.
Timestamp August 17, 2020, 3:30, shows lots of Keys checked, thankfully no match.
Specs:
Sony Xperia Z3 compact w/ Android 6.0.1
App Version 1.2.1
COVID-19-Benachrichtigungen Version<PHONE_NUMBER>4
Google Play-Dienste Version 20.26.14<PHONE_NUMBER>08519)

@kereng5 could you export and share your exposure log? :)

I exported what I think is the "exposure log" and got a .json-File which is not accepted here, so I saved it as .txt.
I did not activate the "priorisierte Hintergrundaktivität" but trigger the exposure check every day by looking into the app.
My phone is Motorola G3 with Android 6.0.1.
all-exposure-checks-1.txt

Thank you, mh!
But granting root access seems too difficult for me.

@kereng5
This is indeed very weird… I just spot checked a few hashes from your August 17th entries and compared them with mine and they were identical, just for me keyCount was always greater than 0.
Could you maybe check if the same behavior occurs again tomorrow?
My device:
Samsung Galaxy S8 (Android 9)
CWA 1.2.1
ENF v.<PHONE_NUMBER>3
Google Play Services: 20.26.14

My log: me-17.zip

@kereng5 I modified the WarnAppCompanion app https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion - starting with version 1.1.1, it will always least try to download the Diagnosis Keys, also without root access.
This might help to check whether a firewall prevents downloading them.

Could you maybe check if the same behavior occurs again tomorrow?

Same as yesterday.
all-exposure-checks-2.txt

version 1.1.1, it will always least try to download the Diagnosis Keys, also without root access.

I got the Diagnosis Keys. The numbers are 2500 for August 4, then 2325, 2095, 1935, 1820, 1780, 1575, 1450, 1190, 890, 680, 435, 285, 20, 0. The last one (0) for today.
How do I understand the 20 for August 17? I guess only 4 of yesterday's 56 reporters transferred their last Diagnosis Key to the server. And the 285?  56*5=280, so only one Diagnosis Key is from the 33 who reported positive on August 16, or some of the 56 had no old keys. (Data source https://micb25.github.io/dka/ )

@kereng5 Yesterday's keys (17 Aug 2020) can only be uploaded today. So they are part of the hourly packages that have been published today. As of right now I already see 50, so 50/5==10 users have already uploaded keys for yesterday.

@mh- I'm not so sure that @kereng5 is missing any packages/downloads: when I was comparing hashes yesterday I found the same hashes as for my checks, even for the most recent package… I don't think that this would be possible w/o the package actually being downloaded. This seems to me to be a displaying error like we had before ENF 1.5…

I can see key numbers again. all-exposure-checks-3.txt
Yesterday I noticed that there was not much internal memory free in my phone, and I deleted some pictures from camera and WhatsApp. I am not convinced that this is the reason. I would expect an error message if there is no space for the Diagnosis Keys.
Do the Diagnosis Keys need less space in companion app? There seems to be less redundancy.

@kereng5 I really don't know, in Warn-App-Companion I just download the Diagnosis Keys to RAM. The data downloaded from the server is probably also cached somewhere, but I think that cached data might be deleted automatically in low-disk-memory situations.
One major difference is that Warn-App-Companion makes no effort to download anything in the background, it only works when you start the app in the foreground. An OS usually gives priority to the foreground application.

Also this issue is closed and the FAQ says the problem is solved with newer google play services versions:
I saw the problem on my dads phone with recent CWA and play services, see screenshots. On top of that, it's not only a invalid display, but risk calculation is not performded correctly.
Should I create a new issue for this, or should it be tracked here?

Hi @vanMacG ,
I found your comment by chance.
As the issue here is closed and as the observation on your dad's phone may have different reasons, I'd recommend to open a new issue.
We would need some more information then, like the phone model and Android version, and how long the app has already been installed.

@vaubaehn
Thank you for your comment. I will get the infos and post a new issue in the evening.

@vanMacG
Great, thank you. What also would be good if you could check how much free space there still is on internal storage.


connect.session Heroku

Warning: connect.session() MemoryStore is not designed for a production environment, as it will leak memory, and will not scale past a single process.
That shouldn't be happening as we're using Redis

I've looked into this. We're giving express-session a redis store, so I'm not 100% sure what's going on here

https://github.com/osumb/challenges/pull/50 I'm a dumbass...

Now I can't log in... God dammit!!

https://github.com/osumb/challenges/pull/54


 However server still reacts strangely.
When trying to create .. file inside a folder, ocis responds 500 Internal Server Error, error log:
2024-06-03T16:06:21+02:00 ERR failed to initiate upload error="Decomposedfs: error getting parent : decomposedfs: root has no parent" pkg=rgrpc service=storage-users status={"code":15,"message":"error getting upload id: Decomposedfs: error getting parent : decomposedfs: root has no parent","trace":"8fb814691e52ef5210d0a1014b1a067d"} traceid=8fb814691e52ef5210d0a1014b1a067d
2024-06-03T16:06:21+02:00 ERR Internal Server Error code=500 name=com.owncloud.web.ocdav path=/users/93a2c474-db76-4676-8abc-6cd1e545f13c request-id=jkoberg-20ud0010ge/d9op1AVpBO-001283 service=ocdav status={"code":15,"message":"error getting upload id: Decomposedfs: error getting parent : decomposedfs: root has no parent","trace":"8fb814691e52ef5210d0a1014b1a067d"} traceid=8fb814691e52ef5210d0a1014b1a067

When trying to create .. file on a space root ocis will respond 405 Method Not Allowed with no error log.
Both is wrong. Ocis should return a 400 Bad Request in both cases.

ATM I get 3 different results:

First attempt on empty personal space: 403 Forbidden
Second attempt: 412 Percondition Failed
Third attempt: 201 Created

This looks somewhat fishy.....

The approach to disallow uploading .. with the validators in reva makes things worse, fixes this issue, but breaks webdav... back to square 1...

Blocked for now, need to clarify with @butonic

TL;dr AFAICT we need to always call path.Clean() ... maybe we forgot that somewhere?
Long version summoning RFC 3986 3.3.  Path:

[...]
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy.  They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names.  This is similar to their role within some operating
systems' file directory structures to indicate the current directory
and parent directory, respectively.  However, unlike in a file
system, these dot-segments are only interpreted within the URI path
hierarchy and are removed as part of the resolution process (Section
5.2).
[...]

5.2.  Relative Resolution
This section describes an algorithm for converting a URI reference
that might be relative to a given base URI into the parsed components
of the reference's target.  The components can then be recomposed, as
described in Section 5.3, to form the target URI.  This algorithm
provides definitive results that can be used to test the output of
other implementations.  Applications may implement relative reference
resolution by using some other algorithm, provided that the results
match what would be given by this one.
5.2.4.  Remove Dot Segments
The pseudocode also refers to a "remove_dot_segments" routine for
interpreting and removing the special "." and ".." complete path
segments from a referenced path.  This is done after the path is
extracted from a reference, whether or not the path was relative, in
order to remove any invalid or extraneous dot-segments prior to
forming the target URI.  Although there are many ways to accomplish
this removal process, we describe a simple method using two string
buffers.

The input buffer is initialized with the now-appended path
components and the output buffer is initialized to the empty
string.

While the input buffer is not empty, loop as follows:
A.  If the input buffer begins with a prefix of "../" or "./",
then remove that prefix from the input buffer; otherwise,
B.  if the input buffer begins with a prefix of "/./" or "/.",
where "." is a complete path segment, then replace that
prefix with "/" in the input buffer; otherwise,
C.  if the input buffer begins with a prefix of "/../" or "/..",
where ".." is a complete path segment, then replace that
prefix with "/" in the input buffer and remove the last
segment and its preceding "/" (if any) from the output
buffer; otherwise,
D.  if the input buffer consists only of "." or "..", then remove
that from the input buffer; otherwise,
E.  move the first path segment in the input buffer to the end of
the output buffer, including the initial "/" character (if
any) and any subsequent characters up to, but not including,
the next "/" character or the end of the input buffer.

Finally, the output buffer is returned as the result of
remove_dot_segments.

Note that dot-segments are intended for use in URI references to
express an identifier relative to the hierarchy of names in the base
URI.  The remove_dot_segments algorithm respects that hierarchy by
removing extra dot-segments rather than treat them as an error or
leaving them to be misinterpreted by dereference implementations.
The following illustrates how the above steps are applied for two
examples of merged paths, showing the state of the two buffers after
each step.
 STEP   OUTPUT BUFFER         INPUT BUFFER

  1 :                         /a/b/c/./../../g
  2E:   /a                    /b/c/./../../g
  2E:   /a/b                  /c/./../../g
  2E:   /a/b/c                /./../../g
  2B:   /a/b/c                /../../g
  2C:   /a/b                  /../g
  2C:   /a                    /g
  2E:   /a/g

 STEP   OUTPUT BUFFER         INPUT BUFFER

  [1](https://datatracker.ietf.org/doc/html/rfc3986#section-1) :                         mid/content=5/../6
  2E:   mid                   /content=5/../6
  2E:   mid/content=5         /../6
  2C:   mid                   /6
  2E:   mid/6

Some applications may find it more efficient to implement the
remove_dot_segments algorithm by using two segment stacks rather than
strings.
 Note: Beware that some older, erroneous implementations will fail
 to separate a reference's query component from its path component
 prior to merging the base and reference paths, resulting in an
 interoperability failure if the query component contains the
 strings "/../" or "/./".

@butonic thx, So I assume it would be sane to disallow ".." as standalone path as proposed in https://github.com/cs3org/reva/pull/4721. This would just leave us with the non-deterministic behavior of the storage list.

yes. that should result in a bad request error imo

It does randomly :laughing:

Reva bump was merged.


after exit game will blackscreen

console show this

Yep I think it's a spt-aki bug, given the stackframe. It is not our code.


Backspace no longer working in TextInput field

Unless text is highlighted, the backspace key has no effect.
I tracked this down to the line
text = text.substr(0, highlightStart) + text.substr(highlightEnd, text.length);
which has no effect when highlightStart == highlightEnd, and this is often the case as just a few lines later
setHighlight(cursorX, cursorX);
will indeed set them as equal.
I noticed that in your kode garden demo the backspace worked as expected in textinputs: http://kodegarden.org/#23ae97114a4d60f249ce6054ba443c25e7264579
I took the code from there and combined it with the erroneous line to produce:
if (highlightStart == highlightEnd && highlightStart == cursorX)
text = text.substr(0, cursorX - 1) + text.substr(cursorX);
else
text = text.substr(0, highlightStart) + text.substr(highlightEnd, text.length);
which seems to fix it.
Jake

Hm is this still an issue in latest zui? I recall having trouble with this as well but should be already patched here: https://github.com/armory3d/zui/commit/4060452f36ae7abed2356c8f0b0e508f45db36ea.

It should probably also be checked if it works with the latest input changes in Kha https://github.com/Kode/Kha/pull/772, https://github.com/Kode/Kha/pull/773, https://github.com/Kode/Kha/pull/779. The 772 PR f.ex. also prevented the use of function keys which is back now with 779. Not sure what other non-char keys might be affected.


update build.sh to use depends and add libsodium

redoes build.sh to use depends and adds libsodium to depends; uses depends for bdb 4.8 and boost

groovy, thanks!


Provide Vulkan examples

Again - just for learning purposes. Provide Vulkan examples from https://vulkan-tutorial.com/ say, but running within a Qt context or window of some sorts.

Im putting this one on hold. We probably don't need a full example right now. OpenGL should be sufficient.


ci: push on master

Self-explanatory, noticed that CI didn't run on master pushes. :thinking:

Codecov Report

Merging #279 (86344c5) into master (5e1dec8) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #279   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines           73        73
  Branches        12        12
=========================================
  Hits            73        73

Continue to review full report at Codecov.

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


downloading plugins in parallel

exactly as the title says. having to download and setup plugins 1 by 1 can get really slow, so downloading multiple at the same time will speed up the process by a lot

since the convenient goro function is added in dev branch of hilbish, this can be done (gopher-lua already has channels)


Promise.onTimeout / completeOnTimeout -- should it cancel original Promise on timeout?

I'd like to open a discussing regarding design choice I made for Promise.orTimeout  and Promise.completeOnTimeout.
Promise.orTimeout returns a new Promise that is either completed normally when original Promise completes normally within timeout given, or completes exceptionally, when original Promise completes exceptionally within timeout given, or completes exceptionally with TimeoutException if timeout was exceeded.
When the returned Promise is cancelled, timeout is cancelled as well. However, original Promise is not cancelled and its completion code keeps running. Moreover, if timeout happens then original Promise is not cancelled either.
Why? To support different execution paths depending on timeout duration. For example:
Promise<String> serviceCall = someSlowServiceCall();

serviceCall.orTimeout(Duration.of(5, ChronoUnit.SECONDS)).exceptionally(e -> {
  if (e instanceof TimeoutException) {
    UI.showMessage("Sorry, it takes a bit longer than expected. Please wait...");
  }
});

serviceCall.onTimeout(Duration.of(20, ChronoUnit.SECONDS)).exceptionally(e -> {
  if (e instanceof TimeoutException) {
    if ("Y".equals(UI.showConfirmation("Server does not respond, do you want to cancel operation (Y/N)?"))) {
      serviceCall.cancel();
    }
  }
});

Obviously, there is a way to cancel original promise as well with minimal coding:
Promise<String> serviceCall = someSlowServiceCall();
Promise<String> withCancelOnTimeout =
  serviceCall
  .orTimeout(Duration.of(5, ChronoUnit.SECONDS), true)
  .exceptionally(e -> serviceCall.cancel(true));

Promise.completeOnTimeout is almost identical in behavior, the only difference is that in case of timeout the returned promise is completed with alternative value (supplied as argument).
Both orTimeout and completeOnTimeout  are executed on the default executor of the original Promise.
What do you think?

I faced the same situation/challenge at zalando/riptide. I decided to cancel the original future and propagate the timeout to the returned one, see here:
final ScheduledFuture<?> scheduledTimeout = delay(timeout(downstream), cancel(upstream));

I actually like your workaround a lot.

Willi,
Thank you for suggestion. I'm realizing that cancellation of original promise is more than 95% of case, so I modified an API and added a parameter cancelOnTimeout (by default true in overloaded methods).
Also I renamed completeOnTimeout to onTimeout -- it doesn't complete original promise, so naming should reflect this.

Hi Valery,
I am sorry that I did not reply. I had a lot of work last week. Anyway, I also thought that functionality will be really wanted so adding a parameters seemed to be a good way also to me. I also thought about the default value and there I thought keep running could be default similar to DependentPromise and cancellation of its dependents. I would see this as a more conservative approach.
However, when the API provides a parameter, we can always choose. We are not forced to use default values :)

Adam,

The only reason why DependentPromise enlists origins explicitly is the rule of least surprise: when DependentPromise is returned as Promise from some black-box code it should walks and quacks like regular promise and DOES NOT enlist anything silently.
In majority of cases there cancelOnTimeout=true is exactly what is necessary. Multiple timeouts over single origin is a boundary case.
Promises.all/any/atLeast works the similar way -- cancelRemaining=true if not explicitly specified.

So these are reasons to make cancelOnTimeout=true by default.
By the way, as a requester for DependentPromise you might find it useful to replace DependentPromise.from with Promise.dependent in next release (already in master) -- this way you may just wright chained calls like:
Promise<DataStructure> someMethod(String url) {
  return CompletableTask
             .supplyAsync( () -> loadXml(url) )
             .dependent()
             .thenApplyAsync( xml -> parseXml(xml), true );
}

Ad 1) sounds reasonable.
Ad 2) Sorry, I do not have direct experience with timeouts. It was just the not cancelling behaviour of FutureTask.get(.. timeout ..) which I was partially aware of. I just wanted to provide some thoughts for the discussion. More info can be found here: https://stackoverflow.com/questions/16231508/does-a-future-timeout-kill-the-thread-execution.
The new Promise.dependent method seems like a useful improvement ragarding the fluency of the API. Thanks.

Sorry, I do not have direct experience with timeouts. It was just the not cancelling behaviour of FutureTask.get(.. timeout ..)

It's implemented differently, via ScheduledExecutorService.schedule + Promise.cancel() -- no time-wait on FutureTask


Update loops-in-progress.md

Added Matthew Byatt's name to the list

If you'd like this merged, you'll have to Reopen it (or let me know and I can).

Hi
Happy for you to merge.
Matthew
On Tuesday, 13 September 2016, Scott Leibrand<EMAIL_ADDRESS>wrote:

If you'd like this merged, you'll have to Reopen it (or let me know and I
can).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/openaps/docs/pull/388#issuecomment-246765616, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVJpIHSLpJ9qicMLPhuJBgBjwWtx6u0Iks5qpuKxgaJpZM4J78zW
.


New Feature vs current docs

Related to MC189163 / Roadmap ID 54235 (from 365 admin message center)
With the message it states "Tenants that do not have PSTN-calling enabled will have access to a sub-set of features, which includes transferring a call to Cloud Voicemail."
That is in contrast to the "Note - Enterprise Voice enable requirement" on this this.
How do those features compare between Enterprise voice enable and not PSTN-calling enabled?  And what is the difference between PSTN-calling enabled and Enterprise voice enabled?
Additionally is this Cloud Voicemail the same as Team Cloud Voicemail (https://docs.microsoft.com/en-us/microsoftteams/set-up-phone-system-voicemail)?

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

ID: ec8b8afb-b9ca-8136-b907-5bbff4c9dcf1
Version Independent ID: d4f68818-6fe6-5bb7-f108-e26a643f2cc7
Content: Configure Cloud Voicemail service for on-premises users
Content Source: Skype/SfbHybrid/hybrid/configure-cloud-voicemail.md
Product: skype-for-business-itpro
GitHub Login: @dstrome
Microsoft Alias: dstrome

@D-Jeffrey Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

@D-Jeffrey thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


[Bug] Connects to few of chatgroups

I have 5 groups in autoconnect

When I start bot, it connects to random 1-3 of them.

If you open settings, can you see the chatrooms which aren't being joined there and are they checked?

Yes

UPD
It connects to all chat groups but not show them in panel

1.0.3
fixed
maybe its really Steam problem...

Maybe, but I did some various fixes that might have been the cause of the issue.

Maybe =)


remove an unnecessary quote mark

This pull request includes a

[ ] Bug fix
[ ] New feature
[x] Translation

The following changes were made

remove an unnecessary quote mark

Awesome, thanks!


Error - Not valid base64 string

Hi, throwing this error on all but 2 songs when I try to add cues:
Error occurred during creation of cues for "96617" from "C:/Users/hears/Desktop/Stuff For LEvels/swedish_house_mafia_-don't_you_worry_child(intro_edit).mp3" System.FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
at System.Convert.FromBase64CharPtr(Char* , Int32 )
at System.Convert.FromBase64String(String s)
at CueGen.TagFile..ctor(String filePath)
at CueGen.Content.GetTag()
at CueGen.Generator.CreateCuesForContent(UInt64& maxId, SQLiteConnection db, Content content)
at CueGen.Generator.<>c__DisplayClass20_3.b__6()
at SQLite.SQLiteConnection.RunInTransaction(Action action)
at CueGen.Generator.Generate()
Any clue how to fix this?

Can you attach a demo MP3 file here? Thanks.


[WIP] Create Pageflow Scrolled Models

REDMINE-17220

Coverage remained the same at ?% when pulling 1f64a2aa06de0fce2b33180a81f5d5dcd5e726a6 on DanielKuhn:pageflow-next-models into dcd9e4853c49b0b510fca0b43cff76423ff7d343 on codevise:master.


[WIP] aka.ms links to new azsdk scheme

So far I've pretty much executed:
find . -type f -exec sed -i<EMAIL_ADDRESS>{} \;

I will also be replacing matches for these links:
aka.ms/azsdk-js-formrecognizer-ref-docs
aka.ms/azsdk-js-search-ref-docs
aka.ms/azsdk-js-textanalytics-ref-docs

TODO:

Actually make the links (Kate taught me how to do it!).

I wonder, what other patterns should I be checking against?
Thank you for your time!
Fixes #8516

I will be closing this PR on favor of another one later today, since the work that needs to be done is considerably different than the work portrayed in this PR.

I'm narrowing this down, but I won't be able to make a follow-up PR today.

Closing this on favor of: https://github.com/Azure/azure-sdk-for-js/pull/9034


Windows binary

Dear Chris,
Could you be so kind to generate .exe for the rest of us who use Windows, if possible?

Err… Hello?

I'm not terribly familiar with the options for packaging rubygems as exes. If you or anyone else has suggestions or wants to submit a PR for this, I'd be glad to take a look.

@frohoff, please check https://github.com/rdp/ruby_tutorials_core/wiki/ruby-talk-faq#ruby_to_exe
Especially, rb2exe looks relevant here, what do you think?

Regarding rb2exe, https://github.com/loureirorg/rb2exe#todo seems to indicate that windows isn't supported yet and that it only supports building for Ruby 2.2.2. Most of the others on that list that I looked into seemed abandoned or broken, but I'm happy to look at others that look more promising.
In the meantime I'm not aware of any reason one couldn't use ciphr by installing it via rubygems from a normal https://rubyinstaller.org/ windows ruby setup.

I'm not aware of any reason one couldn't use Ciphr by installing…

Dependencies make tools awkward. Think of early firearms which required user to carry a heavy ramrod to push the projectile up against the gunpowder before shooting. Back to present day with its challenges: security tools are mostly in demand not by the academic milieu with all dependencies already in place or a willing to pollute system with ones, but by individuals on the go.


[FLOC-3684] Get rid of deperecated ClusterStateService.apply_changes.

https://clusterhq.atlassian.net/browse/FLOC-3864

Thanks @tomprince
Looks good to me but:

There was a single failed build. I restarted it.
:question: With the state era endpoint do we still need the extra complication of ChangeSource's?

ChangeSource was introduced to record the timestamp of each state update and to allow garbage collection of stale state reported by now-offline nodes.
but now we have eras we have a better way, right?
Mightn't we want to re-instate the deprecated but simplified API?

:question: I thought we said that Flocker isn't a library. In which case, why did we bother carefully deprecating that API?

Anyway, merge if you're sure this is the right direction to go and when the builds are all green.

I thought we said that Flocker isn't a library. In which case, why did we bother carefully deprecating that API?

I suspect to avoid having to change test code at the time.

With the state era endpoint do we still need the extra complication of ChangeSource's?

I think we still want to get rid of stale data. The era takes care of invalidating data from a node that has restarted, but doesn't handle the case when an agent has died.


Selections error out (1,2,3....)

First off thank you!
I did a manual install using the steps listed in your .sh file. Later I removed the user selection and ran the script (#1 only ) and it completed the process with out errors. ( other than a PIP as root error)
the issue:
When I would use the automated system, I would select 1, the terminal would toss back errors that correspond with all the if (( $number == lines.
I am using a Pi3 B+ with 32bit Bullseye.

If you could provide me with a screenshot or pastebin of the output log, that would be extremely helpful, but the information you've provided is not enough by itself for me to find the issue.


collision pmDrag subplugin with MarkerCluster

Hi again,
This is a follow-up issue on this previous one. In my project, I am using MarkerCluster and it seems like there is a collision between pmDrag and MarkerCluster.
codesandbox

I looked into it but I didn't found the bug so you have to fix it by your self. I can't support all possible things and you are trying to combine a lot of not well supported features.
I suggest you to recalc the (center-)latlng of the marker while pm:drag is for the polygon called.


JWT header includes parameter cty with null value

https://github.com/cloudfoundry/uaa/blob/5c9fb47e34de30df97fdd6670e055423e0023e0f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/jwt/HeaderParameters.java#L26
With change https://www.pivotaltracker.com/n/projects/997278/stories/161025678 the parameter cty is included with a null value, e.g.
{
"alg": "RS256",
"kid": "key-1",
"typ": "JWT",
"cty": null
}
In contrast to that, the specification https://tools.ietf.org/html/rfc7519#page-11 recommends the cty parameter only to be included for non-null
5.2.  "cty" (Content Type) Header Parameter
The "cty" (content type) Header Parameter defined by [JWS] and [JWE]
is used by this specification to convey structural information about
the JWT.
In the normal case in which nested signing or encryption operations
are not employed, the use of this Header Parameter is NOT
RECOMMENDED.  ...
We have received reports that the cty with null value breaks with some client implementations.

@mwdb Thank you for filing this, it has been closed with #915


Bump ember fetch version, fixes #255

The ember-fetch dependency just needs to be bumped to also allow v6.
Testing:
In your package.json, change ember-simple-auth-token to be:
    "ember-simple-auth-token": "joshuataylor/ember-simple-auth-token#bump-ember-fetch",

Now rerun yarn, and you should be good to test.

@Uysim does this fix your issue on #257 as well?

I tested it. It didn't fixed my problem


abnormal forelimb zeugopod morphology MP:0003855 - axiom

abnormal forelimb zeugopod morphology MP:0003855 currently uses double inheres in
'has part' some (morphology and ('inheres in' some zeugopod) and ('inheres in' part of some forelimb) and ('has modifier' some abnormal))
Change EQ to:
'has part' some (morphology and ('inheres in' some 'forelimb zeugopod') and ('has modifier' some abnormal))

Added this to the pattern template for AbnormalMorphologyofAnatomicalEntity and will close this ticket.


Add ginPort in event while bootstrapping and interrupting

Codecov Report

Merging #40 (9e50400) into master (4f716c5) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #40      +/-   ##
==========================================
- Coverage   84.50%   84.49%   -0.02%
==========================================
  Files          36       36
  Lines        2840     2837       -3
==========================================
- Hits         2400     2397       -3
  Misses        340      340
  Partials      100      100

Impacted Files
Coverage Δ

boot/gin_entry.go
70.20% <100.00%> (-0.19%)
:arrow_down:

Continue to review full report at Codecov.

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


Consider splitting lifecycles into individual files for each type

e.g. a file for kafka, a file for metrics, a file for onyx-seq, etc

This was planned to be moved to lib-onyx. We'll hold off on this, as well as splitting it up, until we've had a bit more of a play with making things composable.

All done


Topology: Error on click of node in backstage instance

Describe the problem
Getting console error on node click in topology view in the backstage instance, this happens likely as there are different versions of d3 and its dependencies i.e  d3-selection library is present with 3.0.0 and pf react-topology has 1.4.2
How do you reproduce the problem?

checkout main https://github.com/janus-idp/backstage-plugins (tried on commit a70889f3304125368e948f15a87f67ae84ab296e)
cd backstage-plugins
rm -rf node_modules (if already have project cloned then remove node_modules)
yarn install
yarn workspace @janus-idp/backstage-plugin-topology run start
select topology from nav and click on any node

error is shown below

Expected behavior
No error should be shown
Is this issue blocking you?
List the workaround if there is one.
Screenshots
If applicable, add screenshots to help explain the issue.
What is your environment?

OS: [e.g. iOS] mac OS
Browser [e.g. chrome, safari] chrome
Version [e.g. 22]

node --version
v16.17.1
yarn -v
1.22.0

"@patternfly/react-topology": "4.93.4",

What is your product and what release date are you targeting?
Backstage / Janus-IDP, this will impact all the plugins consuming pf react-topology
Any other information?

This is an application issue with pulling in multiple versions of d3-selection. Currently we use D3 version 5 which pulls in d3-selection version 1. You are pulling in d3-selection version 3. These versions are quite different and it will take some time to upgrade PF react-topology to version 3.

Fixed by #59


Add row without redrawing existing

Is there any way to add a new row to a grid without redrawing the existing rows?
I have a text box in a cell (added via custom renderer) and when it's value changes a new row needs to be added to the grid. This is done on the keyup event as opposed to when tabbing off, and I'm using api.addItems() to add a new row. When the user types the existing rows seem to redraw, meaning the state of the text box is lost (value, focus, etc.).
Is there any way to avoid this so it just adds a new row without redrawing the existing? I've tried updating the underlying model by adding a new item to the data array and re-setting rowData, and then calling refreshView() (the documentation says this will only redraw volatile rows) but that doesn't then add the new row.
I've noted this SO post which seems related. The answer seems to suggest what I want is not possible, but this is using ng2 which I'm not so I'm not sure how relevant the answer is.
Thanks in advance for any help :)

it's not possible. when you insert rows, the whole grid gets refreshed.

Thanks for the quick reply.
Is there any workaround you can think of, aside from tracking the state of the controls and adding it back again? Ultimately the controls will be fairly advanced and composite in nature (ie a lot of state so not trivial to reinstate) so this approach would be laborious.

put in blank rows? then you just update the blank rows.
to change the grid would require a lot of work, i don't have it coded to take care of all the different things that can change, basically it's a shotgun approach, when something like row count changes, it redraws everything.


Support renaming of GraphQL fields

@GraphQLName can be used to rename GraphQL types (i.e. classes). It is a fairly generic annotation so wondering whether we should extend its usage to also allow renaming of the GraphQL fields, etc, example schema
class RenamedQuery {
  @GraphQLName("renamed")  // currently unsupported
  fun original(id: Int) = OriginalType(id)
}

@GraphQLName("RenamedType")
class OriginalType(
  @GraphQLName("renamedProperty") //currently unsupported
  val originalProperty: Int
)

Could generate following SDL
type Query {
  renamed(id: Int!): RenamedType!
}

type RenamedType {
  renamedProperty: Int!
}

Love this one! Currently, query name is the same as function name. It would be nice if we could override it

@dkuc84  What is the benefit of such a possibility?
That's just my opinion, but such code always leads to unnecessarily complex stuff. I would prefer to rename the function rather than just fake the name with an annotation.
I'm a fan of clean and clear code with no surprises.

@Swissbite in general I'd assume renaming of any of the fields would be rather uncommon. It is a fairly generic annotation but only applicable on a class (i.e. GraphQLObjectType). Since we are already providing functionality to rename the types (driven by use case from here) I think it would make sense to make it consistent and applicable on other GraphQLTypes as well.
As for actual use case for renaming functions/fields I don't have a concrete example but I'm thinking that it could be potentially useful in large federated schemas - if you have dozens of microservices building your graph you might want to provide some common naming patterns among them or need to rename some of the queries to avoid conflicts.

@Swissbite I would tend to agree that we will not use this in our schemas much either but as @dkuc84 mentioned, we already support the annotation so this is just extending it's capabilities for those that do want to use it.


[FEATURE] option to center line labels and points between grid lines on the x axis like in bar charts

Expected Behavior

There should be new property in line dataset or grid lines configuration. And when it is set, line points and x labels should be centered between x grid lines and x ticks (as they are drawn in mixed chart with same line configuration and bar configuration).

Current Behavior

For line charts line points, x grid lines, x ticks and x labels are vertically centered.
Possible Solution

Possible workarounds:
http://stackoverflow.com/questions/39700096/how-to-add-an-offset-to-a-dataset-in-chart-js
http://stackoverflow.com/questions/37970461/chart-js-line-charts-draw-points-between-grid-lines
Context

We are creating charts and mixed type charts based on user configuration and would like to achieve consistent look.
Environment

Chart.js version: 2.5

@cizmiak have you tried
axisOptions: {
  gridLines: {
    offsetGridLines: true
  }
}

The setting is normally used for bar charts, but it might work here

@etimberg, thank you. I'm sorry, but it seems that setting this option doesn't work as expected. Points of a line are still drawn at intersects of grid lines: https://jsfiddle.net/24aotbnc/12/

That's what I was hoping wouldn't happen. Tagging as an enhancement for now.


go: finding github.com/hyperledger/fabric/protoutil latest

Hi Team,
could you please me help to fix this issue. PFA.
@salmanbaset @balazsprehoda
I m using Go version => go version go1.12.7 darwin/amd64

@heeropunjabi Please try to run go get -v github.com/hyperledger/fabric/protoutil@master. If that doesn't work, you can try cloning https://github.com/hyperledger/fabric into $GOPATH/src/github.com manually.

@balazsprehoda Thanks for your reply.
could you please help to update the same thing in the go.mod file.
PFA.

Hi @balazsprehoda,
I am facing one more issue wrt to analyzer dependency.
PFA.
Please let me know what can be done ?
TIA.
Regards,
Heero.

@heeropunjabi : @balazsprehoda and I are planning to upload fabricbeat executables so that folks like you do not have to compile it themselves. Stay tuned.
for the above error, can you please try it again?

Hi,
Thanks @salmanbaset for your reply.
I tried however i couldn't get a success for the same.
@salmanbaset @balazsprehoda Please let me know when you guys are releasing fabricbeat executables. I am waiting for it.

@heeropunjabi There are two additional options available to run fabricbeat now:

Running as a container
Running the pre-compiled executable

For details, see #37


can I use motor(mongodb) with this?

I find this project very interesting, I have been looking for something similar but that can use mongodb as a database.
Is it possible to use motor for mongodb with turbulette?

Thanks for your interest in Turbulette!
Currently, Turbulette use GINO as ORM, and it's possible to use redis through async-caches for caching purposes.
We could add bindings to mongodb using motor, but keep in mind that Turbulette use GINO to interact with the main data source, so you will still have to setup a postgres db if you want to use the built-in auth app for example.
I think the work needed to make it real isn't that big :

Provide a nice way to configure multiple databases in settings
Expose a MotorClient in turbulette's db module

If we add support for more databases, I wonder if it would be a good idea to make db clients optional dependencies (including GINO?) so users could choose the one that best suits their needs, like in your case.

I think the work needed to make it real isn't that big :
* Provide a nice way to configure multiple databases in settings

* Expose a `MotorClient` in turbulette's `db` module

If we add support for more databases, I wonder if it would be a good idea to make db clients optional dependencies (including GINO?) so users could choose the one that best suits their needs, like in your case.
...
Well, I think that if it would be a great idea, it would also give users much more flexibility when choosing their db.

On the other hand, have you thought about including "subscription" and "websokects" in the core of Turbulette?

I will think about it ;)
All the GraphQL binding is handled by Ariadne, which support subscription operations via websockets. You can see more details here.
You make me realize that subscriptionType isn't even defined in Turbulette root_types, and isn't registered in the schema, meaning that you can't use subscription in Turbulette right now. Will fix this ASAP!
Otherwise, there will be nothing special about using subscriptions in Turbulette, you would just follow Ariadne's docs as long as the code live in the resolvers package.

Ok, :) I will wait for you fix it.

Hi @Barceloch ,
v0.4.0 fix websocket / subscription, it should be ready to use.
As Query and Mutation, Subscription is already defined in Turbulette so you can extend it in your app schema :
extend type Subscription {
	count: Int!
}

For the resolver part, use subscription from the turbulette package and follow Ariadne docs :
from turbulette import subscription

@subscription.source("counter")
async def counter_generator(obj, info):
    for i in range(5):
        await asyncio.sleep(1)
        yield i

@subscription.field("counter")
def counter_resolver(count, info):
    return count + 1

Hi @Barceloch ,
v0.4.0 fix websocket / subscription, it should be ready to use.
As Query and Mutation, Subscription is already defined in Turbulette so you can extend it in your app schema :
extend type Subscription {
	count: Int!
}

For the resolver part, use subscription from the turbulette package and follow Ariadne docs :
from turbulette import subscription

@subscription.source("counter")
async def counter_generator(obj, info):
    for i in range(5):
        await asyncio.sleep(1)
        yield i

@subscription.field("counter")
def counter_resolver(count, info):
    return count + 1

nice... in some days I will test this... ;)


Export ec2 instance monitoring state

Hi,
I added a missing key monitoring for ec2 resource.
The state of the API response could be disabled, disabling, enabled, pending.
I implemented this to output monitoring  = true only for enabled state.
refs:

http://docs.aws.amazon.com/sdkforruby/api/Aws/EC2/Types/Monitoring.html
https://www.terraform.io/docs/providers/aws/r/instance.html#monitoring

@ngs Is there any update?

Sorry for slow response. I'll fix this in this morning (JST).

@dtan4 Updated monitoring_state b8916376124e892277e312147e64abb211adf1d8

LGTM :+1: Thanks :exclamation:

Released as v0.3.1. Please try this :bow:

Thanks :pray:


UWP Platform can't compile

ObservableDebugExtensions.cs shows error when compile on UWP Platform.
It means can't find System.IObservable<T>.
File need using System; on line 1.
This is my mistake, sorry for all.

Fixed in UniRx 5.5.0.


Fix wrong assertion of the test: test_buckets_list_ctime

TestName:
s3tests_boto3.functional.test_s3:test_buckets_list_ctime
Problem:
The test creates 5 buckets for a user but in an assertion check,
it asserts false if any bucket of the user has CreationTime less than a day prior to the current time.
Due to this reason, the test fails if the user has pre-existing buckets older than a day.
Solution:
Assert only on the CreationTime of buckets that were created with test execution.

Is there something specific that is blocking this PR being merged? Or did it just slip through the cracks?
We've been running into this issue ourselves, would be handy if we could use this fix.

Is there something specific that is blocking this PR being merged? Or did it just slip through the cracks? We've been running into this issue ourselves, would be handy if we could use this fix.

thanks for the reminder, @jheunis-bloomberg. @alimaredia would you be willing to test this?

FYI, I cherry-picked this commit and tested it on our setup where it's ordinarily failing and it fixes the test:
2024-03-01 12:29:22,899 - DEBUG - 146 - Test OK after 0.73s: test_buckets_list_ctime

FYI, I cherry-picked this commit and tested it on our setup where the test is ordinarily failing and it fixes the test:
2024-03-01 12:29:22,899 - DEBUG - 146 - Test OK after 0.73s: test_buckets_list_ctime

@cbodley - Bob has verified the fix. Can we merge this one in?

merged in https://github.com/ceph/s3-tests/pull/565, thanks @sumedhak27 @bobham-bloomberg


Support ingress.kubernetes.io/configuration-snippet

Possibly support the ingress.kubernetes.io/configuration-snippet annotation
Most of the configuration for Envoy has a json or yaml representation so in theory it could be overlaid with the configuration passed back to Envoy in the caches. In practice this sounds quite hard to do, merging, then retaining the configuration in the face of dynamic updates from k8s, but it's still an interesting prospect.

We're not going to do this.


Blank Map

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
The map on the login website does not work, cannot create geofences.
Expected Behavior
Ability to see map correctly.
Steps To Reproduce
No response
Relevant log output
Nothing relevant in logs

Screenshots

Additional data
No response
Type of installation
Docker
Version
Docker Tag v1.26

Was centering to 0,0 because it had not updated the cars location from fresh install.

How did you resolve this?

Opened the Tesla app on my phone to wake the car up so Teslamate could pull
the location data.
On Thu, Feb 24, 2022 at 17:08 Omar Rahman @.***> wrote:

How did you resolve this?
—
Reply to this email directly, view it on GitHub
https://github.com/adriankumpf/teslamate/issues/2497#issuecomment-1050380909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABO7UUIMSKYB4PTFF66HSIDU43B7ZANCNFSM5PGKS4JA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

Opened the Tesla app on my phone to wake the car up so Teslamate could pull the location data.
…
On Thu, Feb 24, 2022 at 17:08 Omar Rahman @.> wrote: How did you resolve this? — Reply to this email directly, view it on GitHub <#2497 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO7UUIMSKYB4PTFF66HSIDU43B7ZANCNFSM5PGKS4JA . You are receiving this because you modified the open/close state.Message ID: @.>

gee...thanks, I've troubleshooted for a hour on this after a new installation.


Feedback & Issues

Greetings! i have been enjoying your modpack for quite a while now, sadly there is always a few mods that conflict. Yet thats okay since its still fun to use, especially when i scare my friends with the explosive tank scrap. However recently as of V56 and me retrying your pack i have to leave this post with observations

currently using LateGame Upgrades and both yours and this mod uses an item called "Medkit" which conflicts with each other, because if i buy one it uses LGU medkit model and i cant heal with it, if i disable it from the LGU config, yours also gets removed.

Trying to figure this out, but out of my mod profile that adds new items to buy, the moment i add UsualScrap the items in the shop get jumbled, for example if i buy a pro-flashlight i get a shotgun shell

These are the only issues and while i understand you are currently away from your computer, there is just but one thing i wish for you to make and thats a Config file if possible, more so to include the "Enable/Disable" items, since prices and rarity weights can be adjusted with other mods. However an true/fase config would be so helpful!
Either way, Thank you for an amazing mod and i will continue to keep an eye out for any future updates and new items you will add!

Thank you, I'm glad you've enjoyed it. A config for items was in the works before I left so I will get that done when I return, someone else also wanted that so I'm more than happy to add that. I will fix the medkit issue also, I'll just add a mod tag to any references of my items so that shouldn't  happen anymore. As for the jumbling of shop items I don't really know, you can't buy shotgun shells in vanilla so it's probably a mod conflict, just have to find out which mod or mods. If that is happening with only this mod or you figure out the mods conflicting please let me know, I'll try to fix that also. As you know, I'm away from my pc and currently writing from the GitHub app so I cannot work on anything regardless of how much a want to fix this stuff, It will be fixed when I return!

The item conflicts should be fixed now and configs have been added, enjoy! I will soon close this issue.


Implement globbing

We cannot use the globwalk crate as it does not support globbing for parent directories (i.e. paths like ../../* won't work).  We will probably need to roll our own directory walker, either by using globset or modifying glob to support OsStrings.

I added support for non-UTF-8 filenames in glob, so I think we'll just use that.  There are a couple of pull requests in the upstream repository that haven't been merged despite sitting there for a while, so we may want to fork the repository to merge in those changes.

This is also related to the IFS issue (#16) as we need to split the results of globbed expression based on IFS, so I will leave this open for now.


enable edit on github link

Description
enable "edit on github" button
Checklist
Essentials

[ ] Changes are complete (i.e. I finished coding on this PR)

Changes

[x] enable edit on github button in rtd theme

Job PR-337/1 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-337/1/index.html

Job PR-337/5 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-337/5/index.html

Still needs to tweak for the markdown-based notebooks.

Job PR-337/6 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-337/6/index.html

Job PR-337/8 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-337/8/index.html

Job PR-337/9 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-337/9/index.html

Job PR-337/12 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-337/12/index.html


Input

we should have a api like the <Button> one

[x] usage (with a Uppercase because it's a react component)

<Input type="text />

[x] Don't forget to spread the props

Component created


[Web] Handle WebView Full Screen callbacks via state

I tried to write a test for this but so far haven't gotten things to work in that environment. I checked the behaviour during whilst implementing the feature by fullscreening youtube videos in the sample app and showing a dialog with the provided view.

Probably best that I rebase this onto #1097 once that's merged

This one might be venturing into an area we probably don't want to support from the Accompanist version, I almost feel like people should fork their own implementation if they need this functionality.
The biggest part that worries me is that custom view and what that could mean if you want to pass in a ComposeView for it or a normal view and all the can of worms involved in that.

Yep, with the exposure of the WebChromeClient it makes a little less sense to support this explicitly. As for the custom view, it's essentially just what the WebView has given us. There could be an argument over whether it should be exposed as-is or wrapped in a composable and then exposed.
There also seems to be some ambiguity in the docs stating that if the showCustomView/hideCustomView methods are overridden at all then it will be taken to mean that the WebView supports it, and if they're not overridden it will be taken to mean that it doesn't support it. I couldn't find anything concrete to determine if a empty override method with a single super call is somehow seen as supporting fullscreen just by existing even if there's no actual implementation.

I'm going to go ahead and say that this is not something we want to support right now. I am hoping to get the Web wrapper in to a pretty stable state before Accompanist has it's next stable release so will be slowing down on adding new features.
Thanks for the PR again though.


[Feature]: ENV or CLI arg to listen on OTLP on all interfaces

Requirement
Right now, if you start jaeger v2, it listens for OTLP on localhost. This means docker hostnames don't connect. I would like an option to use an ENV value or CLI arg to listen on all interfaces.
Problem
Without this, I need to write a config file for something easy to do in other go daemons like otel-tui or ollama. I would like a simpler experience, and most importantly one that doesn't risk making other config errors.
Proposal
any env or CLI arg would be great
Open questions
No response

I found this out trying https://github.com/open-telemetry/opentelemetry.io/pull/5575 as I was using docker to run the openai instrumentation example. Then, eventually I noticed some listen ports default to localhost, and noticed flags are not supported https://docs.google.com/document/d/18B1yTMewRft2N0nW9K-ecVRTt5VaNgnrPTW1eL236t4/edit?tab=t.0

updated docs - this behavior can be changed using --set overrides.

excellent. thanks!


Unable to locate package certutil error after running  sudo apt-get update && sudo apt-get install -y certutil xdg-utils  - step 14  of ddev wsl2 install

Is there an existing issue for this?

[X] I have searched the existing issues

Run a Diagnostic and Paste Link Here
https://gist.github.com/therobyouknow/407fe334d59a66d3d3a040edf6d13697
Current Behavior
Unable to locate package certutil error after running  sudo apt-get update && sudo apt-get install -y certutil xdg-utils  - step 14 of  https://ddev.readthedocs.io/en/stable/users/install/ddev-installation/ for Windows WSL 2.
Expected Behavior
No error.
Steps To Reproduce
Windows 11 WSL2 Ubuntu 20.04, follow steps for Windows WSL2 up to and including step 14 https://ddev.readthedocs.io/en/stable/users/install/ddev-installation/
Anything else?
No response

Could you please say what Linux distro you were installing?

Ah, it should be libnss3-tools, see https://github.com/FiloSottile/mkcert#linux
Could you please do a PR to fix it? You can just click the pencil on the page.

Could you please say what Linux distro you were installing?

Ubuntu 20.04.    Thank you for responding so soon, always appreciate your help whenever you can.

Ah, it should be libnss3-tools, see https://github.com/FiloSottile/mkcert#linux
Could you please do a PR to fix it? You can just click the pencil on the page.

Thank you! Sure, I think I will be able to do that.  I'll aim for tomorrow morning UK time. I'm probably going to pause for now at 2324.  I'm super grateful for your response @rfay


Colorpicker field is weirdly rendered

Reproduction
https://formkit.link/
Describe the bug
For some reason, color picker fields render in this way
 <FormKit
        type="colorpicker"
        value="#DE1B1B"
        label="A default colorpicker input"
        popover
        help="Just the way it comes out of the box."
    />

    <FormKit
        type="colorpicker"
        inline
        value="hsla(240, 75%, 35%, 0.75)"
        label="An inline colorpicker input"
        help="Shows the colorpicker inline."
    />

Environment
• OS: Winsows 11
• Browser 124.0.6367.208 (Official Build) (64-bit)
• Version
"@formkit/pro": "^0.126.4",
"@formkit/vue": "^1.6.5",

Are you using the theme regenisis?

Are you using the theme regenisis?

Yes, here is the formkit.theme.js
https://gist.github.com/Lazerproof/f3de4d6fccd2651e62734945e73d0b04

It looks fine in the playground: https://formkit.link/80fe33e4aacc38d6ca142af5bcabef92
anything else you have there, like divs, manual changes to the classes?

@Lazerproof I'm going to close this for now, but if you're able to reproduce this in a new project please reopen and let us know.


[FRG] Alignment on Print elements does not align within assigned box

Consider this element definition
{"text":"Welcome to FluentReports","type":"print","settings":{"align":"center","width":234,"absoluteX":234,"absoluteY":0}}

Steps to generate:

Create a new Print element & change the text
Set the width to 234
Set the X to 234
Change the alignment to "Center"

The expectation, is that I would have a print that is half the width of my page, aligned to the right-hand side of my page. But then the text would be centered within the right-hand "column" on my page.
The result:

This is fixed in the next version.     The Text Box (i.e. 234 pixels text width/wrapping area) is moved to the proper alignment, and the text inside the text width/wrapping area is aligned to the proper alignment.    (Demo34 shows the output of a fixed width text box with alignments)

Fixed in 1.3.8


[Bug] DE Translation error in Page 7011 Direct Unit Cost

The German translation of the field "Direct Unit Cost" ist wrong in page 7011. It should be "EK-Preis" instead of "Einstandspreis". It is correct in page 7005.

Sorry, we are not able to fix translation bugs here, please report any issues you have via technical support.


MRG: Check spelling

The ultimate pedantic PR.
But really I just want to see if someone other than @maddycapp27 opening a PR will trigger CircleCI.

Of course it does. @maddycapp27 when you disabled CircleCI building for your fork, did you actually delete it on CircleCI, or just remove the webhook using the GitHub interface? I'm guessing it was the latter, but if you delete / remove continuous integration for your fork it should make it work properly.

Codecov Report

Merging #355 into master will increase coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #355      +/-   ##
==========================================
+ Coverage   89.03%   89.07%   +0.04%
==========================================
  Files          44       44
  Lines        5681     5832     +151
  Branches      917      963      +46
==========================================
+ Hits         5058     5195     +137
- Misses        427      437      +10
- Partials      196      200       +4

@maddycapp27 if you have time to take a quick look please do, then I'll merge

I support proper spelling :)
I looked at circleci and was able to revoke its permissions to my github but not to delete the integration. I'm not sure if that's enough.

Thanks for the look @maddycapp27, we'll see on the CircleCI issue on your next PR :)


allow BindData to be called for each configured environment, using conditional compliation flags/filenames

This PR updates the "bd" subcommand with the ability to call BindData on each environment configured (or just the runtime.GOOS/GOARCH combination if no environments are specifically configured).
Each binddata file is named and uses build tags to ensure no collisions between files occur.
This will allow for cross compliation using a single bundler binddata command.

Updated :)

Cheers