Faild to build ros2_control_demo_hardware package

Hello, does anyone know to solve following build error?
I want to run demo with following page.
https://github.com/ros-controls/ros2_control_demos
I did following steps,
(1) mkdir -p ~/ros2_control_demo_test/src
(2) cd ros2_control_demo_test/src
(3) git clone https://github.com/ros-controls/ros2_control_demos
(4) cd ~/ros2_control_demo_test
(4) rosdep install --from-paths src --ignore-src -r -y
-> #All required rosdeps installed successfully
(5) colcon build
And, I got followig errors.
--- stderr: ros2_control_demo_hardware
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:19:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/external_rrbot_force_torque_sensor.hpp:35:24: error: ‘rclcpp_lifecycle’ does not name a type
35 | using CallbackReturn = rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn;
|                        ^~~~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/external_rrbot_force_torque_sensor.hpp:43:3: error: ‘CallbackReturn’ does not name a type
43 |   CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/external_rrbot_force_torque_sensor.hpp:49:3: error: ‘CallbackReturn’ does not name a type
49 |   CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/external_rrbot_force_torque_sensor.hpp:52:3: error: ‘CallbackReturn’ does not name a type
52 |   CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:19:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_actuator.hpp:36:24: error: ‘rclcpp_lifecycle’ does not name a type
36 | using CallbackReturn = rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn;
|                        ^~~~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_actuator.hpp:44:3: error: ‘CallbackReturn’ does not name a type
44 |   CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_actuator.hpp:53:3: error: ‘CallbackReturn’ does not name a type
53 |   CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_actuator.hpp:56:3: error: ‘CallbackReturn’ does not name a type
56 |   CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:19:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:36:42: error: ‘node_interfaces’ in namespace ‘rclcpp_lifecycle’ does not name a type
36 | using CallbackReturn = rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn;
|                                          ^~~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:44:3: error: ‘CallbackReturn’ does not name a type
44 |   CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:47:3: error: ‘CallbackReturn’ does not name a type
47 |   CallbackReturn on_configure(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:56:3: error: ‘CallbackReturn’ does not name a type
56 |   CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:59:3: error: ‘CallbackReturn’ does not name a type
59 |   CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;
|   ^~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:15:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:41:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::on_init(const hardware_interface::HardwareInfo&)’ marked ‘override’, but does not override
41 |   CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
|                  ^~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:44:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::on_configure(const rclcpp_lifecycle::State&)’ marked ‘override’, but does not override
44 |   CallbackReturn on_configure(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:53:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::on_activate(const rclcpp_lifecycle::State&)’ marked ‘override’, but does not override
53 |   CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:56:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::on_deactivate(const rclcpp_lifecycle::State&)’ marked ‘override’, but does not override
56 |   CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:15:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/diffbot_system.hpp:44:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::DiffBotSystemHardware::on_init(const hardware_interface::HardwareInfo&)’ marked ‘override’, but does not override
44 |   CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
|                  ^~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/diffbot_system.hpp:53:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::DiffBotSystemHardware::on_activate(const rclcpp_lifecycle::State&
’ marked ‘override’, but does not override
53 |   CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/diffbot_system.hpp:56:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::DiffBotSystemHardware::on_deactivate(const rclcpp_lifecycle::State&)’ marked ‘override’, but does not override
56 |   CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:15:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_multi_interface.hpp:46:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::on_init(const hardware_interface::HardwareInfo&)’ marked ‘override’, but does not override
46 |   CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
|                  ^~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_multi_interface.hpp:60:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::on_activate(const rclcpp_lifecycle::State&)’ marked ‘override’, but does not override
60 |   CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_multi_interface.hpp:63:18: error: ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::on_deactivate(const rclcpp_lifecycle::State&)’ marked ‘override’, but does not override
63 |   CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;
|                  ^~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp: In member function ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::on_init(const hardware_interface::HardwareInfo&)’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:33:44: error: ‘on_init’ is not a member of ‘hardware_interface::SystemInterface’
33 |   if (hardware_interface::SystemInterface::on_init(info) != CallbackReturn::SUCCESS)
|                                            ^~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:39:24: error: ‘info_’ was not declared in this scope; did you mean ‘info’?
39 |   hw_start_sec_ = stod(info_.hardware_parameters["example_param_hw_start_duration_sec"]);
|                        ^~~~~
|                        info
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:39:19: error: ‘stod’ was not declared in this scope; did you mean ‘std::cxx11::stod’?
39 |   hw_start_sec = stod(info.hardware_parameters["example_param_hw_start_duration_sec"]);
|                   ^~~~
|                   std::cxx11::stod
In file included from /usr/include/c++/9/string:55,
from /usr/include/c++/9/stdexcept:39,
from /usr/include/c++/9/array:39,
from /usr/include/c++/9/tuple:39,
from /usr/include/c++/9/bits/unique_ptr.h:37,
from /usr/include/c++/9/memory:80,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_multi_interface.hpp:20,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:15:
/usr/include/c++/9/bits/basic_string.h:6642:3: note: ‘std::cxx11::stod’ declared here
6642 |   stod(const wstring& str, size_t* idx = 0)
|   ^~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp: In member function ‘virtual std::vector<hardware_interface::StateInterface> ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::export_state_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:107:31: error: ‘info’ was not declared in this scope
107 |   for (std::size_t i = 0; i < info.joints.size(); i++)
|                               ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp: In member function ‘virtual std::vector<hardware_interface::CommandInterface> ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::export_command_interfaces(
’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:124:31: error: ‘info’ was not declared in this scope
124 |   for (std::size_t i = 0; i < info.joints.size(); i++)
|                               ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp: In member function ‘virtual hardware_interface::return_type ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware::prepare_command_mode_switch(const std::vector<std::cxx11::basic_string >&, const std::vector<std::cxx11::basic_string >&)’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:146:33: error: ‘info’ was not declared in this scope
146 |     for (std::size_t i = 0; i < info.joints.size(); i++)
|                                 ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:163:27: error: ‘info’ was not declared in this scope
163 |   if (new_modes.size() != info.joints.size())
|                           ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:178:33: error: ‘info’ was not declared in this scope
178 |     for (std::size_t i = 0; i < info.joints.size(); i++)
|                                 ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:189:31: error: ‘info’ was not declared in this scope
189 |   for (std::size_t i = 0; i < info.joints.size(); i++)
|                               ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:33:1: error: ‘CallbackReturn’ does not name a type
33 | CallbackReturn RRBotModularJoint::on_init(const hardware_interface::HardwareInfo & info)
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:32:1: error: ‘CallbackReturn’ does not name a type
32 | CallbackReturn RRBotSystemWithSensorHardware::on_init(const hardware_interface::HardwareInfo & info)
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp: In member function ‘virtual std::vector<hardware_interface::StateInterface> ros2_control_demo_hardware::RRBotModularJoint::export_state_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:93:5: error: ‘info_’ was not declared in this scope
93 |     info_.joints[0].name, hardware_interface::HW_IF_POSITION, &hw_joint_state_));
|     ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:94:1: error: ‘CallbackReturn’ does not name a type
94 | CallbackReturn RRBotSystemWithSensorHardware::on_configure(
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp: In member function ‘virtual std::vector<hardware_interface::CommandInterface> ros2_control_demo_hardware::RRBotModularJoint::export_command_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:103:5: error: ‘info_’ was not declared in this scope
103 |     info_.joints[0].name, hardware_interface::HW_IF_POSITION, &hw_joint_command_));
|     ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp: In member function ‘virtual std::vector<hardware_interface::StateInterface> ros2_control_demo_hardware::RRBotSystemWithSensorHardware::export_state_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:125:24: error: ‘info_’ was not declared in this scope
125 |   for (uint i = 0; i < info_.joints.size(); i++)
|                        ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:32:1: error: ‘CallbackReturn’ does not name a type
32 | CallbackReturn ExternalRRBotForceTorqueSensorHardware::on_init(
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp: At global scope:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:108:1: error: ‘CallbackReturn’ does not name a type
108 | CallbackReturn RRBotModularJoint::on_activate(const rclcpp_lifecycle::State & /previous_state/)
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:132:24: error: ‘info_’ was not declared in this scope
132 |   for (uint i = 0; i < info_.sensors[0].state_interfaces.size(); i++)
|                        ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:132:1: error: ‘CallbackReturn’ does not name a type
132 | CallbackReturn RRBotModularJoint::on_deactivate(const rclcpp_lifecycle::State & /previous_state/)
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp: In member function ‘virtual std::vector<hardware_interface::StateInterface> ros2_control_demo_hardware::ExternalRRBotForceTorqueSensorHardware::export_state_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:58:24: error: ‘info_’ was not declared in this scope
58 |   for (uint i = 0; i < info_.sensors[0].state_interfaces.size(); i++)
|                        ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp: At global scope:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:67:1: error: ‘CallbackReturn’ does not name a type
67 | CallbackReturn ExternalRRBotForceTorqueSensorHardware::on_activate(
| ^~~~~~~~~~~~~~
In file included from /opt/ros/foxy/include/rclcpp/client.hpp:40,
from /opt/ros/foxy/include/rclcpp/callback_group.hpp:23,
from /opt/ros/foxy/include/rclcpp/any_executable.hpp:20,
from /opt/ros/foxy/include/rclcpp/memory_strategy.hpp:24,
from /opt/ros/foxy/include/rclcpp/memory_strategies.hpp:18,
from /opt/ros/foxy/include/rclcpp/executor_options.hpp:20,
from /opt/ros/foxy/include/rclcpp/executor.hpp:33,
from /opt/ros/foxy/include/rclcpp/executors/multi_threaded_executor.hpp:26,
from /opt/ros/foxy/include/rclcpp/executors.hpp:21,
from /opt/ros/foxy/include/rclcpp/rclcpp.hpp:146,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:29:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp: In member function ‘virtual hardware_interface::return_type ros2_control_demo_hardware::RRBotModularJoint::read()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:158:5: error: ‘info_’ was not declared in this scope
158 |     info_.joints[0].name.c_str());
|     ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp: In member function ‘virtual std::vector<hardware_interface::CommandInterface> ros2_control_demo_hardware::RRBotSystemWithSensorHardware::export_command_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:145:24: error: ‘info_’ was not declared in this scope
145 |   for (uint i = 0; i < info_.joints.size(); i++)
|                        ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:89:1: error: ‘CallbackReturn’ does not name a type
89 | CallbackReturn ExternalRRBotForceTorqueSensorHardware::on_deactivate(
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp: At global scope:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:154:1: error: ‘CallbackReturn’ does not name a type
154 | CallbackReturn RRBotSystemWithSensorHardware::on_activate(
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp: In member function ‘virtual hardware_interface::return_type ros2_control_demo_hardware::RRBotModularJoint::write()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:174:5: error: ‘info_’ was not declared in this scope
174 |     info_.joints[0].name.c_str());
|     ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:186:1: error: ‘CallbackReturn’ does not name a type
186 | CallbackReturn RRBotSystemWithSensorHardware::on_deactivate(
| ^~~~~~~~~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp: In member function ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::on_init(const hardware_interface::HardwareInfo&)’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:31:44: error: ‘on_init’ is not a member of ‘hardware_interface::SystemInterface’
31 |   if (hardware_interface::SystemInterface::on_init(info) != CallbackReturn::SUCCESS)
|                                            ^~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:37:24: error: ‘info_’ was not declared in this scope; did you mean ‘info’?
37 |   hw_start_sec_ = stod(info_.hardware_parameters["example_param_hw_start_duration_sec"]);
|                        ^~~~~
|                        info
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:37:19: error: ‘stod’ was not declared in this scope; did you mean ‘std::cxx11::stod’?
37 |   hw_start_sec = stod(info.hardware_parameters["example_param_hw_start_duration_sec"]);
|                   ^~~~
|                   std::cxx11::stod
In file included from /usr/include/c++/9/string:55,
from /usr/include/c++/9/stdexcept:39,
from /usr/include/c++/9/array:39,
from /usr/include/c++/9/tuple:39,
from /usr/include/c++/9/bits/unique_ptr.h:37,
from /usr/include/c++/9/memory:80,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:18,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:15:
/usr/include/c++/9/bits/basic_string.h:6642:3: note: ‘std::cxx11::stod’ declared here
6642 |   stod(const wstring& str, size_t* idx = 0)
|   ^~~~
In file included from /opt/ros/foxy/include/rclcpp/client.hpp:40,
from /opt/ros/foxy/include/rclcpp/callback_group.hpp:23,
from /opt/ros/foxy/include/rclcpp/any_executable.hpp:20,
from /opt/ros/foxy/include/rclcpp/memory_strategy.hpp:24,
from /opt/ros/foxy/include/rclcpp/memory_strategies.hpp:18,
from /opt/ros/foxy/include/rclcpp/executor_options.hpp:20,
from /opt/ros/foxy/include/rclcpp/executor.hpp:33,
from /opt/ros/foxy/include/rclcpp/executors/multi_threaded_executor.hpp:26,
from /opt/ros/foxy/include/rclcpp/executors.hpp:21,
from /opt/ros/foxy/include/rclcpp/rclcpp.hpp:146,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:28:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp: In member function ‘virtual hardware_interface::return_type ros2_control_demo_hardware::RRBotSystemWithSensorHardware::read()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:231:29: error: ‘info’ was not declared in this scope
231 |       hw_sensor_states[i], info.sensors[0].state_interfaces[i].name.c_str());
|                             ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp: In member function ‘virtual std::vector<hardware_interface::StateInterface> ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::export_state_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:119:24: error: ‘info’ was not declared in this scope
119 |   for (uint i = 0; i < info.joints.size(); i++)
|                        ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp: In member function ‘ros2_control_demo_hardware::CallbackReturn ros2_control_demo_hardware::DiffBotSystemHardware::on_init(const hardware_interface::HardwareInfo&)’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:31:44: error: ‘on_init’ is not a member of ‘hardware_interface::SystemInterface’
31 |   if (hardware_interface::SystemInterface::on_init(info) != CallbackReturn::SUCCESS)
|                                            ^~~~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp: In member function ‘virtual std::vector<hardware_interface::CommandInterface> ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware::export_command_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:132:24: error: ‘info’ was not declared in this scope
132 |   for (uint i = 0; i < info.joints.size(); i++)
|                        ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:41:29: error: ‘info’ was not declared in this scope; did you mean ‘info’?
41 |   hw_start_sec_ = std::stod(info_.hardware_parameters["example_param_hw_start_duration_sec"]);
|                             ^~~~~
|                             info
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp: In member function ‘virtual std::vector<hardware_interface::StateInterface> ros2_control_demo_hardware::DiffBotSystemHardware::export_state_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:105:25: error: ‘info_’ was not declared in this scope
105 |   for (auto i = 0u; i < info_.joints.size(); i++)
|                         ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp: In member function ‘virtual std::vector<hardware_interface::CommandInterface> ros2_control_demo_hardware::DiffBotSystemHardware::export_command_interfaces()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:119:25: error: ‘info_’ was not declared in this scope
119 |   for (auto i = 0u; i < info_.joints.size(); i++)
|                         ^~~~~
In file included from /opt/ros/foxy/include/rclcpp/client.hpp:40,
from /opt/ros/foxy/include/rclcpp/callback_group.hpp:23,
from /opt/ros/foxy/include/rclcpp/any_executable.hpp:20,
from /opt/ros/foxy/include/rclcpp/memory_strategy.hpp:24,
from /opt/ros/foxy/include/rclcpp/memory_strategies.hpp:18,
from /opt/ros/foxy/include/rclcpp/executor_options.hpp:20,
from /opt/ros/foxy/include/rclcpp/executor.hpp:33,
from /opt/ros/foxy/include/rclcpp/executors/multi_threaded_executor.hpp:26,
from /opt/ros/foxy/include/rclcpp/executors.hpp:21,
from /opt/ros/foxy/include/rclcpp/rclcpp.hpp:146,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:25:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp: In member function ‘virtual hardware_interface::return_type ros2_control_demo_hardware::DiffBotSystemHardware::read()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:199:26: error: ‘info_’ was not declared in this scope
199 |       hw_velocities_[i], info_.joints[i].name.c_str());
|                          ^~~~~
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp: In member function ‘virtual hardware_interface::return_type ros2_control_demo_hardware::DiffBotSystemHardware::write()’:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:231:7: error: ‘info_’ was not declared in this scope
231 |       info_.joints[i].name.c_str());
|       ^~~~~
In file included from /opt/ros/foxy/include/class_loader/class_loader_core.hpp:57,
from /opt/ros/foxy/include/class_loader/class_loader.hpp:55,
from /opt/ros/foxy/include/pluginlib/class_list_macros.hpp:40,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:259:
/opt/ros/foxy/include/class_loader/meta_object.hpp: In instantiation of ‘B* class_loader::impl::MetaObject<C, B>::create() const [with C = ros2_control_demo_hardware::RRBotSystemWithSensorHardware; B = hardware_interface::SystemInterface]’:
/opt/ros/foxy/include/class_loader/meta_object.hpp:216:7:   required from here
/opt/ros/foxy/include/class_loader/meta_object.hpp:218:12: error: invalid new-expression of abstract class type ‘ros2_control_demo_hardware::RRBotSystemWithSensorHardware’
218 |     return new C;
|            ^~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:19:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:38:7: note:   because the following virtual functions are pure within ‘ros2_control_demo_hardware::RRBotSystemWithSensorHardware’:
38 | class RRBotSystemWithSensorHardware : public hardware_interface::SystemInterface
|       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_with_sensor.hpp:28,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_with_sensor.cpp:19:
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:48:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::configure(const hardware_interface::HardwareInfo&)’
48 |   virtual return_type configure(const HardwareInfo & system_info) = 0;
|                       ^~~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:116:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::start()’
116 |   virtual return_type start() = 0;
|                       ^~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:122:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::stop()’
122 |   virtual return_type stop() = 0;
|                       ^~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:128:23: note:     ‘virtual std::string hardware_interface::SystemInterface::get_name() const’
128 |   virtual std::string get_name() const = 0;
|                       ^~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:134:18: note:     ‘virtual hardware_interface::status hardware_interface::SystemInterface::get_status() const’
134 |   virtual status get_status() const = 0;
|                  ^~~~~~~~~~
In file included from /opt/ros/foxy/include/class_loader/class_loader_core.hpp:57,
from /opt/ros/foxy/include/class_loader/class_loader.hpp:55,
from /opt/ros/foxy/include/pluginlib/class_list_macros.hpp:40,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:135:
/opt/ros/foxy/include/class_loader/meta_object.hpp: In instantiation of ‘B* class_loader::impl::MetaObject<C, B>::create() const [with C = ros2_control_demo_hardware::ExternalRRBotForceTorqueSensorHardware; B = hardware_interface::SensorInterface]’:
/opt/ros/foxy/include/class_loader/meta_object.hpp:216:7:   required from here
/opt/ros/foxy/include/class_loader/meta_object.hpp:218:12: error: invalid new-expression of abstract class type ‘ros2_control_demo_hardware::ExternalRRBotForceTorqueSensorHardware’
218 |     return new C;
|            ^~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:19:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/external_rrbot_force_torque_sensor.hpp:37:7: note:   because the following virtual functions are pure within ‘ros2_control_demo_hardware::ExternalRRBotForceTorqueSensorHardware’:
37 | class ExternalRRBotForceTorqueSensorHardware : public hardware_interface::SensorInterface
|       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/external_rrbot_force_torque_sensor.hpp:28,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/external_rrbot_force_torque_sensor.cpp:19:
/opt/ros/foxy/include/hardware_interface/sensor_interface.hpp:47:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SensorInterface::configure(const hardware_interface::HardwareInfo&)’
47 |   virtual return_type configure(const HardwareInfo & sensor_info) = 0;
|                       ^~~~~~~~~
/opt/ros/foxy/include/hardware_interface/sensor_interface.hpp:64:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SensorInterface::start()’
64 |   virtual return_type start() = 0;
|                       ^~~~~
/opt/ros/foxy/include/hardware_interface/sensor_interface.hpp:70:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SensorInterface::stop()’
70 |   virtual return_type stop() = 0;
|                       ^~~~
/opt/ros/foxy/include/hardware_interface/sensor_interface.hpp:76:23: note:      ‘virtual std::string hardware_interface::SensorInterface::get_name() const’
76 |   virtual std::string get_name() const = 0;
|                       ^~~~~~~~
/opt/ros/foxy/include/hardware_interface/sensor_interface.hpp:82:18: note:      ‘virtual hardware_interface::status hardware_interface::SensorInterface::get_status() const’
82 |   virtual status get_status() const = 0;
|                  ^~~~~~~~~~
In file included from /opt/ros/foxy/include/class_loader/class_loader_core.hpp:57,
from /opt/ros/foxy/include/class_loader/class_loader.hpp:55,
from /opt/ros/foxy/include/pluginlib/class_list_macros.hpp:40,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:184:
/opt/ros/foxy/include/class_loader/meta_object.hpp: In instantiation of ‘B* class_loader::impl::MetaObject<C, B>::create() const [with C = ros2_control_demo_hardware::RRBotModularJoint; B = hardware_interface::ActuatorInterface]’:
/opt/ros/foxy/include/class_loader/meta_object.hpp:216:7:   required from here
/opt/ros/foxy/include/class_loader/meta_object.hpp:218:12: error: invalid new-expression of abstract class type ‘ros2_control_demo_hardware::RRBotModularJoint’
218 |     return new C;
|            ^~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:19:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_actuator.hpp:38:7: note:   because the following virtual functions are pure within ‘ros2_control_demo_hardware::RRBotModularJoint’:
38 | class RRBotModularJoint : public hardware_interface::ActuatorInterface
|       ^~~~~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_actuator.hpp:26,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_actuator.cpp:19:
/opt/ros/foxy/include/hardware_interface/actuator_interface.hpp:46:23: note:    ‘virtual hardware_interface::return_type hardware_interface::ActuatorInterface::configure(const hardware_interface::HardwareInfo&)’
46 |   virtual return_type configure(const HardwareInfo & actuator_info) = 0;
|                       ^~~~~~~~~
/opt/ros/foxy/include/hardware_interface/actuator_interface.hpp:113:23: note:   ‘virtual hardware_interface::return_type hardware_interface::ActuatorInterface::start()’
113 |   virtual return_type start() = 0;
|                       ^~~~~
/opt/ros/foxy/include/hardware_interface/actuator_interface.hpp:119:23: note:   ‘virtual hardware_interface::return_type hardware_interface::ActuatorInterface::stop()’
119 |   virtual return_type stop() = 0;
|                       ^~~~
/opt/ros/foxy/include/hardware_interface/actuator_interface.hpp:125:23: note:   ‘virtual std::string hardware_interface::ActuatorInterface::get_name() const’
125 |   virtual std::string get_name() const = 0;
|                       ^~~~~~~~
/opt/ros/foxy/include/hardware_interface/actuator_interface.hpp:131:18: note:   ‘virtual hardware_interface::status hardware_interface::ActuatorInterface::get_status() const’
131 |   virtual status get_status() const = 0;
|                  ^~~~~~~~~~
In file included from /opt/ros/foxy/include/class_loader/class_loader_core.hpp:57,
from /opt/ros/foxy/include/class_loader/class_loader.hpp:55,
from /opt/ros/foxy/include/pluginlib/class_list_macros.hpp:40,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:229:
/opt/ros/foxy/include/class_loader/meta_object.hpp: In instantiation of ‘B* class_loader::impl::MetaObject<C, B>::create() const [with C = ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware; B = hardware_interface::SystemInterface]’:
/opt/ros/foxy/include/class_loader/meta_object.hpp:216:7:   required from here
/opt/ros/foxy/include/class_loader/meta_object.hpp:218:12: error: invalid new-expression of abstract class type ‘ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware’
218 |     return new C;
|            ^~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:15:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:35:7: note:   because the following virtual functions are pure within ‘ros2_control_demo_hardware::RRBotSystemPositionOnlyHardware’:
35 | class RRBotSystemPositionOnlyHardware : public hardware_interface::SystemInterface
|       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:24,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_position_only.cpp:15:
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:48:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::configure(const hardware_interface::HardwareInfo&)’
48 |   virtual return_type configure(const HardwareInfo & system_info) = 0;
|                       ^~~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:116:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::start()’
116 |   virtual return_type start() = 0;
|                       ^~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:122:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::stop()’
122 |   virtual return_type stop() = 0;
|                       ^~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:128:23: note:     ‘virtual std::string hardware_interface::SystemInterface::get_name() const’
128 |   virtual std::string get_name() const = 0;
|                       ^~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:134:18: note:     ‘virtual hardware_interface::status hardware_interface::SystemInterface::get_status() const’
134 |   virtual status get_status() const = 0;
|                  ^~~~~~~~~~
In file included from /opt/ros/foxy/include/class_loader/class_loader_core.hpp:57,
from /opt/ros/foxy/include/class_loader/class_loader.hpp:55,
from /opt/ros/foxy/include/pluginlib/class_list_macros.hpp:40,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:338:
/opt/ros/foxy/include/class_loader/meta_object.hpp: In instantiation of ‘B* class_loader::impl::MetaObject<C, B>::create() const [with C = ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware; B = hardware_interface::SystemInterface]’:
/opt/ros/foxy/include/class_loader/meta_object.hpp:216:7:   required from here
/opt/ros/foxy/include/class_loader/meta_object.hpp:218:12: error: invalid new-expression of abstract class type ‘ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware’
218 |     return new C;
|            ^~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:15:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_multi_interface.hpp:40:7: note:   because the following virtual functions are pure within ‘ros2_control_demo_hardware::RRBotSystemMultiInterfaceHardware’:
40 | class RRBotSystemMultiInterfaceHardware : public hardware_interface::SystemInterface
|       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_multi_interface.hpp:26,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/rrbot_system_multi_interface.cpp:15:
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:48:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::configure(const hardware_interface::HardwareInfo&)’
48 |   virtual return_type configure(const HardwareInfo & system_info) = 0;
|                       ^~~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:116:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::start()’
116 |   virtual return_type start() = 0;
|                       ^~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:122:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::stop()’
122 |   virtual return_type stop() = 0;
|                       ^~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:128:23: note:     ‘virtual std::string hardware_interface::SystemInterface::get_name() const’
128 |   virtual std::string get_name() const = 0;
|                       ^~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:134:18: note:     ‘virtual hardware_interface::status hardware_interface::SystemInterface::get_status() const’
134 |   virtual status get_status() const = 0;
|                  ^~~~~~~~~~
make[2]: *** [CMakeFiles/ros2_control_demo_hardware.dir/build.make:102: CMakeFiles/ros2_control_demo_hardware.dir/src/rrbot_system_with_sensor.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /opt/ros/foxy/include/class_loader/class_loader_core.hpp:57,
from /opt/ros/foxy/include/class_loader/class_loader.hpp:55,
from /opt/ros/foxy/include/pluginlib/class_list_macros.hpp:40,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:241:
/opt/ros/foxy/include/class_loader/meta_object.hpp: In instantiation of ‘B* class_loader::impl::MetaObject<C, B>::create() const [with C = ros2_control_demo_hardware::DiffBotSystemHardware; B = hardware_interface::SystemInterface]’:
/opt/ros/foxy/include/class_loader/meta_object.hpp:216:7:   required from here
/opt/ros/foxy/include/class_loader/meta_object.hpp:218:12: error: invalid new-expression of abstract class type ‘ros2_control_demo_hardware::DiffBotSystemHardware’
218 |     return new C;
|            ^~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:15:
/home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/diffbot_system.hpp:38:7: note:   because the following virtual functions are pure within ‘ros2_control_demo_hardware::DiffBotSystemHardware’:
38 | class DiffBotSystemHardware : public hardware_interface::SystemInterface
|       ^~~~~~~~~~~~~~~~~~~~~
In file included from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/diffbot_system.hpp:24,
from /home/usr/ros2_control_test/src/ros2_control_demos/ros2_control_demo_hardware/src/diffbot_system.cpp:15:
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:48:23: note:      ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::configure(const hardware_interface::HardwareInfo&)’
48 |   virtual return_type configure(const HardwareInfo & system_info) = 0;
|                       ^~~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:116:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::start()’
116 |   virtual return_type start() = 0;
|                       ^~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:122:23: note:     ‘virtual hardware_interface::return_type hardware_interface::SystemInterface::stop()’
122 |   virtual return_type stop() = 0;
|                       ^~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:128:23: note:     ‘virtual std::string hardware_interface::SystemInterface::get_name() const’
128 |   virtual std::string get_name() const = 0;
|                       ^~~~~~~~
/opt/ros/foxy/include/hardware_interface/system_interface.hpp:134:18: note:     ‘virtual hardware_interface::status hardware_interface::SystemInterface::get_status() const’
134 |   virtual status get_status() const = 0;
|                  ^~~~~~~~~~
make[2]: *** [CMakeFiles/ros2_control_demo_hardware.dir/build.make:115: CMakeFiles/ros2_control_demo_hardware.dir/src/rrbot_actuator.cpp.o] Error 1
make[2]: *** [CMakeFiles/ros2_control_demo_hardware.dir/build.make:128: CMakeFiles/ros2_control_demo_hardware.dir/src/external_rrbot_force_torque_sensor.cpp.o] Error 1
make[2]: *** [CMakeFiles/ros2_control_demo_hardware.dir/build.make:76: CMakeFiles/ros2_control_demo_hardware.dir/src/rrbot_system_position_only.cpp.o] Error 1
make[2]: *** [CMakeFiles/ros2_control_demo_hardware.dir/build.make:89: CMakeFiles/ros2_control_demo_hardware.dir/src/rrbot_system_multi_interface.cpp.o] Error 1
make[2]: *** [CMakeFiles/ros2_control_demo_hardware.dir/build.make:63: CMakeFiles/ros2_control_demo_hardware.dir/src/diffbot_system.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:78: CMakeFiles/ros2_control_demo_hardware.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
Failed   <<< ros2_control_demo_hardware [7.45s, exited with code 2]
Summary: 3 packages finished [7.55s]
1 package failed: ros2_control_demo_hardware
1 package had stderr output: ros2_control_demo_hardware
2 packages not processed

Sorry, I'm not familar with blanch operation.
Following video solved my problem.
https://www.youtube.com/watch?v=1MWIkTLEXlw


Update privacy policy

A few changes to incorporate:

updated information on IP address collection
updated contact information

Still waiting to confirm other content change—should have it in tonight.

@timarney @dsamojlenko FYI, we're good.

Thanks Dave for fixing a typo in this! #831


⚠ Bofrost.at has degraded performance

In 9c282ab, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1889 ms

Resolved: Bofrost.at performance has improved in 8cb9528.


Multiple ResponseDescriptors seems to be confusing response object mapping

Consider a data model with two managed objects: ObjectA and ObjectB.
I have setup the routes as follows-
[objectManager.router.routeSet addRoute:[RKRoute routeWithClass:[ObjectA class] pathPattern:@"object_a/" method:RKRequestMethodPOST]];
[objectManager.router.routeSet addRoute:[RKRoute routeWithClass:[ObjectB class] pathPattern:@"object_b/" method:RKRequestMethodPOST]];

The request/response descriptors as setup as follows-
For ObjectA
[objectManager addRequestDescriptor:[RKRequestDescriptor
                                     requestDescriptorWithMapping:[ObjectA objectARequestMappingForRKPOST]
                                     objectClass:[ObjectA class]
                                     rootKeyPath:nil
                                     method:RKRequestMethodPOST]];
[objectManager addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:[ObjectA objectAResponseMappingForRKPOST]
                                                                                method:RKRequestMethodPOST
                                                                             pathPattern:nil
                                                                                keyPath:nil
                                                                             statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]];

For ObjectB
[objectManager addRequestDescriptor:[RKRequestDescriptor
                                     requestDescriptorWithMapping:[ObjectB objectBRequestMappingForRKPOST]
                                     objectClass:[ObjectB class]
                                     rootKeyPath:nil
                                     method:RKRequestMethodPOST]];
[objectManager addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:[ObjectB objectBResponseMappingForRKPOST]
                                                                                method:RKRequestMethodPOST
                                                                             pathPattern:nil
                                                                                keyPath:nil
                                                                             statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]];

Now the problem is, if I have only ObjectA's responseDescriptor added to the RKObjectManager, the response to ObjectA's POST response is deserialized and mapped correctly. However, if I add ObjectB's responseDescriptor to RKObjectManager as well, as shown above, then the response to ObjectA's POST response is not deserialized.
Is there a limitation in RestKit that only one responseDescriptor per method can be used in an ObjectManager?

Any updates on this? I'm still having this issue.
Configuring a RKResponseDescriptor with the same pathPattern but two different RKRequestMethods (e.g. POST and GET) will result in the wrong RKResponseDescriptor being selected when the received data is being parsed.


Consider shortening logger names

As discussed in the following PR comments, our logging names are somewhat verbose:
https://github.com/crossplaneio/crossplane/pull/385#discussion_r274086143
https://github.com/crossplaneio/crossplane/pull/385#discussion_r274089142
e.g. controller.account.storage.azure.crossplane.io
We can consider shortening these logger names somehow, without losing the knowledge of what part of the code base each logger belongs to.  The rook project uses abbreviated names instead of fully qualified type names, such as edgefs-op-cluster.

I like the idea of copying the controller-runtime pattern in which the loggers are named simply crossplane.controller, but have a value with the controller name. For example:
# A Crossplane log
2019-06-25T18:58:11.560Z        DEBUG   crossplane.controller   Reconciling     {"controller": "resourceclaim.crossplane.io", "request": "default/ekscluster"}

# A controller-runtime log
2019-06-25T18:58:11.065Z        DEBUG   kubebuilder.controller  Successfully Reconciled {"controller": "kubernetescluster.eks.compute.aws.crossplane.io", "request": "default/ekscluster"}


Storage blob data reader permission is not enough to use go sdk:NewListBlobsHierarchyPager to list blobs and prefixes, but works with rest api

We are using go sdk to list and read azure blobs. For our use case, we need to get list of first level subfolders and blobs in a given path (or root).
For this we assigned the role "Storage blob data reader" role to our AAD app.
To get first level folders and blob we are using NewListBlobsHierarchyPager. It fails with the error: "This request is not authorized to perform this operation using this permission".
If we give Storage blob data contributor", it works. Which we cannot ask our customer to give this permission.
We do not want to use NewListBlobsFlatPager, as it will list all folders and files recursively. This option works with reader permissions.
We tried REST API with delimiter option, and it worked with reader permission. The api is: https://.blob.core.windows.net/?restype=container&comp=list&delimiter=/ This api is equivalent to NewListBlobsHierarchyPager.
REST API works but go code is not working for hierarchical listing.

@PD-Pramila
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!

@PD-Pramila
Thanks for sharing the feedback. Since this channel is for driving improvements towards Docs, could you please provide the URL of the specific documentation that your feedback is applicable to? That way, we can make sure your feedback is addressed by the right team.

@PD-Pramila
Thanks for your feedback and your contribution to Azure docs.
Feedback for this repository is moving away from GitHub to a system specific to the Microsoft Learn platform. Issues for this repository will soon be disabled, and additional comments from GitHub will no longer be possible. However, we are now tracking and triaging this issue in the new feedback system.
To learn more about our feedback systems, please see Provide feedback for Microsoft Learn content.

@PD-Pramila
We are going to close this thread, if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

Thanks for checking it. It was the issue with the tags. When we include tags in file listing, it needs for owner's permission.


Allow for lowercase commit parameters

the PR does not contain any changes, can be closed?

i do not see it anymore on my list. It was superceded by #19 as far as i know


WIP: Add example contribution

Contributed yolo_v2_tiny as an example. The contribution includes an
example inference pipeline using TVM.
depends on https://github.com/autowarefoundation/modelzoo/pull/2

@sgermanserrano need some help pushing some binaries to this PR.

@LiyouZhou
Hi, I'm from TierIV perception team.
We are currently developing tvm based lidar obstacle detection and here is a sample ros node.
https://github.com/tier4/lidar_instance_segmentation_tvm
Currently, tvm inference files are generated by our own script from pytorch model, but I want to much it with the modelzoo inference pipeline format.
I think we can help you.

@taichiH Would love to have more contributions in this space. Would you like to have a chat and see where we can collaborate? If you don't mind, can you send an email to<EMAIL_ADDRESS>so we can set something up?

@JWhitleyWork do you have any experience with applying license for the pre-trained weights? The data license is clear, but what should we use for the trained model files?

@LiyouZhou Our default is Apache 2.0 and I think that's probably fine for the weights files too. It's almost as permissive as MIT but has more legal-eze.

Oops. I just realized this was still listed as WIP. Sorry about that.
On another note: https://hub.docker.com/r/autoware/model-zoo-tvm-cli/tags

@JWhitleyWork No worries, we will add more stuff in a following PR. Thank you for reviewing.

Oops. I just realized this was still listed as WIP. Sorry about that.
On another note: https://hub.docker.com/r/autoware/model-zoo-tvm-cli/tags

Fantastic!


Break up complexity of a single ods-inputoptions component

Issue report
Your issue may already be reported! Please search on the issue tracker before creating one.
Expected Behavior

Input radio and checkboxes are separate components
A wrapper component that allows only a single radio button to be selected at once
The visible design and interactions remain the same as the current ods-inputoptions

Current Behavior

The single ods-inputoptions is a fairly complex component and exposes properties that compose multiple HTML input properties.

Possible Solution

Break out checkbox and radio with label into separate components. Radio elements should be groupable.
Create wrapper component that allows access to HTML input properties.

Context

This change should allow input options to be a controlled component from React (i.e. allow the outer application to manage the state of the input radio/checkboxes)

References

@polymer/paper-radio-group
@polymer/paper-radio-button
@polymer/paper-checkbox
input/radio

It should be noted that the new work related to this issue will mean the creation of two new components. One for the individual radio/checkbox input and then a component wrapper.
This initial ods-inputoptions will be deprecated and soon removed from the Orion component library.

oops


Use CSS modules for Avatar Component.

Please refer to the guide to use CSS modules.

I would like to work on this issue.

I would like to work on this issue.


Uninstall process leaves files behind

Following the documentation for the uninstall process, all the Kubernetes objects are removed, but lots of files are left behind the process on every single Node. The uninstall process should take care about these files and removed them.
[root@ip-10-20-1-55 oneagent]# pwd
/opt/dynatrace/oneagent
[root@ip-10-20-1-55 oneagent]# du -hs .
894M	.
[root@ip-10-20-1-55 oneagent]# find ./ | wc -l
4460

Hi @makentenza,
The uninstall process leaves OneAgent binaries and configs in the filesystem in an inactive state. This is expected behavior. If you want to purge all OneAgent leftovers, please follow the instructions in our documentation.
https://www.dynatrace.com/support/help/cloud-platforms/openshift/full-stack/operation/uninstall-oneagent-from-openshift/

Closing, as this is a desired behavior.


bfvm: signed operations

this pull request adds signed operations and thus makes bfvm compatible with v1.5.3.

Codecov Report

Merging #121 (8f4162e) into master (b7610bf) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #121   +/-   ##
=======================================
  Coverage   84.95%   84.95%
=======================================
  Files           7        7
  Lines         977      977
=======================================
  Hits          830      830
  Misses        147      147

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7610bf...8f4162e. Read the comment docs.


Throughput of BBR is lower than Cubic with high loss

Hi alls,
I evaluate performance of BRR and Cubic in the context of video streaming with lsquic. I set rtt to 100ms. Then I change loss from 0 to 30%. Topo is client-switch-server.
With 0% loss, average throughput of BRR and Cubic are 6.494 and 6.412 mbps.
When loss is set to 20%, average throughput of BRR and Cubic are 1.349 and 0.391.
When loss is increased to 30%, Cubic outperforms BBR related to average throughput.
When loss is less than 20%, BBR can effectively utilize available bandwidth.
Do anybody know why?
When I see in the source code of bbr, I found this one in calculate_pacing_rate() function:
// Slow the pacing rate in STARTUP by the bytes_lost / CWND.
if (startup_rate_reduction_multiplier_ != 0
        && has_ever_detected_loss
            && (bbr->bbr_flags & BBR_FLAG_HAS_NON_APP_LIMITED))
{
    bbr->bbr_pacing_rate = BW_TIMES(&target_rate,
        (1 - (bbr->bbr_startup_bytes_lost
                * startup_rate_reduction_multiplier_ * 1.0f
                    / bbr->bbr_cwnd_gain)));
    // Ensure the pacing rate doesn't drop below the startup growth target
    // times  the bandwidth estimate.
    if (BW_VALUE(&bbr->bbr_pacing_rate)
                                    < BW_VALUE(&bw) * kStartupGrowthTarget)
        bbr->bbr_pacing_rate = BW_TIMES(&bw, kStartupGrowthTarget);
    return;
}

When there is loss, pacing rate is reduced by the bytes_lost / CWND. Is it the reason for the performance reduction of BBR?
Thank you in advance!
Best regards,
Van

The cut-off at around 20% is an intentional BBR setting: it needs to stop blasting the packets away at some point.  I can't find a reference to where they talk about it in the docs, but the information is out there on the web/newsgropus/YouTube somewhere.

After I create this issue, I found some documents explaining this. This is due to the pacing gain array [1.25, 0.75, 1, 1, 1, 1, 1, 1] and no consideration of loss signal.
Why don't they change the pacing gain adaptively corresponding to different network conditions?

20% is a very high loss ratio.  You should adjust your expectations instead.

Thank you very much.


vector: insns: vgmul: Remote vs1 from mnemonic

vgmul.vv has only two operands.
Let's eliminate the "vs1" from the mnemonic.

LGTM, but isn't the instruction description strictly identic to the new vghsh instruction ?


MRG, FIX: parallel n_jobs check

This fails on master, and passes on this PR:
import numpy as np
import mne
mne.parallel.check_n_jobs(np.int64(6))

strangely, I was definitely passing in a plain int, not a numpy type, so n_jobs must have been recast somewhere in between my call to mne.time_frequency.psd_multitaper and the eventual check.  If it's important to dig in and figure out where/why that happened, LMK.
I didn't see a file mne/tests/test_parallel.py... do we not test the parallel capabilities?

@agramfort CIs are green, this one is ready

thx @drammock

backported


Adds simple bool condition optimization

This change introduces simple boolean condition optimization when dealing with boolean and, or, and == expressions to help trim unnecessary AST nodes.

Another think to optimize:
all(list, predicate_a) && all(list, predicate_b)

to
all(list, predicate_a && predicate_b)

That could be interesting.  A quick investigation shows that'd look like:
# from: `all(input, {# startsWith "scan"}) and all(input, {len(#) > 3})`

BinaryNode:
  Operator: "and"
  Left:
    BuiltinNode:
      Name: "all"
      Arguments:
        - IdentifierNode: { Value: "input" }
        - ClosureNode:
            Node:
              BinaryNode:
                Operator: "startsWith"
                  Left:
                    PointerNode: {}
                  Right:
                    StringNode: { Value: "scan" }
  Right:
    BuiltinNode:
      Name: "all"
      Arguments:
        - IdentifierNode: { Value: "input" }
        - ClosureNode:
            Node:
              BinaryNode:
                Operator: ">"
                  Left:
                    BuiltinNode:
                      Arguments:
                        - PointerNode: {}
                  Right:
                    IntegerNode: { Value: 3 }

and the output would be:
BuiltinNode:
  Name: "all"
  Arguments:
    - IdentifierNode: { Value: "input" }
    - ClosureNode:
        Node:
          BinaryNode:
            Operator: "and"
            Left:
              BinaryNode:
                Operator: "startsWith"
                Left:
                  PointerNode: {}
                Right:
                  StringNode: { Value: "scan" }
            Right:
              BinaryNode:
                Operator: ">"
                Left:
                  BuiltinNode:
                    Arguments:
                      - PointerNode: {}
                Right:
                  IntegerNode: { Value: 3 }

Would you be okay with accepting the current work?  I can try to add the and of all and or of any optimizations later.

Sounds good 👍🏻


Run linked commands with &&

It seems risky to have multiple statements in a single RUN instruction.
In this particular example, it's likely that the final step (apt-get install) will fail if one or more earlier steps failed.  But replacing ; with && means that:

build will fail faster if an early step fails
if this pattern is copied elsewhere, we might avoid obscure bugs

Seems to happen in enketo.dockerfile and nginx.dockerfile. Can you make those changes there too?
I also checked *.sh and didn't find any, but double-check.

We didn't get the chance to review this one before regression testing, so I'd lean toward waiting until v2023.1 to merge this.

Ready to merge after resolving conflicts?


Bump Go version in make.sh helper script

What this PR does / why we need it:
See #1007
Which issue this PR fixes(if applicable):
Fixes #1007
Special notes for reviewers:
We could consider adding a argument to pass in the Go-version, not sure how this script is used out there though. I'm using it occasionally.
Release note:
Bump Go version in make.sh helper script

/ok-to-test

can we use Bump Go version to 1.13 in make.sh helper script for more explicit?

Of course, i've changed the release note!

I dont think release note is needed in this case @lingxiankong ?
/lgtm

I dont think release note is needed in this case @lingxiankong ?
/lgtm

I agree @ramineni, considering release notes are required for any pull request with user-visible changes, I will remove this one and merge.

/approve


Bug fix: vote module must be present on remove delgate

🗃 Github Issue Or Explanation for this PR. (What is it supposed to do and Why is needed)
#1275
✅ Checklist

[x] Github issue details are up to date for people to QA.
[x] I have tested all my changes.

🕵♂ Notes for Code Reviewer
Some work and corrections done on delegates tab in order to notify the Vote bloc to refresh their current delegates, if user performs an operation to remove or add delegates.
IMPORTANT:
I also update the flutter_bloc and Equatable dependencies in order to start to migrate our blocs to the new On API. This only enable the new api the old one will keeps woking in with this version,
@n13 @gguijarro-c-chwy @gguij004  However, for new blocs, I encourage you to use the new API.
👯♀ Paired with
"nobody"

@gguij004 I guess this flow is not completed yet right?
Because I don't find a place where the InitOnboardingDelegate be fired.

I should read the PR comments before starting to review lol
IMPORTANT:
I also update the flutter_bloc and Equatable dependencies in order to start to migrate our blocs to the new On API. This only enable the new api the old one will keeps woking in with this version,
@n13 @gguijarro-c-chwy @gguij004 However, for new blocs, I encourage you to use the new API.

pls post in discord about the new pattern


updated chromadb python package to latest (0.4.12) to mitigate error …

Fix addressing this issue
https://github.com/Dataherald/dataherald/issues/174
Upgraded to latest python chromadb package and followed guidelines from official chromadb docs: https://docs.trychroma.com/migration
After update, golden-records can be uploaded to the system without error.
The rest of the operations seems to be working fine as well including /api/v1/question

Thanks @ppmarkus the PR was approved and merged


SwiftFormat

Is there an option to leave initializers for, say, enum cases aligned?

Should be doable with --disable consecutiveSpaces


Woodpecker CI does not work correctly out of the box

Describe the bug
Unstable versions of Woodpecker have been updated to 1.0+ which changes how the software works. It introduces backends (ssh, local, docker, kubernetes).

exec backend as referenced in configuration.nix doesn't exist anymore
local backend seems to need plugin-git (https://github.com/woodpecker-ci/plugin-git which can be built using buildGoPackage -- you can use gitMinimal for the clone part it's lighter than git) and apparently has issues passing the token to clone private repos (haven't investigated further)
daemon needs a configuration file (that can apparently be empty) for some things. I'm not sure if it needs to be writable.

Steps To Reproduce
Steps to reproduce the behavior:

Use services.woodpecker-.package = unstablePkgs.woodpecker-;
Errors out in the logs / the systemd service when started.

Expected behavior
I expected to use upstream package/module to work directly
Additional context

Agent and server must be of the same version otherwise it doesn't work
It makes some non-reversibles migrations to the DB so beware of your DB if you care about it ~

Notify maintainers
@ambroisie @techknowlogick @adamcstephens

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.45, NixOS, 23.05 (Stoat)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.5`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Hi James!
I'd suggest you go look at my configuration to see how to configure Woodpecker, as it should be a pretty good example of setting up multiple agents with different backends.

Indeed, this should be using local instead of exec, this was a typo in the docs.
plugin-git is packaged in nixpkgs already.
I have not had any issues relating to a configuration file, I would advise you to ask this on their matrix channel to discuss it further.

The issue regarding private repositories is not due to NixOS, and should be fixed by this PR.
I'm not sure what issue you have against the current modules as they exist today, but please do provide feedback on what we could improve in our documentation.

Hey!
Will take a look and get back to you shortly with the results.
Thanks for answering quickly!

well private repos + local backend + window still dont work ... as netrc is not parsed on windows by default
also there was just reported regression for linux ... I'll investigate

daemon needs a configuration file

you revere to the agent ... it only has to be writable on first agent run, as it saves the ID the server assign to an agent,
you can change the location with WOODPECKER_AGENT_CONFIG_FILE env var or --agent-config command argument

local backend seems to need plugin-git

yes and for nix, nix should take care of that on its own ... as the pre build binary's might not work here ?

yes and for nix, nix should take care of that on its own ... as the pre build binary's might not work here ?

Yes, e.g. like this: https://github.com/lounge-rocks/the-lounge/blob/89f73ae27fa4141eb5bf7b5de1df7fdcd27ac7f6/modules/woodpecker/local-agent.nix#L61-L62
Since there also is a NixOS modul it might make sense to enable it there. @ambroisie you seem to be maintainer of it, would you consider it useful to add it there? There might be other parts worth porting, e.g. the bindpaths required to allow nix to run in the local backend.

Indeed, this should be using local instead of exec, this was a typo in the docs.
Should be fixed in the example of the module

The modules are kept lightweight and un-opinionated to avoid stepping on anybody's toes when they're trying to setup their own agents.
I don't think it would make sense to make them much more complicated, adding a services.woodpecker-agents.*.path option would be nice, but I'm not looking to make them more complicated than they currently are.
Instead, if you feel like the setup is still non-trivial, I'd recommend documenting how to setup the agents,  like it has been for e.g: the GitLab runners.

And here I got some time to get back to this issue. (Can't believe it's been a month I'm sorry I haven't seen the notifications :x ).
I was about to write some config to add the path you just commited to the repo, 2fast4me. Thank you for all the changes!
Seems that private clone is still not working on my side (I'll work on it again). But having my own private clone works well instead!

Is this still an issue?

Ah, no shouldn't be, thanks for the ping.


Remove obsolete settings in SublimeLinter >=4.12

Various settings were moved from deprecated to obsolete in SublimeLinter v4.12.
These are now removed, and the linter itself cleaned up to not trigger these warnings.

@mliljedahl by the way, once this merges, would you please release a new version (v2.0.0 probably? Since these are breaking for SublimeLinter v3 users) and publish that to PackageControl.io?

Please do pull these changes in, would like to be able to use ansible-lint again in sublime-text.

Yes, someone please fork this project (even if you have to use a new name like SublimeLinter-contrib-ansible-lint2 on packagecontrol.io). @mliljedahl isn't responding to any of these issues and hasn't been seen on GitHub in almost a year now.

@mconigliaro I’ll see what I can do.

I was considering a fork, the template for these has changed the naming to SublimeLinter-[linter name], but I barely know what I am doing.

I’m totally underwater at work right now, so I recommend simply cloning my fork into Sublime Text 3/Packages/, it will override the Package Control-installed version.

Really sorry for not answering and being away for so long! Ill merge this pull request and make a new release.

Great! Thanks so much, @mliljedahl 🙂


Fix permission denied issue on clicking manage account

Description
Currently only .openbeautyfacts.org domain was checked in the code thus the user_session cookie was not set in the app after successful login for any flavor except OBF. Changed the logic to check for BuildConfig.HOST which makes it possible to save the user_session cookies for all the flavors now.
Related issues and discussion
#Fixes #1965
Screen-shots, if any
Checklist
Make sure you've done all the following (You can delete the checklist before submitting)

[x] Apply the AndroidStyle.xml style template to your code in Android Studio.
[x] Code is well documented
[ ] Include unit tests for new functionality
[x] All user-visible strings are made translatable
[ ] Code passes Travis builds in your branch
[x] If you have multiple commits please combine them into one commit by squashing them.
[x] Read and understood the contribution guidelines.

Thanks @ripetrescu @huzaifaiftikhar , merging


notebook for FOP option chain

Building an option chain for futures/indexes seems to be slightly different then for stocks
it would be very helpful if we could have an example

Is there a difference?
lastTradeDateOrContractMonth for futures must be the futures expiration month (currently 202409) which tracks with regular equity options also being able to be fetched as 202407 or 20240719 etc.

of course.
building an option chain for index (ES,MES) futures requires first to
qualify an Index
and  then request ticker for FuturesOption
On Mon, Jul 1, 2024 at 6:13 PM Matt Stancliff @.***>
wrote:

Is there a difference?
lastTradeDateOrContractMonth for futures must be the futures expiration
month (currently 202409) which tracks with regular equity options also
being able to be fetched as 202407 or 20240719 etc.
—
Reply to this email directly, view it on GitHub
https://github.com/ib-api-reloaded/ib_async/issues/38#issuecomment-2200428010,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANWIKNKVEA4QEO3LL2OVKK3ZKFWZJAVCNFSM6AAAAABKFAPBYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQGQZDQMBRGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Ilan Pinto
Manager, Ecosystem Application Engineering
Red Hat https://www.redhat.com/
https://www.redhat.com/

Not sure what the end result is then? You appear to suddenly have the information you asked for already but didn't mention originally.

I guess just remember to communicate in complete sentences with complete thoughts and examples.
Creating multiple issues of sentence fragments with partial ideas as tickets doesn't really help anybody (and we don't have the resources to act as a private project management system for everybody to dump tasks on expecting uncompensated maintainers to work on requests for free).

of course. building an option chain for index (ES,MES) futures requires first to qualify an Index and then request ticker for FuturesOption

Wow, thank you - this fixed a nearly impossible-to-debug bug I've been seeing. IBKR's TWS documentation says to qualify the Future, which is what I've been doing. But it really should be the Index. This is true for /ES, /CL, any other commodities futures. The option's underlying is the future, the future's underlying is the index, yet the options are children of the index, not the future...
I don't know if another notebook is needed for FOPs. https://github.com/ib-api-reloaded/ib_async/blob/main/notebooks/option_chain.ipynb pretty much covers it; it even qualifies the Index the requests the chain. Maybe just adding text to clarify that commodities options chains are found by the commodities index, not by the futures contract that is underlying the option chain. Their symbols are "CL IND" and "ES IND".

not sure i follow, the example on the notebook is for index options
@ilan-pinto  could you post an example?

it even qualifies the Index the requests the chain.

Well, it does, but also it doesn't.
The notebook is looking up SPX options, but SPX options SPXW options and /ES and /MES options are different instruments.
Looking up index expirations works fine just by combining a symbol name with a correct lastTradeDateOrContractMonth value using regular details.
I couldn't get any lookup to work with Index contracts themselves, but regular OPT options work with just Stock(symbol, "SMART") lookups (FOP options lookups require the exchange to be specified).
The reqSecDefOptParams() works different from the regular reqContractDetails() though.
reqSecDefOptParams() has benefits and drawbacks:

benefit: it's faster, because reqSecDefOptParams() is a direct lookup of a single instrument using (name, exchange, type, contract id) versus the regular reqContractDetails() is a generic lookup service which can search multiple matches if your request isn't specific enough.
benefit: you don't need to populate the exchange (can just use "") if the instrument is an index. You still need the symbol if looking up a Future() though.
downside: the returned expiration and strike combinations aren't detailed enough to use for generating quotes or orders.
downside: the "use the index" trick doesn't work everywhere. It appears to mostly work for indexes which are actual indexes with prices instead of IBKR simulated indexes without prices (you cant get a quote for Index("CL") for example because the trading is on Future("CL")).
downside: you need the actual contract id also in the parameters

The safest way is still using full contracts for lookups like:
Future(symbol='CL', lastTradeDateOrContractMonth='202409', exchange='NYMEX', currency='USD')

The primary problem with Futures is you need to specify the exchange manually, so you need either a local lookup table mapping names to exchanges, or, sometimes, you can qualify the index as just a symbol to discover the exchange to then use for the futures symbol.
Index(symbol='CL')

to then read the returned expansion of
   ib_async.contract.Index(
        secType='IND',
        conId=17340715,
        symbol='CL',
        exchange='NYMEX',
        currency='USD',
        localSymbol='CL'
    )

Then you can do the normal:
chains = await asyncio.wait_for(
  ib.reqContractDetailsAsync(
    Future(symbol='CL', lastTradeDateOrContractMonth='202409', exchange='NYMEX', currency='USD')),
  timeout=10)

I haven't found a generalized solution where, just given an instrument type and symbol name and expiration date, full options can be fetched reliably every time. It's a mix of needing manual exchange lookups for Futures or needing exact contract IDs, or filtering the bad date/expiration combinations out of reqSecDefOptParams() when it does work.

@mattsta , I think you might be experiencing TWS undocumented handling of futures options (both the futures and futures options are the children of the index not of the underlying contract). I had lots of trouble with futures option until I stumbled upon that realization - now it is 100% reliable, grabbing futures options contracts exactly as you described: I just give it symbol name and exchange to get the index's option chain, I get the futures contract using the last traded date of the futures contract, then filter the index's option chain by the future's conId and options expirations I want.
I adapted options_chain.ipynb for futures options:
https://gist.github.com/maqifrnswa/9dd13abcb8166c4ec4e26c5d0647e60f
That one will always grab the earliest delivery futures contract and the chain corresponding to a delivery on the same date. You can make it shorter/easier by skipping the steps where you get all the upcoming futures to find the earliest delivery date if you already know the date and expiries you want. You can add multiple delivery dates and option expirations (that's what I do in my real-life code, I just have a list or dictionary of delivery date keys and a corresponding list of options expirations I want to grab for those keys)
Feel free to adapt this and add it here if it's helpful. I am just keeping it "secret" until it's tweaked to be what's most helpful.

Oh, I see what you're saying now.
It is a quirk of the futures options where this works better than with equity options. Futures options have unique tradingClass names for almost every relevant week/day combination, so it does break out the data better instead of combining all dates and all strikes into one result.
Good point on the Index note too. Another weird un/under-documented part of the API. I hadn't realized there was a tree in the background attaching all of the different parts together so it works with Index(thing) -> Future(...) -> FuturesOption(...).
For my usage I had just settled on a pattern of:

fetch all chains for specific months (just request contract details but truncate the date as 202409 so it returns {date -> strikes} results for every expiration in a month)
cache the symbol/date/strikes results locally
generate more detailed requests to qualify full symbol/expiration/right/strike/exchange contracts as needed (then cache those full contract lookup results too).

For my usage I had just settled on a pattern of:

fetch all chains for specific months (just request contract details but truncate the date as 202409 so it returns {date -> strikes} results for every expiration in a month)
cache the symbol/date/strikes results locally
generate more detailed requests to qualify full symbol/expiration/right/strike/exchange contracts as needed (then cache those full contract lookup results too).

This is similar to workflow I've developed for future options.

This week is a good example of the different approaches and problems too.
Also I figured out the "can't qualify 0DTE futures options" problem going into this again.
There are CME "Event Contracts" which are weird things qualifying as futures options, but are binary payout events. These are daily contracts and they pollute a same-day lookup with duplicates because they only appear daily. Plus, this week being quarterly opex, we have up to 3 contracts for the same symbol/expiration combination on Friday if we don't specify the trading class.
So, if you try to qualify a 0DTE futures option, you get "well, do you want the actual futures option or an event contract on the futures option or the quarterly expiration futures option?" error message (and I was sending all the noisy status messages to a log I rarely look at). To disambiguate the lookup, you must also provide tradingClass= in the contract if there are multiple conflicting matches.
To improve user experience around duplicate matches, I am now allowing the duplicates to be returned directly from a lookup so they can be interacted with at a program level instead of only in log messages.
Now, if you have duplicates, in place of the single contract return value in the qualifyContractsAsync() list of matched contracts, you can ask for await qualifyContractsAsync(contractA, contractB, ..., returnAll=True) and if there are duplicates, you will get a list of duplicate matches in place of the return value for a single contract lookup (e.g. return type is now list[Contract | list[Contract] | None]).
Exposing the duplicate contracts directly in the code helps because then we can manipulate the duplicates in code directly to show users how to fix the duplicate requests with more information like:
2024-09-20 08:03:49.854 | ERROR    | icli.cli:qualify:939 - [FuturesOption(symbol='ES', lastTradeDateOrContractMonth='20240920', strike=5725.0, right='P', exchange='CME', currency='USD')] contract request returned multiple matches! Can't determine which one of 3 to cache: [
    ib_async.contract.Contract(
        secType='FOP',
        conId=710137977,
        symbol='ES',
        lastTradeDateOrContractMonth='20240920',
        strike=5725.0,
        right='P',
        multiplier='50',
        exchange='CME',
        currency='USD',
        localSymbol='ESU4 P5725',
        tradingClass='ES'
    ),
    ib_async.contract.Contract(
        secType='FOP',
        conId=710138340,
        symbol='ES',
        lastTradeDateOrContractMonth='20240920',
        strike=5725.0,
        right='P',
        multiplier='50',
        exchange='CME',
        currency='USD',
        localSymbol='EW3U4 P5725',
        tradingClass='EW3'
    ),
    ib_async.contract.Contract(
        secType='EC',
        conId=730265747,
        symbol='ES',
        lastTradeDateOrContractMonth='20240920',
        strike=5725.0,
        right='P',
        multiplier='1',
        exchange='CME',
        currency='USD',
        localSymbol='ECESU420 P5725',
        tradingClass='ECES'
    )
]

These changes are in the next branch here (docs are basically just the commit messages for now), so if it's useful, give it a try and see if it helps.

I extracted out my future options workflow for, and provided a working example here,
https://github.com/westonplatter/ib_insync_options/blob/main/example_downloads_for_es_gc_cl.ipynb
I confirmed this works for ES, GC, and CL.
Side note: I found that IBKR will sometimes drop the underlying future's price in modelGreeks, so I backfill it the a calculated most recent price from a different ib_insync futures price.


The package stopped working

I tried the package but it doesn't work can you check it, please?

I tried the package but it doesn't work can you check it, please?

What error you get

Error: Exception: Error from AI package check queue code:404

Error: Exception: Error from AI package check queue code:404

I have the same error, how to fix it?

@dj-yacine-flutter can you fix it please

@dj-yacine-flutter can you fix it please
Error: Exception: Error from AI package check queue code:404

I'm working on it ☺

Tomorrow will be fixed I will add new styles and image resolutions 🤠

I'm counting on you bro ❤😍

I'm counting on you bro ❤😍

Same here bro

update to the latest version 0.1


Cosmetic bug: unnecessary print statement

There is an unwanted print statement in denseToSparse, which keeps printing # nnz.
Please suppress it.
Thanks,
Rahul

Thanks for reporting! Will be fixed in #5374.


HttpResponse object should accept a string as a body.

Just tested it. The HttpResponse Object does accept a string for the body field, It is just a misdefined type. I will fix the type definition for it.


logseq: 0.9.8 -> 0.9.9

Description of changes
Updated logseq  from 0.9.8 to 0.9.9. https://github.com/logseq/logseq/releases/tag/0.9.9

Things done

Built on platform(s)

[x ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

also fixes this issue https://github.com/NixOS/nixpkgs/issues/237629

I think this should be back-ported to 23.05 because it fails with SIGSEGV there too.


Renaming and fix a problem in animation/receiver.py.

Damn... talk about breaking changes :P A begrudging +1

I originally thought of doing this four months ago.  :-D
It was only when I did the docs that I became convinced of this...
On Sat, May 13, 2017 at 2:59 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Damn... talk about breaking changes :P A begrudging +1
—
You are receiving this because you authored the thread.
  I can make this a non-breaking change!  BRB...
On Sat, May 13, 2017 at 3:05 PM, Tom Swirly<EMAIL_ADDRESS>wrote:

I originally thought of doing this four months ago.  :-D
It was only when I did the docs that I became convinced of this...
On Sat, May 13, 2017 at 2:59 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Damn... talk about breaking changes :P A begrudging +1
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/188#issuecomment-301246728,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdsvgDWHBT1WFLgOeP1bdN9WzsQSHSks5r5ak6gaJpZM4NaD_4
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

All right!  This should be a non-breaking change!  The old symbols still exist, but are aliases for the new ones, and deprecated.

Oh... nevermind. I see now. +1
That will certainly save a lot of headaches :)
On Sat, May 13, 2017 at 9:28 AM, Tom Swirly<EMAIL_ADDRESS>wrote:

@rec commented on this pull request.
In bibliopixel/led/init.py
https://github.com/ManiacalLabs/BiblioPixel/pull/188#discussion_r116358409
:

from .. layout import Rotation
from .. layout.matrix import gen_matrix
from .. layout.circle import gen_circle
from .. layout.cube import gen_cube

+# These are DEPRECATED
Nah. It's just a comment for the reader. Everything that was defined
before, is still defined now - however, the old names are now just synonyms
for the new, shorter names.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/188#discussion_r116358409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6pSwsccyYOLGxHVOUmxYLF9SVLYnks5r5bANgaJpZM4NaD_4
.


When would I choose meta in preference to repo a.k.a. git-repo ?

When would I choose meta in preference to repo a.k.a. git-repo ?
Re. repo at  https://gerrit.googlesource.com/git-repo/ it seems to do same job? What is core difference & when do you advice us to choose one over the other?
Furthermore the README says meta has

no strange side effects of git submodules or subtree

but what exactly are the these problems? Why is meta better than submodules?
I think this info would be helpful in the project README.
I am a total newbie with meta so apologies if my questions are too simple.

Hi, haven't seen git-repo until now. I also recently saw gico which is similar as well.
meta itself is inspired from earlier usage of a tool called gitslave which did a good job summarizing the problem with git submodules several years ago.

Gitslave creates a group of related repositories—a superproject repository and a number of slave repositories—all of which are concurrently developed on and on which all git operations should normally operate; so when you branch, each repository in the project is branched in turn. Similarly when you commit, push, pull, merge, tag, checkout, status, log, etc; each git command will run on the superproject and all slave repositories in turn. This sort of activity may be very familiar to CVS and (to a lesser extent) Subversion users. Gitslave's design is for simplicity for normal git operations.

git-submodules is the legacy solution for this sort of activity. submodules went a different way where you have a submodule at a semi-fixed commit. It is a little annoying to make changes to the submodule due to the requirement to check out onto the correct submodule branch, make the change, commit, and then go into the superproject and commit the commit (or at least record the new location of the submodule). It was originally designed for third party projects which you typically do not doing active development on (it works the other way with a little inconvenience). Most git commands performed on the superproject will not recurse down into the submodules. As suggested above, submodules give you a tight mapping between subproject commits and superproject commits (you always know which commit a subproject was in for any given superproject commit).

This mismatch of use cases vs git submodule was likely the inspiration for tools like gico and git-repo as well, but I can't speak for their authors.
meta expands on this idea by allowing users to create a .meta file that contains a JSON object that describes all of the repositories that make up the project and perform any command against all or a subset of those projects. It also is an extensible plugin based core, and thus can expand to more use cases than just git. For example, the meta-npm plugin provides lerna-like "npm linking" capabilities, and I used "meta project migrate" just this morning to split a monorepo up to the seven different sub-projects that made it up.

@k1eran last I looked at repo, it had a whooooole lot of convention that was tightly coupled to Android development. At the very least it would cause you to have to overlook a bunch of cruft you don't need in your solution. At the worst, it might not work. I didn't try hard enough to see if the second option was reality. If you want to invest time in it, I'd be happy to hear back about your experience.
The intention behind meta was to create the simplest tool possible, using first principles. How can I use the simple, basic concepts in git to extend git's functionality? That's meta.

lets add "similar tools" to readme

https://gitslave.sourceforge.net/
https://gerrit.googlesource.com/git-repo/ - focus on android
https://gitlab.com/moduon/mrchef - written in python, integrates with nix
https://github.com/blejdfist/git-metarepo

my first impression: git submodules are not bad enough to justify adding a new tool


SQLite bindings

Add Android SQLite bindings to improve speed of the database operations https://www.sqlite.org/android/doc/trunk/www/index.wiki

Fixed in #8


Add custom validation ot Array trait type

Fixes #7
Adding a new valid chaining method to specify custom validators as free functions.

Complete example validating an input array with a prescribed shape.

from traitlets import HasTraits, TraitError
from traittypes import Array

def shape(*dimensions):
    def validator(trait, value):
        if value.shape != dimensions:
            raise TraitError('Expected an of shape %s and got and array with shape %s' % (dimensions, value.shape))
        else:
            return value
    return validator

class Foo(HasTraits):
    bar = Array(np.identity(2)).valid(shape(2, 2))

foo = Foo()

foo.bar = [1, 2]  # Should raise a TraitError

In bqplot for example, we would probably have

x = Array().valid(squeeze).tag(sync=True)

where squeeze is a function like
def squeeze(trait, value):
    if 1 in value.shape:
       value = np.squeeze(value)
    return value

@dmadeka


Fix stack build

Overview
Bumps the cardano-ledger-specs package to latest master, which fixes a dangling symlink in its git repo which broke newer versions of stack.
Comments
Tested with:
stack build --fast --test --no-run-tests --bench --no-run-benchmarks

bors r+

bors retry

Bumps the cardano-ledger-specs package to latest master, which fixes a dangling symlink in its git repo which broke newer versions of stack.

Is there an upstream ticket about this?

No

bors retry

Interestingly, with this combination of commits you can't seem to build the ledger-spec tests:
[ 9 of 20] Compiling Test.Shelley.Spec.Ledger.ConcreteCryptoTypes ( src/Test/Shelley/Spec/Ledger/ConcreteCryptoTypes.hs, /home/jule/git/iohk/cardano-wallet/dist-newstyle/build/x86_64-linux/ghc-8.6.5/shelley-spec-ledger-test-<IP_ADDRESS>/build/Test/Shelley/Spec/Ledger/ConcreteCryptoTypes.o )

src/Test/Shelley/Spec/Ledger/ConcreteCryptoTypes.hs:15:29: error:
    Module ‘Cardano.Crypto.Hash’ does not export ‘MD5Prefix’
   |
15 | import Cardano.Crypto.Hash (MD5Prefix)

Via e.g. cabal build --enable-tests all.

@hasufell Yes, it needs a newer revision of cardano-base. The error was in cardano-node/cabal.project, which is our reference.
I'm not sure why you are running the tests of all dependencies, but fwiw PR #2088 will fix it.

I'm not sure why you are running the tests of all dependencies

Building, not running. This is more of a cabal oddity when passed --enable-tests. I think this will be gone in cabal-<IP_ADDRESS>, which doesn't treat source-repository packages as local anymore.