text:
OLS-495: Keep default user UUID and set it to "nil" UUID

Description
Keep default user UUID and set it to "nil" UUID
Type of change

[x] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #OLS-495

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.34%. Comparing base (732f648) to head (28812a0).
Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #813      +/-   ##
==========================================
- Coverage   94.42%   91.34%   -3.09%
==========================================
  Files          55       55
  Lines        2027     2010      -17
==========================================
- Hits         1914     1836      -78
- Misses        113      174      +61

Files
Coverage Δ

ols/constants.py
100.00% <100.00%> (ø)

ols/utils/auth_dependency.py
72.64% <ø> (ø)

... and 6 files with indirect coverage changes

/retest

/lgtm
/approve

/retest

/retest

authors: bparees codecov-commenter tisnik


text:
Bug 2081172: YAML view in webconsole does not show all the available key value pairs of all the objects

The alm examples annotation was inadvertently removed while migrating
CRDs, hence adding new versions of bfd profile, bgp peer, ip address
pool, bgp and l2 advertisement examples. This would get webconsole
to get rendered with yaml templates.
Signed-off-by: Periyasamy Palanisamy pepalani@redhat.com

/bugzilla refresh

/assign @fedepaol

I think we need to align also the ocp manifests under manifests/stable and manifests/4.11 here

I think we need to align also the ocp manifests under manifests/stable and manifests/4.11 here

yes Federico, aligned those csv's with another commit.

/lgtm
/approve

source: gharchive/pull-request

authors: fedepaol pperiyasamy

repo: openshift/metallb-operator

license_type: permissive

license_source: github-api


text:
USHIFT-1590: Event cache configuration update

Default configuration for event cache allows only 1 event every 5min. This triggers event aggregation which collapses several events into a single one, losing information about the event (aggregation happens when the reason is the same, regardless of the message). By allowing 1 event per second this problem is greatly reduced (if not completely).

Which issue(s) this PR addresses:

Closes #

/cc @ggiguash @dhellmann

Event invariant does not fail now according to https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_microshift/2247/pull-ci-openshift-microshift-main-e2e-openshift-conformance-reduced/1694291170806468608

As events are generated they are placed into a cache. This cache has different filters and aggregators to avoid spamming the api server with events. The default configuration allows only 1 event every 5min to come out of the token bucket from the cache. If the same event (same reason but different message) is generated 10+ times in the latest 10min, it is aggregated into a single one with a higher count.
With this change some of those parameters are changed to allow events go through to the api server more frequently and not get aggregated (saving the original messages and not losing information).
The cache allows 4k entries, so this change does not have a significant impact in the memory footprint.

/override ci/prow/microshift-rpm-upgrade
/lgtm

authors: dhellmann pacevedom

repo: openshift/microshift


text:
Updating supervisord image to use ubi image

https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image

Seems good to me :+1:
I don't see any issue with it!
@girishramnani @surajnarwade want to have look / lgtm?

@amitkrout @surajnarwade @girishramnani Review?

/lgtm

authors: cdrage kadel mohammedzee1000

repo: openshift/odo-supervisord-image


text:
Will there be any migration path for 3.x users?

Will there be any migration path for 3.x users?

Not sure if this will be changing at some point, but the current recommendation is to do a lift-and-shift and then use tools like Velero and Restic to migrated namespaces/projects.

See https://docs.openshift.com/container-platform/4.2/migration/migrating-3-4/about-migration.html

source: gharchive/issue

authors: gratchie shinebayar-g vrutkovs

repo: openshift/okd


text:
Unable to apply 4.4.0-0.okd-2020-05-23-055148-beta5: the image may not be safe to use

Describe the bug
I've tried to update from beta 4 to beta 5 using the web console but it is failing with the following message:

Version
4.4.0-0.okd-2020-04-21-163702-beta4

Dupe of #138

So the beta's are also not signed? I thought that the issue is just for nightlies.

Correct.  I've updated the issue name to avoid confusion.

Betas are promoted nightlies

For anyone running into this error from triggering the upgrade from the OKD web interface, I posted a workaround in #138

authors: cgruver chriskuipers sapkra vrutkovs


text:
bugzilla: log error from image client

/cc @stevekuznetsov

/lgtm

authors: AlexNPavel stevekuznetsov

repo: openshift/release-controller


text:
OCM-6309 | ci: Verify test case(s) 45161|35878|35896|49137|46187|38850|34102|66362|36128

Here is the log https://privatebin.corp.redhat.com/?5575217bfbaec3ee#7dSdFKmDgqGyYznqLkBNA5xq5rhcjcQ2VtDjeVaANq2e

/assign @yasun1 @ciaranRoche @yuwang-RH @oriAdler

/lgtm
/approve

repo: openshift/rosa


text:
Bump operator sdk to 0.10.1 😅

Turns out we are still using 0.9.x, right ? The replace … bothered me :angel:
/cc @sthaha @hrishin @nikhil-thomas
Signed-off-by: Vincent Demeester vincent@sbr.pm

/lgtm

/approve

authors: nikhil-thomas vdemeester

repo: openshift/tektoncd-pipeline-operator


text:
Tison：一名 Community Builder 的自白

hi @tisonkun , please feel free to help us review this PR. And welcome to add more links about you.
By the way, I need to say a BIG thanks to @wey-gu for helping to invite @tisonkun as our guest.
close https://github.com/opensource-f2f/episode/issues/86

❤ I felt ashamed that I couldn't join this precious episode due to family reasons...

hi @tisonkun , I'm going to publish this episode if there are no more comments.

authors: LinuxSuRen wey-gu


text:
fix invalid response id after closing file

Sometimes after closing file, the server will send success message later. At this time, if we have removed response_id from SharedData, it will raise the error of invalid_response_id.

Thank you for the PR!
This is an short sight in the openssh-sftp-client, where I didn't think of this.
There's actually another fix for this:
In openssh-sftp-client, src/handle.rs, it drops the id right after sending a close request.
This is the culprit, you could change the Drop to wait for the close request by using tokio::spawn.
It will infer additional cost but IMHO might be better than ignoring any id-not-found related STATUS response.

@silver-ymz Can you please test this against the PR in opendal?

BTW, @silver-ymz do you want to become a maintainer of this crate?

@silver-ymz Can you please test this against the PR in opendal?

I will begin to make commit in opendal soon.

BTW, @silver-ymz do you want to become a maintainer of this crate?

Thank you for giving me this chance. I'd like to become a maintainer. Sometimes because of my studies I may not be able to deal with issues in time, but I will try to maintain it as much as possible.

I will begin to make commit in opendal soon.

#thumb_up

Thank you for giving me this chance. I'd like to become a maintainer.

I've invited you to become a maintainer of openssh-sftp-client, openssh-sftp-protocol, concurrent_arena and awaitable github repository.
@silver-ymz Please also provide me with your crates.io account name.
Also, if you'd like, I can ask jonhoo to invite you to the openssh-rust org, so that you can contribute to every repository under it.

Sometimes because of my studies I may not be able to deal with issues in time, but I will try to maintain it as much as possible.

That's not a problem, everyone has their own life, just enjoy and contribute when you have time.
Having another maintainer will also reduce the bus-factor of this project while also making updates/improvements more frequent/easier, and all of this is volunteer work/hobbies, I am actually grateful that you are willing to step up and become a maintainer.

Will do a release later today.

@jonhoo Can you please invite @silver-ymz to the openssh-rust org so that they have rw access (or even maintainer access) to all crates?
Thank you!

@NobodyXu invited! :tada:

Thank you!

authors: NobodyXu jonhoo silver-ymz

repo: openssh-rust/openssh-sftp-client

license: MIT


text:
OpenSSL_1_1_0i Windows Install/Compiling Bug

So... I have Strawberry Perl and NASM Installed and tried to follow the directions for installing to the best of my ability.  Here is a log of the command line and the errors.
perl Configure VC-WIN32 is successful, as is VC-WIN64... the log of that is below, but when I call nmake the very next instruction in the installation process I get an error, doesn't matter how its configured (for win32 or win64), I get the same errors below... I tried googling and the only similar article was in Chinese and they didn't really answer the guys question/problem, if you need anything else from me let me know or if you know what i'm doing wrong, please let me know, anyways the logs are below:
<<<< CONFIGURE VC-WIN32 STEP HERE <<<<
C:\Users\Admin\Desktop\openssl-OpenSSL_1_1_0i>perl Configure VC-WIN32
Configuring OpenSSL version 1.1.0i (0x1010009fL)
    no-asan         [default]  OPENSSL_NO_ASAN
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
    no-egd          [default]  OPENSSL_NO_EGD
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ssl3         [default]  OPENSSL_NO_SSL3
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
    no-zlib         [default]
    no-zlib-dynamic [default]
Configuring for VC-WIN32
CC            =cl
CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2
SHARED_CFLAG  =
DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM WHIRLPOOL_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
LFLAG         =/nologo /debug
PLIB_LFLAG    =
EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
APPS_OBJ      =win32_init.o ../ms/applink.o
CPUID_OBJ     =x86cpuid.o
UPLINK_OBJ    =../ms/uplink.o
BN_ASM        =bn-586.o co-586.o x86-mont.o x86-gf2m.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86.o
DES_ENC       =des-586.o crypt586.o
AES_ENC       =aes-586.o vpaes-x86.o aesni-x86.o
BF_ENC        =bf-586.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-586.o
RC5_ENC       =rc5-586.o
MD5_OBJ_ASM   =md5-586.o
SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
RMD160_OBJ_ASM=rmd-586.o
CMLL_ENC      =cmll-x86.o
MODES_OBJ     =ghash-x86.o
PADLOCK_OBJ   =e_padlock-x86.o
CHACHA_ENC    =chacha-x86.o
POLY1305_OBJ  =poly1305-x86.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =ranlib
ARFLAGS       =/nologo
PERL          =D:\StrawberryPerl\perl\bin\perl.exe

THIRTY_TWO_BIT mode
BN_LLONG mode

Configured for VC-WIN32.

<<<< NMAKE STEP HERE <<<<
C:\Users\Admin\Desktop\openssl-OpenSSL_1_1_0i>nmake

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

        "D:\StrawberryPerl\perl\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "crypto\include\internal\bn_conf.h.in" > crypto\include\internal\bn_conf.h
        "D:\StrawberryPerl\perl\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "crypto\include\internal\dso_conf.h.in" > crypto\include\internal\dso_conf.h
        "D:\StrawberryPerl\perl\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h
        NMAKE depend && NMAKE _all

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

        cl  /I "." /I "crypto\include" /I "include" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM "-DENGINESDIR=\"C:\\Program Files (x86)\\OpenSSL\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\Program Files (x86)\\Common Files\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 /Zi /Fdossl_static -c /Focrypto\bio\b_addr.obj "crypto\bio\b_addr.c"
Command line warning D4002 : ignoring unknown option '-wd4090'
b_addr.c
include\openssl/lhash.h(207) : warning C4022: 'OPENSSL_LH_insert' : pointer mismatch for actual parameter 2
crypto\bio\bio_lcl.h(144) : error C2061: syntax error : identifier 'BIO_ADDR_sockaddr_size'
crypto\bio\bio_lcl.h(144) : error C2059: syntax error : ';'
crypto\bio\bio_lcl.h(144) : error C2059: syntax error : 'type'
crypto\bio\bio_lcl.h(145) : error C2061: syntax error : identifier 'BIO_ADDRINFO_sockaddr_size'
crypto\bio\bio_lcl.h(145) : error C2059: syntax error : ';'
crypto\bio\bio_lcl.h(145) : error C2059: syntax error : 'type'
crypto\bio\b_addr.c(113) : error C2027: use of undefined type 'in6_addr'
        crypto\bio\b_addr.c(113) : see declaration of 'in6_addr'
crypto\bio\b_addr.c(118) : error C2115: '=' : incompatible types
crypto\bio\b_addr.c(320) : error C2061: syntax error : identifier 'BIO_ADDR_sockaddr_size'
crypto\bio\b_addr.c(320) : error C2059: syntax error : ';'
crypto\bio\b_addr.c(320) : error C2059: syntax error : 'type'
crypto\bio\b_addr.c(389) : error C2061: syntax error : identifier 'BIO_ADDRINFO_sockaddr_size'
crypto\bio\b_addr.c(389) : error C2059: syntax error : ';'
crypto\bio\b_addr.c(389) : error C2059: syntax error : 'type'
crypto\bio\b_addr.c(813) : warning C4244: 'function' : conversion from 'long ' to 'unsigned short ', possible loss of data
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\VC98\bin\NMAKE.EXE"' : return code '0x2'
Stop.

The first thing to check would be if this happen with the latest 1.1.1 version instead of 1.1.0. 1.1.0 is no longer supported.

ok... well first of all i am in need of getting this version to compile because a project im working on uses this version.  second, it appears that the problem is mostly being caused by #ifdef statements... i resolved most of the problems... however i still have a problem with it saying that in6_addr isn't defined.

well i solved the #ifdef problem and then the in6_addr problem, the problem is the struct is actually in_addr6 not in6_addr.  It might have been at one point, but now its in_addr6.  However, when trying to compile/install I got another set of errors, a longer list, and at that point I decided to look into other options and see if it's possible to use a newer release.

marking as inactive, to be closed at the end of 3.4 dev barring further input

authors: mattcaswell nhorman vbad1987

repo: openssl/openssl


text:
[Bug] 1.1.1q retrieving randomness from PRNGD

I'm having some issues retrieving randomness from PRNGD in test_ecparams. The code works fine elsewhere, but in this test, just not. This has been doing on for a few patches - I cannot determine where as the environment has changed. PRNGD is supplied by the system, but I'm wondering whether OpenSSL is supplying its own for this test. This happens regardless of the build type and platform, so x64 and ia64 are involved.
An example of this failure is:
#   Failed test at ../test/recipes/15-test_ecparam.t line 29.
checking elliptic curve parameters: failed
0:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:335:
0:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:335:
0:error:2406B072:random number generator:RAND_DRBG_generate:in error state:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:588:
0:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:335:
0:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:335:
0:error:2406B072:random number generator:RAND_DRBG_generate:in error state:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:588:
0:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:335:
0:error:2406B072:random number generator:RAND_DRBG_generate:in error state:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/rand/drbg_lib.c:588:
0:error:10089003:elliptic curve routines:ec_GFp_simple_points_make_affine:BN lib:/home/ituglib/randall/jenkins/.jenkins/workspace/OpenSSL-1.1_Pipeline/crypto/ec/ecp_smpl.c:1269:
../../util/shlib_wrap.sh ../../apps/openssl ecparam -noout -check -in ../recipes/15-test_ecparam_data/valid/secp224r1-named.pem => 1
not ok 66

I would appreciate some help in tracking this down.

One option I am considering is to down port the hardware randomizer I wrote for 3.0 back to 1.1.1, but that will not work in the ia64 platform

I don't think that that test does anything special, it's just running the openssl command line utility.
Is it picking up an odd configuration file (or not picking one up)?
It a stretch since other tests don't do anything special with configuration.
Does running it manually work?
./util/shlib_wrap.sh apps/openssl ecparam -noout -check -in test/recipes/15-test_ecparam_data/valid/secp224r1-named.pem

I don't think that that test does anything special, it's just running the openssl command line utility.
Is it picking up an odd configuration file (or not picking one up)? It a stretch since other tests don't do anything special with configuration. Does running it manually work?
./util/shlib_wrap.sh apps/openssl ecparam -noout -check -in test/recipes/15-test_ecparam_data/valid/secp224r1-named.pem

I got:
checking elliptic curve parameters: ok. So that looks ok.

Argh!  Another bit of craziness in the test harness.

Argh!  Another bit of craziness in the test harness.

Apparently, I am the canary in the coal mine: Randall, when the test breaks

Strangely, this does not work in isolated tested but works correctly when built in our Jenkins CI/CD system.

authors: paulidale rsbeckerca


text:
Regression: "make depend" now required to build OpenSSL

making all in crypto/evp...
make[5]: Entering directory `/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU12_64/zimbra-openssl/crypto/evp'
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o encode.o encode.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o digest.o digest.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o evp_enc.o evp_enc.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o evp_key.o evp_key.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o evp_acnf.o evp_acnf.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o evp_cnf.o evp_cnf.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o e_des.o e_des.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o e_bf.o e_bf.c
make[5]: *** No rule to make target `../../include/openssl/idea.h', needed by `e_idea.o'.  Stop.

duplicate of #491

Not the same as #491.  "make depend" must now be run to build, which is a regression from prior releases.

Please can you post your build steps. I don't get this behaviour, so I'm trying to figure out what's different for you.

As a side note, the three backquote syntax in Markdown require them to be on their own lines.  I just edited the starting text accordingly, and it immediately became more readable.

Just seen your note on openssl-dev - so I replied there. Summary: you are configuring with "no-idea"; therefore you do need to run "make depend"; somehow you got away with it before :-)

@quanah  got away with it because the previous tarballs had all the symlinks (made as a result of ./config without no-idea).

@mattcaswell Yeah, this worked on all prior 1.0.1, 1.0.0, and 0.9.8 builds I ever did.  So it may have been unintended that it did work, but it still comes out as a regression.  It may trip up others as well.

@levitte thanks for the cleanup!

@quanah, agreed that this is less than ideal. This should correct itself in the next release when we sort out the problem that caused the screwed up sym links in the first place. I'll leave this issue open until we've done that. Its probably not a big enough issue in itself to reissue the tarballs (again).

@mattcaswell Agreed.  I've updated my debian rules to just run make depend, and am no longer blocked on our update for Zimbra.

Want to second this. After suppressing the 'tar' failure (exit code 2), I've run into the same problem:

Correct log with 1.0.2d:
https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.130
Failure to build some parts with 1.0.2e:
https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.144

Any suggestion how to fix it? I'm already doing a make depend [1], and unsure how to proceed from there.
[1] https://github.com/vszakats/harbour-deps/blob/test/mk-openssl.bat#L30

@vszakats, from looking at https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.144#L428 ,
it doesn't look like make depend was performed...

@levitte Not sure what I'm missing, this is the sequence I'm executing since 1.0.2a (now with echo enabled):
perl Configure mingw   shared no-unit-test no-ssl2 no-ssl3 no-rc5 no-idea no-dso no-sse2 "--prefix=%CD%"
sh -c mingw32-make depend
sh -c mingw32-make

Where should the make depend line go, to work as expected?
At the moment, it appears to start doing the build. [which BTW, fails in tools/c_rehash, and the second make call makes finish the build — just noticed that now.]

Well, the log lines I pointed at look like this:
Since you've disabled or enabled at least one algorithm, you need to do
the following before building:

	make depend

Configured for mingw.
making all in crypto...
mingw32-make[1]: Entering directory 'C:/w/openssl/crypto'
C:/PROGRA~1/Git/usr/bin/perl.exe ../util/mkbuildinf.pl "gcc -I. -I.. -I../include  -D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC -DOPENSSL_THREADS -D_MT -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i686 -mtune=generic -m32 -fno-ident -flto -ffat-lto-objects -frandom-seed=1449153871 -static-libgcc -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM" "mingw" >buildinf.h

Take note that the last lines from Configure is directly followed by making all in crypto.  If your make depend line actually performed, you should have seen something approximating to this:
making depend in crypto...
make[1]: Går till katalogen ”/home/levitte/gitwrk/openssl.net/official/1.0.2/crypto”
making depend in crypto/objects...
make[2]: Entering directory '/home/levitte/gitwrk/openssl.net/official/1.0.2/crypto/objects'
../../util/domd ../.. -MD x86_64-w64-mingw32-gcc -- -D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -Wno-pedantic-ms-format -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST --  o_names.c obj_dat.c obj_lib.c obj_err.c obj_xref.c

Note the starting line making depend in crypto...
If I were you, I'd have a closer look at what actually happens with your make depend line.

I see and understand that I'm instructed to do a make depend, which is exactly what I'm executing right after Configure. But apparently, calling make depend just doesn't work:
C:\w\openssl>sh -c mingw32-make depend
making all in crypto...

The output that follows gives no hint on why depend is not recognised and performed as instructed.
Any clues or past experience on why that happens, or where to look for more information?

Shouldn't that be sh -c "mingw32-make depend", i.e. with quotes?

I think @mattcaswell nailed it.

Touché. Thanks a lot to you both! 👍🏻

Okay, in 1.1 'make depend' is required and the issues brought up for other versions and platforms seem to have been addressed in the comments.  Closing this.

authors: levitte mattcaswell quanah richsalz vszakats


text:
Thread: Avoid a NULL dereference after failed initialisation.

