New Xenial images available on Travis CI

[PeterBowman]

Ubuntu Xenial 16.04 build environment is here! (https://changelog.travis-ci.com/ubuntu-xenial-16-04-build-environment-is-here!-79690)

Full docs: https://docs.travis-ci.com/user/reference/xenial:

• CMake 3.12.4
• GCC 5.4.0
• Python 2.7.15, 3.6.5 and 3.7.1

[PeterBowman]

I just gave it a try in https://travis-ci.com/roboticslab-uc3m/color-debug/jobs/161080835.

[PeterBowman]

Switching announcement label to discussion (please restore if deemed convenient): my original intent was to debate whether current Trusty jobs should be switched to Xenial. Or: perhaps both OSs should prevail, in which case we'll end up with twice as many jobs per build (currently 8, reaching up to 10 in develop).

[jgvictores]

• Developer PCs: Per the current state of https://github.com/roboticslab-uc3m/developer-manual/blob/bcc0c12459da5b07ee274c32081401fd3a34b8df/main-developer-tools.md#main-developer-tools we recommend Ubuntu 16.04 and 18.04.
• TEO: Ubuntu 14.04 per https://github.com/roboticslab-uc3m/teo-developer-manual/blob/50c8020d4d0e675f33587e2415db6f64f230927a/appendix/c-teo-network-information.md#manipulation-robot-front-right-pc
• ASIBOT: Per Distro and distro setup for robots #20 (comment) has headless Debian Jessie (aka Debian 8).

Maybe Trusty makes sense for repos such as yarp-devices and kinematic-dynamics?

[PeterBowman]

* TEO: Ubuntu 14.04

Actually, it's Ubuntu 16.04 ATOW (roboticslab-uc3m/teo-developer-manual#42 (comment)).

Maybe Trusty makes sense for repos such as yarp-devices and kinematic-dynamics?

Not so long ago we had a similar debate about Precise vs Trusty: roboticslab-uc3m/yarp-devices#111. My main concern was expressed in roboticslab-uc3m/yarp-devices#111 (comment) - this is a somehow distro-agnostic train of thought that concerns: 1) the dependencies we expect users to install along with our software; 2) the build environment available in Trusty images. Note that Trusty on Travis provides CMake 3.9.x, well ahead the v3.5 release we assume everybody will use if ever talking about Ubuntu 14.04. Therefore, there is an asymmetry between these two environments that we can't avoid - just adapt to it and keep in mind any potential pitfalls (e.g. the Travis build succeeds but my local machine doesn't).

My 0.05€: follow the updates in Travis & Xenial images, wait until this environment is considered stable enough (should be already), make sure no conflicts arise with regard to our code (shouldn't, everything is well tested and documented on this SO), migrate all Trusty builds to Xenial gradually. Keep in mind Trusty's EOL!

[jgvictores]

Okay! Updated the info regarding TEO's OSs. Totally agree with your 0.05€ !!! 😄

[PeterBowman]

I'd consider moving to YARP 3.0 (#65) shortly afterwards. BTW (#65 (comment)):

ASWJ, in the future, we'd like to create one tag per repo prior to requiring YARP 3.0 everywhere. The goal is to keep track of the last point in the commit history that supported YARP 2.x.

Edit: also remember to delete old Travis caches, by the way.

[PeterBowman]

Xenial is going to become the default Linux build environment, starting next week: https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment.

My 0.05€: follow the updates in Travis & Xenial images, wait until this environment is considered stable enough (should be already), make sure no conflicts arise with regard to our code (shouldn't, everything is well tested and documented on this SO), migrate all Trusty builds to Xenial gradually. Keep in mind Trusty's EOL!

I'll be working on it, triggered builds may come in handy here.

[PeterBowman]

Issues:

• roboticslab-uc3m/vision and roboticslab-uc3m/xgnitive: no PPA available for PCL libraries on Xenial, try libpcl-dev apt package instead (install guide)

• roboticslab-uc3m/vision: cannot find libproj.so, this is a known Xenial bug; solution: install libproj-dev package, then remove a reference to vtkproj4 (SO)

• asrob-uc3m/yarp-devices: libserial-dev should depend on libboost-dev since Xenial, a bug report was sent (ref)

• asrob-uc3m/robotDevastation: Can't open /etc/init.d/xvfb, see 3. Headless browser testing in this blog entry

• roboticslab-uc3m/openrave-yarp-plugins (also xgnitive): "The job exceeded the maximum log length, and has been terminated." - add -Wno-deprecated-declarations compiler flag to reduce verbosity?

[PeterBowman]

roboticslab-uc3m/vision: cannot find libproj.so, this is a known Xenial bug; solution: install libproj-dev package (SO)

Solved via roboticslab-uc3m/vision@834c33c, documented at roboticslab-uc3m/installation-guides@e2a0845.

Edit: roboticslab-uc3m/installation-guides@d186edc.

[PeterBowman]

roboticslab-uc3m/openrave-yarp-plugins (also xgnitive): "The job exceeded the maximum log length, and has been terminated." - add -Wno-deprecated-declarations compiler flag to reduce verbosity?

Added new --cmake-env option to git-cache-dependency.sh: roboticslab-uc3m/openrave-yarp-plugins@6ae570b. All warnings have been disabled (-w option) for OpenRAVE builds.

[PeterBowman]

Now seeing narrowing issues that escalate to errors on Clang jobs, only (ref):

/home/travis/OpenRAVE-master/plugins/ikfastsolvers/ikfastsolver.cpp:1066:49: error: 
      non-constant-expression cannot be narrowed from type 'double' to 'float'
      in initializer list [-Wc++11-narrowing]
                IkReal eetrans[3] = {t.trans.x, t.trans.y, t.trans.z};
                                                ^~~~~~~~~
/home/travis/OpenRAVE-master/plugins/ikfastsolvers/ikfastsolver.cpp:1066:49: note: 
      insert an explicit cast to silence this issue
                IkReal eetrans[3] = {t.trans.x, t.trans.y, t.trans.z};
                                                ^~~~~~~~~
                                                static_cast<float>( )

I need to double-check locally that the -w is not causing this with Clang. Might deserve an upstream patch.

[PeterBowman]

asrob-uc3m/yarp-devices: libserial-dev should depend on libboost-dev since Xenial, a bug report was sent (ref)

Workaround: asrob-uc3m/yarp-devices@6b4a5ff. Remove that dependency and update docs (asrob-uc3m/yarp-devices/doc/yarp-devices-install.md, asrob-uc3m/yarp-devices@a412e45) once this bug is solved.

[PeterBowman]

I need to double-check locally that the -w is not causing this with Clang. Might deserve an upstream patch.

Solved in production branch: rdiankov/openrave@23ad7be. For now, set CMake option OPT_IKFAST_FLOAT32 to OFF (defaults to ON). Traceback:

• https://github.com/rdiankov/openrave/blob/b1ebe135b4217823ebdf56d9af5fe89b29723603/plugins/ikfastsolvers/ikfastsolver.cpp#L1066-L1067 (plus line 1100)
• https://github.com/rdiankov/openrave/blob/b1ebe135b4217823ebdf56d9af5fe89b29723603/plugins/ikfastsolvers/ikfastsolver.cpp#L2419-L2430
• https://github.com/rdiankov/openrave/blob/b1ebe135b4217823ebdf56d9af5fe89b29723603/plugins/ikfastsolvers/CMakeLists.txt#L7-L9

Affects Clang 6.0 (most recent apt release on Xenial) and Clang 7.0 (current Travis Xenial images). Default Clang Xenial packaged release is 3.8, compiles successfully.

Documented at roboticslab-uc3m/installation-guides@e2a0845...23ee6bd.