Special keys do not work on Ayaneo 2S

On latest version 42 the rest of the OS installs fine, but both bottom right two buttons do nothing and the top CL and CR buttons do nothing as well. Attempting to map any of these buttons causes two separate inputs to be registered, so they are technically registering, but something is messed up because each key tries mapping to two buttons at once and 3 of the 4 register as the same input.

I'll need some data from you to support this device.
Please run the following commands:
Post the results of:
cat /sys/devices/virtual/dmi/id/product_name
cat /proc/dev/input/devices

Install evtest and post a screenshot or copy paste of the events:
sudo frzr-unlock
sudo pacman -Sy evtest
sudo evtest

type the # that corresponds to the event device that matches AT Translated Set 2 Keyboard
Press and release one time each the keys in this order:

Ayaspace (large face)
Configurable (small face)
LC (top left)
RC (top right)

That will give me the info I need to either update the existing map for the 2 or add a new one for the 2S.

Here's what I got:
`[gamer@chimeraos ~]$ cat /sys/devices/virtual/dmi/id/product_name
AYANEO 2S
[gamer@chimeraos ~]$ cat /proc/dev/input/devices
cat: /proc/dev/input/devices: No such file or directory
[gamer@chimeraos ~]$ sudo frzr-unlock
[sudo] password for gamer:
:: Synchronizing package databases...
core                  153.9 KiB  91.4 KiB/s 00:02 [######################] 100%
extra                1785.5 KiB   660 KiB/s 00:03 [######################] 100%
community               7.5 MiB  2.12 MiB/s 00:04 [######################] 100%
multilib              161.5 KiB  79.6 KiB/s 00:02 [######################] 100%
frzr deployment chimeraos-42_1de8b04 unlocked
[gamer@chimeraos ~]$ sudo pacman -Sy evtest
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
resolving dependencies...
looking for conflicting packages...
Packages (1) evtest-1.35-1
Total Download Size:   0.02 MiB
Total Installed Size:  0.06 MiB
:: Proceed with installation? [Y/n] y
warning: no /var/cache/pacman/pkg/ cache exists, creating...
:: Retrieving packages...
evtest-1.35-1-x86_64   16.0 KiB  31.2 KiB/s 00:01 [######################] 100%
(1/1) checking keys in keyring                     [######################] 100%
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) checking available disk space                [######################] 100%
:: Processing package changes...
(1/1) installing evtest                            [######################] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[gamer@chimeraos ~]$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Power Button
/dev/input/event1:	Power Button
/dev/input/event10:	Cherry GmbH Cherry TouchBoard
/dev/input/event11:	Cherry GmbH Cherry TouchBoard
/dev/input/event12:	Microsoft X-Box 360 pad
/dev/input/event2:	Video Bus
/dev/input/event3:	AT Translated Set 2 keyboard
/dev/input/event4:	Goodix Capacitive TouchScreen
/dev/input/event5:	PC Speaker
/dev/input/event6:	HD-Audio Generic HDMI/DP,pcm=3
/dev/input/event7:	HD-Audio Generic HDMI/DP,pcm=7
/dev/input/event8:	HD-Audio Generic Mic
/dev/input/event9:	HD-Audio Generic Headphone
Select the device event number [0-12]: 3
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab83
Input device name: "AT Translated Set 2 keyboard"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 2 (KEY_1)
Event code 3 (KEY_2)
Event code 4 (KEY_3)
Event code 5 (KEY_4)
Event code 6 (KEY_5)
Event code 7 (KEY_6)
Event code 8 (KEY_7)
Event code 9 (KEY_8)
Event code 10 (KEY_9)
Event code 11 (KEY_0)
Event code 12 (KEY_MINUS)
Event code 13 (KEY_EQUAL)
Event code 14 (KEY_BACKSPACE)
Event code 15 (KEY_TAB)
Event code 16 (KEY_Q)
Event code 17 (KEY_W)
Event code 18 (KEY_E)
Event code 19 (KEY_R)
Event code 20 (KEY_T)
Event code 21 (KEY_Y)
Event code 22 (KEY_U)
Event code 23 (KEY_I)
Event code 24 (KEY_O)
Event code 25 (KEY_P)
Event code 26 (KEY_LEFTBRACE)
Event code 27 (KEY_RIGHTBRACE)
Event code 28 (KEY_ENTER)
Event code 29 (KEY_LEFTCTRL)
Event code 30 (KEY_A)
Event code 31 (KEY_S)
Event code 32 (KEY_D)
Event code 33 (KEY_F)
Event code 34 (KEY_G)
Event code 35 (KEY_H)
Event code 36 (KEY_J)
Event code 37 (KEY_K)
Event code 38 (KEY_L)
Event code 39 (KEY_SEMICOLON)
Event code 40 (KEY_APOSTROPHE)
Event code 41 (KEY_GRAVE)
Event code 42 (KEY_LEFTSHIFT)
Event code 43 (KEY_BACKSLASH)
Event code 44 (KEY_Z)
Event code 45 (KEY_X)
Event code 46 (KEY_C)
Event code 47 (KEY_V)
Event code 48 (KEY_B)
Event code 49 (KEY_N)
Event code 50 (KEY_M)
Event code 51 (KEY_COMMA)
Event code 52 (KEY_DOT)
Event code 53 (KEY_SLASH)
Event code 54 (KEY_RIGHTSHIFT)
Event code 55 (KEY_KPASTERISK)
Event code 56 (KEY_LEFTALT)
Event code 57 (KEY_SPACE)
Event code 58 (KEY_CAPSLOCK)
Event code 59 (KEY_F1)
Event code 60 (KEY_F2)
Event code 61 (KEY_F3)
Event code 62 (KEY_F4)
Event code 63 (KEY_F5)
Event code 64 (KEY_F6)
Event code 65 (KEY_F7)
Event code 66 (KEY_F8)
Event code 67 (KEY_F9)
Event code 68 (KEY_F10)
Event code 69 (KEY_NUMLOCK)
Event code 70 (KEY_SCROLLLOCK)
Event code 71 (KEY_KP7)
Event code 72 (KEY_KP8)
Event code 73 (KEY_KP9)
Event code 74 (KEY_KPMINUS)
Event code 75 (KEY_KP4)
Event code 76 (KEY_KP5)
Event code 77 (KEY_KP6)
Event code 78 (KEY_KPPLUS)
Event code 79 (KEY_KP1)
Event code 80 (KEY_KP2)
Event code 81 (KEY_KP3)
Event code 82 (KEY_KP0)
Event code 83 (KEY_KPDOT)
Event code 85 (KEY_ZENKAKUHANKAKU)
Event code 86 (KEY_102ND)
Event code 87 (KEY_F11)
Event code 88 (KEY_F12)
Event code 89 (KEY_RO)
Event code 90 (KEY_KATAKANA)
Event code 91 (KEY_HIRAGANA)
Event code 92 (KEY_HENKAN)
Event code 93 (KEY_KATAKANAHIRAGANA)
Event code 94 (KEY_MUHENKAN)
Event code 95 (KEY_KPJPCOMMA)
Event code 96 (KEY_KPENTER)
Event code 97 (KEY_RIGHTCTRL)
Event code 98 (KEY_KPSLASH)
Event code 99 (KEY_SYSRQ)
Event code 100 (KEY_RIGHTALT)
Event code 102 (KEY_HOME)
Event code 103 (KEY_UP)
Event code 104 (KEY_PAGEUP)
Event code 105 (KEY_LEFT)
Event code 106 (KEY_RIGHT)
Event code 107 (KEY_END)
Event code 108 (KEY_DOWN)
Event code 109 (KEY_PAGEDOWN)
Event code 110 (KEY_INSERT)
Event code 111 (KEY_DELETE)
Event code 112 (KEY_MACRO)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 116 (KEY_POWER)
Event code 117 (KEY_KPEQUAL)
Event code 118 (KEY_KPPLUSMINUS)
Event code 119 (KEY_PAUSE)
Event code 121 (KEY_KPCOMMA)
Event code 122 (KEY_HANGUEL)
Event code 123 (KEY_HANJA)
Event code 124 (KEY_YEN)
Event code 125 (KEY_LEFTMETA)
Event code 126 (KEY_RIGHTMETA)
Event code 127 (KEY_COMPOSE)
Event code 128 (KEY_STOP)
Event code 140 (KEY_CALC)
Event code 142 (KEY_SLEEP)
Event code 143 (KEY_WAKEUP)
Event code 155 (KEY_MAIL)
Event code 156 (KEY_BOOKMARKS)
Event code 157 (KEY_COMPUTER)
Event code 158 (KEY_BACK)
Event code 159 (KEY_FORWARD)
Event code 163 (KEY_NEXTSONG)
Event code 164 (KEY_PLAYPAUSE)
Event code 165 (KEY_PREVIOUSSONG)
Event code 166 (KEY_STOPCD)
Event code 172 (KEY_HOMEPAGE)
Event code 173 (KEY_REFRESH)
Event code 183 (KEY_F13)
Event code 184 (KEY_F14)
Event code 185 (KEY_F15)
Event code 217 (KEY_SEARCH)
Event code 226 (KEY_MEDIA)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Event type 17 (EV_LED)
Event code 0 (LED_NUML) state 0
Event code 1 (LED_CAPSL) state 0
Event code 2 (LED_SCROLLL) state 0
Key repeat handling:
Repeat type 20 (EV_REP)
Repeat code 0 (REP_DELAY)
Value    250
Repeat code 1 (REP_PERIOD)
Value     33
Properties:
Testing ... (interrupt to exit)
Event: time<PHONE_NUMBER>.103373, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.103373, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 1
Event: time<PHONE_NUMBER>.103373, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.108531, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.108531, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time<PHONE_NUMBER>.108531, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.112322, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.112322, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.274441, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.274441, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.281881, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.281881, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time<PHONE_NUMBER>.281881, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.288851, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.288851, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 0
Event: time<PHONE_NUMBER>.288851, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.294007, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.294007, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.301959, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.301959, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.308949, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.308949, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.314042, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.314042, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.321993, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.321993, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.328991, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.328991, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.334122, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.334122, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.342079, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.342079, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.348963, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.348963, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.354345, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.354345, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.362039, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.362039, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.369095, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.369095, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.374166, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.374166, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.382055, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.382055, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.389152, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.389152, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.394215, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.394215, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.402164, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.402164, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.409187, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.409187, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.414264, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.414264, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.422277, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.422277, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.429263, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.429263, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.434328, type 4 (EV_MSC), code 4 (MSC_SCAN), value 68
Event: time<PHONE_NUMBER>.434328, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.442292, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.442292, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.449301, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.449301, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.144061, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.144061, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time<PHONE_NUMBER>.144061, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.147336, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.147336, type 1 (EV_KEY), code 32 (KEY_D), value 1
Event: time<PHONE_NUMBER>.147336, -------------- SYN_REPORT ------------
dEvent: time<PHONE_NUMBER>.297349, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.297349, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time<PHONE_NUMBER>.297349, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.302426, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.302426, type 1 (EV_KEY), code 32 (KEY_D), value 0
Event: time<PHONE_NUMBER>.302426, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.309382, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.309382, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.314550, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.314550, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.323204, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.323204, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.327786, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.327786, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.334629, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.334629, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.340022, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.340022, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.347611, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.347611, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.352654, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.352654, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.359847, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.359847, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.364693, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.364693, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.372733, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.372733, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.377643, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.377643, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.384854, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.384854, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.389711, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.389711, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.397707, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.397707, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.403043, type 4 (EV_MSC), code 4 (MSC_SCAN), value 20
Event: time<PHONE_NUMBER>.403043, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.982772, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.982772, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 1
Event: time<PHONE_NUMBER>.982772, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.987677, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.987677, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time<PHONE_NUMBER>.987677, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.991031, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.991031, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.123220, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.123220, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.134353, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.134353, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time<PHONE_NUMBER>.134353, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.141265, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.141265, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 0
Event: time<PHONE_NUMBER>.141265, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.146651, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.146651, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.154197, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.154197, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.161169, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.161169, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.166346, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.166346, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.174399, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.174399, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.181592, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.181592, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.186380, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.186380, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.194353, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.194353, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.201302, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.201302, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.206428, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.206428, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.214356, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.214356, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.221315, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.221315, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.226414, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.226414, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.234616, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.234616, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.241344, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.241344, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.246473, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.246473, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.254385, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.254385, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.261392, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.261392, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.266490, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.266490, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.274437, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.274437, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.281700, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.281700, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.286540, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time<PHONE_NUMBER>.286540, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.294502, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.294502, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.301514, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.301514, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.838626, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.838626, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 1
Event: time<PHONE_NUMBER>.838626, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.843898, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.843898, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time<PHONE_NUMBER>.843898, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.846595, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.846595, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.999100, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.999100, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.007067, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.007067, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time<PHONE_NUMBER>.007067, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.014493, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.014493, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 0
Event: time<PHONE_NUMBER>.014493, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.019178, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.019178, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.027189, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.027189, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.034088, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.034088, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.039249, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.039249, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.047253, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.047253, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.054461, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.054461, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.059335, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.059335, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.067504, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.067504, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.074196, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.074196, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.079368, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.079368, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.087282, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.087282, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.094974, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.094974, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.099332, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.099332, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.107303, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.107303, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.114314, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.114314, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.119758, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.119758, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.127610, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.127610, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.134375, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.134375, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.139430, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.139430, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.147434, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.147434, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.154463, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.154463, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.159541, type 4 (EV_MSC), code 4 (MSC_SCAN), value 67
Event: time<PHONE_NUMBER>.159541, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.167483, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time<PHONE_NUMBER>.167483, -------------- SYN_REPORT ------------
Event: time<PHONE_NUMBER>.174480, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9d
Event: time<PHONE_NUMBER>.174480, -------------- SYN_REPORT ------------`

