text:
Android crash with clientVersion.epub

Hello.
The following epub is part of Adobe's certification suite and will crash Readium hard:
https://s3.amazonaws.com/epub3.nypl-labs.biz/opds/clientVersion.epub
Upon loading...
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:248](22201): initializeReadiumSDK(): initializing Readium SDK...
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:256](22201): initializeReadiumSDK(): initialization of Readium SDK finished
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:427](22201): EPub3.openBook(): path received is '/storage/emulated/0/epubtest/crash.epub'
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:230](22201): READIUM SDK ERROR HANDLER (warning): Package metadata MUST include 'dc:identifier'.
I/System.out(22201): SdkErrorHandler: Package metadata MUST include 'dc:identifier'. (warning)
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:230](22201): READIUM SDK ERROR HANDLER (warning): Package metadata MUST include 'dc:title'.
I/System.out(22201): SdkErrorHandler: Package metadata MUST include 'dc:title'. (warning)
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:230](22201): READIUM SDK ERROR HANDLER (warning): Package metadata MUST include 'dc:language'.
I/System.out(22201): SdkErrorHandler: Package metadata MUST include 'dc:language'. (warning)
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:230](22201): READIUM SDK ERROR HANDLER (warning): Publications MUST contain exactly one navigation document.
I/System.out(22201): SdkErrorHandler: Publications MUST contain exactly one navigation document. (warning)
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:439](22201): EPub3.openBook(): _container OK, version: 1.0
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:191](22201): PointerPool::add(): added pointer 5C37A25C(5) container [./../../Platform/Android/jni/epub3.cpp:442]
I/org.readium.sdk.android.Container(22201): Creating container [ptr:5C37A25C, path:/storage/emulated/0/epubtest/crash.epub]
D/libepub3 [./../../Platform/Android/jni/epub3.cpp:450](22201): EPub3.openBook(): package type: 0x5d9767a0 PSt10shared_ptrIN5ePub37PackageEE
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:191](22201): PointerPool::add(): added pointer 40015334(6) package [./../../Platform/Android/jni/epub3.cpp:453]
I/Package (22201): Creating package [ptr:40015334]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
D/libepub3 [./../../Platform/Android/jni/jni/jni_ptr.cpp:203](22201): PointerPool::get(): got pointer 40015334(5) package [./../../Platform/Android/jni/epub3.cpp:453]
F/libc    (22201): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22201 (ndroid.launcher)
I/DEBUG   ( 1671): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 1671): Build fingerprint: 'samsung/cm_golden/golden:4.4.4/KTU84Q/c0f7681dea:userdebug/test-keys'
I/DEBUG   ( 1671): Revision: '106'
I/DEBUG   ( 1671): pid: 22201, tid: 22201, name: ndroid.launcher  >>> org.readium.sdk.android.launcher <<<
I/DEBUG   ( 1671): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG   ( 1671):     r0 bed75eb4  r1 00000000  r2 00000000  r3 00000000
I/DEBUG   ( 1671):     r4 00000000  r5 400153e8  r6 00000004  r7 41568c4c
I/DEBUG   ( 1671):     r8 bed75fd0  r9 41568c44  sl 4004b4b8  fp bed75e3c
I/DEBUG   ( 1671):     ip 61394b08  sp bed75e30  lr 61022d28  pc 612ce828  cpsr 400f0030
I/DEBUG   ( 1671):     d0  000000003a6e7275  d1  0000000000000000
I/DEBUG   ( 1671):     d2  0000000000000000  d3  0000000000000000
I/DEBUG   ( 1671):     d4  7a714a15b6d11b7c  d5  bf28567d1fda1e4a
I/DEBUG   ( 1671):     d6  861a8b6ccf51ba8c  d7  59ef95ba8fd85e39
I/DEBUG   ( 1671):     d8  0000000000000000  d9  0000000000000000
I/DEBUG   ( 1671):     d10 0000000000000000  d11 0000000000000000
I/DEBUG   ( 1671):     d12 0000000000000000  d13 0000000000000000
I/DEBUG   ( 1671):     d14 0000000000000000  d15 0000000000000000
I/DEBUG   ( 1671):     d16 0000000000000000  d17 0000000000000004
I/DEBUG   ( 1671):     d18 0000000000000000  d19 0000000000000000
I/DEBUG   ( 1671):     d20 0000010000000000  d21 0000000000000000
I/DEBUG   ( 1671):     d22 0000000000000000  d23 0000000000000000
I/DEBUG   ( 1671):     d24 3fe5555560000000  d25 0000000000000000
I/DEBUG   ( 1671):     d26 3ff0000000000000  d27 0000000000000000
I/DEBUG   ( 1671):     d28 3fe5555560000000  d29 0000000000000000
I/DEBUG   ( 1671):     d30 3ff921fb54400000  d31 3dd0b4611a626331
I/DEBUG   ( 1671):     scr 60000013
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): backtrace:
I/DEBUG   ( 1671):     #00  pc 004cf828  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so
I/DEBUG   ( 1671):     #01  pc 00223d24  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so (std::basic_ostream<char, std::char_traits<char> >& ePub3::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, ePub3::string const&)+40)
I/DEBUG   ( 1671):     #02  pc 002ee2f0  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so (ePub3::Package::FullTitle(bool) const+1152)
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): stack:
I/DEBUG   ( 1671):          bed75df0  bed75f4c  [stack]
I/DEBUG   ( 1671):          bed75df4  612b94cf  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so
I/DEBUG   ( 1671):          bed75df8  6139fd98
I/DEBUG   ( 1671):          bed75dfc  bed75ee0  [stack]
I/DEBUG   ( 1671):          bed75e00  bed75eb8  [stack]
I/DEBUG   ( 1671):          bed75e04  612b9579  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so
I/DEBUG   ( 1671):          bed75e08  613951f8  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so
I/DEBUG   ( 1671):          bed75e0c  bed75eac  [stack]
I/DEBUG   ( 1671):          bed75e10  bed75ee0  [stack]
I/DEBUG   ( 1671):          bed75e14  612d4825  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so
I/DEBUG   ( 1671):          bed75e18  bed75e30  [stack]
I/DEBUG   ( 1671):          bed75e1c  bed75e34  [stack]
I/DEBUG   ( 1671):          bed75e20  00000000
I/DEBUG   ( 1671):          bed75e24  00000000
I/DEBUG   ( 1671):          bed75e28  00000000
I/DEBUG   ( 1671):          bed75e2c  bed75e3c  [stack]
I/DEBUG   ( 1671):     #00  bed75e30  00000000
I/DEBUG   ( 1671):          ........  ........
I/DEBUG   ( 1671):     #01  bed75e30  00000000
I/DEBUG   ( 1671):          bed75e34  bed75eb4  [stack]
I/DEBUG   ( 1671):          bed75e38  bed75f74  [stack]
I/DEBUG   ( 1671):          bed75e3c  610ed2f4  /data/app-lib/org.readium.sdk.android.launcher-1/libepub3.so (ePub3::Package::FullTitle(bool) const+1156)
I/DEBUG   ( 1671):     #02  bed75e40  bed75e54  [stack]
I/DEBUG   ( 1671):          bed75e44  01143534
I/DEBUG   ( 1671):          bed75e48  40015334
I/DEBUG   ( 1671):          bed75e4c  bed75f88  [stack]
I/DEBUG   ( 1671):          bed75e50  613a0584
I/DEBUG   ( 1671):          bed75e54  00000004
I/DEBUG   ( 1671):          bed75e58  00000000
I/DEBUG   ( 1671):          bed75e5c  bed75e6c  [stack]
I/DEBUG   ( 1671):          bed75e60  bed75e7c  [stack]
I/DEBUG   ( 1671):          bed75e64  bed75e70  [stack]
I/DEBUG   ( 1671):          bed75e68  00000000
I/DEBUG   ( 1671):          bed75e6c  4001532c
I/DEBUG   ( 1671):          bed75e70  00000000
I/DEBUG   ( 1671):          bed75e74  00000000
I/DEBUG   ( 1671):          bed75e78  00000000
I/DEBUG   ( 1671):          bed75e7c  00000000
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near r0:
I/DEBUG   ( 1671):     bed75e94 61391c68 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75ea4 5d976fc8 5d976f74 6139036c 00000000
I/DEBUG   ( 1671):     bed75eb4 61390380 613951f8 00000000 00000000
I/DEBUG   ( 1671):     bed75ec4 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75ed4 6139fd98 00000018 613a0584 61390394
I/DEBUG   ( 1671):     bed75ee4 00000006 00000000 00001002 00000000
I/DEBUG   ( 1671):     bed75ef4 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f04 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f14 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f24 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f34 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f44 00000008 bed75f04 6139fd98 00000000
I/DEBUG   ( 1671):     bed75f54 40010000 bed75eb8 6139fb1c 6139fdb8
I/DEBUG   ( 1671):     bed75f64 613a04e8 61396d34 4004b4a8 bed75fcc
I/DEBUG   ( 1671):     bed75f74 6114bec4 40015334 00000000 b5800025
I/DEBUG   ( 1671):     bed75f84 4004b008 00000000 40015334 40015328
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near r5:
I/DEBUG   ( 1671):     400153c8 400153bc 00000000 00000006 5db7dfb4
I/DEBUG   ( 1671):     400153d8 5db7dfa8 61393688 40015334 40015328
I/DEBUG   ( 1671):     400153e8 61393698 00000000 00000000 5d976a30
I/DEBUG   ( 1671):     400153f8 5d976a38 5d976a38 000000e0 00000000
I/DEBUG   ( 1671):     40015408 5db09928 4164abc0 4164ab80 00000006
I/DEBUG   ( 1671):     40015418 613936f0 5c37a25c 5c37a250 00000000
I/DEBUG   ( 1671):     40015428 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     40015438 00000000 5d96efc8 5d96efc8 5d96efc8
I/DEBUG   ( 1671):     40015448 00000001 40014ee4 40014ed8 0000002b
I/DEBUG   ( 1671):     40015458 00000000 5db09928 4164aba0 4164ab60
I/DEBUG   ( 1671):     40015468 5d955bdc 5d955bf4 00000000 00000000
I/DEBUG   ( 1671):     40015478 00000028 0000001b 613916c8 40015480
I/DEBUG   ( 1671):     40015488 5db09910 4164ae58 00000000 00000013
I/DEBUG   ( 1671):     40015498 52586d6c 40015480 5db09910 00000011
I/DEBUG   ( 1671):     400154a8 5db06130 5d96efa0 00000010 00000012
I/DEBUG   ( 1671):     400154b8 dead1000 401838c8 00000000 00000013
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near r7:
I/DEBUG   ( 1671):     41568c2c 41568c60 6043dfc0 57cf1430 00000009
I/DEBUG   ( 1671):     41568c3c 00000000 b5800025 40015334 00000000
I/DEBUG   ( 1671):     41568c4c 41568c88 6043df26 57cf1238 6043dfc0
I/DEBUG   ( 1671):     41568c5c 00000000 40015334 00000000 00000004
I/DEBUG   ( 1671):     41568c6c 41fed258 42001ad0 41568cc4 6043df44
I/DEBUG   ( 1671):     41568c7c 57cf11c8 6043df26 00000000 41fed258
I/DEBUG   ( 1671):     41568c8c 42001eb8 4183e510 42001ce0 42001cf8
I/DEBUG   ( 1671):     41568c9c 00000000 5c37a25c 42001ad0 40015334
I/DEBUG   ( 1671):     41568cac 00000000 41568ce8 00000000 57cf1200
I/DEBUG   ( 1671):     41568cbc 6043df44 420013c8 42001ad0 5c37a25c
I/DEBUG   ( 1671):     41568ccc 40015334 00000000 41568cfc 00000000
I/DEBUG   ( 1671):     41568cdc 00000000 00000000 41568d14 41568d14
I/DEBUG   ( 1671):     41568cec 6043ffaa 57cf09c0 00000006 00000000
I/DEBUG   ( 1671):     41568cfc d500001d 41568d60 593edb9a 57cf0738
I/DEBUG   ( 1671):     41568d0c 6043ffaa 00000000 41feb358 59101736
I/DEBUG   ( 1671):     41568d1c 00000000 00000000 41ffa698 422132d0
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near r8:
I/DEBUG   ( 1671):     bed75fb0 40015334 40015328 5daffb54 4004b4a8
I/DEBUG   ( 1671):     bed75fc0 417b4c6c 57cf1430 bed75fe4 41725a94
I/DEBUG   ( 1671):     bed75fd0 41568c40 00000001 00000000 42001ad0
I/DEBUG   ( 1671):     bed75fe0 bed762d0 417566ab 41568c40 6047f57e
I/DEBUG   ( 1671):     bed75ff0 6114be48 4004b4b8 5d976f7f 5db09368
I/DEBUG   ( 1671):     bed76000 00000000 00000000 5daffb90 40161384
I/DEBUG   ( 1671):     bed76010 6114be48 40124333 4015d000 5d976f48
I/DEBUG   ( 1671):     bed76020 00000000 5daffb90 00000000 40120ced
I/DEBUG   ( 1671):     bed76030 400ae004 417582d7 00000000 00000018
I/DEBUG   ( 1671):     bed76040 00000018 41c0f008 00000001 00000018
I/DEBUG   ( 1671):     bed76050 417b92c8 415951bc bed762d0 42001eb8
I/DEBUG   ( 1671):     bed76060 00500b68 42001eb8 4004b3b0 4177ba21
I/DEBUG   ( 1671):     bed76070 bed760dc 57cf1444 00000001 41fed198
I/DEBUG   ( 1671):     bed76080 0000000b 00000001 57cf1430 604b200d
I/DEBUG   ( 1671):     bed76090 bed760dc 00000038 00000000 4177467f
I/DEBUG   ( 1671):     bed760a0 604b200d 603dbda4 41fed198 604b200d
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near r9:
I/DEBUG   ( 1671):     41568c24 0000001f 42001c80 41568c60 6043dfc0
I/DEBUG   ( 1671):     41568c34 57cf1430 00000009 00000000 b5800025
I/DEBUG   ( 1671):     41568c44 40015334 00000000 41568c88 6043df26
I/DEBUG   ( 1671):     41568c54 57cf1238 6043dfc0 00000000 40015334
I/DEBUG   ( 1671):     41568c64 00000000 00000004 41fed258 42001ad0
I/DEBUG   ( 1671):     41568c74 41568cc4 6043df44 57cf11c8 6043df26
I/DEBUG   ( 1671):     41568c84 00000000 41fed258 42001eb8 4183e510
I/DEBUG   ( 1671):     41568c94 42001ce0 42001cf8 00000000 5c37a25c
I/DEBUG   ( 1671):     41568ca4 42001ad0 40015334 00000000 41568ce8
I/DEBUG   ( 1671):     41568cb4 00000000 57cf1200 6043df44 420013c8
I/DEBUG   ( 1671):     41568cc4 42001ad0 5c37a25c 40015334 00000000
I/DEBUG   ( 1671):     41568cd4 41568cfc 00000000 00000000 00000000
I/DEBUG   ( 1671):     41568ce4 41568d14 41568d14 6043ffaa 57cf09c0
I/DEBUG   ( 1671):     41568cf4 00000006 00000000 d500001d 41568d60
I/DEBUG   ( 1671):     41568d04 593edb9a 57cf0738 6043ffaa 00000000
I/DEBUG   ( 1671):     41568d14 41feb358 59101736 00000000 00000000
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near sl:
I/DEBUG   ( 1671):     4004b498 00000000 00000800 4155d008 0000045b
I/DEBUG   ( 1671):     4004b4a8 58a2971a 41568c40 57cf1238 5d8df000
I/DEBUG   ( 1671):     4004b4b8 42001ff0 61396d34 bed76128 00000000
I/DEBUG   ( 1671):     4004b4c8 bed7617c 00000001 00000000 41725c00
I/DEBUG   ( 1671):     4004b4d8 00000000 00000000 56f62970 41563300
I/DEBUG   ( 1671):     4004b4e8 00000000 00000000 00000001 00006000
I/DEBUG   ( 1671):     4004b4f8 00000000 400c4154 41725c00 4172ab40
I/DEBUG   ( 1671):     4004b508 00000000 4172ec3c 4172ecb0 4172eb60
I/DEBUG   ( 1671):     4004b518 4172eb80 4172ebdc 00000000 00000000
I/DEBUG   ( 1671):     4004b528 40071010 00000028 00000000 00000000
I/DEBUG   ( 1671):     4004b538 00000000 00000006 00002000 417b99fc
I/DEBUG   ( 1671):     4004b548 417cb9e8 579c87e8 0000000a 4164ede8
I/DEBUG   ( 1671):     4004b558 00000001 00000080 00000200 00000000
I/DEBUG   ( 1671):     4004b568 00000005 58a8bc20 58a8bc20 00000008
I/DEBUG   ( 1671):     4004b578 58a8bc32 579c8a18 63ce4b88 5d34cf20
I/DEBUG   ( 1671):     4004b588 99a48493 4084e528 48b8f729 9de2e75e
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near fp:
I/DEBUG   ( 1671):     bed75e1c bed75e34 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75e2c bed75e3c 00000000 bed75eb4 bed75f74
I/DEBUG   ( 1671):     bed75e3c 610ed2f4 bed75e54 01143534 40015334
I/DEBUG   ( 1671):     bed75e4c bed75f88 613a0584 00000004 00000000
I/DEBUG   ( 1671):     bed75e5c bed75e6c bed75e7c bed75e70 00000000
I/DEBUG   ( 1671):     bed75e6c 4001532c 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75e7c 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75e8c 00000000 00000000 61391c68 00000000
I/DEBUG   ( 1671):     bed75e9c 00000000 00000000 5d976fc8 5d976f74
I/DEBUG   ( 1671):     bed75eac 6139036c 00000000 61390380 613951f8
I/DEBUG   ( 1671):     bed75ebc 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75ecc 00000000 00000000 6139fd98 00000018
I/DEBUG   ( 1671):     bed75edc 613a0584 61390394 00000006 00000000
I/DEBUG   ( 1671):     bed75eec 00001002 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75efc 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f0c 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near ip:
I/DEBUG   ( 1671):     61394ae8 612b8009 612b81ed 612edf8d 612b81f1
I/DEBUG   ( 1671):     61394af8 612b803d 00000000 00000000 61394b30
I/DEBUG   ( 1671):     61394b08 612b80bd 612b80d9 612b81e9 612b81ed
I/DEBUG   ( 1671):     61394b18 612b6899 612b6811 612b81b9 612b8129
I/DEBUG   ( 1671):     61394b28 612b80ed 00000000 61394b08 613899a8
I/DEBUG   ( 1671):     61394b38 613945f8 00000000 00000000 61394b60
I/DEBUG   ( 1671):     61394b48 612b81e5 612b81f5 612b81e9 612b81ed
I/DEBUG   ( 1671):     61394b58 612b822d 612b81f1 613945d0 613899d0
I/DEBUG   ( 1671):     61394b68 00000000 61394b98 612b8231 612b824d
I/DEBUG   ( 1671):     61394b78 612b81e9 612b81ed 612b6899 612b6811
I/DEBUG   ( 1671):     61394b88 612b8669 612b82e9 612b8261 00000000
I/DEBUG   ( 1671):     61394b98 61394b08 613899e0 613945f8 613945d0
I/DEBUG   ( 1671):     61394ba8 61389a08 00000000 00000000 61394bec
I/DEBUG   ( 1671):     61394bb8 612b87ed 612b8885 612b8ab9 612b8bc1
I/DEBUG   ( 1671):     61394bc8 612b8ac9 612b8c09 612b87e5 612b88dd
I/DEBUG   ( 1671):     61394bd8 612b87e9 612b88cd 61394b08 61389a2c
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): memory near sp:
I/DEBUG   ( 1671):     bed75e10 bed75ee0 612d4825 bed75e30 bed75e34
I/DEBUG   ( 1671):     bed75e20 00000000 00000000 00000000 bed75e3c
I/DEBUG   ( 1671):     bed75e30 00000000 bed75eb4 bed75f74 610ed2f4
I/DEBUG   ( 1671):     bed75e40 bed75e54 01143534 40015334 bed75f88
I/DEBUG   ( 1671):     bed75e50 613a0584 00000004 00000000 bed75e6c
I/DEBUG   ( 1671):     bed75e60 bed75e7c bed75e70 00000000 4001532c
I/DEBUG   ( 1671):     bed75e70 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75e80 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75e90 00000000 61391c68 00000000 00000000
I/DEBUG   ( 1671):     bed75ea0 00000000 5d976fc8 5d976f74 6139036c
I/DEBUG   ( 1671):     bed75eb0 00000000 61390380 613951f8 00000000
I/DEBUG   ( 1671):     bed75ec0 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75ed0 00000000 6139fd98 00000018 613a0584
I/DEBUG   ( 1671):     bed75ee0 61390394 00000006 00000000 00001002
I/DEBUG   ( 1671):     bed75ef0 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):     bed75f00 00000000 00000000 00000000 00000000
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): code around pc:
I/DEBUG   ( 1671):     612ce808 6a304770 ef02f4fa e9c517c1 e7f20100
I/DEBUG   ( 1671):     612ce818 94019c0e 94002400 e7ec47b8 fffffe07
I/DEBUG   ( 1671):     612ce828 f8516809 f0012c0c bf00ba1d b5706803
I/DEBUG   ( 1671):     612ce838 f8534605 44033c0c b1d46fdc 460e7f23
I/DEBUG   ( 1671):     612ce848 f894b13b 46282027 e8bd4631 f7f04070
I/DEBUG   ( 1671):     612ce858 4620ba0b f88ef7ea 4b076822 447b6992
I/DEBUG   ( 1671):     612ce868 bf08429a d0ee220a 210a4620 46024790
I/DEBUG   ( 1671):     612ce878 f01ae7e9 bf00fcb9 fffe9f7b 4ff0e92d
I/DEBUG   ( 1671):     612ce888 7d03f5ad 4607ac01 2200468a 46204601
I/DEBUG   ( 1671):     612ce898 ff26f7ed b96b7823 2204683b 0c0cf853
I/DEBUG   ( 1671):     612ce8a8 69414438 f7ea4311 4638ff6d 7d03f50d
I/DEBUG   ( 1671):     612ce8b8 8ff0e8bd 2000f8da 460b2100 f8524650
I/DEBUG   ( 1671):     612ce8c8 f01e2c0c 683bf87d 0808f10d 72fef64f
I/DEBUG   ( 1671):     612ce8d8 f6c04640 f85372ff 443b3c0c 016cf103
I/DEBUG   ( 1671):     612ce8e8 2b00689b 4699bfcc f7fd4691 4640f89f
I/DEBUG   ( 1671):     612ce8f8 fa68f00b 46404683 faf6f7fd f853683b
I/DEBUG   ( 1671):
I/DEBUG   ( 1671): code around lr:
I/DEBUG   ( 1671):     61022d08 e50b0008 e50b100c e51b000c ebffdd8d
I/DEBUG   ( 1671):     61022d18 e1a03000 e51b0008 e1a01003 fa0aaebf
I/DEBUG   ( 1671):     61022d28 e1a03000 e1a00000 e1a00003 e24bd004
I/DEBUG   ( 1671):     61022d38 e8bd8800 e92d4800 e28db004 e24dd010
I/DEBUG   ( 1671):     61022d48 e50b0008 e50b100c e50b2010 e51b3008
I/DEBUG   ( 1671):     61022d58 e2833008 e1a00003 e51b100c fa0ab47e
I/DEBUG   ( 1671):     61022d68 e51b0008 e51b1010 eb000004 e1a03000
I/DEBUG   ( 1671):     61022d78 e1a00000 e1a00003 e24bd004 e8bd8800
I/DEBUG   ( 1671):     61022d88 e92d4800 e28db004 e24dd008 e50b0008
I/DEBUG   ( 1671):     61022d98 e50b100c e51b3008 e2833008 e1a00003
I/DEBUG   ( 1671):     61022da8 e51b100c ebffffd2 e51b0008 ebffd990
I/DEBUG   ( 1671):     61022db8 e1a03000 e1a00000 e1a00003 e24bd004
I/DEBUG   ( 1671):     61022dc8 e8bd8800 e92d4800 e28db004 e24dd010
I/DEBUG   ( 1671):     61022dd8 e50b0008 e50b100c e50b2010 e51b0008
I/DEBUG   ( 1671):     61022de8 e51b100c e51b2010 eb00067e e24bd004
I/DEBUG   ( 1671):     61022df8 e8bd8800 e52db004 e28db000 e24dd014

