You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
turtlebot/3ea2c30 is about an env hook (basically a Bash script 'plugin') trying to find a directory which doesn't always exist (as it's a directory from a different package, which isn't listed as a dependency of the package in which the failing env hook is located):
ROS packages can make use of environment hooks -- shell scripts
that are executed, for instance, to set up environment variables.
In ROS Indigo, the core Turtlebot package introduced an
environment hook that depended on another package that was not
listed as a dependency in the package manifest. This caused error
messages to be printed to the terminal if the user did not have
the package installed.
The fix was to move the faulty parts of the environment hook to
the package they depended on.
This is classified as SOFTWARE:LIVENESS.
However, the net effects of that env hook failing are essentially:
an annoying warning on the console every time a user sources their setup.bash (ie: activates a workspace)
the TURTLEBOT_MAP_FILE environment variable not getting set
but the base functionality of the package itself (ie: turtlebot_bringup) is not affected. The robot can still be controlled, no software will fail to work, except some other package which might use this variable (some .launch files in turtlebot_navigation).
Do we feel this is sufficient for a LIVENESS label?
Edit: and the env hook also only sets a "sane default".
The text was updated successfully, but these errors were encountered:
That does not sound like a LIVENESS failure, at all.
If not sure if there is a right label for it, but I would guess that the SOFTWARE is perfectly capable of making progress, despite the fault.
turtlebot/3ea2c30 is about an env hook (basically a Bash script 'plugin') trying to find a directory which doesn't always exist (as it's a directory from a different package, which isn't listed as a dependency of the package in which the failing env hook is located):
robust/turtlebot/3ea2c30/3ea2c30.bug
Lines 4 to 14 in 7e3932c
This is classified as
SOFTWARE:LIVENESS
.However, the net effects of that env hook failing are essentially:
source
s theirsetup.bash
(ie: activates a workspace)TURTLEBOT_MAP_FILE
environment variable not getting setbut the base functionality of the package itself (ie:
turtlebot_bringup
) is not affected. The robot can still be controlled, no software will fail to work, except some other package which might use this variable (some.launch
files inturtlebot_navigation
).Do we feel this is sufficient for a
LIVENESS
label?Edit: and the env hook also only sets a "sane default".
The text was updated successfully, but these errors were encountered: