support ARMv4 architecture, needed for armel builds

Forwarded: no
Last-Update: 2016-07-01

Gbp-Pq: Name armv4.diff

Don't use yield on CPUs that might not support it

Gbp-Pq: Name armel-noyield.patch

Enable skipping plugins search at build time.

Forwarded: not-needed

This patch sets
QT_SKIP_AUTO_PLUGIN_INCLUSION and QT_SKIP_AUTO_QML_PLUGIN_INCLUSION to ON
by default, thus avoiding unnecesary build dependencies on plugins.

The variables can still be set to OFF by the user at build time, allowing
them to find the packages if necessary. But if you need so for a Debian
package please reach the Qt maintainers first. We want to know why you
need to do so. Thanks in advance!

Gbp-Pq: Name enable_skip_plugins.patch

Change how stack grows on HPPA.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042018
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Last-Update: 2023-07-28

On HPPA stack grows upwards. This patch introduces this change for
this 3rd party code.

Gbp-Pq: Name forkfd_grow_stack_upwards_on_hppa.patch

remove RPATH/RUNPATH from examples' binaries.

Forwarded: not-needed
Last-Update: 2024-02-15

On Debian the examples are built against system's libraries, so there is no
need to set RPATH/RUNPATH.

Gbp-Pq: Name remove_rpath_from_examples.patch

cross

Gbp-Pq: Name cross.patch

[PATCH] cmake/QtBuildInternalsExtra.cmake.in: Patch out embedded build path.

The original build path should not be needed in the shipped package,
and causes reproducibility issues when built in different paths.

https://reproducible-builds.org/docs/build-path/

Gbp-Pq: Name build_path_embedded_qtbuildinternalsextra_cmake.patch

remove non-used privacy-breach code

Forwarded: not-needed
Last-Update: 2015-02-18

This code makes Lintian unhappy. But we are really not using it, it only
gets inserted when building the online doc.
Anyways the best way to calm down Lintian is to simply remove it.

Gbp-Pq: Name remove_privacy_breaches.diff

[PATCH] Be verbose on plugin inclusion, easy patch point for distros

TL;DR: This creates two changes:

1. Makes the plugin inclusion status more visible for builders for both Qt
   itself and applications.
2. Allows a simple patch-point for distros to change the default
   (perhaps not ideal, but good enough).
3. Does not changes the current behavior.

As discussed both in the mailing list and privately with
Alexandru Croitor and Joerg Bornemann this makes a lot os sense for Qt
on static builds and when trying to find where the plugins are so they
can be easily packaged up in order to distribute a build with all the
dependencies on it.

But at the same time it makes no sense for distributions building the
libraries in dynamic mode as it forces unnecesary build time
dependencies for for both Qt and applications like QML modules or even
PostgreSQL! [0].

[0] <https://sources.debian.org/src/martchus-qtutilities/6.10.0-1/cmake/modules/QtConfig.cmake/?hl=35#L35>

Other approaches have been considered like not shipping specific CMake
files, but this depends on the packager finding the right ones at the
right time, and does not allows end users to change the behavior if they
happen to need it.

Change-Id: Id32fbc0cf0f289edd4426fb703cf1195288aacb4
Gerrit: https://codereview.qt-project.org/c/qt/qtbase/+/515440

Gbp-Pq: Name be_verbose_on_plugin_inclusion.patch

Add SH description

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043225
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Upstream processes archs from time to time and tends to disable those that
they do not know wether they are working or not.

SH is working on Debian, so as an intermediate measure re enable it here.

Gbp-Pq: Name Add-SH-detection.patch

[PATCH] IPC: add PATH_MAX-less fallback definition for MAX_PATH

Define MAX_PATH also when PATH_MAX is not defined (e.g on GNU/Hurd).
MAX_PATH is Windows constant, and it is used in this file only in a
code path for Windows; because of this, the static fallback define
should be good enough.

Change-Id: Ic1b9fee3b62505f86aa8ec89bbd20493bfe1f67c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Gbp-Pq: Name upstream_IPC-add-PATH_MAX-less-fallback-definition-for-MAX_PA.patch

qt6-base (6.6.2+dfsg-9) unstable; urgency=medium

  * Team upload.
  * Drop the unused ${perl:Depends} substvar from qt6-base-dev-tools, and
    qmake6.
  * Exclude one symbol in libqt6core6t64.symbols from hurd-i386, as it is not
    available on x86 architectures.
  * Update install files for more Linux-only bits.
  * Enable the Vulkan support on all the architectures (i.e. not only on
    Linux), as vulkan-loader is portable, and now available also on non-Linux
    architectures in Debian:
    - remove the linux-any limitation for the libvulkan-dev build and runtime
      dependency
    - remove the linux-any limitation for the vulkan-related symbols in
      libqt6gui6.symbols
    - remove the linux-any limitation for the vulkan-related files in install
      files
  * Sort the install files.
  * Backport upstream commit f319895389705a3db7c2134d1ed47ceade1b204e to fix
    the build on the Hurd; patch
    upstream_IPC-add-PATH_MAX-less-fallback-definition-for-MAX_PA.patch.
  * Copy/import the patch armv4.diff from Qt5 to support ARMv4; it is needed
    to be able to build Qt6 bits with clang 16 and older, which in Debian still
    defaults to ARMv4.

[dgit import unpatched qt6-base 6.6.2+dfsg-9]

Import qt6-base_6.6.2+dfsg-9.debian.tar.xz

[dgit import tarball qt6-base 6.6.2+dfsg-9 qt6-base_6.6.2+dfsg-9.debian.tar.xz]

Import qt6-base_6.6.2+dfsg.orig.tar.xz

[dgit import orig qt6-base_6.6.2+dfsg.orig.tar.xz]