Fix endianness problem in sshkdf

Handling of parameter OSSL_KDF_PARAM_SSHKDF_TYPE caused endianness problems on
s390.  It is not possible to pass FIPS tests since the parameter was stored
with an integer value but read via a cast to char pointer.  While this works
on little endian machines, big endian s390 read the most significant bits
instead of the least significant (as done by, e.g., x86).  Change the
parameter to char array and fix the usages.
Signed-off-by: Juergen Christ<EMAIL_ADDRESS>
Checklist

[x] documentation is added or updated
[x] tests are added or updated

Wouldn't it make actually more sense to fix this at the provider side? To treat the parameter as integer and not as an UTF8 string.

Wouldn't it make actually more sense to fix this at the provider side? To treat the parameter as integer and not as an UTF8 string.

The tests seemed to indicate that this should actually be a one-letter string consisting of a letter from the range 'A' to 'F'.  But of course we could also change the tests to provide the correct integer value.  See file test/recipes/30-test_evp_data/evpkdf_ssh.txt (Ctrl.type = type:A for example)

The tests seemed to indicate that this should actually be a one-letter string consisting of a letter from the range 'A' to 'F'.  But of course we could also change the tests to provide the correct integer value.  See file test/recipes/30-test_evp_data/evpkdf_ssh.txt (Ctrl.type = type:A for example)

And the documentation would have to be changed too but in a different way. So it is really a matter of taste which approach would be better.
@openssl/otc Any other opinion? Also shouldn't we actually error out if a numeric parameter is treated as string or vice-versa?

And the documentation would have to be changed too but in a different way. So it is really a matter of taste which approach would be better.
@openssl/otc Any other opinion? Also shouldn't we actually error out if a numeric parameter is treated as string or vice-versa?

Also please to accept this we would need your ICLA submitted.

Also please to accept this we would need your ICLA submitted.

Also please to accept this we would need your ICLA submitted.

That is already done, but the company CCLA update is still pending...

Also please to accept this we would need your ICLA submitted.

That is already done, but the company CCLA update is still pending...

Any other opinion?

I have no strong view. Maybe @slontis does...?

Any other opinion?

I have no strong view. Maybe @slontis does...?

I am on holidays till next week.
I would just leave this as a integer and address the issue it has with using integers.

I am on holidays till next week.
I would just leave this as a integer and address the issue it has with using integers.

Character set concerns appear if it is changed to a UTF-8 string.  EBCDIC vs ASCII primarily.
I agree with @slontis's approach.

Character set concerns appear if it is changed to a UTF-8 string.  EBCDIC vs ASCII primarily.
I agree with @slontis's approach.

That is already done, but the company CCLA update is still pending...

CCLA has been received but it only lists one of your email addresses, and not your "linux.ibm.com" one (just your "ibm.com" one) - so CLA check is still going to fail. Can we either get CCLA changed to list all valid emails, or update the author field in the commits here?

That is already done, but the company CCLA update is still pending...

CCLA has been received but it only lists one of your email addresses, and not your "linux.ibm.com" one (just your "ibm.com" one) - so CLA check is still going to fail. Can we either get CCLA changed to list all valid emails, or update the author field in the commits here?

