robotpkg

I also added a new version of robots/{py-,}example-robot-data.

• graphics/py-pythonqt: it is not the same as mk/sysdep/py-qt{4,5}.mk right?
  Why PREFER = robotpkg by default?
• graphics/osgqt is missing a PREFER default
• In graphics/py-qt-gepetto-viewer, the "ifeq
  (qt4,${PKG_ALTERNATIVE.qt})" will not work: in gnu-make, the "if"
  trigger immediate evaluation of variables, and as this point
  PKG_ALTERNATIVE.qt is most likely not defined.
  (See
  https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html#index-ifeq_002c-expansion
  for immediate vs. deferred expansion)
  You should use a functional "$(if ...)" to get deferred expansion.
• mk/sysdep/openscegraph should be (re)moved

On Monday 22 Jun 2020, at 10:36, Guilhem Saurel wrote:

My issue here is that I need to conditionally include py-pythonqt,
and I can't find any way to to this with a functional "$(if ...)".

That could be something like $(if ...,$(eval include ...)).
But dependencies cannot be added after alternative resolution, so this
would not work either.

The most obvious way to handle this is to have two distinct packages.
Is Qt4 support really required?

If Qt5 works well in all our use cases, we don't need Qt4. I think it is worth a try.
If we have any issue, we will be able to fallback to distinct packages, but not before we find that it is required.

On Monday 22 Jun 2020, at 12:40, Guilhem Saurel wrote:

If Qt5 works well in all our use cases, we don't need Qt4. I think
it is worth a try. If we have any issue, we will be able to
fallback to distinct packages, but not before we find that it is
required.

OK

I did a preliminary merge with openscenegraph, to fix the small build
issues and deal with that first.

What about openthreads? You removed it because it's not required?

openthreads is a component of openscenegraph, and I'm not sure if we really need it or not.

I see that you changed PREFER.openscenegraph for system. But the point of this PR is that, at least on 16.04, 18.04, 20.04 and Arch (and probably debian), the openscenegraph package provided by the system is not build with collada-dom, then the osg-dae plugin is missing, while we actually need it.

On Monday 22 Jun 2020, at 16:51, Guilhem Saurel wrote:

I see that you changed PREFER.openscenegraph for system. But the
point of this PR is that, at least on 16.04, 18.04, 20.04 and Arch
(and probably debian), the openscenegraph package provided by the
system is not build with collada-dom, then the osg-dae plugin is
missing, while we actually need it.

Ah. But #255 was about Qt5 :)
I guess it's not possible to just provide a package for just osg-dae?
(like osgqt)

Ah, yes, the situation was so bad I was too lazy to summarize it, sorry x)

So basically, gepetto-viewer needs OSG, with Qt to draw windows and with DAE to load collada files.
Both Qt & DAE are plugins distributed inside OSG code base.

DAE was never provided with Debian or Ubuntu system packages, so we always had to distribute it in another way, basically by downloading OSG source code, and running "make && make install" in the DAE directory.

Qt4 was provided with Debian and Ubuntu, then in 2015 Debian switched to Qt5, and I was waiting for ubuntu to follow, so that we could get rid of Qt4.

But in 2018, OSG released its 3.6.0 version which removed the Qt plugin from their code base, to put it into another repository, so ubuntu just stopped providing Qt in 20.04.

So if we want OSG & DAE & Qt, we could
- use the system package for OSG & Qt until 20.04, plus compile DAE on the side
- use the system package for OSG from 20.04, plus compile Qt & DAE on the side

But this still wouldn't give us Qt5.

Plus 16.04 has OSG 3.2, 18.04 has 3.4 & 20.04 has 3.6, and I don't know if we can isolate one version of the DAE plugin and one version of the Qt plugin that would work on all those OSG versions.

So my guess is that it would be easier to provide OSG 3.6 everywhere and include DAE, plus provide Qt from its upstream new repository.

Maybe it's possible to make our wip/osg-dae package work again on Ubuntu 20.04 / OSG 3.6, but its source is a copy-paster from OSG 3.2 https://github.com/gepetto/osg-dae, so I'd prefer to drop it and switch back to the upstream. We could make another osg-dae package, providing the whole OSG source to robotpkg and building only the dae plugin, but I don't know if it would work in 16.04, and this would be more work for us than just provide directly OSG including the plugin.

Hi,

From what I see, most packages are now building correctly, thanks !

We are just lacking boost-libs (and qmake & qt4-libs for Qt4) on 20.04. It is just an apt install away, is it not ?

But for the binary packages, at least on 18.04, robotpkg-qt{4,5}-osgqt are dependending on robotpkg-openscenegraph 3.6.5 | 3.6.5r1 ; while the current package is 3.6.5r3. Maybe a PKGREVISION bump was missed at some point ?

On Thursday 25 Jun 2020, at 08:08, Guilhem Saurel wrote:

We are just lacking boost-libs (and qmake & qt4-libs for Qt4)
on 20.04. It is just an apt install away, is it not ?

Not quite:

hydra64-ubuntu2004:/> apt search libqt4-dev
Sorting... Done
Full Text Search... Done

I think I can install everything now, thanks !

But we still have some issues:

- "apt show -a robotpkg-qt5-osgqt" shows a 3.6.0 version in wip.

This version didn't actually exist upstream, it was created in our fork but it doesn't work at all: I was mislead by this: https://github.com/Gepetto/osgQt/releases.
Therefore, when running "robotpkg-py36-qt5-gepetto-viewer", I get an error because the last version of this pakage requires robotpkg-qt5-osgqt=3.5.7r2 and apt is not able to just do it. So we need to manually run "sudo apt install robotpkg-qt5-osgqt=3.5.7r2" before.

To fix this, can we remove that package from the wip apt repository ? Or do we have to increment an epoch number or something like that ?

- gepetto-viewer-corba is not working in python3. I don't know yet if this is a code or a packaging issue, I'll try to find this as soon as possible.

- pythonqt looks to build fine, but gepetto-viewer is not yet configured to use it. There is absolutely no hurry about that, I can take some time to do as many checks as possible before changing that, in order to avoid any other majore break of those packages :)

On Saturday 27 Jun 2020, at 10:36, Guilhem Saurel wrote:

To fix this, can we remove that package from the wip apt repository
?

That was a bit painful, but it should be cleanly removed from wip now!