Dirk Thomas
Dirk Thomas
The build farm will take the release repo as input and produce a binary for each package. It will not build any dependencies - they much have been either available...
I don't know how it affects `bloom`when a new releases platform is added to the distribution file. Maybe @wjwwood can clarify.
You won't need to bump the package versions. A simple manual retriggering of the binary jobs should be sufficient. Each package has the timestamp it was build on appended.
> @bchretien @dirk-thomas can you confirm that the first step is ok? If so, I can make a pull request to rosdistro repo and have that out of the way....
> But does the buildfarm check if for example boost was updated and triggers a rebuild? Or is there an API which should be used to externally trigger the rebuild?...
Adding a trigger mechanism to `ros_buildfarm` to rebuild a set of jobs sounds not too difficult. I don't see a reason why this wouldn't get merged.
The build farm does not run `bloom`. The developer runs bloom to populate the release repo and register the package version in the ROS distribution files. The build farm then...
Same for me with the `.deb` build locally from the current default branch.
None of the attributes in roslaunch currently supports this kind of behavior. In order to stay consistent that rule would need to apply to all attributes (e.g. `machine` attribute of...
Please consider to provide a PR to address the problem.