From 2c6dbf45e116a448a2fac2d6b7157c7301d3ecbe Mon Sep 17 00:00:00 2001 From: George Stavrinos Date: Sat, 11 Mar 2023 01:37:31 +0200 Subject: [PATCH] Added info in preparation for the v1.2.0 release --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 7388510..b3bdcc7 100644 --- a/README.md +++ b/README.md @@ -26,10 +26,13 @@ or #### Tips! * If you encounter errors regarding your graphics card while trying to run the `rosez` or `ros2ez` script, try adding the `fi` or `force-integrated` flag, which will force usage of the integrated graphics card of your computer. This is, of course, not optimal, so update your drivers and try running the script again. Make sure that the flag is the first argument of your command. If this fails too, open an issue. For instance, the examples above can be executed with the integrated graphics card by running `ros2ez fi ros2 run teleop_twist_keyboard teleop_twist_keyboard cmd_vel:=racer_01/cmd_vel` and `rosez fi rosrun rviz rviz` respectively. * You can change or add default workspaces by editing the `includes/ros*_ws.txt` file. One directory per line. +* Migrating from `v1.0.0` to newer versions will most probably introduce some permission issues, since newer versions try to stay inside the user's permissions instead of root. A chown of your workspace(s) to your user should fix the problem. +* [For versions >= `v1.1.0`] User configurable and system files have been separated, so you (most probably) should not mess with the `internals` folder. +* [For versions <= `v1.1.0`] Running multiple `ros*ez` commands concurrently (in separate terminals) can introduce race conditions, especially in workspace building (colcon (ROS2) or catkin (ROS1)). Refrain from running `ros*ez` commands concurrently, but wait for build commands to finish. +* [For versions >= `v1.2.0`] The new concurrency handling system allows for execution of multiple `ros*ez` commands concurrently (in separate terminals). The system uses lock files and tries to handle them effectively to avoid dangling ones. In the (rare?) case of a dangling lock file (essentially eternally waiting for a lock file to unlock), you should do one of the following solutions: The first one is to reboot your machine. The next time you boot up, your lock file will be older than your system's uptime, and be automatically removed. The second one is to use the `clear-locks` or `cl` flag during `ros*ez` execution. Keep in mind that if you generally use the `force-integrated` or `fi` flag, you willneed it here too. For instance, the next commands will remove **ALL** locks and then run the specified command `ros2ez fi cl ros2 run teleop_twist_keyboard teleop_twist_keyboard cmd_vel:=racer_01/cmd_vel` or for ros1 `rosez cl fi rosrun rviz rviz`. Note that the order of the flags is not important, but **have** to be placed before the required ros command. ## Tested platforms * EndeavourOS * Fedora 35 * Ubuntu 22.04 * MX Linux 19.1 -