This occurs with unmodified Android SDK launcher, and has apparently been an issue since at least 0.17.0.

The file referenced above appears to be invalid. This version.epub is a file that our team at Adobe wrote almost 10 years ago.  It appears that this instance has been corrupted along the way.
Running it through EPUBCheck (3) generates a couple of dozen errors.  Can you check it against EPUBCheck and once clear of errors, try re-running it?  From some of the errors, it looks like the actual EPUB file is not packaged correctly. EPUBCheck complains:
ERROR	Mimetype entry must not have an extra field in its ZIP header

That being said, we should not crash in any case (that's a high priority bug).  So that needs to be fixed.  Thanks for bringing this to our attention.

It's still not valid but:
http://waste.io7m.com/2015/09/04/c1.epub
... doesn't crash. I think the problem is the content.opf:
The crashing version has a <dc:metadata> element as a child of the <metadata> element, where as the non-crashing version removes the <dc:metadata> element and adds the contents directly to the <metadata> element:
 <metadata>
   <dc:title>Adobe Digital Editions -- Version Check</dc:title>
   <dc:creator>Peter Sorotokin</dc:creator>
   <dc:date xsi:type="dcterms:W3CDTF">2006-09-12</dc:date>
   <dc:language xsi:type="dcterms:RFC3066">en-US</dc:language>
   <dc:publisher>Adobe Systems Inc.</dc:publisher>
   <dc:identifier id="bookid">urn:uuid:fd974603-8597-4ee1-9588-94ac76230665</dc:identifier>
 </metadata>

Right.  This looks like we are not handling errors correctly in the package file.  We had a similar problem with the ReadiumJS code recently, but the two code bases are separate so I doubt they are connected.  Still, it's a bug.

I fixed a similar bug in readium-js-viewer but the xml was actually malformed. When I investigated that bug, I found that readium-shared-js doesn't do any kind of error handling when it parses xml. This is still the case so it may be related.

Re-tested with 0.25-alpha from develop on both iOS (9.3 iPad Air) and OSX (MBP 10.11).  Both apps complained about the errors in the metadata section but didn't crash.  Closing.

authors: io7m rkwright ryanackley

repo: readium/readium-sdk


text:
Large NSString * objects cut to zero or 64k (iPhone 6S simulator only?)

Goals
Store a large json string in an NSString property.
Expected Results
According to the documentation

NSData and NSString properties cannot hold data exceeding 16MB in size. To store larger amounts of data, either break it up into 16MB chunks or store it directly on the file system, storing paths to these files in the realm. An exception will be thrown at runtime if your app attempts to store more than 16MB in a single property.

Actual Results
When retrieving the json string, it's been cut at 64k (65535 bytes). In other cases, it's not stored at all (zero length).
Steps to Reproduce
Happens randomly but quite frequently. Seems to be limited to the simulator.
Encode a large NSDictionary as JSON, convert to NSString *, assign to a RLMObject and commit.
Note that there are several other pending objects to be committed, as the object is created in the middle of a load-all-or-nothing transaction (HTTP download of serveral pieces). Also note some of those objects have NSData * properties.
Code Sample
Could be provided.
Version of Realm and Tooling
ProductName:	Mac OS X
ProductVersion:	10.11.3
BuildVersion:	15D21

/Applications/Xcode.app/Contents/Developer
Xcode 7.2.1
Build version 7C1002

/usr/local/bin/pod
0.39.0
Realm (0.98.3)
Realm (~> 0.98)

/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)

