libqt4-opengl on armel should be compiled with OpenGL ES 2.x support

This debdiff should be enough to change it at the package level.

One test I'm currently working on is to rebuild all packages that currently use libqt4-opengl, and see if they still build and work properly, as it's kind of common to use Qt OpenGL together with direct OpenGL code.

From Main, we have the following problems:
1 - avogadro: uses OpenGL and libqt4-opengl, and as a result it'll have symbols collision and the build will fail (no easy solution);
2 - kdeedu: need to remove Kalzium, as it uses avogadro and libqt4-opengl;
3 - kdegames: need to remove OpenGL support, and as a side effect Kubrick will not be built and KSudoku will not have Roxdoku support;
4 - kipi-plugins: need to remove OpenGL support;
5 - koffice: need to remove GLEW support;

And in general all packages that use libqt4-opengl with GLEW or normal OpenGL, will fail to build. For those packages the solution would be to remove OpenGL support, when possible.

Ricardo, can qt be built to provide both GL and GLES in the same time by creating both library sets?
Then on armel we could have both and use indirect rendering for apps that require GL.

On Tue, Feb 1, 2011 at 7:16 AM, Jani Monoses <email address hidden> wrote:
> Ricardo, can qt be built to provide both GL and GLES in the same time by creating both library sets?
> Then on armel we could have both and use indirect rendering for apps that require GL.

The problem is that Qt is huge, both in size and in build time, making
almost impossible to maintain two builds just to have GL and GLES
support.

Linaro is developing a proxy library that will probably help making
the decision to use GL or GLES at runtime, but that will only be ready
for Natty+1. For Natty I'd say we could just disable OpenGL support
for applications that will break, and live with it. Using software
OpenGL on ARM is currently almost impossible, because of the lack of a
good CPU that could render it by software, so I really don't believe
people will use those applications, even if we support it for this
cycle.

What do you think?

I don't think removing Kalzium and Kubrick would be an option.

On Wed, Feb 2, 2011 at 2:08 PM, Jonathan Thomas <email address hidden> wrote:
> I don't think removing Kalzium and Kubrick would be an option.

Kalzium can still be enabled, but without the molecular editor.
Kubrick is disabled automatically once you remove OpenGL support.

If you plan to have just one Qt package, and with GLES support, there
is no other way unless you add GLES support at those applications.
Other option would be to have Qt with both GL and GLES support, but
then it's hard to maintain both libraries sets, as Qt is huge and take
an incredible amount of time to build.

If we don't want to break normal usage of Qt and KDE at the ARM image, then I believe the best solution for the moment is to postpone this change at the archive for next cycle and only provide a PPA for users that want to test and use Qt with GLES.

Linaro is building a proxy library that will help making the decision to use GL or GLES at runtime, and also porting GLEW to GLES, so I believe we'll be in a much better shape to do this transition for the next cycle.

In case another solution is proposed, I'll be happy to work on it.

It doesn't seem that the identified impacts are unreasonable for armel. This will impact python-qt4 as well.

Or maybe it won't:

<slangasek> python-qt4 only build-depends on libqt4-opengl-dev, not directly on any of the mesa libraries, and switching to gles2 isn't supposed to break ABI for qt4-opengl.

This bug was fixed in the package qt4-x11 - 4:4.7.1-0ubuntu11

---------------
qt4-x11 (4:4.7.1-0ubuntu11) natty; urgency=low

  [ Felix Geyer ]
  * Explicitly disable EGL support on all architectures except ARM. The last
    version accidentally enabled it as libegl1-mesa-dev was pulled in.
    (LP: #724867)

  [ Jonathan Riddell ]
  * Cast use of double in kubuntu_28_xi2.1.patch to fix FTBFS on armel.

  [ Ricardo Salveti de Araujo ]
  * Changing OpenGL backend from GL to GLES 2 for ARM (LP: #707794)
 -- Felix Geyer <email address hidden> Fri, 25 Feb 2011 14:21:36 +0100

opening tasks for the other affected packages that need to get fixed up to disable opengl support.

So this is supposed to be ABI-compatible with the opengl build, but I see the following symbols dropped on armel as a result of this change:

 QGLContext::chooseVisual()@Base 4:4.7.0~rc1
 QGLContext::tryVisual(QGLFormat const&, int)@Base 4:4.7.0~rc1
 QTransform::QTransform(QTransform const&)@Base 4:4.7.0
 QPaintEngineEx::pixmapFilter(int, QPixmapFilter const*)@Base 4:4.6.1
 QPaintEngineEx::endNativePainting()@Base 4:4.6.1
 QPaintEngineEx::beginNativePainting()@Base 4:4.6.1
 QString::QString(QLatin1String const&)@Base 4:4.5.3
 QPolygon::~QPolygon()@Base 4:4.7.0
 QHashData::hasShrunk()@Base 4:4.7.0

and two symbols have been added:
 qt_resolve_eglimage_gl_extensions(QGLContext*)@Base 4:4.7.1-0ubuntu11
 QReadLocker::~QReadLocker()@Base 4:4.7.1-0ubuntu11

I guess most of these symbols are pulled in via C++ headers and don't really matter, but the two QGLContext symbols may be an issue. Do we need to fix qt4-x11 to provide stubs for these functions when built for GLES2?

$ for pkg in $(zcat /home/lp_archive/ubuntu/dists/natty/*/binary-armel/Packages.gz \
   | grep-dctrl -FDepends libqt4-opengl -n -s Filename); do
        dpkg -x ~/ubuntu/$pkg opengl-check
        find opengl-check/usr/{bin,lib} -type f 2>/dev/null | xargs -r file \
        | grep ELF | cut -f1 -d: | xargs -r objdump -T 2>/dev/null | c++filt \
        | grep -qE 'QGLContext::chooseVisual\(\)|QGLContext::tryVisual\(QGLFormat const&, int\)' && echo $pkg
        rm -r opengl-check
done
pool/main/k/kdebindings/libsmokeqtopengl4-3_4.6.0-0ubuntu2_armel.deb
pool/multiverse/m/mythtv/libmyth-0.24-0_0.24.0+fixes.20110214.ad3c81f-0ubuntu1_armel.deb
pool/universe/q/qtscriptgenerator/libqtscript4-opengl_0.1.0-3ubuntu3_armel.deb
pool/universe/p/pyside/python-pyside.qtopengl_0.4.1-0ubuntu1_armel.deb
pool/universe/p/python-qt4/python-qt4-gl_4.8.3-0ubuntu3_armel.deb
$

So there are definitely packages in the archive using these symbols.

This ABI break affects bindings and code that subclasses QGLContext.
mythtv doesn't call those methods so adding stubs should solve the issue.

Attaching a patch that adds the stubs which call qFatal() to make debugging easier in case some code actually calls the methods.

For kdeedu, kalgebra also used GL (at least I think this is related):

In file included from /usr/include/GL/glu.h:38:0,
                 from ../../../kalgebra/src/graph3d.cpp:24:
/usr/include/GL/gl.h:168:17: error: conflicting declaration 'typedef double GLdouble'
/usr/include/qt4/QtOpenGL/qgl.h:74:17: error: 'GLdouble' has a previous declaration as 'typedef GLfloat GLdouble'
In file included from /usr/include/GL/gl.h:2091:0,
                 from /usr/include/GL/glu.h:38,
                 from ../../../kalgebra/src/graph3d.cpp:24:
/usr/include/GL/glext.h:5040:19: error: conflicting declaration 'typedef ptrdiff_t GLintptr'
/usr/include/GLES2/gl2.h:38:26: error: 'GLintptr' has a previous declaration as 'typedef khronos_intptr_t GLintptr'
/usr/include/GL/glext.h:5041:19: error: conflicting declaration 'typedef ptrdiff_t GLsizeiptr'
/usr/include/GLES2/gl2.h:39:26: error: 'GLsizeiptr' has a previous declaration as 'typedef khronos_ssize_t GLsizeiptr'

kdeartwork has been fixed:

kdeartwork (4:4.6.1-0ubuntu2) natty; urgency=low

  * Set WITH_OpenGL=OFF for ARM, don't build-dep on Qt openGL on ARM,
    add debian/kscreensaver.install.armel file to change installed files

 -- Jonathan Riddell <email address hidden> Thu, 24 Mar 2011 12:47:56 +0000

Avogadro doesn't have build system support for building without GL.

This bug was fixed in the package kdegames - 4:4.6.1-0ubuntu2

---------------
kdegames (4:4.6.1-0ubuntu2) natty; urgency=low

  * Don't build-dep on libqt4-opengl-dev and libglu1-mesa-dev on armel to fix
    FTBFS due to attempt to use GL instead of GLES (LP: #707794)
    - Build ksudoko and kubrick only on i386 amd64 powerpc
    - Include ksudoko and kubrick in the kdegrams metapackage only on i386
      amd64 powerpc
    - Switch kdegames to architecture any due to the need for architecture
      specific dependencies
 -- Scott Kitterman <email address hidden> Sat, 26 Mar 2011 01:29:17 -0400

avogadro will pull in GL, so it needs to be fixed before kdeedu can be fixed.

This bug was fixed in the package kipi-plugins - 1.9.0-1ubuntu2

---------------
kipi-plugins (1.9.0-1ubuntu2) natty; urgency=low

  * Fix FTBFS due to attempt to use GL instead of GLES (LP: #707794)
    - libqt4-opengl-dev, libgl1-mesa-dev, and libglu1-mesa-dev as build-deps
      only on [i386 amd64 powerpc]
 -- Scott Kitterman <email address hidden> Sat, 26 Mar 2011 20:13:45 -0400

This bug was fixed in the package koffice - 1:2.3.3-0ubuntu4

---------------
koffice (1:2.3.3-0ubuntu4) natty; urgency=low

  * Only build-dep on libqt4-opengl-dev and libglew1.5-dev on [i386 amd64
    powerpc] to fix armel FTBFS due to the GL/GLES transition (LP: #707794)
    - Add debian/patches/kubuntu_06_krita_link_x.diff to fix indirect linking
      in krita (Thanks to Jonathan Riddell for the patch)
 -- Scott Kitterman <email address hidden> Sun, 27 Mar 2011 14:56:26 -0400

This bug was fixed in the package avogadro - 1.0.1-3.2ubuntu1

---------------
avogadro (1.0.1-3.2ubuntu1) natty; urgency=low

  * Only build-dep on libqt4-opengl-dev and libglew1.5-dev on [i386 amd64
   powerpc] to fix armel FTBFS due to the GL/GLES transition (LP: #707794)
 -- Kunal Goel <email address hidden> Tue, 29 Mar 2011 19:51:48 +0530

   debian/rules override_dh_install
make[1]: Entering directory `/build/buildd/pyside-1.0.0~rc1'
# Move the debug .so's right in place
# Setup the default version symbolic links
# Do the legacy install for the rest
dh_install --list-missing
dh_install: python-pyside.qtopengl missing files (usr/lib/python*/*-packages/PySide/QtOpenGL.so), aborting
make[1]: *** [override_dh_install_2] Error 2
make[1]: Leaving directory `/build/buildd/pyside-1.0.0~rc1'
make: *** [binary-arch] Error 2
dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2

Re-opened the avogadro task since the last attempt failed to build.

Affects mythtv too:

make[4]: Entering directory `/build/buildd/mythtv-0.24.0+fixes.20110410.2a9d9f5/mythtv/libs/libmythui'
ccache g++ -c -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -fPIC -g -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wno-non-virtual-dtor -funit-at-a-time -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -Wmissing-declarations -D_REENTRANT -fPIC -D_GNU_SOURCE -DUSING_VDPAU -DUSING_X11 -DUSE_JOYSTICK_MENU -DUSE_LIRC -DUSING_XRANDR -DUSE_OPENGL_PAINTER -DUSING_QTWEBKIT -DQT_WEBKIT_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtWebKit -I/usr/include/qt4 -I/usr/include -I/usr -I../libmythdb -I../.. -I.. -I../../external/FFmpeg -I/usr/X11R6/include -I. -o mythmainwindow.o mythmainwindow.cpp
In file included from mythmainwindow_internal.h:11:0,
                 from mythmainwindow.cpp:2:
mythrender_opengl.h:93:41: error: 'GL_BGRA' was not declared in this scope
mythrender_opengl.h:93:70: error: 'GL_RGBA8' was not declared in this scope
make[4]: *** [mythmainwindow.o] Error 1

mythtv was fixed a couple of weeks ago by disabling GL in debian/rules, seems the new upload undid that change.

On Monday, April 11, 2011 11:49:27 AM you wrote:
> mythtv was fixed a couple of weeks ago by disabling GL in debian/rules,
> seems the new upload undid that change.

It would be great if you could fix it again.

mythtv (2:0.24.0+fixes.20110410.2a9d9f5-0ubuntu2) natty; urgency=low

  * debian/rules: Disable OpenGL for armel builds, to prevent FTBFS.
 -- Jani Monoses <email address hidden> Mon, 11 Apr 2011 19:16:56 +0300

this is as fixed as it can get for avogadro, the package fundamentally depends on OpenGL APIs that are not being made available to Qt on armel.

gnuradio on armel fails to build because libqwtplot3d-qt4-dev is not usable; I presume this is related to the GLES2 changes since this is an armel-specific build failure.

Build log is here: https://launchpad.net/ubuntu/+source/gnuradio/3.2.2.dfsg-1ubuntu6/+buildjob/2480937

Note for oneric: kdeedu specified architectures using !armel, so when armfh reach the archive, it will have to be fixed again.

Attaching debdiff to phonon-backend-gstreamer which makes opengl optional and disables it on ARM. Uploading to natty-proposed incase it makes sense to include it there.

Scott marked the phonon-backend-gstreamer task as wontfix for natty, so not sure whether to accept this into natty-proposed or not? It's certainly a rather intrusive patch.

At the time I marked it wontfix, I didn't expect a patch. Completely up to you to decide if it's too intrusive.

I reviewed the phonon-backend-gstreamer patch, and it looks like a no-op if GL is available, so approved for the benefit of our ARM fans.

Accepted phonon-backend-gstreamer into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Attaching debdiff to pyside, to include mesa-common-dev as it checks for /usr/include/GL/gl.h before checking for QtOpenGL. After adding this package it'll fix the FTBFS and I confirmed that pyside worked with libqt4-opengl running on ARM (with GLES backend).

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.

Additional feedback:

[07:39:15] <OdyX> ScottK: deeper investigation shows that libgles2-mesa-dev (src:mesa) should get a mesa-common-dev Depends, as libgl1-mesa-dev
[07:39:26] <ScottK> OdyX: Thanks.
[07:39:34] <OdyX> ScottK: this will solve it in a cleaner way, and make PySide build on natty, for free. :-)

Added mesa to the bug based on the feedback from Debian.

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.

After talking with upstream it seems that this check was added to make PySide properly build with Windows, so it seems we can just remove the GL_H check and depend on HAS_QT_MODULE(QT_QTOPENGL_FOUND QtOpenGL). I'm testing the build and will create another debdiff with the proper fix, after trying to send upstream.

You might consider doing an ifdef for not on windows (even in your Ubuntu
patch) so that it's suitable for upstreaming rather than removing the check
entirely.

Afaik, that is fixed on the upstream side by commit:

http://qt.gitorious.org/pyside/pyside/commit/54e97b8e14613348a881f3375b1f0e9b7bbf0df5

As it is already on the upstream repository, I will not backport the patch to Debian (as it will land later on).

On Thu, May 12, 2011 at 10:56 AM, Didier Raboud <email address hidden> wrote:
> Afaik, that is fixed on the upstream side by commit:
>
> http://qt.gitorious.org/pyside/pyside/commit/54e97b8e14613348a881f3375b1f0e9b7bbf0df5

Yeah, I worked with upstream to have that tested and verified that it
works, I'm just building the new deb on ARM to make sure it works
(takes more than 20 hours to build).

> As it is already on the upstream repository, I will not backport the
> patch to Debian (as it will land later on).

Upstream also said that they will be releasing a new version in 2, 3
weeks, so there is no need to backport to Debian nor Oneiric.

SRU Justification:

Impact: Pyside is not available for armel as it's FTBFS.

Fix: The problem is fixed by ignoring the GL_H check (gl.h), as checking for QtOpenGL is already enough to enable the QtOpenGL bindings. The fix is a backport from upstream, and as upstream is releasing a new version in 2, 3 weeks from now, this backport is not needed for debian and Oineric.

Testcase: With the patch pyside should be available for ARM.

phonon-backend-gstreamer from natty-proposed installs, runs and works.

This bug was fixed in the package phonon-backend-gstreamer - 4:4.7.0really4.5.1-1ubuntu2

---------------
phonon-backend-gstreamer (4:4.7.0really4.5.1-1ubuntu2) oneiric; urgency=low

  * On armel: Build-conflict instead of build-depend on OpenGL. (LP: #707794)
 -- Felix Geyer <email address hidden> Fri, 27 May 2011 22:47:44 +0200

This bug was fixed in the package phonon-backend-gstreamer - 4:4.7.0really4.5.0-0ubuntu2.1

---------------
phonon-backend-gstreamer (4:4.7.0really4.5.0-0ubuntu2.1) natty-proposed; urgency=low

  * Add kubuntu_03_optional_opengl.diff from upstream to make use of
    OpenGL optional
  * Don't build-dep on opengl on ARM, LP: #707794
 -- Jonathan Riddell <email address hidden> Mon, 25 Apr 2011 22:32:57 +0100

sofa-framework FTBFS on oneiric:
/usr/include/GLES2/gl2.h:38:26: error: conflicting declaration 'typedef khronos_intptr_t GLintptr'
/usr/include/GL/glew.h:1608:19: error: 'GLintptr' has a previous declaration as 'typedef ptrdiff_t GLintptr'
[...]

Current oneiric pyside package has the patch applied.

I uploaded pyside to natty-proposed queue.

Unsubscribing sponsors again.

Accepted pyside into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

With natty-proposed enabled I'm able to install and use pyside on ARM just fine.

This bug was fixed in the package pyside - 1.0.1-1ubuntu0.1

---------------
pyside (1.0.1-1ubuntu0.1) natty-proposed; urgency=low

  * debian/patches/remove_opengl_detection_restriction.patch:
    - Remove the restriction of detecting QtOpenGL module just when gl.h is
      available at the system (LP: #707794)
 -- Ricardo Salveti de Araujo <email address hidden> Wed, 11 May 2011 08:06:30 +0200

For qwtplot3d it seems like glu is needed, yet that is only available for GL and not GLES. There is a partial glu port to GLES at https://code.google.com/p/glues/ which doesn't seem to be packaged yet.

natty has seen the end of its life and is no longer receiving any updates. Marking the natty task for this ticket as "Won't Fix".