https://git.openrobots.org/https://git.openrobots.org/favicon.ico?14752240372021-04-23T12:46:19ZOpenrobotsrobotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7712021-04-23T12:46:19ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>I didn't see any blatant issue by just looking at the diff, so I<br />push it and we'll see. Do you plan to also clean-up wip/ ?</p>
<p>There will be an issue with py27-hpp-affordance-corba, which is the<br />same as the current issue with hpp-manipulation-corba: they both<br />depend on hpp-templace-corba, and thus indirectly on omniORB, that<br />needs python.</p>
<p>hpp-template-corba and omniorb are not prefixed with PKGTAG.python<br />which creates the problem. I'm not sure if all those should be<br />prefixed with PKGTAG.python...</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7722021-04-26T10:14:40ZGuilhem Saurel
<ul></ul><p>Hello,</p>
<p>I cleaned wip/, but forgot a package, so the build failed. I just push a fix.</p>
<p>I also catch a C++ standard issue in hpp-util, and pushed a trivial fix, which seems to work.</p>
<p>hpp-pinocchio still didn't on 16.04, because GCC segfaults on a std::remove_if… I'll workaround that.</p>
<p>For the issue with hpp-template-corba, do we already have an error somewhere ?</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7732021-04-26T10:23:02ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>On Monday 26 Apr 2021, at 12:14, Guilhem Saurel wrote:</p>
<blockquote>
<p>I also catch a C++ standard issue in hpp-util, and pushed a trivial<br />fix, which seems to work.</p>
</blockquote>
<p>Yes, fine.</p>
<blockquote>
<p>hpp-pinocchio still didn't on 16.04, because GCC segfaults on a<br />std::remove_if… I'll workaround that.</p>
</blockquote>
<p>I was also looking at that, considering just requiring gcc > 5.5, but<br />if you have a solution that's also nice.</p>
<p>While there, could you also require hpp-pinocchio > 4.11 by default,<br />because of the updated PLIST? (package.xml added, which is not found<br />for earlier versions). An alternative is to not put package.xml in the<br />SYSTEM_SEARCH, so that older version works too.</p>
<blockquote>
<p>For the issue with hpp-template-corba, do we already have an error<br />somewhere ?</p>
</blockquote>
<p>I focused on hpp-pinocchio so far, so I haven't checked yet. Let's see<br />once the build is a bit cleaner.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7742021-04-26T12:14:14ZGuilhem Saurel
<ul></ul><p>That's right, it would be nice to just avoid GCC 5.4 here.</p>
<p>On 16.04, the default clang seems to work well. Is there any way to switch to clang if GCC < 5.5 ?</p>
<p>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.<br />Since it will be easier to track exceptions, I suggest this: <br /><a class="external" href="https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba">https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba</a><br />(a quick rebuild on 18.04 seems to work)</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7762021-04-26T13:08:58ZGuilhem Saurel
<ul></ul><p>hpp-corbaserver might also have some issue with old GCC: <a class="external" href="https://github.com/humanoid-path-planner/hpp-corbaserver/issues/137">https://github.com/humanoid-path-planner/hpp-corbaserver/issues/137</a></p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7772021-04-26T13:15:12ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>On Monday 26 Apr 2021, at 14:14, Guilhem Saurel wrote:</p>
<blockquote>
<p>On 16.04, the default clang seems to work well. Is there any way to<br />switch to clang if GCC < 5.5 ?</p>
</blockquote>
<p>The switch between gcc and clang is not currently thought in this way:<br />this is a user option that is kind of global. I'm not sure it is<br />always safe to mix clang and gcc object, especially for C++ ... so<br />the intended consistency seems cleaner.</p>
<p>In addition, the list of dependencies cannot be changed once they<br />start to be checked, so switching from gcc to clang is not possible<br />once we know the version of gcc. (Of course it could probably still be<br />hacked in some way).</p>
<p>Since the problem seems to come from the auto parameter in the lambda,<br />is it really an issue to use the actual typename instead of auto?<br />I tried with ::pinocchio::CollisionPair and it built fine (but I've no<br />idea if this is the right type and why 'auto' was used instead).</p>
<blockquote>
<p>I suggest this:<br /><a class="external" href="https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba">https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba</a><br />(a quick rebuild on 18.04 seems to work)</p>
</blockquote>
<p>I would rather call it "HPP_MIN_VERSION" instead of "MAIN_VERSION" but<br />otherwise yes, it's a good idea.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7782021-04-28T16:51:53ZGuilhem Saurel
<ul></ul><p>Hello,</p>
<p>I changed this name: https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c</p>
<p>After a quick survey, it seems OK to forget the HPP binaries for 16.04, so we can go for this:<br /><a class="external" href="https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576">https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576</a></p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7792021-04-29T10:50:43ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>On Wednesday 28 Apr 2021, at 18:51, Guilhem Saurel wrote:</p>
<blockquote>
<p>I changed this name:<br /><a class="external" href="https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c">https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c</a></p>
</blockquote>
<p>OK. However, HPP_MIN_VERSION and HPP_VERSION are not the same in<br />general. Since including a "depend"-like file in a "Makefile" is also<br />a bad idea (generally speaking), I removed the inclusion and define<br />hpp version in a standalone way.</p>
<blockquote>
<p>After a quick survey, it seems OK to forget the HPP binaries<br />for 16.04, so we can go for this:<br /><a class="external" href="https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576">https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576</a></p>
</blockquote>
<p>OK. I moved the constraint after inclusion of c++.mk to still get any<br />default value set there.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7822021-05-06T08:27:08ZGuilhem Saurel
<ul></ul><p>Hello,</p>
<p>You were right on the issues with PKGTAG.python.<br />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.</p>
<p>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.</p>
<p>First of all, it seems that the PYTHON_SELF_CONFLICT is inverted in meta-pkgs/hpp/Makefile.common.<br />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.</p>
<pre>
# 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
</pre>
<p>I would expect robotpkg-py27-eigenpy here.</p>
<p>On the other hand, this conflict mechanism works well between eg. robotpkg-hpp-fcl & robotpkg-hpp-fcl+doc.</p>
<p>Do you have an idea why this PYTHON_SELF_CONFLICT is not working as intended ? Or maybe did I understand this wrong ?</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7862021-05-11T10:39:42ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>I fixed something badly wrong with <a class="changeset" title="[mk/sysdep] Add missing macros definition for {PYTHON,QT}_SELF_CONFLICT def. Due to early inclus..." href="https://git.openrobots.org/projects/robotpkg/repository/robotpkg/revisions/50fa64a667104a7250263573e79a0dbaaf235ba4">50fa64a</a></p>
<p>I'm not sure this will solve everything, as the initial issue will<br />remain: pulling a wrong python dependency that is not supposed to be<br />there (sysdep and not robotpkg package).</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7872021-05-12T12:09:43ZGuilhem Saurel
<ul></ul><p>This is clearly better now, thanks a lot !</p>
<p>There is still a C++98 issue in pinocchio on 16.04, but I'll take care of this in another place.</p>
<p>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.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7882021-05-12T13:47:33ZGuilhem Saurel
<ul></ul><p>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:<br /><a class="external" href="https://github.com/nim65s/robotpkg/commit/97f341111edccf6be835db116d9520901afc8180">https://github.com/nim65s/robotpkg/commit/97f341111edccf6be835db116d9520901afc8180</a></p>
<p>While here, I also found a detail: <a class="external" href="https://github.com/nim65s/robotpkg/commit/4443cd679a4f51112b6ef26afcadd40ce1387e5e">https://github.com/nim65s/robotpkg/commit/4443cd679a4f51112b6ef26afcadd40ce1387e5e</a></p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7892021-05-12T14:14:48ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>OK, thanks!</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7902021-05-14T10:29:34ZGuilhem Saurel
<ul></ul><p>Hello,</p>
<p>Now that the conflicts are working as expected, let's look at those python dependency issues.</p>
<p>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.</p>
<p>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</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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 ?</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7912021-05-17T08:08:31ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>On Friday 14 May 2021, at 12:29, Guilhem Saurel wrote:</p>
<blockquote>
<p>Yet another idea would be to split py-hpp-baxter into a python<br />package and a non-python package, as I guess hpp-pinocchio only need<br />the non-python part of it.</p>
</blockquote>
<p>That sounds like the best option.</p>
<blockquote>
<p>I think I would go for the last part. But before I jump in and<br />actually try that, do you have any comment or suggestion on this<br />topic ?</p>
</blockquote>
<p>I think in future, python2 will really start to disappear. python3<br />incompatibilites will also likely vanish, so we could go for a single<br />"python3" dependency (and drop the PKGTAG). So splitting py-hpp-baxter<br />into python/non-python seems the easiest if that's the only remaining<br />issue.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7922021-05-17T08:18:13ZGuilhem Saurel
<ul></ul><p>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 <del>_</del></p>
<p>Here is the fix, then: <a class="external" href="https://github.com/nim65s/robotpkg/commit/142f1695afa060f1b4d4206fce12c0c7a967508a">https://github.com/nim65s/robotpkg/commit/142f1695afa060f1b4d4206fce12c0c7a967508a</a></p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7932021-05-17T08:21:36ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>On Monday 17 May 2021, at 10:18, Guilhem Saurel wrote:</p>
<blockquote>
<p>Ok, actually, I was just wrong. Hpp-pinocchio doesn't need<br />hpp-baxter anymore, as the required description files have been made<br />available in example-robot-data & hpp-environment _</p>
</blockquote>
<p>Even better...<br />I bumped the PKGREVISION.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7942021-05-18T06:57:39ZGuilhem Saurel
<ul></ul><p>This is working as expected too, thanks !</p>
<p>But I have found another strange thing: talos-rbprm is only available in 4.10, while talos-rbprm+doc is correctly on 4.11:</p>
<pre>
╰─>$ 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)
</pre>
<p><a class="external" href="http://robotpkg.openrobots.org/rbulk/robotpkg/robots/py-talos-rbprm/">http://robotpkg.openrobots.org/rbulk/robotpkg/robots/py-talos-rbprm/</a></p>
<p>Any idea about the cause of this issue ?</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7952021-05-18T08:30:31ZAnthony Malletanthony.mallet@laas.fr
<ul></ul><p>On Tuesday 18 May 2021, at 08:57, Guilhem Saurel wrote:</p>
<blockquote>
<p>But I have found another strange thing: talos-rbprm is only<br />available in 4.10, while talos-rbprm+doc is correctly on 4.11:</p>
</blockquote>
<p>It was not listed in SUBDIR, so it was built only because it appeared<br />as a dependency. Since the dependencies don't care about <sub>doc or<br /></sub>!doc, the default was choosen, i.e. ~doc.</p>
<p>I pushed a fix.</p> robotpkg - Pull request #309: new HPP releasehttps://git.openrobots.org/issues/309?journal_id=7962021-05-19T10:30:09ZGuilhem Saurel
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul><p>Ok, I should have checked that, thanks for the fix !</p>
<p>With this, I think everything is working as well as expected, thanks for all the work here :)</p>