building RTT and OCL debian packages
| Submitted by Steven Kauffmann on Mon, 2009-11-16 19:28 |
Hi all,
I'm following the Orocos RTT wiki in order to build debian packages.
Building RTT debian packages for gnulinux was not a problem.
The next step explained on the wiki is to build KDL. However I don't
need KDL so I give it a try to build packages OCL without KDL
installed. Unfortunately OCL has a build-dependency on orocos-kdl.
Removing this dependency in debian/control solves the missing
dependency error.
Is it not possible to add orocos-kdl as an optional build-dependency?
The build process of SocketCANcontroller failed because of a missing
header on my system (debian etch) linux/can.h. This header file is
available in the linux-libc-dev package. Looks like this is a missing
build-dependency of OCL (only for gnulinux)?
The next build error is because my version of libcomedi is not
compatible with ocl-1.10. Upgrading to libcomedi-0.8 solves the
problem. Libcomedi is a build dependency but a minimum version is not
specified. Putting libcomedi-dev (>= 0.8) as a build-dependency solves
this issue.
Debian packages are now created for gnulinux however some files are
reported as not copied into a deb package.
* ocl-config.h ( in liborocos-ocl-sover-dev.install ? )
* netcdf-reporter files ( in liborocos-ocl-sover-dev.install ? )
Steven
building RTT and OCL debian packages
On Mon, Nov 16, 2009 at 20:24, Steven Kauffmann
<steven [dot] kauffmann [..] ...> wrote:
> Hi all,
>
> I'm following the Orocos RTT wiki in order to build debian packages.
> Building RTT debian packages for gnulinux was not a problem.
> The next step explained on the wiki is to build KDL. However I don't
> need KDL so I give it a try to build packages OCL without KDL
> installed. Unfortunately OCL has a build-dependency on orocos-kdl.
> Removing this dependency in debian/control solves the missing
> dependency error.
> Is it not possible to add orocos-kdl as an optional build-dependency?
Build dependencies can never be optional. If you build a package, you
need all of them.
>
> The build process of SocketCANcontroller failed because of a missing
> header on my system (debian etch) linux/can.h. This header file is
> available in the linux-libc-dev package. Looks like this is a missing
> build-dependency of OCL (only for gnulinux)?
Yes, needs to be added.
>
> The next build error is because my version of libcomedi is not
> compatible with ocl-1.10. Upgrading to libcomedi-0.8 solves the
> problem. Libcomedi is a build dependency but a minimum version is not
> specified. Putting libcomedi-dev (>= 0.8) as a build-dependency solves
> this issue.
Correct.
>
> Debian packages are now created for gnulinux however some files are
> reported as not copied into a deb package.
> * ocl-config.h ( in liborocos-ocl-sover-dev.install ? )
> * netcdf-reporter files ( in liborocos-ocl-sover-dev.install ? )
2x yes.
If you're quick with your diff (*and* I am quick), this can get into 1.10.2 :-)
Peter
building RTT and OCL debian packages
When installing the generated OCL debian packages, package
orocos-ocl-gnulinux1.10 depends on
liborocos-ocl-cartesian-gnulinux1.10 however this package is not
generated. I can't even find it in the control file (except the
dependency). Is this because I disabled KDL?
I'm also building debian packages of RTT and OCL for xenomai. In the
generated control file only the package liborocos-rtt-xenomai1.10-dev
has a dependency on xenomai. This looks like I can install
orocos-xenomai without xenomai installed (when not installing the
dev-packages). Is this correct?
When building OCL packages for xenomai, a build dependency is missing.
Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
cmake complains that RTT for xenomai can not be found. Is this a
missing build dependency or is this a missing dependency on
liborocos-rtt-corba-xenomai1.10-dev?
We noticed that RTSocketCAN is not build (when xenomai target is
selected), only SocketCAN. Modifying the file CMakeCanComedi.txt +
some .install files solved that problem. When I tried to install the
generated packages, aptitude returns an error because
liborocos-ocl-can1.10-dev is a virtual package. Did I forgot something
to modify?
Steven
building RTT and OCL debian packages
On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
<steven [dot] kauffmann [..] ...> wrote:
> When installing the generated OCL debian packages, package
> orocos-ocl-gnulinux1.10 depends on
> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
> generated. I can't even find it in the control file (except the
> dependency). Is this because I disabled KDL?
Due to API instabilities in KDL, I had to drop the cartesian packages
from the control.common file. So this dependency (and the build dep)
needs to be removed
as well.
>
> I'm also building debian packages of RTT and OCL for xenomai. In the
> generated control file only the package liborocos-rtt-xenomai1.10-dev
> has a dependency on xenomai.
That is correct.
> This looks like I can install
> orocos-xenomai without xenomai installed (when not installing the
> dev-packages). Is this correct?
No :-] The dependency on libxenomai.so must be picked up by the
${shlibs:Depends}
tag. Check the final dependencies with apt-cache show package-name
>
> When building OCL packages for xenomai, a build dependency is missing.
> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
> cmake complains that RTT for xenomai can not be found. Is this a
> missing build dependency or is this a missing dependency on
> liborocos-rtt-corba-xenomai1.10-dev?
It looks like a bug in the rtt control-template.in file. The first
package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
liborocos-rtt-@TARGET@@LIBVER@-dev
This dependency is missing.
>
> We noticed that RTSocketCAN is not build (when xenomai target is
> selected), only SocketCAN. Modifying the file CMakeCanComedi.txt +
> some .install files solved that problem.
Ok.
> When I tried to install the
> generated packages, aptitude returns an error because
> liborocos-ocl-can1.10-dev is a virtual package. Did I forgot something
> to modify?
Strange, it is declared in control.common and also has an install
file. How did you try to install ? Did you use dpkg -i
liborocos-ocl*deb ?
Peter
building RTT and OCL debian packages
On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
<peter [..] ...> wrote:
> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
> <steven [dot] kauffmann [..] ...> wrote:
>> When installing the generated OCL debian packages, package
>> orocos-ocl-gnulinux1.10 depends on
>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>> generated. I can't even find it in the control file (except the
>> dependency). Is this because I disabled KDL?
>
> Due to API instabilities in KDL, I had to drop the cartesian packages
> from the control.common file. So this dependency (and the build dep)
> needs to be removed
> as well.
>
>>
>> I'm also building debian packages of RTT and OCL for xenomai. In the
>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>> has a dependency on xenomai.
>
> That is correct.
>
>> This looks like I can install
>> orocos-xenomai without xenomai installed (when not installing the
>> dev-packages). Is this correct?
>
> No :-] The dependency on libxenomai.so must be picked up by the
> ${shlibs:Depends}
> tag. Check the final dependencies with apt-cache show package-name
>
>>
>> When building OCL packages for xenomai, a build dependency is missing.
>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>> cmake complains that RTT for xenomai can not be found. Is this a
>> missing build dependency or is this a missing dependency on
>> liborocos-rtt-corba-xenomai1.10-dev?
>
> It looks like a bug in the rtt control-template.in file. The first
> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
> liborocos-rtt-@TARGET@@LIBVER@-dev
> This dependency is missing.
When I generate the control file for xenomai, no libxenomai-dev build
dependency is required. results in:
Orocos target is xenomai
-- Optional library XENOMAI NOT FOUND. If the library is already
installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
set the missing variables manually.
>>
>> We noticed that RTSocketCAN is not build (when xenomai target is
>> selected), only SocketCAN. Modifying the file CMakeCanComedi.txt +
>> some .install files solved that problem.
>
> Ok.
>
>> When I tried to install the
>> generated packages, aptitude returns an error because
>> liborocos-ocl-can1.10-dev is a virtual package. Did I forgot something
>> to modify?
>
> Strange, it is declared in control.common and also has an install
> file. How did you try to install ? Did you use dpkg -i
> liborocos-ocl*deb ?
>
> Peter
>
building RTT and OCL debian packages
On Thu, Nov 19, 2009 at 12:25, Steven Kauffmann
<steven [dot] kauffmann [..] ...> wrote:
> On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
> <peter [..] ...> wrote:
>> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>> <steven [dot] kauffmann [..] ...> wrote:
>>> When installing the generated OCL debian packages, package
>>> orocos-ocl-gnulinux1.10 depends on
>>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>>> generated. I can't even find it in the control file (except the
>>> dependency). Is this because I disabled KDL?
>>
>> Due to API instabilities in KDL, I had to drop the cartesian packages
>> from the control.common file. So this dependency (and the build dep)
>> needs to be removed
>> as well.
>>
>>>
>>> I'm also building debian packages of RTT and OCL for xenomai. In the
>>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>>> has a dependency on xenomai.
>>
>> That is correct.
>>
>>> This looks like I can install
>>> orocos-xenomai without xenomai installed (when not installing the
>>> dev-packages). Is this correct?
>>
>> No :-] The dependency on libxenomai.so must be picked up by the
>> ${shlibs:Depends}
>> tag. Check the final dependencies with apt-cache show package-name
>>
>>>
>>> When building OCL packages for xenomai, a build dependency is missing.
>>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>>> cmake complains that RTT for xenomai can not be found. Is this a
>>> missing build dependency or is this a missing dependency on
>>> liborocos-rtt-corba-xenomai1.10-dev?
>>
>> It looks like a bug in the rtt control-template.in file. The first
>> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
>> liborocos-rtt-@TARGET@@LIBVER@-dev
>> This dependency is missing.
>
> When I generate the control file for xenomai, no libxenomai-dev build
> dependency is required. results in:
>
> Orocos target is xenomai
> -- Optional library XENOMAI NOT FOUND. If the library is already
> installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
> set the missing variables manually.
Oh, so both the build and package deps were wrong then ? Xenomai in
CMake shouldn't be optional either :-)
It's a bug in create-control.sh which first replaces @BUILD_DEPS@ with
$bdeps, and then sets bdeps to something meaningful :/ Same for $tdev.
Same in OCL.
The patches in attachment fix both rtt/ocl control file generation. It
seems it only worked if you specified one target (and even then only
gnulinux :)
If you send me yours, I can commit all in one go.
Peter
building RTT and OCL debian packages
On Thu, Nov 19, 2009 at 1:14 PM, Peter Soetens <peter [..] ...> wrote:
> On Thu, Nov 19, 2009 at 12:25, Steven Kauffmann
> <steven [dot] kauffmann [..] ...> wrote:
>> On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
>> <peter [..] ...> wrote:
>>> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>>> <steven [dot] kauffmann [..] ...> wrote:
>>>> When installing the generated OCL debian packages, package
>>>> orocos-ocl-gnulinux1.10 depends on
>>>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>>>> generated. I can't even find it in the control file (except the
>>>> dependency). Is this because I disabled KDL?
>>>
>>> Due to API instabilities in KDL, I had to drop the cartesian packages
>>> from the control.common file. So this dependency (and the build dep)
>>> needs to be removed
>>> as well.
>>>
>>>>
>>>> I'm also building debian packages of RTT and OCL for xenomai. In the
>>>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>>>> has a dependency on xenomai.
>>>
>>> That is correct.
>>>
>>>> This looks like I can install
>>>> orocos-xenomai without xenomai installed (when not installing the
>>>> dev-packages). Is this correct?
>>>
>>> No :-] The dependency on libxenomai.so must be picked up by the
>>> ${shlibs:Depends}
>>> tag. Check the final dependencies with apt-cache show package-name
>>>
>>>>
>>>> When building OCL packages for xenomai, a build dependency is missing.
>>>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>>>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>>>> cmake complains that RTT for xenomai can not be found. Is this a
>>>> missing build dependency or is this a missing dependency on
>>>> liborocos-rtt-corba-xenomai1.10-dev?
>>>
>>> It looks like a bug in the rtt control-template.in file. The first
>>> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
>>> liborocos-rtt-@TARGET@@LIBVER@-dev
>>> This dependency is missing.
>>
>> When I generate the control file for xenomai, no libxenomai-dev build
>> dependency is required. results in:
>>
>> Orocos target is xenomai
>> -- Optional library XENOMAI NOT FOUND. If the library is already
>> installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
>> set the missing variables manually.
>
> Oh, so both the build and package deps were wrong then ? Xenomai in
> CMake shouldn't be optional either :-)
>
> It's a bug in create-control.sh which first replaces @BUILD_DEPS@ with
> $bdeps, and then sets bdeps to something meaningful :/ Same for $tdev.
> Same in OCL.
>
> The patches in attachment fix both rtt/ocl control file generation. It
> seems it only worked if you specified one target (and even then only
> gnulinux :)
>
> If you send me yours, I can commit all in one go.
In RTT I modified control-template.in in order to fix the missing
dependency of liborocos-rtt-@TARGET@@LIBVER@-dev.
Libxenomai is indeed picked up.
changes in ocl/debian:
Added missing ocl-config.h + netcdf reporter header files in
liborocos-ocl-sover-dev.install
Added liborocos-reporting-netcdf.so in liborocos-ocl-template.install
and liborocos-ocl-template-dev.install
Added minimum required libcomedi version as build-dependency in control.common
Added libnetcdf-dev + linux-libc-dev + libboost-program-options-dev as
build-dependency in control.common
Added libnetcdf-dev + linux-libc-dev as dependency in control-template.in
Added RTSocketCAN in CMakeCanComedi.txt
Added rule in liborocos-ocl-can-template.install and
liborocos-ocl-can-template-dev.install to install rtsocket-can lib if
it exists
Removed liborocos-ocl-cartesian-@TARGET@@LIBVER@ as dependency in
control-template.in
Removed liborocos-kdl1.0-dev in control.common
I don't know if it's required that libnetcdf-dev is added as a
dependency in control-template.in. If I look in rtt there are also a
lot of build-dependencies that are not added in control-template.in.
Steven
building RTT and OCL debian packages
On Fri, Nov 20, 2009 at 09:13, Steven Kauffmann
<steven [dot] kauffmann [..] ...> wrote:
> On Thu, Nov 19, 2009 at 1:14 PM, Peter Soetens <peter [..] ...> wrote:
>> On Thu, Nov 19, 2009 at 12:25, Steven Kauffmann
>> <steven [dot] kauffmann [..] ...> wrote:
>>> On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
>>> <peter [..] ...> wrote:
>>>> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>>>> <steven [dot] kauffmann [..] ...> wrote:
>>>>> When installing the generated OCL debian packages, package
>>>>> orocos-ocl-gnulinux1.10 depends on
>>>>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>>>>> generated. I can't even find it in the control file (except the
>>>>> dependency). Is this because I disabled KDL?
>>>>
>>>> Due to API instabilities in KDL, I had to drop the cartesian packages
>>>> from the control.common file. So this dependency (and the build dep)
>>>> needs to be removed
>>>> as well.
>>>>
>>>>>
>>>>> I'm also building debian packages of RTT and OCL for xenomai. In the
>>>>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>>>>> has a dependency on xenomai.
>>>>
>>>> That is correct.
>>>>
>>>>> This looks like I can install
>>>>> orocos-xenomai without xenomai installed (when not installing the
>>>>> dev-packages). Is this correct?
>>>>
>>>> No :-] The dependency on libxenomai.so must be picked up by the
>>>> ${shlibs:Depends}
>>>> tag. Check the final dependencies with apt-cache show package-name
>>>>
>>>>>
>>>>> When building OCL packages for xenomai, a build dependency is missing.
>>>>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>>>>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>>>>> cmake complains that RTT for xenomai can not be found. Is this a
>>>>> missing build dependency or is this a missing dependency on
>>>>> liborocos-rtt-corba-xenomai1.10-dev?
>>>>
>>>> It looks like a bug in the rtt control-template.in file. The first
>>>> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
>>>> liborocos-rtt-@TARGET@@LIBVER@-dev
>>>> This dependency is missing.
>>>
>>> When I generate the control file for xenomai, no libxenomai-dev build
>>> dependency is required. results in:
>>>
>>> Orocos target is xenomai
>>> -- Optional library XENOMAI NOT FOUND. If the library is already
>>> installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
>>> set the missing variables manually.
>>
>> Oh, so both the build and package deps were wrong then ? Xenomai in
>> CMake shouldn't be optional either :-)
>>
>> It's a bug in create-control.sh which first replaces @BUILD_DEPS@ with
>> $bdeps, and then sets bdeps to something meaningful :/ Same for $tdev.
>> Same in OCL.
>>
>> The patches in attachment fix both rtt/ocl control file generation. It
>> seems it only worked if you specified one target (and even then only
>> gnulinux :)
>>
>> If you send me yours, I can commit all in one go.
>
> In RTT I modified control-template.in in order to fix the missing
> dependency of liborocos-rtt-@TARGET@@LIBVER@-dev.
>
> Libxenomai is indeed picked up.
>
> changes in ocl/debian:
>
> Added missing ocl-config.h + netcdf reporter header files in
> liborocos-ocl-sover-dev.install
> Added liborocos-reporting-netcdf.so in liborocos-ocl-template.install
> and liborocos-ocl-template-dev.install
> Added minimum required libcomedi version as build-dependency in control.common
> Added libnetcdf-dev + linux-libc-dev + libboost-program-options-dev as
> build-dependency in control.common
> Added libnetcdf-dev + linux-libc-dev as dependency in control-template.in
> Added RTSocketCAN in CMakeCanComedi.txt
> Added rule in liborocos-ocl-can-template.install and
> liborocos-ocl-can-template-dev.install to install rtsocket-can lib if
> it exists
> Removed liborocos-ocl-cartesian-@TARGET@@LIBVER@ as dependency in
> control-template.in
> Removed liborocos-kdl1.0-dev in control.common
Thanks. I applied your patch with one minor change: require cmake >=2.6.2.
>
> I don't know if it's required that libnetcdf-dev is added as a
> dependency in control-template.in. If I look in rtt there are also a
> lot of build-dependencies that are not added in control-template.in.
They should be added. Which ones were missing in rtt ?
Peter
building RTT and OCL debian packages
On Fri, Nov 20, 2009 at 9:52 AM, Peter Soetens <peter [..] ...> wrote:
> On Fri, Nov 20, 2009 at 09:13, Steven Kauffmann
> <steven [dot] kauffmann [..] ...> wrote:
>> On Thu, Nov 19, 2009 at 1:14 PM, Peter Soetens <peter [..] ...> wrote:
>>> On Thu, Nov 19, 2009 at 12:25, Steven Kauffmann
>>> <steven [dot] kauffmann [..] ...> wrote:
>>>> On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
>>>> <peter [..] ...> wrote:
>>>>> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>>>>> <steven [dot] kauffmann [..] ...> wrote:
>>>>>> When installing the generated OCL debian packages, package
>>>>>> orocos-ocl-gnulinux1.10 depends on
>>>>>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>>>>>> generated. I can't even find it in the control file (except the
>>>>>> dependency). Is this because I disabled KDL?
>>>>>
>>>>> Due to API instabilities in KDL, I had to drop the cartesian packages
>>>>> from the control.common file. So this dependency (and the build dep)
>>>>> needs to be removed
>>>>> as well.
>>>>>
>>>>>>
>>>>>> I'm also building debian packages of RTT and OCL for xenomai. In the
>>>>>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>>>>>> has a dependency on xenomai.
>>>>>
>>>>> That is correct.
>>>>>
>>>>>> This looks like I can install
>>>>>> orocos-xenomai without xenomai installed (when not installing the
>>>>>> dev-packages). Is this correct?
>>>>>
>>>>> No :-] The dependency on libxenomai.so must be picked up by the
>>>>> ${shlibs:Depends}
>>>>> tag. Check the final dependencies with apt-cache show package-name
>>>>>
>>>>>>
>>>>>> When building OCL packages for xenomai, a build dependency is missing.
>>>>>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>>>>>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>>>>>> cmake complains that RTT for xenomai can not be found. Is this a
>>>>>> missing build dependency or is this a missing dependency on
>>>>>> liborocos-rtt-corba-xenomai1.10-dev?
>>>>>
>>>>> It looks like a bug in the rtt control-template.in file. The first
>>>>> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
>>>>> liborocos-rtt-@TARGET@@LIBVER@-dev
>>>>> This dependency is missing.
>>>>
>>>> When I generate the control file for xenomai, no libxenomai-dev build
>>>> dependency is required. results in:
>>>>
>>>> Orocos target is xenomai
>>>> -- Optional library XENOMAI NOT FOUND. If the library is already
>>>> installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
>>>> set the missing variables manually.
>>>
>>> Oh, so both the build and package deps were wrong then ? Xenomai in
>>> CMake shouldn't be optional either :-)
>>>
>>> It's a bug in create-control.sh which first replaces @BUILD_DEPS@ with
>>> $bdeps, and then sets bdeps to something meaningful :/ Same for $tdev.
>>> Same in OCL.
>>>
>>> The patches in attachment fix both rtt/ocl control file generation. It
>>> seems it only worked if you specified one target (and even then only
>>> gnulinux :)
>>>
>>> If you send me yours, I can commit all in one go.
>>
>> In RTT I modified control-template.in in order to fix the missing
>> dependency of liborocos-rtt-@TARGET@@LIBVER@-dev.
>>
>> Libxenomai is indeed picked up.
>>
>> changes in ocl/debian:
>>
>> Added missing ocl-config.h + netcdf reporter header files in
>> liborocos-ocl-sover-dev.install
>> Added liborocos-reporting-netcdf.so in liborocos-ocl-template.install
>> and liborocos-ocl-template-dev.install
>> Added minimum required libcomedi version as build-dependency in control.common
>> Added libnetcdf-dev + linux-libc-dev + libboost-program-options-dev as
>> build-dependency in control.common
>> Added libnetcdf-dev + linux-libc-dev as dependency in control-template.in
>> Added RTSocketCAN in CMakeCanComedi.txt
>> Added rule in liborocos-ocl-can-template.install and
>> liborocos-ocl-can-template-dev.install to install rtsocket-can lib if
>> it exists
>> Removed liborocos-ocl-cartesian-@TARGET@@LIBVER@ as dependency in
>> control-template.in
>> Removed liborocos-kdl1.0-dev in control.common
>
> Thanks. I applied your patch with one minor change: require cmake >=2.6.2.
Oh no! why? :-) We are building debian packages for etch and using
cmake from backports version 2.6.0.
>
>>
>> I don't know if it's required that libnetcdf-dev is added as a
>> dependency in control-template.in. If I look in rtt there are also a
>> lot of build-dependencies that are not added in control-template.in.
>
> They should be added. Which ones were missing in rtt ?
libboost-program-options-dev | libboost-program-options1.35-dev |
libboost-program-options1.36-dev | libboost-program-options1.37-dev
libboost-thread-dev | libboost-thread1.35-dev |
libboost-thread1.36-dev | libboost-thread1.37-dev
libboost-test-dev | libboost-test1.35-dev | libboost-test1.36-dev |
libboost-test1.37-dev
tao-idl
gperf-ace
In OCL:
libboost-program-options-dev | libboost-program-options1.35-dev |
libboost-program-options1.36-dev | libboost-program-options1.37-dev
(but that one is already installed in rtt-dev)
libcomedi-dev in /control-template.in should also contain the minimum
version number. (i.e >=0.8)
pkg-config
Steven
building RTT and OCL debian packages
On Fri, Nov 20, 2009 at 10:47, Steven Kauffmann
<steven [dot] kauffmann [..] ...> wrote:
> On Fri, Nov 20, 2009 at 9:52 AM, Peter Soetens <peter [..] ...> wrote:
>> On Fri, Nov 20, 2009 at 09:13, Steven Kauffmann
>> <steven [dot] kauffmann [..] ...> wrote:
>>> On Thu, Nov 19, 2009 at 1:14 PM, Peter Soetens <peter [..] ...> wrote:
>>>> On Thu, Nov 19, 2009 at 12:25, Steven Kauffmann
>>>> <steven [dot] kauffmann [..] ...> wrote:
>>>>> On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
>>>>> <peter [..] ...> wrote:
>>>>>> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>>>>>> <steven [dot] kauffmann [..] ...> wrote:
>>>>>>> When installing the generated OCL debian packages, package
>>>>>>> orocos-ocl-gnulinux1.10 depends on
>>>>>>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>>>>>>> generated. I can't even find it in the control file (except the
>>>>>>> dependency). Is this because I disabled KDL?
>>>>>>
>>>>>> Due to API instabilities in KDL, I had to drop the cartesian packages
>>>>>> from the control.common file. So this dependency (and the build dep)
>>>>>> needs to be removed
>>>>>> as well.
>>>>>>
>>>>>>>
>>>>>>> I'm also building debian packages of RTT and OCL for xenomai. In the
>>>>>>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>>>>>>> has a dependency on xenomai.
>>>>>>
>>>>>> That is correct.
>>>>>>
>>>>>>> This looks like I can install
>>>>>>> orocos-xenomai without xenomai installed (when not installing the
>>>>>>> dev-packages). Is this correct?
>>>>>>
>>>>>> No :-] The dependency on libxenomai.so must be picked up by the
>>>>>> ${shlibs:Depends}
>>>>>> tag. Check the final dependencies with apt-cache show package-name
>>>>>>
>>>>>>>
>>>>>>> When building OCL packages for xenomai, a build dependency is missing.
>>>>>>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>>>>>>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>>>>>>> cmake complains that RTT for xenomai can not be found. Is this a
>>>>>>> missing build dependency or is this a missing dependency on
>>>>>>> liborocos-rtt-corba-xenomai1.10-dev?
>>>>>>
>>>>>> It looks like a bug in the rtt control-template.in file. The first
>>>>>> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
>>>>>> liborocos-rtt-@TARGET@@LIBVER@-dev
>>>>>> This dependency is missing.
>>>>>
>>>>> When I generate the control file for xenomai, no libxenomai-dev build
>>>>> dependency is required. results in:
>>>>>
>>>>> Orocos target is xenomai
>>>>> -- Optional library XENOMAI NOT FOUND. If the library is already
>>>>> installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
>>>>> set the missing variables manually.
>>>>
>>>> Oh, so both the build and package deps were wrong then ? Xenomai in
>>>> CMake shouldn't be optional either :-)
>>>>
>>>> It's a bug in create-control.sh which first replaces @BUILD_DEPS@ with
>>>> $bdeps, and then sets bdeps to something meaningful :/ Same for $tdev.
>>>> Same in OCL.
>>>>
>>>> The patches in attachment fix both rtt/ocl control file generation. It
>>>> seems it only worked if you specified one target (and even then only
>>>> gnulinux :)
>>>>
>>>> If you send me yours, I can commit all in one go.
>>>
>>> In RTT I modified control-template.in in order to fix the missing
>>> dependency of liborocos-rtt-@TARGET@@LIBVER@-dev.
>>>
>>> Libxenomai is indeed picked up.
>>>
>>> changes in ocl/debian:
>>>
>>> Added missing ocl-config.h + netcdf reporter header files in
>>> liborocos-ocl-sover-dev.install
>>> Added liborocos-reporting-netcdf.so in liborocos-ocl-template.install
>>> and liborocos-ocl-template-dev.install
>>> Added minimum required libcomedi version as build-dependency in control.common
>>> Added libnetcdf-dev + linux-libc-dev + libboost-program-options-dev as
>>> build-dependency in control.common
>>> Added libnetcdf-dev + linux-libc-dev as dependency in control-template.in
>>> Added RTSocketCAN in CMakeCanComedi.txt
>>> Added rule in liborocos-ocl-can-template.install and
>>> liborocos-ocl-can-template-dev.install to install rtsocket-can lib if
>>> it exists
>>> Removed liborocos-ocl-cartesian-@TARGET@@LIBVER@ as dependency in
>>> control-template.in
>>> Removed liborocos-kdl1.0-dev in control.common
>>
>> Thanks. I applied your patch with one minor change: require cmake >=2.6.2.
>
> Oh no! why? :-) We are building debian packages for etch and using
> cmake from backports version 2.6.0.
Ok, I'll revert that...
>
>>
>>>
>>> I don't know if it's required that libnetcdf-dev is added as a
>>> dependency in control-template.in. If I look in rtt there are also a
>>> lot of build-dependencies that are not added in control-template.in.
>>
>> They should be added. Which ones were missing in rtt ?
>
> libboost-program-options-dev | libboost-program-options1.35-dev |
> libboost-program-options1.36-dev | libboost-program-options1.37-dev
> libboost-thread-dev | libboost-thread1.35-dev |
> libboost-thread1.36-dev | libboost-thread1.37-dev
> libboost-test-dev | libboost-test1.35-dev | libboost-test1.36-dev |
> libboost-test1.37-dev
> tao-idl
> gperf-ace
Hmm. It depends. If on of our headers includes a header from boost
program options, or thread or...
then we need to specify it too as a dependency in our -dev packages.
So a build depend is not always
a package depend. In the above case, only boost-thread is a candidate,
and even then, it is only
enabled in Mac OS-x so not relevant for our debian build.
So none of the above must be added to the -dev packages.
>
> In OCL:
>
> libboost-program-options-dev | libboost-program-options1.35-dev |
> libboost-program-options1.36-dev | libboost-program-options1.37-dev
> (but that one is already installed in rtt-dev)
> libcomedi-dev in /control-template.in should also contain the minimum
> version number. (i.e >=0.8)
> pkg-config
Same here. libcomedi-dev is the only candidate we want to add with >=0.8
Peter
building RTT and OCL debian packages
A Dijous 19 Novembre 2009, Peter Soetens va escriure:
> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>
> <steven [dot] kauffmann [..] ...> wrote:
> > When installing the generated OCL debian packages, package
> > orocos-ocl-gnulinux1.10 depends on
> > liborocos-ocl-cartesian-gnulinux1.10 however this package is not
> > generated. I can't even find it in the control file (except the
> > dependency). Is this because I disabled KDL?
>
> Due to API instabilities in KDL, I had to drop the cartesian packages
> from the control.common file. So this dependency (and the build dep)
> needs to be removed
> as well.
>
> > I'm also building debian packages of RTT and OCL for xenomai. In the
> > generated control file only the package liborocos-rtt-xenomai1.10-dev
> > has a dependency on xenomai.
>
> That is correct.
>
> > This looks like I can install
> > orocos-xenomai without xenomai installed (when not installing the
> > dev-packages). Is this correct?
>
> No :-] The dependency on libxenomai.so must be picked up by the
> ${shlibs:Depends}
> tag. Check the final dependencies with apt-cache show package-name
>
> > When building OCL packages for xenomai, a build dependency is missing.
> > Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
> > ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
> > cmake complains that RTT for xenomai can not be found. Is this a
> > missing build dependency or is this a missing dependency on
> > liborocos-rtt-corba-xenomai1.10-dev?
>
> It looks like a bug in the rtt control-template.in file. The first
> package, liborocos-rtt-corba-@TARGET@@LIBVER@-dev must also depend on
> liborocos-rtt-@TARGET@@LIBVER@-dev
> This dependency is missing.
>
> > We noticed that RTSocketCAN is not build (when xenomai target is
> > selected), only SocketCAN. Modifying the file CMakeCanComedi.txt +
> > some .install files solved that problem.
>
> Ok.
>
> > When I tried to install the
> > generated packages, aptitude returns an error because
> > liborocos-ocl-can1.10-dev is a virtual package. Did I forgot something
> > to modify?
>
> Strange, it is declared in control.common and also has an install
> file. How did you try to install ? Did you use dpkg -i
> liborocos-ocl*deb ?
>
> Peter
Peter,
my opinion is that debian OCL packages actually are in a "pseudo broken"
state. If I'm not wrong, OCL is changing in some way (independent packages?
or something different.
Generate the debian packages now it's a complex combination betwend cmake and
debian/control file modifications and I'm not quiet sure if it's worthwhile
to spend time to make debian packages of OCL d 1.x in a good shape when 2.x
is near and the reorganization too.
If you think that yes, it's important to have debian packages of OCL ok, and
the reorganization will be more later, I look it and I hope to send you some
patches, but if not, I think that install the rtt packages and compile the
ocl component that you need is not a bad option. :-)
Regards,
Leo
building RTT and OCL debian packages
Hi Leo,
On Thu, Nov 19, 2009 at 11:56, Leopold Palomo-Avellaneda
<leopold [dot] palomo [..] ...> wrote:
>
> Peter,
>
> my opinion is that debian OCL packages actually are in a "pseudo broken"
> state. If I'm not wrong, OCL is changing in some way (independent packages?
> or something different.
>
> Generate the debian packages now it's a complex combination betwend cmake and
> debian/control file modifications and I'm not quiet sure if it's worthwhile
> to spend time to make debian packages of OCL d 1.x in a good shape when 2.x
> is near and the reorganization too.
>
> If you think that yes, it's important to have debian packages of OCL ok, and
> the reorganization will be more later, I look it and I hope to send you some
> patches, but if not, I think that install the rtt packages and compile the
> ocl component that you need is not a bad option. :-)
The point is that all our users are 1.x users, so it would not be
smart to ignore them :-) Anything that needs fixing in 1.x must be
fixed, as far as the fix allows backwards compatibility. All the rest
is for 2.x.
Peter