hrpsys_ros_bridge has been failing to build on Groovy, only on Quantal #410
Comments
|
This build failure is blocking next Groovy sync. |
|
So it will happens to all cases, if we run buiding this packages again???? |
|
need to find platform that reproduce this error: |
|
I tested on http://jenkins.jsk.imi.i.u-tokyo.ac.jp:8080/computer/quantal-amd64/, but its seems ok. |
it seems so.... and other is to download tgz from |
|
I have created two PR, #411 ( fix to use git :// and set GIT_SSH env) which should work. How do I integrate this patch? because current HEAD has changed a lot from 1.0.7, one is just to change release repository at |
|
Or is it worth asking buildfarm maintainers if they can check the version of git client and update if it's too old? |
|
yes, that's would be fine if they update git version. |
|
Okay I will ask |
|
Hydro-Precise is failing too but only the last 2 builds, and the cause is different. I think that's a different issue. |
|
In the pre-release log the version of |
|
pre-release and build-deb uses different environment as well as different process. |
|
Sorry I was wrong. That was NOT pre-release; that's "real" build log. |
On the other distro, it has not been compile after Mar 25th, so this problem will happens to all distro, I think. #411 will works, since it uses git access and do not use SSL CA.
That's different it seems somehow CORBA name server has been running, build 158 (last succeed build) and build 159 (broken one) used different build machine. This should be fixed by adding What should we do next?
I would choose 2) and 6) |
|
A couple of comments from ros-release ML. |
|
we can ignore travis failing for this issue because it only happens on rosbuild. |
|
sinsce buildfirm http://jenkins.ros.org/job/ros-groovy-hrpsys-ros-bridge_sourcedeb/, we have to choose one of them. which do you think better? @130s |
|
+1 for |
|
Since 1.0.8 have many update from 1.0.7, so it potentially breaks downstream packages as rtmros_hironx / rtmros_nextage. |
|
I mean, if you're OK, others may OK. So let's update the package. |
|
I see.
For the following reasons, I'll first test and see before making 1.0.8 release.
|
|
By the way does 1.0.8 need OpenHRP3 3.1.5-6 to be released? |
|
(Re-posting; Sorry last post was somehow mistaken.) Pre-release (using I think this is due to the fact that pre-release test wants to install all dependencies from Having said that, we should just make a judgement call to release into Groovy. |
No, I don't think so. from 3.1.5.-5, we only added fedra/arch support, test code and sample code. |
|
I see. Now 1.0.8 released into Groovy, build still fails on buildfarm (not pre-release). This time not just http://jenkins.ros.org/job/ros-groovy-hrpsys-ros-bridge_binarydeb_quantal_amd64/121/consoleFull Assuming git here is failing? I'll look into release repository to see if something was wrong in how I made a release. |
|
do we need to add build_depend git ??? I couldn't see |
|
Hmm..Before making a trial release, I'll locally remove git and buiild |
|
I added Is there a way to run |
|
CMakeLists.txt uses git command so if you remove git from your local machine, then you have to run |
|
Actually |
|
With @k-okada this time again I don't know what's wrong (I think I tried to follow exactly what you did for making the last successful release 1.0.7) and because it's urgent (this is blocking Groovy sync at osrf), could you give it a try? |
|
How many Considering that Groovy will be retired in a few months, if the problem persists on Groovy then another option for us might be to stop providing Groovy update, roll back to what was stably built and freeze. Just an idea. |
k-okada
added a commit
to k-okada/rtmros_common
that referenced
this issue
Apr 15, 2014
|
as we commented at #308 (comment), current sed script https://github.com/start-jsk/rtmros_common/blob/master/hrpsys_ros_bridge/catkin.cmake#L95 assuming you have and generated from https://github.com/tork-a/rtmros_common-release/blob/patches/release/groovy/hrpsys_ros_bridge/0001-Commentout-a-dependency-on-pr2-catkin-package-that-d.patch generate unexpected behavior. I fixed sed script at k-okada@cc3da4c to work with |
|
In the JSK, I'd like to push hydro/catkin, but we have following e-mail last night.... hydro/rosmake seems strange but, the solution suggested from other student was using groovy/rosmake. Maybe because they grown up with groovy/rosmake and do not confident on how hydro/catkin works... please remember https://docs.google.com/file/d/0BzNmzxy4pVGMZHd2b1BSWVlHVHM/edit, this survey was carried out 2013.05 and Fuerte was released 2012.05 and Groovy was released 2012.10, and more people used Fuerte than Groovy. People remain current situation as long as they have super strong motivation or constraint to move forward. |
130s
pushed a commit
that referenced
this issue
Apr 15, 2014
remove sed to comment out pr2_controllers (#410)
|
1.0.10 is submitted. This time I didn't even need this tweak on |
|
seems good. I do not understand correctly, but bloom itself create patch file during that tweak process. bloom seems much more flexible and powerful than I expected. |
|
1.0.10 build fails for most of / all Ubuntu but looks like there was a new script applied on buildfarm, and from my personal experience jenkins might always fail for the first build after new changes. So I don't get bothered by these errors and we'll keep watching. Why |
not to conflict with existing name server, specially working robot/simulator. |
|
There might be two reasons, one is that we fail to kill omniNames and keep alive on buildfirm. Other reason is that multiple build is running at same time. These builds runs at different buildfirm so there might be omniNames running in omniNames. As I wrote in start-jsk/openhrp3#43 (comment), I'm very sorry to bother you, I'll take care of releasing for groovy for a while. |
|
note that if above reason is the problem, that is not related G/H, it will happens to all. |
|
#423 did not pass on travis due to and this is reproduceable... very strange... Only for groovy/catkin, it works on groovy/rosmake and hydro/catkin... |
|
if you compare, https://s3.amazonaws.com/archive.travis-ci.org/jobs/23081123/log.txt and https://s3.amazonaws.com/archive.travis-ci.org/jobs/23081120/log.txt, Hydro and Groovy |
|
it was long way... On groovy, The problem was (This is just my GEUSS) when cmake runs it checks each it generate xmlfile (SampleRobot.xml) but each time cmake runs the ${_corab_port} changes randumly, so the contens of I used chach taht keeps previous corba_port for each PROJECT_NAME. https://github.com/start-jsk/rtmros_common/pull/423/files#diff-5ac07341a443eee9bd9a1be4df6f848aR63 |
|
Looks like it's building! Otsukare-sama deshita. |
|
＼(^O^)／. % how do you say Otsukare-sama deshita in English, good job? |
|
release on hydro, since it is failing on rosbuild due to same error which I believed to solved in 1.0.11 http://jenkins.ros.org/job/ros-hydro-hrpsys-ros-bridge_binarydeb_precise_amd64/160/ |
|
"Good work!" sounds not arrogant and more encouraging in professional sense |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
http://www.ros.org/debbuild/groovy.html?q=regression&s=4&r=1
Latest build job result
Looks like it's been failing since March 25 with the same error.
Why on Quantal only?
Trying to access https://github.com/PR2/pr2_controllers.git/info/refs reaches a page that says (on Firefox):
I'm not sure what error is happening on Quantal, but is this dumb Http transport issue related? Is git client so old on
Quantalon the ROS buildfarm?The text was updated successfully, but these errors were encountered: