[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]

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

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