Uncertain if the failure should return success or failure but chose failure.
The return value from the function isn't checked and there isn't much recovery possible.
Fixes #10491

Merged to master.  Thanks.


text:
Fix d2i_PrivateKey_ex() to work as documented

d2i_PrivateKey(), and thereby d2i_PrivateKey_ex(), is documented to
return keys of the type given as first argument |type|, unconditionally.
Most specifically, the manual says this:

An error occurs if the decoded key does not match type.

However, when faced of a PKCS#8 wrapped key, |type| was ignored, which
may lead to unexpected results.

However, when faced of a PKCS#8 wrapped key, |type| was ignored, which may lead to unexpected results.

Very notably, it leads to issues with the 'file' OSSL_STORE loader, when it's asked to parse a PKCS#8 wrapped key.  Instead of getting one match for the correct tested key type, it's gets matches for all tested key types.  See the discussion in #11755

LGTM if the tests pass.

If they don't, I'll eat my virtual hat.

If they don't, I'll eat my virtual hat.

Look forward to the video :)

Looks good.  The Travis failure is about CHANGES.md, which is fixed in #11788.
(and no, that's not subject for hat eating :wink:)

Why did you put this in the "3.0 New Core + FIPS" project?  This change has nothing to do with that?

Rebased to get rid of the md-nits failure

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged
b2952366dd0248bf35c83e1736cd203033a22378 Fix d2i_PrivateKey_ex() to work as documented

Baackport to 1.1.1 in #11888

authors: levitte openssl-machine slontis


text:
DOC: Fix link to test/README.external in INSTALL.md

CLA: trivial

Checklist
NA

This pull request is ready to merge

Merged
1b495200436b57309ca958a7a72affaf75171c1a DOC: Fix link to test/README.external in INSTALL.md

authors: jcfr levitte openssl-machine


text:
EVP: Add support for delayed EVP_PKEY operation parameters

They get called "delayed parameters" because they may make it to the
implementation at a later time than when they're given.
This currently only covers the distinguished ID, as that's the only
EVP_PKEY operation parameter so far that has been possible to give
before the operation has been initialized.
This includes a re-implementation of EVP_PKEY_CTX_set1_id(),
EVP_PKEY_CTX_get1_id(), and EVP_PKEY_CTX_get1_id_len().
Also, the more rigorous controls of keytype and optype are restored.

#12536 needs this

Unfortunately, I broke 'make update'.  Fixup pushed.  Does your approval stand?

CIs are happy!

CIs look happy (why does this PR have two Travis instances???)

(why does this PR have two Travis instances???)

I've noticed this from time to time recently but not often enough to get an idea as to why.

Rebase done, rebase conflicts were trivial.  I don't think re-approval is necessary, but I'll wait for Travis to complete before merging.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

but I'll wait for Travis to complete before merging.

It completed without failure.  Time to merge

Merged
86df26b3943509219057ae87f8764b3c15e0d8b8 EVP: Add support for delayed EVP_PKEY operation parameters
b968945204130620b1328f585610cbe1d6b5a69e EVP: Expand the use of EVP_PKEY_CTX_md()
8d6481f532ab8c502de2ad17e09f688abb675a71 EVP: Move the functions and controls for setting and getting distid

authors: levitte openssl-machine paulidale


text:
ee-self-signed.pem: Restore original version, adding -attime to 25-test_verify.t

Fixup for #12549, which updated and prolonged the validity of the test certificate but turned it into a CA cert,
which defeated the purpose of the test case "accept trusted self-signed EE cert excluding key usage keyCertSign".
See also https://github.com/openssl/openssl/pull/12549#issuecomment-849478561.
Checklist

[x] tests are added or updated

This pull request is ready to merge

Merged - thanks @t8m

authors: DDvO openssl-machine


text:
apps: Print out a proper message when a store cannot be opened

Fixes #22306
This reverts some of the recent changes in load_key_certs_crls() as they were incorrect.

The second commit is only for the master branch as 3.0/3.1 do not have this code chunk.

@levitte please reconfirm

@levitte please reconfirm.

@levitte ping

ping @levitte for reconfirm or ping anybody for second review

This pull request is ready to merge

Merged to the master branch (both commits), 3.1 and 3.0 (only the first commit with the fixups). Thank you for the reviews.


text:
Add support for MLOCK_ONFAULT to secure arena

Checklist

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

errno is now checked.

Also, mlock2() is not defined in the latest glibc release..., syscall it is.

Merged. Thanks.

authors: dot-asm tmshort


text:
Move more socket stuff

The socket stuff for DJGPP and VMS was only partially moved to
include/internal/sockets.h...
Remains vxWorks.

This continues the work started in #4209

Oops, I made a mistake...  corrective commit coming up

Ok, now things seem to build everywhere.  I'll do a couple of VMS builds too, to be safe...

Ok, builds and tests fine on VMS too now.  A reconfirm would sit well at this point ;-)

reconfirm

Merged. 9a5d80cb5e and 384cdd46a1
Thank you!

authors: levitte richsalz


text:
Validate ClientHello session_id field length and send alert on failure (1.0.2)

RT#4080

+1, subject to the nit being fixed.

Nit fixed just now.

+1

+1 for matt to merge and fix it before commit.

Patch applied. Thanks.

authors: ghedo mattcaswell richsalz


text:
[WIP] Add CRC customization after start

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

recheck

recheck

How's going with this? Another related optimization https://access.redhat.com/solutions/4367311
We might want to define storage ResourceQuota for namespaces like openstack openstack-operators at least, ideally also for openshift-marketplace, metallb-system

@cjeanner FYI

Not relevant anymore.

authors: bogdando pablintino


text:
Fix missiing ifcfg device and bootproto in edpm gen

Whenever there is no device/bootproto setting present, edpm VM no longer takes expected IP address.
Add missing settings to make it working properly.

prolly not needed


text:
Revert to gnocchi 3.1.11

Revert to using an older gnocchi version for compatibility with
python-rados as provided in the Ubuntu archive for Xenial.
Support for gnocchi >= 4.0.0 needs revisting, but this at least
works for the time being.

LGTM

authors: coreycb javacruft

repo: openstack-snaps/snap-gnocchi


text:
Create table component

Tables are used to display rows of data! Include typography considerations for table headings and table body text, and collapsing/responsive table behaviors.
Include the following variations:

Row hover state
Legislative headshots where relevant
Sortable tables

I think this one is pretty good too, only thing I'm not sure about is sortable tables

authors: heyitsolivia jamesturk


text:
A half-drawn way is lost if you zoom out too far

You can zoom out too far in iD and it says "Zoom in to edit", but if you were half way through drawing a way, and you decide to zoom out to this level, then your work on the way is lost.
Usually work on one particular way doesn't represent a lot of work, but I noticed this bug when trying to trace this wiggly river for example http://www.openstreetmap.org/edit#map=16/-34.1686/146.6723  (Something which can be a lot of clicking effort, but over a wide-range, and relatively low zoom)
I guess a good fix would be to let you carry on where you left off, if you just zoom back in.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

What's supposed to happen is that there's a message saying "Cannot zoom out in current mode" and the zoom is prevented. Looks like that's working for mouse zooms but not for the +/- buttons.

I've also lost some work this way, as @harry-wood described. I feel like in the past, the error would restrict zooming out further because I used to do a hard pull on the wheel to get to max editing zoom quickly. The error message would display and halt my zoom at the right place. Hope that is helpful.

authors: harry-wood jfirebaugh talllguy

repo: openstreetmap/iD

license: ISC


text:
ID Editor does not check for WikiData entry if wikipedia entry exists but wikidata field is not present

The ID editor should include checks to make sure an entry with an wikipedia entry has a wikidata entry too and if not add wikidata. I've come across OSM objects that have a wikipedia entry, but no attached wikidata field which may be a legacy data issue. There are other entries which have an existing wikipedia field, but there is no value in the fields content and adding a page name directly to the existing field value results in no wikidata to be added. Placing a check for wikidata entry before save on pages with a wikipedia entry would ensure that these legacy data issues are corrected and that wikidata entries are associated with all pages with a wikipedia field. See such an issue realized in the discussion of https://www.openstreetmap.org/changeset/47082371

This is true - iD doesn't update existing tags.  It only adds new wikidata tags when the user actually modifies the wikipedia field.
We don't do any "silent" updating of tags because the OpenStreetMap community is not very accepting of automated edits.  There are good reasons for this - for example the existing wikipedia field might be wrong, so we wouldn't want to just fetch a corresponding wikidata value without a human actually reviewing what the field contains.
I agree with your point, and I'd also love to see all the features with Wikipedia values also contain Wikidata values.  But I don't want to add anything to silently set the tag, and I don't want to add any warnings or popups to alert mappers about the missing tag (most new mappers wouldn't care about this).  So I'm going to close this for now because this is a better feature for a data cleanup tool.

@bhousel I think there are cases when user changed an existing Wikipedia entry, in which case it would be good to add a new Wikidata item as well.  I think the behavior should be as follows:

If used edits Wikipedia tag, auto add Wikidata tag
If user simply views an object with Wikipedia but without Wikidata tag, show a bright red/yellow/suggestion icon to indicate that wikidata item CAN be added with a single click. It would also be good to show P31 (instance of) at all times, so that editor can verify that the wikipedia/wikidata item is correct.
If wikidata and wikipedia tags mismatch, there should be a visual indication/warning as well

show a bright red/yellow/suggestion icon to indicate that wikidata item CAN be added with a single click.

Isn't this just a warnings or popups to alert mappers about the missing tag?

@pnorman, not sure what you mean

This is true - iD doesn't update existing tags. It only adds new wikidata tags when the user actually modifies the wikipedia field.

@bhousel This is an issue that the modification check is not working as expected in all cases of edits to the wikipedia tag and this wikidata entries are missing. Edits that do not use the dropdown for adding the wikipedia field, but only are a value change are missed from having a wikidata field appended with a value. The request is to make sure the wikidata automatic add function correctly handles the following two cases in addition to the dropdown.
The first situation I am experiencing is to get a wikidata entry for an existing Wikipedia field a user has to delete the existing correct Wikipedia entry to use the drop down to add the same entry again for the wikidata field to populate.
The second situation is where a Wikipedia field exists, but the value is blank. Edits to this by adding a value do not populate a wikidata entry. This could be corrected with a check in ID for the edit or all objects with empty wikipedia fields should be removed from the objects. I'm not sure where the empty fields came from, but this is resulting in less complete data as ID does not auto populate a wikidata entry when a value is added.
ID should check if a field value was touched or query was made for the wikipedia lookup. If either of these cases occur then a wikidata entry should be attached. If this is the intended behavior it is not working in these cases.
This issue is not a request for a silent update nor automated edits, but did include a related thought at the end which may have detracted from the main point and should be a separate feature suggestion. The QA features to prompt users to fix the erroneous data should be split into a separate issue to be addressed including the last two bullet points made by nyurik. Though they also could be another approach to addressing the issues highlighted above and would be valuable improvements to the ID QA functionality.

Sorry @brierjon I misread the intent of the original issue.. I'll reopen and we can discuss some more about what improvements we can make.

Edits that do not use the dropdown for adding the wikipedia field, but only are a value change are missed from having a wikidata field appended with a value.

Yes, in the raw tag editor, whatever the user types is what gets saved.  iD doesn't do any extra processing on what the user inputs (aside from basic removal of whitespace and unprintable characters), and this is by design.  We expect that only advanced users who understand tags are using the raw tag editor.

The first situation I am experiencing is to get a wikidata entry for an existing Wikipedia field a user has to delete the existing correct Wikipedia entry to use the drop down to add the same entry again for the wikidata field to populate.

Maybe we could add a display of the wikidata value below the wikipedia value and, if wikidata is missing, a button to allow the user to do a lookup.

The second situation is where a Wikipedia field exists, but the value is blank. Edits to this by adding a value do not populate a wikidata entry. This could be corrected with a check in ID for the edit or all objects with empty wikipedia fields should be removed from the objects. I'm not sure where the empty fields came from, but this is resulting in less complete data as ID does not auto populate a wikidata entry when a value is added.

Ok, I just tried it and yes, this looks like a bug.  For a feature with an empty wikipedia value, I entered a wikipedia value, and it seemed to fill both wikipedia and wikidata tags, but upon leaving the feature and selecting it again, the wikidata value obviously didn't stick.

@bhouse The button solution for a missing wikipedia tag is simple and effective to correct the missing value and force a lookup. That and the correction to the behavior you confirmed we should be good.
When talking about displaying this button to generate a lookup in the "all fields" that sounds good. Following nyurik's suggestion I concur there needs to be color or other indicator that the value is missing and the button should be pushed. Once the wikidata value displays I'd recommend graying out the wikidata value and field so it can't be edited in the "all fields" view as it should be correct being generated from the wikipedia value.  While this still leaves editing possibility in the "all tags field".
Fixing the second part would solve the failure to stick wikidata issue.
As a complement to resovling the bad data with QA I put in a feature request in Osmose an issue for detecting and correcting objects missing either wikidata or wikipedia - https://github.com/osm-fr/osmose-backend/issues/191

There's a bunch going on here but the "bug" part of the lookup failing is #3987.
The rest of this issue is about letting the user know if wikidata is missing, letting them look it up, and considering adding special code to make wikidata lookup work in the raw tag editor.

moving to #4382

authors: bhousel brierjon nyurik pnorman


text:
Improve Highlighting the members of a selected relation

[x] When a relation is one of multiple selected elements, relation members are highlighted as if they were selected themselves. Instead, they should be highlighted with a different style, possibly with a yellow halo.
[x] When a relation is selected as the only element the members aren't highlighted at all. Instead they should be highlighted as suggested above.
[ ] When a relation  is selected as the only element and requires a sequence of connected member ways, endpoints of such ways should also be highlighted. They need to be eye-catching to indicate small gaps in a route or turn restriction.

@slhh Good idea to use a different color for highlighting the members when only the relation is selected. I implemented that.
Your third bullet bullet point doesn't seem as pressing as the first two. If you definitely think we should do it then I suggest opening a new issue. I find bite-sized issues much easier to address than lists like this.

authors: quincylvania slhh


text:
update imagery TMS for "Tours FR37" with OSM_Fr imagery service

Thanks and Cheers
Cyrille.

iD's list of available background imagery sources come from the editor-imagery-index project. Can you open your pull request there, and it will be included automatically the next time we release iD?  Thank you!


text:
chore: use @opensumi/vscode-ripgrep

Types

[x] 🧹 Chores

Background or solution
Changelog
use @opensumi/vscode-ripgrep

Codecov Report

Merging #270 (626b741) into v2.13.x (52a8861) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           v2.13.x     #270   +/-   ##
========================================
  Coverage    59.40%   59.40%
========================================
  Files         1180     1180
  Lines        72339    72339
  Branches     14972    14972
========================================
  Hits         42971    42971
  Misses       26764    26764
  Partials      2604     2604

Impacted Files
Coverage Δ

...ckages/file-search/src/node/file-search.service.ts
93.18% <100.00%> (ø)

packages/search/src/node/content-search.service.ts
77.53% <100.00%> (ø)

Continue to review full report at Codecov.

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

repo: opensumi/core


text:
feat: update tabbar resizeHandle logic

Types

[x] 🎉 New Features

Background or solution
用户反馈编辑器组件消失：

目前排查到结果如下：

我们通过 ToolBarActionContribution 调用 registerToolbarAction，使用 createToolbarActionBtn 往 tabbar 上挂这个编辑器按钮（调试器左边的位置）：
整体大概是这么用的：
 registry.registerToolbarAction({
      id: 'editor111',
      component: createToolbarActionBtn({
         delegate: () => {
          this.layoutService.bottomExpanded;
        }
      })
});

这个按钮会在渲染时（useEffect(, [])）调用这个 delegate 函数，函数中调用了 bottomExpanded。
bottomExpanded 调用后就会产生报错：

MainLayoutModuleContribution 中是在 initialize 生命周期中初始化的所有 slot，其中会初始化 NextBottomTabRenderer，然后该 render 内部才会把 resizeHandle 注册给 TabBar。
如果在这个 resizeHandle 被注册之前调用 bottomExpanded，就会报错。
所以在我们这个 case 下，渲染 registerToolbarAction 注册的 component 的时机比渲染底部 NextBottomTabRenderer 还早。
目前还不知道这个时序问题是怎么触发的，但 OpenSumi 这里需要容错。
Changelog
Update tabbar resizeHandle logic

Codecov Report

Merging #734 (6b2cbe0) into main (c1f829d) will decrease coverage by 0.02%.
The diff coverage is 41.02%.

@@            Coverage Diff             @@
##             main     #734      +/-   ##
==========================================
- Coverage   58.62%   58.60%   -0.03%
==========================================
  Files        1209     1209
  Lines       74811    74870      +59
  Branches    15528    15560      +32
==========================================
+ Hits        43858    43877      +19
- Misses      28216    28247      +31
- Partials     2737     2746       +9

Impacted Files
Coverage Δ

...kages/components/src/recycle-tree/tree/TreeNode.ts
77.55% <ø> (ø)

...s/main-layout/src/browser/tabbar/tabbar.service.ts
62.09% <10.52%> (-0.92%)
:arrow_down:

...xt/src/browser/services/file-tree-model.service.ts
53.91% <19.04%> (+0.07%)
:arrow_up:

...file-tree-next/src/common/file-tree-node.define.ts
64.86% <57.14%> (-2.94%)
:arrow_down:

...components/src/recycle-tree/prompt/PromptHandle.ts
89.54% <70.00%> (-1.37%)
:arrow_down:

...es/file-tree-next/src/browser/file-tree.service.ts
62.44% <75.00%> (+0.53%)
:arrow_up:

packages/core-browser/src/bootstrap/app.ts
64.66% <100.00%> (ø)

...xtension/src/browser/vscode/api/main.thread.env.ts
85.50% <100.00%> (ø)

...next/src/browser/services/file-tree-api.service.ts
57.85% <100.00%> (-1.18%)
:arrow_down:

...erences/src/browser/preference-settings.service.ts
74.19% <0.00%> (-4.98%)
:arrow_down:

... and 12 more

Continue to review full report at Codecov.

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

authors: bytemain codecov-commenter


text:
fix: queue RecycleTree render progress

Types

[x] 🐛 Bug Fixes

Background or solution
将 RecycleTree 的渲染操作队列化，杜绝出现并发渲染问题
Changelog
queue RecycleTree render progress

/publish

/publish

Codecov Report

Merging #866 (29af4ec) into v2.16 (73a869a) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            v2.16     #866   +/-   ##
=======================================
  Coverage   58.98%   58.98%
=======================================
  Files        1208     1208
  Lines       74810    74810
  Branches    15541    15541
=======================================
+ Hits        44127    44130    +3
+ Misses      27968    27965    -3
  Partials     2715     2715

Impacted Files
Coverage Δ

...ages/file-service/src/node/file-service-watcher.ts
70.55% <0.00%> (+1.66%)
:arrow_up:

Continue to review full report at Codecov.

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

/publish

/publish

/publish

/publish

/publish

/publish

优化效果（本地 10W + 文件每 100 ms 添加情况文件操作）：
https://user-images.githubusercontent.com/9823838/164955271-f58b2d27-ad11-486d-9cc3-e230b2c59ef9.mp4

本 PR 主要解决下面三种场景下的异常问题：

问题一
在频繁发生刷新操作的情况下，本身 Tree 的渲染会根据事件进行刷新，从而触发 flattenedBranch -> id -> Node 的索引，因为节点默认获取到状态为 “非展开” 状态

故出现了，滚动 -> 文件树更新 -> 重新获取 TreeNode 节点 -> 获取到了折叠状态的节点
2.问题二
在出现慢刷新任务的情况下，如存在一个 10W+ 文件存在的 node_modules 情况（CloudIDE 环境下更多为容器请求缓慢的情况） ，由于刷新会首先将 根节点的 flattenedBranch 恢复到初始状态，如果此时出现了文件定位指令的执行，如 展开 a/b/c/d.ts ，这时由于 a 文件在 pathToNode 数据中已被更新展开状态为 false 的情况，故触发了文件树中 a  目录的逐级展开任务，而该任务执行的情况下，可能遇到上一次刷新任务剩余的 a 路径的展开任务影响出现并发的展开操作，最终造成重复文件问题。
3.问题三
在展开的目录包含 a, b, c 的情况下，由于 a 目录的加载速度较慢，刷新过程中还在加载，此时点击了视图中展开状态为 true 实际数据结构为 false 的 a 目录文件，导致在调用 toggleDirectory 时根据 TreeNode 的展开状态判断，又执行了一次 setExpand 操作，即这种情况下总共会触发下面两种方式的展开：

