text:
Two scrollbars visible when catalog content too long for the page

@serenamarie125 @beanh66 @cshinn  @jwforres Wanted to get your opinion on this. The double scrollbars feel awkward to me.

@spadgett Agreed it feels awkward and seems hard to use. I am wondering if the whole page should scroll to see more catalog items, rather than just the subcategory section. What are your thoughts?

We put a max height on the subcategory section in case a tab wrapped below so it would be visible, although I think in many cases it will still be off the page. It was mostly a problem when we were showing the subcategories still for "All," and I know we're working a different design for mobile.

I am wondering if the whole page should scroll to see more catalog items, rather than just the subcategory section. What are your thoughts?

I agree.

@spadgett I remember the conversations around the tabs and why we thought scrolling within a subcategory would make sense, but after interacting with it, I don't know that the separate scroll bar solves that problem and it may create another issue with usability. I am getting feedback on the tabbed structure at summit, including how they wrap and scroll 👍

@spadgett I think we should remove the inner scroll.  I think scrolling in general has changed since our initial design.  I agree that the inner scroll is an issue.
That being said, it would be great if we could restyle the outer scroll so it blends in a bit more - maybe if the background was closer in color to our project panel background or something.

Thanks @serenamarie125 and @beanh66
@rhamilto volunteered to look at this, including restyling the scrollbar

Excellent, thanks @rhamilto @spadgett

repo: openshift/origin-web-catalog


text:
HOSTEDCP-1412 | chore: updates for golang 1.21

HOSTEDCP-1412 | chore: *: go mod tidy with 1.21
Signed-off-by: Steve Kuznetsov skuznets@redhat.com

HOSTEDCP-1412 | chore: updates for golang 1.21
Signed-off-by: Steve Kuznetsov skuznets@redhat.com

/approve

/retitle OCM-5935 | chore: updates for golang 1.21

/lgtm

source: gharchive/pull-request

authors: gdbranco stevekuznetsov

repo: openshift/rosa

license_type: permissive

license_source: github-api


text:
OCM-8329 | fix: add password validator for create admin

https://issues.redhat.com/browse/OCM-8329

/lgtm


text:
Upgrade cluster - manual mode - prompt the aws operator role upgrade commands

Related: SDA-6744

@pvasant @zgalor @ydayagi PTAL
The upgrade account roles command is prompted from the upgrade cluster.
If we exit in upgrade operator roles instead of returning to the upgrade cluster,
we miss the call to upgrade operator roles.

/lgtm
/approve

authors: oriAdler ydayagi


text:
Error saving federation in keycloak dockerized

The server is running and the same configuration of singular-db-provider into other instalation (not dockerized) works well.
2022-11-28 14:52:09,103 ERROR [com.zaxxer.hikari.pool.HikariPool] (executor-thread-38) SINGULAR-USER-PROVIDER-singular-db-user-provider28-11-2022 14:51:32 - Exception during pool initialization.: java.sql.SQLException: Login timed out
Thanks

Sorry, resolved!
SQLSERVER Firewall problem

source: gharchive/issue


text:
Hasura configurations continuously deployed

Describe the feature you'd like to request
Right now, anytime the schema changes, we need to manually configure Hasura to resync the schema, and setup access control.
Describe the solution you'd like
It'd be nice if this was continuously deployed anytime we make changes.
I think there is a Hasura terraform provider, but not sure if that suits this purpose
Describe alternatives you've considered
Keep manually configuring

@ravenac95
Notes from today. We should try to use the Hasura CLI metadata migrations
https://hasura.io/docs/latest/migrations-metadata-seeds/manage-metadata/

From @ravenac95
find dbt/models/marts/ -name "*.sql" -type f -exec sh -c 'basename $0 .sql' {} \; | xargs -n1 xargs -0 printf "bq_%s\n"

https://hasura.io/docs/latest/migrations-metadata-seeds/migrations-metadata-setup/
https://hasura.io/docs/latest/cloud-ci-cd/github-integration/#initial-setup
https://hasura.io/docs/latest/migrations-metadata-seeds/metadata-format/#tablesyaml

Here's a start to the metadata config
https://github.com/opensource-observer/oso/pull/851
Remaining things:

Auto-generated tables based on the dbt models
GitHub action to deploy on merge to main
Auth hooks for checking API keys
API rate limits based on your role

Auto-generated tables here via a script
https://github.com/opensource-observer/oso/pull/861

GitHub workflow here
https://github.com/opensource-observer/oso/pull/869

authors: ryscheng ryscheng-mobile

repo: opensource-observer/oso


text:
Add a Gitter chat badge to README.md

opensourcecities/montreal now has a Chat Room on Gitter
@ruyadorno has just created a chat room. You can visit it here: https://gitter.im/opensourcemontreal/Lobby.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Yeah!

authors: RichardLitt gitter-badger

repo: opensourcecities/montreal

license: Unlicense


text:
Connect with polkadot.js extensioin/subwallet/talisman, and support nova wallet.

[x] Add connect button to header menu bar
[x] Implement extension selector
[x] Implement address selector
[x] Make sure correctly handling ETH accounts
[ ] Add Nova extension support
[ ] Logout (@Popoulosss )
[ ] Loading effect (@Popoulosss )

Figma link
Preview

Files
dot-loading-grey.svg.zip

authors: Popoulosss hyifeng

repo: opensquare-network/dotreasury


text:
Fix issue #1882 , Generate a Unique random number of length 6

Add function to generate a unique number of length 6
Add tests to confirm the length of the generated number is 6

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #1882
Checklist

[x] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[x] I have added any strings visible on UI components to the strings.xml file
[x] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[x] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

Can we use a verifiable number generator based on existing algorithms that can be validated?

For future work, it feels like we have a somewhat arbitrary set of functions in the RuleFactory class, am I missing some pattern or should we reorganize these at some point?

For future work, it feels like we have a somewhat arbitrary set of functions in the RuleFactory class, am I missing some pattern or should we reorganize these at some point?

We will reorganize the functions in future.

@pld @ellykits I have created an extension file just incase some functions are shared or you want to move the logic there.

@pld @ellykits I have created an extension file just incase some functions are shared or you want to move the logic there.

Thanks, let's wait until we thought through the structure before we create this file, I've removed it for now

@pld kdocs added.

authors: SebaMutuku ellykits pld

repo: opensrp/fhircore


text:
ENGINE in OPENSSL

What is the concept of an engine in the context of OPENSSL?
What are its specific use cases?

You can read a great deal of information about ENGINEs in the project documentation : https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/doc/man3/ENGINE_add.pod
Consider that the current development of the next major release of OpenSSL is moving that concept even further, into a new architecture based on "providers".
You can read more about the design of the upcoming 3.0.0 release at: https://www.openssl.org/docs/OpenSSL300Design.html
In 3.0.0 ENGINEs will be deprecated in favor of providers, but there should still be at least limited support for the existing ENGINE API.
Another great source of info about differences between previous release and the upcoming 3.0.0 can be found in the wiki: https://wiki.openssl.org/index.php/OpenSSL_3.0

The links you shared were of great help.
Btw, how do i list the supported engines on my hardware?

The links you shared were of great help.
So, as far as i understand it OpenSSL has built-in support for cryptographic acceleration using the ENGINE object type. if i have a hardware device with a super fast implementation of ECDSA, then i can set the engine to that hardware device (instead of NULL), which means that the operations are now computed by the hardware device instead of the default OpenSSL software layer. Am i correct?

Yes, ENGINEs were originally designed exactly for supporting hw implementations, but their flexibility allowed them to be generally used as "bags" of alternative or new implementations, even in software.
E.g. the GOST engine is comprised of software implementations that enrich the capabilities of libcrypto by allowing users to dinamically load support for cryptographic algorithms mandated by the Russian government.
In other cases they have been used as research tools to, e.g., test and validate alternative implementations of already supported algorithms.

Also, the implementations of the engines are done by specific hardware vendors and later, depending on the need, the application needs to load it dynamically?

Depending on the version, OpenSSL has historically provided a set of built-in engines, some of which are built statically into the library at compile-time and others result in "dynamic" engines that are loadable at run-time.
The details of how an application can make use of a specific set of dynamic engines depend on a few factors.
In general the recommended way is to edit the system-wide or application-specific OpenSSL config file, so that it has an "engines" section to provide all the information necessary to load the desired set of functionality.
Applications that always fully initialize libcrypto by loading the config file don't need any further change, and enabling or disabling this or that engine is completely transparent.
Unfortunately, up to 1.1.1, while applications linking against libssl are always required to fully load the config file, applications that only link against libcrypto are not strictly required to load the configuration file, so your mileage about transparent ENGINE support in libcrypto-only applications might vary: some of these applications might need to either be modified to properly load the config file on init or to explicitly try to load an engine programmatically.
Beware that the upcoming 3.0 release will introduce the concept of providers, that will supersede the ENGINEs. While the ENGINE API will still be supported, it will be considered legacy, deprecated, and there might be usability issues in trying to use advanced features of the provider architecture and legacy ENGINEs at the same time.

Btw, how do i list the supported engines on my hardware?

https://www.openssl.org/docs/man1.1.1/man1/engine.html

Btw, how do i list the supported engines on my hardware?

I should probably expand a little bit more about this, but the previous comment was already quite long.
Anyway: as mentioned before the openssl engine CLI tool can be used to inspect engine objects and capabilities.
On my Ubuntu 18.04.4 LTS development machine, using the distribution installation of OpenSSL, I can observe the following:
; openssl engine -t -c -vvvv
(rdrand) Intel RDRAND engine
 [RAND]
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]
     SO_PATH: Specifies the path to the new ENGINE shared library
          (input flags): STRING
     NO_VCHECK: Specifies to continue even if version checking fails (boolean)
          (input flags): NUMERIC
     ID: Specifies an ENGINE id name for loading
          (input flags): STRING
     LIST_ADD: Whether to add a loaded ENGINE to the internal list (0=no,1=yes,2=mandatory)
          (input flags): NUMERIC
     DIR_LOAD: Specifies whether to load from 'DIR_ADD' directories (0=no,1=yes,2=mandatory)
          (input flags): NUMERIC
     DIR_ADD: Adds a directory from which ENGINEs can be loaded
          (input flags): STRING
     LOAD: Load up the ENGINE specified by other settings
          (input flags): NO_INPUT

I am using the default configuration provided by the distribution maintainers here, which is not loading any extra dynamic ENGINE, while the openssl CLI apps all try to enable all available builtin engines.
The two engines listed are two built-in static ENGINEs compiled inside my libcrypto:

rdrand provides optional support for Intel RDRAND
dynamic is the static engine that allows libcrypto to load dynamic engines

To check what other dynamic engines are available in my system:
; openssl version -a
OpenSSL 1.1.1  11 Sep 2018
built on: Tue Nov 12 16:58:35 2019 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-kxN_24/openssl-1.1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific
; openssl version -a |grep ENGINESDIR
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
; ls /usr/lib/x86_64-linux-gnu/engines-1.1
afalg.so  capi.so  padlock.so

In the default system-wide ENGINE directory I have three engines available. For each of them we could use the openssl engine CLI to try to load them and get more information.
; openssl engine -vvvv -c -tt afalg
(afalg) AFALG engine support
 [AES-128-CBC, AES-192-CBC, AES-256-CBC]
     [ available ]
; openssl engine -vvvv -c -tt capi
140255949046208:error:260B606D:engine routines:dynamic_load:init failed:../crypto/engine/eng_dyn.c:485:
140255949046208:error:2606A074:engine routines:ENGINE_by_id:no such engine:../crypto/engine/eng_list.c:335:id=capi
; openssl engine -vvvv -c -tt padlock
140358876758464:error:260B606D:engine routines:dynamic_load:init failed:../crypto/engine/eng_dyn.c:485:
140358876758464:error:2606A074:engine routines:ENGINE_by_id:no such engine:../crypto/engine/eng_list.c:335:id=padlock

Apparently the afalg ENGINE is the only one that successfully loads: it is meant to support (part of) the Linux Kernel AF_ALG userspace Crypto API (requires Linux >= 4.1.0).
The capi engine should provide support for the Microsoft CryptoAPI, while padlock should support the VIA PadLock Instruction Set on supported VIA CPUs.
3rd party engines can be installed in the default location or somewhere else, depending on the openssl config file and on the use of the OPENSSL_ENGINES env var.
; OPENSSL_ENGINES=/tmp openssl engine -vvvv -c -tt afalg
140552048570816:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:../crypto/dso/dso_dlfcn.c:117:filename(/tmp/afalg.so): /tmp/afalg.so: cannot open shared object file: No such file or directory
140552048570816:error:25070067:DSO support routines:DSO_load:could not load the shared library:../crypto/dso/dso_lib.c:162:
140552048570816:error:260B6084:engine routines:dynamic_load:dso not found:../crypto/engine/eng_dyn.c:414:
140552048570816:error:2606A074:engine routines:ENGINE_by_id:no such engine:../crypto/engine/eng_list.c:335:id=afalg

Thanks for your prompt replies.
This information was really helpful so as to connect the dots.

authors: romen saddy-muchu

repo: openssl/openssl


text:
openssl req: Interactively specify subjectAltName (SAN)

Firefox & Chrome now require the subjectAltName (SAN) X.509 extension for certificates.
Please provide a way to specify the SAN interactively (along the CN) when generating certs & reqs using the openssl command line tool (openssl req).
Currently one has to do some ugly trickery to generate a self-signed certificate:
openssl req -new -key private.key -sha256 -nodes -x509 -days 365 -out public.crt \
    -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" \
    -reqexts SAN \
    -extensions SAN \
    -config <(cat /etc/ssl/openssl.cnf \
              <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))

EDIT:
By "interactively" I mean asking for the SAN when running openssl req (without a -subj):
$ openssl req ..
[ .. ]
Common Name (eg, fully qualified host name) []: mydomain.com
Subject Alternative Name (eg, list of host names) []: mydomain.com,www.mydomain.com
[ .. ]

A PR would help expedite this.
You can also use the $ENV construct in your config file and set the SAN field in the environment.

My assumption is there are two separate requirements here:

Copy the CN value to the default SAN DNS value, and
Additionally capture a list of additional SANs, appending these to the default SAN.

If I've understood the requirement correctly? Is part 1. partially addressed by PR #341?

@richsalz the $ENV approach adds unnecessary complexity and also makes the scripts harder to be cross-platform. Plus it still requires even having a .conf file ...

Sure, it's sub-optimal.  See the other part of my comment :)

Is this "true"? https://certsimple.com/blog/openssl-csr-command
These guys say that I can use -subj '/CN=example.com/subjectAltName=DNS.1=example.com, DNS.2=www.example.com but I can't seem to get such syntax working on version 1.1.0g on Debian Stretch.

@JamesTheAwesomeDude, I would say that's possible if the signing CA knows to pick out subjectAltName from the csr's subject and make an extension of it. I don't know any CA that does this, though...

Yeah, it doesn't create the appropriate "Subject Alternative Name" field, it just adds it to the "Subject" field, which isn't where it should be.

Many commercial CA's add the CN field to the SAN extension, but not all.  And as others pointed out, it is not added to the CSR.

Just wanted to say thanks so much for bfa470a4f64313651a35571883e235d3335054eb and resolving this Issue
Looking forward intensely to its inclusion in Debian. This will make manual CSR generation so much less painful!

authors: JamesTheAwesomeDude leonklingele levitte milosivanovic richsalz sidshetye tedescn


text:
NIST curve P-256 (optimized implementation) signed integer overflow

Compile OpenSSL 1.1.0g:
CC=clang ./config enable-ec_nistp_64_gcc_128 enable-ubsan && make -j4

#include <openssl/ec.h>
#define ABORT abort();
struct nistp_test_params {
    const EC_METHOD *(*meth) ();
    int degree;
    /*
     * Qx, Qy and D are taken from
     * http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/ECDSA_Prime.pdf
     * Otherwise, values are standard curve parameters from FIPS 180-3
     */
    const char *p, *a, *b, *Qx, *Qy, *Gx, *Gy, *order;
};

static const struct nistp_test_params params = {
     /* P-256 */
     EC_GFp_nistp256_method,
     256,
     /* p */
     "ffffffff00000001000000000000000000000000ffffffffffffffffffffffff",
     /* a */
     "ffffffff00000001000000000000000000000000fffffffffffffffffffffffc",
     /* b */
     "5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b",
     /* Qx */
     "b7e08afdfe94bad3f1dc8c734798ba1c62b3a0ad1e9ea2a38201cd0889bc7a19",
     /* Qy */
     "3603f747959dbf7a4bb226e41928729063adc7ae43529e61b563bbc606cc5e09",
     /* Gx */
     "6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296",
     /* Gy */
     "4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5",
     /* order */
     "ffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551",
};

static void nistp_single_test(const struct nistp_test_params *test)
{
    BN_CTX *ctx;
    BIGNUM *p, *a, *b, *x, *y, *n, *m, *order, *yplusone;
    EC_GROUP *NISTP;
    EC_POINT *G, *P, *Q, *Q_CHECK;

    ctx = BN_CTX_new();
    p = BN_new();
    a = BN_new();
    b = BN_new();
    x = BN_new();
    y = BN_new();
    m = BN_new();
    n = BN_new();
    order = BN_new();
    yplusone = BN_new();

    NISTP = EC_GROUP_new(test->meth());
    if (!NISTP)
        ABORT;
    if (!BN_hex2bn(&p, test->p))
        ABORT;
    if (1 != BN_is_prime_ex(p, BN_prime_checks, ctx, NULL))
        ABORT;
    if (!BN_hex2bn(&a, test->a))
        ABORT;
    if (!BN_hex2bn(&b, test->b))
        ABORT;
    if (!EC_GROUP_set_curve_GFp(NISTP, p, a, b, ctx))
        ABORT;
    G = EC_POINT_new(NISTP);
    P = EC_POINT_new(NISTP);
    Q = EC_POINT_new(NISTP);
    Q_CHECK = EC_POINT_new(NISTP);
    if (!BN_hex2bn(&x, test->Qx))
        ABORT;
    if (!BN_hex2bn(&y, test->Qy))
        ABORT;
    if (!BN_add(yplusone, y, BN_value_one()))
        ABORT;
    /*
     * When (x, y) is on the curve, (x, y + 1) is, as it happens, not,
     * and therefore setting the coordinates should fail.
     */
    if (EC_POINT_set_affine_coordinates_GFp(NISTP, Q_CHECK, x, yplusone, ctx))
        ABORT;
    if (!EC_POINT_set_affine_coordinates_GFp(NISTP, Q_CHECK, x, y, ctx))
        ABORT;
    if (!BN_hex2bn(&x, test->Gx))
        ABORT;
    if (!BN_hex2bn(&y, test->Gy))
        ABORT;
    if (!EC_POINT_set_affine_coordinates_GFp(NISTP, G, x, y, ctx))
        ABORT;
    if (!BN_hex2bn(&order, test->order))
        ABORT;
    if (!EC_GROUP_set_generator(NISTP, G, order, BN_value_one()))
        ABORT;

    if (EC_GROUP_get_degree(NISTP) != test->degree)
        ABORT;

    if (!BN_hex2bn(&n, "f1fccaceddcb0addab0bdfcdadfbbae01bbbbdfe0afeaa1acfcfdead1feafb0e"))
        ABORT;
    /* fixed point multiplication */
    EC_POINT_mul(NISTP, Q, n, NULL, NULL, ctx);
    EC_GROUP_free(NISTP);
    EC_POINT_free(G);
    EC_POINT_free(P);
    EC_POINT_free(Q);
    EC_POINT_free(Q_CHECK);
    BN_free(n);
    BN_free(m);
    BN_free(p);
    BN_free(a);
    BN_free(b);
    BN_free(x);
    BN_free(y);
    BN_free(order);
    BN_free(yplusone);
    BN_CTX_free(ctx);
}
int main(void)
{
    nistp_single_test(&params);
    return 0;
}

$ clang -fsanitize=undefined -Iinclude x.c libcrypto.a
$ ./a.out
crypto/ec/ecp_nistp256.c:440:10: runtime error: left shift of 1 by 63 places cannot be represented in type 's64' (aka 'long')

There is one thing to keep in mind about ecp_nistp modules, all three of them. They are not strictly language standard compliant. In other words they are written with certain assumptions about what processor can and how does it do certain things. For example they work only on little-endian processors that tolerate unaligned load. And this particular sanitize failure seems to be of same nature. I.e. code is written under assumption that shift into sign bit works "normally" even though it's not defined by language standard. In other words above failure is not really a problem. This doesn't mean that problem won't be addressed, it just needs closer assessment. I mean it's not sufficient to address problem at this specific line, one has to look around.
In the context a word of warning. Suggested configuration line will fail more sanitizer tests. For reasons mentioned above, non-compliance with letter of the standard. And it's known and expected. Or rather most are known and expected.

Thanks. In addition to the specifics of the underlying processor, another thing to reckon with is that an optimizing compiler may, per the C spec, make certain assumptions about the code, and as a consequence produce code with different behaviour across different optimization levels.
Here's an interesting example of this:
#include <stdlib.h>
#include <stdio.h>
void
mm_memvalid(void *address, size_t size)
{
    void *end = (char *)address + size;

    if (end < address) {
        printf("mm_memvalid: end < address: %p < %p\n", end, address);
    }
}

int main(int argc, char** argv)
{
    char* x = (char*)0xC0000000;
    char* endptr;
    long l;

    if ( argc < 2 ) { return 0; }

    l = strtol(argv[1], &endptr, 16);
    if ( l < 0 ) { return 0; }
    mm_memvalid(x, l);

    return 0;
}

$ clang -m32 mm_memvalid.c ; ./a.out 0xFFFFFFFF
mm_memvalid: end < address: 0x3fffffff < 0xc0000000
$ clang -O1 -m32 mm_memvalid.c ; ./a.out 0xFFFFFFFF
$

Now this example involves pointer arithmetic rather than signed integer overshift, but the upshot is that care must be taken in making assumptions about the effective behaviour of non-conforming code. Also remember that behaviour may vary across different compilers. This is a very interesting paper on this matter: https://pdos.csail.mit.edu/papers/stack:sosp13.pdf

This is cool stuff, thanks!  But if the compiler generates code we're not expecting, our test suite should fail, right?

Currently it does not (according to UBSAN), presumably because it is shifting a zero, so
 438     high = tmp[3] >> 64;
 439     /* As tmp[3] < 2^65, high is either 1 or 0 */
 440     high <<= 63;
 441     high >>= 63;

is effectively
high = 0;
high <<= 63;
high >>= 63;

so there is no risk that the sign bit of the signed integer is set via the shift.
But you can add this to nistp_tests_params[] in test/ectest.c:
    {
     /* P-256 */
     EC_GFp_nistp256_method,
     256,
     /* p */
     "ffffffff00000001000000000000000000000000ffffffffffffffffffffffff",
     /* a */
     "ffffffff00000001000000000000000000000000fffffffffffffffffffffffc",
     /* b */
     "5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b",
     /* Qx */
     "b7e08afdfe94bad3f1dc8c734798ba1c62b3a0ad1e9ea2a38201cd0889bc7a19",
     /* Qy */
     "3603f747959dbf7a4bb226e41928729063adc7ae43529e61b563bbc606cc5e09",
     /* Gx */
     "6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296",
     /* Gy */
     "4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5",
     /* order */
     "ffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551",
     /* d */
     "f1fccaceddcb0addab0bdfcdadfbbae01bbbbdfe0afeaa1acfcfdead1feafb0e",
     },

and the overshift will be triggered.
Still, the only way to be guaranteed of a correct operation on all platforms and compilers is to adjust the code to be spec-compliant.
While this is very hypothetical, one corner case I can think of is that if the compiler inlines several copies of felem_shrink() (in which the offending shift occurs) with different machine code bodies, then this new test might pass, while there are still code paths + input variables that might produce invalid results.
I'm not sure exactly why a compiler would do that, but the compiler having the agency to create any code it wants, no assumptions should be taken as guarantees..

A word of clarification. "above failure is not really a problem" as long as compiler generates said instructions. And it does. Example with pointer arithmetic has no bearing here, because it's not something compiler can judge at compile time. But of course one one shouldn't count on that. And nobody said that we will, see #4974.
Just in case. One can add the suggested test vector, because it doesn't pass EC_POINT_is_on_curve test, so that test is bound to fail. It works as trigger for specific problem, but not as oracle for compiler mischief.

Fix is merged. Thanks for report.

authors: dot-asm guidovranken richsalz


text:
1.1.0h - compile warnings with MinGW & gcc 7.3.0

1.1.0h built & passed all tests, which is typical.
I build & test Ruby trunk (head/master), and when MinGW changed to gcc 7.x, there were quite a few compiler warnings.
If the info is helpful, I can attached all of them...
Thanks, Greg

If they are about size and/or unsigned things, I don't think they're of interest now.  But if there are other warnings, it would be nice to see them.

I forgot to mention that I'm not really a c type.  I can read it and get a general idea...
Forgot to mention that Ruby digest and openssl built also without failures using the 1.1.0h dll's.
Attached is my attempt at cleaning the log of everything not related to the warnings....
mingw-w64-openssl-1.1.0.h-1-x86_64-build_warnings.log
Thanks for your work.

Thank you!  Perhaps @mspncp wants to take a look, but my initial reaction is that most of these are fixed in master, and the others are mostly-harmless noise warnings.

Thank you.  Maybe this weekend I'll try and build 1.1.1.  Standard MSYS2/MinGW is currently using 1.0.2.

@richsalz, I'm not sure why you picked me as candidate for looking at mingw-w64-openssl-1.1.0.h-1-x86_64-build_warnings.log? We don't use mingw to build OpenSSL on Windows.
Regarding the BIO_PRI64 format string warnings, @dot-asm might be the right consultant, see 70b9063cd24904fd3d0b83173c51fdcf34085967.
As for the setsockopt() warning: I know that the warnings occur because Microsoft declares optval non-posix-ly as const char * instead of const void *, see setsockopt() on MSDN. Also, I stumbled over an interesting ten year old thread about setsockopt on mingw on bug-gnulib started by Simon Josefsson (@jas4711?). Maybe he can tell us what happened to his patches that attempted to fix this issue?
../openssl-1.1.0h/crypto/bio/b_sock2.c:90:56: warning: passing argument 4 of 'setsockopt' from incompatible pointer type [-Wincompatible-pointer-types]
         if (setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) != 0) {
                                                        ^

In file included from ../openssl-1.1.0h/e_os.h:199:0,
                 from ../openssl-1.1.0h/crypto/bio/bio_lcl.h:11,
                 from ../openssl-1.1.0h/crypto/bio/b_sock2.c:14:
E:/msys64/mingw64/x86_64-w64-mingw32/include/winsock2.h:999:34: note: expected 'const char *' but argument is of type 'int *'
   WINSOCK_API_LINKAGE int WSAAPI setsockopt(SOCKET s,int level,int optname,const char *optval,int optlen);
                                  ^~~~~~~~~~

I think the warnings about "ll" formatting are because BIO_printf
is actually using gnu format strings, IOW %lld does not work with msvcrt
only %I64d does but the format attribute indicates system default runtime.
You could try to change the attribute on BIO_printf to something like this:
diff --git a/include/openssl/bio.h b/include/openssl/bio.h
index f435bd8..337ecc0 100644
--- a/include/openssl/bio.h
+++ b/include/openssl/bio.h
@@ -718,13 +718,13 @@ void BIO_copy_next_retry(BIO *b);
 #  define __bio_h__attr__(x)
 # endif
 int BIO_printf(BIO *bio, const char *format, ...)
-__bio_h__attr__((__format__(__printf__, 2, 3)));
+__bio_h__attr__((__format__(__gnu_printf__, 2, 3)));
 int BIO_vprintf(BIO *bio, const char *format, va_list args)
-__bio_h__attr__((__format__(__printf__, 2, 0)));
+__bio_h__attr__((__format__(__gnu_printf__, 2, 0)));
 int BIO_snprintf(char *buf, size_t n, const char *format, ...)
-__bio_h__attr__((__format__(__printf__, 3, 4)));
+__bio_h__attr__((__format__(__gnu_printf__, 3, 4)));
 int BIO_vsnprintf(char *buf, size_t n, const char *format, va_list args)
-__bio_h__attr__((__format__(__printf__, 3, 0)));
+__bio_h__attr__((__format__(__gnu_printf__, 3, 0)));
 # undef __bio_h__attr__

Because, sadly, as a dumb American I picked the wrong German.  Sorry to both Bernd and Matthias.

I don't have access to a mingw system but I can come up with a PR if someone
is willing to try out if the above patch improves the situation...

@bernd-edlinger @richsalz
Thank you for the work.  Below are the differences in the build logs:
Build Log Search Results 1.1.0h
before & after patch

before  after  search regex
  14      0    BIO_[a-z]*printf
  35     18    : warning:

Below is the list of remaining warnings:
warning: overflow in implicit constant conversion [-Woverflow]
crypto/bio/b_sock.c:211:13
crypto/bio/b_sock.c:216:16
crypto/bio/b_sock.c:219:16
crypto/bio/b_sock.c:226:13
crypto/bio/b_sock.c:233:13
crypto/bio/b_sock2.c:45:16
crypto/bio/b_sock2.c:51:16

warning: passing argument 4 of 'setsockopt' from incompatible pointer type [-Wincompatible-pointer-types]
crypto/bio/b_sock2.c:90:56
crypto/bio/b_sock2.c:98:56
crypto/bio/b_sock2.c:164:47
crypto/bio/b_sock2.c:189:56
crypto/bio/b_sock2.c:197:56
crypto/bio/b_sock2.c:211:57

warning: overflow in implicit constant conversion [-Woverflow]
crypto/bio/b_sock2.c:256:16
crypto/bio/b_sock2.c:261:16

warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
crypto/engine/eng_list.c:346:22

warning: passing argument 1 of '_InterlockedExchangeAdd' from incompatible pointer type [-Wincompatible-pointer-types]
crypto/threads_win.c:132:35

warning: overflow in implicit constant conversion [-Woverflow]
apps/s_socket.c:92:21

Please feel free to ping me re MinGW builds.
Thanks again, Greg

Closing as this was reported against 1.1.0 which is out of support for a long time. If it applies to master, please open a new issue.

authors: MSP-Greg bernd-edlinger mspncp richsalz t8m


text:
Add possibility to exclude specific symbols from doc-nits check

In pull request #9224, it turned out that it would be convenient to explicitly disable the doc-nits check for specific symbols in certain sections. For example, one might want to add symbols to the NAMES section without providing a corresponding SYNOPSIS (see https://github.com/openssl/openssl/pull/9224#pullrequestreview-253143415). Currently, the only way to avoid doc-nit errors is to add a =for comment generic line. This however has the disadvantage that it disables the synopsis check completely, which is inconvenient when additional symbols are added later on to the pod file. It would be nicer if one could add just add a specific exclusion list (like OSSL_TRACEV, OSSL_TRACE3, OSSL_TRACE4, ... OSSL_TRACE8).
See also the discussions in #9095.

Would putting =for comment undocumented xxxx in the synopsis section fool doc-nits to not complain about xxxx?

Would putting =for comment undocumented xxxx in the synopsis section fool doc-nits to not complain about xxxx?

Oh, I missed that question somehow. I‘ll check that on the next occasion.

authors: mspncp richsalz


text:
Use large enough buffer for signature in dgst.c

Fixes #9732

Close/reopen to kick cla bot

The commit message reads:
Allocate and use new signature buffer with desired length if existing…

… buffer is not large enough

Fixes #9732

Since this description is very general, would you ( @nblka ) mind if it was changed to something along the lines of
apps/dgst.c: allocate a new signature buffer

... if the fixed-size buffer is too small.

Fixes #9732

when squashed ?

@p-steuer no, feel free to change it

merged, thanks.
master: https://github.com/openssl/openssl/commit/7c2d95d47ccb3797f0da6bd4446747c6eee07b87
1.1.1: https://github.com/openssl/openssl/commit/43a8f91f00e35b20e33c393f5b79215c277c508e

authors: mattcaswell nblka p-steuer


text:
Restore last-resort expired untrusted intermediate issuers

Description of change
Fixes #1997
[ Sorry, no time to build a test case. Perhaps someone else can pitch in with that. Just put some expired intermediates in the untrusted store, override expiration errors and check for success. The OP's sample code from #1997 could be used, with permission. It returns success after this change. ]

While, the OP has closed #1997, this PR has not yet been reviewed/merged. Please review this and #2005.

Thanks for the review.  Pushed and closed.


text:
INSTALL: document shared library pinning for static builds

The libcrypto library uses shared library pinning to prevent its cleanup handlers from crashing at program termination because of a premature unloading of the shared library.
However, shared library pinning is enabled also for static builds, which may lead to surpising behaviour if libcrypto is linked statically to a shared third-party library, because in this case the third-party library gets pinned.
This surprising behaviour is caused by the fact that the no-shared configure option does not imply no-pinshared. Since this quirk can't be changed without potentially breaking existing code, we just document it here and provide a workaround.
Fixes #20977

The last force-push fixed a typo.

This pull request is ready to merge

Merged to master, 3.1, and 3.0 branches. Thank you for your contribution.

authors: mspncp openssl-machine t8m


text:
Add test for -nameout output

Using a cert with Cyrillic characters, kindly supplied by Dmitry Belyavsky

@beldmit fyi :)

Updated commit with spacing changes made.

thanks!


text:
Return success in custom_ext_parse_old_cb_wrap if parse_cb is NULL

This fixes a segfault if a NULL parse_cb is passed to
SSL_CTX_add_{client,server}_custom_ext, which was supported in the
pre-1.1.1 implementation.
This behaviour is consistent with the other custom_ext_*_old_cb_wrap
functions, and with the new SSL_CTX_add_custom_ext function.

thanks, I've rebased on top of current master & added 'CLA: trivial' to the commit message

Pushed. Thanks.

authors: grahamedgecombe mattcaswell


text:
Replumbing: add a configuration module for providers

This configuration module supports a configuration structure pretty
much like the engine configuration module, i.e. something like this:
openssl_conf = openssl_init

[openssl_init]
providers = provider_section

[provider_section]
# Configure the provider named "foo"
foo = foo_section
# Configure the provider named "bar"
bar = bar_section

[foo_section]
# Override name given in the provider section
identity = myfoo
# The exact path of the module.  This is platform specific
module_path = /opt/openssl/modules/foo.so
# Whether it should be automatically activated.  Value is unimportant
activate = whatever

# Anything else goes as well, and becomes parameters that the
# provider can get
what = 1
# sub-sections will be followed as well
ever = ever_section

[ever_section]
cookie = monster

All the configurations in a provider section and its sub-sections
become parameters for the provider to get, i.e. the "foo" provider
will be able to get values for the following keys (with associated
values shown):
identity            => myfoo
module_path         => /opt/openssl/modules/foo.so
activate            => whatever
what                => 1
ever.cookie         => monster

Checklist

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

I was thinking that the self test variables would be in a separate config file that gets saved during the install process.. Ideally this would be loaded by the core also (A config file loaded from the config file).

That could be done using the new .include directive.
That separate config file will need to contain a section name.

So @slontis, what I'm suggesting is that the main config file could contain something like this:
openssl_conf = openssl_init

[openssl_init]
providers = provider_section

[provider_section]
fips = fips_module_section

[fips_module_section]
identity = fips
module_path = /opt/openssl/modules/fips.so
activate = whatever
fips_chk = fips_check_section

.include /opt/openssl/modules/fips.conf

And then, /opt/openssl/modules/fips.conf could contain this:
[fips_check_section]
module.mac = DCBD40AEC65D0E62B93E316F9315741021911D2ACEAFEF40730546845E83B90D
install.mac = FE10135AD3B4C7821B1E174CAC840C0AEF5F0696AE6E2C850E8E552886D62AD9
install.status = INSTALL_SELF_TEST_KATS_RUN

The resulting param names that the fips module would have to retrieve are fips_chk.module.mac, fips_chk.install.mac and fips_chk.install.status.

Another variant is just this in the main config file:
openssl_conf = openssl_init

[openssl_init]
providers = provider_section

[provider_section]
fips = fips_module_section

.include /opt/openssl/modules/fips.conf

And the rest in /opt/openssl/modules/fips.conf could contain this:
[fips_module_section]
identity = fips
module_path = /opt/openssl/modules/fips.so
activate = whatever
module.mac = DCBD40AEC65D0E62B93E316F9315741021911D2ACEAFEF40730546845E83B90D
install.mac = FE10135AD3B4C7821B1E174CAC840C0AEF5F0696AE6E2C850E8E552886D62AD9
install.status = INSTALL_SELF_TEST_KATS_RUN

That would make for exactly the param names you talk about instead of having to deal with the fips_chk prefix.

Either way we choose, I believe this PR supports it.

Close / re-open to kick the CIs

This is now open for review

The install application needs to write out these config values (which is why we decided that a seperate file should be used).

The install application needs to write out these config values (which is why we decided that a seperate file should be used).

Yes?  Can I assume that this is basically a mental note?

yes :)

I took this out of draft mode a bit too early...  so making it WIP

Now also includes a test

The tests here are currently failing, and it's due to confusion on when modules exist or not.  #8623 helps a lot with that.

Finally hammered this through the CIs...

Final review?

All things answered, I think...  including CI failures

Merged.  Thankss for all the reviews!
b6670f690c4244e63dbc02a2ba25061f9c53945f Replumbing: add documentation for the provider configuration module
6d872a838df78518508b5661d98da62a097317b1 Add test for the provider configuration module
abbc2c408385326d9c9cd60b92a6c92b945c1d96 Replumbing: add a configuration module for providers
ac1055ef13ccb5789e2bed7b9688c8eb16dd05ce Replumbing: add functionality to set provider parameters

authors: levitte slontis


text:
Functional tests for HSM Support

Functional tests for the Luna HSM model support.

/retest

/retest

recheck

authors: mauricioharley vakwetu


text:
[libvirt_manager] Fix undefined variable cifmw_reproducer_basedir

This change removes the reference of cifmw_reproducer_basedir in libvirt_manager role. Referencing the tasks from start_manage_vms throws undefined variable name.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running

/approve

/lgtm

authors: cjeanner pablintino psathyan


text:
[test-operator] Add the wait_timeout parameter to cleanup tasks

We recently encountered a timeout issue during the deletion of the test-operator. The default timeout is set to 120 seconds. By adding the wait_timeout parameter to the cleanup tasks, we can extend this time frame.

/ok-to-test

/approve

\lgtm

/cherrypick 18.0.0-proposed

authors: lkuchlan lpiwowar rlandy son-vyas


text:
Pass extra install_yamls variables to the set_openstack_containers role

Since the introduction of the multinode layout the defaults set by install_yamls refering to networking are no longer valid. In the edpm_prepare role we are since then passing custom variables for the MTU and the interface name using my NMstate, but till this PR set_openstack_containers is not passing them.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date

Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/544

recheck

/retest

recheck

/lgtm

authors: pablintino viroel


text:
Set default images via webhooks

