ROS Fuerte base packages all posted

[Rich Mattes]

Hi all,

I managed to get the rest of the packages required for the ROS fuerte 
base[1] packaged and posted to bugzilla!  Hooray!  The full list of 
review requests:

rospack: https://bugzilla.redhat.com/show_bug.cgi?id=927458
ros: https://bugzilla.redhat.com/show_bug.cgi?id=927461
roscpp_core: https://bugzilla.redhat.com/show_bug.cgi?id=927462
python-genmsg: https://bugzilla.redhat.com/show_bug.cgi?id=927470
python-gencpp: https://bugzilla.redhat.com/show_bug.cgi?id=927473
python-genlisp: https://bugzilla.redhat.com/show_bug.cgi?id=927475
python-genpy: https://bugzilla.redhat.com/show_bug.cgi?id=927478
ros-std_msgs: https://bugzilla.redhat.com/show_bug.cgi?id=928584
ros_comm: https://bugzilla.redhat.com/show_bug.cgi?id=972345
ros-common_msgs: https://bugzilla.redhat.com/show_bug.cgi?id=972346
actionlib: https://bugzilla.redhat.com/show_bug.cgi?id=972348

I'll be trying to do some review swaps on -devel in the coming days to 
get things moving.  There may still be a few rough edges in some of the 
packages, but I've got time this summer to get them into shape and ready 
to go.  My initial smoke testing shows that utilities like roscore, 
rosbag, rosstack, rospack, etc. all work after /usr/share/ros/setup.sh 
is sourced.

Rich

[1] http://ros.org/rosinstalls/fuerte-ros-base.rosinstall

[Ankur Sinha]

On Sat, 2013-06-08 at 15:22 -0400, Rich Mattes wrote:
> I'll be trying to do some review swaps on -devel in the coming days
> to 
> get things moving.

Hi Rich,

I'll have a few more cycles to work on these once the elections finish
next week.

I had another brain fart on packaging groovy up, in a manner similar to
how the texlive[1] (the spec is scary, please view at your own risk!)
package is done:

1. Use one master spec that goes "ros-groovy"
2. Checkout the entire source via wstool and build it in the spec as
detailed[2]
3. Figure out BRs and add them to spec: can be done from manifests
4. Figure out Requires and add them to the sub-packages: can be done
from the manifests.
5. Put all files for the stacks/packages into sub-packages:
ros-groovy-<stack>

All the core utils can be packaged separately like you've done them
already.

Jindrich wrote a C program[3] iirc that went over the source tree and
spewed out a spec. If required, we could do that too. The info required
to build this stuff is mostly in the manifests. A simple xml parser
program should be enough if we think of scripting it up.

The advantage here is that it'll be built as documented which should be
comparatively easy, and all at once. The disadvantage is that an update
to any of the modules will require a complete rebuild. This is bad on
the build side only. With delta rpm, users won't (shouldn't) get any
updates to the unchanged sub packages.

I've been meaning to try this out. Just haven't found the cycles :/

Even if we deploy it in /opt, we can still host a
repos.fedoraproject.org repo owned by the robotics group.

The same method can be applied to most ros versions, since they believe
in the "let's build it all once" system.

Comments?
[1] http://pkgs.fedoraproject.org/cgit/texlive.git/tree/texlive.spec
[2] http://www.ros.org/wiki/groovy/Installation/Fedora
[3] http://pkgs.fedoraproject.org/cgit/texlive.git/tree/tl2rpm.c

[Rich Mattes]

On 06/15/2013 11:44 PM, Ankur Sinha wrote:
> On Sat, 2013-06-08 at 15:22 -0400, Rich Mattes wrote:
> > I'll be trying to do some review swaps on -devel in the coming days
> > to
> > get things moving.
>
> Hi Rich,
>
> I'll have a few more cycles to work on these once the elections finish
> next week.
>
> I had another brain fart on packaging groovy up, in a manner similar to
> how the texlive[1] (the spec is scary, please view at your own risk!)
> package is done:
> Use one master spec that goes "ros-groovy"
> Checkout the entire source via wstool and build it in the spec as
>
> detailed[2]
> 3. Figure out BRs and add them to spec: can be done from manifests
> 4. Figure out Requires and add them to the sub-packages: can be done
> from the manifests.
> 5. Put all files for the stacks/packages into sub-packages:
> ros-groovy-<stack>
>
> All the core utils can be packaged separately like you've done them
> already.
>
> Jindrich wrote a C program[3] iirc that went over the source tree and
> spewed out a spec. If required, we could do that too. The info required
> to build this stuff is mostly in the manifests. A simple xml parser
> program should be enough if we think of scripting it up.

I think we might be better off trying to extend the upstream "bloom" 
tool[1].  It's already got the logic to parse the xml files and pull out 
the build requirements, and they're using it upstream to spit out the 
control files for their deb files.  It's pluggable, and it probably 
wouldn't be that hard to add a spec file generator along side their 
debian generator (which is located in the source at bloom/generators)
> The advantage here is that it'll be built as documented which should be
> comparatively easy, and all at once. The disadvantage is that an update
> to any of the modules will require a complete rebuild. This is bad on
> the build side only. With delta rpm, users won't (shouldn't) get any
> updates to the unchanged sub packages.
>
> I've been meaning to try this out. Just haven't found the cycles :/

I'm in the same boat.  I'm trying to focus most of my time on trying to 
get the fuerte base finished up (and other miscellaneous bugfixes to my 
packages).  But in the long run
> Even if we deploy it in /opt, we can still host a
> repos.fedoraproject.org repo owned by the robotics group.

That wouldn't be a bad idea.  We might also be able to request group 
privileges for the copr repositories as well.  I think once the fuerte 
packages are in we can try to explore infrastructure for packages that 
land in /opt

Rich

[1] https://github.com/ros-infrastructure/bloom

[Ankur Sinha]

On Sun, 2013-07-21 at 16:48 -0400, Rich Mattes wrote:
> I think we might be better off trying to extend the upstream "bloom" 
> tool[1].  It's already got the logic to parse the xml files and pull
> out 
> the build requirements, and they're using it upstream to spit out the 
> control files for their deb files.  It's pluggable, and it probably 
> wouldn't be that hard to add a spec file generator along side their 
> debian generator (which is located in the source at bloom/generators)

I looked into bloom briefly. It seems to be tightly integrated with
github, specially their repositories. It generates entire packages,
doesn't it? Can we deploy it locally and use it to generate rpms? I'm
not quite sure..