Bug#914671: Removed package(s) from unstable
We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: kdemultimedia-dev | 4:16.08.3-1 | all kdemultimedia-kio-plugins | 4:16.08.3-1 | all --- Reason --- RoQA; NBS -- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 914...@bugs.debian.org. The full log for this bug can be viewed at https://bugs.debian.org/914671 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
clazy_1.4-2_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 27 Nov 2018 07:27:10 +0100 Source: clazy Binary: clazy Architecture: source Version: 1.4-2 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Pino Toscano Description: clazy - Clang plugin for additional warnings Changes: clazy (1.4-2) unstable; urgency=medium . * Backport upstream commit 8ad500134416b960b3c28146e7245b7403f4c851 to properly install the clazy wrapper script as executable; patch upstream_Fix-installation-of-clazy-wrapper-scripts.patch. * Fix the execution of the test suite: - make the clazy wrapper script executable in the build directory, so it can be run - add the top-level build directory to $PATH, so that the clazy script is found * Fix Vcs-Git field to its non-redirecting version. * 'run-tests' autopkgtest: query clang/clang++ for their basic facts (like include/library paths, etc), so it is easier to debug test failures. Checksums-Sha1: 52702af9aa3b10a43c7cce41b83caa998b1e51a1 2312 clazy_1.4-2.dsc 59ddbf1f6942b3c5a54f685215f0b4ed733ddd80 9340 clazy_1.4-2.debian.tar.xz 379df9d3d641f83fe0e9dbcc3eb338e4eaaf8454 10441 clazy_1.4-2_source.buildinfo Checksums-Sha256: f046d2e269d1c12e46afbc2c6202aac8387c8f917c9b3511075d68e949298cbc 2312 clazy_1.4-2.dsc 5eae8a1a944389e3e2e2dc123184d747abccb0ffde094e797ff05e680c844ab6 9340 clazy_1.4-2.debian.tar.xz 4f6f98149583e1bb4a4e921445d9fc71ddbfcdfb16dce7c785fd0bc5f1d2a80c 10441 clazy_1.4-2_source.buildinfo Files: 1703f8c986ea880c81d9d59f2d0d0e30 2312 devel optional clazy_1.4-2.dsc 48f51597bb641a1767fec036665c94fd 9340 devel optional clazy_1.4-2.debian.tar.xz 70b23cbf3e707de0b2652639acd14ba6 10441 devel optional clazy_1.4-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAlv84+kACgkQLRkciEOx P02Hfw/+JTARQuHhMNR2VXI7OR3ESAkSpL/o+X2EbRd5OoxarFDnsIeMGTQovg5h X+aZFt2Gn4cSKgThCtfJ9wljPRQhEkYtua1vT79bADKd80V443TD3Ms/WdZyHXFK kAD+KTQocrRFlRGa0GDGEOqvRBrcS9rUArqPocBTXmKUa1txYDeaW4+lz/upCdQ5 vvMfG/eX2HRdac8EnDe6p4AW1F0oObN0uGyZnnHOcMPM5sCiJSfjynJs9yEdyx28 3RrsMwXokbwLda+UEQhtneJKYuaQX0XHFkoXq7540SCCyDbQFjPNtu8NtfXdd6qt KM2vWwxOwoX38WUauKRVqInq31Xta4TxtO2B8L2WOAB+giXzy4Sm0goS4Bp5IS/j /83tWZVLcBrvvTCW9gTuhUmdLwfLgyXAUtwMtaK8IBbii9jzMWW4iLEySKZtQ3dF d1jqeJo1Nv/FqvF2Vg+iRlolWd+wQ9hcpuLmEFUooIm7D2ukzwQg44MIDCMaoemn nX1MrKIZ2fEAsZPYFtT71BQPozntinhL2JrL9oVUPGtSd2viiFx9nKGbYGJ2FXKI HduJv+NmWh7qRSAWdeVWMTU4zlRMashA2XXMRNMSC7nacCOB8DND3hDpFLdZjFd1 C/jgMlhkWx4zpLv6pyaMmibSnR1hqL0zZ7Tmgkmv40GBi59LoDU= =geEs -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of clazy_1.4-2_source.changes
clazy_1.4-2_source.changes uploaded successfully to localhost along with the files: clazy_1.4-2.dsc clazy_1.4-2.debian.tar.xz clazy_1.4-2_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#914743: (no subject)
KDE upstream bug #396980
Patch: https://phabricator.kde.org/D14554
--
Enneamerdiff -Nru kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch
--- kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch 1969-12-31 19:00:00.0 -0500
+++ kdepim-runtime-16.04.2/debian/patches/fix-array-access-bounds-in-IMAP-resource.patch 2018-11-26 15:48:39.0 -0500
@@ -0,0 +1,41 @@
+Fix array access bounds in IMAP resource
+
+ImapQuotaAttribute::serialized() processes IMAP roots assigning
+corresponding QUOTA and USAGE attributes to each root. It uses three
+dictionaries: mRoots, mLimits, and mUsages assuming that these
+dictionaries always have the same number of elements. In a case when
+mRoots contains more elements than other two dictionaries, this causes
+referencing to non-existent elements in mLimits and mUsages and
+segfaults.
+
+Fix this by using mLimits.size() and mUsages.size() in corresponding
+loops.
+
+BUG: 396980
+Developers: gkowal
+Reviewers: KDE PIM, dvratil
+Reviewed By: KDE PIM, dvratil
+Subscribers: mlaurent, cfeck, kde-pim
+Tags: KDE PIM
+
+Differential Revision: https://phabricator.kde.org/D14554
+--- a/resources/shared/singlefileresource/imapquotaattribute.cpp
b/resources/shared/singlefileresource/imapquotaattribute.cpp
+@@ -91,7 +91,7 @@
+ result += " "; // Members separator
+
+ // Then the limit maps list
+-for (int i = 0; i < mRoots.size(); ++i) {
++for (int i = 0; i < mLimits.size(); ++i) {
+ const QMap limits = mLimits[i];
+ for (auto it = limits.cbegin(), end = limits.cend(); it != end; ++it) {
+ result += it.key();
+@@ -107,7 +107,7 @@
+ result += " "; // Members separator
+
+ // Then the usage maps list
+-for (int i = 0; i < mRoots.size(); ++i) {
++for (int i = 0; i < mUsages.size(); ++i) {
+ const QMap usages = mUsages[i];
+ for (auto it = usages.cbegin(), end = usages.cend(); it != end; ++it) {
+ result += it.key();
diff -Nru kdepim-runtime-16.04.2/debian/patches/series kdepim-runtime-16.04.2/debian/patches/series
--- kdepim-runtime-16.04.2/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ kdepim-runtime-16.04.2/debian/patches/series 2018-11-26 15:47:09.0 -0500
@@ -0,0 +1 @@
+fix-array-access-bounds-in-IMAP-resource.patch
Bug#914745: calligrawords: Second page is empty if margins is set to 0
Package: calligrawords Version: 1:2.9.11+dfsg-4+b1 Severity: normal Dear Maintainer, -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages calligrawords depends on: ii calligra-libs 1:2.9.11+dfsg-4+b1 ii calligrawords-data 1:2.9.11+dfsg-4 ii kde-runtime 4:16.08.3-2 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libkdecore5 4:4.14.26-2 ii libkdeui5 4:4.14.26-2 ii libodfgen-0.1-1 0.1.6-2 ii libqt4-svg 4:4.8.7+dfsg-11 ii libqt4-xml 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii librevenge-0.0-00.0.4-6 ii libstdc++6 6.3.0-18+deb9u1 ii libwpd-0.10-10 0.10.1-5+deb9u1 ii libwpg-0.3-30.3.1-3 ii zlib1g 1:1.2.8.dfsg-5 calligrawords recommends no packages. Versions of packages calligrawords suggests: ii khelpcenter 4:16.08.3-1 -- no debconf information Follow these instructions: 1. open new blank document 2. Go to "page layout", set all margins to 0 3. Copy/paste something to document. Second page is always blank. 4. With margins everything works fine. Stretch Calligra Words version is 2.9.11, maybe newer version should be taken from sid repository?
Bug#914743: kdepim-runtime: akonadi_imap_resource crashes with bus error while syncing the inbox
Package: kdepim-runtime Version: 4:16.04.2-2+b2 Severity: important Dear Maintainer, akonadi_imap_resource crashes with bus error while syncing to my mailbox hosted by a cPanel server. I initially set up the IMAP resource yesterday and synced 2 emails without issue. The third email was sent to me today and may have triggered the issue. The email was fetched successfully though. Application: akonadi_imap_resource (akonadi_imap_resource), signal: Bus error Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f0355e11f80 (LWP 2273))] Thread 1 (Thread 0x7f0355e11f80 (LWP 2273)): [KCrash Handler] #6 std::__atomic_base::load (__m=std::memory_order_relaxed, this=) at /usr/include/c++/6/bits/atomic_base.h:396 #7 QAtomicOps::load (_q_value=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:227 #8 QBasicAtomicInteger::load (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:99 #9 QtPrivate::RefCount::ref (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:55 #10 QMap::QMap (other=..., this=0x7ffef5670560) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:615 #11 Akonadi::ImapQuotaAttribute::serialized (this=0x5634b2953650) at ./resources/shared/singlefileresource/imapquotaattribute.cpp:95 #12 0x7f0368336a62 in attributesToProtocolImpl (ns=, entity=...) at ./src/core/protocolhelper.cpp:110 #13 Akonadi::ProtocolHelper::attributesToProtocol (collection=..., ns=ns@entry=false) at ./src/core/protocolhelper.cpp:205 #14 0x7f036837827f in Akonadi::CollectionModifyJob::doStart (this=0x5634b2941720) at ./src/core/jobs/collectionmodifyjob.cpp:102 #15 0x7f036838b8c0 in Akonadi::JobPrivate::startQueued (this=) at ./src/core/jobs/job.cpp:174 #16 0x7f036834c72e in Akonadi::SessionPrivate::startJob (this=this@entry=0x5634b28953e0, job=job@entry=0x5634b2941720) at ./src/core/session.cpp:204 #17 0x7f036834e5fb in Akonadi::SessionPrivate::doStartNext (this=0x5634b28953e0) at ./src/core/session.cpp:181 #18 0x7f03662ac499 in QObject::event (this=0x5634b2890570, e=) at kernel/qobject.cpp:1263 #19 0x7f0366b62b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #20 0x7f0366b6a341 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #21 0x7f036627f9e0 in QCoreApplication::notifyInternal2 (receiver=0x5634b2890570, event=event@entry=0x5634b297d010) at kernel/qcoreapplication.cpp:988 #22 0x7f036628216d in QCoreApplication::sendEvent (event=0x5634b297d010, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #23 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x5634b282ad10) at kernel/qcoreapplication.cpp:1649 #24 0x7f03662825d8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1503 #25 0x7f03662d3c43 in postEventSourceDispatch (s=0x5634b2865020) at kernel/qeventdispatcher_glib.cpp:276 #26 0x7f03600377f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #27 0x7f0360037a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x7f0360037b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x7f03662d404f in QEventDispatcherGlib::processEvents (this=0x5634b2877b00, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #30 0x7f036627d9ca in QEventLoop::exec (this=this@entry=0x7ffef5670e30, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #31 0x7f036628613c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1261 #32 0x7f036869f91e in Akonadi::ResourceBase::init(Akonadi::ResourceBase*) () from /usr/lib/x86_64-linux-gnu/libKF5AkonadiAgentBase.so.5 #33 0x5634b2093ca5 in Akonadi::ResourceBase::init (argc=, argv=) at /usr/include/KF5/AkonadiAgentBase/resourcebase.h:196 #34 0x7f03656e92e1 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #35 0x5634b2093b1a in _start () -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kdepim-runtime depends on: ii akonadi-server 4:16.04.3-4 ii kdepimlibs-data 4:16.04.2-2 ii kf5-kdepimlibs-kio-plugins 4:16.04.2-2 ii kio 5.28.0-2 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libkf5akonadiagentbase5 4:16.04.3-4 ii libkf5akonadicalendar5 16.04.2-2 ii libkf5akonadicontact5
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió: > Why couldn't you choose QT for Desktop or QT for ES OpenGL when you > compile your program? It's a Qt build-time option. This in an upstream choice, not ours and not up to us to fix. > Supply both libraries? Already answered in the thread. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Why couldn't you choose QT for Desktop or QT for ES OpenGL when you compile your program? Supply both libraries? ES gives an enormous performance boost to little machines that need it, desktop OpenGL is more pretty pictures. On 11/26/18, Lisandro Damián Nicanor Pérez Meyer wrote: > El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió: >> Hello Lisandro, >> >> TLDR: thank you for starting this discussion, it was required as it's not >> an easy decision to take as there is no realistic perfect solution, > > Our (team-wide) pleasure. This is something we have been digging since > 2015. > >> but I >> believe you took the wrong decision. Please consider deferring the >> decision to the technical committe by seeking his advice (point 6.1.3 >> of the constitution >> https://www.debian.org/devel/constitution.en.html#item-6). > > Will "kind of" do. Read below. > > >> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote: >> > It seems now clear that the general consensus seems to expect: >> > = Qt available for both Desktop and ES OpenGL flavours >> > = If no change is possible, keep arm64 with Desktop OpenGL support >> >> I'm not pleased with how this discussion was handled. First of all, >> you did not leave enough time for all stakeholders to participate in >> the discussion (started on November 22th, closed November 25th, 3 days, >> that's not a reasonable timeframe in particular when 2 of the 3 days >> were in the week-end). > > My most sincere apologies if our timeframe do not fit yours. > > Now, wrt the decision: clearly the situation is very complex, involving many > > different kinds of arm64 devices, drivers, libraries et all. People involved > > have different opinions. We so far have been the proxy between them, be it > on > bugs, IRC or whatever other channels our users have to contact us. We prefer > > not to be this proxy anymore (again, read below). > > Besides we (Qt's team) have just learned that the Desktop/ES support is not > > tied to the hardware but to the driver. That's a particularly interesting > point. > > So: > > To quote my original mail, the "Qt available for both Desktop and ES OpenGL > > flavours" point remains unchanged: if someone wants to make it happen [s]he > > must join the team and support it from the inside. Remember there are little > > chances for this to happen in time for Buster. > > For the second point, "If no change is possible, keep arm64 with Desktop > OpenGL support", we have this position: we will keep the status quo, > deferring > users who want GLES support to Ubuntu. > > *But* we are open to change this for any arch (read it: support either one > or > the other technology) as long as the decision is taken by the technical > committee. As I wrote before, we will keep the status quo, so if anyone is > interested in any change feel free to contact the TC. > > Regards, Lisandro. > > -- > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió: > Hello Lisandro, > > TLDR: thank you for starting this discussion, it was required as it's not > an easy decision to take as there is no realistic perfect solution, Our (team-wide) pleasure. This is something we have been digging since 2015. > but I > believe you took the wrong decision. Please consider deferring the > decision to the technical committe by seeking his advice (point 6.1.3 > of the constitution > https://www.debian.org/devel/constitution.en.html#item-6). Will "kind of" do. Read below. > On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote: > > It seems now clear that the general consensus seems to expect: > > = Qt available for both Desktop and ES OpenGL flavours > > = If no change is possible, keep arm64 with Desktop OpenGL support > > I'm not pleased with how this discussion was handled. First of all, > you did not leave enough time for all stakeholders to participate in > the discussion (started on November 22th, closed November 25th, 3 days, > that's not a reasonable timeframe in particular when 2 of the 3 days > were in the week-end). My most sincere apologies if our timeframe do not fit yours. Now, wrt the decision: clearly the situation is very complex, involving many different kinds of arm64 devices, drivers, libraries et all. People involved have different opinions. We so far have been the proxy between them, be it on bugs, IRC or whatever other channels our users have to contact us. We prefer not to be this proxy anymore (again, read below). Besides we (Qt's team) have just learned that the Desktop/ES support is not tied to the hardware but to the driver. That's a particularly interesting point. So: To quote my original mail, the "Qt available for both Desktop and ES OpenGL flavours" point remains unchanged: if someone wants to make it happen [s]he must join the team and support it from the inside. Remember there are little chances for this to happen in time for Buster. For the second point, "If no change is possible, keep arm64 with Desktop OpenGL support", we have this position: we will keep the status quo, deferring users who want GLES support to Ubuntu. *But* we are open to change this for any arch (read it: support either one or the other technology) as long as the decision is taken by the technical committee. As I wrote before, we will keep the status quo, so if anyone is interested in any change feel free to contact the TC. Regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote: > were in the week-end). I was aware of the discussion but did not > had the time to chime in, yet I was the person who re-opened the bug > #881333 in the first place. > I also invited someone else who is working on a concrete project involving > Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available > now but he also did not have the time to contribute to the discussion. > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL > when it has been designed for OpenGL ES only. Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27, featuring Mali-T880. The hardware is not OpenGL ES only .. the propiertary driver is. Mesa-based panfrost driver should support both OpenGL and OpenGL ES: https://gitlab.freedesktop.org/panfrost The open source driver is of course not ready... ...but neither is Debian ES 2.0. In the long run, making the driver ready is time better spent than time spent trying to make Debian more friendly to a class of propiertary drivers. Riku
clazy_1.4-1_amd64.changes ACCEPTED into unstable, unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 04 Nov 2018 22:03:44 +0100 Source: clazy Binary: clazy Architecture: source amd64 Version: 1.4-1 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Scarlett Clark Description: clazy - Clang plugin for additional warnings Closes: 886883 Changes: clazy (1.4-1) unstable; urgency=medium . [ Scarlett Clark ] [ Pino Toscano ] * Initial release (Closes: #886883) Checksums-Sha1: 0a2d2c0f767e264ccb541ab5ab1b74d73306e953 2308 clazy_1.4-1.dsc 8e3c885f48b15e6e0d77287aa4371f7dde4f3994 339104 clazy_1.4.orig.tar.xz 673e9e531d87035d0091153aac891a04312f7af2 376 clazy_1.4.orig.tar.xz.asc 121cd4ca098d0af490a47af99b0b5aab02a5a306 8592 clazy_1.4-1.debian.tar.xz 7d6d356800a7b3670f1604ad0bccac8b049b7c5d 100127448 clazy-dbgsym_1.4-1_amd64.deb eea366a5ea90f1b37bcbda4a85fd7b6f428a472d 11605 clazy_1.4-1_amd64.buildinfo f96cb8a01fc61f6de5c9ecf2bea71288d97ad858 5874316 clazy_1.4-1_amd64.deb Checksums-Sha256: baa8ad687ea31a7fc57dfe722150420a69ba2fe3b9b609248466cd496d7154fd 2308 clazy_1.4-1.dsc 3f5d5e148c9e9c4e43f095796261794da5385578d2375b12c9179d340d6d5a8a 339104 clazy_1.4.orig.tar.xz 9ef50f38fc43604d490f89369bf57fa97022c9aa742676e6e3fc675de4424948 376 clazy_1.4.orig.tar.xz.asc 74be4d8b067392dd6fae2c747e26213c51cb0e7f3acf0eedcf2a07bd3b9241c0 8592 clazy_1.4-1.debian.tar.xz 5a547eaf6e872b9371a414ffd88db8ba6d379a83f5c9734e88ae5288b1d8e95c 100127448 clazy-dbgsym_1.4-1_amd64.deb d5b7007bd1084d752c42344308bdd5f7333556496a4a99fb0748aab1418f 11605 clazy_1.4-1_amd64.buildinfo ef2542920717ed698c20ad4c0279ea9858817b3bdacbe8e1c64b62197dbe26a9 5874316 clazy_1.4-1_amd64.deb Files: 9b51d93cab0ddbf9e6a53d9a05c547ed 2308 devel optional clazy_1.4-1.dsc e78ee0ac50edfce79de449458072eb87 339104 devel optional clazy_1.4.orig.tar.xz 67d03c85ee3c7c94dee31301842736e6 376 devel optional clazy_1.4.orig.tar.xz.asc 6093c541287856a0e413e597fd86f66b 8592 devel optional clazy_1.4-1.debian.tar.xz 5c06e1f6d172b4ec239059fb5e9fa305 100127448 debug optional clazy-dbgsym_1.4-1_amd64.deb 6cfe89d864a76e50328532d39e7d 11605 devel optional clazy_1.4-1_amd64.buildinfo 4fa12c37ff3b7c264ec14bc974469ded 5874316 devel optional clazy_1.4-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAlvfZMwACgkQLRkciEOx P02ZnRAAnHDDC+P++E6e5VYtV27BKyzkEF3WrwFYmFI936dP9a59gAUSZPBx9gA0 TX7ISBGZQ8XA/LR2YaNqh/C9WAvz/DZ0IgR4niQya28a3lT6IO2UEFRcfdRbL30Y A3IOYI+vj1DmP9TkdUxP56UpC3JoLl3NpAz5mT0z46EOSBVMmVad/HRkUv2yz2K8 M0ul0SAqJjxlLAwy7Jhf/3eCufh0rc5tSCq6e12FRVctvpfh569LSoYVhB5vcpIe vwc8uzqGNCRpb4VY65/geOHKQ6eDIXBcJGlpWvIpk8A8di33PGWnSNxyMhExQ9Re P5on+hc1DCq0ibncIAb3n7beASxyQxCY7OSXuN0eBY7H53dlt3MWmucpdaM6hc9P /Oeoujt8YsBHI9FVXiw0+TRJCpAP/Ce3UflGrLvb6koEoSreJbxZ/oBZWCLuFeiy iY+b3ExUBpu4W694ZthKEcAguPrXAtgoGhYTVkjNVam/wJnKM19HW5NF9xZy63u4 todWQtV/7A5wNdSdv/jIcZkXP8tiJGcj6K5fFCkQlhH3uKWLtsHv+Dat8u9OQWh7 IyNYcOtKkrmErr9FwhBYWxZO7NjbF1bRG4RfHZwaUQ6KSgHgsF/CY9XeMXCAh2wK xROkMB2dIghV5GdF2jede0P99HoB8WkVAqw0iCzKJrAci8bB7lM= =Q+pd -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Quoting Raphael Hertzog (2018-11-26 12:37:57) > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL when > it has been designed for OpenGL ES only. Is some _hardware_ really "designed for OpenGL ES only"? I guess you mean that some hardware is only supported by non-free firmware/software hardcoded which is designed for OpenGL ES only". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hello Lisandro, TLDR: thank you for starting this discussion, it was required as it's not an easy decision to take as there is no realistic perfect solution, but I believe you took the wrong decision. Please consider deferring the decision to the technical committe by seeking his advice (point 6.1.3 of the constitution https://www.debian.org/devel/constitution.en.html#item-6). On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote: > It seems now clear that the general consensus seems to expect: > = Qt available for both Desktop and ES OpenGL flavours > = If no change is possible, keep arm64 with Desktop OpenGL support I'm not pleased with how this discussion was handled. First of all, you did not leave enough time for all stakeholders to participate in the discussion (started on November 22th, closed November 25th, 3 days, that's not a reasonable timeframe in particular when 2 of the 3 days were in the week-end). I was aware of the discussion but did not had the time to chime in, yet I was the person who re-opened the bug #881333 in the first place. I also invited someone else who is working on a concrete project involving Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available now but he also did not have the time to contribute to the discussion. Then I have read the whole discussion and I don't have the feeling that any consensus has been reached. It was largely driven by Andy Simpkins who explained his "gut feeling" as a tinkerer of arm* boards/devices and Bret Curtis who contributes to some applications with very specific OpenGL needs. While I value their contribution to the discussion, they both represent very specific classes of users. What I remember from this discussion is that the Windows build of Qt use GLES 2 by default. It would have been interesting to find out the rationale for this... because maybe the right decision for us would be to switch to GLES 2 by default as well (on all architectures as jcristau suggested). Someone else who likely also tried to ensure Qt for Windows is usable on most hardware made that choice. We got confirmation from many persons that almost all cards benefitting from Desktop OpenGL would also work with OpenGL ES. So in terms of hardware support, picking OpenGL ES is the right choice. In terms of sofware support, it looks like that Desktop OpenGL is better as there are a few applications that only work with Desktop OpenGL. Software can be fixed/improved to also work with OpenGL ES. However hardware, once bought, cannot be fixed to support Desktop OpenGL when it has been designed for OpenGL ES only. When taking all this into account, I believe that the right solution is to use OpenGL ES on all architectures. This will provide the required incentives for application developers who stick only to Desktop OpenGL to support OpenGL ES (even it it's at the cost of using some intermediary layer like https://github.com/p3/regal) and would maximize hardware support on all architectures. That said, I'm fine with a decision to change only arm64 since that's an architecture were devices that support only OpenGL ES are in the majority. This is not a easy decision to make but we have a dedicated body to help maintainers find the best technical decision when there are pros/cons in both solutions, it's called the technical committee. Please consider seeking their advice before taking your decision. > Both Dmitry and I just learned that the RPI has the VC4 driver which enables > it to do hardware acceleration for Desktop OpenGL, we must admit that this is > a game changer in many ways, even if we are talking on just one board (but > quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use > Ubuntu. I don't see why this affects the decision in any way. AFAIK the VC4 driver also enables hardware acceleration for OpenGL ES. And this is only relevant for the RPI3 which is the only arm64 hardware. Bret Curtis clearly explained that we do get good performances on older RPI (armhf-based) precisely because of the VC4 driver being able to leverage OpenGL ES too. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
