robotpkg

I didn't see any blatant issue by just looking at the diff, so I
push it and we'll see. Do you plan to also clean-up wip/ ?

There will be an issue with py27-hpp-affordance-corba, which is the
same as the current issue with hpp-manipulation-corba: they both
depend on hpp-templace-corba, and thus indirectly on omniORB, that
needs python.

hpp-template-corba and omniorb are not prefixed with PKGTAG.python
which creates the problem. I'm not sure if all those should be
prefixed with PKGTAG.python...

Hello,

I cleaned wip/, but forgot a package, so the build failed. I just push a fix.

I also catch a C++ standard issue in hpp-util, and pushed a trivial fix, which seems to work.

hpp-pinocchio still didn't on 16.04, because GCC segfaults on a std::remove_if… I'll workaround that.

For the issue with hpp-template-corba, do we already have an error somewhere ?

On Monday 26 Apr 2021, at 12:14, Guilhem Saurel wrote:

I also catch a C++ standard issue in hpp-util, and pushed a trivial
fix, which seems to work.

Yes, fine.

hpp-pinocchio still didn't on 16.04, because GCC segfaults on a
std::remove_if… I'll workaround that.

I was also looking at that, considering just requiring gcc > 5.5, but
if you have a solution that's also nice.

While there, could you also require hpp-pinocchio > 4.11 by default,
because of the updated PLIST? (package.xml added, which is not found
for earlier versions). An alternative is to not put package.xml in the
SYSTEM_SEARCH, so that older version works too.

For the issue with hpp-template-corba, do we already have an error
somewhere ?

I focused on hpp-pinocchio so far, so I haven't checked yet. Let's see
once the build is a bit cleaner.

That's right, it would be nice to just avoid GCC 5.4 here.

On 16.04, the default clang seems to work well. Is there any way to switch to clang if GCC < 5.5 ?

I should definitely have updated all DEPEND_ABI for HPP 4.11. This is generally true for all main HPP upgrades, where the ABI is usually broken in many places.
Since it will be easier to track exceptions, I suggest this:
https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba
(a quick rebuild on 18.04 seems to work)

hpp-corbaserver might also have some issue with old GCC: https://github.com/humanoid-path-planner/hpp-corbaserver/issues/137

On Monday 26 Apr 2021, at 14:14, Guilhem Saurel wrote:

On 16.04, the default clang seems to work well. Is there any way to
switch to clang if GCC < 5.5 ?

The switch between gcc and clang is not currently thought in this way:
this is a user option that is kind of global. I'm not sure it is
always safe to mix clang and gcc object, especially for C++ ... so
the intended consistency seems cleaner.

In addition, the list of dependencies cannot be changed once they
start to be checked, so switching from gcc to clang is not possible
once we know the version of gcc. (Of course it could probably still be
hacked in some way).

Since the problem seems to come from the auto parameter in the lambda,
is it really an issue to use the actual typename instead of auto?
I tried with ::pinocchio::CollisionPair and it built fine (but I've no
idea if this is the right type and why 'auto' was used instead).

I suggest this:
https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba
(a quick rebuild on 18.04 seems to work)

I would rather call it "HPP_MIN_VERSION" instead of "MAIN_VERSION" but
otherwise yes, it's a good idea.

Hello,

I changed this name: https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c

After a quick survey, it seems OK to forget the HPP binaries for 16.04, so we can go for this:
https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576

On Wednesday 28 Apr 2021, at 18:51, Guilhem Saurel wrote:

I changed this name:
https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c

OK. However, HPP_MIN_VERSION and HPP_VERSION are not the same in
general. Since including a "depend"-like file in a "Makefile" is also
a bad idea (generally speaking), I removed the inclusion and define
hpp version in a standalone way.

After a quick survey, it seems OK to forget the HPP binaries
for 16.04, so we can go for this:
https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576

OK. I moved the constraint after inclusion of c++.mk to still get any
default value set there.

Hello,

You were right on the issues with PKGTAG.python.
And this PR created a few more: hpp-pinocchio now depends on py-hpp-baxter, so installing hpp-pinocchio installs py27-hpp-baxter version by default.

After that, if one tries to install py36-hpp-baxter, we get an error. I thought that apt would now that those 2 packages are incompatible and remove the py27 before installing py36, but it is not.

First of all, it seems that the PYTHON_SELF_CONFLICT is inverted in meta-pkgs/hpp/Makefile.common.
But then, even in some packages where PYTHON_SELF_CONFLICT looks good, like py-eigenpy, installing robotpkg-py27-eigenpy then robotpkg-py36-eigenpy fails, instead of removing robotpkg-py27-eigenpy to resolve the conflict.

# apt depends robotpkg-py36-eigenpy
robotpkg-py36-eigenpy
  Depends: libboost-python1.65-dev (>= 1.34.1)
  Depends: libeigen3-dev (>= 3.0.0)
  Depends: libstdc++6
  Depends: python3-numpy (>= 1:1)
  Depends: python3.6-minimal (>= 3.6)
  Depends: python3.6-minimal (<< 3.7)
  Depends: libpython3.6-dev (>= 3.6)
  Depends: libpython3.6-dev (<< 3.7)
  Conflicts: robotpkg-py36-eigenpy
  Replaces: robotpkg-py36-eigenpy

I would expect robotpkg-py27-eigenpy here.

