Bug#741190: qt4-x11: Improve atomic support on parisc
tag 741190 pending thanks I have just added the patch to the repo, sorry for the delay. 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#741190: qt4-x11: Improve atomic support on parisc
Hi Lisandro,
On 4-Apr-14, at 2:18 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
On Friday 04 April 2014 11:46:23 John David Anglin wrote:
On 4/3/2014 10:19 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
OK, here's what upstream replied wrt the patch:
Sorry, there's no way we can accept this patch. It is totally
binary-
incompatible for PA-RISC since it changes the size of QAtomicInt.
Debian will need to keep the patch and ensure that everything is
built
with
the patch applied (or without it).
As noted in message #25, I was worried about this. However, this
is an
essential part of
the change and I don't see any other way to resolve bug #708200.
If you
have any suggestions
for resolving it without changing qt4-x11, let me know.
I'm ok on breaking binary compatibility just in Debian just for
parisc because
it's not a release arch. Would it have been otherwise, then not.
Attached is an updated patch which reflects that the parisc Linux
atomic support does use locks on
SMP systems. We would greatly appreciate your taking this patch in
Debian as it simplifies our support.
The latest Qt and kde release are now built upon this change.
Thanks,
Dave
--
John David Anglin dave.ang...@bell.net
Description: Revise PARISC atomic support to use GCC atomic builtins
The current atomic support for PARISC uses a four word object
to dynamically address the alignment requirements of the ldcw
instruction. Unfortunately, the current implementation breaks
the smokeqt package build http://bugs.debian.org/708200.
This change uses the GCC atomic builtin support available on
linux for qt4-x11 atomic operations. It is derived from the
AVR32 implementation. This allows atomic operations on integer
objects.
Author: John David Anglin dave.ang...@bell.net
Bug-Debian: http://bugs.debian.org/bugnumber
Forwarded: not-needed
Author: John David Anglin dave.ang...@bell.net
Last-Update: 2014-05-03
--- qt4-x11-4.8.6+dfsg.orig/src/corelib/arch/parisc/arch.pri
+++ qt4-x11-4.8.6+dfsg/src/corelib/arch/parisc/arch.pri
@@ -1,5 +1,3 @@
#
# HP PA-RISC architecture
#
-SOURCES += $$QT_ARCH_CPP/q_ldcw.s \
- $$QT_ARCH_CPP/qatomic_parisc.cpp
--- qt4-x11-4.8.6+dfsg.orig/src/corelib/arch/qatomic_parisc.h
+++ qt4-x11-4.8.6+dfsg/src/corelib/arch/qatomic_parisc.h
@@ -101,41 +101,19 @@ template typename T
Q_INLINE_TEMPLATE bool QBasicAtomicPointerT::isFetchAndAddWaitFree()
{ return false; }
-extern C {
-Q_CORE_EXPORT void q_atomic_lock(int *lock);
-Q_CORE_EXPORT void q_atomic_unlock(int *lock);
-}
-
-// Reference counting
-
inline bool QBasicAtomicInt::ref()
{
-q_atomic_lock(_q_lock);
-bool ret = (++_q_value != 0);
-q_atomic_unlock(_q_lock);
-return ret;
+return __sync_add_and_fetch(_q_value, 1);
}
inline bool QBasicAtomicInt::deref()
{
-q_atomic_lock(_q_lock);
-bool ret = (--_q_value != 0);
-q_atomic_unlock(_q_lock);
-return ret;
+return __sync_sub_and_fetch(_q_value, 1);
}
-// Test-and-set for integers
-
inline bool QBasicAtomicInt::testAndSetOrdered(int expectedValue, int newValue)
{
-q_atomic_lock(_q_lock);
-if (_q_value == expectedValue) {
-_q_value = newValue;
-q_atomic_unlock(_q_lock);
-return true;
-}
-q_atomic_unlock(_q_lock);
-return false;
+return __sync_bool_compare_and_swap(_q_value, expectedValue, newValue);
}
inline bool QBasicAtomicInt::testAndSetRelaxed(int expectedValue, int newValue)
@@ -153,15 +131,9 @@ inline bool QBasicAtomicInt::testAndSetR
return testAndSetOrdered(expectedValue, newValue);
}
-// Fetch-and-store for integers
-
inline int QBasicAtomicInt::fetchAndStoreOrdered(int newValue)
{
-q_atomic_lock(_q_lock);
-int returnValue = _q_value;
-_q_value = newValue;
-q_atomic_unlock(_q_lock);
-return returnValue;
+return __sync_lock_test_and_set(_q_value, newValue);
}
inline int QBasicAtomicInt::fetchAndStoreRelaxed(int newValue)
@@ -179,15 +151,9 @@ inline int QBasicAtomicInt::fetchAndStor
return fetchAndStoreOrdered(newValue);
}
-// Fetch-and-add for integers
-
inline int QBasicAtomicInt::fetchAndAddOrdered(int valueToAdd)
{
-q_atomic_lock(_q_lock);
-int originalValue = _q_value;
-_q_value += valueToAdd;
-q_atomic_unlock(_q_lock);
-return originalValue;
+return __sync_fetch_and_add(_q_value, valueToAdd);
}
inline int QBasicAtomicInt::fetchAndAddRelaxed(int valueToAdd)
@@ -205,19 +171,10 @@ inline int QBasicAtomicInt::fetchAndAddR
return fetchAndAddOrdered(valueToAdd);
}
-// Test and set for pointers
-
template typename T
Q_INLINE_TEMPLATE bool QBasicAtomicPointerT::testAndSetOrdered(T
*expectedValue, T *newValue)
{
-q_atomic_lock(_q_lock);
-if (_q_value == expectedValue) {
-_q_value = newValue;
-q_atomic_unlock(_q_lock);
-return true;
-}
-q_atomic_unlock(_q_lock);
-return false;
+return
Bug#741190: qt4-x11: Improve atomic support on parisc
On 4/3/2014 10:19 PM, Lisandro Damián Nicanor Pérez Meyer wrote: OK, here's what upstream replied wrt the patch: Sorry, there's no way we can accept this patch. It is totally binary- incompatible for PA-RISC since it changes the size of QAtomicInt. Debian will need to keep the patch and ensure that everything is built with the patch applied (or without it). As noted in message #25, I was worried about this. However, this is an essential part of the change and I don't see any other way to resolve bug #708200. If you have any suggestions for resolving it without changing qt4-x11, let me know. What's more, I m not sure that you can set the IS_WAIT_FREE macros, since they are probably not wait-free. Just because you removed the explicit lock doesn't mean GCC won't use one behind your back in the __sync functions. I know it does that for ARM for types whose size are not 4 bytes. And knowing PA-RISC doesn't have wait-free atomic instructions, I doubt GCC can do it wait free either. I will not have any problem to keep this delta **if and only if** you can prove is safe to set IS_WAIT_FREE macros. Based on this page http://qt-project.org/doc/qt-5/QAtomicInt.html, the macro defines need to stay as they were before. The implementation is not lock or loop free. I will update the patch and retest. The compare and swap implementation is not in GCC but in the kernel. If you can't, then you need another fix. Tip: if you want to dig further in this subject, you might ask thiago on #qt on freenode, he's the Qt core maintainer. Kinds regards, Lisandro. Thanks for helping. Regards, Dave -- John David Anglindave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Friday 04 April 2014 11:46:23 John David Anglin wrote: On 4/3/2014 10:19 PM, Lisandro Damián Nicanor Pérez Meyer wrote: OK, here's what upstream replied wrt the patch: Sorry, there's no way we can accept this patch. It is totally binary- incompatible for PA-RISC since it changes the size of QAtomicInt. Debian will need to keep the patch and ensure that everything is built with the patch applied (or without it). As noted in message #25, I was worried about this. However, this is an essential part of the change and I don't see any other way to resolve bug #708200. If you have any suggestions for resolving it without changing qt4-x11, let me know. I'm ok on breaking binary compatibility just in Debian just for parisc because it's not a release arch. Would it have been otherwise, then not. What's more, I m not sure that you can set the IS_WAIT_FREE macros, since they are probably not wait-free. Just because you removed the explicit lock doesn't mean GCC won't use one behind your back in the __sync functions. I know it does that for ARM for types whose size are not 4 bytes. And knowing PA-RISC doesn't have wait-free atomic instructions, I doubt GCC can do it wait free either. I will not have any problem to keep this delta **if and only if** you can prove is safe to set IS_WAIT_FREE macros. Based on this page http://qt-project.org/doc/qt-5/QAtomicInt.html, the macro defines need to stay as they were before. The implementation is not lock or loop free. I will update the patch and retest. Cool :) -- 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#741190: qt4-x11: Improve atomic support on parisc
OK, here's what upstream replied wrt the patch: Sorry, there's no way we can accept this patch. It is totally binary- incompatible for PA-RISC since it changes the size of QAtomicInt. Debian will need to keep the patch and ensure that everything is built with the patch applied (or without it). What's more, I m not sure that you can set the IS_WAIT_FREE macros, since they are probably not wait-free. Just because you removed the explicit lock doesn't mean GCC won't use one behind your back in the __sync functions. I know it does that for ARM for types whose size are not 4 bytes. And knowing PA-RISC doesn't have wait-free atomic instructions, I doubt GCC can do it wait free either. I will not have any problem to keep this delta **if and only if** you can prove is safe to set IS_WAIT_FREE macros. If you can't, then you need another fix. Tip: if you want to dig further in this subject, you might ask thiago on #qt on freenode, he's the Qt core maintainer. Kinds regards, Lisandro. -- Programming is really just the mundane aspect of expressing a solution to a problem. There are talents that are specifically related to actually coding, but the real issue is being able to grasp problems and devise solutions that are detailed enough to actually be coded. John Carmack answers on Slashdot, http://slashdot.org/games/99/10/15/1012230.shtml 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#741190: qt4-x11: Improve atomic support on parisc
On 22-Mar-14, at 11:32 PM, Lisandro Damián Nicanor Pérez Meyer wrote: Patch pushed upstream, not it's just time to wait for Thiago to check it :) Thanks for the upstream push. This is reference for m68k change: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660963 #58 Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Wednesday 12 March 2014 19:10:25 John David Anglin wrote: [snip] I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) I have no objection to this approach and could try to send a signed email on the weekend. It's something I've never done before. OK, then let's try with an unsigned mail to this address (741190@...) stating that you put the patch under a BSD license. If we then get the requirement to get it signed we will see what to do. I don't understand the copyright situation for these files. It is my understanding that Helge contributed the code that is being removed in my patch. The AVR32 header that is copied has a Digia copyright. Indeed, every file that I looked at has a Digia copyright. AVR32? OK, did you write this patch or did you just copied another header from Qt source and applied it to parisc? In case you have done the latest, did you modify anything? Please try to be as verbose as possible, it will certainly be the best for all of us :-D WRT copyright: if you substantially modify a file you also get a copyright right, except the changes are trivial or come from well defined data. Kinds regards, Lisandro. -- Super cow powers | bbq /dev/stomach Traveler1, seen on #debian-ar, irc.oftc.net 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#741190: qt4-x11: Improve atomic support on parisc
On 22-Mar-14, at 9:38 PM, Lisandro Damián Nicanor Pérez Meyer wrote: On Wednesday 12 March 2014 19:10:25 John David Anglin wrote: [snip] I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) I have no objection to this approach and could try to send a signed email on the weekend. It's something I've never done before. OK, then let's try with an unsigned mail to this address (741190@...) stating that you put the patch under a BSD license. If we then get the requirement to get it signed we will see what to do. Will do tomorrow. Sorry for the delay. I don't understand the copyright situation for these files. It is my understanding that Helge contributed the code that is being removed in my patch. The AVR32 header that is copied has a Digia copyright. Indeed, every file that I looked at has a Digia copyright. AVR32? OK, did you write this patch or did you just copied another header from Qt source and applied it to parisc? In case you have done the latest, did you modify anything? Please try to be as verbose as possible, it will certainly be the best for all of us :-D I did not write the new qatomic_parisc.h header file. I deleted the old qatomic_parisc.h file, copied qatomic_avr32.h to qatomic_parisc.h and changed all instances of AVR32 to PARISC to ensure that the included header is unique to parisc. Only three lines are changed in the original avr32 header: #ifndef QATOMIC_AVR32_H to #ifndef QATOMIC_PARISC_H #define QATOMIC_AVR32_H to #define QATOMIC_PARISC_H #endif // QATOMIC_AVR32_H to #endif // QATOMIC_PARISC_H Thus, there is no functional difference between the AVR32 and PARISC implementations. I understand that m68k is using a similar approach to enable Qt support. I learned this in a message posted by Thorsten Glaser a few months ago, but I haven't seen a m68k patch. I believe the message is in a Debian bug report. This is what led me to develop the change. WRT copyright: if you substantially modify a file you also get a copyright right, except the changes are trivial or come from well defined data. I would prefer not to have copyright on the modified files because of the commercial licensing of Qt. I believe the changes are trivial and simply revert to the atomic implementation used by all other architectures. Regards, Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Saturday 22 March 2014 22:42:02 John David Anglin wrote: [snip] AVR32? OK, did you write this patch or did you just copied another header from Qt source and applied it to parisc? In case you have done the latest, did you modify anything? Please try to be as verbose as possible, it will certainly be the best for all of us :-D I did not write the new qatomic_parisc.h header file. I deleted the old qatomic_parisc.h file, copied qatomic_avr32.h to qatomic_parisc.h and changed all instances of AVR32 to PARISC to ensure that the included header is unique to parisc. Only three lines are changed in the original avr32 header: #ifndef QATOMIC_AVR32_H to #ifndef QATOMIC_PARISC_H #define QATOMIC_AVR32_H to #define QATOMIC_PARISC_H #endif // QATOMIC_AVR32_H to #endif // QATOMIC_PARISC_H Thus, there is no functional difference between the AVR32 and PARISC implementations. Ahhh, then everything is much easier then. It's just a matter of letting the right people know. I understand that m68k is using a similar approach to enable Qt support. I learned this in a message posted by Thorsten Glaser a few months ago, but I haven't seen a m68k patch. I believe the message is in a Debian bug report. This is what led me to develop the change. WRT copyright: if you substantially modify a file you also get a copyright right, except the changes are trivial or come from well defined data. I would prefer not to have copyright on the modified files because of the commercial licensing of Qt. This is strange for you to say, as the code will remain 100% libre. If you want to make things clearer do not heasitate to write me in private (just because it's off topic for the bug). I believe the changes are trivial and simply revert to the atomic implementation used by all other architectures. Indeed, this changes everything. -- rata hmm, el enchufe hace chispas... -- rata ha dejado este servidor (Leaving). marga ouch Visto en #lugfi, irc.freenode.net 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#741190: qt4-x11: Improve atomic support on parisc
Patch pushed upstream, not it's just time to wait for Thiago to check it :) -- Dadme voto electrónico y con una terminal os haré presidente. el.machi 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#741190: qt4-x11: Improve atomic support on parisc
On 03/12/2014 03:27 AM, John David Anglin wrote: I also don't want to become a Qt developer. I have enough on my plate with GCC and Linux. Helge, do you have any thoughts about this? I would be interested to come up with a good fix, and even submit it via the required CLA, but right now I'm pretty busy with so many things, that I don't want to take another one in addition. Maybe in a few weeks. I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) It looks to me like it's best for me to continue to patch the binary uploads given the Qt CLA. Or alternatively if Debian could carry your patch until we get it resolved somehow in the future (either by me or you) ? Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Wednesday 12 March 2014 21:57:37 Helge Deller wrote: On 03/12/2014 03:27 AM, John David Anglin wrote: I also don't want to become a Qt developer. I have enough on my plate with GCC and Linux. Helge, do you have any thoughts about this? I would be interested to come up with a good fix, and even submit it via the required CLA, but right now I'm pretty busy with so many things, that I don't want to take another one in addition. Maybe in a few weeks. I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) We are currently testing that with some aarch64 (arm64) patches. But this means it has to go though the Chief Engineer Lars Knoll, so it's a bottleneck. It looks to me like it's best for me to continue to patch the binary uploads given the Qt CLA. Or alternatively if Debian could carry your patch until we get it resolved somehow in the future (either by me or you) ? We try our best to avoid any delta with upstream, both to get an upstream ACK both the patch to prevent possible problems and to avoid to let the patch rotten in our repos. So the best path here is pushing it upstream :) -- 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
Hi Lisandro, On 03/12/2014 10:18 PM, Lisandro Damián Nicanor Pérez Meyer wrote: We try our best to avoid any delta with upstream, both to get an upstream ACK both the patch to prevent possible problems and to avoid to let the patch rotten in our repos. Fully understandable. So the best path here is pushing it upstream :) Yes, sure. The only reason why I proposed that is, that each time when you push a new qt4 through the debian buildds, we are in trouble on hppa because I have to kill the build process manually and trigger Dave to build qt4 with his patch manually. If we forget this we will run into unresolved symbols with *all* our already built packages which depend on qt4 (e.g. all KDE apps). So, I'm just asking you to add it to your patch repo until we really can resolve it. Helge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Wednesday 12 March 2014 22:39:17 Helge Deller wrote: Hi Lisandro, On 03/12/2014 10:18 PM, Lisandro Damián Nicanor Pérez Meyer wrote: We try our best to avoid any delta with upstream, both to get an upstream ACK both the patch to prevent possible problems and to avoid to let the patch rotten in our repos. Fully understandable. So the best path here is pushing it upstream :) Yes, sure. The only reason why I proposed that is, that each time when you push a new qt4 through the debian buildds, we are in trouble on hppa because I have to kill the build process manually and trigger Dave to build qt4 with his patch manually. If we forget this we will run into unresolved symbols with *all* our already built packages which depend on qt4 (e.g. all KDE apps). So, I'm just asking you to add it to your patch repo until we really can resolve it. This is fully understandable too. But if I lower the threshold for you, I need to lower it for everyone, and then I get swamped on a myriad of patches that I can't push upstream. The arm64 case might be a game changer if we can push 3rd party [0] BSD patches directly, even if we need to get trough Lars each time. [0] Read this as not wrote by the person pushing it to gerrit -- So long, and thanks for all the fish! The Hitchhickers guide to the Galaxy 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#741190: qt4-x11: Improve atomic support on parisc
On Wednesday 12 March 2014 18:59:25 Lisandro Damián Nicanor Pérez Meyer wrote: On Wednesday 12 March 2014 22:39:17 Helge Deller wrote: Hi Lisandro, On 03/12/2014 10:18 PM, Lisandro Damián Nicanor Pérez Meyer wrote: We try our best to avoid any delta with upstream, both to get an upstream ACK both the patch to prevent possible problems and to avoid to let the patch rotten in our repos. Fully understandable. So the best path here is pushing it upstream :) Yes, sure. The only reason why I proposed that is, that each time when you push a new qt4 through the debian buildds, we are in trouble on hppa because I have to kill the build process manually and trigger Dave to build qt4 with his patch manually. If we forget this we will run into unresolved symbols with *all* our already built packages which depend on qt4 (e.g. all KDE apps). So, I'm just asking you to add it to your patch repo until we really can resolve it. This is fully understandable too. But if I lower the threshold for you, I need to lower it for everyone, and then I get swamped on a myriad of patches that I can't push upstream. The arm64 case might be a game changer if we can push 3rd party [0] BSD patches directly, even if we need to get trough Lars each time. [0] Read this as not wrote by the person pushing it to gerrit And by the way, going through gerrit sounds more like an inversion than a problem if you need to stop the buildd every time someone of the team pushed Qt :) -- 127.0.0.1 sweet 127.0.0.1 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#741190: qt4-x11: Improve atomic support on parisc
Let me offer you another idea: if you really can't go trough gerrit I would need the author of the patch to send a signed mail to this bug report sating that he puts the patch under some BSD-like license (Expat comes to my mind). In this way I can at least try to push it myself as 3rd party code. Of course, I would **really** like to get the patch through the normal flow, but it's the most I can do from my side. -- Mi experiencia me dice que lo que la gente quiere y necesita -en Indonesia, en Turquía, en Italia, en los Estados Unidos, en Brasil, en la Argentina o donde sea- es básicamente lo mismo. La gente quiere comida en la mesa, una vivienda básica, un gobierno que funcione, que en las fuerzas de seguridad haya personas confiables, a las que no tengan que tenerles miedo, educación y salud. ¡La gente de todo el mundo quiere lo mismo! Padre Thomas Michel, jesuita, especialista en diálogo interreligioso, en una entrevista de Elisabetta Piqué para La Nación, 27/09/2006. http://www.lanacion.com.ar/844069 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#741190: qt4-x11: Improve atomic support on parisc
On 12-Mar-14, at 4:57 PM, Helge Deller wrote: On 03/12/2014 03:27 AM, John David Anglin wrote: I also don't want to become a Qt developer. I have enough on my plate with GCC and Linux. Helge, do you have any thoughts about this? I would be interested to come up with a good fix, and even submit it via the required CLA, but right now I'm pretty busy with so many things, that I don't want to take another one in addition. Maybe in a few weeks. This is also a busy time for me. Helge, do you still have a CLA? If you don't, wouldn't you need to get your employer to apply? That might take time as it would probably require legal review. I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) I have no objection to this approach and could try to send a signed email on the weekend. It's something I've never done before. I don't understand the copyright situation for these files. It is my understanding that Helge contributed the code that is being removed in my patch. The AVR32 header that is copied has a Digia copyright. Indeed, every file that I looked at has a Digia copyright. It looks to me like it's best for me to continue to patch the binary uploads given the Qt CLA. Or alternatively if Debian could carry your patch until we get it resolved somehow in the future (either by me or you) ? Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Monday 10 March 2014 10:52:23 John David Anglin wrote: On 3/10/2014 9:06 AM, Lisandro Damián Nicanor Pérez Meyer wrote: tag 741190 moreinfo thanks Hi Jhon! This seems an interesting bugfix for Qt4, if there any chance for you to push it upstream? As it stands, the patch is only applicable to linux. On parisc, kernel support is required to implement GCC's atomic builtins and linux is the only system with this support. I have no clue as to whether Qt will build on hpux or openbsd. If not, the change could go upstream as is. Otherwise, we need to keep the old atomic code for hpux and openbsd. I think not, so the best thing here would be to you to push it upstream. Please note I would really love to do it myself, but I can't due to Qt's CLA. You need to sign up in upstream's gerrit instance and push the patch there. Of course, **do not hesitate** in asking me for help if needed. Once you have pushed the patch upstream, also don't forget to add me as reviewer, at that point I might be of even more help :) The patch changes the atomic interface and this affects quite a few packages using qt4-x11. Since hppa has been back in ports, we have been building qt4-x11 unstable with this change. That's the perfect reason for upstream to accept it, don't forget to mention it! Thanks! -- 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#741190: qt4-x11: Improve atomic support on parisc
On 11-Mar-14, at 10:50 AM, Lisandro Damián Nicanor Pérez Meyer wrote: I think not, so the best thing here would be to you to push it upstream. Please note I would really love to do it myself, but I can't due to Qt's CLA. You need to sign up in upstream's gerrit instance and push the patch there. Well this is messy. I already a similar agreement with the FSF, and as an independent contractor, I deal with other organizations who I transfer copy right assignments for the work I do. I don't really want to sign another CLA for a single change. I also don't want to become a Qt developer. I have enough on my plate with GCC and Linux. Helge, do you have any thoughts about this? Of course, **do not hesitate** in asking me for help if needed. Once you have pushed the patch upstream, also don't forget to add me as reviewer, at that point I might be of even more help :) The patch changes the atomic interface and this affects quite a few packages using qt4-x11. Since hppa has been back in ports, we have been building qt4-x11 unstable with this change. That's the perfect reason for upstream to accept it, don't forget to mention it! Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Tuesday 11 March 2014 18:52:27 John David Anglin wrote: On 11-Mar-14, at 10:50 AM, Lisandro Damián Nicanor Pérez Meyer wrote: I think not, so the best thing here would be to you to push it upstream. Please note I would really love to do it myself, but I can't due to Qt's CLA. You need to sign up in upstream's gerrit instance and push the patch there. Well this is messy. I already a similar agreement with the FSF, and as an independent contractor, I deal with other organizations who I transfer copy right assignments for the work I do. I don't really want to sign another CLA for a single change. I also don't want to become a Qt developer. I have enough on my plate with GCC and Linux. Helge, do you have any thoughts about this? Just for the record: with Qt CLA you are not transferring copyright. From [0] It is important to note that the contributor retains ownership of the contribution as the Qt Project does not require copyright assignment for contributions made to the Qt Project. [0] http://qt-project.org/legal.html -- 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
tag 741190 moreinfo thanks Hi Jhon! This seems an interesting bugfix for Qt4, if there any chance for you to push it upstream? -- With great power comes great responsibility. Peter Parker's uncle. 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#741190: qt4-x11: Improve atomic support on parisc
On 3/10/2014 9:06 AM, Lisandro Damián Nicanor Pérez Meyer wrote: tag 741190 moreinfo thanks Hi Jhon! This seems an interesting bugfix for Qt4, if there any chance for you to push it upstream? As it stands, the patch is only applicable to linux. On parisc, kernel support is required to implement GCC's atomic builtins and linux is the only system with this support. I have no clue as to whether Qt will build on hpux or openbsd. If not, the change could go upstream as is. Otherwise, we need to keep the old atomic code for hpux and openbsd. The patch changes the atomic interface and this affects quite a few packages using qt4-x11. Since hppa has been back in ports, we have been building qt4-x11 unstable with this change. Dave -- John David Anglindave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
Package: qt4-x11 Severity: important The smokeqt package fails to build on hppa. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708200 Will attach fix to this bug report. I would appreciate your adding it to the set of packages for qt4-x11. Dave -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 3.13.6+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
Attached patch. -- John David Anglin dave.ang...@bell.net qt4-x11-parisc-atomic.diff Description: Binary data
