search

roboticslab-uc3m / questions-and-answers

A place for general debate and question&answer
https://robots.uc3m.es/developer-manual/appendix/repository-index.html
2 stars 0 forks source link

New Xenial images available on Travis CI #73

Closed PeterBowman closed 5 years ago

PeterBowman commented 5 years ago

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:

PeterBowman commented 5 years ago

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

PeterBowman commented 5 years ago

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 commented 5 years ago

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

PeterBowman commented 5 years ago 
* TEO: Ubuntu 14.04

Actually, it's Ubuntu 16.04 ATOW (https://github.com/roboticslab-uc3m/teo-developer-manual/issues/42#issuecomment-442238739).

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: https://github.com/roboticslab-uc3m/yarp-devices/issues/111. My main concern was expressed in https://github.com/roboticslab-uc3m/yarp-devices/issues/111#issuecomment-351041371 - 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 commented 5 years ago

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

PeterBowman commented 5 years ago

I'd consider moving to YARP 3.0 (https://github.com/roboticslab-uc3m/questions-and-answers/issues/65) shortly afterwards. BTW (https://github.com/roboticslab-uc3m/questions-and-answers/issues/65#issuecomment-397658934):

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 commented 5 years ago

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 commented 5 years ago

Issues:

PeterBowman commented 5 years ago

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

Solved via https://github.com/roboticslab-uc3m/vision/commit/834c33c1f0795dcd536853949a041c84490d29a7, documented at https://github.com/roboticslab-uc3m/installation-guides/commit/e2a084520b8bbfae71a4e53ce0f835f062a53fc6.

Edit: https://github.com/roboticslab-uc3m/installation-guides/commit/d186edc27e49fc2745ded8b45e9c103df056c503.

PeterBowman commented 5 years ago

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: https://github.com/roboticslab-uc3m/openrave-yarp-plugins/commit/6ae570b2792c9cf806192643ade1be18386d6a68. All warnings have been disabled (-w option) for OpenRAVE builds.

PeterBowman commented 5 years ago

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 commented 5 years ago

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

Workaround: https://github.com/asrob-uc3m/yarp-devices/commit/6b4a5ffeff673ebec78b90305145f1598d01c013. Remove that dependency and update docs (asrob-uc3m/yarp-devices/doc/yarp-devices-install.md, https://github.com/asrob-uc3m/yarp-devices/commit/a412e453f44a36adb070c67596b74a891f3cd3f5) once this bug is solved.

PeterBowman commented 5 years ago

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

Solved in production branch: https://github.com/rdiankov/openrave/commit/23ad7be079086008572513fafd1f5e88da74a279. For now, set CMake option OPT_IKFAST_FLOAT32 to OFF (defaults to ON). Traceback:

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 https://github.com/roboticslab-uc3m/installation-guides/compare/e2a0845...23ee6bd.