[ros-users] Indigo buildfarm ready for releases

Jon Binney jon.binney at gmail.com
Sat Mar 29 09:06:21 UTC 2014


I've written up a tutorial on how to install indigo in a chroot on ubuntu
13.04 and compile ros packages:
http://wiki.ros.org/ROS/Tutorials/InstallingIndigoInChroot

It works for me on 13.04; fixes are welcome!


On Fri, Mar 28, 2014 at 3:00 PM, Jon Binney <jon.binney at gmail.com> wrote:

> Yeah, the system dependencies such as gazebo would definitely be
> problematic, so I understand if it isn't feasible. Maybe worth coming up
> with a quick list of what system dependencies have problematic version
> changes between precise and trusty, to gauge the difficulty of this
> approach?
>
>
> On Fri, Mar 28, 2014 at 12:05 PM, William Woodall <
> william at osrfoundation.org> wrote:
>
>> On Thu, Mar 27, 2014 at 4:36 PM, Jon Binney <jon.binney at gmail.com> wrote:
>>
>>> As has already been identified in this thread, building Hydro from
>>>> source on other systems (Ubuntu Saucy, Ubuntu Trusty) currently works
>>>> quite smoothly, with the caveat being the ~30 minute build time for
>>>> Hydro-desktop, which is of course dependent on one's internet
>>>> bandwidth and system performance.
>>>>
>>>
>>> If it builds from source on other platforms, would there still be
>>> significant developer effort to create debs? Or do you mean that only the
>>> core packages in hydro build from source on Saucy/Trusty?
>>>
>>> The ideal situation from a developer point of view would be if there
>>> were indigo debs for ubuntu precise. This would allow people who are
>>> running hydro/precise to update their own packages so that they work with
>>> indigo, and then to install ubuntu trusty on their machines. It would be
>>> essentially the same as when we switched from electric to fuerte - fuerte
>>> had debs on lucid, but also had debs for precise.
>>>
>>
>> Generally any time you port forward (add debs for a new ubuntu for an
>> existing ROS distro) or backwards (create debs for a new ROS distro on
>> ubuntu platforms that are older or unsupported), there is going to be some
>> significant work involved.
>>
>> However, we are not as far along in the Indigo first time releases, so
>> having bloom start to make debian files for Indigo on Precise is tractable,
>> but still a lot of work to re-bloom already released things. The other
>> problem with backporting Indigo to precise is the changes in dependencies.
>> This is not generally a problem with things like boost or log4cxx, but in
>> this case Gazebo is a good example of a problem. Gazebo's default in
>> precise is 1.x and in trusty it is 2.x, so now any ROS packages which
>> should be released into Indigo not only need to update for 2.x Gazebo, but
>> also needs to be backwards compatible with Gazebo 1.x. To avoid that, you
>> could install the gazebo2 deb on precise for Indigo, but I believe (could
>> be wrong) that the gazebo2 deb cannot be installed at the same time as the
>> gazebo1 deb, so then you wouldn't be able to have Indigo above gazebo and
>> Hydro above gazebo installed at the same time.
>>
>> Gazebo is just an example, and while there are solutions to these
>> problems, they always take effort, not just for us but for maintainers.
>>
>> Unlike Hydro on Trusty, I believe Indigo on Precise is tractable, but
>> still a big cost in terms of engineering time.
>>
>>
>>>
>>> That being said, I understand that it's a huge effort to support extra
>>> distributions, so this may not be practical.
>>>
>>> -Jon
>>>
>>>
>>>
>>>>
>>>> Taking these considerations into account, we think the best approach
>>>> is to improve the experience of building ROS distributions from
>>>> source, so they can be used more easily on distros for which they were
>>>> not originally targeted. There are various things that could be done
>>>> to improve the build-from-source process: better/easier documentation
>>>> [1], better/easier software tools to automate the process [2], and so
>>>> on. If you are interested in participating, ros-sig-buildsystem [3]
>>>> would be a good place for such documentation/tool development and
>>>> discussion.
>>>>
>>>> Cheers,
>>>> Morgan
>>>>
>>>> [1] http://wiki.ros.org/hydro/Installation/Source
>>>> [2] perhaps the tools could display cat photos in ASCII art during the
>>>> build.
>>>> [3] https://groups.google.com/forum/#!forum/ros-sig-buildsystem
>>>>
>>>> On Thu, Mar 27, 2014 at 11:19 AM, Jochen Sprickerhof
>>>> <ros-users at jochen.sprickerhof.de> wrote:
>>>> > * Michael Fritscher <michael.fritscher at telematik-zentrum.de>
>>>> [2014-03-27 18:08]:
>>>> >> But in my experience, apt can handle about every kind of abuse
>>>> fairly well -
>>>> >> to be honest I've done way trickier things in the past without any
>>>> problems.
>>>> >
>>>> > Yes, I did these tricks myself aswell. But as Jack wrote, we should
>>>> not
>>>> > propose it as the official way, as it's too fragile to maintain in
>>>> > larger installations. But if you want to do it cleanly, use a chroot
>>>> > (have a look at the schroot package), this is what I use nowadays.
>>>> >
>>>> > Cheers Jochen
>>>> >
>>>> > _______________________________________________
>>>> > ros-users mailing list
>>>> > ros-users at lists.ros.org
>>>> > http://lists.ros.org/mailman/listinfo/ros-users
>>>> >
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at lists.ros.org
>>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at lists.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>>
>> --
>> William Woodall
>> ROS Development Team
>> william at osrfoundation.org
>> http://williamjwoodall.com/
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140329/0725384e/attachment.html>


More information about the ros-users mailing list