Re: Bug#735488: Qt4 in arm64: wrap up of the current situation

[Lisandro Damián Nicanor Pérez Meyer]

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

[Mark Salter]

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] 
> 
> 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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1395259141.2967.56.ca...@deneb.redhat.com

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Lisandro Damián Nicanor Pérez Meyer]

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] 

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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1666784.Zuv8zkeyqR@tonks

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Dmitry Shachnev]

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  based on
> gtkwebkit changes by Riku Voipio 

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

[Dmitry Shachnev]

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

[Marcin Juszkiewicz]

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 i

Re: Bug#735488: Qt4 in arm64: wrap up of the current situation

[Lisandro Damián Nicanor Pérez Meyer]

[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

[Marcin Juszkiewicz]

-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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e8e011.8060...@redhat.com

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Lisandro Damián Nicanor Pérez Meyer]

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] 

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

[Lisandro Damián Nicanor Pérez Meyer]

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

[Lisandro Damián Nicanor Pérez Meyer]

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

[Lisandro Damián Nicanor Pérez Meyer]

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

[Lisandro Damián Nicanor Pérez Meyer]

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 
> 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

[Marcin Juszkiewicz]

-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 
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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e6a64b.7060...@redhat.com

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Marcin Juszkiewicz]

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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e6a570.3000...@redhat.com

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Lisandro Damián Nicanor Pérez Meyer]

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  based on
> gtkwebkit changes by Riku Voipio 
> 
> 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

[Wookey]

+++ 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  based on
> gtkwebkit changes by Riku Voipio 
> 
> 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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140127182021.gr21...@stoneboat.aleph1.co.uk

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Marcin Juszkiewicz]

-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  based on
gtkwebkit changes by Riku Voipio 

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-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e68c36.1080...@redhat.com

Bug#735488: Qt4 in arm64: wrap up of the current situation

[Lisandro Damián Nicanor Pérez Meyer]

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.