Uses env vars set in CSV to provide defaults for container images in Glance and GlanceAPI CRs.  One possible approach using webhooks (an alternate non-webhook approach is proposed in #172).

@abays I see you removed the GlanceAPI logic in the last change. The patch looks good, I guess we can merge it as long as CI is green (I think the failure is unrelated)

/retest

@abays I see you removed the GlanceAPI logic in the last change. The patch looks good, I guess we can merge it as long as CI is green (I think the failure is unrelated)

Yeah, the CI issue might be a hiccup.  Will retest now.

/lgtm

authors: abays fmount


text:
Fix parameterised $NETWORK_NAME in interfaces-setup.sh

The ip-dhcp-host command still hard codes the network name to default. We should use the $NETWORK_NAME variable.

/recheck

recheck

recheck

recheck

recheck

recheck

recheck

recheck

All the Zuul jobs have passed independently over many attempted batch runs.  Let's override to stop rolling the dice in the hopes for a perfect run with no hiccups.

/override rdoproject.org/github-check

All the Zuul jobs have passed independently over many attempted batch runs. Let's override to stop rolling the dice in the hopes for a perfect run with no hiccups.

There was kind of an agreement to not use override and instead fix the jobs. I think we have no other option but to revert https://github.com/openstack-k8s-operators/edpm-image-builder/pull/19 to make the baremetal job stable.

recheck

/approve

authors: abays hjensas rabi


text:
Update template for telemetry tempest plugin

Dependency listed is to verify the fix works, sine the jobs will be the same otherwise
Depends-On: https://review.opendev.org/c/openstack/telemetry-tempest-plugin/+/912723

/retest-required

recheck

/retest

authors: elfiesmelfie jlarriba


text:
PA: Update legislator links

The existing links for PA legislators went to the generic page for all House/Senate members, and not the specific page for each member. Each member's link will now be for their specific page and not the generic page.

Pull Request Test Coverage Report for Build 1017

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 58.588%

Totals

Change from base Build 1016:
0.0%

Covered Lines:
996

Relevant Lines:
1700

💛  - Coveralls

authors: coveralls csnardi

repo: openstates/people


text:
Rendering bug: magic select looking control appears

What are the circumstances under which this occurred?

I had selected polygon/way and shift-selected point and pressed Detach command. Was in process of detaching landuse from way.
Sorry for no steps, will try to repro

The selection code has changed a lot since April, so I'm thinking this was a bug that's been fixed.
@skfd Please do let us know if you see this happen again.

authors: SilentSpike quincylvania skfd

repo: openstreetmap/iD

license: ISC


text:
[BUG] 在 remote 模式下，在文件选择器中删除文件会报错“文件XXX不存在。”

描述你的问题（Describe the bug）
在 remote 模式下，在文件选择器中删除文件会报错“文件XXX不存在。
复现路径（To Reproduce）
客户端以 electron 的形式启动，后端在远端服务器（文件系统在远端服务器，而非客户端本地）。
import { ClientApp } from "@opensumi/ide-core-browser/lib/bootstrap/app";

const app = new ClientApp({
    isRemote: true,
    wsPath: "ws://xxxxx",
    ... // 其他必要参数
});
await app.start(<XXX/>, "web");

启动后在文件选择器中选中某个文件。
按下快捷键 command + shift + back（macOS 系统）后，弹出对话框后选择确认删除。
右下角弹出消息框：“文件XXX不存在”。

预期表现（Expected behavior）
预期文件成功删除，实际无法删除成功。
问题分析
看如下代码，它判断 isElectronRenderer 为 true 时进入分支。进一步观察可知。
https://github.com/opensumi/core/blob/d983d100160ec5aed39f6a8223367ac8c38b3e60/packages/file-service/src/browser/file-service-client.ts#L405-L410
moveToTrash 方法会调用 electron 的方法，以在客户端删除文件。
https://github.com/opensumi/core/blob/d983d100160ec5aed39f6a8223367ac8c38b3e60/packages/core-electron-main/src/bootstrap/services/ui.ts#L83-L85
显而易见，此时必然失败。因为在 isRemote: true 的情况下，真实的文件在服务端，客户端并不存在该文件。所以删除失败。
此处逻辑是否符合业务需求？如我所示的代码中，isElectronRenderer 的判断条件是否应该改为 isRemote。
或者，我们的业务场景中，isElectronRenderer: true 并且 isRemote: true 的配置是否符合 opensumi 的要求？
环境信息（Environment）

OS: macOS 14.2.1 (23C71) Apple M1 Pro
Browser: electron
OpenSumi Version: 2.26.7

是的，看起来是有这个 bug 的，我们看下怎么解决

@bytemain 有没有可能，将 this.appConfig.isElectronRenderer 改为 this.appConfig.isRemote 即可。我的理解是这里应该用 isRemote。
https://github.com/opensumi/core/blob/d983d100160ec5aed39f6a8223367ac8c38b3e60/packages/file-service/src/browser/file-service-client.ts#L405-L410

repo: opensumi/core

license: MIT


text:
[BUG]  launch.json 里面通过命令替换字符串的方式似乎是失效的！

launch.json 里面通过命令替换字符串的方式似乎是失效的！
希望可以生效

我想要从我自定义的模块里面传入配置，来配置  python 的模块路径。这个路径和 opensumi 的安装路径相关，我应该怎么配置？

@zhuzeyu22  这种命令形式没有支持 .. 目前仅支持了部分 alias 类型的字符，相关代码在这里：
https://github.com/opensumi/core/blob/58b998d9e1f721928f576579f16ded46b7505e84/packages/variable/src/browser/variable-resolver.service.ts

ok， 我注册了一些全局变量。


text:
Test stability (follow up from cluster-confusion test).

Includes #249 because it would result in merge conflicts otherwise.
Addresses issue noted in https://github.com/opentable/sous/pull/246#discussion_r92236804 where we had a duplicated test that additionally relied on lack of isolation between tests for the intended failure condition to cause a failure. Now the failure condition will hold even when separate Test functions are completely isolated.

Current coverage is 58.55% (diff: 100%)

Merging #251 into master will not change coverage

@@             master       #251   diff @@
==========================================
  Files           136        136
  Lines          7040       7040
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           4122       4122
  Misses         2554       2554
  Partials        364        364

Powered by Codecov. Last update a77addd...2b32d5f

@nyarly @alrs Bump? :D

authors: codecov-io samsalisbury

repo: opentable/sous

license: mit

license_source: bigquery


text:
Check that new trait_category column in study table won't break pipeline

I have added a new column (trait_category nullable string) to the study table. This will be used by Eliseo for the phewas api.
The modified table is in staging (gs://genetics-portal-staging/v2d/180913/studies.tsv).
@mkarmona will need to check that it won't break the v2d pipeline if I copy to genetics-data.

Included. It will be in the next genetics-pipe run

It is already included.

repo: opentargets/genetics


text:
feat(trainer): log model explanation with shap

✨ Context
This PR closes https://github.com/opentargets/issues/issues/3562 and adds a more comprehensive understanding of the feature contributions to the model by integrating SHAP
I have tested that it runs, I have logged metrics using the gold standard https://github.com/opentargets/issues/issues/3526#issuecomment-2438453860, and the feature matrix from the 5th data freeze.
Panels have also been rearranged to easier to interact with https://wandb.ai/open-targets/gentropy-locus-to-gene/runs/n6wuhhe2?nw=nwuseropentargets

🛠 What does this PR implement

Added logging for 3 types of plots from SHAP:

1. Feature importances
(Plots section in the dashboard)

Bar plot with the absolute contribution of each feature to the model. In the X axis we see the mean absolute SHAP value, which measures the average influence of each feature on the prediction probability. It informs about magnitude, not directionality.
For example, a mean SHAP value of 0.6 for distanceFootprintMean means that this feature, on average, impacts predictions by 0.6 units. It's also interesting to see the lower tail, with features without any effect on the prediction.
Action: to check if there are non nulls in the gold standard for these features
--> Also interesting to see the difference between this plot and the other one computed based on an impurity based approach. Shapley values are based on the magnitude of feature attributions, whereas impurity based methods "measure how effective the feature is at reducing uncertainty when creating decision trees". I don't really know the limitations/biases of each method, I found this article interesting https://explained.ai/rf-importance/
2. Beeswarm plot
(Plots section in the dashboard)

The beeswarm plot gives an idea of both the magnitude and the direction of the feature in relation with the prediction.
Here features are ordered in terms of importance (mean SHAP value). Each dot represents a single row of the training set for that feature. SHAP values are expressed in terms of log odds, meaning that that positive values push predictions towards the positive class, and negative values push predictions towards the negatives. If we see features that cluster around 0, the contribution is small.
We see that in general our features have a positive effect on the prediction, meaning that high values tend to increase the probability of a positive prediction. However, it is interesting to see proteinGeneCount500kb, that indicates that low values tend to push the prediction to the negatives, but also to the positives in some instances.
3. Scatter plot between the values of a feature and its contribution to the model
(Feature/importance correlation section in the dashboard)

The scatter plot shows the effect a single feature has on the predictions made by the model
Again, each dot is a single prediction from the training set. The X axis is the value of the feature, and the Y axis is the SHAP value as log odds for that feature, representing how much knowing that feature’s value changes the output of the model for that sample’s prediction. The light grey area at the bottom of the plot is a histogram showing the distribution of data values.
For our most important feature, its contribution is largely stable as the feature increases, but only when the feature is ~1 we observe large effect sizes.

Adds shap and matplotlib to the project. Matplotlib is needed to tweak the plots outputed by shap.

I tried exporting the plots as HTML to make them interactive  in W&B but I didn't manage. What we do is that we save the plot in PNG and log that image to W&B
The script to install the dependencies on the cluster was failing becauseshap has a dependency, llvm, that can't be uninstalled to later be installed. In ae34fea20834f1e07c1b97f58be457cc9f6c343d I  have added a flag to overwrite the installation even when the package is already installed

The former feature importance plot has feature labels now. The error was due to trainer.features_list being null

🙈 Missing

🚦 Before submitting

[x] Do these changes cover one single feature (one change at a time)?
[x] Did you read the contributor guideline?
[x] Did you make sure to update the documentation with your changes?
[x] Did you make sure there is no commented out code in this PR?
[x] Did you follow conventional commits standards in PR title and commit messages?
[x] Did you make sure the branch is up-to-date with the dev branch?
[ ] Did you write any new necessary tests?
[x] Did you make sure the changes pass local tests (make test)?
[x] Did you make sure the changes pass pre-commit rules (e.g poetry run pre-commit run --all-files)?

Btw, this is a subset of plots that I thought could bring the most value. I've tested other things, in the notebook https://gist.github.com/ireneisdoomed/d60009ee9ccda6e5d2445e0cdfd83d91

@addramir Yes, please see the "Local interpretation" section in the notebook.
We can explain a prediction in different ways, I particularly like the waterfall plot.

The bottom of a waterfall plot starts as the expected value of the model output, and then each row shows how the positive (red) or negative (blue) contribution of each feature moves the value from the expected model output over the background dataset to the model output for this prediction

The starting probability is ~0.0067 (log odds of -5.3), and you see how each feature contribute to the final probability of ~0.98. What i like about it is also the greyed numbers next to the features, they indicate the value of each feature for this sample.
We could build our own plot (for which we'd need to store the shapley values in the predictions dataset), or use shap directly on the fly. The model is stored in Hugging Face, as soon as it is public the explaining function would download it, create the explainer and calculate the shapley values for that particular prediction.
I haven't implemented this yet because it depends on how we want to show this: if we use it in production, I suggest option 1, but if we only want to do it within gentropy as an explorative function, option 2 is more convenient.

repo: opentargets/gentropy


text:
Loci with strong associations are fine-mapped incorrectly

I thought I would make an issue here so that we keep track of this.
our current approach is to use GCTA-cojo to identify independent signals, using LD from 10,000 UK Biobank samples as a reference panel. (We only do fine-mapping for European GWAS so far.)
There is a problem with this though – at loci with strong associations, the fine-mapping can go wrong due to differences in LD between the reference panel and the GWAS sample. You can see this at almost any locus with a strong signal – e.g. APOE in Alzheimer’s disease. For example, this is a GWAS for family history of AD in UK Biobank samples:
https://genetics.opentargets.org/study/GCST005921
You can see that the genetics portal is reporting 20 independent signals, but 15 of these are at the APOE locus. Most likely, these all simply reflect the APOE4/APOE3/APOE2 haplotypes, but we are nominating different genes at these different “signals”. This occurs even though our reference panel is from the same population as the GWAS sample.
If you want to find more examples, look at any GWAS with strong associations, such as blood cell counts, or pQTLs.
Indeed, I’m concerned about integrating more pQTL datasets, because with the increasing sample size, this problem will get worse.
We need to determine a good solution.
My suggested approach is that we only do fine-mapping for GWAS with exclusively UK samples (e.g. UK Biobank), and use a larger reference panel (at least 50,000 UKB samples?). We could still perform colocalisations using the full marginal summary stats at each locus where we don't perform fine-mapping.

closing as added to feature doc

repo: opentargets/issues


text:
datatype facet should filter by association score

datatype facet should inject a score greater than zero for the requested datatype / datasource
We are currently returning data that has zero score, because it still has evidence associated with it.
Flower plot is enabled but petal for the datatype you requested is empty.

UK to confirm correct behaviour please @andrewhercules

@ElaineMcA and @elipapa:
I believe this is a data pipeline issue as it would require changes to the data pipeline and/or the associations and facets API endpoints.
For example, the associations page for liver disease shows 6977 targets. If a user filters that list by RNA expression, they will see 1753 targets. Within that list of targets, in the RNA expression column, some cells are light blue (score >= 0.0) and others are white (no data). Regardless of what cell a user clicks, they are taken to an evidence page with some evidence from Expression Atlas - for example, ESR1 and liver disease and BRAF and liver disease. The same behaviour is also observed if the user was to select the Affected Pathways facet.
I think the issue here is that the facet doesn't make a distinction between the underlying score and so it shows cells that are both light blue and white, which can confuse users because that behaviour is at odds with the other facets. For example, if a user selects the Drugs facet, the Drugs column will only have cells that have various shades of blue, indicating scores above zero.
My recommendation is that on the associations page, we amend the API response so that it does not return evidence strings that are not counted towards the score. This way, both the RNA Expression and Affected Pathways facets would behave like the other facets. On the evidence page, we can show this additional evidence if required - perhaps in a separate table so as to indicate to users that these evidence strings have not contributed to the overall association score.

Issue moved to opentargets/platform #100 via ZenHub

authors: ElaineMcA andrewhercules elipapa


text:
Memory-Optimized DeHs - UMN bug

Issue on page:        https://github.com/opentelekomcloud-docs/dedicated-host/blob/main/umn/source/product_introduction/categories_and_types/memory-optimized_dehs.rst
In my understanding (2 x 22 x 2 - 14) = 74, means vCPU number in for m4 flavor is not matching

Thank you for your comment, ticket OCS-10616 was created. Waiting for fix.

authors: cboelle mpristro

repo: opentelekomcloud-docs/dedicated-host


text:
Add support for long routes

Currently OpenThread (and Thread itself) does perform very poorly when faced with network consisting of long line of devices - e.g. a street, where there is a device in each street lamp. So, each device sees few neighbours on each side only. If the radio reachability is relatively small (e.g. device can see 5 neighbours on each side), and we want to have lets say 150 devices in line, it is (sadly) simply impossible to have such stable mesh with Thread.
The reasons behind it are pretty related to Thread internals - specifically kMaxRouteCost (equal to 16 now), max router count to be 32 and Route64 TLV not allowing router-router paths to cost more than 16. Given that in the extreme configuration as described above, we'd need all 32 routers, and they will still barely see the next router -> i.e. using maximum cost.
Currently no more than 4-5 routers would work like this, as the route cost between them would quickly reach 16, so they would stop being able to communicate with each other. If one of the edge routers would happen to be the leader, the other edge will be too far away to contact leader within 16 cost and mesh would partition.
I will try to submit PR with some proposal how to solve this, but that obviously will hit a number of problems, so I'm opening this issue to host the discussion (which hopefully will unfold) until PR is ready.
One of the biggest obstacle is that the Thread specification itself (at least in version 1.1.1) basically limits this. Any modification will fail to comply with standard. It seems, that some trade-off can be made, to allow heterogenous meshes containing standard and non-standard devices working together as much as possible - but that is going to be extremely tricky.
We also need to be careful to not exceed certain MLE Advertisement size, to avoid unnecessary packet fragmenting. My tests show that we can add up to 27 bytes to the advertisement packets safely.
Another quirk is that, I feel that introducing brand new TLV would be a better (or more elegant) idea, yet it would add 2 bytes to the advertisement packet, and the current OpenThread implementation seem to rely heavily on Route64TLV::GetCost(), so when cost would depend on different TLV, code refactoring would be significantly bigger. For both those reasons, I think I will try to add some bytes at the end of existing Route64 TLV instead of adding new TLV. Especially that later it should be relatively simple to split that out to new TLV (apart of the refactoring of the today's code).
My biggest question is: if this PR will materialize, and will go through your review process, are there chances to merge it to the master? Or I shouldn't bother, since the change will deviate from standard?
For the reference, there was a very short discussion on this on openthread-users: https://groups.google.com/forum/#!topic/openthread-users/F6YY_lQiTZg
So, my plan is to:

add some #define / configure switch (e.g. LONG_ROUTE_SUPPORT) to have this fully optional
increase kMaxRouteCost to something like 127 (to keep aRouteCost1 + aRouteCost2 within uint8_t range) - 31*4=124 might be enough, actually (I'm not 100% sure here)
or maybe keep kMaxRouteCost at 16 but add kMaxLongRouteCost - for easier handling fallback scenarios to cooperate with vanilla 1.1.1 devices
extend the Route64 TLV with 7 bits for each router-router path with cost higher than current maximum
trace down all route cost calculations and update them to use new max values and making sure they won't overflow uint8_t

What do you think?

Thanks for continuing to drive this proposal (and apologies for not responding to your mail earlier).
While a primary goal of OpenThread is to be a leading reference implementation of Thread, I would also like to see OpenThread support development of forward-looking features that may eventually land in a future version of the Thread specification.  Allowing a Thread network to expand beyond several hops certainly seems like a feature worth exploring.  As long as the new feature places (ideally) no burden (e.g. can be compiled out, limited hooks in the base code, etc.) on the core Thread 1.1 implementation, then I think there is a path forward.
While supporting a single Thread mesh composed of Thread 1.1 routers and "long-route" routers is desirable, I'm not sure this is achievable.  For example, in Thread 1.1, the Leader allocates and maintains the set of active router ids.  The Leader determines if a router is present within its partition by monitoring the route cost to that router.  If the route cost is "infinite" for some continuous time period, the Leader will reclaim the router id and begin advertising that the given router id is no longer a part of the partition.
An alternative approach is to configure the network such that only "long-route" devices are able to become routers.  As part of Thread Commissioning, the Security Policy TLV may be used to restrict Thread 1.1 devices from becoming routers.
Thoughts?

I'm glad to hear that this work have a chance to be merged, encouraging ;) Indeed, the plan is for it to be completely compiled out by default, with no cost.
As for the old & new mixing, I don't have a solid plan yet - I'm also afraid that it won't be possible, at least in some edge cases. I wasn't aware of the Security Policy TLV details, it's R bit seem indeed very interesting solution.
Since many internal details of Thread working are still unknown to me, I'm not sure how much we will gain by that. Like, I'm not sure how much Route64 TLV processing is done on children / REED. It seems that almost none, but the spec also says that child need to check cost to leader from its parent Route64 TLV. If that is the case, even the Security Policy TLV won't help, we will have to transmit values in some backward compatible format (which will be extremely annoying).
However, Security Policy TLV is probably the most elegant solution (if it will work) - and it feels like designed for case like that, actually. It would allow introducing new version of Route64 TLV without any tricks to maintain compatibility with 1.1 - therefore saving some bytes.

Router-Eligible End Devices (REEDs) are required to process Route64 TLVs because they are capable of becoming a router if needed.  If an end device never intends to become a router, there is no reason for it to process Route64 TLVs.  That said, I believe we need to add code to properly honor the Security Policy TLV R bit.

Yeah, the change seems so incompatible, that it warrants the R bit usage. I will go for it.
My only concern is that we have only 1 R bit for whole Thread 1.x stuff. By using it, this feature will eye forward Thread 2.x. Which probably is a proper thing to do... Also, Thread 2.x should probably define more bits like this (only 3 left without extending the TLV) to block all Thread 2.x REEDs from becoming routers - for 3.x compatibility..

@jwhui it seems that the R bit in Security Policy TLV is currently ignored in OpenThread. This is a bug, actually. In order to fix it, should I just add proper && (aDataset.mSecurityPolicy.mFlags & OT_SECURITY_POLICY_ROUTERS) to https://github.com/openthread/openthread/blob/master/src/core/thread/mle_router.cpp#L104 and https://github.com/openthread/openthread/blob/master/src/core/thread/mle_router.cpp#L109 ? What about https://github.com/openthread/openthread/blob/master/src/core/thread/mle_router.cpp#L75 - the TLV value might not be known at the moment of initialization, right?
Or the actual fix should be more sophisticated?

@Nopik, as you noted, the R bit is currently ignored.  I’ll have a PR up soon to address this.  You can see a preview here: https://github.com/openthread/openthread/compare/master...jwhui:security-policy

Thanks. I started to implement this on my PR, but I'll revert, as your implementation seems to be better.

@Nopik, I just submitted #2778.  Please review.

Resolved by #2775.

@Nopik do you still use the OPENTHREAD_CONFIG_MLE_LONG_ROUTES_ENABLE feature?
Working on something related, I noticed OT stack may not compile ok if thire feature enabled (couple of build errors - mostly seem to be trivial type mismatch issues). We can fix them but may be good to not keep code around if it is not being used and/or tested (by CI)?

@abtink Unfortunately I no longer with that company and currently I'm not in position to submit any fixes for this ;( I tried to look up any github nickname from my old team, but didn't found any, either. (Quite surprisingly, because I know that some of them were active in this repo, apparently Github is making search not perfect). Anyway, I eventually pinged one mate on LinkedIn, so hopefully he'll pick it up..

Thanks @Nopik . No worries. I can fix the build issues in an upcoming PR. 😃 (I guess it may be toolchain dependent).

authors: Nopik abtink jwhui

repo: openthread/openthread


text:
[radio] add Radio::GetNow()

This commit adds the GetNow() method to the Radio class, which maps to otPlatRadioGetNow(). This method is used within core modules to avoid calling the otPlat API directly, aligning with the practice for all other otPlatRadio APIs, which are called through the defined Radio class methods.

Will wait for https://github.com/openthread/openthread/pull/10762 to be merged to rebase and also update the uses of otPlatRadioGetNow() within that PR.

@abtink I also hope to use this new method in a upcoming PR. Is it possible to merge this one first as a small PR?

@abtink I also hope to use this new method in an upcoming PR. Is it possible to merge this one first as a small PR?

Yes. Definitely okay/easier for me. :)

authors: abtink bukepo


text:
Fix build warnings on Windows

This fixes build warnings when built on Windows. See issue #570

Current coverage is 63.97% (diff: 75.00%)

Merging #577 into master will increase coverage by 0.01%

@@             master       #577   diff @@
==========================================
  Files            88         88
  Lines         12171      12171
  Methods        1686       1686
  Messages          0          0
  Branches       1429       1428     -1
==========================================
+ Hits           7785       7787     +2
+ Misses         3971       3969     -2
  Partials        415        415

Powered by Codecov. Last update 6243511...69e230f

LGTM 👍

authors: codecov-io jwhui nibanks


text:
OTBR Docker Firewall

Hi @jwhui,
This still needs a review from @Vyrastas, but I wanted to run it by you first.
OTBR firewall/Docker:

Added the steps to Docker Overview
Mentioned it again in Docker Run, in case developers skipped the setup
Added a blub under features (I can take this out if it doesn't make sense here)

Happy to make any changes; just let me know.
Thanks,
Sarah

@jwhui No problem - @Vyrastas - this is ready for a review...thanks!

repo: openthread/ot-docs


text:
[replay] add replay player

This PR adds a new program for playing replay: otns-replay based on PR #76
Example usage:
$ otns-replay otns_0.replay

should we include file web/site/bindata.go?

This PR neither changes the web site, or the gRPC protocol, thus no bindata.go change.

repo: openthread/ot-ns


text:
Updated to support android-sdk-2.9.0

This is to be merged after the 2.9 release.

LGTM

authors: ArdyTokbox Nitrillo

repo: opentok/opentok-android-sdk-samples


text:
🛑 [CN] OpenUPM Website Docs is down

In e922dbb, [CN] OpenUPM Website Docs (https://openupm.cn/docs/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in 98d3bc8 after 8 minutes.

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website is down

In 371ca57, [CN] OpenUPM Website (https://openupm.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in 8f86f5d after 8 minutes.


text:
🛑 [CN] OpenUPM Website Package Detail is down

In 3a7d6cb, [CN] OpenUPM Website Package Detail (https://openupm.cn/packages/com.littlebigfun.addressable-importer/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Package Detail is back up in f60ba9c after 7 minutes.


text:
🛑 [CN] OpenUPM Website Packages is down

In 6daca0f, [CN] OpenUPM Website Packages (https://openupm.cn/packages/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Packages is back up in 98ad840.

repo: openupm/upptime


text:
🛑 [Global] Unity Registry /package-name is down

In 2e5b86a, [Global] Unity Registry /package-name (https://packages.unity.com/com.unity.addressables) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [Global] Unity Registry /package-name is back up in b0c0668.


text:
Fix more pronunciations (1/N)

This is 1/N break up of #504, we fix the incorrect pronunciations in this commit first.

@ChiahongHong I tried to follow the pronunciations from the dictionaries, if you noticed some "commonly misused" ones, please kindly let me know and I'll add them back.

Thank you!
Found a new incorrect pronunciation; it can be corrected as well

出使 ㄔㄨ ㄕˋ → ㄔㄨ ㄕˇ

煽 教育部各字典皆未收 ㄕㄢˋ 這個音，不確定會不會有人這樣讀，如果是就先不處理留作記錄

煽動力 ㄕㄢˋ ㄉㄨㄥˋ → ㄕㄢ ㄉㄨㄥˋ
煽動性
煽情 ㄕㄢˋ ㄑㄧㄥˊ → ㄕㄢ ㄑㄧㄥˊ
煽情主義
煽惑 ㄕㄢˋ ㄏㄨㄛˋ → ㄕㄢ ㄏㄨㄛˋ

Fixed 出使 ㄔㄨ ㄕˋ → ㄔㄨ ㄕˇ.
Yes, I didn't find any references for 煽 ㄕㄢˋ, I made them all consistent as ㄕㄢ
$ ./find.py 煽 ㄕㄢ
煽動 ㄕㄢ ㄉㄨㄥˋ
煽動力 ㄕㄢ ㄉㄨㄥˋ ㄌㄧˋ
煽動性 ㄕㄢ ㄉㄨㄥˋ ㄒㄧㄥˋ
煽客 ㄕㄢ ㄎㄜˋ
煽情 ㄕㄢ ㄑㄧㄥˊ
煽情主義 ㄕㄢ ㄑㄧㄥˊ ㄓㄨˇ ㄧˋ
煽惑 ㄕㄢ ㄏㄨㄛˋ
煽火 ㄕㄢ ㄏㄨㄛˇ
煽色腥 ㄕㄢ ㄙㄜˋ ㄒㄧㄥ
煽起 ㄕㄢ ㄑㄧˇ
煽起來 ㄕㄢ ㄑㄧˇ ㄌㄞˊ
煽風點火 ㄕㄢ ㄈㄥ ㄉㄧㄢˇ ㄏㄨㄛˇ

@xatier I have double-checked all these changes. Thank you! 🎉

@lukhnos this one should be ready to go, after this PR, I'll submit subsequent PRs for characters in #504 individually (fix one character at a time).

Rebase on top of master.

Rebase on top of master.

Rebase on top of master.

@lukhnos thank you for merging this!

@lukhnos would you mind having a sync to the Linux repo? So that I can enjoy the revisited dictionary on my box.
Similar to https://github.com/openvanilla/fcitx5-mcbopomofo/pull/143

authors: ChiahongHong xatier

repo: openvanilla/McBopomofo


text:
Remote sources file name & performance

My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues

Hi all,
I'm trying to import a dataset using the feature "Remote resources" from the create task dialog.
Expected Behaviour
I would expect cvat to store the provided URLs and fetch the content as I label the images. Also, the filename should be the URL provided.
Current Behaviour
The first feature will allow displaying in cvat datasets of arbitrary size, relying on external services such as S3 or Azure Blob Storage to store all the data. The current behavior looks like just downloads everything at task creation.
Keeping the file name as the URL will allow the users to match the labels with the proper image after exporting. The current behavior only keeps the filename in the URL, which is the last path fragment.
Context
I'm working with DVC to track my datasets and I would like to integrate with CVAT to generate the annotations. We've built an image server backed by DVC+git that generates URLs for any image given its path and git ref. The means that we can generate all the URLs of all the images in master branch. The idea is to import this in CVAT, generate the annotations, and import them back to track everything with git.
I know it could be possible to just use a connected file share, but it will require to download the entire dataset before annotating and to duplicate the storage on the CVAT machine. If CVAT could load data on-demand from that URL, it would be incredibly handy as you could create a task and have it available at the same moment. This enables powerful workflows to automatically create annotation tasks.
Just to not forget about it, keeping the original URL as an image path/reference it is required in order to be able to match the annotations back to the original image. Also to prevent collisions due to images with the same name but on different directories.
Thank you for your time
Context
build from source at origin/release-1.2.0 266e7ca9b4ceb76077e8e2b54df6a3a208f3e17b

@MetalBlueberry , you can use Cloud Storages now for the task. Does it solve the issue? I agree that keep "full path" to the url can be useful. Need to think how to implement the feature. In some cases users want to have only filename with its extension.
https://openvinotoolkit.github.io/cvat/docs/manual/basics/attach-cloud-storage/

Hi @nmanovic
I'm no longer working with CVAT so I can't answer your question :sweat_smile:
Thank you for taking the time.

@japrescott , CVAT server downloads all data by default now. But CVAT v2.0.0 has improved permissions management system. It is possible to provide as little rights to a person, as needed. Will it solve the issue?

authors: MetalBlueberry nmanovic

repo: openvinotoolkit/cvat


text:
ADD gcp deploy

REMOVE certs

Motivation and context

How has this been tested?

Checklist

[ ] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below)

# Copyright (C) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage remained the same at 70.28% when pulling 0f0cf353d12c6ab0e6a7197fd191b4f5afe0ce0a on fastcode99:feature/gcp-deploy into 66a32b178c68950add061cbd9732d19ec5389162 on openvinotoolkit:develop.

Coverage remained the same at 70.28% when pulling 0f0cf353d12c6ab0e6a7197fd191b4f5afe0ce0a on fastcode99:feature/gcp-deploy into 66a32b178c68950add061cbd9732d19ec5389162 on openvinotoolkit:develop.


text:
[Doc] AVA action and MVTec data formats

Summary

How to test

Checklist

[ ] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG
[x] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below)

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

Codecov Report
Patch coverage has no change and project coverage change: -0.01 :warning:

Comparison is base (e601f3e) 78.49% compared to head (631e4ab) 78.49%.

Additional details and impacted files
@@                Coverage Diff                 @@
##           releases/1.1.0     #865      +/-   ##
==================================================
- Coverage           78.49%   78.49%   -0.01%
==================================================
  Files                 206      206
  Lines               24939    24939
  Branches             5007     5007
==================================================
- Hits                19577    19575       -2
- Misses               4236     4237       +1
- Partials             1126     1127       +1

Flag
Coverage Δ

macos-11_Python-3.8
?

ubuntu-20.04_Python-3.8
78.49% <ø> (ø)

windows-2019_Python-3.8
?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: codecov-commenter wonjuleee

repo: openvinotoolkit/datumaro


text:
cniserver: Improve CNI performance on Windows

Currently, kubelet on Windows calls the CNI for every single container
within the same POD. This patch adds an early return in order
to skip calling powershell if the interface is already set up.
This applies only for the subsequent calls and not for the
first CNI call.
Signed-off-by: Alin Balutoiu alinbalutoiu@gmail.com

@aserdean @rajatchopra
What do you think about this? It seems to improve the running time by skipping a few powershell calls which are slow. This would probably be noticed when spawning multiple pods at the same time or when creating a pod with multiple containers in it.

My only issue with this one would be diminishing returns.
At one point the number of OVS ports will make the find more costly w.r.t. the commandlets.
Do you mind trying to fetch some numbers on the improvement and when diminishing returns will happen?

I talked and tested this with @alinbalutoiu offline. It ends up that adding ports is slower than querying the database.
/LGTM

@dcbw can you please take a look over the comment?

authors: alinbalutoiu aserdean

repo: openvswitch/ovn-kubernetes


text:
URL shortner solutions - Connectionless Credentials.

Hello.
Question: Is there a solution to shorten the URL for connectionless credentials with the requests~attach property?
It's too long to be converted into a QR code.
If not, how can I approach this situation to convert the connectionless invitation to a QR code? (Ideas needed)
I considered URL shortening solutions for this, but unfortunately, that would not satisfy every other user scanning the QR code with a different wallet.
Note: Normal connection URL fits into the QR code since it has only the basic necessary properties for connection.
Sorry, if it's a dumb question, but I'm kind of stuck on it.

Maybe not all wallets support url shortening, but they should. It's part of the RFCs and useful for specifically the issue you're now running into

Right, thanks @TimoGlastra

authors: TimoGlastra sudddy


text:
database get operations do not properly handle unicode characters

The decoding is localized to reading records from the database (on the client side) which is normalizing to the HTTP default charset ISO-8859-1 instead of UTF-8.
As a sanity check, I confirmed that for a sample code:
function main() {
  var frenchMessage = "Le périphérique est connecté";
  var chineseMesage = "装置被连接";
  return ({"fr": frenchMessage, "zh-Hans": chineseMesage});
}

The record is stored correctly in the database. If I were to encode the string using base64 encoding and logging the result, the activation result and logs are correctly stored in the database:
function main() {
  var msg = 'eyJmciI6IkxlIHDDqXJpcGjDqXJpcXVlIGVzdCBjb25uZWN0w6kiLCJ6aC1IYW5zIjoi6KOF572u6KKr6L+e5o6lIn0=';
  var dec = new Buffer(msg, 'base64').toString('utf-8');
  console.log(dec);
  var res = JSON.parse(dec);
  return res;
}

results in this activation record:
"response": {
    "statusCode": 0,
    "result": {
      "fr": "Le périphérique est connecté",
      "zh-Hans": "装置被连接"
    }
  },
  "logs": [
    "2016-04-23T13:36:16.030199912Z stdout: {\"fr\":\"Le périphérique est connecté\",\"zh-Hans\":\"装置被连接\"}"
  ],

@psuter FYI this is true both using the Cloudant SDK as well as the Spray client.

Can we just normalize to UTF-8 instead of ISO8859-1. Until this is fixed it will be difficult for anyone to use OpenWhisk in anything other than English.

Using Unicode escape sequence in action code also could produce UTF-8 output:
var chineseMesage = "\u88c5\u7f6e\u88ab\u8fde\u63a5";

@psuter can you summarize your findings?

I found a S/O discussion regarding the encoding declaration for HttpEntity in scala/spray
http://stackoverflow.com/questions/36456796/spray-test-case-doesnt-property-unmarshal-utf-8-encoded-json-using-httpentity
Hope this solution would help.

So this is slightly fuzzy in my head.. I believe I had tracked it down to being an issue only happening when the JVMs are running inside a Docker container. (The DB seems to store everything properly.) I had diff'ed the JVM system properties when running outside of a container and when running with the image we use for all Scala containers, and there was only one difference. I believe it was a property related to the byte order mark... not 100% sure. I also believe this was a fixed property, not one that the user can configure.

Also, my branch https://github.com/psuter/openwhisk/tree/utf-8-db had some tests and (unsuccessful) attempts.

I confirmed the DB (CouchDB) stores action codes with non-English data correctly by reviewing the CouchDB web interface for my vagrant install.
http://172.17.0.1:5984/_utils/database.html?vagrant_vagrant-ubuntu-trusty-64_whisks
(Overview > vagrant_vagrant-ubuntu-trusty-64_whisks > guest/myaction)
This may mean wrong charset conversion happens when loading action codes or producing a response in the Invoker.

I suspect that OpenWhisk is using the wrong codepage when actions are being executed. My guess is that they are using ISO8859-1 (Latin 1) when they should be using UTF-8 (Unicode). This should be a simple configuration change and would enable them to avoid having to do a conversion as the actions and data are most likely in UTF-8 already.

Getting more reports from users being hit with this problem, like using a parameter with value ""Aurélien" the é not being handle correctly.

I think that this really needs to get fixed and I think it is tied to #362 as well.

There are many instances of this buy - fixing this will close the most issues in one commit :1st_place_medal:

Here's a hint: actions via zip files work. This rules out (as both @psuter and I confirmed with separate unit tests) that it's not the action container or the interface between the container and the invoker for exchanging arguments.

Ok so this means that it is probably the code that is reading the files. It may be reading it in the wrong codepage. Check to see if they have hardcoded that. If the code that reads the files is written in Java then the default codepage is probably ISO8859-1. I don't believe that UTF-8 is the default you need to explicit state the encoding.

found it!

Don't keep it a secret !!!

Let me get some popcorn, brb

Awesome :)

Proposed patch https://github.com/openwhisk/openwhisk/pull/1757/commits/23bf16ad17534fa746fdd80cb5108f7979352c18.

I confirmed a couple of issues were duplicates and closed them (and tests cover them).
The Java action proxy, and the python proxy for the other runtimes will need to be patched. These are confirmed to be in the containers themselves, and not the Invoker (as was the case with node.js). #1757 fixes the node.js actions as a first step.

Great!

Thanks!

Fix merged in #1757.

authors: csantanapr kaya-mikio midheartty psuter rabbah steveatkin stevenatkin

repo: openwhisk/openwhisk


text:
Bootstrap 4

Looks like Bootstrap 3 is no longer maintained is there any chance that luci will move to Bootstrap 4 anytime soon?

Given that the current boostrap theme does not exactly use a vanilla Bootstrap 3 either, I'd say the chances are rather slim for the moment. At least no immediate switch to Bootstrap 4 is planned.

authors: jow- junland

repo: openwrt/luci


text:
luci-app-lxc: "Action failed!" when configuring container

Steps to reproduce:

go to: Services -> LXC Containers
Create a new container (I'm using "Debian Bullseye" from https://repo.turris.cz/lxc)
After container is created, select "more" drop-down for it and select "configure"
Change any configuration or leave config unchanged
Click "Confirm"

Actual behavior:
Action failed! response is given and the configuration is not saved.  Configuration window does not close.

Nothing appears in /var/log/messages when this happens.
Expected behavior:
Example: Replace the following lines and remove this
Application is saved and configuration window closes
Additional Information:
OpenWrt version information from system /etc/openwrt_release
DISTRIB_ID='TurrisOS'
DISTRIB_RELEASE='6.0.2'
DISTRIB_REVISION='r16699+129-1d12cfdce2'
DISTRIB_TARGET='mvebu/cortexa9'
DISTRIB_ARCH='arm_cortex-a9_vfpv3-d16'
DISTRIB_DESCRIPTION='TurrisOS 6.0.2 1d12cfdce28101ca60fc7afed1e4cf0812814992'
DISTRIB_TAINTS='busybox'

/etc/config/lxc:
config lxc 'lxc'
        option ssl_enabled '1'
        option min_space '100000'
        option min_temp '100000'
        option url 'repo.turris.cz/lxc'

Turris storage plugin is configured for /srv on an ssd (including /srv/lxc/):
/etc/config/storage:
config srv 'srv'
        option uuid 'ca298dde-abf3-49ca-bc77-f10ba5cc0784'

If additional information is required, let me know.

I have the same issue, doing the same modification directly on the config file using vim or something works perfectly though

No one cares about this plugin?

same problem here!

authors: Vinke2 eugenio gclawes thomas-maurice


text:
luci-ssl-openssl selects libmbedtls and libopenssl

Why does luci-ssl-openssl select both these libraries? This seems to just increase file size. Reason why I use openssl is because of the hardware offload it allows.

Why does luci-ssl-openssl select both these libraries?

The reason is mentioned in the luci-ssl-openssl Makefile:
https://github.com/openwrt/luci/blob/master/collections/luci-ssl-openssl/Makefile
As LuCI is common to both Openwrt and LEDE, luci-ssl-openssl still selects also px5g that brings in mbedtls (in LEDE) or polarssl (in Openwrt).

uhttpd in LEDE has been patched to generate SSL keys using the openssl cmd (from openssl-util package)
uhttpd in Openwrt does not yet know how to generate the SSL keys with openssl command line tools. It uses px5g for it.

Luci-ssl-openssl is currently defined as:
LUCI_DEPENDS:=+luci +libustream-openssl +px5g
In LEDE it is possible to replace px5g with openssl-util and achieve "openssl-only" build without px5g and libmbedtls, as uhttpd can also generate keys with openssl commandline tools if px5g is not present.
You can achieve openssl-only build two ways:

edit luci-ssl-openssl Makefile in your LuCI feed repo and replace +px5g with +openssl-util
do not select luci-ssl-openssl, but select separately luci, libustream-openssl and openssl-util

(luci-ssl-openssl was introduced to enable using libustream-openssl more easily for luci SSL connections, but luci-ssl-openssl is not perfect as it still includes px5g.)

Thank you for the thorough explanation!

Openwrt uhttpd has now been patched, so I committed https://github.com/openwrt/luci/commit/b6341bd197aed9640c4d0dcff73019e045978df0 to remove the dependency for px5g (and mbedtls/polarssl)

authors: hnyman thagabe


text:
Update tile and decompose attention pass

This patch adds the following updates to the tile and decompose pass:

Does matmuls in fp16 with fp32 accumulators
Does softmax in fp32
Reduces number of divisions to 1 (from 2) for faster performance
Change exp to exp2 for faster performance

@MaheshRavishankar @hanhanW - please can you review these changes?

I have a consistent repro for the memory error that surfaced here: https://github.com/openxla/iree/issues/13967

@hanhanW - sorry this patch has gotten buried as I was out for a while. Could you please take a look at this again?

Thanks!

authors: GMNGeoffrey harsh-nod

repo: openxla/iree


text:
BRAVE-250

-Added tests to show InheritableThreadLocals will leak across threads
These tests will currently fail. I don't know if it's possible to provide a reliable fix without getting rid of the InheritableThreadLocal. Even if the objects are cloned they will not work in Executors that reuse threads.
A better approach would be to maintain a stack something like
class WrappedSpanLocal {
    Span span
    WrappedSpanLocal parent;
}

and use ThreadLocals. This would involve updating the BraveExecutors that pass context between the threads to not only pass server spans but client and local spans as well which would break backwards compatibility.
I will continue to think of another solution.

cc @schlosna I'm pretty busy next couple days. in case you aren't mind reviewing this?

It looks like you are actually testing the behavior of inheritable thread locals, right? We'd expect inheritable thread locals to propagate to threads.
Can you rephrase your tests on the actual use case you are trying to get to work? or maybe summarize the reason why the inherited state causes a problem? (I know there are a number of reasons why many don't prefer inheritable, but we need to pin this down with a use case)

Sorry I totally forgot about this issue. Your right my test is really testing thread locals. I guess the issue I'm having is Spans are immutable, most users by default will use a executor that reuses threads which results in weird behaviour as the span moves between threads.
I'm not sure I even understand the use case for InheritableServerClientAndLocalSpanState as it seems like it's very unsafe due to the thread locals.
Maybe this issue is more of a documentation update issue than a code fix issue as it seems like it's working as intended.

latest brave has a type called CurrentTraceContext which can be easily customized to not use inheritable thread locals

authors: adriancole gnoremac

repo: openzipkin/brave


text:
Combinations of collectors and storage techs

Hi,
I understand that Kafka has been the main collector so most docker cases focus on the storage. But since I am working on Azure Event Hubs collector, how should we set up the hierarchy and the project setup? Should each combination have their own folder?

Sorry, on second thought does not make sense, closing it.

repo: openzipkin/docker-zipkin


text:
zipkin-ui: improve page rendering time by re-configuring jquery-i18n-properties

By default the jquery-i18n-properties plugin appends the current timestamp every time it requests the language .properties file, which requires the file to be loaded on every page load and prevents it from being served from cache.
By enabling the cache option, that will no longer happen.
Another factor is the loading of several language files that is attempted. In my case traces.properties, traces_en.properties, traces_en_US.properties. The first one succeeds, the other 2 return a 404. That 404 cannot be cached by the browser.
The async option defers the loading of additional files, which should also improve time to render.

Wonderful.
Just please add short comment about this because few here are familiar and
they can learn. The git history isnt always read though should be.

thanks!

authors: adriancole igorwwwwwwwwwwwwwwwwwwww

repo: openzipkin/zipkin


text:
Fixes int overflow issue for large TTL values

Fixes #3357.
The line indexTtl * 1000 will produce an integer overflow for large indexTtl values. For example 7890000 * 1000 will produce an integer overflow (some negative number).
The simple fix is to use long in the multiplication.

Ping @anuraaga
On Sat, 14 Aug 2021, 22:16 m, @.***> wrote:

Fixes #3357 https://github.com/openzipkin/zipkin/issues/3357.
The line indexTtl * 1000 will produce an integer overflow for large
indexTtl values. For example 7890000 * 1000 will produce an integer
overflow (some negative number).
The simple fix is to use long in the multiplication.
You can view, comment on, or merge this pull request online at:
https://github.com/openzipkin/zipkin/pull/3367
Commit Summary

Fixes int overflow issue for large TTL values

File Changes

M
zipkin-storage/cassandra/src/main/java/zipkin2/storage/cassandra/CassandraSpanStore.java
https://github.com/openzipkin/zipkin/pull/3367/files#diff-d85e858924df5caed00b20b67deac8389b768227fc7fdf8f7575884ae941a663
(2)

Patch Links:

https://github.com/openzipkin/zipkin/pull/3367.patch
https://github.com/openzipkin/zipkin/pull/3367.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/pull/3367, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYATCSMZBLEHKGXAOGLTT43FLVANCNFSM5CFNDVLA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

@vy8 could you add a unit test for this?

Hey @jcchavezs just did. Even thought it's a simple test that checks if startMillis is smaller than endMillis it will fail with the old code that doesn't have the explicit 'L' for long.

Somehow the test is failing. Would you please look into it?

@jcchavezs bumped the year in the license from 2020 to 2021 and all should be good.

thanks. will be in next release

authors: codefromthecrypt jcchavezs vy8


text:
npm express package required for zac

I'm not sure if this is a Mac specific thing but when I had first run the command to start up the ZAC server, I was presented with a failure that explained the express package was required.
After a simple npm install express and retrying to start ZAC everything worked.
We should verify if this is a widespread issue or just a local issue in this one case. If it's a widespread issue then update the doc to explain that this package is needed. Or maybe just add a blurb that it's needed and might not be installed and show how to install it.

This is handled by the npm install command in the ZAC quickstart.
https://openziti.github.io/search/?q=zac

repo: openziti/ziti-doc