hardReloadChildren + this.isExpanded = true
setExpand

核心原因
文件树刷新、展开、定位等操作可能对（idToTreeNode，pathToTreeNode，flattenedBranch， branchSize ）等对渲染息息相关的数据产生影响，而由于更新的问题不能在用户视图中没有被及时展示（也没办法做展示），最终导致一系列问题。

整体操作优先级：
展开/折叠 > 定位 >  刷新
冲突情况处理：

在刷新的过程中展开及折叠文件树的情况如下所示：

在刷新过程中发生文件定位的情况如下所示：

在刷新过程中发生文件定位，又发生展开操作的情况如下所示：

整体使用上的变化：

创建节点的方式更简单，无需再顾虑缓存及 ID 创建问题，相关逻辑已在 Tree 内部逻辑处理
调用 Refresh, expandNode/collapseNode, ensureVisible 等文件操作方法无需顾虑时序问题，内部处理
如果需要创建默认展开的树节点，支持如下两种方式：

a. 通过设置节点 expanded = true 的方式，这种方式设置后节点将不能被折叠，伪代码如下：
Class DemoTreeNode extends TreeNode {
  ...
  get expanded() {
    return true;
  }
  ...

}

b. 通过设置节点 isExpanded = true 的方式，这种方式设置后节点能正常被折叠展开，只是默认为展开状态，伪代码如下：
Class DemoTreeNode extends TreeNode {
  ...
  constructor() {
    this.isExpanded = true;
  }
  ...

}

/publish

/publish

/publish

 FAIL  packages/file-tree-next/__tests__/browser/file-tree.test.ts (39.913 s)
  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Expand and collapse Directory should be work

    expect(received).toBeFalsy()

    Received: true

      268 |       expect(rootNode.branchSize).toBe(filesMap.length + 1);
      269 |       await directoryNode.setCollapsed();
    > 270 |       expect(directoryNode.expanded).toBeFalsy();
          |                                      ^
      271 |       expect(rootNode.branchSize).toBe(filesMap.length);
      272 |       // clean effect
      273 |       await fs.remove(path.join(directoryNode.uri.path.toString(), 'child_file'));

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:270:38)

  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Symbolic file should be create with correct decoration and file stat

    expect(received).toBe(expected) // Object.is equality

    Expected: 4
    Received: 5

      288 |         const symbolicNode = rootNode.children?.find((child: File) => child.filestat.isSymbolicLink) as File;
      289 |         const decoration = decorationService.getDecoration(symbolicNode.uri, symbolicNode.filestat.isDirectory);
    > 290 |         expect(rootNode.branchSize).toBe(filesMap.length + 1);
          |                                     ^
      291 |         expect(decoration.color).toBe('gitDecoration.ignoredResourceForeground');
      292 |         expect(decoration.badge).toBe('⤷');
      293 |         fs.removeSync(path.join(root.path.toString(), '0_symbolic_file'));

      at packages/file-tree-next/__tests__/browser/file-tree.test.ts:290:37
      at Emitter.fire (packages/components/src/utils/event.ts:578:20)
      at FileTreeService.doHandleQueueChange.leading (packages/file-tree-next/src/browser/file-tree.service.ts:782:37)

  ● FileTree should be work while on single workspace model › 03 #DragAndDrop Service should be work › Start Dragging with single selected node

    expect(jest.fn()).toBeCalled()

    Expected number of calls: >= 1
    Received number of calls:    0

      548 |       expect(mockEvent.stopPropagation).toBeCalled();
      549 |       expect(mockEvent.dataTransfer.setDragImage).toBeCalled();
    > 550 |       expect(mockEvent.dataTransfer.setData).toBeCalled();
          |                                              ^
      551 |       done();
      552 |     });
      553 |

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:550:46)

Summary of all failing tests
 FAIL  packages/file-tree-next/__tests__/browser/file-tree.test.ts (39.913 s)
  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Expand and collapse Directory should be work

    expect(received).toBeFalsy()

    Received: true

      268 |       expect(rootNode.branchSize).toBe(filesMap.length + 1);
      269 |       await directoryNode.setCollapsed();
    > 270 |       expect(directoryNode.expanded).toBeFalsy();
          |                                      ^
      271 |       expect(rootNode.branchSize).toBe(filesMap.length);
      272 |       // clean effect
      273 |       await fs.remove(path.join(directoryNode.uri.path.toString(), 'child_file'));

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:270:38)

  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Symbolic file should be create with correct decoration and file stat

    expect(received).toBe(expected) // Object.is equality

    Expected: 4
    Received: 5

      288 |         const symbolicNode = rootNode.children?.find((child: File) => child.filestat.isSymbolicLink) as File;
      289 |         const decoration = decorationService.getDecoration(symbolicNode.uri, symbolicNode.filestat.isDirectory);
    > 290 |         expect(rootNode.branchSize).toBe(filesMap.length + 1);
          |                                     ^
      291 |         expect(decoration.color).toBe('gitDecoration.ignoredResourceForeground');
      292 |         expect(decoration.badge).toBe('⤷');
      293 |         fs.removeSync(path.join(root.path.toString(), '0_symbolic_file'));

      at packages/file-tree-next/__tests__/browser/file-tree.test.ts:290:37
      at Emitter.fire (packages/components/src/utils/event.ts:578:20)
      at FileTreeService.doHandleQueueChange.leading (packages/file-tree-next/src/browser/file-tree.service.ts:782:37)

  ● FileTree should be work while on single workspace model › 03 #DragAndDrop Service should be work › Start Dragging with single selected node

    expect(jest.fn()).toBeCalled()

    Expected number of calls: >= 1
    Received number of calls:    0

      548 |       expect(mockEvent.stopPropagation).toBeCalled();
      549 |       expect(mockEvent.dataTransfer.setDragImage).toBeCalled();
    > 550 |       expect(mockEvent.dataTransfer.setData).toBeCalled();
          |                                              ^
      551 |       done();
      552 |     });
      553 |

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:550:46)

Test Suites: 1 failed, 10 passed, 11 of 285 total
Tests:       3 failed, 1 skipped, 310 passed, 314 total
Snapshots:   0 total

 FAIL  packages/file-tree-next/__tests__/browser/file-tree.test.ts (64.576 s)
  ● FileTree should be work while on single workspace model › 04 #Compact Mode should be work › Directory should be compressed while it contain single file

    expect(received).toBeTruthy()

    Received: false

      652 |         dispose.dispose();
      653 |         const directoryNode = rootNode.getTreeNodeAtIndex(0) as Directory;
    > 654 |         expect(directoryNode.expanded).toBeTruthy();
          |                                        ^
      655 |         // cause the directory was compressed, branchSize will not increase
      656 |         expect(rootNode.branchSize).toBe(filesMap.length);
      657 |         expect(directoryNode.name).toBe(`${preNodeName}/a/b`);

      at packages/file-tree-next/__tests__/browser/file-tree.test.ts:654:40
      at Emitter.fire (packages/components/src/utils/event.ts:578:20)
      at FileTreeService.doHandleQueueChange.leading (packages/file-tree-next/src/browser/file-tree.service.ts:782:37)
      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:660:7)

Summary of all failing tests
 FAIL  packages/file-tree-next/__tests__/browser/file-tree.test.ts (64.576 s)
  ● FileTree should be work while on single workspace model › 04 #Compact Mode should be work › Directory should be compressed while it contain single file

    expect(received).toBeTruthy()

    Received: false

      652 |         dispose.dispose();
      653 |         const directoryNode = rootNode.getTreeNodeAtIndex(0) as Directory;
    > 654 |         expect(directoryNode.expanded).toBeTruthy();
          |                                        ^
      655 |         // cause the directory was compressed, branchSize will not increase
      656 |         expect(rootNode.branchSize).toBe(filesMap.length);
      657 |         expect(directoryNode.name).toBe(`${preNodeName}/a/b`);

      at packages/file-tree-next/__tests__/browser/file-tree.test.ts:654:40
      at Emitter.fire (packages/components/src/utils/event.ts:578:20)
      at FileTreeService.doHandleQueueChange.leading (packages/file-tree-next/src/browser/file-tree.service.ts:782:37)
      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:660:7)

Test Suites: 1 failed, 10 passed, 11 of 285 total
Tests:       1 failed, 313 passed, 314 total

Summary of all failing tests
 FAIL  packages/components/__tests__/recycle-tree/tree/TreeNode.test.ts
  ● Test suite failed to run

    packages/components/__tests__/recycle-tree/tree/TreeNode.test.ts:180:29 - error TS2339: Property 'forceLoadTreeNodeAtPath' does not exist on type 'Root'.

    180     const node = await root.forceLoadTreeNodeAtPath('a/c');
                                    ~~~~~~~~~~~~~~~~~~~~~~~

 FAIL  packages/file-service/__tests__/browser/file-service-client.test.ts
  ● FileServiceClient should be work › watch file change

    expect(received).toBe(expected) // Object.is equality

    Expected: "file:///private/var/folders/qf/3s9n2rdx79z_6chlyx45n_cm0000gn/T/file-service-client-test2022325-56626-fr2xpe.qx5z/temp-dir5"
    Received: "file:///private/var/folders/qf/3s9n2rdx79z_6chlyx45n_cm0000gn/T/file-service-client-test2022325-56626-fr2xpe.qx5z/temp-dir2"

      131 |     const targetDir = tempDir.resolve('temp-dir5');
      132 |     watcher.onFilesChanged(async (event) => {
    > 133 |       expect(event[0].uri).toBe(targetDir.toString());
          |                            ^
      134 |       await fileServiceClient.unwatchFileChanges(watcher.watchId);
      135 |       watcher.dispose();
      136 |       done();

      at packages/file-service/__tests__/browser/file-service-client.test.ts:133:28
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at packages/file-service/src/browser/watcher.ts:31:28
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at FileServiceClient.fireFilesChange (packages/file-service/src/browser/file-service-client.ts:323:26)
      at packages/file-service/src/browser/file-service-client.ts:441:61
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at Object.onDidFilesChanged (packages/file-service/src/node/disk-file-system.provider.ts:346:34)
      at NsfwFileSystemWatcherServer.doFireDidFilesChanged (packages/file-service/src/node/file-service-watcher.ts:349:19)
      at NsfwFileSystemWatcherServer.<anonymous> (packages/file-service/src/node/file-service-watcher.ts:343:76)

  ● FileServiceClient should be work › delete file

    expect(received).toBe(expected) // Object.is equality

    Expected: "file:///private/var/folders/qf/3s9n2rdx79z_6chlyx45n_cm0000gn/T/file-service-client-test2022325-56626-fr2xpe.qx5z/temp-dir5"
    Received: "file:///private/var/folders/qf/3s9n2rdx79z_6chlyx45n_cm0000gn/T/file-service-client-test2022325-56626-fr2xpe.qx5z/watch-file-exclude-temp-dir"

      131 |     const targetDir = tempDir.resolve('temp-dir5');
      132 |     watcher.onFilesChanged(async (event) => {
    > 133 |       expect(event[0].uri).toBe(targetDir.toString());
          |                            ^
      134 |       await fileServiceClient.unwatchFileChanges(watcher.watchId);
      135 |       watcher.dispose();
      136 |       done();

      at packages/file-service/__tests__/browser/file-service-client.test.ts:133:28
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at packages/file-service/src/browser/watcher.ts:31:28
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at FileServiceClient.fireFilesChange (packages/file-service/src/browser/file-service-client.ts:323:26)
      at packages/file-service/src/browser/file-service-client.ts:441:61
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at Object.onDidFilesChanged (packages/file-service/src/node/disk-file-system.provider.ts:346:34)
      at NsfwFileSystemWatcherServer.doFireDidFilesChanged (packages/file-service/src/node/file-service-watcher.ts:349:19)
      at NsfwFileSystemWatcherServer.<anonymous> (packages/file-service/src/node/file-service-watcher.ts:343:76)

Test Suites: 2 failed, 1 skipped, 72 passed, 74 of 285 total
Tests:       2 failed, 27 skipped, 1687 passed, 1716 total
Snapshots:   0 total
Time:        62.826 s

Summary of all failing tests
 FAIL  packages/file-tree-next/__tests__/browser/file-tree-contribution.test.ts (5.314 s)
  ● FileTreeContribution › 01 #contribution should be work › should onStart be work

    expect(jest.fn()).toBeCalledTimes(expected)

    Expected number of calls: 1
    Received number of calls: 0

      143 |       const contribution = mockInjector.get(FileTreeContribution);
      144 |       await contribution.onStart();
    > 145 |       expect(mockFileTreeService.init).toBeCalledTimes(1);
          |                                        ^
      146 |       expect(mockMainLayoutService.collectViewComponent).toBeCalledTimes(1);
      147 |       await onWorkspaceLocationChangedEmitter.fireAndAwait(undefined);
      148 |       const handler = tabbarHandlerMap.get(ExplorerContainerId);

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree-contribution.test.ts:145:40)

Test Suites: 1 failed, 1 skipped, 78 passed, 79 of 285 total
Tests:       1 failed, 29 skipped, 1741 passed, 1771 total
Snapshots:   0 total
Time:        67.984 s

Summary of all failing tests
 FAIL  packages/file-service/__tests__/browser/file-service-client.test.ts
  ● FileServiceClient should be work › set watchExcludes

    expect(received).toBeTruthy()

    Received: false

      155 |     const watcher = await fileServiceClient.watchFileChanges(targetDir);
      156 |     watcher.onFilesChanged(async (event) => {
    > 157 |       expect(!!event.find((e) => e.uri === targetDir.resolve('abc.js').toString())).toBeTruthy();
          |                                                                                ^
      158 |       expect(!!event.find((e) => e.uri === targetDir.resolve('test').toString())).toBeFalsy();
      159 |       await fileServiceClient.unwatchFileChanges(watcher.watchId);
      160 |       watcher.dispose();

      at packages/file-service/__tests__/browser/file-service-client.test.ts:157:85
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at packages/file-service/src/browser/watcher.ts:31:28
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at FileServiceClient.fireFilesChange (packages/file-service/src/browser/file-service-client.ts:323:26)
      at packages/file-service/src/browser/file-service-client.ts:441:61
      at Emitter.fire (packages/core-common/src/event.ts:609:22)
      at Object.onDidFilesChanged (packages/file-service/src/node/disk-file-system.provider.ts:346:34)
      at NsfwFileSystemWatcherServer.doFireDidFilesChanged (packages/file-service/src/node/file-service-watcher.ts:349:19)
      at NsfwFileSystemWatcherServer.<anonymous> (packages/file-service/src/node/file-service-watcher.ts:343:76)

 FAIL  packages/outline/__tests__/browser/services/outline-tree.service.test.ts (10.94 s)
  ● OutlineTreeService › sortComparator method should be work

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: -1

      89 |     // sort by position
      90 |     let res = outlineTreeService.sortComparator(newTreeNode('a'), newTreeNode('a', 0, true));
    > 91 |     expect(res).toBe(0);
         |                 ^
      92 |     res = outlineTreeService.sortComparator(newTreeNode('a'), newTreeNode('b'));
      93 |     expect(res).toBeLessThan(0);
      94 |     res = outlineTreeService.sortComparator(newTreeNode('a', 0, true), newTreeNode('b', 0, true));

      at Object.<anonymous> (packages/outline/__tests__/browser/services/outline-tree.service.test.ts:91:17)

  ● OutlineTreeService › onDidChange should emit while sortType change

    : Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error:

      106 |   });
      107 |
    > 108 |   it('onDidChange should emit while sortType change', async (done) => {
          |   ^
      109 |     outlineTreeService.onDidChange(() => {
      110 |       done();
      111 |     });

      at new Spec (node_modules/jest-jasmine2/build/jasmine/Spec.js:116:22)
      at Suite.<anonymous> (packages/outline/__tests__/browser/services/outline-tree.service.test.ts:108:3)

 FAIL  packages/debug/__tests__/browser/view/console/debug-console.view.test.tsx
  ● Test suite failed to run

    Jest worker encountered 4 child process exceptions, exceeding retry limit

      at ChildProcessWorker.initialize (node_modules/jest-worker/build/workers/ChildProcessWorker.js:185:21)

 FAIL  packages/terminal-next/__tests__/node/terminal.service.client.test.ts (22.116 s)
  ● TerminalServiceClientImpl › Should be disposed.

    : Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error:

      80 |   });
      81 |
    > 82 |   it.only('Should be disposed.', async () => {
         |      ^
      83 |     (process as any).env.IS_DEV = 0;
      84 |     const mockId = '2';
      85 |     await terminalServiceClient.create2(mockId, 200, 200, {

      at new Spec (node_modules/jest-jasmine2/build/jasmine/Spec.js:116:22)
      at Suite.<anonymous> (packages/terminal-next/__tests__/node/terminal.service.client.test.ts:82:6)

 FAIL  packages/outline/__tests__/browser/outline-node.define.test.ts
  ● Test suite failed to run

    packages/outline/__tests__/browser/outline-node.define.test.ts:51:17 - error TS2339: Property 'whenReady' does not exist on type 'OutlineCompositeTreeNode'.

    51     expect(node.whenReady).toBeDefined();
                       ~~~~~~~~~

 FAIL  packages/terminal-next/__tests__/node/pty.test.ts (31.953 s)
  ● PtyService function should be valid › cannot create a invalid shell case1

    : Timeout - Async callback was not invoked within the 10000 ms timeout specified by jest.setTimeout.Timeout - Async callback was not invoked within the 10000 ms timeout specified by jest.setTimeout.Error:

      23 |   });
      24 |
    > 25 |   it('cannot create a invalid shell case1', async () => {
         |   ^
      26 |     const ptyService = injector.get(PtyService, ['0', { executable: '' }, 200, 200]);
      27 |     const error = await ptyService.start();
      28 |     expect(error?.message).toEqual('IShellLaunchConfig.executable not set');

      at new Spec (node_modules/jest-jasmine2/build/jasmine/Spec.js:116:22)
      at Suite.<anonymous> (packages/terminal-next/__tests__/node/pty.test.ts:25:3)

 FAIL  packages/extension/__tests__/node/extension.host.manager.test.ts (41.596 s)
  ● /Users/artin/0Ant/opensumi/2.16/packages/extension/__tests__/node/extension.host.manager.common-tester.ts › send message

    expect(received).toBe(expected) // Object.is equality

    Expected: "finish"
    Received: "ready"

      58 |       await sleep(2000);
      59 |       extensionHostManager.onMessage(pid, (message) => {
    > 60 |         expect(message).toBe('finish');
         |                         ^
      61 |         done();
      62 |       });
      63 |       await extensionHostManager.send(pid, 'close');

      at ChildProcess.<anonymous> (packages/extension/__tests__/node/extension.host.manager.common-tester.ts:60:25)

Test Suites: 7 failed, 3 skipped, 275 passed, 282 of 285 total
Tests:       6 failed, 61 skipped, 2552 passed, 2619 total

本地跑完了，就这些报错

Summary of all failing tests
 FAIL  packages/file-tree-next/__tests__/browser/file-tree.test.ts (56.71 s)
  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Expand and collapse Directory should be work

    expect(received).toBeFalsy()

    Received: true

      268 |       expect(rootNode.branchSize).toBe(filesMap.length + 1);
      269 |       await directoryNode.setCollapsed();
    > 270 |       expect(directoryNode.expanded).toBeFalsy();
          |                                      ^
      271 |       expect(rootNode.branchSize).toBe(filesMap.length);
      272 |       // clean effect
      273 |       await fs.remove(path.join(directoryNode.uri.path.toString(), 'child_file'));

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:270:38)

  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Symbolic file should be create with correct decoration and file stat

    expect(received).toBe(expected) // Object.is equality

    Expected: 4
    Received: 5

      288 |         const symbolicNode = rootNode.children?.find((child: File) => child.filestat.isSymbolicLink) as File;
      289 |         const decoration = decorationService.getDecoration(symbolicNode.uri, symbolicNode.filestat.isDirectory);
    > 290 |         expect(rootNode.branchSize).toBe(filesMap.length + 1);
          |                                     ^
      291 |         expect(decoration.color).toBe('gitDecoration.ignoredResourceForeground');
      292 |         expect(decoration.badge).toBe('⤷');
      293 |         fs.removeSync(path.join(root.path.toString(), '0_symbolic_file'));

      at packages/file-tree-next/__tests__/browser/file-tree.test.ts:290:37
      at Emitter.fire (packages/components/src/utils/event.ts:578:20)
      at FileTreeService.doHandleQueueChange.leading (packages/file-tree-next/src/browser/file-tree.service.ts:782:37)

  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Location file should be work

    expect(received).toEqual(expected) // deep equality

    - Expected  - 3
    + Received  + 1

    - Array [
    -   "mod_selected",
    - ]
    + Array []

      398 |       );
      399 |       const fileDecoration = decorations.getDecorations(fileNode);
    > 400 |       expect(fileDecoration?.classlist).toEqual([styles.mod_selected]);
          |                                         ^
      401 |       done();
      402 |     });
      403 |

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:400:41)

  ● FileTree should be work while on single workspace model › 02 #Basic API should be worked › Location file should be work while fileTree can be see

    expect(received).toEqual(expected) // deep equality

    - Expected  - 3
    + Received  + 1

    - Array [
    -   "mod_selected",
    - ]
    + Array []

      417 |       );
      418 |       const fileDecoration = decorations.getDecorations(fileNode);
    > 419 |       expect(fileDecoration?.classlist).toEqual([styles.mod_selected]);
          |                                         ^
      420 |       done();
      421 |     });
      422 |

      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:419:41)

  ● FileTree should be work while on single workspace model › 04 #Compact Mode should be work › Directory should be compressed while it contain single file

    expect(received).toBe(expected) // Object.is equality

    Expected: 3
    Received: 8

      654 |         expect(directoryNode.expanded).toBeTruthy();
      655 |         // cause the directory was compressed, branchSize will not increase
    > 656 |         expect(rootNode.branchSize).toBe(filesMap.length);
          |                                     ^
      657 |         expect(directoryNode.name).toBe(`${preNodeName}/a/b`);
      658 |         done();
      659 |       });

      at packages/file-tree-next/__tests__/browser/file-tree.test.ts:656:37
      at Emitter.fire (packages/components/src/utils/event.ts:578:20)
      at FileTreeService.doHandleQueueChange.leading (packages/file-tree-next/src/browser/file-tree.service.ts:782:37)
      at Object.<anonymous> (packages/file-tree-next/__tests__/browser/file-tree.test.ts:660:7)

 FAIL  packages/debug/__tests__/browser/view/console/debug-console.view.test.tsx
  ● Test suite failed to run

    Jest worker encountered 4 child process exceptions, exceeding retry limit

      at ChildProcessWorker.initialize (node_modules/jest-worker/build/workers/ChildProcessWorker.js:185:21)

 FAIL  packages/terminal-next/__tests__/node/terminal.service.client.test.ts (14.584 s)
  ● TerminalServiceClientImpl › Should be disposed.

    : Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error:

      80 |   });
      81 |
    > 82 |   it.only('Should be disposed.', async () => {
         |      ^
      83 |     (process as any).env.IS_DEV = 0;
      84 |     const mockId = '2';
      85 |     await terminalServiceClient.create2(mockId, 200, 200, {

      at new Spec (node_modules/jest-jasmine2/build/jasmine/Spec.js:116:22)
      at Suite.<anonymous> (packages/terminal-next/__tests__/node/terminal.service.client.test.ts:82:6)

authors: bytemain codecov-commenter erha19


text:
ADR: obligations implementation path

Table of Contents

Background
Option 1: Obligations as a separate policy construct
Option 2: Obligations via flag within existing attributes as previously detailed
Level of Effort
Pros/Cons

Background
Relevant ADR: https://github.com/opentdf/platform/issues/874
Relevant implementation issue: https://github.com/opentdf/platform/issues/1260
Example PEP obligations once Subject entity found to be entitled in a data access decision:

watermark
change-all-images-to-ducks
make-font-size-20

Option 1: Obligations as a separate policy construct

separate FQN for obligations https://<namespace>/oblg/<name>
no parent/child relationship among obligations (they're flat and distinct from one another) but nothing stops you from naming it https://namespace/oblg/drm:watermark
no rule like attributes, or implicit anyOf rule like we've discussed

erDiagram
    obligations {
        uuid id
        uuid namespace_id FK
        string name
        jsonb feature_context "demonstration: we could add robust feature context to an obligation like an expiration timestamp in whatever new columns"
        jsonb metadata "conventional policy metadata labels key/value store"
        compIdx      comp_key     UK "namespace_id + name"
    }

    obligation_assignments {
        uuid id
        uuid obligation_id
        uuid attribute_value_id
    }

    obligation_fulfillments {
        uuid id
        uuid obligation_id
        enum entity_scope "subject | environment"
        jsonb fulfillment_conditions "condition sets not tied to subjects"
        jsonb metadata "conventional policy metadata labels key/value store"
    }

    attribute_values {
        uuid         id                      PK "abbreviated table"
        uuid         attribute_definition_id FK
        varchar      value
    }

    namespaces {
        uuid        id   PK
        varchar     name UK
    }

    attribute_definitions {
        uuid         id           PK "abbreviated table"
        uuid         namespace_id FK
        varchar      name
        enum         rule
    }

    namespaces ||--|{ attribute_definitions : has
    namespaces ||--|{ obligations : has
    attribute_definitions ||--|{ attribute_values : has
    obligations ||--o{ obligation_assignments : links
    attribute_values ||--o{ obligation_assignments : links
    obligations ||--o{ obligation_fulfillments : "fulfilled by"

    %% abbreviations
    subject_mappings ||--o{ attribute_values : entitles
    subject_condition_sets ||--o{ subject_mappings : relates
        kas_val_grants ||--o{ attribute_values : grants
    kas_attr_grants ||--o{ attribute_definitions : grants

Policy work:

new obligations table
new obligation_assignments table linking derived obligations and attribute_values
new obligation_fulfillments table
obligation fulfillment conditions protos (not purely subject-oriented, so can't reuse SCS from entitlements/SubjectMappings without breaking changes)
CRUD RPCs and db functions for:

CRUD obligations
assign/unassign obligations to attribute values
CRUD obligation_fulfillments for obligations

tests for db CRUD of obligations, assignments, fulfillments
docs for CRUD of obligations, assignments, fulfillments
FQN lookup for obligation values (reuses existing FQNs table?) https://namespace/oblg/<name>, i.e. https://demo.com/oblg/drm:watermark or demo.com/oblg/readonly
obligations RPCs/service rolled up into policy with dedicated casbin policy
new CLI CRUD support for obligations:

CRUD obligations
assign/unassign obligations to attribute values
CRUD obligation_fulfillments for obligations

Value protos are updated to include derived obligations
GetAttributesByValueFQNs adds support in protos/db to return derived obligations for values
GetObligationsByFQNs (new RPC) expects obligation FQN structure and returns obligation fulfillment conditions

Authz/KAS/SDK work:

Read derived obligations from resource attributes
Contextualize obligations on TDF data policy
Logic/tests to resolve obligation condition logic
SDK must allow obligation-FQN-structure strings alongside data attribute FQN strings
TODO: AccessPDP resolves obligation fulfillments as scoped (multiple obligations/multiple entities = what behavior?)
GetDecisions calls AccessPDP correctly and returns obligations correctly
KAS returns obligations along with /rewrap
JS SDK support for obligations in response?
Go SDK support for obligations in response?

Option 2: Obligations via flag within existing attributes as previously detailed
erDiagram

    obligation_assignments {
        uuid id
        uuid obligation_attribute_value_id
        uuid data_attribute_value_id
    }

    obligation_fulfillments {
        uuid id
        uuid obligation_attribute_value_id
        enum entity_scope "subject | environment"
        jsonb fulfillment_conditions "condition sets not tied to subjects"
        jsonb metadata "conventional policy metadata labels key/value store"
    }

    attribute_values {
        uuid         id                      PK
        uuid         attribute_definition_id FK
        varchar      value
        jsonb        metadata
        compIdx      comp_key                UK "ns_id + ad_id + value"
    }

    namespaces {
        uuid        id   PK
        varchar     name UK
    }

    attribute_definitions {
        uuid         id           PK
        uuid         namespace_id FK
        varchar      name
        enum        type "data | obligation"
        enum         rule "enforced by policy services to be anyOf if obligation type"
        jsonb        metadata
        compIdx      comp_key     UK "ns_id + name"
    }

    namespaces ||--|{ attribute_definitions : has
    attribute_definitions ||--|{ attribute_values : has
    attribute_values ||--o{ obligation_assignments : "data attr val -> 1+ obligations"
    obligation_assignments ||--o{ attribute_values : "obligation -> 1+ data attr vals"
    attribute_values ||--o{ obligation_fulfillments : "IFF obligation, fulfills"

    %% abbreviations
    subject_mappings ||--o{ attribute_values : "IFF data attr def val, entitles"
    subject_condition_sets ||--o{ subject_mappings : relates
    kas_val_grants ||--o{ attribute_values : "IFF data attr def val, grants"
    kas_attr_grants ||--o{ attribute_definitions : "IFF data attr def val, grants"

Policy work

policy database migration to:

add type ENUM('data','obligation')
write all current platform attributes to the 'data' type

new obligation_assignments table linking derived obligation_attribute_values and data_attribute_values

new obligation_fulfillments table

Update attributes CRUD to support obligations via type enum flag

Create

attributes are implicitly defaulted 'data' type unless defined as 'obligation'
accept type on Create in attr definition protos/rpcs
implicitly default anyOf rule only on 'obligation' type Create, or decide to enforce 'anyOf' and fail?
Update proto comments about two types of attributes and what they mean
tests + docs

GET/LIST

Update Value to query derived obligations from DB and set in response IFF 'data' attribute
Update Value proto to provide obligation_fulfillments IFF 'obligation' attribute
Update Definition proto to provide obligation type in response
tests + docs

UNSAFE

enforce cannot change rule on an obligation-type attribute (unless we want to support rules in obligations other than anyOf?)
tests + docs

Update other policy CRUD to differentiate between attribute types

subject mappings

Create must fail if mapped to an obligation-type attribute value
Update must fail if mapped to an obligation-type attribute value
tests + docs

resource mappings

Create must fail if mapped to an obligation-type attribute value
Update must fail if mapped to an obligation-type attribute value
tests + docs

KAS grants to attribute definitions

Create must fail if mapped to an obligation-type attribute value
Update must fail if mapped to an obligation-type attribute value
tests + docs

KAS grants to attribute values

Create must fail if mapped to an obligation-type attribute value
Update must fail if mapped to an obligation-type attribute value
tests + docs

obligation fulfillment conditions protos (not purely subject-oriented, so can't reuse subject condition sets without breaking changes)

FQN lookup for obligation values (no change) https://namespace/attr/obligation_name/value/<value>, i.e. https://demo.com/attr/drm/value/watermark

CLI CRUD for obligations (still separate subcommands to improve documentation specificity and clarity)

CRUD obligations via policy attribute RPCs under the hood
assign/unassign obligations to attribute values
CRUD obligation_fulfillments to obligation_values

Hide obligation type attributes/values from existing CLI CRUD of those policy objects

docs/tests for new CRUD behaviors (assignments, fulfillments)

Value protos are updated to include derived obligations

GetAttributesByValueFQNs adds support in protos/db to return derived obligations for values

GetAttributesByValueFQNs is updated to have a different response if the requested FQN was an obligation-type attribute value

Authz/KAS/SDK work:

Read derived obligations from resource attributes
Contextualize obligations on TDF data policy
Logic/tests to resolve obligation condition logic
TODO: AccessPDP resolves fulfillment conditions by scope (multiple obligations/multiple entities = what behavior?)
GetDecisions calls AccessPDP correctly and returns obligations correctly
KAS returns obligations along with /rewrap
JS SDK support for obligations in response?
Go SDK support for obligations in response?

Level of Effort (LOE) cost comparison to implement, maintain, understand, and develop

Path 1: Distinctly Separate Obligation Constructs
Work
LOE

Initially implement
M/L

Maintain as obligations and attributes each evolve
S/M

Understand for admins
S/M

Understand as developers building on top
S/M

Path 2: Obligations as Attribute Types
Work
LOE

Initially implement
M/L

Maintain as obligations evolve (unknown but coupled with shared concerns)
M/L

Understand for admins
M

Understand as developers building on top
M

Other data points

Adding the unsafe policy service was 9 new RPC endpoints, db functionalities with tests, 9 new CLI paths, and docs and took one engineer (myself) ~2 weeks with around 2/3 focus

We don't know exactly how obligations will evolve/mature over time (DLP, malware scanning, watermark)

Making obligations attributes means they are parent/child, rule-associated (implicitly), with an FQN that is ambiguous as to attribute type

The two options mostly overlap in cost to implement beyond policy, with the following roughly the same:

KAS/Authz/SDK/AccessPDP support for obligations work once read from policy services
CLI support for obligations work

Pros/Cons of Options
Option 1: Obligations as a separate construct

:green_square: Good, because long-term costs are expected to be lower (maintainance, testing, onboarding)
:green_square: Good, because more flexibility evolving obligations apart from attributes as our understanding of use cases matures
:green_square: Good, because less implicit behavior (requiring anyOf rule and parent/child structure)
:green_square: Good, because we can unblock differentiated RBAC casbin auth on obligations distinct from attributes
:green_square: Good, because it's less burden on admins to understand, and easier to understand when totally separate from attributes (i.e. "here is what an attribute means, and here is what an obligation means")
:green_square: Good, because smaller blast radius for bugs and breaking changes
:green_square: Good, because nothing stopping us from eventually deriving obligations off entities with separate constructs used while deriving - they're decoupled and flexible
:green_square: Good, because easier to add additional context to obligations like time frames or other conditions driving feature behavior post-obligation
:green_square: Good, because meets product use case requirements of "data-driven and derivable obligations satisfied by varied entity types under conditions within platform policy"
:yellow_square: Neutral, because PEP and non-policy costs are close to the same
:yellow_square: Neutral, because short-term policy implementation costs are close to the same, but maybe a little smaller
:yellow_square: Neutral, because if we need hierarchy or allOf rules on obligations, we'd need a new enum construct, but it would be decoupled so they could evolve separately
:red_square: Bad, because further complicates the policy relational db schema (hard to hold in your head at once)

Option 2: Obligations via flag within existing attributes as previously detailed

:green_square: Good, because meets product use case requirements of "data-driven and derivable obligations satisfied by varied entity types under conditions within platform policy"
:yellow_square: Neutral, because PEP and non-policy costs are close to the same
:yellow_square: Neutral, because we may still be able to do things like derive obligations from entities, but it is going to be harder to understand as a developer if obligations are attributes
:yellow_square: Neutral, because short-term policy implementation costs are close to the same, but maybe a little bigger
:yellow_square: Neutral, because fewer tables is good, but coupling to attributes is limiting
:red_square: Bad, because larger blast radius within policy for bugs and breaking changes given all the new IF/Else checks and behaviors
:red_square: Bad, because less flexibility evolving obligations apart from attributes as our understanding of use cases matures
:red_square: Bad, because implicit behavior around anyOf rule
:red_square: Bad, because long-term costs are lower (maintainance, testing, onboarding)
:red_square: Bad, because it's a greater burden on admins to understand (i.e. "here is what an attribute means, unless it's an obligation, and then it really means something different" and vice versa)

Option 1 makes sense to me especially if initial build cost is estimated to be the same between the two.
Is the obligation FQN naming convention what would be used  to decipher the difference between data attribute and obligation if placed on a TDF data policy?
I think product should weigh in on whether a parent->child and obligation rule type would be necessary so this could be tackled in the initial API implementation and reduce API churn.   It does seem like a handy way to do organization of "like" obligations and it seems like some obligations could be hierarchical

@ttschampel Agreed, the underlying assumptions would need to be revised if parent/child on obligations and rule variations are expected to be utilized within policy and enforced appropriately.

authors: jakedoublev ttschampel

repo: opentdf/platform


text:
Bulk Rewrap for NanoTDF Endpoint

Reduce chatter when decrypting a high count of nanotdfs

related, needed in js sdk -- https://github.com/opentdf/client-web/issues/272


text:
[WIP] Initial implementation

This is PoC of new docker-machine driver for OTC

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@709cd3b). Click here to learn what that means.
The diff coverage is 65.48%.

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage          ?   65.48%
=========================================
  Files             ?        5
  Lines             ?      846
  Branches          ?        0
=========================================
  Hits              ?      554
  Misses            ?      193
  Partials          ?       99

Impacted Files
Coverage Δ

driver/services/client.go
52% <52%> (ø)

driver/opentelekomcloud.go
62.61% <62.61%> (ø)

driver/services/compute.go
72.47% <72.47%> (ø)

driver/services/networking.go
74.02% <74.02%> (ø)

driver/services/utils.go
85.71% <85.71%> (ø)

Continue to review full report at Codecov.

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

authors: codecov-io outcatcher


text:
Subnet Registration: lock -> some other mechanism

Is your feature request related to a problem? Please describe.
Currently, if a subnet owner registers on mainnet, the cost for the subnet is locked, but not recycled. So if the subnet fails, the only people significantly affected are the miner and validator operators, who have recycled TAO to register within the subnet. I feel as if the price of failure to launch a subnet and gain emissions from the root network should actually be a price.
Describe the solution you'd like
I would like to see the subnet registration either:

Be recycled, instead of locked
Locked, but then apportioned out to the participants in the subnet according to the last know emissions schedule (18% for the owner, 82% for the node operators).

Describe alternatives you've considered
No response
Additional context
No response

Actually, scratch #2.  That could be exploited. Maybe it would be better just to distribute the tokens evenly across the active registrations and call it a day.

repo: opentensor/subtensor

license: Unlicense


text:
Add BondsPenalty hyperparam

Add BondsPenalty hyperparam
Given recent issues with (partially) blacklisted validators getting poor dividends, we've been exploring the possibility of adjusting the validation bonds penalty to improve their dividends.
Bonds penalty: Weight higher than consensus gets clipped, and bonds calculated from this then also get clipped, which means dividends get clipped. Cabal that sets weights on its own poor servers have their bonds cut and receive less dividends.
Validation advantage: Setting weight on the highest performing servers, means that dividends will be relatively better. Cabal that sets weights on its own poor servers will get less dividends because those servers get less incentive.
Suggestion: Adjust bonds penalty per netuid, with a default zero penalty, keep validation advantage.
Expected result: Partially blacklisted validators that set more weights on a fewer set of servers will enjoy full bonds on those, instead of getting bonds cut like when validation penalty applies.
Security guarantees:
A foremost concern is how this will affect the consensus security guarantees, so we simulate that as part of the subtensor integration tests with the _map_consensus_guarantees() function, and do a comparison with/without bonds penalty.
We observe as slight erosion of guarantees, at one point quantified as a 73% -> 79% honest utility increase required @ 60% honest stake to retain at least 60% emission. This is acceptable given that we gain significant alleviation of poor dividends due to blacklisting.

LGTM; when do you think we can release this update taco?

This is ready for release after outstanding approvals.
@shibshib please merge before the next chain upgrade.

LGTM; when do you think we can release this update taco?

LGTM; when do you think we can release this update taco?

Once outstanding approvals are granted, it can be merged.
@shibshib please merge before the next chain upgrade.


text:
[CSL] overflow in calculating semiWindow.

There is a bug-fixed PR  [csl] fix overflow in calculating semiWindow #6734
Due to the code changed form PR  [sub-mac] fix elapsed time in GetCslWindowEdges() #7299   The overflow now pops up again.
Refer to the discussion  [csl] Issues/inconsistencies from otPlatRadioGetNow() and mInfo.mRxInfo.mTimestamp as uint64_t #7054 . Can we using this formula to calculate the value of semiWindow to avoid the overflow with using the type uin32_t of all relevant variables?
semiWindow = (elapsed / 1000000) * (Get<Radio>().GetCslAccuracy() + mCslParentAccuracy) + (elapsed % 1000000) * (Get<Radio>().GetCslAccuracy() + mCslParentAccuracy) / 1000000;

^^ @marius-preda

@zwx1995tju what are the values of variables so that semiWindow overflows?
Isn't easier to cast to (uint64_t) and downcast back?
Since CSL phase is on 16bit => the final value of semiWindow can't overflow on 32bit even after converting to us

what are the values of variables so that semiWindow overflows

Hi @George-Stefan , the overflow issue may be described in this PR  [csl] fix overflow in calculating semiWindow #6734

@jwhui Hi, Jonathan, this Issue was not created for a question but for a bug during calculating semiWindow, which I have found a few months ago.   [csl] fix overflow in calculating semiWindow #6734 . And this bug need to be fixed.

Hi All, this bug is also fixed with this PR[sub-mac] fix semiWindow overflow in GetCslWindowEdges() #7549 . Sorry for trouble everyone.

repo: openthread/openthread