Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa
On 3/12/23 22:40, Lisandro Damián Nicanor Pérez Meyer wrote: I'm afraid we had similar problems before. Let's better wait for someone to properly test that things are working. Just out of couriosity: Do you know if someone tested on mips, mips64el, mipsel, powerpc, ppc64, riscv64 or s390x ? How should one test? Helge
Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa
Hello Dmitry, On 3/11/23 19:19, Dmitry Shachnev wrote: On Mon, Feb 06, 2023 at 10:12:37PM +0100, Helge Deller wrote: Package: qtquickcontrols-opensource-src Tags: ftbfs, hppa Version: 5.15.8-2 qtquickcontrols-opensource-src FTBFS on hppa with this testcase failure: FAIL! : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values are not the same Actual (): 0 Expected (): 1 Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)] see: https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.8-2=1675556283=0 Looking at debian/rules file I see: $(MAKE) install INSTALL_ROOT=$(CURDIR)/test_root ifneq (,$(filter $(DEB_HOST_ARCH),mips mips64el mipsel powerpc ppc64 riscv64 s390x)) # mips*: segmentation fault, see #868745 # powerpc, ppc64: some failures in extras::Tests_Picture and extras::Tests_StatusIndicator # riscv64: failure in qtquickcontrols::Tests_TreeView::test_pressAndHold # s390x: some failures in qtquickcontrols::Tests_TableView and qtquickcontrols::Tests_TreeView -xvfb-run -a -s "-screen 0 1024x768x24 +extension RANDR +extension RENDER +extension GLX" \ dh_auto_test --no-parallel -- QML2_IMPORT_PATH=$(CURDIR)/test_root/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/qml else so, "riscv64" fails the same testcase. I don't know the backgrounds why riscv64 fails, but I assume adding "hppa" to the ifneq() like this: ifneq (,$(filter $(DEB_HOST_ARCH),mips mips64el mipsel powerpc ppc64 riscv64 s390x hppa)) might fix (or avoid) the FTBFS. I see that someone forced the package to build without the tests, so now it's available in the hppa archive. Yes, sometimes we need to force a build without tests to guarantee forward progress for dependend packages. But we do that rarely and of course it's better to really fix such issues (and avoid that extra build). But have you checked that the produced package is usable? I'm not sure any longer if it was me or not. So, at least I did not check. Does Qt QML engine work on hppa, or there are issues caused by stack growing up? I can't easily test, as my machines run server builds. If you think it works, then I will be happy to disable the tests there. If you look at the log https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.8-2=1675556283=0 the "qtquickcontrols::Tests_TreeView::test_pressAndHold()" test was the only one which failed, same as on the other platforms. So I'd believe it works. It would be great if you could apply that patch. Thank you, Helge
Bug#1030546: qt6-base FTBFS on hppa
Package: qt6-base Tags: patch, ftbfs, hppa Version: 6.4.2+dfsg The attached patch fixes this qt6-base "build-from-source" (FTBFS) failure on hppa: /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC The problem is, that qt6-base suddenly tries to link against the static library of libzstd.a, while in the past it did linked against the shared library: In current failing build (6.4.2+dfsg-1): -- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required is "1.3") Full log is here: https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.2%2Bdfsg-1=1675198832=0 while it worked in the past for qt6-base 6.4.2+dfsg~rc1-1 -- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable version "1.5.2", minimum required is "1.3") Full log is here: https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.2%2Bdfsg%7Erc1-1=1672201686=0 The attached patch changes WrapZSTD to prefer the dynamic library. Thanks, Helge[PATCH] FindWrapZSTD: Prefer libzstd shared library over static library On some architectures a static library can not be linked into shared library because shared libraries may need specific symbol relocations. This fixes the build on hppa architecture which gives those errors: /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(zstd_v05.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(zstd_v06.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(zstd_v07.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(huf_decompress.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC Signed-off-by: Helge Deller --- diff -up ./cmake/FindWrapZSTD.cmake.org ./cmake/FindWrapZSTD.cmake --- ./cmake/FindWrapZSTD.cmake.org 2023-02-04 17:50:29.119361823 + +++ ./cmake/FindWrapZSTD.cmake 2023-02-04 17:51:51.876153609 + @@ -25,10 +25,10 @@ include(FindPackageHandleStandardArgs) if(TARGET zstd::libzstd_static OR TARGET zstd::libzstd_shared) find_package_handle_standard_args(WrapZSTD REQUIRED_VARS zstd_VERSION VERSION_VAR zstd_VERSION) -if(TARGET zstd::libzstd_static) -set(zstdtargetsuffix "_static") -else() +if(TARGET zstd::libzstd_shared) set(zstdtargetsuffix "_shared") +else() +set(zstdtargetsuffix "_static") endif() if(NOT TARGET WrapZSTD::WrapZSTD) add_library(WrapZSTD::WrapZSTD INTERFACE IMPORTED)
Bug#797200: qtbase-opensource-src FTBFS on alpha, hppa m68k
Package: qtbase-opensource-src Version: 5.4.2+dfsg-8 qtbase-opensource-src fails to build on alpha, hppa and m68k architectures, because the symbol files differ. Full logs can be found here: https://buildd.debian.org/status/package.php?p=qtbase-opensource-srcsuite=sid Can you please fix the symbol files for those architectures as well? Thanks, Helge
Bug#764893: PATCH for qtwebsockets-opensource-src FTBFS (hppa/ppc/all)
Hi Dmitry, On 25.01.2015 08:49, Dmitry Shachnev wrote: On Sat, 24 Jan 2015 21:43:11 +0100, Helge Deller wrote: Attached patch fixes everything on the hppa architecture. I'm sure that it will fix powerpc and ppc64el architectures too. Thanks a lot for the patch, it does fix powerpc and ppc64el too. Great! I am uploading it to Debian right now. Do you know why the issue was happening only on these architectures and only with qtbase 5.4 (not 5.3)? I don't know for sure, but in Qt it's documented that you should use the SIGNAL() and SLOT() handlers should be used to avoid issues on various platforms (to be cross platform compatible). So I think it's a mixture of various effect. Overall it's a long time ago that I did Qt development. If it's correct, maybe can push it upstream to https://bugreports.qt.io/browse/QTBUG-43804 ? Upstream Qt uses Gerrit [1][2] for code review, so please submit your patch that way if you can (you will also need to sign the CLA to be able to do that). I would prefer if you could handle that. I don't have such agreements signed... Helge -- 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/54c4a3bb.4090...@gmx.de
Bug#764893: PATCH for qtwebsockets-opensource-src FTBFS (hppa/ppc/all)
Hi Lisandro On 25.01.2015 16:04, Lisandro Damián Nicanor Pérez Meyer wrote: On Sunday 25 January 2015 09:05:15 Helge Deller wrote: [snip] If it's correct, maybe can push it upstream to https://bugreports.qt.io/browse/QTBUG-43804 ? Upstream Qt uses Gerrit [1][2] for code review, so please submit your patch that way if you can (you will also need to sign the CLA to be able to do that). I would prefer if you could handle that. I don't have such agreements signed... a) You don't need to sign anything, just create an account and accept the terms. It basically boils down to: The copyright of my patches are mine but I give Digia/the Qt Company the rights to use it in their commercial edition. Basically still free software, but more BSD-like. I'm fine with that license. I even just created mayself an account and accepted that license, but I don't see an easy way how to just append my patch to some kind of description so that it can get accepted. Maybe I'm blind, but it seems I need to check out the tree, commit and so on. If that's true, then it's a quite huge hurdle... b) An alternative is if you publicly declare your patch under a BSD license, like for example replying to this thread. I think I prefer that option now. I'm happy to put my patch under the BSD license, so now it is. This is the easiest way for you, but we try to let the original patch coders to submit them upstream. I fully see the point, but the way how patches are submitted to other projects seems much more easy for developers who just bring in 1-2 patches in total... Helge -- 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/54c55bb5.2050...@gmx.de
Bug#764893: qtwebsockets-opensource-src FTBFS on hppa (and ppc)
Upstream bug seems to be: https://bugreports.qt.io/browse/QTBUG-43804 -- 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/54c3f327.5000...@gmx.de
Bug#764893: PATCH for qtwebsockets-opensource-src FTBFS (hppa/ppc/all)
I did some more debugging on this bug report.
The problem is, that the code in the testcase is wrong.
One always needs to connect SIGNALs to SLOTS.
In the original code for example it was tried to connect the closed signal to a
closed slot, although an
EchoServer::closed() slot does not exist (but a closed signal which isn't used).
Attached patch fixes everything on the hppa architecture.
I'm sure that it will fix powerpc and ppc64el architectures too.
If it's correct, maybe can push it upstream to
https://bugreports.qt.io/browse/QTBUG-43804 ?
Helge
diff -up ./tests/auto/qwebsocket/tst_qwebsocket.cpp.org ./tests/auto/qwebsocket/tst_qwebsocket.cpp
--- ./tests/auto/qwebsocket/tst_qwebsocket.cpp.org 2015-01-24 21:28:49.069050151 +0100
+++ ./tests/auto/qwebsocket/tst_qwebsocket.cpp 2015-01-24 21:30:18.937237039 +0100
@@ -58,9 +58,6 @@ public:
QHostAddress hostAddress() const { return m_pWebSocketServer-serverAddress(); }
quint16 port() const { return m_pWebSocketServer-serverPort(); }
-Q_SIGNALS:
-void closed();
-
private Q_SLOTS:
void onNewConnection();
void processTextMessage(QString message);
@@ -79,9 +76,8 @@ EchoServer::EchoServer(QObject *parent)
m_clients()
{
if (m_pWebSocketServer-listen()) {
-connect(m_pWebSocketServer, QWebSocketServer::newConnection,
-this, EchoServer::onNewConnection);
-connect(m_pWebSocketServer, QWebSocketServer::closed, this, EchoServer::closed);
+connect(m_pWebSocketServer, SIGNAL(newConnection()),
+this, SLOT(onNewConnection()));
}
}
@@ -95,9 +91,9 @@ void EchoServer::onNewConnection()
{
QWebSocket *pSocket = m_pWebSocketServer-nextPendingConnection();
-connect(pSocket, QWebSocket::textMessageReceived, this, EchoServer::processTextMessage);
-connect(pSocket, QWebSocket::binaryMessageReceived, this, EchoServer::processBinaryMessage);
-connect(pSocket, QWebSocket::disconnected, this, EchoServer::socketDisconnected);
+connect(pSocket, SIGNAL(textMessageReceived(QString)), this, SLOT(processTextMessage(QString)));
+connect(pSocket, SIGNAL(binaryMessageReceived(QByteArray)), this, SLOT(processBinaryMessage(QByteArray)));
+connect(pSocket, SIGNAL(disconnected()), this, SLOT(socketDisconnected()));
m_clients pSocket;
}
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-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5320ca41.7040...@gmx.de
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-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5320d405.8050...@gmx.de
Bug#475767: [Fwd: Re: kde4libs vs qt4]
This should really fix the bug...
---BeginMessage---
Hello Sune,
Sune Vuorela wrote:
I now hacked a bit and got stuff working on one of those cluster machines.
http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4-
x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=filerev=0sc=0
This isn't the real solution though.
Qt4 has arch specific code for most archs (and a generic arch mostly used
for bootstrapping of Qt), but no arch for linux/hppa, so we use the generic
arch here.
The real solution involves some hppa assembler (which is way out of my
league). There is a patch in the package by lamont about patching the hpux
code, but I couldn't get taht to work with my quick tests.
Attached are the basic pieces which should get it working with the
qt4-x11_4.4.0-3 source package. My machine is still compiling, but it
seems OK so far...
First of all, I reused the parisc architecture code from the Trolls.
hppa and parisc are the same architectures, so why introduce something
new? Furthermore the Qt code base has lots of #ifdef QT_ARCH_PARISC,
e.g. in src/corelib/thread/qbasicatomic.h, which would need to be
duplicated for hppa.
The nice effect is, that this way the parisc-atomic-headers will be used
instead of the generic-locking-headers and it should fix a lot of
following problems, e.g. with KDE.
This piece makes configure detect hppa as a parisc-architecture:
diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org
./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 2008-06-11
23:34:12.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff 2008-06-11
23:34:23.0 +0200
@@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t
+ UNAME_MACHINE=armv5tel
+ ;;
+ hppa)
-+ UNAME_MACHINE=parisc64
++ UNAME_MACHINE=parisc
+ ;;
+ hurd-i386)
+ UNAME_MACHINE=i686-AT386
Not sure if it's needed, but it doesn't hurts either:
(I had some problems on my machine, that the Qt configure tests could
not detect the endianess.)
diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org 2008-06-10 23:50:44.0 +0200
+++ ./debian/rules 2008-06-11 23:36:26.0 +0200
@@ -65,6 +65,8 @@ ifeq ($(DEB_HOST_ARCH),hppa)
echo Please update kernel and test again ; \
exit 5 ; \
fi
+
+ EXTRA_CONFIGURE_OPTS += -v -big-endian
endif
# Create mkspecs/glibc-g++ from mkspecs/linux-g++, needed by
GNU/kFreeBSD
And this part replaces the debian patch 70_hppa_ldcw_fix.diff.
Maybe you could name this one 71_hppa_ldcw_fix.diff and add it to the
to-be-applied patches list?
Benefit of my version is, that the q_ldcw() assembler statement will be
inlined any will perform better than a call to an external funtion.
diff -up ./src/corelib/arch/parisc/arch.pri.org
./src/corelib/arch/parisc/arch.pri
--- ./src/corelib/arch/parisc/arch.pri.org 2008-04-28 15:11:18.0
+0200
+++ ./src/corelib/arch/parisc/arch.pri 2008-06-10 00:19:10.0 +0200
@@ -1,5 +1,7 @@
#
# HP PA-RISC architecture
#
-SOURCES += $$QT_ARCH_CPP/q_ldcw.s \
- $$QT_ARCH_CPP/qatomic_parisc.cpp
+
+hpux*: SOURCES += $$QT_ARCH_CPP/q_ldcw.s
+
+SOURCES += $$QT_ARCH_CPP/qatomic_parisc.cpp
diff -up ./src/corelib/arch/parisc/qatomic_parisc.cpp.org
./src/corelib/arch/parisc/qatomic_parisc.cpp
--- ./src/corelib/arch/parisc/qatomic_parisc.cpp.org 2008-06-10
00:02:32.0 +0200
+++ ./src/corelib/arch/parisc/qatomic_parisc.cpp 2008-06-10
00:09:54.0 +0200
@@ -72,7 +72,21 @@ static int *align16(int *lock)
extern C {
+#if defined(Q_OS_LINUX)
+#if defined(__LP64__)
+ #define __LDCW ldcw,co
+#else
+ #define __LDCW ldcw
+#endif
+#define q_ldcw(addr) ({\
+ unsigned __ret; \
+ __asm__ __volatile__(__LDCW 0(%1),%0 \
+ : =r (__ret) : r (addr)); \
+ __ret; \
+ })
+#else /* for HP/UX */
int q_ldcw(volatile int *addr);
+#endif
void q_atomic_lock(int *lock)
{
Full patch attached as well, just in case my mailer breaks the lines.
Could you test it ? Do you need more ?
Best regards,
Helge
diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 2008-06-11 23:34:12.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff 2008-06-11 23:34:23.0 +0200
@@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t
+ UNAME_MACHINE=armv5tel
+ ;;
+ hppa)
-+ UNAME_MACHINE=parisc64
++ UNAME_MACHINE=parisc
+ ;;
+ hurd-i386)
+ UNAME_MACHINE=i686-AT386
diff -up ./debian/rules.org ./debian/rules
KDM slowdown in KDE 3.1 debian packages solution
I'm running KDE 3.1 on a slow machine (160MHz PA-RISC CPU) and noticed, that during startup of KDM krootimage is run twice and thus made the startup even slower. Since krootimage loads debian's default background image this involves a lot of graphics conversion (incl. the memory footprint) and running this application twice without any benefit makes the bootup even slower. After some small searching, I found the reason: On debian krootimage is started by default by KDM _and_ by /etc/kde3/kdm/Xsetup: rdi:/# grep -r krootimage etc/* etc/kde3/kdm/Xresources:! another background renderer than krootimage. In this case you'll need etc/kde3/kdm/Xsetup:/usr/bin/krootimage /etc/kde3/kdm/backgroundrc etc/kde3/kdm/kdmrc:# If true, krootimage will be automatically started by KDM. Otherwise, the etc/kde3/kdm/kdmrc:# The configuration file to be used by krootimage. /etc/kde3/kdm/kdmrc says: # If true, krootimage will be automatically started by KDM. Otherwise, the # Setup script should be used to setup the background. Default is true # UseBackground=false so changing (uncommenting) the line in /etc/kde3/kdm/kdmrc with UseBackground to UseBackground=false solved this performance problem without any regression. Could maybe someone modify the debian package to default with this variable set to false ? Thanks, Helge