Here's what I got:
console.txt

[gamer@chimeraos ~]$ cat /proc/dev/input/devices
cat: /proc/dev/input/devices: No such file or directory

Woops, cat /proc/bus/input/devices

Keycodes look the same, so once I verify if the PCIE address is the same it will hopefully be as simple as adding a DMI string.

@BringusStudios Bump. Can you run the corrected cat above?

Sorry about that, missed your last comment. Here's the output of that
command: https://pastebin.com/8DC1AaFr
On Wed, Jun 14, 2023, 6:49 PM Derek J. Clark @.***>
wrote:

@BringusStudios https://github.com/BringusStudios Bump. Can you run the
corrected cat above?
—
Reply to this email directly, view it on GitHub
https://github.com/ChimeraOS/chimeraos/issues/648#issuecomment-1592215985,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZ5326EBG65ZADCHXLFW6DTXLJS2BANCNFSM6AAAAAAZFO5WTY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Sorry about that, missed your last comment. Here's the output of that command: https://pastebin.com/8DC1AaFr
…
On Wed, Jun 14, 2023, 6:49 PM Derek J. Clark @.> wrote: @BringusStudios https://github.com/BringusStudios Bump. Can you run the corrected cat above? — Reply to this email directly, view it on GitHub <#648 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ5326EBG65ZADCHXLFW6DTXLJS2BANCNFSM6AAAAAAZFO5WTY . You are receiving this because you were mentioned.Message ID: @.>

That didn't appear to capture the xbox controller. They sometimes go to sleep. can you hit B on the controller and run that again? That usually wakes it up.

Dope. It isn't exactly the same as the 2/geek but I should be able to use the same major code. Thanks.

Just tested it, working great to open the 2 menus with the bottom right buttons! I did notice that LC opens an emulation page and RC doesn't seem to do anything. Is there a way to bind these in steam?

Seems like everything is working as intended. RC will open the OSK, but only in game. There isn't really a way to rebind them in steam. You can change to different functions using the guide in the HandyGCCS wiki, but LC is hard coded for ChimeraOS to open the Chimera App right now, or as screenshot otherwise. I'm working on improving this a bit in a refactor. Thanks for testing.

Ok sounds good, thanks for the info and the fix ✌
On Wed, Jun 14, 2023, 8:33 PM Derek J. Clark @.***>
wrote:

Seems like everything is working as intended. RC will open the OSK, but
only in game. There isn't really a way to rebind them in steam. You can
change to different functions using the guide in the HandyGCCS wiki, but LC
is hard coded for ChimeraOS to open the Chimera App right now, or as
screenshot otherwise. I'm working on improving this a bit in a refactor.
Thanks for testing.
—
Reply to this email directly, view it on GitHub
https://github.com/ChimeraOS/chimeraos/issues/648#issuecomment-1592297720,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZ5326ACJNWGVZOVOE3F3YLXLJ67BANCNFSM6AAAAAAZFO5WTY
.
You are receiving this because you were mentioned.Message ID:
@.***>


refactor such that some of the math is cached

For applications where a lot of encryption and decryption needs to occur between two parties, cache the shared secret computations.

ACK


Corrected a typo in pypi publishing example, package-dir -> packages-dir

Thanks @francescalb ! :)


[Hacktoberfest] A few code quality issues

Remove the ` quote and use double quote for Table names in SQL.
Added a newer equals and hashCode in ArchiveIdentifierVersion.
Type of request

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Refactoring
[ ] Documentation or documentation changes

Related Issue(s)
Relates to #35
Concept
This fixes a few issues in the following code quality issues:
https://app.codacy.com/manual/aposin-bot/LicenseScout/issues?bid=12903434&filters=W3siaWQiOiJDYXRlZ29yeSIsInZhbHVlcyI6WyJFcnJvclByb25lIl19XQ==
Initiator
Luiz Henrique Pegoraro / github.com/lpegoraro
How has this Tested?
Ran SQL locally in dockerized MySQL db.
Ran unit tests in core module.

Checklist:

[x] My code follows the code style of this project.
[x] I agree with die CLA.
[x] I have read the CONTRIBUTING docs.
[ ] I have added/updated necessary documentation (if appropriate). (N/A)

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

Hello @lpegoraro - thank you very much for your interest in our project! Before we can assign a maintainer for this PR, could you please sign the CLA (see https://github.com/aposin/LicenseScout/pull/39#issuecomment-537061772)?

Signed, I was having a few issues in my browser and CLA was not working properly. Now I got it.

Thanks you @lpegoraro - @pfistererm, could you review the changes of this PR?

@lpegoraro, some extra-requirement that I forgot to mention: you have to sign your commits before we can merge this PR after review (more information about signing commits in GitHub here). Sorry for any inconvenience.

Thanks!

@lpegoraro - we are almost ready to merge these changes, but we still need that you sign your commits. Sorry for the inconvenience.
You can check the GitHub help on how to sign commits if you are not familiar with the procedure.

Sorry, but your commits are not signed. Our project only accepts signed commits. Have a look at https://help.github.com/en/articles/about-commit-signature-verification.
Can you please do that, so we can accept your contribution? :blush:

Yeah sorry about that, I will sign them and correct it right away

I needed to migrate to a different branch, please go to #41. Thanks!


"Instructions" grid does not display in Edge browser

The latest 1Across grid, "Instructions", does not display in Microsoft Edge or Internet Explorer on Windows 10.
Here is a screenshot from Edge. (Enlarging the Edge window does not help.) The appearance in IE is similar.

Hmm, I have zero access right now to a Windows machine, unfortunately.
If you can bring up the JavaScript console and see if there are any error
messages, that might help.
On Sun, May 24, 2020, 6:13 PM Raceous<EMAIL_ADDRESS>wrote:

The latest 1Across grid, "Instructions", does not display in Microsoft
Edge or Internet Explorer on Windows 10.
Here is a screenshot from Edge. (Enlarging the Edge window does not help.)
The appearance in IE is similar.
[image: image]
https://user-images.githubusercontent.com/54013910/82769560-f74a3d80-9de9-11ea-8b11-f52a0685dabd.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/viresh-ratnakar/exolve/issues/28, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJQ562BFQU4HBPKWBSK2AP3RTHAZXANCNFSM4NJEF5LA
.

Another useful piece of info would be whether some older grid works (to
identify if the issue is limited to the current puzzle or to some recent
core software change)
On Sun, May 24, 2020, 6:24 PM Viresh Ratnakar<EMAIL_ADDRESS>wrote:

Hmm, I have zero access right now to a Windows machine, unfortunately.
If you can bring up the JavaScript console and see if there are any error
messages, that might help.
On Sun, May 24, 2020, 6:13 PM Raceous<EMAIL_ADDRESS>wrote:

The latest 1Across grid, "Instructions", does not display in Microsoft
Edge or Internet Explorer on Windows 10.
Here is a screenshot from Edge. (Enlarging the Edge window does not
help.) The appearance in IE is similar.
[image: image]
https://user-images.githubusercontent.com/54013910/82769560-f74a3d80-9de9-11ea-8b11-f52a0685dabd.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/viresh-ratnakar/exolve/issues/28, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJQ562BFQU4HBPKWBSK2AP3RTHAZXANCNFSM4NJEF5LA
.

The previous 3 grids have also stopped working. LP.html and NJC.html appear the same as above. WH.html (Wormholes) appears as a completely blank page.
Screenshots of console output follow. (Let me know if you would prefer these as text)

Looks like the error thrown at exolve-m.js:610 is the/a core problem. This
code was indeed added when I added non-English support recently.
try {
languageScript = 'Devanagari'
scriptRE = new RegExp('\p{Script=' + languageScript + '}', 'u')
scriptLowerCaseRE = new RegExp('\p{Lowercase}', 'u')
} catch {
}
Can you please type these lines in the browser's JavaScript  console, one
at a time, and let me know what error messages pop up, when you get the
chance. I'm expecting some syntax errors. And then I want to check if the
syntax errors go away with some easy fixes.
On Sun, May 24, 2020 at 7:10 PM Raceous<EMAIL_ADDRESS>wrote:

The previous 3 grids have also stopped working. LP.html and NJC.html
appear the same as above. WH.html (Wormholes) appears as a completely blank
page.
Screenshots of console output follow. (Let me know if you would prefer
these as text)
[image: image]
https://user-images.githubusercontent.com/54013910/82771655-97f02b80-9df1-11ea-8de2-1aa4cfe47fbb.png
[image: image]
https://user-images.githubusercontent.com/54013910/82771693-b2c2a000-9df1-11ea-8616-3a773a311cd0.png
[image: image]
https://user-images.githubusercontent.com/54013910/82771723-ccfc7e00-9df1-11ea-84e7-bbc1a0484dc3.png
[image: image]
https://user-images.githubusercontent.com/54013910/82771815-1351dd00-9df2-11ea-8d3f-770dad574442.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/viresh-ratnakar/exolve/issues/28#issuecomment-633342075,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJQ562HNY4SLHSAJDLLTZCLRTHHQBANCNFSM4NJEF5LA
.

Reopened In.html and copied the whole code fragment:

OK, thanks! Sorry, but we'll have to drill down a bit more. Here are variants aht ablate various aspects of the above. Please try them separately.

try {
languageScript = 'Devanagari'
catch {
}

scriptLowerCaseRE = new RegExp('\p{Lowercase}', 'u')

scriptRE = new RegExp('test1', 'u')

scriptRE = new RegExp('\test2', 'u')

try {
scriptRE = new RegExp('test1', 'u')
catch {
}

try {
scriptRE = new RegExp('\test1', 'u')
catch {
}
Or anything that useful variation can think of :-). Thanks!

Here you go:

Debugged through discussion, thanks!
Fixed with v0.73.

Verified that the grid can now be viewed in Edge.


implement fetching the RTC timer value in milliseconds and mircroseconds

This implements get_time_ms() and get_time_us() on rtc_cntl::Rtc examples are included and have been tested on all cpu types except esp32c2.
Random notes:

in the pac for esp32c6 what was all in RTC_CNTL seems broken out into a number of LP_X peripherals.
should these be combind  in the hal api or should they remain seperate? If seperate should we do the same with other chips?
for esp32 the loop waiting for the time registers to be updated should have a limit

Awesome! Maybe it would be good to align the field names in the SVD/PACs but that can also be done afterwards
Is there anything blocking you here?

Blocked only by because I'm vacationing in Japan. :-)

I'm happy to update the PACs (either before or after merging this, makes no difference to me), so just lemme know if/when you'd like that done!
In the meantime, enjoy your vacation!

@jessebraham ok - lets go ahead and review/merge this. We can adjust the PACs after.

ok - I added what esp-idf does for esp32 - they delay 1us between checks of the update bit to avoid flooding the RTC bus


[CP] fix clear color optimization for large subpasses

Issue Link
https://github.com/flutter/flutter/issues/136507
Commit Hash
d5ca128
Target
beta
PR Link
https://github.com/flutter/engine/pull/47577
Changelog Description
Fixes a case where the color would be dropped for subpass textures that were larger than the parent pass. This could be observed in the non-cached implementation of the Android zoom page transition.
Impacted Users
Impeller / iOS users
Impact Description
Color will disppear from certain surfaces based on sizing.
Workaround
Disable impeller
Risk
low
Test Coverage
yes
Validation Steps
Run attached unit tests

@zanderso could you take a look at this issue and the associated PR?

CP LGTM


Does extract css support named by entrys name?

rollup({
        input: ['./src/index.js', './src/index-pc.js'],
        format: 'cjs',
        allowRealFiles: true,
        plugins: [
          svelte({
            extensions: ['.html'],
            include: 'src/components/**/*.html',
            css: function(css) {
              css.write('src/svelte.css', false)
              //  I want the extract css file named as 'index.css' and 'index-pc.css'
              //  by using like this:    css.write('src/[name].css', false)
            }
          })
        ]
      })

so how can i get the extract css file by different name?

No — it just gives you the CSS for the entire bundle. If you needed to extract CSS for files individually you'd probably be better off just using the compiler directly:
const fs = require('fs');
const glob = require('glob');
const { compile } = require('svelte');

glob.sync('src/**/*.html).forEach(componentFile => {
  const source = fs.readFileSync(componentFile, 'utf-8');
  const { css, cssMap } = compile(source);

  // then write css files to wherever they need to go
});


Github Actions

Hello, lap and lapx have been merged, and the new v0.5.12 is now available. I close this for now, and you still can reopen this later or a new one if you have any idea to improve lap. Thanks!


Go modules update

Aggregated dependabot changes for go modules.

Codecov Report
Base: 61.97% // Head: 32.10% // Decreases project coverage by -29.87% :warning:

Coverage data is based on head (a38d08f) compared to base (cdf064d).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1991       +/-   ##
===========================================
- Coverage   61.97%   32.10%   -29.88%
===========================================
  Files         179      179
  Lines       14523    14530        +7
===========================================
- Hits         9001     4665     -4336
- Misses       4427     9201     +4774
+ Partials     1095      664      -431

Flag
Coverage Δ

acceptance-api
?

acceptance-apps
?

acceptance-cli
30.26% <ø> (-27.10%)
:arrow_down:

unittests
8.26% <ø> (-0.01%)
:arrow_down:

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

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


node-base/tasks/opensuse_leap-15: Add basic repos

Before doing anything on a openSUSE 15 node, make sure the basic
repositories are set up.
Signed-off-by: Thomas Bechtold<EMAIL_ADDRESS>

By the way do we check the return value of ansible before carrying on with deployment ?

yes, we do


Issue running

Checking conda installation...
conda is installed.
Checking config file...
Activating environment whisperx...
Environment activated.
Checking for updates...
Failed to fetch updates. Check your internet connection.
Running Whisper-GUI...
Creating interface...
Traceback (most recent call last):
  File "C:\Users\Aiden\Downloads\whisper-gui-2.3.0\main.py", line 433, in <module>
    demo.launch(inbrowser=args.autolaunch, share=args.share)
  File "C:\Users\Aiden\anaconda3\envs\whisperx\lib\site-packages\gradio\blocks.py", line 2327, in launch
    ) = http_server.start_server(
  File "C:\Users\Aiden\anaconda3\envs\whisperx\lib\site-packages\gradio\http_server.py", line 154, in start_server
    raise OSError(
OSError: Cannot find empty port in range: 7860-7959. You can specify a different port by setting the GRADIO_SERVER_PORT environment variable or passing the `server_port` parameter to `launch()`.
Press any key to continue . . .

any ideas? I tried adding port 7860 to my firewall and that didn't change anything

Similar issue here: https://github.com/CompVis/stable-diffusion/issues/424
They propose different solutions, mostly for Windows. I don't know your environment so try any of those and see if they work.
Let me know if you solve it.


[Sprint 41] XD 2410 & 2412: fix FieldValueCounter names and behavior

rebased, squashed and merged as d7563443d6a127c7e0eafe9de71434da1c14c61d


🌱 Remove kind-redeploy make target

Description
This target is broken because OPERATOR_CONTROLLER_NAMESPACE does not exist.
Reviewer Checklist

[ ] API Go Documentation
[ ] Tests: Unit Tests (and E2E Tests, if appropriate)
[ ] Comprehensive Commit Messages
[ ] Links to related GitHub Issue(s)

I noticed this was broken recently as well. But I know @tmshort added it fairly recently, so maybe worth getting his opinion on this PR.

I noticed this was broken recently as well. But I know @tmshort added it fairly recently, so maybe worth getting his opinion on this PR.

Uh.. it looks like the line got sucked out the airlock in b08a1e92 Should we just put OPERATOR_CONTROLLER_NAMESPACE ?= operator-controller-system and fix the target?

I noticed this was broken recently as well. But I know @tmshort added it fairly recently, so maybe worth getting his opinion on this PR.

Uh.. it looks like the line got sucked out the airlock in b08a1e9 Should we just put OPERATOR_CONTROLLER_NAMESPACE ?= operator-controller-system and fix the target?

I'm not opposed to doing this, but my preference is to remove it. IMO our Makefile is getting a bit cluttered. Also we have tilt setup for quick redeployment which watches filesystem and automates dev process. We can also run it locally with port forwarding or just make run (which is a bit slower and does not persist resources because the kind cluster gets re-created).
But it is just me. If people find it useful for their workflows - then it might be worth keeping it.

This is something that @joelanford had asked for, and I think I noticed that OPERATOR_CONTROLLER_NAMESPACE was not being properly set, either, but it got away from me with other work. I don't have a Tilt setup yet, so, I'm one of those where this might  be useful.

Added #1032 to actually fix kind-redeploy, but it's really just running other targets...

I'm +1 on removing now that Tilt is actually working properly.


Improve Security By Putting API Gateway That Verifies Header Set By CloudFront In Front of Lambdas

Currently this construct deploys Lambda Function URLs with AuthType of NONE. This allows anyone to call the function if they know the Lambda URL. A more secure approach would be to put the Lambda behind an API Gateway which verifies a secret header set by CloudFront and have the CloudFront behavior call the API GW. This would ensure Lambdas can only be called through CloudFront. Is there any interest from the maintainer of this project/community for such a feature? I'd possibly be interested in contributing.

If there are any other techniques that could avoid public Lambda Function URLs, I'd be interested to hear other ideas!

You are welcome to contribute something if you want. What exactly is the security threat of someone hitting the lambda URL directly? What could an attacker do?
NextjsSite from SST uses function URLs too (though it and this project sort of feed off each other): https://github.com/serverless-stack/sst/blob/master/packages/sst/src/constructs/NextjsSite.ts#L292

One thing I can think of would be a Denial-of-Wallet attack since it's bypassing the CDN.

@revmischa, great! I'll begin working on something. I just wanted to make sure it wouldn't be a waste of time.
Security threats quoted from this blog include:

Data retrieval or manipulation
Initial access or privilege escalation
Vulnerability exploitation
Denial of Service
Denial of Wallet (as @khuezy already mentioned)

The first 3 are unlikely because Open Next generates the lambda function code, but it's possible and the fix is pretty simple.
Relevant articles:

https://www.wiz.io/blog/securing-aws-lambda-function-urls
https://sonraisecurity.com/blog/aws-lambda-security-best-practices/
https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/lambda-function-public-url/

To enable this feature, I'm thinking I could add a top level property on the construct called serverType with a type value of an enum like below:
enum ServerType {
  LambdaUrl = "LambdaUrl";
  LambdaApiGateway = "LambdaApiGateway";
}

This would default to ServerType.LambdaUrl. I could also foresee someone maybe adding AppRunner or other configurations for running the next server in the future but that's outside of the scope of this issue.
I'd also want to allow users to be able to edit the API Gateway props so I'd add an optional property onto the defaults property.
What do you think?

Honestly I think this is a waste of time. Can you name an actual specific attack someone could perform by having the lambda function URL?
I read that blog, it was vague, authentication doesn't apply here.

@revmischa, I understand your perspective but my security team would beg to differ :)
Are you still open to a PR to add this functionality? It would of course be opt-in. Default would be to use Lambda URLs.

I'm open to it sure.
I'm curious what actual attack your security team thinks someone could do here. So far it sounds like security theater. I read the blog posts and don't believe they apply to this function.

Hello @bestickley does this apply at all for api routes without authentication (which is how most of my applications are set up)
And if we discard the authentication bypass concerns, is the only concern that someone could grab the function url and repeat a bunch of requests in an attempt to cause financial loss through an extrapolation of runtime costs?

yea I'm not a security person either. I'm scratching my head on the actual security concern here. The only argument that makes sense for me is the server runtime cost a bad actor can cause.

Can ou explain how an API gateway prevents some possible attack here? Now you are paying for the APIGW requests too. I am extremely unconvinced there is a problem here or that adding an APIGW will make anything better vs. adding unnecessary complexity and cost.

Hi, I am a security person. Sort of. It's complicated. 😆
We were just chatting about this in the discord. The main security risk I see would be a denial of wallet attack. You could also possibly eat up the concurrency limit for the account/region causing other lambdas to be throttled. Though the risks are real, the recommendation to use API Gateway by itself will not address those risks. You would need to use API Gateway with a Web Application Firewall and DDOS prevention rules on it to truly address the cited risks. And doing that would go against the whole point of a function URL. They are supposed to be simpler versions of a API gateway for only one purpose. This is also why many larger enterprises don't want to use them.
A simpler solution to mitigate the above risks would be to turn on concurrency limits on the function itself. That would contain the blast radius of a DDOS attack to just that function URL. Or just use API Gateway instead, with a WAF, and enjoy the complexities of that deployment. I'm not sure what methods are currently supported as I was just dragged into this conversation from an external perspective, but I would likely want to support both deployment methods to increase adoptability if they are not both already supported. 😃

That makes sense. Thanks for your expertise and input!

From security team's documentation:

... a Lambda function in your account that allows any user in AWS to perform operations with the function. This may allow third parties to invoke or modify your functions, or use the permissions granted to the function's associated execution role.

I think the key issue is the resource based policy statements on the server and image optimization functions that have "Principal": "*". This means anyone can invoke your function (not just visiting url) with whatever parameters they want. The functions that Open Next creates shouldn't be able to be invoked in such a way that an attacker can do something harmful (besides DoS, DoW), but it's possible.
{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "ss-stickb-ui-NextSiteImgOptFninvokefunctionurl4EE7A243-N6GPZTVZJWUP",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "lambda:InvokeFunctionUrl",
      "Resource": "arn:aws:lambda:us-east-1:268914465231:function:ss-stickb-ui-NextSiteImgOptFnCE453280-02ZhQYjuH0yy",
      "Condition": {
        "StringEquals": {
          "lambda:FunctionUrlAuthType": "NONE"
        }
      }
    }
  ]
}

My security team also reminded me it's about Defense-in-Depth. This is an added layer of security that may not be needed because OpenNext's outputted lambda code is secure, but it's still valuable.
@derekmurawsky, I agree adding WAF to API GW is good idea, but I'm not sure this is right:

Though the risks are real, the recommendation to use API Gateway by itself will not address those risks
Because adding API GW with Authorizer that ensures header set by CloudFront URL won't allow an attacker to invoke the function. Make sense?

And as I was thinking about it, there is one silly thing you could do if you really wanted to switch the AUTH type to IAM... You could have the CloudFront distribution call a lambda to modify the request (via the Origin request lambda in the CDN) and sign it with a valid auth token to trigger the function URL. That would mean using two lambdas per call, but it would lock it down to only the cloudfront distro being able to make the call... But you would have to cache that auth token in the cloudfront lambda very carefully so as not to flood AWS IAM in a DDOS scenario.

External entity calls cloudfront
Cloudfront invokes lambda to modify request (sign it) before passing it to the lambda function URL
Cloudfront passes modified request to function url
Function url validates authorization
Function URL runs as normal

This is a bit silly, imho, but would work.
https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html

From security team's documentation:

... a Lambda function in your account that allows any user in AWS to perform operations with the function. This may allow third parties to invoke or modify your functions, or use the permissions granted to the function's associated execution role.

I think the key issue is the resource based policy statements on the server and image optimization functions that have "Principal": "*". This means anyone can invoke your function (not just visiting url) with whatever parameters they want. The functions that Open Next creates shouldn't be able to be invoked in such a way that an attacker can do something harmful (besides DoS, DoW), but it's a possibility if that code changes in future.
{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "ss-stickb-ui-NextSiteImgOptFninvokefunctionurl4EE7A243-N6GPZTVZJWUP",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "lambda:InvokeFunctionUrl",
      "Resource": "arn:aws:lambda:us-east-1:1234567890:function:ss-stickb-ui-NextSiteImgOptFnCE453280-02ZhQYjuH0yy",
      "Condition": {
        "StringEquals": {
          "lambda:FunctionUrlAuthType": "NONE"
        }
      }
    }
  ]
}

My security team also reminded me it's about Defense-in-Depth. This is an added layer of security that may not be needed because OpenNext's outputted lambda code is secure, but it's still valuable.
@derekmurawsky, I agree adding WAF to API GW is good idea, but I'm not sure this is right:

Though the risks are real, the recommendation to use API Gateway by itself will not address those risks

Because adding API GW with Authorizer that ensures header set by CloudFront URL won't allow an attacker to invoke the function. Make sense?

Ah, I see the assertion here, but I think it may be flawed. If the policy that is created is what you put above, it means that only the functionURL can call that function because of the condition key. So "This means anyone can invoke your function (not just visiting url) with whatever parameters they want." isn't correct because if you just called the function from another AWS role, it wouldn't have the "lambda:FunctionUrlAuthType" context so that policy wouldn't apply. Since that is only assigned by AWS and the IAM level, I don't think it could easily be bypassed. It should be easy enough to test that, though.
If a user got the function URL's URL, then yes, they could point anything they want at it. That's why FunctionURL lambdas must handle their own auth, verification, etc. By design, a function url with an auth type of none is meant to be invoked by anyone, anywhere. The code within it, and the role that the lambda has should be very carefully considered with that fact in mind. That is literally the purpose of a function URL. The principle of * must be there for it to be able to do that. As such, I would never use a function url for a high-visibility or sensitive app. I would absolutely want an API Gateway and WAF to handle potential adverse scenarios. Optionality and Flexibility are key at scale with sensitive stuff. On a related note: I do suspect they will eventually add first class support for them to cloudfront, just like they did for S3. It's too convenient a pattern not to.
Regarding "Because adding API GW with Authorizer that ensures header set by CloudFront URL won't allow an attacker to invoke the function. " - But then you're not using a function URL at all and, instead, just invoking the function from API gateway. You're transforming the cost structure a bit here and running Cloudfront + api gateway + a lambda authorizer + the functional lambda to... prevent someone from calling the function URL directly. Which is the point of a function URL.  I agree that's a better and more enterprise-y pattern in general, but I think it adds complexity for scenarios where you may not need it. Personally, I would support multiple deployment options for different scenarios. See my previous comment for a way to make it work just using Cloudfront and Function URLs.

@derekmurawsky, you're right! Thanks for correcting me. That's good that calling the Lambda function is restricted to the calling it through the function URL.

@bestickley I think that constructs should support options intelligently. I don't know enough about this construct to say definitively one way or the other. However, I do think it would be good if there was a way to set the function url auth type, and a way to add to the cloudfront distribution behaviors that are generated within the construct. That includes things like the headers policy. See this feature request over at SST for some logic as to why. The TLDR is that since there is no other way to set behavior-level things once a behavior is instantiated in CDK, all behavior level settings should be bubbled up in any construct that creates them.
In this scenario, instead of header policies (which I think needs to be supported as well) it would be assigning additional functions to the behaviors that are created. This just increases optionality to more easily support specific use cases but leaves the default path as-is.

@derekmurawsky, I agree with this:

I do think it would be good if there was a way to set the function url auth type, and a way to add to the cloudfront distribution behaviors setting "Origin request lambda" that are generated within the construct

I could add top level props to enable customization of this, but I think that solution would be temporary. Eventually there will be a request for additional customization.
Working on something now that I think will accommodate this. Main idea is that you'll be able to extend this construct and override methods to get functionality you want without having to worry about how all the other pieces of the construct are organized. For example, you could do:
import { Construct } from "constructs";
import { Nextjs, NextjsProps, NextjsServerOriginProps, NextJsLambda, NextjsDistribution } from "cdk-nextjs-standalone";
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
import * as lambda from 'aws-cdk-lib/aws-lambda';

class MyNextjs extends Nextjs {
  constructor(scope: Construct, id: string, props: NextjsProps) {
    super(scope, id, props);
  }

  createNextjsServerOrigin(props: NextjsServerOriginProps): origins.HttpOrigin {
    const server = new NextJsLambda(...);
    // create function url that requires iam auth and cloudfront http origin
    // return http origin that you create and will be consumed by CloudFront distribution
  }

  createDistribution(props: NextjsDistributionProps): NextjsDistribution {
    return new MyNextjsDistribution(this, "Distribution", props);
  }
}

class MyNextjsDistribution extends NextjsDistribution {
  constructor(scope: Construct, id: string, props: NextjsDistributionProps) {
    super(scope, id, props);
  }
  getLambdasAtEdge(): lambda.EdgeLambda {
    // create lambda@edge that signs url with IAM. This code for this could import a `fixHostHeader(...)` function from
    // "cdk-nextjs-standalone" to call at the end of the lambda adding the IAM signing functionality before.
  }
}

@revmischa and others, thoughts? I know this is a sizable change, but I think it will add a lot of customization possibilities and value to future users who want further customization. I'd ensure no breaking changes as current construct props would stay the same, just new non-private methods (so they can be overriden) would be added to Nextjs and NextjsDistribution

Your approach of subclassing functions could work, it's not a bad idea. My original idea was more like letting people simply compose their own "top-level" Nextjs construct out of the various blocks they want to use. But it is nice to not have to create that thing from scratch to customize just one or two pieces of it and it probably exposes too much implementation detail.
So I'm generally cool with your idea here.

Thinking more about the subclassing approach, the downside to it is it adds a lot more to the "public API" meaning that making updates to this construct in the future is more likely going to result in a breaking change which isn't good. However, for max customization this may be required. I'll open up another issue which focuses on allowing different types of compute which is really the "user story" for using the subclass approach.
I've created an PR to address the potential security issue (I say potential because I know some don't see it as a security issue) which implements @derekmurawsky's creative idea to use the Lambda@Edge Origin Request function to sign the request to the Lambda Function URL. Thanks to everyone for their thoughts! Feedback on PR welcome :)


Message getting wiped out in teams

This bug is related to teams chatting window. While chatting with someone if you are fast in typing you may face this issue. This is how the issue happens.
Type something in chat window. Hit Enter.
As soon as you hit enter you quickly start typing the next chat and you will see the message getting wiped out.

@chouav10 Could you please share a screenshot of the issue for our better understanding?

Please re-open with screenshot if you are still facing an issue.


Handle markdown inside frontmatter

Is your feature request related to a problem? Please describe.
Just as the main blog contents might have markdown, so can the title and summary fields inside the frontmatter for a post. Today, these are displayed directly as raw strings ("An _emphatic_ title") instead of being decorated correctly ("An emphatic title").
Describe the solution you'd like
Would be great if the framework could also parse and format the marddown present inside various frontmatter fields.
Additional context
I did try to implement this myself, but got way too confused by the complexity of mdx-bundler that we use today to parse the blog contents.
Considering that the frontmatter fields might be extremely straightforward, it would probably be ok to have a simple markdown parse instead of full mdx support. I managed to get this working somewhat using remark-rehype, but it used dangerouslySetInnerHtml, which might not be the best way to do this.

gray-matter processes the yaml as raw strings and it would remain this work even after migrating to the new v2 with contentlayer. It exposes it as a meta js object so parsing to html does not make sense.

Forgive me, but the question can be rephrased as- if I provide markdown inside the title/summary fields, how do I get them to be styled as such? Is ContentLayer going to support this out of the box, or do we need to do something additional?
PS: thanks a lot for your work on V2! The improvements are very welcome. Will try to migrate soon :)


Turn on/off Google Assistant

Is it possible to turn on/off Google Assistant in the Sonos players that have Google Assistant built in through Node Red?  This would be helpful, as I have one in the bedroom, and I dont like the LED light on when sleeping.  But I like the option of asking Google questions during the day.

Hi. Did you try universal node, player.set.led with payload off|on?

Yes, it doesnt change the Google Assistant LED, but it does turn off/on the main LED.

Understand. I haven`t recognized that additional light.
What device do you use?
Is it possible to switch of that light with the standard SONOS IOS,  Android or desktop app?

