Bug#735488: Qt4 in arm64: wrap up of the current situation
First of all, sorry for the long delay, I'm trying to catch up with my backlog :-/ On Wednesday 19 March 2014 15:59:01 Mark Salter wrote: On Tue, 2014-03-18 at 14:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Mark: as per [0] Thiago (upstream for qtcore) says: +#ifndef Q_DATA_MEMORY_BARRIER +# define Q_DATA_MEMORY_BARRIER asm volatile(dmb sy\n:::memory) +#endif +#ifndef Q_COMPILER_MEMORY_BARRIER +# define Q_COMPILER_MEMORY_BARRIER asm volatile(:::memory) This shouldn't be necessary anymore if we're using the compilr intrinsics with the right __ATOMIC_xxx macros. The compiler will inser the proper barriers. Would it be possible to fix it? I agree that the explicit barriers are not needed. I could spin another patch with them removed, but that still leaves -fpermissive. Please do spin the patch and I'll push it. [snip] I'm not very fluent with c++ and have no idea what needs to be done with this. I think that's stuff for porters then (wookey?) -- You know it's love when you memorize her IP number to skip DNS overhead. Anonymous 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#735488: Qt4 in arm64: wrap up of the current situation
On Tue, 2014-03-18 at 14:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Mark: as per [0] Thiago (upstream for qtcore) says: +#ifndef Q_DATA_MEMORY_BARRIER +# define Q_DATA_MEMORY_BARRIER asm volatile(dmb sy\n:::memory) +#endif +#ifndef Q_COMPILER_MEMORY_BARRIER +# define Q_COMPILER_MEMORY_BARRIER asm volatile(:::memory) This shouldn't be necessary anymore if we're using the compilr intrinsics with the right __ATOMIC_xxx macros. The compiler will inser the proper barriers. Would it be possible to fix it? I agree that the explicit barriers are not needed. I could spin another patch with them removed, but that still leaves -fpermissive. [0] https://codereview.qt-project.org/#patch,all_unified,81011,3 For everyone but specially Wookey who wants the patchs in Debian, quoting upstream WRT -fpermissive: That error needs to be fixed in the right place. Adding -fpermissive to make the error disappear without fixing the problem is not the right solution. So as I said before, this needs to get fixed before merging the patches. As a wrap-up of the push-to-upstream actions, the mostly objected part if the -fpermissive flag. I'm not very fluent with c++ and have no idea what needs to be done with this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
Mark: as per [0] Thiago (upstream for qtcore) says: +#ifndef Q_DATA_MEMORY_BARRIER +# define Q_DATA_MEMORY_BARRIER asm volatile(dmb sy\n:::memory) +#endif +#ifndef Q_COMPILER_MEMORY_BARRIER +# define Q_COMPILER_MEMORY_BARRIER asm volatile(:::memory) This shouldn't be necessary anymore if we're using the compilr intrinsics with the right __ATOMIC_xxx macros. The compiler will inser the proper barriers. Would it be possible to fix it? [0] https://codereview.qt-project.org/#patch,all_unified,81011,3 For everyone but specially Wookey who wants the patchs in Debian, quoting upstream WRT -fpermissive: That error needs to be fixed in the right place. Adding -fpermissive to make the error disappear without fixing the problem is not the right solution. So as I said before, this needs to get fixed before merging the patches. As a wrap-up of the push-to-upstream actions, the mostly objected part if the -fpermissive flag. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
Hi Marcin, I had a quick look at patches you attached. Thanks a lot for submitting them in such structured form. My questions are: - Are 1-basic-aarch64-detection.patch, 2-mkspecs.patch and 4-syscalls.patch authored by you? - Did you forget to attach 3-something patch? Or is that just a naming issue? - 5-qatomic patch has this line on top: include/QtCore/headers.pri usunięte - trzeba przywrócić Can I ignore that? The qtscript.patch is already committed to qtscript git [1], so we should probably submit a cherry-pick upstream (anyone could do that) and make it included in the next snapshot. For some reason Qt Gerrit refuses to accept my changes, so I would welcome if someone else does that. [1]: https://qt.gitorious.org/qt/qtscript/commit/2e049836ee16f4aedbe7ccc3335fc57852725716 -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#735488: Qt4 in arm64: wrap up of the current situation
Thanks for the quick reply. [Adding back the needed CCs addresses.] W dniu 28.02.2014 15:19, Dmitry Shachnev pisze: I had a quick look at patches you attached. Thanks a lot for submitting them in such structured form. My questions are: - Are 1-basic-aarch64-detection.patch, 2-mkspecs.patch and 4-syscalls.patch authored by you? Author: Marcin Juszkiewicz mar...@juszkiewicz.com.pl based on gtkwebkit changes by Riku Voipio riku.voi...@linaro.org Sorry for nitpicking, but these patches are not related to WebKit and only touch files in QtCore. So I assume you are the only author. - Did you forget to attach 3-something patch? Or is that just a naming issue? It got dropped. OK. - 5-qatomic patch has this line on top: include/QtCore/headers.pri usuniФte - trzeba przywrУГciФ Can I ignore that? It means include/QtCore/headers.pri changes are dropped - need to be restored. This is to get qatomics_aarch64.h file included in qt-devel. So I am ignoring it, thanks. The qtscript.patch is already committed to qtscript git [1], so we should probably submit a cherry-pick upstream (anyone could do that) and make it included in the next snapshot. For some reason Qt Gerrit refuses to accept my changes, so I would welcome if someone else does that. And all included patches are BSD licensed. I know, thanks. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#735488: Qt4 in arm64: wrap up of the current situation
W dniu 29.01.2014 02:27, Lisandro Damián Nicanor Pérez Meyer pisze:
Mark: please take a look at [0] for more context or ask Marcin. Quick
context:
getting AArch64 (aka arm64) Qt4 patches in upstream.
Marcin, Mark: to get the code into the Qt4 tree I either need you to:
a) push the code to Qt's gerrit instance
or
b) license the patches as BSD or something equally permissive
The (a) case would be the simpler one for us (Qt / all other distros) but you
might not be able to do so. So we can still the go the (b) way.
I split whole aarch64.patch into more managable parts.
---
configure |6 ++
1 file changed, 6 insertions(+)
--- qt.orig/configure
+++ qt/configure
@@ -3246,6 +3246,12 @@ if [ -z ${CFG_HOST_ARCH} ]; then
echo ARM (arm)
fi
CFG_HOST_ARCH=arm
+ ;;
+*:*:aarch64*)
+if [ $OPT_VERBOSE = yes ]; then
+echo AArch64 (aarch64)
+fi
+CFG_HOST_ARCH=aarch64
;;
Linux:*:sparc*)
if [ $OPT_VERBOSE = yes ]; then
---
configure |3 ++
mkspecs/linux-g++-aarch64/qmake.conf | 28
mkspecs/linux-g++-aarch64/qplatformdefs.h | 42 ++
3 files changed, 73 insertions(+)
--- qt.orig/configure
+++ qt/configure
@@ -2808,6 +2808,9 @@ if [ $CFG_EMBEDDED != no ]; then
*86_64)
PLATFORM=qws/linux-x86_64-g++
;;
+aarch64)
+PLATFORM=linux-g++-aarch64
+;;
*)
PLATFORM=qws/linux-generic-g++
;;
--- /dev/null
+++ qt/mkspecs/linux-g++-aarch64/qplatformdefs.h
@@ -0,0 +1,42 @@
+/
+**
+** Copyright (C) 2012 Digia Plc and/or its subsidiary(-ies).
+** Contact: http://www.qt-project.org/legal
+**
+** This file is part of the qmake spec of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** Commercial License Usage
+** Licensees holding valid commercial Qt licenses may use this file in
+** accordance with the commercial license agreement provided with the
+** Software or, alternatively, in accordance with the terms contained in
+** a written agreement between you and Digia. For licensing terms and
+** conditions see http://qt.digia.com/licensing. For further information
+** use the contact form at http://qt.digia.com/contact-us.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Digia gives you certain additional
+** rights. These rights are described in the Digia Qt LGPL Exception
+** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+**
+** $QT_END_LICENSE$
+**
+/
+
+#include ../linux-g++/qplatformdefs.h
--- /dev/null
+++ qt/mkspecs/linux-g++-aarch64/qmake.conf
@@ -0,0 +1,28 @@
+#
+# qmake configuration for linux-g++
+#
+# Written for GNU/Linux platforms that have both lib and lib64 directories,
+# like the AMD Opteron.
+#
+
+MAKEFILE_GENERATOR = UNIX
+TARGET_PLATFORM = unix
+TEMPLATE = app
+CONFIG += qt warn_on release incremental link_prl gdb_dwarf_index
+QT += core gui
+QMAKE_INCREMENTAL_STYLE = sublib
+
+QMAKE_CFLAGS = -fpermissive
+QMAKE_LFLAGS =
+
+QMAKE_CFLAGS_RELEASE += -O2
+
+include(../common/linux.conf)
+include(../common/gcc-base-unix.conf)
+include(../common/g++-unix.conf)
+
+
+QMAKE_LIBDIR_X11 = /usr/X11R6/lib64
+QMAKE_LIBDIR_OPENGL = /usr/X11R6/lib64
+
+load(qt_config)
---
src/corelib/io/qfilesystemwatcher_inotify.cpp |9 +
1 file changed, 9 insertions(+)
--- qt.orig/src/corelib/io/qfilesystemwatcher_inotify.cpp
+++ qt/src/corelib/io/qfilesystemwatcher_inotify.cpp
@@ -138,6 +138,11 @@
# define __NR_inotify_add_watch 285
# define __NR_inotify_rm_watch 286
# define __NR_inotify_init1 328
+#elif defined (__aarch64__)
+# define __NR_inotify_init1 26
+# define __NR_inotify_add_watch 27
+# define __NR_inotify_rm_watch 28
+// no inotify_init for aarch64
#else
Bug#735488: Qt4 in arm64: wrap up of the current situation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 29.01.2014 02:27, Lisandro Damián Nicanor Pérez Meyer pisze: Mark: please take a look at [0] for more context or ask Marcin. Quick context: getting AArch64 (aka arm64) Qt4 patches in upstream. Marcin, Mark: to get the code into the Qt4 tree I either need you to: a) push the code to Qt's gerrit instance or b) license the patches as BSD or something equally permissive The (a) case would be the simpler one for us (Qt / all other distros) but you might not be able to do so. So we can still the go the (b) way. In case (b) I would need a mail of each of you (preferably to this bug, 735...@bugs.debian.org) stating that you license the patches as BSD. My patches are usually licensed in a way upstream license a code. For this situation you can consider them to be on CC0 (aka public domain) or simply BSD licenced. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS6OANAAoJECbKqQEReiUeLcMP/0rrHQTHlwzA8N0RhKAc47Bt WhdJV8doN4uVaqCpr29aipjXa3fSy08GX6ViwwpCAxyii+13bD2ahZ/zvE3dn6TW FXVFRqMEi/1Qu66wqDmziLMa6CtixLDQ09/HhZtCzqXxETgYNhGjVRbrRA+fMNOR ExO2y1aEzAQdQ+tWrsuibiaNULsgFSD0x7Xi0ZwSSTn/R3HtCtFWomDY7wOyeLUN dyntH8vkzp7tI7ByuwqjcnfyemuD21ftkbdcGu4irm8nFvTp8Hq95KQ3OSIlRmfM Yc+91LJPk+RMczIUF0JfkET1Hjll8H6KwZ5POztLnbW+pGbr3sriGya7zwU/neRb 646aSyfgUUV6lsOOFgfu/fMoYkbQUyP+HNz1zmSvBq9nfF9g67YLJ8zKYEfatJz7 llEAyTTTrsveDXai23sn6At3Weng23+uzkv0GKq6Eu85CrcF6qcMWFqscjB0xW8/ BkOsFy+l1t6rxC6tMFw7xtmjXrR2j7DGGRu9uZhHtDcSaD8ZVYQ0F9P4HAAu4Ova 8ag9ly6ttVFRuKTsCDjBJUEGJ4yso0YkalrBG1aPhO+QFWLSm9/NUNvniX82oho8 LTLWgX2OWcek0Pdnnu7buv3T2U1iTtjX7v3iDX36nAquxXwNEFv+ZsfCThOKTnBH IwpQYpWOPEZ+iaoCLlbH =GmlU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
[snip] My patches are usually licensed in a way upstream license a code. For this situation you can consider them to be on CC0 (aka public domain) or simply BSD licenced. Thanks *a lot* Marcin! -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. Abraham Lincoln 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#735488: Qt4 in arm64: wrap up of the current situation
Mark: please take a look at [0] for more context or ask Marcin. Quick context: getting AArch64 (aka arm64) Qt4 patches in upstream. Marcin, Mark: to get the code into the Qt4 tree I either need you to: a) push the code to Qt's gerrit instance or b) license the patches as BSD or something equally permissive The (a) case would be the simpler one for us (Qt / all other distros) but you might not be able to do so. So we can still the go the (b) way. In case (b) I would need a mail of each of you (preferably to this bug, 735...@bugs.debian.org) stating that you license the patches as BSD. If you think there is another way to solve this, please do not heasitate in replying. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735488 Kinds regards, Lisandro. -- 18: Como se pueden evitar los problemas de alimentacion electrica * No coma cerca de un enchufe Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html 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#735488: Qt4 in arm64: wrap up of the current situation
On Monday 27 January 2014 19:29:04 Marcin Juszkiewicz wrote: [snip] Are QT4 patches going to be accepted at some point or will distros have to carry an arm64 patch for QT4 as long as it remains supported? Ask in https://bugreports.qt-project.org/browse/QTBUG-35442 please I'll take care of asking. Thanks! -- 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#735488: Qt4 in arm64: wrap up of the current situation
On Monday 27 January 2014 19:32:43 Marcin Juszkiewicz wrote: W dniu 27.01.2014 19:14, Lisandro Damián Nicanor Pérez Meyer pisze: So what we are currently missing should be: - The copyright and license of the qatomic stuff. Author: Mark Salter msal...@redhat.com License: same as upstream one \o/ Thanks a lot! -- 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#735488: Qt4 in arm64: wrap up of the current situation
On Monday 27 January 2014 18:20:21 Wookey wrote: [snip] Qt4 patches are not accepted upstream. All new code has to go to Qt5 and since 5.2.0 QAtomics stuff is using std::atomic so compiler takes care of it and there is no code for separate architectures. Are QT4 patches going to be accepted at some point or will distros have to carry an arm64 patch for QT4 as long as it remains supported? Thiago just replied that while technically is a new feature and thus should not be applied to Qt4, distros and most probably other users will use them, so better to accept them. Wookey: are there any arm64 porterboxes available? I can't promise anything, but maybe at some point I could help... Kinds regards, Lisandro. -- http://xkcd.com/162/ Siempre quise una novia así :-) 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#735488: Qt4 in arm64: wrap up of the current situation
On Monday 27 January 2014 22:32:01 Wookey wrote: [snip] Wookey: are there any arm64 porterboxes available? I can't promise anything, but maybe at some point I could help... Not yet. No. And I don't yet know when there might be. 'In time for Jessie, hopefully' is the only clue I've had so far from people who will be in a position to supply one. If you need builds done there are a couple of DDs who can get access (Riku and Fathi). I can do it indirectly. Probably best to pester me. I realise this is not at all convenient but access is very strictly controlled at the moment (because lawyers don't understand how work actually gets done). He, lawyers :) Don't worry, I get the idea :) To fully push the patches upstream we will need the -fpermisive stuff properly addressed though :-/ -- Why should I care about my chatter from yesterday? Nothing prevents me from becoming wiser. Konrad Adenauer, former German chancellor. http://lwn.net/SubscriberLink/397422/60a270d48f933c67/ 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#735488: Qt4 in arm64: wrap up of the current situation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 23.01.2014 18:57, Lisandro Damián Nicanor Pérez Meyer pisze: I've tried to summarize the current arm64 situation. The following are my conclusions, feel free to point if something is wrong, give more info/feedback, etc. As you know from my blog post [0] Qt/AArch64 patch has long history. 0. http://marcin.juszkiewicz.com.pl/2014/01/20/the-story-of-qtaarch64-patching/ = Stuff under debian/ - As explained in a mail before, we don't like the idea of passing -fpermissive as it can lead to very strange crashes. The code will need proper fixing. - We are building webkit with a separate source, -no-javascript-jit and the relevant webkit patches should be applied in src:qtwebkit. The relevant patches contained in the patch submitted by Wookey come from Riku Voipio and seems too similar to other patches we already have there, so it should not be a problem to apply them once we have Qt4 ready form arm64. - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. Maybe it is because linux-g++ may use '-m64' argument for GCC which AArch64 does not support so build fails. = Code patches aarch64.patch: - *No copyright* nor license. We need this at least to be able to apply it and ask upstream if they see it fit. There's the chance that some code comes from Ubuntu people. - Webkit stuff: as described above. If you need that for something: Author: Marcin Juszkiewicz mar...@juszkiewicz.com.pl based on gtkwebkit changes by Riku Voipio riku.voi...@linaro.org License: same as upstream one aarch64_fix_atomic_set.patch: - Copyright present. - Possibly needs the above patch applied. It requires aarch64.patch as it just change two lines. = Some extra remarks We need at least the proper copyright and license for the patches. In that way I'm able to apply them in the package and ping upstream wrt them. Of course, if the original author can push it to upstream's gerrit the better, because in case some objection arises I don't need to be in the middle as a (possibly noisy) proxy. Qt4 patches are not accepted upstream. All new code has to go to Qt5 and since 5.2.0 QAtomics stuff is using std::atomic so compiler takes care of it and there is no code for separate architectures. And all required patches were submitted - just one change to qtwebkit is stuck in review. https://bugreports.qt-project.org/browse/QTBUG-35442 is upstream bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS5owyAAoJECbKqQEReiUedDgQAIoJP8WhTIA+w08/LfuHsGMa gVI5vEtIsMb+IkMDPqFNmWok1//ocmdXPCJJPFRsHT7Nuy2z8I4pmmZFTzG6llgr zrbKb5mP3MCb6/tzv17YtOi3e8Inrz9+Z6YqdMEmhEtnKEO9llLQ55Af1n9ot7NP xB5OSGgWZSmwVpABEuO6+Ehg4wwyjciclC2JJFHUkTgEYjN4fzBDFGg007qS7fNe Q5jArjHnwXyfNFKsdtKWLbh/52IpwXm9t0Sa5OxqWjdmwmAnLo2YHDLrJWlLI1Of 4M7N36ph57huNuuN8pEuLgwM7BHhicK4EoDhjPD4dKisGUwTOaEGGhZMB+d1EjiQ pOCO8NUehWm96JvMmihv1Zb+j2R3q4q8zwwXK1nUQThTTBEE5Mdg63D5TAcHPV5P sL2GjaaKqHgePnQLrxekmZiSHNmfrjcJw12naTGUPsrf+tK4hZ3qGlHwznAKOKwn ZgJEH8mFiTRBNZ83gHSjP8j9NXiHCaxiRNFUL38e6dnYyNyEdz6zB+U4CyaHuEPR h7GQCyVapvHDe5PrA0aXIjVAAQQTw6TI57Ct4lYBdHqDNvBQZIvLr4lP8EYLWVhA gCdia6C7sbjGb96Gio8W8RtEuxhywh+g0wgndgWkF7RjMTXJxw4CFzOi/5WiTdQf topl5mzNXk+tvnb4jn6R =oz85 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
On Monday 27 January 2014 17:41:26 Marcin Juszkiewicz wrote: [snip] - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. Maybe it is because linux-g++ may use '-m64' argument for GCC which AArch64 does not support so build fails. Cool, thanks :) [snip] If you need that for something: Author: Marcin Juszkiewicz mar...@juszkiewicz.com.pl based on gtkwebkit changes by Riku Voipio riku.voi...@linaro.org License: same as upstream one Excellent! aarch64_fix_atomic_set.patch: - Copyright present. - Possibly needs the above patch applied. It requires aarch64.patch as it just change two lines. Yes, sadly we don't have the copyright for that yet :-( = Some extra remarks We need at least the proper copyright and license for the patches. In that way I'm able to apply them in the package and ping upstream wrt them. Of course, if the original author can push it to upstream's gerrit the better, because in case some objection arises I don't need to be in the middle as a (possibly noisy) proxy. Qt4 patches are not accepted upstream. All new code has to go to Qt5 and since 5.2.0 QAtomics stuff is using std::atomic so compiler takes care of it and there is no code for separate architectures. And all required patches were submitted - just one change to qtwebkit is stuck in review. https://bugreports.qt-project.org/browse/QTBUG-35442 is upstream bug. Correct. So what we are currently missing should be: - The copyright and license of the qatomic stuff. - Fix the code that FTBFS without -fpermissive. Thanks for your input! Kinds 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#735488: Qt4 in arm64: wrap up of the current situation
+++ Marcin Juszkiewicz [2014-01-27 17:41 +0100]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 23.01.2014 18:57, Lisandro Damián Nicanor Pérez Meyer pisze: I've tried to summarize the current arm64 situation. The following are my conclusions, feel free to point if something is wrong, give more info/feedback, etc. As you know from my blog post [0] Qt/AArch64 patch has long history. 0. http://marcin.juszkiewicz.com.pl/2014/01/20/the-story-of-qtaarch64-patching/ = Stuff under debian/ - As explained in a mail before, we don't like the idea of passing -fpermissive as it can lead to very strange crashes. The code will need proper fixing. - We are building webkit with a separate source, -no-javascript-jit and the relevant webkit patches should be applied in src:qtwebkit. The relevant patches contained in the patch submitted by Wookey come from Riku Voipio and seems too similar to other patches we already have there, so it should not be a problem to apply them once we have Qt4 ready form arm64. - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. Maybe it is because linux-g++ may use '-m64' argument for GCC which AArch64 does not support so build fails. I think this is correct. I recall hitting that issue. There was also stuff to do with selecting /lib64 vs /lib IIRC. (/lib is correct for arm64/aarch64). = Code patches aarch64.patch: - *No copyright* nor license. We need this at least to be able to apply it and ask upstream if they see it fit. There's the chance that some code comes from Ubuntu people. - Webkit stuff: as described above. If you need that for something: Author: Marcin Juszkiewicz mar...@juszkiewicz.com.pl based on gtkwebkit changes by Riku Voipio riku.voi...@linaro.org License: same as upstream one aarch64_fix_atomic_set.patch: - Copyright present. - Possibly needs the above patch applied. It requires aarch64.patch as it just change two lines. = Some extra remarks We need at least the proper copyright and license for the patches. In that way I'm able to apply them in the package and ping upstream wrt them. Of course, if the original author can push it to upstream's gerrit the better, because in case some objection arises I don't need to be in the middle as a (possibly noisy) proxy. Qt4 patches are not accepted upstream. All new code has to go to Qt5 and since 5.2.0 QAtomics stuff is using std::atomic so compiler takes care of it and there is no code for separate architectures. Are QT4 patches going to be accepted at some point or will distros have to carry an arm64 patch for QT4 as long as it remains supported? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
W dniu 27.01.2014 19:20, Wookey pisze: +++ Marcin Juszkiewicz [2014-01-27 17:41 +0100]: - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. Maybe it is because linux-g++ may use '-m64' argument for GCC which AArch64 does not support so build fails. I think this is correct. I recall hitting that issue. There was also stuff to do with selecting /lib64 vs /lib IIRC. (/lib is correct for arm64/aarch64). /lib or /lib64 is also distro choice. Are QT4 patches going to be accepted at some point or will distros have to carry an arm64 patch for QT4 as long as it remains supported? Ask in https://bugreports.qt-project.org/browse/QTBUG-35442 please -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 27.01.2014 19:14, Lisandro Damián Nicanor Pérez Meyer pisze: So what we are currently missing should be: - The copyright and license of the qatomic stuff. Author: Mark Salter msal...@redhat.com License: same as upstream one -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJS5qZHAAoJECbKqQEReiUeZPQQALLzIGAeCJtUDdk/yBoNv1dh T01VrWX8/aCW1n/DlgAdBGtZm8lTbL/29glib3qhoqLTHDvh4VmQ9kBRRt537vCt 7Qj/v3mDDmZYv5pAyReX7i0N8RRExKWk4alXnBJy62lP3TAGZar4VYjyU5STCIkK NVqs4oE1It38uQObdUaVoDynB0HP1rPsr9UHqZlT716QpORE2qh2PUFDZ4ACZHZh 7bAStNL/JOYqTEGolIm+q8kti3Ozkjx/EdnSjW3yHYy0Ih5PhTtVtqBeWEyv9CXw i5L1TKzV6XFlmm0qHvUHkTKQtidnnpO3/ew5E6tdz8oXVpo9prBVFpO6CE+FPvmn +N6tX+h44fjZ189b1+XB57Z7mV+PrRL6Wk60pKxrJrk5zp9scI0Bb/TEo1FkwPcA CioHrDxCFvywEN15LlUjNQgr2eeO6sPgfaXmrPQ9RAiSX1ojUb8h3BVbqVE8sQHr x1CugZvAGo4v7rSi7paZEGfJdHUWV8+FX/XmeddJq2kqA0icMYLPMPCVc+s7hy3m wLTyACVCFVdaoc6rau8V4pbMgEItvKXkiQueKe4KE5BLBXmVdkT5y+1ltubimrhY 44sQIR1py/gHwQSRrNZ85fio4DpVbzhqwFvAADlJZCbuKr9VNTt9tk9Fz55Gd3+3 LHb+qyxBhHE0vf3R5WN6 =w740 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735488: Qt4 in arm64: wrap up of the current situation
tag 735488 - patch thanks I've tried to summarize the current arm64 situation. The following are my conclusions, feel free to point if something is wrong, give more info/feedback, etc. = Stuff under debian/ - As explained in a mail before, we don't like the idea of passing -fpermissive as it can lead to very strange crashes. The code will need proper fixing. - We are building webkit with a separate source, -no-javascript-jit and the relevant webkit patches should be applied in src:qtwebkit. The relevant patches contained in the patch submitted by Wookey come from Riku Voipio and seems too similar to other patches we already have there, so it should not be a problem to apply them once we have Qt4 ready form arm64. - It uses linux-g++ instead of linux-g++-64. While that could be the best fit, it would be good to know why. - The autotools changes seems unnecessary, as we are not building the 3rd party code that uses it. I've already added a lintian override to the autotools stuff warning in the repo. = Code patches aarch64.patch: - *No copyright* nor license. We need this at least to be able to apply it and ask upstream if they see it fit. There's the chance that some code comes from Ubuntu people. - Webkit stuff: as described above. - mkspecs: not necessary, just added for completeness. aarch64_fix_atomic_set.patch: - Copyright present. - Possibly needs the above patch applied. = Some extra remarks We need at least the proper copyright and license for the patches. In that way I'm able to apply them in the package and ping upstream wrt them. Of course, if the original author can push it to upstream's gerrit the better, because in case some objection arises I don't need to be in the middle as a (possibly noisy) proxy. Kinds 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.
