Support for RTL8710CM?

Is there support for RTL8710CM yet?
I have a couple of devices (Tapo L920 LED controllers) using this chip and would love to be able to flash them with libretuya/esphome.

No, not yet. See #37 and #36.

anything we can do to push support forward? idk what's missing/required :(

Thanks for the information!
Yes, I realized support for the RTL8720C family is in the very early stages. Just figured I'd report my findings.
That makes sense regarding the AT CLI. Since the stock TP-Link EP25 had it I assumed it was standard and always built w/ the RTL MCUs. Their firmware must be based off the "demo" (which makes sense, I guess).
A quick perusal through their stock firmware revealed that there seems to be a way to trigger the SDK-included OTA function remotely. No signatures are checked either (you can send garbage and it will be written as long as the checksum is correct). It should be possible replace the firmware on these smart plugs wirelessly without opening them up! 😎
I'll poke around some more with download mode. I've tried ping\n on UART2 but I wasn't aware of the PA0/PA13 combination. These EP25 plugs are hard enough to get open so anything that makes re-flashing easier will be helpful.

Eventually OTA will be supported.
Have you dumped the original firmware prior to flashing? If yes, you can always mess with it by just flashing it back.

I've got a couple of tp-link KP115 Kasa Smart Wi-Fi Plug (slim energy monitoring) which appear to contain RTL8710CF modules (12-pin pcb mounted through hole on the main board)

I'm keen to test these out with libretiny if someone has some pointers for how I get started?

As indicated in this thread (and in LibreTiny docs -> boards, chips, features) RTL8720C is not yet fully supported. Thus, the documentation pages are also not fully written.

Kinda why I was asking here ;-)
I'm an out of practice embedded C/C++ developer who is willing to have a play with it, but thought rather than re-doing work that's already been done I'd ask the question.

