search

start-jsk / rtmros_common

OpenRTM - ROS interoperability packages
http://wiki.ros.org/rtmros_common
12 stars 52 forks source link

Pre-release test never got "SUCCESS" on Hydro #416

Open 130s opened 10 years ago

130s commented 10 years ago

http://jenkins.ros.org/view/Prerelease/job/prerelease-hydro-rtmros_common/

Since February 2014 up to now, no test ever succeeded; either unstable or failure. Failure is fine, since it definitely needs to be taken care of immediately. Now the problem is unstable, since it makes our judgement difficult whether we can make a new release or not.

Looking at the last pre-release test, what failed are:

test_hironx*.xml will be handled in https://github.com/start-jsk/rtmros_hironx/issues/50.

What about others?

k-okada commented 10 years ago

I think it is because ros build firm (including devel and pre-release) did not run omniorb-nameserver[1], so we have to manually start name server[2], but there might be some issues:

1) This script assume start start_omninames.sh before all other nodes, however roslaunch did not guarantee the order of executing the process. 2) Currently I put start_omninames.sh everyware, opnehrp3, hrpsys, rtmbuild. That is redundant. I think we should rtm-naming in openrtm_aist package, but the script did not keep the nameserver process in foreground. so we need patch.

start_omninames()
{
    echo 'Starting omniORB omniNames: '$hostname':'$port
    rm -f ./omninames-$hostname.log
    rm -f ./omninames-$hostname.bak
    $cosnames -start $port -logdir $currdir &

[1] https://github.com/ros-infrastructure/jenkins_scripts/issues/67#issuecomment-37885110 [2] https://github.com/k-okada/rtmros_common/commit/4de5338af78eb3da5de770a49da017927ac74b98

130s commented 10 years ago

2) Currently I put start_omninames.sh everyware, opnehrp3, hrpsys, rtmbuild. That is redundant.

Hmm, indeed.

I think we should rtm-naming in openrtm_aist package, but the script did not keep the nameserver process in foreground. so we need patch.

Is there any reason why this patch is not yet applied? And where is this patch supposed to be applied?

k-okada commented 10 years ago

Is there any reason why this patch is not yet applied? And where is this patch supposed to be applied?

this should be patched against OpenRTM-aist-1.1.0/utils/rtm-naming/rtm-naming, but in order to keep original behavior, i think it is better to use command line option for proposed behavior.

130s commented 10 years ago

this should be patched against OpenRTM-aist-1.1.0/utils/rtm-naming/rtm-naming,

I see.

but in order to keep original behavior,

I see.

i think it is better to use command line option for proposed behavior.

How is this achievable on buildfarm? Since I'm not familliar, I just opened a PReq to workaround in the same way it's done in hrpsys and other package while I'm open to implement more optimal solution later.

k-okada commented 10 years ago

How is this achievable on buildfarm?

on is to send patch to openrtm-users and wait for new release, other is to add patch file https://github.com/start-jsk/openrtm_aist_core/tree/master/openrtm_aist/patch, but in that case we have to release package without updating package version...