I just looked, and I dont think it's exposed to the app.  So, sadly no.

There is no official documentation of the SONOS api. In the internet I could not find anything related.
What about any mechanical solution:
a) put an Euro on the light
b) or if you really only want to cover it during the night and like to use some nonsense gadgets :-)
switchbot. It supports mechanical movements and might be use to cover the light.

Seems that we don't have any chance to switch of the light - it is hard wired to the microphone:

Currently, there is no way to lock the status of the mic on any voice enabled Sonos device. Currently you only have 2 options, disable the mic on the Arc itself or just like what @AjTrek1 provided, remove voice assistant on the Sonos app. However, what I can do is send this to our engineering team to take a look into as a feature request. Just to set your expectation since our engineering team does not respond to any feature requests. We can subscribe to this thread and our announcement thread for any feature release and up-to-date announcements.

Therefore I close this issue.


Add no_std support

Thank you very much for this crate, it really simplifies the usage for decoding / encoding of Substrate types from metadata. We'd like to use scale-decode (and encode) for the substrate-api-client, but for this we need no-std support.
I'd happily provide the PR for this, but there are two caveats:

thiserror is not no-std compatible. AFAIK, there's no simple workaround
currently, error_in_core is a nightly feature only.

So I'm not sure how open you are to a PR in this regard. If you're still interested, I did some work in a fork:

Decode: https://github.com/scs/scale-decode/pull/1
Encode: https://github.com/scs/scale-encode/pull/1

Happy to share and adapt if you see a solution for the caveats above.

Ooh thankyou for your branches!
I would actually like this, scale-encode (and scale-bits and scale-value) to all be no-std compatible eventually (alloc being allowed of course). And also we'd want a CI check to ensure that no future updates break the no-std support too.
Aah I see, the Error trait is not exposed in core yet. thiserror can always be made optional and used only when "std" is enabled I guess :)
I'll take a look at those branches!

About thiserror: Any idea how to make it optional without duplicating all error types or cluttering the file with #[cfg(..)] ?

Maybe thiserror can just be removed and replaced with a manual Display impl (I see you used a crate for that; likely I'd just do it manually to avoid the extra dependency) and manual From impls as you did. And then a single cfg to enable impl std::error::Error for Error {...} with relevant source impl etc when std is enabled?

Your branches are promising; there's not much to do there I can see!
So if you were up for opening a PR, I'd basically love something that did the following:

adds an "std" feature, and is no_std compatible without it, so alloc crate etc as you've done.
remove thiserror, replacing with manual From, Display impls and Error impls behind a #[cfg(feature = "std")] flag.
adds a CI job to try compiling with --no-default-features with a target eg --target thumbv6m-none-eabi (iirc this one only supports no-std so it's a good way to check that no std importst exist etc).

I'd keep the PR to those things and avoid the rustfmt and other CI things you did in your branches etc offhand so that it's pretty focused, but otherwise that'd be amazing :)

(and I think this is basically all true for scale-encode too!)

Sure thing. Let me clean up a little on my end.
One last thing:  scale-bits currently depends on my GitHub fork due to its no-std compatibility. There's already an open PR for scale-bits (https://github.com/paritytech/scale-bits/pull/2) . If you accept this PR and could publish it on crates.io there'd be no need to change the import to GitHub.

Ah yes; we can't have any github dependencies in the crate (they prevent publishing it), so we'd def need to get scale-bits to no-std first then; I'll have a look at that!

Opened a PR on scale-encode: https://github.com/paritytech/scale-encode/pull/11. Let me know what you think of it, I will adapt on both encode and decode branches, so you don't have to review twice.


Remove old configurations

I'm opening this as a PR but because it's easier than an Issue in this case.
I think that no one uses this configuration any more. It had sense when all/nearly all the rules didn't have type-solving. But right now configurations like that one have little sense.
If you use these configurations or you think it is worth to keep them just close this PR :)

Is the file statistics.yaml still referenced somewhere in the code base? I know that a dogfooding approach was used to run detekt's statistic features on the detekt code base. I'm not sure whether we want to keep it.
I think the Gradle config could be removed quite safely.

Is the file statistics.yaml still referenced somewhere in the code base? I know that a dogfooding approach was used to run detekt's statistic features on the detekt code base. I'm not sure whether we want to keep it.

I couldn't find any reference to statistics.yml (except the one that I removed).


doc(xjl): added Chinese version of ppg doc

Please @zjowowen  review these changes

Thanks for you contribution. BTW, please modify the name of this pull request as our previous format.

Thanks for your contribution, we will merge this PR now!


Can't locate object method "new" via package "Tags::HTML::Pager"

t/Tags-HTML-Pager/03-new.t and t/Tags-HTML-Pager/05-process_css.t fail with the following error
Can't locate object method "new" via package "Tags::HTML::Pager" at /home/cpansand/.cpan/build/2022091919/Tags-HTML-Pager-0.01-uzTrH1/blib/lib/Tags/HTML/Pager.pm line 24.
# Looks like your test exited with 255 just after 1.
t/Tags-HTML-Pager/03-new.t ..........
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 6/7 subtests

Hi,
Fixed in 0.02 release.
Thanks.

Ha, sorry, another bug. Release in 0.03


Fix typos

Pull Request Template
Description
Found via typos --format brief
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] I have checked my code and corrected any misspellings

