[zackees]

Bumps the workspace and Python package to 2.5.31.

Why now

FastLED's hardware validation on a Linux bench (ESP32-C6, ESP32-P4, RP2350, LPC845) hit three deploy and serial bugs in 2.5.30, now fixed on main:

• ESP32 native espflash timeout leaks the serial port to the esptool fallback (EBUSY) #1614 / fix(deploy): wait for timed-out native espflash ops to release the port (#1614) #1615: when a native espflash verify or write timed out, its blocking thread kept the serial port open for about 40 s. The esptool fallback then failed with EBUSY ("port is busy"), so every deploy to a device whose verify timed out failed.
• Serial attach resets ESP32 USB-Serial-JTAG chips (DTR cleared before RTS); P4 re-enumerates and the session dies #1617 / fix(serial): clear RTS before DTR at open so attach does not reset ESP chips (#1617) #1619: every serial attach (and fbuild serial probe read) cleared DTR before RTS, passing through the USB-Serial-JTAG "hold in reset" state, so each open rebooted ESP chips. On the ESP32-P4 that re-enumerates USB and kills the session (Broken pipe after ~4 s), so FastLED autoresearch aborted with session closed.
• ESP32 deploy spawns bare esptool instead of the build-provisioned esptool #1616 / fix(deploy): ESP32 deploy spawns the build-resolved esptool #1618: ESP32 deploy spawned a bare esptool from PATH instead of the esptool the build provisions, so fbuild deploy failed with No such file or directory from any shell without a Python venv.

Release-candidate evidence

Binaries built from the #1618 head (main plus #1615, #1619, #1618; identical code to this bump), run through FastLED's FBUILD_EXECUTABLE override:

• Bare-shell deploy: with no esptool on PATH, fbuild <proj> deploy -e esp32c6 used the provisioned esptool 5.1.0 and printed deploy succeeded (full flash). On 2.5.30 it failed to spawn esptool.
• ESP32-C6: bash autoresearch esp32c6 --all passed PARLIO, RMT, SPI and UART (AUTORESEARCH SUCCEEDED).
• ESP32-P4: bash autoresearch esp32p4 --all now gets through pin discovery and runs every test. RMT, SPI and UART pass. PARLIO and LCD_RGB fail on firmware-side issues tracked in ESP32-P4: PARLIO emits nothing and LCD_RGB capture truncates at 256 edges in AutoResearch loopback FastLED#4669. On 2.5.30 the run aborted before any test with session closed.
• P4 open-time reset: four consecutive fbuild serial probe read opens printed no ESP-ROM banner, and ping answered with 850 s uptime. On 2.5.30 every open printed rst:0x17 (CHIP_USB_UART_RESET).

The diff only touches version fields: Cargo.toml, pyproject.toml, 21 workspace entries in Cargo.lock, and uv.lock. No third-party dependency moved.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 26 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: FastLED/fbuild/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 2381ead1-1500-4ad1-a1ab-24d06a415f38

📥 Commits

Reviewing files that changed from the base of the PR and between fcefa66 and bcc758c.

⛔ Files ignored due to path filters (2)

• Cargo.lock is excluded by !**/*.lock
• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• Cargo.toml
• pyproject.toml

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}