when high-dpi scaling is enabled, there was an offset
from the cursor position to the event position, because
QWindow::mapFromGlobal() works in device-independent
pixels, but we are using actual screen pixels here.
Task-number: QTBUG-77826
Backport from upstream:
Change-Id: Ic8743b9e5c4041065f530ed1d9d6c49337b0207a
Commit: 9d51fb579bb4655f6740096f17f1ced50258c28f
Qt's build system calls mysql_config... which won't work in a cross build
environment like Debian's, as it will throw an exec format error.
In order to solve this call pkgconfig and use mysqlclient.pc.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971604
Forwarded: not-needed
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Gbp-Pq: Name cross_build_mysql.diff
The QStorageInfo/QStorageIterator implementation used for Linux is used also
on Hurd, as it uses an interface provided by GNU libc.
QStorageIterator::device() tries to use PATH_MAX (unavailable on the Hurd)
to lookup a /dev/block/ path, which exists on Linux only; hence, perform that
check within a Q_OS_LINUX block.
Forwarded: no
Last-Update: 2020-04-19
Gbp-Pq: Name qstorageinfo_linux.diff
Use a "safe" size in case PATH_MAX is not defined; in the end, this should not
be used, as a allocating realpath() will be used instead.
Forwarded: no
Last-Update: 2020-04-19
Gbp-Pq: Name path_max.diff
Without this, qmake wrongly thinks that the tests succeed, for example:
./config.tests/unix/futimens/futimens.cpp:44: warning: futimens is not implemented and will always fail
test config.corelib.tests.futimens succeeded
Forwarded: https://codereview.qt-project.org/163214 (rejected)
Bug: https://bugs.debian.org/827935
Last-Update: 2019-03-02
Gbp-Pq: Name gnukfreebsd_linker_warnings.diff
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.
Forwarded: not-needed
Last-Update: 2015-02-18
Gbp-Pq: Name remove_privacy_breaches.diff
- add a gnukfreebsd-g++ qmake mkspec, mostly copied from the hurd-g++ one
- properly use LD_LIBRARY_PATH on GNU/* systems
Last-Update: 2015-06-03
Forwarded: no
Gbp-Pq: Name gnukfreebsd.diff
The solution in d3ed7dac8aa2f4ede0c409254b9dd44842086be0 was needlessly
complicated, and broke a valid use case.
The issue of no identifier being available to parse after the include
has been processed can instead be solved by moving the test for the
closing brace after the include processing.
Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=87973325f1b99f2b
Last-Update: 2022-04-07
Gbp-Pq: Name moc_handle_include.diff
Without this patch, all the code that #includes QtConcurrent headers
will fail to compile with GCC 11.
Origin: upstream, https://codereview.qt-project.org/c/qt/qtbase/+/339417
Last-Update: 2022-04-01
Gbp-Pq: Name gcc-11-qtconcurrentthreadengine.diff
Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167aa8e602c0bea25ebc4d51b55005db13). On Windows, searching
the current directory is the norm, so we keep that behavior.
This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?
See https://kde.org/info/security/advisory-20220131-1.txt
Origin: upstream, https://download.qt.io/official_releases/qt/5.15/CVE-2022-25255-qprocess5-15.diff
Last-Update: 2022-02-21
Gbp-Pq: Name CVE-2022-25255.diff
The MariaDB-connector-c version 3.2 and MariaDB server version 10.6
cooperate to avoid re-transferring the query metadata, so the fact that
we were modifying it was causing it to improperly decode the DATETIME
data types into string, as we had asked. We ended up with a 7-byte
string that was actually the date binary-encoded.
Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=549ee216fd5bf2b3
Last-Update: 2021-11-13
Gbp-Pq: Name mysql_field_readonly.diff
When calling setStyleSheet with property qproperty-styleSheet,
QStyleSheetStyle::polish will call QStyleSheetStyle::setProperties,
and then QStyleSheetStyle::setProperties goes on to call setProperty.
Because there is property qproperty-styleSheet, it will update
stylesheet by calling QStyleSheetStyle::polish.
This causes the recursive call to crash.
Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=e9cdcc7cb314586a
Last-Update: 2021-11-13
Gbp-Pq: Name fix_recursion_crash.diff
For the first call of QXcbClipboard::clipboardReadProperty()
inside of clipboardReadIncrementalProperty() in getSelection(),
it will get a XCB_NONE reply before the contents arrived via
property change. Then we give a chance to read more.
Manually tested with following setups:
* examples/widgets/mainwindows/application with gvim(gtk3)
* examples/widgets/widgets/imageviewer with GIMP 2.10.18(based on
gtk2) and GIMP 2.99.6(based on gtk3 via flatpak)
Fixes: QTBUG-56595
Pick-to: 5.12 5.15 6.1 6.2
Done-With: JiDe Zhang <zhangjide@uniontech.com>
Change-Id: Ib45f08464d39ad79137b1da99808c89b7dca2d08
Reviewed-by: JiDe Zhang <zhangjide@uniontech.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Gbp-Pq: Name xcb_add_a_timeout_control_when_reading_INCR_property.diff
hanpinlong