* builder: Build against Buster
* builder: Use correct repository specifications
* builder: Move ld.so.preload to have less errors
* builder: Use coex repo to install Monkey
* builder: Search for buster ROS packages
* aruco_pose: Vendor in aruco library from OpenCV 3.4.6
* builder: Move to ROS Melodic
* builder: Update kernel version
* aruco_pose, clever: Remove opencv3 ROS dependency
* builder: Update rosdep
* travis: Disable eclint for vendored aruco library
* tests: Don't try to locate opencv in ros
* roscore: Use melodic distribution
* Revert "aruco_pose: Vendor in aruco library from OpenCV 3.4.6"
This reverts commit 9c14a8c002bb3396f9a7d9b2ba39969207f066ba.
* aruco_pose: Vendor opencv_contrib/aruco again
* builder: Add led packages
* builder: Remove unused builder code
* travis: Add native tests
* builder: Set permissions for standalone-install
* builder: Use -y for package installation
* builder: Add repo for standalone build
* builder: Use correct file types for standalone install
* aruco_pose: Accept rgb8 map images
* builder: Disable mjpg_streamer test
* aruco_pose: Allow rgb8 map images (again)
* builder: Re-add mjpgstreamer
* builder: Install tornado==4.2.1 for rosbridge_suite
* builder: Use more recent base image
* builder: Use default kernel
* builder: Move ld.so.preload back after tests
* builder: Disable catkin tests
These tests fail on a remote machine but seem to pass just fine on real hardware. Something must have changed between Kinetic and Melodic, and we must investigate more, but for now we just need a working image.
* aruco_pose: Remove unused vendored code
* selfcheck: Update systemd-analyze regex
* builder: Add opencv repository
* rosdep: Update package definitions for Melodic
* rosdep: Use proper yaml formatting
* travis: Remove unnecessary space
* docs: Reference Melodic wherever possible
Upgrading pip system-wide should be a task for the system package manager,
and doing it through pip itself seems to be frowned upon (not to mention leaving
the end user with a broken package installer and broken packages). It also seems
to have some fun/nasty side effects (like setting pip up to install packages for python3
instead of python2, for which pip2 is used).
Debian-packaged pip, while being older, doesn't seem to break stuff for now. End user should
be able to upgrade to a newer pip locally (which seems like the right thing to do), but
a possibility of having a more recent pip should be looked into nonetheless.
