Bug#1022972: konsole: Konsole does not handle arrow keys correctly anymore
Followup-For: Bug #1022972 Package: konsole Version: 4:22.08.1-1 Dear Maintainer, I can confirm the pinentry and konsole issue, but I'll focus on konsole, even though I suspect they may share a root cause. I found that konsole behaves correctly if I switch my keyboard layout to de nodeadkeys or us. If I use my normal layout Neo2 (`setxkbmap de neo`), the incorrect behaviour occurs. This can be traced down to the keyboard configuration of konsole. When going to: Edit Current Profile... -> Keyboard -> Default (XFree 4) -> Edit... and then using the "input" field for testing, it can be observed that for the arrow up key, different rules trigger depending on the keyboard layout: Layout Rule Escape Sequence de neo Up-Shift+Ansi+AnyModifier\E[1;1A us Up-Shift+Ansi-AppCursorKeys-AnyModifier \E[A The former escape sequence is not recognized by my shell (zsh) or by many other applications. This affects other keys, too (e.g. End, Home, and function keys). Ctrl+Arrow keys work fine, generating a \E[1;5A sequence for Ctrl+Up, which is identical between both layouts. It seems to me as if neo2 somehow causes konsole (or potentially all of Qt, looking at the pinentry thing) to assume some unnamed modifier to be active at all times. Max, Nathanael, could you confirm that you're too using Neo2, or similarly "exotic" layouts? Otherwise we're probably looking at different issues. kind regards, Jonas Schäfer -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages konsole depends on: ii kio5.98.0-1 ii konsole-kpart 4:22.08.1-1 ii libc6 2.35-4 ii libkf5configcore5 5.98.0-2 ii libkf5configwidgets5 5.98.0-1 ii libkf5coreaddons5 5.98.0-1 ii libkf5crash5 5.98.0-1 ii libkf5dbusaddons5 5.98.0-1 ii libkf5globalaccel-bin 5.98.0-1 ii libkf5globalaccel5 5.98.0-1 ii libkf5guiaddons5 5.98.0-2 ii libkf5i18n55.98.0-1+b1 ii libkf5kiowidgets5 5.98.0-1 ii libkf5notifyconfig55.98.0-1 ii libkf5service-bin 5.98.0-1 ii libkf5service5 5.98.0-1 ii libkf5widgetsaddons5 5.98.0-1 ii libkf5windowsystem55.98.0-1 ii libkf5xmlgui5 5.98.0-1+b1 ii libqt5core5a 5.15.6+dfsg-2 ii libqt5gui5 5.15.6+dfsg-2 ii libqt5widgets5 5.15.6+dfsg-2 ii libstdc++6 12.2.0-3 konsole recommends no packages. Versions of packages konsole suggests: pn lrzsz -- no debconf information
Bug#1015625: marked as done (qt6-tools: ftbfs with LTO (link time optimization) enabled)
Your message dated Thu, 03 Nov 2022 12:35:41 + with message-id and subject line Bug#1015625: fixed in qt6-tools 6.4.0-2 has caused the Debian Bug report #1015625, regarding qt6-tools: ftbfs with LTO (link time optimization) enabled to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1015625: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015625 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:qt6-tools Version: 6.2.4-2 Severity: minor Tags: sid bookworm User: debian-...@lists.debian.org Usertags: ftbfs-lto This package currently fails to build (at least on the amd64 architecture) with link time optimizations enabled. For a background for LTO please see https://wiki.debian.org/ToolChain/LTO The goal is to enable this optimization by default in an upcoming Debian release in dpkg-buildflags for 64bit architectures. The goal is to get this package to build with link time optimizations, or to explicitly disable link time optimizations for this package build. To reproduce the build failure, enable the lto optimization in testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS in the debian/rules file, or if this macro is unset, just set it: export DEB_BUILD_MAINT_OPTIONS = optimize=+lto Please try to fix the build with lto enabled, fixing the packaging or forwarding the issue upstream. If the issue cannot be fixed, explicitly disallow building the package with lto by adding to your rules file: export DEB_BUILD_MAINT_OPTIONS = optimize=-lto or adding that string to your existing setting of DEB_BUILD_MAINT_OPTIONS. The full build log can be found at: http://qa-logs.debian.net/2022/06/09/dpkglto/qt6-tools_6.2.4-2_unstable_dpkglto.log The last lines of the build log are at the end of this report. [...] - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_15QHelpFilterDataESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS4_ERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_4QUrlESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE21_M_insert_equal_lowerIS4_EESt17_Rb_tree_iteratorIS4_EOT_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_4QUrlESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE23_M_get_insert_equal_posERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_4QUrlESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE28_M_get_insert_hint_equal_posESt23_Rb_tree_const_iteratorIS4_ERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_9QDateTimeESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE11equal_rangeERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_9QDateTimeESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE24_M_get_insert_unique_posERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_9QDateTimeESt10_Select1stIS4_ESt4lessIS0_ESaIS4_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS4_ERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_P15QListWidgetItemESt10_Select1stIS5_ESt4lessIS0_ESaIS5_EE11equal_rangeERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_P15QListWidgetItemESt10_Select1stIS5_ESt4lessIS0_ESaIS5_EE24_M_get_insert_unique_posERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_P15QListWidgetItemESt10_Select1stIS5_ESt4lessIS0_ESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_S0_ESt10_Select1stIS3_ESt4lessIS0_ESaIS3_EE24_M_get_insert_unique_posERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_S0_ESt10_Select1stIS3_ESt4lessIS0_ESaIS3_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS3_ERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_iESt10_Select1stIS3_ESt4lessIS0_ESaIS3_EE16_M_insert_uniqueIS3_EES1_ISt17_Rb_tree_iteratorIS3_EbEOT_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_iESt10_Select1stIS3_ESt4lessIS0_ESaIS3_EE24_M_get_insert_unique_posERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeI7QStringSt4pairIKS0_iESt10_Select1stIS3_ESt4lessIS0_ESaIS3_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS3_ERS2_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeIiSt4pairIKi7QStringESt10_Select1stIS3_ESt4lessIiESaIS3_EE24_M_get_insert_unique_posERS1_@Base 6.2.2 - (optional=templinst)_ZNSt8_Rb_treeIiSt4pairIKi7QStringESt10_Select1stIS3_ESt4lessIiESaIS3_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS3_ERS1
Bug#1018004: marked as done (qt6-tools: does not build and link with system litehtml)
Your message dated Thu, 03 Nov 2022 12:35:41 + with message-id and subject line Bug#1018004: fixed in qt6-tools 6.4.0-2 has caused the Debian Bug report #1018004, regarding qt6-tools: does not build and link with system litehtml to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1018004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018004 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:qt6-tools Version: 6.3.1-2 Severity: normal Tags: patch Dear Maintainer, This package does not currently build and link with system litehtml as apparently desired. A build dependency on liblitehtml-dev seems to indicate an intention for the package to use the system litehtml for the Qt Assistant tool, though the currently packaged litehtml (0.5-3) is not successfully found via CMake due missing the needed litehtmlConfig.cmake file. So this bug also applies to litehtml. Failure to build/link with the system litehtml is easily confirmed by looking at the assistant-qt6 package [1] which shows no depends on liblitehtml0 as would be expected if system litehtml was used. For previous versions of qt6-tools (ie. 6.2.4) the usual CMake status output shows the failure to find system litehtml during the dh_auto_configure phase which includes the following output [2]: [...] -- The following OPTIONAL packages have not been found: * Qt6QmlCompilerPlus * litehtml [...] Builds of Qt 6.3.1 packages including qt6-tools have much reduced CMake output for some reason, including on Ubuntu Launchpad (not sure why this is so ?) and so the "not been found" message is not shown in the build logs (ie. for latest 6.3.1-2 [3] package). Looking into src:qt6-tools there is a 3rdparty directory [4] which includes a full copy of litehtml source as at commit 971eadc on 2021-10-28 [5]. This is confirmed by doing a git clone of litehtml at that exact commit, with no differences seen between that version of litehtml source and litehtml source included in src:qt6-tools. Builds of src:qt6-tools that successfully use and link with system litehtml have been tested by me, through packaging the exact same version of litehtml (0.5+git20211028) as included in src:qt6-tools. A patch is then also required due issues with Qt CMake code (trying to set Qt defs only applicable to source code in the Qt6 Tools project) and a changed location of litehtml headers (after 0.5). Builds of src:qt6-tools 6.2.4 against src:litehtml 0.5+git20211028 that demonstrate successful use and linking with the system litehtml are now available at a recently created Launchpad PPA [6] for Ubuntu users. So this bug does also affect qt6-tools 6.2.4-2~bpo11+1 as found in bullseye-backports repository, confirmed by above mentioned build logs and again by checking depends for assistant-qt6 [7]. Basic testing of the /usr/lib/qt6/bin/assistant binary (installed via assistant-qt6 binary package) from the Launchpad PPA shows that it appears to work as intended. Adding precompiled Qt help (.qch) files via preferences allows browsing of the content successfully. Attached is a proposed patch which applies cleanly to the qt6-tools 6.3.1-2 package as currently found in Sid. An adaptation of changes made by this patch was used for 6.2.4 with the mentioned Launchpad PPA builds, as could be done for the Bullseye qt6-tools backport. This patch will only be useful once litehtml 0.5+git20211028 is also packaged, due that version being required for a successful build. A bug report will subsequently be filed for litehtml detailing the required version and also other fixes (including updating a patch to litehtml CMakeLists.txt) for building and linking to work with qt6-tools successfully. Both packages will have to be updated for that result to be achieved. Thank you for your work maintaining the Qt6 packages. [1] https://packages.debian.org/sid/assistant-qt6 [2] https://buildd.debian.org/status/fetch.php?pkg=qt6-tools&arch=amd64&ver=6.2.4-3&stamp=1657216677&raw=0 [3] https://buildd.debian.org/status/fetch.php?pkg=qt6-tools&arch=amd64&ver=6.3.1-2&stamp=1660602816&raw=0 [4] src:qt6-tools -> src/assistant/qlitehtml/src/3rdparty/litehtml [5] https://github.com/litehtml/litehtml/commit/971eadc [6] https://launchpad.net/~savoury1/+archive/ubuntu/qt-6-2 [7] https://packages.debian.org/bullseye-backports/assistant-qt6 debian/changelog | 9 ++ debian/control | 2 +- /dev/null => debian/patches/fix-build-with-system-litehtml.patch | 62 /dev/null => debian/patche
Processing of qt6-tools_6.4.0-2_source.changes
qt6-tools_6.4.0-2_source.changes uploaded successfully to localhost along with the files: qt6-tools_6.4.0-2.dsc qt6-tools_6.4.0-2.debian.tar.xz qt6-tools_6.4.0-2_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
qt6-tools_6.4.0-2_source.changes ACCEPTED into experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 03 Nov 2022 13:21:20 +0100 Source: qt6-tools Architecture: source Version: 6.4.0-2 Distribution: experimental Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Patrick Franz Closes: 1015625 1018004 Changes: qt6-tools (6.4.0-2) experimental; urgency=medium . [ Patrick Franz ] * Remove redundant B-D. * Enable link time optimization (Closes: #1015625). . [ Rob Savoury ] * Actually build with system litehtml (Closes: #1018004): - debian/patches/: Add fix-build-with-system-litehtml.patch to fix FTBFS - debian/control: Bump to liblitehtml-dev (>= 0.6~) B-D for the exact version included in src:qt6-tools, required for successful build Checksums-Sha1: 3a7c70d1c3bc012f64f1342c074ffe52facc89de 3163 qt6-tools_6.4.0-2.dsc 16d78aebac4c98158f24fcaa06c4c8851b9f5928 36544 qt6-tools_6.4.0-2.debian.tar.xz dc16963071f0aa38b2f47931cbbcba0716643766 8990 qt6-tools_6.4.0-2_source.buildinfo Checksums-Sha256: bc491ecc8b2335e99235fe8f82ed56353781984966b713704466491269d45440 3163 qt6-tools_6.4.0-2.dsc 0da2896a017c7378bbe166a33f2d70e74bcd03a879009ccb28270b9f1d7329e5 36544 qt6-tools_6.4.0-2.debian.tar.xz ec764f1921ec0ac1ab664d2ccfbdc652b536e0477e716ca1f5acdf687ea52985 8990 qt6-tools_6.4.0-2_source.buildinfo Files: 31492b139927642503e7b58bf2c96bdf 3163 libs optional qt6-tools_6.4.0-2.dsc 2b491d8cfdaac90319708e0b31aaad2f 36544 libs optional qt6-tools_6.4.0-2.debian.tar.xz 3c843bb292141ecbfc46e939d171f899 8990 libs optional qt6-tools_6.4.0-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYodBXDR68cxZHu3Knp96YDB3/lYFAmNjsmkACgkQnp96YDB3 /lb1vRAAie2CzXSXd5m4GPH+W/6LIsvMR2YoUICayUfTojTkvhmRZFN4llPLxjz/ nQcV7alNG+gwmXAaYwn3NWk2KDbKXSnhwQM4/lDZnstLNvKN+21XO7Hluv5UEUi1 NwRitg0IbtdJew21cdNfr+0mYcf6GMmrtdZeMwFoEQ/tNo2fsbxvI3vcN/crvtqJ RAA1YS2f2QtuA6CEDikuKxeH6nkP3lUP7HYziATaNgUu/Cp9yaL17UjS03PRniOI oY2MRmENTiBye14xfUSuDm0PFHGkRzm6hKaTdQaGmTq/6MG/do1ajC7/5yyVIsl8 x7l+M9wI1j9nWpisQfixAMx5RgP4jlPIJpQKMqHzfigsggO/TC6mOo2QEM2yCIT0 UeO/My0dZ9ksfeGv4gWDHe5k2zWUtuvTEk+/IJzI/06ijgxXrja1opnvJwpto3UN B3PYKxLfQApm2PpZ1S1J3nGEMWXM8+S1mhDADaNAMpue1XqqeLYYHCymh2dZ9fez uTMPqo5xSTXxdT7XxWSULWX2zSkiKLyIoLcshQlfWQiDxWdXR9hRcMFEiug4WjCT Dg1Q+chSPlLTn/nCz8w9nJ9KumH032Yp74tModOv181A9+5TtUZabr9nHX5TyBJk DqEDwG2N4P+RwyrkvO2oV4Ff2gVMjsi4dYa9gNoKOjbytz6bRhA= =wUOP -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#1023408: kwin-wayland: black screen on tty1 after resume from hibernation instead of wayland logon screen
Package: kwin-wayland Version: 4:5.26.0-1 Severity: important Dear Maintainer, after sending the laptop to hibernation, the restart did not work. I see the boot message and end up in a black screen. Every terminal (Ctrl+Alt+2 for instance) works. terminal 7 shows a movable cursor. But terminal 1 with the wayland session just shows a black screen -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kwin-wayland depends on: ii kwayland-integration 5.26.0-1 ii kwin-common 4:5.26.0-1 ii libc6 2.36-4 ii libcap2-bin 1:2.44-1 ii libepoxy0 1.5.10-1 ii libfontconfig12.13.1-4.5 ii libfreetype6 2.12.1+dfsg-3 ii libkdecorations2-5v5 4:5.26.0-1 ii libkf5configcore5 5.98.0-2 ii libkf5configgui5 5.98.0-2 ii libkf5configwidgets5 5.98.0-1 ii libkf5coreaddons5 5.98.0-1 ii libkf5crash5 5.98.0-1 ii libkf5dbusaddons5 5.98.0-1 ii libkf5globalaccel-bin 5.98.0-1 ii libkf5globalaccel55.98.0-1 ii libkf5globalaccelprivate5 5.98.0-1 ii libkf5i18n5 5.98.0-1+b1 ii libkf5idletime5 5.98.0-1 ii libkf5notifications5 5.98.0-1 ii libkf5plasma5 5.98.0-1 ii libkf5service-bin 5.98.0-1 ii libkf5service55.98.0-1 ii libkf5windowsystem5 5.98.0-1 ii libkwineffects14 4:5.26.0-1 ii libkwinglutils14 4:5.26.0-1 ii libpipewire-0.3-0 0.3.59-1+b1 ii libqaccessibilityclient-qt5-0 0.4.1-1+b1 ii libqt5core5a [qtbase-abi-5-15-6] 5.15.6+dfsg-2 ii libqt5dbus5 5.15.6+dfsg-2 ii libqt5gui55.15.6+dfsg-2 ii libqt5network55.15.6+dfsg-2 ii libqt5qml55.15.6+dfsg-2 ii libqt5quick5 5.15.6+dfsg-2 ii libqt5widgets55.15.6+dfsg-2 ii libstdc++612.2.0-7 ii libxcb-randr0 1.15-1 ii libxcb-xfixes01.15-1 ii libxcb1 1.15-1 ii xwayland 2:22.1.3-2 kwin-wayland recommends no packages. kwin-wayland suggests no packages. -- no debconf information
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
Hi Carlos!
On Mon, Oct 31, 2022 at 06:55:49PM -0300, Carlos Henrique Lima Melara wrote:
> Took a little while, sorry. Last week was pretty busy. I managed to try
> it today. I will attach the terminal output in the end. So my feedback
> is below.
>
> 1. I wasn't able to reproduce the misplaced menus (QTBUG-68636) in
> unstable or experimental versions.
Me too, actually.
> 2. Your patch makes qt choose the wayland plugin on gnome's wayland
> session by default.
Good. It will reach unstable together with next transition, 5.15.7
or 5.15.8.
> 3. The only problem is that qtwayland5 wayland platform plugin is not
> installed by default in a clean install of debian so applications fail
> to run wayland natively (fallback to xcb).
>
> I think we would need the qtwayland5 installed by default when gnome is
> installed (since wayland is the default there). Do you know which
> package should Depends or Recommends qtwayland5 (maybe gnome-core or
> some other package)?
libqt5gui5 currently suggests it. Do you think it needs to be a
recommendation?
> The terminal output below shows 3 executions of kristall. The first was
> using the version from unstable. The second was using the experimental
> version - fallback to xcb because the wayland platform plugin wasn't
> installed. The third is using experimental's version after qtwayland5
> was installed.
>
> charles@debianSid-vm:~$ kristall
> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> charles@debianSid-vm:~$ kristall
> qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> charles@debianSid-vm:~$ kristall
> QSocketNotifier: Can only be used with threads started with QThread
> defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> ignoring 1 out of 1
> 2 0 "text/gemini"
> Loaded 1265 bytes of type "text" / "gemini"
> cache: pushing url QUrl("gemini://gemini.circumlunar.space/")
> ignoring 1 out of 1
> 2 0 "text/gemini"
> Loaded 350 bytes of type "text" / "gemini"
> cache: pushing url QUrl("gemini://gemini.circumlunar.space/news/")
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Loaded 79 bytes of type "text" / "gemini"
This is probably just debug output, does not indicate actual errors.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
I think it should be more than a recommendation
On Thu, Nov 3, 2022 at 4:06 PM Dmitry Shachnev wrote:
> Hi Carlos!
>
> On Mon, Oct 31, 2022 at 06:55:49PM -0300, Carlos Henrique Lima Melara
> wrote:
> > Took a little while, sorry. Last week was pretty busy. I managed to try
> > it today. I will attach the terminal output in the end. So my feedback
> > is below.
> >
> > 1. I wasn't able to reproduce the misplaced menus (QTBUG-68636) in
> > unstable or experimental versions.
>
> Me too, actually.
>
> > 2. Your patch makes qt choose the wayland plugin on gnome's wayland
> > session by default.
>
> Good. It will reach unstable together with next transition, 5.15.7
> or 5.15.8.
>
> > 3. The only problem is that qtwayland5 wayland platform plugin is not
> > installed by default in a clean install of debian so applications fail
> > to run wayland natively (fallback to xcb).
> >
> > I think we would need the qtwayland5 installed by default when gnome is
> > installed (since wayland is the default there). Do you know which
> > package should Depends or Recommends qtwayland5 (maybe gnome-core or
> > some other package)?
>
> libqt5gui5 currently suggests it. Do you think it needs to be a
> recommendation?
>
> > The terminal output below shows 3 executions of kristall. The first was
> > using the version from unstable. The second was using the experimental
> > version - fallback to xcb because the wayland platform plugin wasn't
> > installed. The third is using experimental's version after qtwayland5
> > was installed.
> >
> > charles@debianSid-vm:~$ kristall
> > Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> > defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall
> > qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> > defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall
> > QSocketNotifier: Can only be used with threads started with QThread
> > defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 1265 bytes of type "text" / "gemini"
> > cache: pushing url QUrl("gemini://gemini.circumlunar.space/")
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 350 bytes of type "text" / "gemini"
> > cache: pushing url QUrl("gemini://gemini.circumlunar.space/news/")
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > Loaded 79 bytes of type "text" / "gemini"
>
> This is probably just debug output, does not indicate actual errors.
>
> --
> Dmitry Shachnev
>
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
On Thu, Nov 03, 2022 at 06:02:03PM +0300, Dmitry Shachnev wrote:
> > 3. The only problem is that qtwayland5 wayland platform plugin is not
> > installed by default in a clean install of debian so applications fail
> > to run wayland natively (fallback to xcb).
> >
> > I think we would need the qtwayland5 installed by default when gnome is
> > installed (since wayland is the default there). Do you know which
> > package should Depends or Recommends qtwayland5 (maybe gnome-core or
> > some other package)?
>
> libqt5gui5 currently suggests it. Do you think it needs to be a
> recommendation?
I think it should be at least a recommendation when wayland is installed
since we're defaulting to run natively. Can we make this behaviour
promoting qtwayland5 to Recommends in libqt5gui5? Because I think people
running X11 will also get the qtwayland5, right? If so, is there other
package that we could use to recommend or depend so it's only installed
when wayland is installed?
I forgot to mention in the first email, but there is a bug filled
against qtwayland5 regarding this matter too [1].
> > The terminal output below shows 3 executions of kristall. The first was
> > using the version from unstable. The second was using the experimental
> > version - fallback to xcb because the wayland platform plugin wasn't
> > installed. The third is using experimental's version after qtwayland5
> > was installed.
> >
> > charles@debianSid-vm:~$ kristall
> > Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
> > QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> > defaultServiceProvider::requestService(): no service found for -
> > "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall
> > qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> > defaultServiceProvider::requestService(): no service found for -
> > "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall
> > QSocketNotifier: Can only be used with threads started with QThread
> > defaultServiceProvider::requestService(): no service found for -
> > "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 1265 bytes of type "text" / "gemini"
> > cache: pushing url QUrl("gemini://gemini.circumlunar.space/")
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 350 bytes of type "text" / "gemini"
> > cache: pushing url QUrl("gemini://gemini.circumlunar.space/news/")
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > Loaded 79 bytes of type "text" / "gemini"
>
> This is probably just debug output, does not indicate actual errors.
I think so too. I just left for completeness :-)
Thanks,
Charles
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998698
signature.asc
Description: PGP signature
Re: Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
On Friday, October 28, 2022 4:09:45 AM MST Agustin Martin wrote: > I am not particularly happy about this (see details below), but seems > we will have to package all these .bdic files because qtwebengine and > chromium use them. Since some .bdic may fail to build I would rather > prefer them to be generated during package creation, where it is > easier not to create them if required. If done during package install > I think everything should be handled from qtwebengine package. In this > case some fine tuning can be done to improve efficiency (handling > symlinks better, regenerate only when a new version of dict package is > installed or incompatibilities in qtwebengine hunspell appear, ...) I agree with you. I am also unhappy that Chromium and QtWebEngine want to use a specialized file format instead of just using the standard Hunspell files. However, as much as I don’t like it, I also agree with you that the best thing Debian can do in the short term is to move forward with the packaging of these .bdic files while we wait to see if we can make any changes upstream. Given that nobody else responded to this question, I think there is a consensus that it is best to create the .bdic files during package creation. The next question that needs to be answered is if we should create new binary packages for the .bdic files or if we should ship them as part of the existing Hunspell language binary packages. The opinions that have been expressed so far have run the gamut on both sides, but my sense is they lean a little towards shipping them in the existing Hunspell packages so as to not add 80+ new packages to Debian that only contain a few files each. Is there anyone who feels strongly that they should not be shipped in the existing files? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#822061: kalarm: KF5 version requires plasma-workspace to work properly
This bug is no longer applicable. KAlarm no longer uses ktimezoned with Qt5 because it now uses QTimeZone. -- David Jarvie. KDE developer, KAlarm author.
