Ubuntu
qt4-x11 package

  1. Bug #707794
  2. Comment #42

Comment 42 for bug 707794

Revision history for this message
Ricardo Salveti (rsalveti) wrote : Re: [Bug 707794] Re: libqt4-opengl on armel should be compiled with OpenGL ES 2.x support

On Thu, May 5, 2011 at 8:28 AM, Scott Kitterman <email address hidden> wrote:
> Here's the feedback from the Debian pyside maintainer.  It seems
> reasonable to me.  Comments?
>
> [07:12:34] <ScottK> OdyX: Would you please have a look at https://bugs.launchpad.net/ubuntu/+source/pyside/+bug/707794 and consider including https://launchpadlibrarian.net/70829859/pyside_1.0.1-1ubuntu0.1.debdiff in your next upload (obviously the changelog entry doesn't work for Debian)?
> [07:14:28] <OdyX> ScottK: will do, thanks for the heads'up.
> [07:14:36] <ScottK> Great.  Thanks.
> [07:25:38] <OdyX> ScottK: huh, no… This patch is no-op (AFAIK, on Debian at least), as mesa-common-dev is already pulled in, B-D on libqt4-opengl-dev > libgl1-mesa-dev > mesa-common-dev .
> [07:25:46] <OdyX> Did Ubuntu break this chain ?
> [07:26:10] <ScottK> OdyX: "Changed".  We switched from GL to GLES in Qt on armel.
> [07:26:34] <ScottK> So it's a no-op for Debian and fixes an actual problem in Ubuntu.
> [07:26:52] <OdyX> ScottK: then requiring PySide to explicitely B-D on mesa-common-dev is wrong (IMHO), it must be done in the libqt4-opengl-dev package.
> [07:27:45] <ScottK> OdyX: Makes sense.  I'll take it up with the people making that recommendation.  Thanks.

It's not wrong, as Qt could be compiled with GL or GLES backend, and
it we can't rely on it to bring the GL headers in both situations.

Also, it doesn't make sense to change the libgles2-mesa-dev package to
depend on libgl1-mesa-dev, as it's not needed. And we can also have
the case where you want to build using some vendor's GLES drivers,
that provides libgles2-dev (libqt4-opengl-dev depends on
libgles2-mesa-dev | libgles2-dev).

After looking again it seems for me that upstream is just wrong
assuming Qt will have OpenGL support if it can find gl.h in the
system. It seems that it should just rely on
HAS_QT_MODULE(QT_QTOPENGL_FOUND QtOpenGL), or at least check both gl.h
and egl.h if it's really needed.

Will discuss with upstream to see what is the preferred fix, meanwhile
we can remove the mesa relation with this bug.