moveit: 2.5.4-1 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository moveit to 2.5.4-1:

upstream repository: https://github.com/ros-planning/moveit2.git
release repository: https://github.com/moveit/moveit2-release.git
distro file: humble/distribution.yaml
bloom version: 0.11.2
previous version for package: 2.5.3-1

chomp_motion_planner
* updated comment formatting for correct doxygen generation (#1582 <https://github.com/ros-planning/moveit2/issues/1582>) (#1664 <https://github.com/ros-planning/moveit2/issues/1664>)
  (cherry picked from commit 71e6d903927116a59b9a142ef7b501f4f6cd1022)
  Co-authored-by: Michael Wrock<EMAIL_ADDRESS>* Replace C array with std::array in std::vector template argument (backport #1612 <https://github.com/ros-planning/moveit2/issues/1612>) (#1621 <https://github.com/ros-planning/moveit2/issues/1621>)
  Co-authored-by: Tyler Weaver<EMAIL_ADDRESS>  (cherry picked from commit a8326ace6bb3e7d17191769533b85ec994a1bdd7)
  Co-authored-by: light-tech<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_chomp_optimizer_adapter
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_common
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_configs_utils
* Use MoveItConfigsBuilder in Pilz test launch file (#1571 <https://github.com/ros-planning/moveit2/issues/1571>) (#1662 <https://github.com/ros-planning/moveit2/issues/1662>)
  (cherry picked from commit 5e880bacaad780f511ed99847050216a8b9905c1)
  Co-authored-by: Abishalini Sivaraman<EMAIL_ADDRESS>* Only require Cartesian limits if Pilz is used (#1519 <https://github.com/ros-planning/moveit2/issues/1519>) (#1653 <https://github.com/ros-planning/moveit2/issues/1653>)
  (cherry picked from commit 40f7f091cc77a683f3c0a4af64f6a463dd0846f1)
  Co-authored-by: Stephanie Eng<EMAIL_ADDRESS>* Typo fix (#1518 <https://github.com/ros-planning/moveit2/issues/1518>) (#1650 <https://github.com/ros-planning/moveit2/issues/1650>)
  (cherry picked from commit e89526de24d88fb05eb646a7925de69ba480bfe8)
  Co-authored-by: Stephanie Eng<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_core
* Free functions for calculating properties of trajectories (#1503 <https://github.com/ros-planning/moveit2/issues/1503>) (#1657 <https://github.com/ros-planning/moveit2/issues/1657>)
  (cherry picked from commit 43a22ece72bb5362e6ef7df1d2783b03935aea2e)
* Improve Cartesian interpolation (#1547 <https://github.com/ros-planning/moveit2/issues/1547>) (#1670 <https://github.com/ros-planning/moveit2/issues/1670>)
* added brace intialization (#1615 <https://github.com/ros-planning/moveit2/issues/1615>) (#1667 <https://github.com/ros-planning/moveit2/issues/1667>)
  (cherry picked from commit f1d0ab59228dc04899724add96162eb93f039939)
  Co-authored-by: Abhijeet Das Gupta<EMAIL_ADDRESS>* size_t bijection index type (#1544 <https://github.com/ros-planning/moveit2/issues/1544>) (#1659 <https://github.com/ros-planning/moveit2/issues/1659>)
  (cherry picked from commit af7bd63a084d62de0821bb0e451008f2b1b11954)
* Add planner configurations to CHOMP and PILZ (#1522 <https://github.com/ros-planning/moveit2/issues/1522>) (#1656 <https://github.com/ros-planning/moveit2/issues/1656>)
  (cherry picked from commit 888fc5358280b20edc394947e98341c0f03dc0bd)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Add error_code_to_string function (#1523 <https://github.com/ros-planning/moveit2/issues/1523>) (#1655 <https://github.com/ros-planning/moveit2/issues/1655>)
  (cherry picked from commit 042709ab3ddfd9e33a0533eb1df14536c1cf1ecf)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Use pragma once as header include guard (#1525 <https://github.com/ros-planning/moveit2/issues/1525>) (#1652 <https://github.com/ros-planning/moveit2/issues/1652>)
  (cherry picked from commit 7d758de1b2f2904b8c85520129fa8d48aad93713)
  Co-authored-by: J. Javan<EMAIL_ADDRESS>* Unified code comment style (#1053 <https://github.com/ros-planning/moveit2/issues/1053>) (#1648 <https://github.com/ros-planning/moveit2/issues/1648>)
* Const ptr to jmg arg for cost function (#1537 <https://github.com/ros-planning/moveit2/issues/1537>) (#1610 <https://github.com/ros-planning/moveit2/issues/1610>)
  (cherry picked from commit 389a5a855140450e5051035e42441c4653c302a2)
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Fixed fabs() use in quaternion interpolation (backport #1479 <https://github.com/ros-planning/moveit2/issues/1479>) (#1496 <https://github.com/ros-planning/moveit2/issues/1496>)
* Fixes for using generate_state_database (backport #1412 <https://github.com/ros-planning/moveit2/issues/1412>) (#1493 <https://github.com/ros-planning/moveit2/issues/1493>)
* Fixed fabs() use in quaternion interpolation (#1479 <https://github.com/ros-planning/moveit2/issues/1479>)
* fix path to constraints parameters
  (cherry picked from commit fb0331610a304172c395084d4d981ed173684305)
* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: Alaa, Henning Kayser, werner291

moveit_hybrid_planning
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_kinematics
* Backport to Humble (#1642 <https://github.com/ros-planning/moveit2/issues/1642>)
  Co-authored-by: Robert Haschke<EMAIL_ADDRESS>  Co-authored-by: Michael Görner<EMAIL_ADDRESS>  Co-authored-by: Jochen Sprickerhof<EMAIL_ADDRESS>* Use pragma once as header include guard (#1525 <https://github.com/ros-planning/moveit2/issues/1525>) (#1652 <https://github.com/ros-planning/moveit2/issues/1652>)
  (cherry picked from commit 7d758de1b2f2904b8c85520129fa8d48aad93713)
  Co-authored-by: J. Javan<EMAIL_ADDRESS>* Unified code comment style (#1053 <https://github.com/ros-planning/moveit2/issues/1053>) (#1648 <https://github.com/ros-planning/moveit2/issues/1648>)
  * Changes the comment style from /**/ to //
  Co-authored-by: JafarAbdi<EMAIL_ADDRESS>  Co-authored-by: Henning Kayser<EMAIL_ADDRESS>  (cherry picked from commit 1d67b519e6ef9ca1ebba494743791da998b72950)
  Co-authored-by: Michael Marron<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: Tyler Weaver, mergify[bot]

moveit_planners
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_planners_chomp
* Add planner configurations to CHOMP and PILZ (#1522 <https://github.com/ros-planning/moveit2/issues/1522>) (#1656 <https://github.com/ros-planning/moveit2/issues/1656>)
  (cherry picked from commit 888fc5358280b20edc394947e98341c0f03dc0bd)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_planners_ompl
* simplify_solution per planning context (#1437 <https://github.com/ros-planning/moveit2/issues/1437>) (#1646 <https://github.com/ros-planning/moveit2/issues/1646>)
  (cherry picked from commit 048062cc8749a1e1e224ff99a3bfa12e8c3ae3ba)
  Co-authored-by: Antoine Duplex<EMAIL_ADDRESS>* Convert OMPL status to MoveItErrorCode in the OMPL interface (#1606 <https://github.com/ros-planning/moveit2/issues/1606>) (#1668 <https://github.com/ros-planning/moveit2/issues/1668>)
  (cherry picked from commit baba9b041225ed5518d5235996afb9aa3c5a61f8)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* size_t bijection index type (#1544 <https://github.com/ros-planning/moveit2/issues/1544>) (#1659 <https://github.com/ros-planning/moveit2/issues/1659>)
  (cherry picked from commit af7bd63a084d62de0821bb0e451008f2b1b11954)
* Fix logic with enforcing constrained planning state space in OMPL (backport #1589 <https://github.com/ros-planning/moveit2/issues/1589>) (#1641 <https://github.com/ros-planning/moveit2/issues/1641>)
  (cherry picked from commit 67e08b7999e252971907dab5cf17b789d1336863)
  Co-authored-by: Stephanie Eng<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Fixes for using generate_state_database (backport #1412 <https://github.com/ros-planning/moveit2/issues/1412>) (#1493 <https://github.com/ros-planning/moveit2/issues/1493>)
* correctly initialize rmw_serialized_message_t
  (cherry picked from commit cf714d5407d5100e4587e9ead740c665e5a70507)
* automatically declare parameters from overrides
  (cherry picked from commit b961e9c14d66a6a7abd91490a76ee2bef0fe08dc)
* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: Alaa, Henning Kayser, mergify[bot]

moveit_plugins
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_resources_prbt_ikfast_manipulator_plugin
* Use pragma once as header include guard (#1525 <https://github.com/ros-planning/moveit2/issues/1525>) (#1652 <https://github.com/ros-planning/moveit2/issues/1652>)
  (cherry picked from commit 7d758de1b2f2904b8c85520129fa8d48aad93713)
  Co-authored-by: J. Javan<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_resources_prbt_moveit_config
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_resources_prbt_pg70_support
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_resources_prbt_support
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_ros
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_ros_benchmarks
* Free functions for calculating properties of trajectories (#1503 <https://github.com/ros-planning/moveit2/issues/1503>) (#1657 <https://github.com/ros-planning/moveit2/issues/1657>)
  (cherry picked from commit 43a22ece72bb5362e6ef7df1d2783b03935aea2e)
* Remove unused benchmark_execution.cpp file (#1535 <https://github.com/ros-planning/moveit2/issues/1535>) (#1564 <https://github.com/ros-planning/moveit2/issues/1564>)
  (cherry picked from commit 8a9652ecbb4bc43964b296a0f62e298bfe7c1870)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_ros_control_interface
* Rename MoveItControllerManager. Add deprecation warning (#1601 <https://github.com/ros-planning/moveit2/issues/1601>) (#1666 <https://github.com/ros-planning/moveit2/issues/1666>)
  (cherry picked from commit b050890a2632a723dd95c08542ef6ed57d77fb06)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* Support chained controllers (backport #1482 <https://github.com/ros-planning/moveit2/issues/1482>) (#1623 <https://github.com/ros-planning/moveit2/issues/1623>)
  (cherry picked from commit 3db960a4b3b1e1d25630867a62ea1182bac2e96a)
  Co-authored-by: Paul Gesel<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_ros_move_group
* Removed plan_with_sensing (#1142 <https://github.com/ros-planning/moveit2/issues/1142>) (#1647 <https://github.com/ros-planning/moveit2/issues/1647>)
  (cherry picked from commit ad9fb465776c68d53431ec477ff89d7e4e25f3b3)
  Co-authored-by: Stephanie Eng<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_ros_occupancy_map_monitor
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_ros_perception
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_ros_planning
* Backport to Humble (#1642 <https://github.com/ros-planning/moveit2/issues/1642>)
  Co-authored-by: Robert Haschke<EMAIL_ADDRESS>  Co-authored-by: Michael Görner<EMAIL_ADDRESS>  Co-authored-by: Jochen Sprickerhof<EMAIL_ADDRESS>* Rename MoveItControllerManager. Add deprecation warning (#1601 <https://github.com/ros-planning/moveit2/issues/1601>) (#1666 <https://github.com/ros-planning/moveit2/issues/1666>)
  (cherry picked from commit b050890a2632a723dd95c08542ef6ed57d77fb06)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* Disable flaky test_servo_singularity + test_rdf_integration (#1530 <https://github.com/ros-planning/moveit2/issues/1530>) (#1654 <https://github.com/ros-planning/moveit2/issues/1654>)
  (cherry picked from commit f7655df7a439069565efa0de73c08e9d1dd45dde)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Removed plan_with_sensing (#1142 <https://github.com/ros-planning/moveit2/issues/1142>) (#1647 <https://github.com/ros-planning/moveit2/issues/1647>)
  (cherry picked from commit ad9fb465776c68d53431ec477ff89d7e4e25f3b3)
  Co-authored-by: Stephanie Eng<EMAIL_ADDRESS>* Default destructor for PlanningComponent (#1470 <https://github.com/ros-planning/moveit2/issues/1470>) (#1645 <https://github.com/ros-planning/moveit2/issues/1645>)
  (cherry picked from commit f95e110085d7d5a9ac7b1cfa903d1a885ff519cb)
  Co-authored-by: Tyler Weaver<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: Tyler Weaver, mergify[bot]

moveit_ros_planning_interface
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Changed 'return false' in plan, move and execute such that MoveItErrorCode is returned (#1266 <https://github.com/ros-planning/moveit2/issues/1266>) (#1460 <https://github.com/ros-planning/moveit2/issues/1460>)
* Fix callback execution in MGI (backport #1305 <https://github.com/ros-planning/moveit2/issues/1305>) (#1462 <https://github.com/ros-planning/moveit2/issues/1462>)
  The initial implementation with the private node allowed for concurrent spinning of the same node, producing runtime exceptions. This change removes the need for a private node by letting MGI manage its own CallbackGroup and Executor thread.
  (cherry picked from commit 042186aef33d9af6de4ccb17e79b0eaffdc7febb)
  Co-authored-by: Henning Kayser<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_ros_robot_interaction
* Add moveit_core dependency to robot_interaction (#1617 <https://github.com/ros-planning/moveit2/issues/1617>) (#1618 <https://github.com/ros-planning/moveit2/issues/1618>)
  (cherry picked from commit cc63903a11652eae3829f7e1dcc1d74e73c50839)
  Co-authored-by: Sebastian Castro<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_ros_visualization
* Use pragma once as header include guard (#1525 <https://github.com/ros-planning/moveit2/issues/1525>) (#1652 <https://github.com/ros-planning/moveit2/issues/1652>)
  (cherry picked from commit 7d758de1b2f2904b8c85520129fa8d48aad93713)
  Co-authored-by: J. Javan<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_ros_warehouse
* Restructure moveit warehouse package (#1551 <https://github.com/ros-planning/moveit2/issues/1551>) (#1661 <https://github.com/ros-planning/moveit2/issues/1661>)
  (cherry picked from commit 8fddbda48148204835de23a741ba11f5be1021fa)
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_runtime
* Uncomment moveit_ros_perception dependency (#1463 <https://github.com/ros-planning/moveit2/issues/1463>) (#1644 <https://github.com/ros-planning/moveit2/issues/1644>)
  (cherry picked from commit 450323cee2c74f09952a95ff1cae9951583cdce9)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_servo
* [Servo] Remove the option for "stop distance"-based collision checking (#1574 <https://github.com/ros-planning/moveit2/issues/1574>) (#1663 <https://github.com/ros-planning/moveit2/issues/1663>)
  (cherry picked from commit e96004702bbd338a08340eab0985fd04c74968fa)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* [Servo] Use a WallRate so the clock is monotonically increasing (#1543 <https://github.com/ros-planning/moveit2/issues/1543>) (#1658 <https://github.com/ros-planning/moveit2/issues/1658>)
  (cherry picked from commit c134d89710e831ae58a66e53d87a78b44b0b307c)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* Disable flaky test_servo_singularity + test_rdf_integration (#1530 <https://github.com/ros-planning/moveit2/issues/1530>) (#1654 <https://github.com/ros-planning/moveit2/issues/1654>)
  (cherry picked from commit f7655df7a439069565efa0de73c08e9d1dd45dde)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Enforce singularity threshold when moving away from a singularity (#620 <https://github.com/ros-planning/moveit2/issues/620>) (#1649 <https://github.com/ros-planning/moveit2/issues/1649>)
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

moveit_setup_app_plugins
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_setup_assistant
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_setup_controllers
* MSA: write the default controller namespace (#1515 <https://github.com/ros-planning/moveit2/issues/1515>) (#1651 <https://github.com/ros-planning/moveit2/issues/1651>)
  (cherry picked from commit 066e8621166858d3f556726197b07643a1b685f9)
  Co-authored-by: AndyZe<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_setup_core_plugins
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_setup_framework
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_setup_srdf_plugins
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

moveit_simple_controller_manager
* Support chained controllers (backport #1482 <https://github.com/ros-planning/moveit2/issues/1482>) (#1623 <https://github.com/ros-planning/moveit2/issues/1623>)
  (cherry picked from commit 3db960a4b3b1e1d25630867a62ea1182bac2e96a)
  Co-authored-by: Paul Gesel<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Contributors: mergify[bot]

pilz_industrial_motion_planner
* Backport to Humble (#1642 <https://github.com/ros-planning/moveit2/issues/1642>)
  Co-authored-by: Robert Haschke<EMAIL_ADDRESS>  Co-authored-by: Michael Görner<EMAIL_ADDRESS>  Co-authored-by: Jochen Sprickerhof<EMAIL_ADDRESS>* Use MoveItConfigsBuilder in Pilz test launch file (#1571 <https://github.com/ros-planning/moveit2/issues/1571>) (#1662 <https://github.com/ros-planning/moveit2/issues/1662>)
  (cherry picked from commit 5e880bacaad780f511ed99847050216a8b9905c1)
  Co-authored-by: Abishalini Sivaraman<EMAIL_ADDRESS>* Add planner configurations to CHOMP and PILZ (#1522 <https://github.com/ros-planning/moveit2/issues/1522>) (#1656 <https://github.com/ros-planning/moveit2/issues/1656>)
  (cherry picked from commit 888fc5358280b20edc394947e98341c0f03dc0bd)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Use pragma once as header include guard (#1525 <https://github.com/ros-planning/moveit2/issues/1525>) (#1652 <https://github.com/ros-planning/moveit2/issues/1652>)
  (cherry picked from commit 7d758de1b2f2904b8c85520129fa8d48aad93713)
  Co-authored-by: J. Javan<EMAIL_ADDRESS>* Removed plan_with_sensing (#1142 <https://github.com/ros-planning/moveit2/issues/1142>) (#1647 <https://github.com/ros-planning/moveit2/issues/1647>)
  (cherry picked from commit ad9fb465776c68d53431ec477ff89d7e4e25f3b3)
  Co-authored-by: Stephanie Eng<EMAIL_ADDRESS>* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: Tyler Weaver, mergify[bot]

pilz_industrial_motion_planner_testutils
* Improve CMake usage (#1550 <https://github.com/ros-planning/moveit2/issues/1550>) (#1555 <https://github.com/ros-planning/moveit2/issues/1555>)
  Co-authored-by: Sebastian Jahr<EMAIL_ADDRESS>* Remove __has_include statements (#1481 <https://github.com/ros-planning/moveit2/issues/1481>) (#1483 <https://github.com/ros-planning/moveit2/issues/1483>)
* Contributors: mergify[bot]

Held for sync: https://discourse.ros.org/t/preparing-for-humble-sync-and-patch-release-2022-11-21/28234


[Bug] Chapter download and read stuck

I can't download and read some chapter of a certain novel but that chapter clearly available when I open it using browser. It made me stuck at that chapter and cannot proceed to the next chapters that's why I make the previous issue #26 so hopefully I can continue reading.

_https://wuxiaworld.site/novel/long-live-summons/_

_https://wuxiaworld.site/novel/oukoku-e-tsuzuku-michi/_

Is it working in the stream read? (I dont know if my parser stopped or if the chapter contains some invalid html)

Stream read isn't working too, it just show error loading chapter and keep loading.

This bug seems to be the same with issue #25 because I also met some novel that I can't open. Although the site is different but wuxiaworld and boxnovel usually has the same problem.

Yes, it is the same issue. It seams like the provider gives an invalid html, so it tried again and again to download that chapter.


wrap qt app install command, add 4 more libs

closes #13
as a shot in the dark, this PR wraps the command to install qt-libs in action.yml, it also added four more libraries that are present in setup-qt-libs, which may be used in certain Qt applications

libdbus-1-3
libegl1-mesa
libxcb-xinput0
x11-utils

@larsoner ... possible that the actions aren't running due to inactivity here?

Also you can see the tests are super basic... if you have widely used modules that would catch some of those new system libraries feel free to add them (but not required)

yeah, I'm afraid it's been a while since I determined the list that I used in setup-qt-libs... i'll dig for a moment and see if I can find a good test case, but may give up :)

Hah, tests fail because the macos-latest now means macos-14. I'll open a separate PR to fix CIs while you look!

side-note, d5e79a9 bumped the action versions and changed python 3.9 to 3.10 (needed unless we want to use an older macos runner)

ah ok :) will undo here

There is a conflict, I can fix it if you want or feel free to push

no worries, got it.

Thanks @tlambert03 !

thanks!

will follow up with better tests in #17


Implement inequality operator for the PlannedContact class

Failure of the ci: https://github.com/ami-iit/bipedal-locomotion-framework/issues/751


when navigate to another screen while Indicator is active, it is become very fast like crazy

https://github.com/exyte/ActivityIndicatorView/assets/155519871/41ece4ec-e1a1-4042-98ff-45e306525d76

Same situation.
Easy reproduce the bug with tabbar.

Hey @michelleKaneen, sorry, but I don't get it: the title is about navigation, but there is no navigation in your code. Where is the indicator during the navigation? How can you see it if you navigate away? Please attach a minimal compilable example (code, not picture) and make sure the issue reproduces on this minimal example. Have a nice day
Hey @SavvaShuli3v, please attach a minimal compilable example and make sure the issue reproduces on this minimal example. Have a nice day

@f3dm76
navigation is passed within "action?()" closure, in the button directly
I was trying to make reusable button with indicator view, it seems the problem due to onAppear function
I fixed this one by stoping the animation before executing the action?() closure


Bump php code_sniffer package to version 3.7.1

Since the actual version 3.6.2 of php code_sniffer yet throw some errors for PHP 8.1 Enums, we need to update to the last version for CodeSniffer package

[X] Update squizlabs/php_codesniffer to 3.7.1 to fully support PHP 8.1

After this is needed to add a new tag to phpqa project.
Thanks

+1 to this PR!


Support for Angular 6

I'm using this in a project that is updating from Angular 2 to Angular 6 (I'm well aware that this is a huge jump). Will there be support for Angular 6 for this datetimepicker? If so, do you know what the timeframe for that is? If you're not doing this update anytime soon, would you be open to a pull request to update the code?

Hello. I am on holidays now, I will take a time for it.

helo @benjaminrlawrence, the plugin should work with angular 6. What issue do you have?

Hi @fetrarij, we were able to get it to work in our project, and the need for a fix was probably project-specific. We had to manually import a script, and then everything worked fine. Thanks for checking though. I'll close this.


Localization Feature

Make config tooltips translatable

if you can make a pull request for another language i can add it

if you can make a pull request for another language i can add it

en_us.json doesn't have localization keys for tooltips

if you can make a pull request for another language i can add it

en_us.json doesn't have localization keys for tooltips

Alr i will quickly port those if you want

if you can make a pull request for another language i can add it

en_us.json doesn't have localization keys for tooltips

What do you mean?

look this
https://github.com/Fruitloopins/Tabby/blob/master/src/main/resources/assets/tabby/lang/en_us.json
and this
https://github.com/Fruitloopins/Tabby/blob/master/src/main/java/com/fwloopins/tabby/config/TabbyConfig.java
no translate keys for @Comment sections (looks like tooltips in minecraft)

i'll have a look at adding it tomorrow

@FurnyGo i've added config tooltip translation strings


updating missing semi-colon

Which problem is this PR solving?

Short description of the changes

/cc @mayurkale22

why do you think this semicolon is needed ?

it was by mistake.


Subscription Swap Error

When i sawp the subscription
$response = $subscription->swap($plan);
i get the error:
Error executing API call (422: Unprocessable Entity): The amount is higher than the maximum. Field: amount. Documentation: https://docs.mollie.com/guides/handling-errors
But i have no problems if i book any of my plans initially, only when "upgrading" by swaping the plan.

This means the plan you're swapping to probably has an amount that's not authorised on your account for this payment method.
It can also happen if another OrderItem is due for processing for this billable model, adding to the amount for the total Order amount.

Closing this for now, let me now if it should be reopened.


File delete by macro cannot be deleted by macro

Hello,
update: I get the same when doing it on the local drive:
rm: cannot remove ‘/dev/shm/activity.fd’: Operation not permitted
Not 100% sure if this is a RPI_cam_Web_Interface problem or just something I'm doing wrong in my scripts.
I use the 2 following macro scripts as explained in the instructions, to create and delete a file at motion start / end. It is a network mount to another pie's /dev/shm.
File: /var/www/html/macros/start_vid.sh
#!/bin/bash echo "MOTION" > /mnt/piramdrive/activity.fd
File: /var/www/html/macros/end_vid.sh
#!/bin/bash while [ -f /mnt/piramdrive/activity.fd ]; do         echo "deleting activity.fd" >> /mnt/usbdrive/log/bash.log         rm -f /mnt/piramdrive/activity.fd >> /mnt/usbdrive/log/bash.log 2>$         sleep 1 done
resulting in bash.log :
deleting activity.fd
rm: cannot remove ‘/mnt/piramdrive/activity.fd’: Operation not permitted
This is the directory listing where the file is created:
pi@pie2:~ $ ls -l /dev/shm/
total 92
-rw-r--r-- 1 pi       pi          20 Jan  8 22:27 light.fd
drwxrwxrwx 2 www-data www-data   100 Jan  8 22:42 mjpeg
The file appears to be created by the user pi, it works fine as soon as motion is detected. The deletion however goes wrong, is the script run by the same user?
I do the same kind of thing from python scripts, but they are started from rc.local, so user root. Creating and deleting files in the same directory works fine then.
This is the macro directory listing:
pi@pie1:~ $ ls /var/www/html/macros/ -l
total 16
-rwxrwxrwx 1 www-data www-data 210 Jan  8 22:25 end_vid.sh
-rwxrwxrwx 1 www-data www-data  33 Dec 24 00:39 error_hard.sh
-rwxrwxrwx 1 www-data www-data  61 Jan  7 19:14 start_vid.sh
-rwxrwxrwx 1 www-data www-data  42 Dec 24 00:39 test.sh
Thanks in advance,
Fj

This sounds like a permissions issue. The macros run as user www-data (which is the user the web server uses and allows better control of security given that these macros are triggered by web operations.). This means that any file operations should be on files or directories that user www-data has relevant permissions.
I'd suggest first testing by doing the operations on a local folder which you have explicitly given www-data access to. If that shows the problem is permissions then there are a number of options; the easiest being to give www-data access to your remote folder.

It is indeed. Creating / deleting it in /dev/shm/mjpeg solves the problem. Not sure how to fix it over a network mount though, but this will work fine. Thanks.


New Lib: fast-json-stable-stringify

In order to add any new production dependency, it must be approved by the App Deployer team. They will evaluate the library and decide if it's something we want to move forward with or if other alternatives should be explored.
Name of library: fast-json-stable-stringify
Details

Link to package: https://www.npmjs.com/package/fast-json-stable-stringify
Problem solved by using this package:

During a performance audit, @janicduplessis noticed that we're spending a significant amount of time in the NumberFormat constructor when chat switching - when opening 5 different chats on Android, it was observed that about 3 seconds were spent in the NumberFormat constructor.
The proposed solution was to cache NumberFormat instances so we aren't re-running the constructor needlessly. In order to do that, we need to serialize the options passed to the constructor so that they can be used in a cache key. JSON.stringify isn't ideal for the purpose of creating cache keys, because the order in JSON objects is not deterministic. i.e: JSON.stringify({a: 'a', b: 'b'}) may produce either {"a": "a", "b": "b"} or {"b": "b", "a": "a"} on two successive calls, which would change the cache key.
This is where fast-json-stable-stringify comes into play - stableStringify({a: 'a', b: 'b'}) and stableStringify({b: 'b', a: 'a'}) will both reliably produce {"a": "a", "b": "b"}. This is what the authors mean when they say it's deterministic.

Number of stars in GH: 273
Number of monthly downloads: >38,000,000 (looking at GH stars vs downloads, everyone uses it without knowing, which - spoiler alert - also includes us!)
Number of releases in the last year: 0 - don't fix it if it ain't broke
Level of activity in the repo: none really, but it still works
Alternatives:

roll-your-own (deep sort the object, then use JSON.stringify)
https://github.com/ljharb/json-stable-stringify. This lib is allegedly the same thing but slower

Are security concerns brought up and addressed in the library's repo? no, not really
How many dependencies does this lib use that will be brought into our code? 0
What will the effect be on the bundle size of our code?

no change - we already use this lib indirectly. It's a transitive dependency so already included in the app bundle. I only created this because we want to add it to package.json and use it directly.

extra context for you @marcaaron:

https://github.com/Expensify/App/pull/40158
https://expensify.slack.com/archives/C035J5C9FAP/p1712894837849989

Looks fine to me I guess - it's like 50 lines of code... do we still have to have a conversation about it?

everyone uses it without knowing, which - spoiler alert - also includes us

so we use it already?

no change - we already use this lib indirectly. It's a transitive dependency so already included in the app bundle. I only created this because we want to add it to package.json and use it directly.

I think you can just go ahead and include this as a dependency since it's a tiny library. But lmk if you still want to talk about it. And I will post this on Monday. Doesn't look like anyone would say no IMO.

Looks like it is currently a transitive dependency of jest and webpack, it might not actually be included in the app bundle currently since those are dev dependencies, but as mentionned it is tiny.

I agree it's unlikely we'll get pushback, I'm just following the process rather than making a unilateral decision to skip it.

Posted here

Closing this. LMK if we need to reopen.


Add line for building dl4j without cuda from source in the doc

https://deeplearning4j.org/buildinglocally.html#building-manually states
mvn clean install -DskipTests -Dmaven.javadoc.skip=true
which fails at the point it is trying to build the cuda part for dl4j. in my opinion the doc should include
mvn clean install -DskipTests -Dmaven.javadoc.skip=true -pl '!org.deeplearning4j:deeplearning4j-cuda-8.0'
for the possibility to build dl4j without cuda support.

This is handled in our build-dl4j-stack.sh script now.


Fetching httponly cookies

Hi,
I am currently developing an app where the users can login to a website via this webview. I need to fetch httponly cookies so that the user is able to use my app and post contents using his session cookies.
The problem is httponly cookies can only be fetched from the server due to security reasons, in the case only from native iOS and android which is NSHTTPCookieStorage (if i'm correct) and Cookie Manager respectively.
There is another third party package, react-native-cookies which does this but it has been abandoned by the owner and it doesnt fetch httponly cookies, when i tried it with iOS. I'm not sure if it's because of the package not directly attaching to webview, or because of iOS updated security policies. I've looked at it's implementation, it is using NSHTTPCookieStorage in iOS and it's called using native modules, so i'm not sure what's wrong here.
I am wondering if you can include fetching of cookies as well in the webview, especially httponly cookies as it will definitely help a lot of developers out there who creates a similar app as myself.
Regards

Why you close this issue? @fadhlisulaimi

@taoqf I have managed to tweak react-native-cookies package and retrieve httponly cookies from there. I have to change the implementation of the native methods in iOS. I am using WKHTTPCookieStore and WKWebsiteDataStore instead. From there I loop through it and get each of the NSHTTPCookie.

Can you share your implementation @fadhlisulaimi ?

@fadhlisulaimi I am also interested to know how you did it!

Could you please share the instructions/code?

just my 0.02 ...

cookies "set" by a client are not http-only. by-design it should only be possible to send a cookie as http-only that was set by the (originating) http host/server. this is a matter of security defined by the protocol and to be enforced by implementations, otherwise, http-only cookies would not exist at all. if you discover a service which accepts a client-set cookie that "should be" http-only then you have discovered a potential vulnerability in the target service: services rely on http-only cookies as a means of securing cookies from malicious scripts/users (abuse.)

http-only cookies should not be readable by client/application code, either. while you may be able to "hack" the cookie out of a native component via external means it would be inappropriate to do so and-also qualifies as exploitation when done to access secure artifacts created/owned by a third party, such as an auth token, since you are circumventing the security protocols expected to be in effect by the third party. I would not expect such a misuse to pass something like appstore validation except that it may have gone unnoticed.

TL;DR? there shouldn't be a way to read/write http-only cookies from within an application. while doing so may seem useful to a small percentage of hackers it would be inappropriate as a community to make it trivially possible from within react-native applications.  if one "necessarily must" make this possible they would need to do as fadhli has done and modify libraries themselves, but such modifications should remain unacceptable/inappropriate to the community as they would make it trivially possible to steal secrets from unsuspecting users.

@wilson0x4d I absolutely agree, but what solution do we go to then? I am using a httponly cookie setup to authenticate users through a website. I also have an app that ideally should use the same auth endpoint. If I create a new endpoint that returns a token, I'm open to XSS again. If I use the httponly cookie as is, it wont persist through app closures.

Basically, due to security concerns...httponly cookies needs to be protected thus it can't be directly retrieved from javascript due to xss or script injection. It can only be retrieved from server or in this case native code.
Thus u need to call httponly cookies from native (android/ios) using cookiemanager (android) and WKHttpCookieStore(ios).

Figured this out by simply using react-native-cookies it is possible

@ansh How did you solve this?

It should be possible to read an httponly cookie by doing a fetch request like shown here:
https://github.com/react-native-webview/react-native-webview/issues/207#issuecomment-498605263
However I am not sure how to transfer this cookie to the webview afterwards

@wilson0x4d
So how do I keep my login when I shut down the app and turn it on?

I read the solutions mentioned above, mostly the same as the library code for https://github.com/react-native-cookies/cookies
So I checked again in that library,
Turn off Network Inspect on the React Debugger to work.
Why does this happen?


Update EDA tools

Motivation for this change
A big batch of updates to the free FPGA tooling, including new package python3Packages.nmigen-soc.
This should also fix trellis and its integration for ECP5 support in nextpnr, which wasn't previously working due to CMake installation path issues.
cc @thoughtpolice if you don't mind taking a look at this? :)
@GrahamcOfBorg build symbiyosys python3Packages.nmigen-boards python3Packages.nmigen-soc glasgow tinyprog
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This PR has moved the nmigen package away from the official repository which is m-labs/nmigen. cc @sbourdeauducq (you're on holiday atm), are you aware of this?

Indeed, the official nmigen repositories are:
https://github.com/m-labs/nmigen
https://github.com/m-labs/nmigen-boards
https://github.com/m-labs/nmigen-soc
The homepage can be https://nmigen.org (currently simply redirects to the repository but we'll make one later).

sigh I was hoping this issue would not come up here too...
For context, @sbourdeauducq is the developer of nMigen's predecessor Migen, and CEO of M-Labs, whitequark's former employer. The nmigen/nmigen repository is the repository where active development happens and is controlled by nMigen's lead and almost sole developer (@whitequark, see https://github.com/nmigen/nmigen/graphs/contributors). Currently, the only change in the m-labs repositories, other than being several days out of date, it is to remove the credit for whitequark's current employer and the current funder of nMigen development. You can also see a long and unpleasant Twitter thread about this issue.
Obviously, the decision is up to those with nixpkgs commit access, but I do not believe this request is being made in good faith, and as the sole maintainer of these packages I am definitely uninterested in pointing them to a disgruntled former employer's clearly-downstream repository. Indeed, it would have been impossible to; at the time of this pull request, the current versions in m-labs' repository did not build together.
Sébastien – my sincerest hope is that you can reflect on what people are telling you about this situation and act in a less toxically passive-aggressive manner towards your (ex-)employees; it would be better for yourself, for M-Labs, and for the EDA community as a whole. I realize that GitHub is not the appropriate place for life advice, but nor is it the appropriate place for you to continue your vendetta against your ex-employee.
To the nixpkgs maintainers – sorry that this interpersonal dispute has reached your shores.

sigh I was hoping this issue would not come up here too...
[...]
nor is it the appropriate place for you to continue your vendetta against your ex-employee.

Who started it by slipping in a change of upstream into a large pull request? Who is being passive-aggressive?

remove the credit for whitequark's current employer and the current funder of nMigen development.

Since you are bringing that up, I have to add that - in addition to the several other arguments I made in the Twitter thread you linked - whitequark obtained that alleged funding behind my back while she was a M-Labs employee and we were trying to figure out ways to get her paid for nMigen work. I do not know under what terms she obtained it (employment or otherwise); as indicated in the commit message I have received no reply when I contacted them about it (still to this day).
I have no issue with the funding in itself - in fact on several occasions M-Labs matched donations made to nMigen (in addition to other funding and funding agreements) - simply with the underhanded way in which whitequark acted.

This is hardly the first roll-up update PR of the EDA tools I've done: #66596, #67022, #67827, #68107, #71238. That's what maintaining packages is about, after all. In this case, I was getting around to fixing the issues with the Trellis package due to relevant upstream changes and a friend requesting I package nmigen-soc. This also involved making upstream changes to nmigen-soc and glasgow to get everything to compile and work properly.
You might get more replies to your communications if you didn't treat everyone like this. Are these really the actions of a heartbroken man (content warning: misgendering), or just a manipulative and controlling one?
I don't really have anything more to say on on this sorry topic, and no real power, so I'll leave this up to @thoughtpolice.

Who started it by slipping in a change of upstream into a large pull request?

The maintainer of the packages in question did -- someone who has complete authority to do so, to be clear -- and someone who has repeatedly shown good faith and work, time and time again, when it comes to contributing to this project. That's who did it, actually. (The only reason Emily even goes through me at this point is formality, honestly.)
On top of that, there's me, the person who approved it. And as a long-time contributor and one of the maintainers of this part of Nixpkgs, I'm not exactly unfamiliar with the projects in question, their developers, their users, or who's who -- the FOSS EDA community isn't exactly large, you know. So when I get a pull request from a co-maintainer to update a package and when I'm familiar with who the developers of that package are, it's very easy for me to see a change in upstream and know it's essentially 100%-without-any-doubt being made in good faith. Even then, the reasoning is relatively easy to verify independently of even what Emily might say -- for instance, by looking at the Git history of nMigen or simply asking anyone involved about the change. Again, not a big community! What, did you expect this whole change/shitstorm was impossible to unravel? I'm not exactly Sherlock Holmes but I'm pretty sure this isn't a murder mystery and I could have figured it out.
There is also the angle about the employment of whitequark but, frankly, it's just none of my business.
The change in upstream repository did not slip by me as an afterthought; I reviewed this request as asked. But upstreams change all the time for a variety of good reasons. Had you or your friend not come in here make a big deal out of it (in a most fantastically poor form, I might add), I would have been completely under the impression that this is a normal organization transferral, and none the wiser. Clearly, that is not the case. And unfortunately, making a big deal out of it isn't working out for you, obviously. Why on earth would I appease any individual or organization that would engage in this behavior? It's only an invitation for it to continue happening. No thanks.
Any discussion concerning a change/revert in upstream isn't continuing, because the change isn't being undone, nor is it up for any further debate (and I'll ensure I'm CC'd on any possible future change to these packages.) You're free to continue this discussion with me privately if you wish -- but it's probably not going to be very enjoyable, I'm afraid.

IMHO locking this issue is a bit premature. While we don't have an official policy on this (or much of anything, really), Nixpkgs does generally stick to upstream versions of packages. If forks are widely considered useful to have, then those can also be included in Nixpkgs, but they should have a different name. In any case the PR should have mentioned that it switches nmigen to a different repo.

The nmigen/nmigen repository is the upstream version of the package in the minds of everyone but sb0.

Uh, interesting. I never knew editing others' comments was a thing on GitHub.

if you have commit access, you can. Generally, people don't.

"Upstream" generally refers to the fork where active development takes place; there is no magical policy in open source that "upstream" is whoever claims the name first. "Upstream" can change organically, due to slow changes in the development team. It can also change instantaneously, such as when the entirety of the active development team switches repos, which was the case here. Regardless of who controls a GitHub or legal entity, it is entirely evident that active development of nmigen has instantaneously switched to this repo.
If anything it is now up to the m-labs folks to prove that their fork deserves to be canonical upstream by, say, taking it in a different/better/more active direction. Which I highly doubt will happen.

IMHO locking this issue is a bit premature.

No it isn't -- there's nothing left to discuss.

(or much of anything, really)

Then I'm not sure why you're second guessing me on a non-existent "policy" when I've got more than enough information to assess the situation, and direct knowledge of the involved tools and people. If you have an issue with the way I handled this, you can take it up with me directly -- personally -- but there's no "policy" to enforce here, and so any further debate isn't necessary, or fruitful.

If forks are widely considered useful to have, then those can also be included in Nixpkgs, but they should have a different name.

Unless you're directly taking the stance that the packages get renamed or something -- which absolutely, 100% is not going to happen, btw, and I would absolutely revert any change that did so no matter who authored it -- I'm not sure what the point of re-opening this is, other than to draw this out.
Software development is largely a social process, and sometimes you get situations like these.  Frankly, you should have zero patience for it. Not only because it's abusive, but because there are few technical mistakes you could ever commit to Nixpkgs that are as bad as allowing that behavior to continue on this issue tracker. And, besides, this change isn't a mistake in any technical sense -- it's the right choice, abusive interlopers aside.
I would make this same call on any package I was familiar with in the tree, and even ones I wasn't familiar with, provided someone was being abused similarly -- totally ignoring the fact this case is extremely clear cut technically.

Nixpkgs does generally stick to upstream versions of packages.

It's not that simple. Upstream is not a technical, immutable property of a repository in the same sense "this crayon is blue, this one is red". In this case the new repository is not only being actively developed by the primary maintainers (who was also doing development for a long time on at the old URL), and they own the namespace on systems like pypi. I'd argue actually it probably violates users intuition if they installed nmigen from nixpkgs and did not get the new repository -- especially since it will be used in shipping products.

If forks are widely considered useful to have, then those can also be included in Nixpkgs, but they should have a different name.

This argument isn't relevant though, because it's not a fork, it's the actual new upstream. This misunderstanding seems to be the root of the issue, so I hope that clears it up.

Software development is largely a social process, and sometimes you get situations like these.

I don't see an ethical issue with calling out the bad behavior of former employees (or anyone else really) especially when it is relevant to explaining the issue at hand. You are simply trying to find excuses to silence me because the truth I am speaking offends you.

abusive interlopers aside.

Surely you are aware that the "abusive interloper":

designed and wrote much the original Migen, from which nMigen is largely inspired
came up with several nMigen-specific ideas even if he did not implement them himself. There is more than the lines of code in the GitHub statistics.
provided financial and administrative support to whitequark
hired someone to work on nmigen-stdio and nmigen-soc
encouraged Lambdaconcept and others to use and sponsor nMigen

Not bad for an interloper, heh?

...
Honestly, all I have to say at this point is that if movie-villain-esque speeches are how these things are decided then I'll have no desire to maintain the packages I do any more and will remove myself from maintainer-list.nix. I signed up to keep free software working and up to date, not to deal with... whatever this is.
Contributing to projects that can't recognize bad-faith actors is simply not worth the strain that having to deal with abusive politicking like this causes; I think that opinion will be shared by many existing and prospective NixOS contributors.

Alternatively, you could try to negociate with me for me to recognize the new upstream (contrary to what you keep repeating, I am acting in good faith), but defamation and other abusive bullshit isn't going to work.

Alternatively, you could try to negociate with me for me to recognize the new upstream

I think your desire for control above all else is beyond obvious to all observers at this point. ¯\_(ツ)_/¯

I don't see an ethical issue with...

Yes, that much is clear.

You are simply trying to find excuses to silence me because the truth I am speaking offends you.

Eelco, if you'd like to discuss this further, please contact me directly, but do not unlock this issue. There's little point in this issue being open, and nothing is going to change here regardless (neither derivation name or upstream).


Recreated doc for Local LLMs - LiteLLM and Ollama - native function calling in Ollama

Why are these changes needed?
Ollama's code base now supports function calling natively, so I have recreated the documentation for LiteLLM+Ollama. Also, LiteLLM is breaking when it is set to use function calling with Ollama and the ollama_chat setting - this avoids that.
Have also updated the documentation to use Meta's Llama 3 model for function calling, which works well.
Changed the documentation file from the markdown format (.md) to a Jupyter notebook (.ipynb) to be inline with other documentation pages.
The code samples are essentially the same.
Related issue number
Should help with #2699.
Checks

[X] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[X] I've made sure all auto checks have passed.

Ollama's code base now supports function calling natively,

If ollama already support function call, would using litellm as proxy still be necessary here?

Ollama's code base now supports function calling natively,

If ollama already support function call, would using litellm as proxy still be necessary here?

Hi @LittleLittleCloud, yes my opinion is that it's better to just use Ollama directly and hence we have the Ollama client class PR underway. However, LiteLLM + Ollama are still a valid option for those already have it installed or use LiteLLM + many inference options.
This documentation will need to be updated when the Ollama client class is ready with a Tip that they can use Ollama directly.


Added support for using spacebar in configuration file

Just a quick change allowing users to pause with sapce bar by using "space" in their config files, of course "space" can be changed but wordwise it makes the most sense to me.
Really like Miniplayer and am looking forward to working more on it :D
(loved your post on unixporn btw)

This is some good work! Thank you! Looking forward to seeing what you come up with 🐸


Move rack and datacenter defaulting to API

This allows the defaults to be visable in something like kubectl get cassandraclusters, avoiding the user being surprised.
NONE

This should be moved into pkg/apis/navigator/v1alpha1 as an actual
defaulting function and not as part of the apiserver registry directly.
See an example here:
https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/apis/servicecatalog/v1beta1/defaults.go
On Wed, 28 Feb 2018 at 12:08, jetstack-bot<EMAIL_ADDRESS>wrote:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
We suggest the following additional approver: wallrj
Assign the PR to them by writing /assign @wallrj in a comment when ready.
The full list of commands accepted by this bot can be found here
https://go.k8s.io/bot-commands.
Needs approval from an approver in each of these OWNERS Files:

OWNERS https://github.com/jetstack/navigator/blob/master/OWNERS

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/jetstack/navigator/pull/269#issuecomment-369220125,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbPxjbSef7VJ8_-FpeQVwkV3aHFgR0ks5tZUG6gaJpZM4SWjMK
.

@munnerz  ah nice, I didn't know about the defaulter-gen stuff

/lgtm
/approve


⚠ ClamAV has degraded performance

In 59caa02, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 185 ms

Resolved: ClamAV performance has improved in ee0b475.


Add HTML Structural and Content Code

Add HTML Structural and Content Code
User Story
As an employer
I want to view a potential employee's deployed portfolio of work samples
So that I can review samples of their work and assess whether they're a good candidate for an open position
Acceptance Criteria
Given I need to sample a potential employee's previous work

When I load their portfolio
Then I am presented with the developer's name, a recent photo or avatar, and links to sections about them, their work, and how to contact them

When I click one of the links in the navigation
Then the UI scrolls to the corresponding section

When I click on the link to the section about their work
Then the UI scrolls to a section with titled images of the developer's applications

When I click on the images of the applications
Then I am taken to that deployed application

Added HTML code to meet all the requirements above.


Consider the role of our internal bandersnatch mirror, and if it makes sense to continue to use it

We currently have an infrastructure where we have Fastly sitting in front of three origin servers:

Our Warehouse cluster
A Bandersnatch Mirror
GCP (I think?) Bucket storing files

Generally speaking the happy path is that files go directly from Fastly to S3, and /simple/ the happy path is from Fastly to our Warehouse cluster.
However, if our Warehouse cluster is down for some reason, then Fastly is configured to hit our internal Bandersnatch mirror, to keep pip install working.
This made a lot of sense when we initially deployed because pip install foo depended on Warehouse being up, and this meant even in the case Warehouse was down, that pip install would still work.
However, in the TUF work, we're now looking to move from generating the /simple/ files on demand, to pregenerating them and storing them inside of an object store. This means that hypothetically we could serve the /simple/ index similarly to how we serve the actual files, having Fastly directly contact the object store.
This raises the question that, if we have Fastly directly contacting the object store, is there a large benefit to continuing to maintain our own internal mirror? In what cases do we expect to actually fall back to the mirror if the Warehouse cluster is taken out of the "hot path" for pip install? Are any of those cases better handled by some form of native object store replication that can replicate a single bucket to another and having Fastly just round robin between them?
This also reminds me that we probably have to disable the bandersnatch mirror once TUF support lands, until bandersnatch gains support for TUF as well.
@ewdurbin @woodruffw @cooperlees @di

Can someone please open a issue when it's fully known what bandersnatch will need to do for TUF please :)

Yea will do for sure, I'm pretty sure the answer is just "more files to copy", but it will be good to have some clarity on the issue.

Just so it's known, I'm down to help/own the bandersnatch mirror for PyPI if we move forward with it (if it's of an advantage). I propose to ansible it all and commit that to https://github.com/python/pypi-infra.
@ewdurbin and I were also keen to change it to use S3, but @techalchemy never came forth with the s3 plugin he's supposedly written.
But totally down to not need this for PyPI if it makes sense. E.g. does it even make sense to run a second origin on a separate cloud if we have enough credits? I only see DB sync complexities there.

Ping for update here.
Today I released to a way more asyncio + uvloop capable version 5.0.0 of bandersnatch. I'd love to upgrade the PyPI internal mirror to this version using our docker container. I see it still exists @ mirror.dub1.pypi.io and writing to a POSIX mount:
/dev/xvdb        12T  9.5T  2.5T  80% /data

@ewdurbin - Any chance of a small test instance + small /data so I can model a:

Docker container running bandersnatch: https://hub.docker.com/repository/docker/pypa/bandersnatch
Docker container running nginx: https://github.com/pypa/bandersnatch/blob/master/src/banderx/Dockerfile

I will then ansible it all and put up a PR to https://github.com/python/pypi-infra we can discuss implementation before moving to the prod instance (or we could replace the prod with the test once read and prod becomes test). What ever your prefer here.
S3 support has not made it to bandersnatch yet, but we do have a contributor adding it: https://github.com/pypa/bandersnatch/pull/886

If this deems useful for our instance here, I will help get this merged.

Thanks!

Ok - we now have a S3 capable version of bandersnatch published to Docker Hub that we can use to proof of concept if it's still of benefit moving from /dev/xvdb to a s3 backend for the PyPI Disaster Recovery mirror.
We've documented the setup here:
https://bandersnatch.readthedocs.io/en/latest/storage_options.html#amazon-s3
Once again, I'm happy to help with the work here. Could be a PyCon sprint objective I'm happy to help drive. To do test this, I'd love to get a new cloud instance somewhere to run bandersnatch (preferably from a docker container) in the new S3 mode and a bucket to fill. Then we can sync away and point the CDN at the s3 bucket I believe and turn down the old instance once it's no longer being used. I am a novice at this tho, I am no s3 guru.
Happy to start a document with a lot more details etc. to plan it all out.
cc: @dstufft + @ewdurbin


epinio app logs --staging command

The user should be able to see the latest staging logs for an application with this command.
The command should find the latest PipelineRun, extract the stageID from it and stream the logs for that staging process.

Relevant but maybe deserves a separate issue:
We haven't discussed rollbacks yet but we do have lots of left-over "Completed" pods from previous staging runs (#55). Maybe a good time to cleanup would be after a successful staging run. In other words, when staging succeeds, we can delete all previous staging pods because the won't be needed anymore. This would maybe simplify this story because there won't bee too many staging pods to select from (though there will be 2 different staging processes to select from).


Add interpolate method

@kurkle you have already added!!! FINE! Let me add a note that when it will be released and included in CHART.JS, the chartjs-plugin-gradient could be changed!


Great content for business continuity planning (last updated in 2016)

(1) This article is a key resource in region-wide business continuity planning. This may be the only document that focuses specifically on a region-wide outage scenario.  Since so many new capabilities are continually added to Azure, can this article be updated to cover new services, new best practices, etc. The publish date lists that the last update was in 2016 - if that is accurate an overall review and update to this would be really appreciated.
(2) The Checklists for disaster recovery section is good but many of the sections make reference to other sections in the document (if possible can you add links to these sections as direct pointers)
Thank you!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b31c85c7-c25d-897f-e52d-789f7306457b
Version Independent ID: 969106a5-df35-afef-5afc-96a26c970f44
Content: Recover from loss of an Azure region
Content Source: docs/resiliency/recovery-loss-azure-region.md
Service: architecture-center
Sub-service: cloud-design-principles
GitHub Login: @adamglick
Microsoft Alias: pnp

@tfurstms Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

Thank you for this great feedback! We are currently working on updating this document as I type. We hope to have updated guidance early in the new year that addresses these exact comments. Thanks so much. Will close for now.


Correct ValueError to TypeError

Hi @mihaimaruseac, I've updated the commit message.

This is a TypeError instead of ValueError because, in the if clause, we are checking the type of identifier. See https://docs.python.org/3/library/exceptions.html#TypeError :

Passing arguments of the wrong type (e.g. passing a list when an int is expected) should result in a TypeError, but passing arguments with the wrong value (e.g. a number outside expected boundaries) should result in a ValueError.

The change from constructor(str, arg) to constructor(str.format(arg)) is because the former is undocumented.


about performance

I test this protocol,and make tx and rx do loop test , then I found the test packet performance seems not very good. it only got near 28000 packets send in each second on a udp port.  It seesm the max packet processed on a server can't reach 30000 . Is there any performance report about this ?

That doesn't seem like a very meaningful benchmark.

I write a server with this quic go implement on udp port. and I test the performance  .I test two scenes case .  One is only one quic client and another is  many quic client.   I found the max performance kept same ,it always only got near 28000 on 40 core cpu.   what is the problem ?   and Is there any performance test report about this ?  thanks !


[DOM] Web framework preview

What this PR does
The pr contains main logic of web framework. It's not the final version. Don't merge it now.

Coverage decreased (-44.8%) to 30.964% when pulling eed593cf8450d63febf3ec148a3348b51d82c420 on kdada:dev into 5ff1eae5410134cba94136cefe89b7d077026a58 on caicloud:master.

Coverage decreased (-44.8%) to 30.964% when pulling eed593cf8450d63febf3ec148a3348b51d82c420 on kdada:dev into 5ff1eae5410134cba94136cefe89b7d077026a58 on caicloud:master.

Coverage decreased (-44.8%) to 30.964% when pulling eed593cf8450d63febf3ec148a3348b51d82c420 on kdada:dev into 5ff1eae5410134cba94136cefe89b7d077026a58 on caicloud:master.

Coverage decreased (-44.9%) to 30.834% when pulling 4bc2ef38b2cec177339c543d7c66d4620b1680da on kdada:dev into 5ff1eae5410134cba94136cefe89b7d077026a58 on caicloud:master.

Coverage decreased (-44.9%) to 30.834% when pulling 1802269e77c072e9cb4a6ffba23078139576f866 on kdada:dev into 16ac1755d3027352c1778ed7e0c89b48583e3eaf on caicloud:master.

Coverage decreased (-54.8%) to 37.574% when pulling 4848eec59c23e2a5f41b03dc54e1bf1938643666 on kdada:dev into 1497682e358d9616cc1aaa7c6d10b935f8622905 on caicloud:master.

Coverage decreased (-54.8%) to 37.574% when pulling 8e2f01ac76e6d0960f0c4ecb6a79fc0b54694ef5 on kdada:dev into 1497682e358d9616cc1aaa7c6d10b935f8622905 on caicloud:master.

Coverage decreased (-54.8%) to 37.574% when pulling f75370a57e12a3a36e85356a4a1ed1c117484598 on kdada:dev into 1497682e358d9616cc1aaa7c6d10b935f8622905 on caicloud:master.

Coverage decreased (-9.2%) to 54.377% when pulling 3008b76888949377f01ca3f7c402f275bfb0b61f on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.2%) to 54.377% when pulling 3008b76888949377f01ca3f7c402f275bfb0b61f on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.2%) to 54.363% when pulling b67952984c83c19451023ade956901271229706c on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.2%) to 54.363% when pulling 6aeac4da9301c33e793bff25364954437fc38fba on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.2%) to 54.302% when pulling 62e78bd997170e8c511542c8283ca6197cf14d23 on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.2%) to 54.317% when pulling ea9667356bf45e0fcc4515fdc87ed12763eb3653 on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.3%) to 54.209% when pulling eabf3b6821be05cc8e334908ed5ee798c410ada7 on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.02%) to 54.511% when pulling 05c4f61c6cdac25d67ce6e373f059b72e0565197 on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-9.9%) to 53.594% when pulling 467d56fb563c10620fb6957a22ded2e868da706d on kdada:dev into b0a0cb11b00fa40248498aed95f20dc64829c881 on caicloud:master.

Coverage decreased (-10.1%) to 53.418% when pulling b0798976a0c28ff73564e1286feb86c18972b697 on kdada:dev into 1d9d0fb7d2f440dcd0126fd71fd64d94d9f5666c on caicloud:master.

Coverage decreased (-10.1%) to 53.418% when pulling b0798976a0c28ff73564e1286feb86c18972b697 on kdada:dev into 1d9d0fb7d2f440dcd0126fd71fd64d94d9f5666c on caicloud:master.

Coverage decreased (-10.1%) to 53.418% when pulling 790e75db29ea1ebe8181722f8fa81e8b4199d116 on kdada:dev into 1d9d0fb7d2f440dcd0126fd71fd64d94d9f5666c on caicloud:master.

Coverage decreased (-10.1%) to 53.418% when pulling 8dc24b5a349db08c3a8232676bf3ed628a61ec29 on kdada:dev into 1d9d0fb7d2f440dcd0126fd71fd64d94d9f5666c on caicloud:master.

Coverage decreased (-9.9%) to 53.671% when pulling 68d4a6d3ed7cc92495983472e6d1e684e6f92047 on kdada:dev into 1d9d0fb7d2f440dcd0126fd71fd64d94d9f5666c on caicloud:master.

Should we put web into root?

Coverage decreased (-9.9%) to 53.654% when pulling 921f5f8f6e532e34ddfaed7fa097fe590f394d96 on kdada:dev into 1d9d0fb7d2f440dcd0126fd71fd64d94d9f5666c on caicloud:master.

Coverage decreased (-9.5%) to 53.419% when pulling 104d4473a691509669434844c2cd08facacbe175 on kdada:dev into 275fcc0b4ea33194d3388bff2b728e59db886319 on caicloud:master.


robot_state_publisher: 2.3.0-3 in 'eloquent/distribution.yaml' [bloom]

Increasing version of package(s) in repository robot_state_publisher to 2.3.0-3:

upstream repository: https://github.com/ros2/robot_state_publisher.git
release repository: https://github.com/ros2-gbp/robot_state_publisher-release.git
distro file: eloquent/distribution.yaml
bloom version: 0.9.0
previous version for package: 2.3.0-1

robot_state_publisher
* Install include directories (#31 <https://github.com/ros2/robot_state_publisher/issues/31>)
* Publish URDF string on startup (#24 <https://github.com/ros2/robot_state_publisher/issues/24>)
* Contributors: Patrick Beeson, Poh Zhi-Ee, Shane Loretz

messed up


Overwrite Autocomplete clear action with onClear property

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
It would be nice to have the opportunity to add my custom function when pressing the x-Icon in the Autocomplete TextField. Therefore I suggest adding the onClear property to customize the action when pressing this button.
I know there is a way around when using the useAucotomplete Hook, but I think if it is not too hard to implement it would be easier to have it within the normal Autocomplete Component.
Examples 🌈
<Autocomplete
inputValue={inputValue}
onInputChange={(event, newValue) => setInputValue(newValue)}
options={options}

onClear={handleClear}
/>

Motivation 🔦
We use Autocomplete for Segmentinputs but have the actions controlled in the backend. We differentiate between Inputs that allow null values and Inputs that do not allow this. Therefore we want to customize the x-Icon action to handle different cases when pressing the Icon.

You can use the third argument of onInputChange, if it is clear do your logic.

You can use the third argument of onInputChange, if it is clear do your logic.

Thank you. I should have looked closer 😆 This is what I needed

Did anyone found a proper solution to this?
I tried the suggested:
<Autocomplete
  onChange={(event, value, reason) => {
      if (reason === 'clear') {
          alert("cleared");
      }
  }
/>

But it doesn't work, clear is also present in reason when the user delete the last character from the input. Therefore it can't be used to detect clicks on the clear button.

Ah, nevermind, I just found a way:
<Autocomplete
  onChange={(event, value, reason) => {
      if (reason === 'clear' && event.type === 'click') {
          alert("cleared using X icon");
      }
  }
/>

If you want to do something else on keyboard delete actions, you can use event.type === "change".