The env.sh script sets these env variables:
export RUBYOPT=-rubygems
export GEM_HOME=/home/kaltan/src/git/orocos-dfki-toolchain/.gems
export PATH=$GEM_HOME/bin:$PATH
Shouldn't we store the .gems in a more common ($HOME/.orocos-gems/) directory
? Or is it best practice to keep it only local ?
On Ubuntu 9.10 it sometimes asks the same questions, It at least asked 3 times
to install git for example (defaulted to 'ask'), during different phases.
Then I got this:
autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
Build failed: autoproj: failed in osdeps phase
'/bin/bash /home/kaltan/src/git/orocos-toolchain-dfki/osdeps.sh' returned
status 100
see /home/kaltan/src/git/orocos-toolchain-dfki/install/log/autoproj-
osdeps.log for details
last 10 lines are:
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libboost-filesystem1.38-dev: Depends: libboost-system1.38-dev (=
1.38.0-6ubuntu6.1) but it is not going to be installed
libboost-graph1.38-dev: Depends: libboost-serialization1.38-dev (=
1.38.0-6ubuntu6.1) but it is not going to be installed
Depends: libboost-test1.38-dev (=
1.38.0-6ubuntu6.1) but it is not going to be installed
libboost-thread1.38-dev: Depends: libboost-date-time1.38-dev (=
1.38.0-6ubuntu6.1) but it is not going to be installed
E: Broken packages
This breaks because I have the 1.40 version installed, which is also part of
9.10.
Finally, I get this:
autoproj: building and installing packages
generating and configuring build system for utilmm
building utilmm (100%)
installing utilmm
generating and configuring build system for rtt
building rtt (100%)
installing rtt
generating and configuring build system for ocl
building ocl (100%)
installing ocl
setting up Ruby package utilrb
generating and configuring build system for typelib
autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
Build failed: typelib: failed in configure phase
'cmake -DCMAKE_INSTALL_PREFIX=/home/kaltan/src/git/orocos-toolchain-
dfki/install/tools -DRUBY_EXECUTABLE=/usr/bin/ruby1.8
/home/kaltan/src/git/orocos-toolchain-dfki/tools/typelib' returned status 1
see /home/kaltan/src/git/orocos-toolchain-dfki/install/tools/log/typelib-
configure.log for details
last 10 lines are:
-- Boost Version: 1.40.0
-- boost/test found ... building test suite
-- cannot find the antlr executable
CMake Error at cmake/FindAntlr.cmake:99 (MESSAGE):
Please install the Antlr executable and/or the CPP language packages
Call Stack (most recent call first):
test/CMakeLists.txt:1 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
and the script ends.
This reminds me a lot of the trouble the ROS people had with their rosdep
tool.
Peter
boostrap.sh - env.sh - orocos-dfki-toolchain
On 08/27/2010 03:35 PM, Peter Soetens wrote:
> The env.sh script sets these env variables:
>
> export RUBYOPT=-rubygems
> export GEM_HOME=/home/kaltan/src/git/orocos-dfki-toolchain/.gems
> export PATH=$GEM_HOME/bin:$PATH
>
> Shouldn't we store the .gems in a more common ($HOME/.orocos-gems/) directory
> ? Or is it best practice to keep it only local ?
I want to keep it local, as the goal is to keep the installations
self-contained (i.e. upgrading gems on one autoproj installation should
not affect another one)
> On Ubuntu 9.10 it sometimes asks the same questions, It at least asked 3 times
> to install git for example (defaulted to 'ask'), during different phases.
Yes, it does because autoproj does not try to detect if a package is
already been installed. I could make that better by avoiding the same
question in the same session though (if that is the problem).
> Then I got this:
>
> autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
> Build failed: autoproj: failed in osdeps phase
> '/bin/bash /home/kaltan/src/git/orocos-toolchain-dfki/osdeps.sh' returned
> status 100
> see /home/kaltan/src/git/orocos-toolchain-dfki/install/log/autoproj-
> osdeps.log for details
> last 10 lines are:
>
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> libboost-filesystem1.38-dev: Depends: libboost-system1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> libboost-graph1.38-dev: Depends: libboost-serialization1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> Depends: libboost-test1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> libboost-thread1.38-dev: Depends: libboost-date-time1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> E: Broken packages
>
> This breaks because I have the 1.40 version installed, which is also part of
> 9.10.
I probably shipped the wrong osdeps file. It should refer to the
unversionned boost versions. You can update the osdeps file and push.
> Finally, I get this:
>
> autoproj: building and installing packages
> generating and configuring build system for utilmm
> building utilmm (100%)
> installing utilmm
> generating and configuring build system for rtt
> building rtt (100%)
> installing rtt
> generating and configuring build system for ocl
> building ocl (100%)
> installing ocl
> setting up Ruby package utilrb
> generating and configuring build system for typelib
> autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
> Build failed: typelib: failed in configure phase
> 'cmake -DCMAKE_INSTALL_PREFIX=/home/kaltan/src/git/orocos-toolchain-
> dfki/install/tools -DRUBY_EXECUTABLE=/usr/bin/ruby1.8
> /home/kaltan/src/git/orocos-toolchain-dfki/tools/typelib' returned status 1
> see /home/kaltan/src/git/orocos-toolchain-dfki/install/tools/log/typelib-
> configure.log for details
> last 10 lines are:
>
> -- Boost Version: 1.40.0
> -- boost/test found ... building test suite
> -- cannot find the antlr executable
> CMake Error at cmake/FindAntlr.cmake:99 (MESSAGE):
> Please install the Antlr executable and/or the CPP language packages
> Call Stack (most recent call first):
> test/CMakeLists.txt:1 (FIND_PACKAGE)
>
>
> -- Configuring incomplete, errors occurred!
>
> and the script ends.
>
> This reminds me a lot of the trouble the ROS people had with their rosdep
> tool.
Did you say "ask" during the update, or yes. If you say "ask", you are
back to the same kind of problems that with total manual install (in
this case "antlr" means antlr + libantlr-dev). In this case, don't
expect the whole thing to work out of the box.
boostrap.sh - env.sh - orocos-dfki-toolchain
On Monday 30 August 2010 07:22:57 Sylvain Joyeux wrote:
> On 08/27/2010 03:35 PM, Peter Soetens wrote:
> > The env.sh script sets these env variables:
> >
> > export RUBYOPT=-rubygems
> > export GEM_HOME=/home/kaltan/src/git/orocos-dfki-toolchain/.gems
> > export PATH=$GEM_HOME/bin:$PATH
> >
> > Shouldn't we store the .gems in a more common ($HOME/.orocos-gems/)
> > directory ? Or is it best practice to keep it only local ?
>
> I want to keep it local, as the goal is to keep the installations
> self-contained (i.e. upgrading gems on one autoproj installation should
> not affect another one)
OK.
>
> > On Ubuntu 9.10 it sometimes asks the same questions, It at least asked 3
> > times to install git for example (defaulted to 'ask'), during different
> > phases.
>
> Yes, it does because autoproj does not try to detect if a package is
> already been installed. I could make that better by avoiding the same
> question in the same session though (if that is the problem).
It was. I'd prefer that the default proposed answer would be [no] since it
appears it will only work on a very limited set of installs. I'd rather then
have the bootstrapping fail and instruct the user to run 'autoproj build'
after installing the missing dependencies.
>
> > Then I got this:
> >
> > autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
> > Build failed: autoproj: failed in osdeps phase
> > '/bin/bash /home/kaltan/src/git/orocos-toolchain-dfki/osdeps.sh'
> > returned status 100
> > see /home/kaltan/src/git/orocos-toolchain-dfki/install/log/autoproj-
> > osdeps.log for details
> > last 10 lines are:
> >
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> >
> > The following packages have unmet dependencies:
> > libboost-filesystem1.38-dev: Depends: libboost-system1.38-dev (=
> > 1.38.0-6ubuntu6.1) but it is not going to be installed
> > libboost-graph1.38-dev: Depends: libboost-serialization1.38-dev (=
> > 1.38.0-6ubuntu6.1) but it is not going to be installed
> > Depends: libboost-test1.38-dev (=
> > 1.38.0-6ubuntu6.1) but it is not going to be installed
> > libboost-thread1.38-dev: Depends: libboost-date-time1.38-dev (=
> > 1.38.0-6ubuntu6.1) but it is not going to be installed
> > E: Broken packages
> >
> > This breaks because I have the 1.40 version installed, which is also part
> > of 9.10.
>
> I probably shipped the wrong osdeps file. It should refer to the
> unversionned boost versions. You can update the osdeps file and push.
That wouldn't work either. Installing libboost-dev will also fail if
libboost1.40-dev is installed. Since you have the choice to install boost1.35-
>1.40, you can't fix this problem, it will always complain, unless 1.38 is
installed.
That's why I would default to [no].
...
> > -- Configuring incomplete, errors occurred!
> >
> > and the script ends.
> >
> > This reminds me a lot of the trouble the ROS people had with their rosdep
> > tool.
>
> Did you say "ask" during the update, or yes. If you say "ask", you are
> back to the same kind of problems that with total manual install (in
> this case "antlr" means antlr + libantlr-dev). In this case, don't
> expect the whole thing to work out of the box.
>
Do you still depend on antlr after the gcc-xml port ? Could it become a build
'option' ?
Peter
boostrap.sh - env.sh - orocos-dfki-toolchain
>>> On Ubuntu 9.10 it sometimes asks the same questions, It at least asked 3
>>> times to install git for example (defaulted to 'ask'), during different
>>> phases.
>>
>> Yes, it does because autoproj does not try to detect if a package is
>> already been installed. I could make that better by avoiding the same
>> question in the same session though (if that is the problem).
>
> It was. I'd prefer that the default proposed answer would be [no] since it
> appears it will only work on a very limited set of installs. I'd rather then
> have the bootstrapping fail and instruct the user to run 'autoproj build'
> after installing the missing dependencies.
Not true. It actually works on Ubuntu 9.04, 9.10 an Debian. The fedora
issue was that autoproj did not detect properly that Fedora was not
supported, and should default to 'wait' now.
>> I probably shipped the wrong osdeps file. It should refer to the
>> unversionned boost versions. You can update the osdeps file and push.
>
> That wouldn't work either. Installing libboost-dev will also fail if
> libboost1.40-dev is installed. Since you have the choice to install boost1.35-
>> 1.40, you can't fix this problem, it will always complain, unless 1.38 is
> installed.
>
> That's why I would default to [no].
If you default to no, you basically stop providing an easy install
option. Yes provides that on supported architectures, and autoproj
defaults to 'wait' on the other architectures.
Moreover, instead of complaining -- to length -- that the boost version
is wrong on Ubuntu, you could quickly fix it by modifying the osdeps
file, which would fix install on all Ubuntu 9.10.
> Do you still depend on antlr after the gcc-xml port ? Could it become a build
> 'option' ?
Yes, it should but I had no time to do it. In parcitular, it requires
the CImporter to be split between support for std::vector and
std::string and the parser itself.
I'm warning you guys again. I'll be able to do very limited work (mainly
reply to emails) until tomorrow evening (Japan time, UTC+7) and you will
then not hear from me until the 3rd of October.
boostrap.sh - env.sh - orocos-dfki-toolchain
On Tuesday 31 August 2010 02:21:37 Sylvain Joyeux wrote:
> >>> On Ubuntu 9.10 it sometimes asks the same questions, It at least asked
> >>> 3 times to install git for example (defaulted to 'ask'), during
> >>> different phases.
> >>
> >> Yes, it does because autoproj does not try to detect if a package is
> >> already been installed. I could make that better by avoiding the same
> >> question in the same session though (if that is the problem).
> >
> > It was. I'd prefer that the default proposed answer would be [no] since
> > it appears it will only work on a very limited set of installs. I'd
> > rather then have the bootstrapping fail and instruct the user to run
> > 'autoproj build' after installing the missing dependencies.
>
> Not true. It actually works on Ubuntu 9.04, 9.10 an Debian.
Not true either.
> The fedora
> issue was that autoproj did not detect properly that Fedora was not
> supported, and should default to 'wait' now.
>
> >> I probably shipped the wrong osdeps file. It should refer to the
> >> unversionned boost versions. You can update the osdeps file and push.
> >
> > That wouldn't work either. Installing libboost-dev will also fail if
> > libboost1.40-dev is installed. Since you have the choice to install
> > boost1.35-
> >
> >> 1.40, you can't fix this problem, it will always complain, unless 1.38
> >> is
> >
> > installed.
> >
> > That's why I would default to [no].
>
> If you default to no, you basically stop providing an easy install
> option. Yes provides that on supported architectures, and autoproj
> defaults to 'wait' on the other architectures.
>
> Moreover, instead of complaining -- to length -- that the boost version
> is wrong on Ubuntu, you could quickly fix it by modifying the osdeps
> file, which would fix install on all Ubuntu 9.10.
I tried to explain that this particular case is not fixable:
$ dpkg -l libboost-filesystem-dev
un libboost-filesystem-dev <none>
$ dpkg -l libboost-filesystem1.40-dev
ii libboost-filesystem1.40-dev 1.40.0-2ubuntu2
# Original osdeps:
$ sudo apt-get install libboost-filesystem1.38-dev
The following packages have unmet dependencies:
libboost-filesystem1.38-dev: Depends: libboost1.38-dev (= 1.38.0-6ubuntu6.1)
but it is not going to be installed
Depends: libboost-system1.38-dev (=
1.38.0-6ubuntu6.1) but it is not going to be installed
E: Broken packages
# Proposed solution by Sylvain
$ sudo apt-get install libboost-filesystem-dev
The following packages have unmet dependencies:
libboost-filesystem-dev: Depends: libboost-filesystem1.38-dev but it is not
going to be installed
So your proposed patch is by no means a fix.
>
> > Do you still depend on antlr after the gcc-xml port ? Could it become a
> > build 'option' ?
>
> Yes, it should but I had no time to do it. In parcitular, it requires
> the CImporter to be split between support for std::vector and
> std::string and the parser itself.
Worries for later.
>
> I'm warning you guys again. I'll be able to do very limited work (mainly
> reply to emails) until tomorrow evening (Japan time, UTC+7) and you will
> then not hear from me until the 3rd of October.
Thanks for the reminder.
Peter
boostrap.sh - env.sh - orocos-dfki-toolchain
On 08/31/2010 09:59 AM, Peter Soetens wrote:
> On Tuesday 31 August 2010 02:21:37 Sylvain Joyeux wrote:
>>>>> On Ubuntu 9.10 it sometimes asks the same questions, It at least asked
>>>>> 3 times to install git for example (defaulted to 'ask'), during
>>>>> different phases.
>>>>
>>>> Yes, it does because autoproj does not try to detect if a package is
>>>> already been installed. I could make that better by avoiding the same
>>>> question in the same session though (if that is the problem).
>>>
>>> It was. I'd prefer that the default proposed answer would be [no] since
>>> it appears it will only work on a very limited set of installs. I'd
>>> rather then have the bootstrapping fail and instruct the user to run
>>> 'autoproj build' after installing the missing dependencies.
>>
>> Not true. It actually works on Ubuntu 9.04, 9.10 an Debian.
>
> Not true either.
>
>> The fedora
>> issue was that autoproj did not detect properly that Fedora was not
>> supported, and should default to 'wait' now.
>>
>>>> I probably shipped the wrong osdeps file. It should refer to the
>>>> unversionned boost versions. You can update the osdeps file and push.
>>>
>>> That wouldn't work either. Installing libboost-dev will also fail if
>>> libboost1.40-dev is installed. Since you have the choice to install
>>> boost1.35-
>>>
>>>> 1.40, you can't fix this problem, it will always complain, unless 1.38
>>>> is
>>>
>>> installed.
>>>
>>> That's why I would default to [no].
>>
>> If you default to no, you basically stop providing an easy install
>> option. Yes provides that on supported architectures, and autoproj
>> defaults to 'wait' on the other architectures.
>>
>> Moreover, instead of complaining -- to length -- that the boost version
>> is wrong on Ubuntu, you could quickly fix it by modifying the osdeps
>> file, which would fix install on all Ubuntu 9.10.
>
> I tried to explain that this particular case is not fixable:
>
> $ dpkg -l libboost-filesystem-dev
> un libboost-filesystem-dev<none>
Can you try apt-cache policy libboost-filesystem-dev ?
> $ dpkg -l libboost-filesystem1.40-dev
> ii libboost-filesystem1.40-dev 1.40.0-2ubuntu2
>
> # Original osdeps:
> $ sudo apt-get install libboost-filesystem1.38-dev
> The following packages have unmet dependencies:
> libboost-filesystem1.38-dev: Depends: libboost1.38-dev (= 1.38.0-6ubuntu6.1)
> but it is not going to be installed
> Depends: libboost-system1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> E: Broken packages
>
> # Proposed solution by Sylvain
> $ sudo apt-get install libboost-filesystem-dev
> The following packages have unmet dependencies:
> libboost-filesystem-dev: Depends: libboost-filesystem1.38-dev but it is not
> going to be installed
>
> So your proposed patch is by no means a fix.
*You* are using non-standard version of the boost library. Ubuntu 9.10
standardizes on 1.38, you are using 1.40. If it does not work out of the
box, your problem. Especially since as soon as another library (for
instance, CGAL) requires boost headers to be installed, it won't work
*at all*.
In practice, you can fix *your* problem by overriding the default osdeps
definition in an autoproj/<pick_your_name>.osdeps. For instance:
--- autoproj/ubuntu910_boost140.osdeps
boost:
ubuntu:
- libboost-filesystem1.40-dev
- libboost-system1.40-dev
# and so on, and so forth
---
I personally expect people that pick boost versions to be able to do
something like that.
---
Sylvain Joyeux (Dr. Ing.)
Researcher - Space and Security Robotics
DFKI Robotics Innovation Center
Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
Phone: +49 421 218-64136
Fax: +49 421 218-64150
Email: sylvain [dot] joyeux [..] ...
Weitere Informationen: http://www.dfki.de
boostrap.sh - env.sh - orocos-dfki-toolchain
On Wednesday 01 September 2010 02:28:00 Sylvain Joyeux wrote:
> On 08/31/2010 09:59 AM, Peter Soetens wrote:
> > On Tuesday 31 August 2010 02:21:37 Sylvain Joyeux wrote:
> >>>>> On Ubuntu 9.10 it sometimes asks the same questions, It at least
> >>>>> asked 3 times to install git for example (defaulted to 'ask'), during
> >>>>> different phases.
> >>>>
> >>>> Yes, it does because autoproj does not try to detect if a package is
> >>>> already been installed. I could make that better by avoiding the same
> >>>> question in the same session though (if that is the problem).
> >>>
> >>> It was. I'd prefer that the default proposed answer would be [no] since
> >>> it appears it will only work on a very limited set of installs. I'd
> >>> rather then have the bootstrapping fail and instruct the user to run
> >>> 'autoproj build' after installing the missing dependencies.
> >>
> >> Not true. It actually works on Ubuntu 9.04, 9.10 an Debian.
> >
> > Not true either.
> >
> >> The fedora
> >> issue was that autoproj did not detect properly that Fedora was not
> >> supported, and should default to 'wait' now.
> >>
> >>>> I probably shipped the wrong osdeps file. It should refer to the
> >>>> unversionned boost versions. You can update the osdeps file and push.
> >>>
> >>> That wouldn't work either. Installing libboost-dev will also fail if
> >>> libboost1.40-dev is installed. Since you have the choice to install
> >>> boost1.35-
> >>>
> >>>> 1.40, you can't fix this problem, it will always complain, unless 1.38
> >>>> is
> >>>
> >>> installed.
> >>>
> >>> That's why I would default to [no].
> >>
> >> If you default to no, you basically stop providing an easy install
> >> option. Yes provides that on supported architectures, and autoproj
> >> defaults to 'wait' on the other architectures.
> >>
> >> Moreover, instead of complaining -- to length -- that the boost version
> >> is wrong on Ubuntu, you could quickly fix it by modifying the osdeps
> >> file, which would fix install on all Ubuntu 9.10.
> >
> > I tried to explain that this particular case is not fixable:
> >
> > $ dpkg -l libboost-filesystem-dev
> > un libboost-filesystem-dev<none>
>
> Can you try apt-cache policy libboost-filesystem-dev ?
>
> > $ dpkg -l libboost-filesystem1.40-dev
> > ii libboost-filesystem1.40-dev
> > 1.40.0-2ubuntu2
> >
> > # Original osdeps:
> > $ sudo apt-get install libboost-filesystem1.38-dev
> > The following packages have unmet dependencies:
> > libboost-filesystem1.38-dev: Depends: libboost1.38-dev (=
> > 1.38.0-6ubuntu6.1) but it is not going to be installed
> > Depends: libboost-system1.38-dev (=
> > 1.38.0-6ubuntu6.1) but it is not going to be installed
> > E: Broken packages
> >
> > # Proposed solution by Sylvain
> > $ sudo apt-get install libboost-filesystem-dev
> > The following packages have unmet dependencies:
> > libboost-filesystem-dev: Depends: libboost-filesystem1.38-dev but it
> > is not going to be installed
> >
> > So your proposed patch is by no means a fix.
>
> *You* are using non-standard version of the boost library. Ubuntu 9.10
> standardizes on 1.38, you are using 1.40. If it does not work out of the
> box, your problem. Especially since as soon as another library (for
> instance, CGAL) requires boost headers to be installed, it won't work
> *at all*.
Blaming the user is most of the time a bad idea.
>
> In practice, you can fix *your* problem by overriding the default osdeps
> definition in an autoproj/<pick_your_name>.osdeps. For instance:
>
> --- autoproj/ubuntu910_boost140.osdeps
> boost:
> ubuntu:
> - libboost-filesystem1.40-dev
> - libboost-system1.40-dev
> # and so on, and so forth
> ---
>
> I personally expect people that pick boost versions to be able to do
> something like that.
It's not *my* problem, it's *our* problem, since it *will* happen in the field
and *we* will have to explain it each time until we fix it.
If we present this as *the* bootstrapping tool for new users, it better work.
Peter
boostrap.sh - env.sh - orocos-dfki-toolchain
On 09/01/2010 03:11 PM, Peter Soetens wrote:
> On Wednesday 01 September 2010 02:28:00 Sylvain Joyeux wrote:
>> On 08/31/2010 09:59 AM, Peter Soetens wrote:
>>> On Tuesday 31 August 2010 02:21:37 Sylvain Joyeux wrote:
>>>>>>> On Ubuntu 9.10 it sometimes asks the same questions, It at least
>>>>>>> asked 3 times to install git for example (defaulted to 'ask'), during
>>>>>>> different phases.
>>>>>>
>>>>>> Yes, it does because autoproj does not try to detect if a package is
>>>>>> already been installed. I could make that better by avoiding the same
>>>>>> question in the same session though (if that is the problem).
>>>>>
>>>>> It was. I'd prefer that the default proposed answer would be [no] since
>>>>> it appears it will only work on a very limited set of installs. I'd
>>>>> rather then have the bootstrapping fail and instruct the user to run
>>>>> 'autoproj build' after installing the missing dependencies.
>>>>
>>>> Not true. It actually works on Ubuntu 9.04, 9.10 an Debian.
>>>
>>> Not true either.
>>>
>>>> The fedora
>>>> issue was that autoproj did not detect properly that Fedora was not
>>>> supported, and should default to 'wait' now.
>>>>
>>>>>> I probably shipped the wrong osdeps file. It should refer to the
>>>>>> unversionned boost versions. You can update the osdeps file and push.
>>>>>
>>>>> That wouldn't work either. Installing libboost-dev will also fail if
>>>>> libboost1.40-dev is installed. Since you have the choice to install
>>>>> boost1.35-
>>>>>
>>>>>> 1.40, you can't fix this problem, it will always complain, unless 1.38
>>>>>> is
>>>>>
>>>>> installed.
>>>>>
>>>>> That's why I would default to [no].
>>>>
>>>> If you default to no, you basically stop providing an easy install
>>>> option. Yes provides that on supported architectures, and autoproj
>>>> defaults to 'wait' on the other architectures.
>>>>
>>>> Moreover, instead of complaining -- to length -- that the boost version
>>>> is wrong on Ubuntu, you could quickly fix it by modifying the osdeps
>>>> file, which would fix install on all Ubuntu 9.10.
>>>
>>> I tried to explain that this particular case is not fixable:
>>>
>>> $ dpkg -l libboost-filesystem-dev
>>> un libboost-filesystem-dev<none>
>>
>> Can you try apt-cache policy libboost-filesystem-dev ?
>>
>>> $ dpkg -l libboost-filesystem1.40-dev
>>> ii libboost-filesystem1.40-dev
>>> 1.40.0-2ubuntu2
>>>
>>> # Original osdeps:
>>> $ sudo apt-get install libboost-filesystem1.38-dev
>>> The following packages have unmet dependencies:
>>> libboost-filesystem1.38-dev: Depends: libboost1.38-dev (=
>>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>>> Depends: libboost-system1.38-dev (=
>>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>>> E: Broken packages
>>>
>>> # Proposed solution by Sylvain
>>> $ sudo apt-get install libboost-filesystem-dev
>>> The following packages have unmet dependencies:
>>> libboost-filesystem-dev: Depends: libboost-filesystem1.38-dev but it
>>> is not going to be installed
>>>
>>> So your proposed patch is by no means a fix.
>>
>> *You* are using non-standard version of the boost library. Ubuntu 9.10
>> standardizes on 1.38, you are using 1.40. If it does not work out of the
>> box, your problem. Especially since as soon as another library (for
>> instance, CGAL) requires boost headers to be installed, it won't work
>> *at all*.
>
> Blaming the user is most of the time a bad idea.
I have some users that fucked up their /usr/lib by adding symlinks that
should not be there. I blame it on him. I have a user (you) that
installs manually a particular version of boost, instead of installing
the standard distribution-wide version. I expect you to know what you
are doing *and* expect you to understand that some things won't work.
Because, already, some packages will *not* install on the distribution
(e.g. CGAL). Admittedly, not a lot of them but some of them anyway
Example:
$ apt-cache rdepends libboost-dev | grep -v boost | sort
bcp
geordi
kdepimlibs5-dev
libakonadi-dev
libasio-dev
libbulletml-dev
libcgal-dev
libdeal.ii-dev
libdolfin0-dev
libftdipp-dev
libgecode-dev
libgetfem++-dev
libluabind-dev
libmdds-dev
libopenvrml-dev
libparser++-dev
librheolef-dev
libsource-highlight-dev
libtorrent-rasterbar-dev
libwt-dev
libxmmsclient++-dev
>>
>> In practice, you can fix *your* problem by overriding the default osdeps
>> definition in an autoproj/<pick_your_name>.osdeps. For instance:
>>
>> --- autoproj/ubuntu910_boost140.osdeps
>> boost:
>> ubuntu:
>> - libboost-filesystem1.40-dev
>> - libboost-system1.40-dev
>> # and so on, and so forth
>> ---
>>
>> I personally expect people that pick boost versions to be able to do
>> something like that.
>
> It's not *my* problem, it's *our* problem, since it *will* happen in the field
> and *we* will have to explain it each time until we fix it.
Yes. So add a bit of documentation on the wiki about that particular
issue. At some point, we have to draw the line. Debian/Ubuntu offer
different versions of boost and pick a "default" or "distribution-wide"
one. That's the one people should install as otherwise some other
packages will *not* install properly. If you do otherwise, you have to
be prepared to fix some problems.
> If we present this as *the* bootstrapping tool for new users, it better work.
If your understanding of a tool that works is a tool that has no
assumption whatsoever and magically autodetects every corner case on
every distribution, then be my guest. But don't expect me to spend more
than 5 minutes on it.
Documentation is also often a good solution. Big red box,
"debian/unbuntu and boost" in bold and here you are.
boostrap.sh - env.sh - orocos-dfki-toolchain
On Thu, Sep 2, 2010 at 1:36 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 09/01/2010 03:11 PM, Peter Soetens wrote:
>>
>> On Wednesday 01 September 2010 02:28:00 Sylvain Joyeux wrote:
>>>
>>> On 08/31/2010 09:59 AM, Peter Soetens wrote:
>>>>
>>>> On Tuesday 31 August 2010 02:21:37 Sylvain Joyeux wrote:
>>>>>>>>
>>>>>>>> On Ubuntu 9.10 it sometimes asks the same questions, It at least
>>>>>>>> asked 3 times to install git for example (defaulted to 'ask'),
>>>>>>>> during
>>>>>>>> different phases.
>>>>>>>
>>>>>>> Yes, it does because autoproj does not try to detect if a package is
>>>>>>> already been installed. I could make that better by avoiding the same
>>>>>>> question in the same session though (if that is the problem).
>>>>>>
>>>>>> It was. I'd prefer that the default proposed answer would be [no]
>>>>>> since
>>>>>> it appears it will only work on a very limited set of installs. I'd
>>>>>> rather then have the bootstrapping fail and instruct the user to run
>>>>>> 'autoproj build' after installing the missing dependencies.
>>>>>
>>>>> Not true. It actually works on Ubuntu 9.04, 9.10 an Debian.
>>>>
>>>> Not true either.
>>>>
>>>>> The fedora
>>>>> issue was that autoproj did not detect properly that Fedora was not
>>>>> supported, and should default to 'wait' now.
>>>>>
>>>>>>> I probably shipped the wrong osdeps file. It should refer to the
>>>>>>> unversionned boost versions. You can update the osdeps file and push.
>>>>>>
>>>>>> That wouldn't work either. Installing libboost-dev will also fail if
>>>>>> libboost1.40-dev is installed. Since you have the choice to install
>>>>>> boost1.35-
>>>>>>
>>>>>>> 1.40, you can't fix this problem, it will always complain, unless
>>>>>>> 1.38
>>>>>>> is
>>>>>>
>>>>>> installed.
>>>>>>
>>>>>> That's why I would default to [no].
>>>>>
>>>>> If you default to no, you basically stop providing an easy install
>>>>> option. Yes provides that on supported architectures, and autoproj
>>>>> defaults to 'wait' on the other architectures.
>>>>>
>>>>> Moreover, instead of complaining -- to length -- that the boost version
>>>>> is wrong on Ubuntu, you could quickly fix it by modifying the osdeps
>>>>> file, which would fix install on all Ubuntu 9.10.
>>>>
>>>> I tried to explain that this particular case is not fixable:
>>>>
>>>> $ dpkg -l libboost-filesystem-dev
>>>> un libboost-filesystem-dev<none>
>>>
>>> Can you try apt-cache policy libboost-filesystem-dev ?
>>>
>>>> $ dpkg -l libboost-filesystem1.40-dev
>>>> ii libboost-filesystem1.40-dev
>>>> 1.40.0-2ubuntu2
>>>>
>>>> # Original osdeps:
>>>> $ sudo apt-get install libboost-filesystem1.38-dev
>>>> The following packages have unmet dependencies:
>>>> libboost-filesystem1.38-dev: Depends: libboost1.38-dev (=
>>>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>>>> Depends: libboost-system1.38-dev (=
>>>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>>>> E: Broken packages
>>>>
>>>> # Proposed solution by Sylvain
>>>> $ sudo apt-get install libboost-filesystem-dev
>>>> The following packages have unmet dependencies:
>>>> libboost-filesystem-dev: Depends: libboost-filesystem1.38-dev but it
>>>> is not going to be installed
>>>>
>>>> So your proposed patch is by no means a fix.
>>>
>>> *You* are using non-standard version of the boost library. Ubuntu 9.10
>>> standardizes on 1.38, you are using 1.40. If it does not work out of the
>>> box, your problem. Especially since as soon as another library (for
>>> instance, CGAL) requires boost headers to be installed, it won't work
>>> *at all*.
>>
>> Blaming the user is most of the time a bad idea.
>
> I have some users that fucked up their /usr/lib by adding symlinks that
> should not be there. I blame it on him. I have a user (you) that installs
> manually a particular version of boost, instead of installing the standard
> distribution-wide version. I expect you to know what you are doing *and*
> expect you to understand that some things won't work. Because, already, some
> packages will *not* install on the distribution (e.g. CGAL). Admittedly, not
> a lot of them but some of them anyway
>
> Example:
> $ apt-cache rdepends libboost-dev | grep -v boost | sort
> bcp
> geordi
> kdepimlibs5-dev
> libakonadi-dev
> libasio-dev
> libbulletml-dev
> libcgal-dev
> libdeal.ii-dev
> libdolfin0-dev
> libftdipp-dev
> libgecode-dev
> libgetfem++-dev
> libluabind-dev
> libmdds-dev
> libopenvrml-dev
> libparser++-dev
> librheolef-dev
> libsource-highlight-dev
> libtorrent-rasterbar-dev
> libwt-dev
> libxmmsclient++-dev
>
>>>
>>> In practice, you can fix *your* problem by overriding the default osdeps
>>> definition in an autoproj/<pick_your_name>.osdeps. For instance:
>>>
>>> --- autoproj/ubuntu910_boost140.osdeps
>>> boost:
>>> ubuntu:
>>> - libboost-filesystem1.40-dev
>>> - libboost-system1.40-dev
>>> # and so on, and so forth
>>> ---
>>>
>>> I personally expect people that pick boost versions to be able to do
>>> something like that.
>>
>> It's not *my* problem, it's *our* problem, since it *will* happen in the
>> field
>> and *we* will have to explain it each time until we fix it.
>
> Yes. So add a bit of documentation on the wiki about that particular issue.
> At some point, we have to draw the line. Debian/Ubuntu offer different
> versions of boost and pick a "default" or "distribution-wide" one. That's
> the one people should install as otherwise some other packages will *not*
> install properly. If you do otherwise, you have to be prepared to fix some
> problems.
>
>> If we present this as *the* bootstrapping tool for new users, it better
>> work.
>
> If your understanding of a tool that works is a tool that has no assumption
> whatsoever and magically autodetects every corner case on every
> distribution, then be my guest. But don't expect me to spend more than 5
> minutes on it.
>
> Documentation is also often a good solution. Big red box, "debian/unbuntu
> and boost" in bold and here you are.
Enjoy your vacation !
;-)
Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
boostrap.sh - env.sh - orocos-dfki-toolchain
On Aug 27, 2010, at 09:35 , Peter Soetens wrote:
> The env.sh script sets these env variables:
>
> export RUBYOPT=-rubygems
> export GEM_HOME=/home/kaltan/src/git/orocos-dfki-toolchain/.gems
> export PATH=$GEM_HOME/bin:$PATH
>
> Shouldn't we store the .gems in a more common ($HOME/.orocos-gems/) directory
> ? Or is it best practice to keep it only local ?
>
> On Ubuntu 9.10 it sometimes asks the same questions, It at least asked 3 times
> to install git for example (defaulted to 'ask'), during different phases.
>
> Then I got this:
>
> autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
> Build failed: autoproj: failed in osdeps phase
> '/bin/bash /home/kaltan/src/git/orocos-toolchain-dfki/osdeps.sh' returned
> status 100
> see /home/kaltan/src/git/orocos-toolchain-dfki/install/log/autoproj-
> osdeps.log for details
> last 10 lines are:
>
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> libboost-filesystem1.38-dev: Depends: libboost-system1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> libboost-graph1.38-dev: Depends: libboost-serialization1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> Depends: libboost-test1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> libboost-thread1.38-dev: Depends: libboost-date-time1.38-dev (=
> 1.38.0-6ubuntu6.1) but it is not going to be installed
> E: Broken packages
>
> This breaks because I have the 1.40 version installed, which is also part of
> 9.10.
>
> Finally, I get this:
>
> autoproj: building and installing packages
> generating and configuring build system for utilmm
> building utilmm (100%)
> installing utilmm
> generating and configuring build system for rtt
> building rtt (100%)
> installing rtt
> generating and configuring build system for ocl
> building ocl (100%)
> installing ocl
> setting up Ruby package utilrb
> generating and configuring build system for typelib
> autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
> Build failed: typelib: failed in configure phase
> 'cmake -DCMAKE_INSTALL_PREFIX=/home/kaltan/src/git/orocos-toolchain-
> dfki/install/tools -DRUBY_EXECUTABLE=/usr/bin/ruby1.8
> /home/kaltan/src/git/orocos-toolchain-dfki/tools/typelib' returned status 1
> see /home/kaltan/src/git/orocos-toolchain-dfki/install/tools/log/typelib-
> configure.log for details
> last 10 lines are:
>
> -- Boost Version: 1.40.0
> -- boost/test found ... building test suite
> -- cannot find the antlr executable
> CMake Error at cmake/FindAntlr.cmake:99 (MESSAGE):
> Please install the Antlr executable and/or the CPP language packages
> Call Stack (most recent call first):
> test/CMakeLists.txt:1 (FIND_PACKAGE)
>
>
> -- Configuring incomplete, errors occurred!
>
> and the script ends.
>
> This reminds me a lot of the trouble the ROS people had with their rosdep
> tool.
>
> Peter
Also, if this is doing a standard "gem install" kind of thing, on some O/S's (e.g. Mac OS X) it stores the gems in locations particular to the O/S. Assuming something in the user account might not work.
S
boostrap.sh - env.sh - orocos-dfki-toolchain
On 08/27/2010 03:52 PM, S Roderick wrote:
> On Aug 27, 2010, at 09:35 , Peter Soetens wrote:
>
>> The env.sh script sets these env variables:
>>
>> export RUBYOPT=-rubygems
>> export GEM_HOME=/home/kaltan/src/git/orocos-dfki-toolchain/.gems
>> export PATH=$GEM_HOME/bin:$PATH
>>
>> Shouldn't we store the .gems in a more common ($HOME/.orocos-gems/) directory
>> ? Or is it best practice to keep it only local ?
>>
>> On Ubuntu 9.10 it sometimes asks the same questions, It at least asked 3 times
>> to install git for example (defaulted to 'ask'), during different phases.
>>
>> Then I got this:
>>
>> autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
>> Build failed: autoproj: failed in osdeps phase
>> '/bin/bash /home/kaltan/src/git/orocos-toolchain-dfki/osdeps.sh' returned
>> status 100
>> see /home/kaltan/src/git/orocos-toolchain-dfki/install/log/autoproj-
>> osdeps.log for details
>> last 10 lines are:
>>
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>> libboost-filesystem1.38-dev: Depends: libboost-system1.38-dev (=
>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>> libboost-graph1.38-dev: Depends: libboost-serialization1.38-dev (=
>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>> Depends: libboost-test1.38-dev (=
>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>> libboost-thread1.38-dev: Depends: libboost-date-time1.38-dev (=
>> 1.38.0-6ubuntu6.1) but it is not going to be installed
>> E: Broken packages
>>
>> This breaks because I have the 1.40 version installed, which is also part of
>> 9.10.
>>
>> Finally, I get this:
>>
>> autoproj: building and installing packages
>> generating and configuring build system for utilmm
>> building utilmm (100%)
>> installing utilmm
>> generating and configuring build system for rtt
>> building rtt (100%)
>> installing rtt
>> generating and configuring build system for ocl
>> building ocl (100%)
>> installing ocl
>> setting up Ruby package utilrb
>> generating and configuring build system for typelib
>> autoproj: updated /home/kaltan/src/git/orocos-toolchain-dfki/env.sh
>> Build failed: typelib: failed in configure phase
>> 'cmake -DCMAKE_INSTALL_PREFIX=/home/kaltan/src/git/orocos-toolchain-
>> dfki/install/tools -DRUBY_EXECUTABLE=/usr/bin/ruby1.8
>> /home/kaltan/src/git/orocos-toolchain-dfki/tools/typelib' returned status 1
>> see /home/kaltan/src/git/orocos-toolchain-dfki/install/tools/log/typelib-
>> configure.log for details
>> last 10 lines are:
>>
>> -- Boost Version: 1.40.0
>> -- boost/test found ... building test suite
>> -- cannot find the antlr executable
>> CMake Error at cmake/FindAntlr.cmake:99 (MESSAGE):
>> Please install the Antlr executable and/or the CPP language packages
>> Call Stack (most recent call first):
>> test/CMakeLists.txt:1 (FIND_PACKAGE)
>>
>>
>> -- Configuring incomplete, errors occurred!
>>
>> and the script ends.
>>
>> This reminds me a lot of the trouble the ROS people had with their rosdep
>> tool.
>>
>> Peter
>
>
> Also, if this is doing a standard "gem install" kind of thing, on some O/S's (e.g. Mac OS X) it stores the gems in locations particular to the O/S. Assuming something in the user account might not work.
> S
If the local gem does not take care of the GEM_HOME, then it is
transparent to autoproj (I'm using the rubygems API).
For people that want to install the gems somewhere else, one can set the
AUTOPROJ_GEM_HOME envvar to whatever location you prefer.