On the other hand, this conflict mechanism works well between eg. robotpkg-hpp-fcl & robotpkg-hpp-fcl+doc.

Do you have an idea why this PYTHON_SELF_CONFLICT is not working as intended ? Or maybe did I understand this wrong ?

I fixed something badly wrong with 50fa64a

I'm not sure this will solve everything, as the initial issue will
remain: pulling a wrong python dependency that is not supposed to be
there (sysdep and not robotpkg package).

This is clearly better now, thanks a lot !

There is still a C++98 issue in pinocchio on 16.04, but I'll take care of this in another place.

We also have an issue with between gepetto-viewer-corba and omniORB on debian 9. I can't reproduce it in my development setup: everything works as expected, with omniORB from robotpkg and from debian. But this is not a priority, as I am not aware of anybody needing this binary package on that platform.

Ok, I spoke too fast. This PYTHON_SELF_CONFLICT behave as intended for eigenpy, but not for HPP packages… I think I found the culprit:
https://github.com/nim65s/robotpkg/commit/97f341111edccf6be835db116d9520901afc8180

While here, I also found a detail: https://github.com/nim65s/robotpkg/commit/4443cd679a4f51112b6ef26afcadd40ce1387e5e

OK, thanks!

Hello,

Now that the conflicts are working as expected, let's look at those python dependency issues.

As you pointed out, "apt depends robotpkg-omniorb" & "apt depends robotpkg-hpp-template-corba" shows a dependency to python2.7-minimal + libpython2.7-dev (3.8 on 20.04). This is not necessary, but I don't think that it hurt, unless someone really needs a system without python, in which case we'll have to find a way to put python as a build dependency but not as a runtime dependency. But I don't think that adding a PKGTAG would help anybody.

On the other side, "apt depends robotpkg-hpp-pinocchio" show "robotpkg-py27-hpp-baxter", and only the python 2.7 alternative. This is a breaking issue for people who want both hpp-pinocchio and py3x-hpp-baxter, and I'm surprise they didn't already contact me about that... Maybe the long WE is helping :D

So I guess we should either find a way to put all python alternatives on the depend section of packages that don't actually need a particular python version, or artificially specialize those packages by adding a PKGTAG.

In the second case, we'll move the issue to all packages that don't already have a PKGTAG.python and depend on hpp-pinocchio (ie. path/hpp-manipulation-urdf, path/hpp-walkgen, path/hpp-constraints, and path/hpp-core).

Another workaround would be to consider the dependency from hpp-pinocchio to py-hpp-baxter as optional, is this is actually required only for unit tests.

Yet another idea would be to split py-hpp-baxter into a python package and a non-python package, as I guess hpp-pinocchio only need the non-python part of it.

I think I would go for the last part. But before I jump in and actually try that, do you have any comment or suggestion on this topic ?

On Friday 14 May 2021, at 12:29, Guilhem Saurel wrote:

Yet another idea would be to split py-hpp-baxter into a python
package and a non-python package, as I guess hpp-pinocchio only need
the non-python part of it.

That sounds like the best option.

I think I would go for the last part. But before I jump in and
actually try that, do you have any comment or suggestion on this
topic ?

I think in future, python2 will really start to disappear. python3
incompatibilites will also likely vanish, so we could go for a single
"python3" dependency (and drop the PKGTAG). So splitting py-hpp-baxter
into python/non-python seems the easiest if that's the only remaining
issue.

Ok, actually, I was just wrong. Hpp-pinocchio doesn't need hpp-baxter anymore, as the required description files have been made available in example-robot-data & hpp-environment _

Here is the fix, then: https://github.com/nim65s/robotpkg/commit/142f1695afa060f1b4d4206fce12c0c7a967508a

On Monday 17 May 2021, at 10:18, Guilhem Saurel wrote:

Ok, actually, I was just wrong. Hpp-pinocchio doesn't need
hpp-baxter anymore, as the required description files have been made
available in example-robot-data & hpp-environment _

Even better...
I bumped the PKGREVISION.

This is working as expected too, thanks !

But I have found another strange thing: talos-rbprm is only available in 4.10, while talos-rbprm+doc is correctly on 4.11:

╰─>$ apt search talos-rbprm
En train de trier... Fait
Recherche en texte intégral... Fait
robotpkg-py27-talos-rbprm/bionic 4.10.0 amd64
  Humanoid Path Planner (Database for talos robot using hpp-rbprm)

robotpkg-py27-talos-rbprm+doc/bionic 4.11.0 amd64
  Humanoid Path Planner (Database for talos robot using hpp-rbprm)

robotpkg-py36-talos-rbprm/bionic 4.10.0 amd64
  Humanoid Path Planner (Database for talos robot using hpp-rbprm)

robotpkg-py36-talos-rbprm+doc/bionic 4.11.0 amd64
  Humanoid Path Planner (Database for talos robot using hpp-rbprm)

http://robotpkg.openrobots.org/rbulk/robotpkg/robots/py-talos-rbprm/

Any idea about the cause of this issue ?

On Tuesday 18 May 2021, at 08:57, Guilhem Saurel wrote:

But I have found another strange thing: talos-rbprm is only
available in 4.10, while talos-rbprm+doc is correctly on 4.11:

It was not listed in SUBDIR, so it was built only because it appeared
as a dependency. Since the dependencies don't care about _{doc or}
!doc, the default was choosen, i.e. ~doc.

I pushed a fix.