:partying_face: :partying_face: :partying_face: :partying_face: :partying_face:


Proposal to Create SIG-TypeScript-Compilation

SIG-TypeScript-Compilation's primary goal is to describe and refine a suitable solution for compiling TypeScript program to WebAssembly based on the Wasm GC proposal and executing it in both browser and standalone Wasm runtime. The scope of this SIG is limited to discussions about compiling TS to WebAssembly, the necessary runtime API (potentially defined as WASI) for supporting TS language features such as Any type, and exploration of how WebAssembly can grow to provide better support of dynamic languages natively.

Hello,
The TSC discussed this SIG proposal at our most recent meeting. We have the
following feedback:

The SIG must not fork the TypeScript language. This can be achieved by only
supporting a strict subset of the language, or by ensuring that all language
extensions (e.g. additions to the type system or standard library) are
coordinated with the TypeScript core team and have a path to being upstreamed.

Any non-standard engine extensions or runtime interfaces exposed to guest
TypeScript Wasm binaries must enter a standards process (e.g. become
standards-track WASI or core Wasm proposals). Any such extensions must not
ship in production until they are on the path to standardization and are
sufficiently stable.

We would like to see verbiage enshrining these requirements in the SIG's
charter.
On behalf of the TSC,
Nick Fitzgerald

Thank you @fitzgen and TSC for the valuable comments! Just one question regarding to the words "ship in production"  below,  what is the exact definition?

Any such extensions must not ship in production until they are on the path to standardization and are sufficiently stable

@xwang98,
Thanks for your patience.

Thank you @fitzgen and TSC for the valuable comments! Just one question regarding to the words "ship in production" below, what is the exact definition?

The features should be behind an experimental flag (e.g. --enable-foo-proposal) and should not be enabled by default in any toolchain or runtime until the proposal reaches the equivalent of phase 4 in the WebAssembly standards process. Additionally, enabling the feature in production deployments should be strongly discouraged, with warnings about the experimental nature and the possibility of breaking changes at any point.
On behalf of the TSC,
Nick Fitzgerald

@fitzgen Thank you for the explanation!
I fully understand the motivation behind however I are not sure phase 4 is appropriate level as requirement. Looking at the proposals from WebAssembly and WASI and many level 3 and below proposals are implemented already, I doubt the suggested rules have been followed in the BA practices:

https://github.com/WebAssembly/proposals
https://github.com/WebAssembly/WASI/blob/main/Proposals.md

Additionally, the primary goal of SIG is for discussion and possibly creating some proposal. It doesn't mean necessary developing tools or runtime.  I see such requirements are better for the projects under BA, rather than SIG.

Any non-standard engine extensions or runtime interfaces exposed to guest
TypeScript Wasm binaries must enter a standards process (e.g. become
standards-track WASI or core Wasm proposals). Any such extensions must not
ship in production until they are on the path to standardization and are
sufficiently stable.

Would it be sufficient to simply state that any new APIs would be added via WASI proposal process?
I don't have a lot of experience within BA, but what is the scope of SIGs as opposed to proposals? From personal experience, other projects define SIGs as coordination venues rather than concrete proposals (CG's subgroups are a similar idea).

The features should be behind an experimental flag (e.g. --enable-foo-proposal) and should not be enabled by default in any toolchain or runtime until the proposal reaches the equivalent of phase 4 in the WebAssembly standards process. Additionally, enabling the feature in production deployments should be strongly discouraged, with warnings about the experimental nature and the possibility of breaking changes at any point.

I am confused by WebAssembly standards process reference, does this requirement derive from it? To my best knowledge decisions about flags and warning are left to the implementer, at the very least I can't find anything about it in CG docs (WASI process seem to now refer to CG process).

@xwang98:

I fully understand the motivation behind however I are not sure phase 4 is appropriate level as requirement. Looking at the proposals from WebAssembly and WASI and many level 3 and below proposals are implemented already, I doubt the suggested rules have been followed in the BA practices:

That's a good point. The exact required level of standardization and stability might vary based on which standards body is involved, and the nature of the proposals. The TSC is happy to provide guidance on whether a lower level of stability is sufficient for specific proposals.
Taking a step back, the TSC, as well as the board, which we consulted last week, feel strongly that this SIG should work towards results that follow two key principles:

The language being compiled must truly be TypeScript, not some fork of it that's not fully compatible.
Any APIs or new instructions a runtime exposes to Wasm to make it a viable compilation target for TypeScript compilation must go through a standardization process, must achieve consensus in that process, and be sufficiently stable before they can be enabled by default in any runtime under the Bytecode Alliance's umbrella.

These principles directly follow from the BA's operational principles, and in particular the "How We Want to Work With Others" section.
Note that these principles are not specific just to this proposed SIG; we are applying them equally to all work under the BA umbrella, including other recently proposed SIGs.

Additionally, the primary goal of SIG is for discussion and possibly creating some proposal. It doesn't mean necessary developing tools or runtime. I see such requirements are better for the projects under BA, rather than SIG.

You're right that some of the above is about implementations. The SIG should however work in a way that makes it easy for any concrete implementations to follow these principles. Additionally, the SIG should ensure that all contributors to these projects are fully aware of these requirements.

@penzn

Would it be sufficient to simply state that any new APIs would be added via WASI proposal process?
[...]
I am confused by WebAssembly standards process reference, does this requirement derive from it? To my best knowledge decisions about flags and warning are left to the implementer, at the very least I can't find anything about it in CG docs (WASI process seem to now refer to CG process).

We explicitly don't want to further any ecosystem fragmentation. As such, we want to ensure that any work resulting from this SIG's activities targets more than just a single runtime. The best way to ensure this is to get consensus to not enable any required features by default until they're sufficiently far along in a standardization process such that they can be implemented by multiple WebAssembly runtimes.
Additionally, WASI isn't the only body to coordinate with for this work. Depending on the direction the SIG ends up taking, the WebAssembly CG itself as well as other standards bodies might become involved. Plus, if any changes to TypeScript as a language are required, close coordination with the TypeScript team will become necessary.
We (Till, Nick, and Bailey) on the TSC can assist in coordinating with the relevant groups.

On behalf of the TSC,
Bailey Hayes
@bytecodealliance/tsc

@ricochet Thank you and TSC for positive response.  I have a submitted a change for added paragraphs according to the discussion:
The SIG is not intended to fork the TypeScript language. This can be achieved by only supporting a strict subset of the language, or by ensuring that all language extensions (e.g. additions to the type system or standard library) are coordinated with the TypeScript core team and have a path to being upstreamed.

This SIG follows BA's common guideline as the TSC suggested: Any APIs or new instructions that a runtime exposes to Wasm must go through a standardization process, and achieve consensus in that process, and be sufficiently stable before they can be enabled by default in any runtime under the Bytecode Alliance's umbrella.

Please see if it works out all the concerns.

The TSC has accepted this proposed SIG! Thank you for your patience and help with tweaking the charter.
If you need a SIG-TypeScript-Compilation repository, we can create one for you. Otherwise, if you are fine with just meeting minutes for the meantime, that is alright as well.
We will create a Google Groups mailing list for you soon and share details once they are ready.
Please do the following two things:

Send a pull request to https://github.com/bytecodealliance/meetings detailing the meeting times, creating a directory for meeting notes, and advertising how to join and participate.

Send an email to the Bytecode Alliance contributors Google Group announcing the creation of the SIG after the above pull requested has been merged. Example

Thanks again!
On behalf of the TSC,
Nick Fitzgerald
@bytecodealliance/tsc


fix: github link for master

I have uploaded spotDL v3 to PyPi, so you can directly use $pip install spotDL to get V3. FOr those who want experimental feature a.k.a not completely tested ones, install spotDL from spotfy-downloader:next-rel-dev

Hey @aasmpro join in on discord
(Check the team your on)


Scandinavian Defense: Portuguese Gambit

Changelog

Removed 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Bb5+ Nbd7 5. f3 Bf5 named Scandinavian Defense: Portuguese Variation, Portuguese Gambit.
Renamed 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 from Scandinavian Defense: Portuguese Variation to Scandinavian Defense: Portuguese Gambit.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. c4 named Scandinavian Defense: Portuguese Gambit, Banker Variation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Nf3 named Scandinavian Defense: Portuguese Gambit, Classical Variation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. g4 named Scandinavian Defense: Portuguese Gambit, Correspondence Refutation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Bb5+ c6 named Scandinavian Defense: Portuguese Gambit, Elbow Variation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. Bb5+ Nbd7 6. c4 named Scandinavian Defense: Portuguese Gambit, Jadoul Variation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Bb5+ Nbd7 5. Be2 named Scandinavian Defense: Portuguese Gambit, Lusophobe Variation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. Bb5+ Nbd7 6. Nc3 named Scandinavian Defense: Portuguese Gambit, Melbourne Shuffle Variation.
Added 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Be2 named Scandinavian Defense: Portuguese Gambit, Wuss Variation.

The Name of 1. e4 d5 2. exd5 Nf6 3. d4 Bg4
This line 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 in the Scandinavian Defense has many different names across chess literature. Selby Anderson released the book Center Counter Defense: The Portuguese Variation in the year 1997 and, apparently, named it Portuguese Variation. In his book Smerdon's Scandinavian, David Smerdon called this line Portuguese Complex, but he noted that it was also called Portuguese Opening as well as Jadoul Variation [Section 1]. It's called Portuguese Gambit in Wikipedia's list of chess gambits and Portuguese Variation as well as Jadoul Variation in Wikipedia's article on the Scandinavian Defense. (Unfortunately, I was unable to check the sources Wikipedia provides because I couldn't find the referenced books.)
Since Selby Anderson's book predates all other sources, there is an argument to name this line Portuguese Variation. However, Black delays taking back the pawn on d5 twice (first time with 2... Nf6 and second time with 3... Bg4). This gives White the opportunity to secure the extra pawn with e.g. 1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. g4 Bg6 6. c4. Additionally, Selby Anderson may not have been aware of the dubious nature of this variation (Stockfish gives White +0.8). Furthermore, David Smerdon repeatedly refers to this line as a gambit despite calling it Portuguese Complex. Because of this, I argue that this line should be called the Portuguese Gambit.
Variations in the Portuguese Gambit
Smerdon's Scandinavian is currently the most extensive book on the Portuguese Gambit. It categorizes all major responses from White after 1. e4 d5 2. exd5 Nf6 3. d4 Bg4. Smerdon also offers creative names for all variations covered by his theory. Here are the variations sorted by chapter:

1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. c4 is called The Banker. (White "banks" the extra pawn with the immediate 5. c4.)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. Bb5+ Nbd7 6. c4 is called The Jadoul. (Named after Michel Jadoul who is one of the earliest exponents of the Portuguese Gambit [Introduction, Inspirational Game 1].)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. Bb5+ Nbd7 6. Nc3 is called The Melbourne Shuffle. (Played by many australian IMs from Melbourne [Chapter 3]. It is named after a rave dance which originated in Melbourne.)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. f3 Bf5 5. g4 is called The Correspondence Refutation. (A line against the Portuguese Gambit successfully employed by the correspondence community [Chapter 4].)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Be2 is called The Wuss. (Apparently, 4. Be2 is a wimpy move and only a wuss would play it.)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Bb5+ Nbd7 5. Be2 is called The Lusophobe. (According to Wikipedia, Lusophobia is irrational hostility, racism or hatred towards Portugal, the Portuguese people or the Portuguese language and culture. David Smerdon is making a joke by referring to the line 4. Bb5+ Nbd7 5. Be2 as "Anti-Portuguese" or "effective against the Portuguese Gambit".)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Bb5+ c6 is called The Elbow. (Given the effectivness of the line 4. Bb5+ Nbd7 5. Be2, occasionally playing 4... c6 may discourage players from studying it while preparing against you. Hitting your well prepared opponent with your elbow is a metaphor for playing 4... c6 [Chapter 7].)
1. e4 d5 2. exd5 Nf6 3. d4 Bg4 4. Nf3 is called The Classical. (Refers to the fact that the move 4. Nf3 is principled [Chapter 8].)

Thanks! (Rebased.)


Require http not found when using SvelteKit/vite

When I try to use the node.js secret manager library with Vite, it throws this error
 node_modules/vite/dist/node/chunks/dep-85dbaaa7.js:62884:18: note: This error came from the "onResolve" callback registered here     62884 │             build.onResolve({ filter: /^[\w@][^:]/ }, async ({ path: id, importer, kind }) => {           ╵
./node_modules/tunnel-agent/index.js:5:19: note: The plugin "vite:dep-pre-bundle" was triggered by this import         5 │   , http = require('http')
I can use datastore fine, in the same project, but secret manager isn't happy
Environment details

OS: MacOS Monterey
Node.js version: 14.18.1, (and 16.13.0)
npm version: 8.1.0
@google-cloud/secret-manager version: 3.10.1

Steps to reproduce

git clone https://github.com/cucumberbob123/secret-manager-bug-report.git
npm install
npm run dev

Thanks!

Hi @cucumberbob123,
Unfortunately we're not currently set up to support browser-side issues. I'm not familiar with SvelteKit/vite, but from doing a preliminary search online, it looks like this issue might be build related as opposed to library related.
Just to confirm that this is the case, can you confirm one of these samples works for you server-side? https://github.com/googleapis/nodejs-secret-manager/tree/main/samples
Thanks!


Issue/24/interact with mysql database

As outlined in #24. Before merging, discuss with @jchiang87 about user input for database connection details.

Ok, I think I've made the necessary changes for now and asked Rahul to test and review the code. As soon as he signs off we'll merge.

Changes Unknown when pulling 774646c7df8b5238137d6ce91ee603af2216c87b on issue/24/interact-with-mysql-database into ** on master**.


Add support to skip tests that are not present in testrun (#50)

@zeburek Please, could you add a specific unittest of your feature?

@apallier I'll try to make my best. But It could be hard for me, I don't have such an experience.

@allankp It seems that everything fixed
Unable to test same things in one test, so added two tests

After merging this PR - I will open new one for #35 issue
My mistake with branches

@allankp Would it be merged?

@zeburek sorry for the delay, thanks for your contribution


Various fixes (bis)

Hello,
I have found that some more fixes were needed:

scale was applied on all types (leading to issues with strings) and even if scale was equal to 1 (leading to conversion of int to float)
mutliple fields fixes done in my last delivery was not following FIT rev 1.7 as it should be handled with an array.
README was containing a small mistake in the usage example.

I have some more fixes in mind, that I will push when I have time for another round of fixes.
All fixes (except README ;-) ) have a spec test associated.
Hope you don't mind receiving multiple pull request along my fixes...

Thanks for the fixes @doc75! I've added a few comments, let me know what you think.

New commits to fix things according to your valuable remarks (except 1 explained in the commented code)
I also added a fix for saling of array elements.
Let me know if anything has to be modified.
I will now try to enhance the lib to support dynamic fields (cf. Rev1.7 §4.5)
After that it will remain to manage Components (cf. Rev1.7 §4.6), but I am not sure to know how this can be done easily.

Thanks @doc75!


chore: added split for permission provider

Description

Splitting permission provider for importexport

PR fixes following issue(s)
Fixes # (issue number)

Summary by CodeRabbit

New Features

Introduced a new class to manage permissions for importing artifacts, enhancing control over artifact import operations.

Refactor

Updated import statements across multiple files for improved code organization.
Replaced PagePermission with ContextPermission in permission management to reflect more granular control over edit operations.

Tests

Modified test cases to align with the new permission model, focusing on context rather than pages.

/ok-to-test<EMAIL_ADDRESS>@tag.Datasource @tag.Fork, @tag.ImportExport @tag.Templates"


Pause causes losing first ping packet

Using flannel as the overlay for my Kubernetes cluster with CoreOS 675.0.0 and have a dedicated etcd cluster running CoreOS 668.2.0.
Whenever I try to access my kubernetes services, it seems some requests get a slight pause that is pretty noticeable.  Investigating it, I found that SSHing into my k8s nodes and trying to ping the different pods that are located on other nodes, I see the first ping packet completely lost.  After doing that excursive for the first time, the next time I run ping command all packets seem to be fine.
Giving it a bit of time to relax and not sending any traffic to those IPs, then SSHing again and attempting the same excursive again, the first ICMP packet again is lost.
I'm not yet able to determine how much time it takes until this staleness becomes a problem needing what seems like a 'refresh'
I did notice however that doing ip -s neighbor list shows those POD IPs as STALE pretty often.  And it when pinging, it takes a good amount of pings (like 10 packets) to become REACHABLE again and then very quickly (in the order of 10-20 seconds) it becomes STALE again.
Incidentally not every time an IP is marked STALE, pinging it would have it lose the first packet.

@danielschonfeld Are you running the default or VXLAN backend?

vxlan backend but just to make sure.... is the distinction is all about doing the following?
/usr/bin/etcdctl set /coreos.com/network/config '{"Network":"<IP_ADDRESS>/16", "Backend": {"Type": "vxlan"}}'

yes, that changes the backend.
flannel's vxlan backend does not mark arp or fdb entries as permanent. It lets them expire just like any other arp entry would. Once it expires, the misses are sent up to flanneld and it pushes the values back into the kernel.
Can you let them expire then do a single ping (ping -c 1) and see what's in the logs. vxlan is verbose so you should see lines notifying of L2 and L3 misses and whether AddL2 and AddL3 succeeded. If you could paste the output, it would be helpful.

you said to let them expire, what signifies them expiring?

you said relaxing it a bit and then trying ping again causes it the first ping packet to get dropped.
So try once when it has reached STALE state and once when it has been completely expunged from the arp cache (just do ip neigh flush)

Before i did this, i checked all entires that use flannel.1 in ip -s neighbor list were showing STALE. This is what I got:
$ ping -c 1 <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.

--- <IP_ADDRESS> ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

And tailing journalctl -u flannel gave me these new entries after i pinged:
May 14 22:15:43 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:15:43.342992 00001 vxlan.go:268] L2 miss: 36:55:bc:7d:22:26
May 14 22:15:43 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:15:43.343242 00001 device.go:216] calling NeighAdd: <IP_ADDRESS>, 36:55:bc:7d:22:26
May 14 22:15:43 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:15:43.343484 00001 vxlan.go:279] AddL2 succeeded
May 14 22:15:51 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:15:51.362256 00001 vxlan.go:263] Ignoring not a miss: 36:55:bc:7d:22:26, <IP_ADDRESS>
May 14 22:15:52 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:15:52.364337 00001 vxlan.go:263] Ignoring not a miss: 36:55:bc:7d:22:26, <IP_ADDRESS>
May 14 22:15:53 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:15:53.366234 00001 vxlan.go:263] Ignoring not a miss: 36:55:bc:7d:22:26, <IP_ADDRESS>

Running sudo ip -s neigh flush dev flannel.1 and then verifying using ip -s neighbor list shows all entries pertaining to flannel.1 as FAILED.
I get the following ping results: (notice this time how odd it is, the packet actually goes through the first time... but I've only waited 5 minutes so i'm not sure what to make out of it)
$ ping -c 1 <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=63 time=2.49 ms

--- <IP_ADDRESS> ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.498/2.498/2.498/0.000 ms

And journalctl -f -u flannel adds the following lines:
May 14 22:20:21 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:20:21.801983 00001 vxlan.go:284] L3 miss: <IP_ADDRESS>
May 14 22:20:21 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:20:21.802235 00001 device.go:242] calling NeighSet: <IP_ADDRESS>, 36:55:bc:7d:22:26
May 14 22:20:21 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:20:21.802479 00001 vxlan.go:295] AddL3 succeeded
May 14 22:20:39 node1.c.my-project.internal sdnotify-proxy[725]: I0514 22:20:39.556219 00001 vxlan.go:263] Ignoring not a miss: 36:55:bc:7d:22:26, <IP_ADDRESS>

So L3 misses (arp) are handled ok -- without packet loss. But L2 misses (fdb, that's vxlan part) result in dropped packets. I now recall that I have seen this but I don't remember tracking it down in the kernel on what causes this. Marking as bug and will investigate.

In the mean time, will downgrading to a different kernel solve this issue?

I am not sure. I haven't followed vxlan changes in the kernel.

@eyakubovich @MohdAhmad how would I know what CoreOS release this solution is included in?

@danielschonfeld It's not yet released (we haven't tagged a version since the merge). Actually we just found a bug related to this. We can update this issue once this lands in alpha.

@eyakubovich ,does this bug fixed ,i have got this problem


Update client pool logic

client/pool does not report connection problems properly: in cases of authorization errors, version incompatibility, incorrect database address, network problems, etc.
Also, we have https://github.com/go-mysql-org/go-mysql/pull/701 with a request for new functionality in the same case.
This PR updates the pool logic a bit: more user-friendly function NewPoolWithOptions, and option WithNewPoolPingTimeout for doing connect&ping during pool initialization.
Also, this fixes make test-local after https://github.com/go-mysql-org/go-mysql/pull/803.

@lance6716 sorry, one more time :)
Together we didn't notice that I accidentally committed the wrong thing to the Makefile:


http to https redirect is not working

at least there is missing ";" in the config.

Thanks for the reporting!


Do not auto find runtime handler for user namespaces tests

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
We rely on the test context runtime handler, which can be empty ("") for the default one reported by the runtime.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

@kubernetes-sigs/cri-tools-maintainers PTAL

/approve
/lgtm

@kubernetes-sigs/cri-tools-maintainers PTAL

@kubernetes-sigs/cri-tools-maintainers PTAL

@saschagrunert, looks good to me!
Even though I have no approval powers here.

@kubernetes-sigs/cri-tools-maintainers PTAL


Increase build performance

Some changes help with the consistency of up-to-date
checks during the build process. Other changes help
with caching improvements based on normalizing the
detection of changes within the outputs of tasks.
The final category of changes helps with absolute
path changes so that remote caching is more effective.

@jeremydyoung any outstanding questions here? were you able to make an upstream PR?