Bug#917066: libqbscore1.12: log-level debug causes segfault
On 2018-12-22 21:56 +0300, Dmitry Shachnev wrote: > Hi Wookey! > > On Sat, Dec 22, 2018 at 03:06:21AM +0000, Wookey wrote: > > Enabling --log-level debug (or using --more-verbose) (in the build of > > dewalls) causes the build to fail with a segfault. > > > > This has been discussed upstream and a fix for the null pointer > > dereference produced. Please apply the attached patch to the package > > until the next release when you should be able to drop this patch. > > > > Details are in this thread: > > https://lists.qt-project.org/pipermail/qbs/2018-December/002290.html > > (some of it was not copied to the list) > > Patch committed, thanks! > > I don’t see it applied in upstream Git yet, not even submitted to > https://codereview.qt-project.org. Can you please ask upstream to do so? I only confirmed to Christian K that it worked yesterday (shortly before I filed the debian bug) so I don't think he's had time to apply it yet. I expect he'll do so soonish (modulo Xmas). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#917066: libqbscore1.12: log-level debug causes segfault
Package: libqbscore1.12
Version: 1.12.1
Severity: normal
Tags: patch upstream
Enabling --log-level debug (or using --more-verbose) (in the build of
dewalls) causes the build to fail with a segfault.
This has been discussed upstream and a fix for the null pointer
dereference produced. Please apply the attached patch to the package until the
next
release when you should be able to drop this patch.
Details are in this thread:
https://lists.qt-project.org/pipermail/qbs/2018-December/002290.html
(some of it was not copied to the list)
You can reproduce/test it as follows:
Install the debug version of libqbscore1.12. Get the dewalls package,
unpack it, cd into it and run dpkg-buildpackage so the 'deb' profile is set up.
then run
qbs build --settings-dir /tmp --log-level debug --command-echo-mode
command-line --no-install
profile:deb
modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp
project.libDir:lib/x86_64-linux-gnu config:qbs-build
You'll need to adjust the installRoot path.
it fails with:
qbs.moduleloader:
Resolving Probe at "/usr/share/qbs/modules/bundle/BundleModule.qbs:46:5"
qbs.moduleloader: Probe disabled; skipping
qbs.moduleloader: reset instance scope of module "Qt.core" in property
"cxxFlags" of module ("cpp")
Thread 3 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff72e89700 (LWP 16286)]
0x778ca457 in QStringRef::toString() const () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Description: Fix for segfault with --log-level debug
A segfault can occur when the debug logging level is enabled if the
'sourceCode' value is null.
Origin: upstream
https://lists.qt-project.org/pipermail/qbs/2018-December/002292.html
Bug-Debian: https://bugs.debian.org/
Reviewed-By: woo...@debian.org
Last-Update: 2018-12-21
--- qbs-1.12.2+dfsg.orig/src/lib/corelib/language/moduleloader.cpp
+++ qbs-1.12.2+dfsg/src/lib/corelib/language/moduleloader.cpp
@@ -2341,9 +2341,11 @@ void ModuleLoader::adjustDefiningItemsIn
<< ", old defining item was " << v->definingItem()
<< " with scope" << v->definingItem()->scope()
<< ", new defining item is" << replacement
-<< " with scope" << replacement->scope()
-<< ", value source code is "
+<< " with scope" << replacement->scope();
+if (v->type() == Value::JSSourceValueType) {
+qCDebug(lcModuleLoader) << "value source code is"
<<
std::static_pointer_cast(v)->sourceCode().toString();
+}
replacement->setPropertyDeclaration(propName, decl);
replacement->setProperty(propName, v);
} else {
Bug#773884: qtxmlpatterns-opensource-src: FTBFS on arm64
Package: qtxmlpatterns-opensource-src
Version: 5.4.0-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertag: arm64
This package seems to have a problem building on arm64.
It has failed twice on the autobuilders, although not with exactly the same
issue:
It built OK on a porterbox, according to
https://lists.debian.org/debian-wb-team/2014/12/msg00010.html
The previous version built OK.
Do the failures below give any clues as to might be wrong? They seem
similar but not identical. Is there parallelism in this build making
it less obvious which test is actually at fault?
Clues about what this is testing and how to re-run just the tests
manually would be helpful to see if this can be reproduced at all.
Build:https://buildd.debian.org/status/fetch.php?pkg=qtxmlpatterns-opensource-src&archhttps://buildd.debian.org/status/fetch.php?pkg=qtxmlpatterns-opensource-src&arch=arm64&ver=5.4.0-1&stamp=1418732066
make[4]: Leaving directory '/«PKGBUILDDIR»/tests/auto'
PASS :
tst_CheckXMLFiles::checkXMLFiles(/«PKGBUILDDIR»/tests/auto/xmlpatternsschemats/Baseline.xml)
PASS :
tst_CheckXMLFiles::checkXMLFiles(/«PKGBUILDDIR»/tests/auto/xmlpatternssdk/docs/XMLIndenterExampleResult.xml)
PASS :
tst_CheckXMLFiles::checkXMLFiles(/«PKGBUILDDIR»/tests/auto/xmlpatternssdk/docs/XMLWriterExampleResult.xml)
Error XSDError in Unknown location, at line 1, column 0: Premature end of
document.
PASS : tst_QXmlSchema::loadSchemaUrlFail()
PASS : tst_QXmlSchemaValidator::loadInstanceUrlFail()
PASS : tst_QXmlSchema::loadSchemaDeviceSuccess()
QWARN : tst_QXmlSchema::loadSchemaDeviceFail() The device must be readable.
PASS : tst_QXmlSchema::loadSchemaDeviceFail()
PASS : tst_QXmlSchemaValidator::loadInstanceDeviceSuccess()
PASS : tst_QXmlSchema::loadSchemaDataSuccess()
QWARN : tst_QXmlSchemaValidator::loadInstanceDeviceFail() The device must be
readable.
PASS : tst_QXmlSchemaValidator::loadInstanceDeviceFail()
terminate called after throwing an instance of 'bool'
PASS : tst_QXmlSchemaValidator::loadInstanceDataSuccess()
Aborted
make[4]: *** [check] Error 134
Makefile:268: recipe for target 'check' failed
make[4]: Leaving directory '/«PKGBUILDDIR»/tests/auto/qxmlschema
=arm64&ver=5.4.0-1&stamp=1419353311
make[4]: Entering directory '/«PKGBUILDDIR»/tests/auto/qxmlschema'
QT_PLUGIN_PATH=/usr/lib/aarch64-linux-gnu/qt5/plugins
LD_LIBRARY_PATH=/«PKGBUILDDIR»/lib:/usr/lib/aarch64-linux-gnu${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
./tst_qxmlschema
* Start testing of tst_QXmlSchema *
Config: Using QtTest library 5.4.0, Qt 5.4.0 (arm64-little_endian-lp64 shared
(dynamic) release build; by GCC 4.9.1)
PASS : tst_QXmlSchema::initTestCase()
PASS : tst_QXmlSchema::defaultConstructor()
PASS : tst_QXmlSchema::copyConstructor()
PASS : tst_QXmlSchema::constructorQXmlNamePool()
PASS : tst_QXmlSchema::copyMutationTest()
PASS : tst_QXmlSchema::isValid()
PASS : tst_QXmlSchema::documentUri()
PASS : tst_QXmlSchema::loadSchemaUrlSuccess()
PASS : tst_QXmlSchema::loadSchemaUrlFail()
PASS : tst_QXmlSchema::loadSchemaDeviceSuccess()
QWARN : tst_QXmlSchema::loadSchemaDeviceFail() The device must be readable.
PASS : tst_QXmlSchema::loadSchemaDeviceFail()
PASS : tst_QXmlSchema::loadSchemaDataSuccess()
Error XSDError in Unknown location, at line 1, column 0: Premature end of
document.
terminate called after throwing an instance of 'bool'
Aborted
Makefile:268: recipe for target 'check' failed
make[4]: *** [check] Error 134
make[4]: Leaving directory '/«PKGBUILDDIR»/tests/auto/qxmlschema'
-- System Information:
Debian Release: 7.7
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.60-kvm-i386-20140609 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
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/20141224190554.19202.92707.report...@stoneboat.aleph1.co.uk
Bug#735488: qt4-x11: Add arm64 support
+++ Lisandro Damián Nicanor Pérez Meyer [2014-08-16 12:04 -0300]: > WRT the mkspecs changes I am currently asking upstream if adding an mkspec > just for getting rid of -m64 is the right way to go. Maybe we can add an > exception somewhere without the need of adding another mkspec. Yes. I think that can be done better. I didn't add that mkspec :-) I suspect it can be removed, but I don't know the codebase well enough to decide exctly how. -m64 is bad practice anyway IMHO. Compilers should use -gcc everywhere and it would just work, and be unambiguous, instead of various different flags for 'some other multilib' on various compilers/cross-compilers. Sadly it's probably too ingrained to get rid of on x86. 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: https://lists.debian.org/20140820220047.gx19...@stoneboat.aleph1.co.uk
Bug#735488: qt4-x11: Add arm64 support
+++ Lisandro Damián Nicanor Pérez Meyer [2014-08-15 22:05 -0300]:
> I was really expecting this mail :)
>
> First of all, allow me to congratulate you an the rest of the arm64 porters
> for it's inclusion in the archive :)
Cheers. We're making good progress there.
> This is a "quick and dirty" mail to let you know that I'm looking at this,
> but
> please give me some time to check this facts. Tip: I'm not currently very
> available, so it might take me time, although some of my team mates might
> show
> up too.
Cheers. I am at bootstrap sprint for next 4 days. Then debconf 3 days after
that.
> On Friday 15 August 2014 23:46:19 Wookey wrote:
> [snip]
> > OK. So I've brought the atomic queries to the attention of Steve
> > Capper, who understands this stuff. He observed that the memory
> > barriers are not the right type. They'll work (as they are the 'mos
> > expensive' type) but will be slower than is necessary. Hopefully he'll
> > find time to have a look at that reasonably soon, but he's a busy man
> > at the moment.
>
> To be honest this is not what I remember, IIRC they will not work. But I'll
> double check the comments upstream did to the patches.
OK. Steve was planning to comment there too.
> > In an attempt to solve the -fpermissive thing, I updated the patches
> > for the current qt4-x11 package to try and get an example build log
> > (without -fpermissive) to wave at people who grokked C++ and
> > arm64. This involved some tweaking of the arch/ABI identification
> > logic wich was bust and by using dpkg_arch ('arm64') in place of uname
> > -m ('aarch64') then checking for arm* later, it incorrectly identified
> > the ABI as 'arm' and tried to build wrong assembler. So I've fixed
> > that up to not use the hacky mechanism and re-order the checks/extend
> > the regeps so both arm64 and aarch64 end up pointing at QTs internel
> > 'aarch64', and other arm* names refer to QTs internal 'arm'.
> >
> > And now it seems that the -fpermissive problem has gone away. The
> > package builds without -fpermissive on arm64 (maybe updated compiler,
> > maybe updated sources, maybe updated something else - who knows?
>
>
> \o/ I skimmed trough the patch an indeed it seems sensible. Moreover, it has
> high chances of getting upstreamed. Did you do this part of the patch (namely
> the part that touches configure)?
Yes. I hereby licence my (minor changes to existing work) under BSD or expat.
> You know that I would *love* to get this upstreamed but in order to do so I
> need to:
>
> a) in case the patch is really simple or not really copyrighteable I might
> push it directly. But it is much much better if at least I can write down who
> the original coder was.
I just adjusted the existing configure stuff so it was right. I
removed 3 lines, swapped position of 4 lines and changed a regexp. I
don't think that's copyrightable, and you already have suitable
licence on the previous patch.
> b) In the case the patch is copyrighteable (ie, just not a couple of
> "obvious"
> changes) I need to find the original coder and convince him/her to either:
>
> b1) push the patch him/herself to upstream's gerrit instance (preferred
> because it allows upstream to make questions or ask for changes directly to
> the people who code them).
>
> b2) publicly announce (could be a mail to this very same bug, a gined mail
> is a plus) that the patch is licensed with a permissive enough license like
> some BSD one. The downside of this approach is that in case upstream finds
> something they don't like I need to be a proxy between them.
>
> I would really *love* if you can help me with this, as I don't know exactly
> who did what (I might infer some of that data from the previous splitted
> patches).
I just took the previous patch and made above changes.
> > Anyway I guess we can call it fixed until we see evidence otherwise.
>
> Definitely.
>
> > Attached is current patch (obviously with atomics stuff unchanged)
> >
> > (The nice neat separated patches did not work for me and I've not had
> > time to separate this one out into nice pieces, sorry).
>
> No problem, I'll take care of it.
>
> > Can we upload this so we at least have a working package in the
> > archive (which will very soon be needed by our nice new official
> > buildds), and refine the atomics patch for upstreaming in due course?
>
> Please allow me to recheck the assertion wrt the atomic stuff. If I'm
> remembering right and the atomic
Bug#735488: qt4-x11: Add arm64 support
Package: src:qt4-x11
Followup-For: Bug #735488
OK. So I've brought the atomic queries to the attention of Steve
Capper, who understands this stuff. He observed that the memory
barriers are not the right type. They'll work (as they are the 'mos
expensive' type) but will be slower than is necessary. Hopefully he'll
find time to have a look at that reasonably soon, but he's a busy man
at the moment.
In an attempt to solve the -fpermissive thing, I updated the patches
for the current qt4-x11 package to try and get an example build log
(without -fpermissive) to wave at people who grokked C++ and
arm64. This involved some tweaking of the arch/ABI identification
logic wich was bust and by using dpkg_arch ('arm64') in place of uname
-m ('aarch64') then checking for arm* later, it incorrectly identified
the ABI as 'arm' and tried to build wrong assembler. So I've fixed
that up to not use the hacky mechanism and re-order the checks/extend
the regeps so both arm64 and aarch64 end up pointing at QTs internel
'aarch64', and other arm* names refer to QTs internal 'arm'.
And now it seems that the -fpermissive problem has gone away. The
package builds without -fpermissive on arm64 (maybe updated compiler,
maybe updated sources, maybe updated something else - who knows?
Anyway I guess we can call it fixed until we see evidence otherwise.
Attached is current patch (obviously with atomics stuff unchanged)
(The nice neat separated patches did not work for me and I've not had
time to separate this one out into nice pieces, sorry).
Can we upload this so we at least have a working package in the
archive (which will very soon be needed by our nice new official
buildds), and refine the atomics patch for upstreaming in due course?
--
Wookey
diff -Nru qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog
--- qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog 2014-07-25 17:07:51.0 +
+++ qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog 2014-08-14 11:25:08.0 +
@@ -1,3 +1,10 @@
+qt4-x11 (4:4.8.6+git49-gbc62005+dfsg-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add arm64/aarch64 support
+
+ -- Wookey Thu, 14 Aug 2014 11:24:00 +
+
qt4-x11 (4:4.8.6+git49-gbc62005+dfsg-1) unstable; urgency=medium
* New upstream GIT snapshot.
diff -Nru qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install
--- qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install 2014-07-25 16:54:39.0 +
+++ qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install 2014-08-15 10:19:56.0 +
@@ -161,6 +161,7 @@
usr/include/qt4/Qt/qanimationgroup.h
usr/include/qt4/Qt/qapplication.h
usr/include/qt4/Qt/qatomic.h
+usr/include/qt4/Qt/qatomic_aarch64.h
usr/include/qt4/Qt/qatomic_alpha.h
usr/include/qt4/Qt/qatomic_arch.h
usr/include/qt4/Qt/qatomic_arm.h
@@ -1345,6 +1346,7 @@
usr/include/qt4/QtCore/qalgorithms.h
usr/include/qt4/QtCore/qanimationgroup.h
usr/include/qt4/QtCore/qatomic.h
+usr/include/qt4/QtCore/qatomic_aarch64.h
usr/include/qt4/QtCore/qatomic_alpha.h
usr/include/qt4/QtCore/qatomic_arch.h
usr/include/qt4/QtCore/qatomic_arm.h
diff -Nru qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch
--- qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch 1970-01-01 00:00:00.0 +
+++ qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch 2014-08-15 10:36:18.0 +
@@ -0,0 +1,619 @@
+Index: qt4-x11-4.8.6+git49-gbc62005+dfsg/configure
+===
+--- qt4-x11-4.8.6+git49-gbc62005+dfsg.orig/configure
qt4-x11-4.8.6+git49-gbc62005+dfsg/configure
+@@ -2856,6 +2856,9 @@ if [ "$CFG_EMBEDDED" != "no" ]; then
+ *86_64)
+ PLATFORM=qws/linux-x86_64-g++
+ ;;
++aarch64)
++PLATFORM=linux-g++-aarch64
++;;
+ *)
+ PLATFORM=qws/linux-generic-g++
+ ;;
+@@ -3289,18 +3292,18 @@ if [ -z "${CFG_HOST_ARCH}" ]; then
+ fi
+ CFG_HOST_ARCH=s390
+ ;;
+-*:*:arm*)
+-if [ "$OPT_VERBOSE" = "yes" ]; then
+-echo "ARM (arm)"
+-fi
+-CFG_HOST_ARCH=arm
+-;;
+-*:*:aarch64*)
++*:*:aarch64*|*:*:arm64*)
+ if [ "$OPT_VERBOSE" = "yes" ]; then
+ echo "AArch64 (aarch64)"
+ fi
+ CFG_HOST_ARCH=aarch64
+ ;;
++*:*:arm*)
++if [ "$OPT_VERBOSE" = "yes" ]; then
++echo "ARM (arm)"
++fi
++
Bug#757639: qtwebkit: FTBFS on arm64
Package: qtwebkit Version: 2.2.1-7 Severity: serious Tags: upstream patch Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertag: arm64 qtwebkit does not build on arm64 (which is (just) now in the main archive). The simple attached patch fixes this issue. It was actually done a couple of months ago but I apparently failed to file this bug, mostly because there were two versions upstream and I thought I should check both out. I see there has been an NMU since then. I'll check that this still works OK with that. Then plan to do an NMU in order to unblock arm64 builds. Wookey diff -Nru qtwebkit-2.2.1/debian/changelog qtwebkit-2.2.1/debian/changelog --- qtwebkit-2.2.1/debian/changelog 2013-11-05 01:15:31.0 + +++ qtwebkit-2.2.1/debian/changelog 2014-06-08 00:20:13.0 + @@ -1,3 +1,10 @@ +qtwebkit (2.2.1-7+arm64) unreleased; urgency=low + + * Non-maintainer upload. + * Add basic arm64/aarch64 support + + -- Wookey Sun, 08 Jun 2014 00:19:24 + + qtwebkit (2.2.1-7) unstable; urgency=low [ Nobuhiro Iwamatsu ] diff -Nru qtwebkit-2.2.1/debian/patches/arm64-support.diff qtwebkit-2.2.1/debian/patches/arm64-support.diff --- qtwebkit-2.2.1/debian/patches/arm64-support.diff 1970-01-01 00:00:00.0 + +++ qtwebkit-2.2.1/debian/patches/arm64-support.diff 2014-06-08 00:41:24.0 + @@ -0,0 +1,33 @@ +Description: Add arm64/aarch64 support + Add basic aarch64 suport +Author: Wookey +Origin: Linaro, https://bugs.launchpad.net/linaro-aarch64/+bug/1096053/+attachment/3482961/+files/aarch64.patch +Bug: https://bugs.launchpad.net/linaro-aarch64/+bug/1096053 +Last-Update: <2014-06-07 + +Index: qtwebkit-2.2.1/Source/JavaScriptCore/wtf/Platform.h +=== +--- qtwebkit-2.2.1.orig/Source/JavaScriptCore/wtf/Platform.h qtwebkit-2.2.1/Source/JavaScriptCore/wtf/Platform.h +@@ -369,6 +369,11 @@ + #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1 + #endif + ++/* CPU(AARCH64) - Aarch64 */ ++#if defined(__aarch64__) ++#define WTF_CPU_AARCH64 1 ++#endif ++ + /* OS() - underlying operating system; only to be used for mandated low-level services like +virtual memory, not to choose a GUI toolkit */ + +@@ -998,7 +1003,8 @@ + || CPU(ALPHA) \ + || CPU(SPARC64) \ + || CPU(S390X) \ +-|| CPU(PPC64) ++|| CPU(PPC64) \ ++|| CPU(AARCH64) + #define WTF_USE_JSVALUE64 1 + #else + #define WTF_USE_JSVALUE32_64 1 diff -Nru qtwebkit-2.2.1/debian/patches/series qtwebkit-2.2.1/debian/patches/series --- qtwebkit-2.2.1/debian/patches/series 2013-07-24 03:29:27.0 + +++ qtwebkit-2.2.1/debian/patches/series 2014-06-08 00:38:36.0 + @@ -18,3 +18,4 @@ hurd.diff webkit_qt_hide_symbols.diff ignore-unused-local-typedefs_error.diff +arm64-support.diff
Bug#746916: soprano: ftbfs with GCC-4.9
I tested the version currently in deferred (soprano_2.9.4+dfsg-1.1.dsc) on arm64 and it builds OK there. It's not the same patch as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752112 but largely the same symbols are involved. My arm64 patch makes them all "(optional=internal)". This one just removes them. My understanding of c++ symbols is such that I don't know which is better (or whether the arm64 fix works on mips64). But either fix makes the package satisfactory on arm64 so is OK with me. Hope this is a useful datapoint. 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: https://lists.debian.org/20140703225212.gw10...@stoneboat.aleph1.co.uk
Bug#744257: attica: FTBFS on arm64 (symbols issue)
+++ Pino Toscano [2014-04-12 09:08 +0200]:
> The patch is indeed wrong, and should not be applied.
>
> If you want more help on the issue, please do post a full build log.
So, as discussed, attica does in fact build fine on arm64 without any
changes. However, because of the way debian-ports works, the arm64
port now needs a version-bump of this package.
I originally uploaded a version 0.4.2-1+arm64 to the 'unreleased'
debian-ports repo to get builds depending on attica going. But that
turned out to be unnecessary. However, the kosher build of attica can
not now upload to plain debian-ports ('unstable') because it has a
lower version number (0.4.2-1) than the 0.4.2-1+arm64 in
unreleased. Only a new upload of attica with a version bump can fix
this. I am happy to do this myself as an NMU as I
made the work, but if you'd prefer to just do a 0.4.2-2 upload that
would be great. Sorry for the faff.
As you can see from
http://buildd.debian-ports.org/status/package.php?p=attica&suite=sid a
correct version was uploaded 19 days ago, but it will not install due
to above versionitis.
cheers
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: https://lists.debian.org/20140630234042.ge10...@stoneboat.aleph1.co.uk
Bug#727419: libnova: diff for NMU version 0.14.0-2.1
tags 727419 + patch tags 727419 + pending thanks Dear maintainer, This bug has been pending for some time, and needs fixing for new ports, including arm64 which is building now: (http://buildd.debian-ports.org/status/architecture.php?a=arm64&suite=sid). So I've prepared an NMU for libnova (versioned as 0.14.0-2.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Discussion on debian-devel revealed consensus that the right way to ensure successful builds on all new architectures was to autoreconf packages, so that method has been used to fix this bug. This works for all arches, even those that need libtool changes, and will continue to work into the future without an update as each new arch comes along. (Discussion at https://lists.debian.org/debian-devel/2014/04/msg00383.html, thread starting at https://lists.debian.org/debian-devel/2014/04/msg00342.html As you can see this works fine on this package, and is a very simple patch. Cheers. diff -Nru libnova-0.14.0/debian/changelog libnova-0.14.0/debian/changelog --- libnova-0.14.0/debian/changelog 2012-03-25 13:51:48.0 +0100 +++ libnova-0.14.0/debian/changelog 2014-06-23 00:12:48.0 +0100 @@ -1,3 +1,10 @@ +libnova (0.14.0-2.1) unstable; urgency=low + + * Non-maintainer upload. + * Use dh-autoreconf in build to support new architectures (closes: #727419) + + -- Chen Baozi Thu, 05 Jun 2014 20:27:12 +0800 + libnova (0.14.0-2) unstable; urgency=low * Team upload. Upload to unstable. diff -Nru libnova-0.14.0/debian/control libnova-0.14.0/debian/control --- libnova-0.14.0/debian/control 2012-03-18 09:29:59.0 + +++ libnova-0.14.0/debian/control 2014-06-05 13:26:58.0 +0100 @@ -2,7 +2,7 @@ Section: libs Priority: optional Maintainer: Debian Krap Maintainers -Build-Depends: debhelper (>= 9), autotools-dev +Build-Depends: debhelper (>= 9), autotools-dev, dh-autoreconf Standards-Version: 3.9.3 Uploaders: Sune Vuorela Homepage: http://libnova.sourceforge.net/ diff -Nru libnova-0.14.0/debian/rules libnova-0.14.0/debian/rules --- libnova-0.14.0/debian/rules 2012-03-18 09:46:28.0 + +++ libnova-0.14.0/debian/rules 2014-06-05 13:26:45.0 +0100 @@ -1,7 +1,7 @@ #!/usr/bin/make -f %: - dh $@ + dh $@ --with autoreconf override_dh_auto_test: dh_auto_test
Bug#752112: soprano: FTBFS on arm64 due to symbols file variance
Source: soprano Version: 2.9.4+dfsg-1 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertag: arm64 This package FTBFS on arm64 due to the symbols file not matching. The build failure log is at http://wookware.org/files/soprano_2.9.4+dfsg-1_arm64-20140611-2012 Thanks to some help from Sune Vuorela to explain the issue I've marked the missing symbols as (optional=internal). It's not entirely clear why these symbols come out different on this arch, but as it's down to toolchain variation it seems like this marking is a sensible way to fix it. This builds fine on arm64 and amd64 with the attached patch applied. This is an important package blocking kde4libs and thus all of kde so a quick upload would be apreciated, or I am hapy to NMU it for you. Thanks -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -Nru soprano-2.9.4+dfsg/debian/changelog soprano-2.9.4+dfsg/debian/changelog --- soprano-2.9.4+dfsg/debian/changelog 2013-11-04 15:13:52.0 + +++ soprano-2.9.4+dfsg/debian/changelog 2014-06-18 17:13:51.0 + @@ -1,3 +1,10 @@ +soprano (2.9.4+dfsg-1+arm64) unreleased; urgency=low + + * Non-maintainer upload. + * Adjust symbols file for arm64 build + + -- Wookey Wed, 18 Jun 2014 17:12:47 + + soprano (2.9.4+dfsg-1) unstable; urgency=low * New upstream release. diff -Nru soprano-2.9.4+dfsg/debian/libsoprano4.symbols soprano-2.9.4+dfsg/debian/libsoprano4.symbols --- soprano-2.9.4+dfsg/debian/libsoprano4.symbols 2013-11-04 15:13:52.0 + +++ soprano-2.9.4+dfsg/debian/libsoprano4.symbols 2014-06-18 17:12:22.0 + @@ -1163,9 +1163,9 @@ _ZN7Soprano5Query20BooleanSetExpression7PrivateD2Ev@Base 2.1.1 _ZN7Soprano5Query20BooleanSetExpressionC1Ev@Base 2.1.1 _ZN7Soprano5Query20BooleanSetExpressionC2Ev@Base 2.1.1 - _ZN7Soprano5Query20BooleanSetExpressionD0Ev@Base 2.7.0 - _ZN7Soprano5Query20BooleanSetExpressionD1Ev@Base 2.7.0 - _ZN7Soprano5Query20BooleanSetExpressionD2Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query20BooleanSetExpressionD0Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query20BooleanSetExpressionD1Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query20BooleanSetExpressionD2Ev@Base 2.7.0 _ZN7Soprano5Query20NumericalGreaterThanC1EPNS0_19NumericalExpressionES3_@Base 2.1.1 _ZN7Soprano5Query20NumericalGreaterThanC2EPNS0_19NumericalExpressionES3_@Base 2.1.1 _ZN7Soprano5Query20NumericalGreaterThanD0Ev@Base 2.7.0 @@ -1196,9 +1196,9 @@ _ZN7Soprano5Query22UnaryBooleanExpression7PrivateD2Ev@Base 2.1.1 _ZN7Soprano5Query22UnaryBooleanExpressionC1EPNS0_17BooleanExpressionE@Base 2.1.1 _ZN7Soprano5Query22UnaryBooleanExpressionC2EPNS0_17BooleanExpressionE@Base 2.1.1 - _ZN7Soprano5Query22UnaryBooleanExpressionD0Ev@Base 2.7.0 - _ZN7Soprano5Query22UnaryBooleanExpressionD1Ev@Base 2.7.0 - _ZN7Soprano5Query22UnaryBooleanExpressionD2Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query22UnaryBooleanExpressionD0Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query22UnaryBooleanExpressionD1Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query22UnaryBooleanExpressionD2Ev@Base 2.7.0 _ZN7Soprano5Query23queryLanguageFromStringERK7QString@Base 2.1.1 _ZN7Soprano5Query24DateTimeGreaterThanEqualC1ERK9QDateTimeS4_@Base 2.1.1 _ZN7Soprano5Query24DateTimeGreaterThanEqualC2ERK9QDateTimeS4_@Base 2.1.1 @@ -1214,9 +1214,9 @@ _ZN7Soprano5Query24UnaryNumericalExpression7PrivateD2Ev@Base 2.1.1 _ZN7Soprano5Query24UnaryNumericalExpressionC1EPNS0_19NumericalExpressionE@Base 2.1.1 _ZN7Soprano5Query24UnaryNumericalExpressionC2EPNS0_19NumericalExpressionE@Base 2.1.1 - _ZN7Soprano5Query24UnaryNumericalExpressionD0Ev@Base 2.7.0 - _ZN7Soprano5Query24UnaryNumericalExpressionD1Ev@Base 2.7.0 - _ZN7Soprano5Query24UnaryNumericalExpressionD2Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query24UnaryNumericalExpressionD0Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query24UnaryNumericalExpressionD1Ev@Base 2.7.0 + (optional=internal)_ZN7Soprano5Query24UnaryNumericalExpressionD2Ev@Base 2.7.0 _ZN7Soprano5Query24UnaryRTermExpressionBase7PrivateC1EPNS0_5RTermE@Base 2.1.1 _ZN7Soprano5Query24UnaryRTermExpressionBase7PrivateC1ERKS2_@Base 2.1.1 _ZN7Soprano5Query24UnaryRTermExpressionBase7PrivateC2EPNS0_5RTermE@Base 2.1.1 @@ -1236,9 +1236,9 @@ _ZN7Soprano5Query25BinaryNumericalExpression9setSecondEPNS0_19NumericalExpressionE@Base 2.1.1 _ZN7Soprano5Query25BinaryNumericalExpressionC1EPNS0_19NumericalExpressionES3_@Base 2.1.1 _ZN7Soprano5Query25BinaryNumericalExpressionC2EPNS0_19NumericalExpressionES3_@Base 2.1.1 - _ZN7Soprano5Query25BinaryNumericalExpressionD0Ev@Base 2.7.0 - _ZN7Soprano5Query25BinaryNumericalExpressionD1Ev@Base 2.7.0 - _ZN7Soprano5Query25BinaryNumericalExpressionD2Ev@Base 2
Bug#750047: qtbase-opensource-src: Fix FTBFS on arm64
Package: qtbase-opensource-src Version: 5.2.1+dfsg-3 Severity: important Tags: patch User: debian-...@lists.debian.org Usertag: arm64 qtbase-opensource-src fails to build on arm64. (see http://buildd.debian-ports.org/status/fetch.php?pkg=icedove&arch=arm64&ver=30.0%7Eb1-1&stamp=1401496681) The attached patch fixes the issues. The arm64 porters would appreciate an upload containing this patch reasonably soon as qt5 has a lot of rdepends. thanks -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -Nru qtbase-opensource-src-5.2.1+dfsg/debian/changelog qtbase-opensource-src-5.2.1+dfsg/debian/changelog --- qtbase-opensource-src-5.2.1+dfsg/debian/changelog 2014-03-24 23:05:46.0 + +++ qtbase-opensource-src-5.2.1+dfsg/debian/changelog 2014-05-31 21:50:31.0 + @@ -1,3 +1,12 @@ +qtbase-opensource-src (5.2.1+dfsg-3+arm64) unreleased; urgency=medium + + * arm64 changes cherry picked from ubuntu ++ Add arm64 to list of 64-bit architectures that should not use -m64 ++ Add arm64 to list of architectures that should not use pch + * Remove .device.vars and .qmake.vars in clean target. + + -- Peter Michael Green Thu, 29 May 2014 15:12:55 + + qtbase-opensource-src (5.2.1+dfsg-3) unstable; urgency=medium * Release to unstable. diff -Nru qtbase-opensource-src-5.2.1+dfsg/debian/rules qtbase-opensource-src-5.2.1+dfsg/debian/rules --- qtbase-opensource-src-5.2.1+dfsg/debian/rules 2014-02-24 15:06:11.0 + +++ qtbase-opensource-src-5.2.1+dfsg/debian/rules 2014-05-31 21:50:31.0 + @@ -48,7 +48,7 @@ extra_configure_opts += -no-sql-ibase endif -no_pch_architectures := armel armhf ia64 +no_pch_architectures := armel armhf ia64 arm64 ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), $(no_pch_architectures))) extra_configure_opts += -no-pch endif @@ -65,7 +65,7 @@ endif ifeq ($(DEB_HOST_ARCH_OS),linux) - ifneq (,$(filter $(DEB_HOST_ARCH),alpha ia64 mips64 mips64el)) + ifneq (,$(filter $(DEB_HOST_ARCH),alpha ia64 mips64 mips64el arm64)) platform_arg = linux-g++ else ifeq ($(DEB_HOST_ARCH_BITS),64) platform_arg = linux-g++-64 @@ -198,6 +198,9 @@ rm -f debian/shlibs.local rm -f debian/stamp-makefile-build-tools + # more leftovers + rm -f .device.vars .qmake.vars + ifeq ($(vendor),Ubuntu) rm -rf po endif
Bug#744173: pkg-kde-tools: add arm64 support to SymbolsHelper
+++ Lisandro Damián Nicanor Pérez Meyer [2014-04-12 10:41 -0300]: > On Saturday 12 April 2014 10:07:35 Maximiliano Curia wrote: > > ¡Hola Wookey! > > > > El 2014-04-11 a las 23:29 +0100, Wookey escribió: > > > I read here: https://lists.debian.org/debian-68k/2013/11/msg00012.html > > > that in QT5 qreal is a double on armhf, but on QT4 it's a float (and > > > it's float on both for armel). Can this helper know which it is doing > > > and DTRT? If not which should be the default? > > There is simply no need for the helper to know the right substitution because > you should not have symbols from Qt4 and Qt5 in the same symbols file. I don't understand this part. Yes, we are not mixing the QT versions, but won't the same pkg-kde-tools helper be used whichever library is in use so it need to hand outthe right answers depending which library is being linked. Or do I misunderstand how this this is used? > The substitutions are rarely added by hand on symbols, they are simply > detected by the helper when two different archs' build logs differ, as it's > the case for Qt4. > > In Qt5 there will be no symbols mismatch between archs for qreal, so no > substitution will be added and no further action is needed. I thought that armel and armhf were going to be different (from each other). Did that change so everything uses double? (even sh4?) 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: https://lists.debian.org/20140413021419.gm15...@stoneboat.aleph1.co.uk
Bug#744173: pkg-kde-tools: add arm64 support to SymbolsHelper
+++ Pino Toscano [2014-04-12 09:13 +0200]: > On 2014-04-11 04:45, Wookey wrote: > >Package: pkg-kde-tools > >Version: 0.15.13 > >Severity: important > >Tags: patch > >User: debian-...@lists.debian.org > >Usertag: arm64 > > > >SymbolsHelper needs to know about the new 64-bit architecture > >arm64 in > >order for any package that uses the (subst) Symbols file > >functionality > >to be buildable. This patch fixes that. > > Please follow my instructions in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656380#21 > > This will give us a better idea on the various type manglings on arm64. OK. Done that: readelf -a manglingtest | grep _type 84: 0040076820 FUNCGLOBAL DEFAULT 13 _Z14f_int64_t_typel 85: 004007b820 FUNCGLOBAL DEFAULT 13 _Z12f_qreal_typed 90: 0040074020 FUNCGLOBAL DEFAULT 13 _Z13f_size_t_typem 95: 004007a420 FUNCGLOBAL DEFAULT 13 _Z15f_quintptr_typey 108: 0040079020 FUNCGLOBAL DEFAULT 13 _Z15f_qptrdiff_typex 109: 0040075420 FUNCGLOBAL DEFAULT 13 _Z14f_ssize_t_typel 111: 0040077c20 FUNCGLOBAL DEFAULT 13 _Z15f_uint64_t_typem 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: https://lists.debian.org/20140413020952.gl15...@stoneboat.aleph1.co.uk
Bug#744257: attica: FTBFS on arm64 (symbols issue)
+++ Pino Toscano [2014-04-12 09:08 +0200]: > On 2014-04-12 02:46, Wookey wrote: > >Even with the updated kde-pkg-tools patch from > > > >https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=pkg-kde-tools_0.15.13.arm64-subst-fix-2.patch;att=1;bug=744173 > >, > > > >this package doesn't build on arm64, because these two symbols are > >missing from the generated file: > > (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD1Ev@Base > >0.4.0 > > (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD2Ev@Base > >0.4.0 > > > >I don't know what that "(optional=gccinternal)" annotation means, > >although it saying 'optional' suggests to me that having it missing > >shouldn't fail the build, but it does. > > (optional=gccinternal) means a symbol is optional, so its lack won't > cause a build failure. See also dpkg-gensymbols(1). Right. Something else must have caused the build to fail. It does indeed complain about the above but actually complete the build now. > >It can be fixed with the attached patch to declare that these are not > >present on arm64. I don't know if this is the right fix, or if there > >is some other reason for these symbols being missing which we should > >look into? > > The patch is indeed wrong, and should not be applied. > > If you want more help on the issue, please do post a full build log. Well, given that I can now build the unpatched source, I think this bug should just be closed. From my POV this builds OK, and presumably is correct as it stands? Ah yes. I see that other arches spit out this whinge so I guess that's OK. 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: https://lists.debian.org/20140413015456.gk15...@stoneboat.aleph1.co.uk
Bug#744257: attica: FTBFS on arm64 (symbols issue)
Package: attica Version: 0.4.2-1 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertag: arm64 Even with the updated kde-pkg-tools patch from https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=pkg-kde-tools_0.15.13.arm64-subst-fix-2.patch;att=1;bug=744173 , this package doesn't build on arm64, because these two symbols are missing from the generated file: (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD1Ev@Base 0.4.0 (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD2Ev@Base 0.4.0 I don't know what that "(optional=gccinternal)" annotation means, although it saying 'optional' suggests to me that having it missing shouldn't fail the build, but it does. It can be fixed with the attached patch to declare that these are not present on arm64. I don't know if this is the right fix, or if there is some other reason for these symbols being missing which we should look into? As ever guidance is welcome. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash diff -Nru attica-0.4.2/debian/changelog attica-0.4.2/debian/changelog --- attica-0.4.2/debian/changelog 2013-06-24 20:28:52.0 + +++ attica-0.4.2/debian/changelog 2014-04-12 00:17:49.0 + @@ -1,3 +1,10 @@ +attica (0.4.2-1+arm64) unreleased; urgency=low + + * Non-maintainer upload. + * Update symbols file for arm64 + + -- Wookey Sat, 12 Apr 2014 00:16:48 + + attica (0.4.2-1) unstable; urgency=low * New upstream release. diff -Nru attica-0.4.2/debian/libattica0.4.symbols attica-0.4.2/debian/libattica0.4.symbols --- attica-0.4.2/debian/libattica0.4.symbols 2013-06-23 23:48:44.0 + +++ attica-0.4.2/debian/libattica0.4.symbols 2014-04-12 00:16:35.0 + @@ -340,8 +340,8 @@ _ZN6Attica19DownloadDescription4sizeEv@Base 0.4.0 _ZN6Attica19DownloadDescription4typeEv@Base 0.4.0 _ZN6Attica19DownloadDescription5setIdEi@Base 0.4.0 - (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD1Ev@Base 0.4.0 - (optional=gccinternal)_ZN6Attica19DownloadDescription7PrivateD2Ev@Base 0.4.0 + (optional=gccinternal|arch=!arm64)_ZN6Attica19DownloadDescription7PrivateD1Ev@Base 0.4.0 + (optional=gccinternal|arch=!arm64)_ZN6Attica19DownloadDescription7PrivateD2Ev@Base 0.4.0 _ZN6Attica19DownloadDescription7setLinkERK7QString@Base 0.4.0 _ZN6Attica19DownloadDescription7setNameERK7QString@Base 0.4.0 _ZN6Attica19DownloadDescription7setSizeEj@Base 0.4.0
Bug#744173: pkg-kde-tools: add arm64 support to SymbolsHelper
+++ Maximiliano Curia [2014-04-11 09:32 +0200]:
> In article
> <20140411024540.25679.92521.reportbug__44887.6658724204$1397184506$gmane$o...@stoneboat.aleph1.co.uk>
> you wrote:
> -return ($arch =~ /amd64|ia64|alpha|s390|sparc64|ppc64|mips64|mips64el/)
> ? "m" : "j";
> +return ($arch =~
> /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ?
> "m" : "j";
> -return ($arch =~ /(arm|sh4)/) ? 'f' : 'd';
> +return ($arch =~ /(arm|armel|armhf|sh4)/) ? 'f' : 'd';
>
> Most of the changes in the patch change non anchored regexps to anchored ones
> to match the full arch name except the last one, that seems to be matching
> arm64, while it shouldn't, right?
Doh. Well spotted. Thank you. That was indeed the problem.
Changing it to
/^(arm|armel|armhf|sh4)$/)
fixes the phonon build.
But in fact that 'arm' is pointless as the 'arm' architecture is long-dead in
debian.
So /^(armel|armhf|sh4)$/) is a better regexp. However there is one more thing
to consider:
It's not clear to me whether that last regexp should be:
/^(armel|armhf|sh4)$/)
or
/^(armel|sh4)$/)
I read here: https://lists.debian.org/debian-68k/2013/11/msg00012.html
that in QT5 qreal is a double on armhf, but on QT4 it's a float (and
it's float on both for armel). Can this helper know which it is doing
and DTRT? If not which should be the default? Lisandro's message seems
to suggest the former (and the the armhf stuff would be taken care of
with extra symbols lines, not (subst) lines).
If someone can confirm which to use I'd like to have an upload with
this patch in forthwith. I'm happy to do that as an MNU - complain if
that's not OK.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
diff -Nru pkg-kde-tools-0.15.13/debian/changelog pkg-kde-tools-0.15.13+arm64.1/debian/changelog
--- pkg-kde-tools-0.15.13/debian/changelog 2014-02-23 12:09:30.0 +
+++ pkg-kde-tools-0.15.13+arm64.1/debian/changelog 2014-04-11 19:22:51.0 +0000
@@ -1,3 +1,17 @@
+pkg-kde-tools (0.15.13+arm64.1) unreleased; urgency=low
+
+ * Non-maintainer upload.
+ * Fix last check pattern to only match whole arch names, like the rest
+
+ -- Wookey Fri, 11 Apr 2014 19:19:39 +0000
+
+pkg-kde-tools (0.15.13+arm64) unreleased; urgency=low
+
+ * Non-maintainer upload.
+ * Add arm64 and ppc64el (and armel/armhf) support to SymbolsHelper substitutions
+
+ -- Wookey Sun, 06 Apr 2014 01:31:56 +
+
pkg-kde-tools (0.15.13) unstable; urgency=medium
[ Maximiliano Curia ]
diff -Nru pkg-kde-tools-0.15.13/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm pkg-kde-tools-0.15.13+arm64.1/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
--- pkg-kde-tools-0.15.13/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm 2014-02-23 12:09:30.0 +
+++ pkg-kde-tools-0.15.13+arm64.1/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm 2014-04-11 22:21:56.0 +
@@ -161,7 +161,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390|sparc64|ppc64|mips64|mips64el/) ? "m" : "j";
+return ($arch =~ /^(amd64|ia64|alpha|s390x|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? "m" : "j";
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::ssize_t;
@@ -180,7 +180,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390|sparc64|ppc64|mips64|mips64el/) ? 'l' : 'i';
+return ($arch =~ /^(amd64|ia64|alpha|s390x|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'l' : 'i';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::int64_t;
@@ -199,7 +199,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'l' : 'x';
+return ($arch =~ /^(amd64|ia64|alpha|s390x|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'l' : 'x';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::uint64_t;
@@ -218,7 +218,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'm' : 'y';
+return ($arch =~ /^(amd64|ia64|alpha|s390x|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'm' : 'y';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::qptrdiff;
@@ -237,7 +237,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'x' : 'i';
+return ($arch =~ /^(amd64|ia64|alpha|s390x|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'x' : 'i';
}
package Debian::Pk
Bug#744173: pkg-kde-tools: add arm64 support to SymbolsHelper
Package: pkg-kde-tools
Version: 0.15.13
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertag: arm64
SymbolsHelper needs to know about the new 64-bit architecture arm64 in
order for any package that uses the (subst) Symbols file functionality
to be buildable. This patch fixes that.
This patch is very dim. I feel that one should be able to at least
move this test into one place instead of having 6 instances to
update. But I started messing with that and it simply made me forget to
file at least this basic, working verison.
Would it not be possible to use dpkg-architecture DEB_HOST_ARCH_BITS
to get a generic test? If it doesn't need to work in non-debian
situations that seems like a good solution?
-- System Information:
Debian Release: 7.4
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru pkg-kde-tools-0.15.13/debian/changelog pkg-kde-tools-0.15.13+arm64/debian/changelog
--- pkg-kde-tools-0.15.13/debian/changelog 2014-02-23 12:09:30.0 +
+++ pkg-kde-tools-0.15.13+arm64/debian/changelog 2014-04-06 01:44:56.0 +
@@ -1,3 +1,10 @@
+pkg-kde-tools (0.15.13+arm64) unreleased; urgency=low
+
+ * Non-maintainer upload.
+ * Add arm64 and ppc64el (and armel/armhf) support to SymbolsHelper substitutions
+
+ -- Wookey Sun, 06 Apr 2014 01:31:56 +
+
pkg-kde-tools (0.15.13) unstable; urgency=medium
[ Maximiliano Curia ]
diff -Nru pkg-kde-tools-0.15.13/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm pkg-kde-tools-0.15.13+arm64/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm
--- pkg-kde-tools-0.15.13/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm 2014-02-23 12:09:30.0 +
+++ pkg-kde-tools-0.15.13+arm64/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm 2014-04-06 01:42:19.0 +
@@ -161,7 +161,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390|sparc64|ppc64|mips64|mips64el/) ? "m" : "j";
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? "m" : "j";
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::ssize_t;
@@ -180,7 +180,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390|sparc64|ppc64|mips64|mips64el/) ? 'l' : 'i';
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'l' : 'i';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::int64_t;
@@ -199,7 +199,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'l' : 'x';
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'l' : 'x';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::uint64_t;
@@ -218,7 +218,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'm' : 'y';
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'm' : 'y';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::qptrdiff;
@@ -237,7 +237,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'x' : 'i';
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'x' : 'i';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::quintptr;
@@ -256,7 +256,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'y' : 'j';
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'y' : 'j';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::intptr_t;
@@ -275,7 +275,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /amd64|ia64|alpha|s390x|sparc64|ppc64|mips64|mips64el/) ? 'l' : 'i';
+return ($arch =~ /^(amd64|ia64|alpha|s390|sparc64|ppc64|ppc64el|mips64|mips64el|arm64)$/) ? 'l' : 'i';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst::qreal;
@@ -294,7 +294,7 @@
sub _expand {
my ($self, $arch) = @_;
-return ($arch =~ /(arm|sh4)/) ? 'f' : 'd';
+return ($arch =~ /(arm|armel|armhf|sh4)/) ? 'f' : 'd';
}
package Debian::PkgKde::SymbolsHelper::Substs::TypeSubst;
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 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-x11: Add arm64 support
Source: qt4-x11
Version: 4.8.5
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertag: arm64
This package fails to build on arm64 without this patch. It is largely
based on the ubuntu patches in 4:4.8.4+dfsg-0ubuntu15,
4:4.8.4+dfsg-0ubuntu17, and the important fix in
4:4.8.4+dfsg-0ubuntu18), but has a few changes.
1) It uses autotools-dev and the dh_ helpers to ensure config.{sub,guess}
are up to date rather than patching them directly. This is cleaner, will
keep working in the future, and allows rebuilds as the clean target works
correctly.
2) It uses linux-g++ PLATFORM and adds the -fpermissive CFLAG to enable
it to build rather than defining a new almost-identical
linux-g++-aarch64 PLATFORM because that seems to be unnecessary and less
clean. However I am no QT expert so there may be a good reason for doing
it the other way. I have left that definition file in so you can see
what was done, but so far as I can see the linux-g++ definitions are
correct. A look at why -fpermissive is needed might be a good thing, but
is beyond my ken.
3) The ubuntu patch disabled the docs build, but that is now working
correctly so no need for that any more.
This is obviously an important package in the bootstrap so I hope this
patch can go in the archive reasonably soon. Obviously I am happy to
answer questions if you have any queries about what is correct for the
arm64/aarch64 build.
-- System Information:
Debian Release: 7.3
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog
--- qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog 2013-12-06 19:38:48.0 +
+++ qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog 2063-04-30 00:08:35.0 +
@@ -1,3 +1,9 @@
+qt4-x11 (4:4.8.5+git192-g085f851+dfsg-2arm64) unstable; urgency=low
+
+ * Add arm64/aarch64 support
+
+ --Mon, 30 Apr 2063 00:00:20 +
+
qt4-x11 (4:4.8.5+git192-g085f851+dfsg-2) unstable; urgency=low
* Fix typo created when refreshing a patch for s390x which created a FTBFS.
diff -Nru qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control
--- qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control 2013-10-11 23:49:32.0 +
+++ qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control 2063-04-30 00:53:04.0 +
@@ -9,6 +9,7 @@
Lisandro Damián Nicanor Pérez Meyer ,
Timo Jyrinki
Build-Depends: debhelper (>= 9),
+ autotools-dev,
dpkg-dev (>= 1.16.1),
firebird-dev [amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sh4 sparc],
flex,
diff -Nru qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch
--- qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch 1970-01-01 00:00:00.0 +
+++ qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch 2063-04-30 01:11:32.0 +
@@ -0,0 +1,653 @@
+Index: qt4-x11-4.8.5+git192-g085f851+dfsg/configure
+===
+--- qt4-x11-4.8.5+git192-g085f851+dfsg.orig/configure 2063-04-29 23:57:10.0 +
qt4-x11-4.8.5+git192-g085f851+dfsg/configure 2063-04-29 23:57:10.0 +
+@@ -264,6 +264,9 @@
+ armhf)
+ UNAME_MACHINE="armv6"
+ ;;
++ arm64)
++ UNAME_MACHINE="aarch64"
++ ;;
+ hppa)
+ UNAME_MACHINE="parisc"
+ ;;
+@@ -2856,6 +2859,9 @@
+ *86_64)
+ PLATFORM=qws/linux-x86_64-g++
+ ;;
++aarch64)
++PLATFORM=linux-g++-aarch64
++;;
+ *)
+ PLATFORM=qws/linux-generic-g++
+ ;;
+@@ -3294,6 +3300,12 @@
+ 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
+Index: qt4-x11-4.8.5+git192-g085f851+dfsg/mkspecs/linux-g++-aarch64/qmake.conf
+===
+--- /dev/null 1970-01-01 00:00:00.0 +
qt4-x11-4.8.5+git192-g085f851+dfsg/mkspecs/linux-g++-aarch64/qmake.conf 2063-04-29 23:57:10.0 +
+@@ -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 +=