/usr/bin/git
git version 2.5.4 (Apple Git-61)

Forget about it!
Was the JSON Serialization going out of range.

source: gharchive/issue

repo: realm/realm-cocoa

license_type: permissive

license_source: github-api


text:
Thread exception when printing Object description with relationships

Goals
Wish to log a resolved realm object description on a separate thread.
Expected Results
descriptionWithMaxDepth: to appropriately return description.
Actual Results
IncorrectThreadException raised.
Code Sample
Create Object subclass which has at least one relationship.
class Group: Object {

    dynamic var id: String = ""
    dynamic var name: String = ""

    dynamic var site: Site?

Now create an instance of the object & give it a relationship object, in this case an instance of Site.
Now create a ThreadSafeReference.
On a new thread create an instance of Realm, resolve the thread reference & then try logging:
let realm = try! Realm(configuration: Realm.Configuration(inMemoryIdentifier: "MyInMemoryRealm"))
realmObject = realm.resolve(resourceThreadRef)
print("realmObject: \(realmObject)")

Version of Realm and Tooling
ProductName:	Mac OS X
ProductVersion:	10.12.3
BuildVersion:	16D32

/Applications/Xcode.app/Contents/Developer
Xcode 8.2.1
Build version 8C1002

/usr/local/bin/pod
1.2.0
(not in use here)

/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)

/usr/local/bin/carthage
0.15.2
(not in use here)

/usr/bin/git
git version 2.10.1 (Apple Git-78)

Thanks for reporting this @markst, I'm looking into it.

@jpsim I think this is largely to do with Realm not complaining when setting a relationship from a different realm. i.e:
let group = Group(value: ["id":NSUUID().uuidString])
group.site = self.site

Resolution for above exception is:
group.site = realm.create(Site.self, value: self.site, update: true)

This also appears to happen if making an unmanaged copy of a realm object which has relationships:
let unmanagedUser = User(value: self.user!)
print("unmanagedUser: \(unmanagedUser)")

Haven't been able to delve too deep, but could be due to RLMIsObjectValidForProperty() not correctly identifying whether it's a valid object for property.
https://github.com/realm/realm-cocoa/blob/master/Realm/RLMUtil.mm#L151
Otherwise the correct duplication of array would occur here:
https://github.com/realm/realm-cocoa/blob/master/Realm/RLMObjectBase.mm#L95

This is bizarre & seems to happen even if creating unmanaged copies of the relationships also:
// Create unmanaged if necessary
var fitting: Fitting = self.fitting.realm == nil ? self.fitting : Fitting(value: self.fitting)
fitting = self.fittingInformationViewController!.fittingInformationView.updateFitting(fitting: fitting)

// Update test relationship with umanaged if necessary
let test: Test = fitting.test?.realm == nil ? fitting.test! : Test(value: fitting.test!)
fitting.test = self.testResultViewController!.testResultView.update(test: test)

// Update group relationship with umanaged if necessary
let group: Group = fitting.group?.realm == nil ? fitting.group! : Group(value: fitting.group!)
fitting.group = group

My solution for now is to return nil for description:
- (NSString *)description
{
    NSLog(@"self.class.className: %@ self: %@ description: %@",self.class.className,self,self.realm);
    return nil;
}

The problems mentioned in https://github.com/realm/realm-cocoa/issues/4747#issuecomment-287668924 and https://github.com/realm/realm-cocoa/issues/4747#issuecomment-289986583 seem at first glance like they stem from an expectation that Object(value:) will perform a deep copy of the passed-in object, when in fact only a shallow copy is performed. This means that any objects referenced via relationships (either properties that are of an Object subclass type or List<T>) would still refer to the instances from the original Realm (and thus from a different thread if the copied object is passed to a different thread). As @jpsim mentioned at https://github.com/realm/realm-cocoa/issues/4882#issuecomment-296810821, we have #3381 tracking adding a built-in way to perform a deep copy in the future.
The initial comment mentions seeing this problem when using a ThreadSafeReference, which must have a different cause. It'd be worth seeing if we can reproduce that.

@markst, can you please share self-contained steps to reproduce the problem when you're able (keeping in mind my point above about Object(value:) only performing a shallow copy)?

Given the age of this issue and the lack of movement, I am closing it. If you see this problem again with the latest version of Realm and are able to build a repro case (or at least offer reproduction steps), please feel free to re-open this ticket or to file a new one.

authors: austinzheng bdash jpsim markst


text:
Not obvious how to build the Examples, & build.sh fails

Goals
Run the ListSwiftUI example
Expected Results

(perform some documented installation)
Run the ListSwiftUI scheme
Build successfully

Actual Results
Build error:

And when building just RealmSwift:

Browsing to the /examples/installation folder shows a build.sh but it's only for testing.
Browsing to /build.sh, I see I can run ./build.sh examples-ios but that itself fails too:

Steps for others to Reproduce
See above, primarily that ./build.sh examples-ios fails with error shown above.
Code Sample
n/a
Version of Realm and Tooling
Realm framework version: Current master - 44b9632b22240
Realm Object Server version: n/a
Xcode version: 12.4
iOS/OSX version: macOS 10.15.7
Dependency manager + version: n/a

The solution is to build.sh build first, before build.sh examples-ios
I just feel that this process could be documented, as probably others would stumble over the same stuff of just opening the example projects and expecting them to build

Hello @iandundas. I guess you already figure it out. Thanks for the suggestions about the documentation, We'll review it and make sure everything is as simple and explanatory as possible.

Cool - happy to close it, this can be googled by someone in my shoes (probably me in 6 months)


text:
Synced Realm collection notifications not being received

How frequently does the bug occur?
Sometimes
Description
We expect to be able to observe collection changes using the following code:
class ViewController: NSViewController {
....
var changeNoficationToken: NotificationToken?
func register(){
`        self.changeNotificationToken = changes?.observe { [weak self] (changes: RealmCollectionChange) in
        DebugLog("UserChange changed")

        switch changes {
        case .initial:

            self?.tableView.reloadData()
            break

        case .update(_,  _,  _,  _):

            self?.tableView.reloadData()
            break

        case .error(let error):
            // An error occurred while opening the Realm file on the background worker thread
            fatalError("\(error)")
        }
    }`

}
}
However for some reason this is not getting called when changes are made by other remote synced clients.  But doing a manual tableView.reloadData() does show the changed data.
Are there some circumstances where these notifications will not be sent - and am I correct in assuming that if register() is called on the main thread then the callback will be called on the main thread.
Stacktrace & log output
N/A

Can you reproduce the bug?
Yes, sometimes
Reproduction Steps
Currently a production system
Version
RealmSwift v10.19.0
What SDK flavour are you using?
MongoDB Realm (i.e. Sync, auth, functions)
Are you using encryption?
No, not using encryption
Platform OS and version(s)
macOS 12.0.1
Build environment
Xcode version: 13.1
Dependency manager and version: none - using downloaded RealmSwift prebuilt packages for Xcode 13.1

So this seems a bit weird because intermittently when opening the synced realm the call to realm.syncSession?.addProgressNotification(...) will return a non-nil value but the callback will subsequently never be called.  And when this occurs the collection notifications are delivered correctly.
However whenever the callback is called the collection notifications don't seem to be called.
It doesn't seem to help to not add a progress notification block.  It seems that opening the realm file will intermittently deliver the collection change notifications, but more frequently than not it won't.

OK I think I found the problem.
When we open the synced realm the first time when the app gets launched by the user we do so from a background thread to avoid any issues with any realm-core database file format upgrades that might need to be run.
If this upgrade needs to be run then this causes the MAIN THREAD to block until the database file format upgrade has completed.  This is obviously undesirable because the UI hangs.
If I remove this first time call to Realm() and do it from the MAIN THREAD then this issue of receiving change notifications appears to now go away.
Strange that the Intel macOS users don't appear to have reported any problems with the UI not updating when other clients update the data.
So I guess the question is should it matter that the first time Realm() is called it is called from a background thread ?  Is this a bug perhaps ?

@duncangroenewald can you send us a project that demonstrates this behaviour? Thanks.

@jsflax - I can try and create one for you.  However I just discovered that the cause of the problem might have something to do with the fact that our initial call is like this below (pseudocode).
Not 100% sure here but is seems that because the realm returned by the initial call to Realm() is not being retained this may be causing a problem for the realm-core setup code.
I am speculating a bit here but I noticed the same issue with a test app where the sync callbacks would never be called if the realm returned from the initial call to Realm() was not retained.  I need to investigate further to be sure though but thought that might be worth mentioning.
I will try and reproduce with a test app for you.
func initRealm(completion: ()->Void) {
DispatchQueue.global().async {
// Open the synced realm the first time on a background thread so
// any blocking because of file format migrations done by realm-core
// don't block the UI
let realm = Realm(config)
DispatchQueue.main.async {
  // Now open the main thread Realm used by the UI in the app
  Global.shared.realmMain = Realm(config)

  completion()

}
}
}

@jsflax - I send you a test app that replicates the issue.

authors: duncangroenewald jsflax


text:
Fix some small test issues

Remove the RLM prefix from some test cases for consistency with the rest of the tests and add the proper license header to one file.
@jpsim

:+1:

source: gharchive/pull-request

authors: jpsim tgoyne


text:
Fix crash in MongoCollection.findOneDocument(filter:) that occurred when no results were found for a given filter

Fixes #7380.

Closing because the Copy Resource change is larger than anticipated.


text:
Error what(): set: row ndx out of range

We have encountered an error something like this:
terminate called after throwing an instance of 'realm::sync::BadChangesetError'
0|nextgo-r | what(): set: row ndx out of range
PM2 | App [nextgo-ros] with id [0] and pid [31707], exited with code [0] via signal [SIGABRT]
PM2 | Starting execution sequence in -fork mode- for app name:nextgo-ros id:0
PM2 | App name:nextgo-ros id:0 online

Please refrain from opening identical issues in multiple repositories - it will not result in faster response times. I'm closing this one as it's not related to the GraphQL service.

authors: howdyhyber nirinchev

repo: realm/realm-graphql-service


text:
Can I filter a PersistableEnum with predicate?

How frequently does the bug occur?
Always
Description
Can I filter a PersistableEnum with predicate?
I search document, but not found solution
Stacktrace & log output
No response
Can you reproduce the bug?
Always
Reproduction Steps
No response
Version
all
What Atlas Services are you using?
Local Database only
Are you using encryption?
No
Platform OS and version(s)
iOS
Build environment
Xcode version: ...
Dependency manager and version: ...

Can you clarify the question? Including some code that demonstrates what's being attempted and your models.
If you're asking about filtering on a Realm Object property that's set to a PersistableEnum value, the answer is yes. But if not, what's the use case for filtering on an enum since it's essentially static data (a fixed set of related values)?

Hi, great thanks your feedback?
we have models:
`enum MSPlaylistType: String, PersistableEnum {
case systemMedia
case systemLastPlay
case systemFavorite
case systemHistory
case userCreated
case artist
case genre
case album
}
class MSPlaylist: Object, Identifiable {
@Persisted(primaryKey: true) public var playlistId      : String!
@Persisted public var title           : String?
@Persisted(indexed: true) var playlistType: MSPlaylistType = .userCreated
}
How can I filterMSPlaylistwithplaylistTypeisalbum`? I don't know write that filter with predicate? I search on google but not found any solution.

You're going to love this!
Here are your original enum and object, noting I changed how the primaryKey is instantiated - nothing to do with the solution.
enum MSPlaylistType: String, PersistableEnum {
    case systemMedia
    case systemLastPlay
    case systemFavorite
    case systemHistory
    case userCreated
    case artist
    case genre
    case album
}

class MSPlaylist: Object, Identifiable {
    @Persisted(primaryKey: true) var _id: ObjectId
    @Persisted public var title : String?
    @Persisted(indexed: true) var playlistType: MSPlaylistType = .userCreated
}

And then some code to write an artist and genre and then query for them
let p0 = MSPlaylist()
p0.playlistType = .artist

let p1 = MSPlaylist()
p1.playlistType = .genre

try! realm.write {
    realm.add(p0)
    realm.add(p1)
}

and then query
let artistResults = realm.objects(MSPlaylist.self).where { $0.playlistType == .artist}
print(artistResults)

let genreResults = realm.objects(MSPlaylist.self).where { $0.playlistType == .genre}
print(genreResults)

There you go!
Try to implement some of the new styles of doing queries that are more type safe than Predicates. See here .where
Going forward try to ask general programming questions in the forums or on StackOverflow - leave git for more bug-level reporting issues.

Great thank your support.

repo: realm/realm-swift


text:
Add feBlend implementation

Add Blend filter effect implementation and add the parser for the already implemented filters.

Great!

authors: Lemmih joseedil

repo: reanimate/reanimate-svg


text:
Slow contextual toolbar in Arrange context

Hi. I use action 'Exclusive toggle contextual toolbar under mouse cursor, preset 1' and I noticed that in reaper 6.56 there is delay in showing (and closing) toolbar in Arrange context. But it's ok in TCP and Ruler.
SWS version is 2.13 (fix cycle action add action)

Hm...I can't reproduce (which would be important for looking into it), for me it shows/closes instantly.
Can you confirm the issue started with Reaper 6.56 (and doesn't happen it Reaper 6.55 and before)?
At first glance I can't see anything in the changelog in 6.56 which should have caused this:
v6.56 - April 25 2022
  + Media items: allow autoscroll when moving/copying items using certain customized mouse modifiers [t=265871]
  + Media items: allow copying per-take FX from locked media items
  + Media items: do not allow opening, deleting, or copying to per-take FX of locked media items
  + Render: fix stereo/multichannel metering (6.55 regression) [p=2550803]
  + RF64: fix duplicate display of embedded cues [t=265078]

Can you provide any additional info which might be relevant, maybe post a screenshot of your contextual toolbar setup for Preset 01?
btw.

SWS version is 2.13 (fix cycle action add action)

SWS v2.13.1 with this fix is out officially, recommended to update to this version :))
https://www.sws-extension.org/download/pre-release/

Thank you for reply. Now I think that reaper version is irrelevant. I tried
it in clean (except sws installed) portable 6.44 and it was fine. Then I
updated it to 6.57 and still fine. So I guess something wrong with my
setup. But don't know what exactly. Tried to remove all extensions except
SWS and disable all running scripts. No luck. Will keep looking.
I also noticed that there is delay in TCP too but in "Empty" context.
Screenshot and video attached.
Thanks, updated to v2.13.1 already. Can I provide anything else useful?