I was playing with a Tuya WBR3-laden ME81H (thermostat for a heater).  I see above documentation that I found from this page during my trials: https://developer.tuya.com/en/docs/iot/burn-and-authorize-wbr-series-modules?id=Ka78imt8pf85p#title-7-Method 2%3A Separated solutions for flashing and authorization
After fixing up ltchiptool to support Linux (https://github.com/libretiny-eu/ltchiptool/pull/13), I was able to dump the OEM Flash and ROM, and to burn a build of ESPHome/generic-rtl8720cf-2mb-992k to the module.  Booting this image however is troublesome; I run into a bootloader verification failure, and so booting halts:
INFO Starting log output from /dev/ttyACM1 with baud rate 115200
[19:48:39]
[19:48:39]== Rtl8710c IoT Platform ==
[19:48:39]Chip VID: 5, Ver: 3
[19:48:39]ROM Version: v3.0
[19:48:39]
[19:48:39]== Boot Loader ==
[19:48:39]Dec  5 2019:14:02:18
[19:48:39]
[19:48:39]fwx SELE[fffffffe]
[19:48:39]fw SELE Bitidx 1, fw1 valid 0, sn 0, fw2 valid 1, sn 1
[19:48:39]fw2 USE, return sn 1
[19:48:40]
[19:48:40]== Rtl8710c IoT Platform ==
[19:48:40]Chip VID: 5, Ver: 3
[19:48:40]ROM Version: v3.0
[19:48:40]
[19:48:40]== Boot Loader ==
[19:48:40]Dec  5 2019:14:02:18
[19:48:40]
[19:48:40]fwx SELE[fffffffe]
[19:48:40]fw SELE Bitidx 1, fw1 valid 0, sn 0, fw2 valid 1, sn 1
[19:48:40]fw2 USE, return sn 1
[19:48:40][MISC Err]Hash Result Incorrect!
[19:48:40]Boot Load Err!

Comparing the dumped images, it seems the initial (and trailing?) portions of Flash are the same; I see "hash" related strings at the same offsets (I have not poked with Ghidra yet, lacking the time currently).
I wonder if using the Tuya "RTL8720CF chip burning tool" would program the correct hash, or if this has been reversed yet?

Download and run the RTL8720CF chip burning tool."

Anyway, it seems I'm at a dead end with this board, and support is in progress, so kudos for everything so far and in the works.  In the mean time, I've ordered an ESP32-C3-12F module to replace this unit (which seems to operate fine without the Tuya module installed, in case anyone needed to know).
As such, let me know if there's anything I can test or help reverse to support the Tuya WBR3/RTL8720CF.

@nmschulte
I can look into this if you post the OEM firmware dump - it contains the hash keys, so that I can check if they are the same as used in LT.

I can look into this if you post the OEM firmware dump

me81h_16-wbr3-oem-dump.tar.gz

This firmware uses OTA1 address of 0x10000, while the board you've chosen has it at 0xC000 - it's incompatible with WBR3.
As you've noticed, support is in progress. The WBR3 board (with correct offsets) is available in feature/realtek-update branch of LibreTiny. If you checkout that branch (I believe you can use version: dev under framework: and then add source: https://github.com/libretiny-eu/libretiny#feature/realtek-update, or something similar) you'll be able to use board: wbr3.
That being said, when RTL8720CF support rolls out, it will automatically adjust flash addresses to match the chosen board code (same will be done for RTL8710BN shortly).

The WBR3 board (with correct offsets) is available in feature/realtek-update

You rock.  I'll give it a whirl.

You rock. I'll give it a whirl.

Success!
INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyACM1 with baud rate 115200
[12:10:22]
[12:10:22]Boot Loader <==
[12:10:22]
[12:10:22]== RAM Start ==
[12:10:22]I [      0.000] LibreTiny v1.4.1+sha.d41d328 on wbr3, compiled at Nov  2 2023 11:53:56, GCC 10.3.1 (-Os)

[12:10:33]Interface 0 IP address : <IP_ADDRESS>[I][wifi:560]: WiFi Connected!

[12:10:33][D][wifi:569]: Disabling AP...
[12:10:33][C][ota:097]: Over-The-Air Updates:
[12:10:33][C][ota:098]:   Address: thermostat.local:8892
[12:10:33][C][api:025]: Setting up Home Assistant API server...
[12:10:33][I][app:062]: setup() finished successfully!
[12:10:33][I][app:102]: ESPHome version 2023.11.0-dev compiled on Nov  2 2023, 11:51:43

[12:10:33][C][lt.component:013]: LibreTiny:
[12:10:33][C][lt.component:014]:   Version: v1.4.1+sha.d41d328 on wbr3, compiled at Nov  2 2023 11:51:25, GCC 10.3.1 (-Os)
[12:10:33][C][lt.component:015]:   Loglevel: 3
[12:15:22][I][ota:117]: Boot seems successful, resetting boot loop counter.
[12:15:22][D][lt.preferences:104]: Saving 1 preferences to flash...
[12:15:22][D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed

WiFi shortly there-after disassociated but subsequently reconnected:
[12:15:48]wifi link err:001f0002
[12:15:48]dissconn reason code: 4
[12:15:48]receive deassoc
[12:15:48]handshake done, connected stage, recv deauth/deassoc

[12:15:52]Interface 0 IP address : <IP_ADDRESS>[W][component:214]: Component wifi took a long time for an operation (4.33 s).
[12:15:52][W][component:215]: Components should block for at most 20-30ms.
[12:15:52][I][wifi:560]: WiFi Connected!

[12:15:52][D][wifi:569]: Disabling AP...
[12:15:52][W][component:214]: Component wifi took a long time for an operation (0.06 s).
[12:15:52][W][component:215]: Components should block for at most 20-30ms.

If you checkout that branch (I believe you can use version: dev under framework: and then add source: https://github.com/libretiny-eu/libretiny#feature/realtek-update, or something similar) you'll be able to use board: wbr3.

Initially, I hacked my way through this, unaware that I could specify these things in the device YAML; I platformio install'd the libretiny branch, and then manually ran generate_components.py and patched ltchiptool.  But, to use this mechanism, one must specify like so in the device YAML, to have PlatformIO/ESPHome automatically pull the correct version:
rtl87xx:
  board: wbr3
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-updates

Mainly, version needs to be a proper semver, and cannot match something listed in ARDUINO_VERSIONS, otherwise this error arises:

Framework version needs to be explicitly specified when custom source is used.

It seems the trend is to use a version: 0.0.0 spec in this kind of scenario.
I guess ltchiptool could be installed in the same way w/ platformio install https://github.com/libretiny-eu/ltchiptool.git#feature/flasher-update (or perhaps pip install git+https://github.com/libretiny-eu/ltchiptool.git#feature/flasher-update); I still manually patched whichever instance is in use.

Also, it seems the firmware insists on outputting to UART2 (LOG_TX / LOG_RX), messages from WiFi driver:
[Driver]: ....
As well, I can't seem to configure ESPHome to output on the other exposed UART (TXD / RXD).  This is stumping me.

After modifying libretiny to define PIN_SERIAL0_RX and PIN_SERIAL_TX, I now have a Tuya Climate device working seemingly well on the WBR3.  Kudos!

UART2 is the default port for log messages, same applies for Tuya firmware. Why did you need to change it, and how did you try to do so?

I didn't need to change the logging UART.  Though, because I was unable to use the other UARTS (HW_UART1 and HW_UART2, because the hardcoded checks against PIN_SERIALn_RX/..._TX, which seem to default to -1/255), I did try disabling the logging and connect this UART (HW_UART2) to the Tuya comm interface ... but because the WBR3 firmware/driver outputs to/configures it regardless, this failed (ME81H seems to require 9600 baud, as well).
Then, I noticed in the debug output that the UART0 and UART1 RX/TX pins were outputting as -1/255 (due to falling into SoftwareSerial) and so discovered the issue that feature/i2c-spi purportedly resolves; I couldn't find any uses of PINS_SERIALn_..., and so just jammed in PIN_SERIAL0_... with 13 and 14, and then ESPHome/LT picked up the Tuya uart: YAML and configured the correct UART for Tuya comms (UART0; WBR3 TXD/RXD pins).
commit 657ad8940efa8e172c380a5f819680e87cbc9644 (HEAD -> feature/realtek-update, github/feature/realtek-update)
Author: Nathan Schulte<EMAIL_ADDRESS>Date:   Thu Nov 2 21:55:25 2023 -0500

    define PIN_SERIAL0_RX/PIN_SERIAL0_TX for wbr3

diff --git a/boards/variants/wbr3.h b/boards/variants/wbr3.h
index 40f6595..d40a1d5 100644
--- a/boards/variants/wbr3.h
+++ b/boards/variants/wbr3.h
@@ -28,8 +28,10 @@
 // ------------
 #define PIN_SERIAL0_RX_0 12u // PIN_A12
 #define PIN_SERIAL0_RX_1 13u // PIN_A13
+#define PIN_SERIAL0_RX   13u // PIN_A13
 #define PIN_SERIAL0_TX_0 11u // PIN_A11
 #define PIN_SERIAL0_TX_1 14u // PIN_A14
+#define PIN_SERIAL0_TX   14u // PIN_A14
 #define PIN_SERIAL1_CTS  4u  // PIN_A4
 #define PIN_SERIAL1_RX_0 2u  // PIN_A2
 #define PIN_SERIAL1_RX_1 0u  // PIN_A0

Setting LT_UART_DEFAULT_PORT to 0 or 1 should redirect all UART output to that port. If you need to get rid of the WiFi messages specifically, try using LT_UART_SILENT_ALL.

The build is already proceeding w/ these defines, yet the WiFi output still persists.  This is not an issue though as it's on the logging UART:
-DLT_UART_SILENT_ALL=1, -DLT_UART_SILENT_ENABLED=1

Hi @nmschulte just wondering how stable is LT running on the thermostat since?

Admittedly I haven't yet put it into production, only had it running for about a day trial during the above.  It dropped WiFi a few times, but re-authed each time.  Seemed to have no issues then; I'm just going to put it into service and see how it fares ... soon-ish (maybe a week or two) I should be able to install it and give better feedback.
Have the branches merged yet?  I assume not; am hesitant to alter my dev. environment until then.

It dropped WiFi a few times, but re-authed each time.

How frequent did that happen and it does stay offline for too long before reconnecting?

How frequent did that happen and does it stay offline for too long before reconnecting?

I only noticed less than a handful of times, and it basically immediately reconnected each time.  I wasn't sure the cause.  Admittedly, I didn't pay it much mind; the overnight test, showed no issues with the logs displayed in HASS.

Hello,
I just saw a new tuya module to control a pellet stove today. It is based on WBR1

I tried to flash ESPHome. I used generic-rtl8720cf-2mb-992k to compile ESPHOME. It work fine and I can flash, but I have the same HASH Result incorrect as for the WBR3 above in this issue.

I presume it's the same problem of offset as WBR3. Unfortunately, I think I'm unable to make the same commit as you made for WBR3.
Here is the OEM Dump of the Flash, but maybe it's the ROM that is needed for this value to be found ?
ltchiptool_ambz2_2023-12-11_13-15-16.bin.zip

You can use the dev branch. In my post about offsets there are instructions what should be added to your ESPHome YAML.

instructions what should be added to your ESPHome YAML.

I shared mine here: https://github.com/libretiny-eu/libretiny/issues/44#issuecomment-1791694851
I still had to do the serial modification; the spi-i2c branch didn't seem to have what I needed, but maybe my config was wrong or I misunderstand somehow.

You can use the dev branch. In my post about offsets there are instructions what should be added to your ESPHome YAML.

Sorry, I didn't realize that the instructions for WBR3 would maybe work with WBR1 as I don't see WBR1 in your commit in feature/realtek-update.
I'll test with board: WBR3 tonight and report back here.

I can confirm that the WBR1 boot fine with WBR3 config from the dev branch after flashing. Offset seems identicals
For the moment, this board is a spare part for me, so do not hesitate if you need any tests that can help to push support for RTL8710Cx forward

Sorry if I sound stupid here but I can’t get esphome to see wbr3 as a valid board type.
Can someone give brief instructions on how they got the necessary version of esphome installed?
thanks.

Can someone give brief instructions on how they got the necessary version of esphome installed?
thanks.

Hello,
Here is my code in yaml
rtl87xx:
  board: wbr3
  family: rtl8720c
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-update

WBR1 and WBR3 (and all Tuya RTL8720CF boards) are identical except for the pinouts, so they will run fine. Generic rtl8720cf has a different offset, since it's meant for BW15 board (which has a separate definition too).

@rtorrente  That worked :-) I was able to compile esphome firmware without issue.
However, when I try to install the firmware with ltchiptool it fails after about 5% write with this error:
send error: expected ACK; got b'\x15' for block 16
Anyone seen this before or know the reason?

How are you guys writing the firmware to the modules? Are you using ltchiptool or something else?

How are you guys writing the firmware to the modules? Are you using ltchiptool or something else?

Yes, ltchiptool works fine for me (though on Linux I need a different version, which I manually patched in-place because I'm unsure how to specify a different version/branch to use for platformio).

What board are you flashing? RTL8710CM or RTL8710CF?
Mine is a m

I have a TP-Link Tapo P100 smart plug which has a RTL8720CF. Tried board:generic-rtl8720cf-2mb-992k, got the "Hash result incorrect" message on boot. Then I tried board: WBR3 with the following:
rtl87xx:
  board: wbr3
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-updates

The device can boot and connect to WiFi. But I can't switch the relay on. I tried all GPIO from 0 to 23. None of them switch on the relay or the LED indicator.
Any thoughts?

Any thoughts?

Did you make it work with ESPhome? What is your gpio configuration for the relay, LED, and button?

I've successfully compiled and ran the PinScan example (amazingly helpful, btw!) and flashed libretiny-esphome on a RTL8710CM with your recent changes.
Everything I was able to test seems to work using the generic-rtl8720cf-2mb-992k board (with the exception of esphome OTAs, but it doesn't look like OTAs are implemented for any of the libretiny-supported RTL MCUs at the moment). The boards I'm playing with (TP-Link EP25/KP125 Smart Plugs) are extremely simple though so outside of WiFi & GPIOs there isn't much. Only minor issue is I cannot seem to read the onboard BL0937 (see: HLW8012). I might have it configured incorrectly, though; I need follow the traces again and/or try interfacing directly instead of using esphome.
It seems compiling a project with PlatformIO and/or libretiny doesn't pull in the AT command CLI from the SDK. Is there a configuration option and/or flag I've glossed over that enables it? This would allow use of the built-in OTA functionality. I had to flash the flash.bin image directly onto the SPI flash because the EP25s refuse to go into UART download mode (even after flashing a libretiny-built project).

How do you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF.

How can you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF.

Ensure you have PlatformIO installed. Review the Quick Start Guide if you haven't used PlatformIO directly before.
Clone the PinScan repo. Edit src/pinscan.h and change USE_WIFI to 1 and enter your WiFi information into WIFI_SSID/WIFI_PASS. Add the following to platformio.ini:
[env:rtl8720cf]
board = generic-rtl8720cf-2mb-992k

You should then be able to build by running pio run -e rtl8720cf. Flash the firmware to the device you're working with. Let it connect to your WiFi network (monitor your DHCP server to figure out what IP address it got). You should then be able to telnet into the device and use PinScan as described in the README.
Be careful what pins you manipulate arbitrarily, though. Don't have the device plugged into the mains when manipulating it. Power the 3.3v rail only (as you would when flashing). There may be pin configurations that damage/break the device; I'd highly recommend tracing the PCB traces as much as possible before switching random pins to OUTPUT and toggling them on and off.

As an aside, how difficult was it to get into the TP-Link Tapo P100? The TP-Link EP25/KP125 Smart Plugs were an absolute pain to open without causing visible damage. Maybe with practice you could do it. They seem like great plugs and, with libretiny, Esphome seems to run great. I'm waiting on OTA support before I can really start using them, though.

How can you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF.

Ensure you have PlatformIO installed. Review the Quick Start Guide if you haven't used PlatformIO directly before.
Clone the PinScan repo. Edit src/pinscan.h and change USE_WIFI to 1 and enter your WiFi information into WIFI_SSID/WIFI_PASS. Add the following to platformio.ini:
[env:rtl8720cf]
board = generic-rtl8720cf-2mb-992k

You should then be able to build by running pio run -e rtl8720cf. Flash the firmware to the device you're working with. Let it connect to your WiFi network (monitor your DHCP server to figure out what IP address it got). You should then be able to telnet into the device and use PinScan as described in the README.
Be careful what pins you manipulate arbitrarily, though. Don't have the device plugged into the mains when manipulating it. Power the 3.3v rail only (as you would when flashing). There may be pin configurations that damage/break the device; I'd highly recommend tracing the PCB traces as much as possible before switching random pins to OUTPUT and toggling them on and off.
As an aside, how difficult was it to get into the TP-Link Tapo P100? The TP-Link EP25/KP125 Smart Plugs were an absolute pain to open without causing visible damage. Maybe with practice you could do it. They seem like great plugs that are well-built. With libretiny, Esphome seems to run great. I'm waiting on OTA support before I can really start using them, though.

I successfully flashed the PinScan example. (I need to use the board= wbr3 and feature/realtek-update branch though. Otherwise,  it boots with a hash error).
However, by using the PinScan tool, I still cannot find the GPIO of the relay or the status LED. Very weird.
The  TP-Link Tapo P100 is also very hard to open.

I successfully flashed the PinScan example. (I need to use the board= wbr3 and feature/realtek-update branch though. Otherwise, it boots with a hash error).
However, by using the PinScan tool, I still cannot find the GPIO of the relay or the status LED. Very weird.

I'm glad you got it flashed. It definitely took some fiddling to figure out the pinout and PinScan over telnet was a bit finicky. Two things to keep in mind:

If you're powering the device from a USB UART adapter, it may not provide enough power to drive the relay (ie: you won't hear it click). A multimeter may help.
The LEDs on these devices are commonly "active low". If you only tried switching pins to OUTPUT and turning them HIGH, also try toggling them to LOW.

@rtorrente That worked :-) I was able to compile esphome firmware without issue. However, when I try to install the firmware with ltchiptool it fails after about 5% write with this error:
send error: expected ACK; got b'\x15' for block 16
Anyone seen this before or know the reason?

Did you ever resolve this? I am seeing the same problem. And this is the topic was the only result googling for it.

Hello,
There is one other variant here:
Product: eightree smart plug et20

Unfortunately, I can't find this chip layout at:

https://developer.tuya.com/en/docs/iot/wifibt-dual-mode-module

But it is RTL8720CF.
I cannot load the firmware back and forth.
I will patiently wait for updates.
Thank you for all your work.

Just wanted to share that after traveling down miles of rabbit-holes, I came to the unusual discovery that RTL8710CF (which I want to point out is slightly different chip ID from the OP's RTL8710CM, and also different from RTL8720CF that was discussed later -- if there's no meaningful difference in the hardware, apologies for the noise) can actually be compiled & successfully flashed with the following ESPHome yaml snippet:
rtl87xx:
  board: wbr3
  family: rtl8720c
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny#feature/realtek-update

FWIW, my RTL8710CF was found inside a Kasa HS200(US) hardware v5 (e.g. the smaller one compared to some of the earlier HS200's, I haven't opened one of those yet to see what's inside). Initially, having read this and other issues plus the LibreTiny documentation discussing the Ameba chip nomenclature, I didn't actually realize I had an RTL8710CF and not an RTL8720CF or RTL8710CM.

Oh, interesting. Thank you for the heads-up, @k-w-1!
I guess I can re-add the M515EGWT blinds I once bought (with a wbr3 chipset) into my queue :)
(pointing the other threads here accordingly)

The RTL8710/8720/CM/CF chips are similar and compatible. The difference between 8710 and 8720 is Bluetooth support in 8720. The difference between CN and CF is memory, CF having built-in flash memory, CM having built-in PSRAM.
Keep in mind that while ESPHome works on these chips, certain features are not supported and the firmware might be unstable. A notable example of such features is OTA updating.

Thank you very much for the detailed information, @kuba2k2!
Very appreciated!

Just wanted to share that after traveling down miles of rabbit-holes, I came to the unusual discovery that RTL8710CF (which I want to point out is slightly different chip ID from the OP's RTL8710CM, and also different from RTL8720CF that was discussed later -- if there's no meaningful difference in the hardware, apologies for the noise) can actually be compiled & successfully flashed with the following ESPHome yaml snippet:
rtl87xx:
  board: wbr3
  family: rtl8720c
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny#feature/realtek-update

FWIW, my RTL8710CF was found inside a Kasa HS200(US) hardware v5 (e.g. the smaller one compared to some of the earlier HS200's, I haven't opened one of those yet to see what's inside). Initially, having read this and other issues plus the LibreTiny documentation discussing the Ameba chip nomenclature, I didn't actually realize I had an RTL8710CF and not an RTL8720CF or RTL8710CM.

This is very timely news indeed, since I have just popped open my Kasa EP10 smart plug and discovered it has an RTL8710CF in it!

Has anyone found a proper pinout for such a chip/board yet?
https://github.com/libretiny-eu/libretiny/issues/44#issuecomment-2384991423

I successfully flashed the PinScan example. (I need to use the board= wbr3 and feature/realtek-update branch though. Otherwise, it boots with a hash error).
However, by using the PinScan tool, I still cannot find the GPIO of the relay or the status LED. Very weird.

I'm glad you got it flashed. It definitely took some fiddling to figure out the pinout and PinScan over telnet was a bit finicky. Two things to keep in mind:
* If you're powering the device from a USB UART adapter, it may not provide enough power to drive the relay (ie: you won't hear it click). A multimeter may help.

* The LEDs on these devices are commonly "active low." If you only tried switching pins to `OUTPUT` and turning them `HIGH`, also try toggling them to `LOW`.

I have opened and measured my Tapo P100(EU) / V2.0 but haven't flashed any firmware yet.
Here is what I found out:

The Relais is conncted to 3.3V VD33_OUT (TP1) and then via an NPN Transistor (Q1) and a fuse (F1) to GND. The Pin on the MCU connecting to the base of the transistor is GPIOA_8. Connected via a 515R resistor (R155).
The LED (D10) is a Bi-Color Bi-Polar LED that is connected to GPIOA_9 and GPIOA_10 with a 100R Resistor (R5) in series. If GPIOA_9 is source and GPIOA_10 is the drain then the LED is orange. It illuminates green in the other direction.
The external switch (SW3) is connected to ground and then with a 100R resistor (R145) to GPIOA_17. It is also connected with a separate 10k resistor (R144) to VD33_FLASH (I/O power), VD1833_LPC (LPCsram power) and VA33_TR (analog circuit power) and with a 25R resistor (R128) to CHIP_EN. So a press of the button should completely reset the micro-controller?
The testpoint GPI00 is connected to GPIOA_0

If someone might be able to assist me in converting this to a configuration and tell me how to flash it to the chip I'd appreciate the help. I have a BW15-Kit with the same IC but was not able to successfully flash anything to it yet with ltchiptool (not completing the flash) and flashing with the Realtek AmebaZ2 PG Tool (v1.2.47) just led to invalid RAM signature errors on the serial output from the bootloader.

Hi @ThxAndBye, you must've been reading my mind, because I also started tinkering with P100 EU this weekend to control some Christmas lights. If I had your message, I wouldn't have to desolder the board, because I traced the same pinout as you, so nice job!
After some picking and prodding I managed to get LibreTiny and ESPHome to work on this board including OTA. I found two bugs in the flashing code, which prevented the bootloader and partition table from flashing and caused a hash error. I fixed those and hacked together OTA support, because the P100 is difficult to open.
Here are the instructions to flash ESPHome onto the P100:
0. Install ltchiptool. Until https://github.com/libretiny-eu/ltchiptool/pull/46 is merged, you need to use my fork, otherwise the first 256 bytes are not flashed when flashing UF2. I use Linux, so here are commands for that (how to use venv on Windows):
python3 -m venv tapo-p100
. tapo-p100/bin/activate
pip install git+https://github.com/prokoma/ltchiptool.git@ambz2-fix
ltchiptool -V

1. Open the device. I used some old plastic cards to pry the side wall away from the device. There are two clips on each of the 4 sides, when you get an opening, stick a piece of the card in so it doesn't close again when you work on the other side. Start on the side with the button first, because it is the weakest. Do not use anything metal, because you could scratch or knock some components off the board, there are tiny resistors and traces near the edge.
2. Connect a 3.3V UART interface to the test points. RX to TX1, TX to RX1, V3.3, GND, everything is marked on the board. Also hook a wire to GPIO0, which is used to enter the bootloader. Be 100% sure that your UART converter doesn't output 5V on the VCC, some cheap ones do and will fry the chip. You can check with your multimeter before connecting it to the board. GPIO0 has to be pulled to 3.3V before powering the chip to enter the bootloader. I first powered GPIO0 and then V33.
3. (optional, but recommended) Make a backup dump of the flash, so you can revert to the stock firmware.
ltchiptool flash read -c realtek-ambz2 path/to/store/dump.bin

3. Build an ESPHome firmware and download the UF2 firmware file. You can use vanilla ESPHome, the magic is in the rtl87xx.framework, thanks @kuba2k2 for this extension point. You can use my config as a starting point, just fill in the secrets.
4. Flash the firmware to the board using ltchiptool. Make sure that you are using the modified version of ltchiptool, otherwise you'll get the hash error on boot.
ltchiptool flash write path/to/firmware.uf2

5. The device should boot up. If you use my config, the orange led should light up for a few seconds while it is connecting to your wifi. Disconnect GPIO0 and try the OTA a few times before closing the device, because you don't want to open it twice. Report if there are any issues.

This is picture of my setup, I used some wires from an old IDE cable, because they are thin and easy to solder.

And proof that it works and shows up in HA. Thank you again @kuba2k2 for your hard work on LibreTiny.

Nice work!
I've left some more comments on the ltchiptool thread. I think that some of your changes (particularly the OTA support) could be added to LibreTiny before the realtek-update branch. After all, I can't tell when will that be merged and people can't wait until the chip gets proper support :slightly_smiling_face:

3. Build an ESPHome firmware and download the UF2 firmware file. You can use vanilla ESPHome, the magic is in the rtl87xx.framework, thanks @kuba2k2 for this extension point. You can use my config as a starting point, just fill in the secrets.

Thank you for providing the detailed guide and configuration. I've been able to connect and read the flash of the controller but when compiling ESPHome I get an error when the UF2 is build:
Building UF2 OTA image
|-- esphome_2024.11.2_generic-rtl8720cf-2mb-992k_rtl8720cf_lt1.7.0.uf2
|-- firmware.uf2
|-- firmware.bin
|-- FileNotFoundError: [Errno 2] No such file or directory: '/data/build/tapo-p100/.pioenvs/tapo-p100/image_firmware_is_ota.0x00C000.bin'
|   |-- File "/root/.platformio/penv/.libretiny/lib/python3.11/site-packages/uf2tool/models/image.py", line 79, in read_file_1

I had no issue to build an image with the feature/realtek-update branch but your ambz2-fix doesn't seem to compile correctly. A file with the name image_firmware_is.0x00C000.bin (538K) is created but the image_firmware_is_ota.0x00C000.bin is missing.
ESPHome 2024.11.2 is running on a HA Yellow (CM4), maybe it doesn't compile correctly on the Pi? If I can provide any more details please let me know.

@ThxAndBye This error means that LibreTiny itself is from my branch, but the ltchiptool it imports is the original version. You can try to delete the /root/.platformio/penv/.libretiny directory, that should force re-download of my forked ltchiptool. Also change something in the YAML, so it runs the linker again. If it doesn't work then, please provide the full build log from ESPHome.

@ThxAndBye I've changed the reference to use a specific commit hash of ltchiptool instead of branch name, that could also help. You also have to use a commit hash in the framework.source directive, because it pulls only when the URL changes:
rtl87xx:
  board: generic-rtl8720cf-2mb-992k
  framework:
    version: 0.0.0
    source: https://github.com/prokoma/libretiny#4ae3fcfab729ccacf271988a8e986cf824a49c4f

@prokoma restarting the ESPHome Container in HA has helped as this cleared all the files. (Using "Clean Build Files" didn't help). I was able to compile the .uf2 and it's working on my P100. Thank you for your help and work in getting the RTL8720CF and Tapo P100 working with ESPHome.

@prokoma  I've gotten so far but I can't get a successful write. TPLink KP400 with RTL8710CF. I took the firmware dump, compiled a firmware, and trying to write back to the chip. I can get it to write up to about 5-10%, and then it fails.
E: send error: expected ACK; got b'\x15' for block 50
Sometimes it gets to 50, sometimes 25, sometimes 130. But I can't get a successful write. I tried writing back the original firmware dump as well but that's doing the same thing. Any suggestions? I'm using an FTDI 3.3V Uart cable, powering the chip with an independent 3.3V supply, pulling the gpio0 to 3.3V on power up to enable write mode, not sure what else to try.

LMK, I can share my yaml, or uf2 file, or the commands I'm using, or the log output of the ltchiptool command

@prokoma The error you're having is a more low level one. I'd double check the power situation and connections. Check that the relay coils are not getting power (that could drop the voltage a fair amount) and that your 3.3V supply is outputting the correct voltage.
Also don't use overly long wires for the connections and if you're using Chinese Dupont wires, check the connection between the wire and the connector, sometimes the wire is rotten at the ends and that causes high resistance.

I have a Xiaomi smart humidifier. The product uses an mhcwb4p-b chip and has a core of RTL8720CN.
I tried and failed to upload espome to this product. I'm not a programmer, so I leave it for recording.
esphome yaml

external_components:
  source: github://dhewg/esphome-miot@main

miot:
  id: miot_main

uart:
  - rx_pin: GPIO13
    tx_pin: GPIO14
    baud_rate: 115200

button:
  - platform: restart
    name: "${name} Restart"
    entity_category: diagnostic

binary_sensor:
  - platform: status
    name: "${name} Connection Status"
  - platform: "miot"
    miot_siid: 5
    miot_piid: 1
    name: "${name} Alarm"

text_sensor:
  - platform: version
    name: "${name} Esphome Version"
  - platform: wifi_info
    ip_address:
      name: ESP IP Address
    mac_address:
      name: ESP Mac Wifi Address

  - platform: "miot"
    miot_siid: 2
    miot_piid: 2
    name: "${name} Device Fault"
    icon: mdi:fan-alert
    entity_category: diagnostic
    filters:
      - map:
        - "0 -> No Faults"
        - "1 -> Insufficient Water"
        - "2 -> Water Separation"
  - platform: "miot"
    miot_siid: 2
    miot_piid: 2
    name: "${name} Device Status"
    entity_category: diagnostic
    filters:
      - map:
        - "0 -> Idle"
        - "1 -> Busy"

sensor:
  - platform: wifi_signal # Reports the WiFi signal strength/RSSI in dB
    name: "WiFi Signal dB"
    id: wifi_signal_db
    internal: true
    entity_category: "diagnostic"

  - platform: copy # Reports the WiFi signal strength in %
    source_id: wifi_signal_db
    name: "${name} WiFi Signal Percent"
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    unit_of_measurement: "Signal %"
    entity_category: "diagnostic"
    device_class: ""
    icon: mdi:wifi

  - platform: "miot"
    miot_siid: 3
    miot_piid: 1
    name: "${name} Humidity"
    unit_of_measurement: "%"
    device_class: humidity
    state_class: measurement

  - platform: "miot"
    miot_siid: 3
    miot_piid: 2
    name: "${name} Temperature"
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1

switch:
  - platform: "miot"
    miot_siid: 2
    miot_piid: 1
    name: "${name} Power"
    id: power_sw
    internal: true
    icon: mdi:power

select:
  - platform: "miot"
    id: mode_select
    miot_siid: 2
    miot_piid: 8
    name: "${name} Mode"
    icon: mdi:auto-mode
    internal: true
    options:
      0: "None"
      1: "Constant Humidity"

number:
  - platform: "miot"
    miot_siid: 2
    miot_piid: 5
    id: fan_level
    name: "${name} Favorite Fan Level"
    device_class: WIND_SPEED
    icon: mdi:fan
    mode: slider
    min_value: 0
    max_value: 3
    step: 1
    internal: true

  - platform: "miot"
    miot_siid: 2
    miot_piid: 5
    id: target_hum
    name: "${name} Target Humidity"
    unit_of_measurement: "%"
    device_class: humidity
    icon: mdi:fan
    mode: slider
    min_value: 40
    max_value: 70
    step: 1
    internal: true

When you upload espome firmware, it pops up in the debug log like this.
== Rtl8710c IoT Platform ==
Chip VID: 5, Ver: 1
ROM Version: v2.1
[BOOT Err]Parttiton Table Header(Plain Text) Verification Err!
StartUp@0x0: Invalid RAM Img Signature!

So I did a firmware analysis.
 Hope it helps someone walking down the same path.

@plplaaa2 If it has RTL8720CN, my fork should work. The chip has no permanent security, if you can flash it via UART, it should work. But you'll probably lose updates for the second IO chip, if the miot custom components can't flash it.
You need to use my fork of ltchiptool for flashing, see https://github.com/libretiny-eu/libretiny/issues/44#issuecomment-2514974466.
Then you put this in your ESPHome config:
rtl87xx:
  board: generic-rtl8720cf-2mb-992k
  framework:
    version: 0.0.0
    source: https://github.com/prokoma/libretiny#55aacc8

If you have issues, please share the entire ESPHome config with secrets removed.

@plplaaa2 If it has RTL8720CN, my fork should work. The chip has no permanent security, if you can flash it via UART, it should work. But you'll probably lose updates for the second IO chip, if the miot custom components can't flash it.
You need to use my fork of ltchiptool for flashing, see #44 (comment).
Then you put this in your ESPHome config:
rtl87xx:
  board: generic-rtl8720cf-2mb-992k
  framework:
    version: 0.0.0
    source: https://github.com/prokoma/libretiny#55aacc8

If you have issues, please share the entire ESPHome config with secrets removed.

I've already used your config, but I haven't tried the ltchiptool as a fork version.
I've already reassembled the device, so I'll try it next time I have time. Thank you.
substitutions:
  name: smart-humidifier-2
  board: generic-rtl8720cf-2mb-992k
  device_description: Smart Humidifier 2

esphome:
  name: ${name}
  comment: ${device_description}
  project:
    name: "dhewg.esphome-miot"
    version: "deerma.humidifier.jsq2g"

rtl87xx:
  board: ${board}
  framework:
    version: 0.0.0
    source: https://github.com/prokoma/libretiny#55aacc8

# Enable logging
logger:
  level: DEBUG
  #baud_rate: 0

# Enable Home Assistant API
api:
  encryption:
    key: !secret api_key
  reboot_timeout: 0s
  services:
    - service: mcu_command
      variables:
        command: string
      then:
        - lambda: 'id(miot_main).queue_command(command);'
ota:
  - platform: esphome
    password: !secret hotspot_pw

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  #power_save_mode: HIGH
  #fast_connect: True
  #output_power: 8.5dB     # ESP32 C3
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: $name
    password: !secret hotspot_pw

captive_portal:

@plplaaa2 Ok, that explains it. In the official ltchiptool, the first 512 bytes of the flash are skipped and that causes the signature error.

@prokoma Thanks for your work!  I managed to flash ESPHome to a Tapo L900 Led strip, still have to adjust few things but is working now.
https://github.com/CladZo91/esphome-devices/blob/main/src/docs/devices/Tapo-L900-5EU/index.md


Check support for bee v1.7.0

So I checked the whole setup from ultra-light mode to light mode and also dev mode. All works with bee-dashboard.


Expose Thanos HTTP APIs to OpenAPI/protobuf Proposal

Signed-off-by: Hangzhi<EMAIL_ADDRESS>

Related to : #4102

[ ] I added CHANGELOG entry for this change.
[x] Change is not relevant to the end user.

Changes

Verification

@Hangzhi make check-docs to see what is causing CI to fail.

Hello @ianbillett. The test shows that the file is not formatted, but it's not clear how not formatted. And it results in errors in the e2e test, though this PR should not involve the e2e test 🤔 . Do you have any hints on how I can resolve these errors?

@Hangzhi
Since you are not modifying the e2e tests we can safely conclude that failed due to a transient flake. You can trigger a re-test with an empty commit git commit --allow-empty -m 'retest'.
If you inspect the output of the failing test it shows you why the linter is failing. If you inspect the makefile that is running the tests, you will find the binary we run (mdox) which you can run locally to fix the issues. The command will be something like mdox fmt -l --links.validate.config-file=./.mdox.validate.yaml docs/proposals/20201019-prometheus-rules-in-observatorium-api.md

@ianbillett  Thank you for your very helpful information! I finally got the error info in detail with  mdox fmt -l docs/proposals-accepted/202107-protobuf-openapi-httpapi.md.


add curl command to get the tag_dir in release guide document

we should make diff more detail in release guide, add following section before check source content.

compare release source with github tag
curl -Lo tag-${RELEASE.VERSION}.zip https://github.com/apache/incubator-shardingsphere/archive/${RELEASE.VERSION}.zip | unzip
unzip apache-shardingsphere-incubating-${RELEASE.VERSION}-src.zip
diff -r apache-shardingsphere-incubating-${RELEASE.VERSION}-src tag-${RELEASE.VERSION}

task lists is here

[ ] add curl command in release.cn
[ ] add curl command in release.en

I'd like to finish two tasks of this issue.


chore: release main

:robot: I have created a release beep boop
renderer: 1.0.9
1.0.9 (2023-12-23)
Bug Fixes

update exports (d78f934)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/pavophilip/react-shader-fiber/releases/tag/renderer-v1.0.9 :sunflower:


Request: Mobile applications with NativeScript + Vue

Building cross platform native mobile applications using NativeScript + Vue = NativeVue.

Confirming myself for this

Meetup#7


Fix wrapper generated by docker_unix provider

Wrapper script generated by docker_unix provider does not contain shebang for the shell. Some shells may fail to execute the script. For example fish is affected.
Add shebang for /bin/sh to make the wrapper script more portable.

+1. Thx for the contribution!


egraphs: Avoid producing iconst.i128 nodes

👋 Hey,
This PR fixes an issue with an egraphs rule, where it could accidentally transform a icmp and produce a iconst.i128 along the way. The fix here is to disable this rule for i128.
Fixes #7229

it looks like wasi-nn CI is failing -- @abrown can you take a look?

Ah I don't think this is wasi-nn related, I think it's https://www.cloudflarestatus.com/incidents/l6x2h1zp69bc


Upcoming change: Wifi firmware removal

As part of https://github.com/coreos/fedora-coreos-tracker/issues/1575, we are planning to remove the remaining wireless card firmwares from the Fedora CoreOS image.
To make sure to keep all those firmware in the ucore images, you will likely want to pre-emptively list them here.
You might also want to include NetworkManager-wifi for full wifi support.
And update the doc: https://github.com/ublue-os/ucore#ucore-1
For the full list, see: https://github.com/coreos/fedora-coreos-config/pull/2938
See also: https://github.com/coreos/fedora-coreos-tracker/issues/862

You might also want to add iwd (https://iwd.wiki.kernel.org/, https://wiki.archlinux.org/title/iwd) which is more stable than wpa_supplicant in my experience.

@travier thank you for the issue and the PRs! I appreciate the support from you and the CoreOS team!
I saw you updated #139 so let me know when you think that list is stable and I can proceed with merging.
It seems the outcome of this will be a responsibility for ucore to track changes of the wifi firmware names in Fedora, but that seems reasonable.
Regarding NetworkManager-wifi and iwd ... I have not used on iwd on Fedora yet, but thanks for the tip. I'll do some testing with that, but we may as well add it with NetworkManager-wifi when the time comes.

Small update on iwd testing... I've been using on my custom Silverblue images the past couple days and while it has been positive, I wasn't having issues before either, so I'm not sure what to think.
One thing I did notice, I had to forget/rejoin NetworkManager saved wifi networks.  I first tried modifying the the foo.connection files to remove the specified wifi device since that changed from predictable naming (eg, wlp8s0) to wlan0, of course restarting NetworkManager after doing so. But this wasn't enough, the network would not join.  I still had to forget/join the network again. I think this is likely due to iwd storing credentials in /var/lib/iwd even when used as a backend for NetworkManager-wifi.
TL;DR
If iwd is truly better, I wish Fedora upstream would default to it.
As is, I'd be hesitant to change to it for ublue desktops given users would probably have a frustrating transition without very clearly setting expectations.
If we want to use iwd by default in ucore we should probably do so from day one, to avoid the frustrating transition problem in ucore.

I saw you updated #139 so let me know when you think that list is stable and I can proceed with merging.

This list should be accurate right now.

It seems the outcome of this will be a responsibility for ucore to track changes of the wifi firmware names in Fedora, but that seems reasonable.

Yes, this is an unfortunate consequence of the firmware package split. Hopefully this does not happen too often.

TL;DR If iwd is truly better, I wish Fedora upstream would default to it. As is, I'd be hesitant to change to it for ublue desktops given users would probably have a frustrating transition without very clearly setting expectations. If we want to use iwd by default in ucore we should probably do so from day one, to avoid the frustrating transition problem in ucore.

Agree that doing the work upstream is better.


Implement HTTP Azure Function rule target resource

┆Issue is synchronized with this Jira Task by Unito

Done in #117


Add ZonedDateTime

@alexander-yevsyukov at SpineEventEngine/base#22:
We need to have a value object for ZonedDateTime counterpart from Java 8.

Addressed in PR #28.


Hello!

Excuse me, how can i change my displayName?

If you navigate to your profile page (login and click the little person outline labeled "me") you can edit your profile there.

I can edit only my fullName, but displayName can't.

The display name is set when you sign up and accept the invite, I don't think that it is changeable. If you want a different name I'd suggest sending yourself an invite to another email address, creating a new account, and then deleting this one to free up the username for someone else.

Thank you!


Update active-directory-b2c-reference-trustframeworks-defined-ief-cus…

…tom.md

@NickFadz : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Thanks. Correction confirmed.


App Service RP: Microsoft.Web/hostingEnvironments says that workerPools property is required but it isn't

In the Microsoft.Web/hostingEnvironments (API version 2020-06-01), the workerPools array property is marked as required. However, this does not appear to actually be required, and it's fine to deploy a hostingEnvironment without specifying that property.
Please consider updating the spec to no longer state that workerPools is a mandatory property.

It looks like this has been resolved in API version 2021-02-01.


question: chaining computed values

Say that we have an input for Scaffold.name to be bob dole
I am looking for the computed value: BOB_DOLE
My experimentation shows me that I cannot

compose sprig transforms so that {{ upper snakecase .Scaffold.name }}
chain computed values so that {{ upper .Computed.snaked }}

Do you have any advice on how to accomplish this?

lol answering my own questions:
https://github.com/Masterminds/sprig?tab=readme-ov-file#calling-the-functions-inside-of-templates


New IDs on Z/K statefulsets

A mistake on an automated build has overwritten our images. I recovered from a working  Kubeless version and tried to upload again, but the sha256 are not reproducible again, so we need to update those sha256 IDs to the new ones.
In order to check the correctness of the solution, I've tested some examples on the kubeless/functions repo.  Also, I've tested with this commands, and it worked too:
snipet="kubectl run  -i --rm client$RANDOM --quiet=true  --image=bitnami/kafka:<IP_ADDRESS>   --restart=Never --"

echo "Creating bitnami topic"
$snipet /opt/bitnami/kafka/bin/kafka-topics.sh --create  --zookeeper zookeeper.kubeless:2181  --topic bitnami --replication-factor 1  --partitions 1 --if-not-exists

echo "Listing topics"
$snipet  /opt/bitnami/kafka/bin/kafka-topics.sh --list  --zookeeper zookeeper.kubeless:2181

echo "Describing topic bitnami"
$snipet  /opt/bitnami/kafka/bin/kafka-topics.sh --describe --zookeeper zookeeper.kubeless:2181 --topic bitnami

echo "Producing events"
$snipet /opt/bitnami/kafka/bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic bitnami --num-records 500 --record-size 5 --throughput -1 --producer-props acks=1 bootstrap.servers=kafka.kubeless:9092 buffer.memory=104857600 batch.size=10

Lgtm. I think we should merge it for new users experiencing master branch and the next release. The existing users should be warned to use the latest, otherwise their z/k setup will be crashed. Merging.

@jbianquetti-nami can you monitor this closely, to make sure that the zk and kafka auto-builds do not overwrite existing tags.


test-branch/execute-job/wrong-commit-sha-on-pr/bf6da89a-4c24-4252-a7fc-f5e4fd3baf66

PR for testing f48bf2c6b50f4402bb61aec99221a2f22995dae0

/canonical/self-hosted-runners/run-workflows 931ad21dd9ace68aaa0a7d341e94de96ad93fa6b


command line arguments should support --version

For now, pd only supports -v for printing version.
Among linux command line tools, -v often means verbose, -V/--version is used for version.

in consistent with tidb/tikv,  pd should support both -v and --version for a version tag.


Start user shells in proper PAM sessions

Is your feature request related to a problem? Please describe.
In NixOS, we rely on PAM to set up some important environment variables, including some related to locales, via pam_env.so. Right now WSL starts a single non-interactive shell with login -f to trigger the user systemd instance, but all the interactive shells are spawned bypassing PAM, and therefore not importing the environment variables.
Describe the solution you'd like
WSL starts every interactive shell instance via login or a similar mechanism that runs PAM modules.
Describe alternatives you've considered
Right now we're considering wrapping the user-selected shell in a script that updates the environment manually, but this will not be correct if any other PAM modules are involved.
Additional context
The specific issue that led me to notice this was zsh failing to discover locales when spawned through WSL, as we require the LOCALE_ARCHIVE environment variable to be set for locale archives to be discovered.

Also an #8842 variant, I believe.

Right now WSL starts a single non-interactive shell with login -f to trigger the user systemd instance,

Huh. Is that what that's supposed to do? 'Cause on my system, at least, it doesn't, which is probably another race-condition-on-slower-systems issue similar to the one causing the issue described in the comments here.
I have to rely on systemd-machined / machinectl shell to get a working user systemd session and its appurtenances.

I have had success working around the wsl pam_env and systemctl --user commands issue by changing the wsl startup command parameters to launch a shell through sudo i.e.
wsl -u root sudo -u username zsh

I had a similar issue related to WSL not using PAM. I had issues with Ubuntu 24.04. having a hard and soft limit on open files of 4096, which was too little for my Java app to compile using Maven: Too many open files
I tried raising the limits in /etc/security/limits.conf, but it didn't work and then I found this line in the config file:
#This file sets the resource limits for the users logged in via PAM.
This led me to this issue about WSL not using PAM.
@HarbingerNight your solution worked for me, thx. I changed the command line of my Windows Terminal according to your example and then the file limits got applied correctly in my terminal.


Cannot start VSCode 1.61.1 on Mac Big Sur 11.6

Does this issue occur when all extensions are disabled?: Yes/No
YES

VS Code Version: 1.61.1
c13f1abb110fc756f9b3a6f16670df9cd9d4cf63
x64

OS Version: macOS Big Sur 11.6 (20G165)

Steps to Reproduce:

Start VSCode from the command line or double-click the icon
Done.

VSCode simply hangs with a black screen after starting. Waiting for minutes and minutes results in nothing changing.
The same behavior is shown whether starting with or without extensions enabled, and also with code-insider.
Process chrome_crashpad_handler is claiming 60-70% of CPU and .dmp files are being constantly written to ~/Library/Application Support/Code/Crashpad/pending. You can find one of these files here: https://github.com/mjeffw/vscode-crash/blob/main/a5f200ce-c6c0-4e55-8b3c-a2a38502001f.dmp
I'm dead in the water until we can resolve this issue.
Everything was working the last time I used this laptop. I've installed no new patches or upgrades to the OS, VSCode or extensions.

I just tried reverting to VSCode 1.16.0, and it started up. Definitely something with the newer version.

Thanks for attaching the crash log, looks like the network service is crashing due to bad ipc message. Can you provide the output of code --verbose ?


Add michallaskowski as dev to plugin-usage-plugin

Description
Hi. I am a new maintainer of plugin-usage-plugin and I would like to be able to release a new version (would list all plugins, and their versions).
You can check I have write access to the repo in commits history.
Mentioning @chrissy25 since he was a maintainer before me (two weeks timeout without response on jenkins dev thread and no recent activity)
Here is a thread where I was accepted as a maintainer

Submitter checklist for changing permissions

Always

[x] Add link to plugin/component Git repository in description above

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] All newly added users have logged in to Artifactory at least once

No responses in more than two months after you sent the email, and no activity on GH since 2016.

@michallaskowski Sorry for not replying to your messages and thanks for taking care of the plugin :)

@chrissy25 Thanks for the response!


[feat]:  How to use shadcn date picker for jalali calendar

Feature description
hi guys
I wanted to use jalali date picker but react day picker version 8.10.1 that shadcn use doesn't support it.
However, in new version of react day picker 9.0.4 this future added (experimental) but due to some changes it doesn't word with shadcn right away.
but if you change code inside calendar.tsx to code down below; it works.
function Calendar({
className,
classNames,
showOutsideDays = true,
...props
}: CalendarProps) {
return (
<DayPicker
dir="rtl"
today={new Date()}
locale={faIR}
showOutsideDays={showOutsideDays}
className={cn("p-2 font-IranSans", className)}
classNames={{
hidden: "invisible",
root: "",
outside:
"day-outside text-muted-foreground opacity-50 aria-selected:bg-accent/50 aria-selected:text-muted-foreground aria-selected:opacity-30",
weekdays: "text-muted-foreground",
weekday: "px-1 text-center",
day_button: cn(buttonVariants({ variant: "ghost" }), "h-9 w-9 p-0"),
day: "",
selected:
"bg-secondary rounded-md text-primary-foreground hover:text-primary-foreground ",
today: "bg-primary rounded-md text-accent-foreground",
    month_caption: "font-bold mt-2 mb-3",
    month: "space-y-4",
    button_next: cn(
      buttonVariants({ variant: "outline" }),
      "h-7 w-7 bg-transparent p-0 opacity-50 hover:opacity-100",
    ),
    button_previous: cn(
      buttonVariants({ variant: "outline" }),
      "h-7 w-7 bg-transparent p-0 opacity-50 hover:opacity-100",
    ),
    nav: "flex flex-row-reverse gap-x-1 absolute left-0.5 top-1 fill-foreground",
  }}
  components={{
    Chevron: ({ orientation }) => {
      if (orientation === "left") {
        return <ChevronLeft />;
      } else {
        return <ChevronRight />;
      }
    },
  }}
  {...props}
/>

);
}
and remember to add css file at top
import "react-day-picker/style.css";
Affected component/components
calendar.tsx
Additional Context
Additional details here...
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

Simular issue: https://github.com/shadcn-ui/ui/issues/4518

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.


Vim-like key bindings

Have anyone tried adding Vim-like key bindings to yakyak? I'd be very much interested in getting my hands on such a modification, even if it's barebones - this would up the effeciency a lot in conjunction with tiling window managers and a general keyboard-centric approach.

nobody tried :)

I love vim-mode ANYTHING. I just discovered this project, let me familiarize myself with it, if it's feasible and able to implement without breaking anything, and I'll think about it :)
I don't always use vim for everything, sometimes I want a GUI (I'm not fond of gVim), so I've been using Sublime_Text for the last couple month, and I love it. Especially, and really, the only reason I even consider it viable, VIM MODE! Using Firefox? Vimperator. And on Chromium I use Vimium. The way I see it, I already learned to control an interface with vim-like keybindings, why not use them everywhere text plays a front and center role?!
Sorry unrelated for the aside, especially since I'm brand-spanking new to the community, but if it's possible, I would love to make it happen. Again, let me look at the code first before I commit to such a thing.
If there are specific features you would like, let me know what you are thinking.