If this is really an integer then it should be doing something like the following inside kdf_sshkdf_set_ctx_params().
if (!OSSL_PARAM_get_int(p, &t)
    || t < EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV
    || t > EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI) {

instead of doing
t = *(unsigned char *)p->data;
if (t < 65 || t > 70) {

If this is really an integer then it should be doing something like the following inside kdf_sshkdf_set_ctx_params().
if (!OSSL_PARAM_get_int(p, &t)
    || t < EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV
    || t > EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI) {

instead of doing
t = *(unsigned char *)p->data;
if (t < 65 || t > 70) {

Hmmmm, this is originally a size issue, isn't it?  Doesn't the recently merged #13429 help?

Hmmmm, this is originally a size issue, isn't it?  Doesn't the recently merged #13429 help?

@t8m sez:

Also shouldn't we actually error out if a numeric parameter is treated as string or vice-versa?

Yes, but it seems we don't check the data type in that particular case...  no idea why.
https://github.com/openssl/openssl/blob/e211d949cd5737e53cd3399e6a88453930768b98/providers/implementations/kdfs/sshkdf.c#L157-L167

@t8m sez:

Also shouldn't we actually error out if a numeric parameter is treated as string or vice-versa?

Yes, but it seems we don't check the data type in that particular case...  no idea why.
https://github.com/openssl/openssl/blob/e211d949cd5737e53cd3399e6a88453930768b98/providers/implementations/kdfs/sshkdf.c#L157-L167

Character set concerns appear if it is changed to a UTF-8 string. EBCDIC vs ASCII primarily.

The owner of the used OSSL_PARAM array needs to ensure that it's actual UTF-8, i.e. convert from EBCDIC to ASCII (since the latter is UTF-8 compatible)

Character set concerns appear if it is changed to a UTF-8 string. EBCDIC vs ASCII primarily.

The owner of the used OSSL_PARAM array needs to ensure that it's actual UTF-8, i.e. convert from EBCDIC to ASCII (since the latter is UTF-8 compatible)

Considering A to F, could it be that the original intent was hex?

Considering A to F, could it be that the original intent was hex?

Considering A to F, could it be that the original intent was hex?

No, it really is ASCII A to F (see https://tools.ietf.org/html/rfc4253#section-7.2)

Considering A to F, could it be that the original intent was hex?

No, it really is ASCII A to F (see https://tools.ietf.org/html/rfc4253#section-7.2)

Considering A to F, could it be that the original intent was hex?

No, it really is ASCII A to F (see https://tools.ietf.org/html/rfc4253#section-7.2)

Thank you!  I was trying to find this info, but my google-fu failed me.
They are presented as ASCII strings in the RFC...  in that case, I fail to see why we should make them integers...  for EBCDIC, it's not that hard to convert (since we have the tools), and the provider side already does the right thing by picking out the first character and comparing it with ASCII codes, all that's lacking there is a check that the data type is OSSL_PARAM_UTF8_STRING.

Considering A to F, could it be that the original intent was hex?

No, it really is ASCII A to F (see https://tools.ietf.org/html/rfc4253#section-7.2)

Thank you!  I was trying to find this info, but my google-fu failed me.
They are presented as ASCII strings in the RFC...  in that case, I fail to see why we should make them integers...  for EBCDIC, it's not that hard to convert (since we have the tools), and the provider side already does the right thing by picking out the first character and comparing it with ASCII codes, all that's lacking there is a check that the data type is OSSL_PARAM_UTF8_STRING.

Really hoping this one gets merged soon.

Really hoping this one gets merged soon.

@juergenchrist Have you made any headway on this?

@juergenchrist Have you made any headway on this?

Having looked at this a number of times, and also played around with an integer solution, I still lean toward this PR over that, most of all because of usability concerns.  Someone playing around with SSHKDF will no doubt have read RFC 4253, or other descriptions derived from that RFC, and will no doubt have heard that there are types, denoted with a single ASCII character.
If we change the type according to docs, i.e. make it an actual integer, these are examples of usability consequences:
diff --git a/test/recipes/20-test_kdf.t b/test/recipes/20-test_kdf.t
index d0ea07ee9a..8d40b35b42 100755
--- a/test/recipes/20-test_kdf.t
+++ b/test/recipes/20-test_kdf.t
@@ -37,7 +37,7 @@ my @kdf_tests = (
     { cmd => [qw{openssl kdf -keylen 14 -kdfopt digest:SHA224 -kdfopt hexkey:6dbdc23f045488e4062757b06b9ebae183fc5a5946d80db93fec6f62ec07e3727f0126aed12ce4b262f47d48d54287f81d474c7c3b1850e9 -kdfopt hexinfo:a1b2c3d4e54341565369643c832e9849dcdba71e9a3139e606e095de3c264a66e98a165854cd07989b1ee0ec3f8dbe SSKDF}],
       expected => 'a4:62:de:16:a8:9d:e8:46:6e:f5:46:0b:47:b8',
       desc => 'SSKDF HASH SHA224'},
-    { cmd => [qw{openssl kdf -keylen 16 -kdfopt digest:SHA256 -kdfopt hexkey:0102030405 -kdfopt hexxcghash:06090A -kdfopt hexsession_id:01020304 -kdfopt type:A SSHKDF}],
+    { cmd => [qw{openssl kdf -keylen 16 -kdfopt digest:SHA256 -kdfopt hexkey:0102030405 -kdfopt hexxcghash:06090A -kdfopt hexsession_id:01020304 -kdfopt hextype:41 SSHKDF}],
     expected => '5C:49:94:47:3B:B1:53:3A:58:EB:19:42:04:D3:78:16',
     desc => 'SSHKDF SHA256'},
 );

diff --git a/test/recipes/30-test_evp_data/evpkdf_ssh.txt b/test/recipes/30-test_evp_data/evpkdf_ssh.txt
index d870df7037..8a49d03e6d 100644
--- a/test/recipes/30-test_evp_data/evpkdf_ssh.txt
+++ b/test/recipes/30-test_evp_data/evpkdf_ssh.txt
@@ -19,7 +19,8 @@ Ctrl.digest = digest:SHA1
 Ctrl.hexkey = hexkey:0000008055bae931c07fd824bf10add1902b6fbc7c665347383498a686929ff5a25f8e40cb6645ea814fb1a5e0a11f852f86255641e5ed986e83a78bc8269480eac0b0dfd770cab92e7a28dd87ff452466d6ae867cead63b366b1c286e6c4811a9f14c27aea14c5171d49b78c06e3735d36e6a3be321dd5fc82308f34ee1cb17fba94a59
 Ctrl.hexxcghash = hexxcghash:a4ebd45934f56792b5112dcd75a1075fdc889245
 Ctrl.hexsession_id = hexsession_id:a4ebd45934f56792b5112dcd75a1075fdc889245
-Ctrl.type = type:A
+# 41 = hex ASCII code for "A"
+Ctrl.hextype = hextype:41
 Output = e2f627c0b43f1ac1

 KDF = SSHKDF

Forcing the users to constantly re-calculate a letter to hex isn't exactly friendly...
I would, however, add this change:
diff --git a/providers/implementations/kdfs/sshkdf.c b/providers/implementations/kdfs/sshkdf.c
index daf0dd2e87..e86c502184 100644
--- a/providers/implementations/kdfs/sshkdf.c
+++ b/providers/implementations/kdfs/sshkdf.c
@@ -135,7 +135,6 @@ static int kdf_sshkdf_set_ctx_params(void *vctx, const OSSL_PARAM params[])
     const OSSL_PARAM *p;
     KDF_SSHKDF *ctx = vctx;
     OSSL_LIB_CTX *provctx = PROV_LIBCTX_OF(ctx->provctx);
-    int t;

     if (!ossl_prov_digest_load_from_params(&ctx->digest, params, provctx))
         return 0;
@@ -156,14 +155,17 @@ static int kdf_sshkdf_set_ctx_params(void *vctx, const OSSL_PARAM params[])

     if ((p = OSSL_PARAM_locate_const(params, OSSL_KDF_PARAM_SSHKDF_TYPE))
         != NULL) {
-        if (p->data == NULL || p->data_size == 0)
+        const char *kdftype;
+
+        if (!OSSL_PARAM_get_utf8_string_ptr(p, &kdftype))
+            return 0;
+        if (kdftype == NULL || kdftype[0] == '\0' || kdftype[1] != '\0')
             return 0;
-        t = *(unsigned char *)p->data;
-        if (t < 65 || t > 70) {
+        if (kdftype[0] < 65 || kdftype[0] > 70) {
             ERR_raise(ERR_LIB_PROV, PROV_R_VALUE_ERROR);
             return 0;
         }
-        ctx->type = (char)t;
+        ctx->type = kdftype[0];
     }
     return 1;
 }

Regarding the issue of EBCDIC, it turns out to be easy to solve.  PR coming up!

Having looked at this a number of times, and also played around with an integer solution, I still lean toward this PR over that, most of all because of usability concerns.  Someone playing around with SSHKDF will no doubt have read RFC 4253, or other descriptions derived from that RFC, and will no doubt have heard that there are types, denoted with a single ASCII character.
If we change the type according to docs, i.e. make it an actual integer, these are examples of usability consequences:
diff --git a/test/recipes/20-test_kdf.t b/test/recipes/20-test_kdf.t
index d0ea07ee9a..8d40b35b42 100755
--- a/test/recipes/20-test_kdf.t
+++ b/test/recipes/20-test_kdf.t
@@ -37,7 +37,7 @@ my @kdf_tests = (
     { cmd => [qw{openssl kdf -keylen 14 -kdfopt digest:SHA224 -kdfopt hexkey:6dbdc23f045488e4062757b06b9ebae183fc5a5946d80db93fec6f62ec07e3727f0126aed12ce4b262f47d48d54287f81d474c7c3b1850e9 -kdfopt hexinfo:a1b2c3d4e54341565369643c832e9849dcdba71e9a3139e606e095de3c264a66e98a165854cd07989b1ee0ec3f8dbe SSKDF}],
       expected => 'a4:62:de:16:a8:9d:e8:46:6e:f5:46:0b:47:b8',
       desc => 'SSKDF HASH SHA224'},
-    { cmd => [qw{openssl kdf -keylen 16 -kdfopt digest:SHA256 -kdfopt hexkey:0102030405 -kdfopt hexxcghash:06090A -kdfopt hexsession_id:01020304 -kdfopt type:A SSHKDF}],
+    { cmd => [qw{openssl kdf -keylen 16 -kdfopt digest:SHA256 -kdfopt hexkey:0102030405 -kdfopt hexxcghash:06090A -kdfopt hexsession_id:01020304 -kdfopt hextype:41 SSHKDF}],
     expected => '5C:49:94:47:3B:B1:53:3A:58:EB:19:42:04:D3:78:16',
     desc => 'SSHKDF SHA256'},
 );

diff --git a/test/recipes/30-test_evp_data/evpkdf_ssh.txt b/test/recipes/30-test_evp_data/evpkdf_ssh.txt
index d870df7037..8a49d03e6d 100644
--- a/test/recipes/30-test_evp_data/evpkdf_ssh.txt
+++ b/test/recipes/30-test_evp_data/evpkdf_ssh.txt
@@ -19,7 +19,8 @@ Ctrl.digest = digest:SHA1
 Ctrl.hexkey = hexkey:0000008055bae931c07fd824bf10add1902b6fbc7c665347383498a686929ff5a25f8e40cb6645ea814fb1a5e0a11f852f86255641e5ed986e83a78bc8269480eac0b0dfd770cab92e7a28dd87ff452466d6ae867cead63b366b1c286e6c4811a9f14c27aea14c5171d49b78c06e3735d36e6a3be321dd5fc82308f34ee1cb17fba94a59
 Ctrl.hexxcghash = hexxcghash:a4ebd45934f56792b5112dcd75a1075fdc889245
 Ctrl.hexsession_id = hexsession_id:a4ebd45934f56792b5112dcd75a1075fdc889245
-Ctrl.type = type:A
+# 41 = hex ASCII code for "A"
+Ctrl.hextype = hextype:41
 Output = e2f627c0b43f1ac1

 KDF = SSHKDF

Forcing the users to constantly re-calculate a letter to hex isn't exactly friendly...
I would, however, add this change:
diff --git a/providers/implementations/kdfs/sshkdf.c b/providers/implementations/kdfs/sshkdf.c
index daf0dd2e87..e86c502184 100644
--- a/providers/implementations/kdfs/sshkdf.c
+++ b/providers/implementations/kdfs/sshkdf.c
@@ -135,7 +135,6 @@ static int kdf_sshkdf_set_ctx_params(void *vctx, const OSSL_PARAM params[])
     const OSSL_PARAM *p;
     KDF_SSHKDF *ctx = vctx;
     OSSL_LIB_CTX *provctx = PROV_LIBCTX_OF(ctx->provctx);
-    int t;

     if (!ossl_prov_digest_load_from_params(&ctx->digest, params, provctx))
         return 0;
@@ -156,14 +155,17 @@ static int kdf_sshkdf_set_ctx_params(void *vctx, const OSSL_PARAM params[])

     if ((p = OSSL_PARAM_locate_const(params, OSSL_KDF_PARAM_SSHKDF_TYPE))
         != NULL) {
-        if (p->data == NULL || p->data_size == 0)
+        const char *kdftype;
+
+        if (!OSSL_PARAM_get_utf8_string_ptr(p, &kdftype))
+            return 0;
+        if (kdftype == NULL || kdftype[0] == '\0' || kdftype[1] != '\0')
             return 0;
-        t = *(unsigned char *)p->data;
-        if (t < 65 || t > 70) {
+        if (kdftype[0] < 65 || kdftype[0] > 70) {
             ERR_raise(ERR_LIB_PROV, PROV_R_VALUE_ERROR);
             return 0;
         }
-        ctx->type = (char)t;
+        ctx->type = kdftype[0];
     }
     return 1;
 }

Regarding the issue of EBCDIC, it turns out to be easy to solve.  PR coming up!

I added the patch from @levitte regarding the additional checks.  Not sure about the documentation changes mentioned by @t8m.  Can anybody help me out here?  Also I cannot reproduce the error in the GitHub CI locally.  For me, 30-test_evp_kdf.t passes without failure.

I added the patch from @levitte regarding the additional checks.  Not sure about the documentation changes mentioned by @t8m.  Can anybody help me out here?  Also I cannot reproduce the error in the GitHub CI locally.  For me, 30-test_evp_kdf.t passes without failure.

It may be that this diff will fix the failures:
diff --git a/test/evp_kdf_test.c b/test/evp_kdf_test.c
index d56e14cdb0..ccb930a881 100644
--- a/test/evp_kdf_test.c
+++ b/test/evp_kdf_test.c
@@ -1207,7 +1207,9 @@ static int test_kdf_sshkdf(void)
     int ret;
     EVP_KDF_CTX *kctx;
     OSSL_PARAM params[6], *p = params;
-    char kdftype = EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV;
+    char kdftype[] = {
+        EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV, 0
+    };
     unsigned char out[8];
     /* Test data from NIST CAVS 14.1 test vectors */
     static unsigned char key[] = {
@@ -1247,7 +1249,7 @@ static int test_kdf_sshkdf(void)
     *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SSHKDF_SESSION_ID,
                                              sessid, sizeof(sessid));
     *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
-                                            &kdftype, sizeof(kdftype));
+                                            kdftype, sizeof(kdftype));
     *p = OSSL_PARAM_construct_end();

     ret =

It may be that this diff will fix the failures:
diff --git a/test/evp_kdf_test.c b/test/evp_kdf_test.c
index d56e14cdb0..ccb930a881 100644
--- a/test/evp_kdf_test.c
+++ b/test/evp_kdf_test.c
@@ -1207,7 +1207,9 @@ static int test_kdf_sshkdf(void)
     int ret;
     EVP_KDF_CTX *kctx;
     OSSL_PARAM params[6], *p = params;
-    char kdftype = EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV;
+    char kdftype[] = {
+        EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV, 0
+    };
     unsigned char out[8];
     /* Test data from NIST CAVS 14.1 test vectors */
     static unsigned char key[] = {
@@ -1247,7 +1249,7 @@ static int test_kdf_sshkdf(void)
     *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SSHKDF_SESSION_ID,
                                              sessid, sizeof(sessid));
     *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
-                                            &kdftype, sizeof(kdftype));
+                                            kdftype, sizeof(kdftype));
     *p = OSSL_PARAM_construct_end();

     ret =

Please also fix the # define EVP_KDF_CTRL_SET_SSHKDF_TYPE        0x11 /* int */ in kdf.h. And maybe also add comments to the individual SSHKDF_TYPE values there like ASCII A, and so on.

Please also fix the # define EVP_KDF_CTRL_SET_SSHKDF_TYPE        0x11 /* int */ in kdf.h. And maybe also add comments to the individual SSHKDF_TYPE values there like ASCII A, and so on.

Please also fix the # define EVP_KDF_CTRL_SET_SSHKDF_TYPE        0x11 /* int */ in kdf.h.

Er, that's completely separate, isn't it?  A question, however, is why we have these CTRL macros at all.

Please also fix the # define EVP_KDF_CTRL_SET_SSHKDF_TYPE        0x11 /* int */ in kdf.h.

Er, that's completely separate, isn't it?  A question, however, is why we have these CTRL macros at all.

I got confused by the KDF_CTRL macros. They should not be there at all. And I'd still like to see the comments with the SSHKDF_TYPE values in the header.

I got confused by the KDF_CTRL macros. They should not be there at all. And I'd still like to see the comments with the SSHKDF_TYPE values in the header.

Shouldn't we also change the macros for the values?  I see the patch from @levitte changes the usage of the macros, but having every user create their own arrays is a little error-prone.  We could do something like
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV     (char[]){65, 0}
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_SRV_TO_CLI     (char[]){66, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV (char[]){67, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI (char[]){68, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV  (char[]) {69, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

And also add some comments to the values.  Also then, if we adjust the pod-documentation, It really fits together since these values can then directly be used to create the parameter.
Regarding the EVP_KDF_CTRL_SET_SSHKDF_TYPE macro: It seems unused, but I was not sure what it was supposed to be used for.  So I just kept it.  If you want, I can also remove it (and similarly the other EVP_KDF_CTRL_SET_SSHKDF_* macros since they also seem to be unused).

Shouldn't we also change the macros for the values?  I see the patch from @levitte changes the usage of the macros, but having every user create their own arrays is a little error-prone.  We could do something like
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV     (char[]){65, 0}
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_SRV_TO_CLI     (char[]){66, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV (char[]){67, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI (char[]){68, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV  (char[]) {69, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

And also add some comments to the values.  Also then, if we adjust the pod-documentation, It really fits together since these values can then directly be used to create the parameter.
Regarding the EVP_KDF_CTRL_SET_SSHKDF_TYPE macro: It seems unused, but I was not sure what it was supposed to be used for.  So I just kept it.  If you want, I can also remove it (and similarly the other EVP_KDF_CTRL_SET_SSHKDF_* macros since they also seem to be unused).

Shouldn't we also change the macros for the values? I see the patch from @levitte changes the usage of the macros, but having every user create their own arrays is a little error-prone. We could do something like
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV     (char[]){65, 0}
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_SRV_TO_CLI     (char[]){66, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV (char[]){67, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI (char[]){68, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV  (char[]) {69, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

That makes sense to me.

And also add some comments to the values. Also then, if we adjust the pod-documentation, It really fits together since these values can then directly be used to create the parameter.
Regarding the EVP_KDF_CTRL_SET_SSHKDF_TYPE macro: It seems unused, but I was not sure what it was supposed to be used for. So I just kept it. If you want, I can also remove it (and similarly the other EVP_KDF_CTRL_SET_SSHKDF_* macros since they also seem to be unused).

Yep, please do that, possibly as a separate commit as it is an unrelated change.

Shouldn't we also change the macros for the values? I see the patch from @levitte changes the usage of the macros, but having every user create their own arrays is a little error-prone. We could do something like
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV     (char[]){65, 0}
#define EVP_KDF_SSHKDF_TYPE_INITIAL_IV_SRV_TO_CLI     (char[]){66, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV (char[]){67, 0}
#define EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI (char[]){68, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV  (char[]) {69, 0}
#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

That makes sense to me.

And also add some comments to the values. Also then, if we adjust the pod-documentation, It really fits together since these values can then directly be used to create the parameter.
Regarding the EVP_KDF_CTRL_SET_SSHKDF_TYPE macro: It seems unused, but I was not sure what it was supposed to be used for. So I just kept it. If you want, I can also remove it (and similarly the other EVP_KDF_CTRL_SET_SSHKDF_* macros since they also seem to be unused).

Yep, please do that, possibly as a separate commit as it is an unrelated change.

#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

Is that portable?

#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

Is that portable?

Well, the use of macros is counter-intuitive in this case.  If I came from having read the docs, I wonder why I should do more than this:
char kdftype[] = "A";
...
params++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
                                            kdftype, sizeof(kdftype));

Well, the use of macros is counter-intuitive in this case.  If I came from having read the docs, I wonder why I should do more than this:
char kdftype[] = "A";
...
params++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
                                            kdftype, sizeof(kdftype));

#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

Is that portable?

That's definitely not acceptable C90.

#define EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI  (char[]) {70, 0}

Is that portable?

That's definitely not acceptable C90.

You are right, but the problem I wanted to avoid is this:
char *kdftype = "A";
...
params++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
                                            kdftype, sizeof(kdftype));

I'm very sure this bug will happen...

You are right, but the problem I wanted to avoid is this:
char *kdftype = "A";
...
params++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
                                            kdftype, sizeof(kdftype));

I'm very sure this bug will happen...

You are right, but the problem I wanted to avoid is this:

Heh, that is a fairly typical not experienced enough C coder problem.  Mastering that sort of thing is what makes you earn your wings :wink:

You are right, but the problem I wanted to avoid is this:

Heh, that is a fairly typical not experienced enough C coder problem.  Mastering that sort of thing is what makes you earn your wings :wink:

AFAIK, the Endian question was addressed in the early 1980s using:

htons(): host to network short
htonl(): host to network long
ntohs(): network to host short
ntohl(): network to host long

although there was never support for long long, which, I guess is why these fell out of favour. Just saying. That was one of the first things I learned trying to use Berkeley sockets back in (mumblemumble) to talk between machines even when both were little Endian so that network traces would be presentable. Yes, I know it's a non-sequitur, but this is a blocker for my exotic NonStop platform.

AFAIK, the Endian question was addressed in the early 1980s using:

htons(): host to network short
htonl(): host to network long
ntohs(): network to host short
ntohl(): network to host long

although there was never support for long long, which, I guess is why these fell out of favour. Just saying. That was one of the first things I learned trying to use Berkeley sockets back in (mumblemumble) to talk between machines even when both were little Endian so that network traces would be presentable. Yes, I know it's a non-sequitur, but this is a blocker for my exotic NonStop platform.

I pushed an updated version with all requested changes.  Please have another look.  @rsbeckerca I can relate.  This is also a blocker for s390x.  This used to be covered via travis.  Not sure if/how this is covered now.

I pushed an updated version with all requested changes.  Please have another look.  @rsbeckerca I can relate.  This is also a blocker for s390x.  This used to be covered via travis.  Not sure if/how this is covered now.

Actually this is not an endianness problem per-se. Yes, it demonstrates on big endian machines only but it is actually a problem of misuse of different parameter types here. Maybe that should be reflected in the commit message more prominently - in the first line.

Actually this is not an endianness problem per-se. Yes, it demonstrates on big endian machines only but it is actually a problem of misuse of different parameter types here. Maybe that should be reflected in the commit message more prominently - in the first line.

The second commit message is unfortunately also misleading talking about removal of the TYPE values and not about removal of the CTRL values.

The second commit message is unfortunately also misleading talking about removal of the TYPE values and not about removal of the CTRL values.

I pushed an updated version with all requested changes. Please have another look. @rsbeckerca I can relate. This is also a blocker for s390x. This used to be covered via travis. Not sure if/how this is covered now.

@juergenchrist On NonStop, it is covered by me building and testing a whole bunch of different configurations on two different architectures and reporting the result back to the team. GitHub does not have a virtual NonStop or s390 box, sadly.

I pushed an updated version with all requested changes. Please have another look. @rsbeckerca I can relate. This is also a blocker for s390x. This used to be covered via travis. Not sure if/how this is covered now.

@juergenchrist On NonStop, it is covered by me building and testing a whole bunch of different configurations on two different architectures and reporting the result back to the team. GitHub does not have a virtual NonStop or s390 box, sadly.

The second commit message is unfortunately also misleading talking about removal of the TYPE values and not about removal of the CTRL values.

Sorry, that was a copy/paste error.  Fixed now.

The second commit message is unfortunately also misleading talking about removal of the TYPE values and not about removal of the CTRL values.

Sorry, that was a copy/paste error.  Fixed now.

Ping @openssl/committers for the second review.

Ping @openssl/committers for the second review.

This pull request is ready to merge

This pull request is ready to merge

merged.
master: https://github.com/openssl/openssl/commit/d744934b756bc71344818a2cb60b13dd89954afb https://github.com/openssl/openssl/commit/270a5ce1d9ea579a2f1d45887971582b1ef2b6a1

merged.
master: https://github.com/openssl/openssl/commit/d744934b756bc71344818a2cb60b13dd89954afb https://github.com/openssl/openssl/commit/270a5ce1d9ea579a2f1d45887971582b1ef2b6a1


Update README.md

Update wording that reads better

Current Behavior

Proposed Changes

Checks

[x] All commits in this Pull Request are signed and Verified by Github.
[x] All commits in this Pull Request follow the Ockam commit message convention.
[x] I accept the Ockam Community Code of Conduct.
[x] I have accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository.

@NathanTarbert sorry that we had trouble landing your changes. I've worked around the problem and landed your changes from the two PRs and landed them in https://github.com/build-trust/ockam/pull/3975 .. while making sure your credit is maintained in the commit log.
Thank you so much for spending time on improving the README .. looking forward to many more contributions. Now that the committers file has both your email, it should be easy to land any future contributions.

Thank you so much @mrinalwadhwa


match statement is not parsed correctly

This is correct GDScript code, but you get "Expected end of statement after expression" error on any match pattern after the first one:
func match_func():
  var str = "hello"
  match str:
    "world":
      pass
    "hello":
      pass
    "third":
      pass

Fix with latest 0.3.2


[RDKDEV-262] DeviceIdentification: syncup from metro version

Copyright scan failure
Commit: eb10349e2c6bda64e92d243952a8955d0eff6203
Report detail: https://gist.github.com/68072a86f26736911f0ed4351750ece2


Discussion: Refactoring of registering order for MVC default services

I see several MVC services whose extensions for IMvcCoreBuilder calls more than once while application starts. In my test project MvcServiceCollectionExtensions.AddMvc method calls only once from Startup.ConfigureServices method.

Views registration does via MvcViewFeaturesMvcCoreBuilderExtensions.AddViews and it calls 2 times (once directly from MvcServiceCollectionExtensions.AddMvc and second once from MvcRazorMvcCoreBuilderExtensions.AddRazorViewEngine, which also calls from MvcServiceCollectionExtensions.AddMvc)
Data annotations registration does via MvcDataAnnotationsMvcCoreBuilderExtensions.AddDataAnnotations and it calls 3 times (twice because  MvcViewFeaturesMvcCoreBuilderExtensions.AddViews executes twice and third once directly from MvcServiceCollectionExtensions.AddMvc)

Are there any reasons for this registration flow?

The registrations are all conditional and should not be problematic in themselves. Does the current excess registrations cause an issue in your scenarios?
FYI the duplication probably comes from us ensuring the registrations all occur in common Startup classes.

@dougbu nope, it isn't cause any issues. I've just wanted to pay attention on it, because for me redundant calls looks strange.

These calls are designed to be idempotent and also include their dependencies. A bunch of stuff is reliant on data annotations (for example) and so it harmlessly gets called multiple times.


cannot import name 'ClimateEntity' from homeassistant.components.climate

Setting up Bosch Compress 7000i AW using IVT HTTP.
Latest HA version.
I installed this component from downloading the master branch? I see now that there is releases as well. I’ll test a release and see if the problem disappear.
I manually added the component through integrations. From what I can tell it only added one entity: water_heater.dhw1. and I get the following errors:
2020-05-01 09:27:01 ERROR (MainThread) [homeassistant.setup] Unable to prepare setup for platform bosch.climate: Platform not found (cannot import name 'ClimateEntity' from 'homeassistant.components.climate' (/usr/src/homeassistant/homeassistant/components/climate/__init__.py)).
2020-05-01 09:28:02 ERROR (MainThread) [homeassistant.helpers.entity] Update for water_heater.dhw1 fails
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 279, in async_update_ha_state
    await self.async_device_update()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 472, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/bosch/water_heater.py", line 208, in update
    self.async_schedule_update_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 443, in async_schedule_update_ha_state
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 297, in async_write_ha_state
    self._async_write_ha_state()  # type: ignore
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 314, in _async_write_ha_state
    attr = self.capability_attributes
  File "/usr/src/homeassistant/homeassistant/components/water_heater/__init__.py", line 153, in capability_attributes
    self.hass, self.min_temp, self.temperature_unit, self.precision
  File "/usr/src/homeassistant/homeassistant/helpers/temperature.py", line 26, in display_temp
    temperature = convert_temperature(temperature, temperature_unit, ha_unit)
  File "/usr/src/homeassistant/homeassistant/util/temperature.py", line 29, in convert
    raise ValueError(UNIT_NOT_RECOGNIZED_TEMPLATE.format(from_unit, TEMPERATURE))
ValueError: None is not a recognized temperature unit.

I'd say that 0.7.2 version is pretty stable and master branch/0.8.x versions are testing. I added XMPP support and same time HA changes way of handling climate device...
Anyway I fixed issue of adding climate component.
For DHW I think I need bosch_scan of your setup as I cannot reproduce same bug.

I downloaded the latest from master now, and your fix seem to have fixed this! Thanks a lot!


Undo (and prevent) reflow of copyright blocks.

I committed the changes that reflowed the copyright blocks for
CMake files because ~I am a dummy~ by accident. Undo those changes.

Thank you!


Search using the search box in the menu panel does not work in Firefox

Search from the left menu panel does not work as expected in Firefox but does work in Chrome and Edge
Expected Behavior
Entering a search term in the search box in the left panel the search should return only entities matching the search term
Current Behavior
All entities are returned, the search term is missing in the search query parameter
Possible Solution

Steps to Reproduce

Use Firefox
Enter a search term in the search box in the left panel and press enter
All entities are returned and the query parameter is empty. I.e http://localhost:3000/search?query=

Context

Firefox (incorrect)

Edge (correct)

Your Environment

NodeJS Version (v12): v14.17.4
Operating System and Version (e.g. Ubuntu 14.04): Windows 10 20H2
Browser Information: Firefox 91.0.2 (64-bit)

Confirmed. But for me, the search term WAS transferred to the box in the result page, but the location bar was not updated. So a bit of a mix.

Also you can see in the location bar that it flickers between at least two different states before settling.

It's like it first loads the location with no term, then with term and filters, then reverts back the location bar to no term but keeps the page contents

It seems like it works if I click on the magnifying glass

But not when hitting enter to search.


Remove the segmatch dependency to laser_slam

The goal is to remove that dependency: https://github.com/ethz-asl/segmatch/blob/master/segmatch/package.xml#L21
This should easily be done by moving the definitions of laser_slam/include/common.h to a separate package which could be in this repository: https://github.com/ethz-asl/laser_slam/blob/master/laser_slam/include/laser_slam/common.hpp
I would suggest to wait until we open source the latest segmatch version.

@dotPiano fyi this is what we discussed about.

@rdube  Has a separate SegMatch repository been created ( without laser_slam dependencies )?


Missing Docker images

It looks like mrnetops/fastly-exporter is missing the v6.1.0 release on Docker Hub..

/cc @mrnetops

Would it be useful to add a CI pipeline to publish them automatically?

Nah, I'm not interested in supporting Docker containers as release artifacts.

Ah, there's a repo for those! Please 301 to https://github.com/mrnetops/fastly-exporter-docker 🙏

I'm reconsidering — if an Action can publish automatically, it might be fine.

GitHub actions or CircleCI, whatever works. This is how all the Prometheus components are auto-published with every git release tag.

@peterbourgon

docker images updated
there is an option to trigger docker builds automatically on github release, but as near as I have managed to figure out, the trigger action and the dockerfile needs to be in the main repository.  I know I was unable to get my repository to trigger automatic builds based on releases from this repository.

Working on this in #75


all-admin-users package

This package should contain:

Handler to Install link (one time creation of join links to all users when package is installed), to make it possible join link should be created to packages user before this package is installed.
Sync handler on User insertion (Join link from that User instance to admin user) should be created.

5000 ₽ can be claimed as a reward. Reward will be paid to the first programmer that will make an NPM package that will pass review of @Konard

Reward was claimed by @Lemeho


feat: scheduler adds filter range limit

Signed-off-by: Gaius<EMAIL_ADDRESS>
Description

Scheduler adds filter range limit.

Related Issue

Motivation and Context

Screenshots (if appropriate)
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.

Codecov Report

Merging #1497 (92b5493) into main (6f0b90c) will decrease coverage by 0.22%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main    #1497      +/-   ##
==========================================
- Coverage   43.50%   43.28%   -0.23%
==========================================
  Files         116      116
  Lines       10675    10681       +6
==========================================
- Hits         4644     4623      -21
- Misses       5550     5579      +29
+ Partials      481      479       -2

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
43.28% <50.00%> (-0.23%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

scheduler/scheduler/scheduler.go
81.29% <50.00%> (-1.94%)
:arrow_down:

client/daemon/peer/peertask_piecetask_poller.go
30.43% <0.00%> (-16.67%)
:arrow_down:

client/daemon/peer/peertask_conductor.go
56.81% <0.00%> (-0.30%)
:arrow_down:

pkg/dag/dag.go
81.37% <0.00%> (ø)

...ent/daemon/peer/peertask_piecetask_synchronizer.go
48.91% <0.00%> (+1.29%)
:arrow_up:


[CM-1612] Restrict Agent messaging after 24 hours inactivity for WhatsApp integration

Summary

Exposed a function to Restrict Agent messaging after 24 hours inactivity for WhatsApp integration.
Also created a function to get Last Received message.

Testing

[x] SPM

Updated the code check the iOS Agent App PR


Retractions from external insertions and retractions are not batched

Currently, when we retract a fact externally, it is removed and then all transitive logical insertions from that fact are immediately retracted. [1, 2]  So, for example, if we have code like the following:
(defrule rule-1
   [?a <- FactA]
   =>
   (insert! (->FactB)))

(defrule rule-2
   [?b-facts <- (acc/all) :from [FactB]]
   =>
   ;; do something)

and do something like
(-> session (insert-all (for [_ (range 10)] (->FactA)))
            fire-rules
            (apply retract (for [_ (range 10)] (->FactA))))

when the retraction occurs, Clara will retract one FactA, retract one FactB, and re-accumulate. This will occur for each FactA that is retracted.  It would be more efficient to retract all the FactA facts at once, then retract all the FactB facts, and then reaccumulate on the FactB condition in rule-2.  This is similar to the approach used when facts are inserted and retracted in a fire-rules call [3, 4].
I've written a prototype of such batching at https://github.com/WilliamParker/clara-rules/commit/115e0673513a55490d0894d97fe45f863807f5e8.  Note that it batches retractions from external insertions as well as retractions.  An external insertion that matches an accumulator condition can cause logical retractions if it changes the accumulated value.  Similarly, an external insertion that matches a negation condition can cause logical retractions for obvious reasons.  These retractions will be immediately fully realized [2].
We have seen a retraction of a fact used in many rules perform poorly that then had performance improve greatly when this batching strategy was used.  It probably merits some more thought before a merge, but right now I don't see much reason to immediately realize everything in external operations and batch operations in the fire-rules loop, and if batching is correct in the latter case it should be correct in the former case as well.

https://github.com/rbrush/clara-rules/blob/0.13.0-RC2/src/main/clojure/clara/rules/engine.cljc#L1515
https://github.com/rbrush/clara-rules/blob/0.13.0-RC2/src/main/clojure/clara/rules/engine.cljc#L296
https://github.com/rbrush/clara-rules/blob/0.13.0-RC2/src/main/clojure/clara/rules/engine.cljc#L1394
https://github.com/rbrush/clara-rules/blob/0.13.0-RC2/src/main/clojure/clara/rules/engine.cljc#L156

+1 the changes make sense to me.
This seems like it has potential for significant performance improvements.  We know we saw a few already with an external retract workflow.

Yep, this makes sense. The only reason this wasn't implemented earlier is that use cases weren't performing retractions very often so it wasn't something I spent time on. I'll be happy to merge a pull req along these lines once one is ready.

Pull request submitted at https://github.com/rbrush/clara-rules/pull/226
It is basically the same as the prototype I linked to previously with a little cleanup of the changes in engine.cljc and some tests added for paths changed by this that I didn't see existing tests for.

I don't see anything left to do here since the PR has been merged.  Closing.


We should not be advocating the use of sudo pip in the README

https://stackoverflow.com/questions/21055859/what-are-the-risks-of-running-sudo-pip/21056000#21056000
This can be dangerous and also install packages with the wrong user/permissions. Either pip was installed incorrectly or they need to use --user.

It's a good idea to start with virtualenv...
Maybe worth a link to... The cheatsheet.
Adding an example for installing Cheat would worth it :
mkdir cheat
virtualenv cheat
cd cheat
./bin/pip install cheat
Run with ./bin/cheat

@shanahanjrs
FYI, I just opened #432, which attempts to resolve multiple installation issues. Along with those changes, I updated the README to advocate the use of the --user flag:
https://github.com/cheat/cheat/pull/432/commits/482161f8e982fc533aabadbb5a6479eb9e794078#diff-04c6e90faac2675aa89e2176d2eec7d8
Does that approach seem sensible?

@chrisallenlane Looks great!

Thanks. This should get merged in soon.


Unable to get disk space usage within a container using Overlay/Overlay2

Output of docker version:
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:28:14 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:28:14 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.1
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge null host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.2.0-30-generic
Operating System: Ubuntu 15.10
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.946 GiB
Name: dockerhub
ID: 3ES5:S6KH:5BYS:6GG2:RFB6:NTOM:O5OE:LL4E:ILKY:NTHC:NBQF:BMUV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: jfusterm
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Ubuntu 15.10 local VM.
Steps to reproduce the issue:

Make sure that Docker uses either Overlay or Overlay2.
Start a new container: $ docker run -it --rm alpine sh
Get the disk usage space within the container: # df -h

Describe the results you received:
I get nothing.
ubuntu1 ➜  ~ docker run -it --rm alpine sh
/ # df -h
Filesystem                Size      Used Available Use% Mounted on
/ # df -i
Filesystem              Inodes      Used Available Use% Mounted on
/ #

There's some applications like Nomad, that need to check the disk usage before starting and it fails every time because it's unable to get it.
It fails with overlay/overlay2. I have tried it with different Docker versions (1.10, 1.11, 1.9) and different distros (CentOS 7, Ubuntu 16.04) and the result is the same.
With AUFS, Devicemapper, BTRFS or ZFS it works.
Describe the results you expected:
Using ZFS.
ubuntu2 ➜  ~ docker run -it --rm alpine sh
/ # df -h
Filesystem                Size      Used Available Use% Mounted on
zroot/docker/da82d6172cbd9b06cd8c6fb395e870f0392499ba4d80d47b0bd1899595625141
                         19.3G      5.5M     19.2G   0% /
tmpfs                     1.9G         0      1.9G   0% /dev
tmpfs                     1.9G         0      1.9G   0% /sys/fs/cgroup
zroot/docker             19.2G    512.0K     19.2G   0% /etc/resolv.conf
zroot/docker             19.2G    512.0K     19.2G   0% /etc/hostname
zroot/docker             19.2G    512.0K     19.2G   0% /etc/hosts
shm                      64.0M         0     64.0M   0% /dev/shm
tmpfs                     1.9G         0      1.9G   0% /proc/kcore
tmpfs                     1.9G         0      1.9G   0% /proc/timer_list
tmpfs                     1.9G         0      1.9G   0% /proc/timer_stats
tmpfs                     1.9G         0      1.9G   0% /proc/sched_debug

/ # df -i
Filesystem              Inodes      Used Available Use% Mounted on
zroot/docker/da82d6172cbd9b06cd8c6fb395e870f0392499ba4d80d47b0bd1899595625141
                      40365206<PHONE_NUMBER>4   0% /
tmpfs                   504747        18    504729   0% /dev
tmpfs                   504747        16    504731   0% /sys/fs/cgroup
zroot/docker          40364804        60  40364744   0% /etc/resolv.conf
zroot/docker          40364804        60  40364744   0% /etc/hostname
zroot/docker          40364804        60  40364744   0% /etc/hosts
shm                     504747         1    504746   0% /dev/shm
tmpfs                   504747        18    504729   0% /proc/kcore
tmpfs                   504747        18    504729   0% /proc/timer_list
tmpfs                   504747        18    504729   0% /proc/timer_stats
tmpfs                   504747        18    504729   0% /proc/sched_debug
/ #

It seems to be an Alpine specific bug, as I get the correct answer both with busybox and debian images.
cc @ncopa

We encountered some similar issues with alpine some time ago. Also the following might be related:
https://github.com/docker-library/official-images/issues/1449

Oh I did file an issue on Alpine previously http://bugs.alpinelinux.org/issues/5703

Thanks Justin for your quick response!
Nothing to worry about, I'll wait until this bug gets fixed in future Alpine releases.

@jfusterm  It is fixed now if you do apk update && apk upgrade, the base image should be updated soon on hub.


Add Codecks to tools section

Codecks is a project management intended for game devs, so it might be a valuable addition to this list :)

Can you tell me the address?
Thanks.

There you go! https://www.codecks.io


[Bug]: File Upload flow causes failures for base64 type

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Uploading files using binary as a stream of data instead of base64 because it causes performance problems and leads to multiple failures. - Reported from client(KB)
Steps To Reproduce

Add a filepicker widget
Upload small and large base64 and binary files
Understand if the data entry and data retrieval process are easy or hard.

Environment
Production
Version
Cloud

Hello,
Indeed, I can't get the base64 content of the files that are picked with the FilePicker...
Hope this bug will be quickly patched ;)
Thanks & Regards,

@j2bd can you tell us a bit about your issue? To which datasource are you trying to upload the file? What is the error you're seeing?

Hi @Nikhil-Nandagopal
With one of my app, filepicker was used to upload files on another webapp by API using base64 content.
Till now, it worked well.
But, I can't get anymore the content of my file as a base64 string via the properties of the widget ( FilePicker1.files[0].data ...)
Thanks for your help,

@j2bd this is a different issue that we were able to resolve so I'm closing it. Can you share the error you're seeing?


Update sns, sso, ssooidc to 2.25.35

About this PR
📦 Updates

software.amazon.awssdk:sns
software.amazon.awssdk:sso
software.amazon.awssdk:ssooidc

from 2.25.31 to 2.25.35
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #33.


feat: add support for PostgreSQL users and databases

What does this fix or implement?

Checklist

[ ] PR name added as appropriate (e.g. feat:/fix:/doc:/test:/refactor:)
[ ] Tests added or updated
[ ] Documentation updated
[ ] Changelog updated and version incremented (label: upcoming release)
[ ] Github Issue linked if any
[ ] Jira task updated

@cristiGuranIonos this is ready for the initial review, please don't mind the TODO comments, they are still in progress. These changes are just functionality-related, no documentation, no tests. After the initial review stage, I'll also write the tests. Thank you!


You DO handle ties now :)

https://github.com/djcunningham0/multielo/blob/440f7922b90ff87009f8283d6491eb0f704e6624/multielo/multielo.py#L18
Hey @djcunningham0, loved the article. I'm implementing this for my friend's Catan games, though I'm trying to do it on Google Sheets -- I do not recommend it. Anyway, I figured I'd look to see how you handle ties and noticed this leftover comment from before v.0.3.0. You DO handle ties now! :)

Ha, good catch! I'll remove that comment next time I push some changes.
By the way, I'm not sure exactly what you mean by implementing it with Google Sheets, but I use Google Sheets to store my group's poker data and then I use this package to calculate Elo ratings. I.e., the results history is stored in the spreadsheet and then I have a web app that reads in the data and calculates the Elo history. The code for the app is in my poker-elo-dashboard repo (the the specific lines for reading the data from Google Sheets are here).
But if instead you mean you're doing all the Elo calculations with formulas in the spreadsheet... good luck to you!

I did mean implementing the Elo calculations/formulas in Google Sheets! Honestly, it wasn't too bad, thanks to your article and this well-documented repo! The spreadsheet took about 5h in total, and I have almost no experience with spreadsheets (thankfully, I'm good enough at Googling things).
If you want to see it, I created a copy here. It's still not finished, but I'm gonna try to do the actual leaderboard tab with graphs and whatnot today.


[Typescript] wrapper does not accept null

According to the recipe in the README, it says to set wrapper to null (https://github.com/probablyup/markdown-to-jsx#other-useful-recipes), but this is currently unsupported in the types.
Please see this codesandbox which shows the error.

Thanks for reporting, open to a PR if you'd like to take a stab at it!


store: bucket: reuse buffers for Series() responses

Reuse the buffers for Series() responses instead of creating separate
buffers for each serialization. Benchmarks show the following numbers:
benchmark                                                                  old ns/op      new ns/op      delta
BenchmarkBucketSeries/1000000SeriesWith1Samples/1of1000000-16              99877102       88749937       -11.14%
BenchmarkBucketSeries/1000000SeriesWith1Samples/10of1000000-16             99204101       90633472       -8.64%
BenchmarkBucketSeries/1000000SeriesWith1Samples/1000000of1000000-16<PHONE_NUMBER><PHONE_NUMBER>     -0.67%
BenchmarkBucketSeries/100000SeriesWith100Samples/1of10000000-16            6905145        6548419        -5.17%
BenchmarkBucketSeries/100000SeriesWith100Samples/100of10000000-16          6826941        6511485        -4.62%
BenchmarkBucketSeries/100000SeriesWith100Samples/10000000of10000000-16     124279560      117056437      -5.81%
BenchmarkBucketSeries/1SeriesWith10000000Samples/1of10000000-16            129306         125762         -2.74%
BenchmarkBucketSeries/1SeriesWith10000000Samples/100of10000000-16          127787         121835         -4.66%
BenchmarkBucketSeries/1SeriesWith10000000Samples/10000000of10000000-16     40783249       34989360       -14.21%

benchmark                                                                  old allocs     new allocs     delta
BenchmarkBucketSeries/1000000SeriesWith1Samples/1of1000000-16              9716           9686           -0.31%
BenchmarkBucketSeries/1000000SeriesWith1Samples/10of1000000-16             9793           9785           -0.08%
BenchmarkBucketSeries/1000000SeriesWith1Samples/1000000of1000000-16        11039980       11040286       +0.00%
BenchmarkBucketSeries/100000SeriesWith100Samples/1of10000000-16            1100           1100           +0.00%
BenchmarkBucketSeries/100000SeriesWith100Samples/100of10000000-16          1135           1138           +0.26%
BenchmarkBucketSeries/100000SeriesWith100Samples/10000000of10000000-16     1104813        1104738        -0.01%
BenchmarkBucketSeries/1SeriesWith10000000Samples/1of10000000-16            200            200            +0.00%
BenchmarkBucketSeries/1SeriesWith10000000Samples/100of10000000-16          200            200            +0.00%
BenchmarkBucketSeries/1SeriesWith10000000Samples/10000000of10000000-16     167478         167481         +0.00%

benchmark                                                                  old bytes      new bytes      delta
BenchmarkBucketSeries/1000000SeriesWith1Samples/1of1000000-16              62057274       62050735       -0.01%
BenchmarkBucketSeries/1000000SeriesWith1Samples/10of1000000-16             62051330       62047650       -0.01%
BenchmarkBucketSeries/1000000SeriesWith1Samples/1000000of1000000-16<PHONE_NUMBER><PHONE_NUMBER>     -5.85%
BenchmarkBucketSeries/100000SeriesWith100Samples/1of10000000-16            4853300        4852006        -0.03%
BenchmarkBucketSeries/100000SeriesWith100Samples/100of10000000-16          4854534        4854798        +0.01%
BenchmarkBucketSeries/100000SeriesWith100Samples/10000000of10000000-16     158506115      126821624      -19.99%
BenchmarkBucketSeries/1SeriesWith10000000Samples/1of10000000-16            213481         212495         -0.46%
BenchmarkBucketSeries/1SeriesWith10000000Samples/100of10000000-16          213365         212681         -0.32%
BenchmarkBucketSeries/1SeriesWith10000000Samples/10000000of10000000-16     115299014      101064549      -12.35%

Performance could be improved even more by memoizing Size() calls
however that is not possible until SeriesResponse becomes an interface
because there are places in the generated code where the three struct
names are hardcoded.
Signed-off-by: Giedrius Statkevičius<EMAIL_ADDRESS>
[x] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes
Made it so that in Series() we would marshal a response to a given buffer. The buffer comes from a sync.Pool.
Verification
Unit/integration tests.

v2 here @bwplotka @yeya24 https://github.com/thanos-io/thanos/pull/4535


RuntimeError: mask_rcnn_fbnetv3g_fpn.yaml not available in Model Zoo!

I have installed according to this installation

but then when I run the d2go_beginner and demo.py
it will have this RuntimeError

please copy d2go\configs* to e:\anaconda3\envs\d2go_22\lib\site-packages\d2go

Hi, I updated the config file location in https://github.com/facebookresearch/d2go/pull/152, it changes the setup.py so you might need to re-install the d2go.

Hi, the issues solved, thank you.

So hard for beginners!
Your need to create soft link to your detectron2 install directory, eg:
ln -s  path_to_my_project/configs/COCO/common/    path_to_detectron2_install_directory/detectron2/detectron2/model_zoo/configs/


Issue when sliding from a long string to a shorter one

When using custom strings with different lengths in popUpView label, if you slide from a long string to a shorter string, the long string remains appearing a bit while target popupview size is already drawn.
It can be seen in your demo project.

Many moons later…
The default is now to not animate the text (currently in development branch - will be merged to master on next release). Creating a mixed solution that would animate by default and temporarily stop animating when the results are glitchy would add code complexity for very little benefit.


Do not replace starting digit with underscore when making identifier

This pull request modifies validate_identifier to add an underscore when the String stars with a digit (instead of replacing the digit with an underscore, which was the old behavior). The validate_identifier test cases has been updated accordingly.
Since validate_identifier is modified, the helper method _is_valid_identifier_bit is not necessary, to remove it is_valid_identifier was also modified to not use it.
Fixes https://github.com/godotengine/godot/issues/82773

I'm a bit worried about the impact this may have on compatibility, notably for the import pipeline. We already broke compat in 4.1 by changing the logic that would remove . from node names, and replaced them instead with _. If this method is used similarly, we could again run into a situation where Godot 4.1 imported scenes will break.
CC @godotengine/import to help assess this.

@akien-mga
If it helps, searching on my end, it seems that validate_identifier (aside from the tests) is only used in:

script_text_editor.cpp on _get_dropped_resource_line and ScriptTextEditor::drop_data_fw, i.e. as result of dropping something in the text editor, and generating source code.
gdscript_editor.cpp on GDScriptLanguage::make_template, i.e. also generating source code.

Thus, it does not provide names for nodes. Modifying it should not affect existing scripts. And as far as I know it is not involved in importing anything.
I also modified is_valid_identifier, however, I believe I didn't change its behavior (its test cases are untouched).
At least, I don't expect issues, but of course I might be mistaken.

Sounds good, thanks for researching it. I expected it to be used way more, but I guess we have other similar methods in Node that partially duplicate this functionality.

Thanks!

Cherry-picked for 4.1.4.


[question] Both the newUri and oldUri properties are mandatory in ResourceFileEdit

monaco-editor version: 0.14.6
Browser: any
OS:  any

Why both the URIs (newUri and oldUri) are mandatory in the ResourceFileEdit?
https://github.com/Microsoft/monaco-editor/blob/daafcb4ce88be8eca9b6303e7624308d7c26d51b/monaco.d.ts#L5380-L5381
When I have to convert the CreateFile,RenameFile, and DeleteFile LSP types to the corresponding ResourceFileEdit monaco type I have to specify both the newUri and the oldUri with "strictNullChecks": true TS compiler options. The current API seems odd to me, and the bulk edit implementation in VS Code is also prepared for falsy URIs. See here.
In theory, I could work around this by setting both the oldUri and the newUri to the same value if the ResourceOperation.kind is either 'create' or 'delete', but then I have no idea whether it was a deletion or a creation.
So I had to apply the following hack to trick the comiler:
asResourceFileEdit(change: CreateFile | RenameFile | DeleteFile): monaco.languages.ResourceFileEdit {
    const { kind, options } = change;
    const oldUri = monaco.Uri.parse(kind === 'rename' ? (change as RenameFile).oldUri : (change as CreateFile | DeleteFile).uri);
    const newUri = monaco.Uri.parse(kind === 'rename' ? (change as RenameFile).newUri : (change as CreateFile | DeleteFile).uri);
    const edit = {
        newUri,
        oldUri,
        options: this.asOptions(options)
    };
    // This is hack. Both the `oldUri` and the `newUri` are mandatory in the `monaco.languages.ResourceFileEdit`.
    if (kind === 'create') {
        delete edit.oldUri;
    } else if (kind === 'delete') {
        delete edit.newUri;
    }
    return edit;
}

Is there a better way to do the LSP type to monaco type conversion?
Thank you!

Any updates on this?


Rename misspelled field

Description
Rename misspelled field
Found this making another change, and it made sense to split off.
Type of change

This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).

/cc @ytimocin


Multiple image viewer

Supersedes #128
In MSiReader, Måns demonstrated an image overlay tool where you can select a number of different ion images to show simultaneously, assign each one a color, scale them, etc.
Andreas raised that he also has a use-case for supporting multiple optical images (full description in comments).
This effectively requires an interface where you can select multiple annotations and optical images, and for each one have individual controls to:

Quickly toggle its visibility
(Annotations only) Toggle visibility of a scalebar
(Up for discussion) Split an RGB optical image into separate R, G and B layers (or allow this to be selected during image upload)
Apply a specific coloration or colorscale
Scale its intensity
Change its opacity
Change its rendering order

Some work will also be needed to determine the best blending mode for the layers, as the premise for #128 is that the current blending mode often produces ugly results.
This also relates to the "High-resolution ion thumbnails" diagnostic. Ideally ion thumbnails would link to the multiple image viewer

This is the explanation of @aeisenbarth 's use case:

There were two projects where this need came up:
A. In the SpaceM revision we had MALDI datasets uploaded by Måns that had a post-MALDI microscopy overlayed and I wanted to overlay another stained microscopy. I had to clone the dataset (including unnecessary reprocessing) for not replacing/removing the existing overlay. In that case, overlays could have *different matrices each. We would need to discuss whether this is important and a recurring need.
B. For SpaceM, the color channels of different stains are visually overloading especially when the MALDI image is overlay on top of them. By uploading the individual channels as multiple (e.g. grayscale) image files (but with same matrix) one could switch to the channel of interest and see only this channel and the MALDI overlay. There could be more than 3 stains, so separate files is simpler than having Metaspace filter a channel out of an RGB file. One could also want to display several channels at a time or assign a specific color to a channel, but that could be done offline in an image editor and then uploading it as a new image. Example with many channels, example with only green channel

Related issue: https://github.com/metaspace2020/metaspace/issues/633

Implemented in #679


fixed redirection to file transport instead of console

The following lines regarding the stdout and stderror
        process.__defineGetter__('stdout', function () {
            return log_stream;
        });
        process.__defineGetter__('stderr', function () {
            return log_stream;
        });

were removed from the event
    log_stream.on('ready', function () {

And issue #4 appears to be fixed without any breaking changes. Was unable to verify with the automated tests however, unit testing looked good.

In a previous stint we relied on this to grab all output from the process, but I've personally moved on to other pastures so I see no problem with adding this change -- anyone who is actually relying on the previous behavior will need to pin to the earlier version.

@demmer makes sense. After all, cases of logs being sent to wrong transport seem far more critical than backwards compatibility with an older version.


ThreeDs lookup error handling

General information

SDK version: 3.82.0
Environment: sandbox
Browser and OS Chrome: 98.0.4758.80 MacOS: 12.1

Issue description
We recently had an issue on our frontend where three-d-secure verifyCard was returning a verify payload with a lookup_error status. As we were not checking this status field, the error was slipping through the cracks on our frontend and not informing anyone.
In the docs, I notice that under the three-d-secure on."lookup_complete") handler, there is a comment that says // check lookup data however, the docs do not tell us how to do this or what potential scenarios to expect. As I said, in our case the issue was a lookup_error which was present in a status field, but this field does not exist in the docs' definition of a ThreeDSecureInfo object.
Ideal Outcomes

either lookup errors or any other status errors cause the verify promise to reject
or the the "status" field, its potential values and an example of how to check for them is added to the docs

Hello @harris-jacob, thanks for writing in; these are some great questions.
Our documentation is vague around the lookup data because that data is returned to us by our third-party MPI provider CardinalCommerce. Additionally, we cannot adjust the promise to reject in these cases because it is possible for a bank to accept the transaction even when these errors occur, so we do not reject these transactions even if 3DS is required.
I hope this has clarified things. I'm going to close this issue for now, but let us know if you have any additional questions.


Failed Build INSTALL_EXIF and INSTALL_PHPREDIS in php-fpm 5.6

hi everyone,
I have a problem whit laradock i can't build my php-fpm 5.6 version because he can't build INSTALL_EXIF and INSTALL_PHPREDIS extension.
error bash is :
Service 'php-fpm' failed to build: One or more build-args [INSTALL_EXIF INSTALL_PHPREDIS] were not consumed, failing build.

can you help me please ?
Thanks

Hi @qZzQ1!
Do you have the latest version of Laradock cloned? Many fixes where implemented yesterday, your issue may already have been fixed.
Make sure to rebuild the containers, like so:
docker-compose up -d --force-recreate --build apache2 mariadb

Feel free to replace apache2 mariadb with the containers you'd like to build, of course.

Yes it's ok, i have solved my issue whit this post :
https://github.com/laradock/laradock/issues/575
I go to rebuild my containers
it's good for me thanks :+1:

Great news! Enjoy Laradock! 👍


Update the contact forces in the case of impact

In the robotDynWithContacts, first the contact forces are computed using the maximum dissipation energy. Then, if an impact is happening, the velocity vector of the robot after the impact is computed. Then, the velocity vector after the impact and the contact forces before the impact are used for the forward dynamics!! But, in case of impact, the contact forces must be updated and the contact forces after the impact is used for the forward kinematic. The simplest point is that in the new contact point, just became in contact through the impact, the contact forces are considered zero!!

C.C. @nunoguedelha  @Giulero @traversaro

As discussed in f2f, probably @VenusPasandi can try to fix this problem and see if it creates problem. If it does not create problems, @VenusPasandi  can create a PR to fix this problem.


[Event Change Request] codeunit 414 "Release Sales Document" - OnBeforeReopenSalesDoc

🕮 Describe the request
Could you please add the parameter SkipWhseRequestOperations  to the event OnBeforeReopenSalesDoc?
procedure Reopen(var SalesHeader: Record "Sales Header")
var
    IsHandled: Boolean;
begin
    IsHandled := false;
    //+Change
    //-OnBeforeReopenSalesDoc(SalesHeader, PreviewMode, IsHandled);
    OnBeforeReopenSalesDoc(SalesHeader, PreviewMode, SkipWhseRequestOperations, IsHandled);
    //-Change
    if IsHandled then
        exit;

   [...]
end;

[IntegrationEvent(false, false)]
//+Change
//-local procedure OnBeforeReopenSalesDoc(var SalesHeader: Record "Sales Header"; PreviewMode: Boolean; var IsHandled: Boolean)
local procedure OnBeforeReopenSalesDoc(var SalesHeader: Record "Sales Header"; PreviewMode: Boolean; SkipWhseRequestOperations: Boolean; var IsHandled: Boolean)
//-Change
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11703.


ingest-service is not logging Elasticsearch 4XX response bodies

Describe the bug
Currently if ElasticSearch is overloaded and is rejecting messages, the only indication that ingest-service gives is that the queue is full. This could be an indication of several different things, and doesn't give a system admin much to go on.
Mar 18 16:00:38 node.example.com hab[1234]: ingest-service.default(O): time="2020-03-18T11:00:38-05:00" level=warning msg="All elasticsearch publishers are full" number_of_publishers=10

However, if you are running compliance scans at the same time, you will see errors similar to this. A 427 error indicating exactly which shard isn't being written to and that it was the was write pool that is overloaded. Indicating that disk I/O isn't keeping up, and in a cluster pointing out exactly which member is failing to keep up.
Mar 18 15:56:49 node.example.com hab[1234]: compliance-service.default(O): time="2020-03-18T10:56:49-05:00" level=error msg="Message failure" error="rpc error: code = Internal desc = InsertInspecReport: elastic: Error 429 (Too Many Requests): rejected execution of processing of [106225694][indices:data/write/bulk[s][p]]: request: BulkShardRequest [[comp-7-r-2020.03.18][0]] containing [index {[comp-7-r-2020.03.18][_doc][12345678-90ab-cdef-0123-abcdef012345], source[n/a, actual length: [163.9kb], max length: 2kb]}], target allocation id:<PHONE_NUMBER>-abcd, primary term: 1 on EsThreadPoolExecutor[name = 64izRMp/write, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@0a1b3c4d[Running, pool size = 8, active threads = 8, queued tasks = 201, completed tasks = 30035248]] [type=es_rejected_execution_exception] InsertInspecSummary: elastic: Error 429 (Too Many Requests): rejected execution of processing of [106225693][indices:data/write/bulk[s][p]]: request: BulkShardRequest [[comp-7-s-2020.03.18][0]] containing [index {[comp-7-s-2020.03.18][_doc][12345678-90ab-cdef-0123-abcdef012345], source[n/a, actual length: [5.6kb], max length: 2kb]}], target allocation id:<PHONE_NUMBER>-abcd, primary term: 1 on EsThreadPoolExecutor[name = 0a1b3c4d/write, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@0a1b3c4d[Running, pool size = 8, active threads = 8, queued tasks = 201, completed tasks = 30035248]] [type=es_rejected_execution_exception]"

To Reproduce
Start chef-load with a mix of compliance and converges.
Use something like bonnie++ to use up all of your disk i/o.
Verify that write rejects are happening
curl localhost:10144/_nodes/stats?pretty | grep -A 4 \"write\"
        "write" : {
          "threads" : 8,
          "queue" : 0,
          "active" : 0,
          "rejected" : 2444,

Check journald logs and verify that only compliance-service is logging 429 errors.
Expected behavior
When receiving a 4XX error code, ingest-service should log the response body similar to how compliance-service behaves.
Additional context
This may be tricky to replicate with standalone A2, reach out to me if you need any further testing or help reproing.

This should be logged at the error level as well.

When the ingest-service logs the message "All elasticsearch publishers are full" ElasticSearch is not rejecting messages the ingest-service's internal queues are full. To increase the internal queues either increase the max number of bundled run messages (max_number_of_bundled_run_msgs) or add more run message publishers (number_of_run_msg_publishers). When the number of max_number_of_bundled_run_msgs is too high the error from Elasticsearch should be message size is too large. If the number_of_run_msg_publishers number is too high the error will be similar to compliance with a "Too Many Requests". I would first increase the number_of_run_msg_publishers until the "All elasticsearch publishers are full" message goes away.
[ingest.v1.sys]
number_of_run_msg_publishers = 7
max_number_of_bundled_run_msgs = 2000


inotify-api implementation only

Proposed changes

Inotify API implementation only. This change was required because our use of the inotify crate duplicated throughout our code base.

in the cumulocity log plugin
in the cumulocity configuation plugin
in the cumulocity mapper (updating operations)

In these three cases: 1. and 2. required a file watch while 3. required a directory watch. The goal of this PR is to propose a new inotify API that is caters for both needs (file or directory watch).
It also tries to be flexible to allow multiple combinations of files and directories to be watched (and hopefully the logic there is bug-free).
After this PR, 3 more PRs will show the implementation of this API for the three cases above. Any changes requested here will spill to those PRs.
Below are some examples on how to use the API.
Creating an instance
To create an instance you can:
use tedge_utils::fs_notify::{NotifyStream, FileEvent, Watch};
use try_traits::default::TryDefault;

let mut fs_notification_stream = NotifyStream::try_default().unwrap();

Adding a directory watch
To add a watch to a directory you would do:
use tedge_utils::fs_notify::{NotifyStream, FileEvent, Watch};
use try_traits::default::TryDefault;

let mut fs_notification = NotifyStream::try_default().unwrap();
let () = fs_notification.add_watcher(
       path,
       Watch::Directory,
       &[FileEvent::Created]
);

Adding a file watch
To add a watch to a file you would do:
use tedge_utils::fs_notify::{NotifyStream, FileEvent, Watch};
use try_traits::default::TryDefault;

let mut fs_notification = NotifyStream::try_default().unwrap();
let () = fs_notification.add_watcher(
       path,
       Watch::File("file_name".to_string()),
       &[FileEvent::Created]
);

How to stream events
use tedge_utils::fs_notify::{NotifyStream, FileEvent, Watch, pin_mut};
use try_traits::default::TryDefault;

let mut fs_notification = NotifyStream::try_default().unwrap();
let () = fs_notification.add_watcher(...);
let fs_notification_stream = fs_notification.stream();
pin_mut!(fs_notification_stream);

while let Some(Ok((path, file_event))) = stream.next().await {
    println!("{}: {:?}", path, file_event);
}

Additionally you can also make use of the fs_notify_stream utility function that creates a NotifyStream::stream() instance:
use tedge_utils::fs_notify::{fs_notify_stream, FileEvent, Watch, pin_mut};
let fs_notification_stream = fs_notify_stream(&[
      (path_1, Watch::File(String::from("file_a")), &[FileEvent::Created]),
      (path_2, Watch::File(String::from("file_b")), &[FileEvent::Modified, FileEvent::Created]),
      (path_3, Watch::Directory, &[FileEvent::Deleted])
     ]
 ).unwrap();
pin_mut!(fs_notification_stream);

while let Some(Ok((path, file_event))) = stream.next().await {
    println!("{}: {:?}", path, file_event);
}

Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

#1173

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[x] I ran cargo fmt as mentioned in CODING_GUIDELINES
[x] I used cargo clippy as mentioned in CODING_GUIDELINES
[x] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

As proposed in a discussion with @PradeepKiruvale and @rina23q, the add_watcher API could be further improved with only two parameters: file or directory path and a slice of FileEvent(s) - leaving the code to decide if the given path is a path to a file or a path to a directory.
let mut fs_notification = NotifyStream::try_default().unwrap();
let () = fs_notification.add_watcher(
       path, &[FileEvent::Created]
);


Feature: Scrolling Progress Bar Addition

Is your feature request related to a problem? Please describe.
Progress bar is missing for scrolling.

Describe the solution you'd like
I want to add a progress bar for scrolling at the top just like GSSOC website

@sanjay-kv please assign label of level to my PR.


Refactor: remove the else statement, try make the code clear.

Remove the else statement, try make the code clear.

There may be many scenes like this. Can you sort out places like this completely

There may be many scenes like this. Can you sort out places like this completely

Good idea, I will modify as suggested.

Codecov Report

Merging #638 (edc4dc5) into master (0749505) will increase coverage by 0.01%.
The diff coverage is 28.57%.

@@             Coverage Diff              @@
##             master     #638      +/-   ##
============================================
+ Coverage     45.36%   45.38%   +0.01%
  Complexity      783      783
============================================
  Files           224      224
  Lines          5341     5341
  Branches        591      591
============================================
+ Hits           2423     2424       +1
+ Misses         2690     2689       -1
  Partials        228      228

Impacted Files
Coverage Δ
Complexity Δ

...omara/soul/admin/controller/AppAuthController.java
12.50% <0.00%> (ø)
1.00 <0.00> (ø)

...in/alibaba/dubbo/cache/ApplicationConfigCache.java
26.92% <0.00%> (ø)
5.00 <0.00> (ø)

...ul/plugin/alibaba/dubbo/param/BodyParamPlugin.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...gin/apache/dubbo/cache/ApplicationConfigCache.java
26.92% <0.00%> (ø)
5.00 <0.00> (ø)

...oul/plugin/apache/dubbo/param/BodyParamPlugin.java
27.58% <0.00%> (ø)
5.00 <0.00> (ø)

.../java/org/dromara/soul/common/utils/JsonUtils.java
75.75% <100.00%> (+2.22%)
3.00 <0.00> (ø)

...va/org/dromara/soul/common/utils/VersionUtils.java
71.42% <100.00%> (+1.05%)
8.00 <0.00> (ø)

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 0749505...edc4dc5. Read the comment docs.


feat(map_loader): show intersection areas

Description
Show intersection area polygon.
related PR: https://github.com/autowarefoundation/autoware_common/pull/211

Tests performed

Psim.
Effects on system behavior

Nothing.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@satoshi-ota Thank you for your PR! Could you tell us who you want to review this?

@satoshi-ota Thank you for your PR! Could you tell us who you want to review this?

@Motsu-san Thanks! Yes, I would like you to review this PR. (On the other hand, I asked @mitsudome-r san to review this in slack.)

@satoshi-ota The following PR is related isn't it?
https://github.com/autowarefoundation/autoware_launch/pull/655

@satoshi-ota The following PR is related isn't it? autowarefoundation/autoware_launch#655

@Motsu-san YES! I'll add link to PR description.

Sorry for my confusing LGTM post, I will approve this after all checks are passed.

FYI, I have merged the dependent PR in autoware_common.

Conflict... :pleading_face: I'll fix it.


Update intro.md

Description
I noticed some small grammatical errors. I just discovered this project and wanted to contribute in some way. I am a technical writer and am browsing through the docs :)

Thanks @aj-emerich!


chore: add incubating notice

Rationale
See https://lists.apache.org/thread/1frk5f146pbzprj0d1ftf15o4z6v3ocs
Detailed Changes
Test Plan
No need

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


New version: Overmind.OvermindCLI 1.0.12

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Automated with GoReleaser
Microsoft Reviewers: Open in CodeFlow

/azp run

https://github.com/microsoft/winget-pkgs/issues/142854


Use pub(crate)

I've never seen pub(in crate) before, so I could definitely be wrong about this, but I think it's equivalent to pub(crate).
This was done with sed -i 's/pub(in crate)/pub(crate)/g' **/*.rs.

Thanks! I've been meaning to do that, but forgot about it. Ya, they're the same. I just didn't know you could drop the in at first.
Can you run rustfmt and force push?

Done!

Merged. Thanks!


xxx Jd 2022 07 15 unittests globalz

Codecov Report

Merging #617 (bf26d6b) into main (aa4f959) will increase coverage by 2.30%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main     #617      +/-   ##
==========================================
+ Coverage   23.77%   26.08%   +2.30%
==========================================
  Files         117      129      +12
  Lines       28966    31494    +2528
  Branches     4711     5054     +343
==========================================
+ Hits         6886     8214    +1328
- Misses      21157    22208    +1051
- Partials      923     1072     +149

Flag
Coverage Δ

unittests
26.08% <75.00%> (+2.30%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

tests/c_unittests/helpers.hpp
96.47% <ø> (ø)

tests/c_unittests/helpers.cpp
90.90% <75.00%> (ø)

tests/c_unittests/test_router_startup.cpp
100.00% <0.00%> (ø)

tests/c_unittests/test_listener_startup.cpp
100.00% <0.00%> (ø)

tests/c_unittests/test_amqp.cpp
100.00% <0.00%> (ø)

tests/c_unittests/c_unittests_main.cpp
52.38% <0.00%> (ø)

tests/c_unittests/test_terminus.cpp
100.00% <0.00%> (ø)

tests/c_unittests/qdr_stubbing_probe.cpp
100.00% <0.00%> (ø)

... and 18 more

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 aa4f959...bf26d6b. Read the comment docs.


replace types verification by isinstance(x, type).

In order to be able to run it on python 3.6 (so probably also previous versions), I replaced checks done using "types" library by a check by isinstance(X, int/float). I've done some trials and checks are still done properly.

Thanks for the contribution! I added automated testing for future PRs - testing in python 2 and 3

You are welcome :) Thank you for your code ! I completely forgot to run
tests.py >_>'
2018-03-31 16:05 GMT+02:00 btaba<EMAIL_ADDRESS>
Thanks for the contribution! I added automated testing for future PRs -
testing in python 2 and 3
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/btaba/sinkhorn_knopp/pull/1#issuecomment-377695414,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIynCjj4PzmYZWTHN3qPOE_jQ8Yl6kSRks5tj41AgaJpZM4TCbvR
.


Hi, i just wanna ask with you about get all data in query builder?

Can you explain with your code in:
https://github.com/GuilhermeSousaDev/QueryBuilderTypeorm/blob/main/src/controllers/PostController.ts
part of get index.
this is very difference about documentation:
https://typeorm.io/select-query-builder

Hi Andi, sorry for the delay in giving an answer, in this part of the
index, if you're talking about the commented code, actually this is
not exclusive to QueryBuilder, typeorm supports writing queries in SQL
language with this command, .query()
Example: getRepository(Post).query('SELECT * FROM posts');
Hope this helps :)

Thanks a lot for answer my question dude.
Really clear about it.