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#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
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? 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? 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? 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.
Bug#1013222: Private headers
On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi > > Private packages have only been created when required for other Qt > submodules or key plasma packages, no more. They are required for key plasma packages here, as well. It is necessary to use these private headers to be able to write plugins to Qt itself, such as for providing support for additional wayland protocols in Qt, and to provide input method support on Wayland using Qt API. I found this issue as I was getting build errors on doing some work to port the wayland code in maliit-framework to Qt6. > > That's because kwin required those headers. As soon as kwin switches > to Qt6 we will know if we need to make them available. If kwin is also using them, then you can be assured they will still be needed, as very little has changed in QtWayland in 6.x from 5.x. As I have found, they are still needed for the on-screen keyboard support. > And no, existing private headers are not free, it is a real pain > because they normally just make transitions more complicated. > > Ideally people should work with Qt upstream in order to avoid > requiring private headers. Most of these needs are long standing issues which I'm sure Qt upstream is well aware of. Third party style plugins for example is a well known case where one must use private API, and it is still the case. Migrating things from private to public API is never a simple task, and even if we could get it done, it would likely take years to get there.
Bug#1013222: Private headers
On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF- 8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?= wrote: > Hi! > > I would really love to know why Telegram developers require so many > private headers from Qt. They shouldn't be using them at all, and if > they really require some private part they need to work with upstream > to make it public API. This isn't only an issue for Telegram. Many projects require private headers for various reasons, because developing plugins to Qt itself is necessary to improve the system. The Qt packages have a long history of including `-private-dev` packages for the various components which provide private API that may be necessary to use in certain situations. There is no reason for that to stop happening with Qt 6.x. Especially given the upstream source is installing them during the build. The qtwayland5-private-dev package is available in Debian, and so should a qt6-wayland-private-dev package be made available containing the includes, cmake files, libraries, etc… necessary to use the QtWayland private API with Qt6.
Bug#597548: python3-distutils-extra: GPL3 license not documented
On Thu, 2010-09-23 at 13:21 +0200, Martin Pitt wrote: Hello Torsten, Torsten Werner [2010-09-20 20:29 +0200]: DistUtilsExtra/command/check.py is Copyright 2009 Canonical Ltd. and GPL3 licensed. Please document it in the copyright file. Thanks for pointing this out. I updated the copyright file in the packaging trunk, but I still need Rodney's agreement for the license change. Rodney, would you mind putting this under GPL-2+, so that it's consistent with the rest of the code? Thanks in advance! Yes, that's fine. Go ahead and fix the comment in the file. It was supposed to be the same as whatever DistUtilsExtra was already using, anyway, so not sure why it went in as GPL3. Sorry. signature.asc Description: This is a digitally signed message part