fixed in #54


feat: upgrade to svelte-check v3

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

I think this sort of change to create-svelte should be at least a minor, not patch.

my bad, meant to make it a minor, thanks for catching that


Adding fonts

I know I can include fonts inside SVG but what if I prefer to install the fonts ? How can I do that ?
Do I need to install the fonts on the system ? on chromium ? inside the module ?
Thank you for your help

you can cheat a little and load the fonts like so
<svg>
    <defs>
      <style type="text/css">
      @import url('https://fonts.googleapis.com/css?family=Roboto');
      </style>
    </defs>
</svg>

Just need to be able to point to the font from the svg, you could also install them on the system and access them directly.

Sorry for the super late response, but I feel that this is out of scope for this library. All packages support standard SVG rendering, exactly as it would appear in a Chrome browser. This means that anything that would apply to getting it to work in the browser, also applies here.
If you have any specific issues with a convert-svg-to-* package not using a font that you feel it should be, please raise a separate bug for that and it can be investigated, as that could be something specific to this tool.


Fixed criticality score

Fix criticality score

Why we don’t have criticality in OSV data please check!

Yes, in all files the severityNum is null

Why we don’t have criticality in OSV data please check!

it's a new field in COSV, not in OSV


Change Unnecessary IPAddress Pass-by-value to Read-only Pass-by-reference Arguments

Problem
The IPAddress object is larger than a POD type and tests on godbolt.org show that const IPAddress & is much more code-size efficient than passing by value.
Summary of Changes
This changes unnecessary pass-by-value IPAddress arguments to read-only pass-by-reference arguments.
Fixes #1120

@gerickson I wonder whether we could make the copy constructor of IPAddress explicit to avoid this problem.  Might make a bunch of other things complicated, though, like C++11-style member initializers and functions that return IPAddress by value...

@jelderton @hawk248 @BroderickCarlin @saurabhst ?

@gerickson can you fix the merge conflicts?


fix func name comment problem

This PR is a

[ ] Feature Implementation
[X] Bug Fix
[ ] Documentation

What this PR does / why we need it: fix func name comment problem
Which issue(s) this PR fixes

Fixes #
Please leave this checklist in the PR comment so that maintainers can ensure a good PR.
Merge Checklist:

[ ] New feature

[ ] Tests
[ ] Documentation

[ ] SVCat CLI flag
[ ] Server Flag for config

[ ] Chart changes
[ ] removing a flag by marking deprecated and hiding to avoid
breaking the chart release and existing clients who provide a
flag that will get an error when they try to update

/hold
add this to #2496

/ok-to-test

@shouhong Thanks for the PR.  I'm merging this, in the future it would be best to combine these simple typo fixes into a single larger PR if you would, it will reduce the amount of time folks have to spend reviewing.  Thanks!

