Re: [QGIS-Developer] How to handle upstream Qt fixes
On Wed, 15 Sept 2021 at 02:19, Alessandro Pasotti wrote: > > > Hi Nyall, > > We discussed this topic in today's PSC meeting and we have an answer about > the question if we can invest money for KDAB help in fixing Qt 5 bugs. > > The answer is yes, even if the patches are against an officially unsupported > Qt 5 version, if you want to contact them please go ahead. > > For windows we can apply the patches ourselves, for debian & friends there is > a good chance the KDE patches + any other patch that fixes critical bugs will > be applied anyway. Great, thanks for the update Alessandro! I've emailed KDAB to see if they are able to undertake this work. I'll report back here with developments. Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] How to handle upstream Qt fixes
Hi Nyall, We discussed this topic in today's PSC meeting and we have an answer about the question if we can invest money for KDAB help in fixing Qt 5 bugs. The answer is yes, even if the patches are against an officially unsupported Qt 5 version, if you want to contact them please go ahead. For windows we can apply the patches ourselves, for debian & friends there is a good chance the KDE patches + any other patch that fixes critical bugs will be applied anyway. Kind regards. On Fri, Sep 3, 2021 at 12:46 AM Nyall Dawson wrote: > Hi PSC, devs, > > I'd like to kick start some discussion on how best to handle the > situation with upstream Qt and their (lack of) support for Qt 5. As a > quick summary of the situation: > > - Qt Co effectively ended open source support of Qt 5 at the 5.15.2 > release, and have moved all focus to Qt 6. > - While some preliminary work has been done, QGIS doesn't currently > support Qt 6 based builds, and likely won't be ready for this for some > time (even completely ignoring all the stable API questions a Qt 6 > build raises entirely!) > - QGIS often depends on fixes and enhancements which need to be made > upstream in Qt, and can't be resolved or worked-around in QGIS alone > - KDE and other open source projects forked Qt 5.15 at > https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively > backporting fixes from Qt6 to that branch. Fedora recently started > using the KDE branch for Qt 5 library builds, so users of that > platform once again are getting bug fixes deployed [1]. I'm unaware if > other distributions or builds of Qt are using this currently. > - Similarly, there's a KDE fork of Qt 3d at > https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/ > > Right now, there's a number of very frustrating issues that Qt 5.15.2 > has which impact our users. An example is #44876, which results in > very large PDF exports from QGIS with broken hairline line rendering > [2]. In the past QGIS has contracted KDAB as part of the QGIS bug > fixing efforts to directly fix issues which affect QGIS users > upstream, with good results. Unfortunately, given that we are stuck on > Qt 5.15.2 and upstream won't release any more 5.15.x versions, we > can't just do that same approach again to get fixes into Qt. > > So I'd like to raise discussions about the best way we can handle this > situation as a downstream project. > > My thoughts/questions: > > - Are we free to change the Windows builds to use the KDE backports > fork of 5.15 instead of the official 5.15.2 releases? (Or does that > change lots of osgeo4w packaging things?). Similarly, are we free to > move the MacOS builds to the KDE branch too? > - Could we also move the Windows/MacOS builds of Qt 3d to use the KDE fork? > - Does anyone know if Debian have plans to migrate to the KDE > backports fork? (Last I heard, the debian Qt maintainers stepped down > and the package is currently lacking a maintainer!) > - If we can get the majority of our users onto builds which use the > KDE backports branch (i.e. Windows/mac users), could we re-start the > relationship with KDAB and contract them for bug fixes again for 3.22? > (with the arrangement explicitly requiring them to backport fixes to > Qt 5 via KDE's fork). > > Nyall > > [1] > https://src.fedoraproject.org/rpms/qt5-qtbase/c/400d49b3925dc2852218289310674abd3950b4e0?branch=rawhide > [2] https://github.com/qgis/QGIS/issues/44876 > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] How to handle upstream Qt fixes
On Sat, 4 Sept 2021 at 07:03, Jürgen E. Fischer wrote: > > Hi Nyall, > > On Fri, 03. Sep 2021 at 08:46:21 +1000, Nyall Dawson wrote: > > - KDE and other open source projects forked Qt 5.15 at > > https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively > > backporting fixes from Qt6 to that branch. Fedora recently started > > using the KDE branch for Qt 5 library builds, so users of that > > platform once again are getting bug fixes deployed [1]. I'm unaware if > > other distributions or builds of Qt are using this currently. > > - Similarly, there's a KDE fork of Qt 3d at > > https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/ > > I asked on #debian-qt-kde on OFTC and they are apparently not planning to > apply > the patch collection blindly, but probably would apply individual patches (of > the currently 222 qtbase and 33 in qt3d patches) that we need. Ok, thanks for the insights. FWIW it looks like Fedora is taking the opposite direction and will be migrating ALL Qt packages to the community forks. See https://bugzilla.redhat.com/show_bug.cgi?id=2000789#c1 > > > Right now, there's a number of very frustrating issues that Qt 5.15.2 > > has which impact our users. An example is #44876, which results in > > very large PDF exports from QGIS with broken hairline line rendering > > [2]. > > Do you know whether the PDF issue is already addressed in the patch > collection? No, it's still open upstream: https://bugreports.qt.io/browse/QTBUG-86094 . (So even if we moved to qt6 today it'd still be an issue). > > - Are we free to change the Windows builds to use the KDE backports > > fork of 5.15 instead of the official 5.15.2 releases? (Or does that > > change lots of osgeo4w packaging things?). Similarly, are we free to > > move the MacOS builds to the KDE branch too? > > - Could we also move the Windows/MacOS builds of Qt 3d to use the KDE fork? > > I suppose so - I would probably just apply them all in OSGeo4W and hope for > the > best ;) I honestly don't think there'd be any higher risk in trusting the community fork vs the official Qt releases. We all know how often those regress *eye roll*. Maybe a community maintained fork is EXACTLY what Qt needs to get back on track. > > - If we can get the majority of our users onto builds which use the > > KDE backports branch (i.e. Windows/mac users) > > Do we know that there are significantly more users on Mac than on free > platforms? Nope. I'm mostly referring to Windows there! Nyall > > , could we re-start the relationship with KDAB and contract them for bug > > fixes again for 3.22? (with the arrangement explicitly requiring them to > > backport fixes to Qt 5 via KDE's fork). > > I'd say yes. > > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 > Software Engineer D-26506 Nordenhttps://www.norbit.de > QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] How to handle upstream Qt fixes
On Fri, 3 Sept 2021 at 19:16, Andreas Neumann wrote: > > Hi all, > > Thank you Nyall for raising these questions - and Greg for joining the > discussion. > > Obviously, the questions are not easy and straight-foward to answer. They > also depend on what the other OS projects will do about this situation in > general. > > Perhaps we can also ask the KDAB folks what they think about this situation > and if they would recommend to continuously work on extending the life span > of qt5x. > > I can mainly comment on the financial aspects: if, after thorough discussion, > we think that staying longer with qt5 is the way the project should follow, > we can of course continue to invest a bit upstream to fix issues through > KDAB. However, the risk is now higher with potential forks and disconnects > from the official qt. Just to clarify -- I'd make sure we require that all fixes land in qt6 first, to ensure that the work isn't a dead-end. Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] How to handle upstream Qt fixes
Hi Nyall, On Fri, 03. Sep 2021 at 08:46:21 +1000, Nyall Dawson wrote: > - KDE and other open source projects forked Qt 5.15 at > https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively > backporting fixes from Qt6 to that branch. Fedora recently started > using the KDE branch for Qt 5 library builds, so users of that > platform once again are getting bug fixes deployed [1]. I'm unaware if > other distributions or builds of Qt are using this currently. > - Similarly, there's a KDE fork of Qt 3d at > https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/ I asked on #debian-qt-kde on OFTC and they are apparently not planning to apply the patch collection blindly, but probably would apply individual patches (of the currently 222 qtbase and 33 in qt3d patches) that we need. > Right now, there's a number of very frustrating issues that Qt 5.15.2 > has which impact our users. An example is #44876, which results in > very large PDF exports from QGIS with broken hairline line rendering > [2]. Do you know whether the PDF issue is already addressed in the patch collection? > - Are we free to change the Windows builds to use the KDE backports > fork of 5.15 instead of the official 5.15.2 releases? (Or does that > change lots of osgeo4w packaging things?). Similarly, are we free to > move the MacOS builds to the KDE branch too? > - Could we also move the Windows/MacOS builds of Qt 3d to use the KDE fork? I suppose so - I would probably just apply them all in OSGeo4W and hope for the best ;) > - Does anyone know if Debian have plans to migrate to the KDE > backports fork? (Last I heard, the debian Qt maintainers stepped down > and the package is currently lacking a maintainer!) see above. > - If we can get the majority of our users onto builds which use the > KDE backports branch (i.e. Windows/mac users) Do we know that there are significantly more users on Mac than on free platforms? > , could we re-start the relationship with KDAB and contract them for bug > fixes again for 3.22? (with the arrangement explicitly requiring them to > backport fixes to Qt 5 via KDE's fork). I'd say yes. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Nordenhttps://www.norbit.de QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC signature.asc Description: PGP signature norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827 Datenschutzerklaerung: https://www.norbit.de/83/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] How to handle upstream Qt fixes
Hi all, Thank you Nyall for raising these questions - and Greg for joining the discussion. Obviously, the questions are not easy and straight-foward to answer. They also depend on what the other OS projects will do about this situation in general. Perhaps we can also ask the KDAB folks what they think about this situation and if they would recommend to continuously work on extending the life span of qt5x. I can mainly comment on the financial aspects: if, after thorough discussion, we think that staying longer with qt5 is the way the project should follow, we can of course continue to invest a bit upstream to fix issues through KDAB. However, the risk is now higher with potential forks and disconnects from the official qt. About the other questions around OSGEO4W I hope that Jürgen can give a useful reply - him being probably the "most technical" person on the QGIS PSC - and also the OSGEO4W main packager. Thanks and greetings, Andreas On 2021-09-03 01:27, Greg Troxel wrote: Nyall Dawson writes: - Qt Co effectively ended open source support of Qt 5 at the 5.15.2 release, and have moved all focus to Qt 6. - While some preliminary work has been done, QGIS doesn't currently support Qt 6 based builds, and likely won't be ready for this for some time (even completely ignoring all the stable API questions a Qt 6 build raises entirely!) - QGIS often depends on fixes and enhancements which need to be made upstream in Qt, and can't be resolved or worked-around in QGIS alone - KDE and other open source projects forked Qt 5.15 at https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively backporting fixes from Qt6 to that branch. Fedora recently started using the KDE branch for Qt 5 library builds, so users of that platform once again are getting bug fixes deployed [1]. I'm unaware if other distributions or builds of Qt are using this currently. - Similarly, there's a KDE fork of Qt 3d at https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/ I'm speaking as the maintainer of the qgis package in pkgsrc, a multi-OS multi-CPU packaging system. Currently this is 3.16.x, and it is built against 5.15.2 (only). I think you have posed semi-separable questions and it's good to semi-separate them: - 1. should qgis target the KDE fork of QT, or 5.15.2, or both, as the library that is expected to be used, and tested in CI? - 2. when qgis.org produces binary builds, should qt-kde or qt be used? - 3. should qgis.org attempt to engage with KDAB to work on a fork of a branch discontinued by the original maintainers? - 4. Given what I see as concerning behavior by Qt Co in placing Free Software users in a bad spot, what should be the future approach to Qt? Perhaps, it should be KDE Qt 5.15, and not Qt 6.) and I think this is informed in large part by understanding the degree to which the various packaging systems (a term that I use to include GNU/Linux distributions) switch the KDE fork. In my view where Debian lands, if at all, is very influential. I will inquire within pkgsrc about the KDE fork and intent to have our Qt 5 packages track them. I am guessing that it's meant to be just a continuation of maintenance, for now, and thus quite compatible. I think that (1) is the current primary question. Choice (2) mostly flows from the answer to (1), in that it's reasonable to target 5.15.2(release) but also test with 5.15.2.kde.x, and use .kde for binaries on the theory that it has bugfixes. It's also reasonable -- if enough packaging systems move or provide the KDE fork -- to just say that testing is only against that -- but qgis seems to support older Qt anyway, and it would seem radical to demand a particular rev of 5.15 at this point. If (1) is decided in favor of the fork, then (3) seems reasonable. (4) is a hard discussion that I think should be deferred a bit until we see how the Free Software world's approach to Qt settles out. It reamains to be seen how that's going to go between extremes of being content about the withdrawal of support and just moving to 6, and deciding that qt's model wasn't such a good idea after all and that it's best to use a truly Free fork or start to get away from it entirely. Pretty obviously neither extreme is likely, but I have little confidence in guesses about where we'll land. Greg ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] How to handle upstream Qt fixes
Nyall Dawson writes: > - Qt Co effectively ended open source support of Qt 5 at the 5.15.2 > release, and have moved all focus to Qt 6. > - While some preliminary work has been done, QGIS doesn't currently > support Qt 6 based builds, and likely won't be ready for this for some > time (even completely ignoring all the stable API questions a Qt 6 > build raises entirely!) > - QGIS often depends on fixes and enhancements which need to be made > upstream in Qt, and can't be resolved or worked-around in QGIS alone > - KDE and other open source projects forked Qt 5.15 at > https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively > backporting fixes from Qt6 to that branch. Fedora recently started > using the KDE branch for Qt 5 library builds, so users of that > platform once again are getting bug fixes deployed [1]. I'm unaware if > other distributions or builds of Qt are using this currently. > - Similarly, there's a KDE fork of Qt 3d at > https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/ I'm speaking as the maintainer of the qgis package in pkgsrc, a multi-OS multi-CPU packaging system. Currently this is 3.16.x, and it is built against 5.15.2 (only). I think you have posed semi-separable questions and it's good to semi-separate them: - 1. should qgis target the KDE fork of QT, or 5.15.2, or both, as the library that is expected to be used, and tested in CI? - 2. when qgis.org produces binary builds, should qt-kde or qt be used? - 3. should qgis.org attempt to engage with KDAB to work on a fork of a branch discontinued by the original maintainers? - 4. Given what I see as concerning behavior by Qt Co in placing Free Software users in a bad spot, what should be the future approach to Qt? Perhaps, it should be KDE Qt 5.15, and not Qt 6.) and I think this is informed in large part by understanding the degree to which the various packaging systems (a term that I use to include GNU/Linux distributions) switch the KDE fork. In my view where Debian lands, if at all, is very influential. I will inquire within pkgsrc about the KDE fork and intent to have our Qt 5 packages track them. I am guessing that it's meant to be just a continuation of maintenance, for now, and thus quite compatible. I think that (1) is the current primary question. Choice (2) mostly flows from the answer to (1), in that it's reasonable to target 5.15.2(release) but also test with 5.15.2.kde.x, and use .kde for binaries on the theory that it has bugfixes. It's also reasonable -- if enough packaging systems move or provide the KDE fork -- to just say that testing is only against that -- but qgis seems to support older Qt anyway, and it would seem radical to demand a particular rev of 5.15 at this point. If (1) is decided in favor of the fork, then (3) seems reasonable. (4) is a hard discussion that I think should be deferred a bit until we see how the Free Software world's approach to Qt settles out. It reamains to be seen how that's going to go between extremes of being content about the withdrawal of support and just moving to 6, and deciding that qt's model wasn't such a good idea after all and that it's best to use a truly Free fork or start to get away from it entirely. Pretty obviously neither extreme is likely, but I have little confidence in guesses about where we'll land. Greg signature.asc Description: PGP signature ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
