Merge qt6-base (6.6.2+dfsg-12) import into refs/heads/workingbranch

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

use _Float16 only when SSE2 is enabled

Forwarded: https://codereview.qt-project.org/c/qt/qtbase/+/579205
Last-Update: 2024-08-01

The GCC documentation [1] says: “On x86 targets with SSE2 enabled, GCC
supports half-precision (16-bit) floating point via the _Float16 type”.

On non-SSE2 x86 (such as Debian i386 baseline [2]), __FLT16_MAX__ is
defined starting with GCC 14 [3], however any non-trivial use of the
_Float16 type results in an error:

error: operation not permitted on type ‘_Float16’ without option ‘-msse2’

which makes some packages fail to build on i386 architecture [4].

[1]: https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html
[2]: https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
[3]: https://gcc.gnu.org/g:9a19fa8b616f83474c35cc5b34a3865073ced829
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076986

Gbp-Pq: Name use_float16_only_with_sse2.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

[PATCH] Ensure that libzstd targets are promoted to global if they were found

Promote all internal zstd targets if they were found by WrapZSTD to
global using PROVIDED_TARGETS mechanism.

Amends 7d9d1220f367d9275dfaa7ce12e89b0a9f4c1978

Task-numer: QTBUG-119469
Change-Id: I15ec484304f7bf2b3ee2a533d2badb3bb7797863
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Gbp-Pq: Name upstream_Ensure-that-libzstd-targets-are-promoted-to-global-i.patch

[PATCH] Prefer using the non-suffixed libzstd over static one

Recent zstd versions provide the libstd target but not only libzstd_shared
or libzstd_static. Attempt to use it as the WrapZSTD::WrapZSTD counterpart
if the target exists.

Task-number: QTBUG-119469
Change-Id: I47916bfa6f10883d099184a497800277c8026b14
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Gbp-Pq: Name upstream_Prefer-using-the-non-suffixed-libzstd-over-static-on.patch

