Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On 03/12/18 09:46, Ben Cooksley wrote: > Hi all, Hi Ben > > I've been informed by the PIM developers that they would like to bump > the dependency of the Qt version they use, from Qt 5.9 which it's on > currently, to Qt 5.10. > > As a consequence, due to many KDE projects using PIM libraries, their > dependency on Qt will also be effectively bumped. To minimize the > maintenance cost of this bump for the CI system, I would like to bump > everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end > up chasing down build failures for a long time) It's not clear if you are suggesting to bump the minimum required Qt version in each CMakeLists.txt file, or if you are just going to bump the Qt version used by the CI server. Could you please clarify? Thanks! > > As most distributions have moved on from 5.10, and use Qt 5.11 now > (and will in many cases soon move to Qt 5.12), i'd like to suggest > that instead of going to Qt 5.10, we move straight to 5.11. > > Because Frameworks has a two versions prior support policy, it'll > remain on 5.9 for now until it's ready to move up to 5.10 (assuming > 5.12 is a usable Qt version) > > If nobody has any objections, i'll proceed with this change in around > 3 days time. > > Cheers, > Ben > Cheers, Elvis
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On Tue, Dec 4, 2018 at 9:45 AM Elvis Angelaccio wrote: > > > > On 03/12/18 09:46, Ben Cooksley wrote: > > Hi all, > > Hi Ben Hi Elvis, > > > > > I've been informed by the PIM developers that they would like to bump > > the dependency of the Qt version they use, from Qt 5.9 which it's on > > currently, to Qt 5.10. > > > > As a consequence, due to many KDE projects using PIM libraries, their > > dependency on Qt will also be effectively bumped. To minimize the > > maintenance cost of this bump for the CI system, I would like to bump > > everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end > > up chasing down build failures for a long time) > > It's not clear if you are suggesting to bump the minimum required Qt > version in each CMakeLists.txt file, or if you are just going to bump > the Qt version used by the CI server. > > Could you please clarify? Thanks! I'll only be bumping the version used by the CI system, the applications themselves will be left unchanged. > > > > > As most distributions have moved on from 5.10, and use Qt 5.11 now > > (and will in many cases soon move to Qt 5.12), i'd like to suggest > > that instead of going to Qt 5.10, we move straight to 5.11. > > > > Because Frameworks has a two versions prior support policy, it'll > > remain on 5.9 for now until it's ready to move up to 5.10 (assuming > > 5.12 is a usable Qt version) > > > > If nobody has any objections, i'll proceed with this change in around > > 3 days time. > > > > Cheers, > > Ben > > > > Cheers, > Elvis Cheers, Ben
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote: > Can't you just configure the CI to use Qt 5.10? I think it's not good to > hardcode an "overzealous" (for lack of a better word) Qt version in > projects that don't require them AND I think that one should support the > current LTS release in as many projects as possible as a general rule of > principle. > > There's a reason why those LTS releases exist and that should probably be > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why > kdelibs4 was split up)! Which is exactly why 5.11.3 (released today) should be picked. It contains all fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to 5.10.1 means regressing all those fixes. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
[QUESTION] KIO slave-socket shortcut - does it exist?
Background: I want to sandbox KDE apps and need to understand better how KIO works. My current level of understanding is that apps ask klauncher/kdeinit for a KIO slave if they need one. Then either kdeinit spawns a new slave process, or there is already an idle slave and it is reused. Idle slaves kill themselves after a couple of minutes if no request is coming in. Communication between the slave and the app happens via a socket, usually to find in /run/user/$UID. The question is if, or rather when, it is possible to shortcut this process. Do slaves, especially idle ones, accept commands issued by third programs via these sockets? Try to take the perspective of an evil-minded adversary. Thank you very much!
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va escriure: > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote: > > Can't you just configure the CI to use Qt 5.10? I think it's not good to > > hardcode an "overzealous" (for lack of a better word) Qt version in > > projects that don't require them AND I think that one should support the > > current LTS release in as many projects as possible as a general rule of > > principle. > > > > There's a reason why those LTS releases exist and that should probably be > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why > > kdelibs4 was split up)! > > Which is exactly why 5.11.3 (released today) should be picked. It contains > all > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to > 5.10.1 means regressing all those fixes. It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10. Of course users should be using 5.11.3, but that's a different story. Cheers, Albert
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On Wed, Dec 5, 2018 at 7:22 AM Albert Astals Cid wrote: > > El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va > escriure: > > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote: > > > Can't you just configure the CI to use Qt 5.10? I think it's not good to > > > hardcode an "overzealous" (for lack of a better word) Qt version in > > > projects that don't require them AND I think that one should support the > > > current LTS release in as many projects as possible as a general rule of > > > principle. > > > > > > There's a reason why those LTS releases exist and that should probably be > > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why > > > kdelibs4 was split up)! > > > > Which is exactly why 5.11.3 (released today) should be picked. It contains > > all > > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to > > 5.10.1 means regressing all those fixes. > > It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10. > > Of course users should be using 5.11.3, but that's a different story. So you'd prefer we move to Qt 5.10 then, and then do another move to 5.11 when Frameworks moves it's bar up? > > Cheers, > Albert > > Regards, Ben
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
El dimarts, 4 de desembre de 2018, a les 20:13:43 CET, Ben Cooksley va escriure: > On Wed, Dec 5, 2018 at 7:22 AM Albert Astals Cid wrote: > > > > El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va > > escriure: > > > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote: > > > > Can't you just configure the CI to use Qt 5.10? I think it's not good to > > > > hardcode an "overzealous" (for lack of a better word) Qt version in > > > > projects that don't require them AND I think that one should support the > > > > current LTS release in as many projects as possible as a general rule of > > > > principle. > > > > > > > > There's a reason why those LTS releases exist and that should probably > > > > be > > > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why > > > > kdelibs4 was split up)! > > > > > > Which is exactly why 5.11.3 (released today) should be picked. It > > > contains all > > > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to > > > 5.10.1 means regressing all those fixes. > > > > It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10. > > > > Of course users should be using 5.11.3, but that's a different story. > > So you'd prefer we move to Qt 5.10 then, and then do another move to > 5.11 when Frameworks moves it's bar up? Personally, yes, it's much easier to detect apps requiring 5.11 API when they don't pretend to (not sure there's much new api in 5.11 but anyhow). I mean in an ideal world we'd compile each app with their required min Qt version to detect those things, but since that's not possible with the current setup let's settle for the smallest possible version. And Frameworks requiring 5.11 is still kind of far no? Cheers, Albert > > > > > Cheers, > > Albert > > > > > > Regards, > Ben
Re: [QUESTION] KIO slave-socket shortcut - does it exist?
On 04/12/18 16:37, Smits Katze wrote: > Background: I want to sandbox KDE apps and need to understand better how > KIO works. > > My current level of understanding is that apps ask klauncher/kdeinit for > a KIO slave if they need one. Then either kdeinit spawns a new slave > process, or there is already an idle slave and it is reused. Idle slaves > kill themselves after a couple of minutes if no request is coming in. > Communication between the slave and the app happens via a socket, > usually to find in /run/user/$UID. > > The question is if, or rather when, it is possible to shortcut this > process. You can bypass klauncher/kdeinit by exporting the KDE_FORK_SLAVES environment variable set to 1. Then the applications will spawn the ioslave process on their own. Not sure if this actually helps you, though. > Do slaves, especially idle ones, accept commands issued by > third programs via these sockets? Try to take the perspective of an > evil-minded adversary. > > Thank you very much! Cheers, Elvis
Re: [QUESTION] KIO slave-socket shortcut - does it exist?
El dimarts, 4 de desembre de 2018, a les 16:37:34 CET, Smits Katze va escriure: > Background: I want to sandbox KDE apps and need to understand better how > KIO works. > > My current level of understanding is that apps ask klauncher/kdeinit for a > KIO slave if they need one. Then either kdeinit spawns a new slave process, > or there is already an idle slave and it is reused. Idle slaves kill > themselves after a couple of minutes if no request is coming in. > Communication between the slave and the app happens via a socket, usually > to find in /run/user/$UID. > > The question is if, or rather when, it is possible to shortcut this > process. Do slaves, especially idle ones, accept commands issued by third > programs via these sockets? Try to take the perspective of an evil-minded > adversary. Do you mean this as a security issue? Albert > > Thank you very much! >
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On Wed, Dec 5, 2018 at 8:18 AM Albert Astals Cid wrote: > > El dimarts, 4 de desembre de 2018, a les 20:13:43 CET, Ben Cooksley va > escriure: > > On Wed, Dec 5, 2018 at 7:22 AM Albert Astals Cid wrote: > > > > > > El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va > > > escriure: > > > > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote: > > > > > Can't you just configure the CI to use Qt 5.10? I think it's not good > > > > > to > > > > > hardcode an "overzealous" (for lack of a better word) Qt version in > > > > > projects that don't require them AND I think that one should support > > > > > the > > > > > current LTS release in as many projects as possible as a general rule > > > > > of > > > > > principle. > > > > > > > > > > There's a reason why those LTS releases exist and that should > > > > > probably be > > > > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember > > > > > why > > > > > kdelibs4 was split up)! > > > > > > > > Which is exactly why 5.11.3 (released today) should be picked. It > > > > contains all > > > > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to > > > > 5.10.1 means regressing all those fixes. > > > > > > It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10. > > > > > > Of course users should be using 5.11.3, but that's a different story. > > > > So you'd prefer we move to Qt 5.10 then, and then do another move to > > 5.11 when Frameworks moves it's bar up? > > Personally, yes, it's much easier to detect apps requiring 5.11 API when they > don't pretend to (not sure there's much new api in 5.11 but anyhow). I mean > in an ideal world we'd compile each app with their required min Qt version to > detect those things, but since that's not possible with the current setup > let's settle for the smallest possible version. Fair enough. > > And Frameworks requiring 5.11 is still kind of far no? That will happen once Qt 5.13 starts to come up for release? As we have no choice in regards to the bump to 5.10 (because PIM will be forcing the issue) i've started the process now of moving all of Applications, Extragear, Calligra and KDevelop over to 5.10 for Linux builds. > > Cheers, > Albert Regards, Ben > > > > > > > > > Cheers, > > > Albert > > > > > > > > > > Regards, > > Ben > > > >
