I've worked through the set of patches which I think are fine for 2.6.
Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
is chewing through the build.
I propose a time of testing/monitoring issues on master. Now is the
time to test it with your systems. For convenience, I also updated the
orocos_toolchain git repository such that all submodules point to
their latest master.
Stuff you'd like to try out:
- circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
- fluent typekit imports from all kinds (generated + hand coded +
rtt-native ) in any order
- lua deployers got corba support
- latest versions of orogen/typegen
- things that you reported as broken
There are some open issues, like the service_discovery package... any
resolution there ?
Also, creating eclipse projects in ROS (make eclipse-project) is still
broken although there is a 'fix'. I'd like to have this fix only
enabled when generating for the CDT, ie when the CMAKE_GENERATOR
variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
someone could test that, I could merge this patch in and free these
poor users from their misery. (
http://bugs.orocos.org/show_bug.cgi?id=980 )
Any other urgent matters, reply here.
Peter
Last round !
On Tue, Oct 9, 2012 at 11:38 PM, Peter Soetens <peter [..] ...> wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
>
> Stuff you'd like to try out:
> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> - fluent typekit imports from all kinds (generated + hand coded +
> rtt-native ) in any order
> - lua deployers got corba support
> - latest versions of orogen/typegen
> - things that you reported as broken
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
>
> Also, creating eclipse projects in ROS (make eclipse-project) is still
> broken although there is a 'fix'. I'd like to have this fix only
> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
> someone could test that, I could merge this patch in and free these
> poor users from their misery. (
> http://bugs.orocos.org/show_bug.cgi?id=980 )
>
> Any other urgent matters, reply here.
FYI: 'bool' and 'bools' support is broken on master (running a
standard deployer).
A bool won't be printed in the taskbrowser and trying to use a
'bools' may lead to a segfault.
Probably a victim of the typekit refactoring...
Peter
Last round !
On Tue, Oct 9, 2012 at 11:38 PM, Peter Soetens <peter [..] ...> wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
>
> Stuff you'd like to try out:
> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> - fluent typekit imports from all kinds (generated + hand coded +
> rtt-native ) in any order
> - lua deployers got corba support
> - latest versions of orogen/typegen
> - things that you reported as broken
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
>
> Also, creating eclipse projects in ROS (make eclipse-project) is still
> broken although there is a 'fix'. I'd like to have this fix only
> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
> someone could test that, I could merge this patch in and free these
> poor users from their misery. (
> http://bugs.orocos.org/show_bug.cgi?id=980 )
>
> Any other urgent matters, reply here.
FYI: 'bool' and 'bools' support is broken on master (running a
standard deployer).
A bool won't be printed in the taskbrowser and trying to use a
'bools' may lead to a segfault.
Probably a victim of the typekit refactoring...
Peter
Last round !
On 10/10/2012 10:37 PM, Peter Soetens wrote:
> On Tue, Oct 9, 2012 at 11:38 PM, Peter Soetens<peter [..] ...> wrote:
>> I've worked through the set of patches which I think are fine for 2.6.
>> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>> is chewing through the build.
>>
>> I propose a time of testing/monitoring issues on master. Now is the
>> time to test it with your systems. For convenience, I also updated the
>> orocos_toolchain git repository such that all submodules point to
>> their latest master.
>>
>> Stuff you'd like to try out:
>> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>> - fluent typekit imports from all kinds (generated + hand coded +
>> rtt-native ) in any order
>> - lua deployers got corba support
>> - latest versions of orogen/typegen
>> - things that you reported as broken
>>
>> There are some open issues, like the service_discovery package... any
>> resolution there ?
>>
>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>> broken although there is a 'fix'. I'd like to have this fix only
>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
>> someone could test that, I could merge this patch in and free these
>> poor users from their misery. (
>> http://bugs.orocos.org/show_bug.cgi?id=980 )
>>
>> Any other urgent matters, reply here.
>
> FYI: 'bool' and 'bools' support is broken on master (running a
> standard deployer).
> A bool won't be printed in the taskbrowser and trying to use a
> 'bools' may lead to a segfault.
Yikes! Is this only a taskbrowser-view thing, or will code using bool
variables segfault?
/Sagar
Last round !
On Wed, Oct 10, 2012 at 10:40 PM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> On 10/10/2012 10:37 PM, Peter Soetens wrote:
>> On Tue, Oct 9, 2012 at 11:38 PM, Peter Soetens<peter [..] ...> wrote:
>>> I've worked through the set of patches which I think are fine for 2.6.
>>> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>>> is chewing through the build.
>>>
>>> I propose a time of testing/monitoring issues on master. Now is the
>>> time to test it with your systems. For convenience, I also updated the
>>> orocos_toolchain git repository such that all submodules point to
>>> their latest master.
>>>
>>> Stuff you'd like to try out:
>>> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>>> - fluent typekit imports from all kinds (generated + hand coded +
>>> rtt-native ) in any order
>>> - lua deployers got corba support
>>> - latest versions of orogen/typegen
>>> - things that you reported as broken
>>>
>>> There are some open issues, like the service_discovery package... any
>>> resolution there ?
>>>
>>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>>> broken although there is a 'fix'. I'd like to have this fix only
>>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>>> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
>>> someone could test that, I could merge this patch in and free these
>>> poor users from their misery. (
>>> http://bugs.orocos.org/show_bug.cgi?id=980 )
>>>
>>> Any other urgent matters, reply here.
>>
>> FYI: 'bool' and 'bools' support is broken on master (running a
>> standard deployer).
>> A bool won't be printed in the taskbrowser and trying to use a
>> 'bools' may lead to a segfault.
>
> Yikes! Is this only a taskbrowser-view thing, or will code using bool
> variables segfault?
The unit tests went fine (which stress the type system a lot), so I
guess only taskbrowser / displaying. I'm on it, probably fixed in a
few minutes.
Peter
Last round !
On Wed, Oct 10, 2012 at 10:48 PM, Peter Soetens
<peter [..] ...> wrote:
> On Wed, Oct 10, 2012 at 10:40 PM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
>> On 10/10/2012 10:37 PM, Peter Soetens wrote:
>>> On Tue, Oct 9, 2012 at 11:38 PM, Peter Soetens<peter [..] ...> wrote:
>>>> I've worked through the set of patches which I think are fine for 2.6.
>>>> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>>>> is chewing through the build.
>>>>
>>>> I propose a time of testing/monitoring issues on master. Now is the
>>>> time to test it with your systems. For convenience, I also updated the
>>>> orocos_toolchain git repository such that all submodules point to
>>>> their latest master.
>>>>
>>>> Stuff you'd like to try out:
>>>> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>>>> - fluent typekit imports from all kinds (generated + hand coded +
>>>> rtt-native ) in any order
>>>> - lua deployers got corba support
>>>> - latest versions of orogen/typegen
>>>> - things that you reported as broken
>>>>
>>>> There are some open issues, like the service_discovery package... any
>>>> resolution there ?
>>>>
>>>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>>>> broken although there is a 'fix'. I'd like to have this fix only
>>>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>>>> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
>>>> someone could test that, I could merge this patch in and free these
>>>> poor users from their misery. (
>>>> http://bugs.orocos.org/show_bug.cgi?id=980 )
>>>>
>>>> Any other urgent matters, reply here.
>>>
>>> FYI: 'bool' and 'bools' support is broken on master (running a
>>> standard deployer).
>>> A bool won't be printed in the taskbrowser and trying to use a
>>> 'bools' may lead to a segfault.
>>
>> Yikes! Is this only a taskbrowser-view thing, or will code using bool
>> variables segfault?
>
> The unit tests went fine (which stress the type system a lot), so I
> guess only taskbrowser / displaying. I'm on it, probably fixed in a
> few minutes.
The printing bug has been fixed. The 'bools' type, I removed from ocl's typekit.
std::vector<bool> just isn't supported by RTT.
Peter
Last round !
Hi,
On 10/09/2012 11:38 PM, Peter Soetens wrote:
> Also, creating eclipse projects in ROS (make eclipse-project) is still
> broken although there is a 'fix'. I'd like to have this fix only
> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles"*and* ROS is used. If
> someone could test that, I could merge this patch in and free these
> poor users from their misery. (
> http://bugs.orocos.org/show_bug.cgi?id=980 )
applied the patch to my 2.5.0 version of ocl and it worked
it didn't check wheter 'the CMAKE_GENERATOR
variable equals "Eclipse CDT4 - Unix Makefiles"*and* ROS'
nick
Last round !
On Wed, Oct 10, 2012 at 11:49 AM, Dominick Vanthienen
<dominick [dot] vanthienen [..] ...> wrote:
> Hi,
>
> On 10/09/2012 11:38 PM, Peter Soetens wrote:
>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>> broken although there is a 'fix'. I'd like to have this fix only
>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>> variable equals "Eclipse CDT4 - Unix Makefiles"*and* ROS is used. If
>> someone could test that, I could merge this patch in and free these
>> poor users from their misery. (
>> http://bugs.orocos.org/show_bug.cgi?id=980 )
> applied the patch to my 2.5.0 version of ocl and it worked
> it didn't check wheter 'the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles"*and* ROS'
That's the whole point.... I know it works, but it will break other
builds so we should only enable these two lines when doing a ros build
and generating eclipse project files instead of plain unix makefiles
Peter
Last round !
On 10/09/2012 11:38 PM, Peter Soetens wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
>
> Stuff you'd like to try out:
> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> - fluent typekit imports from all kinds (generated + hand coded +
> rtt-native ) in any order
> - lua deployers got corba support
> - latest versions of orogen/typegen
> - things that you reported as broken
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
>
> Also, creating eclipse projects in ROS (make eclipse-project) is still
> broken although there is a 'fix'. I'd like to have this fix only
> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
> someone could test that, I could merge this patch in and free these
> poor users from their misery. (
> http://bugs.orocos.org/show_bug.cgi?id=980 )
>
> Any other urgent matters, reply here.
btw,
if you generate a package with rosrun ocl orocreate-pkg, it won't compile out of the box:
Linking CXX shared library ../lib/libsupport-gnulinux.so
make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
[ 28%] Built target support
/home/u0065688/sandbox/test_make_eclipse/typekit/transports/typelib/TransportPlugin.cpp:13:25: fatal error: ros/package.h: No such file or directory
compilation terminated.
make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
Scanning dependencies of target test_make_eclipse
make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
[ 33%] Building CXX object CMakeFiles/test_make_eclipse.dir/src/test_make_eclipse-component.cpp.o
make[3]: *** [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o] Error 1
make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
make[2]: *** [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/all] Error 2
is this expected?
>
> Peter
>
Last round !
On Wed, Oct 10, 2012 at 10:28 AM, Dominick Vanthienen
<dominick [dot] vanthienen [..] ...> wrote:
>
>
> On 10/09/2012 11:38 PM, Peter Soetens wrote:
>> I've worked through the set of patches which I think are fine for 2.6.
>> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>> is chewing through the build.
>>
>> I propose a time of testing/monitoring issues on master. Now is the
>> time to test it with your systems. For convenience, I also updated the
>> orocos_toolchain git repository such that all submodules point to
>> their latest master.
>>
>> Stuff you'd like to try out:
>> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>> - fluent typekit imports from all kinds (generated + hand coded +
>> rtt-native ) in any order
>> - lua deployers got corba support
>> - latest versions of orogen/typegen
>> - things that you reported as broken
>>
>> There are some open issues, like the service_discovery package... any
>> resolution there ?
>>
>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>> broken although there is a 'fix'. I'd like to have this fix only
>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
>> someone could test that, I could merge this patch in and free these
>> poor users from their misery. (
>> http://bugs.orocos.org/show_bug.cgi?id=980 )
>>
>> Any other urgent matters, reply here.
>
> btw,
> if you generate a package with rosrun ocl orocreate-pkg, it won't compile out of the box:
>
> Linking CXX shared library ../lib/libsupport-gnulinux.so
> make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
> [ 28%] Built target support
> /home/u0065688/sandbox/test_make_eclipse/typekit/transports/typelib/TransportPlugin.cpp:13:25: fatal error: ros/package.h: No such file or directory
> compilation terminated.
> make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
> Scanning dependencies of target test_make_eclipse
> make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
> make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
> [ 33%] Building CXX object CMakeFiles/test_make_eclipse.dir/src/test_make_eclipse-component.cpp.o
> make[3]: *** [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o] Error 1
> make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
> make[2]: *** [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/all] Error 2
>
> is this expected?
No. The code was not yet tested on Fuerte, only on Electric. A fix has
been pushed to master. You need to update orogen to get it, and then
rebuild your package.
Peter
Last round !
On 10/10/2012 03:28 AM, Dominick Vanthienen wrote:
On 10/09/2012 11:38 PM, Peter Soetens wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
>
> Stuff you'd like to try out:
> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> - fluent typekit imports from all kinds (generated + hand coded +
> rtt-native ) in any order
> - lua deployers got corba support
> - latest versions of orogen/typegen
> - things that you reported as broken
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
>
> Also, creating eclipse projects in ROS (make eclipse-project) is still
> broken although there is a 'fix'. I'd like to have this fix only
> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
> someone could test that, I could merge this patch in and free these
> poor users from their misery. (
> http://bugs.orocos.org/show_bug.cgi?id=980 )
>
> Any other urgent matters, reply here.
btw,
if you generate a package with rosrun ocl orocreate-pkg, it won't compile out of the box:
Linking CXX shared library ../lib/libsupport-gnulinux.so
make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
[ 28%] Built target support
/home/u0065688/sandbox/test_make_eclipse/typekit/transports/typelib/TransportPlugin.cpp:13:25: fatal error: ros/package.h: No such file or directory
compilation terminated.
make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
Scanning dependencies of target test_make_eclipse
make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
[ 33%] Building CXX object CMakeFiles/test_make_eclipse.dir/src/test_make_eclipse-component.cpp.o
make[3]: *** [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o] Error 1
make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
make[2]: *** [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/all] Error 2
is this expected?
I can confirm this behavior. A new hire tried getting started with Orocos and ran into this issue almost immediately. If you only choose 'component' instead of letting orocreate-pkg create everything, it seems to be ok. I think it's an issue with the typekits.
-dustin
>
> Peter
>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...<mailto:Orocos-Dev [..] ...>
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Last round !
On Wed, Oct 10, 2012 at 4:47 PM, Gooding, Dustin R. (JSC-ER411)
<dustin [dot] r [dot] gooding [..] ...> wrote:
> On 10/10/2012 03:28 AM, Dominick Vanthienen wrote:
>
>
>
> On 10/09/2012 11:38 PM, Peter Soetens wrote:
>> I've worked through the set of patches which I think are fine for 2.6.
>> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>> is chewing through the build.
>>
>> I propose a time of testing/monitoring issues on master. Now is the
>> time to test it with your systems. For convenience, I also updated the
>> orocos_toolchain git repository such that all submodules point to
>> their latest master.
>>
>> Stuff you'd like to try out:
>> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>> - fluent typekit imports from all kinds (generated + hand coded +
>> rtt-native ) in any order
>> - lua deployers got corba support
>> - latest versions of orogen/typegen
>> - things that you reported as broken
>>
>> There are some open issues, like the service_discovery package... any
>> resolution there ?
>>
>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>> broken although there is a 'fix'. I'd like to have this fix only
>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
>> someone could test that, I could merge this patch in and free these
>> poor users from their misery. (
>> http://bugs.orocos.org/show_bug.cgi?id=980 )
>>
>> Any other urgent matters, reply here.
>
> btw,
> if you generate a package with rosrun ocl orocreate-pkg, it won't compile
> out of the box:
>
> Linking CXX shared library ../lib/libsupport-gnulinux.so
> make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
> [ 28%] Built target support
> /home/u0065688/sandbox/test_make_eclipse/typekit/transports/typelib/TransportPlugin.cpp:13:25:
> fatal error: ros/package.h: No such file or directory
> compilation terminated.
> make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
> Scanning dependencies of target test_make_eclipse
> make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
> make[3]: Entering directory `/home/u0065688/sandbox/test_make_eclipse/build'
> [ 33%] Building CXX object
> CMakeFiles/test_make_eclipse.dir/src/test_make_eclipse-component.cpp.o
> make[3]: ***
> [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o]
> Error 1
> make[3]: Leaving directory `/home/u0065688/sandbox/test_make_eclipse/build'
> make[2]: ***
> [typekit/transports/typelib/CMakeFiles/test_make_eclipse-transport-typelib-gnulinux.dir/all]
> Error 2
>
> is this expected?
>
> I can confirm this behavior. A new hire tried getting started with Orocos
> and ran into this issue almost immediately. If you only choose 'component'
> instead of letting orocreate-pkg create everything, it seems to be ok. I
> think it's an issue with the typekits.
I'll look at this later today. It's probably one of the last patches
on master which caused this.
Peter
Last round !
On 10/09/2012 11:38 PM, Peter Soetens wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
Do you actually have a jenkins doing the autoproj builds ? Given the
errors we encounter, I am starting to wonder ...
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
I'm also going to push RTT master on rock-rtt master to test in master.
That is only going to happen end of next week as we update stable and
next next week
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
No, since the opinion of the orocos devs was not very clear to me. So
far, I marked the dependency as optional and left the package in rock.
Sylvain
Last round !
On 10/09/2012 11:38 PM, Peter Soetens wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
Do you actually have a jenkins doing the autoproj builds ? Given the
errors we encounter, I am starting to wonder ...
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
I'm also going to push RTT master on rock-rtt master to test in master.
That is only going to happen end of next week as we update stable and
next next week
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
No, since the opinion of the orocos devs was not very clear to me. So
far, I marked the dependency as optional and left the package in rock.
Sylvain
Last round !
A Dimarts, 9 d'octubre de 2012, Peter Soetens va escriure:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
>
> Stuff you'd like to try out:
> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> - fluent typekit imports from all kinds (generated + hand coded +
> rtt-native ) in any order
> - lua deployers got corba support
> - latest versions of orogen/typegen
> - things that you reported as broken
>
> There are some open issues, like the service_discovery package... any
> resolution there ?
>
> Also, creating eclipse projects in ROS (make eclipse-project) is still
> broken although there is a 'fix'. I'd like to have this fix only
> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
> someone could test that, I could merge this patch in and free these
> poor users from their misery. (
> http://bugs.orocos.org/show_bug.cgi?id=980 )
>
> Any other urgent matters, reply here.
>
Are you sure that the deployer-xenomai share the load between cpus? We have
different behavior (in load) if we compile with xenomai target or gnulinux
target.
Regards,
Leo
Last round !
On Wed, Oct 10, 2012 at 12:24 AM, Leopold Palomo-Avellaneda
<leopold [dot] palomo [..] ...> wrote:
> A Dimarts, 9 d'octubre de 2012, Peter Soetens va escriure:
>> I've worked through the set of patches which I think are fine for 2.6.
>> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>> is chewing through the build.
>>
>> I propose a time of testing/monitoring issues on master. Now is the
>> time to test it with your systems. For convenience, I also updated the
>> orocos_toolchain git repository such that all submodules point to
>> their latest master.
>>
>> Stuff you'd like to try out:
>> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>> - fluent typekit imports from all kinds (generated + hand coded +
>> rtt-native ) in any order
>> - lua deployers got corba support
>> - latest versions of orogen/typegen
>> - things that you reported as broken
>>
>> There are some open issues, like the service_discovery package... any
>> resolution there ?
>>
>> Also, creating eclipse projects in ROS (make eclipse-project) is still
>> broken although there is a 'fix'. I'd like to have this fix only
>> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
>> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
>> someone could test that, I could merge this patch in and free these
>> poor users from their misery. (
>> http://bugs.orocos.org/show_bug.cgi?id=980 )
>>
>> Any other urgent matters, reply here.
>>
>
> Are you sure that the deployer-xenomai share the load between cpus? We have
> different behavior (in load) if we compile with xenomai target or gnulinux
> target.
It's not shared. Xenomai runs all real-time threads on CPU 0 by
default. You need to use the affinity functionality of threads.
On our systems, we didn't get affinity for Xenomai working, although
we couldn't spot any problem in xenomai/fosi_internal.cpp. We didn't
build a pure Xenomai test program, which is probably the first thing
we should have done...
In short, this is still broken on master (or our Xenomai setup was broken).
Peter
Last round !
A Dimecres 10 Octubre 2012, Peter Soetens va escriure:
> On Wed, Oct 10, 2012 at 12:24 AM, Leopold Palomo-Avellaneda
> <leopold [dot] palomo [..] ...> wrote:
> > A Dimarts, 9 d'octubre de 2012, Peter Soetens va escriure:
> >> I've worked through the set of patches which I think are fine for 2.6.
> >> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> >> is chewing through the build.
> >>
> >> I propose a time of testing/monitoring issues on master. Now is the
> >> time to test it with your systems. For convenience, I also updated the
> >> orocos_toolchain git repository such that all submodules point to
> >> their latest master.
> >>
> >> Stuff you'd like to try out:
> >> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> >> - fluent typekit imports from all kinds (generated + hand coded +
> >> rtt-native ) in any order
> >> - lua deployers got corba support
> >> - latest versions of orogen/typegen
> >> - things that you reported as broken
> >>
> >> There are some open issues, like the service_discovery package... any
> >> resolution there ?
> >>
> >> Also, creating eclipse projects in ROS (make eclipse-project) is still
> >> broken although there is a 'fix'. I'd like to have this fix only
> >> enabled when generating for the CDT, ie when the CMAKE_GENERATOR
> >> variable equals "Eclipse CDT4 - Unix Makefiles" *and* ROS is used. If
> >> someone could test that, I could merge this patch in and free these
> >> poor users from their misery. (
> >> http://bugs.orocos.org/show_bug.cgi?id=980 )
> >>
> >> Any other urgent matters, reply here.
> >>
> >
> > Are you sure that the deployer-xenomai share the load between cpus? We
have
> > different behavior (in load) if we compile with xenomai target or gnulinux
> > target.
>
> It's not shared. Xenomai runs all real-time threads on CPU 0 by
> default. You need to use the affinity functionality of threads.
we have done that and it doesn't works.
> On our systems, we didn't get affinity for Xenomai working, although
> we couldn't spot any problem in xenomai/fosi_internal.cpp. We didn't
> build a pure Xenomai test program, which is probably the first thing
> we should have done...
ok.
> In short, this is still broken on master (or our Xenomai setup was broken).
>
Thanks, just to clarify. We have an interesting thread about DDS, using non-
realtime library function calls in a realtime component, etc. and, maybe I'm
lost in this aspect, and the key to solve this kind of problems is to mix non-
realtime components with the ORO_SCHED_OTHERS and realtime components with
ORO_SCHED_RT.
But one interesting thing of orocos is to develop using gnulinux for testing
proposes and after, compile the same components against the realtime
infrastructure. By now, we cannot do it that because the affinity
functionality, IMHO. But, I insist, maybe I'm wrong and it can be solved in
another way.
Regards,
Leo
Last round !
On 10/09/2012 11:38 PM, Peter Soetens wrote:
> I've worked through the set of patches which I think are fine for 2.6.
> Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> is chewing through the build.
>
> I propose a time of testing/monitoring issues on master. Now is the
> time to test it with your systems. For convenience, I also updated the
> orocos_toolchain git repository such that all submodules point to
> their latest master.
>
> Stuff you'd like to try out:
> - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> - fluent typekit imports from all kinds (generated + hand coded +
> rtt-native ) in any order
> - lua deployers got corba support
> - latest versions of orogen/typegen
> - things that you reported as broken
Built the toolchain from master a few minutes ago. All previous build
issues are fixed, with one exception. It is still necessary to remove
the line regarding libncurses-dev from ocl/manifest.xml, else the build
halts with
---
manifest /home/sagar/excludes/orocos-toolchain/ocl/manifest.xml of ocl
from orocos.toolchain lists 'libncurses-dev' as dependency, but it is
neither a normal package nor an osdeps package. osdeps reports: there is
no osdeps definition for libncurses-dev
---
I also noted the following issue with typekits. After doing
orocreate-pkg MyTypes typekit; cd MyTypes/ ; mkdir build ; cd build ;
ccmake -i .. ; make install
the deployer gives the message
----
18.683 [ ERROR ][DeploymentComponent::import] could not load library
'/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so':
libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
file or directory
18.684 [ ERROR ][DeploymentComponent::import] could not load library
'/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so':
libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
file or directory
18.716 [ ERROR ][DeploymentComponent::import] Some found plugins could
not be loaded !
----
The 'No such file or directory' message is misleading, because those
files exist. It picked up the libMyTypes-transport-typelib-gnulinux.so
and libMyTypes-typekit-gnulinux.so present in the same directory and I
can see that the custom types are indeed loaded with the .types command.
System: Debian Wheezy, g++ 4.7.1
Regards,
Sagar
Last round !
On 10/10/2012 12:09 AM, Sagar Behere wrote:
> ----
> 18.683 [ ERROR ][DeploymentComponent::import] could not load library
> '/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so':
> libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
> file or directory
> 18.684 [ ERROR ][DeploymentComponent::import] could not load library
> '/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so':
> libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
> file or directory
> 18.716 [ ERROR ][DeploymentComponent::import] Some found plugins could
> not be loaded !
> ----
>
> The 'No such file or directory' message is misleading, because those
> files exist. It picked up the libMyTypes-transport-typelib-gnulinux.so
> and libMyTypes-typekit-gnulinux.so present in the same directory and I
> can see that the custom types are indeed loaded with the .types command.
>
Could you try to install chrpath with apt-get install chrpath, run the
following three commands and post the result ?
chrpath -l
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so
chrpath -l
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so
chrpath -l
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so
As Peter said, thanks a lot for your patience :-)
Last round !
On 10/10/2012 09:45 AM, Sylvain Joyeux wrote:
> On 10/10/2012 12:09 AM, Sagar Behere wrote:
>> ----
>> 18.683 [ ERROR ][DeploymentComponent::import] could not load library
>> '/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so':
>>
>> libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
>> file or directory
>> 18.684 [ ERROR ][DeploymentComponent::import] could not load library
>> '/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so':
>>
>> libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
>> file or directory
>> 18.716 [ ERROR ][DeploymentComponent::import] Some found plugins could
>> not be loaded !
>> ----
>>
>> The 'No such file or directory' message is misleading, because those
>> files exist. It picked up the libMyTypes-transport-typelib-gnulinux.so
>> and libMyTypes-typekit-gnulinux.so present in the same directory and I
>> can see that the custom types are indeed loaded with the .types command.
>>
> Could you try to install chrpath with apt-get install chrpath, run the
> following three commands and post the result ?
>
> chrpath -l
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so
>
> chrpath -l
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so
>
> chrpath -l
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so
Background:
orocos installed in /home/sagar/oroom/orocos-toolchain/install
MyTypes typekit installed in /home/sagar/oroom/tmp
When deployer is started, I run the following command to pull in the
typekits
Deployer [S]> import("/home/sagar/oroom/tmp/lib/orocos/")
----begin: chrpath output----
sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so:
RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so:
RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so
/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so:
RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ deployer
----end: chrpath output----
immediately after this, the deployer is started and
----------
Deployer [S]> import("/home/sagar/oroom/tmp/lib/orocos/")
4.515 [ ERROR ][DeploymentComponent::import] could not load library
'/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so':
libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
file or directory
4.516 [ ERROR ][DeploymentComponent::import] could not load library
'/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so':
libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
file or directory
4.547 [ ERROR ][DeploymentComponent::import] Some found plugins could
not be loaded !
The command 'import("/home/sagar/oroom/tmp/lib/orocos/")' caused a
std::exception: 'Unable to complete the operation call. The called
operation has thrown an exception' and could not be completed.
Deployer [X]> .typekits
Available Typekits: rtt-corba-types rtt-types rtt-mqueue-transport
OCLTypekit /orogen/MyTypes/TYPELIB /orogen/MyTypes
Deployer [X]> .types
Available data types: MyTypesData std.string std.vector<double>
ConnPolicy FlowStatus PropertyBag SendHandle SendStatus TaskContext
array bool bools char double float int ints rt_string string strings
uint void
Deployer [X]>
----------
Note the availability of typekit /orogen/MyTypes/TYPELIB and
/orogen/MyTypes and the availability of the MyTypesData datatype which
this typekit contains.
Regards,
Sagar
Last round !
On 10/10/2012 10:55 AM, Sagar Behere wrote:
> ----begin: chrpath output----
> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so
>
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so:
> RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
>
> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so
>
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so:
> RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
>
> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so
>
> /home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so:
> RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
>
> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ deployer
> ----end: chrpath output----
>
> immediately after this, the deployer is started and
OK, so:
- on Rock (i.e. for orogen components), lib/orocos/types is part of
the RPATH. I will have to look why it is not the case with typegen
- I don't know why the typelib transport library loads fine
Last round !
Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>On 10/10/2012 10:55 AM, Sagar Behere wrote:
>> ----begin: chrpath output----
>> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
>>
>/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so
>>
>>
>/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so:
>>
>RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
>>
>> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
>>
>/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so
>>
>>
>/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-typelib-gnulinux.so:
>>
>RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
>>
>> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ chrpath -l
>>
>/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so
>>
>>
>/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so:
>>
>RPATH=/home/sagar/oroom/tmp/lib:/home/sagar/oroom/tmp/lib/orocos:/home/sagar/oroom/orocos-toolchain/install/lib
>>
>> sagar@mightymagic:~/oroom/orocos-playground/MyTypes/build$ deployer
>> ----end: chrpath output----
>>
>> immediately after this, the deployer is started and
>OK, so:
>
> - on Rock (i.e. for orogen components), lib/orocos/types is part of
> the RPATH. I will have to look why it is not the case with typegen
Okay, but is that the issue here? The deployer error message states the full path of the .so file, and then claims the file doesn't exist.
/Sagar
> - I don't know why the typelib transport library loads fine
Last round !
On 10/10/2012 11:37 AM, Sagar Behere wrote:
> Okay, but is that the issue here? The deployer error message states the full path of the .so file, and then claims the file doesn't exist.
Actually not. It is showing the full path to the transport, but then the
error only shows the basename of the typekit shared object (i.e. the
library that it cannot find). That's consistent with the wrong RPATH.
Last round !
2012/10/10 Sagar Behere <sagar [dot] behere [..] ...>
> On 10/09/2012 11:38 PM, Peter Soetens wrote:
> > I've worked through the set of patches which I think are fine for 2.6.
> > Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
> > is chewing through the build.
> >
> > I propose a time of testing/monitoring issues on master. Now is the
> > time to test it with your systems. For convenience, I also updated the
> > orocos_toolchain git repository such that all submodules point to
> > their latest master.
> >
> > Stuff you'd like to try out:
> > - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
> > - fluent typekit imports from all kinds (generated + hand coded +
> > rtt-native ) in any order
> > - lua deployers got corba support
> > - latest versions of orogen/typegen
> > - things that you reported as broken
>
> Built the toolchain from master a few minutes ago. All previous build
> issues are fixed, with one exception. It is still necessary to remove
> the line regarding libncurses-dev from ocl/manifest.xml, else the build
> halts with
>
> ---
> manifest /home/sagar/excludes/orocos-toolchain/ocl/manifest.xml of ocl
> from orocos.toolchain lists 'libncurses-dev' as dependency, but it is
> neither a normal package nor an osdeps package. osdeps reports: there is
> no osdeps definition for libncurses-dev
> ---
>
The dep is missing from the package set osdeps.
Patch attached.
>
> I also noted the following issue with typekits. After doing
>
> orocreate-pkg MyTypes typekit; cd MyTypes/ ; mkdir build ; cd build ;
> ccmake -i .. ; make install
>
> the deployer gives the message
>
> ----
> 18.683 [ ERROR ][DeploymentComponent::import] could not load library
>
> '/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-corba-gnulinux.so':
> libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
> file or directory
> 18.684 [ ERROR ][DeploymentComponent::import] could not load library
>
> '/home/sagar/oroom/tmp/lib/orocos/types/libMyTypes-transport-mqueue-gnulinux.so':
> libMyTypes-typekit-gnulinux.so: cannot open shared object file: No such
> file or directory
> 18.716 [ ERROR ][DeploymentComponent::import] Some found plugins could
> not be loaded !
> ----
>
> The 'No such file or directory' message is misleading, because those
> files exist. It picked up the libMyTypes-transport-typelib-gnulinux.so
> and libMyTypes-typekit-gnulinux.so present in the same directory and I
> can see that the custom types are indeed loaded with the .types command.
>
> System: Debian Wheezy, g++ 4.7.1
>
> Regards,
> Sagar
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Last round !
On Wed, Oct 10, 2012 at 7:49 AM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
> 2012/10/10 Sagar Behere <sagar [dot] behere [..] ...>
>>
>> On 10/09/2012 11:38 PM, Peter Soetens wrote:
>> > I've worked through the set of patches which I think are fine for 2.6.
>> > Sylvain merged the rock changes to the orocos-toolchain. And Jenkins
>> > is chewing through the build.
>> >
>> > I propose a time of testing/monitoring issues on master. Now is the
>> > time to test it with your systems. For convenience, I also updated the
>> > orocos_toolchain git repository such that all submodules point to
>> > their latest master.
>> >
>> > Stuff you'd like to try out:
>> > - circular buffers connection policy (DATA, BUFFER, CIRCULAR_BUFFER).
>> > - fluent typekit imports from all kinds (generated + hand coded +
>> > rtt-native ) in any order
>> > - lua deployers got corba support
>> > - latest versions of orogen/typegen
>> > - things that you reported as broken
>>
>> Built the toolchain from master a few minutes ago. All previous build
>> issues are fixed, with one exception. It is still necessary to remove
>> the line regarding libncurses-dev from ocl/manifest.xml, else the build
>> halts with
>>
>> ---
>> manifest /home/sagar/excludes/orocos-toolchain/ocl/manifest.xml of ocl
>> from orocos.toolchain lists 'libncurses-dev' as dependency, but it is
>> neither a normal package nor an osdeps package. osdeps reports: there is
>> no osdeps definition for libncurses-dev
>> ---
>
>
> The dep is missing from the package set osdeps.
> Patch attached.
I have pushed this one to master.
Peter