Re: Bug#1068078: FTBFS on armel: shiboken2:smart::smart_pointer Newly detected Real test failure!
Hi, (CCing debian-arm@l.d.o. Please CC me back as I’m not subscribed.) On Sat, Mar 30, 2024 at 02:11:32PM +0500, Andrey Rakhmatullin wrote: > Source: pyside2 > Version: 5.15.12-6.1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=pyside2&arch=armel&ver=5.15.12-6.1&stamp=1711789575&raw=0 > > RUN 2: Test project /<>/pyside3_build/py3.11-qt5.15.10-32bit- > relwithdebinfo/shiboken2 > RUN 2: Start 181: smart_smart_pointer > RUN 2: 1/1 Test #181: smart_smart_pointer ..***Failed0.23 sec > RUN 2: Running garbage collector for reference test > RUN 2: FFF > RUN 2: == > RUN 2: FAIL: testObjSmartPointer > (__main__.SmartPointerTests.testObjSmartPointer) > RUN 2: -- > RUN 2: Traceback (most recent call last): > RUN 2: File > "/<>/sources/shiboken2/tests/smartbinding/smart_pointer_test.py", > line 94, in testObjSmartPointer > RUN 2: self.assertEqual(integerCount(), 1) > RUN 2: AssertionError: 2 != 1 > [...] I tried to build pyside2 on two porterboxes, amdahl.d.o and abel.d.o, and on both it built successfully (in sid_armel-dchroot). I also ran the test manually several times after build, and it was successful too: (sid_armel-dchroot)mitya57@abel:~/pyside2-5.15.12/pyside3_build/py3.11-qt5.15.10-32bit-relwithdebinfo/shiboken2$ ctest --tests-regex '^(smart_smart_pointer)$' Test project /home/mitya57/pyside2-5.15.12/pyside3_build/py3.11-qt5.15.10-32bit-relwithdebinfo/shiboken2 Start 181: smart_smart_pointer 1/1 Test #181: smart_smart_pointer .. Passed0.48 sec 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 0.53 sec Does anyone have ideas why there may be such difference between the buildds (arm-conova-01, arm-arm-03) and the porter boxes? It’s worth noting that the armhf build ran on the same arm-conova-01, and it was successful. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Wed, Nov 28, 2018 at 12:32:51PM -0800, Steve Langasek wrote: > I would caution against prematurely optimizing for build-time. Yes, > building the entire source package twice is a waste of resources, but it's > probably a drop in the bucket. My mail concert was not build-time, but our (maintainers’) time. For any changes in normal packages (e.g. packaging new upstream releases), we will need to carefully merge these changes into the -gles packages and remove the bits that are not needed there. > The reason not to build the two stacks from a single source package is that > the gl vs gles libraries are by design drop-in replacements for one another > - i.e.: they must have the same soname in order for the symbols magic to > work, which means they end up conflicting on the system. You *could* design > a system that allows them to be coinstallable via subdirectories and > manually-managed symlinks, but I doubt this is actually worth it in practice > for the number of packages affected. Ah, I understand now — you mean that to build both variants of e.g. Qt 3D, we will need to build-depend on both libqt5gui5 and libqt5gui5-gles, which are not co-installable. That is a valid reason for having two separate source packages. However maybe it will be possible to build at least two variants of qtbase from the same source, as that’s one ofthe most complicated Qt packages. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote: > $ grep-dctrl -n -sSource:Package -FDepends \ > -e > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>= > 5\.[0-9.]*\))(?|$),' \ > > /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages > | sort -u > maliit-plugins > ovito > pyqt5 > qml-box2d > qt3d-opensource-src > qtbase-opensource-src > qtdeclarative-opensource-src > qtubuntu-cameraplugin-fake > stellarium > wallch > $ > > Every single other binary package that depends on libqt5gui5 (etc) in Ubuntu > 16.04 has an ORed dependency on libqt5gui5 | libqt5gui5-gles. Ah, this is interesting. The amount of packages will probably be larger in the current sid, but it should not be more than 20 packages. Plus there are packages which are using QT_OPENGL_ES macro for conditional compilation (as I mentioned in my previous mail), but there are also not many of them: gammaray goldendict gst-plugins-good1.0 kamoso krita leocad openclonk phonon-backend-gstreamer qtav qt-gstreamer qtwebkit-opensource-src qtwayland-opensource-src qtcharts-opensource-src > So perhaps someone in this thread is willing to put in this effort to > maintain 6 source packages, in order to avoid having to make a choice > between GL and GLES on arm64. I wonder if these can be new binaries in existing source packages, instead of separate source packages. Otherwise we will have too much code duplication, and also wasted time: for example, in qtbase-opensource-src, only src/gui needs to be built twice, and there is no need to built other submodules twice. We already have an example of double build inside the same source: on i386, src/corelib is built twice, with and without sse2 support. In any case, this task looks manageable. Maybe if I have time someday I will take care of it, but in the meantime volunteers are welcome. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
Hi Steve and all, On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote: > It is actually fairly easy to answer this question as well: simply identify > all the packages in the archive that depend on one of the known dual-stack > libraries, prepare dual stack packages that use the symbols file magic from > Ubuntu, rebuild all the reverse-dependencies, and identify all those > packages which are libraries and which end up with a dependency only on the > GL version of the package instead of a dependency on GL | GLES. > > A fair amount of compile time required to do this analysis, but relatively > little human time. Let me explain what the mentioned “symbols file magic” is: debian/libqt5gui5.symbols header has these lines: libQt5Gui.so.5 libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER# | libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER#, qtbase-abi-5-7-1 | libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER# So symbols that exist in both desktop OpenGL and GL ES builds get a dependency on libqt5gui5 | libqt5gui5-gles, and maybe on a -abi- virtual package if they are private. And symbols that exist in only one of flavours are getting the dependency only on the particular binary package name, e.g.: (optional)_ZN25QOpenGLFunctions_3_2_Core14versionProfileEv@Qt_5 5.2.0 2 → gets a dependency on libqt5gui5 only (optional|arch=!armhf !arm64 !armel)_ZN20QOpenGLFunctions_ES214versionProfileEv@Qt_5 5.2.0 3 → gets a dependency on libqt5gui5-gles only Most of these symbols are for QOpenGLFunctions* classes. I will try to get an estimate of how many package are using them a bit later. Also there are packages that build different things depending on OpenGL variant, by using qtConfig(opengles2) in their .pro files or by checking QT_OPENGL_ES macro in their C++ files. These will probably also need dual stack packages. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hi Rohan! On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote: > [...] > > I concur here. It was correctly pointed out in another reply that by using > OpenGL we're specifically catering to software that doesn't support > GLES while making performance worse for mature applications that > do implement both OpenGL and GLES. The reality of the situation is that > the market currently favors GLES over GL on ARM SBC's, delivered with > proprietary blobs. I think a more pragmatic view of this reality would be to > deliver the best FOSS user experience that's possible with the proprietary > drivers while the open source drivers are being improved. To that extent, > by switching to GLES we improve the overall situation since OpenGL > applications can fall back to software rendering via mesa on platforms > where mesa does not support the GPU. Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. I think we should aim to provide the best possible experience with the free software ecosystem. The experience with proprietary drivers should be the second priority, if priority at all. > By choosing to build Qt with GLES on ARM64, we make Debian a more > attractive platform for vendors who'd like to target ARM64 boards. We should make it attractive for vendors to release their code under a free software (DFSG) license. That way anyone would be able to hack on it and add missing support for a different OpenGL variant, if needed. That said, as Lisandro announced, we will be happy to make any decision if there is either a consensus or a TC decision about it. [1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote: > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze: > > I would still like to know if the upcoming arm64 desktop devices have > > any problems working with OpenGL ES. > > Arm64 desktop systems use Radeon or NVidia cards with same opensource > drivers as x86-64 systems. So you can check how it goes with OpenGL ES > on your amd64 desktop. I have an embedded Intel card right now :) What is the status of OpenGL ES support with these drivers? -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote: > > According to config_help.txt [1], Qt uses ES2 by default on Windows. > > It probably means that it will work fine with most desktop video cards. > > > > But as Lisandro says, such a change in Debian will break many packages > > (which are currently broken on ARM only), so we are definitely not > > considering it at this point. > > Why is it OK to break them on arm64 if it's not OK to break them on > amd64? Do you have a list of those packages? The majority of arm64 devices are mobile/embedded, which cannot be said about amd64. Of course it is bad to break packages, but leaving arm64 users with non-working Qt graphics is also not ideal. So we are trying to find a compromise solution here. We do not have a final list yet, but packages that may get broken will likely belong to one of these two groups: - Packages that build-depend on both qtbase5-dev and libglu1-mesa-dev: cgal, flightgear, fraqtive, kalgebra, kstars, ksudoku, kubrick, paraview, simplescreenrecorder, starpu, starpu-contrib, structure-synth, vtk6, vtk7 - Packages that build-depend on libqt5opengl5-desktop-dev: bino, deepin-movie-reborn, enki-aseba, fracplanet, fraqtive, freecad, krita, libconfig-model-dpkg-perl, mldemos, mm3d, openms, qwtplot3d, shelxle, soundscaperenderer, tetzle, virtualjaguar, vite, vtk7 This is not a final list yet, but should be enough to get an estimate. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote: > I do understand that there would be a lot of effort required to support OGL > and OGLES but as you have already pointed out "you are doing this already" > because OGL is provided for all platforms except armel & armhf which have > OGLES - that means you are already tracking changes for *BOTH* ecosystems. > > Having OGL & OGLES available on the same architecture would be setup > involved in creating two package streams, but once done the actual build > process is automated. Yes there are now twice as many resulting sets of > binaries for this layer, but it is reasonable to assume that functional > test of each strand can be split across the testing for all architectures > (where not automated), so the increased workload again shouldn't differ by > much (just the supporting of the automation). > > I am sure my view is nieve and a little too simplistic... Please keep in mind that not only we (the Qt maintainers) should maintain two sets of packages, but also maintainers of third party Qt libraries and applications. Even in Ubuntu where the core developers can upload any package, this setup did not work fine (they tried to maintain twin -gles packages for x86 for the Ubuntu touch port to these architectures). > As of today there are considerably more 'mobile' arm devices. I suspect > that this will continue because they are lower cost mass market products. > Full 'desktop' on arm64 has felt very close for the last few years, but > hardware isn't there just yet. > There are some quite big server SoCs out there, but the desktop & laptop > world isn't well serviced. > > [...] > > If you want to look at sheer numbers then OGLES will 'win' hands down, but > my gut tells me that long term excluding OGL from the arm64 architecture > would be the wrong decision Thanks, this information is useful! I would still like to know if the upcoming arm64 desktop devices have any problems working with OpenGL ES. Anyway, the decision we are making now is not permanent, we can always revisit it in a few years like we are now revisiting the decision to stick with desktop OpenGL. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote: > I think a better question would be: Does it improve, or disable, decent > video support for the dozens of arm64 cards in the r-pi format, such as > the arm64 based $44 rock64? [...] As far as I know Raspberry Pi 3 and similar devices work fine with OpenGL ES. E.g. Raspbian does not override our choice to build qtbase with OpenGL ES on armhf. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote: > At least mesa drivers can be used for desktop GL or GLESv2 just fine, > AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all > architectures, to stop the special-casing madness, instead of making it > spread? :) According to config_help.txt [1], Qt uses ES2 by default on Windows. It probably means that it will work fine with most desktop video cards. But as Lisandro says, such a change in Debian will break many packages (which are currently broken on ARM only), so we are definitely not considering it at this point. [1]: https://code.qt.io/cgit/qt/qtbase.git/tree/config_help.txt#n271 -- Dmitry Shachnev signature.asc Description: PGP signature
Upcoming Qt switch to OpenGL ES on arm64
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.
We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.
So far we are going to make this change starting with the Qt 5.11.3 packages.
In case you already want to test it, the updated qtbase package is available
in experimental [2]. However the reverse dependencies are not yet rebuilt.
This change will affect packages using Qt Gui [3], Qt Widgets [4], Qt Quick
and some other modules. It will not affect packages using the deprecated Qt
OpenGL module because it loads the OpenGL library at runtime.
The best way to check whether some package needs changes is checking Ubuntu
[5], which has been building Qt with OpenGL ES on arm64 since version 16.10
(yakkety) [6].
We will send a new mail with DD-list of packages that we detect to be affected
a bit later.
There are some packages that are not compatible with OpenGL ES. For example,
packages using libglu and Qt simultaneously will most likely have to drop
their arm64 binaries (like they already have no armel or arm64 binaries).
An example of such package is qwtplot3d.
Also note that as this change breaks ABI on arm64, we are renaming libqt5gui5
to libqt5gui5a, which will need binNMUs of all reverse dependencies. The list
of all such dependencies is available here [7]. This will happen together with
the Qt 5.11.3 transition.
Please Cc me or pkg-kde-talk on reply.
[1]: https://bugs.debian.org/881333
[2]: https://tracker.debian.org/news/1004843/
[3]: https://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration
[4]: https://doc.qt.io/qt-5/qopenglwidget.html
[5]: https://launchpad.net/ubuntu/+source/${SOURCE_PACKAGE_NAME},
or the “ubuntu patches” link in the right panel of tracker.debian.org
[6]: https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/197063f08928ac9c
[7]: https://perezmeyer.com.ar/ben/qtbase.html
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Re: qtxmlpatterns builds fail on arm64 buildds but not on porter boxes
Hi, On Sun, 18 Jan 2015 12:55:43 +, Steve McIntyre wrote: >>If someone provides me with a stack trace from the buildd, then I will >>investigate it. > > That's not very easy - the build logs are normally all we have, I'm > afraid. I don't mean the already finished builds, is it possible to start a new one and check it? >>[1]: tst_QXmlSchema::loadSchemaDataFail() in tst_qxmlschema.cpp > > Is this going to be trying to access things on the network during > build? If so, that's not going to work on most buildds. No, it does not need network (or at least builds fine on other buildds). -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: qtxmlpatterns builds fail on arm64 buildds but not on porter boxes
Hi Steve, On Sun, 18 Jan 2015 12:29:53 +, Steve McIntyre wrote: > Is there anything special about how this is done in terms of timing > etc.? The buildds are set up to use tmpfs for builds, which can throw > things that make assumptions about filesystem behaviour. I have just checked the build log, and it seems that the failing test is the test that tries to load not from file, but from an empty URL [1]. Maybe this is the issue. If someone provides me with a stack trace from the buildd, then I will investigate it. [1]: tst_QXmlSchema::loadSchemaDataFail() in tst_qxmlschema.cpp -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
qtxmlpatterns builds fail on arm64 buildds but not on porter boxes
Dear arm64 buildd admins, For some reason my package qtxmlpatterns-opensource-src started failing to build on arm64 buildds (arm-linaro-01, arm-linaro-03 and arm-arm-01) in experimental [1]. It fails in a test that involves some IO actions (such as reading from a file). However, I can successfully build the package on turfan.debian.net and asachi.debian.org. Also, the same package version successfully built on one of Canonical's builders (beebe). Do you know what can cause this? [1]: https://buildd.debian.org/status/logs.php?pkg=qtxmlpatterns-opensource-src&arch=arm64 -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Help needed with qtcreator FTBFS on arm*
On Sat, Jun 21, 2014 at 6:15 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > I've tried to build it twice on an armhf porterbox and Dmitry Schanev tried on > an armel qemu VM. In my case the porterbox would simply hang before reaching > where the buildd gets, and I think the VM build also failed earlier. FWIW my armhf build segfaulted, but armel build succeeded: http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armhf.build http://95.85.27.130/builds/qtcreator_3.1.1+dfsg-1_armel.build Both were done in qemu. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKimPHUsAAsRH5Tyb=ql+p2+met1dbr+gltbvqqczafxrac...@mail.gmail.com
