Remove arm64 binaries for packages failing to build with Qt compiled with OpenGL ES

[Timo Jyrinki]

Summary of requested archive operations:

On yakkety, remove arm64 binaries from the following source packages that would now fail the arm64 build if rebuilt:

bino goldencheetah openscad ovito sdrangelove tulip vite

Since Qt is now using OpenGL ES on arm64, Qt 5 applications directly using OpenGL features not available in the ES subset may have build failures since OpenGL ES headers are now used instead. Such applications didn't build on armhf either which has used OpenGL ES from the beginning. Similar to armhf, all or most arm64 hardware graphics (like Adreno, Mali) have only ES support.

--- below is background regarding how the package list was created

Qt build for arm64 recently switched to using OpenGL ES in yakkety, similar to armhf.

I've output of packages building against Qt 5 (qtbase5-dev, qt5-qmake, qtdeclarative5-dev or qt5-default), and a list of packages failing to build on armhf - formerly from from http://qa.ubuntuwire.org/ftbfs/ and then again via launchpadlib.

Combining those results in this list:
itksnap
klog
libqglviewer
mudlet
sdrangelove
sleepyhead
thumbnailer
tulip

Of which I already knew tulip was affected. klog and thumbnailer seem false positive, making the following candidates of removing arm64 binaries of:

itksnap
libqglviewer
mudlet
sdrangelove
sleepyhead
tulip

To get absolutely everything, I got a list of all binaries depending on libqt5core5a, got the source package for them and cross-checked. This got me the list of the six above plus the following three:

bino
qwtplot3d
vite

However, rebuilding all of the nine resulted in discovery that not all that failed on armhf fail on arm64: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-035/+packages

The failures for 5 armhf packages seem to be not related to the choice of Qt's OpenGL configuration options, so the arm64 builds succeeded (in case of itksnap, would have succeeded if not for other FTBFS problem).

--
Same but for depwait and not ftbfs (list gotten via launchpadlib), cross-checking against source packages having binaries depending on libqt5core5a package:

goldencheetah # noticed manually first, but also gotten from this filtering
openscad
ovito
qtconnectivity-opensource-src
yade

Of these goldencheetah openscad ovito failed arm64 rebuild.

[Matthias Klose (doko)]

so this is happening without any discussion?

[Gianfranco Costamagna (costamagnagianfranco)]

Calibre was FTBFS (on arm64) due to this particular issue

I had to rebuild pyqt5 to fix it
  File "/«BUILDDIR»/calibre-2.55.0+dfsg/src/calibre/gui2/__init__.py", line 8, in <module>
    from PyQt5.QtWidgets import QStyle # Gives a nicer error message than import from Qt
ImportError: /usr/lib/python2.7/dist-packages/PyQt5/QtGui.aarch64-linux-gnu.so: undefined symbol: _ZTI18QOpenGLTimeMonitor

[Timo Jyrinki (timo-jyrinki)]

This was discussed first in an e-mail thread including some Foundations team members. John McAleely suggested doing the switch, and at that point there was agreement that we can get this done yakkety. Then there was rightly your mailing list thread https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039380.html where it was discussed further.

As all OpenGL GPUs run nowadays OpenGL ES apps, but not the other way around, this is quite acceptable trade-off until the apps mentioned here have hopefully switched to be OpenGL ES compatible. OpenGL ES is largely a cleaner version of OpenGL with also the modern features of latest OpenGL 4.5.

[Steve Langasek (vorlon)]

Removing packages from zesty:
 bino 1.6.3-1build1 in zesty arm64
Comment: ANAIS
1 package successfully removed.

[Steve Langasek (vorlon)]

Removing packages from zesty:
 ovito 2.3.3+dfsg1-2build2 in zesty arm64
Comment: ANAIS
1 package successfully removed.

[Steve Langasek (vorlon)]

Removing packages from zesty:
 vite 1.2+svn1430-5 in zesty arm64
Comment: ANAIS
1 package successfully removed.