What you could try for troubleshooting (though it's a wild guess), open the file BR.ini from your actual Reaper install in a text editor (you can run action 'Show REAPER resource path in explorer' to find it), and delete the whole [ContextualToolbars] section (see pic), it gets recreated when you press 'Save' in the Contextual Toolbar window (make a copy of the original file first, just in case...).
Maybe it got corrupted or something, that's the only other idea I have currently.

Ok, we got him!
Recently I used workaround from this post https://forums.cockos.com/showpost.php?p=2390978&postcount=6. It's a langpack file with 4 lines to change "untitled MIDI item" and "glued" in Items names to something. Somehow this langpack effects Contextual toolbars. So I changed language to default, restarted reaper and now it's great again.
Out of curiosity I tried empty .txt as langpack and actual langpacks and it seems it creates issue too. So you might want to take a look at this. Thanks!

authors: jopoet nofishonfriday

repo: reaper-oss/sws

license: MIT


text:
Actions: Fix 'SWS: Time-select {previous,next} region'

(actually time-select, not loop)
fixes #1648

:white_check_mark: Build sws 768-master completed (commit https://github.com/reaper-oss/sws/commit/25df931e59 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-2.13.1.0-Windows-x64-fix-time-select-next-prev-region-25df931e.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-2.13.1.0-Windows-x86-fix-time-select-next-prev-region-25df931e.exe

macOS x86 64-bit

build/sws-2.13.1.0-Darwin-x86_64-fix-time-select-next-prev-region-25df931e.dmg

macOS x86 32-bit

build/sws-2.13.1.0-Darwin-i386-fix-time-select-next-prev-region-25df931e.dmg

macOS ARM 64-bit

build/sws-2.13.1.0-Darwin-arm64-fix-time-select-next-prev-region-25df931e.dmg

Linux x86 64-bit

build/sws-2.13.1.0-Linux-x86_64-fix-time-select-next-prev-region-25df931e.tar.xz

Linux x86 32-bit

build/sws-2.13.1.0-Linux-i686-fix-time-select-next-prev-region-25df931e.tar.xz

Linux ARM 64-bit

build/sws-2.13.1.0-Linux-aarch64-fix-time-select-next-prev-region-25df931e.tar.xz

Linux ARM 32-bit

build/sws-2.13.1.0-Linux-armv7l-fix-time-select-next-prev-region-25df931e.tar.xz

authors: AppVeyorBot nofishonfriday


text:
Text component doesn't inherit all typography styles

I've recently migrated to version 4 but it doesn't look like the Text component is inheriting all of the typography styles expected from the body property on fonts.
See CodeSandbox example.
I've double-checked the implementation with your documentation, but I can't seem to see what could be wrong. Could you provide any additional direction?

The Text component is unopinionated as to whether it is intended to be used as body, heading or something else. Hence it does not include a default font family.
What you can do is make your own wrapper around it providing the typographic styles you want, or if you just want to alter all defaults you can use for example Global styles if you are using Emotion, and reference your theme's font family there.

@marozzocom Thank you for your reply. This makes sense, I have no problem extending the component or adding global styles to correct the font.
The documentation's example is confusing. The styled-system theming suggests being able to modify the body font-family and font weight: (Theming: Example)
  fonts: {
    body: 'system-ui, sans-serif',
    heading: 'inherit',
    monospace: 'Menlo, monospace',
  },
  fontWeights: {
    body: 400,
    heading: 700,
    bold: 700,
  },

What does the body attribute in styled-sytem themes actually modify then?

@brettinternet No problem, and I definitely don't know everything about Rebass, but I believe the body doesn't change anything, and it is simply an example of how you can have different styles in a theme file. But as default, only the Heading element uses one of these variants from the theme,
I agree that the documentation is perhaps a little bit confusing at times. It also says that the Heading is an "Extension of the Text component for headings" while it actually is an extension of the Box component just like Text and all other Rebass components, only with more preset props.
I am not sure exactly how much reasoning there is behind each design choice of Rebass components, but where it doesn't exactly fit your needs you can basically create your own typography components based on the Box component, using whatever default variants and styles work best for you. You can use Rebass components' source code as a reference.
I believe this is what the authors of the package would suggest, as they probably want to keep the Rebass library itself as light and simple as possible.

@jxnblk Are there plans to make the Text component operate more like the Heading component, or more optimal for themed text?
If not could we provide clearer documentation about which attributes the components use within the theme object (Theme: Example or Text)? The theme documentation directs users to the system-ui theme specification without a clear declaration of which theme properties each component uses/doesn't use.
I have a lot of respect for the simplicity and elegance in this project, I hope that this feedback can contribute to improving these wonderful aspects.

By default the Text component doesn't pick up particular styles from the theme. You can extend the component if you'd like to add default styles to the component

I just started using Rebass and spent about an hour trying to figure out why the Heading component was getting its font set but the Text component was not 😕
Is there some reason why the Text component doesn’t use the body property from Theme UI?
If the way it works is “By default the Text component doesn't pick up particular styles from the theme” then OK, but it feels surprising and it would be great to explain that somewhere… if it is I must’ve missed it.

It's documented in the Variants docs, but could also be mentioned in the Text component docs

what does the fonts.body set then? I would think that if  inherits from fonts.heading, then  and  would inherit from fonts.body. But it doesn't.
fonts: {
    body: 'courier', // <Text>  is not getting these styles
    heading: '"Barlow Condensed", Helvetica, sans-serif', // <Header> is getting these styles
  }

authors: brandonweiss brettinternet jxnblk marozzocom stoplion

repo: rebassjs/rebass


text:
undefined method `retrieve' for #Stripe::StripeObject:0x007fa9590ae268

Doing either:
cus.subscriptions.retrieve(subscription_id)
or
cus.sources.retrieve(cus.default_source)
Causes this issue. It's like nested objects aren't mapping to the correct methods or something?

I am not able to reproduce this. What version of stripe and stripe-ruby-mock  are you using ?
Apart from that, this issue isn't related to this repo, as given object is from stripe gem.
Sidenote -  retrieve is getting called on Stripe::StripeObject, but cus.subscriptions is of Stripe::ListObject type.

Well, it works using the stripe gem, not using stripe-ruby-mock, that's what I'm saying. Mock is 2.2.1, Stripe is 1.31.0

Same issue.

@TrevorHinesley @slash7 still can't reproduce the error. Do you use gem from rubygems or github Mock repository in your projects?

+1 with stripe-mock 2.2.1 & stripe 1.31.0

Having the same issue. The retrieve method works with the Stripe gem, but doesn't work with Stripe Mock. The stack trace also indicates the source of the error is with the Stripe gem:
stripe (1.31.0) lib/stripe/stripe_object.rb:281:in method_missing'`
However, is it possible the 1.3.1 Stripe gem is using a newer version of the Stripe REST API vs. what StripeMock is using? It seems as though the Stripe ruby client is configured remotely and queries the API for configuration. This API version is set from the settings in Stripe dashboard, so that would explain the inconsistent results above.

Might Stripe mock be incompatible with the Stripe gem for newer versions of the Stripe API? @alexmamonchik @yogeshjain999 Are you both using an older version of the API?
Also, I found a related issue here: https://github.com/stripe/stripe-ruby/issues/88.

Interestingly, reverting the Stripe gem back to 1.20.1 with stripe-ruby-mock 2.1.1 resolves the issue in tests. 1.20.1 is about a year old though, so I'm very reluctant to use it in production.

@Aerlinger thanks for your opinion. That's very important for us. I use latest API version - "2016-02-23" and stripe (1.31.0) and StripeMock 2.2.1 from repo, not from rubygems. And I can't reproduce your error. I tried with older stripe and older API. May you help with that? That's open source gem, community contributes it, not only me. When  I have time I'll back to research your problem. But will be better if you do it. Don't use it in production, wait until someone fixed your problem.

For what it's worth I'm seeing the same issue with stripe 1.31.0 and stripe-ruby-mock 2.2.1. Pulling stripe-ruby-mock from master resolves the issue.

@ryanlntn @Aerlinger @matteomelani @slash7 @yogeshjain999 plsease, try stripe mock 2.2.2

Had a similar issue in an old project that had an old version of Stripe Gem. I updated stripe to 1.31.x and also this gem to 2.2.2 and now it appears to wrok. Thanks @alexmamonchik

authors: Aerlinger TrevorHinesley alexmamonchik matteomelani ryanlntn slash7 yogeshjain999 ziyan-junaideen

repo: rebelidealist/stripe-ruby-mock

license: mit

license_source: bigquery


text:
コンポーネント設計

https://bootcamp.fjord.jp/products/18978
の各画面のコンポーネント設計。
参考
https://qiita.com/yusuke_blog1026/items/c68c45790a977cbd0715

https://www.figma.com/design/oUdXucFNoiiIep1SXgzMZO/Untitled?node-id=0-1&t=64ifKqA7IFBmPs38-0
一旦完了。

repo: reckyy/tsundoku


text:
Pin circle's starting point and prevent overflow

I pinned the starting point of circle and prevented shape overflowing.
Additionally, I tried to prevent shape overflow while drawing circle by calculating cx, cy, r from formula but failed(Prevented overflow successfully on the Y axis, but not X-axis).
// many codes...
    } else if (cy + r > naturalHeight) {
      // radius = naturalHeight - cy
      const a = 1, b = -2*((A**2+1)*this.anchor[1]-A**2*naturalHeight), c = (A**2+1)*this.anchor[1]**2-A**2*naturalHeight**2;
      cy = getRoot(this.anchor[1], oppositeY, getRootCandidates(a, b, c));
      console.log("case 4: ", getRootCandidates(a, b, c))
      cx = (A===0) ? this.anchor[0] + naturalHeight - cy : (cy-B)/A;
      r = naturalHeight - cy;
    }

So, I just prevented number of cases with return.
RubberbandCircle.js - line:57
if ((cx-r < 0 || cx + r > naturalWidth) || (cy-r < 0 || cy + r > naturalHeight)) return;

I don't know whether it's normal behavior or not. So, if it is abnormal procedure,  I'd appreciate it if you could let me know.

That's excellent, many thanks!

repo: recogito/annotorious-selector-pack


text:
Move DataProviderArrayItemsNewlinedRector to rector-phpunit

Shouldn't this rule DataProviderArrayItemsNewlinedRector be placed in this repository instead of main repository?
in theory yes https://github.com/rectorphp/rector/blob/main/rules/CodingStyle/Rector/ClassMethod/DataProviderArrayItemsNewlinedRector.php#L96
😄

That would be better location indeed :)

authors: TomasVotruba eerison

repo: rectorphp/rector-phpunit


text:
[CodeQualitiy] Use str_ends_with instead of isName(, '*Test')

@TomasVotruba @staabm here based on https://github.com/rectorphp/rector-src/pull/4980#issuecomment-1713784117

All checks have passed 🎉 @TomasVotruba I am merging it ;)


text:
Update contributing guide using OWNER_ALIASES

Added instructions about how to use tide plugin of openshift ci into contribution.md file.
Updated the OWNERS file to use OWNERS_ALIASES

Description

How Has This Been Tested?

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] For commits that came from upstream, [UPSTREAM] has been prepended to the commit message.
[x] JIRA link(s): https://issues.redhat.com/browse/RHODS-2769, https://issues.redhat.com/browse/RHODS-3396
[ ] The Jira story is acked.
[ ] Live build image:
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work.
[ ] QE contact acknowledges that this has been tested and is approved for merge.

Thank you for your feedback and for noticing this points! I have updated the PR with the last comments.

/qe-approved

/uncc @crobby due to No longer valid.

repo: red-hat-data-services/odh-deployer


text:
BUG 2030742 rbd: reset dummy image id

dummy image rbdVolume struct is derived from the actual one rbdVolume of the volumeID sent in the EnableVolumeReplication request. and the dummy rbdVolume struct contains the image id of the actual volume because
of that when we are repairing the dummy image the image is sent to trash but not deleted due to the wrong image ID. resetting
the image id will makes sure the image id is fetching from ceph cluster and same image id will be used for manager operation.
Signed-off-by: Madhu Rajanna madhupr007@gmail.com
(cherry picked from commit 810e285c5043692348b4e9357958726483ff6800)
backport of https://github.com/ceph/ceph-csi/pull/2733
Note:- should get  merged after https://github.com/red-hat-storage/ceph-csi/pull/60

/assign @agarwal-mudit

repo: red-hat-storage/ceph-csi


text:
Bug 2293611: [release-4.16] Backport cleanup maintenance addon

Backport of #226

/do-not-merge

/test integration-test


text:
Bug 2254547: object: improve the error handling for multisite objs

here is the https://go.dev/play/p/SS9Q-dAiIx3 example which says the error handling was wrongly implemented
Signed-off-by: parth-gr paarora@redhat.com
(cherry picked from commit 46c241433d8722c911bff953dbe8c6c302240a95)

Description of your changes:
Which issue is resolved by this Pull Request:
Resolves #
Checklist:

[ ] Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide).
[ ] Skip Tests for Docs: If this is only a documentation change, add the label skip-ci on the PR.
[ ] Reviewed the developer guide on Submitting a Pull Request
[ ] Pending release notes updated with breaking and/or notable changes for the next minor release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

This test is failing in the object suite:
--- FAIL: TestCephObjectSuite/TestWithTLS/run_a_second_object_store/create_CephObjectStore (400.56s)

I seem to recall we didn't backport this change to 1.12 upstream because of this error. Any insight to the failure?

runner@fv-az1204-469:~/work/rook/rook$ kubectl describe cephobjectstore -nobject-ns other-tls-test-store
Name:         other-tls-test-store
Namespace:    object-ns
Labels:       <none>
Annotations:  <none>
API Version:  ceph.rook.io/v1
Kind:         CephObjectStore
Metadata:
  Creation Timestamp:  2024-01-30T15:37:20Z
  Finalizers:
    cephobjectstore.ceph.rook.io
  Generation:        2
  Resource Version:  6306
  UID:               1f190946-165b-41db-9b51-bf13c0a8e99e
Spec:
  Data Pool:
    Erasure Coded:
      Coding Chunks:  0
      Data Chunks:    0
    Mirroring:
    Quotas:
    Replicated:
      Size:  1
    Status Check:
      Mirror:
  Gateway:
    Instances:  1
    Placement:
    Resources:
    Secure Port:          80
    Ssl Certificate Ref:  other-tls-test-store
  Health Check:
  Metadata Pool:
    Compression Mode:  passive
    Erasure Coded:
      Coding Chunks:  0
      Data Chunks:    0
    Mirroring:
    Quotas:
    Replicated:
      Size:  1
    Status Check:
      Mirror:
  Zone:
    Name:
Status:
  Endpoints:
    Insecure:
    Secure:
      https://rook-ceph-rgw-other-tls-test-store.object-ns.svc:80
  Phase:  Failure
Events:
  Type     Reason           Age                 From                         Message
  ----     ------           ----                ----                         -------
  Warning  ReconcileFailed  16m (x19 over 41m)  rook-ceph-object-controller  failed to reconcile CephObjectStore "object-ns/other-tls-test-store". failed to create object store deployments: failed to configure multisite for object store: failed create ceph multisite for object-store ["other-tls-test-store"]: failed to create ceph ["zone" "--rgw-zone=other-tls-test-store" "unable to initialize zonegroup other-tls-test-store: (2) No such file or directory. "] %!q(MISSING), for reason %!q(MISSING): exit status 2
runner@fv-az1204-469:~/work/rook/rook$

I see this, which the original issue why the BZ was reported

It is because the zonegroup is not created
sh-4.4$ radosgw-admin zonegroup get --rgw-zonegroup=other-tls-test-store
failed to load zonegroup: (2) No such file or directory

As discussed offline, the realm arg isn't being passed for the zonegroup get.

It seems the zonegroup is still failing. From the operator log:
2024-01-30 20:21:53.033880 D | ceph-object-controller: creating realm, zone group, zone for object-store other-tls-test-store
2024-01-30 20:21:53.033930 D | exec: Running command: radosgw-admin realm get --rgw-realm=other-tls-test-store --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring
2024-01-30 20:21:53.148372 D | exec: Running command: radosgw-admin realm create --rgw-realm=other-tls-test-store --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring
2024-01-30 20:21:53.251465 D | ceph-object-controller: created "realm" "--rgw-realm=other-tls-test-store"
2024-01-30 20:21:53.251507 D | exec: Running command: radosgw-admin zonegroup get --master --rgw-zonegroup=other-tls-test-store --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring
2024-01-30 20:21:53.351694 D | op-osd: checking osd processes status.
2024-01-30 20:21:53.351732 D | exec: Running command: ceph osd dump --connect-timeout=15 --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring --format json
2024-01-30 20:21:53.552867 D | exec: Running command: radosgw-admin zone get --rgw-zone=other-tls-test-store --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring
2024-01-30 20:21:53.658482 D | exec: Running command: radosgw-admin zone create --master --endpoints=https://rook-ceph-rgw-other-tls-test-store.object-ns.svc:80 --rgw-realm=other-tls-test-store --rgw-zonegroup=other-tls-test-store --rgw-zone=other-tls-test-store --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring
2024-01-30 20:21:53.800493 D | ceph-object-controller: object store "object-ns/other-tls-test-store" status updated to "Failure"
2024-01-30 20:21:53.800637 D | clusterdisruption-controller: reconciling "object-ns/"
2024-01-30 20:21:53.800768 D | ceph-spec: update event from a CR: "other-tls-test-store"
2024-01-30 20:21:53.800808 D | ceph-spec: update event on CephObjectStore CR
2024-01-30 20:21:53.800906 D | ceph-spec: update event from a CR: "other-tls-test-store"
2024-01-30 20:21:53.800921 D | ceph-spec: update event on CephObjectStore CR
2024-01-30 20:21:53.801095 D | clusterdisruption-controller: could not match failure domain. defaulting to "host"
2024-01-30 20:21:53.808505 D | op-k8sutil: kubernetes version fetched 1.27.2
2024-01-30 20:21:53.810586 D | op-k8sutil: kubernetes version fetched 1.27.2
2024-01-30 20:21:53.810716 D | exec: Running command: ceph status --connect-timeout=15 --cluster=object-ns --conf=/var/lib/rook/object-ns/object-ns.config --name=client.admin --keyring=/var/lib/rook/object-ns/client.admin.keyring --format json
2024-01-30 20:21:53.822881 D | ceph-object-controller: object store "object-ns/other-tls-test-store" status updated to "Failure"
2024-01-30 20:21:53.822971 E | ceph-object-controller: failed to reconcile CephObjectStore "object-ns/other-tls-test-store". failed to create object store deployments: failed to configure multisite for object store: failed create ceph multisite for object-store ["other-tls-test-store"]: failed to create ceph ["zone" "--rgw-zone=other-tls-test-store" "unable to initialize zonegroup other-tls-test-store: (2) No such file or directory. "] %!!(MISSING)q(MISSING), for reason %!!(MISSING)q(MISSING): exit status 2

Got fixed

authors: parth-gr travisn

repo: red-hat-storage/rook


text:
Fixed invalid Message Expiry Interval.

Message Expiry Interval is applied the following case. A PUBLISH packet send from the broker and the packet is not for re-sending.
So the Message Expiry target cases are:

RETAIN
WILL
A new PUBLISH message delivering to the client but the corresponding session offline.

But the following case is NOT the Message Expiry target:

PUBLISH message delivering to the client has been triggered but the corresponding session  offline during the sequence.

This fix removes 4 from the targets.

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

Project coverage is 97.30%. Comparing base (26324f6) to head (dca8342).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #369      +/-   ##
==========================================
- Coverage   97.32%   97.30%   -0.03%
==========================================
  Files         154      154
  Lines        9511     9466      -45
==========================================
- Hits         9257     9211      -46
- Misses        254      255       +1

Files with missing lines
Coverage Δ

include/async_mqtt/util/store.hpp
95.74% <100.00%> (+0.39%)
:arrow_up:

... and 2 files with indirect coverage changes

authors: codecov-commenter redboltz


text:
gcc 8.3.0 high memory usage

Hello!
Compiling the simple subscriber example integrated into my application consumes additional 4GB+ RAM when compiling with gcc version 8.3.0.
I could also find #522 about that. But simply reducing the parallel build is no solution.
Last time I tested this lib v9.0.0 was used.
Was this issue addressed between v9.0.0 and v12.0.0?

No. But some of updates could change memory usage.
I think that 4GB is too small. mqtt_cpp doesn't focus on reducing compile time memory usage, so far.
I recommend that add memory on compiler environment. If it is embedded environment, use cross compiler.
clang++ might use smaller memory, I'm not sure.

I'm very sad to say that at this point it seems that the library is not usable in any complex projects.... It's a shame because I really liked this approach and the use of boost.asio, but the insane compilation times and memory usage make it a pain to work with.

Yes it is sad, I also never experienced such bad compile-time memory / cpu usage with any library. Template/header-only libraries are hard to master.

authors: Bart97 kodidu redboltz


text:
Enable programmatic check of process execution result

Usecase
Invoke-AtomicTest is used to run a sequence of tests. This sequence is chained to a sequence of API calls to the SIEM supposed to detect these activities. Then, a test report is generated.
In this context, it is important to know where the test failed: because it couldn't run on the target or because the SIEM was blind.
One needs to confirm the successful execution of Atomic Tests.
Current Implementation
Unless called with -Interactive, the standard out and error streams are directed to the temporary folder art-out.txt and art-err.txt. The content of these files are sent to the main output once the process terminated, and are deleted. The Invoke-AtomicTest cmdlet doesn't return the process exit code.
As multiple tests may be run in a single invocation, it isn't easy to provide detailed results for every one of them without adding much complexity to the code.
Suggested Implementation
Add a switch -KeepStdOutStdErrFiles to bypass the Remove-Item instruction. It is then to the caller to ensure they clean the files at the right moment (which implies to restrict invocations to a single test, otherwise the output of every test will contain the previous ones as well). This way, the caller may check standard out and error streams for trace of errors.
Tools such as mimikatz don't output their errors to stderr, that's why we may need to check both files.
The check could look like this:
if (((Test-Path -Path "${Env:TEMP}/art-err.txt") -and (Select-String "(ERROR|Exception)" "${Env:TEMP}/art-err.txt")) -or
    ((Test-Path -Path "${Env:TEMP}/art-out.txt") -and (Select-String "(ERROR|Exception)" "${Env:TEMP}/art-out.txt"))) {
          Write-Debug ">>> Error in stream, marking test as failed in Atomic"
          [...]
}

PR on its way.

After playing a bit with it, the output files are cleared every time a new process is created, which lightens the burden of deleting them every time (especially in remote sessions). Additionally, calling -Clean on a test removes the files.

It appears some tools like procdump output to stderr what should be sent to stdout. I updated the test code sample above accordingly.

That's a very good idea! I needed the same and I had to trick it 😉 (I aliased Remove-Item to nothing so it had no action)

authors: Jil cnotin

repo: redcanaryco/invoke-atomicredteam


text:
The future of Bashark

Red Code Lab’s team is looking to expand Bashark. We’re looking for ideas and contributions from the community on what recon, pre-exploitation, and exploitation inclusions you’d like to see.
All feedback and contributions are welcome. Thank you.
Edit: please, just behave like civilized people and write non-offensive comments, thank you

Hey, I am interested in your project, how about you suck my balls?

Aye while ya at it can i get me balls sucked aswell?

Aye i want my dick sucked too

it s good use for us?

no, Why?

De: yanabcd @.>
Enviado: terça-feira, 20 de setembro de 2022 10:46
Para: redcode-labs/Bashark @.>
Cc: Subscribed @.***>
Assunto: Re: [redcode-labs/Bashark] The future of Bashark (#6)
it s good use for us?
—
Reply to this email directly, view it on GitHubhttps://github.com/redcode-labs/Bashark/issues/6#issuecomment-1252172902, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITXMF4JJJGL46SDELCUP6DV7GIY5ANCNFSM477OLERA.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

authors: bagshitter marciopocebon radva unrooted x2taptap yanabcd

repo: redcode-labs/Bashark


text:
Lazily create context attributes attached via baseplate.add_to_context

This changes clients added to requests to be created lazily. The idea is that most requests do not access all of the clients added via baseplate.add_to_context. We should be able to save work by not creating clients that are never accessed.

This micro benchmark seems to indicate that there is potential here. We should observe the performance on a real service though.
Benchmark code:
# coding=utf8

import time

from baseplate import Baseplate
from baseplate.context.thrift import ThriftContextFactory
from baseplate.thrift_pool import ThriftConnectionPool
from baseplate.integration.thrift import RequestContext
from baseplate.core import ServerSpan

from genpy.test import TestService

ITERATIONS = 100000
CLIENTS = 20

def main():
    baseplate = Baseplate()
    baseplate.configure_logging()

    for i in range(CLIENTS):
        pool = ThriftConnectionPool(None)
        context_factory = ThriftContextFactory(pool, TestService.Client)
        baseplate.add_to_context('thrift_client_{}'.format(i), context_factory)

    for clients_to_access in range(CLIENTS):
        finals = []
        for _ in range(3):
            elapsed = 0
            for _ in range(ITERATIONS):
                context = RequestContext()
                start = time.time()
                baseplate.make_server_span(context, "example_service")
                for i in range(clients_to_access):
                    getattr(context, 'thrift_client_{}'.format(i))
                end = time.time()
                elapsed += end-start
            finals.append(elapsed)

        print("Time elapsed to create %d spans (%d clients, %d touched) = %0.4f seconds (%0.2fμs / per)" % (ITERATIONS, CLIENTS, clients_to_access, min(finals), min(finals)/ITERATIONS*1e6))

if __name__ == "__main__":
    main()

Current behavior:
Time elapsed to create 100000 spans (20 clients, 0 touched) = 6.3250 seconds (63.25μs / per)
Time elapsed to create 100000 spans (20 clients, 1 touched) = 6.3950 seconds (63.95μs / per)
Time elapsed to create 100000 spans (20 clients, 2 touched) = 6.4605 seconds (64.60μs / per)
Time elapsed to create 100000 spans (20 clients, 3 touched) = 6.5612 seconds (65.61μs / per)
Time elapsed to create 100000 spans (20 clients, 4 touched) = 6.7313 seconds (67.31μs / per)
Time elapsed to create 100000 spans (20 clients, 5 touched) = 6.6034 seconds (66.03μs / per)
Time elapsed to create 100000 spans (20 clients, 6 touched) = 6.6752 seconds (66.75μs / per)
Time elapsed to create 100000 spans (20 clients, 7 touched) = 7.1518 seconds (71.52μs / per)
Time elapsed to create 100000 spans (20 clients, 8 touched) = 6.7308 seconds (67.31μs / per)
Time elapsed to create 100000 spans (20 clients, 9 touched) = 6.9472 seconds (69.47μs / per)
Time elapsed to create 100000 spans (20 clients, 10 touched) = 6.9752 seconds (69.75μs / per)
Time elapsed to create 100000 spans (20 clients, 11 touched) = 6.9691 seconds (69.69μs / per)
Time elapsed to create 100000 spans (20 clients, 12 touched) = 6.9107 seconds (69.11μs / per)
Time elapsed to create 100000 spans (20 clients, 13 touched) = 6.9144 seconds (69.14μs / per)
Time elapsed to create 100000 spans (20 clients, 14 touched) = 6.9416 seconds (69.42μs / per)
Time elapsed to create 100000 spans (20 clients, 15 touched) = 7.0143 seconds (70.14μs / per)
Time elapsed to create 100000 spans (20 clients, 16 touched) = 7.0484 seconds (70.48μs / per)
Time elapsed to create 100000 spans (20 clients, 17 touched) = 7.0342 seconds (70.34μs / per)
Time elapsed to create 100000 spans (20 clients, 18 touched) = 7.0700 seconds (70.70μs / per)
Time elapsed to create 100000 spans (20 clients, 19 touched) = 7.1635 seconds (71.64μs / per)

New behavior:
Time elapsed to create 100000 spans (20 clients, 0 touched) = 3.9924 seconds (39.92μs / per)
Time elapsed to create 100000 spans (20 clients, 1 touched) = 4.4060 seconds (44.06μs / per)
Time elapsed to create 100000 spans (20 clients, 2 touched) = 4.7910 seconds (47.91μs / per)
Time elapsed to create 100000 spans (20 clients, 3 touched) = 5.0533 seconds (50.53μs / per)
Time elapsed to create 100000 spans (20 clients, 4 touched) = 5.3657 seconds (53.66μs / per)
Time elapsed to create 100000 spans (20 clients, 5 touched) = 6.0241 seconds (60.24μs / per)
Time elapsed to create 100000 spans (20 clients, 6 touched) = 6.1715 seconds (61.72μs / per)
Time elapsed to create 100000 spans (20 clients, 7 touched) = 6.5259 seconds (65.26μs / per)
Time elapsed to create 100000 spans (20 clients, 8 touched) = 6.8693 seconds (68.69μs / per)
Time elapsed to create 100000 spans (20 clients, 9 touched) = 7.1974 seconds (71.97μs / per)
Time elapsed to create 100000 spans (20 clients, 10 touched) = 7.5539 seconds (75.54μs / per)
Time elapsed to create 100000 spans (20 clients, 11 touched) = 7.8392 seconds (78.39μs / per)
Time elapsed to create 100000 spans (20 clients, 12 touched) = 8.4427 seconds (84.43μs / per)
Time elapsed to create 100000 spans (20 clients, 13 touched) = 8.6876 seconds (86.88μs / per)
Time elapsed to create 100000 spans (20 clients, 14 touched) = 8.9292 seconds (89.29μs / per)
Time elapsed to create 100000 spans (20 clients, 15 touched) = 9.2837 seconds (92.84μs / per)
Time elapsed to create 100000 spans (20 clients, 16 touched) = 9.5161 seconds (95.16μs / per)
Time elapsed to create 100000 spans (20 clients, 17 touched) = 9.9022 seconds (99.02μs / per)
Time elapsed to create 100000 spans (20 clients, 18 touched) = 10.1899 seconds (101.90μs / per)
Time elapsed to create 100000 spans (20 clients, 19 touched) = 10.5285 seconds (105.29μs / per)

👓 @spladug

A couple questions:

Those benchmarks concern me a bit, once you use 5 or 6 clients, the behavior is about the same and gets much worse the more you access, so I think we would need to test this out in the real world to see it's effect.
If we do decide to do this, could we use something like this? https://github.com/reddit/baseplate/blob/0f2cf46345ba37a088078e954f4e5edf5cc37cc9/baseplate/_utils.py#L28

@pacejackson

Those benchmarks concern me a bit, once you use 5 or 6 clients, the behavior is about the same and gets much worse the more you access, so I think we would need to test this out in the real world to see it's effect.

Yeah, it does seem to get worse if you start accessing a lot of things. Neil and I discussed doing exactly what you're suggesting. I think we are gonna try rolling it out to graphql since it is one of the extreme cases with a bunch of clients. We will see how it behaves there and decide if this is worth moving forward with.

If we do decide to do this, could we use something like this?
So this was actually the first path that I went down. It turns out that you can't just attach a property to an instance. They have to be attached to classes. I dug into how Pyramid's add_request_method method works and came to this interesting code:
https://github.com/Pylons/pyramid/blob/80baff6e61d775dc34bb11b7d6c8ef8569da1c40/src/pyramid/util.py#L76

They actually create a class per instance and swap out the __class__ beneath you. It's pretty interesting, but it ended up being about 4-5x slower than our current code. This was mostly due to the creation of the new class here:
https://github.com/Pylons/pyramid/blob/80baff6e61d775dc34bb11b7d6c8ef8569da1c40/src/pyramid/util.py#L131
Their approach also brings concerns of possible memory leaks if we don't do it right. This led me to try this lighter-weight solution with __getattr__

💇

@spladug

note: this won't work on r2 but that's probably OK since we're gonna be dropping py2.7 support anyway.

Shouldn't this work as long as r2 uses baseplate's add_to_context and make_server_span methods? I see lots of calls to add_to_context in r2's app_globals file. I'm not sure how span creation happens though.

I'm gonna see if I can monkey patch this into graphql

r2's context object is pylons's tmpl_context global. We don't have any code in this PR for mixing-in our base class there so the lazy stuff won't be present.

r2's context object is pylons's tmpl_context global. We don't have any code in this PR for mixing-in our base class there so the lazy stuff won't be present.

Oh yeah. You told me this yesterday

I'm gonna see if I can monkey patch this into graphql
Since we have wheels, it's probably better to make a wheel of this branch and try using that in graphql?

Since we have wheels, it's probably better to make a wheel of this branch and try using that in graphql?

I'd prefer this. I'm just not sure how to make a wheel of this branch. Do I need to reach out to infra?

I created a ticket to get a wheel of this branch made. I'd just let this sit until then

This branch is off master right? If we wheel off that, any service using it will need to upgrade to apache thrift too. Might want to rebase onto the 0.28 series if you don't want that hassle.
Or you could try on activity service which is on apache thrift now, but won't be terribly interesting otherwise.

This branch is off master right? If we wheel off that, any service using it will need to upgrade to apache thrift too. Might want to rebase onto the 0.28 series if you don't want that hassle.

Changing my ticket to point to this branch:
https://github.com/reddit/baseplate/pull/254

I'm going to close this out as f30f1c5f6ca11d5b63aeae4016342217353caf3a..ec802fe16c56e961354742d993947ff8c621a9a5 is merged. Thanks so much for pioneering this and pushing for the improvement.

authors: bradengroom pacejackson spladug


text:
Move instrumentation back to modules instead of init

This is just targeting our working branch for opentelemetry. @chriskuehl and @KTAtkinson asked to have the instrumentation moved out of the top level modules so that they didn't go into effect on import.
I'm honestly not 100% sure what the problem is but it seems to be something around the ssl library getting loaded before it can be monkey patched. This then breaks urllib3.
This PR reverts the change, but if you have a better suggestion I'm all ears and can try to help validate it.

Here's an example error:
Apr 4 20:43:25 reddit-service-campaign-management-7b797d65cf-8vh9z reddit-service-campaign-management error [00] [01] {"level":"error","ts":1712263404.019811,"msg":"","worker_id":"campaign-management-6","worker_error_msg":"/usr/local/lib/venv/bin/baseplate-serve:12: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/usr/local/lib/venv/lib/python3.12/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/usr/local/lib/venv/lib/python3.12/site-packages/urllib3/util/__init__.py)']. "}

Sorry for the slow review -- I was hoping to dig into this a bit but haven't had time yet. I'll try to check on this probably next week and see if I can find anything about that error.

authors: chriskuehl trevorriles


text:
Appstudio update test-custom-default-branch-vvdk

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-yrqk-on-pull-request-
creating pipelinerun test-annotations-yrqk-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-nwtb-on-pull-request-
creating pipelinerun test-simple-build-nwtb-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-nyrh-on-pull-request-
creating pipelinerun test-simple-build-nyrh-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-mijr-on-pull-request-
creating pipelinerun test-annotations-mijr-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-ufgi-on-pull-request-
creating pipelinerun test-simple-build-ufgi-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-ntht-on-pull-request-
creating pipelinerun test-annotations-ntht-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-lqle-on-pull-request-
creating pipelinerun test-simple-build-lqle-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-uqzm-on-pull-request-
creating pipelinerun test-simple-build-uqzm-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-imul-on-pull-request-
creating pipelinerun test-simple-build-imul-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-dtnt-on-pull-request-
creating pipelinerun test-annotations-dtnt-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-wadk-on-pull-request-
creating pipelinerun test-simple-build-wadk-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-gcoj-on-pull-request-
creating pipelinerun test-annotations-gcoj-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-annotations-vchz-on-pull-request-
creating pipelinerun test-annotations-vchz-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: test-simple-build-mcmm-on-pull-request-
creating pipelinerun test-simple-build-mcmm-on-pull-request- in namespace build-e2e-vhsy-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request


text:
Appstudio update test-component-pac-snif

Pipelines as Code configuration proposal

Pipelines as Code CI/test-component-pac-snif-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
8 seconds
init

✅ Succeeded
16 seconds
clone-repository

✅ Succeeded
4 minutes
build-container

✅ Succeeded
2 minutes
inspect-image

✅ Succeeded
1 minute
deprecated-base-image-check

✅ Succeeded
5 minutes
clair-scan

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
34 seconds
sbom-json-check

✅ Succeeded
42 seconds
label-check

✅ Succeeded
41 seconds
optional-label-check

✅ Succeeded
16 seconds
show-sbom

✅ Succeeded
10 seconds
show-summary

Pipelines as Code CI/test-component-pac-snif-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
10 seconds
init

✅ Succeeded
40 seconds
clone-repository

✅ Succeeded
39 seconds
build-container

✅ Succeeded
11 seconds
inspect-image

✅ Succeeded
9 seconds
deprecated-base-image-check

✅ Succeeded
31 seconds
clair-scan

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
25 seconds
sbom-json-check

✅ Succeeded
16 seconds
label-check

✅ Succeeded
15 seconds
optional-label-check

✅ Succeeded
24 seconds
show-sbom

✅ Succeeded
30 seconds
show-summary


text:
Adding URLs and blank templates for all apps

Adding URLs to all apps.
Adding a blank HTML template page to every feature.
Linking URLs to templates via views
fix #71

What is the difference between signing and login?

Login is for registered users, and sign-in is for new users that want to register.
For now< we add users only via the admin screen, so the sign-in page isn't at top priority.
Still, I thought it would be worthwhile to prepare the ground for the moment we want to add this feature in the Feature.

What is the difference between signing and login?

Login is for registered users, and sign-in is for new users that want to register. For now< we add users only via the admin screen, so the sign-in page isn't at top priority. Still, I thought it would be worthwhile to prepare the ground for the moment we want to add this feature in the Feature.

Sign in and login means the same thing, it's supposed to be sign up or register. @OmerCS8

Should we add views/urls to the direct_message model if its not merged yet?

We already have a direct_message app so i think we should add the views and URLs. For now it's a blank template, but once the direct_message model will be merged we can alter the file.
(BTW we can work on the HTML and CSS of the direct messaging app even if the model hasen't been merged yet)

As we agreed, I removed the sign-up URL 👍

@OmerCS8 Please squash all the commits

@OmerCS8 Please squash all the commits

Squashed all the commits and ready to merge 👍 . @natifridman @halleelyasaf @abiton1

@OmerCS8 Please squash all the commits

Squashed all the commits and ready to merge 👍 . @natifridman @halleelyasaf @abiton1

@OmerCS8 Great! we need one more approval

authors: AlonShakaroff OmerCS8 natifridman yulisuliman

repo: redhat-beyond/ResuMe


text:
Added openshift-logforwarding-splunk to top README

What is this PR About?
Adding openshift-logforwarding-splunk to the list of links in the top-level README
How do we test this?
check link
cc: @redhat-cop/day-in-the-life

thanks @nilsotto 🤸♀

authors: ckavili nilsotto

repo: redhat-cop/helm-charts


text:
Ldap auth engine

This PR contains objects for new auth method, type LDAPAuthEngineConfig :

Create the CRD type and a validating webhooks for LDAPAuthEngineConfig
Update type specs and webhook
Generate CRD manifests
Add test for LDAPAuthEngineConfig
Add LDAPAuthEngineConfig section in readme

@erlisb is this ready for a final check, or are there more test you need to run?

@raffaelespazzoli, I did several tests locally. Seems to be okay.
I added also a ldap-setup step in the makefile. What else is needed ?

I added a bunch on nitpicks, sorry for not spotting them before. The I have two questions:

I don't see a mapping 1 to 1 between the fiuelds defined in the config CRD and the field described in the API doc (https://www.vaultproject.io/api-docs/secret/ad#configuration). Can you share the info you used?
why didn't you also map the role api? I get not mapping the check-in/out and library API, but what about the role. Would it make sense to do it?

I added a bunch on nitpicks, sorry for not spotting them before. The I have two questions:

I don't see a mapping 1 to 1 between the fiuelds defined in the config CRD and the field described in the API doc (https://www.vaultproject.io/api-docs/secret/ad#configuration). Can you share the info you used?
why didn't you also map the role api? I get not mapping the check-in/out and library API, but what about the role. Would it make sense to do it?

I added a bunch on nitpicks, sorry for not spotting them before. The I have two questions:

I don't see a mapping 1 to 1 between the fiuelds defined in the config CRD and the field described in the API doc (https://www.vaultproject.io/api-docs/secret/ad#configuration). Can you share the info you used?
why didn't you also map the role api? I get not mapping the check-in/out and library API, but what about the role. Would it make sense to do it?

@raffaelespazzoli thanks for your review.
regarding 1. I used this info  and set every field to camel case (followed same conventions as in the KubernetesAuthEngineConfig)
regarding 2. I don't get what you mean by role ? I thought a role was not needed in this Auth method. Are you referring to LDAP Groups & Users ? If yes, I was considering this for an upcoming PR.

ok, so I was confusing the auth engine with the secret engine, my bad. What you have is good sorry.
There is one last comment open. Also commit (https://github.com/redhat-cop/vault-config-operator/pull/51/commits/f9595dd369f50bd079c3ee322befaea3b100671b) didn't seem necessary, maybe you want to undo it.
Then we are ready to go I think.

authors: erlisb raffaelespazzoli

repo: redhat-cop/vault-config-operator


text:
Group changes

For channels and subscriptions, group is changed from eventing.knative.dev to messaging.knative.dev

cc @kameshsampath


text:
Package the Build API - without OLM

How would we lifecycle the contoller/CRDs ?

I think the lifecycle for Controller and Operator are different.
If it is an Operator, like Tekton Operator, then you can manage the controller and CRDs inside of the Operator, update or do something or it.
But I think for this repo, it is a build controller, it include the function logic, doesn't include the operation logic.
If there is no easy way, I think like other controllers, we can document in README that let user how to install or update it. And the operation team will handle that.
like our side, our admin manages the controller lifecycle by using Concourse pipeline, if there is any Git release is published. the pipeline will redo the deploy steps:
kubectl apply -f deploy/crds/
kubectl apply -f deploy/
etc ....
to update the crds and controller with new image

So what we call an operator is just code that creates and initialize controllers(via the manager). From my experience, is a best practice to allow the operator also to generate on the fly & install the required controllers CRDs. I guess this is why the Tekton Operator does it, and I would prefer that this build operator does the same. I think is better to reduce dependencies prior to the build operator initialization.
I´m not sure if the above is a lifecycle management of CRDs. I think is not, while it just installs them, and any future CRD definition change, will imply a restart of the operator.
@sbose78 if you are behind a controller life-cycle managent, I think you need a helm chart. And to be able to package the operator into an image, for versioning it. The chart should reference it, and the user should be able to define what version of the operator he/she wants based on image digest(or similar).
I might be missing something here, so please keep me honest.

Also, what about an image mechanism(store in registry with some semantic versioning), if the helm chart is too much. Or is this something already in place?

Thanks!
What
So here are the things that need to "managed and lifecycle'd":

A builder or pipeline Service Account: A default service account created in every namespace which Builds would run as. It is similar to the builder sa[1] in OpenShift, or the pipeline sa which OpenShift Pipelines sets up for us in every namespace. I've documented the manual steps[2] to set it up today.  ( doesn't need much of a lifecycle though ).

Controller image: The image which runs the controllers we have in this repo.

CRDs ( 3 or 4 CRDs ).

[Cluster]Rolebindings , [Cluster]Roles & Service account the controller would run as.

(1), (2) & (3) as a whole bundle needs to be versioned and managed by something on the cluster.
[1] https://docs.openshift.com/container-platform/3.6/dev_guide/service_accounts.html#default-service-accounts-and-roles
[2] https://github.com/redhat-developer/build/blob/master/HACK.md#running-the-operator
Option 1: OLM packaging everything and installing on your behalf
👍  OLM can manage bundles like (1) (2) and (3) as a whole. Example https://github.com/sbose78/buildv2-olm-csv-sample/blob/master/0.0.4/buildv2-operator.v0.0.1.clusterserviceversion.yaml
👍  Just like typical package managers, OLM has a way to define dependencies. https://github.com/operator-framework/operator-lifecycle-manager/blob/master/README.md#dependency-resolution
👎 Out-of-the-box build strategies can't be installed. OLM today only supports the types we have in /deploy/ today. They'll support more kinds in 2-3 months.
👎 There's no OLM tekton operator for kubernetes, hence you can't use dependency resolution.
So, I could specify "Build operator depends on tekton/pipelines" and that would bring in and install Pipelines. Similar to how we yum/rpm dependency management is designed.
Option 2: A dedicated operator for packaging and installing artifacts
👍  We tag and create a release.yaml at frequent intervals ( like tekton )
👍  We write an operator that sets up (0) to (3) in a Kubernetes/OpenShift. ( this is all @qu1queee 's suggestion :) ). You could use OLM to manage this operator in-cluster - unless you have some system in place already to manage operators in a cluster.
👍 The operator can setup build strategies ootb as well.
Based on my analysis, I like option 2 :)
And, I think I'm going to anyway submit 'Option 2' to the list of Kubernetes operators on operatorhub.io https://github.com/operator-framework/community-operators/tree/master/upstream-community-operators but that will not affect your custom way of managing this dedicated operator if you wanted to have a custom way.

Thanks for the analysis.
I like the option 2 and also hope to see a dedicated Build Operator in the OperatorHub :)

Of course, we have the default sa in every namespace in kubernetes that can be used.

https://github.com/redhat-developer/build/issues/77

https://github.com/tektoncd/operator/issues/3 I see that adding the upstream tekton operator is marked as important/soon
If that's done, then we have this easy operatorhub experience too https://www.youtube.com/watch?v=M90IKYKm2aI which is feasible on OpenShift ( https://github.com/sbose78/buildv2-olm-csv-sample/blob/master/0.0.5/buildv2-operator.v0.0.1.clusterserviceversion.yaml#L15 )

I like also option 2! thanks for the detail explanation!

repo: redhat-developer/build


text:
Update golangci-lint to v1.45.2

Update golangci-lint to v1.45.2

/lgtm
/approve

repo: redhat-developer/gitops-backend


text:
NodePlacement or Toleration/NodeSelector not working

Describe the bug
NodePlacement or Toleration/NodeSelector don't affect argocd resources.
Expected behavior
I've already deployed ArgoCD using GitOps operator on default nodes.
Now I need to move ArgoCD resources on dedicated nodes that have a taint and a label.
I've tried to use NodePlacement field in ArgoCD resource template adding the toleration (as indicated here). It takes the toleration but nothing happens and resources remain on default nodes.
Also, I've tried to set toleration inside GitOps Service resource and it works but just for 2 deployment resources: kam and cluster. Others resources (argocd-repo-server, application-controller, etc..) are not affected by this change. This is indicated here.
How can I reach my goal?
Thank you.

Same issue here, and i also found the problem.
There is a default nodeselector in place:
 nodeSelector:     kubernetes.io/os: linux     machine.openshift.io/cluster-api-machineset: cl01-worker-0
but our infra nodes are a different machine set called cl01-infra-0

repo: redhat-developer/gitops-operator


text:
feat: script for running nightly kuttl test

What type of PR is this?

/kind enhancement

What does this PR do / why we need it:
To run the nightly operator test via script
Install the non-olm operator on the cluster
cd hack/non-olm-install
OPERATOR_REGISTRY=brew.registry.redhat.io OPERATOR_REGISTRY_ORG=rh-osbs GITOPS_OPERATOR_VER=v99.9.0-125 IMAGE_PREFIX=openshift-gitops-1- ./install-gitops-operator.sh -i
Run the tests after all the pods are up in the parent directory:
make e2e-non-olm-tests-parallel
make e2e-non-olm-tests-sequential
Add other directories that need to be deleted.
Have you updated the necessary documentation?

[x] Documentation update is required by this PR.
[x] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes #?
Test acceptance criteria:

[ ] Unit Test
[ ] E2E Test

How to test changes / Special notes to the reviewer:

scripts/run-kuttl-tests.sh -> This is an empty file. Is this needed ?

This file exists - https://github.com/redhat-developer/gitops-operator/blob/master/scripts/run-kuttl-tests.sh It is needed to run the suite.

/retest

/lgtm

/approve

/retest

/retest

/retest

/lgtm

/test v4.11-kuttl-parallel

authors: anandf saumeya