[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

QGtk3Theme: fix QGtk3Interface::fileIcon

Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=277d77029d7fe8f4
Last-Update: 2024-08-02

By failing to set the G_FILE_ATTRIBUTE_STANDARD_ICON attribute, the
"icon" returned by g_file_info_get_icon was always null and a
GLib-GIO-CRITICAL warning was output to the console (at least since glib
2.76.0)[1].

After adding the necessary attribute, the code was crashing, because now
a valid icon was returned, however the icon should not be freed[2],
which is why I removed the "g_object_unref(icon)".

Now it was no longer crashing, but the size of the icons was off. It was
passing GTK_ICON_SIZE_BUTTON (4) to gtk_icon_theme_lookup_by_gicon where
a size in pixels was expected. I chose 16 because that's the pixel size
associated with GTK_ICON_SIZE_BUTTON[3].

Finally I noticed the returned icons had the wrong color. It seems that
a GdkPixbuf uses RGBA8888 format[4]. Adding an explicit conversion to
ARGB32 made the icons look correct for me.

[1] https://gitlab.gnome.org/GNOME/glib/-/commit/ed8e86a7d41a0900d8fa57edc64264d04cf8135b
[2] https://docs.gtk.org/gio/method.FileInfo.get_icon.html
[3] https://docs.gtk.org/gtk3/enum.IconSize.html#button
[4] https://docs.gtk.org/gdk-pixbuf/class.Pixbuf.html#image-data

Gbp-Pq: Name fix_qgtk3interface_fileicon.patch

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

  * Team upload.
  * Replace Qml2Imports (deprecated) with QmlImports in debian/qt.conf.in.

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

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

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

Merge qt6-base (6.6.2+dfsg-11) import into refs/heads/workingbranch

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

use _Float16 only when SSE2 is enabled

Forwarded: https://codereview.qt-project.org/c/qt/qtbase/+/579205
Last-Update: 2024-08-01

The GCC documentation [1] says: “On x86 targets with SSE2 enabled, GCC
supports half-precision (16-bit) floating point via the _Float16 type”.

On non-SSE2 x86 (such as Debian i386 baseline [2]), __FLT16_MAX__ is
defined starting with GCC 14 [3], however any non-trivial use of the
_Float16 type results in an error:

error: operation not permitted on type ‘_Float16’ without option ‘-msse2’

which makes some packages fail to build on i386 architecture [4].

[1]: https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html
[2]: https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
[3]: https://gcc.gnu.org/g:9a19fa8b616f83474c35cc5b34a3865073ced829
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076986

Gbp-Pq: Name use_float16_only_with_sse2.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

[PATCH] Ensure that libzstd targets are promoted to global if they were found

Promote all internal zstd targets if they were found by WrapZSTD to
global using PROVIDED_TARGETS mechanism.

Amends 7d9d1220f367d9275dfaa7ce12e89b0a9f4c1978

Task-numer: QTBUG-119469
Change-Id: I15ec484304f7bf2b3ee2a533d2badb3bb7797863
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Gbp-Pq: Name upstream_Ensure-that-libzstd-targets-are-promoted-to-global-i.patch

[PATCH] Prefer using the non-suffixed libzstd over static one

Recent zstd versions provide the libstd target but not only libzstd_shared
or libzstd_static. Attempt to use it as the WrapZSTD::WrapZSTD counterpart
if the target exists.

Task-number: QTBUG-119469
Change-Id: I47916bfa6f10883d099184a497800277c8026b14
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Gbp-Pq: Name upstream_Prefer-using-the-non-suffixed-libzstd-over-static-on.patch

[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

QGtk3Theme: fix QGtk3Interface::fileIcon

Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=277d77029d7fe8f4
Last-Update: 2024-08-02

By failing to set the G_FILE_ATTRIBUTE_STANDARD_ICON attribute, the
"icon" returned by g_file_info_get_icon was always null and a
GLib-GIO-CRITICAL warning was output to the console (at least since glib
2.76.0)[1].

After adding the necessary attribute, the code was crashing, because now
a valid icon was returned, however the icon should not be freed[2],
which is why I removed the "g_object_unref(icon)".

Now it was no longer crashing, but the size of the icons was off. It was
passing GTK_ICON_SIZE_BUTTON (4) to gtk_icon_theme_lookup_by_gicon where
a size in pixels was expected. I chose 16 because that's the pixel size
associated with GTK_ICON_SIZE_BUTTON[3].

Finally I noticed the returned icons had the wrong color. It seems that
a GdkPixbuf uses RGBA8888 format[4]. Adding an explicit conversion to
ARGB32 made the icons look correct for me.

[1] https://gitlab.gnome.org/GNOME/glib/-/commit/ed8e86a7d41a0900d8fa57edc64264d04cf8135b
[2] https://docs.gtk.org/gio/method.FileInfo.get_icon.html
[3] https://docs.gtk.org/gtk3/enum.IconSize.html#button
[4] https://docs.gtk.org/gdk-pixbuf/class.Pixbuf.html#image-data

Gbp-Pq: Name fix_qgtk3interface_fileicon.patch

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

  * Team upload.
  * Add a patch to use _Float16 only when SSE2 is enabled (closes: #1076986).
  * Backport upstream patch to fix QGtk3Interface::fileIcon with GLib ≥ 2.76.

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

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

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

Merge qt6-base (6.6.2+dfsg-10) import into refs/heads/workingbranch

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

[PATCH] Ensure that libzstd targets are promoted to global if they were found

Promote all internal zstd targets if they were found by WrapZSTD to
global using PROVIDED_TARGETS mechanism.

Amends 7d9d1220f367d9275dfaa7ce12e89b0a9f4c1978

Task-numer: QTBUG-119469
Change-Id: I15ec484304f7bf2b3ee2a533d2badb3bb7797863
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Gbp-Pq: Name upstream_Ensure-that-libzstd-targets-are-promoted-to-global-i.patch

[PATCH] Prefer using the non-suffixed libzstd over static one

Recent zstd versions provide the libstd target but not only libzstd_shared
or libzstd_static. Attempt to use it as the WrapZSTD::WrapZSTD counterpart
if the target exists.

Task-number: QTBUG-119469
Change-Id: I47916bfa6f10883d099184a497800277c8026b14
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Gbp-Pq: Name upstream_Prefer-using-the-non-suffixed-libzstd-over-static-on.patch

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

  * Team upload.
  * Backport upstream commit 7d9d1220f367d9275dfaa7ce12e89b0a9f4c1978 to use
    also the zstd::libzstd cmake target, if available; patch
    upstream_Prefer-using-the-non-suffixed-libzstd-over-static-on.patch.
  * Backport upstream commit 3073b9c4dec5e5877363794bf81cbd4b84fdb9ee to promote
    the libzstd cmake targets to global; patch
    upstream_Ensure-that-libzstd-targets-are-promoted-to-global-i.patch.

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

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

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

Merge qt6-base (6.6.2+dfsg-9) import into refs/heads/workingbranch

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]

Merge qt6-base (6.6.2+dfsg-8) import into refs/heads/workingbranch

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

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

  [ Patrick Franz ]
  * Remove the temporary Provides for the t64-suffix.
  * Handle upstream ABI break (Closes: #1071193, #1071436).

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

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

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

Merge qt6-base (6.4.2+dfsg-21.1) import into refs/heads/workingbranch

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

Gbp-Pq: Name armel-noyield.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: 2023-07-23

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

Avoid trying to build the htmlinfo example

Forwarded: not-needed

This example uses non-free images, so we had to remove it from the original
tarball.

This patch avoid building this example.

Gbp-Pq: Name no_htmlinfo_example.patch

force the usage of the shared libzstd library.

Bug: https://bugreports.qt.io/browse/QTBUG-110978
Forwarded: not-needed

The library provides both versions, and the original code prefers the static
version over the shared, while on Debian it should always use the shared
version.

Gbp-Pq: Name force_shared_libzstd.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

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

Fix CVE-2023-24607

Forwarded: not-needed

CVE-2023-24607 can trigger a DOS with a specifically crafted string,
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031871.
This patch https://codereview.qt-project.org/c/qt/qtbase/+/456216,
https://codereview.qt-project.org/c/qt/qtbase/+/457637 and
https://codereview.qt-project.org/c/qt/qtbase/+/457937
See: https://www.qt.io/blog/security-advisory-qt-sql-odbc-driver-plugin

Gbp-Pq: Name cve-2023-24607.patch

[PATCH] Add/enable Alpha detection

- uncomment the Alpha detection defining Q_PROCESSOR_ALPHA, which is
  already used/documented in few places
- set the right machine type in QElfParser for Alpha ELF files

Pick-to: 6.5
Change-Id: I072bdee8b73ad3c86591c764aa7075c114967fd9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Gbp-Pq: Name upstream_Add-enable-Alpha-detection.patch

[PATCH] Add M68k detection

- detect the M68k architecture (Motorola 68000) and define
  Q_PROCESSOR_M68K
- set the right machine type in QElfParser for M68k ELF files

Change-Id: Ie5694abbe1ae2bfeb5692defba0ca6062c1d60ac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Gbp-Pq: Name upstream_Add-M68k-detection.patch

[PATCH] Add HPPA detection

- detect the HPPA architecture (PA-RISC) and define Q_PROCESSOR_HPPA
- set the right machine type in QElfParser for HPPA ELF files

Change-Id: I5214ce64ef1fdd0ecca3d6c1694c5db9b2852a22
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Gbp-Pq: Name upstream_Add-HPPA-detection.patch

cve-2023-33285

Gbp-Pq: Name cve-2023-33285.diff

cve-2023-32763

Gbp-Pq: Name cve-2023-32763.diff

cve-2023-32762

Gbp-Pq: Name cve-2023-32762.diff

[PATCH] Schannel: Reject certificate not signed by a configured CA certificate

Not entirely clear why, but when building the certificate chain for a
peer the system certificate store is searched for root certificates.
General expectation is that after calling
`sslConfiguration.setCaCertificates()` the system certificates will
not be taken into consideration.

To work around this behavior, we do a manual check that the root of the
chain is part of the configured CA certificates.

Pick-to: 6.5 6.2 5.15
Change-Id: I03666a4d9b0eac39ae97e150b4743120611a11b3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Gbp-Pq: Name cve-2023-34410-ada2c57.diff

[PATCH] Ssl: Copy the on-demand cert loading bool from default config

Otherwise individual sockets will still load system certificates when
a chain doesn't match against the configured CA certificates.
That's not intended behavior, since specifically setting the CA
certificates means you don't want the system certificates to be used.

Follow-up to/amends ada2c573c1a25f8d96577734968fe317ddfa292a

This is potentially a breaking change because now, if you ever add a
CA to the default config, it will disable loading system certificates
on demand for all sockets. And the only way to re-enable it is to
create a null-QSslConfiguration and set it as the new default.

Pick-to: 6.5 6.2 5.15
Change-Id: Ic3b2ab125c0cdd58ad654af1cb36173960ce2d1e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Gbp-Pq: Name cve-2023-34410-57ba626.diff

[PATCH] QXmlStreamReader: make fastScanName() indicate parsing status to callers

This fixes a crash while parsing an XML file with garbage data, the file
starts with '<' then garbage data:
- The loop in the parse() keeps iterating until it hits "case 262:",
  which calls fastScanName()
- fastScanName() iterates over the text buffer scanning for the
  attribute name (e.g. "xml:lang"), until it finds ':'
- Consider a Value val, fastScanName() is called on it, it would set
  val.prefix to a number > val.len, then it would hit the 4096 condition
  and return (returned 0, now it returns the equivalent of
  std::null_opt), which means that val.len doesn't get modified, making
  it smaller than val.prefix
- The code would try constructing an XmlStringRef with negative length,
  which would hit an assert in one of QStringView's constructors

Add an assert to the XmlStringRef constructor.

Add unittest based on the file from the bug report.

Later on I will replace FastScanNameResult with std::optional<qsizetype>
(std::optional is C++17, which isn't required by Qt 5.15, and we want to
backport this fix).

Credit to OSS-Fuzz.

Fixes: QTBUG-109781
Fixes: QTBUG-114829
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I455a5eeb47870c2ac9ffd0cbcdcd99c1ae2dd374
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Gbp-Pq: Name cve-2023-37369.diff

[PATCH] xkb: fix build with libxkbcommon 1.6.0 and later

A few XKB_KEY_dead_* defines got removed from 1.6.0. See also
https://github.com/xkbcommon/libxkbcommon/blob/6073565903488cb5b9a8d37fdc4a7c2f9d7ad04d/NEWS#L9-L14
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/70/diffs?commit_id=cb44799b72f611eb4c9d7cc185bc3b09e070be08

Pick-to: 6.6 6.5 6.2 5.15
Fixes: QTBUG-117950
Change-Id: I55861868f2bb29c553d68365fa9b9b6ed01c9aea
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Gbp-Pq: Name libxkbcommon_1.6.0.diff

cve-2023-51714

Gbp-Pq: Name cve-2023-51714.diff