/lgtm
/approve

/test pull-service-catalog-xbuild


Thread 1.2 non-CCM OTBR must report 2 bytes of operational dataset security policy flags

Describe the bug In Thread 1.2 non-CCM case OT BR reports security policy flags as defined by Thread 1.1 specification.
To Reproduce Information to reproduce the behavior, including:

OT BR commit: 3d6ce344a73f58d8dcec2caefa07c205f1484a01
openthread module commit: e49d20ff02aa85a11f3a15d34a7a389516b79472
IEEE 802.15.4 hardware platform: nRF52840 dongle
Build steps:
OTBR: with environment variables NETWORK_MANAGER=0 BACKBONE_ROUTER=1
nRF52840 FW: USB=1 BOOTLOADER=1 THREAD_VERSION=1.2
Network topology: 1 OT BR, network formation just finished. Commissioner application able to detect and petition.

Expected behavior.
On commissioner command opdataset get active OT BR is to provide MGMT_ACTIVE_GET.rsp with 2 bytes of security policy flags (as defined in the Thread 1.2 specification pt. <IP_ADDRESS> Security Policy TLV (12)).
Output of the ot-ctl dataset active command is to be changed correspondingly.
Console/log output If applicable, add console/log output to help explain your problem.

Check on the OT BR side: in the shell issue ot-ctl dataset active command. The output will be:

$ sudo ot-ctl dataset active
...
Security Policy: 672, onrcb
Done

As per Thread 1.1 specification operational dataset security policy has 1 byte of flags with 5 flag bits. These flags symbolically shown inthe Security Policy line after the comma.

Check on the commissioner side:

> start fd01:1234:5678:0:ee08:fec4:de7f:625d 49191
[done]
> opdataset get active
{
...
    "SecurityPolicy": {
        "Flags": "ff",
        "RotationTime": 672
    }
}
[done]

Flags field is 1 byte long (as per Thread 1.1 specification).
Additional context Add any other context about the problem here.

Yes, it needs to be 2 bytes of flags.  I did not build this OT BR yet so cannot comment if the build steps / commands are okay or not.

Resolved by https://github.com/openthread/openthread/pull/6320


Bug in DatetimeIndex.locAtDateTime?

The comment says that if the datetime doesn't exist in the index, it returns a location of -1. However all the implementation does (in the irregular index) is call java.util.Arrays.binarySearch(), which returns, according to the documentation:
"This method returns index of the search key, if it is contained in the array, else it returns (-(insertion point) - 1). The insertion point is the point at which the key would be inserted into the array: the index of the first element greater than the key, or a.length if all elements in the array are less than the specified key."
Therefore it seems to actually be returning negative numbers, but potentially other than -1.
It's an easy fix, and I've fixed it locally, I just want to confirm that I'm not hallucinating before proceeding with this.

http://www.tutorialspoint.com/java/util/arrays_binarysearch_int.htm

I've encountered that too

Ok, as soon as my other pull request is merged, I'll submit my fix for this, along with a regression test I made for it.

Yup, this looks like an issue.  My bad.


Misleading error dialogs when opening "broken" project (importing from older version)

Godot version
v4.0.alpha12.official [2c11e6d9e]
System information
Xubuntu 22.04
Issue description
This is more of a note that some processes could be improved, rather than a bug report. This particular problem with fonts is related to the G4 alpha 11 - alpha 12 transition and shouldn't happen after the feature freeze, but I think in general Godot could be better at helping the user fix broken projects.
I have a project which I created in an earlier G4 alpha that I opened in a12. Due to font resource refactoring there were some errors, but IMHO the dialogs were misleading and didn't help me fix it as fast as it should have.
First issue, "load failed due to missing dependencies"
The project structure is basically:

Arena.tscn
1.1 Player.tscn
1.1.1 Shoot.tscn

Where Shoot.tscn uses some font resources to display remaining ammunition. Eventually I figured out that what I needed to do was to locate the font files in the FileSystem browser and reimport them. However Godot only told me that Arena.tscn had missing dependencies, and I was presented with a dialog to fix them. I found this quite confusing, because it certainly looked like all dependencies were there. I clicked "open anyway" and then it told me that Player.tscn had missing dependencies, and asked me to fix them.. Only when I got to Shoot.tscn it finally told me that the font resource was the broken dependency.
Suggestion: Would it be possible to display errors in a bottom up fashion instead? I.e. immediately when it detects that Shoot.tscn is broken due to dependencies it would complain about that, instead of propagating to the parent which also breaks due to failing to load the child scene?
Second issue, missing source for error message
After reimporting the font files, the follow error is printed to the log:

Class 'Font' or its base class cannot be instantiated.

But I have no idea what the source of the error is, so I don't know what I need to do to fix it. Is it a script? Is it something in the scene? Is it something engine internal?
Steps to reproduce

Create root scene (using G4a11)
Create child scene
Create label3d in child scene, using a .ttf font in res://
Exit G4a11
Open the project in G4a12

Minimal reproduction project
FontTest.zip

Hi.
I had similar issues. Regarding:
Class 'Font' or its base class cannot be instantiated.
I had to add the font in the Inspector again, in Theme Overrides.

@advlpr thanks! I figured it out eventually, but it would be very nice if the error message had some reference to the exact thing that was causing it. Perhaps even if you could click the error and it would open up the node that caused it in the inspector, though I guess that might be difficult to implement.

Hi. I had similar issues. Regarding:
Class 'Font' or its base class cannot be instantiated.
I had to add the font in the Inspector again, in Theme Overrides.

This happens with the Godot Demo project "Dodge the Creeps" upon loading it.
https://github.com/godotengine/godot-demo-projects/tree/master/2d/dodge_the_creeps
The error is more immediate in 4.3, but the result is the same in 4.2 and 4.3


Update deprecated kubeadm flag delete-local-data

This is a Bug Report

Problem:
https://github.com/kubernetes/website/blob/main/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md#remove-the-node
kubectl drain <node name> --delete-local-data --force --ignore-daemonsets

Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data.
I don’t know if it’s a good time to update this flag . If so, I can help update it.
Proposed Solution:
Update to
kubectl drain <node name> --delete-emptydir-data  --force --ignore-daemonsets

Page to Update:
https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#tear-down
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#remove-the-node
https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#ノードの削除
https://kubernetes.io/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#tear-down
https://kubernetes.io/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#menghapus-node

/sig cluster-lifecycle

cc @neolit123

Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data.
I don’t know if it’s a good time to update this flag . If so, I can help update it.

i see the discussion / PR here:
https://github.com/kubernetes/kubernetes/issues/80228
https://github.com/kubernetes/kubernetes/pull/95076
using --delete-emptydir-data in the kubeadm docs makes sense.
/triage accepted
/help

/assign


Cfkawa patch 1

Created function to load data for LSTM. Splits data into test and train
Purpose
Created function to load data for LSTM
Type of change
New Feature (LSTM function)
What types of change is it?
Select the appropriate type(s) that describe this PR

Bugfix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (non-backwards-compatible fix or feature)
Code style update (formatting, renaming)
Refactoring (no functional changes, no API changes)
Repository chores (changes made to improve repository/workflow quality)
Documentation update
Other (please describe)

Checklist
Put an x in the boxes that apply.

[x ] My code functions as intended
[x ] I have used camelCase in my variable and function names
[] I have commented my code properly
[ ] I have provided the necessary prompts for automatic documentation
[ ] I have provided a toy case under the examples folder
[ ] I have addressed all the issues entirely

Run pre-commit. See README.md for instructions

Please use sensible names for PR. Cfkawa patch 1 may make sense to you but is not informative to the rest. Naming is important for debugging purpose.

Please refer to the guidelines in formats directory for commit message style.


small improvements

Sorry, I haven't been too active lately. Been busy with schoolwork.
I didn't know about zig run, that's nice. When I work on this, I have a server jar somewhere else and I'd just copy the blocks.json into it, but this is probably better since the project might need more than just the blocks.json. This looks fine so I'll merge.


Added Certificate issuance with Lets Encrypt

Updated the docs with a new section in the tutorial to describe setting up 'Certificate issuance with Lets Encrypt'

 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.:x: khowling sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

This is really cool @khowling  💯 !!
@draychev  @akshaysngupta could you PTAL !!

@khowling Amazing! Thanks a lot for your contribution!
Can you please apply these minor fixes?


operationMode and operationStatus not always retrieved at device discovery?

My instance just discovered my living room air conditioner, and while it successfully grabbed a number of properties from the device, it appears to have not received the operationMode and operationStatus from the device at discovery. I can request the status via the REST API, but this doesn't appear to propagate back through to MQTT.
The end result is that my home assistant air conditioner controls remain in the "off" state even though the air conditioner is running, and echonetlite2mqtt is able to manually fetch the status.
It seems like two issues:

making a manual request via REST doesn't end up updating MQTT
not all properties are successfully fetched at device discovery

I have the property interval set to 400, as I wanted to be sure that I'm not flooding devices with requests. Is there a chance this could be resolved by updating to the latest echonetlite node library?
echonetlite2mqtt_logs_internalsStatus.zip

@aftertommy
My guess is that the property was not acquired due to the slow response from the air conditioner.
You should use echonetIntervalToGetProperties.
To fix this problem I have to rebuild the communication process.
But I haven't implemented it yet.
The latest source code has updated the ECHONET Lite library, so the problem may be fixed.
But I still have a bug, so I can't release it.

Man i wish you had a paypal or something so i give show you my thanks.

I am happy that this product is helping you.
But solving the underlying problem takes time.
I plan to implement #12, which still has bugs, first.

I believe this is working with the latest update.


Fix the onboarding

Fixed it!
Note for later: commit as often as possible and don't merge your master into your new branches...


Pin git dependencies to crates release versions

This PR removes the git dependency on wasmcloud-control-interface, as well as bumping the patch version for wasmbus-rpc.

