[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1089047: marked as done (qt6-declarative FTCBFS: missing qmltime.qmltypes)

Your message dated Mon, 25 Aug 2025 21:42:25 +0000
with message-id <E1uqexN-00HK97-2U@fasolo.debian.org>
and subject line Bug#1089047: fixed in qt6-declarative 6.9.1+dfsg-2
has caused the Debian Bug report #1089047,
regarding qt6-declarative FTCBFS: missing qmltime.qmltypes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1089047: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089047
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: qt6-base-dev
Version: 6.6.2+dfsg-8
Severity: important
Justification: build regression affecting multiple downstreams
User: debian-cross@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cross@lists.debian.org
Control: affects -1 + src:qt6-declarative

Hi,

qt6-declarative fails to cross build from source since around 6.6. The
last successful version was 6.4.2+dfsg-4 and the first known failing is
6.6.2+dfsg-3. Since then the failure is:

|    dh_install -a -O--buildsystem=cmake\+ninja
| dh_install: warning: Cannot find (any matches for) "usr/lib/arm-linux-gnueabihf/qt6/qml/QmlTime/qmltime.qmltypes" (tried in ., debian/tmp)
| 
| dh_install: warning: qml6-module-qmltime missing files: usr/lib/arm-linux-gnueabihf/qt6/qml/QmlTime/qmltime.qmltypes
| dh_install: error: missing files, aborting
| make: *** [debian/rules:17: binary-arch] Error 255
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2

Now getting to the bottom of this is a lot like searching for a needle
in a haystack. I haven't found the needle, but I'm pretty confident in
discarding much of the haystack.

In diagnosing this, I very much relied on differential builds. I
instrumented the rules to add --trace-expand to the cmake invocation and
compared a native and cross build log. A native build generates the file
as:

| [4905/6992] cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tools/qmltime && /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/lib/qt6/libexec/qmltyperegistrar --generate-qmltypes=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QmlTime/qmltime.qmltypes --import-name=QmlTime --major-version=1 --minor-version=0 --follow-foreign-versioning @/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tools/qmltime/qmltypes/qmltime_foreign_types.txt -o /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tools/qmltime/qmltime_qmltyperegistrations.cpp /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tools/qmltime/meta_types/qt6qmltime_none_metatypes.json && /usr/bin/cmake -E make_directory /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tools/qmltime/.qt/qmltypes && /usr/bin/cmake -E touch /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tools/qmltime/.qt/qmltypes/qmltime.qmltypes

I could not find qmltime.qmltypes in the cross build log, which
initially led me to the wrong path as I was searching for things that
would inhibit building it. Eventually, I dug into the differences in the
--trace-expand output and noticed that the cross build log has a
qmltime_native.qmltypes and that actually gets installed. It just
happens to not be called qmltime.qmltypes and that makes dh_install
unhappy.

So where does this "_native" suffix come from? It originates in
/usr/lib/$DEB_HOST_MULTIARCH/cmake/Qt6/QtToolHelpers.cmake:

| # Sets QT_WILL_BUILD_TOOLS if tools will be built and QT_WILL_RENAME_TOOL_TARGETS
| # if those tools have replaced naming.
| function(qt_check_if_tools_will_be_built)
|     # By default, we build our own tools unless we're cross-building.
|     set(need_target_rename FALSE)
|     if(CMAKE_CROSSCOMPILING)
|         set(will_build_tools FALSE)
|         if(QT_FORCE_BUILD_TOOLS)
|             set(will_build_tools TRUE)
|             set(need_target_rename TRUE)
|         endif()
|     else()
|         set(will_build_tools TRUE)
|         if(QT_FORCE_FIND_TOOLS)
|             set(will_build_tools FALSE)
|             if(QT_FORCE_BUILD_TOOLS)
|                 set(will_build_tools TRUE)
|                 set(need_target_rename TRUE)
|             endif()
|         endif()
|     endif()
| 
|     set(QT_WILL_BUILD_TOOLS ${will_build_tools} CACHE INTERNAL "Are tools going to be built" FORCE)
|     set(QT_WILL_RENAME_TOOL_TARGETS ${need_target_rename} CACHE INTERNAL
|         "Do tool targets need to be renamed" FORCE)
| endfunction()

and

| # Returns the tool name for a given tool target.
| # This is the inverse of qt_get_tool_target_name.
| function(qt_tool_target_to_name out_var target)
|     set(name ${target})
|     if (QT_WILL_RENAME_TOOL_TARGETS)
|         string(REGEX REPLACE "_native$" "" name ${target})
|     endif()
|     set(${out_var} ${name} PARENT_SCOPE)
| endfunction()

In essence, this is a cross/native difference. When cross compiling, we
may decide whether we need to build tools skip them and merely use the
native ones. When we do build them, they get renamed. (Why?) In a native
build, we can opt to use installed tools by setting QT_FORCE_FIND_TOOLS
and then if we still want to build them, they also get renamed.

For cross compilation, we're between a rock and a hard place. Either we
set QT_FORCE_BUILD_TOOLS (and this seems to be implied by
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING, which we already set in d/rules) and
then we end up with the _native suffix or we don't set it and then we
end up without those tools. In neither case will the build system
install them into the desired place. Bummer.

I also find the "_native" naming strange. In the Debian world, we tend
to use "native" in a similar meaning as "build" (i.e. the architecture
we are using to perform the build), but those "*_native" things actually
do get compiled with a host architecture compiler. In most other
contexts, I would expect the "host" objects to keep their name and
perform the renaming on the "build" (or "native") objects. Could it be
that this is a bug in qt6-base-dev? I mean the code still is fairly
fresh and only broke relatively recently.

The last successful build used qt6-base 6.4.2+dfsg-21.1+b1 and the first
failing build used 6.6.2+dfsg-8.

Digging into the history,
https://github.com/qt/qtbase/commit/acfbe3b7795c741b269fc23ed2c51c5937cd7f4f
looks very suspicious to me. Could it be that it is the one that breaks
it? The underlying bug report is
https://bugreports.qt.io/browse/QTBUG-99683.

In any case, we should likely replace QT_BUILD_TOOLS_WHEN_CROSSCOMPILING
with QT_FORCE_BUILD_TOOLS in most qt6 packages. You can find the
affected ones:
https://codesearch.debian.net/search?q=QT_BUILD_TOOLS_WHEN_CROSSCOMPILING+path%3Adebian%2Frules&literal=1

Can someone from the Qt team handle this replacement? I mean like
committing it to git now without a need to upload this change right now.
Would you prefer me filing separate bugs for qt6-wayland, qt6-quick3d,
qt6-scxml, qt6-shadertools and qt6-remoteobjects?

Is anyone able to take this to Qt upstream?

Helmut

--- End Message ---
--- Begin Message --- 
Source: qt6-declarative
Source-Version: 6.9.1+dfsg-2
Done: Patrick Franz <deltaone@debian.org>

We believe that the bug you reported is fixed in the latest version of
qt6-declarative, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1089047@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Patrick Franz <deltaone@debian.org> (supplier of updated qt6-declarative package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 25 Aug 2025 22:37:46 +0200
Source: qt6-declarative
Architecture: source
Version: 6.9.1+dfsg-2
Distribution: experimental
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Changed-By: Patrick Franz <deltaone@debian.org>
Closes: 1089047
Changes:
 qt6-declarative (6.9.1+dfsg-2) experimental; urgency=medium
 .
   [ Patrick Franz ]
   * Do not use ccache on hurd.
   * Replace QT_BUILD_TOOLS_WHEN_CROSSCOMPILING with QT_FORCE_BUILD_TOOLS
     for cross-builds (Closes: #1089047).
Checksums-Sha1:
 a5b7a1f03aae43e25c86c34891713f39ebe57ffc 6832 qt6-declarative_6.9.1+dfsg-2.dsc
 1228380d8846360ae91125c53914040c6b760b7e 52844 qt6-declarative_6.9.1+dfsg-2.debian.tar.xz
 1d73f4c3a2df4d17fab6e213f15c6ed5c4810b25 7252 qt6-declarative_6.9.1+dfsg-2_source.buildinfo
Checksums-Sha256:
 f415c65001575187abf9f7c287f0d86c3ce69a1cb9e7477db3fc5e7e3b4b1e00 6832 qt6-declarative_6.9.1+dfsg-2.dsc
 76f7a5e31fa532761849ea8f0ff66033d8e4bcdbe3de27325990f53a06aa3e06 52844 qt6-declarative_6.9.1+dfsg-2.debian.tar.xz
 f832b479ceb141a7d52c1cf2ab74aed597131b760878c2c3a24b061167237ea4 7252 qt6-declarative_6.9.1+dfsg-2_source.buildinfo
Files:
 4fc71c820d3d2a050a8d79c248bc4802 6832 libs optional qt6-declarative_6.9.1+dfsg-2.dsc
 e34cd39b55c19786f7bd6c8242ccfb7e 52844 libs optional qt6-declarative_6.9.1+dfsg-2.debian.tar.xz
 9f41a848b62a3cec13450cda824cc323 7252 libs optional qt6-declarative_6.9.1+dfsg-2_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEYodBXDR68cxZHu3Knp96YDB3/lYFAmis1CoACgkQnp96YDB3
/lbhNA/+L6a9h7hP4eDrx+EVxYqWQ/PZPzzbjcHyL4hF4kr0O3vGRQjnOsaPWkH2
FXJHc+qSiZ7z4tViw4XgSs6UdqDkQeHk7Q5dP/p47CXDfqtNERv2S60ytlWGqYbo
DEdXtgUrukN92M7JMb8VaiTuBzcOXlrhB66BZVqcgaPgIijUalXMjOim93HwkzEx
xVk9At6rlk9NJqCKh9N4kXyC9b4XdhuC3oQkUxRFQDvg49U/LMO/mizLQuWxBLmM
Xgz6Um7MKWnIycKbAMe5+tT3eqcOYDDd4KwKQWADwWtI4kJTl5+ibOfkrD7lmZF7
JRCkHea2PsuXj6/aJi3MTuREPN4axsilE4b3dY0UP+vUzOA4VHHS3nNPapU9RuM8
LgeZoPlXc08BE3LiWQVdZy/Ybrs7Q/gaMoqr9YjszDcpdX5WVC7+ujTR/Z+4xuok
0zxXLivWUx0fEZeUQwcUtUlYp2EIrjX1KaNKGv80wyIDdf7TYRqJnoWxMChCR2F5
D9zsEIF8w1hcsJhmc9PejePRXtzHD5JNgRd/vsLBX38LYRGQTL1dLdQKodunGj4S
zkq76gXNVpl+3XkYKB4GUhMnsK+BujXX5LYDIhBgxaJjIvEsslqzJKXneMxnEHW1
uKJDI86FwttA85qALECyhLrwnEieTqVvRiT5vZpG8KVoDKgK0mo=
=D9Sh
-----END PGP SIGNATURE-----

Attachment: pgp5pgsZy6JIn.pgp
Description: PGP signature


--- End Message ---
Reply to: