I have a release build job that timed out compiling the codebase of the package I’m trying to release into the ROS distribution. What is the best way around this?
The initial job was triggered through the blooming process. Will re-triggering this job employ a build cache, potentially allowing the build to finish the second time around? If so, what is the best way to re-trigger the release job?
Will re-triggering this job employ a build cache, potentially allowing the build to finish the second time around? If so, what is the best way to re-trigger the release job?
I think failing jobs are retriggered automatically (Maybe nightly by this job for Foxy?), or when one of the package’s dependencies change.
For those curious, here’s the console log of the job:
I see it’s building third party libraries, which is using a lot of the time limit. Can system packages be used instead?
Shane is correct here. Failing jobs are automatically re-triggered. Periodically the ROS boss will review failing jobs and may disable packages that never succeed after opening issues upstream.
Caching is currently disabled on the ROS build farm for security reasons. We’re hoping to bring it back but caching is no guarantee since each cache is host-local and there is guarantee that the previous host will be available when the job re-runs.
We do our best to provide infrastructure to the entire community and as a result we have to set limits on the resources available to any individual package.
In general libraries that are not available in ROS or the upstream platform should not be used in ROS packages. Many of the libraries in this build’s third party directory are already available as system packages or libraries in ROS. Additionally, none of the license information for the vendored software is mentioned in the package.xml included in this installation https://github.com/ngaloppo/ros_openvino-release/blob/master/foxy/package.xml#L8
Since this package is not ROS specific, the best way to make it available in ROS long term is to start packaging it for our upstream distributions like Debian, Ubuntu, and RHEL / AlmaLinux. Following the distribution guidelines for those projects will also lead to improvements that will make releasing this package directly in ROS easier in the interim.
That’s unfortunate. The upstream project has added these third-party dependencies as git submodules. That’s a common method in the open-source community to align a project’s source code revision with third-party source code revisions. Changing the upstream’s approach would be a very heavy lift. Are you recommending against this approach, or saying that it is impossible all together to release into ROS distributions with this approach?
What’s is the recommended approach of including these dependent licenses into the package.xml?
Historically OpenVINO has been packaged as apt packages for Ubuntu releases but unfortunately through a custom PPA. As far as I understand this is not acceptable as a rosdistro source?
I would say that the Linux distribution approach of unbundling dependencies so that the entire distribution can be maintained together is an equally common approach and has the advantage of improving the likelihood of successful interoperability with all combinations of packages in the distribution.
The absolutely optimal approach would be to work with the upstream project to allow their build system to support both the bundled third party software and fetching those dependencies from the system so that the latter could be used in a distribution context.
I do not endorse and actively discourage releasing anything with bundled dependencies. Especially if those dependencies are libraries that are already available on the system. Our policy is not to accept such packages when they are identified but we do not have an established practice of removing them if they are already released. Which is to say that packages which are already released in a ROS distribution can stay in that distribution unless a licensing violation or significant user-facing issue is created by its inclusion but we would not allow new packages to be added which are known to bundle dependencies and I think we would push back on adding those packages to ROS distributions where they are not already released.
Package.xml version 3 allows multiple <license> tags but has no formal mechanism for specifying where they apply so the common practice is to include a license tag for each license that applies and then use xml comments to add further details. If you include a Debian machine readable copyright file in the source as well you can refer to that if you want to keep the comments simple and refer to a parse-able format for package copyright info.
That’s correct, only packages in the expected rosdep sources which generally includes the upstream repositories for our target OS distributions as well as the ROS repositories themselves are usable to build and run ROS packages. If the package in that PPA is adhering to the Debian and Ubuntu guidelines and unbundling the dependencies you could use that as a starting point for efforts to upstream the package into Debian or Ubuntu proper. If not, you could still use the package from that PPA with your own packages and your own custom rosdep sources but any packages which require that would not be release-able to the official ROS build farm.