LGTM except for the test suite failing

@autodidaddict looks like we didn't commit the control interface 0.4.2 correctly, fixed in https://github.com/wasmCloud/control-interface/pull/11


Jobs should allow to set branch

Feature description 💡
When creating a new Job for a workspace, apart from templateReference and the workspace ID, it would be so useful to be able to set also the VCS branch to run the job on. This will allow PR speculative plans (and many other possibilities, I believe) to ensure the code that will ―eventually― end up in master branch, is working properly.
This branch provided to the Job must only be used for that job. I mean, the default branch configured for the workspace must not be changed. This will allow several runs (plans) on different branches in parallel, while still allowing the default branch to be planned and applied. This implies that applies must only run on the default branch, and also that if a different branch is provided, apply should not be an option (or the other way round: branch can only be provided if plan only).
This must be implemented for both UI and API
Anything else?
I believe the API docs for the jobs endpoint is not properly documented (at least the POST method) regarding the body attributes. As an example, templateReference is only mentioned at the top-level example.

For speculative plan at least when using github and using the workspace webhook you can define the branch name using a regex expression like ^feat.*,^fix.* (this will trigger any branch that name starts with feat or fix

The above will trigger a plan for any with feat or fix and when using the main branch you could put "Plan and Apply" like

And you could see the checks in github when creating a PR
There was a discussion about that here
https://terrakubeworkspace.slack.com/archives/C06JW2A4MH9/p1733411772269669

Regarding webhooks:

It's not viable for my case since my TerraKube instance is private, so Github is not able to reach it. That's why I wanted to use the GitHub Actions running on self-hosted runners that are able to reach the TK API.
I noticed one webhook is created per workspace requesting it. This means that for a monorepo you'll have tons of webhooks (one per workspace), which I believe will not properly scale for my use case (more than 400 workspaces and growing).

Regarding the discussion: I don't have access to that Slack workspace. Where could I get an invitation?

Regarding the override branch, it was introduced at #644 and it was already excluded.
To be honest, I don't also fully understand why it was excluded, but I suspect it could be related to
https://github.com/AzBuilder/terrakube/pull/644/files#diff-43af800485a05ebe25524825b180b936831414c0f0754481166f8da7bd3b0aa4R697-R701

Regarding the override branch, it was introduced at #644 and it was already excluded. To be honest, I don't also fully understand why it was excluded, but I suspect it could be related to
https://github.com/AzBuilder/terrakube/blob/fe028bf02566d1be4340e65f42a37af2bcf4e5aa/api/src/main/java/org/terrakube/api/plugin/state/RemoteTfeService.java#L697-L701
(which, again, I honestly don't really understand the logic behind)

To add it to the API we just need to remove the following line
https://github.com/AzBuilder/terrakube/blob/d7c3420f19124b2e54483a751f362fdca4719bd7/api/src/main/java/org/terrakube/api/rs/job/Job.java#L77
remote-content is just a special branch name that is used internally when we setup the URL for the tar.gz file that is used when running the terraform operation for the CLI driven workflow

To add it to the API we just need to remove the following line
https://github.com/AzBuilder/terrakube/blob/d7c3420f19124b2e54483a751f362fdca4719bd7/api/src/main/java/org/terrakube/api/rs/job/Job.java#L77

@alfespa17 PR opened (#1635)

Hi @juan-vg !
If you would like a tip we ran into the same issue at our company where one webhook is created for each workspace. Knowing that a single repo has a limitation of 20 webhooks it is not scalable. To work around this issue we made a homemade lambda that triggers and run speculative plans on correct project when their terraform is modified. We manage the different steps like terraform plan running, terraform plan finished or terraform plan failed etc.. through Github check runs that we update depending on where we are in the execution.


Adding filmbatch field to admin pages and template view

JIRA ticket: https://ackama.atlassian.net/browse/N2-51
This PR is to address latest comments by @joshmcarthur in the above ticket.

Screenshots for reference:


If you do not download an offline cache, the save button in configuration modal is greyed out

https://github.com/OpenFusionProject/OpenFusionClient/blob/d8363b61a629a8f2926cce9e53a279e38ad0d30a/assets/js/server-selector.js#L328
Currently the offline cache location is not created by default, so this validation fails every time until you download a cache.

Fixed by 1eee35b


[docs] Fix error in documentation for brokerClientAuthenticationParameters

Motivation
Fixing an error in the documentation; brokerClientAuthenticationParameters should hold the parameters for the broker not the client. Updated to reflect that.

@zymap can you review this PR from the technical perspective? thanks

@tomiamao Thanks for your contribution. Does this affect only master or other versioned docs?
If latter, could you please help update all affected versions? Thanks

Hi @tomiamao, any progress for the code and doc? Thanks.

Hi @tomiamao, any progress for the code and doc? Thanks.


Read an account from the service

feature: Read an account from the service
scenario: user wants to Read an account from the service
Given the user has been authenticated
When the user attempts to read an account from the service
Then the user should have the ability to read the account in the service


linux/mac file existence checks all wrong for bash

Our checks for existence of files or directories in bash are always like this:
if [ ! -d $SOFTWARE_PATH ]; then

The variable has to be quoted otherwise this check is wrong. If the variable is undefined, the if will not evaluate to true.
This is also the reason why #12 did not cause an abortion of the workspace setup even though the variable was not defined.

Done.


Add CCI task to wait for custom setting value

Critical Changes
Changes

Add tasks.apex.custom_settings.CustomSettingValueWait task to wait for custom setting value

Issues Closed

Thanks @prescod. Change made.

@davisagli and @prescod Are there other changes I should make to this or do you think it's good as is?

Thanks @davisagli. Requested changes made.

@force2b I just added a commit with a few tweaks:

Moved the module from cumulusci/tasks/apex/custom_settings.py to cumulusci/tasks/salesforce/custom_settings_wait.py since there's nothing particularly Apex-y about it.
Only catch simple_salesforce.exceptions.SalesforceError from the query. Other Python exceptions do not necessarily have a content attribute, and it's ok if we let them fall through to the default error reporting.
Fixed a reference to field_value that needed to be self.field_value. This one was caught by the flake8 utility which I would recommend setting up to run automatically for Python files in your IDE.

Thanks @davisagli!


add x86 rpm to repo and dockerfile

before: using 32-bit rpm
after: using 64-bit rpm

tests pass, running accessibility test for the Nessus GUI

Nessus D runs, GUI is available, pulled the branch to local VM.


Rotate Bay

This is a nice feature but once created (IRL) bays are never "moved". I think this is more "nice to have" than necessary in the current state of the plugin.


Restarting Forseti instance should automatically pickup patches

Since patches are only related to bug fixes, we should always make sure by restarting the instance, users are able to get the latest changes instead of having them going through the upgrade process with deployment manager.
e.g.
if user is on 2.0.0 and we released a 2.0.1 patch, by restarting the instance, we should automatically upgrade the version to 2.0.1.

@osandoval011 can you please link to your PR and close this?

#2469


Human logging

As discussed we need more elegant logging. But if we add some context via extra argument for more flexible formatting and user decide to use extended format via basicConfig, then he must pass those extra in every call of logging.
import logging

top = logging.getLogger("top")
top.addHandler(logging.NullHandler())

real = logging.getLogger("top.yoba")

def yoba():

    real.error("FOO", extra={"foo": "bar"})
    logging.error("BAR")

if __name__ == "__main__":

    logging.basicConfig(
        level=logging.DEBUG,
        format="%(asctime)s %(message)s extra['foo'] = %(foo)s",
    )
    yoba()

2015-11-06 07:09:34,871 FOO extra['foo'] = bar
--- Logging error ---
Traceback (most recent call last):
  File "/usr/lib/python3.4/logging/__init__.py", line 978, in emit
    msg = self.format(record)
  File "/usr/lib/python3.4/logging/__init__.py", line 828, in format
    return fmt.format(record)
  File "/usr/lib/python3.4/logging/__init__.py", line 568, in format
    s = self.formatMessage(record)
  File "/usr/lib/python3.4/logging/__init__.py", line 537, in formatMessage
    return self._style.format(record)
  File "/usr/lib/python3.4/logging/__init__.py", line 381, in format
    return self._fmt % record.__dict__
KeyError: 'foo'
Call stack:
  File "./prog.py", line 22, in <module>
  File "./prog.py", line 13, in yoba
Message: 'BAR'
Arguments: ()

The solution looks like this:
import logging

top = logging.getLogger("top")
top.addHandler(logging.NullHandler())

real = logging.getLogger("top.yoba")

def yoba():

    real.error("FOO", extra={"foo": "bar"})
    logging.error("BAR")

if __name__ == "__main__":

    logging.basicConfig(
        level=logging.DEBUG,
        format="%(asctime)s %(message)s [base]",
    )

    top.propagate = False
    h = logging.StreamHandler()
    f = logging.Formatter(fmt="%(asctime)s %(message)s extra['foo'] = %(foo)s")
    h.setFormatter(f)
    top.addHandler(h)
    yoba()

2015-11-06 10:22:49,753 FOO extra['foo'] = bar
2015-11-06 10:22:49,754 BAR [base]

But, is this friendly and simple enough to end user? Of course, he can use basicConfig without configuring extra handler and loose some context.

Also, I've watched requests and aiohttp for logging. And aiohttp can use custom logger, which passed as argument. Probably this is good idea.


synth-fun is parametrized by a term type rather than a nonterminal

Multiple nonterminals may generate terms of the same term type. I believe the intent of, say, (synth-fun max2() E) is to associate max2 with the nonterminal E, rather than the term type E with which it shares a name.
However, the current parser code appears to digest this symbol as a term type instead, situating this as the return type of a function. We appear to have lost information about the nonterminal.
See https://github.com/SemGuS-git/Semgus-Parser/blob/main/ParserLibrary/Commands/SynthFunCommand.cs.

Okay, that makes sense - thank you both for explaining! I will adjust the interpreter code accordingly.


Implement custom TableDataRowBackgroundProvider without re-populate table

Hi, in order to set a selected row I created a custom TableDataRowBackgroundProvider the problem I'm having is that in order for the selected row background to show I have re-populate my table which causes the table to scroll back to the top.
is there a way to implement my custom TableDataRowBackgroundProvider without having to reload my table?
right now I'm doing this
SelectedRowColorProvider selrow= new SelectedRowColorProvider();
tableObras.setDataRowBackgroundProvider(selrow);

inside an addDataClickListener
or
if I have to reload my table how can I scroll back to my selected index?

You can set the SelectedRowColorProvider once to you table (not on click). And on click you set the item.selected and call the TableDataAdapter#notifyDataSetChanged() method.

You can set the SelectedRowColorProvider once to you table (not on click). And on click you set the item.selected and call the TableDataAdapter#notifyDataSetChanged() method.

That worked! many thanks


[linux] App doesn't receive clicks after moving window with startDragging method

App doesn't receive any clicks after moving window with windowManager.startDragging();, and does not happens after dragging window title bar
App resumes receiving clicks if I click once while app isn't receiving them
I confirmed on latest stable and master branch of Flutter and I'm using window_manager v0.1.4
bitsdojo_window also has startDragging method, but this bug didn't happen with it.

Sample code
import 'package:flutter/material.dart';
import 'package:window_manager/window_manager.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: GestureDetector(
        onTap: () => print('Clicked!'), // This won't be called
        child: Scaffold(
          body: Center(
            child: DragToMoveArea(
              child: Container(
                color: Colors.grey,
                padding: EdgeInsets.all(100),
                child: Text('Drag me'),
              ),
            ),
          ),
        ),
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel stable, 2.8.1, on Zorin OS 16 5.13.0-25-generic, locale
    en_US.UTF-8)
    • Flutter version 2.8.1 at /home/user/Flutter/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 77d935af4d (5 weeks ago), 2021-12-16 08:37:33 -0800
    • Engine revision 890a5fca2e
    • Dart version 2.15.1

[✓] Android toolchain - develop for Android devices (Android SDK version
    32.0.0-rc1)
    • Android SDK at /home/user/Android/Sdk
    • Platform android-32, build-tools 32.0.0-rc1
    • Java binary at: /home/user/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.11+0-b60-7590822)
    • All Android licenses accepted.

[✗] Chrome - develop for the web (Cannot find Chrome executable at
    google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✓] Linux toolchain - develop for Linux desktop
    • clang version 10.0.0-4ubuntu1
    • cmake version 3.22.1
    • ninja version 1.8.2
    • pkg-config version 0.29.1

[✓] Android Studio (version 2021.1)
    • Android Studio at /home/user/android-studio
    • Flutter plugin version 63.2.2
    • Dart plugin version 211.7798
    • Java version OpenJDK Runtime Environment (build 11.0.11+0-b60-7590822)

[✓] Connected device (1 available)
    • Linux (desktop) • linux • linux-x64 • Zorin OS 16 5.13.0-25-generic

! Doctor found issues in 1 category.

Please see this example:
https://github.com/leanflutter/window_manager/blob/0ad29c5aab7fd4ec2af3007dd1bff54ec25cd85e/example/lib/pages/home.dart#L543-L565
We also have a DragToMoveArea Widget that you can also use

TL;DR
Don't use onPointerDown/onTapDown for windowManager.startDragging()
Use onPanStart instead

Thank you but I am having problem with startDragging method. So DragToMoveArea widget and onPanStart don't solve my issue
I updated sample code and the problem still happens
I think bitsdojo_window does something after dragging has ended but I have no idea

Please don't wrap DragToMoveArea with GestureDetector
 GestureDetector(
   behavior: HitTestBehavior.translucent,
   onPanStart: (details) {
     windowManager.startDragging();
   },
   onTap: () {
     // do something
   },
   onDoubleTap: () async {
     bool isMaximized = await windowManager.isMaximized();
     if (!isMaximized) {
       windowManager.maximize();
     } else {
       windowManager.unmaximize();
     }
   },
   child: Container(
     margin: EdgeInsets.all(0),
     width: double.infinity,
     height: 54,
     color: Colors.grey.withOpacity(0.3),
     child: Center(
       child: Text('DragToMoveArea'),
     ),
   ),
 ),

Thank you. I tried that but the problem still happens
I think this is a problem with startDragging, so the problem even happens with this code
class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: DragToMoveArea(child: SizedBox()),
    );
  }
}

I should use this for sample all along. I'm sorry.


ThreadChannel#retrieveMembers throwing ParsingException

General Troubleshooting

[x] I have checked for similar issues.
[x] I have updated to the latest JDA version.
[x] I have checked the branches or the maintainers' PRs for upcoming bug fixes.

Bug Report
ThreadChannel#retrieveThreadMembers does not work.
This method depends on the EntityBuilder being able to construct a ThreadMember using the member field in the json payload response, but this is not given. JSON response from Discord:
[
    {
        "id": "930264297064517663",
        "flags": 0,
        "join_timestamp": "2022-01-11T00:58:12+00:00",
        "user_id": "187979032904728576"
    },
    {
        "id": "930264297064517663",
        "flags": 1,
        "join_timestamp": "2022-01-11T03:11:27.366000+00:00",
        "muted": false,
        "mute_config": null,
        "user_id": "381877390219018250"
    }
]

Expected Behavior
ThreadMembers are built using the JSON provided.
Code Example or Reproduction Steps
ThreadChannel#retrieveThreadMembers().queue()

Code for JDABuilder or DefaultShardManagerBuilder Used
N/A
Exception or Error
[JDA RateLimit-Worker 2] ERROR Requester - There was an unexpected error while executing a REST request
net.dv8tion.jda.api.exceptions.ParsingException: Unable to resolve value with key member to type DataObject: null
	at net.dv8tion.jda.api.utils.data.DataObject.valueError(DataObject.java:807)
	at net.dv8tion.jda.api.utils.data.DataObject.lambda$getObject$0(DataObject.java:277)
	at java.base/java.util.Optional.orElseThrow(Optional.java:408)
	at net.dv8tion.jda.api.utils.data.DataObject.getObject(DataObject.java:277)
	at net.dv8tion.jda.internal.entities.EntityBuilder.createThreadMember(EntityBuilder.java:1210)
	at net.dv8tion.jda.internal.entities.ThreadChannelImpl.lambda$retrieveThreadMembers$3(ThreadChannelImpl.java:172)
	at net.dv8tion.jda.internal.requests.RestActionImpl.handleSuccess(RestActionImpl.java:278)
	at net.dv8tion.jda.internal.requests.RestActionImpl.handleResponse(RestActionImpl.java:268)
	at net.dv8tion.jda.api.requests.Request.handleResponse(Request.java:259)
	at net.dv8tion.jda.internal.requests.Requester.execute(Requester.java:237)
	at net.dv8tion.jda.internal.requests.Requester.execute(Requester.java:141)
	at net.dv8tion.jda.internal.requests.Requester.execute(Requester.java:124)
	at net.dv8tion.jda.internal.requests.ratelimit.BotRateLimiter$Bucket.run(BotRateLimiter.java:478)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
[ForkJoinPool.commonPool-worker-19] ERROR RestAction - RestAction queue returned failure: [ErrorResponseException] -1: net.dv8tion.jda.api.exceptions.ParsingException
net.dv8tion.jda.api.exceptions.ParsingException: Unable to resolve value with key member to type DataObject: null
	at net.dv8tion.jda.api.utils.data.DataObject.valueError(DataObject.java:807)
	at net.dv8tion.jda.api.utils.data.DataObject.lambda$getObject$0(DataObject.java:277)
	at java.base/java.util.Optional.orElseThrow(Optional.java:408)
	at net.dv8tion.jda.api.utils.data.DataObject.getObject(DataObject.java:277)
	at net.dv8tion.jda.internal.entities.EntityBuilder.createThreadMember(EntityBuilder.java:1210)
	at net.dv8tion.jda.internal.entities.ThreadChannelImpl.lambda$retrieveThreadMembers$3(ThreadChannelImpl.java:172)
	at net.dv8tion.jda.internal.requests.RestActionImpl.handleSuccess(RestActionImpl.java:278)
	at net.dv8tion.jda.internal.requests.RestActionImpl.handleResponse(RestActionImpl.java:268)
	at net.dv8tion.jda.api.requests.Request.handleResponse(Request.java:259)
	at net.dv8tion.jda.internal.requests.Requester.execute(Requester.java:237)
	at net.dv8tion.jda.internal.requests.Requester.execute(Requester.java:141)
	at net.dv8tion.jda.internal.requests.Requester.execute(Requester.java:124)
	at net.dv8tion.jda.internal.requests.ratelimit.BotRateLimiter$Bucket.run(BotRateLimiter.java:478)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: net.dv8tion.jda.api.exceptions.ContextException
Caused by: net.dv8tion.jda.api.exceptions.ContextException

	at net.dv8tion.jda.api.exceptions.ContextException.here(ContextException.java:54)
	at net.dv8tion.jda.api.requests.Request.<init>(Request.java:71)
	at net.dv8tion.jda.internal.requests.RestActionImpl.queue(RestActionImpl.java:197)
	at net.dv8tion.jda.api.requests.RestAction.queue(RestAction.java:573)
	at net.dv8tion.jda.api.requests.RestAction.queue(RestAction.java:539)
	at net.dv8tion.jda.api.requests.RestAction$queue.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
	at Bot.onMessageReceived(Bot.groovy:45)
	at net.dv8tion.jda.api.hooks.ListenerAdapter.onEvent(ListenerAdapter.java:358)
	at net.dv8tion.jda.api.hooks.InterfacedEventManager.handle(InterfacedEventManager.java:96)
	at net.dv8tion.jda.internal.hooks.EventManagerProxy.handleInternally(EventManagerProxy.java:88)
	at net.dv8tion.jda.internal.hooks.EventManagerProxy.handle(EventManagerProxy.java:70)
	at net.dv8tion.jda.internal.JDAImpl.handleEvent(JDAImpl.java:163)
	at net.dv8tion.jda.internal.handle.MessageCreateHandler.handleInternally(MessageCreateHandler.java:111)
	at net.dv8tion.jda.internal.handle.SocketHandler.handle(SocketHandler.java:36)
	at net.dv8tion.jda.internal.requests.WebSocketClient.onDispatch(WebSocketClient.java:953)
	at net.dv8tion.jda.internal.requests.WebSocketClient.onEvent(WebSocketClient.java:840)
	at net.dv8tion.jda.internal.requests.WebSocketClient.handleEvent(WebSocketClient.java:818)
	at net.dv8tion.jda.internal.requests.WebSocketClient.onBinaryMessage(WebSocketClient.java:992)
	at com.neovisionaries.ws.client.ListenerManager.callOnBinaryMessage(ListenerManager.java:385)
	at com.neovisionaries.ws.client.ReadingThread.callOnBinaryMessage(ReadingThread.java:276)
	at com.neovisionaries.ws.client.ReadingThread.handleBinaryFrame(ReadingThread.java:996)
	at com.neovisionaries.ws.client.ReadingThread.handleFrame(ReadingThread.java:755)
	at com.neovisionaries.ws.client.ReadingThread.main(ReadingThread.java:108)
	at com.neovisionaries.ws.client.ReadingThread.runMain(ReadingThread.java:64)
	at com.neovisionaries.ws.client.WebSocketThread.run(WebSocketThread.java:45)

This likely means that we're going to have to make ThreadMember.getMember() nullable unless we can get Discord to provide this information

Had a lengthy conversation with @ajpalkovic about this issue. The conclusion is that, given bandwidth, Discord will add .member on the ThreadMember entities returned by this endpoint.
Not sure what the timetable for that looks like though

Whats the status on this?

@ajpalkovic has changes in a branch for this iirc. I'll sync with him on it.


ChatGPT needs to be added

What is the vendor's name?
OpenAI/ChatGPT
What is the vendor's pricing site?
https://openai.com/chatgpt/pricing
What is the base pricing? Use the lowest tier that looks sane for a small business customer, not free or personal tiers.
$25/user/month
What is the minimum pricing for SSO support?
Unknown, 150 user minimum required for SSO
Does this pricing info come from a quote or other non-public source?
Are there any caveats we should list in the footnotes?
SSO locked off to Enterprise customers, 150 user minimum

Duplicate of #439 - closing to consolidate.