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!
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.
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].
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.
Pino Toscano [Sat, 22 Jun 2024 17:55:15 +0000 (19:55 +0200)]
[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
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!
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.
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].
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.
Pino Toscano [Sat, 22 Jun 2024 17:55:15 +0000 (19:55 +0200)]
[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
Alexey Edelev [Mon, 27 May 2024 09:09:05 +0000 (11:09 +0200)]
[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].
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.
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.
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!
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.
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].
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.
Pino Toscano [Sat, 22 Jun 2024 17:55:15 +0000 (19:55 +0200)]
[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
Alexey Edelev [Mon, 27 May 2024 09:09:05 +0000 (11:09 +0200)]
[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].
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.
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.
Dmitry Shachnev [Fri, 2 Aug 2024 15:24:23 +0000 (18:24 +0300)]
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.
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!
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.
[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].
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.
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.
Pino Toscano [Sat, 22 Jun 2024 17:55:15 +0000 (19:55 +0200)]
[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
Alexey Edelev [Mon, 27 May 2024 09:09:05 +0000 (11:09 +0200)]
[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
* 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.
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!
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.
[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].
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.
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.
Pino Toscano [Sat, 22 Jun 2024 17:55:15 +0000 (19:55 +0200)]
[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
* 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.
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!
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.
[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].
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.
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.
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.
projects / qt6-base.git / log