Re: Coloured character borders in kterm
Just for info, I managed to downgrade libfreetype6 and fontconfig to 2.11.1+dfsg-1 and the problem persists.
Re: Coloured character borders in kterm
Hello Sven! I removed both simlinks but no effect at all, exactly the same rainbow colored characters, most noticeable with dark background (Kterm) Sven Joachim wrote: > > It is due to new settings in fontconfig-config, especially the symlinks > 10-sub-pixel-rgb.conf and 10-yes-antialias.conf in /etc/fonts/conf.d. > Try removing the first of these, and if you are still not satisfied with > the result, the second as well. > > After that fonts should look the same as before, except that the default > family is now Noto rather than DejaVu, see https://bugs.debian.org/1028643. > > Cheers, >Sven
qt6-webview_6.4.2-1_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 17 Jan 2023 20:14:22 +0100 Source: qt6-webview Architecture: source Version: 6.4.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Patrick Franz Changes: qt6-webview (6.4.2-1) unstable; urgency=medium . [ Patrick Franz ] * Switch to the official 6.4.2 tarball, the tarball is the same. Checksums-Sha1: 098bcc9c7bfd0dd9a262ec1a902e530d72509eab 2906 qt6-webview_6.4.2-1.dsc 3dffcd6059038280e446d85f259ca22dbe2c7b8f 139600 qt6-webview_6.4.2.orig.tar.xz 44f5c031d6d872eabaee86ceeb0ca1b4c18ec4ca 6540 qt6-webview_6.4.2-1.debian.tar.xz a0e49a5e88a1c32be02bef753ab953f1237ce66d 12766 qt6-webview_6.4.2-1_source.buildinfo Checksums-Sha256: 4e2b2ae193089e82c3eb60856cb54039088b4bad5e196961561dbbb380feceed 2906 qt6-webview_6.4.2-1.dsc a642961415c153c6fbf2c8adfebe9d53653116af79c32ebdb06be0c56fb2f372 139600 qt6-webview_6.4.2.orig.tar.xz b7cee5842bfa1bf5b8d347a7512f49f4f87f4c68122d84eee5fbfea98945df94 6540 qt6-webview_6.4.2-1.debian.tar.xz a99d6724ce7c123bb64272d4716810d425f0f3eb3d0c81764e85e0754167b22c 12766 qt6-webview_6.4.2-1_source.buildinfo Files: 65b56e80f567d9d7446f3356cae48640 2906 libs optional qt6-webview_6.4.2-1.dsc ce26f893193529331502685bb39561d6 139600 libs optional qt6-webview_6.4.2.orig.tar.xz 9e0434ae63b02d19fb965a057590372f 6540 libs optional qt6-webview_6.4.2-1.debian.tar.xz 8df5a7c25e585e101b6bfb82e1554dcb 12766 libs optional qt6-webview_6.4.2-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYodBXDR68cxZHu3Knp96YDB3/lYFAmPG9BwACgkQnp96YDB3 /lZ4CA/9EuMVJqIe2+jH/F4hHPWS7ybkbq8/GLv6c6SY08f5oayGkzQjOAGJ8DXJ QsXH+Ws+RmUPnQ4T1QOZA0OWiTIzTpcr7fXk1ugJkwISOV0UVLepmfBRE7pNVurs HcxWOv1EJ2aWM3oKZP0fBA2VxcfWuVNYsbr3N1VnL76JYjJ9U7NyXYEJJKzB2Z1i yXU/Fc9d6CqV/XfcnAjQxisy/mWm1+wJMDrrVldR+u4Dz6Ub7bcDsJPh3/Y1LyFL jNxpx5wiYfZBZn4/skMt1J+FU/ZNSX0kepKG14EjaVrGaCSKuHolopke8fVBE9Pd GYdKyeQLIhhZJ38wYaX33Lf+m5HPCW9svoDfTgbrjUnkc0+IyYLDDGlvXOrTDGL6 xpmb28nOA57YAMnDQKpVd6P+Q0hDn7o0udgyWCp5MHkTRNCETtOkQxvC3sQYxeaE vWt7bdI4IKbBJoFBxxYsU2VUkbYBv03bOKPJF2NyqRbclAG/LZsOUVRIRT0AJco8 NQVbR02LUP+UXyTvsYjhz5pStXUYSsTJgloo05mE5XIZuFX9L0DfVONEopcThr/Y QDt+lhMc6LjE5oJZ5JO3o78b93V/BPuBUuK5xnqYCag+r9Z6WpCxHQhpf0u9fl2s WnmfPkAMf1r1BKA9Zcu9mtTXuz1mact2LlIakOZA/TYOffvmsLk= =OL4v -END PGP SIGNATURE-
Processing of qt6-webview_6.4.2-1_source.changes
qt6-webview_6.4.2-1_source.changes uploaded successfully to localhost along with the files: qt6-webview_6.4.2-1.dsc qt6-webview_6.4.2.orig.tar.xz qt6-webview_6.4.2-1.debian.tar.xz qt6-webview_6.4.2-1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1029079: akonadi-backend-mysql: Build against default-mysql-{client,server}-core 1.1.0
Hi Sedat, On Tue, 17 Jan 2023 14:51:56 +0100 Sedat Dilek wrote: > I removed akonadi-backend-mysql from my Debian/unstable AMD64 box as I > need a higher version of mariadb. There is no need to remove akonadi-backend-mysql from Sid and I also don't see why we would need to rebuild it. During the upgrade of MariaDB, the package default-mysql-server-core is unconfigured for a short moment, but that's it. The log should tell you that it's configured afterwards. -- Med vänliga hälsningar Patrick Franz
Re: Coloured character borders in kterm
On 2023-01-14 22:05 +0100, Miguel A. Vallejo wrote: > Hello! > > After today's apt-upgrade I noticed all letters in kterm have a > coloured border as you can see in the attached image. > > But I also noticed 78 packages have been kept back, so my question is: > > Is this a new problem or only the symptom of an incomplete upgrade? It is due to new settings in fontconfig-config, especially the symlinks 10-sub-pixel-rgb.conf and 10-yes-antialias.conf in /etc/fonts/conf.d. Try removing the first of these, and if you are still not satisfied with the result, the second as well. After that fonts should look the same as before, except that the default family is now Noto rather than DejaVu, see https://bugs.debian.org/1028643. Cheers, Sven
qt6-wayland_6.4.2-1_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 17 Jan 2023 14:44:16 -0300 Source: qt6-wayland Architecture: source Version: 6.4.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Lisandro Damián Nicanor Pérez Meyer Closes: 1029098 Changes: qt6-wayland (6.4.2-1) unstable; urgency=medium . * Team upload. * Add libwayland-dev as qt6-wayland-dev dependency, as CMake files look for its presence. * Switch to the official 6.4.2 tarball, the tarball is the same. * Install private components, which are not tied to private headers and required by the main, public components (Closes: #1029098). Thanks Rodney Dawes for the bug report! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013222#50 Checksums-Sha1: 601a8bc4774de4bedc647f55c33025573ab1 3340 qt6-wayland_6.4.2-1.dsc 394c001681779c22aa39cf97216508e10dcb2a18 836720 qt6-wayland_6.4.2.orig.tar.xz e6a97ef2a95a113666396dd286296887960e93b8 46404 qt6-wayland_6.4.2-1.debian.tar.xz 37bb7cee6088e209c7680321248e1db30d8de805 14822 qt6-wayland_6.4.2-1_source.buildinfo Checksums-Sha256: 466dbd5f3040d9b67a0cc10b2fad4f741c4ee94c093308245497e9f012cbd1e0 3340 qt6-wayland_6.4.2-1.dsc 24cf1a0af751ab1637b4815d5c5f3704483d5fa7bedbd3519e6fc020d8be135f 836720 qt6-wayland_6.4.2.orig.tar.xz 4bd0d6f6a6a7cc9ffc1a61a6a26168c0ae6a1f4979fc1eb44f472217c51ea574 46404 qt6-wayland_6.4.2-1.debian.tar.xz 327dabef3a05ef5c4371e8c98f3159210328bd3539510b6267ddecf551ddcb2e 14822 qt6-wayland_6.4.2-1_source.buildinfo Files: dcced990d09e07017923d64153ac057b 3340 libs optional qt6-wayland_6.4.2-1.dsc 15401160a8d00c65e499f24be3df993b 836720 libs optional qt6-wayland_6.4.2.orig.tar.xz 9e6115793fc92145918c220949b34cee 46404 libs optional qt6-wayland_6.4.2-1.debian.tar.xz e8ab90b8f1cf0796fcaedaa77577b7f9 14822 libs optional qt6-wayland_6.4.2-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEEt36hKwjsrvwSzE8q2RfQGKGp9AFAmPG3w0UHGxpc2FuZHJv QGRlYmlhbi5vcmcACgkQq2RfQGKGp9B3URAAndupAstnkBLYWgUnx36H323n7u/s IEg1dRHATkR43HNcMKTZdc+Gjd9uNm4XvpOAsYDeTuhKIbvACUHeS7tM1yNelkmp 6cpG/33Awue43O8Wn/q1+5+UAqUBkIBdG1S5WaLHXchObfohQgBUZ3oofPHIA+7a zti5JFgLzL1TmLBXu3H6wTnTttKPfx3imlcf9L8LIyaFrJ+7/AikaAbkAL9s+E+C vkhQADZE13FqXxXnWWj+q4LhcNEiBNTNhgkFXJN1MJwtM3OeotrK3TXiZEpALFcL OWS7Zry6QPbtNvs0jVCzGPpWtjO7ZftPAvcI0Jgl+bOFB8UqxWa2UH2m6CN8KVER 768jZz7HvuCrFeXl6xSlhh8SDk/yC+qmeqRTzIqMel+L58ggBRZnYRgErWnK46r6 vTROrQZw2zDJrM2NfrFsXPdjxId8uP6ncGhvOjoMa0DUYPNPMzmuZlCEnBcLxWut tvDhjdXf81uzWYwO9uPMA+ROMgbe1GRv10Bx+3EB/6wufhP4un5RnrdrS2e4gDkN 1ta77NLt4LwXrkpWmFdCHPFZCEDfcvM6DbGtb87ysJYG3OKGMfDpGVkSTgtCMOQH KgVGsi/WneI1Phgoz90fycU1yJEjrVEbU2rCKcm+p9VPbmDd6gxDlNBqRJ6K/C6r qLwdOTmjDzFHRss= =0frF -END PGP SIGNATURE-
Processing of qt6-wayland_6.4.2-1_source.changes
qt6-wayland_6.4.2-1_source.changes uploaded successfully to localhost along with the files: qt6-wayland_6.4.2-1.dsc qt6-wayland_6.4.2.orig.tar.xz qt6-wayland_6.4.2-1.debian.tar.xz qt6-wayland_6.4.2-1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1029098: marked as done (qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate)
Your message dated Tue, 17 Jan 2023 18:05:17 + with message-id and subject line Bug#1029098: fixed in qt6-wayland 6.4.2-1 has caused the Debian Bug report #1029098, regarding qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate 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.) -- 1029098: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029098 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: qt6-wayland Version: 6.4.2~rc1-2 Severity: normal X-Debbugs-Cc: dobey.p...@gmail.com, lisan...@debian.org With a CMakeLists.txt having: find_package(Qt6 REQUIRED COMPONENTS WaylandClient) Runnning CMake issues: ``` -- Could NOT find Qt6WaylandGlobalPrivate (missing: Qt6WaylandGlobalPrivate_DIR) CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake but it set Qt6WaylandClient_FOUND to FALSE so package "Qt6WaylandClient" is considered to be NOT FOUND. Reason given by package: Qt6WaylandClient could not be found because dependency Qt6WaylandGlobalPrivate could not be found. Configuring with --debug-find-pkg=Qt6WaylandGlobalPrivate might reveal details why the package was not found. Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of the path variables that find_package uses to try and find the package. Call Stack (most recent call first): CMakeLists.txt:16 (find_package) ``` A public module should not require a private one, so either WaylandClient has a CMake error or it is not really public. -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Source: qt6-wayland Source-Version: 6.4.2-1 Done: Lisandro Damián Nicanor Pérez Meyer We believe that the bug you reported is fixed in the latest version of qt6-wayland, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1029...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Lisandro Damián Nicanor Pérez Meyer (supplier of updated qt6-wayland package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 17 Jan 2023 14:44:16 -0300 Source: qt6-wayland Architecture: source Version: 6.4.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Lisandro Damián Nicanor Pérez Meyer Closes: 1029098 Changes: qt6-wayland (6.4.2-1) unstable; urgency=medium . * Team upload. * Add libwayland-dev as qt6-wayland-dev dependency, as CMake files look for its presence. * Switch to the official 6.4.2 tarball, the tarball is the same. * Install private components, which are not tied to private headers and required by the main, public components (Closes: #1029098). Thanks Rodney Dawes for the bug report! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013222#50 Checksums-Sha1: 601a8bc4774de4bedc647f55c33025573ab1 3340 qt6-wayland_6.4.2-1.dsc 394c001681779c22aa39cf97216508e10dcb2a18 836720 qt6-wayland_6.4.2.orig.tar.xz e6a97ef2a95a113666396dd286296887960e93b8 46404 qt6-wayland_6.4.2-1.debian.tar.xz 37bb7cee6088e209c7680321248e1db30d8de805 14822 qt6-wayland_6.4.2-1_source.buildinfo Checksums-Sha256: 466dbd5f3040d9b67a0cc10b2fad4f741c4ee94c093308245497e9f012cbd1e0 3340 qt6-wayland_6.4.2-1.dsc 24cf1a0af751ab1637b4815d5c5f3704483d5fa7bedbd3519e6fc020d8be135f 836720 qt6-wayland_6.4.2.orig.tar.xz 4bd0d6f6a6a7cc9ffc1a61a6a26168c0ae6a1f4979fc1eb44f472217c51ea574 46404 qt6-wayland_6.4.2-1.debian.tar.xz 327dabef3a05ef5c4371e8c98f3159210328bd3539510b6267ddecf551ddcb2e 14822
Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate
Control: tag -1 pending These are indeed implementation-private modules, adding them does not requires the use of private headers. The fix has been implemented in commit 5e44bf5ab207edfbe481090e75478a750271a548. I'll be pushing the package ASAP. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Processed: Re: Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate
Processing control commands: > tag -1 pending Bug #1029098 [src:qt6-wayland] qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate Added tag(s) pending. -- 1029098: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029098 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1013222: Private headers
Hi, On Tue, 17 Jan 2023 at 14:15, Rodney Dawes wrote: > > On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Yes, but still not using Qt 6, so no need on our side to create more > > work for us while not yet there. It would be much much easier if they > > just used _stable_ API. And that's where we get back to upstream, > > plugins, etc. Create _stable_ API and everything goes smooth. > > Chicken, meet egg. Yes :-) > It would be much easier if Qt didn't require using private API to do > anything useful at this level. But here we are. Exactly. > Of course maliit isn't using Qt6 *yet* because in trying to do so, I > came across this issue already reported in Debian, which I use as my > main platform, and which has never presented such problem when > developing these projects before. Had the necessary private development > files already been available, we wouldn't even be having this > discussion, and I would already have maliit-framework building on Qt6 > (not least because I'm pretty sure I already did have it building as a > quick experiment, but when revisiting this yesterday, discovered the > private portion of qt6-wayland had been removed). I can offer you two solutions: 1. Come aboard maintaining Qt 6. Once you get a pair of Qt upgrades and you want to support private headers for the whole of the Qt 6 lifetime, you are welcome to add them and support them. 2. Break the chicken and egg issue by building your own Qt. You can use the debian packages as a base. Cheers, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1013222: Private headers
On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Yes, but still not using Qt 6, so no need on our side to create more > work for us while not yet there. It would be much much easier if they > just used _stable_ API. And that's where we get back to upstream, > plugins, etc. Create _stable_ API and everything goes smooth. Chicken, meet egg. It would be much easier if Qt didn't require using private API to do anything useful at this level. But here we are. Of course maliit isn't using Qt6 *yet* because in trying to do so, I came across this issue already reported in Debian, which I use as my main platform, and which has never presented such problem when developing these projects before. Had the necessary private development files already been available, we wouldn't even be having this discussion, and I would already have maliit-framework building on Qt6 (not least because I'm pretty sure I already did have it building as a quick experiment, but when revisiting this yesterday, discovered the private portion of qt6-wayland had been removed).
Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate
Probably the "Private" name here is misleading: this might be a private module but not directly related with public headers (ie, an implementation detail).
Bug#1013222: Private headers
On Tue, 17 Jan 2023 at 13:41, Rodney Dawes wrote: > > And to add to the point, currently the qt6-wayland package is broken in > Debian, even just trying to find it via CMake, because some of these > files have been removed. The following error is from simply checking > for the WaylandClient Qt component via: > > find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient) Thanks! I just filed a bug for that. Public modules should not require private headers, not the first time we see this kind of issues.
Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate
Source: qt6-wayland Version: 6.4.2~rc1-2 Severity: normal X-Debbugs-Cc: dobey.p...@gmail.com, lisan...@debian.org With a CMakeLists.txt having: find_package(Qt6 REQUIRED COMPONENTS WaylandClient) Runnning CMake issues: ``` -- Could NOT find Qt6WaylandGlobalPrivate (missing: Qt6WaylandGlobalPrivate_DIR) CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake but it set Qt6WaylandClient_FOUND to FALSE so package "Qt6WaylandClient" is considered to be NOT FOUND. Reason given by package: Qt6WaylandClient could not be found because dependency Qt6WaylandGlobalPrivate could not be found. Configuring with --debug-find-pkg=Qt6WaylandGlobalPrivate might reveal details why the package was not found. Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of the path variables that find_package uses to try and find the package. Call Stack (most recent call first): CMakeLists.txt:16 (find_package) ``` A public module should not require a private one, so either WaylandClient has a CMake error or it is not really public. -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1013222: Private headers
Hi, On Tue, 17 Jan 2023 at 13:32, Rodney Dawes wrote: > > On Tue, 2023-01-17 at 13:03 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Believe me I understand your frustration. But at the same time you > > don't know the pain it takes to maintain Qt as private headers get > > exposed. > > Actually, I do know. I work on Ubuntu Touch, where we maintained our > own Qt packages on top of Ubuntu. I've also worked on Plasma Mobile on > Manjaro, which ships the KDE patch collection on Qt5, which pulled in > some backported changes from Qt6, which broke ABI in the private API > side, causing much frustration. Being focused on mobile, there is also > the OpenGL vs GLES build issues. You do definitely know the landscape then :) > > Key Plasma packages are normally an exception, and Telegram desktop is > > definitely not a key plasma package. And again, yes, we would love to > > provide **everything**. But I sincerely do not see that happening > > until someone has proper Qt maintenance as his/her day job. > > If the situation of Qt/KDE in Debian is as bad as you say, can we not > reach out to Kubuntu/Neon devs to help out with it? Or maybe the Debian > UBports Team could help, given the heavy dependence on Qt which the > Lomiri stack has? The main Qt 5 maintainer is also Ubuntu's maintainer. From time to time people from Ubuntu try to help us, with various degrees of success, and here we are. Note that we do stress a lot what we think a Debian package should be, and sometimes that clashes with other distros expectations (and that's fine!). > I wasn't implying that telegram-desktop is a key > Plasma package, however, maliit-framework and maliit-keyboard are, I > would think. Yes, but still not using Qt 6, so no need on our side to create more work for us while not yet there. It would be much much easier if they just used _stable_ API. And that's where we get back to upstream, plugins, etc. Create _stable_ API and everything goes smooth. > > That being said the plan is to switch to Plasma with Qt 6 in Trixie > > (aka Debian 13), so I guess that after the freeze is over adding > > Qt-Wayland's private headers will be a must. > > But if nothing else in Debian would require these before the freeze, > why would it need to wait, since nothing would break as a result? No *key* package. As soon as we add private headers we gain non-key packages trying to use them, and thus more man power at the time of updating Qt. > Especially, given how anything that would require them is already > broken, so not having the private headers is already an issue (hence > this bug report). No, see above. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1013222: Private headers
And to add to the point, currently the qt6-wayland package is broken in Debian, even just trying to find it via CMake, because some of these files have been removed. The following error is from simply checking for the WaylandClient Qt component via: find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient) -- Could NOT find Qt6WaylandGlobalPrivate (missing: Qt6WaylandGlobalPrivate_DIR) CMake Warning at /usr/lib/x86_64-linux- gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package): Found package configuration file: /usr/lib/x86_64-linux- gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake but it set Qt6WaylandClient_FOUND to FALSE so package "Qt6WaylandClient" is considered to be NOT FOUND. Reason given by package: Qt6WaylandClient could not be found because dependency Qt6WaylandGlobalPrivate could not be found. Configuring with --debug-find-pkg=Qt6WaylandGlobalPrivate might reveal details why the package was not found. Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of the path variables that find_package uses to try and find the package. Call Stack (most recent call first): CMakeLists.txt:24 (find_package) CMake Error at CMakeLists.txt:24 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT FOUND. Reason given by package: Failed to find required Qt component "WaylandClient". Expected Config file at "/usr/lib/x86_64-linux- gnu/cmake/Qt6WaylandClient/Qt6WaylandClientConfig.cmake" exists Configuring with --debug-find-pkg=Qt6WaylandClient might reveal details why the package was not found. Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of the path variables that find_package uses to try and find the package. -- Configuring incomplete, errors occurred!
Bug#1013222: Private headers
On Tue, 2023-01-17 at 13:03 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Believe me I understand your frustration. But at the same time you > don't know the pain it takes to maintain Qt as private headers get > exposed. Actually, I do know. I work on Ubuntu Touch, where we maintained our own Qt packages on top of Ubuntu. I've also worked on Plasma Mobile on Manjaro, which ships the KDE patch collection on Qt5, which pulled in some backported changes from Qt6, which broke ABI in the private API side, causing much frustration. Being focused on mobile, there is also the OpenGL vs GLES build issues. > Key Plasma packages are normally an exception, and Telegram desktop is > definitely not a key plasma package. And again, yes, we would love to > provide **everything**. But I sincerely do not see that happening > until someone has proper Qt maintenance as his/her day job. If the situation of Qt/KDE in Debian is as bad as you say, can we not reach out to Kubuntu/Neon devs to help out with it? Or maybe the Debian UBports Team could help, given the heavy dependence on Qt which the Lomiri stack has? I wasn't implying that telegram-desktop is a key Plasma package, however, maliit-framework and maliit-keyboard are, I would think. > That being said the plan is to switch to Plasma with Qt 6 in Trixie > (aka Debian 13), so I guess that after the freeze is over adding > Qt-Wayland's private headers will be a must. But if nothing else in Debian would require these before the freeze, why would it need to wait, since nothing would break as a result? Especially, given how anything that would require them is already broken, so not having the private headers is already an issue (hence this bug report).
Bug#1013222: Private headers
Hi! On Tue, 17 Jan 2023 at 01:38, Rodney Dawes wrote: > > On Mon, 2023-01-16 at 23:35 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Maintaining Qt already takes a lot of time, adding private headers > > only makes things worse. So if you want to do porting and the headers > > are not yet there you will have to build Qt itself or fix the problem > > where it really belongs: upstream. > > Upstream? Where it's not a problem, because they ship and install the > private headers? Private headers are non stable API, and that's a problem. > No, this is an issue in Debian, because the headers are being > specifically excluded from packaging, rather than installed. Other > distributions provide these files without such politics. Why is it so > hard to maintain in Debian? The way Debian works (transitions) and man power. It is not politics, it's man power. > Fedora, OpenSUSE, Arch, etc… all have these > files available for installation and developing against. So, surely the > "maintenance burden" is not so high, right? Debian has britney to run > autopackage tests, specifically to prevent things breaking, no? Those > things still are going to break, when those files aren't provided, > since they can no longer build, no? That's actually the point: the maintenance burden **IS** high. Yes, even with britney testing stuff, we still need to manually build/trigger builds for all affected packages (all that use private headers), file bugs, cross fingers that maintainers will fix them or provide fix ourselves. Else we can't ask for a transition slot. Qt is currently (and has been mostly during all these years) maintained by one or two people. Currently Qt5 is maintained by Dmitry and Qt 6 by Patrick, and some people helping whenever possible (like me, nowadays). It's a huge task, one that would be better served by someone dedicated to it, which is not our case. So yes: man power IS an issue, and private headers only adds more man power requirements. Believe me I understand your frustration. But at the same time you don't know the pain it takes to maintain Qt as private headers get exposed. > There is nothing speculative here. The files are required to build many > things against Qt, regardless of whether it is version 5 or 6. > > Leaving the files out, only makes it harder for anyone to rely on > distribution provided packages. These are necessary for shipping KDE > Plasma 6, and many other things, in Debian. Key Plasma packages are normally an exception, and Telegram desktop is definitely not a key plasma package. And again, yes, we would love to provide **everything**. But I sincerely do not see that happening until someone has proper Qt maintenance as his/her day job. That being said the plan is to switch to Plasma with Qt 6 in Trixie (aka Debian 13), so I guess that after the freeze is over adding Qt-Wayland's private headers will be a must. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Re: Coloured character borders in kterm
On 16/01/2023 15:37, Miguel A. Vallejo wrote: Here is the apt log for january 13 and 14 Plenty of packages with something to do with fonts and rendering. libfreetype6 libfontembed1 fonts-wine libtiff6 and so on. And now these packages landed in Testing, packages due to upgrade in my system, among others: libfreetype-dev libfreetype6 libfreetype6-dev libfreetype6:i386 libgcc-11-dev libgl-dev libgl1 libgl1:i386 libgles-dev libgles1 libgles2 I think I will hold fire upgrading these packages, see what happens. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Bug#1029082: qtbase-opensource-src-gles FTCBFS: out of sync with qtbase-opensource-src
Source: qtbase-opensource-src-gles
Version: 5.15.8+dfsg-1
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
qtbase-opensource-src-gles fails to build from source, because it
requires its version to match exactly the version of
qtbase-opensource-src, but an upload is presently missing:
test "`dpkg-query -f '${Version}' -W qt5-qmake-bin`" = "5.15.8+dfsg-1"
make[1]: *** [debian/rules:73: override_dh_auto_configure] Error 1
Would you mind either uploading these packages in lockstep or relaxing
the version check (e.g. ignoring the Debian release) such that it no
longer fails?
Helmut
Bug#1029079: akonadi-backend-mysql: Build against default-mysql-{client,server}-core 1.1.0
Package: akonadi-backend-mysql
Version: 4:22.12.0-2
Severity: normal
X-Debbugs-Cc: sedat.di...@gmail.com
Dear Maintainer,
I removed akonadi-backend-mysql from my Debian/unstable AMD64 box as I need a
higher version of mariadb.
These changes were done on my latest upgrade:
-ii mariadb-client-core-10.61:10.6.11-2
+ii mariadb-client-core 1:10.11.1-1
-ii mariadb-server-core-10.61:10.6.11-2
+ii mariadb-server-core 1:10.11.1-1
-ii default-mysql-client-core 1.0.8
-ii default-mysql-server-core 1.0.8
+ii default-mysql-client-core 1.1.0
+ii default-mysql-server-core 1.1.0
-ii mysql-common5.8+1.0.8
+ii mysql-common5.8+1.1.0
Can you please build against latest default-mysql-{client,server}-core v1.1.0
aka mariadb 10.11?
Thanks.
Best regards,
-Sedat-
P.S.: From my upgrade log:
...
Unpacking default-mysql-server-core (1.1.0) over (1.0.8) ...
dpkg: mariadb-server-core-10.6: dependency problems, but removing anyway as you
requested:
akonadi-backend-mysql depends on default-mysql-server-core |
virtual-mysql-server-core; however:
Package default-mysql-server-core is not configured yet.
Package virtual-mysql-server-core is not installed.
Package mariadb-server-core-10.6 which provides virtual-mysql-server-core is
to be removed.
...
dpkg: mariadb-client-core-10.6: dependency problems, but removing anyway as you
requested:
akonadi-backend-mysql depends on default-mysql-client-core |
virtual-mysql-client-core; however:
Package default-mysql-client-core is not configured yet.
Package virtual-mysql-client-core is not installed.
Package mariadb-client-core-10.6 which provides virtual-mysql-client-core is
to be removed.
...
-- System Information:
Debian Release: unstable/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (99,
'buildd-unstable'), (99, 'buildd-experimental'), (99, 'experimental'), (99,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.2.0-rc4-1-amd64-clang15-kcfi (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de:en_US:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages akonadi-backend-mysql depends on:
ii default-mysql-client-core1.1.0
ii default-mysql-server-core1.1.0
ii libqt5sql5-mysql 5.15.8+dfsg-2
ii mariadb-client-core [virtual-mysql-client-core] 1:10.11.1-1
ii mariadb-server-core [virtual-mysql-server-core] 1:10.11.1-1
Versions of packages akonadi-backend-mysql recommends:
ii akonadi-server 4:22.12.0-2+b1
akonadi-backend-mysql suggests no packages.
-- no debconf information
